Construction graphique dentrepts et de magasins de donnes

Frdric Bret, Olivier Teste

IRIT (Institut de Recherche en Informatique de Toulouse),
quipe SIG, Universit Toulouse III,
118, Route de Narbonne - 31062 Toulouse cedex 04, France
Email : {bret, teste}@irit.fr

Rsum :
De nos jours, les systmes dcisionnels sont devenus un thme de recherche important dans le
domaine des bases de donnes. Les entrepts de donnes ("data warehouses") et les magasins
de donnes ("data marts") constituent les lments principaux de ces systmes.
Cet article prsente notre architecture de systmes d'aide la dcision. Nous proposons des
interfaces graphiques qui aident l'administrateur du systme dcisionnel lors du processus de
construction de l'entrept et des magasins de donnes. Nous prsentons une interface de
construction de l'entrept de donnes base sur un modle conceptuel orient objet. Celui-ci
permet l'historisation des donnes de l'entrept trois niveaux : attribut, classe et
environnement. Nous prsentons galement une interface de construction des magasins de
donnes permettant de rorganiser les donnes de lentrept selon un modle orient objet
multidimensionnel.
Mots cls :
entrepts de donnes, magasins de donnes, historisation, multidimensionnel, interfaces
graphiques pour l'administrateur.

Abstract :
Nowadays, decisional systems have became a significant research topic in databases. Data
warehouses and data marts are the main elements of such systems.
This paper presents our decisional support system. We present graphical interfaces which help
the administrator to build data warehouses and data marts. We present a data warehouse
building interface based on an object-oriented conceptual model. This model allows the
warehouse data historisation at three levels: attribute, class and environment. Also, we present
a data mart building interface which allows warehouse data to be reorganised through a
multidimensional object-oriented model.
Keywords :
data warehouses, data marts, historisation, multidimensional, graphical interfaces for
administrator.

1 Introduction
Issus de lindustrie pour servir de base lanalyse des donnes, les entrepts de donnes
("data warehouses") sont devenus un thme de recherche part entire [WIDO95] [CHAU97]
[WU97]. Lobjectif de ces entrepts est de servir de support la prise de dcision en
permettant une meilleure exploitation des informations contenues dans les systmes
oprationnels des entreprises.
Un entrept est une collection de donnes intgres, orientes sujet, non volatiles, historises,
rsumes et disponibles pour linterrogation et lanalyse [INMO96]. Lentrept intgre les
donnes pertinentes - ncessaires la prise de dcision - des systmes oprationnels de
lentreprise. Cette intgration fait appel des processus d'unification de donnes htrognes,
d'agrgation et d'historisation.
Lentrept de donnes est gnralement destin aux dcideurs de lentreprise souvent non
spcialistes de linformatique. Lentrept doit tre muni dinterfaces graphiques adaptes
des utilisateurs non informaticiens
Le contexte applicatif de nos travaux concerne le milieu mdical (scurit sociale). En effet,
dans le cadre de lAssurance Maladie en France, les systmes oprationnels contiennent de
trs importants volumes de donnes relatifs aux assurs sociaux, aux professionnels de sant,
aux tablissements mdicaux. Ces donnes sont gres par les Centres de Traitements
Informatiques. Lexploitation de ces donnes par les experts de lAssurance Maladie, tels que
les mdecins conseils, s'effectue de manire parfois empirique par des moyens classiques
(vues, requtes SQL, outils graphiques dinterrogation,). Ce processus d'exploitation s'avre
souvent fastidieux et n'apporte pas toujours des rponses satisfaisantes. Les entrepts de
donnes peuvent apporter des solutions pour une meilleure exploitation de ces donnes.
L'objectif de cet article est de prsenter notre architecture des systmes dcisionnels en
distinguant les problmatiques lies la construction de tels systmes. En particulier, nous
prsentons deux interfaces graphiques ddies la construction d'entrepts et de magasins de
donnes.
Cet article est organis en quatre sections. Dans la section 2, nous prsentons des travaux de
recherche dans le domaine des entrepts de donnes et dans le domaine des langages
graphiques destins aux bases de donnes orientes objet. Dans la section 3, nous prsentons
notre architecture de systmes dcisionnels quatre niveaux. Dans la section 4, nous
proposons un outil graphique permettant la construction dentrepts de donnes
(correspondant la seconde phase de notre processus). Cet outil sappuie sur un modle
conceptuel orient objet permettant la gestion de donnes "historises". La section 5 propose
un outil graphique permettant la construction de magasins de donnes (correspondant la
troisime phase de notre processus). Cet outil est bas sur un modle conceptuel orient objet
multidimensionnel et sur une dmarche de construction.

Cette tude a t partiellement finance par le CTI-Sud (Centre de Traitement Informatique des
rgions Midi-Pyrnes et Languedoc-Roussillon) de lAssurance Maladie.

2 Travaux existants
Les entrepts de donnes sont issus originellement du monde industriel. Depuis quelques
annes, les travaux de recherche sur ce thme se sont multiplis. Par consquent, nous
prsentons dans cette section les principaux outils utiliss dans l'industrie, puis divers projets
et travaux de recherche sur les entrepts.

2.1 Outils de l'industrie

