Motivation

Dans nos travaux, nous nous intéressons à la mise ne œuvre d’une nouvelle démarche de sélection combinée d’un schéma de FH et d’IJB, cela pour les motivations suivantes :

- La FH et IJB sont similaires du fait quelle permettent d’optimiser les requêtes de jointures en étoiles avec sélection sur les dimensions.

- Ces deux techniques sont définies sur un même ensemble d’attributs de sélections.

- Dans le contexte d’entrepôts de données, les attributs dimensions servent à effectuer des analyses décisionnelles. Le nombre d’attributs peut être du nombre de 100, 200 attributs ou plus. Par conséquent, définir un schéma d’optimisation sur un tel ensemble d’attribut devient une tâche difficile.

- Peut de travaux se sont intéressés à la mise en œuvre de démarche de sélection combinées de FH et IJB.

Parmi les travaux qui traitent ce type de sélection combinée, on cite les travaux de (Stöhr, et al., 2000). Les auteurs proposent une démarche de fragmentation hiérarchiques qui fragmentent à la fois la table de fait et les IJB définis. La démarche permet de réduire le nombre d’attributs de fragmentation en choisissant un seul attribut par hiérarchie de dimension, mais risque de générer un nombre considérable de fragments faits. Si un attribut Ville de la dimension Client possède 100 valeurs différentes, alors 100 fragments de la dimension Client seront générés.

Concernant les travaux (Boukhalfa, et al., 2008b), la démarche de sélection combinée effectue une sélection séquentielle de fragmentation horizontale et d’index de jointures binaire. Cette sélection commence par la fragmentation en utilisant tous les attributs de sélection, ensuite l’indexation en prenant en compte les attributs non utilisés par la fragmentation et les requêtes non bénéficiaires de la fragmentation. Une requête est dite bénéficiaire si elle est optimisée par la fragmentation, dans le cas contraire, elle est dite non bénéficiaire. Cette sélection engendre un nombre considérable de configurations possibles de schémas de FH car celle-ci est définie sur tous les attributs de sélection. De plus, ces travaux utilisent la FH pour choisir les attributs candidats à l’indexation et pour réduire l’espace de recherche du problème de sélection des index.

Ce choix est souvent guidé par un modèle de coût qui ne prend pas en considération la présence des index de jointure binaire lors de l’évaluation des requêtes. En conséquence, le processus de fragmentation risque d’utiliser certains attributs de sélection même s’ils sont plus performants pour l’indexation et vice versa. Ce constat nous a motivés pour considérer un nouveau problème lié à la sélection multiple des deux structures d’optimisation qui est le partage des attributs de sélection entre elles afin de maximiser la performance de l’ensemble de requêtes.

Nous proposons, dans nos travaux, une nouvelle démarche de sélection multiples d’index et de fragmentation basée sur le partage des attributs de sélections. D’un coté, nous visons à élaguer l’ensemble des attributs de sélection dans le but de réduire l’espace de recherche pour la FH, d’un autre coté nous nous basons sur les travaux de (Boukhalfa, et al., 2008b) et (Bellatreche, et al., 2008a) qui permettent de contrôler le nombre de fragments générés. De plus, nous proposons d’effectuer un partage des attributs de sélection en affectant chaque attribut à la technique la plus adéquate afin d’assurer une meilleure optimisation de la charge de requête. Il faut donc étudier le bénéfice apporté par chaque structure d’optimisation, définie sur un attribut donné, pour voir s’il

Chapitre III : Nouvelle démarche de sélection d’index et de fragmentation

63 est préférable d’indexer ou de fragmenter sur ce dernier. Mais avant cela, nous allons citer plusieurs points qu’il faut prendre en compte afin de pouvoir se prononcer sur l’affectation d’un attribut à une technique d’optimisation :

1. Le volume de données chargé par fragmentation : suivant les travaux (Boukhalfa, et al., 2008b) et (Bellatreche, et al., 2008a), la fragmentation d’un entrepôt de données reviens au partitionnement en sous domaines des domaines d’attributs de fragmentation. Ainsi, un attribut muni d’un sous domaine permet de caractériser un fragment (pour un attribut Ville avec le domaine {Alger, Oran, Msila, Annaba}, un partitionnement en sous domaine sera {Alger, Annaba}, {Msila, Oran}). De ce fait, la contrainte W du nombre de fragments maximum influe sur le partitionnement du domaine d’un attribut, et plusieurs valeurs d’attributs peuvent se retrouver dans un même domaine, contraignant ainsi le chargement d’un grand volume de données pour la sélection d’une seule valeur (la sélection sur Ville=Oran nécessiterait le chargement des tuples dont la ville est Msila).

