Validation : expérimentation et prototypage

de ses constructeurs ontologiques en constructeurs relationnels. Nous appliquons les algorithmes proposés dans le chapitre précédent permettant de traduire une ontologie selon les trois princi-pales approches citées : verticale, binaire et horizontale (cf. section 1.3.4.3).

2.3.4.5 La modélisation physique

Une fois l’ED défini (son modèle et ses données), nous proposons d’utiliser une structure de BDBO pour représenter un ED sémantique. Le modèle de l’ED a été défini indépendamment de toute contrainte d’implémentation, l’ED peut donc être déployé selon les trois architectures de BDBO mentionnées (type I, type II, ou type III). Toutes ces architectures permettent de représenter les données de l’ED, et également l’ontologie explicitant la sémantique de ces données. Les modèles définis (modèle ontologique OED et le modèle logique relationnel) seront donc stockés dans l’entrepôt final. Nous rappelons que le méta-modèle de l’ontologie a été étendu par le modèle des besoins, qui sera donc également stocké dans l’ED pour permettre la persistance des besoins. Le choix du modèle de stockage s’applique aussi bien pour le modèle d’ontologie que pour les instances ontologiques (pour peu que le SGBD supporte les modèles de stockage choisis par le concepteur).

D’un point de vue implémentation, nous proposons une solution de déploiement multiple ba-sée sur l’architecture Modèle-Vue-Contrôleur (MVC) [113]. L’algorithme ETL est défini au niveau de la couche contrôleur. Chaque opérateur ETL est implémenté par un objet DAO (Data Access Object). Cette solution permet d’encapsuler tous les accès aux données dans une couche appelée DAO. L’accès aux données se fait via l’interface java DAO. Cette interface reste constante même si la source de données à implémenter change. L’objet DAO joue le rôle d’un adaptateur entre le composant métier et les sources de données à implémenter. Cette solution a été implémentée dans l’outil supportant notre méthode de conception, qui sera présenté à la section suivante.

2.4 Validation : expérimentation et prototypage

Nous présentons dans cette section une instanciation du Framework d’intégration proposé pour des sources BDBO réelles implémentées en utilisant le SGBD sémantique d’Oracle. Nous appliquons ensuite les cinq étapes de conception énoncées dans la méthode proposée pour définir un système d’ED à partir de ces BDBO. Nous présentons comme deuxième étape de validation l’outil implémenté pour supporter la méthode proposée.

2.4.1 Instanciation du Framework pour des sources BDBO

La deuxième contribution de la proposition présentée dans ce chapitre est de fournir une méthode de conception complète pour l’intégration des BDBO dans un système d’ED. Nous montrons dans cette section que la méthode définie ci-dessus peut être appliquée à des BDBO par instanciation du Framework <G,S,M> comme suit : <Schéma du banc d’essai LUBM, BDBO Oracle, Mappings à définir>. Le schéma du banc d’essai LUBM est présenté dans la figure 2.8. Nous considérons un ensemble de BDBO Oracle référençant l’ontologie LUBM. Les besoins des utilisateurs sont illustrés dans le graphe de buts de la figure 2.9.

2.4.1.2 Scénario d’expérimentation

Nous considérons l’exemple d’un scénario où un organisme de tutelle impose à différentes universités l’utilisation d’un même vocabulaire. Chaque université procède à la création de sa BDBO Oracle. Le scénario utilisé considère la création de six BDBO Oracle peuplées localement comme illustré dans la figure 2.12. Chaque source extrait un fragment (ou une vue) de l’ontologie LUBM selon des assertions de mappings, puis procède à son peuplement localement, en utilisant les instances du banc d’essai LUBM.

Périodiquement, l’organisme de tutelle doit réaliser des études et effectuer des analyses dans un processus de prise de décision. Les BDBO doivent donc être intégrées dans un ED. Le schéma de l’ED est défini après l’analyse et la spécification des besoins des décideurs et utilisateurs (sous forme de buts). Ces derniers seront sauvegardés au niveau de l’ED.

Afin d’effectuer nos expérimentations et pour mener à bien notre processus de déploiement, nous avons fait varier le nombre d’instances des classes ontologiques. Nous avons pour ce faire utilisé l’outil de génération automatique de données (UBA) fourni par le banc d’essai LUBM. Ces données sont répétables et personnalisables, ce qui nous permet de préciser la génération de nombres aléatoires des données. Les données générées respectent les contraintes de l’ontologie (par exemple, la hiérarchie des classes et les relations entre les instances générées).