Les outils issus de l'industrie se concentrent essentiellement sur les aspects de l'interrogation.
Plusieurs requteurs (Business Objects, Impromptu, Discover2000) et outils OLAP
(Powerplay, Discover, Essbase, Express, Mercury) sont proposs. Les requteurs facilitent la
construction de requtes SQL (jointures masques, alias de noms d'attributs,). Les outils
OLAP se concentrent sur l'analyse multidimensionnelle en proposant des objets graphiques
(tableaux croiss,). Ces outils utilisent les donnes de l'entrept ou des magasins, mais ne
permettent pas leur construction.
Peu d'outils sont disponibles pour assister l'administrateur dans la construction des entrepts
et des magasins de donnes (Data Mart Builder, SAS/Warehouse Administrator, Warehouse
Manager). Avec ces outils, le schma de l'entrept ou du magasin doit tre construit au
pralable. L'administrateur a la charge d'associer chaque attribut cible de ce schma un
attribut d'une source de donnes. Cette phase reste complexe et demande une connaissance
importante des structures sources.
Notre approche se distingue en proposant de construire incrmentalement l'entrept ou le
magasin ; l'administrateur construit l'entrept en drivant les donnes sources utiles. Cette
construction se fait partir d'une reprsentation graphique des sources. Ainsi, l'administrateur
peut apprhender plus facilement la structure et la smantique des donnes sources.

2.2 Travaux de recherche

Le projet WHIPS [WIEN96] propose une architecture des systmes dcisionnels centre sur
lintgration des sources de donnes et la maintenance incrmentale de lentrept. L'objectif
du projet WHIPS est de proposer des algorithmes permettant la maintenance de vues
matrialises. [SAMO98] sintresse aux problmes lis lintgration des sources de donnes
en sinspirant de travaux effectus dans les BD fdres. Dans [JARK98] une architecture
DWQ (Data Warehouse Quality) trois niveaux (conceptuel, logique, physique) est propose.
Lobjectif est de dfinir des critres de qualit pour une meilleure organisation des mtadonnes de lentrept.
Initialement, le concept de vue [GARD93] a t dvelopp dans le domaine des bases de
donnes pour exprimer des contraintes de confidentialit sur les donnes. Dans les entrepts
de donnes, les vues sont matrialises [GUPT95]. Cette technique consiste calculer la vue
et stocker le rsultat dans l'entrept. De nombreux travaux tels que [ZHUG95] [BELL98]
[YANG98] proposent des algorithmes relatifs la maintenance incrmentale et la rduction
des cots de maintenance des vues matrialises. Tous ces travaux utilisent une dfinition
textuelle des vues (sous la forme SPJ : Slection - Projection - Jointure) et n'offrent pas une
solution base sur une interface graphique comme nous le proposons.
D'autres travaux de recherche concernent le processus OLAP. Ce processus consiste
organiser les donnes pour faciliter et optimiser leur analyse. Lors de lanalyse, les donnes
sont regroupes, rsumes, consolides et visualises selon diffrents niveaux de dtail. Les

travaux relatifs au processus OLAP se situent un niveau conceptuel [GOLF98], [GYSS97],

[LEHN98], logique [AGRA97], [GRAY96], [REDB95] et physique [COLL96], [ZHAO97].
Avec la gnralisation de l'informatique dans tous les domaines, les langages bass sur un
paradigme caractre visuel se dveloppent naturellement dans les diffrents systmes
informatiques. Puisque nos travaux s'effectuent dans un cadre orient objet, nous nous
limitons aux bases de donnes orientes objet en distinguant :
-

les langages tabulaires comme OOQBE [STAE91], VQL [VADA93],

les langages iconiques comme VISTA [BELI96],

les langages graphiques comme OHQL [ANDO91], VOHQL [ANDO97], EIGOO

[SAYA98].

Les langages graphiques prsentent lavantage de visualiser le schma de la base avec les
diffrents liens entre les classes, tandis que les langages tabulaires prsentent un apport visuel
limit et que les langages iconiques font mal apparatre les diffrents liens entre les classes.

3 Notre architecture
Nous proposons une architecture de systmes d'aide la dcision. Elle est base sur une
organisation quatre niveaux (cf. figure 1), chacun d'eux tant associ un modle de
donnes particulier. Par exemple, le modle de lentrept gre l'volution des donnes
(donnes historises) tandis que le modle des magasins organise les donnes de manire
multidimensionnelle pour optimiser lanalyse.
Nous utilisons un modle orient objet dont la smantique plus riche permet une meilleure
gestion des donnes structures complexes et multimdias.
Source 1
Magasins
de Donnes 1

Source 2
.
.
.
Source n
Modles
Htrognes

Figure 1.

Source Globale
Modle
Orient Objet

Entrept
de Donnes
Modle
Orient Objet
grant lHistorisation

.
.
.
Magasins
de Donnes m
Modle
Orient Objet
Multidimentionnel

Notre architecture de systmes d'aide la dcision.

Dans cet environnement, nous proposons un processus permettant la construction du systme

daide la dcision. Ce processus se dcompose en trois phases permettant disoler les
diffrents problmes rsoudre : une phase dintgration des sources de donnes, une phase
de construction de lentrept et une phase de rorganisation des donnes pour construire les
magasins.
La phase dintgration permet de gnrer une source de donnes globale obtenue partir de
lintgration des diffrentes sources htrognes et distribues. Cette phase doit permettre de
rsoudre les problmes lis lhtrognit et la distribution des sources. Elle fait appel
entre autre des techniques dfinies pour les bases de donnes fdres [SAMO98] et les bases
de donnes rparties [RAVA96].

La phase de construction de lentrept de donnes utilise le mcanisme des vues

matrialises. Nous utilisons le mcanisme des vues pour permettre ladministrateur
dindiquer simplement au systme quelles sont les donnes sources ncessaires la
construction de lentrept. Cette phase consiste dfinir une vue sur la source de donnes
globale au travers dune interface graphique qui assiste ladministrateur. Une opration
importante de cette phase consiste dterminer les donnes dont les volutions doivent tre
conserves dans lentrept. Le systme gnre ensuite lentrept de donnes comme une base
de donnes orientes objet contenant les donnes extraites de la source. Ladministrateur
dtermine une priode de rafrachissement pour maintenir l'entrept de donnes consistant
avec les sources.
La phase de rorganisation consiste gnrer partir de lentrept diffrents magasins de
donnes bass sur un modle multidimensionnel. Chaque magasin prpare les donnes pour
lanalyse (OLAP On Line Analytical Processing) ; les donnes sont organises autour dun
centre dintrt (le "fait") tandis que les dimensions constituent les diffrents axes de
lanalyse. Cette phase aborde des problmes lis la structure des donnes stockes dans les
magasins. Cette structure permet lanalyse optimale d'informations orientes "sujet".
Diffrentes interfaces graphiques sont mises la disposition de ladministrateur chaque
phase du processus de cration du systme daide la dcision. Les outils graphiques
proposs sont destins des utilisateurs experts (nous utiliserons le terme dadministrateur),
non ncessairement informaticiens, qui connaissent parfaitement les besoins des utilisateurs
finals du systme dcisionnel. Ladministrateur a trois tches principales : concevoir,
construire et maintenir le systme dcisionnel.
Phase 3
Phase 1
I
N
T
E
G
R
A
T
I
O
N

S1
S2
S3
.
.
.
Sn
Bases de
Production

Phase 2

SG
Source
Globale

Interface
Administrateur

C
O
N
S
T
R
U
C
T
I
O
N

Mta
Donnes
D
E
V
U
E
S

Interface
Administrateur

Lgende :
Processus de transfert de donnes

ED
Entrept
de Donnes

R
E
O
R
G
A
N
I
S
A
T
I
O
N

M
U
L
T
I
D
I
M
E
N
S
I
O
N
E
L
L
E

Interface
Administrateur

MD1

MD2

.
.
.

MDk
Magasins
de Donnes

Processus dalimentation et
de validation des mta-donnes

Figure 2.

Processus de construction des systmes d'aide la dcision.

4 Construction graphique de lentrept de donnes

Cette section dcrit la phase de construction de lentrept de donnes ; ce dernier est bas sur
une extension dun modle orient objet qui intgre des concepts relatifs aux entrepts de
donnes (typologie d'attributs et d'oprations). La gestion de donnes temporelles se fait

trois niveaux (attribut, classe d'objets et ensemble de classes d'objets). [TEST99] dcrit en
dtail notre modle conceptuel d'entrepts de donnes. Loutil permettant ladministrateur
de construire lentrept repose sur la dmarche suivante :
- 1 - Choisir un schma source.
- 2 - Projeter les classes du schma source dans lentrept de donnes et Slectionner
les instances sources qui alimentent les classes de lentrept ;
- 3 - Enrichir lentrept de donnes par ajout dattributs spcifiques et dattributs
calculs ;
- 4 - Dfinir les parties historises de lentrept de donnes.
Les sections suivantes dtaillent chaque tape en prsentant loutil daide ladministrateur
ainsi que les concepts associs.

4.1 La source globale

L'entrept de donnes est construit partir d'un schma source. La source de donnes repose
sur un modle conceptuel orient objet qui intgre les concepts de classe et de lien
(association, composition, dhritage). Le schma source est reprsent sous la forme dun
diagramme de classes UML [UML97].
Pour illustrer nos propos, nous utilisons un exemple dapplication de lAssurance Maladie en
France qui dispose de bases de production volumineuses.

Figure 3.

Schma UML dune source globale de lAssurance Maladie.

Nous proposons une visualisation de la source au travers dune interface graphique permettant
une vision directe du schma source et une perception intuitive de la smantique des objets
stocks. Afin damliorer cette perception (notamment lorsque le graphe est trs complexe),
diffrents niveaux dabstraction sont proposs pour laffichage du graphe : affichage simple
avec le nom des classes et les liens reliant les classes, visualisation des attributs des classes
pour affiner la perception du schma (cf. figure 3), simplification du graphe en masquant les
liens dhritage ou/et les liens de composition.

4.2 Projection et slection des classes sources

Nous proposons de dfinir un entrept de donnes comme une vue portant sur la source
globale. La vue est matrialise [GUPT95] : les donnes sont extraites de la source et stockes
physiquement dans lentrept. Ainsi les donnes de lentrept sont disponibles pour une
interrogation directe ou pour l'analyse via des outils OLAP (On-line Analytical Processing).
Nous adoptons l'approche des vues matrialises afin de permettre l'entrept de conserver
les volutions des donnes sources (cf. section 4.4).
Dfinition : Une vue V est dfinie comme un schma de classes drives. Le schma SED de
la vue dfinissant lentrept de donnes est reprsent par le graphe (CED ; LED) o
CED = {C1, C2,, Cn} est un ensemble fini de nuds reprsentant les
classes drives ;
LED = {L1, L2,Lm} est un ensemble fini darcs reprsentant les liens smantiques
entre classes.
Une classe drive Ci est dfinie par ( NomCi ; PCi ; RCi ; ExtCi ) o
NomCi est le nom unique de la classe ;
PCi est lensemble des proprits qui caractrisent la structure et le comportement des
instances de la classe ; PCi = ACi MCi avec ACi un ensemble d'attributs et MCi un
ensemble d'oprations.
RCi est la requte associe la classe permettant de calculer un ensemble de valeurs ;
ExtCi est lensemble des instances de la classe obtenues partir du rsultat de la
requte.
Un lien Li est dfini par ( CILi ; CTLi ; Li ) o
CILi est l'extrmit initiale ;
CTLi est l'extrmit terminale ;
Li est le type smantique (association, composition, hritage).
Le schma des classes drives dfinissant la vue est reprsent sous la forme dun
diagramme de classes conforme au formalisme UML [UML97].
Lentrept est construit par projection (drivation) dune partie du graphe source ;
ladministrateur projette les classes de la source quil souhaite placer dans lentrept. Lors de
la projection dune classe, la classe elle-mme, les attributs et les mthodes constituant la
classe, ainsi que les liens reliant la classe avec des classes dj projetes sont projets.
Loutil garantit la fermeture du type de la vue : tous les types ncessaires la dfinition de la
vue sont prsents dans l'entrept. Cette proprit de fermeture est obtenue grce aux principes
de la projection automatique des super classes dune classe projete ainsi que de ses classes
composantes. Par exemple, la projection de la classe "Praticiens" induit la projection de la
super classe "Personnes" dont hrite "Praticiens" (cf. figure 4).

Figure 4.

Exemple de projection dune classe.

Nous proposons lopration de slection au niveau des classes source. L'administrateur

exprime des slections afin dindiquer au systme quels objets sources sont drivs dans
lentrept.

Plusieurs oprations permettent de restructurer le schma de lentrept. Les oprations

disponibles sont renommer, supprimer, clater, regrouper Lopration regrouper permet de
grouper des attributs en un attribut structur de type n-uplet. Lopration clater permet
deffectuer lopration inverse en dstructurant un attribut de type n-uplet.

4.3 Enrichissement de lentrept

Lobjectif de cette tape est de complter les donnes de lentrept. Pour cela, notre modle
distingue trois catgories dattributs. Certains attributs (attributs drivs et attributs calculs)
sont extraits de la source, et dautres enrichissent lentrept (attributs spcifiques). Les
attributs drivs reprsentent dans lentrept les attributs sources. Les attributs calculs sont
obtenus par une combinaison (ou calcul) dattributs sources. Le calcul est exprim laide
dune fonction de calcul associe lattribut. Les attributs spcifiques ne sont pas lis la
source. Ils sont valoriss directement par les utilisateurs ; cela permet de complter et
dadapter lentrept car la source ne contient pas toujours toute linformation ncessaire aux
utilisateurs de lentrept [CHAU97].
Nous tendons le formalisme UML en distinguant chaque attribut par l'ajout une prposition :
D_ pour les attributs drivs, C_ pour les attributs calculs et S_ pour les attributs
spcifiques.
Par exemple, ladministrateur peut ajouter les attributs spcifiques "S_poids" et "S_taille" la
classe "Personnes" qui permettra aux mdecins, utilisateurs de lentrept, de complter les
informations contenues dans cet entrept.

(a)
(b)
Figure 5.

Cration de lattribut spcifique "P_poids".

4.4 Historisation des donnes de lentrept

Une caractristique importante des entrepts de donnes est la possibilit de conserver les
volutions des donnes. La gestion de ces volutions ncessite une modlisation du temps
dans l'entrept. Nous adoptons un modle temporel proche de [WANG97] qui approche le
temps par une suite de grains conscutifs disjoints, appels units temporelles.

Au cours du temps, les entits du monde rel voluent. Cette volution se traduit par des
changements de caractristiques des entits. Dans les bases de donnes classiques, les entits
sont reprsentes par des objets. Toute volution des caractristiques des entits est rpercute
dans la BD par la modification de la valeur ou du schma de lobjet, tandis que les tats
prcdents sont perdus.
Notre modle permet de grer des donnes temporelles trois niveaux diffrents, permettant
ainsi une grande souplesse dans la construction de lentrept et dans le choix dhistorisation
des donnes. Les choix des niveaux temporels sont trs importants ; en effet, ces choix
dtermineront le contenu de lentrept de donnes et donc dtermineront les possibilits
danalyse par rapport au temps. Par ailleurs, les volutions dun objet sont dceles
uniquement lors de la mise jour de lentrept (au cours de la phase dextraction des donnes
sources). La priodicit dextraction conditionne le contenu de lentrept : une priodicit trop
grande par rapport aux volutions de la source entrane une perte dinformation dans
lentrept.
4.4.1 Les attributs historiss
Nous proposons un premier niveau dhistorisation : celui des attributs. Un attribut historis est
dfini par une liste de couples (val ; DateExtrac) o val dsigne la valeur prise par lattribut et
DateExtrac dsigne la date dextraction de la valeur.

Figure 6.

Historisation dun attribut.

Par exemple, ladministrateur peut historiser lattribut "specialite_prat" de la classe

"Praticiens" afin de suivre les changements de spcialit des praticiens au cours de leur
carrire.
4.4.2 Les classes historises
Dans le cadre de lhistorisation des donnes dans les entrepts, les volutions d'une entit
peuvent tre conserves au niveau de l'objet ; chaque volution d'au moins un attribut, un
nouvel tat est dcrit pour l'objet considr. Un objet dit gnrique contient ltat initial, cest
dire ltat de lobjet source lors de la premire extraction. A chaque extraction, un nouvel
tat est ajout dans lobjet gnrique lorsque l'entit a volu.

Monde Rel

BD
Classique

Entrept de Donnes

t1
t2

dernier tat
de lobjet

t3

entit

tats successifs
de l objet

temps

Figure 7.

Historisation dune entit dans un entrept.

Une entit du monde rel est donc dcrite par un objet gnrique au niveau de lentrept. Cet
objet gnrique est form dun ensemble dtats ; chacun d'eux reprsentant une valeur de
lentit un instant donn. Lextension dune classe historise est un ensemble dobjets
gnriques tel que ExtCi = {OCi1, OCi2,, OCio}.
Dfinition : Un objet gnrique OCij est dfini par (IdCij, ECij, OSCij) o
IdCij est un identifiant d'objets;
ECij ={(Idj1, Vj1, Tj1), (Idj2, Vj2, Tj2),, (Idjx, Vjx, Tjx)} est l'ensemble des tats de
l'objet avec Idjk comme identifiant, Vjk comme valeur et Tjk comme intervalle de
temps.
OSCij est l'ensemble des objets sources dont drive l'objet.
Par exemple, ladministrateur peut historiser la classe "Beneficiaires" afin de suivre les
volutions de lensemble des attributs de la classe.

Figure 8.

Historisation dune classe.

Notons que seulement les volutions de valeurs des attributs est conserve. Les liens ne sont
pas modliss par des attributs mais sont un concept part entire du modle. Les liens relient
des objets gnriques. Leurs volutions ne sont conserves que par stockage des volutions
des objets gnriques lis (extrmits des liens).
4.4.3 Les environnements
Nous proposons un niveau dhistorisation plus global concernant un sous-ensemble de classes
dobjets et de liens ; on utilise le terme denvironnement. La notion denvironnement que
nous utilisons sinspire des versions de base de donnes [CELL91], mais applique un
ensemble de classes et non pas la totalit de lentrept. Un environnement est constitu dun

sous-ensemble des nuds de SED (schma de l'entrept) et de certains arcs dont les extrmits
initiales et terminales sont des nuds du sous-schma.
Dfinition : Un environnement Envi est dfini par (NomEnvi , (CEnvi ; LEnvi) ) o
NomEnvi est le nom de lenvironnement,
CEnvi CED,
LEnvi LED | LEnvik LEnvi, CILEnvi CEnvi CTLEnvi CEnvi.
Dans notre outil, pour construire un environnement, ladministrateur slectionne un ensemble
de classes et de liens, directement sur le graphe de lentrept avec la souris, puis il dfinit
lenvironnement en spcifiant son nom.

Figure 9.

Cration dun environnement.

Lobjectif dun environnement est de permettre la conservation des volutions des liens en
garantissant la conservation des volutions des classes d'objets extrmites des liens. En effet,
pour conserver l'volution d'un lien, il faut conserver les volutions de ses extrmits.
Plusieurs environnements peuvent tre dfinis, mais leurs ensembles respectifs de nuds
doivent tre disjoints : Env1, Env2, Env1Env2=.

5 Construction graphique des magasins de donnes

Le processus OLAP dfini par [CODD93] consiste analyser des donnes suivant diffrentes
dimensions. On peut par exemple analyser les prestations de la scurit sociale suivant les
dimensions "Temps", "Praticiens" et "Bnficiaires". Une analyse se concentre sur un sujet
prcis. Pour cette raison, les donnes doivent tre organises de manire particulire. Cette
organisation doit mettre en vidence le sujet analys et les dimensions de lanalyse. De plus,
les temps de rponses doivent tre optimiss lors de linterrogation [CODD93]. Ces objectifs
sont difficiles atteindre dans le cadre de l'entrept de donnes o les informations sont
exhaustives, dtailles et trs normalises. Ces caractristiques entranent une comprhension
difficile des informations ainsi que des performances moindres (en particulier cause de
nombreuses oprations de jointures entre classes).
Un magasin contient un sous-ensemble des donnes de l'entrept traitant d'un mtier
particulier de l'entreprise [INMO96]. Il est donc en mesure d'accueillir les donnes d'un sujet
analyser condition que celles-ci soient organises de manire adquate.
Nous proposons dans cette section une interface graphique d'aide la construction de
magasins de donnes. Cette interface est base sur un modle conceptuel et une dmarche. A
l'aide de l'interface, ladministrateur peut rorganiser les donnes de l'entrept pour une
analyse optimale dans le magasin. Le modle conceptuel propos est orient objet et il tend
le principe du schma en toile [SHOS97].

5.1 Dtermination des faits analyser

Le processus OLAP consiste analyser des mesures d'activit (par exemple la quantit
d'actes). Ces mesures sont analyses suivant diffrents niveaux de dtail. On peut ainsi
analyser la quantit d'actes pour un mois, un trimestre ou une anne avec un niveau de dtail
dcroissant. On passe un niveau de dtail infrieur en regroupant les mesures. Chaque
groupe de mesures est ensuite rsum l'aide de fonctions d'agrgation telles que la somme
ou la moyenne. On peut par exemple tudier les quantits d'actes par trimestre en faisant la
somme des quantits d'actes par mois.
5.1.1 La classe de fait
Les mesures d'activit sont des attributs de la classe de fait. Cette classe est l'lment central
du magasin de donnes. Elle se dfinit comme un ensemble d'attributs Cf = {A1, , Am} de
type simple. On ne fait pas intervenir les types complexes (utilisant les constructeurs
"ensemble" et "liste") pour lesquels des oprations d'agrgation sont difficilement applicables.
5.1.2 Projection de la classe de fait l'aide de l'outil graphique
Dans notre dmarche, la classe de fait est projete dans le magasin partir d'une classe de
l'entrept reprsentative du sujet analyser. L'entrept de donnes peut contenir plusieurs
classes reprsentatives concernant des sujets diffrents. Pour un sujet donn, on considre une

classe reprsentative unique. Les informations de la classe reprsentative sont mises jour
frquemment dans l'entrept (en particulier par des oprations d'ajouts) contrairement des
informations plus statiques (celles de la classe "Praticiens" par exemple). Cette classe peut
donc tre repre de manire automatique par le systme dans l'entrept.
A l'aide de l'interface graphique, ladministrateur peut visualiser les classes reprsentatives
candidates prsentes dans l'entrept de donnes. Lorsqu'une classe reprsentative est
slectionne, elle peut tre projete (avec les attributs qui la composent) dans le magasin de
donnes. Sur l'exemple de la figure 10, la classe reprsentative de l'analyse des prestations est
la classe "Actes". Cette classe est projete dans le magasin de donnes en tant que classe de
fait "Prestations". Dans le magasin de donnes, la classe de fait est identifie par le symbole
" ". La classe reprsentative l'origine d'une classe de fait est identifie par le mme
symbole dans l'entrept de donnes.
Lien d association

Classe de fait

ENTREPOT DE DONNEES

MAGASIN DE DONNEES

Fichier Oprations Affichage

CABINETS

Fichier Oprations

Personnes

SuiviHopitaux

D_Nom

Qte_acte

Etablissements

D_Prnom

D_Naissance

0..*

D_Adresse

Prix_unitaire

Disciplines

D_Num_eta

D_Sexe

Region

Prestations

pratiquees

D_Dept_exec

D_Code_dis

D_Adresse_eta

D_Libell

Dept

Taux_remb

Ville

D_Budget

Execution
Cabinets

intervient

Praticiens
1
D_Num_prat

1..*

D_Categorie_prat

exerce_au

1..*

D_Specialite_prat

Actes

D_Code_convention 1

D_Num_ligne

prescrit_par
0..*

Cabinets

Type

Libelle_cab

Type_acte

Nom

Libelle_jour

Code_cab

Libelle_acte

Prnom

D_Code_cab

Mois

Ville

Sexe

D_Adresse_cab

Trimestre

Dept

Naissance

D_Zone_fiscale

Annee

Region

Adresse

Zone_fiscale

Num_prat

Date_creation

Categorie_prat

D_Date_creation

D_Type_acte

D_Date_exec

Code_cab

PHARMACIES
Region

Dept

Specialite_prat

D_Quantit
D_Prix_unitaire

Praticiens

Date

D_Libelle_cab

Zone_fiscale

Medicaux
D_Agrement_radio

Code_convention

Pharmacies

Medicaux

D_Zone_repartition

Agrement_radio

D_Taux_Remb

Zone_repartition Ville Zone_fiscale

Pharmacies
Zone_repartition

Code_cab

Classe active

Lien activ

Classe de
dimension

Sous-classe
de dimension

Lien dhritage

Dpendance
hirarchique

Fentre de
hirarchie

Figure 10. Fentres principales de loutil graphique de conception des magasins de donnes

5.2 Dtermination des dimensions de l'analyse

Les attributs de la classe de fait sont analyss selon certains paramtres appartenant aux
dimensions. Par exemple, l'attribut "Qt_acte" peut tre analys suivant le mois d'excution de
l'acte (paramtre de la dimension "Execution") ou le type de l'acte (paramtre de la dimension
"Type"). Cet exemple est illustr par la figure 10. Les paramtres permettent de dterminer un
niveau de dtail. Par exemple, une analyse de la quantit d'actes par mois est plus dtaille
qu'une analyse par trimestre.
5.2.1 Les classes de dimension
Une classe de dimension se dfinit comme un ensemble d'attributs Cd = {A1, , Ad}. Ces
attributs peuvent tre de type simple (chane de caractre, numrique) ou de type complexe
(ensemble, liste). Les types complexes permettent d'exprimer des requtes d'analyse
difficilement exprimables dans un contexte relationnel ou multidimensionnel classique (avec
des quantificateurs "Au moins" et "Tous"). La classe de fait est relie une classe de
dimension par un lien d'association de cardinalit (1,1). On peut ainsi considrer la classe de
fait comme une classe d'association [UML97] reliant les classes de dimension (cf. figure 10).

Sur chaque classe de dimension est dfinie une hirarchie Hd des attributs. Les attributs d'une
hirarchie sont des paramtres de lanalyse. Ils sont lis par des dpendances hirarchiques.
Sur l'exemple de la figure 10, l'attribut "Ville" de la classe de dimension "Cabinets" dpend
hirarchiquement de l'attribut "Dpartement".
Dfinition : Une dpendance hirarchique entre deux attributs Ai et Aj (note Ai Aj)
implique :
une dpendance fonctionnelle entre Ai et Aj (note Ai Aj),
labsence dune dpendance fonctionnelle inverse Aj Ai.
On peut ainsi interprter une dpendance hirarchique entre Ai et Aj comme : une valeur de
Ai est associe exactement une valeur de Aj et une valeur de Aj est associe une ou plusieurs
valeurs de Ai. Ainsi, pour chaque attribut Ai Hd, il existe un attribut Aj tel que Ai Aj ou
Aj Ai.
Dfinition : Une hirarchie de dimension est reprsente par un graphe acyclique
Gh = (Nh, Lh) ou Nh est un ensemble de nuds et Lh un ensemble de liens entre ces nuds.
Chaque nud est associ un attribut de la hirarchie. Un lien correspond une dpendance
hirarchique entre deux attributs.
Les classes de dimension peuvent tre relies par un lien d'hritage. Un lien d'hritage permet
de spcialiser une classe de dimension. La sous-classe obtenue possde tous les attributs de la
super-classe, plus des attributs supplmentaires. On peut ainsi spcialiser une hirarchie.
(chaque sous-classe peut possder sa propre hirarchie). Sur l'exemple de la figure 10, la
classe de dimension "Pharmacie" est une sous-classe de la classe de dimension "Cabinets".
Cette sous-classe possde sa propre hirarchie qui spcialise la hirarchie de la super-classe
"Cabinets".
Dfinition : Le principe de dpendance entre classes est utilis dans l'entrept de donnes
pour dterminer les classes de dimension d'une analyse. Une classe C2 est dpendante d'une
classe C1 (C1 C2) dans l'un des cas suivants :
C1 est relie C2 par un lien d'association de cardinalit (x,1),
C1 est relie C2 par un lien d'hritage (dans le sens C1 est une super-classe de C2
ou dans le sens C1 et une sous-classe de C2),
C1 est relie C2 par un lien de composition (dans le sens C1 est une classe
composante de la classe compose C2 ou dans le sens C2 est une classe compose de la classe
composante C1 avec une cardinalit (x,1)),
C1 = C2.
Le principe de transitivit des dpendances se dfinit de la manire suivante : C1 C2 et C2
C3 permet de dduire que C1 C3. Sur l'exemple de la figure 10, la classe "Praticiens" est
dpendante de la classe "Actes". De mme, la classe "Cabinets" est dpendante de la classe
"Praticiens". Par transitivit, la classe "Cabinets" est donc dpendante de la classe "Actes".
5.2.2 Projection des classes de dimension l'aide de l'outil graphique
Dans notre dmarche, on peut dterminer toutes les classes dpendantes de la classe
reprsentative en utilisant le principe de transitivit des dpendances. Les classes dpendantes
de la classe reprsentative sont projetes (avec leurs attributs) dans le magasin en tant que

