1
THÈSE DE DOCTORAT
Présentée par
ELhoussaine ZIYATI
Discipline : Sciences de l’ingénieur
Spécialité : Informatique et Télécommunications
Titre : Optimisation de requêtes OLAP en Entrepôts de Données
Approche basée sur la fragmentation génétique
Soutenue le : 08 Mai 2010
Devant le jury :
Président :
Driss Aboutajdine, PES, Faculté des Sciences Rabat
Examinateurs :
O. El Beqqali, PES, Faculté des Sciences de Fès
S. Ouatik El Alaoui, PH, Faculté des Sciences de Fès
R. Oulad Haj Thami, PES, ENSIAS Rabat
S. Mouline, PH, Faculté des Sciences Rabat
A. El Qadi, PA, EST de Meknès
UNIVERSITÉ MOHAMMED V –
AGDAL
FACULTÉ DES SCIENCES Rabat
N° d’ordre 2491
Faculté des Sciences, 4 Avenue Ibn Battouta B.P. 1014 RP, Rabat – Maroc Tel +212 (05) 37 77 18 34/35/38, Fax: +212 (05) 37 77 42 61, http://www.fsr.ac.ma
3
Avant propos
Les travaux présentés dans ce mémoire ont été effectués au Laboratoire de
Recherche en Informatique et Télécommunications, Unité associée au CNRST
de la Faculté des Sciences de Rabat –Université Mohammed V Agdal, Maroc,
Sous la direction du Professeur Driss Aboutajdine.
Je tiens à remercier :
Mr. Driss Aboutajdine, Professeur à la Faculté des Sciences de Rabat-Université
Mohammed V Agdal, pour la confiance qu’il m’a accordée en m’autorisant à
mener mes travaux de recherche dans ce laboratoire et d’avoir présidé ce jury de
thèse et pour l’intérêt qu’il a manifesté à ce travail en acceptant la charge de
suivre de près ces travaux. Je le remercie vivement pour sa disponibilité, son
soutien et ses encouragements.
Les rapporteurs sur ce travail : Mr. Omar El Beqqali, Professeur à la Faculté
des Sciences de Fès, et Mr. Said Ouatik Alaoui, Professeur à la Faculté des
Sciences de Fès, pour avoir accepté d’être rapporteur, et pour l’intérêt qu’ils ont
manifesté pour ce travail, et pour leurs observations qui ont contribué à
améliorer ce mémoire.
Mr. Rachid Oulad Haj Thami, Professeur à l’ENSIAS, Université Mohammed V
Agdal, pour l’honneur qu’il me fait en faisant partie de ce jury de thèse.
Mme Salma Mouline, Professeur à la Faculté des Sciences de Rabat, Université
Mohammed V Agdal, pour le grand honneur qu’il me fait en participant à ce
jury de thèse, et pour ses remarques qui ont permis d’améliorer la qualité de ce
mémoire.
4
Mr. Abderrahim El Qadi, Professeur à l’EST de Meknès, encadrant de ma thèse.
Je voudrais lui exprimer ma profonde reconnaissance pour l’aide qu’il m’a
constamment octroyée tout au long de ce travail.
Tous les membres du LRIT, Professeurs et Doctorants, pour leur esprit du
groupe. Qu’ils trouvent ici le témoignage de toute mon estime et ma sincère
sympathie.
Il m’est enfin agréable d’adresser ma profonde gratitude pour tous ceux
qui m’ont soutenu durant cette thèse, en particulier Mr. Ladjel Bellatreche, Mr.
Kamel Boukhalfa et Mr. Hammadi Bouslous. Qu’ils veuillent bien trouver ici le
témoignage de ma profonde reconnaissance.
Mes remerciements vont aussi à tous mes collègues dans les laboratoires LRIT,
en particulier, un grand merci à Mounir AIT KERROUM, Rachid SAADANE,
Ahmed FAQIHI, pour leurs aides et conseils.
Je remercie chaleureusement mes parents mes parent pour leur soutien et pour
leurs félicitations lors de mes réussites…
Enfin merci à ceux que je n’ai pu citer mais qui ont toutes mes amitiés et mes
remerciements.
6
Table des matières
CHAPITRE 1
: ENTREPOT DE DONNEES : MODELES ET TECHNIQUES
D’OPTIMISATION ... 19
1 Introduction ... 19
2 Architecture des entrepôts de données ... 19
2.1. Les caractéristiques des entrepôts de données ... 19
2.2. Architecture d’un système décisionnel ... 20
2.3. Fouille de données multidimensionnelles ... 23
2.4. Entrepôt et les bases de données relationnelles ... 24
3 Les modèles des entrepôts de données ... 26
3.1. La modélisation conceptuelle ... 26
3.1.1. Concept de fait, de dimension et de hiérarchie ... 27
3.1.2. Modèles en étoile, en flocon et en constellation ... 28
3.2. La modélisation logique... 30
4 Les techniques d’optimisation dans les entrepôts de données ... 32
4.1. Les techniques redondantes ... 32
4.1.1. Les vues matérialisées ... 32
4.1.2. Les index ... 33
4.2. Les techniques non redondantes ... 36
4.2.1. La fragmentation horizontale ... 36
4.2.2. La fragmentation horizontale dérivée ... 36
4.2.3. La fragmentation verticale ... 37
4.2.4. La fragmentation mixte (hybride) ... 37
5 Conclusion ... 38
CHAPITRE 2
: L’OPTIMISATION DE L’ENTREPOT DE DONNEES ... 40
1 Introduction ... 40
7
2.1. La sélection des vues ... 41
2.1.1. Algorithmes sans contraintes ... 42
2.1.1.1. Algorithme dans le contexte ROLAP ... 42
2.1.1.2. Algorithme dans le contexte MOLAP ... 47
2.1.2. Algorithmes avec contrainte ... 50
2.1.2.1. Contrainte d’espace ... 50
2.1.2.2. Contrainte du temps de maintenance ... 52
2.2. La maintenance des vues matérialisées ... 53
2.2.1. La maintenance incrémentale ... 54
2.2.2. La maintenance autonome ... 55
2.2.3. La maintenance en temps réel ... 56
3 Les fragmentations ... 56
3.1. Fragmentation verticale ... 56
3.1.1. Principe (problème de la fragmentation verticale) ... 57
3.1.2. Les algorithmes de la fragmentation verticale ... 58
3.2. Fragmentation horizontale ... 60 3.2.1. Position du problème ... 60 3.2.2. Principe de la fragmentation ... 61 3.2.3. Propriétés de la fragmentation ... 61 3.2.4. Les algorithmes de la FH ... 62 3.2.4.1. Algorithme glouton ... 62
3.2.4.2. Algorithme dirigé par contrainte ... 63
3.2.4.2.1. Algorithme basé sur la minimalité et la complétude des prédicats ... 64
3.2.4.2.2. Algorithme dirigé par les affinités des prédicats ... 67
3.3. La fragmentation dérivée ... 68
4 Conclusion ... 70
CHAPITRE 3
: ENTREPOT DE DONNEES ET ALGORITHMES
GENETIQUES ... 71
8
2 Concepts et principes des Algorithmes Génétiques ... 71
2.1. Stratégie évolutive ... 71
2.2. Principe de base ... 73
2.2.1. Codage d’individu ... 74
2.2.2. Génération de la population initiale ... 75
2.2.3. Evaluation ... 75
2.2.4. Sélection ... 77
2.2.5. Croisement ... 78
2.2.6. Mutation ... 80
2.2.7. Convergences des algorithmes génétiques ... 81
2.2.8. Limitations des algorithmes génétiques ... 82
3 Application des algorithmes génétiques à l’entrepôt de données ... 82
3.1. Processus génétique de la fragmentation horizontale ... 83
3.1.1. Codage adopté... 83
3.1.2. Représentation des fragments horizontaux ... 84
3.1.3. Sélection des individus ... 86
3.1.4. Types de croisements ... 87
3.2. Optimisation avec contrainte... 87
3.3. Mutation ... 89
4 Conclusion ... 90
CHAPITRE 4
: MISE EN ŒUVRE D’UN ALGORITHME GENETIQUE
POUR LA FRAGMENTATION MIXTE ... 91
1 Introduction ... 91
2 Présentation de notre approche : nouveau modèle d’optimisation avec les AGs ... 91
2.1. Processus génétique de fragmentation mixte ... 91
2.1.1. Codage d’individu ... 92
2.1.2. Sélection des individus ... 93
2.1.3. Croisement ... 93
9
2.1.5. Processus d’amélioration ... 95
2.1.6. Caractéristiques de notre algorithme ... 97
3 Evaluation globale de l’approche sur un benchmark ... 98
3.1. Banc d’essai Benchmark ... 98
3.2. Implémentation... 99
3.2.1. Pseudo code ... 100
3.2.2. Chargement de l’entrepôt ... 101
3.2.3. Types de requêtes prises en compte ... 102
3.3. Evaluation ... 103 3.3.1. Sans pénalisation ... 103 3.3.2. Avec pénalisation ... 108 4 Conclusion ... 111 5 Conclusion et perspectives ... 112 6 Références ... 115
10
Liste des figures
Figure 1.1 : L’entrepôt de données est la base des systèmes décisionnels ... 20
Figure 1.2 : Architecture et niveaux d’agrégation des données. ... 21
Figure 1.3 : Architecture simplifié d’un entrepôt de données ... 21
Figure 1.4 : La fouille de données et entrepôt de données ... 23
Figure 1.5 : Application d’une technique de datamining ... 24
Figure 1.6 : Exemple de cube de données (Ventes par ville)... 27
Figure 1.7 : Exemple de modélisation en étoile ... 28
Figure 1.8 : Exemple de modélisation en flocon de neige ... 29
Figure 1.9 : Exemple de modélisation en constellation ... 30
Figure 1.10 : Index de projection sur l’attribut Age. ... 34
Figure 1.11 : Index de jointure pour l’équi-jointure Département.ville = Employé.ville ... 35
Figure 1.12 : La fragmentation mixte suivant une relationR k Att Att Att
, 1, 2, 3
. ... 38Figure 2.1 : Les types de PSV ... 41
Figure 2.2 : Le processus de sélection des vues matérialisées. ... 42
Figure 2.3 : Principe de base de la sélection de [YLK, 97] ... 44
Figure 2.4 : Cube de données multidimensionnel. ... 47
Figure 2.5 : Exemple de requête... 48
Figure 2.6 : Treillis de vues ... 50
Figure 2.7 : Schéma d’un entrepôt de données ... 54
Figure 2.8 : Principe général de l’algorithme de [HN, 79] ... 60
Figure 2.9 : Processus de sélection des dimensions. ... 61
Figure 2.10 : Structure de l’algorithme glouton ... 63
Figure 2.11 : Les deux relations R (N.emp, Nom, Fonction) et S (Fonction, Salaire) ... 69
Figure 3.1 : Principe général des algorithmes génétiques ... 74
Figure 3.2 : Slicing crossover ... 78
Figure 3.3 : 3-point slicing Crossover. ... 79
Figure 3.4 : Mutation classique discrète ... 80
Figure 3.5 : Mutation continue ... 81
Figure 3.6 : Mutation adaptative ... 81
Figure 3.7 : Les SDSsdes attributs de fragmentation. ... 85
Figure 3.8 : Exemple de représentation de fragments dans le cas de trois attributs. ... 85
Figure 3.9 : Exemple de Mutation ... 89
Figure 4.1 : Codage de différents individus pour un chromosome vertical (schéma de fragmentation verticale) ... 93
Figure 4.2 : Croisement suivant la dimension Store... 94
Figure 4.3 : Exemple de mutation verticale ... 95
11
Figure 4.5 : Architecture du moteur générique ... 100
Figure 4.6 : Démarche de fragmentation proposée. ... 101
Figure 4.7 : Chargement de l’entrepôt de données ... 102
Figure 4.8 : Fenêtre d’exécution d’une requête sous Aqua data studio. ... 104
Figure 4.9 : Temps d’exécution des requêtes selon deux schémas (fragmenté et non fragmenté). ... 105
Figure 4.10 : La différence entre la fragmentation mixte proposée et horizontale. ... 106
Figure 4.11 : L’impact du nombre de fragments verticaux sur la performance... 107
Figure 4.12 : Cout total d’exécutions de l’ensemble suivant le nombre de partitions. ... 108
Figure 4.13 : Temps de réponse avec et sans pénalité ... 109
Figure 4.14 : L’impact du choix entre les trois modes de pénalité. ... 109
Figure 4.15 : La relation entre le coût total et le type de pénalité. ... 110
Figure 4.16 : Relation entre la valeur et le cout total d’exécution ... 110
12
Liste des tableaux
Tableau 1.1 : Différences entre SGBD et entrepôt de données ... 25
Tableau 1.2 : Comparaison des processus OLAP et OLTP ... 26
Tableau 2.1 : La description de l’algorithme [BLT, 86] ... 55
Tableau 2.2 : Relation Projet... 66
Tableau 3.1 : Exemple d’individu ... 85
Tableau 4.1 : Principaux paramètres des différents algorithmes ... 98
Tableau 4.2 : Taille des tables ... 99
13
Liste des algorithmes
Algorithme 1 : La sélection des vues selon [YKL, 97] ... 46
Algorithme 2 : La sélection des vues matérialisées selon [HRU, 96] ... 51
Algorithme 3 : Algorithme de génération des prédicats complets et simples ... 65
Algorithme 4 : Algorithme de fragmentation horizontale [OV, 91] ... 66
Algorithme 5 : Algorithme évolutionnaire typique ... 72
Algorithme 6 : Algorithme mixte proposé ... 92
Algorithme 7 : Algorithme de croisement pour la fragmentation verticale ... 94
14
Abréviations
SI : Système d’information
OLAP : On-Line Analytical Processing OLTP : On-Line Transaction Processing DW : Data Warehouse
AG : Algorithme Génétique
SGBD(R) : Système de Gestion de Base de données (Relationnel) MOLAP : Multidimensionnel OLAP
ROLAP : Relational OLAP OOLAP : Object OLAP
PSV : Problème de sélection des vues matérialisées SPJ : Sélection, Projection et Jointure
B.E.A : Bond Energy Algorithm AE : Algorithme Evolutionnaire EPS : Ensemble des prédicats simples SDS : Sous Domaine stable
IOC : Input Output Cost FS : Fragmentation Schème
j p F
Sel : Facteur de Sélectivité dans la table des faits pour le prédicat pj
FV : Fragmentation verticale FH : Fragmentation horizontale FM : Fragmentation mixe DM : Data Mining
PMEV : Plan multiple d’exécution des vues COM_MIN : Complet et Minimal
15
Introduction générale
L’informatique décisionnelle a connu et connaît aujourd’hui encore un essor important. Elle permet l’exploitation des données d’une organisation dans le but de faciliter la prise de décision.
Parmi les objectifs des entrepôts de données (Data Warehouse), la transformation d’un système d’information (SI) qui avait une vocation de production en SI décisionnel (c’est à dire la transformation des données de production en des informations stratégiques).
L’entrepôt de données est un ensemble de données destinées aux "décideurs", souvent ce sont des données de production avec des valeurs ajoutées (agrégation, intégrées et historisées). C’est aussi, un ensemble d'outils permettant de :
- regrouper, nettoyer, et intégrer les données, - Établir des requêtes, rapports, et analyses.
- Extraire de connaissances (fouille de données) et administration du warehouse.
Les SGBDs et DW ont des objectifs qui différent avec des traitements et stockage des données différentes et font l'objet également de requêtes différentes. Les SGBDs sont des systèmes dont le mode de travail est transactionnel (OLTP On-line Transaction Processing), permettant l'insertion, la modification, l’interrogation des informations avec efficacité et sécurité. Les deux objectifs principaux sont : en premier lieu la sélection, l’ajout, la mise à jour et la suppression des tuples, et en second lieu l’exécution de ces opérations. Ces tâches s’effectuent très rapidement et simultanément par de nombreux utilisateurs. Les DW sont des systèmes conçus pour l’aide à la prise de décision (OLAP On-Line Analytical Processing), fréquemment utilisés en lecture (utilisateurs), avec pour objectifs principaux de regrouper, d’organiser les informations provenant de sources diverses, les intégrer et les stocker pour donner à l’utilisateur une vue orientée métier, retrouver et analyser l’information avec facilité et rapidité.
Les entrepôts de données sont souvent modélisés par un schéma en étoile. Ce schéma est caractérisé par une table de faits de très grande taille (allant de quelques Gigaoctets à plusieurs Téraoctets) liée à un ensemble de tables de dimension de plus petite taille. La table des faits contient les clés étrangères des tables de dimension ainsi qu’un ensemble de mesures
16
collectées durant l’activité de l’organisation. Les tables de dimension contiennent des données qualitatives qui représentent des axes sur lesquels les mesures ont été collectées. Les requêtes de type OLAP définies sur un schéma en étoile (connues par requêtes de jointure en étoile) sont caractérisées par des opérations de sélection sur les tables de dimension, suivies de jointures avec la table des faits. Aucune jointure n’existe entre les tables de dimension. Toute jointure doit passer par la table des faits, ce qui rend le coût d’exécution de ces requêtes très important [Inm, 92] [Inm, 95]. Sans technique d’optimisation, leur exécution peut prendre des heures, voire des jours.
Plusieurs structures d’optimisation ont été proposées pour améliorer la performance de ces requêtes. Nous pouvons ainsi citer les vues matérialisées, les index, la fragmentation, le traitement parallèle. Ces techniques peuvent être classées en deux catégories :
- Des structures redondantes comme les vues matérialisées et les index du fait qu’elles nécessitent un espace de stockage et un coût de rafraîchissement.
- Des structures non redondantes comme la fragmentation (horizontale, verticale et hybride) ne nécessitant ni un coût d’espace de stockage ni un coût de rafraîchissement.
Ces techniques sont largement étudiées et utilisées dans les bases de données traditionnelles (relationnelles et orientées objets), dans le but de réduire le temps d’exécution des requêtes. La fragmentation est une technique de conception logique introduite dans les années 80 dans les bases de données réparties [CNP, 82], [CP, 84]. A travers le modèle relationnel, les stratégies de la fragmentation sont décrites : horizontale, verticale et hybride. Les relations étant des tables, il s’agit de trouver les différentes manières de diviser cette table en plusieurs petites tables. Le nombre de fragments est le degré de fragmentation défini en fonction des applications destinées à s’exécuter sur la base de données. Dans le contexte des entrepôts de données la fragmentation hybride et la fragmentation verticale n’ont pas eu le même succès que la fragmentation horizontale. Dans ce contexte, les travaux, présentés dans ce mémoire, constituent une investigation de l’optimisation par des techniques de calcul évolutif. Ces méthodes qui s’inspirent de métaphores biologiques (programmation génétique, algorithme génétique) offrent la possibilité de trouver des solutions optimales à des problèmes d’optimisation globale. Ces techniques de base ont été proposées initialement pour résoudre un type de problème donné. Par conséquent, pour pouvoir mettre en œuvre une telle méthode,
17
il est indispensable de l’adapter au problème à résoudre. Un bon réglage des paramètres est aussi exigé pour l’obtention de bonnes solutions.
De ce fait, un des objectifs principaux de ce travail consiste en la conception de nouvelles méthodes hybrides basées sur les Algorithmes Génétiques pour résoudre des problèmes complexes. Ces nouvelles méthodes tentent d'améliorer l'efficacité des algorithmes d'optimisation de base dans le contexte de l’entrepôt de données.
Par la suite, notre thèse sera articulée autour des points suivants :
Dans le premier chapitre, nous précisons le cadre de cette thèse en définissant les concepts de base de l’entrepôt de données. Nous effectuons un état de l'art concernant la recherche actuelle dans le domaine de l’optimisation dans les entrepôts de données relationnels.
Dans le deuxième chapitre, nous présentons les techniques d’optimisation des requêtes les plus utilisées dans le contexte de l’entrepôt de données. Nous mettons en évidence les problèmes liés à chaque technique, et nous présentons également les principales solutions et les algorithmes proposés dans le contexte de l’optimisation des requêtes.
Quant au troisième chapitre, il sera consacré à la description de l’optimisation génétique et les différentes étapes de ce processus. Nous décrivons, aussi, le processus d’évolution qu’il induit à travers la structure des différents opérateurs génétiques. Ensuite, Nous rapportons les principaux travaux d’application des algorithmes génétiques à l’entrepôt de données. Nous illustrons, le processus de fragmentation horizontale basé sur les algorithmes génétiques. Un bilan critique et préliminaire de cette approche est présenté, il sert de cadre de réflexions pour définir de nouvelles perspectives à nos travaux.
En ce qui concerne le quatrième chapitre, il présente notre contribution à la mise en œuvre d’un modèle hybride de fragmentation génétique. Nous y décrivons notamment nos motivations, caractéristiques fondamentales de l’AG d’optimisation de requêtes que nous proposons, fonctionnement général, structures et objectifs des opérateurs génétiques proposés. Enfin, On y présente également les résultats d’expérimentations réalisées dans le but de valider notre approche d’optimisation de requêtes. Cette évaluation a pour but de
18
mesurer l’efficacité de l’algorithme proposé et estimer l’impact de chacune de ses caractéristiques sur les résultats de la recherche.
En conclusion, nous dressons un bilan de nos travaux, et nous présentons ensuite les horizons d’évolution de ces travaux.
19
Chapitre 1 : Entrepôt de données : Modèles et techniques d’optimisation
1 Introduction
Comme cité précédemment, le concept Entrepôt de Données surgit à partir des besoins d’analyse des données d’une entreprise pour chercher des avantages compétitifs sur la concurrence. Les bases de données des systèmes existants de type « On-Line Transaction Processing » (OLTP) ne sont pas appropriées comme support de ces analyses parce qu’elles ont été conçues pour des fonctions spécifiques réalisées dans l’entreprise. Donc, les données pertinentes pour faire des analyses se trouvent disséminées entre plusieurs bases. De plus, leur conception vise à améliorer les performances des systèmes OLTP par rapport au traitement d’un grand nombre de transactions de mise à jour, ce qui complique l’interrogation.
Nous présentons dans ce chapitre un état de l’art portant sur l’architecture, et les différents modèles de conception des entrepôts de données. Enfin, nous décrivons les principales techniques d’optimisation utilisées qui ont été suggérés dans la littérature pour améliorer les performances des entrepôts de données.
2 Architecture des entrepôts de données
L’entrepôt de données joue un rôle stratégique dans la vie d’une entreprise. Il stocke des données pertinentes aux besoins de prise de décision en provenance des systèmes opérationnels de l’entreprise et d’autres sources externes.
2.1. Les caractéristiques des entrepôts de données
Un entrepôt de données, par contre, offre des données intégrées, consolidées et historisées pour faire des analyses (figure 1.1). Il s’agit d’une collection de données pour le support d’un processus d’aide à la décision.
Les données d’un entrepôt possèdent les caractéristiques suivantes :
Orientation sujet : Les données d’un entrepôt s’organisent par sujets ou thèmes. Cette organisation permet de rassembler toutes les données, pertinentes à un sujet et nécessaires aux besoins d’analyse, qui se trouvent répandues à travers les structures fonctionnelles d’une entreprise.
20
Intégration : Les données d’un entrepôt sont le résultat de l’intégration de données en provenance de multiples sources ; ainsi, toutes les données nécessaires pour réaliser une analyse particulière se trouvent dans l’entrepôt. L’intégration est le résultat d’un processus qui peut devenir très complexe du à l’hétérogénéité des sources.
Histoire : Les données d’un entrepôt représentent l’activité d’une entreprise pendant une longue période ou il est important de gérer les différentes valeurs qu’une donnée prises au cours du temps. Cette caractéristique donne la possibilité de suivre une donnée dans le temps pour analyser ses variations.
Non-volatilité : les données chargées dans l’entrepôt sont surtout utilisées en interrogation et ne peuvent pas être modifiées, sauf dans certains cas de rafraîchissement.
Figure 1.1 : L’entrepôt de données est la base des systèmes décisionnels
2.2. Architecture d’un système décisionnel
Les données d’un entrepôt se trouvent selon deux axes : synthétique et historique (figure 1.2). L’axe synthétique établit une hiérarchie d’agrégation et comprend les données détaillées (qui représentent les événements les plus récents au bas de la hiérarchie), les données agrégées (qui synthétisent les données détaillées) et les données fortement agrégées (qui synthétisent à un niveau supérieur les données agrégées) [ECM, 99]. L’axe historique comprend les données détaillées historiées, qui représentent des événements passés. Les Méta-données contiennent des informations concernant les données dans l’entrepôt de données, telle que leur provenance et leur structure, ainsi que les méthodes utilisées pour faire l’agrégation.
21
Figure 1.2 : Architecture et niveaux d’agrégation des données.
Dans la figure1.3 nous présentons une architecture simplifiée d’un entrepôt [DG, 01]. Les différents composants ont été intégrés dans trois parties : les sources de données, l’entrepôt et les outils existants dans le marché.
Figure 1.3 : Architecture simplifié d’un entrepôt de données
a) Les sources : Les données de l’entrepôt sont extraites de diverses sources souvent réparties et hétérogènes, et qui doivent être transformées avant leur stockage dans l’entrepôt. Nous avons deux types de sources des données : internes et externes à l’organisation.
22
Internes : La plupart des données sont saisies à partir des différents systèmes de production qui rassemblent les divers SGBD opérationnels, ainsi que des anciens systèmes de production qui contiennent des données encore exploitées par l’entreprise.
Externes : Ils représentent des données externes à l’entreprise et qui sont souvent achetées. Par exemple, les sources de données démographiques.
b) L’entrepôt de données :
Il existe plusieurs types de données dans un entrepôt,
qui correspondent à diverses utilisations, comme : Données de détail courantes : Ce sont l’ensemble des données quotidiennes et plus couramment utilisées. Ces données sont généralement stockées sur le disque pour avoir un accès rapide. Par exemple, le détail des ventes de l’année en cours, dans les différents magasins.
Données de détail anciennes : Ce sont des données quotidiennes concernant des événements passés, comme par exemple le détail des ventes des deux dernières années. Nous les utilisons pour arriver à l’analyse des tendances ou des requêtes prévisionnelles. Néanmoins ces données sont plus rarement utilisées que les précédentes, et elles sont souvent stockées sur des mémoires d’archives.
Données résumées ou agrégées : Ce sont des données moins détaillées que les deux premières et elles permettent de réduire le volume des données à stocker. Le type de données, en fonction de leur niveau de détail, permet de les classifier comme des données légèrement ou fortement résumées. Par exemple, les ventes mensuelles par magasin des dix dernières années sont des données faiblement résumées, tandis que les ventes semestrielles, par région, des dix dernières années sont fortement résumées.
Les méta-données : Ce sont des données essentielles pour parvenir à une exploitation efficace du contenu d’un entrepôt. Elles représentent des informations nécessaires à l’accès et l’exploitation des données dans l’entrepôt comme : la sémantique (leur signification), l’origine (leur provenance), les règles d’agrégation (leur périmètre), le stockage (leur format, par exemple : francs, euro,...) et finalement l’utilisation (par quels programmes sont-elles utilisées).
23
c) Outils : Il existe sur le marché différents outils pour l’aide à la décision, comme les outils de fouille de données (pour découvrir des liens sémantiques), outils d’analyse en ligne (pour la synthèse et l’analyse des données multidimensionnelles), outils d’interrogation (pour faciliter l’accès aux données en fournissant une interface conviviale au langage de requêtes),... [CD, 97], [DG, 01].
2.3. Fouille de données multidimensionnelles
L’extraction de connaissances dans les bases de données désigne le processus d’extraction d’informations précédemment inconnues et potentiellement utiles concernant les données stockées dans les bases de données (figure 1.4) [PS, 91]. L’analyse par exemple des transactions de vente d’un supermarché permettra d’étudier les habitudes des clients, en fonction de quoi il sera possible de réorganiser les rayons afin d’améliorer les ventes.
Figure 1.4 : La fouille de données et entrepôt de données
Les données d’entrepôts enregistrées sont subies à une opération d’orpaillage où datamining qui est par définition la recherche de la connaissance. Il existe plusieurs techniques d’orpaillage, telle que les algorithmes génétiques, l’induction d’arbres de décision et les réseaux de neurones. La figure 1.5 montre l’application d’une technique d’orpaillage à un ensemble de données. Dans ce cas, il s’agit d’induire, à partir de n-uplets en entrée, un modèle de classification sous la forme d’un arbre de décision. L’algorithme appliqué a conduit un arbre dont l’attribut le plus important pour distinguer un n-uplet d’un autre est PRODUIT et dans un deuxième niveau, MAGAZIN. Dans cette figure, il est possible d’observer que, quelque soit la localisation du magasin et l’année, la vente des TV est élevée. En revanche, la vente de radio dépend de la localisation du magasin.
24
Figure 1.5 : Application d’une technique de datamining
2.4. Entrepôt et les bases de données relationnelles
Dans l’environnement des entrepôts de données, les opérations, l’organisation des données, les critères de performance, la gestion des méta-données, la gestion des transactions et le processus de requêtes sont très différents des systèmes de bases de données opérationnels. Par conséquent, les SGBDR orientés vers l’environnement opérationnel, ne peuvent pas être directement transplantés dans un système d’entrepôt de données [WMB, 97].
Les SGBDs ont été créés pour gérer de grands volumes d’information contenus dans les différents systèmes opérationnels qui appartiennent à l’entreprise. Ces données sont manipulées en utilisant des processus transactionnels en ligne [Cod, 93]. Par contre, les entrepôts de données ont été conçus pour l’aide à la prise de décision. Ils intègrent les informations qui ont pour objectif de fournir une vue globale de l’information aux analystes et aux décideurs.
Parallèlement à l’exploitation de l’information contenue dans ces systèmes opérationnels, les dirigeants des entreprises ont besoin d’avoir une vision globale concernant toute cette information pour faire des calculs prévisionnels, des statistiques ou pour établir des stratégies de développement et d’analyses des tendances.
Le tableau 1.1 résume ces différences entre les systèmes de gestion de bases de données et les entrepôts de données [DG, 01].
25
SGBD Entrepôt de données
Objectifs Gestion et production Consultation et analyse
Utilisateurs Gestionnaire de production Décideurs, analystes Taille de la base Plusieurs Gigaoctets Plusieurs Téraoctets
Organisation de données Par traitement Par métier
Types de données Données de gestion (courantes)
Données d’analyses (résumées, historisées)
Requêtes Simples, prédéterminées,
Données détaillées
Complexes, spécifiques Agrégations et group by
Tableau 1.1 : Différences entre SGBD et entrepôt de données
La conception ou la modélisation d’un entrepôt est très différente de celle des bases de données des systèmes de type OLTP, parce qu’il faut penser en terme de concepts plus ouverts et plus difficiles à définir. De plus, les besoins des utilisateurs de l’entrepôt ne sont pas clairs que ceux des utilisateurs des systèmes OLTP.
Les bases de données de type OLTP (On-Line Transaction Processing) permettent de gérer des données variées et de réaliser des transactions sur ces données (lectures, mises à jour, etc.). La fouille de données a une forte relation avec OLAP, dont les objectifs sont similaires, mais il faut cependant souligner une différence essentielle (tableau 1.2). OLAP traite les données, alors que le Datamining vise également à extraire des connaissances de ces données. Le tableau 1.2 compare les caractéristiques des processus OLTP et OLAP.
26
Processus OLTP Processus OLAP
Données Exhaustives Courantes Dynamiques Orientées applications Résumées Historiques Statiques
Orientées sujets (d’analyse)
Utilisateurs
Nombreux
Variés (employés, directeurs…..) Concurrents
Mise à jour et interrogations Requêtes prédéfinies Réponses immédiates Accès à peu d’information
Peu nombreux
Uniquement les décideurs Non concurrents
Interrogations
Requêtes imprévisibles et complexes Réponses moins rapides
Accès à de nombreuses informations.
Tableau 1.2 : Comparaison des processus OLAP et OLTP
3 Les modèles des entrepôts de données
Pour arriver à construire un modèle approprié pour un entrepôt de données, nous pouvons choisir, soit un schéma relationnel (le schéma en étoile, en flocon de neige ou en constellation) ; soit un schéma multidimensionnel.
3.1. La modélisation conceptuelle
La conception des bases de données est en général basée sur le modèle Entité Association (E-R). Ce modèle permet de décrire des relations entre les données élémentaires (entités) éliminant des redondances, ce qui provoque l’introduction d’un nombre important de nouvelles entités.
De ce fait, l’accès aux données devient compliqué et le diagramme généré difficile à comprendre pour un utilisateur. C’est pour cette raison que l’utilisation de la modélisation E-R pour la conception d’un entrepôt n’est pas considérée comme approprié. Avant de décrire les différents schémas, nous commençons par quelques concepts de base.
27
3.1.1. Concept de fait, de dimension et de hiérarchie
Le modèle multidimensionnel est une alternative mieux adéquate aux besoins de l’analyse des données d’un entrepôt. La modélisation multidimensionnelle part du principe que l’objectif majeur est la vision multidimensionnelle des données. Le constructeur fondamental de ces modèles est le cube de données (figure 1.6), qu’offre une abstraction très proche de la façon dont l’analyste voit et interroge les données. Il organise les données en une ou plusieurs dimensions1, Qui déterminent une mesure d’intérêt ou bien le fait2. Une dimension spécifie la manière dont on regarde les données pour les analyser, alors qu’une mesure est un objet d’analyse. Chaque dimension est formée par un ensemble d’attributs et chaque attribut peut prendre différentes valeurs. Les dimensions possèdent en général des
hiérarchies3 associées qui organisent les attributs à différents niveaux pour observer les données à différentes granularités. Une dimension peut avoir plusieurs hiérarchies associées, chacune spécifiant différentes relations d’ordre entre ses attributs.
On peut alors observer les données dans un espace à trois dimensions : la dimension ville, la dimension produit et la dimension temps. Chaque intersection de ces dimensions représente une cellule comportant le montant des ventes.
Figure 1.6 : Exemple de cube de données (Ventes par ville)
1
Une dimension modélise une perspective de l'analyse. Une dimension se compose de paramètres correspondant aux formations faisant varier les mesures de l'activité
2
Le fait modélise le sujet de l'analyse. Un fait est formé de mesures correspondant aux informations de l'activité analysée
3
28
3.1.2. Modèles en étoile, en flocon et en constellation
A partir du fait et des dimensions, il est possible d'établir une structure de données simple qui correspond au besoin de la modélisation multidimensionnelle. Cette structure est constituée du fait central et des dimensions (figure 1.7). Ce modèle représente visuellement une étoile, on parle de modèle en étoile.
Il se compose du fait central et de leurs dimensions. Dans ce schéma il existe une relation pour les faits et plusieurs pour les différentes dimensions autour de la relation centrale. La relation de faits contient les différentes mesures et une clé étrangère pour faire référence à chacune de leurs dimensions.
La figure 1.7 montre le schéma en étoile en décrivant les ventes réalisées dans les différents magasins de l’entreprise au cours d’un jour. Dans ce cas, nous avons une étoile centrale avec une table de faits appelée Ventes et autour leurs diverses dimensions : Temps, Produit et Magasin.
Figure 1.7 : Exemple de modélisation en étoile
Il existe d'autres techniques de modélisation multidimensionnelle, notamment la modélisation en flocon (snowflake). Une modélisation en flocon est une extension de la modélisation en étoile, il consiste à garder la même table des faits et à éclater les tables de dimensions afin de permettre une représentation plus explicite de la hiérarchie [JLS, 99]. Elle peut être vue comme une normalisation des tables de dimensions. L’avantage du schéma en flocon de neige est de formaliser une hiérarchie au sein d’une dimension, ce qui peut faciliter l’analyse. Un autre avantage est représenté par la normalisation des dimensions, car nous
29
réduisons leur taille. Néanmoins dans [Kim, 96], l’auteur démontre que c’est une perte de temps de normaliser les relations des dimensions dans le but d’économiser l’espace disque. Par contre, cette normalisation rend plus complexe la lisibilité et la gestion dans ce type de schéma. En effet, ce type de schéma augmente le nombre de jointures à réaliser dans l’exécution d’une requête.
Les hiérarchies pour le schéma en flocon de neige de l’exemple de la figure 1.7 sont : Dimension Temps = Jour → Mois → Année
Dimension Magasin = Commune → Département → Région → Pays.
La figure 1.8 montre le schéma en flocon de neige avec les dimensions Temps et Magasin éclatées en sous hiérarchies.
Figure 1.8 : Exemple de modélisation en flocon de neige
Dans l’exemple ci-dessus, la dimension Temps a été éclatée en deux, Temps et T_Mois. La deuxième dimension Magasin, à été décomposée en trois : Magasin, M_Département et M_Région.
Le schéma en constellation représente plusieurs relations de faits qui partagent des dimensions communes. Ces différentes relations de faits composent une famille qui partage les dimensions mais où chaque relation de faits a ses propres dimensions [BCA, 01].
La figure 1.9 montre le schéma en constellation qui est composé de deux relations de faits. La première s’appelle Ventes et enregistre les quantités de produits qui ont été vendus
30
dans les différents magasins pendant un certain jour. La deuxième relation gère les différents produits achetés aux fournisseurs pendant un certain temps.
Figure 1.9 : Exemple de modélisation en constellation
La relation de faits Ventes partage leurs dimensions Temps et Produits avec la table Achats. Néanmoins, la dimension Magasin appartient seulement à Ventes. Egalement, la dimension Fournisseur est liée seulement à la relation Achats.
3.2. La modélisation logique
Au niveau logique, plusieurs possibilités sont envisageables pour la modélisation multidimensionnelle. Il est possible d'utiliser :
- un système de gestion de bases de données existant tels que les SGBD relationnels (ROLAP) ou bien les SGBD orientés objet (OOLAP).
- un système de gestion de bases de données multidimensionnelles (MOLAP). L'approche la plus couramment utilisée consiste à utiliser un système de gestion de bases de données relationnelles, on parle de l'approche ROLAP ("Relational On-Line Analytical Processing"). Le modèle multidimensionnel est alors traduit de la manière suivante:
Chaque fait correspond à une table, appelé table de fait,
Chaque dimension correspond à une table, appelée table de dimension.
Ainsi, la table de fait est constituée des attributs représentant les mesures d’activités et les attributs clés étrangers de chacune des tables de dimension. Les tables de dimension
31
contiennent les paramètres et une clé primaire permettant de réaliser des jointures avec la table de fait.
Plus récemment, une autre approche s’appuie sur le paradigme objet ; on parle de l’approche OOLAP (« Object On-Line Analytical Processing»). Le modèle multidimensionnel se traduit ainsi :
Chaque fait correspond à une classe, appelée classe de fait,
Chaque dimension correspond à une classe, appelée classe de dimension. Pour décrire les expressions qui décrivent le schéma en étoile ou en flocon, on utilise le langage de définition standard des bases de données orientées objet défini par (Object Data Management Group) l’ODMG4.
Une alternative à ces deux approches consiste à utiliser un système multidimensionnel. Les systèmes de type MOLAP stockent les données dans un SGBD multidimensionnel sous la forme d’un tableau multidimensionnel. Chaque dimension de ce tableau est associée à une dimension du cube. Seules les valeurs de données correspondant aux données de chaque cellule sont stockées (figure 1.6). Ces systèmes demandent un pré-calcul de toutes les agrégations possibles. En conséquence, ils sont plus performants que les systèmes traditionnels, mais difficiles à mettre à jour et à gérer.
Les systèmes MOLAP apparaissent comme une solution acceptable pour le stockage et l’analyse d’un entrepôt lorsque la quantité estimée des données d’un entrepôt ne dépasse pas quelques giga-octets. Mais, lorsque les données sont éparses, ces systèmes sont consommateurs d’espace [CD, 97] et des techniques de compression doivent être utilisées. L'intérêt est que les temps d'accès sont optimisés, mais cette approche nécessite de redéfinir des opérations pour manipuler ces structures multidimensionnelles, parmi elles utilisées sont : Pivot : Cette opération consiste à faire effectuer à un cube une rotation autour d’un des trois axe passant par le centre de deux faces opposées, de manière à présenter un ensemble de faces différents.
4
32
Switch : Cette opération consiste à interchanger la position des membres d’une dimension.
Split : Elle consiste à présenter chaque tranche du cube, et à passer d’une représentation tridimensionnelle d’un cube à sa représentation sous la forme d’un ensemble de tables. D’une manière générale, cette opération permet de réduire le nombre de dimensions d’une représentation. On notera que le nombre de tables résultant d’une opération Split dépend des informations contenues dans le cube de départ et n’est pas connu à l’avance.
4 Les techniques d’optimisation dans les entrepôts de données
Le processus d’analyse de données s’appuie souvent sur des requêtes qui regroupent et filtrent des données de différentes formes. Compte tenu de la nature interactive des entrepôts de données, la nécessité d’avoir un temps de réponse rapide est un objectif critique pour l’utilisateur et/ou le décideur. Des délais trop longs sont inacceptables dans la plupart des systèmes décisionnels, puisqu’ils peuvent diminuer la productivité. L’exigence courante est un temps de réponse ne dépassant pas quelques secondes ou quelques minutes. Sans technique d’optimisation de requêtes, l’interrogation d’un entrepôt de données serait complexe, et le traitement de ces requêtes pourrait prendre des heures.
Les travaux concernant l’optimisation des performances des requêtes décisionnelles sont principalement basés sur des techniques héritées des bases de données relationnelles/objets. Nous pouvons les classées suivant deux catégories :
Techniques redondantes
Techniques non redondantes4.1. Les techniques redondantes 4.1.1. Les vues matérialisées
Dans l’environnement d’un entrepôt de données, il est généralement possible d’isoler un ensemble de requêtes à privilégier. L’ensemble des vues matérialisées doit être déterminé en fonction de cet ensemble de requêtes [Ull, 96].
33
- Pré-calculer toutes les vues : Cette approche consiste à matérialiser la totalité du cube dans le cas MOLAP, tandis que dans le type ROLAP, elle consiste à matérialiser tous les nœuds intermédiaires des arbres algébriques représentant les requêtes. Cependant, stocker et maintenir toutes les cellules ou nœuds intermédiaires pose un problème dans le cas d'un gros entrepôt.
- Ne matérialiser aucune vue : Cette solution ne présente aucun intérêt en ce qui concerne les performances des requêtes.
- Matérialiser uniquement une partie des cubes ou des nœuds : Dans un cube, nous ne sommes pas obligé de matérialiser toutes les vues, c’est à cause de la dépendance entre les cellules, c'est à dire que les valeurs contenues dans certaines d’entre elles peuvent être réutilisées à partir des valeurs d'autres cellules. De même pour ROLAP, on trouve également cette dépendance dans les arbres algébriques. Il est alors souhaitable de matérialiser les sous-ensembles communs (cellules ou nœuds) à plusieurs requêtes. Cette approche a pour but de sélectionner les cellules ou les nœuds partagés. C’est la solution idéale en comparaison aux deux autres possibilités.
Au niveau de la conception physique, l’administration de l’entrepôt de données doit sélectionner des index afin d’accélérer l’exécution des requêtes de type OLAP. Ce problème est connu sous le nom de problème de sélection des vues matérialisées (PSV). De nombreux travaux ont été réalisés pour résoudre le PSV [Gup, 97] et [KR, 99].
4.1.2. Les index
Les techniques d’indexation utilisées dans les bases de données de type OLTP ne sont pas parfaitement adaptées aux environnements des entrepôts de données. En effet, la plupart des transactions OLTP accèdent à un nombre faible de n-uplets et les techniques utilisées sont adaptées à ce type de situation. Les requêtes décisionnelles dans le cas des entrepôts de données accèdent au contraire à un très grand nombre de n-uplets. Réutiliser les techniques des systèmes OLTP conduirait à des index avec un grand nombre de niveaux.
Un index peut être défini sur une seule ou sur plusieurs colonnes d’une relation, Ce type d’index est appelé mono-index. Il existe également des index définis sur deux relations comme les index de jointure qui sont appelés multi-index. Dans les entrepôts de données, les
34
deux types d’index sont utilisés : index sur liste de valeur, index de projection (mono-index) et index de jointure en étoile (star join index) pour les index multi-index.
Exemple d’index de projection :
Soit C la colonne d’une table à indexer. L’index de projection (voir figure 1.10) sur C est constitué par une séquence des valeurs de C, ces dernières apparaissent dans le même ordre que le numéro des n-uplets dans la table d’origine.
Table client Index de projection
Nom Age …. Sexe Age
Driss 20 …. M 20 Layla 42 …. F 42 Jamal 21 …. M 21 Mounir 52 …. M 52 Alia 18 …. F 18 Karima 17 …. F 17 Hassan 36 …. M 36
Figure 1.10 : Index de projection sur l’attribut Age.
Les requêtes complexes définies sur une base de données relationnelles demandent fréquemment des opérations de jointures entre plusieurs tables. L’opération de jointure est fondamentale dans les bases de données et est très coûteuse en terme de temps de calcul lorsque les tables concernées sont de grande taille, comme le cas des entrepôts de données. Plusieurs méthodes ont été proposées afin d’accélérer ces opérations. Ces méthodes incluent, les boucles imbriquées, le hachage et la fusion.
Un index de jointure matérialise les liens entre deux relations par le biais d’une table à deux colonnes contenant les RowID (identifiant des n-uplets) des n-uplets joints deux à deux [PV, 87]. Cet index peut être vu comme une jointure pré-calculée. Créé à l’avance, il est implémenté par une relation d’arité 2 (figure 1.11). L’efficacité dépend du coefficient de sélectivité de jointure. Si la jointure a une forte sélectivité, l’index de jointure sera de taille
35
faible et aura une grande efficacité. Ce genre d’index est parfaitement adapté pour les requêtes des systèmes OLTP parce qu’elles possèdent fréquemment des jointures entre deux tables.
Par contre, pour les entrepôts de données modélisés par un schéma en étoile, ces index sont limités. En effet, les requêtes décisionnelles définies sur un schéma en étoile possèdent plusieurs jointures (entre la table des faits et les tables de dimensions). Il faut dans ce cas subdiviser la requête en fonction des jointures. Or le nombre de jointures possibles est de l’ordre de N! (Nétant le nombre de tables à joindre).
Figure 1.11 : Index de jointure pour l’équi-jointure Département.ville = Employé.ville
Afin de résoudre ce problème, un nouvel index appelé index de jointure en étoile (star join index) a été introduit [Sys, 97], et adapté aux requêtes définies sur un schéma en étoile. Un index de jointure en étoile peut contenir toute combinaison de clés étrangères de la table des faits. Il peut être n’importe quelle combinaison contenant la clé de la table des faits et une ou plusieurs clés primaires des tables de dimensions. Ce type d’index est dit complet s’il est construit en joignant toutes les tables de dimensions avec la table des faits. Un index de jointure partiel est construit en joignant certaines tables de dimensions avec la table des faits. En conséquence, l’index complet est bénéfique pour n’importe quelle requête posée sur le schéma en étoile. Il exige cependant beaucoup d’espace de stockage.
Deux remarques concernant l’index de jointure:
• Ce type d’index est exclusivement adapté aux schémas en étoile et par conséquent, il ne l’est pas pour les schémas en flocon.
36
• Il n’existe pas d’algorithme de sélection d’index de jointure en étoile pour un ensemble de requête.
De même que pour les PSV, au niveau de la conception physique, l’administration de l’entrepôt de données doit sélectionner des index afin d’accélérer l’exécution des requêtes. Ce problème est connu sous le nom de problème de sélection d’index (PSI), plusieurs solutions ont été proposées [CN, 98] [CN, 99].
4.2. Les techniques non redondantes
4.2.1. La fragmentation horizontale
La fragmentation horizontale a été étudiée dans le cadre des bases de données relationnelles. Elle consiste à diviser une relation R en sous ensembles de n-uplets appelés fragments horizontaux, chacun étant défini par une opération de restriction appliquée à la relation. Les n-uplets de chaque fragment horizontal satisfait une clause de prédicats5. Le schéma de fragmentation de la relation R est donné par :
1 1 cl H R ,
2 2 cl H R , ...,
q q clH R , où cl est une clause de prédicats. La reconstruction de la relation R à partir i de ces fragments horizontaux est obtenue par l’opération d’union de ces fragments.
La fragmentation horizontale se décline en deux versions [CNP, 82] : les fragmentations primaires et dérivées (ou indirecte [GGT, 96]). La fragmentation primaire d’une relation est effectuée grâce à des prédicats de sélection définis sur la relation [OV, 91], voir chapitre 2.
4.2.2. La fragmentation horizontale dérivée
La fragmentation horizontale primaire favorise le traitement des requêtes de restriction portant sur les attributs utilisés dans le processus de la fragmentation. La fragmentation horizontale dérivée est utile pour le traitement des requêtes de jointure, voir chapitre 2.
5
37
4.2.3. La fragmentation verticale
Dans la fragmentation verticale, une relation est divisée en sous relations appelées fragments verticaux où chaque fragment contient un sous–ensemble des attribues de la relation et sa clé.
Soit une relationR k A A
, 1, 2,...,A , avec n attributs n
A A1, 2,...,A et une clé K . Chaque n attribut A a un domaine de valeurs que nous appelonsi dom A . La fragmentation verticale
i de la relation R est donnée par :
1 1 1 1 1 , 1, 2,..., k V k A A A ,
2 2 2 2 2 , 1, 2,..., k V k A A A , ...,
, 1 , 2 ,..., p
p p p p kV k A A A où chaque attribut i
1, 2,...,
j n
A A A A
.
Les fragments verticaux 1, 2,..., pV V V sont disjoints si chaque attribut Ai
1 i n
de la relation R appartient à un et un seul fragment vertical. La clé K est dupliquée dans chaque fragment afin de faciliter la reconstruction de la relation R à partir de ces fragments qui est réalisée par la jointure de p fragments verticaux. La fragmentation verticale favorise naturellement le traitement des requêtes de projection [OQ, 97] portant sur les attributs utilisés dans le processus de la fragmentation, en limitant le nombre de fragments à accéder.4.2.4. La fragmentation mixte (hybride)
La fragmentation mixte (figure 1.12) combine les deux types de fragmentation : horizontale et verticale. Elle consiste à partitionner une relation en sous-ensembles de sous relations, ces dernières étant définies par la fragmentation verticale et les sous-ensembles par la fragmentation horizontale.
38
Figure 1.12 : La fragmentation mixte suivant une relationR k Att Att Att
, 1, 2, 3
.5 Conclusion
Dans ce chapitre, nous avons présenté un état de l’art sur les entrepôts de données et les principales techniques d’optimisation de requêtes définies dans le contexte des entrepôts de données relationnels.
Mieux encore, nous avons traité le sujet des entrepôts de données qui étendent les concepts et la technologie traditionnelle des bases de données, pour créer des systèmes d’aide à la décision. En exploitant l’architecture d’un entrepôt de données, nous avons expliqué les différents composants qu’il intègre, comme les diverses sources, les types de données et les différents outils pour arriver à la visualisation de l’information. En dernier lieu, nous avons décrit les différents modèles multidimensionnels pour la construction d’un entrepôt de données, ainsi que quelques différentes opérations pour la manipulation des données multidimensionnelles.
Nous passerons en revue dans le chapitre suivant quelques techniques et algorithmes utilisés afin de réduire le coût d’exécution des requêtes OLAP.
40
Chapitre 2 : L’optimisation de l’Entrepôt de données
1 Introduction
La taille des entrepôts de données peut varier de quelques giga-octets à plusieurs téraoctets dont la majorité des données sont stockée dans un nombre restreint de grandes tables de faits. Ces données sont dédiées aux applications d'analyse et de prise de décisions. Ce processus d'analyse est réalisé à l'aide de requêtes complexes comportant de multiples jointures et des opérations d'agrégation sur des tables volumineuses. En dépit de leur complexité, les preneurs de décisions souhaitent que leurs requêtes soient satisfaites le plus rapidement possible. Les principales techniques utilisées pour répondre à ce besoin sont : les vues matérialisées, les index et la fragmentation.
Dans ce chapitre, nous allons détailler les principaux algorithmes qui ont été suggérés dans la littérature pour améliorer les performances des entrepôts de données, en précisant les différents processus avec les avantages et inconvénients de chaque proposition.
2 Les vues matérialisées
Une des techniques d’optimisation des performances est la création de vues matérialisées. Par définition, une vue matérialisée est une table contenant les résultats d'une requête pré calculée. Les vues améliorent l'exécution des requêtes en pré calculant les opérations les plus coûteuses telles que la jointure et l'agrégation, et en stockant leurs résultats dans la base. En conséquence, certaines requêtes nécessitent uniquement l'accès aux vues matérialisées, permettant ainsi d’être exécutées plus rapidement.
Les vues peuvent être utilisées pour satisfaire plusieurs objectifs, comme l’amélioration de la performance des requêtes. L’utilisateur applique les requêtes sur les tables de la base de données et le mécanisme de réécriture les réécrit automatiquement de façon à utiliser la ou les vues matérialisées contenant les données requises. Ce mécanisme améliore considérablement le temps de réponse des requêtes. De plus, il est transparent pour l’utilisateur qui n’a pas besoin de connaître l’existence ou non de vues matérialisées.
Deux problèmes majeurs sont liés aux vues matérialisées : La sélection des vues.
41
2.1. La sélection des vues
Dans l'environnement d'un entrepôt de données, il est généralement possible d'isoler un ensemble de requêtes à privilégier. L'ensemble des vues matérialisées doit donc être déterminé en fonction de cet ensemble de requêtes.
Le problème de sélection des vues matérialisées (PSV) peut être abordé sous deux angles différents en fonction du type de modèle de données adopté (figure 2.1):
Le PSV de type ROLAP. Le PSV de type MOLAP.
Figure 2.1 : Les types de PSV
Dans la présentation cubique (PSV dans MOLAP), chaque cellule du cube présente une vue potentielle. Notons que les vues matérialisées à ce niveau ne sont que des requêtes ayant des agrégations sur les relations de base.
Dans le PSV de type ROLAP, chaque requête est représentée par un arbre algébrique. Chaque nœud (non feuille) est considéré comme une vue potentielle. Ce type de PSV est plus général que le premier.
Ce problème de sélection peut être décrit comme suit, quel que soit le type :
Etant donné une contrainte de ressource S (capacité de stockage, par exemple), le PSV consiste à sélectionner un ensemble de vues
V V1, 2,...,V minimisant une fonction k
42
objectif (coût total d'évaluation des requêtes et/ou coût de maintenance des vues sélectionnées) et satisfaisant la contrainteS (figure 2.2)
.
Figure 2.2 : Le processus de sélection des vues matérialisées.
De nombreux algorithmes ont été développés pour élaborer une solution optimale ou quasi optimale pour le PSV. La plupart de ces algorithmes étaient destinés au cas statique comme nous allons le voir dans les sections suivantes.
Les algorithmes proposés pour la sélection des vues peuvent être classés en trois catégories, en fonction du type de contrainte qu'ils utilisent :
Les algorithmes sans aucune contrainte.
Les algorithmes dirigés par une contrainte.2.1.1. Algorithmes sans contraintes
Plusieurs algorithmes sont proposés pour la sélection des vues sans contraintes. Nous allons présenter deux, qui sont l’approche de [YKL, 97] proposée dans le contexte ROLAP, et l’approche de [BPT, 1997] proposée dans le contexte MOLAP.
43
Les auteurs [YKL, 97] ont développé un algorithme de sélection de vues dans un contexte ROLAP statique6. Ils partent du principe suivant : la principale caractéristique des requêtes décisionnelles est qu'elles utilisent souvent les résultats de certaines requêtes afin de répondre à d'autres requêtes. On peut tirer de cette caractéristique que les requêtes partagent certaines expressions. [YKL, 97] ont formulé le problème de sélection de vues (PSV) comme suit:
- Soit un entrepôt de données modélisées par un schéma relationnel ayant d tables de dimensions et une table de fait.
- Soit Q
Q Q1, 2,...,Qn
un ensemble de requêtes d'interrogation (les plus fréquentes) avec leur fréquence d’accès
f f1, 2,...,fn
.- Soit U
U U1, 2,...,Un'
un ensemble de requêtes de mise à jour (les plus fréquentes) avec leur fréquence d’accès
g g1, 2,...,gn'
.
Le PSV consiste à sélectionner un ensemble de vues minimisant la somme des coûts d’évaluations des requêtes et de maintenance des vues sélectionnées. Les étapes principales sont :
Première étape : a pour but de construire un arbre algébrique pour chaque requête de l’ensembleQ
Q Q1, 2,...,Qn
, par la suite on choisit pour chacun l’arbre optimal
7.
Exemple : soit un schéma d’entrepôt ayant cinq tables de dimensions et sur lequel
trois requêtes décisionnelles définies. La figure 2.3 montre que les requêtes Q et 1 Q ont une 2 expression commune (Exp1). Ces nœuds sont de bons candidats pour la matérialisation.
6
PSV statique : Le PSV statique consiste à sélectionner un ensemble de vues à matérialiser afin de minimiser le coût total d’évaluation des requêtes, le coût de maintenance, ou les deux, sous la contrainte de la ressource. Le problème suppose donc que l’ensemble des requêtes n’évolue pas contrairement au PSV dynamique.
7
Arbre optimal : optimal (évalué en fonction des coûts). L'existence de plusieurs arbres algébriques est due aux propriétés des opérations algébriques (appelées règles de transformation des arbres). Ces règles sont au nombre de huit: la commutativité des jointures, l'associativité des jointures, le groupement des restrictions, la commutativité des restrictions et des projections, la commutativité des restrictions et des jointures, la commutativité des restrictions et des unions ou des restrictions et des différences, la commutativité des projections et des jointures, et enfin la commutativité des projections et des unions.
44
Figure 2.3 : Principe de base de la sélection de [YLK, 97]
Deuxième étape : a pour but la génération du PMEV (Plan Multiple d’Exécution des Vues). Suite à l'obtention des graphes optimaux, les sous expressions communes sont identifiées, puis les graphes de requêtes ayant des sous expressions communes sont fusionnés en PMEV. Un PMEV est un graphe orienté, acyclique et étiqueté, dont la structure est définie par (N, A), où N et A représentent les ensembles de nœuds et d'arcs du graphe dont les constructions se réalisent de la façon suivante :
Pour chaque opération dans l'arbre algébrique de la requêteQi
1 i n
, v N
T v est la table générée par le nœud v . T v est une table de base, un résultat intermédiaire
d’exécution d’une requête, ou le résultat final d'une requête. Pour tout nœud feuillev , T v
correspond à la table de base. Pour tout nœud racine v (le nœud qui n'a pas d'arc sortant),
T v correspond au résultat de la requête globale. Soit R, et L l'ensemble des feuilles et des
nœuds racines. Si la table de base ou le résultat intermédiaire T v correspondant à un nœud
v est demandé pour un traitement au niveau d'un nœudv , introduire un arc' vv'.Pour tout nœudv , soit S v l'ensemble des nœuds origines des arcs pointant vers v .
Si v ;L S v
.Soit S*
