Etapes suivies

La mise en œuvre de notre approche sous OntoDB nécessite l’enchaînement d’un ensemble d’étapes : (1) extension du méta-schéma par les dépendances fonctionnelles entre les propriétés des données, (2) persistance de l’ontologie canonique enrichie par les dépendances fonction-nelles entre les propriétés des données, (3) génération du schéma logique de données et (4) création de la structure des tables.

1. Extension du méta-schéma. Notre approche repose sur le processus de normalisation basé sur les dépendances fonctionnelles définies sur les propriétés des données. Par consé-quent, le support desPFDpar le noyau initial d’OntoDB s’avère nécessaire. Étant donné qu’OntoDB ne supporte pas la persistance des PFD, nous proposons, durant cette étape l’extension de son méta-modèle par les PFDdans le but de les rendre persistantes dans la base de données en question. Rappelons que le méta-schéma d’OntoDB contient deux principale tablesEntityetAttribute stockant respectivement les entités et les attributs du méta-modèle décrivant la structure de l’ontologie. Pour mener notre validation, nous dé-veloppons, dans un premier temps, un méta-schéma décrivant la structure initiale du mo-dèle d’ontologies enrichie par les dépendances fonctionnelles entre les propriétés ontolo-giques. Trois nouvelles entités ont été ajoutées:PFD,PFD.Le f tPartetPFD.RightPart.

CREATE ENTITY #PFD.LeftPart (#its.LP.Prop REF (#property)ARRAY) CREATE ENTITY #PFD.RightPart (#its.RP.Prop REF (#property)) CREATE ENTITY #PFD (#Its_Class REF (#Class), #its.PFD.RP REF (#PFD.RightPart), #its.PFD.LP REF (#PFD.LeftPart))

Elles correspondent respectivement aux méta-classes PFD, PFD.PartieGaucheet PFD.

PartieDroitedu méta-modèle générique. Pour chaque entité ajoutée, un ensemble d’attri-buts est défini. Trois attrid’attri-buts sont associés à l’entitéPFD. Le premier attributIts_Class correspond à la propriété sa_Classe. Les attributs its.PFD.RP et its.PFD.LP corres-pondent respectivement aux propriétés sa.PFD.PD et sa.PFD.PG. En ce qui concerne l’entité PFD.RightPart, un attribut nommé its.RP.Propest défini. Ce dernier référence une propriété tandis que l’attributits.LP.Propassocié à l’entitéPFD.Le f tPartréférence une liste de propriétés. La Figure 4.16 illustre un fragment du modèle UML décrivant le méta-schéma étendu. Dans un deuxième temps, nous instancions les deux tables Entity et Attribute par l’ajout des nouveaux attributs et entités (PFD.RightPart, PFD.LeftPart, its.LP.Prop, etc.) assurant le support des dépendances fonctionnelles entre les propriétés par la base de données. La Figure 4.17 traduit l’instantiation de ces deux tables. Cette première étape est assuré par l’exécution de l’ensemble de requêtes OntoQL [Jean et al., 2006a] précédentes codant l’instanciation du méta-schéma avec les dépendances fonc-tionnelles entre les propriétés ontologiques. Plus précisément, elles enrichissent le méta-modèle avec les concepts du méta-modèle UML, assurant la persistance des PFD, tel que décrit dans la figure 4.16.

5. Mise en œuvre dans les bases de données à base ontologique

Figure4.17 – Extension du méta-schéma d’OntoDB avec les dépendances fonctionnelles entre les propriétés ontologiques.

2. Persistance de l’ontologie canonique.Après l’extension du méta-schéma sous OntoDB, tous les ingrédients pour persister une ontologie enrichie par les PFDsont disponibles.

Pour illustrer cette étape, nous adoptons un fragment de l’ontologie LUBM tel que dé-fini dans la figure 4.11. Ces concepts ontologiques sont stockés dans la partie ontologie de l’architecture OntoDB. Par exemple, les requêtes OntoQL ci-dessous permettent de persister la classe Universitydécrivant le concept d’université. Cette classe est définie comme étant le domaine des propriétésIdUniv,Name,Region,CityetCountrydécrivant respectivement l’identifiant, le nom, la région et la ville de l’université.

