Du DataWarehouse au WebHouse :

le croisement des rseaux et

des bases de donnes
Samira Silhadi-Hacid
Malika Tarafi

1. Introduction
Un entrept de donnes (data warehouse) [Kim96, Inmo96] est un ensemble de
technologies destines permettre une personne qui manipule des connaissances
(gestionnaire, analyste, cadre) de prendre de bonnes et rapides dcisions. Pour une
bonne aide la dcision, la personne est suppose avoir la bonne information, la
bonne place, au bon moment et avec un faible cot. La pratique a montr que les
systmes transactionnels ne sont pas appropris pour laide la dcision et que
les avances ralises dans le domaine des rseaux ne peuvent, elles seules,
rsoudre le problme de laccessibilit linformation.
Lentrept de donnes est devenu une stratgie importante pour intgrer des
sources dinformations htrognes dans les organisations, et permettre un
traitement analytique en-ligne. Le dveloppement des entrepts de donnes est
une consquence de lobservation, par W. Inmon et E. F. Codd, au dbut des
annes 90, sur le fait que le niveau oprationnel du traitement transactionnel enligne (OLTP) et les applications daide la dcision (OLAP) ne peuvent pas
coexister efficacement dans le mme environnement de bases de donnes,
essentiellement cause de leurs caractristiques transactionnelles trs diffrentes.
Un entrept de donnes centralise des donnes dintrt slectionnes pour un
groupe de clients, de telle sorte que laccs devienne rapide, moins coteux et plus
efficace. Considr comme un tampon long-terme entre lOLTP et lOLAP (figure
1), lentrept de donnes pose deux problmes importants : (1) comment
rconcilier les donnes manant de multiples sources dinformations htrognes ;
(2) comment personnaliser les donnes drives pour des applications OLAP
spcifiques.

Systmes OLTP

DW

Schma
oprationnel

Schma
du DW

Donnes
oprationnelles

Donnes
consolides

Applications
OLAP
Schma
utilisateur
Donnes
drives

Figure 1 : Du traitement transactionnel au traitement analytique

Nous considrons un entrept de donnes comme une collection de donnes

orientes sujet, intgres, variables dans le temps, et non volatiles, utilises
essentiellement pour laide la dcision. Le but dun entrept de donnes est de
supporter le traitement analytique en-ligne (OLAP). Les exigences en terme de
fonctionnalits et de performances de ces traitements sont diffrents de ceux des
applications de traitement transactionnel en-ligne (OLTP), habituellement
supports par les bases de donnes oprationnelles. Pour permettre des analyses et
visualisation complexes, les donnes dans lentrept sont organises selon le
modle de donnes multidimensionnel. La modlisation de donnes
multidimensionnelle signifie lagrgation partielle des donnes de lentrept selon
diffrents critres.

1.1 Agrgation multidimensionnelle

Le march traditionnel des bases de donnes traite des applications de traitement
transactionnel en-ligne (OLTP). Les applications OLTP se caractrisent par un
grand nombre de transactions relativement simples. Habituellement, les
transactions retrouvent et mettent jour un petit nombre denregistrements qui
sont contenus dans plusieurs tables distinctes. Les relations entre ces tables sont
gnralement simples. Une transaction OLTP typique pour une entre commande
client pourrait retrouver toutes les donnes relatives un client spcifique et
ensuite insrer une nouvelle commande pour le client. Les relations entre les
enregistrements sont simples et seul un petit nombre denregistrements est
retrouv ou mis jour pour une transaction donne.
Cependant, ce qui est attendu de la technologie de linformation daujourdhui
cest la possibilit daider les utilisateurs de connaissances (gestionnaire, analyste,
etc.) dans la prise de dcision. Des requtes typiques quun utilisateur voudrait
formuler son entrept de donnes de lentreprise sont :
. Quelles taient les quantits vendues par rgion et catgorie de produit pour
lanne prcdante ?
. Comment le prix des actions des constructeurs dordinateurs est-il corrl avec
les profits trimestriels au cours des 10 dernires annes ?
. Quelles commandes doivent tre satisfaites pour maximiser les profits ?

Il est clair que de telles exigences en matire dinterrogation ne peuvent tre

satisfaites par les systmes traditionnels.

1.2 OLAP et aide la dcision

Les applications OLAP sont assez diffrentes des applications OLTP. LOLAP fait
partie de systmes daide la dcision et des systmes dinformation excutifs. La
fonctionnalit des OLAP est caractrise par lanalyse multidimensionnelle et
dynamique de donnes consolides qui supportent les activits analytique et
navigationnelle dun utilisateur final. Au niveau pratique, lOLAP entrane
toujours linterrogation interactive des donnes, en ralisant des analyses travers
de multiples passes, comme drill-down, successivement dans des niveaux de
dtail infrieurs.
Linformation est multidimensionnelle, signifiant pour lutilisateur quelle peut
tre visualise sous forme de grilles. Elle est typiquement visualise sous forme
de cubes, et des outils proposent la possibilit de pivoter les axes du cube. Une
caractristique des outils OLAP pour lanalyse de donnes est de permettre la
consolidation de donnes des niveaux suprieurs, tout en supportant des requtes
sur les niveaux de dtail. Considrons lexemple suivant de session danalyse
OLAP : une base de donnes OLAP peut consister en des donnes ventes qui ont
t agrges par rgion, type de produit, et type de distribution. Une requte
OLAP typique pourrait accder une base de donnes ventes de plusieurs gigabytes
contenant des informations sur plusieurs annes afin de retrouver toutes les ventes
de produits dans chaque rgion pour chaque type de produit. Aprs avoir explor
les rsultats, un analyste pourrait alors affiner la requte pour retrouver les
quantits vendues pour chaque type de distribution dans des classifications
rgion/produit. Comme dernire tape, lanalyste pourrait vouloir raliser des
comparaisons annes-annes ou trimestre-trimestre pour chaque type de
distribution.

2. Une architecture pour les entrepts de

donnes
Larchitecture dun entrept de donnes influence plusieurs facteurs comme la
disponibilit des donnes et lefficacit des traitements. Larchitecture la plus
simple consiste seulement en des bases de donnes sources, un entrept de
donnes central et plusieurs clients. Parce que les applications des entrepts de
donnes sont devenues plus complexes, les entrepts sont construits en utilisant
des architectures multi-niveaux afin daccrotre la performance, i.e., il ny a pas
seulement un entrept de donnes cantral, mais aussi des data marts qui
permettent de placer les donnes le plus proche de lutilisateur final.

La figure 2 donne un aperu des composants dun entrept de donnes et les

relations entre ces composants. Les donnes sont charges par des wrappers
partir de plusieurs sources dans lentrept de donnes. Dans lentrept, les
donnes sont intgres pour respecter un schma commun. Un administrateur
contrle les composants pour le chargement et la distribution des donnes. La
mtabase est un entrept qui contient des informations relatives aux diffrents
composants.
Clients

OLAP

SIG

Data
mart

SAD

Data
mart

Administrateur
Mta
base

DW

Wrappers/Chargeurs

Sources

Fichiers

BD

Donnes
externes

Figure 2 : Architecture gnrale dun entrept de donnes

2.1 Les composants dun entrept de donnes

