Les Dépendances Fonctionnelles pour la Sélection de Vues dans les Cubes de Données Eve Garnaud, Sofian Maabout, Mohamed Mosbah LaBRI, CNRS UMR 5800, Université de Bordeaux 351, cours de la Libération, 33405 Talence {garnaud, maabout, mosbah}@labri.fr

Le traitement des requêtes analytiques (OLAP) se base sur deux hypothèses qui semblent contradictoires : d’une part on veut que les requêtes soient optimisées (le mieux c’est de les pré-calculer) et d’autre part on suppose que l’on ne connaît pas a priori les requêtes qui sont posées (difficile de les prévoir toutes car elles sont en nombre infini). Dans le présent travail, nous restreignons au cas particulier des cubes de données et à une classe particulière de requêtes (qu’on pourrait qualifier de requêtes de rapports). Malgré ce contexte restrictif, il n’est pas envisageable de matérialiser toutes les requêtes. Nous développons ainsi des techniques basées sur les dépendances fonctionnelles exactes et approximatives afin de sélectionner les meilleures requêtes à matérialiser. Au lieu de fixer une contrainte sur l’espace mémoire disponible, comme c’est fait dans la plupart des travaux, nous supposons une contrainte sur le temps d’exécution des requêtes. Les résultats théoriques sont accompagnés d’expérimentations montrant la faisabilité de notre approche. RÉSUMÉ.

OLAP query processing assumes two seemingly contradictory requirements: on one hand query processing should be fast (thus, queries pre-precomputation) and on another hand queries are assumed to be submitted in an ad hoc manner making workload usage for optimization sometimes not effective (we cannot materialize an infinite number of queries). Thus, in this paper we address the specific case of data cubes and a special class of queries corresponding somehow to report queries. We present techniques to select the queries to be materialized with the help of exact and approximate functional dependencies (FD’s). In contrast to most of the previous approaches, we take a user instead of a DBA point of view: rather than fixing the available storage space and minimizing queries cost, we fix the maximal queries cost and we minimize the required storage space. The conducted experiments show the effectiveness of our results. ABSTRACT.

MOTS-CLÉS :

Dépendances fonctionnelles, sélection des vues à matérialiser, cube de données.

KEYWORDS:

Functional dependencies, materialized views selection, data cube.

Journal of Decision Systems. Volume 21 – n˚1/2012, pages 1 à 24

2

Journal of Decision Systems. Volume 21 – n˚1/2012

1. Introduction La quantité d’information stockée par les entreprises étant de plus en plus importante, le travail d’analyse et d’exploitation de ces informations tend à devenir souvent long et complexe. Il est donc nécessaire d’optimiser ces traitements. Une interface sous forme de cube de données permet de gérer efficacement ce problème puisqu’il est possible de choisir de ne matérialiser qu’une partie des cuboïdes qui le composent. Reste à savoir quelle est la meilleure partie à stocker pour répondre, dans un temps minimum, à toutes les requêtes. Nous développons donc une technique basée sur les dépendances fonctionnelles pour caractériser les cuboïdes les uns par rapport aux autres et ainsi trouver la meilleure solution à ce problème. Cette solution est optimale dans le sens où, étant donné un facteur de performance f ≥ 1, on peut répondre à toutes les requêtes posées sans que le coût de calcul de chaque requête ne dépasse de plus de f fois le coût de calcul si tous les cuboïdes étaient matérialisés. Il serait trop couteux en terme d’espace mémoire et de coût de maintenance de stocker tous les cuboïdes, c’est pourquoi une sélection s’impose. Nous prouvons que ce problème de sélection est NP-difficile, cependant, nous sommes en mesure de caractériser précisément, grâce aux dépendances fonctionnelles, les sous-ensembles de cuboïdes solutions et cela, quel que soit le f fixé par l’utilisateur. Cette caractérisation nous permet de réduire l’espace de recherche de la solution pour ainsi accélérer le temps de la sélection et assurer son optimalité. Dans la section suivante, nous revoyons quelques propositions de l’état de l’art autour de cette problématique pour constater que, à notre connaissance, la garantie de performance a rarement été prise en compte. Afin de mieux formaliser le problème, nous présentons dans la section 3 quelques notations et définitions originales nous permettant de mieux comprendre les enjeux du problème. Ensuite, nous montrons, dans la section 4, que cette question de sélection des cuboïdes peut être résolue à l’aide des dépendances fonctionnelles exactes qui existent entre les différentes dimensions du cube pour trouver une solution répondant au facteur f = 1. Nous prouvons que ce problème est NP-difficile. Nous proposons donc des algorithmes gloutons permettant de répondre efficacement à la demande de sélection. Nous étendons ensuite nos lemmes et propositions au cas où f > 1 grâce aux dépendances fonctionnelles approximatives. Nous montrons ensuite l’efficacité des algorithmes proposés grâce à quelques expérimentations. Les différents axes de recherche que nous souhaiterions traiter sont développés dans la section 7.

2. Travaux Relatifs L’optimisation de requêtes dans les cubes de données grâce à la sélection de vues à matérialiser est une question déjà souvent étudiée mais à notre connaissance, peu se sont intéressés à l’aspect garantie de performance.

DF’s et matérialisation partielle des cubes

3

Le problème que la plupart des articles cherche à résoudre est le suivant : étant donnés un cube de données C, un ensemble de requêtes Q et un espace mémoire de taille b, trouver l’ensemble des vues S à matérialiser en respectant la contrainte b pour répondre à toutes les requêtes de Q dans un temps minimum. On parle donc ici de solution optimale lorsque celle-ci a une taille inférieure à b et qu’aucune autre sélection de cuboïdes occupant moins d’espace mémoire n’a un coût total inférieur à celui de cette solution. (Li et al., 2005) ont utilisé des techniques de programmation linéaire pour résoudre exactement ce problème à l’aide de solveurs tels que CPLEX. On peut facilement adapter les algorithmes afin de prendre en compte, non pas une borne sur l’espace mémoire, mais plutôt le facteur de performance respecté par chaque requête. Mais, le problème étant NP-difficile (nous le prouvons dans la section 4) ce procédé trouve la solution optimale dans un temps non borné. Notre caractérisation permet de réduire l’espace de recherche de la solution et donc de diminuer les coûts de calcul de celle-ci. Un des premiers algorithmes proposant une solution approchée est celui de (Harinarayan et al., 1996). Leur solution garantit un bénéfice d’au moins 63% par rapport à la solution optimale. Le gain d’une solution est la différence entre le coût des requêtes lorsque seul le cuboïde de base est stocké moins le coût des requêtes lorsqu’un sous-ensemble S est stocké. Cependant, (Karloff et al., 1999) ont montré que la garantie sur le gain ne donne aucune assurance sur le coût de la solution globale. Notre caractérisation se base précisément sur le coût de chaque requête, on évite donc ce genre de problème. Une autre approche développée par (Kotidis et al., 1999) consiste à matérialiser les vues les plus pertinentes à un instant donné. On répond ainsi mieux au besoin d’analyse pour l’aide à la décision puisque le système s’adapte, en temps réel aux requêtes mais, de ce fait, si ce sontPtoujours les mêmes n requêtes qui sont posées en suivant n un cycle régulier et que i=1 |qi | > b où |qi | est la taille de la vue correspondant à la requête qi alors le système ne se trouvera jamais dans un état "stable". Or nous devons considérer le temps de mise à jour de la sélection et c’est donc pour cette méthode un inconvénient. Ce problème ne se pose pas avec notre approche puisque les dépendances fonctionnelles définissent la structure sémantique de la base de données et celle-ci ne change pas lorsque l’on effectue les opérations de maintenance "classiques". Plusieurs méthodes ont été développée pour faire un "résumé" du cube. Cela permet de réduire la taille du cube tout en assurant une performance maximale pour toutes les requêtes. On peut citer notamment (Casali et al., 2009), (Lakshmanan et al., 2002), (Wang et al., 2002) et (Raïssi et al., 2010) mais toutes ces approches considèrent, non pas les cuboïdes comme c’est le cas ici, mais chaque tuple du cube de données pour savoir s’il doit ou non être matérialisé. L’article de (Hanusse et al., 2009a) s’intéresse au même problème que le nôtre. Ils définissent, dans le cube, des cuboïdes dits maximaux qu’il faut matérialiser pour respecter la contrainte de performance. Leur solution cependant ne permet d’obtenir

