Memoire Magister S.hafyane2

Ministère de l’enseignement supérieur et de la recherche scientifique
Institut national de formation en informatique

Oued-Smar Alger
MEMOIRE
Présenté pour l’obtention du diplôme de
MAGISTER
Option : Système d’Information Système de Connaissances et Système
décisionnel (SISCSD)
PAR
SAWSAN HAFYANE
Ingénieur d’état en informatique
Thème
Langage d’interrogation graphique des

bases de données multidimensionnelles
temporelles
Soutenu le devant le jury composé de :

M. D.E.Zegour Professeur / INI Président
M. A.Balla Maître de conférences/ INI Examinateur
M. K.W.Hidouci Maître de conférences/ INI Examinateur
M. F.Ravat Maître de conférences/ IRIT Directeur de mémoire
M. N.Selmoune Chargé de cours / USTHB Codirecteur de mémoire
2007/2008
Dédicace
Je dédie ce mémoire à tous ceux qui m’aiment et que j’aime. Plus

particulièrement à ma mamie chérie.
Remerciements
Mes premiers remerciements vont à mon directeur de mémoire monsieur Franck RAVAT,
qui lorsqu’il nous a donné le cours de « systèmes décisionnels », a renouvelé mon intérêt pour
le domaine. Je souhaite aussi le remercier pour la pleine confiance qu’il m’a accordée dès
l’admission au niveau de son équipe, et pour sa gentillesse et sa patience.
Je tiens à remercier aussi mon codirecteur de mémoire monsieur Nazih SELMOUNE, qui a
su me conseiller efficacement. Ma reconnaissance lui est acquise pour sa disponibilité, son
soutien, sa patience, ses remarques avisées et l’intérêt qu’il a manifesté pour mon travail.
Encore merci à messieurs Franck RAVAT et Nazih SELMOUNE pour la patience dont
ils ont fait preuve face aux lectures et relectures de ce rapport.
Je remercie sincèrement Mademoiselle Leïla BENAKEZOUH pour m’avoir encouragé à

prendre ce sujet, et pour toute son aide.
Mes remerciements vont aussi à Mademoiselle Ammar-Khoudja Nawel pour avoir toujours
été là pour moi.
Je tiens à adresser tous mes remerciements à Monsieur A.Balla, Monsieur K.W.Hidouci et

Monsieur D.E.Zegour pour avoir accepté d’être membres du jury de ce mémoire.
Je remercie sincèrement toutes les personnes proches de mon cœur, mes amis mes proches…
pour leurs soutien, leurs encouragements et leur humour, qui m’ont permis de persévérer.
Résumé
Résumé
Ce travail se situe dans le contexte des systèmes décisionnels et plus
particulièrement, dans le domaine des bases de données multidimensionnelles. Il
consiste à définir un langage d’interrogation graphique de bases de données conçues
selon un modèle multidimensionnel permettant la gestion de l’évolution temporelle des
données et schémas. Après avoir présenté les travaux sur les modèles et les langages
de manipulation multidimensionnels temporels, nous présentons le modèle
multidimensionnel multi-versions sur lequel repose notre travail. Nous abordons, dans
un second temps, le traitement des requêtes temporelles, où nous proposons une
classification de ces dernières. Pour finir, nous proposerons l’intégration de notre
langage dans l’outil Graphic-OLAPSQL.
Mots clés : Base de données multidimensionnelles, modèle multidimensionnel multi-

versions, évolution temporelle des schémas et données, langage de
requête graphique, requête temporelle.
Abstract
This work, belong to the domain of decisional information systems and more
particulary to the domain of multidimensional databases. It tends to define a graphic
query language to interrogate a datebase designed acording a multidimensional model
allowing control of data and schema temporal evolution. After describing the works on
multidimensional models and manipulation languages, we follow by presenting the
multidimensional multiversion model on which is based this work. Later on, we
describe a processing of temporal querries and their classification. Concluding, we
propose integration of our system in the Graphic-OLAPSQL tool.
Key words : Multidimentional database, multidimensional multiversion model,

temporal evolution of data and schema, graphic query language,
temporal query.
Table des matières
Table des matières
Liste des figures

Liste des tableaux
Introduction générale ..............................................................................................................1
I. Contexte du mémoire…………………………………………………………………..1
II. Problématique…………………………………………………………………………2
III. Organisation du mémoire……………………………………………………………. 3
PARTIE 1: Etat de l'art
Chapitre 1 : Concepts de base .................................................................................................5
I. Le Système d’Information Décisionnel (SID)…………………………………………5

I.1 Architecture .....................................................................................................5
I.2 Fonctions .........................................................................................................6
II. Le multidimensionnel…………………………………………………………………7
II.1 Modélisation conceptuelle ..............................................................................7
1.1. Le cube de données ....................................................................................7
1.2. Modélisation basée sur les faits et dimensions.............................................9
II.2 Modélisation logique………………………………………………………... 10
III. Les langages pour bases de données multidimensionnelles………………………...

122
III.1 . Types de langages ..................................................................................... 12
III.2. Opérations multidimensionnelles......………………………………………12
III.3 . Extension de SQL pour le multidimensionnel ............................................ 13
III.4 . Langages graphiques ................................................................................. 14
Chapitre 2 : Evolutions au sein du modèle multidimensionnel .............................................. 17
I. Gestion des évolutions temporelles………………………………………………….. 17

I.1 Approche des Bases de Données Temporelles ................................................ 17
I.2 Approche gestion des versions ....................................................................... 18
I.3 Au niveau des bases de données multidimensionnelles ...................................18
II. Travaux liés aux multi-versions dans le cadre du modèle multidimensionnel………21

II.1 Travaux des auteurs Mathurin Body, Maryvonne Miquel,
Yvan Bédard et Anne Tchounikine ................................................................ 22
II.2 Travaux des auteurs Johann Eder et Christian Koncilia .................................25
II.3 Travaux des auteurs Tadeusz Morzy et Robert Wrembel............................... 28
III. Synthèse……………………………………………………………………………. 32
Table des matières
PARTIE 2: Contributions
Chapitre 3 : Modèle multidimensionnel multi-versions ......................................................... 33
I. Modèle conceptuel multidimensionnel……………………………………………….33

I.1 Représentation de l’espace temps....................................................................... 33
I.2 Constellation et version d’étoile ......................................................................... 34
I.3 Composants d’une version d’étoile ....................................................................35
II. Modèle R-OLAP multi-versions……………………………………………………. 37

II.1 Tables de données : .......................................................................................... 38
II.2 Tables de structure :.......................................................................................... 39
III. Bilan et contribution ……………………………………………………………… 42
Chapitre 4 : Requêtes multidimensionnelles temporelles ....................................................... 45
I. Classification des requêtes 45

I.1 Requête simple ..................................................................................................46
I.2 Requête multidimensionnelle ............................................................................. 46
II. Traitement des requêtes multidimensionnelles 48

II.1 Requête mono-version ...................................................................................... 48
II.2 Requête multi-versions ..................................................................................... 55
III. Conclusion 64
Chapitre 5 : Réalisation ........................................................................................................ 65
I. Existant 65
I.1 Architecture du prototype OLAPSQL + ............................................................. 66
I.2 Commandes du langage OLAP-SQL..................................................................72
II. Extension de Graphic-OLAPSQL…………………………………………………...74

II.1 Extension de la structure de OLAPSQL+………………………………………74
II.2 Extension du langage OLAP-SQL…………...…………………………………76
II.3 Extension de l'interface graphique ...………………………………………...…77
III. Conclusion………………………………………………………………………….78
Conclusion générale et perspectives………………………………………………………….79
Bibliographie
Liste des figures
Liste des figures
Figure Titre Page
FIG 1 Architecture des systèmes décisionnels 5

FIG 2 Exemple : représentation multidimensionnelle (Le cube de données) 8
FIG 3 Le fait Ventes avec ses deux mesures 9
FIG 4 La dimension Temps 9
FIG 5 Exemple d’une modélisation en étoile 10
FIG 6 Exemple d’un tableau multidimensionnel 12
FIG 7 Evolution du schéma S0 vers le schéma S1 20
FIG8 L’outil d’administration COMET 27
FIG 9 Interface utilisateur pour interroger le MVDW 30
FIG 10 Visualisation des résultats d’une requête 30
FIG 13 Classification des requêtes 45
FIG 14 Exemple de constellation composée de deux versions d’étoile 46
FIG 15 Exemple d’un résultat erroné (table multidimensionnelle) 50
FIG 16 Exemple d’un résultat correct (table multidimensionnelle) 50
FIG 17 Résultat de l’exemple 2 (table multidimensionnelle) 51
FIG 18 Résultat correct de l’exemple 2 (table multidimensionnelle) 52
FIG 19 Résultat correct de l’exemple (table multidimensionnelle) 53
FIG 20 Résultat 1 de l’exemple de reclassification (table multidimensionnelle) 53
FIG 21 Résultat 2 de l’exemple de reclassification (table multidimensionnelle) 54
FIG 22 Exemple d’évolutions dans une constellation (plusieurs SV) 58
FIG 23 Résultat partiel sur SVVentes.1 (exemple.1) 62
FIG 24 Résultat partiel sur SVVentes.2 (exemple.2) 62
FIG 25 Résultat global de la requête (exemple 1) 63
FIG 26 Résultat partiel sur SVVentes.1 (exemple 2) 63
FIG 27 Résultat partiel sur SVVentes.2 (exemple 2) 63
FIG 28 Résultat globale (exemple 2) 64
FIG 29 Structure interne de OLAPSQL+ et Graphic-OLAPSQL 67
FIG 30 Interface textuelle de OLAPSQL+ 68
FIG 31 Exemple d’une NJTable résultant d’une requête 69
FIG 32 Visualisation arborescente avec le fait ACHATS déployé 70
FIG 33 Visualisation arborescente avec la dimension Fournisseur déployée 70
FIG 34 Visualisation en graphe d’un schéma multidimensionnel par
Graphic-OLAP-SQL 71
FIG 35 Visualisation hyperbolique d’un schéma multidimensionnel par
Graphic-OLAP-SQL 72
FIG 35 Extension de OLAP-SQL+ (architecture modulaire) 75
FIG 36 Application de l’opérateur DRotate sur un graphe 77
Liste des tableaux
Liste des tableaux
Tableau Titre Page
TAB 1 Exemple vente/catégorie/région 8

TAB 2 Opérations de manipulation d’une TM 13
TAB 3 Montant des ventes de produits en 2005 19
TAB 4 Montant des ventes de produits en 2006 19
TAB 5 Montant des ventes par catégorie en 2005 et 2006 19
TAB 6 Table de version de fait de FVVentes.1 38
TAB 8 Table de version de dimension de DVMagasin.1 39
TAB 9 Table de version de dimension de DVMagasin.2 39
TAB 10 La table de structure « version d’étoile » 40
TAB 11 La table de structure de « VDERIVF » 41
TAB 12 La table de structure de « VDERIVD » 41
TAB 13 La table de structure de «HIERARCHIE » 42
TAB 14 La table de structure « VDERIVD » modifiée 43
F
TAB 15 La table de structure « VDERIV » modifiée 43
F
TAB 16 La table de structure « IDERIV » 44
D
TAB 17 La table de structure « IDERIV » 44
TAB 19 La table de structure « IDERIVF » 48
TAB 20 Table de version de dimension DVMagasin.2 51
TAB 21 La table de structure « IDERIVD » de MAGASIN 51
TAB 22 Table de version de dimension DVProduit.1 53
D
TAB 23 La table de structure « IDERIV » de PRODUIT 53
TAB 24 Opérations du langage OLAP-SQL 66
TAB 25 Traduction des opérations de consultation multidimensionnelles 74
Introduction générale
« La recherche doit avant tout être un jeu et un plaisir.»Pierre Joliot
I. Contexte du mémoire
Dans un contexte économique de mondialisation croissante, les entreprises se développent
dans un environnement en perpétuelle évolution. Le pilotage stratégique de l’entreprise est de
plus en plus complexe et la quantité de paramètres à prendre en compte ne cesse de croître et
de changer. De plus, dans un environnement fortement compétitif, la capacité à réagir est non
seulement un besoin mais surtout un avantage concurrentiel.
Les nouvelles technologies de l’information apportent des solutions efficaces et des outils
performants à ces problématiques avec l'accroissement du potentiel des machines, des
Systèmes de Gestion de Bases de Données (SGBD) et l'évolution d'Internet. Les Systèmes
d’Information (SI) permettent aux entreprises de centraliser les nombreuses informations,
d’extraire les informations décisives et de piloter efficacement la stratégie.
Le Système d’Information Décisionnel (SID) a fait donc, son apparition au côté du

système d’information opérationnel.
L'informatique décisionnelle a pour objectif d'élaborer des systèmes d'analyse de données

dédiés au soutien et à l'amélioration des processus décisionnels des organisations. Ces
systèmes OLAP (On-Line Analytical Processing) sont généralement constitués de bases de
données multidimensionnelles, communément appelées magasins de données (datamarts),
extraits des entrepôts de données (datawarehouses).
Le modèle multidimensionnel est le plus utilisé pour la modélisation de ces Datamarts. Il est
l'un des nouveaux développements remarquables de la conception des bases de données car il
étend de façon considérable les possibilités d'analyse de grands ensembles de données
multidimensionnels. Il connaît un important essor aussi, en raison de son adéquation dans la
manipulation et l'exploitation rapide, efficace et performante des données à des fins
décisionnelles.
Néanmoins, la structure statique de ce modèle peut être une réelle limitation à la prise en
compte de l’évolution des sources de données et des besoins des décideurs. Les données
restituées peuvent donc s’avérer incomplètes ou encore obsolètes. [Benak, 05]
C’est pour cela que de nouveaux modèles dits multidimensionnels temporels ont été
définis, qui intègrent l’aspect temporel dans le modèle multidimensionnel. Ils permettent de
gérer les deux types d’évolutions pouvant survenir au niveau multidimensionnel [Golfa, 05]
à savoir, l’évolution des données et l’évolution du schéma.
Cependant, la recherche dans le domaine des bases de données multidimensionnelles ne se

limite pas à la modélisation de ces dernières. L’interrogation multidimensionnelle des
données représente aussi un axe de recherche important, visant à développer des outils
d'interrogation graphique simples, pour permettre une utilisation plus intuitive de ces bases de
données décisionnelles, dédiées aux décideurs souvent non familiers avec l’informatique.
1
Les premières approches développées nécessitaient la connaissance de la structure de la

base de données et même parfois du langage SQL. Aujourd'hui, ces éléments sont devenus
transparents pour l'utilisateur final, et la facilité d'utilisation des outils s'est accrue.
Dans le contexte décisionnel, ce travail consiste à proposer un langage graphique

d’interrogation des bases de données multidimensionnelles temporelles, qui soit simple et
interactif.
II. Problématique
Beaucoup de nos systèmes d’information ne sont pas préparés pour le changement et les
systèmes multidimensionnels en font malheureusement partie. Or, une gestion inadaptée des
changements de valeurs et de structure dans le schéma du magasin de données peut mener à
de faux résultats d’analyse et engendrer de mauvaises décisions.
Pour remédier à cela, de nombreux travaux de recherche ont proposé de nouveaux modèles,
permettant un traitement correct des évolutions de schéma et de données dans les systèmes
OLAP.
De tels modèles peuvent servir de base pour le développement d’outils OLAP prenant en
compte l’évolution temporelle dans une base de données multidimensionnelle, pour des
résultats corrects de requêtes sur plusieurs périodes.
Cependant, la plupart des propositions existantes se sont axées seulement sur la

modélisation et la représentation conceptuelle des données évolutives en omettant
l’interrogation multidimensionnelle temporelle. De plus, ces solutions ne comportent pas
d’interfaces d’interrogation graphiques et nécessitent la maîtrise du langage SQL, bien
qu’elles soient destinées à des décideurs qui, souvent ne maitrisent pas l’outil informatique.
De plus, les outils commerciaux OLAP actuels, même s’ils s’améliorent d’année en année,
s’avèrent toujours incomplets et imparfaits. En effet, les offres actuelles ne prennent pas en
charge les évolutions temporelles et ne permettent toujours pas aux décideurs de manipuler
simplement et de manière interactive les données décisionnelles en évolution, au travers
d’interfaces intuitives et souples. De plus, elles offrent une vision limitée des données, non
adéquate à la vision des analystes.
C’est pour répondre à cette problématique que nous travaillons sur ce projet dont l’objectif
est de définir un langage graphique pour les manipulations multidimensionnelles des bases de
données intégrant l'évolution des données et du schéma.
Notre travail s’inscrit dans les travaux réalisés au sein de l’équipe SIG (Systèmes
d’Informations Généralisés) de l’IRIT (Institut de Recherche en Informatique de Toulouse.
France). Le modèle multidimensionnel multi-versions de l’équipe, va servir de base pour la
définition de notre langage, nous devrons donc, dans un premier temps, le comprendre, et
éventuellement le compléter.
2
Ce modèle gère les évolutions à travers l’historisation de versions du schéma, créées suite à
des changements de structure. Ceci nous amènera, dans une deuxième étape, à définir le
traitement des requêtes temporelles qui interroge plusieurs versions de schémas d’une base de
données conçue selon ce modèle.
En dernier lieu, nous aurons à introduire notre solution dans l’outil existant
Graphic-OLAPSQL, développé au sein de l’équipe SIG, afin de l’étendre pour qu’il puisse
répondre à des requêtes multi-versions.
En implémentant ce langage, nous devrions aboutir à un outil OLAP grâce auquel

l’utilisateur pourra exprimer ses requêtes à travers des interfaces graphiques, sans forcement
maîtriser le langage SQL. Ces requêtes devront pouvoir interroger plusieurs versions de la
base avec le maximum de transparence pour le décideur.
III. Organisation du mémoire

Après la présentation du contexte général, de la problématique et des objectifs initiaux de
l’étude, le rapport suivant est organisé en deux grandes parties :
La première partie dans laquelle nous avons jugé nécessaire de faire une étude
bibliographique sur « l’interrogation des bases de données multidimensionnelles temporelle ».
Cette partie est composée des deux chapitres suivants :
 Chapitre I : Etant donné que la modélisation multidimensionnelle est utilisée dans les
bases de données décisionnelles, cet état de l’art débute par une présentation du système
d’information décisionnel, suivi de la modélisation multidimensionnelle et ses
évolutions. Nous avons aussi consacré une partie à l’étude des langages de manipulation
multidimensionnelle.
 Chapitre II : Ce chapitre regroupe les travaux faits dans le contexte des bases de données
multidimensionnelles évolutives, en particulier ceux gérant plusieurs versions du
schéma.
La deuxième partie présente notre contribution, qui consiste à concevoir un outil

graphique, orienté décideur, pour l’interrogation des bases de données multi-versions
intégrant l'évolution des données et des schémas.
 Chapitre III : Ce chapitre présente le modèle multidimensionnel multi-versions sur

lequel repose notre travail. Nous proposons à la fin de ce chapitre quelques
améliorations au modèle ainsi qu’un ensemble de contraintes qu’il doit respecter pour
garantir son intégrité.
 Chapitre IV : représentant le cœur de notre travail, ce chapitre explicite la solution que

nous proposons pour le traitement des requêtes OLAP temporelles. Il commence par
une classification de ces requêtes, suivie du traitement de chacune.
3
 Chapitre V : Étant donné que notre travail s’inscrit parmi les travaux de l’équipe SIG,
nous décrivons au début de ce chapitre l’architecture de l’outil développé au sein de
cette équipe avant d’exposer les modifications que nous venons y apporter pour
implanter notre langage. Nous proposons aussi dans ce chapitre, une commande de
sélection (extension du select de SQL) qui permet d’exprimer une requête
multidimensionnelle multi-versions.
Une conclusion générale fera le point sur notre recherche et présentera nos perspectives.
4
Partie 1
ETAT DE L’ART
Etat de l’art Chapitre I : Notions de base
Chapitre 1 : Concepts de base

«La pire décision de toutes est celle que l'on n'a pas prise.» Zig Ziglar
Ce premier chapitre représente une étude bibliographique sur les bases de données
multidimensionnelles temporelles et les langages d’interrogation de ces dernières. Il est
organisé en trois parties. La première traite du contexte de ce travail qu’est le décisionnel, la
seconde présente le modèle multidimensionnel et la troisième et dernière partie liste les
principaux travaux sur les langages d’interrogation des bases de données
multidimensionnelles.
I. Le Système d’Information Décisionnel (SID)

Avec l’apparition de l’ordinateur et son fort potentiel de manipulation des données, le
volume des informations stockées n’a cessé d’augmenter. Informations que les entreprises
cherchent à exploiter tant au niveau opérationnel qu’au niveau décisionnel.
Ainsi, nous devons distinguer deux sortes de systèmes : le système transactionnel qui gère
le quotidien opérationnel de l’entreprise, et le système décisionnel qui va analyser les
données stockées.
Le système d'information décisionnel, ou SID, correspond à l'exploitation des données de

l'entreprise dans le but de faciliter la prise de décision par les décideurs, c'est-à-dire la
compréhension du fonctionnement actuel et l'anticipation des actions pour un pilotage
éclairé de l'entreprise.
I.1 Architecture
L'architecture des systèmes décisionnels met en jeu quatre éléments essentiels : les
sources de données, l'entrepôt de données, les magasins de données et les outils d'analyse
et d'interrogation. La figure suivante représente l’architecture d’un système décisionnel.
Cadre des bases de données multidimensionnelles
Serveurs de données Entrepôt de Magasins de données Utilisateurs / Analyse
opérationnelles données
Positionnement du sujet de ce mémoire

FIG 1 : Architecture des systèmes décisionnels
5
Les sources de données sont nombreuses, variées, distribuées et autonomes. Elles

peuvent être internes (bases de production) ou externes (Internet, bases des partenaires) à
l'entreprise.
L'entrepôt de données est le lieu de stockage centralisé des informations utiles pour les
décideurs. Il met en commun les données provenant des différentes sources et conserve
leurs évolutions.
Le créateur de ce concept, Bill Inmon, définit l’entrepôt de données comme suit : «Un
datawarehouse est une collection de données thématiques, intégrées, non volatiles et
historisées, organisées pour le support d’un processus d’aide à la décision».
Les magasins de données sont des extraits de l'entrepôt orientés sujet, adaptés à une
classe de décideurs. Les données sont organisées de manière adéquate pour permettre des
analyses rapides à des fins de prise de décision.
Les outils d'analyse permettent de manipuler les données suivant des axes d'analyse.
L'information est visualisée au travers d'interfaces interactives et fonctionnelles dédiées à
des décideurs souvent non informaticiens (directeurs, chefs de services, etc.).
I.2 Fonctions
Les données opérationnelles sont souvent disséminées dans l’entreprise dans des
systèmes hétérogènes. Pour centraliser et automatiser le traitement de ces données, le
Système d’Information Décisionnel va remplir trois fonctions : extraction des données,
leur stockage et la restitution des données sous une forme exploitable. [Serre, 04]
- L’extraction, souvent effectuée à l’aide d’un outil d’ETL (Extract, Transform, Load),
consiste à aller chercher les données là où elles se situent, à les trier, et à les transformer
éventuellement afin d’effectuer un prétraitement pour faciliter l’analyse.
Dans cette phase se fait également le nettoyage des données : l’homogénéisation, la

suppression des doublons, la détection de données non conformes. Ensuite, les données
sont centralisées dans des bases de données du Datawarehouse.
- Le stockage sert à structurer les données au sein des deux structures de stockage du
système décisionnel : l’entrepôt de données (Datawarehouse) et les magasins de données
(Datamarts).
Dans l’architecture que présente la figure (Fig I.1), le datawarehouse joue le rôle de
centralisateur et d’intégrateur de l’information. Il garantit l’intégrité des données et
optimise l’approvisionnement des datamarts.
Les datamarts récupèrent les données du datawarehouse centralisé dans des structures
conçues en fonction de la problématique métier à laquelle ils répondent. Ils présentent de
nombreux points forts : ayant un volume de données moins important qu’un
datawarehouse, leur mise en place ne demande pas beaucoup de temps, ils nécessitent des
ressources matérielles moins grandes et présentent une rapidité de réponse plus élevée.
6
- La restitution ou reporting, c’est la face visible du décisionnel, la partie que voient

