Matérialisation partielle des cubes de données

Matérialisation partielle des cubes de données N. Hanusse S. Maabout R.Tofan CNRS-INRIA-LaBRI. Université de Bordeaux {hanusse,maabout,tofan}@labri.fr Résumé Les cubes de données offrent une interface intuitive aux décideurs pour l interrogation d une partie des entrepôts de données. Pour optimiser la navigation au sein de ces cubes, une solution consiste à en matérialiser certaines parties. Se pose alors le problème du choix de ces parties. Dans cet article, nous proposons des algorithmes (exacts et approchés) qui permettent de trouver la partie d un cube de données à stocker en fonction de critères de performances fixés par l utilisateur : étant donné f un nombre réèl positif fixé par l utilisateur, pour chaque requête q d un ensemble Q de requêtes cibles, le temps de réponse de q doit être inférieur à f fois le temps de réponse minimal obtenu lorsque le cube de données est entièrement matérialisé. Nous proposons trois algorithmes de sélection de vues garantissant le critère de performance f. Pour chacun d eux, l objectif est de minimiser la quantité de mémoire requise pour stocker les vues sélectionnées. Les algorithmes proposés sont respectivement des 1-approximation (donc optimal), 1 + ln Q -approximation et f(1 + ln Q )-approximation de l optimal concernant l espace mémoire. En pratique, les algorithmes non optimaux s avèrent très compétitifs en temps de calcul et même en espace mémoire des solutions qu ils retournent. Par ailleurs, nous étudions la stabilité des solutions retournées suite à la mise à jours des cubes. Nous validons nos propositions par des expérimentations. 1 Introduction Dans les applications OLAP, la rapidité de l évaluation des requêtes analytiques est primordiale. En effet, les utilisateurs posent des requêtes complexes, difficiles à optimiser par les systèmes de gestion de bases de données classiques. Ainsi, on a souvent recours à un pré-calcul ou d une manière équivalente à la matérialisation des requêtes les plus souvent exprimées par les utilisateurs. Cependant, ces dernières peuvent être trop nombreuses pour être toutes précalculées et ceci pour deux raisons : soit à cause du temps qu il faudrait pour toutes les calculer ou bien en raison de l espace mémoire nécessaire pour toutes les stocker. Ainsi, on utilise des algorithmes permettant de choisir les meilleures vues (ou requêtes) à matérialiser. Dans notre travail, nous ne considérons que les vues qui correspondent à des cuboïdes, c est-à-dire qu une requête est de la forme : SELECT c,mesures FROM T GROUP BY c où c désigne une liste d attributs et T une table de faits de D attributs. Que ce soit en présence ou absence de hiérarchies entre certains attributs (ou dimensions), le nombre de cuboïdes existants dans le cube de données C est supérieur ou égale à 2 D. Bien que les algorithmes présentés dans cet article puissent prendre en compte des hiérarchies d attributs, pour des raisons de lisibilité Ce travail a été partiellement financé par le Projet Records de la DGE du ministère de l industrie (France). 1

et simplicité, nous supposons d abord qu il n y en a pas. Ainsi, par la suite, C = 2 D. Nous discutons par la suite le cas des hiérarchies. Les performances des algorithmes de sélection sont évaluées selon trois critères : (1) l espace requis pour stocker les vues sélectionnées, (2) le temps d évaluation des requêtes en fonction de la celles que l algorithme a décidé de matérialiser celles et (3) le temps nécessaire à l algorithme pour trouver une solution c.à.d sa complexité. La plupart des solutions proposées jusqu à présent consistent à choisir un sous-ensemble de vues permettant d optimiser l évaluation des requêtes sans dépasser une limite d espace mémoire fixée par l utilisateur. Certaines variantes de ce problèmes ont été étudiées : (1) la nature des données qu on peut stocker, e.g seulement des vues ou des index aussi, (2) le modèle de coût e.g minimiser non seulement le temps d évaluation des requêtes mais aussi la coût de mise à jour ou finalement (3) l ensemble des requêtes susceptibles d être posées e.g toutes ou bien un sous-ensemble. Dans ce dernier cas, le problème peut être raffiné en considérant la fréquence {p i } i=1... C ou charge de travail des requêtes Q C que l on veut optimiser. Nous nous intéressons dans notre étude à un cadre général dans lequel Q correspond à des cuboïdes ou requêtes cibles. Ils peuvent être définit de manière arbitraire par l administrateur de la base de données ou sélectionné parmi les cuboïdes dont la fréquence est au delà d un seuil fixé, c est-à-dire les requêtes fréquentes. En général, le problème peut être décrit par un problème d optimisation sous contrainte : la contrainte étant l espace disponible qu il ne faut pas dépasser et la fonction à optimiser est le coût moyen des requêtes qu il faut minimiser. Dans cet article, nous proposons que la contrainte soit une contrainte de performance. Dans un monde idéal, le temps de réponse à une requête q est égal à q, à un facteur de normalisation près. Pour avoir un tel temps de réponse, il faut stocker toutes les réponses à l avance. Cette solution est inenvisageable. Si on se permet de dégrader le temps de réponse d un facteur f avec une petite valeur de f > 1, on peut espérer n avoir à pré-calculer qu une petite partie du cube de données et ceci en un temps raisonnable. L objectif dans notre approche consiste donc à minimiser l espace mémoire requise pour stocker un sous-ensemble de cuboïdes S C garantissant un temps de réponse pour une requête q Q d au plus f q. A notre connaissance, aucune des solutions proposées dans la littérature n offre un bon compromis entre complexité de l algorithme de sélection, minimalité du coût moyen de la solution et garantie de performance. D autre part, nous montrons des caractéristiques que Q doit avoir pour espérer qu il soit résumable par un ensemble S, c est-à-dire par un ensemble de cuboïdes nécessitant bien moins d espace mémoire que ceux constituant Q. Structure de l article L article est organisé de la manière suivante : nous présentons d abord quelques notations et défintions nous permettant de formaliser le problème à traiter. Nous décrivons par la suite quelques travaux relatifs. Dans la section 3, nous présentons notre solution pour cas où tous les cuboïdes d un cube de données peuvent être interrogés ensuite nous traitons le cas où l on dispose d un ensemble de requêtes fixé (Section 4). Pour résoudre ce dernier cas, nous présentons une solution exacte ainsi que deux méthodes approchées avec garantie d approximation. Nous montrons par la suite que l introduction des hiérarchies ne pose aucun problème quant aux résultats présentés aupravant. Dans la section 6, nous analysons la propriété de stabilité de nos solutions lors d opérations de mise-à-jour de la table de faits. Nous présentons quelques unes des expériences que nous avons conduites permettant de valider notre approche et nous terminons par une conclusion récapitulant notre apport en mentionnant quelques perspectives de travaux futurs. 2