4

Journal of Decision Systems. Volume 21 – n˚1/2012

qu’une approximation de la solution optimale relativement à f dans le sens où elle peut être f fois plus volumineuse. Nous détaillons cette méthode dans la section 6 et nous comparons nos résultats.

3. Préliminaires Nous commençons par présenter quelques notations et définitions qui seront utilisées tout au long du papier. Afin de mieux visualiser l’entrepôt de données, on utilise la modélisation multidimensionnelle qui permet de représenter les données sous forme d’un cube comme proposé par (Gray et al., 1997). Pour simplifier la présentation, nous allons considérer un schéma constitué uniquement d’une table de faits. Chaque attribut est une dimension du cube. Le cube Cube obtenu à partir d’une table de faits T est défini par une requête de la forme SELECT FROM GROUP BY

dimensions, mesures T CUBE(dimensions)

dimensions représentent les attributs de la table T et mesures représente un ensemble de fonction d’agrégation distributives telles que COUNT, ou SUM. Cette requête est équivalente à l’union de toutes les requêtes où GROUP BY est appliqué à un sousensemble des dimensions. Ainsi, si n est le nombre d’attributs, le nombre de requêtes correspondant au cube est 2n . Chaque résultat de ces requêtes est appelé cuboïde ou vue. Le cube est donc un ensemble des cuboïdes (ou vues). On pose n = |Dim(Cube)| où Dim(Cube) est l’ensemble des n dimensions du cube. Dans cet article, nous considérons la situation où l’on ne dispose pas de charge (workload), e.g. toutes les requêtes peuvent être posées sur les vues de façon equi-probable. Pour répondre à une requête, il suffit de parcourir une seule vue (i.e. un cuboïde matérialisé), c’est pourquoi on parle indifféremment de vue, de cuboïde et de requête. Les requêtes sont de la forme : SELECT FROM GROUP BY

attributs, mesure T attributs

Dans un travail futur, nous comptons considérer des requêtes munies d’une clause WHERE (plus proches de la réalité des analyses OLAP) pour lesquelles seuls certains tuples d’une vues seront retournés. Il faut pour cela utiliser les dépendances fonctionnelles conditionnelles et nous ne matérialisons pas les vues dans leur ensemble mais seulement quelques tuples utiles à l’analyse. Il s’agit ici de valider l’utilité des dépendances fonctionnelles pour caractériser les solutions au problème de sélection de vues à matérialiser, nous ne considérons donc que cette classe de requêtes "simples".

DF’s et matérialisation partielle des cubes

5

Soit  la relation d’inclusion des dimensions entre les cuboïdes, < Cube, > forme le treillis que nous allons considérer. Définition 1 (Ordre partiel du treillis). Soit  un ordre partiel entre les vues du treillis < Cube, >. Pour deux vues u et v, v  u si et seulement si on peut répondre à toute requête posée sur v en utilisant uniquement la vue u. On peut définir ainsi, pour un élément a du treillis : – l’ensemble de ses ancêtres : Aa = {b | a  b}, on a Dim(a) ⊆ Dim(b) – l’ensemble de ses descendants : Da = {b | b  a} – l’ensemble des parents : Pa = {b | a  b, @c | a  c∧c  b}, on peut en déduire |Dim(b)| = |Dim(a)| + 1 Pour optimiser les requêtes sur le cube, l’idéal serait de calculer et stocker tous ses cuboïdes. Mais cette solution n’est pas viable du fait de l’espace mémoire trop important qu’elle occuperait et la nécessité de mettre à jour plusieurs de ses cuboïdes à la moindre modification de la table de faits ce qui prendrait trop de temps. En pratique, seul un sous-ensemble S des cuboïdes sera matérialisé. Nous cherchons à savoir quel est le meilleur sous-ensemble qui nous permet de répondre à toutes les requêtes en respectant le facteur de performance f tout en utilisant un minimum d’espace mémoire. Comme dit précédemment, les requêtes que l’on considère consistent simplement à retourner le contenu d’un cuboïde. Lorsque celui-ci est déjà pré-calculé, alors le temps de la réponse est proportionnel à sa taille puisqu’il suffit juste de le parcourir. Quand par contre il n’est pas stocké, il faut chercher le plus petit (en termes de taille) de ses ancêtres stockés et l’utiliser pour évaluer la requête. Il existe essentiellement deux méthodes pour évaluer les requêtes avec GROUP BY (Graefe, 1993) et (Chaudhuri, 1998), (1) trier la table pour constituer les groupes puis effectuer les opérations d’agrégation pour chaque groupe. On se retrouve donc avec un coût de l’ordre de m log m avec m qui est la taille de la table ou bien (2) on utilise le hachage ce qui permet d’atteindre un coût linéaire de l’ordre de m. Nous allons supposer l’utilisation du hachage et donc, le coût minimal d’une requête q, noté |q|, est le nombre de tuples de la vue à laquelle elle se rapporte. Nous donnons maintenant le modèle de coût d’une requête en fonction de l’ensemble S des cuboïdes matérialisés. Définition 2 (Modèle de coût). Soit S ⊆ Cube l’ensemble des cuboïdes matérialisés. C(q, S), le coût d’une requête q respectivement à S, est défini par minw∈Aq |w| avec w ∈ S et |w| est le nombre de tuples de la vue w ancêtre de q. Le lecteur aura noté que nous confondons taille mémoire d’un cuboïde avec le nombre de ses tuples. En effet, pour être plus précis, la taille d’un cuboïde correspond à la place mémoire occupée par un tuple multipliée par le nombre de tuples. Mais, afin de ne pas alourdir davantage les calculs, nous ne considérons que le nombre de tuples pour définir la taille d’un cuboïde comme cela a été fait dans la plupart des articles de référence et notamment par (Harinarayan et al., 1996). A partir du coût calculé pour une requête, on peut déduire son facteur de performance.

