Onto

Conception physique des bases de donn
ees `
a base
ontologique : le cas des vues mat
erialis
ees
Bery Leouro Mbaiossoum
To cite this version:

Bery Leouro Mbaiossoum. Conception physique des bases de donnees a` base ontologique : le cas
des vues materialisees. Autre [cs.OH]. ISAE-ENSMA Ecole Nationale Superieure de Mecanique
et dAerotechique - Poitiers, 2014. Francais. <NNT : 2014ESMA0014>. <tel-01129077>
HAL Id: tel-01129077

https://tel.archives-ouvertes.fr/tel-01129077
Submitted on 10 Mar 2015
HAL is a multi-disciplinary open access

archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
Larchive ouverte pluridisciplinaire HAL, est

destinee au depot et `a la diffusion de documents
scientifiques de niveau recherche, publies ou non,
emanant des etablissements denseignement et de
recherche francais ou etrangers, des laboratoires
publics ou prives.
Ecole Nationale Suprieure de Mcanique et dArotechnique

Laboratoire dInformatique et dAutomatique pour les Systmes
THESE
pour lobtention du Grade de
DOCTEUR DE L'COLE NATIONALE SUPRIEURE

DE MCANIQUE ET D'AEROTECHNIQUE
(Diplme National Arrt du 7 aot 2006)
Ecole Doctorale : Sciences et Ingnierie pour lInformation, Mathmatiques

Secteur de Recherche : INFORMATIQUE & APPLICATIONS
Prsente par :
MBAIOSSOUM BERY LEOURO
*********************************************
Conception physique des bases de donnes base ontologique : le
cas des vues matrialises
*********************************************
Directeur de thse : Ladjel BELLATRECHE
Co-encadrant : Stphane JEAN
*********************************************
Soutenue le 12 dcembre 2014
devant la Commission dExamen
*********************************************
JURY
Rapporteurs : Zohra BELLAHSENE
Nadine CULLOT
Examinateurs : Olivier TESTE
Patrick MARCEL
Professeur, Universit Montpellier II

Professeur, Universit de Bourgogne
Professeur, Universit de Toulouse 2 Jean Jaurs
Matre de Confrences/HDR, Universit de Tours
Ladjel BELLATRECHE Professeur, ISAE-ENSMA, Poitiers

Stphane JEAN
Matre de Confrences, Universit de Poitiers
Ecole Nationale Suprieure de Mcanique et dArotechnique

Laboratoire dInformatique et dAutomatique pour les Systmes
THESE
pour lobtention du Grade de
DOCTEUR DE L'COLE NATIONALE SUPRIEURE

DE MCANIQUE ET D'AEROTECHNIQUE
(Diplme National Arrt du 7 aot 2006)
Ecole Doctorale : Sciences et Ingnierie pour lInformation, Mathmatiques

Secteur de Recherche : INFORMATIQUE & APPLICATIONS
Prsente par :
*********************************************
Conception physique des bases de donnes base ontologique : le
cas des vues matrialises
*********************************************
Directeurs de Thse : Ladjel BELLATRECHE & Stphane JEAN
*********************************************
Soutenue le 12 dcembre 2014
devant la Commission dExamen
*********************************************
JURY
Rapporteurs : Zohra BELLAHSENE
Nadine CULLOT
Examinateurs : Olivier TESTE
Patrick MARCEL
Professeur, Universit Montpellier II

Professeur, Universit de Bourgogne
Professeur, Universit de Toulouse 2 Jean Jaurs
Matre de Confrences/HDR, Universit de Tours
Ladjel BELLATRECHE Professeur, ISAE-ENSMA, Poitiers

Stphane JEAN
Matre de Confrences, Universit de Poitiers
Remerciements
Au terme de cette recherche heuristique, je tiens rendre grce Dieu tout Puissant de
ce qui a permis ce que jatteigne ce trs haut niveau dtudes. Je tiens exprimer toute ma
profonde gratitude tous ceux dont sans la participation active, cette recherche naurait pas vu
le jour. Il sagit de :
Pr Ladjel BELLATRECHE, mon Directeur de thse, pour sa disponibilit sans faille
dans ses brillants conseils, orientations et changes tout au long de cette thse.
Dr Stphane JEAN, mon co-directeur, qui ma marqu de sa disponibilit, sa confiance,
son encadrement, sa promptitude rpondre mes sollicitations durant tout le processus
de la ralisation de ce travail. MM. BELLATRECHE et JEAN ont t trs actifs dans la
recherche de financement de cette thse.
Dr ASLAOU Kobmbaye, pour avoir bien accept de maccompagner dans mes activits
dans mon pays le Tchad. Son soutien et ses conseils mont beaucoup servi.
LAgence Universitaire de la Francophonie dont la contribution se traduit par le financement de cette thse,
Pr Emmanuel GROLLEAU, Directeur du LIAS, pour mavoir accueilli dans son laboratoire.
Pr Zohra BELLAHSENE et Nadine CULLOT pour avoir accept la lourde tche dtre
rapporteurs de cette thse.
Pr Olivier TESTE et Dr Patrick MARCEL pour avoir accept de juger de la scientificit
de cette recherche.
Dr Mickael BARON et Zo FAGET pour leurs contributions si efficaces dans les commentaires techniques lors des lectures de mes travaux.
tous les membre du LIAS et tous les doctorants prsents pendant ces annes de ma
thse (notamment S. Khouri, B. Ahcene, K. Georges, B. Selma, S. Cheikh, L. Thomas, F.
Geraud, B. Moustapha, B. Ilyes, B. Paule, B. Soumia, C. ChedLia, T. Valry, B. Akli) pour
leurs amitis et leurs collaborations sincres.
Hondjack Dehainsala pour mavoir encourag venir faire mes tudes Poitiers.
NETOUA Sylvie, mon pouse, pour la patience dont elle a fait montre tout au long de cette
recherche.
Majorelle, Cyriac et Fortune mes enfants qui, en dpit de mon loignement de la maison
nuptiale nont cess dexprimer leur amour mon gard.
BERI Elazar, mon pre et BOUMBAYE Rod, ma mre pour mavoir montr le chemin
de lcole et leurs soutiens indfectibles.
tous les parents notamment NEASKEM Jared, Namadji Leouro, Lalem Rachel, BEMBA
Namadji Leouro, BENDIMAN Namadji, DJEMBER Philemon, NADWAI Philippe, DJOL
DOG Urbain, MBAIBE Achime, MBAIBE Adolphe, MBAITELSEM Bery et DJEKOUNLA
Malachie pour leur marques de soutien multiforme.
NEKOULNANG Clarice, MONGLENGAR Serges, SADJINAN Mathieu, ALATAN, RAi
HAMAT NOUBARANGAR, compatriotes doctorants avec qui, nous avons pass de bons
et difficiles moments.
toute la communaut tchadienne de Poitiers pour sa sympathie mon endroit.
tous les amis de Poitiers notamment KABORE Samuel, RICHARD Marie-Christine, Stphanie GIRAUD, Quentin pour leur esprit damiti.
Je remercie enfin toutes les personnes qui se reconnatront par les divers soutiens dont jai
fait lobjet.
ii
A
Majorelle, Cyriac et Fortune, mes enfants
iii
Table des matires
Introduction gnrale
Contexte et problmatique . . . . . . . . . . . . . . . . . . . . . . . . . .
Motivations et Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Structure du mmoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Partie I Concepts fondamentaux
Chapitre 1 Ontologie et Bases de Donnes Base Ontologique
11
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
Quest-ce quune ontologie? . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.1
Origine de la notion dontologie . . . . . . . . . . . . . . . . . . .
12
2.2
Notion dontologie en informatique . . . . . . . . . . . . . . . . .
13
2.3
Dfinition dune ontologie . . . . . . . . . . . . . . . . . . . . . .
13
2.4
Types dontologies . . . . . . . . . . . . . . . . . . . . . . . . . .
14
Table des matires

2.5
Taxonomie des ontologies de domaine . . . . . . . . . . . . . . .
15
Comment dfinir formellement une ontologie? . . . . . . . . . . . . . . .
19
3.1
Formalisme RDF/RDFS . . . . . . . . . . . . . . . . . . . . . . .
19
3.2
Formalisme OWL . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.3
Formalisme PLIB . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.4
Synthse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
Ontologies vs. Modles Conceptuels . . . . . . . . . . . . . . . . . . . . .
30
Base de Donnes Base Ontologique . . . . . . . . . . . . . . . . . . . .
31
5.1
Modle de stockage traditionnel ou autres modles pour les BDBO? 32
5.2
Architecture traditionnelle ou dautres architectures pour le SGBD

cible des BDBO? . . . . . . . . . . . . . . . . . . . . . . . . . .
Langage de requtes des BDBO
39
. . . . . . . . . . . . . . . . . . . . . .
44
6.1
Principaux langages proposs . . . . . . . . . . . . . . . . . . . .
45
6.2
Prsentation du langage SPARQL . . . . . . . . . . . . . . . . . .
46
6.3
Prsentation du langage OntoQL . . . . . . . . . . . . . . . . . .
48
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
Chapitre 2 Conception Physique de Bases de Donnes
53
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
Conception physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
Quelques exemples de structures doptimisation . . . . . . . . . . . . . . .
58
3.1
Les index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
3.2
Les vues matrialises . . . . . . . . . . . . . . . . . . . . . . . .
59
3.3
La Fragmentation horizontale . . . . . . . . . . . . . . . . . . . .
62
Synthse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
4.1
Choix structures doptimisation . . . . . . . . . . . . . . . . . . .
65
4.2
Choix de la mthode de slection . . . . . . . . . . . . . . . . . .
65
4.3
Choix dalgorithme de slection . . . . . . . . . . . . . . . . . . .
66
vi
4.4
Mise en uvre des solutions doptimisation . . . . . . . . . . . . .
66
Vers une conception physique des BDBO . . . . . . . . . . . . . . . . . .
66
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
Partie II Contributions
Chapitre 3 Etude Empirique des Bases de Donnes Base Ontologique
73
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
Les composantes dune BDBO . . . . . . . . . . . . . . . . . . . . . . .
74
2.1
Logiques de Description . . . . . . . . . . . . . . . . . . . . . . .
74
2.2
Formalisation dune ontologie . . . . . . . . . . . . . . . . . . . .
76
2.3
Modle unifi des BDBO . . . . . . . . . . . . . . . . . . . . . .
77
Etude des BDBO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
3.1
Prsentation des BDBO . . . . . . . . . . . . . . . . . . . . . . .
78
3.2
Critres de comparaison des BDBO . . . . . . . . . . . . . . . . .
85
Etude de performances des BDBO . . . . . . . . . . . . . . . . . . . . .
88
4.1
Ensembles de donnes et environnement de tests . . . . . . . . . .
88
4.2
Performances en termes de chargement des donnes (ontologie et
instances) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
Performances en termes de temps de rponse de requtes . . . . . .
95
Paramtres influant identifis partir de cette tude . . . . . . . . . . . . .
98
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
4.3
vii
Table des matires

Chapitre 4 Modles de Cot pour les Bases de Donnes base Ontologiques
101
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Revue des modles de cot dans le contexte des BDBO . . . . . . . . . . 103
Les paramtres de notre modle de cot . . . . . . . . . . . . . . . . . . . 104

3.1
Paramtres de la fonction du cot . . . . . . . . . . . . . . . . . . 105
3.2
Template de requtes . . . . . . . . . . . . . . . . . . . . . . . . . 106
3.3
Estimation des facteurs de slectivit . . . . . . . . . . . . . . . . 107
3.4
Cot dune slection et dune projection . . . . . . . . . . . . . . . 110
3.5
Cot de la jointure . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Validation du modle de cot . . . . . . . . . . . . . . . . . . . . . . . . . 112
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Chapitre 5 La Slection des Vues Matrialises dans les BDBO: un Mode dEm-
ploi
119
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Prliminaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
2.1
Reprsentation algbrique dune requte SPARQL . . . . . . . . . 122
2.2
Plan unifi gnrique de requtes . . . . . . . . . . . . . . . . . . 124
Slection des vues matrialises au niveau conceptuel . . . . . . . . . . . . 125

3.1
Identification des vues . . . . . . . . . . . . . . . . . . . . . . . . 126
3.2
Matrices dusage . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Approche impose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Approche simule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

5.1
Identification des vues candidates . . . . . . . . . . . . . . . . . . 133
Exprimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
6.1
Ensembles de donnes pour les tests . . . . . . . . . . . . . . . . . 139
6.2
Diffrents tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
viii
Conclusion gnrale et perspectives
149
Chapitre 6 Conclusion et Perspectives

6.1
6.2
151
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
6.1.1
Etat de lart sur les BDBO . . . . . . . . . . . . . . . . . . . . . . 151
6.1.2
Evaluation de performance de BDBO . . . . . . . . . . . . . . . . 153
6.1.3
Modle de cot pour les BDBO prenant en compte leur diversit . 154
6.1.4
Approches de slection des vues matrialises pour les BDBO . . 154
Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.2.1
Volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.2.2
Varit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
6.2.3
Vlocit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Bibliographie
157
Annexes
171
Annexe A Requtes du benchmarch LUBM utilises
171
Table des figures
173
Liste des tableaux
177
Glossaire
179
ix
Introduction gnrale
Ce chapitre prliminaire prsente le contexte de notre thse savoir la diversit des bases de
donnes dfinies pour stocker la fois les ontologies et les donnes associes. Nous introduisons
ensuite nos contributions qui portent sur la conception physique de telles bases de donnes en
prenant en compte leur diversit.
1 Contexte et problmatique
Lutilisation massive du Web et de lInternet ont fait natre un besoin de partage, dchange
et danalyse des objets et en particulier des donnes. Pour raliser ces tches, connatre le sens
dune donne est devenu un enjeu important pour les entreprises, les gouvernements, les applications, les services, etc. Si nous nous penchons sur la technologie des bases de donnes dans
sa premire gnration, les concepteurs construisaient des bases de donnes pour rpondre
un besoin particulier, mais sans se soucier si ces bases de donnes seraient intgres et utilises par des personnes en dehors de leur entreprise. Lorsque cette dernire souhaite souvrir et
partager ses donnes, elle se heurte au problme dhtrognit structurelle et smantique des
donnes. Afin de rpondre ce problme, les ontologies ont t largement utilises pour expliciter le sens des concepts et des proprits dun domaine donn. Il ny a pas que la technologie
des bases de donnes qui a utilis les ontologies, dautres communauts lont galement fait :
lintelligence artificielle, le traitement de la langue naturelle, etc.
Autour du concept dontologie, plusieurs travaux de recherche se sont concentrs sur : (i)
la construction dontologies de domaine, (ii) la dfinition des formalismes de manipulation des
ontologies, (iii) lexploitation des ontologies et (iv) ltude de son volution. Ainsi, nous faisons
les constats suivants :
1. Plusieurs ontologies de domaine ont t proposes et certaines normalises, souvent dans
les domaines o une grande expertise existe. On peut citer la mdecine (le cas de lontologie Unified Medical Language System (UML)), lingnierie (IEC 61360-4 pour les
composants lectroniques, la norme ISO 23584 dans le domaine de loptique et loptro1
Introduction gnrale
nique), lenvironnement 1 , les agences de voyage [1], les jeux vido 2 , etc. De plus en plus
de besoins de construction dontologie mergent.
2. La conceptualisation dune ontologie ncessite des modles formels pour la dfinir et pour
offrir des mcanismes de raisonnement. Un nombre important de formalismes existent,
que nous pouvons classer en deux types selon lobjectif vis : (a) des formalismes pour
faciliter lchange et le partage de donnes, o les concepts sont dfinis dune manire
unique (le cas de PLIB [2]), (b) des formalismes pour dfinir des correspondances entre
vocabulaires et offrir des possibilits de dduction et dinfrence (le cas dOWL [3]).
3. La maturit des ontologies a motiv plusieurs chercheurs et industriels les utiliser pour
rpondre plusieurs problmatiques, comme lindexation des documents, lintgration
et lchange des donnes, le traitement de la langue naturelle, la conception des bases
de donnes, etc. Lusage dune ontologie apporte de nouveaux questionnements. Prenons
le cas dutilisation des ontologies pour concevoir des bases de donnes. Cette utilisation
gnre un gros volume de donnes qui doit tre stock, interrog, optimis, etc. Des solutions de persistance ont t proposes. Elles ont fait natre un nouveau type de bases
de donnes, appel Base de Donnes Base Ontologique (BDBO) ou bases de donnes
smantiques, qui stockent la fois les instances et lontologie ou les ontologies dcrivant
leur sens. Plusieurs travaux ont t proposs pour offrir des modles de stockage adquats ces donnes et leur ontologie [4, 5, 6, 7, 8, 9]. Certains sont hrits du modle
de stockage traditionnel (table oriented storage), comme la reprsentation horizontale, o
chaque classe de lontologie est stocke dans une table unique, dautres sont originaux
comme les reprsentations binaires et verticales (table de triplets). La prsence dune ontologie au sein dun Systme de Gestion de Base de Donnes (SGBD) a galement contribu lvolution de larchitecture traditionnelle de ce dernier compose habituellement
de la partie contenu et de la partie mta-base. Cette volution vise prendre en compte
la fois lontologie et son modle appel mta-schma. Ce dernier a t propos pour
offrir un accs gnrique au modle dontologie. Il joue, pour lontologie, le mme rle
que celui jou par la mta-base pour les donnes. En ce qui concerne linterrogation des
donnes, plusieurs langages dinterrogation ont t proposs. On peut citer par exemple
RDQL [10], SeRQL [11], RQL [12], Squish [13], SPARQL [14], OntoQL [15], etc. Le
langage SPARQL a t retenu par le consortium W3C (World Wide Web Consortium)
comme le langage standard pour les BDBO. Ce langage ressemble au langage SQL et est
souvent traduit dans ce dernier car la plupart des BDBO utilisent un SGBD Relationnel
comme systme sous-jacent.
4. Comme tout composant informatique, une ontologie volue et ncessite donc une gestion
de ses diffrentes versions. Lvolution dune ontologie est normalement beaucoup plus
problmatique que les volutions dune base de donnes. Ceci est d au caractre partageable de lontologie. Pour illustrer ce problme, citons Rogozan [16] qui sinterroge :
1. https://bioportal.bioontology.org/ontologies/ENVO
2. http://www.mindmeister.com/fr/324669511/game-ontology-project
2. Motivations et Objectifs
"comment prserver laccs et linterprtation des objets au moyen de leur rfrencement
une ontologie volutive" ?
Les constants prcdents nous font remarquer que les ontologies sont devenues une ralit dans
le paysage des bases de donnes et apportent une forte diversit qui a t suivie par les SGBD
industriels. Si nous prenons lexemple de Oracle (Oracle Spatial and Graph) et IBM (SOR),
elles proposent des solutions diffrentes pour grer les instances ontologiques. Cette diffrence
concerne la fois les modles de stockage utiliss et larchitecture de leur SGBD cible. Cette
diversit est au cur des travaux prsents dans ce mmoire. Nous nous intresserons en particulier la conception physique de ce type de bases de donnes qui consiste dfinir des
structures doptimisation prenant en compte cette diversit.
2 Motivations et Objectifs
La conception physique a eu un grand intrt dans le contexte des bases de donnes dcisionnelles, o une large panoplie de structures doptimisation (les vues matrialises, les index
de jointure binaire, la compression, le partitionnement, le traitement parallle, etc.) a t tudie
et supporte par les SGBD commerciaux et acadmiques. Durant la conception physique, une
ou plusieurs structures doptimisation sont slectionnes. Le processus de slection est souvent
guid par un modle de cot mathmatique estimant le cot des requtes (souvent en termes
dentres sorties) en prsence de ces structures doptimisation. La plupart des problmes de slection de structures doptimisation est difficile, car lespace de recherche li chaque structure
peut tre trs large. Prenons le cas des vues matrialises, toute requte ou partie dune requte
peut tre candidate la matrialisation. tant donn que chaque structure doptimisation a des
contraintes comme lespace de stockage et le cot de maintenance pour les vues matrialises,
on ne peut donc pas slectionner toutes les vues candidates. En consquence, nous faisons appel
des algorithmes dexploration de lespace de recherche, comme les algorithmes gntiques, le
recuit simul, les algorithmes glouton, etc. Pour quantifier la qualit de ces derniers, un modle
de cots est utilis. La question que nous nous posons dans nos travaux est comment transporter
cette dmarche traditionnelle sur les BDBO ?
Pour mener bien notre rflexion, nous avons dabord commenc par ltude de la diversit des BDBO en analysant et comparant les approches existantes. Cette tude approfondie de
diffrents types de BDBO nous a permis den proposer une formalisation unifie des BDBO.
Cette formalisation prend en compte les diffrentes composantes engendrant la diversit : les
modles dontologie, les modles de stockage, les architectures, etc. Cette formalisation nous
sert comme cadre pour identifier les variables utiliser dans un processus de slection de structures doptimisation.
La deuxime piste de recherche que nous avons explore est la dfinition dun modle de
cot pour valuer la qualit de chaque type de BDBO en excutant un ensemble de requtes.
Contrairement aux bases de donnes traditionnelles, o nous trouvons un nombre important de
3
Introduction gnrale
modles de cots, peu existent dans le cas des BDBO. Pour en dfinir un, nous avons dabord
suivi une dmarche exprimentale afin dextraire les paramtres pertinents de notre modle
de cots. Nous avons alors considr six exemples de BDBO, trois industriels (Oracle, IBM
SOR et DB2RDF) et trois acadmiques (Jena, Sesame et OntoDB - dveloppe au sein de
notre laboratoire). Ces systmes sont divers, du fait que chacun a ses propres spcificits. Nous
avons effectu une batterie de tests en utilisant le banc dessai LUBM (The Lehigh University
Benchmark) et ses requtes. Par la suite un modle de cot intgrant des paramtres issus de
cette exprimentation a t dvelopp pour valuer toute BDBO. Ce dernier est ensuite utilis
dans une approche que nous proposons pour slectionner les vues matrialises.
3 Contributions
Nos contributions travers ce travail, sont quadruples.
Premirement, nous avons tabli un tat de lart sur les BDBO. Une tude de leurs caractristiques nous a permis de mettre en lumire la grande diversit de BDBO et de leurs usages.
En effet il existe :
diffrents usages dontologies (annotation, explicitation, intgration, change de donnes,
etc.), ce qui implique lexistence dun nombre important de modles dontologies (PLIB,
RDFS, OWL, KIF, etc.);
diffrents modles de stockage (binaire, vertical, horizontal...) qui ont un impact sur la
conception physique ;
diffrents niveaux de modlisation (niveau donnes, niveau mta-donnes, niveau mtaontologie, ...), ce qui conduit des diffrentes architectures.
Deuximement, nous avons propos un modle unifiant les BDBO et un modle de cots
gnrique qui intgrent les diversits remarques.
Troisimement, nous avons effectu une valuation des performances de quelques BDBO
selon deux critres : le temps de chargement des donnes et le temps de traitement de requtes.
Enfin, nous avons exploit la prsence de lontologie au sein de SGBD pour dfinir une
mthodologie de slection des vues matrialises au niveau conceptuel. La prsence de notre
modle de cots nous a galement aid dfinir une autre mthodologie pour slectionner des
vues prenant en compte la diversit des BDBO.
Les approches que nous avons proposes, ont t valids thoriquement en utilisant le modle de cots et rellement sur un ensemble de BDBO comme Oracle, Sesame, Jena, IBM SOR,
DB2RDF et OntoDB.
4
4. Structure du mmoire
Ontologie
Formalismes
Chapitre 3
RDF-Schema, PLIB, OWL
Ontologie
Donnes
Modles de Stockage
Chapitre 4
Charge de
requtes
Triplet, Binaire, Horizontale
liens
Architectures
E
Chapitre 1
Contraintes
Modle Physique
V
A
L
U
E
A
T
I
O
N
M
O
D
E
L
E
Chapitre 5
Slection
des vues
D
E
C
O
{V1, , Vn}
Chapitre 2
S
O
SGBD
Structures doptimisation
Figure 1 Vue globale de la thse
4 Structure du mmoire
Ce mmoire est organis en trois parties et une annexe, comme illustr par la Figure 1.
La premire partie comprend deux chapitres.
Le premier chapitre prsente dans un premier temps un tat des lieux sur les ontologies,
leur modles et introduit une classification des ontologies existantes. Une comparaison entre
les modles conceptuels et les ontologies est galement donne. Dans un deuxime temps, la
notion de BDBO est dfinie avec lensemble de ses composantes : les modles dontologies,
les modles de stockage et les architectures. Des exemples de BDBO existantes sont donns
pour illustrer leur diversit. Cette analyse nous a permis de donner une reprsentation multidimensionnelle des BDBO, impliquant trois dimensions reprsentant: le modle dontologie,
le modle de stockage et larchitecture. Enfin deux langages de requtes smantiques sont dtaills : le langage SPARQL et OntoQL qui a t dvelopp au sein de notre laboratoire. Dans
un souci de clarification et danalyse, nous avons compar les BDBO pour chaque niveau de
diversit.
Le second chapitre dcrit le problme de la conception physique dune manire gnrale. Il
commence par la dfinition formelle de ce problme. Un ensemble de structures doptimisation
est galement prsent, savoir les vues matrialises et les index pour la catgorie redondante
de ces structures et la fragmentation horizontale pour la catgorie non redondante. Pour chaque
structure, une formalisation de son problme de slection est donne, suivie par les approches de
slection proposes dans la littrature. Une confrontation de la conception physique des bases
de donnes traditionnelles avec les BDBO est galement discute, suivie par une dmarche de
5
Introduction gnrale
rsolution qui intgre lensemble de tapes que nous considrons pertinentes pour revisiter la
conception physique dans le contexte des BDBO. Elle comprend quatre tapes principales: (i)
la matrise des BDBO existantes, (ii) une tude exprimentale des BDBO afin de dterminer
les paramtres pertinents pour les modles de cots qui sont au cur de la conception physique,
(iii) la proposition dun modle de cots pour les BDBO et finalement, (iv) lutilisation de ces
modles pour la slection dune structure doptimisation, savoir les vues matrialises.
La deuxime partie de notre manuscrit prsente lensemble de nos contributions. Elle contient
les trois chapitres suivants.
Le chapitre 3 est consacr premirement la formalisation des ontologies et des BDBO.
La formalisation de lontologie prsente la premire dimension de diversit savoir le modle
dontologie. Tandis que la deuxime dimension prsente en dtails la diversit concernant le
modle de stockage pour les instances et lontologie et larchitecture du SGBD cible. Ces formalisations nous donnent une vue globale sur lensemble des paramtres qui peuvent influencer
la performance des requtes et le chargement des donnes au sein des BDBO. Six BDBO sont
testes (Oracle, IBM Sor, Jena, Sesame, DB2RDF et OntoDB) sur les donnes du banc dessai
LUBM, selon les critres cits ci-dessus. Cette tude exprimentale nous permet didentifier les
paramtres importants pour tablir notre modle de cot.
Le chapitre 4 propose un modle de cot pour estimer le cot des requtes en termes
dentres-sorties dfinies sur une BDBO. Ce modle prend en compte la diversit prsente
dans le chapitre 1. Des formules mathmatiques pour estimer le cot de la slection, de la projection et de la jointure sont donnes. Ce modle de cot est valid sur les donnes du banc
dessai LUBM.
Dans le chapitre 5 nous nous focalisons sur une structure doptimisation populaire qui est
les vues matrialises. Rappelons que la slection de ces dernires est difficile et base sur un
ensemble de requtes connu lavance. Pour faciliter la prsentation de nos propositions, nous
commenons par introduire les concepts de base sur les requtes, les arbres algbriques et le plan
unifi regroupant lensemble des arbres algbriques des requtes de dpart. Trois approches de
slection de vues matrialises sont dcrites : une approche conceptuelle, dans laquelle les vues
sont slectionnes au niveau ontologique. Cette approche exploite la prsence de lontologie
dans la base de donnes. La deuxime approche dite impose, qui suppose la connaissance de
toutes les composantes dune BDBO. Cette approche est similaire aux approches de slection
des vues traditionnelles, et ne prend pas en compte la diversit. La troisime approche, dite
simule, prend en compte la diversit. Des algorithmes de type glouton et gntique sont proposs pour rsoudre le problme de la slection des vues. Une comparaison de nos propositions
par rapport ltat de lart est donne.
La troisime partie prsente les conclusions gnrales de ce travail et esquisse diverses perspectives.
Les publications relatives ces travaux sont :
4. Structure du mmoire
Bery Mbaiossoum, Selma Khouri, Ladjel Bellatreche, Stphane Jean, Mickael Baron,
Etude Comparative des Systmes de Bases de Donnes base Ontologiques, Actes du
XXXme Congrs INFORSID, pp. 379-394, Montpellier, France, Mai 2012
Bery Mbaiossoum, Ladjel Bellatreche, Stphane Jean, Mickael Baron, Comparaison et
Evaluation des Systmes de Gestion de Base de Donnes Smantiques, Ingnierie des
Systmes dInformation (ISI), 18(3): 39-63, 2013
Bery Mbaiossoum, Ladjel Bellatreche, Stphane Jean, Towards Performance Evaluation
of Semantic Databases Management Systems, 29th British National Conference on Databases (BNCOD 2013), pp. 107-120, LNCS, Springer, Oxford, July, 2013
Bery Mbaiossoum, Ladjel Bellatreche, Stphane Jean, Materialized View Selection Considering the Diversity of Semantic Web Databases, Proceedings of the 18th Conference on
Advances in Databases and Information Systems (ADBIS), pp. 163-176, LNCS, Springer,
Ohrid, Republic of Macedonia September 2014,
Ce mmoire comporte une annexe qui prsente les requtes utilises dans les exprimentations.
Premire partie
Concepts fondamentaux
Chapitre
Ontologie et Bases de Donnes Base Ontologique
Sommaire
1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
Quest-ce quune ontologie? . . . . . . . . . . . . . . . . . . . . . . .
12
2.1
Origine de la notion dontologie . . . . . . . . . . . . . . . . . .
12
2.2
Notion dontologie en informatique . . . . . . . . . . . . . . . .
13
2.3
Dfinition dune ontologie . . . . . . . . . . . . . . . . . . . . .
13
2.4
Types dontologies . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.5
Taxonomie des ontologies de domaine . . . . . . . . . . . . . .
15
Comment dfinir formellement une ontologie? . . . . . . . . . . . . .
19
3.1
Formalisme RDF/RDFS . . . . . . . . . . . . . . . . . . . . . .
19
3.2
Formalisme OWL . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.3
Formalisme PLIB . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.4
Synthse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
Ontologies vs. Modles Conceptuels . . . . . . . . . . . . . . . . . . .
30
Base de Donnes Base Ontologique . . . . . . . . . . . . . . . . . .
31
5.1
5.2
6
Modle de stockage traditionnel ou autres modles pour les BDBO? 32
Architecture traditionnelle ou dautres architectures pour le SGBD

cible des BDBO? . . . . . . . . . . . . . . . . . . . . . . . . .
Langage de requtes des BDBO
39
. . . . . . . . . . . . . . . . . . . .
44
6.1
Principaux langages proposs . . . . . . . . . . . . . . . . . . .
45
6.2
Prsentation du langage SPARQL . . . . . . . . . . . . . . . . .
46
6.3
Prsentation du langage OntoQL . . . . . . . . . . . . . . . . .
48
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
11
Chapitre 1. Ontologie et Bases de Donnes Base Ontologique
1 Introduction
Les Bases de Donnes Base Ontologique (BDBO) sont au cur de nos travaux et plus
particulirement leur conception physique. Contrairement une base de donnes traditionnelle
qui ne stocke que les instances dune application, une BDBO stocke la fois des instances et
lontologie dcrivant leur sens. La prsence de cette nouvelle composante au sein dun SGBD
a pouss la communaut des bases de donnes rpondre aux quatre questions suivantes :
1. Quest-ce quune ontologie?
2. Comment dfinir formellement une ontologie?
3. Est-ce que les modles de stockage traditionnels (orients table relationnel) sont adapts
aux ontologies et aux instances ontologiques?
4. Est-ce que larchitecture de stockage traditionnelle dun SGBD (constitue de deux parties: le contenu et la mta-base) peut tre remise en question?
Lensemble des rponses ces questions peut influencer considrablement la dfinition dun
modle de cot mathmatique estimant le temps de rponse dun ensemble de requtes, car tout
modle de cot est sensible aux modles de stockage utiliss par le SGBD cible et la dfinition
de structures doptimisation au niveau conceptuel, vu les fortes similarits entre les ontologies
et les modles conceptuels.
Dans ce chapitre, nous commenons par prsenter les concepts fondamentaux lis aux ontologies. Puis nous rpondons aux questions que nous avons poses.
2 Quest-ce quune ontologie?

2.1 Origine de la notion dontologie
Le terme ontologie fut dabord utilis au XV II eme sicle en philosophie aristotlicienne pour
dsigner la partie de la philosophie qui a pour objet ltude des proprits les plus gnrales de
ltre, telles que lexistence, la possibilit, la dure ou le devenir (cf. CNRTL 3 ). Le dictionnaire de la langue philosophique FOULQ. St-JEAN 1962 [17] dfinit "lontologie comme une
tude des tres en eux-mmes et non tels quils nous apparaissent". Daprs Meynard [18],
la mtaphysique et lontologie sont synonymes au sens strict du terme, cest--dire ltude de
ltre dans ses proprits gnrales et dans ce quil peut avoir dabsolu ; en dautres termes,
cest ltude de ce que sont les choses en elles-mmes, dans leur nature intime et profonde, par
opposition la seule considration de leurs apparences ou de leurs attributs spars.
Le terme est aussi utilis en mdecine pour dsigner une doctrine qui prtend tudier ltre
de la maladie, notamment des fivres, comme si la maladie existait conformment un type
bien dfini, une essence.
3. Centre National de ressources Textuelles et Lexicales - http://www.cnrtl.fr/lexicographie/ontologie
12
2.2 Notion dontologie en informatique

En informatique et en science de linformation, une ontologie dsigne un ensemble structur
des termes et concepts ayant une smantique dans un domaine donn. Lontologie constitue
donc un modle de donnes reprsentant un ensemble de concepts dans un domaine, ainsi que
des relations entre ces concepts. Les concepts sont organiss en un graphe dont les relations
peuvent tre des relations smantiques ou des relations de subsomption. Ce type de graphe est
appel le schma dontologies.
En gnral, les ontologies utilisent les notions suivantes :
classe : un ensemble, une collection ou un type dobjets. Une classe possde toujours un
identifiant. Les classes sont toujours organises en une hirarchie laide de relation de
subsomption ;
proprit : une caractristique que des objets peuvent possder ou partager. Cela peut
aussi tre une fonctionnalit des objets. Les proprits permettent de distinguer les instances dune classe. Comme les classes, les proprits possdent toujours un identifiant.
Elles peuvent tre types, cest--dire associes un domaine et un co-domaine de valeurs. Une proprit peut prendre ses valeurs dans des types simples ou dans des classes ;
type de valeurs : un ensemble de valeurs dans lesquels les proprits doivent prendre leurs
valeurs. Il existe (1) des types simples (e.g. entier, rel, caractre, boolen, etc.), (2) des
types classes et (3) des types collections (proprits associes des cardinalits minimum
et maximum) ;
individu : une instance de classes. Les individus sont caractriss par leur appartenance
une (ou ventuellement plusieurs) classes(s) et par des valeurs de proprits. Selon les
formalismes, chaque individu peut ou non avoir un identifiant unique qui permet de le
distinguer des autres ;
axiome : un prdicat applicable des classes, des relations ou des instances permettant
dassurer lintgrit des donnes ou de faire des dductions de connaissances. Tous les
formalismes permettent dexprimer des axiomes de typage et de subsomption. Les autres
axiomes dpendent de chaque modle dontologie et des prdicats particuliers dfinis au
niveau du langage. Par exemple, OWL permet dexprimer des axiomes de cardinalit et
PLIB des contraintes sur les domaines de valeurs.
Dans cette thse, nous ne traitons que des ontologies en informatique.
2.3 Dfinition dune ontologie

Une ontologie est une conceptualisation qui permet de reprsenter explicitement la smantique dun domaine par des "modles objets" consensuels dont chaque concept (classe ou proprit) est associ un identificateur universel permettant de rfrencer la smantique qui lui
correspond. Selon Gruber [19], une ontologie est une spcification explicite dune conceptualisation. Cette dfinition a t enrichie par Pierra [20] en dcrivant une ontologie comme une
13

reprsentation formelle, explicite, rfrenable et consensuelle de lensemble des concepts partags dun domaine en termes de classes dappartenance et de proprits caractristiques. Cette
dfinition a mis en avant quatre caractristiques principales dune ontologie savoir : formelle,
explicite, rfrenable et consensuelle que nous dtaillons ci-dessous :
formelle : exprime dans un langage de syntaxe et de smantique formalises comme par
exemple rdf schma [21], owl [3] ou plib [22] permettant ainsi des raisonnements automatiques ayant pour objet soit deffectuer des vrifications de consistance, soit dinfrer
de nouveaux faits ;
consensuelle : admise par lensemble des membres (et des systmes) dune communaut.
Ainsi, la conception dune ontologie doit impliquer la participation des experts et des
spcialistes du domaine. Tous les lments ontologiques globaux partags doivent tre
accepts et donc tre modliss lidentique par tous. Par exemple, les ontologies de
produits conformes la norme ISO 13584 (PLIB) font lobjet dun consensus international rsultant dun processus rigoureux de standardisation et sont publies comme des
standards internationaux ISO ou IEC. Il convient de signaler que cette caractristique est
inhrente aux ontologies globales qui peuvent tre importes et modifies pour des usages
locaux (ontologie locale) ;
rfrenable : toute entit ou relation dcrite dans lontologie peut tre directement rfrence par un symbole ( identifiant universel ), partir de nimporte quel contexte, afin
dexpliciter la smantique de llment rfrenant ;
explicite : les concepts du domaine et leurs diffrentes proprits sont explicitement
dcrits et le domaine modlis est dcrit indpendamment dun point de vue ou dun
contexte implicite. Des points de vue diffrents pourront donc partager les mmes concepts.
2.4 Types dontologies

Suivant le degr dabstraction vis, trois types dontologies ont t identifis [23] :
les ontologies globales (Top-Level Ontology) : ce sont des ontologies formelles qui prsentent un haut niveau de gnralit et dabstraction. Elles sont le rsultat dun dveloppement systmatique, consensuel et rigoureux permettant le partage de connaissances et le
transfert dun contexte un autre. Elles sont ddies une utilisation trs gnrale. Elles
servent de base pour le dveloppement des ontologies locales spcifiques des domaines
donns. On peut citer comme exemple le projet KRAFT [24] ou WordNet 4 [25] ;
Les ontologies de domaine : ce sont des ontologies qui se limitent une reprsentation des concepts de domaines donnes (gographie, mdecine, etc.). Elles prsentent un
niveau dabstraction moins lev que celui des ontologies globales. En gnral, elles apportent une spcialisation des concepts gnraux dune ontologie globale. On peut citer
comme exemple Uniprot [26], une ontologie dcrivant les protines ;
Les ontologies dapplication qui sont spcifiques un champ prcis dapplication dans
4. dictionnaire de la langue anglaise, http://www.cogsci.princeton.edu/wn
14

un domaine donn. Elles prsentent donc un haut degr de spcificit. Une ontologie
dapplication spcifie une ontologie de domaine ou une ontologie globale. Par exemple,
lensemble des spcifications sur les cours deau de France est une ontologie dapplication qui peut spcifier les concepts gnraux dune ontologie de domaine gographique.
Lontologie gopolitique 5 mise au point par la FAO (Organisation des Nations Unies pour
lAlimentation et lAgriculture) pour faciliter lchange et le partage de donnes de manire standardise entre les systmes de gestion dinformations relatives des pays et/ou
des rgions est aussi un exemple dontologie dapplication.
Dans le cadre de notre recherche, nous nous intressons aux ontologies de domaine. Nous
prsentons dans la section suivante une classification de ce type dontologies.
2.5 Taxonomie des ontologies de domaine

Les ontologies de domaine ne sont pas toutes identiques. Certaines se focalisent sur la dfinition des concepts dun domaine dtude. On les appelle les ontologies conceptuelles (OC).
Gruber [19] distingue deux types de concepts dans une ontologie : les concepts primitifs et les
concepts dfinis. Les concepts primitifs ou canoniques reprsentent des concepts ne pouvant
tre dfinis par une dfinition axiomatique complte. Les concepts primitifs sont une base sur
laquelle peuvent tre dfinis dautres concepts appels concepts dfinis ou concepts non canoniques. Pierra [27] fait remarquer qu ct des ontologies bases sur les concepts, il existe des
ontologies qui dcrivent des mots, elles sont qualifies dontologies linguistiques (OL). Ainsi,
trois catgories dontologies existent [27] :
Ontologies Conceptuelles Canoniques (OCC) : ce sont des ontologies qui ne contiennent
que des concepts primitifs ;
Ontologies Conceptuelles Non Canoniques (OCNC) : ce sont des ontologies qui contiennent
des concepts primitifs ainsi que des concepts dfinis ;
Ontologies Linguistique (OL) : ce sont des ontologies qui dfinissent des termes ventuellement dfinis en plusieurs langues naturelles qui sont utiliss dans un domaine dtude.
Ces ontologies sont orientes vers les traitements linguistiques (par exemple TALN 6 ).
Ces trois catgories dontologies peuvent tre combines en un modle en oignon (Fig. 1.1).
La couche de base de ce modle est constitue par la couche canonique. La seconde couche
non canonique est construite sur la couche canonique et la dernire couche est forme par les
ontologies OL fournissant une reprsentation des concepts dun domaine en langage naturel
ventuellement dans plusieurs langues. Ce modle en oignon dfinit donc une ontologie de
domaine en couches complmentaires pour la rsolution de diffrents problmes.
Nous prsentons ci-dessous brivement chacune des catgories dontologie identifies.
5. http://www.fao.org/countryprofiles/geoinfo.asp?lang=fr
6. Traitement Automatique de la Langue Naturelle
15
OL
Expression de classes :
Logique de Description
OCNC
Autres
OCC
Expression
de
proprits :
F-Logic

:

:

Expression de proprits :
Fonctions de drivation
Figure 1.1 Le modle en oignon pour les ontologies de domaine (extraite de [28] )
2.5.1
Ontologies Conceptuelles Canoniques (OCC)
Une ontologie canonique ne prsente que des concepts primitifs (ou atomiques), cest-dire des concepts qui ne peuvent pas tre drivs dautres concepts. Les ontologies canoniques
fournissent une base formelle pour une modlisation et un change efficace de la connaissance
dun domaine. Ces ontologies sont importantes pour le domaine des bases de donnes (o la
redondance est viter), pour le vocabulaire technique (o chaque notion est reprsente par
un mot unique) et pour les formats dchange (o une seule reprsentation possible est prvue
pour chaque information change). Dublincore 7 [29] est un exemple normalis dontologies
conceptuelles canoniques. Pour mieux illustrer nos propos, considrons un fragment de lontologie LUBM [30] prsente sur la figure 1.2. Elle est constitue de trois classes appeles
Personne ayant comme proprit nom et sexe, Etudiant qui est une sous-classe de Personne et
Universit. Dans cette ontologie, tous les concepts sont canoniques. RDFS [21] et PLIB [31]
sont des modles dontologies communment utiliss pour dfinir des ontologies canoniques.
2.5.2
Ontologies Conceptuelles Non Canoniques (OCNC)
Ce sont des ontologies qui renferment dans leurs dfinitions des relations dquivalence
entre les concepts. Ce genre de relations permet de dfinir les concepts non canoniques. Les
OCNC contiennent des concepts primitifs ainsi que des concepts dfinis. La dfinition de concepts
se fait laide des oprateurs portant sur les classes comme les oprateurs ensemblistes (union,
intersection, diffrence) et les oprateurs portant sur les proprits comme les restrictions sur
les valeurs de proprits ou sur la cardinalit. Elle peut se faire aussi travers des relations
algbriques ou logiques entre les proprits. Les OCNC permettent de reprsenter la fois les
7. http://dublincore.org/
16
Figure 1.2 Exemple dune ontologie OCC

conceptualisations dun domaine et les correspondances entre celles-ci. Dans notre exemple
dontologie OCC prcdent, on pourrait dfinir de manire informelle le concept canonique
Etudiant comme un concept non canonique : Etudiant Personne inscrite dans une universit.
On peut ainsi incorporer dans notre OCC, des concepts non primitifs et obtenir donc une OCNC.
La figure 1.3 prsente une ontologie OCNC surcouche de lontologie OCC prcdente avec une
spcialisation du concept Personne par deux concepts dfinis Homme (Personne de sexe masculin), Femme (Personne de sexe fminin) et une dfinition informelle du concept Etudiant.
Les constructeurs OCNC sont galement trs utiles pour dfinir des mappings entre diffrentes
ontologies. Ils permettent galement dtendre les infrences que lon peut raliser sur une ontologie.
Figure 1.3 Exemple dune ontologie OCNC
2.5.3
Ontologie Linguistique (OL)
Ce sont des ontologies qui visent reprsenter les mots utiliss dans un domaine particulier. Les ontologies linguistiques permettent de fournir une reprsentation en langage naturel
des concepts dun domaine. Les reprsentations peuvent tre multilingues. Ces ontologies sont
17

utilises pour la recherche de synonymes linguistiques et dans la recherche de documents pertinents par rapport une requte qui sexprime par un ensemble de mots. WordNet [25] est un
exemple dontologie linguistique. On peut obtenir une ontologie OL partir de notre exemple
dontologie OCNC prcdent par addition de commentaires ou de descriptions textuelles aux
concepts dfinis ou primitifs. Par exemple, le concept Homme pourrait tre associ aux termes
Man, Hombre, Mann, etc. La construction de telles ontologies est souvent faite de faon semiformelle par un processus dextraction de termes dans un ensemble de documents du domaine
et qui sont ensuite valids et structurs par des experts (humains) du domaine.
2.5.4
Modle en oignon et conception des ontologies
On peut remarquer que la taxonomie des ontologies en couches prsente prcdemment

revt une dimension mthodologique dfinissant deux mthodes de conception dontologies.
La premire mthode dite "des mots aux concepts" consiste extraire la couche conceptuelle
partir de la couche linguistique. Elle ncessite lextraction semi-automatique des termes du
domaine ( partir de corpus textuels par exemple) et la dfinition des concepts partir de ces
termes. La deuxime mthode dite "des concepts aux mots" consiste construire la couche linguistique partir de la couche conceptuelle. Elle ncessite la dfinition des concepts canoniques
dun domaine obtenus par un consensus dexperts, un choix des oprateurs dquivalence entre
les concepts pour dfinir les concepts non canoniques ou drivs, et une dfinition en langage
naturel des concepts de lontologie.
2.5.5
Les ontologies dans le monde industriel
Les ontologies ont t largement utilises dans le monde industriel, et en particulier, un

nombre important dontologies dans le domaine de lingnierie ont t dveloppes. On peut
citer par exemple, lontologie normalise IEC 61360-4 sur le domaine des composants lectroniques, lontologie ISO 13399 sur le domaine des outils coupants, lontologie ISO 13584-501
sur le domaine des matriels de mesure, etc. Ces ontologies ont t acceptes comme des ontologies consensuelles et partages par tous les participants impliqus dans le processus B2B
(Business to Business), o chaque fournisseur dcrit les classes de ses composants dans son
catalogue en rfrenant le plus possible lontologie normalise. Dans ce cas, lontologie joue
le rle dun dictionnaire. Sa prsence facilite lintgration et lchange des composants entre
les diffrents fournisseurs. Notre laboratoire LIAS a particip au dveloppement et la normalisation dun nombre important dontologies dans le domaine de lingnierie (avionique avec
Airbus, nergie avec EDF, gologique avec lInstitut Franais de Ptrole, etc.).
Dans cette section, nous avons dfini et illustr par des exemples les notions fondamentales
lies aux ontologies. Dans la section suivante, nous rpondons la deuxime question pose
dans lintroduction en dcrivant diffrents modles dontologie.
18
3 Comment dfinir formellement une ontologie?

Un formalisme dontologies est un modle permettant de reprsenter des ontologies. Gnralement prsent sous la forme dun modle orient objet, il est compos dentits et dattributs
permettant de dcrire les constructeurs dune ontologie tels que les constructeurs de classes et
de proprits. Dans la littrature, on trouve beaucoup de modle dontologies parmi lesquels
PLIB [2], F-Logic [32], RDF/RDFS [21], DAML+OIL[33], etc. Ces modles diffrent selon
lobjectif vis. Certains ont pour but de dfinir des ontologies pour la gestion et lchange des
donnes. Ils cherchent ainsi dfinir la smantique des concepts de manire unique et prcise et
se focalisent donc sur les OCC. Les modles RDF-Schema [21] et PLIB [2] sont des exemples
de ces formalismes. Dautres formalismes ont t proposs pour la description dontologies
permettant de dfinir des correspondances entre vocabulaires et offrent ainsi des possibilits de
dduction et dinfrence. Ces formalismes dfinissent ainsi des concepts primitifs et dfinis.
OWL ou OWL Flight [3] en sont des exemples. Nous prsentons ci-dessous les modles dontologies qui nous intressent dans nos travaux : les modles RDF/RDFS, OWL et PLIB. Nous
verrons quils se basent sur un noyau commun de constructeurs sur lesquels nous avons bas
nos travaux.
3.1 Formalisme RDF/RDFS

RDF (Resource Description Framework) est un langage utilis pour la reprsentation des
informations relatives aux ressources sur le Web. Il fut conu pour annoter les documents du
Web laide de mtadonnes (le titre, lauteur et la date de modification dune page web, etc.).
Avec la gnralisation du concept de ressource Web , RDF est utilis pour reprsenter des
informations propos de choses identifiables sur le Web. Beaucoup de sites de vente en ligne
utilisent RDF pour la prsentation de leurs articles. Les informations exprimes en RDF sont
traitables par des applications au lieu dtre seulement affiches pour les humains. Ces informations peuvent ainsi tre changes entre les applications sans perte de sens. Cela veut dire
que les informations peuvent tre mises la disposition dautres applications que celles pour
lesquelles elles ont t cres au dpart.
Pour identifier les ressources, RDF utilise des URI (Uniform Resource Identifiers). Il dcrit
les ressources en fonction de proprits et de valeurs de proprits. Les instances RDF (ou
dclaration RDF) sont prsentes sous forme de triplets (sujet, prdicat, valeur).
sujet dsigne la ressource dcrire. Le sujet est en gnral identifi par un URI mais peut
aussi tre un nud anonyme. Une ressource peut tre une page Web, une partie dune
page Web rfrence par une ancre ou mme un objet quelconque.
prdicat reprsente une proprit qui peut tre applique sur la ressource. Il est aussi
reprsent par un URI.
objet est la valeur de la proprit. Il peut tre une donne ou une autre ressource. Il
19

est identifi par un URI mais peut aussi tre un nud anonyme ou un littral (valeur
ventuellement typ par un des types de donnes primitifs dfinis par XML Schma) .
Un ensemble de donnes RDF peut tre reprsent par un graphe de nuds et darcs reprsentant les ressources, leurs proprits et valeurs. Par exemple, le triplet (Etudiant, est-Inscrit,
Cours) est reprsent graphiquement sur la figure 1.4.
( Sujet,
Prdicat,
estInscrit
Etudiant
Objet )
Cours
Figure 1.4 Exemple dun triplet RDF

La smantique dun document RDF est exprime en sappuyant sur la thorie des ensembles
et la thorie du modle [34]. Ce dernier vise dfinir des structures mathmatiques pour une
interprtation des lments du vocabulaire de RDF. Ces structures fournissent le moyen de
vrifier formellement quune dclaration (triplet) est vraie dans un document RDF. En effet,
tout triplet RDF peut tre traduit en formule de logique du premier ordre, positive, conjonctive
et existentielle :
(S u jet, Predicat, Ob jet) Ob ject, S u jet tel que Predicat(S u jet, Ob jet)
RDF introduit quelques prdicats prdfinis, mais ne propose pas de constructeurs prdfinis pour la conception dontologies. Il ne permet pas de formuler des contraintes smantiques
riches ou de faire des raisonnements. Ainsi, il a t rapidement tendu par un ensemble de
constructeurs constituant le modle RDF-Schema pour la dfinition dontologies.
RDF-Schma (ou RDFS) est un modle issu du Web Smantique, tendant le modle RDF
par des constructeurs permettant la dfinition de classes et de proprits. Il permet entre autres
de btir des concepts, ventuellement dfinis partir dautres concepts, et ayant la particularit dtre partags. Il offre un ensemble de constructeurs de modlisation orients objets pour
la dfinition de concepts. RDFS est un langage de reprsentation des connaissances avec une
syntaxe et une smantique. Il permet de raliser des infrences [35]. Grce linfrence, on
peut dduire des nouveaux triplets partir des triplets existants. Les expressions RDFS sont
aussi crites sous forme de triplets (triplets RDF) et restent des expressions RDF valides. La
seule diffrence entre une expression RDF "normale" et une expression RDFS est laccord fait
sur la smantique des termes dfinis en RDFS et par consquent sur linterprtation de certains
triplets.
20

RDFS dfinit la classe ressource comme classe mre de toutes les classes. Il permet une description textuelle des classes et des proprits au travers des attributs rdfs:label, rdfs:comment,
rdfs:seeAlso et rdfs:isDefinedBy. RDFS ne dispose pas de primitives dcrivant les quivalences
conceptuelles. Les ontologies RDFS sont donc des ontologies canoniques (OCC). Nous prsentons ci-dessous les principaux constructeurs de RDFS.
Constructeurs de classes.
Pour crer des classes, le constructeur rdfs:class est utilis. Le constructeur rdfs:subClassOf
permet de spcifier une organisation hirarchique des classes.
Constructeurs de proprits.
Le constructeur rdfs:property permet de spcifier des proprits caractristiques dune
classe. La hirarchie des proprits est cre laide du constructeur rdfs:subProperty.
Les constructeurs rdfs:domain et rdfs:range permettent de spcifier respectivement le domaine (une ou plusieurs classes) et le co-domaine de valeur dune proprit (une classe
ou un type de donnes).
Constructeurs dinstances.
Lappartenance dune instance une classe est dfinie grce au constructeur rdf:type.
Ce constructeur permet de "typer" une ressource (ou instance RDF) avec une proprit
ou une classe dfinie en RDFS. Les triplets correspondant sont de la forme (i, rdf:type,
C) indiquant que i est une instance de la classe C. Dans RDFS, il est possible quune
instance appartienne plusieurs classes mme de diffrentes hirarchies (subsomption).
Lattribution dune valeur v une proprit p dune instance i se fait laide dun triplet
de la forme (i, p, v).
Les types de valeurs.
Les types de valeurs des objets manipuls dans RDFS peuvent tre des instances de
classes ou des littraux. Les littraux peuvent tre typs par les types prdfinis de XML
Schma (pour les chanes de caractres, les numriques, les dates, etc.). RDFS fournit
aussi un type collection (rdfs:Container) et utilise les types collection de RDF (rdf:List,
rdf:Bag).
Les axiomes.
Hormis lappartenance et la subsomption, RDFS ne permet pas de dfinir de nouveaux
axiomes. Par contre, il permet la mta-modlisation. Ainsi, il permet suivant le rle jou
dans un contexte par une information, de la reprsenter comme une classe ou comme une
instance. Dans la relation de subsomption, RDFS ne permet pas de rfrence circulaire,
cest--dire quune classe (ou une proprit) ne peut pas tre sa propre sous-classe (ou sa
propre sous-proprit).
RDFS tend ainsi RDF avec un ensemble de constructeurs qui fait de lui un formalisme
dontologies. Dans la section suivante, nous prsentons le formalisme OWL qui permet de dfinir des ontologies orientes infrence qui sont beaucoup utilises dans le domaine du Web
Smantique.
21
3.2 Formalisme OWL

Le modle OWL est actuellement reconnu par le W3C 8 comme tant le standard pour reprsenter des ontologies pour le Web Smantique. Il permet une description trs riche des ontologies et facilite la publication et le partage des ontologies sur le Web Smantique. OWL est
inspir de DAML (projet amricain) et dOIL (projet Europen). Pour permettre la manipulation
des ontologies par les humains et les machines, OWL tend le modle RDFS par des oprateurs
permettant la dfinition dontologies plus expressives et offrant des capacits de raisonnement
suprieures. OWL tant construit sur RDF et RDFS, il utilise la syntaxe RDF/XML. Il permet
de raisonner sur ces connaissances en sappuyant sur la Logique de Description (axiomatique
formelle).
OWL se dcline en trois versions : OWL-Lite, OWL-DL et OWL-Full, qui sont des sousmodles prsentant un compromis entre leur pouvoir expressif et leur dcidabilit de raisonnement. Le langage OWL-Lite dcrit une hirarchie de classifications et offre des mcanismes de
contraintes simples. Par exemple, OWL-Lite gre des contraintes de cardinalit uniquement de
valeurs 0 ou 1. Le langage OWL-DL offre une expressivit suprieure OWL-Lite sans remettre
en cause la compltude de calcul (infrences) et la dcidabilit des systmes de raisonnement.
Il est fond sur la logique descriptive. Le langage OWL-DL intgre toutes les structures de langage dOWL avec des restrictions comme la sparation des types (une classe ne peut pas tre en
mme temps un individu et une proprit, une proprit doit tre associe un individu ou une
classe). Le langage OWL-Full est destin aux utilisateurs souhaitant une expressivit suprieure
OWL-DL et une libert syntaxique de RDF sans une garantie de dcidabilit du raisonnement
(infrence). Par exemple, dans OWL-Full, on peut simultanment traiter une classe comme une
collection dindividus et comme un individu part. Il existe une hirarchie de dpendance entre
ces trois sous langages : toute ontologie OWL-Lite valide est galement une ontologie OWLDL valide, et toute ontologie OWL-DL valide est galement une ontologie OWL-Full valide. Le
degr dexpressivit est croissant de OWL Lite OWL-Full.
Nous prsentons dans ce qui suit les constructeurs de OWL DL. Certaines limites de OWL
Lite sont aussi voques.
3.2.1
Constructeurs de classe OWL
Il y a plusieurs manires de dclarer une classe OWL :

laide du constructeur owl:Class (classes nommes). Le concept dhritage se traduit
laide de la proprit subClassOf. Il existe dans toute ontologie OWL une superclasse,
nomme Thing, dont toutes les autres classes sont des sous-classes. Il existe galement
une classe nomme noThing, qui est sous-classe de toutes les classes OWL. Cette classe
ne peut pas avoir dinstance ;
8. World Wide Web Consortium
22

par numration des instances de la classe laide du constructeur "owl:oneOf " ;
par restriction des proprits (contrainte de valeur et cardinalit) : une contrainte de valeur
porte sur la valeur de proprit dune instance tandis quune contrainte de cardinalit porte
sur le nombre de valeurs que peut prendre une proprit. Les restrictions sur des valeurs
sont faites par les axiomes :
allValuesFrom qui exprime une restriction universelle, cest--dire toutes les instances
qui, pour une proprit donne, prennent leur valeur dans une classe donne ;
someValuesFrom, qui exprime une restriction existentielle, cest--dire toutes les instances qui, pour une proprit donne, ont au moins une valeur dans une classe donne ;
hasValue qui permet de dfinir des classes selon lexistence de valeurs de proprits
particulires. Elle impose une valeur spcifique toutes les instances de la classe en
question.
Les cardinalits sont dfinies laide des axiomes owl:minCardinality, owl:maxCardinality
et owl:Cardinality qui expriment les nombres dlments dans une relation ou son intervalle ;
par intersection de deux ou plusieurs classes avec owl:intersectionOf ;
par union de deux ou plusieurs classes grce au constructeur owl:unionOf ;
par complmentarit dune autre classe cest--dire une classe qui contient toutes les instances dans le domaine de discours nappartenant pas une autre classe. Cela se fait grce
au constructeur owl:complementOf.
3.2.2
Construction des proprits OWL
On distingue deux types de proprit OWL : Les proprits dobjets (owl:ObjectProperty),

qui sont des relations entre les instances de deux classes et les proprits de types de donnes
(owl:DatatypeProperty), qui sont des relations entre des instances de classes, des littraux RDF
[36] et des types de donne de schma XML [37].
OWL offre des constructeurs pour dfinir et restreindre des proprits (cf. dfinition des
classes par restriction des proprits). Nous pouvons dfinir un domaine et un co-domaine pour
une proprit. Il est possible dajouter des caractristiques de proprit qui fournissent un mcanisme puissant pour amliorer le raisonnement li aux proprits. Parmi les caractristiques
principales des proprits, nous trouvons la transitivit, la symtrie, la fonctionnalit et linverse
[38]. Une proprit peut tre aussi dfinie comme une spcialisation (sous-proprit) dune autre
proprit (rdfs:subProperty).
3.2.3
Types de donnes
OWL utilise pour le type de donnes dune proprit owl:DatatypeProperty, le type RDFSchema rdfs:Literal ou un des types simples dfinis pour les XML Schma. Pour le type de
donnes dune proprit owl:ObjectProperty, on utilise une classe en se servant du constructeur
23

rdfs:range pour la spcifier.
3.2.4
Instance dune classe
On dclare lappartenance dun individu (instance) une classe de la manire suivante :

hNomClasse rdf:ID="individuID"i o individuID est lidentifiant de linstance et NomClasse
est le nom de la classe laquelle on associe individuID. Exemple : hUniversit rdf:ID="UP"i
dclare UP comme instance de la classe Universit. La proprit rdf:type est aussi utilise pour
lier un individu une classe dont il est membre.
Les instance sont identifies par des URI et peuvent appartenir plusieurs classes non lies
par la relation de subsomption.
3.2.5
Constructeur daxiomes
OWL offre la possibilit de prciser les cardinalits dune proprit laide des axiomes
owl:minCardinality, owl:cardinality et owl:maxCardinality. Laxiome owl:equivalentClass indique que deux classes sont quivalentes, cest--dire quelles possdent les mmes instances.
Laxiome owl:disjointWith indique que deux classes donnes ne partagent aucune instance.
Laxiome owl:equivalentProperty permet dindiquer que deux proprits sont quivalentes,
cest--dire quelles prsentent les mmes valeurs pour les mmes instances. En OWL, lhypothse dunicit des noms qui considre que les identifiants permettent didentifier de manire
unique les lments dans une ontologie, nest pas garantie. En effet, deux instances de diffrents
identifiants peuvent tre les mmes. Pour grer cela, OWL propose les axiomes owl:sameAs,
owl:differentFrom et owl:AllDifferent permettant dindiquer lgalit ou lingalit des instances.
Avec ces constructeurs, les raisonnements associs OWL-DL restent dcidables. Le problme dinfrence en OWL DL est class comme tant aussi difficile que ce problme dans
les langages des logiques de description de la famille SHOIN(D). Tobies [39] a montr que ces
langages sont de complexit au pire des cas de temps exponentiel non dterministe (NExpTime). Dans la pratique, OWL-Lite est souvent utilis pour obtenir de bonnes performances
[40]. Celui-ci nautorise pas la cration de classes par les oprations boolennes owl:unionOf et
owl:complementOf, par numration de ses instances et par restriction de valeurs owl:hasValue.
Les axiomes de cardinalit owl:minCardinality, owl:cardinality et owl:maxCardinality sont limits prendre la valeur 0 ou 1 en OWL-Lite. Dans la section suivante, nous prsentons le
formalisme PLIB qui a t conu pour dfinir des ontologies canoniques pour le domaine de
lingnierie.
24
3.3 Formalisme PLIB

Le modle PLIB (Parts LIBrary : srie de normes ISO 13584) [2] est un modle initialement dfini pour la description des diffrentes catgories de composants industriels et de leurs
instances. Son objectif est de permettre lchange et la modlisation des diffrentes catgories
de composants industriels et de leurs instances avec le plus de prcision possible; cest--dire
que lon doit savoir quelle classe appartient un objet, quels objets sapplique une proprit
et avec quelle grandeur. Pour cela, une ontologie PLIB doit dfinir de faon la plus concise
possible les classes et les proprits qui caractrisent les objets dun domaine du monde rel et
les abstractions quune communaut peut en construire. Cela veut dire quune ontologie PLIB
ne dfinit une nouvelle classe que quand celle-ci ne peut tre compltement dfinie en termes
dautres classes et de valeurs de proprits. PLIB offre des oprateurs de modularit permettant
lintgration dans un environnement homogne et cohrent dontologies htrognes provenant
de diffrentes sources.
Dans un schma dontologie PLIB, les proprits jouent un rle essentiel. Elles permettent
dassocier chaque concept une dfinition, une note, un nom, une image ou un document quelconque. Des classes sont dfinies seulement pour reprsenter des domaines de proprits, et
chaque proprit est dfinie dans le domaine dune classe et na de smantique que pour cette
classe et ses sous-classes. Cette vision soppose celle de OWL qui peut dfinir une proprit
sans une classe comme domaine explicite. PLIB permet de construire des ontologies multilingues o le mme identifiant de concept est li des descriptions dans plusieurs langues. La
multi-reprsentation est aussi possible. En effet, une fois dfini, un concept peut tre associ
un nombre illimit de reprsentations. Le point de vue qui caractrise chaque reprsentation est
galement un concept reprsentable dans lontologie. PLIB ne fournit que des constructeurs canoniques et ainsi les ontologies PLIB sont des modles canoniques dchange. Nous prsentons
ci-dessous les principaux constructeurs de ce modle.
3.3.1
Constructeurs de classes PLIB
PLIB propose des constructeurs de classes et des mcanismes pour les organiser en des
hirarchies de subsomption. Pour la dfinition des classes, PLIB fournit le constructeur item_class. Les classes, comme les autres lments dune ontologie, sont identifies par un BSU
(Basic Semantic Unit). Le BSU est un code didentification construit partir de lidentifiant
universel de lorganisation lorigine de la construction de lontologie (supplier). PLIB propose
aussi les constructeurs functional_model_class et functional_view_class pour la cration des
classes de reprsentation (classe ne contenant que des proprits qui nont de sens que pour un
point de vue "mtier") et les classes de point de vue (classe dfinissant une perspective o les
proprits des classes de reprsentation sont dfinies).
Deux oprateurs de subsomption sont disponibles : is_a et is_case_of. Loprateur is_a
dfinit un hritage simple qui implique lhritage des proprits dfinies par les classes sub25

sumantes. Loprateur case_of permet la subsomption multiple avec importation slective et
nimplique pas implicitement lhritage de proprits. Pour hriter dune proprit dune de ses
classes subsumantes, une classe doit explicitement indiquer limportation de cette proprit dans
sa dfinition. On voit quune classe peut donc hriter dune partie des proprits des classes subsumantes. Cela permet une construction modulaire des ontologies de domaine qui nimportent
dautres ontologies de domaines que certaines classes et proprits juges utiles. Une classe
PLIB peut avoir au plus une seule superclasse renseigne par lattribut its_superclass.
3.3.2
Constructeurs de proprits PLIB
Pour dfinir les proprits, PLIB propose le constructeur non_dependent_p_det pour les
proprits autonomes, le constructeur dependent_p_det pour les proprits dpendantes (cest-dire, dont les valeurs dpendent de paramtres de contexte) et le constructeur representation_det pour les proprits de reprsentation dfinies dans une classe de point de vue ou de
reprsentation. PLIB propose un constructeur de paramtres de contexte (condition_det) qui
dcrit le contexte dans lequel une valeur de proprit est donne. PLIB impose un typage fort
des proprits : chaque proprit doit obligatoirement prciser son domaine et son co-domaine.
Le domaine et le co-domaine sont dfinis grce aux constructeurs name_scope et data_type. Un
co-domaine est un ensemble mathmatique dfini en extension ou en intention. Il peut tre une
classe (class_instance_type), une collection (set_type, bag_type, list_type, array_type) ou un
autre type de donnes. Le champ dapplication dune proprit est dfini par son domaine. Il arrive souvent que ce champ dapplication soit compos de plusieurs classes issues de diffrentes
branches de la hirarchie. Pour rsoudre ce problme, PLIB propose de qualifier les proprits
de la faon suivante :
une proprit est dfinie sur une classe C au plus haut niveau de la hirarchie o elle peut
tre dfinie sans ambigut. Sa porte stend sur toutes les sous-classes de C ;
une proprit visible sur une classe C peut devenir applicable sur cette classe, cest--dire
que toute instance de C doit prsenter une caractristique ou une grandeur qui reprsente
cette proprit.
3.3.3
Type de donnes PLIB
Le modle PLIB fournit des types de donnes prdfinis comme les entiers ou les rels.
On peut associer ces derniers des units de mesure (measure_type) ou des units montaires (currency_type). PLIB permet dutiliser une classe comme un type de donnes grce
au constructeur class_instance_type. PLIB fournit galement le type aggregate_type pour la
cration de collections. Plusieurs types collections sont disponibles comme par exemple les
listes (list_type), les tableaux (array_type), les sacs (bag_type) ou les ensembles (set_type). La
cardinalit de ces collections peut tre dfinie. Enfin, le modle dontologies PLIB permet de
crer des types de donnes utilisateurs comme par exemple des types numrs (non_quantita26

tive_code_type, non_quantitative_int_type, ...).
3.3.4
Constructeurs des instances PLIB
Une instance reprsente un objet appartenant une classe. Elle est dfinie par sa classe
dite de base et lensemble de ses valeurs de proprits. PLIB ne permet donc pas la multiinstanciation mais offre le mcanisme dagrgation dinstance. Pour cela, PLIB distingue les
proprits essentielles dune classe de celles qui dpendent dun point de vue sur le concept
reprsent. Ainsi, une instance peut appartenir non seulement sa classe de base mais aussi aux
classes de reprsentation attaches cette classe de base par la relation is_view_of. Cependant
pour viter la redondance au niveau des valeurs des proprits des instances, les proprits
dfinies sur la classe de base ne sont pas reprises dans les classes de reprsentation.
3.3.5
Axiomes PLIB
Pour tre valide, les ontologies PLIB doivent vrifier certains axiomes parmi lesquels on
trouve :
chaque concept ontologique est identifi par un BSU ;

chaque instance doit appartenir une seule classe de base (et ses superclasses) ;
les instances ne sont dcrites que par les proprits applicables leurs classes ;
la valeur dune proprit doit appartenir son co-domaine.
PLIB nautorise pas un hritage multiple et un cycle dans le graphe de subsomption (is_a)
qui est une fort.
Ces axiomes dfinissent des contraintes dintgrit utilises pour la validation des donnes.
Si une instance est associe une proprit non applicable sa classe ou dont le type valeur
nest pas correcte, le systme doit signaler cette erreur et cette incompatibilit entre lontologie
et les donnes.
3.4 Synthse
La prsentation dtaille de ces trois formalismes dontologies (RDF/RDFS, PLIB et OWL)
nous a permis didentifier leurs caractristiques communes et diffrentes. Ces dernires sont
dtailles dans les sections suivantes.
3.4.1
Caractristiques communes des formalismes dontologies
Tous les formalismes tudis utilisent les concepts de classes et de proprits pour la conceptualisation de domaine. La relation de subsomption est utilise pour dfinir la hirarchie entre
les classes. Chaque concept est associ un identifiant qui permet dassurer son rfrencement
27

partir de nimporte quel environnement. En RDFS et OWL, cet identifiant est un URI alors
quen PLIB cest un BSU. Ces formalismes utilisent des types de donnes simples et collections. Ils fournissent donc des constructeurs communs pour la dfinition des OCC. Le tableau
1.1 prsente les constructeurs canoniques communs des formalismes RDFS, OWL et PLIB.
Constructeurs
Classes
Subsumption de classes
Proprits
typage fort
dpendance entre proprits
domaine/co-domaine multiples
subsumption de proprits
fonctionnelle
inverse fonctionnelle
cardinalit
Types de donnes
simple
classe
collection
Individus
identification universelle
multi-instanciation
point de vue
mta-modlisation
dtection derreur de donnes
RDFS
OWL
PLIB
multiple
multiple
simple/ modulaire
+
+
-
(Lite)
(Lite)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
+
+
(Full)
-
+
+
Table 1.1 Constructeurs de la couche canonique des formalismes RDFS, OWL et PLIB.
Ces formalismes dfinissent aussi des mta-attributs qui dcrivent textuellement des concepts
et ce, dans diffrentes langues naturelles. En dautres termes, chaque formalisme fournit des
constructeurs spcifiques pour la couche OL comme on peut le voir sur le tableau 1.2 donnant
les diffrents descripteurs des formalismes tudis.
3.4.2
Diffrences entre les formalismes dontologies
Les formalismes dontologies diffrent par leurs objectifs : certains sont orients gestion
et changes des donnes (PLIB, RDFS) et dautres sont orients infrence (OWL). Les formalismes orients gestion et changes des donnes dfinissent un langage canonique et sont
plus indiqus pour des bases de donnes. Les contraintes quils dfinissent dans les ontologies
sont considres comme des contraintes dintgrit dans les BD et permettent la dtection der28
Constructeurs
Classe / Proprit
commentaire
label
rfrence
source
dfinition
note
remarque
nom court
nom prfr
figure
document de dfinition
Individus
commentaire
label
description multilingue
RDFS
OWL
PLIB
+
+
+
-
+
+
+
+
-
+
+
+
+
+
+
+
+
+
+
+
+
+
Table 1.2 Descripteurs de la couche linguistique des formalismes RDFS, OWL et PLIB.
Constructeurs
Classes
Intersection
Union
Complement
numration dinstances
Restriction
co-domaine
cardinalit
galit/ingalit de valeur
Caractristiques des proprits
rflexivit, symtrie, transitivit
inverse
Dduction de faits
Vrification dintgrit
RDFS
OWL
PLIB
+
(DL/Full)
(DL/Full)
(DL/Full)
+
+
(DL/Full) -
+
+
+
-
Table 1.3 Constructeurs de la couche non canonique des formalismes RDFS, OWL et PLIB.
29

reurs dans les donnes. Les formalismes orients infrence se focalisent sur la dfinition des
concepts dfinis (non primitifs). Ils proposent ainsi un ensemble de constructeurs dquivalence
conceptuelle (union, intersection, quivalence, ...) pouvant tre combins pour dfinir les nouvelles classes et pour raisonner sur ces diffrentes classes. Certains formalismes noffrent pas
de constructeur dontologies de la couche non canonique (OCNC). Nous pouvons citer le cas
de RDFS qui noffre pas constructeur de la couche non canoniques (Tableau 1.3).
4 Ontologies vs. Modles Conceptuels

Les ontologies prsentent des similitudes avec les modles conceptuels classiques sur le
principe de la modlisation car tous deux dfinissent une conceptualisation de lunivers du discours au moyen dun ensemble de classes auxquelles sont associes des proprits [41]. Les
ontologies et les modles conceptuels divergent cependant sur un point essentiel : lobjectif
de modlisation qui est lorigine de la contribution dune ontologie dans une dmarche de
modlisation conceptuelle. Une ontologie est ainsi construite selon une approche descriptive,
par opposition un modle conceptuel qui est construit selon une approche prescriptive. Une
approche prescriptive a les implications suivantes [42]:
seules les donnes pertinentes pour lapplication cible sont dcrites ;
les donnes doivent respecter les dfinitions et contraintes dfinies dans le modle conceptuel ;
aucun fait nest inconnu : cest lhypothse du monde ferm ;
la conceptualisation est faite selon le point de vue des concepteurs et avec leurs conventions ;
le modle conceptuel est optimis pour lapplication cible.
Ces caractristiques, dues au fait quun modle conceptuel dpend fortement du contexte
dans lequel il a t conu, sont lorigine des htrognits identifies lors de lintgration
et de lchange de donnes issues de sources htrognes [43]. Contrairement un modle
conceptuel qui prescrit une base de donnes selon des besoins applicatifs (orients application),
une ontologie est dveloppe selon une approche descriptive (oriente domaine). Elle permet de
dcrire les concepts et proprits dun domaine donn indpendamment de tout objectif applicatif et de tout contexte hormis le domaine sur lequel porte lontologie. En plus de la capacit
de conceptualisation, les ontologies apportent dautres dimensions que nous avons cites dans
les sections prcdentes : identification des concepts, la consensualit et le raisonnement.
Identification des concepts : les concepts dans une ontologie possdent des identificateurs universels (par exemple, un URI) leur permettant dtre rfrencs par des applications externes.
Consensualit : laspect consensuel des ontologies facilite la tche des concepteurs qui
travaillent sur divers projets rfrenant les mmes ontologies et qui souhaitent partager
et changer des donnes sur leurs modles.
30
5. Base de Donnes Base Ontologique

Raisonnement : les ontologies, de par leur aspect formel, offrent des mcanismes de raisonnement permettant de vrifier la consistance des informations et dinfrer de nouvelles
donnes.
A la lumire de ces diffrences, il est par consquent intressant de considrer une ontologie comme un premier niveau de spcification dun modle conceptuel. Nous citons comme
exemple les trois travaux suivants proposs par Roldan-Garcia et al. [44], Sugumaran et al. [45]
et Fankam et al. [42] qui permettent de dfinir le modle conceptuel dune base de donnes
partir dune ontologie suppose prexistante.
Ayant prsent les concepts fondamentaux lis aux ontologies et leurs modles, dans la
section suivante, nous introduisons la notion de base de donnes base ontologique, leurs modles de stockage et architectures afin de rpondre aux deux dernires questions que nous avons
poses dans lintroduction.
5 Base de Donnes Base Ontologique

Dans de nombreux domaines, les ontologies sont utilises pour expliciter la smantique des
donnes manipules dans une application. La forte volumtrie des donnes dcrites par des
ontologies a entran le problme de passage lchelle. En consquence, un nouveau type de
base de donnes a t cr, appel Bases de Donnes Base Ontologique (BDBO). Dans cette
section, nous dtaillons ce type de base de donnes et leur diversit.
Dfinition 1
On appelle base de donnes base ontologique (appele galement base de donnes smantique) une source de donnes qui contient des ontologies, un ensemble de donnes et
des liens entre ces donnes et les lments ontologiques qui en dfinissent le sens [46, 9].
Les donnes (instances) contenues dans une BDBO sont appeles des donnes (instances)
base ontologique.
Figure 1.5 Base de donnes base ontologique

Une BDBO possde deux caractristiques illustres dans la figure 1.5 :
31

les ontologies et les donnes sont toutes deux, reprsentes dans une unique base de donnes et peuvent faire lobjet des mmes traitements (insertion, mise jour, interrogation,
etc.) ;
toute donne est associe un lment ontologique qui en dfinit le sens et vice versa.
Plusieurs BDBO acadmiques et industrielles sont proposes dans la littrature parmi lesquelles on peut citer : RDFSuite [5], Jena [7, 47], Sesame [48], OntoDB [9], OntoMS [49],
DLDB [8], RStar [50], KAON [51], 3Store [52] et PARKA [53], Oracle Semantic [54, 55],
IBM Sor [56], etc.
En examinant ces BDBO nous avons identifi une grande diversit concernant les lments
suivants :
le modle dontologies support ;
le schma de base de donnes (modle de stockage) utilis pour stocker des ontologies ;
le schma de base de donnes utilis pour reprsenter les donnes base ontologique
(instances) ;
les architectures utilises pour reprsenter lensemble des informations.
Nous dtaillons dans ce qui suit les modles de stockage et les architectures des BDBO.
5.1 Modle de stockage traditionnel ou autres modles pour les BDBO?

On peut remarquer dans la dfinition dune BDBO, que lon a dune part lontologie et
dautre part les donnes ontologiques (instances). Il est ainsi ncessaire de dfinir un schma
de tables pour le stockage de chaque partie et de dfinir un mcanisme liant les instances aux
lments de lontologie. Pour le stockage, le schma dontologie et les instances ontologiques
peuvent tre stocks conjointement en utilisant le mme modle de stockage ou sparment en
utilisant des modles de stockage diffrents. Les diffrents modles de stockage des ontologies
et ceux de reprsentation des donnes base ontologiques sont prsents ci-dessous.
5.1.1
Modle de stockage des ontologies
Le problme de reprsentation des ontologies dans une base de donnes consiste dfinir
lensemble des tables ncessaires pour stocker les concepts ontologique et leurs relations. Dans
la littrature, deux approches principales ont t proposes : la reprsentation gnrique et la
reprsentation spcifique.
5.1.1.1 Reprsentation gnrique. Cette reprsentation appele aussi reprsentation verticale utilise une unique table trois colonnes (sujet, prdicat, objet) dite table de triplets pour
stocker lontologie. Cette reprsentation est gnrique par rapport au modle dontologie. En
effet, lontologie est donc dcompose en un ensemble de triplets. Chaque lment E dune
ontologie est dfini par des triplets de lune des formes suivantes :
32

O
n
t
o
l
o
g
i
e
I
n
s
t
a
n
c
e
s
personne
subclassof
DiplomDe
Universit
Lgende :
ID3
sousOrganisationDe
Dpartement
sousOrganisationDe
ID2
membreDe
Etudiant
membreDe
ID1
subclassof
Salari
ID4
DiplomDe
Classe ou
instance
type
Valeur de proprit
Proprit
Figure 1.6 Fragment de lontologie LUBM

la forme (E, rdf:type, entit) : ces triplets permettent dindiquer le type de llment.
Ce type est une des entits dfinies en RDF-Schma comme par exemple rdfs:Class ou
rdfs:Property ;
la forme (E, attribut, valeur) : ces triplets permettent de caractriser les lments dfinis
en leur assignant des valeurs dattributs RDF-Schma comme par exemple rdf:label ou
rdf:comment.
Exemple 1
Soit le fragment de lontologie LUBM prsent sur la figure 1.6. Sa reprsentation gnrique
est prsente sur la figure 1.7.
5.1.1.2 Reprsentation spcifique. Cette reprsentation dpend du modle dontologies

support. Elle consiste reprsenter le modle dontologies en utilisant le modle relationnel ou relationnel-objet support par le SGBD sous-jacent la BDBO. Le schma de tables
est dfini de faon ad hoc (non systmatique) dune implmentation une autre. Il est fonction
des dtails des informations quon veut capturer et du lien tabli avec la partie concernant les
donnes. Chaque BDBO dfinit son propre schma en fonction des concepts du modle dontologies quelle supporte. Pour une ontologie RDFS, le schma contient gnralement les tables ;
class, subclass, domain, range, property, subproperty.
Cette reprsentation est adopte par les BDBO Sesame, RDFSuite, RSTAR, OntoDB, OntoMS, DLDB, PARKA et KAON. La reprsentation spcifique de notre fragment dontologie
de la figure 1.6 est illustre par la figure 1.8
Dans cet exemple, la reprsentation comporte les tables Class, Property et Subclass. La table
Class stocke les classes des ontologies. Elle est compose dune colonne URI permettant de sto33
Triplet
sujet
prdicat
objet
http://lias.fr#Universit
rdf:type
rdfs:Class
http://lias.fr#Dpartement
rdf:type
rdfs:Class
http://lias.fr#Personne
rdf:type
rdfs:Class
http://lias.fr#Etudiant
rdf:type
rdfs:Class
http://lias.fr#Salari
rdf:type
rdfs:Class
http://lias.fr# Salari
rdfs:suclassOf http://lias.fr#Personne
rdfs:suclassOf http://lias.fr#Personne
http://lias.fr#estMembreDe
rdf:type
rdf:Property
rdfs:domain
rdfs:range
http://lias.fr#sousOrganisation
De
http://lias.fr# Universit
rdf:type
rdf:Property
rdfs:comment
Cest une universit de ...
Figure 1.7 Reprsentation gnrique du fragment dontologie LUBM
Class
SubClassOf
Id
URI
label
comment
sub
sup
Universit
Cest une universit de ...
Dpartement
http://lias.fr#Personne
Personne
Etudiant
Salari
Property
id
URI
comment
11
appartenance
12
http://lias.fr#sousOrganisationDe
Sous-organe
...
domain
range
Figure 1.8 Reprsentation spcifique du fragment dontologie LUBM
34

cker lidentifiant externe dune classe. Afin doptimiser les traitements, un identifiant interne
la base de donnes (id) est galement associ aux classes. Cette table permet galement de stocker les noms (label) associs aux classes. Notons que si nous souhaitons associer plusieurs
noms et/ou plusieurs commentaires une mme classe, la normalisation de cette table ncessite de dfinir deux nouvelles tables pour stocker ces informations. La table Property stocke
les proprits. Comme les classes, les proprits sont associes un identifiant interne (id) et
externe (URI) et des noms (label) et des commentaires (comment). Le domaine (domain) et
co-domaine (range) des proprits sont galement spcifis dans cette table par de rfrences
aux classes. La table SubClassOf permet de stocker la hirarchie des classes en indiquant pour
chaque classe ses superclasses.
5.1.2
Modle de stockage des instances ontologiques
Trois principales approches sont utilises pour la reprsentation des instances ontologiques
au sein des BDBO [57] : approche verticale, approche binaire et approche horizontale. Ces
trois approches sont prsentes dans les paragraphes suivants.
5.1.2.1 Approche verticale. Cette approche consiste reprsenter lontologie et ses instances par une table trois colonnes. Ces colonnes reprsentent respectivement : (1) lidentifiant de la ressource ontologique (classe, proprit ou instance ontologique), (2) le nom de la
ressource, et (3) la valeur de cette ressource. Dans cette reprsentation, chaque instance i dune
classe est dfinie par les triplets suivants :
les triplets (i, rdf:type, C) qui permettent dindiquer les classes auxquelles linstance i
appartient ;
les triplets (i, prdicat, valeur) qui permettent de caractriser linstance en lui assignant
des valeurs de proprits.
Cette reprsentation est simple et indpendante de lontologie utilise. Elle facilite linsertion de nouveaux triplets. La mise jour dune information peut ncessiter la modification de
plusieurs triplets. Linterrogation est souvent complexe car elle peut ncessiter plusieurs oprations dauto-jointure. La BDBO Sesame et celle dOracle utilise cette reprsentation pour la
reprsentation des instances ontologiques.
Une variante de cette reprsentation appele approche verticale avec ID consiste utiliser
des tables dictionnaires, cest--dire des tables stockant les identifiants et leurs valeurs littrales.
Une table dictionnaire est prvue pour des ressources et une autre pour les littraux. La table de
triplets utilise les identifiants des ressources et des littraux rfrencs dans les tables dictionnaire. La reprsentation verticale des instances de notre fragment dontologie de la figure 1.6
est prsente sur la figure 1.9. Sa variante avec ID est prsente sur la figure 1.10
35
Triplet
sujet
prdicat
objet
http://lias.fr#ID1
rdf:type
http://lias.fr# Etudiant
http://lias.fr#ID2
rdf:type
http://lias.fr#ID3
rdf:type
http://lias.fr#ID4
rdf:type
http://lias.fr#ID1
http://lias.fr#ID2
http://lias.fr#ID2
http://lias.fr#sousOrganisationDe
http://lias.fr#ID3
http://lias.fr# ID3
rdfs:comment
Universit de Poitiers
http://lias.fr# ID1
http://lias.fr#diplomDe
http://lias.fr# ID3
Figure 1.9 Reprsentation verticale des instances du fragment dontologie LUBM
Litteral
Ressource
ID
URI
ID
URI
C1
C1
C2
C2
C3
C3
P1
C4
P2
P0
rdf:type
L1
Universit of Poitiers ....
P1
..
P2
P3
http://lias.fr#diplomDe
P4
rdfs:comment
I1
http://lias.fr#ID1
I2
http://lias.fr#ID2
I3
http://lias.fr#ID3
I4
http://lias.fr#ID4
sujet
I1
I
I3
I4
I1
I2
I3
I1
Triplet
prdicat
P0
P0
P0
P0
P1
P2
P4
P3
objet
C3
C2
C1
C4
I2
I3
L1
I3
Figure 1.10 Reprsentation verticale avec ID des instances du fragment dontologie LUBM
36

5.1.2.2 Approche binaire. Cette reprsentation consiste dcomposer les relations en deux
catgories : les relations unaires (pour lappartenance aux classes), et les relations binaires (pour
les valeurs de proprits). Lapproche binaire se dcline en trois variantes selon lapproche
adopte pour la reprsentation de lhritage :
1. une table unique pour toutes les classes de lontologie. Cette table est constitue de deux
colonnes (Uri, ClassID) : la colonne Uri dsigne lidentifiant des instances et la colonne
classId reprsente lidentifiant de la classe stocke dans lontologie ;
2. une table par classe avec hritage de table (si une base de donnes relationnelle-objet
est utilise). Cette reprsentation est appele ISA [58]. Elle associe chaque classe et
proprits stockes dans la partie ontologie une table spcifique pour leurs instances respectives. Les proprits des superclasses sont reprises dans les sous-classes. Les tables
de classes sont unaires tandis que les tables de proprits sont binaires. Elles sont constitues de la colonne id pour les identifiants dune instance et de la colonne value pour les
valeurs de cette instance. Cette solution profite des fonctionnalits de SQL99 pour les requtes hirarchiques mais les mises jour sont difficile gres. Par exemple, linsertion
dune classe entre deux classes demande de supprimer des tables puis de les remettre en
relation ;
3. une table par classe sans hritage de table. Cette variante, appele NOISA [58], nutilise
pas lhritage des tables offert par les SGBD relationnels objets. Les tables des proprits
et des classes sont dfinies sparment sans mises en relation. Les requtes polymorphes
ncessitent donc un accs lontologie pour rcuprer leurs classes et leurs proprits.
Cette variante entrane de mauvaises performances pour les requtes polymorphes car les
calculs de sous-classes et des sous-proprits sont rcursifs et par consquent coteux [4].
La figure 1.11 illustre ces approches. La BDBO dIBM SOR utilise cette approche binaire
pour la reprsentation des ontologies et de leurs instances [59].
Cette approche a lavantage dtre efficace en temps de rponse pour des requtes simples.
Cependant des requtes complexes peuvent ncessiter plusieurs oprations de jointures [4].
Cette approche est utilise par Sesame, RDF-Suite, DLDB et PARKA.
5.1.2.3 Approche horizontale. Cette approche est similaire la reprsentation traditionnelle utilise par les SGBD relationnels. Elle consiste stocker toutes les instances des classes
ainsi que leurs valeurs de proprits dans une seule table relationnelle. Lidentifiant dinstance,
le nom de la classe et toutes ses proprits sont stocks dans une entre de cette table.
Cette approche est illustre sur la figure 1.12. Cette approche est simple mais prsente des
inconvnients qui sont :
le grand nombre de colonnes pour la table ;
le nombre de valeurs de proprit limit un ;
le grand nombre de champs nuls ;
37

Classes
Personne
ClassID
URI
C1
Universit
C2
Dpartement
C3
Etudiant
C4
Salarie
C5
Personne
..
Table Unique
Salari
ID4
Departement
ID2
Etudiant
ID1
Universit
ID3
Universit
ID3
Salari
ID4
ISA
Classes
Departement
ID2
Etudiant
ID1
NOISA
Proprits
SousOrganisationDe
sujet
objet
ID2
ID3
estMembreDe
sujet
objet
ID1
ID2
..
diplomDe
sujet
objet
ID1
ID3
sujet
ID1
ID2
ID3
ID4
Type
objet
Etudiant
Dpartement
Universit
Salari
Figure 1.11 Reprsentation binaire des instances du fragment dontologie LUBM

la maintenance difficile : toute modification de lontologie entraine la restructuration de
la table.
TableHorizontaleUnique
ID
Type
estMembre
http://lias.fr#ID1
Etudiant
ID2
http://lias.fr#ID2
Departement
http://lias.fr#ID3
Universit
http://lias.fr#ID4
Salari
....
sousOrganisationDe diplomDe
ID3
ID3
Figure 1.12 Table horizontale unique des instances du fragment dontologie LUBM
Une variante de cette approche consiste utiliser une table pour chaque classe (Fig. 1.13).
A chaque classe ontologique est associe une table ayant une colonne pour chaque proprit
utilise (une valeur associe) pour dcrire au moins une instance de cette classe. Les BDBO
OntoDB et OntoMS utilisent cette approche.
Lapproche horizontale conserve la notion de schma des donnes. Dans cette reprsentation, les tables utilises reprsentent explicitement la structure des donnes. Cet aspect permet
de faciliter lintgration automatique des bases de donnes en utilisant cette BDBO [60]. Cette
approche aide rsoudre des problmes de conception de modles conceptuels ou dindexation
smantique de bases de donnes [61]. Cette variante est galement efficace pour les requtes
portant sur les proprits dun individu ou dun ensemble dindividus. Mais elle prsente certains inconvnients de lapproche initiale comme les valeurs nulles car certains individus nont
pas certaines proprits.
38

Etudiant
Universit
ID
estMembre
diplomDe
ID
comment
ID1
ID2
ID3
ID3
Universit de Poitiers
Departement
ID
sousOrganisationDe
ID2
ID
Salari
ID
ID4
Personne
ID
Figure 1.13 Reprsentation horizontale des instances du fragment dontologie LUBM

NB : Il existe des BDBO qui combinent ces approches, dans ce cas on parle dapproche
hybride.
Nous venons de voir les diffrentes approches de reprsentation des ontologies et des instances ontologiques dans des bases de donnes. Dans la section suivante, nous prsentons les
diffrentes architectures des BDBO.
5.2 Architecture traditionnelle ou dautres architectures pour le SGBD

cible des BDBO?
La prsence dune ontologie au sein du SGBD a permis de mettre en cause larchitecture
initiale dun SGBD contenant deux parties: le contenu et la mta-base. Deux tendances architecturales ont t identifies: (i) garder larchitecture initiale dun SGBD et (ii) faire voluer cette
dernire pour mieux prendre en compte la prsence de lontologie. Dans les sections suivantes,
nous dtaillons ces deux tendances.
5.2.1
Garder lexistant
Les premires propositions de BDBO ont stock les ontologies et leurs instances dune
faon similaire aux bases de donnes classiques en utilisant deux parties : les donnes et la
mta-base aussi appele catalogue du systme. Nous appelons cette architecture, architecture
de type I ou architecture "deux quarts". La partie "donnes" dans cette structure reprsente les
instances ontologiques (instances de classes de lontologie et les valeurs de proprits ontologiques) mais galement le schma de lontologie (classes, proprits, etc.). La partie "mtabase" est la composante traditionnelle des bases de donnes classiques. Elle contient lensemble
des tables systmes permettant la gestion et le bon fonctionnement de lensemble des donnes
contenues dans la base de donnes. Elle sert aussi de dictionnaire qui dcrit les diffrents objets du systme. Par exemple lorsquune table est cre, le catalogue enregistre sa structure
et notamment ses colonnes avec leurs types de donnes, ses diffrentes contraintes, etc. Dans
une BDBO, toutes les tables et les attributs dfinis sont documents dans la mta-base. Cette
architecture, prsente sur la figure 1.14, impose ainsi le mme modle de stockage pour lon39
BDBO I
Meta_table
ID
nom
#1
Triplet
Catalogue
systme
1
Meta_colonne
ID
#1
nom
sujet
.
.
#2
prdicat
Donnes/ Ontologie
Triplet
sujet
prdicat
Objet
Etudiant
Type
Class
Etudiant
subClass
Personne
ID1
type
Etudiant
ID1
nom
Bery
Figure 1.14 Architecture deux quarts

tologie et pour les instances ontologiques. Jena et Oracle utilisent une architecture de ce type
pour stocker les donnes (ontologie et instances) sous forme de triplets RDF (approche verticale). Cette architecture prsente lavantage dtre simple mettre en uvre. Les insertions
des donnes sont faciles. Cependant elle prsente linconvnient de tout stocker dans une seule
table (modle et instances) et ainsi les requtes sexpriment en auto-jointures sur cette table
volumineuse.
5.2.2
Faire voluer larchitecture traditionnelle
Pour pallier cet inconvnient, une deuxime architecture dite architecture de type II ou architecture "trois quarts" (figure 1.15) a t propose. Les instances ontologiques et lontologie
sont stockes dans deux schmas diffrents. Cette nouvelle architecture scinde la base de donnes en trois parties : catalogue systme, schma du modle ontologique, schma des instances
ontologiques. Les parties "donne" et "catalogue systme" jouent les mmes rles que prcdemment. Le schma du modle ontologique est ddi au niveau ontologique. Il dpend du
modle dontologie utilis (OWL, PLIB, RDFS, etc.). Il est compos de table(s) fige(s) pour
le stockage des diffrents concepts ontologiques tels que les classes, les proprits ou les relations de subsomption (sous-classes), etc. IBM SOR [59] est un exemple de BDBO suivant cette
deuxime architecture.
Mme si les deux schmas de stockage (modle et instances) sont indpendants, cette architecture manque de flexibilit dans la mesure o elle impose un modle dontologie fig, ce
qui ne permet pas dintroduire de nouveaux concepts issus dautres modles dontologies. Une
troisime architecture visant combler cette insuffisance a t propose. Cette troisime ar40
BDBO II
Mta_table
ID
nom
#1
Triplet
#2
Classe
Ontologie
Mta_colonne
Catalogue
systme
1
3
ID
#1
nom
sujet
.
.
#2
prdicat
Donnes
Classe
Triplet
ID
nom
sujet
prdicat
objet
#1
Etudiant
#1
nom
Bery
#2
Personne
#1
type
Etudiant
Figure 1.15 Architecture trois quarts
chitecture qualifie de type III (ou architecture "quatre quarts") a t propose dans le cadre
du projet OntoDB (OntoDB1 et OntoDB2) visant rpondre au besoin de flexibilit du modle dontologie utilis dans la BDBO. Cette architecture propose, en plus des trois parties,
une partie nomme mta-schma qui joue, pour les ontologies, le mme rle que celui jou
par le systme catalogue pour les donnes. Le mta-schma appel mta-modle reprsente, au
sein dun modle rflexif, la fois le modle dontologie utilis et le mta-schma lui-mme.
Les modles dontologies sont reprsents comme des instances du mta-modle. Cette partie mta-schma permet un accs gnrique au modle ontologique ainsi que lintroduction de
nouveaux constructeurs issus de diffrents formalismes ontologiques. La figure 1.16 prsente
un schma de donnes de la partie mta-schma et de la partie ontologie de notre fragment dontologie LUBM. Cette architecture a t conue de manire ce quelle soit extensible afin de
pouvoir y reprsenter dautres modles dontologies et ce grce sa partie mta-schma. Cela
donne la possibilit dtendre le schma de lontologie pour reprsenter les nouveaux concepts
non supports par les modles dontologies existants. Le schma de donnes de cette dernire
tant susceptible dvoluer ou dtre modifi ; lauto-reprsentation du mta-modle du modle
dontologie permet de rendre certains traitements gnriques et/ou indpendamment du modle
dontologie utilis.
A titre dillustration, Belaid et al. [62] ont propos dtendre le modle OntoDB pour la
reprsentation de services informatiques et des concepts dontologies de services qui en dfinissent le sens. Khouri et al. [63] ont opt pour une telle architecture pour la reprsentation de
la structure dentrept de donnes intgrant le modle des besoins. Cette vision qui permet de
voir lvolution des BDBO en termes de schmas de stockage et darchitectures est illustre
dans la figure 1.17.
Nous pouvons constater que cette architecture ressemble larchitecture mta-donnes du
41
Entit
Type
ID
E#1
Nom
Ressource
SuperEntiit
E#2
Class
E#1
E#3
Property
E#1
E#4
ObjectProperty
E#3
E#5
Data_property
E#1
ID
Nom
Class
Proprits
C#1
Universit
{D#1}
C#2
Departement
{O#2}
C#3
Etudiant
ID
T#1
T#2
T#3
Nom
String
E#2
E#3
Mta-schma
ID
Nom
Attribut
Domaine
Co-domaine
A#1
name
E#1
T#1
A#2
Domain
E#1
T#1
A#3
Range
T#1
E#1
Ontologie
{O#1, O#3, D#1, D#2, ..}
Data_Property
ID
Object_Property
Nom
Domain
range
O#1
estMembreDe
O#2
C#3
sousOrganisationDe
C#2
C#4
Salari
{O#1, D#1, D#2, }
O#3
diplomDe
C#2
E#5
Personne
{D#1, D#2}
ID
Nom
Range
C#2
D#1
nom
Strin g
C#1
D #2
Age
Int
C#1
Figure 1.16 Mta-schma et ontologie
BDBO III
Mta-schma
Catalogue systme
Mta_table
Entit
ID
nom
#1
Classe
#2
Proprit
ID
#1
#2
ID
#1
#2
nom
nom
inscrit
Proprit
Domaine
Personne
Etudiant
nom
sujet
prdicat
Donnes
Classe
nom
Etudiant
Personne
.
.
Mta_colonne
ID
#1
#2
Ontologie 3
ID
#1
#2
nom
Triplet
Classe
.
.
Triplet
.
Co-domaine
String
Universit
sujet
prdicat
objet
#1
name
Bery
#1
type
Etudiant
Figure 1.17 Architecture quatre quarts.
42
BDBO
Type 2
DAML
PLIB
OWL
RDFS
Type 1
Vertical
binaire
horizontal
Modle de stockage
FFoor
rmm
aal lis
is m
me
e
Architecture
Architecture
Type 3
dimensions
Figure 1.18 Reprsentation multidimensionnelle des BDBO.

MOF (Meta Object Facility) [64]. En effet, cette architecture est constitue des mmes quatre
couches superposes comme celles du MOF. La couche modle M1 de larchitecture MOF
correspond au modle conceptuel, un sous-ensemble de lontologie. Cette couche contient la
couche M0 reprsentant les instances (les donnes dans larchitecture de type III). La couche
mta-modle M2 correspond au (mta-) modle dontologie, la couche mta-mta-modle M3
(MOF model) correspond au mta-modle, lui-mme rflexif, du langage de dfinition du modle dontologie.
5.2.3
Cube de BDBO
En considrant les trois principaux points de la diversit des BDBO identifie prcdemment, nous pouvons reprsenter lespace des BDBO par un cube dont les axes sont respectivement les modles de stockage, les architectures et les formalismes dontologies. Les points dans
cet espace cest--dire les cellules du cube, sont les types 9 de BDBO. La figure 1.18 donne une
reprsentation de cet espace. Toute BDBO peut tre classe dans une cellule de ce cube. Par
exemple, la BDBO Oracle est classe dans la cellule de coordonnes (vertical, type 1, RDFS) 10
et la BDBO OntoDB dans la cellule (horizontale, type 3, PLIB) comme on peut le voir sur la
figure 1.19.
5.2.4
Synthse
Ltude faite dans ce chapitre montre que contrairement aux bases de donnes relationnelles qui sont toutes similaires en termes darchitecture et de modle de stockage, les BDBO
prsentent une grande diversit. Le tableau 1.4, propose une classification dirige par les ar9. A ne pas confondre avec le type darchitecture
10. Oracle est galement class dans dautres cellules car il supporte plusieurs modles dontologies
43
Figure 1.19 Exemple de BDBO dans lespace de BDBO.

chitectures pour des exemples de BDBO couramment utilises. On voit que la majorit de ces
BDBO utilisent larchitecture deux quarts ou trois quarts (architecture de type1 ou de type2).
OntoDB est la seule BDBO qui utilise larchitecture quatre quarts et propose ses utilisateurs
une possibilit dextension du modle dontologie.
BDBO
Oracle
Jena
OntoDB
OntoMS
RDFSuite
Sesame
SOR
3Store
RDFDB
DLDB
DB2RDF
T ype1
T ype2
T ype3
Table 1.4 Classification des BDBO selon leur architecture
6 Langage de requtes des BDBO

Les donnes base ontologique stockes dans une base de donnes sont susceptibles dtre
sujettes des consultations, des mises jour ou des suppressions. Ces actions ncessitent un
langage de manipulation (langage de requtes). Chaque BDBO prvoit au moins un langage de
44
6. Langage de requtes des BDBO

ce type. Comme dans les bases de donnes classiques, les utilisateurs qui veulent interroger des
donnes ne doivent pas se proccuper du modle de stockage et des dtails de mise en uvre.
6.1 Principaux langages proposs

Plusieurs langages dinterrogation ont t proposs pour les donnes ontologiques. Bailey
et al. [65] ont tabli un tat de lart o ils ont class ces langages en sept catgories qui se
distinguent par le modle de donne support, leur expressivit et le support du schma dinformation: famille de SPARQL, famille de RQL, langages inspirs de XPath, XSLT ou XQuery,
langages en anglais contrl, langages avec rgles ractives, langages dductifs et autres langages.
La famille de SPARQL regroupe les langages qui traitent des triplets. Ces langages permettent dinterroger des donnes RDF sans tenir compte de la smantique associe aux lments
des triplets. On retrouve dans cette catgories les langages SPARQL [14], RDQL [10], SquishQL [13], TriQL [66], etc. Le langage SPARQL, bien adapt linterrogation de donnes RDF
et adopt par plusieurs BDBO, a t retenu comme le standard pour les requtes smantiques
par le W3C. Il est trs utilis dans de nombreux travaux dans le domaine du Web Smantique.
Nous le prsenterons un peu plus en dtail dans la section 6.2.
La famille RQL regroupe les langages qui prennent en compte les donnes et le schma
dontologie dans des interrogations. Le modle de donnes RDF quils supportent impose deux
contraintes majeures : (1) les cycles sont interdits dans la relation de subsomption, et (2) pour
chaque proprit, le domaine et le co-domaine doivent tre dfinis. Cette famille regroupe les
langages RQL[12], eRQL[67], SeRQL [11], OntoQL [15].
La famille des langages inspirs de XPath, XSLT ou XQuery regroupe des langages qui
tendent un langage de requte XML. Certains sont mis en uvre en ajoutant des fonctions
supplmentaires ou en normalisant les donnes avant linterrogation. On peut citer XQuery for
RDF [68], XSLT for RDF [69], Versa [70], Path-Based Access to RDF (RDF Path, RPath [71],
RxPath, RxSLT, et RxUpdate), etc.
La famille de langages en anglais contrl fait rfrence Metalog [72], un systme pour
linterrogation et le raisonnement dans le Web Smantique. Metalog diffre notablement des
autres langages de requtes RDF par deux points: (1) Metalog combine linterrogation et le
raisonnement, et (2) la syntaxe du langage est en langage naturel (anglais).
Dans la famille de langages avec rgles ractives, on trouve Algae [73], iTQL et WQL. Ces
langages offrent des possibilits de dfinir dans des requtes des rgles de vrification.
La famille des langages dductifs renferme des langages bass sur un langage de rgles de
dduction et de transformation pour RDF. On trouve dans cette famille N3QL [74], R-DEVICE
[75], TRIPLE [76], etc.
La famille "autres langages RDF" regroupe les langages de requtes RDF qui ne font partie
45

daucune des familles prcites. On y rencontre RDF-QBE [77], RDFQL [78], etc.
Dans ce paragraphe, nous avons prsent les principales familles de langages de requtes
des donnes RDF. Dans les paragraphes suivants, nous prsentons le langage SPARQL et le
langage OntoQL que nous avons utiliss dans nos travaux.
6.2 Prsentation du langage SPARQL

SPARQL [14] est un langage de requtes pour des donnes reprsentes en RDF. Les requtes SPARQL sont nonces dans des patrons de graphes lmentaires qui servent de
motifs de recherche des triplets de forme (sujet, prdicat, objet). SPARQL est donc capable
de rechercher des patrons de graphe (graph patterns) obligatoires et optionnels ainsi que leurs
conjonctions et leurs disjonctions. Les rsultats des interrogations SPARQL peuvent tre des
ensembles de rsultats ou des graphes RDF.
SPARQL propose quatre types de requtes :
les requtes SELECT permettent dextraire des informations dune BDBO ou dune source
de donnes RDF interroge ;
les requtes CONSTRUCT permettent de crer de nouveaux triplets partir du rsultat dune
requte ;
les requtes DESCRIBE permettent dobtenir la description dune ressource donne. Les
spcifications de SPARQL ne prcisent pas la nature de la description dune ressource.
Elles imposent seulement que cette description soit un sous-ensemble du graphe interrog ;
les requtes ASK retournent un boolen indiquant si la requte une solution ou nen a
pas.
Les requtes de type UPDATE sont ralises grce au langage SPARQL UPDATE (SPARUL
[79]). Ce dernier utilise une syntaxe drive de SPARQL. Les oprations de mise jour portent
sur de collections de graphes dans un ensemble de donnes RDF. Ces oprations permettent de
mettre jour, de crer et de supprimer des sous-graphes RDF.
Nous prsentons ci-dessous les requtes de type SELECT qui nous intressent dans la suite
de ces travaux.
6.2.1
Requte SELECT.
La structure dune requte SPARQL de type SELECT est similaire celle du langage SQL.
Elle se prsente sous la forme gnrale 11 suivante :
11. Nous nindiquons ici que les principales clauses dune requte SPARQL.
46

PREFIX namespacesList
SELECT
liste_variables_exportes
[FROM
URL_sources_Donnes ]
WHERE {
triple_pattern1
triple_pattern2
...
triple_patternn
}
[Filter FilterExpression]
[modificateurs de solutions]
= patron de requte
La clause PREFIX permet dindiquer des alias sur les espaces de noms utiliss dans la requte.
Un espace de nom (namespace) indique lURI de lontologie utilise. La clause FROM permet
dindiquer la ou les sources RDF interroges. Cette clause est optionnelle. Si elle nest pas spcifie, lenvironnement dans lequel la requte est excute est charg de fournir la source de
triplets. Par exemple, lorsquune requte SPARQL est excute sur une BDBO, les donnes
RDF interroges sont celles contenues dans la BDBO. La clause WHERE est constitue dun ensemble de triplets pouvant contenir des variables (prfixes par ?). Un interprteur de requtes
SPARQL recherche les valeurs de ces variables pour lesquelles les triplets de la clause WHERE
sont inclus dans le graphe RDF interrog. Il retourne le sous-ensemble de ces valeurs correspondant aux variables spcifies (liste_variables_exportes ) dans la clause SELECT. SPARQL
permet dindiquer des conditions sur les variables utilises dans la requte. Ces conditions sont
dfinies grce loprateur FILTER. Cet oprateur prend en paramtre une expression boolenne. Ce rsultat peut tre modifi en spcifiant des modificateurs de squence de solution
(order by, distinct, reduced, offset, limit, ...) .
Exemple 2
La requte suivante retourne la valeur des proprits name et age pour les ressources de
type Etudiant dcrites par ces proprits. Les rsultats seront tris par ordre croissant sur
les noms.
PREFIX lias: <http://www.ensma.fr/lias#>
SELECT ?name ?age
WHERE {
?x rdf:type lias:Etudiant.
?x lias:name ?name .
?x lias:age ?age }
ORDER BY ASC(?name)
47

Dans cette requte, la variable ?x est introduite dans deux triplets de la clause WHERE. Cette
variable reprsente les ressources RDF prsentant une valeur pour les proprits name et email
dfinies sur lontologie dont lespace de nom est http://www.ensma.fr/lias. La clause
SELECT indique que cette requte retourne les noms (?name) et age (?age) de triplets obtenus
comme rsultats de la requte et la clause ORDER BY indique que les rsultats seront donns par
ordre alphabtique croissant sur les noms (ASC(?name)).
SPARQL dispose galement de loprateur OPTIONAL qui permet dindiquer que des triplets
sont optionnels dans la clause WHERE. Par consquence, des rsultats ne satisfaisant pas les triplets optionnels seront quand mme retourns. Cependant, lorsquune variable utilise uniquement dans des triplets optionnels na pas daffectation correspondant aux donnes interroges,
la valeur UNBOUND est retourne. Par exemple, si nous modifions la requte de notre exemple 2
en ajoutant le patron de triplet optionnel (?x lias:email ?email), (cest--dire OPTIONAL
{ ?x lias:email ?email }), les ressources ne prsentant pas les valeurs pour la proprit
email seront quand mme retournes avec la valeur UNBOUND pour la variable ?email.
SPARQL offre galement loprateur UNION pour joindre deux ensembles de triplets dans
la clause WHERE. Pour une requte o deux ensembles de triplets sont lis par cet oprateur, un
rsultat est retourn ds lors quil permet de satisfaire lun des deux ensembles de triplets.
6.2.2
Traitement dune requte SPARQL
Lexcution dune requte SPARQL passe par une srie dtapes parmi lesquelles on a :
1. le parsing de la requte SPARQL en un arbre de syntaxe abstrait (AST Abstract Syntax
Tree)
2. la conversion de larbre de syntaxe abstrait en une requte abstraite (cest--dire, une
expression algbrique)
3. lvaluation de la requte abstraite sur un ensemble de donnes RDF.
Le calcul dune requte SPARQL de type SELECT se fait par appariement (graph pattern mapping) de graphe. Cela revient chercher les sous-graphes qui apparient le patron de requte.
Lvaluation porte sur lexpression algbrique de la requte. Or une requte peut avoir plusieurs
expressions algbriques, il est important de choisir celle dont lvaluation est bnfique cest-dire rapide et moins gourmande en ressources (CPU, mmoire). Il revient loptimiseur de
requtes de faire ce travail.
6.3 Prsentation du langage OntoQL

Le langage OntoQL [15], dvelopp au LIAS (Laboratoire dInformatique, dAutomatique
pour les Systmes) est un langage dexploitation des bases de donns base ontologique. Il est
implment sur la BDBO OntoDB. OntoQL permet de dfinir, modifier et interroger les ontologies et les donnes base ontologique suivant les diffrentes couches du modle en oignon
48

prsent prcdemment. En outre, OntoQL permet dinterroger simultanment les ontologies
et les donnes dune BDBO et propose les oprateurs traditionnels des bases de donnes. La
syntaxe du langage OntoQL est proche de celle de SQL dans les diffrentes couches daccs.
6.3.1
Requte SELECT.
La forme gnrale dune requte OntoQL de type SELECT ressemble celle de SQL. Sa
synthse est la suivante :
SELECT
liste_slection
[FROM
Liste_de_Refrence_Donnes ]
[WHERE {
Conditionde_recherche
}
[modificateurs de solutions]
Using NAMESPACE<Liste_namespace_definition>
Using LANGUAGE <LanguageID>
Hormis les clauses Using NAMESPACE et Using LANGUAGE, toutes les clauses de cette
syntaxe sont similaires celles de SQL. La clause SELECT permet de prciser les attributs
du rsultat dune requte, dappeler des fonctions ou des expressions arithmtiques comme
dans SQL. La clause WHERE est optionnelle, et permet de dfinir les conditions de restrictions.
La clause FROM rfrence les objets (par exemple, les classes) sur lesquels porte la requte.
La clause USING NAMESPACE indique que la requte doit tre excute sur des lments
ontologiques appartenant lontologie indique en paramtre. La clause Using LANGUAGE
permet dindiquer la langue naturelle utilise.
Exemple 3
La requte de lexemple 2 est exprime en OntoQL par :

SELECT E.name, E.age
FROM Etudiant E
Using NAMESPACE http://www.these.edu/Ontologies/LumbOntoDB.owl
ORDER BY ASC(E.name)
La requte SELECT de OntoQL permet daccder aux diffrentes parties dune BDBO. Par
exemple, la requte SELECT #namespace FROM #Ontology accde la partie Ontologie et de
rechercher les espaces de noms des ontologies stockes dans cette BDBO.
49

6.3.2
Traitement dune requte OntoQL
Le traitement dune requte OntoQL passe par sept tapes comme indiqu sur la figure 1.20.
Ces tapes sont :
1. gnration de lexpression algbrique OntoAlgebra 12 correspondant la requte OntoQL ;
2. optimisation de lexpression algbrique OntoAlgebra ;
3. transformation de larbre algbrique OntoAlgebra en un arbre algbrique utilisant des
oprateurs de lalgbre relationnelle tendue avec les oprateurs disponibles dans les
SGBD relationnels-objets ;
4. optimisation de lexpression de larbre algbrique relationnel. Cette tape permet de faire
des optimisations qui ne sont pas ralises par le SGBD comme par exemple simplifier
une requte imbrique ;
5. transformation de lexpression de lalgbre relationnelle en une requte SQL conforme
au SGBD sur lequel la BDBO OntoDB est implante (PostgreSQL) ;
6. excution de la requte SQL sur OntoDB en utilisant le JBDC. Le rsultat retourn est
ainsi un ResultSet ;
7. transformation du ResultSet pour retourner le rsultat de la requte OntoQL.

!
#$
" ! %
"#! &
!
#$
" ! %
' "#(!
"& %""

)
* " )
*" )
+,
Figure 1.20 Etapes du traitement dune requte OntoQL (extraite de [28])
7 Conclusion
Dans ce chapitre, nous avons prsent la notion dontologie ainsi que ses caractristiques
principales. Plusieurs dfinitions sont proposes dans la littrature mais celle qui est communment cite est celle de Gruber : an explicit specification of a conceptualization . Plusieurs
extensions de cette dfinition ont t proposes. Nous retenons celle de Pierra [20] qui dcrit une ontologie comme une reprsentation formelle, explicite, rfrenable et consensuelle
de lensemble des concepts partags dun domaine en termes de classes dappartenance et de
12. Algbre Encore adapte aux modles de donnes dune BDBO
50
7. Conclusion
proprits caractristiques. Suivant la nature des concepts utiliss dans lontologie, trois types
dontologies existent : (i) les ontologies conceptuelles canoniques qui ne contiennent que des
concepts primitifs, (ii) les ontologies conceptuelles non canoniques qui en plus des concepts
primitifs, renferment dans leurs dfinitions des concepts dfinis et (iii) les ontologies linguistiques qui visent reprsenter les mots utiliss dans un domaine donn. Elles fournissent une
reprsentation en langage naturel des concepts dun domaine. Les reprsentations peuvent tre
multilingues. Pour construire des ontologies, on fait appel des formalismes comme RDFS
et PLIB souvent utiliss dans le domaine de lIngnierie (ils sont orients vers la gestion et
lchange des donnes), DAMLONT, DAML+OIL, FLogic et OWL dans le domaine de lIntelligence Artificielle et du Web (ils sont orients vers linfrence des donnes). Sur la base
de ces ontologies, la notion de bases de donnes base ontologiques a t dtaille. Dans le
monde des ontologies et de leur utilisation, la diversit est bien prsente. Elle concerne la fois
leur usage par les diffrentes communauts de recherche (IA, BD, TALN ...) et la consquence
de leur mise en uvre dans les bases de donnes. Dans ce contexte la diversit concerne les
modles dontologies, les modles de stockage et les architectures du SGBD cible. Nous nous
sommes galement intresss aux langages dexploitation des bases de donnes smantiques.
Nous avons tudi deux langages principaux savoir SPARQL et OntoQL. SPARQL est adopt
par le consortium W3C comme le langage standard pour les BDBO. Il est utilis sur la plupart de BDBO. OntoQL est un langage dvelopp dans notre laboratoire pour exploiter les
ontologies et les instances ontologiques.
Dans le chapitre suivant, nous tudions le problme de la conception physique dans les bases
de donnes traditionnelles, en gnral, et dans les BDBO en particulier. Nous tudions limpact
de la diversit des BDBO sur la conception physique, une phase importante dans le cycle de vie
de conception des bases de donnes avances. Lobjectif de ce chapitre est dtudier en dtail
la conception physique traditionnelle, et ensuite de la gnraliser pour linstancier dans le cadre
des BDBO.
51
Chapitre
Conception Physique de Bases de Donnes
Sommaire
1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
Conception physique . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
Quelques exemples de structures doptimisation . . . . . . . . . . . .
58
3.1
Les index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
3.2
Les vues matrialises . . . . . . . . . . . . . . . . . . . . . . .
59
3.3
La Fragmentation horizontale . . . . . . . . . . . . . . . . . . .
62
Synthse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
4.1
Choix structures doptimisation . . . . . . . . . . . . . . . . . .
65
4.2
Choix de la mthode de slection . . . . . . . . . . . . . . . . .
65
4.3
Choix dalgorithme de slection . . . . . . . . . . . . . . . . . .
66
4.4
Mise en uvre des solutions doptimisation . . . . . . . . . . .
66
Vers une conception physique des BDBO . . . . . . . . . . . . . . . .
66
5
6
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
69
1. Introduction
1 Introduction
Loptimisation de requtes est un enjeu important dans le contexte de bases de donnes. Elle
a toujours eu une place importante travers les diffrentes gnrations de bases de donnes: les
bases de donnes traditionnelles, les bases donnes XML, les bases de donnes dcisionnelles,
les bases de donnes statistiques et scientifiques, les bases de donnes smantiques, et le big
data. Puisque les applications de bases de donnes sont toujours la recherche de temps de
traitement de requtes plus performant, plusieurs travaux ont t mens pour rendre les optimiseurs de requtes plus efficaces. Pour atteindre cet objectif, les optimiseurs de requtes ont pris
en compte progressivement des paramtres issus des phases du cycle de vie de la conception de
base de donnes ( savoir, la modlisation conceptuelle, la modlisation logique ETL, la modlisation physique et le dploiement (Figure 2.1)) et le langage de requtes utilis par le SGBD
cible.
Figure 2.1 Problme de conception physique

Deux gnrations principales doptimiseurs de requtes existent : des optimisations diriges
par certaines phases de cycle de vie (ODCP) et dautres diriges par toutes les phases (ODT P).
La premire gnration des optimiseurs a t base principalement sur ltude des proprits algbriques du langage de requtes dfini sur le modle logique de la base de donnes concevoir.
Le Rule-based Approach (RBA) est un exemple de ce type doptimisation. Plus prcisment, le
RBA utilise un ensemble de rgles intuitives suppos optimiser les requtes. Nous pouvons citer
par exemple, la rgle consistant descendre les oprations de la slection et de projection dans
un arbre algbrique. Cette rgle permet de rduire la taille des relations et des rsultats intermdiaires manipuls. Ce type doptimisation est simple implmenter, pour cette raison, elle a
t considre dans lensemble des SGBD commerciaux et acadmiques. La principale limite
de cette optimisation est quelle ignore les paramtres physiques lis la base de donnes et la
plateforme sur laquelle le SGBD est dploy. Les optimisations de type ODT P sont apparues
pour pallier aux limites de la premire gnration doptimisations. Comme son nom lindique,
55
Chapitre 2. Conception Physique de Bases de Donnes

une optimisation de type ODT P prend en compte des paramtres conceptuels, physiques et de
dploiement. Lapproche base sur des modles de cot mathmatiques, Cost-Based Approach
(CBA) est un exemple de cette gnration. Cette approche consiste dabord calculer le cot des
diffrentes stratgies possibles correspondant aux plans dexcution dune requte en fonction
des caractristiques des fichiers sur lesquels sont implantes les relations, pour ensuite retenir le
plan ayant le cot minimal. Pour illustrer le fonctionnement de cette optimisation, considrons
lexemple suivant:
Exemple 1
Considrons une requte impliquant une opration de jointure entre deux tables relationnelles R et S stockes sur un disque. Si nous souhaitons calculer le cot de cette jointure
en utilisant une implmentation par hachage sachant quil existe plusieurs algorithmes pour
implmenter une opration de jointure (boucles imbriques, le tri, etc.), nous aurons besoin
des paramtres issus de lensemble de phases du cycle de vie:
la couche conceptuelle: la longueur de chaque attribut de chaque table;
la couche logique: la taille (en termes dinstances) de chaque table;
la couche physique: le modle de stockage utilis pour stocker les tables (row store,
column store)
la couche de dploiement: les caractristiques de disque comme la taille dune page
disque.
Le cot de cette jointure, dnot par JHash, est donn par la formule suivante [80]:
JHash = 3 (|R| + |S |)
R
(1)
S
avec |R| et |S | sont gales respectivement ||R||LG

et ||S ||LG
, tels que :
PS
PS
R
S
: LG et LG dsignent respectivement la taille dune instance de R et de S (obtenue
partir du dictionnaire de donnes de la couche conceptuelle) ;
||R|| et ||S || reprsentent respectivement le nombre dinstances de R et S (la couche
logique) ;
PS dcrit la taille dune page disque (la couche de dploiement).
Cet exemple nous montre que loptimisation de requtes est sensible lensemble de phases du
cycle de vie de conception de bases de donnes. Si le langage de requtes, le type de la base de
donnes, le modle de stockage, ou la plateforme de dploiement changent alors le processus
doptimisation doit tre revisit. Lensemble des optimisations est souvent trait dans la phase
physique du cycle de vie. Les bases de donnes autres que orientes objet ne prennent quun
seul paramtre de la phase conceptuelle, savoir le dictionnaire de donnes. Rappelons que
le modle conceptuel exprime la fois les besoins applicatifs et la connaissance du domaine
sous une forme intelligible pour un utilisateur ultrieur. Malheureusement, cest le modle logique qui est exploit; et celui-ci, rsultant de la normalisation (dans le cas de bases de donnes
relationnelles) et de ladaptation au systme support, est en gnral trs diffrent du modle
conceptuel. Dans les bases de donnes orientes objets, les optimiseurs prennent en compte
56
2. Conception physique
les caractristiques du modle objet dans loptimisation: les expressions de chemins, les groupages dobjets, les parcours de pointeurs, les index de chemins, et aussi les mthodes utilisateur
[81]. La prsence du modle dontologie au sein dun SGBD doit tre prise en compte pour la
conception physique. La Figure 2.2 illustre bien les phases de cycle de vie prises en compte par
les deux types de bases de donnes: traditionnelles et smantiques.
Base de Donnes Smantique
Base de Donnes Traditionnelle
Besoins
A1
B1
C1
D1
A2
B1
C2
D2
A3
B2
C1
D3
Phase
Conceptuelle
Phase
Logique
Phase de
dploiement
Phase
Physique
Figure 2.2 Problme de conception physique dans les phases de cycle de vie
A partir de cette discussion, deux constats importants mergent: (i) la prsence de lontologie dans une base de donnes smantique peut tre exploite pour offrir des optimisations et (ii)
tout changement au niveau des phases du cycle de vie entraine automatiquement une nouvelle
visite de la conception physique.
Dans ce chapitre, nous dtaillons le processus de la conception physique la fois dans le
contexte des bases de donnes traditionnelles et smantiques. Nous y exposons la problmatique, des exemples de structures doptimisation ainsi que notre dmarche de rsolution dans le
cas des BDBO.
2 Conception physique
Un enjeu important pour la communaut de bases de donnes est la conception physique
des bases de donnes avances manipulant un gros volume de donnes tels que les entrepts de
donnes [82, 83]. Dans son papier Self-Tuning Database Systems: A Decade of Progress (prix
de 10 Year Best Paper Award la confrence prestigieuse Very Large Databases, dition 2007),
Surajit Chaudhuri indique : "The first generation of relational execution engines were relatively
57

simple, targeted at OLTP, making index selection less of a problem. The importance of physical
design was amplified as query optimizers became sophisticated to cope with complex decision
support queries" [84]. Cette amplification est due aux caractristiques suivantes lies aux bases
de donnes avances : (1) la complexit du schma de la base de donnes, o lensemble des
tables nont pas les mmes caractristiques. Prenons lexemple dun schma dun entrept de
donnes relationnel, nous constatons deux types de tables: la table des faits normalise contenant un nombre important dinstances, et des tables de dimension de taille moins importante,
souvent d-normalises afin de minimiser le nombre de jointures ncessaires pour valuer une
requte, (2) le volume de donnes, (3) la complexit des requtes qui ncessitent de plus en plus
des oprations coteuses comme la jointure et lagrgation, (4) les exigences des dcideurs sur
le temps de rponse de requtes et (5) la diversit des structures doptimisation. Deux grandes
classes de structures doptimisation ont t distingues [85]: des structures redondantes et structures non redondantes. Les structures redondantes sont celles qui ncessitent un espace mmoire
pour leur stockage et ayant un cot de maintenance. Comme exemples de ces structures, on peut
citer les index [86], les vues matrialises [87], la rplication et la fragmentation verticale [88].
Tandis que les structures non redondantes ne demandent pas despace de stockage. Ce sont par
exemple, la fragmentation horizontale [89] et le traitement parallle sans rplication. Une autre
difficult associe cette diversit est lusage de ces structures. Certaines sont appliques pendant la cration de la base de donnes comme la fragmentation horizontale et dautres pendant
lexploitation de la base de donnes comme les vues matrialises. Cela rend le processus de slection et dutilisation de certaines structures sensibles. Dans la section suivante, nous dcrivons
en dtails certaines des structures doptimisation les plus utilises par les SGBD commerciaux
et acadmiques.
3 Quelques exemples de structures doptimisation

Dans cette section, nous prsentons deux exemples de structures doptimisation redondantes, savoir les index et les vues matrialises et une structure doptimisation non redondante, fragmentation horizontale.
3.1 Les index

Les techniques dindexation ont t largement tudies et constituent une option trs importante pour la phase de conception physique des bases de donnes traditionnelles et avances.
Les index sont utiliss pour amliorer le temps daccs aux donnes. La dfinition des index se
fait souvent pendant lexploitation de la base de donnes. Un nombre important dindex a t
propos et support par les SGBD commerciaux et acadmiques. Dans le contexte des bases
de donnes traditionnelles, les index de type B-tree, les index de hachage, lindex de jointure,
etc. ont t proposs. Certaines techniques dindexation sont apparues dans le contexte dentre58
3. Quelques exemples de structures doptimisation

pts de donnes, vu la nature de requtes OLAP (Online Analytical Processing). Ce sont par
exemple les index binaires, les index de jointures binaires, les index de jointure en toile, etc.
Pour plus de dtails sur les caractristiques de ces index, nous recommandons la consultation
de la thse de Kamel Boukhalfa [85].
Slectionner un ensemble dindex pour optimiser une charge de requtes donne est un
problme difficile [90]. Pour rpondre ce problme, les premiers travaux ont propos des
solutions suivant lapproche ODCP, o certaines rgles comme lusage des attributs candidats
lindexation et la frquence des requtes ont t proposes [91]. Ces rgles ne sont pas suffisantes pour offrir une slection performante. Pour pallier ce type de slection, certains travaux
ont formalis le problme de slection dindex (PSI) comme un problme doptimisation suivant
lapproche ODT P.
Etant donns :
Q = {q1 , q2 , ..., qn }, une charge de requtes o chaque requte qi possde une frquence
daccs fi , (1 i n);
un schma de BD ou dun entrept de donnes dploy sur une plateforme donne.
un espace S de stockage des index.
Le PSI consiste trouver une meilleure configuration dindex, CI, permettant doptimiser Q,
cest--dire rduire le cot total dexcution des requtes tout en respectant la contrainte de
stockage (T aille(CI) S ).
Ce problme est NP-complet [90]. Plusieurs approches de rsolution de ce problme ont t
dveloppes. Elles commencent par numrer lensemble des attributs candidats lindexation.
Ces attributs sont choisis parmi ceux prsents dans les clauses WHERE, GROUP BY et ORDER BY des requtes. Des algorithmes de slection des attributs que lon peut indexer ont t
proposs ; ils sont guids par un modle de cot mathmatique quantifiant la qualit de la solution obtenue. On peut citer des algorithmes gntiques, le recuit simul, ou la programmation
linaire entire [92]. Lune de ces approches est utilise dans le module What-if de SGBD SQL
Server [93].
3.2 Les vues matrialises

Une vue est une requte nomme. Elle est dite matrialise si son rsultat est stock physiquement. Les vues amliorent lexcution des requtes en pr-calculant les oprations les plus
coteuses comme la jointure et lagrgation, et en stockant leurs rsultats dans la base. Dans
cette situation, certaines requtes ncessitent seulement laccs aux vues matrialises et par
consquent sont excutes plus rapidement.
Les vues matrialises peuvent tre utilises pour rpondre plusieurs objectifs, comme
lamlioration de la performance des requtes ou la fourniture des donnes dupliques (cache).
Elles sont associes trois problmes majeurs, savoir (i) le problme de leur slection, (ii) le
problme de leur maintenance et (iii) la rcriture des requtes en fonction des vues.
59

3.2.1
La slection des vues matrialises
Etant donn que nous ne pouvons pas matrialiser toutes les vues pour des raisons de stockage, de maintenance et de rcriture, la slection des vues matrialises consiste choisir un
sous-ensemble de vues candidates permettant de rduire le cot dexcution dune charge de
requtes. La slection des vues peut tre effectue sous certaines contraintes, gnralement un
quota despace et/ou un seuil de temps de maintenance ne pas dpasser. Les principaux travaux sur la slection des vues matrialises ont t inspirs de lapproche ODT P. Le problme
de slection des vues matrialises (PSV) peut donc tre formalis comme suit [94, 95] :
Etant donns :
Q = {q1 , q2 , ..., qn } une charge de requtes o chaque requte qi possde une frquence
daccs fi , (1 i n);
un schma de BD ou dun entrept de donnes dploye sur une plateforme donne;
un ensemble de contraintes C.
Le problme de slection de vues (PSV) consiste trouver un ensemble de vues, VM, qui permet de rduire le cot total dexcution des requtes de Q et qui respecte les contraintes de
C. Les contraintes de C peuvent tre des contraintes de stockage, de maintenance, de temps
dexcution, etc.
Comme le problme de slection dindex, le PSV est NP-complet [87]. Le PSV dans les
entrepts de donnes a t largement tudi tant pour lapproche MOLAP (multidimensionnal
OLAP) que pour lapproche ROLAP (relational OLAP). Dans lapproche MOLAP, le cube de
donnes est considr comme la structure primordiale pour slectionner les vues matrialises.
Chaque cellule du cube est considre comme une vue potentielle. Dans lapproche ROLAP
chaque requte est reprsente par un arbre algbrique [96]. Chaque nud (non feuille) est
considr comme une vue potentielle.
Deux types de PSV ont t considrs : le PSV statique et le PSV dynamique. Le PSV statique consiste slectionner un ensemble de vues matrialiser afin de minimiser le cot total
dvaluation de ces requtes, le cot de maintenance ou les deux, et ce, sous la contrainte de la
ressource. Le problme suppose donc que lensemble des requtes nvolue pas. Si des volutions sont enregistres dans les requtes alors il est ncessaire de reconsidrer totalement le problme (en reconstruisant les vues matrialiser). Le PSV dynamique considre que lensemble
des requtes volue dans le temps [97, 98, 99, 100]. Dans ce cas, lalgorithme dynamique peut
tre amen modifier lensemble des vues matrialises en fonction de nouvelles requtes. En
effet, il peut insrer de nouvelles vues et en supprimer dautres dans le cas o lespace maximum autoris serait atteint. Pour combler les lacunes du PSV statique, Kotidis et al. [97] ont
propos un systme appel DynaMat, qui matrialise les vues dune manire dynamique. DynaMat combine en fait les problmes de la slection et de la maintenance des vues.
Plusieurs travaux ont tudi le problme de slection des vues matrialises. Ces travaux
peuvent tre classs en deux grandes catgories [101] : (1) travaux dirigs par le temps dinterrogation et (2) travaux dirigs par le temps de maintenance. La premire catgorie privilgie
60

loptimisation des performances de linterrogation de lentrept et fonctionne sous contrainte
despace de stockage des vues matrialises. La seconde vise rduire le temps de maintenance
des vues matrialises [94]. Elle est employe dans le cas o les rafrachissements de lentrept
sont consquents ou leur frquence leve. Notons que certaines approches ont t proposes
dans le souci de satisfaire simultanment les deux besoins [102].
Comme les travaux effectus sur la slection des index, ceux proposs pour la slection des
vues matrialises utilisent souvent des heuristiques pour trouver une solution quasi-optimale.
Les algorithmes proposs procdent deux principales tapes : (1) gnration des vues candidates
et (2) slection dun sous-ensemble de ces vues. Dans la premire tape, lensemble de vues
matrialises candidates V est construit partir dune charge de requtes Q les plus frquentes.
Cet ensemble est structur de manire prendre en compte les relations susceptibles dexister
entre les vues candidates. Plusieurs structures ont t proposes pour reprsenter les relations
entre les vues. Nous pouvons citer les structures suivantes : les treillis [103, 104, 105, 106, 107],
les graphes [102, 108, 109, 110], les plans dexcution des requtes [111, 112, 113], etc.
Dans la deuxime tape, les algorithmes slectionnent un sous-ensemble des vues candidates en fonction de la fonction objectif utilise ainsi que des contraintes du problme de slection. Plusieurs types dalgorithmes ont t utiliss pour effectuer cette slection. Nous pouvons
citer les algorithmes gloutons [103, 104, 114, 105, 106, 107, 112, 110], les mthodes issues de
la recherche oprationnelle (sac dos [113]) ou les algorithmes gntiques [115, 116].
3.2.2
La maintenance des vues matrialises
Les tables de base changent et voluent au rythme des mises jour. Cependant, si ces changements ne sont pas reports dans les vues matrialises, leurs contenus deviendront obsoltes et leurs objets ne reprsenteront plus la ralit. La maintenance des vues matrialises
consiste reporter les modifications survenues sur les tables de base au niveau des vues. Cela
peut se faire selon trois approches : priodiques, immdiates et diffre. Dans la premire approche [117, 118], les vues sont mises jour continuellement des priodes prcises ; dans ce
cas ces vues peuvent tre considres comme des photographies (snapshots). Dans la seconde
[119, 120], les vues sont mises jour immdiatement la fin de chaque transaction. Dans la
dernire [121], les modifications sont propages dune manire diffre. Dans ce cas, une vue
est mise jour uniquement au moment o elle est utilise par une requte dun utilisateur.
La maintenance des vues peut tre effectue en recalculant ces vues partir des tables de
base. Cependant, cette approche est compltement inefficace (trs coteuse). En effet, une bonne
maintenance des vues est ralise lorsque les changements (insertions, suppressions, modifications) effectus dans les tables sources peuvent tre propags aux vues sans tre dans lobligation de recalculer intgralement leur contenu. Pour rsoudre ce problme, trois types de maintenance ont t proposes : incrmentale, autonome et en batch. La maintenance incrmentale
consiste identifier le nouvel ensemble de n-uplets ajouter la vue dans le cas dune insertion
61

ou le sous-ensemble de n-uplets retirer de la vue dans le cas dune suppression, sans rvaluer
intgralement la vue. La maintenance autonome assure que la maintenance dune vue V peut
tre calcule uniquement partir de V et des changements survenus sur les tables de bases sur
lesquelles elle est dfinie. La maintenance en batch est effectue en utilisant des transactions de
mise jour. Une transaction de maintenance est relativement longue et peut donc interrompre
lusage de lentrept. Par consquent, elle est excute souvent durant les priodes dactivit
creuse (la nuit par exemple). Cette maintenance nest pas souhaitable, car avec lmergence
dinternet, un entrept doit tre oprationnel continuellement (24h/24).
3.2.3
La Rcriture de requtes en fonction des vues matrialises
Aprs le processus de slection des vues, toutes les requtes dfinies sur lentrept doivent
tre rcrites en fonction des vues. Slectionner la meilleure rcriture pour une requte est
une tche difficile [122, 123]. Le processus de rcriture de requtes est support par la plupart
des SGBD multidimensionnels (ex. Oracle). Le processus de rcriture des requtes a attir
lattention de nombreux chercheurs car elle est en relation avec plusieurs problmes de gestion
de donnes: loptimisation de requtes, lintgration des donnes, la conception des entrepts
de donnes, etc. Le processus de rcriture des requtes a t utilis comme une technique
doptimisation pour rduire le cot dvaluation dune requte.
Plus formellement; ce processus peut se dfinir ainsi: soit une requte Q dfinie sur un
schma dune base de donnes et un ensemble de vues {V1 , V2 , ..., Vi } sur le mme schma. Estil possible de rpondre la requte Q en utilisant seulement les vues? Alternativement, quel
est le plan dexcution le moins cher pour Q en supposant quen plus des tables de la base de
donnes, on a aussi un ensemble de vues? La figure 2.3 donne une illustration de ce processus.
Requte
Gnration
de plan
Evaluation
de plans
Structure
doptimisation
Slectionnes
(index, VM,)
Requte
rcrite
meilleur
plan
Gnration
de plan
Figure 2.3 Rcriture dans le processus doptimisation
3.3 La Fragmentation horizontale

La fragmentation horizontale est une structure doptimisation qui a t tudie massivement
dans les diffrentes gnrations de bases de donnes : les bases de donnes relationnelles, les
62

bases de donnes orientes objet, les bases de donnes XML, les entrepts de donnes, etc. Initialement propose comme une technique de conception logique des bases de donnes rparties
dans les annes 80 [124, 125], la fragmentation horizontale consiste partitionner une table en
fonction de ses n-uplets de faon rduire le nombre des accs non ncessaires pour le traitement de certaines requtes. Deux types de fragmentation horizontale existent : primaire [126]
et drive [85]. La fragmentation horizontale primaire dune table se base sur des attributs dfinis sur cette table. La fragmentation horizontale drive consiste propager la fragmentation
dune table sur une autre table. Cette propagation nest possible que si un lien pre-fils existe
entre les deux tables. Par consquent, la fragmentation horizontale drive dune table se base
sur les attributs dfinis sur une ou plusieurs autres tables [85]. Contrairement aux autres structures doptimisation (comme les index et les vues matrialises), o la slection des schmas
doptimisation se fait gnralement lorsque la base de donnes est oprationnelle (ou cre), la
slection dun schma de fragmentation dune base de donnes (ou un entrept de donnes) doit
se dcider avant sa cration [127]. Cette situation rend sa slection plus sensible que les autres
structures. De plus, elle peut galement tre combine avec dautres structures doptimisation
comme les index [128], les vues matrialises [89, 129] et le traitement parallle [130].
Un nombre important de travaux sur la fragmentation horizontale a t dvelopp dans le
cadre des bases de donnes traditionnelles et avances. Ces travaux ont suivi les deux approches
que nous avons cites: ODCP et ODT P. Les premiers travaux ont utilis des critres comme
les affinits entre les prdicats de slection utiliss dans une charge de requtes. Rappelons
que la fragmentation horizontale est efficace si elle est dfinie sur les attributs figurant dans
les prdicats de slection. Laffinit entre deux prdicats reprsente la somme des frquences
daccs des requtes utilisant simultanment les deux prdicats. Cette approche est donc moins
complexe que celle base sur les prdicats dont la complexit est O(2n). Mais, elle ne prend
en considration que la frquence daccs comme critre de regroupement. Or, pour fragmenter une base de donnes, dautres paramtres doivent tre pris en compte, comme les facteurs
de slectivit des prdicats, la taille de la table, la taille de page disque, le nombre de pages
occupes par cette table, etc. Les approches bases sur les prdicats et sur les affinits ne fournissent aucune mtrique permettant dvaluer la qualit du schma de fragmentation obtenu.
Pour pallier ce problme, Bellatreche [131] a propos dans le cadre de ses travaux de thse
une nouvelle approche de fragmentation base sur un modle de cot. Grce ce dernier, il est
possible dvaluer la qualit de la solution fournie.
Afin doffrir aux concepteurs la possibilit de quantifier la qualit de leurs schmas de fragmentation, des algorithmes suivant lapproche ODT P ont t proposs dans le cadre des bases
de donnes orientes objet et les entrepts de donnes [124, 125, 132, 130, 128]. Les composantes principales de ces algorithmes sont: (i) un gnrateur de schmas de fragmentation, (ii)
un modle de cot et (iii) une slection du schma optimal.
1. Gnrateur de schmas de fragmentation : Cette tape consiste gnrer tous les schmas
de fragmentation possibles, dune classe dun schma dune base de donnes oriente
63

objet. Cette gnration est guide par lensemble de prdicats de slection dfini dans la
charge de requtes.
2. modle de cot: Il constitue le noyau de ce type dalgorithmes. Il peut tre vu comme une
fonction dune seule variable reprsentant un schma de fragmentation S i et attribuant le
cot dexcution C(S i ) dun ensemble de requtes. Il prend en considration la taille des
tables, le nombre de pages, les facteurs de slectivit des prdicats, fan-out, etc. Loptimalit et la qualit des solutions obtenues par ces algorithmes sont lies ce modle de
cot.
3. Slection du schma de fragmentation optimal: Il dtermine le schma de fragmentation
S min garantissant la meilleure performance parmi tous les schmas possibles.
4 Synthse
Daprs cette tude, nous concluons que les optimisations actuelles se basent sur lensemble
de phases de cycle de vie de conception dune base de donnes. En consquence, le problme de
la conception physique peut tre prsent comme un problme doptimisation. Etant donns :
Un schma dune base de donnes dploye sur une plateforme donne;
Une charge de requtes Q = {Q1 , Q2 , ..., Qm }, o chaque requte Q j possde une frquence
daccs f j ;
Un ensemble de structures doptimisation S O = {S O1 , S O2 , ..., S Ol } supportes par le
SGBD hte utilis pour rpondre aux requtes ;
Un ensemble de contraintes lies S O : Cont = {Cont1 , Cont2 , ..., Contl }, o chaque
contrainte Conti (1 i l) est associe une structure doptimisation S Oi .
Le problme de la conception physique consiste slectionner des schmas de structures
doptimisation afin de rduire le cot dexcution de la charge de requtes Q en prsence de
ces derniers tout en respectant les contraintes dfinies.
Pour rsoudre ce problme, il faut considrer lespace de recherche qui intgre tous les
sous-espaces correspondants aux structures doptimisation. Si Insi est le nombre dinstances de
Pt
la structure doptimisation S Oi , lespace de recherche global est 2 i=1 Insi . Cela est d au fait que
les diffrentes instances peuvent interagir [133].
Dans la pratique, ladministrateur de base de donnes (DBA) doit effectuer les choix suivants: (a) choix de structures doptimisation parmi S O suppos(es) pertinente(s) (b) choix du
mode de slection des schmas doptimisation de ces dernires dans le cas o il dcide dutiliser plusieurs structures et (c) choix des algorithmes pour les slections. Enfin le DBA passe la
validation des configurations recommandes par une mise en uvre.
64
4. Synthse
Figure 2.4 Problme de conception physique
4.1 Choix structures doptimisation

Nous avons vu quil existe plusieurs types de structures doptimisation pour la conception
physique. Le choix des structures pertinentes et adquates pour optimiser une charge de requtes
est un problme complexe. Il ncessite une certaine expertise. Ce choix peut se faire manuellement en se basant sur lexprience du DBA et les caractristiques des requtes [134]. Mais
on peut aussi se servir des outils proposs par les SGBD commerciaux et non commerciaux
comme DBDSGN [135], SQL Access Advisor [136], DB2 Design Advisor [133], et Parinda de
PostgreSQL [137].
4.2 Choix de la mthode de slection

Deux modes de slection existent [85]: la slection isole [138] lorsque le DBA choisit une
seule structure doptimisation et la slection multiple [130, 139] lorsque plusieurs structures
sont choisies. Dans le cas dune slection multiple, plusieurs scnarii sont possibles pour combiner ces structures doptimisation [140]. Le choix de lensemble des structures utiliser et la
manire de les combiner sont dterminants pour la performance du systme [85].
65
4.3 Choix dalgorithme de slection

Plusieurs classes dalgorithmes ont t proposes dans la littrature pour slectionner des
structures doptimisation allant des algorithmes simples comme les algorithmes gloutons aux
avancs comme les algorithmes gntiques [115, 116] et le recuit simul [141].
4.4 Mise en uvre des solutions doptimisation

Une fois les structures doptimisation recommandes par un algorithme de slection, il est
ncessaire de les valider par un dploiement dans environnement rel afin dvaluer leur performance effective. On peut les valider travers des outils commerciaux proposs comme Oracle
SQL Access Advisor [136] et DB2 Design Advisor [133]. Cependant, ces outils prsentent des
limites lies aux structures doptimisation et au mode de slection fourni.
5 Vers une conception physique des BDBO

La conception physique des BDBO pourrait tre similaire celle des bases de donnes traditionnelles. Mais en examinant les caractristiques de ces dernires marques par la diversit
impliquant la prsence de lontologie dans le SGBD, les modle des stockage de donnes, larchitecture des BDBO et le langage de requtes utilises. Nous optons pour la revisiter pour que
lensemble des caractristiques soit inclus dans la formalisation.
Etant donns:
Une BDBO implmente sur un SGBD donn avec ses spcificits concernant le stockage et larchitecture, et dploye sur une plateforme donne;
Une charge de requtes en Sparql Q = {Q1 , Q2 , ..., Qm }, o chaque requte Q j possde
une frquence daccs f j ;
Un ensemble de structures doptimisation S O = {S O1 , S O2 , ..., S Ol } supportes par le
SGBD hte utilis pour rpondre aux requtes ;
Un ensemble de contraintes lies S O : Cont = {Cont1 , Cont2 , ..., Contl }, o chaque
contrainte Conti (1 i l) est associe une structure doptimisation S Oi .
Le problme de la conception physique consiste slectionner des schmas de structures
doptimisation afin de rduire le cot dexcution de la charge de requtes Q en prsence de ces
derniers tout en respectant les contraintes dfinies.
La figure 2.5 dcrit le problme de conception physique dans les bases de donnes base
ontologique.
En examinant les travaux existants, nous avons identifi que la conception physique dans
le contexte des bases de donnes smantique utilise la mme dmarche que celle des bases de
donnes traditionnelles. Souvent, cette conception suppose un seul modle de stockage et une
66
5. Vers une conception physique des BDBO
Figure 2.5 Problme de conception physique dans les BDBO
67

seule architecture comme dans le cas de [142] et [143]. Dans cette thse, nous proposons une
solution plus globale o lensemble de scnarii de stockage et darchitecturaux sont pris en
compte.
Vu la difficult du problme et la complexit des bases de donnes smantiques, nous avons
suivi la dmarche suivante prsente sur la figure 2.6 :
1. Etude exprimentale des BDBO. Cette tude nous a permis de comprendre les diffrents
facteurs qui peuvent influencer la conception physique et surtout les caractristiques de
chaque type de base de donnes. Pour ce faire, nous avons utilis six bases de donnes
smantiques, trois acadmiques (Jena, Sesame et OntoDB, dveloppe au sein de notre
laboratoire) et trois issues de milieu industriel, savoir Oracle, DB2RDF et IBM SOR.
2. Dveloppement dun modle de cot pour chaque type de BDBO.
3. Considration dune structure doptimisation savoir les vues matrialises. Nous avons
choisi cette structure pour trois raisons principales: (i) elle a t largement tudie dans
le cas des entrepts de donnes, (ii) une vue peut tre indexe et partitionne, et (iii) elle
a t tudie rcemment dans le cas des bases de donnes smantiques.
s
de
de
u
t
BO
BD
Identification des paramtres cls

pour un modle de cots
Dveloppement dun modle de

cots
Utilisation du MC dans la slection

de structure doptimisation
Structures doptimisation
slectionnes (Index, VM, etc.)
Figure 2.6 Notre dmarche. (MC:Modle de cot)
68
6. Conclusion
6 Conclusion
Dans ce chapitre, nous nous sommes intresss la conception physique et avons mis en
vidence les difficults que lon rencontre dans la conception physique des bases de donnes.
Nous avons montr que la diversit de modles de stockage des BDBO, la varit de leurs
architectures et la mconnaissance des tables sur lesquelles portent les requtes amplifient davantage la complexit du problme de conception physique qui est dj NP-complet dans les
BD traditionnelles.
Ce constat nous motive porter notre attention sur ce problme dans les bases de donnes
base ontologique.
Notre dmarche est de proposer une formalisation unifie des BDBO qui prend en compte
leur diversit. Une fois cette formalisation tablie, le dveloppement des modles de cot pour
chaque spcificit devient un enjeu important. La qualit de ces derniers impacte celle de la
conception physique. Pour instancier notre dmarche de conception physique, nous prenons le
cas des vues matrialises. Ces points seront dtaills dans les chapitres suivants.
69
Deuxime partie
Contributions
71
Chapitre
Etude Empirique des Bases de Donnes Base

Ontologique
Sommaire
1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
Les composantes dune BDBO . . . . . . . . . . . . . . . . . . . . .
74
2.1
Logiques de Description . . . . . . . . . . . . . . . . . . . . . .
74
2.2
Formalisation dune ontologie . . . . . . . . . . . . . . . . . . .
76
2.3
Modle unifi des BDBO . . . . . . . . . . . . . . . . . . . . .
77
Prsentation des BDBO
. . . . . . . . . . . . . . . . . . . . .
78
Critres de comparaison des BDBO . . . . . . . . . . . . . . .
85
4.1
Ensembles de donnes et environnement de tests . . . . . . . . .
88
4.2
Performances en termes de chargement des donnes (ontologie

et instances) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
Performances en termes de temps de rponse de requtes . . . .
95
Paramtres influant identifis partir de cette tude . . . . . . . . .
98
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
Etude des BDBO . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1
3.2
4
Etude de performances des BDBO . . . . . . . . . . . . . . . . . . .
4.3
73
78
88
Chapitre 3. Etude Empirique des Bases de Donnes Base Ontologique
1 Introduction
Dans la conclusion du chapitre prcdent, nous avons mentionn qutudier le problme de
la conception physique dans le contexte des BDBO est une tche difficile. Cela est d la forte
diversit lie aux modles de stockage et aux architectures du SGBD candidats pour stocker
ce type de base. Une conception physique de bonne qualit ncessite la prsence dun bon
modle de cot. Ce dernier doit prendre en compte des paramtres influents de lensemble des
phases du cycle de vie de conception des BDBO (Figure 2.1). En examinant la littrature, nous
avons remarqu la prsence dun nombre limit de modles de cot dans le contexte de base
de donnes smantiques. Pour identifier les paramtres de notre modle de cot, nous avons
suivi une approche exprimentale qui a permis dvaluer trois types de BDBO, chacune ayant
un modle de stockage et une architecture diffrente. Pour avoir une vue claire sur les BDBO
utilises, nous avons dabord procd la gnralisation un ensemble des BDBO en proposant
un modle unifi. Cette formalisation nous a permis didentifier lensemble des composantes
dune BDBO.
Dans ce chapitre, nous proposons dabord une formalisation gnrique des BDBO puis une
tude empirique de six exemples de BDBO, savoir OntoDB, Oracle, IBM SOR, DB2RDF,
Sesame et Jena.
2 Les composantes dune BDBO

Afin de pouvoir traiter le problme de conception physique dans les BDBO, nous proposons
une formalisation des BDBO (modle unifi des BDBO), qui prend en compte la diversit
des BDBO que nous avons identifie au chapitre 1. Ce modle unifi est bas sur les critres
fondamentaux des BDBO. Une BDBO stockant une ou plusieurs ontologies, nous prsenterons
dabord une formalisation de cette notion. Mais avant tout, nous introduisons les notions sur les
logiques de description qui sont utilises dans nos formalisations.
2.1 Logiques de Description

Les logiques des descriptions (LD) sont utilises pour reprsenter les connaissances et pour
faire du raisonnement. Elles sont bases sur les notions de concepts et de rles. Un concept
correspond un ensemble dindividus. Un concept peut tre primitif (atomique) ou dfini. Un
rle est une relation binaire entre deux individus. Les concepts et rles peuvent tre organiss
en une hirarchie grce la relation de subsomption. Une base de connaissances est compose
dune TBOX (Terminological Box) qui dcrit les connaissances intentionnelles du domaine sous
forme daxiome et dune ABOX (Assertion Box) qui dcrit les connaissances extensionnelles
du domaine (les instances). Les oprations de base du raisonnement terminologique sont la
classification et linstanciation. La classification sapplique aux concepts et rles et permet de
74
2. Les composantes dune BDBO

dterminer la position dun concept ou rle dans leurs hirarchies respectives. Linstanciation
permet de retrouver les concepts dont un individu est susceptible dtre une instance.
Plusieurs familles de langages des logiques de description existent parmi lesquels AL, F L,
SHOQ[144], SHI Q[145, 146], SHOI N[147], etc. Le langage dontologie OWL est bas
sur la famille ALC. OWL-DL est bas sur le fragment SHOIND(D) et OWL-Lite est bas sur le
fragment SHIF(D). Chaque famille utilise un sous-ensemble de constructeurs. Dans ce qui suit,
nous prsenterons quelques constructeurs de LD et leurs correspondants OWL dont nous avons
besoin pour nos formalisations (tableau 3.1) :
Syntaxe DL
AB
AB
A
{o1 ,, on }
r.C
r.C
P.o1
P.C1
P.C1
= P.C1
D
OWL
intersectionOf
unionOf
complementOf
oneOf
allValuesFrom
someValuesFrom
hasValue
minCardinality
maxCardinality
cardinality
equivalentClass, sameAs
Dfinition
Conjonction de concepts
Disjonction de concepts
Ngation
Enumration
Quantificateur universel
Quantificateur existentiel
Egalit de valeur
Cardinalit minimale
Cardinalit maximale
Cardinalit exacte
Equivalence entre concepts
Table 3.1 Constructeurs de la description logique. A, B et P sont des noms de concepts et oi

et C1 des noms dinstances
.
Intersection ( , owl:intersectionOf ) permet de construire une nouvelle classe comme

une intersection de deux ou plusieurs classes. Par exemple, la classe Mre peut tre dfinie
comme lintersection des classes Parent et Femme (Mre = Parent Femmes).
Union (, owl:UnionOf ) permet de dclarer une nouvelle classe comme tant le regroupement de deux ou plusieurs classes. Par exemple, on pourrait dclarer que la classe
Personne est lunion des classes Homme et Femme (Personne Homme Femme).
Complment (, owl:complementOf ) permet de dfinir une classe comme complmentaire dune autre classe. Par exemple, on pourrait dclarer la classe Homme comme complmentaire de Femme dans la classe Personne (Homme Personne Femme).
numration (owl:oneOf ) permet de dfinir une classe par extension : on liste les instances dans un ensemble. Par exemple Doctorant = {Bery, Selma, ...,}.
Restriction (owl:Restriction) permet de dclarer une nouvelle classe partir dune autre
en dfinissant des restrictions (contrainte de valeur et cardinalit) sur les instances de la
classe. Il sagit de :
quantification Universelle ( p.C1, owl:allValuesFrom) permet de dclarer une nou75
velle classe dont toutes les instances prennent leurs valeurs dans la classe C1 pour la
proprit p ;
quantification existentielle ( p.C1, owl:someValuesFrom) permet de dclarer une nouvelle classe dont les instances prennent au moins une valeur dans C1 pour la proprit
p;
galit de valeur (= P.o1 , owl:hasValue) permet de dclarer une nouvelle classe en
imposant la valeur spcifie (o1 ) toutes les instances de la classe en question. Par
exemple, la classe Homme peut tre dclare comme la classe Personne avec la proprit sexe gale Masculin ( Homme Personne p p.sexe.Masculin) ;
cardinalit minimale ( P.C1 , owl:minCardinality) permet de dclarer une nouvelle
classe en fixant une borne infrieure au nombre dinstances dans une proprit ;
cardinalit maximale ( P.C1 , owl:maxCardinality) permet de dclarer une nouvelle
classe en fixant une borne suprieure au nombre dinstances dans une proprit ;
cardinalit exacte (= P.C1 , owl:cardinality) permet de dclarer une nouvelle classe en
indiquant exactement le nombre des instances dans une proprit.
2.2 Formalisation dune ontologie

La formalisation dune ontologie que nous proposons consiste en le 5-uplet suivant : MO=
<C, P, Applic, Ref, Formalisme>.
C reprsente les classes de lontologie. Lensemble des classes peut tre dcompos en
deux sous-ensembles Cc et Cnc (C = Cc Cnc ) ; o Cc reprsente lensemble des classes
canoniques, et Cnc lensemble des classes dfinies ou non-canoniques. Par exemple, nous
pouvons imaginer une ontologie o Cc = {Homme, Femme} et Cnc = {Personne} car
Personne = {Homme Femme}. Comme autre exemple, si Personne est une classe canonique associe la proprit genre, Cc = {Personne} et Cnc = {Homme, Femme} car
Homme Personne(genre = masculin) et Femme Personne(genre = f minin).
P reprsente les proprits de lontologie. Cest dire les proprits utilises pour dcrire
les instances de lensemble des classes C par des valeurs appartenant soit des types
simples, soit dautres classes. Comme pour lensemble des classes, lensemble des proprits peut tre aussi dcompos en deux sous-ensembles Pc les proprits canoniques
et Pnc les proprits non canoniques. Par exemple si nom et prnom sont des proprits de lontologie, Pc = {nom, prnom} et Pnc = {nomComplet} avec nomComplet =
nom + prnom.
Applic : C 2P est une fonction qui permet de lier chaque classe aux proprits qui lui
sont attaches, cest--dire, celles qui peuvent tre utilises pour en dcrire ses instances.
Seules les proprits ayant pour domaine une classe, ou lune de ses super-classes, sont
applicables une classe. Si le domaine dune proprit nest pas spcifi, la racine de
lontologie est implicitement considre.
Re f : C (operateur, Exp(C)) est une fonction qui associe chaque classe un op76
2. Les composantes dune BDBO

rateur dinclusion ou dquivalence et une expression sur des classes ou des proprits.
Les expressions utilises pour dfinir des ontologies OWL qui sont bases sur les logiques de description prsentent, notre point de vue, un ensemble doprateurs complet couvrant plusieurs formalismes ontologiques. Ces expressions utilisent les oprateurs suivants : oprateurs ensemblistes (intersectionOf (), unionOf (), complementOf
()), restrictions de proprits (AllValuesFrom p.C, SomeValuesFrom p.C, HasValue
p.C) et les oprateurs de cardinalit ( nR.C, nR.C). Les oprateurs dinclusion
() et dquivalence jouent des rles trs importants : loprateur dinclusion permet
de construire des hirarchies de classes et loprateur dgalit intervient dans la dfinition des concepts non canoniques. Exp est une expression sur les classes c C et les
proprits p P utilisant aussi les oprateurs de la logique de description et les oprateurs ensemblistes. Par exemple, Ref(Homme)=(, Exp(Personne)) o Exp(Personne) =
Personne.sexe.Masculin. Notons que Exp peut tre la fonction didentit qui associe
une classe la mme classe. Comme exemple, Ref(Homme)=(, Exp(Personne)) avec
Exp(Personne) = Personne.
Formalisme est comme son nom lindique le formalisme du modle ontologique adopt.
Cela peut tre RDFS, OWL, PLIB, OIL, DAML, etc.
Vu le fait quune ontologie peut tre exprime dans diffrents modles dontologies, il est
possible de faire une spcialisation de cette formalisation pour un modle dontologies donn.
Lexemple suivant prsente une formalisation des ontologies du modle dontologies PLIB.
Exemple 1
OntologiePLIB = <C, P, Applic, Ref(C), PLIB> o Ref(c) =(OntoSub, Exp(c)), avec c C .
Loprateur OntoSub de Plib est un oprateur permettant de dfinir un hritage partiel, o
une classe rfrence une autre classe en hritant de tout ou dune partie de ses proprits.
Cest une relation de subsomption 13 .
2.3 Modle unifi des BDBO

Pour reprsenter la diversit des structures de BDBO, nous avons trouv ncessaire de proposer une structure gnrique permettant de faire ressortir le modle ontologique, le schma de
stockage du schma de lontologie, le schma de stockage des instances ontologiques et larchitecture de BDBO . Notre modle unifi est le 7-uplet dfini de la manire suivante :
BDBO :< MO, I, S ch, Pop, S M MO , S MInst , Ar >, o
MO reprsente les ontologies stockes dans la BDBO formalise sous la forme dun
5-uplet <C, P, Applic, Ref, Formalisme> comme dfini dans la section prcdente ;
I : reprsente lensemble des instances ontologiques ;
S ch : C 2P est une fonction qui associe chaque classe lensemble des proprits
pour lesquelles les instances de cette classe ont des valeurs. On a la contrainte c
C, S ch(c) Applic(c) ;
77

Pop : E 2I , est une fonction qui associe chaque classe ses instances de lensemble
I;
Modle stockage (S M MO ): le modle de stockage de lontologie (vertical, binaire et horizontal) ;
Modle stockage (S MInst ): le modle de stockage des instances ontologiques ;
Modle darchitecture (Ar): le type darchitecture de la base de donnes (Type I, II ou III).
Ce modle sera illustr sur chaque BDBO prsente dans la suite de ce chapitre ( 3.1).
Le modle prsent dans cette section permet de reprsenter la diversit des BDBO au
niveau macroscopique en termes de formalisme dontologie, de modles de stockage et darchitecture. Dans la section suivante, nous chercherons comparer plus prcisment les BDBO.
Pour cela, nous allons nous intresser quelques BDBO particulires.
3 Etude des BDBO

La conception physique des BDBO ncessite une connaissance trs prcise des BDBO,
nous avons choisi de comparer des BDBO fortement utilises et venant de diffrentes communauts. Ainsi, nous nous intressons six BDBO dont trois sont issues du monde de la
recherche (OntoDB, Sesame et Jena) et trois autres sont issues du monde industriel (Oracle,
DB2RDF et IBM SOR dIBM). Nous nous appliquerons mettre en avant les caractristiques
identifies au chapitre 1 qui montre la diversit des BDBO.
3.1 Prsentation des BDBO

3.1.1
Base de Donnes Base Ontologique OntoDB
OntoDB [9] est une architecture de BDBO conue par le Laboratoire dInformatique et
dAutomatique pour les Systmes (LIAS). Elle est conue pour supporter lvolution des ontologies et pour offrir un accs aux donnes au niveau ontologique et au niveau donnes. Une
premire monture est implante sur le SGBD/RO PostGreSQL. Elle offre une nouvelle faon
de concevoir des applications de bases de donnes en stockant dans la base de donnes explicitement les donnes, le modle conceptuel qui dfinit la structure des donnes et lontologie qui
dfinit le sens de ces donnes. Il est dot du langage OntoQL qui a t prsent au chapitre 1.
Celui-ci permet la fois dinterroger les ontologies, les donnes mais aussi les deux simultanment. Il prvoit galement la possibilit dutiliser le langage SPARQL. OntoDB se fonde sur les
hypothses de typage fort des proprits 14 et des instances 15 , la compltude de dfinition et la
mono-instanciation. La BDBO OntoDB a t largement utilise dans des projets industriels et
14. Toute proprit doit avoir un domaine et un co-domaine uniques;
15. toute instance du domaine ne peut tre dcrite que par des proprits applicables sa classe de base.
78
3. Etude des BDBO

ANR (Projet ANR DaFOE4App: Differential And Formal Ontologies Editor For Applications
et ANR E-wok hub: http://www-sop.inria.fr/edelweiss/projects/ewok/, etc.). Cette utilisation a
t souvent base sur les donnes techniques qui sont reprsentes par le formalisme PLIB.
3.1.1.1 Formalisme dontologies. Les ontologies gres jusque-l sous OntoDB, sont conformes au modle dontologies PLIB. Cependant, OntoDB est prvue pour supporter nimporte
quel type dontologie. En effet, larchitecture dOntoDB dispose dun mta-schma susceptible
de prendre en compte tout schma dontologie. Cela offre une structure de donnes pour manipuler aussi les ontologies RDFS, OWL et autres formalismes dontologies.
3.1.1.2 Architecture et Modle de stockage. OntoDB utilise une architecture "quatre quarts"
illustre sur la figure 3.1. Elle se compose des quatre parties :
partie ontologie qui stocke les ontologies cest--dire les concepts permettant de reprsenter la signification des donnes (partie donne);
partie mta-schma qui permet de reprsenter le modle dontologies et le mta-schma
lui-mme. Elle permet de rendre gnrique le traitement sur les ontologies ;
partie donnes qui contient les instances cest--dire les donnes proprement dites ;
partie mta-base, appele galement "catalogue systme", est la partie classique des SGBD
qui contient la description des objets (tables, vues, index,...) de la base de donnes.
OntoDB utilise un modle de stockage horizontal pour reprsenter les instances : une table
est cre pour chaque classe de lontologie, ses colonnes correspondent au sous-ensemble de
proprits applicables de la classe, autrement celles qui sont utilises par au moins une instance
de la classe.
3.1.1.3 Formalisation. Une BDBO OntoDB dans notre modle unifi est exprime par :
BDBOOntoDB :< MO :<C, P, Applic, Ref(C), PLIB>, I, Sch, Pop :classe >table, Spcifique,
Horizontal, Type III>. o <C, P, Applic, Ref(C), PLIB> reprsente une ontologie PLIB (cf;
exemple 1), Pop associe chaque classe la table correspondante.
3.1.2
Base de Donnes Base Ontologique Oracle
La compagnie Oracle a rcemment ajout son SGBD le support des langages RDF et OWL
pour permettre ses clients de bnficier dune plate-forme de gestion de donnes smantiques.
Cette fonctionnalit a t implante pour la premire fois dans le SGBD Spatial Oracle 10g et
est dsormais en option dans les bases de donnes Oracle sous le nom de Oracle Spatial and
Graph.
Oracle propose les fonctionnalits suivantes pour les BDBO :
le stockage, le chargement et laccs aux donnes et aux ontologies travers le langage
de manipulation de donnes ;
79

UML_ATTRIBUTE
_ t
:
(2)
Partie mta-schma
UML_CLASS
nom
ID
111
superclass
Mta-modle dontologie
Class
1
nom : string
*
properties
1
Partie mta-base
UML_class
name
class
Meta_table
ID
1111
UML_attribute
ID
112
property
nom : string
name
nom
ID
1112
Modle dontologie PLIB
(4)
name
P erso n ne
E tu d ia nt
rid
12
P3
Property
name
email

inscrit
String
nom
inscrit
rid
P1
nom
Lola
email
lol@
(3)
Etudiant
rid
E1
Personne
subclassOf
Universit
name
nom
Partie donnes
Personne
C la ss
r id
11
12
(1)
Meta_column
Partie ontologie
superclass
name
Personne
nom
Bery
inscrit
UP
ID01
Lola
nom
inscrit
Bery
UP
nom
sexe
Etudiant
ontologie
Lola
instances dontologie
Figure 3.1 Architecture OntoDB

la dduction de connaissances en utilisant les rgles smantiques RDF/OWL et celles
dfinies par lutilisateur ;
linterrogation de donnes RDF/OWL et des ontologies en utilisant les patrons de graphe
similaires SPARQL inclus dans SQL (SEM_MATCH) ;
linterrogation de donnes relationnelles assiste par lontologie.
Oracle en collaboration avec les dveloppeurs de Jena, ont mis en place une API appele Oracle
Jena Adaptor. Cette API implante et tend lAPI Jena 16 qui est bien connue des dveloppeurs
des applications utilisant les ontologies. Les interfaces Graph et model de Jena ont t particulirement enrichies. Oracle Jena adaptor tend donc les capacits de gestion de donnes
smantiques dOracle (Oracle 10gR2 RDF et Oracle 11g RDF/OWL) avec un ensemble de mthodes Java faciles utiliser pour la plupart des fonctionnalits offertes. Un travail semblable
fait avec les dveloppeurs de Sesame a donn lieu une API appele Oracle Sesame Adaptator.
3.1.2.1 Formalisme dontologies. La BDBO Oracle prend en compte les ontologies RDF
et OWL prsentes sous le format N-Triples. Pour OWL, Oracle a dfini deux sous-ensembles
dOWL-DL quelle traite dans les processus dinfrence [148] : OWLPrime et OWLSIF.
16. A Semantic Web Framework for Java - http://jena.sourceforge.net
80
3. Etude des BDBO

3.1.2.2 Architecture et Modle de stockage. Oracle utilise une architecture de type I ("deux
quarts") et un modle de stockage vertical (table de triplets). La table de triplets utilise a t
dcompose pour viter de manipuler les longues chanes de caractres (les URIs) [148]. Les
valeurs lexicales des sujets, prdicats et objets sont mappes en identificateur (ID) entiers gnrs par le systme. Une table de correspondance appele RDF_Value fait le lien entre les URI,
les littraux et les identifiants gnrs. Etant donn un triplet RDF, ses trois composantes (URI
ou littraux) sont ainsi mappes aux identificateurs correspondants dans la table RDF_Value.
Si aucune correspondance nest trouve pour un URI, un identifiant (ValueId) est gnr et la
correspondance est insre dans la table RDF_Value. Un tuple comprenant lidentifiant du modle (Model_Id) et les trois identifiants des URI est stock dans la table des triplets appele
RDF_LINK$ . La table RDF_LINK$ permet de stocker tous les triplets de tous les modles
smantiques de la base de donnes. La table RDF_LINK$ est fragmente (horizontalement)
sur lattribut MODEL_ID qui a une valeur unique pour chaque modle (smantique ou infr).
Ainsi, chaque partition correspond un modle smantique ou un modle de donnes infr.
3.1.2.3 Formalisation. Dans notre formalisation, une BDBO Oracle est reprsente par:
BDBOOracle :< MO :<C, P, Ref(C), (RDFS, OWLSIF ou OWLPrime)>, I, Sch, Pop, Vertical,
Vertical, Type I>,
o Ref(C) : Application doprateurs des langages RDFS, OWLSIF et OWLPrime sur les classes
et proprits; I : les instances (tables RDF_link et RDF_values); Applic retourne pour chaque
classe c, retourne toutes ses proprits.
3.1.3
Base de Donnes Base Ontologique SOR dIBM
La socit IBM sest investie dans plusieurs travaux sur les technologies dintgration et
de gestion des donnes smantiques et surtout celles relatives au Web Smantique. Elle sest
implique dans le dveloppement doutils dexploitation des ontologies qui sont un maillon
important du Web Smantique [149]. Parmi les outils bass sur les ontologies mis au point
par IBM, nous trouvons Integrated Ontology Development Toolkit (IODT): un outil ddi au
stockage, la manipulation, linterrogation et linfrence des ontologies et leurs instances.
Dans le cadre de notre travail, nous nous sommes intresss SOR [59] qui est un rfrentiel
des ontologies OWL. SOR est incorpor dans IODT. Il comprend un raisonneur et un outil de
recherche. Il utilise pour le stockage une base de donnes relationnelle notamment DB2.
3.1.3.1 Formalisme dontologies. Les outils de SOR sont destins manipuler les ontologies du Web Smantique notamment le formalisme OWL. Cependant, limplantation actuelle
manipule les ontologies OWL-Lite et OWL-DL.
81

3.1.3.2 Architecture et Modle de stockage. SOR utilise une architecture type II ("trois
quarts") pour le stockage des ontologies et de leurs instances. Il spare les ontologies des instances et prvoit un mcanisme de raisonnement dans son modle de stockage. Ainsi, il met
en uvre un modle de stockage spcifique. En effet, SOR propose un schma qui prend en
compte des constructeurs complexes. Dans ce schma, tous les prdicats des rgles dinfrence
ABox 17 ont des tables correspondantes dans la base de donnes. Ainsi, ces rgles sont facilement traduisibles en une squence doprations de lalgbre relationnelle. Quatre catgories de
tables sont dfinies dans le schma de SOR : tables atomiques, tables des axiomes TBox, tables
des faits ABox et tables des constructeurs de classes.
Les tables atomiques. Les tables atomiques sont les tables : Ontology, PrimitiveClass,
Property, Datatype, Individual, Literal et Resource. Ces tables encodent lURI avec un identifiant entier qui rduit la longueur des URI. Elles disposent dune colonne hashcode qui est
utilise pour acclrer la recherche sur les URI et dune colonne ontologyID qui indique de
quelle ontologie une URL provient. La table Property stocke les caractristiques des proprits
(symtrique, transitive, etc.). Pour profiter des oprations de comparaison internes aux bases de
donnes, les littraux boolens, dates et numriques sont reprsents sparment en utilisant les
types de donnes correspondants fournis par les bases de donnes.
Les tables des faits ABox. Il y a trois sortes dassertions ABox dvelopps dans le raisonnement : les assertions TypeOf, Datatypeproperty et Objectproperty. Les triplets de ces assertions sont stocks dans trois tables diffrentes : TypeOf, RelationshipInd et RelationshipLit. Une
vue nomme Relationship est construite comme un point dentre aux triplets objectproperty et
aux triplets datatypeproperty. Les triplets non pertinents au raisonnement tels que ceux dont le
prdicat est RDFS:comment, sont stocks dans la table Utility.
Les tables daxiomes TBox. Ce sont des tables utilises pour garder les axiomes TBox.
Il sagit des tables SubClassOf, SubPropertyOf, Domain, Range, DisjointClass, InversePropertyOf.
Les tables des constructeurs de classes. Les tables des constructeurs de classes sont utilises pour stocker les expressions de classe. SOR dcompose une description complexe de
classe en instances de concepts de classe OWL, assigne un nouvel ID chaque instance et la
stocke dans la table de la classe correspondante.
17. Une base de connaissances en Logique de Description est compose de TBOX (Terminological Box) dcrivant les connaissances intentionnelles du domaine sous forme daxiomes, et de ABOX (Assertion Box) dcrivant
les connaissances extensionnelles du domaine (les instances).
82
3. Etude des BDBO

Une telle conception est motive par lexplicitation de la smantique de description des
classes complexes. De cette faon, tous les nuds dans un arbre de subsomption OWL sont
matrialiss dans les tables de la base de donnes et les rgles dinfrence peuvent ainsi tre
facilement implantes et rapidement excutes via les instructions SQL. Le module de stockage
est destin conserver les triplets originaux et les assertions infres par le raisonneur DL et
le moteur dinfrence. Mais les assertions infres sont identifies grce un flag spcifique.
Ce schma a lavantage que certaines jointures se font entre les tables de petites dimensions
contrairement dautres reprsentations dont les jointures se font sur la table centrale. En plus,
il est indpendant de lontologie utilise.
3.1.3.3 Formalisation. La reprsentation des BDBO SOR dans notre modle unifi est :
BDBOS ORIBM :< MO :< C, P, Applic, Re f, OWL >, I, Sch(c), Spcifique, Binaire, Type II >.
Sch(c) renvoie les proprits qui ont de valeurs de la classe c; o Ref traduit une application
doprateurs de la logique de description (LD) sur les classes et proprits; I : les instances des
tables.
3.1.4
Base de Donnes Base Ontologique DB2RDF dIBM
Parmi les travaux rcents de IBM sur lexploitation de la smantique des donnes, on trouve
DB2RDF [150, 151] qui est un systme de gestion de bases de donnes smantiques (Base de
donnes RDF). IBM la intgr dans la nouvelle version de son SGBD (DB2 10.1) mais on peut
lutiliser aussi sur DB2 9.6. IBM fournit un certain nombre de fonctions pour la gestion des
donnes ontologiques dans un environnement Java (bas sur les paquetages de jena). DB2RDF
supporte le langage SPARQL et utilise comme format de donnes le N-Triple [152] comme
oracle. DB2RDF ne fait pas encore des dductions de donnes.
3.1.4.1 Formalisme dontologies. La BDBO DB2RDF utilise dans sa version actuelle le

formalisme RDF/RDFS. Pour pouvoir tre charges, les instances ontologiques doivent tre
exprimes au format N-Triple.
3.1.4.2 Architecture et Modle de stockage. la BDBO DB2RDF utilise une architecture

de type deux quarts. Elle utilise un modle de stockage vertical pour stocker ses donnes
(schma et instances) mais ce modle est enrichi par lutilisation de plusieurs tables [153] dont
les quatre principales sont :
la table Direct primary qui stocke les triplets avec un index sur le sujet. Les prdicats et
les objets propres un sujet sont stocks dans des colonnes paires de cette table.
La table Direct Secondary est utilise pour stocker les objets RDF qui partagent les
mmes sujets et prdicats.
83

La table Reverse primary qui stocke les triplets indexs par leur objets. Les prdicats et
les sujets dun objet sont stocks dans des colonnes paires de cette table.
La table Reverse Secondary qui stocke les sujets des dclarations RDF qui partagent les
mmes objets et prdicats.
Comme oracle, DB2RDF utilise des identifiants pour viter de manipuler des longues chanes
dURI.
3.1.4.3 Formalisation. Une BDBO DB2RDF dans notre modle unifi est dfinie par :
BDBODB2RDF :< MO :<C, P, Applic, Ref, RDFS>, I, Sch, Pop, Vertical, Vertical, Type I>,
o Applic retourne pour chaque classe c, toutes ses proprits.
3.1.5
Base de Donnes Base Ontologique Sesame
La BDBO ssame est un framework de gestion des donnes smantiques dvelopp par
Aduna, un diteur nerlandais de logiciels. Ssame permet le stockage et linterrogation des
ontologies et de leurs instances. Cest un outil facile utiliser et fournissant une API permettant
une connexion tout systme de stockage de donnes smantiques. Elle offre la possibilit de
faire des infrences de donnes. Sesame est flexible en ce sens quil peut tre dploy sur des
systmes de stockage varis : mmoire centrale, systmes de fichiers, bases de donnes relationnelles, etc. Elle dispose de son propre langage dinterrogation (SeRQL) mais supporte aussi
le langage de requtes SPARQL (le standard du W3C 18 ). Sesame offre un accs transparent
des rfrentiels RDF distants en utilisant exactement la mme API que pour laccs local.
3.1.5.1 Formalisme dontologies. La BDBO Ssame a pour vocation de grer les donnes
du Web Smantique. Elle supporte les modles dontologies RDF/RDFS et OWL.
3.1.5.2 Architecture et Modle de stockage. Ssame utilise une architecture de type I

comme dans une base de donnes relationnelles. Pour le modle de stockage, elle utilise la
reprsentation verticale et la reprsentation binaire. Nous avons considr les deux reprsentations dans les valuations des performances (cf. section 4).
3.1.5.3 Formalisation. Une BDBO Sesame dans notre modle unifi est dfinie par :
BDBOS esame :< MO :<C, P, Applic, Ref, RDFS ou OWL>, I, Sch, Pop, Vertical ou Spcifique,
Vertical ou Binaire, Type I>,
o Applic et Pop sont identiques celles de la BDBO Oracle. I reprsente les instances de la
table des triplets ou des tables de proprits suivant la reprsentation.
18. World Wide Web Consortium, un organisme de normalisation charg de promouvoir la compatibilit des
technologies du World Wide Web
84
3. Etude des BDBO

3.1.6
Base de Donnes Base Ontologique Jena
Jena est une architecture pour stocker et grer les donnes ontologiques. Cest aussi un
framework open-source pour dvelopper des applications pour le Web smantique. Elle fournit
un environnement de programmation pour les modles dontologies RDF Schema et OWL. Jena
utilise comme langage de requte SPARQL. Il propose de moteurs dinfrence base de rgles
(prdfinies et utilisateur).
3.1.6.1 Formalisme dontologies. Comme Sesame la BDBO Jena est oriente vers la gestion des donnes du Web Smantique. Elle prend en compte les modles dontologies RDF/RDFS
et OWL.
3.1.6.2 Architecture et Modle de stockage. Jena propose plusieurs faons de rendre persistantes les donnes que lon regroupe sous deux vocables :
1. TDB (Tuple DataBase), un stockage fond sur le systme de gestion des fichiers ou la
mmoire,
2. SDB (SPARQL DataBase), un systme de stockage utilisant une base de donnes standard.
Cest ce dernier qui fait lobjet de notre travail car nous parlons des bases de donnes base
ontologique. Il existe deux versions de Jena : la premire version appele jena1 utilise la reprsentation verticale (table des triples) [7] et la deuxime version jena2 utilise une reprsentation
spcifique (property-table et class-property-table) [6]. Dans les deux cas, larchitecture est de
type "deux quarts". Nous utiliserons jena2 dans notre travail.
3.1.6.3 Formalisation. Une BDBO Jena dans notre modle unifi est dfinie par :
BDBO Jena :< MO :<C, P, Applic, Ref, RDFS>, I, Sch, Pop, Vertical, Vertical, Type I>, pour le
cas o la reprsentation verticale est utilise et par
BDBO Jena :< MO :<C, P, Applic, Ref, RDFS>, I, Sch, Pop, Vertical, Binaire, Type I> lorsque
lon utilise le modle binaire. I reprsente les instances de la table des triplets ou des tables de
proprits suivant la reprsentation.
3.2 Critres de comparaison des BDBO

Pour dtailler notre comparaison des BDBO, nous avons identifi quelques critres de comparaison essentiels des BDBO. Le tableau 3.2 rcapitule ces critres pour les BDBO considres (Oracle, IBM SOR, DB2RDF, OntoDB, Jena et Sesame).
Nous prsentons brivement chacune de ces caractristiques hormis, les modles de stockage, larchitecture et le formalisme qui ont t dj prsents et le SGBD qui sont les supports
standards de persistance.
85

3.2.1
change de donnes
Cette caractristique indique si la BDBO facilite le transfert de ses donnes sur une autre
BDBO. En effet, une BDBO est base sur une ontologie qui est une conceptualisation consensuelle dun domaine, dont chaque lment est rfrenable. Les donnes des BDBO utilisant
la mme ontologie peuvent tre changes car cette ontologie peut tre considre comme un
format dchange de donnes sur ce domaine. Cette fonctionnalit est importante quand on est
dans un environnement ncessitant de lintgration des donnes.
3.2.2
Support linguistique
Cette caractristique indique si une BDBO est capable de prendre en compte les concepts
dune ontologie dfinis dans plusieurs langues naturelles. En effet, comme nous lavons vu
au chapitre 1, dans certains modles dontologies (RDFS, OWL, PLIB) le multilinguisme est
utilis pour dcrire les ontologies et les donnes.
3.2.3
Langage de requtes
A fin de permettre linterrogation de ses ontologies et ses instances ontologiques, une BDBO
doit supporter au moins un langage de requtes. Celui-ci doit permettre dajouter, modifier et
supprimer les instances dune BDBO ainsi que de dfinir les classes quelles instancient et
les proprits qui les caractrisent. Pour chaque BDBO, nous listons les langages de requtes
quelle supporte dans le tableau 3.2.
3.2.4
Extraction dontologies
Cette caractristique indique si on peut extraire dune BDBO un sous-ensemble des concepts
de lontologie. Les concepts extraits de la base de donnes doivent tre cohrents. Dans la plupart des BDBO, une requte SPARQL portant sur le schma dontologie peut permettre une
extraction.
3.2.5
Scurit des donnes
Cette caractristique est fondamentale dans les bases de donnes classiques. Les donnes
doivent tre protges des accs non autoriss ou mal intentionns [154]. Une BDBO est sense
disposer des mcanismes permettant lautorisation, le refus ou la rvocation de privilge daccs
aux donnes et une ontologie. La plupart des BDBO profite de mcanismes de scurit offerts
par les SGBD relationnel ou relationnel-objet sous-jacents.
86
3. Etude des BDBO

3.2.6
Gestion des versions et volutions des ontologies
Les ontologies sont susceptibles dvoluer. En effet, les ontologies peuvent tre modifies
quand elles ne satisfont plus les besoins dune communaut. Les causes des modifications
peuvent tre :
lintgration de nouveaux concepts et/ou de nouvelles proprits ;

la suppression des concepts ;
le changement de systme de classification ;
la modification de contraintes ;
la modification des concepts (fusion ou sparation dentits) ;
la modification du domaine ou du co-domaine des proprits ;
etc.
Une volution entrane la dfinition de nouvelles versions de ces ontologies. Le principe de

versioning [155] nonce que la gestion de lvolution de lontologie exige de pouvoir conserver
et accder aux diffrentes versions de lontologie gnres au cours de lvolution, ainsi que de
permettre de spcifier par un modle les relations qui rendent compte des modifications faites
entre les versions. Cette fonctionnalit est ncessaire pour prserver les relations smantiques
existantes entre les diffrents concepts des ontologies lors de lintgration dans la BDBO de
nouvelles versions. Cette caractristique nest pas prise en compte dans la plupart des BDBO
utilises ; seule la BDBO OntoDB est prdispose cette gestion et la gestion des cycles de
vie des instances dcrit ci-dessous.
3.2.7
Cycle de vie des instances
Cest une fonctionnalit qui permet une BDBO de grer lvolution des instances. De
la mme manire que les ontologies, les donnes ontologiques voluent. Une volution dune
ontologie peut modifier la structure des instances comme par exemple lors de lajout dune
proprit ou dun concept. Mme les oprations sur les instances (ajout, suppression ou mise
jour) entranent lvolution des instances. Une BDBO peut offrir un mcanisme pour pouvoir
accder toutes les instances des concepts existants dans une version donne et des mcanismes
pour une gestion du cycle de vie des instances des classes.
3.2.8
Moteur dinfrence
Un moteur dinfrence est un outil qui permet de dduire de nouvelles connaissances ou

donnes partir de celles qui sont disponibles. Certaines BDBO disposent de leurs propres moteurs dinfrence pour la dduction de nouvelle donnes partir de celles qui sont disponibles
(Oracle, SOR). Dautres font usage des moteurs dinfrence ontologiques existant comme Racer, Pellet, Fact, Fact++.
87

3.2.9
Base de rgles utilisateur
Parmi les BDBO qui disposent de moteurs dinfrence, certaines offrent lutilisateur la
possibilit de crer sa propre base des rgles. Cest le cas dOracle, de Jena ou de Sesame. Les
rgles sont en gnral de la forme : clause consequence. La dduction peut se faire lors
du chargement de donnes (pour les BDBO satures) ou linitiative de lutilisateur aprs le
chargement de donnes.
3.2.10
Exportation des donnes
Cest une fonctionnalit qui permet dextraire dune BDBO un sous-ensemble des instances
associes certains concepts. Les instances extraites de la base de donnes doivent tre consistantes et cohrentes. Cette fonctionnalit permet le partage et lintgration des donnes.
3.2.11
Vrification de la consistance
Cette fonctionnalit permet une BDBO de sassurer quune ontologie est consistante cest-dire quelle est conforme son modle. La vrification peut porter aussi sur les instances. La
vrification de la consistance dune instance se fait en utilisant les axiomes dfinis dans lontologie. La plupart des BDBO ont des modules qui effectuent cette vrification soit automatiquement (SOR, OntoDB) soit la demande de lutilisateur (Oracle, Jena, Sesame).
4 Etude de performances des BDBO

Pour aller plus loin dans notre comparaison des BDBO, nous prsentons dans cette section une batterie dexprimentation pour valuer les six BDBO tudies selon deux critres:
le temps de chargement des instances ontologiques et le temps dexcution de requtes. Nous
prsenterons dabord lensemble des donnes sur lesquels les exprimentations sont effectues,
puis les rsultats des tests et leurs interprtations.
4.1 Ensembles de donnes et environnement de tests

Pour disposer des donnes ontologiques ncessaires pour nos tests de performance, nous
avons utilis le banc dessai LUBM [30] qui utilise le formalisme OWL. Il cre une ontologie
sur le domaine universitaire. Chaque universit est constitue de 15 20 dpartements. Dans
chaque dpartement, nous retrouvons des enseignants de diffrentes catgories, des tudiants,
des cours, etc. Le schma de cette ontologie est prsent sur la figure 3.2.
Nous avons gnr trois ensembles dontologies ayant respectivement 1, 5 et 10 universits
(Lubm01, Lubm05 et Lubm10). Le nombre dinstances ontologiques dans chaque ensemble
88
4. Etude de performances des BDBO

Critres
Formalisme
change de donnes
Support linguistique
Langage de requtes
Extraction dontologies
Scurit des donnes
Gestion des versions et volutions des ontologies
Cycle de vie des instances
Moteur dinfrence
Base de rgles utilisateur
Exportation des donnes
Vrification de la consistance
Modle de stockage dontologies
Modle de stockage des instances
Architecture
SGBD actuellement utiliss
Oracle
RDF,
OWL
oui
oui
sql,
sparl
SOR
OWL
Sesame
RDF,
OWL
oui
non
serql,
sparql
Db2rdf
RDF
oui
oui
non
OntoDB Jena
PLIB
RDF,
OWL
oui
Oui
oui
oui
oui,
non
sparql ontoql, rql,
sparql
Rdql,
sparql
oui
oui
oui
oui
oui
oui
non
oui
non
oui
oui
non
oui
oui
non
non
oui
oui
oui
oui
Vertic.
non
oui
non
oui
oui
Spcif.
non
oui
oui
oui
oui
Vertic.,
specif.
vertic.,
binaire
2/4
Oracle,
Postgres,
mysql
non
non
non
oui
oui
Vertic.
oui
non
non
oui
oui
Spcif.
non
oui
oui
oui
oui
Vertic.,
specif.
Verticale Binaire Horiz.
Vertical,
specif.
2/4
3/4
4/4
2/4
Oracle DB2, Postgres Oracle,
Derby
Postgres,
mysql
oui
non
sql,
sparql
vertic.
2/4
DB2
Table 3.2 tableau comparatif des BDBO tudies (vertic : verticale, horiz: horizontale, specif :
spcifique)
ainsi que leurs nombres triplets sont indiqus dans le tableau 3.3. Notons que les outils proposs
par Oracle et DB2RDF ne chargent que des donnes au format N-TRIPLE (sujet, prdicat,
objet). En consquence, une conversion des donnes de notre banc dessai dfini en OWL vers
le format N-TRIPLE [152] fut ncessaire. Pour ce faire, nous avons utilis lAPI Jena appele
rdfcat.
Nos valuations ont t ralises sur un ordinateur (DELL) dot dun processeur Intel(R)
Xeon(R) CPU E31225 3.10 GHZ et dune mmoire vive de 4GO et dun disque dur de 500Go.
Les systmes de gestion bases de donnes (SGBD) utiliss sont : Oracle 11g pour la BDBO
Oracle, IBM DB2 9.6 pour SOR et DB2RDF et PosgresSQL 8.2 pour OntoDB, Jena et Sesame.
89

AdvisorOf
Is take
Person
Administrative
Staff
UnderGraduate
Studentt
Employee
Post Doctorate
Student
GraduateStudent
Faculty member
Is take
advisorOf
Is take
TeachingAssistantOf
Professor
SubClass
Assistant
Professor
Associate
Professor
Full Professor
Course
Graduate Course
Research Work
Teaching Course
Work
TeacherOf
Figure 3.2 Schma de lontologie LUBM.

Jeux de Donnes
Lubm01
Lubm05
Lubm10
Nombre dinstances
82415
516116
1052895
Nombre de triplets
100.851
625.103
1.273.108
Table 3.3 Ensembles de donnes gnres.
4.2 Performances en termes de chargement des donnes (ontologie et instances)

Cette partie concerne les chargements de lontologie et de ses instances dans nos BDBO.
Notre mode opratoire se rsume en quatre points : (1) la gnration de donnes OWL ; (2) la
conversion et concatnation de ces donnes dans un fichier N-Triple pour Oracle et DB2RDF ;
(3) le calcul du temps de chargement (en sec.) des instances dans chaque BDBO ; et (4) linterprtation des rsultats.
Pour avoir des rsultats homognes, nous avons effectu quatre fois le chargement de chaque
ensemble de donnes et nous avons retenu la moyenne obtenue. Les rsultats sont consigns
dans le tableau 3.4.
4.2.1
Chargement de donnes dans BDBO Oracle
Oracle offre trois moyens pour charger les ontologies et les donnes base ontologique dans
une base de donnes :
Bulk load (chargement global);
90

Batch load (chargement par lot);
Load into table (chargement par linstruction insert into table).
4.2.1.1 Bulk load (chargement global.) Cest la mthode la plus rapide pour charger les
donnes bases ontologiques dans une BDBO Oracle. Elle utilise lutilitaire SQLLoader. Pour
tre charges, les donnes doivent tre mises dans des fichiers ou des tubes au format N-Triple.
Elles sont dabord charges dans une table de relai avant dtre envoyes dans la base de donnes
grce la procdure SEM_APIS.BULK_LOADER_FROM_STAGING_TABLE. Cette mthode
de chargement a le dfaut de ne pas prendre en compte les littraux de plus de 4ko. Le processus
de chargement est schmatis sur la figure 3.3.
Donnes base
ontologique au
format
N-Triple
SQLLoader
-./01 213456.761
89- 67401
BulkLoader
BDBO Oracle
Figure 3.3 Processus de chargement global dOracle.
4.2.1.2 Batch load (chargement par lot). Cette mthode a lavantage de prendre en compte
les littraux de plus de 4ko. Il utilise une classe java (la classe BatchLoader) pour charger les
donnes au format N-Triple dun fichier.
4.2.1.3 Load into table (chargement par linstruction insert into table) Cest la mthode
classique dinsertion de donnes dans une base de donnes. Elle utilise les instructions du
LMD 19 (Insert, update) sur les tables de donnes smantiques. Elle est recommande pour le
chargement de faibles quantits de donnes. Cette mthode ncessite lutilisation du constructeur SDO_RDF_TRIPLE_S (voir exemple 2).
Pour nos tests, nous avons fait le chargement global (Bulk Load) et le chargement par lot
(Batch Load). Pour le premier, nous avons mesur le temps de chargements des donnes dans la
19. langage de manipulation des donnes
91

table de relais (appele Staging Table) et le temps de transfert dans le modle smantique. Pour
raliser cette valuation, nous avons utilis lutilitaire dOracle Sqlloader qui renvoie le temps
quil met pour charger les donnes. Pour le temps de transfert, nous avons utilis le chronomtre
dOracle. Le temps de chargement est alors gal la somme de ces deux temps.
Pour le chargement par lot, la mesure du temps a t facilite par lAPI utilise. En effet,
la fin du chargement, un rsum du droulement du processus est renvoy et le temps mis est
affich. Dans les deux cas, aprs chaque chargement, nous supprimons et recrons le modle
smantique, avant deffectuer un autre chargement.
Exemple 2
Pour insrer le triple (Bery, travaille, Oracle Techno), dans le modle MdLias, dont la table
smantique est tab_lias, on excute linstruction : INSERT INTO tab_lias VALUES (1000,
sdo_rdf_triple_s(MdLias, Bery,travaille, Oracle Techno));
4.2.2
Chargement de donnes dans la BDBO SOR dIBM
SOR dispose dun module dimportation permettant le chargement des donnes ontologiques dans une base de donnes relationnelle. Ce module est form dun analyseur (parser)
OWL et de deux traducteurs (DB Translator et TBox Translator). Le parseur examine et charge
les fichiers OWL dans un modle EODM 20 . Le DB Translator charge les assertions ABox dans
la base de donnes. Le TBox Translator a deux tches. La premire consiste charger les
axiomes de la TBox dans le raisonneur DL et la seconde consiste faire des dductions de
donnes et de les insrer dans la base de donnes. Pour faire une valuation de performance
de SOR, nous nous sommes servis de lIODT 21 . Nous avons utilis comme SGBD, IBM DB2
Express 9. Nous avons charg les diffrents ensembles de donnes LUBM gnres dans SOR.
A la diffrence des chargements sous Oracle et DB2RDF, les donnes nont pas subi de transformation de format, elles sont restes au format OWL. Pour chaque ensemble de donnes, nous
avons mesur le temps mis pour son chargement.
4.2.3
Chargement de donnes dans la BDBO DB2RDF
A limage dOracle, DB2RDF accepte les donnes au format N-triple. Pour cela, nous avons
utilises les donnes converties en N-Triple. Puis nous avons utilis les fonctions pour le chargement fournies dans un environnement Eclipse, pour charger les donnes. Le temps de chargement est mesur pour chaque ensemble de donnes.
20. Eclipse Modeling Framework (EMF) Ontology Definition Metamodel
21. Integrated Ontology Development Toolkit - http://www.alphaworks.ibm.com
92

4.2.4
Chargement de donnes dans la BDBO OntoDB
Bien quOntoDB soit prdispos prendre en compte tout formalisme dontologies ; il nest
actuellement quip que dun module de chargement dontologie PLIB. Vu le fait que lontologie que nous utilisons pour les exprimentations est reprsente en OWL, nous devons proposer
un moyen pour charger cette ontologie dans OntoDB. Une solution possible serait de faire un
programme permettant dobtenir une ontologie PLIB partir dune ontologie OWL et de la
charger dans OntoDB. Mais, vu la diffrence et la diversit des constructeurs et des oprateurs
des deux formalismes, lontologie obtenue de cette manire nest ni congruente ni quivalente
lontologie de dpart. Nous avons donc prfr dvelopper un module de chargement dOWL
dans OntoDB.
Ainsi, nous avons mis en place un module dimportation des ontologies OWL et leurs instances dans OntoDB. Ce module prend en paramtre une ontologie OWL et ses instances et,
aprs une analyse, il extrait les concepts (classes et proprits) et leurs instances, puis il cre
les tables correspondantes dans la BD et les remplit par les instances appropries. Nous nous
sommes intresss la partie canonique de lontologie OWL (les concepts primitifs).
De manire formelle, notre module est une application dappariement des concepts du formalisme dontologie OWL en concepts PLIB disponibles dans OntoDB. Si on note T, cette
application, T est dfinie par : T :< OOWL , Eowl >< OOntoDB , EOntoDB > o OOWL et EOWL
sont respectivement une ontologie et un concept de lontologie OWL, et o OOntoDB et EOntoDB
sont respectivement ontologie et lobjet(table, attribut ou valeur) dans OntoDB (au formalisme
dontologie PLIB). Soit C, P lensemble de classes et des proprits canoniques de lontologie
O en OWL. T se base sur deux considrations principales :
c C , T (OOWL , c) est une classe de PLIB dfinie dans OntoDB, par une table ;
p P, T (OOWL , p) est une proprit de PLIB attache Domaine(p) cest--dire, toutes
les classes qui sont domaines de la proprit p.
Il faut noter que cette correspondance nest pas parfaite et elle est irrversible du fait que
les concepts OWL non canoniques ne sont pas pris en compte et quil nest pas possible de
retrouver lontologie initiale par une application inverse. Notons galement que notre utilitaire
ne travaille que sur des ontologies acycliques. Cela est une exigence de modle dontologie
PLIB qui est au cur du systme OntoDB. Les ontologies PLIB ne comporte pas de cycles
cest--dire que lorganisation des classes et des proprits est telle quon ne peut pas avoir un
cycle. Or lontologie LUBM renferme des cycles. Nous avons rompu les cycles en transformant
les proprits de type objectproperty lorigine des cycles en datatypeproperty.
4.2.5
Chargement de donnes dans les BDBO Jena et Sesame
Pour les chargements de donnes dans les BDBO Jena et ssame, nous avons utilis un environnement Eclipse identique celui utilis pour SOR et DB2RDF. Pour chaque BDBO, nous
avons mis en uvre les modles et fonctions ncessaires pour le chargement. Etant donn que
93

Sesame donne la possibilit davoir des BDBO de type I et de type II, nous avons expriment
ces deux types. Dans ce qui suit, nous appelons SesameBdsI, le systme Sesame utilisant la
reprsentation verticale (BDBO de type I) et SesameBds2, le systme Sesame utilis comme
BDBO de type II. Les temps de chargement moyens sont consigns dans le tableau 3.4.
4.2.6
Temps de chargement
Les temps moyens de chargement des diffrents jeux de donnes dans les BDBO tudies
sont consigns dans le tableau 3.4. La figure 3.4 prsente un histogramme de ces rsultats. Les
temps de chargement du systme OntoDB ny sont pas reprsents du fait quils sont dune
chelle de grandeur suprieure celles des autres BDBO.
Dataset
Oracle Batch
Oracle Bulk
IBM SOR
DB2RDF
Jena2
SesameBdsI
SesameBdsII
OntoDB
Lubm01
42
12
90
11
25
16
27
15975
Lubm05
222
55
590
53
188
158
231
72699
Lubm10
302
116
1147
109
558
391
522
146023
Table 3.4 Rcapitulatif des temps de chargement (sec).
4.2.7
Interprtation des rsultats
En termes de chargement, comme on le constate sur le tableau 3.4 et la figure 3.4, DB2RDF
et Oracle (Bulk) fournissent de trs bons rsultats, suivi dans lordre de SesameBdsI, Jena,
SesameBdsII, Oracle Bulk et SOR. OntoDB se montre plus lente que les autres BDBO tudies. Pour DB2RDF et Oracle (Bulk), cette performance peut sexpliquer par le fait que peu
doprations sont effectues sur des donnes linsertion dans ces systmes mais aussi par la
puissance des SGBD utiliss (oracle et DB2). La BDBO Ssame utilisant la table de triplets
se relve plus performant que Jena 22 par contre, Sesame utilisant une reprsentation binaire
donne de moins bonnes performances que Jena. En effet, Jena utilisant les tables property-table
et class-property-table prend du temps pour dispatcher les donnes dans les tables indiques.
La BDBO SOR prend assez de temps pour les transpositions du schma dontologies (T-Box)
et des instances ontologies (A-Box) en des tuples pour les diffrentes tables. Elle met aussi un
temps important pour faire les infrences des donnes au niveau de lontologie et des instances.
22. Jena version 2
94
Figure 3.4 Temps de chargement des donnes.

Cela justifie le fait que le temps de chargement est moins bon que ceux des certaines BDBO
mises en vidence.
La lenteur que lon observe sur OntoDB sexplique par les multiples sous-requtes prsentes
dans la plupart des requtes dinsertion des instances. En effet, OntoDB utilise les identifiants
dobjet (Oid) pour traduire les rfrences aux objets(les cls trangres) surtout quil stocke les
identifiants (oid) pour chaque attribut rfrenc. Lors du chargement, le systme excute des
sous-requtes pour chercher les oid des instances de ces attributs. A titre dexemple, linsertion
dune instance de GraduateStudent comporte au moins quatre sous-requtes pour extraire les
oid des cours suivis, du dpartement dappartenance, du conseiller (advisor) et de luniversit
do il tait diplm (undergraduateDegreeFrom). Pour viter des erreurs lors de linsertion,
OntoDB maintient un ordre qui impose la cration des superclasses dune classe avant celle de
la classe et de mme pour les insertions des instances. Tous ces mcanismes contribuent une
cohsion de donnes mais allongent le temps de chargement et ne facilitent pas le passage
lchelle.
On peut ainsi constater quen termes de chargement de donnes, les BDBO de type I sont
plus rapides que les BDBO de type II et III.
4.3 Performances en termes de temps de rponse de requtes

Nous avons mesur les temps dexcution des requtes (en sec.) sur les six BDBO. Comme
pour la mesure des temps de chargement, pour chaque requte, nous avons effectu quatre fois
les mesures et le temps moyen est retenu. Les requtes utilises sont celles proposes dans le
banc dessai LUBM. Nous les avons traduites pour quelles soient acceptes par nos BDBO.
Nous ne prsentons ici que les rsultats avec le jeu de donnes Lubm01, les autres rsultats
95

tant similaires. Les rsultats ont donn lieu aux histogrammes des figures 3.5 et 3.6. Nous
avons utilis la base de rgles owlprime pour Oracle.
4.3.1
Interprtation des rsultats
Pour ce qui est des performances en termes de temps de rponses aux requtes, OntoDB
ragit mieux que les autres BDBO tudies. En effet, OntoDB, ayant stock des oid des champs
rfrencs, se sert de loprateur de rfrencement (DEREF) qui sappuie sur ces oid, vitant
ainsi certains calculs. En plus, OntoDB avec sa reprsentation horizontale des instances, effectue
moins doprations de jointure que les autres systmes parce que toutes les requtes portant sur
les proprits dune mme classe se ramnent des oprations de slection sur la ou les tables
relatives cette classe ; ce qui nest pas le cas dans les autres BDBO. La requte 4 de LUBM
en est une bonne illustration. Cette requte est compose de cinq triplets ayant tous un mme
domaine (Professor). Cette requte ne ncessite aucune jointure dans OntoDB mais demande au
moins quatre jointures dans les autres systmes. Nous pouvons aussi ajouter le fait que OntoDB
scanne moins de donnes que les autres systmes. Effectivement, une simple requte portant
sur la slection dun seul attribut (comme la requte 6) ncessite un parcours de toute la table
de triplets (cest le cas dans Oracle, SesameDbsI et DB2RDF) alors que dans OntoDB, on ne
parcourt que la ou les table(s) de lattribut en question (les tables UndergraduateStudent et
GraduateStudent pour la requte 6 de LUBM). Do le bon temps de rponse.
Oracle vient en second lieu suivi de Sesame. Nous remarquons que Sesame dans la reprsentation binaire (sesameBdsII) ragit un peu mieux que la reprsentation verticale (sesameBdsI).
Cette diffrence est bien marque la requte 14 o SesameBds1 parcourt toute la table de
triplets alors que SesameBds2 ne parcourt que la table typeof. SOR se relve lent car il ralise plusieurs jointures pour toutes les requtes. SOR donne des rsultats plus efficaces que
DB2RDF. Pourtant les deux utilisent le mme SGBD (DB2 9.6). La mauvaise performance
de DB2RDF peut trouver sa rponse dans la multitude des tables qui accompagne la table de
triplets et qui impliquent plusieurs jointures pour rpondre des requtes. En dpit de ses rsultats peu performants, SOR ralise un bon travail de dduction. Par exemple la requte 12
du LUBM, les autres BDBO ne retournent pas de rsultat, car il y a pas de dclaration explicite dinstance de Chair. Cependant, SOR a russi renvoyer des rsultats en se basant sur la
proprit headOf, puisquun individu instance de Professor est instance de Chair sil est la
tte dun Dpartement. Si on ajoute une rgle traduisant cette assertion des BDBO prenant en
compte "les rgles utilisateur" comme Oracle, elles fourniront aussi ces rponses. Mais ce nest
pas une rgle prdfinie dans ce systme. Nous notons que Jena et Sesame utilisent aussi des
moteurs dinfrence pour la dduction de donnes mais en utilisant des fichiers standard. Cette
option est encore difficile mettre en uvre dans les bases de donnes. Mais, il est possible de
faire appel un moteur dinfrence lors de chargement de donnes et de stocker dans la base de
donnes toutes les donnes y comprises celles dduites mais cela serait au dtriment des performances de chargement. Il nest pas exclu denvisager lutilisation dun moteur dinfrence lors
96
Figure 3.5 Temps dexcution de requtes LUBM de 1-7.
Figure 3.6 Temps dexcution de requtes LUBM de 8-14.
97

de lexcution des requtes mais cela allongera considrablement le temps de traitement des
requtes. Pour ce qui concerne OntoDB en matire de moteur dinfrence, elle nen dispose pas
mais lors dinsertion de donnes, elle sature la base de donnes de nouveaux faits dductibles
des relations de subsomption. Cela peut aussi expliquer sa mauvaise performance en temps de
chargement.
5 Paramtres influant identifis partir de cette tude

Dans cette tude empirique, nous avons constat que les rsultats de nos exprimentations
sont divers dans les BDBO tudies. Cette htrognit est due un certain nombre de paramtres parmi lesquels nous pouvons identifier : le SGBD, le format des instances, le modles
de stockage, larchitecture et le type de requtes. En effet, les performances des SGBD ont influenc nos rsultats, nous pouvons le constater dans les chargements de donnes o les SGBD
commerciaux aguerris dans les chargements de donnes (Oracle, DB2) ont fourni de meilleurs
temps de chargement. Lanalyse et le formatage des donnes peuvent aussi constituer de facteurs influenant les systmes. Cest le cas de SOR IBM et dOntoDB qui prennent les instances
OWL, les traitent et les repartissent dans les diffrentes tables appropries. Le format de fichiers
des instances peut galement tre mentionn : certaines BDBO exigent un format spcifique,
cela entraine une conversion qui peut influencer les performances des systmes si la conversion
est faite lors des chargements des donnes.
Larchitecture a certainement jou un rle influant. Pour une architecture classique ("deux
quarts"), nous avons remarqu que les chargements des donnes y sont effectus rapidement
mais les temps de requtes dpendent des types de requtes et du modle de stockage utilis.
Les architectures "trois quarts" et "quatre quarts" sont propices pour des requtes portant sur
le schma dontologie car en sparant les ontologies des donnes, elles rpondent rapidement
aux questions sur les ontologies. Linfluence du type de requte se dgage travers les requtes
de type mono-triplet qui donne de bon rsultat sur les BDBO binaires et horizontales sur tout
SGBD mais pour les requtes de type jointure et de type slection pluri-trplets les rsultats sont
mitigs.
Linfluence du modle de stockage est traduite par la porte des requtes. En effet, une requte SPARQL peut, suivant le modle de stockage, porter une ou plusieurs tables, et entraner
des oprations de jointure ou dunion qui sont coteuses dans le traitement des requtes. Le
modle de stockage vertical est bon en matire de chargement de donnes mais il est coteux
pour les requtes (auto-jointure sur la table de triplets). Le modle de stockage binaire est bien
indique pour les requtes de slection nomo-triplet et le modle de stockage horizontale se
comporte bien pour les requtes de slections (mono-triplet et pluri-triplets) mais il peut entrainer les oprations dunions voire de la redondance selon la gestion de lhritage choisie.
Pour le SGBD, dans la suite de notre travail, nous utiliserons le mme pour toutes nos
BDBO. Nous proposerons un modle de cot qui doit prendre en compte les modles de sto98
6. Conclusion
ckage, larchitecture et le type de requtes.
6 Conclusion
Dans ce chapitre, nous avons propos un modle unifi pour les BDBO et des critres de
comparaison pour pouvoir comparer les BDBO de manire globale et galement de manire
plus dtaille. Nous avons compar les caractristiques de quelques BDBO issues des milieux
acadmiques et industriels. Etant donn que les BDBO sont conues pour le passage lchelle
en termes de volumtrie des ontologies et des instances, il est galement important dtudier les
performances des BDBO actuelles. Tout comme cela a t fait pour les bases de donnes relationnelles, nous avons effectu une comparaison exprimentales des performances des BDBO
en termes de temps de chargement des instances ontologiques et de temps dexcution des requtes. En termes de temps de chargement, cette tude nous a permis de voir que les BDBO
issues du milieu industriel, aguerries dans les chargements de donnes (Oracle, DB2RDF) fournissent de meilleurs temps de chargement. Cette bonne performance sexplique aussi par le fait
que ces systmes utilisent pour les instances et pour les ontologies le modle de stockage vertical et larchitecture de type I. Ils ont donc peu de transformations effectuer lors des chargements de donnes. Nous avons constat que les BDBO horizontales sont lentes en chargement,
cela est d aux multiples oprations pour extraire les donnes des diffrentes tables et aussi pour
tablir des liens smantiques entre les donnes et les concepts ontologiques.
En termes de temps dexcution des requtes, les rsultats sont divers : pour certaines requtes, certaines BDBO fournissent de meilleurs temps dexcution que dautres BDBO et
pour dautres requtes, leurs temps dexcution sont moins bons. Tout dpend de la structure
de la requte (mono-triplet, pluri-triplets, etc.) Certaines BDBO comme IBM SOR sont satures cest--dire quelles contiennent les donnes initiales et les donnes infres. Dautres ne
contenant que des instances fournies sont dites non satures. Ces dernires peuvent faire usage
dun moteur dinfrence pour faire de dduction de donnes. Il existe des BDBO qui donnent
lutilisateur la possibilit de dfinir sa base de rgles de dduction. Les rsultats de certaines
requtes dpend du raisonnement offert par la BDBO.
Ayant identifis quelques facteurs influenant les performances des BDBO, au prochain
chapitre, nous proposerons un modle de cot (Chapitre 4) qui prendra en compte les diversits
de BDBO mais aussi les types de requtes.
99
Chapitre
Modles de Cot pour les Bases de Donnes base

Ontologiques
Sommaire
1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Revue des modles de cot dans le contexte des BDBO . . . . . . . . 103
Les paramtres de notre modle de cot . . . . . . . . . . . . . . . . 104
3.1
Paramtres de la fonction du cot . . . . . . . . . . . . . . . . . 105
3.2
Template de requtes . . . . . . . . . . . . . . . . . . . . . . . 106
3.3
Estimation des facteurs de slectivit . . . . . . . . . . . . . . . 107
3.4
Cot dune slection et dune projection . . . . . . . . . . . . . 110
3.5
Cot de la jointure . . . . . . . . . . . . . . . . . . . . . . . . . 112
Validation du modle de cot . . . . . . . . . . . . . . . . . . . . . . 112
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
101
Chapitre 4. Modles de Cot pour les Bases de Donnes base Ontologiques
1 Introduction
Les modles de cot reprsentent une composante importante des bases de donnes. Ils ont
t utiliss par les diffrentes gnrations de bases de donnes pour rpondre des questions
cruciales. La premire utilisation des modles de cot concernait loptimisation de lexcution
de requtes. Historiquement, les optimiseurs de requtes des SGBD utilisaient une approche dirige par des rgles (Rule-based Approach). Cette approche utilise un ensemble de rgles bien
dfinies comme excuter les oprations de slections avant les oprations binaires comme la
jointure. Avec lapparition des schmas de bases de donnes impliquant un nombre important
de tables (relations), cette approche a t substitue par des optimiseurs dits dirigs par des modles de cot (Cost-based Approach) [80, 156]. Cette approche est utilise actuellement dans la
majorit des SGBD commerciaux. La deuxime utilisation des modles de cot concerne le problme de la conception physique. Comme nous lavons dj voqu au chapitre 3, durant cette
phase un ensemble de structures doptimisation (comme les vues matrialises, les index, le partitionnement, etc.) est slectionn. Vue la taille importante de lespace de recherche de chaque
problme li la slection dune ou plusieurs structures doptimisation, des mta-heuristiques
(par exemple, les algorithmes gntiques [116] ou le recuit simul [157]) diriges par des modles de cot ont t proposes. La troisime utilisation des modles de cot concerne les tapes
de la phase de dploiement des bases de donnes sur des plateformes distribues et parallles
[158].
Un modle de cot est gnralement dvelopp en fonction des composantes principales
dun SGBD [159, 160], do sa dcomposition en trois parties : (1) le cot des entres-sorties
(IO) pour lire et crire entre la mmoire et le support de stockage comme les disque, (2) le
cot CPU et (3) le cot COM de communication sur le rseau (si les donnes sont rparties sur
le rseau). Ce dernier est gnralement exprim en fonction de la quantit totale des donnes
transmises [161, 162]. Il dpend de la nature de la plateforme de dploiement.
Un modle de cot peut tre vu comme une fonction ayant des entres et une sortie. Les
entres reprsentent (i) le schma dune base de donnes (entrept de donnes) gre par un
SGBD utilisant un modle de stockage et une architecture donns, (ii) une charge de requtes,
(iii) la plateforme de dploiement (machine centralise, distribue, parallle, cloud, etc.). Pour
chaque entre, un ensemble de paramtres lui sont associs. Nous distinguons deux catgories
de paramtres : les paramtres calculs (ex. les facteurs de slectivit des prdicats) et les
paramtres non calculs comme la taille des champs, la taille du support de stockage, etc.
Lobtention des paramtres calculs se fait laide des formules mathmatiques et dhypothses
comme par exemple les chemins daccs aux donnes. Pour la partie requte, le calcul de ses
paramtres dpend de la politique de traitement des requtes sur la plateforme de dploiement.
Ces entres reprsentent clairement les entres dun problme de conception physique que nous
avons dtailles dans le chapitre 2. En sortie, nous aurons un cot final dexcution dune charge
de requtes. Cette valeur de cot sera exploite par les algorithmes selon le besoin.
102
2. Revue des modles de cot dans le contexte des BDBO

Une large panoplie de modles de cot a t propose dans les diffrentes gnrations de
SGBD selon la finalit (loptimisation de requtes, la slection des structures doptimisation, le
problme de dploiement, etc.). En examinant la littrature sur les modles de cot, nous avons
remarqu deux phnomnes intressants.
1. Le dveloppement de modle de cot devient un enjeu important chaque apparition
dune gnration de SGBD ayant son propre modle de stockage. Ce fut par exemple, le
cas des bases de donnes orientes objet, o un nombre important de travaux de recherche
ont t effectus. On peut citer les travaux de Georges Gardarin [163, 164] et de Elisa
Bertino [165, 166].
2. Lorsquune nouvelle gnration propose des modles diffrents de ceux utiliss dans les
prcdentes gnrations, les chercheurs proposent des modles de stockage pour stocker
ces nouveaux modles dans les anciens modles et des modles des cots pour leur valuation. Cest le cas des bases de donnes XML, lorsquon a propos des solutions de
stockage relationnel [167, 168].
Les BDBO ont entran les deux phnomnes prcdents, ce qui nous conduit proposer un
modle de cot qui prend en compte la diversit des BDBO.
Ce chapitre est consacr la dfinition de lensemble de paramtres des entres de notre
modle de cot. Une fois dfinis, nous proposons notre modle de cot en prenant en compte
les spcificits des BDBO. Finalement, nous utilisons notre modle de cot pour valuer thoriquement quelques exemples de BDBO et comparons les rsultats ceux obtenus exprimentalement dans le chapitre prcdent.
2 Revue des modles de cot dans le contexte des BDBO

Nous avons identifi plusieurs modles de cot qui ont t proposs pour les BDBO [169,
170, 171, 172, 173]. La particularit de ces derniers est quils se focalisent sur lestimation
de quelques paramtres lis aux BDBO et aux requtes associes. Nous dtaillons ces travaux
dans la suite en notant quils ne traitent pas de la diversit des BDBO.
Maduko et al. [169] proposent des estimations de la cardinalit des patrons de graphes RDF
laide de statistiques smantiques et structurelles. Ces derniers portent sur tous les sousgraphes dune certaine taille contenus dans un ensemble de donnes RDF. Pour effectuer ce
calcul, les auteurs font appel au schma de lontologie. Tous les sous-graphes de lensemble de
donnes peuvent tre dduits partir du graphe du schma de lontologie et annots avec leurs
cardinalits exactes dans la base de donnes.
Shironoshita et al. [170], de leur ct, ont propos une stratgie destimation de cardinalit
construit sur des statistiques bases sur des prdicats. Les auteurs utilisent une fonction de
probabilit pour estimer la cardinalit du rsultat dune requte sur un ensemble de donnes
dune ontologie. Comme dans les travaux de Maduko et al. [169], cette stratgie ncessite un
103

schma dontologie, et est conue dans un contexte de systmes distribus.
Stocker et al. [171] ont propos un modle de cot pour optimiser les patrons de graphe
RDF. Ce modle utilise la slectivit des patrons de triplets et porte sur loptimisation des requtes statiques. Les auteurs proposent de rorganiser les patrons de triplets en fonction de
leur slectivit. La slectivit dun patron de triplets est estime en multipliant la slectivit de
chacun de ses composants (sujet, prdicat et objet). Les hypothses dindpendance et duniformit des donnes ont aussi t faites. Le calcul des statistiques est fonction de la taille de
lensemble de donnes. Dans des ensembles de donnes de taille importante, gnrer les statistiques des donnes peut provoquer des calculs qui influenceraient les performances du systme.
Ainsi, lvolutivit peut poser un problme cette approche. Cependant, nous trouvons que
cette approche peut-tre utile si les statistiques sont calcules davance et gardes dans des
tables appropries.
Neumann et Weikum [172] ont labor une stratgie pour construire des statistiques pour
tous les sous-graphes possible dun ensemble de donnes RDF sans un schma dontologie. Ils
se sont intresss aux sous-graphes de formes arbitraires (graphes en forme de chane, dtoiles,
etc.). Ils utilisent la technique dindexation afin damliorer le traitement des requtes. Leur
approche repose en grande partie sur les capacits dindexation natives. Ainsi, leur stratgie et
sa mise en uvre peuvent difficilement tre adaptes aux diffrents types de BDBO.
Kaoudi et al. [173] ont repris et adapt le calcul de la slectivit de patrons de triplets de
Stocker et al. [171] pour un environnement distribu (DHT : Distributed Hash Table). Neumann
et Moerkotte [174] se sont intresss la slectivit de patron de triplet et lestimation des
cardinalits quils utilisent dans lordonnancement des oprations de jointure.
3 Les paramtres de notre modle de cot

Rappelons quune BDBO est formalise par un 7-uplet :
BDBO :< MO, I, S ch, Pop, S M MO , S MInst , Ar >
tablir un modle de cot doit prendre en considration lensemble de ces composantes.
Comme dans les bases de donnes classiques, les principaux paramtres prendre en compte
dans la fonction de cot sont : les cots daccs disque, les cots de stockage des rsultats intermdiaires, les cots de calcul, etc. Dans notre travail, nous avons tabli certaines hypothses:
(i) la non prise en compte du cot de raisonnement, (ii) le cot des calculs est ngligeable au regard des cots daccs, et (iii) lexistence de statistiques sur les donnes ( partir de lontologie
et des catalogues) plus prcisment, pour chaque relation nous considrons que les statistiques
suivantes sont disponibles : le nombre de tuples stocks, de pages sur lesquelles sont stockes
les tuples, de pages de la mmoire centrale et la taille des tuples. Nous admettons galement les
hypothses faites dans le systme R [175] stipulant que la distribution des valeurs est uniforme
et que les attributs sont indpendants les uns des autres.
104
3. Les paramtres de notre modle de cot

Les hypothses prcdentes sont habituellement faites lors de la construction du modle de
cot. Concernant lhypothse sur le raisonnement, nous distinguons deux types de BDBO,
savoir les BDBO satures et celles non satures. Une BDBO est dite sature si elle contient en
plus des instances ontologiques initiales, des instances dduites, sinon elle est dite non sature.
Certaines BDBO sont automatiquement satures lors du chargement de donnes. Cest par
exemple le cas de SOR dIBM. Dautres BDBO comme Jena et Sesame peuvent tre satures
la demande lors du chargement en utilisant un moteur dinfrence. On trouve aussi des BDBO
qui ne sont pas satures lors du chargement mais qui peuvent tre satures tout moment
la demande de lutilisateur. Oracle en est un exemple. Compte tenu de notre hypothse sur
le raisonnement, notre fonction de cot se base sur les BDBO satures. Pour lappliquer
des BDBO non satures faisant des dductions, il faut ajouter le cot de dduction au cot
dexcution de la requte.
3.1 Paramtres de la fonction du cot

Soit q une requte et bds une BDBO sur laquelle q sera excute et cout la fonction cot. En
ce qui concerne larchitecture dune BDBO, nous pouvons remarquer que par rapport aux modles de cot classiques, les modles de cot dans les BDBO connaissent une " augmentation
" traduite par les cots daccs au diffrentes parties de larchitecture :
Dans une architecture type I :
Cout(q, bds) = cout_acces(metabase) + cout_acces(donnees)
Dans une architecture type II :
Cout(q, bds) = cout_acces(metabase) + cout_acces(ontologie) + cout_acces(donnees)
Dans une architecture type III :
Cout(q, bds) = cout_acces(metabase)+cout_acces(metaschema)+cout_acces(ontologie)
+ cout_acces(donnees).
Le cot daccs la mta-base (cout_acces(mtabase)) faisait partie du modle de cot dans
les bases de donnes classiques est jug ngligeable du fait que la mta-base peut tre garde
en mmoire (buffer). Ainsi, le cot dune requte est fonction de larchitecture et du modle
de stockage de la BDBO. Notre formalisation des BDBO fournit toutes ces informations. La
signature de la fonction de cot est donc : cout :< q, BDBO > R. Nous supposons que
le mta-schma, et lontologie sont de petites tailles et quils peuvent tre placs en mmoire
centrale comme la mta-base. Cette hypothse est raliste pour les ontologies standardises
que lon retrouve dans le domaine de lingnierie. Ainsi, dans toutes les architectures, le cot
peut se rsumer au cot daccs aux donnes notamment en termes de nombre dentres/sorties
cest--dire Cout(q, bdbo) = cout_acces (donnes).
105

Le cot dexcution dune requte est lourdement influenc par les oprations excutes
dans la requte notamment la projection, la slection et la jointure. Pour ce faire, notre fonction
de cot sintresse ces trois oprations. Les paramtres utiliss sont prsents sur le tableau
4.1.
Paramtre
|R|
||R||
M
PS
Nbp(R)
sel(.)
TSR
Taux(R)
Nbv(a,R)
P(I)
Signification
nombre de pages ncessaires pour stocker la table R
nombre de n-uplets de la table R
taille de la mmoire en nombre de pages
taille de la page systme
nombre de tuples de la table R par page
facteur de slectivit dindex ou dun triplet
taille dun n-uplet de la table R
taux de remplissage de la table R
nombre de valeurs distinctes de lattribut a dans la table R
cot de parcours dindex I en E/S
Table 4.1 Les paramtres du modle de cot.
3.2 Template de requtes

Nous considrons que les requtes exprimes sur une BDBO respectant le template cidessous. Soit C1, . . ., Cn des classes et p11, . . . , pnn des proprits dune ontologie, les
requtes considres sont de la forme suivante :
(?id1; type; C1) (?id1; p11; ?val11) (?id1; pn1; ?valn1) [FILTER()]
(?id2; type; C2) (?id2; p12; ?val12) (?id2; pn2; ?valn2) [FILTER()]
(?idn; type; Cn) (?idn; p1n; ?val1n) (?idn; pnn; ?valnn) [FILTER()]
Exemple 3
La requte permettant davoir les tudiants inscrits dans des universits franaises peut tre
exprime dans ce temple comme suit:
(?x type Etudiant ) (?x estInscrit ?y)
(?y type Universit)(?y pays France)
Chaque ligne porte sur une classe et ses proprits. Ce template a t dfini pour que les
requtes puissent tre exprimes dans la plupart de langages dinterrogation des ontologies
comme SPARQL, SeRQL, OntoQl, RQL, etc. Ainsi notre modle de cot nest pas seulement
applicable un seul langage.
106
3.3 Estimation des facteurs de slectivit

La slectivit de triplets et la slectivit des prdicats (de slection et de jointure) sont essentielles pour estimer la taille des rsultats intermdiaires. Elle sont donc des paramtres primordiales pour estimer les cots des requtes [131]. Notre dmarche consiste nous appuyer
sur les travaux qui se sont intresss lestimation du facteur de slectivit de patron de triplet
[171, 173] et les affiner pour prendre en compte limplmentation relationnelle des donnes
pour les BDBO de type I et sur les travaux qui se sont intresss lestimation du facteur de
slectivit de prdicat [175, 131] pour les BDBO de type II et type III. Dans ce qui suit, nous
prsentons la slectivit de patron de triplet pour des BDBO de type I et la slectivit de prdicat pour les BDBO de type II et type III. Dans notre template, tout patron de triplet peut tre
exprim en termes de prdicat de slection sur les BDBO de type II et type III.
3.3.1
Slectivit des patrons de triplet
Dfinition 1
La slectivit dun patron de triplet t note sel(t) est le nombre de triplets correspondant au
patron de triplet divis par le nombre total de triplets [176, 171].
Daprs Stocker et al. [171], elle se calcule suivant la formule :
sel(t) = sel(s) sel(t) sel(o)
o sel(s), sel(p) et sel(o) sont respectivement la slectivit du sujet, du prdicat et de lobjet du
triplet. Ces slectivits sont dfinies comme suit :
Pour tout composant x qui est variable : sel(?x) =1;
Pour le composant sujet s :
1
o R est le nombre total de ressources dans la table de triplets
R
Pour le composant proprit p :
sel(s) =
Tp
T
o T p est le nombre total de triplets ayant p comme proprit et T est le nombre total des
tuples dans la table de triplets.
Pour le composant objet o : on utilise un histogramme de type equal-width qui prsente
la distribution des valeurs par proprit (son co-domaine). Le co-domaine de la proprit
p est divis en B classes (p, oc ).
(
sel(p, oc )
si p est dfinie
sel(o) = P
pP sel(pi , oc ) sinon.
sel(p) =
107

hc (p, oc )
Tp
o le couple (p, oc ) reprsente la classe de lhistogramme de la proprit p o se retrouve
lobjet o. hc (p, oc ) est la frquence de la classe (p, oc ) et T p est le nombre de triplets ayant
p comme proprit.
Si la taille de la BDBO le permet, on peut garder dans les statistiques de la BDBO les
nombres doccurrences de "po 23 ". On peut alors calculer sel(o) comme le nombre de
triplets ayant p comme proprit et o comme valeur (nbrTuple(?s, p, o)) normalis par le
nombre de triplets ayant p comme proprit (T p ) : sel(o) = nbrT uple(?s,p,o)
Tp
La slectivit du composant o est donc lie au composant p. Neumann et Moerkotte [174]
lont qualifi de slectivit conditionnelle.
sel(p, oc ) =
3.3.2
Slectivit de jointure de patrons de triplet
Kaoudi et al. [173] ont dfini la slectivit de jointure de deux patrons de triplet conjonctifs
TP1 et TP2 comme tant le nombre de triplets rsultant de la jointure de TP1 et TP2 (joinP1,T P2)
Card(TP1,TP2)) normalis par le nombre total des triplets (T) au carr : jsel = joinCard(T
.
T2
Cette formule na pas t adapte une implmentation relationnelle des triplets. Elle implique le calcul de la jointure de TP1 et TP2. Etant donn que le rsultat dune excution dun
patron de triplet est une table, nous choisissons utiliser lapproche relationnelle pour ce calcul [154]. Supposons que R1 et R2 soient des relations correspondant aux rsultats des patrons
de triplet TP1 et TP2. Soit card(R1 Z R2) la taille de la jointure de R1 et R2.
||R1|| ||R2||
max(V(R1, ?x), V(R2, ?x))
o ||R1|| et ||R2|| sont le nombre dinstances de R1 et de R2 respectivement, ?x est une variable partage par TP1 et TP2, et V(Ri,?x) est la taille du domaine des attributs ?x de la relation Ri. En dautres termes, ||Ri|| est le nombre de triplets rpondant au patron de triplet TPi
(||Ri|| = sel(T P) T, o T est le nombre total de triplets), et V(Ri,?x) est le nombre des valeurs
distinctes que la variable ?x peut prendre dans la solution de TPi. Pour le calcul de (V(Ri, ?x)),
on peut distinguer deux cas. Si TPi a une variable, alors V(Ri,?x) est gal au nombre de solutions de la variable ?x, cest--dire V(Ri, ?x) = ||Ri||. Pour le second cas o TPi a deux variables,
pour connatre la taille du domaine des variables apparaissant dans la requte, on utilise un histogramme qui, pour chaque patron de triplet, donne le nombre des valeurs distinctes de chaque
composant ainsi que le nombre des valeurs distinctes des combinaisons de deux composants
[173].
card(R1 Z R2) =
Comme lestimation de la slectivit de patron de triplet pour des BDBO de type II et III se
ramne lestimation de slectivit prdicat comme dans les BD relationnelles, nous prsentons
la section suivante la slectivit des prdicats.
23. triplet de la forme(?s, p, o)
108

3.3.3
Slectivit des prdicats
Plusieurs travaux de recherche se sont intresss lestimation de la slectivit des prdicats

[131]. La plupart dentre eux admet les deux hypothses suivantes :
1. uniformit de la distribution des donnes
2. indpendance entre les attributs de chaque relation.
Dfinition 2
La slectivit dun prdicat est le cfficient reprsentant le nombre dobjet slectionns

conformment ce prdicat rapport au nombre dobjets total dune table. Si la slection
vaut 1, tous les objets sont slectionns. Si elle vaut 0, aucun objet nest slectionn.
Lestimation de la slectivit des prdicats de slection se fait comme suit : soient Ai et A j deux
attributs dune table R. La slectivit se fait selon le prdicat par une des formules suivantes :
sel(Ai = valeur) =
sel(Ai > valeur) =
sel(Ai < valeur) =
1
card(Ai (R))
max(Ai ) valeur
max(Ai ) min(Ai )
valeur max(Ai )
max(Ai ) min(Ai )
sel(p(Ai ) p(A j )) = sel(p(Ai )) sel(p(A j ))

sel(p(Ai ) p(A j )) = sel(p(Ai )) + sel(p(A j )) sel(p(Ai )) sel(p(A j ))
sel(Ai {valeurs}) = sel(Ai = valeur) card({valeurs})
Lestimation de la slectivit des prdicats de jointure de R1 et R2 (jsel) est donne par la
formule [154] :
||R1 Z R2||
jsel =
||R1|| ||R2||
Certains travaux ne font aucune hypothse de la distribution des donnes [131]. Dans ce cas
une approche base sur les histogrammes est suggre.
3.3.4
Slectivit des prdicats complexes
Un prdicat complexe est un prdicat compos de plusieurs prdicats relis par des oprateurs de conjonction (ET) et de disjonction (OU). Grce la forme normale, la slectivit
de prdicats complexes se calcule de proche en proche. Pour les prdicats conjonctifs, elle se
calcule selon la formule :
sel(pred1 ET pred2 ) = sel(pred1 ) sel(pred2 |pred1 )
109

o pred1 et pred2 sont de prdicats et sel(pred2 |pred1 ) est la slectivit de pred2 sachant pred1 .
Si les deux prdicats sont indpendants, sel(pred2 |pred1 ) = sel(pred2 ). Cest toujours lhypothse envisage. Aucun systme nest en effet capable de prendre en compte la corrlation entre
les prdicats.
Et pour les prdicats disjonctifs, on utilise la formule :
sel(pred1 OU pred2 ) = sel(pred1 ) + sel(pred2 ) sel(pred1 ET pred2 ).
Si pred1 et pred2 sont mutuellement exclusifs, sel(pred1 OU pred2 ) = 0.
3.4 Cot dune slection et dune projection

Une slection dans notre template de requtes est une requte qui porte sur une seule classe.
Elle est de la forme :
(?id; type; C) (?id; p1; ?val1) ... (?id; pn; ?valn) [FILTER()].
Nous distinguons des slections mono-triplet qui sont des requtes constitues dun seul
motif de triplet des slections pluri-triplets constitues de plus dun motif de triplets portant tous
sur une seule classe. Seules les slections mono-triplet sont interprtes comme des slections
sur les reprsentations verticale et binaire, les slections pluri-triplets impliquent des jointures.
Exemple 4
Soit le fragment dontologie de la figure 4.1.

1. Exemple de requte de slection mono-triplet : q = select ?x where (?x inscrit UP).
Son quivalent SQL considrer dans notre modle de cot est :
sur un modle de stockage vertical, q = select sujet from TableTriplets where objet=UP and predicat=inscrit;
sur un modle de stockage binaire, q = select sujet from Inscrit where objet=UP ;
sur un modle de stockage horizontal, q = select id from Etudiant where inscrit=UP
2. Exemple de requte de slection pluri-triplets : q = select ?x, ?y where (?x inscrit
UP)(?x nom ?y). Son quivalent SQL considrer dans notre modle de cot est :
Sur un modle de stockage vertical,
q = select T1.sujet, T2.objet from TableTriplets T1, TableTriplets T2
where T1.predicat=inscrit and T1.objet=UP and T1.sujet=T2.sujet;
Sur un modle de stockage binaire, q = select I.sujet, N.objet from Inscrit I, Nom N
where I.objet=UP and I.sujet=N.sujet ;
Sur un modle de stockage horizontal, q = select id,nom from Etudiant where inscrit=UP
3. Exemple de requte de jointure : q = select ?x, ?y, ?a where (?x inscrit ?y)(?y adresse ?a)
Son quivalent SQL considrer dans notre modle de cot est :
Sur un modle de stockage vertical, q = select T1.sujet, T1.objet, T2.objet from
110

TableTriplets T1, TableTriplets T2 where T1.sujet=T2.sujet and T1.predicat=inscrit
T2.predicat=adresse;
Sur un modle de stockage binaire, q = select I.sujet, I.objet, A.objet from Inscrit I,
Adresse A where I.sujet=A.sujet ;
Sur un modle de stockage horizontal, q = select E.id, E.inscrit, U.adresse from
Etudiant E, Universit U where E.inscrit=U.id
Etudiant
inscrit
Universit
nom
nomU
dateN
adresse
Figure 4.1 Exemple de schma dune ontologie.

Nous dfinissons la fonction de cot comme celle des bases de donnes relationnelles. Pour
la slection mono-triplet, notre fonction est gale au nombre de pages de la table implique dans
la requte :
dans lapproche verticale, on a : Cout(q, bdbo) = |T | o T est la table de triplets. Si des
index sont dfinis sur les triplets (nous pensons aux six index jugs meilleurs sur la table
de triplets [172], [177] : cout(q, bdbo) = P(index) + sel(t) |T |, o P(index) est le cot de
parcours dindex et sel(t) est la slectivit du triplet t.
dans lapproche binaire, la slection porte sur la table de proprit du triplet : Cout(q, bdbo) =
|T p| o Tp est la table de proprit du triplet de la requte. Avec un index dfini sur le
prdicat de slection, cout(q, bdbo) = P(index)+sel|T p|, sel est la slectivit de lindex.
dans lapproche horizontale, la slection porte sur la ou les tables relatives des classes
qui sont domaine de la proprit du triplet de la requte :
X
(|T cp|)
Cout(q, bdbo) =
T cp domaine(p)
o Tcp sont des tables correspondantes aux classes de la proprit p du triplet de la requte. Sil y a un index dfini sur le prdicat de slection,
X
(P(index) + sel |T cp|)
cout(q, bdbo) =
T cp domaine(p)
o sel est la slectivit de lindex.

Pour la slection pluri-triplets, les requtes sont traduites en des jointures dans les approches
verticales et binaires. Dans lapproche horizontale, la fonction de cot est la mme que celle de
la slection mono-triplet puisque cela nimplique pas de jointure.
Une projection est une slection sans filtre et ayant une liste dattributs de taille infrieure
ou gale au nombre de proprits de la classe sur laquelle elle est dfinie. Son cot est le mme
que celui de la slection.
111
3.5 Cot de la jointure

Les jointures sont des requtes constitues dau moins deux motifs de triplets. Cependant,
dans lapproche horizontale, il faut que les triplets portent sur au moins deux classes de diffrentes hirarchies (sinon cest une slection pluri-triplets). Dabord, pour lapproche verticale,
nous remarquons que lauto-jointure de la table des triplets peut se faire de deux manires :
1. comme jointure nave de deux tables relationnelles classiques cest--dire, un produit
cartsien suivi dune slection. Nous appelons cela, " jointure la BDR ".
2. en sens inverse de la " jointure la BDR " cest--dire des slections suivies dune jointure
classique. Nous appelons cela, " jointure retarde " Nous esquissons un algorithme de
cette deuxime approche ci-aprs.
Algorithm 1 Algorithme de lauto-jointure de la table de triplets
1: // Algorithme de Jointure retarde
2: Entre : T table de triplet, t1 et t2 deux motifs de triplets
3: Sortie : rel(t3) relation rsultat
4: Dbut
5:
Faire une slection suivant t1 sur T et mettre le rsultat dans rel(t1)
6:
Faire une slection suivant t2 sur T et mettre le rsultat dans rel(t2)
7:
Faire une jointure classique de rel(t1) et rel(t2) et mettre le rsultat dans rel(t3)
8: return rel(t3)
9: Fin
Le cot de la jointure de rel(t1) et rel(t2) dpend de lalgorithme de jointure utilis (boucle
imbrique, merge-join, Hash-join). On peut amliorer cet algorithme dans un but doptimisation
de requtes, en considrant la slectivit de triplets comme dans [176] ou la "restrictivit" de
triplets (nombre de variables dans les patrons de triplet) comme lont fait Groppe et al. [178].
Nous considrons distinctement ces deux approches de lauto-jointure de la table de triplets.
Notre fonction de cot dans les autres approches est celle utilise dans le BDR. Les cots de
jointure par boucle imbrique (nested loop) et par hachage sont prsents dans le tableau 4.2.
On rappelle que le cot de jointure par hachage de R1 et R2 est de 3 (|R1 | + |R2 |) et le cot de
leur jointure par boucle imbrique est |R1 | + |R2 | |R1 |/M o M est la taille de la mmoire en
nombre de pages.
4 Validation du modle de cot

Pour valider notre fonction de cot, nous avons considr les requtes de diffrents types.
Nous prsentons ici un rsultat portant sur trois requtes du benchmark LUBM [30] (requtes
2, 4 et 6) reprsentant les types de requtes prsents. La requte 2 est une requte de jointure,
112
4. Validation du modle de cot
Algorithme Nested loop

sans index
Approche verticale join(T,T),
T est la table de triplets
Approche
binaire
join(Tp1,Tp2), Tpi Table
de proprit pi
Approche
horizontale
join(Tcp1,Tcp2),
Tcpi
tables des classes
avec index
Approche
join(Tp1,Tp2),
de proprit pi
jointure retarde
jointure la BDR [154, 179]
2 |T | + 2|t1| + |t2| (1 +
|t1|/M)
|T | + |T | |T |/M
T cpdom(p) (|T cp1|
|T cp1|/M |T cp2|)
jointure retarde
jointure la BDR
|T |(sel(t1) + sel(t2)) +
P(I1)+P(I2)+|t1|+|t1|
|t2|/M, sel(t) est la slectivit des triplets
|T| +|T|*|T|/M
|T p1|+||T p1||(P(I)+||T p2||

sel), P(I) cot de parcours
dindex I et sel la slectivit
de la valeur de recherche dans
Tp2
P
T cpdom(p) (||T cp1| + ||T cp1||
(P(I) + ||T cp2|| sel))
binaire
Tpi Table
Approche
horizontale
join(Tcp1,Tcp2),
Tcpi
tables des classes
sans index
Approche
binaire
join(Tp1,Tp2), Tpi Table
de proprit pi
Approche
horizontale
join(Tcp1,Tcp2),
Tcpi
tables des classes
|T p1| + |T p1|/M |T p2|
jointure retarde
jointure la BDR
2 |T | + 4 (|t1| + |t2|)
6 |T |
3 (|T p1| + |T p2|)
P
T cpdom(p)
3(|T cp1| + |T cp2|)
Table 4.2 Cots de jointures. (dom(p) : domaine de p)
113

la requte 4 est une requte slection pluri-triplets et la requte 6 est un exemple de requtes
de slection mono-triplet. Ces requtes sont traduites en SQL dans les diffrentes approches et
une valuation de leur cot est faite. Les statistiques utilises sont prsentes dans le tableau
4.3. Pour des calculs, nous avons suppos le taux de remplissage des tables de 80%, la taille des
pages de 8Ko, la taille de champs (sujet, proprit et objet) de 200 octets chacune et la mmoire
centrale de 50.000 pages. Chaque requte est considre sur les diffrentes approches. Les cots
calculs de ces requtes sont consigns dans le tableau 4.4.
Concepts
|| triplets||
||University||
||GraduateStudent||
||underGraduateStudent||
||Student ||
||Department||
|| memberOf||
||subject (distincts) ||
||property (distincts) ||
||objects (distincts) ||
||type||
||undergraduateDegreeFrom||
||subOrganizationOf||
||Professor||
||AssociateProfessor||
||AssistantProfessor||
||Chair||
||VisitingProfessor||
||FullProfessor||
||Dean||
||name||
||worksFor||
|| emailAddress||
||telephone||
Cardinalit
100838
979
1874
5916
0
15
7790
17270
31
14072
18213
2414
239
0
176
146
0
0
125
0
15972
540
8330
8330
Table 4.3 Statistiques des instances ontologiques utilises pour lapplication du modle de
cot.
Comme attendu, les rsultats montrent que lexcution dune requte dauto-jointure de la
table de triplets avec une jointure la BDR ncessite plus dentres-sorties que son excution
effectuant dabord les slections suivant les motifs de triplets suivies de jointures (jointure retarde).
114
4. Validation du modle de cot

Requtes
Type de requte
A.V jointure
retarde
A.V jointure
la BDR
Approche
binaire
Requte 6
Lubm
Requte 4
Lubm
Requte 2
Lubm
Slection
Nomo-triplet
Slection
pluri-triplets
Jointure (hash
join)
9168
9168
1138
Approche
horizontale
10289
21308
137520
60864
121
23188 1
65024
195246
18813
Table 4.4 Cots en termes dE/S selon le modle de cot. (A.V: Approche verticale)
Figure 4.2 Cots de requtes fournis par le modle de cot.

Nous observons sur la figure 4.2 que pour une slection mono-triplet, lapproche binaire
ralise moins dE/S et donc est susceptible dtre plus efficace que les autres approches. Dans
notre domaine dapplication, lingnierie, de telles requtes sont rares. Dans dautres types de
requtes (jointure et slections pluri-triplets), lapproche horizontale se montre meilleure suivie
de lapproche verticale. Cela confirme partiellement nos rsultats exprimentaux (chapitre 3,
section 4). Ces rsultats sont confirms par OntoDB qui reprsente lapproche horizontale et
donne de bons temps de rponse, suivie de Oracle ayant une approche verticale et de Sesame
utilisant une approche binaire. Par contre, pour certains systmes expriments comme Jena,
SOR et DB2RDF, les rsultats des valuations ne confirment pas trs clairement ces rsultats
thoriques. Nous croyons que cela est d la procdure de jointure qui peut tre diffrente
de celle applique dans notre modle de cot. Les techniques doptimisation intgres dans
certaines BDBO notamment les vues matrialises peuvent en tre une raison ces diffrences
puisque notre modle de cot ne les intgre pas.
115
5 Conclusion
Nous nous sommes intresss dans ce chapitre aux modles de cot dans les bases de donnes base ontologique. Un modle de cot permet destimer le cot dexcution dune requte
sur une base de donnes. Cest un composant trs utile pour un optimiseur de requtes qui est
un maillon trs important pour tout SGBD [180]. Il permet ce dernier dvaluer les diffrents plans dexcution dune requte et de choisir le plan de moindre cot. En effet, un SGBD
peut valuer une requte de plusieurs manires (plans dexcution). Chaque plan dexcution
est constitu dune suite doprations excuter sur les tables et sur les rsultats intermdiaires
pour rpondre la requte. Loptimiseur de requtes se charge de choisir parmi les plans dexcution possibles dune requte, celui dont le cot est le moindre. Le cot de lexcution des
diffrents plans dexcution dune requte peut considrablement varier. Ainsi, il est trs important davoir un optimiseur de requtes efficace qui peut identifier le plan optimal - ou le
plan proche de loptimal - et viter les plans rellement mauvais. Ceci nest pas une tche triviale parce que le cot dun plan peut varier en fonction de facteurs tels que la distribution
de donnes sous-jacente, lorganisation physique des donnes sur le disque, la taille du buffer
(tampon), lordre de tri des donnes, etc. Le meilleur plan pour un cas peut tre un mauvais
plan pour un autre cas. Pour choisir le meilleur plan pour une requte, un optimiseur de requte
numre un certain nombre de plans candidats selon une stratgie dexploration de lespace des
plans, en utilisant des techniques algorithmiques telles que la programmation dynamique [181].
La qualit du plan choisi dpend clairement de la prcision du modle de cot. Un modle de
cot inexact peut entraner le choix dun mauvais plan pour une requte car loptimiseur peut
incorrectement estimer le cot de ce plan. Estimer le cot des oprateurs dune requte ncessite une estimation de la slectivit de ces oprateurs. Pour estimer une slectivit, il faut la
connaissance de la taille des rsultats et des tailles des entres. La taille de la sortie dun oprateur est dtermine par sa propre slectivit tandis que les tailles des entres dun oprateur
sont dtermines par les slectivits des oprateurs situs en dessous de loprateur dans le plan
dexcution de la requte.
Nous avons propos un modle de cot pour les BDBO en prenant en considration la diversit montre au chapitre 1. Ce modle de cot est donc fonction de larchitecture et du modle
de stockage utilis. Pour les architectures de type II et type III, nous notons une augmentation
dans le modle de cot par rapport larchitecture de type I dont le modle de cot est identique
celui de bases de donnes relationnelles.
Une mise en application de ce modle de cot nous a permis de voir quil ne se dgage
pas un type de BDBO qui est efficace dans le traitement de tous les types de requtes. Cela
confirme le constat fait au chapitre 3, sur ltude des performances des BDBO en termes de
temps dexcution des requtes.
Lintrt de notre modle de cot est de donner au concepteur et ladministrateur la possibilit de quantifier ses requtes et ventuellement de choisir le type de BDBO appropri pour
116
5. Conclusion
une charge de requtes usuelles.
Aussi notre modle de cot sera-t-il exploit dans des problmes de conception physique de
BDBO pour le choix de structures doptimisation. Le prochain chapitre propose des approches
de dfinition et de slection de vues matrialises dans de BDBO. Notre modle de cot aura
son application dans lune de ces approches.
117
Chapitre
La Slection des Vues Matrialises dans les

BDBO: un Mode dEmploi
Sommaire
1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Prliminaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
2.1
Reprsentation algbrique dune requte SPARQL . . . . . . . . 122
2.2
Plan unifi gnrique de requtes . . . . . . . . . . . . . . . . . 124
Slection des vues matrialises au niveau conceptuel . . . . . . . . . 125

3.1
Identification des vues . . . . . . . . . . . . . . . . . . . . . . . 126
3.2
Matrices dusage . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Approche impose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Approche simule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

5.1
Identification des vues candidates . . . . . . . . . . . . . . . . . 133
Exprimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
6.1
Ensembles de donnes pour les tests . . . . . . . . . . . . . . . 139
6.2
Diffrents tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
119
Chapitre 5. La Slection des Vues Matrialises dans les BDBO: un Mode dEmploi
1 Introduction
Dans les chapitres prcdents, nous avons tudi les BDBO et la conception physique dune
manire spare. Lobjectif de ce chapitre est de les confronter pour voir limpact de chacun sur
lautre. Les BDBO ont apport deux caractristiques principales : la prsence de lontologie
dans le SGBD et la diversit concernant les modles de stockage et larchitecture du SGBD
cible. La conception physique est lune des phases cls du cycle de vie de la conception de bases
de donnes, durant laquelle des structures doptimisation sont slectionnes. Pour confronter les
deux mondes, nous considrons une seule structure doptimisation savoir les vues matrialises. Rappelons quelles sont des structures redondantes du fait quelles ncessitent un espace
de stockage et un cot de maintenance. Le processus de slection des vues matrialises est
souvent ralis par des approches diriges par des modles de cot. Notre choix de cette structure est principalement motiv par le fait quune vue matrialise peut tre indexe [128] ou
partitionne [89, 129]. Par ailleurs, les vues matrialises optimisent un large spectre doprations (slection, projection, jointure et agrgation), contrairement aux autres structures qui ne
sont efficaces que pour certaines catgories de requtes.
Le problme de slection des vues matrialises dans les BDBO reprsente un plus grand
dfi que dans le cas gnral car plusieurs formalisations de ce problme sont possibles en fonction de la spcificit de chaque BDBO. Pour illustrer cela, considrons les diffrentes variantes
du problme. Soient:
A = {A1 , A2 , .., An } lensemble de toutes les architectures possibles;
SM = {S M1 , S M2 , .., S Mm } lensemble des modles de stockage existants ;
Part = {Part1 , Part2 , .., Partn } lensemble des parties quun SGBD peut avoir.
Ainsi, le nombre de possibilits de slection des vues matrialises P est donn par lquation suivante:
P = card(A) (card(SM))card(Part) + 1
(1)
Le + 1 correspond la slection sur la base en prsence de lontologie.

Dans le chapitre 2, nous avons identifi trois principaux modles de stockage (table de triplet
(S M1 ), reprsentation horizontale (S M2 ) et reprsentation binaire (S M3 )) et trois architectures
majeures des BDBO (BDBO deux parts, BDBO trois parts et BDBO quatre parts). Rappelons que le processus de slection de vues matrialises ncessite la prise en compte de trois
principales parties (card(Part)=3) : mta-schma (Part1 ), ontologie (Part2 ) et donnes (Part3 ).
En se basant sur les architectures et les
modles de stockage identifis ainsi que les quatre par3
ties qui forment un SGBD, (3 3 ) variantes du problme doivent tre traites. Pour traiter
le problme de slection de vues matrialises dans notre contexte, trois approches sont possibles: (i) la slection base sur lontologie et les requtes. Cette approche rvolutionne les
habitudes des concepteurs et des administrateurs, car la tche de la slection est remonte vers
la phase conceptuelle. Cette slection ne prend pas en compte limplmentation physique de la
120
2. Prliminaires
base de donnes. (ii) une slection impose, qui suppose lexistence pralable dune BDBO.
Cette slection est similaire celle faite dans le contexte des entrepts de donnes. Cette approche a t largement suivie par les chercheurs pour slectionner des vues matrialises dans
les BDBO [182, 142]. Cette approche suppose que la plateforme de dploiement prexiste, en
consquence, elle ne peut pas tre utilise dans le cadre de simulation. Par simulation nous entendons le cas o une entreprise cherche un SGBD pour ses applications et souhaite faire appel
un simulateur pour choisir sa plateforme de dploiement. Pour rpondre ce besoin, une troisime approche existe, appele approche de simulation, dans laquelle le processus de slection
des vues matrialises considre la diversit des BDBO.
Dans ce chapitre, nous dtaillons deux approches : approche conceptuelle et approche simule. Pour chaque approche, une formalisation de son problme est donne. Nous commenons
par donner quelques dfinitions et concepts afin de faciliter la prsentation de lensemble des
contributions.
2 Prliminaires
Dfinition 3 (Triplet RDF)
Un triplet RDF est un 3-uplet (sujet, prdicat, objet) (U B) U (U B L) o U

est un ensemble deURI, B est un ensemble de nuds anonymes et L est un ensemble de
littraux (string, int, ...).
En dautres termes, un triplet est une combinaison de trois lments sujet, prdicat et objet
crite sous la forme : (sujet, prdicat, objet). Cest une dclaration exprimant une connaissance
dans une ontologie.
Dfinition 4 (Patron de triplet)
Un patron de triplet est un 3-uplet (sujet, prdicat, objet) (U B V) (U V) (U

B L V) o U est un ensemble dURI, B est un ensemble de nuds anonymes, L est un
ensemble de littraux (string, int, ...) et V un ensemble de variables.
Autrement dit, un patron de triplet est un triplet dont certains lments sont des variables. Les
patrons de triplets permettent dexprimer de requtes sur des bases de donnes smantiques.
Dfinition 5 (Requte SPARQL)
Une requte SPARQL est une suite de conjonctions des patrons de triplet. Elle est considre comme une suite de jointures entre les relations rsultant de lexcution des patrons
de triplets (si aucune variable nest partage par les patrons de triplets, on a des produits
cartsiens).
Il faut noter quune requte telle que dfinie est appele aussi patrons de requte ou encore
patron lmentaire de graphe (Basic graph patterns). Nous utiliserons de manire indiffrente
121
ces appellations. Dans ce qui suit, nous ne traiterons que des requtes SPARQL conjonctives
sans Filter et sans patron de triplet optionnel. Les patrons de triplets de nos requtes ne prsentent pas non plus de variable la position du prdicat. Nous prcisons que les requtes
SPARQL conjonctives sont celle dont les patrons de requtes partagent au moins une variable.
Nous utilisons le symbole " " pour dsigner les jointures dans des requtes quand les patrons
de triplets sont identifis par des noms comme t1 , tp1 , tp2 , ...
Dfinition 6 (Mapping de variables ou solution mapping)
Un mapping : V T dun ensemble de variables V vers un ensemble T = B U L, o

B lensemble des nuds anonymes, U lensemble de URI et L lensemble de littraux. Par
extension, pour chaque patron de triplet t (triplet avec des variables), (t) est le triplet quon
obtient en remplaant chaque variable v var(t) par son mapping ; var(t) est lensemble des
variables du patron de triplet t.
Dfinition 7 (Mapping de patron dinstance (Graph Pattern Matching))
Un mapping de patron dinstance P est une combinaison dun mapping dinstances RDF s,
et dun mapping de variable , tel que P(x) = (s(x)).
Dfinition 8 (Solution pour un patron lmentaire de graphe)
Soit BGP un patron lmentaire de graphe et G un graphe RDF. est une solution pour BGP
sur G quand il existe un mapping de patron dinstance P tel que P(BGP) est un sous-graphe
de G et est une restriction de P aux variables de la requte dans BGP.
Il faut noter quun mapping contient des valeurs pour les variables et les nuds vides alors
quune solution ne retient que les valeurs des variables. Deux solutions sont dites compatibles
si elles ont des valeurs identiques pour les mmes variables. Les oprateurs de lalgbre de
SPARQL oprent sur des multi-ensembles (ou des squences) des mappings de solutions.
Lvaluation des BGP produit donc un multi-ensemble de mappings de solution o chaque
est une solution pour le BGP. Elle porte sur une expression algbrique de la requte.
2.1 Reprsentation algbrique dune requte SPARQL

Comme dans les bases de donnes relationnelles, chaque requte SPARQL peut tre reprsente par un arbre dexpression algbrique correspondant, appel arbre de requte [183,
184, 185]. Un arbre de requte est une structure de donnes arborescente qui permet de visualiser graphiquement la requte. La racine correspond la requte (cest--dire, au rsultat
de la requte si les oprations sont excutes). Les feuilles de larbre correspondent aux tables
utilises dans la requte. Dans la reprsentation verticale, les feuilles de larbre reprsentent la
table des triplets. Dans les reprsentations binaire et horizontale, elles correspondent aux tables
des proprits et aux tables de classes respectivement. Les nuds intermdiaires correspondent
aux oprations algbriques comme la slection, la jointure ou le produit cartsien. En fait, cha122
2. Prliminaires
Figure 5.1 Arbre de requte pour une BDBO Figure 5.2 Arbre de requte pour une BDBO
Verticale
binaire
cun de ces nuds intermdiaires est considr comme une relation rsultant de lexcution de
lopration sur ses oprandes.
Exemple 5
Soit q une requte constitue de deux triplets t1 et t2 cest--dire, q = t1 t2. Les arbres de
requtes de q dans les reprsentations verticale et binaire sont reprsents sur les figures 5.1
et 5.2.
Compte tenu du fait que le langage SPARQL est indpendant des diffrents types de BDBO
et que les requtes SPARQL sappliquent sur nimporte quel type de BDBO, pour prsenter nos
arbres de requtes, nous utilisons directement les patrons de triplets. Ces derniers seront donc
des feuilles de nos arbres. Cela nous permet de faire une abstraction des diffrents schmas de
BDBO. Ainsi, pour tous les types de BDBO, larbre de la requte prcdente q (Exemple 5)
est donn sur la figure 5.3.
t1
t2
Figure 5.3 Arbre de requte pour tout type BDBO
123
2.2 Plan unifi gnrique de requtes

Dans les entrepts des donnes relationnels, la slection des vues utilise une structure de
donnes appele plan unifi de requtes (ou MVPP: Multiple Views Processing Plan [186]). Ce
plan prend en compte linteraction entre les requtes [187]. Dans le monde des bases de donnes
smantiques, linteraction est plus prsente. Si nous prenons lexemple dune BDBO base de
triplet, toutes les requtes passent par cette table, ce qui augmente considrablement linteraction entre lensemble des requtes. Le plan unifi est construit partir des arbres algbriques
individuels de requtes. Il peut tre vu comme un graphe orient acyclique et tiquet, dont la
structure est dfinie par : (N, A), o N et A reprsentent les ensembles de nuds et darcs du
graphe. Un nud est une opration algbrique ou une relation et un arc est un lien entre deux
nuds. La construction de ce plan est une tche difficile [186]. Dans nos travaux nous utilisons
les travaux de thse dAhcne Boukorca, effectu au sein de notre laboratoire pour gnrer le
meilleur plan [188].
Exemple 6
Soit trois requtes q0 = t1, q1 = t1 t2 t3 et q2 = t1 t2 t4. La branche t1 t2 est

identique dans les requtes q1 et q2. La mise en commun de deux plans passe par la fusion
de cette branche commune. Le plan unifi de ces requtes est prsent dans la figure 5.4.
q1
t3
q0
q2
t2
t1
t4
Figure 5.4 Un plan unifi des requtes SPARQL

Une fois construit, tout nud intermdiaire peut tre candidat la matrialisation [186]. Les
feuilles dans le plan unifi reprsentant les patrons de triplets rsultent des oprations de slection faites sur limplmentation sous-jacente de la BDBO. Les nuds de slection ((.))
qui expriment clairement la smantique de lexcution de patrons de triplets peuvent aussi tre
reprsents sur le plan unifi (figure. 5.5). Pour un patron de triplet, un nud de slection est
dfini comme suit selon le modle de stockage :
select * from TT where condV si BDBO verticale
(t) =
(2)
select * from TabProp(t) where condB si BDBO binaire
select * from TabClass(t) where condH si BDBO horizontale

124
3. Slection des vues matrialises au niveau conceptuel

o TT, TabProp(t) et TabClass(t) reprsentent respectivement la table de triplets, la table de proprits et la table de classe relative au patron de triplet t ; condV, condB et condH reprsentent
respectivement les prdicats de slection correspondant au patron de triplet t dans le modle de
stockage vertical, binaire et horizontal. Les nuds de projection ne sont pas reprsents dans
notre graphe de requtes. Le plan unifi des requtes de lexemple 6 avec des nuds de slection
est prsent sur la figure 5.5.
q1
q0
t:
t;
t<
t=
t3
t1
t2
t4
q2
Figure 5.5 Plan unifi des requtes avec les nuds de slection.
Nous avons prsent dfini les notions ncessaires pour prsenter nos approches de slection des vues matrialises.
3 Slection des vues matrialises au niveau conceptuel

Formellement, le slection des vues pour cette approche est dfinie comme suit. Etant donns
une ontologie de domaine utilise par la BDBO ;
une charge de requtes SPARQL Q; o chaque requte a une frquence daccs;
Le problme de slection des vues matrialises consiste slectionner un ensemble de vues
qui rduid le cot dexcution de la charge de requtes.
Cette approche se veut gnrique. Elle est dfinie au niveau conceptuel (ontologique) et
exige donc le schma dontologie. Elle se base sur les classes de lontologie et principalement
celles qui sont impliques dans la charge de requtes. En plus des classes, elle prend en considration les proprits impliques dans les requtes. Pour rappel, une requte SPARQL est une
conjonction des patrons de triplet. Les requtes SPARQL font souvent appel plusieurs attributs qui sont des proprits lies une mme entit, elles tendent donc tre (sinon contenir)
125
des requtes en toiles (cest--dire une requte dont le graphe est form dun nud central et
de ses voisins).
Il est vrai que les requtes SPARQL ne font pas apparatre clairement les classes vises
comme les requtes SQL le font pour leurs tables, mais on peut identifier ces classes travers
les proprits dans les patrons de triplets. En fait, tout triplet ou patron de triplet ti porte sur au
moins une classe : la classe du domaine de sa proprit.
Lide fondamentale est que quand une mme variable x apparat comme sujet dans plusieurs triplets, (il existe des jointures entre les relations rsultant de lexcution des patrons
de triplet travers la variable x), en matrialisant la classe de x, ces patrons de triplet ayant x
comme sujets, seront excuts sur cette classe, et ainsi le nombre de ces jointures sera rduit.
Cette approche visant donc liminer un certain nombre de jointures est susceptible dacclrer
lexcution des requtes. Chacune des classes dcouvertes est donc une vue matrialiser. Nous
prsentons ci-dessous notre technique didentification de ces classes.
q
t1^t2
Dom(p1, p2)
Figure 5.6 t1 et t2 sur un seul domaine
t>
t2
Dom(p1)
Dom(p2)
Figure 5.7 t1 et t2 sur deux domaines
3.1 Identification des vues

Nous partons de larbre algbrique de chaque requte. Pour chaque triplet, nous considrons le domaine de sa proprit (la classe de son sujet). Il est vident que si cette classe est
matrialise, la branche de larbre construite sur ce patron de triplet aura comme feuille cette
classe. Alors, en remplaant chaque patron de triplet par la classe de sa proprit, et en fusionnant les classes identiques, on obtient un arbre de requtes bas sur les classes. La fusion de
classes se traduit par une union de leurs proprits. Autrement dit, on regroupe tous les patrons
de triplets ayant le mme domaine. Soit ti et t j deux patrons de triplets et C(p), une classe issue
dun triplet t, ayant p comme proprit, si ti et t j ont le mme domaine. Le regroupement de
ti et t j est traduit par la cration dune classe ayant pi et p j comme proprits, C(pi , p j ). Les
figures 5.6 et 5.7 prsentent une illustration des arbres de requte bass sur les classes pour la
requte q = t1 t2. Le schma dontologie est trs important dans lidentification du domaine
dune proprit car il nous renseigne sur les caractristiques des proprits. Il faut noter que le
126

domaine dune proprit peut comporter plusieurs classes. On note lensemble de ces classes
pour une proprit p, Dom(p). Dans le processus didentification de classes, tous les patrons
de triplets dune requte doivent tre considrs. Pour chaque variable, les classes retenues sont
celles qui sont communes aux ensembles de classes obtenues pour chaque patron de triplet o se
trouve la variable. Mais pour viter davoir un grand nombre de ces classes, une prdominance
est accorde au constructeur "rdf:type". Dans une requte, si une variable x est implique dans
plusieurs triplets comme sujet, et que parmi les proprits se trouve le constructeur "rdf:type",
alors la classe de x retenue est celle spcifie par "rdf:type".
Au fur et mesure que lon identifie les classes, on retient les proprits dfinies sur ces classes
qui sont prsentes dans les requtes. Nous rappelons que nous travaillons sur les configurations
de patrons de triplets o le composant " proprit " est une constante ; donc " proprit " dvient
un attribut des classes dcouvertes. Par souci de simplification, nous utilisons notre template de
requtes dfini au chapitre 4 o pour chaque variable, le type est renseign (cest--dire, il y a un
patron de triplet ayant comme proprit " rdf:type "). Le processus didentification des classes
est consolid dans lalgorithme 3.1 qui prend une requte et renvoie ses classes et proprits.
Cet algorithme se sert des matrices dusages prsentes ci-dessous.
Algorithm 2 classIdentifier(q)
1: Entre : q :une requte
2: Sortie : C(q) : ensemble de classes impliques dans q avec leurs proprits
3: Dbut
4: C(q) = vide
5:
pour toute variable var de q faire
6:
pour les triplets o var apparait faire
7:
si var est sujet de triplet ti et proprits pi dfinies faire
8:
C(q) = C(q) (i Dom(pi ))
9:
Ajouter pi comme proprit chacune de classe de Dom(pi )
10:
si var est objet de triplet ti dont si est dfini faire
11:
C(q) = C(q) classe(s) //classe(s) : les classes de s
12:
Ajouter pi comme proprit chacune des classes de s
13:
si var est proprit de triplet ti et sujet variable faire
14:
dterminer pi
15:
C(q) = C(q) (Dom(pi ))
16:
Ajouter Pi a chacune de classe de Dom(pi )
17:
finPour
18:
finPour
19: Retourner C(q)
20: Fin
127
3.2 Matrices dusage
Partant du schma dontologie, de la charge de requtes et des rsultats de lidentification, nous avons dfini deux matrices dusage : Matrice dusage des classes (MUC) et matrice
dusage des proprits (MUP). La matrice dusage de classe prend en ligne des requtes et en
colonne des classes. Elle nous indique si une requte donne utilise une classe donne ou non.
La matrice dusage de proprit nous renseigne sur lutilisation de chaque proprit par les
requtes. Ces deux matrices sont dfinies par les quations 3 et 4:

MUC i, j =

MUP i, j =
1 si la requte i utilise la classe j

0 sinon
(3)
1 si la requte i utilise la proprit j

0 sinon
(4)
Ces deux matrices permettent au travers des algorithmes suivants de dfinir toutes les vues pour
une charge de requtes donne. Lalgorithme ViewDiscover prend un schma dontologie et une
charge de requtes et renvoie la liste des vues matrialiser. Pour chaque requte, la mthode
ClassIdentifier est appele pour identifier les classes et les proprits. A la fin de lidentification
des classes et des proprits, les matrices dusage sont cres. Pour chaque classe de lontologie,
sil existe une requte qui utilise cette classe, celle-ci est prise comme une vue et on lui associe
ses proprits grce la mthode findProperties. Cette dernire considre toutes les proprits
lies la classe traite (notamment par la relation "RDFS:Domain"). Pour chaque classe, sil y
a une requte i qui utilise cette proprit p (cest--dire, MUP[i,q]=1), alors cette proprit est
ajoute comme un attribut la vue.
128

Algorithm 3 ViewDiscover
1: Entre : Q : charge de requtes
2:
O : schma dontologie
3: Sortie : V : liste de vues matrialises
4: Dbut
5:
V=
6:
Pour q Q faire
7:
classIdentifier(q)
8:
finPour
9:
Crer MUC et MUP
10:
pour c O // Classe ontologique
11:
sil existe q Q tel MUC[q, c] = 1 alors
12:
findProperties(c, MUP)
13:
V =V c
14:
finsi
15:
finpour
16: Retourner V
17: Fin
Algorithm 4 findProperties
1: Entre : c : une classe
2:
MUP : matrice dusage des proprits
3: Sortie : L : liste de proprits de c
4: Dbut
5:
L=
6:
Pour p {proprit de c} faire
7:
sil existe q Q tel MUP[q, p] = 1 alors
8:
L = L {c}
9:
finsi
10:
finpour
11:
Retourner L
12: Fin
La figure 5.8 rsume les diffrentes tapes de mise en oeuvre de lapproche conceptuelle.
Cette dernire est une approche base sur les rgles ( rule-based approach, approche ODT P),
cf. chapitre 2) et la rgle utilise est lusage des classes et des proprits par les requtes dfinies
au niveau conceptuel. Rappelons que dans les annes 90, quelques efforts ont t tablis pour
dfinir des langage de requtes au niveau conceptuel, on peut citer le cas du langage ConQuer
[189].
129
Figure 5.8 Les tapes de mise en oeuvre de lapproche conceptuelle
Exemple 7
Soit Q une charge compose des deux requtes suivantes :

Q1 : (?x rdf : type University)(?x name ? uname)
Q2 : (?y rdf:type Professor)(?y workFor ?x)(?x rdf : type University)(?x name ? Uname)
Identification des classes et des proprits :
Le triplet (?x rdf : type University) est typ University alors la classe de la variable x est University. dom(name) ={University,Professor}. Mais pour la variable x, dom(name) = University car on prend lintersection des ensembles de classes dcouverts.
Le triplet (?y rdf:type Professor) la classe de la variable y est Professor > dom(workFor)
= Professor. Pour la variable y, dom(name) = Professor.
Matrice dusage : Les matrices dusage sont prsentes sur les tableaux suivants :
Matrice dusage des classe
Matrice dusage des Proprits
Requtes University Professor
Requtes type workFor name
Q1
1
0
Q1
1
0
1
Q2
1
1
Q2
1
1
1
Vues matrialises : on trouve deux vues matrialises qui sont :
University((rdfId, name) et ;
Professor(RdfId, workFor, name).
130
4. Approche impose
4 Approche impose
Nous commenons par prsenter la formalisation du problme. Etant donn :
une BDBO ayant une architecture et un modle de stockage donns;
une charge de requtes SPARQL Q, o chaque requte a une frquence daccs;
une contrainte de stockage S.
Le problme de slection de vues matrialises consiste slectionner un ensemble de vues qui
minimise le cot dexcution de la charge de requte et respecte la contrainte de stockage S.
Le peu de travaux sur la slection des vues matrialises dans le contexte des BDBO utilisent cette approche. Goasdou et al. [182] ont propos une dmarche de slection de vues dans
BDBO qui utilise la table des triplets comme modle de stockage. Leur dmarche est base sur
la notion dtat inspire du travail de Theodoratos et Sellis [190] sur les vues matrialises dans
les entrepts de donnes. Un tat est une paire <V, R> o V est un ensemble de vues et R un
ensemble de rcritures de requtes sur ces vues. Lobjectif est de trouver un tat qui minimise
le cot dexcution de requtes, lespace de stockage et le cot de maintenance de vues mais
sans contrainte de stockage. Ils utilisent une structure multi-graphe comme celle propose par
Ullman [191] pour reprsenter les requtes et la technique de dcomposition de graphe propos
par Wong et Youssefi [192] enrichie de nouveaux oprateurs. Dans le multi-graphe, chaque patron de triplet est reprsent par un nud. Un arc entre deux nuds indique la jointure entre ces
nuds. Un arc rflexif cest--dire, qui boucle sur un mme nud, symbolise une opration de
slection. A ltat initial, chaque requte est considre comme une vue. Le multi-graphe de la
charge de requtes de lexemple 7 est reprsent sur la figure 5.9.
Figure 5.9 Multi-graphe de requtes

131
Les principales oprations mises au point pour dfinir les vues candidates (les tats) sont
View Break (VB), Selection Cut (SC), Join Cut (JC) et View Fusion (VF). Les trois premires
effacent les prdicats des vues et peuvent diviser une vue en deux, augmentant le nombre de
vues et la dernire fusionne des vues, rduisant ainsi le nombre de vues. Par exemple, une
opration Join Cut (JC) sur la vue V1 de la figure 5.9 produit les vues V3 et V4 prsentes sur
la figure 5.10.
Figure 5.10 Rsult de Join Cut sur V1.
A chaque tat est associ un cot prenant en compte lespace mmoire pour toutes les vues,
le cot de rcriture des requtes et le cot de maintenance des vues matrialises. Cette approche cherche valuer les requtes avec des oprations dassignation, de slection, de projection et des boucles et viter les oprations de jointure. Les jointures sont effectues plutt
travers les boucles.
Castillo et Leser [142] ont propos une approche pour la slection des vues sur des donnes
RDF pour une charge de requtes SPARQL donne. Cette approche suit la mthode de slection dindex propose par Chaudhuri et Narasayya [193] pour les bases de donnes classiques.
Les donnes RDF utilises sont reprsentes dans une table de triplets. Lide est de dcouvrir
les patrons de triplets partags pour tre utiliss comme index afin damliorer les temps de
rponses. En considrant lensemble de requtes comme un espace de recherche initial, lapproche de Castillo et Leser [142] tend cet espace en analysant chaque requte de la charge et
en dgageant toutes les combinaisons des patrons de triplets connexes dune certaine longueur
(>=k) et en les ajoute cet espace de recherche appel espace des index candidats.
Cette approche divise le problme en trois tapes: la gnration des ensembles dindex candidats, lvaluation de ces ensembles et la slection itrative des index. Les informations dindex
sont extraites des patrons de triplet et les ensembles dindex sont gnrs. Une analyse de leur
frquence est effectue. La stratgie de "query containment" est employe pour dterminer quels
sont les patrons de triplet qui sont inclus dans dautres. Cette approche utilise comme contrainte
le nombre maximal de vues (index) que lon peut crer mais ne prend pas en compte lespace
de stockage des index. Le modle de cot repose sur un nombre doccurrences potentielles des
index candidats.
132
5. Approche simule
5 Approche simule
La formalisation du problme dans cette approche est quasi similaire la prcdente, la
diffrence tant quelle considre plusieurs variantes de BDBO. Pour slectionner des vues
dans chaque variante, nous considrons les tapes suivantes :
1. identification des vues matrialises candidates ;
2. annotation des candidats par des fonctions de cot qui dpendent des caractristiques de
la base de donnes cible ;
3. proposition des algorithmes de slection.
Ces tapes sont dtailles dans les sections suivantes.
5.1 Identification des vues candidates

Bien que notre travail porte sur le problme de slection des vues matrialises, il entre
aussi dans le cadre de loptimisation multi-requtes 24 ( Multi-Query Optimisiation - MQO). En
effet, les deux problmes sont lis, surtout quand on utilise une approche consistant rutiliser
certains rsultats intermdiaires. Cette partie traite de la construction de lespace de vues matrialises suivant une approche qui consiste rutiliser certains rsultats intermdiaires comme
dans le cadre de loptimisation multi-requtes. Pour crer notre graphe unifi des requtes, nous
nous focalisons sur le partage des nuds entre les requtes. Cette dmarche favorise la rutilisation des rsultats intermdiaires et permet doptimiser toute la charge de requtes. Pour une
requte donne, il existe plusieurs plans dexcution possibles. Cela est d aux proprits des
oprations algbriques (appeles rgles de transformation des arbres [191, 194]). Selon lordre
donn aux oprations (slection, jointure, projection) et aux oprandes, on obtient plusieurs
plans. Le rsultat dune requte reste le mme quel que soit le plan utilis mais le cot dune
requte peut varier dun plan un autre. Le plan optimal dune requte est celui dont le cot
est minimal. Avant de construire notre graphe unifi, nous commenons dabord par optimiser chaque requte individuellement. Optimiser une requte SPARQL revient ordonner ses
patrons de triplet. Plusieurs techniques sont proposes pour cette tche [171, 173]. Dans notre
travail, nous avons utilis la slectivit des patrons de triplet [171, 173]. Les triplets sont ordonns suivant leurs slectivits croissantes. Il est aussi intressant dordonner les requtes suivant
un autre critre jug pertinent (leurs cots ou frquences, ou leur nombre de patrons de triplet).
Mais on doit garder lesprit que la construction des nuds dpend de lordre darrive des requtes et des patrons de triplet. La construction du graphe unifi passe par les tapes suivantes :
extraction des patrons de triplet : pour chaque requte de la charge de requtes, on extrait tous les patrons de triplet quon garde dans un ensemble. Chaque triplet nest stock
quune seule fois. Vu que les variables peuvent avoir des noms diffrents alors quelles
24. optimisation dune charge de requtes
133
font rfrence aux mmes triplets, on harmonise les variables sur toute la charge de requtes. Par exemple, (?x undergraduateFrom ?u) et (?p undergraduateFrom ?z) sont deux
patrons de triplet rfrenant le mme ensemble de triplets; on doit identifier que la variable ?x correspond la variable ?p et la variable ?u ?z.
extraction des nuds de slection : cette opration est la premire opration sur les donnes. Elle reprsente lexcution des patrons de triplet sur une BDBO. Les nuds correspondants sont en fait lensemble de triplets rpondant chacun des patrons de triplet.
extraction de nuds de jointure : pour chaque requte, nous dgageons les diffrents
nuds de jointure. Nous rappelons quune jointure est une conjonction des deux patrons
de triplet partageant au moins une variable. Ces nuds sont crs sur les nuds de slection des patrons de triplet impliqus. Nous avons opt pour les arbres de type left-join
pour la premire requte.
dfinition des nuds de projection que nous considrons comme des rsultats de requtes.
Notre approche de construction du graphe unifi suit celle qui a t propose et exprimente
dans notre laboratoire [188]. Contrairement cette dernire, nous ne considrons pas plusieurs
liens entre deux nuds donc nous nutilisons pas un hypergraphe. Nous obtenons un simple
graphe qui est notre plan unifi. Par exemple pour notre charge de requtes de lexemple 7,
nous obtenons des graphes unifis dont un exemple est donn sur la figure 5.11. Il est question
q1
(?x name ?uname)
(?x name ?uname)
q2
(?x rdf:type University)
(?y WorkFor ?x)
(?x rdf : type University)
(?y workFor ?x)
(?y rdf:type Professor)
(?y rdf:type Professor)
Figure 5.11 Plan unifi des requtes de lexemple 7.

de savoir si ce graphe est optimal. Etant donn que notre graphe unifi est dpendant de lordre
des requtes, on ordonne les requtes suivant un critre donn (leurs frquences, leur cot, leur
slectivit minimale ou une combinaison donne) et on cre les graphes unifis en faisant une
permutation circulaire jusqu ce que la premire requte de la liste revienne en tte de liste.
Le graphe retenu est celui qui a un cot minimum. Cette alternative ressemble la mthode
"feasible" de Yang et al. [195]. Elle est facile mettre en uvre mais peut entrainer un grand
134
5. Approche simule
nombre de calculs. En effet, pour une charge de N requtes, il faut crer et comparer N graphes
unifis possibles.
5.1.1
Annotation des candidats par des fonctions cot
Une fois le plan unifi obtenu, nous procdons au processus dannotation des nuds par des
fonctions cot reprsentant le cot de construction et le cot daccs.
5.1.1.1 cot de construction. Le cot de construction dun nud est le cot algorithmique
du nud tel que dfini au chapitre 4. Ce cot est considr aussi comme le cot de mise jour
du nud ou encore le cot de maintenance (on suppose que les mises jour sont compltes et
faites de manire priodique, cest--dire par rcration des nuds). On note C_cout(v), le cot
de construction du nud v.
5.1.1.2 cot daccs. Le cot daccs dun nud est dfini comme tant la taille du nud.
Par simplification, on le dfinit comme tant le nombre de tuples du nud. On le note A_cout(v),
pour un nud v. Le calcul de ce cot dpend du type de nud (nud de slection ou nud de
jointure)
Pour un nud de slection.
sel(T P) nbrT uple(T T ) si la BDBO est verticale avec TT la table des triplets
A_cout =
nbrT uple(T abProp(T P)) si la BDBO est binaire
sel(T P) nbrT uple(T abClasse(T P)) si la BDBO est horizontale
o nbrTuple(T) est le nombre de tuples de la table T, TabProp(TP) et TabClasse(TP) sont la

table de proprit et la table de classe relatives au patron de triplet TP, sel(TP) est la slectivit
du patron de triplet TP si on a une BDBO verticale et la slectivit du prdicat correspondant
la traduction du patron de triplet TP en langage SQL, si on a une BDBO binaire et horizontale.
Pour un nud de jointure.
A_cout = jsel nbrtuple(T P1) nbrT uple(T P2)
(5)
o nbrTuple(TP1) et nbrTuple(TP2) reprsente le nombre de tuples dans chaque relation correspondant aux rsultats des traitements des patrons de triplet TP1 et TP2, jsel est leur slectivit
de jointure.
135
5.1.1.3 cot de requte. Le cot de requte est fonction des vues matrialises. Si aucune
vue nest utilise, le cot de la requte est le cot de lalgorithme utilis pour calculer la requte.
Lalgorithme suivant permet de calculer le cot des requtes en prsence dun ensemble de vues
matrialise (on utilise une jointure par hachage).
Algorithm 5 A_cout
1: Entre : q : requte
2:
M : ensemble de vues matrialises
3: Sortie : cout : cot de la requte q
4: Dbut
5:
si (M est vide) retourner C_cout(q);
6:
sinon
7:
si q a des jointures alors
8:
si( dernierejointure de q M)
9:
retourner A_cout(dernierejointure)
10:
sinon
11:
retourner 3*(cout(partieG, M) + cout(partieDroite, M));
12:
finsi
13:
sinon
14:
si (dernireSelection de q M)
15:
retourner A_cout(derniereSelection)
16:
sinon
17:
retourner C_cout(q)
18:
finsi
19:
finsi
20: Fin
5.1.1.4 Cot total de la charge. Le cot total de la charge de requtes est la somme de cot
de chaque requte multipli par la frquence de la requte.
cout_total =
X
qQ
f req(q) cout(q, M)
(6)
o freq(q) est la frquence de la requte q et M lensemble de vues slectionnes.
5.1.2
Algorithmes de slection
Etant donn que chaque nud est une vue potentielle et que nous disposons des caractristiques de chaque nud, il est question de slectionner les vues qui minimisent le cot total de
la charge des requtes et qui respectent la contrainte de stockage.
136
5. Approche simule
Si la contrainte de stockage nexistait pas, lalgorithme de slection de vues dans un MVPP
de Yang et al. [195] nous suffirait pour avoir cet ensemble de vues optimal. Mais vu le fait que
cet algorithme ne prend pas en compte la contrainte de stockage, et que le problme de slection
est un problme de sac dos [196], nous avons utilis un algorithme glouton et un algorithme
gntique pour la slection de vues.
5.1.2.1 Algorithme gntique. Les algorithmes gntiques [115] sont inspirs de lvolution des espces naturelles. Ils reproduisent le modle dvolution en vue de trouver une solution optimale un problme. Ils visent faire voluer une population en vue damliorer ses
individus. Ils considrent une population et non un individu. Ainsi, ils donnent un ensemble de
solution et non une solution. Ces solutions peuvent tre diffrentes mais de qualit quivalente.
Notre algorithme utilise la bibliothque JeneGA dveloppe en Java ddie aux algorithmes
gntiques et disponible sur sourceforge.net/projects/jenes/ [197]. La particularit de
cette dernire est quon lui donne le codage reprsentant un individu dune population, la fonction fitness pour valuer la qualit de lindividu, les critres de croisement et de mutation, et
comme rsultat, elle gnre la solution demande. La figure 5.12 illustre notre dmarche ( base
dun algorithme gntique) de rsolution de notre problme de slection de vues matrialises.
Nous considrons pour chaque vue, lespace quelle occupe et le profit quon obtient si elle
est la vue seule qui est matrialise. Lespace occup est gal au cot daccs comme voqu
ci-dessus (5.1.1.2). Le profit dune vue v est dfini comme la diffrence entre le cot total de la
charge sans vue et le cot total de la charge si la vue v est matrialise.
pro f it(v) =
X
qQ
f req(q) cout(q, )
X
qQ
f req(q) cout(q, M)
(7)
o freq(q) est la frquence de la requte q et M={v}.

Le problme revient trouver un ensemble de vues dont la somme des espaces occups soit
infrieure ou gale la contrainte de stockage S et qui maximisent les profits. Nous dfinissons
notre chromosome comme un tableau de bits (0 ou 1) (Figure 5.12). Tous les nuds intermdiaires de notre plan unifi de requtes sont mapps dans le tableau de bits. Si le bit une
position est 1, cela veut dire que le nud correspondant est slectionn pour la matrialisation.
Une solution initiale est gnre de manire alatoire. Celle-ci sera amliore pour devenir une
bonne solution. Notre fonction fitness est base sur le maximum de profit de chromosome. En
effet, pour chaque chromosome (solution), la somme des bnfices de ses nuds et la somme
des espaces occups par ses nuds sont calcules. Si la somme des espaces occupes est infrieure la contrainte de stockage, le chromosome est dclar valide et peut tre amlior pour
devenir une solution, sinon le chromosome est non intressant et abandonn. Nous avons fait
usage des paramtres suivants souvent utiliss dans les algorithmes gntiques pour la slection des vues [198] : probabilit de croisement (crossover) : 0.8, probabilit de mutation : 0.02,
taille de la population : 1000 et le nombre maximum de gnration : 200. Cet algorithme nous
fournit des solutions assez intressantes au regard des rsultats de nos exprimentations. Hy137
Charge de Requtes {QB, , QC}
Construction dun plan unifi
E FGHIJ KLMINILOJ
?@
?@
t1
?A
t2
t4
t3
Taux de Mutation
& Taux de Croisement
Notre codage
1
. 1
1: si le nud est slectionn

0 : sinon
Contrainte
de Stockage
JeneGA
Fonction fitness
Un ensemble de vues matrialises
{VB, , VD}
Figure 5.12 Notre dmarche de rsolution base dun algorithme gntique

lock [198] a aussi montr que ces algorithmes sont trs bons pour le problme de slection des
vues matrialises.
5.1.2.2 Algorithme glouton. Notre algorithme glouton utilise la notion de bnfice par
unit despace (BPS) [199]. Le BPS est le rapport entre le bnfice quapporte une vue et lespace occup par cette vue. La notion de bnfice diffre de celle de profit dfinie ci-dessus. Le
bnfice prend en compte les apports des autres vues dj retenues alors que le profit dune vue
ne considre que lapport de cette vue seule.
bene f ice(v, M) =
X
qQ
f req(q) cout(q, M)
X
qQ
f req(q) cout(q, M v)
(8)
Lalgorithme calcule de manire itrative les bnfices de chaque vues et retient la vue ayant
le plus grand bnfice, jusqu ce que la contrainte de stockage ne soit plus respecte. Cet
algorithme est donn ci-dessous (la fonction S(v) calcule lespace occup par v).
138
6. Exprimentation
Algorithm 6 greedySelection
1: Entre : V : Plan unifi
2: Sortie : M : ensemble des vues matrialises
3: Dbut
4:
M=
5:
Tant que S(M) < S faire
6:
Pour chaque vue v faire
7:
calculer BPS(v,M)
8:
FinPour
9:
choisir v avec BPS maximum
10:
si (S(M) +S(v) <S) alors
11:
M = Mv
12:
V =V v
13:
Finsi
14:
finTantque
15:
Retourner M
16: Fin
NB : Les notions de larbre de requte et de plan unifi des requtes bas sur les patrons de
triplet prsentes sont valables dans tous les types de BDBO. Pour assurer le caractre gnrique de cette approche comme souhait, une abstraction est faite sur les reprsentations relles
sous-jacentes utilises dans les BDBO et les calculs commencent partir des rsultats individuels des patrons de triplet. Dans la mise en uvre, on doit considrer les cots de construction
de nuds de slection suivant le type de BDBO dont on dispose. Car bien que les tailles des
rsultats de patrons de triplet individuels sont senses tre les mmes quel que soit le type de
BDBO utilise; cest--dire que les rsultats dune requte de slection sur un mme jeu de
donnes doit tre les mmes quel que soit le type de BDBO utilise, mais les cots de calculs
ne sont pas les mmes. Les diffrentes tapes de cette approche sont illustres sur la figure 5.13.
6 Exprimentation
6.1 Ensembles de donnes pour les tests
Nous avons effectu des tests de validation de nos approches sur un ordinateur (PC) de
marque DELL dot dun Processeur Intel(R) Xeon(R) CPU E31225 3.10 GHZ, dune mmoire vive de 4GO et dun disque dur de 500GO. Nous avons utilis le benchmark LUBM [30].
Nous avons gnr les instances pour des jeux de donnes contenant 10 et 100 universits nots Lubm10 et Lubm100 respectivement. Les nombres dinstances de classes, de proprits, de
139
Figure 5.13 Les tapes de mise en oeuvre de lapproche simule

triplets et la taille des ensembles de donnes sont consigns dans le tableau 5.1. Nous avons
utilis les requtes fournies par le benchmark. Pour chaque requte, nous avons fait quatre mesures de temps de traitement et nous avons retenu la moyenne. Lunit de mesure du temps est
la milliseconde (ms). Nous avons fait cela pour les requtes initiales sans les vues matrialises et pour les requtes avec les vues matrialises dans les diffrentes approches. Nous avons
utilis le SGBD PostgreSQL 8.2. pour toutes les BDBO utilises. Nous ne prsentons que les
rsultats o la slection est faite laide de lalgorithme gntique car cest celui qui a donn
des meilleurs rsultats.
Jeux
de
Donnes
LumB10
LumB100
Nombre dinstances de
classe
1.052.895
2779262
Nombre dinstances de
proprits
1.273.108
11096694
Nombre de triplets
1.272.870
12.674.100
Table 5.1 Ensembles de donnes gnres.
6.2 Diffrents tests

Nous prsentons dans cette partie les diffrents tests effectus, les rsultats et leurs interprtations. Nous appelons TBA (Triple-Based Approach), notre approche base sur les patrons de
triplet et CBA (Class-Based Approach), notre approche base sur les classes (approche conceptuelle). Nos exprimentations sont ralises sur des BDBO existantes (Jena, Sesame et On140
6. Exprimentation
Temps de requtes sur Jena (LUBM10)
8000
7000
Temps(ms)
6000
5000
Sparql
4000
CBA
3000
TBA
2000
1000
0
1
11
12
14
Requtes
Figure 5.14 Temps de traitement de requtes sur LUBM10 sur la BDBO verticale
Temps de requte sur Jena (LUBM100)
70
60
Temps(sec)
50
40
sparql
CBA
30
TBA
20
10
0
1
11
12
14
Requtes
Figure 5.15 Temps de traitement de requtes sur LUBM100 sur la BDBO verticale
toDB) et sur une BDBO cre spcialement pour les tests que nous appelons BDBO native.
6.2.1
Exprimentations sur les BDBO existantes
Dans le but dvaluer nos approches dans des BDBO existantes, nous avons cr et utilis
une BDBO verticale (Jena), une BDBO binaire (Sesame) et une BDBO horizontale (OntoDB).
Considrant une charge de quatorze requtes constitue des requtes du benchmark LUBM, et
grce nos approches, nous avons choisi un ensemble de vues que nous avons cres sur ces
BDBO. Nous avons excut la charge de requtes sur les BDBO sans les vues matrialises
avec un moteur SPARQL (ce rsultat est dsign sur les figures par Sparql) et avec les vues
matrialises laide dun moteur SQL. Les rsultats sont prsents sur les figures 5.14 5.19.
141
Temps de requtes sur Sesame (LUBM10)
25000
Temps (ms)
20000
SPARQL
15000
CBA
TBA
10000
5000
0
1
11
12
14
Requtes
Figure 5.16 Temps de traitement de requtes sur LUBM10 sur la BDBO Binaire
Temps de requtes sur Sesame(LUBM100)
25
Temps (sec)
20
15
SPARQL
10
CBA
TBA
0
1
11
12
14
Requtes
Figure 5.17 Temps de traitement de requtes sur LUBM100 sur la BDBO Binaire
Temps de requtes sur OntoDB (LUBM10)
25000
Temps (ms)
20000
SPARQL
15000
CBA
TBA
10000
5000
0
1
11
12
14
Requtes
Figure 5.18 Temps de traitement de requtes sur LUBM10 sur la BDBO horizontale
142
6. Exprimentation
Temps de requtes sur OntoDB (LUBM100)
25
Temps (sec)
20
15
SPARQL
10
CBA
TBA
0
1
11
12
14
Requtes
Figure 5.19 Temps de traitement de requtes sur LUBM100 sur la BDBO horizontale
6.2.1.1 Interprtation des rsultats. TBA fournit des bons rsultats pour toutes les requtes qui utilisent les vues matrialises. Les requtes qui nont pas de vues appropries sont
excutes sur les tables de la BDBO. Leurs rsultats sont moins bons que si elles sont excutes avec un moteur SPARQL. En fait, les moteurs SPARQL de Jena et de Sesame utilisent des
techniques doptimisation et sont plus rapides que le moteur SQL "plat". Castillo et Leser [142]
ayant utilis la rcriture SPARQL-SQL ont fait la mme remarque. Cela veut dire que laccs
la table de triplets de jena travers ARQ 25 , par exemple, est plus rapide que laccs avec un
moteur SQL. CBA trane dernire TBA et produit des rsultats moins intressants que le moteur
SPARQL pour certaines requtes car certaines vues obtenues sont de tailles importantes. Cest
le cas de requtes 1 et 3 qui portent sur les vues GraduateStudent et Publication qui sont assez
grandes. Cependant, la mthode CBA donne un temps cumul acceptable malgr le fait que pour
des requtes individuelles, les rsultats soient mitigs. Nous pouvons amliorer lapproche TBA,
en utilisant un moteur SPARQL pour des requtes nayant pas de vues appropries. Cependant
si la requte est partiellement couverte, il nous faut combiner les moteurs SQL et SPARQL.
Nous remarquons que lapproche CBA ragit bien sur des jeux de donnes de taille moyenne
mais ses performances se dgradent quand la taille de donnes devient importante. On peut voir
cela en comparant les figures 5.14 et 5.15. En ralit, quand plusieurs proprits dune classe
sont impliques dans la charge de requtes, la vue correspondante est large (cest--dire quelle
dispose de plusieurs colonnes), cela peut alourdir le chargement de cette vue qui peut ncessiter
plusieurs oprations dentres-sorties, surtout lorsque toute la vue est balaye.
25. moteur SPARQL implment dans Jena
143
Sparql
TBA
InriaID
InriaText
CBA
1000000
100000
Time(sec)
10000
1000
100
10
1
1
7
8
Requtes
11
12
14
Figure 5.20 Temps de traitement de requtes sur LUBM10 sur la BDBO native
6.2.2
Exprimentations sur une BDBO native et rsultats
Les exprimentations sur les BDBO existantes subissent linfluence des techniques doptimisation mises en uvre sous ces systmes, par exemple lexistence de certains index ou
clusters, lutilisation des dictionnaires, etc. Pour viter de fausser les rsultats des exprimentations par ces influences et pour comparer au plus juste notre travail avec un travail similaire
men par lINRIA 26 [182] qui utilise aussi une BDBO native sous PostgreSQL, nous avons
cr une BDBO verticale sous PostgreSQL. Sur cette BDBO, nous avons appliqu nos deux
approches mais aussi lapproche de lINRIA [182]. Il faut noter que cette dernire utilise un
dictionnaire et fournit des rsultats sous forme didentifiants. Nous appelons Inria_ID les rsultats de cette approche avec les identifiants et Inria_T exte les rsultats de la mme approche
mais sous forme de texte. Lexcution et la mesure des temps de traitement des requtes dans
les diffrentes approches donnent les rsultats prsents sur les figures 5.20 et 5.21.
6.2.2.1 Interprtation des rsultats. La plupart de nos requtes utilisant des vues sexcutent plus rapidement dans lapproche Inria_ID et TBA. Dans TBA, les requtes (par exemple
la requte 14) ne portant sur aucune vue slectionne sont excutes directement sur la table de
triplets. La diffrence entre les rsultats des approches TBA et Inria_ID sexplique par le fait
que cette dernire ne manipule que des valeurs entires et que les oprations y sont plus rapides
que dans les autres approches qui manipulent les chanes de caractres.
Lapproche de lINRIA [182] avec des rsultats textuels (Inria_T exte) donne un temps
moins bon que lapproche TBA. En effet, toutes les requtes ncessitent une ou plusieurs jointures avec la table dictionnaire pour le renvoi des valeurs textuelles. Cela ncessite un temps
important quand la liste des variables exportes est longue et quand il y a assez de tuples favo26. Institut National de Recherche en Informatique et en Automatique
144
6. Exprimentation
Sparql
TBA
InriaID
InriaText
CBA
10000000
1000000
Time(sec)
100000
10000
1000
100
10
1
1
7
8
Requtes
11
12
14
Figure 5.21 Temps de traitement de requtes sur LUBM100 sur la BDBO native
120
Temps (sec)
100
SPA RQL
TBA
80
60
SPA RQL
CBA
SPA RQL
CBA
CBA
40
TBA
TBA
20
0
Vericale
Binaire
Horizontale
Figure 5.22 Temps total de traitement de la charge de requtes sur les BDBO
rables (cest le cas de la requte 7).

Par rapport toute la charge de requtes, lInria_ID fournit un bon temps global suivi
de la mthode CBA pour les BDBO verticales (figures 5.23). Le temps global de TBA pour
ce type de BDBO augmente en raison des requtes ne bnficiant pas des vues. En effet, ces
requtes sont traduites en SQL et excutes sur la table des triplets, leurs temps dexcution sont
mauvais et influencent le temps cumul. Mises part ces requtes, tous les temps de rponse
de TBA sont bons. Il faut noter que toutes les approches prsentent un gain substantiel pour les
temps cumuls pour la charge de requtes comme le montre les figures 5.22 et 5.23. Lapproche
TBA est meilleure pour toute la charge de requtes dans les BDBO binaires et horizontales
(figures 5.22).
145
Temps(sec)
Temps de tratement de la charge de requtes sur la BDBO native(LUBM100)
6000
Sparql
5000
Sparql
TBA
4000
InriaID
InriaText
3000
CBA
2000
1000
InriaID
0
Approches
Figure 5.23 Temps total de traitement de la charge de requtes sur la BDBO native
6.2.3
Influences de la contrainte de stockage
Pour tudier linfluence de la taille de lespace rserv pour les vues matrialises sur le processus de slection de vues, nous avons fix la contrainte 1%, 10% et 25% de la taille de toutes
les vues candidates. Ensuite, nous avons fait des slections des vues que nous avons cres pour
chaque cas. Enfin, nous avons excut et mesur le temps dexcution des requtes de notre
charge de requtes pour chaque cas. Nous avons utilis lapproche TBA. Les rsultats obtenus
sont prsents sur la figure 5.24. Nous constatons que quand la contrainte de stockage est trs
forte cest--dire que taille despace rserv aux vues matrialises est petite (par exemple dans
notre cas, 1% de lespace ncessaire pour toutes les vues), la slection est oriente vers les
vues de slection. Et les rsultats sont aussi mitigs car ces vues napportent pas grand-chose
lexcution de requtes. A partir de 25% despace de toutes les vues, on obtient un rsultat
intressant.
7 Conclusion
Dans ce chapitre nous nous sommes penchs sur le problme de conception physique des
BDBO. Vu la complexit de ce problme, nous avons choisi de traiter uniquement du problme
de la slection des vues matrialises. La diversit des modles de stockage et des architectures de ce type de BD complique davantage le problme de slection. Une exploration de ltat
de lart sur la question nous a permis de constater que, dans les BDBO, il na t trait que
pour des BDBO verticale utilisant la table des triplets. Les approches proposes sont difficilement applicables tous les types de BDBO. Pour couvrir les diffrents types de BDBO, nous
avons prsent deux approches de rsolution : une approche dfinie au niveau conceptuel (ontologique) base sur les classes impliques dans les requtes et une approche dfinie au niveau
logique base sur les patrons de triplet utiliss dans la charge de requtes. La premire approche
146
7. Conclusion
Influence de la contrainte de stockage
120000
100000
80000
1%V
10*V
60000
25%V
ViewLess
40000
20000
0
1
11
12
14
Requtes
Figure 5.24 Influence de la contrainte de stockage sur la slection.

fait abstraction de limplmentation tandis que la seconde prend en compte le modle de stockage sous-jacent et utilise un modle de cot adapt propos dans le chapitre prcdent. Ce
modle de cot offre une grande flexibilit et permet de quantifier la qualit des solutions lors
de la phase de slection. Ces approches se veulent gnriques et prennent en compte la diversit
des schmas de reprsentation des BDBO, donc sappliquent tout type de BDBO. Les exprimentations sur les diffrents types de BDBO montrent que ces approches sont pertinentes.
Une comparaison avec les travaux antrieurs a t faite. Le tableau 5.2 rvle quelques points
de comparaison de nos approches avec celles de Goasdou et al. [182] et Castillo et Leser [142].
Les index gnrs par la mthode de Castillo et Leser [142] prsentent une grande ressemblance avec nos vues. En effet, tant donn que ces index sont des combinaisons des patrons
de triplet, certains dentre eux se retrouveraient tre nos nuds intermdiaires. Mais comme,
toutes les combinaisons possibles dune certaine longueur k sont gnres, certains de ces index ne se trouveront pas dans notre approche. Par contre, si k=1, toutes nos vues vont se retrouver parmi celles de Castillo et Leser [142]. A la diffrence de Castillo et Leser [142] qui
gnre les vues candidates par la combinaisons de tous les composants connexes dune certaine longueur k, nous construisons un plan unifi dexcution de toutes les requtes et nous
slectionnons les nuds les plus profitables pour le traitement de notre charge de requtes.
Nous savons que la slection des vues est un problme NP-complet [200], et donc gnrer
un grand nombre de vues compliquerait davantage lobtention de la solution optimale. Dans
lapproche de Castillo et Leser [142], pour une requte q ayant n patrons de triplet, on obP
tient i=k..n Cin index. (cest--dire, la somme de combinaison de i dans n). Pour une charge de
P P
requtes Q, on peut avoir au pire des cas : qQ i=k..n Cin index.
147
Le travail de Wilkinson [201] utilise une structure qui ressemble notre approche base
sur les classes mais leurs proprits regroupes peuvent provenir des diffrentes classes. Il faut
noter que ce travail est plus relatif aux structures de stockage. Celui de Mengdong et Wu [202]
sur la mise en cache de certains rsultats des requtes SPARQL en vue dacclrer le traitement
dautres requtes dans le cadre du Web Smantique ressemble notre approche base sur les
triplets (TBA) car les rsultats mis en cache sont certains nuds de notre plan unifi de requtes.
En revanche la slection et matrialisation de ces nuds ntaient pas proposes.
Critres
Type de BDBO
Dploiement
Structure de donnes
Schma dontologie
Frquences
Contrainte de stockage
CBA
I, II, III
centralis
graphe
TBA
I, II et III
centralis
graphe
Goasdou et al.
I
centralis
multi-graphe
Castillo et Leser
I
centralis
graphe
utilis
non
non
oui
non
oui
oui
modle de cot
cot
de
construction +
cot accs
cot
de
construction +
cot accs
utilis pour infrence

non
minimise le stockage mais pas de
contrainte
cot cpu + esp de
stockage +maintenance
oui
oui
cot de stockage
Table 5.2 Comparaison des approches de PSVM.

Notre approche base sur les classes prsente quelques dsavantages notamment la multiplicit de vues quand il y a une forte hirarchie des classes (ce qui compliquerait la matrialisation)
et la taille de vues qui a tendance tre norme. Linconvnient de cette seconde approche est
galement le grand nombre de calculs ncessaires pour la recherche du plan unifi optimal.
148
Conclusion gnrale et perspectives
149
Chapitre
6
Conclusion et Perspectives
6.1
Conclusion
Avec le dveloppement de nombreuses ontologies dans diffrents domaines comme le Web

Smantique ou lingnierie, le besoin de stocker ces dernires dans des bases de donnes a
conduit la notion de BDBO. Comme pour toutes les gnrations de bases de donnes, que ce
soient les bases de donnes relationnelles, objet, XML ou dcisionnelles, la conception physique
dune BDBO est un problme crucial pour garantir des temps de rponses acceptables aux
requtes des utilisateurs. Cette phase vise, en effet, slectionner un ensemble de structures
doptimisation sur une base de donnes pour optimiser une charge de requtes. Cette phase
repose donc sur la formalisation de la base de donnes considre. En tudiant les travaux mens
sur la conception physique des BDBO, nous avons identifi que cette formalisation consiste
dfinir une BDBO comme une table de triplets qui est une reprsentation direct du langage RDF
utilis dans le contexte du Web Smantique. Or, les ontologies tant utilises dans de nombreux
autres domaines et certaines tant dfinies avec dautres modles dontologies que ceux du Web
Smantique, toutes les BDBO ne se rduisent pas une table de triplets. Nos travaux ont ainsi
vis prendre en compte la diversit des BDBO dans la phase de conception physique de ces
dernires.
Les diffrentes contributions de ce travail sont les suivantes.
6.1.1 Etat de lart sur les BDBO

La premire contribution de notre travail est un tat de lart dtaill des BDBO afin de
dfinir les critres permettant de diffrencier les BDBO qui jouent un rle important pour la
phase de conception physique de ces bases de donnes. Les critres identifis sont les suivants.
151
Chapitre 6. Conclusion et Perspectives

6.1.1.1
Modle dontologie
Nous avons identifi que plusieurs modles dontologies sont utiliss pour dfinir des ontologies. Ces modles dontologies diffrent selon les objectifs viss : certains se focalisent sur la
gestion et lchange de donnes, comme par exemple PLIB et RDFS, dautres sont orients vers
linfrence sur les donnes, comme par exemple DAML-ONT, DAML+OIL, F-Logic, et OWL.
Chaque BDBO supporte un ou plusieurs modles dontologies ce qui a un impact sur les performances associes puisque ces modles diffrent sur leur expressivit et sur les mcanismes
de raisonnement proposs.
6.1.1.2
Modle de stockage
Contrairement un modle conceptuel, une ontologie ne prescrit pas les proprits qui sont
utilises pour dcrire une instance, elle dcrit uniquement toutes les proprits qui peuvent tre
utilises pour les caractriser. Ainsi, les instances ontologiques peuvent tre plus ou moins structures, cest--dire que les instances peuvent navoir quun petit nombre de proprits de lontologie (structuration faible) ou inversement un grand nombre de proprits (structuration forte).
La structuration des donnes est un facteur important lorsque lon souhaite choisir un schma
de bases de donnes performant pour les stocker. La structuration des instances ontologiques
tant varies et les BDBO stockant aussi lontologie associe, trois principales approches ont
t proposes pour la persistance de lontologie associe et ses instances. (1) Lapproche verticale o les ontologies et les donnes sont reprsentes dans un mme schma contenant une
table principale appele table de triplets constitue de trois colonnes (sujet, prdicat, objet).
Ce schma rappelle la structure du RDF sur lequel se basent les modles dontologies RDFS,
DAML-OIL, OWL, etc. (2) Lapproche binaire qui dcompose les relations en deux catgories :
les relations unaires (pour lappartenance aux classes), et les relations binaires (pour les valeurs
de proprits). Cette approche a trois variantes suivant lapproche adopte pour la reprsentation
de lhritage : (a) une table unique pour toutes les classes de lontologie, (b) une table par classe
avec hritage de table (si une base de donnes relationnelle-objet est utilise) et (c) une table
par classe sans hritage de table. Toutes ces variantes utilisent une table binaire pour chaque
proprit. (3) Lapproche horizontale qui associe chaque classe de lontologie une table ayant
une colonne pour chaque proprit associe une valeur pour au moins une instance de cette
classe. Le choix dun modle de stockage particulier influence directement les performances
des requtes puisque celles-ci seront traduites par diffrentes oprations relationnelles sur le
SGBD sous-jacent.
6.1.1.3
Architecture
Contrairement une base de donnes traditionnelle, une BDBO doit stocker en plus des
donnes lontologie qui en dcrit le sens. Cette "augmentation" a vu natre trois grandes ar152
6.1. Conclusion
chitectures de BDBO : (1) architecture de type I ou architecture "deux quarts" dans laquelle
les ontologies et les donnes sont reprsentes dans un mme schma. Cette architecture est
semblable celle des bases de donnes classiques utilisant deux parties : les donnes et la
mta-base, (2) architecture de type II ou architecture "trois quarts" o les ontologies et les
donnes sont spares et reprsentes dans deux schmas diffrents respectivement appels ontologie et donnes. Le schma ontologie est constitu dun ensemble de tables (class, property,
subclass, subproperty, domain, range, etc.) qui reprsente les constructeurs du modle dontologies (classes, proprits, etc.). Malgr cette sparation, cette architecture reste lie au modle
dontologies utilis, (3) architecture de type III ou architecture "quatre quarts" qui ajoute la
structuration prcdente une partie nomme mta-schma jouant, pour les ontologies, le mme
rle que celui jou par la mta-base pour les donnes. Cette partie stocke les constructeurs du
modle dontologies utilis. Elle permet ainsi un accs gnrique au modle ontologique ainsi
que lintroduction de nouveaux constructeurs issus de diffrents modles dontologies. Le choix
dune architecture particulire a un impact sur les performances puisque la taille des tables diminue lorsque lon dcompose le stockage des donnes dans plusieurs parties en fonction de
leur niveau dabstraction.
En considrant ces trois dimensions de la diversit des BDBO, nous avons dfini lespace
des BDBO comme tant un cube dont les axes sont respectivement les modles de stockage, les
architectures et les formalismes dontologies. Toute BDBO peut tre classe dans une cellule
de ce cube.
6.1.2 Evaluation de performance de BDBO

Pour pouvoir aborder le problme de la conception des BDBO au regard de la diversit
identifie prcdemment, il est important davoir une matrise des caractristiques de ces bases
de donnes. Pour cela, nous avons tudi quelques BDBO existantes et nous avons dgag leurs
principales caractristiques. Cette tude nous a permis de proposer un modle unifi des BDBO
qui intgre leur diversit. Ce modle unifi a t utilis pour comparer au niveau macroscopique
six BDBO largement utilises dans plusieurs communauts dont trois industrielles (Oracle,
IBM SOR et DB2RDF) et trois acadmiques (Jena, Sesame et OntoDB dveloppe au sein de
notre laboratoire). Pour complter cette tude, nous avons fait une valuation des performances
de ces six BDBO en termes de temps de chargement des donnes et en termes de temps de
traitement de requtes. Cela nous a permis didentifier des paramtres pertinents influenant le
traitement des requtes savoir larchitecture, le modle de stockage, le type de requte et le
SGBD sous-jacent.
153
6.1.3 Modle de cot pour les BDBO prenant en compte leur diversit
En dtaillant les travaux raliss sur la conception physique des bases de donnes traditionnelles, nous avons identifi que les modles de cot sont au cur de ces travaux. Or, nous
navons pas trouv de modle de cot dans la littrature qui prennent en compte la diversit des
BDBO. Nous avons donc propos un nouveau modle de cot bas sur le modle unifi des
BDBO introduit prcdemment. Notre modle de cot quantifie les entres-sorties ncessaires
pour le traitement dune requte. Il intgre la diversit des BDBO et peut aider les concepteurs
choisir un meilleur type de BDBO selon un critre de performance donn et une charge de
requtes usuelles. Ce modle de cot a t mis en application dans une tude que nous avons
mene dont les rsultats confirment partiellement ceux que nous avons obtenus dans ltude
exprimentale faite prcdemment. Les rsultats confirms sont les suivants. Le modle de stockage vertical est meilleur en matire de chargement des donnes mais il est trs coteux pour
les requtes (en raison des auto-jointures ncessaires sur la table de triplets). Le modle de stockage binaire est appropri pour les requtes de slection mono-triplet (avec peu de proprits)
et le modle de stockage horizontal pour les requtes de slections mono-triplet et pluri-triplets
mais le modle de stockage horizontal peut conduire des oprations dunions et la redondance des donnes. Concernant les rsultats thoriques non confirms par nos exprimentations
nous notons quils concernent des BDBO spcifiques. Nous pensons que cette divergence vient
doptimisations particulires faites dans ces BDBO ou des structures doptimisation utilises
que nous ne considrons pas dans notre modle de cot. En perspective de ces travaux sur le
modle de cot, il serait donc intressant de spcialiser notre modle pour une BDBO particulire.
6.1.4 Approches de slection des vues matrialises pour les BDBO

La dfinition du modle de cot prcdent, nous a permis daborder le problme de la
conception physique des BDBO. Ce problme tant trs large, nous nous sommes restreint
au problme de slection des vues matrialises dans les BDBO. Nous avons fait ce choix car
les vues matrialises sont des structures doptimisation qui permettent doptimiser de nombreux types de requtes et qui, par ailleurs, ont t peu traites dans la littrature. En effet, les
rares travaux effectus dans ce sens portent sur les BDBO verticales et ainsi ils ne prennent
pas en compte la diversit des BDBO. La formalisation du problme de la conception physique des BDBO sapparente celle des bases de donnes traditionnelles. Nous rappelons que
ce problme est NP-complet [200] dans les BD traditionnelles. La diversit des modles de
stockage et des architectures des BDBO vient compliquer ce problme. Nous avons identifi
trois approches pour traiter le problme de slection de vues matrialises dans le contexte des
BDBO : (i) la slection base sur lontologie et les requtes. Cette approche que nous appelons
aussi slection conceptuelle est originale car elle remonte la tche de slection des vues matrialise la phase conceptuelle. Ainsi, elle ne prend pas en compte limplmentation physique
154
6.2. Perspectives
de la base de donnes mais requiert uniquement le schma de lontologie. (ii) Une slection
impose, qui suppose lexistence pralable dune BDBO. Elle suppose donc la connaissance
du modle de stockage, du SGBD sous-jacent et des autres caractristiques de la BDBO. Elle
est similaire celle faite dans le contexte des bases de donnes traditionnelles. (iii) La dernire
approche appele approche simule intgre dans le processus de slection des vues matrialises la diversit des BDBO. Nous avons propos une approche conceptuelle et une approche
simule. Notre approche conceptuelle est base sur les classes de lontologie impliques dans la
charge des requtes. Elle fait une abstraction de limplmentation des BDBO. Par contre, elle
ncessite la prsence de lontologie. Notre approche simule prend en compte la phase logique,
physique et de dploiement. Elle est base sur les triplets. Elle est gnrique et applicable
tout type de BDBO. En effet, cette approche construit un graphe de requtes (plan unifi des
requtes) bas sur les patrons de triplet des requtes de la charge. Elle prend en compte le modle de stockage sous-jacent et utilise notre modle de cot dans le processus de la slection de
vues matrialises. Les exprimentations ralises sur les diffrents types de BDBO ont montr que nos approches sont pertinentes et comparables dautres approches traitant de la mme
question pour un type de BDBO particulier [182].
6.2
Perspectives
A court terme, nous pensons quil est important de faire une validation plus approfondie
de nos travaux. En effet, mme si nos exprimentations ont donn des rsultats intressants,
il est important de les raliser sur une plus grande volumtrie de donnes avec dautres benchmarks impliquant des requtes plus varies et sur dautres BDBO pour voir la robustesse de nos
propositions. Ct outillage, il serait intressant denvisager la mise au point dun simulateur
intgrant notre modle de cot et nos approches.
A plus long terme, nous notons que nos travaux ont t mens dans un contexte bien particulier o lon considre une BDBO comme un systme centralis ncessitant loptimisation dun
ensemble de requtes connu. Mme si nous pensons que ce contexte concerne de nombreux
cas dapplication, il serait intressant dlargir nos travaux en remettant en cause certaines hypothses faites. Nous pensons notamment au traitement des donnes massives ("big data") qui
apporte de nouvelles dimensions partiellement traites dans nos travaux. Nous dcrivons ces
dimensions ci-dessous et voquons des perspectives de recherche quelles impliquent pour nos
travaux.
6.2.1 Volume
Une BDBO centralise nest pas en mesure de grer des donnes massives. En effet, cellesci sont caractrises par lajout de traoctets de donnes par jour. Dans ce contexte, il est ncessaire de considrer les BDBO dans un contexte distribu ce que nous navons pas fait dans
155

nos travaux. Le partitionnement jouant un rle crucial dans cette problmatique et le partitionnement pouvant reposer sur un modle de cot, nous pensons quil serait intressant dtendre
nos travaux en considrant dautres structures doptimisation comme le partitionnement ou les
index succincts trs utiliss dans le contexte des donnes massives. Il faudra pour cela adapter
notre modle de cot ces structures doptimisation et prendre en considration les cots de
transfert de donnes. Il faudra galement revoir les algorithmes de slection puisque dans ce
cas, nous ne ferons plus une slection de manire isole sur les vues matrialises mais une
slection en combinant un ensemble de structures doptimisation qui peuvent avoir un impact
lune sur lautre.
6.2.2 Varit
Dans nos travaux nous avons considr le stockage dontologies et de leurs instances. Comme
nous lavons vu, ces donnes prsentent une diversit qui ont t au cur de nos travaux. Dans
le cadre des donnes massives, cette varit est encore plus grande puisquil sagit de traiter des
donnes de diverses natures qui peuvent tre ontologiques mais galement semi-structures,
textuelles, multimdia, etc. La gestion de cette diversit a vu natre de nombreuses nouvelles
solutions de stockage qualifies de NoSQL ou NewSQL qui proposent des performances et des
fonctionnalits trs varies. Une des questions centrales actuellement est de dterminer la solution utiliser lorsque lon fait face un problme de traitement de donnes massives. Nous
pensons que la dmarche que nous avons suivie dans nos travaux pourrait tre intressante pour
ce problme que nous qualifions de "dploiement". Il sagirait dabord de bien tudier les solutions NoSQL et NewSQL proposes pour identifier les dimensions de leur diversit et de
confirmer ces dimensions par des tudes exprimentales. Cette tude devrait permettre de dterminer si il est possible de construire un modle unifi pour ses solutions et un modle de cot
associ qui permettrait alors de traiter le problme du dploiement.
6.2.3 Vlocit
Dans nos travaux, nous considrons un contexte statique o lontologie est stable et les
requtes importantes sont connues lavance. Ces hypothses ne sont pas forcment vraie dans
un contexte de traitement de donnes massives o lon considre que les donnes doivent tre
captures et analyses en temps rel. Dans une BDBO, cela voudrait dire que lontologie et/ou
ses instances pourraient tre mises jour frquemment et que les requtes pourraient ne pas
tre connues lavance. Il faudrait donc tudier les impacts de lvolution de lontologie et
des donnes sur les approches de slection des vues matrialises proposes dans nos travaux.
De mme, il faudrait redfinir ce problme, lorsque la charge de requte est dynamique. Enfin,
le problme de maintenance des vues matrialises serait crucial dans un tel contexte puisque
les donnes changeraient rapidement. Aussi, il serait ncessaire daborder la question de la
maintenance incrmentale des vues matrialises dans les BDBO.
156
Bibliographie
[1] M. Rousset et C. Reynaud, PICSEL and xyleme: Two illustrative information integration agents , in Intelligent Information Agents - The AgentLink Perspective, p. 5078,
2003.
[2] G. Pierra, Context representation in domain ontologies and its use for semantic integration of data , Journal Of Data Semantics (JoDS), vol. 10, p. 174211, 2008.
[3] S. Bechhofer, F. van Harmelen, J. Hendler, I. Horrocks, D. McGuinness,
P. Patel-Schneider et L. Stein, Owl web ontology language reference , W3C,
http://www.w3.org/TR/owlref/, 2004.
[4] D. J. Abadi, A. Marcus, S. R. Madden et K. Hollenbach, Scalable Semantic Web
Data Management Using Vertical Partitioning , in Proceedings of the 33rd International
Conference on Very Large Data Bases (VLDB07), p. 411422, 2007.
[5] S. Alexaki, V. Christophides, G. Karvounarakis, D. Plexousakis et K. Tolle, The icsFORTH RDFSuite: Managing voluminous RDF description bases , in Proceedings of
the 2nd International Workshop on the Semantic Web, p. 113, 2001.
[6] K. Wilkinson, Jena Property Table Implementation , in Proceedings of the 2nd International Workshop on Scalable Semantic Web Knowledge Base Systems (SSWS06),
p. 3546, 2006.
[7] B.McBride, Jena: Implementing the rdf model and syntax specification , in Proceedings of the 2nd International Workshop on the Semantic Web, 2001.
[8] Z. Pan et J. Heflin, Dldb: Extending relational databases to support semantic web queries , in Proceedings of the 1st International Workshop on Practical and Scalable Semantic Systems (PSSS03), p. 109113, 2003.
[9] H. Dehainsala, G. Pierra et L. Bellatreche, OntoDB: An Ontology-Based Database
for Data Intensive Applications , in Proceedings of the 12th International Conference
on Database Systems for Advanced Applications (DASFAA07), p. 497508, 2007.
[10] A. Seaborne, Rdql a query language for rdf , W3C Member Submission 9 January,
2004. http://www.w3.org/Submission/2004/SUBM-RDQL-20040109/.
157
Bibliographie
[11] J. Broeskstra et A. Kampman, SeRQL: A Second Generation RDF Query Language ,
in SWAD-Europe Workshop on Semantic Web Storage and Retrieval, November 2003.
[12] G. Karvounarakis, S. Alexaki, V. Christophides, D. Plexousakis et M. Scholl, RQL:
a declarative query language for RDF , in Proceedings of the Eleventh International
World Wide Web Conference (WWW02), p. 592603, 2002.
[13] L. Miller, A. Seaborne et A. Reggiori, Three Implementations of SquishQL, a Simple
RDF Query Language , in Proceedings of the 1st International Semantic Web Conference (ISWC02), p. 423435, 2002.
[14] E. Prudhommeaux et A. Seaborne, Sparql query language for rdf , W3C Candidate
Recommendation 14 June, 2007. http://www.w3.org/TR/rdf-sparql-query/.
[15] S. Jean, Y. Ait-Ameur et G. Pierra, Querying Ontology Based Database Using OntoQL
(an Ontology Query Language) , in ODBASE06, p. 704721, 2006.
[16] C. D. Rogozan, Gestion de lvolution des ontologies: mthodes et outils pour un rfrencement smantique volutif fond sur une analyse des changements entre versions
dontologie. Thse doctorat, Universit du Qubec Montral, 2009.
[17] P. Foulquie et R. Saint-Jean, Dictionnaire de la langue philosophique. Paris, Presses
Universitaires de France, 1962.
[18] L. Meynard, La Mtaphysique. Dans Foulq.-St-Jean 1962, 1959.
[19] T. R. Gruber, Formal ontology in conceptual analysis and knowledge representation.
Chapter: Towards principles for the design of ontologies used for knowledge sharing.
Kluwer Academic Publishers., 1993.
[20] G. Pierra, Context representation in domain ontologies and its use for semantic integration of data , Journal Of Data Semantics (JODS), vol. 4900, p. 173210, 2008.
[21] D. Brickley et R. Guha, Rdf vocabulary description language 1.0: Rdf schema , W3C,
http://www.w3.org/TR/rdfschema/, 2002.
[22] ISO-13584-42, Industrial Automation Systems and Integration Parts LIBrary Part 42 :
Description methodology : Methodology for Structuring Parts families , rap. tech., ISO,
1998.
[23] N. Guarino, Formal ontology in information systems: Proceedings of the first international conference (FOIS98), June 6-8, Trento, Italy, vol. 46. IOS press, 1998.
[24] P. R. S. Visser, M. D. Beer, T. J. M. Bench-Capon, B. M. Diaz et M. J. R. Shave, Resolving ontological heterogeneity in the kraft project , in Proceedings of the 10th International Conference on Database and Expert Systems Applications, DEXA 99, (London,
UK), p. 668677, Springer-Verlag, 1999.
[25] G. A. Miller, Wordnet: a lexical database for english , Communications of the ACM,
vol. 38, p. 3941, 1995.
158
[26] R. Apweiler, A. Bairoch, C. H. Wu, W. C. Barker, B. Boeckmann, S. Ferro, E. Gasteiger, H. Huang, R. Lopez, M. Magrane, M. J. Martin, D. A. Natale, C. O. Donovan,
N. Redaschi et L. S. Yeh, Uniprot: the universal protein knowledgebase , Nucleic Acids
Research, vol. 32, p. D115D119, 2004.
[27] G. Pierra, Context-explication in conceptual ontologies: Plib ontologies and their use
for industrial data , Journal of Advanced Manufacturing Systems, World Scientific Publishing Company, 2006.
[28] S. Jean, G. Pierra et Y. Ait-Ameur, Domain Ontologies : a Database-Oriented Analysis,
vol. 1, p. 238254. Springer, 2007.
[29] S. Weibel, The dublin core: a simple content description model for electronic resources , Bulletin of the American Society for Information Science and Technology,
vol. 24, p. 911, 1997.
[30] Z. P. Y. Guo et J. Heflin, Lubm: A benchmark for owl knowledge base systems , in
Journal of Web Semantics, vol. 3, p. 158182, 2005.
[31] G. Pierra, Context-explication in conceptual ontologies : The plib approach , in Proc.
of Concurrent Engineering (CE2003), p. 243254, July 2003.
[32] M. Kifer, G. Lausen et J. Wu, Logical Foundations of Object-Oriented and FrameBased Languages , Journal of the ACM (JACM), vol. 42, p. 741843, 1995.
[33] D. Connolly, F. van Harmelen, I. Horrocks, D. L. McGuinness, P. F. Patel-Schneider et
L. A. Stein, DAML+OIL Reference Description. World Wide Web Consortium, december 2001. http://www.w3.org/TR/daml+oil-reference.
[34] M. Klaene, Using ibatis sql maps for java data access , Resources for Java server-side
developers, vol. 1, 2004.
[35] P. Hitzler, M. Krtzsch et S. Rudolph, Foundations of semantic web technologies ,
Chapman & Hall/CRC, 2009.
[36] F. Manola, E. Miller, B. McBride et al., Rdf primer , W3C recommendation, vol. 10,
p. 6, 2004.
[37] D. C. Fallside, Xml schema part 0: primer second edition , W3C recommendation,
2004.
[38] M. Smith, C. Welty et D. L. McGuinness, Owl web ontology language guide. w3c
recommendation , URL http://www. w3. org/TR/owl-guide, 2009.
[39] S. Tobies, Complexity Results and Practical Algorithms for Logics in Knowledge Representation. Thse doctorat, RWTH Aachen, Germany, 2001.
[40] J. Zhou, L. Ma, Q. Liu, L. Zhang, Y. Yu et Y. Pan, Minerva: A scalable owl ontology
storage and inference system , in The Semantic Web Conference, p. 429443, Springer,
2006.
[41] P. Spyns, R. Meersman et M. Jarrar, Data modelling versus ontology engineering ,
ACM SIGMod Record, vol. 31, no. 4, p. 1217, 2002.
159
Bibliographie
[42] C. Fankam, L. Bellatreche, D. Hondjack, Y. A. Ameur et G. Pierra, Sisro, conception
de bases de donnes partir dontologies de domaine. , Technique et Science Informatiques, vol. 28, no. 10, p. 12331261, 2009.
[43] M. Lenzerini, Data integration : A theoretical perspective , Proceedings of the ACM
SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems (PODS02),
p. 233246, June 2002.
[44] Roldan-Garcia, M. Navas-Delgado, Aldana-Montes et J. Aldana-Montes, A design
methodology for semantic web database-based systems , Third International Conference on Information Technology and Applications(ICITA05), vol. 1, p. 233237, 2005.
[45] V. Sugumaran et V. C. Storey, The role of domain ontologies in database design: An
ontology management and conceptual modeling environment , in ACM Trans. Database
Syst., vol. 31, (New York, NY, USA), p. 10641094, ACM Press, 2006.
[46] G. Pierra, H. Dehainsala, Y. Ait-Ameur et L. Bellatreche, Base de Donnes Base
Ontologique : principes et mise en uvre , Ingnierie des Systmes dInformation,
vol. 10, p. 91115, 2005.
[47] K. Wilkinson, C. Sayers, H. Kuno et D. Reynolds, Efficient rdf storage and retrieval in
jena2 , HP Laboratories Technical Report HPL-2003-266, p. 131150, 2003.
[48] J. Broekstra, A. Kampman et F. van Harmelen, Sesame: A generic architecture for storing and querying rdf and rdf schema , in Proceedings of the 1st International Semantic
Web Conference (ISWC02), p. 5468, 2002.
[49] M. J. Park, J. H. Lee, C. H. Lee, J. Lin, O. Serres et C. W. Chung, An Efficient and Scalable Management of Ontology , in Proceedings of the 12th International Conference
on Database Systems for Advanced Applications (DASFAA07), p. 975980, 2007.
[50] L. Ma, Z. Su, Y. Pan, L. Zhang et T. Liu, RStar: an RDF Storage and Query System for
Enterprise Resource Management , in Proceedings of the 30th International Conference
on Information and Knowledge Management (CIKM04), p. 484491, 2004.
[51] E. Bozsak, M. Ehrig, S. Handschuh, A. Hotho, A. Maedche, B. Motik, D. Oberle,
C. Schmitz, S. Staab, L. Stojanovic, N. Stojanovic, R. Studer, G. Stumme, Y. Sure,
J. Tane, R. Volz et V. Zacharias, Kaon - towards a large scale semantic web , in
Proceedings of the 3rd International Conference on E-Commerce and Web Technologies
(EC-WEB02), (London, UK), p. 304313, Springer-Verlag, 2002.
[52] S. Harris et N. Gibbins, 3store: Efficient Bulk RDF Storage , in Proceedings of the 1st
International Workshop on Practical and Scalable Semantic Systems (PSSS03), p. 115,
2003.
[53] K. Stoffel, M. Taylor et J. Hendler, Efficient Management of Very Large Ontologies ,
in Proceedings of the 14th National Conference on Artificial Intelligence and 9th Innovative Applications of Artificial Intelligence Conference AAAI97/IAAI97, p. 442447,
1997.
160
[54] S. Das, Rdf support in oracle rdbms , Oracle Technical Presentation, 2009.
[55] C. Murray, Oracle spatial resource description framework (rdfi) , Oracle Corporation,
2005.
[56] IBM, Thinking ontologies at ibm center for advanced studies , IBM Center for Advanced Studies of Rome, 2006.
[57] C. Fankam, Ontodb2 : un systme flexible et efficient de base de donnes base ontologique pour le web smantique et les donnes techniques , ph.d. thesis, Poitiers University, 2009.
[58] Y. Theoharis, V. Christophides et G. Karvounarakis, Benchmarking Database Representations of RDF/S Stores , in Proceedings of the 4th International Semantic Web
Conference (ISWC05), p. 685701, 2005.
[59] J. Lu, L. Ma, L. Zhang, J.-S. Brunner, C. Wang, Y. Pan et Y. Yu, Sor: a practical system
for ontology storage, reasoning and search , in Proceedings of the 33rd international
conference on Very large data bases (VLDB07), p. 14021405, 2007.
[60] D. Nguyen-Xuan, Intgration de base de donnes htrognes par articulation apriori
dontologies : application aux catalogues de composants industriels. Thse doctorat,
LISI/ENSMA et Universit de Poitiers, 2006.
[61] M. del Mar Roldan Garcia, I. N. Delgado et J. F. A. Montes, A Design Methodology
for Semantic Web Database-Based Systems , in Proceedings of the 3rd International
Conference on Information Technology and Applications (ICITA05), p. 233237, IEEE
Computer Society, 2005.
[62] N. Belaid, Y. Ait Ameur et J. F. Rainaud, A semantic handling of geological modeling workflows , in International ACM Conference on Management of Emergent Digital
EcoSystems, p. 8390, 2009.
[63] S. Khouri et L. Bellatreche, Osons tout persister dans un entrept: Donnes et modles , in 7mes Journes Francophones sur les Entrepts de Donnes et analyse en
Ligne (EDA11), 2011.
[64] Object Management Group, Meta Object Facility (MOF), formal/02-04-03, october 2002.
[65] J. Bailey, F. Bry, T. Furche et S. Schaffert, Web and semantic web query languages: A
survey , in Proceedings of the First international conference on Reasoning Web, p. 35
133, Springer-Verlag, 2005.
[66] J. J. Carroll, C. Bizer, P. Hayes et P. Stickler, Named Graphs, Provenance and Trust ,
in Proceedings of the 14th international conference on World Wide Web (WWW05),
(New York, NY, USA), p. 613622, ACM Press, 2005.
[67] K. Tolle et F. Wleklinski, easy RDF Query Language (eRQL), 2004.
http://www.dbis.informatik.uni-frankfurt.de/~tolle/RDF/eRQL.
161
Bibliographie
[68] J. Robie, L. M. Garshol, S. Newcomb, M. Fuchs, L. Miller, D. Brickley, V. Christophides et G. Karvounarakis, The syntactic web: Syntax and semantics on the web ,
Markup Languages: Theory and Practice, vol. 3, p. 411440, 2001.
[69] D. Steer, Treehugger 1.0 introduction , Online only, 2003.
[70] U. Ogbuji, Thinking xml: Basic xml and rdf techniques for knowledge management:
Part 6: Rdf query using versa , Online only, April, 2002.
[71] K. Matsuyama, M. Kraus, K. Kitagawa et N. Saito, A path-based rdf query language
for cc/pp and uaprof , in Pervasive Computing and Communications Workshops, 2004.
Proceedings of the Second IEEE Annual Conference on, p. 37, IEEE, 2004.
[72] M. Marchiori, A. Epifani et S. Trevisan, Metalog v2. 0: Quick user guide , rap. tech.,
Technical report, W3C, 2004.
[73] E. Prudhommeaux, Algae rdf query language , Online only, 2004.
[74] T. Berners-Lee, N3qlrdf data query language , Online only, 2004.
[75] N. Bassiliades et I. P. Vlahavas, Capturing rdf descriptive semantics in an object oriented knowledge base system. , in WWW (Posters), 2003.
[76] M. Sintek et S. Decker, Triple a query, inference, and transformation language for
the semantic web , in The Semantic Web ISWC 2002, p. 364378, Springer, 2002.
[77] D. Reynolds, Rdf-qbe: a semantic web building block , rap. tech., Technical Report
HPL-2002-327, HP Labs, 2002.
[78] S. Powers, Practical rdf. " OReilly Media, Inc.", 2003.
[79] A. Seaborne, G. Manjunath, C. Bizer, J. Breslin, S. Das, I. Davis, S. Harris, K. Idehen,
O. Corby, K. Kjernsmo et al., Sparql/update: A language for updating rdf graphs ,
W3C Member Submission, vol. 15, 2008.
[80] R. Ramakrishnan, Database Management Systems. WCB/McGraw Hill, 1998.
[81] E. Bertino, M. Negri, G. Pelagatti et L. Sbattella, Object-oriented query languages:
The notion and the issues , IEEE Transactions on Knowledge and Data Engineering,
vol. 4, no. 3, p. 223237, 1992.
[82] L. V. S. Lakshmanan, d., Design and Management of Data Warehouses, Proceedings of
the 4th Intl. Workshop (DMDW02), Toronto, Canada, May 27, vol. 58in CEUR Workshop Proceedings, CEUR-WS.org, 2002.
[83] A. Datta, B. Moon, K. Ramamritham, H. Thomas et I. Viguier, Have your data and
index it, too: Efficient storage and indexing for datawarehouses , Techreport Technical
Report 98-7, Department of Computer Science, The University of Arizona, 1998.
[84] S. Chaudhuri et V. Narasayya, Self-tuning database systems: a decade of progress ,
in Proceedings of the 33rd international conference on Very large data bases, p. 314,
VLDB Endowment, 2007.
162
[85] B. Kamel, De la conception physique aux outils dadministration et de tuning des entrepts de donnes. Thse doctorat, ENSMA et Universit de Poitiers, juillet 2009.
[86] H. Gupta, V. Harinarayan, A. Rajaraman et J. D. Ullman, Index selection for olap , in
Proceedings of 13th International Conference on Data Engineering, p. 208219, IEEE,
1997.
[87] H. Gupta, Selection of views to materialize in a data warehouse , in ICDT, p. 98112,
1997.
[88] A. A. B. Lima, C. Furtado, P. Valduriez et M. Mattoso, Improving parallel olap query
processing in database clusters with data replication , Distributed and Parallel Database
Journal, vol. 25, no. 1-2, p. 97123, 2009.
[89] S. Agrawal, V. Narasayya et B. Yang, Integrating vertical and horizontal partitioning
into automated physical database design , in Proceedings of the ACM SIGMOD international conference on Management of data, p. 359370, ACM, 2004.
[90] D. Comer, The difficulty of optimum index selection , ACM Transactions on Database
Systems (TODS), vol. 3, p. 440445, 1978.
[91] N. Pasquier, Y. Bastide, R. Taouil et L. Lakhal, Discovering frequent closed itemsets ,
ICDT, p. 398416, 1999.
[92] M. Simonnard, Programmation linaire. Dunod, 1962.
[93] S. Chaudhuri et V. Narasayya, Autoadmin what-if index analysis utility , Proceedings of the ACM SIGMOD International Conference on Management of Data, p. 367
378, June 1998.
[94] H. Gupta, Selection and maintenance of views in a data warehouse , ph.d. thesis,
Stanford University, September 1999.
[95] J. Ullman, Efficient implementation of data cubes via materialized views , in the Proceedings of the 2nd International Conference on Knowledge Discovery and Data Mining
(KDD96), p. 386388, 1996.
[96] P. A. Bernstein et D.-M. W. Chiu, Using semi-joins to solve relational queries , Journal of the ACM, vol. 28, p. 2540, January 1981.
[97] Y. Kotidis et N. Roussopoulos, Dynamat: a dynamic view management system for data
warehouses , in ACM SIGMOD Record, vol. 28, p. 371382, ACM, 1999.
[98] Z. Bellahsene et P. Marot, Materializing a set of views: Dynamic strategies and performance evaluation , in Database Engineering and Applications Symposium, 2000 International, p. 424428, IEEE, 2000.
[99] Z. Bellahsene, M. Cart et N. Kadi, A cooperative approach to view selection and
placement in p2p systems , in On the Move to Meaningful Internet Systems: OTM10,
p. 515522, Springer, 2010.
163
Bibliographie
[100] J. Zhou, P.-A. Larson, J. Goldstein et L. Ding, Dynamic materialized views , in Data
Engineering, 2007. ICDE 2007. IEEE 23rd International Conference on, p. 526535,
IEEE, 2007.
[101] I. Mami et Z. Bellahsene, A survey of view selection methods , SIGMOD Record,
vol. 41, no. 1, p. 2029, 2012.
[102] M. de Souza et M. Sampaio, Efficient materialization and use of views in data warehouses , SIGMOD Record, vol. 28, no. 1, p. 7883, 1999.
[103] V. Harinarayan, A. Rajaraman et J. D. Ullman, Implementing data cubes efficiently ,
in ACM SIGMOD Record, vol. 25, p. 205216, ACM, 1996.
[104] E. Baralis, S. Paraboschi et E. Teniente, Materialized views selection in a multidimensional database. , in VLDB, vol. 97, p. 156165, 1997.
[105] K. R. H. Uchiyama et T. Teorey, A progressive view materialization algorithm , in
2nd ACM International Workshop on Data warehousing and OLAP (DOLAP 99), Kansas
City, USA, p. 3641, 1999.
[106] P. D. A. Shukla et J. Naughton, Materialized view selection for multi-cubedata models , in 7 th International Conference on Extending DataBase Technology (EDBT 00),
Konstanz, Germany, p. 269284, 2000.
[107] T. Nadeau et T. Teorey, Achieving scalability in olap materialized view selection ,
in 5th ACM International Workshop on Data Warehousing and OLAP (DOLAP 02),
McLean, USA, p. 2834, 2004.
[108] M. Golfarelli et S. Rizzi, View materialization for nested gpsj queries. , in DMDW,
p. 10, 2000.
[109] D. Theodoratos et W. Xu, Constructing search spaces for materialized view selection ,
in Proceedings of the 7th ACM international workshop on Data warehousing and OLAP
(DOLAP 04), Washington DC, USA, p. 112121, ACM, 2004.
[110] A. Gupta, I. S. Mumick et al., Maintenance of materialized views: Problems, techniques, and applications , IEEE Data Eng. Bull., vol. 18, p. 318, 1995.
[111] X. Y. C. Zhang et J. Yang, An evolutionary approach to materialized view selection in
a data warehouse environment , IEEE Transactions on Systems, Man, and Cybernetics,
vol. 31, no. 3, p. 282294, 2001.
[112] S. V. e. K. K. S.R. Valluri, View relevance driven materialized view selection in data
warehousing environment , in 13th Australasian Database Technologies Conference
(ADC02), Melbourne, Australia, p. 187196, 2002.
[113] X. Baril et Z. Bellahs`ene, Selection of materialized views: a cost-based approach ,
in 15th International Conference on Advanced Information Systems Engineering (CAiSE03), Klagenfurt, Austria, p. 665680, 2003.
164
[114] A. Sanjay, C. Surajit et V. R. Narasayya, Automated selection of materialized views

and indexes in microsoft sql server , Proceedings of the International Conference on
Very Large Databases, p. 496505, September 2000.
[115] J. H. Holland, Adaptation in natural and artificial systems: An introductory analysis
with applications to biology, control, and artificial intelligence. U Michigan Press, 1975.
[116] J. Kratica, I. Ljubic et D. Tosic, A genetic algorithm for the index selection problem , in Applications of Evolutionary Computing, EvoWorkshop 2003: EvoBIO, EvoCOP, EvoIASP, EvoMUSART, EvoROB, and EvoSTIM, Essex, UK, April 14-16, 2003,
Proceedings, p. 280290, 2003.
[117] M. Adiba et B. G. Lindsay, Database snapshots , vldb, p. 8691, October 1980.
[118] B. G. Lindsay, L. M. Haas, C. Mohan, H. Pirahesh et P. F. Wilms, A snapshot differential refresh algorithm , in Proceedings of the 1986 ACM SIGMOD International
Conference on Management of Data, Washington, D.C., May 28-30, 1986., p. 5360,
1986.
[119] S. Ceri et J. Widom, Deriving production rules for incremental view maintenance ,
in Proceedings of 17th International Conference on Very Large Data Bases, Barcelona,
Catalonia, Spain, p. 577589, September 1991.
[120] J. A. Blakeley, P.-A. Larson et F. W. Tompa, Efficiently updating materialized views ,
in ACM SIGMOD Record, vol. 15, p. 6171, ACM, 1986.
[121] A. Segev et J. Park, Maintaining materialized views in distributed databases , in Proceedings of fifth International Conference on Data Engineering, p. 262270, IEEE, 1989.
[122] D. Srivastava, S. Dar, H. Jagadish et A. Y. Levy, Answering queries with aggregation
using views , in Proceedings of the 22th International Conference on Very Large Data
Bases, p. 318329, Morgan Kaufmann Publishers Inc., 1996.
[123] J. Gryz, Query rewriting using views in the presence of functional and inclusion dependencies , Information Systems, vol. 24, p. 597612, 1999.
[124] S. Ceri, M. Negri et G. Pelagatti, Horizontal data partitioning in database design ,
in Proceedings of the ACM SIGMOD international conference on Management of data,
p. 128136, ACM, 1982.
[125] D. DeWitt et J. Gray, Parallel database systems: the future of high performance database systems , Communications of the ACM, p. 8598, 1992.
[126] S. Chakravarthy, J. Muthuraj, R. Varadarajan et S. B. Navathe, An objective function
for vertically partitioning relations in distributed databases and its analysis , in Distributed and Parallel Databases Journal, vol. 2, p. 183207, April 1994.
[127] L. Bellatreche et K. Y. Woameno, Dimension table driven approach to referential partition relational data warehouses , in to appear in ACM Twelfth International Workshop
on Data Warehousing and OLAP (DOLAP09), 2009.
165
Bibliographie
[128] L. Bellatreche, M. Schneider, H. Lorinquer et M. Mohania, Bringing together partitioning, materialized views and indexes to optimize performance of relational data warehouses , in Data Warehousing and Knowledge Discovery, p. 1525, Springer, 2004.
[129] J. Rao, C. Zhang, N. Megiddo et G. Lohman, Automating physical database design in
a parallel database , in Proceedings of the ACM SIGMOD international conference on
Management of data, p. 558569, ACM, 2002.
[130] T. Stohr, H. Martens et E. Rahm, Multi-dimensional database allocation for parallel
data warehouses. , in VLDB, p. 273284, 2000.
[131] L. Bellatreche, Utilisation des vues matrialises, des index et de la fragmentation dans
la conception logique et physique dun entrept de donnes. Thse doctorat, Universit
Blaise Pascal de Clermont Ferrand, dcembre 2000.
[132] M. T. zsu et P. Valduriez, Principles of distributed database systems. Springer, 2011.
[133] D. C. Zilio, J. Rao, S. Lightstone, G. Lohman, A. Storm, C. Garcia-Arellano et S. Fadden, Db2 design advisor: integrated automatic physical database design , in Proceedings of the Thirtieth international conference on Very large data bases-Volume 30,
p. 10871097, VLDB Endowment, 2004.
[134] S. Rozen et D. Shasha, A framework for automating physical database design , in
Proceedings of the 17th International Conference on Very Large Data Bases, p. 401
411, Morgan Kaufmann Publishers Inc., 1991.
[135] S. Finkelstein, M. Schkolnick et P. Tiberio, Physical database design for relational
databases , ACM Transactions on Database Systems, vol. 13, p. 91128, 1988.
[136] B. Dageville, D. Das, K. Dias, K. Yagoub, M. Zait et M. Ziauddin, Automatic sql
tuning in oracle 10g , in Proceedings of the Thirtieth international conference on Very
large data bases-Volume 30, p. 10981109, VLDB Endowment, 2004.
[137] C. Maier, D. Dash, I. Alagiannis, A. Ailamaki et T. Heinis, Parinda: an interactive
physical designer for postgresql , in Proceedings of the 13th International Conference
on Extending Database Technology, p. 701704, ACM, 2010.
[138] P. ONeil et D. Quass, Improved query performance with variant indexes , sigmod,
p. 3849, May 1997.
[139] L. Bellatreche, K. Boukhalfa et M. K. Mohania, Pruning search space of physical
database design , in 18th International Conference On Database and Expert Systems
Applications (DEXA07), p. 479488, 2007.
[140] N. Bruno et S. Chaudhuri, To tune or not to tune?: a lightweight physical design alerter , in Proceedings of the 32nd international conference on Very large data bases,
p. 499510, VLDB Endowment, 2006.
[141] K. Boukhalfa et L. Bellatreche, Combinaison des algorithmes gntique et de recuit
simul pour la conception physique des entrepts de donnes. , in INFORSID, p. 673
686, 2006.
166
[142] R. Castillo et U. Leser, U.: Selecting materialized views for rdf data , in In: Semantic
Web Information Management Workshop (SWIM, Citeseer, 2010.
[143] F. Goasdoue, K. Karanasos, J. Leblay et I. Manolescu, View selection in semantic web
databases , Proc. VLDB Endow., vol. 5, p. 97108, oct. 2011.
[144] I.Horrocks et U.Sattler, Ontology reasoning in the shoq(d) description logic , In
Proc. of the 17th Int. Joint Conf. on Artificial Intelligence, p. 199204, 2001.
[145] I. Horrocks, P. F. Patel-Schneider et F. van Harmelen, From shiq and rdf to owl: the
making of a web ontology language. , J. Web Sem., vol. 1, no. 1, p. 726, 2003.
[146] I.Horrocks et U.Sattler, Decidability of shiq with complex role inclusion axioms. ,
Artificial Intelligence, vol. 160, p. 79104, 2004.
[147] I.Horrocks, U.Sattler et S.Tobies, Practical reasoning for expressive description logics , In Proc. of the 6th Int. Conf. on Logic for Programming and Automated Reasoning
(LPAR99), vol. 1705, p. 161180, 1999.
[148] Z. Wu, G. Eadon, S. Das, E. I. Chong, V. Kolovski, M. Annamalai et J. Srinivasan,
Implementing an inference engine for rdfs/owl constructs and user-defined rules in
oracle , in ICDE2008, p. 12391248, April 2008.
[149] O. L. T. Berners-Lee, J. Handler, The semantic web , Scientific American, May 2001.
[150] IBM, RDF application development for IBM data servers.
IBM, 2012.
http://pic.dhe.ibm.com/infocenter/db2luw/v10r1/index.jsp?topic=%2Fcom.ibm.db2.luw.wn.doc%2Fdoc%2Fc0060011.html.
[151] G. R. Mario Briggs, Priya Ranjan Sahoo et F. Anwar, Resource description framework
application development in db2 10 for linux, unix, and windows , IBM, OCT 2012.
[152] D. Beckett, RDF 1.1 N-Triples.
W3C Recommendation, February 2014.
http://www.w3.org/TR/2014/REC-n-triples-20140225/.
[153] M. Briggs, Db2 nosql graph store what, why & overview , Mar. 2012. IBM :
https://www.ibm.com/developerworks/mydeveloperworks/blogs/nlp/resource/DB2_NoS
QLGraphStore.pdf?lang=en.
[154] G. Gardarin, Bases de donnes, les systmes et leurs langages. Eyrolles, 1994.
[155] M. Klein et N. F. Noy, A component-based framework for ontology evolution , in
Proceedings of the IJCAI, vol. 3, Citeseer, 2003.
[156] L. Bellatreche, A. Giacometti, P. Marcel, H. Mouloudi et D. Laurent, A framework
for combining rule-based and cost-based approaches to optimize olap queries , in 1me
Journe Francophone sur les Entrepts de donnes et lAnalyse en ligne (EDA05), Revue
des Nouvelles Technologies de lInformation, RNTI-B-1, p. 177196, 2005.
[157] L. Bellatreche, K. Boukhalfa et P. Richard, Referential horizontal partitioning selection problem in data warehouses: Hardness study and selection algorithms , International Journal of Data Warehousing and Mining, vol. 5, p. 123, March 2009.
167
Bibliographie
[158] B. Soumia, Le dploiement, une phase part entire dans le cycle de vie des entrepts
de donnes : application aux plateformes parallles. Thse doctorat, ENSMA - Poitiers,
juin 2014.
[159] M. G. Lohman, D. Daniels, L. M. Haas, R. Kistler et P. G. Selinger, Optimization
of nested queries in a distributed relational database , Proceedings of the International
Conference on Very Large Databases, p. 403415, August 1984.
[160] M. T. zsu et P. Valduriez, Principles of Distributed Database Systems. Prentice Hall,
1991.
[161] P. M. G. Apers, Data allocation in distributed database systems , ACM Transactions
on database systems, vol. 13, no. 3, p. 263304, 1988.
[162] L. Bellatreche, K. Karlapalem et Q. Li, Complex methods and class allocation in
distributed object-oriented databases , in the 5th International Conference on Object
Oriented Information Systems (OOIS98), p. 239256, September 1998.
[163] G. Gardarin, J.-R. Gruser et Z.-H. Tang, A cost model for clustered object-oriented
databases , VLDB, p. 323334, 1995.
[164] G. Gardarin, J.-R. Gruser et Z.-H. Tang, A cost-based selection of path expression
processing algorithms in object-oriented databases , vldb, p. 390401, 1996.
[165] E. Bertino et P. Foscoli, An analytical model of object-oriented query costs , Proceedings of the Fifth International Workshop on Persistent Object Systems, San Miniato
(Pisa), p. 241261, September 1992.
[166] E. Bertino, On modeling cost functions for object-oriented databases , IEEE Transactions on Knowledge and Data Engineering, vol. 9, p. 500508, May/June 1997.
[167] I. Tatarinov, S. Viglas, K. S. Beyer, J. Shanmugasundaram, E. J. Shekita et C. Zhang,
Storing and querying ordered xml using a relational database system , in SIGMOD
02: Proceedings of the ACM SIGMOD international conference on Management of data,
(New York, NY, USA), p. 204215, ACM Press, 2002.
[168] D. Florescu et D. Kossmann, A performance evaluation of alternative mapping schemes
for storing XML data in a relational database , rap. tech., NRIA Rocquencourt - RODIN,
1999.
[169] A. Maduko, K. Anyanwu, A. P. Sheth et P. Schliekelman, Estimating the cardinality of
rdf graph patterns , in WWW (C. L. Williamson, M. E. Zurko, P. F. Patel-Schneider et
P. J. Shenoy, ds), p. 12331234, ACM, 2007.
[170] E. P. Shironoshita, M. T. Ryan et M. R. Kabuka, Cardinality estimation for the optimization of queries on ontologies , SIGMOD Record, vol. 36, p. 1318, 2007.
[171] M. Stocker, A. Seaborne, A. Bernstein, C. Kiefer et D. Reynolds, Sparql basic graph
pattern optimization using selectivity estimation , in Proceedings of the 17th international conference on World Wide Web, WWW 08, (New York, NY, USA), p. 595604,
ACM, 2008.
168
[172] G. Neumann, Thomas et Weikum, Rdf-3x: a risc-style engine for rdf , Proc. VLDB
Endow., vol. 1, p. 647659, aot 2008.
[173] Z. Kaoudi, K. Kyzirakos et M. Koubarakis, Sparql query optimization on top of dhts ,
in International Semantic Web Conference (1), p. 418435, 2010.
[174] T. Neumann et G. Moerkotte, Characteristic sets: Accurate cardinality estimation for
rdf queries with multiple joins , in ICDE, p. 984994, 2011.
[175] P. G. Selinger, M. M. Astrahan, D. D. Chamberlin, R. A. Lorie et T. G. Price, Access
path selection in a relational database management system , in Proceedings of the 1979
ACM SIGMOD international conference on Management of data, p. 2334, ACM, 1979.
[176] A. Bernstein, C. Kiefer et M. Stocker, Optarq: A sparql optimization approach based
on triple pattern selectivity estimation , rap. tech., University of Zurich, Department of,
2007.
[177] C. Weiss, P. Karras et A. Bernstein, Hexastore: sextuple indexing for semantic web
data management , Proceedings of the VLDB Endowment, vol. 1, p. 10081019, Aug.
2008.
[178] J. Groppe, S. Groppe, S. Ebers et V. Linnemann, Efficient processing of sparql joins in
memory by dynamically restricting triple patterns , in Proceedings of the 2009 ACM
symposium on Applied Computing, SAC 09, (New York, NY, USA), p. 12311238,
ACM, 2009.
[179] T. M. Connolly et C. E. Begg, Database Systems: A Practical Approach to Design, Implementation and Management (4th Edition). Pearson Addison Wesley, 2004.
[180] M. Jarke et J. Koch, Query optimization in database systems , ACM Comput. Surv.,
vol. 16, p. 111152, 1984.
[181] R. Bellman, Dynamic programming and lagrange multipliers , Proceedings of the
National Academy of Sciences of the United States of America, vol. 42, no. 10, p. 767,
1956.
[182] F. Goasdoue, K. Karanasos, J. Leblay et I. Manolescu, View selection in semantic web
databases , computer science, INRIA, 2011. Rapport de recherche no. 7738.
[183] J. Perez, M. Arenas et C. Gutierrez, Semantics and complexity of sparql , in The
Semantic Web-ISWC 2006, p. 3043, Springer, 2006.
[184] F. Frasincar, G.-J. Houben, R. Vdovjak et P. Barna, Ral: An algebra for querying rdf ,
World Wide Web, vol. 7, p. 83109, mars 2004.
[185] R. Cyganiak, A relational algebra for SPARQL , rap. tech., Digital Media Systems
Laboratory, HP Laboratories Bristol, 2005.
[186] J. Yang, K. Karlapalem et Q. Li, Algorithms for materialized view design in data warehousing environment , in VLDB, p. 136145, 1997.
[187] K. Amira, Linteraction au service de loptimisation grande chelle des entrepts de
donnes relationnels. Thse doctorat, ENSMA - Poitiers, Dcembre 2013.
169
Bibliographie
[188] A. Boukorca, L. Bellatreche et S.-A. B. Senouci, Votre plan dexcution de requtes
est un circuit intgr : Changer de mtier , in EDA, p. 133148, 2013.
[189] A. C. Bloesch et T. A. Halpin, Conquer: a conceptual query language , in Conceptual
Modeling ER96, p. 121133, Springer, 1996.
[190] D. Theodoratos et T. K. Sellis, Designing data warehouses , Data Knowl. Eng.,
vol. 31, p. 279301, 1999.
[191] J. D. Ullman, Principles of Database Systems, 2nd Edition. Computer Science Press,
1982.
[192] E. Wong et K. Youssefi, Decomposition - a strategy for query processing , ACM Trans.
Database Syst., vol. 1, p. 223241, 1976.
[193] S. Chaudhuri et V. R. Narasayya, An efficient cost-driven index selection tool for microsoft sql server , in Proceedings of the 23rd International Conference on Very Large
Data Bases, VLDB 97, (San Francisco, CA, USA), p. 146155, Morgan Kaufmann Publishers Inc., 1997.
[194] J. U. H. Garcia-Molina et J. Wisdom, Database Systems: The Complete Book. Pearson
Education Inc, 2009.
[195] J. Yang, K. Karlapalem et Q. Li, A framework for designing materialized views in data
warehousing environment , in ICDCS, p. 458465, 1997.
[196] P. Toth et S. Martello, Knapsack problems: Algorithms and computer implementations , Discrete Mathematics and Optimization. Wiley, 1990.
[197] L. Troiano, D. De Pasquale et P. Marinaro, Genetic algorithms in java , 2014. URL:
http://jenes.intelligentia.it.
[198] R. Hylock, A comparison of heuristic algorithms to solve the view selection problem ,
Information Systems, p. 27, 2005.
[199] A. Shukla, P. Deshpande, J. F. Naughton et al., Materialized view selection for multidimensional datasets , in VLDB, vol. 98, p. 488499, 1998.
[200] H. Gupta et I. S. Mumick, Selection of views to materialize under a maintenance cost
constraint , in Database Theory-ICDT99, p. 453470, Springer, 1999.
[201] K. Wilkinson et K. Wilkinson, Jena property table implementation , in In SSWS, 2006.
[202] Y. Mengdong et G. Wu, Caching intermediate result of sparql queries , in 20th International World Wide Web Conference (WWW2011), p. 159, March/April 2011.
170
Annexe
Requtes du benchmarch LUBM utilises

Cette annexe prsente les requtes du benchmark LUBM [30] que nous avons utilises pour
les exprimentations.
1. SELECT ?x WHERE {?x rdf:type ub:GraduateStudent.
?x ub:takesCourse http://www.Department0.University0.edu/GraduateCourse0.} ;
2. SELECT ?x ?y ?z WHERE {
?x rdf:type ub:GraduateStudent.
?x ub:undergraduateDegreeFrom ?y. ?x ub:memberOf ?z.
?y rdf:type ub:University. ?z rdf:type ub:Department.
?z ub:subOrganizationOf ?y.}
3. SELECT * WHERE {
?x rdf:type ub:Publication.
?x ub:publicationAuthor http://www.Department0.University0.edu/AssistantProfessor0.}
4. SELECT * WHERE {
?x rdf:type ub:FullProfessor.
?x ub:worksFor http://www.Department0.University0.edu.
?x ub:name ?y1.
?x ub:emailAddress ?y2.
?x ub:telephone ?y3. } ;
5. SELECT ?x WHERE { ?x
rdf:type
ub:Person).}
6. SELECT ?x WHERE { ?x
rdf:type
ub:Student.}
171
Annexe A. Requtes du benchmarch LUBM utilises

7. SELECT ?x WHERE {?x rdf:type ub:UndergraduateStudent>.
?x ub:takesCourse ?y.
?y rdf:type ub:Course.
?z rdf:type ub:AssistantProfessor.
?z ub:teacherOf ?y. } ;
8. SELECT ?x ?y WHERE {
?x rdf:type ub:UndergraduateStudent.
?x ub:memberOf ?z.
?x ub:emailAddress ?email.
?z rdf:type ub:Department.
?z ub:subOrganizationOf http://www.University0.edu.} ;
9. SELECT ?x ?y WHERE {?x rdf:type
?y rdf:type ub:FullProfessor.
?z rdf:type ub:Course.
?x ub:advisor ?y.
?x ub:takesCourse ?z.
?y ub:teacherOf ?z.} ;
10. SELECT ?x WHERE {
?x rdf:type ub:Student. ?x
ub:UndergraduateStudent.
ub:takesCourse
GraduateCourse0. } ;
11. SELECT ?z WHERE {?z rdf:type ub:ResearchGroup.

?z ub:subOrganizationOf http://www.Department0.University0.edu. };
12. SELECT * WHERE { ?x rdf:type ub:AssistantProfessor.
?x ub:worksFor ?z.
?z rdf:type ub:Department.
?z ub:subOrganizationOf http://www.University0.edu.} ;
13. SELECT ?x WHERE {
?x rdf:type ub:Person. ?x
14. SELECT * WHERE {?x
ub:hasAlumnus
rdf:type
http://www.University0.edu. } ;
ub:UndergraduateStudent.};
172
Table des figures
Vue globale de la thse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1
Le modle en oignon pour les ontologies de domaine (extraite de [28] ) . . . .
16
1.2
Exemple dune ontologie OCC . . . . . . . . . . . . . . . . . . . . . . . . . .
17
1.3
Exemple dune ontologie OCNC . . . . . . . . . . . . . . . . . . . . . . . . .
17
1.4
Exemple dun triplet RDF . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
1.5
Base de donnes base ontologique . . . . . . . . . . . . . . . . . . . . . . .
31
1.6
Fragment de lontologie LUBM . . . . . . . . . . . . . . . . . . . . . . . . .
33
1.7
Reprsentation gnrique du fragment dontologie LUBM . . . . . . . . . . .
34
1.8
Reprsentation spcifique du fragment dontologie LUBM . . . . . . . . . . .
34
1.9
Reprsentation verticale des instances du fragment dontologie LUBM . . . . .
36
1.10 Reprsentation verticale avec ID des instances du fragment dontologie LUBM
36
1.11 Reprsentation binaire des instances du fragment dontologie LUBM . . . . . .
38
1.12 Table horizontale unique des instances du fragment dontologie LUBM . . . .
38
1.13 Reprsentation horizontale des instances du fragment dontologie LUBM . . .
39
1.14 Architecture deux quarts . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
1.15 Architecture trois quarts . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
1.16 Mta-schma et ontologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
1.17 Architecture quatre quarts. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
1.18 Reprsentation multidimensionnelle des BDBO. . . . . . . . . . . . . . . . .
43
1.19 Exemple de BDBO dans lespace de BDBO. . . . . . . . . . . . . . . . . . .
44
1.20 Etapes du traitement dune requte OntoQL (extraite de [28]) . . . . . . . . . .
50
173
Table des figures

2.1
Problme de conception physique . . . . . . . . . . . . . . . . . . . . . . . .
55
2.2
Problme de conception physique dans les phases de cycle de vie . . . . . . . .
57
2.3
Rcriture dans le processus doptimisation . . . . . . . . . . . . . . . . . . .
62
2.4
Problme de conception physique . . . . . . . . . . . . . . . . . . . . . . . .
65
2.5
Problme de conception physique dans les BDBO . . . . . . . . . . . . . . .
67
2.6
Notre dmarche. (MC:Modle de cot) . . . . . . . . . . . . . . . . . . . . . .
68
3.1
Architecture OntoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
3.2
Schma de lontologie LUBM. . . . . . . . . . . . . . . . . . . . . . . . . . .
90
3.3
Processus de chargement global dOracle. . . . . . . . . . . . . . . . . . . . .
91
3.4
Temps de chargement des donnes. . . . . . . . . . . . . . . . . . . . . . . . .
95
3.5
Temps dexcution de requtes LUBM de 1-7. . . . . . . . . . . . . . . . . . .
97
3.6
Temps dexcution de requtes LUBM de 8-14. . . . . . . . . . . . . . . . . .
97
4.1
Exemple de schma dune ontologie. . . . . . . . . . . . . . . . . . . . . . . . 111
4.2
Cots de requtes fournis par le modle de cot. . . . . . . . . . . . . . . . . . 115
5.1
Arbre de requte pour une BDBO Verticale . . . . . . . . . . . . . . . . . . . 123
5.2
Arbre de requte pour une BDBO binaire . . . . . . . . . . . . . . . . . . . . 123
5.3
Arbre de requte pour tout type BDBO . . . . . . . . . . . . . . . . . . . . . 123
5.4
Un plan unifi des requtes SPARQL . . . . . . . . . . . . . . . . . . . . . . . 124
5.5
Plan unifi des requtes avec les nuds de slection. . . . . . . . . . . . . . . 125
5.6
t1 et t2 sur un seul domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.7
t1 et t2 sur deux domaines
5.8
Les tapes de mise en oeuvre de lapproche conceptuelle . . . . . . . . . . . . 130
5.9
Multi-graphe de requtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.10 Rsult de Join Cut sur V1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

5.11 Plan unifi des requtes de lexemple 7. . . . . . . . . . . . . . . . . . . . . . 134
5.12 Notre dmarche de rsolution base dun algorithme gntique . . . . . . . . . 138
5.13 Les tapes de mise en oeuvre de lapproche simule . . . . . . . . . . . . . . . 140
5.14 Temps de traitement de requtes sur LUBM10 sur la BDBO verticale . . . . . 141
5.15 Temps de traitement de requtes sur LUBM100 sur la BDBO verticale . . . . . 141
5.16 Temps de traitement de requtes sur LUBM10 sur la BDBO Binaire . . . . . . 142
174
5.17 Temps de traitement de requtes sur LUBM100 sur la BDBO Binaire . . . . . 142
5.18 Temps de traitement de requtes sur LUBM10 sur la BDBO horizontale . . . . 142
5.19 Temps de traitement de requtes sur LUBM100 sur la BDBO horizontale . . . 143
5.20 Temps de traitement de requtes sur LUBM10 sur la BDBO native . . . . . . . 144
5.21 Temps de traitement de requtes sur LUBM100 sur la BDBO native . . . . . . 145
5.22 Temps total de traitement de la charge de requtes sur les BDBO
. . . . . . . 145
5.23 Temps total de traitement de la charge de requtes sur la BDBO native
. . . . 146
5.24 Influence de la contrainte de stockage sur la slection. . . . . . . . . . . . . . . 147
175
Liste des tableaux
1.1
Constructeurs de la couche canonique des formalismes RDFS, OWL et PLIB. .
28
1.2
Descripteurs de la couche linguistique des formalismes RDFS, OWL et PLIB. .
29
1.3
Constructeurs de la couche non canonique des formalismes RDFS, OWL et PLIB. 29
1.4
Classification des BDBO selon leur architecture . . . . . . . . . . . . . . . . .
3.1
Constructeurs de la description logique. A, B et P sont des noms de concepts et

oi et C1 des noms dinstances . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
tableau comparatif des BDBO tudies (vertic : verticale, horiz: horizontale,

specif : spcifique) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
3.3
Ensembles de donnes gnres. . . . . . . . . . . . . . . . . . . . . . . . . .
90
3.4
Rcapitulatif des temps de chargement (sec). . . . . . . . . . . . . . . . . . . .
94
4.1
Les paramtres du modle de cot. . . . . . . . . . . . . . . . . . . . . . . . . 106
4.2
Cots de jointures. (dom(p) : domaine de p) . . . . . . . . . . . . . . . . . . . 113
4.3
Statistiques des instances ontologiques utilises pour lapplication du modle

de cot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.4
Cots en termes dE/S selon le modle de cot. (A.V: Approche verticale) . . . 115
5.1
Ensembles de donnes gnres. . . . . . . . . . . . . . . . . . . . . . . . . . 140
5.2
Comparaison des approches de PSVM. . . . . . . . . . . . . . . . . . . . . . . 148
3.2
177
44
Glossaire
API : Application Programming Interface

BD : Base de donnes
BDR : Base de donnes relationnelle
BDBO : Base de donnes base ontologique
BDT : Base de donnes traditionnelle
BDO : Base de donnes objet
BDS : Base de donnes Smantique
CC : Classe canonique
CNC : Classe non canonique
ISAE : Institut Suprieur de lAronautique et de lEspace
LIAS : Laboratoire dInformatique, dApplication et de Systmes
LISI : Laboratoire dInformatique Scientifique et Industrielle
LO : Ontologie Locale
OC : Ontologie Conceptuelle
OCC : Ontologie Conceptuelle Canonique
OCNC : Ontologie Conceptuelle Non Canonique
OL : Ontologie Linguistique
OWL : Web Ontology Language
PLIB : Parts Library - Norme ISO 13584
RDF : Ressource Description Framework
RDFS : Ressource Description Framework Schema
SDB : SPARQL DataBase
SQL : Structured Query Language
SPARQL : Simple Protocol And RDF Query Language
TDB : Tuple DataBase
UML : Unified Modeling Language
URI : Uniform Resource Identifier
URL : Uniform Resource Locator
W3C : World Wide Web Consortium
179
Rsum
La forte volumtrie des donnes dcrites par des ontologies a conduit la naissance des
bases de donnes base ontologique (BDBO). Les communauts industrielles et acadmiques
se sont intresses de prs cette technologie, o plusieurs solutions ont t proposes pour
reprsenter, stocker les donnes smantiques au sein des SGBD et manipuler ses donnes via
des langages de requtes comme SPARQL et OntoQL.
Paralllement, la conception physique est devenue une tape primordiale dans le cycle de vie
de conception des bases de donnes avances. Durant cette phase, des structures doptimisation
de requtes slectionnes. Si de nombreux travaux ont t mens sur la conception physique
dans le contexte des bases de donnes traditionnelles, peu se sont intresss la conception
physique dans les BDBO. Aprs une analyse approfondie des principales BDBO existantes,
nous affirmons que leur conception physique est plus complexe. Cela est d leur diversit qui
porte sur : (1) des formalismes supports : chaque BDBO utilise un formalisme particulier pour
dfinir ses ontologies (OWL, PLIB ou FLIGHT) ; (2) des modles de stockage : une varit de
modles de stockage (reprsentation horizontale, spcifique, verticale, etc.) sont utiliss pour les
BDS et (3) des architectures des SGBD cibles supportant ces bases. Trois types darchitecture
existent : (a) architecture "deux quarts" qui est celle des BD traditionnelles, o les ontologies et
les donnes sont stockes ensemble. (b) Le second type darchitecture qualifi de "trois quarts"
spare les ontologies des instances ontologiques; (c) la dernire architecture dite "quatre quarts"
ajoute la prcdente une partie appele mta-schma.
Notons que le modle de cot est la composante principale de la phase de conception physique. Il permet de guider la slection des structures doptimisation et quantifier sa qualit.
Pour cette raison, nous avons dvelopp des modles de cots mathmatiques pour estimer
le cot de chargement des donnes et le temps de rponse des requtes en termes de nombre
dEntres-Sorties entre le disque et la mmoire pour chaque type de BDBO. Les rsultats thoriques sont confronts avec les rsultats pratiques obtenus partir de six BDBO dont trois
industrielles (Oracle et IBM SOR, DB2RDF) et trois acadmiques (Jena, Sesame et OntoDB,
dvelopp au laboratoire LIAS de lISAE-ENSMA). Ces modles de cots ont t utiliss dans
le processus de slection des vues matrialises, des structures doptimisation populaires dans
le contexte des bases de donnes. Nous avons propos deux approches de matrialisation : une
approche conceptuelle et une approche physique. Dans la premire approche, la slection des
vues matrialises est faite sur les classes et les proprits utilises par les requtes dinterrogation (SPARQL). Dans lapproche physique, la slection prend en compte larchitecture et les
modles de stockage du SGBD cible. Des exprimentations ont t conduites pour valuer la
qualit de nos approches en les confrontant avec les principaux travaux existants.
181
Conception physique de bases de donnes base ontologique : le cas des

Vues Matrialises
Prsente par :
Directeurs de Thse :
Ladjel Bellatreche et Stphane Jean
Rsum
La forte volumtrie des donnes dcrites par des ontologies a conduit la naissance des bases
de donnes base ontologique (BDBO). Plusieurs communauts se sont intresses cette technologie
et ont propos des solutions pour persister les donnes smantiques dans des SGBD.
Paralllement, la conception physique est devenue une tape primordiale dans le cycle de vie
de conception des bases de donnes (BD). Durant cette phase, des structures doptimisation sont
slectionnes. Si de nombreux travaux ont t mens sur la conception physique dans le contexte des
BD traditionnelles, peu se sont intresss la conception physique dans les BDBO qui est plus
complexe. Cette complexit est due la diversit des BDBO qui porte sur des formalismes supports,
des modles de stockage et des architectures utiliss.
Pour guider la slection des structures doptimisation et mesurer sa qualit, nous avons
dvelopp un modle de cot pour estimer le cot des requtes dans les BDBO. Les rsultats
thoriques sont confronts avec les rsultats pratiques obtenus partir de six BDBO dont trois
industrielles (Oracle et IBM SOR, DB2RDF) et trois acadmiques (Jena, Sesame et OntoDB du LIAS
de l'ISAE-ENSMA). Ce modle de cot a t utilis dans le processus de slection des vues
matrialises. Nous avons propos deux approches de matrialisation : une approche conceptuelle o
la slection des vues matrialises est faite sur les classes et les proprits utilises par les requtes et
une approche simule o la slection prend en compte la diversit des BDBO. Des exprimentations
ont t conduites pour valuer la qualit de nos approches en les confrontant avec les principaux
travaux existants.
Mots-cls : Ontologies (informatique), Bases de donnes--Conception, Bases de donnes-Interrogation, ArchitectureInformatique, Diversit des bases de donnes base ontologique,
Optimisation des requtes, Conception physique, Vues matrialises
Abstract
The high volume of data described by ontologies led to the creation of Ontology-Based
Database (OBDB). Many communities are interested in this technology and have proposed solutions
to persist semantic data in DBMS.
Meanwhile, the physical design has become an essential step in the life cycle of database
design, in which optimization structures are selected. While many studies have been conducted on the
physical design in the context of traditional databases, few have focused on the physical design in
OBDB which is more complex. This complexity is due to the diversity of OBDB which focuses on
formalisms supported, storage models and architectures used.
To guide the selection of optimization structures, we have developed a cost model to estimate
the cost of queries in OBDB. The theoretical results are compared with the practical results obtained
from six OBDB including three industrial (Oracle, IBM SOR and DB2RDF) and three academic (Jena,
Sesame and OntoDB of the LIAS Lab of ISAE-ENSMA). This cost model was used in the
materialized views selection process. We proposed two approaches of materialized views selection: a
conceptual approach where the selection of materialized views is made on the classes and properties
used by queries and a simulated approach where the selection takes into account the diversity of
OBDB. Experiments were conducted to evaluate the quality of our approaches and compare them with
the main existing work.
Mots-cls : Ontologies (Information retrieval), Database design, Querying (Computer science),
Architecture--Data processing, Ontology-based database diversity, Query optimisation, Physical
design, Materialized views.

Onto

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Onto

Transféré par

Droits d'auteur :

Formats disponibles

Conception physique des bases de donn

To cite this version:

HAL Id: tel-01129077

HAL is a multi-disciplinary open access

Larchive ouverte pluridisciplinaire HAL, est

Ecole Nationale Suprieure de Mcanique et dArotechnique

DOCTEUR DE L'COLE NATIONALE SUPRIEURE

Ecole Doctorale : Sciences et Ingnierie pour lInformation, Mathmatiques

MBAIOSSOUM BERY LEOURO

Professeur, Universit Montpellier II

Ladjel BELLATRECHE Professeur, ISAE-ENSMA, Poitiers

Matre de Confrences, Universit de Poitiers

Ecole Nationale Suprieure de Mcanique et dArotechnique

DOCTEUR DE L'COLE NATIONALE SUPRIEURE

Ecole Doctorale : Sciences et Ingnierie pour lInformation, Mathmatiques

MBAIOSSOUM BERY LEOURO

Professeur, Universit Montpellier II

Ladjel BELLATRECHE Professeur, ISAE-ENSMA, Poitiers

Matre de Confrences, Universit de Poitiers

Table des matires

Partie I Concepts fondamentaux

Chapitre 1 Ontologie et Bases de Donnes Base Ontologique

Quest-ce quune ontologie? . . . . . . . . . . . . . . . . . . . . . . . . .

Origine de la notion dontologie . . . . . . . . . . . . . . . . . . .

Notion dontologie en informatique . . . . . . . . . . . . . . . . .

Dfinition dune ontologie . . . . . . . . . . . . . . . . . . . . . .

Table des matires

Taxonomie des ontologies de domaine . . . . . . . . . . . . . . .

Comment dfinir formellement une ontologie? . . . . . . . . . . . . . . .

Ontologies vs. Modles Conceptuels . . . . . . . . . . . . . . . . . . . . .

Base de Donnes Base Ontologique . . . . . . . . . . . . . . . . . . . .

Modle de stockage traditionnel ou autres modles pour les BDBO? 32

Architecture traditionnelle ou dautres architectures pour le SGBD

Langage de requtes des BDBO

Principaux langages proposs . . . . . . . . . . . . . . . . . . . .

Prsentation du langage SPARQL . . . . . . . . . . . . . . . . . .

Prsentation du langage OntoQL . . . . . . . . . . . . . . . . . .

Chapitre 2 Conception Physique de Bases de Donnes

Quelques exemples de structures doptimisation . . . . . . . . . . . . . . .

Les vues matrialises . . . . . . . . . . . . . . . . . . . . . . . .

Choix structures doptimisation . . . . . . . . . . . . . . . . . . .

Choix de la mthode de slection . . . . . . . . . . . . . . . . . .

Choix dalgorithme de slection . . . . . . . . . . . . . . . . . . .

Mise en uvre des solutions doptimisation . . . . . . . . . . . . .

Vers une conception physique des BDBO . . . . . . . . . . . . . . . . . .

Chapitre 3 Etude Empirique des Bases de Donnes Base Ontologique

Les composantes dune BDBO . . . . . . . . . . . . . . . . . . . . . . .

Formalisation dune ontologie . . . . . . . . . . . . . . . . . . . .

Modle unifi des BDBO . . . . . . . . . . . . . . . . . . . . . .

Etude des BDBO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Prsentation des BDBO . . . . . . . . . . . . . . . . . . . . . . .

Critres de comparaison des BDBO . . . . . . . . . . . . . . . . .

Etude de performances des BDBO . . . . . . . . . . . . . . . . . . . . .

Ensembles de donnes et environnement de tests . . . . . . . . . .

Performances en termes de chargement des donnes (ontologie et

Performances en termes de temps de rponse de requtes . . . . . .

Paramtres influant identifis partir de cette tude . . . . . . . . . . . . .

Table des matires

Revue des modles de cot dans le contexte des BDBO . . . . . . . . . . 103

Les paramtres de notre modle de cot . . . . . . . . . . . . . . . . . . . 104

Paramtres de la fonction du cot . . . . . . . . . . . . . . . . . . 105

Template de requtes . . . . . . . . . . . . . . . . . . . . . . . . . 106

Estimation des facteurs de slectivit . . . . . . . . . . . . . . . . 107

Cot dune slection et dune projection . . . . . . . . . . . . . . . 110