CREATE #Class University(DESCRIPTOR (#name[en] = ’University’) PROPERTIES(IdUniv INT, Name STRING, City STRING,

Region STRING, Country STRING))

Une fois les classes canoniques créées, les dépendances fonctionnelles élémentaires entre les propriétés sont associées à chacune d’entre elles. Reprenons l’exemple de la classe University et supposons l’existence d’une dépendance fontionnelle définie sur les pro-priétés IdUniv et Name tel que suit: PFD : IdUniv → Name. A travers les requêtes OntoQL ci-dessous, cette dépendance est attachée à la classeUniversity:

Insert Into #PFD (#Its_Class, #its.PFD.RP, #its.PFD.LP) Values(

(Select #oid From #Class c Where c.#name = ’University’), (Select #its.RP.Prop.#oid From #PFD.RightPart Where

#its.RP.Prop.#name = ’Name’), [Select #oid From #Property p Where p.#name = ’IdUniv’])

La figure 4.18 traduit l’instanciation de l’exemple décrit ci-dessus.

3. Génération du schéma logique de données.La génération du schéma logique de don-nées nécessite l’application de l’algorithme de synthèse appliqué aux ontologies (voir algorithm 2). La première étape de cet algorithme consiste en l’identification de l’en-semble des dépendances fonctionnelles élémentaires définies sur les propriétés des don-nées (DEFCC_i) pour chaque classe canonique. Cette extraction est assurée par l’exécution d’un ensemble de requêtes OntoQL. Par exemple, si nous souhaitons l’extraction des PFDassociées à la classeUniversity, les requêtes OntoQL ci-dessous sont appliquées:

SELECT #PFD.#its.PFD.RP.#its.RP.Prop.#oid,

#PFD.#its.RP.Prop.#its.LP.Prop FROM #PFD WHERE #PFD.#Its_Class.#name=’University’;

Une foisDEFCC_i extrait (dans notre casDEFUniversity), nous procédons à la normalisation deCCi à travers l’exécution d’un programme java codant les différentes étapes restantes de l’algorithme 2. Cet algorithme permet de générer le schéma logique de données de l’ontologie canonique étudiée en troisième forme normale. Reprenons l’exemple de la classeUniversityoùPFD^U={PF₁, PF₂, PF₃, PF₄, PF₅, PF₅, PF₆, PF₇ }tel que:

– PF₁={(U;{IdUniv})→Name}, – PF2={(U;{IdUniv})→city}, – PF3={(U;{IdUniv})→region}, – PF₄={(U;{IdUniv})→country}, – PF₅={(U;{city})→region}, – PF₆={(U;{region})→country}, – PF₇={(U;{URI})→Univacronym}.

En appliquant l’algorithme 2, quatre relations normalisées sont générées : University1(IdUniv,URI,Name,city), University2(city,region), University₃(region,country), University₄(URI,Univacronym).

Par exemple, la propriétéIdUnivdéfinit la clé primaire de la relation University1 tandis que les propriétés URI et city représentent des clés étrangères internes référençant res-pectivement les clés primaires des relationsUniversity₃etUniversity₄. Afin de préserver la transparence des données, une vue relationnelle portant le nom de la classe est définie sur ces relations : University(IdUniv,URI, Name,city,region,country,Univacronym). La figure 4.19 traduit le schéma logique de données associé à la classeUniversity.

4. Création de la structure des tables. Après avoir généré le modèle logique de don-nées de l’ontologie canonique, nous créons, dans la partie données sous OntoDB, les tables normalisées ainsi que les vue relationelles définies sur ces tables. En considérant l’exemple de la classe University, quatre tables normalisées (University₁, University₂, University3, etUniversity4) ainsi qu’une vue relationnelleUniversitysont créées. La fi-gure 4.20 illustre la création de la structure de données pour la classe Universitysous OntoDB. Les requêtes OntoQL ci-dessus permet la création de telles structures.

5. Mise en œuvre dans les bases de données à base ontologique

Figure4.18 – Exemple de persistance des concepts ontologiques sous OntoDB.

Figure 4.19 – Exemple de génération du schéma logique de données en troisième forme nor-male.

CREATE FDEXTENT OFUniversity(IdUniv,name,city,region,country,Univacronym).

Figure4.20 – Exemple de structure de données normalisée sous OntoDB.