Vous êtes sur la page 1sur 28

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.

S y s t m e s O L T P S chm a o p r a tio n n e l D onnes o p r a t io n n e lle s

DW S chm a du DW D onnes c o n s o lid e s

A p p lic a t i o n s O LA P S chm a u t ilis a t e u r D onnes d riv e s

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.
C lie n t s S IG O LAP SAD

D a ta m a rt

D a ta m a rt

A d m in is t r a t e u r M ta base

DW

W ra p p e rs /C h a rg e u rs

S o u rc e s

F ic h ie r s

BD

D onnes e x te rn e s

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.
Tem ps
C ode T em ps C o d e T rim e s tr e N o m T r im e s tr e C o d e M o is N o m M o is D a te

G o g ra p h ie
C o d e G o g ra p h ie C o d e R g io n R e s p o n s a b le R g io n C o d e E ta t C o d e V ille ...

V e n te s
C o d e G o g r a p h ie C ode T em ps C o d e C o m p te C o d e P r o d u it M o n ta n t e n F F U n it s

C o m p te
C o d e C o m p te ...

P r o d u it
C o d e P ro d u it N o m P r o d u it C o d e M a rq u e N o m M a rq u e C o d e L ig n e P r o d . N o m L ig n e P r o d .

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. ... ... ...
T r im e s tre
C o d e T rim e s t r e N o m T r im e s tr e

G o g r a p h ie Tem ps
C ode Tem ps C o d e T r im e s tr e C o d e M o is

... V e n te s
C o d e G o g r a p h ie C ode Tem ps C o d e C o m p te C o d e P ro d u it M o n ta n t e n F F U n it s

M o is
C o d e M o is N o m M o is

... ...

C o m p te
C o d e C o m p te

...

... ... ...


Figure 4 : Schma en flocon

P r o d u it . ..

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.
O u t il d 'u n t e r r o g a t io n a d 'h o c A p p li c a t io n O LAP

BDM D

DW

S o u rc e s

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.
S o u rc e E x t ra c tio n

T r a n s fo rm a tio n

In t g r a tio n

C h a rg e m e n t

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.
W ra p p e r S o u rc e E x t ra c tio n / T ra n s fo r m a t io n DW S o u rc e In t g ra tio n / T r a n s fo r m a t io n / C h a rg e m e n t

E x t r a c t io n /T r a n s fo rm a tio n

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.
R g io n
N Jus C o la S 10 13

P r o d u it

Jan

M o is

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

N o n - a lim e n t a ir e I n d u s tr ie C a t g o rie P r o d u it A lim e n ta ire

P ays

R g io n

V ille M o is

B u re a u

A nne

T rim e s tr e S e m a in e

Jour

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
T ype B ac B a c c a la u r a t L y o n S c ie n c e s M a s c u lin A nne S exe 99 98 ... 99 98 ... 25000 23000 G n ra l S p c ia lit L it t r a t u r e 14000 15000 p r o fe s s io n n e l S p c ia lit M c a n iq u e E le c t ro te c h n iq u e 10000 11000 6000 7000

F m i n in

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 : 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.
1.

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 hirarchie de classification 3 niveaux pour les besoins de consolidation aux niveaux mois et anne.
21

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

T e m p s = a n n e , m o is , jo u r

Q u a n t it v e n d u e

Lyon, m #1
500

17 N ov. 1999

P ro d u it

C o la e m p la c e m e n t m a g a s in : v ille , # m a g a s in

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.

A nne 99 98

C ...

T ype B ac S exe C G n ra l F S c ie n c e s C C P ro fe s s io n n e l C

L it t ra tu r e M c a n iq u e

E le c tr o t e c h n iq u e

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 ).
T ype B ac B a c c a la u r a t L y o n S c ie n c e s M a s c u lin A nne S exe 99 98 ... 25000 23000 G n ra l S p c ia lit L it t r a t u r e 14000 15000 p r o fe s s io n n e l S p c ia lit E le c t ro t . M c a n iq u e 10000 11000 6000 7000 T o ta l T o ta l 16000 55000

F m in in

99 98 ...

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
Attribut de catgorie Hirarchie de catgorie Valeur de catgorie Attribut synthse Objet statistique Produit crois Table rsum

OLAP
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
S-projection S-selection S-aggregation S-desagregation S-union

OLAP
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