2. Le volume chargé par index : pour des attributs de faibles cardinalité (attribut Genre {Féminin, Masculin}), le volume de données chargé par index, lors de l’exécution d’une requête, peut être tout aussi volumineux que celui chargé lors de l’accès direct à l’entrepôt.

Dans ce cas, l’optimiseur jugera cet index inutile et accédera directement aux tables.

3. Avantage de la fragmentation par rapport à l’indexation : soit un attribut de forte cardinalité.

La contrainte W sur le nombre de fragments détermine l’efficacité du schéma de fragmentation pour cet attribut. Ceci dit, une optimisation est assurée tant que l’attribut fait parti du processus de FH. D’un autre coté, ce même attribut peut être complètement écarté de la sélection d’index, car pour la sélection d’index soit l’attribut est indexé soit il ne l’est pas.

Cela signifie que la FH est plus tolérante que l’indexation.

4. La sélection d’un attribut pour l’indexation : lors de la sélection d’index, certains attributs peuvent être écartés de la sélection d’index dans deux cas :

- L’index crée est volumineux, c’est le cas ou la cardinalité de l’attribut est grande (attribut jour - cardinalité 30 - pour un entrepôt de 25 millions de tuples donnerais au minimum un index de 90 mo sans compression)

- L’attribut n’est pas fréquemment utiliser par la charge de requête

Ceci dit, la sélection des index dépend de l’espace de stockage réservé, si cet espace permet de recouvrir un grand nombre d’index crées, des attributs qui présentent un ou deux des cas cités ci-dessus peuvent être choisi par l’indexation.

Pour résumer, afin de déterminer quelle technique d’optimisation définir sur un attribut donnée, il faut prendre en compte la nature de ce dernier qui dépend de trois facteur importants : la cardinalité de l’attribut, la fréquence d’utilisation par la charge de requêtes et le volume de données chargé, lors de l’exécution d’une requête, en employant la technique définie sur l’attribut.

Dans ce qui suit, en considérant un attribut donné, nous allons étudier deux cas de figures : le cas ou la fragmentation sur l’attribut est plus appropriée et le cas où l’IJB donnerait un meilleur résultat que la fragmentation sur ce même attribut

III.1.1.1FH est meilleure

Etant donné un attribut, la fragmentation sur cet attribut peut être plus bénéfique que l’indexation dans les cas suivants :

- La cardinalité de l’attribut est grande, un index sur un tel attribut peut être écarté lors du processus de sélection d’index.

64 - L’attribut est fréquemment utilisé par les requêtes, dans ce cas il vaut mieux fragmenter sur

cet attribut afin d’assurer l’optimisation du coût d’exécution de la charge de requêtes.

- le coût d’exécution d’une requête avec index sur l’attribut est tout aussi grand que le coût avec accès direct aux tables. Dans ce cas, l’index est non employé par l’optimiseur.

Afin de mieux expliquer le troisième point que nous venons de citer, nous allons introduire l’exemple suivant :

Exemple 21 : Soit un ED dont la population est représenté par la figure III-1. Supposant deux scénarii d’optimisation : un scénario avec un schéma de FH sur l’attribut Genre, un autre scénario avec IJB sur Genre (figure III-2). Concernant la FH, la répartition en sous domaine de l’attribut Genre est {F}, {M}, ceci donne deux fragments de la dimension Client. Chaque fragment fait est calculé comme suit : Ventei=Vente x Clientj, où Clientj, est un fragment de Client (1<= i<= 2). La figure III-2 illustre l’IJB sur Genre et le sous schéma en étoile de l’ED fragmenté pour Genre = F. Soit la requête qui affiche la quantité, par client, des produits vendus à des clients féminins.

SELECT C.IdC, Sum(Prix) FROM Vente V, Client C

WHERE V.IdC=C.IdC AND C.Genre = ‘F’

GROUP BY C.Id C

Vente

Client RID IdC IdP IdT Prix

RID IdC Age Genre Ville 1 100 330 500 2000

1 100 20 F Annaba 2 110 300 510 15000

2 110 25 M Alger 3 130 320 520 6500

3 120 45 F Oran 4 110 340 550 2200

4 130 30 M Msila 5 120 320 500 8000

5 140 60 F Annaba 6 100 310 520 1000

6 150 40 M Oran 7 120 310 540 8000

7 160 60 F Alger 8 160 330 530 6500

9 130 320 550 22000 10 100 310 520 8000

Produit 11 130 340 550 1500

RID IdP Classe 12 160 300 510 70000

1 300 A 13 120 340 530 1500

