Académique Documents
Professionnel Documents
Culture Documents
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
2007/2008
Dédicace
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.
Mes remerciements vont aussi à Mademoiselle Ammar-Khoudja Nawel pour avoir toujours
été là pour moi.
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.
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.
I. Contexte du mémoire…………………………………………………………………..1
II. Problématique…………………………………………………………………………2
III. Organisation du mémoire……………………………………………………………. 3
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. Synthèse……………………………………………………………………………. 32
Table des matières
PARTIE 2: Contributions
III. Conclusion 64
I. Existant 65
I.1 Architecture du prototype OLAPSQL + ............................................................. 66
I.2 Commandes du langage OLAP-SQL..................................................................72
III. Conclusion………………………………………………………………………….78
Bibliographie
Liste des figures
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 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.
1
Introduction générale
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.
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
Introduction générale
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.
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.
3
Introduction générale
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
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.
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.
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
5
Etat de l’art Chapitre I : Notions de base
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.
- 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
Etat de l’art Chapitre I : Notions de base
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]
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.
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
Etat de l’art Chapitre I : Notions de base
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.
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
Etat de l’art Chapitre I : Notions de base
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.
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.
Temps Dimension
Paramètre Temps
Jour
Jour_desc Hiérarchie
Mois
Mois_desc
Année Attribut
9
Etat de l’art Chapitre I : Notions de base
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.
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.
10
Etat de l’art Chapitre I : Notions de base
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.
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.
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.
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.
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
Etat de l’art Chapitre I : Notions de base
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'
12
Etat de l’art Chapitre I : Notions de base
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.
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
Etat de l’art Chapitre I : Notions de base
Quelques travaux de recherche, ainsi que des outils commerciaux, ont proposés des
interfaces graphiques dédiées au multidimensionnel.
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
Etat de l’art Chapitre I : Notions de base
Cependant, les travaux sur les langages de manipulation graphique, sont beaucoup plus
rares que ceux sur les langages de définition graphique.
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
Quant aux outils commerciaux, ils s’améliorent d’année en année. Nous pouvons citer :
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
Etat de l’art Chapitre I : Notions de base
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.
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
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.
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.
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.
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
Etat de l’art Chapitre II : Evolutions au sein du modèle multidimensionnel
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].
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.
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]
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]
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.
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
Etat de l’art Chapitre II : Evolutions au sein du modèle 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].
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.
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
Etat de l’art Chapitre II : Evolutions au sein du modèle multidimensionnel
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 :
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
Etat de l’art Chapitre II : Evolutions au sein du modèle 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.
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
Etat de l’art Chapitre II : Evolutions au sein du modèle multidimensionnel
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.
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).
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
22
Etat de l’art Chapitre II : Evolutions au sein du modèle multidimensionnel
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.
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
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
Etat de l’art Chapitre II : Evolutions au sein du modèle multidimensionnel
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
multidimensionnelle.
Pour implémenter le modèle proposé dans les outils OLAP existants, les auteurs ont choisit
une architecture constituée de trois parties :
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
Etat de l’art Chapitre II : Evolutions au sein du modèle multidimensionnel
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).
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 :
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é.
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
Etat de l’art Chapitre II : Evolutions au sein du modèle multidimensionnel
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.
- 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.
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 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
Etat de l’art Chapitre II : Evolutions au sein du modèle multidimensionnel
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 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
Etat de l’art Chapitre II : Evolutions au sein du modèle multidimensionnel
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.
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.
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).
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
Etat de l’art Chapitre II : Evolutions au sein du modèle multidimensionnel
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’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.
29
Etat de l’art Chapitre II : Evolutions au sein du modèle multidimensionnel
30
Etat de l’art Chapitre II : Evolutions au sein du modèle multidimensionnel
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.
- 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.
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
multidimensionnelle.
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
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.
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é.
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
Contributions Chapitre III : Modèle multidimensionnel multi-versions
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.
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 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.
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.
Contributions Chapitre III : Modèle multidimensionnel multi-versions
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.
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)
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.
35
Contributions Chapitre III : Modèle multidimensionnel multi-versions
DVi
Définition 6. Une hiérarchie H j est définie par (NDVij, PDVij, WADVij)
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.
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.
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
Contributions Chapitre III : Modèle multidimensionnel multi-versions
Les états consécutifs des faits et dimensions aussi bien que leurs relations sont définis à
travers cinq versions d’étoile :
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
DVMagasin2 SVStock.2
SVVentes.2 DVTemps.1
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.
37
Contributions Chapitre III : Modèle multidimensionnel multi-versions
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).
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
Contributions Chapitre III : Modèle multidimensionnel multi-versions
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
Ces tables de structure stockent les données décrivant des structures multidimensionnelles et
leurs évolutions.
39
Contributions Chapitre III : Modèle multidimensionnel multi-versions
- 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).
- 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
Contributions Chapitre III : Modèle multidimensionnel multi-versions
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
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, …}
41
Contributions Chapitre III : Modèle multidimensionnel multi-versions
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_GeoFr All 5 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
DVMagasin.2 H_GeoFr All 4 P
TAB 13 : La table de structure de «HIERARCHIE »
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é:
42
Contributions Chapitre III : Modèle multidimensionnel multi-versions
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.
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
Contributions Chapitre III : Modèle multidimensionnel multi-versions
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.
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
IS5 DVMagasin.2 IS3 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.
Conclusion
Le modèle ainsi défini, servira de base à la définition de notre langage d’interrogation
multidimensionnel multi-versions.
44
Contributions Chapitre IV : Requête multidimensionnelle multi-versions
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.
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.
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
45
Contributions Chapitre IV : Requête multidimensionnelle multi-versions
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) :
SVVentes.2 DVTemps.1
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
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 :
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.
46
Contributions Chapitre IV : Requête multidimensionnelle multi-versions
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.
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
Contributions Chapitre IV : Requête multidimensionnelle multi-versions
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.
48
Contributions Chapitre IV : Requête multidimensionnelle multi-versions
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.
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.
Les instances d’une version de dimension sont mises à jour dans les cas suivants :
49
Contributions Chapitre IV : Requête multidimensionnelle multi-versions
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.
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 :
« Le montant des ventes du produit IP1 par magasins et par clients à une date IT1 »
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.
VENTES Client
(Montant) Id Client IC1 IC2
Magasin Id Magasin
IS7 60.00 40.00
Id Produit = ‘IP1’, Id Temps = ‘IT1’
Modification du nom du magasin IS4 (IS4 IS7) le 02/07/2006
FIG 16: Exemple d’un résultat correct (table multidimensionnelle)
50
Contributions Chapitre IV : Requête multidimensionnelle multi-versions
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.
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
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
IS5 DVMagasin.2 IS3 01/01/2006 DVMagasin.2 dérive de DVMagasin.1
IS7 DVMagasin.2 IS4 02/07/2006 Le magasin change de nom
TAB 21 : La table de structure « IDERIVD » de MAGASIN
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.
VENTES Client
(Montant) Id Client IC3
Magasin Id Magasin
IS6 500.00
Id Produit = ‘IP3’, Id Temps = ‘IT3’
FIG 17 : Résultat de l’exemple 2 (table multidimensionnelle)
51
Contributions Chapitre IV : Requête multidimensionnelle multi-versions
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é.
VENTES Client
(Montant) Id Client IC2 IC3
Magasin Id Magasin
IS6 20.00 500.00
Id Produit = ‘IP4’, Id Temps = ‘IT3’
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.
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é.
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
Contributions Chapitre IV : Requête multidimensionnelle multi-versions
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)
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.
53
Contributions Chapitre IV : Requête multidimensionnelle multi-versions
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
Temps >= T1, Temps<= T3
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).
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.
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
Contributions Chapitre IV : Requête multidimensionnelle multi-versions
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 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.
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é.
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.
55
Contributions Chapitre IV : Requête multidimensionnelle multi-versions
Modification de dimension
56
Contributions Chapitre IV : Requête multidimensionnelle multi-versions
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.
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.
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
Contributions Chapitre IV : Requête multidimensionnelle multi-versions
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
DVMagasin2 SVStock.2
SVVentes.2 DVTemps.1
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 :
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.
Cette requête concerne, donc, le fait STOCK et les dimensions PRODUIT et MAGASIN.
58
Contributions Chapitre IV : Requête multidimensionnelle multi-versions
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.
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.
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.
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.
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.
59
Contributions Chapitre IV : Requête multidimensionnelle multi-versions
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.
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.
Exemple : Soit la requête: « Quantité en stock, par produit par état entre T1 et T3 ».
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
Contributions Chapitre IV : Requête multidimensionnelle multi-versions
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.
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.
- 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.
61
Contributions Chapitre IV : Requête multidimensionnelle multi-versions
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.
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.
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 -
Temps >= T1, Temps<= T3
Fermeture du magasin IS2 le 31/07/2005
FIG 23 : Résultat partiel sur SVVentes.1 (exemple.1)
VENTES Produit
(Montant) Id Produit IP1 IP4 IP6
Magasin Id Magasin
IS5 50.00 - -
IS6 - 520.00 -
IS7 250.00 - 60.00
Temps >= T1, Temps<= T3
Modification du nom du magasin IS4 (IS4 IS7) le 02/07/2006
Modification du nom du produit IP3 (IP3 IP4) le 31/07/2006
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
Contributions Chapitre IV : Requête multidimensionnelle multi-versions
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
Temps >= T1, Temps<= T3
Fermeture du magasin IS2 le 31/07/2005
Modification du nom du magasin IS4 (IS4 IS7) le 02/07/2006
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.
Considérons la requête : « Montant des ventes par date et par produit entre T1 et T3 ».
VENTES Produit
(Montant) Id Produit IP1 IP2
Magasin Id Temps
IT1 220.00 130.00
IT2 200.00 -
Temps >= T1, Temps<= T3
Fermeture du magasin IS2 le 31/07/2005
FIG 26 : Résultat partiel sur SVVentes.1 (exemple 2)
VENTES Produit
(Montant) Id Produit IP1 IP4 IP6
Magasin Id Temps
IT1 100.00 - -
IT2 200.00 - -
IT3 - 520.00 60.00
Temps >= T1, Temps<= T3
Modification du nom du magasin IS4 (IS4 IS7) le 02/07/2006
Modification du nom du produit IP3 (IP3 IP4) le 31/07/2006
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
Contributions Chapitre IV : Requête multidimensionnelle multi-versions
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
Temps >= T1, Temps<= T3
Fermeture du magasin IS2 le 31/07/2005
Modification du nom du magasin IS4 (IS4 IS7) le 02/07/2006
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.
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 :
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.
65
Contributions Chapitre V : Réalisation
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.
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.
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.
66
Contributions Chapitre V : Réalisation
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.
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.
67
Contributions Chapitre V : Réalisation
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.
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.
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,…).
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
Contributions Chapitre V : Réalisation
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 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]
69
Contributions Chapitre V : Réalisation
Visualisation arborescente
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).
70
Contributions Chapitre V : Réalisation
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.
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.
71
Contributions Chapitre V : Réalisation
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.
É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
Contributions Chapitre V : Réalisation
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 :
Le résultat de cette requête est la table bidimensionnelle représenté par la figure FIG 31.
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
Contributions Chapitre V : Réalisation
Le tableau suivant résume ces opérations et leur traduction en OLAP-SQL. [Ravat et al, 02]
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
Contributions Chapitre V : Réalisation
Ces deux modules viennent s’ajouter au schéma global de OLAP-SQL+ (Figure FIG 29),
comme le montre la figure (FIG 36).
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
Les modules en bleu, sur la figure ci-dessus, sont ceux que nous devons insérer dans
l’architecture existante de OLAPSQL +
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.
75
Contributions Chapitre V : Réalisation
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.
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.
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.
select …
[ according to …]
from …
[ where … ]
[ order by …]
76
Contributions Chapitre V : Réalisation
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 :
77
Contributions Chapitre V : Réalisation
É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.
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.
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.
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
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.
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.
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
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.
80
Bibliographie
Bibliographie
Bibliographie
[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.
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é.
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é.
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.
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.
[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.
[Kimball, 96] R. KIMBALL, «The Data Warehouse Toolkit». Edition John Wiley&Sons,
1996.
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).