les utilisateurs. Elle consiste en l’analyse des données, à travers la formulation de requête
et la visualisation des résultats, et à la diffusion des informations. Les résultats doivent
répondre du mieux possible aux différents impératifs de restitution: clarté et fluidité,
précision mais concision.
Les outils de restitution peuvent être regroupés en plusieurs catégories : les outils de
reporting, les tableaux de bord (EIS Executive Information System), les outils d’analyse
multidimensionnelle (OLAP On Line Analytical Processing), les outils de datamining.
Notre travail, porte principalement sur les magasins de données. Dans ce cadre là, le
modèle de données le plus répandu est le modèle multidimensionnel [Golfarelli et al,
2002]. Nous allons, donc, nous intéresser de plus près à la modélisation
multidimensionnelle dans la partie suivante de ce chapitre.
II. Le multidimensionnel
Un modèle multidimensionnel consiste à considérer un sujet analysé comme un point dans
un espace à plusieurs dimensions. Les données sont organisées de manière à mettre en
évidence le sujet analysé et les différentes perspectives de l’analyse [Teste, 2000].
Ce modèle de données permet d’observer les données sous plusieurs perspectives. Son axe
d’analyse facilite l’accès aux données. Il est plus facilement compréhensible, même pour les
personnes qui ne sont pas expertes en informatique. [Bella, 00]
Dans la modélisation multidimensionnelle nous distinguons trois niveaux d’abstraction, à

savoir : le niveau conceptuel, le niveau logique et le niveau physique.
II.1 Modélisation conceptuelle
Au niveau conceptuel, il s’agit de présenter les données sous plusieurs dimensions selon
les besoins des décideurs, on faisant abstraction des aspects techniques.
La modélisation conceptuelle se fait soit à travers le cube de données ou les concepts de

fait et de dimensions. [Kimball, 96]
II.1.1 Le cube de données
Le cube de données 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 dimensions qui
déterminent une mesure d’intérêt. Une dimension spécifie la manière dont on observe les
données pour les analyser, alors qu’une mesure est un objet d’analyse.
7
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érarchies associées qui
organisent les attributs en 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.
Exemple : [Teste, 01]

Considérons les données suivantes : Ventes en 1999
Catégories des produits Régions Montant des ventes

Électroménager Midi-Pyrénées 50
Électroménager Aquitaine 40
Électroménager Languedoc-Roussillon 30
Papeterie Midi-Pyrénées 60
Papeterie Languedoc-Roussillon 50
Bricolage Midi-Pyrénées 30
Bricolage Aquitaine 30
TAB 1 : Exemple vente/catégorie/région

Maintenant, si nous considérons plusieurs tables, relatives aux ventes de chaque année
entre 1997 et 1999. On peut alors observer les données dans un espace à trois dimensions :
la dimension catégorie, la dimension région et la dimension temps. Chaque intersection de
ces dimensions représente une cellule comportant le montant des ventes, comme le montre
la figure.
FIG 2: Exemple : représentation multidimensionnelle

(Le cube de données)
Le cube de données est une abstraction conceptuelle regroupant une structure de données
multidimensionnelle avec les valeurs associées. Dans les sections suivantes, nous étudions
en détail les différents composants d'un schéma multidimensionnel.
8
II.1.2 Modélisation basée sur les faits et de dimensions
 Fait
Le fait modélise le sujet d’analyse. Un fait est composé de mesures représentant les
informations de l’activité à analyser via des fonctions d’agrégation.
Exemple 1 : La figure suivante présente le fait « VENTES » et ses mesures « Montant »

et « Quantité ».
FIG 3 : Le fait Ventes avec ses deux mesures
 Dimension et de hiérarchie
Le fait est analysé selon différents axes appelés dimensions. Une dimension modélise
donc une perspective d’analyse selon laquelle sont visualisées les mesures du fait.
Une dimension est composée de paramètres qui représentent les niveaux de visualisation
des mesures d’analyse. Ces paramètres peuvent être accompagnés de descripteurs, qui sont
les attributs faibles, et sont organisés selon leur niveau de détail (granularité) en une ou
plusieurs hiérarchies, de la granularité la plus fine vers la granularité la plus générale.
Les concepts multidimensionnels (faits, dimensions, hiérarchies, etc.) peuvent être

représentés au travers d’un formalisme graphique spécifique. La Figure 4 présente la
dimension «Temps », ainsi que ses hiérarchies, paramètres et attributs faibles.
Exemple 2 : La figure suivante présente la dimension « Temps ».
Temps Dimension
Paramètre Temps
Jour
Jour_desc Hiérarchie
Mois
Mois_desc
Année Attribut
FIG 4 : La dimension Temps.
9
 Modèles en étoile et en constellation [Teste, 01] [Benak, 05]
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. Ce modèle représente visuellement une étoile,
on parle de modèle en étoile (star schema [Kimball, 1996]).
Exemple : La Figure suivante décrit le schéma en étoile modélisant les analyses des
quantités et des montants des ventes selon trois dimensions : le temps, le produit et le
département.
FIG 5 : Exemple d’une modélisation en étoile
L'avantage de cette modélisation est de formaliser une hiérarchie au sein d'une dimension.
Par contre, la modélisation en flocon induit une dénormalisation des dimensions générant
une plus grande complexité en termes de lisibilité et de gestion.
Une autre variante du modèle en étoile, est la modélisation en constellation. Il s'agit de

fusionner plusieurs modèles en étoile qui utilisent des dimensions communes. Un modèle en
constellation comprend donc plusieurs faits et des dimensions communes ou non.
II.2 Modélisation logique [Bella, 00]

Selon la façon dont le cube de données est stocké, il existe deux approches fondamentales
pour construire des systèmes basés sur le modèle multidimensionnel. L’approche MOLAP
(Miltidimensional OLAP) implémente le cube de données dans un tableau
multidimensionnel. Par contre, l’approche ROLAP (Relational OLAP) utilise un SGBD
relationnel pour gérer et stocker le cube de données.
II.2.1 Les systèmes MOLAP

Les systèmes de type MOLAP (Multidimensional OLAP) stockent les données dans un
SGBD multidimensionnel sous la forme d’un tableau multidimensionnel. Chaque dimension
du tableau est associée à une dimension du cube. Seules les valeurs de données
correspondant aux données de chaque cellule sont stockées.
10
Les systèmes MOLAP apparaissent comme une solution acceptable pour le stockage et
l’analyse d’un magasin de données lorsque la quantité estimée de données ne dépasse pas
quelques gigaoctets et lorsque le modèle multidimensionnel évolue peu. Mais, lorsque les
données sont éparses, ces systèmes sont consommateur d’espace et des techniques de
compression doivent être utilisées.
II.2.2 Les systèmes ROLAP
Les systèmes de type ROLAP utilisent un SGBD relationnel pour stocker les données de
l’entrepôt. Il représente une interface multidimensionnelle pour le SGBD relationnel.
Dans ces systèmes, la table de fait et traduite en une relation et chaque dimension en une
ou plusieurs relations selon qu’elle soit normalisée ou pas.
Si les tables de dimension sont normalisées, chaque dimension est traduite par plusieurs
tables, et le modèle résultant est dit en flocon (snowflake). Une modélisation en flocon
consiste à décomposer les dimensions du modèle en étoile en sous hiérarchies. Chaque
niveau hiérarchique d’une dimension est traduit en une table.
Exemple : reprenons l’exemple précédent (schéma de la figure 5) ;
ROLAP dénormalisé donne les tables suivantes : Ventes, Produits, Département, Temps.
ROLAP normalisé : le fait Ventes est traduit en une table, la dimension Temps en les
tables : Jour, Mois, Année et Semaine, la dimension Département en les tables :
Département et Division, et la dimension Produits en deux tables : Produit et Catégorie-
produit.
Le moteur ROLAP est un élément supplémentaire qui fournit une vision

multidimensionnelle de l’entrepôt, des calculs de données dérivées et des agrégations à
différents niveaux. Il est aussi responsable de la génération de requêtes SQL mieux adaptées
au schéma relationnel, qui profitent des vues matérialisées existantes pour exécuter
efficacement ces requêtes.
Ces systèmes peuvent stocker de grands volumes de données, mais ils peuvent présenter
un temps de réponse élevé. Les principaux avantages de ces systèmes sont :
- Une facilité d’intégration dans les SGBD relationnels existants,
- Une bonne efficacité pour stocker les données multidimensionnelles.
II.2.3 Les systèmes HOLAP

Les systèmes HOLAP (Hybride OLAP) essaient de tirer les bénéfices des deux systèmes
précédemment décrits. Dans les systèmes HOLAP, les données sont maintenues par un
SGBD relationnel, tandis que les agrégations le sont par un SGBD multidimensionnel.
En général, dans cette approche, les données consultées fréquemment sont matérialisées
sous forme multidimensionnelle pour un accès rapide, et les autres données sont laissées
dans la base relationnelle pour être extraites directement lors des requêtes ;
11
III. Les langages pour bases de données multidimensionnelles

La représentation multidimensionnelle des données induit de nouveaux langages constitués
de nouvelles opérations liées à l'aspect "analyse". Ces opérations peuvent être classées selon
le type de langage.
III.1 . Types de langages

Les langages dédiés aux bases de données multidimensionnelles sont classés en trois types
[Ravat et al, 02] à savoir :
 Le langage de Définition des Données (LDD) : ce langage définit les opérateurs

nécessaires à la définition d’un schéma multidimensionnel (définition des faits,
dimensions et hiérarchies) ainsi qu’à la modification de ses éléments ou encore leur
suppression ;
 Le langage de Manipulation des Données (LMD) : ce langage définit les opérations

nécessaires à la mise à jour ainsi qu’à la consultation des données ;
 Le langage de Contrôle des Données (LCD) : Ce langage définit les opérations
nécessaires à l’affectation et à la suppression des droits des utilisateurs sur les éléments
du schéma multidimensionnel.
III.2 . Opérations multidimensionnelles

Les opérations multidimensionnelles sont liées aux structures et au niveau d'observation des
valeurs, appelé niveau de granularité des données. Des opérations ont été proposées
[Ravat et al, 02] pour la création et la manipulation de tables multidimensionnelles :
III.2.1 Construction d’une table multidimensionnelle

La construction d’une table multidimensionnelle se fait par la fonction DISPLAY (NCS, F,
[{f1(m1), f2(m2),…}], DL, [HL], DC, [HC]) = TR , avec les arguments suivants :
• NCS : nom de la constellation,
• F : fait analysé (sujet de l'analyse),
• {f1(m1), f2(m2),…} : mesures et fonctions d'agrégations de F
• DL : dimension en ligne avec HL comme hiérarchie courante,
• DC : dimension en colonne avec HC comme hiérarchie courante.
Exemple : DISPLAY (C,VENTES,{sum(Montant), Sum(Bénéfices)},TEMPS,MAGASINS)
VENTES MAGASINS
(Montant, Bénéfices) Villes Toulouse Lyon Dallas
TEMPS Années
2002 (20, 2) (30, 4) (20, 3)
2001 (10, 2) (20, 4) (30, 5)
2000 (20, 5) (20, 3) (20, 1)
1999 (30, 6) (10, 2) (10, 1)
PRODUITS.Classes='C2'
FIG 6: Exemple d’un tableau multidimensionnel
12
III.2.2 Manipulation d’une table multidimensionnelle
Le tableau suivant résume les opérations de manipulation de table multidimensionnelle (TM) :

Catégorie Opérateur Description
DrillDown Forage vers le bas
Forage
RollUp Forage vers le haut
Frotate Rotation de faits
Paramétrage
Rotation Drotate Rotation de dimensions
d'une TM
Hrotate Rotation de hiérarchies d'une dimension
Select Sélection de valeurs de paramètres ou de mesures
Sélection
UnSelect Désélection
Switch Permutation de deux valeurs d'un même paramètre
Permutation
Présentation de paramètres Order Ordonnancement de valeurs de paramètres
d'une TM Nest Permutation de deux paramètres
Cube Permet de spécifier une fonction d'agrégation
Calcul
Uncube Permet de supprimer une fonction d'agrégation
Modification DelM Suppression d'une mesure
Transformation du fait AddM Ajout d'une mesure
d'une TM Modification Push Transformation d'un paramètre en mesure
dimension Pull Transformation d'une mesure en paramètre.
TAB 2 : Opérations de manipulation d’une TM
III.3 . Extension de SQL pour le multidimensionnel
La majorité des outils du marché proposent une modélisation R-OLAP. Dans ces
systèmes, chaque dimension est implantée sous la forme d’une table. Chaque fait est défini
par une table et son identifiant est une clé primaire composée des clés étrangères
correspondantes aux dimensions liées.
Néanmoins, le langage assertionnel standard des bases relationnelles (SQL (Iso, 1992))
n'est pas adapté et manque d'expressivité pour la définition d’une base multidimensionnelle.
C’est pour cela que les SGBD relationnels (Oracle, MS SQL Server…), étendent le
langage d'interrogation SQL. Oracle étend l'opérateur GROUP BY en intégrant les
commandes CUBE et ROLL UP qui permettent l'expression de calculs de sous totaux. MS
SQL Server propose une extension de la clause SELECT permettant l'affichage et la
navigation des données en colonne et en ligne.
Cependant, les SGBD relationnels tendent à intégrer certains concepts de l'approche

OLAP mais ils restent incomplets et ne profitent pas de la puissance des concepts
multidimensionnels.
Dans [Ravat et al, 02] est proposé un langage dédié aux bases multidimensionnelles
implantées sous une forme Relationnal-OLAP (OLAP-SQL); ce langage intègre les
commandes de définition, de contrôle et de manipulation d’une base de données
multidimensionnelle organisée en constellation.
13
Ce langage repose sur l'extension multidimensionnelle du standard SQL. Le langage de

définition (OLAP-LDD) permet de spécifier simplement les composants (faits, dimensions,
hiérarchies) du schéma multidimensionnel avec une abstraction complète des tables
relationnelles. Le langage de contrôle (OLAP-LCD) permet de définir de manière uniforme
des droits sur tout ou partie du schéma. Enfin, le langage de manipulation (OLAP-LMD)
offre un mécanisme unique de consultation reposant sur l'extension de la commande
SELECT.
III.4 . Langages graphiques
Quelques travaux de recherche, ainsi que des outils commerciaux, ont proposés des
interfaces graphiques dédiées au multidimensionnel.
III.4.1 . Langages graphiques de définition
Des outils sont disponibles pour assister l'administrateur dans la construction des entrepôts
et des magasins de données (Data Mart Builder, SAS/Warehouse Administrator, warehouse
Manager). Avec ces outils, le schéma de l'entrepôt ou du magasin doit être construit au
préalable. L'administrateur a la charge d'associer chaque attribut cible de ce schéma à un
attribut d'une source de données.
Une approche [Fred, 99] se distingue en proposant des interfaces graphiques qui aident
l'administrateur du système décisionnel lors du processus de construction de l'entrepôt et des
magasins de données. Il présente une interface de construction de l'entrepôt de données
basée sur un modèle conceptuel orienté objet. Il présente également une interface de
construction des magasins de données permettant de réorganiser les données de l’entrepôt
selon un modèle orienté objet multidimensionnel.
D’autres langages de définition de données graphiques, ont été proposés, opérant via
l’intermédiaire d’éditeurs graphique de schémas multidimensionnels.
[Golfarelli et al. 2001,2002] avec son outil de conception assistée par ordinateur, WAND.
[Sapia et al. 1999], propose un éditeur basé sur le modèle Entité/Association.
[Trujillo et al. 2002] propose une extension d’UML pour modéliser les bases
multidimensionnelles.
Au sein de l’équipe SIG, des travaux ont proposé des interfaces graphiques qui aident
l’administrateur du système décisionnel lors du processus de construction de l’entrepôt et du
magasin de données.
Au sein de cette même équipe, une autre approche [Annoni, 03] propose un langage
assertionnel pour les bases de données multidimensionnelles. Ces travaux proposent une
implantation d’un langage graphique de définition de données basé sur une algèbre
multidimensionnelle [Ravat et al, 02]. Il présente également le prototype OLAP-SQL+.
14
III.4.2 Langages graphiques de contrôle
Peu de recherches abordent la gestion de droits dans les bases multidimensionnelles.

Parmi les offres commerciales, la gestion de droits ne donne pas lieu à une proposition
spécifique liée au contexte multidimensionnel.
[Ravat et al, 02] propose le langage OLAP-LCD. Les commandes de ce langage

permettent de définir de manière flexible des droits utilisateurs en fonction des différents
types de décideurs. La contribution majeure réside en la définition de droits directement sur
les composants (fait, dimension, hiérarchie) du schéma en constellation. Toutefois,
l’affectation des droits se fait de manière textuelle et non pas à travers des interfaces
graphiques.
III.4.3 Langages graphiques de manipulation
Le magasin de données est généralement destiné aux décideurs de l’entreprise souvent

non spécialistes de l’informatique. Il doit, donc, être muni d’interfaces graphiques adaptées
à des utilisateurs non informaticiens.
Cependant, les travaux sur les langages de manipulation graphique, sont beaucoup plus
rares que ceux sur les langages de définition graphique.
[Cabibbo, 1998] propose en plus d’une algèbre, un langage de manipulation graphique

simple. [Böhnlein et al. 2002] propose un requêteur graphique basé sur une interface
utilisateur simple et conviviale. Mais ces travaux ne s’appuient pas sur une algèbre
multidimensionnelle et le formalisme du modèle employé, le SDWM (Semantic Data
Warehouse Model), est trop chargé pour des représentations de schémas en constellation.
Au sein de l’équipe SIG, dans [Tournier, 04], est proposé un langage graphique de
manipulation et d’interrogation de données basé sur une algèbre multidimensionnelle
[Ravat et al, 02]. Ces propositions ont été validées par l’implantation du prototype Graphic-
OLAP-SQL
Graphic-OLAP-SQL est un outil graphique qui repose sur un ensemble d'interfaces

utilisateurs permettant de définir, de manipuler, de visualiser et de consulter des bases de
données multidimensionnelles structurées en constellation. Il intègre essentiellement deux
modes de fonctionnement : textuel au travers du langage OLAP-SQL, et Graphique au
travers d'un graphe de visualisation de la constellation.
Quant aux outils commerciaux, ils s’améliorent d’année en année. Nous pouvons citer :
- COGNOS PowerPlay 7.3 : Numéro un mondial du « business intelligence », ce logiciel,

outil d’analyse OLAP, se présente sous la forme d’un tableur muni de fonctions très évolué.
Il permet l’analyse d’un cube de données (un schéma en étoile). La représentation
conceptuelle du cube se fait sous la forme d’arborescence.
Les requêtes se font par glisser déplacer des éléments (mesures, dimensions, hiérarchies
paramètres et attributs faibles) vers la fenêtre de présentation des résultats (un tableur), en
les positionnant en lignes ou en colonnes.
15
- CRYSTAL Analysis 10 : Crystal Decisions, acquisition du géant Business Objects,

développe Crystal Analysis, un outil de visualisation de résultats et une extension pour
Excel. Il propose pour la visualisation des données conceptuelle la même arborescence
utilisée par tous les concurrents et se limite aussi à la visualisation d’un seul fait à la fois.
Des fonctionnalités avancées de sélection sont misent en avant mais elles requièrent toutes
de maîtriser un langage de requête textuel (SQL en général).
-RATIONAL Rose XDE : Rose XDE, un éditeur de schémas UML très connu est édité par
Rational Software, racheté par IBM. Mais comme UML étant une méthode sur le paradigme
objet, la modélisation multidimensionnelle via XDE n’est donc pas indépendante de
l’architecture sous-jacente et impose le support du paradigme objet.
Selon [Tournier, 04], ces logiciels bien que puissants et faciles d’utilisations, souffrent de
l’absence de visualisation globale du schéma multidimensionnel car il se limite à la
présentation d’un unique schéma en étoile. De plus, le système de visualisation par
arborescence est absolument inutilisable en cas de schéma large, imposant un parcours lent
et fastidieux.
Il existe aussi des outils issus de l'industrie, qui se concentrent essentiellement sur les
aspects de l'interrogation.
Plusieurs requêteurs (Business Objects, Impromptu, Discover2000) et outils OLAP

(Powerplay, Discover, Essbase, Express, Mercury) sont proposés.
Les requêteurs facilitent la construction de requêtes SQL (jointures masquées, alias de

noms d'attributs,…). Les outils OLAP se concentrent sur l'analyse multidimensionnelle en
proposant des objets graphiques (tableaux croisés,…). Ces outils manipulent les données de
l'entrepôt ou des magasins.
Cependant, même si les requêteurs graphiques sont simples et facilitent l'accès aux
informations, ils restent limités pour un processus d'analyse complexe. Les outils
spécifiques OLAP offrent de nombreuses possibilités de manipulation multidimensionnelle
mais ils sont difficiles d'accès pour les non informaticiens. [Ravat et al, 02]
16
Etat de l’art Chapitre II : Evolutions au sein du modèle multidimensionnel
Chapitre 2 : Evolutions au sein du modèle

multidimensionnel
«L'infini n'est pas un état stable, mais la croissance elle-même.»Aristote
Conserver les données passées afin de mieux appréhender le présent et anticiper le futur est
une caractéristique majeure des entrepôts et des magasins de données ; le terme d'historisation
des données est employé.
Les données sources sont issues essentiellement des systèmes opérationnels (OLTP), ces
données sont peu ou pas historisées : Certaines évolutions ne sont pas conservées, la période
de conservation des données temporelles est courte et les dates sont stockées sous forme d'un
simple attribut.
Les bases de données décisionnelles doivent palier à ces insuffisances en terme de

conservation des évolutions pour servir de support efficace aux techniques d'analyse de type
OLAP (On-Line Analytical Processing) utilisées lors de la prise de décision. [Laurent et al]
La dimension temporelle des données ne doit pas être considérée comme une dimension
quelconque, pour permettre d'exprimer des requêtes temporelles complexes.
Dans le contexte des entrepôts de données, de nombreux problèmes liés à la représentation

du temps se posent, et il est nécessaire de concevoir des moyens permettant de manipuler
simplement le temps.
L’objectif de cette partie est de présenter les travaux concernant la prise en compte de
l’évolution des données et schémas dans le cadre des bases de données multidimensionnelles.
Ces travaux se sont basés sur ceux effectués dans les domaines de base de données
temporelles et les bases de données intégrants des versions.
Nous allons donc présenter les travaux effectués dans les deux domaines, avant d’aborder
l’évolution temporelle dans le cadre des bases de données multidimensionnelles.
I. Gestion des évolutions temporelles

I.1 Approche des Bases de Données Temporelles
La première approche pour gérer l’évolution d’entités a été d’intégrer le temps au niveau
de leur représentation dans la base de données. [Benak, 05], d’où les bases de données
temporelles.
Les bases de données temporelles offrent les concepts et les fonctionnalités permettant
aux applications de dater les informations et de gérer l'histoire de leurs évolutions,
contrairement aux bases de données traditionnelles qui offrent une vision instantanée des
données (définies par la dernière mise à jour de la base). [Teste, 01]
17
Les premiers travaux ont porté sur l’extension du modèle relationnel et d’autres ont été
développés autour de modèles orientés objets [Hubert, 97].
Concernant les modèles relationnels, deux approches se distinguent [Hubert, 97]. La

première consiste à intégrer le temps au niveau des n-uplets et l’autre, au niveau des
attributs d’une entité:
 La première approche consiste à associer un intervalle de temps à l'objet (de type [Date
début de validité, Date fin de validité]). A chaque modification de la valeur d'un des
attributs, un nouvel état est décrit. Ce nouvel état contient une valeur pour chacun des
attributs. D'un état à l'autre, les attributs n'ayant pas été modifiés ont la même valeur.
 La deuxième approche consiste à associer un intervalle de temps aux attributs. Chaque

changement de la valeur d'un attribut est conservé. La valeur qu'il possédait
précédemment est associée à un intervalle de temps borné et la nouvelle valeur à un
intervalle de temps non borné. Les différentes valeurs prises par un attribut sont
conservées indépendamment des changements de valeurs des autres attributs.
Dans les bases de données temporelles, les évolutions des valeurs sont toutes conservées.
Ceci induit l'inconvénient majeur de générer des volumes de données très importants,
altérant rapidement le fonctionnement de la base. Des données temporelles doivent alors
être soit supprimées de la base ou bien archivées. [Teste, 01]
I.2 Approche gestion des versions
Les modèles de gestion de versions sont une solution permettant de gérer les évolutions au
niveau des bases de données en gardant les versions antérieures et postérieures aux
évolutions. [Benak, 05]
Concernant la gestion des évolutions d’instances, trois grandes approches se sont

