These - Conception Et Réalisation D'un Data Warehouse Pour La Mise en Place D'un Système Décisionnel

Entrep
ots de donn
ees pour laide `
a la d
ecision m
edicale:
conception et exp
erimentation
Serna Encinas Mara Trinidad
To cite this version:

Serna Encinas Mara Trinidad. Entrepots de donnees pour laide a` la decision medicale: conception et experimentation. Networking and Internet Architecture. Universite Joseph-Fourier
- Grenoble I, 2005. French. <tel-00184256>
HAL Id: tel-00184256

https://tel.archives-ouvertes.fr/tel-00184256
Submitted on 30 Oct 2007
HAL is a multi-disciplinary open access

archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
Larchive ouverte pluridisciplinaire HAL, est

destinee au depot et `a la diffusion de documents
scientifiques de niveau recherche, publies ou non,
emanant des etablissements denseignement et de
recherche francais ou etrangers, des laboratoires
publics ou prives.
UNIVERSIT JOSEPH FOURIER
THSE
pour obtenir le grade de
Docteur de lUniversit Joseph Fourier
Spcialit : Informatique
prpare au laboratoire LSR IMAG
dans le cadre de lcole Doctorale
Mathmatiques, Sciences et Technologies de lInformation
prsente et soutenue publiquement par
Mara Trinidad Serna Encinas

Le 27 Juin 2005
Entrepts de donnes pour laide la

dcision mdicale :
conception et exprimentation
Composition du jury
Mme. Christine Collet,
Mme. Anne Doucet,
M. Mokrane Bouzeghoub,
M. Jacques Demongeot,
M. Ren Ecochard,
M. Michel Adiba,
Prsident
Rapporteur
Rapporteur
Examinateur
Examinateur
Directeur de thse
Remerciements
Je tiens remercier Anne Doucet, professeur lUniversit Pierre et Marie Curie de Paris (LIP6), et Mokrane Bouzeghoub, professeur lUniversit de Versailles
(PRiSM), pour avoir accept dtre rapporteur et pour leurs commentaires et critiques constructives qui mont apport un regard clairant sur les contributions de
cette thse. Je remercie aussi Jacques Demongeot, professeur lInstitut dIngnierie de lInformation de Sant de Grenoble (TIMC), et Ren Ecochard, professeur au
Service de Biostatistique de Lyon (LBBE), davoir accept de faire partie de mon
jury.
Je remercie trs sincrement Christine Collet, professeur lEcole Nationale Suprieure dInformatique et de Mathmatiques Appliques de Grenoble (ENSIMAG)
et responsable du projet NODS, pour mavoir accueilli dans son quipe et pour
lhonneur quelle ma fait en prsidant le jury de thse.
Jexprime ma profonde gratitude Michel Adiba, professeur lUniversit Joseph
Fourier de Grenoble (UJF), pour la conance quil ma toujours tmoign, ainsi que
pour ses conseils, ses encouragements et sa patience. Jose dire que vous devenez
mon ami.
Je remercie galement Claudia Lucia Roncancio, professeur lEcole Nationale
Suprieure dInformatique et de Mathmatiques Appliques de Grenoble (ENSIMAG), pour son aide, ses suggestions et principalement, pour son amiti.
Je tiens aussi remercier aux membres et collaborateurs de lquipe STORM,
Genoveva Vargas-Solar, Cyril Labbe, Fabrice Jouanot, Christophe Bobineau, Khalid Belhajjame, Edgar Benitez, Tran-Kien Cao, Laurent dOrazio, Levent Gurgen,
Nagapraveen Jayaprakash, Thi-Huong-Giang Vu et Hanh Tan, pour la disponibilit
quils ont eue pendant la ralisation de ce travail.
Merci tous les membres du Laboratoire Logiciels, Systmes, Rseaux de lIMAG,
en particulier aux quipes administratives (Liliane Di Giacomo, Martine Pernice,
Pascale Poulet et Carol Pasanisi) qui mont toujours aide dans les dmarches
suivre.
Jadresse mes plus vifs remerciements Gennaro Bruno, Hctor Manuel Prez
Urbina, Maria del Pilar Villamil, Sonia Mendoza-Chapa, Edicarsia Barbiero, Julio
Moreno, Irma Ramirez, Patricia Quintero, Norma Pacheco, Sonia Meneses, Carmen
Villarreal, Daniel Prez et Francisca Lorena Zepeda, pour avoir partag cette aventure avec moi et mavoir toujours soutenue pendant les moments les plus diciles
de cette thse. Pour moi, vous tes dj une partie de ma famille.
Je remercie ma mre, qui toujours ma soutenue, mes soeurs et mes frres, pour
leur amour inconditionnel et sans limites, pour leurs encouragements et pour leurs
conseils. Je tiens remercier spcialement Migdia, Carmen, Rosa, et Juan, qui ont
toujours cru en moi et qui mont soutenue tout ou long de ce travail.
A mes lles, dont lexistence donne un sens ma vie. Tous mes remerciements
sont vous. Vous tes la raison pour laquelle je me lve tous les jours de ma vie.
Pour ustedes, yo me levanto todos los dias de mi vida.
A mon pre, o quil soit. A mi padre, donde quiera que est.
Table des matires

1 Introduction
1.1 Les entrepts de donnes pour laide la dcision . . . . . . . . . . .
1.2 Le projet ADELEM : Aide la Dcision Logistique et Mdicale . . .
1.3 Problmatique et objectif de la thse . . . . . . . . . . . . . . . . . .
1.3.1 Conception dun systme pour le dcisionnel . . . . . . . . . .
1.3.2 Slection des vues matrialiser . . . . . . . . . . . . . . . . .
1.3.3 Gestion de lvolution des entrepts . . . . . . . . . . . . . . .
1.3.4 Objectif de la thse . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Dmarche et contribution . . . . . . . . . . . . . . . . . . . . . . . .
1.4.1 Mtamodle multidimensionnel . . . . . . . . . . . . . . . . .
1.4.2 Algorithme pour la slection des vues matrialiser . . . . . .
1.4.3 Interface pour la gnration (semi-automatique) des indicateurs
1.4.4 Versions de schmas bitemporels . . . . . . . . . . . . . . . . .
1.5 Plan de la thse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2
3
6
6
8
9
10
10
10
11
11
11
12
2 Entrepts de donnes multidimensionnelles et aspects temporels

2.1 Entrepts de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Architecture dun entrept de donnes . . . . . . . . . . . . .
2.1.2 Entrepts et les bases de donnes . . . . . . . . . . . . . . . .
2.2 Modlisation multidimensionnelle . . . . . . . . . . . . . . . . . . . .
2.2.1 Schmas relationnels . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 Schma multidimensionnel (Cube) . . . . . . . . . . . . . . . .
2.3 Manipulation des donnes multidimensionnelles . . . . . . . . . . . .
2.3.1 Oprations classiques . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 Oprations agissant sur la structure . . . . . . . . . . . . . . .
2.3.3 Oprations agissant sur la granularit . . . . . . . . . . . . . .
2.4 Serveurs OLAP (On-Line Analytical Processing) . . . . . . . . . . . .
2.4.1 ROLAP (Relational OLAP) . . . . . . . . . . . . . . . . . . .
2.4.2 MOLAP (Multidimensional OLAP) . . . . . . . . . . . . . . .
2.4.3 HOLAP (Hybrid OLAP) . . . . . . . . . . . . . . . . . . . . .
2.5 Les projets de recherche . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.1 WHIPS Warehouse Information Prototype at Stanford . . . . .
2.5.2 SIRIUS Supporting the Incremental Refreshment of Information warehouses . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.3 DWQ Foundations of Data Warehouse Quality . . . . . . . . .
15
15
15
17
18
20
22
23
23
24
27
27
28
30
32
34
34
35
35
ii
2.6
2.7
2.5.4 Projet EVOLUTION . . . . . . . . . . . . . . . . . .

Aspects temporels des entrepts . . . . . . . . . . . . . . . .
2.6.1 Etat courant des versions . . . . . . . . . . . . . . . .
2.6.2 Espace de versions . . . . . . . . . . . . . . . . . . .
2.6.3 Versions bases sur ltat et sur les changements . . .
2.6.4 Graphes de version . . . . . . . . . . . . . . . . . . .
2.6.5 Gestion de versions extensionnelles et intensionnelles
2.6.6 Oprations primitives . . . . . . . . . . . . . . . . . .
Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
37
38
43
44
45
46
47
47
3 Architecture et modle pour un entrept de donnes mdicales

3.1 Architecture dun systme dcisionnel . . . . . . . . . . . . . . . . . .
3.1.1 Interface graphique pour la Gnration (Semi - automatique)
dIndicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2 Entrept de donnes . . . . . . . . . . . . . . . . . . . . . . .
3.1.3 Gestionnaire dEvolution . . . . . . . . . . . . . . . . . . . . .
3.2 Mtamodle Multidimensionnel . . . . . . . . . . . . . . . . . . . . .
3.2.1 Relations entre les mtaclasses . . . . . . . . . . . . . . . . . .
3.2.2 Contraintes entre les mtaclasses . . . . . . . . . . . . . . . .
3.2.3 Description des Mtaclasses . . . . . . . . . . . . . . . . . . .
3.2.4 Dnition dun modle multidimensionnel . . . . . . . . . . .
3.3 Analyse des donnes dune application mdicale . . . . . . . . . . . .
3.3.1 Sources de donnes . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2 Analyse des donnes . . . . . . . . . . . . . . . . . . . . . . .
3.4 Classication des indicateurs du projet . . . . . . . . . . . . . . . . .
3.4.1 Indicateurs dore (gographiques - spatio-temporels) . . . . .
3.4.2 Indicateurs de consommation, de besoins et de ux (temporels)
3.4.3 Nouveaux indicateurs de consommation et de ux (temporels)
3.5 Application du modle multidimensionnel dans le cadre du projet . .
3.5.1 Schma en constellation pour ADELEM . . . . . . . . . . . .
3.5.2 Hirarchies du schma . . . . . . . . . . . . . . . . . . . . . .
3.5.3 Description du schma Prise_MCO et de ses dimensions . . . .
3.5.4 Description du schma Population et de ses dimensions . . . .
3.5.5 Description du schma Prise_SSR et de ses dimensions . . . .
3.6 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
50
4 Systme daide la dcision mdicale : une exprimentation

4.1 Construction du schma . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Schma en toile Adelem_MCO . . . . . . . . . . . . . . . . . .
4.1.2 Matrialisation de lHypercube . . . . . . . . . . . . . . . .
4.2 Vues matrialises . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Slection des vues matrialiser . . . . . . . . . . . . . . . .
4.2.2 Algorithme propos pour la slection des vues matrialiser
4.2.3 Gnration des vues matrialises . . . . . . . . . . . . . . .
75
76
76
77
79
80
84
88
.
.
.
.
.
.
.
50
51
51
51
52
53
53
54
59
59
61
62
63
63
64
65
65
66
67
70
71
72
iii
4.3
4.4
Interface graphique pour la Gnration (semi-automatique) dIndicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3.1 Architecture pour linterface graphique . . . . . . . . . . . .
4.3.2 Fonctionnement de linterface . . . . . . . . . . . . . . . . .
4.3.3 Types de requtes excuter . . . . . . . . . . . . . . . . . .
4.3.4 Fonctionnement de linterface graphique . . . . . . . . . . .
Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Aspects temporels et versions de schmas dans les entrepts

5.1 Versions de schmas . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 Versions de schmas annuels dans un contexte mdical .
5.1.2 Reprsentation bitemporelle des versions de schmas . .
5.2 Les oprations primitives . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Ensemble de primitives . . . . . . . . . . . . . . . . . . .
5.2.2 Ensemble de restrictions . . . . . . . . . . . . . . . . . .
5.3 Dnition formelle des primitives . . . . . . . . . . . . . . . . .
5.3.1 Gestion de la relation (cube, dimension ou hirarchie) . .
5.3.2 Gestion des versions . . . . . . . . . . . . . . . . . . . .
5.4 Gestion temporelle des entrepts . . . . . . . . . . . . . . . . .
5.4.1 Architecture simplie du projet . . . . . . . . . . . . . .
5.4.2 Modle de versions de schmas bitemporels . . . . . . . .
5.4.3 Gestionnaire dvolution de schmas . . . . . . . . . . .
5.5 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 Conclusions et perspectives
6.1 Bilan du travail ralis . . . . . . . . . . . . . . . . . . . .
6.1.1 Principales contributions . . . . . . . . . . . . . . .
6.1.2 Dnition dun modle multidimensionnel . . . . .
6.1.3 Algorithme pour la slection des vues matrialiser
6.1.4 Gnration (semi-automatique) des requtes . . . .
6.1.5 Versions de schmas bitemporels . . . . . . . . . . .
6.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Extension du prototype . . . . . . . . . . . . . . .
6.2.2 Aspects spatiaux des donnes . . . . . . . . . . . .
6.2.3 Construction et rafrachissement de donnes . . . .
6.2.4 Grille de donnes . . . . . . . . . . . . . . . . . . .
A Description des sources de donnes
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
90
91
92
94
95
98
.
.
.
.
.
.
.
.
.
.
.
.
.
.
101
. 102
. 102
. 103
. 105
. 105
. 105
. 107
. 108
. 115
. 116
. 117
. 117
. 119
. 122
.
.
.
.
.
.
.
.
.
.
.
125
. 125
. 125
. 125
. 126
. 127
. 127
. 128
. 128
. 129
. 131
. 132
145
iv
Table des figures

1.1
1.2
1.3
Architecture gnrale dun systme dcisionnel . . . . . . . . . . . . .

Tous les tablissements au niveau national . . . . . . . . . . . . . . .
Gestion de lvolution du schma dans un entrept . . . . . . . . . .
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
Architecture dun entrept de donnes . . .

Exemple de modlisation en toile. . . . . .
Exemple de modlisation en ocon de neige.
Exemple de modlisation en constellation. .
Exemple de schma multidimensionnel. . . .
Exemple de lopration Jointure. . . . . . . .
Architecture ROLAP. . . . . . . . . . . . . .
Architecture MOLAP. . . . . . . . . . . . .
Architecture HOLAP. . . . . . . . . . . . . .
Espace des changements . . . . . . . . . . .
Graphes de version un niveau . . . . . . .
Graphe de version deux niveaux . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
20
21
22
23
25
29
30
33
44
45
46
3.1 Architecture propose dun systme dcisionnel . . . . .

3.2 Mtamodle Multidimensionnel . . . . . . . . . . . . . .
3.3 Schma et une instance possible du Cube . . . . . . . . .
3.4 Schma et une instance possible de la hirarchie H_Geo
3.5 Schma en Constellation pour ADELEM . . . . . . . . .
3.6 Hirarchies de la dimension x . . . . . . . . . . . . . . .
3.7 Schma en ocon de neige Prise_MCO . . . . . . . . . . .
3.8 Schma en ocon de neige Population . . . . . . . . . . .
3.9 Schma en ocon de neige Prise_SSR . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
50
52
56
58
66
67
68
70
71
4.1 Schma en toile Adelem_MCO . . . . . . . . . . .

4.2 Hypercube avec le cot de calcul ( gauche) et le
droite) de chaque noeud (vue) . . . . . . . . . .
4.3 Algorithme Greedy [HRU95] . . . . . . . . . . .
4.4 Ensemble ordonn des vues slectionnes . . . .
4.5 Algorithme propos . . . . . . . . . . . . . . . .
4.6 Ensemble ordonn des vues slectionnes . . . .
4.7 Architecture pour linterface graphique . . . . .
4.8 Cration dune dimension . . . . . . . . . . . .
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
5
9
. . . . . . . . . . .
cot de stockage (
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. 76
.
.
.
.
.
.
.
79
82
83
86
87
91
93
vi
4.9
4.10
4.11
4.12
Structure de la dimension . . . . . . . . . . . . . . . . . . . .
Interface pour la gnration (semi-automatique) dindicateurs
Rsultat de lexcution de la requte Q4 . . . . . . . . . . . .
Fichier Requete.REL . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
94
96
97
98
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
Trois versions de schmas annuels. . . . . . . . . . . . . . . . . . .

Reprsentation bitemporelle des versions de schmas. . . . . . . .
Insertion du niveau District la Hirarchie H_Geo. . . . . . . .
Rsultat dliminer le niveau Departement la Hirarchie H_Geo.
Interaction des composants lintrieur de larchitecture. . . . . .
Modle de versions de schmas bitemporels. . . . . . . . . . . . .
Gestionnaire dvolution de schmas. . . . . . . . . . . . . . . . .
Gestion dvolution de schmas par niveau. . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
102
103
113
114
117
118
120
120
6.1
6.2
Reprsentation du mode vecteur et rasteur . . . . . . . . . . . . . . . 131

Architecture des systmes pour lintgration de donnes . . . . . . . . 132
Liste des tableaux

2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
Dirences entre SGBD et entrepts de

Comparaison des systmes . . . . . . .
Ventes par magasin . . . . . . . . . . .
Prix des produits . . . . . . . . . . . .
Ventes de produits par ville 1 . . . . .
Ventes de produits par ville 2 . . . . .
Ventes du Dpartement Isre . . . . . .
Table de ventes du Magasin 1 . . . . .
Exemple de relation bitemporelle . . .
donnes
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
3.1
3.2
Description des sources de donnes . . . . . . . . . . . . . . . . . . . 61

Caractristiques des sources de donnes historiques . . . . . . . . . . 62
4.1
4.2
4.3
4.4
4.5
Liste de relations de base . . . . . . . . . . . . . . . . . . .

Matrialisation complte de lhypercube . . . . . . . . . .
Application de lalgorithme Greedy aux donnes ADELEM
Application de notre algorithme aux donnes ADELEM . .
Ensemble minimal des vues matrialiser . . . . . . . . .
5.1
5.2
Primitives pour la gestion de relation . . . . . . . . . . . . . . . . . . 106

Primitives pour la gestion des versions . . . . . . . . . . . . . . . . . 106
A.1
A.2
A.3
A.4
Description
Description
Description
Description
des variables du chier RSA .

de variables du chier RSA . .
de variables du chier FINESS
de variables du chier FINESS
vii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
19
24
24
25
25
25
26
26
26
42
77
78
82
86
88
148
149
151
152
viii
Chapitre 1
Introduction
Les entrepts de donnes intgrent les informations en provenance de direntes
sources, souvent rparties et htrognes et qui ont pour objectif de fournir une vue
globale de linformation aux analystes et aux dcideurs. Ces applications daide la
dcision sont de type OLAP (On-Line Analytical Processing ou Analyse en ligne).
La construction et la mise en oeuvre dun entrept de donnes reprsentent une
tche complexe qui se compose de plusieurs tapes. La premire consiste lanalyse
des sources de donnes et lidentication des besoins des utilisateurs. La deuxime
correspond lorganisation des donnes lintrieur de lentrept. Finalement, la
troisime consiste tablir divers outils dinterrogation (danalyse, de fouille de
donnes ou dinterrogation). Chaque tape prsente des problmatiques spciques.
Ainsi, par exemple, lors de la premire tape, la dicult principale consiste en lintgration des donnes, de manire quelles soient de qualit pour leur stockage.
Pour lorganisation, ils existent plusieurs problmes comme : la slection des vues
matrialiser, le rafrachissement de lentrept, la gestion de lensemble de donnes
(courantes et historises), entre autres. En ce qui concerne le processus dinterrogation, nous avons besoin des outils performants et conviviaux pour laccs et lanalyse
de linformation.
Notre travail se focalise principalement sur les deux dernires tapes, ainsi, pour le
processus dorganisation, nous proposons la dnition dun modle multidimensionnel, un algorithme pour la slection optimale des vues matrialiser et lutilisation
des versions de schmas bitemporels pour la gestion des aspects temporels des entrepts. Pour linterrogation, nous avons dvelopp une interface graphique qui permet
la gnration semi-automatique des indicateurs. Dans les chapitres suivants, nous
dployons chacune de nos propositions.
Cette thse a eu pour cadre un projet mdical. Ainsi, dans ce chapitre nous
prsentons dabord une introduction des entrepts dans le milieu mdical et un
rsum du projet ADELEM (Aide la Dcision Logistique et Mdical). Ensuite,
nous prsentons la problmatique et lobjectif de la thse et pour nir, nous exposons
la dmarche suivie et notre contribution.
1
Introduction
1.1
Les entrepts de donnes pour laide la dcision
La dnition classique dun entrept donne par [IH94] :

"Un Entrept de Donnes est une collection de donnes orientes sujet, intgres, non volatiles et historises, organises pour le support dun
processus daide la dcision".
Nous dtaillons ces caractristiques [Fra97, DG01] :
orientes sujet : Les donnes des entrepts sont organises par sujet plutt que
par application. Par exemple, une chane de magasins dalimentation organise les
donnes de son entrept par rapport aux ventes qui ont t ralises par produit et
par magasin, au cours dun certain temps.
intgres : Les donnes provenant des direntes sources doivent tre intgres,
avant leur stockage dans lentrept de donnes. Lintgration (mise en correspondance des formats, par exemple), permet davoir une cohrence de linformation.
non volatiles : A la dirence des donnes oprationnelles, celles de lentrept
sont permanentes et ne peuvent pas tre modies. Le rafrachissement de lentrept,
consiste ajouter de nouvelles donnes, sans modier ou perdre celles qui existent.
historises : La prise en compte de lvolution des donnes est essentielle pour la
prise de dcision qui, par exemple, utilise des techniques de prdiction en sappuyant
sur les volutions passes pour prvoir les volutions futures.
La construction dun entrept revient faire correspondre les besoins des utilisateurs avec la ralit des informations disponibles. Nous devons dabord identier
et analyser les sources de donnes, ce qui nous permet de proposer les mcanismes
adapts selon les caractristiques des informations. Ensuite, nous devons organiser lensemble de donnes lintrieur de lentrept. Pour cela, nous devons dabord
structurer ces informations en considrant leur granularit. Ceci nous permet daboutir la conception dun schma multidimensionnel qui permet de rpondre aux besoins des utilisateurs.
La gure 1.1 montre une architecture gnrale dun systme dcisionnel qui se
compose de trois processus : extraction-intgration, organisation et interrogation.
Nous trouvons le processus dextraction-intgration entre les sources de donnes
et lentrept. Ce processus est responsable de lidentication des donnes dans les
diverses sources internes et externes ; de lextraction de linformation qui nous intresse et de la prparation et de la transformation (nettoyage, ltrage,...) des donnes.
1.2 Le projet ADELEM : Aide la Dcision Logistique et Mdicale
E
X
T
R
A
C
T
I
O
N
Sources de donnes
O
R
G
A
N
I
S
A
T
I
O
N
Entrept
de
donnes
I
N
T
E
R
R
O
G
A
T
I
O
N
Outils
Fig. 1.1 Architecture gnrale dun systme dcisionnel
A lintrieur de lentrept, nous trouvons le processus dorganisation, il est responsable de structurer les donnes par rapport leur niveau de granularit (agrgats).
Finalement, le troisime processus correspond linterrogation qui se place entre
lentrept et les dirents outils pour arriver lanalyse des donnes, pour les dirents utilisateurs de lentreprise.
Malgr une conception attentive et soigneuse, la structure dune base de donnes
est sujette de nombreux changements. Bien que les estimations dirent, la plupart
saccordent sur le fait que plus de 50% du travail des dveloppeurs se focalise sur les
modications du systme aprs leur implantation [Rod95]. Ces changements peuvent
aecter aussi bien les donnes que leur structure. En eet, lvolution dun schma
concerne tout le cycle de vie dun entrept de donnes. Un de premiers travaux dans
ce contexte est [HMV99a, HMV99b], o les auteurs proposent des oprateurs pour
lvolution des dimensions.
1.2
Le projet ADELEM : Aide la Dcision Logistique et Mdicale
Cette thse a eu pour cadre le projet ADELEM1 qui consiste en la mise au point
doutils logiciels ncessaires laide la dcision logistique et mdicale, dans le cadre
des SROS (Schmas dOrganisation Sanitaire et Sociale) grs par les ARH (Agences
Rgionales dHospitalisation). Dans le systme de soins dune rgion, ces agences
sont charges de rpartir de manire optimale les moyens mdicaux (l"ore") en
fonction des besoins sanitaires (la "demande"). A partir des observations de sant
constituant linformation primaire, essentiellement contenue dans les donnes PMSI
(Programme de Mdicalisation du Systme dInformation des hpitaux) [PMS04], il
1
Action Concerte Incitative "Technologies pour la Sant". Projet ADELEM. 2001
Introduction
est ncessaire de mettre au point des outils logiciels danalyse et de visualisation.

Ce projet est trait par une quipe interdisciplinaire compose de :
- Le Laboratoire TIMC IMAG, UMR CNRS 5525.
- Le Laboratoire de Biomtrie et Biologie volutive (UMR CNRS 5558) qui fournit lanalyse statistique des donnes mdicales.
- LOrganisation Mondiale de la Sant (bas en Suisse) qui a dvelopp le logiciel
HealthMapper pour la cration et la manipulation des donnes gographiques.
- Notre quipe du Laboratoire LSR IMAG, UMR CNRS 5526 qui fournit le support pour les bases de donnes et les entrepts.
Objectif du projet :
La rpartition de lore de soins (nombre de lits par spcialit, plateaux techniques) doit sadapter rgulirement lvolution de la demande (volution des pathologies ncessitant une prise en charge hospitalire, de la structure dge et de limplantation gographique de la population), et de lore de soins (volution des techniques et de lorganisation du systme de sant, telles que rseau et tl-mdecine).
Le projet consiste donc en la mise au point dun outil de modlisation-simulation
partir des donnes du PMSI et des donnes de lINSEE (Institut National de la
Statistique et des Etudes Economiques) [INS05] pour aider les gestionnaires du systme de sant dans leur dmarche de prise de dcision.
Sources de donnes relles :
Nous avons trois types de sources : gographiques, dmographiques et les donnes
publiques concernant la sant. Elles sont rparties, htrognes et certaines dentre
elles sont externes au domaine mdical proprement dit. En ce qui concerne les donnes gographiques, lquipe de Service de Biostatistique Lyon sest focalis sur
la visualisation (reprsentation cartographique) de lore et de la consommation de
soins. Ainsi, dans la suite, nous dcrivons ce travail.
Description de lactivit de lquipe de Lyon (Service de Biostatistique)
Ils ont abouti au dveloppement dun logiciel de cartographie de lore et de
la demande de soins hospitaliers en France. Dans cette version initiale, ils se sont
intresss lore et la demande de soins, aux besoins et aux ux mais pas la comparaison sur une mme carte de lore et de la consommation (ratios) qui ncessite
de dnir un maillage gographique commun. Ainsi les reprsentations graphiques
de lore et de la demande se feront sur des fonds de cartes dirents. En eet,
1.2 Le projet ADELEM : Aide la Dcision Logistique et Mdicale
les renseignements sur lorigine gographique des patients pour la consommation de

soin sont bass sur les codes postaux et non pas le code INSEE de la commune de
rsidence du patient [Bel02].
La carte de France se dcompose en quatre niveaux administratifs : la commune,
le canton, le dpartement et la rgion. Il existe une hirarchie entre ces niveaux :
la commune est incluse dans le canton, lui-mme est inclus dans le dpartement,
et celui-ci appartient une rgion. Nanmoins, nous ne disposons pas encore de
la correspondance entre les communes et les cantons au niveau national (chier de
lIntitut de Gographie National). Ainsi, dans cette version 0, la France se compose
de trois niveaux administratifs :
- niveau 1 correspondant Admin1 : rgion
- niveau 2 correspondant Admin2 : dpartement
- niveau 3 correspondant Admin3 : commune
Pour la cration du logiciel, ils ont utilis le systme HealthMapper (logiciel de
cartographie). Il se base sur un gestionnaire de donnes qui permet de combiner
les informations gographiques et pidmiologiques. Le nombre dindicateurs prvus
pour cette version 0 est limit 2 pour la visualisation de lore et de la consommation de soins. Cette version permet de reprsenter tous les tablissements de courts
sjours au niveau national ainsi que le nombre de lits de chaque tablissement hospitalier. Pour ce dernier, la gure 1.2 montre la carte obtenue.
Fig. 1.2 Tous les tablissements au niveau national
Introduction
1.3
Problmatique et objectif de la thse
Les entrepts de donnes ont t conus pour laide la dcision. Ils intgrent les
informations en provenance des dirents systmes transactionnels de lentreprise.
Lensemble des donnes, y compris leur historique, est utilis pour faire des calculs
prvisionnels, des statistiques ou pour tablir des stratgies de dveloppement et
danalyses des tendances.
Dans le cadre du projet ADELEM, nous nous proposons dadapter notre savoirfaire au problme de la gestion de donnes mdicales qui constituent un cadre applicatif particulirement intressant. En eet, ces donnes se trouvent rparties dans
plusieurs sources quil faut, dans un premier temps, fdrer pour constituer un entrept de donnes pertinentes pour lapplication vise. Cette tape est importante
car elle doit non seulement identier les sources, mais aussi dterminer comment
extraire de ces sources les donnes dsires. Nous devons dterminer si les donnes
doivent tre extraites telles quelles ou bien sil faut les traiter au pralable en leur
appliquant des fonctions spciques comme des agrgats, des sommes, ... En plus,
nous devons tablir un mcanisme pour la gestion de lvolution. Dans ce cas, il faut
dterminer ladaptation au niveau : de lapplication dextraction, des agrgats et de
lapplication danalyse.
Cette problmatique est gnrale la constitution de tout entrept mais nous
devons ici tenir compte de la nature particulire des donnes sur lesquelles portent
ltude : type, format, smantique, condentialit, degr de abilit et de conance,
informations manquantes ou incompltes, ... En rsum, il sagit de constituer un
entrept qui contient des donnes pertinentes et de qualit sur lesquelles sera bas
loutil dinterrogation et le processus daide la dcision.
Prcedemment, nous avons dit que notre travail sencadre principalement aux
tapes dorganisation et dinterrogation. Pour cela, nous nous sommes focaliss sur
les problmatiques suivantes : la conception dun entrept de donnes, la slection
des vues matrialiser et la gestion de lvolution. Ainsi, nous traitons dabord ces
sujets et nous terminons avec lobjectif de notre thse.
1.3.1
Conception dun systme pour le dcisionnel
La conception et la construction dun entrept de donnes est une tche complexe

et dlicate. Dans [Kim96, KR03], nous trouvons une mthodologie descendante pour
la conception dun entrept. Elle se compose de neuf dcisions majeures qui sont
la base dune conception complte. Les cinq premires portent sur la structure
logique, tandis que les autres quatre traitent sur la structure physique.
1) Lidentication des tables de faits.
2) Le niveau de granularit de chaque table de faits.
3) Les dimensions appartenant la table de faits.
1.3 Problmatique et objectif de la thse
4) Lensemble de mesures.
5) Les attributs des dimensions avec des descriptions compltes.
6) La gestion de lvolution.
7) La dnition des agrgats, des dimensions dgnres et des dimensions htrognes.
8) Ltendue historique des donnes.
9) La priodicit des mises jour.
Nous donnons une description de ces dcisions :
A partir de lanalyse des sources de donnes existantes et rellement utilises,
nous pouvons aboutir aussi bien lidentication des tables de faits, qui reprsentent
le sujet danalyse, qu son niveau de granularit. Lorsque le grain de la table de
faits est connu, les dimensions peuvent tre identies. Le choix des dimensions
est le point cl de la conception, car elles modlisent les perspectives de lanalyse.
Une fois les dimensions choisies, nous dnissons lensemble de mesures, qui reprsentent les direntes valeurs de lactivit analyse. Nous devons aussi enregistrer
pour chaque dimension lensemble des attributs textuels. Les attributs peuvent tre
utiliss comme source de restrictions dans une requte.
Pour la gestion de lvolution lintrieur des dimensions, Kimball [Kim96] propose trois solutions qui assurent un suivi des modications dans le temps :
1) Remplacer des valeurs anciennes par des nouvelles dans lenregistrement de la
dimension, nanmoins, nous perdons la possibilit de suivre les vnements passs.
2) Crer des nouveaux enregistrements de dimension lors du changement qui
contiennent les nouvelles valeurs de lattribut. Ceci quivaut segmenter lhistorique selon lancienne et la nouvelle description.
3) Crer des nouveaux champs "actuels" lintrieur de lenregistrement dorigine
de la dimension, tout en conservant en mme temps les premires valeurs enregistres. Dans ce cas, nous pouvons garder seulement la valeur originale et la courante
de lattribut modi. Les valeurs intermdiaires sont perdues.
Une dimension qui contient un seul attribut reprsente une dimension dgnre.
De cette manire, nous gardons lattribut (la cl de la dimension) lintrieur de la
table de faits.
Nous dcrirons une dimension htrogne en utilisant un exemple. Une compagnie dassurances a en gnral des domaines dactivit trs direncis. Il y a par
exemple : les risques habitation, les risques automobiles, les risques objets personnels, la responsabilit civile, ..., o chaque domaine est reprsent par des attributs
particuliers. Nous identions deux dimensions : une pour le bien assur et une autre
Introduction
pour le risque couvert. Nanmoins, la dimension Bien_assure contient lensemble

dattributs des produits htrognes (habitation, automobile, ...) ce qui fait delle
une dimension htrogne. Kimball propose de faire des dimensions particularises,
ce qui signie de faire des "copies" de la dimension Bien_assure pour chaque domaine
dactivit, ainsi, pour chaque type de risque couvert nous crons des dimensions particularises pour Bien_assure et pour Risque_couvert.
Finalement, nous devons tablir le priode des donnes historises ainsi que la
frquence des mises jour. Cette dernire peut tre journalire, hebdomadaire, mensuelle,...
1.3.2
Slection des vues matrialiser
La slection de lensemble optimal des vues matrialiser fait partie du processus

dorganisation et elle reprsente une tche essentielle dans la conception dun entrept. La matrialisation nous permet doptimiser lexcution dune requte, pour
cela, nous avons les possibilits suivantes :
La matrialisation complte : Cette approche donne le meilleur temps de rponse
de la requte. Nanmoins, la matrialisation complte nest pas faisable, due principalement au cot de stockage lev.
Pas de matrialisation : Dans ce cas, nous navons pas besoin de stockage supplmentaire. Cependant, pour rpondre chaque requte, nous devons chercher linformation au niveau plus bas de granularit (i.e., raw data). Ainsi, nous avons le
problme dun cot de calcul trs lev pour chaque requte.
La matrialisation partielle : Dans cette approche, le problme se rduit dterminer le nombre optimal de vues matrialiser, en considrant leur cot de stockage,
de maintenance, ...
Il est vident que la dernire approche est la plus intressante. Elle fait lobjet de
plusieurs recherches qui ont pour objectif daboutir la dnition dun mcanisme
pour la slection dun ensemble optimal des vues matrialiser. La plupart des travaux utilisent un modle de cot mais qui a t adapt avec linclusion de certains
paramtres, tels que : la frquence de la requte, la frquence des mises jour sur
les relations de base, le cot de maintenance, entre autres.
Pour nir, nous voulons faire une remarque. Quand nous parlons de la possibilit de rien matrialiser, nous nous rfrons au fait que nous ne considrons pas
les donnes du niveau plus bas comme des donnes matrialises. En eet, certains
dentre nous visualisent les donnes de dtail de lentrept comme une sorte de matrialisation de linformation qui se trouve dans les sources de donnes. Nanmoins,
pour nous, ces donnes une fois intgres et stockes dans lentrept, reprsentent
1.3 Problmatique et objectif de la thse
lensemble de relations de base partir desquelles nous slectionnerons les vues

matrialiser.
1.3.3
Gestion de lvolution des entrepts
Le problme dvolution de schma apparat quand un changement au schma

dune base de donnes modie lensemble de vues dnies sur ce schma. Par exemple :
Supposons que S1 reprsente un schma et V1 lensemble de vues sur S1 . Si nous
avons une nouvelle version de schma S2 partir de S1 , le problme est la dnition
de la nouvelle version V2 qui soit cohrente avec S2 [Ber03].
Lvolution dun schma a des consquences sur lapplication charge de lextraction et lintgration de donnes des sources, car elle peut devenir incomplte
ou incohrente vis--vis du nouveau schma de lentrept. Cette volution entrane
aussi ladaptation des agrgats pr-calculs et ladaptation du processus de maintenance.
La gure 1.3 montre les adaptations ncessaires aprs quune volution du schma
a eu lieu dans un entrept de donnes.
Adaptation de
lapplication
dextraction
E
X
T
R
A
C
T
I
O
N
Sources de donnes
Adaptation des
agrgats
O
R
G
A
N
I
S
A
T
I
O
N
Entrept
de
donnes
Adaptation de
lapplication
danalyse
I
N
T
E
R
R
O
G
A
T
I
O
N
Outils
Fig. 1.3 Gestion de lvolution du schma dans un entrept

Pour rsoudre le problme de perte de donnes aprs des changements du schma,
le concept dvolution de schma t introduit pour rcuprer les donnes existantes par le biais de leur adaptation au nouveau schma. Nanmoins, dans les
systmes qui doivent grer des donnes historiques, lvolution de schma nest pas
susante et la maintenance de plusieurs schmas est requise [GM02]. Ainsi, pour
grer ces changements, nous pouvons utiliser soit lvolution de schmas soit les
versions de schmas. Nous devons choisir la technique utiliser par rapport aux
caractristiques de lapplication cible.
10
Introduction
1.3.4
Objectif de la thse
Notre objectif consiste la conception et mise en oeuvre dun entrept de donnes

pour laide la dcision. Pour faire cela, nous proposons :
- La dnition dun mtamodle multidimensionnel qui se compose de trois classes :
Cube, Dimension et Hirarchie.
- Un algorithme pour la slection de lensemble optimal des vues matrialiser.
- Une interface graphique pour la gnration (semi-automatique) des requtes.
- Les versions de schmas bitemporels pour la gestion de lvolution dun entrept.
1.4
Dmarche et contribution
Notre travail se focalise sur les processus dorganisation et dinterrogation. Nous

reprenons les propositions numres prcdemment et nous donnons une description
de chacune delles.
1.4.1
Mtamodle multidimensionnel
Pour le mtamodle, nous avons spci trois mtaclasses : Cube, Dimension et

Hirarchie. Nous avons propos les dnitions pour chaque mtaclasse et leurs instances, ainsi quune dnition dune base de donnes multidimensionnelle et de son
instance. Ceci nous a permis daboutir la conception dun modle multidimensionnel qui se compose dun ensemble de classes contenant des proprits, des relations
et des contraintes entre les classes. Nous distinguons les termes de dimension et de
hirarchie avec les caractristiques suivantes :
- Une dimension peut contenir zro, une ou plusieurs hirarchies. Une instance de
hirarchie ne peut pas relier linstance du cube auquel est associe linstance de la
dimension contenant cette hirarchie. Nanmoins, elle peut relier une instance dun
autre cube et ceci en raison de la granularit associe chaque hirarchie.
- Nous pouvons insrer un niveau de hirarchie soit ct de la hirarchie dj
dnie soit lintrieur.
- Nous considrons le cas o nous avons seulement deux niveaux de hirarchie.
Nous avons conu un schma en constellation pour le projet ADELEM et nous
avons donn une description de ce schma en utilisant notre mtamodle.
1.4 Dmarche et contribution
1.4.2
11
Algorithme pour la slection des vues matrialiser
Nous avons dit prcdemment que pour la matrialisation dun hypercube, nous
avions les possibilits suivantes : la matrialisation complte, pas de matrialisation
ou la matrialisation partielle. Dans notre cas, nous considrons la dernire approche.
Notre algorithme utilise un modle de cot, nanmoins, nous considrons aussi les
paramtres suivants : frquence dutilisation, cot de calcul et frquence des mises
jour des relations de base.
Nous avons utilis notre algorithme et celui propos dans [HRU95] sur des donnes
mdicales relles et nous avons constat que notre proposition donne de meilleurs
rsultats pour notre cas exprimental.
1.4.3
Interface pour la gnration (semi-automatique) des indicateurs
Lobjectif de notre interface est de faciliter la tche de cration dindicateurs pour

les utilisateurs. Nous avons dvelopp les composants suivants :
- Un module pour la cration et/ou la modication du schma.
- Un module pour la gnration de requtes de manire quasi-automatique.
Nous avons construit le schma en toile Adelem_MCO et nous avons cre la base
de donnes correspondante en utilisant un chantillon de 10% des donnes relles du
projet ADELEM. Ceci nous a permis de vrier et de prouver notre interface graphique, de cette manire, la requte SQL gnre sexcute sur les donnes mdicales
et le rsultat est prsent sur linterface.
1.4.4
Versions de schmas bitemporels
Nous proposons lutilisation des versions de schmas bitemporels pour la gestion,

le stockage et la visualisation des donnes historises intensionnelles et extensionnelles. Dans ce cas, nous devons grer la combinaison du temps de transaction et du
temps de validit dans notre modle de versions.
Nanmoins, la gestion des versions est une tche complexe et elle prsente plusieurs problmes. Le principal, notre connaissance, est lexplosion des versions,
ainsi, nous devons tablir un mcanisme pour contrler cette explosion. Notre proposition considre :
- Un oprateur appel SetVersion qui permet dappliquer un ensemble de changements sur une version et de gnrer une nouvelle version.
12
Introduction
- Un ensemble de 19 primitives ncessaires pour la gestion des cubes, des dimensions et des hirarchies.
- Un ensemble de 5 primitives qui agissent sur les versions de schmas.
- Un gestionnaire dvolution responsable de la manipulation des direntes versions de schmas historises.
1.5
Plan de la thse
Nous prsentons ici lorganisation du document.

Le chapitre 2 fait un tat de lart des entrepts de donnes dans le contexte
o nous nous plaons. Nous prsentons larchitecture dun entrept et ses composants, les dirents modles multidimensionnels pour la construction dun systme
dcisionnel, ainsi que lensemble des oprations pour la manipulation des donnes
multidimensionnelles. Nous dcrivons les serveurs dcisionnels : ROLAP, MOLAP
et HOLAP. Dans la dernire partie, nous prsentons lapproche des versions de
schma. Nous prsentons dabord ltat courant des versions dans les modles de
donnes existants. Ensuite nous dcrivons lespace de versions, leurs types, la gestion de donnes extensionnelles et intensionnelles, ainsi que les oprations primitives
utiliser.
Le chapitre 3 prsente larchitecture conue pour un systme dcisionnel dans
le domaine mdical. Elle est base sur trois composants, une interface graphique
pour la gnration semi-automatique des indicateurs, un entrept multidimensionnel et les versions de schmas bitemporels. Nous dcrivons notre mtamodle et
ses mtaclasses. Nous prsentons le schma en constellation conu compos de trois
sous-schmas : Prise_MCO, Prise_SSR et Population, o chacun est compos soit de
ses propres dimensions soit des dimensions partages.
Le chapitre 4 traite le sujet des vues matrialises, aussi bien leur slection que
leur cration. Nous prsentons dabord lhypercube pour le schma Adelem_MCO. Ensuite, nous prsentons un algorithme pour la slection de lensemble optimal des vues
slectionner. Nous terminons ce chapitre avec une description du fonctionnement
de linterface pour la gnration semi-automatique dindicateurs.
Le chapitre 5 prsente notre proposition pour la gestion, le stockage et la visualisation de lensemble de donnes historises. Pour la cration et la gestion des
versions de schmas, nous donnons une liste doprations primitives adaptes aux
entrepts de donnes et nous avons aussi dni un ensemble de contraintes pour la
manipulation des versions. Nous donnons aussi pour chaque primitive sa dnition
formelle. La dernire partie traite de la description du gestionnaire dvolution de
schmas. Nous prsentons aussi bien la gestion de donnes historises que lactivit
1.5 Plan de la thse

du gestionnaire dvolution par niveau.
Finalement, le chapitre 6 prsente nos conclusions et quelques perspectives.
13
14
Introduction
Chapitre 2
Entrepts de donnes
multidimensionnelles et aspects
temporels
Les entrepts de donnes sont apparus vers les annes 1990 en rponse la ncessit de rassembler toutes les informations de lentreprise en une base de donnes
unique destine aux analystes et aux gestionnaires [Cod93, DG01]. Lensemble des
donnes, y compris leur historique, est utilis dans de nombreux domaines, tels
que : lanalyse de donnes et laide la dcision (gestion et analyse de march,
gestion et analyse du risque, gestion et dtection des fraudes,...) ; dans autres applications (recherches dans des textes, dans les documents web, dans lastronomie,...)
[Adi02, BCA01].
Dans ce chapitre, nous analysons aussi bien les caractristiques des entrepts que
leurs aspects temporels.
2.1
Entrepts de donnes
Nous prsentons dabord larchitecture dun systme dcisionnel qui se compose

de trois composants : les sources, lentrept et les outils pour linterrogation de
lensemble de donnes. Nous dcrivons aussi les caractristiques des entrepts et les
bases de donnes.
2.1.1
Architecture dun entrept de donnes
Larchitecture des entrepts de donnes repose souvent sur un SGBD spar du

systme de production de lentreprise qui contient les donnes de lentrept. Le processus dextraction des donnes permet dalimenter priodiquement ce SGBD. Nanmoins avant dexcuter ce processus, une phase de transformation est applique aux
donnes oprationnelles. Celle-ci consiste les prparer (mise en correspondance
des formats de donnes), les nettoyer, les ltrer,..., pour nalement aboutir leur
15
16
Entrepts de donnes multidimensionnelles et aspects temporels
stockage dans lentrept.

Dans la Figure 2.1, nous prsentons une architecture simplie dun entrept
[DG01]. Les dirents composants ont t intgrs dans trois parties : les sources de
donnes, lentrept et les outils existants dans le march.
Entrept de
donnes
O
Mtadonnes
Donnes externes
Donnes fortement
rsumes
U
T
I
Donnes lgrement
rsumes
Donnes de dtail
L
S
Donnes de production
(SGBD, systmes lgus)
Donnes anciennes
archives
Fig. 2.1 Architecture dun entrept de donnes
a) Les sources : Les donnes de lentrept sont extraites de diverses sources souvent rparties et htrognes, et qui doivent tre transformes avant leur stockage
dans lentrept. Nous avons deux types de sources des donnes : internes et externes
lorganisation.
Internes : La plupart des donnes sont saisies partir des dirents systmes
de production qui rassemblent les divers SGBD oprationnels, ainsi que des anciens
systmes de production qui contiennent des donnes encore exploites par lentreprise.
Externes : Ils reprsentent des donnes externes lentreprise et qui sont souvent
achtes. Par exemple, les sources de donnes dmographiques.
b) Lentrept de donnes : Il existe plusieurs types de donnes dans un entrept, qui correspondent diverses utilisations, comme :
2.1 Entrepts de donnes
17
Donnes de dtail courantes : Ce sont lensemble des donnes quotidiennes

et plus couramment utilises. Ces donnes sont gnralement stockes sur le disque
pour avoir un accs rapide. Par exemple, le dtail des ventes de lanne en cours,
dans les dirents magasins.
Donnes de dtail anciennes : Ce sont des donnes quotidiennes concernant
des vnements passs, comme par exemple le dtail des ventes des deux dernires
annes. Nous les utilisons pour arriver lanalyse des tendances ou des requtes prvisionnelles. Nanmoins ces donnes sont plus rarement utilises que les prcdentes,
et elles sont souvent stockes sur des mmoires darchives.
Donnes rsumes ou agrges : Ce sont des donnes moins dtailles que les
deux premires et elles permettent de rduire le volume des donnes stocker. Le
type de donnes, en fonction de leur niveau de dtail, permet de les classier comme
des donnes lgrement ou fortement rsumes. Par exemple, les ventes mensuelles
par magasin des dix dernires annes sont des donnes faiblement rsumes, tandis
que les ventes semestrielles, par rgion, des dix dernires annes sont fortement rsumes.
Les mtadonnes : Ce sont des donnes essentielles pour parvenir une exploitation ecace du contenu dun entrept. Elles reprsentent des informations
ncessaires laccs et lexploitation des donnes dans lentrept comme : la smantique (leur signication), lorigine (leur provenance), les rgles dagrgation (leur
primtre), le stockage (leur format, par exemple : francs, euro,...) et nalement
lutilisation (par quels programmes sont-elles utilises).
c) Outils : Il existe sur le march dirents outils pour laide la dcision, comme
les outils de fouille de donnes ou datamining (pour dcouvrir des liens smantiques),
outils danalyse en ligne (pour la synthse et lanalyse des donnes multidimensionnelles), outils dinterrogation (pour faciliter laccs aux donnes en fournissant une
interface conviviale au langage de requtes),... [CD97, Fra97, DG01].
2.1.2
Entrepts et les bases de donnes
Dans lenvironnement des entrepts de donnes, les oprations, lorganisation des

donnes, les critres de performance, la gestion des mtadonnes, la gestion des
transactions et le processus de requtes sont trs dirents des systmes de bases
de donnes oprationnels. Par consquent, les SGBD relationnels orients vers lenvironnement oprationnel, ne peuvent pas tre directement transplants dans un
systme dentrept de donnes [WB97].
Les SGBD ont t cres pour les applications de gestion de systmes transactionnels. Par contre, les entrepts de donnes ont t conus pour laide la prise
18
de dcision. Ils intgrent les informations qui ont pour objectif de fournir une vue
globale de linformation aux analystes et aux dcideurs.
Le tableau 2.1 rsume ces dirences entre les systmes de gestion de bases de
donnes et les entrepts de donnes [DG01].
Objectifs
Utilisateurs
Taille de la base
Organisation
des donnes
Type de donnes
Requtes
Transactions
SGBD
Gestion et production
Gestionnaires de production
Plusieurs gigaoctets
Par traitement
Entrepts de donnes
Consultation et analyse
Dcideurs, analystes
Plusieurs teraoctets
Par mtier
Donnes de gestion
(courantes)
Simples, prdtermines,
donnes dtailles
Courtes et nombreuses,
temps rel
Donnes danalyse
(rsumes, historises)
Complexes, spciques,
agrgations et group by
Longues, peu nombreuses
Tab. 2.1 Dirences entre SGBD et entrepts de donnes
Systmes transactionnels et systmes dcisionnels Les SGBD ont t crs

pour grer de grands volumes dinformation contenus dans les dirents systmes
oprationnels qui appartiennent lentreprise. Ces donnes sont manipules en utilisant des processus transactionnels en ligne [Cod93].
Paralllement lexploitation de linformation contenue dans ces systmes oprationnels, les dirigeants des entreprises ont besoin davoir une vision globale concernant toute cette information pour faire des calculs prvisionnels, des statistiques ou
pour tablir des stratgies de dveloppement et danalyses des tendances.
Le tableau 2.2 compare les caractristiques des systmes transactionnels et dcisionnels par rapport aux donnes et aux utilisateurs [BCA01, CT98, GM00, SMKK98,
Tes00, ZS99].
2.2
Modlisation multidimensionnelle
Pour arriver construire un modle appropri pour un entrept de donnes, nous

pouvons choisir, soit un schma relationnel (le schma en toile, en ocon de neige
ou en constellation) ; soit un schma multidimensionnel. Avant de dcrire les dirents schmas, nous commenons par quelques concepts de base.
19
2.2 Modlisation multidimensionnelle
Donnes
Utilisateurs
S. Transactionnel
Exhaustives
Courantes
Dynamiques
Orientes applications
Nombreux
Varis (employs,
directeurs,...)
Concurrents
Mises jour et
interrogations
Requtes prdnies
Rponses immdiates
Accs peu
dinformation
S. Dcisionnel
Rsumes
Historiques
Statiques
Orientes sujets (danalyse)
Peu nombreux
Uniquement les dcideurs
Non concurrents
Interrogations
Requtes imprvisibles et complexes
Rponses moins rapides
Accs de nombreuses informations
Tab. 2.2 Comparaison des systmes

La modlisation multidimensionnelle consiste considrer un sujet analys comme
un point dans un espace plusieurs dimensions. Les donnes sont organises de manire mettre en vidence le sujet (le fait) et les direntes perspectives de lanalyse
(les dimensions).
En partant de cette dnition, nous remarquons les concepts de fait et de dimension. Le fait reprsente le sujet danalyse. Il est compos dun ensemble de
mesures qui reprsentent les direntes valeurs de lactivit analyse. Par exemple,
dans le fait Ventes (cf. Figure 2.2), nous pouvons avoir la mesure "Quantit de produits vendus par magasin". Les mesures doivent tre valorises de manire continue
[AGS97, CT97, Inm92, Inm95, Kim96, KR03, KS95] et elles peuvent tre additives (pour rsumer une grande quantit denregistrements) ; semi-additives (si elles
peuvent seulement tre additionnes pour certaines dimensions) et non additives.
Une dimension modlise une perspective de lanalyse. Elle se compose de paramtres (ou attributs) qui servent enregistrer les descriptions textuelles. Nous
pouvons utiliser les paramtres textuels comme source des restrictions dans une requte. Par exemple, dans la requte "Quantit de produits vendus dans la rgion
Rhne Alpes durant le mois de Janvier 2000". Nous trouvons les paramtres : rgion
"Rhne Alpes" et mois "Janvier 2000".
Une hirarchie reprsente les paramtres dune dimension selon leur niveau
de granularit ou de dtail. Les paramtres sont ordonns par une relation "est
_plus_fin" et note P1 P2. Dans notre exemple sur les ventes (cf. gure 2.2)
nous pouvons avoir une hirarchie pour la dimension Magasin de la forme suivante :
20

Commune Dpartement Rgion Pays
2.2.1
Schmas relationnels
Dans les schmas relationnels nous trouvons deux types de schmas. Les premiers
sont des schmas qui rpondent fort bien aux processus de type OLTP qui ont t
dcrits prcdemment, alors que les deuximes, que nous appelons des schmas pour
le dcisionnel, ont pour but de proposer des schmas adapts pour des applications
de type OLAP.
Nous dcrivons les dirents types des schmas relationnels pour le dcisionnel.
2.2.1.1
Le schma en toile
Il se compose du fait central et de leurs dimensions. Dans ce schma il existe une

relation pour les faits et plusieurs pour les direntes dimensions autour de la relation centrale. La relation de faits contient les direntes mesures et une cl trangre
pour faire rfrence chacune de leurs dimensions.
La gure 2.2 montre le schma en toile en dcrivant les ventes ralises dans
les dirents magasins de lentreprise au cours dun jour. Dans ce cas, nous avons
une toile centrale avec une table de faits appele Ventes et autour leurs diverses
dimensions : Temps, Produit et Magasin.
Produit
Temps
Cl_T
Jour
Mois
Anne
Ventes
Cl_P
Cl_T
Cl_M
Cl_P
Description
Type
Catgorie
Quantit
Magasin
Cl_M
Raison_soc
Adresse
Commune
Dpartement
Rgion
Pays
Fig. 2.2 Exemple de modlisation en toile.
21
2.2 Modlisation multidimensionnelle

2.2.1.2
Le schma en flocon de neige (Snowflake)
Il drive du schma prcdent avec une relation centrale et autour delle les direntes dimensions, qui sont clates ou dcomposes en sous hirarchies. Lavantage
du schma en ocon de neige est de formaliser une hirarchie au sein dune dimension, ce qui peut faciliter lanalyse. Un autre avantage est reprsent par la normalisation des dimensions, car nous rduisons leur taille. Nanmoins dans [Kim96],
lauteur dmontre que cest une perte de temps de normaliser les relations des dimensions dans le but dconomiser lespace disque. Par contre, cette normalisation
rend plus complexe la lisibilit et la gestion dans ce type de schma. En eet, ce type
de schma augmente le nombre de jointures raliser dans lexcution dune requte.
Les hirarchies pour le schma en ocon de neige de lexemple de la gure 2.2 sont :
Dimension Temps = Jour Mois Anne
Dimension Magasin = Commune Dpartement Rgion Pays
La gure 2.3 montre le schma en ocon de neige avec les dimensiones Temps et
Magasin clates en sous hirarchies.
Produit
Temps
Cl_T
Jour
Mois
Ventes
Cl_P
Cl_T
Cl_M
Cl_P
Description
Type
Catgorie
Quantit
T_Mois
Magasin
Mois
Anne
Cl_M
Raison_soc
Adresse
Commune
Dpartement
M_Dpartement
Dpartement
Rgion
M_Rgion
Rgion
Pays
Fig. 2.3 Exemple de modlisation en ocon de neige.

Dans lexemple ci-dessus, la dimension Temps a t clate en deux, Temps et
T_Mois. La deuxime dimension Magasin, t dcompose en trois : Magasin, M_
Dpartement et M_Rgion.
22
2.2.1.3

Le schma en constellation
Le schma en constellation reprsente plusieurs relations de faits qui partagent

des dimensions communes. Ces direntes relations de faits composent une famille
qui partage les dimensions mais o chaque relation de faits a ses propres dimensions
[BCA01].
La gure 2.4 montre le schma en constellation qui est compos de deux relations
de faits. La premire sappelle Ventes et enregistre les quantits de produits qui ont
t vendus dans les dirents magasins pendant un certain jour. La deuxime relation gre les dirents produits achets aux fournisseurs pendant un certain temps.
Magasin
Produit
Cl_M
Raison_soc
Adresse
Commune
Dpartement
Rgion
Pays
Ventes
Cl_P
Cl_M
Cl_T
Cl_P
Description
Type
Catgorie
Quantit
Temps
Cl_T
Jour
Mois
Anne
Achats
Cl_P
Cl_F
Cl_T
Quantit
Fournisseur
Cl_F
Raison_soc
Adresse
Code_postal
Commune
Pays
Fig. 2.4 Exemple de modlisation en constellation.

La relation de faits Ventes partage leurs dimensions Temps et Produits avec la
table Achats. Nanmoins, la dimension Magasin appartient seulement Ventes. Egalement, la dimension Fournisseur est lie seulement la relation Achats.
2.2.2
Schma multidimensionnel (Cube)
Dans le modle multidimensionnel, le concept central est le cube, lequel est

constitu des lments appels cellules qui peuvent contenir une ou plusieurs mesures. La localisation de la cellule est faite travers les axes, qui correspondent
chacun une dimension. La dimension est compose de membres qui reprsentent
les direntes valeurs.
23
2.3 Manipulation des donnes multidimensionnelles
En reprenant une partie du schma en toile de la g. 2.2, nous pouvons construire

le schma multidimensionnel suivant.
Magasin
Produit
Magasin
TV
CS
S
U
M
CP
Lyon
Grenoble
Annecy
Pays
Temps
anne
Rgion
mois
Dpartement
Jour
Ville
SUM
01/01/2000
Temps
02/01/2000
03/01/2000
SUM
All
Hirarchies des dimensions
Fig. 2.5 Exemple de schma multidimensionnel.

La gure 2.5, prsente un schma multidimensionnel pour les ventes qui ont t
ralises dans les magasins pour les dirents produits au cours dun temps donn
(jour). Par exemple, nous avons la quantit de 100 Tlviseurs vendus dans le magasin dAnnecy pendant le 1er janvier 2000.
2.3
Manipulation des donnes multidimensionnelles
Pour visualiser les donnes multidimensionnelles, nous pouvons utiliser la reprsentation sous forme dune table de donnes, qui est la plus courante [Mar98, Vas98].
Dans une table, nous reprsentons les direntes combinaisons des valeurs choisies
pour constituer les noms de lignes et de colonnes. Nanmoins, quand le nombre de
dimensions est suprieur deux, lutilisateur a des problmes pour visualiser simultanment lensemble de linformation. Pour rsoudre ce problme, nous devons
disposer doprations pour manipuler les donnes et rendre possible la visualisation.
Nous prsentons les oprations pour la manipulation des donnes multidimensionnelles, en les divisant selon leur impact sur la faon de prsenter les direntes
vues des donnes analyses [Mar98, MQM97, MS90, Tes00].
2.3.1
Oprations classiques
Ces oprations correspondent aux oprations relationnelles de manipulation des

donnes :
La slection : Rsulte en un sous-ensemble de donnes qui respecte certains conditions dappartenance. Nous pouvons avoir une slection avec des conditions soit sur
24
les mesures, soit sur les membres. Par exemple, une slection des ventes suprieur
350 est une slection sur les mesures, tandis que une slction des ventes raliss
dans la rgion "Rhne Alpes" de lanne "2000" est une slection sur les membres
dune dimension.
La projection : Rsulte en un sous-ensemble des attributs dune relation, qui sont
soit des dimensions, soit des niveaux de granularit. Dans les systmes dcisionnels,
les oprations de slection et de projection sont appeles souvent "slice-and-dice".
La jointure : Permet dassocier les donnes de relations direntes. Par exemple,
en utilisant les tables 2.3 et 2.4, nous faisons une jointure sur la dimension Produit.
Lobjectif est de reprsenter sur une mme table la quantit de produits vendue et
leur prix (cf. Figure 2.6).
Ventes (01/01/2000)
Tlviseur
Radio
Camscope
Camera photo
Mag1
100
50
100
Mag2
Mag3
250
200
50
100
100
Tab. 2.3 Ventes par magasin

Produit
Tlviseur
Radio
Camscope
Camera photo
Prix (01/01/2000)
1
2
3
4
Tab. 2.4 Prix des produits
Les oprations ensemblistes : Dunion, dintersection et de dirence sont des

oprations qui agissent sur des relations qui ont le mme schma. Par exemple,
lunion des tables 2.5 et 2.6 donne comme rsultat la table 2.7.
2.3.2
Oprations agissant sur la structure
Les oprations agissant sur la structure visent prsenter une vue (face du cube)
dirente en fonction de leur analyse, citons :
La rotation (rotate) : Consiste pivoter ou eectuer une rotation du cube, de
manire prsenter une vue dirente des donnes analyser.
25
2.3 Manipulation des donnes multidimensionnelles
Fig. 2.6 Exemple de lopration Jointure.

Ville
Grenoble
Grenoble
Grenoble
Grenoble
Produit
Tlviseur
Radio
Camscope
Camera photo
Mag1
50
50
100
Mag2
100
Mag3
100
50
100
Tab. 2.5 Ventes de produits par ville 1

Ville
Fontaine
Fontaine
Fontaine
Fontaine
Produit
Tlviseur
Radio
Camscope
Camera photo
Mag1
100
50
100
100
Mag2
100
50
Mag3
50
100
100
100
Tab. 2.6 Ventes de produits par ville 2

Ville
Grenoble
Grenoble
Grenoble
Grenoble
Fontaine
Fontaine
Fontaine
Fontaine
Produit
Tlviseur
Radio
Camscope
Camera photo
Tlviseur
Radio
Camscope
Camera photo
Mag1
50
50
100
100
50
100
100
Mag2
100
Mag3
100
50
100
50
Tab. 2.7 Ventes du Dpartement Isre
100
50
100
100
100
26
La permutation (switch) : Consiste inverser des membres dune dimension, de

manire permuter deux tranches du cube.
La division (split) : Consiste prsenter chaque tranche du cube en passant
dune reprsentation tridimensionnelle une prsentation tabulaire. Par exemple, si
nous dcoupons par magasin le cube de ventes de la gure 2.5, nous avons les tables
2.8, 2.9 et 2.10.
Ventes Magasin 1
Tlviseur
Radio
Camscope
Camera photo
01/01/2000
100
50
02/01/2000
100
200
100
100
03/01/2000
50
100
100
100
Tab. 2.8 Table de ventes du Magasin 1

Ventes Magasin 2
Tlviseur
Radio
Camescope
Camera photo
01/01/2000
200
50
100
02/01/2000
100
200
100
03/01/2000
150
100
100

Ventes Magasin 3
Tlviseur
Radio
Camscope
Camera photo
01/01/2000
250
02/01/2000
100
100
50
100
03/01/2000
50
100
50
100

Nous remarquons que le nombre de tables rsultantes de cette opration dpend
du nombre de valeurs lintrieur de la dimension.
Lembotement (nest) : Permet dimbriquer les membres dune dimension. En
utilisant cette opration, nous reprsentons dans une table bidimensionnelle toutes
les donnes dun cube quel que soit le nombre de dimensions.
Lenfoncement (push) : Consiste combiner les membres dune dimension aux
mesures du cube et donc de reprsenter un membre comme une mesure.
2.4 Serveurs OLAP (On-Line Analytical Processing)
27
Lopration inverse de retrait (pull) : Permet de changer le statut de certaines

mesures, pour transformer une mesure en membre dune dimension.
La factualisation (fold) : Consiste transformer une dimension en mesure(s) ;
cette opration permet de transformer en mesure lensemble des paramtres dune
dimension.
La paramtrisation (unfold) : Permet de transformer une mesure en paramtre
dans une nouvelle dimension.
Lopration Cube : Permet de calculer des sous-totaux et un total nal dans le
cube (cf. Fig 2.5).
2.3.3
Oprations agissant sur la granularit
Les oprations agissant sur la granularit des donnes analyses, permettent de

hirarchiser la navigation entre les dirents niveaux de dtail dune dimension.
Dans la suite nous traitons les deux oprations de ce type :
Le forage vers le haut (drill-up ou roll-up) : Permet de reprsenter les donnes
du cube un niveau plus haut de granularit en respectant la hirarchie de la
dimension. Nous utilisons une fonction dagrgation (somme, moyenne,...), qui est
paramtre, pour indiquer la faon de calculer les donnes du niveau suprieur
partir de celles du niveau infrieur.
Le forage vers le bas (drill-down ou roll-down ou scale-down) : Consiste reprsenter les donnes du cube un niveau de granularit infrieur, donc sous une
forme plus dtaille.
Ces types doprations ont besoin dinformations non reprsentes dans un cube,
pour augmenter ou aner des donnes, partir dune reprsentation initiale vers une
reprsentation de granularit dirente. Le forage vers le haut a besoin de connatre
la fonction dagrgation utilise tandis que le forage vers le bas ncessite de connatre
les donnes au niveau infrieur.
2.4
Serveurs OLAP (On-Line Analytical Processing)
Les donnes oprationnelles constituent la source principale dun systme dinformation dcisionnel. Les systmes dcisionnels complets reposent sur la technologie
OLAP, conue pour rpondre aux besoins danalyse des applications de gestion.
Lacronyme FASMI (Fast Analysis of Shared Multidimensional Information) permet de rsumer la dnition des produits OLAP. Cette dnition fut utilise pour
28
la premire fois en 1995 et depuis aucune autre dnition nest plus proche pour
rsumer le terme OLAP [Ola04].
Fast : Le temps de rponse aux demandes des utilisateurs oscille entre 1 et 20
secondes. Les constructeurs utilisent des pr-calculs pour rduire les dures des requtes.
Analysis : Le systme doit pouvoir faire face toutes les logiques daaires et
de statistiques, ainsi que fournir la possibilit aux utilisateurs de construire leurs
calculs et leurs analyses sans avoir programmer. Pour cela, il y a des outils qui
seront fournis par le constructeur.
Shared : Le systme doit crer un contexte o la condentialit est prserve et doit
grer les cas o plusieurs utilisateurs ont des droits en critures. Ce point constitue
la plus grosse faiblesse des produits actuels.
Multidimensional : Cest la caractristique cl. Le systme doit fournir des vues
conceptuelles multidimensionnelles des donnes. Il doit supporter aussi les hirarchies.
Informations : Lensemble des donnes et les informations ncessaires pour un produit OLAP.
Nous exposons dans la suite les divers types de stockage des informations dans
les systmes dcisionnels.
2.4.1
ROLAP (Relational OLAP)
Dans les systmes relationnels OLAP, lentrept de donnes utilise une base de
donnes relationnelle. Le stockage et la gestion de donnes sont relationnels. Toutefois, le modle relationnel requiert des extensions pour supporter les requtes danalyses multidimensionnelles du niveau dapplication. Le moteur ROLAP traduit dynamiquement le modle logique de donnes multidimensionnel M en modle de stockage relationnel R (la plupart des outils requirent que la donne soit structure en
utilisant un schma en toile ou un schma en ocon de neige). Techniquement, le
moteur ROLAP excute une transformation partir dune requte multidimensionnelle m contre M vers une requte relationnelle r contre R. Lecacit du rsultat
de la requte est le facteur dominant pour la performance et le passage lchelle
global du systme. Ainsi, les stratgies doptimisation reprsentent le point principal
qui distingue les systmes ROLAP existants [DSBH99, Sat03].
La gure 2.7 montre une architecture pour le serveur ROLAP.
29
Serveur ROLAP
Base de donnes
relationnelle
Vue
multidimensionnelle
Client OLAP
Fig. 2.7 Architecture ROLAP.

La technologie ROLAP a deux avantages principaux : (1) elle permet la dnition
de donnes complexes et multidimensionnelles en utilisant un modle relativement
simple , et (2) elle rduit le nombre de jointures raliser dans lexcution dune
requte. Le dsavantage est que le langage de requtes tel quil existe, nest pas
assez puisant ou nest pas assez exible pour supporter de vraies capacits dOLAP
[VS99, BSH98].
Nous dcrivons quelques produits commerciaux existants [How03, CHJM02] :
IBM DB2 UDB : Cest un SGBD tournant sur une varit de plate-formes. IBM
est une shared nothing database et elle supporte le concept de fdration. Elle dispose
dune large gamme doutils, par exemple :
DB2 Performance Expert : Cet outil pour multiplate-formes permet la cration
des rapports, des analyses et recommande des changements par rapport la performance.
DB2 DataJoiner : Outil pour loptimisation des requtes SQL.
DB2 Integrated Cluster Environnement : Il permet le passage lchelle.
Oracle 9i : Cest un SGBD tournant aussi sur une varit de plate-formes. Oracle
supporte des partitions de hash, range et list.
Oracle 9i : Cest une shared disk database et elle supporte la consolidation (focalise sur une base de donnes centralise).
Real Application Clusters : Il permet de dsigner certains processeurs comme processeurs OLAP et dautres comme processeurs de requtes.
30
Loptimiser : Bas sur les cots ou sur les rgles.

SQL Server 2000 : Cest une shared nothing database et elle supporte le concept
de fdration (liaison entre bases de donnes distribues et htrognes via le logiciel).
Loptimiser de SQL Server : Bas sur les cots avec cration automatique de
statistiques et leur rafrachissement.
Le Query Processor : Il supporte des requtes multidimensionnelles, ainsi que les
index composites et semi-jointures.
Le SQL Query Analyzer : Il peut faire des suggestions par rapport limplantation des index additionnels et des statistiques complmentaires.
Microsoft DTS (Data Transformation Services) : Loutil ETL intgr dans Microsoft SQL Server.
2.4.2
MOLAP (Multidimensional OLAP)
Les systmes multidimensionnels OLAP utilisent une base de donnes multidimensionnelle pour stocker les donnes de lentrept et les applications analytiques
sont construites directement sur elle. Dans cette architecture, le systme de base de
donnes multidimensionnel sert tant au niveau de stockage quau niveau de gestion
des donnes. Les donnes des sources sont conformes au modle multidimensionnel,
et dans toutes les dimensions, les direntes agrgations sont prcalcules pour des
raisons de performance [WB97].
La gure 2.8 montre une architecture pour les systmes MOLAP.
Serveur MOLAP
Base de donnes
multidimensionnelle
(hypercube)
Client OLAP
Fig. 2.8 Architecture MOLAP.
31
Les systmes MOLAP doivent grer le problme de donnes clairsemes, quand

seulement un nombre rduit de cellules dun cube contiennent une valeur de mesure
associe. Par exemple, dans le cube Ventes (cf. Fig 2.5), il peut arriver que certains produits ne se soient pas vendus dans une ville spcique et quen consquent
il ny ait pas de valeurs de mesure pour cette combinaison. La faon de rsoudre
cette problmatique, par les produits commerciaux, reprsente un des plus importants critres pour les systmes MOLAP. La plupart des systmes existants utilisent
lapproche du vecteur multidimensionnel pour le stockage de donnes, ainsi que la
compression de lespace de stockage pour les vecteurs de plus de trois dimensions
[Ben02, DSBH99].
Les avantages des systmes MOLAP sont bass sur les dsavantages des systmes
ROLAP et elles reprsentent la raison de leur cration. Dun ct, les requtes MOLAP sont trs puissantes et exibles en termes du processus OLAP, tandis que,
dun autre ct, le modle physique correspond plus troitement au modle multidimensionnel. Nanmoins, il existe des dsavantages au modle physique MOLAP. Le
plus important, notre avis, cest quil nexiste pas de standard du modle physique.
Les produits commerciaux existants sont :
Hyperion Essbase OLAP Server : Cest une base de donnes multi-utilisateurs,
multi-thread et multidimensionnelle [Blo99]. Les composants dEssbase OLAP sont :
Hyperion Essbase Application Manager : Il fournit des outils graphiques. Il inclut
des modules pour la construction et le chargement des structures OLAP, pour le
chargement des donnes, pour la dnition des processus de calcul, pour la gestion
des partitions de la base de donnes,...
Hyperion Essbase Query Designer : Ce composant remplace le Query Wizard
dEssbase 6.0. Il a t conu pour faciliter la navigation des utilisateurs naux.
Hyperion Essbase Partition Option : Il permet aux dveloppeurs des applications
la cration logique et physique de sous-ensembles des bases de donnes. Les deux
types de partitions qui sont supports sont : transparente et lie. Le premier cherche
montrer lutilisateur nal une base de donnes centralise. Avec le deuxime type,
nous pouvons dnir deux partitions lies si elles partagent au moins une partie dune
dimension. Ainsi, nous pouvons naviguer entre applications et non entre partitions.
Par exemple, nous pouvons naviguer entre lapplication de ventes et celle dachats,
car elles relient le mme ensemble de produits.
SAS OLAP Server : Cest une base multidimensionnelle qui fournit un accs
rapide aux donnes agrges [SAS04]. Leurs composants incluent :
32
SAS OLAP Cube Studio : Cest un outil pour la construction des cubes et qui
peut tre facilement utilis pour la dnition des mesures, des dimensions et des
agrgations.
SAS Metadata Server : Cest un conteneur des mtadonnes.
Ce serveur fournit un processus ETL (Extract, Transform and Load) qui est
transparent et intgr.
Informix MetaCube : Il fournit un mcanisme pour analyser lentrept de donnes et leurs data marts intgrant des outils OLAP avec la technologie de bases de
donnes relationnelles [Inf02]. Les composants du logiciel MetaCube sont :
MetaCube Analysis Engine : Il fournit une interface multidimensionnel. Cet outil tend la fonctionnalit danalyse de la base de donnes avec lincorporation des
oprations OLAP, par exemple lopration rotation (rotate).
MetaCube Explorer : Cest une interface graphique qui permet aux utilisateurs
dexcuter des requtes au travers du MetaCube Analysis Engine.
MetaCube Warehouse Manager : Cest une interface graphique pour crer une description multidimensionnelle des tables et des colonnes dans lentrept de donnes.
Le MetaCube Analysis Engine stocke cette description multidimensionnelle comme
un ensemble de tables.
2.4.3
HOLAP (Hybrid OLAP)
Un systme HOLAP est un systme qui supporte et intgre un stockage des donnes multidimensionnel et relationnel dune manire quivalente pour proter des
caractristiques de correspondance et des techniques doptimisation.
Ci-dessous, nous traitons une liste des caractristiques principales quun systme
HOLAP doit fournir [DSBH99] :
La transparence du systme : Pour la localisation et laccs aux donnes, sans
connatre si elles sont stockes dans un SGBD relationnel ou dimensionnel. Pour la
transparence de la fragmentation,...
Un modle de donnes gnral et un schma multidimensionnel global :
Pour aboutir la transparence du premier point, tant le modle de donnes gnral
que le langage de requte uniforme doivent tre fournis. Etant donn quil nexiste
pas un modle standard, cette condition est dicile raliser.
Une allocation optimale dans le systme de stockage : Le systme HOLAP
33
doit bncier des stratgies dallocation qui existent dans les systmes distribus
tels que : le prol de requtes, le temps daccs, lquilibrage de chargement,...
Une re-allocation automatique : Toutes les caractristiques traites ci-dessus
changent dans le temps. Ces changements peuvent provoquer la rorganisation de
la distribution des donnes dans le systme de stockage multidimensionnel et relationnel, pour assurer des performances optimales.
Actuellement, la plupart des systmes commerciaux utilisent une approche hybride. Cette approche permet de manipuler des informations de lentrept de donnes avec un moteur ROLAP, tandis que pour la gestion des data marts, ils utilisent
lapproche multidimensionnelle. Dans la gure 2.9, nous montrons une architecture
en utilisant les types de serveurs ROLAP et MOLAP pour le stockage de donnes.
Serveur
MOLAP
Base de donnes
multidimensionnelle
(hypercube)
Base de donnes
relationnelle
Vue
multidimensionnelle
Client OLAP
Fig. 2.9 Architecture HOLAP.

Les produits commerciaux existants sont :
DB2 OLAP Server : Il permet de calculer, de consolider et daccser linformation partir des bases de donnes multidimensionnelles, relationnelles ou les deux
[DB204]. Certains de ses composants sont :
DB2 OLAP Integration Server : Il utilise des outils graphiques et des services
pour lintgration des donnes qui rduisent le cot pour crer, dployer et grer les
applications de DB2 OLAP Server.
DB2 OLAP Server Administration Services : Il fournit des outils pour amliorer
et faciliter des tches dadministration.
Oracle Express Server : Ce serveur exploite un modle de donnes multidimensionnel. Il gre un ensemble dindicateurs n dimensions, dont les valeurs sont
34
stockes ou calcules dynamiquement [ORA96].

Le stockage des donnes peut se faire dans une base de donnes multidimensionnelle ou relationnelle.
La base Oracle Express Server : Stocke les agrgats multidimensionnels, tandis
que les donnes de dtail sont stockes dans la base relationnelle.
En utilisant un 4GL (Langage de 4me gnration), Express Server propose
des fonctions avances pour la prsentation et lanalyse des rsultats, tels que :
traitement de sries chronologiques, consolidation, statistiques, prvisions,...
2.5
Les projets de recherche
Dans cette partie, nous dcrivons les projets de recherche sur les entrepts de donnes. Les deux premiers (WHIPS et SIRIUS) sont centrs sur des problmatiques
lies lextraction et la maintenance des donnes. Le troisime DWQ traite de la
qualit des entrepts, tandis que le dernier, le projet EVOLUTION propose le dveloppement dune mthodologie et doutils pour laide la conception et lvolution
des entrepts.
2.5.1
WHIPS Warehouse Information Prototype at Stanford
Lobjectif du projet est de dvelopper des algorithmes pour collecter, intgrer

et maintenir des informations de sources htrognes, distribues et autonomes. Le
modle relationnel est utilis comme modle unicateur.
Pour linitialisation de lentrept, lintgrateur cre un gestionnaire de vues pour
chaque vue dans lentrept. Le gestionnaire de vues envoie les requtes issues de la
dnition dune vue au processeur de requtes. Le processeur de requte contacte
les traducteurs de la source dinformation adquate pour obtenir les rsultats, les
assemble et passe la rponse au gestionnaire de vue. Le gestionnaire de vue envoie
la rponse ladaptateur de lentrept pour initialiser la vue.
Chaque source contienne un moniteur et un adaptateur. Ladaptateur transforme
les donnes de la source en une reprsentation relationnelle. Le moniteur dtecte les
changements qui se produisent au niveau des sources. Les mises jour sont transmises lintgrateur, qui les transmet aux gestionnaires de vues qui sont concerns
par les modications [LZW+ 97, HGMW+ 95].
Description des composants :
Adaptateur/Moniteur : Il est associ chaque source de donnes et il a deux
fonctionnes : transformer le schma et ses instances en une reprsentation interm-
2.5 Les projets de recherche
35
diaire et dtecter automatiquement les changements dans la source pour les propager
vers lintgrateur.
Intgrateur : Il est responsable de la rception des reprsentations intermdiaires
des donnes sources, en provenance des adaptateurs, et de lintgration de cellesci. Lintgration entrane aussi une phase de transformation, celle-ci consiste les
prparer (mise en correspondance des formats de donnes), les nettoyer, les ltrer,...,
pour les rendre conforme au schma de lentrept et aux critres de qualit choisis.
2.5.2
SIRIUS Supporting the Incremental Refreshment of Information warehouses
Ce projet dvelopp lUniversit de Zurich, est un systme dentrept de donnes qui a pour objectif dtudier des techniques permettant le rafrachissement
incrmental de lentrept en rduisant les temps de mise jour. Le schma de lentrept est dni sous la forme dun schma global UML.
Chaque source de donnes est munie dun adaptateur et dun moniteur. Le moniteur dtecte les volutions de la source laquelle il est associ. Le module de
gestion du rafrachissement est le module central (DWRM Data Warehouse Refresh
Manager). Ladaptateur traduit les donnes de la source dans un modle commun,
interne au systme et les transmet au module central DWRM [VGD00].
Objectif du projet :
Lobjectif principal de cette approche est dintroduire une architecture dintergiciel exible, pour :
- Fournir des solutions pour le rafrachissement de donnes.
- Pouvoir tre utilise de faon indpendante par rapport au stockage de donnes
de lentrept.
- Pouvoir tre utilise par des entrepts de donnes composs des sources de
donnes htrognes.
2.5.3
DWQ Foundations of Data Warehouse Quality
DWQ est un projet de la communaut Europenne (France, Allemagne, Italie et

Grce) pour le dveloppement des fondements smantiques qui permettront daider
les concepteurs dentrepts de donnes dans le choix des modles, des structures de
donnes avances et des techniques dimplantation ecaces en sappuyant sur des
facteurs de qualit de service.
36
Les rsultats comportent des mta-modles formels de donnes destins la description de larchitecture statique dun entrept de donnes. Les outils associs
comportent des facilits de modlisation incluant des caractristiques spciques
aux entrepts comme la rsolution de sources multiples, la gestion de donnes multidimensionnelles agrges et des techniques pour loptimisation de requtes et la
propagation incrmentale des mises jour.
Ce projet permet aussi lvolution de lentrept. Les outils incluent un ensemble
doprateurs, lanalyse et loptimisation des dnitions des vues, la slection optimise de sources de donnes, des stratgies dintgration et des vues matrialises
[JV97, JQJ98, JJQV99, TS99].
Objectifs du projet :
Les objectifs de recherche visent trois domaines, o les facteurs de qualit reprsentent le point central :
- Enrichir la smantique de la mta base avec des models formels de qualit de
linformation qui permettent loptimisation de la conception de faon adaptative et
quantitative.
- Enrichir la smantique des models dinformation qui permettent aussi bien le
rafrachissement incrmental de donnes et leur propagation vers lentrept, que la
rsolution des conits.
- Enrichir la smantique des models de schma de lentrept qui permettent aux
concepteurs de prendre les avantages explicites par rapport la nature temporelle,
spatiale et des agrgats des donnes.
Composants de lentrept de donnes :
Le projet DWQ fournit un modle architectural qui considre la conception, la
mise en oeuvre, la maintenance et lvolution des entrepts. Les composants basics
sont :
- Sources : les donnes stockes dont le contenu peut tre matrialis dans lentrept.
- Adaptateur : responsable du chargement des donnes sources dans lentrept.
- Base de donnes nale : lentrept de donnes et les data marts.
- Mta base : conteneur dinformation des autres composants, par exemple, le
schma des donnes sources.
2.6 Aspects temporels des entrepts
37
- Agents dadministration : concepteurs de lentrept.

- Clients : utilisateurs de linformation.
2.5.4
Projet EVOLUTION
Le projet propose le dveloppement dune mthodologie et dun atelier doutils

de type CASE pour laide la conception et lvolution des entrepts de donnes.
Lobjectif de ce projet est la spcication dun ensemble doutils daide la conception de lentrept et sa maintenance. Deux objectifs sont intgrs dans la cration
de ces outils : prvoir lvolutivit de schma et grer la traabilit des volutions
successives.
Pour atteindre ce but, trois objectifs, correspondant aux problmes de recherches
encore non rsolus sont atteindre :
- La dnition dun formalisme de modlisation des donnes et des mtadonnes
de lentrept, ce formalisme doit permettre la fois de le dcrire et de le manipuler
(pour le faire voluer ou pour vrier ses proprits).
- Des algorithmes de traitement smantique de la triple htrognit de conceptualisation, de temps et de granularit.
- Des algorithmes doptimisation des performances des ressources matrielles et
logicielles de lentrept pour fournir ecacement les outils de Data Mining.
Lapproche envisage propose : lintgration smantique des dirents schmas
sources, la constitution dun schma de lentrept, la dnition et la mise jour des
vues, la prise en compte de limprcision (des donnes mal connues ou incertaines
dans lentrept), la prise en compte du temps et de la granularit, la vrication
de la cohrence et de la consistance et loptimisation des ressources (paralllisme)
[Evo97].
2.6
Aspects temporels des entrepts
Malgr une conception attentive et soigneuse, la structure dune base de donnes est sujette de nombreux changements. Bien que les estimations dirent,
la plupart saccordent sur le fait que plus de 50% du travail des dveloppeurs se
focalise sur les modications du systme aprs leur implantation [Rod95]. Pour rsoudre le problme de perte de donnes aprs des changements du schma, le concept
dvolution de schma t introduit pour rcuprer les donnes existantes. Cette
rcupration se ralise par le biais de ladaptation des donnes au nouveau schma.
Nanmoins, dans les systmes qui doivent grer des donnes historiques, lvolution
38
de schma nest pas susante et la maintenance de plusieurs schmas est requise

[GM02]. Cette problmatique a donne naissance la notion de versions de schmas.
Nous traitons les direntes nuances entre les dnitions de modication, dvolution et de version de schma. Nous commenons avec ltat actuel des versions
dans les dirents modles existants. Ensuite nous traitons le sujet des versions de
schmas, la gestion des donnes intensionnelles et extensionnelles, les changements
et leur reprsentation. Pour nir, la dernire section donne une brve description
des oprations primitives.
2.6.1
Etat courant des versions
Nous tudions ce paradigme dans les divers modles de donnes existants. Ceux
que nous abordons sont le modle relationnel, le modle objets, les bases de donnes
temporelles et nous terminons avec les entrepts de donnes.
2.6.1.1
Modle relationnel
La gestion des volutions dans la structure des bases de donnes a donn naissance
aux concepts de modication, dvolution et de versions de schmas. La distinction
entre les dirents concepts reste un peu imprcise. Dans la suite nous donnons
chaque dnition [DGW+ 98, Rod92, Rod95, TS93] :
La modification de schma dun systme de bases de donnes peut se faire
mme si la base de donnes est dj peuple.
Lvolution de schma dun systme de bases de donnes facilite la modication du schma de la base sans perdre les donnes existantes.
Les versions de schma permettent laccs toutes les donnes, de faon rtrospective et prospective, travers des interfaces de versions dnies par lutilisateur.
A partir de ces dnitions, nous constatons que mme si lvolution de schma
permet leur actualisation, elle nimplique pas un support historique complte du
schma.
Versions et bases de donnes : Dans la suite nous traitons les conditions pour
quune base de donnes supporte la gestion de versions [ABCM99, CW98, KU95,
Mun93].
La fonctionnalit des systmes qui supportent les versions est reprsente par
lensemble des oprations utiliser. Les oprations fondamentales sont la cration
de nouvelles versions et laccs aux donnes des direntes versions. Nanmoins, le
systme doit fournir dautres oprations sur les versions : dnition des noms ou des
identications, eacement, modication, transformer une version dans une version
39
immuable1 , combinaison de versions, etc.

La transparence des versions reprsente la capacit daccder aux donnes sans
avoir la ncessit de manipuler le systme de versions. Il existe trois manires daborder les relations entre le modle de donnes et le modle de versions. La premire
consiste placer le modle de version au-dessus du modle de donnes. De cette
faon, le modle de version est reprsent par un schma dont le modle de donnes
sous-jacent est indpendant du modle de versions. Lavantage de cette solution est
la simplicit du modle de donnes. Par contre, cette approche ne supporte pas le
stockage des versions de faon ecace. De plus, la gestion des transactions du SGBD
ne considre pas le systme de versions. PCTE (Version Management in the PACT
Integrated Software Engineering) et CoMa [CW98, EJWG03] sont deux exemples de
systmes reposant sur cette approche.
La deuxime solution construit un modle de version lintrieur du modle
de donnes. Cette approche requiert lextension du modle de donnes pour supporter les versions, ainsi que la modication du langage de requtes pour fournir
un mcanisme dcriture de requtes une base de donnes supportant des versions. Ce processus dextension du modle complique la structure des donnes ainsi
que la formulation des requtes. De plus, le modle de version dpend fortement
du modle de donnes. Quelques systmes qui suivent cette voie sont DAMOKLES
[CW98, EJWG03] et Adele [Mun93, EJWG03].
La dernire approche reprsente le modle de version en-dessous du modle de
donnes. Dans cette alternative, le modle de version est compltement orthogonal
au modle de donnes. Cette approche peut tre atteinte au travers dun moteur de
version qui fournit un stockage des deltas2 et des rgles de conguration utilises
dans la formulation des modles de version spciques. Le moteur de version est
indpendant du modle de donnes et peut tre associ nimporte quel modle de
donnes. Les systmes qui utilisent cette approche sont par exemple ICE et COV
[CW98].
Pour nir, dans [CGJM01], les auteurs utilisent les versions dentits persistantes
et le partage entre versions des parties ayant mme valeur (quils appellent versions
locales) par plusieurs versions (versions globales), pour prsenter deux approches : ascendante et descendante. La premire utilise lidentication ascendante des versions
locales, le partage incassable (qui permet seulement linsertion de nouvelles versions
et la lecture des versions stockes) et le stockage par entit. Lapproche descendante
utilise lidentication de versions globales, le partage cassable (qui permet en plus
les mises jour des versions) et aussi le stockage par entit. Ils prsentent aussi les
conclusions de chaque approche.
1
2
Une version immuable ne permet pas de changements.

Les deltas reprsentent les diffrences entre versions.
40
2.6.1.2

Modle objets
Dans ce paradigme, deux types de changements sont signicatifs : les changements dans la dnition dune classe (le contenu dun noeud) et les changements
dans la structure (les artes et les noeuds). Ces changements reprsentent lensemble
des oprations primitives qui permettent de manipuler lvolution de la classe. Les
changements dans la dnition de la classe incluent les oprations de cration et
de suppression des attributs et des mthodes qui appartiennent une classe. Les
changements dans la structure, correspondent aux oprations de cration et de
suppression dune classe, ainsi que la modication des relations entre les classes
[MBJ+ 02, GM99, GMS00, FGM00, Lau96, RR97].
Versions de schmas, de classes et de vues : Dans lenvironnement de bases de
donnes multi-utilisateurs, une fonctionnalit importante est la capacit des utilisateurs visualiser et manipuler direntes collections dobjets via direntes versions
de schma. Il existe trois approches pour reprsenter les volutions : la version de
schma, la version de classes et les schmas de vues [Lau96, KC88, FGM00, MS93,
Odb92].
Dans lapproche de versions de schma, chaque version reprsente une conguration cohrente de versions au niveau de la classe. Le systme fournit un ensemble
doprations primitives pour la gestion de lvolution. Quand nous drivons une
nouvelle version de schma SVj partir de SVi , les classes existantes peuvent tre
modies ou eaces et des classes nouvelles peuvent tre cres pour SVj . Si une
classe C est modie, on peut dire que SVi et SVj contiennent direntes versions
de la class C, dnote par SVi .C et SVj .C respectivement. Toutes les versions dun
schma sont stockes dans une structure qui garde les relations de drivation entre
toutes les versions de schmas.
La deuxime approche traite lvolution au niveau de la classe. A la dirence
des versions de schma, si une version nouvelle Vj de la classe C est drive de la
version Vi , toutes les sous-classes de la classe C doivent faire rfrence la nouvelle
version de C. Ceci signie quune nouvelle version doit tre cre pour chacune des
sous-classes de C.
Le schma de vues peut tre utilis pour simuler des modications de schma.
Lide gnrale est de manipuler la base de donnes seulement travers des vues.
Dans ce cas, les changements peuvent tre simuls en changeant les vues et les applications peuvent utiliser direntes vues (comme dirents schmas) sans changer
la base de donnes sous-jacente.
De nombreux travaux [MBJ+ 02, GM99, GMS00, KC88, Lau96] se sont focaliss
sur la premire approche, car elle manipule la granularit de versions au niveau du
schma. Ceci permet une vue globale de lensemble des classes lintrieur dune
version de schma.

2.6.1.3
41
Bases de donnes temporelles
Les bases de donnes temporelles permettent de reprsenter et de manipuler lhistoire des donnes (donnes extensionnelles). Le support de versions de schmas dans
les bases de donnes temporelles prsente deux problmes fondamentaux. Le premier
est le stockage et la manipulation de lensemble de versions de schma appele la smantique du changement. Ce problme implique la vrication et la maintenance de
la consistance du schma aprs des changements. Le second problme reprsente la
gestion et la manipulation des versions de donnes, nomme aussi la propagation des
changements. Cette problmatique concerne la consistance des donnes existantes
avec la nouvelle version du schma [MBJ+ 02, GM02, GMS00, ME97, RGMS01].
Laspect temporel est associ aux objets, aux versions, aux attributs et aux relations. Dans les bases de donns temporelles, le temps de transaction correspond
linstant o un fait est enregistr dans la base. Alors que, le temps de validit dun
fait correspond aux instants auxquels ce fait est vrai dans le monde modlis. Dans
la suite, nous traitons chaque dnition.
Temps de transaction, temps de validit et bitemporel : La manipulation de la dimension temps dans les versions de schma correspond soit la version de schma au temps de transaction, soit au temps de validit, soit les deux.
Cette dernire appele bitemporel, reprsente la combinaison des deux premires
[Dum00, GM02, ME97, Sno99].
Pour le temps de transaction, les modications appliques dans une version de
schma sont eectives au moment de leur dnition. Dans cette approche, la gestion
du temps est transparente lutilisateur. Le schma courant peut tre modi et
les changements sont appliqus sans aucune rfrence au temps. Cette approche ne
permet aucun changement sur les versions successives du schma. Nanmoins, toutes
les versions sont disponibles pour laccs et la manipulation des donnes.
La version de schma en temps de validit est ncessaire quand les modications des versions de schmas rtroactives ou proactives doivent tre supportes.
Dans ce cas, chaque version de schma est assigne une validit temporelle. Cette
approche permet des versions de schmas multiples valides dirents moments.
Toutes les versions de schmas sont disponibles aussi bien pour laccs et la manipulation des donnes, que pour la ralisation des modications futures.
La version de schma bitemporelle reprsente une combinaison du temps de
transaction et du temps valide. Elle supporte les modications des versions de schmas courantes, comme dans la premire approche et aussi les modications des
versions de schmas de faon rtroactive et proactive. Par rapport la version de
schma en temps valide, lhistoire complte des changements du schma est maintenue, car aucune version de schma nest abandonne.
42

Le tableau 2.11 dcrit un exemple de relation bitemporelle en TSQL2 [Sno95].
Nom
SERNA
SERNA
SERNA
Salaire
Temps de transaction
1000
1500
1600
1-07-2000 - 31-12-2000
1-01-2002 - 31-01-2002
1-01-2003 - UC3
Temps de validit
1-07-2000 - 31-12-2001
1-01-2002 - 31-12-2002
01-01-2003 - 31-12-2004
Tab. 2.11 Exemple de relation bitemporelle
2.6.1.4
Le temps et les entrepts de donnes
Les actualisations ralises dans les sources des donnes doivent tre reportes
sur lentrept. Ce processus requiert une transaction de maintenance. Dans les entrepts, une problmatique trs importante est la faon dexcuter les transactions
de maintenance sans perturber les requtes des utilisateurs. La plupart des systmes
commerciaux garantissent la consistance sans blocage, en excutant une seule et
unique transaction de maintenance, normalement pendant la nuit, quand lentrept
est hors de service [QW97].
Les changements eectus dans les sources peuvent tre appliqus aussi bien au
contenu des donnes qu leur structure. Dans [Ben02], lauteur propose une infrastructure adaptable pour lvolution des entrepts de donnes. Il prsente un
ensemble doprateurs dvolution de schmas multidimensionnels, ainsi quun langage de description de donnes multidimensionnelles. Nanmoins, aucun support
historique nest prsent dans ce travail.
En ce qui concerne lapproche des versions de schmas, la plupart des recherches se
sont focalises dans la propagation des changements sur les donnes [KC02, KM99,
QW97, TU98]. Dans [KC02], par exemple, les auteurs proposent un contrle de
concurrence multi-version adapt pour les entrepts de donnes (MVCC-DW) en
utilisant un serveur multidimensionnel OLAP (MOLAP). MVCC-DW permet des
actualisations de lentrept pendant que des requtes sont excutes sur les donnes.
Dans [QW97], les auteurs proposent un mcanisme appel 2VNL (Two-Version
No-Locking). Ce mcanisme permet quune requte puisse continuer utiliser une
vue, alors quune transaction de maintenance crit la nouvelle version de cette vue.
Dans [ZR98, RKZ+ 99], les auteurs proposent une approche pour la maintenance
de la consistance dans un environnement concurrent supportant des changements sur
les donnes et sur leur schma. Ils ont dvelopp un systme appel EVE (Evolvable
3
Le symbole UC (Until Changed) indique que lintervalle de transaction de la version va jusqu
la date daujourdhui.
43
View Environment), qui utilise un langage nomm Evolvable-SQL pour le support

du processus dvolution des vues, et un processus de rcriture de vues pour leur
adaptation quand le schma volue.
Cependant, dans lenvironnement des entrepts nous considrons comme essentielles la gestion et la manipulation des donnes historiques, aussi bien que des donnes courantes. Lapproche des versions de schma a t utilise principalement pour
la cohrence des donnes et de leurs schmas courants. Nous proposons lutilisation
des versions de schma, comme une alternative pour la gestion et la manipulation
des donnes courantes et historiques.
2.6.2
Espace de versions
Dans cette partie, nous traitons de lespace de versions. Dabord, nous ranons
la dnition de version de schma. Ensuite, nous expliquons leurs types ainsi que
les graphes de version, puis, nous terminons avec une description de lensemble des
oprations utiliser lors des changements eectuer.
Versions de schmas : Il est important dans la gestion des versions de distinguer la rcupration et la mise jour des donnes. Pour rpondre ce besoin, le concept de versions de schma a t divis en version partielle et complte
[CW98, Rod95, WMC01] :
Version partielle de schma : Les donnes stockes sous nimporte quel schma
historique peuvent tre visualises sous tout autre schma. Nanmoins les donnes
peuvent seulement tre actualises au travers du schma courant.
Version complte de schma : Les donnes stockes sous nimporte quel
schma historique peuvent tre visualises et actualises sous tout autre schma.
Un modle de version dnit les lments qui ont volus, les proprits communes partages et les deltas. Chaque version doit tre identie de faon unique,
travers un identicateur de version VID. Les deltas reprsentent les dirences entre
deux versions. Un delta peut tre symtrique ou direct.
Un delta symtrique entre deux versions v1 et v2 , reprsente lensemble de diffrences entre elles, cest dire :
(v1 , v2 ) = (v1 - v2 ) U (v2 - v1 )
O le symbole correspond la dnition du delta.
Un delta direct reprsente une squence doprations de changements op1 , ...
,opm . Quand ces changements sont appliqus sur une version v1 , ils produisent une
44
nouvelle version v2 .
(v1 ,v2 ) = op1 , ... ,opm
Cest--dire, v1 gnre v2 : v1 v2
2.6.3
Versions bases sur ltat et sur les changements
Une version est dnie comme un tat dun objet variant dans le temps. Les
modles de versions peuvent considrer les dirents tats des objets. Dans cette
approche, les versions sont dcrites par rapport aux rvisions et aux variantes. Une
rvision est une version qui remplace la prcdente. Lensemble des versions qui coexistent sont appeles des variantes.
Dans les modles bass sur les changements, une version est dcrite par rapport
aux modications. Dans cette approche, chaque changement est aect un identicateur (CID) ainsi que des attributs pour caractriser les causes et/ou la nature
du changement. Ainsi, une version est dcrite par rapport aux changements quelle
implante.
Lespace des changements peut se reprsenter de deux faons (Figure 2.10).
changements
b
c1
c2
c3
c4
c5
c6
c1
v1
c3
c2
v2
versions
c4
c3
v3
v1
c5
v3
v4
c6
c4
v4
v2
a) Reprsentation en matrice
b) Graphe de version avec des

changements explicites
Fig. 2.10 Espace des changements

La partie a) de la gure montre la reprsentation en matrice utilise dans le
systme Aide de camp [CW98, Mun93]. Les lignes et colonnes correspondent des
versions et des changements. Par exemple, lensemble des changements c1 , c2 , c3
et c4 construisent la version v2 . La partie b) reprsente un graphe de versions o b
dnote la racine partir de laquelle tous les changements dune version sont dcrits
de manire explicite. Au contraire, dans lapproche base sur ltat, les changements
45
sont anonymes de faon ce que nous puissions les dduire partir de la topologie
du graphe de version.
2.6.4
Graphes de version
Un graphe de version consiste en un ensemble de noeuds et dartes qui correspondent une version et leur relations [Mun93, CW98]. La plupart des systmes
utilisent une organisation un ou deux niveaux que nous exposons dans la suite.
Types dorganisations Un graphe de version dun niveau consiste en un ensemble de versions qui sont connectes par leurs relations successeurs. Ce type de
graphes reprsente lhistorique de lvolution dun lment. Par exemple, si la version v2 est un successeur de v1 , cela signie que la version v2 a t drive partir
de v1 . La gure 2.11 reprsente dirents types de graphes de version.
v1
v1
v1
v2
v4
v2
v3
v2
v4
v3
v3
a) Squence
b) Arbre
c) Graphe acyclique
Fig. 2.11 Graphes de version un niveau

La partie a) de la gure 2.11 montre le cas le plus restrictif qui reprsente les
versions comme une squence de rvisions. Dans le cas dun arbre b), les noeuds qui
ne sont pas des feuilles peuvent crer des successeurs. Finalement, dans un graphe
acyclique c), nous pouvons avoir des versions avec de multiples prdcesseurs. Dans
lensemble des systmes qui utilisent le type dorganisation un niveau, nous pouvons citer PCTE et DAMOKLES [CW98, EJWG03].
Dans le cas dorganisation deux niveaux, un graphe de version est constitu dun
ensemble de branches, dont chacune est compose dune squence de rvisions. Cette
approche gre deux types de relations : successeurs ( lintrieur dune branche) et
descendants (entre les branches). La gure 2.12 montre ce type dorganisation.
Les changements excuts dans une branche peuvent tre propags aux autres
branches. Nous pouvons avoir comme rsultat un Graphe Direct Acyclique. Nanmoins, les branches ne sont pas relies et elles continuent dexister. Le systme
ClearCase [CW98, EJWG03] utilise cette approche.
46

b1
v1
b3
b2
v1
v2
v1
branche
successeur
descendants
b4
v1
v2
v3
v2
v3
v4
v3
v4
v2
fusion
Fig. 2.12 Graphe de version deux niveaux
2.6.5
Gestion de versions extensionnelles et intensionnelles
La gestion de versions extensionnelles ou de versions de donnes, concerne la reconstruction de versions cres priori. Elle requiert lidentication de la version
(VID) et limmutabilit de la version. Une version est immuable si elle nautorise
pas de changements, ce qui permet dassurer une rcupration sre des donnes.
Finalement, la reconstruction de versions demande aussi un systme de stockage
ecace [CW98, ME97, MBJ+ 02].
En ce qui concerne la gestion de versions intensionnelles (ou versions de schmas), elle traite de la construction de nouvelles versions partir des descriptions
bases sur des proprits. Cette approche est trs utilise quand un logiciel volue
en plusieurs rvisions et variantes o beaucoup de changements doivent tre combins. Les systmes qui supportent des versions intensionnelles doivent fournir un
mcanisme pour rsoudre le problme dexplosion des combinaisons et de contrle
de cohrence. Ce mcanisme permet seulement la construction de versions pouvant
satisfaire certaines contraintes [CW98, ABCM99].
Dans [ABCM99], les auteurs prsentent un modle uni de versions extensionnelles. Ce modle utilise un mcanisme appel version concentration pour rduire le
nombre de combinaisons prendre en compte. Dans [MBJ+ 02], les auteurs utilisent
un modle temporel de version (TVM) pour permettre le stockage de versions dobjets, ainsi que toute lhistoire des changements pour chaque version. Finalement,
dans [GM02], les auteurs prsentent un modle formel pour des versions temporelles
de schmas dans les bases de donnes orientes objets. Ils proposent un schma volu qui consiste en une collection de versions de schmas dnies sur un ensemble
de noms de classes et dattributs.
47
2.7 Bilan
2.6.6
Oprations primitives
La possibilit de supporter des changements de schmas est reprsente par un

ensemble de primitives qui permettent aussi bien des changements au niveau de la
structure du schma, que la mise jour des donnes extensionnelles. La liste des
oprations primitives dnies par un modle de donnes particulier reprsente lensemble de changements possibles excuter sur le modle. Par exemple, dans le
contexte des bases de donnes orientes sujets [Lau96, GM99], cette liste a t groupe en : changements de schma sur un noeud et changements de schma sur des
artes. La premire catgorie groupe les oprations agissant sur les lments supports par le modle de donnes orientes-sujets, comme les attributs et les classes.
Tandis que les changements sur des artes fournissent le support pour lintgration
des caractristiques dune version de schma avec des versions de schmas appartenant dautres noeuds.
En plus, dans [GMS00, GM02] les auteurs introduisent la notion de temps pour la
cration des versions temporelles. A chaque version temporelle nouvelle est associe
un temps-valide pertinent. Ainsi, les donnes stockes peuvent tre accdes par le
biais des versions de schmas du pass, du prsent et du futur.
2.7
Bilan
Dans ce chapitre, nous avons trait le sujet des entrepts de donnes qui tendent
les concepts et la technologie traditionnelle des bases de donnes pour crer des systmes daide la dcision.
En utilisant larchitecture dun entrept de donnes, nous avons expliqu les diffrents composants quil intgre, comme les diverses sources, les types de donnes
et les dirents outils pour arriver la visualisation de linformation. Nous avons
dcrit les dirents modles multidimensionnels pour la construction dun entrept
de donnes, ainsi que les direntes oprations pour la manipulation des donnes
multidimensionnelles.
Lavant dernire partie a t consacre aux types de serveurs dcisionnels. Dans
un premier temps, nous avons dcrit le serveur ROLAP qui utilise une base de donnes relationnelle, tant au niveau du stockage quau niveau de la gestion de donnes.
Dans cette architecture, les stratgies doptimisation reprsentent le point principal
qui distingue les systmes existants. Nous avons donn galement une description
des systmes ROLAP existants sur le march.
Le serveur MOLAP a t la deuxime architecture que nous avons traite. Ces
types de systmes utilisent une base de donnes multidimensionnelle pour le stockage des donnes. Les systmes MOLAP doivent grer le problme de donnes
clairsemes, quand seulement un nombre rduit des cellules dun cube contiennent
48
une valeur de mesure associe. La faon de rsoudre cette problmatique, par les
produits commerciaux, reprsente un des plus importants critres pour les systmes
MOLAP. Nous avons aussi donn une liste des produits existants.
La troisime architecture que nous avons dcrite est le serveur HOLAP. Un systme de ce type supporte et intgre un stockage de donnes multidimensionnelles et
relationnelles. La plupart des systmes commerciaux utilisent une approche hybride
pour manipuler les informations de lentrept avec un moteur ROLAP, tandis que
pour la gestion des magasins des donnes (data marts), ils utilisent lapproche MOLAP. Finalement, nous avons dcrit quelques produits commerciaux existants.
En ce qui concerne les projets de recherche dans le domaine des entrepts de donnes, nous avons dcrit succinctement WHIPS, SIRIUS, DWQ et EVOLUTION. Les
deux premiers sont centrs sur des problmatiques lies lextraction et la maintenance incrmentale des donnes. Le projet de la communaut Europenne DWQ
traite de la qualit des entrepts, tandis que le dernier, le projet EVOLUTION du
laboratoire PRiSM Paris, propose le dveloppement dune mthodologie et doutils
pour laide la conception et lvolution des entrepts.
Dans la dernire partie, nous avons dcrit lapproche des versions de schma.
Dabord nous avons donn ltat courant des versions dans les modles de donnes
existants. Ensuite nous avons dcrit lespace de versions, leurs types, la gestion de
donnes extensionnelles et intensionnelles, ainsi que les oprations primitives utiliser.
En ce qui concerne lvolution de schmas, elle permet la rcupration des donnes
existantes par le biais de leur adaptation au nouveau schma. Nanmoins, lvolution
nimplique pas un support historique du schma et par consquent ne considre pas
un mcanisme pour la visualisation des donnes travers des schmas volus. Dans
le paradigme des entrepts la manipulation de donnes historiques reprsente une
tche essentielle. Par consquent le concept dvolution de schma nest pas susant
et il est ncessaire tablir une stratgie spcique pour rpondre cette ncessit.
Nous considrons lapproche de versions de schma comme une alternative aux
systmes qui doivent grer et manipuler des donnes historiques. Dans le cas prcis
du projet ADELEM, nous proposons lutilisation de versions de schma pour grer
les aspects temporels de lentrept de donnes. Pour aboutir cela, nous devons
tablir un mcanisme pour la gestion, le stockage et la visualisation de lensemble
de donnes (courantes et historiques) mdicales.
Nous prsentons dans la suite une architecture et un modle que nous proposons
pour un systme dcisionnel dans le contexte mdical.
Chapitre 3
Architecture et modle pour un
entrept de donnes mdicales
La conception dun entrept de donnes est une tche complexe et dlicate. Elle
se compose de plusieurs tapes. Dans un premier temps, nous devons analyser lensemble des sources de donnes internes et externes. Cette analyse sert aussi bien
la slection de lensemble de donnes stocker dans lentrept, qu la slection
des outils requis pour lextraction et la transformation de ces donnes avant leur
stockage. La deuxime tape consiste organiser ces donnes lintrieur de lentrept. Pour ce faire, nous devons concevoir le modle multidimensionnel utiliser
ainsi que dnir lensemble optimal de vues matrialiser. Finalement, la troisime
tape consiste dterminer les outils ncessaires pour la visualisation de lensemble
des donnes.
Dans le chapitre prcdent, nous avons prsent larchitecture typique dun entrept de donnes. Dans cette architecture, nous trouvons les trois tapes dj dcrites :
extraction-intgration, organisation et interrogation. Nanmoins, en ce qui concerne
le concept dorganisation, nous considrons quil est pertinent de faire une distinction entre la structuration et lorganisation. Pour nous le terme de structuration
correspond la conception du modle multidimensionnel et la slection des vues
matrialiser, tandis que lorganisation entrane la gestion de lensemble de donnes
(intensionnelles et extensionnelles) courantes et historises stockes soit lintrieur,
soit lextrieur de lentrept.
Ce chapitre prsente la premire partie du processus de structuration, savoir, la description de la conception dun modle multidimensionnel. Nous proposons dabord une architecture pour un systme dcisionnel. Cette architecture comprend trois composants qui traitent les deux derniers processus (la structurationorganisation et linterrogation). Dans une deuxime partie, nous dnissons un mtamodle multidimensionnel qui est compos de trois classes : Cube, Dimension et
Hirarchie. Ce mtamodle sert la conception dun modle multidimensionnel avec
quatre dnitions : le schma dune base multidimensionnelle, dun cube, dune dimension et dune hirarchie. Nous donnons aussi la dnition dinstances de chacune
49
50
Architecture et modle pour un entrept de donnes mdicales
des classes.
Nous avons utilis des donnes mdicales relles, ainsi, les dernires parties de ce
travail prsentent lapplication de notre modle sur ces donnes.
3.1
Architecture dun systme dcisionnel
Dans cette partie, nous dcrivons larchitecture qui a t conue. Elle est base
sur trois composants. Le premier est lInterface pour la Gnration (Semiautomatique) dIndicateurs. Nous plaons ce composant lintrieur du processus dinterrogation. Les composants de lEntrept de donnes et les Versions de
Schmas Bitemporels font partie du processus de structuration-organisation.
La gure 3.1 montre notre architecture ainsi que les dirents liens entre les composants :
Interface graphique
Gestionnaire de Requtes
Entrept de
donnes
Sources
de
donnes
s
u
l
t
a
t
Gestionnaire dEvolution
Donnes rsumes
et de dtail
courantes
Fig. 3.1 Architecture propose dun systme dcisionnel
3.1.1
Interface graphique pour la Gnration (Semi - automatique) dIndicateurs
Nous dcrivons les principaux lments de linterface graphique [SA04] :

Interface Graphique : Outil graphique o les utilisateurs peuvent choisir les
divers composants (relations, mesures et proprits) correspondant lindicateur
3.2 Mtamodle Multidimensionnel
51
exprim. Lobjectif de linterface est de faciliter la gnration semi-automatique des

requtes.
Gestionnaire de Requtes : Composant pour traduire le mta-schma en schma
local (relationnel), pour gnrer le code SQL et pour excuter la requte sur les donnes de lentrept.
Rsultat : Les donnes qui correspondent la requte et qui doivent tre aches
par linterface graphique.
Le chapitre 4 contient une description dtaille de notre interface.
3.1.2
Entrept de donnes
Entrept de Donnes : Reprsente la collection des donnes consulter. Lentrept contient aussi bien des donnes de dtail que rsumes. Par exemple :
Donnes de dtail : "Le nombre de ventes par magasin, par produit et par ville
du mois de janvier 2000".
Donnes rsumes : Nous pouvons avoir des donnes lgrement ou fortement
rsumes. Par exemple, "les ventes mensuelles par magasin et par produit des dix
dernires annes" sont des donnes faiblement rsumes, tandis que "les ventes semestrielles par rgion des dix dernires annes" sont fortement rsumes.
Sources : Elles rassemblent lensemble de sources internes, par exemple, les dirents systmes oprationnels qui sont utiliss pour mettre jour les donnes stockes
dans lentrept. Les sources externes sont des donnes qui nappartiennent pas
lentreprise et qui sont souvent achetes, par exemple, les donnes gographiques.
3.1.3
Il est responsable de la gestion, du stockage et de la visualisation des donnes

historises. Nous proposons lutilisation des versions de schmas bitemporels pour
la gestion de lvolution des donnes intensionnelles et extensionnelles. Le chapitre
5 dcrit en dtail ce composant.
3.2
Mtamodle Multidimensionnel
Il reprsente la structure pour la mise en oeuvre des modles de type multidimensionnel (cf. Section 2.3) qui se compose des mtaclasses1 . La gure 3.2 montre les
1
Une mtaclasse est une classe qui modlise des classes [PCTM02, PCTM03]. Nous avons utilis
UML (Unified Modeling Language) pour la spcification du mtamodle multidimensionnel.
52
Mtaclasses Cube, Dimension et Hirarchie qui constituent notre MtaSchma.
<<Mtaclasse>>
MtaSchma
+/cube: Cube
+/dimension: Dimension
1
1..
1..
+Strings[]: Attribut_nom
+Strings[]: Type
+Strings[]: Cl_P
+Strings[]: Cl_E
+/hirarchie: Hirarchie
+Strings[]: Mesure_nom
+Strings[]: Type
+Strings[]: Cl
+/dimension: Dimension
1..
*
{La Cl de la mtaclasse
Cube est compose de
lensemble des Cl_P de ses
mtaclasses Dimensions}
1..
1..
{La Cl_P est

contenu ou est
gale lensemble
Attributs_noms}
*
{La Cl_P dune
mtaclasse
Hirarchie ne
peut pas relier
la mtaclasse
Cube associe
sa mtaclasse
Dimension
(granularit)}
<<Mtaclasse>>
Dimension
<<Mtaclasse>>
Cube
0..1
<<Mtaclasse>>
Hirarchie
+Strings[]:
+Strings[]:
+Strings[]:
+Strings[]:
0..
Attribut_nom
Type
Cl_P
Cl_E
Fig. 3.2 Mtamodle Multidimensionnel

La spcication du notre mtamodle, nous permet de reprsenter et de visualiser
les dirents composants. Ceci, nous a permis dabord pour identier les associations
et leur cardinalit, mais principalement pour identier lensemble de restrictions, soit
niveau des associations, soit lintrieur dun composant.
3.2.1
Relations entre les mtaclasses
Pour relier les mtaclasses, nous pouvons utiliser les types de relations suivants
[PCTM03, Var00, VQVJ00] :
Association : Cest une relation entre deux classes qui reprsente les connections
entre leurs objets. Une association est bidirectionnelle ou unidirectionnelle.
Agrgation : Elle spcie une relation de composition et peut tre :
Partage : Un lment composant lintrieur dun ou de plusieurs lments composites ; ou
53
Compose : Lensemble de composants intgre llment composite.

Gnralisation : Cest une relation entre une classe plus gnrale et une classe
plus spcique.
Dpendance : Cest une relation entre deux classes o les changements appliqus
sur la classe indpendante aectent la classe dpendante.
3.2.2
Contraintes entre les mtaclasses
Les contraintes permettent de complter la spcication du mtamodle. Ils existe

deux types de contraintes : syntaxiques ou smantiques. Par exemple, la contrainte :
une classe est reprsente graphiquement par un rectangle compartiment, est une
contrainte syntaxique. Nous avons class les contraintes smantiques de la manire
suivante :
Contraintes de cardinalit : Reprsentent le nombre de liens qui peuvent exister
entre deux classes. Par exemple : 0..1 (zro ou un), 1 (un et un seul), * (zro
plusieurs), M..N (de M N),...
Contraintes dintgrit rfrentielle : Reprsentent le fait quun ensemble
dattributs qui appartient une classe apparat dans une autre classe. Par exemple,
soient r1 (R1 ) et r2 (R2 ) deux classes avec les cls primaires C1 et C2 . Le sous-ensemble
de R2 est une cl externe qui fait rfrence C1 de r1 , si pour chaque t2 de r2
existe une n-uplet t1 de r1 tel que t1 [C1 ] = t2 [].
Pour dcrire des contraintes additionnelles qui ne sont pas exprimes directement par la structure du mtamodle, nous pouvons utiliser le langage OCL (Object
Constraint Language) fourni par UML ou dcrire les contraintes en langue naturelle.
Par exemple, nous avons la contrainte : {La Cl_P dune mtaclasse Hirarchie
ne peut pas relier la mtaclasse Cube associe sa mtaclasse Dimension (granularit)}.
3.2.3
Description des Mtaclasses
Nous dcrivons les mtaclasses qui composent le mtamodle multidimensionnel :

Mtaclasse MtaSchma : La mtaclasse MtaSchma est compose des mtaclasses Cube et Dimension. Elle reprsente un schma multidimensionnel compos
des classes Cube et Dimension.
54
Mtaclasse Cube : La mtaclasse Cube modlise des classes de type Cube. Elle
reprsente les direntes mesures danalyse. Une mtaclasse Cube est reprsente
par deux ensembles de couples :
h Mesure_nom : string, Type : string i reprsentent le(s) sujet(s) danalyse.
h Cl : string, Type : string i reprsentent lensemble des mtaclasses Dimensions (perspectives danalyse) qui appartiennent la mtaclasse Cube.
Mtaclasse Dimension : Cette mtaclasse modlise des classes de type Dimension. Elle reprsente une perspective danalyse ou un axe de localisation dune cellule
dun Cube. Une mtaclasse Dimension est compose densembles de couples de
type :
h Attribut_nom : string, Type : string i ensemble dattributs textuels
lintrieur de la classe Dimension.
h Cl_P : string, Type : string i identicateur unique pour la classe Dimension.
h Cl_E : string, Type : string i reprsentent des liens entre les classes
Dimension et Hirarchie.
Mtaclasse Hirarchie : Elle reprsente les relations de dpendance entre les
niveaux lintrieur dune classe Hirarchie. Une mtaclasse Hirarchie est compose des ensembles de couples de type :
h Attribut_nom : string, Type : string i reprsentent des paramtres textuels dans la classe Hirarchie.
h Cl_P : string, Type : string i identicateur unique pour la classe Hirarchie.
h Cl_E : string, Type : string i reprsentent des liens entre les classes de
type Hirarchie.
3.2.4
Dfinition dun modle multidimensionnel
Un modle multidimensionnel est une instance de la mtaclasse MtaSchma.

Nous lappelons classe ModleMultidimensionnel (MM). Nous utilisons les descriptions des mtaclasses de la section prcdente pour aboutir la dnition dune
base de donnes multidimensionnelle. Nous sommes partis de travaux existants
[Ben02, GM02, HMV99a, HMV99b, LW96, Qui99] pour la dnition dun schma
et dune instance. La plupart des travaux proposent un ensemble doprateurs pour
55
lvolution dun systme multidimensionnel. Dans [GM02], lauteur propose un modle formel des versions de schmas temporelles pour des bases de donnes objets.
Nous faisons la dirence entre une dimension et une hirarchie. Ainsi, notre modle se compose de quatre lments essentiels : une base multidimensionnelle, un
cube, une dimension et une hirarchie. Nous donnons pour chacun la dnition de
schma et dinstance. Nous supposons lexistence de :
S
S
S
S
DOM = dom(char) dom(integer) dom(oat) dom(decimal) dom(date)
S
{t} contenant le domaine de chaque type atomique plus la valeur distingue t.
C = Ensemble de noms de cubes.
D = Ensemble de noms de dimensions.
H = Ensemble de noms de hirarchies.
M = Ensemble de noms de mesures.
P = Ensemble de noms de proprits.
L = Ensemble de noms de niveaux.
R = Ensemble de contraintes.
Nous associons chaque cube cC un ensemble de valeurs {a1 , ..., a n } tel que
i=1,...n ai DOM. De mme pour chaque dimension dD, nous associons un ensemble
de valeurs {b1 , ..., bn } tel que i=1,...n bi DOM. Finalement, pour chaque niveau lL,
nous associons un ensemble de valeurs {f1 , ..., fn } tel que i=1,...n fi DOM.
Nous supposons lexistence des fonctions suivantes :
measuredom : M E(DOM)2 , qui retourne lensemble des valeurs associes
une mesure.
propertydom : P E(DOM), qui retourne lensemble des valeurs associes
une proprit.
levelset : H E(DOM), qui retourne lensemble des membres associs un
niveau.
Dfinition 3.1 : Schma de base de donnes et dinstance multidimensionnelle.
Le schma dune base de donnes multidimensionnelle est un n-uplet SM = (Cs ,
Ds , Hs , R), o Cs est un ensemble de schmas de cubes, Ds est un ensemble de
schmas de dimensions, Hs est un ensemble de schmas de hirarchies et R est un
ensemble de contraintes.
2
Lensemble E(A) est lensemble des parties de A. E(A) = {X|X A}.
56
Linstance dune base multidimensionnelle est un n-uplet IM = (Ci , Di , Hi , Ri ),

o Ci est un ensemble dinstances de cubes tel que, pour chaque instance ci Ci , il
existe un schma cs Cs avec ci conforme cs . Di est un ensemble dinstances de
dimensions tel que, pour chaque instance di Di , il existe un schma ds Ds avec di
conforme ds . Hi est un ensemble dinstances de hirarchies tel que, pour chaque
instance hi Hi , il existe un schma hs Hs avec hi conforme hs . Finalement, Ri
est un ensemble dinstances de contraintes tel que chaque instance ri Ri .
Dfinition 3.2 : Schma et instance du cube.
Un schma de cube est un n-uplet Cs = (cn , M, D), o cn C est le nom du cube,
M est un ensemble de mesures et D est un ensemble de dimensions.
Une instance de cube est un ensemble de cellules. Une cellule est un n-uplet Ic =
(cn , {v1 ,...,vk }, {d}), o cn est le nom du cube, {v1 ,...,vk } est lensemble de mesures
tel que i=1,...n vi measuredom(mi ) avec mi M et dD est lensemble de dimensions.
Par exemple, la gure 3.3 reprsente le schma et linstance du cube Ventes.
Produit
TV
Produit
Magasin
CS
S
U
M
CP
Lyon
Grenoble
Annecy
Magasin
SUM
01/01/2000
Quantit
Temps
02/01/2000
Temps
03/01/2000
SUM
All
Schma du cube Ventes
Instance
Fig. 3.3 Schma et une instance possible du Cube

La partie gauche montre le schma du cube de nom Ventes. Lensemble {Temps,
Magasin, Produit} sont les axes du cube et la mesure est Quantit. La partie droite
montre une instance de ce cube. Par exemple, nous avons 100 Tlviseurs vendus
dans le magasin dAnnecy le 1er janvier 2000.
Dfinition 3.3 : Schma et instance de dimension.
Un schma de dimension est un n-uplet Ds = (dn , P, H), o dn D est le nom de
la dimension, P est lensemble de proprits de la dimension dn et H est lensemble
57
de hirarchies.
Une instance de dimension est un n-uplet Id = (dn , {(v1 ,...,vi )}, {h}), o dn D
est le nom de la dimension, (v1 ,...,vi ) est un ensemble de proprits tel que j=1,...n vj
propertydom(pj ) avec pj P. Enfin, hH est lensemble de hirarchies qui appartiennent dn .
Par exemple, le schma de la dimension Magasin est dni de la manire suivante :
dn = Magasin
{p1 ,...pi } = {Cle_Magasin, Libelle_Magasin }
hn = H_Geo (cf. Dnition 3.4)
Schma et instance de hirarchie.
Pour nous un schma et une instance de hirarchie peuvent prendre la forme dun
graphe squentiel ou dun graphe acyclique dirig reprsentant les hirarchies de niveaux. Chaque noeud du graphe contient un niveau et un arc entre deux noeuds
reprsente une association entre les niveaux contenus par les noeuds. Nous supposons lexistence de deux noeuds, nomms base et sommet, partir desquels tous
les autres noeuds peuvent tre atteints directement ou par transitivit. Le noeud
sommet contient le niveau de la hirarchie. La gure 3.4 prsente un exemple de
graphe squentiel. Comme exemple de graphe acyclique dirig, nous pouvons considrer le schma de hirarchie suivant : H_Temps = ({(Jour, Mois), (Mois, Semestre),
(Semestre, Annee)}, {(Jour, Semaine), (Semaine, Annee)}), o la base=Jour et le
Sommet=Annee. Dans notre modle, nous considrons les caractristiques suivantes :
1. Nous distinguons les termes de dimension et de hirarchie. Ainsi, une dimension peut relier 0, une ou plusieurs hirarchies. Pour une hirarchie donne, il
y a une liaison directe avec la dimension associe dans le cube. Par exemple, si
le cube Ventes comporte la dimension Magasin relie une commune, ce cube
sera alors indirectement li aux niveaux suprieurs commune (Dpartement,
Rgion, ). Ainsi, il sera possible deectuer des agrgats sur ces niveaux
suprieurs.
2. Nous pouvons insrer un niveau de hirarchie soit ct de la hirarchie dj
dnie soit lintrieur. Pour faire cela, nous avons besoin de spcier trois
niveaux, le premier est le niveau insrer, les deux derniers reprsentent les
niveaux infrieur et suprieur partir desquels le nouveau niveau sera plac.
3. Dans la dnition du schma de hirarchie, nous considrons le cas o l=,
cest dire quand nous avons seulement les niveaux base et sommet.
Nous donnons dans la suite la dnition de schma et dinstance de hirarchie.
58

Dfinition 3.4 : Schma et instance de hirarchie.
Un schma de hirarchie est un n-uplet Hs = (hn , L, ), o hn H est le nom de la

hirarchie, L est lensemble de niveaux lintrieur de la hirarchie hn et le symbole
est une relation de dpendance entre les niveaux telle que sa fermeture transitive
et rflexive * reprsente un ordre partiel dans L. Il existe un seul niveau l tel que
(i) si l6=, lL l * l lL l * et (ii) si l=, l * . Un niveau lj L
est un niveau immdiatement suprieur (relation de dpendance) de li L si li lj .
Une instance de hirarchie organise les proprits participant aux hirarchies
dagrgation. Pour chaque arc dans un schma de dimension, il existe une fonction de RUP (rollup, cf. Dnition dinstance en-dessous) associe.
S
Une instance de hirarchie est un n-uplet Ih = ( li L levelset(li ), RUP), o RUP
l
est un ensemble de fonctions ruplji tel que (i) (l1 , l2 ) L tels que l1 l2 , il existe
une fonction rupll21 : levelset(l1 ) levelset(l2 ) et (ii) (l1 , l2 , l3 ) L tels que l1
l2 et l2 l3 , ran(rupll21 ) dom(rupll32 ).
Par exemple, dans la gure 3.4, la partie gauche prsente le schma de la hirarchie H_Geo. Il est dni de la manire suivante : hn est le nom de la hirarchie
H_Geo, lensemble de proprits (niveaux) lintrieur de la hirarchie est {Commune, Dpartement, Rgion, } et la relation est reprsente par {(Commune,
Dpartement), (Dpartement, Rgion), (Rgion, )}.
Region
Rhne Alpes
Departement
Commune
Schma
...
Isre
Lyon
Grenoble
...
Annecy
Instance
Fig. 3.4 Schma et une instance possible de la hirarchie H_Geo
3.3 Analyse des donnes dune application mdicale
59
La partie droite montre une instance possible de ce schma. La fonction rupDepartement

Commune
met en relation les proprits Lyon, Grenoble et Annecy du niveau Commune avec la
proprit Isre du niveau Departement. Les proprits du niveau Region sont mises
en relation avec la proprit unique t du niveau .
Le reste du chapitre montre une application de notre modle. Nous utilisons des
sources de donnes relles et un ensemble dindicateurs dans le cadre du projet
ADELEM.
3.3
Analyse des donnes dune application mdicale
Cette section est consacre lanalyse des donnes du projet. Dabord, nous
analysons lensemble des sources existantes, ce qui nous permet didentier deux
types de donnes, les donnes publiques concernant la sant (RSA, RHA, CIM10 et
FINESS) et les donnes dmographiques (RP99) [Bel02].
3.3.1
Sources de donnes
Nous dcrivons les chiers RSA (Rsums de Sorties Anonymes), RHA (Rsum
Hebdomadaire Anonyme), FINESS (Fichier National des tablissements Sanitaires
et Sociaux), CIM10 (Classication International de Maladies version 10). Ces chiers
sont htrognes et rpartis et ils devront tre intgrs (les prparer, les nettoyer,
les transformer, etc.), avant leur stockage dans lentrept de donnes.
Fichier RSA (Rsums de Sorties Anonymes) Tout sjour hospitalier, effectu dans la partie court sjour dun tablissement, fait lobjet dun Rsum de
Sortie Standardis RSS). Un RSS est constitu dun ou plusieurs Rsum(s) dUnit
Mdicale (RUM). La transmission dinformations mdicales la direction de ltablissement ou lextrieur de celui-ci, sopre sur la base de donnes agrges ou
Rsums de Sortie Anonymes (RSA).
Le chier RSA est obtenu par transformation automatise des RSS. A partir du
chier de RSS groups, le mdecin responsable du DIM (Dpartement dInformation
Mdicale) utilise le logiciel GENRSA (Gnrateur de RSA), proprit de lEtat, pour
produire le chier de RSA. Le RSA comprend toujours un enregistrement unique
par sjour (environ 15 18 millions denregistrements pour chaque anne) [PMS04].
Caractristiques du chier :
-
Propritaire : Agence Rgionale dHospitalisation

Type du chier : Texte (ASCII xe) ou Access
Anne : 2000
Mode dobtention : gratuit
Mise jour : annuelle
60

- Taille : 11 Go
Fichier RHA (Rsum Hebdomadaire Anonyme) Il comprend environ 1600

tablissements avec 28 millions de journes dhospitalisation qui correspondent 18%
de lactivit hospitalire. Etant donne que la moyenne dun sjour est denviron 35
jours, nous avons calcul une taille de 4 millions denregistrements hebdomadaires
annuels ((28000000 / 35)*5) pour le chier RHA.
Les objectifs sont doubles : le premier est la poursuite de soins mdicaux et de
rducation, le deuxime est la radaptation (sociale, professionnelle, scolaire,...)
[PMS04].
- Propritaire : Agence Rgionale dHospitalisation
- Type du chier : Texte (ASCII xe) ou Access
- Mode dobtention : gratuit
Fichier FINESS (Fichier National des tablissements Sanitaires et Sociaux) Recense les structures sanitaires et sociales au niveau national (5079 tablissements pour la France Mtropolitaine) [SMS04].
-
Propritaire : Ministre Charg des Aaires Sanitaires et Sociales

Type du chier : Texte (ASCII xe) au Excel
Anne : 2000
Mode dobtention : gratuit
Mise jour : annuelle
Taille : 2.24 Mo
Fichier CIM10 (Classification International de Maladies version 10) Ce

chier contient le code et le libell pour chaque maladie (diagnostic) environ 17694
enregistrements. La taille du chier est de 1.34 Mo.
Dans la suite, nous dcrivons la source de donnes dmographiques RP90/99
(recensement de la population de 1990 et 1999).
Fichier RP90/99 Ce chier recense la population de chaque commune rpartie
en 96 tranches dge : < 1 an, 1 an 2 ans, ..., 95 ans et plus. Les communes sont
dsignes par leurs codes administratifs et leurs intituls.
61
3.3 Analyse des donnes dune application mdicale
- Propritaire : INSEE
- Type du chier : BDF
- Anne : 1999
- Mode dobtention : achat
- Taille : 50.8 Mo (chier avec tranches dge dhommes et de femmes par commune)
Lannexe A contient une description en dtail des sources RSA et FINESS.
3.3.2
Analyse des donnes
Dans cette partie nous analysons les direntes sources dcrites prcdemment
pour proposer des mcanismes adapts selon les caractristiques des informations.
Nous proposons dabord un tableau qui contient les proprits des sources. Ensuite,
nous donnons un tableau danalyse de donnes en considrant une dizaine dannes
de stockage.
Le tableau 3.1 dcrit les direntes proprits des sources :
Source
Propritaire
RSA
ARH
RHA
ARH
FINESS
MCASS
CIM10
RP90/99
OMS
INSEE
Type de fichier
Texte (ASCII fixe)
ou Access
Texte (ASCII fixe)
ou Access
Texte (ASCII fixe)
ou Access
Excel
DBF
Mode
dobtention
Taille
Anne
Mise jour
Gratuit
11 Go
2000
Annuelle
Gratuit
3 Go
2000
Annuelle
Gratuit
2.24 Mo
2000
Annuelle
Achat (625,04)
1.34 Mo
50.8 Mo
1995
1999
Tous les 9 ans3
Tab. 3.1 Description des sources de donnes

Le tableau prcdent indique les caractristiques essentielles prendre en compte
lors des premires phases de la conception dun entrept. Nanmoins, si nous reprenons les deux dernires proprits, lanne et la mise jour, pour les reprsenter
dans un tableau 3.2 qui aura des donnes sur 10 ans, nous avons les caractristiques
des donnes historises.
Lanalyse du tableau prcdent, nous permet de remarquer les sources RSA (Rsums de Sortie Anonymes) et RHA (Rsums Hebdomadaire Anonymes). Leurs
3
Il a t dcid une mise jour annuelle des rsultats du recensement par le biais dune nouvelle
mthode de collecte. Le dpart de cette nouvelle collecte a t fix au dbut de lanne 2004 pour
obtenir les premiers rsultats la fin de lanne 2008. A partir de cette anne (2008) des rsultats
rcents et rguliers seront publis sur la population de chaque commune, avec une anciennet
maximale de trois ans.
4
A partir de 2008.
62

Source
Taille
RSA
RHA
FINESS
CIM10
RP90/99
110 Go
30 Go
22.4 Mo
13.4 Mo
508 Mo
Optimisation
du stockage
Rafrachissement
Requtes
complexes
Agrgats
Evolution
du schma
Oui
Oui
Non
Non
Oui
Annuel
Annuel
Annuel
Oui
Oui
Non
Non
Non
Oui
Oui
Non
Non
Oui
Oui
Oui
Oui
Oui
Oui
Annuel4
Tab. 3.2 Caractristiques des sources de donnes historiques

tailles nous obligent rechercher des mcanismes doptimisation pour le stockage
(partitionnement, paralllisme, agrgats) et pour traiter des requtes complexes.
Une autre partie grer est lvolution du schma, pour prendre en compte des
changements dans la structure logique de la source et qui peuvent avoir des rpercussions sur la structure logique de notre entrept, voire laecter. Ceci nous oblige
proposer une conception adaptable de lentrept de donnes pour mieux intgrer
ces changements notre schma.
Dans les chapitres suivants, nous reprenons cette problmatique. Par exemple,
pour le cas du volume de stockage grer, nous devons dnir lensemble optimal
des vues matrialiser en considrant leur cot de calcul pour la matrialisation et
leur cot de stockage (cf. Chapitre 4). Par rapport lvolution du schma, nous
proposons (cf. Chapitre 5) lutilisation des versions de schmas bitemporels pour
la gestion des aspects temporels de lentrept de donnes. Pour cette raison, nous
avons dcid de garder toutes les donnes, mme celles qui ne changent pas, car elles
formeront les versions historises annuelles.
3.4
Classification des indicateurs du projet
Nous numrons les divers indicateurs, qui ont t crs pour le projet ADELEM.
Nous les avons diviss en trois types, les deux premiers rassemblent les dirents indicateurs crs par le Laboratoire de Biomtrie et Biologie de Lyon (les indicateurs
dore "gographiques" et les indicateurs de consommation, de besoins et de ux
"temporels"). Le troisime type sont des indicateurs que nous proposons, ils correspondent des indicateurs "temporels", quil est intressant de prendre en compte.
Dans les divers types dindicateurs, il existe des valeurs qui sont des paramtres
de la requte. Par exemple dans lindicateur : "Nombre de sjours par maladie de
ltablissement CHU GRENOBLE durant le 1er janvier 2000", nous trouvons pour
lattribut Raison_sociale de la dimension Etablissement la valeur "CHU GRENOBLE" ainsi que la valeur "01-01-2000" pour lattribut Jour de la dimension Temps.
3.4 Classification des indicateurs du projet
3.4.1
63
Indicateurs doffre (gographiques - spatio-temporels)
Reprsentent des ressources que possde chaque tablissement, et qui permettent

de constater sur une carte la rpartition dores, en fonction des besoins sanitaires
dans le systme de soins dune Rgion.
Indicateur dore 1 : Localiser sur une carte tous les tablissements de court sjour en faisant apparatre leur capacit en nombre de lits MCO (Mdecine-ChirurgieObsttrie).
Indicateur dore 2 : Localiser sur une carte toutes les maternits avec leur niveau
(I, II ou III).
Niveau I : Maternit sans service de ranimation ou de nonatalogie.
Niveau II : Maternit avec un service de nonatalogie.
Niveau III : Maternit avec un service de ranimation nonatale.
Indicateur dore 3 : Reprsenter un ou plusieurs indices dattraction pour chaque
tablissement.
3.4.2
Indicateurs de consommation, de besoins et de flux

(temporels)
Cette section rassemble des indicateurs de trois types : consommation de soins,

besoins et ux de patient.
a) Indicateurs de consommations de soins : Ils dcrivent les sjours dans les
dirents tablissements de soins. Lquipe de Lyon a slectionn trois grandes catgories dactivit mdicale (lObsttrique, les AVC et lInfarctus), nanmoins dans
notre entrept avec une dimension par Maladie et une autre par tablissement, nous
pouvons analyser les divers sjours pour nimporte quelle maladie dans nimporte
quel hpital. Voici les indicateurs qui ont t retenus :
Indicateur de consommation 1 : Le nombre annuel de sjours par tablissement.
Indicateur de consommation 2 : Reprsentation du nombre annuel daccouchements par maternit et rgion.
Indicateur de consommation 3 : Reprsentation des eectifs de nouveau-ns par
maternit et par poids de naissance.
Indicateur de consommation 4 : Reprsentation des eectifs de nouveau-ns par
poids de naissance et par niveau de maternits (niveau I, II ou III).
64
Indicateur de consommation 5 : Provenance des accouchements pris en charge

dans tous les tablissements de la rgion ou dans une slection dtablissements.
b) Indicateurs de besoins : Ces indicateurs dnissent lensemble des individus susceptibles dtre pris en charge par un tablissement de sant. Par exemple,
dans obsttrique, un indicateur de besoin serait le nombre de femmes en ge de procrer actuellement ou bien une prvision de cet eectif dans les 5 10 annes venir.
Indicateur de besoin 1 : Population dans les diverses tranches dge par secteurs
gographiques (communes, dpartement, rgion ou pays).
Indicateur de besoin 2 : Nombre de personnes dans les diverses tranches dge
dans 5 ans, 10 ans, selon le lieu dhabitation.
c) Indicateurs de flux de patient : Ces indicateurs sintressent soit lorigine
des donnes (do viennent les patients) soit leur destination (o vont-ils).
Indicateur de ux 1 : Do proviennent les mres qui accouchent dans les maternits (ventuellement selon le niveau de maternit) ?
Indicateur de ux 2 : O vont les mres qui accouchent en fonction de leur lieu
dhabitation ?
3.4.3
Nouveaux indicateurs de consommation et de flux (temporels)
Ce sont des indicateurs qui permettent de faire des analyses de comparaison, soit
sur lge des patients, soit sur le mode de sortie de lunit mdicale.
a) Indicateurs de consommation : Indicateurs de comparaison sur lge du
patient. En gardant lge du patient dans la relation Prise_MCO, on peut faire des
analyses comme :
Indicateur de comparaison 1 : Nombre annuel de patients par tablissement et
par ge.
Indicateur de comparaison 2 : Nombre annuel de personnes de plus de 60 ans par
maladie et par tablissement.
b) Indicateurs de flux : Indicateurs de comparaison sur le mode de sortie. Avec
cette dimension on peut faire des analyses sur le mode de sortie, en utilisant le code
suivant :
6 = mutation, le dpart vers une autre unit mdicale de la mme entit juridique.
3.5 Application du modle multidimensionnel dans le cadre du projet

7
8
9
0
=
=
=
=
65
transfert normal, le dpart vers une autre entit juridique.

domicile, le patient rentre chez lui.
dcs, le patient est dcd dans lunit mdicale.
transfert pour ou aprs ralisation dun acte.
Indicateur 1 : Nombre annuel de patients qui sont transfrs (code 7) par maladie
et par tablissement.
Indicateur 2 : Nombre annuel de patients dcds par maladie, par tablissement
et par rgion.
3.5
Application du modle multidimensionnel dans

le cadre du projet
Nous avons donn prcdemment un ensemble de dnitions requises pour la

conception dun modle multidimensionnel. Dans cette partie, nous reprenons cet
ensemble pour aboutir la description dun modle multidimensionnel dans un
contexte mdical. Dabord, nous dcrivons le schma en constellation conu ainsi
que les hirarchies dnies pour le projet ADELEM et nous terminons cette partie
par une description dtaille de lensemble des schmas qui composent ce modle.
3.5.1
Schma en constellation pour ADELEM
La gure 3.5 montre le schma en constellation avec trois relations de faits et

leurs dimensions. La relation de faits Prise_MCO (Mdecine-Chirurgie-Obsttrique)
a t conue pour la gestion des sjours hospitaliers eectus dans la partie court
sjour dun tablissement. La relation de faits Population manipule des informations dmographiques. La troisime Prise_SSR (Soins de Suite et de Radaptation)
dirence de Prise_MCO enregistre des donnes correspondantes des longs sjours.
Prcedemment, nous avons dni une base de donnes multidimensionnelle, un
cube, une dimension et une hirarchie. Ainsi, en utilisant la gure 3.5, nous dcrivons notre schma en constellation de la manire suivante :
Base de donnes multidimensionnelle :
Une base de donnes multidimensionnelle est un n-uplet SM = (Cs , Ds , Hs , R), o
Cs = {Prise_MCO, Prise_SSR, Population}
Ds = {Etablissements, CIM10, Temps, Zone_geo, Age, Mode_sortie, Poids_naissance,
RP99, Semaine_debut, Semaine_n}
R = {C_Cube, C_Dimension, C_Hirarchie}
66
Fig. 3.5 Schma en Constellation pour ADELEM

contrainte :
C_Cube = le component Cl_P est compos de lensemble des Cl_P du component /Dimension.
C_Dimension = permet davoir une instance D avec un seul attribut, dimension
dgnre [Kim96].
C_Hirarchie = la Cl_P dune mtaclasse Hirarchie ne peut pas relier la
mtaclasse Cube associe sa mtaclasse Dimension et ceci en raison de sa granularit.
3.5.2
Hirarchies du schma
La gure 3.6 montre deux hirarchies que nous avons conues pour le schma en
constellation prcdent [JLS99, WB97]. La premire, que nous appelons H_Geo,
t dnie pour les dimensions Etablissement et Zone_geo de la manire suivante.
Etant donn que le domaine de la dimension est : x ={C1,...,Cn}, reprsentant
les communes du pays, nous dnissons :
x {D1, ..., Dn} comme Dpartements
x {R1, ..., Rn} comme Rgions
x {P } comme Pays.
La seconde hirarchie, appele H_Temps, correspond la dimension Temps, dont
le domaine est : x ={1, ..., 12}, reprsentant les mois de lanne, nous dnissons :
x {H, P, E, A} comme les saisons (Hiver, Printemps, Et, Automne)
67

x {A} reprsentant lanne.
P
X
(Pays)
R1
...
D1
...
C1
...
Rn
X
(Anne)
X
(Rgion)
Dn
Cn
A
X
(Saison)
X
(Dpartement)
X
(Commune)
1 2 3 4 5 6 7
8 9 10 11 12
X
(Mois)
Dimension Temps
Dimension Etablissement et Zone_geo
Fig. 3.6 Hirarchies de la dimension x

A lintrieur de la hirarchie H_Geo, llment Commune reprsente la donne de
granularit infrieure, tandis que Pays reprsente le niveau suprieur dagrgation.
Dans la hirarchie H_Temps, la donne de granularit infrieure est reprsente par
le Mois et celle de granularit suprieure est lAnnee. Par exemple, si N est dnie
comme une fonction f de x, y, z, dnot par N = f (x,y,z), donc le domaine de f
est lespace multidimensionnel construit par les dimensions (x,y,z), nous pouvons
grouper N le long de la dimension x pour le niveau x, de la manire suivante :
X
f (x , y, z )
N = F (x , y, z ) =
x {x }
Lquation prcdente fait une agrgation de niveau x lintrieur de la dimension

x. Le rsultat reprsente le nombre de patients par Commune groups par Departement.
Nous pouvons aussi faire des agrgations par rapport au nombre de patients le long
de plusieurs dimensions.
3.5.3
Description du schma
Prise_MCO
et de ses dimensions
Nous montrons la spcication de ltoile : Prise_MCO. Pour faire cela, nous prenons la gure 3.5 et nous isolons la premire toile. La gure 3.7 reprsente un
schma compose de la relation de faits Prise_MCO et de ses dimensions. La saisie
de linformation se fera partir du chier RSA (public2000.mdb et prive2000.mdb),
du chier FINESS (FINESSTOT.xls), du chier CIM10 (libcim10-95.xls) et du chier RP99 (DA99CCMC.xls). Dans cette relation, il y aura un enregistrement pour
chaque sjour eectu dans la partie court sjour dun tablissement. La taille estime pour la relation Prise_MCO est environ 15 18 millions denregistrements par
anne.
Un schma de cube est un n-uplet Cs = (cn , M, D), o
68
Fig. 3.7 Schma en ocon de neige Prise_MCO

cn = Prise_MCO
M = {CompteDuree_sejour, SommeDuree_sejour}
D = {CIM10, Etablissement, Temps, Zone_geo, Poids_naissance,
Age, Mode_sortie}
Un schma de dimension est un n-uplet Ds = (dn , P, H), o
dn = CIM10
P = {Cle_Maladie, Libelle_maladie}
H = {}
dn = Etablissement
P = {Cle_Finess, Raison_sociale, Adresse, Codepostal, CA1..CA7, CMO1..CMO7,
NLA, NLO, Libelle_commune, Departement, Region, Pays}
H = {H_Geo}
Les attributs CA1..CA7 et CMO1..CMO7 reprsentent le nombre de lits autoriss et le nombre de lits mis en oeuvre respectivement par discipline. Une discipline
dsigne une activit homogne qui est en fonction du type de soins ou de service
social. Par exemple, mdecine gnrale, pdiatrie, chirurgie, hbergement, accueil
temporaire, ducation. Dans le domaine sanitaire, certaines autorisations sont faites
par Grands Groupes de Disciplines GGDE qui sont des regroupements de disciplines.
dn = Temps
P = {Cle_Temps, Mois, Saison, Annee}
H = {H_Temps}
Saison : Type char, en utilisant le code comme suit :
69
Hiver = janvier, fvrier et mars

Printemps = avril, mai et juin
t = juillet, aot et septembre
Automne = octobre, novembre et dcembre.
Pour arriver faire des analyses saisonnires.
dn = Zone_geo
P = {Cle_Zone, Libelle_commune, Departement, Region, Pays}
H = {H_Geo}
dn = Poids_naissance
P = {Cle_Poids, Libelle_poids}
H = {}
Dans cette relation nous avons pour le poids la naissance les intervalles suivants :
1
2
3
4
5
6
<1500g
>=1500g
>=2000g
>=2500g
>=3000g
>3500g
et
et
et
et
<2000g
<2500g
<3000g
<3500g
dn = Age
P = {Cle_Age}
H = {}
dn = Mode_sortie
P = {Cle_Mode, Libelle_mode}
H = {}
Un schma de hirarchie est un n-uplet Hs = (hn , L, ), o
hn = {H_Geo}
L = {Commune, Dpartement, Rgion, }
= {(Commune, Dpartement), (Dpartement, Rgion), (Rgion, )}
hn = {H_Temps}
L = {Mois, Saison, }
= {(Mois, Saison), (Saison, )}
70
3.5.4
Population
La saisie de linformation se fera partir du chier RP99 (DA99CCMC.xls) qui

contient une pyramide des ges hommes et une autre pour les femmes. Nanmoins,
si nous nous intressons seulement aux prvisions des accouchements, nous pouvons
stocker des donnes par rapport aux femmes ou bien, nous pouvons calculer et agrger les informations directement dans la relation Prvision. Celle-ci deviendra une
sorte de relation dagrgats et dans ce cas nous navons pas besoin de la dimension
RP99. La gure 3.8 reprsente le schma Population.
Fig. 3.8 Schma en ocon de neige Population

cn = Population
M = {CompteFem_proc}
D = {Zone_geo, RP99}
dn = Zone_geo
P = {Cle_Zone, Libelle_commune, Departement, Region, Pays}
H = {H_Geo}
dn = RP99
P = {Cle_Depcom, Intcom, POPF00 .. POPF>95}
H = {}
Un schma de hirarchie est un n-uplet Hs = (hn , L, ), o
hn = {H_Geo}
71
L = {Commune, Dpartement, Rgion, }

= {(Commune, Dpartement), (Dpartement, Rgion), (Rgion, )}
3.5.5
Prise_SSR
Dans cette relation, il y aura un enregistrement pour chaque sjour eectu dans
la partie long sjour dun tablissement (Soins de Suite ou de Radaptation). La
taille estime pour la relation Prise_SSR est denviron 4 millions denregistrements
par an correspondants des sjours hebdomadaires. La gure 3.9 reprsente le troisime schma Prise_SSR.
Fig. 3.9 Schma en ocon de neige Prise_SSR

cn = Prise_SSR
M = {CompteJoursenwk, CompteJourshorswk}
D = {Etablissment, CIM10, Mode_sortie, Temps, Age, Zone_geo, Semaine_debut,
Semaine_n}
dn = Semaine_debut
P = {Cle_Semdebut}
H = {}
dn = Semaine_n
P = {Cle_Semn}
H = {}
72

Les autres dimensions ont t traites au paragraphe 3.5.3.
Un schma de hirarchie est un n-uplet Hs = (hn , L, )
A lintrieur du cube Prise_SSR, nous avons les hirarchies H_Geo et H_Temps,

nanmoins, elles aussi ont t traites au paragraphe 3.5.3.
3.6
Bilan
Dans ce chapitre, nous avons prsent la premire partie de ce que nous appelons le processus de structuration. Nous avons conu dabord une architecture pour
un systme dcisionnel base sur trois composants, une interface graphique pour
la gnration semi-automatique des indicateurs, un entrept multidimensionnel qui
rassemble les donnes internes et externes et les versions de schmas bitemporels.
Dans une deuxime phase, nous nous sommes focalis sur le mtamodle et le modle multidimensionnel. Pour le mtamodle, nous avons spci trois mtaclasses :
Cube, Dimension et Hirarchie. Nous avons propos un ensemble de dnitions pour
chaque mtaclasse et leurs instances, ainsi quune dnition dune base de donnes
multidimensionnelle et de son instance. Ceci nous a permis daboutir la conception
dun schma en constellation pour la construction dun entrept multidimensionnel
de donnes mdicales. Nous avons utilis les informations concernant lensemble des
sources de donnes relles et des indicateurs du projet ADELEM pour prouver et
vrier le modle propos.
Pendant la premire tape de notre exprimentation, nous avons analys les
sources de donnes. Ceci nous a permis didentier deux types de donnes, les donnes dmographiques (RP99) et les donnes publiques concernant la sant (RSA,
RHA, CIM10 et FINESS). Principalement, dans ces dernires, nous avons constat
le besoin dorir des mcanismes pour une manipulation ecace de lensemble dinformation. Pour le projet, nous avons conu un tableau danalyse qui regroupe les
donnes sur dix annes. Ce tableau nous a permis didentier les sources qui ont
besoin dutiliser des techniques doptimisation de stockage comme la cration des
agrgats.
Lanalyse des indicateurs tablis pour le projet nous a permis de les classer en trois
types. Les deux premiers rassemblent les identicateurs dore "gographiques" et
les identicateurs de consommation, de besoins et de ux "temporels". Le troisime
type correspond des nouveaux indicateurs galement "temporels". Nous les avons
identis comme des indicateurs de consommations et de ux. Ils nous permettent
de faire des analyses par rapport lge du patient ainsi qu son mode de sortie de
lhpital.
Dans la dernire partie, nous nous sommes focaliss sur la conception dun modle
3.6 Bilan
73
multidimensionnel pour le projet. Nous avons conu une constellation compose de

trois schmas : Prise_MCO, Prise_SSR et Population, o chacun est compos de ses
propres dimensions ainsi que des dimensions partages pour lensemble de schmas.
Nous avons utilis les dnitions proposes pour aboutir la description des schmas.
Nous avons dit prcdemment que lensemble des sources comporte aussi bien des
donnes rparties et htrognes quexternes au domaine mdical. Ainsi, nous avons
dun ct des problmatiques lies la nature particulire des donnes mdicales :
type, format, smantique, condentialit, degr de abilit et de conance, informations manquantes ou incompltes, et dun autre ct lhtrognit des donnes
fournies par des organismes hors du contexte mdical. Par exemple : les renseignements sur lorigine gographique des patients pour la consommation de soins sont
bass sur les codes postaux et non pas sur le code INSEE de la commune de rsidence du patient.
Dans le chapitre suivant, nous dcrivons la deuxime partie du processus de structuration. Elle consiste en la slection de lensemble optimal de vues matrialiser.
Nous prsentons aussi le fonctionnement de linterface graphique conue pour la
gnration semi-automatique de requtes partir des indicateurs.
74
Chapitre 4
Systme daide la dcision
mdicale : une exprimentation
Dans le chapitre prcdent, nous avons dcrit le modle multidimensionnel conu
pour le projet ADELEM. Tout au long de ce chapitre, nous focalisons notre exprimentation sur un systme dcisionnel.
Nous avons divis le travail ralis en trois parties. La premire dcrit le schma
en toile construit et la matrialisation de lhypercube pour celui-ci. La deuxime
partie traite le sujet des vues matrialises qui nous permettent doptimiser lexcution de requtes. Nous avons construit le schma Adelem_MCO et nous avons cre
la base de donnes correspondante en utilisant un chantillon du 10% des donnes
relles du projet. Nous avons utilis le systme dcisionnel dOracle9i Entreprise
Edition Release 9.2.0.1.0 pour la cration du schma et pour la gnration des vues
matrialises. Ceci nous a permis de connatre le cot de stockage (reprsent par le
nombre de n-uplets du rsultat) de chaque vue et de pouvoir facilement dterminer
leur cot de calcul (produit des cardinalits approximatives des relations de base).
Nous proposons un algorithme pour la slection de lensemble optimal des vues
slectionner qui utilise comme paramtres la frquence dutilisation, le cot de calcul
et la probabilit de changement des relations de base. Nous terminons cette partie
avec les relations de dpendance et la cration des vues matrialiser de cet ensemble optimal.
Finalement, la troisime partie se focalise sur le fonctionnement de linterface pour
la gnration semi-automatique dindicateurs. Nous donnons dabord larchitecture
pour cette interface et la description de ses composants. Lutilisation de linterface
requiert un module pour la cration du schma, ainsi, nous dcrivons dabord le
fonctionnement de ce module, ensuite, nous classions les types de requte excuter
et nalement, nous dcrivons le fonctionnement de linterface graphique en utilisant
un exemple de requte.
75
76
Systme daide la dcision mdicale : une exprimentation
4.1
Construction du schma
Dans cette section, nous dcrivons la construction du schma en toile Adelem_MCO.

Il est compos dune relation de faits et de quatre relations de dimensions. Nous
dnissons dabord la structure de chaque relation qui intgre le schma et la matrialisation de lhypercube.
4.1.1
Schma en toile
Adelem_MCO
Pour la construction du schma, nous avons seulement utilis une partie de ltoile
Prise_MCO du schma en constellation conu pour le projet (cf. Figure 3.5). La gure 4.1 montre le schma Adelem_MCO construit. Il est compos de la relation de
faits Prise_MCO et des dimensions Etablissement, CIM10, Temps et Mode_sortie.
Fig. 4.1 Schma en toile Adelem_MCO

Nous dcrivons la structure de chaque relation qui compose le schma :
Fait :
Prise_MCO = {Cle_Finess, Cle_Maladie, Cle_Temps, Cle_Mode,
CompteDuree_sejour, SommeDuree_sejour}
Dimensions :
Etablissement = {Cle_Finess, Raison_sociale, Adresse, Code_postal, CA1,
77
4.1 Construction du schma

CMO1, CA2, CMO2, CA3, CMO3, CA4, CMO4, CA5, CMO5, CA6, CMO6, CA7,
CMO7, NLA, NLO, Libelle_commune, Departement, Region, Pays}
CIM10 = {Cle_Maladie, Libelle_maladie}
Temps = {Cle_Temps, Mois, Saison, Annee}
Mode_sortie = {Cle_Mode, Libelle_mode}
Le tableau 4.1 contient le type et le nombre denregistrements de chaque relation.

Relation
Prise_MCO
Etablissement
CIM10
Temps
Mode_sortie
Fait/Dimension
Fait
Dimension
Dimension
Dimension
Dimension
Taille
53799 n-uplets
5079
17788
12
5
Tab. 4.1 Liste de relations de base
4.1.2
Matrialisation de lHypercube
Les utilisateurs des entrepts travaillent dans un environnement graphique et ils

visualisent les donnes comme un cube de 2, 3 ou plusieurs dimensions. Nous utilisons le schma en toile de la gure 4.1 pour construire un hypercube. Chaque
cellule (E, C, T, M, m1, m2) contient le nombre de sjours (m1) et leur somme en
jours (m2) qui ont eu lieu dans lHpital E, avec la maladie C, pendant le mois T
et avec un mode de sortie M (par exemple : le patient rentre chez lui).
Dans les systmes dcisionnels, les utilisateurs sont intresss par des requtes
du type : "le nombre de sjours de lhpital E1 pour la maladie C1". Dans ce cas,
la cellule (E1, C1, ALL1 , ALL, m1), contient la valeur : "le nombre de sjours de
lhpital E1 pour la maladie C1 pour tous les mois (ALL) et pour tous les modes de
sortie (ALL)".
Nous pouvons calculer la valeur de la cellule (E1, C1, ALL, ALL) comme la
somme des valeurs des cellules de (E1, C1, T1 , M1 ), ..., (E1, C1, TN temps , MN mode ),
o TN temps et MN mode reprsentent lensemble de mois et lensemble de modes de
sortie respectivement. Toutes les cellules contenant la valeur ALL dans un de ses
axes sont des cellules dpendantes. Ainsi, pour la slection des vues matrialiser, le
1
Nous utilisons la recommandation dajouter la valeur ALL au domaine de la dimension T et

M, prsente dans [GBLP95]
78
problme se rduit dterminer lensemble des cellules dpendantes matrialiser.

Etant donn que le cot de stockage 2 pour une matrialisation de toutes les vues
P
est de 205929 n-uplets ( i=1,...,n CS(vi ), o CS(vi ) est le cot de stockage des vues
du tableau 4.2), nous avons un pourcentage de 74% ((206781-53799)*100/206781)
de cellules dpendantes pour le schma Prise_MCO construit.
Pour la matrialisation de lhypercube, nous avons les possibilits suivantes :
la matrialisation complte, pas de matrialisation et la matrialisation partielle.
Dans notre exprimentation, nous considrons la dernire approche. Nous dnissons dabord la taille de la matrialisation complte dun cube qui est compos de
5 relations de la manire suivante :
Taille du Cube
Fait = 1
Dimensions = 4
Total = 16 (2n o n est le nombre de dimensions = 24 )
Nous dnissons lensemble des vues possibles matrialiser. Le tableau 4.2
contient les 15 vues pour une matrialisation complte ainsi que leur cot de stockage et de calcul. La gure 4.2 reprsente lhypercube sur 4 dimensions du schma
Prise_MCO, nous utilisons la notation : M pour million et K pour mille.
Vue
Relations
V1
V2
V3
V4
V5
V6
V7
V8
V9
V10
V11
V12
V13
V14
V15
Prise_MCO+Etablissement+CIM10+Temps+Mode_sortie
Prise_MCO+Etablissement+CIM10+Temps
Prise_MCO+Etablissement+CIM10+Mode_sortie
Prise_MCO+Etablissement+Temps+Mode_sortie
Prise_MCO+CIM10+Temps+Mode_sortie
Prise_MCO+Etablissement+CIM10
Prise_MCO+Etablissement+Temps
Prise_MCO+Etablissement+Mode_sortie
Prise_MCO+CIM10+Temps
Prise_MCO+CIM10+Mode_sortie
Prise_MCO+Temps+Mode_sortie
Prise_MCO+Etablissement
Prise_MCO+CIM10
Prise_MCO+Temps
Prise_MCO+Mode_sortie
C. de Stockage
C. de Calcul
53799 n-uplets
47133
18456
603
32918
13973
184
58
26058
8186
48
19
5329
12
4
90M
90M
90M
61K
346K
90M
60K
25K
216K
90K
60
5K
18K
12
5
Tab. 4.2 Matrialisation complte de lhypercube

La vue V1 reprsente les donnes de dtail du sous-schma Prise_MCO. Le cot de
stockage (reprsent par le nombre de n-uplets du rsultat) est denviron 54K et le
cot de calcul (produit des cardinalits approximatives des relations de base) est de
2
Le cot de stockage dune requte est le nombre de n-uplets du rsultat.
79
4.2 Vues matrialises
90M. En ce qui concerne le cot de calcul, nous le calculons de la manire suivante :

CS(Etablissement)*CS(CIM10) : 5K*18K = 90M, o CS reprsente le cot de
stockage (cf. Tableau 4.1)
+
CS(V6)*CS(Temps) : 14K*12 = 168K
+
CS(V2)*CS(Mode_sortie) : 47K*5 = 235K
(90M + 168K + 235K) 90M
La gure 4.2 reprsente le treillis pour lhypercube et elle contient le cot de
stockage droite de chaque noeud (vue) et le cot de calcul gauche.
90M
90M
90M
EC
V6
14K
5K
ECT
V2
60K
Etab
V12
47K
ET
V7
19
90M
184
ECM
V3
25K
18K
ECTM
V1
18K
EM
V8
61K
58
216K
Cim10
V13
5K
12
ALL
V16
4 Dim
54K
ETM
V4
CT
V9
603
26K
Temps
V14
12
346K
90K
CTM
V5
CM
V10
3 Dim
33K
8K
Mode
5 V15
60
TM
V11
2 Dim
48
1 Dim
4
0 Dim
1
Cot de calcul
Matrialisation Complte:
Pas de Matrialisation:
361M (n-uplets)
90M (n-uplets)
Fig. 4.2 Hypercube avec le cot de calcul ( gauche) et le cot de stockage (

droite) de chaque noeud (vue)
4.2
Vues matrialises
Dans cette section, nous nous focalisons sur la gnration des vues matrialises.
Nous appliquons deux algorithmes aux donnes du projet ADELEM. Le premier est
lalgorithme Greedy, lautre est un algorithme que nous proposons pour la slection
des vues matrialiser.
Lalgorithme Greedy propos par [HRU95, HRU96] repose sur un modle de cot
pour dterminer lensemble optimal de vues matrialiser. Il utilise le cot de sto-
80
ckage et le nombre de vues dpendantes (optimales) dune vue pour calculer le

bnce optimal de celle-ci. Nous rappelons que une vue Vi est dpendante de Vj
si, et seulement si, nous pouvons rpondre Vi en utilisant Vj , ainsi, Vi Vj .
Nous prsentons dabord lapplication de lalgorithme Greedy aux donnes relles
du projet. Pour faire cela, nous listons lensemble des vues dpendantes de chaque
vue de lhypercube. Ensuite, nous exposons le fonctionnement de lalgorithme, et
pour nir, nous prsentons le tableau rsultant qui dcrit le choix des 7 premires
vues matrialiser. Dans une deuxime partie, nous prsentons le fonctionnement
de notre algorithme, ainsi que le tableau pour une slection aussi des 7 premires
vues matrialiser.
4.2.1
Slection des vues matrialiser
Nous formalisons la slection des vues matrialiser en utilisant lalgorithme

Greedy. Nous avons dcid dutiliser cet algorithme pour deux raisons, la premire
parce que nous avons toutes les donnes ncessaires pour leur utilisation. Ainsi, nous
navons pas besoin de faire des hypothses, principalement, pour le cot de stockage,
car nous avons le cot de stockage rel de chaque vue possible dtre matrialise.
La seconde raison, notre avis la plus importante, est lide que nous avons eue
de rutiliser le nombre de vues dpendantes comme un paramtre initial pour la
frquence dutilisation dune vue.
Nous avons remarqu que plusieurs propositions utilisent comme frquence dutilisation un nombre assign chaque vue, par exemple : la frquence dutilisation
pour la vue V1 est gale 10, V2 5, V3 1, ... Ainsi, la particularit de notre
algorithme rside dans la spcication de deux propositions. La premire consiste
utiliser la complexit de la vue (nombre total de ses relations dpendantes) pour
les deux premiers paramtres : la frquence dutilisation et le cot de calcul de la
vue. Ainsi, nous considrons que la frquence dutilisation dune vue augmente en
proportion directe du nombre de ses relations dpendantes et que le cot de calcul
diminue dans la mme proportion. La deuxime proposition consiste dterminer
la probabilit de changement sur les relations de base. Pour faire cela, nous avons
besoin du nombre dlments lintrieur de la vue qui peuvent subir des changements et nous le multiplions par le cot de calcul de celle-ci.
Nous utilisons lhypercube de la g 4.2 et nous considrons que le cot de stockage
est reprsent par le nombre de n-uplets de la vue. Ainsi, nous pouvons dterminer
lensemble de vues dpendantes de chaque vue de la manire suivante.
Relations de dpendance lintrieur de lhypercube :
V2 : V6 V2, V7 V2, V9 V2, V12 V2, V13 V2, V14 V2, V16 V2
81
V6 : V12 V6, V13 V6, V16 v6
V7 : V12 V7, V14 V7, V16 V7
V8 : V12 V8, V15 V8, V16 V8
V9 : V13 V9, V14 V9, V16 V9
V10 : V13 V10, V15 V10, V16 V10
V11 : V14 V11, V15 V11, V16 V11
V12 : V16 V12
V13 : V16 V13
V14 : V16 V14
V15 : V16 V15
Quelques notations de lalgorithme Greedy :
C(v) = Cot de stockage de la vue v.
= Relation de dpendance. Par exemple, Q2 Q1 si et seulement si Q2 peut tre
rpondue par Q1, donc Q2 est dpendante de Q1.
S = Ensemble de vues slectionnes.
B(v, S) = Gain de la vue v relative S,
1) Pour chaque w v, dnir la quantit Bw par :
a) Si u est la vue de cot infrieur dans S, tel que w u. Nous remarquons que
lensemble S contient au moins la vue V1.
b) Si C(v) < C(u), alors Bw = C(v) - C(u). Sinon Bw = 0.
P
2) Dnir B(v, S) =
wv Bw .
La gure 4.3 dcrit lalgorithme Greedy pour une slection de n vues matrialiser.
Nous utilisons lhypercube de la g 4.2 pour lapplication de lalgorithme. La
table 4.3 dcrit les rsultats avec n gal 7.
82

S = {top view};
for i = 1 to n do begin
select that view v not in S such that
B(v, S) is maximized;
S = S union {v};
end;
resulting S in the greedy selection;
Fig. 4.3 Algorithme Greedy [HRU95]
Vue
1re Choix
2 Choix
3 Choix
4 Choix
5 Choix
6 Choix
7 Choix
V2
V3
V4
V5
V6
V7
V8
V9
V10
V11
V12
V13
V14
V15
V16
{V1}
7K*8=56K
36K*8=288K
53K*8=424K
21K*8=168K
40K*4=160K
54K*4=216K
54K*4=216K
28K*4=112K
46K*4=184K
54K*4=216K
54K*2=108K
49K*2=98K
54K*2=108K
54K*2=108K
54K*1=54K
S=S+V4
7K*4=28K
36K*4=144K
21K*4=84K
40K*2=80K
419*4=2K
545*4=2K
28K*2=56K
46K*2=92K
555*4=2K
584*2=1K
49K*1=49K
591*2=1K
599*2=1K
1K
S=S+V3
7K*2=14K
21K*2=42K
4K*2=8K
419*4=2K
545*4=2K
28K*1=28K
10K*2=20K
555*4=2K
584*2=1K
13K*1=13K
591*2=1K
599*2=1K
1K
S=S+V5
7K*1=7K
4K*2=8K
419*4=2K
545*4=2K
7K*1=7K
10K*2=20K
555*4=2K
584*2=1K
13K*1=13K
591*2=1K
599*2=1K
1K
S=S+V10
7K*1=7K
4K*1=4K
419*4=2K
545*4=2K
7K*1=7K
555*4=2K
584*2=1K
3K
591*2=1K
599*2=1K
1K
S=S+V9
7K*1=7K
4K*1=4K
419*4=2K
545*4=2K
555*4=2K
584*2=1K
3K
591*2=1K
599*2=1K
1K
S=S+V2
4K*1=4K
419*4=2K
545*4=2K
555*4=2K
584*2=1K
3K
591*2=1K
599*2=1K
1K
S=S+V6
Tab. 4.3 Application de lalgorithme Greedy aux donnes ADELEM

Pour la premire itration, le fonctionnement de lalgorithme Greedy est assez
simple, car nous avons seulement la vue V1 dans lensemble S ; de cette manire la
valeur de u est gal 54K (le cot de V1) car elle reprsente la vue avec le cot de
stockage minimum dans lensemble S. Ainsi, pour obtenir le bnce optimal de V2,
nous devons calculer la dirence du cot de stockage de V2 par rapport V1 (47K
- 54K) et nous multiplions cette dirence par le nombre de relations dpendantes
de V2 (V2, V6, V7, V9, V12, V13, V14 et V16), ce qui nous donne 56K de bnce
optimal pour V2. Pour V3, le mcanisme est pareil, ainsi nous avons 288K. Dans le
cas de la vue V6, nous multiplions la dirence du cot de stockage entre V6 et V1
par les vues dpendantes de V6 (V6, V12, V13 et V16) et ainsi de suite.
Une fois calcul le bnce optimal de lensemble de vues, nous devons choisir
celle qui ait le bnce maximum. Dans la premire itration, le choix est la vue
V4, car elle reprsente le gain le plus lev (53K*8=424K), le gain est calcul de la
manire suivante : cot(V4) - cot(V1) = 53K multipli par 8, le nombre de vues
dpendantes de V4 (V4, V7, V8, V11, V12, V14, V15 et V16).
83
Nanmoins, au fur et mesure que nous remplissons lensemble S, nous devons

toujours choisir le cot de stockage minimum de u lintrieur de S duquel la vue
dpende. Ainsi, dans le second choix, pour certains vues, u est reprsente par 54K
(le cot de stockage de V1), tandis que pour les vues qui dpendent de V4 (qui a
t choisie dans la premire itration), u est 603. Par exemple, le bnce optimal
de V2 est 28K, car la dirence entre les cots de stockage de V2 et V1 (toujours
7K) est multipli par 4 (V2, V6, V9 et V13). Les autres vues dpendantes de V2
(V7, V12, V14 et V16) ne sont pas prises en compte, car elles donnent un gain plus
lev avec la vue V4.
Dans la seconde choix, la slection porte sur la vue V3 avec 144K (36K*4 (V3,
V6, V10 et V13)), les autres vues dpendantes de V3 ne sont pas prises en compte,
car elles donnent un gain plus lev avec la vue V4. Finalement, la dernire ligne
contient le rsultat, elle reprsente lensemble S={V4, V3, V5, V10, V9, V2, V6}.
La gure 4.4 montre lapplication de lalgorithme Greedy par rapport aux cots
de calcul et de stockage. Nous considrons seulement les 7 premiers rsultats, mme
si partir de la 6me itration, nous navons aucun avantage pour la matrialisation.
Par exemple, la vue V2, rsultat de la 6me itration, a pour cot de stockage 47K
et un cot de calcul de 90M. Si nous faisons la comparaison de ces rsultats, par rapport la vue V1, que nous sommes censs matrialiser3 , nous nous apercevons que
le gain est presque minimum, mais que les cots de leur matrialisation sont doubls.
V2
V3
90M
V6
.
.
.
Cot de calcul
Cot de stockage
Nombre
de
tuples
V5
300k
V9
200k
V10
100k
V4
...
16
Nombre de vues matrialises
Fig. 4.4 Ensemble ordonn des vues slectionnes

La gure 4.4 contient les cots de calcul et de stockage dans laxe Y et les sept
premires vues de la table 4.3 ordonnes (par rapport leur cot de calcul) sur laxe
X.
3
Car cette vue ne peut pas tre construit partir daucune autre vue.
84

Lalgorithme Greedy est optimal dans les cas suivants :
1. Si V1 est plus grande que les autres vues, alors lalgorithme est proche de
loptimal.
2. Si toutes les vues sont gales, alors lalgorithme est optimal.
Si nous considrons le cot de stockage que nous avons dans lhypercube de la
gure 4.2, nous nous apercevons que notre cas est similaire au premier, car la seule
vue proche de la vue V1 est la vue V5. Le reste des vues est plus petit que V1.
La slection des vues matrialiser est un sujet de recherche trs important. Il
existe de nombreux travaux de recherche [AAD+ 96, BB03, BPT97, CHS02, CLF99,
GM95, Gup97, KMP02, KR99, LMSS95, SDJL96, YKL97, ZYY01, YW00] qui utilisent un modle de cot, comme celui de Greedy, mais qui a t adapt avec linclusion de certains paramtres, tels que : la frquence de la requte, la frquence des
mises jour sur les relations de base, le cot de maintenance, entre autres.
Par exemple, dans [BB03], les auteurs proposent un algorithme qui permet de
calculer le gain global de la vue par rapport au cot de la requte et le cot de
maintenance. Ils direncient le cot dvaluation dune requte par rapport au
type dopration (Select, Project et Join). Ils utilisent aussi la frquence de la requte ainsi que le cot de maintenance bas sur les oprateurs Add et Delete.
Lalgorithme Greedy est simple et ecace, nanmoins, dans notre exprimentation, partir du 6me choix, il slectionne les vues les plus coteuses. Ceci nous
motive pour proposer un mcanisme pour une slection plus able. Nous proposons
dinclure les paramtres suivants : frquence dutilisation, cot de calcul et probabilit de changement des relations de base (cot).
4.2.2
Algorithme propos pour la slection des vues matrialiser
Dans notre algorithme, les relations dpendantes dune vue jouent un rle essentiel, ainsi, nous considrons que leur nombre reprsente un paramtre initial pour
la frquence dutilisation, ainsi que pour le cot de calcul. Pour le premier, nous
multiplions le bnce optimal, donn par lalgorithme Greedy, par le nombre total des relations dpendantes, car pour nous, la frquence dutilisation augmente
en proportion directe du nombre de relations dpendantes. Pour le cot de calcul,
nous considrons quil diminue par rapport au nombre de relations dpendantes,
ainsi, nous divisons le cot de calcul par le nombre total des relations dpendantes
[SA05a].
Notre algorithme considre aussi la probabilit de changement des relations de
base. Dans ce cas, nous avons besoin du nombre dlments lintrieur de la vue qui
85
peuvent subir des changements. Considrons par exemple la vue V2. Elle se compose
des relations Etablissement, CIM10 et Temps. La relation Etablissement contient 24
proprits, CIM10 et Mode_sortie contiennent 2 proprits et Temps en contient
4 (cf. paragraphe 4.1.1). Nous avons 36 lments pouvant voluer (32 proprits et
4 dimensions). Supposons que nous avons une probabilit de changement de 20%,
ainsi, notre calcul pour la frquence des mises jour de V2 est (33*100/36*.20), o
33 est le nombre dlments de la vue V2.
Quelques notations :
CC = Cot de calcul (produit des cardinalits approximatives des relations de base)
divis par le nombre de relations dpendantes. Par exemple, le CC(v) si v=V2 (vue
ECT, cf. Figure 4.4) est : CC(V2) = ((5K*18K) + (14K*12))/8 90M/8 = 11M,
o 8 est le nombre total des relations dpendantes de V2.
PC = Probabilit de changement des relations de base multipli par le cot de
calcul. Par exemple, si nous avons lhypothse de 20% de changement des lments
du schma sur la vue V2 (3 dimensions et 30 attributs qui peuvent changer), alors
PC(V2) = (3300/36*.20)*11M = 2M.
V = Ensemble de vues.
S = Ensemble de vues slectionnes.
w = Nombre de choix.
fq(v) = Complexit de la vue (nombre total des relations dpendantes de la vue v).
v = Vue slectionne.
vo = C(vue "top view").
La gure 4.5 montre lalgorithme propos incluant la frquence dutilisation, le
cot de calcul et la probabilit de changement.
Le tableau 4.4 montre les rsultats de lapplication de notre algorithme pour les
7 premiers choix, en considrant 20% comme frquence des mises jour sur les relations de base.
Pour le premier choix la valeur de vo est gale 54K, le cot de V1, car elle
reprsente la vue avec le cot de stockage minimum dans lensemble S. Pour le
deuxime et le troisime elle est reprsente par 603 (le cot de V4), car cest la vue
ayant un cot de stockage infrieur lintrieur de S. Dans la premire itration,
le choix est la vue V4, car elle reprsente le plus haut gain ((((53K*8)*8)=3392K)((61K/8)*1.18=9K)=3M). Le gain est calcul de la manire suivante : cot(V4) cot(V1) = (53K*8) reprsente le gain de Greedy, nous multiplions ce gain par le
nombre de relations dpendantes de V4 (V4, V7, V8, V11, V12, V14, V15 et V16).
Ensuite, nous le soustrayons le cot de calcul divis par le nombre de relations dpendantes et multipli par la frquence des mises jour.
Le second choix est la vue V5 avec 626K (((21K*4*8)=672K) - ((346K/8) *
86
S = {vue T}; vo = C(vue T); fq = 1; Bg = 0; t = 0; n = |V|;

for y = 1 to w do begin
//nombre de choix
for x = 2 to n do begin
//parcours de lhypercube pour chaque vue
i = x + 1;
repeat
//calculer la frquence et le bnfice de lalgorithme Greedy
if vi dpend de vx
if {vx} appartient S
vo=C(vx)
else vo=C(vue T)
endif
if vi dpend de v tel que {v} appartient S
vo=C(v)
endif
fq = fq + 1;
if C(vx) < vo
B(vi) = C(vx) - vo
else B(vi) = 0
endif
Bg = Bg + B(vi)
//bnfice Greedy
endif
i = ++;
until i = n;
Bg = Bg + (C(vx) - vo);
//bnfice de vx
B(vx, S) = (Bg * fq) - (CC(vx)/fq + PC(vx));
//bnfice incluant la frquence, le cot de calcul et la prob. chang.
if B(vx, S) > t
t = B(vx, S);
//bnfice maximal
v = vx;
endif
endfor
t=0;
S = S U {v};
endfor
rsultat S
Fig. 4.5 Algorithme propos
Vue
1re Choix
2 Choix
3 Choix
4 Choix
5 Choix
6 Choix
7 Choix
V2
V3
V4
V5
V6
V7
V8
V9
V10
V11
V12
V13
V14
V15
S=S+V1
(448K-(11M*1.18))=-13M
(2M-13M)=-11M
(3392K-9K)=3M
(1344K-46K)=1298K
(640K-26M)=-25M
(864K-18K)=845K
(864K-7K)=857K
(448K-56K)=392K
(736K-24K)=713K
(864K-62)=864K
(216K-3K)=213K
(196-9K)=187K
(54K*2*2=216K)=216K
(54K*2*2=216K)=216K
S=S+V4
-13M
-12M
626K
-26M
-11K
2K
168K
345K
9K
-1K
89K
2K
2K
S=S+V5
-13M
-12M
-26M
-11K
2K
0K
177K
9K
-1K
47K
2K
2K
S=S+V10
-13M
-12M
-26M
-11K
2K
-28K
9K
-1K
-3K
2K
2K
S=S+V11
-13M
-12M
-26M
-11K
2K
-28K
-1K
-3K
30
41
S=S+V8
-13M
-12M
-26M
-11K
-28K
-3K
-3K
30
41
S=S+V15
-13M
-12M
-26M
-11K
-28K
-3K
-3K
30
S=S+V14
Tab. 4.4 Application de notre algorithme aux donnes ADELEM
87
1.06=46K) = 626K), les vues dpendantes sont (V5, V9, V10 et V13), les autres
vues dpendantes de V5 ne sont pas prises en compte, car elles ont un gain infrieur
celui de la vue V4. Nanmoins, nous multiplions le rsultat par le nombre total
des vues dpendantes et nous divisons le cot de calcul par ce nombre total. Finalement, la dernire ligne contient le rsultat, elle reprsente lensemble S={V4, V5,
V10, V11, V8, V15, V14}.
La gure 4.6 montre lapplication de notre algorithme par rapport aux cots
de calcul et de stockage. Nous considrons les 7 premiers rsultats. Si nous prenons comme rfrence la gure 4.2, nous remarquons que la slection est faite de
la manire suivante : du deuxime niveau (3 Dim), notre algorithme slectionne les
deux vues de gain optimal. Pour le troisime niveau (2 Dim), il slectionne les trois
meilleures et nalement pour le dernier niveau (1 Dim), il slectionne les deux premires vues optimales.
90M
.
.
.
Cot dexcution
Cot de stockage
Nombre
de
tuples
V5
300k
200k
V10
100k
V4
V8
V11
V14
V15
...
16
Nombre de vues matrialises
Fig. 4.6 Ensemble ordonn des vues slectionnes

Le graphique contient les cots de calcul et de stockage sur laxe des Y et les
sept premires vues de la table 4.4 ordonnes (par rapport leur cot de calcul) sur
laxe X. Nous constatons, qu la dirence de lalgorithme Greedy, notre proposition donne de meilleurs rsultats dans notre cas exprimental.
Finalement, nous devons reconnatre la faiblesse de notre algorithme. Nous avons
deux paramtres que nous navons pas considr, le premier est labsence du cot
dvaluation dune requte par rapport au type dopration (Select, Project ou Join).
Le second paramtre que nous ne considrons pas sont des restrictions, par exemple
la restriction ventuelle sur lespace de stockage.
88
4.2.3
Gnration des vues matrialises
Cette partie dcrit la cration de lensemble de vues matrialiser. Le tableau

4.5 reprsente lensemble minimal des vues matrialiser que nous avons obtenu
en appliquant notre algorithme. Il contient pour chaque vue le nombre de jointures
ainsi que les cots de stockage et de calcul.
Vue
No de jointures
Cot de Stockage
Cot de Calcul
3
3
2
2
2
1
1
603
33K
58
8K
48
12
4
61K
346K
25K
90K
60
12
5
V4 E+T+M
V5 C+T+M
V8 E+M
V10 C+M
V11 T+M
V14 T
V15 M
Tab. 4.5 Ensemble minimal des vues matrialiser

Lensemble S est = {V4, V5, V8, V10, V11, V14, V15}. Ainsi :
VM4 : Nombre de sjours par tablissement, temps et mode de sortie
CREATE MATERIALIZED VIEW cs_sejour_etab_temps_mode_3d
ENABLE QUERY REWRITE AS
SELECT etablissement.cle_ness, temps.cle_temps, mode_sortie.cle_mode,
sum(compteduree_sejour) AS compte_sejour,
sum(sommeduree_sejour) AS somme_sejour
FROM etablissement, temps, mode_sortie, prise_mco
WHERE etablissement.cle_ness=prise_mco.cle_ness
AND temps.cle_temps=prise_mco.cle_temps
AND mode_sortie.cle_mode=prise_mco.cle_mode
GROUP BY etablissement.cle_ness, temps.cle_temps, mode_sortie.cle_mode ;
Rsultats : 603 n-uplets
VM5 : Nombre de sjours par maladie, temps et mode de sortie
CREATE MATERIALIZED VIEW cs_sejour_cim10_temps_mode_3d
SELECT cim10.cle_maladie, temps.cle_temps, mode_sortie.cle_mode,

FROM cim10, temps, mode_sortie, prise_mco
WHERE cim10.cle_maladie=prise_mco.cle_maladie
AND temps.cle_temps=prise_mco.cle_temps
GROUP BY cim10.cle_maladie, temps.cle_temps, mode_sortie.cle_mode ;
VM8 : Nombre de sjours par tablissement et mode de sortie
CREATE MATERIALIZED VIEW cs_sejour_etab_mode_2d
SELECT etablissement.cle_ness, mode_sortie.cle_mode,
sum(compteduree_sejour) as compte_sejour,
sum(sommeduree_sejour) as somme_sejour
FROM etablissement, mode_sortie, prise_mco
WHERE etablissement.cle_ness=prise_mco.cle_ness
GROUP BY etablissement.cle_ness, mode_sortie.cle_mode ;
VM10 : Nombre de sjours par maladie et mode de sortie
CREATE MATERIALIZED VIEW cs_sejour_cim10_mode_3d
SELECT cim10.cle_maladie, mode_sortie.cle_mode,
FROM cim10, mode_sortie, prise_mco
WHERE cim10.cle_maladie=prise_mco.cle_maladie
GROUP BY cim10.cle_maladie, mode_sortie.cle_mode ;
VM11 : Nombre de sjours par temps et mode de sortie
CREATE MATERIALIZED VIEW cs_sejour_temps_mode_2d
SELECT temps.cle_temps, mode_sortie.cle_mode,
sum(compteduree_sejour) as compte_sejour,
FROM temps, mode_sortie, prise_mco
89
90
WHERE temps.cle_temps=prise_mco.cle_temps
GROUP BY temps.cle_temps, mode_sortie.cle_mode ;
VM14 : Nombre de sjours par mois
CREATE MATERIALIZED VIEW cs_sejour_temps_1d
SELECT temps.cle_temps, count(compteduree_sejour) as compte_sejour,
FROM temps, prise_mco
WHERE temps.cle_temps=prise_mco.cle_temps
GROUP BY temps.cle_temps ;
VM15 : Nombre de sjours par mode de sortie
CREATE MATERIALIZED VIEW cs_sejour_mode_1d
SELECT mode_sortie.cle_mode, count(compteduree_sejour) as compte_sejour,
FROM mode_sortie, prise_mco
WHERE mode_sortie.cle_mode=prise_mco.cle_mode
GROUP BY by mode_sortie.cle_mode ;
4.3
Interface graphique pour la Gnration (semiautomatique) dIndicateurs
Nous avons cr deux modules, le premier permet la cration et/ou modication

de notre schma et le deuxime facilite la gnration de requtes de manire quasiautomatique.
Nous avons group notre travail en quatre parties. La premire montre larchitecture de linterface graphique. La deuxime dcrit le fonctionnement du module
pour la cration du schma. La troisime schmatise les types de requtes excuter
dans linterface graphique. Finalement, la dernire partie expose le fonctionnement
4.3 Interface graphique pour la Gnration (semi-automatique) dIndicateurs
91
de linterface pour la gnration (quasi-automatique) de requtes. Nous dcrivons

en dtail chaque partie.
4.3.1
Architecture pour linterface graphique
Dans notre architecture, nous trouvons trois composants principaux. Le premier

correspond linterface pour la gnration (quasi-automatique) de requtes. Le
deuxime, lentrept de donnes, a t dcrit au chapitre prcdent. Le troisime
et dernier composant est notre gestionnaire dvolution qui est dcrit au chapitre
suivant. La gure 4.7 montre notre architecture pour linterface graphique.
Interface graphique
Schma Global/Schma Local
Gnration SQL
Excution SQL
s
u
l
t
a
t
Schma
relationnel
+
Mta-schma
(mappings)
Entrept de
donnes
Sources
de
donnes
Fig. 4.7 Architecture pour linterface graphique

Nous dcrivons les dirents lments qui composent linterface :
Utilisateur : Les personnes qui utilisent cet outil pour exprimer leurs direntes
requtes (indicateurs).
Interface Graphique : Outil graphique o les utilisateurs peuvent choisir les divers composants (relations, mesures et proprits) conformes lindicateur exprim.
Gestionnaire de Requtes : Il est compos de :
92
(Schma Global/Schma Local) : Composant qui permet de traduire le

schma global (mta-schma) en schma local (relationnel).
Gnration SQL : Outil semi-automatique qui permet de gnrer le code SQL
partir du schma global et du schma local, pour rpondre aux besoins des utilisateurs.
Excution SQL : Lexcution de la requte SQL sur lentrept de donnes.
Rsultat : Les donnes qui correspondent la requte et qui doivent tre aches
par linterface graphique.
Schma Relationnel + Mta-Schma (Mappings) : Composant qui contient
les schmas (Relationnel et Mta-Schma) et qui peut tre consult par le Gestionnaire de Requtes.
Nous dcrivons le fonctionnement des modules pour la cration et/ou la mise
jour du schma.
4.3.2
Fonctionnement de linterface
Cette interface permet la cration de la structure des relations. Nous avons

construit un module pour la cration et un autre pour la mise jour des relations.
Cration dune relation
Nous pouvons crer des relations de faits ou de dimensions. La gure 4.8 montre
un exemple de cration de la dimension E_Departement pour dcrire les direntes
options :
Relation : Il contient un n-uplet de type {Nom_relation : Type}, o le type reprsente une relation de Fait ou de Dimension. Par dfaut il est de type Dimension.
Proprits : Il reprsente un ensemble de n-uplets de type {Nom_proprit :
Type}, o Type {Texte, Mmo, Numrique, Date, Montaire, Boolen}.
Cl Primaire : Il reprsente un ensemble de n-uplets de type {Nom_proprit :
Type}, o Nom_proprit : Type {Proprits}.
Cl Etrangre : Il reprsente un ensemble de n-uplets de type {Nom_proprit :
Type = Nom_relation.Nom_proprit : Type}. O Nom_proprit : Type {Pro-
93
Fig. 4.8 Cration dune dimension

prits} et Nom_relation {Relation}.
Options : Elle est compose de :
Sauvegarder : Pour lenregistrement de la relation.
Reset : Pour nettoyer lcran et continuer la cration des relations.
Exit : Pour sortir de linterface de cration.
La cration dune relation gnre de faon automatique un chier qui contient
sa structure. Lensemble de chiers crs sont accds de faon dynamique pour le
module de gnration dindicateurs pendant lexcution de requtes.
Structure du fichier : Elle contient les mta donnes suivantes(nous utilisons le
dlimiteur #) :
#Nom_relation(type) : Il identie le nom de la relation et leur type.
#Proprits : Il reprsente lensemble dattributs de la relation.
#Key : Il contient lensemble de cls primaires.
#Fkey : Il contient lensemble de cls trangres.
La gure 4.9 montre la structure de la dimension E_Departement.
Elle contient le nom et type de la relation, un ensemble de trois proprits et leur
94
Fig. 4.9 Structure de la dimension

cl_primaire.
Mise jour dune relation (fait ou dimension)
Suivant la structure de la relation modier, le module de mise jour remplit les direntes options avec des mta donnes contenues dans la relation. Ainsi,
lutilisateur peut ajouter, eacer ou modier les mta donnes contenues dans la
structure, sauf le nom et le type (faits ou dimension) de la relation, car ils ne sont
pas modiables.
4.3.3
Types de requtes excuter
Avant de dcrire le fonctionnement de linterface graphique, nous avons inclus des

exemples de requtes que nous pouvons excuter. Nous avons classi les types de requtes par rapport au nombre de relations quelles intgrent. A lintrieur du premier
type, nous avons aussi divis les requtes par rapport lensemble de paramtres
quelles contiennent. Nous montrons quelques exemples :
Requtes du type 1 : Correspondent aux requtes sur 1 relation. Nous dcrivons
ce type :
Slection sur 1 relation + condition sur un membre :
Q1 : Quels sont les tablissements avec un nombre de lits autoriss suprieur 100 ?
SELECT Cle_Finess, Raison_sociale, Adresse, NLA
FROM Etablissement
WHERE NLA > 100
Slection sur 1 relation + comptage + condition sur une mesure :
95
Q2 : Nombre de sjours.
SELECT Sum(CompteDuree_sejour)
FROM Prise_MCO
HAVING Sum(SommeDuree_sejour)>100
Slection sur 1 relation + comptage + group by + condition sur une
mesure :
Q3 : Nombre de sjour par tablissement.
SELECT Cle_Finess, Sum(CompteDuree_sejour)
FROM Prise_MCO
GROUP BY Cle_Finess
Requtes de type 2 : Correspondent aux requtes sur n relations, nous dcrivons
ce type avec un exemple :
Q4 : Nombre de sjours par tablissement et par maladie pendant le mois janvier
(avec nombre de sjours > 100).
SELECT Etablissement.Cle_Finess, Etablissement.Raison_sociale,
CIM10.Libelle_maladie, Count(Prise_MCO.CompteDuree_sejour),
Sum(Prise_MCO.SommeDuree_sejour)
FROM Prise_MCO, Etablissement, CIM10, Temps
WHERE Prise_MCO.Cle_Finess=Etablissement.Cle_Finess
AND Prise_MCO.Cle_Maladie=CIM10.Cle_Maladie
AND Prise_MCO.Cle_Temps=Temps.Cle_Temps
AND Temps.Cle_Temps=1
GROUP BY Etablissement.Cle_Finess, Etablissement.Raison_sociale,
CIM10.Libelle_maladie
ORDER BY Etablissement.Cle_Finess
Dans la partie suivante, nous dcrivons linterface graphique que nous avons
conue pour faciliter lexcution de lensemble des requtes.
4.3.4
Fonctionnement de linterface graphique
Lobjectif de notre interface est de faciliter la tche de cration dindicateurs aux

utilisateurs. La gure 4.10 dcrit lutilisation de linterface pour la gnration (semiautomatique) de requtes. Nous avons utilis lindicateur : "Q4 : Nombre de sjours
par tablissement et par maladie pendant le mois janvier (avec nombre de sjours >
96
100)", pour arriver la description des dirents choix lintrieur de linterface.
Fig. 4.10 Interface pour la gnration (semi-automatique) dindicateurs

Par rapport lindicateur, nous devons choisir : la(s) relation(s), la(s) mesure(s)
calculer, la(s) proprit(s) acher, la(s) condition(s) de slection (sur des mesures
ou sur des membres) et lordre de prsentation des rsultats.
Relations : Il contient lensemble des relations slectionnes par rapport lindicateur exprim.
Mesures et leur condition : Il contient les mesures calculer ainsi que leur fonction de groupage. La condition reprsente une slection sur la mesure. Dans le code
SQL92, cette condition est exprime dans la clause HAVING.
Proprits et leurs paramtres : Ce composant contient lensemble de proprits
acher comme rsultat de lexcution de la requte. Les paramtres reprsentent
les conditions de slection sur les membres des dimensions. Dans le code SQL92,
elles sont incluses dans la clause WHERE.
Tri : Il reprsente lensemble de proprits considrer pour la mise en ordre des
rsultats.
Options : Elle est compose de :
97
Excuter : Pour lexcution de la requte.

Reset : Pour nettoyer lcran et continuer avec la cration dune nouvelle requte.
Exit : Pour sortir de linterface de gnration.
Finalement, pour les quatre premiers composants, nous pouvons ajouter et/ou
eacer les relations, les mesures, les proprits ou les conditions (aussi bien sur les
mesures que sur les membres) qui ont t slectionnes. Par exemple, si nous eaons
une relation, lensemble de ses attributs sont eacs de linterface.
Par exemple, la gure 4.10 reprsente une requte qui requiert lexcution de
trois jointures et de deux conditions de slection. La premire condition est une
slection sur les mesures (Sum(SommeDuree_sejour)>100), tandis que la deuxime reprsente une slection sur les membres de la dimension Temps (Temps.Cle_Temps=1).
La fonction de groupage est automatiquement calcule par rapport aux proprits
slectionnes. Finalement, le rsultat est ach tri par hpital.
Chaque fois que nous choisissons loption dExcution, nous crons un chier appel Requete.REL qui contient le code SQL92 gnr. En utilisant loutil dadministration ODBC pour tablir la connexion, nous envoyons ce code vers le programme
Access pour son excution. La gure 4.11 montre le rsultat de lexcution de la
requte.
Fig. 4.11 Rsultat de lexcution de la requte Q4

Loption Exit de cet cran nous permet revenir en arrire pour rexcuter la
requte, pour changer certains paramtres ou pour excuter une nouvelle requte.
Finalement, la gure 4.12 montre la requte gnre.
Nous considrons que la requte Q4 illustre bien le rle des dirents composants
de notre systme.
98
Fig. 4.12 Fichier Requete.REL
4.4
Bilan
Dans ce chapitre, nous avons dcrit notre exprimentation dans le cadre dun
systme dcisionnel. Pour aboutir la mise en oeuvre du schma, nous avons utilis
seulement une partie du modle multidimensionnel que nous avons conu pour le
projet ADELEM (cf. Chapitre 3).
La premire section sest focalise sur la construction du schma, que nous avons
appel Adelem_MCO. Il se compose dune table de faits (Prise_MCO) et de quatre dimensions (Etablissement, CIM10, Temps et Mode_sortie). Nous avons construit ce
schma en utilisant un chantillon du 10% des donnes relles du projet.
La deuxime partie a t consacre aux vues matrialiser. Nous avons dabord
utilis lalgorithme Greedy pour la slection de lensemble optimal de vues matrialiser, ensuite, nous avons appliqu notre algorithme. Nous les avons appliqu sur
des donnes mdicales relles et nous avons constat que notre proposition donne
de meilleurs rsultats pour notre cas dexprimentation. Nous avons termin cette
partie avec la gnration de lensemble optimal de vues matrialiser.
La dernire section dcrit linterface pour la gnration (semi-automatique) dindicateurs. Nous avons divis ce travail en quatre parties. La premire partie dcrit
notre architecture pour linterface graphique. La deuxime dcrit le fonctionnement
de linterface pour la cration et/ou la mise jour du schma. Nous avons group
lensemble des lments qui intgrent cette interface dans 5 composants et nous
avons termin cette partie avec la description de chaque composant.
Dans la troisime partie, nous avons class les types de requtes par rapport au
nombre de dimensions. Nous avons aussi donn des exemples de chaque type de
requtes excuter sur linterface graphique et nous avons termin cette section
avec la description du fonctionnement de linterface graphique pour la gnration
(semi-automatique) de requtes. Nous avons utilis un exemple pour dcrire son
4.4 Bilan
99
fonctionnement.
Dans le chapitre suivant, nous dployons notre proposition pour la gestion, le
stockage et la visualisation de lensemble de donnes contenues dans un entrept de
donnes. Nous proposons lutilisation des versions de schmas bitemporels pour la
gestion de lvolution des donnes aussi bien intensionnelles que extensionnelles.
100
Chapitre 5
Aspects temporels et versions de
schmas dans les entrepts
Malgr une conception attentive et soigneuse, la structure dune base de donnes
est sujette de nombreux changements. Ces changements peuvent aecter aussi
bien les donnes que leur structure. Pour grer ces changements, nous pouvons utiliser lvolution de schmas ou les versions de schmas. Pour rsoudre le problme
de perte de donnes aprs des changements du schma, le concept dvolution de
schma t introduit pour rcuprer les donnes existantes par le biais de leur
adaptation au nouveau schma. Nanmoins, nous considrons que pour les systmes
qui doivent grer des donnes historiques, lvolution de schma nest pas susante
et la maintenance de plusieurs schmas est requise. Nous devons choisir la technique
utiliser par rapport aux caractristiques de lapplication cible.
Dans ce chapitre, nous utilisons un schma en volution qui contient aussi bien
des changements sur les donnes extensionnelles que sur les donnes intensionnelles.
Ceci nous permet dintroduire le concept de versions de schmas qui permettent de
grer ces changements en gardant lensemble des donnes. Nous nous inspirons des
besoins et des caractristiques dune application mdicale.
Nous proposons lutilisation des versions de schmas pour la gestion, le stockage et
la visualisation des donnes historises de lapplication mdicale ADELEM. Nanmoins, la gestion des versions est une tche complexe et elle prsente plusieurs
problmes. Le principal, notre connaissance, est lexplosion des versions, car lexcution de chacune des primitives entrane la gnration dune nouvelle version. Ainsi,
nous devons tablir un mcanisme pour contrler cette explosion. Pour faire cela,
nous avons dni un oprateur appele SetVersion qui permet de grouper un ensemble de primitives excuter sur une version de schma et qui gnre une nouvelle
[SA05b].
La gestion des versions de schmas requiert aussi la spcication dun ensemble
de composants. Dabord, nous avons besoin dun ensemble de primitives permettant
lvolution dune version vers une autre et dun ensemble de rgles dintgrit. Nous
101
102
Aspects temporels et versions de schmas dans les entrepts
avons aussi besoin dun gestionnaire dvolution qui manipule les direntes versions
de schmas historises et dun moteur de versions. Ce dernier gre le stockage des
deltas et les rgles de conguration ncessaires lors de la manipulation des versions
de schmas.
5.1
Versions de schmas
Cette section prsente une introduction aux versions de schmas. Nous utilisons
dabord un schma en volution pour dcrire le besoin de la gestion des versions de
schmas. Ensuite, nous montrons la reprsentation bitemporelle de cet ensemble de
versions.
5.1.1
Versions de schmas annuels dans un contexte mdical
Nous utilisons un schma en toile avec quatre dimensions qui est dcrit par la
gure 5.1. Il reprsente une volution annuelle dune application mdicale. La table
centrale reprsente une table de faits (Prise_MCO). Elle contient un n-uple pour
chaque sjour dans un hpital.
CIM10 (VS01)
Etablissment (VS01)
Cle_Maladie
Libelle_maladie
Prise_MCO (VS01)
Cle_Maladie
Cle_Finess
Prise_MCO (VS02)
Cle_Maladie
Cle_Finess
Temps (VS01)
Cle_Temps
Temps (VS02)
Cle_Temps
Mois
Semestre
Annee
Prise_MCO (VS03)
Cle_Maladie
Cle_Finess
Cle_Temps
Cle_Mode
Compte_sejour
Somme_sejour
Cle_Finess
Raison_sociale
Code_postal
CA1..CA7
...
Etablissement (VS02)
Cle_Finess
Raison_sociale
Adresse
Code_postal
CA1..CA7
...
Mode_sortie (VS01)
Cle_Mode
Libelle_mode
Temps (VS03)
Cle_Temps
Mois
Saison
Semestre
Annee
Fig. 5.1 Trois versions de schmas annuels.

La gure 5.1 dcrit trois versions de schmas annuels pour la table de faits Prise
_MCO et pour la dimension Temps. Nanmoins, dans la dernire version de schma de
la dimension Temps VS03, le schma a t modi par lajout de lattribut Saison.
La dimension Etablissement reprsente deux versions, o la version de schma VS01
reprsente la version pour lanne 2001 et la version VS02 correspond aux versions
de schmas annuelles pour lanne 2002 et 2003. Cette version a t modie par
103
5.1 Versions de schmas
lajout de lattribut Adresse. Finalement, les dimensions CIM10 et Mode_sortie ne

changent pas dun schma lautre.
5.1.2
Reprsentation bitemporelle des versions de schmas
Pour la gestion de la notion du temps dans notre modle de versions de schmas, nous pouvons utiliser soit le temps transactionnel, soit le temps de validit,
ou bien le bitemporel [DGS95, GM02, AQ86]. Le temps de validit dune version
correspond aux instants auxquels cette version est vraie dans le monde modlis.
De cette manire, nous pouvons linterroger par rapport la validit, des donnes
de cette version, du schma correspondant, ou en utilisant un schma valide dans
un intervalle dirent. Par contre, le temps transactionnel correspond linstant o
un fait est enregistr dans la base. Dans cette approche, nous pouvons seulement
modier le schma courant. Ainsi, si par exemple, nous avons besoin daccder une
version historique pour corriger certains erreurs en gardant lhistoire complte des
changements du schma, nous devons choisir le bitemporel pour la gestion du temps.
Dans notre cas, nous avons dcid de manipuler les versions de schmas bitemporels.
Ainsi, nous devons grer la combinaison du temps de transaction et du temps de
validit (cf. Subsection 2.6.1.3).
La gure 5.2 montre la gestion du temps pour lapplication mdicale prsente
dans la gure 5.1.
01/01
01/03
01/02
01/04
UC
valid-time
07/02
VS01
07/03
VS02
07/04
VS03
07/05
UC
transaction-time
Fig. 5.2 Reprsentation bitemporelle des versions de schmas.

Cette gure reprsente les versions de schmas bitemporels VS01, VS02 et VS03.
Chaque version de schma a un temps de transaction et un temps de validit. Par
104
exemple pour la version VS01, nous avons un temps de transaction 2002-07 et un

temps de validit de 2001-01 - 2001-12. Dans la suite, nous dcrivons les versions de
schmas bitemporels. Nous supposons lexistence de lensemble {C, D, H, M, P, L,
R} (cf. paragraphe 3.2.4) et de :
V = Ensemble de noms des versions de schmas.
CS = Ensemble des changements sur les schmas.
= Reprsente une fonction timestamp1 .
TIME = (TIMEt X TIMEv )
: TIME VS
{}
(tt, vt) =
V Si si V Si active dans (tt, vt)
sinon
Nous dnotons par 1 (VS) le temps associ par la fonction VS. Ainsi, 1 (VS)
reprsente la pertinence temporelle (timestamp) de VS.
Finalement, notre version de schma reprsente un n-uplet VS = (Vs , Cs , Ds ,
Hs , R, CS, 1 ) par rapport la gure 5.1, tel que :
Vs = {VS01, VS02, VS03}
Cs = {Prise_MCO}
M = {Compte_sejor, Somme_sejour}
Ds = {Etablissement, CIM10, Temps, Mode_sortie}
P = {Cle_Finess, Raison_sociale, Adresse, Codepostal, CA1 .. CA7, CMO1 ..
CMO7, NLA, NLO, Commune, Departement, Region, Pays, Cle_Maladie, ... }
Hs = {}
L = {}
CS = {(AddProprieteAdresse , VS01, VS02), (AddProprieteSaison , VS02, VS03)}
1 (VS01) = (2002-07, UC2 )t X (2001-01 - 2001-12)v
1 (VS02) = (2003-07, UC)t X (2002-01 - 2002-12)v
1 (VS03) = (2004-07, UC)t X (2003-01 - 2003-12)v
La gestion de lensemble des changements dun schma en volution requiert
un nombre doprations primitives qui permettent aux donnes intensionnelles et
extensionnelles, de continuer dexister ou dtre valides.
1
2
Nous utilisons la fonction prsente dans [GM02]

Until Change
5.2 Les oprations primitives
5.2
105
Les oprations primitives
Nous dcrivons les oprations primitives que nous avons dnies pour la gestion
dun schma en volution. Lensemble doprations a t inspir par les travaux de
recherche dans le domaine de lvolution de schmas [Ben02, KC88, KC02, GM02,
GMS00, Lau96, RKZ00]. Nous avons adapt lensemble de primitives pour les entrepts de donnes et nous avons dni les rgles dintgrit requises.
5.2.1
Ensemble de primitives
Nous avons divis les primitives en deux catgories, la premire pour la gestion
des cubes, des dimensions ou des hirarchies. La deuxime correspond aux primitives
qui agissent sur les versions de schmas.
Gestion de la relation (cube, dimension ou hirarchie) :
Nous avons construit le tableau 5.1 avec lensemble des primitives qui agissent
sur le contenu dune relation avec leur dnition et les rgles dintgrit.
Gestion des versions :
Le trableau 5.2 dcrit lensemble des primitives construites pour la gestion de
versions avec leur dntion et les rgles dintgrit.
5.2.2
Ensemble de restrictions
Nous prsentons lensemble des rgles dintgrit que nous avons conu. Le format
gnral pour leur dnition est le suivant :
constraint nom_contrainte := constraint ;
Nous listons lensemble des restrictions que nous avons dni par rapport aux
oprations primitives prcdentes. Nous avons aussi divis les restrictions en deux
catgories.
Rgles dintgrit dfinies
Sur une relation :
R1 : constraint addm := type(mn ) = numrique.
R2 : constraint deletem := {M} 2.
R3 : constraint created := cl primaire {FC}, o FC est lensemble de cls
trangres qui appartiennent la relation de faits.
R4 : constraint dropd := cl primaire
/ {FC}.
106
Primitive
CreateC
DropC
RenameC
AddM
DeleteM
RenameM
CreateD
DropD
RenameD
AddP
DeleteP
Change_typeP
RenameP
CreateH
Dfinition
CreateC(BM, cn , {M}, {D})
DropC(BM, cn )
RenameC(BM, cn , cn )
AddM(BM, cn , mn )
DeleteM(BM, cn , mn )
RenameM(BM, cn , mn , mn )
CreateD(BM, dn , {P}, {H})
DropD(BM, dn )
RenameD(BM, dn , dn )
AddP(BM, dn , pn )
DeleteP(BM, dn , pn )
Change_typeP(BM, dn , pn , pn )
RenameP(BM, dn , pn , pn )
CreateH(BM, hn , L, )
DropH
DropH(BM, hn )
RenameH
AddL
DeleteL
RenameH(BM, hn , hn )
AddL(BM, hn , ln , l1 , l2 )
DeleteL(BM, hn , ln )
RenameL
RenameL(BM, hn , ln , ln )
Rgle dintgrit
(R1) type(mn ) = numrique

(R2) {M} 2
(R3) cl primaire {FC}
(R4) cl primaire
/ {FC}
(R5) proprit 6= cl primaire

cl primaire {FD}
(R9) cl primaire
/ {FC}
cl primaire
/ {FD}
(R10) cl primaire
/ {FC}
cl primaire
/ {FD}
cl primaire {FD}
Tab. 5.1 Primitives pour la gestion de relation
Primitive
CreationV
FreezeV
DefrostV
ExporterR
DropV
Dfinition
Rgle dintgrit
AddV(BMS, VSn )
FreezeV(VSn )
(R12) (VSn )=vrai
DefrostV(VSn )
ExporterR(VSn , CIM10, VSn ) (R13) dn VSn
DropV(VSn )
(R14) DropV(VSn ) (VSn )=vrai
Tab. 5.2 Primitives pour la gestion des versions
5.3 Dfinition formelle des primitives
107
R5 : constraint deletep := proprit 6= cl primaire.

R6 : constraint change_typep := proprit 6= cl primaire.
R7 : constraint renamep := proprit 6= cl primaire.
R8 : constraint createh := cl primaire {FC} cl primaire {FD}, o FD
est lensemble de cls trangres lintrieur de la dimension.
R9 : constraint droph := cl primaire
/ {FC} cl primaire
/ {FD}.
R10 : constraint deletel := cl primaire
/ {FC} cl primaire
/ {FD}.
R11 : constraint renamel := cl primaire {FC} cl primaire {FD}.
Sur une version :
R12 : constraint freezev := version de schma lhistorique.
R13 : constraint exporterr := relation_nom version de schma.
R14 : constraint dropv := version de schma
/ lhistorique et version de schma
6 version courante.
=
5.3
Dfinition formelle des primitives
Dans cette section, nous traitons la dnition de lensemble des primitives requises
pour la cration dune version de schma. Nous avons gard les deux catgories spcies prcdemment. Nous avons aussi identi un ensemble de proprits qui doivent
tre prserves lors des volutions.
Noms uniques : Les versions de schmas, les cubes, les dimensions, les hirarchies, les mesures, les proprits et les niveaux ont des noms uniques.
Schma du cube : La cardinalit de lensemble daxes et de lensemble de mesures doit tre suprieure ou gale 1.
Schma de dimension : La cardinalit de lensemble des proprits doit tre
suprieure ou gale 1.
Schma de hirarchie : Il est reprsent par un graphe acyclique dirig qui
contient un seul noeud base et un seul noeud sommet .
Schma de version : Il est reprsent par un schma multidimensionnel VS=(V,
C, D, H, R, CS, 1 ) et linstance est IV=(Vi , Ci , Di , Hi , Ri , CSi , 1
i ).
La smantique de lensemble de primitives doit respecter ces proprits. Pour la
dnition des primitives, nous avons repris les 4 dnitions pour la spcication
dune base de donnes multidimensionnelle dj prsentes (cf. Chapitre 3).
108
5.3.1
Gestion de la relation (cube, dimension ou hirarchie)
Dans cette partie, nous prsentons lensemble des dnitions des primitives qui
agissent sur les schmas de cubes, de dimensions ou de hirarchies.
Dfinition 5.1 : Primitive CreateC
Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et dinstance IV = (Vi , Ci , Di , Hi , Ri , CSi , 1
i ), un nom de cube cn C, un ensemble de
dimensions D tel que |D| 1 et un ensemble de mesures M tel que |M| 1, le
rsultat de la primitive CreateC(VS, cn , M, D) est une version dont le schma est
S
VS = (Vs , Cs {cs }, Ds , Hs , R, CS, 1 ), o cs est un schma de cube (cn , M, D)
et linstance est IM = IM.
Considrons linsertion dans la version VSi dun nouveau cube Achats qui contient
lensemble de dimensions {Magasin, Temps, Produit, Fournisseur} et la mesure
QuantiteA, la primitive CreateC(VSi , Achats, {Magasin, Temps, Produit, Fournisseur}, QuantiteA) cre le cube.
Dfinition 5.2 : Primitive DropC
Cette primitive limine un schma de cube, ses dimensions et ses hirarchies dune
version de schma VS.
Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et
dinstance IV = (Vi , Ci , Di , Hi , Ri , CSi , 1
i ), un nom de cube cn C, la primitive
DropC(VS, cn ) cre une version dont le schma est VS = (Vs , Cs , Ds , Hs , R,
CS, 1 ), o Cs = Cs \{(cn , m1 ,..., mj , D)}. Linstance est IV = (Vi , Ci \{ci }, Di ,
Hi , Ri , CSi , 1
i ), o ci = {(cn , {(v1 ,..., vj )| i=1,...,n vi measuredom(mi )}, {d})}.
Par exemple, pour liminer le cube Achats de la version VSi , nous excutons la
primitive DropC(VSi , Achats).
Dfinition 5.3 : Primitive RenameC
i ), les noms de cubes cn cn C, lexcution
de la primitive RenameC(VS, cn , cn ) fournit une version dont le schma est VS
S
= (Vs , Cs , Ds , Hs , R, CS, 1 ), o Cs = Cs \{(cn , M, D)} {(cn , M, D)}, et
linstance est IV = IV.
Par exemple, pour renommer le cube Ventes par VentesJournalieres : RenameC(VSi ,
Ventes, VentesJournalieres).
Dfinition 5.4 : Primitive AddM
109
i ), un nom de cube cn C et un nom de
mesure mn M, la primitive AddM(VS, cn , mn ) cre une version dont le schma est
S
S
VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Cs = Cs \{(cn , M, D)} {(cn , M {mn },
S
D)}, et linstance est IV = (Vi , Ci , Di , Hi , Ri , CSi , 1
i ) oSCi = C i \{ci } {ci },
o ci = (cn , {(m1 ,..., mi )}, {d}) et ci = (cn , {(m1 ,..., mi )} {mn }, {d}).
Par exemple, pour ajouter la mesure QuantiteV au cube Ventes, nous excutons
la primitive AddM(VSi , Ventes, QuantiteV).
Dfinition 5.5 : Primitive DeleteM
i ), un nom de cube cn C et un nom de
mesure mn M tel que |M| 2, le rsultat de DeleteM(VS, cn , mn ) est une version dont le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Cs = Cs \{(cn ,
S
M, D)} {(cn , M\{mn }, D)}. Linstance IV = (Vi , Ci , Di , Hi , Ri , CSi , 1
i )
S
o Ci = C i \{ci } {ci }, o ci = (cn , {(m1 ,..., mi )}, {d}) et ci = (cn , {(m1 ,...,
mi )}\{mn }, {d}).
Par exemple, pour supprimer la mesure QuantiteV de cube Ventes : DeleteM(VSi ,
Ventes, QuantiteV).
Dfinition 5.6 : Primitive RenameM
i ), un nom de cube cn C et les noms mn et
mn M, lexcution de la primitive RenameM(VS, cn , mn , mn ) donne une version
dont le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Cs = Cs \{(cn , M,
S
S
D)} {(cn , M\{mn } {mn }, D)}. Linstance est IV = IV.
Par exemple, pour changer le nom de la mesure Quantite par QuantiteJournaliere,
nous excutons la primitive RenameM(VSi , Ventes, Quantite, QuantiteJournaliere).
Dfinition 5.7 : Primitive CreateD
i ), un nom de cube cn C un nom de
dimension dn D, un ensemble de proprits P tel que |P| 1 et H, le rsultat de la
primitive CreateD(VS, Cn , dn , P, H) est une version dont le schma est VS = (Vs ,
S
S
S
Cs , Ds {ds }, Hs , R, CS, 1 ), o Cs = Cs \{(cn , M, D)} {(cn , M, D {dn })}
S
et Ds = Ds {ds }. Linstance est IV = (Vi , Ci , Di , Hi , Ri , CSi , 1
i ), o Ci =
S
S
Ci \{ci } {ci }, ci = (cn , {m}, {d1 ,... di }), ci = (cn , {m}, {d1 ,... di } {dn }) et Di
110
= Di .
Considrons par exemple la cration de la dimension Fournisseur qui contient
lensemble de proprits {Cle_F, Raison_sociale, Adresse, Tlphone, Pays} au
cube Ventes, nous excutons la primitive CreateD(VSi , Ventes, Fourniseur, {Cle_F,
Raison_sociale, Adresse, Tlphone, Pays}, {}).
Dfinition 5.8 : Primitive DropD
Cette primitive limine un schma de dimension et leurs instances dune version
VSi . La primitive ne peut pas tre excute sil existe un schma de cube qui utilise
cette dimension. Ainsi, nous supposons lexistence dune fonction boolenne indiquant si la dimension peut tre supprime.
i ), un nom de dimension dn D tel que
(dn =vrai), la primitive DropD(VS, dn ) cre une version dont le schma est VS
= (Vs , Cs , Ds , Hs , R, CS, 1 ), o Ds = Ds \{(dn , P, H)}. Linstance est IV =
(Vi , Ci , Di , Hi , Ri , CSi , 1
i ), o Di = Di \{di }, o di = (dn , {(v1 ,..., vx )| i=1,...,n
vi propertydom(pi )}, {h}).
Par exemple, pour supprimer la dimension Magasin, nous excutons la primitive
DropD (VSi , Magasin) (Magasin)=vrai.
Dfinition 5.9 : Primitive RenameD
i ), un nom de cube cn C et deux noms de
dimensions dn , dn D, lopration RenameD(VS, cn , dn , dn ) fournit une version
dont le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Cs = Cs \{(cn , M,
S
S
S
D)} {(cn , M, D\{dn } {dn })} et Ds = Ds \{(dn , P, H)} {(dn , P, H)} et linstance est IV = IV.
Par exemple, pour changer le nom de la dimension Magasin par le nom Boutique
du cube Ventes : RenameD(VSi , Ventes, Magasin, Boutique).
Dfinition 5.10 : Primitive AddP
i ), un nom de dimension dn D et un nom
de proprit pn P, la primitive AddP(VS, dn , pn ) cre une version dont le schma
S
S
est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Ds = Ds \{(dn , P, H)} {(dn , P {pn },
S
H)}, et linstance est IV = (Vi , Ci , Di , Hi , Ri , CSi , 1
o Di = Di \{di } {di },
i )S
o di = (dn , {(p1 ,..., pi )}, {h}) et di = (dn , {(p1 ,..., pi )} {pn }, {h}).
111
Par exemple, pour ajouter la proprit Telephone la dimension Magasin, nous

excutons la primitive AddP(VSi , Magasin, Telephone).
Dfinition 5.11 : Primitive DeleteP
i ), un nom de dimension dn D et un nom de
proprit pP tel que |P| 2, le rsultat de DeleteP(VS, dn , p) est une version dont
S
le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Ds = Ds \{(dn , P, H)} {(dn ,
S
P\{p}, H)}. Linstance IV = (Ci , Di , Hi , Ri , CSi , 1
i ) o Di = D i \{di } {di },
o di = (dn , {(p1 ,..., pi )}, {h}) et di = (dn , {(p1 ,..., pi )}\{p}, {h}).
Pour supprimer la proprit Telephone de la dimension Magasin, nous excutons
la primitive DeleteP(VSi , Magasin, Telephone).
Dfinition 5.12 : Primitive Change_typeP
i ), un nom de dimension dn D et les noms
de proprits pn , pn P, le rsultat de Change_typeP(BM, dn , pn , pn ) est une
version dont le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Ds = Ds \{(dn ,
S
S
P, H)} {(dn , P\{pn } {pn }, H)}. Linstance IV = (Vi , Ci , Di , Hi , Ri , CSi , 1
i )
S
o Di = Di \{di } {di }, o di = (dn , {(p1 ,..., pi )}\{pn }, {h}) et di = (dn , {(p1 ,...,
S
pi )} {pn }, {h}).
Par exemple, pour changer la proprit Codepostal de integer char : Change_
typeP(VSi , Magasin, Codepostal, CodepostalChar).
Dfinition 5.13 : Primitive RenameP
i ), un nom de dimension dn D et les noms
de proprits pn , pn P, le rsultat de RenameP(VS, dn , pn , pn ) est une version
dont le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Ds = Ds \{(dn , P,
S
S
H)} {(dn , P\{pn } {pn }, H)}. Linstance IV = IV.
Par exemple, pour changer le nom de la proprit Raison par Raison _sociale :
RenameP(VSi , dn , Raison, Raison_sociale).
Dfinition 5.14 : Primitive CreateH
i ), un nom de dimension dn D un nom de
112
hirarchie hn H, un ensemble de niveaux L et une relation dfinie sur L, le rsultat de la primitive CreateH(VS, dn , hn , L, ) est une version dont le schma est VS
S
S
= (Vs , Cs , Ds , Hs , R, CS, 1 ), o Ds = Ds \{(dn , P, H)} {(dn , P, H {hn })}
S
et Hs = Hs {hs }, o hs est un schma de hirarchie (hn , L, ). Linstance est IV
S
= (Vi , Ci , Di , Hi , Ri , CSi , 1
D = Di \{di } {di }, di = (dn , {p}, {(h1 , ...,
i ), o
S i
hk )}), di = (dn , {p}, {(h1 , ..., hk )} {hn }) et Hi = Hi .
Considrons par exemple la cration de la hirarchie H_Temps qui contient lensemble de niveaux {Jour, Mois, Saison, Annee}. La relation entre les niveaux est
{(Jour, Mois), (Mois, Saison), (Saison, Annee)}. La primitive CreateH(VSi , Etablissement, H_Temps, L, ) insre la dimension Etablissement, la nouvelle hirarchie.
Dfinition 5.15 : Primitive DropH
Nous ne pouvons pas utiliser cette primitive sil existe un schma de cube utilisant
un niveau de la hirarchie en tant quaxe. Ainsi, nous supposons lexistence dune
fonction boolenne qui nous indique si nous pouvons excuter la primitive.
i ), un nom de hirarchie hn H tel que
(hn )=vrai, la primitive DropH(VS, hn ) fournit une version dont le schma est VS
= (Vi , Cs , Ds , Hs , R, CS, 1 ), o Hs = Hs \{(hn , L, )}. Linstance est IV =
S
(Vi , Ci , Di , Hi , Ri , CSi , 1
i ), o Hi = Hi \{( li L levelset(li ), RUP)}.
Par exemple, pour supprimer la hirarchie H_Temps : DropH(VSi , H_Temps).
Dfinition 5.16 : Primitive RenameH
i ), le nom de dimension dn D, et deux noms
de hirarchies hn et hn H, la primitive RenameH(VS, dn , hn , hn ) cre une version
dont le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Ds = Ds \{(dn , P,
S
S
S
H)} {(dn , P, H\{hn } {hn }) et Hs = Hs \{(hn , L, )} {(hn , L, )}. Linstance
est IV= IV.
Par exemple, pour renommer la hirarchie H_Temps de la dimension Temps par le
nom H_Jour, nous excutons la primitive RenameH(VSi , Temps, H_Temps, H_Jour).
Dfinition 5.17 : Primitive AddL
Cette primitive modie le schma de hirarchie hs en construisant une relation
entre les niveaux l1 et l2 qui appartiennent hs et un nouveau niveau ln . Cette opration tablit les relations de dpendances suivantes : l1 ln et ln l2 . Pour faire
cela, nous supposons lexistence dune fonction qui, tant donns un nom de hi-
113
rarchie hn et deux niveaux li et lj , retourne une valeur boolenne gale vrai si li lj .

i ), un nom de hirarchie hn H, les niveaux
ln , l1 et l2 L, et un membre mlevelset(ln ), la primitive AddL(VS, hn , ln , l1 , l2 )
cre une version dont le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) tel que
S
S
S
Hs = (Hs \{hs } {hs }), o hs = (hn , L, ) et hs = (hn , L {ln }, {(l1 ln ),
) telle que Hi =
(ln l2 )}). Linstance est IV = (Vi , Ci , Di , Hi , Ri , CSi , 1
Si
S
S
(Hi \ {hi } {hi }), o hi = ( li L levelset(li ), RUP) et hi = ( li L S {ln } levelset(li ),
l
RUP). Lensemble RUP contient les fonctions ruplji telles que ruplln1 = {(e, m)|e
l
l
levelset(l1 )}, rupll2n = {(e, m)|e levelset(l2 )} et ruplji = ruplji pour les autres
niveaux li et lj .
Par exemple si nous voulons insrer le niveau District la hirarchie H_Geo de

la gure 3.4 (cf. Chapitre 3) entre les niveaux Departement et Region, la primitive
AddL(VSi , H_Geo, District, Departement, Region, Columbia) modie le schma et
linstance de la hirarchie spcie. La gure 5.3 montre le rsultat de cet oprateur.
Region
Rhne Alpes
District
Columbia
Departement
Commune
Isre
Lyon
Grenoble
a) Schma
...
...
...
Annecy
b) Instance
Fig. 5.3 Insertion du niveau District la Hirarchie H_Geo.

Dfinition 5.18 : Primitive DeleteL
i ), un nom de hirarchie hn H, et un niveau
ln L, tel que ln 6= et ln 6=l, la primitive DeleteL(VS, hn , ln ) donne une version
114
dont le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Hs = (Hs \{(hn , L,

S
S
)} {(hn , L, )}), o L = (L\{ln }), = (\{(l1 , l2 )|ln = l1 (ln = l2 )}) {(l1 ,
S
l2 )|l1 ln ln l2 }. Linstance est IV = (Vi , Ci , Di , Hi \{hi } {hi }, Ri , CSi , 1
i ),
S
S
o hi = ( li L levelset(li ), RUP) et hi = ( li L levelset(li ), RUP). Lensemble
l
RUP contient les fonctions ruplji telles que (i) rupll21 = ruplln1 rupll2n , si l1 ln
ln l2 , (ii) rupll21 = rupll21 , dans les autres cas.
Par exemple si nous voulons eacer le niveau Departement la hirarchie H_Geo
de la gure 5.3 entre les niveaux District et Commune, nous excutons la primitive
DeleteL(VSi , H_Geo, Departement). La gure 5.4 montre le rsultat de cet oprateur.
Rhne Alpes
Region
District
Commune
Columbia
Lyon
Grenoble
a) Schma
...
...
Annecy
b) Instance
Fig. 5.4 Rsultat dliminer le niveau Departement la Hirarchie H_Geo.

Dfinition 5.19 : Primitive RenameL
Cette primitive change le nom dun niveau, il prend en entre le nom hn de la
hirarchie, le niveau renommer, lancien nom ln et le nouveau nom ln .
i ), un nom de hirarchie hn H, et les
niveaux ln et ln L, la primitive RenameL(VS, hn , ln , ln ) cre une version dont le
S
schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Hs = Hs \{(hn , L, )} {(hn ,
S
L\{ln } {ln }, )}, et linstance est IV = IV.
Par exemple, pour renommer le niveau Commune de la hirarchie H_Geo par le nom
Ville : RenameL(VSi , H_Geo, Commune, Ville).
5.3.2
115
Gestion des versions
Nous prsentons lensemble des dnitions de primitives qui agissent sur la gestion de versions de schmas. Nous considrons lexistence de :
S
S
S
S
DOM = dom(char) dom(integer= dom(oat) dom(decimal) dom(date)
contenant le domaine de chaque type atomique.
OP = Ensemble de oprations primitives.
Dfinition 5.20 : Primitive CreateV
i ), et un nom de version vn V, le rsultat
de CreateV(VS, vn ) cre une nouvelle version dont le schma est VS = VS et linstance est IV = IV.
Par exemple, supposons que nous voulons crer une version de schma VSj
partir de la version VSi . La primitive CreateV(VSi , VSj ) cre la version VSj = (Vs ,
Cs , Ds , Hs , R, CS, 1 ).
Dfinition 5.21 : Primitive FreezeV
Cette primitive permet de geler une version (i.e., elle ne permet plus de changements). La seul primitive que nous pouvons appliquer une version gele est
DefrostV (cf. Dnition 5.22).
i ), et un nom de version vn V, la primitive
FreezeV(vn ) bloque cette version en interdisant lexcution des primitives dvolution. La version de schma est VSi =vn dont le schma est VS = (Vs , Cs , Ds , Hs , R,
CS, 1 ) et linstance IV = (Vi , Ci , Di , Hi , Ri , CSi , 1
i ). i=1,...,n pi OP, pi (VSi )
sexcute si et seulement si VSi nest pas gele.
Dfinition 5.22 : Primitive DefrostV
i ), et un nom de version vn V, la primitive DefrostV(vn ) fournit une version de schma VSi =vn dont le schma est VS
= (Vs , Cs , Ds , Hs , R, CS, 1 ) et linstance IV = (Vi , Ci , Di , Hi , Ri , CSi , 1
i ).
i=1,...,n ei E(VSi ) pi (VSi ) sexcute, o pi OP.
Dfinition 5.23 : Primitive ExporterR
Cette primitive permet de faire migrer lensemble des donnes intensionnelles et
extensionnelles dune relation vers une nouvelle version de schma.
116
i ), un schma de dimension dn D et un nom
de version vn V, le rsultat de ExporterR(VS, dn , vn ) est une version VS dont le
S
schma est VS = (Vs , Cs , Ds {ds }, Hs , R, CS, 1 ), o ds est un schma de dimension (dn , P, H), et linstance est IV = IV.
Par exemple, pour faire migrer la dimension CIM10 qui appartient la version
VSn , nous excutons la primitive ExporterR(VSn , CIM10, VSn ), o le schma de
la dimension CIM10 est (CIM10, {Cle_Maladie, Libelle_maladie}, {}).
Dfinition 5.24 : Primitive DropV
Lexcution de cette primitive limine le schma et les instances dune base de
donnes multidimensionnelle. Nous pouvons excuter cette opration si la version
de schma nexiste pas dans le priode historique tabli. Ainsi, nous supposons
lexistence dune fonction boolenne indiquant si la version de schma peut tre
supprime.
i ), et un nom de version vn V tel que
(vn )=vrai, la primitive DropV(VSi ), o VSi = vn , limine la version de schma
SVi ainsi que leurs instances.
Dfinition 5.25 : Oprateur SetVersion
i ), un ensemble de primitives {EP} et les
noms de versions vn et vn V, la primitive SetVersion(VSi , {EP}, VSj ), o VSi
= vn et VSj = vn , cre la version de schma VSj dont le schma est VS = (Vs ,
Cs , Ds , Hs , R, CS, 1 ) et linstance est IV = (Vi , Ci , Di , Hi , Ri , CSi , 1
i ).
Si nous voulons crer une nouvelle version VSj partir de la version courante VSi
incluant les changements : {EP}=(DropC(VSi , Prise_MCO), DropD(VSi , Mode_sortie),
ExporterR(VSi , CIM10, VSj ), ExporterR(VSi , Etablissement, VSj ), RenameP(VSi ,
Etablissement, Codepostal, Code), ExporterR(VSi , Temps, VSj ), DeleteP(VSi , Temps,
Saison)), lexcution de SetVersion (VSi , {EP}, VSj ) donne le rsultat souhait.
Chaque primitive de lensemble EP doit respecter la dnition donne prcdemment.
5.4
Gestion temporelle des entrepts
Nous traitons dans cette section la gestion des donnes historises de notre modle. Nous montrons dabord larchitecture conue simplie du projet et linterac-
117
5.4 Gestion temporelle des entrepts
tion entre leurs composants, puis nous prsentons le modle de versions de schmas
bitemporels et nous terminons par la description du gestionnaire dvolution de
schmas.
5.4.1
Architecture simplifie du projet
Larchitecture que nous avons conue pour le projet ADELEM est compose de
trois composants principaux : linterface graphique, lentrept de donnes mdicales
et le gestionnaire dvolution. La gure 5.5 montre linteraction entre le gestionnaire
de requtes et le gestionnaire dvolution.
Interface Graphique
Entrept
de
donnes
Donnes de
dtail et rsumes
(courantes)
Fig. 5.5 Interaction des composants lintrieur de larchitecture.

Le composant Interface Graphique contient un gestionnaire de requtes qui interagit avec le gestionnaire dvolution dans lexcution de requtes sur des schmas
historiss. Nous donnons dans la suite une description de la gestion de versions de
schmas.
5.4.2
Modle de versions de schmas bitemporels
Le gestionnaire dvolution est compos dun entrept de donnes historises et

du moteur de versions. La gure 5.6 montre le modle de versions de schmas bitemporels.
Lentrept de donnes historises contient le schma et les instances de chaque
version de schma hisorise ainsi que la table de correspondance. Celle-ci est requise
pour spcier la pertinence temporelle entre les donnes intensionnelles de la version
de schma et les donnes extensionnelles. Le moteur de versions contient la fois
le stockage des deltas entre versions et les rgles de conguration que nous devons
respecter lors de la gestion des versions.
118
Gestionnaire dvolution
Entrept
de donnes
historises
Donnes intensionnelles
et extensionnelles
Stockage de deltas
+
Table de correspondance
Rgles de configuration
Fig. 5.6 Modle de versions de schmas bitemporels.

Les deltas reprsentent lensemble de dirences entre versions. Un delta symS
trique entre SVi et SVj = (SVi - SVj )
(SVj - SVi ) et un delta direct est une
squence de changements c1 , ..., cn qui appliqus sur une version v1 en gnerent une
nouvelle v2 [CW98, RGMS01].
Notre gestionnaire de versions bitemporels est au-dessus du systme de gestion
de bases de donnes. Dans cette approche, le modle de version est orthogonal au
modle de donnes du SGBD [CW98, WMC01]. Nous considrons le stockage de
lensemble de changements qui produisent une version, pour cela, le mta-schma se
compose de :
Table pour la version de schma : Identication de la version.
TVS = {ID_Version, ID_Conteneur, Version_nom, Temps_transaction,
Temps_validite, Version_immuable}
Lattribut Version_immuable est de type boolen. Par dfaut il est faux.

Table pour la relation :
TR = {ID_Relation, ID_Version, Relation_nom, Temps_transaction,
Temps_validite, Relation_immuable, Relation_type}
Lattribut Relation_type spcie les types : cube, dimension, hirarchie, vue matrialise, vue.
Table pour les attributs :
119
TA = {ID_Attribut, ID_Relation, Attribut_nom,

Attribut_type, Attribut_taille, Temps_transaction, Temps_validite,
Attribut_immuable, Key}
Lattribut Key est de type boolen et sert pour indiquer si ID_Attribut fait partie
de la cl primaire.
Table dquivalences :
TE = {ID_Attribut, ID_Relation, Attribut_nomancien,
Attribut_nomnouveau, Temps_transaction, Temps_validite, Attribut_immuable}
Cette table stocke lquivalence entre attributs renomms.

Les rgles de conguration contiennent lensemble des rgles dintgrit dj dnies, nanmoins, nous pouvons aussi en dnir de nouvelles, par exemple :
versioncourante = 1 (VSi ) = maximum
Cette rgle tablit que la version courante sera celle dont la pertinence temporelle
est maximum.
Nous avons dit prcdemment que la requte est excute sur les donnes courantes. Nanmoins, pour les requtes sur des donnes historises, le composant Interface Graphique interagit avec le composant Gestionnaire dvolution pour dterminer
la possibilit dexcution de la requte.
5.4.3
Gestionnaire dvolution de schmas
Dans cette partie, nous traitons la gestion de donnes historises et lactivit du

gestionnaire dvolution de schmas par niveau. La gure 5.7 montre le dtail de la
gestion des donnes historiques.
Nous considrons une base de donnes pour stocker le mta-schma et un ensemble de bases de donnes historiques pour enregistrer les donnes intensionnelles
et extensionnelles ainsi que la table de correspondance (TC) de chaque version de
schma. Cette table stocke la pertinence temporelle des donnes extensionnelles par
rapport la pertinence temporelle de leurs donnes intensionnelles.
La gure 5.8 dcrit lactivit du gestionnaire dvolution par niveau.
Le niveau 3 stocke lensemble des changements des versions de schma et lensemble des rgles de conguration lors de la cration et de la manipulation des
versions. A lintrieur de ce niveau, la pertinence temporelle de requtes danalyses
ou de comparaison sur des donnes courantes et historises est dtermine. Par
120
Gestionnaire dvolution
Stockage
de deltas
...
Donnes
intensionnelles
et extensionnelles
historises 1
+
Table Corresp.
Meta
Schema
Donnes
intensionnelles
et extensionnelles
historises n
+
Table Corresp.
Rgles de
Configuration
Fig. 5.7 Gestionnaire dvolution de schmas.
Deltas
+
Rgles de Configuration
T1
T2
Niveau 3
(Meta-schema)
T4
T3
UC
tv
VS01 (DI)
Niveau 2
(Intensionnel)
Table de Corresp.
Niveau 1
(Extensionnel)
VS01 (DE)
T
VS02 (DI)
Niveau 2
(Intensionnel)
Table de Corresp.
Niveau 1
(Extensionnel)
VS02 (DE)
T
VS03 (DI)
UC
Niveau 2
(Intensionnel)
tt
Table de Corresp.
Historique
VS03 (DE)
Niveau 1
(Extensionnel)
Fig. 5.8 Gestion dvolution de schmas par niveau.
121
exemple, si le mta-schma de la requte sur la version de schma courant concide

avec celui de la version de schma historique, nous pouvons excuter la requte sur
les deux versions de schmas. Dans le cas contraire, la requte est annule et lutilisateur doit tre inform. Les niveau 1 et 2 reprsentent les direntes versions de
donnes (extensionnelles et intensionnelles) de faon linaire par rapport au temps
de cration. La table de correspondance fait partie du niveau intensionnel, dans la
suite, nous dcrivons son fonctionnement.
Table de Correspondance :
Nous avons place dans le niveau 2 la table de correspondance ncessaire pour la
pertinence temporelle entre lensemble de donnes. Le schma de la table est :
{ID_Table, ID_Version, ID_Conteneur, Cle_Temps, Temps_transaction,
Temps_validite}.
Ceci nous permet de stocker les donnes extensionnelles sans leur ajouter les proprits Temps_transaction et Temps_validite. Etant donn la taille de lensemble des
donnes extensionnelles, cette table nous permet davoir un gain trs considrable
sur la quantit des donnes stocker.
Par exemple, en utilisant la syntaxe du langage TSQL2 [Sno95], nous pouvons
exprimer les requtes suivantes :
SET SCHEMA DATE now
SELECT * FROM Prise_MCO
WHERE VALID (Prise_MCO) OVERLAPS PERIOD 2003-01 - 2003-12
ou
SET SCHEMA TRANSACTION DATE 2004-07
Nous avons le mme rsultat pour les deux requtes, car elles sont excutes sur
la version de schma courant, aussi bien sur les donnes intensionnelles quintensionnelles. Au contraire, la requte :
SET SCHEMA VALID PERIOD 2002-01 - 2002-12
prend des donnes de la table Prise_MCO qui ont t valides durant la priode
2002-01 - 2002-12, cette requte utilise le schma valide durant la mme priode du
temps. Dans la suite, nous montrons un exemple plus complexe :
122
SET SCHEMA VALID PERIOD 2003-01 - 2003-12

La requte slectionne le schma valide entre 2003-01 et 2003-12 qui correspond,
dans notre cas, au schma courant. Les donnes valides entre 2002-01 et 2002-12
correspondent aux donnes de la version historise VS02.
5.5
Bilan
Dans un entrept de donnes, la manipulation des donnes historises est essentielle. Nanmoins, leur gestion est une tche complexe et coteuse. Dans ce chapitre,
nous avons prsent notre proposition pour la gestion, le stockage et la visualisation
de lensemble de donnes historises. Nous avons introduit dabord un ensemble de
versions de schmas annuels dans un contexte mdical. Ce schma est compos dune
toile avec quatre dimensions prsentant divers changements au cours du temps. En
considrant ces changements, nous avons cre un ensemble de versions de schmas
qui nous permet la manipulation des donnes sans perte. Nous avons aussi donn
une reprsentation bitemporelle pour chaque version de schma.
Pour la cration et la gestion des versions de schmas, nous avons spci une
liste doprations primitives divise en deux catgories, la premire rassemble un
ensemble de 19 primitives ncessaires pour la gestion des cubes, des dimensions
et des hirarchies. La deuxime contient 5 primitives qui agissent sur les versions
de schmas. Nous avons aussi dni loprateur SetVersion qui permet de grouper
un ensemble de primitives excuter sur une version de schma et qui gnre une
nouvelle version. De cette manire, nous pouvons contrler le nombre de versions
gnres. Nous avons aussi dni un ensemble de contraintes pour la manipulation
des versions. La smantique de lensemble de primitives doit respecter cet ensemble
de contraintes pour assurer une gestion cohrente.
Pour chaque primitive, nous avons donn sa dnition formelle. Pour ce faire,
nous avons repris la dnition dune base de donnes multidimensionnelle, dun
cube, dune dimension, dune hirarchie ainsi que de leurs instances donnes au
Chapitre 3. La dnition formelle de la primitive considre aussi bien son schma
que ses instances.
La dernire section a trait la gestion temporelle des entrepts de donnes. Nous
avons donn une architecture simplie qui dcrit linteraction entre gestionnaires
de requtes et dvolution. Nous avons prsent notre modle de versions de schmas
bitemporels compos dun entrept de donnes historises et dun moteur de versions
stockant les deltas et les rgles de conguration. Nous avons donn la description du
gestionnaire dvolution de schmas. Nous avons prsent aussi bien la gestion de
donnes historises que lactivit du gestionnaire dvolution par niveau. Le niveau
5.5 Bilan
123
1 dcrit la gestion des donnes extensionnelles, le niveau 2 prsente la manipulation

des donnes intensionnelles et le niveau 3 montre la gestion des deltas ainsi que des
rgles de conguration. Finalement, nous avons termin cette partie avec quelques
exemples de requtes en utilisant la syntaxe du langage TSQL2 pour spcier la
version de schma souhaite.
124
Chapitre 6
Conclusions et perspectives
6.1
Bilan du travail ralis
Les entrepts de donnes tendent les concepts et la technologie traditionnelle

des bases de donnes pour crer des systmes daide la dcision. Ils intgrent
des informations provenant des sources de donnes qui sont souvent htrognes
et distribues. En consquence, la conception et la mise en oeuvre dun entrept
est une tche complexe, elle se compose de trois processus : extraction-intgration,
organisation et interrogation. Notre proposition se place lintrieur des processus
dorganisation et dinterrogation.
6.1.1
Principales contributions
Nous listons nos contributions pour la conception et la mise en oeuvre dun entrept de donnes :
- Dnition dun modle multidimensionnel.
- Traitement de requtes et algorithme pour la slection optimale de vues matrialiser.
- Interface graphique pour la gnration (semi-automatique) des requtes.
- Versions de schmas bitemporels pour la gestion de donnes mdicales historises.
6.1.2
Dfinition dun modle multidimensionnel
Notre mtamodle multidimensionnel se compose de trois classes : Cube, Dimension et Hirarchie. Ce mtamodle sert la conception dun modle multidimensionnel. Pour faire cela, nous avons donn quatre dnitions : le schma dune base
multidimensionnelle, dun cube, dune dimension et le schma dune hirarchie.
125
126
Ceci nous a permis daboutir la conception dun schma en constellation pour la

construction dun entrept multidimensionnel de donnes mdicales. Il se compose
de trois sous-schmas en toile : Prise_MCO, Prise_SSR et Population, o chaque
toile contient ses propres dimensions ainsi que des dimensions qui sont partages
entre lensemble dtoiles. Nous avons identi deux hirarchies : H_Geo et H_Temps.
Finalement, nous avons utilis les informations concernant lensemble des sources
de donnes relles et des indicateurs du projet ADELEM pour prouver et vrier le
modle propos.
Tout au long de notre travail, nous avons t confronts plusieurs dicults.
La principale a t la conception du modle multidimensionnel. Pour nous, cette
tape a t trs dure, mme avec laide dune mthodologie pour sa ralisation. Ceci
d principalement la manque dun mtamodle qui puisse orienter les choix des
dirents lments (cubes, dimensions et hirarchies) et ses relations, mais aussi, en
raison de la nature sensible de donnes mdicales. Cest la raison pour laquelle nous
avons propos un mtamodle dont la caractristique fondamentale est sa simplicit. Notre objectif est de normaliser et de faciliter dans la mesure du possible le
dveloppement de cette phase.
6.1.3
Algorithme pour la slection des vues matrialiser
Nous avons appliqu notre algorithme et celui de Greedy aux donnes du projet ADELEM. Lalgorithme Greedy est simple et ecace, nanmoins, dans notre
exprimentation, partir du 6me choix, lalgorithme slectionne les vues les plus
coteuses. Ceci nous a motiv pour proposer un algorithme qui tend Greedy avec
les paramtres : frquence dutilisation, cot de calcul et frquence des mises jour
sur les relations de base.
Nous avons remarqu que plusieurs propositions utilisent comme frquence dutilisation un nombre assign chaque vue, par exemple : la frquence dutilisation
pour la vue V1 est gale 10, V2 5, V3 1, ... Ainsi, la particularit de notre
algorithme rside dans la spcication de deux propositions. La premire consiste
utiliser la complexit de la vue (nombre de ses relations dpendantes) pour les
deux premiers paramtres : la frquence dutilisation et le cot de calcul de la vue.
Ainsi, nous considrons que la frquence dutilisation dune vue augmente en proportion directe du nombre de ses relations dpendantes et que le cot de calcul
diminue dans la mme proportion. La deuxime proposition consiste dterminer la
frquence des mises jour sur les relations de base, dans ce cas, nous avons besoin
du nombre dlments lintrieur de la vue qui peuvent subir des changements.
Nous avons constat que notre proposition donne de meilleurs rsultats dans notre
cas exprimental.
La faiblesse de notre algorithme est labsence du cot dvaluation dune requte
par rapport au type dopration (Select, Project ou Join). Nous ne considrons pas
6.1 Bilan du travail ralis
127
des restrictions comme lespace de stockage.
6.1.4
Gnration (semi-automatique) des requtes
Le dveloppement de notre interface graphique est dans sa premire version. Nous

avons dvelopp deux modules : le module pour la cration et la mise jour du
schma et le module pour la gnration (semi-automatique) des requtes. Le premier
module nous permet dadapter linterface tout schma, ainsi nous avons seulement
besoin dinterroger les donnes correspondantes ce schma en utilisant le deuxime
module.
Nous avons prsent nos rsultats aux participants du projet ADELEM, ce qui
nous a permis de vrier et de prouver le fonctionnement de linterface.
6.1.5
Les actualisations ralises dans les sources des donnes doivent tre reportes sur
lentrept. Ces changements peuvent aecter aussi bien les donnes que leur structure. Pour sa gestion, nous pouvons utiliser lvolution de schmas ou les versions
de ceux-ci.
En ce qui concerne lvolution de schmas, elle permet la rcupration des donnes
existantes par le biais de leur adaptation au nouveau schma. Nanmoins, lvolution nimplique pas un support historique de celui-ci et elle ne considre non plus
un mcanisme pour la visualisation des donnes travers des schmas volus. Par
consquence le concept dvolution de schma nest pas susant et il est ncessaire
dtablir une stratgie spcique pour rpondre cette ncessit.
Lapproche des versions de schma a t utilise principalement pour la cohrence
des donnes et de leurs schmas courants. Nous considrons cette approche comme
une alternative aux systmes qui doivent grer et manipuler des donnes historiques.
Dans le cas prcis du projet ADELEM, nous proposons lutilisation de versions de
schma pour grer les aspects temporels de lentrept de donnes.
La principale caractristique de notre proposition consiste fournir une approche
simple et adapte au paradigme des entrepts pour la gestion et la manipulation
aussi bien des donnes historiques que courantes. En plus, la dirence des systmes temporels, o lensemble de donnes doit contenir la notion du temps, les
donnes extensionnelles dans notre approche sont stockes telles quelles.
Bien que nous nous sommes inspirs des caractristiques et des besoins du projet
ADELEM, notre approche de versions peut tre utilise par tout systme qui doit
grer des donnes historises. Cest la raison pour laquelle nous avons dcid duti-
128
liser les temps de transaction et de validit et de fournir lensemble de primitives

dnies.
6.2
Perspectives
Nous avons un ensemble de perspectives permettant de continuer le travail prsent ainsi que son amlioration. Nous avons dit prcdemment que nous avons
seulement dvelopp une version initiale de linterface, ainsi, nous dcrivons dabord
lextension du prototype ralis. Nous donnons aussi une autre perspective pour
la gestion des donnes, celle dinclure les aspects spatiaux aux donnes mdicales.
Finalement, nous incluons dautres perspectives quil est intressant de prendre en
compte.
6.2.1
Extension du prototype
Nous avons divis ce travail en deux parties : limplantation de lalgorithme pour

la slection des vues matrialiser et les versions de schmas pour la gestion de
donnes historises.
6.2.1.1
Algorithme propos
Le dveloppement de lalgorithme a deux objectifs : disposer dun mcanisme

pour la slection automatique de lensemble de vues matrialiser et rcuprer par
le biais de leur utilisation, des statistiques relles pour amliorer et perfectionner les
paramtres initiaux que nous avons tablis. De cette manire, nous pouvons collecter la frquence dutilisation relle des vues matrialises. Ceci nous permettra de
proposer de nouvelles vues pour leur matrialisation ou den eacer dautres. Une
autre statistique collecter est la frquence relle des mises jour des relations de
base, ce qui permettra dadapter la probabilit de changement appliquer.
Lutilisation des agrgats est loutil le plus ecace pour amliorer les performances. Nanmoins, nous devons tablir un mcanisme permettant lutilisation des
vues matrialises dans lexcution dune requte. Une ide assez simple consiste
ordonner lensemble de vues matrialises par rapport leur cot de stockage. De
cette manire, si la requte peut tre excute en utilisant la premire vue, nous arrtons le processus doptimisation. Dans le cas contraire, nous prenons la deuxime
vue de lensemble et nous continuons le processus. Si nous arrivons la n de lensemble, nous devons excuter la requte en utilisant les relations de base.
Finalement, nous considrons comme important les problmes de la gestion des
index et la possibilit dutiliser un cache pour loptimisation des requtes.
6.2 Perspectives
6.2.1.2
129
Limplantation des versions de schmas permettra lexcution des requtes sur

les donnes historises. Ainsi, nous pourrons faire des calculs prvisionnels ou des
requtes comparatives qui comportent des donnes aussi bien courantes que historises. Par exemple, si le mta-schma de la requte sur la version de schma courant
concide avec celui de la version de schma historique, nous pouvons excuter la
requte sur les deux versions de schmas. Pour faire cela, le gestionnaire dvolution
interagit avec le gestionnaire de requtes pour dterminer la possibilit dexcution
de cette requte.
Notre gestionnaire de versions bitemporels est au-dessus du systme de gestion
de bases de donnes. De cette manire, le modle de version est orthogonal au
modle de donnes du SGBD. Cette caractristique nous permet dadapter notre
modle de versions tout SGBD et pouvoir faire le choix par rapport aux besoins
de lapplication cible.
6.2.2
Aspects spatiaux des donnes
Linformation gographique dcrit des phnomnes qui adviennent sur, au dessus,

et en dessous de la surface de la terre [Sch01]. Les cartes sont un des supports de
cette information. Une carte contient des objets gographiques tels que des parcelles
doccupation des sols, des routes, des territoires communaux, etc., dans une rgion
gographique donne. Un objet gographique a des proprits de deux types :
- Une proprit spatiale reprsente par un attribut gomtrique ou encore attribut spatial. Cet attribut dcrit lemplacement dun objet dans lespace deux ou
trois dimensions.
- Des proprits qui dcrivent lobjet reprsentes par des attributs dits thmatiques ou descriptifs.
La dnition suivante du Systme dInformation Gographique (SIG) est gnralement admise :
Un systme dinformation gographique est un ensemble organis de matriels informatiques, de logiciels, de donnes gographiques et de personnel capable de saisir,
stocker, mettre jour, manipuler, analyser et prsenter toutes formes dinformations
gographiques rfrences.
La nature des donnes stockes et exploites dans les SIGs entrane beaucoup
de problmes, tant au niveau modlisation et conception quau niveau gestion au
sein dun mme systme, du fait de la complexit de stockage, de consultation et de
prsentation [Dbo97].
130
La diversit de ces donnes est une question critique : donnes textuelles, donnes
spatiales de type vectoriel telles que les donnes gomtriques, de type matriciel ( ou
rasteur) comme les donnes cartographiques, et donnes multimdia, par exemple les
images satellitales et ariennes, les donnes audio et vido. Ces donnes proviennent
de sources diverses et sous direntes chelles et formats de stockage ou dchange.
La reprsentation des donnes dans les SIGs :
Tous les SIGs utilisent trois primitives, le point, la ligne, et la rgion pour
construire la gomtrie dun objet. Deux choix sont faire pour reprsenter cette
gomtrie [Sch01] :
1. Quelle primitive utiliser (point, ligne ou rgion) ?
2. Quel mode rasteur ou vecteur dans chacun des cas ?
La description dun terrain partir de donnes de source satellitaire ou provenant
dimages ariennes est faite dans un mode reprsentation discrte appel rasteur, au
moyen dune grille : le plan est soit divis en un nombre ni de points soit dcompos
en un nombre ni de cellules rgulires. Une ligne ou une rgion peut tre reprsente
en mode rasteur par des cellules connexes. Plus la rsolution de la grille est grande,
meilleure est lapproximation obtenue.
La plupart des systmes actuels utilisent le mode vecteur : les points sont reprsents par leurs coordonnes, les lignes sont reprsentes par des segments de droite
qui sont des approximations linaires par morceaux, aussi appeles polylignes. Quant
aux rgions elles sont reprsentes par une approximation polygonale de leur frontire.
La gure 6.1 montre les deux modes pour reprsenter la gomtrie dun objet.
Aujourdhui lutilisation des SIGs et des techniques de cartographie dans le domaine de la sant en Sant Publique se dveloppe rapidement. Les ressources de
Sant Publique, les maladies spciques et les vnements sanitaires peuvent tre
reprsents et cartographis en fonction de leur environnement et de lexistence
dinfrastructures sanitaires et sociales. De telles informations, quand elles sont cartographis ensemble, crent un outil puissant pour grer et contrler les priorits en
matire de Sant Publique. Le SIG fournit un sens excellent de lanalyse de donnes pidmiologiques et programmes, rvlant les tendances, les dpendances et
les corrlations, ce qui est plus dicile mettre en valeur lorsque ces donnes sont
sous forme de tableau.
Finalement, il est intressant de faire un couplage entre larchitecture conue
pour ADELEM et un SIG. Pour faire cela, nous pouvons utiliser le logiciel HealthMapper, ceci nous permettra dacher les donnes slectionnes au travers de leur
6.2 Perspectives
131
Fig. 6.1 Reprsentation du mode vecteur et rasteur

reprsentation cartographique.
6.2.3
Construction et rafrachissement de donnes
Le processus dextraction-intgration est fondamental dans la conception dun entrept de donnes, car les donnes fournies seront stockes lintrieur de lentrept.
Pour cela, nous pensons quil est intressant de prendre en compte le dveloppement
de ce processus, due au fait que nous pouvons mesurer la qualit de lentrept par
le biais de la qualit de ses donnes. La principale problmatique est le suivi des
changements dans les sources de donnes et leur propagation vers lentrept pour
le mettre jour. Ce processus requiert une transaction de maintenance. Dans les
entrepts de donnes, une problmatique trs importante est la faon dexcuter les
transactions de maintenance sans perturber les requtes des utilisateurs.
La gure 6.2 montre larchitecture propose pour le projet WHIPS lUniversit
de Stanford [HGMW+ 95, Wid95].
Adaptateur/Moniteur : Il est associ chaque source de donnes et il a deux
fonctionnes : transformer le schma et ses instances en une reprsentation intermdiaire et dtecter automatiquement les changements dans la source pour les propager
vers lintgrateur.
Intgrateur : Il est responsable de la rception des reprsentations intermdiaires
des donnes sources, en provenance des adaptateurs, et de lintgration de celles-ci.
Lintgration entrane aussi une phase de transformation, celle-ci consiste les prparer (mise en correspondance des formats de donnes), les nettoyer, les ltrer,...,
pour les rendre conforme au schma de lentrept et aux critres de qualit choisis.
132
Entrept
de
donnes
Intgrateur
Adaptateur/
Moniteur
Source
Adaptateur/
Moniteur
Source
Adaptateur/
Moniteur
Source
Fig. 6.2 Architecture des systmes pour lintgration de donnes
Enn, la nature diverse des sources oblige programmer un adaptateur/moniteur

spcique pour chaque type de source. Du mme pour chaque entrept de donnes, dont lactivit de lintgrateur peut tre spcique. Ainsi, il est important
de proposer le dveloppement de techniques et doutils pour la gnration automatique dadaptateurs/moniteurs et dintgrateurs partir de spcications dclaratives [Ben02].
6.2.4
Grille de donnes
La dernire perspective que nous envisagions est la technologie de la Grille. Elle

vise fournir une infrastructure globale qui permet un partage de ressources coordonnes, exibles, distribues et scurises [Hea05]. Par exemple, dans le milieu
mdical [Med05], la Grille ore :
- La puissance de calcul pour des algorithmes complexes.
- Une infrastructure distribue qui permet le partage de ressources aux dirents
participants mdicaux ayant des besoins similaires de traitement de donnes.
- Une architecture commune pour laccs des donnes htrognes.
- La possibilit de grer dnormes bases de donnes (par exemple, pour des tudes
pidmiologiques).
6.2 Perspectives
133
En raison de la nature sensible de donnes mdicales, il est important de prendre

en compte des problmes propres leur condentialit, tels que : authentication
des utilisateurs, spcication de leurs droits daccs, cryptage ou suppression des
donnes relatives au patient pour la transmission sur le rseau, ...
De cette manire, nous pouvons crer un vaste rseau dans lequel il sera possible
de questionner un systme de donnes ayant une vue globale sur toute cette infrastructure.
Le datawarehouse nest quune toile de plus dans le firmament des

technologies [Gog04].
134
Bibliographie
[AAD+ 96]
[ABCM99]
[Adi02]
[AGS97]
[AQ86]
[BB03]
[BCA01]
[Bel02]
[Ben02]
[Ber03]
[Blo99]
[BPT97]
Sameet Agarwal, Rakesh Agrawal, Prasad Deshpande, Ashish Gupta,

Jerey F. Naughton, Raghu Ramakrishnan, and Sunita Sarawagi. On
the Computation of Multidimensional Aggregates. In VLDB, pages
506521, 1996.
Ulf Asklund, Lars Bendix, Henrik Baerbak Christensen, and Boris
Magnusson. The Unied Extensional Versioning Model. In System
Configuration Management, pages 100122, 1999.
M. Adiba. Entrepts de donnes et fouille de donnes, Introduction,
Supports de cours, 2002.
Rakesh Agrawal, A. Gupta, and Sunita Sarawagi. Modeling Multidimensional Databases. In Alex Gray and Per-ke Larson, editors,
Proc. 13th Int. Conf. Data Engineering, ICDE, pages 232243. IEEE
Computer Society, 711 1997.
Michel E. Adiba and N. Bui Quang. Historical Multi-Media Databases. In VLDB 86 : Proceedings of the Twelfth International Conference on Very Large Data Bases, pages 6370. Morgan Kaufmann
Publishers Inc., 1986.
X. Baril and Z. Bellahsne. Selection of Materialized Views : A CostBased Approach. In CAiSE, pages 665680, Bethesda, Maryland,
USA, 2003. J. Eder and M. Missiko.
E. Benitez, C. Collet, and M. Adiba. Entrepts de donnes : caractristiques et problmatique. Revue TSI, 20(2), 2001.
A. Belot. Dveloppement dun logiciel de cartographie de lore et de
la demande de soins hospitaliers en france. Technical report, 2002.
E. Benitez. Infrastructure adaptable pour lvolution des entrepts de
donnes. PhD thesis, Universit Joseph Fourier, Grenoble, France,
Septembre 2002.
Philip Bernstein. Applying Model Management to Classical Meta
Data Problems. In CIDR Conference on Innovative Data Systems
Research, 2003.
Bloor Research - http ://www.bloor-research.com/, 1999.
Elena Baralis, Stefano Paraboschi, and Ernest Teniente. Materialized
Views Selection in a Multidimensional Database. The VLDB Journal,
pages 156165, 1997.
135
136
[BSH98]
J.W. Buzydlowski, I-Y. Song, and L. Hassell. A Framework for ObjectOriented On-Line Analytic Processing. In ACM First International
Workshop on Data Warehousing and OLAP, Bethesda, Maryland,
USA, November 1998.
[CD97]
Surajit Chaudhuri and Umeshwar Dayal. An overview of data warehousing and OLAP technology. SIGMOD Record, 26(1) :6574, 1997.
[CGJM01]
W. Cellary, S. Gangarski, G. Jomier, and M. Manouvrier. Les versions, Chapitre 8 du livre : Bases de Donnes et Internet, Modles,
langages et systmes. Editions Herms, 2001.
[CHJM02]
D. Coadic, F. Hertout, Y. Julien, and C. Murgale. PFE : Mthodologie

dAnalyse Dcisionnelle. EISTI, 2002.
[CHS02]
Rada Chirkova, Alon Y. Halevy, and Dan Suciu. A formal perspective

on the view selection problem. The VLDB Journal, 11(3) :216237,
2002.
[CLF99]
G. Chan, Q. Li, and L. Feng. Design and Selection of Materialized

Views in Data Warehousing : A Case Study. In ACM International
Workshop on Data Warehousing and OLAP, 1999.
[Cod93]
E.F. Codd. Providing OLAP (On-Line Analytical Processing) to useranalystes : an IT mandate. Technical report, 1993.
[CT97]
Luca Cabibbo and Riccardo Torlone. Querying Multidimensional Databases. In Workshop on Database Programming Languages, pages
319335, 1997.
[CT98]
L. Cabibbo and R. Torlone. A Logical Approach to Multidimensional

Databases. In EDBT 98 : Proceedings of the 6th International Conference on Extending Database Technology, pages 183197. SpringerVerlag, 1998.
[CW98]
R. Conradi and B. Westfechtel. Version Models for Software Conguration Management. ACM Computing Surveys, 30(2) :232282, June
1998.
[DB204]
DB2
OLAP
Server
http
306.ibm.com/software/data/db2/db2olap/, 2004.
[Dbo97]
Mohamed Dbouk. HyperGo : Conception et ralisation dun Systme

dInformation Gographique Hypermdia. PhD thesis, Universit Paris
XI Orsay, Paris, France, Janvier 1997.
[DG01]
A. Doucet and S. Gangarski. Entrepts de donnes et Bases de Donnes Multidimensionnelles, Chapitre 12 du livre : Bases de Donnes
et Internet, Modles, langages et systmes. Editions Herms, 2001.
[DGS95]
C. DeCastro, F. Grandi, and M. R. Scalas. On Schema Versioning in

Temporal Databases. In S. Cliord and A. Tuzhilin, editors, Recent
Advances in Temporal Databases, pages 272294, Zurich, Switzerland,
1995. Springer Verlag.
://www-
6.2 Perspectives
[DGW+ 98]
[DSBH99]
[Dum00]
[EJWG03]
[Evo97]
[FGM00]
[Fra97]
[GBLP95]
[GM95]
[GM99]
[GM00]
[GM02]
[GMS00]
137
Curtis Dyreson, Fabio Grandi, Wolfgang, Nick Kline, Nikos Lorentzos,

Yannis Mitsopoulos, Angelo Montanari, Daniel Nonen, Elisa Peressi,
Barbara Pernici, John F. Roddick, Nandlal L. Sarda, Maria Rita Scalas, Arie Segev, Richard T. Snodgrass, Mike D. Soo, Abdullah Tansel,
Paolo Tiberio, and Gio Wiederhold. A consensus glossary of temporal
database concepts. SIGMOD Rec., 23(1) :5264, 1998.
B. Dinter, C. Sapia, M. Blaschka, and G. Hing. OLAP Market
and Research : Initiating the Cooperation. Computer Science and
Information Management, 2(3), 1999.
M. Dumas. TEMPOS : une plate-forme pour le dveloppement dapplications temporelles au dessus de SGBD objets. PhD thesis, Universit Joseph Fourier, Grenoble, France, Juin 2000.
Jr. E. James Whitehead and Dorrit Gordon. Uniform Comparison of
Conguration Management Data Models. In Software Configuration
Management, pages 7085, 2003.
Projet Evolution - http ://www.prism.uvsq.fr/recherche/themes/ anciens/teams/dataware/coop/evolution.html, 1997.
E. Franconi, F. Grandi, and F. Mandreoli. Schema Evolution and
Versioning : a Logical and Computational Characterisation. In 9th
Intl. Workshop on Foundations of Models and Languages for Data and
Objects : Database schema evolution and meta-modeling (DEMM00),
September 2000.
J-M Franco. Le Data Warehouse (Le Data Mining). Editions Eyrolles,
Paris, 1997.
J. Gray, A. Bosworth, A. Layman, and H. Pirahesh. Data Cube : A
Relational Aggregation Operator Generalizing Group-By, Cross-Tab
and Sub-Totals. Technical Report Microsoft Technical Report No.
MSR-TR-95-22., 1995.
A. Gupta and I. Mumick. Maintenance of Materialized Views : Problems, Techniques and Applications. IEEE Quarterly Bulletin on Data
Engineering ; Special Issue on Materialized Views and Data Warehousing, 18(2) :318, 1995.
Fabio Grandi and Federica Mandreoli. ODMG Language Extensions
for Generalised Schema Versioning Support. In ER Workshops, pages
3647, 1999.
A. Gutirrez and A. Marotta. An Overview of Data Warehouse Design
Approaches. 2000.
Fabio Grandi and Federica Mandreoli. A Formal Model for Temporal
Schema Versioning in Object-Oriented Databases. Technical report,
2002.
Fabio Grandi, Federica Mandreoli, and Maria Rita Scalas. A Generalized Modeling Framework for Schema Versioning Support. In
Australasian Database Conference, pages 3340, 2000.
138
[Gog04]
Jean-Franois Goglin. Le datawarehouse, pivot de la relation client.

Herms Science, 2004.
[Gup97]
Himanshu Gupta. Selection of Views to Materialize in a Data Warehouse. In ICDT, pages 98112, 1997.
[Hea05]
Healthgrid - http ://www.healthgrid.org/, 2005.
[HGMW 95] J. Hammer, H. Garcia-Molina, J. Widom, W. Labio, and Y. Zhuge.

The Stanford Data Warehousing Project. IEEE Quarterly Bulletin
on Data Engineering. Special Issue on Materialized Views and Data
Warehousing, 18(2) :4148, 1995.
+
[HMV99a]
Carlos A. Hurtado, Alberto O. Mendelzon, and Alejandro A. Vaisman.

Maintaining Data Cubes under Dimension Updates. In ICDE, pages
346355, 1999.
[HMV99b]
Carlos A. Hurtado, Alberto O. Mendelzon, and Alejandro A. Vaisman.

Updating OLAP dimensions. In DOLAP 99 : Proceedings of the 2nd
ACM international workshop on Data warehousing and OLAP, pages
6066. ACM Press, 1999.
[How03]
P. Howard. Database Performance, IBM, Oracle and Microsoft, une

valuation. Bloor Research, Novembre 2003.
[HRU95]
V. Harinarayan, A. Rajaraman, and J. Ullman. Implementing Data

Cubes Eciently. A full version. Technical Report IRI-92-23406 and
DAAH04-95-1-0192 and F33615-93-1-1339, 1995.
[HRU96]
V. Harinarayan, A. Rajaraman, and J. Ullman. Implementing Data

Cubes Eciently. In SIGMOD. ACM 0-89791-7944/96/0006, pages
205216, 1996.
[IH94]
W. Inmon and R.D. Hackathorn. Using the Data Warehouse. 1994.
[Inf02]
Informix Metacube - http ://publib.boulder.ibm.com/epubs/pdf/

ct1s9na.pdf, 2002.
[Inm92]
William Inmon. Building the Data Warehouse. QED Technical Publishing Group, Wellesley, Massachusetts, U.S.A., 1992, 1992.
[Inm95]
William Inmon. What is a Data Warehouse, White paper., 1995.
[INS05]
Institut National de la Statistique et des Etudes Economiques, France

- http ://www.insee.fr/fr/home/home_page.asp, 2005.
[JJQV99]
M. Jarke, M. Jeusfeld, C. Quix, and P. Vassiliadis. Architecture and

Quality in Data Warehouses : An Extended Repository Approach.
Information Systems, 24(3) :229253, 1999.
[JLS99]
H. Jagadish, L. Lakshmanan, and D. Srivastava. What can Hierarchies

do for Data Warehouses ? In The VLDB Journal, pages 530541, 1999.
[JQJ98]
M. Jeusfeld, C. Quix, and M. Jarke. Design and Analysis of Quality

Information for Data Warehouses. In International Conference on
Conceptual Modeling / the Entity Relationship Approach, pages 349
362, 1998.
6.2 Perspectives
139
[JV97]
M. Jarke and Y. Vassiliou. Data Warehouse Quality : A Review of

the DWQ Project. Technical report, 1997.
[KC88]
Won Kim and Hong-Tai Chou. Versions of Schema for ObjectOriented Databases. In Proceedings of the Fourteenth International
Conference on Very Large Data Bases, pages 148159. Morgan Kaufmann Publishers Inc., 1988.
[KC02]
Heum-Geun Kang and Chin-Wan Chung. Exploiting Versions for Online Data Warehouse Maintenance in MOLAP Servers. In Proceedings
of the 28th VLDB Conference, 2002.
[Kim96]
R. Kimball. Entrepts de donnes, Guide pratique du concepteur de

data warehouse. John Wiley and Sons, Inc., 1996.
[KM99]
Sachin Kulkarni and Mukesh K. Mohania. Concurrent Maintenance of

Views Using Multiple Versions. In International Database Engineering
and Application Symposium, pages 254259, 1999.
[KMP02]
Panos Kalnis, Nikos Mamoulis, and Dimitris Papadias. View selection

using randomized search. Data Knowl. Eng., 42(1) :89111, 2002.
[KR99]
Yannis Kotidis and Nick Roussopoulos. DynaMat : a dynamic view

management system for data warehouses. In SIGMOD 99 : Proceedings of the 1999 ACM SIGMOD international conference on Management of data, pages 371382. ACM Press, 1999.
[KR03]
R. Kimball and M. Ross. Entrepts de donnes, Guide pratique de

modlisation dimensionnelle. Vuibert, Paris, 2003.
[KS95]
Ralph Kimball and Kevin Strehlo. Why Decision Support Fails and
How To Fix It. SIGMOD Record, 24(3) :9297, 1995.
[KU95]
Arthur M. Keller and Jerey D. Ullman. A Version Numbering Scheme

with a Useful Lexicographical Order. In Proceedings of the Eleventh
International Conference on Data Engineering, pages 240248. IEEE
Computer Society, 1995.
[Lau96]
Sven-Eric Lautemann. An Introduction to Schema Versioning in

OODBMS. In Database and Expert Systems Applications, pages 132
139, 1996.
[LMSS95]
A. Levy, A. Mendelzon, Y. Sagiv, and D. Srivastava. Answering Queries Using Views. In Proceedings of the 14th ACM SIGACT-SIGMODSIGART Symposium on Principles of Database Systems, pages 95
104, San Jose, Calif., 1995.
[LW96]
Chang Li and Xiaoyang Sean Wang. A Data Model for Supporting

On-Line Analytical Processing. In CIKM, pages 8188, 1996.
[LZW+ 97]
W. Labio, Y. Zhuge, J. Wiener, H. Gupta, H. Garcia-Molina, and

J. Widom. The WHIPS prototype for data warehouse creation and
maintenance. In In Proceedings ACM SIGMOD International Conference on Management of Data, pages 557559, May 1997.
140
[Mar98]
[MBJ+ 02]
[ME97]
[Med05]
[MQM97]
[MS90]
[MS93]
[Mun93]
[Odb92]
[Ola04]
[ORA96]
[PCTM02]
[PCTM03]
[PMS04]
[Qui99]
[QW97]
[RGMS01]
P. Marcel. Manipulations de Donnes Multidimensionnelles et Langages de Rgles. PhD thesis, Institut National des Sciences Appliques
de Lyon, France, 1998.
Renata Matos, Adriana Bueno, Anelise Jantsch, Nina Edelweiss, and
Clesio Saraiva. Dynamic Schema Evolution Management Using Version in Temporal Object-Oriented Databases. In Database and Expert
Systems Applications, pages 524533, 2002.
Viviane Pereira Moreira and Nina Edelweiss. Queries to Temporal
Databases Supporting Schema Versioning, 1997.
Aci project MEDIGRID : medical data storage and processing on the
GRID - http ://www.creatis.insa-lyon.fr/medigrid/, 2005.
Inderpal Singh Mumick, Dallan Quass, and Barinderpal Singh Mumick. Maintenance of data cubes and summary tables in a warehouse.
In SIGMOD 97 : Proceedings of the 1997 ACM SIGMOD international conference on Management of data, pages 100111. ACM Press,
1997.
E. McKenzie and Richard Thomas Snodgrass. Schema evolution and
the relational algebra. Inf. Syst., 15(2) :207232, 1990.
Simon Monk and Ian Sommerville. Schema evolution in OODBs using
class versioning. SIGMOD Rec., 22(3) :1622, 1993.
B. P. Munch. Versioning in a Software Database - The Change Oriented Way. PhD thesis, Norwegian Institute of Technologie, 1993.
Erik Odberg. A Framework for Managing Schema Versioning in
Object-Oriented databases. In DEXA, pages 115120, 1992.
The OLAP Report - http ://www.olapreport.com/fasmi.htm, 2004.
Oracle Express Server - http ://otn.oracle.com/documentation /express_server.html, 1996.
J. Poole, D. Chang, D. Tolbert, and D. Mellor. Common Warehouse
Metamodel, An Introduction to the Standard for Data Warehouse Integration. Wiley Publishing, Inc., 2002.
J. Poole, D. Chang, D. Tolbert, and D. Mellor. Common Warehouse
Metamodel, Developers Guide. Wiley Publishing, Inc., 2003.
Programme de Mdicalisation des Systmes dInformation http ://www.atih.sante.fr/, 2004.
Christoph Quix. Repository Support for Data Warehouse Evolution.
In DMDW, page 4, 1999.
Dallan Quass and Jennifer Widom. On-line warehouse view maintenance. In Proceedings of the 1997 ACM SIGMOD international
conference on Management of data, pages 393404. ACM Press, 1997.
John F. Roddick, Fabio Grandi, Federica Mandreoli, and Maria Rita
Scalas. Beyond Schema Versioning : A Flexible Model for SpatioTemporal Schema Selection. Geoinformatica, 5(1) :3350, 2001.
6.2 Perspectives
141
[RKZ+ 99]
E. A. Rundensteiner, A. Koeller, X. Zhang, A. J. Lee, A. Nica, A. Van

Wyk, and Y. Lee. Evolvable view environment (EVE) : non-equivalent
view maintenance under schema changes. In SIGMOD 99 : Proceedings of the 1999 ACM SIGMOD international conference on Management of data, pages 553555. ACM Press, 1999.
[RKZ00]
Elke A. Rundensteiner, Andreas Koeller, and Xin Zhang. Maintaining

data warehouses over changing information sources. Commun. ACM,
43(6) :5762, 2000.
[Rod92]
John F. Roddick. Schema evolution in database systems : an annotated bibliography. SIGMOD Rec., 21(4) :3540, 1992.
[Rod95]
John F. Roddick. A survey of schema versioning issues for database

systems. Information and Software Technology, 37(7) :383393, 1995.
[RR97]
Young-Gook Ra and Elke A. Rundensteiner. A Transparent SchemaEvolution System Based on Object-Oriented View Technology. IEEE
Transactions on Knowledge and Data Engineering, 9(4) :600624,
1997.
[SA04]
Maria-Trinidad Serna and Michel Adiba. Los Almacenes de Datos

como soporte a la decisin mdica. In Proceedings of the Congreso Internacional en Ciencias Computacionales(CICC04), Colima, Mxico,
Mars 2004.
[SA05a]
Maria-Trinidad Serna and Michel Adiba. Conception et optimisation

dun entrept de donnes mdicales. Revue des Nouvelles Technologies
de lInformation. RNTI-B-1, pages 122140, 2005.
[SA05b]
Maria-Trinidad Serna and Michel Adiba. Exploiting bitemporal

schema versions for managing an historical medical data warehouse : A
case study. In Proceedings of the Encuentro Nacional de computacin
(ENC05), Puebla, Mxico, September 2005.
[SAS04]
SAS OLAP Server - http ://www.sas.com/technologies/dw/storage/

mddb/, 2004.
[Sat03]
Ulrike Sattler. Data Warehouse Models and OLAP Operations http ://www.cs.man.ac.uk/ sattler/teaching/cs636.html, 2003.
[Sch01]
Michel School. Bases de donnes gographiques, volume Chapitre 6.

Editions Herms, 2001.
[SDJL96]
Divesh Srivastava, Shaul Dar, H. V. Jagadish, and Alon Y. Levy. Answering Queries with Aggregation Using Views. In VLDB 96 : Proceedings of the 22th International Conference on Very Large Data Bases,
pages 318329. Morgan Kaufmann Publishers Inc., 1996.
[SMKK98]
Sunil Samtani, Mukesh K. Mohania, Vijay Kumar, and Yahiko Kambayashi. Recent Advances and Research Problems in Data Warehousing. In ER Workshops, pages 8192, 1998.
[SMS04]
Site du Ministre des Solidarits de la Sant et de la Famille http ://www.sante.gouv.fr/, 2004.
142
[Sno95]
Richard T. Snodgrass. The TSQL2 Temporal Query Language. Kluwer

Academic Publishers, 1995.
[Sno99]
Richard T. Snodgrass. Developing Time-Oriented Database Applications in SQL. Morgan Kaufmann, 1999.
[Tes00]
O. Teste. Modlisation et manipulation dentrepts de donnes complexes et historises. PhD thesis, Universit Paul Sabatier de Toulouse,
Dcembre 2000.
[TS93]
Markus Tresch and Marc H. Scholl. Schema transformation without

database reorganization. SIGMOD Rec., 22(1) :2127, 1993.
[TS99]
D. Theodoratos and T. Sellis. Dynamic Data Warehouse Design. In

Data Warehousing and Knowledge Discovery, pages 110, 1999.
[TU98]
Michael Teschke and Achim Ulbrich. Concurrent Warehouse Maintenance Without Compromising Session Consistency. In Database and
Expert Systems Applications, pages 776785, 1998.
[Var00]
G. Vargas. Service dvenements flexible pour lintgration dapplications bases de donnes rparties. PhD thesis, Universit Joseph
Fourier, Grenoble, France, Dcembre 2000.
[Vas98]
Panos Vassiliadis. Modeling Multidimensional Databases, Cubes and

Cube Operations. In SSDBM 98 : Proceedings of the 10th International Conference on Scientific and Statistical Database Management,
pages 5362. IEEE Computer Society, 1998.
[VGD00]
A. Vavouras, S. Gatziu, and K. Dittrich. Modeling and Executing the

Data Warehouse Refreshment Process. Technical Report i-2000.01,
11, 2000.
[VQVJ00]
Panos Vassiliadis, Christoph Quix, Yannis Vassiliou, and Matthias

Jarke. A Model for Data Warehouse Operational Processes. In Conference on Advanced Information Systems Engineering, pages 446461,
2000.
[VS99]
Panos Vassiliadis and Timos K. Sellis. A Survey of Logical Models for

OLAP Databases. SIGMOD Record, 28(4) :6469, 1999.
[WB97]
M-C Wu and A.P. Buchmann. Research Issues in Data Warehousing.

In BTW German Database Conference, 1997.
[Wid95]
Jennifer Widom. Research problems in data warehousing. In CIKM

95 : Proceedings of the fourth international conference on Information
and knowledge management, pages 2530, New York, NY, USA, 1995.
ACM Press.
[WMC01]
Bernhard Westfechtel, Bjorn P. Munch, and Reidar Conradi. A Layered Architecture for Uniform Version Management. Software Engineering, 27(12) :11111133, 2001.
[YKL97]
J. Yang, K. Karlapalem, and Q. Li. Algorithms for Materialized View

Design in Data Warehousing Environment. In The VLDB Journal,
pages 136145, 1997.
6.2 Perspectives
143
[YW00]
J. Yang and J. Widom. Making temporal views self-maintainable for

data warehousing. In ICDE, In Proceedings of the 7th International
Conference on Extending Database Technology, March 2000.
[ZR98]
Xin Zhang and Elke A. Rundensteiner. Data Warehouse Maintenance

Under Concurrent Schema and Data Updates. Technical report, 1998.
[ZS99]
Thomas Zurek and Markus Sinnwell. Datawarehousing Has More Colours Than Just Black & White. In VLDB 99 : Proceedings of the 25th
International Conference on Very Large Data Bases, pages 726729.
Morgan Kaufmann Publishers Inc., 1999.
[ZYY01]
C. Zhang, X. Yao, and J. Yang. An evolutionary approach to materialized view selection in a data warehouse environment. IEEE Trans.
Systems, Man, Cybernetics, PART C, 31 :282294, September 2001.
144
Annexe A
Description des sources de donnes
Caractristiques du fichier RSA :
Tout sjour hospitalier, eectu dans la partie court sjour dun tablissement,
fait lobjet dun Rsum de Sortie Standardis (R.S.S.) constitu dun ou plusieurs
Rsum(s) dUnit Mdicale (R.U.M.). La transmission dinformations mdicales
la direction de ltablissement ou lextrieur de celui-ci, sopre sur la base de
donnes agrges ou de Rsums de Sortie Anonymes (R.S.A.) obtenus par transformation des RSS. La production des RSA est automatise. A partir du chier de RSS
groups, le mdecin responsable du DIM utilise le logiciel GENRSA (Gnrateur de
RSA), proprit de lEtat, pour produire le chier de RSA. A la dirence du RSS,
le RSA constitue toujours un enregistrement unique par sjour.
Description des variables du fichier :
GHM : Tout Rsum de Sortie Standardis est class dans un Groupe Homogne
de Malades. La classication en GHM permet un classement exhaustif et unique :
tout sjour est obligatoirement class dans un GHM et dans un seul. A partir des
variables mdico-administratives contenues dans le RSS, chaque sjour va aboutir
dans lun des groupes de la classication. Celle-ci comporte 512 groupes, soit 462
GHM et 50 groupes autres, dont 46 groupes "ambulatoires" et 4 groupes dans la
Catgorie Majeure n90 (erreurs et sjours inclassables).
CMD : Les sjours de moins de 24 heures (sances, dcs immdiat, transfert
immdiat, pathologies traites en moins de 24 heures) sont classs dans la Catgorie
Majeure n24 (CM24 : sances et sjours de moins de 24 heures), spcicit franaise
absente de la classication amricaine qui ne prend pas en compte les sjours de
moins de 48 heures. Les sjours de plus de 24 heures sont classs dans lune des 23
Catgories Majeures de Diagnostic (CMD01 CMD23), en fonction du diagnostic
principal contenu dans le RSS.
RUM : Le RUM contient un nombre limit dinformations qui doivent tre systmatiquement renseignes. Ces informations sont dordre administratif et mdical.
Pour que les informations mdico-administratives contenues dans le RUM puissent
145
146
bncier dun traitement automatis, elles sont codes selon des nomenclatures et
des classications standardises. Les nomenclatures utilises pour coder les RUM
sont :
Pour le codage des diagnostics, la Classication Internationale des Maladies (C.I.
M.)
Pour le codage des actes, le Catalogue des Actes Mdicaux (C.d.A.M.)
DP : (concerne les sjours de plus de 24 heures) :
Dans le cas dun sjour mono-unit, le diagnostic principal contenu dans le RUM
devient celui du RSS.
Dans le cas dun sjour multi-unit, le diagnostic principal est obtenu par lalgorithme suivant : si un seul RUM comporte un acte classant opratoire, le DP de ce
RUM est celui du RSS ; si aucun RUM ne mentionne dacte classant opratoire ou,
si plusieurs RUM en mentionnent (au moins) un, le DP du RSS est celui du RUM
dont la dure de sjour est la plus longue ; si deux RUM possdent la mme dure
de sjour, le DP du RSS est celui du RUM de la dernire unit chronologiquement
frquente.
Codage du mode dentre Le mode dentre dans lunit mdicale se code comme
suit :
6 : mutation La mutation signie la provenance dune autre unit mdicale de la
mme entit juridique.
7 : transfert normal Le transfert normal signie la provenance dune autre entit
juridique pour une hospitalisation part entire, distinguer du cas de la prestation
ralise pour le compte de ltablissement dorigine, cod 0.
8 : domicile Le patient vient de chez lui.
0 : transfert pour ou aprs ralisation dun acte Ce type particulier de transfert
est rserv deux cas :
Un tablissement "prestataire" reoit un patient pour une dure de moins de 48
heures dans le seul but de raliser un acte que ltablissement dorigine ne peut
pas raliser lui-mme. Cette "prestation" donnera dailleurs lieu une facturation
ltablissement dorigine.
Un tablissement "donneur dordre" rcupre un patient quil avait transfr pour
la ralisation dun acte quil ne pouvait raliser lui-mme. Il sagit donc de la n de
la prestation.
Codage du mode de sortie Le mode dentre dans lunit mdicale se code comme
suit :
147
6 : mutation La mutation signie le dpart vers une autre unit mdicale de la
mme entit juridique.
7 : transfert normal Le transfert normal signie le dpart vers une autre entit
juridique, distinguer du cas dun retour ltablissement dorigine aprs la ralisation dune prestation, cod 0.
8 : domicile Le patient rentre chez lui.
9 : dcs Le patient est dcd dans lunit mdicale.
0 : transfert pour ou aprs ralisation dun acte Ce type particulier de transfert
est rserv deux cas :
Un tablissement "prestataire" retourne le patient dans son tablissement dorigine aprs lavoir accueilli pour une dure de moins de 48 heures dans le seul but de
raliser un acte qui ne pouvait pas tre ralis sur place. Il facture dailleurs cette
"prestation" ltablissement dorigine.
Un tablissement "donneur dordre" envoie un patient dans un autre tablissement pour la ralisation dun acte quil ne peut raliser lui-mme.
Liste Alphabtique des Variables :
Les variables sont classes dans lordre alphabtique de leur code et sont dcrites
dans le tableau de la manire suivante :
-
le code
le type (numrique ou caractre)
la longueur
le libell
Les tableaux A.1 et A.2 dcrivent les variables du chier RSA.

Notation :
* = Pour le priv
+ = Pour le public
La variable Filler pour les RSA publics regroupe les champs 34, 35 et 36 des RSA
des tablissements privs.
Caractristiques du fichier FINESS :
Ce chier recense les structures sanitaires et sociales au niveau national, chaque
structure tant renseigne par son numro FINESS. Il contient trois types de structures publiques ou prives :
148
Variable
FINESS
Type
Caractre
Taille
9
Champ 2
Caractre
Champ 3 + numRSA
Champ 5
Caractre
Caractre
10
3
Champ 6
Champ 7 + cmd_
tab + ghm_tab
+ Champ 10
Champ 11 + cmd +
ghm + Champ14
Caractre
Caractre
3
9
Caractre
Champ 15
Numrique
AGE_ANNEES
AGE_JOURS
Numrique
Caractre
3
3
sexe
Mode_ent
Caractre
Caractre
1
1
Provenan
Caractre
Mois_sor
Anne_sor
Mode_sor
Destinat
Caractre
Caractre
Caractre
Caractre
2
4
1
1
Type_sjour
Nbre_rad
Caractre
Numrique
1
2
Nbre_dia
Dure_se
Numrique
Numrique
2
3
Libell
Numro FINESS de
lentit juridique
N de version du
format du RSA (C05)
Clef de validation
Numro de version du format
du "RSS-group" (ou du RSS) lu
N de version de Genrsa
Groupage lu sur le
"RSS-group" : V,
CMD, GHM, code retour
Groupage obtenu
par GENRSA : V,
CMD, GHM, code retour
Nombre de RUM composant
le RSS dorigine
Age en annes
Age en jours (si < 1 an)
calcul lentre
Sexe
Mode dentre dans
le champ du PMSI
Provenance (si le
mode dentre est
mutation ou transfert)
Mois de sortie du champ PMSI
Anne de sortie du champ PMSI
Mode de sortie du champ PMSI
Destination (si le
mode de sortie est
mutation ou transfert)
Type de sjour
Nombre dactes de
radiothrapie
Nombre dactes de dialyse
Dure totale du sjour
dans le champ du PMSI
(vide si sances)
Tab. A.1 Description des variables du chier RSA
149
Variable
Champ 29
Type
Caractre
Taille
3
Code_geo
Poids
Nbre_sea
Igs2
Filler
Champ 34
Champ 35
Champ 36
Diag_pri
Diag_rel
Nbre_di1
Caractre
Numrique
Numrique
Caractre
Caractre
Caractre
Caractre
Caractre
Caractre
Caractre
Numrique
5
4
2
3
8
1
1
6
6
6
2
Nbre_act
Numrique
Libell
Dure de la priode
sur laquelle stalent
les sances (si sances)
Code gographique de rsidence
Poids la naissance (en grammes)
Nombre de sances
IGS 2
Filler +
Code de prise en charge *
Facture associe 0 franc *
Zone rserve *
Diagnostic principal (DP)
Diagnostic reli (DR)
Nombre de diagnostics
associs (Nd) dans ce RSA
Nombre dactes (Na) dans ce RSA
Tab. A.2 Description de variables du chier RSA

Les structures sanitaires : structures hospitalires, autres centres de soins, laboratoires et pharmacies.
Les structures sociales : personnes ges, jeunesse handicape, adultes handicaps,
aide sociale lenfance, adultes en dicult sociale.
Les structures de formation des personnels sanitaires et sociaux.
Mise jour :
Les mises jour de ce chier sont faites annuellement par la DRASS (Direction
Rgionale des Aaires Sanitaires et Sociales) et la DDASS (Direction Dpartementale des Aaires Sanitaires et Sociales).
La source de donnes :
Les donnes proviennent du site Internet du ministre de la sant : http ://www.
sante.gouv.fr. Le chier national des tablissements sanitaires et sociaux (FINESS)
est gr par la Direction de la Recherche, des Etudes de lEvaluation et des Statistiques (DREES) - Unit Rpertoires - Ministre de lEmploi et de la Solidarit, en
liaison avec les services dconcentrs de lEtat (DDASS, DRASS).
Description des variables du fichier :
Fichier FINESS : Fichier National des Etablissements Sanitaires et Sociaux.
150
Une entit juridique : Correspond la notion de personne morale. Une personne

morale exerce son activit dans des tablissements. Elle reprsente juridiquement
lensemble de ses tablissements.
Un tablissement : Correspond une implantation gographique. De plus, quand
dans un mme lieu, plusieurs activits dpendent de budgets distincts, on identie
autant dtablissements dans le mme lieu que de budgets distincts. Exemple : un
Centre hospitalier rgional C.H.R (entit juridique) peut avoir plusieurs implantations gographiques et dans certaines de ses implantations avoir un service de soins
de longue dure qui dpend dun budget annexe. Il y aura dans FINESS autant
dtablissements que dimplantations gographiques et de services dpendant dun
budget annexe. Une association (entit juridique) grant sur un mme lieu un C.A.T.
et un foyer dhbergement aura, dans FINESS, 2 tablissements la mme adresse
puisque ces 2 structures ont rglementairement des budgets spars.
Le numro FINESS : A chaque tablissement et chaque entit juridique est attribu un numro FINESS 9 chires dont les 2 premiers correspondent au numro
de dpartement dimplantation. Ce numro est un numro de rfrence en particulier pour la facturation hospitalire et la liquidation de scurit sociale. Rien ne
distingue, dans la constitution du numro, un numro dentit juridique dun numro dtablissement.
Le type dtablissement : Les tablissements sont caractriss dans FINESS par
leur catgorie et les disciplines quils sont autoriss exercer. Ces informations sont
la traduction dune rglementation complexe et de la possibilit de pluridisciplinarit des tablissements sanitaires. Exemple : un tablissement dun C.H.R (lieu
gographique) peut la fois comprendre des services de mdecine, de chirurgie, une
maternit et une cole dinrmire. Pour faciliter votre recherche, nous avons retenu
une prsentation par type dtablissement qui rsulte du croisement des informations
de catgorie et de disciplines. Un tablissement pourra ainsi appartenir plusieurs
types en fonction de son niveau de pluridisciplinarit.
La catgorie : Elle caractrise le cadre rglementaire dans lequel sexerce lactivit de ltablissement. Exemples : centre Hospitalier, Institut mdico-ducatif,
centre daide par le travail.
La discipline : Dsigne une activit homogne qui est fonction du type de soins ou
de service social. Exemple : mdecine gnrale, pdiatrie, chirurgie, hbergement, accueil temporaire, ducation. Dans le domaine sanitaire, certaines autorisations sont
faites par Grands Groupes de Disciplines GGDE qui sont des regroupements de disciplines. Dans le cadre de ce site Internet, les informations relatives ces disciplines
prsentes dans le chier FINESS ne sont pas accessibles dans leur dtail. Seules
apparaissent sur la che des tablissements concerns les GGDE des tablissements
sanitaires et les disciplines denseignement des tablissements denseignements.
151
Le statut : Caractrise la situation juridique de la personne morale dont dpend

ltablissement. Exemple : tablissement dhospitalisation communal, association loi
1901 reconnue dutilit publique, SARL.
La capacit : Pour les tablissements sanitaires, est ache la capacit en lits
par grand groupe de discipline autorise (par un arrt) et mise en uvre (dont
linstallation a t constate et certie conforme). Pour les tablissements sociaux,
est ache la capacit totale observe en places par sexe. Pour les tablissements
denseignement, est ach le nombre de places dune promotion par discipline denseignement.
Les adresses : Pour les tablissements sanitaires et sociaux, est ache, quand elle
existe, une deuxime adresse : ladresse daccueil durgence 24H sur 24 pour le public.
Le tarif : Dtermine lautorit responsable de la xation du tarif principal de
ltablissement et la procdure utilise.
La participation au service public hospitalier : Pour les tablissements privs relevant de la loi hospitalire, il indique si ltablissement participe au service public
hospitalier et sous quelle forme.
Les numros SIREN et SIRET : Sont lidentiant de lentit juridique (SIREN)
et celui de ltablissement (SIRET) attribu par lINSEE dans le cadre du systme
national lgal didentication des entreprises et de leurs tablissements.
Liste Alphabtique des Variables :
Variable
Adresse
Adressepublic
Capaciteautorisee1
Capaciteautorisee2
Capaciteautorisee3
Capaciteautorisee4
Capaciteautorisee5
Capacitemiseenoeuvre1
Type
Char
Char
Num
Num
Num
Num
Num
Num
Num
Taille
35
25
8
8
8
8
8
8
8
Libell
Adresse de ltablissement
Adresse de ltablissement
capacit autorise en nombre de lits
capacit observe en nombre de lits
Tab. A.3 Description de variables du chier FINESS
152
Variable
Code1
Code2
Code3
Code4
Code5
CodePSPH
Codecategorie
Codepostal
Codepostalpublic
Codestatut
Codetarif
Compldistrpublic
Complementdistribution
Dateouvert
FINESSjuridique
Fax
Faxpublic
GGDE1
GGDE2
GGDE3
GGDE4
GGDE5
LibPSPH
Libcategorie
Libelleroutage
Libstatut
Libtarif
LieuditBP
LieuditBPpublic
NumeroFINESS
Raisonsociale
Routagepublic
SIRET
Tel
Telpublic
Type
Num
Num
Num
Num
Num
Num
Num
Num
Num
Num
Num
Char
Num
Num
Char
Char
Char
Char
Char
Char
Char
Char
Char
Char
Char
Char
Char
Char
Char
Char
Char
Char
Char
Char
Char
Char
Char
Char
Taille
8
8
8
8
8
8
8
8
8
8
8
5
8
8
20
35
20
9
15
15
20
20
20
20
20
20
25
30
25
20
35
10
9
65
20
20
15
15
Libell
Code de la discipline
Code de Part. au Serv. Pub. Hosp.
Code lactivit de ltab.
Code postal
Code postal public
Code le statut de ltab.
Code de lautorit xant le tarif
Complment de distribution public
Complment de distribution
Date douverture
Numro FINESS juridique
Numro Fax
Numro Fax public
Grands Groupe de Discipline 1
Libell de Part. au Serv. Pub. Hosp.
Libell de la catgorie
Libelle du routage
Libell du statut
Libell de lautorit xant le tarif
Lieudit BP
Lieudit BP public
Numro FINESS
Nom de ltablissement
Routage public
Numro SIRET
Numro Tlphone
Numro Tlphone public
Tab. A.4 Description de variables du chier FINESS

These - Conception Et Réalisation D'un Data Warehouse Pour La Mise en Place D'un Système Décisionnel

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

These - Conception Et Réalisation D'un Data Warehouse Pour La Mise en Place D'un Système Décisionnel

Uploaded by

Copyright:

Available Formats

Entrep

To cite this version:

HAL Id: tel-00184256

HAL is a multi-disciplinary open access

Larchive ouverte pluridisciplinaire HAL, est

UNIVERSIT JOSEPH FOURIER

prsente et soutenue publiquement par

Mara Trinidad Serna Encinas

Entrepts de donnes pour laide la

A mon pre, o quil soit. A mi padre, donde quiera que est.

Table des matires

2 Entrepts de donnes multidimensionnelles et aspects temporels

2.5.4 Projet EVOLUTION . . . . . . . . . . . . . . . . . .

3 Architecture et modle pour un entrept de donnes mdicales

4 Systme daide la dcision mdicale : une exprimentation

Interface graphique pour la Gnration (semi-automatique) dIndicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 Aspects temporels et versions de schmas dans les entrepts

Table des figures

Architecture gnrale dun systme dcisionnel . . . . . . . . . . . . .

Architecture dun entrept de donnes . . .

3.1 Architecture propose dun systme dcisionnel . . . . .

4.1 Schma en toile Adelem_MCO . . . . . . . . . . .

Trois versions de schmas annuels. . . . . . . . . . . . . . . . . . .

Reprsentation du mode vecteur et rasteur . . . . . . . . . . . . . . . 131

Liste des tableaux

Dirences entre SGBD et entrepts de

Description des sources de donnes . . . . . . . . . . . . . . . . . . . 61

Liste de relations de base . . . . . . . . . . . . . . . . . . .

Primitives pour la gestion de relation . . . . . . . . . . . . . . . . . . 106

des variables du chier RSA .

Les entrepts de donnes pour laide la dcision

La dnition classique dun entrept donne par [IH94] :

1.2 Le projet ADELEM : Aide la Dcision Logistique et Mdicale

Fig. 1.1 Architecture gnrale dun systme dcisionnel

Le projet ADELEM : Aide la Dcision Logistique et Mdicale

Action Concerte Incitative "Technologies pour la Sant". Projet ADELEM. 2001

est ncessaire de mettre au point des outils logiciels danalyse et de visualisation.

1.2 Le projet ADELEM : Aide la Dcision Logistique et Mdicale

les renseignements sur lorigine gographique des patients pour la consommation de

Fig. 1.2 Tous les tablissements au niveau national

Problmatique et objectif de la thse

Conception dun systme pour le dcisionnel

La conception et la construction dun entrept de donnes est une tche complexe

1.3 Problmatique et objectif de la thse

pour le risque couvert. Nanmoins, la dimension Bien_assure contient lensemble

Slection des vues matrialiser

La slection de lensemble optimal des vues matrialiser fait partie du processus

1.3 Problmatique et objectif de la thse

lensemble de relations de base partir desquelles nous slectionnerons les vues

Gestion de lvolution des entrepts

Le problme dvolution de schma apparat quand un changement au schma

Fig. 1.3 Gestion de lvolution du schma dans un entrept

Notre objectif consiste la conception et mise en oeuvre dun entrept de donnes

Notre travail se focalise sur les processus dorganisation et dinterrogation. Nous

Pour le mtamodle, nous avons spci trois mtaclasses : Cube, Dimension et

1.4 Dmarche et contribution

Algorithme pour la slection des vues matrialiser

Interface pour la gnration (semi-automatique) des indicateurs

Lobjectif de notre interface est de faciliter la tche de cration dindicateurs pour

Versions de schmas bitemporels

Nous proposons lutilisation des versions de schmas bitemporels pour la gestion,

Nous prsentons ici lorganisation du document.

1.5 Plan de la thse