6

Journal of Decision Systems. Volume 21 – n˚1/2012

Définition 3 (Facteur de performance). Soit S ⊆ Cube l’ensemble des vues matérialisées. Le facteur de performance d’une requête q sur S est donné par F P (q, S) = C(q, S) ÷ |q| où |q| = C(q, Cube) est le coût minimal de q. Exemple 1. Soit la table de fait T ci-dessous (nous allons l’étudier tout au long de l’article afin d’illustrer nos propos). Nous avons quatre attributs A, B, C et D, donc le cube que nous considérons a quatre dimensions. La mesure ici importe peu, c’est pourquoi nous ne la notons pas pour le pas alourdir les schémas. A 1 2 3 4

B 1 1 2 2

C 1 1 1 1

D 1 1 1 2

Figure 1. Exemple de table de faits.

Considérons le cube Cube défini par SELECT FROM GROUP BY

A, B, C, D T CUBE (A, B, C, D)

C est composé de 24 = 16 cuboïdes. Le cuboïde de base cb est la table T elle-même, le cuboïde A contient 4 tuples tandis que le cuboïde BC n’est composé que des 2 tuples (B = 1, C = 1) et (B = 2, C = 1). Supposons que les cuboïdes matérialisés sont S = {ABCD, BCD, BC, CD}. Soit la requête q SELECT FROM GROUP BY

D T D

Pour évaluer cette requête, nous pouvons utiliser soit le cuboïde ABCD soit BCD ou encore CD (ce sont les seuls ancêtres de D qui sont stockés). |CD| = 2, |BCD| = 3 et |ABCD| = 4. Puisque CD est le plus petit, nous avons donc intérêt à l’utiliser comme suit SELECT FROM GROUP BY

D CD D

Nous avons donc C(q, S) = 2 et q vérifie le facteur de performance f = 1.

DF’s et matérialisation partielle des cubes

7

Nous introduisons maintenant les définitions relatives aux dépendances fonctionnelles que nous utilisons dans cet article. Les DF’s exactes comme approximatives ont été largement étudiées par le passé. Cependant, notre recherche bibliographique nous a montré que plusieurs mesures d’approximation ont été définies dans la littérature et à notre connaissance, aucune n’est équivalente à celle que nous présentons ici. Définition 4 (DF approximative). Soient R un schéma relationnel, X et Y deux sousensembles de R. On dit que l’instance r de R satisfait la dépendance fonctionnelle |X| X → Y avec une confiance c ≤ 1 ∈ Q si et seulement si |XY | = c où |X| est le nombre de tuples (ou la taille) de X et |XY | la taille de XY . On note dans ce cas, r |= X → Y (c). On dit que la dépendance fonctionnelle X → Y est exacte si nous avons c = 1, sinon, elle est approximative. Exemple 1 (Suite). Reprenons la table illustrée par la Figure 1. Parmi les dépendances que cette table satisfait, on trouve :A → B(1), B → C(1). En effet, connaissant la valeur de l’attribut A (ou B dans le second exemple), on peut déduire la valeur de B (ou C pour le second exemple). On a également C → D(1/2) et C → B(1/2) puisqu’une valeur de C est associée à 2 valeurs de D ou de B. Le lecteur peut remarquer que les deux dernières dépendances ont la même confiance alors que pour les autres approches qu’on rencontre dans la littérature, C → D est "plus correcte" que C → B car, pour qu’elle soit exacte, il suffit de supprimer un seul tuple (le dernier). Alors que pour C → B, il faut supprimer les deux derniers tuples. Intuitivement, la confiance d’une dépendance approximative X → Y reflète le nombre moyen de valeurs de Y qui sont associées à chaque valeur de X. Il est à noter également que X → Y (c) nous indique qu’une requête portant sur l’attribut X peut être évaluée à partir de son ancêtre XY avec un facteur de performance f = 1/c. Plusieurs définitions de dépendances approximatives ont été proposées dans la littérature notamment par (Giannella et al., 2004) et (Kivinen et al., 1995). Dans ces travaux, les auteurs expriment les DF’s approximatives en fonction de leur distance par rapport à la dépendance exacte. L’approche développée par (Kivinen et al., 1995) parle d’une mesure d’erreur de la dépendance pour se ramener à une DF exacte alors qu’ici, nous ne sommes pas dans un contexte de vérification ou de validation DF’s sur une instance donnée r de R mais nous cherchons à dégager de l’information utile pour évaluer les requêtes. Malgré nos recherches bibliographiques, nous n’avons pas trouvé de travaux ayant étudié le type de dépendances définies ci-dessus. Ceci nous a poussé à vérifier les axiomes d’Armstrong pour ce "nouveau" type de dépendances. Lemme 1 (Réduction). X → Y (c1 ) et X → Z(c2 ) alors X → Y Z(c3 ) où c3 ≤ min(c1 , c2 ). |X| |X| a |XY | = b et |XZ| |X| a |XY Z| = d avec d ≥

Preuve. Soient

= ac .

On sait que

max(b, c, |Y Z|), donc on a

|X| |XY Z|

≤ min( ab , ac ).

8

Journal of Decision Systems. Volume 21 – n˚1/2012

En effet, il est facile de remarquer qu’une requête évaluée à partir d’un de ses parents a un facteur de performance plus petit que si elle est évaluée à partir d’un ancêtre situé plus haut dans le treillis puisque ce dernier a une taille plus grande. On a X  XY  XY Z et X  XZ  XY Z et donc F P (X, XY ) > F P (X, XY Z). Dans notre exemple, nous avons vu que A détermine B et C avec une confiance |A| |A| |A| = |AC| = 1 mais aussi |ABC| = 1 ≤ 1. égale à 1. En effet, nous avons bien |AB| On peut vérifier de la même façon que C → B(1/2) ∧ C → D(1/2) ⇒ C → BD(c) avec c = 1/3 ≤ 1/2. Lemme 2 (Transitivité). X → Y (c1 ) et Y → Z(c2 ) alors X → Z(c3 ) où c3 ≥ c1 × c2 . Preuve. (par l’absurde) On suppose |XZ| >

|XY |×|Y Z| |Y |

≥

|XY Z|×|Y | |Y |

|X| |XZ|




|XY | |X|

× |Y|YZ| | ⇔

= |XY Z| or, on sait que |XZ| ≤ |XY Z| donc il

y a une incohérence et on peut en déduire qu’on a bien

|X| |XZ|

≥

|X| |XY |

×

|Y | |Y Z| .