distinguées [Hubert, 97]. La première concerne les modèles de gestion de versions
d’attributs et s’inspire des études effectuées dans les bases de données temporelles. La
seconde approche propose la gestion des versions d’objets et la conservation des instances
de l’objet et non des attributs séparément. Quant à la dernière approche, elle préconise la
gestion de versions de contextes. Le principe étant de regrouper des versions d’entités selon
une signification précise.
L’évolution du schéma de la base de données a également été abordée par l’approche des
versions [Hubert, 97]. Cela consiste à conserver les schémas, avant et après modification,
en sachant que toute modification donne lieu à une nouvelle version et que toutes les
versions sont conservées.
I.3 Au niveau des bases de données multidimensionnelles
De nombreux auteurs, tels que Golafarelli [Golfarelli et al, 05], ont classé les évolutions
pouvant survenir au niveau multidimensionnel en deux types :
 Evolution des données : insertion/mise à jour/suppression d’enregistrements ;
 Evolution des schémas : le schéma multidimensionnel peut évoluer en réponse à de
nouveaux besoins d’analyse ou encore à l’évolution naturelle des éléments analysés.
18
I.3.1 Exemples d’évolutions temporelles au niveau multidimensionnel
Pour mieux voir les conséquences que peut avoir le fait de ne pas considérer ces deux
types d’évolutions dans le modèle multidimensionnel sur l’analyse de données, nous
présentons deux exemples parlants, extraits de [Benak, 05].
Exemple 1 : Evolution de données : insertion de nouveaux produits.
Considérons les tableaux suivants qui représentant les montants des ventes de produits
réalisées durant les années 2005 et 2006.
Année 2005
Produit Désignation Catégorie Montant des ventes
P1 PC Portable Toshiba C1 257
P2 PC Portable Dell C1 468
P3 PC LG C2 378
P4 Chaîne HiFi Samsung C3 265
TAB 3 : Montant des ventes de produits en 2005
Année 2006
Produit Désignation Catégorie Montant des ventes
P1 PC Portable Toshiba C1 365
P3 PC LG C2 278
P4 Chaîne HiFi Samsung C3 377
P5 Ipod nano v768 C4 225
TAB 4 : Montant des ventes de produits en 2006
Supposons maintenant la requête suivante « le montant des ventes réalisées par catégorie
et par année » dont les résultats sont représentés par le tableau suivant.
Catégorie Année 2005 Année 2006 Évaluation

C1 725 365 -
C2 378 278 -
C3 256 377 +
C4 ? 225 ?
TAB 5 : Montant des ventes par catégorie en 2005 et 2006
L’interprétation des résultats de cette requête pourrait être faussée si l’utilisateur (les
décideurs, en général) n’a pas pris connaissance du fait que le produit P2 n’était plus en
vente en 2006 (ce qui justifie la baisse du montant des ventes de la catégorie C1) et que le
produit P5 n’a été commercialisé qu’à partir de l’année 2006 (ce qui justifie que le montant
des ventes pour la catégorie C4 sur les deux années est le plus bas).
Cet exemple montre que le fait de ne pas considérer l’évolution des données au sein des
bases de données multidimensionnelles, peut entraîner des analyses incomplètes ou encore
incohérentes.
19
Exemple 2 : Evolution de schémas
Supposons le schéma multidimensionnel (S0) représenté dans la figure suivante (en haut, à
gauche de la figure). A t= 01/01/2006, supposons les évolutions suivantes :
♦ Le niveau de granularité « Jour » disparaît de la dimension « Temps » ;

♦ Une classification en super-catégories est introduite dans la dimension « Produit »
(nouveau niveau de granularité) ;
♦ Une nouvelle mesure « Montant-Fr » est ajoutée, elle permet le calcul des montants de
vente en francs ;
♦ Une nouvelle dimension « Client » est ajoutée au schéma en étoile.
FIG 7 : Evolution du schéma S0 vers le schéma S1
Suite à ces évolutions, nous aboutissons au schéma multidimensionnel, noté « S1 » (en

bas, à gauche de la figure).
Si on considère que seule la dernière version du schéma multidimensionnel est conservée

(S1), les requêtes ne permettront pas de retourner certaines données qui n’ont pas de
correspondance dans ce nouveau schéma. Il n’est donc pas possible de répondre, par
exemple, à la requête suivante : ‘montant des ventes par produit et par client pour les années
2005 et 2006’, car on ne dispose pas des données concernant les clients pour l’année 2005.
Pour la cohérence des requêtes pouvant impliquer une période de temps plus large, ou
encore antérieure, à la date à laquelle a été crée le schéma, il est évident que les anciennes
versions de schémas doivent être historisées [Golfarelli et al, 05].
20
I.3.2 .Travaux relatifs à l’évolution temporelle au niveau

multidimensionnel
Contrairement aux bases de données temporelles, domaine qui a été largement traité, peu
d’approches concernant les bases de données multidimensionnelles sont connues de la
littérature. Selon [Eder et al, 05], on peut distinguer les travaux suivants selon qu’ils
abordent l’évolution des données, des schémas ou encore les deux aspects.
Au sein de la catégorie de travaux relatifs à l’évolution des schémas, nous pouvons citer
les travaux de Marcus Blashka. Le système FIESTA, proposé par l’auteur, dans
[Blaschka, 00], présente une méthodologie permettant la prise en compte des évolutions des
schémas multidimensionnels.
Pour ce qui est des travaux relatifs à l’évolution des données, parmi les premiers de cette
catégorie, nous pouvons citer ceux de Ralph Kimball [Kimball, 96]. L’auteur propose trois
façons de gérer les évolutions. La première ne garde pas trace de l’historique des évolutions,
la seconde crée un nouvel enregistrement pour la donnée modifiée, et la troisième consiste à
ajouter une colonne pour garder trace de l’ancienne valeur ainsi que la date du changement.
Quant aux travaux visant à gérer les évolutions des données et des schémas, nous
pouvons les classer en deux catégories : ceux où seule une unique version du schéma
multidimensionnel est supportée (quand une évolution survient le schéma et ses instances
sont mis à jour ; il n’y pas d’historisation des versions) tels que [Hurtado et al, 99]
[Vaisman, 01]. Et ceux qui portent sur la création de versions temporelles de la structure
multidimensionnelle (historisation de versions) tels que [Body et al, 02] [Body et al, 03],
[Morzy et Wrembel, 04], [Eder et Koncilia, 01], [Eder et al, 02B], [Ravat, 06A] et
[Ravat, 06B].
Dans la partie qui suit, nous allons nous intéresser de plus près à ces travaux qui gèrent les
évolutions de structures multidimensionnelles par historisation de versions. Nous
présenterons aussi, pour chaque approche proposée, les critiques qu’elle a soulevées dans la
littérature.
II. Travaux liés aux multi-versions dans le cadre du modèle

multidimensionnel
Au niveau des modèles multidimensionnels, il est usuel de considérer que les données
représentées par le(s) fait(s) analysé(s) reflètent l’aspect dynamique des bases de données
multidimensionnelles alors que les dimensions représentent l’aspect statique [Body et al, 02].
Or, dans les cas de figures réels, il en est tout autrement car, les dimensions (ainsi que leurs
instances), hiérarchies et attributs sont appelées à évoluer [Eder et al, 02B].
Selon les travaux de Peter Chamoni, Steffen Stock [Chamoni et Stock, 99], l’ajout
d’intervalles de validité est crucial à la prise en compte des évolutions. Plusieurs auteurs ont
proposé, donc, de rajouter des extensions temporelles, sous forme d’intervalles de validité
délimités par des dates de début et de fin de validité, aux éléments du schéma
multidimensionnel.
21
Notez que dans ce qui suit, les termes de DataWarehouse (entrepôt de données) et
DataMart (magasin de données) sont utilisés pour désigner une base de données
multidimensionnelle, donc, tout ce qui est dit concernant les entrepôts de données et valable
aussi pour les magasins de données.
II.1 Travaux des auteurs Mathurin Body, Maryvonne Miquel,

Yvan Bédard et Anne Tchounikine
Selon [Body et al, 02] et [Body et al, 03], le fait de travailler avec la dernière version
seulement, ne permet pas de voir les évolutions qui peuvent être cruciales pour l’analyse des
données. L’analyse peut même conduire à de fausses conclusions si l’évolution explicite des
données et du schéma n’est pas prise en compte.
Les auteurs proposent donc, une approche qui vise à permettre l’historisation de versions
de structure et la comparaison des données. Le modèle conceptuel proposé est basé sur une
table de fait multi-versions, construite à partir d’un schéma multidimensionnel temporel. Ils
introduisent aussi la notion de ‘modes de représentation’ qui correspond aux différentes
manières d’analyse des données et de leurs évolutions.
Pour prendre en compte tous les changements des structures multidimensionnelles, il est
nécessaire de recenser, dans un premier lieu, les évolutions possibles, classées par type (de
schéma ou de données).
II.1.1 Evolutions possibles au niveau multidimensionnel
Les changements suivants peuvent se produire dans un schéma multidimensionnel :

 Création et suppression de dimension
 Création et suppression d’une hiérarchie
 Création et suppression d’un niveau
 Déplacement d’un niveau dans la structure hiérarchique du schéma
 Création et suppression d’une mesure
 Création et suppression d’un attribut
Les évolutions dans les instances de dimensions sont plus difficiles à lister
exhaustivement, toutefois, six opérations de bases sont citées et qui peuvent être combinées
pour construire des opérations complexes. Les opérations simples sont :
 Création d’un élément de dimension
 Suppression d’un élément de dimension
 Transformation d’un élément (changement d’un attribut, son sens ou son nom)
 Fusion de n éléments en un élément
 Eclatement d’un élément en n éléments
 Reclassification d’un élément dans la structure de dimension
Des exemples d’opérations complexes :

 Réduction (Decreasing) : éclatement suivi de suppression
 Augmentation (Increasing) : création suivie d’une fusion
 Annexion partielle : éclatement suivi d’une fusion
22
II.1.2 . Le modèle proposé
Le modèle proposé prend en compte les évolutions de schéma ainsi que d’instances. D’un
autre coté, le modèle n’impose aucune structure de schéma explicite, il peut donc facilement
manipuler des structures hiérarchiques complexes.
Le modèle multidimensionnel temporel proposé sera présenté, dans ce qui suit, suivant les
trois niveaux d’abstraction : conceptuel, logique et physique.
 Niveau conceptuel
Le modèle est basé sur la redéfinition des tables de fait et de dimensions par l’ajout
d’intervalles de validité. Cette approche est essentiellement bâtie sur une unique table de
faits multi-versions.
En outre, dans le but de garder le lien à travers les transitions (entre les versions), les
auteurs introduisent les relations de mapping et un facteur de confiance (fiabilité des
données agrégées), qui sont utilisés pour construire une table de fait multi-versions.
Un schéma multidimensionnel temporel, est représenté par un ensemble de dimensions

temporelles, une dimension Temps, un ensemble de relations de mapping et une table de
fait. Et une version de structure est une version d’un schéma multidimensionnel temporel
TDM valide pendant un intervalle de temps.
Après avoir énoncé toutes ses définitions, nécessaires pour comprendre la conception de la
table de fait multidimensionnelle, et la définition de cette dernière, les auteurs présentent les
opérateurs structurels d’évolution. Ils proposent quatre opérateurs de bases : Insert, Exclude,
Associate et Reclassif ; pour modifier la structure du schéma multidimensionnel temporel.
En utilisant ces opérateurs de base, il est possible de réaliser toutes les opérations
d’évolutions citées plus haut. Cela en traduisant toute opération, simple ou complexe, en une
séquence d’opérateurs de base.
Par conséquent, tous les changements pouvant survenir dans les instances de dimensions
sont pris en charge. De plus, il n’est pas nécessaire d’introduire de nouveaux opérateurs pour
gérer les évolutions de schéma, car elles sont traitées en même temps que ceux des instances.
Par exemple, l’introduction (ou la suppression) d’un niveau est équivalent à la création (ou
suppression) des éléments de ce niveau.
 Niveau logique
A ce niveau, il s’agit d’adapter l’approche conceptuelle au schéma en étoile, étant le plus

utilisé par les systèmes commerciaux actuels.
D’après les définitions énoncées plus haut, le mode de représentation temporel est similaire
à une dimension et le facteur de confiance apparaît comme une mesure. Dans le niveau
logique, l’ensemble de TMP est représenté par une dimension « plate » (qui ne contient pas
de hiérarchies). Chaque facteur de confiance doit être vu comme une mesure dans la table de
fait, associé aux mêmes éléments dans la structure multidimensionnelle.
23
 Niveau physique
Les auteurs présentent plusieurs adaptations de leur approche, nécessaires, pour pouvoir
implémenter le modèle conceptuel (l’associer à un schéma en étoile) dans les outils
commerciaux existants. Mais ils soulignent que cette solution n’est pas satisfaisante et qu’il
aurait été plus approprié de concevoir un modèle physique adapté à leur structure
Pour implémenter le modèle proposé dans les outils OLAP existants, les auteurs ont choisit
une architecture constituée de trois parties :
- Un entrepôt de données temporel : qui contient le schéma multidimensionnel temporel

et ses méta-données, y compris les relations de mapping.
- Un entrepôt de donnés multi-versions : dans lequel se trouve la dimension « mode de
représentation temporel » et la table de fait multi-versions.
- Un cube OLAP : construit à partir de l’entrepôt de données multi-versions, en utilisant
des agrégations, et qui permet aux requêtes d’intégrer les concepts de modes de
représentation.
II.1.3 Interfaces utilisateur
Ces travaux sont principalement motivés par les besoins de l’utilisateur final. Le système
est muni d’une interface utilisateur contenant comme principales fenêtres :
- Fenêtre principale
- Grille de résultat : où différents facteurs de confidence sont représentés par des
couleurs différentes.
- Requête utilisateurs : où l’utilisateur pour parcourir et combiner plusieurs modes
temporels dans une requête.
- Mét-data : une description complète des évolutions de versions est fournie à
l’utilisateur.
- Conseil pour utilisateur : l’utilisateur peut être aidé, orienté, dans sa navigation à travers
le tube et principalement entre les différentes versions temporelles.
II.1.4 Bilan
Les auteurs présentent une définition formelle d’un modèle multidimensionnel temporel
permettant l’historisation des versions de structures. Ce modèle est basé sur la re-définition
des tables de faits et des dimensions par l’utilisation d’intervalles de validité.
Selon Morzy et Robert Wrembel [Morzy et Wrembel, 04] Cette approche est
essentiellement bâtie sur une unique table de faits permettant de stocker toutes les versions.
En conséquence, le nombre de changements qui peuvent survenir au niveau du schéma est
limité. De plus, dans ce modèle les évolutions supportées sont limitées aux évolutions de la
structure des dimensions et des instances des attributs de dimensions (deux attributs sont
fusionnés en un seul ou encore, un attribut est décomposé en deux attributs). L’évolution
des instances de dimensions n’est pas abordée.
24
II.2 Travaux des auteurs Johann Eder et Christian Koncilia
Tout comme les auteurs des travaux présentés précédemment, ces auteur considèrent que
les différentes évolutions qui peuvent survenir au niveau des bases de données
multidimensionnelles ne peuvent pas être représentées correctement, tant que toutes les
dimensions sont considérées statiques, et engendrent de lourdes restrictions quant à la
validité des requêtes OLAP couvrant plusieurs périodes.
Pour répondre à cette problématique, les auteurs proposent, dans l’article [Eder et
Koncilia, 01], un modèle de données multidimensionnel temporel qui permet l’historisation
de versions temporelles des dimensions de données. Il représente une extension du modèle
utilisé dans les magasins de données (schéma en étoile et ses variantes).
II.2.1 Modèle multidimensionnel temporel
Pour assurer une analyse correcte malgré les changements de structures qui peuvent avoir
lieu, les extensions suivantes, pour un système multidimensionnel, sont nécessaires :
- Extension temporelle : introduction du temps de validité dans les dimensions.

- Versions de structure : le système doit êtres capable de gérer plusieurs versions de
structures.
- Fonctions de transformation : le système doit supporter des fonctions pour transformer
les données d’une version de structure à une autre.
Une version de structure est définie comme étant une vue, d’une structure
multidimensionnelle, valide pendant un certain temps [Ts, Te]. Tous les éléments de
dimension et toutes les relations hiérarchiques dans cette structure multidimensionnelle sont
valides pour l’intervalle de temps donné.
Par conséquent, toute modification d’un élément de dimension ou une relation

hiérarchique, engendre une nouvelle version de structure, si une version de structure pour
l’intervalle de temps donné n’existe pas.
Les auteurs présentent également trois opérations de base : INSERT, UPDATE, et

DELETE, qui permettent respectivement d’insérer, mettre à jour ou supprimer une instance
de dimension, en précisant les dates de début et fin de validité. En se basant sur ces
opérations de base, les auteurs définissent des opérations plus complexes.
Pour répondre à une requête, l’utilisateur doit toujours préciser quelle version de structure
doit être utilisée. Les données retournées par la requête peuvent, cependant, provenir de
plusieurs versions temporelles du cube. Par conséquent, il est nécessaire d’avoir des
fonctions qui permettent de garder trace des modifications de données d’une version de
structure à une autre.
Les auteurs étendent donc, le modèle temporel du magasin de données, en introduisant des
fonctions de mapping pour faire le lien entre les différentes versions de structure afin de
répondre aux requêtes portant sur des intervalles de temps impliquant plusieurs versions.
25
II.2.2 Les requêtes
Quand l’utilisateur pose une requête, il doit spécifier un temps Tq pour sa requête. Cela
permet de déterminer la version de structure (celle pour laquelle Ts ≤ Tq ≤ Te) qui doit être
utilisée pour l’analyse. Dans la plupart des cas, c’est la version de structure courante.
Pour répondre à la requête, les cas suivants sont possibles :
- Une version de structure : une requête qui porte sur une seule version de structure.
- Deux versions de structure contiguës : le système doit utiliser les fonctions de mapping.
- Deux versions de structure non-contiguës : le procédé est le même que pour le cas
précédent, sauf que dans le cas où la fonction de mapping n’existe pas, il faut procéder
par transition.
- Plus de deux versions de structure : ce cas peut être résolu par analogie au cas
précédent. Si, par exemple, des données d’une version de structure SV1 doivent être
reliées à la version de structure SV3, cela peut se faire en considérant les fonctions :
SV1  SV2 et SV2  SV3.
II.2.3 Le modèle COMET
Dans l’article [Eder et al, 02B] faisant suite au précédent, J.Eder, C.Koncilia et T.Morzy
présentent le modèle « COMET » qui, en plus de l’extension temporel du modèle
multidimensionnel qui lui permet de supporte l’évolution des données et schémas
multidimensionnels, répond à d’autres objectifs. Cet article présente aussi les contraintes qui
doivent être appliquées afin de vérifier l’intégrité de ce modèle proposé.
Les principaux objectifs de ce modèle sont :
 Entrepôt de données temporel : le modèle COMET permet de garder trace des

modifications au niveau instances (données) et au niveau schéma aussi.
 Constellation de faits : le modèle COMET prend en compte les schémas en constellation,

il permet le partage de dimensions.
 Agrégation proportionnelle : le modèle supporte les agrégations proportionnelles pour

permettre une agrégation correcte des instances d’attributs non disjoints (ont plusieurs
pères). Par exemple, la 5ème semaine appartient au mois Janvier et Février.
 Dimensionnalité générique : toutes les dimensions sont considérées équivalentes que se

soit dans leur structure ou leurs possibilités opérationnelles, et sont traitées de la même
façon.
Les auteurs énoncent 23 contraintes que doit respecter le modèle COMET pour garantir
son intégrité.
Pour implémenter le modèle COMET, les auteurs utilisent une approche d’implantation
d’entrepôt de données temporel qu’ils appellent : « approche indirecte ».
26
FIG8 :L’outil d’administration COMET
Le prototype COMET consiste en trois parties : l’entrepôt de données temporel

(contient les informations concernant les versions de structures, les mesures et les fonctions
de transformation) implémenté avec Oracle 8.1 ; le transformateur (transpose toutes les
valeurs de cellules requises, de toutes les versions de structure requises, dans la version de
structure choisie, en utilisant les fonctions de transformations définies) et l’outil
d’administration (permet de définir, et de modifier, le schéma et la structure de l’entrepôt
de données et d’importer les données des cellules vers l’entrepôt de données temporel).
II.2.4 Bilan
Les auteurs ont présenté une nouvelle approche en introduisant l’extension temporelle, les
versions de structure et les fonctions de transformation. Le modèle COMET pourrait
constituer une bonne base pour développement d’un outil OLAP.
Selon Mathurin Body, Maryvonne Miquel, Yvan Bédard et Anne Tchounikine

[Body et al, 02], le point fort de l’approche présentée dans [Eder et Koncilia, 01] est la
considération des liens entres versions de structure, cependant, elle propose une solution
partielle qui ne prend pas en compte l’évolution de schéma et la représentation cohérente du
temps, et ne considère pas les structures de dimensions complexes. Cependant, la gestion
des évolutions de schéma a été prise en compte dans [Eder et al, 02B].
Selon les auteurs Tadeusz Morzy et Robert Wrembel [Morzy et Wrembel, 04], le modèle
et le prototype d’entrepôt de données temporel présentés supporte les requêtes qui
concernent une version de structure particulière mais aussi les requêtes qui portent sur
plusieurs versions de structure. Cependant, dans ce dernier cas, des fonctions de conversion
doivent être appliquées et engendrent des transformations excessives des données.
27
II.3 Travaux des auteurs Tadeusz Morzy et Robert Wrembel
L’approche proposée [Morzy et Wrembel, 04 ] vise à gérer les évolutions du schéma et

des données par historisations de versions. A chaque changement, un administrateur crée
explicitement une version de l’entrepôt de données et lui associe un intervalle de temps
donné. L’historisation de toutes les versions permet de gérer explicitement les différents
schémas de l’entrepôt et les données qui lui sont associées, et de répondre aux requêtes qui
portent sur plusieurs versions.
Les auteurs proposent aussi une extension du langage SQL traditionnel qui permet de
parcourir plusieurs versions, comparer leurs résultats et les fusionner, si nécessaire et
possible, en un ensemble de données commun.
II.3.1 Entrepôt de données multi-versions
Les auteurs présentent une définition d’un entrepôt de données multi-versions, où la

nouvelle version, créée suite à une évolution, appelée version fils est dérivée de plusieurs
versions appelées versions père.
Les versions d’un entrepôt de données forment un arbre appelé graphe de dérivation de
versions, chaque nœud de ce graphe représente une version, alors que les arcs représentent
des relations « dérivé de » entre deux versions consécutives.
Un entrepôt de données multi-versions MVDW est composé de l’ensemble des ses

versions. Chaque version DWVi est composée d’une version de schéma Si et une version
d’instance Ii qui garde les données décrites par Si.
La structure des informations contenues dans l’entrepôt de données est décrite par un
schéma S, constitué de schémas de dimension et schémas de fait. Alors qu’une instance de
l’entrepôt et constituée d’instances de dimension (instances des niveaux hiérarchiques de la
dimension) et d’instances de fait (les valeurs du fait).
II.3.2 Types de versions
Dans un bon processus décisionnel il est, souvent, nécessaire de prévoir le futur en se

basant aussi bien sur les données actuelles et historisées, que sur les suppositions des
décideurs. Dans ce type de processus, le décideur simule, dans l’entrepôt de données, des
changements qui peuvent avoir lieu dans le monde réel, crée des scénarii virtuels possibles
et les explore avec des outils OLAP.
Les auteurs distinguent donc, deux types de nouvelles versions créées dans un schéma
multidimensionnel, à savoir :les versions réelles (crées suite à des changements réels des
règles de gestion ou de l’environnement) et les versions alternatives (crées pour des besoins
de simulation).
28
II.3.3 Interrogation de données multidimensionnelles (Extension de SQL)
Les données qui intéressent l’utilisateur appartiennent souvent à plusieurs versions et ce

dernier ne doit pas se soucier de l’emplacement de la donnée et peut interroger toutes les
versions, une version en particulier ou encore un ensemble de versions, qu’elles soient
réelles ou alternatives.
Dans l’approche et le prototype proposés, une requête dans un entrepôt de données multi-
versions, qui s’adresse à plusieurs versions est traitée en deux étapes. Dans la première
étape, la requête est décomposée en un ensemble de requêtes partielles indépendantes,
chacune pour une version. Dans la deuxième étape, les résultats partiels sont intégrés dans
un ensemble commun de données, si possible.
Pour, l’utilisateur a les trois possibilités suivantes : soit interroger la version en cours, soit
d’interroger l’ensemble des versions réelles ou bien interroger l’ensemble des versions
alternatives sélectionnées. Une requête qui s’adresse à une seule version est appelée requête
mono-version, alors qu’une requête qui s’adresse à un ensemble de versions, qu’elles soient
réelles ou alternatives, est appelée requête multi-version.
Pour répondre à de telles requêtes, les auteurs proposent une extension du langage SQL
traditionnel.
Interrogation de la version en cours : par défaut, les utilisateurs utilise les versions
mono-version adressée à la version réelle en cours (la dernière). Dans ce cas, du point de
vue utilisateur, aucune extension du langage SQL n’est requise. Cependant, du point de vue
implantation, il faut retrouver toutes les données qui appartiennent à la version.
Interrogation d’un ensemble de versions réelles : les requêtes multi-versions dans