2 Préliminaires Notations Une table de faits T est une relation où l ensemble des attributs est divisé en 2 parties : l ensemble des dimensions Dim(T ) et l ensemble des mesures Mesures(T ). En général, Dim(T ) forme une clé pour la table T. Le cube de données [?] construit à partir de T est obtenu en agrégeant T et en regroupant ses tuples dans toutes les manières possibles c.à.d tous les Group By c où c est un sous-ensemble de Dim(T ). Chaque c correspond à un cuboïde 1. Le cube de données associé à T est noté DC(T ). Par abus de notation Dim(DC(T )) désignera Dim(T ). Soit DC(T ) un cube de données, Dim(T ) ses dimensions et Dim(T ) = D. L ensemble des cuboïdes de DC(T ) est noté C(T ). Il est évident que C(T ) = 2 D. Le cuboïde obtenu en regroupant T sur toutes les dimensions de T est appelé cuboïde de base et est noté c b. La taille d un cuboïde c correspond au nombre de ses lignes et est notée size(c). La taille d un ensemble de cuboïdes S est notée size(s). Le treillis du cube de données est induit par une relation d ordre partiel entre cuboïdes qui est définie comme suit : v w ssi Dim(v) Dim(w). On dit que w est un ancêtre de v. Aussi, si Dim(w) = Dim(v) + 1 alors w est un parent de v. En fait, si v w alors v peut être calculé à partir de w. 2 Modèle de coût Soient S C l ensemble des cuboïdes matérialisés et v un cuboïde. Alors, S v = {w S v w} est l ensemble de cuboïdes matérialisés à partir desquels v peut être calculé. Le coût de v respectivement à S est défini comme suit : si S ne contient aucun ancêtre de v alors cost(v, S) = sinon cost(v, S) = min w Sv size(w), c.à.d v est évalué à partir de son ancêtre qui a le plus petit nombre de tuples. C est la mesure généralement utilisée pour évaluer le coût des requêtes (voir par exemple [?,?,?]). Noter que quand v S v alors cost(v, S) = size(v). Ceci est le coût minimal pour v. Nous définissons le coût induit par S comme étant le coût de toutes les requêtes possibles, c.à.d cost(s) = c C cost(c, S). Quand S = C c.à.d tous les cuboïdes sont stockés, cost(s) = c C size(c). Ceci est le coût minimal et est noté MinCost. Si S = {c b } alors cost(s) = C M où M = size(c b ). Ceci représente le coût maximal et est noté MaxCost. Ainsi, pour tout S, on a c C size(c) cost(s) C M. 3 Nous définissons la performance d un ensemble S comme suit : Définition 1 (Facteur de performance). Soit S l ensemble des cuboïdes matérialisés et c un cuboïde de C. Le facteur de performance de S resp. à c est défini par f(c, S) = cost(c,s). Le size(c) facteur de performance moyen de S resp. à C C est défini par f(c, S) = c C f(c,s) C Intuitivement, le facteur de performance mesure le ratio entre le temps d exécution d une requête à partir de S par rapport au coût minimal de cette requête. L exemple ci-dessous permet d illustrer les notions qu on a introduites dans cette section. Exemple 1. Considérons le graphe de la Figure??. Il représente le treillis du cube de données associé à une table T dont les dimensions sont A, B, C, D et E. Chaque nœud du graphe représente un cuboïde décrit par ses dimensions ainsi que sa taille. Le coût minimal pour évaluer toutes les requêtes correspond au cas où tous les cuboïdes sont stockés. Ainsi, MinCost = 2 5 i=1 size(c i) = 8928. Le coût maximal est obtenu en considérant que seul le cuboïde de base est stocké ainsi MaxCost = 2 5 size(abcde) = 2000 32 = 64000. Noter néanmoins que ceci correspond à l espace mémoire minimum que l on doit utiliser pour pouvoir répondre à toutes les requêtes. Supposons maintenant que S = {ABCDE, BE}. Les mesures de performance de S sont comme suit : L espace mémoire utilisé est M em(s) = size(abcde)+size(be) = 2000+100 = 2100. Le coût 1. Dans la suite de l article, nous utiliserons d une manière équivalente les termes cuboïde, vue et requête. 2. Dans cet article, on ne considère que les mesures algébriques. 3. On ne considère que les S qui contiennent c b car sinon cost(s) =. 3

2000 ABCDE 600 600 1000 1000 600 ABCD ABCE ABDE ACDE BCDE 100 300 180 60 250 300 300 300 300 180 ABC ABD ABE ACD ACE ADE BCD BCE BDE CDE 30 40 100 40 250 15 50 40 50 150 AB AC AD AE BC BD BE CD CE DE 10 30 2 20 30 A B C D E 1 Apex Figure 1 Un exemple de cube de données pour évaluer les 2 5 requêtes possibles est obtenu de la manière suivante. D abord, prenons le cuboïde stocké BE. Ce dernier sert à calculer BE, B, E et Apex 4. Tous les autres cuboïdes sont calculés à partir de ABCDE. Ainsi, Cost(S) = 4 size(be) + 28 size(abcde) = 56400. Considérons maintenant les cuboïdes BE et BC. leurs facteurs de performance respectifs sont f(be, S) = cost(be,s) size(be) = 100/100 = 1 et f(bc, S) = cost(bc,s) size(bc) = size(abcde)/40 = 2000/40 = 50. Cela signifie qu en matérialisant ABCDE et BE, le coût de BE en utilisant S est égal à son coût minimal, par contre pour BC, le coût est 50 fois son coût minimal. Formalisation du problème Dans cet article nous traitons le problème suivant : Etant donnés un nombre réel f 1 et un ensemble de requêtes Q C trouver un ensemble de cuboïdes S tel que pour tout q Q, on a cost(q, S) f size(q) et size(s) est minimal. Nous étudions dans cet article deux cas : celui où Q = C (appelée plus loin absence de cible) et celui où Q C (présence de cible). Le modèle absence de cible correspond au cas où on ne dispose pas de connaissance préalable sur les requêtes cibles. Travaux relatifs Avant de présenter nos solutions, nous rappelons d abord quelques travaux relatifs. Aucun des travaux que nous avons trouvés dans la littérature ne pose le problème de sélection des vues dans les termes que nous avons utilisés. La plupart considère une limite M sur l espace mémoire disponible et essaye de trouver le sous-ensemble dont la taille ne dépasse pas M et qui réduit au maximum la somme des coûts des requêtes. Dans [?], les auteurs montrent que ce problème est NP-complet et proposent donc un algorithme glouton pour le résoudre. Ils utilisent pour cela la notion de gain qu on rappelle ici. Définition 2 (Gain). Soit S C. Le gain de S est défini par cost({c b }) cost(s). Noter que cost({c b }) est MaxCost. L algorithme qu ils proposent tend à trouver un ensemble S qui maximise le gain. Les auteurs montrent que le gain apporté par leur solution est supérieur à 63% du gain apporté par la solution optimale. Ceci représente leur garantie de performance. Cependant, il faut faire ici quelques remarques : (i) L algorithme glouton qu ils proposent a une complexité en O(n) avec n qui est le nombre de cuboïdes au total. On sait bien que ce nombre 4. Apex est le cuboïde sans dimensions. 4