Sur notre exemple, A → C(1) et C → B(1/2). On a bien A → B(1 ≥ 1 × 1/2). Lemme 3 (Augmentation). X → Y (c1 ) alors ∀Z : XZ → Y (c2 ) avec c2 ≥ c1 . |XZ| Preuve. Posons DF1 : XZ → X(c3 = 1) car |XZ| = 1 et DF2 : X → Y (c1 ). Par transitivité, on déduit de DF1 et DF2 : XZ → Y (c2 ) avec c2 ≥ c3 ×c1 = 1×c1 = c1 .

Naturellement, plus on connaît de valeurs d’attributs, plus il est facile de déduire la valeur d’un dernier et donc plus la confiance de la dépendance est grande. Le lecteur peut vérifier que pour tout X et tout Y ensembles d’attributs, r |= X → Y (c) avec n1 ≤ c ≤ 1 où n est le nombre de tuples de r. Précisons maintenant, grâce aux dépendances fonctionnelles, les relations d’ordre que nous avons définies précedemment dans le treillis. Définition 5 (f _Ancêtre). Soient c un cuboïde portant sur l’ensemble d’attributs X et c0 un ancêtre de c portant sur l’ensemble d’attributs Y avec X ⊂ Y .1 c0 est un |Y | f _ancêtre de c si et seulement si |X| ≤ f i.e. le coût d’évaluation d’une requête posée sur Y ne dépasse pas de plus de f fois le coût de cette même requête sur X. Cet indice donné aux ancêtres c0 de tout cuboïde c nous permet de savoir avec quel performance une requête posée sur c peut être évaluée sur un ancêtre c0 . On peut donc aussi connaître la confiance de la dépendance liant les attributs de c aux attributs Dim(c0 ) \ Dim(c). 1. Pour ne pas alourdir les notations, nous parlons indifféremment d’un cuboïde c ou de ses attributs avec le même vocabulaire.

DF’s et matérialisation partielle des cubes

9

Exemple 1 (Suite). Nous avons vu qu’une requête portant sur D peut être évaluée à partir de CD avec un facteur de performance f = 1, CD est donc un 1_ancêtre de D. En revanche, CD est un 2_ancêtre de C puisque |CD| |C| = 2. En effet, on avait vu que C → D(1/2). Nous définissons maintenant la solution au problème que nous voulons résoudre. A savoir, l’ensemble des cuboïdes qu’il faut matérialiser étant donné un facteur de performance f ≥ 1 fixé par l’utilisateur pour avoir une solution de taille minimale. Définition 6 (Solution f _optimale). Une solution S est f _optimale ssi : 1) ∀q ∈ C, F P (q, S) ≤ f . Ce qui s’écrit également, ∃ q 0 ∈ S telle que q 0 est un f _ancêtre de q. 2) S est de taille minimale par rapport à tout autre ensemble solution S 0 qui satisfait la contrainte 1. La première condition nous assure que la contrainte de performance est bien respectée puisque chaque requête est évaluée à partir d’un de ses f _ancêtres avec donc un facteur de performance inférieur ou égal à celui fixé par l’utilisateur. On dit dans ce cas que la solution est f _correcte. La seconde condition précise l’optimalité, en terme d’espace mémoire, de notre solution. Il n’existe pas de solution plus petite qui respecte la même contrainte de performance. Intuitivement, la solution que nous cherchons permet d’évaluer chaque requête à partir d’un ancêtre matérialisé dont la taille ne dépasse pas f fois la taille du résultat de la requête. D’une manière équivalente, sachant que si la requête elle-même est déjà matérialisée alors on aurait le coût minimal, notre solution permet d’avoir un coût au plus f fois supérieur au coût minimal. Dans les sections suivantes, nous détaillons pas à pas comment trouver une solution 1_optimale (section 4) et f _optimale (section 5) à l’aide des dépendances fonctionnelles.

4. DF’s Exactes et Solution 1_optimale Commençons par caractériser la solution 1_optimale. C’est-à-dire que l’on cherche une solution dont le coût total serait le même que si on matérialisait tous les cuboïdes. On souhaite cependant trouver une solution de taille minimale. Étudions le lien entre dépendances fonctionnelles "exactes" et solution 1_optimale par le biais de quelques lemmes et propositions. Définition 7 (Cuboïde clos). X est clos si et seulement si ∀Y | X ⊂ Y ⇒ |X| < |Y |. Autrement dit, tous les ancêtres de X ont une taille strictement supérieure à celle de X, i.e. X n’a pas de 1_ancêtre. On peut l’écrire aussi @X 0 | X → X 0 (c = 1).

10

Journal of Decision Systems. Volume 21 – n˚1/2012

Définition 8 (Fermeture d’un ensemble d’attributs). Soient F un ensemble de dépendances fonctionnelles exactes et X un ensemble d’attributs. La fermeture de X par rapport à F, notée X + est l’ensemble des attributs A tels que F |= X → A(1). Exemple 1 (Suite). Dans notre exemple, C est de taille 1 et tous ses ancêtres sont de taille au moins 2, il n’a pas de 1_ancêtre, il est donc clos. D par contre n’est pas clos puisque |D| = |CD| et donc D → C(1), ce qui nous donne D+ = CD. Lemme 4. X est clos si et seulement si X + = X. Preuve. ⇒ : si X est clos alors, par définition, ∀Y tel que X ⊂ Y (i.e. Y ∈ AX )) on a |X| < |Y | (X n’a pas de 1_ancêtre). Ainsi, |X| |Y | < 1. D’où, X 6→ Y (1) et donc X + = X. ⇐ : Si X + = X alors @A | X ⊂ A et F |= X → A(1). Ainsi, ∀A, donc, |X| < |A|. D’où X qui est clos par définition.

|X| |A|

< 1 et

Revenons plus concrètement au problème de sélection des vues à matérialiser pour répondre à toutes les requêtes Q de Cube en optimisant le temps de maintenance sur le cube de données sans pour autant perdre en performance. On cherche donc une solution 1_optimale. Puisqu’un cuboïde clos a une taille strictement inférieure à celle de tous ses ancêtres, il semble pertinent de le matérialiser pour trouver la solution 1_optimale respectant bien le facteur de performance. Proposition 1. Soient F1 l’ensemble des cuboïdes clos et S la solution 1_optimale au problème de sélection de vues. On a alors S = F1 . Preuve. Soit S la solution 1_optimale au problème de sélection de vues. Supposons qu’il existe un cuboïde c ∈ S non clos. c est non clos donc il existe un ancêtre c0 de c tel que |c| = |c0 |. Le coût d’évaluation d’une requête sur c est donc le même que le coût d’évaluation de la même requête sur c0 . Il est donc préférable de stocker uniquement c0 et non c puisque c0 permet de répondre à un plus grand nombre de requêtes. On procède de la même façon sur c0 s’il n’est pas clos non plus et ainsi de suite. c n’appartient donc pas à S et tous les cuboïdes de S sont des cuboïdes clos. Supposons maintenant qu’il existe un cuboïde c clos qui n’appartient pas à S. Pour évaluer une requête q posée sur c, il va donc falloir utiliser un ancêtre c0 de c appartenant à S. Or, étant donné que c est clos, on sait que |c| < |c0 | donc C(q, c0 ) > C(q, c). On en déduit naturellement que S n’est pas la solution 1_optimale si c 6∈ S. On voit donc que S contient tous les cuboïdes clos du treillis et uniquement ceux là. Exemple 1 (Suite). Avec la table de faits T de la figure 1, nous pouvons dessiner le cube de données à quatre dimensions A, B, C et D suivant :