l’ensemble des versions réelles sont définies en spécifiant l’intervalle de temps qui intéresse
l’utilisateur. A cette fin, la commande SELECT a été étendue, avec la clause : version de la
date « date de début » jusqu'à « date fin », pour sélectionner toutes les versions concernées
suivant leurs dates de début et de fin de validité.
Interrogation d’un ensemble de versions alternatives : comme les versions alternatives

ne sont pas ordonnées linéairement dans le temps, l’utilisateur doit préciser explicitement
l’ensemble des versions qui l’intéressent. Pour cela, la commande SELECT a été étendue
avec la clause : version alternative ({ver_id / ver_name}, …,).
Interrogation d’une seule version : les requêtes mono-version pour une version réelle ou
alternative, sont traitées comme des cas particuliers des deux cas d’interrogation précédents,
en spécifiant dans la clause version la date pour laquelle la version est valide ou alors
l’identifiant et le nom de la version, selon le cas.
Fusions de résultats de requêtes partielles : dans quelques cas, il est possible de

regrouper les résultats des requêtes partielles (en un seul cube). Cette fusion est définie en
incluant la fusion (merge) dans la clause {ver_id / ver_name}, où ver_id et ver_name
désignent l’identifiant et le nom de la version dont le schéma sera utilisé comme schéma de
destination pour tous les résultats des requêtes partielles obtenues.
29
II.3.4 Interface utilisateur
La fenêtre principale est représentée dans la figure suivante :
FIG 9 : Interface utilisateur pour interroger le MVDW
Le coté gauche de la fenêtre (navigateur d’objets) permet de naviguer à travers les

versions du MVDW, où le schéma de la version du DW peut être exploré. Le coté droit de
la fenêtre est réservé à l’écriture des requêtes et à la visualisation des résultats. Comme le
montre la figure (FIG 9), l’utilisateur doit écrire directement ça requête dans une fenêtre.
FIG 10: Visualisation des résultats d’une requête.
Le résultat d’une requête multi-versions est représenté par un ensemble de résultats

partiaux (par version) annotés par des méta-données décrivant les changements de structure
du schéma et des instances des versions concernées par la requête. Il est possible de
visualiser le résultat intégral aussi, quand l’intégration des résultats des requêtes partielles
est possible.
30
II.3.5 Implantation
Pour supporter les différentes techniques d’interrogations citées plus haut, le prototype est
construit comme suit :
 Une interface utilisateur graphique pour visualiser les objets du MVDW et écrire des
requêtes multi-versions.
 Un parseur SQL pour décomposer les requêtes multi-versions
 Un exécuteur SQL pour exécuter les requêtes partielles dans les versions appropriées,
recevoir des données et les combinées dans un seul résultat cohérent.
 Une interface qui permet de visualiser les résultats des requêtes.
Le prototype a été implémenté en Java et Oracle PL/SQL. Les données et les méta-
données sont stockées dans base de donnés Oracle 9i.
Toutefois, cette première version du prototype présente quelques limites :
- Tous les prédicats de la commande SELECT s’appliquent à toutes les versions valides
pendant l’intervalle précisé, et celles dans les clauses version, il n’est donc pas possible
d’exprimer un prédicat dans une unique version.
- Le parseur de requêtes est incapable de déduire les versions nécessaires de la clause
WHERE.
- Le parseur de requêtes est capable de calculer le résultat d’une requête multi-version on
utilisant, seulement, les fonctions d’agrégation simples (sum, min, max, avg) mais pas
les fonctions OLAP avancées.
II.3.6 Bilan
L’approche proposée est basée sur les versions d’entrepôt de données, où une version
représente la structure et le contenu de l’entrepôt pour une période donnée. Pour être en
mesure d’analyser le contenu d’un MVDW, le langage de requête SQL a été étendu.
Le prototype développé permet d’interroger plusieurs versions, cependant, l’implantation

actuelle de son interface de requête présente des limites qui, selon les auteurs, seront
résolues dans la prochaine version.
Selon les auteurs Mathurin Body, Maryvonne Miquel, Yvan Bédard et Anne Tchounikine
[Body et al, 02], les approches proposées par Mendelzon et Eder semblent être
complémentaires, la première fixe les bases de la manipulation des évolutions dans les
structures multidimensionnelles, alors que la deuxième apporte des solutions pour exploiter
les connaissances en évolution.
31
Etat de l’art synthèse de la partie1
III. Synthèse
Nous avons défini, à travers cette première partie du mémoire, les principaux concepts qui
nous intéressent dans le cadre de notre projet.
Le premier chapitre nous a permis de présenter le contexte de nos travaux qui est le système
décisionnel, ainsi que les concepts de magasin de données et de modélisation
Le deuxième chapitre s’intéresse aux évolutions au sein des modèles multidimensionnels.

Celles-ci sont classées en deux catégories : évolutions de données et évolutions du schéma.
Dans le schéma multidimensionnel, la dimension Temps permet d’avoir l’historique des

évolutions des mesures (attributs de la table de faits). Or, il est essentiel, pour l’exactitude des
résultats des requêtes OLAP, que les modifications des dimensions soient prises en compte.
Autrement, les résultats seront faussés et vont engendrer de mauvaises décisions.
Pour un traitement correct de ces changements de schéma et de données dans les requêtes
OLAP, de nouveaux modèles ont été proposés. Le deuxième chapitre regroupe ces travaux et
en particulier ceux liés au multi-versions. De tels modèles peuvent servir de base pour des
outils OLAP qui prennent en compte les changements de structure et renvoient des résultats
corrects de requêtes sur plusieurs périodes et concernant différentes versions.
Cependant, ces travaux ont soulevé certaines critiques dans la littérature, et aucun d’entre
eux ne présente des interfaces de manipulation qui ne soient pas textuels et qui ne nécessitent
pas la connaissance d’SQL.
Le modèle sur lequel repose notre travail, a été conçu par l’équipe SIG. Il permet la gestion
des évolutions de données et de structure par historisation de versions du schéma
multidimensionnel, et ne présente pas les limites et manques reprochés aux solutions
proposées par les précédents travaux.
Ce modèle sera développé dans le 1er chapitre de la partie suivante. Il servira de base pour la
définition de notre langage graphique d’interrogation de bases de données décisionnelles
évolutives.
32
Partie 2
Contributions
Contributions Chapitre III : Modèle multidimensionnel multi-versions
Chapitre 3 : Modèle multidimensionnel multi-versions

«Plusieurs sciences ont été, pour ainsi dire, contemporaines; mais, dans l'ordre historique des
progrès de l'esprit, on ne peut les embrasser que successivement.»Jean le Rond d’Alembert
Cette seconde partie du mémoire présente notre proposition. Divisée en trois chapitres, elle
définit : le modèle sur lequel repose les travaux présents, le traitement des requêtes
multidimensionnelles, et enfin, la définition du langage de manipulation graphique.
Ce premier chapitre présente le modèle conceptuel multidimensionnel sur lequel reposent

nos travaux, proposé par F.Ravat et O.Teste dans [Ravat, 06B] faisant suite à [Ravat, 06A].
Le modèle permet de gérer aussi bien les évolutions de données que les évolutions de
schémas. L’approche consiste à sauvegarder des versions du schéma en étoile pour les
évolutions de structures alors que les changements de valeurs sont enregistrés à travers les
instances de dimension et les instances de fait dans une version d’étoile.
Ce modèle entre dans le cadre des travaux de gestion d’évolutions dans une base de données
multidimensionnelle (BDM) avec historisation de versions parce qu’il ne se limite pas à la
présentation des données transformées dans la version la plus récente mais il vise aussi à
garder trace de tous les changements de la structure multidimensionnelle.
Les auteurs traitent aussi la question OLAP au niveau logique suivant le paradigme
R-OLAP. Le modèle logique proposé est basé sur des tables de version de données
(contiennent les instances de fait et de dimension) et des tables de structure qui décrivent une
version d’étoile et les processus de dérivation entre versions.
Le chapitre se termine par un bilan présentant les limites du modèle, les solutions que nous
apportons pour y remédier, ainsi que quelques contraintes que nous proposons pour garantir
son intégrité.
I. Modèle conceptuel multidimensionnel

I.1 Représentation de l’espace temps
Le modèle conceptuel proposé dans [Ravat, 06B] est un modèle temporel linéaire et discret
qui approche le temps de manière granulaire au travers d'unités temporelles d'observation.
Dans le monde réel, l'espace temporel peut être vu comme une droite continue. L’objectif
est de proposer un modèle temporel, proche de la représentation humaine, qui appréhende le
temps de manière empirique en utilisant des variables discrètes (par exemple le calendrier
Grégorien).
La droite continue du temps est divisée en une suite de segments définissant une partition ;
chaque point d'un segment est approché par le grain de temps qui le contient. Chaque unité
temporelle correspond à une partition de la droite du temps. Des exemples d'unités
temporelles sont le jour, le mois, l'année, correspondant à une partition de la droite du temps.
33
Un instant est un grain de temps relativement à une unité temporelle alors qu’un intervalle
représente le temps entre deux instants.
Dans le modèle, deux types de temps sont considérés : le temps de validité et le temps de
transaction. Le temps de validité correspond au temps pendant lequel l'information est
considérée valide dans la réalité, alors que le temps de transaction représente le temps pendant
lequel l’information est enregistrée dans la BDM.
I.2 Constellation et version d’étoile
Le modèle proposé étend le concept de fait (sujet d'analyse) et de dimension (axe d'analyse)
initialement proposé pour la modélisation multidimensionnelle. Plus précisément ce modèle
repose sur une constellation (fusion de plusieurs schémas en étoile par des dimensions
communes) regroupant différents versions d'étoile.
Une version d'étoile est une vue d’un schéma en étoile dont la structure n’a pas changé.
Une BDM est donc modélisée à travers une constellation C, qui est composée de versions
d’étoile {SV1,…, SVU} modélisant les changements du schéma.
Chaque version d’étoile SV 1 est définie par une version de fait FV 2, et des versions de
dimensions (DVi) 3 associées à la FV.
Les définitions formelles d’une constellation et d’une version d’étoile sont : [Ravat, 06B]
Définition 1. Une constellation C est définie par (FC, DC, VStar) où :

- FC est l’ensemble de faits de la constellation.
- DC est l’ensemble de dimensions de la constellation.
- VStar : FVC  DVC est une fonction qui associe chaque version de fait aux versions de
dimension qui lui sont liées.
- FVC = FVF i est l’ensemble de toutes les versions de fait de la constellation.
- DVC = DVDi est l’ensemble de toutes les versions de dimension de la constellation.
Définition 2. Une version d’étoile SV i.j est défini par (FVi, VStar (FVi)) où
- FVi est une version de fait.
- VStar (FVi) est l’ensemble des versions de dimension qui sont liées à FVi.
Remarque : les définitions formelles d’une FV2 et d’une DV3 sont données un peu plus loin.
Si les changements de données sources ne requièrent pas de changements de structure, la

version en cours est rafraîchie (une nouvelle instance de dimension et/ou de fait est créée par
exemple). Si les changements des données sources requièrent un changement de structure (par
exemple, une hiérarchie peut être transformée suivant une nouvelle source de données), une
nouvelle version d’étoile est définie.
1
SV pour « Star Version », ou version d’étoile.
2
FV pour « Fact Version », ou version de fait.
3 34
DV pour « Dimension version », ou version de dimension.
I.3 Composants d’une version d’étoile
Chaque version d’étoile est composée d’une version de fait et de plusieurs versions de
dimensions. Chaque version de fait est composée de mesures et chaque version de dimension
est composée de propriétés qui sont organisées suivant une ou plusieurs hiérarchies.
I.3.1 Version de fait
Pour définir une version de fait nous devons d’abord définir le Fait :
Définition 3. Un fait F est défini par (NF, FVF, VDerivF, IDerivF)
- NF est le nom du fait.

- FVF = {FV1,…, FVn} ensemble des versions du fait, qui représentent les états du fait.
- VDerivF : FVF  FVF est la fonction de dérivation tel que VDerivF (FVi) = FVj reflète
la dérivation de FVj à partir de FVi.
F F F F F F
F - IDeriv : ID  ID est la fonction de dérivation tel que IDeriv (I k) = I i veut dire
ID est l’ensemble d’identifiants
F des instances du fait.
F
que l’instance I i , est dérivée de l’instance I k.
IDF est l’ensemble des identifiants des instances du fait.

Définition 4. Une version de fait FVi est définie par (IFVi, IntFVi, ExtFVi)
- IFVi est l’identifiant de la version de fait.

- IntFVi = (AFVi, MFVi) où AFVi = {id F } U {TStart, TEnd} et MFVi = {f1(m1),…, fp(mp)} est
un ensemble de mesures (ou indicateurs) associées à des fonctions d’agrégation.
- ExtFVi = {iFV1,…, iFVx} est un ensemble d’instances. Chaque instance est définie par les
valeurs de mesures, les identifiants des dimensions liées à VF et le temps de transaction.
Une nouvelle version de fait est définie lorsque de nouvelles mesures sont crées ou
d’anciennes mesures sont supprimées. De la même façon, une nouvelle version de fait est
créée quand une nouvelle dimension est reliée à la version de fait ou une ancienne dimension
est déconnectée de la version de fait.
I.3.2 Version de dimension

Une dimension est représentée par plusieurs versions de dimension ayant le même nom.
Définition 5. Une dimension D est définie par (ND, DVD, VDerivD, IDerivD)
- ND est le nom de la dimension.

- DVD = {DV1,…, DVm} ensemble des versions de la dimension.
- VDerivD : DVD  DVD est la fonction de dérivation tel que VDerivD (DVi) = DVj
reflète la dérivation de DVi en DVj.
- IDerivD : IDD  IDD est la fonction de dérivation tel que IDerivD (ID k) = ID i veut dire
que l’instance ID i est dérivée de l’instance ID k.
IDD est l’ensemble des identifiants des instances de la dimension.
35
DVi
Définition 6. Une hiérarchie H j est définie par (NDVij, PDVij, WADVij)
- NDVi j est le nom de la hiérarchie.

- PDVij = <p 1,…,p s> est un ensemble ordonné d’attributs de la dimension, appelés
paramètres (p 1 = a0 est le paramètre racine et ps = All est le paramètre d’extrémité).
- WADVi j est une fonction qui associe chaque paramètre à un ensemble d’attributs faibles,
qui apportent des informations sur le paramètre.
Une nouvelle version de dimension est définie lorsque sa structure change ; par exemple,
quand un attribut est créé ou supprimé, une hiérarchie ajoutée, supprimée ou modifiée.
Une version de dimension est définie comme suit :

Définition 7. Une version de dimension DVi est définie par (IDVi, IntDVi, ExtDVi)
- IDVi est l’identifiant de la version de dimension.

- IntDVi = (ADVi, HDVi) où ADVi est l’ensemble des attributs de la dimension et HDVi
l’ensemble de ses hiérarchies.
- ExtDVi = {iD1,…, iVy} est un ensemble d’instances. Chaque instance de dimension est
définie par les valeurs des attributs de la dimension, ainsi que le temps de transaction.
Remarque : Le temps de transaction est un intervalle de temps associé aux instances de fait
et aux instances de dimensions. Le temps de validité est modélisé par une dimension
temporelle dans la BDM.
Exemple : Pour illustrer toutes les définitions présentées, voici un exemple de données
commerciales.
Soit une constellation composée de deux faits :

FVentes FVentes
- FVentes = (‘‘VENTES’’, FV , VDeriv )
FStock FStock
- FStock = (‘‘STOCK’’, FV , FDeriv )
Et quatre dimensions :
DTemps
- DTemps = (‘‘TEMPS’’, DV , VDerivDTemps )
DClient
- DClient = (‘‘CLIENT’’, DV , VDerivDClient )
DProduit
- DProduit = (‘‘PRODUIT’’, DV , VDerivDProduit )
DMagasin
- DMagasin = (‘‘MAGASIN’’, DV , VDerivDMagasin )
Des évolutions de structure vont survenir, tels que l’ajout d’une nouvelle mesure au fait
VENTES, la connexion d’une version de fait à une version de dimension et l’ajout d’une
hiérarchie dans la dimension MAGASIN. Ces évolutions vont engendrer la création de
nouvelles versions d’étoile.
Ce modèle est multi-versions parce que plusieurs versions d’étoile peuvent être utilisées en
un même instant. Une nouvelle version d’étoile est créée lorsque des changements de
structure se produisent entre deux versions.
36
Les états consécutifs des faits et dimensions aussi bien que leurs relations sont définis à
travers cinq versions d’étoile :
- SVVentes.1 = (FVVentes.1, {DVTemps.1, DVProduit.1, DVMagasin.1})

- SVVentes.2 = (FVVentes.2, {DVTemps.1, DVProduit.1, DVMagasin.2, DVClient.1})
- SVStock.1 = (FVStock.1, {DVProduit.1, DVMagasin.1})
- SVStock.2 = (FVStock.1, {DVProduit.1, DVMagasin.2})
- SVStock.3 = (FVStock.2, {DVTemps.1, DVProduit.1, DVMagasin.2})
Ces différentes évolutions dans le temps (entre les instants T1 et T3) sont résumées dans la
figure suivante :
SVVentes.1
DVTemps.1
T1
FVVentes.1 DVProduit.1 FVStock.1
DVMagasin1 SVStock.1
SVVentes.2 DVTemps.1
T2
DVClient.1 FVVentes.2 DVProduit.1
FVStock.1

T3 FVStock.2
FIG 12 : Exemple de changements dans une constellation.
Le fait « VENTES » et la dimension «MAGASIN » sont pris comme exemple, dans ce qui
suit, pour illustrer les différentes définitions liées respectivement, aux versions de fait et
versions de dimension.
II. Modèle R-OLAP multi-versions

Cette section présente des solutions pour le stockage d’informations multidimensionnelles
ainsi que leurs changements dans un contexte relationnel. Cette approche logique, appelée R-
OLAP, introduit des contraintes techniques pour l’implantation de données
multidimensionnelles, leurs structures, ainsi que leurs évolutions dans le temps dans un
contexte relationnel.
La solution proposée consiste à traduire la constellation conceptuelle en « tables de

structure » et « tables de données ».
37
II.1 Tables de données :
Chaque DV est traduite en une table de données dimension. Son schéma est composé de :
- L’identifiant de l’instance de dimension,
- Les attributs de la dimension (paramètres et attributs faibles),
- Les attributs de temps (TStart, Tend) 4,
- L’identifiant de l’instance précédente. La valeur de cet attribut est soit NULL pour la
version racine (la première version), soit elle représente l’identifiant de l’instance à
partir de laquelle cette version est dérivée (IDerivD).
De la même façon, chaque FV est traduite en une table de données fait, composée de :
- L’identifiant de l’instance de fait,
- Les mesures,
- Les attributs de temps (TStart, Tend),
- L’identifiant de l’instance précédente (IDerivD).
Exemple : les tables de données du fait VENTES et de la dimension MAGASIN de l’exemple

précédent (voir FIG 12).
 Le fait VENTES : ses instances sont contenues dans deux tables qui représentent les
deux versions du fait (TAB 6, et TAB 7).
FVVentes.1
F
IdVentes Montant DVtemps1 DVProduit1 DVMagasin1 TStart TEnd IDeriv
S1 100.00 IT1 IP1 IS1 01/01/2004 31/12/2005 Null
S2 150.00 IT2 IP1 IS1 01/06/2005 31/12/2005 Null
S3 120.00 IT1 IP1 IS2 01/01/2004 31/07/2005 Null
S4 130.00 IT1 IP2 IS2 01/01/2004 31/07/2005 Null
S5 50.00 IT2 IP1 IS3 01/06/2005 31/12/2005 Null
TAB 6 : table de version de fait de FVVentes.1
Dans la deuxième version, une nouvelle mesure est rajoutée (Quantité), et le fait connecté à
une nouvelle dimension appelée « CLIENT ».
FVVentes.2
F
Id Mon- Quan- DV DV DV DV TStart TEnd IDeriv
Ventes tant tité temps1 Produit1 Magasin1 Client1
S6 60.00 6 ITx IPy IS4 IC1 01/01/2006 01/07/2006 S1
S7 40.00 4 ITx IPy IS4 IC2 01/01/2006 01/07/2006 S1
S8 150.00 15 ITz IPy IS4 IC1 01/01/2006 01/07/2006 S2
S9 50.00 5 ITz IPy IS5 IC2 01/01/2006 Now S5
S10 500.00 50 ITw IPu IS6 IC3 01/01/2006 Now Null
S11 60.00 6 ITx IPy IS7 IC1 02/07/2006 Now S6
S12 40.00 4 ITx IPy IS7 IC2 02/07/2006 Now S7
S13 150.00 15 ITz IPy IS7 IC1 02/07/2006 Now S8
TAB 7 : Table de version de fait de FVVentes.2
Les instances S6, S7, S8 de FVventes.2 dérivent de celles de FVventes.1 encore valides le
31/12/2005, et S11, S12, S13 dérivent respectivement de S6, S7, S8 suite à un changement
dans DVmagasin.1 (IS7 dérive de IS4).
38
 La dimension MAGASIN
Les instances de la dimension « MAGASIN » sont contenues dans deux tableaux qui
représentent les deux versions de la dimension (TAB8, et TAB9).
DVMagasin.1
D
IdMagasin Nom Ville Département Région All TStart TEnd IDeriv
IS1 Carrefour Toulouse 31 Midi-P all 01/01/2004 31/12/2005 null
IS2 Auchan Bordeaux 33 Aquitaine all 01/01/2004 31/07/2005 null
IS3 Carrefour Labège 31 Midi-P all 01/06/2005 31/12/2005 null
TAB 8 : Table de version de dimension de DVMagasin.1
Cette BDM est initialement instanciée le 1er janvier 2004. Elle est composée de deux
magasins français identifiés par IS1 et IS2. Le magasin IS2 a fermé le 31 juillet 2005 et un
nouveau magasin (IS3) a ouvert le 1er juin 2005.
Le 1 er janvier 2006, les décideurs ont voulu changer la structure de cette dimension. Ils
veulent changer la structure de la base de données pour intégrer un magasin situé aux USA.
La nouvelle version de la dimension doit intégrer un nouvel attribut (Etat) et une nouvelle
hiérarchie (un nouveau tuple dans la table « Hiérarchie »).
Cette nouvelle version de dimension est représentée par une table qui comporte deux
magasins français (IS4 et IS5 dérivés de IS1 et IS3) et un nouveau magasin situé à Dallas
(IS6). Le nom du magasin IS4 change le 02/07/2006 et une nouvelle version est donc créée.
DVMagasin.2
IdMagasin Nom Ville Etat
Départ- Dpt_Des Région All TStart TEnd IDerivD
ement
IS4 Carrefour Toulouse null 31 Haute- Midi- all
01/01 01/07 IS1
Garonne Pyrénées /2006 /2006
IS5 Carrefour Labège null 31 Haute- Midi- all 01/01 Now IS3
Garonne Pyrénées /2006
IS6 WallMart Dallas Texas null null null all 01/06 Now null
/2005
IS7 Grand Toulouse null 31 Haute- Midi- all 02/07 Now IS4
Carrefour Garonne Pyrénées /06
TAB 9 : Table de version de dimension de DVMagasin.2
II.2 Tables de structure :
Ces tables de structure stockent les données décrivant des structures multidimensionnelles et
leurs évolutions.
La structure multidimensionnelle est stockée à travers deux tables :

- La table « version d’étoile » contient les liens entre les versions de fait et versions de
dimension. Sa structure est composée de deux attributs nommés :
 Version de fait,
 Version de dimension.
39
- Une table « hiérarchie » est associée à chaque dimension. Cette table représente
différentes hiérarchies de la dimension et ses versions. Cette table est composée de :
 Identifiant de la version de dimension,
 Identifiant de la hiérarchie,
 Nom de l’attribut de la dimension,
 Position de l’attribut : ce numéro représente le niveau d’agrégation de l’attribut de la
dimension (1 représente le niveau d’agrégation le plus bas),
 Type d’attribut (‘P’ pour paramètre et ‘w’ (weak) pour l’attribut faible).
Les changements dans la BDM sont modélisés à travers deux tables :
- La table nommée VDERIVD représente la dérivation entre deux versions de

dimension. Cette table est composée de deux attributs :
 Identifiant de la version de dimension précédente,
 Identifiant de la version de dimension dérivée.
- La table nommée VDERIVF représente la dérivation entre deux versions de fait. Cette
table est composée de deux attributs :
 Identifiant de la version de fait précédente,
 Identifiant de la version de fait dérivée.
