Modélisation multidimensionnelle des données

Modélisation multidimensionnelle des données complexes : application aux
données médicales
Midouni Sid Ahmed Djallal
Version -908/06/05
Sommaire :
1. Introduction .......................................................................................................................... 3
2. Etat de l’art ........................................................................................................................... 4
3. Modélisation multidimensionnelle des données complexes .............................................. 5
3.1. Modélisation multidimensionnelle .................................................................................. 6
3.2. Données complexes ......................................................................................................... 7
3.3. Modélisation multidimensionnelle des données complexes ............................................ 8
4. Contexte et objectifs ............................................................................................................. 9
4.1. Le projet MAP ................................................................................................................. 9
4.2. Le magasin cardiovasculaire .......................................................................................... 9
5. Notre démarche de modélisation ...................................................................................... 10
5.1. Le magasin cardiovasculaire : existant ........................................................................ 11
5.2. Nouveau modèle multidimensionnel du magasin cardiovasculaire.............................. 12
5.3. Le métamodèle............................................................................................................... 15
6. Prototype et Evaluation ..................................................................................................... 18
7. Conclusion et perspectives : .............................................................................................. 23
Liste des figures
Figure 1 : Représentation multidimensionnelle.......................................................................... 7
Figure 2 : Schéma en étoile ........................................................................................................ 7
Figure 3 : Les données complexes .............................................................................................. 8
Figure 4 : La démarche de modélisation.................................................................................. 11
Figure 5 : Le modèle multidimensionnel du module Cardiovasculaire [MAP04] .................. 11
Figure 6 : Le nouveau modèle Cardiovasculaire ..................................................................... 13
Figure 7 : Le Méta Modèle ....................................................................................................... 16
Figure 8 : Le processus de développement............................................................................... 19
Figure 9 : Architecture du prototype GEDM ........................................................................... 20
Figure 10 : Liste des dimensions .............................................................................................. 21
Figure 11 : Propriétés d’une dimension................................................................................... 21
Figure 12 : Liste des tables de faits .......................................................................................... 22
Figure 13 : Propriétés d’une table de faits............................................................................... 22
Figure 14 : Le méta modèle multidimensionnel de CWM ........................................................ 24
1
Résumé:
La vocation d’un entrepôt de données est l’analyse de données pour l’aide à la
décision dans les entreprises. Tout de même, la modélisation multidimensionnelle est la base
des entrepôts de données et l’analyse en ligne (OLAP).
Dans ce rapport, nous abordons le problème de la modélisation multidimensionnelle
des données complexes à travers le cas des données médicales du projet MAP (Médecine
d'anticipation personnalisée). Nous proposons un méta modèle multidimensionnel étendu pour
les données médicales en généralisant le modèle cardiovasculaire du projet MAP. Enfin, nous
avons spécifié et réalisé un outil d’aide à la conception d’entrepôt de données médicales.
Abstract :
2
1. Introduction
L’intérêt pour l’analyse de données s’est développé énormément ces dernières années.
Les entreprises se sont rendues compte de l’efficacité de la technologie OLAP1 (OnLine
Analytical Processing) dans l’analyse et l’exploration des données. Cette technologie est
utilisée dans les systèmes d’aide à la décision. Ces systèmes sont basés sur des techniques
d’entreposage de données pour exploiter la grande masse d’informations disponibles dans les
entreprises à des fins d’analyse et d’aide à la décision.
La manière la plus appropriée pour faciliter cette analyse OLAP est la modélisation
multidimensionnelle des données. Cette dernière représente les données comme des points
dans un espace multidimensionnel [20, 21]. Les données sont vues comme des sujets
d’analyse (les faits) étudiés selon plusieurs axes (les dimensions). Chaque dimension est liée à
un ou plusieurs points de vues définissant ainsi le degré de granularité des données
(hiérarchies).
Contrairement aux modèles relationnels, entité/association ou orienté-objet, les
modèles multidimensionnels sont les plus appropriés pour faire l’analyse et faciliter la prise
de décision dans les entreprises. Ils permettent d’observer des faits à travers des indicateurs
(mesures) et des dimensions. Autrement dit, le modèle multidimensionnel se compose de faits
contenant les mesures à analyser et de dimensions contenant les paramètres de l'analyse.
La modélisation multidimensionnelle est donc une technique qui vise à organiser les
données de telle sorte que les applications OLAP soient performantes et efficaces. Cependant,
cette technique n’est pas adaptée à un certain type de données, dites complexes.
Depuis quelques années, la nécessité de gérer et de traiter ce type de données n’a cessé
de s’accentuer à cause de la variété de ces données (texte, image, son, vidéo, etc.). Cette
variété de données met clairement en évidence la nécessité de créer de nouveaux modèles
multidimensionnels pour ces nouveaux types de données qui sont qualifiées de complexes.
C’est dans ce contexte que doit être repensée la modélisation multidimensionnelle.
Les modèles existants, tel que le schéma en étoile, le schéma en constellation ou le
schéma en flocon de neige, ont été conçus afin de rendre les données d’un entrepôt prêtes à
l’analyse. Ces modèles offrent un cadre agréable pour faire la modélisation
multidimensionnelle des données simples, mais ils ne sont pas adaptés aux données
complexes.
Notre travail de recherche s'inscrit dans le cadre des travaux menés au laboratoire
ERIC (Equipe de Recherche en Ingénierie des Connaissances) et plus particulièrement au
sein du pôle BDD (Bases de Données Décisionnelles). Ce pôle travaille sur l’élaboration des
solutions permettant l’exploration des données complexes et s’intéresse plus particulièrement
au processus d’entreposage de ce type de données.
Le présent travail s’insère dans la continuité de ces travaux. Il vise à apporter des
solutions aux problèmes de la modélisation multidimensionnelle de données complexes, en
l’occurrence les données médicales du projet MAP (Médecine d'anticipation personnalisée).
L’entrepôt MAP est formé de plusieurs magasins interconnectés partageant les mêmes
données sur les patients, les laboratoires, les médecins, etc. Chaque magasin contient
également d’autres données de natures différentes (biologiques, biométriques,
cardiovasculaires, psychologiques, etc.).
1
OLAP: OnLine Analytical Processing, ce sont en fait les technologies utilisées pour faire l’analyse de données
multidimensionnelle stockées au sein d’un entrepôt
3
Notre objectif est de proposer un modèle multidimensionnel pour ces données
médicales, plus particulièrement pour les données du module cardiovasculaires, et de
généraliser ce modèle vers un méta modèle pour l’entrepôt de données médicales. Le rôle de
cet entrepôt est d’intégrer et de stocker toute information utile aux médecins MAP et de
conserver l’historique des données médicales pour supporter les analyses effectuées
nécessaire aux prises de décision.
Ce rapport est organisé de la manière suivante : nous étudions les principaux travaux
traitant la modélisation multidimensionnelle des données et plus précisément les données
complexes dans la section 2. La section 3 présente quelques définitions des concepts utilisés
dans le domaine de la modélisation de données et présente aussi une définition de données
complexes. La section 4 présente le contexte, les objectifs de ce travail et les motivations pour
proposer un nouveau modèle du module cardiovasculaire.
Notre démarche de modélisation est décrite dans la section 5. Elle consiste, dans un
premier temps, à proposer le nouveau modèle multidimensionnel du module cardiovasculaire.
Ce dernier modèle sera généralisé en un méta modèle qui prend en charge tous les types de
données du projet MAP.
La section 6 décrit une implémentation possible de ce méta modèle dans une base de
données relationnelle ainsi que la manière de l’instancier pour définir les autres magasins de
données du projet MAP. La dernière section conclut ce travail et présente quelques
perspectives d’utilisation et de recherche ouvertes par ce méta modèle.
2. Etat de l’art
De nombreux travaux ont étudié la modélisation multidimensionnelle. Certains
proposent des langages algébriques pour faciliter l’interrogation et la manipulation des
données de l’entrepôt [2, 3, 4, 5, 6,11]. Ces modèles peuvent être classés en trois niveaux [25,
26] :
•
Au niveau conceptuel, on trouve des modèles proches de l’utilisateur et indépendants
de l’implémentation. Golfarelli et al. présentent un modèle conceptuel graphique pour
l’entreposage de données [19]. Trujillo et al. décrivent un modèle conceptuel orienté
objet basé sur UML [17]. Franconi et al. proposent un modèle conceptuel des
entrepôts de données basé sur la logique de description (langage de représentation) qui
permet de décrire les concepts de ce modèle [12].
•
Au niveau logique, les modèles dépendent du SGBD, (Système de Gestion des Bases
de Données) utilisé dans l’implémentation, mais restent compréhensibles pour les
utilisateurs finaux. Kimball résume les travaux de recherche traitant ce niveau [20]. Il
décrit aussi l’implémentation des modèles multidimensionnels dans des bases de
données relationnelles. Vassiliadis et al. donnent une vue générale des modèles
logiques pour les bases de données OLAP [21].
•
Au niveau physique, les modèles dépendant du SGBD spécifique utilisé sont conçus
pour décrire la manière dont les données seront stockées. Ils expliquent
l'implémentation des cubes de données. Luján-Mora et al. utilisent le diagramme de
composant et le diagramme de déploiement d’UML [UML] pour modéliser la
structure physique des entrepôts de données [13].
Ces différentes propositions sont parfaitement adaptées aux applications de données
classiques, mais ne répondent pas complètement aux exigences des applications à base de
données complexes telles que les applications médicales.
4
La majorité de ces travaux ne prennent pas en compte les objets à structure complexes.
Cependant, Olivier Teste a spécifié dans [4] [22] [24], des modèles de représentation et des
langages de manipulation qui sont dédiés aux entrepôts et magasins de données complexes et
évolutives et qui sont basés sur le paradigme objet. Il a intégré par ailleurs dans son modèle
la dimension temporelle afin de conserver l'évolution des données de manière pertinente.
Wan et Zeitouni [10] proposent un modèle multidimensionnel, pour un autre type de
données complexes (les objets mobiles), qui considère le temps et l’espace comme des
dimensions importantes dans leur analyse multidimensionnelle.
Tanasescu et al. ont conçu un modèle UML générique basé sur un modèle général [14,
DBB02], pour mieux identifier et représenter tous les types des données complexes pour
qu’elles soient prêtes au processus de modélisation multidimensionnelle. Dans le même
article, l’auteur a proposé l’utilisation des techniques de fouille de données permettent
l'extraction les caractéristiques des données complexes en vue de leur modélisation
multidimensionnelle.
Les efforts de modélisation des données spatiales, considérées comme un autre type de
données complexes, se concentrent sur la représentation arbitraire des objets géométriques
(points, lignes, polygones, etc.) dans un espace multidimensionnel [16]. La technologie
SOLAP [15] est basée sur une structure multidimensionnelle pour supporter l’analyse spatiotemporelle. Miquel et al. proposent des solutions pour concevoir ces structures lorsque les
sources de données sont hétérogènes des points de vue temporel, spatial et sémantique [9].
Ces structures sont ensuite explorées dans l’environnement SOLAP.
D'autres auteurs, comme Zghal et al. se sont intéressés aux problèmes de la
modélisation multidimensionnelle des données spatiales en se basant sur le développement de
l’entrepôt spatial [8].
Dans le domaine médical, Pederson et Jensen proposent un modèle multidimensionnel
intégrant des données temporelles et imprécises pour la gestion des patients de l’hôpital [6].
Ils ont résolu les problèmes de validité et d’incertitude des données respectivement par
l’ajout, au modèle, du temps de validité et de probabilité.
Dans [JMP] les mêmes auteurs proposent des solutions d’intégration des documents
XML et des données relationnelles dans une base de données multidimensionnelle en vue de
leur analyse OLAP.
Les auteurs s’intéressent à l’aide à la décision dans le domaine médical [5], ils
proposent un modèle de données étendu pour les bases de données multidimensionnelles qui
améliore l’analyse, le suivi et le contrôle des dépenses de santé, de l’activité des médecins et
du comportement consommateur des patients. Cependant ces études se limitent aux données
au dossier du patient et ne traitent pas la complexité des données médicales.
Peu de recherches s’intéressent à la modélisation multidimensionnelle des données
médicales. Ces travaux se révèlent inadaptés à notre contexte de travail car ils ne prennent pas
en compte le problème de l’hétérogénéité des données médicales.
3. Modélisation multidimensionnelle des données complexes
Dans cette section nous allons définir, dans un premier temps, les concepts généraux
utilisés dans le domaine de la modélisation multidimensionnelle. Nous commençons par une
définition de la modélisation multidimensionnelle, ensuite nous présentons une définition des
données complexes et enfin la modélisation multidimensionnelle de ce type de données.
5
3.1. Modélisation multidimensionnelle
Pour mieux définir la modélisation multidimensionnelle et ses concepts, on doit
répondre aux questions suivantes : Qu’est ce qu’un modèle ? Quelle est la différence entre les
systèmes transactionnels et les systèmes décisionnels ?
"Un modèle est la représentation d’un objet, d’un système ou d’une idée sous forme
quelconque autre celle de l’entité représentée elle-même. Sa fonction est d'aider à expliquer, à
comprendre ou à améliorer un système" [Sha 75].
Le modèle de données est le cœur d’un système décisionnel. Toutes les expériences
ont montré que la modélisation d’un système décisionnel nécessitait des approches
spécifiques différentes des approches utilisées dans les systèmes transactionnels. En effet, les
techniques couramment utilisées pour modéliser les données ont initialement été conçues pour
qu’elles s’adaptent à des problématiques qui n’ont pas lieu d’être dans le cadre de la mise en
œuvre d’un système décisionnel.
L’une des différences importantes entre les systèmes classiques (systèmes
transactionnels) et les systèmes décisionnels (entrepôt de données) est l’organisation des
données dans le système, ou plus simplement, le modèle de données. Un modèle
dimensionnel contient les mêmes informations qu’un modèle Entité/Relation, mais présente
les données dans un format symétrique plus approprié pour faire l’analyse de données.
La modélisation dimensionnelle est une approche dédiée aux systèmes décisionnels.
Elle part du principe que l’objectif majeur de ce type de système est l’analyse de la ventilation
de données quantitatives (les faits) par rapport à des données qualifiantes (les dimensions)
[Fra 00].
Chaque modèle dimensionnel se compose d’une table contenant une clé multiple, la
table des faits, et d’un ensemble de tables plus petites nommées tables dimensionnelles :
-
La table des faits est la table principale de tout modèle dimensionnel destiné à
héberger des données permettant de mesurer l’activité (les mesures). Chacune de
ces mesures est prise à l’intersection avec toutes les dimensions.
-
Une table dimensionnelle appartient à un ensemble de table accompagnant une
table de faits. Chaque dimension est définie par sa clé primaire qui assure
l’intégrité référentielle avec la ou les tables de faits à laquelle elle est liée. Les
tables de dimension servent à enregistrer les descriptions textuelles des dimensions
de l’activité.
Exemple : Considérons les données suivantes.
Ventes en 1999.
Maintenant, nous considérons plusieurs tables, relatives aux ventes de chaque année
entre 1999 et 2002. On peut alors observer les données dans un espace à trois dimensions : la
6
dimension catégorie, la dimension produits et la dimension temps. Chaque intersection de ces
dimensions représente une cellule comportant le montant des ventes.
Figure 1 : Représentation multidimensionnelle
La figure 2 décrit le schéma en étoile modélisant les analyses des quantités et des
montants des médicaments dans les pharmacies selon trois dimensions : le temps, la catégorie
et la situation géographique.
Figure 2 : Schéma en étoile
3.2. Données complexes
La description des données complexes nécessite une certaine précision et un espace de
représentation adapté. A ce jour, il n’existe pas de modèle universel pour toutes les formes de
données complexes. Une définition des données complexes (figure 3) est donnée dans [ICEIS
05] où les données sont qualifiées de complexes si elles sont:
•
multiformats : l'information est représentée sous différents formats (base de données,
données numériques, symboliques, textes, images, sons, vidéos...) ;
et/ou
•
multistructures : les données peuvent être structurées, non structurées ou semistructurées (bases de données relationnelles, collection de documents XML...);
et/ou
7
•
multisources : les données proviennent de différents origines (bases de données
réparties, web...) ;
et/ou
•
multimodales : un même phénomène est décrit par plusieurs canaux ou points de vue
(radiographies et diagnostic audio d'un médecin pour évaluer l'état de santé d’un
patient, données exprimées dans des échelles ou des langues différentes...) ;
et/ou
•
multiversions : les données sont évolutives en termes de définition ou de valeur (bases
de données temporelles, recensements périodiques dont les critères évoluent...).
Figure 3 : Les données complexes
3.3. Modélisation multidimensionnelle des données complexes
Nous avons vu jusqu'à maintenant la définition de la modélisation dimensionnelle et la
définition des données complexes. Une nouvelle question se pose alors : les techniques de la
modélisation dimensionnelle classique doivent-elles être conservées telles quelles, doiventelles être adaptées au contexte des données complexes ou totalement repensées ?
Les bases de données et les entrepôts de données utilisent, à ce jour, des techniques
d’analyse qui traitent seulement des données simples comme les chaînes de caractères, les
nombres, etc. Les données multimédia qui sont un exemple des données complexes
engendrent plus d’informations nécessaires à l’analyse de données.
L’intégration et la structuration des données complexes dans une base de données
classique ont déjà été réalisées [DBB02]. Ces structures permettent la gestion et la
consultation des données mais elles ne sont pas appropriées à l’analyse des données. Le plus
souvent, les données complexes sont stockées dans les bases de données pour qu’elles soient
retrouvées plus facilement.
8
Les SGBD (les Systèmes de Gestion de Bases de Données) existant ne permettent pas
de traiter les données complexes. Cependant, ces SGBD offrent des solutions pour permettre
la gestion des données multimédia, il s’agit de stocker les données complexes d’origine dans
des BLOB2 avec leurs descripteurs. Mais, si on veut analyser ces données complexes on est
amené à les intégrer dans des bases de données multidimensionnelles qui sont des structures
plus appropriées pour l’analyse de données.
4. Contexte et objectifs
Notre travail de recherche s’inscrit dans le projet MAP (Médecine d’Anticipation
Personnalisée). Il s’agit d’apporter des solutions aux problèmes posées par la modélisation
multidimensionnelle des données médicales. Les modèles existants tels que les modèles en
étoile ou en constellation sont inadaptés aux données médicales du projet MAP. Pour cela, le
but de ce stage est de proposer un modèle multidimensionnel qui permettra de traiter et
d’analyser ce type de données complexes.
Dans cette section, nous présentons le projet MAP le contexte général de notre travail,
et nous nous intéressons plus particulièrement au magasin cardiovasculaire du projet MAP.
4.1. Le projet MAP
Le projet MAP est le fruit d’une collaboration entre le laboratoire ERIC et le docteur
Ferret, médecin du sport et porteur d’un projet de création d’entreprise accueilli au sein de
l’incubateur CREALYS. Ce projet est financé pour moitié par l’université Lyon 2 et pour
moitié par la région Rhône-Alpes. L’objectif est d’étendre les résultats et avancées empiriques
développés pour les sportifs de haut niveau à d’autres populations et de faire en sorte que les
sujets analysés deviennent les gestionnaires de leur capital santé. Ce travail est fondé sur la
structuration, le stockage et l’analyse d’un ensemble de données médicales complexes
(qualitatives, numériques, textes, images…) concernant un grand ensemble de personnes.
L’entrepôt de données médicales MAP est organisé sous forme d’une collection de
magasins de données (DataMarts). Chaque magasin contient les données spécifiques, à une
spécialité médicale (par exemple, les données des analyses biologiques, les données
biométriques, les données cardiovasculaires, etc.) et est défini par un ensemble de faits et de
dimensions partagées avec d’autres magasins de données.
Une modélisation multidimensionnelle du magasin biologique et du magasin
biométrique a été réalisée dans [MAP 03]. Les données de ces deux modules étaient
essentiellement textuelles ou numériques. Par contre, les données du magasin cardiovasculaire
[MAP 04] sont plus complexes, ce magasin contient en plus des données textuelles et
numériques, des images, des vidéos et des conclusions écrites.
Suite aux problèmes rencontrés lors de la modélisation multidimensionnelle du
magasin cardiovasculaire et à cause de la variété et la complexité des données, nous allons
nous intéresser plus particulièrement au module cardiovasculaire, tout en essayant de
généraliser cette solution aux autres magasins du projet MAP.
4.2. Le magasin cardiovasculaire
Le magasin cardiovasculaire est un magasin particulier de l’entrepôt MAP. Il contient
principalement les différentes données provenant des différents appareils médicaux, les
2
BLOB (Binary Large OBject), C'est en général une image ou une séquence sonore sans grande structure
interne, qu'on trouve fréquemment dans une base de données. La taille d'un Blob peut aller jusqu'à plusieurs Go.
9
résultats cardiovasculaires des individus et toute autre information utile, et qui peuvent
apporter une aide au diagnostic médical. Ces données sont qualifiées de complexes à cause de
leur hétérogénéité et de la diversité de leur format.
Notre but est d’intégrer ces données dans une structure dimensionnelle pour apporter
au médecin MAP l’aide à la décision afin d’émettre un diagnostic précis sur un individu
donné.
Un des objectifs de ce magasin est de conserver tout type de document, les documents
conservés servent à la vérification en cas de doute ou pour établir de nouveaux diagnostiques.
Les valeurs numériques sont aussi conservées, dont certaines sont issues directement des
documents.
En plus des documents multimédia, on trouve les rapports détaillés rédigés par le
médecin MAP, qui contiennent les résultats, les remarques et la conclusion sur un examen
particulier effectué par un individu à une date donnée.
Les examens cardiovasculaires sont classés en plusieurs types, ces types sont à leur
tour classés en familles d’examen. Un type d’examen peut contenir une ou plusieurs analyses
médicales. Un individu peut effectuer un type d’examen à une date donnée.
Il existe quatre types d’examens dans ce magasin :
-
L’échocardiogramme produit des vidéos, des images, des valeurs numériques et
des conclusions écrites,
-
L’électrocardiogramme produit des tracés dont la nature numérique reste flou à
l’heure actuelle,
-
L’examen clinique cardiologique est un compte rendu qui contient des valeurs
numériques et des commentaires écrits,
-
Le test d’effort contient des valeurs numériques.
5. Notre démarche de modélisation
Notre démarche de modélisation est incrémentale. A partir d’un modèle existant, nous
procédons à construire un nouveau modèle multidimensionnel, Cardio-M, qui résout les
problèmes rencontrés dans l’ancien modèle. Ensuite, nous créons un méta modèle qui
généralise le modèle Cardio-M pour pouvoir modéliser les autres magasins de données du
projet MAP.
En d’autres termes, l’idée derrière cette démarche est de modéliser le module le plus
complexe dans l’entrepôt médical MAP afin d’extraire les différents concepts qui vont
permettre de créer un méta modèle générique pour générer les autres modules de l’entrepôt
MAP.
La figure 4 présente notre approche de modélisation qui se base sur le modèle existant
afin de l’améliorer pour proposer un méta modèle générique. Nous détaillons dans la suite
chaque étape de notre approche en expliquant nos motivations pour effectuer le passage entre
chaque deux étapes différentes de notre démarche.
10
Figure 4 : La démarche de modélisation
5.1. Le magasin cardiovasculaire : existant
La figure 5 montre le modèle existant du magasin cardiovasculaire, c’est le premier
essai pour intégrer le magasin cardiovasculaire dans l’entrepôt MAP.
Ce modèle nous donne une vue générale sur le magasin cardiovasculaire. Il contient
les différentes analyses médicales, les différents résultats et les conclusions des examens
cardiovasculaires.
Figure 5 : Le modèle multidimensionnel du module Cardiovasculaire [MAP04]
11
La première remarque que l’on peut faire sur ce modèle est qu’il n’a pas une hiérarchie
de temps, en d’autres termes, il n’a pas exprimé les différents niveaux hiérarchiques de cette
dimension importante. La dimension temporelle est présente dans tous les magasins de
données de notre entrepôt MAP. Elle doit faire l’objet d’une attention toute particulière lors
de la modélisation des données.
Pour cela, nous proposons de hiérarchiser la dimension du temps en quatre niveaux :
Heure, Jour, Mois et Année. Le premier niveau (Heure) contient une clé primaire l’Heure et le
deuxième niveau contient le Jour comme clé primaire pour permettre d’effectuer plusieurs
examens et analyses dans la même journée. Les clés primaires des deux autres niveaux, Mois
et Année, sont respectivement le mois et l’année.
Le centre et le point d’entrée dans le modèle est la table de fait Compte_Rendu qui
contient la conclusion sur les analyses médicales effectuées pour un individu donnée. Le
problème est que ce compte rendu est le rapport final d’un processus médical, il dépend du
diagnostic du médecin sur les différentes analyses et examens médicaux. Le compte rendu est
la conclusion générale du médecin sur un examen donné. Pour éviter cet abus de langage,
nous préférons utiliser le concept Examen, qui sera le fait à analyser de notre modèle, à la
place du Compte_rendu qui sera inclus dans la conclusion de l’examen.
Une autre remarque sur ce modèle est la relation plusieurs à plusieurs entre la table de
faits Examen et la dimension Document_Cardio qui pose un problème de conception dans le
modèle dimensionnel. Le problème est que la dimension Document_Cardio peut prendre
zéro, un ou plusieurs valeurs pour un même enregistrement de la table de fait. En plus ces
différentes valeurs n’ont pas la même importance médicale sur laquelle se base le médecin
pour effectuer un examen donné. Pour gérer cette dimension, nous proposons d’ajouter une
table intermédiaire Groupe_Doc entre la table de fait et la dimension, comme le montre la
figure 4, qui regroupent l’ensemble de documents cardiologiques. La table Groupe_Doc, qui
est notre table intermédiaire, contient un groupe de documents pour chaque examen.
La dernière remarque concerne les dimensions du modèle, la dimension
Document_Cardio contient les documents multimédia, son rôle dans l’entrepôt MAP est
seulement le stockage de ces documents importants. A l’heure actuelle, ce type de dimension
ne peut pas faire l’objet d’une analyse OLAP. Nous proposons dans la suite une classification
des différentes dimensions de l’entrepôt MAP.
Partant des différentes solutions apportées aux différents problèmes décrits ci-dessus,
nous proposons un nouveau modèle multidimensionnel du module cardiovasculaire détaillé
dans la section suivante.
5.2. Nouveau modèle multidimensionnel du magasin cardiovasculaire
L’analyse du module cardiovasculaire a permis d’observer deux sujets d’analyses
importants, les résultats des analyses et la conclusion du médecin sur ces résultats, qui sont
étudiés selon plusieurs axes d’analyse : Individu, Type d’Examen, Analyse, Temps, Médecin,
Machine ou Document.
Comme une première étape pour modéliser les données cardiovasculaires, nous avons
utilisé un schéma en étoile. Nous avons mis les deux mesures dans une seule table de fait,
cette table est lié à toutes les dimensions mentionnées au-dessus.
Le problème dans cette première tentative est qu’on a deux mesures qui ne dépendent
pas totalement des mêmes dimensions, ce qui nous a amené à utiliser dans la deuxième étape
12
le modèle en constellation. Par conséquent, nous avons mis les deux mesures dans deux tables
de faits séparées et entourées chacune de ces dernières par les dimensions appropriées.
Cette solution n’est pas adaptée à nos faits qui dépendent l’un de l’autre, on ne peut
pas analyser l’un sans avoir l’autre, ce qui explique nos motivations pour faire le lien entre
les deux tables de faits. Les deux mesures ont un degré de granularité différent qui est
exprimé par le lien hiérarchique existant entre les tables de faits.
Laboratoire
- Id Labo
- Nom Labo
0..1
*
Médecin
Document Cardio
1..1
- Id Doc
-
Groupe Doc
*
- Id Groupe
1..1
Famille Exam
Id Médecin
Nom
Prenom
Spécialité
- Id Famille
- Famille Exam
0..1
1..1
*
*
Examen
Individu
- Id Individu
- Nom
- Prenom
*
1..1
-
Id Individu
Id Type
Id Médecin
Id Groupe
Id Temps
Id Machine
Conclusion
Normal
*
Année
- Année
*
1..1
Mois
Jour
*
- Mois
1..1
*
- Jour
1..1
*
Type Exam
*
1..1
0..1
*
1..1
Heure
- Heure
- Id Type
- Type Examen
Machine
- Id Machine
- Nom
1..1
1..1
1..1
*
*
*
Résultat_Exam
-
Id Examen
Id Analyse
Id Temps
Valeur
Analyse
*
1..1
- Id Analyse
- Nom
- Nom Alternatif
Figure 6 : Le nouveau modèle Cardiovasculaire
13
Les dimensions du modèle et leurs niveaux hiérarchiques sont :
-
Individu : cette dimension est commune avec les autres magasins de données, elle
contient les informations sur le patient concerné par les examens cardiovasculaires.
-
Temps : c’est une autre dimension commune avec les autres magasins de données,
elle sert à stocker la date de l’enregistrement concerné, elle est exprimée par une
hiérarchie à trois niveaux : Heure Jour Mois Année.
-
Classification Analyse : elle contient trois niveaux hiérarchiques :
Type examen : contient les différents types d’examens cardiovasculaires
(l’échocardiogramme, l’électrocardiogramme, l’examen clinique général et
le test d’effort).
Famille examen : dans notre cas, ce niveau contient seulement la valeur
« cardiovasculaire », c’est un niveau commun avec les autres magasins de
données de l’entrepôt MAP.
Analyse : ce sont les différentes analyses cardiovasculaires effectués par un
individu dans un certain type d’examen, par exemple Echographie contient
les analyses suivantes : Gradient Valvulaire, Fraction Ejection, Gradient
Mitral, Diamètre Aortique, …
-
Personnel Médical : cette dimension est composée de deux niveaux:
Médecin : c’est le médecin responsable
cardiovasculaire pour un individu donné.
d’effectuer
l’examen
Laboratoire : c’est l’organisme dans lequel l’individu passe son examen.
-
Machine : est l’ensemble des appareils médicaux qui permet de réaliser les
différents examens cardiovasculaires et qui permet d’exporter les différents
résultats médicaux.
-
Document Cardio : contient les différents documents médicaux sur lesquels se
base le médecin pour faire les examens.
Les données de la table de faits Examen sont analysées selon six dimensions (Individu,
Type Examen, Temps, Médecin, Machine et Document), tandis que la table de fait Résultat
Examen est vue selon trois axes d’analyses (Examen, Temps et Analyse).
La première remarque que l’on peut faire sur ce modèle (figure 6) est qu’on a un
modèle en constellation mais un peu spécial, on a deux tables de faits qui sont liées entre elles
avec un lien hiérarchique. Ce nouveau concept, le lien hiérarchique entre les deux tables de
faits, est justifié par le niveau de granularité différent entre ces deux tables. Celle de niveau
haut (Examen) joue un double rôle dans ce modèle, elle est considéré comme une table de fait
par rapport aux dimensions qui sont autour d’elle et elle joue le rôle de dimension par rapport
à la table de fait de niveau de granularité plus bas (Résultat Exam). Dans notre cas, l’examen
contient les résultats agrégés des résultats d’examen.
La table de fait Examen contient deux mesures (Normale et Conclusion), la mesure
Normale peut avoir deux valeurs (“oui” ou “non”) qui contiendra la réponse à la question :
“le patient a-t-il déjà eu une alerte cardiovasculaire ?”, et la mesure Conclusion contient la
conclusion du médecin sur un examen donné.
L’autre table de fait (Résultat Exam), qui contient les résultats des analyses passées
dans un examen donné, est liée à la première table de fait par un lien hiérarchique. Dans la
14
première table, Examen, on trouve les valeurs globales et génériques, et dans la deuxième on a
le détail de ces valeurs. En d’autre terme, un enregistrement de la table de fait Examen est
équivalent à un ensemble d’enregistrement de la table Résultats Exam, ce qui explique la
relation un à plusieurs entre ces deux tables.
Nous constatons dans la partie droite du modèle une hiérarchie liée à la dimension
Analyse qu’elle est liée à la table de fait Résultats Exam. Cette dimension est hiérarchisée en
type d’examen qui est à leur tour agrégée en famille d’examen. Cette hiérarchie (Type_Exam
– Famille-Exam) permet de prendre en compte les différents types d’examens du projet MAP
(biologiques, biométriques, cardiovasculaires,…), elle est commune avec les autres modules
du projet MAP.
Passons maintenant aux dimensions du modèle, pendant la modélisation du module
cardiovasculaire, on a constaté qu’il y a un autre type de dimension, en plus des dimensions
classiques et temporelles qui représentent des axes d’analyse, ce sont les dimensions
multimédia qui vont contenir tous les fichiers sources médicales. On ne peut pas appliquer
l’analyse OLAP sur ce type dimension mais elles vont servir comme un axe de vérification et
de révision pour le médecin en cas de doute. Introduire ce type de dimensions dans les
modèles multidimensionnels nécessite des méthodes pour construire un cube de données avec
ce type de dimensions. Les trois types de dimensions seront détaillés un peu plus dans la
section suivante.
5.3. Le métamodèle
Afin de modéliser l’entrepôt de données médicales MAP, c’est à dire la collection de
magasins de données, nous proposons un métamodèle orienté objet (figure 7) permettant de
créer les différents magasins de données du projet MAP. Ce métamodèle est une
généralisation du modèle cardiovasculaire décrit auparavant avec la prise en compte des faits
complexes et les nouveaux concepts définis lors de la modélisation multidimensionnelle du
magasin cardiovasculaire.
Peu de travaux proposent des méta modèles multidimensionnels [8, YAM, CWM],
l’objectif de ces travaux est de spécifier des méta modèles pour représenter les bases de
données multidimensionnelles.
Par exemple les auteurs dans [8] ont spécifié un méta modèle pour la construction d’un
entrepôt de données spatiales. Aussi un autre méta modèle multidimensionnel proposé par
Abelló [YAM]. Il s’est basé sur le langage UML pour donner un plus de sémantique en
profitant des concepts objets tel que les relations de généralisation et de composition.
Cependant ces travaux ne sont pas suffisants et ne sont pas adaptés pour représenter les
concepts multidimensionnels comme nous souhaitons le faire.
Notamment, le standard de l’OMG (Object Management Group), CWM3 (Common
Warehouse MetaModel) qui propose un ensemble de méta modèles pour les techniques
d’entrepôt de données. Cet ensemble CWM est assez complet pour modéliser un entrepôt de
données dans son ensemble. Mais le métamodèle multidimensionnel proposé par CWM
représente les aspects multidimensionnels d’une façon générale, il ne contient pas tous les
objets d’une base de données multidimensionnelle. Il faut le combiner avec d’autres
métamodèles du même standard pour avoir une représentation plus complète. Nous avons
essayé de prendre en compte, dans un seul métamodèle, tous les composants d’une base de
données multidimensionnelle.
3
Voir en annexe A: Common Warehouse Metamodel (CWM)
15
En plus le métamodèle CWM ne permet pas de spécifier et de représenter les
nouveaux concepts multidimensionnels que nous avons proposé. Notre méta modèle présenté
dans la suite constitue une extension de ces trois derniers travaux qui soit applicable aux
données médicales.
La figure 7 montre une représentation UML du méta modèle, ce qui va nous permettre
de mieux représenter les concepts multidimensionnels génériques (Dimensions, Faits,
Mesures) et les autres concepts extraits de notre étude du module cardiovasculaire (le lien
entre les tables de fait, les différents types de dimensions).
EDM : Entrepôt de données Medical
EDM
MDM : Magasin de données Medical
- Nom EDM
- Description EDM
1..1
*
MDM
Hiérarchie Fait
Dim Classique
- Id MDM
- Nom MDM
- Description MDM
- Type Lien
1..*
1..1
Rec
0..*
0..1
1..*
T_Fait
0..*
Dimensions
- Id T_Fait
- Nom T_Fait
- Description T_Fait
1..*
Ass
1..*
-
Id Dim
Nom Dim
Type Dim
Description Dim
Dim Temporelle
1..1
1..1
1..*
Niveaux
-
Id Niveau
Nom Niveau
Ordre Niveau
Description Niveau
Dim Multimédia
1..1
1..*
1..*
Mesures
Paramètres
Attributs
- Id Attribut
- Nom Attribut
- Type Attribut
Figure 7 : Le Méta Modèle
16
L’instanciation de ce méta modèle va nous permettre de créer les différents magasins
de données dans l’entrepôt médical du projet MAP. Ce dernier, qui est représenté par la classe
EDM, est composé d’un ensemble de magasins de données représenté par la classe MDM.
Chaque magasin (MDM) est caractérisé par un ensemble de faits, qui représentent les
sujets d’analyses, et un ensemble de dimensions, qui représentent les axes d’analyse. A
chaque fait correspond une ou plusieurs mesures et à chaque dimension correspond un
ensemble de paramètres. Ces deux derniers concepts (Mesures et Paramètres) héritent de la
même classe Attribut mais ils ont une sémantique différente dans les bases de données
multidimensionnelles.
Les faits complexes sont caractérisés par la relation récursive Rec qui permet
d’associer à chaque table de fait une autre table de faits, cette relation permet d’exprimer
l’hiérarchie des tables de faits.
L’hiérarchie de dimensions est matérialisée par les deux classes Dimension et Niveaux,
on associé à chaque niveau son ordre hiérarchique dans la dimension. Par exemple, l’ordre du
niveau Heure de la dimension Temps est égal à zéro et l’ordre de Jour égal à un (figure 4).
Nous définissons les principales classes de notre méta modèle comme suit :
•
Entrepôt de données
Notre entrepôt de données est matérialisé par la classe EDM (Entrepôt de Données
Médicales), cette classe est le conteneur global de toutes les classes du méta modèle. La
classe EDM est définie par (NEDM, DesEDM) où
•
•
NEDM est le nom de l’entrepôt de données,
•
DesEDM est la description de l’entrepôt.
Magasin de données
C’est un entrepôt de données spécialisé, destiné à ne contenir que les informations
élaborées pour un objectif particulier. Par exemple le magasin cardiovasculaire contient
seulement les données cardiovasculaires. Le magasin de données est représenté par la
classe MDM (Magasin de Données Médicales), qui est définie par le quadruplet (NMDM,
FMDM, DMDM, Ass) où
•
•
NMDM est le nom du magasin de données,
•
FMDM = {F1, F2, ….} est l’ensemble des faits,
•
DMDM = {D1, D2, ….} est l’ensemble des dimensions,
•
Ass est la fonction qui va associer chaque fait avec ses dimensions.
La table de faits
Une table de fait est la table centrale du modèle multidimensionnel. Elle contient les
différentes mesures de l’activité à analyser, ces mesures peuvent être observées selon
différentes dimensions. Cette classe est définie par le triplet (NF, MF, Rec) où
•
NF est le nom du fait,
•
MF = {m1, m2, ….} est l’ensemble des mesures,
•
Rec est la fonction récursive qui va associer un fait avec un autre fait pour
permettre l’hiérarchisation des faits.
17
•
La dimension
Une dimension est un axe d'analyse au sein d'une structure multidimensionnelle. Elle
est composée d'une liste ordonnée de paramètres (attributs) qui partagent une signification
sémantique commune dans le domaine modélisé. Elle est définie par le quadruplet (NDim,
PDim, HDim, TDim) où
•
NDim est le nom de la dimension,
•
PDim = {p1, p2, …} est l’ensemble des paramètres,
•
HDim = {H1, H2, ….} est l’ensemble des niveaux formant les hiérarchies de
cette dimension,
•
TDim = {Classique, Temporelle, Multimédia} est le type de la dimension.
Nous distinguons trois types de dimensions dans notre modèle : les dimensions
classiques, les dimensions temporelles et les dimensions multimédia.
La dimension classique
Les dimensions servent à enregistrer les valeurs pour lesquelles sont analysées les
mesures de l'activité. Une dimension est généralement formée de paramètres (attributs)
textuels (pour restreindre la portée des requêtes) et discrets (les valeurs possibles sont bien
déterminées et constantes) [20]. Les paramètres d'une dimension sont organisés en hiérarchies
de la granularité la plus fine vers la granularité maximale.
La dimension temporelle
La dimension temporelle joue un rôle primordial dans les modèles dimensionnels, elle
est présente dans tous les magasins de données de notre entrepôt MAP. La dimension
temporelle s’ajoute à l’entrepôt pour maintenir l’historique de l’évolution des données
médicales dans le temps. Cette dimension est généralement considérée comme une dimension
normale.
La dimension multimédia
Ce type de dimension contient les différents types de données multimédias contenues
dans notre entrepôt médical, on trouve par exemple : des électrocardiogrammes et des
échocardiogrammes. Les données de ce type de dimension sont difficiles à manipuler par les
outils d’analyses actuels, leur but dans notre entrepôt médical est l’archivage de ces données
multimédia pour faire la vérification et le contrôle, en cas de doute, des résultats d’analyses.
Par exemple, dans le module cardiovasculaire, la dimension Document contient les différents
documents multimédias utilisés dans le suivi médical d’un individu donné.
6. Prototype et Evaluation
Afin de valider notre méta modèle (décrit dans la section 5.3), nous avons développé
un prototype d’aide à la conception et la modélisation de notre entrepôt MAP, intitulé GEDM
(Générateur d’Entrepôt de Données Médicales).
Notre outil facilite la tache de l’administrateur MAP pour créer et générer des
magasins de données à fin de construire l’entrepôt global, tout en respectant nos nouveaux
concepts définis dans le méta modèle des données médicales. En effet, l’élaboration de
l’entrepôt MAP suit un processus de développement à trois niveaux : conceptuel, logique et
physique.
18
La figure 8 décrit ce processus de développement, la génération des magasins de
données passe généralement par ces trois étapes :
•
premièrement, on génère une instance du méta modèle (figure 7), cette instance
représente le modèle multidimensionnel du magasin de données en cours de
modélisation,
•
deuxièmement, on fait la transformation de ce modèle soit vers un fichier XML
ou vers une base de données relationnelle,
•
ce dernier choix va nous permettre dans la troisième étape de choisir soit un
entrepôt XML ou un entrepôt relationnel.
Instanciation
Création
Transformation
Schéma
XML
3
2
Méta
Modèle
1
4
Modèle
UML
Entrepôt de
données XML
2’
Schéma
Relationnel
3’
Niveau
Méta
Niveau
Instance
Niveau
Conceptuel
Entrepôt de
données
relationnel
Niveau
Logique
Niveau
Physique
Figure 8 : Le processus de développement
Pour des raisons techniques et à cause de la performance limitée (à notre
connaissance) vis-à-vis des entrepôts XML, nous avons opté pour la solution relationnelle. En
effet, GEDM est un prototype implanté au-dessus du SGBD Oracle version 10g. Le choix
d’un SGBD relationnel est motivé par la grande capacité de stockage ainsi la performance lors
de la manipulation des données. En effet, les systèmes de gestion de bases de données
relationnelles offrent d’excellentes performances en terme de rapidité d’accès, de volume de
stockage et de stabilité des données.
19
Le choix du SGBD Oracle version 10g est justifié par plusieurs raisons :
Oracle Database 10g est la solution idéale pour le transactionnel en ligne, l'aide a
la décision et la gestion de contenus,
c’est un produit qui combine l’analyse relationnelle (SQL) et multidimensionnelle
(OLAP) et intègre des fonctions d'extraction, transfert et chargement de contenu
(ETL),
en effet, le moteur OLAP est directement intégré dans le SGBDR avec, de ce fait,
un seul système de sécurité et de stockage et une maintenance grandement
facilitée,
il propose un gestionnaire de base de données capable de gérer dans un même
espace de stockage des données relationnelles et multidimensionnelles accessibles
à travers une interface SQL standard.
GEDM se base sur une approche incrémentale, l’administrateur MAP élabore
l’entrepôt étape par étape en construisant les différents magasins de données du projet MAP.
L’architecture de ce prototype, comme le montre la figure 9, est composée essentiellement
d’une interface utilisateur et un générateur de script.
•
L’interface utilisateur permet de définir les magasins de données MAP, en
introduisant les différents éléments (dimensions, faits,…) du schéma
dimensionnel.
•
Le générateur de script est le module responsable de la génération des scripts,
ces derniers scripts permettent la création du schéma de l’entrepôt de données
MAP dans une base de données relationnelle, en s’appuyant sur notre méta
modèle défini dans la section 5.3.
GEDM
Générateur de
script
Interface
Utilisateur
Administrateur
MAP
Oracle
Entrepôt
Figure 9 : Architecture du prototype GEDM
20
Pour montrer la cinématique de notre application et pour comprendre son
fonctionnement, nous nous intéressons encore une fois à la définition du module
cardiovasculaire à travers le prototype GEDM.
Les figures qui suivent décrivent la chronologie des principales fonctionnalités de ce
prototype. Nous définissons en premier les tables dimensionnelles et leurs propriétés qui
permettent par la suite de définir les tables de faits.
La figure 10 liste les différentes dimensions existantes dans le magasin courant en
offrant la possibilité d’ajouter, de modifier ou de supprimer une dimension.
Figure 10 : Liste des dimensions
L'administrateur MAP peut ajouter une dimension à l'entrepôt en définissant les
propriétés, les différents niveaux et les paramètres de la dimension (figure 11).
Figure 11 : Propriétés d’une dimension
21
Concernant les faits, la figure 12 illustre la liste des tables de faits. Cette interface
permet d’ajouter, de modifier ou de supprimer une table de faits.
Figure 12 : Liste des tables de faits
La figure 13 présente l’interface permettant de représenter les différents onglets de la
table de faits.
Figure 13 : Propriétés d’une table de faits
22
7. Conclusion et perspectives :
Le travail présenté dans ce mémoire traite la modélisation multidimensionnelle des
données complexes. Notre objectif est d’intégrer les données médicales du projet MAP
(Médecine d’Anticipation Personnalisée), qui se compose de plusieurs modules, dans une
structure multidimensionnelle pour apporter l’aide au processus décisionnel. Pour répondre à
cet objectif, nous avons proposé une approche de modélisation et d’implémentation de
l’entrepôt médical en se basant sur un méta modèle que nous avons développé.
Dans un premier temps, nous avons modélisé le module le plus complexe du projet
MAP, le module cardiovasculaire. Pendant cette modélisation, nous avons constaté la
difficulté de modéliser et d’intégrer les données médicales telles que les données
cardiovasculaires dans une structure multidimensionnelle. Par conséquent, nous avons senti le
besoin de proposer de nouveaux concepts qui étendent les modèles existants vers un nouveau
type de modèle.
Dans un second temps, nous avons proposé un méta modèle en généralisant le modèle
multidimensionnel du module cardiovasculaire. L’instanciation de ce méta modèle permet de
spécifier et de définir les différents magasins de données de l’entrepôt MAP indépendamment
des plates formes techniques.
En fin, nous avons concrétisé ce méta modèle par le développement du prototype
GEDM, acronyme de Générateur d’Entrepôt de Données Médicales. Il comporte une
interface utilisateur et un module générateur de script permettant de créer automatiquement
les différents composants de l’entrepôt de données.
Notre approche étant incrémental, à partir des retours d’usage nous essayons de faire
évoluer le prototype que nous avons réalisé afin de lui permettre une meilleure manipulation
de tous les éléments de notre entrepôt.
Nos travaux futurs se concentrent sur la généralisation du méta modèle défini en
ajoutant des nouveaux concepts afin de lui permettre de prendre en compte d’autres types de
données complexes. Ainsi l’objectif sera l’élaboration des nouveaux modèles de plus haut
niveau d’abstraction.
23
Annexe A: Common Warehouse Metamodel (CWM)
Le CWM est le standard de l’OMG pour les techniques liées aux entrepôts de données.
Il couvre le cycle de vie complet de modélisation, construction et gestion des entrepôts de
données. Le CWM définit un méta-modèle qui représente les méta-données aussi bien métiers
que techniques qui sont le plus souvent trouvées dans les entrepôts de données. Il est utilisé à
la base des échanges de méta-données entre systèmes hétérogènes.
Le CWM comprend actuellement un certain nombre de méta-modèles concernant les
entrepôts de données (représentation des données, analyse, gestion). Les méta-modèles de
données permettent de modéliser des ressources comme les bases de données relationnelles,
les bases de données orientées objets. Une couche d’analyse du CWM définit des métamodèles pour les transformations de données, OLAP, la visualisation, la nomenclature et le
data-mining. Une couche de gestion est constituée de méta-modèles représentant les processus
standards, la journalisation et la planification des activités.
Le CWM représente une démarche d’échange de méta-données entre systèmes
logiciels. Les échanges de méta-données sont formulés en terme de modèles de données qui
correspondent à un ou plusieurs méta-modèles CWM. Un logiciel exporte ses méta-données
avec un modèle de leurs structures interne dans un format du CWM. Symétriquement, un
logiciel importe des méta-données à l’aide d’un modèle CWM et les “traduit” dans son format
interne.
L’ensemble des méta-modèles du CWM est assez complet pour modéliser un entrepôt
de données dans son ensemble. Il est possible à l’aide d’outils CWM de générer une instance
d’entrepôt de données à partir de son modèle. Le schéma suivant (figure 14) présente le méta
modèle multidimensionnel de CWM.
Figure 14 : Le méta modèle multidimensionnel de CWM
24
Références bibliographiques : Je suis entrain de numéroter ces bibliographies
[YAM²] Abelló A., YAM² (Yet Another Multidimensional Model): A Multidimensional Conceptual
Model, PhD Thesis, Universitat Politècnica de Catalunya. Barcelona, April 2002.
[YAM²] Abelló A., Samos J., Saltor F., YAM² (Yet Another Multidimensional Model): An extension of
UML. In Proc. of the Int. Database Engineering and Application Symposium, pp. 172-181, 2002.
[18] Abello A., Samos J., Saltor F., Understanding Analysis Dimensions in a Multidimensional
rd
Object-Oriented Model, In 3 International Workshop on Design and Management of Data
Warehouses (DMDW). SwissLife, 2001.
[3] Agrawal R., Gupta A., Sarawagi S., Modeling Multidimensional Databases, Research Report, IBM
Almaden Research Center, San Jose (California), 1995. Parus dans les actes de ICDE'97 pages 232243.
[26] Batini C., Ceri S., Navethe S.B., Conceptual Database Design: An Entity-Relationship Approach,
Benjamin-Cummings Publishing. 1992.
[2] [Cab98] Cabibbo L., Torlone R., A Logical Approach to Multidimensional
Databases. EDBT 1998:183-197.
[DBB02] Darmont J., Boussaid O., Bentayeb F., Rabaseda S., Zellouf Y., Web multiform data
structuring for warehousing, In C. Djeraba, ed., Multimedia Mining: A Highway to Intelligent
Multimedia Documents; Multimedia Systems and Applications, Vol. 22, Kluwer, 2002, 179-194.
[ICEIS 05] Darmont J., Boussaid O., Ralaivao J., Aouiche K., An Architecture Framework for
Complex Data Warehouses, 7th International Conference on Enterprise Information Systems (ICEIS
05), Miami, USA, May 2005.
[1] Decleir C., Hacid M.S., kouloumdjian J., A Database Approach for
Modelling and Querying Video Data, IEEE International Conference on Data
Engineering (ICDE), march 1999 6-13 Sydney, Australie, pp 6-13
[25] Elmasri R., Navethe S.B., Fundamentals of database systems, Benjamin-Cummings Publishing.
3ième edition, 2000.
[12] Franconi E., Sattler U., A Data Warehouse Conceptual Data Model for Multidimensional
Aggregation. In Proceedings of the Workshop on Design and Management of Data Warehouses
(DMDW’99), 1999.
[Fra 00] Franco J.M., Lingnerolles S., Piloter l’entreprise grâce au data warehouse, Eyrolles 2000.
[19] Golfarelli M., Maio D., and Rizzi S., The Dimensional Fact Model: a Conceptual Model for Data
Warehouses, Int. Journal of Cooperative Information Systems, 1998.
[16] Guting R. H., An introduction to spatial database systems, VLDB Journal, 3(4):357– 399, 1994.
[JMP] Jensen M., Moller T., Pedersen TB., Specifying OLAP cubes on XML data, Journal Of
Intelligent Information Systems, 17(2/3):255--280, 2001.
25
[20] Kimball R., The Data Warehouse Toolkit: Practical techniques for building dimensional data
warehouses. John Wiley. 1996.
[13] Luján-Mora S., Trujillo J., Physical Modeling of Data Warehouses using UML, DOLAP’04,
November 2004, Washington, DC, USA.
[CWM] OMG, Common Warehouse Metamodel (CWM) Specification, March 2003, Version 1.1.
[UML] OMG, Unified Modeling Language (UML) Specification, March 2003, Version 1.5.
[6] Pedersen TB., Jensen CS., Multidimensional Data Modeling for Complex Data, In Proceedings of
ICDE, pp. 336--345, 1999.
[11] Pokorny J., Sokolowsky P., A Conceptuel Modeling Perspective for Data Warehouses, Electronic
Business Engineering / 4. Internationale Tagung Wirtschaftsinformatik 1999.
[24] Ravat F., Teste O., Zurfluh G., Modélisation et extraction de données pour un entrepôt objet",
BDA’2000, Octobre 2000, Blois (France).
[5] Ravat F., Teste O., Zurfluh G., Modélisation multidimensionnelle des systèmes décisionnels, In
Actes des 1ères Journées Francophones d'Extraction et de Gestion des Connaissances - EGC 2001, 1819 Janvier 2001, Nantes (Loire-Atlantique, France).
[15] Rivest,S., Bédard, Y. & Marchand P., 2001, Towards better support for spatial decision-making:
Defining the characteris Spatial On-Line Analytical Processing (SOLAP), Geomatica: The journal of
the Canadian Institute of Geomatics, 2001
[Sha 75] Shanon R.E, Systems Simulation, the art and science, Prentice Hall 1975.
[14] Tanasescu
[22] Teste O., Elaboration d'entrepôts de données complexes, Actes du XVIIIème Congrès
INFormatique des ORganisations et Systèmes d'Information et de Décision - INFORSID'00, ed.
INFORSID - ISBN 2-906855-16-2, p229-245, 16-19 mai 2000, Lyon (Rhône, France).
[4] Teste O., Modélisation et manipulation d'entrepôts de données complexes et historisées, Thèse de
Doctorat de l’Institut de Recherche en Informatique - Université Paul Sabatier de Toulouse (France),
2000.
[17] Trujillo J. C., Palomar M., Gomez
J., Applying Object-Oriented Conceptual Modeling
st
Techniques to the Design of Multidimensional Databases and OLAP applications, In Proc. of 1 Int.
Conf. on Web-Age Information Management (WAIM), Springer, 2000 .
[21] Vassiliadis P., Sellis T., A Survey on Logical Models for OLAP Databases, SIGMOD Record
28(4): 64-69, 1999.
[10] Wan T., Zeitouni K., Modélisation d’objets mobiles dans un entrepôt de données, 5èmes journées
d’Extraction et Gestion des Connaissances (EGC), janvier 2005.
[MDA] La démarche MDA, Projet ACCORD, Mai 2002.
26