Elaboration d'entrepts de donnes complexes

Olivier Teste
Universit Paul Sabatier (Toulouse III),
IRIT (Institut de Recherche en Informatique de Toulouse), quipe SIG,
118, Route de Narbonne - 31062 Toulouse cedex 04, France
tel : (33) (0)5 61 55 63 22 fax : (33) (0)5 61 55 62 58
mel : Olivier.Teste@irit.fr
[Catgorie Jeune Chercheur]

Rsum :
Dans cet article, nous abordons le problme de la modlisation des entrepts de donnes couramment utiliss dans
les systmes d'aide la dcision. Nous proposons un modle permettant de dcrire l'entrept comme un rfrentiel
centralis de donnes complexes, temporelles et extraites d'une source d'information. Notre modle intgre trois
concepts : l'objet entrept, la classe entrept et l'environnement. Chaque objet entrept est compos d'un tat
courant, de plusieurs tats passs (modlisant les volutions dtailles) et de plusieurs tats archivs (modlisant
les volutions de manire rsume). Le concept d'environnement dfinit les parties temporelles dans le schma de
l'entrept avec une granularit pertinente (attribut, classe, graphe). Enfin, nous spcifions cinq fonctions visant
dfinir les structures de l'entrept et deux fonctions permettant d'organiser la hirarchie d'hritage des classes
entrept.
Mots-cls :
Modlisation des entrepts, modle orient objet, donnes temporelles complexes.

Abstract :
In this paper, we study the data warehouse modelling used in decision support systems. We provide an object-
oriented data warehouse model allowing data warehouse description as a central repository of relevant, complex
and temporal data. Our model integrates three concepts such as warehouse object, environment and warehouse
class. Each warehouse object is composed of one current state, several past states (modelling its detailed
evolutions) and several archive states (modelling its evolutions within a summarised form). The environment
concept defines temporal parts in the data warehouse schema with significant granularities (attribute, class, graph).
Finally, we provide five functions aiming at defining the data warehouse structures and two functions allowing the
warehouse class inheritance hierarchy organisation.
Keywords :
Warehouse modelling, object-oriented model, complex temporal data.
1 Introduction
L'approche des entrepts de donnes ("data warehousing") est aujourd'hui unanimement
reconnue comme tant une solution adapte et performante, permettant d'amliorer la prise de
dcision dans les entreprises [WIDO95] [INMO96] [CHAU97] [GATZ99] [JARK99]. Un
entrept se dfinit comme "une collection de donnes intgres, orientes sujet, non volatiles,
historises, rsumes et disponibles pour linterrogation et lanalyse" [INMO96]. Il permet de
stocker les donnes ncessaires la prise de dcision ; il est aliment par des extractions de
donnes portant sur des bases de production, appeles sources de donnes.
La prsente tude poursuit les travaux effectus dans notre quipe en conception de systme
d'informations en milieu hospitalier [LAPU97] et vise laborer un systme d'aide la
dcision, bas sur l'approche des entrepts de donnes, dans le milieu mdicali. Plus
prcisment, notre systme se propose d'amliorer l'analyse, le suivi et le contrle des dpenses
de sant, de l'activit des mdecins et du "comportement consommateur" des patients. Nos
travaux se placent dans le cadre du groupe EVOLUTIONii, regroupant diffrentes quipes de
recherche franaises, pour le dveloppement de systmes d'aide la conception d'entrepts.

C S
I O T
N N R
T S U
Analyses
E T C Interrogations
G R T
R U U Fouilles de donnes
...

...

A C R
SOURCE ENTREPT
T T A
GLOBALE DE DONNEES
I I T
O O I
SOURCE MAGASINS
N N O
DE DONNEES DE DONNEES
N

figure 1 : Architecture du systme d'aide la dcision.

Nous avons dfini un tel systme [BRET99] [RAVA00], dcompos en trois niveaux
(intgration, construction, structuration), dans le but de distinguer les diffrentes
problmatiques de recherche ; la figure 1 prsente l'architecture du systme.
- L'intgration se propose de rsoudre les problmes d'htrognit (modles, formats et
smantiques des donnes, systmes,) des diffrentes sources de donnes en intgrant
celles-ci dans une source globale. Cette source globale est virtuelle, c'est dire que les
donnes utilises pour la dcision restent stockes dans les sources de donnes et sont
extraites uniquement au moment des mises jour de l'entrept.
Les techniques issues des bases de donnes fdres [SAMO98] et rparties [RAVA96]
peuvent tre utilises. De nombreux travaux de recherche traitent de ces problmatiques,
notamment le projet WHIPSiii [WIDO95] [LABI97], dvelopp l'universit de Stanford,
qui propose plusieurs algorithmes pour l'intgration et la maintenance des donnes issues de
sources autonomes, distribues et htrognes.
- La construction consiste extraire les donnes pertinentes pour la prise de dcision, puis
les recopier dans lentrept de donnes, tout en conservant, le cas chant, les changements
dtats des donnes. L'entrept de donnes constitue une collection centralise, de donnes

