THÈSE DE DOCTORAT Présentée par ELhoussaine

UNIVERSITÉ MOHAMMED V –
AGDAL
FACULTÉ DES SCIENCES Rabat
N° d’ordre 2491
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
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
1
2
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.
3
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.
4
5
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.
3.2.
4
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
La modélisation logique...................................................................................... 30
Les techniques d’optimisation dans les entrepôts de données ................... 32
4.1.
4.2.
5
La modélisation conceptuelle.............................................................................. 26
Les techniques redondantes ................................................................................ 32
4.1.1.
Les vues matérialisées ........................................................................................ 32
4.1.2.
Les index ........................................................................................................... 33
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
Conclusion ...................................................................................................38
CHAPITRE 2 : L’OPTIMISATION DE L’ENTREPOT DE DONNEES ....... 40
1
Introduction .................................................................................................40
2
Les vues matérialisées ................................................................................. 40
6
2.1.
La sélection des vues .......................................................................................... 41
2.1.1.
2.1.1.1.
Algorithme dans le contexte ROLAP............................................................... 42
2.1.1.2.
Algorithme dans le contexte MOLAP .............................................................. 47
2.1.2.
2.2.
3
Algorithmes sans contraintes .............................................................................. 42
Algorithmes avec contrainte ............................................................................... 50
2.1.2.1.
Contrainte d’espace ....................................................................................... 50
2.1.2.2.
Contrainte du temps de maintenance .............................................................. 52
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
Les fragmentations ...................................................................................... 56
3.1.
3.2.
Fragmentation verticale ...................................................................................... 56
3.1.1.
Principe (problème de la fragmentation verticale) ............................................... 57
3.1.2.
Les algorithmes de la fragmentation verticale ..................................................... 58
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.
4
La fragmentation dérivée .................................................................................... 68
Conclusion ...................................................................................................70
CHAPITRE 3 : ENTREPOT DE DONNEES ET ALGORITHMES
GENETIQUES ................................................................................................ 71
1
Introduction .................................................................................................71
7
2
Concepts et principes des Algorithmes Génétiques ...................................71
2.1.
Stratégie évolutive .............................................................................................. 71
2.2.
Principe de base .................................................................................................. 73
3
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
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
AGs
Présentation de notre approche : nouveau modèle d’optimisation avec les
...................................................................................................................... 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
2.1.4.
Mutation ............................................................................................................ 95
8
3
2.1.5.
Processus d’amélioration .................................................................................... 95
2.1.6.
Caractéristiques de notre algorithme ................................................................... 97
Evaluation globale de l’approche sur un benchmark ................................ 98
3.1.
Banc d’essai Benchmark ..................................................................................... 98
3.2.
Implémentation................................................................................................... 99
3.3.
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
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
9
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 relation R  k , Att1 , Att2 , Att3  . ................... 38
Figure 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 SDSs des 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
Figure 4.4 : Schéma de l’entrepôt utilisé APB benchmark..................................................... 99
10
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
Figure 4.17 : Effet du nombre de dimensions sur le coût total d’exécution. ......................... 111
11
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
12
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
Algorithme 8 : Opération de mutation................................................................................... 95
13
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
p
SelF j
: Facteur de Sélectivité dans la table des faits pour le prédicat
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
14
pj
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
15
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,
16
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
17
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.
18
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.
19

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.
20
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.
21

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).
22
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.
23
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].
24
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
Données d’analyses
(courantes)
(résumées, historisées)
Simples, prédéterminées,
Complexes, spécifiques
Données détaillées
Agrégations et group by
Requêtes
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.
25
Données
Processus OLTP
Processus OLAP
Exhaustives
Résumées
Courantes
Historiques
Dynamiques
Statiques
Orientées applications
Orientées sujets (d’analyse)
Nombreux
Peu nombreux
Variés (employés, directeurs…..) Uniquement les décideurs
Utilisateurs
Concurrents
Non concurrents
Mise à jour et interrogations
Interrogations
Requêtes prédéfinies
Requêtes imprévisibles et complexes
Réponses immédiates
Réponses moins rapides
Accès à peu d’information
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 ER 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.
26
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
3
Le fait modélise le sujet de l'analyse. Un fait est formé de mesures correspondant aux informations de l'activité analysée
Une hiérarchie organise les paramètres d'une dimension selon un ordre conformément à leur niveau de détail
27
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
28
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
29
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
30
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
www.odmg.org
31
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 redondantes
4.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].
Il existe 3 possibilités pour sélectionner un ensemble de vues [Ull, 96] :
32
-
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
33
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
Nom
Index de projection
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
34
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.
35
• 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 : H1   cl1  R  , H 2   cl2  R  ,
..., H q   clq  R  , où cli est une clause de prédicats. La reconstruction de la relation R à partir
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
Une clause de prédicats est une combinaison de prédicats avec les opérateurs
36
 et 
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 relation R  k , A1 , A2 ,..., An  , avec n attributs A1 , A2 ,..., An et une clé K . Chaque
attribut Ai a un domaine de valeurs que nous appelons dom  Ai  . La fragmentation verticale
de la relation R est donnée par :


V p k , A1p , A2p ,..., Akpp où
chaque




V1 k , A11 , A21 ,..., Ak11 , V2 k , A12 , A22 ,..., Ak22 , ...,
attribut Aij   A1 , A2 ,..., An  .
Les
fragments
verticaux
V1 , V2 ,..., V p 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.
37
Figure 1.12 : La fragmentation mixte suivant une relation R  k , Att1 , Att2 , Att3  .
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.
38
39
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.

La maintenance des vues matérialisées.
40
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 V1 ,V2 ,...,Vk  minimisant une fonction
41
objectif (coût total d'évaluation des requêtes et/ou coût de maintenance des vues
sélectionnées) et satisfaisant la contrainte S (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.
2.1.1.1.
Algorithme dans le contexte ROLAP
42
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  Q1, Q2 ,..., Qn  un ensemble de requêtes d'interrogation (les plus fréquentes)
avec leur fréquence d’accès  f1 , f 2 ,..., f n  .
-
Soit U  U1 ,U 2 ,...,U n ' un ensemble de requêtes de mise à jour (les plus
fréquentes) avec leur fréquence d’accès  g1, g 2 ,..., g n ' .
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’ensemble Q  Q1 , Q2 ,..., Qn  , par la suite on choisit pour chacun l’arbre optimal7.
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 Q1 et Q2 ont une
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.
43
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ête Qi 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 feuille v , 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œud v ' , introduire un arc v  v ' .
Pour tout nœud v , soit S  v  l'ensemble des nœuds origines des arcs pointant vers v .
Si v  L ; S  v    .
Soit S *  v  l'ensemble des descendants de v . Pour tout v  N , Cqi  v  est le coût
d'exécution de la requête Qi accédant à T  v  , lorsque T  v  est matérialisée, Cu j  v  est le coût
44
de maintenance de T  v  causé par la requête de mise à jour Uj et basé sur les changements de
base S *  v   L .
Nous avons vu que en fonction des types d'opérations relationnelles (sélection,
projection et opérations ensemblistes), le PMEV peut être divisé en quatre niveaux (figure
2.3) :
Les feuilles sont les tables de dimension de l’entrepôt et représentent le niveau 0. Dans le
niveau 1, nous trouvons des nœuds représentant les résultats des opérations algébriques de
sélection et de projection. Dans le niveau 2, les nœuds représentent les opérations
ensemblistes comme la jointure, l'union, etc. Le dernier niveau représente les résultats de
chaque requête. Chaque nœud intermédiaire de ce graphe est étiqueté par le coût de
l'opération algébrique (sélection, jointure, union, etc.) et le coût de maintenance. Ce graphe
est utilisé pour rechercher l'ensemble des vues dont la matérialisation minimise la somme des
coûts d'évaluation des requêtes et de maintenance des vues. La solution prend en
considération l'existence de plusieurs expressions possibles pour une requête. Chaque nœud
intermédiaire est considéré comme une vue potentielle.
Troisième étape : attribution des coûts
Avant de définir ces coûts, quelques notations sont introduites :

Ov dénote l’ensemble des requêtes utilisant le nœud v ; Ov  R  D *  v  avec
R représentant l’ensemble des nœuds racines et D *  v  l’ensemble des ascendants de v .

I v dénote l’ensemble des tables de base utilisées pour produire v ;
I v  L  S *  v  avec L est l’ensemble des feuilles et S *  v  est l’ensemble descendants de v .

V est l’ensemble des vues matérialisées.

A chaque nœud est associé un poids statique w(v ) représentant le bénéfice si le
nœud v est matérialisé. Ce poids est donné par la formule suivante :
w v 
  f  C v    g
i
Qi Ov
Qi
jI v
45
j
 CU j  v 

(2.1)
Ce poids est utilisé pour ordonner les nœuds du PMEV, le nœud ayant la plus grande
valeur sera privilégié pour la matérialisation.

O 'v dénote les requêtes globales qui utilisent v , excluant celles qui peuvent
utiliser les ascendants de v déjà sélectionnés. O 'v  Ov  Ou avec u V  D *  v  .

Cs dénote le poids dynamique d'un nœud, est donné par :
Cs 