DF’s et matérialisation partielle des cubes

11

ABCD 4

ABC

ABD4

4

AB4

AC 4

A 4

ACD 4

BCD 3

AD 4

BC 2

BD

B

C

D

2

1

CD 3

2

2

01 Figure 2. Cube de données construit à partir de T

En comparant la taille d’un cuboïde avec celle de ses parents, on voit que les cuboïdes clos sont C, BC, CD, BCD et ABCD. La solution 1_optimale consiste donc à matérialiser S = {C, BC, CD, BCD, ABCD} puisqu’aucun de leurs ancêtres n’a une taille égale à la leur et de ce fait, il serait plus couteux d’interroger un de ces ancêtre plutôt que les cuboïdes eux-mêmes directement. On a ici l’ensemble des dépendances fonctionnelles exactes suivant : Fexacte = {A → B(1), A → C(1), A → D(1), B → C(1), D → C(1)}. On note |S| la taille de la solution S, et on a, pour S la solution 1_optimale, |S| = 1 + 2 + 2 + 3 + 4 = 12 1, sa matérialisation est toujours indispensable. Pour cela, nous devons considérer tous ses f _ancêtres c0 ∈ c+ f pour savoir si, par transitivité, nous avons bien Qc ⊂ Qc0 . Toute solution f _optimale est donc composée uniquement de cuboïdes clos, ce qui est équivalent à dire que S ⊆ S ∗ . L’espace de recherche d’une solution f _optimale peut donc être réduit à l’ensemble des cuboïdes 1_clos puisqu’on a vu que S∗ = F1 . Accroître le facteur de performance nous permet donc de diminuer la taille de la solution. De cette façon, si l’espace mémoire est borné, comme c’est la cas dans la plupart des travaux antérieurs, nous pouvons augmenter progressivement la valeur de f afin de trouver une solution de taille raisonnable par rapport à cette nouvelle contrainte qui a le meilleur facteur de performance possible. Pour trouver une solution 1_optimale, il suffit de matérialiser tous les cuboïdes 1_clos. Il est donc naturel de penser que pour calculer une solution f _optimale, nous devons matérialiser l’ensemble de tous les cuboïdes f _clos. En effet, nous avons le résultat suivant. Proposition 4. Soit S une solution f _optimale, alors Ff ⊆ S. Preuve. D’après la proposition 3, on sait qu’il est suffisant de ne s’intéresser qu’aux cuboïdes de la solution 1_optimale pour savoir s’ils appartiendront ou non à la solution f _optimale. On cherche une solution S dont le coût d’exécution est au plus f fois supérieur à celui de la solution 1_optimale S ∗ . Par définition, un cuboïde f _clos c ∈ Ff n’a pas d’ancêtre dont la taille est moins de f fois supérieure à la sienne. Pour ne pas violer la contrainte de performance, il est donc indispensable de matérialiser tous les cuboïdes f _clos. On voit donc bien qu’une solution f _optimale contient tous les cuboïdes f _fermés, les autres cuboïdes de la solution étant des cuboïdes 1_fermés.

16

Journal of Decision Systems. Volume 21 – n˚1/2012

Voyons alors avec l’exemple suivant, pourquoi il n’est pas suffisant de ne matérialiser que les cuboïdes f _clos. Exemple 1 (Suite). Fixons le facteur de performance f = 2 pour le treillis des exemples précédents. Pour une solution 1_optimale, on matérialise les cuboïdes ABCD, BCD, BC, CD et C. Voyons alors, "à la main", s’il est nécessaire de tous les conserver pour la solution 2_optimale. – on a vu que C2+ = {BC, CD} donc on en déduit (et on peut l’observer sur le treillis) que |BC| = |CD| ≤ 2 × |C| donc il n’est plus nécessaire de conserver le cuboïde C qui peut être calculer à partir d’un de ces deux ancêtre. – |BCD| ≤ 2 × |BC| = 2 × |CD|, les cuboïdes BC et CD ne sont donc pas f _fermés et il ne semble plus indispensable de les matérialiser. Or BCD 6∈ C2+ donc nous devons choisir de stocker C, BC ou CD pour respecter la contrainte de performance. Puisque C est le plus petit cuboïde et le seul qui ne peut pas être évaluer à partir de BCD et que nous cherchons une solution de taille minimale, nous choisissons de le matérialiser. – |ABCD| ≤ 2 × |BCD| et ABCD ∈ CD2+ , BC2+ donc il n’est pas optimal de matérialiser BCD ou BC ni CD puisque ABCD appartient à la solution. Nous avons donc sélectionné pour la solution S2 2_optimale les cuboïdes C qui est 1_clos mais pas 2_clos et ABCD, le cuboïde de base. Nous avons |S2 | = 4 + 1 = 5. En suivant le même raisonnement pour une solution S4 4_optimale, on trouve S4 = ABCD et |S4 | = 4. On voit donc que, plus le facteur de performance augmente, plus la taille de la solution diminue. Le problème de sélection des cuboïdes à matérialiser étant NP-difficile, nous proposons l’algorithme 3 qui trouve une solution approchée. Il se base sur l’algorithme de recherche de l’ensemble couvrant de poids maximal. En effet, ces deux problèmes sont liés et, pour s’en convaincre, il suffit de considérer chaque cuboïde du treillis comme étant un nœud d’un graphe qui couvre l’ensemble des requêtes auxquelles on peut répondre à partir de celui-ci. On cherche donc à matérialiser un minimum de nœuds (ou plutôt un ensemble de taille minimale) pour couvrir toutes les requêtes. Détail de l’algorithme 3 : Nous avons vu qu’une solution f _optimale est composée de tous les cuboïdes f _clos (on les ajoute à la solution dès la première ligne de l’algorithme) et de quelques cuboïdes 1_clos. On reduit donc l’espace de recherche de la solution, space, à l’ensemble F1 \ Ff . Il faut maintenant que chaque cuboïde c ∈ F1 soit "couvert" par un élément de la solution, i.e. qu’on puisse répondre à une requête posée sur c en utilisant un f _ancêtre de ce dernier qui soit matérialisé. Puisque l’espace de recherche est composé d’éléments non couverts, nous devons progressivement le vider. Pour cela, nous cherchons l’élément qui couvre un maximum de requêtes et qui soit de la taille la plus petite possible (lignes 7 à 10). On définit ainsi le poids de chaque cuboïde. On initialise ce poids à 1 puisque, bien entendu, chaque cuboïde se couvre lui même (ligne

DF’s et matérialisation partielle des cubes

17

S ← Ff ; space ← F1 \ Ff ; 3 tant que space 6= ∅ faire 4 pmax ← 0 ; 5 pour chaque cuboïde c ∈ space faire 6 poids ← 1 ; 7 pour chaque d descendant de c et d ∈ space faire 8 poids + + ; 9 fin 10 poids ← poids ÷ |c| ; 11 si poids > pmax alors 12 pmax ← poids ; 13 candidat ← c ; 14 fin 15 fin 16 S ← S ∪ candidat ; 17 space ← space \ {candidat ∪ descendants couverts par candidat} ; 18 si @c ∈ space tel que c n’a pas d’ancêtre dans Ff alors 19 space ← ∅ ; 20 fin 21 fin 22 retourner S Algorithme 3 : Ensemble couvrant de poids maximal : une solution approchée 1 2

6). Celui qui obtient un poids maximal (on l’a noté en tant que candidat à la ligne 13) a donc le plus grand intérêt à être matérialisé (ligne 16). Il faut ensuite répercuter cet ajout en supprimant de l’espace de recherche ce cuboïde nouvellement dans S et tous ses descendants qui sont à présent couverts. Les cuboïdes ayant un f _ancêtre f _clos doivent être considérés de manière particulière. En effet, nous devons les étudier car ils peuvent avoir un poids maximal à un moment donné et nous permettre de nous approcher au mieux de la solution f _optimale mais en même temps, ils sont déjà couverts par un élément de la solution. C’est pourquoi, si, au bout d’un moment, il ne reste plus, dans l’espace de recherche, que des cuboïdes déjà couverts alors on le vide pour arrêter l’exécution de la boucle tant que (lignes 3 à 21) et nous avons notre solution. Voyons maintenant la complexité de l’algorithme : si tous les cuboïdes sont 1_clos et aucun n’est f _clos (sauf le cuboïde de base bien entendu) alors, à la ligne 2, space contient 2n − 1 éléments. A chaque tour de la boucle tant que, on supprime entre 2 et n − 1 éléments, soit en moyenne, (n + 1) ÷ 2 (si le candidat est au niveau 1 du treillis, il n’a qu’un seul descendant, ∅, et s’il est au niveau n − 1, il a n − 2 descendants). Il y a donc environ 2n+1 ÷ (n + 1) tours de boucle. Pour chacun, on regarde tous les éléments restants ainsi que leurs descendants, on a donc une boucle pour de taille inférieure à |space| × (n − 2) où n − 2, on l’a vu, est le nombre maximum

