Ministère de l Enseignement Supérieur et de la Recherche Scientifique. Ecole nationale Supérieure d Informatique (ESI) (Oued Semar, Alger) Mémoire

Transcription

1 Ministère de l Enseignement Supérieur et de la Recherche Scientifique Ecole nationale Supérieure d Informatique (ESI) (Oued Semar, Alger) École Doctorale Sciences et Technologies de l'information et de la Communication STIC Mémoire Pour l obtention du diplôme de Magistère Option : Ingénierie des Systèmes Informatiques (ISI) Présenté par Rym BOUCHAKRI Une approche dirigée par la classification des attributs pour fragmenter et indexer des entrepôts de données Soutenu devant le jury : Thouraya TEBIBEL Maître de Conférences à l'esi Présidente Walid HIDOUCI Maître de Conférences à l'esi Examinateur Hamid HENTOUS Docteur à l'emp Examinateur Ladjel BELLATRECHE Kamel BOUKHALFA Maître de Conférences à l'université de Poitiers Maître de conférences à l USTHB Directeur de mémoire Co-Encadreur ANNEE UNIVERSITAIRE 2008/2009

2 Remerciements Au terme de ce modeste travail, je voudrais adresser mes vifs remerciements à toutes les personnes qui ont contribué, de près ou de loin, à accomplir ce présent travail. Je remercie Mr Bellatreche L., enseignant à l ENSMA, Poitiers, pour m avoir accordé l honneur de travailler avec lui, pour m avoir permis, par la même occasion, de mettre un pas dans le grand monde de la recherche et pour tous les conseils qu il m a prodigué tout au long de la réalisation de mon travail. J exprime ma profonde gratitude à Mr Boukhalfa K., enseignant à l USTHB, Alger, pour sa disponibilité, pour le temps précieux qu il m a accordé et pour ses observations qui ont contribué à améliorer la qualité de ce travail. Je tiens à remercier très sincèrement l ensemble des membres du jury qui me font le grand honneur d accepté de juger mon travail. Cette thèse a été menée dans le cadre de l Ecole Doctorale (STIC) de l Ecole nationale Supérieure d Informatique (ESI). Ainsi, mes remerciements s adressent à Me Tebibel T., responsable de l Ecole Doctorale (STIC), à Me Cherid N., Directrice de la poste graduation (DPGR), aux enseignants de l ESI et de l Ecole Doctorale (STIC) et à tout le personnel de la DPGR pour leur disponibilité et leur soutient. Un grand merci à ma mère qui m a toujours soutenue, toujours encouragée et qui a fait de moi ce que je suis aujourd hui. Merci à ma famille pour tous les moments de bonheur partagés. A mes amis de tout temps et tout bord, à ceux et celles qui ont su trouver les mots pour m aider à franchir les obstacles et à avancer dans la vie.

3 Résumé Le volume d information contenu dans un entrepôt de données s accroît sans cesse, augmentant de ce fait la complexité des requêtes décisionnelles. Pour y remédier, l administrateur doit, durant la phase de conception physique de l entrepôt, effectuer une sélection de structures d optimisation (index, vues matérialisées ou fragmentation), puis assurer leur gestion et maintenance. Pour optimiser un nombre maximum de requêtes, il est indispensable d opter pour une sélection multiple de structures ayant une forte similarité. Dans la littérature, deux principales similarités entre les structures d optimisation ont été identifiées : une entre les vues et les index et l autre entre la fragmentation horizontale dérivée et les index de jointure binaire. Dans ce travail, nous proposons une approche de sélection multiple des index de jointure binaire et de fragmentation. Vue la complexité de la sélection multiple, nous proposons une nouvelle approche permettant d abord de partager l ensemble des attributs extraits des requêtes entre les deux structures, ensuite sélectionner chaque structure avec un algorithme. Pour réaliser ce partage, nous proposons d utiliser la méthode k-means. Une étude expérimentale et des tests comparatifs sur un entrepôt de données réel sous le SGBD Oracle 11g sont proposés montrant l intérêt de notre approche. Abstract The volume of data contained in a data warehouse grows dramatically, thereby increasing the complexity of decision support queries. To remedy this, the administrator shall, during the physical design phase of the data warehouse, perform a selection of structure optimization (indexes, materialized views or fragmentation), and ensure their maintenance. In order to maximize a large number of queries, it is mandatory to select several similar optimization structures. This similarity facilitates the manageability of each structure. In the literature, two main similarities between the optimization structures have been identified: one between materialized views and indexes and the other between the derived horizontal fragmentation and bitmap join indexes. In this work, we deal with the problem of selecting both horizontal partitioning and bitmap join indexes schemes. Due to the complexity of this selection, we propose a new approach that first splits the set of selection attributes among these two structures, and then selects each structure with an algorithm. This split is done using k-means method. An intensive experimental study is conducted on a real data warehouse under the Oracle 11g DBMS.

4 Sommaire Introduction... 1 Chapitre I : Techniques d optimisation des entrepôts de données... 3 I.1 L ENTREPOT DE DONNEE (ED)... 3 I.1.1 Définition... 3 I.1.2 Principe général... 4 I.1.3 Type de données... 5 I.1.4 Modèles de données... 5 I.1.5 Implémentation d un ED... 6 I.1.6 L entreposage de données dans Oracle... 9 I.1.7 Problématique liée aux entrepôts de données... 9 I.2 TECHNIQUES D OPTIMISATION DES ENTREPOTS DE DONNEES I.2.1 Les techniques redondantes I.2.2 Les techniques non redondantes I.2.3 Similarité entre techniques d'optimisation dans les entrepôts de données I.2.4 Résumé des techniques d optimisation dans les ED I.2.5 Optimisation dans le SGBD Oracle CONCLUSION Chapitre II : Problèmes de sélection des techniques d optimisation II.1 SELECTION D UN SCHEMA D OPTIMISATION : PRE-REQUIS II.1.1 Rôle de l administrateur de bases ou entrepôts de données II.1.2 Rôle du concepteur de la stratégie de sélection des techniques d optimisation II.2 PROBLEME DE SELECTION D INDEX PSI II.2.1 Démarche de sélection d index II.2.2 Formalisation du problème PSI II.2.3 Travaux de Feldman et al II.2.4 Travaux de Kratica et al II.2.5 Travaux de Chaudhuri et al II.2.6 Travaux de Valentin et al II.2.7 Travaux de Golfareli et al II.2.8 Travaux Aouiche et al II.2.9 Travaux de Bellatreche et al II.2.10 Synthèse II.3 PROBLEME DE SELECTION D UN SCHEMA DE FRAGMENTATION II.3.1 Algorithmes de fragmentation verticale II.3.2 Algorithmes de fragmentation horizontale FH II.3.3 Algorithmes de fragmentation mixte II.3.4 Fragmentation dans les entrepôts de données II.3.5 Synthèse II.4 SELECTION COMBINEE D IJB ET FH DANS LES ENTREPOTS DE DONNEES II.4.1 Type de sélection combinée II.4.2 Choisir entre sélection parallèle ou séquentielle II.4.3 Travaux de T. Stöhr et al II.4.4 Travaux de Bellatreche et al. et Boukhalfa et al II.4.5 Analyse de l approche existante CONCLUSION... 60

5 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation, dirigée par la classification III.1 DEMARCHE DE SELECTION COMBINEE AVEC PARTAGE DES ATTRIBUTS III.1.1 Motivation III.1.2 Problème de partage des attributs entre FH et IJB III.1.3 Critère de partage III.1.4 Déroulement du processus de sélection III.2 CLASSIFICATION DES ATTRIBUTS DE SELECTION III.2.1 Principe générale de classification III.2.2 Classification des attributs par «k-means» III.2.3 Exemple de classification III.3 MODELE DE COUT III.3.1 Modèle de coût pour la fragmentation III.3.2 Modèles de coût pour les index III.4 FONCTION OBJECTIF POUR L ALGORITHME GENETIQUE III.4.1 Formulation d une fonction objectif III.4.2 Fonction objectif pour la fragmentation III.4.3 Fonction objectif pour les index III.5 SELECTION D UN SCHEMA DE FRAGMENTATION III.5.1 Démarche de sélection d un schéma de fragmentation III.5.2 Implémentation du schéma de fragmentation sur l entrepôt III.5.3 Réécriture des requêtes pour exécution sur schéma fragmenté III.6 SELECTION D INDEX DE JOINTURE BINAIRE CONCLUSION Chapitre IV : Etude expérimentale et outil d assistance à l administration des EDs IV.1 ADMINFIC : OUTIL DE SELECTION DE FH ET IJB PAR CLASSIFICATION IV.1.1 Visualisation de l état de l entrepôt IV.1.2 Paramètres des algorithmes IV.1.3 Sélection combinée avec classification OAC IV.1.4 Sélection combinée simple OS (sans classification) IV.2 ENVIRONNEMENT EXPERIMENTAL IV.2.1 Démarche d Optimisation Avec Classification OAC IV.2.2 Démarche d Optimisation Simple OS IV.3 TESTS ET RESULTATS IV.3.1 Test 1 : Variation du mode d optimisation IV.3.2 Test 2 : Variation de W (S = 500mo) IV.3.3 Test 3 : Variation de S (W = 50) IV.3.4 Performance d algorithmes de sélection (comparaison test 2 et test 3) IV.3.5 Test 4 : Variation de l ordre d exécution pour FH/IJB IV.3.6 Test 5 : Choix des Facteurs du Poids de classification Conclusion Perspectives Bibliographie Sites Web Annexe A : Charge de requêtes

6 Table des figures Figure I-1: Intégration des données en données orientées sujet... 4 Figure I-2 : Structure d un EDR... 4 Figure I-3 : Cube de données... 5 Figure I-4 : Magasins de données (datamarts)... 6 Figure I-5 : Modèle ROLAP : Schéma de données en étoile... 7 Figure I-6 : Modèle ROLAP : Schéma de données en flocon de neige... 7 Figure I-7 : Modèle ROLAP : Schéma de données en constellation... 8 Figure I-8 : Tableau multidimensionnel de données, modèle MOLAP... 8 Figure I-9 : Exemple d index de jointure Figure I-10: Schéma en étoile d un entrepôt de données Figure I-11: index de jointure en étoile Figure I-12 : Exemple d index bitmap Figure I-13 : Exemple d index bitmap de jointure Figure I-14 : Exemple de fragmentation verticale Figure I-15 : Exemple de fragmentation horizontale primaire Figure I-16 : Exemple de fragmentation horizontale dérivée Figure I-17 : FH dérivée et IJB sur la table Vente Figure I-18: Mode de fragmentation simple Figure I-19: Mode de fragmentation composite Figure I-20: Mode de fragmentation dérivée REFERENCE Figure I-21: Mode de Fragmentation Horizontale sous Oracle Figure II-1 : Choix de l administrateur pour une stratégie d optimisation Figure II-2 : Démarche de sélection d index Figure II-3 : Graphe d exécution pour une requête Figure II-4 : Outil de sélection d index IST dans AutoAdmin Figure II-5 : Architecture de DB2 Adviser Figure II-6 : Matrice d usage et supports Figure II-7 : Exemple de motifs pour chaque requête Figure II-8 : Architecture de sélection automatique d'index (Aouiche, et al., 2005) Figure II-9: Fragmentation verticale par Hammer et al Figure II-10 : Architecture de fragmentation horizontale (Bellatreche, 2000) Figure II-11: Schéma en étoile d un entrepôt de données Figure II-12: Codage d un schéma de fragmentation Figure II-13: Schéma d entrepôt fragmenté Figure II-14 : Types de sélection combinée pour deux structures d optimisation Figure II-15 : Population de l entrepôt Figure II-16 : Optimisation par FH et IJB sur l attribut Pays Figure II-17: schéma de sélection combinée d IJB et FH par Stöhr Figure II-18: schéma de sélection combinée d IJB et FH Figure III-1 Population de l entrepôt de données Figure III-2 Schéma de fragmentation Genre=F / IJB sur l attribut Genre Figure III-3 Données chargées pour l exécution de la requête : cas FH sur Ville Figure III-4 Données chargées pour l exécution de la requête : cas IJB sur Ville Figure III-5 : Notre approche de sélection d IJB et FH avec classification Figure III-6 : Représentation graphique de la classification hiérarchique Figure III-7 : Centroïde d une classe de trois données Figure III-8 : Répartition des attributs en fonction de leurs poids Figure III-9: Démarche de sélection d un schéma de fragmentation... 82

7 Figure III-10: Schéma en étoile d un entrepôt de données Figure III-11 : Codage d un schéma de fragmentation Figure III-12: Remplissage de la colonne «COL» dans les dimensions Figure III-13: Remplissage de la colonne «COL» pour Figure III-14: Exemple de sous schéma après fragmentation Figure III-15: Schéma d entrepôt de données en étoile et fragmenté Figure III-16: Démarche de sélection d IJB Figure IV-1: Architecture générale de l outil AdminFIC Figure IV-2: Visualisation de l état de l entrepôt Figure IV-3: Choix de paramètre pour le génétique et k-means Figure IV-4: Paramétrage de l approche OAC Figure IV-5: Résultats de sélection par OAC Figure IV-6: Paramétrage de l approche OS Figure IV-7: Résultats de sélection par OS Figure IV-8 : Schéma en étoile de l entrepôt expérimental Figure IV-9 : Répartition des attributs en fonction du poids de classification Figure IV-10 : Coût d'exécution (E/S) pour différents modes Figure IV-11 : Taux de requêtes optimisées Figure IV-12 : Taux de réduction du coût de la charge de requêtes Figure IV-13 : Effet de W sur le coût (E/S) Figure IV-14 : Effet de W sur le taux d optimisation des requêtes Figure IV-15 : Comparaison entre OAC et OS par variation de l espace de stockage Figure IV-16 : Temps de sélection d un schéma de FH (variation de W) Figure IV-17 : Temps de sélection d IJB (variation de W) Figure IV-18 : Temps de sélection d un schéma de FH (variation de S) Figure IV-19 : Temps de sélection d IJB (variation de S) Figure IV-20 : différentes exécutions pour FH et IJB Figure IV-21 : Optimisation selon la formulation du poids de classification

8 Liste des tableaux Tableau I-1 : Différences entres les données opérationnelles et les données décisionnelles... 3 Tableau I-2 : Comparaison entre modèle MOLAP et modèle ROLAP... 9 Tableau I-3 : comparaison des techniques d optimisation Tableau II-1 : Synthèse de travaux sur les index Tableau II-2 : Comparaison entre travaux de fragmentation Tableau II-3 : Représentation d un codage d une hiérarchie pour IJB encodé Tableau III-1 : Calcul du poids des attributs dimension Tableau III-2 : Coordonnées des attributs dimension Tableau III-3 : Paramètres du modèle de coût pour la fragmentation Tableau III-4 : Paramètres du modèle de coût pour les index Tableau III-5 : Numérotation des fragments dimension Tableau IV-1 : Calcul du poids de classification Tableau IV-2 : Schéma de fragmentation optimal pour OAC Tableau IV-3 : Schéma de fragmentation optimal pour OS Tableau IV-4 : Temps de réalisation des tests expérimentaux

9 Introduction générale Introduction L informatique décisionnelle permet l'exploitation des données d une organisation dans le but de faciliter la prise de décision. Elle est aujourd hui omni présente dans tous les secteurs d activités (économique, médical, militaire ou autre). Ces secteurs produisent et manipulent de très importants volumes de données stockés dans des entrepôts de données alimentés par des sources hétérogènes (données financières, informations concernant des clients, données provenant de site web ou autre). Les données dans un entrepôt sont organisées en cube multidimensionnel où chaque dimension est un axe d analyse et chaque cellule est le fait analysé. Pour le stockage physique, le modèle relationnel ROLAP est utilisé, où chaque fait est stocké dans une table de fait, très volumineuse (Giga ou Terra Octets), liée par clés étrangères à plusieurs tables de dimension formant ainsi un schéma en étoile. Le volume de données exploité dans les entreprises est en perpétuel augmentation. Cette exploitation réside dans l interrogation des données (stockées en entrepôt) par des requêtes décisionnelles très complexes et très gourmandes en temps d exécution (des heures voir des jours). Cette complexité réside dans le fait que ces requêtes renferment le plus souvent des opérations de jointures en étoiles entre table de fait volumineuse et tables dimension avec opérations de sélection sur les dimensions. Afin de satisfaire le besoin des décideurs, le temps de réponse aux requêtes doit être réduit en réduisant le coût de chargement de données de l entrepôt pour le calcul de ces requêtes. Ainsi, des techniques d optimisation sont mises en œuvre afin de réduire la complexité de ces requêtes. Parmi les techniques d optimisations utilisées, on trouve les techniques redondantes comme les index, les vues matérialisées et la fragmentation verticale, et les techniques non redondantes comme la fragmentation horizontale. Concernant la fragmentation de données, elle permet de répartir les données d un entrepôt en plusieurs partitions pouvant être accédées séparément. La fragmentation verticale optimise l exécution des requêtes de projection mais nécessite des jointures entres fragments pour retrouver la relation initiale. Quand à la fragmentation horizontale, elle permet de répartir les tuples de données en plusieurs fragments dont la reconstitution est faite par opération d union. Plusieurs travaux se sont intéressés au développement d algorithmes de fragmentation particulièrement dans le contexte des bases de données et cela depuis les années 70. L intérêt pour la fragmentation dans les entrepôts de données est apparu un peu plus tard, plus particulièrement la fragmentation horizontale, car celle-ci ne nécessite pas de jointures pour la reconstruction des relations initiales, surtout que la jointure est une opération très coûteuse dans les entrepôts de données. Pour ce qui est des index, ils sont classés parmi les techniques d optimisation redondante. Ils nécessitent un espace de stockage supplémentaire. Malgré cela, ils sont très utilisés pour l optimisation des requêtes dans le contexte de bases de données et celui d entrepôts de données, particulièrement les index de jointure binaires qui consomment un minimum d espace grâce aux bitmaps et qui optimisent les requêtes de jointures en étoile. Dans la littérature, le problème de sélection d un schéma de fragmentation ou le problème de sélection d index on été largement étudié. Par contre, rares sont les travaux qui traitent les deux problèmes combinés. En effet, la fragmentation horizontale (FH) et les index de jointure binaires (IJB) sont similaires du fait qu elles visent à optimiser les jointures en étoile très gourmandes en temps et en ressources. De plus, elles sont toutes deux définis sur les mêmes attributs issus des tables de dimensions, il serait dont intéressant de les sélectionner de manière combinées. Les 1

10 Introduction générale principaux travaux qui traitent la sélection combinées de schéma de fragmentation et index sont (Bellatreche, et al., 2008a), (Boukhalfa, et al., 2008b) et (Stöhr, et al., 2000). Dans le contexte d entrepôts de données, les attributs dimensions servent à effectuer des analyses décisionnelles. Le nombre de ces attributs peut être du nombre de 100, 200 attributs ou plus. Par conséquent, définir un schéma d optimisation sur un tel ensemble d attribut devient une tâche difficile. Ainsi, nous proposons une nouvelle démarche de sélection combinée d IJB et un schéma FH qui permet d effectuer l élagage de l ensemble d attribut et de le partager entre fragmentation et index. Notre démarche se base sur l étude du partage des attributs de dimensions entre les deux structures dans le but de choisir, d un coté, les attributs les mieux adaptés pour la fragmentation et, d un autre côté, ceux qui permettent de mettre en œuvre les index les plus efficaces. De plus, l élagage de l ensemble d attributs permet de réduire le nombre de configurations possibles pour la sélection de chaque technique (la sélection d un schéma de fragmentation sur 50 attributs est plus efficace que sur 100 attributs). Notre mémoire est organisé en quatre chapitres. Dans le premier chapitre, nous commençons par une introduction au concept général d un entrepôt, nous abordons ses implémentations physiques puis nous parlons de la problématique liée aux entrepôts. Par la suite, nous abordons les techniques d optimisation des entrepôts : définition, concept général et classification des techniques. Dans le second chapitre, nous abordons le problème de sélection des techniques d optimisation dans les bases de données en général et les entrepôts de données en particulier. Nous présentons un état de l art sur les travaux effectués dans ce sens, plus particulièrement les index et la fragmentation, et une comparaison des travaux pour chaque technique citée. Nous mettons l accent sur les techniques les plus adaptées dans les entrepôts de données : la fragmentation horizontale et les index de jointures binaires, ainsi que les travaux de sélection combinée. Le troisième chapitre est consacré à la description détaillée de l approche proposée. Nous décrivons l architecture de notre sélection combinée, la démarche de sélection des structures d optimisation et les concepts important pour réalisée notre approche comme le modèle de coût qui permet de guider la sélection des techniques d optimisation ainsi que les algorithmes de sélection implémentés. Le quatrième et dernier chapitre est consacré à la description de l outil que nous avons implémenté et nommé «AdminFIC». C est un outil d assistance et d administration d entrepôt de données qui permet d assister l administrateur pour la sélection d une stratégie de sélection et de validé notre approche proposée. Nous décrivons ensuite l environnement expérimental : l entrepôt de données réel et la charge de requêtes. Enfin, nous terminons par l étude expérimentale et les tests effectués sur site réel sous le SGBD Oracle 11g, qui montre l apport de notre nouvelle démarche et les améliorations apportées au coût d exécution des requêtes sur l entrepôt de données réel. 2

11 I. Chapitre I : Techniques d optimisation des entrepôts de données Dans l informatique décisionnelle, les entreprises exploitent de grands volumes de données stockés dans des entrepôts de données. Ces données sont issues de différentes sources hétérogènes et leurs volumes sont destinés à augmenter sans cesse. L exemple type est le domaine des télécommunications (opérateurs téléphoniques) où l entreposage des données constitue un axe vital autour duquel tourne toute la stratégie de l entreprise de télécom. Un entrepôt de données possède une structure scalable permettant l ajout continuel de nouvelles sources de données, ce qui provoque l augmentation continuelle du volume de données. Par conséquent, l exécution des requêtes devient de plus en plus complexe et nécessite alors d introduire des techniques d optimisation qui auront pour rôle de réduire les délais d exécution. Ainsi, la tâche de gestion et d administration de l entrepôt de données devient un véritable challenge. En effet, la gestion des entrepôts de données requière une bonne connaissance des méthodes de conceptions logiques et physiques, une bonne maitrise des structures physiques (index, vues matérialisées, etc.) afin de choisir la politique de conception optimale susceptible d améliorer les performances des traitements. Nous présentons dans ce chapitre un état de l art sur les techniques d optimisation des entrepôts de données, nous commençons par une introduction au concept général d un entrepôt, nous abordons ses implémentations physiques puis nous parlons de la problématique liée aux entrepôts. Par la suite, nous abordons les techniques d optimisation des entrepôts. Nous présentons leurs définitions, différents concepts et similarités pour finir par la description de l optimisation dans le SGBD Oracle. I.1 L entrepôt de donnée (ED) I.1.1 Définition Type de données Opération Données opérationnelles Orientées application, détaillées, précises au moment de l accès Lecture, mise à jour, insertion et suppression. Données décisionnelles Orientées activité (sujet), condensées, représentent des données historiques Lecture et d insertion Mise à jour Immédiate Différée par lot (par jour, par semaine) Accès aux données Par une personne à la fois Par l ensemble des analystes Redondance Pas de redondance Peuvent être redondantes Exploitation Petite quantité de données utilisées par un traitement Grande quantité de données utilisée par les traitements Taille En gigaoctets En téraoctets Tableau I-1 : Différences entres les données opérationnelles et les données décisionnelles Apparus pour gérer de grands volumes de données issues de différentes sources hétérogènes, l entrepôt de données représente la consolidation d un volume important de données de plusieurs sources ou systèmes opérationnels hétérogènes (bases de données opérationnelles) en une localisation centralisée. Il permet d effectuer des études et analyses sur des données décisionnelles. Ces données diffèrent des données opérationnelles sur plusieurs points résumés dans le tableau I-1 (Desnos, 2008). L entrepôt de données a été formalisé en 1990 par Bill Inmon. 3

12 Chapitre I : Techniques d optimisation des entrepôts de données Il s agit de constituer une base de données orientée sujet, intégrée et contenant des informations historisées, non volatiles et exclusivement destinées aux processus d aide à la décision (Inmon, 1992). Les données de l entrepôt sont (Encinas, 2005) : 1) Orientées sujets ou métier : les données sont organisées selon l activité de l organisme qui déploie l entrepôt (produit, clients, vendeur) (figure I-1). L intérêt d une telle représentation est de faciliter la réalisation des analyses sur ces différentes activités. 2) Intégrées : l intégration permet la mise en forme et l unification des données afin d'avoir un état cohérent et résoudre les problèmes d hétérogénéité (figure I-1). En effet, les données intégrées possèdent une codification et un niveau de détail différent que celui de l entrepôt. Cette intégration nécessite une bonne maîtrise de la sémantique et des règles de gestion, s appliquant aux données manipulées, spécifiées au sein des métadonnées de l ED. Source 1 Données Client Source hétérogènes.. Intégration, unification Données Vente Données orientées sujet Source n Données Produit Figure I-1: Intégration des données en données orientées sujet 3) Historisées : plusieurs versions de données sont stockées dans l ED permettant ainsi de conserver un historique. Ceci permet d effectuer des analyses comparatives dans le temps. 4) Non volatiles : Afin de conserver la traçabilité des informations et des décisions prises, les données d un ED ne doivent pas être supprimées. Cela rejoint le caractère historisé des données pour pouvoir effectuer des analyses sur une longue période. I.1.2 Principe général Figure I-2 : Structure d un EDR La figure I-2 montre le principe général de l ED [1]. Ce principe est structuré en quatre axes importants (Encinas, 2005) : - Différentes données sont chargées dans l entrepôt à partir de plusieurs sources de données hétérogènes (bases de données relationnelles, objet ou encore des fichiers XML). 4

13 Chapitre I : Techniques d optimisation des entrepôts de données - Le chargement des données s effectue à travers le processus ETL (Extract, Transform and Load) par lots. ETL permet d'extraire les données des différentes sources, de les nettoyer afin d'éliminer les valeurs non conformes et les incohérences, et de les charger dans l ED selon les règles de gestion. Cette dernière étape nécessite de prévoir les pannes de chargement et de revenir à l état précédent sans altérer l historique. - Une fois chargées, les données de l entrepôt sont structurées d une manière multidimensionnelle afin de les mettre à disposition des décideurs (cf. section I.1.4). - Une fois l ED conçu, plusieurs outils d aide à la décision sont utilisés comme les outils de datamining, d'analyse des tendances ou de prédiction. Ce qui permet d établir une planification de stratégie pour prendre les décisions pertinentes concernant l entreprise. I.1.3 Type de données L organisation des données doit faciliter l analyse décisionnelle. Cette organisation peut se structurer en quatre classes importantes qui sont présentées dans ce qui suit (Encinas, 2005) : - Les données détaillées : représentent les données fraichement extraites à partir des différentes sources opérationnelles. Elles reflètent donc les événements les plus récents. - Les données agrégées : correspondent à des données regroupées selon le sujet et besoins des utilisateurs (Produit : Groupe Famille Type). Elles peuvent dors et déjà constituer un résultat d analyse et une synthèse de l information contenue dans le système décisionnel, et doivent être facilement accessibles et compréhensibles. - Les données historisées : Chaque nouvelle insertion de données ne détruit pas les anciennes valeurs, mais créée une nouvelle occurrence munie d une étiquette temporelle. - Les métadonnées : ce sont des données définis sur les données. Il représente un dictionnaire unique qui résout l hétérogénéité des données sources et permet de maintenir leur cohérence. I.1.4 Modèles de données I Les cubes de données Les données dans l entrepôt doivent être organisées de manière à faciliter leur exploitation et leurs analyses par les décideurs. L analyse est effectuée selon plusieurs axes d analyses : temporelles, selon la localité ou encore l analyse des tendances. Ainsi, la représentation des les données ne ce fait plus sous forme de tables (SGBD relationnel) (Desnos, 2008) mais sous forme de cube ou hypercube centré sur une activité de dimension n. Exemple 1 : La figure I-3 illustre un exemple de cube de données. Il représente la répartition de ventes suivant plusieurs axes d analyse : temps, localité ou région et catégorie. (Teste, 2000). Figure I-3 : Cube de données On retrouve dans le cube deux concepts important : 5

14 Chapitre I : Techniques d optimisation des entrepôts de données - Concept de fait : Etant considéré comme un point du cube de données, le fait représente le sujet analysé (Desnos, 2008), il est formé de mesures correspondant aux informations de l'activité étudiée. Ces mesures sont calculables à partir d un grand nombre d enregistrement en appliquant les opérations d addition, de calcul du minimum ou de la moyenne. En prenant le fait «Vente» de l exemple précédant, les mesures d activité peuvent être «quantité de produits vendus» et «montant total des ventes» (Teste, 2000). - Concept de dimension : La dimension représente l axe d analyse de l activité. Elle regroupe des paramètres et des informations pouvant influencer les mesures d activités du fait. Elle est munie d une ou plusieurs hiérarchies permettant de faire l analyse d un niveau faible de détail vers un niveau plus détaillée. On peut prendre l exemple de la dimension «Temps» qui peut être hiérarchisée comme suit : «années, mois, semaines et jours» (Teste, 2000). I Les magasins de données (Datamarts) Un entrepôt de données peut être fragmenté selon le sujet des données donnant lieu à des magasins de données ou datamarts (figure I-4). Un datamart représente un extrait de l entrepôt dont les données son orientées sujet (Service, clients, etc.) (Teste, 2000). I.1.5 Implémentation d un ED Figure I-4 : Magasins de données (datamarts) Pour l implémentation des cubes de données, il existe plusieurs modèles qui permettent de stocker les données multidimensionnelles. Mais avant d introduire ces modèles, nous allons invoquer le processus d interrogation des données multidimensionnelles : le Serveur OLAP. I Serveur OLAP Dans les EDs, l analyse multidimensionnelle est effectuée par le processus OLAP (On-Line Analytical Processing). Contrairement à OLTP (processus transactionnels en ligne pour l interrogation des bases de données), qui ne supporte pas l analyse temporelle (Ventes sur une durée de cinq ans), le processus OLAP supporte efficacement les applications d'aide à la décision (Guerrero, 2002). Il permet d effectuer des traitements complexes visant à interroger, visualiser et synthétiser ou agréger un grand volume de données. Il accomplit l analyse d un nombre d'enregistrements importants aux structures hétérogènes (Teste, 2000). Afin d être interrogées et exploitables, les données multidimensionnelles doivent être implémentées physiquement. Cette implémentation est réalisée par des modèles de données comme le modèle ROLAP et le modèle MOLAP. I Modèle ROLAP Le modèle ROLAP (Relational OLAP) utilise un modèle relationnel pour la représentation du cube de données (Bellatreche, 2000), (Guerrero, 2002). Chaque fait correspond à une table appelée table de fait et chaque dimension correspond à une table de dimension. La table de fait va 6

15 Chapitre I : Techniques d optimisation des entrepôts de données avoir comme attribut les mesures d activités et les clés étrangères vers les tables de dimension. Ce modèle a pour avantage l utilisation des systèmes de gestion de bases de données existant, ce qui réduit le coût de mise en œuvre. Néanmoins, le temps de réponse de l exécution des requêtes SQL s avère être très élevée vu la taille énorme de la table de fait. Dans le modèle ROLAP, trois représentations sont possibles, le schéma en étoile, en flocon de neige et en constellation. Nous présentons dans ce qui suit ces trois schémas (Encinas, 2005): a) Schéma en étoile Le schéma en étoile est le plus répondu dans les systèmes d implémentation des entrepôts de données. C est un schéma relationnel où la table des faits est normalisée, mais les tables de dimension ne sont pas normalisées (Encinas, 2005). La figure I-5 montre un schéma ROLAP en étoile avec Vente comme table de fait et Temps, Produit et Régions comme dimensions. Produit Code_prod Typeprod Classe Nomprod Couleur Vente Code_prod Code_temps Code_rég Quantité Montant Région Code_rég Ville Pays Temps Code_temps Année Mois Jours Figure I-5 : Modèle ROLAP : Schéma de données en étoile Les requêtes typiques de ce schéma sont appelées requêtes de jointure en étoile (Star-Join Queries) qui ont les caractéristiques suivantes (Bellatreche, 2000) : - Il y a des jointures multiples entre la table des faits et les tables de dimension. - Il n y a pas de jointure entre les tables de dimensions. - L opération de sélection est souvent effectuée sur les tables de dimensions. Le problème majeur de ce type de représentation et la non-normalisation des données. En conséquence à cela, il existe une redondance des données dans les tables de dimensions. De plus ce schéma ne reflète pas de manière explicite les hiérarchies des dimensions (Guerrero, 2002). b) Schéma en flocon de neige Produit Code_prod Typeprod Classe Nomprod Couleur Pays Pays Ville Ville Pays Ventes Code_prod Code_temps Code_rég Quantité Montant Région Code_rég Ville Année Années Temps Code_temps Jours Mois Mois Années Figure I-6 : Modèle ROLAP : Schéma de données en flocon de neige Jours Jours Mois 7

16 Chapitre I : Techniques d optimisation des entrepôts de données A la différence du schéma en étoile, le schéma en flocon de neige permet de normaliser les tables de dimensions. La figure I-6 montre la normalisation des dimensions «Temps» en «Temps Jours Mois Années» et la dimension «Région» en «Région Ville Département». Cette normalisation réduit la redondance des données mais augmente le temps d exécution des requêtes qui nécessite plus de jointure (Encinas, 2005), (Guerrero, 2002). c) Schéma en constellation Produit Code_prod Typeprod Classe Nomprod Couleur Ventes Code_ prod Code_temps Code_rég Quantité Montant Temps Code_temps Année Mois Jours Fournisseur Code_four RaisonSociale Adresse Figure I-7 : Modèle ROLAP : Schéma de données en constellation Le schéma en constellation représente le regroupement de plusieurs schémas en étoiles qui possèdent des dimensions communes. Il est employé lorsque les faits analysés ne sont pas tous déterminés par les mêmes dimensions (Guerrero, 2002). Prenant le schéma en constellation illustré sur la figure I-7. Ce schéma comporte deux tables de fait «Vente» et «Approvisionnement». Ces deux tables on les dimensions «Produit» et «Temps» en communs. La différence est que les ventes sont analysées par régions et que les faits d approvisionnement nécessitent la spécification du fournisseur. I Modèle MOLAP Approvisionnement Code_prod Code_temps Code_four Quantité Montant Région Code_rég Ville Pays Région Algérie France Temps Alger Oran Taref Paris Légende 10/01/ /01/ /02/2009 P1 P2 P3 P4 Produit Figure I-8 : Tableau multidimensionnel de données, modèle MOLAP Les systèmes de type MOLAP (Multidimensional OLAP) est une approche qui permet de représenter les données de l entrepôt sous la forme d un tableau multidimensionnel à n dimensions, où chaque dimension de ce tableau est associée à une dimension de l hypercube de données. La figure I-8 représente un tableau multidimensionnel «T» pour le stockage d un cube de données. Ce tableau possède trois dimensions, chacune est un axe d analyse : «Région» 8