i
Cette tude a t partiellement finance par le CTI-Sud (Centre de Traitement Informatique des rgions Midi-
Pyrnes et Languedoc-Roussillon) de lAssurance Maladie.
ii
Le projet EVOLUTION (http://www.prism.uvsq.fr/dataware/coop/evolution.html) se positionne dans le
domaine de la conception des systmes d'informations et propose le dveloppement d'une mthodologie et d'un
outil de type CASE pour l'aide la conception et l'volution des entrepts de donnes.
iii
http://www-db.stanford.edu/warehousing/index.html
 matrialises et historiques (conservation des volutions), disponibles pour les applications
de l'entrept.
Pour construire l'entrept, l'approche des vues matrialises [GUPT95] est souvent utilise.
Les aspects techniques, comme la maintenance des vues matrialises [HYUN97]
[KOTI99] [YANG00] et la slection des vues matrialiser [THEO98] [THEO99] font
l'objet de nombreuses propositions, tandis que les aspects modlisation restent peu abords
[GATZ99]. Rcemment, des travaux abordent l'un des aspects essentiels des entrepts :
celui de la conservation des volutions (donnes temporelles) ; [YANG00] propose un
langage de dfinition de vues relationnelles temporelles et un algorithme de maintenance de
ces vues matrialises.
- La structuration rorganise les donnes dans des magasins de donnes afin de supporter
efficacement les processus d'interrogation et d'analyse tels que les applications OLAP ("On-
Line Analytical Processing" [CODD93]) et la fouille de donnes ("Data Mining"
[FAYY96]). Pour ce faire, les donnes importes dans les magasins sont organises de
manire multidimensionnelle [AGRA97].
De nombreux travaux proposent des modles multidimensionnels, pour les bases
relationnelles [AGRA97] [GYSS97] [LEHN98]. Ces diffrentes propositions sont
parfaitement adaptes aux applications de gestion classiques, mais ne permettent pas de
rpondre compltement aux exigences des applications actuelles telles que les applications
mdicales [PEDE99]. En effet, ces dernires ncessitent des modles plus riches que les
modles bass sur l'approche relationnelle afin de grer des donnes complexes. Un autre
intrt de l'approche objet rside dans la modlisation des dimensions de l'analyse par des
hirarchies de composition pour supporter efficacement les analyses OLAP en niveaux de
dtails. [PEDE99] propose un modle multidimensionnel orient objet intgrant des
donnes temporelles ainsi que des donnes imprcises. Cependant cette tude, situe dans le
milieu mdical, se limite au dossier patient et ne propose pas de mthode pour constituer
une base multidimensionnelle objet.
Dans notre architecture, au niveau de l'entrept on se concentre sur la gestion efficace des
donnes extraites et sur la conservation de leurs volutions, tandis qu'au niveau des magasins
de donnes on se concentre sur les performances d'interrogation. Un magasin contient un sous
ensemble des donnes de l'entrept traitant d'un mtier particulier de l'entreprise [INMO96].
Les donnes relatives un sujet analyser sont donc rorganises de manire adquate,
gnralement de manire multidimensionnelle pour rpondre aux exigences des applications
OLAP. Dans [BRET99] nous avons propos un modle orient objet multidimensionnel
gnral, ddi aux magasins de donnes. Les donnes de l'entrept sont ainsi rorganises au
travers d'une classe de fait regroupant les mesures d'activit analyser et de plusieurs classes de
dimension correspondant aux diffrents paramtres de l'analyse. Cette proposition est valide
par un outil d'aide la rorganisation multidimensionnelle objet. D'autre part, nous avons men
une tude mthodologique pour concevoir des magasins de donnes orientes objet
multidimensionnels [BRET00].
Cet article se positionne au second niveau de notre architecture et traitent de la construction de
l'entrept de donnes. Nous abordons la problmatique de la modlisation et de
l'laboration de l'entrept. A notre connaissance, il n'existe pas de proposition de
modlisation des entrepts base sur le paradigme objet.
Notre tude aborde les points suivants :
- Nous proposons une modlisation de l'entrept permettant de dcrire des donnes
complexes et temporelles. Notre modle prend en compte les besoins de modlisation de
donnes complexes et intgre la dimension temporelle afin de conserver les volutions des
donnes de manire pertinente. Il doit tre organis de manire adapte une gestion
efficace des donnes afin d'assurer la prennit dans le temps de l'entrept.
- Nous prsentons une solution visant l'laboration de l'entrept qui est construit par
extractions de donnes issues de la source globale.
La section 2 tudie la modlisation de l'entrept et dcrit notre modle ddi aux entrept de
donnes. La section 3 traite du processus d'laboration de l'entrept, en proposant un
mcanisme pour construire le schma de l'entrept en utilisant des fonctions d'extraction,
d'accroissement et de hirarchisation. Enfin, la section 4 dcrit brivement un prototype visant
valider nos propositions.

2 Modlisation de l'entrept
L'entrept de donnes collecte des donnes, pertinentes pour supporter les processus de
dcision, issues d'une source globale. Ainsi, nous dcrivons un exemple de schma source dans
le section 2.1. Ensuite, la section 2.2 prsente le concept d'objet entrept et la section 2.3 celui
de classe entrept. La section 2.4 introduit le concept d'environnement pour dfinir les parties
temporelles de l'entrept. Enfin, la section 2.5 dfinit le schma de l'entrept.

2.1 Cadre de l'tude : exemple de schma source

La source globale, c'est dire la base de donnes partir de laquelle est labor l'entrept, est
dcrite avec un modle de donnes orientes objet. Nous justifions notre choix par le fait que le
paradigme objet s'est rvl parfaitement adapt pour l'intgration de sources htrognes
[BUKH93] [RAVA96] [SAMO98] et permet de modliser des sources intgrant des structures
complexes.
Pour dcrire les aspects statiques de cette source, nous utilisons le modle objet standard :
modle de l'ODMG [CATT95] tendu par le concept de composition d'objets [BERT98].
Les travaux, prsents dans la suite de l'article, seront illustrs partir de la source de donnes
mdicales suivante. Cette source de donnes dcrit des patients et des praticiens. Ces derniers
travaillent dans des services hospitaliers. Chaque service est dirig par un praticien. Les
patients consultent les praticiens, qui mettent des diagnostics et peuvent ordonner des
analyses.
interface PERSONNE {
attribute String nom;
attribute String prnom;
attribute Struct T_Adresse { String libelle,
String ville,
Long code_postal } adresse;
attribute Short anne_naissance;
Short age();
String dpartement();
}
interface PATIENT (extend PERSONNE) {
attribute String no_insee;
attribute String cle_insee;
}
interface PRATICIEN (extend PERSONNE) {
attribute String no_praticien;
attribute String catgorie;
attribute String spcialit;
attribute Double revenus;
relationship Set<SERVICE> travaille inverse SERVICE::quipe;
relationship <SERVICE> dirige inverse SERVICE::est_dirig;
}
interface ETABLISSEMENT {
attribute String nom;
attribute String statut;
attribute Struct T_Adresse { String libelle,
String ville,
Long code_postal } adresse;
attribute Double budget;
 composition Set<SERVICE> organisation;
}
interface SERVICE {
attribute String nom;
attribute String tlphone;
relationship Set<PRATICIEN> quipe inverse PRATICIEN::travaille;
relationship <PRATICIEN> est_dirig inverse PRATICIEN::dirige;
}
interface CONSULTATION {
attribute Date date;
attribute String commentaires;
attribute String diagnostic;
relationship Set<Image> analyses;
relationship <PATIENT> patient;
relationship <PRATICIEN> praticien;
}

2.2 Concept d'objet entrept

Au niveau de l'entrept, chaque objet source extrait (ou groupe d'objets source) est reprsent
par un objet, appel objet entrept. Un objet entrept est caractris par un identifiant interne,
lequel est immuable, persistant au cours du cycle de vie de l'objet et indpendant des objets de
la source.
L'entrept de donnes doit conserver les changements d'tat des objets, tandis que la source de
donnes ne contient gnralement que l'tat courant [CHAU97], ou bien, ne conserve qu'une
partie rcente des volutions, insuffisante pour la prise de dcision [YANG00]. Dans un
entrept, l'administrateur peut dcider de conserver :
- l'image de l'objet source, c'est dire son tat courant,
- les tats successifs que prend l'objet source dans le temps, c'est dire ses tats passs,
- uniquement un rsum de ses tats passs successifs, c'est dire l'agrgation de certains
tats passs, appele tats archivs.
La figure 2 illustre notre proposition de modlisation des objets entrept, en reprsentant un
objet entrept possdant un tat courant, trois tats passs et un tat archiv.
M on d e R el S ou rce E n trep t