18

Journal of Decision Systems. Volume 21 – n˚1/2012

de descendants dans l’espace de recherche. Il ne reste plus qu’à exécuter le test de la ligne 18 dans un temps inférieur à |space| × (n − 1). Cet algorithme a donc une complexité théorique exponentielle mais dans la pratique, notre élagage de l’espace de recherche nous permet d’obtenir des temps de calcul très raisonnables (de l’ordre de la seconde pour des cubes à 15 dimensions). Nous détaillons cela dans la section suivante. Exemple 2. Cherchons la solution 1,5_optimale de notre exemple avec l’algorithme 3. Nous pouvons tout d’abord ajouter à S les cuboïdes ABCD et C puisqu’ils sont 1,5_fermés. L’espace de recherche est constitué des autres cuboïdes 1_fermés, ici space = {BCD, BC, CD}. On voit, avec le graphe 3, que BCD est le cuboïde qui a plus grand poids (p = 3 ÷ 3 = 1 puisqu’il couvre trois cuboïdes et il est de taille 3 alors BC et CD ont un poids de 0.5 : ils couvrent chacun un cuboïde et sont de taille 2). On ajoute donc BCD à la solution et tous les cuboïdes sont couverts, on a S = {ABCD, BCD, C}. On fait théoriquement ici une 3_approximation puisque le degré maximal observé dans le graphe est 3 mais on peut voir que, sur cet exemple, la solution retournée est bien la solution 1,5_optimale. BCD

BC

CD

noeuds candidats

BCD

BC

CD

noeuds couverts

Figure 3. Graphe de calcul des poids

Dans la section suivante, nous verrons l’utilité de l’élagage de recherche mais également, nous pourrons valider l’efficacité de notre solution approchée. Il est à noter que notre solution est approchée dans le sens où elle n’est pas de taille minimale mais notre caractérisation permet de s’assurer qu’elle est toujours f _correcte.

6. Expérimentations Dans cette section, nous présentons quelques expérimentations. Afin d’évaluer la qualité de notre algorithme approché, nous devons comparer la solution retournée avec la solution exacte. Pour ce faire, nous avons utilisé le solver lp-solve2 . Il s’est avéré (et ce n’est pas surprenant étant donné le grand nombre de variables à considérer) qu’il est impossible de terminer l’exécution dans des temps raisonnables (inférieurs à 4h) quand le nombre de dimensions est important. Nous avons donc restreint leur nombre à 7 et, dans ses conditions, notre algorithme s’exécute de façon quasi instantanée. 2. www.lpsolve.com

DF’s et matérialisation partielle des cubes

19

Soit S ∗ la solution optimale retournée par lp-solve. On sait que S ∗ = Ff ∪ s où Ff est l’ensemble des éléments f _clos et s un ensemble d’éléments 1_fermés. Notre approximation, trouvée grâce à l’algorithme de recherche de l’ensemble couvrant de poids maximal, ne porte que sur s. On note d le degré maximal du graphe décrit plus haut. On trouve donc une log(d)-approximation de s. Pour nos tests, on compare la taille de notre solution approchée à celle de la solution f _optimale lorsque f augmente. On note également, la taille occupée par les f _clos afin d’interpréter au mieux nos résultats et pour apprécier l’utilité de notre caractérisation dans l’élagage de l’espace de recherche. Cas d’étude 1 Nous étudions un premier cube dans lequel il y a très peu de dépendances fonctionnelles à utiliser. Il s’agit du jeu de données US Census 1990 (kdd.ics.uci.edu) que nous avons tronqué afin d’obtenir un cube à 7 dimensions. Le cube a 362275 lignes et tous les cuboïdes sont 1_clos. On constate (figure 4) que ces 128 cuboïdes sont également 1,5_closs, c’est pourquoi, lorsque f = 1.5, nous trouvons la solution 1,5_optimale. On remarque que, dans cet exemple, notre solution approchée se révèle être la solution optimale lorsque f < 3. En effet, dans ces cas là, l’espace de recherche comporte au maximum 10 cuboïdes si on ne considère pas les 1_clos pour lesquels on peut répondre à partir d’un cuboïde f _clos. Ensuite cependant, on note une importante chute du nombre de f _clos ce qui explique pourquoi les courbes représentant notre solution et la solution optimale commencent à se distinguer plus clairement.