17 Chapitre I : Techniques d optimisation des entrepôts de données «Produit» et «Temps». Chaque case du tableau T [i, j, k] renferme le montant et la quantité de la vente du produit i, dans la région j et du temps k. L avantage principal de cette technique est le gain considérable en temps d exécution des requêtes, vu que l accès aux données est direct. Par contre, elle présente certaines limites telles que (Bellatreche, 2000): - Redéfinir les opérations SQL pour manipuler des structures multidimensionnelles. - La difficulté de la mise à jour et de la gestion du modèle, - La consommation de l espace lorsque les données sont creuses, ce qui nécessite l utilisation des techniques de compression. I Comparaison des modèles d implémentation Modèle ROLAP MOLAP Stockage de données Accès aux données Coût de mise en œuvre Schéma relationnel Lent (requêtes avec jointures en étoiles sur des tables volumineuses) Aucun (exploitation des SGBD relationnels existants) Tableau multidimensionnel Direct et rapide (accès aux cases du tableau) Redéfinition des opérations SQL sur les tableaux Espace réservé Tout l espace est utilisé Données creuses, espace perdu Tableau I-2 : Comparaison entre modèle MOLAP et modèle ROLAP Le tableau I-2 résume les points de différence entre les deux modèles d implémentation d un cube de données. Nous remarquons que le modèle ROLAP est le plus approprié, il n introduit aucun coût de mise en œuvre car il se base sur un modèle relationnel permettant d exploiter les SGBD relationnels existants. De plus, le modèle MOLAP cause la perte d espace de stockage à cause des données creuses. Le seul avantage de ce dernier, par rapport au modèle ROLAP, est la rapidité d accès direct aux données devant un accès lent des requêtes au schéma relationnel. I.1.6 L entreposage de données dans Oracle Le principe d entreposage de données a été introduit par Oracle dès sa version 8i en 1999 (Hobbs, et al., 1999). Depuis, Oracle à enrichit ce concept dans les versions 9i, (Lane, et al., 2002), 10g (Powell, 2005) et 11g (Rittman, 2009). En effet, il possède plusieurs produits pour gérer les ED, les données multidimensionnelles et l analyse décisionnelles, comme «Oracle Warehouse Builder» qui supporte le processus ETL pour l extraction transformation et chargement des données, «Oracle OLAP» qui représente un moteur pour l exécution des requêtes analytiques complexes accédant à des données multidimensionnelles et «Oracle Data Mining» qui permet de produire des informations prédictives exploitables et d élaborer des applications de business intelligence intégrées [3]. I.1.7 Problématique liée aux entrepôts de données Les ED intègrent, dans une même localité, des données issues de différentes sources dont le nombre peut augmenter (ajout de nouvelles sources). L intégration des données par processus ETL se fait par lot et périodiquement, cela afin d assurer la cohérence entre les données entreposées et les données présentes dans les sources opérationnelles. Cela signifie que le volume de données dans un ED est destiné à augmenter sans cesse. Le concept d entrepôt de données génère plusieurs problématiques comme : 9

18 Chapitre I : Techniques d optimisation des entrepôts de données - L augmentation du volume de données peut nécessiter l augmentation de l espace de stockage. Le grand leader en matière d'entrepôts de données «Teradata» propose une solution de stockage qui offre la possibilité d ajouter une capacité de stockage à très moindre coût et de rentabiliser la performance afin de répondre aux besoins des utilisateurs commerciaux en entreprise [4]. - Les données sont hétérogènes. Cette hétérogénéité ne touche plus seulement la représentation des données mais également leurs formats. Par conséquent de nouveaux types d entrepôts de données sont proposés, comme les entrepôts de données XML (Mahboubi, 2009) - A cause de la volumétrie grandissante des données et leur hétérogénéité, les opérations d analyses deviennent très complexes et le temps de réponse des requêtes décisionnelles de plus en plus long. Il faut donc prévoir une stratégie d optimisation des ED afin de permettre de réduire le temps de réponse et le coût d exécution des requêtes d analyse. Afin de palier au problèmes d accès lent aux données d un entrepôt, une grande panoplie de structures d optimisation est proposée afin de gérer les grands volumes de données, de réduire la difficulté d analyses décisionnelles et de permettre aux décideurs d atteindre les résultats voulus en un temps réduits. Cela dit, il faut savoir choisir l optimisation adéquate parmi toutes les stratégies et techniques existantes. Ainsi, dans les sections qui suivent, nous allons introduire les techniques d optimisation des requêtes dans les entrepôts de données. Nous allons définir leurs concepts, analyses d éventuelles similarités entre elles et les procédés de sélection. I.2 Techniques d optimisation des entrepôts de données Afin d adopter une politique d optimisation d un ED, il faut être en mesure de choisir la technique d optimisation adéquate, la nature de sélection nécessaire et l algorithme de sélection (Bellatreche, et al., 2008a), afin d assurer une réduction de la complexité d exécution des requêtes et du temps et coût d exécution. Il existe deux classes de structures d optimisation (Bellatreche, 2000): Les techniques redondantes dont l utilisation produit une duplication des données : les index, les vues matérialisée et la fragmentation verticale. Les techniques non redondantes ne dupliquent pas les données. Parmi ces techniques on trouve la fragmentation horizontale et le data clustering qui permettent de réorganiser la représentation physique des données, le traitement parallèle qui permet d exécuter les opérations en parallèle pour un gain de temps de traitement. Généralement, les structures d optimisation sont implémentées en se basant sur les requêtes les plus fréquemment exécutées. Elles sont définies sur des prédicats de sélection et attributs de sélections extraits à partir de ces requêtes et figurant dans la clause WHERE. Les prédicats de sélection sont du type : ( ), (, ), ou. Avec A attribut de sélection, v1, v2 les valeurs possibles de A et,,,,. Exemple 2 : On considère un entrepôt de données avec deux dimensions Produit, Client et une table de fait Vente. Soit la requête suivante : SELECT * FROM Vente V, Produit P, Client C WHERE V.Id_Client=C.Id AND V.Id_Produit=P. Id AND C.Ville= Alger AND P.Classe= A 10

19 Chapitre I : Techniques d optimisation des entrepôts de données La requête contient deux prédicats de sélection «Ville= Alger» et «Classe= A» et donc deux attributs de sélection : «Ville» et «Classe». Il est à noter que les prédicats «V.Id_Client=C.Id» et «V.Id_Produit=P. Id» sont appelés prédicats de jointure. Dans ce qui suit, nous allons présenter les index, vues matérialisées et fragmentation verticale comme techniques redondantes. Concernant les techniques non redondantes nous allons présenter uniquement la fragmentation horizontale. I.2.1 Les techniques redondantes Les techniques redondantes sont des structures d optimisation qui nécessitent un espace de stockage supplémentaire pour leur implémentation. Elles causent ainsi une redondance des données qui sont présentes à la fois dans les tables et dans les structures d optimisation. I Les index Les index sont utilisés pour réduire les délais d exécution des requêtes afin de gagner en temps et en performance. L utilisation des index peut optimiser les requêtes qui requière d ordonner les tuples selon un ou plusieurs attributs comme les clauses GROUP BY et ORDER BY. Les index réduisent aussi le nombre d opérations d entrée sortie surtout pour les opérations de jointures. Si l attribut de jointure entre deux ou plusieurs tables est indexé, il suffit juste de calculer la jointure en utilisant les index sans pour autant accéder aux tables. Nous présentons les différents types d index dans le contexte de bases de données ou entrepôts de données. Nous abordons par la suite l intérêt des index ainsi que les index les plus appropriés dans les entrepôts de données. a) Types d index Nous allons présenter, dans ce qui suit, les techniques d indexation utilisées dans les contextes de bases de données relationnelles et d entrepôts de données. 1. Les index simples : Regroupent les index B-arbres et les index de projection. L index B-arbre est défini sur un attribut d une table. Les nœuds de l arbre renferment les valeurs ordonnées de l attribut et les feuilles contiennent des clés vers les tuples de données stockés sur disque. Un B-arbre permet d accélérer les opérations de recherche par clé et par intervalle, ce qui explique son utilisation dans la plupart des SGBD. Quand à l index de projection, il représente une copie parfaite de toute une colonne d un attribut donné. Ce type d index est très bénéfique pour l optimisation des requêtes contenant la clause GROUP BY. 2. Les index de jointure : Etant très coûteuse en temps d exécution, la jointure entre deux tables peut être précalculée et stockée dans un index (figure I-9) (Bellatreche, 2000). Département D_Id NomD Ville Budget Info Math Alger Oran Index de jointure D_Id E_Id Employé E_Id EID Ville natale Alger Oran Alger Figure I-9 : Exemple d index de jointure 11

20 Chapitre I : Techniques d optimisation des entrepôts de données Exemple 3 : Soient deux tables «Département» et «Employé» et l index de jointure qui précalcule la jointure entre les deux tables sur l attribut «Ville» (figure I-9). Cet index permet d optimiser les requêtes contenant une équijointure avec Département.Ville = Employé.Ville. 3. Index de jointure en étoile : L index de jointure en étoile est adapté aux requêtes définies sur les entrepôts de données modélisés en étoile. Il permet de stocker le résultat de la jointure entre la table de fait et les tables de dimensions (figure I-11). Il est dit complet s il regroupe toutes les tables de dimension, partiel sinon. Il accélère l opération de jointure mais exige beaucoup d'espace de stockage et un coût de maintenance très élevé (Aouiche, et al., 2005). Exemple 4 : Soit un ED avec un schéma en étoile contenant une table de fait «Vente» et trois dimensions «Client», «Temps» et «Produit» (figure I-10). Temps Id Mois Année Produit Id Classe Vente Id_Temps Id_ Client Id_ Produit Prix_Unit Client Id Age Genre Pays Figure I-10: Schéma en étoile d un entrepôt de données L index de jointure en étoile précalcule la jointure entre les quatre tables (figure I-11). Index de jointure en étoile Vente_1 Client_1 Produit_1 Temps_2 Vente_1 Client_2 Produit_3 Temps_2 Vente_3 Client_4 Produit_15 Temps_5 Figure I-11: index de jointure en étoile 4. Les index bitmap : étant donné un attribut (Genre par exemple), on assigne, pour chaque valeur de l attribut, un vecteur de 0 et 1. On assigne un 1 si le tuple de la table de la même ligne possède la valeur de la colonne en cour de l index, 0 sinon. Le problème est que pour chaque instance ajoutée dans la table, l index doit être mis à jour. En plus on peut avoir des vecteurs qui contiennent un grand nombre de bit à 0. Comme solution à cela, des méthodes de compressions peuvent être utilisées. Mais la compression reste très coûteuse en temps et peut dégrader les performances du système (Bellatreche, 2000). Exemple 5 : Considérons la dimension «Client», un index bitmap sur l attribut «Genre» donne deux colonne IB1 et IB2 comme suit (figure I-12) : Table Client IB1 IB2 Id Age Genre Pays M F M F M M Algérie Syrie Liban Algérie Figure I-12 : Exemple d index bitmap

21 Chapitre I : Techniques d optimisation des entrepôts de données 5. Index bitmap de jointure (index de jointure binaire IJB) : c est un index généralement calculé sur la table de fait et l attribut indexé de faible cardinalité représente un attribut d une table de dimension. Pour obtenir cet index, il suffit de faire la jointure entre la table de fait et la table de dimension puis de calculer l index sur la clé de la table de fait avec l attribut d indexation. Ainsi, une instance «i» de l index est à «1» si l instance de la table de dimension correspondante à la valeur de l attribut indexé peut être jointe avec l instance «i» de la table de fait, 0 sinon. Exemple 6: Considérons la dimension «Client» et la table de fait «Vente» qui contient les ventes pour les clients. L index de jointure binaire définis sur «Vente» par rapport à l attribut «Genre» est spécifié par la figure I-13. Table Vente IJB Id Id_C Quanté M F Cet index est crée par la syntaxe suivante : CREATE BITMAP INDEX IJB ON Vente (Client.Genre) FROM Vente, Client WHERE Vente.Id_C=Client.Id ; Figure I-13 : Exemple d index bitmap de jointure b) L indexation dans les entrepôts de données Les méthodes d indexation dans les entrepôts de données doivent être différent que ceux utilisées dans les systèmes OLTP. Au cas contraires, on pourrait obtenir des index très volumineux avec un grand nombre de niveau (les B-arbres par exemple). Ainsi, les index les plus fréquemment utilisés pour les ED sont les index de type bitmap, ils possèdent plusieurs avantages à savoir (Darmont, 2009) : - Un faible coût de stockage (l index est une matrice binaire) - Certaines opérations (opérations de comptage, opérations AND, OR) sont très rapides, elles ne nécessitent par l accès aux données est sont effectuées en mémoire centrale. - Les index bitmap sont peu performants dans le cas de mise à jours, cela dit cette opération est rare dans le contexte d entrepôt de données. - Ces index sont plus efficaces que les B-arbres. En effet, les B-arbres sont largement répandus dans les SGBD, mais ils sont limités lorsqu'il s'agit d'indexer des données volumineuses et des attributs à faible cardinalité (Aouiche, 2005). Exemple 7 : S il on veut obtenir le nombre des Ventes des Clients Masculins, pas besoin d accéder aux tables «Client» et «Vente» ni de faire une jointure, il suffit de compter le nombre de 1 dans la colonne M de l IJB de la figure I-13 pour trouver trois. I Les vues matérialisées Les vues matérialisées représentent une technique d optimisation redondante car elle se base sur le principe de matérialisation des requêtes les plus fréquentes et donc de duplication de

22 Chapitre I : Techniques d optimisation des entrepôts de données données. Généralement, ces vues renferment le résultat d exécution de jointures et d agrégation qui sont les opérations les plus coûteuses en temps d exécution. En plus, le gain en temps est obtenu grâce à l accès aux données de la vue dont le nombre d instances est beaucoup moins important que celui des tables de dimensions et de faits. Cependant, la manipulation des vues matérialisées présente deux problématiques importantes : la sélection des vues matérialisées et la maintenance des vues matérialisées a) Problème de sélection des vue matérialisées (PSV) Le problème de sélection des vues matérialisées PSV peut se résumer à trouver une réponse à la question: quelles sont les requêtes qu il faut matérialiser tout en prenant en compte certaines contraintes (espace de stockage réservé, coût de maintenance)? Ainsi, il faut sélectionner un ensemble de vues afin d optimiser le coût d exécution des requêtes sous une contrainte d espace de stockage ou de maintenance. Un problème PSV peut être formulé comme suit (Aouiche, 2005) : Etant donné : - V={v 1,,v n } un ensemble de vues. - Q={Q 1,,Q m } un ensemble de requêtes. - S la taille de l espace de stockage allouée pour les vues. Alors il faut trouver une configuration de vues tel que - Le coût d exécution des requêtes soit minimal - L espace alloué pour le stockage de ces index ne doit pas dépasser S Ce problème est NP-Complet (Bellatreche, 2000), (Aouiche, 2005). Pour le résoudre il faut utiliser des méthodes non exactes comme les heuristiques qui tentent d élaborer une solution optimale ou quasi-optimale en réduisant la complexité de sélection. Les travaux dans ce sens peuvent être divisés en deux classes selon l'objectif de l'optimisation (Bellatreche, 2000): - Algorithmes dirigés par la contrainte d'espace où la taille maximale allouée pour matérialiser les vues ne doit pas dépasser la taille totale de stockage. Les auteurs dans (Aouiche, et al., 2006) proposent une approche de classification des requêtes à base de techniques de Datamining afin de générer les vues matérialisées. - Algorithmes dirigés par le temps de maintenance où le temps de maintenance des vues estimé ne doit pas dépasser un certain seuil fixé au préalable (Gupta, et al., 2005). b) Le problème de la maintenance des vues matérialisée (PMV) Les vues matérialisées représentent le stockage physique du résultat des requêtes fréquemment exécutées sur l entrepôt. Quand de nouvelles données arrivent, il faut s assurer de la cohérence du contenu de ces vues par rapport au nouvelles données en effectuant une mise à jour de la vue. Cela rajoute, d un coté, un coût de maintenance, qui peut surcharger le système, et d un autre coté un espace de stockage additionnel qu il faut leur allouer (Aouiche, 2005). Cette mise à jour doit être considérée selon deux aspects : l instant de mise à jour de la vue et la manière dont le recalcule de la requête qui détermine la vue est effectué (Bellatreche, 2000). Selon l instant de mise à jour, trois stratégies existent - Mise à jour périodique où les vues sont recalculées à des instants déterminés. Dans ce cas elles sont considérées comme des instantanés ou Snapshots. - Mise à jour immédiate signifie que la vues est recalculée dès qu une nouvelle donnée surgie dans l entrepôt - Mise à jour différée, la vue est mise à jour lors de son utilisation par une requête. 14

23 Chapitre I : Techniques d optimisation des entrepôts de données Selon la manière de recalcule de la vue, deux méthodes existent - Mise à jour par recalcule total de la requête qui détermine la vue, cette solution est très coûteuse en temps et est rarement utilisée - Mise à jour incrémentale : exécuter une nouvelle fois la requête de la vue uniquement sur les données qui viennent d être nouvellement chargées ou mises à jour. Pour une vue dont la requête est R S, le recalcule est effectué par une semi jointure entre les nouveaux tuples de R avec la table S : R S Il existe des travaux qui se sont penchés sur le problème de maintenance dans le but d essayer de réduire le temps d exécution des opérations de maintenance. Dans l article (Garcia, 2006), l auteur présente une stratégie de maintenance des vue matérialisée incrémentale. Elle permet d exécuter les requêtes de maintenance des vues en parallèle avec les requêtes OLAP. Cette stratégie est basée sur un algorithme nommé VNLTR pour des requêtes de type SPJ (Sélection Projection Jointure) avec un Group By et les fonctions d agrégation Sum, Avg, Count, Min et Max. Dans (Kim, et al., 2007), l auteur présente une solution de maintenance des vue matérialisées concurrente, où l exécution des requêtes OLTP est parallèle aux requêtes OLAP. Quand une requête OLTP est exécutée dans une source de données, les changements effectués sont momentanément sauvegardés dans d une structure notée VODB avant d être répercutés dans l entrepôt à travers les transactions de maintenance. Par contre, une requête OLAP peut directement s exécuter sur l ED et en parallèle avec la requête OLTP qui s exécute, elle, sur la VODB. Ceci permet de respecter les contraintes de délais pour les requêtes OLAP. Cela dit, pour ce qui est des travaux de (Garcia, 2006) et (Kim, et al., 2007), les mises à jour des vues restent coûteuses en temps et peuvent bloquer d autres transactions. En plus, il n est pas précisé si ces transactions sont elles même exécutées en parallèle, leurs séquentiabilité peut dégrader les performances du système et retarder l exécution des requêtes utilisateurs qui devraient être plus prioritaires que les transactions de maintenance. c) Réécriture des requêtes Afin de bénéficier de l intérêt des vues matérialisées, les requêtes doivent être réécrites afin d utiliser ces vues au lieu des tables. En effet, ces vues sont stockées physiquement sous forme de tables qui peuvent être accédées par les requêtes, indexées ou fragmentées (Bellatreche, 2000). Exemple 8 : Soit un ED de la figure I-10. Soient une requête et une vue représenté comme suit : Vue CREATE MATERIALIZED VIEW VM AS SELECT * FROM Vente V, Produit P WHERE V.Id_Produit=P. Id AND P.Classe= A La réécriture de la requête en utilisant la vue est : SELECT Id_Produit, Sum(Prix_Unit) FROM VM, Client C WHERE VM.Id_Client=C.Id AND C.Ville= Alger GROUP BY Id_ Produit Requête SELECT Id_Produit, Sum(Prix_Unit) FROM Vente V, Produit P, Client C WHERE V.Id_Client=C.Id AND V.Id_Produit=P. Id AND C.Ville= Alger AND P.Classe= A GROUP BY Id_ Produit 15

24 Chapitre I : Techniques d optimisation des entrepôts de données d) Intérêt d utiliser les vues L intérêt de l optimisation par les vues matérialisées est de rendre disponible les résultats intermédiaires pouvant être utilisés par des requêtes complexes. Ceci réduit ainsi la complexité et le coût d exécution des ces requêtes. De plus, pour une meilleure performance, ces vues peuvent elle même être indexée profitant des avantages des index. I La fragmentation verticale La fragmentation verticale permet de diviser une relation verticalement en plusieurs sous relations, chacune va comporter un ensemble d attributs de la relation initiale. Pour chaque sous relation ou fragment vertical, l attribut clé est ajouté afin de pouvoir reconstituer la relation initiale par opération de jointure. Cette technique est redondante car elle duplique la clé primaire de la table fragmentée, plus la duplication d autres attributs selon le besoin de fragmentation. Elle nécessite donc un espace de stockage supplémentaire. La fragmentation verticale accélère les opérations de projection. En effet, le traitement de la requête de projection nécessite uniquement le chargement des sous relation dont les attributs figurent dans la requête, il n est pas nécessaire de charger toute la table. Par contre, son principal inconvénient est quelle nécessite des opérations de jointures très coûteuses si une requête accède à plusieurs fragments verticaux (Bellatreche, 2000). Exemple 9 : Soit une table «Client». Le résultat de fragmentation verticale de cette dimension est présenté dans la figure I-14 Table Client Client1 Client2 Id Nom Age Genre Id Nom Genre Id Age Fragmentation 1 Ali 30 M 1 Ali M Kassi Lee Jones F M M Verticale Kassi Lee Jones F M M I.2.2 Les techniques non redondantes Figure I-14 : Exemple de fragmentation verticale Les techniques non redondantes ne dupliquent pas les données. De ce fait, contrairement aux techniques redondantes, elles ne nécessitent pas un espace de stockage supplémentaire. Nous allons présenter, dans ce qui suit, la fragmentation horizontale comme exemple de structures non redondante. I La fragmentation horizontale La fragmentation horizontale (FH) se base sur le principe de réorganisation des données par la répartition des tuples d une table en plusieurs sous ensembles disjoints, appelés fragments horizontaux et pouvant être accédés séparément. Cette répartition est effectuée par une opération de restriction sur la table initiale et une simple opération d union permet de reconstituer la relation initiale. Deux types de fragmentation horizontale existent : la FH primaire et la FH dérivée 1. La fragmentation horizontale primaire : cette fragmentation horizontale est appelée primaire car elle permet de répartir les tuples d une table suivent la conjonction de prédicats de sélection définis sur les attributs de la même table. Cette fragmentation est réalisée grâce à l application de l opération de restriction sur les tuples de la table à fragmenter. La FH primaire favorise les opérations de sélection portée sur les attributs de fragmentation. 16

25 Chapitre I : Techniques d optimisation des entrepôts de données 2. La fragmentation horizontale dérivée : c est une FH dérivée car elle permet de fragmenter une relation suivant la fragmentation horizontale primaire d une seconde relation, à condition de l existence d une clé étrangère (relation père-fils) qui pointe de la première table (relation membre) à la seconde table (relation propriétaire). Le calcul des fragments dérivés se fait par la semi-jointure des fragments propriétaire avec la relation membre. a) Scénarii de fragmentation horizontale d un entrepôt de données Dans le contexte d entrepôt de données, les opérations les plus coûteuses en temps et en ressources sont les jointures en étoile entre table de fait volumineuse et plusieurs tables de dimensions (Bellatreche, 2000). Afin de bénéficier de la fragmentation horizontale (primaire et dérivée) pour l optimisation de ces opérations, il existe quatre différents scénarii de FH : - Fragmenter les tables de dimension par une FH primaire. Ce scénario est à exclure car il n intègre pas la table de faits qui est très volumineuse comparé aux dimensions souvent de petites tailles. De plus, les requêtes décisionnelles incluent toujours la table de faits. - Fragmenter la table de faits par une FH primaire. Ce type de fragmentation favorise les opérations de sélection qui sont rarement définis sur une table de faits. - Fragmenter les tables de faits et dimension par une FH primaire. Pour la même raison que le scénario 2, les requêtes ne vont pas bénéficier d une telle fragmentation sur la table de faits. - Fragmenter la table de faits par une FH dérivée suivant la FH Primaire des dimensions. Ce dernier scénario est le plus approprié pour les entrepôts de données, il permet d améliorer les opérations de sélections sur les dimensions et les opérations de jointures entre faits et dimension (Boukhalfa, et al., 2008a). Exemple 10 : Soit un entrepôt de données avec une dimension «Client» et une table de faits «Vente». Considérons le quatrième scénario de FH. La table «Client» est fragmentée avec une FH primaire sur l attribut «Genre» en clients féminins et clients masculins. La fragmentation est réalisée par opération de restriction comme suit : - Client1= " é " (Client) - Client2= " " (Client) Le résultat de la FH primaire est illustré sur la figure I-15 : Table Client Client1 Client2 Id Nom Age Genre Id Nom Age Genre Id Nom Age Genre Ali Kassi Lee Jones M F M M FH Primaire Ali Lee Jones M M M 2 Kassi 25 F Figure I-15 : Exemple de fragmentation horizontale primaire La table «Vente», contenant la clé étrangère vers Client «Id_C», est fragmentée par une FH dérivée suivent la FH primaire de «Client», cette fragmentation est obtenue par semi- jointure comme suit : - Vente1= Vente Client1 - Vente2= Vente Client2 Les résultats de FH dérivée sont illustrés dans la figure I-16: 17

26 Chapitre I : Techniques d optimisation des entrepôts de données Table Vente Vente1 Vente2 Id Id_C Quantité Id Id_C Quantité Id Id_C Quantité FH Dérivée Selon Client Figure I-16 : Exemple de fragmentation horizontale dérivée Ce scénario de FH permet d accélérer les requêtes contenant le prédicat de jointure «Client.Id=Vente.Id_C» entre la table de fait Vente et la dimension Client avec prédicat de sélection sur Client «Client.Genre = valeur», où valeur = F ou M. b) Intérêt de la fragmentation horizontale En se plaçant dans le contexte de base de données, la principale difficulté de la fragmentation horizontale est le maintient de la cohérence du schéma de fragmentation lors d opérations de mises à jour. Il faut détecter les fragments concernés par la mise à jour et gérer les migrations de données (fragmentation sur l attribut Age). Par contre, dans le contexte d entrepôt de données, les opérations de mise à jour sont très rares, la plus par des requêtes sont de type SELECT ou INSERT INTO et ne nécessite pas un coût élevé de maintenance. De plus, la fragmentation horizontale présente plusieurs avantages (Boukhalfa, et al., 2008a) qui sont : - Éliminer les partitions non valides pour une requête afin de réduire le temps d exécution. - Paralléliser l accès aux données en stockant les partitions sur des disques durs différents. - Concevoir des magasins de données - Dans le contexte d une base de données réparties, limiter le taux de transfère de données en mettant chaque donnée dans le site qui l exploite le plus. - Créer des index locaux, un index sur chaque partition. Ainsi, seuls les index locaux, correspondants aux partitions exploitées par une requête, seront chargés. - Optimiser les opérations de sélection dans le cas de FH primaire et les opérations de jointures avec opérations sélection dans le cas de FH dérivée I.2.3 Similarité entre techniques d'optimisation dans les entrepôts de données Parmi la panoplie des structures que nous venant de voir, certaines techniques présentent de fortes similarités. Cette similarité réside dans l effet d optimisation, l aspect de représentation et de restructuration des données ou le type de bénéfice apportée par chaque technique. Elle peut s avérer intéressante lors de la sélection d une stratégie d optimisation. En effet, les techniques similaires peuvent être sélectionnées de manière combinées et permettre donc d obtenir une meilleur optimisation. D autant plus que ces structures peuvent avoir des natures différentes : l une redondante et l autre non redondante ce qui réduit l espace de stockage réservé pour l optimisation des données. I Index de jointure binaire et fragmentation horizontale Dans le contexte d entrepôt de données, les index de jointure binaires et la fragmentation horizontale sont deux techniques d optimisation similaires. Elles permettent d accélérer l exécution de requêtes contenant des opérations de jointures en étoile, entre table de faits 18

27 Chapitre I : Techniques d optimisation des entrepôts de données volumineuse et plusieurs dimensions, et opérations de sélection sur les dimensions. Nous allons montrer cette similarité à travers l exemple suivant : Exemple 11 : Soit un ED avec les dimensions «Client», «Produit» et la table de fait «Vente». Nous considérons deux cas d optimisation que nous résumons sur la figure I-17: 1. Optimisation par FH dérivée de «Vente» suivant la FH primaire de «Client» avec l attribut «Genre» 2. Optimisation par IJB définit sur «Vente» suivant le même attribut «Genre». Considérons la requête suivante qui permet de calculé, pour chaque client féminin, la quantité totale de produits vendus. SELECT Nom_Client, Sum(Quantité) FROM Vente V, Client C WHERE V.Id_C=C.Id AND C.Genre= feminin GROUP BY Nom_Client Table Vente Vente1 Vente2 Id Id_C Quantité Id Id_C Quantité Id Id_C Quantité FH Dérivée Selon Client Table Vente IJB Id Id_C Quanté M F Figure I-17 : FH dérivée et IJB sur la table Vente Les deux cas d optimisations permettent d optimiser la requête comme suit : Cas avec FH dérivée, seul le fragment Vente2 (ventes des clients féminin) sera chargé. Sur ce fragment, les deux opérations de regroupement et d agrégation sont effectuées. - Cas avec IJB. Le bitmap qui vérifie «Genre= féminin» est chargé. Les lignes contenant des 1 seront choisies pour permettre de charger les tuples faits des ventes des clients féminins. Sur ces tuples chargés, le regroupement et agrégation sont réalisés. Résumé : Dans les deux cas d optimisations de l exemple présenté, la FH et l IJB ont permit de réduire le coût de chargement de données (seules les ventes de clients féminins sont chargées). De plus, les opérations de jointures et de sélections sur dimensions sont précalculées par chaque structure d optimisation. En résumé, les deux techniques, définies sur les mêmes attributs dimensions, possèdent la même sémantique et permettent de réduire le coût de jointures en étoile entre table de fait et tables dimensions avec opérations de sélection sur ces dimensions. 19

28 Chapitre I : Techniques d optimisation des entrepôts de données I Index de jointure binaires et vues matérialisées Les vues matérialisées, définies sur les entrepôts, permettent d optimiser les requêtes les plus fréquentes et les plus coûteuses. Ces vues renferment des jointures en étoile et opérations de sélections, permettent un gain de coût et temps d exécution et évite le recalcule de ces jointures. Les mêmes opérations de jointures et sélections peuvent être optimisées par IJB d où la similarité entre les deux techniques. I.2.4 Résumé des techniques d optimisation dans les ED Le tableau I-3 montre une comparaison entre les techniques d optimisation dans les entrepôts de données suivant plusieurs critères : la nécessité d un espace supplémentaire de stockage, le besoin ou pas d un coût de maintenance, la transparence d utilisation de la technique pour l utilisateur de l entrepôt, le changement du schéma des relations de base et enfin l apport de chaque technique dans l optimisation des entrepôts de données. Technique Espace de stockage Coût de maintenance Transparence à l utilisateur Changement du schéma Index X X X - Vues matérialisées Fragmentation verticale Fragmentation horizontale X X X - X - X X (altère les relations) - - X - Type d optimisation dans les entrepôts de données Jointures en étoile, opérations de sélection Les requêtes les plus fréquentes Les requêtes de projection Les jointures en étoile, opérations de sélection Tableau I-3 : comparaison des techniques d optimisation Nous remarquons que les index, vues matérialisées et fragmentation verticale nécessitent un espace de stockage puisque ce sont des techniques redondantes. Un coût de maintenance existe uniquement pour les index et vues. Pour ce qui est de la fragmentation (horizontale ou verticale) dans les ED, les opérations les plus fréquentes sont les sélections et insertions qui ne nécessitent pas une maintenance du schéma de fragmentation. Il suffit de détecter le fragment adéquat pour les nouvelles données et les insérer. Certaines techniques provoquent un changement dans le schéma physique initial comme la fragmentation verticale. Cette fragmentation restructure une relation en plusieurs sous relations, chacune contient un sous ensemble d attributs de la relation initiale. Par contre, les utilisateurs d un ED doivent pouvoir exécuter leurs requêtes sans se soucier de la représentation physique des données. Il faut prendre en compte l adaptation des requêtes sur le schéma de données (réécriture des requêtes pour les vues, jointures dans le cas de fragmentation verticale) afin de garantir la transparence d accès aux données pour l utilisateur. I.2.5 Optimisation dans le SGBD Oracle Le SGBD Oracle met en œuvre plusieurs extensions pour répondre aux problèmes d optimisation des requêtes. Ces extensions sont utilisées pour optimiser les traitements et requêtes exécutées sur une base de données ou entrepôt de données avec un schéma relationnel. Notre étude c est porté sur ce SGBD pour sa réputation et grande utilisation. De plus, il permet d implémenter les index de jointures binaires et propose plus d opérations et modes pour la fragmentation horizontale des tables que d autres SGBD (Boukhalfa, et al., 2008a). 20