classe de dimension. Ladministrateur peut choisir les classes dpendantes projeter ou

laisser le systme projeter toutes les classes dpendantes dtectes.
On peut galement projeter une classe de dimension dans le magasin partir d'un attribut
d'une classe dpendante. Un attribut reprsentant une date peut ainsi tre l'origine d'une
classe de dimension temporelle. De mme, un attribut reprsentant une adresse peut tre
l'origine d'une classe de dimension gographique. Sur l'exemple de la figure 10, l'attribut
"Date_exec" de la classe "Actes" est l'origine de la classe de dimension "Execution".
Ladministrateur dfinit ensuite la hirarchie de chacune des classes de dimension du magasin
de donnes. Cette tape de la dmarche peut tre assiste par le systme qui recherche les
dpendances hirarchiques entre attributs de la classe de dimension. Ces attributs sont ensuite
ordonns pour dfinir les diffrents niveaux de dtail de la dimension. Ladministrateur peut
galement dfinir lui-mme une hirarchie si les dpendances sont dfinies dans un dossier
d'analyse ou si elles sont prsentes sous forme de mtadonnes dans l'entrept.
L'interface graphique d'aide la construction de magasins de donnes propose
automatiquement ladministrateur les classes dpendantes d'une classe slectionne.
Ladministrateur active une ou plusieurs classes dpendantes en empruntant un lien. Sur
l'exemple de la figure 10, depuis la classe "Actes", le concepteur active la classe dpendante
"Praticiens" en empruntant le lien "Prescrit_par". Les classes et les liens activs sont griss
sur le graphe reprsentant le schma de l'entrept. Dans le magasin de donnes, une classe de
dimension est identifie par le symbole "
". La classe dpendante l'origine d'une classe de
dimension est identifie par le mme symbole dans l'entrept de donnes.
Linterface d'aide la construction de magasin propose galement une fentre de hirarchie
permettant d'organiser les attributs d'une classe de dimension suivant leurs dpendances
hirarchiques. La figure 10 prsente la fentre de hirarchie de la classe de dimension
"Cabinets".