Exemple :
Dans notre exemple, la table de structure « version d’étoile » décrit les relations des
versions de fait FVVentes.1 et FVVentes.2 avec les versions de dimension aux quels elles sont
liées dans la constellation (FIG 12).
Version d’étoile
Version de fait Version de dimension
FVVentes.1 DVMagasin.1
FVVentes.1 DVProduit.1
FVVentes.1 DVTemps.1
FVVentes.2 DVMagasin.2
FVVentes.2 DVProduit.1
FVVentes.2 DVTemps.1
FVVentes.2 DVClient.1
TAB 10 : La table de structure « version d’étoile »
 Le fait VENTES
FVentes FVentes
FVentes = (‘‘VENTES’’, FV , VDeriv )
FVentes
- FV = {FVVentes.1, FVVentes.2}
FVentes
- VDeriv (FVVentes.1) = FVVentes.2
FVVentes.2, qui est dérivée de FVVentes.1, a une nouvelle mesure « Quantité », et la nouvelle
version de fait est connectée à la quatrième dimension : « CLIENT ».
40
La dérivation des versions du fait est représentée par une table appelée « VDERIVF». Cette
table contient un tuple qui représente la dérivation du fait VENTES.
VDERIVF
Origin_FV Dérivé_FV
FVVentes.1 FVVentes.2
TAB 11 : La table de structure de « VDERIVF »
 La dimension MAGASIN
DMagasin DMagasin DMagasin
DMagasin = (‘‘MAGASIN’’, DV , VDeriv , IDeriv )
DMagasin
- DV = {DVMagasin.1, DVMagasin.2}
DMagasin
- VDeriv (DVMagasin.1) = DVMagasin.2
DVMagasin.2 dérive de DVMagasin.1 en ajoutant deux attributs (Etat, Dpt-Desc) et une

Magasin Magasin
hiérarchie (H 2) et en mettant à jour la hiérarchie existante (H 1).
La dérivation des versions du fait sont représentées par une table appelée « VDERIVF».
Cette table contient un tuple qui représente la dérivation du fait VENTES.
VDERIVD
Origin_DV Dérivé_DV
DVMagasin.1 DVMagasin.2
TAB 12 : La table de structure de « VDERIVD »
DVMagasin.1 DVMagasin.1 DVMagasin.1
- DVMagasin.1 = (I , Int , Ext ) où :
DVMagasin.1
I =1
DVMagasin.1 Magasin
 Int = ({Id , Nom, Ville, Département, Région, All, TStartDVi, Tend DVi},
Magasin
{H 1})
Magasin Magasin Magasin
Où H 1 = (‘‘H_GeoFr’’, <Id , Ville, Département, Région, All>,{(Id ,
{Nom})}),
DVMagasin.1 Magasin
 Ext = {Id 1, …}
DVMagasin.2 DVMagasin.2 DVMagasin.2

- DVMagasin.2 = (I , Int , Ext ) où :
DVMagasin.2
I =2
DVMagasin.2 Magasin
 Int = ({Id , Nom, Ville, Département, Région, Etat, Dpt_Desc, All,
Magasin Magasin
TStartDVi, Tend DVi}, {H 1, H 2})
Où H 1 = (‘‘H_GeoFr’’, <Id , Ville, Département, Région, All>,{(Id ,
{Nom}), (Département, {Dpt_Desc})}),
H 2 = (‘‘H_GeoUS’’, <Id , Ville, Etat, All>,{(Id , {Nom})}),
DVMagasin.2 Magasin Magasin
 Ext = {Id 2, Id 3,…}
41
Enfin, les hiérarchies sont modélisées à travers une table nommée « Hiérarchie ». Dans
notre exemple, cette table contient des données représentant les hiérarchies associées aux
versions de la dimension « MAGASIN », et est représentée par la figure suivante :
HIERARCHIE
Dim_Vers Hiérarchie Attribut Position Type
DVMagasin.1 H_GeoFr Id Magasin 1 P
DVMagasin.1 H_GeoFr Nom 1 W
DVMagasin.1 H_GeoFr Ville 2 P
DVMagasin.1 H_GeoFr Département 3 P
DVMagasin.1 H_GeoFr Région 4 P
DVMagasin.1 H_GeoFr All 5 P
DVMagasin.2 H_GeoFr Id Magasin 1 P
DVMagasin.2 H_GeoFr Nom 1 W
DVMagasin.2 H_GeoFr Ville 2 P
DVMagasin.2 H_GeoFr Département 3 P
DVMagasin.2 H_GeoFr Dpt_Desc 3 W
DVMagasin.2 H_GeoFr Région 4 P
DVMagasin.2 H_GeoUS Id Magasin 1 P
DVMagasin.2 H_GeoUS Nom 1 W
DVMagasin.2 H_GeoUS Ville 2 P
DVMagasin.2 H_GeoUS Etat 3 P
TAB 13 : La table de structure de «HIERARCHIE »
III. Bilan et contribution

Le modèle multidimensionnel prévoit de gérer plusieurs sujets d’analyse étudiés à travers
plusieurs axes d’analyse. La solution présentée ici est une constellation composée de plusieurs
faits reliés à des dimensions composées de hiérarchies.
Le modèle logique est basé sur des tables de version de donnée et des tables de structure.
Chaque version de fait (ou version de dimension) est modélisée à travers une table de version
de données. Les tables de structure contiennent des données sur la version d’étoile, les
hiérarchies et le processus de dérivation entre les versions des faits et des dimensions.
Cela dit, aucun contrôle n’est effectué pour garantir l’intégrité du modèle. Nous avons donc
apporté une première contribution en proposant cet ensemble de contraintes d’intégrité:
 Une FV appartient à une seule SV à un instant donné.

 Une DV (FV) dérive d’une seule DV (FV).
 Une instance d’une DV (FV) dérive d’une seule instance d’une CV (FV).
 Un attribut d’une DV, pour une hiérarchie donnée, a un niveau et un type.
 Deux paramètres ne peuvent avoir le même niveau dans une hiérarchie, pour une DV.
 Dans une hiérarchie, pour une DV, il doit exister un paramètre de niveau 1.
 Il ne peut exister un attribut faible sans un paramètre du même niveau.
 Une SV ne peut contenir plusieurs DV d’une même dimension.
42
Les contraintes à respecter concernant l’intervalle de validité sont:
 Dans un intervalle de validité [Ts, Te], Ts ≤ Te.

 Tous les composants d’une SV sont valides pendant son intervalle de validité.
 Lorsqu’une FVi est liée à une DVj, une nouvelle FVx est créée (dérivée de FVi) ainsi
qu’une nouvelle SV contenant DVj et FVx.
 Si I1 et I2 sont deux instances d’une DV (FV), tel que : I2 dérive de I1, alors :
Ts (I2) ≥ Te (I1).
 Si DVi et DVj sont deux DV, tel que : DVj dérive de DVi, alors : Ts (DVj) ≥ Te
(DVi).
 Si FVi et FVj sont deux FV, tel que : FVj dérive de FVi, alors : Ts (FVj) ≥ Te (FVi).
 L’intersection des intervalles de validité des FV d’un même fait (des DV d’une même
dimension) est nulle.
En plus de ces contraintes d’intégrité, nous enrichissons le modèle en apportant quelques

modifications, que nous jugeons nécessaires, aux tables de la base multidimensionnelle.
Par souci d’optimisation, nous proposons un troisième attribut dans les tables de structure
VDERIVD et VDERIVF contenant la date de dérivation.
Il est possible de retrouver ces dates en parcourant les tables de données, mais elles sont très
importantes pour le traitement des requêtes, et leur ajout dans les tables de structure limite le
nombre d’accès et le temps de traitement des requêtes.
Une autre colonne est aussi ajoutée, contenant la raison pour laquelle une nouvelle version
dérivée est créée. Cet attribut sera utilisé lors du traitement des requêtes et apportera des
informations qui s’avèrent parfois nécessaire aux utilisateurs pour l’interprétation des
résultats.
Les tables de structure deviennent donc comme suit :
VDERIVD
Origin_DV Dérivé_DV T_DerivD Cause DerivD
DVMagasin.1 DVMagasin.2 01/01/2006 Nouvelle hiérarchie H-GeoUS
TAB 14 : La table de structure « VDERIVD » modifiée
VDERIVF
Origin_FV Dérivé_FV T_DerivF Cause DerivF
FVVentes.1 FVVentes.2 01/01/2006 Connexion à DVclient.1
TAB 15 : La table de structure « VDERIVF » modifiée
Pour ce qui est des tables de données, elles permettent de retrouver l’instance d’origine ainsi
que la date de dérivation lorsque l’instance dérive d’une seule instance (cas de mise à jour,
d’éclatement, et de connexion d’une version de fait à une version de dimension).
Cependant, le modèle ne permet pas de gérer les cas où une instance dérive de plusieurs
instances, tel que le regroupement, la suppression d’une version de dimension ou sa
déconnexion d’une version de fait.
43
Pour étendre le modèle afin de lui permettre de couvrir de tels cas, nous proposons
d’introduire deux nouvelles tables de structure contenant les instances des faits (IDERIV F),
et des dimensions (IDERIVD). Ces tables contiennent les instances, la date de dérivation, la
version de fait et un commentaire indiquant la cause de la création de l’instance dérivée.
La structure des tables est donc comme suit :

VDERIVF
Origin_IF FV Dérivé_IF T_IDerivF Cause IDerivF
S6 FVVentes.2 S1 01/01/2006 FVVentes.2 dérive de FVVentes.1
S11 FVVentes.2 S6 02/07/2006 Le magasin change de nom
TAB 16 : La table de structure « IDERIVF »
VDERIVD
Origin_ID DV Dérivé_ID T_IDerivD Cause IDerivD
IS4 DVMagasin.2 IS1 01/01/2006 DVMagasin.2 dérive de DVMagasin.1
IS7 DVMagasin.2 IS4 02/07/2006 Le magasin change de nom
TAB 17 : La table de structure « IDERIVD »
La méta-base contiendra donc, une table de structure d’instance par dimension et par fait.
Nous reconnaissons que l’ajout de ces tables crée une certaine redondance, toutefois
nécessaire si nous voulons que le modèle soit complet et qu’il gère la totalité des cas
d’évolution dans le schéma multidimensionnel.
Au niveau de l’implantation, les causes de dérivation ne seront certainement pas exprimées

en langage naturel, nous utiliseront une codification pour pouvoir les exploiter lors du
traitement des requêtes.
Conclusion
Le modèle ainsi défini, servira de base à la définition de notre langage d’interrogation
multidimensionnel multi-versions.
Il s’agit de spécifier et d’implémenter un langage de requête graphique, ce langage doit

permettre d’interroger la version d’étoile en cours, ou un ensemble de versions d’étoile ou
encore une version spécifique, selon le choix de l’utilisateur.
La solution développée constituera donc une extension de l’outil « Graphic OLAPSQL »

pour gérer plusieurs versions.
La suite du mémoire est consacrée à la conception et la réalisation de notre outil

d’interrogation graphique. Le chapitre qui suit présente le traitement des requêtes temporelles
interrogeant un magasin de données conçu suivant le modèle multidimensionnel multi-
versions.
44
Contributions Chapitre IV : Requête multidimensionnelle multi-versions
Chapitre 4 : Requêtes multidimensionnelles temporelles

«Une science se confirme ou s'infirme dans son progrès, non dans la relecture de ses
inventeurs.» André AKOUN
Ce chapitre présente la solution que nous proposons pour le traitement des requêtes OLAP
temporelles, en nous basant sur le modèle décrit dans le chapitre précédent.
Dans un premier temps, nous proposons une classification des requêtes selon qu’elles soient
multi-versions ou non et selon qu’elles portent sur les tables de fait en fonction des
dimensions (requête multidimensionnelle) ou seulement sur une dimension.
Ensuite, nous nous intéresserons de plus près au traitement des requêtes

multidimensionnelles mono et multi versions. Nous listerons tous les cas de figure possibles
et un traitement spécifique pour chacun.
I. Classification des requêtes

Pour poser sa requête, l’utilisateur peut spécifier une version d’étoile de son choix, ou bien,
travailler, par défaut, sur la version en cours (la plus récente).
Toutefois, pour répondre à une requête, il est parfois nécessaire d’interroger d’autres
versions en plus de celle choisie, auquel cas la requête est considérée comme étant temporelle
multi-versions. Cependant, une requête qui ne porte que sur une seule version est appelée
« requête mono-version ».
D’autre part, une requête qui ne porte pas sur un fait, mais seulement sur une dimension, est
appelée requête simple par opposition à requête multidimensionnelle.
Le schéma suivant représente les différents types de requêtes :
Requête
Porte sur
Requête simple
Les dimensions
Le Fait en fonction des Dimensions
Requête
multidimensionnelle
Interroge
Requête Requête
mono-version Une seule Version Plusieurs Versions multi-versions
FIG 13 : Classification des requêtes.
45
Pour illustrer les définitions de ces différents types de requête, à travers des exemples, nous
nous servirons de la constellation suivante (cf. Chapitre 3, § II) :
DVClient.1 FVVentes.2 DVProduit.1 FVStock.2

FIG 14 : Exemple de constellation composée de deux versions d’étoile.
Tel que :
- SVventes.2 et SVstock.3 sont les versions d’étoile en cours (les plus récentes).
- FVvente.2 est une version de fait qui dérive de la version de fait FVvente.1
- FVstock.2 est une version de fait qui dérive de la version de fait FVstock.1
- DVclient.1, DVtemps.1, DVproduit.1 et DVmagasin.2 sont des versions de dimensions
- DVmagasins.2 dérive de la version de dimension DVmagasin.1
I.1 Requête simple
Une requête simple est une requête qui porte sur les différentes versions d’une dimension,
les tables de structures ou encore les tables de la méta-base.
Exemple : soient les deux requêtes suivantes, posées sur la constellation de la figure 13 :
« La date à laquelle le magasin M a fermé»

« Quels sont les magasins de la ville V encore ouverts en 2005 »
La réponse à ces requêtes nécessite l’interrogation des versions de la dimension Magasin

(cf. Chapitre 3, § II).
Bien que le modèle permette de répondre à de telles requêtes, nous ne les traiterons pas
dans ce document, car ce ne sont pas des requêtes multidimensionnelles. En effet, leur
expression se fait simplement par la commande SELECT de SQL (ne nécessite aucune
extension de SQL au multidimensionnel), et le résultat renvoyé n’est pas une table
dimensionnelle.
Dans notre exemple, la réponse aux requêtes revoie une date pour la première,
correspondant à la date de fin de validité du magasin M, et une liste de magasins encore
valide en 2005 (table à une dimension) pour la seconde.
I.2 Requête multidimensionnelle
Les requêtes multidimensionnelles peuvent être classées en deux catégories, requêtes

mono-version et requêtes multi-versions.
46
I.2.1 Requête mono-version
Une requête mono-version est une requête qui ne concerne qu’une seule version d’étoile.
La réponse à une telle requête ne nécessite l’interrogation que de la version d’étoile (SV)
sur laquelle l’utilisateur a posé sa requête.
Exemple : « Le montant des ventes d’un produit Py par magasins à une date Tx »
Sachant que :
- Cette requête est posée sur la version SVventes.2 (figure 13).
- Le « montant » est une mesure de la table de données FVventes.2
La réponse à cette requête se fait par l’interrogation des tables de la version SVventes.2.
Pour l’expression de requêtes mono-version, OLAP-SQL (cf. Chapitre 1, § II.2) ne

nécessite aucune extension. La commande d’interrogation de ce langage, qui repose sur
l’extension de la requête de recherche de SQL (SELECT), permet parfaitement d’exprimer
de telles requêtes. La syntaxe de cette commande sera présentée dans la partie consacrée à
l’implantation du langage (cf. Chapitre 5, § II.2).
I.2.2 Requête multi-versions
Une requête est qualifiée de multi-versions lorsqu’elle interroge plusieurs SV.
Ce type correspond aux requêtes impliquant une période de temps plus large que
l’intervalle de validité de la version du schéma interrogée. Toutes les SV valides durant
cette période, induites par des évolutions de structures du schéma, sont interrogées.
Exemple : « Le montant des ventes des produits par magasin en 2005 et 2006»
Sachant que :
- Cette requête est posée sur la version SVventes.2 (figure 13).
- Le « montant » est une mesure de la table de données FVventes.2
- La structure de la dimension magasin a changée le 01/01/2006.
- Un magasin a fermé le 15/05/2005.
Dans ce cas, le système se charge de retrouver les versions à interroger, selon l’intervalle
de temps spécifié dans la requête.
L’utilisateur peut aussi préciser explicitement l’ensemble des versions qu’il veut
interroger. Dans ce cas, une extension de la commande SELECT du langage OLAP-SQL est
nécessaire, elle sera traitée plus loin, dans la partie réservée à la réalisation.
Remarque : lorsque l’utilisateur précise une seule version, la requête est considérée
mono-version.
Nous allons nous intéresser, dans la partie suivante du chapitre, au traitement de ces deux
types de requêtes multidimensionnelles.
47
II. Traitement des requêtes multidimensionnelles

II.1 Requête mono-version
La syntaxe d’une requête mono-version est similaire à celle de toute requête
multidimensionnelle exprimée grâce à la commande SELECT du langage OLAP-SQL.
Toutefois, le traitement de la requête est différent, car on doit tenir compte des intervalles de
validité des instances.
Pour mieux voir les conséquences que peut avoir le fait de ne pas considérer les intervalles
de validité dans le traitement des requêtes, sur l’analyse de données, et pour illustrer les
solutions proposées, nous reprenons l’exemple précédent (cf. Chapitre 3), en l’enrichissant
pour contenir le maximum de cas d’évolution possibles.
Le tableau suivant représente les données de la version de fait FVventes.2

FVVentes.2
IdVentes Mon- Quan- DV DV DV DV TStart TEnd
Tant tité temps1 Produit1 Magasin1 Client1
S6 60.00 6 IT1 IP1 IS4 IC1 01/01/2006 01/07/2006
S7 40.00 4 IT1 IP1 IS4 IC2 01/01/2006 01/07/2006
S8 150.00 15 IT2 IP1 IS4 IC1 01/01/2006 01/07/2006
S9 50.00 5 IT2 IP1 IS5 IC2 01/01/2006 Now
S10 500.00 50 IT3 IP3 IS6 IC3 01/01/2006 30/07/2006
S11 60.00 6 IT1 IP1 IS7 IC1 02/07/2006 Now
S12 40.00 4 IT1 IP1 IS7 IC2 02/07/2006 Now
S13 150.00 15 IT2 IP1 IS7 IC1 02/07/2006 Now
S14 500.00 50 IT3 IP4 IS6 IC3 31/07/2006 Now
S15 20.00 2 IT3 IP4 IS6 IC2 05/08/2006 Now
S16 60.00 4 IT3 IP5 IS7 IC3 20/08/2006 30/08/2006
S17 60.00 4 IT3 IP6 IS7 IC3 31/08/2006 Now
TAB 18 : Table de version de fait de FVVentes.2
Et celui-ci, la table de structure de FVventes

VDERIVF
Origin_IF FV Dérivé_IF T_IDerivF Cause IDerivF
S11 FVVentes.2 S6 02/07/2006 Modification du magasin
S14 FVVentes.2 S10 31/07/2006 Modification du produit
S17 FVVentes.2 S16 31/08/2006 Modification du produit
TAB 19 : La table de structure « IDERIVF »
Rappelons que dans notre modèle, les changements de structure du schéma

multidimensionnel entraînent la création de nouvelles versions du schéma, contrairement
aux évolutions de données qui engendrent des changements dans les instances d’une même
version.
48
Les mises à jour dans une table de version de fait sont dues aux changements des
instances de tables de versions de dimensions qui lui sont liées dans une même version
d’étoile.
Dans le tableau ci-dessus, une nouvelle instance S11 dérivée de l’instance S6, a été créée
le 02/07/2006 suite à la création d’une nouvelle instance IS7 dérivée de IS4 dans la table de
version de dimension DVMagasin.
De chaque instance liée au magasin IS4 est dérivée une nouvelle instance (S7  S12 ;
S8 S13).
La création d’une nouvelle instance dérivée d’une autre instance se traduit par l’ajout de
la nouvelle instance dans la table de version, et l’attribution d’une date de fin de validité à
l’ancienne instance.
II.1.1 Les cas d’évolution de données
Les différentes évolutions qui peuvent survenir dans une version de dimension DV sont :
 L’insertion d’une instance dans une dimension se traduit par :
- La mise à jour de la table de la DV par l’insertion d’une nouvelle ligne
- La définition de la date de début de validité de cette instance.
 La suppression d’une instance dans une dimension se traduit par :

- Définition de la date de fin de validité de l’instance supprimée dans la table de DV.
 La mise à jour d’une instance dans une dimension se traduit par :

- Définition de la date de fin de validité de l’instance mise à jour dans la table de DV
- La mise à jour de la table de la version de dimension par l’insertion d’une nouvelle ligne
- La définition de la date de début de validité de cette instance.
Les instances d’une version de dimension sont mises à jour dans les cas suivants :
 Transformation d’une instance (changement de la valeur d’un de ses attributs faibles)

Exemple : le magasin change de nom, le client change d’adresse.
 Reclassification d’une instance dans la structure de dimension (changement de la valeur

d’un de ses paramètres)
Exemple : le produit change de catégorie.
 Fusion de plusieurs instances en une instance.
 Eclatement d’une instance en plusieurs instances.
II.1.2 Traitement par cas
Lors de la réponse à une requête multidimensionnelle mono-version, chacun de ces cas

d’évolution, énumérés plus haut, nécessite un traitement spécifique. Nous allons expliquer
dans ce qui suit, à travers des exemples, chacun cas ainsi que son traitement.
49
La présentation détaillée du traitement de tous les cas est nécessaire, pour s’assurer que le
système peut répondre à toutes les requêtes d’une part, et d’autre part pour pouvoir
comprendre la généralisation du traitement à laquelle en aboutit dans la conclusion.
 Cas 1 : Transformation d’une instance

Dans ce cas, la valeur d’un ou de plusieurs attributs faibles d’une instance de version de
dimension (DV) changent, et induisent des changements dans les instances correspondantes
de la version de fait (FV).
Prenons par exemple la requête suivante, posée sur la version d’étoile SVventes.2 :
« Le montant des ventes d’un produit P par magasins et par clients à une date T »
Dans SVventes.2, la version de fait FVVentes.2 est liée aux versions de dimensions :
DVTemps.1, DVProduit.1, DVClient.1, DVMagasin.2. Comme le montre la figure (FIG 14).
La requête interroge donc, FVVentes.2 et renvoie les montants des ventes en fonction des
magasins et des clients, selon des restrictions sur le produit et le temps.
Le traitement de la requête diffère selon que les mises à jour sont apportées aux DV sur
lesquelles porte la restriction (DVTemps.1 et DVProduit.1), ou sur les DV qui représentent les
axes d’analyse (DVClient.1, DVMagasin.2).
Pour développer les deux cas, considérons les deux exemples suivants :
Exemple1 : Un magasin change de nom
« Le montant des ventes du produit IP1 par magasins et par clients à une date IT1 »
Voici le résultat renvoyé sans prise en compte des intervalles de validité :
VENTES Client
(Montant) Id Client IC1 IC2
Magasin Id Magasin
IS4 60.00 40.00
IS7 60.00 40.00
Id Produit = ‘IP1’, Id Temps = ‘IT1’
FIG 15: Exemple d’un résultat erroné (table multidimensionnelle)
Or les instance IS4 et IS7 représentent le même magasin. IS7 dérive de IS4 suite à un
changement du nom du magasin.
Le résultat correct que doit renvoyer le système est le suivant :
VENTES Client
Magasin Id Magasin
IS7 60.00 40.00
Modification du nom du magasin IS4 (IS4  IS7) le 02/07/2006
FIG 16: Exemple d’un résultat correct (table multidimensionnelle)
50
Pour que le résultat soit correct (pas de répétition), il ne faut prendre en considération que
les instances de la table FVventes.2 qui concernent le produit IP1 et la date IT1, dont aucune
autre instance ne dérive.
Dans notre exemple, le changement a eu lieu dans la dimension MAGASIN. Le tableau