29 Chapitre I : Techniques d optimisation des entrepôts de données Oracle prend en compte deux types d optimisation : l optimisation des instructions SQL et l optimisation des données par implémentation des techniques d optimisation (Oracle, 2009). Mais avant d introduire ces deux types, nous allons aborder les différentes extensions implémentées. I Extensions pour l optimisation Pour les besoins d optimisation des requêtes décisionnelles, plusieurs extensions ont été mise en œuvre dans le SGBD Oracle, elles sont résumées dans ce qui suit : - SQL Tuning Set : Il constitue l'environnement de base pour recueillir, gérer et optimiser les charges SQL (Oracle, 2009). - SQL Tuning Advisor : Il permet, à parti des instructions SQL, de présenter plusieurs directives et recommandations pouvant être utilisées pour optimiser une charge de requêtes. Il permet de présenter les résultats et interagir avec l administrateur via une interface. Pour ce faire, cet outil utilise des statistiques sur les objets présents dans la base de données (Oracle, 2009). - Automatic Tuning Optimizer : Cette extension se charge de l optimisation des instructions SQL en effectuant le Profiling des instructions SQL (Dageville, et al., 2004). - SQL Access Advisor : Cette extension génère des conseils sur la façon d'optimiser la conception physique d un schéma de données afin de maximiser la performance d accès aux données. Il prend en entrée une charge de requêtes, l analyse et fournit des recommandations concernant la création de nouvelles partitions ou de nouveaux index, la suppression d'index inutilisés ou encore la création de nouvelles vues matérialisées (Dageville, et al., 2004). I Implémentation des techniques d optimisation Le SGBD Oracle propose l implémentation des structures d optimisation à savoir les index, les vues matérialisée et la fragmentation dans l outil SQL Access Advisor. a) Les index Pour les index, Oracle permet d implémenter les index classiques comme les B-arbres, les Index Bitmap et les Index de Jointure Bitmaps. Il offre la possibilité de définir des index partitionnés par spécification du mot clé «Local» lors de la définition de l index. b) Les vues matérialisée Oracle permet l implémentation des vues et la gestion de leurs maintenances suivant les deux modes déjà présentés : mode de mise à jour total par spécification des mots clés «REFRESH COMPLETE» et le mode de mise à jour incrémental grâce aux mots clés «REFRESH FAST». On peut également spécifier le moment de mise à jour avec les clauses suivantes : - ON COMMIT : la mise à jour survient en temps réel - ON DEMAND : les modifications sont sauvegardées et traitées en différé à la demande de l utilisation - START WITH et NEXT : la mise à jour est effectuée de manière périodique. Cette clause précise la date de début et la prochaine date de mise à jour. Exemple 12 : Nous présentons dans ce qui suit un exemple de création d une vue matérialisée. La mise à jour de cette vue est effectuée de manière totale et à la demande de l utilisateur. 21

30 Chapitre I : Techniques d optimisation des entrepôts de données CREATE MATERIALIZED VIEW VM REFRESH COMPLETE ON DEMAND AS SELECT * FROM Vente V, Produit P WHERE V.Id_Produit=P. Id AND P.Classe= A c) La fragmentation horizontale primaire Oracle permet d effectuer la fragmentation d une table suivant selon plusieurs modes de fragmentations. Ces modes sont classés en deux grandes classes : les modes de fragmentation simples et les modes de fragmentation composites. - Les modes simples : représentent une fragmentation à un seul niveau. Ils permettent d effectuer la fragmentation d une table en plusieurs partitions suivant un attribut de fragmentation ou clé de fragmentation C. Chaque partition est définie par une ou plusieurs valeurs de C qui représentent un sous domaine sd i de l ensemble des valeurs de C. Le découpage du domaine de C en n sous domaine sd 1,, sd n permet de spécifier n partitions (figure I-18 (Boukhalfa, et al., 2008a)). A l insertion d un nouveau tuple, on vérifie l appartenance, à un sd i, de la valeur de C dans ce tuple, cela permet de désigné la partition adéquate pour cette insertion. Partition 1 C Domaine de C : sd 1,, sd n... Partition n Table Figure I-18: Mode de fragmentation simple Oracle implémente le mode simple à travers trois modes : RANGE, HASH et LIST : RANGE : chaque sd i représente un intervalle de valeurs de C. Un intervalle est muni d une borne inférieure et une borne supérieure. Cette fragmentation est très bénéfique pour les requêtes d intervalle. HASH : il suffit de spécifier au système la clé de fragmentation et le nombre de fragmentation désirés. En utilisant une fonction de hachage interne du système (Oracle), chaque tuple est attribué au fragment adéquat. LIST : permet d avoir une répartition des données en liste de valeur de la clé de fragmentation. Ce type de FH est très utile pour les requêtes avec des prédicats d égalité. Pour les trois modes, chaque partition est stockée physiquement dans une zone sur le disque appelée TABLESPACE. Exemple 13 : Soit une table «Client» avec les attributs Id, Nom, Genre, Ville et Age. Nous présentant le script de création de la table avec chaque mode de fragmentation simple : a. Mode RANGE : la fragmentation par se mode peut être effectué sur l attribut Age avec le découpage suivant : Age = {[0 20[, [20 40[, [40 100]}. La requête permettant cette fragmentation est la suivante : 22

31 Chapitre I : Techniques d optimisation des entrepôts de données CREATE TABLE CLIENT (Id number(6), Nom varchar(30), Ville varchar(30), Genre char(1), Age number(3) PARTITION BY RANGE(Age) PARTITION Client1 VALUES LESS THAN (20) TABLESPACE TBS1, PARTITION Client2 VALUES LESS THAN (40) TABLE SPACE TBS2, PARTITION Client3 VALUES LESS THAN (MAXVALUE) TABLE SPACE TBS3) Cette fragmentation accélère les requêtes d intervalle sur Age comme : SELECT * FROM Client WHERE Age >40 b. Mode HASH : nous présentons la fragmentation de la table Client par mode HASH sur l attribut clé Id CREATE TABLE CLIENT (Id number(6), Nom varchar(30), Ville varchar(30), Genre char(1), Age number(3)) PARTITION BY HASH (Id) PARTITION 4 STORE IN (TBS1, TBS2, TBS4, TBS4) c. Mode LIST : la fragmentation par liste sur l attribut Ville vise à répartir les tuples de la table Client en Clients d Alger, Client d Annaba et Taref et Client d Oran. Les clients dont la ville n est pas une de celles citées, seront regroupés dans une quatrième partition. CREATE TABLE CLIENT (Id number(6), Nom varchar(30), Ville varchar(30), Genre char(1), Age number(3)) PARTITION BY LIST (Ville) (PARTITION Client1 VALUES ( Alger ), PARTITION Client2 VALUES ( Annaba, Taref ), PARTITION Client3 VALUES ( Oran ), PARTITION Client4 VALUES (DEFAULT)) Cette fragmentation accélère les requêtes avec prédicats de sélection sur Ville : SELECT * FROM Client WHERE Ville = Alger - Les modes composites : représentent la fragmentation d une table en deux niveaux. Le premier niveau est la fragmentation d une table par un mode simple. Le second niveau représente la fragmentation par mode simple en sous partitions des partitions issues de la première fragmentation (figure I-19 (Boukhalfa, et al., 2008a). C1 C2 Table Mode simple C1 Partition 1... Partition n Mode simple C2 Mode simple C2 Sous partition 11 Sous partition 1m1 Sous partition n1 Sous partition n m1 Figure I-19: Mode de fragmentation composite Plusieurs modes composites peuvent être définies à partir des trois modes simples : RANGE- RANGE, RANGE-LIST, RANGE-HASH, LIST-RANGE, etc. 23

32 Chapitre I : Techniques d optimisation des entrepôts de données Exemple 14 : La fragmentation en mode composite de la table «Client» se fait à l aide des clauses SQL PARTITION BY pour le premier niveau et SUBPARTITION BY pour le second niveau. Nous présentons la requête de fragmentation de la table Client avec le mode simple RANGE sur l attribut Age pour le premier niveau, puis la fragmentation avec le mode LIST sur l attribut Genre pour le second niveau (Boukhalfa, et al., 2008a). CREATE TABLE CLIENT (Id number(6), Nom varchar(30), Ville varchar(30), Genre char(1), Age number(3)) PARTITION BY RANGE (Age) SUBPARTITION BY LIST (Genre) TEMPLATE (SUBPARTITION C-Masculins VALUES ( M ), SUBPARTITION C-Féminins VALUES ( F )) (PARTITION Client1 VALUES LESS THAN (20) TABLESPACE TBS-1, PARTITION Client2 VALUES LESS THAN (40) TABLE SPACE TBS-2, PARTITION Client3 VALUES LESS THAN (MAXVALUE) TABLE SPACE TBS-3)) Nous concluons que la fragmentation dans Oracle s applique sur une seule table à la fois sur au plus deux clé de fragmentation. Chaque clé est employé dans la fragmentation par un des trois modes simples RANGE, HASH et LIST. d) La fragmentation horizontale dérivée La FH dérivée est supportée à partir de la version 11g par le mode REFERENCE. Elle est réalisée en deux étapes : la première étape consiste à fragmenté par FH primaire une première table selon un mode simple RANGE, HASH ou LIST. La seconde étape effectue la FH dérivée d une seconde table selon la FH primaire de la première table (à condition de l existence d une relation père-fils entre la première et seconde table). Exemple 15 : soit une table Vente liée par clé étrangère à une table Client. Client est fragmenté par mode simple RANGE sur l attribut Age. Suivant cette FH primaire, la table Vente est fragmentée par mode REFERENCE en une FH dérivée (figure I-20 (Boukhalfa, et al., 2008a)). Id Age RANGE (Age) Client1 Age < 20 Client2 Age < 40 Client3 Age > 40 Client Vente REFERENCE Vente1 Vente Client1 Vente2 Vente Client2 Vente3 Vente Client3 Id_C Clé étrangère Figure I-20: Mode de fragmentation dérivée REFERENCE La requête qui permet de créer la table Vente fragmentée est la suivante CREATE TABLE VENTES (Id_C number(6), Date DATE, Montant Number(8,2) CONSTRAINT Client_fk FOREIGN KEY (Id_C) REFERENCES Client(Id)) PARTITION BY REFERENCE(Client_fk) 24

33 Chapitre I : Techniques d optimisation des entrepôts de données e) Bilan de la fragmentation horizontale dans Oracle La figure I-21 résume l évolution de la fragmentation horizontale sous Oracle. La fragmentation simple par mode RANGE à été introduite dès la version 8 d Oracle. Dans la version 8i, le mode simple HASH est supporté ainsi que le mode composite HASH-RANGE. Les autres modes composites ont été introduit par la suite, mais le mode de FH dérivée REFERENCE n a été développé qu après la version Oracle 11g (figure I-21) 1997 Range Global Range Index Hash Hash-Range List Range-List 8 8i 9i 11g Range-Range, List-Range, List-List, List-Hash Reference Virtual Column Interval Partition Adviser Figure I-21: Mode de Fragmentation Horizontale sous Oracle I Optimisation par Profiling SQL Introduite à partir d'oracle 10g dans le Automatic Tuning Optimizer, cet outil permet d établir une classification des requêtes SQL en Profiles SQL qui sont stockés d une manière permanente dans la base de données. Une fois sauvegardé, ce schéma est utilisé dans l optimisation par profil des requêtes SQL. Il se base sur le regroupement d un ensemble d informations sur les requêtes et schémas de données, obtenues à partir d analyses statistiques et estimations comme le coût de balayage des tables de données ou encore le coût des opérations de jointures (Dageville, et al., 2004). 25

34 Chapitre I : Techniques d optimisation des entrepôts de données Conclusion Les entrepôts de données connaissent une grande utilisation dans l informatique décisionnelle. Cet intérêt pour l entreposage de données grandi de jours en jours causant une grande complexité de mise en œuvre d un coté et des analyses décisionnelles de l autre. Cette complexité induit les concepteurs et administrateurs des entrepôts de données à utiliser les stratégies d optimisations dans le but d optimiser les traitements complexes et réduire le temps de réponse des requêtes. Ce temps de réponse est un facteur important et dont la réduction est vitale pour la stratégie décisionnelle de tout organisme employant un entrepôt de données. Nous avons abordé dans cette partie, le concept général d un entrepôt de données. Nous avons présenté le modèle multidimensionnel des données (cube de données), les différents modèles de stockage (modèle ROLAP et MOLAP) et les types de données qui y sont présentent. Nous avons mentionné que les entrepôts les plus fréquemment utilisés sont les entrepôts de schéma en étoile implémenté par un modèle ROLAP. En effet, ce modèle utilise un schéma relationnel pour la représentation des données et ne nécessite donc pas un coût supplémentaire de mise en œuvre ou d interrogation. Le modèle ROLAP représente l entrepôt sous forme de dimensions qui gravitent autour d une table de fait très volumineuses. Ainsi, les requêtes décisionnelles exécutées sur un tel schéma sont très complexes et nécessitent un temps de réponse très long. Ainsi, nous avons présenté les différentes techniques d optimisations des requêtes dans un ED. Nous avons donné une classification de ces méthodes selon la nécessité ou pas d un espace de stockage supplémentaires. Nous avons également mis le point sur les similarités entre certaines techniques et avons présenté un tableau comparatif qui les classe selon plusieurs critères. Pour finir, nous avons abordé l optimisation dans le SGBD Oracle. Nous avons montré comment Oracle supporte l implémentation des différent techniques d optimisation et quelle sont les différents extensions mise en œuvre pour ce faire. 26

35 II. Chapitre II : Problèmes de sélection des techniques d optimisation Devant la complexité des traitements dans les entrepôts de données ou les bases de données de plus en plus volumineuses, l administrateur, d entrepôts ou bases de données, à la tâche difficile de choisir une politique d optimisation des requêtes et opérations exécutées sur les données. Cette optimisation s effectue durant la phase de conception physique et doit être la plus optimale possible. Elle nécessite de choisir les techniques d optimisation (index, fragmentation, vues, etc.) à implémenter. De plus, l architecture physique des données doit pouvoir supporter l ajout de nouvelles données, les opérations de maintenances ne doivent pas altérer l exécution des requêtes de traitements et l espace de stockage doit être optimisé. Ainsi, plusieurs travaux ce sont intéressés à la sélection des techniques d optimisation dans le but de choisir les techniques les plus adéquates, qui permettent d optimiser les requêtes et réduire le coût d accès aux données. Dans le cadre d entrepôts de données, les opérations les plus coûteuses en temps et en ressources sont les jointures en étoiles entre table de fait volumineuse (plusieurs Gega ou Tera octets) et plusieurs dimensions (certains entrepôts très volumineux peuvent avoir plusieurs dizaines de dimensions). Parmi les techniques qui optimisent ce type d opérations on trouve les index de jointures binaires et la fragmentation horizontale. La première technique est une technique redondante qui nécessite un espace de stockage, mais l utilisation des index bitmaps dans les entrepôts de données est intéressante du fait de la rareté des opérations de mise à jour et de la rapidité d accès à ce type d index. La seconde technique est non redondante, elle permet de répartir les tuples des tables en plusieurs sous ensembles de n-uplets pouvant être accédés indépendamment, ce qui réduit le volume de données chargé pour une requête donnée. Plusieurs travaux traitent la sélection des index d un coté et la sélection d un schéma de fragmentation de l autre. Par contre peu de travaux se sont penchés sur la sélection des index de jointure binaire et de la fragmentation horizontale de manière combinée, malgré le grand intérêt de cette démarche. En effet, seuls les index nécessitent un espace de stockage, et la combinaison des deux permet de couvrir l optimisation d un plus grand nombre de requêtes avec jointures en étoile. Nous allons présenter, dans ce chapitre, un état de l art sur le problème de sélection d index et de schéma de fragmentation, ainsi qu une comparaison des différentes approches, ceci dans un contexte général de données (bases ou entrepôts). Nous allons mettre l accent sur les index de jointure binaires et la fragmentation horizontale et présenter les travaux de sélection combinée des deux dans le contexte d entrepôt de données. II.1 Sélection d un schéma d optimisation : Pré-requis La conception d une démarche de sélection des techniques d optimisation doit assurer la réduction du coût d exécution des opérations ou requêtes les plus complexes. Cette complexité peut être évaluée par la durée d exécution de la requête (estimée en secondes, heures ou jours dans les entrepôts de données) ou par le nombre d entrées/sorties entre disque et mémoire vive. En effet, afin d exécuter une requête, il faut charger, dans la mémoire vive, les données stockées sur disque afin d effectuer les opérations nécessaires à l exécution de la requête (jointures, sélection, restrictions, etc.). Concernant la conception physique d un entrepôt ou base de données, elle se passe en deux phases importantes : 27

36 Chapitre II : Problèmes de sélection des techniques d optimisation - La sélection d une stratégie d optimisation : elle consiste à choisir, parmi la panoplie des techniques d optimisation, celles qui optimisent aux mieux les traitements exécutées (choisir les index à implémenter, sélectionner le schéma de fragmentation des tables, etc.) - L implémentation physique des techniques d optimisation sélectionnées. Elle représente la création physique des structures préalablement sélectionnées. (création des index, matérialisation des vues, fragmentation effectives des tables). Dans les bases de données classiques, ces deux phases de conceptions physiques sont à la charge de l administrateur de base de données. Elles sont réalisées suivant l expérience et le bon sens de celui-ci. Par contre, dans le contexte d entrepôt de données, la tâche d administration devient de plus en plus difficile (cf. section I.1.1) et l administrateur doit être assisté par des outils qui procurent les bonnes recommandations pour la bonne conception et la bonne optimisation d un ED. Devant la difficulté de l administrateur à choisir une stratégie d optimisation, plusieurs travaux se sont penchés sur l établissement, la mise en œuvre et l automatisation de stratégies de sélection des techniques d optimisation qui doivent prendre en compte les choix d optimisation exprimés par l administrateur (choix des tables, des techniques, des attributs, etc.). Souvent, un concepteur d une démarche de sélection à pour rôle de concevoir un outil d assistance qui va permettre de saisir les besoins en optimisation de l administrateur et de lui proposer un schéma d optimisation pouvant réduire le coût d exécution d une charge de requêtes. Ainsi, toute démarche de sélection d un schéma d optimisation possède deux grands axes : le premier axe concerne le rôle de l administrateur dans le choix des paramètres d une stratégie de sélection. Le second axe concerne le rôle du concepteur d une démarche de sélection dans la mise en œuvre de cette stratégie. II.1.1 Rôle de l administrateur de bases ou entrepôts de données Techniques d optimisation : - Index - Vues - Fragmentation Mode de sélection - Isolé - combiné Choix de l administrateur Algorithme de sélection - Gloutons - Complexes : heuristiques, génétiques Choix des tables, des attributs Paramètre d algorithme - Génétique (taux de croisement, taille de population, etc) - Recuit simulé Figure II-1 : Choix de l administrateur pour une stratégie d optimisation Afin de mettre en œuvre une stratégie d optimisation, l administrateur (de bases ou entrepôts de données) doit prendre plusieurs décisions pertinentes (figure II-1 (Bellatreche, et al., 2008a) ) : - Choisir les techniques d optimisation à implémenter (index, vues, fragmentation, etc.). 28

37 Chapitre II : Problèmes de sélection des techniques d optimisation - Décider de la nature de sélection : isolée où une seule technique est choisie, combinée où plusieurs techniques sont sélectionnés à la fois. - Choisir l algorithme de sélection qui va permettre de sélectionner les structures d optimisation à implémenter sur l entrepôt ou la base de données (algorithmes simples, heuristiques, algorithmes génétiques etc.). - Choisir les tables et les attributs du schéma de données sur lesquels les structures vont être définies. Les techniques d optimisation étant exposées dans le chapitre précédant, nous allons détailler la nature de sélection (isolée et combinée) ainsi que les algorithmes de sélection. II Nature de sélection Il existe deux natures de sélection des techniques d optimisation: la sélection isolée et la sélection combinée. - La sélection isolée consiste à choisir d implémenter une seule technique d optimisation (redondante ou non redondante) indépendamment de toute influence ou similarité avec une autre technique. Plusieurs travaux ont traités la sélection isolée de structures d optimisation pour les index (Aouiche, et al., 2005), (Bellatreche, et al., 2008b), (Chaudhuri, et al., 2004), (Feldman, et al., 2003), (Golfarelli, et al., 2002), (Valentin, et al., 2000) et (Kratica, et al., 2003), pour les vues matérialisée (Aouiche, et al., 2006) ou pour la fragmentation (Hammer, et al., 1979), (Navathe, et al., 1995), (Ozsu, et al., 1991), (Golfarelli, et al., 1999), (Zhang, et al., 1994), (Bellatreche, et al., 2006), (Bellatreche, et al., 2009) (Boukhalfa, et al., 2008a), (Mahboubi, 2009). - La sélection multiple, elle permet de réaliser l implémentation conjointe de deux ou plusieurs techniques qui disposent alors du même espace de stockage et du même algorithme d implémentation. Dans ce cas l influence et l interaction entre techniques sont prises en compte pour une meilleure optimisation et exploitation des ressources. Un exemple de sélection combinée est la sélection d index et vues matérialisée (Agrawal, et al., 2000), (Bellatreche, et al., 2005) ou la sélection d index de schéma de fragmentation (Boukhalfa, et al., 2008b) et (Bellatreche, et al., 2008a), II Types d algorithmes de sélection Etant donné une structure d optimisation, plusieurs configurations sont possibles pour optimiser les données. Pour les index par exemple, on peut créer autant d index que d attribut existants dans le schéma des tables. Puisque les index nécessitent un espace de stockage, on ne peut pas tout indexer. Il faut impérativement choisir les index qui permettent d optimiser au mieux les traitements et requêtes exécutés. Afin d automatiser la sélection des techniques d optimisation, plusieurs algorithmes de résolutions sont utilisés pour choisir une configuration de structures optimale. Ce sont des algorithmes approximatifs classifiés en deux catégories : les algorithmes simples ou gloutons et les algorithmes complexes comme les heuristiques ou algorithmes de Datamining. a) Les algorithmes gloutons Ces algorithmes sont utilisés pour choisir la configuration de structures optimale. Cette dernière est obtenue en effectuant une suite de choix. A chaque étape de l algorithme, le choix qui semble le meilleur est effectué. Ce choix est définitif car le principe de l algorithme n adopte pas le retour arrière. Ce type d algorithme à été souvent adopté pour la sélection d index (Chaudhuri et al. 2004, Valentin et al. 2000, Golfareli et al. 2002, Aouiche et al. 2005, Bellatreche et al. 2008b) ou pour la fragmentation (Bellatreche, 2000). 29

38 Chapitre II : Problèmes de sélection des techniques d optimisation b) Les algorithmes complexes Contrairement aux algorithmes exacts, qui permettent de trouver la configuration optimale à un problème mais dont la complexité est exponentielle, les algorithmes complexes regroupent les algorithmes non exhaustifs qui permettent de trouver une solution quasi optimale (acceptable) en un temps raisonnable. Parmi ces algorithmes on trouve les heuristiques (Hill Climbing, Recuit Simulé, etc.) les algorithmes génétiques ou les algorithmes de fouilles de données. Généralement ces algorithmes démarrent d une ou plusieurs solutions initiales et visent à les améliorer par application d opérations (Split and Merge pour le Hill Climbing. Sélection, croisement, mutation pour les génétiques). Certains algorithmes on pour handicape la possibilité de choisir un optimum local comme solution optimale (Hill Climbing). Ainsi, des algorithmes comme le Recuit simulé permettent d admettre de mauvaises solutions ou des solutions inadmissibles, avec une certaine probabilité, afin de sortir des optimums locaux. Parmi les travaux qui emploient ce type d algorithmes on trouve les travaux de sélection d index par fouilles de données (Aouiche, et al., 2005), (Bellatreche, et al., 2008b), la sélection d index par algorithme génétique (Kratica, et al., 2003), la sélection de schéma de fragmentation par heuristiques (Hill Climbing) et algorithmes génétiques (Boukhalfa, et al., 2008b), (Boukhalfa, et al., 2008a) et (Bellatreche, et al., 2009). II.1.2 Rôle du concepteur de la stratégie de sélection des techniques d optimisation Le concepteur doit mettre en œuvre une stratégie qui permet de sélectionner les structures d optimisation, en prenant en compte les décisions prise par l administrateur, puis d implémenter ces structures sur les données physiques. Pour ce faire, le concepteur doit formaliser le problème de sélection des structures d optimisation afin d identifier les contraintes sur la sélection (par exemple la contrainte d espace de stockage pour les index et vue matérialisées) et pouvoir proposer les algorithmes de sélection les plus adéquats (si le problème est NP-Complet par exemple, il faut employer les algorithmes complexes afin d obtenir un meilleur résultat). Concernant l implémentation des algorithmes de sélection, il faut prendre en compte l optimisation de la charge de requêtes. Chaque algorithme de sélection doit permettre de sélectionner les structures d optimisation qui optimisent le coût d exécution de cette charge. Ce coût et évalué par modèle de coût qui permet de guider la sélection des structures afin de choisir la configuration optimale. Nous présentons dans ce qui suit, la formalisation générale d un problème de sélection puis le principe de modèle de coût. II Formalisation générale d un problème de sélection Etant donné une charge de requêtes C (récupérée généralement à partir du journal de transaction du SGBD ou spécifiée par l administrateur) et une ou plusieurs contraintes d optimisations B (espace de stockage, coût de maintenance, temps d exécution). Il faut trouver une configuration de structures physiques en un temps raisonnable, qui, une fois implémentées, permettent de réduire le coût d exécution des requêtes C sans violer la contrainte B (Bruno, et al., 2005). II Modèle de coût Nous allons présenter, dans les paragraphes suivants, le principe, les domaines d utilisations ainsi que les méthodes d estimation d un modèle de coût. 30

39 Chapitre II : Problèmes de sélection des techniques d optimisation a) Principe et domaines d utilisation Le modèle de coût permet d estimer le coût d exécution d une requête en se basant sur plusieurs paramètres physiques qui sont : - La taille des tables, des tuples et le temps d accès aux données qu elles soient en mémoire centrale ou en mémoire secondaire. - Le facteur de sélectivité d une opération qui représente le rapport entre le nombre de tuples sélectionné par l opération et la taille globale de la table. - L implémentation physique de chaque opération : jointure, sélection etc. Par exemple, pour la jointure, il faut préciser si c est une jointure par boucles imbriquées (NESTED LOOP), tri-fusion (SORT-JOIN) ou par hachage (HASH-JOIN) (Bellatreche, 2000). - Données système comme la taille d une page système. Le modèle de coût peut être utilisé dans plusieurs cas (Bellatreche, 2000): - Choisir le meilleur plan d exécution pour une requête en incluant les algorithmes d implémentations des opérateurs. Le plan dont le coût est optimal est sélectionné. - Guider les algorithmes de sélection des techniques d optimisation. Le modèle de coût permet d évaluer chaque configuration générée afin d en choisir la plus optimale. b) Méthodes d évaluation : Le modèle de coût peut être évalué de deux manières : la première fait appel à l optimiseur du SGBD. La seconde évalue le modèle de coût par fonction mathématique. 1) Le modèle de coût basé sur appel d optimiseur à l avantage d être précis car il se base sur l estimation réelles de la tailles des tables, des données chargées, de la tailles des tuples etc. son principal inconvénient et qu il rend la technique de sélection dépendante du SGBD. De plus, les appels fréquents de l optimiseur peuvent dégrader les performances (Darmont J., 2006). Parmi les travaux qui utilisent ce type de modèle de coût, on trouve les travaux de sélection d index (Chaudhuri, et al., 2004) et (Valentin, et al., 2000). 2) Le modèle de coût basé sur une fonction mathématique a l avantage de rendre la stratégie d optimisation rapide et complètement indépendante du SGBD. Par contre, il nécessite l utilisation d hypothèses qui peuvent ne pas refléter exactement la réalité d exécution des requêtes. Afin de mettre en œuvre un modèle de coût mathématique il faut : - Identifier les algorithmes d implémentation des opérateurs. L algorithme de jointure le plus utilisé est le HASH (Bellatreche, 2000), (Aouiche, 2005). - Estimer les paramètres de coût : ils désignent des statistiques et des estimations sur la sélectivité des prédicats, les tables (nombre de tuples d une table, taille de tuples ), sur le système (taille d une page système, le coût de chargement) et enfin des estimations sur les techniques d optimisation utilisées (espace de stockage, coût de maintenance). - Plusieurs travaux utilisent ce type de modèle de coût pour la sélection d index (Golfarelli, et al., 2002), (Kratica, et al., 2003), (Aouiche, et al., 2005), (Bellatreche, et al., 2008b) ou la sélection d un schéma de fragmentation, (Navathe, et al., 1989), (Ozsu, et al., 1991), (Zhang, et al., 1994), (Bellatreche, et al., 2006), (Bellatreche, et al., 2009) (Boukhalfa, et al., 2008a) et (Mahboubi, 2009) 31

40 Chapitre II : Problèmes de sélection des techniques d optimisation c) Intérêt d utiliser un modèle de coût Dans la plus part des SGBD, le modèle de coût est employé pour choisir le meilleur plan d exécution d une requête. En effet, le modèle de coût permet de prendre en compte la représentation des données sur lesquelles s exécutent les requêtes de traitements. L exécution d une requête représente une succession d opérations de sélections, jointures projections, etc. appelée plan d exécution. Afin de sélectionner le meilleur plan, l optimiseur d un SGBD utilise deux méthodes : soit par Rule Based soit par Cost Based : 1. Le Rule Base se base sur le principe de réécriture de la requête en utilisant l algèbre relationnel. La requête représente un ensemble de tables sur lesquelles sont appliquée des opérateurs algébriques comme la jointure, la sélection, la projection et les opérateurs ensemblistes. Cette requête peut être illustrée sous forme d arbre algébrique. Afin d optimiser la requête, on effectue des modifications sur l arbre suivant plusieurs règles comme exécution le plus tôt possible les opérations de sélection afin de réduire la taille des tables à manipuler. L inconvénient principal du Rule Based est qu il est complètement indépendant de l implémentation physique des données ou des opérateurs (jointure, sélection etc.). Ainsi, la pluparts des SGBD emploie l optimisation par modèle de coût (Cost Based) 2. Le Cost Based se base sur l évaluation de l exécution d une requête en exploitant un modèle de coût. L optimiseur établi un plan d exécution qui représente un arbre algébrique. La différence avec le Rule Base est qu au niveau de chaque nœud, l algorithme d implémentation de chaque opérateur est précisé. Ce plan est évalué en calculant le coût d exécution. Le plan dont le coût est le plus réduit sera choisi pour la requête. II.2 Problème de Sélection d Index PSI Les index représentent une technique d optimisation de requêtes très efficace. Ils permettent de réduire le coût d exécution de ces requêtes en minimisant le volume de données à exploiter dans les calculs. Les index sont utilisés dans le contexte de bases de données et d entrepôts de données. Par contre, les techniques d indexation employées dans l un des contextes diffèrent de l autre. En effet, concernant les bases de données, les index simple B-arbre ou les bitmap font leurs preuves. Concernant les entrepôts de données, les index les plus efficaces sont les index de jointures en étoiles ou index de jointures binaires. II.2.1 Démarche de sélection d index Charge de requêtes Sélection d index candidats Réduction de l ensemble d index Configuration finale d index Figure II-2 : Démarche de sélection d index 32

41 Chapitre II : Problèmes de sélection des techniques d optimisation La sélection d un ensemble d index suit en général trois étapes importantes : la sélection d index candidats, la réduction de l espace de recherche puis la sélection d une configuration finale d index (figure II-2) : II Sélection d index Candidats Afin de trouver la configuration optimale d index, des algorithmes de résolutions sont exécutés sur un ensemble d index de départ, ce sont des index candidats. La sélection d un ensemble d index candidats peut se faire de deux manières (Aouiche, 2005) : - Manuelle: en se basant sur son expérience, l administrateur de la base de données peut manuellement sélectionner un ensemble d index candidats. Le choix est alors subjectif car il dépend du degré d'expertise de l'administrateur (Kratica, et al., 2003). - Automatique : par une analyse syntaxique de la charge de requêtes et extraction des tables et attributs à partir des clauses WHERE, GROUP BY, ORDER BY et UPDATE sur lesquels il serait bénéfique de définir des index. La plupart des travaux de sélection d index utilisent la sélection automatique d index candidats index (Aouiche, et al., 2005), (Bellatreche, et al., 2008b), (Chaudhuri, et al., 2004), (Feldman, et al., 2003), (Golfarelli, et al., 2002) et (Valentin, et al., 2000) II Réduction de l ensemble d index Cette étape permet d écarter les index non avantageux. La suppression d un index peut se faire par plusieurs méthodes : - Estimation de l impact de l index sur l optimisation des données. Si cet index n apporte pas un grand bénéfice il est écarté (Chaudhuri, et al., 1998). - Suppression des index qui causent le dépassement de l espace total réservé au stockage des index (Feldman, et al., 2003). - Suppression des index ne pouvant pas être crées ou dont la clause de création présente une anomalie (Aouiche, et al., 2005) et (Bellatreche, et al., 2008b) Cette étape à pour intérêt de diminuer le nombre d index possibles soumis à l algorithme de sélection, ce qui permet d obtenir l ensemble d index optimal plus rapidement grâce à la réduction de l espace de recherche. II Sélection de la configuration finale d index La sélection d une configuration d index est effectuée par des algorithmes de résolutions. Nous avons deux catégories de résolution selon la nature de ces algorithmes : a) Résolution par algorithmes simples (gloutons) Ces algorithmes permettent la construction d un ensemble d index de deux manières : - Construction ascendante (Bottom-Up) : démarre d une configuration d index vide et l enrichie par l ajout successif d index jusqu'à saturation de l espace de stockage est optimisation totale de la charge de requête. - Construction descendante : démarre d une configuration optimale qui viole la contrainte d espace, supprime les index jusqu'à ce qu aucune amélioration n est obtenue. La majorité des travaux de sélection d index finaux emploient la construction ascendante (Aouiche, et al., 2005), (Bellatreche, et al., 2008b), (Chaudhuri, et al., 2004), (Golfarelli, et al., 2002) et (Valentin, et al., 2000) 33

