Entrepôts de Données Pour L'aide À La Decision Medicale

UNIVERSIT JOSEPH FOURIER
THSE pour obtenir le grade de Docteur de lUniversit Joseph Fourier

Spcialit : Informatique prpare au laboratoire LSR IMAG dans le cadre de lcole Doctorale Mathmatiques, Sciences et Technologies de lInformation
prsente et soutenue publiquement par
Mara Trinidad Serna Encinas

Le 27 Juin 2005
Entrepts de donnes pour laide la dcision mdicale : conception et exprimentation

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

1 Introduction 1.1 Les entrepts de donnes pour laide la dcision . . . . . . . . . . . 1.2 Le projet ADELEM : Aide la Dcision Logistique et Mdicale . . . 1.3 Problmatique et objectif de la thse . . . . . . . . . . . . . . . . . . 1.3.1 Conception dun systme pour le dcisionnel . . . . . . . . . . 1.3.2 Slection des vues matrialiser . . . . . . . . . . . . . . . . . 1.3.3 Gestion de lvolution des entrepts . . . . . . . . . . . . . . . 1.3.4 Objectif de la thse . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Dmarche et contribution . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1 Mtamodle multidimensionnel . . . . . . . . . . . . . . . . . 1.4.2 Algorithme pour la slection des vues matrialiser . . . . . . 1.4.3 Interface pour la gnration (semi-automatique) des indicateurs 1.4.4 Versions de schmas bitemporels . . . . . . . . . . . . . . . . . 1.5 Plan de la thse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Entrepts de donnes multidimensionnelles et aspects temporels 2.1 Entrepts de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Architecture dun entrept de donnes . . . . . . . . . . . . . 2.1.2 Entrepts et les bases de donnes . . . . . . . . . . . . . . . . 2.2 Modlisation multidimensionnelle . . . . . . . . . . . . . . . . . . . . 2.2.1 Schmas relationnels . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Schma multidimensionnel (Cube) . . . . . . . . . . . . . . . . 2.3 Manipulation des donnes multidimensionnelles . . . . . . . . . . . . 2.3.1 Oprations classiques . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Oprations agissant sur la structure . . . . . . . . . . . . . . . 2.3.3 Oprations agissant sur la granularit . . . . . . . . . . . . . . 2.4 Serveurs OLAP (On-Line Analytical Processing) . . . . . . . . . . . . 2.4.1 ROLAP (Relational OLAP) . . . . . . . . . . . . . . . . . . . 2.4.2 MOLAP (Multidimensional OLAP) . . . . . . . . . . . . . . . 2.4.3 HOLAP (Hybrid OLAP) . . . . . . . . . . . . . . . . . . . . . 2.5 Les projets de recherche . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1 WHIPS Warehouse Information Prototype at Stanford . . . . . 2.5.2 SIRIUS Supporting the Incremental Refreshment of Information warehouses . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.3 DWQ Foundations of Data Warehouse Quality . . . . . . . . . i 1 2 3 6 6 8 9 10 10 10 11 11 11 12 15 15 15 17 18 20 22 23 23 24 27 27 28 30 32 34 34 35 35
ii 2.5.4 Projet EVOLUTION . . . . . . . . . . . . . . . . . . Aspects temporels des entrepts . . . . . . . . . . . . . . . . 2.6.1 Etat courant des versions . . . . . . . . . . . . . . . . 2.6.2 Espace de versions . . . . . . . . . . . . . . . . . . . 2.6.3 Versions bases sur ltat et sur les changements . . . 2.6.4 Graphes de version . . . . . . . . . . . . . . . . . . . 2.6.5 Gestion de versions extensionnelles et intensionnelles 2.6.6 Oprations primitives . . . . . . . . . . . . . . . . . . Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 37 38 43 44 45 46 47 47 49 50 50 51 51 51 52 53 53 54 59 59 61 62 63 63 64 65 65 66 67 70 71 72 75 76 76 77 79 80 84 88
2.6
2.7
3 Architecture et modle pour un entrept de donnes mdicales 3.1 Architecture dun systme dcisionnel . . . . . . . . . . . . . . . . . . 3.1.1 Interface graphique pour la Gnration (Semi - automatique) dIndicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Entrept de donnes . . . . . . . . . . . . . . . . . . . . . . . 3.1.3 Gestionnaire dEvolution . . . . . . . . . . . . . . . . . . . . . 3.2 Mtamodle Multidimensionnel . . . . . . . . . . . . . . . . . . . . . 3.2.1 Relations entre les mtaclasses . . . . . . . . . . . . . . . . . . 3.2.2 Contraintes entre les mtaclasses . . . . . . . . . . . . . . . . 3.2.3 Description des Mtaclasses . . . . . . . . . . . . . . . . . . . 3.2.4 Dnition dun modle multidimensionnel . . . . . . . . . . . 3.3 Analyse des donnes dune application mdicale . . . . . . . . . . . . 3.3.1 Sources de donnes . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Analyse des donnes . . . . . . . . . . . . . . . . . . . . . . . 3.4 Classication des indicateurs du projet . . . . . . . . . . . . . . . . . 3.4.1 Indicateurs dore (gographiques - spatio-temporels) . . . . . 3.4.2 Indicateurs de consommation, de besoins et de ux (temporels) 3.4.3 Nouveaux indicateurs de consommation et de ux (temporels) 3.5 Application du modle multidimensionnel dans le cadre du projet . . 3.5.1 Schma en constellation pour ADELEM . . . . . . . . . . . . 3.5.2 Hirarchies du schma . . . . . . . . . . . . . . . . . . . . . . 3.5.3 Description du schma Prise_MCO et de ses dimensions . . . . 3.5.4 Description du schma Population et de ses dimensions . . . . 3.5.5 Description du schma Prise_SSR et de ses dimensions . . . . 3.6 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Systme daide la dcision mdicale : une exprimentation 4.1 Construction du schma . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Schma en toile Adelem_MCO . . . . . . . . . . . . . . . . . . 4.1.2 Matrialisation de lHypercube . . . . . . . . . . . . . . . . 4.2 Vues matrialises . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Slection des vues matrialiser . . . . . . . . . . . . . . . . 4.2.2 Algorithme propos pour la slection des vues matrialiser 4.2.3 Gnration des vues matrialises . . . . . . . . . . . . . . . . . . . . . .
iii 4.3 Interface graphique pour la Gnration (semi-automatique) dIndicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Architecture pour linterface graphique . . . . . . . . . . . . 4.3.2 Fonctionnement de linterface . . . . . . . . . . . . . . . . . 4.3.3 Types de requtes excuter . . . . . . . . . . . . . . . . . . 4.3.4 Fonctionnement de linterface graphique . . . . . . . . . . . Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4
. . . . . .
90 91 92 94 95 98
5 Aspects temporels et versions de schmas dans les entrepts 5.1 Versions de schmas . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Versions de schmas annuels dans un contexte mdical . 5.1.2 Reprsentation bitemporelle des versions de schmas . . 5.2 Les oprations primitives . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Ensemble de primitives . . . . . . . . . . . . . . . . . . . 5.2.2 Ensemble de restrictions . . . . . . . . . . . . . . . . . . 5.3 Dnition formelle des primitives . . . . . . . . . . . . . . . . . 5.3.1 Gestion de la relation (cube, dimension ou hirarchie) . . 5.3.2 Gestion des versions . . . . . . . . . . . . . . . . . . . . 5.4 Gestion temporelle des entrepts . . . . . . . . . . . . . . . . . 5.4.1 Architecture simplie du projet . . . . . . . . . . . . . . 5.4.2 Modle de versions de schmas bitemporels . . . . . . . . 5.4.3 Gestionnaire dvolution de schmas . . . . . . . . . . . 5.5 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Conclusions et perspectives 6.1 Bilan du travail ralis . . . . . . . . . . . . . . . . . . . . 6.1.1 Principales contributions . . . . . . . . . . . . . . . 6.1.2 Dnition dun modle multidimensionnel . . . . . 6.1.3 Algorithme pour la slection des vues matrialiser 6.1.4 Gnration (semi-automatique) des requtes . . . . 6.1.5 Versions de schmas bitemporels . . . . . . . . . . . 6.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Extension du prototype . . . . . . . . . . . . . . . 6.2.2 Aspects spatiaux des donnes . . . . . . . . . . . . 6.2.3 Construction et rafrachissement de donnes . . . . 6.2.4 Grille de donnes . . . . . . . . . . . . . . . . . . . A Description des sources de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
101 . 102 . 102 . 103 . 105 . 105 . 105 . 107 . 108 . 115 . 116 . 117 . 117 . 119 . 122 125 . 125 . 125 . 125 . 126 . 127 . 127 . 128 . 128 . 129 . 131 . 132 145
iv
Table des gures

1.1 1.2 1.3 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 Architecture gnrale dun systme dcisionnel . . . . . . . . . . . . . Tous les tablissements au niveau national . . . . . . . . . . . . . . . Gestion de lvolution du schma dans un entrept . . . . . . . . . . Architecture dun entrept de donnes . . . Exemple de modlisation en toile. . . . . . Exemple de modlisation en ocon de neige. Exemple de modlisation en constellation. . Exemple de schma multidimensionnel. . . . Exemple de lopration Jointure. . . . . . . . Architecture ROLAP. . . . . . . . . . . . . . Architecture MOLAP. . . . . . . . . . . . . Architecture HOLAP. . . . . . . . . . . . . . Espace des changements . . . . . . . . . . . Graphes de version un niveau . . . . . . . Graphe de version deux niveaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5 9 16 20 21 22 23 25 29 30 33 44 45 46 50 52 56 58 66 67 68 70 71
3.1 Architecture propose dun systme dcisionnel . . . . . 3.2 Mtamodle Multidimensionnel . . . . . . . . . . . . . . 3.3 Schma et une instance possible du Cube . . . . . . . . . 3.4 Schma et une instance possible de la hirarchie H_Geo 3.5 Schma en Constellation pour ADELEM . . . . . . . . . 3.6 Hirarchies de la dimension x . . . . . . . . . . . . . . . 3.7 Schma en ocon de neige Prise_MCO . . . . . . . . . . . 3.8 Schma en ocon de neige Population . . . . . . . . . . . 3.9 Schma en ocon de neige Prise_SSR . . . . . . . . . . . 4.1 Schma en toile Adelem_MCO . . . . . . . . . . . 4.2 Hypercube avec le cot de calcul ( gauche) et le droite) de chaque noeud (vue) . . . . . . . . . . 4.3 Algorithme Greedy [HRU95] . . . . . . . . . . . 4.4 Ensemble ordonn des vues slectionnes . . . . 4.5 Algorithme propos . . . . . . . . . . . . . . . . 4.6 Ensemble ordonn des vues slectionnes . . . . 4.7 Architecture pour linterface graphique . . . . . 4.8 Cration dune dimension . . . . . . . . . . . . v
. . . . . . . . . . . cot de stockage ( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 76 . . . . . . . 79 82 83 86 87 91 93
vi 4.9 4.10 4.11 4.12 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 6.1 6.2 Structure de la dimension . . . . . . . . . . . . . . . . . . . . Interface pour la gnration (semi-automatique) dindicateurs Rsultat de lexcution de la requte Q4 . . . . . . . . . . . . Fichier Requete.REL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 96 97 98 102 103 113 114 117 118 120 120
Trois versions de schmas annuels. . . . . . . . . . . . . . . . . . . Reprsentation bitemporelle des versions de schmas. . . . . . . . Insertion du niveau District la Hirarchie H_Geo. . . . . . . . Rsultat dliminer le niveau Departement la Hirarchie H_Geo. Interaction des composants lintrieur de larchitecture. . . . . . Modle de versions de schmas bitemporels. . . . . . . . . . . . . Gestionnaire dvolution de schmas. . . . . . . . . . . . . . . . . Gestion dvolution de schmas par niveau. . . . . . . . . . . . . .
Reprsentation du mode vecteur et rasteur . . . . . . . . . . . . . . . 131 Architecture des systmes pour lintgration de donnes . . . . . . . . 132
Liste des tableaux

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 3.1 3.2 4.1 4.2 4.3 4.4 4.5 5.1 5.2 A.1 A.2 A.3 A.4 Dirences entre SGBD et entrepts de Comparaison des systmes . . . . . . . Ventes par magasin . . . . . . . . . . . Prix des produits . . . . . . . . . . . . Ventes de produits par ville 1 . . . . . Ventes de produits par ville 2 . . . . . Ventes du Dpartement Isre . . . . . . Table de ventes du Magasin 1 . . . . . Table de ventes du Magasin 2 . . . . . Table de ventes du Magasin 3 . . . . . Exemple de relation bitemporelle . . . donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 19 24 24 25 25 25 26 26 26 42
Description des sources de donnes . . . . . . . . . . . . . . . . . . . 61 Caractristiques des sources de donnes historiques . . . . . . . . . . 62 Liste de relations de base . . . . . . . . . . . . . . . . . . . Matrialisation complte de lhypercube . . . . . . . . . . Application de lalgorithme Greedy aux donnes ADELEM Application de notre algorithme aux donnes ADELEM . . Ensemble minimal des vues matrialiser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 78 82 86 88
Primitives pour la gestion de relation . . . . . . . . . . . . . . . . . . 106 Primitives pour la gestion des versions . . . . . . . . . . . . . . . . . 106 Description Description Description Description des variables du chier RSA . de variables du chier RSA . . de variables du chier FINESS de variables du chier FINESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 149 151 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 lintgration des donnes, de manire quelles soient de qualit pour leur stockage. Pour lorganisation, ils existent plusieurs problmes comme : la slection des vues matrialiser, le rafrachissement de lentrept, la gestion de lensemble de donnes (courantes et historises), entre autres. En ce qui concerne le processus dinterrogation, nous avons besoin des outils performants et conviviaux pour laccs et lanalyse de linformation. Notre travail se focalise principalement sur les deux dernires tapes, ainsi, pour le processus dorganisation, nous proposons la dnition dun modle multidimensionnel, un algorithme pour la slection optimale des vues matrialiser et lutilisation des versions de schmas bitemporels pour la gestion des aspects temporels des entrepts. Pour linterrogation, nous avons dvelopp une interface graphique qui permet la gnration semi-automatique des indicateurs. Dans les chapitres suivants, nous dployons chacune de nos propositions. Cette thse a eu pour cadre un projet mdical. Ainsi, dans ce chapitre nous prsentons dabord une introduction des entrepts dans le milieu mdical et un rsum du projet ADELEM (Aide la Dcision Logistique et Mdical). Ensuite, nous prsentons la problmatique et lobjectif de la thse et pour nir, nous exposons la dmarche suivie et notre contribution. 1
Introduction
1.1
Les entrepts de donnes pour laide la dcision
La dnition classique dun entrept donne par [IH94] : "Un Entrept de Donnes est une collection de donnes orientes sujet, intgres, non volatiles et historises, organises pour le support dun processus daide la dcision". Nous dtaillons ces caractristiques [Fra97, DG01] : orientes sujet : Les donnes des entrepts sont organises par sujet plutt que par application. Par exemple, une chane de magasins dalimentation organise les donnes de son entrept par rapport aux ventes qui ont t ralises par produit et par magasin, au cours dun certain temps. intgres : Les donnes provenant des direntes sources doivent tre intgres, avant leur stockage dans lentrept de donnes. Lintgration (mise en correspondance des formats, par exemple), permet davoir une cohrence de linformation. non volatiles : A la dirence des donnes oprationnelles, celles de lentrept sont permanentes et ne peuvent pas tre modies. Le rafrachissement de lentrept, consiste ajouter de nouvelles donnes, sans modier ou perdre celles qui existent. historises : La prise en compte de lvolution des donnes est essentielle pour la prise de dcision qui, par exemple, utilise des techniques de prdiction en sappuyant sur les volutions passes pour prvoir les volutions futures. La construction dun entrept revient faire correspondre les besoins des utilisateurs avec la ralit des informations disponibles. Nous devons dabord identier et analyser les sources de donnes, ce qui nous permet de proposer les mcanismes adapts selon les caractristiques des informations. Ensuite, nous devons organiser lensemble de donnes lintrieur de lentrept. Pour cela, nous devons dabord structurer ces informations en considrant leur granularit. Ceci nous permet daboutir la conception dun schma multidimensionnel qui permet de rpondre aux besoins des utilisateurs. La gure 1.1 montre une architecture gnrale dun systme dcisionnel qui se compose de trois processus : extraction-intgration, organisation et interrogation. Nous trouvons le processus dextraction-intgration entre les sources de donnes et lentrept. Ce processus est responsable de lidentication des donnes dans les diverses sources internes et externes ; de lextraction de linformation qui nous intresse et de la prparation et de la transformation (nettoyage, ltrage,...) des donnes.
1.2 Le projet ADELEM : Aide la Dcision Logistique et Mdicale
E X T R A C T I O N
O R G A N I S A T I O N
Sources de donnes
Entrept de donnes
I N T E R R O G A T I O N
Outils
Fig. 1.1 Architecture gnrale dun systme dcisionnel
A lintrieur de lentrept, nous trouvons le processus dorganisation, il est responsable de structurer les donnes par rapport leur niveau de granularit (agrgats). Finalement, le troisime processus correspond linterrogation qui se place entre lentrept et les dirents outils pour arriver lanalyse des donnes, pour les dirents utilisateurs de lentreprise. Malgr une conception attentive et soigneuse, la structure dune base de donnes est sujette de nombreux changements. Bien que les estimations dirent, la plupart saccordent sur le fait que plus de 50% du travail des dveloppeurs se focalise sur les modications du systme aprs leur implantation [Rod95]. Ces changements peuvent aecter aussi bien les donnes que leur structure. En eet, lvolution dun schma concerne tout le cycle de vie dun entrept de donnes. Un de premiers travaux dans ce contexte est [HMV99a, HMV99b], o les auteurs proposent des oprateurs pour lvolution des dimensions.
1.2
Le projet ADELEM : Aide la Dcision Logistique et Mdicale
Cette thse a eu pour cadre le projet ADELEM1 qui consiste en la mise au point doutils logiciels ncessaires laide la dcision logistique et mdicale, dans le cadre des SROS (Schmas dOrganisation Sanitaire et Sociale) grs par les ARH (Agences Rgionales dHospitalisation). Dans le systme de soins dune rgion, ces agences sont charges de rpartir de manire optimale les moyens mdicaux (l"ore") en fonction des besoins sanitaires (la "demande"). A partir des observations de sant constituant linformation primaire, essentiellement contenue dans les donnes PMSI (Programme de Mdicalisation du Systme dInformation des hpitaux) [PMS04], il
1
Action Concerte Incitative "Technologies pour la Sant". Projet ADELEM. 2001
Introduction
est ncessaire de mettre au point des outils logiciels danalyse et de visualisation. Ce projet est trait par une quipe interdisciplinaire compose de : - Le Laboratoire TIMC IMAG, UMR CNRS 5525. - Le Laboratoire de Biomtrie et Biologie volutive (UMR CNRS 5558) qui fournit lanalyse statistique des donnes mdicales. - LOrganisation Mondiale de la Sant (bas en Suisse) qui a dvelopp le logiciel HealthMapper pour la cration et la manipulation des donnes gographiques. - Notre quipe du Laboratoire LSR IMAG, UMR CNRS 5526 qui fournit le support pour les bases de donnes et les entrepts. Objectif du projet : La rpartition de lore de soins (nombre de lits par spcialit, plateaux techniques) doit sadapter rgulirement lvolution de la demande (volution des pathologies ncessitant une prise en charge hospitalire, de la structure dge et de limplantation gographique de la population), et de lore de soins (volution des techniques et de lorganisation du systme de sant, telles que rseau et tl-mdecine). Le projet consiste donc en la mise au point dun outil de modlisation-simulation partir des donnes du PMSI et des donnes de lINSEE (Institut National de la Statistique et des Etudes Economiques) [INS05] pour aider les gestionnaires du systme de sant dans leur dmarche de prise de dcision. Sources de donnes relles : Nous avons trois types de sources : gographiques, dmographiques et les donnes publiques concernant la sant. Elles sont rparties, htrognes et certaines dentre elles sont externes au domaine mdical proprement dit. En ce qui concerne les donnes gographiques, lquipe de Service de Biostatistique Lyon sest focalis sur la visualisation (reprsentation cartographique) de lore et de la consommation de soins. Ainsi, dans la suite, nous dcrivons ce travail. Description de lactivit de lquipe de Lyon (Service de Biostatistique) Ils ont abouti au dveloppement dun logiciel de cartographie de lore et de la demande de soins hospitaliers en France. Dans cette version initiale, ils se sont intresss lore et la demande de soins, aux besoins et aux ux mais pas la comparaison sur une mme carte de lore et de la consommation (ratios) qui ncessite de dnir un maillage gographique commun. Ainsi les reprsentations graphiques de lore et de la demande se feront sur des fonds de cartes dirents. En eet,
1.2 Le projet ADELEM : Aide la Dcision Logistique et Mdicale
les renseignements sur lorigine gographique des patients pour la consommation de soin sont bass sur les codes postaux et non pas le code INSEE de la commune de rsidence du patient [Bel02]. La carte de France se dcompose en quatre niveaux administratifs : la commune, le canton, le dpartement et la rgion. Il existe une hirarchie entre ces niveaux : la commune est incluse dans le canton, lui-mme est inclus dans le dpartement, et celui-ci appartient une rgion. Nanmoins, nous ne disposons pas encore de la correspondance entre les communes et les cantons au niveau national (chier de lIntitut de Gographie National). Ainsi, dans cette version 0, la France se compose de trois niveaux administratifs : - niveau 1 correspondant Admin1 : rgion - niveau 2 correspondant Admin2 : dpartement - niveau 3 correspondant Admin3 : commune Pour la cration du logiciel, ils ont utilis le systme HealthMapper (logiciel de cartographie). Il se base sur un gestionnaire de donnes qui permet de combiner les informations gographiques et pidmiologiques. Le nombre dindicateurs prvus pour cette version 0 est limit 2 pour la visualisation de lore et de la consommation de soins. Cette version permet de reprsenter tous les tablissements de courts sjours au niveau national ainsi que le nombre de lits de chaque tablissement hospitalier. Pour ce dernier, la gure 1.2 montre la carte obtenue.
Fig. 1.2 Tous les tablissements au niveau national
Introduction
1.3
Problmatique et objectif de la thse
Les entrepts de donnes ont t conus pour laide la dcision. Ils intgrent les informations en provenance des dirents systmes transactionnels de lentreprise. Lensemble des donnes, y compris leur historique, est utilis pour faire des calculs prvisionnels, des statistiques ou pour tablir des stratgies de dveloppement et danalyses des tendances. Dans le cadre du projet ADELEM, nous nous proposons dadapter notre savoirfaire au problme de la gestion de donnes mdicales qui constituent un cadre applicatif particulirement intressant. En eet, ces donnes se trouvent rparties dans plusieurs sources quil faut, dans un premier temps, fdrer pour constituer un entrept de donnes pertinentes pour lapplication vise. Cette tape est importante car elle doit non seulement identier les sources, mais aussi dterminer comment extraire de ces sources les donnes dsires. Nous devons dterminer si les donnes doivent tre extraites telles quelles ou bien sil faut les traiter au pralable en leur appliquant des fonctions spciques comme des agrgats, des sommes, ... En plus, nous devons tablir un mcanisme pour la gestion de lvolution. Dans ce cas, il faut dterminer ladaptation au niveau : de lapplication dextraction, des agrgats et de lapplication danalyse. Cette problmatique est gnrale la constitution de tout entrept mais nous devons ici tenir compte de la nature particulire des donnes sur lesquelles portent ltude : type, format, smantique, condentialit, degr de abilit et de conance, informations manquantes ou incompltes, ... En rsum, il sagit de constituer un entrept qui contient des donnes pertinentes et de qualit sur lesquelles sera bas loutil dinterrogation et le processus daide la dcision. Prcedemment, nous avons dit que notre travail sencadre principalement aux tapes dorganisation et dinterrogation. Pour cela, nous nous sommes focaliss sur les problmatiques suivantes : la conception dun entrept de donnes, la slection des vues matrialiser et la gestion de lvolution. Ainsi, nous traitons dabord ces sujets et nous terminons avec lobjectif de notre thse.
1.3.1
Conception dun systme pour le dcisionnel
La conception et la construction dun entrept de donnes est une tche complexe et dlicate. Dans [Kim96, KR03], nous trouvons une mthodologie descendante pour la conception dun entrept. Elle se compose de neuf dcisions majeures qui sont la base dune conception complte. Les cinq premires portent sur la structure logique, tandis que les autres quatre traitent sur la structure physique. 1) Lidentication des tables de faits. 2) Le niveau de granularit de chaque table de faits. 3) Les dimensions appartenant la table de faits.
1.3 Problmatique et objectif de la thse
4) Lensemble de mesures. 5) Les attributs des dimensions avec des descriptions compltes. 6) La gestion de lvolution. 7) La dnition des agrgats, des dimensions dgnres et des dimensions htrognes. 8) Ltendue historique des donnes. 9) La priodicit des mises jour. Nous donnons une description de ces dcisions : A partir de lanalyse des sources de donnes existantes et rellement utilises, nous pouvons aboutir aussi bien lidentication des tables de faits, qui reprsentent le sujet danalyse, qu son niveau de granularit. Lorsque le grain de la table de faits est connu, les dimensions peuvent tre identies. Le choix des dimensions est le point cl de la conception, car elles modlisent les perspectives de lanalyse. Une fois les dimensions choisies, nous dnissons lensemble de mesures, qui reprsentent les direntes valeurs de lactivit analyse. Nous devons aussi enregistrer pour chaque dimension lensemble des attributs textuels. Les attributs peuvent tre utiliss comme source de restrictions dans une requte. Pour la gestion de lvolution lintrieur des dimensions, Kimball [Kim96] propose trois solutions qui assurent un suivi des modications dans le temps : 1) Remplacer des valeurs anciennes par des nouvelles dans lenregistrement de la dimension, nanmoins, nous perdons la possibilit de suivre les vnements passs. 2) Crer des nouveaux enregistrements de dimension lors du changement qui contiennent les nouvelles valeurs de lattribut. Ceci quivaut segmenter lhistorique selon lancienne et la nouvelle description. 3) Crer des nouveaux champs "actuels" lintrieur de lenregistrement dorigine de la dimension, tout en conservant en mme temps les premires valeurs enregistres. Dans ce cas, nous pouvons garder seulement la valeur originale et la courante de lattribut modi. Les valeurs intermdiaires sont perdues. Une dimension qui contient un seul attribut reprsente une dimension dgnre. De cette manire, nous gardons lattribut (la cl de la dimension) lintrieur de la table de faits. Nous dcrirons une dimension htrogne en utilisant un exemple. Une compagnie dassurances a en gnral des domaines dactivit trs direncis. Il y a par exemple : les risques habitation, les risques automobiles, les risques objets personnels, la responsabilit civile, ..., o chaque domaine est reprsent par des attributs particuliers. Nous identions deux dimensions : une pour le bien assur et une autre
Introduction
pour le risque couvert. Nanmoins, la dimension Bien_assure contient lensemble dattributs des produits htrognes (habitation, automobile, ...) ce qui fait delle une dimension htrogne. Kimball propose de faire des dimensions particularises, ce qui signie de faire des "copies" de la dimension Bien_assure pour chaque domaine dactivit, ainsi, pour chaque type de risque couvert nous crons des dimensions particularises pour Bien_assure et pour Risque_couvert. Finalement, nous devons tablir le priode des donnes historises ainsi que la frquence des mises jour. Cette dernire peut tre journalire, hebdomadaire, mensuelle,...
1.3.2
Slection des vues matrialiser
La slection de lensemble optimal des vues matrialiser fait partie du processus dorganisation et elle reprsente une tche essentielle dans la conception dun entrept. La matrialisation nous permet doptimiser lexcution dune requte, pour cela, nous avons les possibilits suivantes : La matrialisation complte : Cette approche donne le meilleur temps de rponse de la requte. Nanmoins, la matrialisation complte nest pas faisable, due principalement au cot de stockage lev. Pas de matrialisation : Dans ce cas, nous navons pas besoin de stockage supplmentaire. Cependant, pour rpondre chaque requte, nous devons chercher linformation au niveau plus bas de granularit (i.e., raw data). Ainsi, nous avons le problme dun cot de calcul trs lev pour chaque requte. La matrialisation partielle : Dans cette approche, le problme se rduit dterminer le nombre optimal de vues matrialiser, en considrant leur cot de stockage, de maintenance, ... Il est vident que la dernire approche est la plus intressante. Elle fait lobjet de plusieurs recherches qui ont pour objectif daboutir la dnition dun mcanisme pour la slection dun ensemble optimal des vues matrialiser. La plupart des travaux utilisent un modle de cot mais qui a t adapt avec linclusion de certains paramtres, tels que : la frquence de la requte, la frquence des mises jour sur les relations de base, le cot de maintenance, entre autres. Pour nir, nous voulons faire une remarque. Quand nous parlons de la possibilit de rien matrialiser, nous nous rfrons au fait que nous ne considrons pas les donnes du niveau plus bas comme des donnes matrialises. En eet, certains dentre nous visualisent les donnes de dtail de lentrept comme une sorte de matrialisation de linformation qui se trouve dans les sources de donnes. Nanmoins, pour nous, ces donnes une fois intgres et stockes dans lentrept, reprsentent
1.3 Problmatique et objectif de la thse
lensemble de relations de base partir desquelles nous slectionnerons les vues matrialiser.
1.3.3
Gestion de lvolution des entrepts
Le problme dvolution de schma apparat quand un changement au schma dune base de donnes modie lensemble de vues dnies sur ce schma. Par exemple : Supposons que S1 reprsente un schma et V1 lensemble de vues sur S1 . Si nous avons une nouvelle version de schma S2 partir de S1 , le problme est la dnition de la nouvelle version V2 qui soit cohrente avec S2 [Ber03]. Lvolution dun schma a des consquences sur lapplication charge de lextraction et lintgration de donnes des sources, car elle peut devenir incomplte ou incohrente vis--vis du nouveau schma de lentrept. Cette volution entrane aussi ladaptation des agrgats pr-calculs et ladaptation du processus de maintenance. La gure 1.3 montre les adaptations ncessaires aprs quune volution du schma a eu lieu dans un entrept de donnes.
Adaptation de lapplication dextraction
Adaptation des agrgats
Adaptation de lapplication danalyse
E X T R A C T I O N
O R G A N I S A T I O N
Sources de donnes
Entrept de donnes
I N T E R R O G A T I O N
Outils
Fig. 1.3 Gestion de lvolution du schma dans un entrept Pour rsoudre le problme de perte de donnes aprs des changements du schma, le concept dvolution de schma t introduit pour rcuprer les donnes existantes par le biais de leur adaptation au nouveau schma. Nanmoins, dans les systmes qui doivent grer des donnes historiques, lvolution de schma nest pas susante et la maintenance de plusieurs schmas est requise [GM02]. Ainsi, pour grer ces changements, nous pouvons utiliser soit lvolution de schmas soit les versions de schmas. Nous devons choisir la technique utiliser par rapport aux caractristiques de lapplication cible.
10
Introduction
1.3.4
Objectif de la thse
Notre objectif consiste la conception et mise en oeuvre dun entrept de donnes pour laide la dcision. Pour faire cela, nous proposons : - La dnition dun mtamodle multidimensionnel qui se compose de trois classes : Cube, Dimension et Hirarchie. - Un algorithme pour la slection de lensemble optimal des vues matrialiser. - Une interface graphique pour la gnration (semi-automatique) des requtes. - Les versions de schmas bitemporels pour la gestion de lvolution dun entrept.
1.4
Dmarche et contribution
Notre travail se focalise sur les processus dorganisation et dinterrogation. Nous reprenons les propositions numres prcdemment et nous donnons une description de chacune delles.
1.4.1
Mtamodle multidimensionnel
Pour le mtamodle, nous avons spci trois mtaclasses : Cube, Dimension et Hirarchie. Nous avons propos les dnitions pour chaque mtaclasse et leurs instances, ainsi quune dnition dune base de donnes multidimensionnelle et de son instance. Ceci nous a permis daboutir la conception dun modle multidimensionnel qui se compose dun ensemble de classes contenant des proprits, des relations et des contraintes entre les classes. Nous distinguons les termes de dimension et de hirarchie avec les caractristiques suivantes : - Une dimension peut contenir zro, une ou plusieurs hirarchies. Une instance de hirarchie ne peut pas relier linstance du cube auquel est associe linstance de la dimension contenant cette hirarchie. Nanmoins, elle peut relier une instance dun autre cube et ceci en raison de la granularit associe chaque hirarchie. - Nous pouvons insrer un niveau de hirarchie soit ct de la hirarchie dj dnie soit lintrieur. - Nous considrons le cas o nous avons seulement deux niveaux de hirarchie. Nous avons conu un schma en constellation pour le projet ADELEM et nous avons donn une description de ce schma en utilisant notre mtamodle.
1.4 Dmarche et contribution
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 indicateurs
Lobjectif de notre interface est de faciliter la tche de cration dindicateurs pour les utilisateurs. Nous avons dvelopp les composants suivants : - Un module pour la cration et/ou la modication du schma. - Un module pour la gnration de requtes de manire quasi-automatique. Nous avons construit le schma en toile Adelem_MCO et nous avons cre la base de donnes correspondante en utilisant un chantillon de 10% des donnes relles du projet ADELEM. Ceci nous a permis de vrier et de prouver notre interface graphique, de cette manire, la requte SQL gnre sexcute sur les donnes mdicales et le rsultat est prsent sur linterface.
1.4.4
Versions de schmas bitemporels
Nous proposons lutilisation des versions de schmas bitemporels pour la gestion, le stockage et la visualisation des donnes historises intensionnelles et extensionnelles. Dans ce cas, nous devons grer la combinaison du temps de transaction et du temps de validit dans notre modle de versions. Nanmoins, la gestion des versions est une tche complexe et elle prsente plusieurs problmes. Le principal, notre connaissance, est lexplosion des versions, ainsi, nous devons tablir un mcanisme pour contrler cette explosion. Notre proposition considre : - Un oprateur appel SetVersion qui permet dappliquer un ensemble de changements sur une version et de gnrer une nouvelle version.
12
Introduction
- Un ensemble de 19 primitives ncessaires pour la gestion des cubes, des dimensions et des hirarchies. - Un ensemble de 5 primitives qui agissent sur les versions de schmas. - Un gestionnaire dvolution responsable de la manipulation des direntes versions de schmas historises.
1.5
Plan de la thse
Nous prsentons ici lorganisation du document. Le chapitre 2 fait un tat de lart des entrepts de donnes dans le contexte o nous nous plaons. Nous prsentons larchitecture dun entrept et ses composants, les dirents modles multidimensionnels pour la construction dun systme dcisionnel, ainsi que lensemble des oprations pour la manipulation des donnes multidimensionnelles. Nous dcrivons les serveurs dcisionnels : ROLAP, MOLAP et HOLAP. Dans la dernire partie, nous prsentons lapproche des versions de schma. Nous prsentons dabord ltat courant des versions dans les modles de donnes existants. Ensuite nous dcrivons lespace de versions, leurs types, la gestion de donnes extensionnelles et intensionnelles, ainsi que les oprations primitives utiliser. Le chapitre 3 prsente larchitecture conue pour un systme dcisionnel dans le domaine mdical. Elle est base sur trois composants, une interface graphique pour la gnration semi-automatique des indicateurs, un entrept multidimensionnel et les versions de schmas bitemporels. Nous dcrivons notre mtamodle et ses mtaclasses. Nous prsentons le schma en constellation conu compos de trois sous-schmas : Prise_MCO, Prise_SSR et Population, o chacun est compos soit de ses propres dimensions soit des dimensions partages. Le chapitre 4 traite le sujet des vues matrialises, aussi bien leur slection que leur cration. Nous prsentons dabord lhypercube pour le schma Adelem_MCO. Ensuite, nous prsentons un algorithme pour la slection de lensemble optimal des vues slectionner. Nous terminons ce chapitre avec une description du fonctionnement de linterface pour la gnration semi-automatique dindicateurs. Le chapitre 5 prsente notre proposition pour la gestion, le stockage et la visualisation de lensemble de donnes historises. Pour la cration et la gestion des versions de schmas, nous donnons une liste doprations primitives adaptes aux entrepts de donnes et nous avons aussi dni un ensemble de contraintes pour la manipulation des versions. Nous donnons aussi pour chaque primitive sa dnition formelle. La dernire partie traite de la description du gestionnaire dvolution de schmas. Nous prsentons aussi bien la gestion de donnes historises que lactivit
1.5 Plan de la thse du gestionnaire dvolution par niveau. Finalement, le chapitre 6 prsente nos conclusions et quelques perspectives.
13
14
Introduction
Chapitre 2 Entrepts de donnes multidimensionnelles et aspects temporels