Figure 4. Expérimentations sur le premier cube à 7 dimensions

20

Journal of Decision Systems. Volume 21 – n˚1/2012

Cas d’étude 2 Dans cet exemple tiré du jeu de données wisconsin breadth cancer data (archive.ics.uci.edu/ml/machine-learning-databases/breast-cancer-wisconsin/) auquel on a supprimé 4 dimensions afin de n’en avoir plus que 7, l’ensemble des dépendances fonctionnelles approximatives à exploiter est plus riche que sur l’exemple précédent. Le nombre de f _clos est donc beaucoup moins significatif ce qui implique que nous avons un espace de recherche plus important. Cela explique le fait que nos résultats sont moins proches, en terme d’occupation mémoire, de la solution optimale que précédemment. Le cube a 22494 lignes et 126 1_clos. L’espace de recherche étant naturellement plus grand, le solver lp-solve considère un grand nombre de variables et prend donc plusieurs heures pour s’exécuter notamment lorsque f ≥ 2 alors que notre algorithme retourne une solution après seulement quelques secondes. On peut noter cependant sur la figure 5 que la somme des tailles des f _clos et celle de la solution globale décroissent en suivant sensiblement le même coefficient lorsque f augmente. Ceci n’est pas surprenant puisque, quand on augmente la valeur de f , on peut se permettre d’utiliser des cuboïdes situés plus haut dans le treillis donc on stocke moins de cuboïdes. C’est ce que nous avons vu dans la section 5. De plus, les trois courbes restent relativement "parallèles". Le fait d’avoir plus de dépendances fonctionnelles à considérer implique que le nombre de descendants de chaque cuboïde devient considérable (déjà un maximum de 45 descendants 1_clos lorsque f = 1, 5 et jusqu’à 92 pour f = 4). Notre approximation se basant sur ce nombre, il est tout à fait prévisible d’observer de moins bons résultats sur cet exemple que dans le précédent.

Figure 5. Expérimentations sur le second cube à 7 dimensions

DF’s et matérialisation partielle des cubes

21

On a donc vu sur ces deux exemples que essentiellement deux facteurs sont à prendre en compte pour évaluer l’efficacité de notre méthode : – Le temps d’exécution : quelle que soit la taille de l’espace de recherche, il est de l’ordre de la seconde pour un cube à 7 dimensions avec notre algorithme. En revanche, il faut parfois attendre plusieurs heures avant d’avoir la solution optimale avec lp-solve puisque le nombre de variables influe sur la difficulté du calcul. – Le nombre de dépendances fonctionnelles à considérer : lorsque ce nombre est faible, notre résultat est très proche de l’optimal puisque l’espace de recherche et le nombre de descendants sont négligeables. On a vu cependant que lorsque ce nombre augmente, notre solution est plus "éloignée" de l’optimale même si elle reste très acceptable dans le sens où on sait borner sa déviation par rapport à la solution optimale. Comparaison avec les travaux sur les bordures A notre connaissance, seuls les travaux de (Hanusse et al., 2009b) traitent du problème de matérialisation partielle des cubes de données avec, comme principale contrainte, la performance de chaque requête. Voyons alors quels sont les cuboïdes qu’ils sélectionnent. Définition 11 (Petit cuboïde et bordure). Soit f > 1 le facteur de performance fixé par l’utilisateur. – Un cuboïde c est dit petit si |c| ≤ |cb |/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 Cube relativement à f . Leur solution f _optimale est l’ensemble des cuboïdes de la bordure. Exemple 2 (Suite). On a trouvé précédemment S1,5 = {ABCD, BCD, C} notre solution 1,5_optimale avec |S1,5 | = 8. Commençons par repérer les petits cuboïdes lorsque f = 1, 5. On trouve : |C| ≤ |BC| = |B| = |CD| = |D| ≤ |ABCD| ÷ 1, 5. On note ensuite que BC et CD sont les seuls à ne pas avoir de parents petits, ils sont donc maximaux et on a S = {ABCD, BC, CD} avec |S| = 8. Dans les deux cas, la contrainte de performance est bien respectée et nous avons bien des solutions de taille minimale même si la manière de le calculer implique des résultats très différents. En revanche, lorsque f = 2, nous obtenons S2 = {ABCD, C} alors que leur solution reste la même.

22

Journal of Decision Systems. Volume 21 – n˚1/2012

7. Conclusion et Travaux Futurs Nous poursuivons les travaux de (Hanusse et al., 2009b), ou plus récemment (Hanusse et al., 2011), sur la matérialisation partielle des cubes de données en considérant comme contrainte, non pas l’espace mémoire disponible pour la matérialisation comme c’est le cas dans la plupart des autres travaux, mais une contrainte sur la performance avec laquelle l’utilisateur veut que ses requêtes soient évaluées. Pour résoudre, en partie, ce problème nous avons établi quelques liens avec les dépendances fonctionnelles qu’elles soient exactes ou approximatives. Pour ces dernières, bien que des travaux assez anciens les aient déjà traitées (voir par exemple (Mannila et al., 1994) ou (Kivinen et al., 1995)), nos recherches bibliographiques ne nous ont pas permis de trouver des travaux qui utilisent la définition de dépendance approximative que nous avons proposée. En effet, la plupart des références utilisent la mesure g3 introduite dans (Kivinen et al., 1995) qui désigne le rapport entre le nombre minimum de tuples à supprimer d’une table et le nombre de tuples de celles-ci afin de rendre une dépendance exacte. Nous n’avons pas utilisé cette définition puisque la problématique visée n’est pas la même. En effet, nous voulons tirer d’une DF approximative une information utile pour caractériser les cuboïdes entre eux et nous ne sommes pas dans une optique d’analyse de la donnée en elle-même. Nous comptons cependant analyser dans nos futurs travaux les liens entre notre facteur d’approximation et ceux qu’on rencontre dans la littérature. Nous avons démontré que le problème de sélection des cuboïdes à matérialiser était équivalent au problème de recherche des dépendances fonctionnelles. Ces dernières pouvant être en nombre exponentiel en fonction du nombre d’attributs, ceci montre que notre problème est aussi exponentiel en nombre d’attributs. C’est pourquoi nous proposons un algorithme exact pour la recherche d’une solution 1_optimale et un algorithme d’approximation pour trouver une solution f _optimale. En effet, dans les cubes de données, notamment dans les schémas en étoile, le concepteur connaît les dépendances existant entre les niveaux de chaque hiérarchie. Ainsi, les 1_clos peuvent être calculés d’une manière statique. Nos expérimentations montrent des résultats encourageants ce qui ne nous interdit pas de chercher dans le futur des algorithmes polynomiaux en fonction, non pas du nombre d’attributs, mais du nombre de dépendances. Ceci est un autre axe que nous comptons explorer. Afin d’affiner encore notre élagage de l’espace de recherche et de caractériser au mieux notre solution, il serait intéressant d’identifier clairement quels sont les cuboïdes 1_clos qui sont stockés dans une solution f _optimale. Pour cela, nous devront étudier plus précisément tous les dépendances fonctionnelles approximatives et, peut être, affiner notre définition. Nous pourrions ainsi caractériser exactement tous les éléments sélectionnés ce qui constitue une autre perspective à suivre. Les requêtes que nous avons considérées sont trop restreintes pour que nos solutions soient envisageables en pratique. En effet, dans le but d’intégrer des requêtes avec conditions de restriction (clause WHERE), nous voulons étudié les dépendances conditionnelles de (Diallo et al., 2010) et (Fan et al., 2011). Elles ont déjà été utilisées