42 Chapitre II : Problèmes de sélection des techniques d optimisation b) Résolution par Heuristique Ces méthodes de résolutions se basent sur l assimilation du problème de sélection des index au problème du sac à dos. Ainsi, le problème de sélection d index peut être résolu par heuristique comme le recuit simulé et la recherche taboue ou les algorithmes génétiques où l individu représente un index. Ces heuristiques se basent, pour sélectionner une configuration optimale, sur la minimisation d une fonction objectif. Elle est calculée par modèle de coût qui représente le coût d exécution de la charge de requêtes en présence de l ensemble d index en cour, sous la contrainte d espace de stockage (Kratica, et al., 2003), (Feldman, et al., 2003). II Complexité Il existe deux types d index : les index mono-attributs et les index multi-attributs. Les index mono-attributs sont définit sur un seul attribut d une seule table. Ils sont caractérisés par une seule colonne qui référence les valeurs de l attribut indexé. Concernant les index multi-attributs, ils sont définis sur plusieurs attributs issus de plusieurs tables. L index comporte autant de colonne que d attributs indexé et chaque colonne référence les valeurs de chaque attribut. a) Nombre d index possible : Soit l ensemble de N attributs indexable A = {A 1,,A n }. Le nombre d index mono attributs est donné avec la formule (Bellatreche, et al., 2008a) : _ 2 1. Si les index sont multi-attribut, chaque index à un nombre combinatoire de configurations possibles 2 1. Ainsi le nombre total de configuration d index possible est : _ 2 1. b) Contrainte sur la sélection d index : En théorie, le nombre d index pouvant être sélectionnés est _ 2 1. Cela dit, en pratique, la sélection d index doit être effectuée avec la prise en compte de facteurs majeurs: - La contrainte d espace : l espace réservée pour index sélectionner ne doit pas dépasser un certain seuil définis par l administrateur. - La contrainte de mise à jour : les index nécessitent leur mise à jour dans le cas de changement sur les données indexées (mise à jour, insertion, suppression). Si un index nécessite un coût de mise à jour élevé, il devient non bénéfique. - Réduction du coût d exécution : le but de la mise en œuvre des index est l optimisation des requêtes en réduisant leur coût d exécution. Ainsi la configuration d index choisis doit être la plus optimale pour la charge de requêtes. II.2.2 Formalisation du problème PSI Un problème PSI peut être formulé comme suit (Aouiche, 2005) : Etant donné : - un ensemble d index candidats (chaque index est munis d une taille Ti). - un ensemble de requêtes. - S la taille de l espace de stockage allouée pour les index. Alors il faut trouver une configuration d index tel que : - Le coût d exécution des requêtes soit minimal. - L espace alloué pour le stockage de ces index ne dépasse pas S : 34

43 Chapitre II : Problèmes de sélection des techniques d optimisation Formalisé ainsi, ce problème est NP-Complet (Bellatreche, 2000), (Chaudhuri, et al., 2004). Par conséquent, il n'existe pas d'algorithmes exacts qui proposent une solution optimale en un temps fini. Il est impératif d employer d autres types d algorithmes (gloutons, heuristiques, etc.) pour la sélection d index. II.2.3 Travaux de Feldman et al. Les auteurs proposent un outil d assistance pour la sélection d index nommé DINNER (Feldman, et al., 2003). Il représente un outil à base de connaissance qui prend en entrée la charge de requêtes, les différentes relations et des statistiques définies sur ces tables afin de constituer un modèle de coût, ensuite, DINNER effectue la sélection du meilleur plan d exécution des requêtes qui permet de recommander une configuration d index. Le procédé de sélection d index se déroule en deux étapes : génération des graphes d exécution des requêtes, puis élimination et unification des nœuds inutiles pour sélectionner le meilleur plan d exécution Racine Jointure Table1, Table2 Jointure Table2, Table1 Tri fusion AND OR Figure II-3 : Graphe d exécution pour une requête 1. Génération des graphes d exécution des requêtes: l outil crée un graphe d exécution pour chaque requête de la charge. Le but est de décomposer la requêtes en sous requêtes définies chacune sur une seule table (figure II-3). Les nœuds renferment les résultats intermédiaires et les feuilles représentent des requêtes exécutées sur une seule table. Chaque nœud intermédiaire peut être un OR ou AND entre les résultats qu il reçoit de ses fils. Une fois le graphe construit, DINNER calcule, des feuilles à la racine, le temps d exécution et l espace de stockage pour le chemin qui à la plus forte probabilité d être choisit par l optimiseur. On obtient un graphe d exécution d une requête avec estimation du coût d exécution et l espace requit pour les calculs. 2. Elimination et unification pour sélectionner le meilleur plan d exécution : exécuté dans le cache pour de meilleurs performances, cette étape consiste à supprimer tous les nœuds dont l espace de stockage requit viole l espace maximum. Ensuite, les graphes des requêtes définis sur une même table sont regroupés. En utilisant les coûts des opérateurs déjà stockés dans l étape précédente, le coût des jointures est calculé et la meilleure implémentation est sélectionnée. A ce niveau, à partir des meilleurs graphes, on obtient une configuration d'index, avec leurs coûts et leurs espaces de stockage. Il reste à trouver, dans cette configuration d index candidats, les meilleurs index par heuristiques. II.2.4 Travaux de Kratica et al. Boucle imbriquée Tri fusion AND Boucle imbriqué Requête 1 Requête 2 Requête 3 Requête 3 Requête 2 Requête 1 Les auteurs proposent l implémentation d un algorithme génétique pour la sélection d index (Kratica, et al., 2003). Cet algorithme s'applique sur une population d'individus N pop. Le nombre OR 35

44 Chapitre II : Problèmes de sélection des techniques d optimisation d'individus élus pour survivre à la prochaine génération est N elit. La fonction objectif à évaluer représente le temps de traitement des requêtes. Elle est stockée dans une table cache de taille N cache pour accélérer le temps des calculs. II.2.5 Travaux de Chaudhuri et al. Dans le but de mettre en œuvre un outil qui contribue à résoudre le problème de la conception physique automatique, en particulier la sélection d index, Microsoft a lancé l outil AutoAdmin pour l auto administration des bases de données. Les auteurs (Chaudhuri, et al., 1997) proposent un outil de sélection d index mono et multi-attributs IST (Index Selection Tool) (figure II-4). L outil se base sur un principe de sélection qui suit quatre étapes : sélection des index candidats, réduction de l espace de recherche, génération des index multi-attributs et sélection de la configuration finale d index. Figure II-4 : Outil de sélection d index IST dans AutoAdmin 1. Sélection des index candidats : à partir de la charge de requêtes. 2. Réduction de l ensemble d index : les index non avantageux sont écartés en estimant leur impact sur la base de données. Pour ce faire, les auteurs ont développé un outil nommé What- If API (Chaudhuri, et al., 1998). Il se base sur l extension du server de base de données afin de pouvoir simuler la stratégie d optimisation (à l aide de métadonnées et de statistiques) et d évaluer le coût de la charge de requête. Ce coût est calculé en faisant appel à l optimiseur du SGBD. Ainsi, la meilleure configuration d index est obtenue. 3. Génération d index multi-attributs (fusion) : Les index obtenus sont mono attributs. Une amélioration est apportée dans (Chaudhuri, et al., 1999) propose de fusionner deux ou plusieurs index ensemble, le but est de générer un nouvel index qui permettrait d optimiser d avantage plusieurs requêtes que les index initiaux. Ceci réduit le nombre de structures, améliore le taux d optimisation des requêtes et réduit l espace de stockage. 4. Sélection de la configuration finale : à partir de l ensemble de n index obtenu précédemment, les k meilleurs sont sélectionnés par un algorithme glouton. A chaque itération, l algorithme ajoute un index de l ensemble n-k et fait appel à l optimiseur pour évaluer le 36

45 Chapitre II : Problèmes de sélection des techniques d optimisation coût d exécution des requêtes. L algorithme s arrête lorsque l ajout d un index n apporte aucune amélioration. Par la suite, les auteurs montrent que le problème de sélection d index est NP-Complet, ils proposent donc une démarche de sélection des index à base d heuristiques (Chaudhuri, et al., 2004). L inconvénient majeur de cette démarche est l explosion du nombre d index générés à la troisième étape, ce qui rend le nombre de combinaisons possibles de fusion d index encore plus complexe. De plus, les appels fréquents de l optimiseur dégradent largement les performances. II.2.6 Travaux de Valentin et al. Mémoire Utilisateur Disque Interface graphique SmartGuide Package BDD DB2Advise : outil ligne de commande Tables de recommandations Data Cache SQL DB2 BDD Optimiseur Statistiques Figure II-5 : Architecture de DB2 Adviser Sous le système DB2 Advisor d IBM, les auteurs proposent une solution pour la sélection d index (figure II-5) (Valentin, et al., 2000). Nous allons présenter les différents modules implémentés pour la sélection d index puis aborder le principe général de sélection. 1. Description des modules du DB2 Adviser : l architecture générale du DB2 Adviser se comporte quatre modules importants : - Index Smart Guide : une interface graphique pour l utilisateur. - DB2Advise : une ligne de commande qui permet de recommander des index. - Optimiseur : une extension de l optimiseur DB2 pour la sélection et évaluation d index. - Tables de recommandation : Utilisées comme un moyen de communication entre l'optimiseur et l'outil DB2Advise. 2. Démarche de sélection : la sélection d index est établie par un algorithme qui est une extension de l optimiseur. L outil commence par sélectionner un ensemble d index candidats. L algorithme effectue une simulation (similaire à l outil What-If (Chaudhuri, et al., 1998) afin d évaluer l exécution de ces index et génère des statistiques et métadonnées qui sont stockés, ainsi que les index, dans une table de recommandations. En se basant sur ces index et les statistiques, l optimiseur génère pour chaque requête le plan d exécution optimal. Les index utilisés dans ces plans seront recommandés. Une fois l ensemble d index définit, le problème est modélise comme le problème du sac à dos pour être résolu par heuristiques. Le principal avantage de la solution est le fait que l algorithme de sélection des index est intégré dans l optimiseur ce qui supprime pratiquement le coût des appels fréquent à l optimiseur. 37

46 Chapitre II : Problèmes de sélection des techniques d optimisation II.2.7 Travaux de Golfareli et al. Dans leurs travaux, Golfareli et al proposent une technique de sélection d index dans les entrepôts de données (Golfarelli, et al., 2002). Elle se base sur un modèle de coût mathématique pour l estimation du coût d exécution des requêtes qui permet à un algorithme glouton de sélectionné la configuration optimale d index. La démarche de sélection est effectuée comme suit - Initialiser l'ensemble des index candidats I et optimaux O, ainsi que l'espace de stockage S des index à sélectionner. - Sélectionner à partir de I, d'une manière gloutonne et en se basant sur le modèle de coût, les index apportant un meilleur bénéfice et les mettre dans l'ensemble O. - Si après un ajout, il arrive que tous les attributs (incluant la clé primaire) d'une table de fait soient indexés, alors ces index sont transformés en un seul index multi-attributs construit sur la clé primaire de la table de fait. II.2.8 Travaux Aouiche et al. Les auteurs proposent d utiliser l algorithme CLOSE pour la sélection d IJB. CLOSE est un algorithme de fouille de données utilisé pour la recherche des motifs fréquents. L approche que présente les auteurs se base sur la technique d extraction des motifs fréquents fermés où chaque motif correspond un IJB potentiel (Aouiche, et al., 2005). Nous commençons par donner les définitions des motifs fréquents et fermés puis présenter la démarche de sélection d IJB, par la suite nous présentons la fonction objectif utilisée par un algorithme glouton pour la sélection des index finaux et nous terminons par une analyse de l approche. II Définitions - Motif fréquent : Soient I = i 1,, i m un ensemble de m items (attributs) B = t 1,, t n une base de données de n transactions (les requêtes) ou chaque transaction est composée d'un sous-ensemble d'items de I et possède un identifiant unique TID. X un sous ensemble d item de taille k appelé motif. Une transaction t i contient un motif X si et seulement si. Le support d'un motif X :,, représente la proportion de transactions de B qui contient ce motif. Un motif est dit fréquent si son support est supérieur à un seuil minsup. Vu que le nombre de motif possible croit exponentiellement (2 ), les auteurs ont eu recours aux motifs fréquents fermés - Motif fréquent fermé : c est un motif fréquent maximal dans toutes les transactions auxquelles il appartient (ne représente pas un sous ensemble d un autre motif). Exemple 16 : Pour l adaptation de cette technique à la sélection d IJB dans les entrepôts de données, les supports sont calculés à partir de la matrice d usage (figure II-6). A 1 A 2 A 3 A 4 Q Q Q Q Support 3/4 3/4 2/4 1/4 Figure II-6 : Matrice d usage et supports 38

47 Chapitre II : Problèmes de sélection des techniques d optimisation Un exemple de motifs peut être : TID Motifs Support A 4 A 1 A 2 A 2 A 1 A 2 1/4 3/4 3/4 3/4 Figure II-7 : Exemple de motifs pour chaque requête Pour minsup=2/4, les motifs fréquents sont A 1 A 2 et A 2, les motifs fréquents fermé A 1 A 2. En effet le motif A 2 ne l est pas car il apparait à A 1 A 2. II Démarche de sélection d IJB Entrepôts de données Extraction des Attributs indexables Application de l algorithme CLOSE Charge de requêtes Matrice d usage Motifs fréquents fermés Index candidats Configuration finale d index Modèle de coût Figure II-8 : Architecture de sélection automatique d'index (Aouiche, et al., 2005) La démarche se sélection d IJB proposé par l auteur se déroule en trois étapes (figure II-8) : génération des IJB candidats, réduction de l espace de recherche puis sélection des index finaux. 1. Générer les index candidats : A partir de la charge de requêtes, les attributs indexables sont extraits. Ensuite, l algorithme de fouille de données CLOSE extrait les motifs fréquents fermés de la forme <Table i.attribut j > en se basant sur les supports. 2. Réduire l espace de recherche : la clause de création d un IJB sur une table de fait «Fait» et une table de dimension «Dimension» sur l attribut Att est donnée comme suit : CREATE BITMAP INDEX IJB ON Fait (Dimension.Att) FROM Fait, Dimension WHERE Fait.Id_Dim= Dimension.Id A ce niveau, chaque motif va contribuer à la construction d un IJB s il contient les attributs nécessaires : des clés étrangères de fait (Id_Dim), des clés primaires de dimension (Id) et les attributs non clés de dimension sur lesquels sont définis les IJB (Att). Les attributs non clés 39

48 Chapitre II : Problèmes de sélection des techniques d optimisation permettent de définir le ON de la requête de création de l IJB, les clés définissent les prédicats de jointure du WHERE et les tables jointes définissent le FROM. Tout motif démuni de l un de ces éléments est écarté. 3. Sélection de la configuration finale d index: Une fois les motifs sélectionnés, un algorithme glouton parcourt l espace de recherche pour la sélection d index les plus bénéfiques en se basant sur un modèle de coût comme fonction objectif. Si l index apporte une amélioration du coût de la charge de requêtes il est retenu. A la première itération, le modèle de coût est équivalent au coût d exécution des jointures par hachage présentent dans les requêtes. Suite à l ajout d un index, le coût est recalculé avec prise en compte des index. II Fonction objectif Les auteurs utilisent trois versions de la fonction objectif pour estimer le coût d exécution d une requête. Ils établissent ensuite une comparaison entre les trois méthodes. Ces fonctions sont une fonction profit qui prend en compte le profit apporté par l ajout d un index, une fonction ratio profit/espace utilisée quand l espace de stockage réservé pour les index est réduit, et une dernière hybride utilisée quand l espace de stockage est grand : - Fonction profit : estime le profit apporté par un index. Pour les index,, une charge de requête et une configuration finale Config I, la fonction profit est :,,, Où est le rapport entre le coût des jointures évitées par l index i j et le coût total des jointures, est la fréquence de mise à jour de l index. - Fonction ratio profit/espace : utilisée quand l espace de stockage réservé pour les index est réduit : - Fonction hybride : utilisée quand l espace de stockage est grand, elle mixe entre les deux fonctions précédences suivant un seuil : II Analyse Le point fort de cette solution est qu elle peut être appliquée pour n importe quelle technique d indexation. De plus, l interaction entre IJB est prise en compte. En effet, à chaque itération, le modèle de coût est recalculé en incluant l index en cour et tous les index précédemment générés. Ainsi, le coût d utilisation d un index varie d une itération à l autre. Ajouter à cela le fait que l algorithme utilisé dans cette technique permet de générer les index mono et multi-attributs avec un seul passage. Plus besoin d effectuer une fusion d index pour améliorer les performances comme dans (Chaudhuri, et al., 1999) ou d exécuter plusieurs itérations pour générer les index multi attributs comme dans (Chaudhuri, et al., 1997). Il est vrai que l importance d un index peut résider dans sa fréquence d utilisation par un maximum de requêtes, mais ce seul critère n est pas suffisant pour sélectionner les index les plus optimaux. D autres critères sont utilisés dans (Bellatreche, et al., 2008b). II.2.9 Travaux de Bellatreche et al Les auteurs dans leurs travaux (Bellatreche, et al., 2008b) se basent sur la technique d extraction des motifs fréquents fermés. Elle est réalisée comme suit : (1) récupérer les attributs 40

49 Chapitre II : Problèmes de sélection des techniques d optimisation indexable, (2) réduire l espace de recherche par une méthode de Datamining (2) sélectionner les index par un algorithme glouton sous la contrainte d espace de stockage. II Motivation Les travaux de Aouiche et al (Aouiche, et al., 2005) présentent une limitation, il utilise uniquement la fréquence d accès des requêtes aux attributs pour générer les motifs fréquents fermés. Bellatreche, et al. utilisent en plus de la fréquence la taille des tables, la longueur des tuple, taille de la page système et proposent une nouvelle version d algorithmes DynaClose et DynaCharm qui prennent en compte ces paramètres. Ceci est justifié par le fait que les opérations les plus coûteuses sont les jointures qui dépendent fortement de la taille des tables. Exemple 17 : En reprenant l exemple précédent, le motif sélectionner par la technique proposée par Aouiche est al. sera <A 1, A 2 > et <A 4 > sera écarté, supposant que A4 est un attribut d une table de dimension de tuples et que A 1, A 2 appartienne à une table de 10 tuples, il est évident qu un IJB définit sur la première table (motif <A 4 >) est plus optimal. II La démarche de sélection d index : La sélection des index est établie suivant les étapes suivantes : - Générer les attributs candidats : La matrice d usage et les supports sont construits. Par la suite, les motifs fréquents fermés sont générés par les algorithmes DynaClose et DynaCharm qui utilisent une nouvelle métrique appelée Fitness. Elle utilise, en plus de la fréquence, les tailles des tables et est définit sur les attributs non clés du motif comme suit : Où n est le nombre d attributs non clé du motif, est le support de Ai et où et représente le nombre de page de la table dimension qui contient Ai et de la table de fait respectivement. Tout comme pour les supports, un seuil est définit : - Réduction de l espace de recherche : une fois les motifs récupérés, il faut en éliminer ceux présentant une anomalie pouvant empêcher la création de l IJB tout comme pour les travaux d Aouiche et al. De plus, il faut contrôler les attributs de chaque motif, pour cela il existe deux cas de figures : (1) Chaque motif ayant tous les attributs non clés définis sur une même table dimension doit avoir uniquement deux attributs clés, une clé dimension et la clé étrangère de fait correspondante. (2) Chaque motif ayant les attributs non clés sur k tables de dimension doit avoir 2k clés : k clés dimension et k clés étrangères de la table de fait correspondantes. - Sélection de la configuration finale d index: à partir des motifs, les attributs indexables sont récupérés dans un ensemble CA. Un algorithme glouton exploite cet ensemble sous une contrainte d espace afin de générer les index finaux. Cet algorithme se base sur un modèle de coût pour définir la fonction objectif afin estimer l exécution de la charge de requête (Aouiche, 2005) et le coût de stockage de l index (Bellatreche, 2000). A chaque itération, l attribut de plus faible cardinalité est choisit jusqu'à saturation de l espace de stockage, d épuisement de CA ou de stabilité de la fonction objectif. 41

50 Chapitre II : Problèmes de sélection des techniques d optimisation II.2.10 Synthèse Travaux Kratica et al Feldman et al Chaudhuri et al Valentin et al Golfareli et al Aouiche et al Bellatreche et al. 2008b Contexte BDD BDD BDD BDD BDD ED ED Type de sélection d index Général sur une table Général sur une table Général sur une table Général sur une table Général sur une table IJB sur plusieurs tables IJB sur plusieurs tables Sélection d index candidats Manuelle Algorithme de sélection finale d index Heuristique (génétique) Modèle de coût Fonction mathématique Automatique Heuristique - Automatique Automatique Automatique Automatique par Datamining Automatique par Datamining Glouton (Ascendant), Heuristiques Glouton (Ascendant) Glouton (Ascendant) Fouille de données (motifs), glouton (Ascendant) Fouille de données (motifs), glouton (Ascendant) Optimiseur des requêtes Optimiseur des requêtes Fonction mathématique Fonction mathématique Fonction mathématique Tableau II-1 : Synthèse de travaux sur les index Nous avons abordé le problème de sélection d index et présenté quelques travaux qui existent dans la littérature traitant ce problème (tableau II-1). Nous allons résumer ces travaux en les classant suivant plusieurs critères qui sont : - Le contexte de manipulation de données : entrepôt de données ED ou base de données BDD. - Le type de sélection d index sélection sur une ou plusieurs tables pour les index de jointure binaires ou index général. - La méthode de sélection de l ensemble d index candidats. - La méthode de sélection d une configuration finale d index. - La catégorie du modèle de coût utilisée pour cette seconde sélection. II.3 Problème de sélection d un schéma de fragmentation Plusieurs travaux s intéressent à la fragmentation horizontale et verticale que ce soit dans le domaine des bases de données ou des entrepôts de données. Nous allons introduire dans ce qui suit les travaux et algorithmes de fragmentation verticale, horizontale et même mixte. Nous mettrons l accent sur la fragmentation des entrepôts de données. II.3.1 Algorithmes de fragmentation verticale Le problème de sélection d un schéma de fragmentation verticale consiste à déterminer un partitionnement de l ensemble d attributs d une relation en plusieurs sous ensembles d attributs. Ce partitionnement doit garantir la création d un schéma de fragmentation vertical qui optimise les performances d exécution des requêtes. Mais il ne faut pas oublier que la sélection d un schéma de fragmentation optimal est un problème difficile car le nombre de schémas possibles explose, en effet, une relation de n attributs peut être fragmentée en B(n) manières, B(n) étant le nombre de Bell. Pour m grand, B(n) est égal à n n (Bellatreche, 2000). II Travaux de Hammer et al. Les auteurs (Hammer, et al., 1979) proposent d effectuer une fragmentation verticale puis de la simuler afin d évaluer les performances d exécution et d obtenir le schéma optimal. Le modèle de simulation est composé de deux parties importantes (figure II-9): 42

51 Chapitre II : Problèmes de sélection des techniques d optimisation Relation à fragmenter Générateur de partition Générateur par fusion de blocs de la partition courante Simulateur : Evaluation des performances Générateur par migration d attributs Figure II-9: Fragmentation verticale par Hammer et al - Un générateur de partitions : cette génération est effectuée de manière heuristique à deux étapes. A chaque itération, le générateur construit une variation de la fragmentation (par fusion et par migration d attributs) puis les schémas de fragmentation obtenus sont soumis à un évaluateur de performance afin de choisir le schéma de fragmentation de l itération suivante. L entrée du générateur par fusion représente un schéma de fragmentation avec des fragments à un seul attribut, l entée du générateur par migration est le schéma de fragmentation issu du générateur par fusion. - Un évaluateur de performances : se charge d attribuer un coût à chaque schéma. L algorithme de fragmentation s arrête lorsqu aucune amélioration ne peut être apportée. II Travaux de Navathe et al Partition optimale Les auteurs proposent une méthode de fragmentations verticale par répartition des attributs selon deux approches : le regroupement binaires et le regroupement graphique des attributs (Navathe, et al., 1989). 1. Regroupement binaire se base sur une relation à m attributs à fragmenter et un ensemble de n requêtes les plus fréquentes. Il s'exécute en deux phases : a. La première phase consiste à construire trois matrices : - Matrice d'usage des attributs. Les lignes et les colonnes représentent les n requêtes et les m attributs. l'élément de la ligne i et la colonne j est à 1 si le prédicat j dans la requête i, 0 sinon. La matrice est complétée par une colonne des fréquences des requêtes. - Matrice d'affinités des attributs (m x m). Chaque élément de la matrice est la somme des fréquences d'accès des requêtes accédant simultanément aux deux attributs. - Matrice d'affinités ordonnée. L ordre est effectué par permutation des lignes et des colonnes de la matrice d affinités. Les attributs qui sont utilisés simultanément sont regroupés ce qui donne une matrice sous la forme d'un semi-bloc diagonal. b. La seconde phase consiste à appliquer un partitionnement binaire de la matrice d'affinité ordonné afin de rechercher les fragments verticaux. Le partitionnement est effectué de manière récursive jusqu'à optimisation d une fonction objectif. 43

52 Chapitre II : Problèmes de sélection des techniques d optimisation 2. Regroupement graphique considère la matrice d affinités comme un graphe complet. Les nœuds symbolisent les attributs et les arrêtes sont étiquetées des valeurs d affinité. Le but est de trouver les composantes connexes du graphe où chaque composante est un fragment. II.3.2 Algorithmes de fragmentation horizontale FH La fragmentation horizontale se base sur la répartition des tuples d une table en plusieurs sous ensembles suivant des critères de fragmentation. Ces critères sont des prédicats de sélections définis sur un ensemble d attributs de fragmentation. Ainsi, la définition d un schéma de fragmentation revient à répartir ces prédicats en sous ensembles où chaque sous ensemble permet de définir un fragment. Les algorithmes de fragmentation doivent satisfaire les règles de correction suivantes (Bellatreche, 2000) : - Complétude : tous les n-uplets d une relation sont associés à au moins un fragment. - Reconstruction : elle assure qu une relation peut être reconstruite à partir de ses fragments. - Disjonction : elle assure que les fragments d une relation sont disjoints deux à deux. Il existe trois grandes catégories d algorithmes : algorithmes à base de minimalité et complétude de prédicats, à base d affinité de prédicats et à base de modèle de coût. II Algorithmes à base de minimalité et complétude de prédicats Afin d aborder cette approche, nous présentons les définitions suivantes (Bellatreche, 2000): - Un prédicat simple et pertinent : un prédicat simple p est pertinent à un ensemble de prédicat P s il existe un prédicat q dans P tel que les fragments définis par et ceux définis par soient accédés individuellement par au moins une application (pour une table Client avec un attribut Ville, si aucun Client n est d Oran alors le prédicat Ville=Oran n est pas pertinent car il ne permet pas de partitionner la table en deux fragments distincts). - Un ensemble de prédicats est dit minimale s il ne contient que des prédicats pertinents. Les travaux de (Ozsu, et al., 1991) ont proposé une méthode de fragmentation dans le contexte des bases de données répartie suivant quatre étapes : - Classifier des transactions : regrouper dans une même classe les transactions qui proviennent du même nœud du réseau d'ordinateurs composant le système réparti. - Générer un ensemble complet et minimal de prédicats simples : on extrait, à partir des transactions, un ensemble complet et minimal de prédicats simples suivant l algorithme COM-MIN. Cet algorithme génère des prédicats non redondants (minimalité) et permet de partitionner une dimension en au moins deux fragments séparément ciblés par une requête (complétude). L algorithme initialise cet ensemble avec un prédicat pertinent. Ensuite, l algorithme sélection itérativement chaque prédicat pertinent. Les prédicats non pertinents sont éliminés à fur et mesure de l évolution de l algorithme. - Construire l ensemble des minterms par conjonction d un ensemble de prédicats définit dans l étape précédente. - Réduire l ensemble des minterms : les minterms contradictoires sont éliminés. - Générer les fragments : A ce niveau, chaque minterm correspond à un fragment horizontal. II Algorithmes à base d affinités des prédicats Les auteurs dans (Zhang, et al., 1994) proposent une adaptation de l algorithme d affinité à base de regroupement binaire de (Navathe, et al., 1989). Cette adaptation permet de regrouper les prédicats de sélection par affinité et non plus les attributs. Pour ce faire, les auteurs utilisent la 44

53 Chapitre II : Problèmes de sélection des techniques d optimisation matrice d usage des prédicats, la matrice d affinité des prédicats et la matrice ordonnée. Ces matrices sont obtenues de la même manière que dans l algorithme de (Navathe, et al., 1989). Extraction des prédicats de sélection Charge de requêtes Matrice d usage Matrice d affinité Regroupement graphique Elimination des prédicats Complétude des composantes Composantes ou Prédicats optimisés Ensemble de minterms Figure II-10 : Architecture de fragmentation horizontale (Bellatreche, 2000) Par la suite, les auteurs définissent les fragments à partir du semi-bloc en liant tous les prédicats simples comprenant le même attribut par l'opérateur logique OU et les prédicats avec des attributs distincts avec l'opérateur logique ET. Enfin, ils définissent le fragment résiduel en construisant la négation de la disjonction des différents prédicats de fragmentation. (Bellatreche, 2000) propose également une adaptation de l algorithme d affinité à base de regroupement graphique de Navathe et al. pour la fragmentation horizontale primaire dans le contexte des bases de données, bases de données objets ou des entrepôts de données. Cet algorithme comporte huit étapes (figure II-10): - Enumérer les prédicats de sélection à partir de la charge de requêtes - Construire la matrice d usage Fragments horizontaux - Construire la matrice d affinité : la différence avec les travaux précédents est que cette matrice possède deux types de valeur : (1) numérique qui est la somme des fréquences des requêtes accédant simultanément à chaque paire de prédicats. (2) logique qui peut être : ou signifiant que le prédicat p i implique p j et qu ils accèdent aux même tuples, «*» qui signifie que p i et p j sont similaires (définit sur le même attribut et ont un prédicat commun définit lui sur un autre attribut) - Regrouper les prédicats graphiquement mais avec prise en comptes de règles suivantes : (1) la valeur numérique est plus prioritaires que la valeur logique. (2) si p p alors p j est plus prioritaire. (3) à plus d affinité que «*». - Optimiser les composants en éliminant les prédicats qui ont des prédicats plus prioritaires qu eux. Tous les attributs figurant dans tous prédicats sont des attributs de fragmentation. - Former les minterms : chaque composante permet de définir un fragment. Une composante C i peut ne pas couvrir tous les attributs de fragmentation, ce qui peut générer des fragments non disjoints. Ainsi, C i est rendue complète en deux phases : (1) identifier les attributs non 45

54 Chapitre II : Problèmes de sélection des techniques d optimisation utilisés par C i. (2) pour chacun attribut A j, partitionner C i en m nouvelles partitions où chaque partition contient les prédicats de C i plus un prédicat définit sur A j - Former les fragments horizontaux : chaque composante forme un fragment. Les prédicats définis sur les même attributs sont liées par un OU, sinon par un ET. Un fragment résiduel est défini par la négation de la disjonction de tous les prédicats définissant les autres fragments. - Générer les fragments disjoints : ceci en combinant les fragments non disjoints entre eux. II Problèmes liés aux deux algorithmes de fragmentation Plusieurs problèmes peuvent survenir lors de l adaptation de l approche de complétude et minimalité ou l approche d affinité des prédicats, on peut citer les problèmes suivants : - Les algorithmes qui se basent sur la minimalité et la complétude des prédicats sont complexes. Pour n prédicats le nombre de minterms pouvant être générés est de 2 n. - L approche des affinités est moins complexe que celle des prédicats mais le critère de regroupement est la fréquence d accès des requêtes aux attributs. Il faut prendre en compte d autres critères : les facteurs de sélectivité des prédicats, la taille des tables, etc. - Les deux approches ne permettent pas d évaluer le schéma de fragmentation. - Ces méthodes ne permettent pas de contrôler le nombre de fragments générés. Quand ce nombre est important, l administration de l entrepôt devient une tâche difficile - Ces techniques sont utilisées pour la fragmentation primaire d une seule table. II Algorithmes à base de modèle de coût Les approches proposées jusqu ici présentent un grand handicape. Elles ne permettent ni d évaluer le coût d exécution des requêtes, ni de montrer l amélioration apportée par la fragmentation pour l exécution des traitements. De plus, on ne peut affirmer que tel ou tel algorithme est le plus efficace pour la sélection d un schéma de fragmentation. Ainsi, (Bellatreche, 2000) et (Boukhalfa, et al., 2008a) proposent une stratégie de sélection qui emploie un modèle de coût afin d évaluer chaque schéma de fragmentation généré. Elle est réalisée en trois étapes : - Phase de génération les schémas de fragmentation : à partir des la charge de requêtes, les prédicats de sélection sont extraits. Ils permettent d identifier les différents fragments à travers les minterms. Un générateur produit tout les schémas de fragmentation possibles. - Phase d évaluation : se base sur un modèle de coût, elle permet d évaluer le coût d exécution des requêtes sur chaque schéma de fragmentation généré. - Phase de sélection du schéma optimal : permet de déterminer le schéma de fragmentation le plus bénéfique pour l exécution de la charge de requête. Le premier algorithme proposé est exhaustif et consiste à construire tous les schémas de fragmentation possibles par fragmentation horizontale. Il énumère ensuite ces schémas et calcule pour chacun d'entre eux le coût d'exécution des requêtes de la charge. Il sélectionne finalement le schéma qui correspond au coût minimum. Le deuxième algorithme est approximatif. Il construit un schéma initial par l'algorithme de fragmentation dirigé par les affinités, puis l'améliore par des opérations de fusion ou de décomposition des fragments. Finalement, le troisième algorithme exploite un algorithme génétique pour sélectionner le schéma de fragmentation optimal. 46

55 Chapitre II : Problèmes de sélection des techniques d optimisation II.3.3 Algorithmes de fragmentation mixte La fragmentation mixte d une relation s effectue en combinant entre une fragmentation horizontale et une autre verticale. Pour ce faire, deux approches de fragmentation existent : la fragmentation par création de grille et la fragmentation par définition de vues II Fragmentation par création de grille Proposé par (Navathe, et al., 1995), cet algorithme consiste à fragmenter une relation horizontalement et verticalement puis de combiner les résultats afin de construire une grille. Chaque cellule de la grille est définie à partir d un prédicat de sélection (fragment horizontal) et un prédicat de projection (fragment vertical) II Fragmentation par définition de vues Les travaux de (Pernul, et al., 1991) présentent une démarche de fragmentation mixte d un schéma relationnel en fragments disjoints où un ou plusieurs fragments représentent une vue. Cette démarche est réalisée en trois étapes : (1) Trouver toutes les vues ayant une intersection. (2) Pour chaque paire de vues, appliquer les processus de la fragmentation verticale, horizontale (primaire et dérivée) afin de construire des fragments potentiels disjoints. (3) Appliquer les même processus sur les vues isolées. II.3.4 Fragmentation dans les entrepôts de données Plusieurs travaux se sont intéressés à la fragmentation des entrepôts de données. La fragmentation la plus étudiée est la fragmentation horizontale (Bellatreche, 2000), (Bellatreche, et al., 2006), (Boukhalfa, et al., 2008a) et (Bellatreche, et al., 2009). En effet, la fragmentation verticale ajoute un coût de jointures pour la reconstitution des tables initiales, mais il existe des travaux qui traitent de cette fragmentation (Golfarelli, et al., 1999). II Travaux de Golfarelli et al. Les auteurs proposent une méthode de fragmentation verticale des entrepôts de données, plus exactement les vues (Golfarelli, et al., 1999). Cette approche de fragmentation est effectuée en deux opérations : le partitionnement d'une table en plusieurs fragments et l'unification des fragments deux à deux en un seul fragment. Les opérations de partitionnement et unification sont effectué plusieurs fois, à chaque fois le schéma obtenu est évalué par modèle de coût jusqu'à trouver le schéma qui optimise le plus une charger de requêtes. II Travaux de Bellatreche L auteur propose une méthodologie de fragmentation dans un entrepôt de données relationnel centralisé modélisé en étoile (Bellatreche, 2000). Cette méthode effectue la FH primaire des tables de dimensions puis une FH horizontale dérivée de fait. L algorithme prend en entrée n requêtes de jointures munies de leurs fréquences et réalise les étapes suivantes : - Enuméré les prédicats de sélection à partir de la charge de requêtes puis calculer leurs facteurs de sélectivité. - Attribuer à chaque table dimension un ensemble de prédicats de sélection. - Identifier les dimensions à fragmenter en éliminant celles n ayant pas de prédicats de sélection. - Vérifier la complétude et la minimalité en appliquant l algorithme COM-MIN, utilisé dans (Ozsu, et al., 1991), sur chaque sous ensemble de prédicats. Ceci garanti que chaque table soit fragmentée en au moins deux fragments accédé chacun par au moins une requête. 47

56 Chapitre II : Problèmes de sélection des techniques d optimisation - Fragmenter les tables de dimensions par un des algorithmes de fragmentation basé sur la complétude et la minimalité des prédicats - Fragmenter la table de faits par une FH dérivée selon les fragments de dimensions. Le problème de cette démarche est le nombre important de fragments de fait générés. Ainsi, l auteur propose de réduire la complexité de fragmentation en réduisant le nombre de table de dimensions à fragmenter obtenues dans la troisième étape. Ceci est un problème de sélection des tables de dimension à fragmenter formalisé comme suit : - Soit une charge de m requête. - Soit d tables de dimensions. - Soit N le nom de fragments de fait maximum. Le but est de choisir un ensemble de tables de dimension à partir de la totalité des tables qui permet d obtenir un schéma de fragmentation avec un nombre de fragments qui ne dépasse pas N et qui optimise au mieux l exécution des requêtes. Pour sélectionner les tables de dimensions, l auteur propose un algorithme glouton. Ce dernier commence par sélectionner une dimension d une manière aléatoire et effectue la fragmentation de l entrepôt. Il calcule le nombre de fragments généré et le coût d exécution des requêtes. Si le nombre de fragments N et le coût est réduit, la table est sélectionnée, sinon elle est rejetée. II Travaux de Bellatreche et al. et Boukhalfa et al. Les travaux de (Bellatreche, et al., 2006), (Boukhalfa, et al., 2008a) et (Bellatreche, et al., 2009) s intéressent à mettre en œuvre une démarche de fragmentation horizontale dans les entrepôts de données. Cette démarche représente les caractéristiques suivantes : - Approche basée sur un modèle de coût. - Permet le contrôle du nombre de fragments générés. - A partir d un nombre de fragments maximum fixé par l administrateur, elle effectue la fragmentation de l entrepôt suivant le scénario suivant : FH primaire des dimensions suivant laquelle la FH dérivée de la table de fait est effectuée. Ce scénario est le plus approprié pour les entrepôts de données, il permet d améliorer les opérations de sélections sur les dimensions et les opérations de jointures entre faits et dimension (Boukhalfa, et al., 2008a). Nous procédons à la description générale de cette démarche. Nous présentons la motivation des auteurs pour mettre en œuvre une nouvelle stratégie de fragmentation horizontale. a) Motivation Dans le domaine de l industrie, les SGBD commerciaux, particulièrement Oracle, supportent la fragmentation horizontale. Oracle permet d effectuer la fragmentation horizontale primaire d une table suivant les modes RANGE, LIST et HASH par rapport à une clé de fragmentation : c est le mode simple. Il permet également d étendre cette fragmentation en deux niveaux à l aide du mode composite, où deux modes simples sont employés pour fragmenter une table suivant deux clé de fragmentation. Concernant la fragmentation horizontale dérivée, elle est supportée par le mode REFERENCE permettant de fragmenter une table suivant la FH primaire d une autre table. Même si Oracle offre différents modes et opérations de fragmentation, celui-ci présente une limitation importante : - La FH dérivée d une table est effectuée sur la FH primaire d une seule autre table. - La FH primaire d une table est faite sur deux attributs au plus. 48

