1

Modélisation multidimensionnelle des données complexes : application aux données médicales

Midouni Sid Ahmed Djallal

Version -9- 08/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

2

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 :

3

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

4

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.

5

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 spatio-temporelle. 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.

6

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

7

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 semi-structurées (bases de données relationnelles, collection de documents XML...);

et/ou

8

• 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, doivent-elles ê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.

9

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.

10

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.

11

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]

12

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

13

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.

Figure 6 : Le nouveau modèle Cardiovasculaire

0..1

*

1..1

*

1..1

*

1..1

*

1..1

*

0..1

*

0..1

*

1..1 *

1..1

*

1..1

*

1..1

*

1..1

*

1..1

*

1..1

*

1..1

*

1..1

*

Laboratoire--

Id LaboNom Labo

Médecin----

Id MédecinNomPrenomSpécialité

Examen--------

Id IndividuId TypeId MédecinId GroupeId TempsId MachineConclusionNormal

Résultat_Exam----

Id ExamenId AnalyseId TempsValeur

Famille Exam--

Id FamilleFamille Exam

Type Exam--

Id TypeType Examen

Analyse---

Id AnalyseNomNom Alternatif

Document Cardio- Id Doc

Individu---

Id IndividuNomPrenom

Groupe Doc- Id Groupe

Machine--

Id MachineNom

Heure- Heure

Mois- Mois

Année- Année

Jour- Jour

14

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 d’effectuer l’examen cardiovasculaire pour un individu donné.

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

15

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)

16

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).

1..1

1..*

1..1

1..*

Ass

Rec

EDM : Entrepôt de données Medical

MDM : Magasin de données Medical

1..1

*

1..*

1..*

1..1

0..*

1..*

1..*

1..1

1..*

0..1

0..*

EDM--

Nom EDMDescription EDM

MDM---

Id MDMNom MDMDescription MDM

T_Fait---

Id T_FaitNom T_FaitDescription T_Fait

Dimensions----

Id DimNom DimType DimDescription Dim

Mesures Paramètres

Attributs---

Id AttributNom AttributType Attribut

Dim Classique

Dim Temporelle

Dim Multimédia

Hiérarchie Fait- Type Lien

Niveaux----

Id NiveauNom NiveauOrdre NiveauDescription Niveau

Figure 7 : Le Méta Modèle

17

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.

18

• 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.

19

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.

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.

Méta Modèle

Modèle UML

Schéma XML

Schéma Relationnel

Entrepôt de données XML

Entrepôt de données

relationnel

2

2’

3

4

3’

1

Niveau Conceptuel

Niveau Logique

Niveau Physique

Niveau Méta

Niveau Instance

Instanciation Transformation Création

20

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.

Figure 9 : Architecture du prototype GEDM

Interface Utilisateur

Générateur de script

GEDM

Oracle

Entrepôt

Administrateur MAP

21

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

22

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

23

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.

24

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éta-modè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

25

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 Object-Oriented Model, In 3

rd 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 232-243. [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.

26

[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, 18-19 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 Techniques to the Design of Multidimensional Databases and OLAP applications, In Proc. of 1

st 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.