2.1.1 Sources et wrappers
Concernant les sources, les compagnies spcialises dans les entrepts de donnes
tentent de prendre en compte autant de sources de donnes que possible. Les
catgories de sources dinformation suivantes sont mentionnes dans le contexte
de lintgration de sources de donnes :
. Systmes de bases de donnes (relationnel, orient-objet, rseau, hirarchique)
. Sources dinformation externes (informations obtenues auprs dautres
compagnies, rsultats dtudes, )
. Fichiers dapplications standards (e.g., Excel)
. Dautres documents (e.g., word, WWW)
4

Les wrappers et les chargeurs sont des programmes qui chargent les donnes des
sources dinformation dans lentrept de donnes. Ces programmes sont
responsables du chargement, de la transformation, du nettoyage et de la mise
jour des donnes des sources dans lentrept. Une liste dtaille doutils pour ces
tches peut tre trouve dans [Gree97]. Ces outils essayent dautomatiser ou
fournissent une aide pour les tches qui sont :
. Lextraction (accdant diffrentes bases de donnes sources)
. Le nettoyage (trouver et rsoudre les inconsistances dans les donnes sources)
. La transformation (transformation entre diffrents formats de donnes, langages,
etc.)
. Le chargement (chargement des donnes dans lentrept)
. Lanalyse (dtection des valeurs non valides/inattendues)
. Le transfert de donnes haut dbit (important pour les gros entrepts de
donnes)
. Le test pour la qualit de donnes, correction et compltude
. Analyse des mta donnes (pour supporter la conception dun entrept de
donnes)
2.1.2 Entrept de donnes et data marts
Le systme de gestion de bases de donnes qui est utilis pour lentrept de
donnes lui-mme et les data marts doit tre un systme trs performant, qui
rpond aux exigences en terme dinterrogations complexes exprimes par les
clients. Les architectures suivantes sont utilises pour lentrept de
donnes [Weld97] :
. Les systmes de gestion de bases de donnes relationnels
. Les systmes de gestion de bases de donnes super-relationnels
. Les systmes de gestion de bases de donnes multidimensionnels
. Les systmes de gestion de bases de donnes orient-objets
Les systmes de gestion de bases de donnes relationnelles sont plus flexibles
quand ils sont utiliss avec une structure de donnes normalise. Parce que les
structures de donnes normalises sont non redondantes, les relations normalises
sont utiles pour un travail oprationnel journalier. Dans un contexte OLAP, les
requtes concernent plusieurs structures et donc ncessitent plusieurs oprations
de jointures sur une structure de donnes normalise.
2.1.3 Les applications clients
LOLAP est lune des applications importantes pour les entrepts de donnes. Des
requtes OLAP typiques scrutent de nombreuses relations, ralisent de
nombreuses jointures et agrgations. Au contraire, les systmes de gestion de

bases de donnes, qui sont utiliss pour un travail oprationnel quotidien, appels
systmes de traitement transactionnels en-ligne (OLTP), sont optimiss pour
assurer un petit nombre de transactions et les requtes utilisent des cls primaires
et des indexes spcialiss. Alors que les systmes OLTP stockent uniquement
linformation courante, les entrepts de donnes contiennent des donnes
historiques et consolides. Ces donnes sont utilises par les gestionnaires pour
trouver des tendances dans les marchs, et aident les gestionnaires dans la prise de
dcision. Les oprations typiques excutes par les clients OLAP sont [CD97] :
. Roll-up (relever le niveau dagrgation)
. Drill-down (diminuer le niveau dagrgation)
. Slice et Dice (slection et projection)
. Pivot (r-orienter la vue multidimensionnelle)
Pour rendre les SGBDs plus utiles pour les applications OLAP, les vendeurs leur
ont ajout de nouvelles fonctions. Ces caractristiques, dites super-relationnelles,
comportent un support pour lextension aux formats de stockage, et des schmas
dindexation spcialiss. Pour fournir des temps daccs rapides aux applications
OLAP, les donnes sont organises selon un schma en toile (star) ou en flocon
(snowflake).
Un schma en toile consiste en une table de faits centrale et plusieurs tables
dimensions. Les mesures dintrt pour lOLAP sont stockes dans la table des
faits (e.g., ventes, stock). Pour chaque dimension du modle multidimensionnel il
existe une table (e.g., rgion, produit, temps). Cette table stocke les informations
relatives aux dimensions.
Temps

Gographie

Code Temps
Code Trimestre
Nom Trimestre
Code Mois
Nom Mois
Date

Code Gographie
Code Rgion
Responsable Rgion
Code Etat
Code Vil e
...

Ventes
Code Gographie
Code Temps
Code Compte
Code Produit
Montant en FF
Units

Compte

Produit

Code Compte

Code Produit
Nom Produit
Code Marque
Nom Marque
Code Ligne Prod.
Nom Ligne Prod.

...

Figure 3 : Schma en toile

La figure 3 est un exemple de schma en toile. La table ventes au centre de

ltoile est la table de faits avec les cls trangres code gographie, code temps,
code compte, et code produit vers les tables dimensions correspondantes. Les
dimensions sont souvent organises de faon hirarchique. Chaque table
dimension consiste en plusieurs attributs dcrivant un niveau de dimension. Par
exemple, la dimension produit est organise dans une hirarchie comportant les
niveaux produit, catgorie de produit, et marque. La structure hirarchique dune
dimension est particulirement importante pour les oprations drill-down et rollup. Chaque hirarchie est reprsente par un ou plusieurs attributs dans la table
dimension. Les tables dimensions ont une structure dnormalise. A cause des
problmes relatifs aux structures de donnes dnormalises, comme la
redondance, il peut tre utile de crer un schma en flocon. Ceci est fait en
normalisant les tables dimensions du schma en toile. Un schma en flocon
correspondant au schma en toile de la figure 3 est donn figure 4. Par exemple,
la table temps est maintenant divise en trois nouvelles tables : temps, trimestre et
mois.
...
...
...
Trimestre
Code Trimestre
Nom Trimestre

Gographie
Temps

...

Code Temps
Code Trimestre
Code Mois

Mois

Ventes
Code Gographie
Code Temps
Code Compte
Code Produit
Montant en FF
Units

Code Mois
Nom Mois

...

Compte
Code Compte

...

...

...

Produit
...

...
...
Figure 4 : Schma en flocon

Le modle de donnes rsultant peut tre trs complexe et difficile comprendre

pour un utilisateur final. Les vendeurs de SGBDs, comme Informix et Sybase,
tentent de cacher cette complexit derrire un moteur spcial pour OLAP.
Larchitecture rsultant est appele OLAP relationnel (ROLAP).

Les systmes de gestion de bases de donnes multidimensionnelles sont plus

appropris pour les applications OLAP car le modle de donnes
multidimensionnel correspond mieux la faon dont les utilisateurs OLAP
apprhendent, visualisent et travaillent avec les donnes. LOLAP ncessite
lanalyse de gros volumes de donnes complexes et relies entre elles, et la
visualisation de ces donnes selon plusieurs perspectives [Kena95]. Les systmes
de gestion de bases de donnes multidimensionnelles (SGBDM) stockent les
donnes dans des cubes n-dimensionnels. Chaque dimension reprsente une
perspective. Par exemple, les donnes ventes dune compagnie peuvent avoir les
dimensions produit, rgion, et temps. Grce la faon dont les donnes sont
stockes, il ny a pas doprations de jointure ncessaires pour rpondre aux
requtes qui retrouvent les donnes ventes par lune de ces dimensions. Par
consquent, pour les applications OLAP, les SGBDM sont souvent plus
performants que les SGBDR classiques [Coll96]. Un problme avec les SGBDM
est que la restructuration est beaucoup plus coteuse que dans les bases de
donnes relationnelles. De plus, il ny a pas actuellement de langages de dfinition
et de requtes standards pour le modle de donnes multidimensionnel.
En pratique, le SGBDM est utilis pour complter une architecture dentrepts de
donnes [Sahi96]. Il obtient ses donnes dun entrept de donnes relationnel et
les fournit aux applications OLAP.
Application
OLAP