57 Chapitre II : Problèmes de sélection des techniques d optimisation Cette limitation représente un grand handicape dans le contexte d entrepôt de données. En effet, les requêtes exécutées sur entrepôt renferment des jointures en étoiles entre une table de faits et plusieurs tables de dimensions avec plusieurs opérations de sélections sur dimensions. Afin d optimiser ce type de requêtes, il serait intéressant de pouvoir fragmenter les dimensions suivant plusieurs attributs (plus de deux) puis de fragmenter la table de fait suivant la fragmentation primaire de toutes les dimensions concernées (Boukhalfa, et al., 2008a). b) Formalisation du problème Suivant le scénario choisi par les auteurs pour la fragmentation horizontale d un entrepôt, le problème est l explosion du nombre de fragments de faits qui dépend du nombre de fragments de dimension. Si le nombre de fragments de dimensions D i est m i, alors le nombre de fragments de fait est N=. Le problème de sélection du schéma de fragmentation, en considérant une contrainte sur le nombre de fragments généré, a été formalisé dans ces travaux comme suit : Etant donné : - Q={Q 1,,Q m } un ensemble de requêtes. - F une table de fait et D={d 1,,d n } d tables de dimensions. - W le nombre de fragment de la table de fait imposé par l administrateur Le problème se sélection d'un schéma de fragmentation consiste à fragmenter la table de fait F en N fragments selon des schémas de fragmentation des tables de dimension tel que : - Le coût d exécution des requêtes soit minimal - Le nombre de fragment de F soit minimisé : N W c) Le modèle de coût Afin de mettre en œuvre le modèle de coût, les auteurs ont établi les hypothèses suivantes : - Le coût d exécution des requêtes est estimé par le nombre d accès disque (E/S) nécessaires pour le chargement des données. - Algorithme de sélection d un ordre de jointure : la sélection de l ordre de jointure est un problème combinatoire (NP-Complet). Ainsi, les auteurs se basent sur une technique de sélectivité minimum qui est simple à appliquer, non gourmande en temps de calcul et permet d ordonner l exécution des jointures. A chaque étape, cette technique calcul le facteur de sélectivité de la jointure entre l ensemble des tables déjà sélectionnées et chaque table qui reste, la table qui engendre le facteur de sélectivité minimum est choisie. - Pour l opérateur de jointure, les auteurs ont choisi d utiliser la jointure par hachage. - Le modèle de coût est estimé à traves trois types de données : - Les données de l entrepôt : nombre de tuples de chaque table, la taille de chaque tuple, le nombre de pages stockant une table. - Les paramètres physiques : la taille du buffer (pour stocker les résultats intermédiaires et réduire ainsi le nombre d E/S) et la taille de la page. - Les données de la charge de requêtes : les fréquences d accès, les facteurs de sélectivité des prédicats de sélection, les facteurs de sélectivité des jointures. d) Démarche de fragmentation Les auteurs proposent une démarche de fragmentation qui permet en premier lieu de fragmenter par FH primaire les dimensions de l entrepôt. La sélection d un schéma de fragmentation optimal des dimensions suit quatre étapes importantes : d abords les informations 49