suivant représente les données de la version de dimension DVmagasin.2.
DVMagasin.2
Id Nom Ville Etat Départ- Dpt_Des Région All TStart TEnd
Magasin ement
IS4 Carrefour Toulouse null 31 Haute- Midi- all 01/01/2006 01/07
Garonne Pyrénées /2006
IS5 Carrefour Labège null 31 Haute- Midi- all 01/01/2006 Now
Garonne Pyrénées
IS6 WallMart Dallas Texas null null null all 01/06/2005 Now
IS7 Grand Toulouse null 31 Haute- Midi- all 02/07/2006 Now
Carrefour Garonne Pyrénées
TAB 20 : Table de version de dimension DVMagasin.2
Et ce tableau représente la table de structure de la dimension MAGASIN
VDERIVD
IS7 DVMagasin.2 IS4 02/07/2006 Le magasin change de nom
TAB 21 : La table de structure « IDERIVD » de MAGASIN
IS7 dérive de IS4 suite au changement du nom du magasin : « Carrefour » en «Grand

carrefour » le 01/07/2006. Il en résulte l’ajout des instances (S11, S12, S13) dans FVventes.2
(TAB 18), dérivées respectivement des instances (S6, S7, S8).
Exemple2 : Le produit change de nom
Soit la requête : « Le montant des ventes du produit IP3 par magasins et par clients à une
date IT3 ».
Nous retrouvons, dans la table DVproduit.1, les instances IP3 et IP4 telles que IP4 dérive
de IP3 ; et dans FVventes.2 l’instance S13 dérive de S10.
La réponse à la requête renvoie le tableau suivant :
VENTES Client
(Montant) Id Client IC3
Magasin Id Magasin
IS6 500.00
FIG 17 : Résultat de l’exemple 2 (table multidimensionnelle)
51
Le résultat peut être considéré correct si l’utilisateur sait que le produit a changé de nom,
et il veut avoir le montant des ventes sous l’ancien nom.
Néanmoins, si l’utilisateur ne sait pas que le produit a changé de nom, ce résultat est
considéré erroné et peut induire le décideur en erreur, car le montant des ventes du produit
sous son nouveau nom ne lui est pas renvoyé.
La solution serait de présenter à l’utilisateur un tableau représentant le montant des ventes

de IP4 :
VENTES Client
Magasin Id Magasin
IS6 20.00 500.00
Modification du nom du produit IP3 (IP3 IP4) le 31/07/2006
FIG 18 : Résultat correct de l’exemple 2 (table multidimensionnelle)
Il faudrait aussi informer l’utilisateur que IP4 et IP3 représentent le même produit et
préciser la date à laquelle le produit a changé de nom.
Remarque : si la requête portait sur le nouveau nom du produit :

« Le montant des ventes du produit IP4 par magasins et par clients à une date IT3 ».
La réponse à la requête renverrait le tableau FIG 18, et le résultat serait correct.
 Cas 2 : suppression d’instances
Dans ce cas, on définit la date de fin de validité de l’instance supprimée dans la table de
version de dimension, et de toutes les instances de la version de fait qui la concernent.
Dans notre exemple, la suppression se fait lorsqu’un magasin ferme ou lorsqu’un produit
n’est plus mis en vente.
De telles instances doivent être prises en considération dans le résultat de la requête, mais
en précisant à l’utilisateur que le produit n’est plus en vente ou que le magasin a fermé.
 Cas 3 : Reclassification d’une instance dans la structure de dimension
Dans ce cas, la valeur d’un paramètre de l’instance de version de dimension est modifiée.
Ceci change la classification de l’instance dans la hiérarchie de la dimension.
Par exemple : un produit change de catégorie. Et la dimension Produit est organisée selon
la hiérarchie suivante : Produit  Catégorie  Super catégorie.
Si la requête porte sur un attribut d’un niveau de granularité supérieur à celui modifié
(produit), le traitement de la requête est identique à celui du cas de transformation
d’instance.
52
Exemple : la réponse à la requête suivante, posées sur SVventes.2 : « Le montant des

ventes des produits entre T1 et T4» renvoie le résultat suivant :
VENTES Produit
(Montant) Id Produit IP1 IP4 IP6
Temps Id Temps
IT1 100.00 - -
IT2 200.00 - -
IT3 - 520.00 60.00
Temps >= T1, Temps<= T3
FIG 19 : Résultat correct de l’exemple (table multidimensionnelle)
Le traitement de la requête diffère si elle porte sur un attribut de niveau de granularité

égale ou inférieur à celui du paramètre modifié (catégorie ou super catégorie).
Exemple : la requête suivante : « Le montant des ventes des produits par catégories».
Sachant que :
- La requête est posée sur SVventes.2
- SVventes.2 est composée de : FVventes.2, DVmagasin.2, DVproduit.1, DVTemps.1.
Le tableau suivant représente les données de la version de dimension DVproduit.1 :

Id Produit Nom Prix Catégorie Super All TStart TEnd
U catégorie
IP1 W 10 Cat1 Scat1 all 01/01/2004 Now
IP2 X 12 Cat3 Scat2 all 01/01/2004 Now
IP3 Y 10 Cat2 Scat1 all 01/01/2005 30/07/2006
IP4 Z 10 Cat2 Scat1 all 31/07/2006 Now
IP5 N 15 Cat1 Scat1 all 15/08/2006 30/08/2006
IP6 N 15 Cat2 Scat1 all 31/08/2006 Now
TAB 22 : Table de version de dimension DVProduit.1
Et celui-ci, la table de structure des instances de la dimension PRODUIT

VDERIVD
IP4 DVProduit.1 IP3 31/07/2006 Le produit change de nom
IP6 DVProduit.1 IP5 31/08/2006 Le produit change de catégorie
TAB 23 : La table de structure « IDERIVD » de PRODUIT
Le résultat de la requête est donc le suivant :

VENTES Produit
(Montant) Catégorie Cat1 Cat2
Temps Id Temps
IT1 100.00 -
IT2 200.00 -
IT3 - 580.00
Modification de la catégorie du produit IP5 (IP5 IP6) le 31/08/2006
FIG 20 : Résultat 1 de l’exemple de reclassification (table multidimensionnelle)
53
Si l’utilisateur veut analyser les ventes en T3, il considérerait que les produits de catégorie
Cat1 n’ont pas été vendus en T3. Or, si on considère les ventes des produits selon leur
classification au moment de la vente, on aura le résultat suivant :
VENTES Produit
(Montant) Catégorie Cat1 Cat2
Temps Id Temps
IT1 100.00 -
IT2 200.00 -
IT3 60.00 520.00
FIG 21 : Résultat 2 de l’exemple de reclassification (table multidimensionnelle)
La solution que nous proposons dans une telle situation, est de prévenir l’utilisateur du
changement et lui donner la possibilité, s’il le souhaite, de visualiser le résultat de sa requête
sans considérer ce changement (table de la figure FIG 21).
 Cas 4 : Fusion d’instances
La fusion d’instances consiste à regrouper plusieurs instances en une seule, et se traduit

par la création d’une nouvelle instance dérivée de plusieurs autres.
Lorsque des instances d’une version de dimension sont fusionnées, les instances de la
version de fait qui leur sont liées sont fusionnées aussi, et la valeur des mesures des
nouvelles instances dérivées sont calculées selon leur fonctions d’agrégation.
Pareillement au cas précédent, les nouvelles instances dérivées sont celle renvoyées à
l’utilisateur pour répondre à sa requête. L’utilisateur est aussi informé de la fusion et de sa
date, et peut visualiser le résultat avant cette évolution des données.
 Cas 5 : Eclatement d’une instance
Dans ce cas, une instance est divisée en plusieurs instances. Il se traduit par l’ajout de
nouvelles instances dérivées d’une seule.
Les instances de la version de fait (FV) sont éclatées lorsque celles aux quelles elles sont
liées dans les versions de dimension (DV) sont éclatées, ou lorsque la FV est reliée à une
nouvelle DV.
Nous retrouvons ce cas dans notre exemple, en effet, la version de fait FVventes.2 dérive
de FVventes.1 suite à l’ajout de la nouvelle version de dimension DVclient.1.
Toutes les instances de FVventes.2 sont, donc, créées en éclatant celles de FVventes.1. Les
montants et les quantités de ventes sont calculés par client.
Dans le cas où l’éclatement des instances d’une FV est dû à un éclatement des instances
d’une DV, le traitement de la requête est identique au cas précédent (Fusion d’instances).
54
II.1.3 Conclusion
Après avoir étudié les cas, un à un, nous remarquons que le traitement à appliquer à
chacun est le même. Nous arrivons à la conclusion que pour une réponse correcte à une
requête mono-version, parmi les instances sélectionnées, voici celles qui doivent être
renvoyées à l’utilisateur :
- Les instances valides ;

- Les instances non valides dont aucune instance ne dérive ;
- Les instances qui dérivent de celles sélectionnées.
Des messages accompagnent le résultat (table multidimensionnelle) pour informer

l’utilisateur du changement dans le cas d’évolution des données.
Les instances valides sont celles qui n’ont pas de date de fin de validité (Te = Now), ou
qui ont une date de fin de validité égale à celle de la FV ou DV au quelle elles
appartiennent. Tandis que les instances non valides sont celles qui ont une date de fin de
validité inférieure à celle de leur VF ou VD.
II.2 Requête multi-versions
Une requête est considérée multi-versions lorsque sa réponse nécessite l’interrogation de

plusieurs versions de structure (SV).
Dans notre modèle, une nouvelle SV est créée suite à chaque évolution du schéma. Cette
nouvelle version est constituée de l’élément (fait, dimension, hiérarchies, etc.) ayant évolué
ainsi que de tous les autres éléments qui lui sont liés et qui n’auront pas évolué.
II.2.1 Les cas d’évolution de structure
 Modification des faits
 La connexion d’une version de fait (FV) à une version de dimension (DV) se traduit
par :
- La création d’une nouvelle FV en précisant sa date de début de validité et en
précisant la date de fin de validité de la précédente ;
- L’insertion d’une nouvelle colonne représentant l’attribut identifiant de la DV
connectée, et l’ajout de la contrainte de clé étrangère ;
- Les mesures sont recalculées et les instances de la nouvelle FV dérivent de celles
de l’ancienne FV.
 La déconnexion d’une FV d’une DV se traduit par :

précisant la date de fin de validité de la précédente ; et dans laquelle ne figure pas
la colonne représentant l’attribut identifiant de la DV déconnectée.
- Les mesures sont recalculées et les instances de la nouvelle FV dérivent de celles
de l’ancienne FV.
55
 Ajout d’une mesure se traduit par :

- L’insertion d’une nouvelle colonne représentant la nouvelle mesure ;
- L’insertion des instances dérivées de celles de l’ancienne FV en ajoutant la valeur
pour la nouvelle mesure (si elle est disponible).
 Suppression d’une mesure se traduit par :

la colonne représentant la mesure supprimée.
- L’insertion des instances dérivées de celles de l’ancienne FV.
 Modification du nom ou du domaine d’une mesure se traduit par :

- L’insertion des instances dérivées de celles de l’ancienne FV.
 Suppression du fait se traduit par :

- Mise à jour de la date de fin de validité de la FV et de ses mesures.
 Modification de dimension
 Ajout d’un attribut se traduit par :

- La création d’une nouvelle DV en précisant sa date de début de validité et en
- L’insertion d’une nouvelle colonne représentant le nouvel attribut ;
- L’insertion des instances dérivées de celles de l’ancienne DV en ajoutant la valeur
pour le nouvel attribut ;
 Suppression d’un attribut se traduit par :

la colonne représentant l’attribut supprimé ;
- L’insertion des instances dérivées de celles de l’ancienne DV.
 Modification du nom ou du domaine d’un attribut se traduit par :

 Suppression de la dimension se traduit par :

- Mise à jour de la date de fin de validité de la DV et de ses mesures.
 Ajout d’une hiérarchie se traduit par :

- L’insertion de nouvelles colonnes représentant les nouveaux attributs ;
- L’insertion des instances dérivées de celles de l’ancienne DV en ajoutant les
valeurs pour les nouveaux attributs ;
56
 Suppression d’une hiérarchie se traduit par :

précisant la date de fin de validité de la précédente ; et dans laquelle ne figurent
pas les colonnes représentant les attributs de la hiérarchie supprimée.
Remarques :
- Dans chacun de ces cas d’évolution de structure, est créée une nouvelle SV en
précisant sa date de début de validité (date du jour) et en précisant la date de fin de
validité de la version précédente ;
- à chaque fois qu’une nouvelle FV ou DV est créée, les tables de structure
« VDERIV » sont mises à jour par l’ajout d’un tuple précisant la date et la cause de
la dérivation.
- En précisant la date de fin de validité d’une FV ou DV, cette même date est attribuée
comme date de fin de validité, à ses mesures encore valides à ce moment là.
- Chaque création d’une nouvelle DV engendre la mise à jour de la table de structure
« Hiérarchie ». (voir TAB13 page 45).
- Le cas de changement de l’ordre des attributs dans une hiérarchie est traité comme le
cas d’ajout d’une nouvelle hiérarchie.
- Touts ces changements engendrent des mises à jour dans les tables de la méta-base.
Une requête est multi-versions dans les deux cas suivants:
- L’utilisateur précise un intervalle de temps et qu’un ou plusieurs de ces cas

d’évolution surviennent pendant cet intervalle ;
- L’utilisateur choisit explicitement les versions à interroger.
Dans le premier cas, les SV interrogées sont contiguës, elles sont ordonnées linéairement
dans le temps et chacune dérive de celle qui la précède. Alors que dans le second cas, les SV
peuvent être non-contiguës.
La requête multi-versions est divisée en plusieurs requêtes partielles, chacune adressée à

une SV, et sont traitées comme des requêtes mono-version.
Lorsque les SV sont non-contiguës, des résultats partiels (une table dimensionnelle par
SV) sont renvoyés à l’utilisateur, accompagnés de commentaires, extraits de la table de
structure « VDERIV », précisant l’intervalle de validité de chaque SV et le changement de
structure effectué.
Cependant, lorsque les SV sont contiguës, un seul résultat global (une table
dimensionnelle) est renvoyé à l’utilisateur, à condition que l’intégration des résultats
partiels soit possible.
Pour identifier les cas dans lesquels l’intégration des requêtes partielles est réalisable,
nous allons étudier toutes les situations possibles en considérant tous les cas d’évolution du
fait et des dimensions cités précédemment.
Nous expliquerons par la suite, l’intégration des résultats partiels à travers des exemples,
après avoir identifié les cas dans lesquels elle est possible.
57
II.2.2 Traitement par cas
Reprenons notre exemple (figure FIG12 p.40)
SVVentes.1
DVTemps.1
T1
FVVentes.1 DVProduit.1 FVStock.1
T2
FVStock.1

T3 FVStock.2
FIG 22 : Exemple d’évolutions dans une constellation (plusieurs SV).
Commençons par les deux cas les plus évidents où l’intégration est possible car la requête
adresse des attributs présents dans toutes les versions :
 Cas 1 : FV et DV ne changent pas
Un tel cas se présente lorsque la structure du fait et des dimensions concernés par la
requête ne change pas, l’évolution est due à un changement de la structure d’une autre
dimension du schéma en étoile.
Exemple : Considérons par exemple la requête suivante:

«La quantité en stocke par produit et par magasin entre T2 et T4 ». (T4 > T3).
Cette requête concerne, donc, le fait STOCK et les dimensions PRODUIT et MAGASIN.
Entre T2 et T4, à la date T3, la connexion de FV à la DV « DVTemps.1 » a engendré la

création d’une nouvelle SV mais le fait et les dimensions adressés par la requête n’ont subis
aucun changement.
L’intégration des résultats partiels de SVStoock.2 et SVStock.3 est possible. Le résultat

renvoyé à l’utilisateur est une table dimensionnelle représentant la quantité en stock en
fonction des produits et des magasins.
58
 Cas 2 : les mesures et les attributs ne changent pas
Dans ce cas la, la structure du fait et/ou des dimensions interrogés par la requête change,
mais ces évolutions ne concernent pas les mesures et les attributs adressés par la requête.
Exemple : Considérons par exemple la requête suivante:

«Le montant des ventes par produit par mois entre T1 et T3 ».
Cette requête concerne, donc, le fait VENTES et les dimensions PRODUIT et TEMPS.
Entre T1 et T3, à la date T2, une nouvelle SV est créée suite à deux changements : la
connexion de la FV à une nouvelle DV et l’ajout d’une nouvelle mesure au fait VENTES.
Le fait a donc subi un changement de structure mais qui ne concerne pas la mesure
« Montant » adressée par requête.
Ici, tout comme dans le cas précédent, l’intégration des résultats partiels de SVVentes.1 et
SVVentes.2 est possible.
Contrairement aux deux cas précédents, dans ceux qui suivent, nous considérons que le
changement concerne les attributs adressés par la requête.
Nous Commençons par les cas où la structure de la FV change.
 Cas 3 : connexion / déconnexion d’une FV
Lorsqu’une DV adressée par une requête n’est pas présente dans toutes les versions
concernées par celle-ci, les SV interrogées sont celles où la DV est connectée à la FV et la
réponse est sous forme d’un ensemble de résultats partiels.
Exemple : Soit la requête suivante:

«Le montant des ventes par produit par client entre T1 et T3 ».
Cette requête concerne le fait VENTES et les dimensions PRODUIT et CLIENT.
Les deux SV valides dans l’intervalle [T1, T3] sont : SVVentes.1 et SVVentes.2. Mais, la
première SV ne contient pas la dimension CLIENT, elle n’est donc pas interrogée par la
requête et la réponse renvoyée est le résultat de la requête partielle de SVVentes.2.
 Cas 4 : ajout / suppression d’une mesure
Si plusieurs SV sont valides pendant l’intervalle de temps qui intéresse l’utilisateur, mais
qu’elles ne contiennent pas toutes les mesures adressées par la requête, l’intégration de tous
les résultats partiels n’est pas possible.
Toutefois, une intégration partielle est envisageable en regroupant les résultats

d’interrogation des SV dont les FV contiennent les mêmes mesures.
Exemple : Soit la requête suivante:

«Le montant et la quantité des ventes par produit entre T1 et T3 ».
59
Cette requête concerne le fait VENTES et les dimensions PRODUIT et TEMPS.
En T2, T2 [T1, T3], la mesure « Quantité » est ajoutée au fait VENTES.
Les deux SV valides dans l’intervalle [T1, T3] sont : SVVentes.1 et SVVentes.2. Mais, FV
de la première SV ne contient pas la mesure « Quantité ».
La réponse renvoyée est donc, deux tables dimensionnelles représentant les résultats
partiels de SVVentes.1 et SVVentes.2. La première continent la mesure « Montant » et la
seconde les mesures « Montant » et « Quantité ».
Remarque : Si la requête ne concerne qu’une seule mesure, les SV interrogées sont celles
valides après la date de dérivation de la FV dans le cas d’ajout de la mesure et avant cette
date dans le cas de suppression de la mesure.
 Cas 5 : changement du nom ou du domaine d’une mesure
Lorsque la requête concerne deux SV contiguës où l’une dérive de l’autre suite au

changement du nom ou du domaine d’une mesure, l’intégration des résultats partiels est
possible.
Dans le résultat global apparaît le nouveau nom de la mesure et un message extrait de la

table de structure « VDERIV » précise à l’utilisateur le changement ainsi que sa date.
Les cas qui suivent représentent les changements de structure de la DV :
 Cas 6 : ajout / suppression d’un attribut
Le traitement de ce cas est similaire à celui du cas 4, l’intégration des résultats partiels
n’est pas possible lorsque les deux versions sont contiguës et que la raison de la dérivation
est l’ajout ou la suppression d’un attribut.
Dans le cas où la requête ne concerne qu’un seul attribut de la dimension, les SV

interrogées sont celles valides après la date de dérivation de la DV lorsque l’attribut est
ajouté, et avant cette date lorsqu’il est supprimé.
L’ajout et la suppression d’une hiérarchie appartiennent à ce cas, car ils consistent à

ajouter ou supprimer des attributs de la dimension.
Exemple : Soit la requête: « Quantité en stock, par produit par état entre T1 et T3 ».
Cette requête concerne le fait STOCK et les dimensions PRODUIT et MAGASIN.
En T2, une nouvelle hiérarchie et un nouvel attribut « Etat » sont introduits dans la
dimension MAGASIN. La réponse à la requête est donc constituée du résultat partiel de
SVStock.1 et des résultats de SVStock.2 et SVStock.3 intégrés.
60
 Cas 7 : changement du nom ou du domaine d’un attribut
Pareillement au cas 5, lorsque la requête concerne deux SV contiguës où l’une dérive de

l’autre suite au changement du nom ou du domaine d’un attribut adressé par la requête,
l’intégration des résultats partiels est possible.
Dans le résultat global apparaît le nouveau nom de l’attribut et un message extrait de la

table de structure « VDERIV » précise à l’utilisateur le changement effectué ainsi que la
date de dérivation.
 Cas 8 : changement de l’ordre des attributs dans une hiérarchie
Dans ce cas là, la requête interroge deux attributs de la dimension, qui changent d’ordre
dans leur hiérarchie entre deux des SV concernées par la requête.
L’intégration des résultats est possible si l’attribut de niveau de granularité supérieur

change de niveau mais reste supérieur à l’autre, ou bien, si l’attribut de niveau de granularité
inférieur change de niveau mais reste inférieur à celui de l’autre attribut.
Cependant, si le changement d’ordre fait que l’attribut de niveau inférieur devienne

supérieur à l’autre ou vice-versa, l’intégration des résultats partiels n’est plus possible.
Remarques :
- Dans le cas de suppression du fait ou d’une dimension, si la date de suppression (date de fin
de validité du sa dernière version) appartient à l’intervalle de la requête, seules les SV
valides avant cette date sont interrogées.
- Si un nouveau fait ou une nouvelle dimension est créée, et que la date de début de validité
de sa première version appartient à l’intervalle de la requête, seules les SV valides après
cette date sont interrogées.
- Dans le cas où l’évolution est due à un changement du nom du fait, de la dimension ou de la

hiérarchie, sans que leur structure ne change, les résultats partiels sont intégrés en un seul
résultat global.
- Lorsque la réponse à une requête est le résultat d’intégration de plusieurs résultats partiels
de SVs, l’intervalle renvoyé à l’utilisateur avec le résultat global représente l’union des
intervalles de validité de ces SV.
- Lorsqu’entre deux SV concernées par la requête, la dérivation est due à un changement de

structure du fait et d’une dimension, l’intégration est possible si les deux cas d’évolution
sont des cas où l’intégration est possible.
- Lorsque l’intervalle de validité d’une SV n’appartient pas complètement à l’intervalle de la

requête, seules les instances de la SV valident pendant l’intersection des deux intervalles
sont prises en compte. Exemple : si l’intervalle qui intéresse l’utilisateur est :
[01/05/2005, 30/05/2006] et qu’une SV est valide pendant l’intervalle [01/01/2005,
01/08/2005], parmi les instances qui répondent à la requête, seules celles dont la date de
début de validité est supérieur ou égale à 01/05/2005 sont prises en compte.
61
II.2.3 Intégration des résultats partiels
En réponse à une requête multi-versions, l’intégration des résultats partiels est possible
lorsque les mesures et attributs adressés par la requête existent dans toutes les SVs, et aussi
dans le cas de changement du nom ou du domaine de la mesure ou de l’attribut.
L’intégration se fait après le traitement des requêtes partielles comme requêtes

