These

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, Prsident
Mme. Anne Doucet, Rapporteur
M. Mokrane Bouzeghoub, Rapporteur
M. Jacques Demongeot, Examinateur
M. Ren Ecochard, Examinateur
M. Michel Adiba, Directeur de thse
Remerciements
Je tiens remercier Anne Doucet, professeur lUniversit Pierre et Marie Cu-
rie de Paris (LIP6), et Mokrane Bouzeghoub, professeur lUniversit de Versailles
(PRiSM), pour avoir accept dtre rapporteur et pour leurs commentaires et cri-
tiques constructives qui mont apport un regard clairant sur les contributions de
cette thse. Je remercie aussi Jacques Demongeot, professeur lInstitut dIngnie-
rie 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 Su-
prieure 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 (ENSI-
MAG), 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, Kha-
lid 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 aven-
ture 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.1 Les entrepts de donnes pour laide la dcision . . . . . . . . . . . 2
1.2 Le projet ADELEM : Aide la Dcision Logistique et Mdicale . . . 3
1.3 Problmatique et objectif de la thse . . . . . . . . . . . . . . . . . . 6
1.3.1 Conception dun systme pour le dcisionnel . . . . . . . . . . 6
1.3.2 Slection des vues matrialiser . . . . . . . . . . . . . . . . . 8
1.3.3 Gestion de lvolution des entrepts . . . . . . . . . . . . . . . 9
1.3.4 Objectif de la thse . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Dmarche et contribution . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.1 Mtamodle multidimensionnel . . . . . . . . . . . . . . . . . 10
1.4.2 Algorithme pour la slection des vues matrialiser . . . . . . 11
1.4.3 Interface pour la gnration (semi-automatique) des indicateurs 11
1.4.4 Versions de schmas bitemporels . . . . . . . . . . . . . . . . . 11
1.5 Plan de la thse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Entrepts de donnes multidimensionnelles et aspects temporels 15
2.1 Entrepts de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1 Architecture dun entrept de donnes . . . . . . . . . . . . . 15
2.1.2 Entrepts et les bases de donnes . . . . . . . . . . . . . . . . 17
2.2 Modlisation multidimensionnelle . . . . . . . . . . . . . . . . . . . . 18
2.2.1 Schmas relationnels . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.2 Schma multidimensionnel (Cube) . . . . . . . . . . . . . . . . 22
2.3 Manipulation des donnes multidimensionnelles . . . . . . . . . . . . 23
2.3.1 Oprations classiques . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.2 Oprations agissant sur la structure . . . . . . . . . . . . . . . 24
2.3.3 Oprations agissant sur la granularit . . . . . . . . . . . . . . 27
2.4 Serveurs OLAP (On-Line Analytical Processing) . . . . . . . . . . . . 27
2.4.1 ROLAP (Relational OLAP) . . . . . . . . . . . . . . . . . . . 28
2.4.2 MOLAP (Multidimensional OLAP) . . . . . . . . . . . . . . . 30
2.4.3 HOLAP (Hybrid OLAP) . . . . . . . . . . . . . . . . . . . . . 32
2.5 Les projets de recherche . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.5.1 WHIPS Warehouse Information Prototype at Stanford . . . . . 34
2.5.2 SIRIUS Supporting the Incremental Refreshment of Informa-
tion warehouses . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.5.3 DWQ Foundations of Data Warehouse Quality . . . . . . . . . 35
i
ii
2.5.4 Projet EVOLUTION . . . . . . . . . . . . . . . . . . . . . . . 37
2.6 Aspects temporels des entrepts . . . . . . . . . . . . . . . . . . . . . 37
2.6.1 Etat courant des versions . . . . . . . . . . . . . . . . . . . . . 38
2.6.2 Espace de versions . . . . . . . . . . . . . . . . . . . . . . . . 43
2.6.3 Versions bases sur ltat et sur les changements . . . . . . . . 44
2.6.4 Graphes de version . . . . . . . . . . . . . . . . . . . . . . . . 45
2.6.5 Gestion de versions extensionnelles et intensionnelles . . . . . 46
2.6.6 Oprations primitives . . . . . . . . . . . . . . . . . . . . . . . 47
2.7 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3 Architecture et modle pour un entrept de donnes mdicales 49
3.1 Architecture dun systme dcisionnel . . . . . . . . . . . . . . . . . . 50
3.1.1 Interface graphique pour la Gnration (Semi - automatique)
dIndicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.1.2 Entrept de donnes . . . . . . . . . . . . . . . . . . . . . . . 51
3.1.3 Gestionnaire dEvolution . . . . . . . . . . . . . . . . . . . . . 51
3.2 Mtamodle Multidimensionnel . . . . . . . . . . . . . . . . . . . . . 51
3.2.1 Relations entre les mtaclasses . . . . . . . . . . . . . . . . . . 52
3.2.2 Contraintes entre les mtaclasses . . . . . . . . . . . . . . . . 53
3.2.3 Description des Mtaclasses . . . . . . . . . . . . . . . . . . . 53
3.2.4 Dnition dun modle multidimensionnel . . . . . . . . . . . 54
3.3 Analyse des donnes dune application mdicale . . . . . . . . . . . . 59
3.3.1 Sources de donnes . . . . . . . . . . . . . . . . . . . . . . . . 59
3.3.2 Analyse des donnes . . . . . . . . . . . . . . . . . . . . . . . 61
3.4 Classication des indicateurs du projet . . . . . . . . . . . . . . . . . 62
3.4.1 Indicateurs dore (gographiques - spatio-temporels) . . . . . 63
3.4.2 Indicateurs de consommation, de besoins et de ux (temporels) 63
3.4.3 Nouveaux indicateurs de consommation et de ux (temporels) 64
3.5 Application du modle multidimensionnel dans le cadre du projet . . 65
3.5.1 Schma en constellation pour ADELEM . . . . . . . . . . . . 65
3.5.2 Hirarchies du schma . . . . . . . . . . . . . . . . . . . . . . 66
3.5.3 Description du schma Prise_MCO et de ses dimensions . . . . 67
3.5.4 Description du schma Population et de ses dimensions . . . . 70
3.5.5 Description du schma Prise_SSR et de ses dimensions . . . . 71
3.6 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4 Systme daide la dcision mdicale : une exprimentation 75
4.1 Construction du schma . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.1.1 Schma en toile Adelem_MCO . . . . . . . . . . . . . . . . . . . 76
4.1.2 Matrialisation de lHypercube . . . . . . . . . . . . . . . . . 77
4.2 Vues matrialises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.2.1 Slection des vues matrialiser . . . . . . . . . . . . . . . . . 80
4.2.2 Algorithme propos pour la slection des vues matrialiser . 84
4.2.3 Gnration des vues matrialises . . . . . . . . . . . . . . . . 88
iii
4.3 Interface graphique pour la Gnration (semi-automatique) dIndica-
teurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.3.1 Architecture pour linterface graphique . . . . . . . . . . . . . 91
4.3.2 Fonctionnement de linterface . . . . . . . . . . . . . . . . . . 92
4.3.3 Types de requtes excuter . . . . . . . . . . . . . . . . . . . 94
4.3.4 Fonctionnement de linterface graphique . . . . . . . . . . . . 95
4.4 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5 Aspects temporels et versions de schmas dans les entrepts 101
5.1 Versions de schmas . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.1.1 Versions de schmas annuels dans un contexte mdical . . . . 102
5.1.2 Reprsentation bitemporelle des versions de schmas . . . . . 103
5.2 Les oprations primitives . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.2.1 Ensemble de primitives . . . . . . . . . . . . . . . . . . . . . . 105
5.2.2 Ensemble de restrictions . . . . . . . . . . . . . . . . . . . . . 105
5.3 Dnition formelle des primitives . . . . . . . . . . . . . . . . . . . . 107
5.3.1 Gestion de la relation (cube, dimension ou hirarchie) . . . . . 108
5.3.2 Gestion des versions . . . . . . . . . . . . . . . . . . . . . . . 115
5.4 Gestion temporelle des entrepts . . . . . . . . . . . . . . . . . . . . 116
5.4.1 Architecture simplie du projet . . . . . . . . . . . . . . . . . 117
5.4.2 Modle de versions de schmas bitemporels . . . . . . . . . . . 117
5.4.3 Gestionnaire dvolution de schmas . . . . . . . . . . . . . . 119
5.5 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
6 Conclusions et perspectives 125
6.1 Bilan du travail ralis . . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.1.1 Principales contributions . . . . . . . . . . . . . . . . . . . . . 125
6.1.2 Dnition dun modle multidimensionnel . . . . . . . . . . . 125
6.1.3 Algorithme pour la slection des vues matrialiser . . . . . . 126
6.1.4 Gnration (semi-automatique) des requtes . . . . . . . . . . 127
6.1.5 Versions de schmas bitemporels . . . . . . . . . . . . . . . . . 127
6.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
6.2.1 Extension du prototype . . . . . . . . . . . . . . . . . . . . . 128
6.2.2 Aspects spatiaux des donnes . . . . . . . . . . . . . . . . . . 129
6.2.3 Construction et rafrachissement de donnes . . . . . . . . . . 131
6.2.4 Grille de donnes . . . . . . . . . . . . . . . . . . . . . . . . . 132
A Description des sources de donnes 145
iv
Table des gures
1.1 Architecture gnrale dun systme dcisionnel . . . . . . . . . . . . . 3
1.2 Tous les tablissements au niveau national . . . . . . . . . . . . . . . 5
1.3 Gestion de lvolution du schma dans un entrept . . . . . . . . . . 9
2.1 Architecture dun entrept de donnes . . . . . . . . . . . . . . . . . 16
2.2 Exemple de modlisation en toile. . . . . . . . . . . . . . . . . . . . 20
2.3 Exemple de modlisation en ocon de neige. . . . . . . . . . . . . . . 21
2.4 Exemple de modlisation en constellation. . . . . . . . . . . . . . . . 22
2.5 Exemple de schma multidimensionnel. . . . . . . . . . . . . . . . . . 23
2.6 Exemple de lopration Jointure. . . . . . . . . . . . . . . . . . . . . . 25
2.7 Architecture ROLAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.8 Architecture MOLAP. . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.9 Architecture HOLAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.10 Espace des changements . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.11 Graphes de version un niveau . . . . . . . . . . . . . . . . . . . . . 45
2.12 Graphe de version deux niveaux . . . . . . . . . . . . . . . . . . . . 46
3.1 Architecture propose dun systme dcisionnel . . . . . . . . . . . . 50
3.2 Mtamodle Multidimensionnel . . . . . . . . . . . . . . . . . . . . . 52
3.3 Schma et une instance possible du Cube . . . . . . . . . . . . . . . . 56
3.4 Schma et une instance possible de la hirarchie H_Geo . . . . . . . 58
3.5 Schma en Constellation pour ADELEM . . . . . . . . . . . . . . . . 66
3.6 Hirarchies de la dimension x . . . . . . . . . . . . . . . . . . . . . . 67
3.7 Schma en ocon de neige Prise_MCO . . . . . . . . . . . . . . . . . . 68
3.8 Schma en ocon de neige Population . . . . . . . . . . . . . . . . . . 70
3.9 Schma en ocon de neige Prise_SSR . . . . . . . . . . . . . . . . . . 71
4.1 Schma en toile Adelem_MCO . . . . . . . . . . . . . . . . . . . . . . . 76
4.2 Hypercube avec le cot de calcul ( gauche) et le cot de stockage (
droite) de chaque noeud (vue) . . . . . . . . . . . . . . . . . . . . . . 79
4.3 Algorithme Greedy [HRU95] . . . . . . . . . . . . . . . . . . . . . . . 82
4.4 Ensemble ordonn des vues slectionnes . . . . . . . . . . . . . . . . 83
4.5 Algorithme propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.6 Ensemble ordonn des vues slectionnes . . . . . . . . . . . . . . . . 87
4.7 Architecture pour linterface graphique . . . . . . . . . . . . . . . . . 91
4.8 Cration dune dimension . . . . . . . . . . . . . . . . . . . . . . . . 93
v
vi
4.9 Structure de la dimension . . . . . . . . . . . . . . . . . . . . . . . . 94
4.10 Interface pour la gnration (semi-automatique) dindicateurs . . . . 96
4.11 Rsultat de lexcution de la requte Q4 . . . . . . . . . . . . . . . . 97
4.12 Fichier Requete.REL . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.1 Trois versions de schmas annuels. . . . . . . . . . . . . . . . . . . . . 102
5.2 Reprsentation bitemporelle des versions de schmas. . . . . . . . . . 103
5.3 Insertion du niveau District la Hirarchie H_Geo. . . . . . . . . . 113
5.4 Rsultat dliminer le niveau Departement la Hirarchie H_Geo. . . 114
5.5 Interaction des composants lintrieur de larchitecture. . . . . . . . 117
5.6 Modle de versions de schmas bitemporels. . . . . . . . . . . . . . . 118
5.7 Gestionnaire dvolution de schmas. . . . . . . . . . . . . . . . . . . 120
5.8 Gestion dvolution de schmas par niveau. . . . . . . . . . . . . . . . 120
6.1 Reprsentation du mode vecteur et rasteur . . . . . . . . . . . . . . . 131
6.2 Architecture des systmes pour lintgration de donnes . . . . . . . . 132
Liste des tableaux
2.1 Dirences entre SGBD et entrepts de donnes . . . . . . . . . . . . 18
2.2 Comparaison des systmes . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Ventes par magasin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4 Prix des produits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5 Ventes de produits par ville 1 . . . . . . . . . . . . . . . . . . . . . . 25
2.6 Ventes de produits par ville 2 . . . . . . . . . . . . . . . . . . . . . . 25
2.7 Ventes du Dpartement Isre . . . . . . . . . . . . . . . . . . . . . . . 25
2.8 Table de ventes du Magasin 1 . . . . . . . . . . . . . . . . . . . . . . 26
2.11 Exemple de relation bitemporelle . . . . . . . . . . . . . . . . . . . . 42
3.1 Description des sources de donnes . . . . . . . . . . . . . . . . . . . 61
3.2 Caractristiques des sources de donnes historiques . . . . . . . . . . 62
4.1 Liste de relations de base . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.2 Matrialisation complte de lhypercube . . . . . . . . . . . . . . . . 78
4.3 Application de lalgorithme Greedy aux donnes ADELEM . . . . . . 82
4.4 Application de notre algorithme aux donnes ADELEM . . . . . . . . 86
4.5 Ensemble minimal des vues matrialiser . . . . . . . . . . . . . . . 88
5.1 Primitives pour la gestion de relation . . . . . . . . . . . . . . . . . . 106
5.2 Primitives pour la gestion des versions . . . . . . . . . . . . . . . . . 106
A.1 Description des variables du chier RSA . . . . . . . . . . . . . . . . 148
A.2 Description de variables du chier RSA . . . . . . . . . . . . . . . . . 149
A.3 Description de variables du chier FINESS . . . . . . . . . . . . . . . 151
A.4 Description de variables du chier FINESS . . . . . . . . . . . . . . . 152
vii
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 lin-
tgration 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 dinterroga-
tion, 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 multidimension-
nel, un algorithme pour la slection optimale des vues matrialiser et lutilisation
des versions de schmas bitemporels pour la gestion des aspects temporels des entre-
pts. 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
2 Introduction
1.1 Les entrepts de donnes pour laide la dci-
sion
La dnition classique dun entrept donne par [IH94] :
"Un Entrept de Donnes est une collection de donnes orientes su-
jet, 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 correspon-
dance 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 utili-
sateurs 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 organi-
ser lensemble de donnes lintrieur de lentrept. Pour cela, nous devons dabord
structurer ces informations en considrant leur granularit. Ceci nous permet dabou-
tir la conception dun schma multidimensionnel qui permet de rpondre aux be-
soins 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 int-
resse et de la prparation et de la transformation (nettoyage, ltrage,...) des donnes.
1.2 Le projet ADELEM : Aide la Dcision Logistique et Mdicale 3
E
X
T
R
A
C
T
I
O
N
Entrept
de
donnes
Sources de donnes
O
R
G
A
N
I
S
A
T
I
O
N
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 respon-
sable 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 di-
rents 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 Logis-
tique et Mdicale
Cette thse a eu pour cadre le projet ADELEM
1
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
4 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 four-
nit 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 sup-
port pour les bases de donnes et les entrepts.
Objectif du projet :
La rpartition de lore de soins (nombre de lits par spcialit, plateaux tech-
niques) doit sadapter rgulirement lvolution de la demande (volution des pa-
thologies ncessitant une prise en charge hospitalire, de la structure dge et de lim-
plantation gographique de la population), et de lore de soins (volution des tech-
niques 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 sys-
tme 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 don-
nes 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 com-
paraison 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 5
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 consomma-
tion 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 hos-
pitalier. Pour ce dernier, la gure 1.2 montre la carte obtenue.
Fig. 1.2 Tous les tablissements au niveau national
6 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 savoir-
faire au problme de la gestion de donnes mdicales qui constituent un cadre appli-
catif particulirement intressant. En eet, ces donnes se trouvent rparties dans
plusieurs sources quil faut, dans un premier temps, fdrer pour constituer un en-
trept 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 7
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 ht-
rognes.
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 repr-
sentent 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] pro-
pose 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 lhisto-
rique 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 enregis-
tres. 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 compa-
gnie dassurances a en gnral des domaines dactivit trs direncis. Il y a par
exemple : les risques habitation, les risques automobiles, les risques objets person-
nels, la responsabilit civile, ..., o chaque domaine est reprsent par des attributs
particuliers. Nous identions deux dimensions : une pour le bien assur et une autre
8 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 par-
ticularises 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, men-
suelle,...
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 en-
trept. 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 princi-
palement au cot de stockage lev.
Pas de matrialisation : Dans ce cas, nous navons pas besoin de stockage suppl-
mentaire. Cependant, pour rpondre chaque requte, nous devons chercher lin-
formation 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 dter-
miner 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 tra-
vaux 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 possi-
bilit 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 ma-
trialisation 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 9
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 S
1
reprsente un schma et V
1
lensemble de vues sur S
1
. Si nous
avons une nouvelle version de schma S
2
partir de S
1
, le problme est la dnition
de la nouvelle version V
2
qui soit cohrente avec S
2
[Ber03].
Lvolution dun schma a des consquences sur lapplication charge de lex-
traction 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 mainte-
nance.
La gure 1.3 montre les adaptations ncessaires aprs quune volution du schma
a eu lieu dans un entrept de donnes.
E
X
T
R
A
C
T
I
O
N
Entrept
de
donnes
Sources de donnes
O
R
G
A
N
I
S
A
T
I
O
N
I
N
T
E
R
R
O
G
A
T
I
O
N Outils
Adaptation de
lapplication
dextraction
Adaptation des
agrgats
Adaptation de
lapplication
danalyse
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 exis-
tantes 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 ins-
tances, ainsi quune dnition dune base de donnes multidimensionnelle et de son
instance. Ceci nous a permis daboutir la conception dun modle multidimension-
nel 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 11
1.4.2 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 in-
dicateurs
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 gra-
phique, 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 extension-
nelles. 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 plu-
sieurs problmes. Le principal, notre connaissance, est lexplosion des versions,
ainsi, nous devons tablir un mcanisme pour contrler cette explosion. Notre pro-
position considre :
- Un oprateur appel SetVersion qui permet dappliquer un ensemble de chan-
gements sur une version et de gnrer une nouvelle version.
12 Introduction
- Un ensemble de 19 primitives ncessaires pour la gestion des cubes, des dimen-
sions et des hirarchies.
- Un ensemble de 5 primitives qui agissent sur les versions de schmas.
- Un gestionnaire dvolution responsable de la manipulation des direntes ver-
sions 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 compo-
sants, 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 ges-
tion 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 multidimension-
nel 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. En-
suite, 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 vi-
sualisation 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 13
du gestionnaire dvolution par niveau.
Finalement, le chapitre 6 prsente nos conclusions et quelques perspectives.
14 Introduction
Chapitre 2
Entrepts de donnes
multidimensionnelles et aspects
temporels
Les entrepts de donnes sont apparus vers les annes 1990 en rponse la n-
cessit 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 appli-
cations (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 pro-
cessus dextraction des donnes permet dalimenter priodiquement ce SGBD. Nan-
moins 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.
Donnes externes
Donnes de production
(SGBD, systmes lgus)
O
U
T
I
L
S
Donnes anciennes
archives
Donnes de dtail
Donnes lgrement
rsumes
Donnes fortement
rsumes
Mtadonnes
Entrept de
donnes
Fig. 2.1 Architecture dun entrept de donnes
a) Les sources : Les donnes de lentrept sont extraites de diverses sources sou-
vent 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 lentre-
prise.
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 entre-
pt, 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 pr-
visionnelles. 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 r-
sumes.
Les mtadonnes : Ce sont des donnes essentielles pour parvenir une ex-
ploitation ecace du contenu dun entrept. Elles reprsentent des informations
ncessaires laccs et lexploitation des donnes dans lentrept comme : la sman-
tique (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 multidimension-
nelles), 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 len-
vironnement 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 transac-
tionnels. Par contre, les entrepts de donnes ont t conus pour laide la prise
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].
SGBD Entrepts de donnes
Objectifs Gestion et production Consultation et analyse
Utilisateurs Gestionnaires de production Dcideurs, analystes
Taille de la base Plusieurs gigaoctets Plusieurs teraoctets
Organisation Par traitement Par mtier
des donnes
Type de donnes Donnes de gestion Donnes danalyse
(courantes) (rsumes, historises)
Requtes Simples, prdtermines, Complexes, spciques,
donnes dtailles agrgations et group by
Transactions Courtes et nombreuses, Longues, peu nombreuses
temps rel
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 uti-
lisant des processus transactionnels en ligne [Cod93].
Paralllement lexploitation de linformation contenue dans ces systmes opra-
tionnels, les dirigeants des entreprises ont besoin davoir une vision globale concer-
nant 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 dci-
sionnels 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 di-
rents schmas, nous commenons par quelques concepts de base.
2.2 Modlisation multidimensionnelle 19
S. Transactionnel S. Dcisionnel
Donnes Exhaustives Rsumes
Courantes Historiques
Dynamiques Statiques
Orientes applications Orientes sujets (danalyse)
Utilisateurs Nombreux Peu nombreux
Varis (employs, Uniquement les dcideurs
directeurs,...)
Concurrents Non concurrents
Mises jour et Interrogations
interrogations
Requtes prdnies Requtes imprvisibles et complexes
Rponses immdiates Rponses moins rapides
Accs peu Accs de nombreuses informations
dinformation
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 ma-
nire 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 di-
mension. 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 pro-
duits vendus par magasin". Les mesures doivent tre valorises de manire continue
[AGS97, CT97, Inm92, Inm95, Kim96, KR03, KS95] et elles peuvent tre addi-
tives (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 pa-
ramtres (ou attributs) qui servent enregistrer les descriptions textuelles. Nous
pouvons utiliser les paramtres textuels comme source des restrictions dans une re-
qute. 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_n" 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 :
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 rela-
tion 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.
Temps
Cl_T
Jour
Mois
Anne
Cl_P
Cl_T
Cl_M
Quantit
Ventes
Produit
Cl_P
Description
Type
Catgorie
Magasin
Cl_M
Raison_soc
Adresse
Commune
Dpartement
Rgion
Pays
Fig. 2.2 Exemple de modlisation en toile.
2.2 Modlisation multidimensionnelle 21
2.2.1.2 Le schma en ocon de neige (Snowake)
Il drive du schma prcdent avec une relation centrale et autour delle les di-
rentes dimensions, qui sont clates ou dcomposes en sous hirarchies. Lavantage
du schma en ocon de neige est de formaliser une hirarchie au sein dune dimen-
sion, ce qui peut faciliter lanalyse. Un autre avantage est reprsent par la nor-
malisation des dimensions, car nous rduisons leur taille. Nanmoins dans [Kim96],
lauteur dmontre que cest une perte de temps de normaliser les relations des di-
mensions 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
Cl_P
Description
Type
Catgorie
Cl_P
Cl_T
Cl_M
Quantit
Ventes
Temps
Cl_T
Jour
Mois
T_Mois
Mois
Anne
Magasin
Cl_M
Raison_soc
Adresse
Commune
Dpartement
M_Rgion
Rgion
Pays
M_Dpartement
Dpartement
Rgion
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.
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 re-
lation gre les dirents produits achets aux fournisseurs pendant un certain temps.
Produit
Cl_P
Description
Type
Catgorie
Cl_P
Cl_M
Cl_T
Quantit
Ventes
Temps
Cl_T
Jour
Mois
Anne
Achats
Cl_P
Cl_F
Cl_T
Quantit
Magasin
Cl_M
Raison_soc
Adresse
Commune
Dpartement
Rgion
Pays
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. Ega-
lement, 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 me-
sures. 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.
2.3 Manipulation des donnes multidimensionnelles 23
En reprenant une partie du schma en toile de la g. 2.2, nous pouvons construire
le schma multidimensionnel suivant.
SUM
03/01/2000
02/01/2000
01/01/2000
SUM
Annecy
Grenoble
Lyon
TV R CS CP
S
U
M
All
Temps
Magasin
Produit
Jour
mois
anne
Temps
Ville
Dpartement
Rgion
Pays
Magasin
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 ma-
gasin dAnnecy pendant le 1er janvier 2000.
2.3 Manipulation des donnes multidimensionnelles
Pour visualiser les donnes multidimensionnelles, nous pouvons utiliser la repr-
sentation 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 si-
multanment 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 multidimen-
sionnelles, 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 condi-
tions dappartenance. Nous pouvons avoir une slection avec des conditions soit sur
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) Mag1 Mag2 Mag3
Tlviseur 100 250
Radio 50 200
Camscope 50 100
Camera photo 100 100
Tab. 2.3 Ventes par magasin
Produit Prix (01/01/2000)
Tlviseur 1
Radio 2
Camscope 3
Camera photo 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.
2.3 Manipulation des donnes multidimensionnelles 25
Fig. 2.6 Exemple de lopration Jointure.
Ville Produit Mag1 Mag2 Mag3
Grenoble Tlviseur 50 100
Grenoble Radio 50 100
Grenoble Camscope 100
Grenoble Camera photo 50 100
Tab. 2.5 Ventes de produits par ville 1
Fontaine Tlviseur 100 100 50
Fontaine Radio 50 100
Fontaine Camscope 100 50 100
Fontaine Camera photo 100 100
Tab. 2.6 Ventes de produits par ville 2
Grenoble Tlviseur 50 100
Grenoble Radio 50 100
Grenoble Camscope 100
Grenoble Camera photo 50 100
Fontaine Tlviseur 100 100 50
Fontaine Radio 50 100
Fontaine Camscope 100 50 100
Fontaine Camera photo 100 100
Tab. 2.7 Ventes du Dpartement Isre
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 01/01/2000 02/01/2000 03/01/2000
Tlviseur 100 100 50
Radio 50 200 100
Camscope 100
Camera photo 100 100 100
Tab. 2.8 Table de ventes du Magasin 1
Ventes Magasin 2 01/01/2000 02/01/2000 03/01/2000
Tlviseur 100 150
Radio 200 200 100
Camescope 50 100
Ventes Magasin 3 01/01/2000 02/01/2000 03/01/2000
Tlviseur 250 100 50
Radio 100
Camscope 100 50 50
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 re-
prsenter 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 dinfor-
mation 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) per-
met de rsumer la dnition des produits OLAP. Cette dnition fut utilise pour
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 re-
qutes.
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 hirar-
chies.
Informations : Lensemble des donnes et les informations ncessaires pour un pro-
duit 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. Toute-
fois, le modle relationnel requiert des extensions pour supporter les requtes dana-
lyses multidimensionnelles du niveau dapplication. Le moteur ROLAP traduit dy-
namiquement le modle logique de donnes multidimensionnel M en modle de sto-
ckage 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 multidimension-
nelle 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.
Base de donnes
relationnelle
Serveur ROLAP
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 perfor-
mance.
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 (foca-
lise sur une base de donnes centralise).
Real Application Clusters : Il permet de dsigner certains processeurs comme pro-
cesseurs OLAP et dautres comme processeurs de requtes.
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 logi-
ciel).
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 limplanta-
tion des index additionnels et des statistiques complmentaires.
Microsoft DTS (Data Transformation Services) : Loutil ETL intgr dans Mi-
crosoft SQL Server.
2.4.2 MOLAP (Multidimensional OLAP)
Les systmes multidimensionnels OLAP utilisent une base de donnes multidi-
mensionnelle 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
Client OLAP
Base de donnes
multidimensionnelle
(hypercube)
Fig. 2.8 Architecture MOLAP.
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 cer-
tains 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 impor-
tants 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 MO-
LAP sont trs puissantes et exibles en termes du processus OLAP, tandis que,
dun autre ct, le modle physique correspond plus troitement au modle multidi-
mensionnel. 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 :
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 don-
nes 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 ou-
til 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 des-
cription 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 don-
nes 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
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 rela-
tionnel, pour assurer des performances optimales.
Actuellement, la plupart des systmes commerciaux utilisent une approche hy-
bride. Cette approche permet de manipuler des informations de lentrept de don-
nes 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
Client OLAP
Base de donnes
multidimensionnelle
(hypercube)
Base de donnes
relationnelle
Vue
multidimensionnelle
Fig. 2.9 Architecture HOLAP.
Les produits commerciaux existants sont :
DB2 OLAP Server : Il permet de calculer, de consolider et daccser linforma-
tion 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 multidi-
mensionnel. Il gre un ensemble dindicateurs n dimensions, dont les valeurs sont
stockes ou calcules dynamiquement [ORA96].
Le stockage des donnes peut se faire dans une base de donnes multidimension-
nelle 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 don-
nes. 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 dve-
loppement 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 trans-
mises 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 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.
2.5.2 SIRIUS Supporting the Incremental Refreshment of Informa-
tion warehouses
Ce projet dvelopp lUniversit de Zurich, est un systme dentrept de don-
nes qui a pour objectif dtudier des techniques permettant le rafrachissement
incrmental de lentrept en rduisant les temps de mise jour. Le schma de len-
trept est dni sous la forme dun schma global UML.
Chaque source de donnes est munie dun adaptateur et dun moniteur. Le mo-
niteur 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 dintergi-
ciel 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.
Les rsultats comportent des mta-modles formels de donnes destins la des-
cription 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 mul-
tidimensionnelles 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 opti-
mise 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 repr-
sentent 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 len-
trept.
- 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 concep-
tion 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 concep-
tualisation, 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 don-
nes 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 r-
soudre 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
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, dvo-
lution 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 modication 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 modica-
tion du schma de la base sans perdre les donnes existantes.
Les versions de schma permettent laccs toutes les donnes, de faon rtros-
pective 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
immuable
1
, 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 dabor-
der 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 sup-
porter les versions, ainsi que la modication du langage de requtes pour fournir
un mcanisme dcriture de requtes une base de donnes supportant des ver-
sions. 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 deltas
2
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 : as-
cendante 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
Une version immuable ne permet pas de changements.
2
Les deltas reprsentent les dirences entre versions.
2.6.1.2 Modle objets
Dans ce paradigme, deux types de changements sont signicatifs : les change-
ments 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 utilisa-
teurs 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 congu-
ration 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 SV
j
partir de SV
i
, les classes existantes peuvent tre
modies ou eaces et des classes nouvelles peuvent tre cres pour SV
j
. Si une
classe C est modie, on peut dire que SV
i
et SV
j
contiennent direntes versions
de la class C, dnote par SV
i
.C et SV
j
.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 V
j
de la classe C est drive de la
version V
i
, 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 ap-
plications 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 Bases de donnes temporelles
Les bases de donnes temporelles permettent de reprsenter et de manipuler lhis-
toire 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 s-
mantique 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 rela-
tions. 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 manipula-
tion de la dimension temps dans les versions de schma correspond soit la ver-
sion 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 modi-
cations 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 mani-
pulation 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 sch-
mas 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 mainte-
nue, car aucune version de schma nest abandonne.
Le tableau 2.11 dcrit un exemple de relation bitemporelle en TSQL2 [Sno95].
Nom Salaire Temps de transaction Temps de validit
SERNA 1000 1-07-2000 - 31-12-2000 1-07-2000 - 31-12-2001
SERNA 1500 1-01-2002 - 31-01-2002 1-01-2002 - 31-12-2002
SERNA 1600 1-01-2003 - UC
3
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 en-
trepts, 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 in-
frastructure adaptable pour lvolution des entrepts de donnes. Il prsente un
ensemble doprateurs dvolution de schmas multidimensionnels, ainsi quun lan-
gage 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.
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 essen-
tielles la gestion et la manipulation des donnes historiques, aussi bien que des don-
nes 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 dis-
tinguer la rcupration et la mise jour des donnes. Pour rpondre ce be-
soin, 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 com-
munes 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 v
1
et v
2
, reprsente lensemble de dif-
frences entre elles, cest dire :
(v
1
, v
2
) = (v
1
- v
2
) U (v
2
- v
1
)
O le symbole correspond la dnition du delta.
Un delta direct reprsente une squence doprations de changements op
1
, ...
,op
m
. Quand ces changements sont appliqus sur une version v
1
, ils produisent une
nouvelle version v
2
.
(v
1
,v
2
) = op
1
, ... ,op
m
Cest--dire, v
1
gnre v
2
: v
1
v
2
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 co-
existent 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 iden-
ticateur (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
versions
c1 c2 c3 c4 c5 c6
v1
v2
v3
v4
a) Reprsentation en matrice
b
c1
c2
c3
v1
v3
c6
v2
c4
c5
c3
b) Graphe de version avec des
changements explicites
c4
v4
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 c
1
, c
2
, c
3
et c
4
construisent la version v
2
. 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
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 corres-
pondent 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 en-
semble de versions qui sont connectes par leurs relations successeurs. Ce type de
graphes reprsente lhistorique de lvolution dun lment. Par exemple, si la ver-
sion v
2
est un successeur de v
1
, cela signie que la version v
2
a t drive partir
de v
1
. La gure 2.11 reprsente dirents types de graphes de version.
v1
v2
v3
v1
v2
v3
v4
v1
v2 v3
v4
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 pou-
vons 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. Nan-
moins, les branches ne sont pas relies et elles continuent dexister. Le systme
ClearCase [CW98, EJWG03] utilise cette approche.
v1
v2
v3
v1
v2
v3
v4
v1
v2
v3
v4
v1
v2
b4
b2
b1
b3
branche
successeur
descendants
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 re-
construction 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 sch-
mas), 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 com-
bins. 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 extension-
nelles. 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 dob-
jets, 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 vo-
lu qui consiste en une collection de versions de schmas dnies sur un ensemble
de noms de classes et dattributs.
2.7 Bilan 47
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 len-
semble de changements possibles excuter sur le modle. Par exemple, dans le
contexte des bases de donnes orientes sujets [Lau96, GM99], cette liste a t grou-
pe en : changements de schma sur un noeud et changements de schma sur des
artes. La premire catgorie groupe les oprations agissant sur les lments sup-
ports 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 apparte-
nant 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 sys-
tmes daide la dcision.
En utilisant larchitecture dun entrept de donnes, nous avons expliqu les dif-
frents 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 don-
nes 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 sto-
ckage des donnes. Les systmes MOLAP doivent grer le problme de donnes
clairsemes, quand seulement un nombre rduit des cellules dun cube contiennent
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 sys-
tme 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 MO-
LAP. Finalement, nous avons dcrit quelques produits commerciaux existants.
En ce qui concerne les projets de recherche dans le domaine des entrepts de don-
nes, nous avons dcrit succinctement WHIPS, SIRIUS, DWQ et EVOLUTION. Les
deux premiers sont centrs sur des problmatiques lies lextraction et la main-
tenance 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 uti-
liser.
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 len-
semble 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 len-
trept. 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 entre-
pt 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 distinc-
tion 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, sa-
voir, la description de la conception dun modle multidimensionnel. Nous propo-
sons dabord une architecture pour un systme dcisionnel. Cette architecture com-
prend trois composants qui traitent les deux derniers processus (la structuration-
organisation et linterrogation). Dans une deuxime partie, nous dnissons un m-
tamodle 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 di-
mension 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 (Semi-
automatique) dIndicateurs. Nous plaons ce composant lintrieur du proces-
sus 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 com-
posants :
R
s
u
l
t
a
t
Gestionnaire de Requtes
Gestionnaire dEvolution
Interface graphique
Donnes rsumes
et de dtail
courantes
Entrept de
donnes
Sources
de
donnes
Fig. 3.1 Architecture propose dun systme dcisionnel
3.1.1 Interface graphique pour la Gnration (Semi - auto-
matique) 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 don-
nes 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. Len-
trept 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 se-
mestrielles par rgion des dix dernires annes" sont fortement rsumes.
Sources : Elles rassemblent lensemble de sources internes, par exemple, les di-
rents 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 Gestionnaire dEvolution
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 multidimen-
sionnel (cf. Section 2.3) qui se compose des mtaclasses
1
. La gure 3.2 montre les
1
Une mtaclasse est une classe qui modlise des classes [PCTM02, PCTM03]. Nous avons utilis
UML (Unied Modeling Language) pour la spcication du mtamodle multidimensionnel.
Mtaclasses Cube, Dimension et Hirarchie qui constituent notre MtaSchma.
<<Mtaclasse>>
MtaSchma
+/cube: Cube
+/dimension: Dimension
<<Mtaclasse>>
Cube
+Strings[]: Mesure_nom
+Strings[]: Type
+Strings[]: Cl
+/dimension: Dimension
<<Mtaclasse>>
Dimension
+Strings[]: Attribut_nom
+Strings[]: Type
+Strings[]: Cl_P
+Strings[]: Cl_E
+/hirarchie: Hirarchie
{La Cl_P est
contenu ou est
gale lensemble
Attributs_noms}
<<Mtaclasse>>
Hirarchie
+Strings[]: Attribut_nom
+Strings[]: Type
+Strings[]: Cl_P
+Strings[]: Cl_E
{La Cl_P dune
mtaclasse
Hirarchie ne
peut pas relier
la mtaclasse
Cube associe
sa mtaclasse
Dimension
(granularit)}
*
0..1
{La Cl de la mtaclasse
Cube est compose de
lensemble des Cl_P de ses
mtaclasses Dimensions}
*
1..
*
1..
* 0..
*
1..
1
*
1..
*
1..
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 com-
posites ; ou
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 r
1
(R
1
) et r
2
(R
2
) deux classes avec les cls primaires C
1
et C
2
. Le sous-ensemble
de R
2
est une cl externe qui fait rfrence C
1
de r
1
, si pour chaque t
2
de r
2
existe une n-uplet t
1
de r
1
tel que t
1
[C
1
] = t
2
[].
Pour dcrire des contraintes additionnelles qui ne sont pas exprimes directe-
ment 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 (granu-
larit)}.
3.2.3 Description des Mtaclasses
Nous dcrivons les mtaclasses qui composent le mtamodle multidimensionnel :
Mtaclasse MtaSchma : La mtaclasse MtaSchma est compose des mta-
classes Cube et Dimension. Elle reprsente un schma multidimensionnel compos
des classes Cube et Dimension.
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 :
Mesure_nom : string, Type : string ) reprsentent le(s) sujet(s) danalyse.
Cl : string, Type : string ) reprsentent lensemble des mtaclasses Dimen-
sions (perspectives danalyse) qui appartiennent la mtaclasse Cube.
Mtaclasse Dimension : Cette mtaclasse modlise des classes de type Dimen-
sion. Elle reprsente une perspective danalyse ou un axe de localisation dune cellule
dun Cube. Une mtaclasse Dimension est compose densembles de couples de
type :
Attribut_nom : string, Type : string ) ensemble dattributs textuels
lintrieur de la classe Dimension.
Cl_P : string, Type : string ) identicateur unique pour la classe Dimen-
sion.
Cl_E : string, Type : string ) 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 com-
pose des ensembles de couples de type :
Attribut_nom : string, Type : string ) reprsentent des paramtres tex-
tuels dans la classe Hirarchie.
Cl_P : string, Type : string ) identicateur unique pour la classe Hirar-
chie.
Cl_E : string, Type : string ) reprsentent des liens entre les classes de
type Hirarchie.
3.2.4 Dnition dun modle multidimensionnel
Un modle multidimensionnel est une instance de la mtaclasse MtaSchma.
Nous lappelons classe ModleMultidimensionnel (MM). Nous utilisons les des-
criptions 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
lvolution dun systme multidimensionnel. Dans [GM02], lauteur propose un mo-
dle formel des versions de schmas temporelles pour des bases de donnes objets.
Nous faisons la dirence entre une dimension et une hirarchie. Ainsi, notre mo-
dle 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 :
DOM = dom(char)
dom(integer)
dom(oat)
dom(decimal)
dom(date)
{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 {a
1
, ..., a
n
} tel que
i=1,...n
a
i
DOM. De mme pour chaque dimension dD, nous associons un ensemble
de valeurs {b
1
, ..., b
n
} tel que
i=1,...n
b
i
DOM. Finalement, pour chaque niveau lL,
nous associons un ensemble de valeurs {f
1
, ..., f
n
} tel que
i=1,...n
f
i
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.
Dnition 3.1 : Schma de base de donnes et dinstance multidimen-
sionnelle.
Le schma dune base de donnes multidimensionnelle est un n-uplet SM = (C
s
,
D
s
, H
s
, R), o C
s
est un ensemble de schmas de cubes, D
s
est un ensemble de
schmas de dimensions, H
s
est un ensemble de schmas de hirarchies et R est un
ensemble de contraintes. 2
2
Lensemble E(A) est lensemble des parties de A. E(A) = {X[X A}.
Linstance dune base multidimensionnelle est un n-uplet IM = (C
i
, D
i
, H
i
, R
i
),
o C
i
est un ensemble dinstances de cubes tel que, pour chaque instance c
i
C
i
, il
existe un schma c
s
C
s
avec c
i
conforme c
s
. D
i
est un ensemble dinstances de
dimensions tel que, pour chaque instance d
i
D
i
, il existe un schma d
s
D
s
avec d
i
conforme d
s
. H
i
est un ensemble dinstances de hirarchies tel que, pour chaque
instance h
i
H
i
, il existe un schma h
s
H
s
avec h
i
conforme h
s
. Finalement, R
i
est un ensemble dinstances de contraintes tel que chaque instance r
i
R
i
. 2
Dnition 3.2 : Schma et instance du cube.
Un schma de cube est un n-uplet C
s
= (c
n
, M, D), o c
n
C est le nom du cube,
M est un ensemble de mesures et D est un ensemble de dimensions. 2
Une instance de cube est un ensemble de cellules. Une cellule est un n-uplet I
c
=
(c
n
, {v
1
,...,v
k
}, {d}), o c
n
est le nom du cube, {v
1
,...,v
k
} est lensemble de mesures
tel que
i=1,...n
v
i
measuredom(m
i
) avec m
i
M et dD est lensemble de dimen-
sions. 2
Par exemple, la gure 3.3 reprsente le schma et linstance du cube Ventes.
SUM
03/01/2000
02/01/2000
01/01/2000
SUM
Annecy
Grenoble
Lyon
TV R CS CP
S
U
M
All
Temps
Magasin
Produit
Schma du cube Ventes
Quantit
Instance
Temps
Magasin
Produit
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.
Dnition 3.3 : Schma et instance de dimension.
Un schma de dimension est un n-uplet D
s
= (d
n
, P, H), o d
n
D est le nom de
la dimension, P est lensemble de proprits de la dimension d
n
et H est lensemble
de hirarchies. 2
Une instance de dimension est un n-uplet I
d
= (d
n
, {(v
1
,...,v
i
)}, {h}), o d
n
D
est le nom de la dimension, (v
1
,...,v
i
) est un ensemble de proprits tel que
j=1,...n
v
j
propertydom(p
j
) avec p
j
P. Enn, hH est lensemble de hirarchies qui appar-
tiennent d
n
. 2
Par exemple, le schma de la dimension Magasin est dni de la manire suivante :
d
n
= Magasin
{p
1
,...p
i
} = {Cle_Magasin, Libelle_Magasin }
h
n
= 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 ni-
veaux. Chaque noeud du graphe contient un niveau et un arc entre deux noeuds
reprsente une association entre les niveaux contenus par les noeuds. Nous suppo-
sons 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 consi-
drer 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 dimen-
sion 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.
Dnition 3.4 : Schma et instance de hirarchie.
Un schma de hirarchie est un n-uplet H
s
= (h
n
, L, ), o h
n
H est le nom de la
hirarchie, L est lensemble de niveaux lintrieur de la hirarchie h
n
et le symbole
est une relation de dpendance entre les niveaux telle que sa fermeture transitive
et rexive _* reprsente un ordre partiel dans L. Il existe un seul niveau l
tel que
(i) si l,=,
lL
l
_* l
lL
l _* et (ii) si l=, l
_* . Un niveau l
j
L
est un niveau immdiatement suprieur (relation de dpendance) de l
i
L si l
i
l
j
. 2
Une instance de hirarchie organise les proprits participant aux hirarchies
dagrgation. Pour chaque arc dans un schma de dimension, il existe une fonc-
tion de RUP (rollup, cf. Dnition dinstance en-dessous) associe.
Une instance de hirarchie est un n-uplet I
h
= (
l
i
L
levelset(l
i
), RUP), o RUP
est un ensemble de fonctions rup
l
j
l
i
tel que (i) (l
1
, l
2
) L tels que l
1
l
2
, il existe
une fonction rup
l
2
l
1
: levelset(l
1
) levelset(l
2
) et (ii) (l
1
, l
2
, l
3
) L tels que l
1

l
2
et l
2
l
3
, ran(rup
l
2
l
1
) dom(rup
l
3
l
2
). 2
Par exemple, dans la gure 3.4, la partie gauche prsente le schma de la hi-
rarchie H_Geo. Il est dni de la manire suivante : h
n
est le nom de la hirarchie
H_Geo, lensemble de proprits (niveaux) lintrieur de la hirarchie est {Com-
mune, Dpartement, Rgion, } et la relation est reprsente par {(Commune,
Dpartement), (Dpartement, Rgion), (Rgion, )}.
Commune
Departement
Region
T
Lyon Grenoble Annecy
Isre
. . .
Rhne Alpes . . .
t
Schma
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 rup
Departement
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, ef-
fectu 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 lta-
blissement 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
- 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
Fichier FINESS (Fichier National des tablissements Sanitaires et So-
ciaux) Recense les structures sanitaires et sociales au niveau national (5079 ta-
blissements pour la France Mtropolitaine) [SMS04].
- Propritaire : Ministre Charg des Aaires Sanitaires et Sociales
- Type du chier : Texte (ASCII xe) au Excel
- Anne : 2000
- Mise jour : annuelle
- Taille : 2.24 Mo
Fichier CIM10 (Classication 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.
3.3 Analyse des donnes dune application mdicale 61
- Propritaire : INSEE
- Type du chier : BDF
- Anne : 1999
- Mode dobtention : achat
- Taille : 50.8 Mo (chier avec tranches dge dhommes et de femmes par com-
mune)
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 Type de chier Mode Taille Anne Mise jour
dobtention
RSA ARH Texte (ASCII xe) Gratuit 11 Go 2000 Annuelle
ou Access
RHA ARH Texte (ASCII xe) Gratuit 3 Go 2000 Annuelle
ou Access
FINESS MCASS Texte (ASCII xe) Gratuit 2.24 Mo 2000 Annuelle
ou Access
CIM10 OMS Excel - 1.34 Mo 1995 -
RP90/99 INSEE DBF Achat (625,04) 50.8 Mo 1999 Tous les 9 ans
3
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 re-
prenons 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 (R-
sums 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 x au dbut de lanne 2004 pour
obtenir les premiers rsultats la n 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.
Source Taille Optimisation Rafrachissement Requtes Agrgats Evolution
du stockage complexes du schma
RSA 110 Go Oui Annuel Oui Oui Oui
RHA 30 Go Oui Annuel Oui Oui Oui
FINESS 22.4 Mo Non Annuel Non Non Oui
CIM10 13.4 Mo Non - Non Non Oui
RP90/99 508 Mo Oui Annuel
4
Non Oui Oui
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 rper-
cussions 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 Classication 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 in-
dicateurs 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 corres-
pondent 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 GRE-
NOBLE" ainsi que la valeur "01-01-2000" pour lattribut Jour de la dimension Temps.
3.4 Classication des indicateurs du projet 63
3.4.1 Indicateurs dore (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 s-
jour en faisant apparatre leur capacit en nombre de lits MCO (Mdecine-Chirurgie-
Obsttrie).
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 ux
(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 ca-
tgories 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 daccouche-
ments 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).
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 indivi-
dus 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 pro-
crer 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 ux 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 mater-
nits (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 ux (tem-
porels)
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 ux : 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 65
7 = transfert normal, le dpart vers une autre entit juridique.
8 = domicile, le patient rentre chez lui.
9 = dcs, le patient est dcd dans lunit mdicale.
0 = 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 informa-
tions 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 dcri-
vons notre schma en constellation de la manire suivante :
Base de donnes multidimensionnelle :
Une base de donnes multidimensionnelle est un n-uplet SM = (C
s
, D
s
, H
s
, R), o
C
s
= {Prise_MCO, Prise_SSR, Population}
D
s
= {Etablissements, CIM10, Temps, Zone_geo, Age, Mode_sortie, Poids_naissance,
RP99, Semaine_debut, Semaine_n}
R = {C_Cube, C_Dimension, C_Hirarchie}
Fig. 3.5 Schma en Constellation pour ADELEM
contrainte :
C_Cube = le component Cl_P est compos de lensemble des Cl_P du com-
ponent /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 gra-
nularit.
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)

x
A reprsentant lanne.
Dimension Etablissement et Zone_geo
Rn
R1
(Rgion)
X
P
(Pays)
X
Dn D1
(Dpartement)
X
Cn C1
(Commune)
X
Dimension Temps
X
(Saison)
H A P
A
(Anne)
X
(Mois)
12 7 6 11
10
9 8 5 4 3 2 1
X
...
...
...
E
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 :
N
= F(x
, y, z ) =
x{x
}
f (x, y, z )
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 pre-
nons 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 esti-
me pour la relation Prise_MCO est environ 15 18 millions denregistrements par
anne.
s
= (c
n
, M, D), o
Fig. 3.7 Schma en ocon de neige Prise_MCO
c
n
= Prise_MCO
M = {CompteDuree_sejour, SommeDuree_sejour}
D = {CIM10, Etablissement, Temps, Zone_geo, Poids_naissance,
Age, Mode_sortie}
s
= (d
n
, P, H), o
d
n
= CIM10
P = {Cle_Maladie, Libelle_maladie}
H = {}
d
n
= 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 autori-
ss 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.
d
n
= Temps
P = {Cle_Temps, Mois, Saison, Annee}
H = {H_Temps}
Saison : Type char, en utilisant le code comme suit :
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.
d
n
= Zone_geo
P = {Cle_Zone, Libelle_commune, Departement, Region, Pays}
H = {H_Geo}
d
n
= Poids_naissance
P = {Cle_Poids, Libelle_poids}
H = {}
Dans cette relation nous avons pour le poids la naissance les intervalles suivants :
1 <1500g
2 >=1500g et <2000g
3 >=2000g et <2500g
4 >=2500g et <3000g
5 >=3000g et <3500g
6 >3500g
d
n
= Age
P = {Cle_Age}
H = {}
d
n
= Mode_sortie
P = {Cle_Mode, Libelle_mode}
H = {}
s
= (h
n
, L, ), o
h
n
= {H_Geo}
L = {Commune, Dpartement, Rgion, }
= {(Commune, Dpartement), (Dpartement, Rgion), (Rgion, )}
h
n
= {H_Temps}
L = {Mois, Saison, }
= {(Mois, Saison), (Saison, )}
3.5.4 Description du schma Population et de ses dimensions
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 agr-
ger 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
s
= (c
n
, M, D), o
c
n
= Population
M = {CompteFem_proc}
D = {Zone_geo, RP99}
s
= (d
n
, P, H), o
d
n
= Zone_geo
P = {Cle_Zone, Libelle_commune, Departement, Region, Pays}
H = {H_Geo}
d
n
= RP99
P = {Cle_Depcom, Intcom, POPF00 .. POPF>95}
H = {}
s
= (h
n
, L, ), o
h
n
= {H_Geo}
L = {Commune, Dpartement, Rgion, }
= {(Commune, Dpartement), (Dpartement, Rgion), (Rgion, )}
3.5.5 Description du schma Prise_SSR et de ses dimensions
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 troi-
sime schma Prise_SSR.
Fig. 3.9 Schma en ocon de neige Prise_SSR
s
= (c
n
, M, D), o
c
n
= Prise_SSR
M = {CompteJoursenwk, CompteJourshorswk}
D = {Etablissment, CIM10, Mode_sortie, Temps, Age, Zone_geo, Semaine_debut,
Semaine_n}
s
= (d
n
, P, H), o
d
n
= Semaine_debut
P = {Cle_Semdebut}
H = {}
d
n
= Semaine_n
P = {Cle_Semn}
H = {}
Les autres dimensions ont t traites au paragraphe 3.5.3.
s
= (h
n
, 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 appe-
lons 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 mo-
dle 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 don-
nes 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 din-
formation. 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, infor-
mations manquantes ou incompltes, et dun autre ct lhtrognit des donnes
fournies par des organismes hors du contexte mdical. Par exemple : les renseigne-
ments 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 rsi-
dence du patient.
Dans le chapitre suivant, nous dcrivons la deuxime partie du processus de struc-
turation. 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.
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 expri-
mentation 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 lex-
cution 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 dOracle9
i
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 en-
semble 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 ma-
trialisation 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,
4.1 Construction du schma 77
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 Fait/Dimension Taille
Prise_MCO Fait 53799 n-uplets
Etablissement Dimension 5079
CIM10 Dimension 17788
Temps Dimension 12
Mode_sortie Dimension 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 uti-
lisons 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, ALL
1
, 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, T
1
, M
1
), ..., (E1, C1, T
Ntemps
, M
Nmode
),
o T
Ntemps
et M
Nmode
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]
problme se rduit dterminer lensemble des cellules dpendantes matrialiser.
Etant donn que le cot de stockage
2
pour une matrialisation de toutes les vues
est de 205929 n-uplets (
i=1,...,n
CS(v
i
), o CS(v
i
) 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 dnis-
sons 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 (2
n
o n est le nombre de dimensions = 2
4
)
Nous dnissons lensemble des vues possibles matrialiser. Le tableau 4.2
contient les 15 vues pour une matrialisation complte ainsi que leur cot de sto-
ckage 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 C. de Stockage C. de Calcul
V1 Prise_MCO+Etablissement+CIM10+Temps+Mode_sortie 53799 n-uplets 90M
V2 Prise_MCO+Etablissement+CIM10+Temps 47133 90M
V3 Prise_MCO+Etablissement+CIM10+Mode_sortie 18456 90M
V4 Prise_MCO+Etablissement+Temps+Mode_sortie 603 61K
V5 Prise_MCO+CIM10+Temps+Mode_sortie 32918 346K
V6 Prise_MCO+Etablissement+CIM10 13973 90M
V7 Prise_MCO+Etablissement+Temps 184 60K
V8 Prise_MCO+Etablissement+Mode_sortie 58 25K
V9 Prise_MCO+CIM10+Temps 26058 216K
V10 Prise_MCO+CIM10+Mode_sortie 8186 90K
V11 Prise_MCO+Temps+Mode_sortie 48 60
V12 Prise_MCO+Etablissement 19 5K
V13 Prise_MCO+CIM10 5329 18K
V14 Prise_MCO+Temps 12 12
V15 Prise_MCO+Mode_sortie 4 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.
4.2 Vues matrialises 79
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.
4 Dim
3 Dim
2 Dim
1 Dim
0 Dim
ECTM
V1
ECT
V2
ECM
V3
ETM
V4
CTM
V5
Etab
V12
EC
V6
ET
V7
EM
V8
CT
V9
CM
V10
TM
V11
Cim10
V13
Temps
V14
Mode
V15
ALL
V16
90M 54K
90M 47K 90M 18K 61K 603 346K 33K
90M 14K 60K 184 25K 58 216K 26K 90K 8K 60 48
5K 19 18K 5K 12 12 5 4
1
Matrialisation Complte: 361M (n-uplets)
Pas de Matrialisation: 90M (n-uplets)
Cot de calcul
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-
ckage et le nombre de vues dpendantes (optimales) dune vue pour calculer le
bnce optimal de celle-ci. Nous rappelons que une vue V
i
est dpendante de V
j
si, et seulement si, nous pouvons rpondre V
i
en utilisant V
j
, ainsi, V
i
_ V
j
.
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 duti-
lisation 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 change-
ments 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
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 B
w
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 B
w
= C(v) - C(u). Sinon B
w
= 0.
2) Dnir B(v, S) =
wv
B
w
.
La gure 4.3 dcrit lalgorithme Greedy pour une slection de n vues matria-
liser.
Nous utilisons lhypercube de la g 4.2 pour lapplication de lalgorithme. La
table 4.3 dcrit les rsultats avec n gal 7.
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 7K*8=56K 7K*4=28K 7K*2=14K 7K*1=7K 7K*1=7K 7K*1=7K -
V3 36K*8=288K 36K*4=144K - - - - -
V4 53K*8=424K - - - - - -
V5 21K*8=168K 21K*4=84K 21K*2=42K - - - -
V6 40K*4=160K 40K*2=80K 4K*2=8K 4K*2=8K 4K*1=4K 4K*1=4K 4K*1=4K
V7 54K*4=216K 419*4=2K 419*4=2K 419*4=2K 419*4=2K 419*4=2K 419*4=2K
V8 54K*4=216K 545*4=2K 545*4=2K 545*4=2K 545*4=2K 545*4=2K 545*4=2K
V9 28K*4=112K 28K*2=56K 28K*1=28K 7K*1=7K 7K*1=7K - -
V10 46K*4=184K 46K*2=92K 10K*2=20K 10K*2=20K - - -
V11 54K*4=216K 555*4=2K 555*4=2K 555*4=2K 555*4=2K 555*4=2K 555*4=2K
V12 54K*2=108K 584*2=1K 584*2=1K 584*2=1K 584*2=1K 584*2=1K 584*2=1K
V13 49K*2=98K 49K*1=49K 13K*1=13K 13K*1=13K 3K 3K 3K
V14 54K*2=108K 591*2=1K 591*2=1K 591*2=1K 591*2=1K 591*2=1K 591*2=1K
V15 54K*2=108K 599*2=1K 599*2=1K 599*2=1K 599*2=1K 599*2=1K 599*2=1K
V16 54K*1=54K 1K 1K 1K 1K 1K 1K
{V1} S=S+V4 S=S+V3 S=S+V5 S=S+V10 S=S+V9 S=S+V2 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).
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 rap-
port la vue V1, que nous sommes censs matrialiser
3
, nous nous apercevons que
le gain est presque minimum, mais que les cots de leur matrialisation sont doubls.
1 2 3 4
16
. . . 5 6
Cot de calcul
Cot de stockage
Nombre de vues matrialises
0
100k
300k
.
.
.
90M
200k
Nombre
de
tuples
7
V2 V3 V6
V5
V9
V10
V4
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.
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 uti-
lisent un modle de cot, comme celui de Greedy, mais qui a t adapt avec lin-
clusion 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 re-
qute ainsi que le cot de maintenance bas sur les oprateurs Add et Delete.
Lalgorithme Greedy est simple et ecace, nanmoins, dans notre exprimenta-
tion, 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 proba-
bilit de changement des relations de base (cot).
4.2.2 Algorithme propos pour la slection des vues mat-
rialiser
Dans notre algorithme, les relations dpendantes dune vue jouent un rle essen-
tiel, 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 to-
tal 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
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 re-
lations 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 d-
pendantes et multipli par la frquence des mises jour.
Le second choix est la vue V5 avec 626K (((21K*4*8)=672K) - ((346K/8) *
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 (448K-(11M*1.18))=-13M -13M -13M -13M -13M -13M -13M
V3 (2M-13M)=-11M -12M -12M -12M -12M -12M -12M
V4 (3392K-9K)=3M - - - - - -
V5 (1344K-46K)=1298K 626K - - - - -
V6 (640K-26M)=-25M -26M -26M -26M -26M -26M -26M
V7 (864K-18K)=845K -11K -11K -11K -11K -11K -11K
V8 (864K-7K)=857K 2K 2K 2K 2K - -
V9 (448K-56K)=392K 168K 0K -28K -28K -28K -28K
V10 (736K-24K)=713K 345K 177K - - - -
V11 (864K-62)=864K 9K 9K 9K - - -
V12 (216K-3K)=213K -1K -1K -1K -1K -3K -3K
V13 (196-9K)=187K 89K 47K -3K -3K -3K -3K
V14 (54K*2*2=216K)=216K 2K 2K 2K 30 30 30
V15 (54K*2*2=216K)=216K 2K 2K 2K 41 41 -
S=S+V1 S=S+V4 S=S+V5 S=S+V10 S=S+V11 S=S+V8 S=S+V15 S=S+V14
Tab. 4.4 Application de notre algorithme aux donnes ADELEM
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. Fina-
lement, 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 pre-
nons 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 pre-
mires vues optimales.
16
. . .
5 6
Cot dexcution
Cot de stockage
Nombre de vues matrialises
7
0
100k
300k
90M
200k
Nombre
de
tuples
4 3 2 1
.
.
.
V5
V10
V4
V8
V11 V14 V15
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 proposi-
tion 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.
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
V4 E+T+M 3 603 61K
V5 C+T+M 3 33K 346K
V8 E+M 2 58 25K
V10 C+M 2 8K 90K
V11 T+M 2 48 60
V14 T 1 12 12
V15 M 1 4 5
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
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 (semi-
automatique) 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 quasi-
automatique.
Nous avons group notre travail en quatre parties. La premire montre larchi-
tecture 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.
R
s
u
l
t
a
t
Gnration SQL
Excution SQL
Interface graphique
+
Mta-schma
(mappings)
Schma
relationnel
Entrept de
donnes
Sources
de
donnes
Schma Global/Schma Local
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 di-
vers composants (relations, mesures et proprits) conformes lindicateur exprim.
Gestionnaire de Requtes : Il est compos de :
(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 utili-
sateurs.
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 Gestion-
naire 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 rela-
tions.
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 re-
prsente 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-
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 chier : 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
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 rem-
plit 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 re-
qutes 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 :
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 (semi-
automatique) de requtes. Nous avons utilis lindicateur : "Q4 : Nombre de sjours
par tablissement et par maladie pendant le mois janvier (avec nombre de sjours >
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 lindica-
teur exprim.
Mesures et leur condition : Il contient les mesures calculer ainsi que leur fonc-
tion 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 :
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 re-
prsente 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 ap-
pel Requete.REL qui contient le code SQL92 gnr. En utilisant loutil dadminis-
tration 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.
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 di-
mensions (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 mat-
rialiser, 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) din-
dicateurs. 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.
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 uti-
liser 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. Nan-
moins, la gestion des versions est une tche complexe et elle prsente plusieurs
problmes. Le principal, notre connaissance, est lexplosion des versions, car lex-
cution 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 en-
semble 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.
Prise_MCO (VS03)
Prise_MCO (VS02)
Prise_MCO (VS01)
Etablissment (VS01)
Mode_sortie (VS01)
CIM10 (VS01)
Temps (VS02)
Temps (VS01)
Cle_Maladie
Libelle_maladie
Cle_Temps
Cle_Temps
Mois
Semestre
Annee
Cle_Finess
Raison_sociale
Code_postal
CA1..CA7
...
Cle_Mode
Libelle_mode
Cle_Maladie
Cle_Finess
Cle_Temps
Cle_Mode
Compte_sejour
Somme_sejour
Cle_Maladie
Cle_Finess
Cle_Maladie
Cle_Finess
Temps (VS03)
Cle_Temps
Mois
Saison
Semestre
Annee
Etablissement (VS02)
Cle_Finess
Raison_sociale
Adresse
Code_postal
CA1..CA7
...
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
5.1 Versions de schmas 103
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 sch-
mas, 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.
07/02
07/03
07/04
07/05
UC
VS01
VS02
VS03
transaction-time
01/01 01/02 01/03 01/04 UC
valid-time
0
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
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 timestamp
1
.
TIME = (TIME
t
X TIME
v
)
: TIME VS
{}
(tt, vt) =
V S
i
si V S
i
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 = (V
s
, C
s
, D
s
,
H
s
, R, CS,
1
) par rapport la gure 5.1, tel que :
V
s
= {VS01, VS02, VS03}
C
s
= {Prise_MCO}
M = {Compte_sejor, Somme_sejour}
D
s
= {Etablissement, CIM10, Temps, Mode_sortie}
P = {Cle_Finess, Raison_sociale, Adresse, Codepostal, CA1 .. CA7, CMO1 ..
CMO7, NLA, NLO, Commune, Departement, Region, Pays, Cle_Maladie, ... }
H
s
= {}
L = {}
CS = {(AddPropriete
Adresse
, VS01, VS02), (AddPropriete
Saison
, VS02, VS03)}
1
(VS01) = (2002-07, UC
2
)
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
Nous utilisons la fonction prsente dans [GM02]
2
Until Change
5.2 Les oprations primitives 105
5.2 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 en-
trepts 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 dnies
Sur une relation :
R1 : constraint addm := type(m
n
) = 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}.
Primitive Dnition Rgle dintgrit
CreateC CreateC(BM, c
n
, {M}, {D})
DropC DropC(BM, c
n
)
RenameC RenameC(BM, c
n
, c
n
)
AddM AddM(BM, c
n
, m
n
) (R1) type(m
n
) = numrique
DeleteM DeleteM(BM, c
n
, m
n
) (R2) {M} 2
RenameM RenameM(BM, c
n
, m
n
, m
n
)
CreateD CreateD(BM, d
n
, {P}, {H}) (R3) cl primaire {FC}
DropD DropD(BM, d
n
) (R4) cl primaire / {FC}
RenameD RenameD(BM, d
n
, d
n
)
AddP AddP(BM, d
n
, p
n
)
DeleteP DeleteP(BM, d
n
, p
n
) (R5) proprit ,= cl primaire
Change_typeP Change_typeP(BM, d
n
, p
n
, p
n
RenameP RenameP(BM, d
n
, p
n
, p
n
CreateH CreateH(BM, h
n
, L, ) (R8) cl primaire {FC}
cl primaire {FD}
DropH DropH(BM, h
n
cl primaire / {FD}
RenameH RenameH(BM, h
n
, h
n
)
AddL AddL(BM, h
n
, l
n
, l
1
, l
2
)
DeleteL DeleteL(BM, h
n
, l
n
cl primaire / {FD}
RenameL RenameL(BM, h
n
, l
n
, l
n
) (R11) cl primaire {FC}
cl primaire {FD}
Tab. 5.1 Primitives pour la gestion de relation
Primitive Dnition Rgle dintgrit
CreationV AddV(BMS, VS
n
)
FreezeV FreezeV(VS
n
) (R12) (VS
n
)=vrai
DefrostV DefrostV(VS
n
)
ExporterR ExporterR(VS
n
, CIM10, VS
n
) (R13) d
n
VS
n
DropV DropV(VS
n
) (R14) DropV(VS
n
) (VS
n
)=vrai
Tab. 5.2 Primitives pour la gestion des versions
5.3 Dnition formelle des primitives 107
R5 : constraint deletep := proprit ,= cl primaire.
R6 : constraint change_typep := proprit ,= cl primaire.
R7 : constraint renamep := proprit ,= 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
,= version courante.
5.3 Dnition 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 spci-
es 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 hirar-
chies, les mesures, les proprits et les niveaux ont des noms uniques.
Schma du cube : La cardinalit de lensemble daxes et de lensemble de me-
sures 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=(V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
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).
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.
Dnition 5.1 : Primitive CreateC
Etant donns une version de schma VS = (V
s
, C
s
, D
s
, H
s
, R, CS,
1
) et dins-
tance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
), un nom de cube c
n
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, c
n
, M, D) est une version dont le schma est
VS = (V
s
, C
s
{c
s
}, D
s
, H
s
, R, CS,
1
), o c
s
est un schma de cube (c
n
, M, D)
et linstance est IM = IM. 2
Considrons linsertion dans la version VS
i
dun nouveau cube Achats qui contient
lensemble de dimensions {Magasin, Temps, Produit, Fournisseur} et la mesure
QuantiteA, la primitive CreateC(VS
i
, Achats, {Magasin, Temps, Produit, Fournis-
seur}, QuantiteA) cre le cube.
Dnition 5.2 : Primitive DropC
Cette primitive limine un schma de cube, ses dimensions et ses hirarchies dune
version de schma VS.
s
, C
s
, D
s
, H
s
, R, CS,
1
) et
dinstance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
), un nom de cube c
n
C, la primitive
DropC(VS, c
n
) cre une version dont le schma est VS = (V
s
, C
s
, D
s
, H
s
, R,
CS,
1
), o C
s
= C
s
{(c
n
, m
1
,..., m
j
, D)}. Linstance est IV = (V
i
, C
i
{c
i
}, D
i
,
H
i
, R
i
, CS
i
,
1
i
), o c
i
= {(c
n
, {(v
1
,..., v
j
)[
i=1,...,n
v
i
measuredom(m
i
)}, {d})}. 2
Par exemple, pour liminer le cube Achats de la version VS
i
, nous excutons la
primitive DropC(VS
i
, Achats).
Dnition 5.3 : Primitive RenameC
s
, C
s
, D
s
, H
s
, R, CS,
1
) et dins-
tance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
), les noms de cubes c
n
c
n
C, lexcution
de la primitive RenameC(VS, c
n
, c
n
) fournit une version dont le schma est VS
= (V
s
, C
s
, D
s
, H
s
, R, CS,
1
), o C
s
= C
s
{(c
n
, M, D)}
{(c
n
, M, D)}, et
linstance est IV = IV. 2
Par exemple, pour renommer le cube Ventes par VentesJournalieres : RenameC(VS
i
,
Ventes, VentesJournalieres).
Dnition 5.4 : Primitive AddM
s
, C
s
, D
s
, H
s
, R, CS,
1
) et dins-
tance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
), un nom de cube c
n
C et un nom de
mesure m
n
M, la primitive AddM(VS, c
n
, m
n
) cre une version dont le schma est
VS = (V
s
, C
s
, D
s
, H
s
, R, CS,
1
), o C
s
= C
s
{(c
n
, M, D)}
{(c
n
, M
{m
n
},
D)}, et linstance est IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
) o C
i
= C
i
{c
i
}
{c
i
},
o c
i
= (c
n
, {(m
1
,..., m
i
)}, {d}) et c
i
= (c
n
, {(m
1
,..., m
i
)}
{m
n
}, {d}). 2
Par exemple, pour ajouter la mesure QuantiteV au cube Ventes, nous excutons
la primitive AddM(VS
i
, Ventes, QuantiteV).
Dnition 5.5 : Primitive DeleteM
s
, C
s
, D
s
, H
s
, R, CS,
1
) et dins-
tance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
), un nom de cube c
n
C et un nom de
mesure m
n
M tel que [M[ 2, le rsultat de DeleteM(VS, c
n
, m
n
) est une ver-
sion dont le schma est VS = (V
s
, C
s
, D
s
, H
s
, R, CS,
1
), o C
s
= C
s
{(c
n
,
M, D)}
{(c
n
, M{m
n
}, D)}. Linstance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
)
o C
i
= C
i
{c
i
}
{c
i
}, o c
i
= (c
n
, {(m
1
,..., m
i
)}, {d}) et c
i
= (c
n
, {(m
1
,...,
m
i
)}{m
n
}, {d}). 2
Par exemple, pour supprimer la mesure QuantiteV de cube Ventes : DeleteM(VS
i
,
Ventes, QuantiteV).
Dnition 5.6 : Primitive RenameM
s
, C
s
, D
s
, H
s
, R, CS,
1
) et dins-
tance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
), un nom de cube c
n
C et les noms m
n
et
m
n
M, lexcution de la primitive RenameM(VS, c
n
, m
n
, m
n
) donne une version
dont le schma est VS = (V
s
, C
s
, D
s
, H
s
, R, CS,
1
), o C
s
= C
s
{(c
n
, M,
D)}
{(c
n
, M{m
n
}
{m
n
}, D)}. Linstance est IV = IV. 2
Par exemple, pour changer le nom de la mesure Quantite par QuantiteJournaliere,
nous excutons la primitive RenameM(VS
i
, Ventes, Quantite, QuantiteJournaliere).
Dnition 5.7 : Primitive CreateD
s
, C
s
, D
s
, H
s
, R, CS,
1
) et
dinstance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
), un nom de cube c
n
C un nom de
dimension d
n
D, un ensemble de proprits P tel que [P[ 1 et H, le rsultat de la
primitive CreateD(VS, C
n
, d
n
, P, H) est une version dont le schma est VS = (V
s
,
C
s
, D
s
{d
s
}, H
s
, R, CS,
1
), o C
s
= C
s
{(c
n
, M, D)}
{(c
n
, M, D
{d
n
})}
et D
s
= D
s
{d
s
}. Linstance est IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
), o C
i
=
C
i
{c
i
}
{c
i
}, c
i
= (c
n
, {m}, {d
1
,... d
i
}), c
i
= (c
n
, {m}, {d
1
,... d
i
}
{d
n
}) et D
i
= D
i
. 2
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(VS
i
, Ventes, Fourniseur, {Cle_F,
Raison_sociale, Adresse, Tlphone, Pays}, {}).
Dnition 5.8 : Primitive DropD
Cette primitive limine un schma de dimension et leurs instances dune version
VS
i
. La primitive ne peut pas tre excute sil existe un schma de cube qui utilise
cette dimension. Ainsi, nous supposons lexistence dune fonction boolenne indi-
quant si la dimension peut tre supprime.
s
, C
s
, D
s
, H
s
, R, CS,
1
) et
dinstance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
), un nom de dimension d
n
D tel que
(d
n
=vrai), la primitive DropD(VS, d
n
) cre une version dont le schma est VS
= (V
s
, C
s
, D
s
, H
s
, R, CS,
1
), o D
s
= D
s
{(d
n
, P, H)}. Linstance est IV =
(V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
), o D
i
= D
i
{d
i
}, o d
i
= (d
n
, {(v
1
,..., v
x
)[
i=1,...,n
v
i
propertydom(p
i
)}, {h}). 2
Par exemple, pour supprimer la dimension Magasin, nous excutons la primitive
DropD (VS
i
, Magasin) (Magasin)=vrai.
Dnition 5.9 : Primitive RenameD
s
, C
s
, D
s
, H
s
, R, CS,
1
) et dins-
tance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
), un nom de cube c
n
C et deux noms de
dimensions d
n
, d
n
D, lopration RenameD(VS, c
n
, d
n
, d
n
) fournit une version
s
, C
s
, D
s
, H
s
, R, CS,
1
), o C
s
= C
s
{(c
n
, M,
D)}
{(c
n
, M, D{d
n
}
{d
n
})} et D
s
= D
s
{(d
n
, P, H)}
{(d
n
, P, H)} et lins-
tance est IV = IV. 2
Par exemple, pour changer le nom de la dimension Magasin par le nom Boutique
du cube Ventes : RenameD(VS
i
, Ventes, Magasin, Boutique).
Dnition 5.10 : Primitive AddP
s
, C
s
, D
s
, H
s
, R, CS,
1
) et dins-
tance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
n
D et un nom
de proprit p
n
P, la primitive AddP(VS, d
n
, p
n
) cre une version dont le schma
est VS = (V
s
, C
s
, D
s
, H
s
, R, CS,
1
), o D
s
= D
s
{(d
n
, P, H)}
{(d
n
, P
{p
n
},
H)}, et linstance est IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
) o D
i
= D
i
{d
i
}
{d
i
},
o d
i
= (d
n
, {(p
1
,..., p
i
)}, {h}) et d
i
= (d
n
, {(p
1
,..., p
i
)}
{p
n
}, {h}). 2
Par exemple, pour ajouter la proprit Telephone la dimension Magasin, nous
excutons la primitive AddP(VS
i
, Magasin, Telephone).
Dnition 5.11 : Primitive DeleteP
s
, C
s
, D
s
, H
s
, R, CS,
1
) et dins-
tance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
n
D et un nom de
proprit pP tel que [P[ 2, le rsultat de DeleteP(VS, d
n
, p) est une version dont
le schma est VS = (V
s
, C
s
, D
s
, H
s
, R, CS,
1
), o D
s
= D
s
{(d
n
, P, H)}
{(d
n
,
P{p}, H)}. Linstance IV = (C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
) o D
i
= D
i
{d
i
}
{d
i
},
o d
i
= (d
n
, {(p
1
,..., p
i
)}, {h}) et d
i
= (d
n
, {(p
1
,..., p
i
)}{p}, {h}). 2
Pour supprimer la proprit Telephone de la dimension Magasin, nous excutons
la primitive DeleteP(VS
i
, Magasin, Telephone).
Dnition 5.12 : Primitive Change_typeP
s
, C
s
, D
s
, H
s
, R, CS,
1
) et dins-
tance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
n
D et les noms
de proprits p
n
, p
n
P, le rsultat de Change_typeP(BM, d
n
, p
n
, p
n
) est une
version dont le schma est VS = (V
s
, C
s
, D
s
, H
s
, R, CS,
1
), o D
s
= D
s
{(d
n
,
P, H)}
{(d
n
, P{p
n
}
{p
n
}, H)}. Linstance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
)
o D
i
= D
i
{d
i
}
{d
i
}, o d
i
= (d
n
, {(p
1
,..., p
i
)}{p
n
}, {h}) et d
i
= (d
n
, {(p
1
,...,
p
i
)}
{p
n
}, {h}). 2
Par exemple, pour changer la proprit Codepostal de integer char : Change_
typeP(VS
i
, Magasin, Codepostal, CodepostalChar).
Dnition 5.13 : Primitive RenameP
s
, C
s
, D
s
, H
s
, R, CS,
1
) et dins-
tance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
n
D et les noms
de proprits p
n
, p
n
P, le rsultat de RenameP(VS, d
n
, p
n
, p
n
) est une version
s
, C
s
, D
s
, H
s
, R, CS,
1
), o D
s
= D
s
{(d
n
, P,
H)}
{(d
n
, P{p
n
}
{p
n
}, H)}. Linstance IV = IV. 2
Par exemple, pour changer le nom de la proprit Raison par Raison _sociale :
RenameP(VS
i
, d
n
, Raison, Raison_sociale).
Dnition 5.14 : Primitive CreateH
s
, C
s
, D
s
, H
s
, R, CS,
1
) et dins-
tance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
n
D un nom de
hirarchie h
n
H, un ensemble de niveaux L et une relation dnie sur L, le rsul-
tat de la primitive CreateH(VS, d
n
, h
n
, L, ) est une version dont le schma est VS
= (V
s
, C
s
, D
s
, H
s
, R, CS,
1
), o D
s
= D
s
{(d
n
, P, H)}
{(d
n
, P, H
{h
n
})}
et H
s
= H
s
{h
s
}, o h
s
est un schma de hirarchie (h
n
, L, ). Linstance est IV
= (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
), o D
i
= D
i
{d
i
}
{d
i
}, d
i
= (d
n
, {p}, {(h
1
, ...,
h
k
)}), d
i
= (d
n
, {p}, {(h
1
, ..., h
k
)}
{h
n
}) et H
i
= H
i
. 2
Considrons par exemple la cration de la hirarchie H_Temps qui contient len-
semble de niveaux {Jour, Mois, Saison, Annee}. La relation entre les niveaux est
{(Jour, Mois), (Mois, Saison), (Saison, Annee)}. La primitive CreateH(VS
i
, Etablis-
sement, H_Temps, L, ) insre la dimension Etablissement, la nouvelle hirarchie.
Dnition 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.
s
, C
s
, D
s
, H
s
, R, CS,
1
) et
dinstance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
), un nom de hirarchie h
n
H tel que
(h
n
)=vrai, la primitive DropH(VS, h
n
) fournit une version dont le schma est VS
= (V
i
, C
s
, D
s
, H
s
, R, CS,
1
), o H
s
= H
s
{(h
n
, L, )}. Linstance est IV =
(V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
), o H
i
= H
i
{(
l
i
L
levelset(l
i
), RUP)}. 2
Par exemple, pour supprimer la hirarchie H_Temps : DropH(VS
i
, H_Temps).
Dnition 5.16 : Primitive RenameH
s
, C
s
, D
s
, H
s
, R, CS,
1
) et dins-
tance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
), le nom de dimension d
n
D, et deux noms
de hirarchies h
n
et h
n
H, la primitive RenameH(VS, d
n
, h
n
, h
n
) cre une version
s
, C
s
, D
s
, H
s
, R, CS,
1
), o D
s
= D
s
{(d
n
, P,
H)}
{(d
n
, P, H{h
n
}
{h
n
}) et H
s
= H
s
{(h
n
, L, )}
{(h
n
, L, )}. Linstance
est IV= IV. 2
Par exemple, pour renommer la hirarchie H_Temps de la dimension Temps par le
nom H_Jour, nous excutons la primitive RenameH(VS
i
, Temps, H_Temps, H_Jour).
Dnition 5.17 : Primitive AddL
Cette primitive modie le schma de hirarchie h
s
en construisant une relation
entre les niveaux l
1
et l
2
qui appartiennent h
s
et un nouveau niveau l
n
. Cette op-
ration tablit les relations de dpendances suivantes : l
1
l
n
et l
n
l
2
. Pour faire
cela, nous supposons lexistence dune fonction qui, tant donns un nom de hi-
rarchie h
n
et deux niveaux l
i
et l
j
, retourne une valeur boolenne gale vrai si l
i
l
j
.
s
, C
s
, D
s
, H
s
, R, CS,
1
) et dins-
tance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
n
H, les niveaux
l
n
, l
1
et l
2
L, et un membre mlevelset(l
n
), la primitive AddL(VS, h
n
, l
n
, l
1
, l
2
)
cre une version dont le schma est VS = (V
s
, C
s
, D
s
, H
s
, R, CS,
1
) tel que
H
s
= (H
s
{h
s
}
{h
s
}), o h
s
= (h
n
, L, ) et h
s
= (h
n
, L
{l
n
},
{(l
1
l
n
),
(l
n
l
2
)}). Linstance est IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
) telle que H
i
=
(H
i
{h
i
}
{h
i
}), o h
i
= (
l
i
L
levelset(l
i
), RUP) et h
i
= (
l
i
L
{l
n
}
levelset(l
i
),
RUP). Lensemble RUP contient les fonctions rup
l
j
l
i
telles que rup
l
n
l
1
= {(e, m)[e
levelset(l
1
)}, rup
l
2
l
n
= {(e, m)[e levelset(l
2
)} et rup
l
j
l
i
= rup
l
j
l
i
pour les autres
niveaux l
i
et l
j
. 2
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(VS
i
, 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.
Commune
Departement
Region
T
. . .
Rhne Alpes
. . .
t
a) Schma
b) Instance
District
Isre
Columbia
. . .
Fig. 5.3 Insertion du niveau District la Hirarchie H_Geo.
Dnition 5.18 : Primitive DeleteL
s
, C
s
, D
s
, H
s
, R, CS,
1
) et dins-
tance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
n
H, et un niveau
l
n
L, tel que l
n
,= et l
n
,=l, la primitive DeleteL(VS, h
n
, l
n
) donne une version
s
, C
s
, D
s
, H
s
, R, CS,
1
), o H
s
= (H
s
{(h
n
, L,
)}
{(h
n
, L, )}), o L = (L{l
n
}), = ({(l
1
, l
2
)[l
n
= l
1
(l
n
= l
2
)})
{(l
1
,
l
2
)[l
1
l
n
l
n
l
2
}. Linstance est IV = (V
i
, C
i
, D
i
, H
i
{h
i
}
{h
i
}, R
i
, CS
i
,
1
i
),
o h
i
= (
l
i
L
levelset(l
i
), RUP) et h
i
= (
l
i
L
levelset(l
i
), RUP). Lensemble
RUP contient les fonctions rup
l
j
l
i
telles que (i) rup
l
2
l
1
= rup
l
n
l
1
rup
l
2
l
n
, si l
1
l
n

l
n
l
2
, (ii) rup
l
2
l
1
= rup
l
2
l
1
, dans les autres cas. 2
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(VS
i
, H_Geo, Departement). La gure 5.4 montre le rsultat de cet opra-
teur.
Commune
Region
T
. . .
t
a) Schma
b) Instance
District
Columbia
Rhne Alpes
. . .
Fig. 5.4 Rsultat dliminer le niveau Departement la Hirarchie H_Geo.
Dnition 5.19 : Primitive RenameL
Cette primitive change le nom dun niveau, il prend en entre le nom h
n
de la
hirarchie, le niveau renommer, lancien nom l
n
et le nouveau nom l
n
.
s
, C
s
, D
s
, H
s
, R, CS,
1
) et
dinstance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
n
H, et les
niveaux l
n
et l
n
L, la primitive RenameL(VS, h
n
, l
n
, l
n
) cre une version dont le
schma est VS = (V
s
, C
s
, D
s
, H
s
, R, CS,
1
), o H
s
= H
s
{(h
n
, L, )}
{(h
n
,
L{l
n
}
{l
n
}, )}, et linstance est IV = IV. 2
Par exemple, pour renommer le niveau Commune de la hirarchie H_Geo par le nom
Ville : RenameL(VS
i
, H_Geo, Commune, Ville).
5.3.2 Gestion des versions
Nous prsentons lensemble des dnitions de primitives qui agissent sur la ges-
tion de versions de schmas. Nous considrons lexistence de :
DOM = dom(char)
dom(integer=
dom(oat)
dom(decimal)
dom(date)
contenant le domaine de chaque type atomique.
OP = Ensemble de oprations primitives.
Dnition 5.20 : Primitive CreateV
s
, C
s
, D
s
, H
s
, R, CS,
1
) et dins-
tance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
), et un nom de version v
n
V, le rsultat
de CreateV(VS, v
n
) cre une nouvelle version dont le schma est VS = VS et lins-
tance est IV = IV. 2
Par exemple, supposons que nous voulons crer une version de schma VS
j