2 310 B 14 140 310 540 8000

3 320 C 15 110 320 500 1400

4 330 C 16 140 310 520 22000

5 340 A 17 130 330 550 800

18 110 310 510 15000

Temps 19 130 310 500 8000

RID IdT Mois Année 20 100 330 520 2200

1 500 Janvier 2009 21 150 320 540 15000

2 510 Février 2009 22 130 300 550 14000

3 520 Mars 2009 23 100 300 510 1500

4 530 Janvier 2010 24 140 340 540 8000

5 540 Février 2010 25 140 300 500 8000

6 550 Mars 2010 26 160 310 530 22000

Figure III-1 Population de l’entrepôt de données

Chapitre III : Nouvelle démarche de sélection d’index et de fragmentation

65

Vente IJBGenre

RID IdC IdP IdT Prix F M

1 100 330 500 2000 1 0 Vente1 2 110 300 510 15000 0 1 RID IdC IdP IdT Prix 3 130 320 520 6500 0 1 1 100 330 500 2000 4 110 340 550 2200 0 1 Client1 ⁵ 120 320 500 8000 5 120 320 500 8000 1 0 RID IdC Age Genre Ville 6 100 310 520 1000 6 100 310 520 1000 1 0 1 100 20 F Annaba 7 120 310 540 8000 7 120 310 540 8000 1 0 3 120 45 F Oran 8 160 330 530 6500 8 160 330 530 6500 0 1 5 140 60 F Annaba 10 100 310 520 8000 9 130 320 550 22000 0 1 7 160 60 F Alger 12 160 300 510 70000 10 100 310 520 8000 1 0 13 120 340 530 1500 11 130 340 550 1500 1 0 14 140 310 540 8000 12 160 300 510 70000 1 0 16 140 310 520 22000 13 120 340 530 1500 1 0 20 100 330 520 2200 14 140 310 540 8000 1 0 23 100 300 510 1500 15 110 320 500 1400 0 1 24 140 340 540 8000 16 140 310 520 22000 1 0 25 140 300 500 8000 17 130 330 550 800 0 1 18 110 310 510 15000 0 1 19 130 310 500 8000 0 1 20 100 330 520 2200 1 0 21 150 320 540 15000 0 1 22 130 300 550 14000 0 1 23 100 300 510 1500 1 0 24 140 340 540 8000 0 1 25 140 300 500 8000 1 0 26 160 310 530 22000 1 0

Figure III-2 – Schéma de fragmentation Genre=F / IJB sur l’attribut Genre

Pour l’entrepôt optimisé par fragmentation ou par IJB, l’exécution de la requête nécessite le chargement de 57% de la table de fait. Vu la taille importante des entrepôts de données (dizaine ou centaine millions de tuple pour la table de fait), l’IJB peut être jugé inutile est non sélectionné par l’optimiseur pour l’exécution de la requête. Par contre, une réduction du volume de données chargé est obtenue par fragmentation car seul le fragment Vente1 est chargé. Ce dernier est obtenu par semi jointure comme suit : Vente1=Vente x Client1, ou Client1 (ventes de clients féminins). Ainsi, il est préférable de fragmenter sur l’attribut Genre.

III.1.1.2 IJB est meilleur

Un IJB défini sur un attribut donné peut s’avérer plus utile que de définir un schéma de FH, c’est dans le cas où la cardinalité de l’attribut n’est pas très faible (index généré est écarté par l’optimiseur) ou pas très forte (l’attribut risque d’être écarté par processus de sélection d’index), et que le seuil W donne un schéma de fragmentation où les domaines des attributs sont fusionnés.

Exemple 22 : Soit un ED dont la population est représenté par la figure III-1. Soient les attributs de sélection Genre, Ville, Classe, Mois et Année. Le nombre de fragments possibles est de 96.

Supposant W= 30 et un schéma de FH avec les répartitions en sous domaines suivants : Genre : {F}, {M} ; Ville : {Alger, Annaba}, {Oran, Msila} ; Classe {A}, {B, C} ; Mois :{Janvier}, {Février}, {Mars}, ceci donne 24 fragments fait et donc 24 sous schémas en étoile. Chaque fragment fait est calculé comme suit : Ventei=Vente x Clientj x Produitk x Tempsp, où Clientj, Produit_k et Temps_p sont respectivement un fragment de Client (1<= i <=4), Produit (1<= j <=2) et Temps (1<= k <=3). Nous présentons sur la figure III-3 les données chargées (faits et dimensions) pour l’exécution de la requête dans le cas d’ED fragmenté sur Ville. Sur la figure III-4, nous présentons l’IJB définit sur l’attribut Ville et les données chargées par emploi de l’IJB lors de l’exécution de la requête.