5.3 Oprations sur les classes du magasin de donnes

Lorsque la classe de fait et les classes de dimension sont projetes dans le magasin de
donnes, ladministrateur se trouve en prsence d'un schma orient objet en toile. Les
oprations prsentes dans ce paragraphe permettent de modifier ce schma (opration d'ajout
ou de suppression de mesures ou de paramtres) ou de slectionner des objets de classes
(opration de slection) pour limiter les objets imports depuis l'entrept de donnes dans le
magasin.
5.3.1 Manipulation d'attributs calculs
On peut ajouter un attribut calcul une classe du magasin de donnes. Cet attribut est une
combinaison dattributs appartenant aux classes de lentrept. Un attribut calcul est associ
une formule de calcul qui se prsente sous la forme d'un arbre Gc=(Nc, Lc). Nc est un
ensemble de nuds. Chaque nud reprsente un oprateur ou une oprande. Les oprateurs
peuvent tre de type scalaire (addition, soustraction, multiplication, division) ou agrgation
(somme, moyenne, comptage, min, max). Les oprandes sont des attributs des classes de
l'entrept. Lc est un ensemble de liens entre les nuds. Ces liens permettent d'associer
oprateurs et oprandes.
Dans notre dmarche, ladministrateur peut dcider de supprimer des attributs de la classe de
fait ou des classes de dimension qui n'intressent pas l'analyse. Il peut galement crer des
mesures calcules dans la classe de fait. On peut ainsi analyser des informations qui ne sont

