Identification des vues candidates

Bien que notre travail porte sur le problème de sélection des vues matérialisées, il entre

aussi dans le cadre de l’optimisation multi-requêtes²⁴( Multi-Query Optimisiation - MQO). En

effet, les deux problèmes sont liés, surtout quand on utilise une approche consistant à réutiliser certains résultats intermédiaires. Cette partie traite de la construction de l’espace de vues maté-rialisées suivant une approche qui consiste à réutiliser certains résultats intermédiaires comme dans le cadre de l’optimisation multi-requêtes. Pour créer notre graphe unifié des requêtes, nous nous focalisons sur le partage des nœuds entre les requêtes. Cette démarche favorise la réutili-sation des résultats intermédiaires et permet d’optimiser toute la charge de requêtes. Pour une requête donnée, il existe plusieurs plans d’exécution possibles. Cela est dû aux propriétés des opérations algébriques (appelées règles de transformation des arbres [191, 194]). Selon l’ordre donné aux opérations (sélection, jointure, projection) et aux opérandes, on obtient plusieurs plans. Le résultat d’une requête reste le même quel que soit le plan utilisé mais le coût d’une requête peut varier d’un plan à un autre. Le plan optimal d’une requête est celui dont le coût est minimal. Avant de construire notre graphe unifié, nous commençons d’abord par optimi-ser chaque requête individuellement. Optimioptimi-ser une requête SPARQL revient à ordonner ses patrons de triplet. Plusieurs techniques sont proposées pour cette tâche [171, 173]. Dans notre travail, nous avons utilisé la sélectivité des patrons de triplet [171, 173]. Les triplets sont ordon-nés suivant leurs sélectivités croissantes. Il est aussi intéressant d’ordonner les requêtes suivant un autre critère jugé pertinent (leurs coûts ou fréquences, ou leur nombre de patrons de triplet). Mais on doit garder à l’esprit que la construction des nœuds dépend de l’ordre d’arrivée des re-quêtes et des patrons de triplet. La construction du graphe unifié passe par les étapes suivantes : – extraction des patrons de triplet : pour chaque requête de la charge de requêtes, on ex-trait tous les patrons de triplet qu’on garde dans un ensemble. Chaque triplet n’est stocké qu’une seule fois. Vu que les variables peuvent avoir des noms différents alors qu’elles

font référence aux mêmes triplets, on harmonise les variables sur toute la charge de re-quêtes. Par exemple, (?x undergraduateFrom ?u) et (?p undergraduateFrom ?z) sont deux patrons de triplet référençant le même ensemble de triplets; on doit identifier que la va-riable ?x correspond à la vava-riable ?p et la vava-riable ?u à ?z.

– extraction des nœuds de sélection : cette opération est la première opération sur les

don-nées. Elle représente l’exécution des patrons de triplet sur une BDBO. Les nœuds

cor-respondants sont en fait l’ensemble de triplets répondant à chacun des patrons de triplet. – extraction de nœuds de jointure : pour chaque requête, nous dégageons les différents

nœuds de jointure. Nous rappelons qu’une jointure est une conjonction des deux patrons de triplet partageant au moins une variable. Ces nœuds sont créés sur les nœuds de sé-lection des patrons de triplet impliqués. Nous avons opté pour les arbres de type left-join pour la première requête.

– définition des nœuds de projection que nous considérons comme des résultats de requêtes. Notre approche de construction du graphe unifié suit celle qui a été proposée et expérimentée dans notre laboratoire [188]. Contrairement à cette dernière, nous ne considérons pas plusieurs liens entre deux nœuds donc nous n’utilisons pas un hypergraphe. Nous obtenons un simple graphe qui est notre plan unifié. Par exemple pour notre charge de requêtes de l’exemple 7, nous obtenons des graphes unifiés dont un exemple est donné sur la figure 5.11. Il est question

(?x rdf : type University)

(?x name ?uname) (?y workFor ?x) (?y rdf:type Professor)

q₁ q₂

σ

(?x name ?uname) σ

(?x rdf:type University) σ

(?y WorkFor ?x) σ

(?y rdf:type Professor)

Figure 5.11 – Plan unifié des requêtes de l’exemple 7.

de savoir si ce graphe est optimal. Etant donné que notre graphe unifié est dépendant de l’ordre des requêtes, on ordonne les requêtes suivant un critère donné (leurs fréquences, leur coût, leur sélectivité minimale ou une combinaison donnée) et on crée les graphes unifiés en faisant une permutation circulaire jusqu’à ce que la première requête de la liste revienne en tête de liste. Le graphe retenu est celui qui a un coût minimum. Cette alternative ressemble à la méthode

nombre de calculs. En effet, pour une charge de N requêtes, il faut créer et comparer N graphes unifiés possibles.

5.1.1 Annotation des candidats par des fonctions coût

Une fois le plan unifié obtenu, nous procédons au processus d’annotation des nœuds par des fonctions coût représentant le coût de construction et le coût d’accès.

5.1.1.1 coût de construction. Le coût de construction d’un nœud est le coût algorithmique du nœud tel que défini au chapitre 4. Ce coût est considéré aussi comme le coût de mise à jour du nœud ou encore le coût de maintenance (on suppose que les mises à jour sont complètes et faites de manière périodique, c’est-à-dire par récréation des nœuds). On note C_cout(v), le coût de construction du nœud v.

5.1.1.2 coût d’accès. Le coût d’accès d’un nœud est défini comme étant la taille du nœud. Par simplification, on le définit comme étant le nombre de tuples du nœud. On le note A_cout(v), pour un nœud v. Le calcul de ce coût dépend du type de nœud (nœud de sélection ou nœud de jointure)

Pour un nœud de sélection.

A_cout =

  

sel(T P)∗ nbrTuple(TT) si la BDBO est verticale avec TT la table des triplets

nbrT uple(T abProp(T P)) si laBDBO est binaire

sel(T P)∗ nbrTuple(TabClasse(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 propriété et la table de classe relatives au patron de triplet TP, sel(TP) est la sélectivité

du patron de triplet TP si on a uneBDBO verticale et la sélectivité du prédicat correspondant à

la traduction du patron de triplet TP en langage SQL, si on a uneBDBO binaire et horizontale.

Pour un nœud de jointure.

A_cout = jsel∗ nbrtuple(T P1) ∗ nbrTuple(T P2) (5)

où nbrTuple(TP1) et nbrTuple(TP2) représente le nombre de tuples dans chaque relation corres-pondant aux résultats des traitements des patrons de triplet TP1 et TP2, jsel est leur sélectivité de jointure.

5.1.1.3 coût de requête. Le coût de requête est fonction des vues matérialisées. Si aucune vue n’est utilisée, le coût de la requête est le coût de l’algorithme utilisé pour calculer la requête. L’algorithme suivant permet de calculer le coût des requêtes en présence d’un ensemble de vues matérialisée (on utilise une jointure par hachage).

Algorithm 5 A_cout