Outil
d'unterrogation
ad'hoc

BDMD

DW

Sources

Figure 5 : Un SGBDMD dans un environnement entrept de donnes

Comme le montre la figure 5, les requtes ad-hoc sont envoyes directement

lentrept de donnes, alors que les applications OLAP travaillent sur le modle
de donnes plus appropri du SGBDM.

Cette stratgie est aussi propose par les vendeurs de bases de donnes
multidimensionnelles comme Arbor Software [Arbo96] et Oracle [Orac97].
Comme il a t dit prcdemment, OLAP est une application importante des
entrepts de donnes. Les autres applications clientes possibles sont :
. Rapports et outils dinterrogation
. Systmes dinformation gographiques (SIG)
. Fouille de donnes (Data-Mining)
. Systmes daide la dcision (SAD)
. Systmes dinformation excutifs (SIE)
. Statistiques
Les applications OLAP ncessitent un support pour les oprations spciales rotate,
slice, dice, roll-up, et drill-down dun cube multidimensionnel. Ce support est
fourni par les systmes de bases de donnes multidimensionnelles et les serveurs
OLAP relationnels.

3. Construction des entrepts de donnes

Nous distinguons deux niveaux dans la construction des entrepts de donnes. Le
premier niveau correspond la construction des sources de donnes
oprationnelles, et lentrept de donnes global. Le second niveau englobe tous
les entrepts de donnes locaux. La raison de cette distinction est qu chaque
niveau, sont associes fondamentalement diffrentes tapes de traitement et
difficults techniques.
Au premier niveau, le processus de construction est dcompos en quatre tapes
principales, qui sont : (1) extraction des donnes des sources de donnes
oprationnelles, (2) transformation des donnes aux niveaux structurel et
smantique, (3) intgration des donnes, et (4) stockage des donnes intgres
dans le systme cible. La figure 8 rsume lenchanement de ces tapes de
traitement.
Source

Extraction

Transformation

Intgration

Chargement

DW

Figure 8 : Etapes de traitement du premier niveau de construction dun entrept de donnes.

Notez cependant que cette dcomposition est seulement logique. L tape

dextraction et une partie de ltape de transformation peuvent tre groupes dans
le mme composant logiciel, tel quun wrapper ou un outil de migration de
donnes. Ltape dintgration est souvent couple avec des possibilits de

transformation de donnes riches dans un mme composant logiciel, qui,

habituellement ralise le chargement dans lentrept de donnes. Toutes les tapes
de traitement peuvent aussi tre groupes dans un mme logiciel, comme par
exemple un systme multibase. Quand les tapes dextraction et dintgration sont
spares, les donnes ncessitent dtre stockes entre les deux. Ceci peut tre fait
en utilisant un mdia par source ou un mdia pour toutes les sources. Une vue
oprationnelle typique de ces composants est donne par la figure 9. Les
composants logiciels sont reprsents par des rectangles. Les ellipses dsignent
des stockages intermdiaires des rsultats de ltape dextraction/transformation.
Toutes les donnes qui sont en entre du composant intgration utilisent le mme
modle de reprsentation de donnes. Finalement, un wrapper est associ
chaque source, fournissant ainsi une interface API la source.
Wrapper
Source
Extraction/Transformation
DW
Source

Intgration/
Transformation/
Chargement

Extraction/Transformation

Figure 9 : Vue Oprationnelle des composants utiliss pour la construction dentrepts de donnes

Au second niveau, le processus de construction comporte trois tapes distinctes,

qui sont : (1) lextraction de donnes partir dune base de donnes (entrept de
donnes local ou global), (2) calcul des donnes drives pour lentrept de
donnes local cible, et (3) stockage des rsultats dans lentrept de donnes local.
Ltape dextraction est un cas particulier de celle du premier niveau parce que les
donnes de lentrept sont stockes dans une base de donnes. A loppos, dans le
premier niveau, lextraction peut concerner des sources de donnes arbitraires,
comme des fichiers par exemple. Le calcul des donnes drives est assez
spcifique car il peut impliquer des requtes complexes avec agrgats.

4. Vue conceptuelle multidimensionnelle des

donnes
Les tables dans les bases de donnes relationnelles contiennent des
enregistrements. Chaque enregistrement consiste en des champs (colonnes). Un
certain nombre de champs (cls) dans chaque enregistrement peut identifier de
faon unique chaque enregistrement. A loppos, le modle de donnes
multidimensionnel est un tableau n-dimensionnel (parfois appel hypercube). A
chaque dimension est associe une hirarchie de niveaux comme pays, rgion,

10

ville, bureau. Sur lexemple de la figure 6, les dimensions choisies sont Produit,
Rgion et Mois.
Rgion
N

Jus

10

Cola

13

Produit

Jan

Mois

Figure 6 : Les ventes comme une fonction de produit, temps, et gographie

Les mesures, qui sont aussi appeles variables ou mtriques comme ventes dans
lexemple, ou revenu, inventaire, etc. dans un tableau multidimensionnel
correspondent des colonnes dans une table de base de donnes relationnelle. Les
valeurs dans une colonne dune table correspondent des valeurs pour cette
mesure dans un tableau multidimensionnel : une mesure est un point dans lespace
multidimensionnel. Dans notre exemple, une mesure des ventes du produit Cola,
dans la rgion du nord, en janvier, est 13. Ainsi, une dimension agit comme un
index pour identifier des valeurs dans un tableau multidimensionnel.
Si un membre dune dimension est slectionn, alors les dimensions restantes
avec les membres slectionns, dfinissent un sous-cube. Si toutes les dimensions,
sauf deux, ont un membre unique slectionn, les deux dimensions restantes
dfinissent une page (ou slice ou spreadsheet). Si toutes les dimensions ont un
membre unique slectionn, alors une cellule est dfinie. Les dimensions offrent
une faon concise et intuitive pour organiser et slectionner les donnes pour
linterrogation, lexploration et lanalyse.
Des exemples de niveaux de dimensions pour lagrgation de donnes dans un
entrept de donnes sont : temporelle (annes vs. mois), gographique/spatiale
(e.g., Lyon vs. France), organisationnelle (Institut vs. Dpartement), et physiques
(voiture vs. moteur). La figure 7 donne quelques hirarchies typiques.

11

Non-alimentaire
Industrie

Catgorie

Produit
Alimentaire

Pays

Rgion

Vil e

Bureau
Mois

Anne

Trimestre

Jour
Semaine

Figure 7 : Exemples de hirarchies de dimensions

Une valeur dans une cellule peut reprsenter une mesure agrge calcule partir
de donnes spcifiques un niveau donn infrieur de la mme dimension. Par
exemple, la valeur 13 pour les ventes de janvier, peut avoir t obtenue en faisant
la somme des valeurs des ventes hebdomadaires (ou quotidiennes).

4.1 Oprations impliquant les dimensions