CQi  v )    g r  CU j  v 
uSv v
 rIv

  f  (C  v   
i
Qi O 'v
Qi


(2.2)
La première partie de la formule précédente représente le bénéfice si v est matérialisée.
La deuxième partie est le coût de maintenance de la vue v .

Ce terme
CQi  v  est un facteur dupliqué dans le cas où quelques descendants de v ont
uSv v
été choisis pour la matérialisation.
Quatrième étape : sélection des vues
Cette étape consiste à ordonner les nœuds de PMEV en fonction de leur poids statique w  v  ;
ensuite, on calcule leur poids dynamique. Si Cs  0 , v est matérialisée (algorithme 1).
Algorithme 1 : La sélection des vues selon [YKL, 97]
1.
V : 
2.
créer la liste
3.
prendre le 1er élément v de LV .
4.
Calculer Ov ,
5.
Calculer
6.
If
LV de tous les nœuds ayant des poids positifs (dans l’ordre descendant)
I v et Cv
Cs
Cs  0 then
7.
Insérer v dans M
8.
Retirer v de
9.
LV
Else
Retirer v des nœuds listés après v dans
10.
11.
End if
12.
Repeat
13.
Etape 3
46
LV et qui sont dans la même branche.
LV  
 la liste est vide.
14.
Until
15.
v V si D  v   M , alors Retirer v de V .
2.1.1.2.
Algorithme dans le contexte MOLAP
L’algorithme de [BPT, 97] est proposé pour un contexte multidimensionnel,
concernant la sélection des vues matérialisées à base de treillis. Un cube de données
multidimensionnel est composé de cellules présentant des mesures observées aux croisements
des dimensions. La figure 2.4 montre un exemple de cube composé de la mesure sale
observée suivant les trois dimensions customers, times et products. Dans chaque cellule
 c, t , p 
de ce cube est stocké le montant des ventes du produit p acheté au mois t par le
client c . Dans ce cube, on peut être amené à observer les ventes d'un produit p pour un client
c donné. La valeur ALL , ajoutée au domaine de chaque dimension, a été proposée pour
répondre à la requête d’agrégation.
Cet exemple montre que les valeurs (mesures) de plusieurs cellules sont calculables à partir
d'autres cellules du même cube. De telles cellules sont appelées dépendantes. Par exemple, les
valeurs
des
 p, ALL, c 
cellules

peuvent
être
calculées

cellules  p, t1 , c  ,..., p, t t , c , où t désigne la cardinalité de la dimension t .
Figure 2.4 : Cube de données multidimensionnel.
47
à
partir
des
Toute cellule ayant la valeur ALL est dite dépendante. Sa valeur peut donc être
calculée à partir d'autres cellules. En revanche, si une cellule ne comporte pas la valeur ALL ,
elle ne peut pas être calculée à partir d'autres cellules. Les cellules sont organisées dans
différents ensembles suivant la position de la valeur ALL dans leur adresse. Par exemple,
toutes les cellules  , ALL,   sont placées dans le même ensemble. Chacun de ces ensembles
correspond à une requête SQL. Par exemple, la requête SQL de la Figure 2.5 prend ses
résultats dans l'ensemble des cellules  p, ALL, c  . La table R de la clause From contient
l'ensemble de toutes les cellules. Chaque requête est ainsi caractérisée par les attributs de la
clause Group by. Par exemple, la requête de la figure 2.5 est caractérisée par (products,
customers).
Select
Products, Customers, sum (sales)
From Relation
Group by
Products, Customers
Figure 2.5 : Exemple de requête
Sélectionner les ensembles de cellules à matérialiser revient à décider quelles requêtes
SQL ou vues à matérialiser. Ce problème a été formalisé sous forme de treillis capturant les
relations existantes entre les vues, requêtes ou cellules [HRU, 96]. Cette technique consiste à
élaborer un treillis qui exploite les hiérarchies des attributs (par exemple : quartier → ville →
pays), de plus il est possible de déterminer à partir de quel niveau d'agrégation il n'est plus
pertinent de matérialiser. Nous donnons dans la suite quelques définitions utilisées pour
formaliser le problème de sélection de vues.
Définition 1 : On dit que Qi  Q j
si et seulement si Qi peut être évaluée en utilisant
seulement les résultats de la requête Q j .
48
Par exemple, la vue (products) peut être résolue en utilisant la vue (products, customers) car
(products)  (products, customers). D'autres vues ne sont pas comparables en utilisant
l’opérateur  , Par exemple, (products) et (customers). L'opérateur  forme alors un ordre
partiel sur l'ensemble des vues. L'ensemble des vues muni de l'opérateur  a été modélisé
sous forme d'un treillis.
Définition 2 : Un treillis noté par L V ,   , est formé par un ensemble de vues V et
l'opérateur  défini précédemment. La borne supérieure du treillis correspond à la vue dont
laquelle toutes les vues sont dépendantes (la totalité du cube) et sa borne inférieure
correspond à la vue générée en agrégeant complètement les données de n'importe quelle vue
du treillis.
Les nœuds de ce treillis représentent les vues V (agrégées sur certaines dimensions),
tandis qu’un arc existe entre deux nœuds Vi et V j si celles-ci sont dépendantes Vi  V j  . Le
nœud Vi est un nœud ancêtre et V j un descendant. Les ancêtres et les descendants d'un nœud
Vi du treillis sont définis comme suit :
Ancêtre ( Vi ) = { V j | Vi  V j }
Descendant ( Vi ) = { V j | V j  Vi }
On considère le treillis des vues possibles pour une base de 3 tables de dimensions (P :
Product ; T : time ; C : client) figure 2.6.
On dit qu’une vue Vi du treillis est une vue candidate si une des conditions suivantes
est satisfaite :

Vi est associé à quelques requêtes.

Il existe deux vues candidates V j et Vk telle que Vi est la plus petite borne
supérieure de V j et Vk (le coût de mise à jour des vues V j et Vk est supérieur à celui de Vi ).
49
Figure 2.6 : Treillis de vues
Une fois que les vues candidates sont sélectionnées, le bénéfice pour chaque nœud descendant
est recalculé et la vue de bénéfice maximal est sélectionnée. Pour conclure sur ce type
d'algorithme, nous pouvons dire qu'étant donné l'absence de contrainte qui leur est liée, il
n'existe aucun moyen d'évaluer leurs résultats.
2.1.2.
Algorithmes avec contrainte
Plusieurs modèles de coût ont été développés pour optimiser le compromis espacetemps lorsque le treillis de vues est implémenté. Le problème est approché selon trois points
de vue :

optimiser le temps ;

optimiser l'espace de stockage ;

optimiser le temps tant que la contrainte d'espace de stockage n'est pas atteinte.
Le coût d'exécution d'une requête est assimilé au nombre de n-uplets lus pour répondre
à cette requête. En absence d'index construits sur la vue exploitée par une requête, le coût de
cette dernière est égale au nombre de n-uplets que contient cette vue.
2.1.2.1.
Contrainte d’espace
Plusieurs modèles de coût ont été proposés pour évaluer l'exploitation d'une vue et par
conséquent le bénéfice qu'elle apporte. Le coût de stockage des vues a aussi été estimé pour
satisfaire la contrainte d'espace.
50
[HRU, 96] ont présenté un algorithme glouton pour sélectionner un ensemble de
cellules (vues) dans un cube de données. L’objectif de cet algorithme est de minimiser le
temps de réponse des requêtes sous la contrainte que la taille des vues sélectionnées ne
dépasse pas la capacité d’espace S . Les auteurs s’intéressent seulement aux requêtes ayant des
fonctions d’agrégation. Ils ont modélisé le problème sous la forme d'un treillis de vues,
représenté en figure 2.6, et ont développé un modèle de coût afin d'estimer le coût de chaque
vue du treillis. Ce coût est basé sur le principe suivant :
Pour évaluer une requête Q (vue), nous choisissons une vue ancêtre de Q (disons Qa ),
qui a été matérialisée. Le coût d'évaluation de la requête Q est le nombre de tuples présents
dans la table correspondante à Qa . Chaque vue est associée à un coût de
stockage
correspondant au nombre de tuples de cette vue.
Soit C  v  le coût d'une vue v . Le bénéfice B  v, S  apporté par la vue v , sachant qu'un
ensemble S est préalablement sélectionné, est le seuil à ne pas dépasser.
1.
Pour chaque vue w  v , définir la quantité Bw :
a. Soit u la vue de plus petit coût telle que w  u
b. Si C  v   C  u  , alors B  w   C  u   C  v  . sinon B  w  0 .
2.
B  v, S    B  w 
w u
L’algorithme est alors le suivant :
Algorithme 2 : La sélection des vues matérialisées selon [HRU, 96]
1: déclaration: A (la capacité d’espace), | v | (la taille de la vue v )
2: while  A  0  do
3:
v : vue ayant un bénéfice maximal;
4:
if  A | v | 0  then
5:
V : V  v ;
6:
A  A | v | ;
7:
V : l'ensemble des vues
end if
51
8: end while
En d'autre terme, le bénéfice de V est calculé en considérant sa contribution dans la
l'évaluation des requêtes. Pour chaque vue w couvrant v , nous calculons le coût d'évaluation
w en utilisant v et d'autres vues dans S offrant un coût moins élevé pour évaluer w . Si le coût
de la vue v est inférieur au coût de w , alors la différence représente une partie du bénéfice de
la matérialisation de la vue v .
Le bénéfice total B  v, S  est la somme de tous les bénéfices en utilisant v pour évaluer w , et
fournissant un bénéfice positif. Les auteurs montrent que cet algorithme présente des
performances très proches de l'optimum. Cependant, il parcourt l'espace des solutions
possibles à un niveau élevé de granularité et peut éventuellement laisser échapper de bonnes
solutions [BPT, 97].
2.1.2.2.
Contrainte du temps de maintenance
Pour les algorithmes dirigés par le temps de maintenance, nous citons les travaux de
[GM, 99]. Le problème de sélection de vues consiste à sélectionner un ensemble de vues afin
de minimiser le temps de réponse des requêtes de manière à ce que le temps de maintenance
des vues sélectionnées ne dépasse pas un seuil fourni par l'utilisateur.
Ces algorithmes supposent que les requêtes qui sont l'objet de l'optimisation sont
connues à priori. Dans ce cas, le problème de sélection de vues est qualifié de statique. Si une
évolution des requêtes est enregistrée, alors il est nécessaire de reconsidérer le problème de
sélection de vues en reconstruisant les vues à matérialiser. La sélection devient alors
dynamique. Dans ce contexte, nous pouvons citer le système DynaMat de [KR, 99], qui
rafraîchit les vues sélectionnées si la taille de ces dernières dépasse la capacité de l'espace de
stockage allouée par l'administrateur suite aux opérations de mise à jour. Il procède alors à
certaines éliminations selon des critères de remplacement. Par exemple, les vues les moins
utilisées sont éliminées.
Plus formellement, si V  v1 , v2 ,..., vn  est un ensemble de vues candidates,
Q  q1 , q2 ,..., qm  un ensemble de requêtes et S la taille de l’espace disque réservé par
52
l’administrateur pour stocker les vues à sélectionner, alors il faut trouver une configuration de
vues configV telle que :

Le coût d’exécution des requêtes de la charge soit minimal, c’est-à-dire :
CoutConfigV  Q   min  CoutV  Q  
Avec CoutV  Q  : le coût de l’ensemble Q
sachant V .


L’espace de stockage de configV ne dépasse pas S (seuil d’espace) :
taille  v   S
vConfigV
2.2. La maintenance des vues matérialisées
Un entrepôt de données contient un ensemble de vues matérialisées dérivées à partir
de tables qui ne résident pas dans l’entrepôt de données. Les tables de base changent et
évoluent au rythme des mises à jour. Cependant, si ces changements ne sont pas reportés dans
les vues matérialisées, leurs contenus deviendront obsolètes et leurs objets ne représenteront
plus la réalité. Par conséquent, un objet d’une vue peut continuer à exister alors que les objets
ayant servi à la création des vues ont été modifiés ou supprimés. Afin de résoudre ce
problème d’inconsistance des données, la solution le plus intuitive serait de recalculer la vue,
mais ce type de traitement reste toujours le plus coûteux pour un DW.
Trois stratégies fondamentales ont été proposées :

Dans la première, les vues sont mises à jour périodiquement [LHM, 86]; dans
ce cas ces vues peuvent être considérées comme des photographies ("snapshots").

Dans la seconde [BLT, 86], les vues sont mises à jour immédiatement à la fin
de chaque transaction.

Dans la dernière, les modifications sont propagées d’une manière différée [SP,
89]. Dans ce cas, une vue est mise à jour uniquement au moment où elle est utilisée par une
requête d’un utilisateur.
La maintenance permet de recalculer le contenu des vues matérialisées à partir des tables
sources. Cependant, cette approche est complètement inefficace (très coûteuse). En effet, une
bonne maintenance des vues est réalisée lorsque les changements (insertions, suppressions,
53
modifications) effectués dans les tables sources peuvent être propagés aux vues sans être dans
l’obligation de recalculer intégralement leurs contenus. Plusieurs techniques ont été proposées
dans la littérature afin de répondre à ce besoin : la maintenance incrémentale, la maintenance
autonome des vues et la maintenance des vues en batch.
2.2.1.
La maintenance incrémentale
La maintenance incrémentale qui se propose de répercuter les mises à jour survenues
au niveau des données sources sans recalculer complètement les vues. Cette maintenance
consiste à identifier le nouvel ensemble de n-uplets à ajouter à la vue dans le cas d’une
insertion ou le sous-ensemble de n-uplets à retirer de la vue dans le cas d’une suppression.
Plusieurs approches traitent le problème de la maintenance incrémentale des vues
matérialisées ont été développées dans les bases de données relationnelles et entrepôts de
données [RSS, 96]. Nous en retenons, les travaux de [BLT, 86] dans le contexte des bases de
données puisque la plus part des contributions traitent celui de la maintenance des bases de
données relationnelles et/ou Objet (figure 2.7).
Figure 2.7 : Schéma d’un entrepôt de données
Les auteurs s’intéressent aux vues SPJ (Sélection, Projection et Jointure). Dans un
souci de clarté, nous présentons l’algorithme incrémental pour les vues de jointures (qui
s’étend aux vues SPJ ). Soit V   R1  R2  ...  Rn  une vue joignant n relations.
Supposons que l’on insère les ensembles de n-uplets Ri dans les relations Ri , i  1,...., n ,
respectivement.
54
D’après la propagation de ces insertions au niveau de la vue V , nous
obtenons V '   R1  R1   R2  R2   ....   Rn  Rn   . En appliquant la propriété de
la distributivité de la jointure sur l’union, la mise à jour de V est égale à l’union de 2n multijointures. Les auteurs ont montré que pour maintenir la vue V de façon incrémentale, il est
facile d’obtenir toutes les multi-jointures de V ' grâce à une table de vérité dont chaque entrée
Bi 1  i  n  est associée à une relation Ri de la vue.
Bi 

1, correspond aux nouveaux n-uplets (Ri )
0, correspond aux anciens
Exemple : supposons que n  3 V  R1  R2  R3  , l’ensemble de toutes les multijointures est décrit dans le tableau 2.1 suivant :
Tableau 2.1 : La description de l’algorithme [BLT, 86]
Supposons que R3 ne soit pas mise à jour, nous devons donc évaluer l’expression suivante :
 R1  R2  R3    R1  R2  R3    R1  R2  R3  .
La même procédure est
appliquée dans le cas de suppression de n-uplets, en respectant la propriété de la distributivité
de la jointure par rapport à la différence.
2.2.2.
La maintenance autonome
Considérons un schéma d’un entrepôt de données ayant un ensemble de tables de base
T  T1 , T2 ,..., Tn  . Soit V une vue matérialisée calculée à partir d’une table Ti . Supposons
qu’un changement Ti intervienne au niveau de Ti . La vue V est dite à maintenir d’une
manière autonome si elle peut être maintenable en utilisant seulement la vue V et les
changements Ti de Ti .
55
Parmi les solutions proposées pour garantir la maintenance autonome, est celle qui nécessite
la duplication entière de toutes les données de la base dans l’entrepôt de données. Le
processus de maintenance des vues devient alors local à l’entrepôt. Toutefois, cette technique
génère un nouveau problème au niveau de l’entrepôt de données qui se traduit par
l’augmentation de l’espace de stockage pour loger les données dupliquées et entraîne une
redondance d’informations.
2.2.3.
La maintenance en temps réel
Une opération de maintenance est relativement longue et peut donc interrompre
l’usage de l’entrepôt. Dû à cette raison elle est exécutée durant les périodes d’activité creuse
(la nuit par exemple), c’est le cas pour les systèmes commerciaux, la mise à jour s’effectue en
batch par l’intermédiaire de transactions de maintenance.
3 Les fragmentations
La fragmentation est une technique de conception logique. Dans la littérature, deux termes
sont utilisés pour la segmentation d’une relation : partitionnement et fragmentation. Comme
précédemment énoncé, le partitionnement d’une relation se définit par la division de cette
dernière en plusieurs partitions disjointes. La fragmentation consiste en la division en
plusieurs fragments (sous-ensembles de la relation) qui peuvent être non disjoints. Deux
sortes de fragmentation sont possibles : la fragmentation horizontale et la fragmentation
verticale.
3.1. Fragmentation verticale
Telle qu’elle est déjà définie, la fragmentation verticale d’une relation R répartie les
attributs de la relation afin de générer plusieurs tables R1 , R2 ,..., Rk  , contenant chacun un
sous-ensemble des attributs de R en plus de la clé primaire de R. Elle permet d’accélérer
l’exécution des requêtes décisionnelles, et élimine la duplication des données en stockant
l’index et non les colonnes indexées, cela permet de réduire l’espace nécessaire pour ces
index.
56
Dans la littérature, nombreux travaux ont été proposés pour définir les fragments
verticaux, en se basant sur les affinités des attributs [NR, 89], ou un modèle de simulation
[HN, 79].
3.1.1.
Principe (problème de la fragmentation verticale)
La fragmentation verticale représente un enjeu plus important dans les entrepôts que
dans un contexte de base de données relationnelles ou objets. Cette importance est due au
choix des tables (de dimensions ou des faits) à fragmenter. Les choix possibles sont les
suivants :

Fragmenter verticalement une ou les tables de dimensions. Ce choix pourrait
être intéressant pour le cas où la taille des tables de dimensions est importante (le cas d’un
schéma en étoile). Cette fragmentation pourrait réduire le coût des opérations de jointures en
étoile.

Partitionner seulement la table de faits. Celle-ci est composée des clés
étrangères des tables de dimensions et des mesures. La fragmentation verticale possible de la
table de faits consiste à fragmenter l’ensemble des mesures en différents fragments. Les clés
étrangères seront dupliquées dans chaque fragment vertical.
Dans le présent travail nous optons pour le premier choix. Plus formellement, et selon [ZBB,
07] dans le contexte d’entrepôt de données, le problème de fragmentation verticale peut être
formalisé de la façon suivante : étant donné : (1) un ensemble de tables de dimension
D  D1 , D2 ,..., Dd  et une table de faits F , (2) un ensemble de requêtes OLAP fréquentes
Q  Q1 , Q2 ,..., Qm  ,où chaque requête Qi 1  i  m  possède une fréquence d’accès f Qi , et
(3) un seuil
M 
qui représente le nombre de fragments verticaux que l’administrateur
souhaiterait avoir. Le problème consiste à (1) déterminer un ensemble de tables de dimension
à fragmenter, et (2) fragmenter une ou des tables de dimension de façon à ce que le coût total
d’exécution des requêtes sur le schéma en étoile fragmenté soit réduit et que le nombre de
fragments verticaux ne dépasse pas le seuil M .
57
3.1.2.
Les algorithmes de la fragmentation verticale
Une première approche est celle présentée par [NCW, 84], qui suppose une relation
ayant m attributs à fragmenter et un ensemble de n requêtes les plus fréquentes. Elle
s’exécute en deux phases : Durant la première phase, trois matrices sont construites : la
matrice d’usage des attributs, la matrice des affinités des attributs et la matrice d’affinité
ordonnée.
-
Dans la matrice d’usage des attributs, la valeur de l’élément de la ligne i et de
la colonne j a pour valeur 1 si l’attribut j est accédé par la requête i, sinon cette valeur est
nulle. Cette matrice est complétée par des valeurs de fréquences d’accès pour chacune des
requêtes représentées dans une colonne supplémentaire.
-
La matrice des affinités d’attributs a m lignes et n colonnes correspondant aux
attributs de la relation à fragmenter. La valeur de l’élément de la ligne i et de la colonne j
reporte les valeurs d’affinités définies entre ces attributs. Cette affinité correspond à la somme
des fréquences d’accès des requêtes accédant simultanément aux deux attributs.
-
La matrice d’affinité ordonnée est obtenue après l’application de l’algorithme
de B.E.A (Bound Energy Algorithm) [SSGJ, 84] sur la matrice des affinités d’attributs. Par
permutation de lignes et de colonnes, l’algorithme B.E.A. regroupe les attributs qui sont
utilisés simultanément en fournissant une matrice sous la forme d’un semi-bloc diagonal.
Les informations nécessaires durant la 1ère partie sont de type quantitatif. En effet, elle
s’appuie sur le comportement des applications et a pour but de placer dans une même partition
les attributs qui sont généralement accédés ensemble. Une mesure indiquant la proximité des
attributs est l’affinité des attributs.
Soit Q  Q1 , Q2 ,..., Qm  l’ensemble de requêtes destinées à s’exécuter sur une
relation R  A1 , A2 ,..., An  . A chaque requête qi et chaque attribut A j , on associe une valeur
d’usage de l’attribut noté use  qi , A j  définie comme suit :
use qi , Aj  

1 si l'attribut Aj est référencé par une requete qi
0 sinon
Par un ensemble de requêtes Q et un ensemble d’attributs  A1 , A2 ,..., Ak  on aura donc
une matrice dite matrice d’usage des attributs
58
 A1
A2 ...... . Ak 
 q1  1 0 .......... . . 
 

 q2  0 .

 .  1
.
.
 

1 0
 .  .
 q  .
.......... 0 1 
 n 
Cependant cette matrice n’est pas suffisante pour fragmenter une relation car les
valeurs qu’elle contient ne décrivent pas les fréquences des différentes applications. Les
auteurs [NCW, 84] ont introduit alors la quantité aff  Ai , A j  , qui mesure l’affinité entre deux
attributs Ai et A j d’une relation R en fonction de l’ensemble d’applications Q .
aff  Ai , Aj  

 ref  q acc  q 
l


k
l
k
k / use  qk , Ai  1use qk , A j 1 Sl
Où refl  qk  est le nombre d’accès aux attributs
 A , A  pour
i
j
chaque exécution de
l’application qk au site Sl et accl  qk  est la fréquence d’accès de l’application.
La matrice d’affinité est utilisée lors du processus de fragmentation, qui consiste dans
un premier temps à grouper l’ensemble des attributs ayant une forte affinité, et dans un
deuxième temps à fragmenter la relation en fonction de ces groupements.
Un autre algorithme de la fragmentation verticale est celui présenté par [HN, 79]: Les
auteurs ont proposé une solution basée sur un modèle de simulation pour l’évaluation des
performances présentées par le schéma après une fragmentation verticale (figure 2.8). Les
deux composantes principales de cette méthode sont :

Un générateur de partitions.

Un évaluateur de performances qui attribue une valeur de mérite à chaque
partition.
59
Figure 2.8 : Principe général de l’algorithme de [HN, 79]
3.2. Fragmentation horizontale
La fragmentation horizontale constitue un aspect important dans la conception physique
des bases de données [SNY, 04]. Elle a un impact significatif sur l’exécution des requêtes
OLAP et la gestion de l’entrepôt de données.
3.2.1.
Position du problème
Dans le contexte des entrepôts de données relationnels, la fragmentation horizontale
permet de partitionner les tables, les index et les vues matérialisées en plusieurs ensembles de
lignes disjoints, physiquement stockés et séparément consultés [SNY, 04]. Contrairement aux
vues matérialisées et aux index, la fragmentation ne duplique pas les données, en conséquence
elle réduit le coût de mises à jour [PSA, 04]. Le problème consiste à déterminer un ensemble
des tables de dimension à fragmenter et d’utiliser leurs schémas de fragmentation pour
fragmenter la table de faits F en un nombre de fragments horizontaux (appelés fragments de
faits) tels que le coût total d’exécution des requêtes sur le schéma en étoile fragmenté soit
réduit.
60
3.2.2.
Principe de la fragmentation
Le problème majeur de la fragmentation horizontale (figure 2.9) peut être formalisé de
la façon suivante : étant donné un ensemble de tables de dimension D  D1 , D2 ,..., Dd  et une
table de fait F , un ensemble de requêtes OLAP fréquentes Q  Q1 , Q2 ,..., Qm  , ou chaque
Qi 1  i  m  possède
requête
une fréquence d’accès, et un seuil
W (donné par
l’administrateur de la base de données) représentant le nombre maximum de fragments qu’il
peut maintenir. Notons que la satisfaction de cette contrainte évite le cas d’un nombre très
grand de fragments de la table de fait (noté N ).
g
N   mi ou mi et g représentent respectivement le nombre de fragments de la table
i 1
de dimension Di et le nombre de tables de dimensions participant dans le processus.
Figure 2.9 : Processus de sélection des dimensions.
3.2.3.
Propriétés de la fragmentation
Durant ce processus de fragmentation dans les bases de données ou les entrepôts de
données on doit garantir trois propriétés [CP, 84] : la complétude, la reconstitution, et la
disjonction.

La complétude garantie que tous les n-uplets d’une relation sont associés à au
moins un fragment.
61

La reconstitution garantie qu’une relation peut être reconstruite à partir de ses
fragments. Par exemple pour la fragmentation horizontale, la reconstitution de la table des
faits et des tables de dimensions est obtenue par l’opération d’union, c’est-à-dire
N
mi
i 1
j 1
F   Fi et Di   Dij .

La disjonction garantie que les fragments d’une relation sont disjoints deux à
deux, pas d’intersection.
A partir de ces caractéristiques, chaque algorithme proposé doit les tenir compte, sinon
il y’aura soit une perte de données ou redondance de données, et cela induit l’incohérence des
données initiales. En effet, une relation de m attributs peut être fragmentée verticalement en
B  m  différentes manières [OV, 91], B  m  étant le nombre de Bell.
Pour m grand,
m
B  m  peut atteindre m .
3.2.4.
3.2.4.1.
Les algorithmes de la FH
Algorithme glouton
Le problème de partitionnement horizontal a été montré NP-Complet par [SW, 85], de
plus, il est NP-complet au sens fort selon [BBR, 08], qu’ils ont considéré une version
simplifiée du problème, intitulé: Fragmentation Horizontale à un Seul Domaine, démontrée
par réduction du problème 3-partitions qui est connu NP-complet au sens fort. Plusieurs
algorithmes sont proposés pour répondre à ce problème d’optimisation. Nous considérons
seulement les tables de dimensions dont leurs ensembles de prédicats simples sont non vides.
Définition : Un prédicat simple P est de la forme : P : Ai  valeur
Où,
Ai est
un
attribut
d’une
relation
à
fragmenter,   ; ; ; ; ;  ,
valeur  dom  Ai  . Etant donné le nombre, cet algorithme commence par sélectionner une
table de dimension de manière aléatoire, cette table est alors fragmentée ainsi que la table des
faits par la fragmentation dérivée. Si le nombre de fragments N est inférieur au seuil
 L  et il
y’a une amélioration dans le coût, l’algorithme sélectionne une autre table de dimension et
62
réitère le même processus tant que les deux conditions (amélioration de coût et N  L ) sont
satisfaites (figure 2.10). Sinon l’algorithme désélectionne cette table et considère une autre
table. À la fin de l’algorithme, nous obtenons un schéma d’entrepôt fragmenté réduisant le
coût de traitement des requêtes.
Figure 2.10 : Structure de l’algorithme glouton
3.2.4.2.
Algorithme dirigé par contrainte
Nous avons vu précédemment que la fragmentation horizontale permet de réduire le
temps d’exécution des requêtes en minimisant le nombre d’accès aux données. Cependant,
pour atteindre cet objectif il faut disposer des algorithmes de fragmentation ayant une
complexité raisonnable. Les algorithmes de fragmentation primaire proposés dans les
contextes relationnels et objets se divisent en deux catégories :

Les algorithmes basés sur la minimalité et la complétude des prédicats.

Les algorithmes dirigés par les affinités des prédicats.
Ces algorithmes ont été développés dans les bases de données relationnelles dans un
contexte soit :

Centralisé : La fragmentation verticale favorise naturellement le traitement des
requêtes de projection. La fragmentation horizontale permet de limiter le nombre de pages
accédées, ou de réduire le nombre de n-uplets accédés inutilement.

Réparti : le principe général est le même, seul dans le contexte réparti, la
fragmentation consiste à découper une relation par rapport à un ensemble de sites.
63
3.2.4.2.1.
Algorithme basé sur la minimalité et la complétude des prédicats
Avant de décrire cet algorithme quelques définitions s’imposent :
Définition 1 : Une fréquence d’accès est le nombre d’accès aux données que la requête pourra
faire pour une période spécifique.
Définition 2 : Un prédicat simple p est pertinent relativement à un ensemble de prédicats
simples P s’il existe un prédicat simple q  P tel que les fragments horizontaux définis par
 p  q
et  p  q  soient accédés individuellement par au moins une application.
[OV, 91] ont proposé une méthode de fragmentation horizontale dont les étapes sont :
1.
Extraction des informations relatives à la base de données: il s’agit de
déterminer tous les liens qui existent entre les différentes relations, surtout les jointures et
ainsi que regrouper, dans une même classe, toutes les transactions ayant pour origine le même
nœud du réseau d’ordinateurs composant le système réparti. Une fréquence d’accès est
associée à chaque transaction.
2.
Spécification d’un ensemble complet et minimal de prédicats simples: à
partir de ces transactions, on énumère tous les prédicats simples P . La complétude garantit
que chaque fragment soit accédé par toutes les applications avec la même probabilité. La
minimalité garantit que tous les fragments d’une table soient accédés différemment par au
moins une application.
L’algorithme de production d’un ensemble de prédicats complet et minimal (COM-MIN) à
partir d’un ensemble de prédicats simples procède en deux étapes. La première étape initialise
l’ensemble de résultats avec un prédicat et sa négation qui fragmente la relation en deux
fragments, chacun étant accédé par au moins une application. La seconde étape est itérative, et
ajoute tout nouveau prédicat qui fragmente un fragment défini dans l’ensemble résultat en
deux fragments, chacun étant accédé par au moins une application. Lors de cette étape, les
prédicats qui deviennent non pertinents par rapport à l’ensemble résultat sont éliminés
(algorithme 3).
64
Algorithme 3 : Algorithme de génération des prédicats complets et simples
1: Données: une relation
R et un ensemble de prédicats P définis sur R
2: Sortie: Un ensemble complet et minimal de prédicats simples
3: déclaration: F (l’ensemble de fragments),
P ' de P
f i (un fragment défini par un minterm mi )
4: Règle 1: toute relation est fragmentée en au moins deux fragments qui seront accédés différemment
par au moins une application.
5: Initialisation
6:
P' 
7: chercher un prédicat
8: P '  qi ; P 
qi de P tel que qi fragmente R en respectant la règle1
P  qi ; F  fi
9: repeat
10:
chercher un prédicat qi de P tel que
11:
P '  P ' qi ; P  P  qi ; F  F  f i
12:
if il existe
qk  P ' qui n’est pas pertinent then
13:
P '  P ' qi
14:
F  F  fi
15:
end if
16: until
3.
qi fragmente f k de F en respectant la règle 1
P ' est complete
Construction
des
prédicats
MINTERM
de
P  q1 ,..., qn  :
plus
formellement ces prédicats sont générés de la façon suivante : étant donnée une relation
R  A1 ,..., An  et un ensemble de prédicats simples P   p1 ,...., pm  , l’ensemble des minterms est
composé de tous les prédicats de la forme :  pi P pi* avec pi*  pi ou pi*  pi .
4.
Eliminations des minterms non significatifs : durant cette étape on élimine
les minterms qui n’ont pas de sens (données inexistantes, duplications...).
Donc suivant cette approche précédemment définie, la fragmentation
horizontale
primaire pourra formuler par, étant donnée une relation Ri , ses fragments horizontaux sont
donnés par :
65
Ri j   Fj  Ri  1  j  n Avec n : nombre de minterms et F j est un prédicat minterm
défini sur Ri .
L’algorithme global de la fragmentation horizontal de [OV, 91] est :
Algorithme 4 : Algorithme de fragmentation horizontale [OV, 91]
1: Données: une relation R et un ensemble de prédicats P définis sur R
2: Sortie: Un ensemble de fragments horizontaux
3: P '  COM _ MIN  R, P  //génération d’un ensemble de prédicats complet et minimal
4: Déterminer l’ensemble de minterms M i
5: Déterminer l’ensemble des implications I entre les prédicats pi de P '
for each minterm mi  M i
6:
if mi est contradictoire en respectant I then
7:
M i : M i  mi
8:
9:
end if
10: end for
Exemple : Nous illustrons cet
algorithme en prenons
la relation projet
suivante (tableau 2.2) :
N.projet
Thème.projet
Budget
Lieu.étude
1
Architecture.parralèles 150.000
INPT
2
Bases.données.objets
135.000
ENSIAS
3
Réseaux.ATM
250.000
INPT
4
Robotique
310.000
FSR
Tableau 2.2 : Relation Projet
Supposons que deux applications utilisent cette relation. La première est utilisée sur
trois sites et retourne le thème et le budget de chaque projet étant donné le numéro du projet.
Les prédicats simples sont alors :
66
p1 lieu.étude = INPT
p2 lieu.étude = ENSIAS
p3 lieu.étude = FSR
La deuxième application est exécutée sur deux sites. Sur le premier site sont gérés les
projets ayant moins de 200.000 DH de budgets, sur le deuxième ceux de budgets > 200.000.
Les prédicats simples qui peuvent être utilisés pour fragmenter la relation projet selon cette
deuxième application sont :
p4 budget  200.000
p5 budget  200.000
On en déduit l’ensemble Pr de prédicats simples :
Pr   p1 , p2 , p3 , p4 , p5 
Les prédicats minterms pertinents pouvant être définis de Pr sont alors:
m1 lieu.étude = INPT  budget  200.000
m2 lieu.étude = INPT  budget  200.000
m3 lieu.étude = ENSIAS  budget  200.000
m4 lieu.étude = ENSIAS  budget  200.000
m5 lieu.étude = FSR  budget  200.000
m6 lieu.étude = FSR  budget  200.000
Le résultat de la fragmentation de la relation projet est la formation de fragments selon
les prédicats minterms cités ci-dessus.
3.2.4.2.2.
Algorithme dirigé par les affinités des prédicats
L’algorithme proposé par [BKA, 00] et [BKS, 97], se base principalement sur les
travaux présentés par [NR, 89]. Les auteurs ont adapté cet algorithme qui décrit par cinq
étapes principales :  i  l’énumération des attributs utilisés par les requêtes,  ii  la construction
67
de la matrice d’usage des attributs,  iii  la construction de la matrice d’affinité des attributs,
 iv  le
regroupement des attributs, et
 v  la
construction des fragments verticaux. Par
analogie, et pour cet algorithme [BKA, 00], les étapes seraient donc :  i  l’énumération des
prédicats de sélection,
 ii  la
construction de la matrice d’usage des prédicats,
construction de la matrice d’affinité des prédicats,
 v  l’optimisation des composantes,  vi 
 iv  le
 iii  la
regroupement des prédicats,
la construction des minterms,
 vii  la formation des
fragments horizontaux, et  viii  la génération des fragments disjoints.
Ce genre d’algorithme a été développé dans le contexte des bases de données réparties
[CP, 84][OV, 91] dans lequel la fréquence d’accès des requêtes sur les sites est considérée
comme un paramètre essentiel. Le contexte réparti n’est pas le seul domaine d’application de
la fragmentation, qui peut être également utilisée dans un contexte centralisé pour minimiser
le coût des requêtes [OR, 99].
3.3. La fragmentation dérivée
Dans la littérature : Une relation S (relation membre) peut contenir une clé étrangère
vers une relation R (relation propriétaire). La fragmentation horizontale dérivée est définie sur
la relation membre S en fonction des fragments horizontaux de la relation propriétaire R .
Plus formellement, étant donné un lien allant de la relation S vers la relation R , les
fragments horizontaux dérivés de R sont définis par :
Ri  R  Si , 1  i  w
Où w est le nombre maximum de fragments et Si le i è m e fragment de S .
Trois informations sont nécessaires pour effectuer une fragmentation horizontale
dérivée : (1) le nom de la relation membre et de la relation propriétaire, (2) le nombre de
fragments horizontaux de la relation membre, et (3) la qualification de la jointure entre ces
deux relations.
Exemple :
Considérons les deux relations S et R (figure 2.11), ayant pour extensions
respectives :
68
N.emp
Nom
Fonction
E1
X1
²Adminitstrateur.système
E2
X2
Programmeur
E3
X3
Analyse
E4
X4
Programmeur
E5
X5
Ingénieur.maintenance
Foncion
Salaire
Administrateur système
35.000
Ingénieur.maintenance
20.000
Analyste
35.000
Programmeur
25.000
Figure 2.11 : Les deux relations R (N.emp, Nom, Fonction) et S (Fonction, Salaire)
On peut donc grouper les employés en deux groupes relativement à leur salaire. Ceux
touchant un salaire inférieur à 35.000 et ceux un salaire supérieur ou égal à 35.000.
Les fragments S1 et S 2 sont définis comme suit :
R1  R  S1
R2  R  S2
Où S1  S sal 35.000 et S 2  S sal 35.000 .
Fragment R1 :
N.emp
No
Fonction
m
Fragment R2 :
N.emp
Nom
Fonction
E2
X2
Programmeur
E1
X1
Administrateur. système
E4
X4
Programmeur
E3
X3
Analyste
E5
X5
Administrateur. Système
69
4 Conclusion
Malgré ces algorithmes présentés dans un contexte de base de données relationnelles,
le problème reste toujours ouvert, surtout dans le cas d’un entrepôt de données (relationnel ou
multidimensionnel), c’est d’ailleurs l’objectif de ce travail, dans lequel on a conçu une
nouvelle approche pour fragmenter un entrepôt de données, tout en renduisant le coût
d’exécution d’un ensemble de requêtes.
Tout algorithme de fragmentation (horizontale, verticale et mixte) devrait prendre en
considération les paramètres physiques, ce qui n’est pas malheureusement le cas des
algorithmes de la fragmentation horizontale basés sur les affinités, la complétude et la
minimalité des prédicats. Dans le chapitre suivant, nous nous attachons à présenter un
nouveau type d’algorithme, prenons en compte les paramètres physiques de l’entrepôt, basé
sur les algorithmes évolutionnaires.
70
Chapitre 3
: Entrepôt de données et algorithmes génétiques
1 Introduction
Récemment, un nouvel algorithme de sélection de fragmentation horizontale a été conçu
par [BB, 05]. En considérant ce fait comme problème d’optimisation, les auteurs ont utilisé
une nouvelle approche, basée sur les algorithmes génétiques, ils ont normalisé un modèle de
coût afin d’évaluer chaque solution proposée par l’algorithme, et tester sa validité. Avant
d’entamer les détails, quelques notions sur les algorithmes génétiques s’imposent. C’est
l’objectif de la première section. Dans la dernière section du chapitre, nous allons illustrer ce
processus génétique de fragmentation horizontale dans l’entrepôt de données.
2 Concepts et principes des Algorithmes Génétiques
Les algorithmes évolutifs (Evolutionary Algorithms) sont des techniques de recherche
inspirées de l'évolution biologique des espèces, apparues à la fin des années 1950. Les
algorithmes génétiques (AG) constituent certainement les algorithmes les plus connus [Gol,
89].
2.1. Stratégie évolutive
Le principe d'un algorithme évolutionnaire8 (AE) est très simple. Un ensemble
de N points dans un espace de recherche, choisi à priori au hasard, constituent la population
initiale; chaque individu x de la population possède une certaine performance, qui mesure
son degré d'adaptation (fitness) à l'objectif visé: dans le cas de la minimisation d'une fonction
objectif f , x est d'autant plus performant que f  x  est plus petit. Un AE consiste à faire
évoluer progressivement, par générations successives, la composition de la population, en
maintenant
8
sa
taille
constante. Au
cours des
générations, l'objectif est d'améliorer
http://www.enseignement.polytechnique.fr/profs/informatique/Eric.Goubault/poly/cours009.html
71
globalement la performance des individus; le but étant d'obtenir un tel résultat en imitant les
deux principaux mécanismes qui régissent l'évolution des êtres vivants :
- la sélection, qui favorise la reproduction et la survie des individus les plus
performants.
- la reproduction, qui permet le brassage, la recombinaison et les variations des
caractères héréditaires des parents, pour former des descendants aux potentialités nouvelles.
Chaque individu est représenté par un seul chromosome constitué d’une chaîne de gènes. Le
codage des données sous la forme d’un chromosome est l’un des points délicats de
l’utilisation d’un algorithme génétique (traditionnellement, les algorithmes génétiques
manipulent les chaînes de bits). L’algorithme génétique fait évoluer cette population au cours
de générations à l’aide d’opérateurs de sélection, de croisement et de mutation, qui sont
chargés d’explorer l’espace de recherche en constituant de nouveaux individus à partir
d’individus de la population précédente, alors que la sélection favorise les individus qui
possèdent une adaptation élevée. La forme générale d’un algorithme génétique suit la
structure d’un algorithme évolutionnaire (algorithme 5).
Algorithme 5 : Algorithme évolutionnaire typique
1: t  0
2: INITIALISE_POPULATION ( P  t  )
3: ÉVALUATION ( P  t  )
4: Repeat
5:
t  t 1
6:
SÉLECTION_PARENTS ( P  t  )
7:
MUTATION ( P  t  )
8:
RECOMBINAISON ( P  t  )
9:
ÉVALUATION ( P  t  )
10:
REPRODUCTION ( P  t  )
11: Until TEST_CRITÈRE_D’_ARRÊT ( P  t  )
72
La robustesse est une des caractéristiques principales des algorithmes génétiques : ils
permettent de fournir une ou plusieurs de « bonne » qualité (pas nécessairement optimales
mais suffisantes en pratique) à des problèmes très variés, en sollicitant un investissement
assez faible.
2.2. Principe de base
Les algorithmes génétiques sont des algorithmes itératifs qui suivent le schéma des
évolutionnistes présenté dans l’algorithme 5. Leur fonctionnement est schématisé dans la
figure 3.1 dont les étapes sont9 :
1°.
A l’initialisation de l’algorithme, une population de taille fixée est générée
aléatoirement. Elle est en générale répartie uniformément sur l’espace de recherche. Chaque
individu ensuite évalué et on lui associe son adaptation.
2°.
Pour la génération k , on reproduit une partie de la population en fonction de
l’adaptation de chaque individu : plus la fitness (relative, i.e. par rapport à celle des autres
individus) d’un individu est élevée, plus il sera reproduit dans la nouvelle population.
3°.
On choisit des couples d’individus parents au hasard dans cette nouvelle
population, puis on leur applique avec la probabilité Pc (souvent choisie autour de 0.6)
l’opérateur de croisement, les enfants remplacent alors les parents dans la population de la
génération k  1 . L’opérateur de croisement est traditionnellement l’heuristique d’un
algorithme génétique.
4°.
On applique ensuite l’opérateur de mutation à chaque individu avec la
probabilité Pm , qui est en général choisit plus faible que Pc . La mutation effectue un
déplacement «local» sur les individus. Les mutants remplacent alors les parents dans la
nouvelle génération k  1 .
5°.
Les individus qui n’ont subi ni de croisement sont recopies tels quels dans la
nouvelle population.
9
http://www.recherche.enac.fr/opti/papers/thesis/HABIT/main002.html
73
6°.
On réitère ces opérations à partir de la 2ème étape jusqu'à ce qu’un critère
d’arrêt soit satisfait. Différentes critères d’arrêt de l’algorithme génétique peuvent être
choisis : nombre de générations fixé (temps constant), convergence de la population,
population n’évoluant plus suffisamment…
Figure 3.1 : Principe général des algorithmes génétiques
Pour utiliser un AG sur un problème d’optimisation on doit donc disposer d’un principe de
codage des individus, d’un mécanisme de génération de la population initiale, d’une fonction
de fitness qui dépend de la fonction à optimiser et qui fournit l’adaptation d’un individu, et
d’opérateur permettant de diversifier la population au cours de générations et d’explorer
l’espace de recherche. Il faut également choisir les paramètres de l’algorithme qui sont
nombreux et parfois délicats à régler : probabilité de croisement Pc et de mutation Pm , taille de
population, nombre de générations (si c’est le critère d’arrêt choisi).
2.2.1.
Codage d’individu
Un individu représente un point de l’espace de recherche du problème traité, c’est-àdire une évaluation de l’ensemble des variables du problème. La mise bout à bout, ces
74
variables, appelés gènes, forme le chromosome de l’individu. Par analogie avec la génétique
naturelle, les algorithmes génétiques utilisent traditionnellement des chaînes de bits pour
représenter les chromosomes. Ainsi, pour un problème d’optimisation sur n variables
entières X i , on peut représenter chacune des variables par un nombre binaire à ki bits (suivant
leur domaine), et on obtient le chromosome de taille

k à n gènes d’individu en mettant
i1,n  i
bout à bout ces nombres binaires.
Beaucoup d’autres codages en adéquation avec la structure de problème ont été
expérimentés : chaînes d’entiers, de réels, de graphes d’expressions …Ces types de codage se
sont avérés très efficaces sur beaucoup de problèmes.
2.2.2.
Génération de la population initiale
Généralement, la population initiale est générée aléatoirement de manière à répartir les
individus uniformément sur l’espace de recherche. Néanmoins, si on a une idée de la forme de
la (des) solution (s), on peut biaiser cette initialisation en regroupant les individus autour de la
région considérée, ce qui est susceptible d’accélérer la convergence de l’algorithme.
D’autre part, si les contraintes n’ont pu être correctement prises en charge par le codage des
individus, il est parfois possible de générer une solution initiale qui les satisfait : domaine des
gènes, vérification de contraintes élémentaires… Il faut alors veiller à concevoir des
opérateurs qui n’engendrent que des individus admissibles ou prendre en charge les
contrevenants pendant l’évaluation.
2.2.3.
Evaluation
La fitness d’un individu est calculée par la fonction d’évaluation ; elle mesure son
adaptation à un environnement donné et le but de l’algorithme génétique est de maximiser
cette fonction. Pour résoudre un problème d’optimisation, on prend naturellement la fonction
de coût comme fonction d’évaluation, mais dans le cas d’un problème de minimisation, il faut
évidemment considérer l’opposé de la fonction de coût. Seule la fonction de coût est utilisée
par un algorithme génétique, lors de l’évaluation.
Cependant, des problèmes liés à l’évaluation peuvent handicaper la convergence d’un
AG : si un gène domine la population très rapidement en conférant à certains individus une
75
fitness élevée, l’exploitation de l’espace de recherche peut être inhibé car le croisement ne
produit presque plus de nouvelles solutions10 et seule la mutation permet alors de diversifier la
population, ce qui en général n’est pas suffisant11, l’algorithme risque alors de converger
prématurément vers un optimum local. Le problème opposé peut également survenir : si tous
les individus ont des fitnesses très voisines, par exemple après un grand nombre de
générations (quand la population a « presque » convergée), la sélection ne parviendra pas à
faire évoluer la population vers l’optimum car les meilleurs individus ne seront pas assez
favorisés. On peut remédier ce problème en effectuant un scaling de la fonction de coût,
c’est-à-dire en la transformant (par exemple linéairement ou exponentiellement) pour
diminuer ou accroître l’écart relatif entre les fitnesses des individus.
D’autre part, si la gestion des contraintes n’a pas être effectuée par le codage des
données ou la génération des individus (population initiale, et opérateurs de croisement et
mutation), on peut la prendre en charge dans la fonction d’évaluation. Une première solution
consiste à attribuer une fitness nulle à un individu qui viole les contraintes du problème, ce
qui revient à l’éliminer car il ne sera pas reproduit dans la génération suivante. Cependant il
peut être intéressant de conserver des individus qui ne satisfont pas toutes les contraintes,
mais qui contiennent des « morceaux » de solutions éventuellement utiles dans les générations
ultérieures [ZAQ, 08a]. La technique usuelle est alors d’intégrer à la fonction d’évaluation des
pénalités pour les individus qui ne respectent pas les contraintes. Ces pénalités dépendent en
général du nombre et/ou de l’ « importance » des contraintes violées. On peut alors espérer
que l’algorithme génétique va faire évoluer la population vers des régions qui satisfont les
contraintes.
Néanmoins, les AGs supportent mal la présence de contraintes nombreuses ou complexes, et
la technique des pénalités est délicate à mettre en œuvre. Quant le problème est un CSP
(Problème de Satisfaction de Contraintes), il peut être difficile de générer la population
initiale puis de la faire évoluer.
10
Le croisement de deux individus identiques produit deux individus identiques.
11
L’opérateur de croisement est en général l’heuristique de recherche prépondérante d’un algorithme génétique.
76
2.2.4.
Sélection
La phase de reproduction de la population d’un AG utilise un principe de sélection
pour favoriser les individus les plus adaptés. Différents types de sélection sont couramment
utilisés :

La Roulette Wheel sélection : pour chaque individu, on reproduit sur un disque
de périmètre un arc de cercle proportionnel à sa fitness relative 12, puis on fait tourner la
roulette aléatoirement (i.e. on tire au hasard un nombre dans  0,1 ) et on reproduit l’individu
sélectionné ; on recommence n fois pour obtenir la nouvelle génération. Le nombre de
descendant est ainsi statistiquement proportionnel à sa fitness . Cependant, plus la taille de la
population est faible, plus la sélection sera biaisée à cause du petit nombre de tirages
effectués.

La Stochastic remainder without replacement selection : cette sélection évite le
problème lié aux populations de petites tailles éprouvé par la roulette Wheel selection. Pour
chaque individu Ind i , on calcule le rapport ri de sa fitness sur la moyenne des fitnesses (i.e. n
fois sa fitness relative ), puis on prend sa partie entière E  ri  et l’individu est reproduit
exactement E  ri  fois ; on exécute ensuite Roulette Wheel selection sur tous les individus
affectés des fitnesses ri  E  ri  pour compléter la nouvelle population.

Ranking selection : cette sélection remédie le problème dans lequel un gène
associé à une fitness élevée peut dominer rapidement la population. Cette sélection tente de
remédier ce problème en associant à chaque individu une probabilité de sélection qui ne
dépend que du rang de sa fitness dans la population ; on parcourt ensuite la population en
tirant pour chaque individu un nombre dans  0,1 et on le reproduit si sa probabilité est
supérieure ; on réitère l’opération afin de compléter la nouvelle population. Cette solution est
12
fitness relative

d’un individu se calcule en rapportant sa

i
individus : f

realtive Ind
f  Ind

j 1, n 
i

f  Ind
j

77
fitness à
la somme des
fitnesses de
tous les
avantageuse au début de l’algorithme mais peut empêcher la sélection efficace des meilleurs
individus.
On ajoute très souvent un principe d’élitisme dans le processus de sélection destiné à
conserver systématiquement le meilleur individu de la population courante dans la génération
suivante, sans lui faire subir d’opérateurs de croisement ou de mutation qui pourraient le
détruire.
2.2.5.
Croisement
Le croisement ou crossover est un opérateur de recombinaison qui fournit un couple
d’enfants à partir d’un couple de parents de la génération précédente. Les deux chromosomes
initiaux s’alignent et s’entremêlent en plusieurs points de croisement puis se séparent pour
former deux chromosomes, où s’alternent des tronçons deux premiers chromosomes.
Un opérateur de croisement classique, appelé slicing crossover, est illustré dans la
figure 3.2 : deux individus sont choisis dans la population après la phase de reproduction, puis
un point de croisement est choisi sur leur chromosome ; on intervertit alors les parties des
parents de part et d’autre du point de croisement pour fournir deux nouveaux individus.
Figure 3.2 : Slicing crossover
Le fait de choisir un seul point de croisement biaise l’effet du crossover : s’il est choisi
proche d’une extrémité du chromosome, les enfants seront presque identiques aux parents, et
78
s’il est choisi au milieu, ils en seront très différents. Le 2-point slicing crossover évite ce
problème en considérant les chromosomes comme circulaires plutôt que linéaires et en les
coupant en deux points. Des k-points slicing crossovers ont également été proposés [DS, 92]
(figure 3.3 avec k  3 ), jusqu’au uniform crossover qui utilise un masque binaire généré
aléatoirement de la même taille que les chromosomes, pour indiquer à chaque position du
gène dans un chromosome le parent qui fournira le gène.
Figure 3.3 : 3-point slicing Crossover.
Autre type de croisement utilisé est le croisement barycentrique qui produit les gènes
des enfants G1i et Gi2 avec des combinaisons linéaires des gènes des parents G1i et Gi2
fils

G 1i
fils
G i2
fils

fils
 G 1i
 1  

père
G 1i
père
père


:
père
1   G i2père
 G i2
père
Ceci pour chaque position i  1, n  du gène dans le chromosome, et avec  un
coefficient de pondération aléatoire qui peut éventuellement prendre des valeurs en dehors de
 0,1 , pour générer des points « entre » ou à l’ « extérieur » des gènes des pères, mais il faut
veiller à respecter les contraintes de domaine des variables.
Un autre mécanisme de croisement peut être proposé, à condition de respecter les
propriétés :
-
Lorsque deux individus identiques s’accouplent, ils engendrent des individus
identiques à eux-mêmes.
-
La probabilité que rien ne se passe pendant un crossing-over est toujours non
nulle.
79
-
Les deux individus qui s’accouplent jouent des rôles identiques.
Les opérateurs de croisement adoptés par notre algorithme génétique vérifient ces trois
propriétés.
2.2.6.
Mutation
L’opérateur de mutation effectue en général un déplacement local sur la solution
représentée par un individu. La mutation est considérée comme un opérateur marginal pour
les AGs, bien qu’elle leur confère la propriété d’ergodicité, c’est-à-dire que tous les points de
l’espace de recherche peuvent être atteints ; cet opérateur a une grande importance, de point
de vue théorique.
L’opérateur classique de mutation sur les chaînes de bits choisit aléatoirement une
position dans le gène et le remplace par son complémentaire pour construire l’individu mutant
comme l’illustre la figure 3.4.
Figure 3.4 : Mutation classique discrète
On peut généraliser cette mutation sur des chaînes à domaines discrets de tailles
quelconque en changeant la valeur du gène choisi par une autre de son domaine, proche de la
valeur initiale. Dans les problèmes continus (figure 3.5), on procède un peu de la même
manière en tirant aléatoirement un gène dans le chromosome, auquel on ajoute un bruit
aléatoire (par exemple un bruit gaussien) en veillant bien évidemment à ce que le gène
résultant reste dans le domaine de définition qui lui est propre. L’écart type de ce bruit est
délicat et difficile à régler : s’il est trop faible, l’exploration sera ralentie au début et on risque
la convergence locale ; s’il est trop grand, les solutions seront modifiées trop brutalement et
on ne pourra pas non plus converger localement vers l’optimum.
80
Figure 3.5 : Mutation continue
Il existe également un principe de mutation adaptative figure 3.6, permettant
d'optimiser le taux de mutation en codant ce dernier dans la structure du chromosome [Bac,
92]. Ce second chromosome est géré de la même manière que le premier chromosome codant
l'espace d'état, c'est-à-dire lui-même soumit aux opérateurs génétiques (croisement et
mutation). Au cours du déroulement de l'algorithme, les gènes et les individus ayant des
probabilités de mutation élevées auront tendance à disparaître à mesure que la population
converge vers l'optimum. De même, les gènes ayant des probabilités de mutation trop faibles
ne peuvent évoluer favorablement et tendent à être supplantés.
Figure 3.6 : Mutation adaptative
2.2.7.
Convergences des algorithmes génétiques
Dans leur version canonique, les AGs présentent des limites qui conduisent le plus
souvent à des problèmes de convergences lente ou prématurée. Pour pallier à ces
inconvénients, des améliorations ont été apportées: e.g, codage, opérateurs biologiques,
81
stratégie élitiste, etc. Les détails de fonctionnement de ces algorithmes peuvent être
trouvés dans plusieurs références [Mich, 96]
2.2.8.
Limitations des algorithmes génétiques
Les algorithmes génétiques sont des outils efficaces pour une classe de problèmes
d’optimisation. De plus, ils permettent de traiter des problèmes où la fonction à optimiser ne
présente aucune propriété de continuité ou de dérivabilité, par exemple. Néanmoins, les
sections précédentes mettent en avant un certain nombre de limitations à leur sujet :

