Master Extraction de Connaissances à partir des
publicité
Master Extraction de Connaissances à partir des Données Mémoire rédigé dans le cadre du master ECD Sélection dynamique d'index dans les entrepôts de données Stage réalisé au sein du Laboratoire ERIC 5 Avenue Pierre Mendès-France 69676 BRON Cedex - France http://eric.univ-lyon2.fr Stephane-gaston AZEFACK Master Recherche ECD [email protected] Encadrée par : Jérôme DARMONT Laboratoire ERIC - Université Lyon 2 [email protected] Remerciements Ce stage de master recherche a été réalisé au laboratoire ERIC (Equipe de Recherche en Ingénierie des Connaissances), au sein de l'équipe BDD (Base de Données Décisionnelles). Je tiens à remercier tous les membres de l’équipe, professeurs et doctorants qui ont contribué de près ou de loin à la réussite de ce travail. Plus particulièrement, j’aimerais remercier mon directeur de mémoire Jérôme Darmont, sans qui ce stage n’aurait pas vu le jour, pour ses conseils à chaque fois que je me suis incrusté dans son bureau sans rendez-vous. Mes remerciements vont également aux membres du jury, messieurs H. Briand, Y. Kodratoff et D.A Zighed. 2 Résumé Les entrepôts de données connaissent un très vif développement. Il devient important de réduire la charge de travail qu’un administrateur doit effectuer manuellement. Le but des systèmes auto-administratifs est de s'administrer et de s'adapter eux-mêmes, automatiquement, sans perte ou même avec un gain de performance. L’idée d’utiliser les techniques de fouilles de données pour extraire de ces mêmes données des connaissances intervenant dans le processus de sélection automatique d’index dans les entrepôts de données est une approche très prometteuse. Une première approche utilisant les motifs fréquents fermés a été proposée dans [Aou05] mais cette approche est statique et ne garantie pas l’aspect un dynamique, la charge pouvant évolue dans le temps. Dans ce mémoire, nous proposons une amélioration de l’approche proposée dans [Aou05] afin que le processus de sélection d’index soit dynamique en l’adaptant cette fois à une recherche incrémentale des motifs fréquents maximaux. Nous avons développé un outil, qui extrait de manière incrémental, les motifs fréquents maximaux à partir d’une charge de requête et à partir de ceux-ci, recommande une configuration d’index afin d'optimiser le temps d'accès aux Données. Mots clés : Bases de données, Entrepôts de données, Indexation, Fouille de données, Recherche de motifs fréquents incrémentale,Modèles de coût, Performance. Abstract With the wide development of databases in general and data warehouses in particular, it is important to reduce the tasks that a database administrator must perform manually. The aim of auto-administrative systems is to administrate and adapt themselves automatically without loss or even with a gain in performance. The idea of using data mining techniques to extract useful knowledge for administration from the data themselves is very important. First static approach was proposed in [Aou05]. In this paper, we propose an improvement of the approach suggested in [Aou05] in mean that the process of index selection been dynamic by adapting it this time to an incremental research of the maximum frequent item. 3 Tables des matières Remerciements ............................................................................................................... 2 Résumé ........................................................................................................................... 3 Chapitre 1 Introduction ................................................................................................ 5 1.1 Contexte et problématique ................................................................................ 5 1.2 Objectifs et contributions ................................................................................... 5 1.3 Organisation du mémoire .................................................................................. 6 Chapitre 2 Etat de l’art ................................................................................................. 7 2.1 Problème de sélection d'index........................................................................... 7 2.1.1 Travaux de Frank et al. .............................................................................. 8 2.1.2 Travaux de Choenni et al. .......................................................................... 9 2.1.3 Travaux de Whang - Algorithmes ADD and DROP .................................. 10 2.1.4 Travaux de Gündem ................................................................................ 10 2.1.5 Travaux de Chaudhuri et al. ..................................................................... 10 2.1.6 Travaux de Feldman et al......................................................................... 11 2.1.8 Travaux de Valentin et al. ........................................................................ 12 2.2 Recherche incrémentale des motifs fréquents ................................................ 13 2.2.1 Algorithme incrémental recherche de motifs fréquents fermes ............... 13 2.2.2 Algorithme incrémental de recherche de motifs fréquents maximaux ..... 14 Chapitre 3 Approche proposé.................................................................................... 15 3.1 Recherche de motifs fréquents ....................................................................... 15 3.1.1 Contexte et motivations............................................................................ 15 3.1.2 Algorithme Zigzag .................................................................................... 17 3.2 Démarche de sélection automatique d'index................................................... 19 3.2.1 Extraction de la charge ............................................................................ 20 3.2.2 Analyse de la charge................................................................................ 21 3.2.3 Construction du contexte d'extraction ...................................................... 22 3.3 Modèles de coût .............................................................................................. 23 3.4 Stratégie de sélection d'index bitmap de jointure ............................................ 23 3.4.1 Construction de l'ensemble d'index candidats.......................................... 23 3.4.2 Enregistrement et suppression des index candidat.................................. 24 3.4.3 Construction de la configuration d'index ........................................................ 25 Chapitre 4 Implémentation et Expérimentations ........................................................ 26 4.1 Implémentation................................................................................................ 26 4.1.1 Génération des motifs fréquents .............................................................. 26 4.2 Expérimentations............................................................................................. 29 Chapitre 5 Conclusion et perspectives ...................................................................... 31 Annexe A : Fichier de sauvegarde : base de connaissance .......................................... 32 Bibliographie.................................................................................................................. 33 4 Chapitre 1 Introduction 1.1 Contexte et problématique Aujourd’hui, l’information joue un rôle crucial dans le quotidien des entreprises. L’acquisition et l’analyse de cette information sont devenues des choix stratégiques incontournables dans les entreprises avec de plus en plus de grands volumes de données à manipuler. Ce développement a contribué au développement des entrepôts de données. Un administrateur en plus de la gestion de l’espace de stockage et de la gestion des performances, a également à sa charge la conception logique ou physique des bases de données. Il devient donc important de réduire la fonction d’administration [WMHZ02]. Pour améliorer les performances du système en minimisant les temps d'accès aux données l’administrateur peut mettre en œuvre la sélection des structures physiques tels que les index [FST88]. L'optimisation automatique de ces tâches donne lieu à des systèmes dits auto-administratifs avec comme objectif de s'administrer et de s'adapter eux-mêmes, automatiquement, sans perte de performance. Depuis quelques années, l'idée d'utiliser les techniques de fouille de données (data mining) pour extraire des connaissances utiles des données elles-mêmes, pour leur administration est exploité [Cha98]. Dans [Aou05] une approche basée sur la recherche des motifs fréquents fermés pour la sélection des index bitmap de jointure à été proposée. Cependant, cette recherche de motifs fréquents fermés reste statique et ne garantie pas encore l’aspect dynamique du processus de sélection d’index. C'est pourquoi nous étudions dans ce mémoire l'utilisation des techniques de fouille de données (recherche des motifs fréquents incrémentale) pour la sélection d’index. 1.2 Objectifs et contributions Notre objectif principal consiste à fournir des stratégies qui permettent de sélectionner une structure d’index efficace afin d'optimiser les performances des entrepôts de données en se basant sur la recherche incrémentale des motifs fréquents. Plusieurs travaux de recherche ont traité le problème de sélection d'index. Cependant, ces travaux ne prennent pas en compte les connaissances (mé-tadonnées, statistiques, charge de requêtes appliquée au système, usage des attributs de l'entrepôt de données dans ces requêtes, etc.) qui peuvent être extraites de la charge afin de réduire la complexité du problème de sélection et de cibler les index candidats les plus intéressants. La stratégie de sélection d'index que nous proposons intègre donc cette 5 connaissance elle exploite la recherche des motifs fréquents maximaux de manière incrémentale afin de cibler l'ensemble des index candidats. L’intuition [Aou05] est que l'utilité d'un index donné est fortement corrélée avec la fréquence d'utilisation des attributs associés à cet index dans l'ensemble des requêtes de la charge. 1.3 Organisation du mémoire Ce mémoire de stage est organise comme suit. Dans le chapitre 1 nous présentons les principaux travaux proposés pour résoudre le problème de la sélection d’index. Cette partie est suivie d’un état de l’art sur la recherche incrémentale des motifs fréquents fermés et maximaux. Le chapitre 3 présente l’approche proposée pour la sélection d'index basée sur la recherche incrémentale de motifs fréquents maximaux. Nous exposons également les raisons de notre choix et l’explication de l’algorithme. Le chapitre 4 pressente notre implémentation et les objets utilisés. Pour terminer, nous concluons et indiquons quelques perspectives dans le chapitre 5. 6 Chapitre 2 Etat de l’art Dans ce chapitre, nous abordons une recherche bibliographique et nous exposons une synthèse des travaux qui traitent des problèmes de sélection d’index dans les entrepôts de données car ces structures physiques (index…) réduisent considérablement le temps de réponses des requêtes dans les bases et entrepôts [VG99LBE03]. 2.1 Problème de sélection d'index Nous exposons dans cette partie, une synthèse des travaux qui traitent des problèmes de sélection d’index dans les entrepôts de données. Le problème de sélection d'index consiste à construire une configuration d'index optimisant le coût d'exécution d'une charge donnée sous certaines contraintes comme l’espace de stockage alloué par les Systèmes de Gestion des Bases de Données aux index à sélectionner. - Le coût d’exécution de la charge doit être minimal ; - L’espace de stockage des index ne doit pas dépasser la taille de l’espace disque alloué par l’administrateur pour stocker les index à sélectionner. On est donc face à un problème NP-Complet [Com78]. Alors, il n'existe pas d'algorithmes qui proposent une solution optimale en un temps fini. Plusieurs travaux de recherche dans la littérature proposent plutôt des solutions proches de la solution optimale en utilisant des heuristiques réduisant la complexité du problème [LBE03]. La sélection d'index peut être effectuer à partir d’un ensemble d’index candidats extraite à partie d’une charge de donnée [FON92, CBC93a, CBC93b] par l’administrateur mais également de manière automatique en réalisant une analyse syntaxique (SGBD) des requêtes de la charge [CN97, VZZ+00, GRS02]. La configuration final d’index peut ainsi être faite par une méthodes ascendantes partent d'une configuration d'index candidats vide [KY87, FON92, CBC93b, CN97] ou alors par une méthode descendantes dont point de départ est l'ensemble de tous les index candidats. À chaque itération, des index sont élagués [KY87, CBC93a]. Si le coût de la charge avant élagage est inférieur (respectivement, supérieur) au coût de cette même charge après élagage, les index élagués sont inutiles (respectivement, utiles) pour réduire le coût de la charge. Le processus d'élagage s'arrête lorsque le coût augmente suite à un élagage. Les algorithmes génétiques sont couramment utilisés pour résoudre des problèmes d’optimisation [Aou05]. Ils ont même été adaptés au problème de sélection d'index [KLT03]. On a au départ un ensemble d'index candidats fourni en entrée. La fonction objectif à optimiser est le coût de la charge en présence d'une configuration d’index [Aou05]. 7 2.1.1 Travaux de Frank et al. Dans [FON92], Frank et al. Proposent un outil d'aide à la décision pour le choix d'index dans une base de données en utilisant une configuration initiale d'index et une charge de requêtes. Un dialogue est alors établi entre l'outil de sélection d'index et l'optimiseur de requêtes du SGBD afin de calculer le gain en performance qu'apporte l'utilisation d'un index donné pour la charge. Le gain est défini comme la différence entre le coût d'exécution des requêtes sans index et celui de leur exécution avec index. Le gain est représenté sous forme d'un graphe d'index. Le graphe d'index représenté à la Figure 2.1 correspond au dialogue ci-dessous en langage naturel entre l'outil et l'optimiseur : - Outil : Pour une requête q, quel est l'index à choisir parmi un ensemble d'index candidats p1 = {a, b, c, d} et quel est son coût d'utilisation ? Optimiseur : Je propose l'index i1 = {b}. Le coût estimé pour la requête q utilisant cet index est c1=23. Outil : Parmi les index qui restent, c'est-à-dire p2 = p1- i1 = {a, c, d}, quel est le meilleur index et son coût pour la requête q ? Optimiseur : L'index i2 = {d} avec un coût c2 = 27. Fig. 2.1 - Graphe d'index simple Ce jeu de questions-réponses continue jusqu'à ce qu'il n'y ait plus d'index à proposer (ik= { }) Cette technique peut donc être résumée en cinq étapes : 1. Une requête de la charge est soumise à l'optimiseur de requêtes avec un ensemble d'index initial. 2. L'ensemble des index utilisés pour la requête courante est stocké avec le gain de performance pour la requête. 3. De nouveaux ensembles d'index sont générés et l'étape 2 est réitérée jusqu'à effectuer un parcours séquentiel. 4. Les gains en performance de chaque index sont additionnés. 8 5. Les index présentant un gain total positif sont enfin proposés à l'utilisateur. 2.1.2 Travaux de Choenni et al. Etant donnée que l'ajout d'un index dans une configuration peut augmenter son coût, comme il peut aussi le réduire, Le problème de sélection d'index, tel qu'il a été posé dans [CBC93b], est basé sur un modèle mathématique avec un comportement similaire a celui des fonctions mathématiques dites super-modulaire et sous-modulaire [Aou05]. A l’aide de cet exemple nous allons étudier le comportement de ces fonctions : Considérons la table Persons de 400000 tuples composée des attributs Pers_ID, Pers_name,Pers_salary, Pers_age, Pers_sexe, Pers_education et la requête suivante : select pers_name from persons where pers_education = 'second' and pers_salary = 2000 and pers_age = 21 Supposons que les facteurs de sélectivité SF des attributs Pers_education, Pers_salary et Pers_age sont respectivement SFPers_education = 110 , SFPers_salary = 140 et SFPers_age = 50 , et qu'une page disque contient vingt tuples. Étudions le comportement de l'ajout d'un index construit sur l'attribut Pers_education dans les trois ensembles d'index suivants A = {}, A’ = {Pers_salary} et A’’ = {Pers_salary; Pers_age}. Les coûts, qui représentent le nombre de pages lues, dans chaque con_guration, avec ajout et sans ajout d'un index construit sur l'attribut Pers_education, sont résumés au Tableau 2.1. Tab. 2.1 - Résultat de calcul des coûts L'ajout d'un index construit sur l'attribut Pers_education dans la configuration vide n'apporte aucun gain Le coût avant et après l'ajout de cet index reste inchangé. En revanche, l'ajout du même index dans la configuration A’ apporte un gain important En effet, le coût passe de 10000 pages à 1000 pages. Le même ajout dans A’’ apporte un gain, quoique moindre comparé au précédent. Ces observations montrent les caractéristiques de base de la fonction de coût similaires aux caractéristiques des fonctions super et sous-modulaires. Le formalisme mathématique de ces fonctions et son adaptation au problème de sélection d'index est détaillé dans [Aou03]. L'algorithme de sélection d'index prend en entrée une fonction de coût C1, une charge Qred2 extraite de la charge Q, un ensemble d'attributs à indexer selon l'administrateur du système et une configuration initiale d'index pertinente pour chaque requête de la charge et renvoie un ensemble d'index 9 avantageux et un autre ensemble d'index désavantageux, pour des groupes de requêtes constituant des sous-ensembles de Qred [Aou03]. 2.1.3 Travaux de Whang - Algorithmes ADD and DROP L'algorithme DROP de K. Whang commence d’abord en considérant l'ensemble des index possibles [Kin74] et à chaque étape, il élimine l'index qui engendre la plus grande décroissance du coût. Quand la valeur de la fonction ne peut plus être réduite en éliminant un seul index, l'algorithme tente d'éliminer deux index à la fois, trois index à la fois, et ainsi de suite, jusqu'à ce que ça ne soit plus possible. L'algorithme ADD quant à lui, initialise le processus d'optimisation par l'ensemble vide. À chaque étape, il ajoute un index susceptible de réduire la fonction de coût et s'arrête quand il n'y a plus de réduction de coût. 2.1.4 Travaux de Gündem Dans [Gun99], Gündem pose le problème des choix multiples pour la sélection d'index. Il propose une méthode qui prend en compte le fait qu'un attribut donné peut être indexé suivant plusieurs techniques et que, par conséquent, les index construits sur cet attribut suivant différentes techniques apportent des gains et occupent des espaces de stockage différents. La méthode présentée utilise un ensemble d'index candidats fourni par l'administrateur pour y sélectionner un sous-ensemble I qui minimise, suivant une erreur tolérée, le coût de traitement des opérations de mise à jour et de sélection sans violer la contrainte d'espace de stockage[Aou03] Pour utiliser cette méthode, les choix multiples d'index pour chaque attribut et les fréquences respectives des sélections et des mises à jour sont supposés fournis par l'administrateur du système. 2.1.5 Travaux de Chaudhuri et al. Dans le but de trouver de nouvelles techniques pour auto-administrer une base de données, tout en assurant des performances comparables à celles d'une base de données gérée uniquement par un administrateur humain [Mic01] Microsoft a lancé le projet de recherche AutoAdmin. L'outil de sélection d'index IST (Index Selection Tool) [CN97] extrait un ensemble d'index, dit configuration, souhaitable pour une base et une charge données. L’architecture générale d’ IST est représentée à la Figure 2.2. Dans la première itération elle ne considère que les index mono-attribut. Dans la seconde itération, il ne considère que les index à un seul attribut (trouvés dans la première étape) et à deux attributs ; et ainsi de suite dans les itérations suivantes. 10 Fig. 2.2 - Architecture générale d'IST L'algorithme de sélection d'index passe par trois phases : - Le module de sélection des index candidats élimine un nombre important d'index qui n'apportent aucun bénéfice aux requêtes de la charge. - Le module de sélection de configurations recherche les différents sousensembles d'index et extrait la configuration optimale. - Le module générateur d'index multi-attributs génère les attributs multi-attributs à considérer à chaque nouvelle itération. Le module d'évaluation du coût qui maintient la table des coûts. Module What-if creation index [CN98] simule la présence des index qui n’existent pas dans la base de données. 2.1.6 Travaux de Feldman et al. Feldman et al. ont de développé dans [FR03] un outil à base de connaissances qui assiste l'administrateur dans la sélection d'index appelé DINNER. Partant d’un ensemble de tables, leurs statistiques et un ensemble de requêtes sur ces tables, DINNER recommande une configuration d'index qui contient un index primaire et un ensemble d'index secondaires. DINNER utilise une base de connaissances extraite de différentes sources : l'expertise de l'administrateur de la base de données,le manuel du SGBD utilisé, des cours sur l'administration des bases de données, etc. Ces connaissances sont formalisées en utilisant un schéma de représentation de connaissances. La Figure 2.3 illustre une représentation sous forme d'un graphe de la requête de jointure donnée par la requête (q1) ci-dessous. (q1) select T1.name from Item T1, Item-Wharehouse T3 11 Where T3.catalog-number = T1.catalog-number and T3.quantity > 10000 and T1.supplier-code = 4 and T1.price > 1000 Fig. 2.3 - Graphe de solutions de la requête q1 Le noeud A correspond à une solution réalisant une jointure où l'attribut item de T1 est dans une table OUTER et l'attribut item-warehouse de T3 est dans une table INNER. Le nœud B correspond à la solution réalisant la jointure dans le sens inverse. Chacun de ces nœuds a deux fils : boucle imbriquée (nested loop) et tri-fusion (mergedsort), qui sont des nœuds AND. Chaque nœud possède deux fils représentant une requête définie sur une seule table. 2.1.8 Travaux de Valentin et al. Le système DB2 Advisor, est une boite noire pour recommander un ensemble d'index [VZZ+00]. Ce système admet en entrée une charge de requêtes SQL et renvoie en sortie la configuration d'index qui optimise les requêtes de la charge. Il est composé de : - D'une interface graphique pour la sélection d'index, - D'un outil en ligne de commande pour recommander des index. - De l'optimiseur de requêtes de DB2 qui évalue et recommande des index. En définitive, nous pouvons classer dans un tableau, les travaux traitant du problème de sélection d'index en tenant compte de ces critères suivant : - la méthode de construction des index candidats : manuelle ou automatique 12 - la méthode de construction de la configuration finale d'index : algorithme glouton (de manière ascendante ou descendante), algorithme génétique ou résolution de problème du sac à dos [Aou03]. le modèle de coût : fonction mathématique ou appel à l'optimiseur de requêtes. Tab. 2.2 - Classification des travaux sur la sélection d'index 2.2 Recherche incrémentale des motifs fréquents Le problème de la recherche incrémentale des motifs fréquents est un problème crucial car il pose le problème même de la validation des informations issues d’une base de données de transaction qui évolue dans le temps. Son principe est le suivant : Soit F l’ensemble des motifs fréquents extraits d’une la base de données de transactions BD. D est le nombre de transactions dans BD. On suppose que le support de chaque motif X ∈ F est X.support et qu’il est stocké. Après une série de mise à jour de la base de données, un incrément bd est ajouté à la base de données BD, d est le nombre de transactions contenues dans bd. Si nous voulons mettre à jour notre ensemble de motifs fréquents pour le même seuil minimum de support S, nous devons trouver tous les motifs X dans BD’ = BD+bd. X est fréquent dans BD’ si X.supportBD’ ≥ S × (D+d). Soit F’ l’ensemble des motifs fréquents extraits de BD’ ; un motif fréquent Y qui se trouvait dans F peut ne pas se trouver dans F’, ou encore, un motif Z qui ne se trouvait pas dans F peut apparaître dans F’ ce qui peut causer une perte d’information. 2.2.1 Algorithme incrémental recherche de motifs fréquents fermes Définition (Motif fréquent fermé) Un motif fermé est un ensemble maximal de motifs communs à un ensemble d'objets. Un motif i ⊆ I tel que support (i) ≥ minsup est appelé motif fréquent fermé. 13 Les algorithmes incrémentaux permettent de mettre à jour le treillis de concepts lors de l'ajout de nouveaux objets. Un certain nombre d'algorithmes incrémentaux existent déjà [GMA95, VM01, VMGMO2], et Propose une construction du Treillis de Concept en même temps que la génération des concepts [VMGO2]. Ces algorithmes partent d'un même principe qui spécifie qu'après mise à jour, un treillis comporte trois types de noeuds : (i) des noeuds inchangés (concepts existants dans le treillis initial), (ii) des noeuds modifiés (au niveau de l'extension des Concepts) ou bien (iii) des noeuds rajoutés (dont l'intention n'était pas présente dans le Treillis initial).cependant, la complexité de ces algorithmes est d'ordre quadratique par rapport au nombre d'éléments dans le treillis de concepts [VMH03].L’ensemble des motifs fréquents fermés générés peut devenir très grand en fonction de la taille de la base de données[ZG03]. Certains algorithmes utilisent également des structures de données tel que les FP-tree (fréquent pattern tree) comme dans [CYH05] et des variantes de structures FPtree comme dans [WCOZ03]. 2.2.2 Algorithme incrémental de recherche de motifs fréquents maximaux Définition (Motif fréquent maximal) Un motif dont tous les sur-ensembles sont non fréquents. Ces algorithmes sont basés sur la propriété que les motifs fréquents maximaux, c'est-à-dire les motifs dont tous les sur-ensembles sont infréquents, forment une bordure au dessous de laquelle tous les motifs sont fréquents dans le treillis des motifs « treillis des itemsets ».A partir des motifs fréquents maximaux, tous les motifs fréquents sont dérivés et leur support sont déterminés en réalisant un balayage du contexte [GZ05]. Plusieurs algorithmes ont été proposés pour la recherche incrémentale des motifs fréquents [ATA99, TC00, DLC97, DLC97, TBA97, FAA97] ils réutilisent tous les motifs trouvés avant la mis à jour de la base de donnée pour retrouver les nouveaux motifs mais le coût des mis à jour des motifs est très important. L’algorithme Zigzag [VMCPO2] que nous avons choisi et que nous décrirons dans l’approche proposé pour notre sélection d’index (chapitre 3), est basé sur l’algorithme GenMax [GZ05] qui est un algorithme qui utilise de retour-arriere pour élaguer l’arbre de recherche au plus tôt guidé par les résultats des précédentes itérations de l’algorithme. Cet algorithme améliore également le calcul du support et optimise la recherche des petits articles « short term mining ». 14 Chapitre 3 Approche proposé Les entrepôts de données sont généralement modélisés selon un schéma en étoile contenant une table de faits centrale volumineuse et un certain nombre de tables dimensions représentant les descripteurs des faits [Inm02, KR02]. Avec ce type de modèle, une requête décisionnelle nécessite une ou plusieurs jointures entre la table de faits et les tables dimensions. Ces jointures sont très coûteuses en terme de temps de calcul. Ce coût devient prohibitif lorsque les jointures opèrent sur de très grands volumes de données. Il est alors crucial de le réduire notamment par les des techniques qui exploitent des index de jointure pour pré-calculer ces dernières afin d’assurer un accès rapide aux données [lBE03, Aou05]. L'administrateur de l'entrepôt de données a donc pour tâche cruciale de choisir les meilleurs index à construire. Avec le développement des entrepôts de données, il est devenu très important de réduire la fonction d'administration des SGBD [WMHZ02]. Dans [Aou05], l’auteur propose une stratégie permettant de sélectionner les index plus avantageux grâce à des modèles de coût. Notre stratégie s’inscrit dans la poursuite des travaux dans [Aou05] afin de rendre la recherche des motifs fréquents incrémentale. Dans cette étude, nous avons choisi de nous focaliser sur les index bitmap de jointure car ils sont bien adaptés à l'environnement des entrepôts de données. En effet, les bitmaps de ces index rendent efficace l'exécution d'opérations courantes comme And, Or, Not ou Count qui opèrent directement sur les bitmaps (donc en mémoire) et non plus sur les données sources. De plus, les jointures sont préalablement calculées au moment de la création de ces index et pas lors de l'exécution des requêtes. Avant de présenter le principe de notre démarche de sélection automatique d'index à base d'extraction de motifs fréquents maximaux, allons d’abord exposer les motivations de notre choix d'utiliser les motifs fréquents maximaux pour la sélection d'index. 3.1 Recherche de motifs fréquents 3.1.1 Contexte et motivations Dans [Aou05] l’auteur par de l’intuition que la pertinence d'un index est fortement corrélée avec la fréquence de son utilisation dans l'ensemble des requêtes d'une charge. A priori, la recherche des fréquents est un moyen qui semble approprié pour rendre compte de cette corrélation et ainsi faciliter le choix des index à construire [Aou05]. 15 Définition (Motif fréquent) : Soient I = i1,…. im un ensemble de m items et B =t1, …, tn une base de données de n transactions. Chaque transaction est composée d'un sousensemble d'items I’ ⊆ I. Un sous-ensemble I’ de taille k est appelé un k-motif. Une transaction ti contient un motif I’ si et seulement si I’ ⊆ ti. Le support d'un motif I’ est la proportion de transactions de B qui contiennent I’. Le support est donné par la formule suivante. Un motif dont le support est supérieur ou égal au seuil minimal du support minsup, défini par l'utilisateur, est appelé un motif fréquent. Définition (Motif fréquent maximal) Un motif donc tous les sur-ensembes sont infrequents. Par exemple, sur le tableau X, ACTW n’a plus de sur-ensemble qui soit fréquent. Tableau 3.1 : Exemple d'extraction de motifs fréquents et maximaux Bien que plusieurs algorithmes traitent le problème de la recherche incrémentale des motifs fréquents. C’est celui-ci [VMCPO2] qui a retenu notre attention pour les raisons suivantes. Dans notre cas d'étude, les objets (transactions) sont des requêtes et les items sont les attributs extraits de ces requêtes. La charge de requêtes peut être volumineuse et dans une requête ont peut avoir un seul attribut indexable sélectionné. La charge de requêtes peut évoluer dans le temps. L'algorithme Zigzag [VMCPO2] s'avère adapté à la résolution de ce problème. En effet, Zigzag est basé sur l’algorithme Genmax[GZ05] qui permet en un temps minime, la détermination de tous les motifs fréquents maximaux dans de très grandes bases de données en optimisant le calcul des support et l’élimination des motifs infrequent par retour-arriere. Par ailleurs, les données interrogées dans une session de travail sont souvent corrélées. De ce fait, les requêtes de la charge, prises dans un intervalle continu de temps, le sont aussi [Aou05]. 16 Cette corrélation entre les requêtes donne lieu à un contexte d'extraction dense. L’algorithme de recherche incrémentale basé sur la recherche des motifs fermés peut avoir un nombre de motifs fermés exponentiellement plus grand que l’ensemble des motifs fréquents maximaux générés [ZG03]. De plus, l’ensemble des motifs fréquents peut être généré directement à partir de l'ensemble des motifs fréquents maximaux [GZ05]. D'autre part, le nombre d'index candidats dépend du nombre de motifs fréquents. Plus le nombre de motifs fréquents est élevé, plus on génère d'index candidats. Pour éviter la prolifération des index candidats, il est judicieux de générer ces index à partir des motifs fréquents maximaux dont le nombre est moins important que les motifs fréquents et moins important encore que le nombre de motifs fréquents fermés [ZG03, VMH03]. Cela permet de réduire la complexité du problème de sélection d'index. 3.1.2 Algorithme Zigzag Zigzag est un algorithme incrémental, il commence donc par rechercher les informations (motifs fréquents maximaux, motifs non maximaux mais fréquents, nombre de transactions …etc) qui ont été calculées et sauvegardées dans une base des connaissances P à l’étape précédente. Il scanne également la base de donnée entière D pour savoir si les transactions ont été modifiées en comparant par exemple le nombre de transactions dans la base à celui précédemment calculé. Le calcul des supports et la mis à jour des motifs est faite dans la base de donnée des mis à jour ∆ = {(D U d+) - d-} en fonction de P pour éviter des accès à la base de données D. d+ représente la liste des nouvelles transactions « ajoutés dans la base de données ». d- représente la liste des anciennes transactions « supprimés dans la base de données». Ainsi, la mis à jour des motifs fréquents se fait donc dans ∆ en utilisant P pour minimiser les accès à D. on peut donc avoir : - Des motifs qui déclinent « déclined », qui étaient fréquents dans P (de exécution précédente…) et ne sont plus fréquent dans ∆ (de l’exécution actuelle…). - Des motifs qui émergent « emerged » qui étaient infrequents dans P mais deviennent fréquents ∆. - Des motifs maintenus « retained » sont fréquents dans tout le temps. L’algorithme ce déroule en plusieurs étapes. Premier étape : Enregistrement et suppression les transactions Les nouvelles transactions sont ajoutés et pour chaque item dans ∆, on crée sa tidlist dans d+ et de le même manière, les vielles transactions sont supprimés et pour chaque item dans ∆, on créé sa tidlist dans d- ce qui forme la projection vertical. Ce qui rend très rapide le calcul du support d’un motif car il suffit de compter le nombre d’éléments dans sa tidlist. Pour un motif X sa tidlist sera : 1 L∆(X)= (LD(X) U Ld+(X)) – (Ld-(X) 1 Une tidlist c’est la liste des transactions dans lesquelles un motif apparaît. 17 Deuxième étape : Détermination des motifs fréquents Apres avoir enregistrer les nouvelles transaction et supprimer les anciennes, zigzag doit maintenant déterminer les motifs fréquents maximaux dans ∆. A ce niveau, Zigzag utilise comme sur la figure 3.1 un algorithme de retour-arriere pour élaguer l’arbre de recherche. Zigzag utilise également la technique de calcul des supports par des tidlist et celle du combinet set2 pour élaguer le treillis et améliorer le calcul du support à l’aide de la projection verticale des motifs [ZG03, GZ05]. Figure 3.1 : Sous ensemble et l’arbre de recherche des motifs fréquent maximaux par retour-arriere (motifs maximaux encadrés dans un cercle) Exemple : Partant de F1 = {A, C, D, T, W}, un ensemble des motifs fréquents de taille un. F1 correspond au combine set de départ. En prenant A comme premier items pour la construction d’un motifs fréquent de taille deux, AD n’est pas fréquent alors tous les sous arbres contenant AD sont élagués et AD n’entrera d’aucune façon dans la construction des motifs fréquents de taille trois. Par ailleurs AC étant fréquent avec un combine set {T, W} il produit comme motif fréquent ACT et {W} et ensuite ACTW comme motif fréquent et {} un combine set vide. ACTW n’ayant plus de sur-ensemble, est alors considéré comme motif fréquent et maximal. Troisième étape : La mis à jour des supports des motifs Fréquents L’algorithme lance pour chaque motif fréquent maximal θ trouvé, l’algorithme récursif sur la figure 3.2, qui pour chaque k-motif frquents manimal θ, sépare θ en k sous ensembles de taille (k-1) et calcule leur support dans ∆. Figure 3.2 : Algorithme de calcul des support 2 Combinet set d’un motif I : C’est l’ensemble des items qui ajoutés à I peuvent créer un motif fréquent. 18 3.2 Démarche de sélection automatique d'index L'approche que nous proposons, dont le principe général est représenté à la figure 3.3, exploite une charge de requêtes afin d'en extraire une configuration d'index améliorant le temps d'accès aux données dans un processus de recherche incrémentale des motifs donnant un dynamisme au processus de sélection d’index. Tout d'abord, nous extrayons de la charge des attributs indexables, c'est-à-dire, les attributs qui peuvent être utiles lors de l'exécution des requêtes s'ils sont indexés. Ces attributs sont stockés dans un fichier « attribut » et comporte pour chaque ligne la liste des attributs indexables de la requête correspondante, préfixé par le nom de la table. Une ligne du fichier est considérée comme une transaction, ce qui correspond à un contexte d'extraction exploit é par l'algorithme de fouille de données Zigzag. Métadonnées Schéma, statistiques 1 Figure 3.3 : Architecture la stratégie de sélection automatique d'index Charge 2 Fichier Contexte d’extraction Entrepôts de données 3 Ensemble des motifs fréquents maximaux 4 P Index Base de candidats connaissance Enregistrement / élagage des index candidats 5 Ajout Suppression Modèle de coût 6 Configuration finale d’index Enregistrement / élagage des index 7 Ajout Suppression 19 1 Extraction de la charge 2 Extraction des attributs indexables 3 Application de l'algorithme Zigzag sur ce contexte 5 Enregistrement ou élagage des index candidats 6 Construction de la configuration finale 7 Création des effective des index dans l’entrepôt de données des requêtes par le système 4G Génération de l’ensemble des index candidats à partir de l’ensemble des motifs fréquents maximaux Nous procédons comme suit pour proposer une configuration d'index : - Extraction de la charge des requêtes par le système, - Analyse de la charge de requêtes pour extraire les attributs indexables, - Construction du contexte de recherche des motifs fréquents, - Application de l'algorithme Zigzag sur ce contexte, - Génération de l’ensemble des index candidats à partir de l’ensemble des motifs fréquents maximaux, - Enregistrement ou élagage des index candidats qui serons appliqués à la configuration finale, en fonction des candidats déjà existants (calculés a une précédente session …), - Application du modèle de coût [Aou05] et Construction de la configuration finale d'index. - Enregistrement et élagage de la configuration finale, - Création des effective des index dans l’entrepôt. Nous détaillons chacune de ces étapes dans les sections qui suivent. 3.2.1 Extraction de la charge La première étape de notre stratégie de sélection d'index consiste à extraire du journal des transactions les requêtes adressées au SGBD. Cette tâche peut être réalisée en exploitant la capacité des SGBD actuels de sauvegarder les opérations réalisées sur le système durant une période de temps. Cette période est fixée par l'administrateur et doit être suffisante pour pouvoir anticiper les requêtes futures des utilisateurs. Dans l'environnement des entrepôts de données, les requêtes extraites sont décisionnelles. Dans un schéma en étoile par exemple, elles peuvent être exprimées en algèbre relationnelle comme suit [Aou05] : Où S est une conjonction de prédicats simples sur les attributs des tables dimensions, G est un ensemble d'attributs des tables dimensions Di (les attributs de la clause Group 20 by), et M est un ensemble de mesures agrégées, chacune étant définie en appliquant un opérateur d’agrégation sur une mesure de la table de faits F. 3.2.2 Analyse de la charge Les requêtes SQL présentes dans la charge sont traitées par un analyseur syntaxique afin d'en extraire tous les attributs susceptibles d'être des supports d'index. Ces attributs sont ceux présents dans les clauses Where des requêtes. Ces attributs servent à la recherche dans les requêtes d'interrogation. Dans les systèmes décisionnels, les requêtes sont de type Select et les rafraîchissements sont réalisés périodiquement [VG99]. Nous ne construisons donc le fichier contenant les attributs qu'à partir des requêtes d'interrogation. Les règles permettant de proposer des attributs indexables à travers un exemple sont les suivantes. Soit un prédicat de restriction qui a l'une des formes suivantes : t.a between v1 and V2, t.a θ v2, t.a like v1 ou t.a IN (v1, v2 ..) Où: t est le nom ou l'alias d'une table ; a est un attribut de cette table ; θ est l'un des opérateurs =, ≠, >, >, ≤, ≥ ; v1 v2 sont des valeurs constantes ne faisant pas référence à une table (nom ou alias d'une table). Plusieurs cas peuvent conduire à proposer des index « inutiles », c'est-à-dire des index candidats qui ne seront pas exploités pour répondre aux requêtes de la charge. 1. Un prédicat de la forme E(t.a) = v1, où E(t.a) est une expression en t.a, par exemple, t.a2+3t.a. Dans un tel cas, t.a n’est pas l’opérande immédiat de l’opérateur de comparaison. Le SGBD n'utilise pas d'index sur l'attribut a pour chercher les tuples vérifiant ce prédicat. 2. Un prédicat de la forme t.a≠ v1 n’utilise pas d’index sur l’attrubut a car toutes les données sont parcourues sauf v1, si elle existe dans la table. 3. Un prédicat de comparaison de chaîne de caractères utilisant Like n’exploite pas l’existence d’un index pour chercher les tuples vérifiant ce prédicat si la recherche s’effectue sur une sous-chaine (comme pour l’utilisation de joker u début du like ‘%chaine’) plutôt que sur la totalité de la chaîne. 21 3.2.3 Construction du contexte d'extraction À partir des attributs extraits dans l'étape précédente, nous construisons un fichier contenant sur chaque ligne du fichier, tous les attributs indexables de chaque requête. Nous illustrons la construction de ce fichier à travers l'exemple suivant. Soit un entrepôt de données composé de la table de faits Sales et de cinq tables dimensions Channels, Customers, Products, Times et Promotions. La figure 3.4 représente un extrait de charge composé de trois requêtes. Figure. 3.4 - Extrait de charge Le fichier « attributs » obtenu après l’analyse syntaxique de la charge est composé de trois lignes chacune comportant les attributs indexables de chaque requête (figure 3.5).chaque attribut est préfixé par le nom de la table correspondante. Ce fichier, exploitée par l'algorithme Zigzag, donne lieu à un ensemble de motifs fréquents maximaux. Apres une petite présentation du modèle de coût décrit dans [Aou05], nous détaillerons comment sont générés les index bitmap de jointure candidats à partir de ces motifs fréquents maximaux. Figure. 3.5 – fichier « attributs » 22 3.3 Modèles de coût Généralement, le nombre d'index candidats est d'autant plus important que la charge en entrée est volumineuse [Aou05]. La création de tous ces index peut ne pas être réalisable en pratique à cause des contraintes systèmes telles que le nombre limité d'index par table ou la taille de l'espace de stockage alloué aux index. Pour pallier ces limitations, des modèles de coût ont été proposé dans [Aou05] permettant de ne conserver que les index les plus avantageux. Ces modèles estiment l'espace en octets occupé par les index bitmap de jointure, les coûts d'accès aux données à travers ces index et les coûts de maintenance de ces index en terme de nombre d'entrées/sorties. La construction de ce modèle passe par : - le calcul de la taille d’un index bitmap de jointure, le coût de la sa maintenance en fonction de la variation de la taille et du coût d’insertion dans la table des faits mais également dans les tables dimensions. Coût d’accès aux données par un accès direct au bitmap. Coût de jointure. 3.4 Stratégie de sélection d'index bitmap de jointure La stratégie de sélection d’index est la même que dans [Aou05] à la seule différence que nous partons cette fois d’un ensemble de motifs fréquents maximaux. Un algorithme glouton exploite ensuite une fonction objectif basée sur les modèles de coût présentés à la Section 3.3 et développé dans [Aou05], afin d'élaguer les index les moins avantageux. Le détail des étapes de la construction des index candidats est donné dans les sections suivantes. 3.4.1 Construction de l'ensemble d'index candidats Avec l’ensemble des motifs fréquents maximaux et du schéma de l'entrepôt de données (clés étrangères de la table de faits, clés primaires des tables dimensions, etc.), nous construisons un ensemble d'index candidats. L'instruction de creation d'un index bitmap de jointure est généralement composée de trois clauses : On, From et Where. La clause On est composée des attributs sur lesquels est construit l'index (attributs non clés des tables dimensions), la clause From contient les tables jointes et la clause Where est constituée des prédicats de jointure. La requête cidessous montre un exemple d'une commande SQL permettant de construire un index 23 bitmap de jointure sur l'attribut Fiscal_Year de la table dimension Times (Sales est la table de faits), sous Oracle 9i. (1) CREATE bitmap index BIJ_TIMES on sales (times.fiscal_year) from sales,times where sales.time_id=times.time_id En considérant un motif fréquent maximal « Table.attribut1,....., Table.attributn » comme une suite finie d'éléments de la forme Table.attribut. Chaque motif fréquent est analysé pour déterminer les différentes clauses d'un index bitmap de jointure. Tout d'abord, nous extrayons les éléments contenant les clés étrangères de la table de faits. Les motifs ne contenant pas de tels éléments ne donnent pas d'index bitmap de jointure car ces éléments sont nécessaires pour définir les clauses From et Where de l'index. Nous recherchons ensuite, dans le motif fréquent, les éléments contenant les clés primaires des tables dimensions afin de construire la clause Where. Les tables trouvées au cours de cette analyse constituent la clause From. Les éléments contenant des attributs non clés des tables dimensions forment la clause On. Si de tels éléments n'existent pas, l'index bitmap de jointure ne peut pas être construit car la clause On est formée des attributs non clés des tables dimensions. Par exemple, le motif fréquent maximal <Times.Time_id, Sales.Time_id, Times.Fiscal_Year> donne l'index bitmap de jointure BIJ_TIMES de la commande SQL est présentée ci-dessus. 3.4.2 Enregistrement et suppression des index candidat Nous disposons donc dans P et ∆ (décrit à la section 3.1.2), l’ensemble un ensemble de connaissances sauvegardées au cours de l’exécution du processus et qui va nous permettre de choisir à ce niveau les index candidats intéressants que nous allons soumettre ensuite à la configuration d’index finale avec application du modèle de coût pour avoir les index les plus pertinents. Des index supprimés et ajoutés, on extrait la liste des motifs qui on contribués à leur création. Le résultat de ce calcul est enregistré dans la base de connaissance P (cf annexe 1) les index sont également sauvegardés. Pour la requête de création d’index ci-dessus (1), le motif qui a permit sa création est : (2) Times.Time_id, Sales.Time_id, Times.Fiscal_Year Le motif (2) de l’index (1) ayant été par exemple sélectionné lors d’une précédente recherche, peut devenir lors de l’exécution de l’application non fréquent à cause par exemple de la mis à jour de la base de données ou du changement du support minimal. On dit qu’il décline « declined » et si par contre il est toujours fréquent, on dit qu’il est maintenu « retained » il est donc intéressant pour la configuration d’index finale à laide du modèle de coût. Les index constitués à partir des motifs maximaux qui déclinent « déclined », sont supprimés et ne participerons pas à la configuration finale d’index. Les index constitués a partir des motifs qui émergent « emerged » ou qui sont 24 maintenus « retained » sont les plus intéressants et sont engregistrer pour participer à la configuration finale d’index. 3.4.3 Construction de la configuration d'index Le seul objectif d’un index est de réduire les entrées-sorties. Pour la configuration finale, il faut donc évaluer la réduction ou l'augmentation du coût d'exécution en terme d'entrées/sorties, des requêtes de la charge pour chaque index. Le coût d'exécution d'une requête est égal au coût d'accès aux données à travers cet index. La sélection est faite en privilégiant les index apportant le plus de profit tout en occupant un minimum d'espace de stockage mais également en privilégiant aussi les index qui engendrent le moins d’entrées sorties lors de l'exécution des requêtes. L’algorithme de sélection d'index défini dans [Aou05] se base sur une recherche gloutonne dans l'ensemble des index candidats I donné en entrée. La configuration d’index est générée à l’aide des fonctions objectif P « profit », R « ration profit/espace » ou H « hybride » décrites dans et du modèle de coût décrits dans [Aou05]. 25 Chapitre 4 Implémentation et Expérimentations Il est difficile d’apprécier une méthode sans lui appliquer des tests sur des données réelles. Il nous a donc semblé capital d’implémenter notre approche pour pouvoir l’évaluer. Nous l’évaluons par la suite avec un entrepôt de données test. Les deux principales parties de notre approche sont la génération des motifs fréquents à partir d’une charge de requêtes et la sélection d’index. 4.1 Implémentation 4.1.1 Génération des motifs fréquents Langage et librairies Un langage évolué gérant facilement des classes « structure de données » et disposant d’une multitude de librairies efficaces était nécessaire, c’est pour cela que nous avons choisi le langage Java pour le développement. Structure de données Il nous a d’abord fallut définir une structure de données pour la représentation d’un motif car celui ci peut avoir plusieurs propriétés pendant l’exécution du programme. Un motif est une classe java qui a les propriétes suivante : - le nombre de transactions dans lesquelles il apparaît, Le nombre d’items qui le compose, Un vecteur qui comporte la liste de ces items, Un vecteur qui comporte la liste des transactions Un drapeau pour savoir si le motif est maximal, Un drapeau pour les éventuels changement d’état et le niveau de génération du motif. L’algorithme : zigzag L’application prend en entrée le fichier d’attribut généré dans [Aou05] à partir de la charge de requête ; sur chaque ligne la liste des attributs indexables de chaque requête. 26 Notre approche étant incrémental, l’application commence par lire les informations qui ont été calculées pendant une précédente exécution. La méthode Read_information() parcours le fichier de sauvegarde des données « base de connaissance » (en annexe) pour lire les informations sur : - le nombre de transaction « requête » à l’étape précédente, - le nombre de motifs non fréquents qui ont été créés pendant l’exécution ainsi que la liste de ceux-ci. - Le nombre de motif maximaux fréquents qui on été généré et la liste de ceux ci. - Le nombre d’index candidats sélectionnés et la liste des motifs fréquents qui les constituent. - Le nombre d’index candidats supprimes et la liste des motifs fréquents qui les composent. Il faut maintenant savoir pour l’exécution encours quels sont les modification qui ont été apportés à la charge. Pour cela, il faut parcourir la le fichier d’attribut avec la méthode Parsefile() elle permet donc de parcourir le fichier d’attributs ligne par ligne. Un attribut est considéré comme un motif de taille un. A chaque fois qu’on rencontre un item pour la première fois, on remplit ses champs « classe motif », on incrémente le compteur des items et on le sauvegarde dans une table de hachage à l’indice de la valeur du compteur. Tout au long de l’exécution du programme nous ne travaillons plus qu’avec des entiers, un accès à la table de hachage avec le numéro « indice » permet de récupérer la valeur de l’attribut correspondant(cf. figure 5.1). Apres le traitement d’une ligne, on passe à la ligne suivante donc il faut également incrémenté le compteur des transactions « requête ». À chaque fois qu’on rencontre cet item, on incrémente juste le compteur des items Pour savoir si des requêtes ont étés ajouté à la charge il suffit de comparer le nombre de transactions lues précédemment dans Read_information() et le compteur total des transactions actuel. Exemple pour une base de transaction BD (sur chaque ligne des attributs représentés par des lettres): BD ABCD BCD AB nb_trans = 2 nb_items = 1 list_items = A, list_trans = 1 et 3 Ismax = 0 Flag = 0 nb_trans = 3 nb_items = 1 list_items = B, list_trans = 1, 2 et 3 Ismax = 0 Flag = 0 nb_trans = 2 nb_items = 1 list_items = C, list_trans = 1et 2 Ismax = 0 Flag = 0 nb_trans = 2 nb_items = 1 list_items = C, list_trans = 1et 2 Ismax = 0 Flag = 0 Figure 5.1 structure d’une instance motif Le treillis des motifs « treilis des itemset » commence par les motifs de tailles un « item ». Genmax[ZG03] commence également par généré les motifs de taille un qui sont fréquents à laide de la méthode generateF1(). Elle compte tout simplement pour chaque motif le nombre d’éléments dans la liste des transactions qu’elle compare au support minimum. Pour un support de trois, sur la figure 5.1 seul le motif B est fréquent. 27 La méthode execu() implémente la fonction de retour-arriere avec en entrée une classe motif « itemset » vide et un combinet set correspondant à l’ensemble des motifs fréquents de taille un précédemment calculés. Dans cette méthode, les motifs non fréquents lues dans le fichier de sauvegarde « base de connaissance » et ceux nouvellement calculés sont utilisés en évitant a chaque d’avoir des motifs en doublons. Ils peuvent devenir des maximaux auquel cas on dit qu’ils émergent. Dans le même ordre les maximaux découverts aux étapes précédente peuvent devenir non fréquent ont dit qu’ils déclinent. (cf. section 3.12) Save_maximaux(fichier_max) permet de sauvegarder les maximaux créer dans un autre fichier « des maximaux ». Store_information(fichier_base) sauvegarde toutes les informations calculées dans le fichier de sauvegarde P. Look_max_indexSupp() recherhe les maximaux qui ont été créés à partir des index supprimés non sélectionnées. Look_max_indexAjout() recherche les maximaux qui ont été créés à partir des index sélectionnées. Sélection d’index Bitmap Constru_Max_Index() propose section d’index généré à l’aide des maximaux contenues dans le fichier des maximaux comme expliqué à la section 3.4.1. Figure 5.2 : interface de sélection des index 28 4.2 Expérimentations Afin de valider notre stratégie de sélection d'index bitmap de jointure, nous l'avons appliquée sur un entrepôt de données test implanté au sein du SGBD Oracle 9i installé sur un PC sous Windows XP Pro doté d'un processeur Pentium Dual Core à 1,60 GHz, d'une mémoire centrale de 1024 Mo et d'un disque dur IDE de 120 Go. Cet entrepôt de données est composé d'une table de faits Sales et de cinq tables dimensions Customers, Products, Promotions, Times et Channels. Le Tableau 5.1 détaille le nombre de tuples et la taille en Mo de chaque table de cet entrepôt. Nous avons mesuré pour différentes valeurs de la charge des requêtes, le temps d'exécution des requêtes de la charge d’abord en utilisant une approche statique avec reconstruction des index à zéro et l’approche incrémentale avec génération des index de manière dynamique à l’aide des motifs fréquents maximaux générés de manière incrémentale. Tableau. 5.1 - Caractéristiques de l'entrepôt de données test (Oracle 9i) La charge est composée de quarante requêtes décisionnelles comportant plusieurs jointures (cf. Annexe B). Nous avons mesuré le temps total d'exécution des requêtes de cette charge (il faut tout de même forcer l’exécution des index en utilisant /*+ORDERED dans la charge) 29 Temps de reponses(en minutes) 500 450 400 350 300 Statique incremental 250 200 150 100 50 0 1x40 2x40 3x40 4x40 5x40 Charge de requete Figure. 5.3 - Fonction profit La Figure 5.3 montre que les en utilisant les index dans les deux cas, les temps d’exécution sont plus ou moins proches jusqu’à une certaine valeur de la quantité de la charge. Apres cette valeur autour d’une charge (4x40=160 requêtes), le temps d’exécution en situation itérative a tendance à augmenter très vite alors que dans la situation incrémentale ce temps semble plutôt se stabiliser. Cela peut être du au fait que étant donnée que la recherche des index est basé sur la recherche des motifs fréquents maximaux (sur-ensemble de tous les fréquents) plus la base augmente plus on a de corrélation et moins on a de motifs fréquents maximaux. Dans ce cas on n’a de moins en moins de nouveaux index à créer. De plus le coût de rafraîchissement l'entrepôt de données étant proportionnel au nombre d'index construits [Aou05] cette réduction du nombre d'index devient intéressante. 30 Chapitre 5 Conclusion et perspectives Dans ce mémoire, nous nous sommes intéressées à la possibilité d'utiliser techniques de fouille de données tel que la recherche des motifs fréquents maximaux pour la sélection d’index, en ayant comme objectif d'optimiser les performances des entrepôts de données. Notre travail a été guidé par une étude préalable des travaux existants traitant du problème de la sélection d'index en général mais en particulier par les travaux de Kamel Aouche [Aou05]. En se basant sur un algorithme existant [VMCP02] nous avons implémenté notre stratégie que nous avons expérimenté sur un entrepôts de données test. Notre stratégie sélection d’index permet ainsi la construction des index en exploitant certaines méta-données et certaine connaissance en administration et en optimisation des SGBD, intégrée directement dans l'analyseur syntaxique, cela produit des index candidats pertinents pour la charge. La recherche incrémentale des motifs fréquents maximaux réduit considérablement l’espace de recherche des index candidats et rend leur recherche dynamique et incrémentale car on conserve les index candidats qui n’on pas été retenus et les motifs qui n’ont pas été maximaux pendant les processus de sélection précédent. Ceux-ci peuvent devenir intéressant dans le processus suivant. Le module génération des index, génère directement des index mono et multi-attributs. Notre stratégie de sélection d’index prend en compte les index bitmap très efficaces pour les requêtes d’interrogation dans les bases volumineuses. Elle peut également être adapté à d’autres techniques. L’algorithme de construction de la configuration finale d'index peut être améliorée ou adaptée à d’autres techniques d’indexation en changeant le modèle de coût par exemple. Différentes perspectives sont envisagées. En premier lieu, il serait intéressant de pouvoir développer une véritable interface graphique conviviale afin que pouvoir saisir les paramètres de l’application. Les tests effectués dans ce mémoire ne considèrent que le temps d’exécution en fonction de l’évolution de la charge. Il serait intéressant de regarder également le temps des mis à jour et l’espace disque occupé par les index en utilisant la fonction objectif décrit dans [Aou05]. 31 Annexe A : Fichier de sauvegarde : base de connaissance Nombre de requête dans la base Nombre de motifs non fréquents Motifs non fréquents …………. (candidats à la maximalité) Séparateur entre les non fréquents et fréquents Motifs maximaux Motifs candidat ajoutés Motifs candidat supprimés 32 Bibliographie [Aou05] Aouiche K., Techniques de fouille de données pour l'optimisation automatique des performances des entrepôts de données, thesis, laboratoire ERIC – Université de lyon2. 2005. [CYH05] Hong Cheng. & Xifeng Yan. & Jiawei Han., IncSpan: Incremental Mining of Sequential Patterns in Large Database. Sixth IEEE International Conference on Data Mining - Workshops (ICDMW'05), 2005. [ZG03]Mohammed J. Zaki, Karam Gouda, Fast Vertical Mining Using Diffsets, 9th International Conference on Knowledge Discovery and Data Mining, Washington, DC, August 2003. [Cha98] Chaudhuri S., “ Data Mining and Database Systems : Where is the Intersec-tion ? “, Data Engineering Bulletin, 21(1) :4-8. 1998. [Com78] Comer D., “The di_culty of optimum index selection “, ACM Transactions on Database Systems (TODS), 3(4) :440-445. 1978. [FON92] Frank M.R., Omiecinski E., Navathe S.B., “ Adaptive and Automated Index Selection in RDBMS “, in 3rd International Conference on Extending Database Technology, EDBT 1992, Vienna, Austria, volume 580 de Lecture Notes in Computer Science, pp. 277-292. 1992. [CBC93a] Choenni S., Blanken H.M., Chang T., “ Index Selection in Relational Databases “, in 5th International Conference on Computing and Information ICCI 1993, Ontario, Canada, pp. 491-496. 1993. [CBC93b] Choenni S., Blanken H.M., Chang T., “ On the Selection of Secondary Indices in relational Databases “, Data Knowledge Engineering, 11(3) :207-238.1993. [CN97] Chaudhuri S., Narasayya V.R., “ An E_cient Cost-Driven Index Selection Tool for Microsoft SQL Server _, in 23rd international Conference on Very Large Data Bases (VLDB 994), Santiago de Chile, Chile, pp. 146_155. 1997. [VMCPO2] Adriano Veloso, Wagner Meira, Jr., Marcio Carvalho, Bruno Possas, Srini Parthasarathy, Mohammed J. Zaki, Mining Frequent Itemsets in Evolving Databases, 2nd SIAM International Conference on Data Mining, Arlington, April 2002. [GZ05] Karam Gouda and Mohammed J. Zaki, GenMax: An Efficient Algorithm for Mining Maximal Frequent Itemsets, Data Mining and Knowledge Discovery: An International Journal, Vol. 11, pp 1-20, 2005. [FST88] Finkelstein S.J., Schkolnick M., Tiberio P., “ Physical Database Design for Relational Databases “, ACM Transactions on Database Systems, 13(1) :91-128. 1988. [LBE03] Ladjel Bellatreche., Techniques d'optimisation des requêtes dans les data warehouses. LISI/ENSMA, 2003. [VMGO2] Petko Valtchev; Rokia Missaoui; Robert Godin; Mohamed Meridji., Generating frequent itemsets incrementally : two novel approaches based on Galois lattice theory. Journal of Experimental & Theoretical Artificial Intelligence, Volume 14, pages 115 – 142, April 2002. 33 [KY87] Kyu-Young W., Foundation of Data Organization, chapitre Index Selection in Rational Databases, pp. 497_500, Plenum Publishing Co. 1987. [WCOZ03] William Cheung. & Osmar R. Zaïane R. Incremental Mining of Frequent Patterns Without Candidate Generation Or Support . iteseer.ist.psu.edu/622682.html, 2003. [GMA95] Godin, R. & Missaoui, R. & Alaoui, H., Incremental concept formation algorithmsbased on galois lattices. Computational Intelligence, 11(2), pages 246-267, 1995. [GRS02] Golfarelli M., Rizzi S., Saltarelli E., “ Index selection for data ware-housing “, in 4th International Workshop on Design and Management of Data Warehouses (DMDW 2002), Toronto, Canada, pp. 33_42. 2002. [VMH03] Valtchev, P. & Missaoui, R. & Hacene, M. R. & Godin, R., Incremental maintenance of association rule bases. In Proceedings of the 2nd Workshop on Discrete Mathematics and Data Mining, San Francisco, 2003. [VM01] Valtchev, P. & Missaoui, R., Building concept (Galois) lattices from parts : generalizing the incremental methods. In H. Delugach and G.Stumme, editors, Proceedings,ICCS-01, volume 2120 of Lecture Notes in Computer Science, Stanford (CA), USA,Springer-Verlag, pages 290-303, 2001. [VMGMO2] Valtchev, P. & Missaoui, R. & Godin, R. & Meridji, M., Generating Frequent Itemsets Incrementally : Two Novel Approaches Based On Galois Lattice Theory. Journal of Experimental & Theoretical Artifcial Intelligence, 14(2-3), pages. 115-142, 2002. [VG99] Vanachayobon S., Gruenwald L., “ Indexing Techniques for Data Warehouses Queries “, Technical report, The University of Oklahoma, School of Computer Science. 1999. [VVK02] Valluri S.R., Vadapalli S., Karlapalem K., “ View Relevance Driven Materialized View Selection in Data Warehousing Environment “, in 13th Australasian Database Technologies (ADC 2002), Melbourne, Australia, pp. 187-196.2002. [VZZ+00] Valentin G., Zuliani M., Zilio D., Lohman G., Skelley A., “DB2Advisor : An Optimizer Smart Enough to Recommend Its Own Indexes “, in 16th International Conference on Data Engineering, (ICDE 2000), California,USA, pp. 101-110. 2000. [WB98] Wu M., Buchmann A., “ Encoded Bitmap Indexing for Data Warehouses “,in 14th International Conference on Data Engineering (ICDE 1998), Orlando,USA, pp. 220_230. 1998. [WMHZ02] Weikum G., Monkeberg A., Hasse C., Zabback P.,“ Self-tuning DatabaseTechnology and Information Services : from Wishful Thinking to ViableEngineering “, in 28th International Conference on Very Large Data Bases (VLDB 2002), Hong Kong, China, pp. 20-31. 2002. [FAA97] R. Feldman, Y. Auman, A. Amir and H. Mannila. Efficient Algorithms for Discovering Frequents Sets in Incremental Databases. In Proc. Of SIGMOD Work-shop on Research Issues in Data Mining and Knowlewdge Discovery, May 1997. [TBA97] S. Thomas, S. Bodagala, K. Alsabti and S. Ranka. An Efficient Algorithm for the Incremental Updation of Association Rules in Large Databases. In Proc. Of the 3rd International conference on Data Mining and Knowlewdge Discovery (KDD 97), August 1997. [DLC97] S. D. Lee, and D. Cheung. Maintenance of Association Rules: When to Update? In Proc. Of SIGMOD Workshop on Research Issues in Data Mining and Knowlewdge Discovery, May 1997. 34 [CLK97] D. Cheung, S. D.n Lee, and B Kao. A general Incremental Technique for Maintaining Discovered Association Rules. In Proc. Of the 5th intl. conf. on Databases Systems for Advanced Applications, April 1997. [TC00] S. Thomas and S. Chakravarthy. Incremental Mining of Constrained Associations. In Proc. Of the 7th Intnl. Conf. of high Performance Computing (HiPC), P. 547-558, December 2000. [ATA99] N.Ayan, A. Tansel, and E. Arkun. And Efficient Algorithm to Update Large Itemsets with Early Prunning. In Proc. Of the 5th ACM6SIGKDD intnl. Conf. on Data Mining and Knowlewdge Discovery, August 1999. [VZZ+00] Valentin G., Zuliani M., Zilio D., Lohman G., Skelley A., “ DB2 Advisor : An Optimizer Smart Enough to Recommend Its Own Indexes “, in 16th International Conference on Data Engineering, (ICDE 2000), California, USA, pp. 101-110. 2000. [Gun99] Gundem T.I., “ Near optimal multiple choice index selection for relational databases “, Computers & Mathematics with Applications, 37(2) :111-120. 1999. 35