66

Ventes chargées par fragmentation

Client1 RID IdC IdP IdT Prix

RID IdC Age Genre Ville 1 100 330 500 2000 1 100 20 F Annaba 2 110 300 510 15000 2 110 25 M Alger 4 110 340 550 2200 5 140 60 F Annaba 6 100 310 520 1000 7 160 60 F Alger 8 160 330 530 6500 10 100 310 520 8000 12 160 300 510 70000 14 140 310 540 8000 15 110 320 500 1400 16 140 310 520 22000 18 110 310 510 15000 20 100 330 520 2200 23 100 300 510 1500 24 140 340 540 8000 25 140 300 500 8000 26 160 310 530 22000

Figure III-3 – Données chargées pour l’exécution de la requête : cas FH sur Ville

Vente IJB_Ville

RID IdC IdP IdT Prix Alger Annaba Oran Msila 1 100 330 500 2000 0 1 0 0 2 110 300 510 15000 1 0 0 0 3 130 320 520 6500 0 0 0 1 4 110 340 550 2200 1 0 0 0 5 120 320 500 8000 0 0 1 0 Ventes chargées par IJB_Ville 6 100 310 520 1000 0 1 0 0 RID IdC IdP IdT Prix 7 120 310 540 8000 0 0 1 0

2 110 300 510 15000 8 160 330 530 6500 1 0 0 0 4 110 340 550 2200 9 130 320 550 22000 0 0 0 1 8 160 330 530 6500 10 100 310 520 8000 0 1 0 0 12 160 300 510 70000 11 130 340 550 1500 0 0 0 1 15 110 320 500 1400 12 160 300 510 70000 1 0 0 0 18 110 310 510 15000 13 120 340 530 1500 0 0 1 0 26 160 310 530 22000 14 140 310 540 8000 0 1 0 0

15 110 320 500 1400 1 0 0 0 16 140 310 520 22000 0 1 0 0 17 130 330 550 800 0 0 0 1 18 110 310 510 15000 1 0 0 0 19 130 310 500 8000 0 0 0 1 20 100 330 520 2200 0 1 0 0 21 150 320 540 15000 0 0 1 0 22 130 300 550 14000 0 0 0 1 23 100 300 510 1500 0 1 0 0 24 140 340 540 8000 0 1 0 0 25 140 300 500 8000 0 1 0 0 26 160 310 530 22000 1 0 0 0

Figure III-4 – Données chargées pour l’exécution de la requête : cas IJB sur Ville Soit la requêtes qui affiche le prix, par client, les ventes des clients d’Alger :

SELECT C.IdC, Sum(Prix) FROM Vente V, Client C

WHERE V.IdC=C.IdC AND C.ville= 'Alger' GROUP BY C.IdC

Considérons l’entrepôt fragmenté. L’exécution de la requête nécessite le chargement de 12 sous schémas en étoile, chaque sous schéma concerne les vente des clients vivant à Alger ou à Annaba (les deux valeurs sont dans le même sous-domaine de Ville). Ainsi, le volume total de données

Chapitre III : Nouvelle démarche de sélection d’index et de fragmentation

67 chargées représente 61% de la table de fait (figure III-3). De plus, l’exécution de la requête nécessite des opérations de Jointure entre fragments Clientj et Ventei, une sélection sur Ville=Alger sur chaque sous schéma en étoile, une union des résultats obtenus par les 12 sous schéma puis le calcul du résultat du GROUP BY.

A présent, considérons l’entrepôt optimisé par IJB définit sur l’attribut Ville (figure III-4).

L’exécution de la requête ne requière ni chargement des fragments des la table Client ni jointure avec les fragments fait. De plus seuls 7 tuples seront chargé soit 27% de la table de fait. Ainsi, il est plus intéressant de définir un IJB sur Ville.

Pour résumer, dans les travaux de (Boukhalfa, et al., 2008b) et (Bellatreche, et al., 2008a), la FH est sélectionnée sur tous les attributs de sélections. Ceux qui restent permettent de définir les IJB. Par contre, ces index peuvent s’avérer inutiles. En effet, si le volume de donnée chargé par index est volumineux, l’optimiseur du SGBD jugera préférable d’utiliser la table directement. Si la cardinalité de l’attribut est forte, l’attribut peut être écarté du processus de sélection d’IJB.

D’autre part, des attributs peuvent être choisis pour la FH alors que leur sélection pour un IJB donnerait un meilleur résultat. Ainsi, nous proposons de répartir les attributs entre IJB et FH, avant de sélectionner les structures.