Pour valider notre fonction de coût, nous avons considéré les requêtes de différents types. Nous présentons ici un résultat portant sur trois requêtes du benchmark LUBM [30] (requêtes 2, 4 et 6) représentant les types de requêtes présentés. La requête 2 est une requête de jointure,
Algorithme Nested loop sans index
jointure retardée jointure à la BDR [154, 179]
Approche verticale join(T,T), T est la table de triplets
2∗ |T| + 2|t1| + |t2| ∗ (1 +
|t1|/M) |T| + |T| ∗ |T|/M
Approche binaire
join(Tp1,Tp2), Tpi Table
de propriété pi
|T p1| + |T p1|/M ∗ |T p2|
Approche horizontale
join(Tcp1,Tcp2), Tcpi
tables des classes
P
T cp∈dom(p)(|Tcp1| + |Tcp1|/M ∗ |Tcp2|)
Algorithme Nested loop
avec index
jointure retardée jointure à la BDR
Approche verticale join(T,T), T est la table de triplets
|T|(sel(t1) + sel(t2)) +
P(I1)+P(I2)+|t1|+|t1|∗ |t2|/M, sel(t) est la
sé-lectivité des triplets
|T| +|T|*|T|/M
Approche binaire
join(Tp1,Tp2), Tpi Table
de propriété pi
|T p1|+||T p1||∗(P(I)+||T p2||∗
sel), P(I) coût de parcours
d’index I et sel la sélectivité de la valeur de recherche dans Tp2
Approche horizontale
join(Tcp1,Tcp2), Tcpi
tables des classes
P
T cp∈dom(p)(||Tcp1|+||Tcp1||∗
(P(I) +||Tcp2|| ∗ sel))
Algorithme Nested loop
sans index
jointure retardée jointure à la BDR
Approche verticale join(T,T), T est la table de triplets
2∗ |T| + 4 ∗ (|t1| + |t2|) 6∗ |T|
Approche binaire
join(Tp1,Tp2), Tpi Table
de propriété pi
3∗ (|T p1| + |T p2|)
Approche horizontale
join(Tcp1,Tcp2), Tcpi
tables des classes
P
T cp∈dom(p)3(|Tcp1| + |Tcp2|)
la requête 4 est une requête sélection pluri-triplets et la requête 6 est un exemple de requêtes de sélection mono-triplet. Ces requêtes sont traduites en SQL dans les différentes approches et une évaluation de leur coût est faite. Les statistiques utilisées sont présentées 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, propriété et objet) de 200 octets chacune et la mémoire centrale de 50.000 pages. Chaque requête est considérée sur les différentes approches. Les coûts calculés de ces requêtes sont consignés dans le tableau 4.4.
Concepts Cardinalité || triplets|| 100838 ||University|| 979 ||GraduateStudent|| 1874 ||underGraduateStudent|| 5916 ||Student || 0 ||Department|| 15 || memberOf|| 7790 ||subject (distincts) || 17270 ||property (distincts) || 31 ||objects (distincts) || 14072 ||type|| 18213 ||undergraduateDegreeFrom|| 2414 ||subOrganizationOf|| 239 ||Professor|| 0 ||AssociateProfessor|| 176 ||AssistantProfessor|| 146 ||Chair|| 0 ||VisitingProfessor|| 0 ||FullProfessor|| 125 ||Dean|| 0 ||name|| 15972 ||worksFor|| 540 || emailAddress|| 8330 ||telephone|| 8330
Table 4.3 – Statistiques des instances ontologiques utilisées pour l’application du modèle de coût.
Comme attendu, les résultats montrent que l’exécution d’une requête d’auto-jointure de la table de triplets avec une jointure à la BDR nécessite plus d’entrées-sorties que son exécution effectuant d’abord les sélections suivant les motifs de triplets suivies de jointures (jointure
Requêtes Type de re-quête A.V jointure retardée A.V jointure à la BDR Approche binaire Approche horizon-tale Requête 6 Lubm Sélection Nomo-triplet 9168 9168 1138 10289 Requête 4 Lubm Sélection pluri-triplets 21308 137520 60864 121 Requête 2 Lubm Jointure (hash join) 23188 1 65024 195246 18813
Table 4.4 – Coûts en termes d’E/S selon le modèle de coût. (A.V: Approche verticale)
Figure 4.2 – Coûts de requêtes fournis par le modèle de coût.
Nous observons sur la figure 4.2 que pour une sélection mono-triplet, l’approche binaire réalise moins d’E/S et donc est susceptible d’être plus efficace que les autres approches. Dans notre domaine d’application, l’ingénierie, de telles requêtes sont rares. Dans d’autres types de requêtes (jointure et sélections pluri-triplets), l’approche horizontale se montre meilleure suivie de l’approche verticale. Cela confirme partiellement nos résultats expérimentaux (chapitre 3, section 4). Ces résultats sont confirmés par OntoDB qui représente l’approche horizontale et donne de bons temps de réponse, suivie de Oracle ayant une approche verticale et de Sesame utilisant une approche binaire. Par contre, pour certains systèmes expérimentés comme Jena, SOR et DB2RDF, les résultats des évaluations ne confirment pas très clairement ces résultats théoriques. Nous croyons que cela est dû à la procédure de jointure qui peut être différente de celle appliquée dans notre modèle de coût. Les techniques d’optimisation intégrées dans
certainesBDBO notamment les vues matérialisées peuvent en être une raison à ces différences
5 Conclusion
Nous nous sommes intéressés dans ce chapitre aux modèles de coût dans les bases de don-nées à base ontologique. Un modèle de coût permet d’estimer le coût d’exécution d’une requête sur une base de données. C’est un composant très utile pour un optimiseur de requêtes qui est un maillon très important pour tout SGBD [180]. Il permet à ce dernier d’évaluer les diffé-rents plans d’exécution d’une requête et de choisir le plan de moindre coût. En effet, un SGBD peut évaluer une requête de plusieurs manières (plans d’exécution). Chaque plan d’exécution est constitué d’une suite d’opérations à exécuter sur les tables et sur les résultats intermédiaires pour répondre à la requête. L’optimiseur de requêtes se charge de choisir parmi les plans d’exé-cution possibles d’une requête, celui dont le coût est le moindre. Le coût de l’exéd’exé-cution des différents plans d’exécution d’une requête peut considérablement varier. Ainsi, il est très im-portant d’avoir un optimiseur de requêtes efficace qui peut identifier le plan optimal - ou le plan proche de l’optimal - et éviter les plans réellement mauvais. Ceci n’est pas une tâche tri-viale parce que le coût d’un plan peut varier en fonction de facteurs tels que la distribution de données sous-jacente, l’organisation physique des données sur le disque, la taille du buffer (tampon), l’ordre de tri des données, etc. Le meilleur plan pour un cas peut être un mauvais plan pour un autre cas. Pour choisir le meilleur plan pour une requête, un optimiseur de requête énumère un certain nombre de plans candidats selon une stratégie d’exploration de l’espace des plans, en utilisant des techniques algorithmiques telles que la programmation dynamique [181]. La qualité du plan choisi dépend clairement de la précision du modèle de coût. Un modèle de coût inexact peut entraîner le choix d’un mauvais plan pour une requête car l’optimiseur peut incorrectement estimer le coût de ce plan. Estimer le coût des opérateurs d’une requête néces-site une estimation de la sélectivité de ces opérateurs. Pour estimer une sélectivité, il faut la connaissance de la taille des résultats et des tailles des entrées. La taille de la sortie d’un opé-rateur est déterminée par sa propre sélectivité tandis que les tailles des entrées d’un opéopé-rateur sont déterminées par les sélectivités des opérateurs situés en dessous de l’opérateur dans le plan d’exécution de la requête.
Nous avons proposé un modèle de coût pour lesBDBO en prenant en considération la
diver-sité montrée au chapitre 1. Ce modèle de coût est donc fonction de l’architecture et du modèle de stockage utilisé. Pour les architectures de type II et type III, nous notons une augmentation dans le modèle de coût par rapport à l’architecture de type I dont le modèle de coût est identique à celui de bases de données relationnelles.
Une mise en application de ce modèle de coût nous a permis de voir qu’il ne se dégage
pas un type de BDBO qui est efficace dans le traitement de tous les types de requêtes. Cela
confirme le constat fait au chapitre 3, sur l’étude des performances des BDBO en termes de
temps d’exécution des requêtes.
L’intérêt de notre modèle de coût est de donner au concepteur et à l’administrateur la
une charge de requêtes usuelles.
Aussi notre modèle de coût sera-t-il exploité dans des problèmes de conception physique de
BDBO pour le choix de structures d’optimisation. Le prochain chapitre propose des approches
de définition et de sélection de vues matérialisées dans deBDBO. Notre modèle de coût aura