partir de la version VS
i
. La primitive CreateV(VS
i
, VS
j
) cre la version VS
j
= (V
s
,
C
s
, D
s
, H
s
, R, CS,
1
).
Dnition 5.21 : Primitive FreezeV
Cette primitive permet de geler une version (i.e., elle ne permet plus de chan-
gements). La seul primitive que nous pouvons appliquer une version gele est
DefrostV (cf. Dnition 5.22).
s
, C
s
, D
s
, H
s
, R, CS,
1
) et dins-
tance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
n
V, la primitive
FreezeV(v
n
) bloque cette version en interdisant lexcution des primitives dvolu-
tion. La version de schma est VS
i
=v
n
s
, C
s
, D
s
, H
s
, R,
CS,
1
) et linstance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
).
i=1,...,n
p
i
OP, p
i
(VS
i
)
sexcute si et seulement si VS
i
nest pas gele. 2
Dnition 5.22 : Primitive DefrostV
s
, C
s
, D
s
, H
s
, R, CS,
1
) et
dinstance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
n
V, la pri-
mitive DefrostV(v
n
) fournit une version de schma VS
i
=v
n
dont le schma est VS
= (V
s
, C
s
, D
s
, H
s
, R, CS,
1
) et linstance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
).
i=1,...,n
e
i
E(VS
i
) p
i
(VS
i
) sexcute, o p
i
OP. 2
Dnition 5.23 : Primitive ExporterR
Cette primitive permet de faire migrer lensemble des donnes intensionnelles et
extensionnelles dune relation vers une nouvelle version de schma.
s
, C
s
, D
s
, H
s
, R, CS,
1
) et dins-
tance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
), un schma de dimension d
n
D et un nom
de version v
n
V, le rsultat de ExporterR(VS, d
n
, v
n
) est une version VS dont le
schma est VS = (V
s
, C
s
, D
s
{d
s
}, H
s
, R, CS,
1
), o d
s
est un schma de di-
mension (d
n
, P, H), et linstance est IV = IV. 2
Par exemple, pour faire migrer la dimension CIM10 qui appartient la version
VS
n
, nous excutons la primitive ExporterR(VS
n
, CIM10, VS
n
), o le schma de
la dimension CIM10 est (CIM10, {Cle_Maladie, Libelle_maladie}, {}).
Dnition 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.
s
, C
s
, D
s
, H
s
, R, CS,
1
) et
dinstance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
n
V tel que
(v
n
)=vrai, la primitive DropV(VS
i
), o VS
i
= v
n
, limine la version de schma
SV
i
ainsi que leurs instances. 2
Dnition 5.25 : Oprateur SetVersion
s
, C
s
, D
s
, H
s
, R, CS,
1
) et dins-
tance IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
), un ensemble de primitives {EP} et les
noms de versions v
n
et v
n
V, la primitive SetVersion(VS
i
, {EP}, VS
j
), o VS
i
= v
n
et VS
j
= v
n
, cre la version de schma VS
j
s
,
C
s
, D
s
, H
s
, R, CS,
1
) et linstance est IV = (V
i
, C
i
, D
i
, H
i
, R
i
, CS
i
,
1
i
). 2
Si nous voulons crer une nouvelle version VS
j
partir de la version courante VS
i
incluant les changements : {EP}=(DropC(VS
i
, Prise_MCO), DropD(VS
i
, Mode_sortie),
ExporterR(VS
i
, CIM10, VS
j
), ExporterR(VS
i
, Etablissement, VS
j
), RenameP(VS
i
,
Etablissement, Codepostal, Code), ExporterR(VS
i
, Temps, VS
j
), DeleteP(VS
i
, Temps,
Saison)), lexcution de SetVersion (VS
i
, {EP}, VS
j
) donne le rsultat souhait.
Chaque primitive de lensemble EP doit respecter la dnition donne prcdem-
ment.
5.4 Gestion temporelle des entrepts
Nous traitons dans cette section la gestion des donnes historises de notre mo-
dle. Nous montrons dabord larchitecture conue simplie du projet et linterac-
5.4 Gestion temporelle des entrepts 117
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 simplie 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
Donnes de
dtail et rsumes
(courantes)
Entrept
de
donnes
Fig. 5.5 Interaction des composants lintrieur de larchitecture.
Le composant Interface Graphique contient un gestionnaire de requtes qui in-
teragit 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 bi-
temporels.
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.
Gestionnaire dvolution
Entrept
de donnes
historises
Donnes intensionnelles
et extensionnelles
+
Table de correspondance
Stockage de deltas
+
Rgles de configuration
Fig. 5.6 Modle de versions de schmas bitemporels.
Les deltas reprsentent lensemble de dirences entre versions. Un delta sym-
trique entre SV
i
et SV
j
= (SV
i
- SV
j
)