Les entrepts de donnes sont apparus vers les annes 1990 en rponse la ncessit de rassembler toutes les informations de lentreprise en une base de donnes unique destine aux analystes et aux gestionnaires [Cod93, DG01]. Lensemble des donnes, y compris leur historique, est utilis dans de nombreux domaines, tels que : lanalyse de donnes et laide la dcision (gestion et analyse de march, gestion et analyse du risque, gestion et dtection des fraudes,...) ; dans autres applications (recherches dans des textes, dans les documents web, dans lastronomie,...) [Adi02, BCA01]. Dans ce chapitre, nous analysons aussi bien les caractristiques des entrepts que leurs aspects temporels.
2.1
Entrepts de donnes
Nous prsentons dabord larchitecture dun systme dcisionnel qui se compose de trois composants : les sources, lentrept et les outils pour linterrogation de lensemble de donnes. Nous dcrivons aussi les caractristiques des entrepts et les bases de donnes.
2.1.1
Architecture dun entrept de donnes
Larchitecture des entrepts de donnes repose souvent sur un SGBD spar du systme de production de lentreprise qui contient les donnes de lentrept. Le processus dextraction des donnes permet dalimenter priodiquement ce SGBD. Nanmoins avant dexcuter ce processus, une phase de transformation est applique aux donnes oprationnelles. Celle-ci consiste les prparer (mise en correspondance des formats de donnes), les nettoyer, les ltrer,..., pour nalement aboutir leur 15
16
Entrepts de donnes multidimensionnelles et aspects temporels
stockage dans lentrept. Dans la Figure 2.1, nous prsentons une architecture simplie dun entrept [DG01]. Les dirents composants ont t intgrs dans trois parties : les sources de donnes, lentrept et les outils existants dans le march.
Entrept de donnes
O Mtadonnes Donnes externes Donnes fortement rsumes Donnes lgrement rsumes Donnes de dtail U T I L S
Donnes de production (SGBD, systmes lgus)
Donnes anciennes archives
Fig. 2.1 Architecture dun entrept de donnes
a) Les sources : Les donnes de lentrept sont extraites de diverses sources souvent rparties et htrognes, et qui doivent tre transformes avant leur stockage dans lentrept. Nous avons deux types de sources des donnes : internes et externes lorganisation. Internes : La plupart des donnes sont saisies partir des dirents systmes de production qui rassemblent les divers SGBD oprationnels, ainsi que des anciens systmes de production qui contiennent des donnes encore exploites par lentreprise. Externes : Ils reprsentent des donnes externes lentreprise et qui sont souvent achtes. Par exemple, les sources de donnes dmographiques. b) Lentrept de donnes : Il existe plusieurs types de donnes dans un entrept, qui correspondent diverses utilisations, comme :
2.1 Entrepts de donnes
17
Donnes de dtail courantes : Ce sont lensemble des donnes quotidiennes et plus couramment utilises. Ces donnes sont gnralement stockes sur le disque pour avoir un accs rapide. Par exemple, le dtail des ventes de lanne en cours, dans les dirents magasins. Donnes de dtail anciennes : Ce sont des donnes quotidiennes concernant des vnements passs, comme par exemple le dtail des ventes des deux dernires annes. Nous les utilisons pour arriver lanalyse des tendances ou des requtes prvisionnelles. Nanmoins ces donnes sont plus rarement utilises que les prcdentes, et elles sont souvent stockes sur des mmoires darchives. Donnes rsumes ou agrges : Ce sont des donnes moins dtailles que les deux premires et elles permettent de rduire le volume des donnes stocker. Le type de donnes, en fonction de leur niveau de dtail, permet de les classier comme des donnes lgrement ou fortement rsumes. Par exemple, les ventes mensuelles par magasin des dix dernires annes sont des donnes faiblement rsumes, tandis que les ventes semestrielles, par rgion, des dix dernires annes sont fortement rsumes. Les mtadonnes : Ce sont des donnes essentielles pour parvenir une exploitation ecace du contenu dun entrept. Elles reprsentent des informations ncessaires laccs et lexploitation des donnes dans lentrept comme : la smantique (leur signication), lorigine (leur provenance), les rgles dagrgation (leur primtre), le stockage (leur format, par exemple : francs, euro,...) et nalement lutilisation (par quels programmes sont-elles utilises). c) Outils : Il existe sur le march dirents outils pour laide la dcision, comme les outils de fouille de donnes ou datamining (pour dcouvrir des liens smantiques), outils danalyse en ligne (pour la synthse et lanalyse des donnes multidimensionnelles), outils dinterrogation (pour faciliter laccs aux donnes en fournissant une interface conviviale au langage de requtes),... [CD97, Fra97, DG01].
2.1.2
Entrepts et les bases de donnes
Dans lenvironnement des entrepts de donnes, les oprations, lorganisation des donnes, les critres de performance, la gestion des mtadonnes, la gestion des transactions et le processus de requtes sont trs dirents des systmes de bases de donnes oprationnels. Par consquent, les SGBD relationnels orients vers lenvironnement oprationnel, ne peuvent pas tre directement transplants dans un systme dentrept de donnes [WB97]. Les SGBD ont t cres pour les applications de gestion de systmes transactionnels. Par contre, les entrepts de donnes ont t conus pour laide la prise
18
de dcision. Ils intgrent les informations qui ont pour objectif de fournir une vue globale de linformation aux analystes et aux dcideurs. Le tableau 2.1 rsume ces dirences entre les systmes de gestion de bases de donnes et les entrepts de donnes [DG01]. SGBD Gestion et production Gestionnaires de production Plusieurs gigaoctets Par traitement Donnes de gestion (courantes) Simples, prdtermines, donnes dtailles Courtes et nombreuses, temps rel Entrepts de donnes Consultation et analyse Dcideurs, analystes Plusieurs teraoctets Par mtier Donnes danalyse (rsumes, historises) Complexes, spciques, agrgations et group by Longues, peu nombreuses
Objectifs Utilisateurs Taille de la base Organisation des donnes Type de donnes Requtes Transactions
Tab. 2.1 Dirences entre SGBD et entrepts de donnes
Systmes transactionnels et systmes dcisionnels Les SGBD ont t crs pour grer de grands volumes dinformation contenus dans les dirents systmes oprationnels qui appartiennent lentreprise. Ces donnes sont manipules en utilisant des processus transactionnels en ligne [Cod93]. Paralllement lexploitation de linformation contenue dans ces systmes oprationnels, les dirigeants des entreprises ont besoin davoir une vision globale concernant toute cette information pour faire des calculs prvisionnels, des statistiques ou pour tablir des stratgies de dveloppement et danalyses des tendances. Le tableau 2.2 compare les caractristiques des systmes transactionnels et dcisionnels par rapport aux donnes et aux utilisateurs [BCA01, CT98, GM00, SMKK98, Tes00, ZS99].
2.2
Modlisation multidimensionnelle
Pour arriver construire un modle appropri pour un entrept de donnes, nous pouvons choisir, soit un schma relationnel (le schma en toile, en ocon de neige ou en constellation) ; soit un schma multidimensionnel. Avant de dcrire les dirents schmas, nous commenons par quelques concepts de base.
2.2 Modlisation multidimensionnelle S. Transactionnel Exhaustives Courantes Dynamiques Orientes applications Nombreux Varis (employs, directeurs,...) Concurrents Mises jour et interrogations Requtes prdnies Rponses immdiates Accs peu dinformation S. Dcisionnel Rsumes Historiques Statiques Orientes sujets (danalyse) Peu nombreux Uniquement les dcideurs Non concurrents Interrogations Requtes imprvisibles et complexes Rponses moins rapides Accs de nombreuses informations
19
Donnes
Utilisateurs
Tab. 2.2 Comparaison des systmes La modlisation multidimensionnelle consiste considrer un sujet analys comme un point dans un espace plusieurs dimensions. Les donnes sont organises de manire mettre en vidence le sujet (le fait) et les direntes perspectives de lanalyse (les dimensions). En partant de cette dnition, nous remarquons les concepts de fait et de dimension. Le fait reprsente le sujet danalyse. Il est compos dun ensemble de mesures qui reprsentent les direntes valeurs de lactivit analyse. Par exemple, dans le fait Ventes (cf. Figure 2.2), nous pouvons avoir la mesure "Quantit de produits vendus par magasin". Les mesures doivent tre valorises de manire continue [AGS97, CT97, Inm92, Inm95, Kim96, KR03, KS95] et elles peuvent tre additives (pour rsumer une grande quantit denregistrements) ; semi-additives (si elles peuvent seulement tre additionnes pour certaines dimensions) et non additives. Une dimension modlise une perspective de lanalyse. Elle se compose de paramtres (ou attributs) qui servent enregistrer les descriptions textuelles. Nous pouvons utiliser les paramtres textuels comme source des restrictions dans une requte. Par exemple, dans la requte "Quantit de produits vendus dans la rgion Rhne Alpes durant le mois de Janvier 2000". Nous trouvons les paramtres : rgion "Rhne Alpes" et mois "Janvier 2000". Une hirarchie reprsente les paramtres dune dimension selon leur niveau de granularit ou de dtail. Les paramtres sont ordonns par une relation "est _plus_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 :
20
Entrepts de donnes multidimensionnelles et aspects temporels Commune Dpartement Rgion Pays
2.2.1
Schmas relationnels
Dans les schmas relationnels nous trouvons deux types de schmas. Les premiers sont des schmas qui rpondent fort bien aux processus de type OLTP qui ont t dcrits prcdemment, alors que les deuximes, que nous appelons des schmas pour le dcisionnel, ont pour but de proposer des schmas adapts pour des applications de type OLAP. Nous dcrivons les dirents types des schmas relationnels pour le dcisionnel. 2.2.1.1 Le schma en toile
Il se compose du fait central et de leurs dimensions. Dans ce schma il existe une relation pour les faits et plusieurs pour les direntes dimensions autour de la relation centrale. La relation de faits contient les direntes mesures et une cl trangre pour faire rfrence chacune de leurs dimensions. La gure 2.2 montre le schma en toile en dcrivant les ventes ralises dans les dirents magasins de lentreprise au cours dun jour. Dans ce cas, nous avons une toile centrale avec une table de faits appele Ventes et autour leurs diverses dimensions : Temps, Produit et Magasin.
Produit Temps Cl_T Jour Mois Anne Ventes Cl_P Cl_T Cl_M Quantit 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 2.2.1.2 Le schma en ocon de neige (Snowake)
21
Il drive du schma prcdent avec une relation centrale et autour delle les direntes dimensions, qui sont clates ou dcomposes en sous hirarchies. Lavantage du schma en ocon de neige est de formaliser une hirarchie au sein dune dimension, ce qui peut faciliter lanalyse. Un autre avantage est reprsent par la normalisation des dimensions, car nous rduisons leur taille. Nanmoins dans [Kim96], lauteur dmontre que cest une perte de temps de normaliser les relations des dimensions dans le but dconomiser lespace disque. Par contre, cette normalisation rend plus complexe la lisibilit et la gestion dans ce type de schma. En eet, ce type de schma augmente le nombre de jointures raliser dans lexcution dune requte. Les hirarchies pour le schma en ocon de neige de lexemple de la gure 2.2 sont : Dimension Temps = Jour Mois Anne Dimension Magasin = Commune Dpartement Rgion Pays La gure 2.3 montre le schma en ocon de neige avec les dimensiones Temps et Magasin clates en sous hirarchies.
Produit Temps Cl_T Jour Mois Ventes Cl_P Cl_T Cl_M Quantit T_Mois Mois Anne Magasin Cl_M Raison_soc Adresse Commune Dpartement M_Dpartement Dpartement Rgion M_Rgion Rgion Pays Cl_P Description Type Catgorie
Fig. 2.3 Exemple de modlisation en ocon de neige. Dans lexemple ci-dessus, la dimension Temps a t clate en deux, Temps et T_Mois. La deuxime dimension Magasin, t dcompose en trois : Magasin, M_ Dpartement et M_Rgion.
22 2.2.1.3
Entrepts de donnes multidimensionnelles et aspects temporels Le schma en constellation
Le schma en constellation reprsente plusieurs relations de faits qui partagent des dimensions communes. Ces direntes relations de faits composent une famille qui partage les dimensions mais o chaque relation de faits a ses propres dimensions [BCA01]. La gure 2.4 montre le schma en constellation qui est compos de deux relations de faits. La premire sappelle Ventes et enregistre les quantits de produits qui ont t vendus dans les dirents magasins pendant un certain jour. La deuxime relation gre les dirents produits achets aux fournisseurs pendant un certain temps.
Magasin Produit Cl_M Raison_soc Adresse Commune Dpartement Rgion Pays Cl_P Description Type Catgorie
Ventes Cl_P Cl_M Cl_T Quantit
Temps Cl_T Jour Mois Anne
Achats Cl_P Cl_F Cl_T Quantit
Fournisseur Cl_F Raison_soc Adresse Code_postal Commune Pays
Fig. 2.4 Exemple de modlisation en constellation. La relation de faits Ventes partage leurs dimensions Temps et Produits avec la table Achats. Nanmoins, la dimension Magasin appartient seulement Ventes. Egalement, la dimension Fournisseur est lie seulement la relation Achats.
2.2.2
Schma multidimensionnel (Cube)
Dans le modle multidimensionnel, le concept central est le cube, lequel est constitu des lments appels cellules qui peuvent contenir une ou plusieurs mesures. La localisation de la cellule est faite travers les axes, qui correspondent chacun une dimension. La dimension est compose de membres qui reprsentent les direntes valeurs.
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.
Magasin Produit
S U M Pays
Magasin
TV Lyon Grenoble Annecy SUM
CS
CP
Temps
anne Rgion
01/01/2000
Temps
02/01/2000
mois
Dpartement
03/01/2000
SUM All
Jour
Ville
Hirarchies des dimensions
Fig. 2.5 Exemple de schma multidimensionnel. La gure 2.5, prsente un schma multidimensionnel pour les ventes qui ont t ralises dans les magasins pour les dirents produits au cours dun temps donn (jour). Par exemple, nous avons la quantit de 100 Tlviseurs vendus dans le magasin dAnnecy pendant le 1er janvier 2000.
2.3
Manipulation des donnes multidimensionnelles
Pour visualiser les donnes multidimensionnelles, nous pouvons utiliser la reprsentation sous forme dune table de donnes, qui est la plus courante [Mar98, Vas98]. Dans une table, nous reprsentons les direntes combinaisons des valeurs choisies pour constituer les noms de lignes et de colonnes. Nanmoins, quand le nombre de dimensions est suprieur deux, lutilisateur a des problmes pour visualiser simultanment lensemble de linformation. Pour rsoudre ce problme, nous devons disposer doprations pour manipuler les donnes et rendre possible la visualisation. Nous prsentons les oprations pour la manipulation des donnes multidimensionnelles, en les divisant selon leur impact sur la faon de prsenter les direntes vues des donnes analyses [Mar98, MQM97, MS90, Tes00].
2.3.1
Oprations classiques
Ces oprations correspondent aux oprations relationnelles de manipulation des donnes : La slection : Rsulte en un sous-ensemble de donnes qui respecte certains conditions dappartenance. Nous pouvons avoir une slection avec des conditions soit sur
24
les mesures, soit sur les membres. Par exemple, une slection des ventes suprieur 350 est une slection sur les mesures, tandis que une slction des ventes raliss dans la rgion "Rhne Alpes" de lanne "2000" est une slection sur les membres dune dimension. La projection : Rsulte en un sous-ensemble des attributs dune relation, qui sont soit des dimensions, soit des niveaux de granularit. Dans les systmes dcisionnels, les oprations de slection et de projection sont appeles souvent "slice-and-dice". La jointure : Permet dassocier les donnes de relations direntes. Par exemple, en utilisant les tables 2.3 et 2.4, nous faisons une jointure sur la dimension Produit. Lobjectif est de reprsenter sur une mme table la quantit de produits vendue et leur prix (cf. Figure 2.6). Ventes (01/01/2000) Tlviseur Radio Camscope Camera photo Mag1 100 50 100 Mag2 200 50 100 Mag3 250 100
Tab. 2.3 Ventes par magasin Produit Tlviseur Radio Camscope Camera photo Prix (01/01/2000) 1 2 3 4
Tab. 2.4 Prix des produits
Les oprations ensemblistes : Dunion, dintersection et de dirence sont des oprations qui agissent sur des relations qui ont le mme schma. Par exemple, lunion des tables 2.5 et 2.6 donne comme rsultat la table 2.7.
2.3.2
Oprations agissant sur la structure
Les oprations agissant sur la structure visent prsenter une vue (face du cube) dirente en fonction de leur analyse, citons : La rotation (rotate) : Consiste pivoter ou eectuer une rotation du cube, de manire prsenter une vue dirente des donnes analyser.
2.3 Manipulation des donnes multidimensionnelles
25
Fig. 2.6 Exemple de lopration Jointure. Ville Grenoble Grenoble Grenoble Grenoble Produit Tlviseur Radio Camscope Camera photo Mag1 50 50 100 Mag2 100 Mag3 100 50 100
Tab. 2.5 Ventes de produits par ville 1 Ville Fontaine Fontaine Fontaine Fontaine Produit Tlviseur Radio Camscope Camera photo Mag1 100 50 100 100 Mag2 100 50 Mag3 50 100 100 100
Tab. 2.6 Ventes de produits par ville 2 Ville Grenoble Grenoble Grenoble Grenoble Fontaine Fontaine Fontaine Fontaine Produit Tlviseur Radio Camscope Camera photo Tlviseur Radio Camscope Camera photo Mag1 50 50 100 100 50 100 100 Mag2 100 Mag3 100 50 100 50 100 50 100 100 100
Tab. 2.7 Ventes du Dpartement Isre
26
La permutation (switch) : Consiste inverser des membres dune dimension, de manire permuter deux tranches du cube. La division (split) : Consiste prsenter chaque tranche du cube en passant dune reprsentation tridimensionnelle une prsentation tabulaire. Par exemple, si nous dcoupons par magasin le cube de ventes de la gure 2.5, nous avons les tables 2.8, 2.9 et 2.10. Ventes Magasin 1 Tlviseur Radio Camscope Camera photo 01/01/2000 100 50 100 02/01/2000 100 200 100 03/01/2000 50 100 100 100
Tab. 2.8 Table de ventes du Magasin 1 Ventes Magasin 2 Tlviseur Radio Camescope Camera photo 01/01/2000 200 50 100 02/01/2000 100 200 100 03/01/2000 150 100 100
Tab. 2.9 Table de ventes du Magasin 2 Ventes Magasin 3 Tlviseur Radio Camscope Camera photo 01/01/2000 250 100 02/01/2000 100 50 100 03/01/2000 50 100 50 100
Tab. 2.10 Table de ventes du Magasin 3 Nous remarquons que le nombre de tables rsultantes de cette opration dpend du nombre de valeurs lintrieur de la dimension. Lembotement (nest) : Permet dimbriquer les membres dune dimension. En utilisant cette opration, nous reprsentons dans une table bidimensionnelle toutes les donnes dun cube quel que soit le nombre de dimensions. Lenfoncement (push) : Consiste combiner les membres dune dimension aux mesures du cube et donc de reprsenter un membre comme une mesure.
2.4 Serveurs OLAP (On-Line Analytical Processing)
27
Lopration inverse de retrait (pull) : Permet de changer le statut de certaines mesures, pour transformer une mesure en membre dune dimension. La factualisation (fold) : Consiste transformer une dimension en mesure(s) ; cette opration permet de transformer en mesure lensemble des paramtres dune dimension. La paramtrisation (unfold) : Permet de transformer une mesure en paramtre dans une nouvelle dimension. Lopration Cube : Permet de calculer des sous-totaux et un total nal dans le cube (cf. Fig 2.5).
2.3.3
Oprations agissant sur la granularit
Les oprations agissant sur la granularit des donnes analyses, permettent de hirarchiser la navigation entre les dirents niveaux de dtail dune dimension. Dans la suite nous traitons les deux oprations de ce type : Le forage vers le haut (drill-up ou roll-up) : Permet de reprsenter les donnes du cube un niveau plus haut de granularit en respectant la hirarchie de la dimension. Nous utilisons une fonction dagrgation (somme, moyenne,...), qui est paramtre, pour indiquer la faon de calculer les donnes du niveau suprieur partir de celles du niveau infrieur. Le forage vers le bas (drill-down ou roll-down ou scale-down) : Consiste reprsenter les donnes du cube un niveau de granularit infrieur, donc sous une forme plus dtaille. Ces types doprations ont besoin dinformations non reprsentes dans un cube, pour augmenter ou aner des donnes, partir dune reprsentation initiale vers une reprsentation de granularit dirente. Le forage vers le haut a besoin de connatre la fonction dagrgation utilise tandis que le forage vers le bas ncessite de connatre les donnes au niveau infrieur.
2.4
Serveurs OLAP (On-Line Analytical Processing)
Les donnes oprationnelles constituent la source principale dun systme dinformation dcisionnel. Les systmes dcisionnels complets reposent sur la technologie OLAP, conue pour rpondre aux besoins danalyse des applications de gestion. Lacronyme FASMI (Fast Analysis of Shared Multidimensional Information) permet de rsumer la dnition des produits OLAP. Cette dnition fut utilise pour
28
la premire fois en 1995 et depuis aucune autre dnition nest plus proche pour rsumer le terme OLAP [Ola04]. Fast : Le temps de rponse aux demandes des utilisateurs oscille entre 1 et 20 secondes. Les constructeurs utilisent des pr-calculs pour rduire les dures des requtes. Analysis : Le systme doit pouvoir faire face toutes les logiques daaires et de statistiques, ainsi que fournir la possibilit aux utilisateurs de construire leurs calculs et leurs analyses sans avoir programmer. Pour cela, il y a des outils qui seront fournis par le constructeur. Shared : Le systme doit crer un contexte o la condentialit est prserve et doit grer les cas o plusieurs utilisateurs ont des droits en critures. Ce point constitue la plus grosse faiblesse des produits actuels. Multidimensional : Cest la caractristique cl. Le systme doit fournir des vues conceptuelles multidimensionnelles des donnes. Il doit supporter aussi les hirarchies. Informations : Lensemble des donnes et les informations ncessaires pour un produit OLAP. Nous exposons dans la suite les divers types de stockage des informations dans les systmes dcisionnels.
2.4.1
ROLAP (Relational OLAP)
Dans les systmes relationnels OLAP, lentrept de donnes utilise une base de donnes relationnelle. Le stockage et la gestion de donnes sont relationnels. Toutefois, le modle relationnel requiert des extensions pour supporter les requtes danalyses multidimensionnelles du niveau dapplication. Le moteur ROLAP traduit dynamiquement le modle logique de donnes multidimensionnel M en modle de stockage relationnel R (la plupart des outils requirent que la donne soit structure en utilisant un schma en toile ou un schma en ocon de neige). Techniquement, le moteur ROLAP excute une transformation partir dune requte multidimensionnelle m contre M vers une requte relationnelle r contre R. Lecacit du rsultat de la requte est le facteur dominant pour la performance et le passage lchelle global du systme. Ainsi, les stratgies doptimisation reprsentent le point principal qui distingue les systmes ROLAP existants [DSBH99, Sat03]. La gure 2.7 montre une architecture pour le serveur ROLAP.
29
Serveur ROLAP
Base de donnes relationnelle
Vue multidimensionnelle
Client OLAP
Fig. 2.7 Architecture ROLAP. La technologie ROLAP a deux avantages principaux : (1) elle permet la dnition de donnes complexes et multidimensionnelles en utilisant un modle relativement simple , et (2) elle rduit le nombre de jointures raliser dans lexcution dune requte. Le dsavantage est que le langage de requtes tel quil existe, nest pas assez puisant ou nest pas assez exible pour supporter de vraies capacits dOLAP [VS99, BSH98]. Nous dcrivons quelques produits commerciaux existants [How03, CHJM02] : IBM DB2 UDB : Cest un SGBD tournant sur une varit de plate-formes. IBM est une shared nothing database et elle supporte le concept de fdration. Elle dispose dune large gamme doutils, par exemple : DB2 Performance Expert : Cet outil pour multiplate-formes permet la cration des rapports, des analyses et recommande des changements par rapport la performance. DB2 DataJoiner : Outil pour loptimisation des requtes SQL. DB2 Integrated Cluster Environnement : Il permet le passage lchelle. Oracle 9i : Cest un SGBD tournant aussi sur une varit de plate-formes. Oracle supporte des partitions de hash, range et list. Oracle 9i : Cest une shared disk database et elle supporte la consolidation (focalise sur une base de donnes centralise). Real Application Clusters : Il permet de dsigner certains processeurs comme processeurs OLAP et dautres comme processeurs de requtes.
30
Loptimiser : Bas sur les cots ou sur les rgles. SQL Server 2000 : Cest une shared nothing database et elle supporte le concept de fdration (liaison entre bases de donnes distribues et htrognes via le logiciel). Loptimiser de SQL Server : Bas sur les cots avec cration automatique de statistiques et leur rafrachissement. Le Query Processor : Il supporte des requtes multidimensionnelles, ainsi que les index composites et semi-jointures. Le SQL Query Analyzer : Il peut faire des suggestions par rapport limplantation des index additionnels et des statistiques complmentaires. Microsoft DTS (Data Transformation Services) : Loutil ETL intgr dans Microsoft SQL Server.
2.4.2
MOLAP (Multidimensional OLAP)
Les systmes multidimensionnels OLAP utilisent une base de donnes multidimensionnelle pour stocker les donnes de lentrept et les applications analytiques sont construites directement sur elle. Dans cette architecture, le systme de base de donnes multidimensionnel sert tant au niveau de stockage quau niveau de gestion des donnes. Les donnes des sources sont conformes au modle multidimensionnel, et dans toutes les dimensions, les direntes agrgations sont prcalcules pour des raisons de performance [WB97]. La gure 2.8 montre une architecture pour les systmes MOLAP.
Serveur MOLAP Base de donnes multidimensionnelle (hypercube)
Client OLAP
Fig. 2.8 Architecture MOLAP.
31
Les systmes MOLAP doivent grer le problme de donnes clairsemes, quand seulement un nombre rduit de cellules dun cube contiennent une valeur de mesure associe. Par exemple, dans le cube Ventes (cf. Fig 2.5), il peut arriver que certains produits ne se soient pas vendus dans une ville spcique et quen consquent il ny ait pas de valeurs de mesure pour cette combinaison. La faon de rsoudre cette problmatique, par les produits commerciaux, reprsente un des plus importants critres pour les systmes MOLAP. La plupart des systmes existants utilisent lapproche du vecteur multidimensionnel pour le stockage de donnes, ainsi que la compression de lespace de stockage pour les vecteurs de plus de trois dimensions [Ben02, DSBH99]. Les avantages des systmes MOLAP sont bass sur les dsavantages des systmes ROLAP et elles reprsentent la raison de leur cration. Dun ct, les requtes MOLAP sont trs puissantes et exibles en termes du processus OLAP, tandis que, dun autre ct, le modle physique correspond plus troitement au modle multidimensionnel. Nanmoins, il existe des dsavantages au modle physique MOLAP. Le plus important, notre avis, cest quil nexiste pas de standard du modle physique. Les produits commerciaux existants sont : Hyperion Essbase OLAP Server : Cest une base de donnes multi-utilisateurs, multi-thread et multidimensionnelle [Blo99]. Les composants dEssbase OLAP sont : Hyperion Essbase Application Manager : Il fournit des outils graphiques. Il inclut des modules pour la construction et le chargement des structures OLAP, pour le chargement des donnes, pour la dnition des processus de calcul, pour la gestion des partitions de la base de donnes,... Hyperion Essbase Query Designer : Ce composant remplace le Query Wizard dEssbase 6.0. Il a t conu pour faciliter la navigation des utilisateurs naux. Hyperion Essbase Partition Option : Il permet aux dveloppeurs des applications la cration logique et physique de sous-ensembles des bases de donnes. Les deux types de partitions qui sont supports sont : transparente et lie. Le premier cherche montrer lutilisateur nal une base de donnes centralise. Avec le deuxime type, nous pouvons dnir deux partitions lies si elles partagent au moins une partie dune dimension. Ainsi, nous pouvons naviguer entre applications et non entre partitions. Par exemple, nous pouvons naviguer entre lapplication de ventes et celle dachats, car elles relient le mme ensemble de produits. SAS OLAP Server : Cest une base multidimensionnelle qui fournit un accs rapide aux donnes agrges [SAS04]. Leurs composants incluent :
32
SAS OLAP Cube Studio : Cest un outil pour la construction des cubes et qui peut tre facilement utilis pour la dnition des mesures, des dimensions et des agrgations. SAS Metadata Server : Cest un conteneur des mtadonnes. Ce serveur fournit un processus ETL (Extract, Transform and Load) qui est transparent et intgr. Informix MetaCube : Il fournit un mcanisme pour analyser lentrept de donnes et leurs data marts intgrant des outils OLAP avec la technologie de bases de donnes relationnelles [Inf02]. Les composants du logiciel MetaCube sont : MetaCube Analysis Engine : Il fournit une interface multidimensionnel. Cet outil tend la fonctionnalit danalyse de la base de donnes avec lincorporation des oprations OLAP, par exemple lopration rotation (rotate). MetaCube Explorer : Cest une interface graphique qui permet aux utilisateurs dexcuter des requtes au travers du MetaCube Analysis Engine. MetaCube Warehouse Manager : Cest une interface graphique pour crer une description multidimensionnelle des tables et des colonnes dans lentrept de donnes. Le MetaCube Analysis Engine stocke cette description multidimensionnelle comme un ensemble de tables.
2.4.3
HOLAP (Hybrid OLAP)
Un systme HOLAP est un systme qui supporte et intgre un stockage des donnes multidimensionnel et relationnel dune manire quivalente pour proter des caractristiques de correspondance et des techniques doptimisation. Ci-dessous, nous traitons une liste des caractristiques principales quun systme HOLAP doit fournir [DSBH99] : La transparence du systme : Pour la localisation et laccs aux donnes, sans connatre si elles sont stockes dans un SGBD relationnel ou dimensionnel. Pour la transparence de la fragmentation,... Un modle de donnes gnral et un schma multidimensionnel global : Pour aboutir la transparence du premier point, tant le modle de donnes gnral que le langage de requte uniforme doivent tre fournis. Etant donn quil nexiste pas un modle standard, cette condition est dicile raliser. Une allocation optimale dans le systme de stockage : Le systme HOLAP
33
doit bncier des stratgies dallocation qui existent dans les systmes distribus tels que : le prol de requtes, le temps daccs, lquilibrage de chargement,... Une re-allocation automatique : Toutes les caractristiques traites ci-dessus changent dans le temps. Ces changements peuvent provoquer la rorganisation de la distribution des donnes dans le systme de stockage multidimensionnel et relationnel, pour assurer des performances optimales. Actuellement, la plupart des systmes commerciaux utilisent une approche hybride. Cette approche permet de manipuler des informations de lentrept de donnes avec un moteur ROLAP, tandis que pour la gestion des data marts, ils utilisent lapproche multidimensionnelle. Dans la gure 2.9, nous montrons une architecture en utilisant les types de serveurs ROLAP et MOLAP pour le stockage de donnes.
Serveur MOLAP Base de donnes multidimensionnelle (hypercube) Base de donnes relationnelle
Vue multidimensionnelle
Client OLAP
Fig. 2.9 Architecture HOLAP. Les produits commerciaux existants sont : DB2 OLAP Server : Il permet de calculer, de consolider et daccser linformation partir des bases de donnes multidimensionnelles, relationnelles ou les deux [DB204]. Certains de ses composants sont : DB2 OLAP Integration Server : Il utilise des outils graphiques et des services pour lintgration des donnes qui rduisent le cot pour crer, dployer et grer les applications de DB2 OLAP Server. DB2 OLAP Server Administration Services : Il fournit des outils pour amliorer et faciliter des tches dadministration. Oracle Express Server : Ce serveur exploite un modle de donnes multidimensionnel. Il gre un ensemble dindicateurs n dimensions, dont les valeurs sont
34
stockes ou calcules dynamiquement [ORA96]. Le stockage des donnes peut se faire dans une base de donnes multidimensionnelle ou relationnelle. La base Oracle Express Server : Stocke les agrgats multidimensionnels, tandis que les donnes de dtail sont stockes dans la base relationnelle. En utilisant un 4GL (Langage de 4me gnration), Express Server propose des fonctions avances pour la prsentation et lanalyse des rsultats, tels que : traitement de sries chronologiques, consolidation, statistiques, prvisions,...
2.5
Les projets de recherche
Dans cette partie, nous dcrivons les projets de recherche sur les entrepts de donnes. Les deux premiers (WHIPS et SIRIUS) sont centrs sur des problmatiques lies lextraction et la maintenance des donnes. Le troisime DWQ traite de la qualit des entrepts, tandis que le dernier, le projet EVOLUTION propose le dveloppement dune mthodologie et doutils pour laide la conception et lvolution des entrepts.
2.5.1
WHIPS Warehouse Information Prototype at Stanford
Lobjectif du projet est de dvelopper des algorithmes pour collecter, intgrer et maintenir des informations de sources htrognes, distribues et autonomes. Le modle relationnel est utilis comme modle unicateur. Pour linitialisation de lentrept, lintgrateur cre un gestionnaire de vues pour chaque vue dans lentrept. Le gestionnaire de vues envoie les requtes issues de la dnition dune vue au processeur de requtes. Le processeur de requte contacte les traducteurs de la source dinformation adquate pour obtenir les rsultats, les assemble et passe la rponse au gestionnaire de vue. Le gestionnaire de vue envoie la rponse ladaptateur de lentrept pour initialiser la vue. Chaque source contienne un moniteur et un adaptateur. Ladaptateur transforme les donnes de la source en une reprsentation relationnelle. Le moniteur dtecte les changements qui se produisent au niveau des sources. Les mises jour sont transmises lintgrateur, qui les transmet aux gestionnaires de vues qui sont concerns par les modications [LZW+ 97, HGMW+ 95]. Description des composants : Adaptateur/Moniteur : Il est associ chaque source de donnes et il a deux fonctionnes : transformer le schma et ses instances en une reprsentation interm-
2.5 Les projets de recherche
35
diaire et dtecter automatiquement les changements dans la source pour les propager vers lintgrateur. Intgrateur : Il est responsable de la rception des reprsentations intermdiaires des donnes sources, en provenance des adaptateurs, et de lintgration de cellesci. Lintgration entrane aussi une phase de transformation, celle-ci consiste les prparer (mise en correspondance des formats de donnes), les nettoyer, les ltrer,..., pour les rendre conforme au schma de lentrept et aux critres de qualit choisis.
2.5.2
SIRIUS Supporting the Incremental Refreshment of Information warehouses
Ce projet dvelopp lUniversit de Zurich, est un systme dentrept de donnes qui a pour objectif dtudier des techniques permettant le rafrachissement incrmental de lentrept en rduisant les temps de mise jour. Le schma de lentrept est dni sous la forme dun schma global UML. Chaque source de donnes est munie dun adaptateur et dun moniteur. Le moniteur dtecte les volutions de la source laquelle il est associ. Le module de gestion du rafrachissement est le module central (DWRM Data Warehouse Refresh Manager). Ladaptateur traduit les donnes de la source dans un modle commun, interne au systme et les transmet au module central DWRM [VGD00]. Objectif du projet : Lobjectif principal de cette approche est dintroduire une architecture dintergiciel exible, pour : - Fournir des solutions pour le rafrachissement de donnes. - Pouvoir tre utilise de faon indpendante par rapport au stockage de donnes de lentrept. - Pouvoir tre utilise par des entrepts de donnes composs des sources de donnes htrognes.
2.5.3
DWQ Foundations of Data Warehouse Quality
DWQ est un projet de la communaut Europenne (France, Allemagne, Italie et Grce) pour le dveloppement des fondements smantiques qui permettront daider les concepteurs dentrepts de donnes dans le choix des modles, des structures de donnes avances et des techniques dimplantation ecaces en sappuyant sur des facteurs de qualit de service.
36
Les rsultats comportent des mta-modles formels de donnes destins la description de larchitecture statique dun entrept de donnes. Les outils associs comportent des facilits de modlisation incluant des caractristiques spciques aux entrepts comme la rsolution de sources multiples, la gestion de donnes multidimensionnelles agrges et des techniques pour loptimisation de requtes et la propagation incrmentale des mises jour. Ce projet permet aussi lvolution de lentrept. Les outils incluent un ensemble doprateurs, lanalyse et loptimisation des dnitions des vues, la slection optimise de sources de donnes, des stratgies dintgration et des vues matrialises [JV97, JQJ98, JJQV99, TS99]. Objectifs du projet : Les objectifs de recherche visent trois domaines, o les facteurs de qualit reprsentent le point central : - Enrichir la smantique de la mta base avec des models formels de qualit de linformation qui permettent loptimisation de la conception de faon adaptative et quantitative. - Enrichir la smantique des models dinformation qui permettent aussi bien le rafrachissement incrmental de donnes et leur propagation vers lentrept, que la rsolution des conits. - Enrichir la smantique des models de schma de lentrept qui permettent aux concepteurs de prendre les avantages explicites par rapport la nature temporelle, spatiale et des agrgats des donnes. Composants de lentrept de donnes : Le projet DWQ fournit un modle architectural qui considre la conception, la mise en oeuvre, la maintenance et lvolution des entrepts. Les composants basics sont : - Sources : les donnes stockes dont le contenu peut tre matrialis dans lentrept. - Adaptateur : responsable du chargement des donnes sources dans lentrept. - Base de donnes nale : lentrept de donnes et les data marts. - Mta base : conteneur dinformation des autres composants, par exemple, le schma des donnes sources.
2.6 Aspects temporels des entrepts
37
- Agents dadministration : concepteurs de lentrept. - Clients : utilisateurs de linformation.
2.5.4
Projet EVOLUTION
Le projet propose le dveloppement dune mthodologie et dun atelier doutils de type CASE pour laide la conception et lvolution des entrepts de donnes. Lobjectif de ce projet est la spcication dun ensemble doutils daide la conception de lentrept et sa maintenance. Deux objectifs sont intgrs dans la cration de ces outils : prvoir lvolutivit de schma et grer la traabilit des volutions successives. Pour atteindre ce but, trois objectifs, correspondant aux problmes de recherches encore non rsolus sont atteindre : - La dnition dun formalisme de modlisation des donnes et des mtadonnes de lentrept, ce formalisme doit permettre la fois de le dcrire et de le manipuler (pour le faire voluer ou pour vrier ses proprits). - Des algorithmes de traitement smantique de la triple htrognit de conceptualisation, de temps et de granularit. - Des algorithmes doptimisation des performances des ressources matrielles et logicielles de lentrept pour fournir ecacement les outils de Data Mining. Lapproche envisage propose : lintgration smantique des dirents schmas sources, la constitution dun schma de lentrept, la dnition et la mise jour des vues, la prise en compte de limprcision (des donnes mal connues ou incertaines dans lentrept), la prise en compte du temps et de la granularit, la vrication de la cohrence et de la consistance et loptimisation des ressources (paralllisme) [Evo97].
2.6
Aspects temporels des entrepts
Malgr une conception attentive et soigneuse, la structure dune base de donnes est sujette de nombreux changements. Bien que les estimations dirent, la plupart saccordent sur le fait que plus de 50% du travail des dveloppeurs se focalise sur les modications du systme aprs leur implantation [Rod95]. Pour rsoudre le problme de perte de donnes aprs des changements du schma, le concept dvolution de schma t introduit pour rcuprer les donnes existantes. Cette rcupration se ralise par le biais de ladaptation des donnes au nouveau schma. Nanmoins, dans les systmes qui doivent grer des donnes historiques, lvolution
38
de schma nest pas susante et la maintenance de plusieurs schmas est requise [GM02]. Cette problmatique a donne naissance la notion de versions de schmas. Nous traitons les direntes nuances entre les dnitions de modication, dvolution et de version de schma. Nous commenons avec ltat actuel des versions dans les dirents modles existants. Ensuite nous traitons le sujet des versions de schmas, la gestion des donnes intensionnelles et extensionnelles, les changements et leur reprsentation. Pour nir, la dernire section donne une brve description des oprations primitives.
2.6.1
Etat courant des versions
Nous tudions ce paradigme dans les divers modles de donnes existants. Ceux que nous abordons sont le modle relationnel, le modle objets, les bases de donnes temporelles et nous terminons avec les entrepts de donnes. 2.6.1.1 Modle relationnel
La gestion des volutions dans la structure des bases de donnes a donn naissance aux concepts de modication, dvolution et de versions de schmas. La distinction entre les dirents concepts reste un peu imprcise. Dans la suite nous donnons chaque dnition [DGW+ 98, Rod92, Rod95, TS93] : La 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 modication du schma de la base sans perdre les donnes existantes. Les versions de schma permettent laccs toutes les donnes, de faon rtrospective et prospective, travers des interfaces de versions dnies par lutilisateur. A partir de ces dnitions, nous constatons que mme si lvolution de schma permet leur actualisation, elle nimplique pas un support historique complte du schma. Versions et bases de donnes : Dans la suite nous traitons les conditions pour quune base de donnes supporte la gestion de versions [ABCM99, CW98, KU95, Mun93]. La fonctionnalit des systmes qui supportent les versions est reprsente par lensemble des oprations utiliser. Les oprations fondamentales sont la cration de nouvelles versions et laccs aux donnes des direntes versions. Nanmoins, le systme doit fournir dautres oprations sur les versions : dnition des noms ou des identications, eacement, modication, transformer une version dans une version
2.6 Aspects temporels des entrepts immuable1 , combinaison de versions, etc.
39
La transparence des versions reprsente la capacit daccder aux donnes sans avoir la ncessit de manipuler le systme de versions. Il existe trois manires daborder les relations entre le modle de donnes et le modle de versions. La premire consiste placer le modle de version au-dessus du modle de donnes. De cette faon, le modle de version est reprsent par un schma dont le modle de donnes sous-jacent est indpendant du modle de versions. Lavantage de cette solution est la simplicit du modle de donnes. Par contre, cette approche ne supporte pas le stockage des versions de faon ecace. De plus, la gestion des transactions du SGBD ne considre pas le systme de versions. PCTE (Version Management in the PACT Integrated Software Engineering) et CoMa [CW98, EJWG03] sont deux exemples de systmes reposant sur cette approche. La deuxime solution construit un modle de version lintrieur du modle de donnes. Cette approche requiert lextension du modle de donnes pour supporter les versions, ainsi que la modication du langage de requtes pour fournir un mcanisme dcriture de requtes une base de donnes supportant des versions. Ce processus dextension du modle complique la structure des donnes ainsi que la formulation des requtes. De plus, le modle de version dpend fortement du modle de donnes. Quelques systmes qui suivent cette voie sont DAMOKLES [CW98, EJWG03] et Adele [Mun93, EJWG03]. La dernire approche reprsente le modle de version en-dessous du modle de donnes. Dans cette alternative, le modle de version est compltement orthogonal au modle de donnes. Cette approche peut tre atteinte au travers dun moteur de version qui fournit un stockage des deltas2 et des rgles de conguration utilises dans la formulation des modles de version spciques. Le moteur de version est indpendant du modle de donnes et peut tre associ nimporte quel modle de donnes. Les systmes qui utilisent cette approche sont par exemple ICE et COV [CW98]. Pour nir, dans [CGJM01], les auteurs utilisent les versions dentits persistantes et le partage entre versions des parties ayant mme valeur (quils appellent versions locales) par plusieurs versions (versions globales), pour prsenter deux approches : ascendante et descendante. La premire utilise lidentication ascendante des versions locales, le partage incassable (qui permet seulement linsertion de nouvelles versions et la lecture des versions stockes) et le stockage par entit. Lapproche descendante utilise lidentication de versions globales, le partage cassable (qui permet en plus les mises jour des versions) et aussi le stockage par entit. Ils prsentent aussi les conclusions de chaque approche.
1 2
Une version immuable ne permet pas de changements. Les deltas reprsentent les dirences entre versions.
40 2.6.1.2
Entrepts de donnes multidimensionnelles et aspects temporels Modle objets
Dans ce paradigme, deux types de changements sont signicatifs : les changements dans la dnition dune classe (le contenu dun noeud) et les changements dans la structure (les artes et les noeuds). Ces changements reprsentent lensemble des oprations primitives qui permettent de manipuler lvolution de la classe. Les changements dans la dnition de la classe incluent les oprations de cration et de suppression des attributs et des mthodes qui appartiennent une classe. Les changements dans la structure, correspondent aux oprations de cration et de suppression dune classe, ainsi que la modication des relations entre les classes [MBJ+ 02, GM99, GMS00, FGM00, Lau96, RR97]. Versions de schmas, de classes et de vues : Dans lenvironnement de bases de donnes multi-utilisateurs, une fonctionnalit importante est la capacit des utilisateurs visualiser et manipuler direntes collections dobjets via direntes versions de schma. Il existe trois approches pour reprsenter les volutions : la version de schma, la version de classes et les schmas de vues [Lau96, KC88, FGM00, MS93, Odb92]. Dans lapproche de versions de schma, chaque version reprsente une conguration cohrente de versions au niveau de la classe. Le systme fournit un ensemble doprations primitives pour la gestion de lvolution. Quand nous drivons une nouvelle version de schma SVj partir de SVi , les classes existantes peuvent tre modies ou eaces et des classes nouvelles peuvent tre cres pour SVj . Si une classe C est modie, on peut dire que SVi et SVj contiennent direntes versions de la class C, dnote par SVi .C et SVj .C respectivement. Toutes les versions dun schma sont stockes dans une structure qui garde les relations de drivation entre toutes les versions de schmas. La deuxime approche traite lvolution au niveau de la classe. A la dirence des versions de schma, si une version nouvelle Vj de la classe C est drive de la version Vi , toutes les sous-classes de la classe C doivent faire rfrence la nouvelle version de C. Ceci signie quune nouvelle version doit tre cre pour chacune des sous-classes de C. Le schma de vues peut tre utilis pour simuler des modications de schma. Lide gnrale est de manipuler la base de donnes seulement travers des vues. Dans ce cas, les changements peuvent tre simuls en changeant les vues et les applications peuvent utiliser direntes vues (comme dirents schmas) sans changer la base de donnes sous-jacente. De nombreux travaux [MBJ+ 02, GM99, GMS00, KC88, Lau96] se sont focaliss sur la premire approche, car elle manipule la granularit de versions au niveau du schma. Ceci permet une vue globale de lensemble des classes lintrieur dune version de schma.
2.6 Aspects temporels des entrepts 2.6.1.3 Bases de donnes temporelles
41
Les bases de donnes temporelles permettent de reprsenter et de manipuler lhistoire des donnes (donnes extensionnelles). Le support de versions de schmas dans les bases de donnes temporelles prsente deux problmes fondamentaux. Le premier est le stockage et la manipulation de lensemble de versions de schma appele la smantique du changement. Ce problme implique la vrication et la maintenance de la consistance du schma aprs des changements. Le second problme reprsente la gestion et la manipulation des versions de donnes, nomme aussi la propagation des changements. Cette problmatique concerne la consistance des donnes existantes avec la nouvelle version du schma [MBJ+ 02, GM02, GMS00, ME97, RGMS01]. Laspect temporel est associ aux objets, aux versions, aux attributs et aux relations. Dans les bases de donns temporelles, le temps de transaction correspond linstant o un fait est enregistr dans la base. Alors que, le temps de validit dun fait correspond aux instants auxquels ce fait est vrai dans le monde modlis. Dans la suite, nous traitons chaque dnition. Temps de transaction, temps de validit et bitemporel : La manipulation de la dimension temps dans les versions de schma correspond soit la version de schma au temps de transaction, soit au temps de validit, soit les deux. Cette dernire appele bitemporel, reprsente la combinaison des deux premires [Dum00, GM02, ME97, Sno99]. Pour le temps de transaction, les modications appliques dans une version de schma sont eectives au moment de leur dnition. Dans cette approche, la gestion du temps est transparente lutilisateur. Le schma courant peut tre modi et les changements sont appliqus sans aucune rfrence au temps. Cette approche ne permet aucun changement sur les versions successives du schma. Nanmoins, toutes les versions sont disponibles pour laccs et la manipulation des donnes. La version de schma en temps de validit est ncessaire quand les modications des versions de schmas rtroactives ou proactives doivent tre supportes. Dans ce cas, chaque version de schma est assigne une validit temporelle. Cette approche permet des versions de schmas multiples valides dirents moments. Toutes les versions de schmas sont disponibles aussi bien pour laccs et la manipulation des donnes, que pour la ralisation des modications futures. La version de schma bitemporelle reprsente une combinaison du temps de transaction et du temps valide. Elle supporte les modications des versions de schmas courantes, comme dans la premire approche et aussi les modications des versions de schmas de faon rtroactive et proactive. Par rapport la version de schma en temps valide, lhistoire complte des changements du schma est maintenue, car aucune version de schma nest abandonne.
42
Entrepts de donnes multidimensionnelles et aspects temporels Le tableau 2.11 dcrit un exemple de relation bitemporelle en TSQL2 [Sno95]. Nom SERNA SERNA SERNA Salaire 1000 1500 1600 Temps de transaction 1-07-2000 - 31-12-2000 1-01-2002 - 31-01-2002 1-01-2003 - UC3 Temps de validit 1-07-2000 - 31-12-2001 1-01-2002 - 31-12-2002 01-01-2003 - 31-12-2004
Tab. 2.11 Exemple de relation bitemporelle
2.6.1.4
Le temps et les entrepts de donnes
Les actualisations ralises dans les sources des donnes doivent tre reportes sur lentrept. Ce processus requiert une transaction de maintenance. Dans les entrepts, une problmatique trs importante est la faon dexcuter les transactions de maintenance sans perturber les requtes des utilisateurs. La plupart des systmes commerciaux garantissent la consistance sans blocage, en excutant une seule et unique transaction de maintenance, normalement pendant la nuit, quand lentrept est hors de service [QW97]. Les changements eectus dans les sources peuvent tre appliqus aussi bien au contenu des donnes qu leur structure. Dans [Ben02], lauteur propose une infrastructure adaptable pour lvolution des entrepts de donnes. Il prsente un ensemble doprateurs dvolution de schmas multidimensionnels, ainsi quun langage de description de donnes multidimensionnelles. Nanmoins, aucun support historique nest prsent dans ce travail. En ce qui concerne lapproche des versions de schmas, la plupart des recherches se sont focalises dans la propagation des changements sur les donnes [KC02, KM99, QW97, TU98]. Dans [KC02], par exemple, les auteurs proposent un contrle de concurrence multi-version adapt pour les entrepts de donnes (MVCC-DW) en utilisant un serveur multidimensionnel OLAP (MOLAP). MVCC-DW permet des actualisations de lentrept pendant que des requtes sont excutes sur les donnes. Dans [QW97], les auteurs proposent un mcanisme appel 2VNL (Two-Version No-Locking). Ce mcanisme permet quune requte puisse continuer utiliser une vue, alors quune transaction de maintenance crit la nouvelle version de cette vue. Dans [ZR98, RKZ+ 99], les auteurs proposent une approche pour la maintenance de la consistance dans un environnement concurrent supportant des changements sur les donnes et sur leur schma. Ils ont dvelopp un systme appel EVE (Evolvable
3 Le symbole UC (Until Changed) indique que lintervalle de transaction de la version va jusqu la date daujourdhui.
43
View Environment), qui utilise un langage nomm Evolvable-SQL pour le support du processus dvolution des vues, et un processus de rcriture de vues pour leur adaptation quand le schma volue. Cependant, dans lenvironnement des entrepts nous considrons comme essentielles la gestion et la manipulation des donnes historiques, aussi bien que des donnes courantes. Lapproche des versions de schma a t utilise principalement pour la cohrence des donnes et de leurs schmas courants. Nous proposons lutilisation des versions de schma, comme une alternative pour la gestion et la manipulation des donnes courantes et historiques.
2.6.2
Espace de versions
Dans cette partie, nous traitons de lespace de versions. Dabord, nous ranons la dnition de version de schma. Ensuite, nous expliquons leurs types ainsi que les graphes de version, puis, nous terminons avec une description de lensemble des oprations utiliser lors des changements eectuer. Versions de schmas : Il est important dans la gestion des versions de distinguer la rcupration et la mise jour des donnes. Pour rpondre ce besoin, le concept de versions de schma a t divis en version partielle et complte [CW98, Rod95, WMC01] : Version partielle de schma : Les donnes stockes sous nimporte quel schma historique peuvent tre visualises sous tout autre schma. Nanmoins les donnes peuvent seulement tre actualises au travers du schma courant. Version complte de schma : Les donnes stockes sous nimporte quel schma historique peuvent tre visualises et actualises sous tout autre schma. Un modle de version dnit les lments qui ont volus, les proprits communes partages et les deltas. Chaque version doit tre identie de faon unique, travers un identicateur de version VID. Les deltas reprsentent les dirences entre deux versions. Un delta peut tre symtrique ou direct. Un delta symtrique entre deux versions v1 et v2 , reprsente lensemble de diffrences entre elles, cest dire : (v1 , v2 ) = (v1 - v2 ) U (v2 - v1 ) O le symbole correspond la dnition du delta. Un delta direct reprsente une squence doprations de changements op1 , ... ,opm . Quand ces changements sont appliqus sur une version v1 , ils produisent une
44
nouvelle version v2 . (v1 ,v2 ) = op1 , ... ,opm Cest--dire, v1 gnre v2 : v1 v2
2.6.3
Versions bases sur ltat et sur les changements
Une version est dnie comme un tat dun objet variant dans le temps. Les modles de versions peuvent considrer les dirents tats des objets. Dans cette approche, les versions sont dcrites par rapport aux rvisions et aux variantes. Une rvision est une version qui remplace la prcdente. Lensemble des versions qui coexistent sont appeles des variantes. Dans les modles bass sur les changements, une version est dcrite par rapport aux modications. Dans cette approche, chaque changement est aect un identicateur (CID) ainsi que des attributs pour caractriser les causes et/ou la nature du changement. Ainsi, une version est dcrite par rapport aux changements quelle implante. Lespace des changements peut se reprsenter de deux faons (Figure 2.10).
changements b c1 v1 c3 v2 versions v3 c3 v1 v4 c4 v4 v2 a) Reprsentation en matrice b) Graphe de version avec des changements explicites v3 c6 c2 c4 c5 c2 c3 c4 c5 c6 c1
Fig. 2.10 Espace des changements La partie a) de la gure montre la reprsentation en matrice utilise dans le systme Aide de camp [CW98, Mun93]. Les lignes et colonnes correspondent des versions et des changements. Par exemple, lensemble des changements c1 , c2 , c3 et c4 construisent la version v2 . La partie b) reprsente un graphe de versions o b dnote la racine partir de laquelle tous les changements dune version sont dcrits de manire explicite. Au contraire, dans lapproche base sur ltat, les changements
45
sont anonymes de faon ce que nous puissions les dduire partir de la topologie du graphe de version.
2.6.4
Graphes de version
Un graphe de version consiste en un ensemble de noeuds et dartes qui correspondent une version et leur relations [Mun93, CW98]. La plupart des systmes utilisent une organisation un ou deux niveaux que nous exposons dans la suite. Types dorganisations Un graphe de version dun niveau consiste en un ensemble de versions qui sont connectes par leurs relations successeurs. Ce type de graphes reprsente lhistorique de lvolution dun lment. Par exemple, si la version v2 est un successeur de v1 , cela signie que la version v2 a t drive partir de v1 . La gure 2.11 reprsente dirents types de graphes de version.
v1
v1
v1
v2 v2
v4
v2
v3
v3 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 pouvons citer PCTE et DAMOKLES [CW98, EJWG03]. Dans le cas dorganisation deux niveaux, un graphe de version est constitu dun ensemble de branches, dont chacune est compose dune squence de rvisions. Cette approche gre deux types de relations : successeurs ( lintrieur dune branche) et descendants (entre les branches). La gure 2.12 montre ce type dorganisation. Les changements excuts dans une branche peuvent tre propags aux autres branches. Nous pouvons avoir comme rsultat un Graphe Direct Acyclique. Nanmoins, les branches ne sont pas relies et elles continuent dexister. Le systme ClearCase [CW98, EJWG03] utilise cette approche.
46