La navigation est un terme utilis pour dcrire le processus employ par les
utilisateurs pour explorer un cube de faon interactive, habituellement en utilisant
un client OLAP graphique connect un serveur OLAP. Le processus utilisateur
interactif pour une requte multidimensionnelle est appel slicing et
dicing . Le rsultat dune requte multidimensionnelle est soit une cellule, un
slice bi-dimensionnel, ou un sous-cube multidimensionnel. Les oprations sur
les donnes multidimensionnelles les plus frquentes dans les systmes
commercialiss sont :
Agrgation (ou consolidation, ou Roll-up) : lagrgation concerne le calcul des
relations pour une ou plusieurs dimensions. Par exemple, les centres de ventes
peuvent tre agrgs en zones et les zones en rgions; lutilisateur peut tre
intress par le total des ventes, par des pourcentages du total, etc.
Roll down (ou Drill down, ou Drill through) : lutilisateur navigue travers les
niveaux de donnes allant du plus haut niveau de consolidation au plus bas niveau
de consolidation (ou donnes dtailles).
Screening (ou slection, ou filtrage) : un critre est valu sur les donnes ou les
membres dune dimension dans le but de restreindre lensemble des donnes
retrouves. Comme exemples de slection, on peut sintresser aux dix meilleurs

12

vendeurs par chiffre daffaire, aux donnes de la rgion Est uniquement et tous
les produits avec une marge suprieure 20 pourcent.
Slicing : slectionner toutes les donnes satisfaisant une condition au regard dune
dimension particulire. Un slice est un sous ensemble dun tableau
multidimensionnel correspondant une valeur individuelle pour un ou plusieurs
membres des dimensions qui ne sont pas dans le sous ensemble.
Scoping : restriction de la vue des objets dune base de donnes un sous
ensemble spcifique. Dautres oprations, comme la mise jour ou la recherche,
affecteront seulement les cellules du sous ensemble spcifi. Par exemple, cette
opration permet aux utilisateurs de retrouver ou de mettre jour uniquement les
valeurs des ventes pour le premier trimestre dans la rgion Est (si ce sont les
seules donnes quils souhaitent recevoir).
Pivot (ou Rotate) : pour changer lorientation (par rapport aux dimensions) dun
cube, pour analyser les donnes en utilisant un niveau de dimension particulier
comme variable indpendante. Par exemple, la rotation peut consister
interchanger les lignes et les colonnes.

4.2 Modles de donnes

Etant donne la popularit des systmes de gestion de bases de donnes
relationnelles, on est tent de construire un outil OLAP comme un niveau
smantique au dessus dun SGBD relationnel [Coll96]. Ceci sappelle le OLAP
Relationnel (ROLAP ). Cest juste une extension du modle relationnel dans
lequel les oprations sur les donnes multidimensionnelles sont traduites en
oprations relationnelles standards. Ce niveau fournit une vue
multidimensionnelle, le calcul de donnes consolides, les oprations de drill
down, et la gnration dordres SQL appropris pour accder aux donnes.
Une autre approche est lOLAP Multidimensionnel (MOLAP). Cest un modle
de donnes ddi dans lequel les donnes multidimensionnelles et les oprations
sont mises en correspondance directement.
4.2.1 Le Modle de donnes ROLAP
Un outil bas sur ROLAP possde un gnrateur SQL puissant, capable de crer
des select multi-passes et/ou des sous-requtes corrles; il est suffisamment
puissant pour crer des classements non triviaux et des comparaisons; il gnre
des ordres SQL optimiss pour la base de donnes cible, comprenant des
extensions SQL, en utilisant, par exemple, les ordres Group By, sous-requtes
corrles, Having, Create View et Union. Il fournit un mcanisme pour dcrire le
modle travers les mta-donnes, et utilise les mta-donnes en temps rel pour
construire des requtes.

13

Au centre de la technologie ROLAP se trouve la modlisation des dimensions. Il

sagit dorganiser linformation en deux types de structures de donnes : mesures,
ou donnes numriques (par exemple les ventes), qui sont stockes dans des tables
dites tables des faits; et des dimensions, qui sont stockes dans des tables satellites
et sont relies la table des faits. Les systmes ROLAP doivent fournir des
techniques capables de supporter et doptimiser les trois fonctions suivantes :
Dnormalisation : une conception de base de donnes qui consiste stocker les
donnes dans des tables, minimisant le nombre de jointures (consommatrices de
temps quand une requte est excute), et rduisant le nombre denregistrements
qui doivent tre analyss;
Consolidation : une technique pour agrger les informations par avance, vitant
ainsi de le faire lexcution;
Partitionnement : la possibilit de dcomposer une table de faits volumineuse en
plusieurs petites tables, amliorant ainsi le temps de rponse aux requtes et aussi
aux restorations et rechargement de lentrept de donnes.
Les Data marts sont des collections, probablement sous forme de vues
matrialises drives dun entrept de donnes, o les agrgations et les
partitions sont implantes selon les besoins des utilisateurs cibles, de telle sorte
que les requtes puissent tre mieux optimises.
Un argument lencontre du modle ROLAP porte sur les faibles performances
rsultant dun grand nombre de jointures [Fink96]. Cest la raison pour laquelle
les Data Marts sont introduits dans ROLAP comme des bases de donnes
spciales dnormalises. Les tables dnormalises sont des tables qui sont prjointes (i.e., toutes les tables sont combines en une seule table), pour viter les
jointures consommatrices de temps. Malheureusement, cette solution prsente
plusieurs inconvnients lis la performance et aux ressources systme. La
dnormalisation produit des tables volumineuses car les donnes sont
redondantes. Les requtes danalyse en-ligne sadressent ainsi des bases de
donnes volumineuses conduisant des calculs aussi coteux, sinon plus, que les
jointures. De plus, la dnormalisation gnre des valeurs manquantes dans la base
de donnes.
Une approche intressante qui permet de remdier ces problmes dutilisabilit
dans le modle relationnel consiste stocker les donnes dans une structure en
toile (star), qui tente doffrir une structure multidimensionnelle au dessus du
modle relationnel bi-dimensionnel. Le modle en toile simplifie le modle
logique en organisant les donnes plus efficacement pour le traitement analytique.
4.2.2 Le modle de donnes MOLAP
14

Plutt que de stocker les informations comme des enregistrements, et les