est 2 D. On est donc en présence d un algorithme exponentiel en nombre de dimensions. Aussi, (2) l algorithme suppose la connaissance de la taille de tous les cuboïdes. Ceci est largement non réaliste dans le cas où le nombre de dimensions est grand. Enfin, (3) la garantie du gain qu ils prouvent pour leur algorithme n implique pas une garantie de performance. Autrement dit, le rapport entre le coût de leur solution sur le coût de la solution optimale n est pas borné par une constante. Cette même remarque a été soulevée dans [?]. Ces derniers ont démontré que dans les graphes généraux, l algorithme glouton ne garantissait pas une performance de requêtes. Ils ont néanmoins laissé ouverte la question quant aux cubes de données. Nous en avons fait la démonstration dans le cadre particulier des cubes de données mais faute d espace nous ne la présentons pas ici. Pour pallier le problème de complexité de [?], les auteurs de [?] en ont proposé une simplification qui consiste tout simplement à prendre les cuboïdes selon l ordre croissant de leurs tailles jusqu à épuiser l espace mémoire disponible. Ils montrent que souvent les solutions qu ils trouvent étaient comparables à celle de [?]. Bien sûr, cette méthode souffre des même travers que ceux de [?] quant aux performances. D autres auteurs ont eu une vision plus générale du problème. Par exemple, [?,?,?] considèrent la possibilité de stocker en plus certains index. [?] a utilisé une extension de [?] alors que [?] a montré que le problème pouvait se modéliser par un programme linéaire qu on pouvait résoudre exactement, c.à.d trouver la solution optimale, quand le nombre de variables n était pas trop élevé sinon, ils ont proposé une relaxation pour réduire la taille du problème mais dans ce cas, ils n ont montré l efficacité de cette approche que d une manière expérimentale. 3 Sélection de vues en l absence de cible Dans cette section, nous considérons le cas où l ensemble des requêtes susceptibles d être posées par l utilisateur correspond à tous les cuboïdes du cube de données. Cette situation peut avoir lieu lors de la création du cube de données, puisqu à ce moment on ne sait pas encore quelles sont les requêtes qui seront le plus souvent posées. Nous aborderons par la suite le cas où l on dispose de cette information. Nous donnons d abord quelques définitions. Définition 3 (Petit cuboïde et Bordure). Soit f > 1 un nombre réel et M = size(c b ). Un cuboïde c est dit petit si size(c) M/f. Soit c un petit cuboïde. Alors c est maximal ssi aucun de ses parents n est petit. L ensemble des cuboïdes maximaux représente une bordure du cube de données C relativement à f. On la note B f (C) ou simplement B f quand C est compris du contexte. Exemple 2. Reprenons le cube de données de la figure?? et supposons f = 10. Comme size(abcde) = 2000 alors les petits cuboïdes sont ceux dont la taille ne dépasse pas 2000 10. On peut facilement vérifier que B f = {ACD, ADE, BCD, BDE}. Tous les cuboïdes qui sont au dessus de la bordure peuvent être calculés à partir du cuboïde de base en ayant une garantie de performance sur leurs coûts : Lemme 1. Soient f > 1 et B f. Pour tout c ancêtre d un élément de B f, cost(c, {c b }) f size(c). Comment obtenir la même garantie pour les autres cuboïdes? Il suffit de calculer les autres bordures B f 2, B f 3... Définition 4 (Bordures). Soient f > 1 et M = size(c b ). Soit B f = log f (M) i=0 B f i. L ensemble B f désigne les bordures de C. 5

2000 ABCDE 0 f=1 600 600 1000 1000 600 ABCD ABCE ABDE ACDE BCDE 300 300 300 100 300 180 60 300 180 250 ABC ABD ABE ACD ACE ADE BCD BCE BDE CDE 1 f=10 2 f=100 250 15 30 50 40 40 100 40 50 150 AB AC AD AE BC BD BE CD CE DE 10 30 20 30 A B C D E 2 3 f=1000 1 Apex Figure 2 Les bordures du cube de données pour f = 10. Exemple 3. Reprenons notre exemple courant. La figure?? montre l ensemble des bordures de C. Ses éléments sont représentés par des cercles pleins. Les bordures d un cube de données permettent de garantir la performance des requêtes : Théorème 1 ([?]). Soit f > 1 et B f. Alors pour tout c C, cost(c, B f ) size(c) f. Ceci signifie que si l utilisateur fixe une valeur pour f, nous sommes capables de lui retourner un ensemble de cuboïdes qui garantit que le coût de chaque requête ne dépasse pas f fois le coût minimal de cette dernière. Du théorème précédent, on déduit le corolaire suivant : Corolaire 1. Soient f > 1 et B f. Soit M = size(b f ). Soit C M = {S C size(s) M}. Soit S = arg min S CM cost(s). Alors, cost(b f ) f cost(s ). Autrement dit, si avec un espace mémoire disponible égal à M, la meilleure solution, c.à.d celle qui réduit au maximum le coût des requêtes, est S alors le coût de B f est au maximum f fois le coût de S. Exemple 4. Pour illustrer notre proposition, reprenons la Figure??. Les courbes représentent les bordures relatives aux différentes puissances de f quand f = 10. Les nœuds représentés par des cercles remplis sont donc les seuls à être matérialisés. La taille totale du cube de données est de 8928. Ceci représente le coût minimal pour évaluer toutes les requêtes. Le coût maximal est de 32*2000=64000. Par ailleurs, size(b f ) = 2607 et cost(b f ) = 27554. Noter néanmoins que même si on a fixé le facteur de performance à f = 10, le ratio entre le coût de B f et le coût minimal est 27554 = 3.09. Ainsi, le coût moyen pour répondre à n importe quelle requête en 8927 utilisant B f est 3 fois le coût minimal. Avec HRU, l algorithme de [?] et avec la contrainte sur l espace qui ne doit pas dépasser size(b f ), les seuls cuboïdes qui seront retenus sont ABCDE et BCDE. On obtient ainsi un coût de 41600 ce qui représente un ratio, toujours par rapport au coût minimal, de 41600 = 4.67. Notons aussi que PBS, l algorithme de [?], retourne 16 cuboïdes 8927 (les 16 premiers cuboïdes selon l ordre croissant de leurs tailles respectives). Le coût de cette solution est de 34518. Ce qui correspond à un ratio de 34518 = 3.87 meilleur que HRU. 8927 Dans [?,?] nous avons montré que le problème de calcul des bordures dans notre contexte est similaire à celui de la recherche des ensembles fréquents maximaux bien étudié dans le cadre du datamining [?,?,?,?]. Nous y avons aussi proposé un algorithme de calcul de bordures adapté à notre problématique. 6

4 Sélection de vues en présence de cible Dans cette section, nous considérons un ensemble Q qui représente l ensemble des requêtes que l on veut optimiser. Rappelons que les requêtes que l on considère dans cet article sont celle de la forme select * from c où c est un des cuboïdes de C 5. Il s agit donc de trouver un ensemble S C tel que : Pour chaque q Q, il existe c S t.q q c c.à.d q peut être calculée Pour chaque q Q, il existe c S t.q q c et size(c) f size(q) c.à.d q peut être calculée efficacement S doit avoir une taille minimale Notre contribution pour résoudre ce problème est double : (1) nous donnons un algorithme de complexité polynomiale retournant une log n-approximation de l optimal et (2) un programme linéaire en nombre entiers qui retourne la solution optimale mais en un temps non borné. Nous introduisons d abord quelques notations. On note par A f (q) l ensemble des cuboïdes qui sont (1) ancêtres d une requête q Q et (2) dont la taille est inférieure ou égale à f size(q). B f (q) A f (q) est l ensemble des éléments maximaux de A f (q), c est-à-dire la f-bordure de q. Soit A f (Q) = q Q A f(q). Noter que Q A f (Q). On utilise aussi la notation B f (Q) = q Q B f(q). Il est facile de voir que la solution à notre problème est un sous-ensemble de A f (Q). En effet, Lemme 2. Soit S C le plus petit ensemble de cuboïdes (en terme de taille mémoire) t.q cost(q, S ) f size(q) pour chaque q Q. Alors S A f (Q). 4.1 Modélisation par un problème de domination dans des graphes orientés et pondérés Quelle que soit la solution proposée, on peut modéliser notre problème par celui de la recherche d un ensemble dominant pondéré dans le graphe orienté et pondéré suivant : Définition 5 (Graphe de recherche). Soit G(f) = (V, E, w) le graphe de recherche défini par : V = A f (Q) et (v 1, v 2 ) E ssi (i) v 2 Q et (ii) v 1 A f (v 2 ). w : V [1, C ] défini par w(c) = size(c). Définition 6 (Graphe de recherche partiel). Le graphe de recherche partiel G p (f) est le sousgraphe de G(f) induit par les sommets V = B f (Q) Q. L exemple de la figure?? montre le graphe de recherche et le graphe de recherche partiel pour la valeur f = 10. Le poids d un ensemble de sommets correspond à l espace mémoire requis pour stocker cet ensemble. Nous allons construire un ensemble dominant Q dans le graphe de recherche : Définition 7 (Ensemble dominant). Soit G un graphe de recherche. S V domine (ou couvre) Q V ssi pour tout q Q, il existe s S tel que q est voisin (sortant) de s. Partant du graphe de recherche, la sélection du plus petit S revient à chercher l ensemble de sommets de V de poids minimum qui couvre tous les éléments de Q. Ce problème est 5. On pourrait inclure les requêtes du type select * from c where att=val sans changer fondamentalement les résultats car on n a pas considéré la possibilité d avoir des index. 7