(SV
j
- SV
i
) et un delta direct est une
squence de changements c
1
, ..., c
n
qui appliqus sur une version v
1
en gnerent une
nouvelle v
2
[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 ma-
trialise, vue.
Table pour les attributs :
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 d-
nies, nanmoins, nous pouvons aussi en dnir de nouvelles, par exemple :
version
courante
=
1
(VS
i
) = 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 cou-
rantes. Nanmoins, pour les requtes sur des donnes historises, le composant Inter-
face 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 en-
semble 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 len-
semble 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
Gestionnaire dvolution
. . .
Donnes
intensionnelles
et extensionnelles
historises 1
+
Table Corresp.
Donnes
intensionnelles
et extensionnelles
historises n
+
Table Corresp.
Meta
Schema
Stockage
de deltas
+
Rgles de
Configuration
Fig. 5.7 Gestionnaire dvolution de schmas.
Historique
Niveau 1
(Extensionnel)
Niveau 2
(Intensionnel)
Niveau 3
(Meta-schema)
UC
tv
T1 T2 T3 T4
0
T
T
T
UC
tt
Deltas
+
Rgles de Configuration
VS01 (DE)
VS02 (DE)
VS03 (DE)
VS03 (DI)
VS02 (DI)
VS01 (DI)
Table de Corresp.
Table de Corresp.
Table de Corresp.
Niveau 2
(Intensionnel)
Niveau 1
(Extensionnel)
Niveau 2
(Intensionnel)
Niveau 1
(Extensionnel)
Fig. 5.8 Gestion dvolution de schmas par niveau.
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 luti-
lisateur 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 pro-
prits 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 quintension-
nelles. 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 :
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 essen-
tielle. 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.
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 en-
trept de donnes :
- Dnition dun modle multidimensionnel.
- Traitement de requtes et algorithme pour la slection optimale de vues ma-
trialiser.
- Interface graphique pour la gnration (semi-automatique) des requtes.
- Versions de schmas bitemporels pour la gestion de donnes mdicales histori-
ses.
6.1.2 Dnition dun modle multidimensionnel
Notre mtamodle multidimensionnel se compose de trois classes : Cube, Dimen-
sion et Hirarchie. Ce mtamodle sert la conception dun modle multidimen-
sionnel. Pour faire cela, nous avons donn quatre dnitions : le schma dune base
multidimensionnelle, dun cube, dune dimension et le schma dune hirarchie.
125
126 Conclusions et perspectives
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 simpli-
cit. 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 pro-
jet 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 duti-
lisation 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 pro-
portion 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 Versions de schmas bitemporels
Les actualisations ralises dans les sources des donnes doivent tre reportes sur
lentrept. Ces changements peuvent aecter aussi bien les donnes que leur struc-
ture. 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, lvolu-
tion 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 sys-
tmes 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-
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 pr-
sent 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 collec-
ter 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 perfor-
mances. 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 ar-
rtons 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 len-
semble, 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 129
6.2.1.2 Versions de schmas bitemporels
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 histori-
ses. 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 attri-
but spatial. Cet attribut dcrit lemplacement dun objet dans lespace deux ou
trois dimensions.
- Des proprits qui dcrivent lobjet reprsentes par des attributs dits thma-
tiques ou descriptifs.
La dnition suivante du Systme dInformation Gographique (SIG) est gnra-
lement admise :
Un systme dinformation gographique est un ensemble organis de matriels in-
formatiques, 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].
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 repr-
sents 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 fron-
tire.
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 do-
maine 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 car-
tographis 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 don-
nes 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 Health-
Mapper, ceci nous permettra dacher les donnes slectionnes au travers de leur
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 en-
trept 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 interm-
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 celles-ci.
Lintgration entrane aussi une phase de transformation, celle-ci consiste les pr-
parer (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.
Entrept
de
donnes
Intgrateur
Adaptateur/
Moniteur
Adaptateur/
Moniteur
Adaptateur/
Moniteur
Source Source 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 don-
nes, dont lactivit de lintgrateur peut tre spcique. Ainsi, il est important
de proposer le dveloppement de techniques et doutils pour la gnration automa-
tique dadaptateurs/moniteurs et dintgrateurs partir de spcications dclara-
tives [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 co-
ordonnes, 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).
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 infra-
structure.
Le datawarehouse nest quune toile de plus dans le rmament des
technologies [Gog04].
Bibliographie
[AAD
+
96] 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.
[ABCM99] Ulf Asklund, Lars Bendix, Henrik Baerbak Christensen, and Boris
Magnusson. The Unied Extensional Versioning Model. In System
Conguration Management, pages 100122, 1999.
[Adi02] M. Adiba. Entrepts de donnes et fouille de donnes, Introduction,
Supports de cours, 2002.
[AGS97] Rakesh Agrawal, A. Gupta, and Sunita Sarawagi. Modeling Multi-
dimensional Databases. In Alex Gray and Per-ke Larson, editors,
Proc. 13th Int. Conf. Data Engineering, ICDE, pages 232243. IEEE
Computer Society, 711 1997.
[AQ86] Michel E. Adiba and N. Bui Quang. Historical Multi-Media Data-
bases. In VLDB 86 : Proceedings of the Twelfth International Confe-
rence on Very Large Data Bases, pages 6370. Morgan Kaufmann
Publishers Inc., 1986.
[BB03] X. Baril and Z. Bellahsne. Selection of Materialized Views : A Cost-
Based Approach. In CAiSE, pages 665680, Bethesda, Maryland,
USA, 2003. J. Eder and M. Missiko.
[BCA01] E. Benitez, C. Collet, and M. Adiba. Entrepts de donnes : caract-
ristiques et problmatique. Revue TSI, 20(2), 2001.
[Bel02] A. Belot. Dveloppement dun logiciel de cartographie de lore et de
la demande de soins hospitaliers en france. Technical report, 2002.
[Ben02] E. Benitez. Infrastructure adaptable pour lvolution des entrepts de
donnes. PhD thesis, Universit Joseph Fourier, Grenoble, France,
Septembre 2002.
[Ber03] Philip Bernstein. Applying Model Management to Classical Meta
Data Problems. In CIDR Conference on Innovative Data Systems
Research, 2003.
[Blo99] Bloor Research - http ://www.bloor-research.com/, 1999.
[BPT97] Elena Baralis, Stefano Paraboschi, and Ernest Teniente. Materialized
Views Selection in a Multidimensional Database. The VLDB Journal,
pages 156165, 1997.
135
[BSH98] J.W. Buzydlowski, I-Y. Song, and L. Hassell. A Framework for Object-
Oriented 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 ware-
housing and OLAP technology. SIGMOD Record, 26(1) :6574, 1997.
[CGJM01] W. Cellary, S. Gangarski, G. Jomier, and M. Manouvrier. Les ver-
sions, 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 user-
analystes : an IT mandate. Technical report, 1993.
[CT97] Luca Cabibbo and Riccardo Torlone. Querying Multidimensional Da-
tabases. 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 Confe-
rence on Extending Database Technology, pages 183197. Springer-
Verlag, 1998.
[CW98] R. Conradi and B. Westfechtel. Version Models for Software Congu-
ration Management. ACM Computing Surveys, 30(2) :232282, June
1998.
[DB204] DB2 OLAP Server - http ://www-
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 Don-
nes 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.
[DGW
+
98] 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 Sca-
las, 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.
[DSBH99] B. Dinter, C. Sapia, M. Blaschka, and G. Hing. OLAP Market
and Research : Initiating the Cooperation. Computer Science and
Information Management, 2(3), 1999.
[Dum00] M. Dumas. TEMPOS : une plate-forme pour le dveloppement dap-
plications temporelles au dessus de SGBD objets. PhD thesis, Uni-
versit Joseph Fourier, Grenoble, France, Juin 2000.
[EJWG03] Jr. E. James Whitehead and Dorrit Gordon. Uniform Comparison of
Conguration Management Data Models. In Software Conguration
Management, pages 7085, 2003.
[Evo97] Projet Evolution - http ://www.prism.uvsq.fr/recherche/themes/ an-
ciens/teams/dataware/coop/evolution.html, 1997.
[FGM00] 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.
[Fra97] J-M Franco. Le Data Warehouse (Le Data Mining). Editions Eyrolles,
Paris, 1997.
[GBLP95] 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.
[GM95] A. Gupta and I. Mumick. Maintenance of Materialized Views : Pro-
blems, Techniques and Applications. IEEE Quarterly Bulletin on Data
Engineering ; Special Issue on Materialized Views and Data Warehou-
sing, 18(2) :318, 1995.
[GM99] Fabio Grandi and Federica Mandreoli. ODMG Language Extensions
for Generalised Schema Versioning Support. In ER Workshops, pages
3647, 1999.
[GM00] A. Gutirrez and A. Marotta. An Overview of Data Warehouse Design
Approaches. 2000.
[GM02] Fabio Grandi and Federica Mandreoli. A Formal Model for Temporal
Schema Versioning in Object-Oriented Databases. Technical report,
2002.
[GMS00] Fabio Grandi, Federica Mandreoli, and Maria Rita Scalas. A Ge-
neralized Modeling Framework for Schema Versioning Support. In
Australasian Database Conference, pages 3340, 2000.
[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 Ware-
house. 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 Publi-
shing 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.
[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 Object-
Oriented Databases. In Proceedings of the Fourteenth International
Conference on Very Large Data Bases, pages 148159. Morgan Kauf-
mann Publishers Inc., 1988.
[KC02] Heum-Geun Kang and Chin-Wan Chung. Exploiting Versions for On-
line 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 : Procee-
dings of the 1999 ACM SIGMOD international conference on Mana-
gement 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 Que-
ries Using Views. In Proceedings of the 14th ACM SIGACT-SIGMOD-
SIGART 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 Confe-
rence on Management of Data, pages 557559, May 1997.
[Mar98] P. Marcel. Manipulations de Donnes Multidimensionnelles et Lan-
gages de Rgles. PhD thesis, Institut National des Sciences Appliques
de Lyon, France, 1998.
[MBJ
+
02] Renata Matos, Adriana Bueno, Anelise Jantsch, Nina Edelweiss, and
Clesio Saraiva. Dynamic Schema Evolution Management Using Ver-
sion in Temporal Object-Oriented Databases. In Database and Expert
Systems Applications, pages 524533, 2002.
[ME97] Viviane Pereira Moreira and Nina Edelweiss. Queries to Temporal
Databases Supporting Schema Versioning, 1997.
[Med05] Aci project MEDIGRID : medical data storage and processing on the
GRID - http ://www.creatis.insa-lyon.fr/medigrid/, 2005.
[MQM97] Inderpal Singh Mumick, Dallan Quass, and Barinderpal Singh Mu-
mick. Maintenance of data cubes and summary tables in a warehouse.
In SIGMOD 97 : Proceedings of the 1997 ACM SIGMOD internatio-
nal conference on Management of data, pages 100111. ACM Press,
1997.
[MS90] E. McKenzie and Richard Thomas Snodgrass. Schema evolution and
the relational algebra. Inf. Syst., 15(2) :207232, 1990.
[MS93] Simon Monk and Ian Sommerville. Schema evolution in OODBs using
class versioning. SIGMOD Rec., 22(3) :1622, 1993.
[Mun93] B. P. Munch. Versioning in a Software Database - The Change Orien-
ted Way. PhD thesis, Norwegian Institute of Technologie, 1993.
[Odb92] Erik Odberg. A Framework for Managing Schema Versioning in
Object-Oriented databases. In DEXA, pages 115120, 1992.
[Ola04] The OLAP Report - http ://www.olapreport.com/fasmi.htm, 2004.
[ORA96] Oracle Express Server - http ://otn.oracle.com/documentation /ex-
press_server.html, 1996.
[PCTM02] J. Poole, D. Chang, D. Tolbert, and D. Mellor. Common Warehouse
Metamodel, An Introduction to the Standard for Data Warehouse In-
tegration. Wiley Publishing, Inc., 2002.
[PCTM03] J. Poole, D. Chang, D. Tolbert, and D. Mellor. Common Warehouse
Metamodel, Developers Guide. Wiley Publishing, Inc., 2003.
[PMS04] Programme de Mdicalisation des Systmes dInformation -
http ://www.atih.sante.fr/, 2004.
[Qui99] Christoph Quix. Repository Support for Data Warehouse Evolution.
In DMDW, page 4, 1999.
[QW97] Dallan Quass and Jennifer Widom. On-line warehouse view main-
tenance. In Proceedings of the 1997 ACM SIGMOD international
conference on Management of data, pages 393404. ACM Press, 1997.
[RGMS01] John F. Roddick, Fabio Grandi, Federica Mandreoli, and Maria Rita
Scalas. Beyond Schema Versioning : A Flexible Model for Spatio-
Temporal Schema Selection. Geoinformatica, 5(1) :3350, 2001.
[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 : Procee-
dings of the 1999 ACM SIGMOD international conference on Mana-
gement 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 annota-
ted 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 Schema-
Evolution 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 In-
ternacional 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. Ans-
wering Queries with Aggregation Using Views. In VLDB 96 : Procee-
dings 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 Kam-
bayashi. Recent Advances and Research Problems in Data Warehou-
sing. 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.
[Sno95] Richard T. Snodgrass. The TSQL2 Temporal Query Language. Kluwer
Academic Publishers, 1995.
[Sno99] Richard T. Snodgrass. Developing Time-Oriented Database Applica-
tions in SQL. Morgan Kaufmann, 1999.
[Tes00] O. Teste. Modlisation et manipulation dentrepts de donnes com-
plexes 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 Mainte-
nance Without Compromising Session Consistency. In Database and
Expert Systems Applications, pages 776785, 1998.
[Var00] G. Vargas. Service dvenements exible pour lintgration dappli-
cations 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 Interna-
tional Conference on Scientic 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 Confe-
rence 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 Laye-
red Architecture for Uniform Version Management. Software Engi-
neering, 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.
[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 Co-
lours 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 mate-
rialized view selection in a data warehouse environment. IEEE Trans.
Systems, Man, Cybernetics, PART C, 31 :282294, September 2001.
Annexe A
Description des sources de donnes
Caractristiques du chier 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 transfor-
mation 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 chier :
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 sys-
tmatiquement renseignes. Ces informations sont dordre administratif et mdical.
Pour que les informations mdico-administratives contenues dans le RUM puissent
145
146 Description des sources de donnes
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 lalgo-
rithme 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 rali-
sation 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 dori-
gine 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 tablisse-
ment 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 chier 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 struc-
tures publiques ou prives :
Variable Type Taille Libell
FINESS Caractre 9 Numro FINESS de
lentit juridique
Champ 2 Caractre 3 N de version du
format du RSA (C05)
Champ 3 + numRSA Caractre 10 Clef de validation
Champ 5 Caractre 3 Numro de version du format
du "RSS-group" (ou du RSS) lu
Champ 6 Caractre 3 N de version de Genrsa
Champ 7 + cmd_ Caractre 9 Groupage lu sur le
tab + ghm_tab "RSS-group" : V,
+ Champ 10 CMD, GHM, code retour
Champ 11 + cmd + Caractre 9 Groupage obtenu
ghm + Champ14 par GENRSA : V,
CMD, GHM, code retour
Champ 15 Numrique 2 Nombre de RUM composant
le RSS dorigine
AGE_ANNEES Numrique 3 Age en annes
AGE_JOURS Caractre 3 Age en jours (si < 1 an)
calcul lentre
sexe Caractre 1 Sexe
Mode_ent Caractre 1 Mode dentre dans
le champ du PMSI
Provenan Caractre 1 Provenance (si le
mode dentre est
mutation ou transfert)
Mois_sor Caractre 2 Mois de sortie du champ PMSI
Anne_sor Caractre 4 Anne de sortie du champ PMSI
Mode_sor Caractre 1 Mode de sortie du champ PMSI
Destinat Caractre 1 Destination (si le
mode de sortie est
mutation ou transfert)
Type_sjour Caractre 1 Type de sjour
Nbre_rad Numrique 2 Nombre dactes de
radiothrapie
Nbre_dia Numrique 2 Nombre dactes de dialyse
Dure_se Numrique 3 Dure totale du sjour
dans le champ du PMSI
(vide si sances)
Tab. A.1 Description des variables du chier RSA
149
Champ 29 Caractre 3 Dure de la priode
sur laquelle stalent
les sances (si sances)
Code_geo Caractre 5 Code gographique de rsidence
Poids Numrique 4 Poids la naissance (en grammes)
Nbre_sea Numrique 2 Nombre de sances
Igs2 Caractre 3 IGS 2
Filler Caractre 8 Filler +
Champ 34 Caractre 1 Code de prise en charge *
Champ 35 Caractre 1 Facture associe 0 franc *
Champ 36 Caractre 6 Zone rserve *
Diag_pri Caractre 6 Diagnostic principal (DP)
Diag_rel Caractre 6 Diagnostic reli (DR)
Nbre_di1 Numrique 2 Nombre de diagnostics
associs (Nd) dans ce RSA
Nbre_act Numrique 2 Nombre dactes (Na) dans ce RSA
Tab. A.2 Description de variables du chier RSA
Les structures sanitaires : structures hospitalires, autres centres de soins, labo-
ratoires 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 Dpartemen-
tale 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 Statis-
tiques (DREES) - Unit Rpertoires - Ministre de lEmploi et de la Solidarit, en
liaison avec les services dconcentrs de lEtat (DDASS, DRASS).
Description des variables du chier :
Fichier FINESS : Fichier National des Etablissements Sanitaires et Sociaux.
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 implanta-
tions 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 at-
tribu un numro FINESS 9 chires dont les 2 premiers correspondent au numro
de dpartement dimplantation. Ce numro est un numro de rfrence en parti-
culier pour la facturation hospitalire et la liquidation de scurit sociale. Rien ne
distingue, dans la constitution du numro, un numro dentit juridique dun nu-
mro 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 pluridiscipli-
narit 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 lac-
tivit 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, ac-
cueil temporaire, ducation. Dans le domaine sanitaire, certaines autorisations sont
faites par Grands Groupes de Disciplines GGDE qui sont des regroupements de dis-
ciplines. 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 den-
seignement.
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 re-
levant 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 :
Adresse Char 35 Adresse de ltablissement
Adressepublic Char 25 Adresse de ltablissement
Capaciteautorisee1 Num 8 capacit autorise en nombre de lits
Capacitemiseenoeuvre1 Num 8 capacit observe en nombre de lits
Tab. A.3 Description de variables du chier FINESS
Code1 Num 8 Code de la discipline
CodePSPH Num 8 Code de Part. au Serv. Pub. Hosp.
Codecategorie Num 8 Code lactivit de ltab.
Codepostal Num 8 Code postal
Codepostalpublic Char 5 Code postal public
Codestatut Num 8 Code le statut de ltab.
Codetarif Num 8 Code de lautorit xant le tarif
Compldistrpublic Char 20 Complment de distribution public
Complementdistribution Char 35 Complment de distribution
Dateouvert Char 20 Date douverture
FINESSjuridique Char 9 Numro FINESS juridique
Fax Char 15 Numro Fax
Faxpublic Char 15 Numro Fax public
GGDE1 Char 20 Grands Groupe de Discipline 1
LibPSPH Char 20 Libell de Part. au Serv. Pub. Hosp.
Libcategorie Char 25 Libell de la catgorie
Libelleroutage Char 30 Libelle du routage
Libstatut Char 25 Libell du statut
Libtarif Char 20 Libell de lautorit xant le tarif
LieuditBP Char 35 Lieudit BP
LieuditBPpublic Char 10 Lieudit BP public
NumeroFINESS Char 9 Numro FINESS
Raisonsociale Char 65 Nom de ltablissement
Routagepublic Char 20 Routage public
SIRET Char 20 Numro SIRET
Tel Char 15 Numro Tlphone
Telpublic Char 15 Numro Tlphone public
Tab. A.4 Description de variables du chier FINESS

These

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

These

Загружено:

Авторское право:

Доступные форматы

UNIVERSIT JOSEPH FOURIER

{t} contenant le domaine de chaque type atomique plus la valeur distingue t.

D1, ..., Dn comme Dpartements

R1, ..., Rn comme Rgions

H, P, E, A comme les saisons (Hiver, Printemps, Et, Automne)

Вам также может понравиться