b1 v1 b2 v1 v2 b3 v1
branche successeur descendants
b4 v1 v2 v3 v2
fusion
v2
v3
v4
v3
v4
Fig. 2.12 Graphe de version deux niveaux
2.6.5
Gestion de versions extensionnelles et intensionnelles
La gestion de versions extensionnelles ou de versions de donnes, concerne la reconstruction de versions cres priori. Elle requiert lidentication de la version (VID) et limmutabilit de la version. Une version est immuable si elle nautorise pas de changements, ce qui permet dassurer une rcupration sre des donnes. Finalement, la reconstruction de versions demande aussi un systme de stockage ecace [CW98, ME97, MBJ+ 02]. En ce qui concerne la gestion de versions intensionnelles (ou versions de schmas), elle traite de la construction de nouvelles versions partir des descriptions bases sur des proprits. Cette approche est trs utilise quand un logiciel volue en plusieurs rvisions et variantes o beaucoup de changements doivent tre combins. Les systmes qui supportent des versions intensionnelles doivent fournir un mcanisme pour rsoudre le problme dexplosion des combinaisons et de contrle de cohrence. Ce mcanisme permet seulement la construction de versions pouvant satisfaire certaines contraintes [CW98, ABCM99]. Dans [ABCM99], les auteurs prsentent un modle uni de versions extensionnelles. Ce modle utilise un mcanisme appel version concentration pour rduire le nombre de combinaisons prendre en compte. Dans [MBJ+ 02], les auteurs utilisent un modle temporel de version (TVM) pour permettre le stockage de versions dobjets, ainsi que toute lhistoire des changements pour chaque version. Finalement, dans [GM02], les auteurs prsentent un modle formel pour des versions temporelles de schmas dans les bases de donnes orientes objets. Ils proposent un schma volu qui consiste en une collection de versions de schmas dnies sur un ensemble de noms de classes et dattributs.
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 lensemble de changements possibles excuter sur le modle. Par exemple, dans le contexte des bases de donnes orientes sujets [Lau96, GM99], cette liste a t groupe en : changements de schma sur un noeud et changements de schma sur des artes. La premire catgorie groupe les oprations agissant sur les lments supports par le modle de donnes orientes-sujets, comme les attributs et les classes. Tandis que les changements sur des artes fournissent le support pour lintgration des caractristiques dune version de schma avec des versions de schmas appartenant dautres noeuds. En plus, dans [GMS00, GM02] les auteurs introduisent la notion de temps pour la cration des versions temporelles. A chaque version temporelle nouvelle est associe un temps-valide pertinent. Ainsi, les donnes stockes peuvent tre accdes par le biais des versions de schmas du pass, du prsent et du futur.
2.7
Bilan
Dans ce chapitre, nous avons trait le sujet des entrepts de donnes qui tendent les concepts et la technologie traditionnelle des bases de donnes pour crer des systmes daide la dcision. En utilisant larchitecture dun entrept de donnes, nous avons expliqu les diffrents composants quil intgre, comme les diverses sources, les types de donnes et les dirents outils pour arriver la visualisation de linformation. Nous avons dcrit les dirents modles multidimensionnels pour la construction dun entrept de donnes, ainsi que les direntes oprations pour la manipulation des donnes multidimensionnelles. Lavant dernire partie a t consacre aux types de serveurs dcisionnels. Dans un premier temps, nous avons dcrit le serveur ROLAP qui utilise une base de donnes relationnelle, tant au niveau du stockage quau niveau de la gestion de donnes. Dans cette architecture, les stratgies doptimisation reprsentent le point principal qui distingue les systmes existants. Nous avons donn galement une description des systmes ROLAP existants sur le march. Le serveur MOLAP a t la deuxime architecture que nous avons traite. Ces types de systmes utilisent une base de donnes multidimensionnelle pour le stockage des donnes. Les systmes MOLAP doivent grer le problme de donnes clairsemes, quand seulement un nombre rduit des cellules dun cube contiennent
48
une valeur de mesure associe. La faon de rsoudre cette problmatique, par les produits commerciaux, reprsente un des plus importants critres pour les systmes MOLAP. Nous avons aussi donn une liste des produits existants. La troisime architecture que nous avons dcrite est le serveur HOLAP. Un systme de ce type supporte et intgre un stockage de donnes multidimensionnelles et relationnelles. La plupart des systmes commerciaux utilisent une approche hybride pour manipuler les informations de lentrept avec un moteur ROLAP, tandis que pour la gestion des magasins des donnes (data marts), ils utilisent lapproche MOLAP. Finalement, nous avons dcrit quelques produits commerciaux existants. En ce qui concerne les projets de recherche dans le domaine des entrepts de donnes, nous avons dcrit succinctement WHIPS, SIRIUS, DWQ et EVOLUTION. Les deux premiers sont centrs sur des problmatiques lies lextraction et la maintenance incrmentale des donnes. Le projet de la communaut Europenne DWQ traite de la qualit des entrepts, tandis que le dernier, le projet EVOLUTION du laboratoire PRiSM Paris, propose le dveloppement dune mthodologie et doutils pour laide la conception et lvolution des entrepts. Dans la dernire partie, nous avons dcrit lapproche des versions de schma. Dabord nous avons donn ltat courant des versions dans les modles de donnes existants. Ensuite nous avons dcrit lespace de versions, leurs types, la gestion de donnes extensionnelles et intensionnelles, ainsi que les oprations primitives utiliser. En ce qui concerne lvolution de schmas, elle permet la rcupration des donnes existantes par le biais de leur adaptation au nouveau schma. Nanmoins, lvolution nimplique pas un support historique du schma et par consquent ne considre pas un mcanisme pour la visualisation des donnes travers des schmas volus. Dans le paradigme des entrepts la manipulation de donnes historiques reprsente une tche essentielle. Par consquent le concept dvolution de schma nest pas susant et il est ncessaire tablir une stratgie spcique pour rpondre cette ncessit. Nous considrons lapproche de versions de schma comme une alternative aux systmes qui doivent grer et manipuler des donnes historiques. Dans le cas prcis du projet ADELEM, nous proposons lutilisation de versions de schma pour grer les aspects temporels de lentrept de donnes. Pour aboutir cela, nous devons tablir un mcanisme pour la gestion, le stockage et la visualisation de lensemble de donnes (courantes et historiques) mdicales. Nous prsentons dans la suite une architecture et un modle que nous proposons pour un systme dcisionnel dans le contexte mdical.
Chapitre 3 Architecture et modle pour un entrept de donnes mdicales