Ils sont moins efficaces qu’un algorithme déterministe spécifique (lorsqu’il en
existe un) dédié à un problème donné.

Les nombreux paramètres qui les contrôlent sont délicats à régler (probabilités
de croisement et de mutation notamment), ainsi que le codage des chromosomes qui peut faire
varier radicalement la vitesse de convergence.

Afin de garantir la robustesse des algorithmes évolutifs, le calcul d’un très
grand nombre de fitness (parfois de l’ordre de plusieurs centaines de milliers) est
généralement nécessaire avant l’obtention d’une bonne solution. Ce nombre de calcul
important peut s’avérer problématique lorsque le coût de calcul (ressources systèmes ou
temporelles) de la fitness est important, ou lorsqu’on travaille en grande dimension sur des
fonctions à complexité importante par exemple.
Ils peuvent éprouver des difficultés à gérer des contraintes nombreuses et complexes car la
technique des pénalités intégrées à la fonction de coût utilise des contraintes à posteriori de
manière passive.
3 Application des algorithmes génétiques à l’entrepôt de données
La fragmentation de la table des faits dans un environnement DW pourrait engendrer un
nombre important de fragments qui rendrait le processus de maintenance très coûteux. Afin de
réduire ce nombre ou le rendre contrôlable par l’administrateur de l’entrepôt de données,
plusieurs travaux de recherche ont proposé l’utilisation d’un Algorithme Génétique. Ce
dernier a pour but de sélectionner les tables de dimension à fragmenter pour éviter l’expulsion
82
du nombre de fragments de la table des faits et garantir une meilleure performance
d’exécution des requêtes [BB, 05]. [BBR, 08].
3.1. Processus génétique de la fragmentation horizontale
3.1.1.
Codage adopté
Tout algorithme de fragmentation horizontale nécessite les données d’un ensemble de
requêtes les plus fréquentes. A partir de ces requêtes, nous extrairons deux types
d’informations : qualitative et quantitative.
Les informations qualitatives concernent les tables de dimension et sont représentées
par les prédicats de sélection simples utilisés dans les requêtes. Les informations quantitatives
concernent la sélectivité de ces prédicats et les fréquences d’accès des requêtes. Nous
rappelons qu’un prédicat simple p est défini par p : Ai  Valeur , où Ai est un attribut d’une
relation à fragmenter,   , , , , ,  , Valeur  Dom  Ai  .
Avant de décrire le processus de codage des individus de la population, nous devons
réaliser les tâches suivantes :
1°.
L’extraction de tous les prédicats de sélection simples utilisés par les n
requêtes.
2°.
L’attribution à chaque table de dimension Di 1  i  d  d’un ensemble de
prédicats simples EPS Di qui lui est propre.
3°.
Toute table de dimension Di ayant EPS Di   , ne sera pas fragmentée. Soit
Dcandidat l’ensemble de toutes les tables de dimension ayant leur ensemble de prédicats simples
non vide. Soit g la cardinalité de l’ensemble Dcandidat  g  d  .
4°.
L’application de l’algorithme COM _ MIN [OV, 99] à chaque ensemble de
prédicats simples d’une table de dimension Di . Il fournit en sortie une forme complète et
minimale de ces ensembles. La règle de complétude et de minimalité assure que si une table
est fragmentée en au moins deux fragments, elle sera accédée différemment par au moins une
requête [OV, 99].
83
3.1.2.
Représentation des fragments horizontaux
L’analyse des clauses représentant les fragments horizontaux permet d’effectuer une
partition du domaine des attributs de fragmentation en sous-domaines appelés sous domaines
stables  SDS  . Les éléments de cette partition sont déterminés par les prédicats simples.
Exemple : Cet exemple montre comment les prédicats de fragmentation définissent
des partitions de chaque domaine des attributs de fragmentation (un attribut de fragmentation
est un attribut qui participe dans le processus de partitionnement). Considérons trois attributs
de fragmentation : Age et Sexe de la table de dimension Client, et Saison de la table de
dimension Temps. Supposons que les domaines des attributs de fragmentation sont :
Dom  Age   0,120 ;
Dom  Sexe   ' M ', ' F ' ;
Dom  Saison   " Printemps ", " Eté ", " Automne ", " Hiver "
Sur l’attribut Age, quatre prédicats simples sont définis : P1 : Age  18 , P 2 : Age  60 ,
P 3 : Age  18 et P 4 : Age  60 .
SDSs
par
les
Le domaine de l’attribut
quatre
Age
 0,120