600 600 ABCD ABCD 300 300 100 60 300 300 100 60 ABC ABD ACD BCD ABC ABD ACD BCD 250 15 30 40 40 40 250 15 30 40 40 40 AB AC AD BC BD CD AB AC AD BC BD CD 10 30 2 20 10 30 2 20 A B C D A B C D 1 1 Apex Apex Figure 3 Graphe de recherche complet (à gauche) et partiel (à droite) avec Q = {B, C, D} et f = 10. une variante du problème bien connu du minimal weighted set cover (MWSC) qui est NPcomplet [?]. 6 Cependant, il existe un algorithme glouton de complexité en temps O( V S ) = O( V Q ). qui permet de le résoudre avec une 1+ln Q -approximation de la solution optimale [?]. Plus exactement, si Q est le degré sortant maximal du graphe de recherche, on peut trouver une solution qui est une 1 + ln approximation de l optimal. Le premier algorithme présenté possède cette approximation et nous en donnons un deuxième qui est f(1 + ln ) approximation. Ce deuxième résultat est nouveau. Par ailleurs, il est bien connu que le problème MWSC peut être modélisé par un programme d optimisation linéaire qui peut être résolu assez rapidement par les solveurs existants lorsque le nombre de variables n est pas trop élevé. 4.2 Solutions approchées Soit Γ(c) l ensemble des voisins sortant de c. Cet algorithme est une adaptation de l algorithme classique glouton de construction d ensemble dominant pour un graphe pondéré. Fonction PickFromf Ancestors(G) V = sommets de G S = Tant que Q c size(c) = arg min c V (Q) Γ(c) S = S {c } V (Q) = V (Q)\({c } Γ(c )) Q = Q\Γ(c ) Fin Tant Que Retourner S Fin Fonction L algorithme consiste à choisir, lors de chaque itération, l ancêtre qui a la charge size(c) Γ(c) minimale. Cette dernière est définie comme étant la taille de l ancêtre divisée par le nombre de ses voisins (c.à.d le nombre de requêtes de Q qu il couvre). Dès qu un ancêtre est choisi, on le met dans la solution S et on le supprime du graphe ainsi que les requêtes qu il couvre. Ceci a 6. Dans le problème initial, Q = V. 8