pas directement prsentes dans l'entrept. Une mesure calcule est exprime sous forme d'une
requte s'appliquant sur l'entrept. Le point de dpart de cette requte est la classe
reprsentative l'origine de la classe de fait. A partir de cette classe, on accde aux classes
voisines via les liens. On peut ainsi crer une mesure calcule "Montant remb" dans la classe
de fait. Les valeurs de cette mesure sont calcules suivant la formule suivante :
("Actes.Quantit" * "Actes.Prix Unitaire") * "Actes.Taux Remb". Chaque nom d'attribut
intervenant dans la formule est prcd du nom de la classe laquelle il appartient.
Selon un principe similaire, ladministrateur peut crer des paramtres calculs dans une
classe de dimension. Un paramtre calcul s'exprime galement sous forme d'une requte
applique l'entrept. Le point de dpart de cette requte est la classe dpendante l'origine
de la classe de dimension. A partir de cette classe, on accde aux classes voisines via les liens.
Les paramtres calculs permettent par exemple d'ajouter des paramtres "Mois" et "Anne"
partir d'un paramtre "Date" d'une classe de dimension "Temps". De mme, partir d'un
paramtre "Adresse" d'une classe de dimension "Cabinets", on peut crer des paramtres
calculs "Ville", "Dpartement" et "Rgion". Sur l'exemple de la figure 11, les paramtres
"Libelle_jour", "Mois", "Trimestre" et "Annee" de la classe de dimension "Execution" sont
calculs partir de l'attribut "Date_exec" de la classe "Actes" prsente dans l'entrept.
MAGASIN DE DONNEES
Fichier Oprations