mono-version. Les instances de chaque SV qui répondent à la requête sont représentées
dans le résultat global
Pour que le résultat soit correct, il ne faut pas qu’il y ait des répétitions. Par conséquent,
lorsqu’une instance est incluse dans le résultat global de la requête, on ne prend pas en
considération les instances dont elle dérive, ni celles qui dérivent d’elle.
Le traitement diffère selon que la requête porte sur la dimension TEMPS ou pas. Nous
allons développer chacun de ces deux cas à travers des exemples.
Exemple 1: La requête ne porte pas sur la dimension TEMPS
Considérons la requête : « Montant des ventes par magasin et par produit entre T1 et T3 ».
Les deux SV concernées par cette requête et valides dans l’intervalle [T1, T3] sont :
SVVentes.1 et SVVentes.2.
Selon FVVentes.1 et FVVentes.2 (voir TAB18 et TAB19), les deux résultats partiels sont
comme suit :
VENTES Produit
(Montant) Id Produit IP1 IP2
Magasin Id Magasin
IS1 250.00 -
IS2 120.00 130.00
IS3 50.00 -
Fermeture du magasin IS2 le 31/07/2005
FIG 23 : Résultat partiel sur SVVentes.1 (exemple.1)
VENTES Produit
Magasin Id Magasin
IS5 50.00 - -
IS6 - 520.00 -
IS7 250.00 - 60.00
Modification de la catégorie du produit IP5 (IP5  IP6) le 31/08/2006
FIG 24 : Résultat partiel sur SVVentes.2 (exemple.2)
62
Sachant que : IS7 dérive de IS4 et IS4 dérive de IS1, et que IS5 dérive de IS3, le résultat
global est comme suit :
VENTES Produit
(Montant) Id Produit IP1 IP2 IP4 IP6
Magasin Id Magasin
IS2 120.00 130.00 - -
IS5 50.00 - -
IS6 - - 520.00 -
IS7 250.00 - - 60.00
Modification du nom du produit IP5 (IP5  IP6) le 31/08/2006
FIG 25 : Résultat global de la requête (exemple 1)
Les instances prises en considération sont celles dont aucune autre instance ne dérive.
Exemple 2: La requête porte sur la dimension TEMPS
Considérons la requête : « Montant des ventes par date et par produit entre T1 et T3 ».
Les deux résultats partiels sont comme suit :
VENTES Produit
(Montant) Id Produit IP1 IP2
Magasin Id Temps
IT1 220.00 130.00
IT2 200.00 -
FIG 26 : Résultat partiel sur SVVentes.1 (exemple 2)
VENTES Produit
Magasin Id Temps
IT1 100.00 - -
IT2 200.00 - -
IT3 - 520.00 60.00
Modification de la catégorie du produit IP5 (IP5  IP6) le 31/08/2006
FIG 27 : Résultat partiel sur SVVentes.2 (exemple 2)
63
Le résultat global est comme suit :
VENTES Produit
(Montant) Id Produit IP1 IP2 IP4 IP6
Magasin Id Magasin
IT1 220.00 130.00 - -
IT2 200.00 - -
IT3 - - 520.00 60.00
Modification du nom du produit IP5 (IP5  IP6) le 31/08/2006
FIG 28 : Résultat globale (exemple 2)
Les instances prises en considération sont celles qui ne dérivent pas d’autres instances.
Remarque : Si nous avions appliqué le même traitement que pour le premier exemple,
nous aurions considéré les instances de FVVentes.2 et le montant des ventes de IP1 en IT1
serait : 100.00 or, le résultat juste est : 220.00.
Ceci permet de discerner la limite du modèle, qui est la perte d’information dans le cas où
la requête n’interroge que SVVentes.2. Car, le résultat renvoyé serait la table
multidimensionnelle représentée par la figure FIG 27, dans laquelle les ventes de IP1 en
IT1 sont de 100.00.
III. Conclusion
Dans ce chapitre nous avons proposé un traitement des requêtes multidimensionnelles
interrogeant un entrepôt de donnés conçu selon le modèle multi-versions détaillé dans le
chapitre précédent.
Nous avons commencé par classer les requêtes en deux catégories : mono-version et
multi-versions. Puis, nous avons proposé un traitement pour chaque type.
L’approche adoptée, consiste à diviser la requête multi-versions en plusieurs requêtes

mono-version, et un seul résultat global est renvoyé à l’utilisateur si l’intégration des résultats
partiels est possible.
Les améliorations que nous apportons au modèle utilisé facilitent considérablement le

traitement de ces requêtes, car les tables de structure proposées permettent de retrouver le
type d’évolution de données ou de schéma, et c’est de cette information que dépendent le
traitement des requêtes mono-version et l’intégration des résultats partiels.
Aussi, l’ajout du champ, contenant le type d’évolution, permet de joindre au résultat de la

requête un commentaire apportant des précisions à l’utilisateur.
Dans le chapitre suivant, nous présentons notre langage d’interrogation graphique qui prend
en considération les spécificités du multi-versions.
64
Contributions Chapitre V : Réalisation
Chapitre 5 : Réalisation
«Les difficultés ne sont pas faites pour abattre mais pour être battues.» Charles De Montalembert
Dans ce chapitre nous présentons notre langage d’interrogation graphique basé le procédé
de traitement de requêtes temporelles proposé dans le chapitre précédent.
Nous commencerons par rappeler les différents travaux réalisés au sein de l’équipe SIG que
nous venons compléter par notre proposition, ainsi que l’architecture globale de l’outil
existant Graphic-OLAPSQL et la syntaxe du langage OLAP-SQL sur lequel il est basé.
Nous aborderons par la suite l’extension de l’outil pour lui permettre de répondre à des
requêtes temporelles multi-versions. Cette extension se fera par l’apport de quelques
modifications aux composants de OLAPSQL+, l’ajout de nouveaux modules, l’extension de
la commende Select du langage OLAP-SQL et la modification de la représentation
arborescente au niveau de l’interface graphique.
I. Existant
Au sein de l’équipe, un langage OLAP-SQL a été proposé [Ravat et al, 02]. Il se compose
de trois sous-langages :
- Un langage de description des données (OLAP-LDD) qui permet de créer, modifier et

supprimer des faits, des dimensions, des hiérarchies et leurs composants (mesures,
paramètres et attributs faibles). Il a été implanté en partie dans la proposition
[Annoni, 2003].
- Un langage de contrôle de données (OLAP-LCD) qui permet de définir des droits

utilisateurs sur les composants multidimensionnels. Cette proposition a été poursuivie par
l’équipe dans [Sallami 2004].
- Un langage de manipulation de données (OLAP-LMD) qui permet de sélectionner,

insérer, modifier ou supprimer des données dans les éléments de la base
multidimensionnelle. Cette partie a été complétée par les travaux de [Tournier, 04] par
l’implantation du prototype Graphic-OLAPSQL, qui permet de manipuler une base
multidimensionnelle à travers des interfaces entièrement graphiques.
L’implantation logique est basée sur le modèle R-OLAP (Relational OLAP) qui permet de
stocker une base de données multidimensionnelle sous la forme de tables relationnelles.
Chaque dimension est représentée par une table relationnelle, dont les paramètres sont les
colonnes, et chaque fait est représenté par une table dont la clé primaire est la concaténation
des identifiants des dimensions et dont les mesures sont les colonnes.
Le langage OLAP_SQL permet de rendre transparente l’implantation relationnelle sous-

jacente, offrant ainsi la possibilité d’utiliser des requêtes dont le langage est proche du SQL
pour formuler des opérations de consultation propres au contexte OLAP (manipulation directe
des faits, dimensions, etc.).
65
Le tableau suivant résume les opérations permises par le langage OLAP-SQL tant au niveau
du langage de définition que de contrôle ou de manipulation des données.
LDD LMD LCD

Création d’un schéma Insertion de valeurs Ajout de droits d’utilisateurs
Modification Modification Modification de droits
Suppression Suppression Suppression de droits
Consultation
TAB 24 : Opérations du langage OLAP-SQL
Après la réalisation du prototype OLAPSQL + basé sur le langage OLAP-SQL, l’objectif de

l’équipe a été d’étendre ce langage vers le multi-versions. Et donc, de concevoir un langage
qui permet la définition, le contrôle ainsi que la manipulation d’une base de données
multidimensionnelle temporelle conçue selon un modèle multi-versions.
Les travaux de [Benak, 05] ont permis de définir un modèle multidimensionnel permettant
la gestion de l’évolution temporelle des données et schémas, ainsi qu’un ensemble
d’opérations nécessaires à la définition et à la manipulation d’une base de données
multidimensionnelle temporelle (que nous pouvons apercevoir en rose sur le tableau si
dessus).
Ont suivi les travaux [Ravat et al, 06A] et [Ravat et al, 06B] qui ont défini le modèle
multidimensionnel multi-versions sur lequel se sont basés nos travaux.
Notre travail consiste donc, à compléter, d’un coté, celui de [Benak, 05] en définissant les
opérations nécessaires à la consultation des données (que nous pouvons apercevoir en bleu sur
le tableau si dessus) de la base de données temporelle. Et d’un autre coté, celui de
[Tournier, 04] en étendant les interfaces d’interrogation graphiques de Graphic-OLAPSQL
aux multi-versions.
I.1 Architecture de OLAPSQL + et Graphic-OLAPSQL
OLAPSQL+ est un outil utilisable tant par les administrateurs que par les décideurs pour la
définition, la manipulation et la visualisation de données organisées au sein d’une
constellation de faits et de dimensions.
Il repose sur une architecture modulaire dont les trois principales composantes sont :
♦ Un module de saisie et d’analyse des commandes ;
♦ Un module d’exploitation OLAPSQL ;
♦ Un module de présentation des données graphique ou tabulaire.
Le prototype proposait, à la base, deux modes de fonctionnement pour l’utilisateur, à

savoir, une approche textuelle basée sur le langage OLAP-SQL et une approche graphique
pour la visualisation des résultats.
Mais avec Graphic-OLAPSQL, l’utilisateur peut, s’il le désire, s’affranchir du requêteur

textuel et donc du langage OLAP-SQL, grâce aux interfaces graphiques de visualisation et
de manipulation du schéma multidimensionnel de la base de données.
66
La figure suivante présente l’architecture générale du prototype OLAPSQL+.
Graphic-OLAPSQL
FIG 29 : Structure interne de OLAPSQL+ et Graphic-OLAPSQL
L'outil est développé en Java au dessus du SGBD Oracle. Il repose sur les principaux
composants suivants:
- L’interface textuelle ;
- L’analyseur lexical et syntaxique ;
- Le moteur OLAPSQL ;
- La base de données (méta-schéma et schéma multidimensionnel);
- Le générateur de Tables et NJTables ;
- Les interfaces graphiques.
L’outil extrait le schéma multidimensionnel de la base de données et crée en mémoire une

structure d’instances le représentant. Cette structure est alors envoyée dans un constructeur
de graphe et dans deux constructeurs d’arbres, pour créer les trois interfaces graphiques avec
lesquelles peut interagir l’utilisateur. [Tournier, 04]
La spécification de requêtes se fait soit de façon textuelle, soit au travers d’une des
représentations graphiques, où l’utilisateur crée un graphe de requête qui est convertit puis
envoyé au Moteur OLAP-SQL. Ce dernier crée une requête SQL émise vers la base de
données. L’outil récupère les résultats les présente dans une interface graphique : une
NJTable.
I.1.1 Interface textuelle
L’éditeur de texte de OLAPSQL+ permet à l’utilisateur de saisir sa requête. Il sert aussi à

afficher les résultats, ainsi que le compte rendu des requêtes, et à signaler les erreurs
syntaxiques et /ou sémantiques.
67
La requête est écrite en OLAP-SQL, nous allons décrire la syntaxe de ce langage un peu
plus loin dans ce chapitre. La figure suivante présente l’interface textuelle.
FIG 30 : Interface textuelle de OLAPSQL+
Cet éditeur codé, comme le reste du prototype, en JAVA permet de soumettre la requête à
OLAPSQL+ communique avec l’analyseur en entrée et avec le moteur OLAPSQL en sortie.
I.1.2 Analyseur lexical et syntaxique
Développé avec une grammaire JavaCC, il valide syntaxiquement les ordres OLAP-SQL,
et analyse afin d’extraire et de sauvegarder les informations nécessaires à l’exécution de la
requête.
La syntaxe de OLAP-SQL est très proche de celle du langage SQL, de laquelle elle est
inspirée, et qu’elle étend pour respecter les concepts du multidimensionnel (fait,
dimension,…).
I.1.3 Analyseur lexical et sémantique
Développé en Java et JDBC, il convertit les ordres OLAP-SQL sémantiquement validés en

un ordre algébrique interne. Il effectue tous les traitements associés à l’ensemble des
commandes du langage OLAP-SQL en vérifiant l’existence des objets impliqués dans la
requête.
I.1.4 Moteur OLAPSQL
Cette partie est le « coeur » de l’outil OLAPSQL+. Le moteur OLAPSQL établit la

connexion avec le SGBD Oracle dans lequel sont stockés le méta-schéma et la base de
données multidimensionnelle.
En dernier lieu, ce composant traduit la commande en une série d’ordres SQL équivalents
afin de modifier les implantations relationnelles. [Benak, 05]
68
I.1.5 Notion de méta-schéma multidimensionnel
L’outil stocke les données multidimensionnelles dans des tables relationnelles. La structure
conceptuelle induite par la définition multidimensionnelle de la base de données (faits,
dimensions, hiérarchies, etc.), les méta-données, est stockée dans des tables spécifiques qui
sont les méta-tables et qui constituent le méta-schéma. L’outil OLAPSQL+ se charge
d’assurer une cohérence entre la structure relationnelle et les méta-données.
La base de données R-OLAP et la méta-base sont développées en SQL et PL/SQL et sont

gérées par le SGBD Oracle.
Afin de faciliter l’évolutivité de la structure du méta-schéma, le système fonctionne par

l’intermédiaire de vues (méta-vues), et donc n’attaque pas directement les tables
relationnelles qui sont susceptibles d’évoluer. [Tournier, 04]
I.1.6 Générateur de tables et de NJTables

Développé en Java Swing, Ce module permet la visualisation et la manipulation, grâce aux
opérations de l’algèbre multidimensionnelle, des données résultat d’une requête.
La NJTable est une structure de présentation composée d’une table bidimensionnelle (elle
s’apparente aux tables dimensionnelles citées dans le chapitre précédent). Cette table permet de
visualiser les mesures sélectionnées en fonction des paramètres des dimensions disposées en
lignes et en colonne.
La figure suivante présente un exemple de NJTable résultant d’une requête. [Tournier, 04]
FIG 31 : Exemple d’une NJTable résultant d’une requête.
I.1.7 Les interfaces interactives de visualisation conceptuelle
Trois interfaces de visualisation sont fournies à l’utilisateur dans Graphic-OLAPSQL

[Tournier, 04]. Elles offrent une bonne vision du schéma conceptuel de la base de données
multidimensionnelle :
- une visualisation arborescente,

- une visualisation en graphe,
- une visualisation évoluée hyperbolique.
69
 Visualisation arborescente
Ce mode est probablement le plus inadapté à la représentation multidimensionnelle. En

effet, il représente un arbre, alors que les données multidimensionnelles sont structurées en
graphe. De plus, l’arborescence une fois déployée peut être rapidement très vaste.
Mais il a quand même été utilisé dans Graphic-OLAPSQL car il est reconnu
universellement et est maîtrisé par tous les utilisateurs.
Le graphe est parcouru « étoile par étoile ». C'est-à-dire que les faits sont présentés un à un
et chacun avec les dimensions auxquelles il est relié, comme le montre la figure FIG32 ci-
dessous.
Afin de permettre la vision inverse, à savoir : en observant une dimension, trouver les faits
qui lui sont reliés, le parcours du graphe « dimension par dimension » a été ajouté (figure
FIG 33).
La vision des hiérarchies se fait de manière éclatée.
FIG 33 : Visualisation arborescente avec

la dimension Fournisseur déployée.
FIG 32 : Visualisation arborescente avec le fait

ACHATS déployé.
Actuellement ce type de représentation représente l’unique interface de visualisation

implantée dans les outils commerciaux OLAP. Par exemple, Oracle Data Warehouse
Builder et Cognos PowerPlay utilisent ce principe. Une représentation ne modifiant pas la
structure du schéma multidimensionnel serait mieux adaptée.
70
 Visualisation en graphe
Ce système de représentation repose sur la théorie des graphes. Un graphe consiste en une
série de sommets et de segments reliant certaines paires de sommets, sans structure
prédéfinie.
Cette structure est due aux multiples liaisons que peuvent avoir les dimensions et les faits
entre eux, mais aussi celles au sein d’une même dimension. Des paramètres peuvent être
agrégés de plusieurs manières en fonction des différentes hiérarchies.
Comme le montre la figure suivante, l’outil utilise une représentation fidèle au formalisme
graphique définit précédemment dans ce rapport.
FIG 34 : Visualisation en graphe d’un schéma multidimensionnel par Graphic-OLAP-SQL.
 Visualisation évoluée hyperbolique
Ce troisième mode de visualisation a été proposé afin de pallier à certains des problèmes
liés au mode précédent. En effet, bien que théoriquement bien adapté, la visualisation en
graphe montre ses limites si le schéma devient trop volumineux. Ceci peut arriver très vite
car si les exemples présents dans ce mémoire se limitent à une dizaine d’éléments (faits et
dimensions), dans l’industrie, il n’est pas rare de voir des schémas avec des centaines
d’éléments.
La visualisation hyperbolique repose sur un modèle permettant de représenter dans un plan

euclidienne une représentation hyperbolique. Elle utilise exactement la même arborescence
que la visualisation arborescente.
71
La figure suivante présente le mode de visualisation hyperbolique d’un schéma

multidimensionnel.
FIG 35 : Visualisation hyperbolique d’un schéma multidimensionnel par Graphic-OLAP-SQL.
I.2 Commandes du langage OLAP-SQL
Selon [Ravat et al, 02], le langage assertionnel standard des bases relationnelles (SQL
(Iso, 1992)) n'est pas adapté et manque d'expressivité pour la définition d’une base
multidimensionnelle. C’est pour quoi les auteurs ont proposé une extension de ce langage
afin de conserver ses avantages (déclaratif, standard, puissant, reconnu) tout en facilitant la
définition et la manipulation des concepts multidimensionnels.
Le langage proposé nommé OLAP-SQL, comme décrit au début de ce chapitre, est un

langage dédié aux bases multidimensionnelles implantées sous une forme Relationnal-
OLAP ; il intègre les commandes de définition, de contrôle et de manipulation.
Étant donné que notre travail porte sur l’interrogation des bases de données
multidimensionnelles, nous allons nous intéresser uniquement aux commandes de
consultation (voir TAB 24)
A l'instar du langage SQL qui permet d'exprimer simplement l'ensemble des opérations de
l'algèbre relationnelle, le langage OLAP-SQL a pour objectif d'exprimer l'ensemble des
opérations de l'algèbre multidimensionnelle (voir TAB 2 p.13) (pour une base en
constellation). [Ravat et al, 02]
72
I.2.1 Expression de requête de consultation
Le langage comprend une commande unique permettant l'expression de l'ensemble des

opérations multidimensionnelles de consultation. Cette commande repose sur l'extension de
la requête de recherche du langage SQL (SELECT).
La syntaxe de la commande est comme suit :
select <agreg>(<mesure1>), <agreg>(<mesure2>), …

[ according to [ rows <parametre1_lig>, <parametre2_lig>,…,
of <nomdimension_lig> with <nomhierarchie_lig>, ]
[ columns <parametre1_col>, <parametre2_col>,…, ]
of <nomdimension_col> with <nomhierarchie_col> ] ]
from <nomfait>
[ where <predicat> ]
[ order by <parametre1> values(<valeur1_1>, <valeur1_2>,…)
[…[ ,<parametre2> values(<valeur2_1>, <valeur2_2>,…)],…] ];
Les différentes clauses qui regroupe cette commande consultation sont :

- <select> définit des mesures à afficher.
- <according to> définit des paramètres en fonction desquels les mesures sont
calculées. Cette clause permet de structurer le résultat obtenu en fonction de
lignes et de colonnes correspondant aux dimensions.
- <from> précise le fait de l'analyse.
- <where> est une clause optionnelle permettant de restreindre le résultat obtenu. La
restriction peut s'appliquer sur le fait et/ou sur les dimensions associées.
- <order by> est également optionnelle et permet de classer les valeurs des
paramètres.
Exemple : Supposons que des décideurs souhaitent analyser les montants et les marges des
ventes des véhicules en fonction des villes entre les années 1999 et 2004, pour la région des
Midi-Pyrénées. La requête OLAP-SQL permettant de répondre à ce besoin est la suivante :
select (montant), (marge)

according to rows annee of TEMPS with H_AN,
columns ville of CLIENT with H_GEO
from VENTES
where CLIENT.ville='Midi-Pyrenees' ;
Le résultat de cette requête est la table bidimensionnelle représenté par la figure FIG 31.
I.2.2 Traduction des opérations multidimensionnelles
Une fois le résultat présenté à l’utilisateur, celui-ci peut manipuler la table dimensionnelle
pour ajuster le résultat selon ses besoins. Il peut modifier le niveau de granularité selon
lequel les données sont affichées, effectuer des rotations, exprimer des sélections pour
limiter les données affichées, ou encore organiser le résultat de la requête grâce aux
opérations de structuration.
73
L’expression de chacune de ces opérations de consultations se traduit par la récriture de la

requête (réécriture de la commande SELECT), en apportant les modifications appropriées.
Le tableau suivant résume ces opérations et leur traduction en OLAP-SQL. [Ravat et al, 02]
Opération Fonction Traduction OLAP-SQL

Opérations de forage : Modification de la granularité des données
DrillDown Augmenter le détail des données Ajouter un (ou plusieurs) paramètre(s) de
visualisées plus bas niveau (suivant la hiérarchie
courante) dans la clause <according to>
RollUp Réduire le détail des données Supprimer un (ou plusieurs) paramètre(s)
visualisées dans la clause <according to>
Opération de rotation : remplacement d’un élément par un autre
FRotate Changer le fait de l'analyse Spécification d'un nouveau fait dans la
courante clause <from> avec adéquation de
l'ensemble des autres clauses
DRotate Permuter deux axes (dimension) Modification de la clause <according
d'analyse to>
HRotate Changer la perspective d'analyse Modification de la clause <according
en permutant deux hiérarchies sur to> au niveau du <with>
une même dimension affichée
Opérations de sélection : limitation des données
Dice Sélection des valeurs de mesures Spécification d'un prédicat dans la clause
<where>
Slice Sélection des valeurs des Spécification d'un prédicat dans la clause
paramètres <where>
Opération de structuration : organisation des données
Switch Permutation des valeurs des Spécification de l'ordre dans la clause
paramètres d'une des dimensions <order by>
affichées (structuration des
positions des lignes ou des
colonnes)
Nest Permutation des paramètres des Spécification de l'ordre dans la clause
dimensions affichées(structuration <according to>
des lignes et des colonnes)
TAB 25 : Traduction des opérations de consultation multidimensionnelles
II. Extension de Graphic-OLAPSQL

II.1 Extension de la structure de OLAPSQL+
Comme précisé précédemment, l’un de nos objectif est d’étendre l’outil OLAP-SQL+ afin
qu’il puisse répondre à des requêtes temporelles multi-versions.
Pour cela, nous proposons deux modules, l’un responsable du traitement de ces requêtes
multi-versions, et l’autre dédié au regroupement des résultats partiels.
74
Ces deux modules viennent s’ajouter au schéma global de OLAP-SQL+ (Figure FIG 29),
comme le montre la figure (FIG 36).
L’architecture modulaire du système est représentée par le schéma suivant :
Décideur
Interface utilisateur
(Graphique et textuelle)
Table
Requête temporelle dimensionnelle
BDD et
méta-base
Exécuteur de requête Module de synthèse des
multi-versions résultats partiels
Requête(s) Tables
Partielle(s) dimensionnelles
Moteur OLAP-SQL Constructeur de NJTable
FIG 35 : Extension de OLAP-SQL+ (architecture modulaire)
Les modules en bleu, sur la figure ci-dessus, sont ceux que nous devons insérer dans
l’architecture existante de OLAPSQL +
 Exécuteur de requête multi-versions

L’utilisateur exprime sa requête à travers l’interface graphique ou l’éditeur textuel. Celle-ci
est traitée par l’exécuteur de requête multi-versions, qui se charge la diviser, quand
nécessaire, en plusieurs requêtes mono-version. Pour cela il doit consulter les intervalles de
validité des versions du schéma dans la méta-base.
Ces requêtes multidimensionnelles sont par la suite traitées par le moteur OLAP-SQL.
Celui-ci se charge de leur analyse lexical, syntaxique et sémantique, avant de les traduire en
requêtes SQL comprises par le SGDB.
Le traitement des requêtes temporelles revient donc à un traitement ordinaire d’une ou

plusieurs requêtes multidimensionnelles après décomposition de la requête multi-versions en
requêtes mono-version.
Toutefois, le moteur OLAP-SQL devra subir quelques modifications pour pouvoir

effectuer correctement le traitement des requêtes mono-version. On effet, il doit tenir compte
des intervalles de validité des instances des différentes table du schéma multidimensionnel.
(cf. Chapitre 3, § II.1.3).
75
 Module de synthèse des résultats partiels
Le module de synthèse de résultats partiels se charge de regrouper les résultats des requêtes
mono-version renvoyés par le constructeur de NJTable, en un résultat global représenté par
une même table dimensionnelle.
Comme expliqué précédemment, (cf. Chapitre 3, § II.2.3), le regroupement des résultats

partiels n’est pas possible dans tous les cas. Le module de synthèse des résultats partiels doit
donc, consulter les tables de structure dans la méta-base pour vérifier que les conditions
d’intégration des résultats partiels sont satisfaites.
Ce module s’occupe aussi d’extraire les commentaires, des tables de structure, qui doivent
accompagner le résultat présenté à l’utilisateur. Seuls les commentaires concernant les
instances présentes dans le résultat sont extraits.
II.2 Extension du langage OLAP-SQL
Pour permettre à l’utilisateur d’exprimer des requêtes temporelles à travers le requêteur

