These - Conception et réalisation d’un Data Warehouse pour la mise en place d’un système décisionnel

Entrepots de donnees pour laide a` la decision medicale:

conception et experimentation

Serna Encinas Mara Trinidad

To cite this version:

Serna Encinas Mara Trinidad. Entrepots de donnees pour laide a` la decision medicale: con-ception et experimentation. Networking and Internet Architecture. Universite Joseph-Fourier- Grenoble I, 2005. French.

HAL Id: tel-00184256

https://tel.archives-ouvertes.fr/tel-00184256

Submitted on 30 Oct 2007

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.

Larchive ouverte pluridisciplinaire HAL, estdestinee au depot et a` la diffusion de documentsscientifiques de niveau recherche, publies ou non,emanant des etablissements denseignement et derecherche francais ou etrangers, des laboratoirespublics ou prives.

UNIVERSIT JOSEPH FOURIER

THSE

pour obtenir le grade de

Docteur de lUniversit Joseph Fourier

Spcialit : Informatique

prpare au laboratoire LSR IMAGdans le cadre de lcole Doctorale

Mathmatiques, Sciences et Technologies de lInformation

prsente et soutenue publiquement par

Mara Trinidad Serna Encinas

Le 27 Juin 2005

Entrepts de donnes pour laide la

dcision mdicale :

conception et exprimentation

Composition du jury

Mme. Christine Collet, Prsident

Mme. Anne Doucet, Rapporteur

M. Mokrane Bouzeghoub, Rapporteur

M. Jacques Demongeot, Examinateur

M. Ren Ecochard, Examinateur

M. Michel Adiba, Directeur de thse

Remerciements

Je tiens remercier Anne Doucet, professeur lUniversit Pierre et Marie Cu-rie de Paris (LIP6), et Mokrane Bouzeghoub, professeur lUniversit de Versailles(PRiSM), pour avoir accept dtre rapporteur et pour leurs commentaires et cri-tiques constructives qui mont apport un regard clairant sur les contributions decette thse. Je remercie aussi Jacques Demongeot, professeur lInstitut dIngnie-rie de lInformation de Sant de Grenoble (TIMC), et Ren Ecochard, professeur auService de Biostatistique de Lyon (LBBE), davoir accept de faire partie de monjury.

Je remercie trs sincrement Christine Collet, professeur lEcole Nationale Su-prieure dInformatique et de Mathmatiques Appliques de Grenoble (ENSIMAG)et responsable du projet NODS, pour mavoir accueilli dans son quipe et pourlhonneur quelle ma fait en prsidant le jury de thse.

Jexprime ma profonde gratitude Michel Adiba, professeur lUniversit JosephFourier de Grenoble (UJF), pour la conance quil ma toujours tmoign, ainsi quepour ses conseils, ses encouragements et sa patience. Jose dire que vous devenezmon ami.

Je remercie galement Claudia Lucia Roncancio, professeur lEcole NationaleSuprieure dInformatique et de Mathmatiques Appliques de Grenoble (ENSI-MAG), pour son aide, ses suggestions et principalement, pour son amiti.

Je tiens aussi remercier aux membres et collaborateurs de lquipe STORM,Genoveva Vargas-Solar, Cyril Labbe, Fabrice Jouanot, Christophe Bobineau, Kha-lid Belhajjame, Edgar Benitez, Tran-Kien Cao, Laurent dOrazio, Levent Gurgen,Nagapraveen Jayaprakash, Thi-Huong-Giang Vu et Hanh Tan, pour la disponibilitquils 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, JulioMoreno, Irma Ramirez, Patricia Quintero, Norma Pacheco, Sonia Meneses, CarmenVillarreal, Daniel Prez et Francisca Lorena Zepeda, pour avoir partag cette aven-ture avec moi et mavoir toujours soutenue pendant les moments les plus dicilesde 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, pourleur amour inconditionnel et sans limites, pour leurs encouragements et pour leursconseils. Je tiens remercier spcialement Migdia, Carmen, Rosa, et Juan, qui onttoujours 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 remerciementssont 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 11.1 Les entrepts de donnes pour laide la dcision . . . . . . . . . . . 21.2 Le projet ADELEM : Aide la Dcision Logistique et Mdicale . . . 31.3 Problmatique et objectif de la thse . . . . . . . . . . . . . . . . . . 6

1.3.1 Conception dun systme pour le dcisionnel . . . . . . . . . . 61.3.2 Slection des vues matrialiser . . . . . . . . . . . . . . . . . 81.3.3 Gestion de lvolution des entrepts . . . . . . . . . . . . . . . 91.3.4 Objectif de la thse . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4 Dmarche et contribution . . . . . . . . . . . . . . . . . . . . . . . . 101.4.1 Mtamodle multidimensionnel . . . . . . . . . . . . . . . . . 101.4.2 Algorithme pour la slection des vues matrialiser . . . . . . 111.4.3 Interface pour la gnration (semi-automatique) des indicateurs 111.4.4 Versions de schmas bitemporels . . . . . . . . . . . . . . . . . 11

1.5 Plan de la thse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Entrepts de donnes multidimensionnelles et aspects temporels 152.1 Entrepts de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.1 Architecture dun entrept de donnes . . . . . . . . . . . . . 152.1.2 Entrepts et les bases de donnes . . . . . . . . . . . . . . . . 17

2.2 Modlisation multidimensionnelle . . . . . . . . . . . . . . . . . . . . 182.2.1 Schmas relationnels . . . . . . . . . . . . . . . . . . . . . . . 202.2.2 Schma multidimensionnel (Cube) . . . . . . . . . . . . . . . . 22

2.3 Manipulation des donnes multidimensionnelles . . . . . . . . . . . . 232.3.1 Oprations classiques . . . . . . . . . . . . . . . . . . . . . . . 232.3.2 Oprations agissant sur la structure . . . . . . . . . . . . . . . 242.3.3 Oprations agissant sur la granularit . . . . . . . . . . . . . . 27

2.4 Serveurs OLAP (On-Line Analytical Processing) . . . . . . . . . . . . 272.4.1 ROLAP (Relational OLAP) . . . . . . . . . . . . . . . . . . . 282.4.2 MOLAP (Multidimensional OLAP) . . . . . . . . . . . . . . . 302.4.3 HOLAP (Hybrid OLAP) . . . . . . . . . . . . . . . . . . . . . 32

2.5 Les projets de recherche . . . . . . . . . . . . . . . . . . . . . . . . . 342.5.1 WHIPS Warehouse Information Prototype at Stanford . . . . . 342.5.2 SIRIUS Supporting the Incremental Refreshment of Informa-

tion warehouses . . . . . . . . . . . . . . . . . . . . . . . . . . 352.5.3 DWQ Foundations of Data Warehouse Quality . . . . . . . . . 35

i

ii

2.5.4 Projet EVOLUTION . . . . . . . . . . . . . . . . . . . . . . . 372.6 Aspects temporels des entrepts . . . . . . . . . . . . . . . . . . . . . 37

2.6.1 Etat courant des versions . . . . . . . . . . . . . . . . . . . . . 382.6.2 Espace de versions . . . . . . . . . . . . . . . . . . . . . . . . 432.6.3 Versions bases sur ltat et sur les changements . . . . . . . . 442.6.4 Graphes de version . . . . . . . . . . . . . . . . . . . . . . . . 452.6.5 Gestion de versions extensionnelles et intensionnelles . . . . . 462.6.6 Oprations primitives . . . . . . . . . . . . . . . . . . . . . . . 47

2.7 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3 Architecture et modle pour un entrept de donnes mdicales 493.1 Architecture dun systme dcisionnel . . . . . . . . . . . . . . . . . . 50

3.1.1 Interface graphique pour la Gnration (Semi - automatique)dIndicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.1.2 Entrept de donnes . . . . . . . . . . . . . . . . . . . . . . . 513.1.3 Gestionnaire dEvolution . . . . . . . . . . . . . . . . . . . . . 51

3.2 Mtamodle Multidimensionnel . . . . . . . . . . . . . . . . . . . . . 513.2.1 Relations entre les mtaclasses . . . . . . . . . . . . . . . . . . 523.2.2 Contraintes entre les mtaclasses . . . . . . . . . . . . . . . . 533.2.3 Description des Mtaclasses . . . . . . . . . . . . . . . . . . . 533.2.4 Dnition dun modle multidimensionnel . . . . . . . . . . . 54

3.3 Analyse des donnes dune application mdicale . . . . . . . . . . . . 593.3.1 Sources de donnes . . . . . . . . . . . . . . . . . . . . . . . . 593.3.2 Analyse des donnes . . . . . . . . . . . . . . . . . . . . . . . 61

3.4 Classication des indicateurs du projet . . . . . . . . . . . . . . . . . 623.4.1 Indicateurs dore (gographiques - spatio-temporels) . . . . . 633.4.2 Indicateurs de consommation, de besoins et de ux (temporels) 633.4.3 Nouveaux indicateurs de consommation et de ux (temporels) 64

3.5 Application du modle multidimensionnel dans le cadre du projet . . 653.5.1 Schma en constellation pour ADELEM . . . . . . . . . . . . 653.5.2 Hirarchies du schma . . . . . . . . . . . . . . . . . . . . . . 663.5.3 Description du schma Prise_MCO et de ses dimensions . . . . 673.5.4 Description du schma Population et de ses dimensions . . . . 703.5.5 Description du schma Prise_SSR et de ses dimensions . . . . 71

3.6 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4 Systme daide la dcision mdicale : une exprimentation 754.1 Construction du schma . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.1.1 Schma en toile Adelem_MCO . . . . . . . . . . . . . . . . . . . 764.1.2 Matrialisation de lHypercube . . . . . . . . . . . . . . . . . 77

4.2 Vues matrialises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.2.1 Slection des vues matrialiser . . . . . . . . . . . . . . . . . 804.2.2 Algorithme propos pour la slection des vues matrialiser . 844.2.3 Gnration des vues matrialises . . . . . . . . . . . . . . . . 88

iii

4.3 Interface graphique pour la Gnration (semi-automatique) dIndica-teurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904.3.1 Architecture pour linterface graphique . . . . . . . . . . . . . 914.3.2 Fonctionnement de linterface . . . . . . . . . . . . . . . . . . 924.3.3 Types de requtes excuter . . . . . . . . . . . . . . . . . . . 944.3.4 Fonctionnement de linterface graphique . . . . . . . . . . . . 95

4.4 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

5 Aspects temporels et versions de schmas dans les entrepts 1015.1 Versions de schmas . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

5.1.1 Versions de schmas annuels dans un contexte mdical . . . . 1025.1.2 Reprsentation bitemporelle des versions de schmas . . . . . 103

5.2 Les oprations primitives . . . . . . . . . . . . . . . . . . . . . . . . . 1055.2.1 Ensemble de primitives . . . . . . . . . . . . . . . . . . . . . . 1055.2.2 Ensemble de restrictions . . . . . . . . . . . . . . . . . . . . . 105

5.3 Dnition formelle des primitives . . . . . . . . . . . . . . . . . . . . 1075.3.1 Gestion de la relation (cube, dimension ou hirarchie) . . . . . 1085.3.2 Gestion des versions . . . . . . . . . . . . . . . . . . . . . . . 115

5.4 Gestion temporelle des entrepts . . . . . . . . . . . . . . . . . . . . 1165.4.1 Architecture simplie du projet . . . . . . . . . . . . . . . . . 1175.4.2 Modle de versions de schmas bitemporels . . . . . . . . . . . 1175.4.3 Gestionnaire dvolution de schmas . . . . . . . . . . . . . . 119

5.5 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

6 Conclusions et perspectives 1256.1 Bilan du travail ralis . . . . . . . . . . . . . . . . . . . . . . . . . . 125

6.1.1 Principales contributions . . . . . . . . . . . . . . . . . . . . . 1256.1.2 Dnition dun modle multidimensionnel . . . . . . . . . . . 1256.1.3 Algorithme pour la slection des vues matrialiser . . . . . . 1266.1.4 Gnration (semi-automatique) des requtes . . . . . . . . . . 1276.1.5 Versions de schmas bitemporels . . . . . . . . . . . . . . . . . 127

6.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1286.2.1 Extension du prototype . . . . . . . . . . . . . . . . . . . . . 1286.2.2 Aspects spatiaux des donnes . . . . . . . . . . . . . . . . . . 1296.2.3 Construction et rafrachissement de donnes . . . . . . . . . . 1316.2.4 Grille de donnes . . . . . . . . . . . . . . . . . . . . . . . . . 132

A Description des sources de donnes 145

Table des figures

1.1 Architecture gnrale dun systme dcisionnel . . . . . . . . . . . . . 31.2 Tous les tablissements au niveau national . . . . . . . . . . . . . . . 51.3 Gestion de lvolution du schma dans un entrept . . . . . . . . . . 9

2.1 Architecture dun entrept de donnes . . . . . . . . . . . . . . . . . 162.2 Exemple de modlisation en toile. . . . . . . . . . . . . . . . . . . . 202.3 Exemple de modlisation en ocon de neige. . . . . . . . . . . . . . . 212.4 Exemple de modlisation en constellation. . . . . . . . . . . . . . . . 222.5 Exemple de schma multidimensionnel. . . . . . . . . . . . . . . . . . 232.6 Exemple de lopration Jointure. . . . . . . . . . . . . . . . . . . . . . 252.7 Architecture ROLAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.8 Architecture MOLAP. . . . . . . . . . . . . . . . . . . . . . . . . . . 302.9 Architecture HOLAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.10 Espace des changements . . . . . . . . . . . . . . . . . . . . . . . . . 442.11 Graphes de version un niveau . . . . . . . . . . . . . . . . . . . . . 452.12 Graphe de version deux niveaux . . . . . . . . . . . . . . . . . . . . 46

3.1 Architecture propose dun systme dcisionnel . . . . . . . . . . . . 503.2 Mtamodle Multidimensionnel . . . . . . . . . . . . . . . . . . . . . 523.3 Schma et une instance possible du Cube . . . . . . . . . . . . . . . . 563.4 Schma et une instance possible de la hirarchie H_Geo . . . . . . . 583.5 Schma en Constellation pour ADELEM . . . . . . . . . . . . . . . . 663.6 Hirarchies de la dimension x . . . . . . . . . . . . . . . . . . . . . . 673.7 Schma en ocon de neige Prise_MCO . . . . . . . . . . . . . . . . . . 683.8 Schma en ocon de neige Population . . . . . . . . . . . . . . . . . . 703.9 Schma en ocon de neige Prise_SSR . . . . . . . . . . . . . . . . . . 71

4.1 Schma en toile Adelem_MCO . . . . . . . . . . . . . . . . . . . . . . . 764.2 Hypercube avec le cot de calcul ( gauche) et le cot de stockage (

droite) de chaque noeud (vue) . . . . . . . . . . . . . . . . . . . . . . 794.3 Algorithme Greedy [HRU95] . . . . . . . . . . . . . . . . . . . . . . . 824.4 Ensemble ordonn des vues slectionnes . . . . . . . . . . . . . . . . 834.5 Algorithme propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864.6 Ensemble ordonn des vues slectionnes . . . . . . . . . . . . . . . . 874.7 Architecture pour linterface graphique . . . . . . . . . . . . . . . . . 914.8 Cration dune dimension . . . . . . . . . . . . . . . . . . . . . . . . 93

v

vi

4.9 Structure de la dimension . . . . . . . . . . . . . . . . . . . . . . . . 944.10 Interface pour la gnration (semi-automatique) dindicateurs . . . . 964.11 Rsultat de lexcution de la requte Q4 . . . . . . . . . . . . . . . . 974.12 Fichier Requete.REL . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

5.1 Trois versions de schmas annuels. . . . . . . . . . . . . . . . . . . . . 1025.2 Reprsentation bitemporelle des versions de schmas. . . . . . . . . . 1035.3 Insertion du niveau District la Hirarchie H_Geo. . . . . . . . . . 1135.4 Rsultat dliminer le niveau Departement la Hirarchie H_Geo. . . 1145.5 Interaction des composants lintrieur de larchitecture. . . . . . . . 1175.6 Modle de versions de schmas bitemporels. . . . . . . . . . . . . . . 1185.7 Gestionnaire dvolution de schmas. . . . . . . . . . . . . . . . . . . 1205.8 Gestion dvolution de schmas par niveau. . . . . . . . . . . . . . . . 120

6.1 Reprsentation du mode vecteur et rasteur . . . . . . . . . . . . . . . 1316.2 Architecture des systmes pour lintgration de donnes . . . . . . . . 132

Liste des tableaux

2.1 Dirences entre SGBD et entrepts de donnes . . . . . . . . . . . . 182.2 Comparaison des systmes . . . . . . . . . . . . . . . . . . . . . . . . 192.3 Ventes par magasin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.4 Prix des produits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.5 Ventes de produits par ville 1 . . . . . . . . . . . . . . . . . . . . . . 252.6 Ventes de produits par ville 2 . . . . . . . . . . . . . . . . . . . . . . 252.7 Ventes du Dpartement Isre . . . . . . . . . . . . . . . . . . . . . . . 252.8 Table de ventes du Magasin 1 . . . . . . . . . . . . . . . . . . . . . . 262.9 Table de ventes du Magasin 2 . . . . . . . . . . . . . . . . . . . . . . 262.10 Table de ventes du Magasin 3 . . . . . . . . . . . . . . . . . . . . . . 262.11 Exemple de relation bitemporelle . . . . . . . . . . . . . . . . . . . . 42

3.1 Description des sources de donnes . . . . . . . . . . . . . . . . . . . 613.2 Caractristiques des sources de donnes historiques . . . . . . . . . . 62

4.1 Liste de relations de base . . . . . . . . . . . . . . . . . . . . . . . . . 774.2 Matrialisation complte de lhypercube . . . . . . . . . . . . . . . . 784.3 Application de lalgorithme Greedy aux donnes ADELEM . . . . . . 824.4 Application de notre algorithme aux donnes ADELEM . . . . . . . . 864.5 Ensemble minimal des vues matrialiser . . . . . . . . . . . . . . . 88

5.1 Primitives pour la gestion de relation . . . . . . . . . . . . . . . . . . 1065.2 Primitives pour la gestion des versions . . . . . . . . . . . . . . . . . 106

A.1 Description des variables du chier RSA . . . . . . . . . . . . . . . . 148A.2 Description de variables du chier RSA . . . . . . . . . . . . . . . . . 149A.3 Description de variables du chier FINESS . . . . . . . . . . . . . . . 151A.4 Description de variables du chier FINESS . . . . . . . . . . . . . . . 152

vii

Chapitre 1

Introduction

Les entrepts de donnes intgrent les informations en provenance de direntessources, souvent rparties et htrognes et qui ont pour objectif de fournir une vueglobale de linformation aux analystes et aux dcideurs. Ces applications daide ladcision sont de type OLAP (On-Line Analytical Processing ou Analyse en ligne).

La construction et la mise en oeuvre dun entrept de donnes reprsentent unetche complexe qui se compose de plusieurs tapes. La premire consiste lanalysedes sources de donnes et lidentication des besoins des utilisateurs. La deuximecorrespond lorganisation des donnes lintrieur de lentrept. Finalement, latroisime consiste tablir divers outils dinterrogation (danalyse, de fouille dedonnes ou dinterrogation). Chaque tape prsente des problmatiques spciques.Ainsi, par exemple, lors de la premire tape, la dicult principale consiste en lin-tgration des donnes, de manire quelles soient de qualit pour leur stockage.Pour lorganisation, ils existent plusieurs problmes comme : la slection des vues matrialiser, le rafrachissement de lentrept, la gestion de lensemble de donnes(courantes et historises), entre autres. En ce qui concerne le processus dinterroga-tion, nous avons besoin des outils performants et conviviaux pour laccs et lanalysede linformation.

Notre travail se focalise principalement sur les deux dernires tapes, ainsi, pour leprocessus dorganisation, nous proposons la dnition dun modle multidimension-nel, un algorithme pour la slection optimale des vues matrialiser et lutilisationdes versions de schmas bitemporels pour la gestion des aspects temporels des entre-pts. Pour linterrogation, nous avons dvelopp une interface graphique qui permetla gnration semi-automatique des indicateurs. Dans les chapitres suivants, nousdployons chacune de nos propositions.

Cette thse a eu pour cadre un projet mdical. Ainsi, dans ce chapitre nousprsentons dabord une introduction des entrepts dans le milieu mdical et unrsum du projet ADELEM (Aide la Dcision Logistique et Mdical). Ensuite,nous prsentons la problmatique et lobjectif de la thse et pour nir, nous exposonsla dmarche suivie et notre contribution.

1

2 Introduction

1.1 Les entrepts de donnes pour laide la dci-

sion

La dnition classique dun entrept donne par [IH94] :

"Un Entrept de Donnes est une collection de donnes orientes su-jet, intgres, non volatiles et historises, organises pour le support dunprocessus daide la dcision".

Nous dtaillons ces caractristiques [Fra97, DG01] :

orientes sujet : Les donnes des entrepts sont organises par sujet plutt quepar application. Par exemple, une chane de magasins dalimentation organise lesdonnes de son entrept par rapport aux ventes qui ont t ralises par produit etpar magasin, au cours dun certain temps.

intgres : Les donnes provenant des direntes sources doivent tre intgres,avant leur stockage dans lentrept de donnes. Lintgration (mise en correspon-dance des formats, par exemple), permet davoir une cohrence de linformation.

non volatiles : A la dirence des donnes oprationnelles, celles de lentreptsont 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 laprise de dcision qui, par exemple, utilise des techniques de prdiction en sappuyantsur les volutions passes pour prvoir les volutions futures.

La construction dun entrept revient faire correspondre les besoins des utili-sateurs avec la ralit des informations disponibles. Nous devons dabord identieret analyser les sources de donnes, ce qui nous permet de proposer les mcanismesadapts selon les caractristiques des informations. Ensuite, nous devons organi-ser lensemble de donnes lintrieur de lentrept. Pour cela, nous devons dabordstructurer ces informations en considrant leur granularit. Ceci nous permet dabou-tir la conception dun schma multidimensionnel qui permet de rpondre aux be-soins des utilisateurs.

La gure 1.1 montre une architecture gnrale dun systme dcisionnel qui secompose de trois processus : extraction-intgration, organisation et interrogation.

Nous trouvons le processus dextraction-intgration entre les sources de donneset lentrept. Ce processus est responsable de lidentication des donnes dans lesdiverses sources internes et externes ; de lextraction de linformation qui nous int-resse et de la prparation et de la transformation (nettoyage, ltrage,...) des donnes.

1.2 Le projet ADELEM : Aide la Dcision Logistique et Mdicale 3

EXTRACTION

Entrept dedonnesSources de donnes

ORGANISATION

INTERROGATION Outils

Fig. 1.1 Architecture gnrale dun systme dcisionnel

A lintrieur de lentrept, nous trouvons le processus dorganisation, il est respon-sable de structurer les donnes par rapport leur niveau de granularit (agrgats).

Finalement, le troisime processus correspond linterrogation qui se place entrelentrept et les dirents outils pour arriver lanalyse des donnes, pour les di-rents utilisateurs de lentreprise.

Malgr une conception attentive et soigneuse, la structure dune base de donnesest sujette de nombreux changements. Bien que les estimations dirent, la plupartsaccordent sur le fait que plus de 50% du travail des dveloppeurs se focalise sur lesmodications du systme aprs leur implantation [Rod95]. Ces changements peuventaecter aussi bien les donnes que leur structure. En eet, lvolution dun schmaconcerne tout le cycle de vie dun entrept de donnes. Un de premiers travaux dansce contexte est [HMV99a, HMV99b], o les auteurs proposent des oprateurs pourlvolution des dimensions.

1.2 Le projet ADELEM : Aide la Dcision Logis-

tique et Mdicale

Cette thse a eu pour cadre le projet ADELEM1 qui consiste en la mise au pointdoutils logiciels ncessaires laide la dcision logistique et mdicale, dans le cadredes SROS (Schmas dOrganisation Sanitaire et Sociale) grs par les ARH (AgencesRgionales dHospitalisation). Dans le systme de soins dune rgion, ces agencessont charges de rpartir de manire optimale les moyens mdicaux (l"ore") enfonction des besoins sanitaires (la "demande"). A partir des observations de santconstituant linformation primaire, essentiellement contenue dans les donnes PMSI(Programme de Mdicalisation du Systme dInformation des hpitaux) [PMS04], il

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

4 Introduction

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

Ce projet est trait par une quipe interdisciplinaire compose de :

- Le Laboratoire TIMC IMAG, UMR CNRS 5525.

- Le Laboratoire de Biomtrie et Biologie volutive (UMR CNRS 5558) qui four-nit lanalyse statistique des donnes mdicales.

- LOrganisation Mondiale de la Sant (bas en Suisse) qui a dvelopp le logicielHealthMapper pour la cration et la manipulation des donnes gographiques.

- Notre quipe du Laboratoire LSR IMAG, UMR CNRS 5526 qui fournit le sup-port pour les bases de donnes et les entrepts.

Objectif du projet :

La rpartition de lore de soins (nombre de lits par spcialit, plateaux tech-niques) doit sadapter rgulirement lvolution de la demande (volution des pa-thologies ncessitant une prise en charge hospitalire, de la structure dge et de lim-plantation gographique de la population), et de lore de soins (volution des tech-niques et de lorganisation du systme de sant, telles que rseau et tl-mdecine).Le projet consiste donc en la mise au point dun outil de modlisation-simulation partir des donnes du PMSI et des donnes de lINSEE (Institut National de laStatistique et des Etudes Economiques) [INS05] pour aider les gestionnaires du sys-tme de sant dans leur dmarche de prise de dcision.

Sources de donnes relles :

Nous avons trois types de sources : gographiques, dmographiques et les donnespubliques concernant la sant. Elles sont rparties, htrognes et certaines dentreelles sont externes au domaine mdical proprement dit. En ce qui concerne les don-nes gographiques, lquipe de Service de Biostatistique Lyon sest focalis surla visualisation (reprsentation cartographique) de lore et de la consommation desoins. 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 dela demande de soins hospitaliers en France. Dans cette version initiale, ils se sontintresss lore et la demande de soins, aux besoins et aux ux mais pas la com-paraison sur une mme carte de lore et de la consommation (ratios) qui ncessitede dnir un maillage gographique commun. Ainsi les reprsentations graphiquesde lore et de la demande se feront sur des fonds de cartes dirents. En eet,

1.2 Le projet ADELEM : Aide la Dcision Logistique et Mdicale 5

les renseignements sur lorigine gographique des patients pour la consommation desoin sont bass sur les codes postaux et non pas le code INSEE de la commune dersidence 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 dela correspondance entre les communes et les cantons au niveau national (chier delIntitut de Gographie National). Ainsi, dans cette version 0, la France se composede 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 decartographie). Il se base sur un gestionnaire de donnes qui permet de combinerles informations gographiques et pidmiologiques. Le nombre dindicateurs prvuspour cette version 0 est limit 2 pour la visualisation de lore et de la consomma-tion de soins. Cette version permet de reprsenter tous les tablissements de courtssjours au niveau national ainsi que le nombre de lits de chaque tablissement hos-pitalier. Pour ce dernier, la gure 1.2 montre la carte obtenue.

Fig. 1.2 Tous les tablissements au niveau national

6 Introduction

1.3 Problmatique et objectif de la thse

Les entrepts de donnes ont t conus pour laide la dcision. Ils intgrent lesinformations en provenance des dirents systmes transactionnels de lentreprise.Lensemble des donnes, y compris leur historique, est utilis pour faire des calculsprvisionnels, des statistiques ou pour tablir des stratgies de dveloppement etdanalyses des tendances.

Dans le cadre du projet ADELEM, nous nous proposons dadapter notre savoir-faire au problme de la gestion de donnes mdicales qui constituent un cadre appli-catif particulirement intressant. En eet, ces donnes se trouvent rparties dansplusieurs sources quil faut, dans un premier temps, fdrer pour constituer un en-trept de donnes pertinentes pour lapplication vise. Cette tape est importantecar elle doit non seulement identier les sources, mais aussi dterminer commentextraire de ces sources les donnes dsires. Nous devons dterminer si les donnesdoivent tre extraites telles quelles ou bien sil faut les traiter au pralable en leurappliquant des fonctions spciques comme des agrgats, des sommes, ... En plus,nous devons tablir un mcanisme pour la gestion de lvolution. Dans ce cas, il fautdterminer ladaptation au niveau : de lapplication dextraction, des agrgats et delapplication danalyse.

Cette problmatique est gnrale la constitution de tout entrept mais nousdevons ici tenir compte de la nature particulire des donnes sur lesquelles portentltude : type, format, smantique, condentialit, degr de abilit et de conance,informations manquantes ou incompltes, ... En rsum, il sagit de constituer unentrept qui contient des donnes pertinentes et de qualit sur lesquelles sera basloutil dinterrogation et le processus daide la dcision.

Prcedemment, nous avons dit que notre travail sencadre principalement auxtapes dorganisation et dinterrogation. Pour cela, nous nous sommes focaliss surles problmatiques suivantes : la conception dun entrept de donnes, la slectiondes vues matrialiser et la gestion de lvolution. Ainsi, nous traitons dabord cessujets 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 complexeet dlicate. Dans [Kim96, KR03], nous trouvons une mthodologie descendante pourla conception dun entrept. Elle se compose de neuf dcisions majeures qui sont la base dune conception complte. Les cinq premires portent sur la structurelogique, tandis que les autres quatre traitent sur la structure physique.

1) Lidentication des tables de faits.2) Le niveau de granularit de chaque table de faits.3) Les dimensions appartenant la table de faits.

1.3 Problmatique et objectif de la thse 7

4) Lensemble de mesures.5) Les attributs des dimensions avec des descriptions compltes.6) La gestion de lvolution.7) La dnition des agrgats, des dimensions dgnres et des dimensions ht-

rognes.8) Ltendue historique des donnes.9) La priodicit des mises jour.

Nous donnons une description de ces dcisions :

A partir de lanalyse des sources de donnes existantes et rellement utilises,nous pouvons aboutir aussi bien lidentication des tables de faits, qui reprsententle sujet danalyse, qu son niveau de granularit. Lorsque le grain de la table defaits est connu, les dimensions peuvent tre identies. Le choix des dimensionsest le point cl de la conception, car elles modlisent les perspectives de lanalyse.Une fois les dimensions choisies, nous dnissons lensemble de mesures, qui repr-sentent les direntes valeurs de lactivit analyse. Nous devons aussi enregistrerpour chaque dimension lensemble des attributs textuels. Les attributs peuvent treutiliss comme source de restrictions dans une requte.

Pour la gestion de lvolution lintrieur des dimensions, Kimball [Kim96] pro-pose trois solutions qui assurent un suivi des modications dans le temps :

1) Remplacer des valeurs anciennes par des nouvelles dans lenregistrement de ladimension, nanmoins, nous perdons la possibilit de suivre les vnements passs.

2) Crer des nouveaux enregistrements de dimension lors du changement quicontiennent les nouvelles valeurs de lattribut. Ceci quivaut segmenter lhisto-rique selon lancienne et la nouvelle description.

3) Crer des nouveaux champs "actuels" lintrieur de lenregistrement doriginede la dimension, tout en conservant en mme temps les premires valeurs enregis-tres. Dans ce cas, nous pouvons garder seulement la valeur originale et la courantede 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 latable de faits.

Nous dcrirons une dimension htrogne en utilisant un exemple. Une compa-gnie dassurances a en gnral des domaines dactivit trs direncis. Il y a parexemple : les risques habitation, les risques automobiles, les risques objets person-nels, la responsabilit civile, ..., o chaque domaine est reprsent par des attributsparticuliers. Nous identions deux dimensions : une pour le bien assur et une autre

8 Introduction

pour le risque couvert. Nanmoins, la dimension Bien_assure contient lensembledattributs des produits htrognes (habitation, automobile, ...) ce qui fait delleune dimension htrogne. Kimball propose de faire des dimensions particularises,ce qui signie de faire des "copies" de la dimension Bien_assure pour chaque domainedactivit, ainsi, pour chaque type de risque couvert nous crons des dimensions par-ticularises pour Bien_assure et pour Risque_couvert.

Finalement, nous devons tablir le priode des donnes historises ainsi que lafrquence des mises jour. Cette dernire peut tre journalire, hebdomadaire, men-suelle,...

1.3.2 Slection des vues matrialiser

La slection de lensemble optimal des vues matrialiser fait partie du processusdorganisation et elle reprsente une tche essentielle dans la conception dun en-trept. La matrialisation nous permet doptimiser lexcution dune requte, pourcela, nous avons les possibilits suivantes :

La matrialisation complte : Cette approche donne le meilleur temps de rponsede la requte. Nanmoins, la matrialisation complte nest pas faisable, due princi-palement au cot de stockage lev.

Pas de matrialisation : Dans ce cas, nous navons pas besoin de stockage suppl-mentaire. Cependant, pour rpondre chaque requte, nous devons chercher lin-formation au niveau plus bas de granularit (i.e., raw data). Ainsi, nous avons leproblme dun cot de calcul trs lev pour chaque requte.

La matrialisation partielle : Dans cette approche, le problme se rduit dter-miner le nombre optimal de vues matrialiser, en considrant leur cot de stockage,de maintenance, ...

Il est vident que la dernire approche est la plus intressante. Elle fait lobjet deplusieurs recherches qui ont pour objectif daboutir la dnition dun mcanismepour la slection dun ensemble optimal des vues matrialiser. La plupart des tra-vaux utilisent un modle de cot mais qui a t adapt avec linclusion de certainsparamtres, tels que : la frquence de la requte, la frquence des mises jour surles relations de base, le cot de maintenance, entre autres.

Pour nir, nous voulons faire une remarque. Quand nous parlons de la possi-bilit de rien matrialiser, nous nous rfrons au fait que nous ne considrons pasles donnes du niveau plus bas comme des donnes matrialises. En eet, certainsdentre nous visualisent les donnes de dtail de lentrept comme une sorte de ma-trialisation de linformation qui se trouve dans les sources de donnes. Nanmoins,pour nous, ces donnes une fois intgres et stockes dans lentrept, reprsentent

1.3 Problmatique et objectif de la thse 9

lensemble de relations de base partir desquelles nous slectionnerons les vues matrialiser.

1.3.3 Gestion de lvolution des entrepts

Le problme dvolution de schma apparat quand un changement au schmadune 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 nousavons une nouvelle version de schma S2 partir de S1, le problme est la dnitionde la nouvelle version V2 qui soit cohrente avec S2 [Ber03].

Lvolution dun schma a des consquences sur lapplication charge de lex-traction et lintgration de donnes des sources, car elle peut devenir incomplteou incohrente vis--vis du nouveau schma de lentrept. Cette volution entraneaussi ladaptation des agrgats pr-calculs et ladaptation du processus de mainte-nance.

La gure 1.3 montre les adaptations ncessaires aprs quune volution du schmaa eu lieu dans un entrept de donnes.

EXTRACTION

Entrept dedonnesSources de donnes

ORGANISATION

INTERROGATION Outils

Adaptation de lapplication dextraction

Adaptation des agrgats

Adaptation de lapplication danalyse

Fig. 1.3 Gestion de lvolution du schma dans un entrept

Pour rsoudre le problme de perte de donnes aprs des changements du schma,le concept dvolution de schma t introduit pour rcuprer les donnes exis-tantes par le biais de leur adaptation au nouveau schma. Nanmoins, dans lessystmes qui doivent grer des donnes historiques, lvolution de schma nest passusante et la maintenance de plusieurs schmas est requise [GM02]. Ainsi, pourgrer ces changements, nous pouvons utiliser soit lvolution de schmas soit lesversions de schmas. Nous devons choisir la technique utiliser par rapport auxcaractristiques de lapplication cible.

10 Introduction

1.3.4 Objectif de la thse

Notre objectif consiste la conception et mise en oeuvre dun entrept de donnespour 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. Nousreprenons les propositions numres prcdemment et nous donnons une descriptionde chacune delles.

1.4.1 Mtamodle multidimensionnel

Pour le mtamodle, nous avons spci trois mtaclasses : Cube, Dimension etHirarchie. Nous avons propos les dnitions pour chaque mtaclasse et leurs ins-tances, ainsi quune dnition dune base de donnes multidimensionnelle et de soninstance. Ceci nous a permis daboutir la conception dun modle multidimension-nel qui se compose dun ensemble de classes contenant des proprits, des relationset des contraintes entre les classes. Nous distinguons les termes de dimension et dehirarchie avec les caractristiques suivantes :

- Une dimension peut contenir zro, une ou plusieurs hirarchies. Une instance dehirarchie ne peut pas relier linstance du cube auquel est associe linstance de ladimension contenant cette hirarchie. Nanmoins, elle peut relier une instance dunautre cube et ceci en raison de la granularit associe chaque hirarchie.

- Nous pouvons insrer un niveau de hirarchie soit ct de la hirarchie djdnie 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 nousavons 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, nousavions les possibilits suivantes : la matrialisation complte, pas de matrialisationou la matrialisation partielle. Dans notre cas, nous considrons la dernire approche.

Notre algorithme utilise un modle de cot, nanmoins, nous considrons aussi lesparamtres 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 donnesmdicales relles et nous avons constat que notre proposition donne de meilleursrsultats pour notre cas exprimental.

1.4.3 Interface pour la gnration (semi-automatique) des in-dicateurs

Lobjectif de notre interface est de faciliter la tche de cration dindicateurs pourles 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 basede donnes correspondante en utilisant un chantillon de 10% des donnes relles duprojet ADELEM. Ceci nous a permis de vrier et de prouver notre interface gra-phique, de cette manire, la requte SQL gnre sexcute sur les donnes mdicaleset le rsultat est prsent sur linterface.

1.4.4 Versions de schmas bitemporels

Nous proposons lutilisation des versions de schmas bitemporels pour la gestion,le stockage et la visualisation des donnes historises intensionnelles et extension-nelles. Dans ce cas, nous devons grer la combinaison du temps de transaction et dutemps de validit dans notre modle de versions.

Nanmoins, la gestion des versions est une tche complexe et elle prsente plu-sieurs problmes. Le principal, notre connaissance, est lexplosion des versions,ainsi, nous devons tablir un mcanisme pour contrler cette explosion. Notre pro-position considre :

- Un oprateur appel SetVersion qui permet dappliquer un ensemble de chan-gements sur une version et de gnrer une nouvelle version.

12 Introduction

- Un ensemble de 19 primitives ncessaires pour la gestion des cubes, des dimen-sions et des hirarchies.

- Un ensemble de 5 primitives qui agissent sur les versions de schmas.

- Un gestionnaire dvolution responsable de la manipulation des direntes ver-sions de schmas historises.

1.5 Plan de la thse

Nous prsentons ici lorganisation du document.

Le chapitre 2 fait un tat de lart des entrepts de donnes dans le contexteo nous nous plaons. Nous prsentons larchitecture dun entrept et ses compo-sants, les dirents modles multidimensionnels pour la construction dun systmedcisionnel, ainsi que lensemble des oprations pour la manipulation des donnesmultidimensionnelles. Nous dcrivons les serveurs dcisionnels : ROLAP, MOLAPet HOLAP. Dans la dernire partie, nous prsentons lapproche des versions deschma. Nous prsentons dabord ltat courant des versions dans les modles dedonnes existants. Ensuite nous dcrivons lespace de versions, leurs types, la ges-tion de donnes extensionnelles et intensionnelles, ainsi que les oprations primitives utiliser.

Le chapitre 3 prsente larchitecture conue pour un systme dcisionnel dansle domaine mdical. Elle est base sur trois composants, une interface graphiquepour la gnration semi-automatique des indicateurs, un entrept multidimension-nel et les versions de schmas bitemporels. Nous dcrivons notre mtamodle etses mtaclasses. Nous prsentons le schma en constellation conu compos de troissous-schmas : Prise_MCO, Prise_SSR et Population, o chacun est compos soit deses propres dimensions soit des dimensions partages.

Le chapitre 4 traite le sujet des vues matrialises, aussi bien leur slection queleur cration. Nous prsentons dabord lhypercube pour le schma Adelem_MCO. En-suite, nous prsentons un algorithme pour la slection de lensemble optimal des vues slectionner. Nous terminons ce chapitre avec une description du fonctionnementde linterface pour la gnration semi-automatique dindicateurs.

Le chapitre 5 prsente notre proposition pour la gestion, le stockage et la vi-sualisation de lensemble de donnes historises. Pour la cration et la gestion desversions de schmas, nous donnons une liste doprations primitives adaptes auxentrepts de donnes et nous avons aussi dni un ensemble de contraintes pour lamanipulation des versions. Nous donnons aussi pour chaque primitive sa dnitionformelle. La dernire partie traite de la description du gestionnaire dvolution deschmas. Nous prsentons aussi bien la gestion de donnes historises que lactivit

1.5 Plan de la thse 13

du gestionnaire dvolution par niveau.

Finalement, le chapitre 6 prsente nos conclusions et quelques perspectives.

14 Introduction

Chapitre 2

Entrepts de donnes

multidimensionnelles et aspects

temporels

Les entrepts de donnes sont apparus vers les annes 1990 en rponse la n-cessit de rassembler toutes les informations de lentreprise en une base de donnesunique destine aux analystes et aux gestionnaires [Cod93, DG01]. Lensemble desdonnes, y compris leur historique, est utilis dans de nombreux domaines, telsque : lanalyse de donnes et laide la dcision (gestion et analyse de march,gestion et analyse du risque, gestion et dtection des fraudes,...) ; dans autres appli-cations (recherches dans des textes, dans les documents web, dans lastronomie,...)[Adi02, BCA01].

Dans ce chapitre, nous analysons aussi bien les caractristiques des entrepts queleurs aspects temporels.

2.1 Entrepts de donnes

Nous prsentons dabord larchitecture dun systme dcisionnel qui se composede trois composants : les sources, lentrept et les outils pour linterrogation delensemble de donnes. Nous dcrivons aussi les caractristiques des entrepts et lesbases de donnes.

2.1.1 Architecture dun entrept de donnes

Larchitecture des entrepts de donnes repose souvent sur un SGBD spar dusystme de production de lentreprise qui contient les donnes de lentrept. Le pro-cessus dextraction des donnes permet dalimenter priodiquement ce SGBD. Nan-moins avant dexcuter ce processus, une phase de transformation est applique auxdonnes oprationnelles. Celle-ci consiste les prparer (mise en correspondancedes 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 dedonnes, lentrept et les outils existants dans le march.

Donnes externes

Donnes de production(SGBD, systmes lgus)

O

U

T

I

L

S

Donnes anciennes archives

Donnes de dtail

Donnes lgrement rsumes

Donnes fortement rsumes

Mtadonnes

Entrept de donnes

Fig. 2.1 Architecture dun entrept de donnes

a) Les sources : Les donnes de lentrept sont extraites de diverses sources sou-vent rparties et htrognes, et qui doivent tre transformes avant leur stockagedans lentrept. Nous avons deux types de sources des donnes : internes et externes lorganisation.

Internes : La plupart des donnes sont saisies partir des dirents systmesde production qui rassemblent les divers SGBD oprationnels, ainsi que des ancienssystmes de production qui contiennent des donnes encore exploites par lentre-prise.

Externes : Ils reprsentent des donnes externes lentreprise et qui sont souventachtes. Par exemple, les sources de donnes dmographiques.

b) Lentrept de donnes : Il existe plusieurs types de donnes dans un entre-pt, qui correspondent diverses utilisations, comme :

2.1 Entrepts de donnes 17

Donnes de dtail courantes : Ce sont lensemble des donnes quotidienneset plus couramment utilises. Ces donnes sont gnralement stockes sur le disquepour 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 concernantdes vnements passs, comme par exemple le dtail des ventes des deux derniresannes. Nous les utilisons pour arriver lanalyse des tendances ou des requtes pr-visionnelles. Nanmoins ces donnes sont plus rarement utilises que les prcdentes,et elles sont souvent stockes sur des mmoires darchives.

Donnes rsumes ou agrges : Ce sont des donnes moins dtailles que lesdeux premires et elles permettent de rduire le volume des donnes stocker. Letype de donnes, en fonction de leur niveau de dtail, permet de les classier commedes donnes lgrement ou fortement rsumes. Par exemple, les ventes mensuellespar magasin des dix dernires annes sont des donnes faiblement rsumes, tandisque les ventes semestrielles, par rgion, des dix dernires annes sont fortement r-sumes.

Les mtadonnes : Ce sont des donnes essentielles pour parvenir une ex-ploitation ecace du contenu dun entrept. Elles reprsentent des informationsncessaires laccs et lexploitation des donnes dans lentrept comme : la sman-tique (leur signication), lorigine (leur provenance), les rgles dagrgation (leurprimtre), le stockage (leur format, par exemple : francs, euro,...) et nalementlutilisation (par quels programmes sont-elles utilises).

c) Outils : Il existe sur le march dirents outils pour laide la dcision, commeles outils de fouille de donnes ou datamining (pour dcouvrir des liens smantiques),outils danalyse en ligne (pour la synthse et lanalyse des donnes multidimension-nelles), outils dinterrogation (pour faciliter laccs aux donnes en fournissant uneinterface 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 desdonnes, les critres de performance, la gestion des mtadonnes, la gestion destransactions et le processus de requtes sont trs dirents des systmes de basesde donnes oprationnels. Par consquent, les SGBD relationnels orients vers len-vironnement oprationnel, ne peuvent pas tre directement transplants dans unsystme dentrept de donnes [WB97].

Les SGBD ont t cres pour les applications de gestion de systmes transac-tionnels. Par contre, les entrepts de donnes ont t conus pour laide la prise


de dcision. Ils intgrent les informations qui ont pour objectif de fournir une vueglobale de linformation aux analystes et aux dcideurs.

Le tableau 2.1 rsume ces dirences entre les systmes de gestion de bases dedonnes et les entrepts de donnes [DG01].

SGBD Entrepts de donnesObjectifs Gestion et production Consultation et analyseUtilisateurs Gestionnaires de production Dcideurs, analystesTaille de la base Plusieurs gigaoctets Plusieurs teraoctetsOrganisation Par traitement Par mtierdes donnesType de donnes Donnes de gestion Donnes danalyse

(courantes) (rsumes, historises)Requtes Simples, prdtermines, Complexes, spciques,

donnes dtailles agrgations et group byTransactions Courtes et nombreuses, Longues, peu nombreuses

temps rel

Tab. 2.1 Dirences entre SGBD et entrepts de donnes

Systmes transactionnels et systmes dcisionnels Les SGBD ont t crspour grer de grands volumes dinformation contenus dans les dirents systmesoprationnels qui appartiennent lentreprise. Ces donnes sont manipules en uti-lisant des processus transactionnels en ligne [Cod93].

Paralllement lexploitation de linformation contenue dans ces systmes opra-tionnels, les dirigeants des entreprises ont besoin davoir une vision globale concer-nant toute cette information pour faire des calculs prvisionnels, des statistiques oupour tablir des stratgies de dveloppement et danalyses des tendances.

Le tableau 2.2 compare les caractristiques des systmes transactionnels et dci-sionnels par rapport aux donnes et aux utilisateurs [BCA01, CT98, GM00, SMKK98,Tes00, ZS99].

2.2 Modlisation multidimensionnelle

Pour arriver construire un modle appropri pour un entrept de donnes, nouspouvons choisir, soit un schma relationnel (le schma en toile, en ocon de neigeou en constellation) ; soit un schma multidimensionnel. Avant de dcrire les di-rents schmas, nous commenons par quelques concepts de base.

2.2 Modlisation multidimensionnelle 19

S. Transactionnel S. DcisionnelDonnes Exhaustives Rsumes

Courantes HistoriquesDynamiques StatiquesOrientes applications Orientes sujets (danalyse)

Utilisateurs Nombreux Peu nombreuxVaris (employs, Uniquement les dcideursdirecteurs,...)Concurrents Non concurrentsMises jour et InterrogationsinterrogationsRequtes prdnies Requtes imprvisibles et complexesRponses immdiates Rponses moins rapidesAccs peu Accs de nombreuses informationsdinformation

Tab. 2.2 Comparaison des systmes

La modlisation multidimensionnelle consiste considrer un sujet analys commeun point dans un espace plusieurs dimensions. Les donnes sont organises de ma-nire mettre en vidence le sujet (le fait) et les direntes perspectives de lanalyse(les dimensions).

En partant de cette dnition, nous remarquons les concepts de fait et de di-mension. Le fait reprsente le sujet danalyse. Il est compos dun ensemble demesures qui reprsentent les direntes valeurs de lactivit analyse. Par exemple,dans le fait Ventes (cf. Figure 2.2), nous pouvons avoir la mesure "Quantit de pro-duits vendus par magasin". Les mesures doivent tre valorises de manire continue[AGS97, CT97, Inm92, Inm95, Kim96, KR03, KS95] et elles peuvent tre addi-tives (pour rsumer une grande quantit denregistrements) ; semi-additives (si ellespeuvent seulement tre additionnes pour certaines dimensions) et non additives.

Une dimension modlise une perspective de lanalyse. Elle se compose de pa-ramtres (ou attributs) qui servent enregistrer les descriptions textuelles. Nouspouvons utiliser les paramtres textuels comme source des restrictions dans une re-qute. Par exemple, dans la requte "Quantit de produits vendus dans la rgionRhne 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 niveaude granularit ou de dtail. Les paramtres sont ordonns par une relation "est_plus_fin" et note P1 P2. Dans notre exemple sur les ventes (cf. gure 2.2)nous pouvons avoir une hirarchie pour la dimension Magasin de la forme suivante :


Commune Dpartement Rgion Pays

2.2.1 Schmas relationnels

Dans les schmas relationnels nous trouvons deux types de schmas. Les premierssont des schmas qui rpondent fort bien aux processus de type OLTP qui ont tdcrits prcdemment, alors que les deuximes, que nous appelons des schmas pourle dcisionnel, ont pour but de proposer des schmas adapts pour des applicationsde 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 unerelation pour les faits et plusieurs pour les direntes dimensions autour de la rela-tion centrale. La relation de faits contient les direntes mesures et une cl trangrepour faire rfrence chacune de leurs dimensions.

La gure 2.2 montre le schma en toile en dcrivant les ventes ralises dansles dirents magasins de lentreprise au cours dun jour. Dans ce cas, nous avonsune toile centrale avec une table de faits appele Ventes et autour leurs diversesdimensions : Temps, Produit et Magasin.

Temps

Cl_TJourMoisAnne

Cl_PCl_TCl_M

Quantit

Ventes

Produit

Cl_PDescriptionTypeCatgorie

Magasin

Cl_MRaison_socAdresseCommuneDpartementRgionPays

Fig. 2.2 Exemple de modlisation en toile.

2.2 Modlisation multidimensionnelle 21

2.2.1.2 Le schma en flocon de neige (Snowflake)

Il drive du schma prcdent avec une relation centrale et autour delle les di-rentes dimensions, qui sont clates ou dcomposes en sous hirarchies. Lavantagedu schma en ocon de neige est de formaliser une hirarchie au sein dune dimen-sion, ce qui peut faciliter lanalyse. Un autre avantage est reprsent par la nor-malisation des dimensions, car nous rduisons leur taille. Nanmoins dans [Kim96],lauteur dmontre que cest une perte de temps de normaliser les relations des di-mensions dans le but dconomiser lespace disque. Par contre, cette normalisationrend plus complexe la lisibilit et la gestion dans ce type de schma. En eet, ce typede 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 etMagasin clates en sous hirarchies.

Produit

Cl_PDescriptionTypeCatgorieCl_P

Cl_TCl_M

Quantit

Ventes

Temps

Cl_TJourMois

T_Mois

MoisAnne

Magasin

Cl_MRaison_socAdresseCommuneDpartement

M_Rgion

RgionPays

M_Dpartement

DpartementRgion

Fig. 2.3 Exemple de modlisation en ocon de neige.

Dans lexemple ci-dessus, la dimension Temps a t clate en deux, Temps etT_Mois. La deuxime dimension Magasin, t dcompose en trois : Magasin, M_Dpartement et M_Rgion.


2.2.1.3 Le schma en constellation

Le schma en constellation reprsente plusieurs relations de faits qui partagentdes dimensions communes. Ces direntes relations de faits composent une famillequi 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 relationsde faits. La premire sappelle Ventes et enregistre les quantits de produits qui ontt vendus dans les dirents magasins pendant un certain jour. La deuxime re-lation gre les dirents produits achets aux fournisseurs pendant un certain temps.

Produit

Cl_PDescriptionTypeCatgorie

Cl_PCl_MCl_T

Quantit

Ventes

Temps

Cl_TJourMoisAnne

Achats

Cl_PCl_FCl_T

Quantit

Magasin

Cl_MRaison_socAdresseCommuneDpartementRgionPays

Fournisseur

Cl_FRaison_socAdresseCode_postalCommunePays

Fig. 2.4 Exemple de modlisation en constellation.

La relation de faits Ventes partage leurs dimensions Temps et Produits avec latable Achats. Nanmoins, la dimension Magasin appartient seulement Ventes. Ega-lement, la dimension Fournisseur est lie seulement la relation Achats.

2.2.2 Schma multidimensionnel (Cube)

Dans le modle multidimensionnel, le concept central est le cube, lequel estconstitu des lments appels cellules qui peuvent contenir une ou plusieurs me-sures. La localisation de la cellule est faite travers les axes, qui correspondentchacun une dimension. La dimension est compose demembres qui reprsententles direntes valeurs.

2.3 Manipulation des donnes multidimensionnelles 23

En reprenant une partie du schma en toile de la g. 2.2, nous pouvons construirele schma multidimensionnel suivant.

SUM

03/01/2000

02/01/2000

01/01/2000

SUMAnnecyGrenoble

LyonTV R CS CP

SUM

All

Temps

Magasin

Produit

Jour

mois

anne

Temps

Ville

Dpartement

Rgion

Pays

Magasin

Hirarchies des dimensions

Fig. 2.5 Exemple de schma multidimensionnel.

La gure 2.5, prsente un schma multidimensionnel pour les ventes qui ont tralises dans les magasins pour les dirents produits au cours dun temps donn(jour). Par exemple, nous avons la quantit de 100 Tlviseurs vendus dans le ma-gasin dAnnecy pendant le 1er janvier 2000.

2.3 Manipulation des donnes multidimensionnelles

Pour visualiser les donnes multidimensionnelles, nous pouvons utiliser la repr-sentation sous forme dune table de donnes, qui est la plus courante [Mar98, Vas98].Dans une table, nous reprsentons les direntes combinaisons des valeurs choisiespour constituer les noms de lignes et de colonnes. Nanmoins, quand le nombre dedimensions est suprieur deux, lutilisateur a des problmes pour visualiser si-multanment lensemble de linformation. Pour rsoudre ce problme, nous devonsdisposer doprations pour manipuler les donnes et rendre possible la visualisation.

Nous prsentons les oprations pour la manipulation des donnes multidimen-sionnelles, en les divisant selon leur impact sur la faon de prsenter les direntesvues des donnes analyses [Mar98, MQM97, MS90, Tes00].

2.3.1 Oprations classiques

Ces oprations correspondent aux oprations relationnelles de manipulation desdonnes :

La slection : Rsulte en un sous-ensemble de donnes qui respecte certains condi-tions dappartenance. Nous pouvons avoir une slection avec des conditions soit sur


les mesures, soit sur les membres. Par exemple, une slection des ventes suprieur 350 est une slection sur les mesures, tandis que une slction des ventes ralissdans la rgion "Rhne Alpes" de lanne "2000" est une slection sur les membresdune dimension.

La projection : Rsulte en un sous-ensemble des attributs dune relation, qui sontsoit 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 etleur prix (cf. Figure 2.6).

Ventes (01/01/2000) Mag1 Mag2 Mag3Tlviseur 100 250Radio 50 200Camscope 50 100Camera photo 100 100

Tab. 2.3 Ventes par magasin

Produit Prix (01/01/2000)Tlviseur 1Radio 2Camscope 3Camera photo 4

Tab. 2.4 Prix des produits

Les oprations ensemblistes : Dunion, dintersection et de dirence sont desoprations 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, demanire prsenter une vue dirente des donnes analyser.

2.3 Manipulation des donnes multidimensionnelles 25

Fig. 2.6 Exemple de lopration Jointure.

Ville Produit Mag1 Mag2 Mag3Grenoble Tlviseur 50 100Grenoble Radio 50 100Grenoble Camscope 100Grenoble Camera photo 50 100

Tab. 2.5 Ventes de produits par ville 1

Ville Produit Mag1 Mag2 Mag3Fontaine Tlviseur 100 100 50Fontaine Radio 50 100Fontaine Camscope 100 50 100Fontaine Camera photo 100 100

Tab. 2.6 Ventes de produits par ville 2

Ville Produit Mag1 Mag2 Mag3Grenoble Tlviseur 50 100Grenoble Radio 50 100Grenoble Camscope 100Grenoble Camera photo 50 100Fontaine Tlviseur 100 100 50Fontaine Radio 50 100Fontaine Camscope 100 50 100Fontaine Camera photo 100 100

Tab. 2.7 Ventes du Dpartement Isre


La permutation (switch) : Consiste inverser des membres dune dimension, demanire permuter deux tranches du cube.

La division (split) : Consiste prsenter chaque tranche du cube en passantdune reprsentation tridimensionnelle une prsentation tabulaire. Par exemple, sinous dcoupons par magasin le cube de ventes de la gure 2.5, nous avons les tables2.8, 2.9 et 2.10.

Ventes Magasin 1 01/01/2000 02/01/2000 03/01/2000Tlviseur 100 100 50Radio 50 200 100Camscope 100Camera photo 100 100 100

Tab. 2.8 Table de ventes du Magasin 1

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


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


Nous remarquons que le nombre de tables rsultantes de cette opration dpenddu nombre de valeurs lintrieur de la dimension.

Lembotement (nest) : Permet dimbriquer les membres dune dimension. Enutilisant cette opration, nous reprsentons dans une table bidimensionnelle toutesles donnes dun cube quel que soit le nombre de dimensions.

Lenfoncement (push) : Consiste combiner les membres dune dimension auxmesures 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 certainesmesures, 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 dunedimension.

La paramtrisation (unfold) : Permet de transformer une mesure en paramtredans une nouvelle dimension.

Lopration Cube : Permet de calculer des sous-totaux et un total nal dans lecube (cf. Fig 2.5).

2.3.3 Oprations agissant sur la granularit

Les oprations agissant sur la granularit des donnes analyses, permettent dehirarchiser 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 donnesdu cube un niveau plus haut de granularit en respectant la hirarchie de ladimension. Nous utilisons une fonction dagrgation (somme, moyenne,...), qui estparamtre, pour indiquer la faon de calculer les donnes du niveau suprieur partir de celles du niveau infrieur.

Le forage vers le bas (drill-down ou roll-down ou scale-down) : Consiste re-prsenter les donnes du cube un niveau de granularit infrieur, donc sous uneforme plus dtaille.

Ces types doprations ont besoin dinformations non reprsentes dans un cube,pour augmenter ou aner des donnes, partir dune reprsentation initiale vers unereprsentation de granularit dirente. Le forage vers le haut a besoin de connatrela fonction dagrgation utilise tandis que le forage vers le bas ncessite de connatreles donnes au niveau infrieur.

2.4 Serveurs OLAP (On-Line Analytical Processing)

Les donnes oprationnelles constituent la source principale dun systme dinfor-mation dcisionnel. Les systmes dcisionnels complets reposent sur la technologieOLAP, conue pour rpondre aux besoins danalyse des applications de gestion.

Lacronyme FASMI (Fast Analysis of Shared Multidimensional Information) per-met de rsumer la dnition des produits OLAP. Cette dnition fut utilise pour


la premire fois en 1995 et depuis aucune autre dnition nest plus proche pourrsumer le terme OLAP [Ola04].

Fast : Le temps de rponse aux demandes des utilisateurs oscille entre 1 et 20secondes. Les constructeurs utilisent des pr-calculs pour rduire les dures des re-qutes.

Analysis : Le systme doit pouvoir faire face toutes les logiques daaires etde statistiques, ainsi que fournir la possibilit aux utilisateurs de construire leurscalculs et leurs analyses sans avoir programmer. Pour cela, il y a des outils quiseront fournis par le constructeur.

Shared : Le systme doit crer un contexte o la condentialit est prserve et doitgrer les cas o plusieurs utilisateurs ont des droits en critures. Ce point constituela plus grosse faiblesse des produits actuels.

Multidimensional : Cest la caractristique cl. Le systme doit fournir des vuesconceptuelles multidimensionnelles des donnes. Il doit supporter aussi les hirar-chies.

Informations : Lensemble des donnes et les informations ncessaires pour un pro-duit OLAP.

Nous exposons dans la suite les divers types de stockage des informations dansles systmes dcisionnels.

2.4.1 ROLAP (Relational OLAP)

Dans les systmes relationnels OLAP, lentrept de donnes utilise une base dedonnes relationnelle. Le stockage et la gestion de donnes sont relationnels. Toute-fois, le modle relationnel requiert des extensions pour supporter les requtes dana-lyses multidimensionnelles du niveau dapplication. Le moteur ROLAP traduit dy-namiquement le modle logique de donnes multidimensionnel M en modle de sto-ckage relationnel R (la plupart des outils requirent que la donne soit structure enutilisant un schma en toile ou un schma en ocon de neige). Techniquement, lemoteur ROLAP excute une transformation partir dune requte multidimension-nelle m contre M vers une requte relationnelle r contre R. Lecacit du rsultatde la requte est le facteur dominant pour la performance et le passage lchelleglobal du systme. Ainsi, les stratgies doptimisation reprsentent le point principalqui distingue les systmes ROLAP existants [DSBH99, Sat03].

La gure 2.7 montre une architecture pour le serveur ROLAP.


Base de donnes relationnelle

Serveur ROLAP

Vuemultidimensionnelle

Client OLAP

Fig. 2.7 Architecture ROLAP.

La technologie ROLAP a deux avantages principaux : (1) elle permet la dnitionde donnes complexes et multidimensionnelles en utilisant un modle relativementsimple , et (2) elle rduit le nombre de jointures raliser dans lexcution dunerequte. Le dsavantage est que le langage de requtes tel quil existe, nest pasassez 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. IBMest une shared nothing database et elle supporte le concept de fdration. Elle disposedune large gamme doutils, par exemple :

DB2 Performance Expert : Cet outil pour multiplate-formes permet la crationdes rapports, des analyses et recommande des changements par rapport la perfor-mance.

DB2 DataJoiner : Outil pour loptimisation des requtes SQL.

DB2 Integrated Cluster Environnement : Il permet le passage lchelle.

Oracle 9i : Cest un SGBD tournant aussi sur une varit de plate-formes. Oraclesupporte des partitions de hash, range et list.

Oracle 9i : Cest une shared disk database et elle supporte la consolidation (foca-lise sur une base de donnes centralise).

Real Application Clusters : Il permet de dsigner certains processeurs comme pro-cesseurs OLAP et dautres comme processeurs de requtes.


Loptimiser : Bas sur les cots ou sur les rgles.

SQL Server 2000 : Cest une shared nothing database et elle supporte le conceptde fdration (liaison entre bases de donnes distribues et htrognes via le logi-ciel).

Loptimiser de SQL Server : Bas sur les cots avec cration automatique destatistiques et leur rafrachissement.

Le Query Processor : Il supporte des requtes multidimensionnelles, ainsi que lesindex composites et semi-jointures.

Le SQL Query Analyzer : Il peut faire des suggestions par rapport limplanta-tion des index additionnels et des statistiques complmentaires.

Microsoft DTS (Data Transformation Services) : Loutil ETL intgr dans Mi-crosoft SQL Server.

2.4.2 MOLAP (Multidimensional OLAP)

Les systmes multidimensionnels OLAP utilisent une base de donnes multidi-mensionnelle pour stocker les donnes de lentrept et les applications analytiquessont construites directement sur elle. Dans cette architecture, le systme de base dedonnes multidimensionnel sert tant au niveau de stockage quau niveau de gestiondes donnes. Les donnes des sources sont conformes au modle multidimensionnel,et dans toutes les dimensions, les direntes agrgations sont prcalcules pour desraisons de performance [WB97].

La gure 2.8 montre une architecture pour les systmes MOLAP.

Serveur MOLAP

Client OLAP

Base de donnesmultidimensionnelle(hypercube)

Fig. 2.8 Architecture MOLAP.


Les systmes MOLAP doivent grer le problme de donnes clairsemes, quandseulement un nombre rduit de cellules dun cube contiennent une valeur de mesureassocie. Par exemple, dans le cube Ventes (cf. Fig 2.5), il peut arriver que cer-tains produits ne se soient pas vendus dans une ville spcique et quen consquentil ny ait pas de valeurs de mesure pour cette combinaison. La faon de rsoudrecette problmatique, par les produits commerciaux, reprsente un des plus impor-tants critres pour les systmes MOLAP. La plupart des systmes existants utilisentlapproche du vecteur multidimensionnel pour le stockage de donnes, ainsi que lacompression 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 systmesROLAP et elles reprsentent la raison de leur cration. Dun ct, les requtes MO-LAP sont trs puissantes et exibles en termes du processus OLAP, tandis que,dun autre ct, le modle physique correspond plus troitement au modle multidi-mensionnel. Nanmoins, il existe des dsavantages au modle physique MOLAP. Leplus 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 inclutdes modules pour la construction et le chargement des structures OLAP, pour lechargement des donnes, pour la dnition des processus de calcul, pour la gestiondes partitions de la base de donnes,...

Hyperion Essbase Query Designer : Ce composant remplace le Query WizarddEssbase 6.0. Il a t conu pour faciliter la navigation des utilisateurs naux.

Hyperion Essbase Partition Option : Il permet aux dveloppeurs des applicationsla cration logique et physique de sous-ensembles des bases de donnes. Les deuxtypes 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 dunedimension. 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 accsrapide aux donnes agrges [SAS04]. Leurs composants incluent :


SAS OLAP Cube Studio : Cest un outil pour la construction des cubes et quipeut tre facilement utilis pour la dnition des mesures, des dimensions et desagrgations.

SAS Metadata Server : Cest un conteneur des mtadonnes.

Ce serveur fournit un processus ETL (Extract, Transform and Load) qui esttransparent et intgr.

Informix MetaCube : Il fournit un mcanisme pour analyser lentrept de don-nes et leurs data marts intgrant des outils OLAP avec la technologie de bases dedonnes relationnelles [Inf02]. Les composants du logiciel MetaCube sont :

MetaCube Analysis Engine : Il fournit une interface multidimensionnel. Cet ou-til tend la fonctionnalit danalyse de la base de donnes avec lincorporation desoprations OLAP, par exemple lopration rotation (rotate).

MetaCube Explorer : Cest une interface graphique qui permet aux utilisateursdexcuter des requtes au travers du MetaCube Analysis Engine.

MetaCube Warehouse Manager : Cest une interface graphique pour crer une des-cription multidimensionnelle des tables et des colonnes dans lentrept de donnes.Le MetaCube Analysis Engine stocke cette description multidimensionnelle commeun ensemble de tables.

2.4.3 HOLAP (Hybrid OLAP)

Un systme HOLAP est un systme qui supporte et intgre un stockage des don-nes multidimensionnel et relationnel dune manire quivalente pour proter descaractristiques de correspondance et des techniques doptimisation.

Ci-dessous, nous traitons une liste des caractristiques principales quun systmeHOLAP doit fournir [DSBH99] :

La transparence du systme : Pour la localisation et laccs aux donnes, sansconnatre si elles sont stockes dans un SGBD relationnel ou dimensionnel. Pour latransparence 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 gnralque le langage de requte uniforme doivent tre fournis. Etant donn quil nexistepas un modle standard, cette condition est dicile raliser.

Une allocation optimale dans le systme de stockage : Le systme HOLAP


doit bncier des stratgies dallocation qui existent dans les systmes distribustels que : le prol de requtes, le temps daccs, lquilibrage de chargement,...

Une re-allocation automatique : Toutes les caractristiques traites ci-dessuschangent dans le temps. Ces changements peuvent provoquer la rorganisation dela distribution des donnes dans le systme de stockage multidimensionnel et rela-tionnel, pour assurer des performances optimales.

Actuellement, la plupart des systmes commerciaux utilisent une approche hy-bride. Cette approche permet de manipuler des informations de lentrept de don-nes avec un moteur ROLAP, tandis que pour la gestion des data marts, ils utilisentlapproche multidimensionnelle. Dans la gure 2.9, nous montrons une architectureen utilisant les types de serveurs ROLAP et MOLAP pour le stockage de donnes.

ServeurMOLAP

Client OLAP

Base de donnesmultidimensionnelle(hypercube)

Base de donnesrelationnelle

Vuemultidimensionnelle

Fig. 2.9 Architecture HOLAP.

Les produits commerciaux existants sont :

DB2 OLAP Server : Il permet de calculer, de consolider et daccser linforma-tion partir des bases de donnes multidimensionnelles, relationnelles ou les deux[DB204]. Certains de ses composants sont :

DB2 OLAP Integration Server : Il utilise des outils graphiques et des servicespour lintgration des donnes qui rduisent le cot pour crer, dployer et grer lesapplications de DB2 OLAP Server.

DB2 OLAP Server Administration Services : Il fournit des outils pour amlioreret faciliter des tches dadministration.

Oracle Express Server : Ce serveur exploite un modle de donnes multidi-mensionnel. Il gre un ensemble dindicateurs n dimensions, dont les valeurs sont


stockes ou calcules dynamiquement [ORA96].

Le stockage des donnes peut se faire dans une base de donnes multidimension-nelle ou relationnelle.

La base Oracle Express Server : Stocke les agrgats multidimensionnels, tandisque les donnes de dtail sont stockes dans la base relationnelle.

En utilisant un 4GL (Langage de 4me gnration), Express Server proposedes fonctions avances pour la prsentation et lanalyse des rsultats, tels que :traitement de sries chronologiques, consolidation, statistiques, prvisions,...

2.5 Les projets de recherche

Dans cette partie, nous dcrivons les projets de recherche sur les entrepts de don-nes. Les deux premiers (WHIPS et SIRIUS) sont centrs sur des problmatiqueslies lextraction et la maintenance des donnes. Le troisime DWQ traite de laqualit des entrepts, tandis que le dernier, le projet EVOLUTION propose le dve-loppement dune mthodologie et doutils pour laide la conception et lvolutiondes entrepts.

2.5.1 WHIPS Warehouse Information Prototype at Stanford

Lobjectif du projet est de dvelopper des algorithmes pour collecter, intgreret maintenir des informations de sources htrognes, distribues et autonomes. Lemodle relationnel est utilis comme modle unicateur.

Pour linitialisation de lentrept, lintgrateur cre un gestionnaire de vues pourchaque vue dans lentrept. Le gestionnaire de vues envoie les requtes issues de ladnition dune vue au processeur de requtes. Le processeur de requte contacteles traducteurs de la source dinformation adquate pour obtenir les rsultats, lesassemble et passe la rponse au gestionnaire de vue. Le gestionnaire de vue envoiela rponse ladaptateur de lentrept pour initialiser la vue.

Chaque source contienne un moniteur et un adaptateur. Ladaptateur transformeles donnes de la source en une reprsentation relationnelle. Le moniteur dtecte leschangements qui se produisent au niveau des sources. Les mises jour sont trans-mises lintgrateur, qui les transmet aux gestionnaires de vues qui sont concernspar les modications [LZW+97, HGMW+95].

Description des composants :

Adaptateur/Moniteur : Il est associ chaque source de donnes et il a deuxfonctionnes : 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 propagervers lintgrateur.

Intgrateur : Il est responsable de la rception des reprsentations intermdiairesdes donnes sources, en provenance des adaptateurs, et de lintgration de celles-ci. Lintgration entrane aussi une phase de transformation, celle-ci consiste lesprparer (mise en correspondance des formats de donnes), les nettoyer, les ltrer,...,pour les rendre conforme au schma de lentrept et aux critres de qualit choisis.

2.5.2 SIRIUS Supporting the Incremental Refreshment of Informa-tion warehouses

Ce projet dvelopp lUniversit de Zurich, est un systme dentrept de don-nes qui a pour objectif dtudier des techniques permettant le rafrachissementincrmental de lentrept en rduisant les temps de mise jour. Le schma de len-trept est dni sous la forme dun schma global UML.

Chaque source de donnes est munie dun adaptateur et dun moniteur. Le mo-niteur dtecte les volutions de la source laquelle il est associ. Le module degestion du rafrachissement est le module central (DWRM Data Warehouse RefreshManager). Ladaptateur traduit les donnes de la source dans un modle commun,interne au systme et les transmet au module central DWRM [VGD00].

Objectif du projet :

Lobjectif principal de cette approche est dintroduire une architecture dintergi-ciel exible, pour :

- Fournir des solutions pour le rafrachissement de donnes.

- Pouvoir tre utilise de faon indpendante par rapport au stockage de donnesde lentrept.

- Pouvoir tre utilise par des entrepts de donnes composs des sources dedonnes htrognes.

2.5.3 DWQ Foundations of Data Warehouse Quality

DWQ est un projet de la communaut Europenne (France, Allemagne, Italie etGrce) pour le dveloppement des fondements smantiques qui permettront daiderles concepteurs dentrepts de donnes dans le choix des modles, des structures dedonnes avances et des techniques dimplantation ecaces en sappuyant sur desfacteurs de qualit de service.


Les rsultats comportent des mta-modles formels de donnes destins la des-cription de larchitecture statique dun entrept de donnes. Les outils associscomportent des facilits de modlisation incluant des caractristiques spciquesaux entrepts comme la rsolution de sources multiples, la gestion de donnes mul-tidimensionnelles agrges et des techniques pour loptimisation de requtes et lapropagation incrmentale des mises jour.

Ce projet permet aussi lvolution de lentrept. Les outils incluent un ensembledoprateurs, lanalyse et loptimisation des dnitions des vues, la slection opti-mise de sources de donnes, des stratgies dintgration et des vues matrialises[JV97, JQJ98, JJQV99, TS99].

Objectifs du projet :

Les objectifs de recherche visent trois domaines, o les facteurs de qualit repr-sentent le point central :

- Enrichir la smantique de la mta base avec des models formels de qualit delinformation qui permettent loptimisation de la conception de faon adaptative etquantitative.

- Enrichir la smantique des models dinformation qui permettent aussi bien lerafrachissement incrmental de donnes et leur propagation vers lentrept, que larsolution des conits.

- Enrichir la smantique des models de schma de lentrept qui permettent auxconcepteurs 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, lamise en oeuvre, la maintenance et lvolution des entrepts. Les composants basicssont :

- Sources : les donnes stockes dont le contenu peut tre matrialis dans len-trept.

- Adaptateur : responsable du chargement des donnes sources dans lentrept.

- Base de donnes nale : lentrept de donnes et les data marts.

- Mta base : conteneur dinformation des autres composants, par exemple, leschma 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 doutilsde type CASE pour laide la conception et lvolution des entrepts de donnes.Lobjectif de ce projet est la spcication dun ensemble doutils daide la concep-tion de lentrept et sa maintenance. Deux objectifs sont intgrs dans la crationde ces outils : prvoir lvolutivit de schma et grer la traabilit des volutionssuccessives.

Pour atteindre ce but, trois objectifs, correspondant aux problmes de recherchesencore non rsolus sont atteindre :

- La dnition dun formalisme de modlisation des donnes et des mtadonnesde lentrept, ce formalisme doit permettre la fois de le dcrire et de le manipuler(pour le faire voluer ou pour vrier ses proprits).

- Des algorithmes de traitement smantique de la triple htrognit de concep-tualisation, de temps et de granularit.

- Des algorithmes doptimisation des performances des ressources matrielles etlogicielles de lentrept pour fournir ecacement les outils de Data Mining.

Lapproche envisage propose : lintgration smantique des dirents schmassources, la constitution dun schma de lentrept, la dnition et la mise jour desvues, la prise en compte de limprcision (des donnes mal connues ou incertainesdans lentrept), la prise en compte du temps et de la granularit, la vricationde la cohrence et de la consistance et loptimisation des ressources (paralllisme)[Evo97].

2.6 Aspects temporels des entrepts

Malgr une conception attentive et soigneuse, la structure dune base de don-nes est sujette de nombreux changements. Bien que les estimations dirent,la plupart saccordent sur le fait que plus de 50% du travail des dveloppeurs sefocalise sur les modications du systme aprs leur implantation [Rod95]. Pour r-soudre le problme de perte de donnes aprs des changements du schma, le conceptdvolution de schma t introduit pour rcuprer les donnes existantes. Cettercupration se ralise par le biais de ladaptation des donnes au nouveau schma.Nanmoins, dans les systmes qui doivent grer des donnes historiques, lvolution


de schma nest pas susante et la maintenance de plusieurs schmas est requise[GM02]. Cette problmatique a donne naissance la notion de versions de schmas.

Nous traitons les direntes nuances entre les dnitions de modication, dvo-lution et de version de schma. Nous commenons avec ltat actuel des versionsdans les dirents modles existants. Ensuite nous traitons le sujet des versions deschmas, la gestion des donnes intensionnelles et extensionnelles, les changementset leur reprsentation. Pour nir, la dernire section donne une brve descriptiondes oprations primi

Documents

These - Conception et réalisation d’un Data Warehouse pour la mise en place d’un système décisionnel