Académique Documents
Professionnel Documents
Culture Documents
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.
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
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.
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.
Figure 3.
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.
Figure 4.
(a)
(b)
Figure 5.
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.
Monde Rel
BD
Classique
Entrept de Donnes
t1
t2
dernier tat
de lobjet
t3
entit
tats successifs
de l objet
temps
Figure 7.
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.
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.
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=.
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
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
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
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
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
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"
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 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.
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
ANDO91
ANDO97
BELL98
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
CHAU97
CODD93
COLL96
GARD93
GOLF98
GRAY96
GUPT95
GYSS97
INMO96
W.H. Inmon, Building the Data Warehouse , second edition, Wiley Computer
Publishing, USA.
JARK98
LEHN98
RAVA96
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
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
TEST99
UML97
UML version 1.0 . Rational Software Corporation, 13 January 1997, Santa Clara
(USA).
VADA93
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
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
YANG98
ZHAO97
ZHUG95