Génération du schéma logique de données

Durant l’application de notre approche sur l’ontologie LUBM, nous avons classé les classes ontologiques selon leur canonicité. Pour chaque type de classe, nous proposons un traitement spécifique tel que décrit dans la section 2.2.5. Par exemple, en se référant aux CC et CNC identifiées, nous proposons de traiter le cas des classes Course et DoctoralCourse décrivant respectivement l’ensemble des cours universitaires et la totalité des cours doctoraux.

Étant donnée queCourse est une classe canonique, nous procédons à sa normalisation en se basant sur les dépendances fonctionnelles définies sur ses propriétés des données IdCourse, Course_Name,DurationetCourse_leveldécrivant respectivement l’identifiant d’un cours, son intitulé, sa durée et son niveau d’enseignement. En exécutant la requête OntoQL ci-dessous, les structures de données associées à cette classe sont générées.

CREATE ALLEXTENT OF Course (IdCourse,Course_Name,Duration,Course_level) Ainsi, une table normalisée nomméeCourse_0 (IdCourse,Course_Name,Duration,Course_

level) est générée. De plus, une vue relationnelle portant le nom de la classe en question (View Course(IdCourse,Course_Name, Duration,Course_level) est définie. La figure 6.11 traduit cet exemple. En ce qui concerne la classe non canoniqueDoctoralCoursedécrite comme étant une restriction de la classeCoursesur la propriétéCourse_level(≡ ∃Course_level.{Phd}), une vue de classe est définie comme suit :

Create View DoctoralCourse as

(select * from Course where Course_level = ’Phd’)

Figure6.11 – Exemple de traitement d’une classe canonique

5 Comparaison des approches de conception

Dans cette section, nous proposons une étude comparative de notre méthodologie de concep-tion desBDBOet des deux principales approches étudiées dans le chapitre 1.4 : celle de [del Mar Roldán García et al., 2005] et celle de [Fankam et al., 2009]. Dans cette étude, nous nous intéressons à six principaux critères.

1. Réutilisation de la connaissance du domaine. Ceci est assuré par la réutilisation de la sé-mantique formalisée du domaine telle qu’elle est définie dans les ontologies. Dans [del Mar Roldán García et al., 2005], les auteurs ébauchent une méthodologie pour la concep-tion des bases de données en se basant sur une ontologie de domaine prédéfinie. Dans [Fankam et al., 2009], Fankam et .al proposent une approche de conception de base de données fondée sur les ontologies de domaine. Dans notre approche, nous proposons de choisir une ontologie partagée identifiée à partir du domaine de l’application. Ainsi, la réutilisation de la connaissance du domaine est assurée par les trois approches grâce à l’exploitation de l’ontologie du domaine.

2. Intégration. Ce critère concerne l’intégration future des bases de données conçues à partir de la même ontologie de domaine. Contrairement à l’approche de [del Mar Roldán García et al., 2005] où le lien entre données et ontologie est indéfini, dans notre approche ainsi que dans celle de [Fankam et al., 2009], ce lien est indiqué ce qui facilite et assure une telle intégration.

3. Gestion des dépendances ontologiques. Ce critère concerne la modélisation des dépen-dances entre les concepts ontologiques et leur intégration dans le modèle d’ontologies.

Ces dépendances incluent (i) les dépendances définies sur les propriétés ontologiques et (ii) les dépendances entre les classes ontologiques. Contrairement aux approches de [del Mar Roldán García et al., 2005] et de [Fankam et al., 2009], dans notre approche,

6. Conclusion nous proposons la modélisation de telles dépendances et leur intégration dans le modèle d’ontologies en étendant le modèle formel proposé dans [Bellatreche et al., 2003] par les dépendances entre classes (CD) et les dépendances entre propriétés (PFD).

4. Placement. Ce critère décrit l’organisation des classes ontologiques (canoniques et non canoniques) dans la bonne hiérarchie de subsomption. Contrairement aux approches de [del Mar Roldán García et al., 2005] et de [Fankam et al., 2009] où les classes de l’ontolo-gie peuvent être définies sans spécifier leur relation de subsomption, nous proposons dans notre méthodologie, de compléter la description de cette hiérarchie en (a) définissant un ensemble de règles de placement pour un ensemble de constructeurs (union, intersection, etc.) et (b) en exploitant les raisonneurs existants pour établir le placement de ces classes.

5. BDBO en troisième forme normale. Étant donné que les dépendances ontologiques ne sont pas gérées par les approches proposées par [del Mar Roldán García et al., 2005] et [Fankam et al., 2009], offrir un schéma normalisé reste une tâche très difficile pour le concepteur. Par contre, dans notre approche, nous proposons la génération d’un schéma logique de données normalisé exploitant les dépendances définies entre les concepts on-tologiques et réduisant par la suite la redondance et l’inconsistance des données dans la base de données cible.

6. Déploiement. Ce critère concerne la description du processus de déploiement de l’ap-proche proposée dans la base de données cible. Vue la diversité des architectures des BDBOet la variété des modèles de stockage, nous proposons une étude du processus de déploiement de notre approche dans les bases de données à base ontologique. Notons que ce point n’a pas été traité dans les deux autres approches.

La figure 6.12 illustre l’étude comparative proposée.

6 Conclusion

Dans ce chapitre, deux approches sont présentées. Dans un premier temps, nous avons pro-posé une méthodologie dédiée à la conception d’une base de données à base ontologique à partir d’une ontologie de domaine. Inspirée des méthodologies de conception des bases de données classiques, cette approche traite les différentes phases traditionnelles du processus de concep-tion: les modélisations conceptuelle, logique et physique. Cette méthode considère les onto-logies locales comme des modèles conceptuels et emprunte des techniques formelles issues à la fois de la théorie des graphes pour l’analyse de dépendances, du raisonnement déduit de la logique de description pour le placement des classes et de la théorie des bases de données relationnelles pour la création des vues relationnelles, définies sur des tables normalisées et as-sociées aux classes canoniques. De plus, elle considère différents types de dépendances entre les concepts ontologiques à des niveaux différents de conception. Dans un deuxième temps, étant donné la diversité des architectures des bases de données à base ontologique et la variété

Figure6.12 – Comparaison des approches de conception.

de leurs modèles de stockage, nous avons étudié la complexité de la phase de déploiement. En se basant sur cette étude, nous avons proposé une approche présentant un déploiement à la carte ayant pour but de satisfaire les préférences du déployeur quant à ses choix portant sur les ar-chitectures et les modèles de stockage. Celle-ci permet d’abord de réduire la combinatoire des solutions possibles avant le calcul de la meilleur solution suivant un modèle de coût donné. En-fin, un scénario de déploiement dans un environnement de base de données à base de modèles OntoDB est présenté. Dans le chapitre suivant, nous présentons l’implémentation de ce scénario une telle base.

Chapitre 7

Prototype de validation

Sommaire

1 Introduction . . . 155 2 OBDBDesignTool : un outil d’aide à la conception des BD à partir

d’une ontologie conceptuelle . . . 155 2.1 Description de l’outil . . . 155 2.2 Description de l’interface graphique . . . 157

2.2.1 Module I : Chargement et visualisation de l’ontologie globale . . . 157 2.2.2 Module II : Définition de l’ontologie locale . . . 157 2.2.3 Module III : Gestion de la canonicité . . . 158 2.2.4 Module VI : Génération du schéma relationnel . . . . 158 2.2.5 Module V : Génération du script . . . 160 3 Validation sous OntoDB : Extension du langage OntoQL . . . 160 3.1 Création des dépendances ontologiques . . . 162 3.1.1 Création d’une dépendance entre les classes ontologiques162 3.1.2 Création d’une dépendance fonctionnelle entre les

pro-priétés ontologiques . . . 162 3.2 Création de l’extension d’une classe . . . 163

3.2.1 Dépendances fonctionnelles entre propriétés et créa-tion de l’extension d’une classe . . . 163 3.2.2 Création générique de l’extension d’une classe . . . . 165 4 Implémentation . . . 165 4.1 Mise en œuvre d’OBDBDesignTool . . . 165 4.1.1 Environnement de travail . . . 166 4.1.2 Architecture de l’outil . . . 167 4.1.3 Analyse conceptuelle . . . 167 4.1.4 Génération du code . . . 174

4.2 Implantation de la méthodologie sous OntoDB . . . 174 4.2.1 Environnement de travail . . . 174 4.2.2 Architecture générale du processus de validation sous

OntoDB . . . 176 4.2.3 Développements réalisés . . . 176 5 Conclusion . . . 181

Résumé. Dans les deux derniers chapitres, deux principales approches ont été pro-posées. La première décrit une méthode de conception d’une base de données à base ontologique à partir d’une ontologie conceptuelle tandis que la seconde pré-sente le mécanisme de déploiement des données ontologiques après la conception d’une telle base. Dans ce chapitre, nous montrons la faisabilité de leur implantation en présentant leur mise en oeuvre sur laBDBOOntoDB. De plus, nous proposons un outil d’aide à la conception des bases de données à base de modèles à partir d’une ontologie conceptuelle adoptant notre approche de conception. Cet outil a pour ob-jectif d’accompagner le concepteur durant les différentes étapes de modélisation à travers la proposition d’une interface graphique.

1. Introduction

1 Introduction

Dans cette thèse, deux approches sont proposées. La première présente une méthode de conception d’une base de données à base ontologique à partir d’une ontologie conceptuelle (canonique ou non-canonique). La deuxième approche traduit le mécanisme de déploiement des données ontologiques après la conception d’une telle base. Dans ce chapitre, nous com-mençons par la proposition d’un outil d’aide à la conception des bases de données à base de modèles à partir d’une ontologie conceptuelle. Ensuite, nous présentons la validation de notre approche dans un environnement deBDBOsous OntoDB. Celle-ci nécessite l’extension du lan-gage OntoQL étant donné qu’il n’offre pas les constructeurs nécessaires pour la création (1) des dépendances fonctionnelles entre les propriétés ontologiques, (2) des dépendances définies sur les classes ontologiques et (3) la génération du modèle logique de données en troisième forme normale. Notons que dans cette validation, nous traitons uniquement les ontologies concep-tuelles canoniques. Enfin, nous présentons les développements que nous avons menés autour ce processus de validation.

2 OBDBDesignTool : un outil d’aide à la conception des BD à partir d’une ontologie conceptuelle

Dans cette section, nous présentons dans un premier temps une description de l’outil propo-sée suivie de la description de son interface graphique.