58 Chapitre II : Problèmes de sélection des techniques d optimisation qui permettent la spécification d un schéma de fragmentation sont extraites. Ensuite, un codage d un schéma de fragmentation est spécifié. Puis un ensemble de schéma candidats est générer. Enfin, sur cet ensemble de schémas possibles, le schéma de fragmentation optimal est sélectionné. - Préparer la fragmentation : A partir de la charge de requêtes, les prédicats de sélection sont extraits. Ces prédicats permettent de spécifier les attributs de sélection sur lesquels portera la fragmentation des dimensions et dont les domaines sont découpés en sous domaines. Ces attributs permettent, à leur tour, d identifier les dimensions candidates à la fragmentation. Puis, pour chaque table de dimension, un ensemble de prédicats complet et minimal est générer. - Coder le schéma de fragmentation : Chaque attribut de fragmentation AFi de la dimension Dk, extrait au niveau de l étape précédente, possède un domaine de valeurs di. Le découpage du domaine di en n sous domaine sd1,, sdni permet de spécifier ni fragments de la dimension Dk. Pour t attributs AF1,, AFt de la dimension Dk le nombre de fragments total est égale à. Ce nombre représente le nombre de fragments maximum pour une dimension, il se peut que certains domaines soient regrouper dans le même domaine ce qui permet de générer un nombre de fragments dimension inférieur à. Afin d exprimer cela, les auteurs proposent un codage du schéma de fragmentation qui attribue à chaque sous domaine sdj de chaque AFi un numéro. Les sous domaines du même AFi ayant le même numéro définissent le même fragment. Exemple 18 : Soit un entrepôt de données dont le schéma est donné par la figure II-11. Soient les attributs de fragmentation suivants : «Genre» avec les valeurs {F, M}, «Classe» avec les valeurs {A, B, C} et «Age» dont les valeurs sont représentées par l intervalle [0, 60]. Le découpage en sous domaines des domaines de ces attributs est : Genre : {F} et {M}, Classe : {A}, {B} et {C}, enfin Age = [0, 20[, [20, 40[et [40, 60]. Temps Id Mois Année Produit Id Classe Vente Id_Temps Id_ Client Id_ Produit Prix_Unit Client Id Age Genre Pays Figure II-11: Schéma en étoile d un entrepôt de données Un codage du schéma de fragmentation est représenté par la figure II-12 Age Genre Classe [0, 20[ [20, 40[ [40, 60] F M A B C Figure II-12: Codage d un schéma de fragmentation Ce codage présenté sur la figure II-12 montre les points suivants : (1) Les dimensions concernées par la fragmentation sont la dimension Client sur les attributs Age et Genre et la dimension Produit sur l attribut Classe. (2) Pour la dimension Client, chaque sous domaine de l attribut Age possède un numéro différent. Par contre, les domaines de l attribut Genre possèdent le même numéro. Cet attribut ne participe donc pas au processus de fragmentation. Par conséquent la 50

59 Chapitre II : Problèmes de sélection des techniques d optimisation table Client est fragmentée en trois fragments selon l attribut Age. (3) Pour la dimension Produit, les domaines {A} et {B} de Classe sont regroupés en un seul domaine (ils possèdent le même numéro 0), ce qui signifie que les tuples Produit dont la Classe est égale à «A» ou «B» appartiennent au même fragment. Cela donne deux fragments de la table Produit. - Générer une solution initiale : les auteurs proposent d utiliser l algorithme d affinités adapté à la FH dans les entrepôts où le regroupement ne se fait pas sur les prédicats mais sur les sous domaines des attributs. Une affinité entre deux sous-domaines est la somme des fréquences d accès des requêtes accédant simultanément à ces deux sous-domaines. - Appliquer une heuristique : La solution initiale est améliorée grâce à l application des heuristiques. Concernant le Hill Climbing, deux mouvements sont utilisés : Split pour fragmenter Merge pour fusionner. Le problème est que cette heuristique présente un problème majeur : la sélection d un optimum local comme solution de fragmentation. Ainsi, le Recuit simulé est utilisé. Ces deux heuristiques exploitent une seule solution à la fois, ainsi l algorithme génétique est utilisé pour permettre la considération de plusieurs schémas de fragmentations au même temps sous forme d une population. Cette population est améliorée en appliquant des opérations génétiques de sélection, croisement et mutation. Une fois le schéma de fragmentation optimal des dimensions est trouvé, la fragmentation dérivée de la table de faits est effectuée. Les détails de mise en œuvre de cette fragmentation sont expliqués dans la section III.6.1 e) Réécriture des requêtes Les auteurs ont proposé une nouvelle démarche de fragmentation non supportée par les SGBD commerciaux. Afin de bénéficier de cette fragmentation de l entrepôt, il faut réécrire les requêtes sur le nouveau schéma de données. Cette réécriture à pour but de charger uniquement les fragments nécessaires pour l exécution d une requêtes donnée. Une fois l entrepôt de donnée fragmenté, il peut être représenté sous forme de plusieurs sous schémas en étoile. Ainsi, pour calculer le coût d exécution d une requête sur un schéma fragmenté, il faut calculer ce coût sur chaque sous schéma. Avant cela, il faut identifier les sous schémas valides et leur correspondance pour une requête. 1) Identifier les sous schéma en étoile valides pour la requête comme suit : - Identifier les fragments de dimensions valides pour la requête (comparer les prédicats de la requête et ceux formant la clause définissant chaque fragment de dimension) - Utiliser ces fragments pour déterminer les fragments de faits valides. 2) Exécuter la requête sur chaque sous schéma. Pour ce faire il faut identifier la correspondance entre la requête et le fragment de faits pour déterminer les jointures à exécuter en plus des jointures spécifiées dans la clause WHERE. Cette correspondance peut être : - Totale : la réponse à la requête est le fragment de faits, aucune jointure n est requise - Partielle : le fragment de faits contient des tuples non pertinents pour la requête, il faut effectuer des jointures avec les tables de dimensions pour les éliminer. Exemple 19 : Le codage su schéma de fragmentation de la figure II-13 donne quatre fragment fait «Vente1» «Ventre4» et donc quatre sous schéma en étoile 51

60 Chapitre II : Problèmes de sélection des techniques d optimisation Produit1 Classe = A ou B Vente1 Vente2 Client1 Genre= F Produit1 Classe = C Vente3 Vente4 Client2 Genre= M Figure II-13: Schéma d entrepôt fragmenté Soit la requête : SELECT Id_Temps, Sum(Prix_Unit) FROM Vente V, Client C, Produit P WHERE V.Id_Produit=P.Id AND V.Id_Client=C. Id AND C.Genre= F GROUP BY Id_Temps La réécriture donne SELECT Id_Temps, Sum(Prix_Unit) FROM ( SELECT Id_Temps, Prix_Unit FROM Vente PARTITION (Vente1) UNION ALL SELECT Id_Temps, Prix_Unit FROM Vente PARTITION (Vente3) ) GROUP BY Id_Temps II Travaux de Mahboubi Dans (Mahboubi, 2009), l auteur s intéresse à la fragmentation horizontale des entrepôts de données XML afin de les répartir sur plusieurs sites. Pour ce faire, il se base sur l adaptation des techniques de fragmentation existantes sur les entrepôts XML comme la fragmentation horizontale primaire basée sur les prédicats et celle basée sur les affinités de prédicats. Ensuite, il présente une nouvelle méthode à base du concept de fouilles de données à savoir la fragmentation basée sur la classification des prédicats. Elle est effectuée en trois étapes : - Codage des prédicats de sélection de la charge de requêtes dans une matrice binaire qui représente le contexte de classification. elle est similaire à la matrice d usage des prédicats. - Classification des prédicats par application de la technique des k-means (Pham, et al., 2004) qui permet de partitionner l ensemble des prédicats en k classes disjointes. - Construction des fragments. Cette étape exploite l'ensemble de classes et le document XML qui représente le schéma de l'entrepôt pour construire un autre document XML sur le schéma de fragmentation. Afin d assurer la complétude, un fragment supplémentaire est ajouté par négation de la disjonction de tous les prédicats. II.3.5 Synthèse Nous avons abordé la fragmentation de données et le problème de sélection d un schéma de fragmentation qui permet d optimiser une charge de requêtes. Nous avons évoqué les travaux dans le domaine qui traitent de la fragmentation dans le contexte de bases de données ou entrepôts de données. Nous allons résumer dans le tableau qui suit ces différents travaux. 52

61 Chapitre II : Problèmes de sélection des techniques d optimisation Travaux Contexte Type Algorithme employé Modèle de coût Hammer et al. (1979) BDD Verticale Modèle de simulation - Navathe et al. (1989) BDD Verticale Affinité des attributs, regroupement binaire et graphique Modèle mathématique Navathe et al. (1995) BDD Mixte Création de grilles - Ozsu et al. (1991) BDD répartie Horizontale Complétude et minimalité des prédicats (COM-MIN) Modèle mathématique Pernul et al. (1991) BDD Mixte Fragmentation par définition de vues - Zhang et al (1994) BDD Horizontale Affinité des prédicats par regroupement binaire Modèle mathématique Golfarelli et al. (1999) ED répartie Verticale Fragmentation de vues - Bellatreche (2000) 1 ED relationnel Horizontale Affinité des prédicats, regroupement graphique Bellatreche (2000) 2 ED relationnel Horizontale Complétude et minimalité des prédicats Bellatreche, Boukhalfa (2006, 2008, 2009) ED relationnel Horizontale Heuristique (Hill Climbing, recuit simulé), algorithmes génétiques Mahboubi (2009) ED XML Horizontale Classification des prédicats par algorithme de fouille de données Tableau II-2 : Comparaison entre travaux de fragmentation Modèle mathématique Modèle mathématique Modèle mathématique Modèle mathématique Le tableau II-2 présente une classification des travaux de fragmentation suivant plusieurs critères à savoir le contexte de données (entrepôt ou base), la nature de fragmentation (horizontale, verticale ou mixte) et l algorithme de fragmentation (heuristique, algorithme génétique, complétude et minimalité des prédicats, fouille de donnée etc.) et enfin l utilisation d un modèle de coût. Ce dernier critère montre que seul le modèle mathématique est employé. Malgré la difficulté à maintenir un schéma de fragmentation cohérent, son adaptation dans un entrepôt de données est très efficace puisque les requêtes de mise à jour sont très rares. Cela dit, La fragmentation horizontale FH est la plus adaptée pour les entrepôts. En effet, la fragmentation verticale nécessite des jointures très coûteuses. Ainsi, il est préférable d employé des index de projection pour l optimisation des requêtes de projection (Bellatreche, 2000) II.4 Sélection combinée d IJB et FH dans les entrepôts de données La sélection et la gestion des structures d optimisation sont au cœur de la conception physique d un entrepôt de données. Pour optimiser une charge de requêtes, l administrateur peut sélectionner une ou plusieurs structures. La sélection est isolée s il choisit une seule structure, elle est multiple (combinée) sinon. La sélection isolée n est pas toujours suffisante pour optimiser toute la charge de requêtes, particulièrement dans les entrepôts de données. En effet, les requêtes sont nombreuses (plusieurs dizaines), très complexes et sont exécutées sur un volume importants de données (table de fait de plusieurs Gega ou Tera octets), d où le recours à la sélection multiple (Bellatreche, et al., 2007) (Boukhalfa, et al., 2008b) et (Stöhr, et al., 2000). La sélection multiple peut concerner des structures redondantes, non redondantes ou les deux. Elle est plus complexe que la sélection isolée vue la complexité de son espace de recherche englobant ceux des structures concernées. En plus de cette complexité, une autre s y ajoute concernant la gestion des similarités (ou dépendances) entre certaines structures. Prenons l exemple des vues matérialisées et des index. Elles génèrent deux schémas d optimisation redondants, partageant la même ressource qui est l espace de stockage et nécessitent des mises à jour régulières. Une vue matérialisée 53

62 Chapitre II : Problèmes de sélection des techniques d optimisation relationnelle peut être indexée afin d augmenter ses performance. En conséquence, en plus des tables, il faut considérer les vues matérialisées lors du processus de sélection des index. Cette similarité pourrait influencer la sélection de leurs schémas (Zilio, et al., 2004). Récemment, une autre similarité entre les index de jointure binaire et la fragmentation horizontale dérivée (ou référentielle) a été identifiée. En effet, ces deux techniques permettent d optimiser les opérations les plus coûteuses en coût et en temps d exécution. A savoir les opérations de jointures entres table de faits volumineuse et plusieurs dimensions avec sélection sur les dimensions. De ce fait, des travaux se sont intéressés à la sélection combinée de ces deux structures d optimisation (Stöhr, et al., 2000), (Boukhalfa, et al., 2008b), cela pour les raisons suivantes: - Optimiser les jointures en étoiles avec opérations de sélection sur dimensions. - Trouver un compromis entre les deux contraintes de sélection des deux structures : l espace de stockage pour les index et le nombre maximum de fragments faits générés pour la fragmentation, dans le but d optimiser un maximum de requêtes décisionnelle. - Seul les index nécessitent un espace de stockage ca ils représentent une technique redondante, contrairement à la fragmentation qui est non redondante. II.4.1 Type de sélection combinée Les index est la fragmentation sont définis sur le même ensemble d attributs de sélection appartenant aux tables dimensions, ils se partagent donc la même ressource. De ce fait, la sélection combinée d index et de schéma de fragmentation peut se faire de deux manières : parallèle : où chaque technique est définie sur le même ensemble d attributs de manière simultanée, séquentielle : qui permet de définir une première structure sur l ensemble d attributs puis de sélectionner la seconde structure sur le reste d attributs (figure II-14). Sélection parallèle Ensemble d attributs Sélection séquentielle Ensemble d attributs Sélection d un schéma de FH Sélection d un schéma de FH Sélection d un schéma d index Attributs écartés par la FH Sélection d un schéma d index Figure II-14 : Types de sélection combinée pour deux structures d optimisation Une fois la sélection des structures d optimisation effectuée, l implémentation de ces structures sur l entrepôt est établie. Cette implémentation est réalisée de manière séquentielle : soit les index sont définit puis la fragmentation est réalisée sur les tables et les index, soit la fragmentation est effectuée suivi de l indexation de chaque fragment. Le résultat obtenu représente des tables fragmentées et chaque fragment est muni d un index sur ces données, si le fragment contient un attribut indexable. 54

63 Chapitre II : Problèmes de sélection des techniques d optimisation II.4.2 Choisir entre sélection parallèle ou séquentielle Concernant les index et la fragmentation, la sélection parallèle peut s avérer non bénéfique. En effet, un même attribut peut être choisit pour définir un index et un schéma de fragmentation au même temps. Dans ce fait, les deux structures auront le même effet d optimisation et une d entre elle sera inutile. Vu les contraintes liées au index et a la fragmentation (espace de stockage limité, nombre de fragment maximum) ce cas de figure ne peut être permis. Ainsi, le type sélection combinée le plus adapté est la sélection combinée séquentielle. Exemple 20 : Soient la table de fait Vente et la dimension Client représentée par la figure II-15. Nous définissons un IJB et une FH sur l attribut Pays, le résultat est illustré sur la figure II-16 Table Client Id Age Genre Pays M F M M Algérie Liban Liban Algérie Vente 1 Id Id_C Quanté Figure II-15 : Population de l entrepôt Client1 Id Age Genre Pays M M Client2 Algérie Algérie Id Age Genre Pays F M Liban Liban Vente 1 IJB1 Id Id_C Quanté Algérie Liban Syrie Vente IJB2 Id Id_C Quanté Algérie Liban Syrie Figure II-16 : Optimisation par FH et IJB sur l attribut Pays La figure II-16 montre que les index définis sur les fragments de Vente sont inutiles. En effet, une requête qui utilise l attribut Pays sera optimisée par fragmentation sans utilisation de l IJB. Nous allons présenter dans ce qui suit, les travaux qui abordent l optimisation d un entrepôt de données par index de jointures binaires et fragmentation horizontale. II.4.3 Travaux de T. Stöhr et al Les auteurs s intéressent à la mise en œuvre d une stratégie d optimisation des requêtes dans les entrepôts de données parallèles par index de jointures binaires et fragmentation horizontale, puis allocation d espace de stockage pour ces structures. Ils proposent de définir les index bitmaps sur le schéma en étoile de l entrepôt, puis de fragmenter à la fois les tables et les index. Pour ce faire, ils définissent une démarche de fragmentation hiérarchique multidimensionnelle notée MDHF. Elle se base sur les hiérarchies des attributs dimensions (pour la table Temps, une hiérarchie est Année Trimestre Mois Jour) ainsi que la duplication des données de chaque niveau de la hiérarchie suivant les niveaux plus haut (le mois Janvier de l année 2008 diffère du mois de Janvier de 2009). 55

64 Chapitre II : Problèmes de sélection des techniques d optimisation Attributs de dimensions IJB sur les attributs de faibles cardinalité IJB encodés sur une hiérarchie d attribut Attributs de FH (un attribut par hiérarchies-dimension) Schéma de fragmentation des tables et index Ecarter les bitmaps inutiles (bitmaps définis sur des attributs de FH et ceux plus haut dans la hiérarchie) Allocation disque pour les structures Figure II-17: schéma de sélection combinée d IJB et FH par Stöhr Année Trimestre Mois Jour Total bitmap Cardinalité totale Cardinalité sans parent Nombre de bits pour le codage (log 2 ) Exemple de code a bb cccc dddddddd abbccccdddddddd Tableau II-3 : Représentation d un codage d une hiérarchie pour IJB encodé La démarche, proposée par les auteurs (figure II-17), s effectue en deux étapes : la première étape permet la définition des fragments des tables et index de jointure binaires. La seconde étape réalise l allocation des fragments sur les différents disques et espaces de stockage. La partie qui nous intéresse est la sélection des structures d optimisation, elle est réalisée comme suit ; 1. Définir des IJB simples sur les attributs de faible cardinalité, et les index encodé sur une hiérarchie d attributs à forte cardinalité. Soit la hiérarchie Année Trimestre Mois Jour, un IJB encodé est représenté par le tableau II-3. Le code «abbccccdddddddd» spécifie le nombre de bitmap obtenu pour les 4 attributs dimensions au lieu de 2880 possibles. 2. Définir un schéma de fragmentation sur la table de fait et ces index. A partir de chaque hiérarchie, un seul attribut est choisi pour la fragmentation. Le nombre de fragments fait total est le produit des cardinalité de tous les attributs de fragmentation. 3. Ecarter les bitmaps inutiles. Ce sont les bitmaps défini sur les attributs de fragmentation et leurs parents (attributs plus haut dans la hiérarchie). En effet, les bitmaps servent à sélectionner les tuples réponse d une requête dans le cas où celle-ci est trop sélective par rapport à un fragment donné. Supposant une fragmentation sur l attribut Mois. Pour une requête qui utilise la sélection sur «Mois=Janvier» et «Jour=12», il faut écarter de chaque fragment «Mois=Janvier» les jour différents de 12 en utilisant les bitmaps. Or pour une requête qui emploie «Trimestre=4», aucune sélection n est effectuée sur les fragments, une 56

65 Chapitre II : Problèmes de sélection des techniques d optimisation opération d union s impose entre tous les fragments dont le Mois appartient au Trimestre 4. De ce fait, les bitmaps définis sur Année, Trimestre et Mois sont inutiles, seuls les bitmaps sur Jour sont retenus. Cette démarche de sélection à pour avantage l élagage de l ensemble des attributs dimensions par la réduction d un coté du nombre d attributs candidats à la FH et de l autre le nombre d index possibles. Néanmoins, dans cette démarche, aucun contrôle n est effectué sur le nombre de fragments fait générés. En effet, ce dernier représente le produit des cardinalité des attributs de FH. Dans le cas où tout les attributs de FH choisi sont de basse hiérarchie, aucun index n est nécessaire, mais le nombre de fragments fait explose (la FH sur Jour uniquement présente 2880 fragments). II.4.4 Travaux de Bellatreche et al. et Boukhalfa et al. Entrepôt de donnée Charge de requêtes Attributs de sélection Sélection d un schéma de FH Implémentation des structures d optimisation Requêtes non bénéficières de la FH Modèle de coût Attributs d indexation de faibles cardinalité Sélectionner les IJB Configuration finale de FH et IJB Figure II-18: schéma de sélection combinée d IJB et FH Pour leurs travaux, les auteurs (Boukhalfa, et al., 2008b) proposent une approche de sélection combinée séquentielle entre fragmentation horizontale et index de jointure binaire. Pour ce faire, ils présentent deux interdépendances pouvant exister entre les structures d optimisation proposés par les chercheurs d IBM (Zilio, et al., 2004) : la dépendance forte et la dépendance faible. Une technique d optimisation dépend fortement d une autre si un changement dans la seconde se traduit souvent par un changement dans la première. Sinon, l indépendance est faible. 57

66 Chapitre II : Problèmes de sélection des techniques d optimisation Les auteurs ont montré que l interaction entre IJB-FH est forte faible. En effet, la mise en œuvre d un IJB dépend de la structuration des données. Ainsi, les auteurs proposent une sélection combinée avec mise œuvre de FH suivie de la définition d IJB (figure II-18) comme suit: - Sélectionner un schéma de FH sur l ensemble des attributs candidats. - Déterminer les requêtes non bénéficiaires en utilisant un paramètre de tuning ( [0,1]) fixé par l administrateur. Pour cela les auteurs définissent une métrique :,,, - Où, et, sont le coût d exécution de la requête sur un schéma partitionné SF et non partitionné respectivement. Ainsi, si alors est bénéficiaire, est non bénéficiaire sinon. - Déterminer les attributs candidats à l indexation extrais à partir des requêtes non bénéficiaires. Les auteurs privilégient les attributs à faible cardinalité. - Sélectionner un ensemble d IJB sur l entrepôt fragmenté en utilisant les algorithmes de sélection d IJB Afin de mettre en œuvre cette méthode de sélection, les auteurs dans (Bellatreche, et al., 2008a) proposent un outil d assistance à l administration et de tuning appelé ParAdmin. Cet outil gère trois techniques d optimisation ; la fragmentation horizontale primaire ; la fragmentation horizontale dérivée et les index de jointure en étoile. ParAdmin propose ce qui suit : - Permet de visualiser l état courant de l entrepôt de données : sa structure et la charge de requêtes. - Offre deux modes de sélection de techniques d optimisation : personnalisée par l administrateur et non personnalisée qui propose "le meilleur schéma" d optimisation pour l entrepôt. - Offre une sélection mono et multi-structure d optimisation. - Permet de voir la qualité de chaque technique d optimisation proposée et de ses critères de performance : le coût d E/S de requêtes, le taux d amélioration apporté par la technique, etc. Cet outil propose trois stratégies d optimisation : une à base d IJB notée IJBSEULE, une seconde à base de fragmentation notée FHSEULE et la dernière qui combine IJB&FH. pour la dernière stratégie l outil commence par une FHSEULE puis exécute l opération IJBSEULE. Les attributs d indexation sont choisis parmi les attributs de sélection non utilisé dans la FH. II.4.5 Analyse de l approche existante Dans l approche que nous venons de voir, la FH est sélectionnée sur l ensemble des attributs de sélection extraits de la charge de requêtes. Par la suite, les IJB sont définis sur le reste des attributs extraits à partir des requêtes non bénéficiaires (ceux qui ne contribuent pas à la définition du schéma de FH). Les requêtes non bénéficiaires sont déterminées suivant un paramètre. Les points forts de la démarche proposés par les auteurs sont résumés comme suit : - Elaboration d une nouvelle approche de fragmentation horizontale qui combine la FH primaire des dimensions suivi d une FH dérivée de la table de fait. - Utilisation d une contrainte W pour contrôler le nombre de fragments fait générer. - Prise en compte des requêtes non bénéficiaires de la fragmentation pour la spécification d'ijb. Cela permet de couvrir l optimisation d un maximum de requêtes. 58

67 Chapitre II : Problèmes de sélection des techniques d optimisation Néanmoins, l approche que nous venons de décrire, présente des problèmes qui vont nous permettre d élaborer une nouvelle démarche de sélection combinée de FH et IJB. Ces problèmes sont présentés comme suit : - La sélection combinée fait que la FH est défini sur tout l ensemble des attributs de sélection. Cela donne un très grand nombre de configurations de schéma de FH possibles. - L utilisation d un paramètre approximatif pour définir les requêtes non bénéficiaires, à partir desquelles sont extraits les attributs d indexation. - La FH est réalisée indépendamment de la sélection d IJB. Du coup, il n est pas sûr que les attributs laissé pour indexation soient les plus appropriés. - Les IJB définis après fragmentation peuvent s avérer inutiles pour l optimisation. En effet, si le volume de données chargé par index est tout aussi volumineux que la table même, l optimiseur du SGBD jugera préférable d utiliser la table directement. - Des attributs peuvent être choisis pour la FH alors que leur sélection pour un IJB donnerait un meilleur résultat. En effet, à cause de la contrainte W sur le nombre de fragments, les valeurs d un attribut peuvent se regrouper dans un même domaine, cela obligerait le chargement d une grande partie de données pour une requête comportant la sélection sur une seule valeur de l attribut. 59

68 Chapitre II : Problèmes de sélection des techniques d optimisation Conclusion Nous avons présenté dans ce chapitre les travaux sur les techniques d optimisation dans les entrepôts de données. Nous avons abordé les travaux sur les index en général et les index de jointure binaires en particulier. Nous avons décrit les démarches de sélection d index dans ces travaux. Nous avons effectué une synthèse des travaux dans un tableau comparatif. Cette synthèse compare les travaux sur les index suivant le contexte de données (base de données ou entrepôt de données), le type de sélection (index simple, index de jointure binaire), la démarche de sélection des index candidats (manuelle ou automatique), l algorithme de sélection (heuristique, glouton) et enfin l utilisation ou pas d un modèle de coût. Nous avons mis l accent sur les index de jointures binaires : principe, complexité problème de sélection et démarche de sélection Par la suite, nous avons abordé les différents types de fragmentation horizontale, verticale et mixte. Nous avons présenté les travaux sur cette technique et les avons classés selon le contexte de donnée, type de fragmentation, algorithme de fragmentation (affinité d attributs ou prédicats, complétude et minimalité des prédicats, heuristique basé sur un modèle de coût, fouille de données) et le problème NP-Complet abordé (sélection d attributs, sélection des prédicats, sélection d un schéma de fragmentation). Nous avons abordé de manière plus détaillée la fragmentation horizontale des entrepôts de données Pour finir, nous avons présenté les travaux de sélection combinée entre index de jointure binaires et fragmentation horizontale dans le contexte d entrepôt de données. Nous avons analysé ces travaux afin de pouvoir proposer une nouvelles approche que nous allons décrire dans le chapitre suivant. 60

69 III. Chapitre III : Nouvelle démarche de sélection d index et de fragmentation, dirigée par la classification Dans le contexte d entrepôt de données, les requêtes exécutées renferment des opérations de jointures en étoile entre table de faits volumineuse (des dizaines voir même des centaines de millions de tuples) et plusieurs tables de dimensions avec opérations de sélection sur les dimensions sur plusieurs attributs. Ces opérations sont très gourmandes en temps et en ressources et engendrent un coût d exécution des requêtes élevé. Pour optimiser une charge de requêtes, l administrateur peut sélectionner une ou plusieurs structures. Dans le cas, où il choisit une seule structure, sa sélection est appelée sélection isolée. Dans le cas, où il choisit plusieurs structures, leur sélection est appelée sélection multiple. La sélection isolée n est cependant pas toujours suffisante pour optimiser toute la charge de requêtes, chaque structure d optimisation étant bien adaptée pour un profil particulier de requêtes, d où le recours à la sélection multiple (Stöhr et al., 2000; Bellatreche et al., 2007). Parmi les structures d optimisation permettant d optimiser ces requêtes, ont trouvent les index de jointure binaire (structure redondante) et la fragmentation horizontale dérivée ou référentielle (structure non redondante). La fragmentation horizontale primaire des tables de dimension et la dérivée de la table des faits optimisent les sélections et les jointures, respectivement. D un autre côté, les index de jointure binaire optimisent également les jointures et les sélections. De ce fait, ces deux structures sont souvent sélectionnées de manière combinée. Cette sélection permet de respecter au mieux les deux contraintes d optimisation (espace de stockage pour les index et nombre de fragments fait générés) et de couvrir l optimisation d un maximum de requêtes. La sélection des deux techniques d optimisation s effectue à partir des attributs de sélection extraits de la charge de requêtes. Les deux structures sont donc concurrentes sur la même ressource représentant l ensemble des attributs de sélection définis sur les tables de dimension. Nous proposons ainsi, une nouvelle approche de sélection combinée d index de jointure binaires et schéma de fragmentation qui se base sur le partage des attributs de sélection pour définir les index et le schéma de FH. Ce partage est effectué par classification de l ensemble d attributs en deux ensembles. Les index seront définis sur un ensemble et le schéma de fragmentation sur l autre ensemble. Nous présentons, dans ce chapitre, le principe de cette nouvelle démarche. Nous commençons par montrer la motivation de notre choix de sélection par analyse des approches de sélection combinées existantes. Par la suite, nous détaillons la mise en œuvre de cette nouvelle démarche avec spécifications des algorithmes utilisés. III.1 Démarche de sélection combinée avec partage des attributs Nous allons considérer un entrepôt de données relationnel centralisé modélisé par un schéma en étoile. Il est interrogé par un ensemble de requêtes dites Requêtes de Jointure en Étoile (Bellatreche, 2000) qui sont caractérisées par un ensemble de prédicats de sélection définis sur des attributs appartenant aux tables de dimension (qu on appelle attributs de sélection), plusieurs opérations de jointure entre la table des faits et les tables de dimensions et aucune jointure entre les tables de dimension. Toutes les jointures incluent la table des faits. 61

70 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation Dans ce qui va suite, nous allons aborder la motivation de nos travaux, le principe de notre nouvelle démarche de sélection multiple, la formalisation du problème ainsi que les différentes étapes de déroulement du processus de sélection. III.1.1 Motivation Dans nos travaux, nous nous intéressons à la mise ne œuvre d une nouvelle démarche de sélection combinée d un schéma de FH et d IJB, cela pour les motivations suivantes : - La FH et IJB sont similaires du fait quelle permettent d optimiser les requêtes de jointures en étoiles avec sélection sur les dimensions. - Ces deux techniques sont définies sur un même ensemble d attributs de sélections. - Dans le contexte d entrepôts de données, les attributs dimensions servent à effectuer des analyses décisionnelles. Le nombre d attributs peut être du nombre de 100, 200 attributs ou plus. Par conséquent, définir un schéma d optimisation sur un tel ensemble d attribut devient une tâche difficile. - Peut de travaux se sont intéressés à la mise en œuvre de démarche de sélection combinées de FH et IJB. Parmi les travaux qui traitent ce type de sélection combinée, on cite les travaux de (Stöhr, et al., 2000). Les auteurs proposent une démarche de fragmentation hiérarchiques qui fragmentent à la fois la table de fait et les IJB définis. La démarche permet de réduire le nombre d attributs de fragmentation en choisissant un seul attribut par hiérarchie de dimension, mais risque de générer un nombre considérable de fragments faits. Si un attribut Ville de la dimension Client possède 100 valeurs différentes, alors 100 fragments de la dimension Client seront générés. Concernant les travaux (Boukhalfa, et al., 2008b), la démarche de sélection combinée effectue une sélection séquentielle de fragmentation horizontale et d index de jointures binaire. Cette sélection commence par la fragmentation en utilisant tous les attributs de sélection, ensuite l indexation en prenant en compte les attributs non utilisés par la fragmentation et les requêtes non bénéficiaires de la fragmentation. Une requête est dite bénéficiaire si elle est optimisée par la fragmentation, dans le cas contraire, elle est dite non bénéficiaire. Cette sélection engendre un nombre considérable de configurations possibles de schémas de FH car celle-ci est définie sur tous les attributs de sélection. De plus, ces travaux utilisent la FH pour choisir les attributs candidats à l indexation et pour réduire l espace de recherche du problème de sélection des index. Ce choix est souvent guidé par un modèle de coût qui ne prend pas en considération la présence des index de jointure binaire lors de l évaluation des requêtes. En conséquence, le processus de fragmentation risque d utiliser certains attributs de sélection même s ils sont plus performants pour l indexation et vice versa. Ce constat nous a motivés pour considérer un nouveau problème lié à la sélection multiple des deux structures d optimisation qui est le partage des attributs de sélection entre elles afin de maximiser la performance de l ensemble de requêtes. Nous proposons, dans nos travaux, une nouvelle démarche de sélection multiples d index et de fragmentation basée sur le partage des attributs de sélections. D un coté, nous visons à élaguer l ensemble des attributs de sélection dans le but de réduire l espace de recherche pour la FH, d un autre coté nous nous basons sur les travaux de (Boukhalfa, et al., 2008b) et (Bellatreche, et al., 2008a) qui permettent de contrôler le nombre de fragments générés. De plus, nous proposons d effectuer un partage des attributs de sélection en affectant chaque attribut à la technique la plus adéquate afin d assurer une meilleure optimisation de la charge de requête. Il faut donc étudier le bénéfice apporté par chaque structure d optimisation, définie sur un attribut donné, pour voir s il 62

71 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation est préférable d indexer ou de fragmenter sur ce dernier. Mais avant cela, nous allons citer plusieurs points qu il faut prendre en compte afin de pouvoir se prononcer sur l affectation d un attribut à une technique d optimisation : 1. Le volume de données chargé par fragmentation : suivant les travaux (Boukhalfa, et al., 2008b) et (Bellatreche, et al., 2008a), la fragmentation d un entrepôt de données reviens au partitionnement en sous domaines des domaines d attributs de fragmentation. Ainsi, un attribut muni d un sous domaine permet de caractériser un fragment (pour un attribut Ville avec le domaine {Alger, Oran, Msila, Annaba}, un partitionnement en sous domaine sera {Alger, Annaba}, {Msila, Oran}). De ce fait, la contrainte W du nombre de fragments maximum influe sur le partitionnement du domaine d un attribut, et plusieurs valeurs d attributs peuvent se retrouver dans un même domaine, contraignant ainsi le chargement d un grand volume de données pour la sélection d une seule valeur (la sélection sur Ville=Oran nécessiterait le chargement des tuples dont la ville est Msila). 2. Le volume chargé par index : pour des attributs de faibles cardinalité (attribut Genre {Féminin, Masculin}), le volume de données chargé par index, lors de l exécution d une requête, peut être tout aussi volumineux que celui chargé lors de l accès direct à l entrepôt. Dans ce cas, l optimiseur jugera cet index inutile et accédera directement aux tables. 3. Avantage de la fragmentation par rapport à l indexation : soit un attribut de forte cardinalité. La contrainte W sur le nombre de fragments détermine l efficacité du schéma de fragmentation pour cet attribut. Ceci dit, une optimisation est assurée tant que l attribut fait parti du processus de FH. D un autre coté, ce même attribut peut être complètement écarté de la sélection d index, car pour la sélection d index soit l attribut est indexé soit il ne l est pas. Cela signifie que la FH est plus tolérante que l indexation. 4. La sélection d un attribut pour l indexation : lors de la sélection d index, certains attributs peuvent être écartés de la sélection d index dans deux cas : - L index crée est volumineux, c est le cas ou la cardinalité de l attribut est grande (attribut jour - cardinalité 30 - pour un entrepôt de 25 millions de tuples donnerais au minimum un index de 90 mo sans compression) - L attribut n est pas fréquemment utiliser par la charge de requête Ceci dit, la sélection des index dépend de l espace de stockage réservé, si cet espace permet de recouvrir un grand nombre d index crées, des attributs qui présentent un ou deux des cas cités ci-dessus peuvent être choisi par l indexation. Pour résumer, afin de déterminer quelle technique d optimisation définir sur un attribut donnée, il faut prendre en compte la nature de ce dernier qui dépend de trois facteur importants : la cardinalité de l attribut, la fréquence d utilisation par la charge de requêtes et le volume de données chargé, lors de l exécution d une requête, en employant la technique définie sur l attribut. Dans ce qui suit, en considérant un attribut donné, nous allons étudier deux cas de figures : le cas ou la fragmentation sur l attribut est plus appropriée et le cas où l IJB donnerait un meilleur résultat que la fragmentation sur ce même attribut III FH est meilleure Etant donné un attribut, la fragmentation sur cet attribut peut être plus bénéfique que l indexation dans les cas suivants : - La cardinalité de l attribut est grande, un index sur un tel attribut peut être écarté lors du processus de sélection d index. 63

72 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation - L attribut est fréquemment utilisé par les requêtes, dans ce cas il vaut mieux fragmenter sur cet attribut afin d assurer l optimisation du coût d exécution de la charge de requêtes. - le coût d exécution d une requête avec index sur l attribut est tout aussi grand que le coût avec accès direct aux tables. Dans ce cas, l index est non employé par l optimiseur. Afin de mieux expliquer le troisième point que nous venons de citer, nous allons introduire l exemple suivant : Exemple 21 : Soit un ED dont la population est représenté par la figure III-1. Supposant deux scénarii d optimisation : un scénario avec un schéma de FH sur l attribut Genre, un autre scénario avec IJB sur Genre (figure III-2). Concernant la FH, la répartition en sous domaine de l attribut Genre est {F}, {M}, ceci donne deux fragments de la dimension Client. Chaque fragment fait est calculé comme suit : Vente i =Vente x Client j, où Client j, est un fragment de Client (1<= i<= 2). La figure III-2 illustre l IJB sur Genre et le sous schéma en étoile de l ED fragmenté pour Genre = F. Soit la requête qui affiche la quantité, par client, des produits vendus à des clients féminins. SELECT C.IdC, Sum(Prix) FROM Vente V, Client C WHERE V.IdC=C.IdC AND C.Genre = F GROUP BY C.Id C Vente Client RID IdC IdP IdT Prix RID IdC Age Genre Ville F Annaba M Alger F Oran M Msila F Annaba M Oran F Alger Produit RID IdP Classe A B C C A Temps RID IdT Mois Année Janvier Février Mars Janvier Février Mars Figure III-1 Population de l entrepôt de données 64

73 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation Vente IJBGenre RID IdC IdP IdT Prix F M Vente RID IdC IdP IdT Prix Client RID IdC Age Genre Ville F Annaba F Oran F Annaba F Alger Figure III-2 Schéma de fragmentation Genre=F / IJB sur l attribut Genre Pour l entrepôt optimisé par fragmentation ou par IJB, l exécution de la requête nécessite le chargement de 57% de la table de fait. Vu la taille importante des entrepôts de données (dizaine ou centaine millions de tuple pour la table de fait), l IJB peut être jugé inutile est non sélectionné par l optimiseur pour l exécution de la requête. Par contre, une réduction du volume de données chargé est obtenue par fragmentation car seul le fragment Vente1 est chargé. Ce dernier est obtenu par semi jointure comme suit : Vente1=Vente x Client1, ou Client1 (ventes de clients féminins). Ainsi, il est préférable de fragmenter sur l attribut Genre. III IJB est meilleur Un IJB défini sur un attribut donné peut s avérer plus utile que de définir un schéma de FH, c est dans le cas où la cardinalité de l attribut n est pas très faible (index généré est écarté par l optimiseur) ou pas très forte (l attribut risque d être écarté par processus de sélection d index), et que le seuil W donne un schéma de fragmentation où les domaines des attributs sont fusionnés. Exemple 22 : Soit un ED dont la population est représenté par la figure III-1. Soient les attributs de sélection Genre, Ville, Classe, Mois et Année. Le nombre de fragments possibles est de 96. Supposant W= 30 et un schéma de FH avec les répartitions en sous domaines suivants : Genre : {F}, {M} ; Ville : {Alger, Annaba}, {Oran, Msila} ; Classe {A}, {B, C} ; Mois :{Janvier}, {Février}, {Mars}, ceci donne 24 fragments fait et donc 24 sous schémas en étoile. Chaque fragment fait est calculé comme suit : Vente i =Vente x Client j x Produit k x Temps p, où Client j, Produit k et Temps p sont respectivement un fragment de Client (1<= i <=4), Produit (1<= j <=2) et Temps (1<= k <=3). Nous présentons sur la figure III-3 les données chargées (faits et dimensions) pour l exécution de la requête dans le cas d ED fragmenté sur Ville. Sur la figure III- 4, nous présentons l IJB définit sur l attribut Ville et les données chargées par emploi de l IJB lors de l exécution de la requête. 65

74 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation Ventes chargées par fragmentation Client1 RID IdC IdP IdT Prix RID IdC Age Genre Ville F Annaba M Alger F Annaba F Alger Figure III-3 Données chargées pour l exécution de la requête : cas FH sur Ville Vente IJB_Ville RID IdC IdP IdT Prix Alger Annaba Oran Msila Ventes chargées par IJB_Ville RID IdC IdP IdT Prix Figure III-4 Données chargées pour l exécution de la requête : cas IJB sur Ville Soit la requêtes qui affiche le prix, par client, les ventes des clients d Alger : SELECT C.IdC, Sum(Prix) FROM Vente V, Client C WHERE V.IdC=C.IdC AND C.ville= 'Alger' GROUP BY C.IdC Considérons l entrepôt fragmenté. L exécution de la requête nécessite le chargement de 12 sous schémas en étoile, chaque sous schéma concerne les vente des clients vivant à Alger ou à Annaba (les deux valeurs sont dans le même sous-domaine de Ville). Ainsi, le volume total de données 66

75 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation chargées représente 61% de la table de fait (figure III-3). De plus, l exécution de la requête nécessite des opérations de Jointure entre fragments Client j et Vente i, une sélection sur Ville=Alger sur chaque sous schéma en étoile, une union des résultats obtenus par les 12 sous schéma puis le calcul du résultat du GROUP BY. A présent, considérons l entrepôt optimisé par IJB définit sur l attribut Ville (figure III-4). L exécution de la requête ne requière ni chargement des fragments des la table Client ni jointure avec les fragments fait. De plus seuls 7 tuples seront chargé soit 27% de la table de fait. Ainsi, il est plus intéressant de définir un IJB sur Ville. Pour résumer, dans les travaux de (Boukhalfa, et al., 2008b) et (Bellatreche, et al., 2008a), la FH est sélectionnée sur tous les attributs de sélections. Ceux qui restent permettent de définir les IJB. Par contre, ces index peuvent s avérer inutiles. En effet, si le volume de donnée chargé par index est volumineux, l optimiseur du SGBD jugera préférable d utiliser la table directement. Si la cardinalité de l attribut est forte, l attribut peut être écarté du processus de sélection d IJB. D autre part, des attributs peuvent être choisis pour la FH alors que leur sélection pour un IJB donnerait un meilleur résultat. Ainsi, nous proposons de répartir les attributs entre IJB et FH, avant de sélectionner les structures. III.1.2 Problème de partage des attributs entre FH et IJB Rappelons que la sélection des schémas de fragmentation et d IJB s effectue à l aide des attributs de sélection extraits de la charge de requêtes. Souvent la fragmentation horizontale et les IJB sont concurrentes sur un sous ensemble important d attributs de sélection. Partager cet ensemble entre la fragmentation et les IJB doit satisfaire le problème global de la sélection multiple des deux structures qui est formalisé comme suit : - une charge de requête - les attributs de sélection extraits à partir de Q. - S espace de stockage des index. - W le nombre de fragment maximum. Le problème de la sélection multiple (PSM) consiste à répartir les attributs de sélection entre FH et IJB tel que : (1) La sélection des deux techniques, définies chacune sur son ensemble d attributs, permet de réduire le coût d exécution des requêtes. (2) L espace réservée aux index ne dépasse pas S. (3) Le nombre de fragments ne dépasse pas W. La résolution de ce problème nécessite une exploitation de l espace de recherche englobant les deux sous espaces correspondants aux fragmentations et indexation. Soient Ins F et Ins I le nombre d instances du problème de la fragmentation et d indexation respectivement. L espace de recherche global est 2 InsF+InsI, du fait que les différentes instances peuvent interagir (Zilio, et al., 2004). Vue cette complexité, le PSM doit se résoudre d une manière séquentielle en prenant en compte les similarités entre les deux structures. En conséquence, une démarche de résolution du PSM consiste d abord à partager les attributs entre les deux structures, ensuite à lancer les algorithmes de sélection avec leurs attributs respectifs. Un partage a priori des attributs de sélection entre les structures réduit la complexité des deux problèmes (problème de la sélection de schéma de fragmentation et problème de sélection de schémas d indexation). Le nombre de classifications possibles de l ensemble A en deux classes distinctes est donné par la formule : 2 67

76 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation Tel que : une classe peut être vide, et au maximum comporter n attributs. En effet, classifier un ensemble en deux classes distinctes revient à sommer les combinaisons C C C, cette formule n est autre que le développement de Pascale du terme (1+1) n = 2 n Énumérer tous les cas possibles de classification et pour chaque cas exécuter deux algorithmes de sélection reste impossible vue la complexité identifiée par l équation précédente. En conséquence, nous développons une approche de partage moins coûteuse prenant en considération les caractéristiques de chaque problème et chaque structure d optimisation. III.1.3 Critère de partage Nous avons vu qu afin de déterminer quelle technique d optimisation définir sur un attribut donnée, il faut prendre en compte trois facteur importants : la cardinalité de l attribut, la fréquence d utilisation par la charge de requêtes et le volume de données chargé, lors de l exécution d une requête, en employant la technique définie sur l attribut. Ces trois facteurs représentent les critères de décisions pour le partage d attributs : - Fréquence d utilisation d un attribut Frc: ce critère représente le nombre de fois qu un attribut de sélection est utilisé par les requêtes. Si la fragmentation est utilisée sur un ensemble d attributs fréquents elle donne de meilleures performances que les index. Dans certains cas, les index sont meilleurs, mais puisque un IJB défini sur un attribut donné peut s avérer inutile on privilège la fragmentation vue sa caractéristique de non redondance. - Facteur de sélectivité des prédicats définis sur les attributs de sélection FS : Soit un attribut A utilisé par k (k 0) prédicats de sélection {P 1,..., P k }. Les expérimentations ont montré qu un IJB sur A est bénéfique pour les requêtes si les facteurs de sélectivité de ses prédicats sont faibles. Nous définissons un facteur de sélectivité d un attribut A (FS(A)) par la moyenne des facteurs de sélectivité de ses prédicats. - Cardinalité de l attribut Card: Plus la cardinalité d un attribut est grande, plus la taille de chaque fragment est réduite. En conséquence, une requête donnée peut charger qu une petite partie de la table des faits. Mais ce cas n est pas toujours vrai car la fragmentation est contraint par le seuil de fragments faits générés. Dans ce cas, certains domaines doivent être fusionnés ce qui a été démontré dans (Bellatreche, et al., 2009). D un autre coté, les index définit sur des attributs à forte cardinalité sont volumineux et peuvent ne pas être sélectionné par le processus de sélection des index (contrainte de l espace de stockage). Ainsi, les attributs de forte cardinalité sont adaptés à la fragmentation tandis que les attributs de faible cardinalité sont candidats à l indexation. Pour résumer, nous favorisons, pour la fragmentation, les attributs dont la fréquence d utilisation, le facteur de sélectivité et la cardinalité sont grands. III.1.4 Déroulement du processus de sélection Afin d effectuer la répartition des attributs entre index et fragmentation, nous proposons d effectuer une classification des attributs en deux classes : Classe_IJB et Classe_FH. Cette classification est réalisée à l aide d une technique de Datamining à savoir l algorithme de classification «k-means». Après classification, les structures d optimisation doivent être sélectionnées, chacune sur sa classe d attributs. Pour cela, nous avons mis en œuvre deux modules de sélection, un pour la sélection d IJB et l autre pour la sélection d un schéma de fragmentation. 68

77 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation - Espace de stockage S - Nombre de fragments maximum W - Nombre d itérations pour la classification Entrepôt de donnée Charge de requêtes Attributs de sélection Nombre d itérations Classification par «k-means» Classe Attributs Classe Attributs Sélection d un schéma de Attributs exclus par FH Sélection d IJB Modèle de coût Figure III-5 : Notre approche de sélection d IJB et FH avec classification Dans notre démarche de sélection, nous considérons un entrepôt de données en étoile et une charge de requêtes décisionnelles exécutée dessus. Cette démarche permet d analyser la charge de requêtes afin d y extraire les attributs de sélection à classifier pour sélectionner et implémenter les structures d optimisation : index de jointure binaires et fragmentation horizontale. Notre démarche suit les étapes suivantes (figure III-5) : - Analyse syntaxique des requêtes et extraction des attributs de sélection : La charge de requêtes représente l ensemble des requêtes décisionnelles exécutées sur l entrepôt de données. Elles ont la forme suivante : SELECT A1, F(A2) FROM, Di, F WHERE PJ, PS GROUP BY [AG] Implémentation des structures résultantes sur Tel que : A1 : attributs de réponse de la requête. F(A2), F : Fonction d agrégation (Max, Min, Sum, Count, Avg), A2 : attribut l agrégation. PJ, PS : prédicats de jointure et de sélection resp. AG : Attributs de groupement. L analyse syntaxique de la charge de requête que nous avons mis en œuvre, permet de représenter chaque requête sous forme d une modélisation à base de quatre objets : SELECT, FROM, WHERE et GROUP BY. Ces objets vont permettre d identifier : Les 69

78 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation tables et leurs alias présents dans FROM, les prédicats de sélections présents dans WHERE et critères de classification des attributs (cf. section III.1.3). Puisque la fragmentation et les index de jointure binaires optimisent les jointures en étoiles avec opération de sélection sur les dimensions, seuls les attributs des tables dimensions, présents dans les prédicats de sélection du WHERE, vont participer au processus de sélection des structures d optimisation. Ces attributs sont extraits à partir des prédicats puis sont soumis à la classification par «k-means». Algorithme d analyse et extraction d attributs des requêtes (Algorithme 1) Entrée : Q : tableau de requêtes Sortie : A : ensemble d attributs de sélection P : ensemble de prédicats de sélection T : ensemble contenant les dimensions et la table de fait Début A = P= T = T {Table_Fact(Q 1 )} Pour toute requête Q i dans Q Faire Pinter = {Extraire_Prédicats(Q i )} /* récupéré les prédicats de la requête PQ = (P Pinter)-P /* prédicats figurants dans Pinter et ne figurant pas dans P P = P Pinter Pour tout P i dans PQ Faire Si P i est un prédicat de jointure Alors T = T {Table_Dimension(P i )} Sinon A = A {Attribut(P i )} FSI FP FP Fin - Classification des attributs de sélection : Nous avons effectué la classification des attributs par l algorithme «k-means». Il permet de partager un ensemble en k classes. L adaptation de l algorithme «k-means» à notre approche fixe k à 2 classes. Nous obtenons ainsi une classe d attributs d indexation et une autre pour la FH. - Sélection d un schéma de fragmentation : Nous avons mis en œuvre un module de sélection d un schéma de fragmentation à base d algorithme génétique. Cette mise en œuvre s inspire des travaux de (Bellatreche, et al., 2006), (Boukhalfa, et al., 2008a) et (Bellatreche, et al., 2009). Notre module de sélection prend en entrée les attributs de la Classe_FH et effectue la sélection d un schéma de FH par algorithme génétique guidé par un modèle de coût et une contrainte du nombre de fragments maximum W - Sélection des index de jointure binaire : Tout comme pour la fragmentation, nous avons réalisé un module de sélection d index de jointures binaires en se basant sur les travaux de (Bellatreche, et al., 2008b). Ce module prend les attributs de la Classe_IJB et sans violé l espace de stockage réservé au index, il sélectionne les IJB les plus bénéfiques par algorithme génétique guidé par modèle de coût. 70

79 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation - Implémenter les structures sélectionnées sur l entrepôt de données : Une fois la configuration des structures d optimisation finale obtenue, l optimisation physique de l entrepôt de données est effectuée. Suivant le schéma de fragmentation optimal obtenu, la FH primaire est réalisée sur les dimensions suivie de la FH dérivée de la table de faits. Après fragmentation, les index de jointure binaires sont implémentés de manière local sur les fragments faits générés. Nous exposons dans les sections suivantes une description de l approche proposée, nous commençons par présenter le principe de classification des attributs, puis nous détaillons le modèle de coût et les algorithmes de sélection. Nous terminons par la description des modules de sélection du schéma de fragmentation et de sélection d index de jointure binaires. III.2 Classification des attributs de sélection Nous avons vu que la classification des attributs de sélection est un problème dont la complexité est donnée par la formule suivante : 2. Ainsi, nous adoptons une approche de classification basée sur un algorithme de Datamining k-means. Afin de présenter cette approche de classification, nous présentons le concept de classification en général avec ces différents types. Par la suite, nous exposons le principe de l algorithme de classification que nous avons choisis à savoir k-means. Pour finir, nous détaillons notre approche de classification des attributs par algorithme k-means. III.2.1 Principe générale de classification La classification de données est une approche de Datamining qui vise à extraire des connaissances à partir d un ensemble de données. Elle peut être supervisée ou non supervisée (Jain, et al., 1999). La classification supervisée effectue un apprentissage à partir d exemples de données (Robardet, 2005). Elle se base sur des hypothèses concernant la structuration des données. On peut citer dans ce sens la régression linéaire qui suppose que la répartition d un échantillon de données est linéaire. Cette dernière vise à modéliser l échantillon de données par une fonction linéaire (une droite), dans le but de pouvoir générer d autres données similaires à l échantillon. La classification qui nous intéresse est la classification non supervisée ou data clustering qui ne fait aucune hypothèse sur les données (Robardet, 2005). Elle représente la répartition de données en plusieurs classes non connues au départ. Chaque classe regroupe les données similaires (segmentation d une image en zones de couleur uniforme). Deux types de classification non supervisée existent (Jain, et al., 1999): la classification par partitionnement et la classification hiérarchique. 1. La classification hiérarchique répartie les données en plusieurs classes. Ces classes s emboites les unes dans les autres sur plusieurs niveaux jusqu'à obtenir une seule grande classe qui contient toutes les données. Ces classes forment ainsi un arbre binaire (figure III- 6). Chaque niveau dans l arbre contient un certains nombre de classes (Jain, et al., 1999). 71

80 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation Deux classes Trois classes Cinq classes Les données : Figure III-6 : Représentation graphique de la classification hiérarchique 2. La classification par partitionnement (c est la classification qui nous intéresse le plus) vise à classifier un ensemble de données, représenté dans l espace multidimensionnel R n, en plusieurs classes où chaque classe regroupe les données les plus proches entre elles. Ces classes peuvent ou pas se chevaucher entre elles, c'est-à-dire qu une donnée peut appartenir à plusieurs classes différentes (Jain, et al., 1999). Parmi les techniques de classification supervisée les plus utilisées, on cité l algorithme k- means présenté dans (Hartigan, et al., 1979). Il partitionne un ensemble de données en k classes non chevauchées. Nous allons détailler cet algorithme dans le paragraphe qui suit. III.2.2 Classification des attributs par «k-means» Dans les sections qui suivent, nous présentons le principe général de l algorithme k-means. Nous détaillons les étapes de cet algorithme pour finir par présenter l adaptation de cet algorithme à notre problème de classification des attributs de sélection. III Principe de l algorithme Le principe de cet algorithme est de partitionner m données d 1,, d m en k classes C 1,, C k en positionnant dans l espace des données, R n, k centroïdes ct 1,, ct k. Ces centroïdes sont généralement choisis de manière aléatoire parmi les données elles même. Chaque donnée est alors affectée à une classe dont le centroïde est le plus proche de cette donnée. La notion de données proches peut être exprimée par la distance euclidienne entre les données représentées dans l espace R n et chaque centroïde. La distance euclidienne entre une donnée d dont les coordonnées dans R n sont (d 1,, d n ) et un centroïde ct avec les coordonnées (ct 1,, ct n ) est donnée par la formule suivante : Neuf classes Afin de vérifier la stabilité des classes, k-means effectue la réaffectation des données à chaque classe sur plusieurs itérations. A chaque itération, k nouveaux centroïdes sont déterminés et les distances entre les données et ces centroïdes sont calculées afin de réaffecter les données à la classe la plus approprié. k-means vise ainsi à réduire les distances intra classes (distances entre les données de chaque classe). Chaque nouveau centroïde ct i est calculé à partir des données d 1,, d t déjà affectées à la classe C i. Chaque donnée d p possède les coordonnées suivantes (d 1 p,, d n p ) (figure III-7). La formule qui calcul chaque coordonnée j du nouveau ct i (ct j i ) est données par la formule suivante : 72

81 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation d 1 d 2 ct d 3 Figure III-7 : Centroïde d une classe de trois données Etant donné un ensemble de données et leurs coordonnées sur R n, un nombre d itération nb, le déroulement de l algorithme k-means est donné comme suit : 1. Choisir, parmi les données à classifier, k centroïdes de manière aléatoire 2. Pour chaque donnée - Calculer la distance euclidienne entre cette donnée et les k centroïdes - Affecter la donné à la classe dont le centroïde est le plus proche 3. Recalculer les centroïdes en choisissant le centre de chaque classe 4. Refaire les étapes 1, 2 et 3 selon le nombre d itérations nb III Adaptation de la classification à notre problème de sélection Notre choix s est porté sur «k-means» car cet algorithme est simple à utilisé et répond bien à nos besoin de classification. En effet, nous visons à effectuer une classification non supervisée des attributs en 2 classes qui ne doivent pas se chevaucher entre elles. De plus, ils existent des travaux qui on implémenté cet algorithme pour l optimisation des entrepôts de données à savoir (Mahboubi, 2009). L auteur emploi «k-means» pour le partitionnement de l ensemble des prédicats de sélection (définis sur les attributs de sélection) en sous ensembles formant ainsi des fragments horizontaux. Ces travaux ont permis de montrer la force et la simplicité d une telle démarche avec «k-means». Pour la mise en œuvre de la classification, nous utilisons une API JAVA nommé SimpleKMeans qui permet d implémente l algorithme «k-means» (Holmes, et al., 1994). Cette API utilise, pour le calcul de la distance intra classe, la distance euclidienne. Selon le nombre d itération, «k-means» recalcule de nouveau les deux centroïdes puis réaffecte chaque attribut à la classe qu il faut selon la distance euclidienne. Afin adapter cet algorithme à notre besoin de classification des attributs de sélection, nous considérons ce qui suit : - Les données à classifier sont les attributs de sélection - Les attributs sont classifiés en deux ensembles : Classe_IJB et Classe_FH. Ainsi, k = 2 - Les attributs sont représentés dans l espace à deux dimensions R 2 par des coordonnées (x, y) Les coordonnées des attributs dans R 2 sont établies à partir d un poids de classification qui va nous permettre de décider, pour chaque attribut, s il est candidat à la FH ou à l indexation. Le calcul d un point d un attribut A i est basé sur trois facteurs cités ci-dessous. Où Frc i, FS i, Card i représentent respectivement la fréquence de l attribut, le facteur de sélectivité et la cardinalité de l attribut i. ces facteur sont calculé durant 73

82 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation Nous avons remarqué que les données de chaque facteur présentaient une échelle différente. Pour le facteur Card les données représentent les cardinalités des attributs qui peuvent être 12 pour un attribut Mois, 30 pour un attribut Jour ou 60 pour un attribut Ville. Par contre, les données sur facteur FS sont comprises entre 0 et 1. La somme directe entre ces deux facteurs ferait que le facteur Card soit plus dominant que le facteur FS. Pour que le poids soit cohérent, nous avons effectué la normalisation des données issues de chaque facteur. La normalisation vise à centrer et réduire un échantillon de données suivant la moyenne et l écart type de celui-ci (Raffestin, 2002), cet échantillon suivra alors une loi normale centrée réduire de moyenne 1 et écart type 0. Soit un échantillon de données d 1,, d n. A partir de la moyenne type, chaque donnée est centrée réduire comme suit : III.2.3 Exemple de classification et l écart Soit un entrepôt de données et une charge de requêtes à optimiser. A partir de ces requêtes, les facteurs Frc, FS, Card et le poids sont calculés. L ensemble d attributs de sélection est : {Mois, Année, Ville, Pays, Classe}. Le tableau III-1 résume le calcul du poids pour chaque attribut. Plus le poids est grand, plus l attribut est candidat à la fragmentation. Attribut Frc FS Card Frc Normalisé FS Normalisé Card Normalisé Poids Année 11 0,2 23 1,14 0,53 0,01 1,70 Mois 5 0, ,26 1,41-0,30 1,37 Ville 6 0,1 55 0,41-0,13 0,94 1,22 Pays 9 0, ,85-0,20-0,07 0,57 Classe 3 0, ,02-0,67 1,14 0,44 Tableau III-1 : Calcul du poids des attributs dimension Une fois le poids calculé on munit les attributs de leurs coordonnées dans (numéro de l attribut i, poids de l attribut i ). Ces coordonnés sont résumés dans le tableau III-2 Attribut Année Mois Ville Pays Classe Coordonnées [1, 1.70] [2, 1.37] [3, 1.22] [4, 0.57] [5, 0.44] Tableau III-2 : Coordonnées des attributs dimension La représentation graphique de ces attributs est illustrée dans la figure III-8 : Figure III-8 : Répartition des attributs en fonction de leurs poids 74

83 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation La figure III-8 montre une répartition des attributs en deux ensembles délimités par les cercles rouges. Les attributs «Année», «Mois» et «Ville» vont constituer la Classe_FH pour la fragmentation. Les attributs «Pays» et «Classe» vont constituer la Classe_IJB. Le déroulement de l algorithme de classification des attributs est présenté comme suit Algorithme de classification des attributs de sélection (Algorithme 2) Entrée : : Tableau d attributs de sélection Sortie : : tableau du nombre de requête : tableau des facteurs de sélectivité : tableau des cardinalité _, _ : classe d attribut pour les index et fragmentation resp. Notation : : tableau des poids des attributs : tableau à deux dimensions Début _ _,, /* Normaliser les données afin de pouvoir les sommer */ Pour tout attribut A i Faire // Calcul du poids de classification, FP KMEAN (, _, _ /*Application de «k-means» sur «Coord», le résultat est «Classe_IJB» et «Classe_FH» */ Fin III.3 Modèle de coût Une fois le partage des attributs effectué, il faut effectuer la sélection des structures sur chaque classe. La sélection est effectuée par heuristique à savoir l algorithme génétique. Cet algorithme est guidé par un modèle de coût qui permet d évaluer chaque configuration de structure généré par génétique. Cela permet de choisir la configuration qui optimisent le mieux la charge de requête. Dans leurs travaux, (Boukhalfa, et al., 2006), (Boukhalfa, et al., 2008b) et (Bellatreche, et al., 2008b) montrent l intérêt de sélectionner un schéma de fragmentation et les index de jointure binaires en se basant sur un modèle de coût mathématique. En prenant l exemple de la fragmentation, les approches qui se basent sur la complétude et minimalité des prédicats ou ceux qui utilisent les affinités ne donnent aucun mécanisme permettant d estimer la qualité du schéma de fragmentation obtenu. Pour les algorithmes à base d affinités par exemple, le paramètre essentiel est la fréquence d accès des requêtes aux données. Ce paramètre n est pas suffisant car certaines requêtes non fréquentes peuvent engendrer un coût d exécution important. Il faut utiliser d autres paramètres comme la taille des tables, la taille des tuples, les facteurs de sélectivité des prédicats de sélection et la taille d une page système. De plus, le problème de sélection d index et le problème de sélection d un schéma de fragmentation 75

84 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation sont des problèmes NP-Complet. Ils nécessitent l utilisation d heuristiques qui se basent sur une fonction objectif. Cette fonction est spécifiée à partir du modèle de coût. Le modèle de coût permet d estimer le coût d exécution des requêtes. Il est composé de deux grandeurs : (1) le nombre d opération d entrée sortie (E/S) nécessaire pour charger les données exploité par une requête. (2) le coût de calcul CPU. Généralement, le coût CPU est négligeable devant le coût d E/S. Ainsi, seul ce dernier est pris en compte pour estimer le coût d exécution. Dans notre travail, nous allons effectuer la sélection d IJB ou de schéma FH à base d algorithme génétique. Il faut donc établir un modèle de coût mathématique qui va permette de spécifier la fonction objectif du génétique et guider la sélection des structures d optimisation. Afin d établir ce modèle de coût, nous présentons la formulation du coût d exécution des jointures ainsi que le coût d exécution d une requête sur un schéma non optimisé. a) Cout d exécution des jointures Dans le modèle que nous présentons, les jointures sont implémentées grâce à l algorithme de jointure par hachage. C est l algorithme le plus utilisé pour calculer les opérations de jointures dans les SGBD commerciaux. De plus la jointure par hachage est simple et donne de bonnes performances dans le cas où les tables sont volumineuses. Le coût d une seule jointure par hachage de deux tables R et S est 3 où représente le nombre de pages nécessaires pour stocker la table T. Pour n jointures, (Bellatreche, et al., 2008b) montrent que cette formule n est pas toujours vraie. Elle dépend de la taille des résultats intermédiaires (taille du résultat des jointures déjà calculées). Pour le calcul de chaque jointure, il faut estimer le volume de données à charger en plus du chargement de la table à joindre. En effet, si les résultats intermédiaires ne tiennent pas en mémoire centrale, il faut les écrire sur disque, puis les charger pour calculer la jointure suivante. Dans nos travaux, nous présentons un modèle de coût simplifié qui suppose que les résultats intermédiaires de jointures tiennent en mémoire centrale. Ainsi, le coût de jointures entre n tables T 1,, T n est 3 b) Formule de coût sur un entrepôt non optimisé Soit un entrepôt de données modélisé en étoile avec une table de fait F et d tables de dimensions D 1,...D d. Soit une charge de requête Q 1, Q n. le coût d exécution d une requête sur un entrepôt de données représente le coût de chargement des tables pour effectuer les jointures par hachage, il est donné par la formule suivante (on suppose que les jointures intermédiaire ne nécessite pas une écriture sur disque):, 3 Nous allons présenter, dans les sections qui suivent, la formulation du modèle de coût pour la fragmentation horizontale est les index de jointures binaires. III.3.1 Modèle de coût pour la fragmentation Le modèle de coût, que nous allons utiliser pour évaluer un schéma d entrepôt en étoile et fragmenté, s inspire du modèle avancé dans (Boukhalfa, et al., 2006). Ce modèle permet de calculer le nombre d E/S nécessaires pour exécuter une charge de requêtes sur un schéma fragmenté par fragmentation horizontale. Plus exactement une fragmentation horizontale primaire sur les dimensions et une dérivée sur la table de fait. Chaque requête comporte des prédicats de sélection et des jointures en étoile entre fait et dimension. 76

85 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation Paramètre F D i R R P Sel(P) PS L Signification la table des faits i ème table de dimension nombre de pages nécessaires pour stocker la table R nombre de tuples de la table R prédicat de sélection facteur de sélectivité d un prédicat taille de la page système taille d un tuple de la table R Tableau III-3 : Paramètres du modèle de coût pour la fragmentation Les paramètres utilisés dans ce modèle de coût sont classés en trois catégories (tableau III-3): - Les paramètres sur l entrepôt de données comme la taille des tables, la taille d un tuple, la taille des tables en pages systèmes nécessaires pour leur stockage. - Les paramètres sur le système physique à savoir la taille de la page système. - Les paramètres sur la charge de requêtes comme la sélectivité des prédicats. Nous considérons un entrepôt de données modélisé en étoile avec une table de fait F et d table de dimensions D 1,...D d. La fragmentation de l entrepôt donne N sous schéma en étoiles S 1, S N. Soit une requête Q à exécuter sur l entrepôt. Le modèle de coût présenté calcule le nombre de pages qu il faut charger pour l exécution de la requête Q sur le schéma fragmenté. Dans un sous schéma en étoile S i, Un fragment fait est spécifié par un ensemble de M i prédicats de sélection PF j. Un fragment dimension est également spécifié par L i prédicats de sélection PM k. On définit le coût de chargement d un fragment fait et un fragment dimension par les formules suivantes : - Pour un fragment fait : - Pour un fragment dimension : Où Sel(P) est le facteur de sélectivité du prédicat de sélection P. On suppose que les facteurs de sélectivité sont définis à travers une répartition uniforme (RU). Il est à noter que le nombre de page nécessaire à charger une table R est calculé par la formule suivante : Afin d estimer le coût d exécution d une requête sur un schéma fragmenté, il faut identifier les sous schéma valides pour la requête. Un sous schéma valide est un sous schéma où le fragment fait est accédé par la requête sur au moins un tuple. Ainsi, on définit une fonction booléenne dont la signature est la suivante :, 1 0 Le coût d exécution d une requête sur un sous schéma S i estime le coût de chargement du fragment fait puis la jointure entre ce fragment et les fragments dimensions.,, 3 Le coût total d exécution de la requête sur tout l entrepôt fragmenté est,, 77

86 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation III.3.2 Modèles de coût pour les index Afin de mettre en œuvre un modèle de coût pour la sélection d index de jointure binaire, nous nous somme basés sur les travaux de (Aouiche, et al., 2005). Les auteurs proposent un modèle de coût qui permet de ne conserver que les index les plus avantageux pour l exécution d une charge de requête. Ce modèle estime l'espace de stockage d un index de jointure binaire en octets, le coût d'accès aux données à travers cet index et le coût de maintenance des index. De plus, les auteurs présentent deux variantes du modèle : un modèle de coût qui ne prend pas en considération l implémentation physique des index et un modèle qui considère des IJB accédés par B-Arbre. Dans notre approche, nous allons considérer le modèle de coût avec index accédé par B-arbre et dont les coûts calculés sont le coût de stockage et le coût d accès aux données. Un IJB accédé par B-arbre va être constitué d un index B-arbre sur l attribut indexé. Chaque feuille du B-arbre va contenir un pointeur vers la page qui contient un bitmap. Chaque bitmap est défini sur une valeur donnée de l attribut indexé. Le tableau III-4 résume les notations du modèle présenté. Paramètre F R R A A PS S pointeur W(X) d m Signification la table des faits nombre de pages nécessaires pour stocker la table R nombre de tuples de la table R attribut d indexation cardinalité de l attribut A taille en octet de la page système taille en octet d un pointeur d une page taille en octet d un tuple de la table T ou de l attribut X Nombre de bitmap utilisé pour une requête Ordre d un B-arbre Tableau III-4 : Paramètres du modèle de coût pour les index Nous allons présenter la formule qui permet d estimer l espace réservé pour le stockage des index puis introduire le modèle de coût. III Stockage d un IJB Soit un index de jointure binaire défini sur une table de fait F avec l attribut dimension A. L IJB contient des bitmaps dont le nombre de lignes est égale au nombre de tuples de la table de faits. Cet index contient autant de bitmap que la cardinalité de l attribut A. De plus, chaque ligne de l index est munie de la clé qui référence un tuple de fait (RowId). Ainsi, la taille d un index de jointure binaire est donnée par :. Dans les SGBD, la taille du RowId est généralement de 16 octets. Ainsi, la taille d un index devient : III Coût d accès aux données par IJB 16 L accès à l index de jointure binaire est fait par index B-arbre. Les nœuds feuilles du B-arbre pointe sur les bitmap de l IJB. Ainsi, le coût d accès aux données par IJB, en terme de nombre de pages, est composé de trois coûts : C = C descente +C parcours +C lecture. C descente correspond au coût de descente du B-arbre de la racine aux nœuds feuilles, C parcours indique le coût de parcours des nœuds feuilles dans le but d identifier les clé des bitmaps et le coût de lecture de ces bitmaps et C lecture donne le coût de lecture des tuples de la table de fait. Afin de calculer le coût de descente dans le B-arbre, il faut connaitre sa hauteur. La hauteur d'un B-arbre construit sur un attribut A est log, où m représente l ordre du B-arbre est A la 78

87 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation cardinalité de l attribut A. l ordre m est égale à K+1, K étant le nombre de clés de recherche dans le B-arbre. Désignant par w(a) la taille en octet de l attribut A et S pointeur la taille du pointeur d une page et donc le pointeur de l emplacement d un bitmap. Le nombre K est égale à Sans considérer les feuilles du B-arbre, le coût de descente du B-arbre est log 1 Pour le coût de parcours, on considère le pire cas où tous les nœuds feuilles sont lus. Cela donne. Concernant la lecture des bitmaps, dans le but d identifier les bits mis à 1, il faut parcourir chaque bitmap. Le coût de lecture de d bitmaps est. Le coût total de parcours est : m 1 F 8PS Pour des données d entrepôt uniformément distribués, le nombre de tuples de la table de fait lu par un bitmap est. En général, le nombre de tuples fait accédés par d bitmap est. Le nombre d entrées/sorties nécessaires pour lire N r tuples fait est : F 1 e Pour résumé, le coût d exécution d une requête qui accède aux données par IJB noté I est, log 1 m 1 F F 1 e 8PS III.4 Fonction objectif pour l algorithme génétique Afin de sélectionner les structures d optimisation (index de jointure binaires et schéma de fragmentation) nous avons utilisé un algorithme génétique qui exploite une fonction objectif. Cette fonction évalue, pour chaque itération de l algorithme génétique, le taux d optimisation du coût d exécution, en termes d E/S, d un ensemble de requête sur un schéma d entrepôt avec présence de la structure d optimisation (index ou fragmentation). Cette évaluation est effectuée en comparant ce coût par rapport au coût d exécution des requêtes sur un entrepôt non optimisé. Ainsi, le but de l algorithme génétique est de trouver la solution (configuration d IJB ou schéma de fragmentation) qui minimise la fonction objectif. Nous présentons, dans ce qui suit, la formulation générale d une fonction objectif ainsi que les différents types de fonctions. Nous exposons ensuite la fonction objectif pour la sélection d un schéma de fragmentation et celle utilisée pour sélection des index. III.4.1 Formulation d une fonction objectif Soit F(x) comme une fonction objectif utilisée dans une heuristique. On s intéresse généralement à Maximiser F(x) sous la contrainte C(x). C est un problème d optimisation d une fonction F sous une contrainte C. Soit Pen(x) une fonction pénalité qui pénalise une solution x qui viole une contrainte. L utilisation de la fonction de pénalité pour la fonction F(x) permet de transformer le problème en un problème d optimisation sans contraintes d une fonction F (x) définie à partir des fonctions F(x) et Pen(x). Cela peut être effectué en utilisant trois modes, soustraction, division et division-soustraction (Boukhalfa, et al., 2008a). - Mode soustraction 0 79

88 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation - Mode division 1 - Mode soustraction/division 1 1 Dans nos travaux, nous avons choisi d utilisé le mode division. Mais la formulation de la fonction objectif nécessite d être adaptée à notre problème de sélection. En effet, le problème présenté ainsi est un problème de maximisation. Or, notre sélection de structure d optimisation se base sur la minimisation du coût d exécution des requêtes. L adaptation du problème nécessité une reformulation de la fonction pénalité. Cette fonction doit pénaliser les solutions qui violent la contrainte en augmentant leur fonction objectif. Nous présentons dans ce qui, la fonction objectif choisie pour la sélection d index et celle adoptée pour la sélection d un schéma de fragmentation. (Aouiche, et al., 2005) proposent trois types de fonction objectif permettant d évaluer le coût d exécution d une charge de requête sur un entrepôt optimisé La première fonction «Fonction objectif profit» privilégie les structures d optimisation qui apporte les plus de profit lors de l exécution de la charge de requête. La seconde «Fonction objectif ratio profit/contrainte» favorise les structures d optimisation qui apportent le plus de profit mais qui ne viole pas une contrainte C. Enfin la troisième fonction «Fonction objectif hybride» représente une hybridation des deux fonctions annoncée. Elle permet de sélectionner, en premier lieu, les structures qui apportent le plus de profit. Ensuite, si la contrainte risque d être violée, la fonction objectif sélectionne les structures qui apportent le plus de profit mais qui ne viole pas la contrainte. Pour notre approche de sélection nous avons retenue la fonction objectif avec ratio profit/contrainte. Elle permet de sélection les structures d optimisation optimales sous la contrainte liée à la technique, cela en spécifiant la fonction F et la fonction pénalité Pen à partir de la contrainte, puis déterminer la fonction générale F. III.4.2 Fonction objectif pour la fragmentation Nous allons présenter, dans ce qui suit, la formulation de la fonction objectif ainsi que la fonction pénalité pour la sélection, par algorithme génétique, d un schéma de fragmentation. Soit un entrepôt de données modélisé en étoile avec une table de fait F et d tables de dimensions D 1,...D d. nous allons considérer ce qui suit : - Une charge de t requête Q = Q 1,, Q t à exécuter sur l entrepôt. - L espace de m solutions ou schémas de fragmentations possibles générés par l algorithme génétique SF = SF 1,, SF m. - Nsf i sous schéma en étoiles relatifs à un schéma SF i = S 1, S Ni. Rappelons le coût d exécution d une requête Q k sur un sous schéma S j :,, 3 80

89 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation Avec le nombre de prédicats de sélection qui définissent un fragment fait. le nombre de prédicats qui définissent un fragment de la dimension D s, ceci par rapport au sous schéma S j Le coût d exécution de la requête Q k sur tout le schéma fragmenté est le suivant,, On peut donc exprimer le coût d exécution de toute la charge de requête sur l entrepôt fragmenté :,, Afin de formuler la fonction objectif, il faut définir la fonction pénalité. Etant donné une contrainte sur le nombre de fragments fait maximum W, l algorithme génétique peut générer des solutions SF i dont le nombre de fragments dépasse W. La fonction pénalité d un schéma de fragmentation est égale à : Enfin, l algorithme génétique doit sélectionner un schéma de fragmentation qui minimise la fonction objectif ratio (profit/nombre de fragment maximum) suivante, 1, III.4.3 Fonction objectif pour les index Nous allons présenter, dans ce qui suit, la formulation de la fonction objectif ainsi que la fonction pénalité pour la sélection, par algorithme génétique, d index de jointure binaires Soit un entrepôt de données modélisé en étoile avec une table de fait F, d tables de dimensions D 1,...D d et t attributs dimensions A=A 1,, A t. Nous allons considérer ce qui suit : - Une charge de p requête Q = Q 1,, Q p à exécuter sur l entrepôt. - L espace de m configurations d index possibles ConfigI = ConfigI 1,, ConfigI m - Chaque configuration contient N i index : ConfigI i = I 1,, I n défini sur A Rappelons le coût d exécution d une requête Q k avec présence d un index I j, log 1 m 1 F F 1 e 8PS Supposant que Nv i index (Nv i N i ) sont sélectionnés parmi les index de ConfigI i. Le coût d exécution de t requêtes avec présence des Nv i index est :,, Soit l espace de stockage des index S, la fonction pénalité est donnée par la formule suivante : Où est une fonction qui permet de calculer l espace de stockage des index de ConfigI i : 16 Enfin, l algorithme génétique doit sélectionner les index de jointure binaires qui minimisent la «fonction objectif ratio (profit/espace de stockage d index)» suivante :, 1, 81

90 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation III.5 Sélection d un schéma de fragmentation Nombre de fragments maximum W Entrepôt de donnée Charge de requête Classe_FH : attributs de sélection choisit par «k-means» pour FH 1 - Découpage des domaines d attributs - Vérification des règles de correction 2 Codage du schéma de fragmentation 3 Sélection d un schéma optimal par génétique 4 Modèle de coût Implémentation du schéma de FH sur l entrepôt 1. Valeurs des attributs candidats à la fragmentation 2. Attributs de candidats à la fragmentation et leurs domaines 3. Schéma de fragmentation 4. Schéma optimal de fragmentation Figure III-9: Démarche de sélection d un schéma de fragmentation Etant donné un ensemble d attributs de sélection extrais à partir de la charge de requête et choisir par «k-means» pour la FH, nous définissions la démarche de fragmentation horizontale en s inspirant des travaux de (Boukhalfa, et al., 2008a). Cette démarche suit le processus suivant (figure III-9): En premier lieu, les domaines des attributs sont partitionnés en sous domaines suivants les prédicats de sélection des requêtes. Ces attributs et leurs sous domaines constitue un schéma de fragmentation initial. En suite, les règles de correction sur ce schéma de fragmentation sont vérifiées par rapport aux sous domaines d attributs. Après codage du schéma, celui-ci est soumis à un algorithme génétique, guidé par modèle de coût, pour sélectionner un SF optimal. Enfin, la FH primaire des dimensions et la FH dérivée de la table de fait sont réalisées sur l entrepôt. III.5.1 Démarche de sélection d un schéma de fragmentation Nous avons vu, dans la présentation des travaux de (Bellatreche, et al., 2008a) et (Boukhalfa, et al., 2008a) sur la fragmentation, que la fragmentation avancée dans le SGBD Oracle présentait deux manques importants. - La FH dérivée d une table est effectuée sur la FH primaire d une seule autre table. - La FH primaire d une table est faite sur une seule clé de fragmentation pour le mode simple et seulement deux clés pour le mode composite Ces manques empêchent la mise en œuvre d une stratégie de fragmentation bénéfique. En effet, les requêtes exécutées sur entrepôt renferment des jointures en étoiles entre une table de 82

91 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation faits et plusieurs tables de dimensions avec plusieurs opérations de sélections sur dimensions. Il serait intéressant de pouvoir fragmenter les dimensions suivant plusieurs attributs (plus de deux) puis de fragmenter la table de fait suivant la fragmentation primaire de toutes les dimensions concernées (Boukhalfa, et al., 2008a). Ainsi, nous nous somme basés sur ces travaux afin de mettre en œuvre la sélection d un schéma de fragmentation, cela en quatre parties : découper les domaines des attributs, coder le schéma de fragmentation, sélectionner le schéma optimal (le plus bénéfique) par algorithme génétique et enfin implémenter la fragmentation horizontale sur l entrepôt. III Découpage des domaines d attributs La fragmentation horizontale se base sur la répartition des tuples d une table en plusieurs sous ensembles suivant des prédicats de sélections définis sur les attributs de fragmentation. Lors de la génération d un schéma de fragmentation, il faut s assurer qu il vérifie les règles de correction annoncées dans (Bellatreche, 2000). Il doit assurer la reconstruction du schéma initial de l entrepôt (aucune perte de donnée), vérifier la disjonction entre fragments des tables et assurer la complétude qui signifie que chaque tuple d une table appartient à un fragment. A partir des attributs de sélection de la Classe_FH, il faut établir un schéma de fragmentation horizontale primaire des tables dimensions. Il faut découper, en sous domaines, les domaines de chaque attribut candidat à la fragmentation. Chaque attribut de fragmentation AF i de la dimension D k, appartenant à Classe_FH, possède un domaine de valeurs d i. Le découpage du domaine d i en n i sous domaine sd 1,, sd ni permet de spécifier n i fragments de la dimension D k. Pour t attributs AF 1,, AF t de la dimension D k le nombre de fragments total est égale à. Les valeurs des sous domaines d un attribut sont extraites de la charge de requêtes. Ces requêtes peuvent ne pas utiliser toutes les valeurs d un attribut. Ainsi, pour vérifier la complétude du schéma de FH et éviter la permet de données après fragmentation de l entrepôt, nous allons extraire, à partir de l entrepôt de données et pour chaque attribut, les autres valeurs qui ne figurent pas dans la charge de requêtes. Ces valeurs constituent un nouveau sous domaine sd ni+1 ajouté à chaque attribut. Ainsi, chaque attribut est muni de ni+1 sous domaine sd 1,, sd ni, + sd ni+1 Exemple 23 : Soit un entrepôt de données dont le schéma est donné par la figure III-10. Temps Id Mois Année Produit Id Classe Vente Id_Temps Id_ Client Id_ Produit Prix_Unit Client Id Age Genre Pays Figure III-10: Schéma en étoile d un entrepôt de données Soit une charge de requête à partir de la quelle on extrait les prédicats de sélections suivants : «Genre = F», «Mois=Jan», «Mois in (Fév, Mar)», «Classe = B» et «Age 20». Les attributs de fragmentation et les sous domaines complets sont : Genre = {F}, {M}, Mois = {Jan}, {Fév, Mar}, {Avr, Mai,, Déc}, Classe = {B}, {A, C, D} et Age = {[0, 20[}, {[20, 70]} 83

92 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation III Codage du schéma de fragmentation Nous avons vu que le nombre de fragments maximum pour une dimension est. Mais il se peut que certains sous domaines d un attribut soient regrouper dans le même sous domaine ce qui permet de générer un nombre de fragments dimension inférieur à. Afin d exprimer cela, les auteurs (Boukhalfa, et al., 2008a) proposent un codage du schéma de fragmentation. Ce codage permet de représenter le schéma de fragmentation sous forme d un tableau. Chaque ligne représente un attribut et ces sous domaines. Chaque sous domaine sera numéroté. Les domaines qui possèdent le même numéro vont être regroupés en un seul sous domaine. Si tout les sous domaines d un attribut possèdent la même valeur, l attribut ne participe pas à la fragmentation Exemple 24 : la figure suivante représente le codage d un schéma de fragmentation Mois Janvier (0) Février (0) Mars (0) Avr,, Déc (0) Age [0, 20[ (0) [20, 70] (1) Genre F (0) M(1) Classe A (0) B (2) C(1) D(1) Figure III-11 : Codage d un schéma de fragmentation Ce codage montre que les dimensions concernées par la fragmentation sont Client et Produit. Le partitionnement en sous domaine des domaines des attributs est le suivant : Age :{ [0, 20[} et {[20, 70]}, Genre : {F}, {M}, Classe : {A}, {B} et {C, D}. III Sélection d un schéma de fragmentation par algorithme génétique Afin d effectuer la sélection d un schéma de fragmentation, nous adoptons un algorithme génétique qui exploite le modèle de coût défini pour la fragmentation. Le chromosome de l algorithme représente un schéma de fragmentation. Chaque chromosome comporte des gènes composites et chaque gène composite contient n gènes simples. Chaque gène composite est un attribut et chaque gène simple est un sous domaine d attribut (Boukhalfa, et al., 2008a). L implémentation de l algorithme génétique est faite par une APT JAVA nommée JGAP (Java Genetic Algorithms Package) Nous disposons de tous les éléments requis afin de spécifier l algorithme de sélection d un schéma de fragmentation par algorithme génétique : 84

93 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation Algorithme de sélection d un schéma de fragmentation (Algorithme 3) Entrée : A : Tableau d attributs de sélection SD : Tableau à deux dimensions des sous domaine de A W : nombre de fragments maximum ED : ensemble de données relatif au modèle de coût (taille de table, de page système etc) D : ensemble de table de dimension F : table de fait Sortie : : schéma de fragmentation Notation : SF initial : schéma de fragmentation initial P 0 : population initiale de chromosome Fitness_FH : fonction objectif pour le génétique SF : schéma de fragmentation optimal Début SD = Complet (A, SD i ) /* compléter les domaines de chaque attribut*/ SF initial = Générer_SF (A, SD i ) /* codage des domaines d attributs*/ P 0 = Genetic_Population(SF initial ) Fitness_FH = Genetic_FitnessFonction (A, W, ED) SF = Genetic_GetBestSolution (A, SD, P 0, Fitness_FH) FHPrimaire (SF, D) /* fragmentation primaire des dimensions FHDérivée (D, F) /* fragmentation dérivée de la fait suivant la FH des dimensions Fin III.5.2 Implémentation du schéma de fragmentation sur l entrepôt Une fois le schéma optimal obtenu, une fragmentation horizontale primaire est effectuée suivant les attributs de fragmentations munis de leurs sous domaines. Chaque attribut AF i et un sous domaine sd j constitue un prédicat de fragmentation (AF i = sd j ). Afin de générer les fragments dimensions, il faut effectuer le produit cartésien entre les prédicats de chaque attribut avec les prédicats des autres attributs de la même table. Cela permet de vérifier la disjonction des fragments et la reconstruction du schéma initial. Exemple 25 : Considérons le schéma de fragmentation de la figure III-10. Les prédicats de fragmentation sur chaque dimension sont les suivants : - Pour la dimension Client, il y a deux prédicats sur Age et deux prédicats sur Genre. La combinaison de ces prédicats donne «Age <20 et Genre=F», «Age<20 et Genre=M», «Age 20 et Genre=F», «Age 20 et Genre=M». - Pour la dimension Produit, trois prédicats sur Classe : «Classe = A», «Classe = B» et «Classe in (B, C)». La génération des fragments dimension donne quatre fragments pour Client et trois pour Produit. Afin d implémenter la fragmentation, nous utilisons le SGBD Oracle. Un schéma de fragmentation peut présente une fragmentation sur une dimension suivant trois attributs et plus. Puisque ce type de fragmentation n est pas supporté par Oracle, les auteurs dans (Boukhalfa, et al., 2008a) proposent d ajouter à chaque dimension un attribut noté «COL». Cette colonne vise à 85

94 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation décrire l appartenance d un tuple de la dimension à un fragment donné en affectant, dans cette colonne, le numéro du fragment. Pour ce faire, il faut comparer les valeurs des attributs de fragmentation dans le tuple aux valeurs dans les prédicats de fragmentation de chaque fragment. Ainsi, pour fragmenter la dimension, suivant plusieurs attributs, il suffit de la fragmenter suivant cet attribut particulier. C est une fragmentation de mode simple bien supportée par Oracle. Exemple 26 : Soit l entrepôt de données de la figure III-10. Nous présentons dans le tableau III-5 la numérotation des fragments de chaque dimension Table Client Table Produit Age Genre N de fragment Classe N de fragment < 20 > = 20 < 20 > = 20 F M F M Tableau III-5 : Numérotation des fragments dimension Le remplissage de la colonne «COL» pour les dimensions «Client» et «Produit» est : Table Client Id Pays Age Genre COLC Algerie Syrie Algérie Tunisie M F M M Figure III-12: Remplissage de la colonne «COL» dans les dimensions Une fois la FH primaire faite, la FH dérivée sur la table de faits est réalisée suivant les dimensions fragmentées. Comme Oracle ne permet par la FH dérivée de la table de faits suivant plus d une dimension, les auteurs dans (Boukhalfa, et al., 2008a) proposent d ajouter une colonne «COLF» à la table de fait. Pour chaque tuple de fait, on affecte à la colonne COLF la concaténation entre tous les numéros de fragments dimensions auxquels appartient le tuple. A ce niveau, le problème de est de fragmenter la table de faits effectivement suivant cet attribut. Or Oracle ne permet pas de fragmenter une table que lors de sa création. Ainsi, les auteurs propose de créer une vue qui contient tous les tuples fait et qui calcul la colonne COLF. Par la suite, une nouvelle table de fait fragmentée selon COLF est créée. Il suffit alors de remplir cette table avec les données de la vue. Cette vue est créée à partir de la table de fait non partitionnée, les dimensions, et chaque attribut «COL». La vue contient des jointures naturelles entre table de faits et toutes les dimensions en spécifiant dans la clause SELECT les attributs de la table de faits, ce qui permet de reconstituer la table de fait. Exemple 27 : La syntaxe SQL pour créer la vue suivant l exemple précédant est donnée par : CREATE MATERIALIZED VIEW VM BUILD IMMEDIATE AS SELECT V.Id_Temps, V.Id_Client, V.Id_Produit, V.Prix_Unit COLC '-' COLP as COLF FROM Vente V, Client C, Produit P WHERE V.Id_Produit=P.Id AND V.Id_Client=C. Id A B C D Table Produit Id Classe COLP A C B C D A

95 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation Le remplissage le la colonne COLF, à partir des colonnes COL des dimensions, est présenté sur la figure III-13. On donne l exemple d un sous schéma qui vérifie «Genre = M et Age > 20» et «Classe in (C, D) (figure III-14) : Vue matérialisée Id_Temps Id_ Client Id_ Produit Prix_Unit COLF Figure III-13: Remplissage de la colonne «COL» pour Client2 Id Pays Age Genre COLC Algerie Algérie Tunisie M M M Produit3 Id Classe COLP C C D Figure III-14: Exemple de sous schéma après fragmentation Pour résumer, la mise en œuvre de la fragmentation passe par les étapes suivantes : - Ajouter pour chaque dimension ainsi que la table de fait un attribut «COL». Cet attribut va contenir, pour chaque tuple de chaque table, le numéro de fragment au quel il appartient. - Remplir l attribut «COL» des dimensions selon le schéma de fragmentation sélectionné par génétique. - Fragmenter les dimensions suivant l attribut «COL» par FH primaire - Créer une vue à partir de la table de fait, les dimensions, et chaque attribut «COL». - Créer une table de fait partitionnée. Vente6 Id_Temps Id_ Client Id_ Produit Prix_Unit COLF Remplir la table de fait partitionnée à partir de la vue. 3 1 Cette démarche a permit de palier au manque du SGBD Oracle concernant la fragmentation. III.5.3 Réécriture des requêtes pour exécution sur schéma fragmenté La fragmentation réalisée sur l entrepôt est une fragmentation de chaque table suivant l attribut COL. Le problème est que cet attribut est créé pour les besoins de fragmentation et ne figure dans aucune requête. Ainsi, l exécution de la requête brute sur un tel schéma n est pas améliorée. En effet, il n y a aucun moyen d identifier les fragments non pertinent pour cette requête. Par conséquent, pour que la fragmentation soit prise en compte lors de l exécution d une requête, chaque requête doit être réécrite pour prendre en compte le nouveau schéma de données. L exécution d une requête sur un schéma fragmenté passe par les étapes suivantes :

96 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation - Identifier les sous schémas valides pour la requête - Exécuter la requête sur chaque sous schéma, cela nécessite deux opérations : Trouver la correspondance de la requête avec chaque fragment fait Identifier les jointures à effectuer - Effectuer l union des résultats III Schémas valides pour une requête Il n est pas nécessaire d exécuter les requêtes sur tous les sous schémas, c est l intérêt même de la FH. En effet, il suffit d exécution la requête uniquement sur les sous schéma valides en éliminant les partitions non pertinentes. Un sous schéma valide pour une requête est un sous schéma où le fragment fait est accédé par la même requête sur au moins un tuple. Exemple 28 : Considérons l entrepôt de données fragmenté de la figure III-15 Produit1 Classe = A Produit2 Classe = B Produit3 Classe = C ou D Vente1 Vente2 Vente3 Vente4 Vente5 Vente6 Client1 Genre= F Client2 Genre= M Figure III-15: Schéma d entrepôt de données en étoile et fragmenté Soit la requête : SELECT Id_Temps, Sum(Prix_Unit) FROM Vente V, Client C, Produit P WHERE V.Id_Produit=P.Id AND V.Id_Client=C. Id AND C.Genre= F AND P.Classe in (A, C) GROUP BY Id_Temps Les fragments fait valides pour cette requête sont les fragments contenant les tuples qui vérifient : (Genre = F) et (Classe = A ou C). Ces fragments sont : Vente1 et Vente5 III Exécution d une requête sur un sous schéma Sur un schéma d entrepôt fragmenté, la fragmentation horizontale primaire précalcule les opérations de sélection sur les dimensions. Quand à la et la fragmentation dérivée, elle précalcule des jointures entre les dimensions et la table de fait. Ainsi, lors de l exécution d une requête sur un sous schéma, certaines jointures et opérations de sélection ne sont pas nécessaires. Afin de trouver les sélections à calculer, il faut identifier la correspondance entre la requête et chaque fragment faits. De plus, il faut identifier les jointures à effectuer dans chaque sous schéma. 1. Correspondance de la requête avec un fragment fait La correspondance entre fragment fait et requête permet de savoir si les tuples du fragment fait vérifient les prédicats de sélection de la requête, autrement dit, si ces tuples vont participer au calcul des résultats de la requête. Il existe trois types de correspondance : - Aucune : cela signifie que le sous schéma n est pas valide pour la requête 88

97 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation - Totale : tout les tuples du fragment fait sont pertinent pour la requête. La requête contient tous les prédicats de sélection qui définissent les fragments dimensions - Partielle : le fragment fait contient des tuples non pertinent pour la requête. La requête ne contient pas tous les prédicats de sélection qui définissent les fragments dimensions Exemple 29 : Pour la requête suivante SELECT Id_Temps, Sum(Prix_Unit) FROM Vente V, Client C, Produit P WHERE V.Id_Produit=P.Id AND V.Id_Client=C. Id AND C.Genre= F AND P.Classe in (A, C) GROUP BY Id_Temps La correspondance avec le fragment Vente1 est totale. En effet, les tuples de ce fragment vérifient «Genre=F» et «Classe=A». Par contre la correspondance avec Vente5 est partielle. Ce fragment contient les tuple dont «Classe=D». Ces tuples sont non pertinent pour la requête. 2. Identification des jointures à effectuer Les jointures à effectuer sont identifiés grâce aux dimensions et les attributs dimensions qui figurent dans la requête. Si la requête contient une jointure avec une dimension non fragmentée, la jointure est ajoutée. Concernant les attributs dimension, ils figurent soit dans la clause SELECT ou WHERE. Pour les attributs présents dans la clause SELECT, la jointure avec la dimension est immédiatement ajoutée. Concernant les attributs dans la clause WHERE, ils n impliquent pas forcement une jointure car certaines sont précalculées par FH dérivée. Ces jointures dépendent de la correspondance entre le fragment fait et la requête : - Correspondance totale : aucune jointure supplémentaire n est ajoutée, le fragment fait répond complètement à la requête - Correspondance partielle : afin d écarter les tuples non pertinent, il faut ajouter les prédicats de sélection qu il faut. Ces prédicats engendrent l ajout des jointures correspondantes. Exemple 30 : Supposant que le schéma d entrepôt de donnée contient une dimension non fragmentée «Temps» qui contient les attributs «Mois, Année». Soit la requête Q suivante : SELECT Pays, Sum(Prix_Unit) FROM Vente V, Client C, Produit P, Temps T WHERE V.Id_Produit=P.Id AND V.Id_Client=C. Id AND V.Id_Temps=T.Id AND C.Genre= F and P.Classe in (A, C) AND T. Mois = Janvier GROUP BY Pays La requête exécutée sur le schéma fragmentée de la figure III-15 nécessite les jointures suivantes : - Jointure entre chaque fragment valide pour Q et la dimension Temps (dimension non fragmentée) - Jointure avec le fragment dimension Client (attributs Pays figure dans le SELECT) - Jointure entre Vente5 et le fragment dimension Produit (correspondance partielle entre Ventre 5 et Q, il faut écarter les produit de Classe = D). c) Union des résultats Une fois la requête exécutée sur chaque sous schéma, on effectue une opération d union sur tous les tuples résultats. Ensuite, on effectue les opérations de groupement et d agrégation Exemple 31 : la réécriture de la requête précédente donne 89

98 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation SELECT Pays, Sum(Prix_Unit) FROM ( SELECT Pays, Prix_Unit FROM Vente PARTITION (Vente1) V, Temps T, Client PARTITION (Client1) C WHERE V.Id_Temps=T.Id AND V.Id_Client=C. Id AND T. Mois = Janvier UNION ALL SELECT Pays, Prix_Unit FROM Vente PARTITION (Vente5), Temps T, Client PARTITION (Client1) C, Produit PARTITION (Produit3) P WHERE V.Id_Temps=T.Id AND V.Id_Client=C. Id AND V.Id_Produit=P.Id AND T. Mois = Janvier AND P.Classe= C )GROUP BY Pays III.6 Sélection d index de jointure binaire Espace de stockage S Entrepôt de donnée Charge de requête Classe_IJB : attributs de sélection choisit par «k-means» pour IJB Codage des index candidats 1 Sélection d un schéma optimal par génétique Modèle de coût 2 Implémentation les IJB sur l entrepôt 1. Les index codés 2. Configuration d index optimale Figure III-16: Démarche de sélection d IJB Etant donné un ensemble d attributs de sélection extrais à partir de la charge de requête et choisir par «k-means» pour la les index, nous définissions la démarche de sélection d index de jointures binaire par algorithme génétique. Le processus de sélection d index suit les étapes suivantes (figure III-16): - Codage des index candidats : chaque attribut correspond à un IJB candidats. Afin de soumettre l ensemble des index candidats au génétique, il faut coder la configuration. Le chromosome représente une configuration d index et chaque gène représente un attribut indexable. Si un donné gène vaux 1, l attribut correspondant vé permettre de définir un index. Si c est 0, l attribut est écarté du processus de sélection. - La sélection d index se fait par génétique tout comme pour la sélection de SF. On soumet au génétique la configuration d index codée en chromosome et l algorithme sélectionne la meilleure configuration, en se basant sur la fonction objectif que nous avons défini 90

99 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation - L implémentation des index se fait par exécution de la requête de création (ORACLE) pour chaque attribut de dimension sur la table de fait : CREATE BITMAP INDEX IJB ON Fait (Dimension.Attribut) FROM Fait, Dimension WHERE Fait.Id_ Dimension = Dimension.Id ; Réduction de la complexité des index Le nombre possible d index générés sur une base de données est _ 2, où n est le nombre d attributs indexables. Vu la complexité du nombre d index possibles, nous avons adopté la sélection d index de jointures binaires mono attributs uniquement. Dans le cas où nous voulons obtenir un index sur plusieurs attributs dimensions, il suffit de faire une opération AND entre les IJB mono attribut voulus. Ainsi, le nombre d index de jointure binaires possible est _ 2 1. Algorithme de sélection et d implémentation d IJB (Algorithme 4) Entrée : A : ensemble d attributs de sélection S : espace de stockage maximum ED : ensemble de données relatif au modèle de coût (taille de table, de page système etc.) D : ensemble de table de dimension F : table de fait Sortie : Index de jointure binaires Notation : ChromosomeIJB: choromosome de configuration d index candidats P 0 : Population initiale de choromosomes Fitness _ IJB: fonction objectif pour le génétique Configuration_Finale_IJB : configuration d index optimimale Début ChromosomeIJB= Générer_Configuration_Index(A) P 0 = Genetic_Population(ChromosomeIJB) Fitness_IJB = Genetic_FitnessFonction (A, S, ED) Configuration_Finale_IJB = Genetic_GetBestSolution (P 0, Fitness_IJB) Implémenter_IJB(Configuration_Finale_IJB, D, F) Fin 91

100 Chapitre III : Nouvelle démarche de sélection d index et de fragmentation Conclusion Dans ce chapitre, nous avons proposé une nouvelle démarche de sélection combinée d un schéma de fragmentation et des index de jointures binaires. Cette démarche se base sur l étude du partage des attributs de sélection entre les deux structures dans le but de choisir, d un coté, les attributs les mieux adaptés pour la fragmentation et, d un autre côté, ceux qui permettent de mettre en œuvre les index les plus efficaces. Nous avons décrit notre démarche de partage d attributs de sélection par algorithme de classification «k-means». Cet algorithme est facile à utilisé, non gourmant en temps et en calcul et permet d obtenir de bon résultats de classification. Afin d exploiter cet algorithme, nous avons définit un poids de classification à partir d information sur les attributs de sélection : facteur de sélectivité des requêtes, la cardinalité des attributs et la fréquence d un attribut dans la charge de requêtes. Ce poids à permis, à travers «k-means» d effectuer une bonne répartition des attributs entre fragmentation et index. Enfin, nous avons décrit l architecture de notre démarche de sélection, nous avons explicité les algorithmes de sélection et le modèle de coût utilisé pour guider la sélection des structures. 92

101 IV. Chapitre IV : Etude expérimentale et outil d assistance à l administration des EDs Devant la panoplie de structures d optimisation existantes, les approches de sélection et les algorithmes de sélection, l administration d un entrepôt de données devient une tâche très complexe, toute aussi difficile que la mise en œuvre d un concept d entrepôt de données. Ainsi, l administrateur trouve la nécessite d être assister afin d accomplir la tâche d optimisation des requêtes décisionnelles. Il est vrai que les outils d assistance à l administration d ED existant prennent en charge la sélection d un grand nombre de structures d optimisation : index, vues matérialisée, fragmentation horizontale et verticale, particulièrement dans le domaine des bases de données. On cite l outil AutoAdmin lancé par Microsoft SQL Server et DB2 Advisor d IBM pour administration des bases de données. Mais également Oracle Tuning Advisor pour l administration et le tuning des entrepôts de données. Dans le domaine de recherche on peut citer l outil ParAdmin proposé par (Bellatreche, et al., 2008a) Dans nos travaux, nous avons préféré se concentrer sur l optimisation des requêtes décisionnelles qui renferment des jointures en étoiles et opérations de sélection sur les dimensions. Ainsi nous avons développé un outil nommé «AdminFIC». Il prend en charge la classification des attributs de sélection pour la sélection combinée d un schéma de fragmentation et d index de jointure binaires. La sélection de chaque technique est effectuée par algorithme génétique guidé par un modèle de coût Nous allons, dans ce chapitre présenter l architecture générale de notre outil «AdminFIC», nous allons procéder à une description du fonctionnement de l outil pour finir par une étude expérimentale présentant les résultats des différents tests effectués sous Oracle 11g. IV.1 AdminFIC : Outil de sélection de FH et IJB par classification Afin de mettre en œuvre, et tester l approche que nous avons décrite jusqu ici, nous avons mis en œuvre un outil de sélection combinée de FH et IJB, basé sur la classification d attribut et nommé AdminFIC., l architecture de l outil est présentée dans la figure IV-1. L outil AdminFIC permet d assister l administrateur afin de mettre en œuvre une stratégie d optimisation d un entrepôt de données basé sur la fragmentation horizontale et les index de jointure binaires. Nous avons développé cet outil sous l IDE Eclipse et lui avons intégré deux API JAVA, l une permet d implémente l algorithme de classification «k-means», la seconde nommé JGAP (Java Genetic Algorithms Package) est un Framework qui implémente un algorithme génétique pour la sélection des techniques d optimisation. Notre outil permet de charger un schéma en étoile d un entrepôt de donnée et de spécifier une charge de requêtes à optimiser. L outil permet à l administrateur d effectuer les opérations suivantes : - Visualiser l état de l entrepôt ainsi que la charge de requêtes - Choisir la démarche de sélection isolée ou combinée de FH et IJB - Paramétrer l algorithme génétique et l algorithme de classification k-means - Paramétrer la sélection en spécifiant les contraintes W et S. 93

102 Chapitre IV : Etude expérimentale et outil d assistance à l administration des EDs SGBD Oracle 11g Entrepôt de donnée Administrateur Visualiser l état actuel Conception physique : Sélection des techniques d optimisation - Schéma de l entrepôt (tables, attributs) - Charge de requêtes (requêtes SQL, nature) - Coût d exécution des requêtes Isolée Combinée FH/IJB FH Seul IJB Seul Simple Avec Classification Préparation Génération des scripts Implémentation des structures sélectionnées Paramètres d algorithmes Configuration de W et S Type de fragmentation Génétique k-means Personnalisée Non personnalisée Choix des tables Choix des attributs Figure IV-1: Architecture générale de l outil AdminFIC - Sélectionné, pour FH seule et sélection combinée simple, le type de fragmentation : personnalisée où l administrateur choisit les tables et les attributs concerné par le processus de sélection de FH, non personnalisé ou la tâche de sélection est entièrement laisser à la charge de l outil - Visualiser les résultats de sélection : attributs de fragmentation, nombre de sous domaines pour chaque attributs, nombre de fragments de la table fait, attribut d indexation et enfin, attributs exclus du processus de sélection 94

103 Chapitre IV : Etude expérimentale et outil d assistance à l administration des EDs IV.1.1 Visualisation de l état de l entrepôt Chargement Figure IV-2: Visualisation de l état de l entrepôt L Outil AdminFIC permet, à travers le bouton «Charger», de charger le schéma en étoile d un entrepôt de données et de le connecter au SGBD Oracle, puis l outil affiche les tables de l entrepôt, le nombre de tuples ainsi que les attributs de chaque table. Il permet également de spécifier la charge de requêtes à optimiser, à partir d un emplacement sur disque. IV.1.2 Paramètres des algorithmes Figure IV-3: Choix de paramètre pour le génétique et k-means Afin d effectuer la sélection des structures d optimisation, l administrateur doit spécifier le paramètre de l algorithme de classification «k-means» à savoir le nombre d itération pour exécuter la classification. De plus, il doit introduire les paramètres lié à l algorithme génétique : la taille de la population, le nombre de génération, le taux de croisement et le temps de mutation (figure IV-3). Ces paramètres vont être introduits à l API JAVA relative à l implémentation de chaque algorithme. IV.1.3 Sélection combinée avec classification OAC Afin d effectuer l optimisation de l entrepôt par sélection combinée de FH et IJB, l administrateur doit choisir entre l optimisation simple OS et l optimisation avec classification OAC. Il doit spécifier les contraintes sur chaque sélection : W et S. Pour la démarche OAC (figure IV-4), l outil affiche la classification des attributs en deux classes : Classe_FH et Classe_IJB. En appuyant sur le bouton «Démarrer», la sélection des techniques est lancée. L administrateur peut visualiser l avancement de la sélection grâce à une barre de progression. Une fois la sélection terminée, l outil montre le temps, en seconde, que les algorithmes on prit pour sélectionner toutes les structures d optimisation. 95

104 Chapitre IV : Etude expérimentale et outil d assistance à l administration des EDs Figure IV-4: Paramétrage de l approche OAC Figure IV-5: Résultats de sélection par OAC Une fois la sélection achevée, l outil permet de visualiser les résultats (figure IV-5), il montre les attributs de fragmentations muni chacun du nombre de sous domaine, ainsi que le nombre total de fragments fait. Il montre aussi les attributs d indexation et les attributs exclus du processus de sélection. IV.1.4 Sélection combinée simple OS (sans classification) Figure IV-6: Paramétrage de l approche OS Concernant la démarche d optimisation simple, l administrateur spécifie les contraintes W et S. Il peut personnaliser la fragmentation en choisissant les attributs de fragmentation et les tables à fragmenter. 96

105 Chapitre IV : Etude expérimentale et outil d assistance à l administration des EDs Figure IV-7: Résultats de sélection par OS Comme pour la sélection par classification, l outil montre les résultats : les attributs de fragmentation et le nombre de sous domaines, les attributs d indexation et les attributs exclus du processus de sélection. IV.2 Environnement expérimental Nous avons effectué l étude expérimentale sous le SGBD Oracle 11g avec une machine Intel Core2Duo et une mémoire 2go. Notre étude utilise un entrepôt de données réel issu du benchmark APB1 (Council, 1998). Sur cet entrepôt de données, on exécute une charge de 47 requêtes. Le schéma en étoile de cet entrepôt est donné par la figure IV-8. Il est constitué d une table de faits Actvars ( tuples) et de quatre dimensions, Prodlevel (9 000 tuples), Custlevel (900 tuples), Timelevel (24 tuples) et Chanlevel (9 tuples). Dans un premier temps, nous allons présenter notre sélection d IJB et FH avec classification d attributs de sélection effectuée sur l entrepôt réel. Par la suite, nous allons effectuer une série de test afin de montrer l intérêt de notre démarche. CustLevel Store Retailer Gender City Timelevel Tid Year Quarter Month Actvars Customer Product Channel Time UnitsSold DollarSales Prodlevel Code Class Group Family Division Base All Chanlevel Figure IV-8 : Schéma en étoile de l entrepôt expérimental IV.2.1 Démarche d Optimisation Avec Classification OAC Nous allons monter, dans ce qui suit, la mise en œuvre de notre démarche de sélection combinée de FH et d IJB à base de classification d attributs de sélection. la présentation de notre démarche est accompagnée par les résultats obtenues sur site réel avec W = 70 et S = 500 Mo. IV Classification des attributs en deux classes : Afin d effectuer la classification des attributs, nous avons besoins de calculer trois facteurs importants : nombre de requêtes accédant à un même attribut, le facteur de sélectivité des valeurs 97

106 Chapitre IV : Etude expérimentale et outil d assistance à l administration des EDs d attributs et la cardinalité d attributs. Ces facteurs vont nous permettre de calculer le poids de classification. Attribut Frc FS Card Frc Normalisé FS Normalisé Card Normalisé Poids Poids translaté Class_level Group_level Quarter_Level Family_Level Month_Level Division_Level Year_Level Gender_Level Retailer_Level City_Level All_Level Tableau IV-1 : Calcul du poids de classification Le tableau IV-1 résume les attributs de sélection et leurs poids de classification, les facteurs de classification on été normaliser afin d obtenir une cohérence du poids. En effet, pour l attribut «Classe» par exemple, Frc = 4, FS = 00,1 et la cardinalité est de 605. Une somme directe entre ces facteurs engendre la domination de la cardinalité par rapport aux autres facteurs. A partir du tableau IV-1, nous remarquons que le poids représente des valeurs négatives. Afin de ne pas soumettre des valeurs négatives à l algorithme «k-means», nous additionnons au poids une constante qui rend toute ces valeurs positives. Cette constante est égale à 2. Figure IV-9 : Répartition des attributs en fonction du poids de classification La figure IV-9 illustre la répartition des attributs en fonction de leurs poids. Les attributs sont répartis en deux classes : une pour la fragmentation et une pour les IJB. Les coordonnées des attributs illustré sur la figure IV-9 sont soumises à l algorithme «k-means», pour un nombre d itération 50, il en résulte la classification suivante : - Classe_FH = {Gender, Month, Year, All, Quarter, Group}, - Classe_IJB = {Family, Division, Class, City, Retailer}. 98

107 Chapitre IV : Etude expérimentale et outil d assistance à l administration des EDs IV Optimisation de l entrepôt de données: Optimisation de l entrepôt de données commence par sélectionner un schéma de fragmentation puis les index adéquats. Ces structures sont enfin implémentées sur l entrepôt a) Fragmentation horizontale Attribut Domaines Gender F M Month 1, 2 3,4,,12 Year All EF BC Quarter Q1, Q2 Q3, Q4 Group S7 Les autres valeurs Tableau IV-2 : Schéma de fragmentation optimal pour OAC L algorithme génétique sélectionne le schéma de FH du tableau IV-2 avec 8 fragments sur Timelevel (Month, Year, Quarter), 2 fragments sur Chanlevel (All) et 4 fragments sur Custlevel (Gender, City), ceci donne 64 fragments Fait. b) Indexation Une fois un schéma de FH sélectionné sur la Classe_FH, les attributs de fragmentation constituent un ensemble AttFrag. Cet ensemble n est pas forcement égale à Classe_FH, un ensemble d attributs est exclu de la fragmentation. Soit AttExclu = Classe_FH - AttFrag cet ensemble qui est ajouté à la Classe_IJB. Ainsi, Sur Classe_IJB + AttExclu les IJB sont définit. Dans notre cas, tous les attributs de Classe_FH sont concernés par la FH. Le génétique sélectionne, sur Classe_IJB, quatre IJB sur cinq qui sont : {Family, Division, City, Retailer}, sous une contrainte d espace S=500 Mo. c) Implémentation de la FH et des IJB : Notre application permet de générer des scripts SQL qui décrivent toutes les opérations nécessaires afin de réaliser l implémentation physique des structures d optimisation. IV.2.2 Démarche d Optimisation Simple OS Afin d évaluer les performances de notre démarche d optimisation par classification, nous avons effectué l optimisation de l entrepôt simple. Elle consiste à effectuer la sélection d un schéma de fragmentation puis la sélection d IJB sans effectuer la classification. L exécution de la FH donne les résultats du tableau IV-3 : Attribut Domaines Quarter Q1, Q3 Q2, Q4 Group S7J M Family URT Les autres valeurs Month 7 1,2,,12 Class P70, L2B Les autres valeurs Retailer ZST, COG Les autres valeurs Tableau IV-3 : Schéma de fragmentation optimal pour OS 99

108 Chapitre IV : Etude expérimentale et outil d assistance à l administration des EDs Le schéma de FH sélectionné du tableau IV-3 donne 64 fragments fait : 8 fragments sur la dimension Prodlevel (Group, Family, Class), 4 fragments sur Timelevel (Month, Quarter) et 2 fragments sur Custlevel (Retailer), ce qui L algorithme génétique sélectionne des IJB définis sur les attributs suivants : {Gender, Year, All, City, Division}. IV.3 Tests et résultats Nous avons effectué plusieurs tests, dans chaque test, nous avons comparé entre OAC et OS afin de montrer la méthode qui donne la meilleure optimisation. Les coûts des requêtes, après chaque implémentation d une optimisation, sont calculés par l optimiseur d Oracle11g. L étude expérimentale vise à montrer trois points essentiels : - L intérêt d optimiser une charge de requêtes, exécutée sur un entrepôt de données, par sélection combinée d un schéma de fragmentation et index de jointure binaires - L intérêt de l approche de classification par «k-means» des attributs de sélection en attributs de fragmentation et attributs d indexation - Manier les structures d optimisation est une tâche difficile qui requière une grande expérience et une bonne maitrise de l administrateur. Estimation du coût d exécution des requêtes avec Oracle Afin de calculé les coûts d exécution des requêtes sur le schéma de l entrepôt optimisé, nous faisant appel à l optimiseur d Oracle, qui estime le coût d exécution d une requête dans pour autant l exécutée réellement. Cela est possible à travers l opération EXPLAIN PLAN d Oracle. Soit une requête dont la syntaxe est la suivante : SELECT * FROM Table WHERE Attribut = valeur Il possible d estimé le coût d exécution de Q à travers la requête suivante : EXPLAIN PLAN SET STATEMENT_ID = Q_Id FOR SELECT * FROM Table WHERE Table.Attribut = valeur Cette requête à pour effet d estimer le coût d exécution de Q et de le stocké dans une table system nommée Plan_Table dans une colonne Cost avec une clé Q_Id. afin d obtenir le coût de Q à partir de la table système il suffit d exécuter la requête suivante SELECT Cost FROM Plan_Table WHERE STATEMENT_ID = Q_Id IV.3.1 Test 1 : Variation du mode d optimisation Nous avons réalisé l optimisation de l ED selon différent mode : IJB Seul, FH Seule et FH et IJB avec S=500 Mo et w=70. Pour chaque mode, nous effectuons l optimisation par OAC et OS afin de comparer les résultats. 100

109 Chapitre IV : Etude expérimentale et outil d assistance à l administration des EDs Figure IV-10 : Coût d'exécution (E/S) pour différents modes Figure IV-11 : Taux de requêtes optimisées Figure IV-12 : Taux de réduction du coût de la charge de requêtes Nous présentons, dans les figures IV-10, IV-11 et IV-12 plusieurs résultats suivant les quatre modes. Pour chaque mode, nous spécifions les résultats pour OS et OAC. La figure IV-10 illustre les coûts d exécution de la charge de requêtes, la figure IV-11 montre le taux des requêtes optimisées et enfin la figure IV-12 présente le taux de réduction du coût total de la charge. Nous remarquons que le meilleur coût d exécution est obtenu pour le mode mixte FH/IJB et pour la démarche avec classification OAC. En effet, le coût passe de millions à millions E/S, soit une réduction de 60% du coût total et 96% des requêtes ont été optimisées. Cela montre deux résultats essentiels : - La fragmentation sur la classe d attributs choisis par k-means donne un meilleur coût que la fragmentation sur tout l ensemble d attributs. En effet, pour l approche OAC, les attributs les plus appropriés sont choisi pour la fragmentation. - L optimisation mixte par FH et IJB apporte les meilleurs résultats. En effet, la prise en compte des deux techniques permet de trouver un compromis entre les deux contraintes S et W sur IJB et FH respectivement. - Notre démarche OAC permet une meilleure optimisation que la méthode simple, elle permet de choisir pour la FH et les IJB les attributs les plus adéquats. - Notons que pour l indexation seule, la méthode simple présente un meilleur résultat. En effet, la méthode simple définis les IJB sur tout les attributs de sélection, par contre notre démarche OAC définis l indexation uniquement sur la classe IJB. IV.3.2 Test 2 : Variation de W (S = 500mo) Afin de voir l influence de la contrainte W (nombre de fragments maximum) sur l optimisation de la charge de requêtes, nous avons fait varier W avec S=500 mo. Pour chaque valeur de W, nous effectuons une optimisation par la démarche OS et une par OAC. Ce test se déroule en deux parties : En premier lieu, nous avons relevé le coût d exécution et le taux de requêtes optimisées (figures IV-13, IV-14). En suite, nous montrons le temps d implémentation des techniques d optimisation sélectionnées sur entrepôt réel (Tableau IV-4). 101

110 Chapitre IV : Etude expérimentale et outil d assistance à l administration des EDs a) Coût d exécution et optimisation des requêtes Figure IV-13 : Effet de W sur le coût (E/S) Figure IV-14 : Effet de W sur le taux d optimisation des requêtes Les résultats qu illustrent les figures IV-13 et IV-14 montrent que la meilleure optimisation est obtenue avec notre démarche OAC surtout pour W = 90 et 150. En effet, le coût est réduit de 68% et 75% respectivement avec 96% des requêtes optimisées. b) Temps d implémentation des structures Pour le test que nous venons d effectuer, nous avons relevé le temps d implémentation des structures optimisation, index et fragmentation, les résultats sont résumé dans le tableau IV-4. Le temps total pour effectuer le test de variation de W sur les deux sélections OS et OAC est de 13h 44mn et 55s. W OS OAC 30 39mn 51 55mn 5s 50 45mn 54s 1h 25mn 44s 70 47mn 31s 55mn 4s 90 48mn 51s 1h 6mn 10s mn 28s 1h 6mn 31s mn 52s 1h 37mn 34s mn 50s 1h 27mn 30s Total 5h 11mn 17s 8h 33mn 38 s Tableau IV-4 : Temps de réalisation des tests expérimentaux IV.3.3 Test 3 : Variation de S (W = 50) Figure IV-15 : Comparaison entre OAC et OS par variation de l espace de stockage 102

111 Chapitre IV : Etude expérimentale et outil d assistance à l administration des EDs Tout comme pour le test 2, nous avons voulu étudier l influence de la contrainte d espace de stockage des index S sur l optimisation de la charge de requêtes. Nous avons fait varier S Avec W=50. Pour chaque valeur, nous effectuons une optimisation par la démarche OS et une par OAC. Nous avons relevé le coût d exécution de la charge de requêtes (figure IV-15). Sachant que l espace de stockage théorique que nécessitent tous les index, sans compression, est de 3,27 Go, nous avons fait varier S de 50 à 2500 Mo. Nous remarquons que, pour S entre 50 et 300Mo, l approche simple OS apporte une meilleure optimisation, mais à partir de 400 Mo, la meilleure optimisation est obtenue par notre approche OAC. L optimisation simple OS apporte une meilleure amélioration du coût d exécution pour de faibles valeurs de S (50, 300 Mo). En effet, la majorité des attributs sélectionnés pour indexation sont de faibles cardinalité (Gender 2, Year 2, All 2, City 3 et Division 4}. Des index définis sur ces attributs ne sont pas volumineux et ne violent donc pas la contrainte d espace de stockage. D un autre coté, les attributs indexables sélectionnés pour notre approche OAC ont les cardinalités suivantes : Family 75, Division 4, Class 605, City 3 et Retailer 99. Pour que la taille de ces index ne viole pas la contrainte d espace il faut que S soit grand (> 400 Mo). Ainsi, pour de faibles valeurs de S, peu d index seront sélectionnées par le génétique ce qui empêche l optimisation de certaines requêtes. Mais à partir de S=500mo, d avantage d index sont sélectionné par notre approche OAC ce qui donne un coût de 12,2 Millions E/S par rapport à 14,1 Millions E/S pour la démarche (OS), jusqu'à obtenir la meilleurs optimisation (11,7 Millions E/S) pour S=2000mo. IV.3.4 Performance d algorithmes de sélection (comparaison test 2 et test 3) En effectuant les tests précédents 2 et 3, nous avons relevé le temps de sélection (seconde) par génétique de la FH et des IJB, les résultats sont illustrés dans les figures suivantes : a) Test 2 Variation de W (S = 500mo) Figure IV-16 : Temps de sélection d un schéma de FH (variation de W) Figure IV-17 : Temps de sélection d IJB (variation de W) Les figures IV-16 et IV-17 montrent le temps de sélection d un schéma de FH et des IJB respectivement, cela par algorithme génétique. Nous notons que les performances d exécution des algorithmes de sélection diffèrent sur la fragmentation. De plus, ce temps de sélection est presque linaire pour l approche OAC, mais pour OS, il démarre de 2,4s pour décroitre vers 2s par augmentation de W. En effet, la sélection pour OS est effectuée sur tous les attributs (11 attributs), pour OAC, seul les attributs de la Classe FH sont concernés (6 attributs). Concernant la sélection d IJB, le temps de sélection et pratiquement le même, que ce soit pour OAC ou pour OS. Pour de faibles valeurs de W, la sélection dure entre 1,6s et 2s et plus W augmente plus ce temps décroît jusqu'à atteindre presque 1s. En effet, l augmentation de W réduit 103

112 Chapitre IV : Etude expérimentale et outil d assistance à l administration des EDs le nombre d attributs écartés par la fragmentation, ce qui réduit le nombre d attributs candidats à la sélection d IJB et donc l espace de recherche soumis au génétique. b) Test 3 : Variation de S (W = 50) Figure IV-18 : Temps de sélection d un schéma de FH (variation de S) Figure IV-19 : Temps de sélection d IJB (variation de S) Les figures IV-18 et IV-19 montrent le temps de sélection d un schéma de FH et des IJB par algorithme génétique. Sur la figure IV-18, nous remarquons que le temps de sélection est linéaire car la contrainte W sur FH n a pas changée. Concernant la sélection des index (figure IV-19), elle croit légèrement avec l augmentation de l espace de stockage car cela augmente l espace des solutions admissibles sur les index (solutions qui ne violent pas la contrainte d espace) IV.3.5 Test 4 : Variation de l ordre d exécution pour FH/IJB Figure IV-20 : différentes exécutions pour FH et IJB Les tests effectués jusque là se basent sur la sélection d un schéma de FH suivi de la sélection des IJB. Nous avons testé le changement de l ordre de sélections (chaque technique dispose de son propre module de sélection). La figure IV-20 montre trois possibilités de sélections : FH puis IJB, IJB puis FH et FH//IJB avec S=500 Mo et W=50. Concernant la démarche de sélection FH//IJB, elle signifie que chaque sélection est effectuée sur sa classe correspondante, sans prendre en compte les attributs non choisit par l autre sélection. Figure IV-20 montre que les meilleurs résultats sont obtenus par notre approche OAC pour l ordre FH puis IJB (11.24 m E/S), suivi de la démarche OAC avec l ordre FH//IJB (12.41 m E/S) puis OS avec l ordre FH puis IJB (14.29 m E/S) et enfin OAC avec IJB puis FH (17.04 m E/S). A partir de ces résultats, nous pouvons faire les remarques suivantes : - L ordre IJB puis FH donne l optimisation la moins intéressante. En effet, les attributs non sélectionnés par IJB vont être ajoutés à la classe FH et vont fausser le choix du schéma d optimisation (puisque la fragmentation est plus tolérante que la sélection d index, ces attributs peuvent être choisis pour la FH avec un nombre de sous domaines réduit.). Ces attributs on été choisit pour les IJBs lors de la classification et sont donc non adaptés pour la 104

113 Chapitre IV : Etude expérimentale et outil d assistance à l administration des EDs FH. Contrairement à l ordre FH puis IJB où les attributs écartés par la sélection de FH et non adaptés pour IJB vont être directement écartés par la sélection d IJB. - Les résultats de OS dans le mode FH puis IJB (14,29 millions) sont meilleurs que OAC dans le mode IJB puis FH (17,04 millions). En effet, la fragmentation dans OS (FH puis IJB) s effectue sur tous les attributs de sélection. Par contre, la fragmentation dans OAC (IJB puis FH) s effectue sur un ensemble d attributs qui contient des attributs non adaptés à la FH (attributs choisi par k-means pour indexation et écartés par la sélection d IJB). - L ordre FH//IJB est moins bénéfique que FH puis IJB car la séparation des deux sélections empêche la prise en compte par IJB des attributs non choisis par FH. Cela nous conduit à déduire la force de la classification des attributs. En effet, et malgré le fait que la FH est défini sur un nombre réduit d attributs, ces attributs constituent les meilleurs candidats pour la fragmentation. D autre part, ceux choisit pour les index sont plus adaptés aussi. Ce qui donne une meilleure optimisation globale. IV.3.6 Test 5 : Choix des Facteurs du Poids de classification Figure IV-21 : Optimisation selon la formulation du poids de classification Le poids de classification comporte trois facteurs : Frc, FS et Card. Afin d étudier leurs pertinences, nous avons effectué l optimisation par OAC en faisant varier la formulation du poids. Cela donne sept combinaisons possibles. Les résultats sont présentés dans la figure IV-21. Nous remarquons que la meilleure optimisation de la charge de requêtes est de 11,37 millions, elle est obtenue pour un poids de classification qui comporte tout les facteurs. Cela montre que les trois facteurs sont pertinents pour la classification. 105