enregistrements dans des tables, les bases de donnes multidimensionnelles
(BDM) bases sur MOLAP stockent les donnes dans des tableaux. Les BDMs
sont capables de fournir des performances remarquables quant au traitement des
requtes, qui sont obtenues en anticipant la manire avec laquelle les donnes
seront accdes. Parce que linformation, dans une BDM, est stocke avec une
granularit plus coersive que les bases de donnes relationnelles classiques,
lindex est plus petit et trs souvent rside en mmoire. Une fois lindex parcouru,
peu de pages sont considres. Certains outils sont conus pour placer ces pages
dans des mmoires partages, amliorant ainsi la performance. Un autre aspect
intressant des BDMs est que linformation est physiquement stocke dans des
tableaux : Ceci veut dire que les valeurs dans le tableau peuvent tre mises jour
sans modifier lindex. Un inconvnient de cette architecture est que mme des
changements mineurs affectant la structure des dimensions ncessitent une
rorganisation complte de la base de donnes.
Un avantage du MOLAP par rapport au ROLAP est quil permet des oprations
OLAP ddies. Avec un serveur BDM, il est facile de pivoter linformation
(puisque toute l'information est stocke dans un hypercube multidimensionnel), de
raliser des drill down sur les donnes, et deffectuer des calculs complexes
impliquant des cellules de structure multidimensionnelle. Il nest pas ncessaire
davoir recours des jointure complexes, des sous-requtes, et des unions. Ces
aspects nexistent pas car les donnes sont stockes comme des blocs
multidimensionnels au lieu dune structure de table dissque.

5. Interrogation des entrepts de donnes

Un entrept de donnes peut tre vu comme une collection de vues matrialises
rsultant de linterrogation de sources de donnes. En gnral, les entrepts de
donnes sont structurs de faon hirarchique : il y a diffrents niveaux de vues,
o les vues dun niveau donn sont drives de celles des niveaux au-dessous. Les
vues dans un entrept de donnes partagent des caractristiques avec les requtes
utilisateur, et donc les calculer pose des problmes similaires. Pour cette raison,
nous discuterons les traitements de requtes dans une perspective la plus gnrale
possible, couvrant toutes les parties dune architecture dentrept de donnes.
Un entrept de donnes ne contient pas uniquement des donnes dcrivant une
entreprise ou autre organisation, mais aussi des donnes auxiliaires, appeles
mta-donnes dcrivant la structure interne et les oprations de lentrept de
donnes. Explorer et interroger les mta-donnes est une activit importante pour
chaque utilisateur final, qui doit connatre quels sont les niveaux dinformation
disponibles avant dinterroger les donnes. De plus, les mta-donnes sont
importantes pour les administrateurs pour grer lentrept. Finalement, les

15

oprations du systme lui-mme sont spcifies et contrles travers les mtadonnes.

Cependant, contrairement aux donnes de bases, il ny a pas de standards quant
la reprsentation des mta-informations. En particulier, il ny a pas de consensus
sur le format et le contenu des requtes portant sur les mta-donnes. De ce fait,
nous nous restreignons ici des requtes portant sur le niveau donnes.
Dans la suite, nous supposons une architecture simplifie dentrept de donnes,
qui consiste en un noyau, un front end et un back end.
Requtes au niveau Back End : le back end connecte lentrept de donnes aux
sources de donnes oprationnelles. Le back end accde aux sources,
habituellement des intervalles de temps rguliers, pour charger les donnes dans
lentrept. Le chargement implique le nettoyage des donnes. Dans le cas le
plus simple, le nettoyage nest rien dautre que lassociation de codes crypts
apparaissant dans les sources des chanes plus lisibles. Cependant, des
techniques plus labores peuvent entraner des accs des bases de donnes qui
contiennent des informations supplmentaires ncessaires la rsolution des
ambiguts dans les sources. Le chargement peut galement entraner le calcul
dagrgats des donnes sources, comme la somme (sums), ou des agrgats plus ou
moins complexes.
Requtes au niveau Front End : le front end contient les outils avec lesquels les
utilisateurs finaux accdent aux donnes de lentrept. Il existe une multitude de
moyens mis la disposition des utilisateurs pour retrouver linformation : les
gestionnaires qui gnralement se contentent dun bref coup dil sur une
interface graphique, les assistants qui inspectent la dernire version dun rapport
complexe, les analystes qui interroge un cube de donnes avec un outil de
spcification de requtes ad-hoc, les personnels systmes qui construisent de telles
interfaces et dfinissent la perspective sous laquelle lentrept de donnes peut
tre peru travers les outils dinterrogation.
Requtes au niveau noyau : le noyau consiste en un gestionnaire dobjets et de
mta-donnes. Dans les systmes OLTP, les schmas sont conus de telle sorte
quil y ait un minimum de redondance. A loppos, les entrepts de donnes, sont
conus de faon prsenter une certaine redondance : certaines donnes sont des
vues sur dautres donnes, et donc redondantes dun point de vue logique. La
redondance peut tre inhrente larchitecture globale. Elle peut tre aussi locale
un composant o des rsultats pr-calculs sont stocks pour amliorer le temps
de rponse de certaines requtes supposes frquentes.

5.1 Transactionnel vs. requtes sur un entrept de

donnes
16

Les requtes sur un entrept de donnes se distinguent des requtes dans les
systmes OLTP par leur frquence et les volumes de donnes sur lesquels elles
portent. Les requtes OLTP sont des parties de transactions. Elles concernent
uniquement un petit nombre de tuples, mais apparaissent frquemment : e.g., 50
transactions par seconde sont possibles dans une base de donnes dune
compagnie arienne. Au contraire, les requtes dans un entrept de donnes tous
les niveaux peuvent concerner des gigabytes de donnes, mais avec une moindre
frquence.
Cest une caractristique, de presque toutes les requtes dans les entrepts de
donnes, de porter sur des ensembles volumineux de donnes. Cependant, ceci ne
veut pas dire quelles produisent galement des sorties volumineuses. Les
rsultats volumineux sont typiques des requtes qui correspondent au processus de
chargement. Dans une telle optique, de telles requtes sont excutes en batch sur
une base de donnes transactionnelle.
Les utilisateurs, au contraire, ne sont pas intresss par des sorties gigantesques.
Ils veulent rduire de gros volumes un petit nombre de paramtres
caractristiques, pour lesquels ils ont besoin dagrgation.
Requtes pr-formules et requtes ad-hoc : dans un entrept de donnes, nous
distinguons deux modes dinterrogation : (1) les requtes pr-formules ont t
spcifies par ladministrateur et excutes par un utilisateur final. Elles peuvent
tre sujettes une certaine paramtrisation, mais elles sont principalement fixes.
Typiquement, toutes les requtes excutes au niveau back end et au niveau du
noyau entrent dans cette catgorie. Les interfaces graphiques fournissant une vue
grable dune organisation et les rapports sont bases sur les requtes prformules ; (2) lanalyste interroge un entrept de donnes dans un mode ad-hoc.
Dans une session danalyse, il formule une srie de requtes corrles. Par
exemple, afin de connatre comment un vnement particulier influence la
performance de la compagnie entire, il formulera des requtes avec des niveaux
de gnralisation qui concerneront de plus en plus de donnes.

5.2 Requtes multidimensionnelles

Parmi les requtes multidimensionnelles, on peut distinguer celles qui retrouvent
des donnes partir des dimensions, et celles qui retrouvent des faits [Kim96].
Interroger les dimensions : avant dinterroger les informations factuelles dun
data cube, un analyste explorera en premier les dimensions du cube. Il utilisera un
outil dinterrogation pour prendre connaissance dune ou de plusieurs valeurs des
attributs dune dimension, probablement en restreignant les autres attributs. Par
exemple, il peut interroger la dimension produit pour connatre les valeurs de
lattribut marque quand lattribut catgorie est restreint produit_laitier. Si le data
17

cube est implant sur une base de donnes relationnelle selon le modle en toile,
alors une telle requte entranera juste des projections et des slections. Sil est
implant comme un flocon, alors la requte entranera la jointure des tables de la
dimension en question.
Bien que les tables des dimensions sont plus petites que les tables des faits, elles
peuvent savrer volumineuses dans certains cas. La dimension client dans un
entrept de donnes dune compagnie tlphonique peut contenir plusieurs
millions de tuples. De ce fait, les requtes dexploration, bien que simples dun
point de vue structurel, requirent des optimisations pour pouvoir les excuter
efficacement.
Le but de lexploration est didentifier des sous-ensembles intressants dune
dimension, appels des groupes contraints car ils satisfont certaines contraintes
sur la dimension, et les dcrire par des requtes. Avec un outil dinterrogation on
peut nommer de telles requtes et les stocker. Dans un environnement coopratif,
les groupes contraints peuvent tre rendus accessibles par les utilisateurs. Dans ce
cas, il y a ncessit dorganiser de nombreuses requtes et de spcifier leur sens.
Des outils offrent cette possibilit en permettant, par exemple, dattacher des
commentaires aux requtes, mais noffrent aucune possibilit de raisonnement.
Dautres sous ensembles dune dimensions, appels groupes comportementaux ne
se dfinissent pas uniquement en termes des attributs dune dimension, mais
impliquent galement des faits et des restrictions sur dautres dimensions. Un
exemple serait le groupe des produits qui se vendent trs bien durant les quatre
semaines prcdant Nol. Ce groupe est dfini non seulement en terme de la
dimension produit mais aussi en termes des ventes et du temps. Comme pour les
groupes contraints, il y a aussi ncessit de grer des requtes dfinissant des
groupes comportementaux.
Interroger les informations factuelles : lobjectif principal dans linterrogation
des cubes de donnes est de produire des rapports. Un rapport est une table dont
les dimensions sont tiquetes avec des valeurs dattributs et dont les faits sont
calculs en agrgeant des faits du cube impliqu. Souvent les faits ne sont pas de
simples agrgats comme count et sum, mais sont des comparaisons entre
diffrents agrgats. De plus, un rapport peut contenir dautres agrgats comme des
sous-totaux et des totaux, et des valeurs exceptionnelles peuvent tre mises en
vidence.
Pour calculer un rapport, il existe deux possibilits : La premire est de traduire la
spcification du rapport dans SQL. Ceci pose des problmes quand des
comparaisons sont considrer. Comparer les ventes du mois courant avec celles
du mois prcdent ncessite daccder la table des faits au moins deux fois.
Dans SQL, ceci peut tre accompli soit avec un self-join, ou avec des sous
requtes corrles comme dans SQL-2. Cependant, les deux options conduisent
18

un code difficile lire et pour lequel les optimiseurs de requtes tendent

produire des plans dexcution inefficaces. La deuxime possibilit est de
dcomposer la spcification du rapport en un nombre de requtes SQL
relativement simples, une pour chaque comparaison, et laisser loutil
dinterrogation assembler les rsultats dans le rapport. Cette stratgie vhicule
plusieurs avantages. Comme les requtes ne sont pas trop complexes,
essentiellement des requtes select-project-join avec lagrgation, elles peuvent
tre excutes efficacement par des SGBDs. De plus, une dition incrmentale du
rapport est possible, puisque aprs une modification, seules les requtes qui sont
affectes par la modification sont recalcules.
Les rapports peuvent galement tre spcifis et calculs par des serveurs OLAP
ddis. Les serveurs OLAP sont spcialiss dans le stockage de cubes de donnes
et supportent les requtes multidimensionnelles sur ces cubes. Ils contiennent non
seulement les cubes de bases, mais aussi des agrgats pr-calculs pour les
attributs des dimensions. Ainsi, ils garantissent des temps de rponse raisonnables
pour des requtes qui ncessitent lagrgation. Cependant, et souvent, ils
manquent de flexibilit pour la formulation de requtes plus labores.
Extensions de SQL : Kimball souligne les limites de SQL quand les requtes
daide la dcision sont spcifier [Kim96]. De telles requtes requirent des
agrgations plus sophistiques que ceux disponibles dans SQL, e.g., rank, n-tile,
moving-avg, ou moving-sum. De plus, pour les requtes danalyse, les
comparaisons sont essentielles. Si elles sont exprimes en SQL ou si un code SQL
est produit par un outil dinterrogation, elles sont excutes par des passes
squentielles multiples. Ceci peut tre vit si SQL est tendu par une syntaxe
spciale pour les comparaisons, qui peuvent tre values plus efficacement
[CR96].
Pour la spcification des groupes de requtes agrgats, les oprateurs rollup et
cube ont t introduits comme des extensions SQL dans [GBLP97]. Chaque
oprateur a comme argument une relation et une liste dattributs. Il spcifie un
ensemble de requtes relies entre elles et qui calculent des agrgats travers des
groupements.
Loprateur rollup agrge travers des groupements o chaque groupement est
plus compact que ses prdcesseurs. Par exemple, rollup pour la liste des attributs
anne, magasin, et prix produit dabord une agrgation travers le groupement
par tous les attributs, ensuite par anne et magasin, et finalement par anne
uniquement. Une requte rollup peut tre calcule efficacement en drivant le
rsultat pour un groupement partir du rsultat pour son prdcesseur.
Loprateur cube ralise des groupements par chaque sous ensemble dattributs de
la liste. Ainsi, sil y a n attributs, cube spcifie des groupements. Les groupements
forment un treillis boolen qui dcrit ce qui peut tre calcul et partir de quoi.
19

Contrairement rollup, il nest pas facile de dterminer la stratgie la plus

efficace pour calculer les agrgats. Agarwal et al. rapportent des analyses
empiriques sur les diffrentes stratgies de calcul de requtes avec loprateur
cube [AAD+96].

6. OLAP et bases de donnes statistiques

Les deux domaines traitement analytique en-ligne (OLAP) et bases de donnes
statistiques (BDS) traitent densembles de donnes multidimensionnelles, et ces
deux domaines sintressent la production de rsums statistiques moyennant les
dimensions des ensembles de donnes.

6.1 Exemples de bases de donnes statistiques et de bases

de donnes OLAP
6.1.1 Reprsentation de donnes dans les BDS
Considrons les donnes reprsentes sur la figure 10 comme une table 2-D. Cette
figure montre la rpartition, selon les types de baccalaurats, des succs cet
examen dans la rgion lyonnaise (les nombres sont fictifs). La rpartition est faite
par sexe, par anne et par spcialit. Cette forme de reprsentation de tables
multidimensionnelles est trs populaire dans le domaine des statistiques. Plusieurs
remarques simposent :
1.

Par ncessit, plus dune dimension doit tre reprsente par les lignes et les
colonnes si plus de deux dimensions existent dans lensemble de donnes. Ceci
est ralis en slectionnant un ordre arbitraire pour les dimensions dans les lignes
et les colonnes. Sur la figure 10, les lignes reprsentent les deux dimensions
sexe et anne , qui sont ordonnes (sexe puis anne) de faon arbitraire.
2.
Les colonnes dans cet exemple ne reprsentent pas deux dimensions, bien que
leur forme ressemble aux lignes. Type Bac et Spcialit reprsentent une
relation hirarchique entre les instances de Type Bac (e.g., Gnral) et les
instances de Spcialit (e.g., Sciences ). On se rfre cette structure par
hirarchie de classification .
3.
Le label Baccalaurat Lyon reprsente la mesure rsume pour cet
ensemble de donnes, mais il dit aussi que cet ensemble de donnes admet une
dimension supplmentaire ville o linstance slectionne est le singleton
Lyon .
4.
Il y a une fonction dagrgation implique par cet ensemble de donnes pour
deventuels rsums ( travers Sexe ou Spcialit ). Dans ce cas la fonction
dagrgat est sum . Notons qualors que sexe et anne est un seul
niveau dagrgation, lagrgation travers Spcialit peut tre ralise au
niveau Type Bac ou au niveau de toutes les spcialits et tous les types de
baccalaurats. Ceci grce la structure hirarchique de classification.
20

Pour rsumer, cet ensemble de donnes admet la structure conceptuelle suivante :

Mesure de rsum : Baccalaurat
Fonction de rsum : Sum
Dimensions : Sexe, Anne, Spcialit, ville=Lyon
Hirarchie de classification : Type Bac Spcialit
Type Bac
professionnel

Gnral

Baccalaurat Lyon
Sciences
Masculin
Anne

Spcialit

Spcialit

Littrature

Mcanique

Electrotechnique

99

25000

14000

10000

6000

98
...

23000

15000

11000

7000

Sexe

Fminin

99
98
...

Figure 10 : Reprsentation de donnes statistiques en 2-D

6.1.2 Un exemple OLAP utilisant le modle data cube

Sur la figure 11 nous montrons un exemple typique dune base de donnes,
reprsente comme un cube multidimensionnel. Evidemment, cette reprsentation
graphique peut tre utilise seulement pour un nombre de dimensions infrieur ou
gal 3. Mais elle est utile pour des besoins dillustration. Cet exemple de data
cube contient la quantit vendue pour une chane de magasins particulire, par
produit, par magasin et par jour. Nous notons :
1. La dimension emplacement magasin admet une hirarchie naturelle.
emplacement magasin a deux composantes : ville et numro
magasin . Puisque les magasins sont organiss selon la ville o ils sont
implants, la hirarchie ville magasin existe. Si les numros de magasins
ne sont pas globalement uniques, alors on a besoin de concatener ville et
numro de magasin pour la rendre unique. Au regard de la terminologie des
modles ER, on peut dire quil existe une ID dpendance entre magasins
et la ville.
2. La dimension jour est un autre exemple de hirarchie de classification.
Etant donn que jour est identifi par son mois et son anne (e.g., 17
novembre 1999), alors il est ID dpendant de mois (novembre, 1999) qui
son tour est dpendant de lanne (1999). Ainsi, il peut tre trait comme une
21

hirarchie de classification 3 niveaux pour les besoins de consolidation aux

niveaux mois et anne.
3. La mesure quantit vendue .
Pour rsumer, pour cette base de donnes OLAP, nous avons la structure
conceptuelle suivante :
Mesure de rsum : quantit vendue
Fonction de mesure : Sum
Dimensions : produit, emplacement magasin, jour
Hirarchie de classification : ville magasin
Hirarchie de classification : anne mois jour
Comme on peut le constater, dun point de vue structure conceptuelle, les
exemples de BDS et OLAP ont exactement les mmes composants : une mesure,
une fonction, une ou plusieurs dimensions, zro ou plusieurs hirarchies de
classification. Il est vident que lexemple OLAP peut tre reprsent moyennant
la reprsentation 2-D des BDS, et lexemple de BDS sous forme dun cube de
donnes.
Il est facile dtendre ce modle pour avoir plusieurs mesures associes au mme
ensemble de donnes travers les mmes dimensions (comme par exemple
population et revenu moyen par dpartement, par anne, par sexe, et par race ).
Dans la littrature BDS, on appelle ceci objet statistique complexe .

6.2 Domaines dapplications

Le domaine des BDS est essentiellement motiv par des bases de donnes socioconomiques, qui sont essentiellement le domaine des statisticiens. Comme
exemples de domaines dapplications, nous pouvons citer les donnes de
recensement, les donnes conomiques (ventes et revenus des entreprises),
ressources naturelles (niveaux deau dans les barrages, exploitation du bois dans
les forets, etc.). Le domaine des OLAP est, quant lui, dirig par des applications
de commerce, et leur analyse pour un besoin daide la dcision. Des exemples
dapplications sont lanalyse des ventes au dtail dans les magasins, gestion de
stock, etc. Cest la raison pour laquelle OLAP est considr comme un composant
des possibilits des entrepts de donnes. Lobjectif principal dun entrept de
donnes est de collecter et danalyser linformation pour prendre des dcisions.
Les dcideurs ne sont pas ncessairement des statisticiens, mais
plutt des gestionnaires commerciaux.

22

Temps = anne, mois, jour

Quantit vendue

Lyon, m#1
17 Nov. 1999

500

Produit

Cola
emplacement magasin : ville, # magasin

Figure 11 : Une reprsentation data cube de donnes OLAP

De ces exemples, il apparat que les BDS et les bases de donnes OLAP traitent de
problmes similaires. Cependant, chaque domaine a mis laccent sur des aspects
diffrents. La littrature BDS sest focalise sur le traitement des structures de
classification multi-niveaux complexes, alors que la littrature OLAP suppose des
structures simples et lgantes. Certaines BDS se sont fortement focalises sur les
dimensions rgion, spatiale et gographique, alors que dans certaines bases de
donnes OLAP, laccent est mis sur les dimensions temporelles. Une autre
diffrence est que la littrature OLAP traite de lefficacit des accs des
gygabytes de donnes (pour satisfaire le caractre en-ligne des OLAP), alors
que la littrature BDS sest concentre sur dautres aspects, comme la
modlisation conceptuelle.

6.3 Modlisation conceptuelle reprsentation des

structures de donnes
Nous dcrivons dans ce qui suit 3 modles utiliss pour les BDS et les OLAP,
savoir : (1) les modles base de graphes, (2) les modles tabulaires, et (3) le
modle data cube.
6.3.1 Modles base de graphes
Le modle graphique, exhib par la figure 12 pour la table 2-D de la figure 10
montre les lments du modle graphique. Il y a 3 types de noeuds : les S-noeuds
pour les attributs rsums, les X-noeuds pour le produit crois reprsentant la
multidimensionnalit, et le C-noeud pour reprsenter lattribut catgorie (qui
23

correspond la classification). Notons quun C-noeud au dessus dune collection

dautres C-noeuds reprsente un niveau de la structure de classification
hirarchique, et ainsi appel hirarchie catgorie.

Anne

Type Bac
Sexe

...

99
98

Gnral

M
F
Sciences

Professionnel
C

Littrature

Mcanique

Electrotechnique

Figure 12 : Un modle graphique pour les donnes statistiques

Cette reprsentation comporte plusieurs avantages compare la reprsentation

tabulaire 2-D : (1) les dimensions nont pas tre partitionnes en celles qui vont
dans les colonnes et celles qui vont dans les lignes, (2) cette reprsentation est
insensible la permutation des noeuds, (3) la hirarchie de classification est
explicite, et donc un attribut catgorie de niveau suprieur (comme Type Bac)
ne peut pas tre confondu avec une dimension de lensemble de donnes
statistiques, et (4) il est possible de reprsenter convenablement un nombre
raisonnable de dimensions sur un seul cran.
Nanmoins, Cette reprsentation possde certains problmes dans les applications
relles quand il est question de reprsenter des ensembles de donnes complexes.
Un des problmes est que dans le cas o le nombre de valeurs dun attribut
catgorie est important (e.g., 50 villes), il devient difficile de les reprsenter
convenablement lcran. Un autre problme, plus important, est que les noeuds
intermdiaires dune hirarchie de catgories ont deux rles : (1) reprsenter la
valeur de la catgorie du noeud au dessus, (2) reprsenter le nom de lattribut
catgorie pour les noeuds au dessous.
6.3.2 Modle tabulaire
La figure 13 montre la mme table 2-D que celle de la figure 10 mais nous
insrons deux colonnes qui donnent un rcapitulatif sur les lignes. Comme on peut
le voir, une colonne total est associe au type de baccalaurat
professionnel . Des colonnes similaires pour les autres types de baccalaurats

24

existent. Les inconvnients de cette reprsentation tabulaire rejoignent ceux des

modles base de graphes.
Une autre reprsentation tabulaire dcoule de la popularit du modle relationnel.
Lavantage de cette reprsentation est sa familiarit et le fait quelle peut tre
raisonnablement implante sur un schma relationnel, et galement la flexibilit
de lintgrer avec dautres donnes dans le mme modle. Cependant, il y a
plusieurs problmes avec cette reprsentation, comme : (1) il ny a pas de
smantique associe une table relationnelle pour distinguer entre catgorie et
attribut rsum, (2) il ny a pas de distinction entre les attributs associs la
hirarchie de classification et les dimensions.
Une reprsentation relationnelle qui rsoud partiellement ces problmes et
dautres est utilise par une compagnie OLAP [MicroStrategy], en utilisant le
modle en toile ( star model ).
Type Bac
Baccalaurat Lyon
Sciences
Masculin
Anne
Sexe

Gnral
Spcialit

Littrature

professionnel
Spcialit
Mcanique

Total
Electrot.

Total
16000

99

25000

14000

10000

6000

98
...

23000

15000

11000

7000

55000

99
98
...

Fminin

Figure 13 : Table statistique avec des marges

6.3.3 Modle data cube

Un exemple de modle data cube tait donn figure 10. Cette reprsentation
graphique est utilise dans les papiers OLAP (e.g., [GB+96]) et les produits
OLAP multidimensionnels (e.g., [Arborsoft]).
Alors que lespace multidimensionnel est clairement reprsent dans ce modle
data cube, la structure des dimensions nest pas bien prsente. Ce nest qu
travers des labels comme lyce, ville, dpartement, etc. associs aux dimensions
que lon peut supposer que la dimension a une structure et des donnes.
Mis part ces insuffisances, ce concept de data cube est utile dans la visualisation
de certaines oprations, comme le slice et le dice. La table de la figure 14 donne la
correspondance entre les termes utiliss dans les domaine de BDS et OLAP.

25

BD Statistiques

OLAP

Attribut de catgorie
Hirarchie de catgorie
Valeur de catgorie
Attribut synthse
Objet statistique
Produit crois
Table rsum

Dimension
Hirarchie de dimension
Valeur de dimension
Mesure
Data cube
Multidimensionnalit
Table/data cube

Figure 14 : correspondance entre les termes dans les BDS et OLAP

6.4 Oprations
6.4.1 Oprateurs statistiques
Dans la littrature BDS, il existe plusieurs approches pour dfinir les oprateurs
qui refltent le modle structurel de lobjet statistique. Une approche consiste
utiliser le cadre relationnel, mais enrichir le modle structurel avec une
smantique relative aux proprits de lobjet statistique, particulirement : la
multidimensionnalit et la hirarchie de classification. Dans [MRS92] des
oprateurs qui correspondent aux oprateurs de lalgbre relationnelle select ,
project , union , et aggregate taient dfinis. Ils taient nomms Sselect , S-project , etc.
6.4.2 Oprateurs OLAP
Les oprateurs dfinis dans le domaine OLAP utilisent limage graphique du data
cube. Ainsi, un slice est une coupe travers lespace multidimensionnel, un dice
est la slection sur certaines valeurs des dimensions, roll-up (appel aussi
consolidation) est le rsum au dessus dun niveau de la hirarchie de
classification, et drill-down est lopration oppose.
La table de la figure 15 rsume la correspondance entre les oprateurs des BDS et
ceux des OLAP.
BD Statistiques

OLAP

S-projection
S-selection
S-aggregation
S-desagregation
S-union

Slice
Dice
Rool-up
Drill-down
---

Figure 15 : Correspondance entre les oprateurs des BDS et ceux des OLAP

26

Bibliographie
[AAD+96] S. Agrawal, R. Agrawal, P. Deshpande, A. Gupta, J. Naughton, R.
Ramakrishnan et S. Sarawagi. On the computation of multidimensional
aggregates. In Proceedings of the 22nd Interational Conference on Very Large Data
Bases, Bombay (India), September 1996.
[Arbo96]
Arbor
Software
Corporation.
http://www.arborsoft.com/essbase.html, 1996.

Arbor

Essbase.

[Arborsoft] Relational OLAP : Expectations & Reality. An Arbor Software White

Paper, http://www.arborsoft.com/papers/rolapTOC.html.
[CD97] S. Chaudhuri and U. Dayal. An Overview of Data Warehousing and
OLAP Technology. SIGMOD Record, Vol. 26, No. 1, March 1997.
[Coll96] G. Colliat. OLAP, Relational, and Multidimensional Database Systems.
SIGMOD Record, Vol. 25, No. 3, Septembre 1996.
[CR96] D. Chatziantoniou and K. Ross. Querying multiple features in relational
databases. In Proceedings of the 22nd Interational Conference on Very Large Data
Bases, Bombay (India), September 1996.
[Fink96] Richard Finkelstein. Understanding the need for On-line analytical
servers. White paper from Arbor Software, Inc.
[GBLP97] J. gray, A. Bosworth, A. Leyman et H. Pirahesh. Data cube : A
relational operator generalizing group-by, cross-tabs, and sub-totals. Data
Mining and Knowledge Discovery Journal, 1(1), 1997.
[GB+96] Jim Gray, Adam Bosworth, Andrew Layman and Hamid Pirahesh. Data
Cube : A Relational Aggregation Operator Generalizing Group-By, Cross-Tab,
and Sub-Total. In Proceedings of the International Conference on Data
Engineering (ICDE96), 1996.
[Gree97]
L.
Greenfield.
Data
Warehousing
http://pwp.starnetinc.com/larryg/index.html.

Information

Center.

[Inmo96] W. H. Inmon. Building the Data Warehouse. John Wiley and Sons,
1996.
[Kena95] Kenan Technologies. An Introduction to Multidimensional Database
Technology. http://www.kenan.com/acumate/mddb_toc.htm, 1995.
27

[Kim96] Ralph Kimball. The data warehouse toolkit. John Wiley and Sons, 1996.
[MicroStrategy] The Case For Relational OLAP, A White Paper Prepared by
MicroStrategy, Incorporated. http://www.strategy.com/dwf/wp_b_a1.htm.
[MRS92] Leonardo Meo-Evoli, Fabrizio L. Ricci and Arie Shoshani. On the
Semantic Completeness of Macro Data Operators for Statistical Aggregation. In
Proceedings of the 6th International Conference on Statistical and Scientific
Database Management (SSDBM) 1992, pp. 239-258.
[Orac97]
Oracle
Corporation.
Oracle
Express
http://www.oracle.com :81/products/olap/html/oes.html, 1997.

Server.

[Sahi96] Kenan Sahin. Multidimensional Database Technology and Data

Warehousing. http://www.kenan.com/acumate/byln_mdw.htm, 1996.
[Weld97] Jay-Louise Weldon. Warehouse Cornerstones. Byte, pp. 85-88.

Autres rfrences :
Le site http://www.cs.toronto.edu/~mendel/dwbib.html
recense et donne accs tous les travaux raliss par des chercheurs
universitaires et dautres centres de recherche (IBM, Microsoft, AT&T, etc.)
acadmiques sur les entrepts de donnes et OLAP. On y trouve 132 articles.
Le site http://www.cio.com/research/data/
Est consacr des travaux portant sur la vulgarisation de ces nouvelles
technologies daide la dcision et leur croisement avec dautres technologies
comme le datamining, le commerce lctronique, Internet, etc.
Les sites http://www.intelligententerprise.com/
, http://www.datawarehousingonline.com/
, et http://www.dwinfocenter.org/ sont, quant eux, consacrs lutilisation
effective de ces technologies au sein des entreprises. On y trouve des dizaines et
des dizaines darticles.

28