La conception dun entrept de donnes est une tche complexe et dlicate. Elle se compose de plusieurs tapes. Dans un premier temps, nous devons analyser lensemble des sources de donnes internes et externes. Cette analyse sert aussi bien la slection de lensemble de donnes stocker dans lentrept, qu la slection des outils requis pour lextraction et la transformation de ces donnes avant leur stockage. La deuxime tape consiste organiser ces donnes lintrieur de lentrept. Pour ce faire, nous devons concevoir le modle multidimensionnel utiliser ainsi que dnir lensemble optimal de vues matrialiser. Finalement, la troisime tape consiste dterminer les outils ncessaires pour la visualisation de lensemble des donnes. Dans le chapitre prcdent, nous avons prsent larchitecture typique dun entrept de donnes. Dans cette architecture, nous trouvons les trois tapes dj dcrites : extraction-intgration, organisation et interrogation. Nanmoins, en ce qui concerne le concept dorganisation, nous considrons quil est pertinent de faire une distinction entre la structuration et lorganisation. Pour nous le terme de structuration correspond la conception du modle multidimensionnel et la slection des vues matrialiser, tandis que lorganisation entrane la gestion de lensemble de donnes (intensionnelles et extensionnelles) courantes et historises stockes soit lintrieur, soit lextrieur de lentrept. Ce chapitre prsente la premire partie du processus de structuration, savoir, la description de la conception dun modle multidimensionnel. Nous proposons dabord une architecture pour un systme dcisionnel. Cette architecture comprend trois composants qui traitent les deux derniers processus (la structurationorganisation et linterrogation). Dans une deuxime partie, nous dnissons un mtamodle multidimensionnel qui est compos de trois classes : Cube, Dimension et Hirarchie. Ce mtamodle sert la conception dun modle multidimensionnel avec quatre dnitions : le schma dune base multidimensionnelle, dun cube, dune dimension et dune hirarchie. Nous donnons aussi la dnition dinstances de chacune 49
50 des classes.
Architecture et modle pour un entrept de donnes mdicales
Nous avons utilis des donnes mdicales relles, ainsi, les dernires parties de ce travail prsentent lapplication de notre modle sur ces donnes.
3.1
Architecture dun systme dcisionnel
Dans cette partie, nous dcrivons larchitecture qui a t conue. Elle est base sur trois composants. Le premier est lInterface pour la Gnration (Semiautomatique) dIndicateurs. Nous plaons ce composant lintrieur du processus dinterrogation. Les composants de lEntrept de donnes et les Versions de Schmas Bitemporels font partie du processus de structuration-organisation. La gure 3.1 montre notre architecture ainsi que les dirents liens entre les composants :
Interface graphique
R s u l t a t
Gestionnaire de Requtes
Entrept de donnes
Gestionnaire dEvolution
Sources de donnes
Donnes rsumes et de dtail courantes
Fig. 3.1 Architecture propose dun systme dcisionnel
3.1.1
Interface graphique pour la Gnration (Semi - automatique) dIndicateurs
Nous dcrivons les principaux lments de linterface graphique [SA04] : Interface Graphique : Outil graphique o les utilisateurs peuvent choisir les divers composants (relations, mesures et proprits) correspondant lindicateur
3.2 Mtamodle Multidimensionnel
51
exprim. Lobjectif de linterface est de faciliter la gnration semi-automatique des requtes. Gestionnaire de Requtes : Composant pour traduire le mta-schma en schma local (relationnel), pour gnrer le code SQL et pour excuter la requte sur les donnes de lentrept. Rsultat : Les donnes qui correspondent la requte et qui doivent tre aches par linterface graphique. Le chapitre 4 contient une description dtaille de notre interface.
3.1.2
Entrept de donnes
Entrept de Donnes : Reprsente la collection des donnes consulter. Lentrept contient aussi bien des donnes de dtail que rsumes. Par exemple : Donnes de dtail : "Le nombre de ventes par magasin, par produit et par ville du mois de janvier 2000". Donnes rsumes : Nous pouvons avoir des donnes lgrement ou fortement rsumes. Par exemple, "les ventes mensuelles par magasin et par produit des dix dernires annes" sont des donnes faiblement rsumes, tandis que "les ventes semestrielles par rgion des dix dernires annes" sont fortement rsumes. Sources : Elles rassemblent lensemble de sources internes, par exemple, les dirents systmes oprationnels qui sont utiliss pour mettre jour les donnes stockes dans lentrept. Les sources externes sont des donnes qui nappartiennent pas lentreprise et qui sont souvent achetes, par exemple, les donnes gographiques.
3.1.3
Il est responsable de la gestion, du stockage et de la visualisation des donnes historises. Nous proposons lutilisation des versions de schmas bitemporels pour la gestion de lvolution des donnes intensionnelles et extensionnelles. Le chapitre 5 dcrit en dtail ce composant.
3.2
Mtamodle Multidimensionnel
Il reprsente la structure pour la mise en oeuvre des modles de type multidimensionnel (cf. Section 2.3) qui se compose des mtaclasses1 . La gure 3.2 montre les
Une mtaclasse est une classe qui modlise des classes [PCTM02, PCTM03]. Nous avons utilis UML (Unied Modeling Language) pour la spcication du mtamodle multidimensionnel.
1
52
Mtaclasses Cube, Dimension et Hirarchie qui constituent notre MtaSchma.
<<Mtaclasse>> MtaSchma +/cube: Cube +/dimension: Dimension 1
1.. <<Mtaclasse>> Cube +Strings[]: Mesure_nom +Strings[]: Type +Strings[]: Cl +/dimension: Dimension 1..
1..
<<Mtaclasse>> Dimension +Strings[]: Attribut_nom +Strings[]: Type +Strings[]: Cl_P +Strings[]: Cl_E +/hirarchie: Hirarchie 1..
*
{La Cl de la mtaclasse Cube est compose de lensemble des Cl_P de ses mtaclasses Dimensions}
1..
*
{La Cl_P dune mtaclasse Hirarchie ne peut pas relier la mtaclasse Cube associe sa mtaclasse Dimension (granularit)}
{La Cl_P est contenu ou est gale lensemble Attributs_noms}
0..1 <<Mtaclasse>> Hirarchie +Strings[]: +Strings[]: +Strings[]: +Strings[]: Attribut_nom Type Cl_P Cl_E
0..
Fig. 3.2 Mtamodle Multidimensionnel La spcication du notre mtamodle, nous permet de reprsenter et de visualiser les dirents composants. Ceci, nous a permis dabord pour identier les associations et leur cardinalit, mais principalement pour identier lensemble de restrictions, soit niveau des associations, soit lintrieur dun composant.
3.2.1
Relations entre les mtaclasses
Pour relier les mtaclasses, nous pouvons utiliser les types de relations suivants [PCTM03, Var00, VQVJ00] : Association : Cest une relation entre deux classes qui reprsente les connections entre leurs objets. Une association est bidirectionnelle ou unidirectionnelle. Agrgation : Elle spcie une relation de composition et peut tre : Partage : Un lment composant lintrieur dun ou de plusieurs lments composites ; ou
53
Compose : Lensemble de composants intgre llment composite. Gnralisation : Cest une relation entre une classe plus gnrale et une classe plus spcique. Dpendance : Cest une relation entre deux classes o les changements appliqus sur la classe indpendante aectent la classe dpendante.
3.2.2
Contraintes entre les mtaclasses
Les contraintes permettent de complter la spcication du mtamodle. Ils existe deux types de contraintes : syntaxiques ou smantiques. Par exemple, la contrainte : une classe est reprsente graphiquement par un rectangle compartiment, est une contrainte syntaxique. Nous avons class les contraintes smantiques de la manire suivante : Contraintes de cardinalit : Reprsentent le nombre de liens qui peuvent exister entre deux classes. Par exemple : 0..1 (zro ou un), 1 (un et un seul), * (zro plusieurs), M..N (de M N),... Contraintes dintgrit rfrentielle : Reprsentent le fait quun ensemble dattributs qui appartient une classe apparat dans une autre classe. Par exemple, soient r1 (R1 ) et r2 (R2 ) deux classes avec les cls primaires C1 et C2 . Le sous-ensemble de R2 est une cl externe qui fait rfrence C1 de r1 , si pour chaque t2 de r2 existe une n-uplet t1 de r1 tel que t1 [C1 ] = t2 []. Pour dcrire des contraintes additionnelles qui ne sont pas exprimes directement par la structure du mtamodle, nous pouvons utiliser le langage OCL (Object Constraint Language) fourni par UML ou dcrire les contraintes en langue naturelle. Par exemple, nous avons la contrainte : {La Cl_P dune mtaclasse Hirarchie ne peut pas relier la mtaclasse Cube associe sa mtaclasse Dimension (granularit)}.
3.2.3
Description des Mtaclasses
Nous dcrivons les mtaclasses qui composent le mtamodle multidimensionnel : Mtaclasse MtaSchma : La mtaclasse MtaSchma est compose des mtaclasses Cube et Dimension. Elle reprsente un schma multidimensionnel compos des classes Cube et Dimension.
54
Mtaclasse Cube : La mtaclasse Cube modlise des classes de type Cube. Elle reprsente les direntes mesures danalyse. Une mtaclasse Cube est reprsente par deux ensembles de couples : Mesure_nom : string, Type : string reprsentent le(s) sujet(s) danalyse. Cl : string, Type : string reprsentent lensemble des mtaclasses Dimensions (perspectives danalyse) qui appartiennent la mtaclasse Cube. Mtaclasse Dimension : Cette mtaclasse modlise des classes de type Dimension. Elle reprsente une perspective danalyse ou un axe de localisation dune cellule dun Cube. Une mtaclasse Dimension est compose densembles de couples de type : Attribut_nom : string, Type : string lintrieur de la classe Dimension. ensemble dattributs textuels
Cl_P : string, Type : string identicateur unique pour la classe Dimension. Cl_E : string, Type : string Dimension et Hirarchie. reprsentent des liens entre les classes
Mtaclasse Hirarchie : Elle reprsente les relations de dpendance entre les niveaux lintrieur dune classe Hirarchie. Une mtaclasse Hirarchie est compose des ensembles de couples de type : Attribut_nom : string, Type : string tuels dans la classe Hirarchie. Cl_P : string, Type : string chie. Cl_E : string, Type : string type Hirarchie. reprsentent des paramtres tex-
identicateur unique pour la classe Hirar-
reprsentent des liens entre les classes de
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 descriptions des mtaclasses de la section prcdente pour aboutir la dnition dune base de donnes multidimensionnelle. Nous sommes partis de travaux existants [Ben02, GM02, HMV99a, HMV99b, LW96, Qui99] pour la dnition dun schma et dune instance. La plupart des travaux proposent un ensemble doprateurs pour
55
lvolution dun systme multidimensionnel. Dans [GM02], lauteur propose un modle formel des versions de schmas temporelles pour des bases de donnes objets. Nous faisons la dirence entre une dimension et une hirarchie. Ainsi, notre modle se compose de quatre lments essentiels : une base multidimensionnelle, un cube, une dimension et une hirarchie. Nous donnons pour chacun la dnition de schma et dinstance. Nous supposons lexistence de : 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 {a1 , ..., a n } tel que i=1,...n ai DOM. De mme pour chaque dimension dD, nous associons un ensemble de valeurs {b1 , ..., bn } tel que i=1,...n bi DOM. Finalement, pour chaque niveau lL, nous associons un ensemble de valeurs {f1 , ..., fn } tel que i=1,...n fi DOM. Nous supposons lexistence des fonctions suivantes : measuredom : M E(DOM)2 , qui retourne lensemble des valeurs associes une mesure. propertydom : P E(DOM), qui retourne lensemble des valeurs associes une proprit. levelset : H E(DOM), qui retourne lensemble des membres associs un niveau. Dnition 3.1 : Schma de base de donnes et dinstance multidimensionnelle. Le schma dune base de donnes multidimensionnelle est un n-uplet SM = (Cs , Ds , Hs , R), o Cs est un ensemble de schmas de cubes, Ds est un ensemble de schmas de dimensions, Hs est un ensemble de schmas de hirarchies et R est un ensemble de contraintes.
2
Lensemble E(A) est lensemble des parties de A. E(A) = {X|X A}.
56
Linstance dune base multidimensionnelle est un n-uplet IM = (Ci , Di , Hi , Ri ), o Ci est un ensemble dinstances de cubes tel que, pour chaque instance ci Ci , il existe un schma cs Cs avec ci conforme cs . Di est un ensemble dinstances de dimensions tel que, pour chaque instance di Di , il existe un schma ds Ds avec di conforme ds . Hi est un ensemble dinstances de hirarchies tel que, pour chaque instance hi Hi , il existe un schma hs Hs avec hi conforme hs . Finalement, Ri est un ensemble dinstances de contraintes tel que chaque instance ri Ri . Dnition 3.2 : Schma et instance du cube. Un schma de cube est un n-uplet Cs = (cn , M, D), o cn C est le nom du cube, M est un ensemble de mesures et D est un ensemble de dimensions. Une instance de cube est un ensemble de cellules. Une cellule est un n-uplet Ic = (cn , {v1 ,...,vk }, {d}), o cn est le nom du cube, {v1 ,...,vk } est lensemble de mesures tel que i=1,...n vi measuredom(mi ) avec mi M et dD est lensemble de dimensions. Par exemple, la gure 3.3 reprsente le schma et linstance du cube Ventes.
Produit
S U M
TV
CS
CP
Produit Magasin
Magasin
Lyon Grenoble Annecy SUM
01/01/2000 Quantit
Temps Temps
02/01/2000
03/01/2000
SUM All
Schma du cube Ventes
Instance
Fig. 3.3 Schma et une instance possible du Cube La partie gauche montre le schma du cube de nom Ventes. Lensemble {Temps, Magasin, Produit} sont les axes du cube et la mesure est Quantit. La partie droite montre une instance de ce cube. Par exemple, nous avons 100 Tlviseurs vendus dans le magasin dAnnecy le 1er janvier 2000. Dnition 3.3 : Schma et instance de dimension. Un schma de dimension est un n-uplet Ds = (dn , P, H), o dn D est le nom de la dimension, P est lensemble de proprits de la dimension dn et H est lensemble
3.2 Mtamodle Multidimensionnel de hirarchies.
57
Une instance de dimension est un n-uplet Id = (dn , {(v1 ,...,vi )}, {h}), o dn D est le nom de la dimension, (v1 ,...,vi ) est un ensemble de proprits tel que j =1,...n vj propertydom(pj ) avec pj P. Enn, hH est lensemble de hirarchies qui appartiennent dn . Par exemple, le schma de la dimension Magasin est dni de la manire suivante : dn = Magasin {p1 ,...pi } = {Cle_Magasin, Libelle_Magasin } hn = H_Geo (cf. Dnition 3.4) Schma et instance de hirarchie. Pour nous un schma et une instance de hirarchie peuvent prendre la forme dun graphe squentiel ou dun graphe acyclique dirig reprsentant les hirarchies de niveaux. Chaque noeud du graphe contient un niveau et un arc entre deux noeuds reprsente une association entre les niveaux contenus par les noeuds. Nous supposons lexistence de deux noeuds, nomms base et sommet, partir desquels tous les autres noeuds peuvent tre atteints directement ou par transitivit. Le noeud sommet contient le niveau de la hirarchie. La gure 3.4 prsente un exemple de graphe squentiel. Comme exemple de graphe acyclique dirig, nous pouvons considrer le schma de hirarchie suivant : H_Temps = ({(Jour, Mois), (Mois, Semestre), (Semestre, Annee)}, {(Jour, Semaine), (Semaine, Annee)}), o la base=Jour et le Sommet=Annee. Dans notre modle, nous considrons les caractristiques suivantes : 1. Nous distinguons les termes de dimension et de hirarchie. Ainsi, une dimension peut relier 0, une ou plusieurs hirarchies. Pour une hirarchie donne, il y a une liaison directe avec la dimension associe dans le cube. Par exemple, si le cube Ventes comporte la dimension Magasin relie une commune, ce cube sera alors indirectement li aux niveaux suprieurs commune (Dpartement, Rgion, ). Ainsi, il sera possible deectuer des agrgats sur ces niveaux suprieurs. 2. Nous pouvons insrer un niveau de hirarchie soit ct de la hirarchie dj dnie soit lintrieur. Pour faire cela, nous avons besoin de spcier trois niveaux, le premier est le niveau insrer, les deux derniers reprsentent les niveaux infrieur et suprieur partir desquels le nouveau niveau sera plac. 3. Dans la dnition du schma de hirarchie, nous considrons le cas o l=, cest dire quand nous avons seulement les niveaux base et sommet. Nous donnons dans la suite la dnition de schma et dinstance de hirarchie.
58
Architecture et modle pour un entrept de donnes mdicales Dnition 3.4 : Schma et instance de hirarchie.
Un schma de hirarchie est un n-uplet Hs = (hn , L, ), o hn H est le nom de la hirarchie, L est lensemble de niveaux lintrieur de la hirarchie hn et le symbole est une relation de dpendance entre les niveaux telle que sa fermeture transitive et 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 lj L est un niveau immdiatement suprieur (relation de dpendance) de li L si li lj . Une instance de hirarchie organise les proprits participant aux hirarchies dagrgation. Pour chaque arc dans un schma de dimension, il existe une fonction de RUP (rollup, cf. Dnition dinstance en-dessous) associe. Une instance de hirarchie est un n-uplet Ih = ( li L levelset(li ), RUP), o RUP l tel que (i) (l1 , l2 ) L tels que l1 l2 , il existe est un ensemble de fonctions ruplj i l2 une fonction rupl1 : levelset(l1 ) levelset(l2 ) et (ii) (l1 , l2 , l3 ) L tels que l1 l3 2 l2 et l2 l3 , ran(rupl l1 ) dom(rupl2 ). Par exemple, dans la gure 3.4, la partie gauche prsente le schma de la hirarchie H_Geo. Il est dni de la manire suivante : hn est le nom de la hirarchie H_Geo, lensemble de proprits (niveaux) lintrieur de la hirarchie est {Commune, Dpartement, Rgion, } et la relation est reprsente par {(Commune, Dpartement), (Dpartement, Rgion), (Rgion, )}.
Region
Rhne Alpes
...
Departement
Isre
...
Commune
Lyon
Grenoble
Annecy
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 rupDepartement Commune met en relation les proprits Lyon, Grenoble et Annecy du niveau Commune avec la proprit Isre du niveau Departement. Les proprits du niveau Region sont mises en relation avec la proprit unique t du niveau . Le reste du chapitre montre une application de notre modle. Nous utilisons des sources de donnes relles et un ensemble dindicateurs dans le cadre du projet ADELEM.
3.3
Analyse des donnes dune application mdicale
Cette section est consacre lanalyse des donnes du projet. Dabord, nous analysons lensemble des sources existantes, ce qui nous permet didentier deux types de donnes, les donnes publiques concernant la sant (RSA, RHA, CIM10 et FINESS) et les donnes dmographiques (RP99) [Bel02].
3.3.1
Sources de donnes
Nous dcrivons les chiers RSA (Rsums de Sorties Anonymes), RHA (Rsum Hebdomadaire Anonyme), FINESS (Fichier National des tablissements Sanitaires et Sociaux), CIM10 (Classication International de Maladies version 10). Ces chiers sont htrognes et rpartis et ils devront tre intgrs (les prparer, les nettoyer, les transformer, etc.), avant leur stockage dans lentrept de donnes. Fichier RSA (Rsums de Sorties Anonymes) Tout sjour hospitalier, effectu dans la partie court sjour dun tablissement, fait lobjet dun Rsum de Sortie Standardis RSS). Un RSS est constitu dun ou plusieurs Rsum(s) dUnit Mdicale (RUM). La transmission dinformations mdicales la direction de ltablissement ou lextrieur de celui-ci, sopre sur la base de donnes agrges ou Rsums de Sortie Anonymes (RSA). Le chier RSA est obtenu par transformation automatise des RSS. A partir du chier de RSS groups, le mdecin responsable du DIM (Dpartement dInformation Mdicale) utilise le logiciel GENRSA (Gnrateur de RSA), proprit de lEtat, pour produire le chier de RSA. Le RSA comprend toujours un enregistrement unique par sjour (environ 15 18 millions denregistrements pour chaque anne) [PMS04]. Caractristiques du chier : Propritaire : Agence Rgionale dHospitalisation Type du chier : Texte (ASCII xe) ou Access Anne : 2000 Mode dobtention : gratuit Mise jour : annuelle
60 - Taille : 11 Go
Fichier RHA (Rsum Hebdomadaire Anonyme) Il comprend environ 1600 tablissements avec 28 millions de journes dhospitalisation qui correspondent 18% de lactivit hospitalire. Etant donne que la moyenne dun sjour est denviron 35 jours, nous avons calcul une taille de 4 millions denregistrements hebdomadaires annuels ((28000000 / 35)*5) pour le chier RHA. Les objectifs sont doubles : le premier est la poursuite de soins mdicaux et de rducation, le deuxime est la radaptation (sociale, professionnelle, scolaire,...) [PMS04]. Caractristiques du chier : - Propritaire : Agence Rgionale dHospitalisation - Type du chier : Texte (ASCII xe) ou Access - Mode dobtention : gratuit Fichier FINESS (Fichier National des tablissements Sanitaires et Sociaux) Recense les structures sanitaires et sociales au niveau national (5079 tablissements pour la France Mtropolitaine) [SMS04]. Caractristiques du chier : Propritaire : Ministre Charg des Aaires Sanitaires et Sociales Type du chier : Texte (ASCII xe) au Excel Anne : 2000 Mode dobtention : gratuit Mise jour : annuelle Taille : 2.24 Mo
Fichier CIM10 (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. Caractristiques du chier :
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 commune) Lannexe A contient une description en dtail des sources RSA et FINESS.
3.3.2
Analyse des donnes
Dans cette partie nous analysons les direntes sources dcrites prcdemment pour proposer des mcanismes adapts selon les caractristiques des informations. Nous proposons dabord un tableau qui contient les proprits des sources. Ensuite, nous donnons un tableau danalyse de donnes en considrant une dizaine dannes de stockage. Le tableau 3.1 dcrit les direntes proprits des sources :
Source RSA RHA FINESS CIM10 RP90/99 Propritaire ARH ARH MCASS OMS INSEE Type de chier Texte (ASCII xe) ou Access Texte (ASCII xe) ou Access Texte (ASCII xe) ou Access Excel DBF Mode dobtention Gratuit Gratuit Gratuit Achat (625,04) Taille 11 Go 3 Go 2.24 Mo 1.34 Mo 50.8 Mo Anne 2000 2000 2000 1995 1999 Mise jour Annuelle Annuelle Annuelle Tous les 9 ans3
Tab. 3.1 Description des sources de donnes Le tableau prcdent indique les caractristiques essentielles prendre en compte lors des premires phases de la conception dun entrept. Nanmoins, si nous reprenons les deux dernires proprits, lanne et la mise jour, pour les reprsenter dans un tableau 3.2 qui aura des donnes sur 10 ans, nous avons les caractristiques des donnes historises. Lanalyse du tableau prcdent, nous permet de remarquer les sources RSA (Rsums de Sortie Anonymes) et RHA (Rsums Hebdomadaire Anonymes). Leurs
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.
3
62
Source RSA RHA FINESS CIM10 RP90/99 Taille 110 Go 30 Go 22.4 Mo 13.4 Mo 508 Mo

Optimisation du stockage Oui Oui Non Non Oui Rafrachissement Annuel Annuel Annuel Annuel4 Requtes complexes Oui Oui Non Non Non Agrgats Oui Oui Non Non Oui Evolution du schma Oui Oui Oui 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 rpercussions sur la structure logique de notre entrept, voire laecter. Ceci nous oblige proposer une conception adaptable de lentrept de donnes pour mieux intgrer ces changements notre schma. Dans les chapitres suivants, nous reprenons cette problmatique. Par exemple, pour le cas du volume de stockage grer, nous devons dnir lensemble optimal des vues matrialiser en considrant leur cot de calcul pour la matrialisation et leur cot de stockage (cf. Chapitre 4). Par rapport lvolution du schma, nous proposons (cf. Chapitre 5) lutilisation des versions de schmas bitemporels pour la gestion des aspects temporels de lentrept de donnes. Pour cette raison, nous avons dcid de garder toutes les donnes, mme celles qui ne changent pas, car elles formeront les versions historises annuelles.
3.4
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 indicateurs crs par le Laboratoire de Biomtrie et Biologie de Lyon (les indicateurs dore "gographiques" et les indicateurs de consommation, de besoins et de ux "temporels"). Le troisime type sont des indicateurs que nous proposons, ils correspondent des indicateurs "temporels", quil est intressant de prendre en compte. Dans les divers types dindicateurs, il existe des valeurs qui sont des paramtres de la requte. Par exemple dans lindicateur : "Nombre de sjours par maladie de ltablissement CHU GRENOBLE durant le 1er janvier 2000", nous trouvons pour lattribut Raison_sociale de la dimension Etablissement la valeur "CHU GRENOBLE" ainsi que la valeur "01-01-2000" pour lattribut Jour de la dimension Temps.
3.4 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 sjour en faisant apparatre leur capacit en nombre de lits MCO (Mdecine-ChirurgieObsttrie). Indicateur dore 2 : Localiser sur une carte toutes les maternits avec leur niveau (I, II ou III). Niveau I : Maternit sans service de ranimation ou de nonatalogie. Niveau II : Maternit avec un service de nonatalogie. Niveau III : Maternit avec un service de ranimation nonatale. Indicateur dore 3 : Reprsenter un ou plusieurs indices dattraction pour chaque tablissement.
3.4.2
Indicateurs de consommation, de besoins et de 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 catgories dactivit mdicale (lObsttrique, les AVC et lInfarctus), nanmoins dans notre entrept avec une dimension par Maladie et une autre par tablissement, nous pouvons analyser les divers sjours pour nimporte quelle maladie dans nimporte quel hpital. Voici les indicateurs qui ont t retenus : Indicateur de consommation 1 : Le nombre annuel de sjours par tablissement. Indicateur de consommation 2 : Reprsentation du nombre annuel daccouchements par maternit et rgion. Indicateur de consommation 3 : Reprsentation des eectifs de nouveau-ns par maternit et par poids de naissance. Indicateur de consommation 4 : Reprsentation des eectifs de nouveau-ns par poids de naissance et par niveau de maternits (niveau I, II ou III).
64
Indicateur de consommation 5 : Provenance des accouchements pris en charge dans tous les tablissements de la rgion ou dans une slection dtablissements. b) Indicateurs de besoins : Ces indicateurs dnissent lensemble des individus susceptibles dtre pris en charge par un tablissement de sant. Par exemple, dans obsttrique, un indicateur de besoin serait le nombre de femmes en ge de procrer actuellement ou bien une prvision de cet eectif dans les 5 10 annes venir. Indicateur de besoin 1 : Population dans les diverses tranches dge par secteurs gographiques (communes, dpartement, rgion ou pays). Indicateur de besoin 2 : Nombre de personnes dans les diverses tranches dge dans 5 ans, 10 ans, selon le lieu dhabitation. c) Indicateurs de 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 maternits (ventuellement selon le niveau de maternit) ? Indicateur de ux 2 : O vont les mres qui accouchent en fonction de leur lieu dhabitation ?
3.4.3
Nouveaux indicateurs de consommation et de ux (temporels)
Ce sont des indicateurs qui permettent de faire des analyses de comparaison, soit sur lge des patients, soit sur le mode de sortie de lunit mdicale. a) Indicateurs de consommation : Indicateurs de comparaison sur lge du patient. En gardant lge du patient dans la relation Prise_MCO, on peut faire des analyses comme : Indicateur de comparaison 1 : Nombre annuel de patients par tablissement et par ge. Indicateur de comparaison 2 : Nombre annuel de personnes de plus de 60 ans par maladie et par tablissement. b) Indicateurs de 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 7 8 9 0 = = = = transfert normal, le dpart vers une autre entit juridique. domicile, le patient rentre chez lui. dcs, le patient est dcd dans lunit mdicale. transfert pour ou aprs ralisation dun acte.
65
Indicateur 1 : Nombre annuel de patients qui sont transfrs (code 7) par maladie et par tablissement. Indicateur 2 : Nombre annuel de patients dcds par maladie, par tablissement et par rgion.
3.5
Application du modle multidimensionnel dans le cadre du projet
Nous avons donn prcdemment un ensemble de dnitions requises pour la conception dun modle multidimensionnel. Dans cette partie, nous reprenons cet ensemble pour aboutir la description dun modle multidimensionnel dans un contexte mdical. Dabord, nous dcrivons le schma en constellation conu ainsi que les hirarchies dnies pour le projet ADELEM et nous terminons cette partie par une description dtaille de lensemble des schmas qui composent ce modle.
3.5.1
Schma en constellation pour ADELEM
La gure 3.5 montre le schma en constellation avec trois relations de faits et leurs dimensions. La relation de faits Prise_MCO (Mdecine-Chirurgie-Obsttrique) a t conue pour la gestion des sjours hospitaliers eectus dans la partie court sjour dun tablissement. La relation de faits Population manipule des informations dmographiques. La troisime Prise_SSR (Soins de Suite et de Radaptation) dirence de Prise_MCO enregistre des donnes correspondantes des longs sjours. Prcedemment, nous avons dni une base de donnes multidimensionnelle, un cube, une dimension et une hirarchie. Ainsi, en utilisant la gure 3.5, nous dcrivons notre schma en constellation de la manire suivante : Base de donnes multidimensionnelle : Une base de donnes multidimensionnelle est un n-uplet SM = (Cs , Ds , Hs , R), o Cs = {Prise_MCO, Prise_SSR, Population} Ds = {Etablissements, CIM10, Temps, Zone_geo, Age, Mode_sortie, Poids_naissance, RP99, Semaine_debut, Semaine_n} R = {C_Cube, C_Dimension, C_Hirarchie}
66
Fig. 3.5 Schma en Constellation pour ADELEM contrainte : C_Cube = le component Cl_P est compos de lensemble des Cl_P du component /Dimension. C_Dimension = permet davoir une instance D avec un seul attribut, dimension dgnre [Kim96]. C_Hirarchie = la Cl_P dune mtaclasse Hirarchie ne peut pas relier la mtaclasse Cube associe sa mtaclasse Dimension et ceci en raison de sa granularit.
3.5.2
Hirarchies du schma
La gure 3.6 montre deux hirarchies que nous avons conues pour le schma en constellation prcdent [JLS99, WB97]. La premire, que nous appelons H_Geo, t dnie pour les dimensions Etablissement et Zone_geo de la manire suivante. Etant donn que le domaine de la dimension est : x ={C1,...,Cn}, reprsentant les communes du pays, nous dnissons : x {D1, ..., Dn} comme Dpartements x {R1, ..., Rn} comme Rgions x {P } comme Pays. La seconde hirarchie, appele H_Temps, correspond la dimension Temps, dont le domaine est : x ={1, ..., 12}, reprsentant les mois de lanne, nous dnissons : x {H, P, E, A} comme les saisons (Hiver, Printemps, Et, Automne)
3.5 Application du modle multidimensionnel dans le cadre du projet x {A} reprsentant lanne.
67
P X (Pays) R1
... ... ...
A X (Anne) H P E A X (Saison) 1 2 3 4 5 6 7 8 9 10 11 12 X (Mois)
Rn X (Rgion) Dn X (Dpartement) X (Commune)
D1
C1
Cn
Dimension Etablissement et Zone_geo
Dimension Temps
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 prenons la gure 3.5 et nous isolons la premire toile. La gure 3.7 reprsente un schma compose de la relation de faits Prise_MCO et de ses dimensions. La saisie de linformation se fera partir du chier RSA (public2000.mdb et prive2000.mdb), du chier FINESS (FINESSTOT.xls), du chier CIM10 (libcim10-95.xls) et du chier RP99 (DA99CCMC.xls). Dans cette relation, il y aura un enregistrement pour chaque sjour eectu dans la partie court sjour dun tablissement. La taille estime pour la relation Prise_MCO est environ 15 18 millions denregistrements par anne. Un schma de cube est un n-uplet Cs = (cn , M, D), o
68
Fig. 3.7 Schma en ocon de neige Prise_MCO cn = Prise_MCO M = {CompteDuree_sejour, SommeDuree_sejour} D = {CIM10, Etablissement, Temps, Zone_geo, Poids_naissance, Age, Mode_sortie} Un schma de dimension est un n-uplet Ds = (dn , P, H), o dn = CIM10 P = {Cle_Maladie, Libelle_maladie} H = { } dn = Etablissement P = {Cle_Finess, Raison_sociale, Adresse, Codepostal, CA1..CA7, CMO1..CMO7, NLA, NLO, Libelle_commune, Departement, Region, Pays} H = {H_Geo} Les attributs CA1..CA7 et CMO1..CMO7 reprsentent le nombre de lits autoriss et le nombre de lits mis en oeuvre respectivement par discipline. Une discipline dsigne une activit homogne qui est en fonction du type de soins ou de service social. Par exemple, mdecine gnrale, pdiatrie, chirurgie, hbergement, accueil temporaire, ducation. Dans le domaine sanitaire, certaines autorisations sont faites par Grands Groupes de Disciplines GGDE qui sont des regroupements de disciplines. dn = Temps P = {Cle_Temps, Mois, Saison, Annee} H = {H_Temps} Saison : Type char, en utilisant le code comme suit :
3.5 Application du modle multidimensionnel dans le cadre du projet
69
Hiver = janvier, fvrier et mars Printemps = avril, mai et juin t = juillet, aot et septembre Automne = octobre, novembre et dcembre. Pour arriver faire des analyses saisonnires. dn = Zone_geo P = {Cle_Zone, Libelle_commune, Departement, Region, Pays} H = {H_Geo} dn = Poids_naissance P = {Cle_Poids, Libelle_poids} H = { } Dans cette relation nous avons pour le poids la naissance les intervalles suivants : 1 2 3 4 5 6 <1500g >=1500g >=2000g >=2500g >=3000g >3500g
et et et et
<2000g <2500g <3000g <3500g
dn = Age P = {Cle_Age} H = { } dn = Mode_sortie P = {Cle_Mode, Libelle_mode} H = { } Un schma de hirarchie est un n-uplet Hs = (hn , L, ), o hn = {H_Geo} L = {Commune, Dpartement, Rgion, } = {(Commune, Dpartement), (Dpartement, Rgion), (Rgion, )} hn = {H_Temps} L = {Mois, Saison, } = {(Mois, Saison), (Saison, )}
70
3.5.4
Population
La saisie de linformation se fera partir du chier RP99 (DA99CCMC.xls) qui contient une pyramide des ges hommes et une autre pour les femmes. Nanmoins, si nous nous intressons seulement aux prvisions des accouchements, nous pouvons stocker des donnes par rapport aux femmes ou bien, nous pouvons calculer et agrger les informations directement dans la relation Prvision. Celle-ci deviendra une sorte de relation dagrgats et dans ce cas nous navons pas besoin de la dimension RP99. La gure 3.8 reprsente le schma Population.
Fig. 3.8 Schma en ocon de neige Population Un schma de cube est un n-uplet Cs = (cn , M, D), o cn = Population M = {CompteFem_proc} D = {Zone_geo, RP99} Un schma de dimension est un n-uplet Ds = (dn , P, H), o dn = Zone_geo P = {Cle_Zone, Libelle_commune, Departement, Region, Pays} H = {H_Geo} dn = RP99 P = {Cle_Depcom, Intcom, POPF00 .. POPF>95} H = { } Un schma de hirarchie est un n-uplet Hs = (hn , L, ), o hn = {H_Geo}
3.5 Application du modle multidimensionnel dans le cadre du projet L = {Commune, Dpartement, Rgion, } = {(Commune, Dpartement), (Dpartement, Rgion), (Rgion, )}
71
3.5.5
Prise_SSR
Dans cette relation, il y aura un enregistrement pour chaque sjour eectu dans la partie long sjour dun tablissement (Soins de Suite ou de Radaptation). La taille estime pour la relation Prise_SSR est denviron 4 millions denregistrements par an correspondants des sjours hebdomadaires. La gure 3.9 reprsente le troisime schma Prise_SSR.
Fig. 3.9 Schma en ocon de neige Prise_SSR Un schma de cube est un n-uplet Cs = (cn , M, D), o cn = Prise_SSR M = {CompteJoursenwk, CompteJourshorswk} D = {Etablissment, CIM10, Mode_sortie, Temps, Age, Zone_geo, Semaine_debut, Semaine_n} Un schma de dimension est un n-uplet Ds = (dn , P, H), o dn = Semaine_debut P = {Cle_Semdebut} H = { } dn = Semaine_n P = {Cle_Semn} H = { }
72
Architecture et modle pour un entrept de donnes mdicales Les autres dimensions ont t traites au paragraphe 3.5.3. Un schma de hirarchie est un n-uplet Hs = (hn , L, )
A lintrieur du cube Prise_SSR, nous avons les hirarchies H_Geo et H_Temps, nanmoins, elles aussi ont t traites au paragraphe 3.5.3.
3.6
Bilan
Dans ce chapitre, nous avons prsent la premire partie de ce que nous appelons le processus de structuration. Nous avons conu dabord une architecture pour un systme dcisionnel base sur trois composants, une interface graphique pour la gnration semi-automatique des indicateurs, un entrept multidimensionnel qui rassemble les donnes internes et externes et les versions de schmas bitemporels. Dans une deuxime phase, nous nous sommes focalis sur le mtamodle et le modle multidimensionnel. Pour le mtamodle, nous avons spci trois mtaclasses : Cube, Dimension et Hirarchie. Nous avons propos un ensemble de dnitions pour chaque mtaclasse et leurs instances, ainsi quune dnition dune base de donnes multidimensionnelle et de son instance. Ceci nous a permis daboutir la conception dun schma en constellation pour la construction dun entrept multidimensionnel de donnes mdicales. Nous avons utilis les informations concernant lensemble des sources de donnes relles et des indicateurs du projet ADELEM pour prouver et vrier le modle propos. Pendant la premire tape de notre exprimentation, nous avons analys les sources de donnes. Ceci nous a permis didentier deux types de donnes, les donnes dmographiques (RP99) et les donnes publiques concernant la sant (RSA, RHA, CIM10 et FINESS). Principalement, dans ces dernires, nous avons constat le besoin dorir des mcanismes pour une manipulation ecace de lensemble dinformation. Pour le projet, nous avons conu un tableau danalyse qui regroupe les donnes sur dix annes. Ce tableau nous a permis didentier les sources qui ont besoin dutiliser des techniques doptimisation de stockage comme la cration des agrgats. Lanalyse des indicateurs tablis pour le projet nous a permis de les classer en trois types. Les deux premiers rassemblent les identicateurs dore "gographiques" et les identicateurs de consommation, de besoins et de ux "temporels". Le troisime type correspond des nouveaux indicateurs galement "temporels". Nous les avons identis comme des indicateurs de consommations et de ux. Ils nous permettent de faire des analyses par rapport lge du patient ainsi qu son mode de sortie de lhpital. Dans la dernire partie, nous nous sommes focaliss sur la conception dun modle
3.6 Bilan
73
multidimensionnel pour le projet. Nous avons conu une constellation compose de trois schmas : Prise_MCO, Prise_SSR et Population, o chacun est compos de ses propres dimensions ainsi que des dimensions partages pour lensemble de schmas. Nous avons utilis les dnitions proposes pour aboutir la description des schmas. Nous avons dit prcdemment que lensemble des sources comporte aussi bien des donnes rparties et htrognes quexternes au domaine mdical. Ainsi, nous avons dun ct des problmatiques lies la nature particulire des donnes mdicales : type, format, smantique, condentialit, degr de abilit et de conance, informations manquantes ou incompltes, et dun autre ct lhtrognit des donnes fournies par des organismes hors du contexte mdical. Par exemple : les renseignements sur lorigine gographique des patients pour la consommation de soins sont bass sur les codes postaux et non pas sur le code INSEE de la commune de rsidence du patient. Dans le chapitre suivant, nous dcrivons la deuxime partie du processus de structuration. Elle consiste en la slection de lensemble optimal de vues matrialiser. Nous prsentons aussi le fonctionnement de linterface graphique conue pour la gnration semi-automatique de requtes partir des indicateurs.
74
Chapitre 4 Systme daide la dcision mdicale : une exprimentation