prédicats  P1, P 2, P 3, P 4 
de
est donc partitionné en trois
la
manière
suivante:
Dom  Age   d 11  d 12  d 13 , avec d 11  0,18 , d 12  18, 60 , d 13   60,120 .
– D’une manière similaire, le domaine de l’attribut Sexe est partitionné en deux
SDSs : Dom  Sexe   d 21  d 22 , avec d 21  ' M ' , d 22  ' F '
–
Finalement,
l’attribut
Saison
est
partitionné
en
quatre
SDSs :
Dom  Saison   d 31  d 32  d 33  d 34 , avec d 31  "Printemps" et d 32  "Eté" , d 33  "Automne" et
d 34  "Hiver" [ZBB, 07].
Les différents SDSs de chaque attribut de fragmentation sont représentés par la figure
3.7 :
84
Figure 3.7 : Les SDSs des attributs de fragmentation.
Chaque attribut de fragmentation Ai sera représenté par un tableau d’entiers de ni
cellules, où ni correspond au nombre de sous domaines, les valeurs dans les cellules de ce
tableau oscilleront entre 1 et ni . Si deux cellules ont la même valeur, on regroupe les sous
domaines de manière à n’en former qu’un. Chaque individu (un schéma de fragmentation) est
donc représenté par un tableau d’entiers (tableau 3.1) ou par un cube (figure 3.8).
Sexe
1
1
Saison
2
1
3
Age
2
1
2
3
Tableau 3.1 : Exemple d’individu
Figure 3.8 : Exemple de représentation de fragments dans le cas de trois attributs.
85
A partir du tableau 3.1, on peut déduire que la fragmentation de l’entrepôt ne se fera
pas sur l’attribut Sexe , car tous les sous domaines de l’attribut ont la même valeur. En
conséquence, on fragmentera en utilisant l’attribut Saison et l’attribut Age .
Pour l’attribut Saison , trois prédicats de fragmentation sont possibles, à savoir :
P1 : Saison  " Printemps" , P 2 : Saison  " Eté" et P3 : Saison  " Automne"  Saison ="Hiver" .
Pour
l’attribut
Age,
deux
prédicats
sont
possibles
:
P 4 :  Age  18  Age  60  et P 5 : 18  Age  60 .
A partir de ces prédicats, nous pouvons fragmenter le schéma de l’entrepôt en 6
fragments,
où
chaque
fragment
est
défini
par
une
clause
de
prédicats : P1  P 4 ; P1  P5 ; P 2  P 4 ; P 2  P5 ; P 3  P 4 et P3  P5 .
La représentation en tableau multidimensionnel peut être utilisée pour calculer le
nombre de tous les schémas de fragmentation possibles (dénoté par H ) :
H
 2