L gende :
p e1
E ntit courante
E tat pass d'une entit
O bjet source courant
p e2 E tat pass d'un objet source
O bjet entrept
E tat courant d'un objet entrept
E tat pass d'un objet entrept
p e3
E tat archiv d'un objet entrept

p e4

p e5

p e6

entit points
objet
d'extraction objet entrept
source

figure 2 : Principe de modlisation d'un objet entrept.

Deux approches sont envisageables pour rafrachir l'entrept de donnes [WIDO95], c'est dire
pour rpercuter dans l'entrept les volutions qui surviennent au niveau de la source :
- L'approche du rafrachissement priodique consiste mettre jour rgulirement
l'entrept lors de points d'extraction correspondant un tat de cohrence de la source
(terminaison des transactions).
- L'approche du rafrachissement incrmental consiste rpercuter chaque modification
d'une valeur de la source ds que possible. Cette approche fait l'objet de travaux importants
dans le domaine des entrepts [WIDO95] [ZHUG95] [YANG00].
Nous adoptons l'approche priodique puisque dans notre contexte (contrle et suivi de l'activit
des professionnels de sant et des patients) il est admis que l'analyse de l'activit des hpitaux
peut s'effectuer avec un dcalage par rapport la ralit. Ainsi l'tat courant dans l'entrept ne
correspond pas forcment l'tat courant de la source et certaines volutions de la source
peuvent ne pas tre rpercutes dans l'entrept (notamment lorsque plusieurs volutions
surviennent entre deux points d'extraction conscutifs). Ceci oblige l'administrateur choisir
une priode de rafrachissement de l'entrept adapte aux besoins des applications
dcisionnelles et au rythme d'volution de la source, tout en maintenant les performances de
l'entrept lors de l'interrogation.
Nous formalisons le concept d'objet entrept par les dfinitions suivantes :
Un objet entrept o est dfini par le quadruplet (oid, S0, EP, EA) o
oid est l'identifiant interne,
S0 est l'tat courant,
EP = {Sp1, Sp2,, Spn} est un ensemble fini contenant les tats passs,
AP = {Sa1, Sa2,, Sam} est un ensemble fini contenant les tats archivs.
Un objet entrept possde toujours un tat courant, tandis que l'ensemble des tats passs et
l'ensemble des tats archivs peuvent tre vides.
Un tat Si d'un objet entrept est dfini par le couple (hi, vi) o
hi est le domaine temporel correspondant aux instants durant lesquels l'tat Si est courant,
vi est la valeur de l'objet durant les instants de hi.
Afin de dfinir le domaine temporel hi d'un tat, notre modle intgre un modle temporel,
linaire, discret qui dfinit le temps par le biais d'units de temps [GORA98]. L'espace continu
du temps peut tre reprsent par une droite de rels, laquelle est dcompose en une suite
d'intervalles conscutifs disjoints [WANG97] [FAUV99]. Chaque intervalle (rgulier ou
irrgulier) est non dcomposable et tout instant de la droite de rels est approch par l'intervalle
qui le contient. Les units de temps sont caractrises par la taille des intervalles dcomposant
la droite du temps. Notre modle gre un ensemble d'units temporelles nommes (anne,
semestre, trimestre, mois,), muni d'une relation d'ordre partiel est-plus-fine permettant de
comparer les units. Enfin, nous dfinissons trois types temporels de base : dure, instant et
intervalle.
Un domaine temporel hi est un ensemble ordonn d'intervalles, exprim par hi = <[td1, tf1[;
[td2, tf2[;;[tdh, tfh[>, satisfaisant aux proprits suivantes :
chaque intervalle est non vide, k[1..h], tdktfk,
les intervalles ont la mme unit temporelle, k[1..h],j[1..h], unit([tdk,tfk[)=unit([tdj,tfj[),
les intervalles sont disjoints, k[1..h], jk[1..h], [tdk, tfk[[tdj, tfj[=,
les intervalles sont ordonns et non contigus, k[1..h-1[,tfk < tdk+1.
La fonction unit(Int) retourne le nom de l'unit temporelle utilise par l'intervalle Int.
Le cycle de vie [d, f] d'un objet entrept recouvre les domaines temporels de ses tats passs, de
ses tats archivs et de son tat courant :
pn am
[ d , f [ h 0 h i h j .

i 1 j 1
Au cours de son cycle de vie, un objet entrept est initialement, actif tant que tous les objets
sources partir desquels il est gnr, sont prsents dans la source, puis, gel lorsqu'au moins
un de ses objets source a t supprim. Ainsi, l'objet entrept peut tre rafrachi tant qu'il est
actif, tandis qu'il n'est plus modifiable lorsqu'il est gel, puisque son origine la source n'est
plus disponible.
EXEMPLE : La figure 3 reprsente graphiquement un objet entrept modlisant un hpital. Cet
objet a t cr le 1er janvier 1990 et il est rafrachi chaque anne. L'objet conserve les
volutions du budget et du nombre de services, sous une forme dtaille durant deux ans, puis
sous une forme rsume pour les tats les plus anciens. Il se compose d'un tat courant, de deux
tats passs et d'un tat archiv.
H _oid 1:H op itau x objet entrept

tat cou ran t : < [01-01-2000;n ow [>

nom = "C H U R angueil"
ville= "T oulouse"
tat courant
budget= 250 000 000,00
nb_services= 60
date_creation= 1958

tat p ass : < [01-01-1999;01-01-2000[> tat p ass : < [01-01-1998;01-01-1999[>

budget= 220 000 000,00 budget= 200 000 000,00 tats passs
nb_services= 55 nb_services= 52

tat arch iv : < [01-01-1990;01-01-1998[>

budget= 150 000 000,00 tat archiv
nb_services= 50

figure 3 : Reprsentation graphique d'un objet entrept.

2.3 Concept de classe entrept

Les objets entrept qui ont le mme type abstrait, sont regroups dans une classe. Nous
dfinissons le concept de classe entrept comme suit.
Une classe entrept c est dfinie par le septuplet (Nomc, Typec, Superc, Extensionc, Mappingc,
Tempoc, Archic) o
Nomc est le nom de la classe,
Typec est le type dfinissant la structure et le comportement des objets entrept de c,
Superc est l'ensemble des super classes de c,
Extensionc = {o1, o2,, ox} est l'ensemble fini des objets entrept regroups dans c,
Mappingc est une fonction de construction qui permet de spcifier l'origine de la classe c,
Tempoc est un filtre temporel dfinissant l'ensemble des proprits temporelles de c (une
proprit est temporelle lorsque ses volutions sont conserves par des tats passs),
Archic est un filtre d'archives dfinissant l'ensemble des proprits archives de c (une
proprit est archive lorsque ses volutions passes sont rsumes dans des tats archivs).
Le type d'une classe c est dfini par un couple (Structurec, Comportementc) o
Structurec=(Attributsc, Relationsc) est un ensemble de proprits, celles-ci pouvant tre soit des
attributs, soit des relations smantiques (association, composition) entre la classe entrept c et
une (ou plusieurs) autre(s) classe(s), tandis que Comportementc est un ensemble d'oprations
applicables.
Nous tendons le concept de type en spcifiant l'origine de chaque proprit.
- Une proprit drive est une proprit issue directement de la source. Le type et la valeur
d'un attribut driv sont identiques l'attribut source. Une relation drive reprsente une
relation source ; elle est dfinie entre les classes entrept issues des classes source
impliques dans la relation source.
- Une proprit calcule est un attribut dont la valeur est le rsultat d'une fonction (avg,
sum, max, min, count,) applique sur la source et dont le type est infr par le rsultat de
 cette fonction. Ce mcanisme permet l'administrateur d'agrger des donnes source dans
l'entrept.
- Une proprit spcifique est une proprit introduite par l'administrateur sans tre issue de
la source. Une telle proprit est valorise soit par l'administrateur, soit par les utilisateurs
qui peuvent ainsi complter l'information contenue dans l'entrept.
De manire analogue, nous dfinissons une opration drive comme une opration issue de la
source et une opration spcifique comme une opration ajoute par l'administrateur (elle
complte le comportement de l'entrept pour satisfaire des exigences lies aux applications
dcisionnelles).
Les classes entrept sont organises suivant une hirarchie d'hritage, modlise par Superc.
Pour deux classes ci et cj, ci est une sous classe de cj (cj est une super classe de ci), note cicj si
et seulement si, TypeciTypecj et ExtensionciExtensioncj.
La fonction de construction Mappingc permet de prciser comment est construite la classe
entrept, c'est dire, partir de quelle(s) classe(s), avec quelle(s) proprit(s) drive(s),
augmente de quelle(s) proprit(s) spcifique(s) et de quel(s) attribut(s) calcul(s). Cette
fonction, implique dans l'laboration de l'entrept, fait l'objet d'une tude dtaille dans la
section 3.
Les filtres temporel Tempoc et d'archives Archic, caractrisent respectivement les proprits
temporelles et d'archives de la classe. Par consquent, le filtre temporel est constitu d'un
ensemble d'attributs temporels dont les volutions de valeur seront conserves par des tats
passs. Le filtre d'archives est un ensemble de couples (attribut, fonction) ; l'ensemble des
attributs archivs (sous ensemble des attributs temporels de la classe) sont associs une
fonction d'agrgation qui indique comment sont rsumes les volutions dtailles dans les
tats d'archives.
EXEMPLE : Un administrateur dsire laborer un entrept contenant les informations relatives
la catgorie des praticiens chirurgiens. Il dfinit un entrept constitu de six classes, dont la
dfinition est donne ci-dessous, dans un langage de dfinition objet, proche de celui de
l'ODMG.
- La classe entrept "Personnes" est constitue de proprits drives et d'un filtre temporel
prcisant que les volutions dtailles de l'attribut "adresse" sont conserves. Les
volutions des autres proprits ne sont pas conserves.
- La classe "Chirurgiens" hrite de "Personnes". Son filtre temporel est compos de quatre
proprits tandis que son filtre d'archives contient uniquement les attributs temporels
"spcialit" (rsum par la fonction last) et "revenus" (rsum avec la fonction avg).
- La classe "Jeunes_Chirurgiens" hrite de la classe "Chirurgiens".
- La classe "Hpitaux_Publics" est constitue d'attributs drivs ("nom", "ville" et "budget"),
d'un attribut calcul ("nb_services"), d'un attribut spcifique ("anne_cration") et d'une
relation de composition drive ("organisation"). Un filtre temporel et un filtre d'archives
sont prciss.
- La classe "Services", composante de "Hpitaux_Publics", comprend un attribut driv et
deux relations d'association drives. Son filtre temporel indique les proprits temporelles.
- La classe "Etablissements" hrite des classes "Hpitaux_Publics" et "Services".
Nous prcisons l'origine des proprits par une lettre prfixe "D_" pour drive, "C_" pour
calcule et "S_" pour spcifique.
interface Personnes {
D_attribute String nom;
D_attribute String prnom;
attribute Struct T_Adresse { String libelle,
String ville,
Long code_postal } adresse;
D_attribute Short anne_naissance;
}
with filters {
temporal adresse;
}
interface Chirurgiens (extend Personnes) {
D_attribute Long no_praticien;
D_attribute String spcialit;
D_attribute Double revenus;
D_relationship Set<Services> travaille inverse Services::quipe;
D_relationship <Services> dirige inverse Services::est_dirig;
}
with filters {
temporal spcialit, revenus, travaille, dirige;
archive last(spcialit), avg(revenus);
}
interface Jeunes_Chirurgiens (extend Chirurgiens) {
}
interface Hpitaux_Publics {
D_attribute String nom;
D_attribute String ville;
D_attribute Double budget;
C_attribute Short nb_services;
S_attribute Short anne_cration;
D_composition Set<Services> organisation;
}
with filters {
temporal budget, nb_services, organisation;
archive avg(budget), avg(nb_services);
}
interface Services {
D_attribute String nom;
D_relationship Set<Chirurgiens> quipe inverse Chirurgiens::travaille;
D_relationship <Chirurgiens> est_dirig inverse Chirurgiens::dirige;
}
with filters {
temporal quipe, est_dirig;
}
interface Etablissements (extend Hpitaux_Publics, Services) {
}

2.4 Environnement
Pour supporter efficacement les processus d'analyse dcisionnelle, l'entrept de donnes doit
tre muni d'un mcanisme permettant de dfinir les parties temporelles, dont les volutions de
valeur seront conserves. En effet, les filtres associs aux classes entrept caractrisent
comment sont rsums les volutions de valeur des objets entrept, mais il est ncessaire de
dfinir dans l'entrept les parties ayant un comportement temporel homogne (priode de
rafrachissement, critres d'archivage,) Pour cela, nous proposons le concept
d'environnement pour dfinir ces parties temporelles cohrentes.
Un environnement Env est dfini par le triplet (NomEnv, CEnv, ConfigEnv) o
NomEnv est le nom identifiant l'environnement,
CEnv = {c1, c2,, cm} est l'ensemble fini des classes contenues dans l'environnement,
ConfigEnv est un ensemble de rgles de configuration, visant dfinir diffrents paramtres
locaux l'environnement (priode de rafrachissement,).
L'environnement regroupe des classes dont l'volution de valeur des objets est conserve.
Ainsi, les classes possdant un filtre sont contenues dans un environnement. Les
environnements sont disjoints, Envi, Envji,CEnviCEnvj=.
EXEMPLE : Reprenons l'exemple prcdent. Les quatre classes "Personnes", "Chirurgiens",
"Hpitaux_Publics" et "Services" possdent des filtres, ce qui oblige la cration d'au moins un
environnement. L'administrateur dfinit un seul environnement regroupant ces quatre classes.
Environment Evolutions {
class Personnes, Chirurgiens, Hpitaux_Publics, Services;
}
Remarquer que la classe "Chirurgiens" hrite du filtre temporel de la classe "Personnes", car
elles font partie du mme environnement, tandis que la classe "Jeunes_Chirurgiens", qui
n'appartient pas l'environnement "Evolutions", hrite ni du filtre temporel de "Personnes", ni
des filtres de "Chirurgiens".
L'hritage entre les classes d'un mme environnement est tendu leurs proprits temporelles
(filtres temporel et d'archives), ciCEnv, cjiCEnv, cicj TypeciTypecj
ExtensionciExtensioncj cicj cicj. Par contre, l'hritage entre deux classes
n'appartenant pas au mme environnement, ou n'appartenant pas un environnement ne
s'applique pas aux filtres, ciCEnv, cjCEnv, cicj TypeciTypecj
ExtensionciExtensioncj.
La configuration d'un environnement ConfigEnv s'effectue au travers de rgles ECA [DAYA88],
spcifies par l'administrateur, pour dfinir la gestion des objets entrept contenus dans
l'environnement. Par exemple, l'administrateur dfinit des critres d'archivage (nombre d'tats
passs et/ou dure de conservation des tats passs,) ; nous avons tudi en dtail les
configurations dans [RAVA99].
Notre concept d'environnement autorise diffrents niveaux d'historisation. Contrairement
[YANG00] qui propose le seul niveau n-uplet pour l'historisation ou [PEDE99] qui propose
d'historiser les donnes au seul niveau d'une table de dimension temps, nous proposons une
historisation des donnes trois niveaux : graphe, classe, attribut.
- Le niveau classe est le niveau intermdiaire qui consiste restreindre un environnement
une seule classe entrept. Le filtre temporel de la classe slectionne tous les attributs de la
classe, garantissant ainsi la conservation de leurs volutions. Notons que toutes les relations
impliquant la classe ne sont pas historises, l'exception des relations rflexives.
- Le niveau attribut est le niveau le plus fin qui consiste crer un environnement contenant
uniquement une classe drive. Le filtre temporel prcise les attributs temporels dont les
volutions doivent tre conserves tandis que les attributs non slectionns par le filtre ne
sont pas historiss.
- Le niveau graphe est le niveau le plus gnral o l'environnement est constitu d'un
ensemble de classes. Ce niveau permet donc de conserver les volutions des relations, en
garantissant la conservation de leurs extrmits. Les relations reliant des classes de
l'environnement sont historises, tandis que les relations reliant une classe externe
l'environnement ne le sont pas. Rappelons que l'hritage entre les classes d'un mme
environnement est tendu aux proprits temporelles des classes (filtres temporels et
d'archives), tandis que l'hritage retenu pour ce qui concerne les classes externes
l'environnement, ne concerne que l'extension et le type.

2.5 Schma de l'entrept

Un entrept se caractrise par son schma dfini comme suit.
Un schma d'entrept SED est dfini par le quadruplet (NomED, CED, EnvED, ConfigED) o
NomED est le nom de l'entrept,
CED = {c1, c2,, cn} est l'ensemble fini des classes de l'entrept,
EnvED = {env1, env2,, envp} est l'ensemble des environnements de l'entrept,
ConfigED est un ensemble de rgles de configuration, visant dfinir les diffrents paramtres
de l'entrept (priode de rafrachissement,).
Les configurations de l'entrept ConfigED, de manire analogue celles des l'environnements,
dterminent le fonctionnement de l'entrept en terme de gestion des objets entrept. Ces rgles
globales sont appliques tout l'entrept, tandis que les rgles locales un environnement sont
appliques uniquement sur l'environnement. Dans un souci de simplification nous n'abordons
pas ici cette problmatique, que nous avons tudi dans [RAVA99].
Pour garantir la cohrence du schma de l'entrept, nous introduisons une contrainte
d'intgrit, permettant de vrifier que toutes les classes, extrmits des relations drives, sont
prsentes dans l'entrept. Ainsi, le schma d'un entrept est valide si et seulement si toutes les
relations drives de la source sont dfinies dans l'entrept, ciCDW, rkRelationsci,
cjCDW | rk=(ci, cj, ) o ='' pour une association et ='' pour une composition.

2.6 Synthse
Dans cette section nous avons prsent notre modle orient objet pour les entrepts de
donnes complexes et temporelles. Nous avons dfini les composants d'un schma d'entrept
pour rpondre notre problmatique.
- Le concept d'objet entrept permet de stocker l'tat courant d'une entit, ainsi que des
tats passs (volutions dtailles) et des tats archivs (volutions rsumes). Cette
modlisation permet de conserver les donnes ainsi que leurs volutions sous une forme
pertinente avec un niveau de dtail adquat.
- Le concept de classe entrept tend le concept de classe en intgrant une fonction de
construction, un filtre temporel et un filtre d'archives afin de prendre en compte les
caractristiques volutives des objets entrept.
- Le concept d'environnement vise dfinir les parties temporelles cohrentes dans
l'entrept. Ce concept permet de dfinir trois niveaux d'historisation (graphe, classe et
attribut) et tend l'hritage aux proprits temporelles des classes.
La section suivante se propose d'tudier en dtail la fonction de construction (Mappingc)
permettant l'laboration des classes entrept.

3 Processus d'laboration de l'entrept

L'entrept de donnes stocke des informations collectes partir d'une source globale ; ce
processus vise construire le schma de l'entrept, partir de celui de la source globale. Nous
proposons un processus de construction de l'entrept dcompos en deux phases :
- Une phase d'extraction qui consiste dfinir la structure des classes entrept, en drivant
les proprits des classes source pertinentes pour les utilisateurs, et ventuellement, en
augmentant les classes entrept d'attributs calculs et de proprits spcifiques.
- Une phase de hirarchisation qui consiste organiser la hirarchie d'hritage des classes
entrept, en fonction des besoins spcifiques de l'entrept lis aux applications
dcisionnelles.

3.1 Phase d'extraction

Nous proposons de caractriser la phase d'extraction au travers d'une fonction d'extraction,
compose de fonctions de base, f1of2oofm. On dfinit les fonctions de bases fi sur cs dans c ;
par extension, cs dsigne l'ensemble des classes source, tandis que c reprsente l'ensemble des
classes entrept. Cependant, lorsque plusieurs fonctions fi composent l'extraction, on a
f1of2oofm : cc1cm-1c o i[1,m-1], ci est une classe temporaire.
Nous dfinissons les cinq fonctions de bases suivantes :
- La fonction de projection P : csc dfinit les proprits drives (de l'tat courant) de la
classe entrept, partir d'une classe source. L'ensemble des proprits, spcifies par
P={p1, p2,, pm}, est un sous ensemble des proprits de la classe source (PStructurecs).
 Extensionc={o iv| osExtensioncs, v0=[p1:os.p1,, pm:os.pm] avec i[1,m], (piP
piStructurecs)},
Attributsc={a | aP (aAttributscs (aAttributscs' | cs'Supercs))},
Relationsc={r | rP (rRelationscs (rRelationscs' | cs'Supercs))}.
- La fonction de masquage P : csc (comparable l'oprateur "hide" [ABIT91]), associe
l'ensemble de proprits P (de la classe source) non drives, dfinit la structure de la
classe entrept, compose des proprits drives de la source n'appartenant pas P.
Extensionc={o | osExtensioncs, v0=[p1:os.p1,, pp:os.pp] avec i[1,p], (piP
piStructurecs)},
Attributsc={a | aP (aAttributscs (aAttributscs' | cs'Supercs))},
Relationsc={r | rP (rRelationscs (rRelationscs' | cs'Supercs))}.
- La fonction d'accroissement PxF : csc consiste crer de nouvelles proprits dans la
structure de la classe entrept gnre. Ces proprits P={p1', p2',, pq'} sont soit calcules
(fi{count, sum, avg, max, min} ou fiComportementcs), soit spcifiques (fi est un type
connu dans l'entrept).
Extensionc={o | osExtensioncs, v0=[p1:os.p1,, pp:os.pp, p1':f1(os),, pq':fq(os)]},
Attributsc={a | aAttributscs (aAttributscs' | cs'Supercs)} {pi' | pi'P, pi' est un
attribut},
Relationsc={r | rRelationscs (rRelationscs' | cs'Supercs)} {pi' | pi'P, pi' est une
relation}.
- La fonction de slection p :csc consiste restreindre, par un prdicat de slection p,
l'extension de la classe source partir de laquelle la classe entrept est gnre.
Extensionc={o | osExtensioncs, p(os) o.v0 = os. v0},
Attributsc={a | aAttributscs (aAttributscs' | cs'Supercs)},
Relationsc={r | rRelationscs (rRelationscs' | cs'Supercs)}
- La fonction de jointure p :cs1xcs2c consiste filtrer le produit cartsien de deux
classes source avec un prdicat de jointure p.
Extensionc = {o | os1Extensioncs1, os2Extensioncs2, p(os1,os2) o.v0 = [os1.v0,
os2.v0]},
Attributsc = {a | (aAttributscs1) (aAttributscs' | cs'Supercs1) (aAttributscs2)
(aAttributscs" | cs"Supercs2) },
Relationsc = {r | (rRelationscs1) (rRelationscs' | cs'Supercs1) (rRelationscs2)
(rRelationscs" | cs"Supercs2)}.
Notons que pour l'ensemble des fonctions de base, la classe entrept gnre c n'a pas de super
classe (Superc=).
EXEMPLE : Les classes entrept "Chirurgiens", "Hpitaux_Publics" et "Services" dfinies dans
la section 2.3 sont gnres partir des fonctions suivantes.
- La classe "Chirurgiens" est gnre partir d'une slection des praticiens de la classe
source "PRATICIEN" dont la catgorie est chirurgie. La structure gnre contient toutes
les proprits de la classe source (les relations sont redfinies entre les classes de
l'entrept).
MappingChirurgiens=p.catgorie="chirurgie"(p PRATICIEN)
- La classe "Hpitaux_Publics" est construite partir d'une slection sur la classe source
"ETABLISSEMENT" des hpitaux publics. Une fonction de projection spcifie les
proprits drives ("nom", "ville", "budget", "organisation") et une fonction

iv
Un objet entrept o=(oid, S0, EP, AP) avec S0=(h0, v0) l'tat courant, EP les tats passs, AP les tats archivs.
 d'accroissement dfinit un attribut calcul ("nb_services") et un attribut spcifique
("anne_cration").
MappingHspitaux_Publics=nb_services:count(h.organisation), anne_cration:Short
h.nom, h.adresse.ville, h.budget, h.organisation
(h e.statut="public"(e ETABLISSEMENT))
- La classe "Services" est construite en filtrant le produit cartsien entre les classes source
"ETABLISSEMENT" (dont l'extension est restreinte aux hpitaux publics) et "SERVICE".
La fonction de masquage indique les proprits non drives.
MappingServices=sr.nom, sr.statut, sr.adresse, sr.budget, sr.tlphone

(sr h.organisation=s
(h e.statut="public"(e ETABLISSEMENT), s SERVICE)))

3.2 Phase de hirarchisation

L'entrept de donnes doit tre organis en fonction des applications dcisionnelles. La phase
de hirarchisation consiste organiser la hirarchie d'hritage dans entrept, en crant des super
classes, et des sous classes entrept.
Lors de l'extraction, les classes entrept rsultat ne sont pas organises suivant une hirarchie
d'hritage (Superc=). Nous introduisons deux nouvelles fonctions visant gnraliser et
spcialiser les classes entrept.
- La fonction de gnralisation P:c1xc2xxcnc0 consiste gnrer, partir d'une ou
plusieurs classes, une super classe regroupant l'ensemble P={p1, p2,, pm} des proprits
communes aux classes, spcifies par l'administrateur.
n

Extensionc0={o|o' Extension cj
, o.v0=[p1:o'.p1,, pm:o'.pm], piP},
j 1

Structurec0={p|p Structure cj
pP},
j 1

Superc0={c|c Super cj
},
j 1

i[1..n], Structureci={p|pStructurecipP},
Superci={c|cSupercic Super cj }{c0}.
ji

- La fonction de spcialisation p: c1xc2xxcnc0 consiste gnrer une sous classe

partir d'une ou plusieurs classes.
Extensionc0={o|o1Extensiono1,, onExtensionon, p(o1,on) o.v0=[o1.v0,,
on.v0]},
n

Structurec0={p|p Structure cj
},
j 1

Superc0={c1, c2,,cn}.
EXEMPLE : Les classes entrept "Personnes", "Jeunes_Chirurgiens" et "Etablissements"
dfinies dans la section 2.3 sont gnres partir des fonctions de spcialisation et de
gnralisation suivantes.
- La super classe "Personnes" regroupe les attributs "nom", "prnom", "adresse" et
"anne_naissance" de la sous classe "Chirurgiens".
MappingPersonnes = c.nom, c.prnom, c.adresse, c.anne_naissance(c Chirurgiens)
- La sous classe "Jeunes_Chirurgiens" spcialise la classe "Chirurgiens". Elle regroupe les
jeunes chirurgiens dont la date de naissance est suprieure 1970.
MappingJeunes_Chirurgiens = c.anne_naissance1970(c Chirurgiens)
- La classe "Etablissements" spcialise les super classes "Hpitaux_Publics" et "Services", en
contenant les tablissements hospitaliers situs dans la ville de Toulouse.
MappingEtablissements = e.organisation=s
(e h.adresse.ville="Toulouse"(h Hpitaux_Publics), s Services)

4 Implantation
Dans l'optique de valider nos propositions, nous avons dvelopp un prototype, appel
GEDOOH v, acronyme de Gnrateur d'Entrepts de Donnes Orientes Objet et Historises
[BRET99] [RAVA99]. Ce prototype se propose d'aider l'administrateur laborer le schma
d'un entrept de donnes. Il se compose de deux modules principaux.
- Une interface graphique visualisant le schma de la source globale ainsi que celui de
l'entrept,
- Un gnrateur d'entrepts fournissant automatiquement les scripts de cration de
l'entrept, ainsi que les scripts de chargement initial et de rafrachissement des donnes.
GEDOOH

A dm inistrateur
IN T E R F A C E GENERATEUR
G R A P H IQ U E dE N T R E P T S
R M agasin
E
I S
N T
S ource O2
T R M agasin
E U
G R frentiel C
S ource
R Initialisation C reation
des T
. A M ta-donnes R afrachissem ent U
. T M agasin
R
. I A

...
O T
S ource N I
O
N M agasin
E n trep t
S ource G lobale extractions

figure 4 : Architecture du prototype GEDOOH.

Notre outil facilite la tche de l'administrateur pour construire et gnrer des entrepts de
donnes en proposant :
- Une reprsentation graphique des schmas de la source et de l'entrept.
- Une laboration du schma de l'entrept incrmentalle et ergonomique grce un ensemble
de fentres de saisie et de menus.
- Une simplification des lments affichs, tels que les environnements (reprsents par un
double rectangle englobant les classes et les relations lui appartenant). Notons que les filtres
temporels et d'archives sont explicitement reprsentes ; le symbole ' ' dfinit une
proprit appartenant au filtre temporel et le symbole ' ' dfinit une proprit appartenant
au filtre d'archives.
- Une gnration automatique ( partir de la dfinition graphique du schma de l'entrept)
des scripts de cration, d'alimentation et de rafrachissement de l'entrept dans le systme
de gestion de base de donnes orientes objet (SGBDOO) hte.
GEDOOH est un prototype oprationnel, implant au dessus du SGBDOO O2. Il comporte
approximativement 5000 lignes de code Java (jdk 1.2) pour l'interface et le gnrateur tandis
que le rfrentiel des mta-donnes implant dans O2, comprend environ 20 classes et
reprsente 1500 lignes de code O2C.

v
http://www.irit.fr/SSI/ACTIVITES/EQ_SIG/gedooh.html
 Fentre Entrept

Fentre Source Globale

figure 5 : Interface GEDOOH.

5 Conclusion
Nous avons propos une architecture pour les systmes d'aide la dcision, fonde sur
l'approche des entrepts de donnes et distinguant diffrentes problmatiques de recherche. Cet
article tudie plus particulirement l'lment central de notre architecture : l'entrept de
donnes.
Premirement, nous avons prsent un modle d'entrept de donnes complexes et temporelles,
bas sur le paradigme objet. Les principales contributions de notre modle sont :
- Le concept d'objet entrept qui modlise l'tat courant d'un objet source extrait, ainsi que
des tats passs (reprsentant les volutions de l'objet sous une forme dtaille) et des tats
archivs (correspondant aux volutions de l'objet dcrites sous une forme rsume).
L'intrt de cette modlisation est de conserver les donnes de l'entrept ainsi que leurs
volutions un niveau de dtail pertinent.
- Le concept de classe entrept qui tend le concept de classe en intgrant les caractristiques
de notre approche par une fonction de construction, un filtre temporel et un filtre d'archives.
- Le concept d'environnement qui permet de dfinir simplement les parties temporelles
homognes dans le schma de l'entrept. L'administrateur dispose de trois niveaux
d'historisation (graphe, classe et attribut) pour spcifier les parties temporelles de l'entrept
dans une taille adapte aux besoins des applications de l'entrept.
Dans un second temps, nous avons propos un processus d'laboration de l'entrept, partir
d'un schma de source globale. Ce processus repose sur
- des fonctions (projection, masquage, augmentation, slection, jointure) visant dfinir les
structures de l'entrept et
- des fonctions (spcialisation, gnralisation) permettant d'organiser la hirarchie d'hritage
des classes entrept.
L'ensemble de notre proposition est implante au dessus du SGBDOO O2 dans le prototype
GEDOOH [BRET99] [RAVA99]. Il permet de dfinir graphiquement le schma de l'entrept
partir d'une reprsentation graphique de la source. Il gnre les scripts de cration des structures
de l'entrept ainsi que les scripts de chargement initial et de rafrachissement des donnes de
l'entrept.
Notre processus d'laboration de l'entrept n'intgre pas le comportement des classes. A l'heure
actuelle, nous tudions le processus d'extraction automatique des mthodes. Ce processus
ncessite d'analyser et de redfinir la signature et le corps des mthodes drives dans
l'entrept. Par ailleurs, il est indispensable de proposer un langage de manipulation des
lments de notre entrept. Ce langage doit englober une extension temporelle d'OQL
[FAUV99] et prendre en compte les caractristiques de nos objets entrept.

6 Remerciements
Je tiens remercier Monsieur Franck Ravat, matre de confrences et membre 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 m'apportent.

7 Rfrences
[AGRA97] Agrawal R., Gupta A., Sarawagi A., "Modeling Multidimensional Databases",
ICDE'97.
[BERT98] Bertino E., Ferrari E., Guerrini G., Merlo I., "Extending the ODMG Object
Model with Composite Objects", OOPSLA'98, Vancouver (Canada), 1998.
[BRET99] Bret F., Teste O., "Construction Graphique d'Entrepts et de Magasins de
Donnes", INFORSID'99, La Garde (France), Juin 1999.
[BRET00] Bret F., Soule-Dupuy C., Zurfluh G., "Outil mthodologique pour la conception
de bases de donnes dcisionnelles orientes objet", LMO'00, St Hilaire
(Canada), Jan. 2000.
[BUKH93] Bukhres O.A., Elmagarmid A.K., "Object-Oriented Multidatabase Systems A
solution for Advanced Applications", Prentice Hall, ISBN 0-13-103813-2, 1993.
[CATT95] Cattel R.G.G, "ODMG-93 Le Standard des bases de donnes objet", Thomson
publishing, ISBN 2-84180-006-7, 1995.
[CHAU97] Chaudhuri S., Dayal U., "An Overview of Data Warehousing and OLAP
Technology", ACM SIGMOD Record, 26(1), 1997.
[CODD93] Codd E.F., Providing OLAP (on-line analytical processing) to user-analysts: an
IT mandate, Technical Report EF Codd and Associate, 1993.
[DAYA88] Dayal U., Blaustein B. T., Buchmann A. P., Chakravarthy U. S., Hsu M., Ledin
R., McCarthy D. R., Rosenthal A., Sarin S. K., Carey M. J., Livny M., Jauhari
R., "The HiPAC Project: Combining Active Databases and Timing Constraints",
ACM SIGMOD Record, 17(3), Chicago (Illinois, USA), 1988.
[FAUV99] Fauvet M.C., Dumas M., Scholl P-C., "A representation-independent temporal
extension of ODMG's Object Query Language", BDA'99, Bordeaux, Oct. 1999.
[FAYY96] Fayyad U.M., Piatetsky-Shapiro G., Smyth P., Uthurusamy R., "Advances in
Knowledge Discovery and Data Mining", AAAI Press, ISBN 0-262-56097-6,
1996.
[GATZ99] Gatziu S., Jeusfeld M.A., Staudt M., Vassiliou Y., "Design and Management of
Data Warehouses", Report on the DMDW'99, ACM SIGMOD Record, 28(4),
Dec. 1999.
[GORA98] Goralwalla I.A., zsu M.T., Szafron D., "An Object-Oriented Framework for
Temporal Data Models", LNCS Temporal DBs, ISBN 3-540-64519-5.
[GUPT95] Gupta A., Mumick I.S., "Maintenance of Materialized Views: Problems,
Techniques, and Applications", IEEE Data Engineering Bulletin, 1995.
[GYSS97] Gyssen M., Lakshmanan L.V.S., "A Foundation for Multi-Dimensional
Databases", VLDB'97, Athens (Greece), 1997.
[HYUN97] Hyun N., "Multiple-View Self-Maintenance in Data Warehousing
Environments", VLDB'97, Athens, 1997.
[INMO96] Inmon W.H., "Building the Data Warehouse", John Wiley&Sons, ISBN 0471-
14161-5.
[JARK99] Jarke M., Lenzerini M., Vassiliou Y., Vassiliadis P., "Fundamentals of Data
Warehouses", Ed. Springer Verlag, ISBN 3-540-65365-1, 1999.
[KOTI99] Kotidis Y., Roussopoulos N., "DynaMat: A Dynamic View Management System
for Data Warehouses", ACM SIGMOD'99.
[LABI97] Labio W.J., Zhuge Y., Wiener J.L., Gupta H., Garcia-Molina H., Widom J.,
"The WHIPS Prototype for Data Warehouse Creation and Maintenance",
SIGMOD, 1997.
[LAPU97] Lapujade A., Ravat F., "Conception de systmes d'information multimdia
rpartie : Application au milieu hospitalier", INFORSID'97, Toulouse, 1997.
[LEHN98] Lehner W., Albrecht J., Wedekind H., "Normal forms for multidimensional
databases", SSDBM'98, pp.63-72, 1998.
[PEDE99] Pedersen T.B., Jensen C.S, "Multidimensional Data Modeling for Complex
Data", ICDE'99, march 1999.
[RAVA00] Franck Ravat, Olivier Teste, "Object-Oriented Decision Support System", To be
appeared in the proceedings of ICEIS'00, July 4-7 2000, Stafford (UK).
[RAVA99] Ravat F., Teste O., Zurfluh G., "Towards the Data Warehouse Design", ACM
CIKM'99, Kansas City (Kansas, USA), Nov 1999.
[RAVA96] Ravat F., "La fragmentation d'un schma conceptuel orient objet", Ingnierie
des systmes d'information, Vol 4, n2, pp161-193, 1996.
[SAMO97] Samos J., Saltor F., Sistrac J., Bards A., "Database Architecture for Data
Warehousing: An evolutionary Approach", DEXA'98, Vienna (Austria), 1998.
[THEO98] Theodoratos D., Sellis T., "Data Warehouse Schema and Instance Design",
ER'98, Singapore, 1998.
[THEO99] Theodoratos D., Ligoudistianos S., Sellis T., "Designing the global data
warehouse with SPJ views", CAISE'99, Heidelberg (Germany), June, 1999.
[WANG97] Wang X.S., Bettini C., Brodsky A., Jajodia S., "Logical design for temporal
databases with multiple granularities", ACM TODS, 22(2), 1997.
[WIDO95] J. Widom, "Research problems in data warehousing", ACM CIKM'95, 1995.
[YANG00] Yang J., Widom J., "Temporal View Self-Maintenance in a Warehousing
Environment", EDBT'00, Konstanz (Germany), March 2000.
[ZHUG95] Y. Zhuge, H. Garcia-Molina, J. Hammer, J. Widom, "View Maintenance in a
Warehousing Environment", SIGMOD Record, San Jose (USA), 1995.