Dans le chapitre prcdent, nous avons dcrit le modle multidimensionnel conu pour le projet ADELEM. Tout au long de ce chapitre, nous focalisons notre exprimentation sur un systme dcisionnel. Nous avons divis le travail ralis en trois parties. La premire dcrit le schma en toile construit et la matrialisation de lhypercube pour celui-ci. La deuxime partie traite le sujet des vues matrialises qui nous permettent doptimiser lexcution de requtes. Nous avons construit le schma Adelem_MCO et nous avons cre la base de donnes correspondante en utilisant un chantillon du 10% des donnes relles du projet. Nous avons utilis le systme dcisionnel dOracle9i Entreprise Edition Release 9.2.0.1.0 pour la cration du schma et pour la gnration des vues matrialises. Ceci nous a permis de connatre le cot de stockage (reprsent par le nombre de n-uplets du rsultat) de chaque vue et de pouvoir facilement dterminer leur cot de calcul (produit des cardinalits approximatives des relations de base). Nous proposons un algorithme pour la slection de lensemble optimal des vues slectionner qui utilise comme paramtres la frquence dutilisation, le cot de calcul et la probabilit de changement des relations de base. Nous terminons cette partie avec les relations de dpendance et la cration des vues matrialiser de cet ensemble optimal. Finalement, la troisime partie se focalise sur le fonctionnement de linterface pour la gnration semi-automatique dindicateurs. Nous donnons dabord larchitecture pour cette interface et la description de ses composants. Lutilisation de linterface requiert un module pour la cration du schma, ainsi, nous dcrivons dabord le fonctionnement de ce module, ensuite, nous classions les types de requte excuter et nalement, nous dcrivons le fonctionnement de linterface graphique en utilisant un exemple de requte.
75
76
Systme daide la dcision mdicale : une exprimentation
4.1
Construction du schma
Dans cette section, nous dcrivons la construction du schma en toile Adelem_MCO. Il est compos dune relation de faits et de quatre relations de dimensions. Nous dnissons dabord la structure de chaque relation qui intgre le schma et la matrialisation de lhypercube.
4.1.1
Schma en toile
Adelem_MCO
Pour la construction du schma, nous avons seulement utilis une partie de ltoile
Prise_MCO du schma en constellation conu pour le projet (cf. Figure 3.5). La gure 4.1 montre le schma Adelem_MCO construit. Il est compos de la relation de faits Prise_MCO et des dimensions Etablissement, CIM10, Temps et Mode_sortie.
Fig. 4.1 Schma en toile Adelem_MCO Nous dcrivons la structure de chaque relation qui compose le schma : Fait :
Prise_MCO = {Cle_Finess, Cle_Maladie, Cle_Temps, Cle_Mode, CompteDuree_sejour, SommeDuree_sejour}
Dimensions :
Etablissement = {Cle_Finess, Raison_sociale, Adresse, Code_postal, CA1,
4.1 Construction du schma

CMO1, CA2, CMO2, CA3, CMO3, CA4, CMO4, CA5, CMO5, CA6, CMO6, CA7, CMO7, NLA, NLO, Libelle_commune, Departement, Region, Pays} CIM10 = {Cle_Maladie, Libelle_maladie} Temps = {Cle_Temps, Mois, Saison, Annee} Mode_sortie = {Cle_Mode, Libelle_mode}
77
Le tableau 4.1 contient le type et le nombre denregistrements de chaque relation. Relation Prise_MCO Etablissement CIM10 Temps Mode_sortie Fait/Dimension Fait Dimension Dimension Dimension Dimension Taille 53799 n-uplets 5079 17788 12 5
Tab. 4.1 Liste de relations de base
4.1.2
Matrialisation de lHypercube
Les utilisateurs des entrepts travaillent dans un environnement graphique et ils visualisent les donnes comme un cube de 2, 3 ou plusieurs dimensions. Nous utilisons le schma en toile de la gure 4.1 pour construire un hypercube. Chaque cellule (E, C, T, M, m1, m2) contient le nombre de sjours (m1) et leur somme en jours (m2) qui ont eu lieu dans lHpital E, avec la maladie C, pendant le mois T et avec un mode de sortie M (par exemple : le patient rentre chez lui). Dans les systmes dcisionnels, les utilisateurs sont intresss par des requtes du type : "le nombre de sjours de lhpital E1 pour la maladie C1". Dans ce cas, la cellule (E1, C1, ALL1 , ALL, m1), contient la valeur : "le nombre de sjours de lhpital E1 pour la maladie C1 pour tous les mois (ALL) et pour tous les modes de sortie (ALL)". Nous pouvons calculer la valeur de la cellule (E1, C1, ALL, ALL) comme la somme des valeurs des cellules de (E1, C1, T1 , M1 ), ..., (E1, C1, TN temps , MN mode ), o TN temps et MN mode reprsentent lensemble de mois et lensemble de modes de sortie respectivement. Toutes les cellules contenant la valeur ALL dans un de ses axes sont des cellules dpendantes. Ainsi, pour la slection des vues matrialiser, le
Nous utilisons la recommandation dajouter la valeur ALL au domaine de la dimension T et M, prsente dans [GBLP95]
1
78
problme se rduit dterminer lensemble des cellules dpendantes matrialiser. Etant donn que le cot de stockage 2 pour une matrialisation de toutes les vues est de 205929 n-uplets ( i=1,...,n CS(vi ), o CS(vi ) est le cot de stockage des vues du tableau 4.2), nous avons un pourcentage de 74% ((206781-53799)*100/206781) de cellules dpendantes pour le schma Prise_MCO construit. Pour la matrialisation de lhypercube, nous avons les possibilits suivantes : la matrialisation complte, pas de matrialisation et la matrialisation partielle. Dans notre exprimentation, nous considrons la dernire approche. Nous dnissons dabord la taille de la matrialisation complte dun cube qui est compos de 5 relations de la manire suivante : Taille du Cube Fait = 1 Dimensions = 4 Total = 16 (2n o n est le nombre de dimensions = 24 ) Nous dnissons lensemble des vues possibles matrialiser. Le tableau 4.2 contient les 15 vues pour une matrialisation complte ainsi que leur cot de stockage et de calcul. La gure 4.2 reprsente lhypercube sur 4 dimensions du schma Prise_MCO, nous utilisons la notation : M pour million et K pour mille.
Vue V1 V2 V3 V4 V5 V6 V7 V8 V9 V10 V11 V12 V13 V14 V15 Relations Prise_MCO+Etablissement+CIM10+Temps+Mode_sortie Prise_MCO+Etablissement+CIM10+Temps Prise_MCO+Etablissement+CIM10+Mode_sortie Prise_MCO+Etablissement+Temps+Mode_sortie Prise_MCO+CIM10+Temps+Mode_sortie Prise_MCO+Etablissement+CIM10 Prise_MCO+Etablissement+Temps Prise_MCO+Etablissement+Mode_sortie Prise_MCO+CIM10+Temps Prise_MCO+CIM10+Mode_sortie Prise_MCO+Temps+Mode_sortie Prise_MCO+Etablissement Prise_MCO+CIM10 Prise_MCO+Temps Prise_MCO+Mode_sortie C. de Stockage 53799 n-uplets 47133 18456 603 32918 13973 184 58 26058 8186 48 19 5329 12 4 C. de Calcul 90M 90M 90M 61K 346K 90M 60K 25K 216K 90K 60 5K 18K 12 5
Tab. 4.2 Matrialisation complte de lhypercube La vue V1 reprsente les donnes de dtail du sous-schma Prise_MCO. Le cot de stockage (reprsent par le nombre de n-uplets du rsultat) est denviron 54K et le cot de calcul (produit des cardinalits approximatives des relations de base) est de
2
Le cot de stockage dune requte est le nombre de n-uplets du rsultat.
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.
90M ECTM V1 54K
4 Dim
90M
ECT V2
47K
90M
ECM V3
18K
61K
ETM V4
603
346K
CTM V5
3 Dim
33K
90M
EC V6
14K
60K
ET V7
184
25K
EM V8
58
216K
CT V9
26K
90K
CM V10
8K
60
TM V11
2 Dim
48
5K
Etab V12
19
18K
Cim10 V13 5K
12
Temps V14 12
Mode 5 V15
1 Dim
4
ALL V16
0 Dim
1
Cot de calcul
Matrialisation Complte: Pas de Matrialisation: 361M (n-uplets) 90M (n-uplets)
Fig. 4.2 Hypercube avec le cot de calcul ( gauche) et le cot de stockage ( droite) de chaque noeud (vue)
4.2
Vues matrialises
Dans cette section, nous nous focalisons sur la gnration des vues matrialises. Nous appliquons deux algorithmes aux donnes du projet ADELEM. Le premier est lalgorithme Greedy, lautre est un algorithme que nous proposons pour la slection des vues matrialiser. Lalgorithme Greedy propos par [HRU95, HRU96] repose sur un modle de cot pour dterminer lensemble optimal de vues matrialiser. Il utilise le cot de sto-
80
ckage et le nombre de vues dpendantes (optimales) dune vue pour calculer le bnce optimal de celle-ci. Nous rappelons que une vue Vi est dpendante de Vj si, et seulement si, nous pouvons rpondre Vi en utilisant Vj , ainsi, Vi Vj . Nous prsentons dabord lapplication de lalgorithme Greedy aux donnes relles du projet. Pour faire cela, nous listons lensemble des vues dpendantes de chaque vue de lhypercube. Ensuite, nous exposons le fonctionnement de lalgorithme, et pour nir, nous prsentons le tableau rsultant qui dcrit le choix des 7 premires vues matrialiser. Dans une deuxime partie, nous prsentons le fonctionnement de notre algorithme, ainsi que le tableau pour une slection aussi des 7 premires vues matrialiser.
4.2.1
Slection des vues matrialiser
Nous formalisons la slection des vues matrialiser en utilisant lalgorithme Greedy. Nous avons dcid dutiliser cet algorithme pour deux raisons, la premire parce que nous avons toutes les donnes ncessaires pour leur utilisation. Ainsi, nous navons pas besoin de faire des hypothses, principalement, pour le cot de stockage, car nous avons le cot de stockage rel de chaque vue possible dtre matrialise. La seconde raison, notre avis la plus importante, est lide que nous avons eue de rutiliser le nombre de vues dpendantes comme un paramtre initial pour la frquence dutilisation dune vue. Nous avons remarqu que plusieurs propositions utilisent comme frquence dutilisation un nombre assign chaque vue, par exemple : la frquence dutilisation pour la vue V1 est gale 10, V2 5, V3 1, ... Ainsi, la particularit de notre algorithme rside dans la spcication de deux propositions. La premire consiste utiliser la complexit de la vue (nombre total de ses relations dpendantes) pour les deux premiers paramtres : la frquence dutilisation et le cot de calcul de la vue. Ainsi, nous considrons que la frquence dutilisation dune vue augmente en proportion directe du nombre de ses relations dpendantes et que le cot de calcul diminue dans la mme proportion. La deuxime proposition consiste dterminer la probabilit de changement sur les relations de base. Pour faire cela, nous avons besoin du nombre dlments lintrieur de la vue qui peuvent subir des changements et nous le multiplions par le cot de calcul de celle-ci. Nous utilisons lhypercube de la g 4.2 et nous considrons que le cot de stockage est reprsent par le nombre de n-uplets de la vue. Ainsi, nous pouvons dterminer lensemble de vues dpendantes de chaque vue de la manire suivante. Relations de dpendance lintrieur de lhypercube : V2 : V6 V2, V7 V2, V9 V2, V12 V2, V13 V2, V14 V2, V16 V2
4.2 Vues matrialises V3 : V6 V4 : V7 V5 : V9 V6 : V12 V7 : V12 V8 : V12 V9 : V13 V10 : V13 V11 : V14 V12 : V16 V13 : V16 V14 : V16 V15 : V16 V3, V8 V4, V8 V5, V10 V6, V13 V7, V14 V8, V15 V9, V14 V10, V15 V11, V15 V12 V13 V14 V15 V3, V10 V4, V11 V5, V11 V6, V16 V7, V16 V8, V16 V9, V16 V3, V12 V4, V12 V5, V13 v6 V7 V8 V9 V10 V11 V3, V13 V4, V14 V5, V12 V3, V15 V4, V15 V5, V15 V3, V16 V4, V16 V5, V16
81 V3 V4 V5
V10, V16 V11, V16
Quelques notations de lalgorithme Greedy : C(v) = Cot de stockage de la vue v. = Relation de dpendance. Par exemple, Q2 Q1 si et seulement si Q2 peut tre rpondue par Q1, donc Q2 est dpendante de Q1. S = Ensemble de vues slectionnes. B(v, S) = Gain de la vue v relative S, 1) Pour chaque w v, dnir la quantit Bw par : a) Si u est la vue de cot infrieur dans S, tel que w u. Nous remarquons que lensemble S contient au moins la vue V1. b) Si C(v) < C(u), alors Bw = C(v) - C(u). Sinon Bw = 0. 2) Dnir B(v, S) = w v Bw . La gure 4.3 dcrit lalgorithme Greedy pour une slection de n vues matrialiser. Nous utilisons lhypercube de la g 4.2 pour lapplication de lalgorithme. La table 4.3 dcrit les rsultats avec n gal 7.
82

S = {top view}; for i = 1 to n do begin select that view v not in S such that B(v, S) is maximized; S = S union {v}; end; resulting S in the greedy selection;
Fig. 4.3 Algorithme Greedy [HRU95]
Vue V2 V3 V4 V5 V6 V7 V8 V9 V10 V11 V12 V13 V14 V15 V16 {V1}
1re Choix 7K*8=56K 36K*8=288K 53K*8=424K 21K*8=168K 40K*4=160K 54K*4=216K 54K*4=216K 28K*4=112K 46K*4=184K 54K*4=216K 54K*2=108K 49K*2=98K 54K*2=108K 54K*2=108K 54K*1=54K S=S+V4
2 Choix 7K*4=28K 36K*4=144K 21K*4=84K 40K*2=80K 419*4=2K 545*4=2K 28K*2=56K 46K*2=92K 555*4=2K 584*2=1K 49K*1=49K 591*2=1K 599*2=1K 1K S=S+V3
3 Choix 7K*2=14K 21K*2=42K 4K*2=8K 419*4=2K 545*4=2K 28K*1=28K 10K*2=20K 555*4=2K 584*2=1K 13K*1=13K 591*2=1K 599*2=1K 1K S=S+V5
4 Choix 7K*1=7K 4K*2=8K 419*4=2K 545*4=2K 7K*1=7K 10K*2=20K 555*4=2K 584*2=1K 13K*1=13K 591*2=1K 599*2=1K 1K S=S+V10
5 Choix 7K*1=7K 4K*1=4K 419*4=2K 545*4=2K 7K*1=7K 555*4=2K 584*2=1K 3K 591*2=1K 599*2=1K 1K S=S+V9
6 Choix 7K*1=7K 4K*1=4K 419*4=2K 545*4=2K 555*4=2K 584*2=1K 3K 591*2=1K 599*2=1K 1K S=S+V2
7 Choix 4K*1=4K 419*4=2K 545*4=2K 555*4=2K 584*2=1K 3K 591*2=1K 599*2=1K 1K S=S+V6
Tab. 4.3 Application de lalgorithme Greedy aux donnes ADELEM Pour la premire itration, le fonctionnement de lalgorithme Greedy est assez simple, car nous avons seulement la vue V1 dans lensemble S ; de cette manire la valeur de u est gal 54K (le cot de V1) car elle reprsente la vue avec le cot de stockage minimum dans lensemble S. Ainsi, pour obtenir le bnce optimal de V2, nous devons calculer la dirence du cot de stockage de V2 par rapport V1 (47K - 54K) et nous multiplions cette dirence par le nombre de relations dpendantes de V2 (V2, V6, V7, V9, V12, V13, V14 et V16), ce qui nous donne 56K de bnce optimal pour V2. Pour V3, le mcanisme est pareil, ainsi nous avons 288K. Dans le cas de la vue V6, nous multiplions la dirence du cot de stockage entre V6 et V1 par les vues dpendantes de V6 (V6, V12, V13 et V16) et ainsi de suite. Une fois calcul le bnce optimal de lensemble de vues, nous devons choisir celle qui ait le bnce maximum. Dans la premire itration, le choix est la vue V4, car elle reprsente le gain le plus lev (53K*8=424K), le gain est calcul de la manire suivante : cot(V4) - cot(V1) = 53K multipli par 8, le nombre de vues dpendantes de V4 (V4, V7, V8, V11, V12, V14, V15 et V16).
83
Nanmoins, au fur et mesure que nous remplissons lensemble S, nous devons toujours choisir le cot de stockage minimum de u lintrieur de S duquel la vue dpende. Ainsi, dans le second choix, pour certains vues, u est reprsente par 54K (le cot de stockage de V1), tandis que pour les vues qui dpendent de V4 (qui a t choisie dans la premire itration), u est 603. Par exemple, le bnce optimal de V2 est 28K, car la dirence entre les cots de stockage de V2 et V1 (toujours 7K) est multipli par 4 (V2, V6, V9 et V13). Les autres vues dpendantes de V2 (V7, V12, V14 et V16) ne sont pas prises en compte, car elles donnent un gain plus lev avec la vue V4. Dans la seconde choix, la slection porte sur la vue V3 avec 144K (36K*4 (V3, V6, V10 et V13)), les autres vues dpendantes de V3 ne sont pas prises en compte, car elles donnent un gain plus lev avec la vue V4. Finalement, la dernire ligne contient le rsultat, elle reprsente lensemble S={V4, V3, V5, V10, V9, V2, V6}. La gure 4.4 montre lapplication de lalgorithme Greedy par rapport aux cots de calcul et de stockage. Nous considrons seulement les 7 premiers rsultats, mme si partir de la 6me itration, nous navons aucun avantage pour la matrialisation. Par exemple, la vue V2, rsultat de la 6me itration, a pour cot de stockage 47K et un cot de calcul de 90M. Si nous faisons la comparaison de ces rsultats, par rapport la vue V1, que nous sommes censs matrialiser3 , nous nous apercevons que le gain est presque minimum, mais que les cots de leur matrialisation sont doubls.
V2 90M
V3
V6
. . .
Cot de calcul Cot de stockage
Nombre de tuples
300k
V5
V9 200k
100k
V10 V4
...
16
Nombre de vues matrialises
Fig. 4.4 Ensemble ordonn des vues slectionnes La gure 4.4 contient les cots de calcul et de stockage dans laxe Y et les sept premires vues de la table 4.3 ordonnes (par rapport leur cot de calcul) sur laxe X.
3
Car cette vue ne peut pas tre construit partir daucune autre vue.
84
Systme daide la dcision mdicale : une exprimentation Lalgorithme Greedy est optimal dans les cas suivants :
1. Si V1 est plus grande que les autres vues, alors lalgorithme est proche de loptimal. 2. Si toutes les vues sont gales, alors lalgorithme est optimal. Si nous considrons le cot de stockage que nous avons dans lhypercube de la gure 4.2, nous nous apercevons que notre cas est similaire au premier, car la seule vue proche de la vue V1 est la vue V5. Le reste des vues est plus petit que V1. La slection des vues matrialiser est un sujet de recherche trs important. Il existe de nombreux travaux de recherche [AAD+ 96, BB03, BPT97, CHS02, CLF99, GM95, Gup97, KMP02, KR99, LMSS95, SDJL96, YKL97, ZYY01, YW00] qui utilisent un modle de cot, comme celui de Greedy, mais qui a t adapt avec linclusion de certains paramtres, tels que : la frquence de la requte, la frquence des mises jour sur les relations de base, le cot de maintenance, entre autres. Par exemple, dans [BB03], les auteurs proposent un algorithme qui permet de calculer le gain global de la vue par rapport au cot de la requte et le cot de maintenance. Ils direncient le cot dvaluation dune requte par rapport au type dopration (Select, Project et Join). Ils utilisent aussi la frquence de la requte ainsi que le cot de maintenance bas sur les oprateurs Add et Delete. Lalgorithme Greedy est simple et ecace, nanmoins, dans notre exprimentation, partir du 6me choix, il slectionne les vues les plus coteuses. Ceci nous motive pour proposer un mcanisme pour une slection plus able. Nous proposons dinclure les paramtres suivants : frquence dutilisation, cot de calcul et probabilit de changement des relations de base (cot).
4.2.2
Algorithme propos pour la slection des vues matrialiser
Dans notre algorithme, les relations dpendantes dune vue jouent un rle essentiel, ainsi, nous considrons que leur nombre reprsente un paramtre initial pour la frquence dutilisation, ainsi que pour le cot de calcul. Pour le premier, nous multiplions le bnce optimal, donn par lalgorithme Greedy, par le nombre total des relations dpendantes, car pour nous, la frquence dutilisation augmente en proportion directe du nombre de relations dpendantes. Pour le cot de calcul, nous considrons quil diminue par rapport au nombre de relations dpendantes, ainsi, nous divisons le cot de calcul par le nombre total des relations dpendantes [SA05a]. Notre algorithme considre aussi la probabilit de changement des relations de base. Dans ce cas, nous avons besoin du nombre dlments lintrieur de la vue qui
85
peuvent subir des changements. Considrons par exemple la vue V2. Elle se compose des relations Etablissement, CIM10 et Temps. La relation Etablissement contient 24 proprits, CIM10 et Mode_sortie contiennent 2 proprits et Temps en contient 4 (cf. paragraphe 4.1.1). Nous avons 36 lments pouvant voluer (32 proprits et 4 dimensions). Supposons que nous avons une probabilit de changement de 20%, ainsi, notre calcul pour la frquence des mises jour de V2 est (33*100/36*.20), o 33 est le nombre dlments de la vue V2. Quelques notations : CC = Cot de calcul (produit des cardinalits approximatives des relations de base) divis par le nombre de relations dpendantes. Par exemple, le CC(v) si v=V2 (vue ECT, cf. Figure 4.4) est : CC(V2) = ((5K*18K) + (14K*12))/8 90M/8 = 11M, o 8 est le nombre total des relations dpendantes de V2. PC = Probabilit de changement des relations de base multipli par le cot de calcul. Par exemple, si nous avons lhypothse de 20% de changement des lments du schma sur la vue V2 (3 dimensions et 30 attributs qui peuvent changer), alors PC(V2) = (3300/36*.20)*11M = 2M. V = Ensemble de vues. S = Ensemble de vues slectionnes. w = Nombre de choix. fq(v) = Complexit de la vue (nombre total des relations dpendantes de la vue v). v = Vue slectionne. vo = C(vue "top view"). La gure 4.5 montre lalgorithme propos incluant la frquence dutilisation, le cot de calcul et la probabilit de changement. Le tableau 4.4 montre les rsultats de lapplication de notre algorithme pour les 7 premiers choix, en considrant 20% comme frquence des mises jour sur les relations de base. Pour le premier choix la valeur de vo est gale 54K, le cot de V1, car elle reprsente la vue avec le cot de stockage minimum dans lensemble S. Pour le deuxime et le troisime elle est reprsente par 603 (le cot de V4), car cest la vue ayant un cot de stockage infrieur lintrieur de S. Dans la premire itration, le choix est la vue V4, car elle reprsente le plus haut gain ((((53K*8)*8)=3392K)((61K/8)*1.18=9K)=3M). Le gain est calcul de la manire suivante : cot(V4) cot(V1) = (53K*8) reprsente le gain de Greedy, nous multiplions ce gain par le nombre de relations dpendantes de V4 (V4, V7, V8, V11, V12, V14, V15 et V16). Ensuite, nous le soustrayons le cot de calcul divis par le nombre de relations dpendantes et multipli par la frquence des mises jour. Le second choix est la vue V5 avec 626K (((21K*4*8)=672K) - ((346K/8) *
86
S = {vue T}; vo = C(vue T); fq = 1; Bg = 0; t = 0; n = |V|; for y = 1 to w do begin //nombre de choix for x = 2 to n do begin //parcours de lhypercube pour chaque vue i = x + 1; repeat //calculer la frquence et le bnfice de lalgorithme Greedy if vi dpend de vx if {vx} appartient S vo=C(vx) else vo=C(vue T) endif if vi dpend de v tel que {v} appartient S vo=C(v) endif fq = fq + 1; if C(vx) < vo B(vi) = C(vx) - vo else B(vi) = 0 endif Bg = Bg + B(vi) //bnfice Greedy endif i = ++; until i = n; Bg = Bg + (C(vx) - vo); //bnfice de vx B(vx, S) = (Bg * fq) - (CC(vx)/fq + PC(vx)); //bnfice incluant la frquence, le cot de calcul et la prob. chang. if B(vx, S) > t t = B(vx, S); //bnfice maximal v = vx; endif endfor t=0; S = S U {v}; endfor rsultat S
Fig. 4.5 Algorithme propos
Vue V2 V3 V4 V5 V6 V7 V8 V9 V10 V11 V12 V13 V14 V15 S=S+V1
1re Choix (448K-(11M*1.18))=-13M (2M-13M)=-11M (3392K-9K)=3M (1344K-46K)=1298K (640K-26M)=-25M (864K-18K)=845K (864K-7K)=857K (448K-56K)=392K (736K-24K)=713K (864K-62)=864K (216K-3K)=213K (196-9K)=187K (54K*2*2=216K)=216K (54K*2*2=216K)=216K S=S+V4
2 Choix -13M -12M 626K -26M -11K 2K 168K 345K 9K -1K 89K 2K 2K S=S+V5
3 Choix -13M -12M -26M -11K 2K 0K 177K 9K -1K 47K 2K 2K S=S+V10
4 Choix -13M -12M -26M -11K 2K -28K 9K -1K -3K 2K 2K S=S+V11
5 Choix -13M -12M -26M -11K 2K -28K -1K -3K 30 41 S=S+V8
6 Choix -13M -12M -26M -11K -28K -3K -3K 30 41 S=S+V15
7 Choix -13M -12M -26M -11K -28K -3K -3K 30 S=S+V14
Tab. 4.4 Application de notre algorithme aux donnes ADELEM
87
1.06=46K) = 626K), les vues dpendantes sont (V5, V9, V10 et V13), les autres vues dpendantes de V5 ne sont pas prises en compte, car elles ont un gain infrieur celui de la vue V4. Nanmoins, nous multiplions le rsultat par le nombre total des vues dpendantes et nous divisons le cot de calcul par ce nombre total. Finalement, la dernire ligne contient le rsultat, elle reprsente lensemble S={V4, V5, V10, V11, V8, V15, V14}. La gure 4.6 montre lapplication de notre algorithme par rapport aux cots de calcul et de stockage. Nous considrons les 7 premiers rsultats. Si nous prenons comme rfrence la gure 4.2, nous remarquons que la slection est faite de la manire suivante : du deuxime niveau (3 Dim), notre algorithme slectionne les deux vues de gain optimal. Pour le troisime niveau (2 Dim), il slectionne les trois meilleures et nalement pour le dernier niveau (1 Dim), il slectionne les deux premires vues optimales.
90M
. . .
Cot dexcution Cot de stockage
Nombre de tuples
300k
V5
200k
100k
V10 V4 V8 V11 V14 6 V15 7 ... 16
Nombre de vues matrialises
Fig. 4.6 Ensemble ordonn des vues slectionnes Le graphique contient les cots de calcul et de stockage sur laxe des Y et les sept premires vues de la table 4.4 ordonnes (par rapport leur cot de calcul) sur laxe X. Nous constatons, qu la dirence de lalgorithme Greedy, notre proposition donne de meilleurs rsultats dans notre cas exprimental. Finalement, nous devons reconnatre la faiblesse de notre algorithme. Nous avons deux paramtres que nous navons pas considr, le premier est labsence du cot dvaluation dune requte par rapport au type dopration (Select, Project ou Join). Le second paramtre que nous ne considrons pas sont des restrictions, par exemple la restriction ventuelle sur lespace de stockage.
88
4.2.3
Gnration des vues matrialises
Cette partie dcrit la cration de lensemble de vues matrialiser. Le tableau 4.5 reprsente lensemble minimal des vues matrialiser que nous avons obtenu en appliquant notre algorithme. Il contient pour chaque vue le nombre de jointures ainsi que les cots de stockage et de calcul. Vue V4 E+T+M V5 C+T+M V8 E+M V10 C+M V11 T+M V14 T V15 M No de jointures 3 3 2 2 2 1 1 Cot de Stockage 603 33K 58 8K 48 12 4 Cot de Calcul 61K 346K 25K 90K 60 12 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 ENABLE QUERY REWRITE AS SELECT cim10.cle_maladie, temps.cle_temps, mode_sortie.cle_mode, sum(compteduree_sejour) AS compte_sejour, sum(sommeduree_sejour) AS somme_sejour
4.2 Vues matrialises FROM cim10, temps, mode_sortie, prise_mco WHERE cim10.cle_maladie=prise_mco.cle_maladie AND temps.cle_temps=prise_mco.cle_temps AND mode_sortie.cle_mode=prise_mco.cle_mode GROUP BY cim10.cle_maladie, temps.cle_temps, mode_sortie.cle_mode ; Rsultats : 32918 n-uplets VM8 : Nombre de sjours par tablissement et mode de sortie CREATE MATERIALIZED VIEW cs_sejour_etab_mode_2d ENABLE QUERY REWRITE AS 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 AND mode_sortie.cle_mode=prise_mco.cle_mode GROUP BY etablissement.cle_ness, mode_sortie.cle_mode ; Rsultats : 58 n-uplets VM10 : Nombre de sjours par maladie et mode de sortie CREATE MATERIALIZED VIEW cs_sejour_cim10_mode_3d ENABLE QUERY REWRITE AS SELECT cim10.cle_maladie, mode_sortie.cle_mode, sum(compteduree_sejour) AS compte_sejour, sum(sommeduree_sejour) AS somme_sejour FROM cim10, mode_sortie, prise_mco WHERE cim10.cle_maladie=prise_mco.cle_maladie AND mode_sortie.cle_mode=prise_mco.cle_mode GROUP BY cim10.cle_maladie, mode_sortie.cle_mode ; Rsultats : 8186 n-uplets VM11 : Nombre de sjours par temps et mode de sortie CREATE MATERIALIZED VIEW cs_sejour_temps_mode_2d ENABLE QUERY REWRITE AS SELECT temps.cle_temps, mode_sortie.cle_mode, sum(compteduree_sejour) as compte_sejour, sum(sommeduree_sejour) as somme_sejour FROM temps, mode_sortie, prise_mco
89
90
WHERE temps.cle_temps=prise_mco.cle_temps AND mode_sortie.cle_mode=prise_mco.cle_mode GROUP BY temps.cle_temps, mode_sortie.cle_mode ; Rsultats : 48 n-uplets VM14 : Nombre de sjours par mois CREATE MATERIALIZED VIEW cs_sejour_temps_1d ENABLE QUERY REWRITE AS SELECT temps.cle_temps, count(compteduree_sejour) as compte_sejour, sum(sommeduree_sejour) as somme_sejour FROM temps, prise_mco WHERE temps.cle_temps=prise_mco.cle_temps GROUP BY temps.cle_temps ; Rsultats : 12 n-uplets VM15 : Nombre de sjours par mode de sortie CREATE MATERIALIZED VIEW cs_sejour_mode_1d ENABLE QUERY REWRITE AS SELECT mode_sortie.cle_mode, count(compteduree_sejour) as compte_sejour, sum(sommeduree_sejour) as somme_sejour FROM mode_sortie, prise_mco WHERE mode_sortie.cle_mode=prise_mco.cle_mode GROUP BY by mode_sortie.cle_mode ; Rsultats : 4 n-uplets
4.3
Interface graphique pour la Gnration (semiautomatique) dIndicateurs
Nous avons cr deux modules, le premier permet la cration et/ou modication de notre schma et le deuxime facilite la gnration de requtes de manire quasiautomatique. Nous avons group notre travail en quatre parties. La premire montre larchitecture de linterface graphique. La deuxime dcrit le fonctionnement du module pour la cration du schma. La troisime schmatise les types de requtes excuter dans linterface graphique. Finalement, la dernire partie expose le fonctionnement
4.3 Interface graphique pour la Gnration (semi-automatique) dIndicateurs
91
de linterface pour la gnration (quasi-automatique) de requtes. Nous dcrivons en dtail chaque partie.
4.3.1
Architecture pour linterface graphique
Dans notre architecture, nous trouvons trois composants principaux. Le premier correspond linterface pour la gnration (quasi-automatique) de requtes. Le deuxime, lentrept de donnes, a t dcrit au chapitre prcdent. Le troisime et dernier composant est notre gestionnaire dvolution qui est dcrit au chapitre suivant. La gure 4.7 montre notre architecture pour linterface graphique.
Interface graphique
Gestionnaire de Requtes Schma Global/Schma Local Gnration SQL Excution SQL Schma relationnel + Mta-schma (mappings)
R s u l t a t
Entrept de donnes Sources de donnes
Fig. 4.7 Architecture pour linterface graphique Nous dcrivons les dirents lments qui composent linterface : Utilisateur : Les personnes qui utilisent cet outil pour exprimer leurs direntes requtes (indicateurs). Interface Graphique : Outil graphique o les utilisateurs peuvent choisir les divers composants (relations, mesures et proprits) conformes lindicateur exprim. Gestionnaire de Requtes : Il est compos de :
92
(Schma Global/Schma Local) : Composant qui permet de traduire le schma global (mta-schma) en schma local (relationnel). Gnration SQL : Outil semi-automatique qui permet de gnrer le code SQL partir du schma global et du schma local, pour rpondre aux besoins des utilisateurs. Excution SQL : Lexcution de la requte SQL sur lentrept de donnes. Rsultat : Les donnes qui correspondent la requte et qui doivent tre aches par linterface graphique. Schma Relationnel + Mta-Schma (Mappings) : Composant qui contient les schmas (Relationnel et Mta-Schma) et qui peut tre consult par le Gestionnaire de Requtes. Nous dcrivons le fonctionnement des modules pour la cration et/ou la mise jour du schma.
4.3.2
Fonctionnement de linterface
Cette interface permet la cration de la structure des relations. Nous avons construit un module pour la cration et un autre pour la mise jour des relations. Cration dune relation Nous pouvons crer des relations de faits ou de dimensions. La gure 4.8 montre un exemple de cration de la dimension E_Departement pour dcrire les direntes options : Description des composants : Relation : Il contient un n-uplet de type {Nom_relation : Type}, o le type reprsente une relation de Fait ou de Dimension. Par dfaut il est de type Dimension. Proprits : Il reprsente un ensemble de n-uplets de type {Nom_proprit : Type}, o Type {Texte, Mmo, Numrique, Date, Montaire, Boolen}. Cl Primaire : Il reprsente un ensemble de n-uplets de type {Nom_proprit : Type}, o Nom_proprit : Type {Proprits}. Cl Etrangre : Il reprsente un ensemble de n-uplets de type {Nom_proprit : Type = Nom_relation.Nom_proprit : Type}. O Nom_proprit : Type {Pro-
93
Fig. 4.8 Cration dune dimension prits} et Nom_relation {Relation}. Options : Elle est compose de : Sauvegarder : Pour lenregistrement de la relation. Reset : Pour nettoyer lcran et continuer la cration des relations. Exit : Pour sortir de linterface de cration. La cration dune relation gnre de faon automatique un chier qui contient sa structure. Lensemble de chiers crs sont accds de faon dynamique pour le module de gnration dindicateurs pendant lexcution de requtes. Structure du 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
94
Fig. 4.9 Structure de la dimension cl_primaire. Mise jour dune relation (fait ou dimension) Suivant la structure de la relation modier, le module de mise jour remplit les direntes options avec des mta donnes contenues dans la relation. Ainsi, lutilisateur peut ajouter, eacer ou modier les mta donnes contenues dans la structure, sauf le nom et le type (faits ou dimension) de la relation, car ils ne sont pas modiables.
4.3.3
Types de requtes excuter
Avant de dcrire le fonctionnement de linterface graphique, nous avons inclus des exemples de requtes que nous pouvons excuter. Nous avons classi les types de requtes par rapport au nombre de relations quelles intgrent. A lintrieur du premier type, nous avons aussi divis les requtes par rapport lensemble de paramtres quelles contiennent. Nous montrons quelques exemples : Requtes du type 1 : Correspondent aux requtes sur 1 relation. Nous dcrivons ce type : Slection sur 1 relation + condition sur un membre : Q1 : Quels sont les tablissements avec un nombre de lits autoriss suprieur 100 ? SELECT Cle_Finess, Raison_sociale, Adresse, NLA FROM Etablissement WHERE NLA > 100 Slection sur 1 relation + comptage + condition sur une mesure :
4.3 Interface graphique pour la Gnration (semi-automatique) dIndicateurs Q2 : Nombre de sjours. SELECT Sum(CompteDuree_sejour) FROM Prise_MCO HAVING Sum(SommeDuree_sejour)>100
95
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 HAVING Sum(SommeDuree_sejour)>100 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 HAVING Sum(SommeDuree_sejour)>100 ORDER BY Etablissement.Cle_Finess Dans la partie suivante, nous dcrivons linterface graphique que nous avons conue pour faciliter lexcution de lensemble des requtes.
4.3.4
Fonctionnement de linterface graphique
Lobjectif de notre interface est de faciliter la tche de cration dindicateurs aux utilisateurs. La gure 4.10 dcrit lutilisation de linterface pour la gnration (semiautomatique) de requtes. Nous avons utilis lindicateur : "Q4 : Nombre de sjours par tablissement et par maladie pendant le mois janvier (avec nombre de sjours >
96
100)", pour arriver la description des dirents choix lintrieur de linterface.
Fig. 4.10 Interface pour la gnration (semi-automatique) dindicateurs Par rapport lindicateur, nous devons choisir : la(s) relation(s), la(s) mesure(s) calculer, la(s) proprit(s) acher, la(s) condition(s) de slection (sur des mesures ou sur des membres) et lordre de prsentation des rsultats. Description des composants : Relations : Il contient lensemble des relations slectionnes par rapport lindicateur exprim. Mesures et leur condition : Il contient les mesures calculer ainsi que leur fonction de groupage. La condition reprsente une slection sur la mesure. Dans le code SQL92, cette condition est exprime dans la clause HAVING. Proprits et leurs paramtres : Ce composant contient lensemble de proprits acher comme rsultat de lexcution de la requte. Les paramtres reprsentent les conditions de slection sur les membres des dimensions. Dans le code SQL92, elles sont incluses dans la clause WHERE. Tri : Il reprsente lensemble de proprits considrer pour la mise en ordre des rsultats. Options : Elle est compose de :
97
Excuter : Pour lexcution de la requte. Reset : Pour nettoyer lcran et continuer avec la cration dune nouvelle requte. Exit : Pour sortir de linterface de gnration. Finalement, pour les quatre premiers composants, nous pouvons ajouter et/ou eacer les relations, les mesures, les proprits ou les conditions (aussi bien sur les mesures que sur les membres) qui ont t slectionnes. Par exemple, si nous eaons une relation, lensemble de ses attributs sont eacs de linterface. Par exemple, la gure 4.10 reprsente une requte qui requiert lexcution de trois jointures et de deux conditions de slection. La premire condition est une slection sur les mesures (Sum(SommeDuree_sejour)>100), tandis que la deuxime reprsente une slection sur les membres de la dimension Temps (Temps.Cle_Temps=1). La fonction de groupage est automatiquement calcule par rapport aux proprits slectionnes. Finalement, le rsultat est ach tri par hpital. Chaque fois que nous choisissons loption dExcution, nous crons un chier appel Requete.REL qui contient le code SQL92 gnr. En utilisant loutil dadministration ODBC pour tablir la connexion, nous envoyons ce code vers le programme Access pour son excution. La gure 4.11 montre le rsultat de lexcution de la requte.
Fig. 4.11 Rsultat de lexcution de la requte Q4 Loption Exit de cet cran nous permet revenir en arrire pour rexcuter la requte, pour changer certains paramtres ou pour excuter une nouvelle requte. Finalement, la gure 4.12 montre la requte gnre. Nous considrons que la requte Q4 illustre bien le rle des dirents composants de notre systme.
98
Fig. 4.12 Fichier Requete.REL
4.4
Bilan
Dans ce chapitre, nous avons dcrit notre exprimentation dans le cadre dun systme dcisionnel. Pour aboutir la mise en oeuvre du schma, nous avons utilis seulement une partie du modle multidimensionnel que nous avons conu pour le projet ADELEM (cf. Chapitre 3). La premire section sest focalise sur la construction du schma, que nous avons appel Adelem_MCO. Il se compose dune table de faits (Prise_MCO) et de quatre dimensions (Etablissement, CIM10, Temps et Mode_sortie). Nous avons construit ce schma en utilisant un chantillon du 10% des donnes relles du projet. La deuxime partie a t consacre aux vues matrialiser. Nous avons dabord utilis lalgorithme Greedy pour la slection de lensemble optimal de vues matrialiser, ensuite, nous avons appliqu notre algorithme. Nous les avons appliqu sur des donnes mdicales relles et nous avons constat que notre proposition donne de meilleurs rsultats pour notre cas dexprimentation. Nous avons termin cette partie avec la gnration de lensemble optimal de vues matrialiser. La dernire section dcrit linterface pour la gnration (semi-automatique) dindicateurs. Nous avons divis ce travail en quatre parties. La premire partie dcrit notre architecture pour linterface graphique. La deuxime dcrit le fonctionnement de linterface pour la cration et/ou la mise jour du schma. Nous avons group lensemble des lments qui intgrent cette interface dans 5 composants et nous avons termin cette partie avec la description de chaque composant. Dans la troisime partie, nous avons class les types de requtes par rapport au nombre de dimensions. Nous avons aussi donn des exemples de chaque type de requtes excuter sur linterface graphique et nous avons termin cette section avec la description du fonctionnement de linterface graphique pour la gnration (semi-automatique) de requtes. Nous avons utilis un exemple pour dcrire son
4.4 Bilan fonctionnement.
99
Dans le chapitre suivant, nous dployons notre proposition pour la gestion, le stockage et la visualisation de lensemble de donnes contenues dans un entrept de donnes. Nous proposons lutilisation des versions de schmas bitemporels pour la gestion de lvolution des donnes aussi bien intensionnelles que extensionnelles.
100
Chapitre 5 Aspects temporels et versions de schmas dans les entrepts