L’outil UBA commence par la création des instances de la principale classe Université de l’on-tologie. Chaque université se compose de 15 à 25 départements. Dans chaque département (De-partment), nous trouvons différentes catégories de professeurs (Professor), d’étudiants (Student) dont les étudiants en graduation (GraduateStudents), de cours (Course), pour ne citer que les principales classes. Nous avons généré six ensembles d’ontologies avec respectivement 1, 3, 6, 9, 12 et 15 universités. Le nombre d’instances dans chaque ensemble ontologique est présenté dans le tableau 2.1.

2.4.1.3 Instanciation du Framework d’intégration

Nous commençons par instancier le Framework d’intégration <G,S,M> proposé, par des BDBO Oracle, créées en référençant le schéma global LUBM selon une approche LaV (le schéma de la source est défini en fonction du schéma global), par différents types de mappings. La création des BDBO sources se fait selon plusieurs scénarios, où chaque BDBO peut être un

2.4. Validation : expérimentation et prototypage

Classes ontologiques Instances ontologiques

1 université 70193 3 universités 210579 6 universités 421158 9 universités 631737 12 universités 842316 15 universités 1052895

Table 2.1 – Génération des instances ontologiques du banc d’essai LUBM

simple fragment du schéma global de l’ontologie LUBM, ou une vue sur le schéma global de l’ontologie LUBM.

Le schéma global est formalisé par son modèle conceptuel ontologique (MO) comme suit : MO_Oracle : <Classes C, Properties P (Datatype Property et Object Property), Applic(C) et Sub(C) définies par des requêtes Sparql, Ref(C) :(Opérateur, Expression), Ref’(R) :(Opérateur, Expression), OWLPrime>.

Ref (resp.Ref’) est la fonction qui associe à chaque classe (resp. rôle) une expression définie en utilisant les opérateurs d’équivalence et/ou d’inclusion d’OWLPrime (rdfs :subClassOf, owl : equivalentClass, rdfs :subPropertyOf, owl :equivalentProperty). Expression est une expression sur les classes et propriétés de l’ontologie partagée utilisant les constructeurs d’OWLPrime.

