• Aucun résultat trouvé

5 Approche simulée

Algorithm 5 A_cout 1: Entrée : q : requête

2: M : ensemble de vues matérialisées

3: Sortie : cout : coût de la requête q 4: Début

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 (dernièreSelection 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 Coût total de la charge. Le coût total de la charge de requêtes est la somme de coût de chaque requête multiplié par la fréquence de la requête.

cout_total = X

q∈Q

f req(q)∗ cout(q, M) (6)

où freq(q) est la fréquence de la requête q et M l’ensemble de vues sélectionnées.

5.1.2 Algorithmes de sélection

Etant donné que chaque nœud est une vue potentielle et que nous disposons des caractéris-tiques de chaque nœud, il est question de sélectionner les vues qui minimisent le coût total de la charge des requêtes et qui respectent la contrainte de stockage.

Si la contrainte de stockage n’existait pas, l’algorithme de sélection 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 problème de sélection est un problème de sac à dos [196], nous avons utilisé un algorithme glouton et un algorithme génétique pour la sélection de vues.

5.1.2.1 Algorithme génétique. Les algorithmes génétiques [115] sont inspirés de l’évolu-tion des espèces naturelles. Ils reproduisent le modèle d’évolul’évolu-tion en vue de trouver une solu-tion optimale à un problème. Ils visent à faire évoluer une populasolu-tion en vue d’améliorer ses individus. Ils considèrent une population et non un individu. Ainsi, ils donnent un ensemble de solution et non une solution. Ces solutions peuvent être différentes mais de qualité équivalente. Notre algorithme utilise la bibliothèque JeneGA développée en Java dédiée aux algorithmes génétiques et disponible sur sourceforge.net/projects/jenes/ [197]. La particularité de cette dernière est qu’on lui donne le codage représentant un individu d’une population, la fonc-tion fitness pour évaluer la qualité de l’individu, les critères de croisement et de mutafonc-tion, et comme résultat, elle génère la solution demandée. La figure 5.12 illustre notre démarche (à base d’un algorithme génétique) de résolution de notre problème de sélection de vues matérialisées. Nous considérons pour chaque vue, l’espace qu’elle occupe et le profit qu’on obtient si elle est la vue seule qui est matérialisée. L’espace occupé est égal au coût d’accès comme évoqué ci-dessus (5.1.1.2). Le profit d’une vue v est défini comme la différence entre le coût total de la charge sans vue et le coût total de la charge si la vue v est matérialisée.

pro f it(v) =X

q∈Q

f req(q)∗ cout(q, ∅) −X

q∈Q

f req(q)∗ cout(q, M) (7)

où freq(q) est la fréquence de la requête q et M={v}.

Le problème revient à trouver un ensemble de vues dont la somme des espaces occupés soit inférieure ou égale à la contrainte de stockage S et qui maximisent les profits. Nous définissons notre chromosome comme un tableau de bits (0 ou 1) (Figure 5.12). Tous les nœuds inter-médiaires de notre plan unifié de requêtes sont mappés dans le tableau de bits. Si le bit à une position est à 1, cela veut dire que le nœud correspondant est sélectionné pour la matérialisation. Une solution initiale est générée de manière aléatoire. Celle-ci sera améliorée pour devenir une bonne solution. Notre fonction fitness est basée sur le maximum de profit de chromosome. En effet, pour chaque chromosome (solution), la somme des bénéfices de ses nœuds et la somme des espaces occupés par ses nœuds sont calculées. Si la somme des espaces occupées est infé-rieure à la contrainte de stockage, le chromosome est déclaré valide et peut être amélioré pour devenir une solution, sinon le chromosome est non intéressant et abandonné. Nous avons fait usage des paramètres suivants souvent utilisés dans les algorithmes génétiques pour la sélec-tion des vues [198] : probabilité de croisement (crossover) : 0.8, probabilité de mutasélec-tion : 0.02, taille de la population : 1000 et le nombre maximum de génération : 200. Cet algorithme nous fournit des solutions assez intéressantes au regard des résultats de nos expérimentations.

Hy-t1 t2 ?@ t3 t4 ?A ?@ t1 t2 ?@ t3 t4 ?A ?@ t1 t2 ?@ t3 t4 ?A ?@ 1 …. 1 0 1 Notre codage JeneGA

Construction d’un plan unifié

Charge de Requêtes {QB, …, QC}

1: si le nœud est sélectionné 0 : sinon

Taux de Mutation & Taux de Croisement

Fonction fitness Un ensemble de vues matérialisées

{VB, …, VD} E FGH I JKLMI NILOJ Contrainte de Stockage

Figure 5.12 – Notre démarche de résolution à base d’un algorithme génétique

lock [198] a aussi montré que ces algorithmes sont très bons pour le problème de sélection des vues matérialisées.

5.1.2.2 Algorithme glouton. Notre algorithme glouton utilise la notion de bénéfice par unité d’espace (BPS) [199]. Le BPS est le rapport entre le bénéfice qu’apporte une vue et l’es-pace occupé par cette vue. La notion de bénéfice diffère de celle de profit définie ci-dessus. Le bénéfice prend en compte les apports des autres vues déjà retenues alors que le profit d’une vue ne considère que l’apport de cette vue seule.

bene f ice(v, M) =X

q∈Q

f req(q)∗ cout(q, M) −X

q∈Q

f req(q)∗ cout(q, M ∪ v) (8)

L’algorithme calcule de manière itérative les bénéfices de chaque vues et retient la vue ayant le plus grand bénéfice, jusqu’à ce que la contrainte de stockage ne soit plus respectée. Cet algorithme est donné ci-dessous (la fonction S(v) calcule l’espace occupé par v).

Algorithm 6 greedySelection