PRESTATIONS - Mesure calcule

Nom de
lattribut
calcul

Prestations
Montant_remb
Qte_acte
Prix_unitaire

Oprateur

Taux_remb
*
Actes.Quantit

Execution

Cabinets

Oprande

Type
Actes.Prix_unitaire

Date

Libelle_cab

Type_acte
Actes.Taux_remb

CABINETS - Slection

Libelle_jour
Mois

Sexe

And

Trimestre

Fentre de
calcul

Naissance

Annee

Adresse

Num_prat
Ville

Categorie_prat

"Toulouse"

Specialite_prat
Code_convention

>

Medicaux
Date_creation
Agrement_radio

Fentre de
slection

"01/01/1975"

Figure 11. Oprations principales dans un magasin de donnes

Pour ajouter des mesures ou des paramtres calculs, notre interface propose une fentre de
calcul. Cette fentre permet ladministrateur de construire une formule de calcul. Dans la
figure 11, ladministrateur ajoute une mesure calcule "Montant_remb" la classe de fait.
5.3.2 Opration de slection
L'opration de slection permet de construire un sous-ensemble d'objets d'une classe de fait ou
d'une classe de dimension. Ladministrateur peut par exemple dcider de ne conserver dans le
magasin que les cabinets de la ville de Toulouse crs aprs le 1er janvier 1975. Une formule
de slection est associe une opration de slection d'objets. Ce type de formule se prsente
sous la forme d'un arbre. Chaque nud correspond un oprateur ou une oprande. Les