Malgr une conception attentive et soigneuse, la structure dune base de donnes est sujette de nombreux changements. Ces changements peuvent aecter aussi bien les donnes que leur structure. Pour grer ces changements, nous pouvons utiliser lvolution de schmas ou les versions de schmas. Pour rsoudre le problme de perte de donnes aprs des changements du schma, le concept dvolution de schma t introduit pour rcuprer les donnes existantes par le biais de leur adaptation au nouveau schma. Nanmoins, nous considrons que pour les systmes qui doivent grer des donnes historiques, lvolution de schma nest pas susante et la maintenance de plusieurs schmas est requise. Nous devons choisir la technique utiliser par rapport aux caractristiques de lapplication cible. Dans ce chapitre, nous utilisons un schma en volution qui contient aussi bien des changements sur les donnes extensionnelles que sur les donnes intensionnelles. Ceci nous permet dintroduire le concept de versions de schmas qui permettent de grer ces changements en gardant lensemble des donnes. Nous nous inspirons des besoins et des caractristiques dune application mdicale. Nous proposons lutilisation des versions de schmas pour la gestion, le stockage et la visualisation des donnes historises de lapplication mdicale ADELEM. Nanmoins, la gestion des versions est une tche complexe et elle prsente plusieurs problmes. Le principal, notre connaissance, est lexplosion des versions, car lexcution de chacune des primitives entrane la gnration dune nouvelle version. Ainsi, nous devons tablir un mcanisme pour contrler cette explosion. Pour faire cela, nous avons dni un oprateur appele SetVersion qui permet de grouper un ensemble de primitives excuter sur une version de schma et qui gnre une nouvelle [SA05b]. La gestion des versions de schmas requiert aussi la spcication dun ensemble de composants. Dabord, nous avons besoin dun ensemble de primitives permettant lvolution dune version vers une autre et dun ensemble de rgles dintgrit. Nous 101
102
Aspects temporels et versions de schmas dans les entrepts
avons aussi besoin dun gestionnaire dvolution qui manipule les direntes versions de schmas historises et dun moteur de versions. Ce dernier gre le stockage des deltas et les rgles de conguration ncessaires lors de la manipulation des versions de schmas.
5.1
Versions de schmas
Cette section prsente une introduction aux versions de schmas. Nous utilisons dabord un schma en volution pour dcrire le besoin de la gestion des versions de schmas. Ensuite, nous montrons la reprsentation bitemporelle de cet ensemble de versions.
5.1.1
Versions de schmas annuels dans un contexte mdical
Nous utilisons un schma en toile avec quatre dimensions qui est dcrit par la gure 5.1. Il reprsente une volution annuelle dune application mdicale. La table centrale reprsente une table de faits (Prise_MCO). Elle contient un n-uple pour chaque sjour dans un hpital.
CIM10 (VS01) Cle_Maladie Libelle_maladie
Etablissment (VS01) Cle_Finess Raison_sociale Code_postal CA1..CA7 ...
Prise_MCO (VS01) Cle_Maladie Cle_Finess Prise_MCO (VS02) Cle_Maladie Cle_Finess Temps (VS01) Cle_Temps Temps (VS02) Cle_Temps Mois Semestre Annee Prise_MCO (VS03) Cle_Maladie Cle_Finess Cle_Temps Cle_Mode Compte_sejour Somme_sejour
Etablissement (VS02) Cle_Finess Raison_sociale Adresse Code_postal CA1..CA7 ...
Mode_sortie (VS01) Cle_Mode Libelle_mode
Temps (VS03) Cle_Temps Mois Saison Semestre Annee
Fig. 5.1 Trois versions de schmas annuels. La gure 5.1 dcrit trois versions de schmas annuels pour la table de faits Prise _MCO et pour la dimension Temps. Nanmoins, dans la dernire version de schma de la dimension Temps VS03, le schma a t modi par lajout de lattribut Saison. La dimension Etablissement reprsente deux versions, o la version de schma VS01 reprsente la version pour lanne 2001 et la version VS02 correspond aux versions de schmas annuelles pour lanne 2002 et 2003. Cette version a t modie par
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 schmas, nous pouvons utiliser soit le temps transactionnel, soit le temps de validit, ou bien le bitemporel [DGS95, GM02, AQ86]. Le temps de validit dune version correspond aux instants auxquels cette version est vraie dans le monde modlis. De cette manire, nous pouvons linterroger par rapport la validit, des donnes de cette version, du schma correspondant, ou en utilisant un schma valide dans un intervalle dirent. Par contre, le temps transactionnel correspond linstant o un fait est enregistr dans la base. Dans cette approche, nous pouvons seulement modier le schma courant. Ainsi, si par exemple, nous avons besoin daccder une version historique pour corriger certains erreurs en gardant lhistoire complte des changements du schma, nous devons choisir le bitemporel pour la gestion du temps. Dans notre cas, nous avons dcid de manipuler les versions de schmas bitemporels. Ainsi, nous devons grer la combinaison du temps de transaction et du temps de validit (cf. Subsection 2.6.1.3). La gure 5.2 montre la gestion du temps pour lapplication mdicale prsente dans la gure 5.1.
01/01 01/03 01/04 UC
01/02
valid-time
07/02 VS01
07/03 VS02
07/04 VS03
07/05
UC
transaction-time
Fig. 5.2 Reprsentation bitemporelle des versions de schmas. Cette gure reprsente les versions de schmas bitemporels VS01, VS02 et VS03. Chaque version de schma a un temps de transaction et un temps de validit. Par
104
exemple pour la version VS01, nous avons un temps de transaction 2002-07 et un temps de validit de 2001-01 - 2001-12. Dans la suite, nous dcrivons les versions de schmas bitemporels. Nous supposons lexistence de lensemble {C, D, H, M, P, L, R} (cf. paragraphe 3.2.4) et de : V = Ensemble de noms des versions de schmas. CS = Ensemble des changements sur les schmas. = Reprsente une fonction timestamp1 . TIME = (TIMEt X TIMEv ) : TIME VS {} V Si si V Si active dans (tt, vt) sinon
(tt, vt) =
Nous dnotons par 1 (VS) le temps associ par la fonction VS. Ainsi, 1 (VS) reprsente la pertinence temporelle (timestamp) de VS. Finalement, notre version de schma reprsente un n-uplet VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) par rapport la gure 5.1, tel que : Vs = {VS01, VS02, VS03} Cs = {Prise_MCO} M = {Compte_sejor, Somme_sejour} Ds = {Etablissement, CIM10, Temps, Mode_sortie} P = {Cle_Finess, Raison_sociale, Adresse, Codepostal, CA1 .. CA7, CMO1 .. CMO7, NLA, NLO, Commune, Departement, Region, Pays, Cle_Maladie, ... } Hs = {} L = { } CS = {(AddProprieteAdresse , VS01, VS02), (AddProprieteSaison , VS02, VS03)} 1 (VS01) = (2002-07, UC2 )t X (2001-01 - 2001-12)v 1 (VS02) = (2003-07, UC)t X (2002-01 - 2002-12)v 1 (VS03) = (2004-07, UC)t X (2003-01 - 2003-12)v La gestion de lensemble des changements dun schma en volution requiert un nombre doprations primitives qui permettent aux donnes intensionnelles et extensionnelles, de continuer dexister ou dtre valides.
1 2
Nous utilisons la fonction prsente dans [GM02] Until Change
5.2 Les oprations primitives
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 entrepts de donnes et nous avons dni les rgles dintgrit requises.
5.2.1
Ensemble de primitives
Nous avons divis les primitives en deux catgories, la premire pour la gestion des cubes, des dimensions ou des hirarchies. La deuxime correspond aux primitives qui agissent sur les versions de schmas. Gestion de la relation (cube, dimension ou hirarchie) : Nous avons construit le tableau 5.1 avec lensemble des primitives qui agissent sur le contenu dune relation avec leur dnition et les rgles dintgrit. Gestion des versions : Le trableau 5.2 dcrit lensemble des primitives construites pour la gestion de versions avec leur dntion et les rgles dintgrit.
5.2.2
Ensemble de restrictions
Nous prsentons lensemble des rgles dintgrit que nous avons conu. Le format gnral pour leur dnition est le suivant : constraint nom_contrainte := constraint ; Nous listons lensemble des restrictions que nous avons dni par rapport aux oprations primitives prcdentes. Nous avons aussi divis les restrictions en deux catgories. Rgles dintgrit dnies Sur une relation : R1 : constraint addm := type(mn ) = numrique. R2 : constraint deletem := {M} 2. R3 : constraint created := cl primaire {FC}, o FC est lensemble de cls trangres qui appartiennent la relation de faits. R4 : constraint dropd := cl primaire / {FC}.
106
Primitive CreateC DropC RenameC AddM DeleteM RenameM CreateD DropD RenameD AddP DeleteP Change_typeP RenameP CreateH DropH RenameH AddL DeleteL RenameL
Dnition CreateC(BM, cn , {M}, {D}) DropC(BM, cn ) RenameC(BM, cn , cn ) AddM(BM, cn , mn ) DeleteM(BM, cn , mn ) RenameM(BM, cn , mn , mn ) CreateD(BM, dn , {P}, {H}) DropD(BM, dn ) RenameD(BM, dn , dn ) AddP(BM, dn , pn ) DeleteP(BM, dn , pn ) Change_typeP(BM, dn , pn , pn ) RenameP(BM, dn , pn , pn ) CreateH(BM, hn , L, ) DropH(BM, hn ) RenameH(BM, hn , hn ) AddL(BM, hn , ln , l1 , l2 ) DeleteL(BM, hn , ln ) RenameL(BM, hn , ln , ln )
Rgle dintgrit
(R1) type(mn ) = numrique (R2) {M} 2 (R3) cl primaire {FC} (R4) cl primaire / {FC}
(R5) proprit = cl primaire (R6) proprit = cl primaire (R7) proprit = cl primaire (R8) cl primaire {FC} cl primaire {FD} (R9) cl primaire / {FC} cl primaire / {FD}
(R10) cl primaire / {FC} cl primaire / {FD} (R11) cl primaire {FC} cl primaire {FD}
Tab. 5.1 Primitives pour la gestion de relation
Primitive CreationV FreezeV DefrostV ExporterR DropV
Dnition Rgle dintgrit AddV(BMS, VSn ) FreezeV(VSn ) (R12) (VSn )=vrai DefrostV(VSn ) ExporterR(VSn , CIM10, VSn ) (R13) dn VSn DropV(VSn ) (R14) DropV(VSn ) (VSn )=vrai Tab. 5.2 Primitives pour la gestion des versions
5.3 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 spcies prcdemment. Nous avons aussi identi un ensemble de proprits qui doivent tre prserves lors des volutions. Noms uniques : Les versions de schmas, les cubes, les dimensions, les hirarchies, les mesures, les proprits et les niveaux ont des noms uniques. Schma du cube : La cardinalit de lensemble daxes et de lensemble de mesures doit tre suprieure ou gale 1. Schma de dimension : La cardinalit de lensemble des proprits doit tre suprieure ou gale 1. Schma de hirarchie : Il est reprsent par un graphe acyclique dirig qui contient un seul noeud base et un seul noeud sommet . Schma de version : Il est reprsent par un schma multidimensionnel VS=(V, 1 C, D, H, R, CS, 1 ) et linstance est IV=(Vi , Ci , Di , Hi , Ri , CSi , i ). La smantique de lensemble de primitives doit respecter ces proprits. Pour la dnition des primitives, nous avons repris les 4 dnitions pour la spcication dune base de donnes multidimensionnelle dj prsentes (cf. Chapitre 3).
108
5.3.1
Gestion de la relation (cube, dimension ou hirarchie)
Dans cette partie, nous prsentons lensemble des dnitions des primitives qui agissent sur les schmas de cubes, de dimensions ou de hirarchies. Dnition 5.1 : Primitive CreateC Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et dins1 tance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), un nom de cube cn C, un ensemble de dimensions D tel que |D| 1 et un ensemble de mesures M tel que |M| 1, le rsultat de la primitive CreateC(VS, cn , M, D) est une version dont le schma est VS = (Vs , Cs {cs }, Ds , Hs , R, CS, 1 ), o cs est un schma de cube (cn , M, D) et linstance est IM = IM. Considrons linsertion dans la version VSi dun nouveau cube Achats qui contient lensemble de dimensions {Magasin, Temps, Produit, Fournisseur} et la mesure QuantiteA, la primitive CreateC(VSi , Achats, {Magasin, Temps, Produit, Fournisseur}, QuantiteA) cre le cube. Dnition 5.2 : Primitive DropC Cette primitive limine un schma de cube, ses dimensions et ses hirarchies dune version de schma VS. Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et 1 dinstance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), un nom de cube cn C, la primitive DropC(VS, cn ) cre une version dont le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Cs = Cs \{(cn , m1 ,..., mj , D)}. Linstance est IV = (Vi , Ci \{ci }, Di , 1 Hi , Ri , CSi , i ), o ci = {(cn , {(v1 ,..., vj )| i=1,...,n vi measuredom(mi )}, {d})}. Par exemple, pour liminer le cube Achats de la version VSi , nous excutons la primitive DropC(VSi , Achats). Dnition 5.3 : Primitive RenameC Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et dins1 tance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), les noms de cubes cn cn C, lexcution de la primitive RenameC(VS, cn , cn ) fournit une version dont le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Cs = Cs \{(cn , M, D)} {(cn , M, D)}, et linstance est IV = IV. Par exemple, pour renommer le cube Ventes par VentesJournalieres : RenameC(VSi , Ventes, VentesJournalieres). Dnition 5.4 : Primitive AddM
109
Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et dins1 tance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), un nom de cube cn C et un nom de mesure mn M, la primitive AddM(VS, cn , mn ) cre une version dont le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Cs = Cs \{(cn , M, D)} {(cn , M {mn }, 1 D)}, et linstance est IV = (Vi , Ci , Di , Hi , Ri , CSi , i ) o Ci = C i \{ci } {ci }, o ci = (cn , {(m1 ,..., mi )}, {d}) et ci = (cn , {(m1 ,..., mi )} {mn }, {d}). Par exemple, pour ajouter la mesure QuantiteV au cube Ventes, nous excutons la primitive AddM(VSi , Ventes, QuantiteV). Dnition 5.5 : Primitive DeleteM Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et dins1 tance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), un nom de cube cn C et un nom de mesure mn M tel que |M| 2, le rsultat de DeleteM(VS, cn , mn ) est une version dont le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Cs = Cs \{(cn , 1 M, D)} {(cn , M\{mn }, D)}. Linstance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ) o Ci = C i \{ci } {ci }, o ci = (cn , {(m1 ,..., mi )}, {d}) et ci = (cn , {(m1 ,..., mi )}\{mn }, {d}). Par exemple, pour supprimer la mesure QuantiteV de cube Ventes : DeleteM(VSi , Ventes, QuantiteV). Dnition 5.6 : Primitive RenameM Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et dins1 tance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), un nom de cube cn C et les noms mn et mn M, lexcution de la primitive RenameM(VS, cn , mn , mn ) donne une version dont le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Cs = Cs \{(cn , M, D)} {(cn , M\{mn } {mn }, D)}. Linstance est IV = IV. Par exemple, pour changer le nom de la mesure Quantite par QuantiteJournaliere, nous excutons la primitive RenameM(VSi , Ventes, Quantite, QuantiteJournaliere). Dnition 5.7 : Primitive CreateD Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et 1 dinstance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), un nom de cube cn C un nom de dimension dn D, un ensemble de proprits P tel que |P| 1 et H, le rsultat de la primitive CreateD(VS, Cn , dn , P, H) est une version dont le schma est VS = (Vs , Cs , Ds {ds }, Hs , R, CS, 1 ), o Cs = Cs \{(cn , M, D)} {(cn , M, D {dn })} 1 et Ds = Ds {ds }. Linstance est IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), o Ci = Ci \{ci } {ci }, ci = (cn , {m}, {d1 ,... di }), ci = (cn , {m}, {d1 ,... di } {dn }) et Di
110 = Di .
Considrons par exemple la cration de la dimension Fournisseur qui contient lensemble de proprits {Cle_F, Raison_sociale, Adresse, Tlphone, Pays} au cube Ventes, nous excutons la primitive CreateD(VSi , Ventes, Fourniseur, {Cle_F, Raison_sociale, Adresse, Tlphone, Pays}, {}). Dnition 5.8 : Primitive DropD Cette primitive limine un schma de dimension et leurs instances dune version VSi . La primitive ne peut pas tre excute sil existe un schma de cube qui utilise cette dimension. Ainsi, nous supposons lexistence dune fonction boolenne indiquant si la dimension peut tre supprime. Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et 1 dinstance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), un nom de dimension dn D tel que (dn =vrai), la primitive DropD(VS, dn ) cre une version dont le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Ds = Ds \{(dn , P, H)}. Linstance est IV = 1 (Vi , Ci , Di , Hi , Ri , CSi , i ), o Di = Di \{di }, o di = (dn , {(v1 ,..., vx )| i=1,...,n vi propertydom(pi )}, {h}). Par exemple, pour supprimer la dimension Magasin, nous excutons la primitive DropD (VSi , Magasin) (Magasin)=vrai. Dnition 5.9 : Primitive RenameD Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et dins1 tance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), un nom de cube cn C et deux noms de dimensions dn , dn D, lopration RenameD(VS, cn , dn , dn ) fournit une version dont le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Cs = Cs \{(cn , M, D)} {(cn , M, D\{dn } {dn })} et Ds = Ds \{(dn , P, H)} {(dn , P, H)} et linstance est IV = IV. Par exemple, pour changer le nom de la dimension Magasin par le nom Boutique du cube Ventes : RenameD(VSi , Ventes, Magasin, Boutique). Dnition 5.10 : Primitive AddP Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et dins1 tance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), un nom de dimension dn D et un nom de proprit pn P, la primitive AddP(VS, dn , pn ) cre une version dont le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Ds = Ds \{(dn , P, H)} {(dn , P {pn }, 1 H)}, et linstance est IV = (Vi , Ci , Di , Hi , Ri , CSi , i ) o Di = D i \{di } {di }, o di = (dn , {(p1 ,..., pi )}, {h}) et di = (dn , {(p1 ,..., pi )} {pn }, {h}).
111
Par exemple, pour ajouter la proprit Telephone la dimension Magasin, nous excutons la primitive AddP(VSi , Magasin, Telephone). Dnition 5.11 : Primitive DeleteP Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et dins1 tance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), un nom de dimension dn D et un nom de proprit pP tel que |P| 2, le rsultat de DeleteP(VS, dn , p) est une version dont le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Ds = Ds \{(dn , P, H)} {(dn , 1 P\{p}, H)}. Linstance IV = (Ci , Di , Hi , Ri , CSi , i ) o Di = D i \{di } {di }, o di = (dn , {(p1 ,..., pi )}, {h}) et di = (dn , {(p1 ,..., pi )}\{p}, {h}). Pour supprimer la proprit Telephone de la dimension Magasin, nous excutons la primitive DeleteP(VSi , Magasin, Telephone). Dnition 5.12 : Primitive Change_typeP Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et dins1 tance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), un nom de dimension dn D et les noms de proprits pn , pn P, le rsultat de Change_typeP(BM, dn , pn , pn ) est une version dont le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Ds = Ds \{(dn , 1 P, H)} {(dn , P\{pn } {pn }, H)}. Linstance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ) o Di = Di \{di } {di }, o di = (dn , {(p1 ,..., pi )}\{pn }, {h}) et di = (dn , {(p1 ,..., pi )} {pn }, {h}). Par exemple, pour changer la proprit Codepostal de integer char : Change_ typeP(VSi , Magasin, Codepostal, CodepostalChar). Dnition 5.13 : Primitive RenameP Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et dins1 tance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), un nom de dimension dn D et les noms de proprits pn , pn P, le rsultat de RenameP(VS, dn , pn , pn ) est une version dont le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Ds = Ds \{(dn , P, H)} {(dn , P\{pn } {pn }, H)}. Linstance IV = IV. Par exemple, pour changer le nom de la proprit Raison par Raison _sociale : RenameP(VSi , dn , Raison, Raison_sociale). Dnition 5.14 : Primitive CreateH Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et dins1 tance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), un nom de dimension dn D un nom de
112
hirarchie hn H, un ensemble de niveaux L et une relation dnie sur L, le rsultat de la primitive CreateH(VS, dn , hn , L, ) est une version dont le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Ds = Ds \{(dn , P, H)} {(dn , P, H {hn })} et Hs = Hs {hs }, o hs est un schma de hirarchie (hn , L, ). Linstance est IV 1 = (Vi , Ci , Di , Hi , Ri , CSi , i ), o Di = Di \{di } {di }, di = (dn , {p}, {(h1 , ..., hk )}), di = (dn , {p}, {(h1 , ..., hk )} {hn }) et Hi = Hi . Considrons par exemple la cration de la hirarchie H_Temps qui contient lensemble de niveaux {Jour, Mois, Saison, Annee}. La relation entre les niveaux est {(Jour, Mois), (Mois, Saison), (Saison, Annee)}. La primitive CreateH(VSi , Etablissement, H_Temps, L, ) insre la dimension Etablissement, la nouvelle hirarchie. 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. Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et 1 dinstance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), un nom de hirarchie hn H tel que (hn )=vrai, la primitive DropH(VS, hn ) fournit une version dont le schma est VS = (Vi , Cs , Ds , Hs , R, CS, 1 ), o Hs = Hs \{(hn , L, )}. Linstance est IV = 1 (Vi , Ci , Di , Hi , Ri , CSi , i ), o Hi = Hi \{( li L levelset(li ), RUP)}. Par exemple, pour supprimer la hirarchie H_Temps : DropH(VSi , H_Temps). Dnition 5.16 : Primitive RenameH Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et dins1 tance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), le nom de dimension dn D, et deux noms de hirarchies hn et hn H, la primitive RenameH(VS, dn , hn , hn ) cre une version dont le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Ds = Ds \{(dn , P, H)} {(dn , P, H\{hn } {hn }) et Hs = Hs \{(hn , L, )} {(hn , L, )}. Linstance est IV= IV. Par exemple, pour renommer la hirarchie H_Temps de la dimension Temps par le nom H_Jour, nous excutons la primitive RenameH(VSi , Temps, H_Temps, H_Jour). Dnition 5.17 : Primitive AddL Cette primitive modie le schma de hirarchie hs en construisant une relation entre les niveaux l1 et l2 qui appartiennent hs et un nouveau niveau ln . Cette opration tablit les relations de dpendances suivantes : l1 ln et ln l2 . Pour faire cela, nous supposons lexistence dune fonction qui, tant donns un nom de hi-
113
rarchie hn et deux niveaux li et lj , retourne une valeur boolenne gale vrai si li lj . Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et dins1 tance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), un nom de hirarchie hn H, les niveaux ln , l1 et l2 L, et un membre mlevelset(ln ), la primitive AddL(VS, hn , ln , l1 , l2 ) cre une version dont le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) tel que Hs = (Hs \{hs } {hs }), o hs = (hn , L, ) et hs = (hn , L {ln }, {(l1 ln ), 1 (ln l2 )}). Linstance est IV = (Vi , Ci , Di , Hi , Ri , CSi , i ) telle que Hi = (Hi \ {hi } {hi }), o hi = ( li L levelset(li ), RUP) et hi = ( li L {ln } levelset(li ),
n RUP). Lensemble RUP contient les fonctions ruplj telles que rupl l1 = {(e, m)|e i lj lj 2 levelset(l1 )}, rupl ln = {(e, m)|e levelset(l2 )} et rupli = rupli pour les autres niveaux li et lj .
Par exemple si nous voulons insrer le niveau District la hirarchie H_Geo de la gure 3.4 (cf. Chapitre 3) entre les niveaux Departement et Region, la primitive AddL(VSi , H_Geo, District, Departement, Region, Columbia) modie le schma et linstance de la hirarchie spcie. La gure 5.3 montre le rsultat de cet oprateur.
Region
Rhne Alpes
...
District
Columbia
...
Departement
Isre
...
Commune
Lyon
Grenoble
Annecy
a) Schma
b) Instance
Fig. 5.3 Insertion du niveau District la Hirarchie H_Geo. Dnition 5.18 : Primitive DeleteL Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et dins1 tance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), un nom de hirarchie hn H, et un niveau ln L, tel que ln = et ln =l, la primitive DeleteL(VS, hn , ln ) donne une version
114
dont le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Hs = (Hs \{(hn , L, )} {(hn , L, )}), o L = (L\{ln }), = (\{(l1 , l2 )|ln = l1 (ln = l2 )}) {(l1 , 1 l2 )|l1 ln ln l2 }. Linstance est IV = (Vi , Ci , Di , Hi \{hi } {hi }, Ri , CSi , i ), o hi = ( li L levelset(li ), RUP) et hi = ( li L levelset(li ), RUP). Lensemble l l2 ln 2 RUP contient les fonctions ruplj telles que (i) rupl l1 = rupl1 rupln , si l1 ln i l2 2 ln l2 , (ii) rupl l1 = rupl1 , dans les autres cas. Par exemple si nous voulons eacer le niveau Departement la hirarchie H_Geo de la gure 5.3 entre les niveaux District et Commune, nous excutons la primitive DeleteL(VSi , H_Geo, Departement). La gure 5.4 montre le rsultat de cet oprateur.
Region
Rhne Alpes
...
District
Columbia
...
Commune
Lyon
Grenoble
Annecy
a) Schma
b) Instance
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 hn de la hirarchie, le niveau renommer, lancien nom ln et le nouveau nom ln . Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et 1 dinstance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), un nom de hirarchie hn H, et les niveaux ln et ln L, la primitive RenameL(VS, hn , ln , ln ) cre une version dont le schma est VS = (Vs , Cs , Ds , Hs , R, CS, 1 ), o Hs = Hs \{(hn , L, )} {(hn , L\{ln } {ln }, )}, et linstance est IV = IV. Par exemple, pour renommer le niveau Commune de la hirarchie H_Geo par le nom Ville : RenameL(VSi , H_Geo, Commune, Ville).
115
5.3.2
Gestion des versions
Nous prsentons lensemble des dnitions de primitives qui agissent sur la gestion de versions de schmas. Nous considrons lexistence de : DOM = dom(char) dom(integer= dom(oat) contenant le domaine de chaque type atomique. OP = Ensemble de oprations primitives. Dnition 5.20 : Primitive CreateV Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et dins1 tance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), et un nom de version vn V, le rsultat de CreateV(VS, vn ) cre une nouvelle version dont le schma est VS = VS et linstance est IV = IV. Par exemple, supposons que nous voulons crer une version de schma VSj partir de la version VSi . La primitive CreateV(VSi , VSj ) cre la version VSj = (Vs , Cs , Ds , Hs , R, CS, 1 ). Dnition 5.21 : Primitive FreezeV Cette primitive permet de geler une version (i.e., elle ne permet plus de changements). La seul primitive que nous pouvons appliquer une version gele est DefrostV (cf. Dnition 5.22). Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et dins1 tance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), et un nom de version vn V, la primitive FreezeV(vn ) bloque cette version en interdisant lexcution des primitives dvolution. La version de schma est VSi =vn dont le schma est VS = (Vs , Cs , Ds , Hs , R, 1 CS, 1 ) et linstance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ). i=1,...,n pi OP, pi (VSi ) sexcute si et seulement si VSi nest pas gele. Dnition 5.22 : Primitive DefrostV Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et 1 dinstance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), et un nom de version vn V, la primitive DefrostV(vn ) fournit une version de schma VSi =vn dont le schma est VS 1 = (Vs , Cs , Ds , Hs , R, CS, 1 ) et linstance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ). i=1,...,n ei E(VSi ) pi (VSi ) sexcute, o pi OP. 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. dom(decimal) dom(date)
116
Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et dins1 tance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), un schma de dimension dn D et un nom de version vn V, le rsultat de ExporterR(VS, dn , vn ) est une version VS dont le schma est VS = (Vs , Cs , Ds {ds }, Hs , R, CS, 1 ), o ds est un schma de dimension (dn , P, H), et linstance est IV = IV. Par exemple, pour faire migrer la dimension CIM10 qui appartient la version VSn , nous excutons la primitive ExporterR(VSn , CIM10, VSn ), o le schma de la dimension CIM10 est (CIM10, {Cle_Maladie, Libelle_maladie}, {}). 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. Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et 1 dinstance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), et un nom de version vn V tel que (vn )=vrai, la primitive DropV(VSi ), o VSi = vn , limine la version de schma SVi ainsi que leurs instances. Dnition 5.25 : Oprateur SetVersion Etant donns une version de schma VS = (Vs , Cs , Ds , Hs , R, CS, 1 ) et dins1 tance IV = (Vi , Ci , Di , Hi , Ri , CSi , i ), un ensemble de primitives {EP} et les noms de versions vn et vn V, la primitive SetVersion(VSi , {EP}, VSj ), o VSi = vn et VSj = vn , cre la version de schma VSj dont le schma est VS = (Vs , 1 Cs , Ds , Hs , R, CS, 1 ) et linstance est IV = (Vi , Ci , Di , Hi , Ri , CSi , i ). Si nous voulons crer une nouvelle version VSj partir de la version courante VSi incluant les changements : {EP}=(DropC(VSi , Prise_MCO), DropD(VSi , Mode_sortie), ExporterR(VSi , CIM10, VSj ), ExporterR(VSi , Etablissement, VSj ), RenameP(VSi , Etablissement, Codepostal, Code), ExporterR(VSi , Temps, VSj ), DeleteP(VSi , Temps, Saison)), lexcution de SetVersion (VSi , {EP}, VSj ) donne le rsultat souhait. Chaque primitive de lensemble EP doit respecter la dnition donne prcdemment.
5.4
Gestion temporelle des entrepts
Nous traitons dans cette section la gestion des donnes historises de notre modle. Nous montrons dabord larchitecture conue simplie du projet et linterac-
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
Gestionnaire de Requtes
Entrept de donnes
Donnes de dtail et rsumes (courantes)
Fig. 5.5 Interaction des composants lintrieur de larchitecture. Le composant Interface Graphique contient un gestionnaire de requtes qui interagit avec le gestionnaire dvolution dans lexcution de requtes sur des schmas historiss. Nous donnons dans la suite une description de la gestion de versions de schmas.
5.4.2
Modle de versions de schmas bitemporels
Le gestionnaire dvolution est compos dun entrept de donnes historises et du moteur de versions. La gure 5.6 montre le modle de versions de schmas bitemporels. Lentrept de donnes historises contient le schma et les instances de chaque version de schma hisorise ainsi que la table de correspondance. Celle-ci est requise pour spcier la pertinence temporelle entre les donnes intensionnelles de la version de schma et les donnes extensionnelles. Le moteur de versions contient la fois le stockage des deltas entre versions et les rgles de conguration que nous devons respecter lors de la gestion des versions.
118
Gestionnaire dvolution
Entrept de donnes historises

