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
A
NNEEU
NIVERSITAIRE2008/2009
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.
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.
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 ... 10
I.2.1 Les techniques redondantes ... 11
I.2.2 Les techniques non redondantes ... 16
I.2.3 Similarité entre techniques d'optimisation dans les entrepôts de données ... 18
I.2.4 Résumé des techniques d’optimisation dans les ED ... 20
I.2.5 Optimisation dans le SGBD Oracle ... 20
CONCLUSION ... 26
Chapitre II : Problèmes de sélection des techniques d’optimisation ... 27
II.1 SELECTION D’UN SCHEMA D’OPTIMISATION :PRE-REQUIS ... 27
II.1.1 Rôle de l’administrateur de bases ou entrepôts de données ... 28
II.1.2 Rôle du concepteur de la stratégie de sélection des techniques d’optimisation ... 30
II.2 PROBLEME DE SELECTION D’INDEX PSI ... 32
II.2.1 Démarche de sélection d’index ... 32
II.2.2 Formalisation du problème PSI ... 34
II.2.3 Travaux de Feldman et al. ... 35
II.2.4 Travaux de Kratica et al. ... 35
II.2.5 Travaux de Chaudhuri et al. ... 36
II.2.6 Travaux de Valentin et al. ... 37
II.2.7 Travaux de Golfareli et al. ... 38
II.2.8 Travaux Aouiche et al. ... 38
II.2.9 Travaux de Bellatreche et al ... 40
II.2.10Synthèse ... 42
II.3 PROBLEME DE SELECTION D’UN SCHEMA DE FRAGMENTATION ... 42
II.3.1 Algorithmes de fragmentation verticale ... 42
II.3.2 Algorithmes de fragmentation horizontale FH ... 44
II.3.3 Algorithmes de fragmentation mixte ... 47
II.3.4 Fragmentation dans les entrepôts de données ... 47
II.3.5 Synthèse ... 52
II.4 SELECTION COMBINEE D’IJB ET FH DANS LES ENTREPOTS DE DONNEES ... 53
II.4.1 Type de sélection combinée ... 54
II.4.2 Choisir entre sélection parallèle ou séquentielle... 55
II.4.3 Travaux de T. Stöhr et al ... 55
II.4.4 Travaux de Bellatreche et al. et Boukhalfa et al. ... 57
II.4.5 Analyse de l’approche existante ... 58
CONCLUSION ... 60
Chapitre III : Nouvelle démarche de sélection d’index et de fragmentation, dirigée par la
classification ... 61
III.1 DEMARCHE DE SELECTION COMBINEE AVEC PARTAGE DES ATTRIBUTS ... 61
III.1.1 Motivation ... 62
III.1.2 Problème de partage des attributs entre FH et IJB ... 67
III.1.3 Critère de partage ... 68
III.1.4 Déroulement du processus de sélection ... 68
III.2 CLASSIFICATION DES ATTRIBUTS DE SELECTION ... 71
III.2.1 Principe générale de classification ... 71
III.2.2 Classification des attributs par « k-means » ... 72
III.2.3 Exemple de classification ... 74
III.3 MODELE DE COUT ... 75
III.3.1 Modèle de coût pour la fragmentation ... 76
III.3.2 Modèles de coût pour les index... 78
III.4 FONCTION OBJECTIF POUR L’ALGORITHME GENETIQUE ... 79
III.4.1 Formulation d’une fonction objectif ... 79
III.4.2 Fonction objectif pour la fragmentation ... 80
III.4.3 Fonction objectif pour les index ... 81
III.5 SELECTION D’UN SCHEMA DE FRAGMENTATION ... 82
III.5.1 Démarche de sélection d’un schéma de fragmentation ... 82
III.5.2 Implémentation du schéma de fragmentation sur l’entrepôt ... 85
III.5.3 Réécriture des requêtes pour exécution sur schéma fragmenté ... 87
III.6 SELECTION D’INDEX DE JOINTURE BINAIRE ... 90
CONCLUSION ... 92
Chapitre IV : Etude expérimentale et outil d’assistance à l’administration des EDs ... 93
IV.1 ADMINFIC :OUTIL DE SELECTION DE FH ET IJB PAR CLASSIFICATION ... 93
IV.1.1 Visualisation de l’état de l’entrepôt... 95
IV.1.2 Paramètres des algorithmes ... 95
IV.1.3 Sélection combinée avec classification OAC ... 95
IV.1.4 Sélection combinée simple OS (sans classification) ... 96
IV.2 ENVIRONNEMENT EXPERIMENTAL ... 97
IV.2.1 Démarche d’Optimisation Avec Classification OAC ... 97
IV.2.2 Démarche d’Optimisation Simple OS ... 99
IV.3 TESTS ET RESULTATS ... 100
IV.3.1 Test 1 : Variation du mode d’optimisation ... 100
IV.3.2 Test 2 : Variation de W (S = 500mo) ... 101
IV.3.3 Test 3 : Variation de S (W = 50) ... 102
IV.3.4 Performance d’algorithmes de sélection (comparaison test 2 et test 3) ... 103
IV.3.5 Test 4 : Variation de l’ordre d’exécution pour FH/IJB ... 104
IV.3.6 Test 5 : Choix des Facteurs du Poids de classification ... 105
Conclusion ... 106
Perspectives ... 107
Bibliographie ... 108
Sites Web ... 110
Annexe A : Charge de requêtes ... 111
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 ... 11
Figure I-10: Schéma en étoile d’un entrepôt de données ... 12
Figure I-11: index de jointure en étoile ... 12
Figure I-12 : Exemple d’index bitmap ... 12
Figure I-13 : Exemple d’index bitmap de jointure ... 13
Figure I-14 : Exemple de fragmentation verticale ... 16
Figure I-15 : Exemple de fragmentation horizontale primaire ... 17
Figure I-16 : Exemple de fragmentation horizontale dérivée ... 18
Figure I-17 : FH dérivée et IJB sur la table Vente ... 19
Figure I-18: Mode de fragmentation simple ... 22
Figure I-19: Mode de fragmentation composite ... 23
Figure I-20: Mode de fragmentation dérivée REFERENCE ... 24
Figure I-21: Mode de Fragmentation Horizontale sous Oracle ... 25
Figure II-1 : Choix de l’administrateur pour une stratégie d’optimisation ... 28
Figure II-2 : Démarche de sélection d’index ... 32
Figure II-3 : Graphe d’exécution pour une requête ... 35
Figure II-4 : Outil de sélection d’index IST dans AutoAdmin ... 36
Figure II-5 : Architecture de DB2 Adviser ... 37
Figure II-6 : Matrice d’usage et supports ... 38
Figure II-7 : Exemple de motifs pour chaque requête ... 39
Figure II-8 : Architecture de sélection automatique d'index (Aouiche, et al., 2005) ... 39
Figure II-9: Fragmentation verticale par Hammer et al... 43
Figure II-10 : Architecture de fragmentation horizontale (Bellatreche, 2000) ... 45
Figure II-11: Schéma en étoile d’un entrepôt de données ... 50
Figure II-12: Codage d’un schéma de fragmentation ... 50
Figure II-13: Schéma d’entrepôt fragmenté ... 52
Figure II-14 : Types de sélection combinée pour deux structures d’optimisation ... 54
Figure II-15 : Population de l’entrepôt ... 55
Figure II-16 : Optimisation par FH et IJB sur l’attribut Pays ... 55
Figure II-17: schéma de sélection combinée d’IJB et FH par Stöhr ... 56
Figure II-18: schéma de sélection combinée d’IJB et FH ... 57
Figure III-1 Population de l’entrepôt de données ... 64
Figure III-2 – Schéma de fragmentation Genre=F / IJB sur l’attribut Genre ... 65
Figure III-3 – Données chargées pour l’exécution de la requête : cas FH sur Ville ... 66
Figure III-4 – Données chargées pour l’exécution de la requête : cas IJB sur Ville ... 66
Figure III-5 : Notre approche de sélection d’IJB et FH avec classification ... 69
Figure III-6 : Représentation graphique de la classification hiérarchique... 72
Figure III-7 : Centroïde d’une classe de trois données ... 73
Figure III-8 : Répartition des attributs en fonction de leurs poids ... 74
Figure III-9: Démarche de sélection d’un schéma de fragmentation ... 82
Figure III-10: Schéma en étoile d’un entrepôt de données ... 83
Figure III-11 : Codage d’un schéma de fragmentation ... 84
Figure III-12: Remplissage de la colonne « COL» dans les dimensions... 86
Figure III-13: Remplissage de la colonne « COL» pour ... 87
Figure III-14: Exemple de sous schéma après fragmentation ... 87
Figure III-15: Schéma d’entrepôt de données en étoile et fragmenté ... 88
Figure III-16: Démarche de sélection d’IJB ... 90
Figure IV-1: Architecture générale de l’outil AdminFIC... 94
Figure IV-2: Visualisation de l’état de l’entrepôt... 95
Figure IV-3: Choix de paramètre pour le génétique et k-means ... 95
Figure IV-4: Paramétrage de l’approche OAC ... 96
Figure IV-5: Résultats de sélection par OAC ... 96
Figure IV-6: Paramétrage de l’approche OS ... 96
Figure IV-7: Résultats de sélection par OS ... 97
Figure IV-8 : Schéma en étoile de l’entrepôt expérimental ... 97
Figure IV-9 : Répartition des attributs en fonction du poids de classification ... 98
Figure IV-10 : Coût d'exécution (E/S) pour différents modes ... 101
Figure IV-11 : Taux de requêtes optimisées ... 101
Figure IV-12 : Taux de réduction du coût de la charge de requêtes ... 101
Figure IV-13 : Effet de W sur le coût (E/S) ... 102
Figure IV-14 : Effet de W sur le taux d’optimisation des requêtes ... 102
Figure IV-15 : Comparaison entre OAC et OS par variation de l’espace de stockage ... 102
Figure IV-16 : Temps de sélection d’un schéma de FH (variation de W) ... 103
Figure IV-17 : Temps de sélection d’IJB (variation de W) ... 103
Figure IV-18 : Temps de sélection d’un schéma de FH (variation de S) ... 104
Figure IV-19 : Temps de sélection d’IJB (variation de S) ... 104
Figure IV-20 : différentes exécutions pour FH et IJB ... 104
Figure IV-21 : Optimisation selon la formulation du poids de classification ... 105
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 ... 20
Tableau II-1 : Synthèse de travaux sur les index ... 42
Tableau II-2 : Comparaison entre travaux de fragmentation... 53
Tableau II-3 : Représentation d’un codage d’une hiérarchie pour IJB encodé ... 56
Tableau III-1 : Calcul du poids des attributs dimension... 74
Tableau III-2 : Coordonnées des attributs dimension... 74
Tableau III-3 : Paramètres du modèle de coût pour la fragmentation ... 77
Tableau III-4 : Paramètres du modèle de coût pour les index ... 78
Tableau III-5 : Numérotation des fragments dimension... 86
Tableau IV-1 : Calcul du poids de classification ... 98
Tableau IV-2 : Schéma de fragmentation optimal pour OAC ... 99
Tableau IV-3 : Schéma de fragmentation optimal pour OS ... 99
Tableau IV-4 : Temps de réalisation des tests expérimentaux ... 102
Introduction générale
1
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
2 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.
3
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éfinitionTableau 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.
Données opérationnelles Données décisionnelles Type de données Orientées application, détaillées,
précises au moment de l’accès
Orientées activité (sujet), condensées, représentent des données historiques Opération Lecture, mise à jour, insertion et
suppression. 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
4 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.
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).
Source
hétérogènes Intégration, unification .
. Source 1
Source n Données Produit
Données Client
Données Vente Données orientées sujet
Chapitre I : Techniques d’optimisation des entrepôts de données
5 - 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.1.4.1 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 :
6 - 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.1.4.2 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).
Figure I-4 : Magasins de données (datamarts)
I.1.5 Implémentation d’un ED
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.1.5.1 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.1.5.2 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
Chapitre I : Techniques d’optimisation des entrepôts de données
7 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.
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
Figure I-6 : Modèle ROLAP : Schéma de données en flocon de neige Vente
Code_prod Code_temps
Code_rég Quantité Montant Produit
Code_prod Typeprod
Classe Nomprod
Couleur
Temps Code_temps
Année Mois Jours Région
Code_rég Ville Pays
Produit Code_prod
Typeprod Classe Nomprod
Couleur
Temps Code_temps
Jours Ventes
Code_prod Code_temps
Code_rég Quantité Montant
Jours Jours Mois Mois
Mois Années Région
Code_rég Ville Pays
Pays Ville
Ville Pays
Année Anné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
« Temps Jours Mois
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
c) Schéma en constellation
Figure I-7
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
illustré sur la figure I-7. Ce schéma comporte deux tables de fait «
« Approvisionnement ». Ces deux tables on les dimensions « La différence est que les ventes son
nécessitent la spécification du fournisseur.
I.1.5.3 Modèle MOLAP
Figure I-8 : Tableau multidimensionnel de données, modèle MOLAP Les systèmes de type MOLAP (
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 tablea
de données. Ce tableau possède trois dimensions, chacune est un axe d’analyse Produit
Code_prod Typeprod
Classe Nomprod
Couleur Fournisseur
Code_four RaisonSociale
Adresse
Alger Algérie Oran
France Paris
Région
Temps
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 «
Mois Années » et la dimension « Région » en «
». 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)
Schéma en constellation
: 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
7. Ce schéma comporte deux tables de fait «
». Ces deux tables on les dimensions « Produit » et «
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.
: 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 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
Code_temps Ventes
Code_ prod Code_temps
Code_rég Quantité Montant Approvisionnement
Code_prod Code_temps
Code_four Quantité Montant
Légende 10/01/2009 17/01/2009 03/02/2009 Alger
Algérie Oran Taref France Paris
Produit Temps
P1 P2 P3 P4
8 A la différence du schéma en étoile, le schéma en flocon de neige permet de normaliser les 6 montre la normalisation des dimensions « Temps » en
» en « Région Ville
». Cette normalisation réduit la redondance des données mais augmente le temps (Guerrero, 2002).
: 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 . Prenant le schéma en constellation 7. Ce schéma comporte deux tables de fait « Vente » et
» et « Temps » en communs.
t analysées par régions et que les faits d’approvisionnement
: Tableau multidimensionnel de données, modèle MOLAP
) 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
» pour le stockage d’un cube de données. Ce tableau possède trois dimensions, chacune est un axe d’analyse : « Région »
Temps Code_temps
Année Mois Jours
Région Code_rég
Ville Pays
Légende 10/01/2009 17/01/2009 03/02/2009
Chapitre I : Techniques d’optimisation des entrepôts de données
9
« 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.1.5.4 Comparaison des modèles d’implémentation
Modèle ROLAP MOLAP
Stockage de
données Schéma relationnel Tableau multidimensionnel
Accès aux données Lent (requêtes avec jointures en étoiles sur des tables volumineuses)
Direct et rapide (accès aux cases du tableau)
Coût de mise en œuvre
Aucun (exploitation des SGBD relationnels existants)
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 :
10 - 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’
Chapitre I : Techniques d’optimisation des entrepôts de données
11 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.2.1.1 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 100
200
Info Math
Alger Oran
10000 20000
Figure I-9 : Exemple d’index de jointure Employé
E_Id EID Ville natale 521
654 785
23 34 18
Alger Oran Alger Index de jointure
D_Id E_Id
100 100 200
521 785 654
12 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 Client
Id Mois Année
Vente Id
Age Genre
Pays Id_Temps
Id_ Client Id_ Produit
Produit Prix_Unit
Id Classe
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
1 2 3 4
30 25 15 45
M F M M
Algérie Syrie Liban Algérie
1 0 1 1
0 1 0 0 Figure I-12 : Exemple d’index bitmap
Chapitre I : Techniques d’optimisation des entrepôts de données
13 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
33 55 78 175
1 2 2 4
7580 1500 1200 5460
1 0 0 1
0 1 1 0 Figure I-13 : Exemple d’index bitmap de jointure 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 ;
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.2.1.2 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
14 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={v1,…,vn} un ensemble de vues.
- Q={Q1,…,Qm} 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.
Chapitre I : Techniques d’optimisation des entrepôts de données
15 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 Requête
CREATE MATERIALIZED VIEW VM AS SELECT *
FROM Vente V, Produit P
WHERE V.Id_Produit=P. Id AND P.Classe= ‘A’
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 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