k

i 1

ni 


Où k et ni représente le nombre d’attributs de fragmentation et le nombre de sous
domaines de l’attribut Ai , respectivement.
Si on considère les trois attributs de fragmentation : Age, Sexe et Saison (de l’exemple
précédent), le nombre de schémas possibles est 2
2 3 4 
 29 . Ce nombre représente également
le nombre de minterms possibles générés par l’algorithme de fragmentation horizontale
primaire proposé par [OV, 99].
3.1.3.
Sélection des individus
[BB, 05] ont utilisé la méthode de la roulette pour sélectionner les individus parents.
Dans cette méthode chaque individu est accompagné de son évaluation. Plus cette évaluation
est élevée, plus l’individu a de chance d’être sélectionné. Les individus choisis sont appelés le
« père » et la « mère ».
– Une fois les individus choisis, on détermine si on va les croiser ou pas en tirant un
chiffre aléatoire ;
86
– Si ce chiffre est supérieur à un certain taux de croisement (en général fixé entre 70 et
90 %), on ne les croise pas et les individus sont réinjectés directement dans la population de
génération suivante.
– Si le père et la mère sont trop semblables, un seul sera réinjecté.
Dans l’autre cas, on crée deux enfants à partir des deux parents. On ajoute alors ces
enfants à la population.
3.1.4.
Types de croisements
Plusieurs types de croisement peuvent être envisagés : le croisement mono-point (1
seul point de croisement par individu), le croisement multipoints (2 ou plusieurs points de
croisement par individu), le croisement uniforme (opération bit à bit entre les individus). Dans
notre étude, [BB, 05] ont choisi d’utiliser un croisement multipoints pour la raison suivante :
nous savons depuis la création d’un individu que les prédicats sont placés les uns à la suite des
autres dans le vecteur d’entiers.
Les individus sont croisés une fois sur chaque prédicat, pour ne pas désavantager le
croisement d’un prédicat par rapport à un autre. On sait en effet que chaque prédicat dispose
d’un nombre d’entiers différents. Si on n’effectue qu’un croisement par individu le prédicat
qui a un grand nombre d’entiers (par exemple, l’attribut Age de la table de dimension Client
aura autant d’entiers que d’âges) aura une probabilité de croisement supérieure à un attribut
ayant un domaine de faible cardinalité, comme l’attribut Sexe (masculin et féminin). Cette
opération de sélection est effectuée tant que la population n’a pas atteint le nombre
convenable d’individus.
3.2. Optimisation avec contrainte
Chaque chromosome (schéma de fragmentation) FSi généré par notre AG est évalué
en utilisant une fonction de fitness représentée par un modèle de coût qui calcule la somme
de pages accédées (entrées/sorties) nécessaires pour exécuter chaque requête dans l’entrepôt
de données fragmenté. Soit D sel   D1sel ,..., Dksel  l’ensemble des tables de dimension ayant
87
des attributs de sélection, où chaque prédicat de sélection Pj (défini sur une table de
P
dimension Di ) possède un facteur de sélectivité notée par ( SelDij   0,1 ).
Ce prédicat Pj , a également un facteur de sélectivité dans la table des faits, noté

P
P
P

par SelF j SelF j  SelDij . Dans notre étude, les facteurs de sélectivité sont choisis en utilisant
une répartition uniforme (RU), car la présentation la plus simple est celle qui suppose
l’uniformité de la distribution des valeurs et l’indépendance des attributs pour évaluer la
sélectivité des prédicats de comparaison.
Notons
que

chaque
requête
Qk est
exécutée
sur
chaque
schéma
de

fragmentation FSi S1 ,..., S Ni .
Afin d’identifier les sous schémas en étoile pertinents pour la requête Qk , Nous avons
introduit une variable booléenne dénotée par Pertinence  Qk , S i  [BB, 05], définie par :
Pertinence  Qk , Si  

1 si le sous schéma Si participe dans l'evaluation de Qk
0 sinon
.
Cependant, le coût d’exécution en termes de pages (entrées/sorties entre le disque et la
mémoire centrale) de chaque requête Qk 1  k  m  est évalué de la façon suivante :

Identification de tous les sous schémas pertinents par les Ni sous schémas,

Pour chaque sous schéma pertinent, nous chargeons en mémoire les pages de la
table des faits concernées par la requête Qk .
Finalement, ce coût peut être exprimé par l’équation suivante [BB, 05] :
Mj
 Ni
 F  L
IOC  Q, FSi     Pertinence  Qk , S j    SelFPi  
 
 j 1
i 1
 PS   (3.1)

Avec, M j , F , L et PS représentent le nombre de prédicats de sélection utilisés pour
définir les fragments de sous schéma en étoile S j , la cardinalité de la table des faits (nombre
de tuples) F , la longueur en octets de chaque tuple de la table des faits, et la taille d’une page
disque (en octets), respectivement. Le coût total pour exécuter l’ensemble des requêtes est
exprimé par l’équation suivante :
88
m
TIOC  Q, FSi    IOC  Qk , FSi 
k 1
(3.2)
Donc le problème de fragmentation d’un entrepôt de données relationnel consiste à
partitionner un schéma en étoile, tel que le coût total d’exécution de requêtes soit minimal ou
en d’autres termes, le gain est maximisé :
Maximiser_ Eval  Q, FSi   TIOC  Q ,    TIOC  Q , FS i  
(3.3)
tel que Ni  W , avec TIOC  Q ,   représente le coût d’exécution de l’ensemble de requêtes
sur le schéma de l’entrepôt non fragmenté.
3.3. Mutation
L’analogie avec le monde vivant nous amène à nous poser la question de la mutation.
Dans la nature, les mutations sont fréquentes et entraînent des variations plus ou moins
marquées de l’individu. Dans notre modèle (figure 3.9) nous avons choisi un taux de mutation
qui se situe entre 30% et 6%, c’est le taux habituellement utilisé. Il faut choisir un juste milieu
entre une trop faible et une trop forte mutation. Les mutations s’effectuent aux niveaux des
attributs de notre individu. Suivant un nombre aléatoire, nous choisissons de muter un ou
plusieurs attributs de l’individu. On peut voir sur le schéma suivant la mutation d’un attribut.
Figure 3.9 : Exemple de Mutation
On remarque sur l’exemple ci-dessus (figure 3.9), la mutation d’un individu sur l’un de ses
attributs, qu’il y avait trois fragments dans l’individu initial en ce qui concerne l’attribut 2.
Sur l’individu muté, on remarque qu’il y a toujours trois fragments mais les intervalles pris en
compte ne sont plus les mêmes. Dans la pratique, il pourrait y avoir plus d’intervalles distincts
89
ou un regroupement d’intervalles. De même, les mutations pourraient se produire sur
plusieurs attributs de l’individu.
4 Conclusion
Dans ce chapitre, nous avons décrit les principales fonctions d’un algorithme
génétique. D’abord nous avons donné des exemples, ensuite nous avons présentés les travaux
de recherche d’optimisation des requêtes OLAP, basés sur les AGs, concernant le codage,
mutation et croisement, ainsi que les opérations primitives à utiliser pour la fragmentation
horizontale. Bien que l’algorithme présente une solution remarquable, vues les résultats
obtenus, il reste loin, d’exploiter les possibilités offertes pour améliorer le cout d’exécution
des requêtes OLAP, c’est pour cela nous voulons introduire la fragmentation verticale dans ce
processus afin d’améliorer d’avantages la solution d’optimisation.
De plus apparemment, dans une telle démarche, toutes les tables de dimension auraient
la même probabilité d’être utilisées, ce qui n’est pas toujours vrai dans la réalité, car elles ne
possèdent pas la même taille fréquence d’utilisation, etc. Donc il serait intéressent de décider
le nombre des tables de dimensions pertinentes pour la fragmentation ensuite leurs attributs.
Par la suite nous allons démontrer cette hypothèse, c’est l’objectif du quatrième chapitre.
90
Chapitre 4 : Mise en œuvre d’un algorithme Génétique pour la
fragmentation mixte
1 Introduction
Dans ce chapitre, nous allons décrire notre adaptation de l’algorithme génétique,
concernant le codage, mutation et croisement, ainsi que les opérations primitives à utiliser,
pour la fragmentation mixte. Le choix d’utilisation est la garantie d’aboutir à la fin du
processus à une solution presque optimale et qui répond à toutes les exigences et contraintes
établies par l’administrateur. De plus et pour confirmer notre approche une étude détaillée
avec des expérimentations est envisagée dans la fin du chapitre. Nous considérons cette
approche d’optimisation comme une alternative aux systèmes qui doivent gérer, manipuler et
optimiser des données historiques.
2 Présentation de notre approche : nouveau modèle d’optimisation avec
les AGs
L’idée majeure consiste à combiner l’algorithme précédemment cité dans chapitre 3
(section 3), par au autre algorithme chargé de trouver un schéma de fragmentation verticale,
puisque cette dernière n’a pas connu le même succès que celui de la fragmentation
horizontale, cet algorithme lui-même est un algorithme génétique [ZAQ, 08a].
2.1. Processus génétique de fragmentation mixte
Le processus de fragmentation mixte est entamé par une fragmentation horizontale
primaire des dimensions, et une fragmentation horizontale dérivée de la table des faits ([BB,
05] et [BBR, 08]), suivie par une verticale suivant les dimensions [ZAQ, 08a], [ZAQ, 08b].
L’algorithme 6 nous montre les étapes nécessaires de notre approche pour répondre au
problème d’optimisation dans l’entrepôt de données relationnel. La première étape consiste à
extraire les données utiles à savoir les fréquences d’utilisations et les prédicats de sélection à
partir des requêtes. Les deux dernières étapes sont indépendantes.
91
Algorithme 6 : Algorithme mixte proposé
Entrée :
Q: Ensemble de requêtes avec leurs fréquences F
D : Ensemble de tables de dimension
Sortie: schémas de fragmentation (vertical et horizontal).
Début
Extraire (prédicats de selection)
Algorithme_genetique_horizontal()
// fragmentation horizontale de l’ED suivant la configuration générée
Algorithme_genetique_horizontal()
// fragmentation verticale de l’ED suivant la configuration générée
Fi n
2.1.1.
Codage d’individu
Tout algorithme de fragmentation verticale nécessite un ensemble de requêtes les plus
fréquentes. A partir de ces requêtes, et pour une table de dimension candidate pour la
fragmentation, nous avons construit une matrice d’usage des attributs. Soit ni le nombre
d’attributs non clés de la table de dimension Di . Chaque individu (un schéma de
D
fragmentation) est donc représenté par un tableau d’entiers de taille N   ni ( D est le
k 1
nombre de dimensions) (figure 4.1). Si des cellules ont la même valeur, cela signifie que ces
attributs forment le même fragment vertical. Si dans un tableau de codage toutes les cellules
ont la même valeur, cela signifie que cette table de dimension ne sera pas partitionnée.
Exemple 1 : Considérons l’individu qui présente une dimension ayant la représentation
suivante :  3, 0,3, 0, 2, 2 . Cette représentation génèrera trois fragments verticaux de cette
dimension : les attributs A1 et A3 forment le premier fragment, A2 et A4 forment le deuxième
fragment, tandis que A5 et A6 forment le dernier fragment (il faut ajouter la clé primaire de la
relation dans chaque fragment).
92
Figure 4.1 : Codage de différents individus pour un chromosome vertical (schéma de
fragmentation verticale)
Exemple 2 : Dans la figure ci-dessus, le chromosome présentant la dimension Custlevel
indique la création de deux fragments verticaux : FV1  Key , A1 , A2  et FV2  Key , A3 , A4  .
2.1.2.
Sélection des individus
Nous avons utilisé la méthode de la roulette pour sélectionner nos individus parents comme
pour la fragmentation horizontale (chap.3, sc. 3.1.3).
2.1.3.
Croisement
Nous avons appliqué le croisement à une paire d’individus (les parents) d’une certaine
proportion de la population - avec une probabilité Pc , généralement autour de 0.6 - pour en
produire de nouveaux (chromosomes), et on décide si on croise ou pas suivant une variable
aléatoire échantillonnée et comparée avec la probabilité Pc . Le type de croisement utilisé est
celui d’un seul point pour la génération de la population suivante (Algorithme 7) [ZAQ, 08].
93
Algorithme 7 : Algorithme de croisement pour la fragmentation verticale
Entrée : Génération G
Paramètre : Probabilité de croisement Pc
Début :
1:
Choisir deux Individus aléatoirement ( I i , I j )
2:

Échantionner n  1, d 

ième
// Choisir la n dimension des deux
// Individus ( I i , I j )

3:
Échantionner u  0,1
4:
Si  u  Pc  alors


5:
Échantionner m  1, N att 
6:
Échanger I i  m  , I j  m 



// Permutation a partir de l’attribut m
7:
Fin
Fin si
La figure 4.2 montre un exemple de croisement pour un entrepôt de données de trois
dimensions (Product, Client, Store)
Figure 4.2 : Croisement suivant la dimension Store.
Dans cet exemple (figure 4.2), la dimension store est choisie suivant une valeur prise
aléatoirement, puis on applique le même type de croisement utilisé pour la fragmentation
horizontale.
94
2.1.4.
Mutation
L’algorithme 8 nous illustre cette étape qui est presque la même que celle de la
fragmentation horizontale avec une légère adaptation.
Algorithme 8 : Opération de mutation
Entrée : Génération G
Paramètre : Nbre_Mutation, Probabilité de mutation Pm
Début :
1:
Choisir un Individu aléatoirement de G
2:
Répéter
4:


Échantionner  m  0,1 
5:
Si  m  Pm  alors
Échantionner d  1, N d 
3:
Echantionner n  1, N att 
6:
7:
8:
9:
Fin
Muter le nème attribut
fin si
Jusqu’a Nbre_Mutation
La figure 4.3 montre un exemple de mutation pour une dimension (Product) choisie
suivant une valeur donnée aléatoirement.
Figure 4.3 : Exemple de mutation verticale
2.1.5.
Processus d’amélioration
Pour réaliser cette amélioration et suivant les deux parties de l’algorithme mixte, nous
avons entamé le processus par une population diversifiée et aléatoire qui ne dépend pas des
95
informations de l’entrepôt de données et ne prend aucune information qui lui permet d’avoir
une idée sur la solution initiale, ceci offre plus de chances de bien cerner la recherche et de
mieux s’approcher de la solution optimale. Le principe de notre approche est de considérer
chaque population d’une façon itérative, dans le but de réduire le plus possible le coût
d’évaluation des requêtes. Notons que notre AG peut générer des solutions violant la
contrainte d’espace. Et afin d’améliorer et pénaliser ces solutions, une valeur de pénalité est
introduite à la fonction objective (à minimiser ou maximiser) comme une partie de la fonction
de fitness [YCG, 04][ZAQ, 08d].
Supposons que nous traitons le problème suivant : Maximiser F  x  sous la contrainte
Cx  C où Cx représente un coût généré par la solution x et C représente un seuil de coût à ne
pas dépasser. La fonction de pénalité (notée Pen  x  ) permet de pénaliser les solutions violant
la contrainte, en diminuant la valeur de la fonction à maximiser selon le degré de violation de
la contrainte.
Trois types de la fonction de pénalité ont été définis, logarithmique, linéaire et
exponentielle :
- Pénalité logarithmique : Pen  x   log 2 1    Cx  C   où  représente le facteur de
pénalité.
- Pénalité linéaire : Pen  x   1    Cx  C 
- Pénalité exponentielle : Pen  x   1    Cx  C  
2
L’utilisation de la fonction de pénalité au sein de la fonction F  x  permet de
transformer le problème à un problème d’optimisation sans contraintes d’une fonction
F '  x  définie à partir des fonctions F  x  et Pen  x  . Cela peut être effectué en utilisant trois
modes, soustraction, division et division-soustraction qui sont définis comme suit.
1.
Mode Soustraction :
 F ' xF  x Pen x si F xPen x
 F ' x0 sinon

2.
Mode division
96
 F ' x  F x  s i P e n x 1
  P en x
 

 
 F ' x  F  x 
s i P e n  x  1


3.





Mode soustraction-division
F ' x  F  x  P e n  x  s i F  x   P e n  x 
F x 
F ' x 
s i P e n  x  1 e t F  x  P e n  x 
P en x 
F ' x  F  x 
s i P e n  x  1 s i F  x  P e n  x 
Nous avons adopté ces opérations pour améliorer les solutions, on procède ainsi à:

éliminer toutes les solutions non admissibles et ne laisser que les solutions
admissibles. Cette approche peut être non intéressante dans le cas où le déplacement entre
deux solutions admissibles passerait obligatoirement par une solution non admissible. Notons
qu’il est nécessaire dans ce cas de mettre en œuvre des opérateurs génétiques qui gardent
l’admissibilité des solutions (l’application d’un opérateur génétique sur une solution
admissible donne toujours une solution admissible) ; pénaliser les solutions non admissibles
en incluant une fonction de pénalité comme partie de la fonction d’évaluation.
2.1.6.
Caractéristiques de notre algorithme
Pour chaque technique d’optimisation, un certain nombre d’algorithmes est disponible.
Pour sélectionner un schéma de FH, plusieurs algorithmes de sélection ont été proposés
[BBR, 08].
Suivant l’algorithme mixte proposé (algorithme 6), et pour réaliser cette fragmentation
(verticale), l’administrateur doit identifier quelques paramètres de configuration relatifs
d’abord à l’algorithme génétique, et indépendants du processus de sélection, plus les attributs
de dimension participant à ce processus, appelés les attributs de fragmentation (tableau 4.1).
Ainsi, chaque algorithme est caractérisé par un certain nombre de paramètres à configurer. Le
tableau suivant récapitule les différents paramètres utilisés par ces algorithmes.
97
Sachant qu’il n’existe pas de paramètres qui soient adaptés à la résolution de tous les
problèmes qui peuvent être posés à un A.G. Cependant, certaines valeurs sont souvent
utilisées peuvent être de bons points de départ pour démarrer une recherche de solution à
l’aide d’un A.G.
 Taille de la population : entre 30 et 50 individus
 Taux de crossover : entre 70% et 95%
 Taux de mutation : entre 0,5% et 1%.

Algorithme
Paramètres
- Nombre d’individus
Algorithme génétique
- Nombre de générations
- Taux de croisement
- Taux de mutation
- Les attributs de fragmentation (à partir de la
Algorithme de fragmentation verticale
clause Select).
- Les fréquences d’utilisations des requêtes
OLAP.
Tableau 4.1 : Principaux paramètres des différents algorithmes
3 Evaluation globale de l’approche sur un benchmark
Afin de valider nos contributions, nous avons mené des expériences qui nous ont permet
d’évaluer et de comparer les techniques de fragmentation. Ces expériences exploitent un
entrepôt de données généré par un banc d’essai (Data warehouse Benchmark APB-1 release II
[OC, 98]).
3.1. Banc d’essai Benchmark
L’évaluation des performances des SGBDs en général, et les tests d’efficacité des
techniques d’optimisation des performances en particulier, sont généralement effectués à
l’aide de bancs d’essais. Dans le contexte des entrepôts de données, nous avons utilisé le banc
d’essais Benchmark APB-1 release II [OC, 98]. Le schéma en étoile que nous avons dégagé à
98
partir de ce banc d’essais est constitué d’une table de faits Actvars et de quatre tables de
dimensions, Prodlevel, Custlevel, Timelevel et Chanlevel (figure 4.4). Les caractéristiques de
chaque table sont représentées dans le tableau 1. Le détail de ces tables est représenté dans
l’annexe A.
Figure 4.4 : Schéma de l’entrepôt utilisé APB benchmark.
Table
Nombre d’enregistrement
Taille d’enregistrement
1 500 000
74
Prodlevel
9000
72
Custlevel
900
24
Chanlevel
9
24
Timelevel
24
36
Actvars
Tableau 4.2 : Taille des tables
3.2. Implémentation
Pour évaluer nos méthodes de fragmentation génétique, nous avons développé un
moteur génétique relatif à la fragmentation verticale (figure 4.5) [ZBB, 07] [ZAB, 06].
99
Figure 4.5 : Architecture du moteur générique
3.2.1.
Pseudo code
Proposer un modèle de coût générique prenant en compte tous les types de requêtes et
adapté à tous les SGBDs est une tâche très difficile. Plusieurs travaux ont porté sur la
proposition de modèles de coût pour estimer le coût d’exécution d’une requête. Il est possible
de classer les modèles proposés en deux catégories :
(1) modèles basés sur une fonction mathématique ad-hoc [BBA, 06] [ZBB, 07].
(2) modèles basés sur l’optimiseur de requêtes. Ce coût est calculé en utilisant des
formules qui prennent en compte un certain nombre de paramètres et de statistiques collectées
sur la base de données.
Le premier modèle de coût utilisé lors de la fragmentation horizontale permet
d’évaluer la qualité des différents schémas de fragmentation générés par l’algorithme de
fragmentation. Il permet d’estimer le nombre d’entrées/sorties nécessaire pour exécuter une
requête sur un schéma fragmenté ou non (figure 4.6). Ce modèle de coût a été détaillé dans le
chapitre 3. Le deuxième modèle de coût pour la fragmentation verticale est une adaptation du
premier model, il permet d’évaluer les différentes configurations (localisation) des attributs
générés par l’algorithme de sélection. Nous ne prenons pas en compte le temps CPU que nous
supposons négligeable par rapport au temps nécessaire pour effectuer les E/S.
100
Figure 4.6 : Démarche de fragmentation proposée.
Dans le cadre de nos contributions, nous avons proposé un modèle de coût appartenant à la
première catégorie pour être indépendant du SGBD utilisé et avoir rapidement un coût de
chaque schéma de fragmentation sans passer par l’optimiseur (chapitre 3, §3.2).
3.2.2.
Chargement de l’entrepôt
Le banc d’essais ABP-1 est livré avec un fichier exécutable APB.exe [OC, 98], qui
sert à générer les fichiers de données servant à peupler l’entrepôt. Il est livré aussi avec un
fichier contenant les scripts de création des tables constituant l’entrepôt. Nous avons modifié
ces scripts pour créer les tables de dimension ProdLevel, TimeLevel, CustLevel et ChanLevel
et la table des faits Actvars. Le peuplement de l’entrepôt se fait à l’aide de l’utilitaire
SQLLoader fourni avec Oracle10g en utilisant des fichiers de contrôles que nous avons créés.
Les fichiers de contrôles spécifient les formats des fichiers de données et des tables dans
lesquelles ces fichiers seront chargées. La figure 4.7 montre le chargement de l’entrepôt en
utilisant l’outil de génération APB.EXE fourni avec le banc d’essais APB-1 [OC, 98] et l’outil
SQLLoader fourni avec Oracle.
101
Figure 4.7 : Chargement de l’entrepôt de données
3.2.3.
Types de requêtes prises en compte
Les requêtes prises en compte dans ces expériences et lors de l’élaboration de notre
modèle de coût sont des requêtes de jointure en étoile ayant la structure suivante :
SELECT [SGA], FC1(AA), FC2(AA),..., FCn(AA)
FROM F, D1, D2,... Dk
WHERE PJOIN AND PSEL
[GROUP BY GA]
Où :

SGA : l’ensemble des attributs retournés dans la réponse à la requête (il peut
être vide pour les requêtes retournant un calcul). Ces attributs peuvent être des attributs de
dimension et/ou de faits.

FC1, FC2,…, FCn : les fonctions de calculs (MIN, MAX, COUNT, SUM,

AA : l’ensemble des attributs d’agrégation, ces attributs sont généralement des
AVG).
mesures définies dans la table des faits.

k : le nombre de tables de dimension utilisées par la requête.
102

PJOIN : un ensemble de prédicats de jointure entre la table des faits et les
tables de dimension sous forme de conjonction. Un prédicat de jointure (équi-jointure) a la
forme suivante : F . fki  Di .ki . où fki , ki représentent respectivement la clé étrangère et la clé
primaire de la table de dimension Di .

PSEL : un ensemble de prédicats de sélection sous forme de conjonction,
chaque conjonction est constituée de plusieurs prédicats définis sur la même table.

GA : l’ensemble des attributs de groupement. Ces attributs peuvent être des
attributs de faits et/ou de dimension.
Les requêtes que nous avons prises en charges pour notre modèle de coût sont
représentées dans l’annexe B. Le problème de ce type des requêtes, définies sur un schéma en
étoile, est qu’elles 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 ! et N étant le nombre de tables de dimensions à
joindre. Nous pouvons même formaliser ce problème d’ordonnancement ainsi, étant donnée
une requête de jointure en étoile Q impliquant m jointures entre la table des faits F et
m tables de dimension D1 , D 2 ,…, Dm . Le problème de sélection d’un ordre de jointure
consiste à trouver une permutation de l’ensemble 1, 2,..., m tel que le coût d’exécution de la
requête suivant l’ordre de jointure généré par cette permutation soit minimal. Notons que
chaque élément i de cet ensemble représente l’ordre d’apparition de la table de dimension
Di dans la séquence de jointures. Pour résoudre ce problème, une recherche exhaustive peut
être utilisée. Elle consiste à générer tous les ordres possibles, les évaluer et choisir le meilleur
ordre. Il est clair que pour des valeurs importantes de m , le problème de sélection d’un ordre
de jointure devient complexe, et par conséquent aucun algorithme ne pourra donner la
solution optimale en un temps fini.
3.3. Evaluation
3.3.1.
Sans pénalisation
Nous avons effectué nos expérimentations en deux étapes :
103
La première étape consiste à fragmenter horizontalement l’entrepôt de données en
utilisant l’algorithme génétique. Alors que dans la deuxième étape, il s’agit de partitionner les
fragments horizontaux verticalement en utilisant l’algorithme 6. Chaque solution est
implémentée sous Oracle 10g. Pour le calcul des temps d’exécution de requêtes, nous avons
utilisé l’utilitaire Aqua data studio 4.7.2 (ADS). Pour mener notre évaluation, nous avons
considéré un ensemble de 14 requêtes (voir annexe), ayant la forme précédemment citée.
Chaque requête est exécutée sur l’entrepôt non fragmenté et son temps d’exécution est calculé
avec ADS (figure 4.8).
Figure 4.8 : Fenêtre d’exécution d’une requête sous Aqua data studio.

Intérêt de la fragmentation horizontale
Nous avons mené plusieurs expériences. Premièrement, nous voulons savoir l’intérêt
de la fragmentation horizontale, L’axe des abscisses montre les différentes requêtes et l’axe
des ordonnées montre le temps d’exécution de chaque requête en milliseconde. La figure 4.9
montre que la fragmentation horizontale est très intéressante pour cet ensemble de requêtes,
en particulier les trois premières. Ces résultats confirment les travaux présentés dans [BB, 05]
et avec une baisse de 19% du coût total.
104
Figure 4.9 : Temps d’exécution des requêtes selon deux schémas (fragmenté et non
fragmenté).
Ces résultats sont obtenus suivant le schéma de fragmentation horizontale généré :
Dimension Timelevel : 7 partitions
Dimension Prodlevel : 48 partitions
Dimension Custlevel : 2 partitions
Dimension Chanlevel : 3 partitions