Donnes intensionnelles et extensionnelles + 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 symtrique entre SVi et SVj = (SVi - SVj ) (SVj - SVi ) et un delta direct est une squence de changements c1 , ..., cn qui appliqus sur une version v1 en gnerent une nouvelle v2 [CW98, RGMS01]. Notre gestionnaire de versions bitemporels est au-dessus du systme de gestion de bases de donnes. Dans cette approche, le modle de version est orthogonal au modle de donnes du SGBD [CW98, WMC01]. Nous considrons le stockage de lensemble de changements qui produisent une version, pour cela, le mta-schma se compose de : Table pour la version de schma : Identication de la version.
TVS = {ID_Version, ID_Conteneur, Version_nom, Temps_transaction, Temps_validite, Version_immuable}
Lattribut Version_immuable est de type boolen. Par dfaut il est faux. Table pour la relation :
TR = {ID_Relation, ID_Version, Relation_nom, Temps_transaction, Temps_validite, Relation_immuable, Relation_type}
Lattribut Relation_type spcie les types : cube, dimension, hirarchie, vue matrialise, vue. Table pour les attributs :

TA = {ID_Attribut, ID_Relation, Attribut_nom, Attribut_type, Attribut_taille, Temps_transaction, Temps_validite, Attribut_immuable, Key}
119
Lattribut Key est de type boolen et sert pour indiquer si ID_Attribut fait partie de la cl primaire. Table dquivalences :
TE = {ID_Attribut, ID_Relation, Attribut_nomancien, Attribut_nomnouveau, Temps_transaction, Temps_validite, Attribut_immuable}
Cette table stocke lquivalence entre attributs renomms. Les rgles de conguration contiennent lensemble des rgles dintgrit dj dnies, nanmoins, nous pouvons aussi en dnir de nouvelles, par exemple : versioncourante = 1 (VSi ) = maximum Cette rgle tablit que la version courante sera celle dont la pertinence temporelle est maximum. Nous avons dit prcdemment que la requte est excute sur les donnes courantes. Nanmoins, pour les requtes sur des donnes historises, le composant Interface Graphique interagit avec le composant Gestionnaire dvolution pour dterminer la possibilit dexcution de la requte.
5.4.3
Gestionnaire dvolution de schmas
Dans cette partie, nous traitons la gestion de donnes historises et lactivit du gestionnaire dvolution de schmas par niveau. La gure 5.7 montre le dtail de la gestion des donnes historiques. Nous considrons une base de donnes pour stocker le mta-schma et un ensemble de bases de donnes historiques pour enregistrer les donnes intensionnelles et extensionnelles ainsi que la table de correspondance (TC) de chaque version de schma. Cette table stocke la pertinence temporelle des donnes extensionnelles par rapport la pertinence temporelle de leurs donnes intensionnelles. La gure 5.8 dcrit lactivit du gestionnaire dvolution par niveau. Le niveau 3 stocke lensemble des changements des versions de schma et lensemble des rgles de conguration lors de la cration et de la manipulation des versions. A lintrieur de ce niveau, la pertinence temporelle de requtes danalyses ou de comparaison sur des donnes courantes et historises est dtermine. Par
120
Gestionnaire dvolution
...
Donnes intensionnelles et extensionnelles historises 1 + Table Corresp. Donnes intensionnelles et extensionnelles historises n + Table Corresp.
Stockage de deltas
Meta Schema
Rgles de Configuration
Fig. 5.7 Gestionnaire dvolution de schmas.
Deltas + Rgles de Configuration
Niveau 3 (Meta-schema)
0 T
T1
T2
T3
T4
UC
VS01 (DI)
tv
Niveau 2 (Intensionnel)
Table de Corresp.
VS01 (DE) T VS02 (DI)
Niveau 1 (Extensionnel)
Table de Corresp.
VS02 (DE) T VS03 (DI)
UC
tt
Table de Corresp.
Historique
VS03 (DE)
Fig. 5.8 Gestion dvolution de schmas par niveau.
121
exemple, si le mta-schma de la requte sur la version de schma courant concide avec celui de la version de schma historique, nous pouvons excuter la requte sur les deux versions de schmas. Dans le cas contraire, la requte est annule et lutilisateur doit tre inform. Les niveau 1 et 2 reprsentent les direntes versions de donnes (extensionnelles et intensionnelles) de faon linaire par rapport au temps de cration. La table de correspondance fait partie du niveau intensionnel, dans la suite, nous dcrivons son fonctionnement. Table de Correspondance : Nous avons place dans le niveau 2 la table de correspondance ncessaire pour la pertinence temporelle entre lensemble de donnes. Le schma de la table est : {ID_Table, ID_Version, ID_Conteneur, Cle_Temps, Temps_transaction, Temps_validite}. Ceci nous permet de stocker les donnes extensionnelles sans leur ajouter les proprits Temps_transaction et Temps_validite. Etant donn la taille de lensemble des donnes extensionnelles, cette table nous permet davoir un gain trs considrable sur la quantit des donnes stocker. Par exemple, en utilisant la syntaxe du langage TSQL2 [Sno95], nous pouvons exprimer les requtes suivantes : SET SCHEMA DATE now SELECT * FROM Prise_MCO WHERE VALID (Prise_MCO) OVERLAPS PERIOD 2003-01 - 2003-12 ou SET SCHEMA TRANSACTION DATE 2004-07 SELECT * FROM Prise_MCO WHERE VALID (Prise_MCO) OVERLAPS PERIOD 2003-01 - 2003-12 Nous avons le mme rsultat pour les deux requtes, car elles sont excutes sur la version de schma courant, aussi bien sur les donnes intensionnelles quintensionnelles. Au contraire, la requte : SET SCHEMA VALID PERIOD 2002-01 - 2002-12 SELECT * FROM Prise_MCO WHERE VALID (Prise_MCO) OVERLAPS PERIOD 2002-01 - 2002-12 prend des donnes de la table Prise_MCO qui ont t valides durant la priode 2002-01 - 2002-12, cette requte utilise le schma valide durant la mme priode du temps. Dans la suite, nous montrons un exemple plus complexe :
122
SET SCHEMA VALID PERIOD 2003-01 - 2003-12 SELECT * FROM Prise_MCO WHERE VALID (Prise_MCO) OVERLAPS PERIOD 2002-01 - 2002-12 La requte slectionne le schma valide entre 2003-01 et 2003-12 qui correspond, dans notre cas, au schma courant. Les donnes valides entre 2002-01 et 2002-12 correspondent aux donnes de la version historise VS02.
5.5
Bilan
Dans un entrept de donnes, la manipulation des donnes historises est essentielle. Nanmoins, leur gestion est une tche complexe et coteuse. Dans ce chapitre, nous avons prsent notre proposition pour la gestion, le stockage et la visualisation de lensemble de donnes historises. Nous avons introduit dabord un ensemble de versions de schmas annuels dans un contexte mdical. Ce schma est compos dune toile avec quatre dimensions prsentant divers changements au cours du temps. En considrant ces changements, nous avons cre un ensemble de versions de schmas qui nous permet la manipulation des donnes sans perte. Nous avons aussi donn une reprsentation bitemporelle pour chaque version de schma. Pour la cration et la gestion des versions de schmas, nous avons spci une liste doprations primitives divise en deux catgories, la premire rassemble un ensemble de 19 primitives ncessaires pour la gestion des cubes, des dimensions et des hirarchies. La deuxime contient 5 primitives qui agissent sur les versions de schmas. Nous avons aussi dni loprateur SetVersion qui permet de grouper un ensemble de primitives excuter sur une version de schma et qui gnre une nouvelle version. De cette manire, nous pouvons contrler le nombre de versions gnres. Nous avons aussi dni un ensemble de contraintes pour la manipulation des versions. La smantique de lensemble de primitives doit respecter cet ensemble de contraintes pour assurer une gestion cohrente. Pour chaque primitive, nous avons donn sa dnition formelle. Pour ce faire, nous avons repris la dnition dune base de donnes multidimensionnelle, dun cube, dune dimension, dune hirarchie ainsi que de leurs instances donnes au Chapitre 3. La dnition formelle de la primitive considre aussi bien son schma que ses instances. La dernire section a trait la gestion temporelle des entrepts de donnes. Nous avons donn une architecture simplie qui dcrit linteraction entre gestionnaires de requtes et dvolution. Nous avons prsent notre modle de versions de schmas bitemporels compos dun entrept de donnes historises et dun moteur de versions stockant les deltas et les rgles de conguration. Nous avons donn la description du gestionnaire dvolution de schmas. Nous avons prsent aussi bien la gestion de donnes historises que lactivit du gestionnaire dvolution par niveau. Le niveau
5.5 Bilan
123
1 dcrit la gestion des donnes extensionnelles, le niveau 2 prsente la manipulation des donnes intensionnelles et le niveau 3 montre la gestion des deltas ainsi que des rgles de conguration. Finalement, nous avons termin cette partie avec quelques exemples de requtes en utilisant la syntaxe du langage TSQL2 pour spcier la version de schma souhaite.
124
Chapitre 6 Conclusions et perspectives

6.1 Bilan du travail ralis
Les entrepts de donnes tendent les concepts et la technologie traditionnelle des bases de donnes pour crer des systmes daide la dcision. Ils intgrent des informations provenant des sources de donnes qui sont souvent htrognes et distribues. En consquence, la conception et la mise en oeuvre dun entrept est une tche complexe, elle se compose de trois processus : extraction-intgration, organisation et interrogation. Notre proposition se place lintrieur des processus dorganisation et dinterrogation.
6.1.1
Principales contributions
Nous listons nos contributions pour la conception et la mise en oeuvre dun entrept de donnes : - Dnition dun modle multidimensionnel. - Traitement de requtes et algorithme pour la slection optimale de vues matrialiser. - Interface graphique pour la gnration (semi-automatique) des requtes. - Versions de schmas bitemporels pour la gestion de donnes mdicales historises.
6.1.2
Dnition dun modle multidimensionnel
Notre mtamodle multidimensionnel se compose de trois classes : Cube, Dimension et Hirarchie. Ce mtamodle sert la conception dun modle multidimensionnel. Pour faire cela, nous avons donn quatre dnitions : le schma dune base multidimensionnelle, dun cube, dune dimension et le schma dune hirarchie.
125
126
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 simplicit. Notre objectif est de normaliser et de faciliter dans la mesure du possible le dveloppement de cette phase.
6.1.3
Algorithme pour la slection des vues matrialiser
Nous avons appliqu notre algorithme et celui de Greedy aux donnes du projet ADELEM. Lalgorithme Greedy est simple et ecace, nanmoins, dans notre exprimentation, partir du 6me choix, lalgorithme slectionne les vues les plus coteuses. Ceci nous a motiv pour proposer un algorithme qui tend Greedy avec les paramtres : frquence dutilisation, cot de calcul et frquence des mises jour sur les relations de base. Nous avons remarqu que plusieurs propositions utilisent comme frquence dutilisation un nombre assign chaque vue, par exemple : la frquence dutilisation pour la vue V1 est gale 10, V2 5, V3 1, ... Ainsi, la particularit de notre algorithme rside dans la spcication de deux propositions. La premire consiste utiliser la complexit de la vue (nombre de ses relations dpendantes) pour les deux premiers paramtres : la frquence dutilisation et le cot de calcul de la vue. Ainsi, nous considrons que la frquence dutilisation dune vue augmente en proportion directe du nombre de ses relations dpendantes et que le cot de calcul diminue dans la mme proportion. La deuxime proposition consiste dterminer la frquence des mises jour sur les relations de base, dans ce cas, nous avons besoin du nombre dlments lintrieur de la vue qui peuvent subir des changements. Nous avons constat que notre proposition donne de meilleurs rsultats dans notre cas exprimental. La faiblesse de notre algorithme est labsence du cot dvaluation dune requte par rapport au type dopration (Select, Project ou Join). Nous ne considrons pas
6.1 Bilan du travail ralis des restrictions comme lespace de stockage.
127
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 structure. Pour sa gestion, nous pouvons utiliser lvolution de schmas ou les versions de ceux-ci. En ce qui concerne lvolution de schmas, elle permet la rcupration des donnes existantes par le biais de leur adaptation au nouveau schma. Nanmoins, lvolution nimplique pas un support historique de celui-ci et elle ne considre non plus un mcanisme pour la visualisation des donnes travers des schmas volus. Par consquence le concept dvolution de schma nest pas susant et il est ncessaire dtablir une stratgie spcique pour rpondre cette ncessit. Lapproche des versions de schma a t utilise principalement pour la cohrence des donnes et de leurs schmas courants. Nous considrons cette approche comme une alternative aux systmes qui doivent grer et manipuler des donnes historiques. Dans le cas prcis du projet ADELEM, nous proposons lutilisation de versions de schma pour grer les aspects temporels de lentrept de donnes. La principale caractristique de notre proposition consiste fournir une approche simple et adapte au paradigme des entrepts pour la gestion et la manipulation aussi bien des donnes historiques que courantes. En plus, la dirence des systmes temporels, o lensemble de donnes doit contenir la notion du temps, les donnes extensionnelles dans notre approche sont stockes telles quelles. Bien que nous nous sommes inspirs des caractristiques et des besoins du projet ADELEM, notre approche de versions peut tre utilise par tout systme qui doit grer des donnes historises. Cest la raison pour laquelle nous avons dcid duti-
128
liser les temps de transaction et de validit et de fournir lensemble de primitives dnies.
6.2
Perspectives
Nous avons un ensemble de perspectives permettant de continuer le travail prsent ainsi que son amlioration. Nous avons dit prcdemment que nous avons seulement dvelopp une version initiale de linterface, ainsi, nous dcrivons dabord lextension du prototype ralis. Nous donnons aussi une autre perspective pour la gestion des donnes, celle dinclure les aspects spatiaux aux donnes mdicales. Finalement, nous incluons dautres perspectives quil est intressant de prendre en compte.
6.2.1
Extension du prototype
Nous avons divis ce travail en deux parties : limplantation de lalgorithme pour la slection des vues matrialiser et les versions de schmas pour la gestion de donnes historises. 6.2.1.1 Algorithme propos
Le dveloppement de lalgorithme a deux objectifs : disposer dun mcanisme pour la slection automatique de lensemble de vues matrialiser et rcuprer par le biais de leur utilisation, des statistiques relles pour amliorer et perfectionner les paramtres initiaux que nous avons tablis. De cette manire, nous pouvons collecter la frquence dutilisation relle des vues matrialises. Ceci nous permettra de proposer de nouvelles vues pour leur matrialisation ou den eacer dautres. Une autre statistique collecter est la frquence relle des mises jour des relations de base, ce qui permettra dadapter la probabilit de changement appliquer. Lutilisation des agrgats est loutil le plus ecace pour amliorer les performances. Nanmoins, nous devons tablir un mcanisme permettant lutilisation des vues matrialises dans lexcution dune requte. Une ide assez simple consiste ordonner lensemble de vues matrialises par rapport leur cot de stockage. De cette manire, si la requte peut tre excute en utilisant la premire vue, nous arrtons le processus doptimisation. Dans le cas contraire, nous prenons la deuxime vue de lensemble et nous continuons le processus. Si nous arrivons la n de lensemble, nous devons excuter la requte en utilisant les relations de base. Finalement, nous considrons comme important les problmes de la gestion des index et la possibilit dutiliser un cache pour loptimisation des requtes.
6.2 Perspectives 6.2.1.2 Versions de schmas bitemporels
129
Limplantation des versions de schmas permettra lexcution des requtes sur les donnes historises. Ainsi, nous pourrons faire des calculs prvisionnels ou des requtes comparatives qui comportent des donnes aussi bien courantes que historises. Par exemple, si le mta-schma de la requte sur la version de schma courant concide avec celui de la version de schma historique, nous pouvons excuter la requte sur les deux versions de schmas. Pour faire cela, le gestionnaire dvolution interagit avec le gestionnaire de requtes pour dterminer la possibilit dexcution de cette requte. Notre gestionnaire de versions bitemporels est au-dessus du systme de gestion de bases de donnes. De cette manire, le modle de version est orthogonal au modle de donnes du SGBD. Cette caractristique nous permet dadapter notre modle de versions tout SGBD et pouvoir faire le choix par rapport aux besoins de lapplication cible.
6.2.2
Aspects spatiaux des donnes
Linformation gographique dcrit des phnomnes qui adviennent sur, au dessus, et en dessous de la surface de la terre [Sch01]. Les cartes sont un des supports de cette information. Une carte contient des objets gographiques tels que des parcelles doccupation des sols, des routes, des territoires communaux, etc., dans une rgion gographique donne. Un objet gographique a des proprits de deux types : - Une proprit spatiale reprsente par un attribut gomtrique ou encore attribut spatial. Cet attribut dcrit lemplacement dun objet dans lespace deux ou trois dimensions. - Des proprits qui dcrivent lobjet reprsentes par des attributs dits thmatiques ou descriptifs. La dnition suivante du Systme dInformation Gographique (SIG) est gnralement admise : Un systme dinformation gographique est un ensemble organis de matriels informatiques, de logiciels, de donnes gographiques et de personnel capable de saisir, stocker, mettre jour, manipuler, analyser et prsenter toutes formes dinformations gographiques rfrences. La nature des donnes stockes et exploites dans les SIGs entrane beaucoup de problmes, tant au niveau modlisation et conception quau niveau gestion au sein dun mme systme, du fait de la complexit de stockage, de consultation et de prsentation [Dbo97].
130
La diversit de ces donnes est une question critique : donnes textuelles, donnes spatiales de type vectoriel telles que les donnes gomtriques, de type matriciel ( ou rasteur) comme les donnes cartographiques, et donnes multimdia, par exemple les images satellitales et ariennes, les donnes audio et vido. Ces donnes proviennent de sources diverses et sous direntes chelles et formats de stockage ou dchange. La reprsentation des donnes dans les SIGs : Tous les SIGs utilisent trois primitives, le point, la ligne, et la rgion pour construire la gomtrie dun objet. Deux choix sont faire pour reprsenter cette gomtrie [Sch01] : 1. Quelle primitive utiliser (point, ligne ou rgion) ? 2. Quel mode rasteur ou vecteur dans chacun des cas ? La description dun terrain partir de donnes de source satellitaire ou provenant dimages ariennes est faite dans un mode reprsentation discrte appel rasteur, au moyen dune grille : le plan est soit divis en un nombre ni de points soit dcompos en un nombre ni de cellules rgulires. Une ligne ou une rgion peut tre reprsente en mode rasteur par des cellules connexes. Plus la rsolution de la grille est grande, meilleure est lapproximation obtenue. La plupart des systmes actuels utilisent le mode vecteur : les points sont reprsents par leurs coordonnes, les lignes sont reprsentes par des segments de droite qui sont des approximations linaires par morceaux, aussi appeles polylignes. Quant aux rgions elles sont reprsentes par une approximation polygonale de leur frontire. La gure 6.1 montre les deux modes pour reprsenter la gomtrie dun objet. Aujourdhui lutilisation des SIGs et des techniques de cartographie dans le domaine de la sant en Sant Publique se dveloppe rapidement. Les ressources de Sant Publique, les maladies spciques et les vnements sanitaires peuvent tre reprsents et cartographis en fonction de leur environnement et de lexistence dinfrastructures sanitaires et sociales. De telles informations, quand elles sont cartographis ensemble, crent un outil puissant pour grer et contrler les priorits en matire de Sant Publique. Le SIG fournit un sens excellent de lanalyse de donnes pidmiologiques et programmes, rvlant les tendances, les dpendances et les corrlations, ce qui est plus dicile mettre en valeur lorsque ces donnes sont sous forme de tableau. Finalement, il est intressant de faire un couplage entre larchitecture conue pour ADELEM et un SIG. Pour faire cela, nous pouvons utiliser le logiciel HealthMapper, ceci nous permettra dacher les donnes slectionnes au travers de leur
6.2 Perspectives
131
Fig. 6.1 Reprsentation du mode vecteur et rasteur reprsentation cartographique.
6.2.3
Construction et rafrachissement de donnes
Le processus dextraction-intgration est fondamental dans la conception dun entrept de donnes, car les donnes fournies seront stockes lintrieur de lentrept. Pour cela, nous pensons quil est intressant de prendre en compte le dveloppement de ce processus, due au fait que nous pouvons mesurer la qualit de lentrept par le biais de la qualit de ses donnes. La principale problmatique est le suivi des changements dans les sources de donnes et leur propagation vers lentrept pour le mettre jour. Ce processus requiert une transaction de maintenance. Dans les entrepts de donnes, une problmatique trs importante est la faon dexcuter les transactions de maintenance sans perturber les requtes des utilisateurs. La gure 6.2 montre larchitecture propose pour le projet WHIPS lUniversit de Stanford [HGMW+ 95, Wid95]. Adaptateur/Moniteur : Il est associ chaque source de donnes et il a deux fonctionnes : transformer le schma et ses instances en une reprsentation intermdiaire et dtecter automatiquement les changements dans la source pour les propager vers lintgrateur. Intgrateur : Il est responsable de la rception des reprsentations intermdiaires des donnes sources, en provenance des adaptateurs, et de lintgration de celles-ci. Lintgration entrane aussi une phase de transformation, celle-ci consiste les prparer (mise en correspondance des formats de donnes), les nettoyer, les ltrer,..., pour les rendre conforme au schma de lentrept et aux critres de qualit choisis.
132
Entrept de donnes
Intgrateur
Adaptateur/ Moniteur
Source
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 donnes, dont lactivit de lintgrateur peut tre spcique. Ainsi, il est important de proposer le dveloppement de techniques et doutils pour la gnration automatique dadaptateurs/moniteurs et dintgrateurs partir de spcications dclaratives [Ben02].
6.2.4
Grille de donnes
La dernire perspective que nous envisagions est la technologie de la Grille. Elle vise fournir une infrastructure globale qui permet un partage de ressources coordonnes, exibles, distribues et scurises [Hea05]. Par exemple, dans le milieu mdical [Med05], la Grille ore : - La puissance de calcul pour des algorithmes complexes. - Une infrastructure distribue qui permet le partage de ressources aux dirents participants mdicaux ayant des besoins similaires de traitement de donnes. - Une architecture commune pour laccs des donnes htrognes. - La possibilit de grer dnormes bases de donnes (par exemple, pour des tudes pidmiologiques).
6.2 Perspectives
133
En raison de la nature sensible de donnes mdicales, il est important de prendre en compte des problmes propres leur condentialit, tels que : authentication des utilisateurs, spcication de leurs droits daccs, cryptage ou suppression des donnes relatives au patient pour la transmission sur le rseau, ... De cette manire, nous pouvons crer un vaste rseau dans lequel il sera possible de questionner un systme de donnes ayant une vue globale sur toute cette infrastructure.
Le datawarehouse nest quune toile de plus dans le rmament des technologies [Gog04].
134
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. Ulf Asklund, Lars Bendix, Henrik Baerbak Christensen, and Boris Magnusson. The Unied Extensional Versioning Model. In System Conguration Management, pages 100122, 1999. M. Adiba. Entrepts de donnes et fouille de donnes, Introduction, Supports de cours, 2002. Rakesh Agrawal, A. Gupta, and Sunita Sarawagi. Modeling Multidimensional Databases. In Alex Gray and Per-ke Larson, editors, Proc. 13th Int. Conf. Data Engineering, ICDE, pages 232243. IEEE Computer Society, 711 1997. Michel E. Adiba and N. Bui Quang. Historical Multi-Media Databases. In VLDB 86 : Proceedings of the Twelfth International Conference on Very Large Data Bases, pages 6370. Morgan Kaufmann Publishers Inc., 1986. X. Baril and Z. Bellahsne. Selection of Materialized Views : A CostBased Approach. In CAiSE, pages 665680, Bethesda, Maryland, USA, 2003. J. Eder and M. Missiko. E. Benitez, C. Collet, and M. Adiba. Entrepts de donnes : caractristiques et problmatique. Revue TSI, 20(2), 2001. A. Belot. Dveloppement dun logiciel de cartographie de lore et de la demande de soins hospitaliers en france. Technical report, 2002. E. Benitez. Infrastructure adaptable pour lvolution des entrepts de donnes. PhD thesis, Universit Joseph Fourier, Grenoble, France, Septembre 2002. Philip Bernstein. Applying Model Management to Classical Meta Data Problems. In CIDR Conference on Innovative Data Systems Research, 2003. Bloor Research - http ://www.bloor-research.com/, 1999. Elena Baralis, Stefano Paraboschi, and Ernest Teniente. Materialized Views Selection in a Multidimensional Database. The VLDB Journal, pages 156165, 1997. 135
[ABCM99]
[Adi02] [AGS97]
[AQ86]
[BB03]
[BCA01] [Bel02] [Ben02]
[Ber03]
[Blo99] [BPT97]
136 [BSH98]
Conclusions et perspectives J.W. Buzydlowski, I-Y. Song, and L. Hassell. A Framework for ObjectOriented On-Line Analytic Processing. In ACM First International Workshop on Data Warehousing and OLAP, Bethesda, Maryland, USA, November 1998. Surajit Chaudhuri and Umeshwar Dayal. An overview of data warehousing and OLAP technology. SIGMOD Record, 26(1) :6574, 1997. W. Cellary, S. Gangarski, G. Jomier, and M. Manouvrier. Les versions, Chapitre 8 du livre : Bases de Donnes et Internet, Modles, langages et systmes. Editions Herms, 2001. D. Coadic, F. Hertout, Y. Julien, and C. Murgale. PFE : Mthodologie dAnalyse Dcisionnelle. EISTI, 2002. Rada Chirkova, Alon Y. Halevy, and Dan Suciu. A formal perspective on the view selection problem. The VLDB Journal, 11(3) :216237, 2002. 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. E.F. Codd. Providing OLAP (On-Line Analytical Processing) to useranalystes : an IT mandate. Technical report, 1993. Luca Cabibbo and Riccardo Torlone. Querying Multidimensional Databases. In Workshop on Database Programming Languages, pages 319335, 1997. L. Cabibbo and R. Torlone. A Logical Approach to Multidimensional Databases. In EDBT 98 : Proceedings of the 6th International Conference on Extending Database Technology, pages 183197. SpringerVerlag, 1998. R. Conradi and B. Westfechtel. Version Models for Software Conguration Management. ACM Computing Surveys, 30(2) :232282, June 1998. DB2 OLAP Server http 306.ibm.com/software/data/db2/db2olap/, 2004. ://www-
[CD97] [CGJM01]
[CHJM02] [CHS02]
[CLF99]
[Cod93] [CT97]
[CT98]
[CW98]
[DB204] [Dbo97]
Mohamed Dbouk. HyperGo : Conception et ralisation dun Systme dInformation Gographique Hypermdia. PhD thesis, Universit Paris XI Orsay, Paris, France, Janvier 1997. A. Doucet and S. Gangarski. Entrepts de donnes et Bases de Donnes Multidimensionnelles, Chapitre 12 du livre : Bases de Donnes et Internet, Modles, langages et systmes. Editions Herms, 2001. 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.
[DG01]
[DGS95]
6.2 Perspectives [DGW+ 98]
137
[DSBH99]
[Dum00]
[EJWG03]
[Evo97] [FGM00]
[Fra97] [GBLP95]
[GM95]
[GM99]
[GM00] [GM02]
[GMS00]
Curtis Dyreson, Fabio Grandi, Wolfgang, Nick Kline, Nikos Lorentzos, Yannis Mitsopoulos, Angelo Montanari, Daniel Nonen, Elisa Peressi, Barbara Pernici, John F. Roddick, Nandlal L. Sarda, Maria Rita Scalas, Arie Segev, Richard T. Snodgrass, Mike D. Soo, Abdullah Tansel, Paolo Tiberio, and Gio Wiederhold. A consensus glossary of temporal database concepts. SIGMOD Rec., 23(1) :5264, 1998. B. Dinter, C. Sapia, M. Blaschka, and G. Hing. OLAP Market and Research : Initiating the Cooperation. Computer Science and Information Management, 2(3), 1999. M. Dumas. TEMPOS : une plate-forme pour le dveloppement dapplications temporelles au dessus de SGBD objets. PhD thesis, Universit Joseph Fourier, Grenoble, France, Juin 2000. Jr. E. James Whitehead and Dorrit Gordon. Uniform Comparison of Conguration Management Data Models. In Software Conguration Management, pages 7085, 2003. Projet Evolution - http ://www.prism.uvsq.fr/recherche/themes/ anciens/teams/dataware/coop/evolution.html, 1997. E. Franconi, F. Grandi, and F. Mandreoli. Schema Evolution and Versioning : a Logical and Computational Characterisation. In 9th Intl. Workshop on Foundations of Models and Languages for Data and Objects : Database schema evolution and meta-modeling (DEMM00), September 2000. J-M Franco. Le Data Warehouse (Le Data Mining). Editions Eyrolles, Paris, 1997. J. Gray, A. Bosworth, A. Layman, and H. Pirahesh. Data Cube : A Relational Aggregation Operator Generalizing Group-By, Cross-Tab and Sub-Totals. Technical Report Microsoft Technical Report No. MSR-TR-95-22., 1995. A. Gupta and I. Mumick. Maintenance of Materialized Views : Problems, Techniques and Applications. IEEE Quarterly Bulletin on Data Engineering ; Special Issue on Materialized Views and Data Warehousing, 18(2) :318, 1995. Fabio Grandi and Federica Mandreoli. ODMG Language Extensions for Generalised Schema Versioning Support. In ER Workshops, pages 3647, 1999. A. Gutirrez and A. Marotta. An Overview of Data Warehouse Design Approaches. 2000. Fabio Grandi and Federica Mandreoli. A Formal Model for Temporal Schema Versioning in Object-Oriented Databases. Technical report, 2002. Fabio Grandi, Federica Mandreoli, and Maria Rita Scalas. A Generalized Modeling Framework for Schema Versioning Support. In Australasian Database Conference, pages 3340, 2000.
138 [Gog04] [Gup97] [Hea05]