oprateurs permettent de crer des expressions boolennes (et, ou, non) ou de comparaison
(gal, suprieur, infrieur). Les oprandes sont des attributs d'une classe de l'entrept.
L'opration de slection est disponible dans notre outil graphique via une fentre de slection
(cf. figure 11).

6 Conclusion
Dans cet article, nous avons prsent notre contribution en matire de construction d'entrepts
et de magasins de donnes. En particulier, nous avons propos :
-

une architecture des systmes dcisionnels quatre niveaux permettant de

distinguer clairement les problmatiques lies chaque phase de construction
(intgration des sources de donnes, construction de lentrept de donnes,
construction des magasins de donnes).

une dmarche et une interface graphique qui assiste ladministrateur pour

construire lentrept de donnes. Notre approche est base sur un modle
d'entrept de donnes orientes objet intgrant un mcanisme dhistorisation des
donnes trois niveaux (attribut, classe et environnement).

une dmarche et une interface graphique qui assiste ladministrateur dans la phase
de rorganisation permettant de construire des magasins de donnes. Ce processus
est bas sur un modle orient objet multidimensionnel.

Nous avons dvelopp un prototype au dessus du SGBD O2 permettant de valider nos

propositions. Pour cela, nous avons dfini un mta-schma permettant la gestion des entrepts
de donnes dans le SGBD O2 ; tout entrept dfini graphiquement par une vue est gnr
partir des classes du mta-schma grce au mcanisme dhritage. A partir des spcifications
graphiques, notre systme gnre les scripts de cration de la structure de l'entrept ou du
magasin, mais aussi les scripts de chargement initial et de rafrachissement des donnes. Nous
avons implant une interface administrateur permettant de dfinir graphiquement une vue et
d'historiser l'entrept diffrents niveaux (attribut, classe, environnement). Une autre
interface permettant de construire des magasins de donnes est en cours de ralisation. Cette
interface permet de rorganiser les donnes de l'entrept sous forme multidimensionnelle.
Nous souhaitons poursuivre nos travaux en proposant des langages graphiques permettant la
manipulation et linterrogation des donnes au niveau de lentrept et la manipulation et
linterrogation multidimensionnelle des donnes au niveau des magasins. Nous allons
galement complter nos travaux en intgrant des contraintes dans notre modle d'entrept de
donnes. Ces contraintes permettront l'administrateur de configurer le processus
d'historisation des donnes de l'entrept.

7 Remerciements
Nous tenons remercier Monsieur Franck Ravat et Madame Chantal Soul-Dupuy, matres de
confrences et membres de l'quipe SIG ainsi que Monsieur Gilles Zurfluh, professeur et
responsable de l'quipe SIG, pour leur contribution et toute l'aide qu'ils nous ont apport.

8 Rfrences :
AGRA97

R. Agrawal, A. Gupta, S. Sarawagi, Modeling Multidimensional Databases ,

Proceeding of the ICDE'97.

ANDO91

Eric Andonoff, Michel Canillac, Hypertext Interface for an Object-Oriented

Database , Proceedings of the RIAO International Conf., Barcelona, April 1991.

ANDO97

Eric Andonoff, Gilles Hubert, Annig Le Parc Interrogation de bases de donnes