Chaque source locale Si est instanciée comme suit : Si : < MO_Oracle, Individuals (tri-plets), Pop représentée par les tables RDF_link et RDF_values, Vertical, Vertical, type I>. Le modèle de stockage vertical est le schéma relationnel composé d’une table de triplets (sujet, pré-dicat, object). Par exemple : (Student, type, Class) pour le stockage du schéma, et (Student#1, type, Student), (Student#1, takeCourse, Course#1) pour le stockage des instances.

Les mappings entre le schéma global et les schémas locaux sont donc définis comme suit : Mapping M :< MO_Oracle de chaque source, MO_Oracle du schéma global, expression sur G (fragment ou vue), Classe de la source S, interprétation intentionnelle, (Equivalent, Containment ou Overlap (owl :SubClassOf et owl :equivalentClass d’OWLPrime)), LaV>.

Les six BDBO sont créées comme suit : deux BDBO sont créées comme des fragments hori-zontaux, la troisième BDBO est créée comme un fragment vertical sur l’ontologie globale et deux autres BDBO sont créées comme des fragments mixtes. Une classe de l’ontologie locale de la source référence dans ce cas une seule classe de l’ontologie globale. La dernière BDBO est créée comme une vue sur l’ontologie globale où un concept de l’ontologie globale correspond à une expression (utilisant les constructeurs d’OWLPrime) sur les classes et propriétés de l’ontologie globale. Notons que la vérification de la consistance de l’ontologie locale résultante est laissée au soin du concepteur. Nous donnons les définitions suivantes de fragments et de vues ontologiques.

Définition 3 Un fragment vertical sur l’ontologie globale G est défini comme une projection sur les classes de l’ontologie. Chaque classe hérite de tous ses rôles. La figure 2.13 illustre une frag-mentation verticale ontologique.

l’on-Figure2.12 – Scénario de validation de l’approche proposée avec des BDBO Oracle

tologie globale O :<C : ensemble de classes, R : ensemble de rôles, Applic(C), Sub(C), Ref(C), Ref’(R), Formalisme>, est formellement définie comme suit : Π_{(Ci,Cj,...,Cm)} (C).

Le premier type de BDBO est obtenu par une projection sur les classes Person, Student, GraduateStudent, Publication de l’ontologie LUBM :

Π_{(P erson,Student,GraduateStudent,P ublication)} (C)

Définition 4 Un fragment horizontal sur l’ontologie globale G est défini comme une restriction sur un ensemble de rôles pour chaque classe de l’ontologie. La figure 2.13 illustre une fragmenta-tion horizontale ontologique. Une fragmentafragmenta-tion horizontale sur une ontologie est formellement définie comme suit : σ_{rest(ri),rest(rj ),...,rest(rm)} (C) où rest(ri)représente une restriction sur les rôles ri de la classe C.

Par exemple pour le deuxième type BDBO, des restrictions sont définies sur les propriétés (Age et EmailAdress) de la classe Person de l’ontologie LUBM :

σAge,EmailAdress (Person)

Définition 5 Un fragment mixte sur une ontologie est défini comme un processus d’application simultanée d’une fragmentation horizontale et verticale sur l’ontologie globale G.

Par exemple, le troisième type BDBO est un fragment mixte de l’ontologie LUBM, défini par une fragmentation verticale obtenant les classes : Person, Student, GraduateStudent et Publication. Une restriction est définie sur deux propriétés de la classe Person : Age et EmailAdress.

2.4. Validation : expérimentation et prototypage

Figure 2.13 – Fragmentation verticale et horizontale de l’ontologie globale

Définition 6 Une vue sur une ontologie est définie par des expressions utilisant les constructeurs de la logique de description OWLPrime. Formellement, une ontologie locale construite par des mappings complexes est définie par : OL : <C’, R’, Applic’(C’), Sub’(C’), Ref’(C’), Ref’(R’), Refext(C’), Formalisme>, où Refext(C’) représente les références externes entre l’ontologie locale de la source et l’ontologie globale.

Par exemple, pour le quatrième type de BDBO les trois classes : Person, Student et Publication sont définies comme des vues sur l’ontologie LUBM, comme suit :

S4 : Refext(Person) = (Student ∪ Employee) ∩ ∀ member (Person, Organization). S₄ : Refext(Student) = Student ∩ ∀takesCourse (Person, Course)

S₄ : Ref_ext(Publication) = Publication ∩ ∀PublicationAuthor (Publication,GraduateStudent)

Une fois que le schéma ontologique de chaque source est défini selon ces types de mappings, nous implémentons les BDBO Oracle sources correspondantes à ces schémas. Nous avons utilisé la version d’Oracle 11g version 2. Oracle 11g permet le chargement des données sous forme d’un fichier N-Triple (.nt) selon une représentation verticale. Pour ce faire, nous avons utilisé l’API Jena qui fournit un convertisseur appelé rdfcat. Il permet la transformation des fichiers OWL au format N-Triple. Le nombre d’instances obtenu pour chaque ensemble ontologique est représenté dans le tableau 2.2 complétant le tableau 2.1 par la colonne Instances N-triples. Pour chaque cas (ligne) du tableau, ces instances N-triples sont chargées dans les six BDBO en utilisant l’utilitaire Oracle SQL Loader. Pour nos expérimentations, nous testons dans ce qui suit notre méthode pour chacun des cas du tableau.

2.4.2 Application de la méthode de conception sur le Framework défini

Nous déroulons la méthode proposée (les cinq étapes) en prenant comme entrées les éléments du Framework instancié par les BDBO.

Figure 2.14 – Le modèle multidimensionnel obtenu

2.4.2.1 Définition des besoins et du modèle conceptuel

Les besoins considérés dans cette étude sont les buts représentés dans la figure 2.9. Ces besoins sont projetés sur l’ontologie globale de LUBM afin de définir l’ontologie OED. Dans notre scénario, l’ensemble des besoins spécifiés permettent de définir l’ontologie OED comme module de l’ontologie globale (scénario 2 : OED ⊂ G). Cette ontologie est annotée par les concepts multidimensionnels selon l’algorithme 1 d’annotation. L’algorithme a permis d’identifier trois classes Fait : Publication, Student et Employee. Les classes dimensions sont Institute, University, Program et Research. La figure 2.14 présente le modèle multidimensionnel obtenu sous forme d’un diagramme de classes.

2.4.2.2 Le processus ETL

Dans cette étape, nous déroulons l’algorithme ETL au niveau ontologique sur l’ontologie OED afin d’alimenter son schéma par les instances des sources. Pour ce faire, il suffit de traduire les opérateurs ETL par des requêtes Sparql, ensuite de de dérouler l’algorithme 4 sur l’OED.

2.4. Validation : expérimentation et prototypage

2.4.2.3 Définition de l’ED sémantique final

Cette dernière section présente les phases de modélisation logique et physique. Oracle permet de stocker les ontologies en utilisant une représentation verticale où tous les triplets sont stockés dans la même table. Les données sémantiques sont stockées dans le schéma MDSYS. La BDBO d’Oracle suit une architecture de type I où il n’y a pas de séparation entre les différents schémas (ontologiques et de données).

Nous avons procédé à la création de l’ED sémantique en créant une nouvelle BDBO Oracle, dont le schéma logique correspond à la traduction du schéma de l’OED dans une représentation verticale. Cette ontologie est stockée dans un fichier N-triple (défini selon une représentation verticale). L’éditeur d’ontologies Protégé fournit un moyen pour sauvegarder une ontologie OWL sous ce format N-triple. Nous avons ensuite utilisé l’utilitaire SQL*Loader pour le chargement du fichier N-triple dans la nouvelle BDBO. SQL*Loader est un utilitaire d’Oracle qui permet le chargement de données à partir d’un fichier plat (fichier N-triple) vers une table de la base de données Oracle. Comme la démarche le préconise, nous étendons le métaschéma ontologique d’Oracle par le modèle des besoins défini, comme présenté dans le chapitre précédent.

Nous avons ensuite procédé à une série d’expérimentation pour tester notre méthode. Les expérimentations du déroulement du processus ETL sur ce scénario nous ont permis d’étudier trois aspects relatifs [22] : à la complexité de l’algorithme proposé, à la scalabilité de l’approche, et à l’étude des performances du processus ETL. Nous rappelons que très peu de travaux ETL dans la littérature proposent des expérimentations validant le processus ETL, et se contentent de dérouler leurs propositions sur un exemple proposé. Certains travaux proposent des outils supportant le processus ETL proposé. Il n’y a donc aucun consensus établi concernant les critères d’évaluation d’un processus ETL.

Nos expérimentations ont été réalisées sur un ordinateur portable (HP) Intel (R) CoreT M i5-3320M CPU 2,60 GHz, avec un disque dur de 500 Go et une RAM de 4 Go. Nous avons utilisé le système d’exploitation Windows XP Professional et le SDK Java 1.7. Nous commençons par examiner l’espace de calcul nécessaire pour peupler chaque classe de l’ontologie de l’ED. La figure 2.15 présente le nombre d’itérations de l’algorithme ETL proposé, nécessaires pour converger, par rapport au nombre de classes de l’ontologie OED. L’algorithme est basé sur des mappings définis au niveau intentionnel (concepts) et pas au niveau extensionnel (instances). Les résultats montrent que l’espace de calcul reste stable relativement au nombre de classes. Bien que le nombre d’itérations moyen par source soit de 15 ; dans le pire des cas notre algorithme ne calcule pas plus de 125 itérations. Ces résultats vérifient la faisabilité de notre approche.

Nous avons ensuite examiné la scalabilité et les performances du processus ETL sur l’ED. La figure 2.16 illustre les résultats de l’intégration pour les six BDBO. Pour ces sources, nous calculons le temps nécessaire pour l’intégration des instances des sources au niveau du schéma de l’ED. Nous faisons le test en faisant évoluer le nombre d’instances à chaque test (tableau 2.2). La courbe du temps montre que l’exécution de l’algorithme se fait de manière linéaire par rapport au nombre d’instances utilisées, ce qui signifie que la méthode proposée est évolutive. D’autre part, le temps nécessaire pour intégrer les six BDBO créées en utilisant notre méthode n’excède pas 4 minutes, ce qui indique les performances acceptables de l’algorithme proposé. Nous présentons dans ce qui suit l’outil développé pour supporter la méthode de conception proposée.