+
Conclusions et perspectives Jean-Franois Goglin. Le datawarehouse, pivot de la relation client. Herms Science, 2004. Himanshu Gupta. Selection of Views to Materialize in a Data Warehouse. In ICDT, pages 98112, 1997. 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. 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. P. Howard. Database Performance, IBM, Oracle and Microsoft, une valuation. Bloor Research, Novembre 2003. 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. V. Harinarayan, A. Rajaraman, and J. Ullman. Implementing Data Cubes Eciently. In SIGMOD. ACM 0-89791-7944/96/0006, pages 205216, 1996. W. Inmon and R.D. Hackathorn. Using the Data Warehouse. 1994. Informix Metacube - http ://publib.boulder.ibm.com/epubs/pdf/ ct1s9na.pdf, 2002. William Inmon. Building the Data Warehouse. QED Technical Publishing Group, Wellesley, Massachusetts, U.S.A., 1992, 1992. William Inmon. What is a Data Warehouse, White paper., 1995. Institut National de la Statistique et des Etudes Economiques, France - http ://www.insee.fr/fr/home/home_page.asp, 2005. 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. H. Jagadish, L. Lakshmanan, and D. Srivastava. What can Hierarchies do for Data Warehouses ? In The VLDB Journal, pages 530541, 1999. 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.
[HMV99b]
[How03] [HRU95]
[HRU96]
[IH94] [Inf02] [Inm92] [Inm95] [INS05] [JJQV99]
[JLS99] [JQJ98]
6.2 Perspectives [JV97] [KC88]
139
M. Jarke and Y. Vassiliou. Data Warehouse Quality : A Review of the DWQ Project. Technical report, 1997. Won Kim and Hong-Tai Chou. Versions of Schema for ObjectOriented Databases. In Proceedings of the Fourteenth International Conference on Very Large Data Bases, pages 148159. Morgan Kaufmann Publishers Inc., 1988. Heum-Geun Kang and Chin-Wan Chung. Exploiting Versions for Online Data Warehouse Maintenance in MOLAP Servers. In Proceedings of the 28th VLDB Conference, 2002. R. Kimball. Entrepts de donnes, Guide pratique du concepteur de data warehouse. John Wiley and Sons, Inc., 1996. Sachin Kulkarni and Mukesh K. Mohania. Concurrent Maintenance of Views Using Multiple Versions. In International Database Engineering and Application Symposium, pages 254259, 1999. Panos Kalnis, Nikos Mamoulis, and Dimitris Papadias. View selection using randomized search. Data Knowl. Eng., 42(1) :89111, 2002. Yannis Kotidis and Nick Roussopoulos. DynaMat : a dynamic view management system for data warehouses. In SIGMOD 99 : Proceedings of the 1999 ACM SIGMOD international conference on Management of data, pages 371382. ACM Press, 1999. R. Kimball and M. Ross. Entrepts de donnes, Guide pratique de modlisation dimensionnelle. Vuibert, Paris, 2003. Ralph Kimball and Kevin Strehlo. Why Decision Support Fails and How To Fix It. SIGMOD Record, 24(3) :9297, 1995. 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. Sven-Eric Lautemann. An Introduction to Schema Versioning in OODBMS. In Database and Expert Systems Applications, pages 132 139, 1996. A. Levy, A. Mendelzon, Y. Sagiv, and D. Srivastava. Answering Queries Using Views. In Proceedings of the 14th ACM SIGACT-SIGMODSIGART Symposium on Principles of Database Systems, pages 95 104, San Jose, Calif., 1995. Chang Li and Xiaoyang Sean Wang. A Data Model for Supporting On-Line Analytical Processing. In CIKM, pages 8188, 1996. W. Labio, Y. Zhuge, J. Wiener, H. Gupta, H. Garcia-Molina, and J. Widom. The WHIPS prototype for data warehouse creation and maintenance. In In Proceedings ACM SIGMOD International Conference on Management of Data, pages 557559, May 1997.
[KC02]
[Kim96] [KM99]
[KMP02] [KR99]
[KR03] [KS95] [KU95]
[Lau96]
[LMSS95]
[LW96] [LZW+ 97]
140 [Mar98]
Conclusions et perspectives P. Marcel. Manipulations de Donnes Multidimensionnelles et Langages de Rgles. PhD thesis, Institut National des Sciences Appliques de Lyon, France, 1998. Renata Matos, Adriana Bueno, Anelise Jantsch, Nina Edelweiss, and Clesio Saraiva. Dynamic Schema Evolution Management Using Version in Temporal Object-Oriented Databases. In Database and Expert Systems Applications, pages 524533, 2002. Viviane Pereira Moreira and Nina Edelweiss. Queries to Temporal Databases Supporting Schema Versioning, 1997. Aci project MEDIGRID : medical data storage and processing on the GRID - http ://www.creatis.insa-lyon.fr/medigrid/, 2005. Inderpal Singh Mumick, Dallan Quass, and Barinderpal Singh Mumick. Maintenance of data cubes and summary tables in a warehouse. In SIGMOD 97 : Proceedings of the 1997 ACM SIGMOD international conference on Management of data, pages 100111. ACM Press, 1997. E. McKenzie and Richard Thomas Snodgrass. Schema evolution and the relational algebra. Inf. Syst., 15(2) :207232, 1990. Simon Monk and Ian Sommerville. Schema evolution in OODBs using class versioning. SIGMOD Rec., 22(3) :1622, 1993. B. P. Munch. Versioning in a Software Database - The Change Oriented Way. PhD thesis, Norwegian Institute of Technologie, 1993. Erik Odberg. A Framework for Managing Schema Versioning in Object-Oriented databases. In DEXA, pages 115120, 1992. The OLAP Report - http ://www.olapreport.com/fasmi.htm, 2004. Oracle Express Server - http ://otn.oracle.com/documentation /express_server.html, 1996. J. Poole, D. Chang, D. Tolbert, and D. Mellor. Common Warehouse Metamodel, An Introduction to the Standard for Data Warehouse Integration. Wiley Publishing, Inc., 2002. J. Poole, D. Chang, D. Tolbert, and D. Mellor. Common Warehouse Metamodel, Developers Guide. Wiley Publishing, Inc., 2003. Programme de Mdicalisation des Systmes dInformation http ://www.atih.sante.fr/, 2004. Christoph Quix. Repository Support for Data Warehouse Evolution. In DMDW, page 4, 1999. Dallan Quass and Jennifer Widom. On-line warehouse view maintenance. In Proceedings of the 1997 ACM SIGMOD international conference on Management of data, pages 393404. ACM Press, 1997. John F. Roddick, Fabio Grandi, Federica Mandreoli, and Maria Rita Scalas. Beyond Schema Versioning : A Flexible Model for SpatioTemporal Schema Selection. Geoinformatica, 5(1) :3350, 2001.
[MBJ+ 02]
[ME97] [Med05] [MQM97]
[MS90] [MS93] [Mun93] [Odb92] [Ola04] [ORA96] [PCTM02]
[PCTM03] [PMS04] [Qui99] [QW97]
[RGMS01]
6.2 Perspectives [RKZ+ 99]
141
E. A. Rundensteiner, A. Koeller, X. Zhang, A. J. Lee, A. Nica, A. Van Wyk, and Y. Lee. Evolvable view environment (EVE) : non-equivalent view maintenance under schema changes. In SIGMOD 99 : Proceedings of the 1999 ACM SIGMOD international conference on Management of data, pages 553555. ACM Press, 1999. Elke A. Rundensteiner, Andreas Koeller, and Xin Zhang. Maintaining data warehouses over changing information sources. Commun. ACM, 43(6) :5762, 2000. John F. Roddick. Schema evolution in database systems : an annotated bibliography. SIGMOD Rec., 21(4) :3540, 1992. John F. Roddick. A survey of schema versioning issues for database systems. Information and Software Technology, 37(7) :383393, 1995. Young-Gook Ra and Elke A. Rundensteiner. A Transparent SchemaEvolution System Based on Object-Oriented View Technology. IEEE Transactions on Knowledge and Data Engineering, 9(4) :600624, 1997. Maria-Trinidad Serna and Michel Adiba. Los Almacenes de Datos como soporte a la decisin mdica. In Proceedings of the Congreso Internacional en Ciencias Computacionales(CICC04), Colima, Mxico, Mars 2004. 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. 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. SAS OLAP Server - http ://www.sas.com/technologies/dw/storage/ mddb/, 2004. Ulrike Sattler. Data Warehouse Models and OLAP Operations http ://www.cs.man.ac.uk/ sattler/teaching/cs636.html, 2003. Michel School. Bases de donnes gographiques, volume Chapitre 6. Editions Herms, 2001. Divesh Srivastava, Shaul Dar, H. V. Jagadish, and Alon Y. Levy. Answering Queries with Aggregation Using Views. In VLDB 96 : Proceedings of the 22th International Conference on Very Large Data Bases, pages 318329. Morgan Kaufmann Publishers Inc., 1996. Sunil Samtani, Mukesh K. Mohania, Vijay Kumar, and Yahiko Kambayashi. Recent Advances and Research Problems in Data Warehousing. In ER Workshops, pages 8192, 1998. Site du Ministre des Solidarits de la Sant et de la Famille http ://www.sante.gouv.fr/, 2004.
[RKZ00]
[Rod92] [Rod95] [RR97]
[SA04]
[SA05a]
[SA05b]
[SAS04] [Sat03] [Sch01] [SDJL96]
[SMKK98]
[SMS04]
142 [Sno95] [Sno99] [Tes00]
Conclusions et perspectives Richard T. Snodgrass. The TSQL2 Temporal Query Language. Kluwer Academic Publishers, 1995. Richard T. Snodgrass. Developing Time-Oriented Database Applications in SQL. Morgan Kaufmann, 1999. O. Teste. Modlisation et manipulation dentrepts de donnes complexes et historises. PhD thesis, Universit Paul Sabatier de Toulouse, Dcembre 2000. Markus Tresch and Marc H. Scholl. Schema transformation without database reorganization. SIGMOD Rec., 22(1) :2127, 1993. D. Theodoratos and T. Sellis. Dynamic Data Warehouse Design. In Data Warehousing and Knowledge Discovery, pages 110, 1999. Michael Teschke and Achim Ulbrich. Concurrent Warehouse Maintenance Without Compromising Session Consistency. In Database and Expert Systems Applications, pages 776785, 1998. G. Vargas. Service dvenements exible pour lintgration dapplications bases de donnes rparties. PhD thesis, Universit Joseph Fourier, Grenoble, France, Dcembre 2000. Panos Vassiliadis. Modeling Multidimensional Databases, Cubes and Cube Operations. In SSDBM 98 : Proceedings of the 10th International Conference on Scientic and Statistical Database Management, pages 5362. IEEE Computer Society, 1998. A. Vavouras, S. Gatziu, and K. Dittrich. Modeling and Executing the Data Warehouse Refreshment Process. Technical Report i-2000.01, 11, 2000. Panos Vassiliadis, Christoph Quix, Yannis Vassiliou, and Matthias Jarke. A Model for Data Warehouse Operational Processes. In Conference on Advanced Information Systems Engineering, pages 446461, 2000. Panos Vassiliadis and Timos K. Sellis. A Survey of Logical Models for OLAP Databases. SIGMOD Record, 28(4) :6469, 1999. M-C Wu and A.P. Buchmann. Research Issues in Data Warehousing. In BTW German Database Conference, 1997. 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. Bernhard Westfechtel, Bjorn P. Munch, and Reidar Conradi. A Layered Architecture for Uniform Version Management. Software Engineering, 27(12) :11111133, 2001. J. Yang, K. Karlapalem, and Q. Li. Algorithms for Materialized View Design in Data Warehousing Environment. In The VLDB Journal, pages 136145, 1997.
[TS93] [TS99] [TU98]
[Var00]
[Vas98]
[VGD00]
[VQVJ00]
[VS99] [WB97] [Wid95]
[WMC01]
[YKL97]
6.2 Perspectives [YW00]
143
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. Xin Zhang and Elke A. Rundensteiner. Data Warehouse Maintenance Under Concurrent Schema and Data Updates. Technical report, 1998. Thomas Zurek and Markus Sinnwell. Datawarehousing Has More Colours Than Just Black & White. In VLDB 99 : Proceedings of the 25th International Conference on Very Large Data Bases, pages 726729. Morgan Kaufmann Publishers Inc., 1999. C. Zhang, X. Yao, and J. Yang. An evolutionary approach to materialized view selection in a data warehouse environment. IEEE Trans. Systems, Man, Cybernetics, PART C, 31 :282294, September 2001.
[ZR98] [ZS99]
[ZYY01]
144
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 transformation des RSS. La production des RSA est automatise. A partir du chier de RSS groups, le mdecin responsable du DIM utilise le logiciel GENRSA (Gnrateur de RSA), proprit de lEtat, pour produire le chier de RSA. A la dirence du RSS, le RSA constitue toujours un enregistrement unique par sjour. Description des variables du 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 systmatiquement 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 lalgorithme suivant : si un seul RUM comporte un acte classant opratoire, le DP de ce RUM est celui du RSS ; si aucun RUM ne mentionne dacte classant opratoire ou, si plusieurs RUM en mentionnent (au moins) un, le DP du RSS est celui du RUM dont la dure de sjour est la plus longue ; si deux RUM possdent la mme dure de sjour, le DP du RSS est celui du RUM de la dernire unit chronologiquement frquente. Codage du mode dentre Le mode dentre dans lunit mdicale se code comme suit : 6 : mutation La mutation signie la provenance dune autre unit mdicale de la mme entit juridique. 7 : transfert normal Le transfert normal signie la provenance dune autre entit juridique pour une hospitalisation part entire, distinguer du cas de la prestation ralise pour le compte de ltablissement dorigine, cod 0. 8 : domicile Le patient vient de chez lui. 0 : transfert pour ou aprs ralisation dun acte Ce type particulier de transfert est rserv deux cas : Un tablissement "prestataire" reoit un patient pour une dure de moins de 48 heures dans le seul but de raliser un acte que ltablissement dorigine ne peut pas raliser lui-mme. Cette "prestation" donnera dailleurs lieu une facturation ltablissement dorigine. Un tablissement "donneur dordre" rcupre un patient quil avait transfr pour la ralisation dun acte quil ne pouvait raliser lui-mme. Il sagit donc de la n de la prestation. Codage du mode de sortie Le mode dentre dans lunit mdicale se code comme suit :
147 6 : mutation La mutation signie le dpart vers une autre unit mdicale de la mme entit juridique. 7 : transfert normal Le transfert normal signie le dpart vers une autre entit juridique, distinguer du cas dun retour ltablissement dorigine aprs la ralisation dune prestation, cod 0. 8 : domicile Le patient rentre chez lui. 9 : dcs Le patient est dcd dans lunit mdicale. 0 : transfert pour ou aprs ralisation dun acte Ce type particulier de transfert est rserv deux cas : Un tablissement "prestataire" retourne le patient dans son tablissement dorigine aprs lavoir accueilli pour une dure de moins de 48 heures dans le seul but de raliser un acte qui ne pouvait pas tre ralis sur place. Il facture dailleurs cette "prestation" ltablissement dorigine. Un tablissement "donneur dordre" envoie un patient dans un autre tablissement pour la ralisation dun acte quil ne peut raliser lui-mme. Liste Alphabtique des Variables : Les variables sont classes dans lordre alphabtique de leur code et sont dcrites dans le tableau de la manire suivante : le code le type (numrique ou caractre) la longueur le libell
Les tableaux A.1 et A.2 dcrivent les variables du chier RSA. Notation : * = Pour le priv + = Pour le public La variable Filler pour les RSA publics regroupe les champs 34, 35 et 36 des RSA des tablissements privs. Caractristiques du 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 structures publiques ou prives :
148
Variable FINESS Champ 2 Champ 3 + numRSA Champ 5 Champ 6 Champ 7 + cmd_ tab + ghm_tab + Champ 10 Champ 11 + cmd + ghm + Champ14 Champ 15 AGE_ANNEES AGE_JOURS sexe Mode_ent Provenan Mois_sor Anne_sor Mode_sor Destinat Type_sjour Nbre_rad Nbre_dia Dure_se
Type Caractre Caractre Caractre Caractre Caractre Caractre Caractre Numrique Numrique Caractre Caractre Caractre Caractre Caractre Caractre Caractre Caractre Caractre Numrique Numrique Numrique
Taille 9 3 10 3 3 9 9 2 3 3 1 1 1 2 4 1 1 1 2 2 3
Libell Numro FINESS de lentit juridique N de version du format du RSA (C05) Clef de validation Numro de version du format du "RSS-group" (ou du RSS) lu N de version de Genrsa Groupage lu sur le "RSS-group" : V, CMD, GHM, code retour Groupage obtenu par GENRSA : V, CMD, GHM, code retour Nombre de RUM composant le RSS dorigine Age en annes Age en jours (si < 1 an) calcul lentre Sexe Mode dentre dans le champ du PMSI Provenance (si le mode dentre est mutation ou transfert) Mois de sortie du champ PMSI Anne de sortie du champ PMSI Mode de sortie du champ PMSI Destination (si le mode de sortie est mutation ou transfert) Type de sjour Nombre dactes de radiothrapie Nombre dactes de dialyse Dure totale du sjour dans le champ du PMSI (vide si sances)
Tab. A.1 Description des variables du chier RSA
149 Variable Champ 29 Code_geo Poids Nbre_sea Igs2 Filler Champ 34 Champ 35 Champ 36 Diag_pri Diag_rel Nbre_di1 Nbre_act Type Caractre Caractre Numrique Numrique Caractre Caractre Caractre Caractre Caractre Caractre Caractre Numrique Numrique Taille 3 5 4 2 3 8 1 1 6 6 6 2 2 Libell Dure de la priode sur laquelle stalent les sances (si sances) Code gographique de rsidence Poids la naissance (en grammes) Nombre de sances IGS 2 Filler + Code de prise en charge * Facture associe 0 franc * Zone rserve * Diagnostic principal (DP) Diagnostic reli (DR) Nombre de diagnostics associs (Nd) dans ce RSA Nombre dactes (Na) dans ce RSA
Tab. A.2 Description de variables du chier RSA Les structures sanitaires : structures hospitalires, autres centres de soins, laboratoires et pharmacies. Les structures sociales : personnes ges, jeunesse handicape, adultes handicaps, aide sociale lenfance, adultes en dicult sociale. Les structures de formation des personnels sanitaires et sociaux. Mise jour : Les mises jour de ce chier sont faites annuellement par la DRASS (Direction Rgionale des Aaires Sanitaires et Sociales) et la DDASS (Direction Dpartementale des Aaires Sanitaires et Sociales). La source de donnes : Les donnes proviennent du site Internet du ministre de la sant : http ://www. sante.gouv.fr. Le chier national des tablissements sanitaires et sociaux (FINESS) est gr par la Direction de la Recherche, des Etudes de lEvaluation et des Statistiques (DREES) - Unit Rpertoires - Ministre de lEmploi et de la Solidarit, en liaison avec les services dconcentrs de lEtat (DDASS, DRASS). Description des variables du chier : Fichier FINESS : Fichier National des Etablissements Sanitaires et Sociaux.
150
Une entit juridique : Correspond la notion de personne morale. Une personne morale exerce son activit dans des tablissements. Elle reprsente juridiquement lensemble de ses tablissements. Un tablissement : Correspond une implantation gographique. De plus, quand dans un mme lieu, plusieurs activits dpendent de budgets distincts, on identie autant dtablissements dans le mme lieu que de budgets distincts. Exemple : un Centre hospitalier rgional C.H.R (entit juridique) peut avoir plusieurs implantations gographiques et dans certaines de ses implantations avoir un service de soins de longue dure qui dpend dun budget annexe. Il y aura dans FINESS autant dtablissements que dimplantations gographiques et de services dpendant dun budget annexe. Une association (entit juridique) grant sur un mme lieu un C.A.T. et un foyer dhbergement aura, dans FINESS, 2 tablissements la mme adresse puisque ces 2 structures ont rglementairement des budgets spars. Le numro FINESS : A chaque tablissement et chaque entit juridique est attribu un numro FINESS 9 chires dont les 2 premiers correspondent au numro de dpartement dimplantation. Ce numro est un numro de rfrence en particulier pour la facturation hospitalire et la liquidation de scurit sociale. Rien ne distingue, dans la constitution du numro, un numro dentit juridique dun numro dtablissement. Le type dtablissement : Les tablissements sont caractriss dans FINESS par leur catgorie et les disciplines quils sont autoriss exercer. Ces informations sont la traduction dune rglementation complexe et de la possibilit de pluridisciplinarit des tablissements sanitaires. Exemple : un tablissement dun C.H.R (lieu gographique) peut la fois comprendre des services de mdecine, de chirurgie, une maternit et une cole dinrmire. Pour faciliter votre recherche, nous avons retenu une prsentation par type dtablissement qui rsulte du croisement des informations de catgorie et de disciplines. Un tablissement pourra ainsi appartenir plusieurs types en fonction de son niveau de pluridisciplinarit. La catgorie : Elle caractrise le cadre rglementaire dans lequel sexerce lactivit de ltablissement. Exemples : centre Hospitalier, Institut mdico-ducatif, centre daide par le travail. La discipline : Dsigne une activit homogne qui est fonction du type de soins ou de service social. Exemple : mdecine gnrale, pdiatrie, chirurgie, hbergement, accueil temporaire, ducation. Dans le domaine sanitaire, certaines autorisations sont faites par Grands Groupes de Disciplines GGDE qui sont des regroupements de disciplines. Dans le cadre de ce site Internet, les informations relatives ces disciplines prsentes dans le chier FINESS ne sont pas accessibles dans leur dtail. Seules apparaissent sur la che des tablissements concerns les GGDE des tablissements sanitaires et les disciplines denseignement des tablissements denseignements.
151
Le statut : Caractrise la situation juridique de la personne morale dont dpend ltablissement. Exemple : tablissement dhospitalisation communal, association loi 1901 reconnue dutilit publique, SARL. La capacit : Pour les tablissements sanitaires, est ache la capacit en lits par grand groupe de discipline autorise (par un arrt) et mise en uvre (dont linstallation a t constate et certie conforme). Pour les tablissements sociaux, est ache la capacit totale observe en places par sexe. Pour les tablissements denseignement, est ach le nombre de places dune promotion par discipline denseignement. Les adresses : Pour les tablissements sanitaires et sociaux, est ache, quand elle existe, une deuxime adresse : ladresse daccueil durgence 24H sur 24 pour le public. Le tarif : Dtermine lautorit responsable de la xation du tarif principal de ltablissement et la procdure utilise. La participation au service public hospitalier : Pour les tablissements privs relevant de la loi hospitalire, il indique si ltablissement participe au service public hospitalier et sous quelle forme. Les numros SIREN et SIRET : Sont lidentiant de lentit juridique (SIREN) et celui de ltablissement (SIRET) attribu par lINSEE dans le cadre du systme national lgal didentication des entreprises et de leurs tablissements. Liste Alphabtique des Variables : Variable Adresse Adressepublic Capaciteautorisee1 Capaciteautorisee2 Capaciteautorisee3 Capaciteautorisee4 Capaciteautorisee5 Capacitemiseenoeuvre1 Capacitemiseenoeuvre2 Type Char Char Num Num Num Num Num Num Num Taille 35 25 8 8 8 8 8 8 8 Libell Adresse de ltablissement Adresse de ltablissement capacit autorise en nombre de lits capacit autorise en nombre de lits capacit autorise en nombre de lits capacit autorise en nombre de lits capacit autorise en nombre de lits capacit observe en nombre de lits capacit observe en nombre de lits
Tab. A.3 Description de variables du chier FINESS
152
Variable Capacitemiseenoeuvre3 Capacitemiseenoeuvre4 Capacitemiseenoeuvre5 Code1 Code2 Code3 Code4 Code5 CodePSPH Codecategorie Codepostal Codepostalpublic Codestatut Codetarif Compldistrpublic Complementdistribution Dateouvert FINESSjuridique Fax Faxpublic GGDE1 GGDE2 GGDE3 GGDE4 GGDE5 LibPSPH Libcategorie Libelleroutage Libstatut Libtarif LieuditBP LieuditBPpublic NumeroFINESS Raisonsociale Routagepublic SIRET Tel Telpublic
Type Num Num Num Num Num Num Num Num Num Num Num Char Num Num Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char Char
Taille 8 8 8 8 8 8 8 8 8 8 8 5 8 8 20 35 20 9 15 15 20 20 20 20 20 20 25 30 25 20 35 10 9 65 20 20 15 15
Libell capacit observe en nombre de lits capacit observe en nombre de lits capacit observe en nombre de lits Code de la discipline Code de la discipline Code de la discipline Code de la discipline Code de la discipline Code de Part. au Serv. Pub. Hosp. Code lactivit de ltab. Code postal Code postal public Code le statut de ltab. Code de lautorit xant le tarif Complment de distribution public Complment de distribution Date douverture Numro FINESS juridique Numro Fax Numro Fax public Grands Groupe de Discipline 1 Grands Groupe de Discipline 2 Grands Groupe de Discipline 3 Grands Groupe de Discipline 4 Grands Groupe de Discipline 5 Libell de Part. au Serv. Pub. Hosp. Libell de la catgorie Libelle du routage Libell du statut Libell de lautorit xant le tarif Lieudit BP Lieudit BP public Numro FINESS Nom de ltablissement Routage public Numro SIRET Numro Tlphone Numro Tlphone public
Tab. A.4 Description de variables du chier FINESS

Entrepôts de Données Pour L'aide À La Decision Medicale

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Entrepôts de Données Pour L'aide À La Decision Medicale

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSIT JOSEPH FOURIER

THSE pour obtenir le grade de Docteur de lUniversit Joseph Fourier

prsente et soutenue publiquement par

Mara Trinidad Serna Encinas

Entrepts de donnes pour laide la dcision mdicale : conception et exprimentation

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

Table des matires

Table des gures

Liste des tableaux

Les entrepts de donnes pour laide la dcision

1.2 Le projet ADELEM : Aide la Dcision Logistique et Mdicale

Fig. 1.1 Architecture gnrale dun systme dcisionnel

Le projet ADELEM : Aide la Dcision Logistique et Mdicale

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

1.2 Le projet ADELEM : Aide la Dcision Logistique et Mdicale

Fig. 1.2 Tous les tablissements au niveau national

Problmatique et objectif de la thse

Conception dun systme pour le dcisionnel

1.3 Problmatique et objectif de la thse

Slection des vues matrialiser

1.3 Problmatique et objectif de la thse

Gestion de lvolution des entrepts

Adaptation de lapplication dextraction

Adaptation des agrgats

Adaptation de lapplication danalyse

1.4 Dmarche et contribution

Algorithme pour la slection des vues matrialiser

Interface pour la gnration (semi-automatique) des indicateurs

Versions de schmas bitemporels

Chapitre 2 Entrepts de donnes multidimensionnelles et aspects temporels

Architecture dun entrept de donnes

Entrepts de donnes multidimensionnelles et aspects temporels

Donnes de production (SGBD, systmes lgus)

Donnes anciennes archives

Fig. 2.1 Architecture dun entrept de donnes

2.1 Entrepts de donnes

Entrepts et les bases de donnes

Entrepts de donnes multidimensionnelles et aspects temporels

Tab. 2.1 Dirences entre SGBD et entrepts de donnes

Entrepts de donnes multidimensionnelles et aspects temporels Commune Dpartement Rgion Pays

Magasin Cl_M Raison_soc Adresse Commune Dpartement Rgion Pays

Fig. 2.2 Exemple de modlisation en toile.

2.2 Modlisation multidimensionnelle 2.2.1.2 Le schma en ocon de neige (Snowake)

Entrepts de donnes multidimensionnelles et aspects temporels Le schma en constellation

Ventes Cl_P Cl_M Cl_T Quantit

Temps Cl_T Jour Mois Anne

Achats Cl_P Cl_F Cl_T Quantit

Fournisseur Cl_F Raison_soc Adresse Code_postal Commune Pays

Schma multidimensionnel (Cube)

2.3 Manipulation des donnes multidimensionnelles

TV Lyon Grenoble Annecy SUM

Hirarchies des dimensions

Manipulation des donnes multidimensionnelles

Entrepts de donnes multidimensionnelles et aspects temporels

Tab. 2.4 Prix des produits

Oprations agissant sur la structure

2.3 Manipulation des donnes multidimensionnelles

Tab. 2.7 Ventes du Dpartement Isre

Entrepts de donnes multidimensionnelles et aspects temporels

2.4 Serveurs OLAP (On-Line Analytical Processing)

Oprations agissant sur la granularit

Serveurs OLAP (On-Line Analytical Processing)

Entrepts de donnes multidimensionnelles et aspects temporels