DF’s et matérialisation partielle des cubes

23

dans (Bra et al., 1983) pour définir des décompositions horizontales de tables relationnelles. Ceci s’apparente aux travaux sur le partitionnement proposés par exemple dans (Bellatreche et al., 2004). Notre approche étant toujours centrée sur la performance des requêtes, nous devons encore adapter la définition pour qu’elle réponde mieux à notre besoin. Nous notons également le travail de (Ciaccia et al., 2003) qui ont utilisé les dépendances de cardinalité, un cas particulier des dépendances que nous avons considérées, pour estimer la taille des cuboïdes. Nous pourrons ainsi comparer nos résultats avec les cubes condensés proposés par (Wang et al., 2002) et cubes quotient de (Lakshmanan et al., 2002) et aussi l’étendre aux cubes clos de (Casali et al., 2003) ou encore aux skycubes de (Raïssi et al., 2010). Dans toutes ces approches, les auteurs étudient la structure de ces cubes particuliers qui constituent un résumé sans perte du cube complet. Il serait donc intéressant de voir dans quelle mesure les DF’s et leurs variantes peuvent caractériser ces propriétés sur les tuples.

Remerciements Nous remercions les rapporteurs anonymes pour leurs remarques constructives qui nous ont permis d’améliorer sensiblement la présentation de notre travail.

8. Bibliographie Bauer A., Lehner W., « On Solving the View Selection Problem in Distributed Data Warehouse Architectures », Proceedings of SSDBM Conference, IEEE Computer Society, p. 43-54, 2003. Bellatreche L., Schneider M., Lorinquer H., Mohania M. K., « Bringing Together Partitioning, Materialized Views and Indexes to Optimize Performance of Relational Data Warehouses », Proceedings of DaWaK Conference, vol. 3181 of LNCS, Springer, p. 15-25, 2004. Bra P. D., Paredaens J., « Conditional Dependencies for Horizontal Decompositions », Proceedings of ICALP Conference, vol. 155 of LNCS, Springer, p. 67-82, 1983. Casali A., Cicchetti R., Lakhal L., « Extracting semantics from data cubes using cube transversals and closures », Proceedings of KDD Conference, ACM, p. 69-78, 2003. Casali A., Nedjar S., Cicchetti R., Lakhal L., « Closed Cube Lattices », New Trends in Data Warehousing and Data Analysis, vol. 3 of Annals of Information Systems, Springer, p. 1-20, 2009. Chaudhuri S., « An Overview of Query Optimization in Relational Systems », Proceedings of PODS Conference, ACM, p. 34-43, 1998. Ciaccia P., Golfarelli M., Rizzi S., « Bounding the cardinality of aggregate views through domain-derived constraints », Data and Knowledge Engineering, vol. 45, n˚ 2, p. 131-153, 2003. Diallo T., Novelli N., « Découverte des dépendances fonctionnelles conditionnelles fréquentes », Actes de la conférence EGC, vol. RNTI-E-19 of Revue des Nouvelles Technologies de l’Information, Cépaduès-Éditions, p. 315-326, 2010.

24

Journal of Decision Systems. Volume 21 – n˚1/2012

Fan W., Geerts F., Li J., Xiong M., « Discovering Conditional Functional Dependencies », IEEE Transactions on Knowledge and Data Engineering, vol. 23, n˚ 5, p. 683-698, 2011. Giannella C., Robertson E. L., « On approximation measures for functional dependencies », Information Systems, vol. 29, n˚ 6, p. 483-507, 2004. Graefe G., « Query Evaluation Techniques for Large Databases », ACM Computing Surveys (CSUR), vol. 25, n˚ 2, p. 73-170, 1993. Gray J., Chaudhuri S., Bosworth A., Layman A., Reichart D., Venkatrao M., Pellow F., Pirahesh H., « Data Cube : A Relational Aggregation Operator Generalizing Group-by, Cross-Tab, and Sub Totals », Data Mining and Knowledge Discovery, vol. 1, n˚ 1, p. 29-53, 1997. Hanusse N., Maabout S., « A parallel algorithm for computing borders », Proceedings of the CIKM Conference, ACM, p. 1639-1648, 2011. Hanusse N., Maabout S., Tofan R., « Algorithmes pour la sélection des vues à matérialiser avec garantie de performance », Entrepôts de Données et l’Analyse en ligne, p. 107-122, 2009a. Hanusse N., Maabout S., Tofan R., « A view selection algorithm with performance guarantee », Proceedings of EDBT conference, vol. 360 of ACM International Conference Proceeding Series, ACM, p. 946-957, 2009b. Harinarayan V., Rajaraman A., Ullman J., « Implementing data cubes efficiently », Proceedings of ACM SIGMOD, ACM Press, p. 205-216, 1996. Karloff H., Mihail M., « On the complexity of the view-selection problem », Proceedings of PODS Conference, ACM, p. 167-173, 1999. Kivinen J., Mannila H., « Approximate Inference of Functional Dependencies from Relations », Theoretical Computer Science, vol. 149, n˚ 1, p. 129-149, 1995. Kotidis Y., Roussopoulos N., « DynaMat : a dynamic view management system for data warehouses », ACM SIGMOD Record, vol. 28, n˚ 2, p. 371-382, 1999. Lakshmanan L., Pei J., Han J., « Quotient cube : How to summarize the semantics of a data cube », Proceedings of VLDB Conference, VLDB Endowment, p. 778-789, 2002. Li J., Talebi Z., Chirkova R., Fathi Y., « A formal model for the problem of view selection for aggregate queries », Advances in Databases and Information Systems, Springer, p. 125-138, 2005. Mannila H., Räihä K.-J., « Algorithms for Inferring Functional Dependencies from Relations », Data and Knowledge Engineering, vol. 12, n˚ 1, p. 83-99, 1994. Raïssi C., Pei J., Kister T., « Computing closed skycubes », Proceedings of the VLDB Endowment, vol. 3, n˚ 1-2, p. 838-847, 2010. Shukla A., Deshpande P., Naughton J., « Materialized view selection for multi-cube data models », Proceedings of EDBT Conference, Springer, p. 269-284, 2000. Wang W., Feng J., Lu H., Yu J., « Condensed cube : An effective approach to reducing data cube size », Proceedings of ICDE Conference, IEEE, p. 155-165, 2002.