Impact de la fragmentation mixte
Dans la deuxième expérience [ZAQ, 08][ ZBB, 07], nous avons voulu voir le
comportement de la fragmentation mixte (horizontale puis verticale) par rapport à la
fragmentation horizontale. Pour ce faire, nous avons exécuté les mêmes requêtes sur un
schéma fragmenté horizontalement et un schéma mixte fragmenté horizontalement et
verticalement suivant la configuration :
Timelevel
012
Prodlevel
10224
105
Chanlevel
11
Custlevel
11
Cette configuration, par exemple suivant la dimension Timelevel (Tid, Year_level,
Month_level) se traduit par la création de 3 partitions verticales PV1 (Tid, Year_level), PV2
(Tid, Month_level) et PV3 (Tid, Quarter_level)). Si nous prenons en compte le coût total de
requêtes, la réduction causée par la fragmentation mixte est significative. La figure 4.10
montre l’intérêt de la fragmentation mixte pour les entrepôts de données, avec un bénéfice est
de 2,3%.
Figure 4.10 : La différence entre la fragmentation mixte proposée et horizontale.

Impact du nombre de fragments verticaux
Dans la troisième expérience, nous avons varié le nombre de fragments verticaux
possibles de l’entrepôt. Nous avons considéré trois configurations d’entrepôts: avec 9
fragments verticaux, avec 8 fragments verticaux, et le dernier avec 7 fragments. Pour chaque
configuration, nous avons exécuté notre algorithme de fragmentation mixte (fragmentation
horizontale suivie par une verticale), avec la contrainte de seuil (qui représente le nombre de
106
fragments verticaux). Les requêtes sont ainsi exécutées selon chaque configuration. Les
résultats sont présentés dans les figure 4.11 et 4.12. Nous pouvons conclure que la
performance dépend fortement du nombre de fragments ; le gain se traduit par une réduction
de 16,68%. Cela pourrait être expliqué par le fait que lorsqu’on augmente le nombre de
fragments verticaux, on augmente les opérations de jointures.
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.
3.3.2.
Avec pénalisation
Pour évaluer chaque solution, nous avons utilisé la fonction de coût déjà cité (chapitre
3, §3.2) qui calcule le coût d’exécution des requêtes sur l’entrepôt fragmenté et partitionné.
Des solutions de mauvaises qualités peuvent être acceptées au cours de la recherche et
peuvent être inadmissibles. Pour prendre en considération les solutions inadmissibles, nous
avons inclu une fonction de pénalité pour la solution transgressant une contrainte [ZAQ, 08d].
Ainsi, et pour les réexaminer, il faut introduire une fonction de pénalité. Plusieurs formes de
cette fonction de pénalité peuvent être définies. Dans [YCG, 04] les auteurs ont défini trois
formes de la fonction de pénalité, et trois modes pour l’inclure dans la fonction objective. Ils
ont traité un problème de maximisation du gain apporté en matérialisant un ensemble de vues
sous une contrainte du coût de maintenance.
Compte tenu de la fonction de pénalité, le résultat obtenu est significatif (figure 4.13),
puisque le temps d’exécution de l’ensemble des requêtes décisionnelles chute d’une manière
brutale et remarquable, ce qui traduit que la solution trouvée est presque optimal [ZQA, 09].
108
Figure 4.13 : Temps de réponse avec et sans pénalité

Impact des modes de pénalité
Le choix de la forme de pénalité joue un rôle additif vers une solution affine, Nous
évaluons à présent l’intérêt des trois modes au cours de la recherche, la figure 4.14 présente
les résultats d’exécution de l’AG utilisant les opérateurs appropriés à chaque mode.
Figure 4.14 : L’impact du choix entre les trois modes de pénalité.
Il apparaît clairement l’intérêt de l’application du mode, on obtenant une réduction
remarquable du coût.
De plus, et selon les trois types de pénalité définis précédemment, l’administrateur a le
choix entre logarithmique, exponentielle ou bien linéaire, la figure 4.15 présente la différence
entre les trois.
109
Figure 4.15 : La relation entre le coût total et le type de pénalité.
Selon cette figure, on peut décider que le choix de pénalité est décisif, est de type
linéaire cela est du fait que lorsque on modifie l’écart (la valeur ajoutée) d’une manière
logarithmique ou exponentielle, cela minimise et réduit le fait de pénalité. Après, nous
voulons savoir, si la valeur que nous avons pris pour   0, 6 est justifiable, nous avons
changé cette valeur plusieurs fois et pour chaque valeur on a lancé la charge des requêtes sur
l’entrepôt de données fragmenté, on a obtenue la figure 4.16
Figure 4.16 : Relation entre la valeur  et le cout total d’exécution

Impact du nombre de dimensions
110
Nous nous intéressons à présent, à l’évaluation de l’impact du nombre des dimensions
intervenant dans ce processus génétique d’optimisation de requête sur les résultats de la
recherche. A cet effet, nous avons fragmenté notre entrepôt de données d’une manière
graduelle: une dimension, deux dimensions, trois dimensions…. les résultats obtenus nous
montrent qu’il y’a un seuil de fragmentation relatif au nombre de dimensions (figure 4.17).
Figure 4.17 : Effet du nombre de dimensions sur le coût total d’exécution.
L’évaluation est basée sur l’estimation de dimensions pertinentes ainsi que le nombre de
dimensions, c’est le facteur Treshold.
4 Conclusion
Dans ce chapitre, nous avons présenté notre approche d’optimisation des requêtes
OLAP dans un système décisionnel. Nous avons décrit le processus génétique de
fragmentation mixte de l’entrepôt de données. Pour aboutir à la mise en œuvre de ce modèle,
nous avons utilisé APB Benchmark release II [OC, 98]).
Nous avons évalué les techniques de fragmentation sur un schéma d’entrepôt de
données en étoile, qui est composée d’une table de faits (Actvars) et de quatre tables de
dimensions (chanlevel, prodlevel, custlevel et timelevel). Nous avons construit ce schéma en
utilisant le SGBD oracle 10g.
Pour l’optimisation de temps d’exécution des requêtes OLAP, nous avons définit un ensemble
de requêtes Q  Q1 , Q2 ,..., Qm  joignant la table de fait avec les tables de dimensions. Nous
avons d’abord utilisé l’algorithme basé sur la fragmentation horizontale seulement, ensuite,
111
nous avons appliqué notre algorithme (avec et/ou sans pénalité), et nous avons constaté que
notre proposition donne de meilleurs résultats pour notre cas des expérimentations.
5 Conclusion et perspectives
Les travaux développés dans ce mémoire s’inscrivent dans le cadre de la
conception physique de l’entrepôt de données relationnel. Nous y avons proposé une approche
d’optimisation de requêtes basée sur les concepts de la génétique.
De nombreux modèles et techniques d’optimisation ont été proposés dans la littérature.
Nous avons présenté les techniques principales mises à l’épreuve dans les bases de données
relationnelles et orientées objets. Il s’agit de vues matérialisées, de la création d’index, et de la
fragmentation. Ces techniques se basent sur les différentes modélisations des entrepôts de
données : le modèle ROLAP et le modèle MOLAP. Nous avons mis en évidence les
problèmes liés à chaque technique.
Dans ce contexte de travail, nous nous sommes intéressés à la fragmentation et à la
mise en œuvre d’un AG d’optimisation de requêtes OLAP. Les AG’s sont des procédés
d’optimisation qui présentent des propriétés fort intéressantes : exploration parallèle et
efficace d’espaces complexes, construction graduelle de solutions partielles, recherche
coopérative. Nous avons formalisé le problème de la fragmentation horizontale dans les
entrepôts de données modélisées par des schémas en étoile. Nous avons présenté les travaux
effectués par les algorithmes génétiques dans la fragmentation horizontale de la table des
faits, en adaptant les techniques utilisées dans les bases de données relationnelles. Par la suite,
nous avons illustré les problèmes liés à la fragmentation de la table des faits en fonction des
tables de dimensions, et nous avons suggéré l’utilisation d’une fragmentation mixte basée sur
les algorithmes génétiques.
Notre contribution consiste à fragmenter un schéma relationnel d’un entrepôt de
données horizontalement, ensuite verticalement afin de réduire le coût d’exécution de
requêtes. Nous avons formalisé le problème de sélection de schéma de fragmentation verticale
112
comme un problème d’optimisation avec contrainte. Cette dernière représente le nombre de
fragments verticaux que l’administrateur peut maintenir. Pour le résoudre, nous avons proposé
un algorithme génétique qui adapte le même codage que l’algorithme proposé [BB, 05]. Un
processus de codage des schémas de fragmentation possibles est décrit. Un modèle de coût
qui représente la fonction sélective a été développé afin de mesurer la qualité de la solution
choisie.
L’évaluation de notre nouvelle approche d’optimisation de l’entrepôt de données a
montré son impact positif sur le temps d’exécution des requêtes OLAP. Les résultats générés
par l’AG sont intéressants et montrent que la fragmentation mixte peut être utilisée dans les
entrepôts de données ayant des tables de dimensions importantes. Avec une fragmentation
adéquate des tables de dimensions, il est possible d’améliorer les performances d’exécution
des requêtes décisionnelles en respectant le seuil des fragments que l’administrateur doit
choisir.
Les résultats obtenus, en appliquant cette approche, justifient l’adoption des
algorithmes génétiques pour résoudre le problème de sélection d’une configuration pour
fragmenter et partitionner un entrepôt de données.
Pour les perspectives envisageables à nos travaux, il serait intéressant de faire passer à
l’échelle cet algorithme en considérant des tables très volumineuses. Il serait également
intéressant d’aménager notre algorithme afin de tenir compte de l’évolution des requêtes tant
dans leurs structures que dans leurs fréquences. Ainsi que, nous essayerons d’améliorer
d’avantage notre approche :

proposer une population initiale mieux dépendante de la solution cherchée.