pour incidence de modifier le nombre de voisins des sommets restants. En utilisant le résultat de [?] nous montrons le facteur d approximation obtenu par cet algorithme appliqué à G(f) ou à G p (f). Théorème 2. Soient f > 1 et G un graphe de recherche. Soit S la solution retournée par PickFromfAncestors(G). Si S est la solution optimale (c.à.d la plus petite en taille mémoire) alors : Pour chaque q Q, cost(q, S) f size(q) ; Si G = G(f) alors size(s) (1 + ln ) size(s ) où est le degré maximal de G ; Si G = G p (f) alors size(s) f(1 + ln ) size(s ) où est le degré maximal de G. Démonstration. Seul le troisième point nécessite d être démontré. Soit S (resp. S p une solution optimale donnée par le graphe de recherche G(f) (resp. G p (f)). Soit V l ensemble des sommets de G p (f). Réalisons une solution S V à partir de S. Pour tout s V S, s appartient S. Si s / V S, alors on ajoute à S le plus petit ancêtre s de s qui appartient à V. Autrement dit, si s domine q 1, q 2,..., q k Q avec size(q i ) size(q i+1 ) alors s B f (q 1 ) et size(s)/f size(s ) f q i pour tout i k. Par construction, nous avons donc que S et S ont même cardinalité et size(s ) f size(s ). Or, par définition, size(s ) size(s p). Il s en suit que size(s p) f size(s ). Comme PickFromf Ancestors retourne une solution qui est une (1 + ln ) approximation de l optimal S p, la solution retournée a une taille au plus f(1 + ln )size(s ). On peut se demander l intérêt de considérer le graphe de recherche partiel car la garantie sur l espace mémoire est plus mauvaise qu en prenant le graphe de recherche. Cependant, ce graphe de recherche partiel est plus petit et il sera plus rapide d y chercher une solution S. 4.3 Solution exacte Nous donnons maintenant le programme d optimisation linéaire. Avant cela, nous décrivons les variables utilisées : s i désigne la taille du cuboïde c i A f (Q), x i {0, 1} et signifie que c i est choisi pour être matérialisé (1) ou non (0), y ij {0, 1} telle que y ij = 1 ssi q i Q utilise c j pour être calculée min i : q i Q j:c j A f (Q) j:c j A f (q i ) x j s j (1) y ij = 1 (2) i : q i Q, j : c j A f (q i ) y ij x j (3) j : c j A f (Q) x j {0, 1} (4) i : c i Q, j : c j A f (q i ) y ij {0, 1} (5) La contrainte (2) impose que q i n utilise qu un seul cuboïde et la contrainte (3) implique que q i ne peut utiliser c j que si c j est stocké. Enfin, les contraintes (4) et (5) imposent que les x i et les y ij sont des variables binaires. Résoudre ce problème revient à affecter des valeurs aux variable x j et y ij qui permettent de minimiser la valeur de l expression (1). La solution exacte à notre problème correspond donc à S = {c j A f (Q) : x j = 1}. On peut se demander pourquoi avoir recours à un algorithme approché lorsqu on peut résoudre 9

exactement un problème. En fait, les solveurs tels que Cplex, ou LP Solve 7, sont très puissants jusqu à un certain nombre de variables. Or, le nombre de x i et de y ij peut croître assez rapidement avec l accroissement de Q ou avec l accroissement de f. Dans les expérimentations que nous avons menées, nous avons utilisé LP Solve qui est un outil gratuit qui, bien que efficace, ne nous a néanmoins pas permis de traiter des cas où Q était grand. Remarque 1. Il est à noter que le nombre de variables y ij correspond au nombre d arcs dans le graphe de recherche G et que le nombre de variables x j est égal au nombre de sommets. Il y a donc au moins 2 Q variables. Dans nos expérimentations avec Q > 200 et f > 2, la taille de A f (Q) dépassait largement les 20000. 5 Intégration des dimensions avec hiérarchies Dans ce qui a été présenté auparavant, nous n avons pas pris en compte le fait que certaines dimensions puissent être modélisées par des hiérarchies. Ces dernières sont souvent présentes dans les cubes de données et sont utilisées dans le cadre des requêtes du type Roll-Up et Drill- Down. Dans cette section, nous montrons que, à quelques détails mineurs prés, la prise en compte des hiérarchies ne pose pas de problèmes. Nous définissons d abord une relation d ordre entre les niveaux d une même hiérarchie. Définition 8 (Hiérarchie d une dimension). Soit d i D une dimension du cube de données. Soit L i = {l 1,..., l m } les différents niveaux de d i. On dit que l k est moins spécialisé que l k, et on note l k i l k, ssi on peut regrouper les valeurs de l k pour obtenir des éléments de l k. Exemple 5. Soit la dimension T emps dont les niveaux de la hiérarchie sont {jour, mois, année}. On peut regrouper les jours pour former des mois (ou des années) et on peut regrouper des mois pour former des années. Nous avons donc, mois jour, année mois et année jour. Dans la suite, nous supposons que pour chaque dimension d i il existe un plus petit élément dans la hiérarchie L i et un plus grand élément dans L i qui est noté All Exemple 6. Dans l exemple précédent, le niveau jour peut être considéré comme étant le plus petit élément. Le plus grand élément étant All. Noter qu en présence de hiérarchies, le nombre de cuboïdes d un cube de données est égal à D i=1 L i. Nous définissons maintenant une relation d ordre entre cuboïdes comme suit. Définition 9 (Ordre entre cuboïdes). Supposons que chaque cuboïde c est représenté par un vecteur à D dimensions de la forme [l 1i,..., l D i ]. Avec l ki qui désigne un élément de la hiérarchie L k. Soient c et c deux cuboïdes. c est plus petit que c, on note c c, ssi pour tout 1 k D on a c [k] k c[k]. Exemple 7. Soient un cube C avec D = {T emps, produit}. La dimensions T emps forme la hiérarchie L T = {jour, semaine, mois, All} et la dimension produit forme la hiérarchie L 2 = {nomp, All}. Les relations d ordre sont les suivantes : jour 1 mois, jour 1 semaine, mois 1 All et semaine 1 All nomp 2 All Soit c = (mois, nomp ) et c = (jour, nomp ). Alors, c c car (1) c [1] = jour 1 c[1] = mois et c [2] = nomp c[2] = nomp. 7. Disponible à l URL http ://lpsolve.sourceforge.net/5.5/ 10

On peut voir facilement que le cube de données C muni de la relation d ordre définit un treillis. Par ailleurs, nous disposons des mêmes propriétés que celles que nous avons utilisées auparavant, à savoir : Si c c alors c peut être calculé à partie de c 8, et Si c c alors la taille de c est plus petite que celle de c. Exemple 8. Le treillis défini par (C, ) de l exemple précédent est décrit dans la figure??. Si Figure 4 Cube de données à 2 dimensions hiérarchisées. c est un cuboïde et si c[i] = All alors cela signifie que la dimension i n est pas présente dans c. Le lecteur intéressé peut consulter [?] pour plus de détails sur la prise en compte des hiérarchies et la modélisation sous forme de treillis des cubes de données ainsi obtenus. En conclusion de cette section, nous notons essentiellement que bien que les résultats présentés dans cet article et les expériences effectuées ne tiennent pas compte de la présence de hiérarchies dans les dimensions, ils sont facilement généralisables à ce cadre. 6 Stabilité Dans cette section, nous analysons la stabilité des solutions que l on propose. On entend par stabilité le fait qu une solution S calculée à un instant t voie ses performances quasiment inchangée à un instant t + 1 suite aux mises à jour du cube de données. Considérons un cuboïde q qui appartient à Q et un cuboïde s qui appartient à la solution calculée à l instant t tels que s est le plus petit ancêtre de q qui soit matérialisé (c.à.d q est calculé à partir de s). Si le facteur de performance fixé par l utilisateur est f, alors on sait que size(q) f size(s). On aimerait savoir quel est le nombre de tuples qu on doit insérer (ou supprimer) de s pour que le facteur de performance de q dépasse f +1. Nous analysons juste les opérations d insertion et de suppression puisque la modification est une combinaison des deux. Insertion L insertion de n tuples dans s engendre l insertion de m tuples dans q avec 0 m n. La pire des situations pour le facteur de performance correspond à m = 0. En effet, dans ce cas, la taille de s augmente mais pas celle de q. Le lemme suivant donne le nombre minimum de tuples à insérer dans s pour que le facteur de performance de q passe de f à f + 1. Lemme 3. Soient s et q deux cuboïdes tels que s est ancêtre de q et size(q) f size(s). Alors, il faut insérer au moins size(q) tuples dans s pour que le facteur de performance de q passe à f + 1. 8. Toujours en supposant que les seules mesures considérées sont celles qui sont algébriques. 11

Démonstration. La preuve est immédiate. Ajoutons n tuples à s et aucun à q. s peut atteindre une taille size(s) + n = f size(q) + n. Cette valeur dépasse (f + 1) size(q) dès que n dépasse size(q). Suppression En utilisant les mêmes arguments qu auparavant, on peut facilement voir que la suppression de n tuples de s peut provoquer la suppression de m tuples de q avec 0 m n. Dans ce cas, la pire des situations pour le facteur de performance correspond à m = n. En effet, dans ce cas, le rapport de diminution de taille de q est plus grand que celui de s ce qui a pour effet l augmentation du facteur de performance. Lemme 4. Soient s et q deux cuboïdes tels que s est ancêtre de q et size(q) f size(s). Alors, il faut supprimer au moins size(q) tuples de s pour que le facteur de performance de q f passe à f + 1. Démonstration. Enlevons n tuples à s et à q. Les tailles respectives deviennent size(s) n f size(q) n et size(q) n. Or f size(q) n size(s) n (f + 1)(size(q) n) si et seulement si nf size(q). Dans les deux types de mise à jour, nous voyons que le nombre de tuples à insérer (resp. à supprimer) pour détruire la stabilité d un élément s doit être au moins égal à la taille du cuboïde q (divisé par f dans le cas de la suppression) que l on veut optimiser. Ainsi, plus ce dernier est petit (en taille) et plus il sera exposé aux détériorations de performance. Nous concluons cette partie en faisant remarquer le fait que, généralement, les petits cuboïdes avec peu de dimensions atteignent assez rapidement leurs tailles finales (ex : le cuboïde Apex a une ligne et sa taille n évolue pas au grès des insertions et des suppressions) si on se limite à des opérations d ajouts. Ceci bien sûr n est pas toujours le cas (il suffit de considérer la dimension Temps qui est en perpétuelle évolution). Enfin, le fait que ce soit les petits cuboïdes qui soient touchés par la détérioration de performance est difficilement perceptible par l utilisateur. En effet, si le temps d évaluation d une requête passe d 1 seconde à 2 secondes, ceci est pratiquement invisible du côté de l utilisateur, pourtant le facteur de performance a doublé, alors que passer d 1 heure à 2 est bien plus pénalisant. Dans la partie expérimentations, nous rendons compte de ce phénomène en menant une analyse de la stabilité de nos solutions. Sous réserve de données dont les valeurs sont distribuées uniformément, nous pouvons montrer qu une solution peut être stable pour de nombreuses instances de Q. Plus précisément, nous pouvons définir la stabilité d une solution de la manière suivante : Définition 10. Soient T une table de faits et T une table obtenue à partir d opérations d ajouts et suppressions de tuples dans T. Soient Q et S deux sous-ensembles de DC(T ) tels que q Q, f(q, S) f. S est stable si et seulement si q Q, f(q, S) f + 1 pour la table T. Sous réserve de certaines hypothèses, nous pouvons montrer que S tend à être stable : Théorème 3. Soit {D i } i [1,D] un multi-ensemble. Soit T une table de faits dont les tuples sont tirées de manière aléatoire et uniforme dans D 1 D 2... D D. Soient Q et S deux sousensembles de DC(T ) tels que q Q, f(q, S) f. Si on ne fait qu ajouter des tuples à T de manière aléatoire uniforme, avec probabilité 1 2/ Q : Si q Q, size(q) > β ln Q, alors S est stable. Si T > βf ln Q (ln β + ln ln Q ), alors S est stable. Si on effectue moins de T 2f ln 4f insertions de tuples dans T, alors S est stable. 12

Démonstration. Nous ne donnons qu un schéma très bref de preuve pour étayer notre affirmation. Aprés un premier calculn pour n importe quel ensemble Q Q, il existe S S tel que size(s) < f size(q). Pour des raisons pratiques, s et q représentent size(s) et size(q). D aprés le lemme??, pour détruire la propriété de stabilité, il faut ajouter au moins q elements à S. Nous prouvons que cela est impossible car s est proche de sa valeur maximale m(s) = D j Dim(s) D j, c est-à-dire m(s) s < q avec probabilité 1 1/Q 2. L intuition est la suivante : si un cuboide Q est petit, alors Q et S sont presque saturé. De plus, si T est assez grand, les plus petits cuboides (de taille infèrieure à 64f 2 ln Q ) sont saturés. Ces deux affirmations sont vraies avec grande probabilité. La première étape consiste à montrer que les valeurs de s et q sont bien estimées. Ensuite, nous montrons que la manière de construire T implique que m(s) et q sont trés similaires. Enfin, il se trouve que m(s) s < q avec grande probabilité. Si on ajoute un nouveau tuple t = (t 1, t 2,..., t D ) à un cuboide V de manière aléatoire uniforme dans Dom(V ), alors la formule de Cardenas donne l espérance de la taille de n importe quel cuboide en supposant que T soit aussi construit dans le modèle indépendant et aléatoire. Pour tout cuboide V de taille v, on a : ( ( E(v) = m(v ) 1 1 1 ) ) T. (6) m(v ) On peut montrer que la variable aléatoire v a une valeur proche de sa moyenneavec grande probabilité. Plus précisémeent, en utilisant la borne de Chernoff, pour tout δ < 1, on a : Pr ( v E(v) > δe(v)) < 2 exp( E(v)δ 2 /2). (7) En supposant E(v) > 64f 2 ln Q et en prenant δ = 1/4f, on obtient ( Pr v E(v) > E(v) ) < 2 exp( 2 ln Q ) = 2 4f Q. (8) 2 Pour T assez grand, E(v) m(v )(1 exp( T /m(v )). Dans notre cas, on suppose que pour tout cuboide V, Dom(V ) = D i Dim(V ) Dom(D i). Soit t V la projection du tuple t sur les dimensions de V, c est-à-dire t V = (t i1,..., t i Dim(V ) ) avec Dom(D ij ) Dim(V ). Si t est choisit de manière aléatoire et uniforme dans D i=1 Dom(D i), alors pour tout cuboid V et pour tout V 0 Dom(V ), Pr(t v = V 0 ) = D i Dim(V ) 1/Dom(D i) = 1/Dom(V ). Il s en suit que la formule de Cardenas est valide dans notre cas pour tout cuboide. La fin de la preuve n est pas indiquée ici mais elle consiste en une étude de cas : m(s) > 2fq ou m(s) 2fq. Le premier cas s avère impossible avec nos hypothèses. Dans le deuxième cas, m(s) s m(s)( 1 1 ) < q. 2f 16f 2 7 Expérimentations Dans cette section nous montrons quelques unes des expérimentations que nous avons entreprises pour valider notre approche. Nous ne présenterons que celles relatives au cas où l on dispose d un ensemble Q que l on veut optimiser. D autres expériences validant le premier cas ont déjà été présentées dans [?]. Jeu de données : Nous avons travaillé sur la table US Census 1990 data, disponible à http ://kdd.ics.uci.edu/. Nous en avons exclu le premier attribut qui est une clé. La table de faits initiale contient 2.5 millions de tuples et 65 dimensions. Dans nos expériences, nous 13

n avons considéré les sous-tables USData10et USData20correspondant aux 10 et 20 premiers attributs. Un pré-calcul des tailles exactes a été fait pour tous les cuboïdes de USData10et USData20. Le temps d exécution des différents algorithmes mesure le temps mis pour construire les graphes de recherche et le temps de calcul de la solution S. Méthodes de génération de Q Les différentes mesures de performances d une solution S dépend en très grande partie des caractéristiques des requêtes cibles Q. En préambule, on peut remarquer que si Q ne contient que des gros cuboïdes, c est-à-dire q Q, size(q) T /f, la solution S = {c b } est une solution respectant la contrainte de facteur de performance et dont l espace mémoire est inférieure à f fois l espace mémoire de la solution optimale. Nous ne considérons donc pas ce type de requêtes fréquentes. Nous avons donc proposé 3 méthodes de génération aléatoire de Q qui traduise chacune d elle des caractéristiques précises : génération aléatoire uniforme (UNIF) : Toutes les dimensions ont la même probabilité d apparaître dans le cuboïde tiré au hasard, génération entre dimension 1 et dimension d max puis aléatoire uniforme (DMAX) : On se fixe un nombre maximal de dimensions. Pour i allant de 1 à d max, on choisit un cuboïde à i dimensions de manière aléatoire uniforme ; DESC : On itère le même processus que DMAX mais pour chaque choix aléatoire d un cuboïde q de niveau i, on ajoute à Q les 2 i cuboïdes {q j } j [1,2 i ] descendants de q, c est-àdire q j q. Cette procédure de tirage aléatoire permet de simuler les navigations du type Roll Up et Drill Down très courantes dans le cadre de l analyse en ligne. La méthode de génération UNIF est la plus simple et naturelle. Cependant, on peut montrer facilement qu une proportion constante des cuboïdes tirés avec cette méthode sont de dimension comprise entre D/2 D et D/2 + D. Les cuboïdes extrêmes, c est-à-dire petit ou grand en terme de dimension, sont improbables. Puisque les cuboïdes grands peuvent facilement être résumé par le cuboïde de base, il reste à proposer des méthodes de génération tendant à sélectionner des cuboïdes de petite dimension. C est l objectif de DMAX et DESC. La méthode DESC se justifie par le fait qu en pratique certains attributs sont plus fréquemment utilisés que d autres. 7.1 Etude de USData10 Nous avons considéré USdata10. La taille du cuboïde de base est de 52278 (une fois les doublons de la table de faits enlevés). Nous avons généré Q de manière aléatoire uniforme en faisant varier la cardinalité des cuboïdes cibles entre 4 et 1024. Nous avons comparé la mémoire de Q avec la mémoire de la solution optimale S opt ainsi que la solution retournée par PickFromf Ancestors pour la valeur f = 10. PickFromf Ancestors se comporte très bien par rapport à la solution optimale et le gain de mémoire par rapport à la matérialisation complète de Q est extrêmement important. Le véritable apport de PickFromf Ancestors par rapport à la programmation linéaire est le temps d exécution : pour PickFromf Ancestors, cela va de 0.01s ( Q =4) à 0.29s ( Q =1024). Or le programme linéaire exécuté sur CPLEX met de 0.1s ( Q =4) à 3366s ( Q =1024) 9. En dimension supérieure, la programmation linéaire prend beaucoup trop de temps. En dimension 20, PickFromfAncestors donne une solution en temps inférieur à la minute. Bien entendu, cela dépend de la valeur de f et de Q. C est l objectif de la section suivante. 9. LP Solve était incapable de résoudre des programme d une taille aussi grande. 14

Figure 5 Comparaison entre PickFromfAncestors et la solution optimale. 7.2 Etude de USData20 Nous avons mené un certain nombre d expériences sur ce jeu de données afin de mettre en évidence quelques propriétés. Ce jeu de données a un cuboïde de base qui contient 500K lignes. Pour chaque type de génération de requêtes, nous avons fait varier Q de 4 à 1024 par puissance de 4. Pour chaque valeur de Q, nous avons fait varier le facteur f de 2 à 16 en le doublant à chaque fois. Enfin, pour chaque combinaison des trois paramètres précédents, nous avons calculé la solution avec le graphe G ainsi qu avec le graphe partiel G p. Par construction, l espace mémoire de Q dépend de la méthode de génération. Par exemple, pour 1024 cuboïdes, Q est de l ordre de 6.10 7 pour les méthodes UNIF et DMAX pour d max = 10 et devient 5.10 6 pour les méthodes DMAX et DESC pour d max = 8. 7.2.1 Temps de calcul de S Les résultats des temps d exécution (exprimés en secondes) sont illustrés dans les figures?? à??. Ces courbes illustrent le gain en temps d exécution lorsque l on utilise G p au lieu de G. Le graphe de recherche partiel offre de très bon compromis en terme de temps de calcul et gain de mémoire. Il mène à une solution avec un temps de calcul environ 4 fois inférieur à celui du graphe de recherche complet avec un facteur de gain en mémoire comparable. Nous n avons rencontré qu une exception (cf. Figures?? et??). Dans ce cas-là, le graphe de recherche partiel résume mal car il propose une solution avec beaucoup de cuboïdes. Comme le temps de calcul O( V (G) S ) peut dépendre du nombre de cuboïdes de la réponse, il est peut être plus important pour G p si la solution qu il donne a une cardinalité plus grande que celle donné par G. En régle générale, le graphe G p est bien plus petit que G (degré maximal et nombre de sommets sont plus petits). Ceci explique la plus grande rapidité de l algorithme approché si on prend en entrée le graphe G p. 7.2.2 Gain de mémoire de S par rapport à Q Dans cette partie on décrit les gains en espace mémoire qu on obtient en faisant varier les quatre paramètres utilisés précédemment. Noter que les expériences décrites ici sont celles de la section précédente. Une première remarque consiste à noter le fait qu avec G on réduit toujours plus l espace mémoire (cf Théorème??). On note aussi que dans la plupart des cas (les 3 premiers), les ratios de réduction d espace mémoire en utilisant G ou G p sont comparables sauf dans le dernier (figure??) où l on a une nette différence. Rappelons que c est aussi le cas où le 15

Figure 6 Temps de calcul de S si Q généré parla méthode UNIF. Figure 7 Temps de calcul de S si Q généré par la méthode DMAX avec d max = 10. Figure 8 Temps de calcul de S si Q généré par la méthode DMAX avec d max = 8. Figure 9 Temps de calcul de S si Q généré par la méthode DESC avec d max = 8. 16

temps d exécution avec G était meilleur que celui avec G p (voir??). Ce qui est frappant, c est la différence des ratios de réduction de mémoire en fonction du type de génération de Q. En effet, lorsque beaucoup de requêtes de Q ont relativement beaucoup de dimensions, l ensemble Q est plus résumable. Figure 10 Gain de mémoire de S si Q généré par la méthode UNIF Figure 11 Gain de mémoire de S si Q généré par la méthode DMAX avec d max = 10. Figure 12 Gain de mémoire de S si Q généré par la méthode DMAX avec d max = 8. Figure 13 Gain de mémoire de S si Q généré par la méthode DESC avec d max = 8. 7.3 Un premier bilan génération de Q Hétérogénéïté de Q Q Résumable Temps de calcul de S UNIF oui oui faible DMAX8 oui non important DMAX10 oui oui faible DESC8 non oui faible Table 1 Comparaison Temps/Mémoire pour les différentes caractéristiques de Q. Le table?? dresse un bilan qualitatif des différentes expériences. Q est considéré comme hétérogène si chaque attribut a la même probabilité d apparition dans les cuboïdes requêtes. C est le cas pour toutes les méthodes de génération à l exception de DESC. 17

Le seul cas pour lequel Q ne semble pas résumable est lorsque Q est hétérogène et constitué uniquement de petits cuboïdes en terme de nombre d attributs. 7.4 Analyse de la stabilité Pour vérifier la stabilité des solutions retournées par notre approche nous avons conduit un certain nombre d expériences dont le principe est le suivant : On fixe un facteur de performance f, on fixe le nombre de requêtes dans la charge, puis on fait tourner notre algorithme sur différents fichiers de données fichier 1,..., fichier n tels que fichier 1 fichier n. Le fichier de départ fichier n peut représenter une table de faits ou un cuboïde de base. Pour chaque fichier i, on calcule une solution S i ainsi que, pour tous les éléments de Q, le facteur de performance f(q, S i 1 ). Autrement dit, on vérifie dans quelle mesure les performances de S i 1 se détériorent quand on insère un certain nombre de tuples pour passer de fichier i 1 à fichier i. Les critères de comparaison que nous avons retenus sont (1) le nombre de requêtes cibles Q dont le facteur de performance avec S i 1 dépasse le facteur f fixé par l utilisateur et (2) les dépassements moyen et maximal par rapport à f. Bien sûr, ces deux mesures sont calculées par rapport à fichier i. Nous avons répété ces expériences en faisant varier les requêtes cibles et les valeurs du facteur de performance. Nous présentons ici juste le cas où Q = 512. Les requêtes sont tirées d une manière aléatoire uniforme dans DC(T ) et un facteur de performance maximal fixé par l utilisateur qui est égal à f = 4 et à f = 8. Le jeu de données initial est USData-20. Figure 14 Requêtes ne satisfaisant plus le seuil fixé par l utilisateur. Figure 15 Les dépassements. La figure?? montre que le nombre de requêtes qui voient leur facteur de performance dépasser le seuil fixé par l utilisateur quand elles sont évaluées respectivement à une solution calculée précédemment. Par exemple, on a calculé une solution avec le fichier dont le cuboïde de base a une taille de 100k, puis on a compté le nombre de requêtes, parmi les 512 de la charge, dont le facteur de performance dépasse le seuil après avoir inséré 50k tuples dans le cuboïde de base. En passant de 100k à 150k, le nombre de dépassements est égal à à 48 et 31 quand f est égal à respectivement 4 et 8. Il est intéressant de noter que le nombre de dépassements est inversement proportionnel au ratio d augmentation de la taille du cuboïde de base. En effet, pour passer de 100k à 150k, nous avons ajouté la moitié de la taille de 100k, alors que pour passer de 450k à 500k, la ratio d augmentation est de 1/9. Une autre remarque peut être faite sur l impact combiné du facteur de performance et de la taille du cuboïde de base : en effet sur le graphe, on voit que pour les petites tailles, le nombre de dépassements et inversement proportionnel à la taille (ex : 48 avec f = 4 et 31 avec f = 8 à 150k) mais cette tendance va s inverser à partir d une certaine taille (ex : 5 avec f = 4 et 12 avec f = 8 à 500k). 18

Bien que le théorème?? soit valide sous certaines hypothèses et qu il ne considère que les dépassements 1, il permet d expliquer le fait qu une solution avec un paramètre f = 4 soit plus stable qu une solution avec un paramètre f = 8 si la table de faits est grande (ici, vers 400K). Si la table est plus petite, un certain nombre de cuboïdes requêtes ont une taille bien inférieure à leur taille maximale. La figure?? montre l évolution du rapport de taille q si la q taille du cuboïde de base augmente. Nous avons sélectionné arbitrairement quelques couples de cuboïdes (q, q) tels que q est ancêtre de q. Systématiquement, le rapport de taille augmente fortement quand la taille du cuboïde de base est petite puis tend à se stabiliser car les cuboïdes commencent à approcher leur taille maximal à force d ajouter des tuples. La figure?? montre les écarts entre le seuil fixé par l utilisateur et les facteurs de performances des cuboïdes qui dépassent ce seuil suite aux insertions. On note que pour les deux valeurs de f cet écart a tendance à décroître. On note cependant le même phénomène qu auparavant : à savoir que la différence des écarts moyens s inverse à partir d une certaine taille. En effet, au début, l écart moyen de f = 4 est supérieur à celui de f = 8, puis la tendance s inverse à partir de 250k. 350 300 Rapport q' / q 250 200 150 100 8;5 8;4 9;5 7;4 9;7 50 0 0 100000 200000 300000 400000 500000 Taille cuboide de base Figure 16 Evolution du rapport de tailles de différents paires de cuboïdes (q, q) telles que q q lors d ajouts de tuples. Les dimensions d une paire (q, q ) dont notés Dim(q ); Dim(q). La figure?? montre les écarts entre le seuil fixé par l utilisateur et les facteurs de performances des cuboïdes qui dépassent ce seuil suite aux insertions. On note que pour les deux valeurs de f cet écart a tendance à décroître. On note cependant le même phénomène qu auparavant : à savoir que la différence des écarts moyens s inverse à partir d une certaine taille. En effet, au début, l écart moyen de f = 4 est supérieur à celui de f = 8, puis la tendance s inverse à partir de 250k. 8 Conclusion Nous avons présenté dans cet article des techniques permettant de sélectionner les vues à matérialiser dans le cadre des cubes de données. L intérêt de notre approche est que le critère de sélection est basé sur le facteur de performance de l évaluation des requêtes non pas sur l espace mémoire requis. Nous avons présenté des méthodes exactes et approchées et pour chacune nous 19

avons prouvé sa performance. Nous avons conduit plusieurs expérimentations qui nous ont permis de confirmer la pertinence des choix que nous avons effectués. Nous comptons dans nos prochains travaux enrichir notre modèle selon plusieurs directions. Un premier axe serait d intégrer des requêtes plus générales, par exemple en considérant celles de la forme SELECT * FROM c WHERE c.a = valeur. Dans le modèle présenté dans cet article, l évaluation de cette requête se traduit par le parcours de c si ce dernier est matérialisé, ou bien on parcourt son plus petit ancêtre matérialisé. Pour optimiser ce type de requêtes, deux possibilités ont été envisagées dans la littérature : soit on a la possibilité d avoir un index sur l attribut A associé au cuboïde c (ou à son plus petit ancêtre matérialisé) (p. ex. [?]), soit c (ou son plus petit ancêtre) est partitionné horizontalement en fonction des valeurs de A (p. ex. [?]). Dans l une ou l autre des deux alternatives, le coût de la requête doit être adapté en conséquence. Un autre axe que nous comptons explorer est l intégration du coût de la maintenance de la partie matérialisée dans le même esprit que p. ex.[?,?]. Enfin, la possibilité d avoir des requêtes qui ont besoin de plusieurs vues (cf. [?,?]). Par exemple, la requête qui retourne les paires de produits dont le montant des ventes ont été égales lors d une même année est une requête qui nécessite une auto-jointure du cuboïde (Produit, Année, SUM(ventes)). Ce cas de figure est modélisé dans la littérature par des AND-OR-Graphs que nous comptons explorer pour adapter notre approche. Nous avons introduit la notion de stabilité et nous l avons testée sur des jeux de données. Nous envisageons de pousser l analyse de cette propriété en fonction des distributions des valeurs des différents attributs (distribution uniforme, loi en puissance, poissons...). Enfin, cette dernière propriété ne tient compte que du caractère dynamique des données, pas celui des requêtes. Or, il se peut qu au cours du temps, certaines requêtes considérées comme importantes ne le soient plus et inversement. Il serait alors important de disposer d algorithmes incrémentaux pouvant calculer efficacement les cuboïdes à matérialiser. C est un des axes que nous sommes en train d explorer. Références [Bay98] [BB03] R. Bayardo. Efficiently mining long patterns from databases. In SIGMOD Proceedings, 1998. X. Baril and Z. Bellahsene. Selection of materialized views : A cost-based approach. In Proceedings of CAiSE conference, 2003. [BBR08] L. Bellatreche, K. Boukhalfa, and P. Richard. Data partitioning in data warehouses : Hardness study, heuristics and ORACLE validation. In Proceedings of DaWaK 08 conference, 2008. [BCG01] D. Burdick, M. Calimlim, and J. Gehrke. Mafia : A maximal frequent itemset algorithm for transactional databases. In ICDE Proceedings, 2001. [BPT97] E. Baralis, S. Paraboschi, and E. Teniente. Materialized views selection in a multidimensional database. In VLDB Proceedings, 1997. [Chv79] V. Chvàtal. A greedy heuristic for the set covering problem. Mathematics of operation research, 4(3) :233 235, 1979. [GCB + 97] J. Gray, S. Chaudhuri, A. Bosworth, A. Layman, D. Reichart, M. Venkatrao, F. Pellow, and H. Pirahesh :. Data cube : A relational aggregation operator generalizing group-by, cross-tab, and sub totals. Data Mining and Knowledge Discovery, 1(1), 1997. [GHRU97] H. Gupta, V. Harinarayan, A. Rajaraman, and J.D. Ullman. Index selection for olap. In ICDE Proceedings, 1997. 20

[GKM + 03] D. Gunopulos, R. Khardon, H. Mannila, S. Saluja, H. Toivonen, and R.S. Sharm. Discovering all most specific sentences. ACM Transactions on Database Systems, 28(2) :140 174, 2003. [GM05] H. Gupta and I.S. Mumick. Selection of views to materialize in a data warehouse. IEEE TKDE, 17(1) :24 43, 2005. [GZ05] K. Gouda and M. Zaki. GenMax : An efficient algorithm for mining maximal frequent itemsets. Data Mining and Knowledge Discovery, 11(3) :223 242, 2005. [HMT09a] N. Hanusse, S. Maabout, and R. Tofan. Algorithmes pour la sélection de vues à matérialiser avec garantie de performance. In Actes des 5èmes journées francophones sur les enrepôts de données et analyse en ligne (EDA 09), 2009. [HMT09b] N. Hanusse, S. Maabout, and R. Tofan. A view selection algorithm with performance guarantee. In Proceddings of EDBT conference, 2009. [HRU96] [Kar72] [KM99] [MAD06] [PKM08] [SDN98] [TCFS08] V. Harinarayan, A. Rajaraman, and J.D. Ullman. Implementing data cubes efficiently. In SIGMOD Proceedings, 1996. R. Karp. Reducibility among combinatorial problems. In R. E Miller and J. W Thatcher, editors, Complexity of Computer Computations, pages 85 103. Plenum Press, 1972. H.J. Karloff and M. Mihail. On the complexity of the view-selection problem. In PODS Proceedings, 1999. N. Maiz, K. Aouiche, and J. Darmont. Sélection automatique d index et de vues matérialisées dans les entrepôts de données. In Proceedings de (EDA 06), 2006. T. Palparas, N. Koudas, and A. Mendelzon. On space constrained set selection problems. Data and Knowledge Engineering, 67(1), 2008. A. Shukla, P. Deshpande, and J. Naughton. Materialized view selection for multidimensional datasets. In VLDB Proceedings, 1998. Z. Talebi, R. Chirkova, Y. Fathi, and M. Stallmann. Exact and inexact methods for selecting views and indexes for olap performance improvement. In EDBT Proceedings, 2008. 21