textuel, il est nécessaire d’étendre le langage OLAP-SQL.
L’utilisateur interroge, par défaut, la dernière version du schéma (la plus récente). Il lui est
toutefois possible de désigner une version précise, ou un intervalle de temps pour sa requête.
Toutes les versions valides pendant cet intervalle seront interrogées.
Nous proposons donc d’ajouter des clauses à la commande SELECT de OLAP-SQL. La

syntaxe de la commende devient comme suit :
select <agreg>(<mesure1>), <agreg>(<mesure2>), …
[ according to [ rows <parametre1_lig>, <parametre2_lig>,…,
of <nomdimension_lig> with <nomhierarchie_lig>, ]
[ columns <parametre1_col>, <parametre2_col>,…, ]
of <nomdimension_col> with <nomhierarchie_col> ] ]
from <nomfait>
[ where <predicat> ]
[ order by <parametre1> values(<valeur1_1>, <valeur1_2>,…)
[…[ ,<parametre2> values(<valeur2_1>, <valeur2_2>,…)],…] ]
[version < ver_id | ver_name >] ;
Et dans le cas de choix d’un intervalle, la syntaxe est comme suit :
select …
[ according to …]
from …
[ where … ]
[ order by …]
[version from date ‘date_début’ to date ‘date_fin’] ;
76
II.3 Extension de l’interface graphique
Comme cité plus haut, dans l’existant, trois interfaces de visualisation sont fournies à
l’utilisateur [Tournier, 04]. Elles offrent une bonne vision du schéma conceptuel de la base
de données multidimensionnelle :
♦ Une visualisation arborescente;

♦ Une visualisation en graphe ;
♦ Une visualisation évoluée hyperbolique.
L’interface de visualisation en graphe du schéma multidimensionnelle est interactive, elle

permet à l’utilisateur d’effectuer les opérations de manipulation et d’interrogation e manière
complètement graphique.
Pour l’interrogation, l’utilisateur va donc sélectionner des éléments de ce graphe, générant

ainsi un sous graphe : le graphe de requête. Par la suite, Il va pouvoir modifier ce graphe de
requête afin d’observer les résultats différemment. Mais il pourra aussi changer
complètement sa requête effaçant ainsi son graphe pour recommencer. Enfin, afin d’affiner
les observations, il devra pouvoir ajouter des contraintes sur les attributs du graphe de
requête (mesures et paramètres). [Tournier, 04].
Une requête graphique se compose donc d’éléments qui seront sélectionnés

graphiquement.
L’application des opérateurs de manipulation multidimensionnels se fait à travers quelques

manipulations graphiques. La figure suivante illustre un exemple d’application d’un
opérateur de rotation « DRotate » (rotation de dimension) par un clic droit sur la souris
dimension.
FIG 36 : Application de l’opérateur DRotate sur un graphe.
77
L’utilisateur manipule, par défaut, la version du schéma la plus récente, il a aussi la

possibilité de choisir une version en particulier.
Étant donné que, dans les deux cas, l’utilisateur ne manipule qu’un seul schéma à un
moment donné, aucune modification n’est apportée aux deux modes de visualisation : en
graphe et en hyperbole.
Cependant, il est nécessaire d’ajouter, dans la représentation en arborescence, le niveau

«Version » pour permettre à l’utilisateur de sélectionner une version de son choix.
Les nœuds fils du nœud schéma représenterons donc les différentes versions du schéma. La
structure du schéma telle que présentée dans [Tournier, 04], représentera la structure des
sous arbres de racine version_schéma.
III. Conclusion
Nous avons présenté, dans ce chapitre, le prototype Graphic-OLAPSQL qui permet
implanter nos propositions.
Le prototype existant permet de définir et de manipuler une base de données

multidimensionnelle multi-versions, mais il ne couvre pas la consultation et l’interrogation.
L’interface graphique fournie permet de manipuler et d’interroger une simple base de

données multidimensionnelle et non pas multidimensionnelle multi-versions.
Notre travail a consisté donc, à faire évoluer ce prototype de façon à permettre la

consultation de bases de données multidimensionnelles temporelles multi-versions.
Dans cette optique, nous avons proposé deux nouveaux modules à insérer dans la structure
de OLAPSQL+ ainsi qu’un ensemble de modifications à apporter aux composants existants.
Nous avons également étendu la syntaxe de la commande d’interrogation du langage

OLAP-SQL, et proposé une petite évolution de la visualisation arborescente du schéma de la
base de données multidimensionnelle pour représenter les différentes versions de schéma.
Toutes nos propositions sont parfaitement réalisables. Car, d’un coté, le processus de
traitement des requêtes, détaillé dans ce rapport, couvre tous les cas d’évolutions de données
et de structure et donc tous les types de requêtes temporelles. D’un autre coté, toutes les
informations nécessaire au bon déroulement de ce processus sont disponibles dans la méta-
base, que se soit pour la décomposition des requêtes ou le regroupement des résultats
partiels
78
Conclusion
&
Perspectives
Conclusion & perspectives
Conclusion et perspectives
«La chercheur doit être libre de tester des expériences audacieuses, de soutenir des théories
révolutionnaire voire paradoxale. Il doit disposer du droit à l’erreur.» Pierre Joliot
Ce travail se situe à la croisée de deux domaines, celui des bases de données

multidimensionnelles temporelles, et celui des langages de requête graphiques.
Il consiste à concevoir un langage graphique qui permet l’interrogation de bases de données

multidimensionnelles conçues selon un modèle permettant la gestion de l’évolution
temporelle des données et schémas.
Le modèle sur lequel se base notre travail est un modèle multidimensionnel multi-versions.
Il gère les évolutions de données par ajout d’intervalles de validité, et les évolutions de
structure par historisation de versions du schéma multidimensionnel.
Un langage d’interrogation d’une base de données conçue selon ce modèle, devrait donc
pouvoir répondre à des requêtes temporelles impliquant une ou plusieurs versions du schéma
parmi celles historisées.
Notre apport, par ce travail, a été de concevoir un tel langage, qui permet d’interroger une
base de données multidimensionnelle multi-versions, à travers des interfaces graphiques.
Dans le cadre de cette proposition, nous avons été amené à :
 Compléter le modèle multidimensionnel temporel utilisé, afin de couvrir tous les cas
d’évolution et pour faciliter l’accès aux données nécessaires au traitement des requêtes. Et
proposer un ensemble de contraintes pour garantir l’intégrité du modèle.
 Proposer une classification des requêtes pouvant interroger une base de données
conçue selon ce modèle, selon qu’elles interrogent une ou plusieurs versions du schéma
multidimensionnel.
 Expliciter le traitement de chacun de ces types de requêtes temporelles, en traitant

chaque cas d’évolution de données ou de structure.
 Combiner les différents traitements pour aboutir à un langage de requête permettant

l’expression de tous les types de requêtes temporelles et couvrant tous les cas d’évolution.
Après cela, nous avons présenté les différentes évolutions qu’implique l’implantation de
notre langage dans le prototype OLAP-SQL+, et avons proposé une nouvelle syntaxe pour la
commande Select du langage OLAP-SQL, afin de pouvoir exprimer des requêtes temporelles.
Concernant l’aspect graphique, nous avons proposé une extension de l’outil Graphic-
OLAPSQL, afin d’utiliser les commandes de manipulation graphiques du schéma
multidimensionnel qu’il propose, pour une interrogation multi-versions.
79
Conclusion & perspectives
Le travail accompli, ne constitue qu’une brique dans la gestion de bases de données

multidimensionnelles temporelles et de nombreuses perspectives peuvent être envisagées,
d’une part pour améliorer notre langage et d’autre part, pour faire évoluer l’outil OLAP-SQL+
selon deux axes : la manipulation graphique et la gestion des évolutions temporelles.
Comme premières perspectives, il s’agit de :
 Améliorer l’interface de visualisation du prototype en proposant une représentation

graphique qui permet de visualiser les différentes versions de structures composant le
schéma multidimensionnel, qui soit lisible et facile à manipuler. En plus de la
visualisation en arborescence proposée, étant donné que cette dernière ne convient pas
parfaitement à la représentation de constellations.
 Définir des commandes graphiques qui permettent d’appliquer les différentes

opérations de manipulation multidimensionnelle sur les tables dimensionnelles
résultats des requêtes. En effet, l’utilisateur devrait pouvoir manipuler les tables
résultats pour modifier sa requête, sans être obligé de revenir à la représentation
graphique du schéma conceptuel.
Par ailleurs, sur un niveau plus élevé, nous voyons les perspectives suivantes :
 Afin de présenter à l’utilisateur une interface encore plus souple, il serait intéressant de
faire évoluer l’outil vers un véritable éditeur multidimensionnel. Il s’agirait de
compléter le langage de manipulation graphique par un langage de définition et un
langage de contrôle de données basés sur des interactions sur les graphes. Il serait
alors possible de créer un schéma en constellation sans la moindre requête textuelle
mais uniquement par manipulation graphique.
 En dernier lieu, afin de rendre le langage OLAP-SQL complètement temporel, il serait

intéressant d’étendre le langage de contrôle de données au multi-versions, étant donné
que les langages de définition et de manipulation le sont déjà.
80
Bibliographie
Bibliographie
Bibliographie
[Annoni, 03] E.ANNONI, « Conception et Developpement d'un langage assertionnel

pour les bases de données multidimensionnelles ». Rapport de DEA, IRIT,
Université Paul Sabatier, Toulouse, France, 2003.
Ce rapport de DEA propose une implantation d’un langage de définition de données et de

manipulation de données basé sur [Ravat et al, 02]. Il présente également le prototype
OLAP-SQL+.
[Bella, 00] Ladjel BELLATRECHE, « Utilisation des Vues Matérialisées, des Indexes et
de la fragmentation dans la conception logique et physique d’un entrepôt
de données ». Thèse de doctorat, Université de CLERMONT-FERRAND,
France, 2000.
[Benak, 05] Leïla Benakezouh, « Etude et conception de bases de données

multidimensionnelles temporelles ». Rapport de Master2 recherche
Informatique, IRIT, Université Paul Sabatier, Toulouse, France, 2006.
Le travail de ce DEA consiste à définir un modèle multidimensionnel permettant la gestion

de l’évolution temporelle des données et schémas, on se basant sur l’utilisation d’extensions
temporelles, définies par des intervalles de validité, mais aussi sur le principe de versions de
structure multidimensionnelle. Dans ce mémoire est défini aussi, un ensemble d’opérations
nécessaires à la définition et à la manipulation d’une base de données multidimensionnelle
temporelle. L’implantation de ce modèle a permis l’évolution du prototype OLAPSQL+.
[Blaschka, 00] M.BLASCHKA, FIESTA: « A Framework for Schema Evolution in

Multidimensional Databases ». Thèse de doctorat, université technique,
Munich, Allemagne, 2000.
La proposition de cette thèse repose sur une algèbre permettant l’évolution de schémas ainsi
que la définition d’un modèle multidimensionnel qui repose sur le formalisme « Entité-
Relation ». Un prototype du système FIESTA est également présenté.
[Body et al, 02] M.BODY, Y.BEDARD, M.MIQUEL, A.TCHOUNIKINE, « A

Multidimensional and Multiversion Structure for OLAP ». Article de
recherche, DOLAP’2002, 2002.
Cet article présente un modèle conceptuel permettant de prendre en charge les évolutions et
données et structures multidimensionnelles mais aussi, de gérer l’historique des versions.
L’article présente également un certain nombre d’opérateurs permettant de passer d’une
version de structure à une autre. Une implantation des propositions des auteurs est présentée à
travers un prototype brièvement expliqué.
[Body et al, 03] : M.BODY, Y.BEDARD, M.MIQUEL, A.TCHOUNIKINE,

« Handling évolutions in multidimensional structures », Article de recherche,
IEEE 19th International Conference on Data Engineering (ICDE), Bangalore,
Inde, 2003.
Bibliographie
[Böhnlein et al, 02] M.BÖHNLEIN, M.PLAHA, ULBRICH-VOM, A.ENDE, «Visual

specification of Multidimensional Queries based on a Semantic Data
Model ». Article de recherche, Data Warehouse zum Corporate Knowledge
Center, DW2002, 2002.
Cet article présente un requêteur graphique pour bases de données multidimensionnelles.

Basé sur le modèle SDWM (Semantic Data Warehouse Model), l’outil présente à l’utilisateur
deux vues sur la même fenêtre : une vue des mesures et une vue des dimensions. Il est
possible alors de choisir des éléments graphiquement pour former une requête (équivalente
au SELECT d’OLAP-SQL). Des contraintes peuvent être ajoutées sur chacun des éléments
sélectionnés afin de limiter les données traitées, l’interface présente les éléments qui peuvent
recevoir une contrainte dans une arborescence.
[Cabibbo. 1998] L.CABIBBO, R.TORLONE, « From a Procedural to a Visual Query

th
Language for OLAP». Article de recherche, 10 IEEE International
Conference on Scientific and Statistical Database Management, 1998.
Cet article propose un modèle de données multidimensionnel : MD, indépendant de toute

implantation. Il présente la comparaison entre deux langages de manipulation de données. Le
premier, algébrique, permet de manipuler les données de manière procédurale. Le second est
un langage graphique simple et intuitif.
[Chamoni et Stock, 99] P.CHAMONI, S.STOCK, «Temporal structures in Data

Warehousing ». Article de recherche, Dawak99, 1999.
[Eder et Koncilia, 01] J.EDER, C.KONCILIA, « Changes of dimension Data in

Temporal Data Warehouses ». Article de recherche, Dawak01, 2001.
Dans cette article, les auteurs proposent une extension du modèle multidimensionnel utilisé
par les magasins de données (faits, dimensions, hiérarchies) qui permet la prise en compte de
l’historique des versions de structures ainsi que de l’historique de données ayant évolué.
Cette approche repose principalement sur l’ajout d’intervalles de validité aux instances de
dimensions (données) ainsi qu’aux relations hiérarchiques entre ces instances. Les auteurs
présentent également trois opérations de base permettant de modifier la structure de leur
magasin de données temporel.
[Eder et al, 02B] J.EDER, C.KONCILIA, T.MORZY, « The COMET Metamodel

forTemporal Data Warehouses ». Article de recherche, Dawak02, 2002.
Cet article, faisant suite au précédent, présente le méta-modèle COMET, qui permet de
représenter les évolutions au niveau des donnés et schémas multidimensionnels. Cet article
décrit le méta-modèle présenté ainsi que les contraintes à respecter afin de garantir l’intégrité
de leur base de données multidimensionnelle temporelle.
[Eder et al, 05] J.EDER, C.KONCILIA, K.WIGGISSER, « A Tree Comparison

Approach to Detect Changes in Data Warehouse Structures ». Article de
recherche, Dawak05, 2005.
Bibliographie
[Fred. 99] Frédéric BRET, Olivier TESTE « Construction graphique d’entrepôts et de

magasins de données ». Article de recherche, INFORSID 1999, 165-184.
[Golfa. 05] M.GOLFARELLI, J.LECHTENBORGER, S.RIZZI, VOSSEN, « Schema

Versioning in Data Warehouses: Enabling Cross-Version Querying via
Schema Augmentation ». Article de recherche, Data and Knowledge
Engineering, 2005.
[Hubert, 97] G.HUBERT, « les versions dans les bases de données orientées objet :
modélisation et manipulation ». Thèse de doctorat, Université Paul
Sabatier, Toulouse, France, 1997.
[Hurtado et al, 99] A. HURTADO, A.O. MENDELZON, A.A. VAISMAN,

« Updating OLAP Dimensions ». Article de recherche, DOLAP’99, 1999.
[Kimball, 96] R. KIMBALL, «The Data Warehouse Toolkit». Edition John Wiley&Sons,
1996.
[Koncilia et Wrembel, 07] C. KONCILIA, R. WREMBEL, « Data Warehouses and

OLAP: Concepts, Architectures and Solutions».Edition IRM Press, 2007.
[Laurent et al]A. LAURENT, P.MARCEL, F.RAVAT, O.TESTE et G. ZURLFUH,

« Entrepôt de données et OLAP ». Un aperçu orienté recherche, Groupe de
travail GaFOLAP - Action spécifique GaFoDonnées.
[Mandelzon et Vaisman, 00] A.MANDELZON, A.VAISMAN, « Temporal queries

in OLAP ». Article de recherche, Conférence VLBD, Caire, Egypte,
2000.
[Morzy et Wrembel, 04] T.MORZY, R.WREMBEL, « On querying versions of

Multiversion Data Warehouse ». Article de recherche, DOLAP’04, 2004.
[Morzy et Wrembel, 05] T.MORZY, R.WREMBEL, « Multiversion datawarehouses,

challenges and solutions ». Article de recherche, 3ème conférence IEEE
Computational Cybernetics - ICCC'05, Maurice, 2005.
Cet article présente le concept de “multi-versions” pour les bases de données

multidimensionnelles. Les auteurs présentent ce concept à travers la définition de version
réelles ‘reflétant les changements réels’ et de versions alternatives (crées pour des besoins de
simulation). En dernier lieu, les auteurs introduisent l’interrogation de données multi-versions
réalisée par l’opérateur « SELECT » qu’ils proposent d’étendre.
[Pedersen et Jensen, 99] T B. Pedersen, C.S. Jensen, « Multidimensional Data

Modeling for ComplexData », Article de recherche, Proceedings of the
15th International Conference on Data Engineering (1999) – ICDE’99,
1999.
Bibliographie
[Ravat et al, 02] F.RAVAT, O.TESTE, G.ZURFLUH, « Langage pour bases

multidimensionnelles OLAP-SQL ». Article de recherche, Revue des
Sciences et Technologies de l'Information, 2002.
Cet article définit un langage de définition de données, de manipulation de données et de

contrôle de données pour bases de données multidimensionnelles implantées en relationnel.
Ce langage se repose sur l’extension multidimensionnelle du standard SQL.
[Ravat, 06A] Franck RAVAT, Olivier TESTE, Gilles Zurfluh «A multiversion-based

multidimensional model». Article de recherche, 8 ème conférence
internationale Dawak2006, 2006.
L’article propose un modèle supportant les évolutions de données et les évolutions de

schémas. L’approche consiste à sauvegarder des versions du schéma en étoile pour les
évolutions de structures alors que les changements des données sont enregistrés à travers les
instances de dimension et les instances de fait dans une version d’étoile.
[Ravat, 06B] Franck RAVAT, Olivier TESTE « Supporting data changes in

multidimensional data warehouses ». Article de recherche, revue :
International Review on Computers and Software (I.RE.CO.S.), 2006.
Dans cet article, faisant suite au précédent, les auteurs apportent quelques modifications à
leur modèle en introduisant des changements dans les définitions des composants de la BDM.
Ils traitent aussi la question OLAP au niveau logique suivant le paradigme R-OLAP. Le
modèle logique proposé est basé sur des tables de version de données (instances de fait et de
dimension) et des tables de structure (version d’étoile et processus de dérivation entre
versions).
[Sallami 2004] Sallami M., « Bases de données multidimensionnelles : définition d’un

langage de contrôle de données », rapport de stage de DEA à l’IRIT au sein
de l’équipe SIG, 2004.
[Serre, 04] Elvire SERRES, « Le Système d’Information Décisionnel ». Thèse

professionnelle, Mastère MSIT, HEC-Ecole des Mines, France, 2004.
[Teste, 01] Olivier TESTE, « Modélisation et manipulation d’entrepôts de données

complexes et historisées ». Thèse de doctorat, Université Paul Sabatier,
Toulouse, France, 2001.
Ce mémoire de thèse définit un modèle de donnée pour l’entrepôt de données. Il permet de

décrire l’évolution temporelle des objets complexes au travers de l’extension du concept
d’objet avec des filtres temporels et d’archivages et des fonctions de construction.
[Tournier, 04] R.Tournier, « Bases de données multidimensionnelles : Etude et

Implantation d’un langage graphique ». Rapport de DEA, IRIT, Université
Paul Sabatier, Toulouse, France, 2004.
Bibliographie
Ce mémoire de DEA présente un modèle multidimensionnel et définit son formalisme

graphique, ainsi qu’une algèbre multidimensionnelle et un langage de manipulation
graphique. L’outil implémenté « Graphic-OLAP-SQL » présente une triple interface
graphique de visualisation et adaptée aux différents besoins du modèle : une visualisation
arborescente, une visualisation en graphe fidèle au formalise de représentation graphique et
une visualisation hyperbolique en cas de surcharge de schéma en constellation.
[Trujillo et Palomar, 98] J. Trujillo, M. Palomar, « An Object Oriented Approach to

MultidimensionalDatabase Conceptual Modeling (OOMD) », Article de
recherche, DOLAP’98, 1998.
[Vaisman, 01] A.VAISMAN, «Updates: View maintenance and time management in

multidimensional databases ». Thèse de doctorat, université de Buenos
Aires, Argentine, 2001.

Memoire Magister S.hafyane2

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Memoire Magister S.hafyane2

Загружено:

Авторское право:

Доступные форматы

Ministère de l’enseignement supérieur et de la recherche scientifique

Institut national de formation en informatique

Langage d’interrogation graphique des

Soutenu le devant le jury composé de :

Je dédie ce mémoire à tous ceux qui m’aiment et que j’aime. Plus

Je remercie sincèrement Mademoiselle Leïla BENAKEZOUH pour m’avoir encouragé à

Je tiens à adresser tous mes remerciements à Monsieur A.Balla, Monsieur K.W.Hidouci et

Mots clés : Base de données multidimensionnelles, modèle multidimensionnel multi-

Key words : Multidimentional database, multidimensional multiversion model,

Table des matières

Liste des figures

Introduction générale ..............................................................................................................1

PARTIE 1: Etat de l'art

Chapitre 1 : Concepts de base .................................................................................................5

I. Le Système d’Information Décisionnel (SID)…………………………………………5

III. Les langages pour bases de données multidimensionnelles………………………...

Chapitre 2 : Evolutions au sein du modèle multidimensionnel .............................................. 17

I. Gestion des évolutions temporelles………………………………………………….. 17

II. Travaux liés aux multi-versions dans le cadre du modèle multidimensionnel………21

Chapitre 3 : Modèle multidimensionnel multi-versions ......................................................... 33

I. Modèle conceptuel multidimensionnel……………………………………………….33

II. Modèle R-OLAP multi-versions……………………………………………………. 37

III. Bilan et contribution ……………………………………………………………… 42

Chapitre 4 : Requêtes multidimensionnelles temporelles ....................................................... 45

I. Classification des requêtes 45

II. Traitement des requêtes multidimensionnelles 48

Chapitre 5 : Réalisation ........................................................................................................ 65

II. Extension de Graphic-OLAPSQL…………………………………………………...74

Conclusion générale et perspectives………………………………………………………….79

Liste des figures

Figure Titre Page

FIG 1 Architecture des systèmes décisionnels 5

Liste des tableaux

Tableau Titre Page

TAB 1 Exemple vente/catégorie/région 8

Le Système d’Information Décisionnel (SID) a fait donc, son apparition au côté du

L'informatique décisionnelle a pour objectif d'élaborer des systèmes d'analyse de données

Cependant, la recherche dans le domaine des bases de données multidimensionnelles ne se

Les premières approches développées nécessitaient la connaissance de la structure de la

Dans le contexte décisionnel, ce travail consiste à proposer un langage graphique

Cependant, la plupart des propositions existantes se sont axées seulement sur la

En implémentant ce langage, nous devrions aboutir à un outil OLAP grâce auquel

III. Organisation du mémoire

La deuxième partie présente notre contribution, qui consiste à concevoir un outil

 Chapitre III : Ce chapitre présente le modèle multidimensionnel multi-versions sur

 Chapitre IV : représentant le cœur de notre travail, ce chapitre explicite la solution que

Chapitre 1 : Concepts de base

I. Le Système d’Information Décisionnel (SID)

Le système d'information décisionnel, ou SID, correspond à l'exploitation des données de

Positionnement du sujet de ce mémoire

Les sources de données sont nombreuses, variées, distribuées et autonomes. Elles

Dans cette phase se fait également le nettoyage des données : l’homogénéisation, la

- La restitution ou reporting, c’est la face visible du décisionnel, la partie que voient

Dans la modélisation multidimensionnelle nous distinguons trois niveaux d’abstraction, à

II.1 Modélisation conceptuelle

La modélisation conceptuelle se fait soit à travers le cube de données ou les concepts de

II.1.1 Le cube de données

Exemple : [Teste, 01]

Catégories des produits Régions Montant des ventes

TAB 1 : Exemple vente/catégorie/région

FIG 2: Exemple : représentation multidimensionnelle

II.1.2 Modélisation basée sur les faits et de dimensions

Exemple 1 : La figure suivante présente le fait « VENTES » et ses mesures « Montant »

FIG 3 : Le fait Ventes avec ses deux mesures