rendre la condition d’arrêt flexible.
De l’autre coté, il est intéressant de ne pas se consacrer sur la réponse exacte d’une requête
OLAP, des recherches actuelles se penchent pour trouver des approches d’approximation des
résultats d’une requête OLAP soumise à un entrepôt de données. Ces approches offrent de
nouvelles possibilités d’exploration et d’extraction de données qui permettent de réduire à la
fois le temps de réponse et la taille des données parcourues.
113
114
6 Références
[All, 96]
Jean-Marc Alliot ; Techniques d’optimisation stochastique appliquées aux
problèmes du contrôle aérirn. Thèse d’habilitation, Université de Toulouse Paul
Sabatier, 1996.
[Bac92]
T. Back, Self-Adaptation in genetic algorithms. Proceedings of the first European
conference on Artificial Life, 1992.
[BBA, 06]
Bellatreche, L., B. K., et H. I. Abdalla (2006). Saga : A combination of genetic
and simulated annealing algorithms for physical data warehouse design. In 23rd
British National Conference on Databases (212-219).
[BB, 05]
Ladjel Bellatreche and Kamel Boukhalfa, La fragmentation dans les entrepôts de
données : une approche basée sur les algorithmes génétiques, Revue des
Nouvelles Technologies de l'Information (EDA'2005), Juin, 2005, pp. 141-160.
[BBR, 08]
Kamel Boukhalfa, Ladjel Bellatreche and Pascal RICHARD, Fragmentation
Primaire et Dérivée: Étude de Complexité, Algorithmes de Sélection et Validation
sous ORACLE10g, LISI, Rapport de Recherche, N° 01 -2008, Mars, 2008.
[BCA, 01]
E. Benitez, C. Collet, and M. Adiba. Entrepôts de données : caractéristiques et
problématique. Revue TSI, 20(2), 2001.
[BKS, 97]
L. Bellatreche, K. Karalapalem, and A. Simonet. Horizontal class partitioning in
object-oriented database. In 8th International Conference and Database and Expert
systems Applications (DESA’97), Toulouse, Lecture Notes in Computer Science
1308, pages 58-67, Septembre 1997.
[BKS, 00]
L. Bellatreche, K. Karalapalem, and A. Simonet. Algorithms and support for
Horizontal class partitioning in object-oriented database. In the distributed and
parallel Databases joutnal, 8(2): 155-179, April 2000.
[BLT, 86]
J. A. Blakeley, P. Larson, and F. W. Tompa. Efficently updating materialized
views. Proceedings of the ACM SIGMOD International Conference on
Management of Data, pages 61–71, June 1986.
115
[BPT, 97]
E. Baralis, S. Paraboschi, and E. Teniente. Materialized view selection in a
multidimensional database. Proceedings of the International Conference on Very
Large Databases, pages 156–165, August 1997.
[CD, 97]
Surajit Chaudhuri and Umeshwar Dayal. An overview of data warehousing and
OLAP technology. SIGMOD Record, 26(1) :65–74, 1997.
[CN, 98]
S. Chaudhuri and V. Narasayya. Autoadmin ‘what-if’ index analysis utility.
Proceedings of the ACM SIGMOD International conference on Management of
Data, pages 367-378, June 1998.
[CN, 99]
S. Chaudhuri and V. Narasayya. Index merging. Proceedings of the International
conference on Data Engineering (ICDE), pages 296-303, March 1999.
[CNP, 82]
Ceri S., Negri M., Pelagatti G.(1982), « Horizontal Data Partitioning in Database
Design », Proceedings of the ACM SIGMOD International Conference on
Management of Data. SIGPLAN Notices, vol., p. 128-136.
[Cod, 93]
Codd E.F., "Providing OLAP (on-line analytical processing) to user-analysts : an
IT mandate", Technical Report, E.F. Codd and Associates, 1993.
[CP, 84]
S. Ceri and G. Pelagatti. Distributed Databases: Principles and Systems. McGrawHill International Editions, 1984.
[DS, 92]
Kenneth A. De Jonh and William M. Spears. A Formal analysis of the Role of
Multi-Point Crossover in Genetic Algorithms, volume 5 of Annals of
Mathematics and Artificial Intelligence, chapter 1, pages 1-26. 1992.
[DG, 01]
A. Doucet and S. Gangarski. Entrepôts de données et Bases de Données
multidimensionnelles, Chapitre 12 du livre : Bases de Données et internet,
Modèles, langages et systèmes. Editions Hermès, 2001.
[ECM, 99] Edgard Benitez-Guerrero, Christine Collet, Michel Adiba, Rapport de Recherche,
entrepôt de données : Synthèse et analyse. RR 1017-I-LSR 8, Mai 1999.
[GGT, 96]
Gardarin G., Gruser J.-R., Tang Z.-H.(1996), « A Cost-based Selection of Path
Expression Processing Algorithms in Object-Oriented Databases », 22nd
International Conference on Very Large Data Bases, VLDB’96, vol., p. 390-401.
116
[GM, 99]
Gupta H., Mumick I.S., “Selection of Views to Materialize Under a Maintenance
Cost Constraint”, in 7th International Conference on Database Theory (ICDT
1999), Jerusalem, Israel, pp. 453-470. 1999.
[Gol, 89]
Goldberg D. E., (1989). Genetic Algorithms in search, optimization and machine
learning. Addison-wesley Publishing Inc.
[Gup, 97]
H.Gupta. Selection of views to materialize in a data warehouse. Proceedings of
the 6th International conference on Database Theory (ICDT’97), pages 98-112,
1997.
[HN, 79]
Hammer M., Niamir B. « A heuristic appoach to attribute paritioning »,
Proceedings of the ACM SIGMOD International Conference on Management
of Data, pages 93-101, 1979.
[HRU,96]
Harinarayan V., Rajaraman A., Ullman J.D., “Implementing data cubes
efficiently”, in ACM SIGMOD International Conference on Management of data
(SIGMOD 1996), Montreal, Canada, pp. 205-216. 1996
[Inm, 92]
Inmon (W.). – Building the data warehouse.- Wellesley, Massachusetts, U.S.A.,
QED Technical publishing Group, 1992.
[Inm, 95]
Inmon (W.). –what is a Data warehouse? – Rapport technique, INPT solutions,
1995.
[JLS, 99]
H. Jagadish, L. V. S. Lakshmanan, and D. Srivastava. What can hierarchies do for
your data warehouses. Proceedings of the international conference on Very Large
Databases, pages 530-541, September 1999.
http://www.cait.wuslt.edu/cait/papers/INPT/vol11-no1/.
[Kim, 96]
R. Kimball. Entrepôts de données, Guide pratique du concepteur de data
warehouse. John Wiley and Sons, Inc., 1996.
[KR, 99]
Y.Kotidis and N. Roussopoulus. Dynamat: A dynamic view management system
for data warehouses. Proceedings of the ACM SIGMOD International Conference
on Management of Data, pages 371-382, June 1999.
[LHM, 86] B. G. Lindsay, L. M. Haas, C. Mohan, H. Pirahesh, and P. F. Wilms. A snapshot
differential refresh algorithm. Proceedings of the ACM SIGMOD International
Conference on Management of Data, pages 53–60, June 1986.
117
[Mich, 96]
Michalewicz Z., (1996). Genetic Algorithms + Data Structures = Evolution
Programs. Springer-Verlag, New York.
[NCW, 84] S. Navathe, S. Ceri, G.Wiederhold, and D. J. Vertical partitioning algorithms for
database design. ACM Transaction on Database Systems, 9(4) :681–710,
December 1984.
[NR, 89]
Navathe, S., Ra M., « Vertical partitioning for database design: graphical
algorithm », ACM SIGMOD, pages 440-450, 1989.
[OC, 98]
O. Council. Apb-1 olap benchmark, release ii.
http ://www.olapcouncil.org/ research/ resrchly.htm, 1998.
[OQ, 97]
O’Neil, P. et D. Quass (1997). Improved query performance with variant indexes.
Proceedings of the ACM SIGMOD International Conference on Management of
Data, 38–49.
[OR, 99]
Oracle8i Concepts. Oracle Corporation, Release 8.1.5, 1999.
[OV, 91]
M. T. Özsu and P. vuldurez. Principals of Distributed Database systems. Prentice
Hall, 1991.
[OV, 99]
M. T. Özsu and P. vuldurez. Principals of Distributed Database systems: Second
Edition. Prentice Hall, 1999.
[PS, 91]
G. Piatesky-Shapiro. Discovery, analysis, and presentation of strong rules. In
knowledge discovery in Databases, AAAI/MIT Press, pages 229-248, 1991.
[PSA, 94]
Papadomanolakis, S. et A. Ailamaki (2004). Autopart : Automating schema
design for large scientific databases using data partitioning. Proceedings of the
16th International Conference on Scientific and Statistical Database Management
(SSDBM 2004), 383–392.
[PV, 87]
P. Valduriez. Join indices. ACM Transactions on Database Systems, 12(2) :218–
246, June 1987.
[SNY, 04]
Sanjay A., Narasayya V. R., Yang B., « Integrating Vertical and Horizontal
Partitioning Into Automated Physical Database Design », Proceedings of the
ACM SIGMOD International Conference on Management of Data, vol., p. 359370, June, 2004.
118
[SP, 89]
A. Segev and J. Park. Maintaining materialized views in distributed databases.
Proceedings of the international conference on Data engineering (ICDE), pages
262-270, February 1989.
[SSGJ, 84] Shamkant B. Navathe, Stefano Ceri, Gio Wiederhold, Jinglie Dou: Vertical
Partitioning Algorithms for Database Design. ACM Trans. Database Syst. 9(4):
680-710 (1984).
[SW, 85]
Sacca, D. et G. Wiederhold (1985). Database partitioning in a cluster of
processors. ACM Trans. Database Syst. 10(1), 29–56.
[SYS, 97]
Red Breck Systems. Star schema processing for complex queries. White paper.
July 1997.
[RSS, 96]
K. Ross, D. Srivastava, and S. Sudarshan. Materialized view maintenance and
integrity constraint checking :Trading space for time. Proceedings of the ACM
SIGMOD International Conference on Management of Data, pages 447–458, June
1996.
[Ull, 96]
J. Ullman. Efficient implementation of data cubes via materialized views, in the
Proceedings of the 2nd international conference on knowledge discovery and Data
Mining (KDD’96), pages 386-388, 1996.
[WMB, 97] Wu,M.-C. et A. Buchmann (1997). Research issues in data warehousing. in
Datenbanksysteme in Büro, Technik und Wissenschaft(BTW’97), 61–82.
[YCG, 04]
Yu J. X., Choi C.-H., Gou G.( November, 2004), “Materialized View Selection as
Constrained Evolution Optimization”, IEEE Transactions On Systems, Man, and
Cybernetics, Part 3, vol. 33, n° 4, p. 458-467.
[YKL, 97]
J. Yang, K. Karlapalem, and Q. Li. Algorithms for materialized view design in
data warehousing environment. Proceedings of the International Conference on
Very Large Databases, pages 136–145, August 1997.
[ZAB, 06]
Ziyati. E, D.Aboutajdine et L.Bellatreche et « Un algorithme génétique pour la
sélection d’un schéma de fragmentation mixte dans les entrepôt de données »
(ASD’2006 Agadir, Maroc).
[ZAQ, 08a] Ziyati. E, D.Aboutajdine et A. El Qadi « Complete algorithm for fragmentation in
data warehouse », The 7th WSEAS International Conference on Artificial
119
Intelligence, Knowledge Engineering and Data Bases (AIKED'08) Cambridge,
England.
[ZAQ, 08b] Ziyati. E, D.Aboutajdine et A. El Qadi « Algorithms for data warehouse design to
enhance decision-making » (WSEAS Transactions on Computer research , Issue
3, Volume 3, March 2008 pp 111-120.
[ZAQ, 08c] Ziyati. E, D.Aboutajdine et A. El Qadi « Mixed fragmentation enhancement in
data warehouse » (GEI’2008 Génie Logiciel, Systèmes distribués, Réseaux
Informatiques, Intelligence artificielle, Systèmes d’information, Systèmes
Multimédia, Tunisie).
[ZAQ, 08d] E. ziyati, A. El Qadi, D. Aboutajdine, « L’amélioration du processus de
fragmentation mixte dans un entrepôt de données ». 1ère Conférence
Internationale sur les “Systèmes d’Information et Intelligence Economique”, 1416 Février 2008 à Hammamet – Tunisie.
[ZAQ,09a] Ziyati. E, A. El Qadi, et D.Aboutajdine «Toward a complete data warehouse
Design» WASET, World Academy of Science Engineering and Technology,
WCSET, October Venice Italy, 2009.
[ZAQ,09b] Ziyati E., A. Elqadi, D. Aboutajdine, «Vers une nouvelle approche de
fragmentation complète dans les entrepôts de données » Premières Journées
Doctorales en Technologies de l'Information et de la Communication
(JDTIC'09) le 16, 17et 18 Juillet 2009.
[ZBB, 07]
Ziyati. E, L.Bellatreche et K. boukhalfa
« La contribution des structures
d’optimisation non redondantes dans la conception physique des entrepôts de
données » (ISPS’2007 algiers, Alger).
[ZAQ, 09c] Ziyati. E, A. El Qadi,, D.Aboutajdine et L.Bellaterche « Genetic optimization in
data warehouse design» International Journal Of Computational Science,
volume 4, N°1, January 2010, pp 70-79.
120
Annexe A
nombre de valeurs distinctes
custlevel
timelevel
chanlevel
prodlevel
store_level
900
retailer_level
99
tid
24
year_level
2
quarter_level
4
month_level
12
week_level
1
day_level
2
base_level
9
all_level
0
code_level
9000
class_level
605
group_level
300
family_level
75
line_level
15
division_level
4
customer_level
37
product_level
6500
channel_level
9
time_level
17
nombre
d'enregistrements
Taille
d'enregistrement
900
24
24
36
9
24
9000
72
1500000
74
actvars
unitsSold
dollarSales
dollarCost
121
Annexe B
Q1 :
Q2 :
select
Customer_Level,
from
Select
prodlevel.code_level,
Product_level,
prodlevel.family_level,
Time_level,
chanlevel.all_level,
Sum(Dollarcost)
sum(Actvars.dollarsales),
ACTVARS A, CUSTLEVEL
Count(actvars.dollarsales),
C,PRODLEVEL P,TIMELEVEL T
where
count(*)
from
A.customer_level=C.store_level
dw.actvars, dw.chanlevel, dw.prodlevel
where
and A.prodcut_level=P.code_level
chanlevel.base_level = actvars.channel_level
and A.time_level=T.TID
and prodlevel.code_level = actvars.product_level
and T.year_level='1996'
and prodlevel.family_level = 'IKKIOVKDGTWO'
and C.retailer_level ='NXEYFSIQE3JM'
and chanlevel.all_level = 'UFEJCH4EE4C5'
and P.line_level='MJ1F1U1EG009'
group by
group by
prodlevel.code_level,
Customer_level,
prodlevel.family_level,
Product_level,
chanlevel.all_level
Time_level
Q3 :
Q4 :
SELECT
SELECT
code_level,
base_level,
sum(dollarsales),
sum(dollarsales) ,
sum(UnitsSold)
sum(UnitsSold)
FROM dw.actvars, dw.timelevel, dw.prodlevel
FROM dw.actvars, dw.timelevel, dw.prodlevel,
WHERE
dw.chanlevel
time_level = tid
WHERE
and product_level = code_level
time_level = tid
and month_level between '01' and '03'
and product_level = code_level
and family_level = 'M8VWHZM5BS2N'
and channel_level = base_level
group by code_level
and month_level between '10' and '12'
and family_level = 'M8VWHZM5BS2N'
and all_level = 'MX0TV6Y3ZYIX'
group by base_level
Q5 :
Q6:
122
SELECT
SELECT
code_level,
code_level,
sum(dollarsales)
sum(dollarsales)
FROM dw.actvars, dw.prodlevel, dw.chanlevel
FROM dw.actvars, dw.timelevel, dw.prodlevel
WHERE
WHERE
time_level = tid
product_level = code_level
and product_level = code_level
and channel_level = base_level
and month_level <> '06'
and family_level = 'M8VWHZM5BS2N'
and group_level = 'SV5L8W0J8UMZ'
and all_level <> 'FQYP80SGU24G'
group by
group by
code_level
code_level
Q7:
Q8:
SELECT
SELECT
product_level,
product_level,
sum(dollarsales),
sum(dollarsales),
sum(UnitsSold)
sum(UnitsSold)
FROM dw.actvars, dw.prodlevel, dw.timelevel
FROM dw.actvars, dw.prodlevel, dw.timelevel,
WHERE time_level = tid
dw.chanlevel
and product_level = code_level
WHERE time_level = tid
and month_level = '03'
and product_level = code_level
and class_level = 'KPB8DCM3VDMK'
and channel_level = base_level
and division_level = 'DVWQ0OHI8M00'
and year_level = '1995'
Group by
product_level
and month_level='03'
and class_level = 'G7DPNCB3JSFW'
and division_level = 'D0NS4TAC8RAW'
droup by
Q9:
Q10 :
SELECT
select
product_level
time_level,
prodlevel.group_level,
sum(dollarsales),
custlevel.retailer_level,
sum(UnitsSold)
chanlevel.base_level,
timelevel.month_level,
FROM dw.actvars, dw.prodlevel, dw.timelevel,
sum(a.UNITSSOLD),
dw.chanlevel
sum(a.DOLLARSALES)
from dw.actvars a, dw.prodlevel P, dw.timelevel T,
WHERE
dw.custlevel C, dw.chanlevel CH
123
time_level = tid
where
and product_level = code_level
a.product_level = P.code_level
and channel_level = base_level
and a.customer_level = C.store_level
and year_level = '1995'
and a.channel_level = CH.base_level
and month_level='01'
and a.time_level = T.tid
and class_level = 'G7DPNCB3JSFW'
and P.line_level = 'WEINIRDJIU32'
and division_level = 'D0NS4TAC8RAW'
and C.retailer_level = 'R5MPR2102564'
and CH.all_level = 'UFYXSH4EE4C6'
group by
time_level
and T.month_level between '7' and '9'
group by
prodlevel.line_level,
custlevel.retailer_level,
chanlevel.all_level,
timelevel.month_level
Q11 :
Q12 :
select
select
prodlevel.division_level,
prodlevel.family_level,
custlevel.retailer_level,
custlevel.retailer_level,
timelevel.month_level,
chanlevel.all_level,
sum (a.unitssold) AS Units,
timelevel.month_level
sum (a.dollarsales) as DollarSales,
from
sum (a.DollarCost) as DollarCost,
dw.actvars a, dw.prodlevel P, dw.timelevel,
sum(a.dollarsalles) - sum (a.dollarCost) as Margin,
dw.custlevel C, dw.chanlevel CH
(sum(a.dollarsales)-sum
where
(a.DollarCost))/sum(a.DOLLARSALES) as
a.product_level = prodlevel.code_level
MarginPct
and a.customer_level = custlevel.store_level
from
and a.channel_level = chanlevel.base_level
dw.actvars a, dw.prodlevel P, dw.timelevel T,
and a.time_level = timelevel.Tid
dw.custlevel C
and P.family_level = 'M8VWHZM5BS2N'
where
and C.retailer_level = 'R5MPR2102564'
a.product_level = prodlevel.code_level
and CH.all_level = 'MX0TV6Y3ZYIX'
and a.time_level = timelevel.tid
and T.month_level = '01'
and a.customer_level = custlevel.store_level
group by
and T.year_level = '1995'
prodlevel.family_level,
and C.retailer_level = 'R5MPR2102564'
custlevel.retailer_level,
and P.division_level in
chanlevel.all_level,
124
('NF7WO9GBZ20C', 'D0NS4TAC8RAW',
timelevel.month_level
'PE6Z2EN6Y7LQ')
group by
prodlevel.division_level,
custlevel.retailer_level,
timelevel.month_level
Q13:
Q14 :
SELECT
select
time_level,
prodlevel.division_level,
channel_level,
custlevel.retailer_level,
product_level,
timelevel.month_level,
sum(dollarsales),
sum (a.unitssold) as Units,
sum(UnitsSold)
sum (a.dollarsales) as DollarSales,
FROM
dw.actvars,
dw.prodlevel,
dw.timelevel,
dw.chanlevel
sum (a.DollarCost) as DollarCost
from
WHERE
dw.actvars a, dw.prodlevel P, dw.timelevel T,
time_level = tid
dw.custlevel C
and product_level = code_level
where
and channel_level = base_level
a.product_level = prodlevel.code_level
and year_level = '1995'
and a.time_level = T.Tid
and month_level='05'
and a.customer_level = C.store_level
and code_level = 'JY6ZFUICYLS3'
and P.division_level IN ('PE6Z2EN6Y7LQ',
and division_level = 'NF7WO9GBZ20C'
'NF7WO9GBZ20C')
group by
time_level,
and C.retailer_level = 'R5MPR2102564'
group by
channel_level,
P.division_level,
product_level
C.retailer_level
125
UNIVERSITÉ MOHAMMED V – AGDAL
FACULTÉ DES SCIENCES
Rabat
DOCTORAT
Résumé de la Thèse
Discipline : Sciences de l’ingénieur
Spécialité : Informatique et Télécommunications
UFR : Informatique et Télécommunications
Responsable de l’UFR : Prof. Driss ABOUTAJDINE
Période d’accréditation : 2003/2008
Titre de la thèse : Optimisation de requêtes OLAP en Entrepôt de Données
Approche basée sur la fragmentation génétique
Prénom, Nom : ELhoussaine ZIYATI
Résumé
Les systèmes décisionnels manipulent de très importants volumes de données stockées dans
des entrepôts de données. Ces derniers sont alimentés par des données provenant de sources
distribuées et hétérogènes. Les entrepôts de données sont très 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. Les
requêtes 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. 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. Sans technique d’optimisation, leur exécution peut prendre des heures, voire
des jours.
Les travaux présentés dans cette thèse traitent des apports de l’algorithmique génétique à ce
problème. Notre étude se focalise en premier lieu, sur 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. En second lieu, notre intérêt s’est porté à la mise en œuvre de notre approche d’optimisation
de requête. Elle consiste à fragmenter un schéma relationnel d’un entrepôt de données
horizontalement, ensuite verticalement afin de réduire le coût d’exécution de requêtes. Nous avons
formalisé le problème de sélection de schéma de fragmentation verticale comme un problème
d’optimisation avec contrainte. Cette dernière représente le nombre de fragments verticaux que
l’administrateur peut maintenir. Pour le résoudre, nous avons proposé un algorithme génétique qui
adapte le même codage que les algorithmes proposés. Un processus de codage des schémas de
fragmentation possibles est décrit. Un modèle de coût qui représente la fonction sélective a été
développé afin de mesurer la qualité de la solution choisie.
Nous évaluons enfin notre approche, au travers d’expérimentations réalisées à l’aide d’un
banc d’essai et un ensemble de requêtes décisionnelles pour prouver l’efficacité et l’utilité de la
fragmentation mixte génétique, en entrepôt de données.
Mots-clefs (6) :
Entrepôt de données, Algorithme Génétique, Optimisation, Fragmentation,
Requêtes décisionnelles (OLAP).
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
126