intgrant des versions ,15me congrs INFORSID Toulouse (France), Juin 1997.

BELL98

Zohra Bellahsene, Structural View Maintenance in Data Warehousing Systems ,

14me Journes Bases de Donnes Avance BDA98, p217-229, Hammamet
(Tunisie), 26-30 Octobre 1998.

BELI96

B. Blires, C. Trpied, New Methophors for a Visual Query Language , IN 7th Int
Workshop on Database and Expert Systems Applications, Zurich (Switzerland),
September 1996.

CELL91

Wojciech Cellary, Genevive Jomier, Formal Model of an Object-Oriented

Database with Versionned Objects and Schema , in Proceedings of the Database and
Expert Systems Applications Conference - DEXA'91, 1991, Berlin (Germany).

CHAU97

Surajit Chaudhuri, Umeshwar Dayal, An Overview of Data Warehousing and OLAP

Technology , Proceedings of SIGMOD Records, 26(1) : p65-74, March 1997.

CODD93

E.F. Codd, Providing OLAP (on-line analytical processing) to user-analysts : an IT

mandate , Technical Report, E.F. Codd and Associates, 1993.

COLL96

George Colliat, OLAP, relationnal and multidimensionnal database systems ,

SIGMOD Record, vol. 25, n. 3, pp. 64-69, 1996.

GARD93

G. Gardarin, Matriser les Bases de donnes et Langages , Ed Eyrolles, Avril 1993.

GOLF98

M. Golfarelli, D. Maio, S. Rizzi, Conceptual Design of Data Warehouses form E/R

Schemes , 31st, Hawaii International Conference On system Sciences, January 6-9,
1998, Kona, Hawaii.

GRAY96

J. Gray, A. Bosworth, A. Layman, H. Pirahesh, Data Cube : A Relationnal

Aggregation Operator Generalizing Group-By, Cross-Tab and Sub-Totals , 12th
IEEE International Conference on Data Engineering, ICDE'96, pp. 152-159, New
Orleans, Louisiana, Feb. 26-Mar. 1, 1996.

GUPT95

Ashish Gupta, Inderpel Singh Mumick, Maintenance of Materialized Views :

Problems, Techniques, and Applications , Data Engineering Bulletin, June 1995.

GYSS97

M. Gyssens, L. V.S. Lakshmanan. A Foundation for Multi-Dimensional Databases

, Proc. of the 23rd VLDB Conference, Athens, 1997, p106-115.

INMO96

W.H. Inmon, Building the Data Warehouse , second edition, Wiley Computer
Publishing, USA.

JARK98

Matthias Jarke, Manfred A. Jeusfeld, Christoph Quix, Panos Vassiliadis,

Architecture and Quality in Data Warehouses , Proceedings in CAISE98, June
1998, Pisa (Italy).

LEHN98

W. Lehner, Modeling Large Scale OLAP Scenarios , 6th International Conference

On Extending Database Technology, EDBT'98, Valencia, Spain, 23-27, March 1998.

RAVA96

F. Ravat, La fragmentation d'un schma conceptuel orient objet ,Ingnirie des

systmes d'information, Vol 4, n2, pp161-193, 1996.

REDB95

Red Brick Systems White Paper, Decision-Makers, Business Data and RI-SQL ,
Red Brick Systems, Los Gatos, CA, 1995.

SAMO98

Jos Samos, Flix Saltor, Jaume Sistrac, Agusti Bards, Database Architecture for
Data Warehousing : An evolutionary Approach , Proceedings of the 9th International
Conference on Database and Expert Sytems Applications DEXA98, p746-756,
August 1998, Vienna (Austria).

SAYA98

Marguerite Sayah, Un environnement dinterrogation graphique de bases de

donnes orientes objet (EIGOO) pour des utilisateurs non informaticiens , Thse de
linstitut national des sciences appliques de Lyon, Lyon (France), 1998.

SHOS97

Arie Shoshani, OLAP and Statistical Databases : Similarities and Differences , 16th
ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems,
pp185-196, 1997.

STAE91

F. Staes, L. Tarantino, A. Tiems, A Graphical Query Language for Object Oriented

Databases , In IEEE Workshop on visual language, Kobe (Japan), 1991.

TEST99

Olivier Teste, Modlisation conceptuelle des entrepts de donnes , Rapport

interne IRIT/99-01-R, Institut de Recherche en Informatique de Toulouse, Janvier
1999, Toulouse (France).

UML97

UML version 1.0 . Rational Software Corporation, 13 January 1997, Santa Clara
(USA).

VADA93

K. Vadaparty, Y.A. Aslandogan, G. Ozsoyoglu, Towards a Unified Visual Database

Access , In Int. Conf. of SIGMOD93, pp.357-366, Washington (USA), 1993.

WANG97

X. Sean Wang, Claudio Bettini, Alexander Brodsky, Sushil Jajodia, Logical Design
for Temporal Databases with Multiple Granularities , ACM TODS, Vol 22, n2,
pp.115-170, June 1997.

WIDO95

Jennifer Widom, Research problems in data warehousing , Proceedings of the 4th

Internationnal Conference on Information and Knowledge Management (CIKM), p2530, November 1995.

WIEN96

Janet L. Wiener, Himanshu Gupta, Wilburt J. Labio, Yue Zhuge, Hectore GarciaMolina, Jennifer Widom, A system prototype for warehouse view maintenance ,
Proceedings of the ACM Workshop on Materialized Views : Techniques and
Applications, p26-33, June 1996, Montreal (Canada).

WU97

Ming-Chuan Wu, Alejandro P. Buchmann, Research Issues in Data Warehousing ,

BWT97, pp61-82, 1997.

YANG98

Jun Yang, Jennifer Widom, Maintaining Temporal Views Over Non-Temporal

Information Sources For Data Warehousing , Proc. of the 6th Int. Conf. on Extending
DataBase Technologie EDBT98, March 1998, Valencia (Spain).

ZHAO97

Yihong Zhao, Prasad Deshpande, Jeffrey F. Naughton, An Array-Based Algorithm

for Simultaneous Multidimensionnal Aggregates , SIGMOD 1997.

ZHUG95

Yue Zhuge, Hector Garcia-Molina, Joachim Hammer, Jennifer Widom, View

Maintenance in a Warehousing Environment , Proc. of ACM SIGMOD Int. Conf. on
Management of Data, p316-327, June 1995, San Jose (California, USA).