N° d’ordre 2005-ISAL-00125 Année 2005

Thèse

Définition d'un système générique de partage de données entre systèmes

existants

Présentée devant L’institut national des sciences appliquées de Lyon

Pour obtenir

Le grade de docteur

Formation doctorale : Documents multimédia, Images et Systèmes

d’Information Communicants (DISIC) École doctorale : École doctorale Informatique et Information pour la société

(EDIIS)

Par Mohamed Salah BOUMEDIENE

(Ingénieur)

Soutenue le 17 Décembre 2005 devant la Commission d’examen

Jury MM.

Rapporteur M. COLLARD Chef d’unité à l’ONERA (ONERA-DMSC) Directeur A. FLORY Professeur (INSA de Lyon) Examinateur M.HACID Professeur (Université Claude Bernard) Co-directrice F. LAFOREST Maître de conférences (INSA de Lyon) Rapporteur M. SIMONET HDR (Université Joseph Fourier Grenoble) Examinateur G. ZURFLUH Professeur (Université Toulouse II)

i

SOMMAIRE SOMMAIRE...................................................................................................... i Table des figures.............................................................................................. vi Liste des tableaux...........................................................................................viii Résumé............................................................................................................. ix Abstract............................................................................................................. x Chapitre I : Introduction ................................................................................... 1 1 Position du problème ................................................................................ 1 2 Contexte de la thèse : Le projet SICOM................................................... 2 3 Objectif ..................................................................................................... 4 4 Organisation de la thèse............................................................................ 4 Chapitre II : ETAT de l’art ............................................................................... 7 1 Introduction............................................................................................... 8 2 Les différentes approches d’intégration de bases de données .................. 9

2.1 Bases de données fédérées................................................................ 9 2.1.1 Les principaux systèmes fédérés............................................... 9

2.1.1.1 Information Manifold ........................................................... 9 2.1.1.2 InfoMaster........................................................................... 10 2.1.1.3 L’approche de Florescu ...................................................... 10 2.1.1.4 GARLIC.............................................................................. 10 2.1.1.5 Intégrateur de données biologiques .................................... 11

2.2 Les Médiateurs................................................................................ 12 2.2.1 Classification des approches de médiation ............................. 13 2.2.2 Les principaux systèmes de médiation ................................... 14

2.2.2.1 E-XMLMEDIA................................................................... 14 2.2.2.2 MIX..................................................................................... 15 2.2.2.3 PICSEL ............................................................................... 16 2.2.2.4 SIMS ................................................................................... 17 2.2.2.5 OBSERVER........................................................................ 18 2.2.2.6 DISCO ................................................................................ 19 2.2.2.7 TSIMMIS............................................................................ 21 2.2.2.8 EDC .................................................................................... 23 2.2.2.9 MOMIS............................................................................... 23

2.3 Conclusion ...................................................................................... 24 3 Construction d’une vue unifiée à partir de schémas de sources ............. 27

3.1 Introduction..................................................................................... 27 3.2 L'opération de « matching »............................................................ 27 3.3 Différents types de matching .......................................................... 28 3.4 Les principales approches de matching .......................................... 30

3.4.1 TranScm.................................................................................. 30 3.4.2 LSD (Learning Source Descriptions for Data Integration)..... 31 3.4.3 SemInt..................................................................................... 32

ii

3.4.4 Vues globales.......................................................................... 33 3.4.5 ARTEMIS............................................................................... 34 3.4.6 Cupid....................................................................................... 35 3.4.7 Clio (IBM Almaden et Univ. de Toronto) .............................. 36

3.5 Conclusion ...................................................................................... 36 4 Les ontologies ......................................................................................... 38

4.1 Introduction..................................................................................... 38 4.2 Définition de l’ontologie................................................................. 38

4.2.1 Définition philosophique ........................................................ 38 4.2.2 Les ontologies dans le cadre de la science informatique ........ 39

4.3 Les ontologies en médecine............................................................ 39 4.3.1 Les principales ontologies médicales ..................................... 39

4.3.1.1 ON9..................................................................................... 39 4.3.1.2 GALEN............................................................................... 40

4.3.2 UMLS ..................................................................................... 40 4.3.3 Nautilus................................................................................... 40 4.3.4 MED........................................................................................ 41

4.3.4.1 Ontologie du cancer du sein................................................ 41 4.3.4.2 MENELAS.......................................................................... 42

4.4 Conclusion ...................................................................................... 42 5 Contrôle de données................................................................................ 43

5.1 Les différentes approches de contrôle de données.......................... 43 5.1.1 L’approche de Damiani .......................................................... 43 5.1.2 L’approche de Bertino ............................................................ 43 5.1.3 La première approche de Gabillon.......................................... 44 5.1.4 La deuxième approche de Gabillon ........................................ 44 5.1.5 L’approche de Michiharu........................................................ 45

5.2 Conclusion ...................................................................................... 46 6 Le système DRUID................................................................................. 47

6.1 Introduction..................................................................................... 47 6.2 Principe de DRUID......................................................................... 47 6.3 Fonctionnement de DRUID............................................................ 48

6.3.1 Saisie des données .................................................................. 48 6.3.2 Consultation des données........................................................ 49

6.4 L’analyseur de DRUID................................................................... 50 7 Conclusion du chapitre ........................................................................... 51 Chapitre III : Création d’une vue unifiée........................................................ 53 1 Introduction............................................................................................. 53 2 Vue unifiée.............................................................................................. 55

2.1 Introduction..................................................................................... 55 2.2 Les ontologies ................................................................................. 57

2.2.1 L’ontologie de structure.......................................................... 57 2.2.2 L’ontologie de valeurs ............................................................ 58

2.3 Description XML d’une base de données à l’aide des ontologies.. 59 2.3.1 Le document XML décrivant la base de données................... 59

iii

2.3.2 Règles de description .............................................................. 61 2.3.3 Etape 1 : Description des relations ......................................... 63 2.3.4 Etape 2 : Description des attributs .......................................... 65 2.3.5 Etape 3 : Description des liens entre les relations .................. 66 2.3.6 Conclusion .............................................................................. 67

2.4 Le schéma médiateur ...................................................................... 68 2.4.1 Le document XML contenant le schéma médiateur ............... 68 2.4.2 Le document XML contenant les règles de mapping ............. 68

2.4.2.1 Les types des règles de mapping......................................... 69 2.4.2.2 Les cardinalités de règles de mapping ................................ 70 2.4.2.3 Fonction de conversion....................................................... 71

2.4.3 Règles de génération du schéma médiateur ............................ 71 2.4.4 Génération du schéma médiateur............................................ 74

2.4.4.1 Génération des relations du schéma médiateur................... 75 2.4.4.2 Génération des attributs du schéma médiateur ................... 77 2.4.4.3 Insertion des clés primaires des relations du schéma médiateur ............................................................................................ 78 2.4.4.4 Optimisation du schéma médiateur..................................... 78 2.4.4.5 Traitement des liens entre les relations du schéma médiateur ............................................................................................ 79 2.4.4.6 Conclusion .......................................................................... 80

2.5 Modification du schéma médiateur................................................. 81 2.5.1 Processus d’insertion .............................................................. 81

2.5.1.1 Ajout d’une relation dans un schéma source ...................... 81 2.5.1.2 Ajout d’un attribut dans une relation du schéma source..... 82 2.5.1.3 Ajout d’une clé primaire dans une relation du schéma source ............................................................................................ 83

2.5.2 Processus de suppression ........................................................ 84 2.5.2.1 Suppression d’une relation dans un schéma source............ 84 2.5.2.2 Suppression d’un attribut dans un schéma source .............. 85

3 Conclusion du chapitre ........................................................................... 86 Chapitre IV : Médiation et protection............................................................. 88 1 Introduction............................................................................................. 89 2 Médiateur ................................................................................................ 89

2.1 Introduction..................................................................................... 89 2.2 Architecture logicielle..................................................................... 89 2.3 Traitement des requêtes .................................................................. 91

2.3.1 Décomposition des requêtes ................................................... 91 2.3.2 Traduction de la requête ......................................................... 91 2.3.3 Exécution d’une requête ......................................................... 91 2.3.4 Interaction médiateur – ontologie de valeurs.......................... 92

2.4 Algorithme de traitement de la requête........................................... 93 2.5 Conclusion ...................................................................................... 97

3 Contrôle de données................................................................................ 98 3.1 Introduction..................................................................................... 98

iv

3.2 Utilisation de DRUID comme système d’entrée pour le médiateur98 3.2.1 Saisie des données avec DRUID ............................................ 99 3.2.2 Consultation des données avec DRUID................................ 100

3.3 Génération des DTDs.................................................................... 102 3.3.1 Génération des DTD SSD..................................................... 102

3.3.1.1 Présentation des DTDs SSD ............................................. 102 3.3.1.2 Le processus de génération des DTDs SSD...................... 104 3.3.1.3 L’algorithme de génération des DTD SSD:..................... 106

3.3.2 Génération des DTD WSD ................................................... 109 3.3.2.1 Présentation des DTDs WSD............................................ 109 3.3.2.2 Le processus de génération des DTDs WSD.................... 110 3.3.2.3 L’algorithme de génération de la DTD WSD................... 111

3.3.3 Filtrage des DTDs................................................................. 111 3.3.3.1 Problématique ................................................................... 111 3.3.3.2 Proposition ........................................................................ 112 3.3.3.3 Algorithme de filtrage des DTDs...................................... 113

3.3.4 Modification du document.................................................... 115 3.3.4.1 Filtrage d’un document en consultation............................ 115 3.3.4.2 Algorithme de filtrage....................................................... 116

3.4 Conclusion .................................................................................... 118 4 Conclusion du chapitre ......................................................................... 119 Chapitre V : Prototypes................................................................................. 120 1 Introduction........................................................................................... 121 2 Architecture globale.............................................................................. 122

2.1.1 Générateur de schéma médiateur .......................................... 123 2.1.2 Médiateur .............................................................................. 123 2.1.3 Contrôle de données.............................................................. 123 2.1.4 DRUID.................................................................................. 124

3 Vue unifiée............................................................................................ 124 3.1 Introduction................................................................................... 124 3.2 L’ontologie de structure................................................................ 125 3.3 L’ontologie de valeurs .................................................................. 127 3.4 Présentation du prototype 1 : Descripteur de bases de données ... 129

3.4.1 Diagramme des classes du descripteur de base de données.. 129 3.4.2 Diagramme de séquence du processus de description .......... 131

3.4.2.1 Description de la relation.................................................. 131 3.4.2.2 Description d’un attribut ................................................... 132

3.4.3 Exemple: Description d’une relation .................................... 133 3.5 Présentation du prototype 2 : Générateur de schéma médiateur... 135

3.5.1 Diagramme des classes du générateur de schéma médiateur 135 3.5.2 Diagramme des séquences : Génération des relations .......... 137 3.5.3 Diagramme de séquence : Génération des attributs.............. 138 3.5.4 Exemple: Génération du schéma médiateur ......................... 138

4 Médiateur .............................................................................................. 141 4.1 Présentation du prototype 3 : Médiateur....................................... 141

v

4.2 Fonctionnement du prototype ....................................................... 145 4.2.1 Règles des traitements des requêtes..................................... 145 4.2.2 Traitement de l’expression du FROM .................................. 146 4.2.3 Traitement de l’expression du SELECT............................... 147 4.2.4 Traitement de l’expression du WHERE ............................... 147 4.2.5 Traduction des requêtes ........................................................ 148

4.3 Diagrammes des classes du médiateur.......................................... 149 4.4 Présentation des classes ................................................................ 149 4.5 Diagramme de séquences.............................................................. 150

5 Contrôle des données ............................................................................ 151 5.1 Introduction................................................................................... 151 5.2 Présentation du prototype 4 : Génération et filtrage de DTDs ..... 152 5.3 Digrammes des classes ................................................................. 153 5.4 Diagramme de séquences.............................................................. 155

6 Conclusion ............................................................................................ 155 CHAPITRE VI : CONCLUSION................................................................. 156 1 Contribution .......................................................................................... 156

1.1 Schéma médiateur......................................................................... 156 1.2 Saisie et Contrôle des données...................................................... 157

2 Perspectives .......................................................................................... 157 2.1 Orienté-objet ................................................................................. 158 2.2 Utilisation du système dans un cadre professionnel ..................... 158 2.3 Enrichir l’ontologie....................................................................... 158 2.4 Un système d’apprentissage.......................................................... 158 2.5 Interface de validation .................................................................. 159 2.6 Interface d’interrogation ............................................................... 159

CHAPITRE VII : Bibliographie ................................................................... 160 ANNEXES.................................................................................................... 172

vi

Table des figures Figure 1 : Les différents modules qui composent SICOM .........................................................3 Figure 2 : Architecture de GARLIC .........................................................................................11 Figure 3 : Architecture globale d’un système de médiation .....................................................12 Figure 4 : Les deux types d'approches : LAV et GAV .............................................................13 Figure 5 : Architecture de PICSEL...........................................................................................17 Figure 6 : Architecture du médiateur OBSERVER..................................................................19 Figure 7 : Architecture de DISCO ............................................................................................20 Figure 8 : Architecture de TSIMMIS .......................................................................................22 Figure 9 : Architecture de Momis.............................................................................................24 Figure 10: Deux arbres de deux parties de bases de données...................................................36 Figure 11: Fonctionnement de DRUID ....................................................................................49 Figure 12 : Architecture de notre système de médiation ..........................................................54 Figure 13 : Le diagramme des classes de notre ontologie de structure ....................................58 Figure 14 : DTD du document décrivant la base de données ...................................................59 Figure 15 : Document décrivant la base de données BD..........................................................61 Figure 16 : Processus de description de base de données.........................................................63 Figure 17 : Une partie de l'ontologie de structure.....................................................................64 Figure 18 : DTD du schéma médiateur.....................................................................................68 Figure 19 : DTD du document des règles de mapping .............................................................69 Figure 20 : Document de règles de mapping ............................................................................71 Figure 21 : Processus de génération de schéma médiateur.......................................................75 Figure 22 : Document XML contenant des règles de mapping ................................................77 Figure 23 : Processus de modification du schéma médiateur (Insertion Relation) .......................82 Figure 24 : Processus de modification du schéma médiateur (Insertion Attribut) ......................... 82 Figure 25 : Processus de modification du schéma médiateur (Suppression Relation)...........................84 Figure 26 : Architecture du médiateur ......................................................................................90 Figure 27 : DTD du document contenant les résultats..............................................................92 Figure 28 : Une partie de l'ontologie médicale .........................................................................93 Figure 29 Les étapes suivies par un document avant la saisie de ses

informations dans une base de données. ...........................................................................99 Figure 30: Processus de saisie des informations avec le système..........................................100 Figure 31 : Processus de consultation des données avec DRUID ..........................................101 Figure 32 : Les étapes de génération des DTDs .....................................................................102 Figure 33 Exemple de schéma de base de données ................................................................103 Figure 34 Exemple d’une DTD SSD ......................................................................................104 Figure 35 : Processus de génération des DTDs SSD..............................................................104 Figure 36 DTD ordonnée et non ordonnée .............................................................................110 Figure 37 DTD WSD pour la saisie par un médecin d’un document prescription....................... 110 Figure 38 : Processus de transformation d'une DTD SSD en une DTD WSD .......................110

vii

Figure 39 : Processus de filtrage des DTDs............................................................................112 Figure 40 : Filtrage d'un document en consultation................................................................116 Figure 41 : Architecture globale du système ..........................................................................122 Figure 42 : Architecture du générateur de vue unifiée ...........................................................125 Figure 43 : Une partie de notre ontologie de structure ...........................................................126 Figure 44 : Schéma des classes de l’ontologie de structure....................................................127 Figure 45 : Schéma des classes du descripteur de bases de données......................................129 Figure 46 : Document XML décrivant la relation "Patient" ..................................................134 Figure 47 : Schéma des classes du générateur de schéma médiateur .....................................135 Figure 48 : Document XML contenant le schéma médiateur .................................................139 Figure 49 : Document XML contenant les règles de mapping ...............................................141 Figure 50: Architecture du médiateur.....................................................................................141 Figure 51 : Interface graphique permettant à l’utilisateur de formuler sa requête ....................... 142 Figure 52 : Résultats de l’exécution des différentes requêtes.................................................143 Figure 53 : Interface graphique permettant à l’utilisateur de formuler sa requête ....................... 144 Figure 54 : Résultats de l’exécution des différentes requêtes.................................................144 Figure 55 : Schéma des classes du médiateur.........................................................................149 Figure 56 : L'architecture du prototype de contrôle de données.............................................152 Figure 57 Exemple de génération d’une DTD SSD ...............................................................153 Figure 58 : Diagramme de classes du prototype.....................................................................154 Figure 59 : Une partie de l’ontologie du dossier médical.......................................................196 Figure 60 : Document XML décrivant la base de données BD1 ............................................207 Figure 61 : Document XML décrivant la base de données BD2 ............................................209 Figure 62 : Document XML contenant le schéma médiateur .................................................252 Figure 63 : Document XML contenant les règles de mapping ...............................................256

viii

Liste des tableaux Tableau 1 : récapitulatif des systèmes de médiation.................................................................25 Tableau 2 : récapitulatif des systèmes de fédération ................................................................26 Tableau 3 : structure de deux schémas hétérogènes .................................................................28 Tableau 4 : Les différentes cardinalités du mapping ................................................................29 Tableau 5 : Tableau comparatif des différentes approches de matching..................................37 Tableau 6 : différentes approches de contrôle ..........................................................................46 Tableau 7 : Tableau présentant les différents types d’hétérogénéités. .....................................56 Tableau 8 : Tableau présentant les différents types d’hétérogénéités ainsi que

leur résolution. ..................................................................................................................87 Tableau 9 : Table reliant les concepts des deux ontologies....................................................128 Tableau 10: Tableau contenant une partie du contenu de la relation Diagnostic

de la base de données BD1 .............................................................................................194 Tableau 11: : Tableau contenant une partie du contenu de la relation Patient

de la base de données BD1 .............................................................................................194

ix

Résumé Le travail de ma thèse s’inscrit dans la problématique de l’intégration

de bases de données et de la confidentialité des données échangées. Le but est de résoudre les problèmes liés à la création des schémas médiateurs. Nous avons proposé une solution qui génère une vue unifiée de différentes bases de données en minimisant au maximum les interventions manuelles. Pour ce faire nous décrivons en premier chaque schéma à intégrer à l’aide de termes issus d’une ontologie. Cette description crée pour chaque base de données un document XML. Ces documents sont ensuite utilisés pour la création du schéma médiateur et des règles de correspondances. Afin d’exploiter le schéma médiateur nous avons créé un médiateur qui permet aux utilisateurs d’interroger les différentes bases de données via la vue unifiée. Afin d’alléger le processus de saisie des données nous avons utilisé le système DRUID qui permet aux utilisateurs de saisir les données sous forme de documents qui seront ensuite traités pour alimenter les bases de données. Afin de gérer la confidentialité dans la saisie et la consultation des données nous avons proposé d’utiliser des modèles de documents (DTD) pour chaque profil utilisateur, que ce soit pour les documents en écriture ou en lecture. Ces DTD sont générés automatiquement à partir du schéma de la base de données et modifiées ensuite pour chaque type d’utilisateur à partir des droits sur la base de données. Notre solution a été appliquée dans le domaine médical en consultant un dossier médical réparti.

Mots-clés : Intégration de bases de données, Médiateur, Schéma médiateur, Règles de mapping, XML, Ontologie, DTD, XML-schema, Echange de données, Partage d'information.

x

Abstract My thesis deals with the the database integration problems and the

confidentiality of the exchanged data. My aim, however, is to solve the problems related to the mediator schema ceation. We proposed a solution which will generate a global view of the different databases by reducing, considerably, the manual interventions. To achieve this, we will describe, at the beginning, each schema using ontologic terms. This description will create for each database an XML file which will be used ,then, for the creation of mediator schema and the matching rules. In order to process the mediator schema, we created a mediator that allows users to query the different databases trough the global view. To lighten the data input process, we used the DRUID system which allows users to input their data under the form of files which will be processed, then, to populate the databases. To handle the confidentiality of the data entry and access, however, we proposed the use of (DTD) documents models and files to each type of user’s profil, whether, for writing or reading files. These DTD are generated, automatically, from the database schema and then modified, for each user type according to their rights on the database. Our solution was applied in the medical domain through the consulting of a distributed medical file.

Keywords: database integration, mediator schema, mapping rules,

ontology, DTD, XML- schema, data exchange, information sharing.

1

Chapitre I : Introduction Chapitre I : Introduction............................................................................................................. 1 1 Position du problème.......................................................................................................... 1 2 Contexte de la thèse : Le projet SICOM ............................................................................ 2 3 Objectif............................................................................................................................... 4 4 Organisation de la thèse ..................................................................................................... 4

1 Position du problème

La diversité des systèmes rend difficile leur communication, car ces systèmes peuvent

concerner un même métier mais être bâtis avec des modèles différents. Leurs diversités sont

classées dans deux types d’hétérogénéités, l’hétérogénéité sémantique et l’hétérogénéité

structurelle. La première concerne des relations et attributs ou nous pouvons avoir deux

informations identiques qui portent des noms différents. Par exemple dans une première base

de données un attribut est appelé « Nom » alors que dans la deuxième base de données le

même attribut est appelé « libellé ». Nous pouvons également avoir des données ayant les

mêmes dénominations mais qu’elles soient différentes dans leur contenu. Par exemple dans

un premier schéma la relation « Diagnostic » contient les maladies d’un patient alors que dans

le deuxième schéma la même relation contient un dictionnaire de maladies. L’hétérogénéité

structurelle quant à elle, réside dans le fait qu’une même information est modélisée de

manière différente dans différents schémas de bases de données. Par exemple dans une

première base de données d’un magasin les informations sur les produits sont contenues dans

une seule relation composée du code du produit, de son libellé et du nom du fournisseur. La

deuxième modélise les informations des produits sur trois relations : la première contient les

données sur le produit (sa quantité et son prix), la deuxième relation stocke les informations

sur les fournisseurs alors que la troisième recense les clients du magasin. Les différences dans

les modèles exposées ci-dessus rendent difficile le partage d’information. A la fin des années

70, des recherches ont été effectuées dans ce domaine et ont donné naissance aux bases de

données fédérées. Ces bases de données reposent sur un modèle pivot, créé manuellement et

est utilisé pour interroger les différentes bases de données. Dans les années 90 les techniques

à base de médiateurs [WIE 92] permettent l’émergence de nouvelles architectures de

médiation. Un médiateur est un outil qui permet aux utilisateurs d’interroger différentes bases

2

de données hétérogènes. Il se repose sur une ontologie ou une vue unifiée [WIE 92],

permettant ainsi à l’utilisateur d’avoir l’impression qu’il interroge une seule base de données.

Nous en étudions sa structure dans le chapitre état de l’art. Comme pour les bases de données

fédérées, la création de la vue unifiée pose problème, car elle nécessite de multiples

interventions des utilisateurs, ce qui la rend délicate. Par ailleurs une autre difficulté se pose

dans les deux approches à savoir la modification ou l’insertion de schémas de sources de

données. Cette opération nécessite, dans la plupart du temps, une reconstruction du modèle

pivot dans les bases de données fédérées ainsi que celle de la vue unifiée dans les médiateurs.

Nous devons donc définir un système de médiation qui permet de résoudre cette

problématique.

La saisie des données reste toujours désagréable pour les utilisateurs. En effet

l’utilisateur voulant saisir ses données se retrouve devant des formulaires de cases à remplir et

il est difficile de retrouver la souplesse des papiers. Afin de combiner la puissance des

approches base de données et base documentaire nous proposons à l’utilisateur de saisir et

consulter ses informations en utilisant le système DRUID [BAD 03a], que nous rattacherons à

notre système de médiation. DRUID permet à l’utilisateur de saisir ses informations dans un

document semi-structuré où chaque paragraphe de texte libre est balisé. Ce document est

ensuite traité afin d’en extraire les informations et de remplir la base de données. L’utilisateur

qui interroge la base de données à travers DRUID récupère les tuples résultats ainsi que le

document qui a alimenté la base de données. Cette solution est certes performante pour la

saisie et la consultation des données, mais il est difficile de contrôler les informations

entrantes et sortantes. Ces données sont dans la plupart des cas confidentielles et il est difficile

de contrôler l’accès de chaque utilisateur. Cette problématique est résolue dans les SGBDR

quand les données manipulées sont sous forme de tuples, mais elle devient plus compliquée

quand on traite des documents. Nous devons donc gérer cette confidentialité, et ce en

proposant un système qui permet de contrôler l’accès des utilisateurs aux données selon leurs

droits respectifs.

2 Contexte de la thèse : Le projet SICOM

La problématique de l’intégration des bases de données concerne bien évidemment le

domaine médical où il est important de connaître le dossier médical d’un patient, dossier qui

est réparti sur plusieurs bases de données. C’est dans ce contexte que le projet SICOM

(Systèmes d’Information COMmunicants pour la santé) est né. Son but est de créer et de

3

partager l’information médicale dans le cadre des réseaux ville-hôpital (Hospitalisation A

Domicile). L'hospitalisation à domicile (HAD) est une alternative à l'hospitalisation

prolongée. Elle permet d'assurer au domicile du patient tous les soins médicaux et

paramédicaux prescrits par un médecin (prise en charge globale).

Modèles adaptatifs

d’interfaces utilisateurs

Equipements communicants

Gestion administrateur

(création des comptes, etc.)

Confidentialité Authentification

Cryptage

BD médicale

Alpha-num.

BDmultimédia

BDAdministr.

Système de communication

Entrepôt

Gestion des informations

médicales réparties

Système d’évaluation -

Gestion desalertes

- Visioconférence

Outils pour la mobilité

Traçabilité Gestion des accès et de l’historique

(1)

(11)

(6)

(7)

(2)

(3)

(5)

(8)

(9)

(4)

(10)

Figure 1 : Les différents modules qui composent SICOM

La Figure 1 présente l’architecture du projet SICOM, ce travail consiste à trouver une

solution pour faire communiquer les systèmes d’informations médicales réparties. En effet, le

patient étant soigné dans plusieurs structures (domicile, médecin traitant, hôpital), son dossier

est géré par différents systèmes et nous nous trouvons alors en présence d’un dossier médical

réparti. En télémédecine, l’accès aux informations de la part de différents utilisateurs est le

premier besoin à satisfaire. Ainsi, chaque pièce rédigée au sujet d’un patient doit être

disponible à tout professionnel de santé qui prend en charge ce dernier. Nous devons, de ce

fait, fournir un point d’accès à toutes ces pièces, et ce quel que soit leur auteur, leur

localisation et leur type. Lorsque les données sont informatisées, la communication implique

une liaison entre les logiciels utilisés par les différents praticiens. Cette liaison concerne la

transmission ou le partage de données entre les bases de données intégrées aux logiciels. Nous

devons alors définir un système permettant d’intégrer différentes bases de données

4

hétérogènes et présenter aux utilisateurs une interface lui permettant de récupérer les

informations stockées sur les différents sites.

3 Objectif

Le but de ce travail consiste à fournir un système d’information, qui d’une part

facilitera aux utilisateurs la manipulation des informations et d’autre part permettra aux

différents systèmes placés dans différents sites d’échanger les informations sans modification

des systèmes existants.

Il devra être facile à manipuler : l’utilisateur ne sera pas obligé de passer par un formulaire

pour saisir ses données, ni d’apprendre un langage de requêtes pour interroger sa base de

données, ni de changer de système pour communiquer avec les autres.

Les directives de mes recherches ont donc concerné les deux points suivants :

• Intégration : Notre système devra permettre l’intégration de différentes bases de

données. Ce point constitue le centre de la problématique d’interopérabilité de

différentes sources. Pour ce faire, nous devons présenter une solution qui améliore

l’étape de création des schémas médiateurs. Ce schéma permettra aux utilisateurs

d’interroger des sources d'informations multiples, les libérant de ce fait de devoir

identifier les sources appropriées et de combiner manuellement les informations

provenant des différentes sources.

• Confidentialité : Le système est utilisé par différents types d’utilisateurs. Les données

stockées sont dans la plupart du temps confidentielles. Il est donc important de prendre

en compte les droits d’accès aux données à la fois dans la saisie et dans la

consultation. Nous devons alors proposer un modèle de confidentialité permettant de

filtrer les données selon les profils des utilisateurs et leurs droits d’accès à la base de

données. Ce modèle devra être créé le plus automatiquement possible.

4 Organisation de la thèse Chapitre 2 : ETAT de l’art

Dans le deuxième chapitre nous étudierons l’état de l’art où nous exposerons les

différentes approches d’intégration de bases de données. Elles regroupent deux types

5

d’approches : les bases de données fédérées et les systèmes de médiations. Nous aborderons

ensuite les différents systèmes de construction de vues unifiées à partir de schémas de sources

de données existantes. Le troisième point de notre recherche bibliographique concernera le

contrôle des informations confidentielles. Nous enchaînerons par la présentation des

ontologies médicales avant de terminer le chapitre par le système DRUID qui permet la saisie

et la consultation de données sous forme de documents.

Chapitre 3 : Création d’une vue unifiée

Le chapitre 3 abordera notre proposition à la problématique de notre thèse. Cette

proposition est composée de deux parties. La première nous permet de décrire chaque base de

données à intégrer afin de résoudre les hétérogénéités entre les différents schémas. La

deuxième utilise ces descriptions afin de générer la vue unifiée. Nous exposerons ensuite

comment les modifications des schémas sources influencent celles du schéma médiateur.

Chapitre 4 : Médiation et protection

Dans ce chapitre nous montrerons comment la vue unifiée est exploitée. Pour ce faire

nous avons conçu un médiateur qui utilise cette vue et qui permet aux utilisateurs de formuler

leurs requêtes sur l’ensemble des bases de données sources. Nous montrons aussi la solution

proposée afin de protéger les informations stockées dans ces bases de données et manipulées

par les différents types d’utilisateurs.

Chapitre 5 : Prototype

Ce chapitre a pour objectif de valider les propositions faites dans les chapitres 3 et 4.

Nous avons développé plusieurs prototypes, chacun permettant de valider une partie de notre

proposition.

6

7

Chapitre II : ETAT de l’art Chapitre II : ETAT de l’art...............................................................................................................7 1 Introduction ..............................................................................................................................8 2 Les différentes approches d’intégration de bases de données..................................................9

2.1 Bases de données fédérées ...............................................................................................9 2.1.1 Les principaux systèmes fédérés ..............................................................................9

2.1.1.1 Information Manifold...........................................................................................9 2.1.1.2 InfoMaster ..........................................................................................................10 2.1.1.3 L’approche de Florescu......................................................................................10 2.1.1.4 GARLIC .............................................................................................................10 2.1.1.5 Intégrateur de données biologiques....................................................................11

2.2 Les Médiateurs ...............................................................................................................12 2.2.1 Classification des approches de médiation.............................................................13 2.2.2 Les principaux systèmes de médiation...................................................................14

2.2.2.1 E-XMLMEDIA ..................................................................................................14 2.2.2.2 MIX ....................................................................................................................15 2.2.2.3 PICSEL...............................................................................................................16 2.2.2.4 SIMS...................................................................................................................17 2.2.2.5 OBSERVER.......................................................................................................18 2.2.2.6 DISCO................................................................................................................19 2.2.2.7 TSIMMIS ...........................................................................................................21 2.2.2.8 EDC....................................................................................................................23 2.2.2.9 MOMIS ..............................................................................................................23

2.3 Conclusion......................................................................................................................24 3 Construction d’une vue unifiée à partir de schémas de sources.............................................27

3.1 Introduction ....................................................................................................................27 3.2 L'opération de « matching » ...........................................................................................27 3.3 Différents types de matching..........................................................................................28 3.4 Les principales approches de matching..........................................................................30

3.4.1 TranScm .................................................................................................................30 3.4.2 LSD (Learning Source Descriptions for Data Integration) ....................................31 3.4.3 SemInt ....................................................................................................................32 3.4.4 Vues globales .........................................................................................................33 3.4.5 ARTEMIS ..............................................................................................................34 3.4.6 Cupid ......................................................................................................................35 3.4.7 Clio (IBM Almaden et Univ. de Toronto)..............................................................36

3.5 Conclusion......................................................................................................................36 4 Les ontologies ........................................................................................................................38

4.1 Introduction ....................................................................................................................38 4.2 Définition de l’ontologie ................................................................................................38

4.2.1 Définition philosophique........................................................................................38 4.2.2 Les ontologies dans le cadre de la science informatique .......................................39

8

4.3 Les ontologies en médecine ...........................................................................................39 4.3.1 Les principales ontologies médicales.....................................................................39

4.3.1.1 ON9 ....................................................................................................................39 4.3.1.2 GALEN ..............................................................................................................40

4.3.2 UMLS.....................................................................................................................40 4.3.3 Nautilus ..................................................................................................................40 4.3.4 MED.......................................................................................................................41

4.3.4.1 Ontologie du cancer du sein ...............................................................................41 4.3.4.2 MENELAS .........................................................................................................42

4.4 Conclusion......................................................................................................................42 5 Contrôle de données ...............................................................................................................43

5.1 Les différentes approches de contrôle de données .........................................................43 5.1.1 L’approche de Damiani ..........................................................................................43 5.1.2 L’approche de Bertino............................................................................................43 5.1.3 La première approche de Gabillon .........................................................................44 5.1.4 La deuxième approche de Gabillon........................................................................44 5.1.5 L’approche de Michiharu .......................................................................................45

5.2 Conclusion......................................................................................................................46 6 Le système DRUID ................................................................................................................47

6.1 Introduction ....................................................................................................................47 6.2 Principe de DRUID ........................................................................................................47 6.3 Fonctionnement de DRUID ...........................................................................................48

6.3.1 Saisie des données..................................................................................................48 6.3.2 Consultation des données .......................................................................................49

6.4 L’analyseur de DRUID ..................................................................................................50 7 Conclusion du chapitre...........................................................................................................51

1 Introduction Notre sujet de thèse a été effectuée dans le cadre du projet SICOM et concerne la problématique

de l’intégration de bases de données. Avant de présenter notre solution, nous étudions dans ce

chapitre l’état de l’art de l’existant. Ce chapitre est composé de cinq parties :

Intégration et interrogation de bases de données hétérogènes : présentation des systèmes

de médiations et des bases de données fédérées,

Construction d’une vue unifiée à partir de schémas de sources de données existantes :

présentation des approches de créations de schémas médiateur,

Contrôle d’accès aux informations confidentielles : présentation des approches de

contrôle de données,

9

Etude des ontologies médicales existantes : présentation d’une vue générale sur les

ontologies médicales,

Le système DRUID : Nous présenterons le système DRUID qui permet à l’utilisateur de

consulter les informations sous forme de documents.

2 Les différentes approches d’intégration de bases de données

Actuellement de nombreux systèmes communiquent entre eux en échangeant des

informations. La plupart de ces systèmes sont hétérogènes, d’où la difficulté de partager les

informations. Deux types d’approches essaient de résoudre cette problématique, les bases de

données fédérées [SHE 90] et les médiateurs [WIE 92].

2.1 Bases de données fédérées

Les bases de données fédérées présentent aux utilisateurs une vue unique des données,

implémentées sur plusieurs systèmes hétérogènes. Différents systèmes fédérés ont été

développés, nous en présentons quelques-uns ci-dessous.

2.1.1 Les principaux systèmes fédérés

2.1.1.1 Information Manifold

Information Manifold [IVE 99] [LEV 96] [LEV 95] est un system de décision logique

pour intégrer des sources d'informations basées sur le Web, développé par AT&T en 1995/96. Il

présente à l'utilisateur une vue globale unique, appelé World View, sur laquelle il formule ses

requêtes. Cette vue est une collection de relations virtuelles et de classes qui décrivent le contenu

des sources d'informations. Son modèle de données est relationnel, augmenté avec les hiérarchies

de classes. Chaque fois qu’un utilisateur accède au système il identifie les sources pertinentes et

exécute sur elles ses sous-requêtes. Une fois les requêtes exécutées l'utilisateur est responsable de

nettoyer l'information redondante.

10

2.1.1.2 InfoMaster

InfoMaster [GEN 97a] utilise une interface WEB ou un langage logique pour interroger

une vue définie sous la forme d'un schéma relationnel. Ce schéma est constitué de la partie

commune des modèles fédérés. A chaque source de données est affectée une liste de règles

associant les attributs de la vue à ceux des schémas locaux. Ces règles sont définies en utilisant le

langage KIF [GEN 92]. Elles permettent aussi de convertir l’information afin de la mettre sous

format adéquat et de l’adapter aux sources de données.

2.1.1.3 L’approche de Florescu

Le fonctionnement du système [FLO 96] [FLO 95] se base sur des interfaces d'accès

présentées par chaque système, et un modèle commun représentant ces interfaces. Une interface

d'accès a été définie en ODMG [CAT 96] (Object Database Management Group) pour fédérer

les interfaces locales. Le système utilise un ensemble de règles afin de reformuler les requêtes

tout en préservant la sémantique. Il existe deux types de règles : les règles de contraintes (mise en

correspondance) qui ajoutent de la sémantique à la structure des informations et les règles de

réécriture qui aident à reformuler des requêtes. Une fois que la requête est réécrite les wrappers

prennent en charge les sous-requêtes pour les exécuter sur les systèmes locaux et renvoient les

résultats. Un wrapper (adaptateur) est un outil permettant l'accés au contenu d'une source

d'informations. Son rôle est centré sur la résolution des conflits syntaxiques. Le wrapper fait le

lien entre la représentation locale des informations et leur représentation dans le modèle de

médiation. Les exemples commerciaux de wrapper sont les passerelles JDBC et ODBC pour les

bases de données relationnelles.

2.1.1.4 GARLIC

L’objectif de GARLIC [TOR 97] [CAR 95] [COD 95] est l’intégration de diverses

sources multimédias en fournissant une vue intégrée des schémas des sources de données locales.

11

Ces schémas sont fusionnés en un schéma global exprimé en ODMG. L’accès aux objets de

GARLIC peut se faire de deux façons, via une interface graphique ou en utilisant le langage de

requêtes de GARLIC. Son langage de requêtes GQL est une extension de SQL supportant les

expressions de chemins, les collections imbriquées ainsi que les méthodes. Les requêtes

formulées par les utilisateurs sont envoyées au processeur de requêtes. Ce dernier développe des

plans d’exécution de requêtes décomposées pour les multiples sources de données avant d’être

envoyées aux wrappers. Un wrapper est associé à chaque source d’informations (Figure 2)

présentant une interface pour accéder aux données locales.

Figure 2 : Architecture de GARLIC

2.1.1.5 Intégrateur de données biologiques

Un autre système a été proposé par [DEV 02] pour intégrer des données biologiques

présentées ensuite aux utilisateurs sous forme de documents XML conformes à une DTD. Ce

système permet de rechercher des informations réparties sur plusieurs entrepôts de données. La

recherche se fait en plusieurs étapes et le résultat de chacune est utilisé comme une entrée dans

l’étape suivante. Les données collectées sont intégrées au fur et à mesure du déroulement de la

recherche dans un document XML. L’utilisateur intervient dans le choix des données pertinentes

12

qui seront stockées. Ses requêtes sont formulées via un formulaire et pour chaque type de

recherche une DTD est créée manuellement.

L’évolution des approches de bases de données fédérées a donné naissance aux

médiateurs.

2.2 Les Médiateurs

L’approche de médiation consiste à développer une application chargée de jouer le rôle

d’interface entre les bases de données et les applications utilisées par des utilisateurs. Un

médiateur permet de résoudre les différents conflits entre les schémas des sources de données, il

génère un plan d’exécution entre les utilisateurs et ces sources [JAK 97]. Il simplifie, et décrit les

données distribuées. La Figure 3 montre une application utilisant un médiateur et comme la

plupart des médiateurs il se base sur l’architecture proposée par [WIE 92] dont les fonctionnalités

sont présentées dans [WIE 94]. Cette architecture se compose de trois couches :

Figure 3 : Architecture globale d’un système de médiation

Couche 1 : Concerne les utilisateurs et les applications.

Couche 2 : Comprend le médiateur. Elle se charge de récupérer les requêtes émises par les

utilisateurs et d’effectuer un ensemble de transformations sur ces dernières afin des les exécuter

sur les sources de données.

Couche 1

Couche 2

Couche 3

13

Couche 3 : Comprend les sources de données où chacune est connectée à un wrapper. Il peut être

une simple interface d’interrogation ou un module qui résout les problèmes liés à la sémantique

[ALI 04].

2.2.1 Classification des approches de médiation

Les approches de médiation sont classifiées selon le type de leur schéma médiateur en

deux groupes [ROU 04] [MCB 03] [LEV 00] : les approches GAV (global As View) où le

schéma médiateur est une vue sur des schémas locaux et les approches LAV (Local As View), où

les schémas locaux sont des vues du schéma global, ce qui signifie que les données dans chaque

source doivent être définies selon le schéma global et non l'inverse.

Schéma fédéré Base de données « vue universelle »

vue complexe, multi-relation qui transforme les sources et combine les informations

Profil de la source

Processeur de requêtes LAV

Profil de la source

Source semi-structurée Source

structurée

Figure 4 : Les deux types d'approches : LAV et GAV

L’approche GAV

Dans l’approche GAV [GMP 97]le schéma médiateur est défini en fonction des schémas

des sources à intégrer. Sa vue est utilisée pour réécrire les requêtes sur le schéma global en des

requêtes distribuées sur des bases de données locales. Les requêtes sont alors transformées d’une

14

requête sur la vue globale en des requêtes sur les sources locales. Son avantage est que la

reformulation des requêtes est simple car chaque terme de la requête est remplacé par son

équivalent dans les schémas des bases de données. L’inconvénient de cette approche réside dans

l’ajout et la suppression de relations dans les schémas locaux car chaque modification entraîne la

modification du schéma global et la création des interactions de la nouvelle source avec les

sources existantes. Parmi les systèmes appartenant aux approches GAV, nous citons GARLIC

[CAR 95], DISCO [TOM 96], TSIMMIS [GAR 97], MIX [BAR 99] et E-XMLMEDIA [GAR

99]

L’approche LAV

L’approche LAV [LRO 96] consiste à décrire le contenu des sources à intégrer en

fonction du schéma médiateur. Le traitement des requêtes sur le schéma global implique leur

réécriture en des requêtes utilisant les vues. La requête sur le schéma global doit être reformulée

suivant les schémas des sources locales, ce qui la rend complexe.

Dans une telle approche l’ajout ou la suppression d’une relation est facile à traiter car elle

n’affecte pas le schéma médiateur, vu que chaque source est définie indépendamment. Parmi les

systèmes appartenant aux approches LAV, nous citons Information Manifold [IVE 99], PICSEL

[GOA 98] et OBSERVER [GON 97]. Dans ce qui suit nous allons développer quelques systèmes

de médiation.

2.2.2 Les principaux systèmes de médiation

2.2.2.1 E-XMLMEDIA

E-XMLMEDIA [XME 02] [GAR 99] est un système médiateur de base de données

fédérées utilisant XML comme modèle fédéré et mis en vente par la société du même nom. Son

but est de fournir un accès aux multiples sources de données sur Internet ou Intranet qui utilisent

des protocoles XML et des outils basés sur les composants Java. Il permet de fédérer des sources

de données hétérogènes, en présentant une vue unique de l’ensemble des sources. Son langage de

requêtes est basé sur XQuery, et les résultats sont sous format XML. E-XMLMedia est composé

de quatre modules :

15

XMLizer joue le rôle d'interface XML pour des données stockées dans un SGBD relationnel. Il

permet l'extraction de données, leur transformation au format XML et l'insertion d'informations

XML dans des tables relationnelles en respectant les règles de gestion en place

e-XML Repository permet de stocker et d'interroger des documents XML dans un SGBD

relationnel. Il assure un chargement et une restitution rapide des documents stockés dans les

tables relationnelles, en conservant et exploitant leur structure pour optimiser leur emplacement.

e-XML Mediator permet l’exécution des requêtes sur des sources de données XML multiples et

hétérogènes. Il se connecte aux sources de données via des wrappers qui assurent la traduction

des données du format source vers XML, et la traduction de la requête XML vers le langage de la

source interrogée. Les résultats sont fournis sous forme de documents XML dont la structure est

définie dans les requêtes.

e-XML XForms Engine automatise l'intégration des données saisies aux systèmes d'information

par la génération d'un flux de données au format XML.

2.2.2.2 MIX

MIX [BAR 99] [LUD 99] (Médiation of Information using XML) est un médiateur basé

sur XML fournissant à l’utilisateur une vue intégrée de différentes sources développé dans le

cadre d’un projet au sein de « University of California at San Diego Database Laboratory ». Cette

vue est une interface définie en utilisant le langage XMAS (Xml Matching And Structuring

language). XMAS est un langage déclaratif inspiré du langage de requêtes XML-QL utilisé

comme un langage de définition de vue, ainsi que pour interroger l'interface du système. Le

système MIX est également composé d’une interface graphique appelée BBQ (Blended Browsing

and Querying) et de wrappers. L’interface guide l’utilisateur dans la conception des vues en

utilisant les DTDs fournies par les wrappers. Elle permet d’interroger des données XML

complexes, et de générer des requêtes en XMAS. Les réponses aux requêtes sont sous forme de

documents XML. Les wrappers permettent d’avoir une vue logique en XML (DTD) d’une source

d’information. Ils traduisent une requête XMAS vers un langage compréhensible par la source

concernée et permettent aussi de traduire les résultats en XML. Le médiateur de MIX récupère

une requête formulée par l’utilisateur en utilisant l’interface BBQ, la traduit en utilisant les

16

termes de la vue de médiation, et produit un ensemble de requêtes XML avant d’être envoyées

aux wrappers. Ces requêtes peuvent être ensuite simplifiées en se basant sur les DTDs.

La difficulté dans MIX est que la modification de l’existant ou l’ajout d’une source

réclame la modification de toute la vue de médiation.

2.2.2.3 PICSEL

PICSEL [ROU 02] [GOA 99] [GOA 98] est composé d’un médiateur jouant le rôle

d’interface entre les utilisateurs et les sources de données à interroger. Son schéma global est

exprimé dans le langage Carin [LEV 98]. L’architecture de PICSEL est constituée d’une

ontologie du domaine, et de bases de connaissances (BCcomp) connectées au médiateur,

décrivant le contenu des sources d’information. Une ontologie permet de représenter la

connaissance d’un domaine sous la forme d’une hiérarchie de concepts et de relations

sémantiques entre ces concepts [BEC 02]. L’ontologie dans PICSEL fournit tout le vocabulaire

utile aux utilisateurs pour formuler leurs requêtes. Elle est décrite en utilisant le langage de

représentation CARIN-ALN [ROU 02], un langage riche permettant de décrire de façon très fine

l'ontologie d'un domaine et le contenu des sources d'information. Les autres bases de

connaissances permettent au médiateur de déterminer quelles sources d’information peuvent

fournir des éléments de réponses à une requête utilisateur. Entre chaque base de connaissances et

chaque source, est connecté un wrapper. Le langage de requête utilisé est le langage hybride

CARIN/core-CLASSIC [GOA 98].

Son inconvénient est qu’une fois l’ontologie partagée définie, chaque source doit utiliser

le vocabulaire commun, ce qui limite l’autonomie des sources de données locales.

.

17

Figure 5 : Architecture de PICSEL

2.2.2.4 SIMS

Dans SIMS [ASH 99] [ARE 97] le partage d’information entre multiples schémas

relationnels est facilité par l’utilisation d’un schéma de représentation de connaissance LOOM

incluant un schéma global pour chaque domaine d’application. Il décrit le contexte en définissant

les concepts sous forme de classes, les relations entre les concepts ainsi que les rôles. Un rôle

définit la signification d’un concept par rapport à un autre. Les informations dans SIMS sont

modélisées dans des classes sémantiques du domaine. Le langage de requêtes est basé sur LOOM

et les requêtes sont exprimées sur les concepts du domaine. L'utilisateur formule une requête en

utilisant les termes de l'ontologie. SIMS décompose alors la requête en sous requêtes propres à

chaque source, rassemble et combine ensuite les résultats. Son modèle permet d’unifier le

vocabulaire d’un domaine et du coup de résoudre les conflits de nommage [BAT 86].

18

2.2.2.5 OBSERVER

OBSERVER [MEN 00] [GON 97] [MEN 96a] [MEN 96b] associe des ontologies

représentant chacune le vocabulaire d’un domaine d’application particulier, à des sources de

données. À chaque terme du vocabulaire d’une ontologie sont associées les structures des

différentes bases de données qui lui correspondent. Les ontologies donnent une description de la

sémantique des informations indépendamment de la représentation syntaxique des données. Elles

permettent une accessibilité plus large aux données car elles peuvent être utilisées pour capturer

de nouvelles vues du monde.

Le processus de traitement de requêtes passe par plusieurs étapes. En premier lieu

l'utilisateur choisit une ontologie [GRU 93] et se connecte à elle (cette ontologie est appelée

l'ontologie de l'utilisateur). Dans la deuxième étape les termes appropriés de l'ontologie de

l'utilisateur sont choisis et la requête est traduite en utilisant des termes propres à l’ontologie

(utilisation des synonymes). Si la traduction est équivalente à la requête originale, l’ontologie est

pertinente et les réponses seront trouvées. Si l'utilisateur n'est pas satisfait de la réponse, il pourra

accéder à d’autres ontologies et les deux étapes de traduction de requête et d’accès aux données

sont répétées. L’interopérabilité à travers les ontologies est faite en traversant des relations

sémantiques définies entre les termes à travers les ontologies. Les requêtes de l'utilisateur sont

réécrites de manière à préserver la sémantique en remplaçant les termes par leurs synonymes

récupérés des ontologies. La Figure 6 expose l’architecture du médiateur OBSERVER qui est

constitué de quatre modules:

Processeur de requêtes : Il traite une requête exprimée en DL (langage de description) qui

utilise les termes d'une ontologie. Il traduit ensuite les termes de la requête en utilisant

l’ontologie, tout en conservant la sémantique de la requête.

Serveur d’ontologies : Il fournit l'information au sujet des ontologies au processeur de requêtes.

Gestionnaire des relations inter-ontologies (IRM) : Les relations de synonymie entre plusieurs

ontologies sont représentées de manière explicative dans une base de données indépendante. Ces

relations permettent d'expliciter les équivalences sémantiques entre les concepts et sont utilisées

pour réécrire une requête d'un domaine sur un autre domaine et pour résoudre les problèmes liés

au vocabulaire.

19

Les ontologies : Chaque ontologie est un ensemble de termes d'intérêt dans un domaine

d'information particulier liés entre eux.

Figure 6 : Architecture du médiateur OBSERVER

L’inconvénient de OBSERVER est dû à l’exploitation des relations entre les concepts qui

ne sont que purement terminologiques (synonymes). OBSERVER résout les conflits

sémantiques, mais ne prévoir rien pour les conflits de valeurs. Un deuxième inconvénient est dû à

la communication de différentes ontologies qui provoque une hétérogénéité d’ontologies. Cette

hétérogénéité est produite si deux systèmes font des suppositions ontologiques différentes au

sujet de leurs connaissances du domaine.

Exemple : Dans un système une maison est composée de matière de bâtiment, tel que

briques et fenêtres, et dans un autre système la maison est constituée par exemple de pièces et

douches. Le manque d'un vocabulaire commun rend extrêmement difficile de comparer des

ontologies de source différentes. [VIS 98] recense les différences entre les ontologies ainsi que

leurs solutions.

2.2.2.6 DISCO

Dans DISCO [NAA 99] [BUG 97] [TOM 96] les sources de données peuvent être des

bases de données, des fichiers, des serveurs de données ou des pages HTML. Leurs données

20

peuvent êtres structurées, semi-stucturé ou non structurés. Le modèle de données de DISCO est

une extension du modèle de données orienté objet ODMG et son langage de requêtes est OQL.

DISCO est composé d’un médiateur qui présente à l’application une vue unifiée des sources, il

reçoit une requête, l’optimise et la renvoie au wrapper. Une fois les requêtes exécutées, il

récupère les résultats, les recompose avant de les renvoyer à l’application. Un wrapper est

connecté à chaque source de données, son rôle est de fournir au médiateur une vue homogène de

la source lui permettant ainsi un accès uniforme. Le wrapper reçoit une requête du médiateur, la

traduit dans le langage utilisé par la source à laquelle il est connecté, la fait exécuter par la source

et renvoie les résultats au médiateur.

Figure 7 : Architecture de DISCO

L’utilisation de DISCO est composée de deux phases : enregistrement des sources (étape

1 et 2 sur la Figure 7) et traitement des requêtes (3 à 6). Durant la première phase le médiateur

fait appel au wrapper localisé par l’administrateur. Le wrapper envoie la description des sources.

Cette description est faite dans le langage ODL, elle contient les capacités de traitement des

wrappers, ainsi que les informations sur les coûts. Ces informations permettent au médiateur

d’évaluer le coût d’une requête avant son exécution. Dans la deuxième phase, le médiateur

récupère une requête d’une application, cette requête est envoyée au module d’analyse

sémantique et d’optimisation (étape 3 sur la Figure 7), qui analyse la requête afin de vérifier sa

cohérence et la décompose ensuite. Une fois la requête décomposée, il vérifie si les sous-requêtes

21

envoyées au wrapper n’excèdent pas leurs capacités avant de générer un plan d’exécution et

d’évaluer son coût. L’exécution de la requête passe par trois étapes, (4) contact des wrappers par

le médiateur, (5) envoi des sous requêtes et exécution par les wrappers, (6) recomposition des

résultats.

2.2.2.7 TSIMMIS

TSIMMIS [LIC 98] [GAR 97] [PAP 95] est un projet en collaboration entre Stanford et

IBM Almaden Research Center dont le but est de développer un outil facilitant l'intégration

rapide des sources de données hétérogènes qui peuvent inclure des données structurées et non-

structurées. Ces sources de données peuvent évoluer rapidement (Web et domaine de biologie).

Le modèle commun utilisé, est le modèle OEM (Modèle d'Échange d'Objet) [PAP 95]. OEM est

un modèle orienté objet flexible, auto descriptif dans lequel les objets ont des étiquettes, types,

valeurs, et un identificateur (facultatif). Il permet de définir des objets sans référence à une

structure fixe. Un langage de règles MSL est utilisé comme langage de spécification des

médiateurs et des wrappers. MSL utilise des règles de prologue et des fonctions pour traduire des

objets. Le langage de requêtes utilisé est OEM-QL afin d’interroger les objets OEM.

L’utilisateur de TSIMMIS choisit un médiateur et envoie sa requête, ce dernier génère les

plans d’exécution optimaux et envoie des sous requêtes aux différents wrappers et médiateurs. A

chaque source est connecté un wrapper qui convertit des requêtes formulées sur le modèle

commun en des requêtes propre aux sources afin d’être exécutées, et il convertit les données

récupérées des sources dans le modèle commun. Les wrappers et les médiateurs prennent comme

entrée des requêtes OEM-QL et retourne des objets OEM comme résultat.

22

Figure 8 : Architecture de TSIMMIS

La Figure 8 expose l’architecture de TSIMMIS qui est composée de :

Classifieur/Extracteur : il classifie les types d’objets (page Web, courrier électronique…)

contenus dans des pages HTML, XML ou du texte brut. Il extrait ensuite des informations telles

que : la date, le nom de l’auteur etc.

Traducteur : il traduit les requêtes formulées en OEM-QL sur le modèle commun en requêtes

propres à chaque source de données. Il traduit ensuite les résultats envoyés par ces sources dans

le format du modèle commun.

Médiateur : Il génère les plans d’exécution optimale et envoie des sous requêtes aux différents

Wrapper et médiateurs

L’intégration des données dans TSIMMIS exige la participation des humains. Son

inconvénient est dans le choix du médiateur par l’utilisateur qui ne possède pas d'informations

sémantiques pour identifier les médiateurs qui répondent à ses besoins. Le modèle de

représentation des données de TSIMMIS est simple et n'est pas très adapté à la représentation des

informations complexes.

23

2.2.2.8 EDC

Le médiateur d’EDC (Energy Data Collection) [AMB 01] a été conçu au sein du projet du

même nom pour permettre l’accès à des sources d’information hétérogènes dans le domaine de

l’énergie (centres de recherche, statistiques, etc.). Il prend en entrée des requêtes exprimées en

OLAP (On-line Analytical Processing) [CHA 96] qu’il envoie ensuite au planificateur de

requêtes développé dans l’architecture de SIMS [ARE 97]. Ce dernier se charge de renvoyer les

réponses au client en interrogeant les bases susceptibles de contenir les informations recherchées.

Le médiateur EDC a deux types de fonctionnement. Dans le premier il récupère les

données directement à partir des bases de données et des sources Web. Ce type de

fonctionnement est performant dans le cas où les requêtes seraient simples. Dans le cas contraire

où les requêtes sont complexes et ont besoin d’une quantité importante de données et de

ressources, l’accès direct aux informations ne donne pas toujours à l’utilisateur le niveau

d’interaction recherchée. Dans le deuxième type de fonctionnement, le système stocke une partie

des informations dans un entrepôt de données afin de rendre l’exécution des requêtes complexes

plus performante. Ce type de fonctionnement est certes plus rapide mais gourmand en ressources.

En plus les données présentes dans l’entrepôt ne sont pas mises à jour en même temps que les

sources de données.

2.2.2.9 MOMIS

Le projet MOMIS (Mediator envirOnment for Multiple Information Sources) [BEN 01]

[BER 01] [BER 99a] [BER 98] concerne la création d’un médiateur basé sur les systèmes

d'intégration de données structurées et semi-structurées. Il a été développé en collaboration entre

l'Université de Modène et Reggio Emilie et l’Université de Milano et Brescia. Il a été conçu pour

permettre l’accès à des sources d’informations hétérogènes stockées dans des bases de données

classiques (relationnelles et orientées objet), des systèmes de fichiers et des sources de données

semi-structurées. Il utilise le langage de requête OQLi³ dérivé d’OQL pour interroger les sources.

Son modèle de données est ODMG. Un thesaurus commun jouant le rôle d'une ontologie

partagée est construit en extrayant les relations terminologiques entre les schémas des sources.

Les wrappers de MOMIS traduisent les schémas des sources hétérogènes dans un modèle

24

commun orienté objet. La traduction est basée sur les liens trouvés dans le thesaurus. Les

schémas des sources sont analysés, et la vue globale est construite semi automatiquement en se

fondant sur les relations entre les concepts des schémas sources.

Figure 9 : Architecture de Momis

Le médiateur est composé de deux modules : Le module « Global Schema Builder »

(GSB) qui génère le schéma global présenté à l’utilisateur à partir des descriptions des sources

faites avec ODLi³. Le module Query Manager (QM) est le gestionnaire de requêtes, il génère

automatiquement à partir de la requête de l’utilisateur, des requêtes en OQLi³, qui sont envoyées

aux wrappers.

2.3 Conclusion

Dans les deux types d’approches (les approches de médiations et les approches fédérées)

présentées ci-dessus, la construction des schémas médiateurs ainsi que les correspondances

nécessite beaucoup d’interventions manuelles. L’utilisateur indique les ressemblances entre les

différents schémas de sources. Une fois les ressemblances trouvées, elles sont regroupées pour

créer leur équivalent (relation ou attribut) dans le schéma médiateur. La deuxième limite est que

la modification des schémas des sources de données engendre la régénération entière du schéma

médiateur.

25

En conclusion voici deux tableaux récapitulant les systèmes présentés dans ce chapitre. Le

premier tableau contient les systèmes de médiation et le deuxième les systèmes de fédération. Les

tableaux montrent pour chaque système son modèle de données, son langage de requêtes et la

représentation sémantique des données. En plus des informations, les inconvénients et les

avantages de chaque système sont montrés.

Système Modèle de

données Langage de

requêtes Inconvénients (-) & avantages (+)

TSIMMIS OEM LOREL - Pas adaptable pour la représentation des informations complexes.

Observer Terminologique Langage de description

- Exploitation des ontologies purement terminolgique (relation synonyme)

DISCO Extension de ODMG

OQL + Le médiateur gère l’absence des réponses d’un SI + Résout les conflits de nommage et de valeur

MIX XML Vue SIMS LOOM LOO + Résout les conflits de nommage

- Conflits structurels et sémantiques non résolus

EXML-MEDIA XML XQuery / XML-QL

EDC LOOM OLAP - Fonctionnement gourmand en ressources. - Les données présentes dans l’entrepôt ne sont pas mises à jour en même temps que les sources de données

MOMIS ODMG OQLi3 PICSEL Carin CARIN/core-

CLASSIC - L’utilisation du vocabulaire commun

limite l’autonomie des sources de

données locales

Tableau 1 : récapitulatif des systèmes de médiation

26

Système Modèle de

données Langage de requêtes Exploitation

Garlic ODMG Langage de requêtes de Garlic

Browser & méta-données

L’approche de Florescu

ODL Oql Interface d'accès définie en ODMG

InfoMaster

Relationel Logique Interface WEB

Information Manifold

Relationnel + hiérarchies de

classes

Requêtes sur la vue

Intégrateur de données biologiques

XML Requêtes via un formulaire

Formulaire

Tableau 2 : récapitulatif des systèmes de fédération

27

3 Construction d’une vue unifiée à partir de schémas de sources

3.1 Introduction

L’un des problèmes concernant l’intégration des bases de données est la recherche des

ressemblances entre les schémas (matching). Trouver ces ressemblances est une problématique

qui concerne beaucoup de domaines d’applications. Plusieurs travaux ont été faits à propos de

l’automatisation des matchings des schémas [SHV 04] [DOH 02] [RAH 01c], dont quelques-uns

seront présentés dans cette partie. Le matching prend deux schémas comme entrée et génère un

mapping entre les éléments similaires dans les deux schémas et qui se correspondent

sémantiquement [LIW 94]. Il est utilisé dans de nombreuses applications, tels que l’intégration

des données, le commerce électronique, les entrepôts des données, la conception de bases de

données…etc. Actuellement la plupart des matchings sont exécutés manuellement, et peuvent

supporter une interface graphique. Spécifier manuellement des matchings de schémas est délicat

et consomme beaucoup de temps, et par conséquent il devient un processus coûteux. De nos jours

les bases de données tendent à croître et le nombres des sources de données aussi. De plus les

systèmes deviennent capables de manier des bases de données plus complexes, leurs schémas

deviennent plus grands, ce qui complique le processus de matching.

3.2 L'opération de « matching »

L'opération de matching est une fonction qui prend deux schémas S1 et S2 en entrée et

génère un mapping entre ces deux schémas [MAD 00]. Les schémas peuvent être de type entité-

relation(ER), orienté objet (O.O), XML ou graphe tagé. Un mapping est un ensemble de

correspondances, où chacune des correspondances indique que certains éléments de S1 sont

mappés à certains éléments de S2. En outre chaque mapping d’un élément peut avoir une

expression de mapping qui spécifie comment les éléments de S1 sont reliés aux éléments de S2.

L'expression de mapping peut être une simple relation scalaire (=, <=) une fonction (addition ou

concaténation), des relations (par exemple, IS-A), etc.. Le Tableau 3 expose un exemple de deux

28

schémas S1 et S2 qui représentent des informations sur des patients. Un mapping entre S1 et S2

pourrait contenir un élément qui fait correspondre les numéros des patients des deux schémas

avec l'expression de mapping «Patient.Code = Malade.Numordre ». Un autre mapping avec

l'expression “Concatenate (Malade.Nompersprev, Malade.Prenompersprev) =

Patient.contactpatient” décrit un mapping de deux éléments de S1 à un seul élément de S2.

Patient (schéma S1) Malade (schéma S2)

Numordre Code Nom Nompat

Contactpatient Nom Tel Nompersprev

Prenompersprev Tableau 3 : structure de deux schémas hétérogènes

3.3 Différents types de matching Un système de mapping peut utiliser de multiples algorithmes de matching selon le domaine

d’application et les types de schémas. Dans [RAH 01a] les types majeurs ont été classés en cinq

catégories :

Instance VS schéma : Il concerne les instances des schémas ainsi que ses informations.

L'information sur les schémas inclut les propriétés des éléments d’un schéma, tels que le nom, les

descriptions, les types de données, le type des relations (par exemple IS-A), les contraintes, et la

structure du schéma. Ce type de matching peut utiliser des approches linguistiques [GIU 04a]

[GUI 04b] [COH 03] telles que la similarité des noms des éléments : égalité de noms, synonymes

(voiture = automobile), égalité de représentations canoniques (NumEmp = numéroEmployé)

parties communes (représenté_Par = représentant), etc. ou les descriptions fournies dans les

schémas. Certaines techniques utilisent un assemblage au niveau des instances, par exemple en

exploitant un ensemble de mots clés qui peuvent apparaître dans les instances (tels que "excellent

état" pour la description) ou la structure du contenu de l’élément (un numéro de téléphone est un

nombre à 10 chiffres), etc.

Élément VS matching de structure : Il est exécuté sur les éléments du schéma (e.g les attributs)

ou sur une combinaison d'éléments (e.g les structures complexes de schéma). Le matching des

29

éléments consiste à déterminer pour chaque élément du premier schéma, ses correspondances

dans le deuxième schéma.

Langage VS contrainte: Ce matching peut utiliser une approche basée sur une linguistique (les

noms ou les descriptions textuelles des éléments d’un schéma) ou une approche basée sur les

contraintes (clés primaires, étrangères ou les relations). Les approches linguistiques utilisent les

noms et les textes (mots ou phrases) pour trouver les similarités dans le schéma. Elles exploitent

les descriptions des schémas tels que les commentaires exprimant la sémantique des éléments

d’un schéma. Ces commentaires peuvent aussi être traités linguistiquement pour déterminer la

ressemblance entre les éléments. Les approches basées sur les contraintes [VAL 99] [VAL 97]

quant à elles, concernent les types des données, les gammes des valeurs, les types de relations, les

cardinalités, etc. Ces informations sont utilisées pour déterminer la ressemblance entre les

éléments des schémas. Une ressemblance peut être basée sur l'équivalence des types des données

et des domaines, les caractéristiques des clés (par exemple, unique, primaire, étrangère), les

cardinalités ou les types de relations.

Exemple :

Patient (schéma S1) Malade (schéma S2)

Code Pk Numordre PK Nom String Patnom String

Datenaiss Date Naissance Date Adresses String Adr Sting

Tableau 4 : Les différentes cardinalités du mapping

Les attributs datenaiss et naissance du Tableau 4 sont les seuls attributs de type date, nous

pouvons alors en déduire qu’ils peuvent être similaires.

Cardinalité : Le résultat du matching peut relier un ou plusieurs éléments d’un premier schéma à

un ou plusieurs éléments d’un deuxième schéma. Nous pouvons avoir quatre types de cardinalités

: 1:1, 1:n, n:1, n:m. De plus, chaque élément du mapping peut mettre en corrélation un élément

ou plus des deux schémas.

30

Information auxiliaire : La plupart des matchings n’exploitent pas que les informations des

schémas en entrée, mais également les informations auxiliaires, tels que les dictionnaires, les

décisions de matching antérieures, ainsi que les entrées des utilisateurs. L’exploitation des

synonymes et des hypernym exige l’utilisation d’un thésaurus (exemple Wordnet [MIL 95]) ou

de dictionnaires multilingues dans le cas où les schémas seraient de différentes langues.

3.4 Les principales approches de matching

3.4.1 TranScm

TranScm [MIL 98] [ZOH 97] examine les schémas sources et cibles sous forme de

graphe, et essaie de trouver des similarités et des différences entre eux. Il utilise une méthode

basée sur des règles où chaque règle manie les similarités communes entre deux composants de

schémas, et fournit des moyens pour traduire une instance du premier composant à une instance

du second. Ces règles peuvent être ajustées ou modifiées par l’utilisateur.

Le matching est exécuté nœud par nœud en commençant par le sommet. Il utilise les

règles et essaie de trouver pour chaque composant du schéma source une unique correspondance

« meilleur matching » à un composant dans le schéma cible ou détermine que le composant ne

devrait pas être représenté dans le schéma. Chaque règle a deux composants, la première

s’occupe des ressemblances et la deuxième de la traduction. La première partie consiste en deux

fonctions de base : une fonction de similarité, qui prend deux arcs en entrée V1 et V1 du graphe

du schéma, examine leur tag et détermine s’ils sont égaux ou non. La ressemblance est

conditionnelle avec les similarités des composants des arcs (c.-à-d. leurs descendants dans le

schéma), ce qui est déterminé par la deuxième fonction, appelé fonction Descendant. Pour chaque

paire d’arcs V1 et V2, la fonction Descendant renvoie deux ensembles de descendants de V1 et

V2 qui seront égalés. La partie de la traduction quant à elle, consiste en une fonction Translation

qui est responsable de la traduction des instances.

Dans cette approche il existe deux cas où le matching ne fonctionne pas (i) un composant

du schéma source ni similaire à aucun autre composant cible ou (ii) un composant du schéma

source est similaire à plusieurs composants du schéma cible. Dans ce cas le système ne peut

déterminer automatiquement la meilleure correspondance. Pour les résoudre (i) l'utilisateur peut

31

ajouter des règles au système permettant de manier ce composant et décrire la traduction qui lui

est appliquée. (ii) le système demande à l'utilisateur de déterminer le meilleur matching. L'entrée

de l'utilisateur est ajoutée au système comme une nouvelle règle avec une plus haute priorité que

celle de la règle qui cause l'ambiguïté.

Une fois le matching terminé, une traduction des données est possible. Pour exécuter la

traduction, une instance du schéma source est importée dans le modèle de données commun.

Chaque élément est traduit en utilisant la fonction de traduction de la règle qui égale son

composant avec un composant du schéma cible. Les éléments résultants formeront une instance

valide.

Un prototype a été développé, contenant une interface graphique qui peut afficher à

chaque point les deux schémas et l'ensemble des similarités déterminées par les règles du

système. Quand il y a des ambiguïtés dans les ressemblances, le système affiche à l'utilisateur la

ressemblance partielle. L’utilisateur peut ainsi ajouter et modifier les règles afin de mieux gérer le

processus du matching.

3.4.2 LSD (Learning Source Descriptions for Data Integration)

LSD [DOA 02] [DOA 01] [DOA 00] utilise des techniques d'apprentissage automatique

afin d’exécuter un matching basé sur les instances, ainsi que sur les informations sur le schéma de

données. LSD fait correspondre les nouvelles sources de données à un schéma global

précédemment déterminé. Cette approche est basée sur l’idée qu’après avoir faire correspondre

manuellement un ensemble de sources de données au schéma médiateur, l’utilisateur

(administrateur du système) transmet au système son "savoir-faire". Pour ce faire LSD utilise

quatre modules « d’apprentissage », le premier ne traite que les éléments textuels tels que les

descriptions et les observations. Un deuxième exploite les fréquences d’un mot. Le troisième

quant à lui, recherche les similarités en se basant sur les ressemblances des noms. Le dernier

module recherche une base de données dans le web pour vérifier si une instance est un pays (ville

ou autre). Le processus de matching est composé de deux phases : l’apprentissage et la

classification. Dans la phase d’apprentissage, un matching manuel entre le schéma d’une source

et le schéma de médiation est appliqué. Cet apprentissage est effectué à l’aide d’un échantillon de

données. Durant la deuxième phase, les modules d’apprentissage classifient les éléments de

32

l’échantillon de données et renvoient les différents matching ainsi que des coefficients de

confiance. Une fois les deux phases terminées, les différents résultats sont combinés afin de

donner une prédiction finale.

En résumé LSD est un système qui reçoit en entrée des informations antérieures sur les

mappings, et un ensemble d’objets d’un élément à faire correspondre. Il génère à partir de ces

informations une liste de prédictions pour les objets, qui est utilisée pour générer un résultat final

afin faire correspondre les éléments.

3.4.3 SemInt

SemInt [LCW 94] représente une approche hybride qui exploite les informations des

schémas (type de données, taille et contrainte de domaine), et des instances afin d’identifier des

attributs qui se correspondent entre différents schémas relationnels. SemInt a également la

capacité à réutiliser ou à adapter la connaissance acquise durant le processus de la résolution des

hétérogénéités sémantiques pour résoudre le problème des ressemblances (exemple les salaires

des employés dans deux bases de données différentes sont des grands nombres supérieurs à zéro)

[LIW 00]. Le problème qui se pose est comment trouver ces ressemblances. Durant le processus

de matching décrit dans [LCL 00], des analyseurs extraient de l'information (schéma ou contenu

des données) des bases de données. Ils se basent sur cette information pour faire la distinction

entre les attributs. L’information sur les champs comporte les types des données, la longueur, le

format, les contraintes et autres. Le contenu des données des différents attributs a tendance a être

différent, bien que parfois la conception des schémas soit la même (type de données et taille). Par

exemple dans la relation « Patient », le code du patient et son numéro de sécurité social sont deux

informations différentes (ils sont différents dans leur contenu), pourtant elles ont la même taille et

le même type. Nous ne pouvons pas distinguer ces informations en ne se basant que sur leurs

contraintes. Dans ce cas l’examen du contenu est nécessaire et il peut corriger ou rehausser

l'exactitude des résultats de l’analyse. Pour chaque attribut, une analyse du domaine est exécutée

(comparer le contenu complet de chaque paire d’attributs) pour obtenir un ensemble de

caractéristiques qui décrivent les données. Ces caractéristiques peuvent être de deux types :

caractère ou numérique. Pour les champs de type caractère, plusieurs critères sont étudiés tels que

la proportion des caractères blancs dans l’ensemble des caractères contenu dans un champ

(exemple : les noms et prénoms contiennent peu de caractères blancs, par contre une adresse en

33

contient beaucoup). Pour les champs de type numérique, l’analyse statistique est utilisée. Par

exemple les éléments représentant des dimensions différentes sont différents dans leur niveau de

granularité (ventes annuelles et ventes mensuelles).

SemInt détermine un coefficient qui consiste en une valeur dans l'intervalle [0,1] pour

tous les critères de ressemblance impliqués. Pour ce faire, il utilise 15 critères de matching basés

sur les contraintes et 5 critères basés sur le contenu, où chaque critère a une fonction de mapping.

Les coefficients sont utilisés ensuite pour regrouper les attributs similaires du schéma en premier

et puis trouver le meilleur groupe similaire pour les attributs du deuxième schéma. Le processus

de regroupement et de classification est exécuté en utilisant un réseau de neurones avec un

apprentissage automatique. Ce réseau peut déterminer les attributs semblables entre les bases de

données. Les réseaux de neurones sont une technique puissante de la reconnaissance de modèles

de données. Ils peuvent reconnaître les ressemblances parmi les données directement à partir des

instances. Ils s’adaptent facilement aux nouveaux problèmes et peuvent déduire des relations

méconnues par les programmeurs. Le résultat du matching consiste en des groupes d’attributs

similaires des deux schémas entrés, avec une cardinalité multiple M : N.

En résumé SemInt représente une approche puissante et flexible avec un matching

hybride, par contre il ne supporte pas de matching basé sur les noms.

3.4.4 Vues globales

[CAS 01b] construit des vues globales en lecture pour les éléments des schémas en se

basant sur les affinités entre eux. Cette approche adopte un modèle de données basé sur le modèle

relationnel enrichi par les caractéristiques de l’orienté objet. Il inclut des relations et des classes.

Les relations contiennent des tuples et les classes des objets ayant un identifiant unique. Les

classes ont également des attributs et peuvent appartenir à une hiérarchie ‘IS-A’ avec héritage des

attributs. Durant la première étape, une analyse est effectuée sur les éléments des schémas où le

concept d’affinité est utilisé pour identifier des éléments des différents schémas ayant une

relation sémantique. Il existe deux types d’affinités, l’affinité des noms et l’affinité structurelle.

Durant la première, le contenu sémantique des noms des éléments est analysé en se basant sur

l’exploitation de la terminologie employée dans les schémas et qui est fournie au moyen de

thésaurus. Une fois l’analyse terminée, les termes sont groupés en utilisant des relations

34

terminologiques selon leur sémantique. Ces relations peuvent être des relations de synonymie

(patient = malade) ou d’hyponymies (individu et patient). Afin de trouver les affinités

structurelles, les propriétés des éléments des schémas sont analysées en prenant en compte les

noms, les domaines et les cardinalités. L’établissement d’une correspondance sémantique entre

les propriétés consiste en deux étapes : l’évaluation de l’affinité des noms en recherchant les

propriétés avec la même signification et l’évaluation de la compatibilité du domaine en testant si

leurs représentations de valeur de données sont similaires. Il faut noter que les deux types de

similarités ont des coefficients d’affinité. Une fois les affinités ainsi que leurs coefficients ont été

calculés, la vue est construite et présentée au concepteur qui vérifie sa consistance avant de la

valider.

Cette approche ne fonctionne pas dans le cas où deux éléments seraient identiques mais

n’auraient pas d’affinité de noms. Exemple PAT & PATIENT

3.4.5 ARTEMIS

ARTEMIS [CAS 01] [CAS 97] est un composant du médiateur de base de données

hétérogènes MOMIS (Médiateur envirOment pour les Multiples sources d'informations) décrit en

paragraphe 2.2.2.9 [BER 99b]. Son approche de matching est hybride basée sur les schémas. Il

rassemble les classes en se basant sur leur affinité de nom et de structure [CAS 99]. Les classes

des schémas à intégrer sont regroupées pour obtenir les classes globales constituant le schéma

médiateur. Pour ce faire, ARTEMIS [CAS 01b] calcule les affinités structurelles pour toutes les

paires de classes, basé sur leur affinité de nom et attributs. Il regroupe ensuite ces classes en se

basant sur les affinités de nom et de structure. Une fois les classes regroupées, le même

traitement est appliqué sur les attributs similaires, qui sont ensuite fusionnés.

ARTEMIS opère sur un modèle hybride orienté objet–relationnel qui inclut le nom, le

type des données, la cardinalité des attributs, et les types des objets cibles. Il calcule les

similarités entre les noms, les affinités des types de données et les affinités structurelles.

L’affinité des noms est calculée en utilisant un thésaurus de domaine (WordNet [MIL 95]) où

chaque association de deux noms peut être un synonyme, un hyponyme ou une relation de

généralisation, avec une affinité fixe pour chaque type d’association. L’affinité des types de

35

données est basée sur une table générique de compatibilité des données. L’affinité structurelle,

quant à elle, est basée sur la ressemblance des relations.

3.4.6 Cupid

Cupid [YAT 03] [MAD 00] est une approche de matching basée sur les schémas, qui

combine un matching linguistique avec un matching de structure. Le processus de matching se

compose de deux étapes. Durant la première les schémas des sources de données sont convertis

en arbres. Durant la deuxième étape CUPID utilise un algorithme afin de calculer les coefficients

de ressemblance entre les éléments de deux schémas en utilisant un matching linguistique basé

sur leurs noms, le type des données, les contraintes du domaine, etc. A chaque ressemblance est

affecté deux poids dus aux deux types de matching. Ces coefficients sont calculés en deux

phases. Durant la première phase, le matching linguistique fait correspondre les éléments de

schémas en se basant sur leurs noms, les type de données, les domaines etc. Pour ce faire, il

utilise un thesaurus pour le matching des noms permettant d’identifier les formes courtes (Qté

pour Quantité), acronymes (UdM pour UnitéDeMesure) et synonymes (Delivrer à et livrer à). Le

résultat est un coefficient de ressemblance linguistique entre chaque paire d'éléments. Durant la

deuxième phase, un matching structurel des éléments du schéma est effectué, en se basant sur la

ressemblance de leurs contextes ou de leurs voisinages.

Exemple : Ligne dans la Figure 10 est mappé à NumArticle vu que leurs parents, Article,

se correspondent et les deux enfants (qte et Unite) se ressemblent également. Le résultat de cette

phase est un coefficient de ressemblance structurel pour chaque paire d'éléments. Une fois

terminé, le poids de ressemblance, qui est la moyenne des deux coefficients de ressemblance

calculé. Un mapping est créée en choisissant les paires d'éléments du schéma avec des

ressemblances ayant un poids maximal. Le mapping trouvé est de cardinalité 1:1.

Le prototype de Cupid fonctionne actuellement avec les schémas XML et relationnels. Il

présente à l’utilisateur une interface graphique lui permettrant d’améliorer les résultats du

matching.

36

BC

BCArticles LivrerA

NBRArticle Article

UdM

quantite

Ligne Adresse

Rue CP

VenduA

Adresse

Rue CP

Bon de commande

Articles DélivrerA

NBRArticle Article

Unite de mesure

qteNumArt Adresse

Rue CP

FacturerA

Adresse

Rue CP

Figure 10: Deux arbres de deux parties de bases de données

3.4.7 Clio (IBM Almaden et Univ. de Toronto)

Clio [POP 02] [YAN 01] [LIW 94] est un outil visant à créer interactivement

(intervention de l’utilisateur) des mappings entre un schéma cible donné et un nouveau schéma.

Pour ce faire l’utilisateur charge les schémas source et cible dans Clio. Ces schémas sont lus

d'une base de données Objet-Relationnelle ou d'un fichier XML avec un Schéma XML associé. Il

connecte ensuite graphiquement les objets du schéma source avec les objets du schéma cible

[MIL 01] [HAA 99]. Ces liens sont appelés des correspondances de valeurs. Clio fournit un

navigateur de schéma et de données permettant aux utilisateurs de comprendre le mapping

produit. L’interface graphique facilite le processus de localisation et de chargement de schémas

ainsi que la création des correspondances de valeurs. Les utilisateurs peuvent ajouter et effacer

des correspondances de valeurs de cette vue et immédiatement voir les changements dans les

tuples résultant de la cible [MIL 00]. Clio stocke les mappings et à chaque modification de

l’utilisateur, le mapping est regénéré. Une fois l’intervention de l’utilisateur terminée, le moteur

de mapping de Clio « Descouvre » [YAN 01] implémente le mapping sous forme d’une requête

(SQL, XQuery) et permet à Clio de traduire un mapping de haut niveau (correspondances de

valeurs) dans une représentation de bas niveau (une requête).

3.5 Conclusion En conclusion, nous présentons un tableau (Tableau 5) comparatif des différents systèmes

présentés dans cette partie.

37

Sem

Int

LSD

A

rtem

is

Tra

nSco

m

V.G

C

lio

Cup

id

Type

de

sché

ma

Rel

atio

nnel

Fi

chie

r X

ML

Rel

atio

nnel

, O

.O, E

.R

SGM

L, O

O

Rel

atio

nnel

X

ML

et o

bjet

re

latio

nnel

X

ML

et re

latio

nnel

Gra

nula

rité

du m

appi

ng

Elém

ents

&

attri

buts

El

émen

ts &

st

ruct

ures

El

émen

ts,

stru

ctur

es,

entit

és e

t at

tribu

ts

Elém

ents

El

émen

ts &

st

ruct

ures

El

émen

ts

Elém

ents

&

stru

ctur

es

Car

dina

lité

du m

appi

ng

1 :1

1

:1

1

:1

1 :1

1

: N

1 : 1

1

: N

1 : 1

Bas

é su

r les

no

ms

- Sy

nony

me

Syno

nym

e,

hypo

nym

e Sy

nony

me,

hy

pony

me

Syno

nym

e,

hypo

nym

e -

Form

e co

urte

, sy

nony

me,

ac

rony

me

Bas

é su

r les

co

ntra

inte

s Ty

pe d

e do

nnée

s, ta

ille,

clé

s…

D

omai

nes,

cl

és

Car

dina

lités

des

re

latio

ns

Dom

aine

s, ca

rdin

alité

s -

Type

s des

don

nées

, do

mai

nes

Réu

tilis

atio

n/

info

rmat

ions

au

xilia

ires

C

ompa

rais

on a

vec

les m

atch

ings

an

térie

urs

thés

auru

s

thés

auru

s C

ompa

rais

on a

vec

les m

atch

ings

an

térie

urs

-

Inte

rven

tions

m

anue

lles /

en

trées

ut

ilisa

teur

Séle

ctio

n de

s cr

itère

s de

mat

chin

g

Cré

atio

n de

s do

nnée

s des

m

odul

es

« d’

appr

entis

sage

»

Util

isat

eur

ajus

te le

s ré

sulta

ts

Rés

oud

le

mat

chin

g m

ultip

le, a

jout

e de

nou

velle

règl

e et

les a

just

e

Util

isat

eur

vérif

ie le

s ré

sulta

ts a

vant

co

nfirm

atio

n

Util

isat

eur f

ait

corr

espo

ndre

les

inst

ance

s

-

Rés

ulta

t du

mat

chin

g C

orre

spon

danc

es

entre

les é

lém

ents

av

ec u

n po

ids [

0,1]

Cor

resp

onda

nces

en

tre le

s élé

men

ts

avec

un

poid

s [0,

1]

Des

cla

sses

re

grou

pées

se

lon

leur

af

finité

Cor

resp

onda

nces

en

tre le

s él

émen

ts

Une

vue

gl

obal

e R

equê

te S

QL

Cor

resp

onda

nces

en

tre le

s élé

men

ts

avec

un

poid

s [0,

1]

Rem

arqu

es

Util

isat

ion

des

rése

aux

de

neur

ones

Util

ise

la n

otio

n de

co

rres

pond

ance

de

vale

urs

Se b

ase

sur l

e vo

isin

age

Tab

leau

5 :

Tab

leau

com

para

tif d

es d

iffér

ente

s app

roch

es d

e m

atch

ing

38

4 Les ontologies

4.1 Introduction

Dans beaucoup de domaines le nombre de données augmente énormément et leur

partage pose des problèmes. Ces problèmes sont dus à l’hétérogénéité des données stockées

dans les différents systèmes. Nous pouvons distinguer deux types d'hétérogénéité [VIS 98] :

l’hétérogénéité des données et l’hétérogénéité sémantique. La première fait référence aux

différences entre les définitions locales, tel que le type ou le format des données. La deuxième

quant à elle, concerne les différences ou les ressemblances dans la signification des données

locales. Par exemple, deux éléments dans deux sources de données locales peuvent avoir la

même signification, mais des noms différents. Ou bien, deux éléments dans deux sources

différentes de données peuvent être nommés identiquement, alors que leurs significations sont

incompatibles. Donc ces éléments devraient être traités comme deux éléments différents

pendant l’intégration. En conséquence, pour que l'intégration des données soit adéquate et

significative nous devons prendre en compte la découverte des contradictions et des

ressemblances entre les éléments de différents schémas. Pour accomplir une intégration et

résoudre les problèmes d’hétérogénéité sémantique, les différents systèmes doivent utiliser les

mêmes termes ou trouver des liens entre les différentes structures. Ceci nous a amené à nous

intéresser à l’utilisation des ontologies [HAK 01]. En effet comme présenté dans le chapitre

suivant, pour notre solution nous utilisons deux ontologies, une première pour la structure du

dossier médical et une deuxième pour les valeurs stockées.

4.2 Définition de l’ontologie

4.2.1 Définition philosophique

Le terme ontologie a été proposé pour la première fois par deux philosophes

allemands, Göckel et Lorhard, en 1613. Il s’agissait d’un néologisme dérivé du mot grec

"onto" qui signifie l’existence d’où l’ontologie est la science d’un "existant". [USC 96] la

définit comme une branche de la philosophie qui a comme objet ce qui existe sous la forme

d'une description abstraite, en insistant sur des catégories, principes et traits généraux. La

philosophie traite d'une ontologie générale qui réfère à toute l'existence. Il y a également des

39

ontologies partielles, propres à un domaine précis selon le cas: physique, chimie, médecine,

etc.

4.2.2 Les ontologies dans le cadre de la science informatique

Les ontologies permettent une représentation de la connaissance d’un domaine sous la

forme d’une hiérarchie de concepts et de relations sémantiques entre ces concepts [GRU 93].

L’utilisation d’une ontologie commune entre plusieurs systèmes garantit la cohérence lors de

l’échange des données. Les concepts admettent la même signification pour tous les systèmes.

Ainsi les relations sont interprétées d’une façon homogène. Comme le schéma conceptuel

dans un SGBD joue le rôle d’assurer une description logique permettant aux programmes

d’applications d’intéropérer avec la base de données, les ontologies jouent le même rôle que

les schémas conceptuels dans les systèmes de bases de connaissance. Well l’a défini comme

suit : “Une ontologie est la définition de concepts, relations entre concepts, contraintes et

règles d’inférences qui seront utilisés par un système de représentation des connaissances.”

[WEL 98].

4.3 Les ontologies en médecine

La médecine est un domaine complexe qui utilise de très nombreux termes et

concepts. La communication de plus en plus importante d’informations médicales entre les

différents professionnels de santé rend le recours aux ontologies tout à fait indispensable.

4.3.1 Les principales ontologies médicales

4.3.1.1 ON9

ON9 [GAN 98] [STE 97] est une librairie d’ontologies décrite en Ontolingua [GRU

92] et LOOM [MAC 91]. Elle inclut des milliers de concepts. Ce travail a mené à une

intégration de cinq systèmes de terminologie médicale. Pour ce faire la méthodologie

ONIONS (ONtologiq Integration On Naïves Sources) [GAN 99] [STE 97] [GAN 96] a été

utilisée pour construire cette ontologie. ON9 inclut des milliers de concepts médicaux. Parmi

les ontologies qui la constituent, SNOMED [COT 93], ICD (identifient les maladies), UMLS-

SN(orienté vers les connaissances scientifiques)…

40

SNOMED est une nomenclature multiaxiale de plus de 130 000 termes médicaux et de

11 axes. Aucune information n’est donnée sur les propriétés linguistiques des concepts. Les

termes possèdent des relations hiérarchiques à l’intérieur de chacun des 11 axes.

4.3.1.2 GALEN

Le Système GALEN [REC 93] [REC 92] est un Projet Européen (Anglais, Hollandais,

Suisse) dont l’objectif est la modélisation des concepts médicaux, et la production d’un

serveur de terminologie générique voulant représenter toute la terminologie médicale au sein

d'une ontologie de concepts. Il est composé d’un ensemble de concepts et de relations (rôles).

La relation IS-A est l’opération fondamentale. Elle donne aux concepts une structure de

graphe dirigé acyclique.

4.3.2 UMLS

UMLS (Unified Medical Language System) [PIS 99] [REC 94] [HUM 92], est un

vaste projet conçu par la NLM (National Library of Medicine) aux Etats-Unis. Son objectif

est d’unifier les classifications médicales et de présenter un thésaurus pour la recherche

d’information. Il est composé d'environ 40 vocabulaires qui contiennent plus de 700 milles

concepts biomédicaux et plus d’un million de termes pour les décrire. Il intègre actuellement

la quasi-totalité des nomenclatures standards utilisées pour coder ou indexer l'information

biomédicale. La base de connaissances de UMLS contient, entre autres, une ontologie et un

méta thesaurus constituant une base unifiée des concepts médicaux. La version de 2000

contient 730 000 concepts, 1 330 000 Termes et 1 718 000 Chaînes. Le meta-thesaurus

recense tous les concepts inventoriés dans les nomenclatures intégrées à UMLS. Il est

constitué de 135 types sémantiques (Exemple Types anatomiques) reliés par des relations. Les

135 types sémantiques constituent une hiérarchie (un arbre) structurée par la relation IS-A.

Chaque concept du métathésaurus possède un ou plusieurs types sémantiques.

4.3.3 Nautilus

Nautilus [DIE 04a] est une ontologie médicale sous forme de base de données

contenant une nomenclature où les termes sont reliés entre eux par des liens de type : "est un",

"se situe sur", "se mesure en". Cette ontologie a été étendue par l’équipe ACACIA [Die 04b]

41

en y intégrant des concepts qui concerne les réseaux de soin. Une fois ces concepts intégrés,

leurs relations avec les autres concepts existant déjà dans l’ontologie Nautilus ont été définis.

Nautilus est représentée dans un formalisme standard de représentation des connaissances,

RDF(S) (Resource Description Framework Schema [BEC 01] [LAS 99]). RDF(S) est un

langage recommandé par le W3C [W3C 03] pour la description des ressources du Web, il est

intéressant pour décrire des ressources accessibles via un réseau local, un intranet ou un

extranet.

4.3.4 MED

MED (Medical Entities Dictionary) [GUH 99] [ZAP 97] est un vocabulaire contrôlé

servant de passerelle normalisée entre les vocabulaires de différents systèmes cliniques du

« Columbia Presbyterian Medical Center ». L’ensemble des concepts est hiérarchisé par la

relation IS-A, et forme un graphe dirigé acyclique : certains concepts peuvent posséder

plusieurs pères. Les concepts du haut du graphe ont été repris du métathésaurus UMLS. MED

décrit chaque concept sous forme d’un objet possédant des propriétés et des relations

sémantiques, qui sont héritées par les objets fils. Cette description structurée permet l’accès

aux concepts selon leurs propriétés.

Les ontologies générales de la médecine représentent un très grand nombre de

concepts. Ceci a poussé à chercher à développer des ontologies partielles relatives à une

pathologie spécifique par exemple cancer du sein, maladies coronariennes.

4.3.4.1 Ontologie du cancer du sein

Une ontologie du cancer du sein a été conçue dans le cadre du projet européen Inface

[SIM 04]. Elle a été développée à partir d’une ontologie générale de L&C, qui comporte 5000

concepts liés au cancer du sein. En plus de l’ontologie L&C de départ, conçue par la société

belge « Language and Computing », des corpus de textes anglais et français du domaine ont

été utilisés. Des termes provenant de la nomenclature médicale MEDCIN [MED 97] ont été

également pris en compte. Le corpus français contenait 670 fichiers, dont 68 articles

scientifiques, 20 compte-rendus médicaux et des pages web contenant des textes provenant de

diverses nomenclatures et classifications. Le corpus anglais était plus centré sur des textes

scientifiques.

42

4.3.4.2 MENELAS

MENELAS [BOU 94] est une ontologie construite pour les pathologies coronariennes,

elle est constituée de 1800 types de concepts atomiques et 300 relations, structurés en arbre

contenant des relations de type IS-A. MENELAS comprend aussi des lexiques sémantiques et

morpho-syntaxiques de mots simples et composés.

4.4 Conclusion

Dans cette partie nous avons défini les ontologies et nous avons fait un tour d’horizon

sur les ontologies médicales existantes. Ces ontologies sont peu satisfaisantes pour notre

problématique (manque d’informations, de liens, etc.) ou sur définies, c’est-à-dire contenant

plus de détails qu’il n’en faut. Nous n’avons donc par trouvé une ontologie opérationnelle

satisfaisant notre besoin. Ceci nous a amené à concevoir une ontologie (ou plutôt des parties

d’ontologies) sur le dossier médical qui sera utilisée pour la compréhension des structures des

bases de données à intégrer.

Il faut noter qu’en plus des ontologies il existe des systèmes de codage des

informations médicales (CIM 9 et 10), diverses classifications d’actes médicaux pour

l’essentiel, SNOMED [COT 93] (classification internationale) et LOINC [LOI 04] (examens

biologiques).

43

5 Contrôle de données

Plusieurs travaux ont concerné la sécurité et le contrôle des informations contenues

dans des documents XML. Dans cette partie, nous présentons quelques travaux qui ont étudié

cette problématique avant de terminer par un tableau de synthèse comparant ces différentes

approches.

5.1 Les différentes approches de contrôle de données

5.1.1 L’approche de Damiani

Dans cette approche [DAM 01] [DAM 00] les autorisations peuvent être soit positives

en accordant l'accès à un élément XML ou à un attribut, soit négatives en le refusant. Elles

peuvent concerner des éléments des documents XML ou du schéma XML, ce qui amène à

avoir des contrôles pour chaque document ou pour un ensemble de documents. Chaque

autorisation peut être locale (s’applique seulement à l'élément courant et ses attributs) ou

récursive (s’applique aux éléments et aux sous éléments). Chaque fois qu’un accès aux

données XML est demandé, la mise en application des autorisations communes est appliquée

au niveau du schéma et du document, et une vue est créée incluant seulement l'information

permise. L’utilisation du langage XPath [CLA 99] permet d’associer une condition à chaque

nœud du document ou du schéma. XPath est un langage pour adresser des parties de

documents XML. Une autorisation d’accès aux données est caractérisée par un triplet

constitué de l’identifiant de l'utilisateur, l’adresse IP de la machine du client, et le nom de la

machine. L’application des autorisations peut aussi concerner un ensemble d'utilisateurs ou de

machines. Quand un document est demandé, une analyse de toutes les autorisations qui

concernent le client est faite, afin de décider quelles autorisations s’appliquent sur chaque

nœud. Chaque nœud a un 8-tuple, dont le contenu reflète les autorisations spécifiées sur le

nœud. Un prototype a été développé en Java afin de valider leur proposition.

5.1.2 L’approche de Bertino

Dans [BER 00] l’autorisation sur les objets exige trois étapes, en premier le document

(ou l’ensemble des documents) sur lequel une autorisation s’applique, est identifié. Une fois

les documents/DTDs spécifiés, les éléments demandés sont sélectionnés. Finalement la

44

portion des éléments sélectionnés sur lesquels l'autorisation s’applique, sont identifiés. Leur

modèle supporte deux types de privilèges : Browser et Authoring. Le premier permet de lire

l'information dans un élément ou de naviguer à travers ses liens (lecture et navigation). Les

privilèges Authoring permettent à l’utilisateur de modifier (ou effacer) le contenu d'un

élément ou d’attacher une nouvelle information à un élément. Il existe deux types de

privilèges Authoring : attacher et écrire. Il faut noter que chaque autorisation a son niveau de

propagation, ce niveau peut être en cascade, en premier niveau, ou aucun dans le cas où

aucune propagation d'autorisation ne serait exécutée. L’inconvénient majeur est que pour

chaque DTD ou document non valide une politique de sécurité est définie manuellement. La

proposition a été validée par un prototype et elle est utilisée pour les documents non valides.

5.1.3 La première approche de Gabillon

Dans l’approche de [GAB 01a] [GAB 01b], les règles d’autorisation sont sous la

forme d’un 4-tuple < ensemble de sujets, ensemble d’objets, accès, priorité > où la valeur

d’accès est soit « accepter » soit « refuser » et la valeur de la priorité est optionnelle. Les

règles d’autorisation sont écrites par l’administrateur dans une feuille XAS (XML

Autorisation Sheet). Si l’accès à un nœud N est accordé à utilisateur U, alors U est autorisé à

voir le sous-arbre dont N est la racine et si l’accès lui est refusé, alors ce dernier ne peut pas

voir le sous arbre. Dans cette approche un document XML peut être représenté par un arbre

XPath où chaque objet devient un nœud. L’originalité de cette approche est l’utilisation de la

notion de « mensonge » permettant de cacher une information sensible à un patient ou à sa

famille, en la remplaçant par une fausse information afin de garder le secret professionnel ou

afin de ne pas alarmer les personnes. Un prototype utilisant XSLT a été développé. Ce

prototype produit une vue en deux étapes, en premier la politique de sécurité est traduite en

une feuille XSLT avant qu’elle soit appliquée au document source. Pour chaque utilisateur un

modèle ou une feuille de style est défini.

5.1.4 La deuxième approche de Gabillon

Un autre modèle de contrôle d’accès aux données pouvant être appliqué à toutes les

structures de données typées et non typées, a été proposé dans [GAB 02]. Dans ce modèle

chaque objet est représente par un nœud ayant une liste de contrôles d’accès, et à chaque arbre

est associée une politique de sécurité. Ils utilisent une version de XPath simplifiée permettant

45

d’avoir des nœuds non typés. La politique de sécurité est définie en tagant les nœuds de

l'arbre de la source avec des attributs d'autorisation. Un attribut d'autorisation fait référence à

un utilisateur unique et un privilège unique. Il est constitué d’une paire < sujet, privilège >, où

le sujet identifie un utilisateur. Le privilège peut avoir comme valeur « lire » « effacer »,

« insérer » ou « MAJ ». L'ensemble des attributs d'autorisation associés à un nœud constitue

une liste de contrôles d'accès. Il faut noter que dans ce modèle, ce qui n'est pas autorisé est

défendu. L’avantage de cette approche est qu’elle permet de définir des politiques de sécurité

dynamiques, lesquelles sont mises à jour toutes les fois que l’arbre source est modifié. Deux

algorithmes ont été proposés pour calculer la vue d’un arbre pour un utilisateur donné.

5.1.5 L’approche de Michiharu

Une dernière approche est présentée par [MIC 00]. Elle permet d’utiliser des

autorisations provisoires, ce qui est un nouvel apport aux modèles d'autorisation traditionnels

(vus ci-dessus). En effet dans les approches présentées ci-dessus, les autorisations sont

toujours de type « Refus/accepter », et ne prennent pas en compte le cas où les autorisations

peuvent contenir des conditions. Par exemple, « si aujourd’hui est férié alors l’utilisateur X

n’a pas le droit de consulter le document Y ». Un deuxième apport est le codage des données

en transformant les données extraites dans un autre format de codage afin de mieux les

protéger. En premier une demande d'autorisation est envoyée au module d'autorisation

provisoire. Ce dernier crée un ensemble de décisions d'autorisations, avant de faire appel au

module d'exécution des requêtes REM (Request Execution Module). REM transforme les

objets en se basant sur les décisions d’autorisation et met à jour le document XML. Il permet

aussi de coder le contenu des éléments qui sont en format texte ordinaire en leur appliquant

des opérations cryptographiques. La différence avec les autres approches est que la plupart

autorisent ou rejettent une autorisation contrairement à [MIC 00], qui propose la notion

d'autorisation provisoire qui informe l'utilisateur (et/ou le système) que sa demande est

autorisée s’il satisfait des conditions. Son inconvénient est que pour chaque document on doit

définir une politique d’autorisation.

46

5.2 Conclusion

En conclusion nous présentons dans le tableau 6 un comparatif des différentes

approches présentées ci-dessus.

[MIC 00] [BER 00] [DAM 01] [GAB 01] [GAB 02]Les droits sont appliqués sur :

Documents XML

Des politiques de sécurité

pour chaque document

+ + + +

Les droits sont appliqués sur : DTD / XML

schema

+ + - +

Gère des priorités entre les règles de

sécurité

- - + + -

Ecriture des politiques de

sécurité

Manuelle Manuelle Manuelle Manuelle Manuelle

Les droits sont appliqués pour la

lecture

+ + + + +

Les droits sont appliqués pour

l’écriture

- + - - +

Possede un prototype

- + - + -

Observation Les politiques de sécurité

concernent des utilisateurs et des

machines

Utilise la notion de « mensonge » pour

cacher l’information

Tableau 6 : différentes approches de contrôle

47

6 Le système DRUID

Il existe deux approches pour saisir les informations, la première est l’utilisation de

formulaires de saisie afin de mettre les données dans des bases de données. Cette approche est

très performante quand on veut interroger la base de données ou chercher une information, par

contre elle est lourde pour l’utilisateur qui saisit ces données. La deuxième approche est la

saisie de texte libre sous forme de document afin de le mettre dans une base documentaire.

Elle est certes souple pour l’utilisateur qui saisit mais elle n’est pas aussi puissante que les

bases de données pour ce qui est de l’interrogation.

Le projet DRUID (Database and Rule-based User Interface for Documents) [BAD

03a] combine la puissance des approches bases de données et bases documentaires en mettant

à jour une base de données "classique" à partir de documents saisis semi librement par

l’utilisateur.

6.1 Introduction

Le projet DRUID [BAD 03a] présente à l’utilisateur une interface documentaire

permettant de créer et de consulter des documents semi-structurés. Cette interface s’appuie sur

une base de données contenant l’extraction de certaines données provenant des documents

ainsi qu’une base documentaire contenant les documents sources saisis par les utilisateurs.

L’objectif général du projet est de proposer à l’utilisateur de DRUID la souplesse de saisie

qu’offrent les documents, tout en conservant la puissance d’interrogations des bases de

données classiques.

6.2 Principe de DRUID

Le système DRUID [BAD 03a] propose à l’utilisateur de saisir ses informations non

pas dans des formulaires, mais sous forme de documents XML appelés documents faiblement

structurés [LAF 01a] [LAF 01b] dans lesquels le balisage est très lâche : des balises encadrent

des paragraphes et non chaque information. Par exemple dans la saisie du dossier médical le

médecin saisit un paragraphe « Prescription » qui est délimité par la balise « Prescription » et

non une balise pour chaque donnée saisie par l’utilisateur.

Exemple 1 : <Prescription> 2 comprimés de Voltarène 3 fois par jour, 15 jours </Prescription>

48

Cette technique permet d’alléger considérablement le travail de l’utilisateur.

Cependant, afin de faciliter l’extraction des informations du document pour remplir la base de

données, ce dernier doit être transformé en un document plus structuré, appelé document

fortement structuré [LAF 01a], c’est-à-dire dans lequel chaque information unitaire est

balisée. Dans l’exemple ci-dessus, la balise encadrera chaque donnée et non chaque

paragraphe. L’exemple 2 expose une partie d’un document fortement structuré où chaque

information est balisée afin de faciliter l’extraction de données pour alimenter la base de

données. Ce document est le résultat de la transformation du document présenté dans

l’exemple 1 [BAD 01].

Exemple2 : <Prescription>

<Medicament>Voltarène</Medicament> <Posologie> <Frequence>3</Frequence> <UniteFrequence>jour</UniteFrequence> </Posologie> <Duree> <Nombre>15</Nombre> <UniteDuree>Jour</UniteDuree> </Duree> <Quantite> <NBRQuantite>2</NBRQuantite>

<forme>Comprime</forme> </Quantite>

</Prescription>

Afin de contrôler le flux d’information en entrée et en sortie, des modèles de

documents sont crées pour les documents en écriture et en lecture [BOU 01]. Nous

détaillerons dans le chapitre IV comment ces modèles sont fabriqués.

6.3 Fonctionnement de DRUID

6.3.1 Saisie des données

Au début de la saisie l’utilisateur choisit un type de document. Ce type de document

associé au groupe de l’utilisateur permet de déduire la DTD du document. Afin de faciliter

l’analyse du document, DRUID demande à l’utilisateur de baliser chaque paragraphe. Les

balises possibles dépendent de la DTD du document. Chaque paragraphe de ce document fera

ensuite l’objet d’une analyse [BAD 03b]. Le résultat de l’analyse est également un document

XML contenant le texte saisi initialement, mais les balises délimitent chaque donnée

49

élémentaire. Le document résultat est appelé document fortement structuré. Les balises du

document résultant sont insérées par l’analyseur et son contenu alimentera ensuite une base de

données.

<?xml version='1.0' encoding='ISO-8859-1' ?> <!ELEMENT Rencontre (Lieu, dateheure, nommed, nompatient, Symptome*, Prescription+, Diagnostic?)> <!ATTLIST Rencontre Norenc #REQUIRED Nomedecin #REQUIRED Nopatient #REQUIRED> <!ELEMENT Lieu (#PCDATA)> <!ELEMENT dateheure (#PCDATA)> <!ELEMENT nommed(#PCDATA)> <!ELEMENT nompatient (#PCDATA)> <!ELEMENT Symptome (Libellé)> <!ATTLIST Symptome Codesymptome REQUIRED> <!ELEMENT Libellé (#PCDATA)> <!ELEMENT Prescription (qte?, Uqte?, Freq?, Ufreq?, nommedic Duree?, Uduree?)> <!ATTLIST Prescription Nomedic #REQUIRED> <!ELEMENT nommedic (#PCDATA)> <!ELEMENT qte (#PCDATA)> <!ELEMENT Uqte (#PCDATA)> <!ELEMENT Freq (#PCDATA)> <!ELEMENT Ufreq (#PCDATA)> <!ELEMENT Duree (#PCDATA)> <!ELEMENT Uduree (#PCDATA)> …

<?xml version='1.0' encoding='ISO-8859-1' ?> <!ELEMENT Rencontre (Lieu, dateheure, nommed, nompatient, Symptome*, Prescription+, Diagnostic?)> <!ATTLIST Rencontre Norenc #REQUIRED Nomedecin #REQUIRED Nopatient #REQUIRED> <!ELEMENT Lieu (#PCDATA)> <!ELEMENT dateheure (#PCDATA)> <!ELEMENT nommed(#PCDATA)> <!ELEMENT nompatient (#PCDATA)> <!ELEMENT Symptome (#PCDATA)> <!ELEMENT Prescription (#PCDATA)> <!ELEMENT Diagnostic (#PCDATA)>

Analyseur

Figure 11: Fonctionnement de DRUID

6.3.2 Consultation des données

DRUID est également composé d’une base documentaire qui assure la traçabilité des

documents entrant dans le système, pour une consultation ultérieure et ainsi permettre aux

utilisateurs de consulter ces documents. Les utilisateurs voulant interroger la base de données

envoient leurs requêtes à DRUID. Ce dernier exécute la requête récupère les tuples associés

aux liens vers les documents sources des données. Ceci permet aux utilisateurs de consulter

les documents rédigés. Une fois les résultats trouvés, pour chaque type d’utilisateur et chaque

document trouvé dans le résultat, DRUID récupère sa DTD. Il modifie ensuite le document

50

[BOU 01] à envoyer en le rendant conforme à sa DTD, permettant ainsi de protéger les

informations confidentielles. Une fois terminé, les tuples ainsi que les documents XML

modifiés sont présentés à l’utilisateur.

6.4 L’analyseur de DRUID

Le système proposé par le projet DRUID permet d’analyser des documents semi-

structurés rédigés en XML, afin d’en extraire les informations qui doivent être stockées dans

la base de données. Pour cela, il s’appuie sur une base de connaissances (thésaurus,

informations de liaison entre la structure de la base et la structure des documents, règles

d’extraction des documents pour remplir la base) qui indique quels types d’informations

doivent être stockés, et à quel endroit dans la base. L’analyseur de document a fait l’objet

d’un premier prototype réalisé par [WEI 99] et d’une thèse réalisée par Y. Badr [BAD 03b]

Ce composant a la charge d’analyser les documents saisis par les utilisateurs, afin de

transmettre leur contenu dans la base de données.

Chaque document rédigé subit trois types de traitements qui se font par l’analyseur.

Ces traitements sont : transformations, extraction et alimentation. Durant le processus de

transformation l’analyseur étudie le document contenant des paragraphes balisés et construit

le document fortement structuré en balisant chaque donnée. Pour ce faire, il s’appuie sur des

feuilles de transformations contenant des séquences de règles décrivant comment transformer

un document faiblement structuré en un document fortement structuré. Il faut noter que pour

chaque DTD, il existe une feuille de transformation.

Durant le deuxième processus (le processus d’extraction), l’analyseur reçoit un

paragraphe rédigé en langue naturelle et retourne des termes extraits du paragraphe. La

dernière étape est l’alimentation des bases de données à partir du contenu des documents

fortement structurés. Pour ce faire DRUID utilise des règles d’alimentation écrites dans un

format XML pour construire une vue objet du document centré données et d’autres règles

pour relier cette vue au modèle de la base de données. Pour plus d’information sur

l’analyseur, voir [BAD 03a].

51

7 Conclusion du chapitre Dans ce chapitre nous avons fait un tour d’horizon de l’existant. Nous avons présenté dans les

deux premières parties les différents systèmes d’intégration de bases de données ainsi que les

approches de construction de schéma médiateur. Leur inconvénient principal est dans la

construction de la vue unifiée qui demande beaucoup d’efforts à l’utilisateur. Nous montrons

dans le chapitre III notre proposition qui permet d’alléger les interventions d’utilisateur. Elle

permet aussi la modification automatique de la vue unifiée si les schémas sources sont

modifiés.

Les échanges d’informations entre différents systèmes exigent un contrôle de données, nous

avons donc présenté quelques approches de contrôles de données. Ces approches appliquent

des politiques de contrôles sur les documents, les modèles de documents ou les utilisateurs.

La plupart de ces politiques sont écrites manuellement. Dans le chapitre IV nous présenterons

une solution à cet inconvénient.

Notre système proposé utilise des ontologies de domaines nous avons donc présenté les

ontologies médicales existantes (Cas pratique appliqué au domaine médical). Avant de

terminer par la présentation du système DRUID qui facilite la saisie des données en

remplaçant les formulaires de saisie par une saisie libre. Il permet ainsi de combiner les

avantages des approches bases de données et bases de documents.

52

53

Chapitre III : Création d’une vue unifiée 1 Introduction..................................................................................................................................53 2 Vue unifiée...................................................................................................................................55

2.1 Introduction..........................................................................................................................55 2.2 Les ontologies ......................................................................................................................57

2.2.1 L’ontologie de structure...............................................................................................57 2.2.2 L’ontologie de valeurs .................................................................................................58

2.3 Description XML d’une base de données à l’aide des ontologies .......................................59 2.3.1 Le document XML décrivant la base de données........................................................59 2.3.2 Règles de description ...................................................................................................61 2.3.3 Etape 1 : Description des relations...............................................................................63 2.3.4 Etape 2 : Description des attributs ...............................................................................65 2.3.5 Etape 3 : Description des liens entre les relations........................................................66 2.3.6 Conclusion ...................................................................................................................67

2.4 Le schéma médiateur ...........................................................................................................68 2.4.1 Le document XML contenant le schéma médiateur ....................................................68 2.4.2 Le document XML contenant les règles de mapping ..................................................68

2.4.2.1 Les types des règles de mapping..............................................................................69 2.4.2.2 Les cardinalités de règles de mapping .....................................................................70 2.4.2.3 Fonction de conversion ............................................................................................71

2.4.3 Règles de génération du schéma médiateur .................................................................71 2.4.4 Génération du schéma médiateur.................................................................................74

2.4.4.1 Génération des relations du schéma médiateur........................................................75 2.4.4.2 Génération des attributs du schéma médiateur ........................................................77 2.4.4.3 Insertion des clés primaires des relations du schéma médiateur..............................78 2.4.4.4 Optimisation du schéma médiateur..........................................................................78 2.4.4.5 Traitement des liens entre les relations du schéma médiateur .................................79 2.4.4.6 Conclusion ...............................................................................................................80

2.5 Modification du schéma médiateur......................................................................................81 2.5.1 Processus d’insertion ...................................................................................................81

2.5.1.1 Ajout d’une relation dans un schéma source ...........................................................81 2.5.1.2 Ajout d’un attribut dans une relation du schéma source..........................................82 2.5.1.3 Ajout d’une clé primaire dans une relation du schéma source ................................83

2.5.2 Processus de suppression .............................................................................................84 2.5.2.1 Suppression d’une relation dans un schéma source.................................................84 2.5.2.2 Suppression d’un attribut dans un schéma source ...................................................85

3 Conclusion du chapitre ................................................................................................................86

1 Introduction

Dans le premier chapitre, nous avons présenté notre problématique, qui consiste à construire

un système permettant à l’utilisateur de manipuler des informations stockées sur différentes bases de

données appartenant à un même domaine, mais hétérogènes aussi bien dans leur contenu que dans

54

leur conception. Nous nous sommes posé comme contrainte que nous n’avons aucunement le droit de

modifier l’existant.

Ontologie de valeurs

MEDIATEUR

BD1 BD 2 BD3

Wrapper WrapperWrapper Ontologie de structure

Req

uête

Doc

umen

t X

ML

DRUID DRUID DRUID

Saisie des données

Saisie des données

Saisie des données

Figure 12 : Architecture de notre système de médiation

La Figure 12 présente l’architecture du système de médiation proposé et qui permet à

l’utilisateur de formuler une requête sur une vue unifiée et de récupérer un résultat provenant de

l’exécution de la requête sur un ensemble de bases de données hétérogènes.

Le médiateur : il permet à l’utilisateur d’interroger différentes bases de données. Pour ce faire, le

médiateur récupère les requêtes des utilisateurs, les traite, les traduit, les distribue sur les bases de

données, intègre les résultats des différentes bases de données et renvoie les résultats. Le médiateur

utilise un schéma médiateur (vue unifiée). Cette vue est générée à partir de schémas de bases de

données hétérogènes à intégrer. Nous détaillerons les phases de génération du schéma médiateur ci-

dessous (sections 2.3 & 2.4 de ce chapitre). Son fonctionnement sera détaillé dans la partie 2 du

chapitre IV.

55

DRUID [BAD 03a] : Afin de rendre la saisie des informations plus souple nous utilisons le système

DRUID (présenté dans le chapitre état de l’art). L’utilisateur de DRUID saisit ses informations dans

un document semi-structuré où chaque paragraphe est balisé. Ce document est ensuite traité afin d’en

extraire les informations et de remplir la base de données. Il présente les résultats des requêtes sous

formes de tuples ainsi que l’Url des documents sources, ce qui permet de consulter les documents qui

ont alimenté la base de données. Pour contrôler la saisie et faciliter l’analyse des documents ainsi que

l’alimentation des bases de données, les documents saisis doivent être conformes à des DTD où

chaque type de document a sa propre DTD selon le thème choisi. Nous présenterons dans le chapitre

IV, la méthode avec laquelle les DTDs sont générées et filtrées automatiquement à partir d’un

modèle de base de données.

Notre chapitre est présenté comme suit. Durant la première partie nous abordons la

description des bases de données avec laquelle la vue unifiée est générée dans la deuxième partie.

Nous exposons ensuite comment les modifications des schémas sources influencent celles du schéma

médiateur, avant de clôturer le chapitre par une conclusion.

2 Vue unifiée

2.1 Introduction

La diversité des schémas, des termes ainsi que des appréhensions que nous pouvons avoir des

schémas à intégrer rend difficile la génération automatique de vues unifiées. Cette diversité comporte

souvent une hétérogénéité sémantique qui peut concerner aussi bien les différences que les

ressemblances dans la signification des données. Ainsi, il est possible que deux termes (relation,

attribut ou autre) possédant le même nom, diffèrent dans leur signification. Nous pouvons également

nous trouver en présence de deux termes ayant la même signification mais des dénominations

différentes.

La deuxième difficulté, quant à elle, consiste en l’existence d’hétérogénéités structurelles

dues aux différentes conceptions des schémas. Cette hétérogénéité concerne les conflits de types,

c’est le cas où une même information est représentée de façon différente dans les différents modèles.

En effet, du fait que les bases de données ont été conçues par des personnes différentes et pour des

besoins différents nous pouvons avoir des vues différentes de la même information. Par exemple, une

information dans une première base de données est représentée par une relation R et dans une

deuxième base de données par un attribut A. Ainsi, la difficulté dans la création des schémas

médiateurs réside, d’une part, dans la détection de ce type d’hétérogénéités et, d’autre part, dans sa

56

résolution même qui nécessite l’intervention d’experts (présentés dans l’état de l’art). Le tableau

suivant présente les différents types d’hétérogénéités que nous avons recensés.

Type d’Hétérogénéité Exemple

Hétérogénéité sémantique

Deux Relations ou attributs portent le

même nom et diffèrent dans leur

signification (homonymes)

Deux relations « Diagnostic », la première

contient les maladies des patients hospitalisés

dans un service, la seconde répertorie toutes les

maladies existantes (classification)

Relations ou attributs diffèrent dans

leur nom et ont la même signification

(synonymes)

Deux relations « Patient » et « Malade »

stockent les données sur les patients

Hétérogénéité structurelle

BD1 BD2

Relation Attribut - Relation SERVICE contenant des champs

nom, spécialité, adresse.

- Attribut SERVICE ne contenant que le nom

du service.

Relation

spécialisée

(1 relation)

Relation

généralisée

(N relation)

Relation « Médecin »

Relation « Pédiatre »

Relation « Chirurgien »

Un attribut N Attributs - Attribut Adresses = N°rue + Rue + Code

Postal +Ville

Tableau 7 : Tableau présentant les différents types d’hétérogénéités.

Afin de résoudre ces hétérogénéités nous présentons à l’utilisateur une vue unifiée de toutes

les bases de données à interroger. Pour ce faire nous décrivons en premier chaque base de données en

utilisant des termes unifiés issus d’ontologies de domaines. Ceci permet de résoudre l’hétérogénéité

sémantique. Nous créons ensuite à l’aide de cette description un schéma médiateur, en résolvant le

deuxième type d’hétérogénéité. Ce processus est composé de deux parties principales :

Partie I : Description des bases de données : Son but est de créer, pour chaque schéma d’une

base de données source, un document XML le décrivant. Ce document contient la description des

57

relations et attributs, issus des termes de l’ontologie. Pour ce faire, pour chaque relation (ou attribut)

nous recherchons dans l’ontologie le concept [USC 96] le décrivant. Une fois terminé, toutes les

structures à intégrer sont décrites par des termes unifiés.

Partie II : Génération du schéma médiateur : Durant cette partie, le schéma médiateur est

créé à partir des documents décrivant les bases de données, créés ci-dessus. Pour ce faire nous

regroupons les concepts équivalents décrivant les relations afin de créer une relation dans le schéma

médiateur. Nous créons ensuite les correspondances la liant aux relations des schémas sources. Une

fois terminé, le même traitement est appliqué aux attributs des relations.

2.2 Les ontologies

Dans la phase de description des bases de données, deux étapes sont clés :

1 : L’étude de la structure en recherchant le concept décrivant une relation ou un attribut,

2 : L’étude du contenu dont le but est d’aider l’utilisateur-concepteur dans son choix.

Ces deux phases reposent sur l’utilisation d’ontologies. Afin de différencier les termes utilisés dans

les schémas des bases de données et ceux utilisés dans leur contenu, nous avons introduit les notions

d’ontologie de structure et d’ontologie de valeurs.

2.2.1 L’ontologie de structure

L’ontologie de structure est composée d’un ensemble de concepts qui sont issus des

vocabulaires utilisés dans les modèles des bases de données à intégrer tels que les noms des relations

et attributs. Chaque concept est défini par son identifiant, son nom et son type. Ce dernier peut être

simple (String, Date, Integer, float, blob) ou complexe, c’est-à-dire pouvant être composé d’autres

concepts ou d’autres types définis pour nos besoins. Un exemple de type complexe est le dossier

médical, qui est composé des concepts intervention, symptômes, prescription etc.

Les concepts qui composent notre ontologie sont liés entre eux par des liens. Un lien est

défini par son nom, un concept père, un concept fils ainsi que le type de lien (Agrégation,

Généralisation, Composition, Association, Synonyme). Par exemple, un cours est toujours donné par

un enseignant, ceci nous permet donc de lier le concept enseignant au concept cours dans l’ontologie

de structure. Ces liens nous permettent d’exploiter au mieux l’ontologie de structure durant le

processus de description de bases de données. Nous verrons dans les paragraphes suivants comment

ces liens sont utilisés. Le diagramme des classes de l’ontologie est présenté dans la Figure 13

58

Integer Date String

Concept_Simple

Blob

Concept_Complexe

Agrégation Composition Généralisation Association

ConceptIdNom

LienNom

Synonymie

Figure 13 : Le diagramme des classes de notre ontologie de structure

2.2.2 L’ontologie de valeurs

L’ontologie de valeurs recense l’ensemble des valeurs que peuvent contenir certains concepts

du domaine. Cette ontologie inclue des concepts organisés par domaine, et où chacun est constitué

d’un ensemble de valeurs et d’une liste de concepts fils.

Pour notre problématique, ces deux ontologies seront appliquées à la médecine, nous

montrons leur exploitation dans l’annexe D.

Le fait que les deux ontologies soient du même domaine, nous permet de gagner du temps

dans le processus de comparaison du contenu des relations et des attributs. En effet, durant le

processus de traitement des contenus nous n’avons pas besoin de parcourir les valeurs de toute

l’ontologie de valeurs, mais seulement des concepts trouvés lors de la première phase. Nos deux

ontologies sont liées, ce qui nous permet de comparer le contenu de la relation avec uniquement le

contenu des concepts qui lui correspondent.

59

2.3 Description XML d’une base de données à l’aide des ontologies

Dans cette partie nous exposons la description de bases de données qui nous permettra de

faciliter le processus de génération de schéma médiateur. Cette description décrit chaque relation et

chaque attribut de la base de données en utilisant des termes unifiés pour toutes les bases de données

et qui sont issus de l’ontologie de structure.

2.3.1 Le document XML décrivant la base de données

Pour chaque base de données, un document XML [W3C 98] la décrivant est généré. Ce

document est conforme à la DTD de la Figure 14. <?xml version="1.0" encoding="UTF-8"?> <!ELEMENT schema (Nom-schema, Relation+)> <!ELEMENT Nom-schema (#PCDATA)> <!ELEMENT Relation (Nom-concept, description, CleP?, attribut+, References?)> <!ATTLIST Relation nom-relation ID #REQUIRED> <!ELEMENT Nom-concept (#PCDATA)> <!ELEMENT description (#PCDATA)> <!ELEMENT attribut (Nom-concept, description)> <!ATTLIST attribut Nom-attribut ID #REQUIRED> <!ELEMENT References ((IDrelation, CleP)+)> <!ATTLIST References IDrelation IDREF #REQUIRED> <!ELEMENT CleP (IDAttribut*)> <!ATTLIST CleP IDREFS #REQUIRED>

Figure 14 : DTD du document décrivant la base de données

Le document XML est composé d’un ensemble d’éléments XML décrivant les relations, les

attributs, les clés primaires ainsi que les liens entre les relations. Comme présenté dans la Figure 14

un élément décrivant une relation ainsi qu’un élément décrivant un attribut sont, chacun, identifiés

par leur nom respectif. Un élément décrivant une relation est composé du nom du concept de

l’ontologie de structure le décrivant, de sa description ainsi que des éléments décrivant ses attributs

(Règle 3). Un élément décrivant un attribut est composé du concept lui correspondant dans

l’ontologie de structure ainsi que de sa description récupérée du dictionnaire de données de la base

de données (Règle 4). L’élément décrivant une relation contient également deux autres types

d’éléments ; le premier « CleP » indique ses identifiants tandis que le deuxième « References » liste

les noms des relations où a été exportée la clé primaire. Ceci permet de reproduire les liens entre les

relations sources dans le schéma médiateur. Ainsi, si une relation A est reliée à une relation B dans le

schéma source, alors un l’élément XML décrivant la relation A aura dans son élément « References »

le nom de la relation B.

Dans ce qui suit nous présentons le document XML décrivant la base de données BD présentée ci-

dessous :

60

Base de données BD : Malade (Nordre, Nom, Prenom) Diagnostic (Nordre, codeDiag, libelle, date-diag) Symptomes (Nordre, codesymptome, libellesymptome, typesymptome, datesymptome)

• Souligné : clé primaire. • Italique : clé étrangère.

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE schema SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD DESCRIPTION.dtd"> <schema> <Nom-schema/> <Relation nom-relation="malade"> <Nom-concept>Patient</Nom-concept> <description>relation contenant les informations sur les patients</description> <attribut Nom-attribut="Nordre"> <Nom-concept>Nordre</Nom-concept> <description>Identifiant du patient</description> </attribut> <attribut Nom-attribut="nom"> <Nom-concept>nom-patient</Nom-concept> <description>Nom de famille du patient</description> </attribut> <attribut Nom-attribut="prenom"> <Nom-concept>Prenom-patient</Nom-concept> <description>prenom du patient</description> </attribut> <CleP IDAttribut="Nordre"/> <References IDrelation="Diagnostic Symptomes"></References> </Relation> <Relation nom-relation="Diagnostic"> <Nom-concept>Diagnostic</Nom-concept> <description>relation contenant les informations sur les maladies des patients</description> <attribut Nom-attribut="codeDiag"> <Nom-concept>code-diagnostic</Nom-concept> <description>identifiant du diagnostic</description> </attribut> <attribut Nom-attribut="libelle"> <Nom-concept>Libelle-diagnostic</Nom-concept> <description>llibelle du diagnostic</description> </attribut> <attribut Nom-attribut="date-diag"> <Nom-concept>date-diagnostic</Nom-concept> <description>date du diagnostic</description> </attribut> <CleP IDAttribut="Nordre codeDiag"/> </Relation> <Relation nom-relation="Symptomes"> <Nom-concept>Symptomes</Nom-concept> <description>relation contenant les symptomes des patients</description> <attribut Nom-attribut="codesymptome"> <Nom-concept>code-symptome</Nom-concept> <description>identifiant des symptomes</description> </attribut> <attribut Nom-attribut="libellesymptome">

61

<Nom-concept>Libelle-symptome</Nom-concept> <description>llibelle du symptome</description> </attribut> <attribut Nom-attribut="datesymptome"> <Nom-concept>date-symptome</Nom-concept> <description>date du symptome</description> </attribut> <attribut Nom-attribut="typesymptome"> <Nom-concept>type-symptome</Nom-concept> <description>type du symptome</description> </attribut> <CleP IDAttribut="Nordre codesymptome"/> </Relation> </schema>

Figure 15 : Document décrivant la base de données BD

La Figure 15 montre une partie d’un document décrivant la relation « Patient » composé des

attributs « Nordre », « Nom » et « Prenom » etc., ayant comme clé primaire l’attribut « Nordre ». La

relation « Malade » est liée aux relations « Diagnostic » et « Symptomes ». Ce document est

constitué de l’élément XML ayant le nom de la relation à décrire « Malade » et qui est composé d’un

premier élément contenant le concept « Patient » (issu de l’ontologie de structure) équivalent à la

relation et d’un deuxième élément décrivant la relation « Patient » à partir de son dictionnaire de

données. L’élément XML contient également d’autres éléments décrivant les attributs, la clé primaire

et les liens entre les relations. L’élément « Nom» décrit un des attributs de la relation « Malade ». Il

est composé du nom du concept qui lui est équivalent « Nom-Patient » ainsi que de sa description.

L’élément XML « CleP » contient le nom de l’attribut composant la clé primaire (dans notre

exemple, l’attribut « Nordre»). L’élément « References » quant à lui est composé des noms des

relations qui sont liées à la relation « Patient » (« Diagnostic » et « Symptomes »).

2.3.2 Règles de description

Le processus de description suit un ensemble de règles présentées ci-dessous. Nous montrons dans

les paragraphes 2.3.3 & 2.3.4 comment elles sont exploitées :

Règle 1 : Pour chaque base de données, un document XML la décrivant est généré. Ce document

porte le nom de la base de données.

Règle 2 : Le document XML généré est composé d’un ensemble d’éléments XML décrivant les

relations, les attributs, les clés primaires ainsi que les liens entre les relations.

62

Règle 3 : L’élément XML décrivant une relation est identifié par le nom de la relation, et constitué

d’un élément XML contenant le nom du concept le décrivant, d’un élément XML contenant sa

description, d’éléments contenant la clé primaire, d’autres décrivant ses attributs et ses liens avec les

autres relations.

Règle 4 : L’élément XML décrivant un attribut, est identifié par le nom de l’attribut, et constitué

d’un élément XML contenant le nom du concept le décrivant, et celui contenant sa description.

Règle 5 : Pour chaque relation (ou attribut) est affecté un et un seul concept et une et une seule

description.

Règle 6 : Un attribut ou une relation peut être considéré comme correspondant à un concept, s’il a le

même nom ou s’il est synonyme.

Règle 7 : Si aucun concept n’a été trouvé en utilisant la recherche par synonyme, la recherche

s’effectuera par type. Les concepts du même type que l’attribut en phase de traitement sont affichés à

l’utilisateur.

Règle 8 : Chaque clé primaire est modélisée comme un attribut dans l’ontologie. Exemple :

<xs:attribute name="code-patient" type="xs:ID" use="required"/>

Règle 9 : Les attributs identifiants n’ayant pas de concepts les décrivant (dans le cas où l’ontologie

ne serait pas encore complète), gardent leur nom dans les documents les décrivant

Règle 10 : Soient X et Y deux concepts reliés par un lien de type « agrégation ». Soit A, un attribut

appartenant à une relation R, où R est décrite par le concept X. Si X ne contient pas de concept

équivalent à l’attribut A, alors la recherche s’effectuera aussi dans le concept Y.

Règle 11 : Soient X et Y deux concepts où X est une généralisation de Y. Soit A un attribut

appartenant à une relation R, où R est équivalente au concept Y. Si Y ne contient pas de concept

équivalent à l’attribut A, alors la recherche s’effectuera aussi dans le concept X.

Règle 12 : Si durant la description des bases de données aucun concept décrivant un attribut ou une

relation n’a été trouvé, alors l’utilisateur-concepteur indique manuellement le concept correspondant.

Règle 13 : Si durant le traitement de description aucun concept équivalent à un attribut ou une

relation n’a été trouvé, ni de façon automatique, ni de façon manuelle, alors l’utilisateur-concepteur

saisit un nouveau concept qui sera utilisé dans la description de la base de données. Ce concept est

63

ajouté à l’ontologie de structure, ainsi que les concepts qui le composent, si ce dernier n’est pas

élémentaire.

Règle 14 : Si une clé primaire ou une partie de la clé primaire est un identifiant standard tels que les

identifiants des maladies, alors cette clé portera le nom du concept qui lui est équivalent.

Règle 15 : Un identifiant est considéré comme identifiant standard, s’il appartient à une

nomenclature.

Règle 16 : Les clés primaires des relations du schéma médiateur qui n’ont pas de concept équivalent

gardent le nom qu’elles possèdent dans les relations équivalentes à celles du schéma médiateur.

2.3.3 Etape 1 : Description des relations

Figure 16 : Processus de description de base de données

<Ontologie> <Concept C1> </Concept C1’> </Concept C1’’> </Concept C1’’> </Concept C1> <Concept C2> </Concept C2’> </Concept C2’’> </Concept C2> </Ontologie>

R1( Att1, Att2)BD1

R1(Att1, Att2)R2(Att3, Att4)

BD1

Concept décrivant la relation R1

Concept décrivant l’attribut Att1

<BD1> <R1> <Concept>C1</Concept> <Att1>C1’</Att1> <Att2>C1’’</Att2> </R1> <R2> <Concept>C2</Concept> <Att3>C2’</Att1> <Att4>C2’’</Att4> </R2> </BD1>

<BD2> <R1> <Concept>C1</Concept> <Att1>C1’’’</Att1> <Att2>C1’</Att2> </R1> </BD2>

Document décrivant la base de données

64

Le processus de description utilise les ontologies, le dictionnaire de la base de données et

nécessite les interventions de l’utilisateur-concepteur pour valider les résultats des traitements. En

premier nous créons un document XML portant le nom de la base de données. Une fois le document

créé, nous sélectionnons une relation R quelconque, sur laquelle est appliqué le traitement suivant :

Trouver dans l’ontologie de structure, les concepts Ci la décrivant et récupérer sa description Desc à

partir du dictionnaire de la base de données. Les phases suivantes donnent plus de détails sur le

processus de description. Il faut également noter que les trois phases sont faites une à une pour

chaque relation.

Phase 1 : Recherche du concept

Durant cette phase nous recherchons, dans l’ontologie de structure, la liste des concepts Ci qui

peuvent décrire la relation R. Ces concepts sont recherchés à partir de leur nom et de leurs

synonymes (Règle 6).

Exemple : Si la relation en phase de traitement est Medecin, nous allons avoir, à partir de notre

ontologie de structure (Figure 17), la liste des concepts suivants : Docteur, Médecin, Praticien.

Figure 17 : Une partie de l'ontologie de structure

Phase 2 : Récupération de la description de la relation

Nous récupérons à partir du dictionnaire de données de la base de données, la description Desc de la

relation R.

Phase 3 : Validation des traitements

Durant cette phase, les résultats des différents traitements sont affichés à l’utilisateur-concepteur. Ce

dernier choisit alors le concept C décrivant la relation R, à partir de la liste des concepts pouvant

décrire la relation R qui lui sont affichés. Si aucun concept n’a été soumis à l’utilisateur-concepteur

ou si ce dernier n’a pas trouvé son choix, alors il navigue dans l’ontologie afin de sélectionner le

concept C (Règle 12). Si l’ontologie ne contient pas de concept décrivant la relation R, alors un

nouveau concept ainsi que ceux qui le composent, sont saisis (Règle 13).

Docteur

Medecin

Praticien

Synonyme Synonyme

65

Phase 4 : Modification du document décrivant la base de données :

A cette phase, nous avons le nom de la relation, le concept C la décrivant ainsi que sa description.

Ces informations sont ajoutées au document XML décrivant la base de données :

- Un nouvel élément XML portant le nom de la relation est créé,

- Deux autres éléments sont créés et ajoutés à l’élément XML. Le premier contient le nom du

concept C et le deuxième la description de la relation.

2.3.4 Etape 2 : Description des attributs

La deuxième étape consiste à décrire les attributs Atti contenus dans la relation R, et qui est

composée de quatre phases.

Phase 1 : Recherche du concept Catt décrivant un attribut

A : Description des attributs non identifiants : De même que pour la description des relations

(Règle 6), nous recherchons dans l’ontologie de structure, la liste des concepts pouvant décrire

l’attribut Att. Cette recherche est effectuée dans la liste des concepts composant le concept C

décrivant la relation R. Si aucun concept n’a pu être trouvé ni par son nom ni par ses synonymes, la

recherche se fait par type.

Exemple : Si C contient le concept « date_naissance » de type date et si l’attribut «Date_N », en

phase de traitement est lui aussi de type Date alors le concept « date_naissance » est proposé à

l’utilisateur-concepteur.

Dans le cas où aucun concept appartenant au concept C et décrivant l’attribut Att n’aurait pas été

trouvé, nous élargissons notre recherche aux concepts Ci reliés au concept C, en remontant les liens

de type généralisation (Règle 10) ou agrégation (Règle 11) (nous recherchons les concepts les plus

généraux).

B : Traitement des attributs identifiants : Pour les attributs composant la clé primaire dont le

concept équivalent n’existe pas dans l’ontologie de structure, un concept portant le nom de l’attribut

leur sera rattaché (Règle 9). En effet il est impossible de recenser dans une ontologie, tous les

identifiants possibles. Pour y remédier les attributs composant la clé primaire, n’ayant pas de concept

équivalent, gardent leur nom dans le document XML les décrivant. Ceci est appliqué une fois que

l’utilisateur-concepteur a confirmé l’inexistance d’équivalent.

66

Phase 2 : Etude du contenu

De la même manière que pour le traitement du contenu de la relation, nous exploitons les liens

stockés entre les concepts des deux ontologies et nous n’étudions que le contenu des concepts

trouvés ci-dessus. Une fois l’étude du contenu terminée, nous récupérons la description de l’attribut à

partir de son dictionnaire de données.

Phase 3 : Validation des traitements

A la fin des traitements, les résultats sont affichés à l’utilisateur-concepteur qui choisit le concept

CAtt décrivant l’attribut Att. Si l’ontologie de structure ne contient pas de concept équivalent à

l’attribut Att, l’utilisateur-concepteur recherche manuellement le concept dans l’ontologie de

structure (Règle 12). Dans le cas où ce dernier n’aurait pas pu être trouvé, un nouveau concept

équivalent à l’attribut Att est saisi (Règle 13). Ce dernier est rajouté au concept C équivalent à la

relation R et permettant ainsi d’enrichir l’ontologie de structure.

Le traitement des attributs permet d’infirmer ou de confirmer le choix du concept C équivalent à la

relation R. Dans le cas de l’infirmation, nous recherchons tout d’abord, dans la liste des concepts

candidats proposés dans l’étape précédente à l’utilisateur-concepteur, un autre concept qui peut être

équivalent à la relation R. Notre recherche se portera sur toute l’ontologie. Une fois le concept

trouvé, nous lui appliquons le même traitement, c’est-à-dire la description de la relation et de ses

attributs ainsi que la modification du document XML. Si le concept n’est pas trouvé, un nouveau

concept est inséré dans l’ontologie qui sera rattaché à la relation.

Phase 4 : Modification du document décrivant la base de données

Une fois les traitements validés, les données qui décrivent l’attribut Att sont ajoutées au

document XML. Nous ajoutons à l’élément XML décrivant la relation R, un élément décrivant

l’attribut Att. Cet élément est constitué du nom de l’attribut, du nom du concept le décrivant ainsi

que de sa description (Règle 4). Dans le cas où l’attribut serait un identifiant, alors un élément XML

appelé « CleP » est lui aussi inséré dans l’élément décrivant la relation R. Cet élément contient les

noms des attributs identifiants.

2.3.5 Etape 3 : Description des liens entre les relations

La dernière étape traite des clés exportées dans les relations. Pour chaque clé étrangère de la

relation R, nous récupérons le nom de la relation R2 d’où a été importée cette clé. Nous modifions

67

ensuite l’élément XML décrivant la relation R, et ce en lui ajoutant un élément XML portant le nom

« References » et contenant le nom des concepts décrivant les relations où sa clé primaire a été

exportée. Cet élément recense la liste des liens de la relation et permet lors de la génération du

schéma médiateur de reproduire les liens entre les relations des bases de données sources.

Exemple : Dans l’élément XML décrivant la relation « Patient » dans la Figure 15, l’élément XML

« References » contient les noms des relations où la clé primaire de la relation « Patient » a été

exportée. Nous savons, de ce fait, à partir de cet élément, que « Patient » est en relation avec :

« Diagnostic », « Prescription », « Antecedent-fam », « Antecedent-pers », « Symptomes »,

« Bilan ».

A la fin de cette étape, la description de la base de données a produit un document XML

décrivant chaque relation et chaque attribut.

2.3.6 Conclusion

Afin de conclure cette partie, nous résumons le processus de description de bases de données.

Partie I : Description des bases de données : Son but est de créer pour chaque schéma un document

XML le décrivant et utilisant le langage des ontologies du domaine concerné. Elle est composée de

trois étapes :

Etape A : Description des relations

- Recherche dans l’ontologie de structure du (ou des) concept(s) qui décrit la

relation,

- Extraction de la description de la relation du dictionnaire de données,

- Validation des traitements par l’utilisateur-concepteur : Choix du concept

décrivant la relation au vu des résultats des points précédents,

- Modification du document XML décrivant la base de données.

Etape B : Description des attributs

- Recherche dans l’ontologie de structure du (ou des) concept(s) qui décrit

l’attribut,

- Comparaison du contenu de l’attribut avec celui de l’ontologie de valeurs

afin d’aider l’utilisateur-concepteur dans son choix du concept qui

correspond à l’attribut,

- Récupération de la description de l’attribut du dictionnaire de données,

- Validation des traitements par l’utilisateur-concepteur : Choix du concept

correspondant à l’attribut, au vu des résultats des points précédents

68

- Modification du document XML décrivant la base de données.

Etape C : Description des liens entre les relations

- Pour chaque clé étrangère dans la relation R faire :

o Prendre le nom du concept décrivant la relation R2 d’où elle a été importée

o Ajout à l’élément XML décrivant la relation R, un élément « References »

contenant le nom du concept trouvé ci-dessus.

2.4 Le schéma médiateur

Les documents décrivant les bases de données construits sont utilisés pour générer le schéma

médiateur et les règles de mapping sous la forme de deux documents XML.

2.4.1 Le document XML contenant le schéma médiateur Le document XML contenant le schéma médiateur est conforme à la DTD de la Figure 18. Il

est composé d’un ensemble d’éléments XML appelés « RelationMed » qui correspondent aux

relations du schéma médiateur. Chaque élément « RelationMed » est défini par son nom, sa clé

primaire « CleP » ainsi que par un ensemble d’attributs appelé « AttributMed ». L’élément

« AttributMed » contient les attributs des relations du schéma médiateur et il est défini par son nom.

L’élément « CleP » quant à lui contient l’ensemble des attributs qui composent la clé primaire.

<?xml version="1.0" encoding="UTF-8"?> <!ELEMENT SchemaMed (RelationMed+)> <!ELEMENT RelationMed (nom-relation, AttributMed+, CleP?)> <!ATTLIST RelationMed relation ID #REQUIRED> <!ATTLIST AttributMed attribut ID #REQUIRED> <!ELEMENT CleP (IDAttribut*)> <!ATTLIST CleP IDREFS #REQUIRED>

Figure 18 : DTD du schéma médiateur

2.4.2 Le document XML contenant les règles de mapping

Un document XML de règles de mapping est rattaché au schéma médiateur. Ce document est

conforme à la DTD de la Figure 19, et contient les différentes correspondances (règles de mapping)

entre ses relations et attributs, et leurs équivalents dans les schémas sources (Règle 22). Une règle de

mapping est composée du nom de la base de données, du nom de la relation ainsi que du nom de

69

l’attribut (ou de l’ensemble d’attributs) dans le cas des correspondances entre les attributs. Elle peut

également contenir des fonctions de conversion. <?xml version="1.0" encoding="UTF-8"?> <!ELEMENT SchemaMedMapping (RelationMedMapping+)> <!ELEMENT RelationMedMapping ( lienRelation+, AttributMedMapping+)> <!ATTLIST RelationMedMapping relation ID #REQUIRED> <!ELEMENT AttributMedMapping (LienAttribut+)> <!ATTLIST AttributMedMapping attribut ID #REQUIRED> <!ELEMENT lienRelation (nomBase, nom-rel)> <!ELEMENT nomBase (#PCDATA)> <!ELEMENT nom-rel (#PCDATA)> <!ELEMENT LienAttribut (nomBase, nom-rel, nom-attrib+, fctConv?)> <!ELEMENT fctConv (#PCDATA)> <!ELEMENT nom-attrib (#PCDATA)>

Figure 19 : DTD du document des règles de mapping

RelationMedMapping : Relie les relations du schéma médiateur à celles des schémas sources. Il est

constitué du nom de la relation du schéma médiateur, des liens de correspondances entre cette

relation et celles des schémas sources qui lui sont reliées appelé « LienRelation », ainsi que d’un

ensemble d’éléments « AttributMedMapping » reliant les attributs à leurs équivalents dans les

schémas sources.

LienRelation : Pour chaque relation des schémas sources, équivalente à la relation du schéma

médiateur, un élément « LienRelation » est inséré dans la règle de mapping. Cet élément contient le

nom de la base de données source ainsi que le nom de la relation équivalente à la relation du schéma

médiateur.

AttributMedMapping : Défini par son nom, il est composé de liens appelés « LienAttribut » le

reliant aux attributs des schémas sources qui lui sont équivalents et d’une fonction de conversion.

LienAttribut : Contient la liste des attributs sources. Il est composé du nom de la base de données

source, du nom de la relation source contenant ses équivalents ainsi que des noms des attributs qui

lui sont équivalents.

2.4.2.1 Les types des règles de mapping

A- Les correspondances entre relations : Pour chaque relation RMed du schéma médiateur, est

assigné un élément XML dans le document des règles de mapping, contenant ses

correspondances avec les relations des schémas sources. Cet élément est constitué d’une part,

du nom de la relation RMed, d’éléments contenant les noms des relations qui lui sont

équivalentes dans les schémas sources et les noms des bases de données les contenant et

70

d’autre part, des correspondances des attributs de la relation du schéma médiateur (DTD de la

Figure 19).

B- Les correspondances entre attributs : Ces correspondances relient les attributs du schéma

médiateur à ses équivalents dans les schémas sources. Ils sont définis par leur nom, un

ensemble de liens contenant les noms des attributs qui leur sont équivalents dans les schémas

sources et les noms des relations et bases de données les contenant. Ils peuvent également

être composés de fonctions de conversion (DTD de la Figure 19).

2.4.2.2 Les cardinalités de règles de mapping

Les règles de mapping peuvent être simples de type 1-1, reliant un attribut (ou une relation)

du schéma médiateur à un attribut (ou relation) de la base de données existante.

Exemple : L’attribut « A » de la relation R est relié à l’attribut « B » de la relation R2. Ce processus

se complique quand le type du mapping devient 1-N c'est-à-dire dans le cas où un attribut du schéma

médiateur remplacerait plusieurs attributs du schéma source ou bien un attribut de la base de données

existante est explosé en plusieurs attributs dans le schéma médiateur.

Exemple : L’attribut adresse peut être la fusion du numéro de la rue, du nom de la rue et du code

postal. En effet nous pouvons avoir dans une base de données source l’attribut Adresse contenant

l’adresse complète des personnes alors que dans le schéma médiateur, les adresses des personnes

sont stockées dans plusieurs attributs tels que le nom de la rue et le code postal. La règle de mapping

dans ce cas, est de type complexe, liant l’ensemble des attributs, numéro de la rue, nom de la rue et

du code postal du schéma médiateur, à l’attribut Adresse de la première base de données. Ceci est

présenté dans le document des règles de mapping de la Figure 20.

En effet la Figure 20 montre une partie d’un document de règles de mapping liant l’attribut Adresse

du schéma médiateur à l’attribut Adresse (mapping de type simple 1-1) dans la base de donnée BD1,

et aux attributs N-Rue, Rue et code-postal (mapping de type complexe 1-N) dans la base de données

BD2. Pour ce faire la fonction de conversion « Concatenat » est utilisée. <?xml version="1.0" encoding="UTF-8"?> <SchemaMedMapping> <RelationMedMapping nom-relation="Patient"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Adresse">

71

<LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Adresse</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>N-Rue</nom-attrib> <nom-attrib>Rue</nom-attrib> <nom-attrib>Code-postal</nom-attrib> <fctConv>Concatenat</fctConv> </LienAttribut> </AttributMedMapping> </RelationMedMapping> </SchemaMedMapping>

Figure 20 : Document de règles de mapping

2.4.2.3 Fonction de conversion

Une règle de mapping peut utiliser une fonction de conversion afin d’établir les

correspondances. Nous pouvons lier un attribut Att dans un schéma médiateur à un attribut

Fonction(Att) dans une base de données source. Par exemple nous pouvons faire correspondre un

attribut « date de naissance » dans une première base de données à un attribut « age » dans une

seconde base de données. Afin de comparer les âges des deux bases de données, nous devons

calculer les âges des patients stockés dans la deuxième base de données à partir de leurs dates de

naissance. Pour ce faire une fonction de conversion est utilisée. Nous avons également recours à des

fonctions de conversion de type et de format qui convertissent nos données d’un format (ou d’un

type) à un autre.

2.4.3 Règles de génération du schéma médiateur

Le processus de génération du schéma médiateur suit un ensemble de règles présentées ci-

dessous. Nous montrons dans les paragraphes 2.4.4.1, 2.4.4.2, 0 et 2.4.4.5 comment ces règles sont

utilisées :

Règle 17 : Le schéma médiateur est généré à partir des documents XML décrivant chaque base de

données à intégrer.

Règle 18 : Un document XML contenant les correspondances entre les relations du schéma

médiateur et celles des schémas sources, est rattaché au schéma médiateur.

72

Règle 19 : Pour chaque concept C référencé dans un document décrivant une base de données faire :

- Recherche des concepts qui lui sont équivalents et qui sont contenus dans les documents

décrivant chaque base de données,

- Recherche des relations décrites par le concept C,

- Création de la relation dans le schéma médiateur, portant le nom du concept C,

- Création des règles de mapping.

Règle 20 : Pour chaque concept C décrivant un attribut et appartenant au document XML décrivant

une base de données faire :

- Recherche des concepts qui lui sont équivalents et qui sont contenus dans les documents

décrivant chaque base de données,

- Recherche des attributs décrits par le concept C,

- Création de l’attribut dans le schéma médiateur portant le nom du concept C,

- Création des règles de mapping.

Règle 21 : Les attributs et les relations du schéma médiateur portent les noms des concepts qui leur

sont équivalents dans le document XML les décrivant.

Règle 22 : Pour chaque relation (ou attribut) créée dans le schéma médiateur, une règle de mapping

est créée. Cette règle définit les correspondances entre les éléments du schéma médiateur et ceux des

schémas sources.

Règle 23 : La règle de mapping d’une relation (resp. un attribut) porte le nom de la relation (resp.

attribut) du schéma médiateur à laquelle elle est référée.

Règle 24 : La règle de mapping d’une relation est composée de :

- Noms des relations sources équivalentes à celle du schéma médiateur,

- Nom des bases de données sources,

- Règles de mapping des attributs.

73

Règle 25 : La règle de mapping d’un attribut est composée de :

- Noms des attributs sources équivalents à celui du schéma médiateur,

- Noms de la relation source équivalente à celle qui le contient dans le schéma médiateur le

contenant,

- Nom des bases de données sources,

- Fonction de conversion dans le cas échéant.

Règle 26 : Si une relation X, appartenant à une base de données B, est équivalente à un attribut Y,

appartenant à une base de données Z, et si X et Y sont insérés dans le schéma médiateur, alors une

correspondance sera créée entre X et Y. Pour ce faire, nous recherchons l’attribut A appartenant à la

relation X et équivalent l’attribut Y. Une fois trouvé, un lien est créé, liant Y à A.

Exemple : Si nous avons la relation « Service » du schéma médiateur et si dans la relation

« Médecin » nous avons également l’attribut service. Nous recherchons alors un attribut appartenant

à « Service » et équivalent à l’attribut « service » de la relation « Medecin » (exemple : nom-service).

Nous créerons ensuite une correspondance dans le document des règles de mapping liant l’attribut

service à son équivalent dans la relation « Service ».

Règle 27 : Si nous voulons ajouter à la relation T du schéma médiateur les attributs X et Y, et s’il

existe déjà un attribut Z, tel que la fusion de X et Y est équivalente à Z. Alors dans ce cas les deux

attributs ne sont pas insérés dans le schéma médiateur et une fonction de conversion (« Concatenat »)

est utilisée.

Règle 28 : Si dans une relation du schéma médiateur, deux attributs portent le même nom alors qu’ils

sont différents, l’un des attributs sera précédé du nom de la relation dont il provient. Exemple si la

relation « Patient » du schéma médiateur contient deux attributs de même nom « Maladie» alors un

des deux attributs portera le nom « Dossier_medical.Maladie».

Règle 29: Les liens entre les relations des schémas à intégrer doivent être préservés dans le schéma

médiateur.

Règle 30 : Les clés primaires qui n’ont pas de concepts équivalents dans l’ontologie de structure sont

fusionnées dans le schéma médiateur.

74

Règle 31 : Les clés primaires qui ont des concepts équivalents dans l’ontologie de structure,

subissent le même traitement que les attributs non identifiants.

2.4.4 Génération du schéma médiateur

Afin de créer le schéma médiateur nous recherchons, pour chaque concept décrivant une

relation, ses équivalents dans les différentes bases de données. Une fois ces concepts trouvés, nous

créons une relation dans le schéma médiateur portant leur nom. Durant la deuxième étape, le même

traitement est appliqué sur les concepts décrivant les attributs. Il faut noter que pour chaque attribut

ou relation créée dans le schéma médiateur, un ensemble de règles de mapping leur est assigné. Une

fois le schéma médiateur généré, nous reproduisons les liens entres les relations des schémas sources

dans le schéma médiateur. Pour ce faire pour chaque relation équivalente à la relation du schéma

médiateur nous récupérons la liste des relations où a été exportée sa clé primaire. Nous exportons

ensuite les attributs composant la clé primaire de la relation du schéma médiateur dans les relations

du schéma médiateur équivalentes à celle de la liste.

75

<BD1> <R1> <Concept>C1</Concept> <Att1>C1’</Att1> <Att2>C1’’</Att2> </R1> <R2> <Concept>C2</Concept> <Att3>C2’</Att1> <Att4>C2’’</Att4> </R2> </BD1>

<BD2> <R1> <Concept>C1</Concept> <Att1>C1’’’</Att1> <Att2>C1’</Att2> </R1> </BD2>

Document décrivant la base de données

2 relations décrites par le même concept ⇒ Création relation

schéma médiateur « C1 »

<Schéma Med> <Rmed Nom= “C1”> </AttMED Nom = “C1’ ” > </AttMED Nom = “C1’ ” > </AttMED Nom = “C1’’’ ” > </Rmed > … </Schéma Med>

<RG Mapping ><RmedMapp Nom= “C1”> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>R1</nom-rel>

</lienRelation> </RmedMapp > … </RG Mapping >

Document contenant les règles de mapping

Document contenant le schéma médiateur

Création schéma

médiateur

Figure 21 : Processus de génération de schéma médiateur

2.4.4.1 Génération des relations du schéma médiateur

Notre processus de génération de schéma médiateur n’utilise pas les schémas existants mais

les documents XML les décrivant (Règle 17).

Phase 1 : Récupération du concept C

Nous entamons notre traitement par la récupération de la liste des concepts liés aux relations à partir

des documents XML décrivant chaque base de données. Une fois la liste des concepts récupérée, un

concept C quelconque est choisi pour être traité. Il faut noter que le choix des concepts n’affecte, en

aucun cas, le résultat de la génération du schéma médiateur car quel que soit le concept choisi les

76

résultats obtenus sont les mêmes puisque nous parcourons toute la liste et nous appliquons le même

traitement pour chaque concept C (Règle 19).

Phase 2 : Trouver les relations décrites par le concept C

Nous prenons de chaque document décrivant les bases de données, l’élément XML, ELXML,

contenant le concept C. Nous récupérons ensuite le nom de la relation décrite par le concept (Règle

19), ainsi que le nom de la base de données la contenant.

Phase 3 : Création de la relation dans le schéma médiateur

Après avoir trouver la liste ListR des relations décrites par le concept C ainsi que les noms des bases

de données les contenant, nous créons dans le schéma médiateur, une relation RMed, équivalente à

celles trouvées ci-dessus. Cette relation, porte le nom du concept C (Règle 19).

Phase 4 : Création des règles de mapping

Nous créons un élément XML de type RelationMedMapping dans le document XML contenant les

règles de mapping pour chaque élément de la liste trouvée durant la phase 2 (Règle 22). Cet élément

porte le nom de la relation RMed du schéma médiateur (Règle 23). Nous lui insérons également,

pour chaque relation appartenant à la liste ListR, un élément XML de type lienRelation. Cet élément

est composé du nom de la relation du schéma source ainsi que de celui de la base de données à

laquelle elle appartient (Règle 24), ceci nous permet de relier la relation du schéma médiateur à ses

équivalences dans les schémas sources.

Exemple : La Figure 22 expose une partie d’un document XML contenant des règles de mapping ; ce

document permet de lier la relation « Patient » du schéma médiateur aux relations « Patient » de la

base de données BD1 et à la relation « Malade » de la base de données BD2. Il est composé de

l’élément XML RelationMedMapping contenant le nom de la relation « Patient » du schéma

médiateur. Cet élément est composé de deux éléments Lien-Relation, contenant chacun aussi bien le

nom des schémas sources « BD1, BD2 » que les noms des relations sources « Patient, Malade ». <?xml version="1.0" encoding="UTF-8"?> <SchemaMedMapping> <RelationMedMapping nom-relation="Patient"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> </lienRelation>

77

</RelationMedMapping> </SchemaMedMapping>

Figure 22 : Document XML contenant des règles de mapping

2.4.4.2 Génération des attributs du schéma médiateur

Une fois la relation du schéma médiateur créée, nous traitons les concepts décrivant les

attributs contenus dans le concept C (traité ci-dessus) afin de les insérer dans le schéma médiateur.

Phase 1 : Récupération du concept CAtt

De la même manière que pour les traitements des relations, nous récupérons la liste des concepts

équivalents aux attributs et contenus dans le concept C.

Phase 2 : Trouver les attributs décrits par le concept CAtt

Nous récupérons à partir des autres bases de données les concepts équivalents au concept CAtt. A

cette fin, nous recherchons dans les documents XML décrivant chaque base de données, et plus

précisément dans les éléments du concept C, le concept CAtt.

Phase 3 : Création d’un attribut dans le schéma médiateur

Une fois en possession de la liste ListAtt, des attributs décrits par le concept CAtt, ainsi que les noms

des bases de données les contenant, un attribut AttMed portant le nom du concept CAtt est inséré

dans la relation RMed du schéma médiateur.

Phase 4 : Création des règles de mapping

De la même manière que pour les correspondances entre les relations, nous créons un élément XML

de type AttributMedMapping dans le document XML contenant les règles de mapping. Cet élément

porte le nom de l’attribut AttMed (Règle 23). Nous lui insérons également, pour chaque attribut

appartenant à la liste ListAtt, un élément XML de type LienAttribut. Cet élément est composé du

nom de l’attribut, de sa relation ainsi que de celui de la base de données source à laquelle il

appartient, permettant ainsi de lier l’attribut du schéma médiateur à ses équivalents dans les schémas

sources (Règle 25). Dans le cas où une conversion serait nécessaire, nous ajoutons une fonction de

conversion à l’élément XML contenant les correspondances.

78

2.4.4.3 Insertion des clés primaires des relations du schéma médiateur

Le traitement des clés primaires représente un cas particulier du traitement des attributs. Il est

composé de deux types :

Partie A : Concerne les clés primaires qui n’ont pas de concepts équivalents dans l’ontologie de

structure. Dans ce cas nous fusionnons les attributs des clés primaires de toutes les relations des

schémas sources équivalentes, en évitant les redondances (Règle 30).

Partie B : Concerne les clés primaires ayant des concepts équivalents dans l’ontologie de structure.

Pour ce type de clés, le même traitement que celui des attributs non identifiants, est appliqué (Règle

31).

2.4.4.4 Optimisation du schéma médiateur

Dans cette partie, le schéma médiateur est optimisé, afin d’enlever les redondances et de

résoudre les hétérogénéités structurelles :

- les attributs équivalents aux relations,

- les attributs ayant des relations d’hyponymie entre eux.

Le traitement des redondances se compose de deux étapes, à savoir leur détection et leur traitement.

1. Les attributs équivalents aux relations

Pour ce type de redondance, nous détectons les attributs pouvant être équivalents à des relations à

partir de leur nom (synonymes) et des documents XML les décrivant. Une fois la relation trouvée,

nous comparons le contenu de ses attributs avec celui de l’attribut portant son nom, afin de trouver

l’attribut Att2 qui lui est équivalent. Les résultats sont ensuite présentés à l’utilisateur-concepteur qui

les confirme ou les infirme. Pour chaque attribut Att équivalent à une relation R, nous modifions ses

liens de correspondances avant de l’enlever de la relation du schéma médiateur le contenant. La

modification des liens de correspondance consiste à faire correspondre les attributs sources Atti

correspondant à l’attribut Att, à l’attribut Att2 (Règle 26).

Exemple : Si dans la relation « Médecin » nous avons l’attribut « service » contenant le nom du

service dans lequel travaille un médecin et si la relation « Service » existe aussi dans le schéma

médiateur, alors cet attribut est enlevé et des correspondances entre les attributs des schémas sources

qui lui sont liés et la relation « Service » sont ajoutées dans le document des mapping.

2. Les attributs ayant des relations d’hyponymie entre eux (1 attribut : N attributs).

Si dans une relation du schéma médiateur un attribut est un hyponyme d’un ensemble d’attributs

appartenant à la même relation, ces derniers sont fusionnés et remplacés par l’attribut parent dans la

79

relation (Règle 27). Les relations hyponymes sont reconnues à partir des liens (« Composition »)

entre les concepts de l’ontologie de structure. Pour ce faire, nous testons chaque attribut d’une

relation avec ceux qui la composent, et vérifie l’existence de lien entre eux. Si le lien trouvé est de

type composition alors l’attribut fils est remplacé par l’attribut père. Nous modifions, ensuite, les

liens des correspondances en faisant correspondre les attributs des schémas sources qui sont en

correspondance avec l’attribut fils à l’attribut père.

Exemple : Si nous avons les attributs Adresse, Rue, Numéro_de_rue et Code_postal, nous pouvons

alors à partir de l’ontologie de structure, remplacer ces attributs par l’attribut Adresse, et modifier les

règles de mapping en faisant correspondre l’attribut Adresse du schéma médiateur aux attributs Rue,

Numéro_de_rue et Code_postal des schémas sources.

2.4.4.5 Traitement des liens entre les relations du schéma médiateur

Une fois le schéma médiateur généré, nous traitons les liens entre les relations (Règle 29). Pour

chaque relation du schéma médiateur sont appliquées trois phases de traitement.

Phase 1 : Récupérer les relations sources équivalentes à celle du schéma médiateur

Pour chaque relation Rmed du schéma médiateur, nous récupérons à partir du document XML

contenant ses règles de mapping, la liste des relations qui lui sont équivalents dans les schémas

sources.

Phase 2 : Trouver les « References »

Une fois les noms des relations obtenus, nous recherchons dans les documents XML les décrivant, la

liste des relations dans lesquelles la clé primaire a été exportée. Pour chaque relation trouvée ci-

dessus, nous récupérons à partir du document contenant les règles de mapping, la liste ListEquiv des

noms des relations du schéma médiateur qui leur sont équivalentes.

Phase 3 : Reproduire les liens dans le schéma médiateur

Nous exportons ensuite la clé primaire de la relation Rmed dans les relations appartenant à la liste

ListEquiv en évitant les redondances, permettant ainsi de reproduire les liens entre les différentes

relations. En effet si dans les schémas sources la relation R1 est liée à la relation R2, alors la Rmed1

80

du schéma médiateur équivalente à la relation R1, sera, elle aussi liée à la relation Rmed2 du schéma

médiateur équivalente à la relation R2.

A la fin du traitement, nous obtenons deux documents XML, le premier contenant le schéma

médiateur, et le second, les règles de mapping rattachées aux éléments du premier document (Règle

18).

2.4.4.6 Conclusion

Afin de conclure cette partie, nous résumons le processus de génération de schéma médiateur.

Partie II : Génération du schéma médiateur : Durant cette partie, le schéma médiateur est créé à

partir des documents décrivant les base de données, elle est composée de trois étapes :

Etape A : Création des relations

- A partir des concepts décrivant chaque relation, rechercher les relations des

différentes bases de données, décrites par le même concept,

- Créer dans le schéma médiateur une relation portant le nom du concept

décrivant les relations trouvées ci-dessus,

- Créer pour chaque relation du schéma médiateur, une règle de mapping

permettant de la lier à ses équivalentes dans les bases de données.

Etape B : Création des attributs

- A partir des concepts décrivant chaque attribut appartenant aux relations

obtenues dans l’étape A, rechercher les attributs des différentes bases de

données, décrits par le même concept,

- Créer dans le schéma médiateur un attribut portant le nom du concept

décrivant les attributs trouvés ci-dessus,

- Créer pour chaque attribut du schéma médiateur, une règle de mapping

permettant de le lier à ses équivalents dans les bases de données,

- Reproduire dans le schéma médiateur, les liens existant entre les relations des

schémas à intégrer.

Etape C : Optimisation du schéma médiateur : Durant cette étape nous traitons le schéma

médiateur généré afin de l’optimiser et résoudre les hétérogénéités structurelles.

81

2.5 Modification du schéma médiateur

Durant cette partie nous traitons les changements du schéma médiateur, dus à ceux des

schémas sources. Ces changements peuvent être l’insertion ou la suppression de relations ou

d’attributs dans les sources de données.

2.5.1 Processus d’insertion

2.5.1.1 Ajout d’une relation dans un schéma source

La Figure 23 expose les étapes de modification du schéma médiateur dans le cas de

l’insertion d’une relation dans une des bases de données sources. Durant la première phase, nous

décrivons la nouvelle relation Rnew ainsi que ses attributs. La description d’une relation a déjà été

exposée dans la partie 2.3 de ce chapitre et le même traitement est appliqué sur cette relation ainsi

que sur ses attributs. Une fois la description achevée, nous modifions le document XML décrivant sa

base de données. La deuxième phase concerne la modification du schéma médiateur. Pour ce faire

nous recherchons une relation du schéma médiateur portant le nom du concept Cnew décrivant la

relation Rnew. Si la relation existe déjà dans le schéma médiateur nous modifions les règles de

mapping afin de lier la relation insérée dans la base de données à celle trouvée dans le schéma

médiateur. Dans le cas où la relation n’existerait pas dans le schéma médiateur, une relation portant

le nom du concept Cnew y est créée. Une fois la relation créée, nous créons, dans le document

contenant les règles de mapping, les correspondances liant cette relation à son équivalente dans la

base de données source. Afin de résoudre l’hétérogénéité structurelle nous appliquons le processus

d’optimisation sur le schéma modifié.

82

Figure 23 : Processus de modification du schéma médiateur (Insertion Relation)

2.5.1.2 Ajout d’un attribut dans une relation du schéma source

Figure 24 : Processus de modification du schéma médiateur (Insertion Attribut)

Attribut Description de l’attribut

Concept Equivalent

BD

Modification

Doc XML décrivant la

BD

Ontologie de structure

Insertion

Schéma médiateur

Rech. Att. Equiv. OU

Insérer Att.

Règles de mapping

Modif. Correspondance

Nom Rel. équivalente

Relation Description de la relation

Concept Equivalent

BD

Modification

Doc XML décrivant la

BD

Ontologie de structure

Insertion

Schéma médiateur

Rech. Rel. Equiv. OU

Insérer Rel.

Règles de mapping

Modif. Correspondance

83

De la même manière que pour l’insertion d’une relation, l’insertion d’un attribut AttNew

provoque le même processus de traitement. Nous décrivons chaque attribut durant la première phase,

avant de modifier le document décrivant la base de données. Nous recherchons, ensuite, dans la

relation Rmed du schéma médiateur équivalente à la relation source Rsource où a été inséré

l’attribut, un attribut portant le nom du concept le décrivant. Pour ce faire nous nous positionnons sur

l’élément du document des règles de mapping qui contient les correspondances de la relation

Rsource. Une fois l’élément trouvé, nous récupérons le nom de la relation Rmed du schéma

médiateur équivalente à la relation Rsource. Durant la deuxième étape nous modifions le schéma

médiateur en recherchant, en premier, si la relation Rmed contient un attribut portant le nom du

concept décrivant l’attribut AttNew. Si l’attribut existe déjà nous modifions les règles de mapping en

insérant un lien entre l’attribut du schéma médiateur et celui inséré dans la base de données source.

Dans le cas où l’attribut n’existerait pas dans la relation du schéma médiateur, un attribut portant le

nom du concept le décrivant est créé dans le schéma médiateur. Une fois l’attribut créé, nous

insérons dans le document contenant les règles de mapping une correspondance le liant à son

équivalent dans la base de données source. A la fin de la modification du schéma médiateur nous

appliquons le processus d’optimisation afin de vérifier les différentes redondances.

2.5.1.3 Ajout d’une clé primaire dans une relation du schéma source

L’insertion de clés primaires provoque un traitement particulier du schéma médiateur. Tout

comme pour le traitement des attributs simples nous décrivons chaque attribut composant la clé

primaire. Nous modifions, ensuite, le document décrivant leur base de données. Durant la description

nous modifions également la liste des relations où a été exportée la clé primaire de la relation en

phase de description. Une fois la description faite, nous modifions le schéma médiateur. Pour ce

faire, nous nous positionnons sur l’élément du document des règles de mapping qui contient les

correspondances. Nous extrayons ensuite le nom de la relation Rmed du schéma médiateur

équivalente à la relation contenant la clé primaire « CleP » à insérer. Durant la deuxième phase, nous

modifions le schéma médiateur en recherchant en premier si la relation Rmed contient déjà la clé

primaire (ou une partie de la clé primaire). Si cette dernière existe déjà, nous modifions les règles de

mapping afin de la lier à la clé primaire contenue dans la relation source. Dans le cas contraire, la clé

primaire est insérée dans le schéma médiateur ainsi que ses correspondances dans le document

contenant les règles de mapping. Une fois la mise à jour terminée, nous recherchons dans le

document décrivant la base de données source, la liste des relations ListeRel où a été exportée la clé

primaire « CleP ». Nous recherchons ensuite dans le document contenant les règles de mapping, pour

84

chaque relation appartenant à la liste ListeRel, sa relation équivalente dans le schéma source. Une

fois les relations trouvées nous leur insérons la clé primaire et nous modifions le document des règles

de mapping.

2.5.2 Processus de suppression

2.5.2.1 Suppression d’une relation dans un schéma source

Suppression

Nom Relation

BD Concept

équivalent Règles de mapping

Schéma médiateur

Modification OU

Suppression Modif. OU Supp. Correspondance

Figure 25 : Processus de modification du schéma médiateur (Suppression Relation)

La Figure 25 expose les étapes de modification du schéma médiateur dans le cas d’une

suppression d’une relation dans une des bases de données sources. Durant la première phase, nous

recherchons dans le document des règles de mapping, le nom de la relation Rmed du schéma

médiateur équivalente à la relation Rsup à enlever. Une fois trouvée nous vérifions si la relation à

supprimer, a des équivalentes dans les autres bases de données. Dans le cas où la relation aurait

différentes équivalences, nous ne modifions que les règles de correspondances. Dans le cas contraire

nous enlevons la relation Rmed, ainsi que ses correspondances, du schéma médiateur. Une fois la

mise à jour du schéma médiateur effectuée nous traitons les clés primaires de la relation Rsup. Pour

ce faire, nous récupérons, à partir du document décrivant sa base de données, la liste des relations

ListeRel où a été exportée sa clé primaire. Nous recherchons ensuite, dans le document des règles de

mapping, les relations du schéma médiateur équivalentes à celles contenues dans la liste listeRel.

85

Une fois les relations obtenues, nous extrayons la clé primaire qui a été exportée de la relation Rsup

supprimée ci-dessus afin de détruire ces liens, qui ont été reproduits dans le schéma médiateur.

2.5.2.2 Suppression d’un attribut dans un schéma source

De la même manière que pour la suppression d’une relation, nous modifions le schéma

médiateur. Dans un premier temps, nous recherchons dans le document contenant les règles de

mapping, l’élément contenant les correspondances de la relation source de l’attribut supprimé. Dans

un second temps, nous récupérons le nom de l’attribut AttMed du schéma médiateur équivalent à

l’attribut AttSup. Une fois trouvée, nous vérifions si l’attribut à supprimer, a des équivalents dans les

autres bases de données. Dans le cas où l’attribut possèderait différents équivalents, nous ne

modifierions que les règles de correspondances. Dans le cas contraire nous l’enlevons, ainsi que ses

correspondances, de la relation du schéma médiateur.

86

3 Conclusion du chapitre

Dans ce chapitre nous avons présenté notre proposition qui consiste à générer un schéma

médiateur à partir de schémas de bases de données sources. Pour ce faire nous décrivons chaque base

de données à l’aide de termes communs issus d’une ontologie de structure, cette description est

stockée dans des documents XML, qui sont ensuite exploités afin de générer un schéma médiateur

ainsi que ses règles de mapping.

Notre approche présente deux apports. Le premier est la génération du schéma médiateur le

plus automatiquement possible, génération qui diminue l’intervention de l’utilisateur-concepteur par

rapport aux approches [DOH 02] [RAH 01c] présentées dans le chapitre « Etat de l’art ». En effet,

les documents XML décrivant les schémas nous aident à trouver les ressemblances et à les résoudre

en se basant sur des règles présentées ci-dessus. Le second apport réside dans le fait que notre

proposition résout un des inconvénients majeurs de l’approche GAV (Global As Views) [ROU 04]

concernant l’ajout et la suppression de relations dans les bases de données. En effet nous n’avons

plus à régénérer entièrement le schéma médiateur à chaque modification des schémas des bases de

données mais seulement à le modifier, ainsi que le document XML contenant les règles de mapping.

Nous terminons notre conclusion par l’exposition du tableau présenté dans l’introduction

avec les solutions proposées pour chaque type d’Hétérogénéité :

87

Type d’Hétérogénéité Résolution

Hétérogénéité sémantique

Des relations ou attributs portent le même

nom et diffèrent dans leur signification

Deux relations « Diagnostic », la première recense

les maladies des patients hospitalisés dans un

service, la seconde contient toutes les maladies

existantes [Résolu lors de la description des bases

de données, en les décrivant par des concepts

différents]

Des relations ou attributs diffèrent dans

leur nom et ont la même signification

Deux relations Patient et Malade, diffèrent dans

leur nom mais stockent les données sur les

patients

[Résolu lors de la description des bases de

données, en les décrivant par le même concept]

Hétérogénéité structurelle

BD1 BD2 Exemple

Relation Attribut - Relation SERVICE contenant son nom, sa

spécialité, son adresse ainsi que d’autres

informations.

- Attribut SERVICE ne contenant que le nom du

service

[Résolu par la Règle 26]

Relation spécialisée Relation

généralisée

- Relation « Médecin »

- Relation « Pédiatre »

- Relation « Chirurgien »

[Résolu par la Règle 11]

Un attribut N Attributs - Attribut Adresses = N°rue + Rue + Code

Postal +Ville

[Résolu par la Règle 27]

Tableau 8 : Tableau présentant les différents types d’hétérogénéités ainsi que leur résolution.

88

Chapitre IV : Médiation et protection 1 Introduction..................................................................................................................................89 2 Médiateur .....................................................................................................................................89

2.1 Introduction..........................................................................................................................89 2.2 Architecture logicielle..........................................................................................................89 2.3 Traitement des requêtes .......................................................................................................91

2.3.1 Décomposition des requêtes ........................................................................................91 2.3.2 Traduction de la requête...............................................................................................91 2.3.3 Exécution d’une requête ..............................................................................................91 2.3.4 Interaction médiateur – ontologie de valeurs...............................................................92

2.4 Algorithme de traitement de la requête................................................................................93 2.5 Conclusion ...........................................................................................................................97

3 Contrôle de données.....................................................................................................................98 3.1 Introduction..........................................................................................................................98 3.2 Utilisation de DRUID comme système d’entrée pour le médiateur ....................................98

3.2.1 Saisie des données avec DRUID..................................................................................99 3.2.2 Consultation des données avec DRUID.....................................................................100

3.3 Génération des DTDs.........................................................................................................102 3.3.1 Génération des DTD SSD..........................................................................................102

3.3.1.1 Présentation des DTDs SSD ..................................................................................102 3.3.1.2 Le processus de génération des DTDs SSD...........................................................104 3.3.1.3 L’algorithme de génération des DTD SSD:..........................................................106

3.3.2 Génération des DTD WSD ........................................................................................109 3.3.2.1 Présentation des DTDs WSD.................................................................................109 3.3.2.2 Le processus de génération des DTDs WSD .........................................................110 3.3.2.3 L’algorithme de génération de la DTD WSD ........................................................111

3.3.3 Filtrage des DTDs ......................................................................................................111 3.3.3.1 Problématique ........................................................................................................111 3.3.3.2 Proposition .............................................................................................................112 3.3.3.3 Algorithme de filtrage des DTDs...........................................................................113

3.3.4 Modification du document.........................................................................................115 3.3.4.1 Filtrage d’un document en consultation.................................................................115 3.3.4.2 Algorithme de filtrage............................................................................................116

3.4 Conclusion .........................................................................................................................118 4 Conclusion du chapitre ..............................................................................................................119

89

1 Introduction

Dans le chapitre III (Architecture d’un système de médiation), nous avons présenté une

proposition à notre problématique, permettant de générer un schéma médiateur à partir de documents

XML décrivant les bases de données à intégrer. Ces documents sont construits afin d'unifier les

termes des différents schémas. Dans ce chapitre nous allons montrer comment cette vue est

exploitée. Le deuxième problème qui se pose à nous, est que la manipulation des données peut être

faite par divers utilisateurs ayant différentes autorisations. Nous devons donc présenter une solution

permettant de protéger les données confidentielles. Nous exposons dans la partie 3, une méthode qui

filtre les données suivant les droits de l’utilisateur.

Ce chapitre est structuré comme suit : une première partie présente l’architecture et le

fonctionnement de notre médiateur et une seconde partie détaille la proposition permettant de

protéger les données en consultation et en saisie.

2 Médiateur

2.1 Introduction

Afin de valider notre proposition et de tester l’intérêt du schéma médiateur nous avons conçu

une partie d’un médiateur permettant de distribuer et de traduire des requêtes simples, formulées sur

la vue unifiée, en des requêtes propres à chaque base de données source. Notre médiateur récupère

des requêtes formulées par l’utilisateur avec les termes du schéma médiateur et les décompose afin

d’en extraire les noms des relations et attributs interrogés. Une fois les relations et les attributs

récupérés, il se connecte au document XML contenant les différentes correspondances et effectue la

traduction nécessair pour distribuer les requêtes sur les différentes bases de données. Il présente enfin

les résultats reçus.

2.2 Architecture logicielle

La Figure 26 présente l’architecture de notre médiateur. L’utilisateur formule une requête

utilisant l’interface graphique. Cette requête est envoyée au médiateur qui la décompose en plusieurs

parties (SELECT, FROM et WHERE) avant de la transmettre au composant DecomposReq. Ce

dernier traite chaque partie et extrait les noms des relations et des attributs utilisés dans la requête.

Une fois le traitement terminé, le composant Traducteur remplace chaque relation et chaque attribut

de la requête par son équivalent, en utilisant les règles de mapping rattachées au schéma médiateur. Il

90

renvoie ensuite au médiateur une requête pour chaque base de données. Le Processeur de requêtes

exécute chaque requête et renvoi les tuples au module FormatResultat qui recompose les résultats et

les formate dans un document XML avant de les afficher à l’utilisateur.

Résultats

Requêtes traduites

Document XML

Requêtes traduites

Requête

Interface graphique

Médiateur

Traducteur DecomposReq

BD1

BD2

BD3Mapping

(XML)

FormatResultat Processeur de requêtes

Requêtes décomposées

Ontologie de valeurs

GestOnto Synonymes

Figure 26 : Architecture du médiateur

Notre médiateur est composé des modules suivants :

InterfaceGraphique : Permet à l’utilisateur de formuler sa requête sur la vue unifiée et de visualiser

les résultats,

Mediateur : C’est le chef d’orchestre de l’application; il récupère la requête et l’envoi aux différents

composants. Il reçoit ensuite les résultats avant de les renvoyer à l’interface graphique pour être

affichés,

DecomposReq : Décompose la requête, et récupère les noms des relations, des schémas et des

attributs, ainsi que les conditions,

FormatResulat : Recompose les résultats et les formate dans un document XML avant qu’il envoie

au médiateur,

Processeur de Requêtes : Exécute chaque requête sur sa base de données et envoie les résultats au

module FormatResultat,

91

Traducteur : Traduit la requête principale en plusieurs requêtes propres à chaque base de données.

Pour ce faire, il utilise le document XML rattaché au schéma médiateur contenant les règles de

mapping,

GestOnto : Récupère, à partir de l’ontologie de valeurs, les synonymes des termes utilisés dans les

requêtes.

2.3 Traitement des requêtes

2.3.1 Décomposition des requêtes

L’utilisateur formule une requête sur le schéma médiateur en utilisant le vocabulaire retenu

dans le schéma de ce dernier. La requête est envoyée, ensuite, au médiateur afin d’être décomposée

en plusieurs requêtes sur différentes sources de données. Le médiateur décompose la requête en trois

parties, à savoir les données à afficher qui sont après la clause SELECT, les relations interrogées, se

trouvant après la clause FROM, ainsi que les relations et les attributs qui sont contenus dans la

condition et qui viennent après la clause WHERE. Une fois terminé, la liste des relations et attributs

est extraite de la requête, elle est renvoyé au médiateur. Ce dernier la renvoie au traducteur de

requête.

2.3.2 Traduction de la requête

Dans cette partie nous créons pour chaque base de données, ses propres requêtes. Pour ce

faire le traducteur remplace les noms des relations et des attributs par leur équivalent dans chaque

base de données. Durant la première phase, nous récupérons pour chaque base de données, les

relations des requêtes principales et nous recherchons ensuite dans le document XML contenant les

différentes correspondances, les relations qui leur sont équivalentes dans cette base de données. Une

fois le traitement des relations terminé, nous traduisons leurs attributs, sur lesquelles le même

traitement est appliqué. Les attributs peuvent avoir, en plus des règles de correspondances, des

fonctions de conversion. Dans ce cas cette fonction est ajoutée à l’attribut afin de traduire son

contenu dans le format exigé par le schéma médiateur.

2.3.3 Exécution d’une requête

Une fois la requête principale traduite, le médiateur envoie les différentes requêtes qui lui

sont équivalentes, au processeur de requêtes afin de les exécuter. Ce dernier interroge chaque base de

données, récupère les résultats et les renvoie au composant FormatXML qui les rassemble dans un

92

document XML, avant d’être présentés à l’utilisateur. Les informations extraites de chaque base de

données sont regroupées dans un même élément XML afin de garder trace de la provenance de

chacune d’entre elles. Ce document XML est conforme à la DTD de la Figure 27. Il est composé

d’un ensemble d’éléments, appelés « BD », contenant les noms des bases de données interrogées.

Ces éléments permettent de connaître d’où a été extraite chaque information. Chaque élément BD est

identifié par le nom de la base de données et par un ensemble de tuples. Chaque tuple est composé

d’un ensemble d’attributs ainsi que leur valeur. : <?xml version="1.0" encoding="UTF-8"?> <!ELEMENT DocResultat (BD*)> <!ELEMENT BD (nomBD, tuple*)> <!ELEMENT nomBD (#PCDATA)> <!ELEMENT tuple (attribut*, URL)> <!ELEMENT attribut (nom-attribut, valeur*)> <!ELEMENT URL (#PCDATA)> <!ELEMENT valeur (#PCDATA)> <!ELEMENT nom-attribut (#PCDATA)>

Figure 27 : DTD du document contenant les résultats

2.3.4 Interaction médiateur – ontologie de valeurs

Une particularité de notre médiateur est l’exploitation de l’ontologie de valeurs. Pour chaque

information recherchée, il récupère la liste de ses équivalences dans l’ontologie et recherche la

réponse à la requête à partir de cette liste dans la base de données. Pour ce faire, il vérifie si le nom

de l’attribut recherché existe dans l’ontologie. Si c’est le cas, il extrait de l’ontologie les données

ayant une relation de type « IS-A » ou une relation d’égalité avec le terme recherché dans notre

requête. La recherche terminée, nous modifions la requête en lui insérant des opérateurs booléens

(OR), permettant à l’attribut d’avoir ses valeurs à partir de la liste récupérée de l’ontologie.

Exemple : Soit la requête R : « Rechercher tous les patients qui prennent des Anti-inflammatoire ».

Nous avons dans la requête R la condition « Médicament= ‘Anti-inflammatoire’ ». Pour y répondre,

nous vérifions en premier lieu si notre ontologie (Figure 28) contient le concept Médicament. Si le

concept est trouvé, nous vérifions si le terme ‘Anti-inflammatoire’ est contenu dans ce concept. Une

fois ce dernier trouvé nous récupérons les valeurs ayant une relation « IS-A » avec ‘Anti-

inflammatoire’ : Votrex, Nifluril, Voltarène etc. Notre requête est ensuite modifiée en rajoutant des

opérateurs booléens. « Médicament = ‘Voltarène’ » devient « Médicament = ‘Voltarène’ OR

Médicament= ‘Votrex’ OR Médicament= ‘Nifluril».

93

Medicament

Anti-inflammatoire

Voltarène Nifluril Votrex

IS-A IS-A IS-A

IS-A

Figure 28 : Une partie de l'ontologie médicale

2.4 Algorithme de traitement de la requête Requete_Principale : Requete principale ;

DocMapp : Document des règles de mapping

DEBUT

{Traitement de la clause Select}

Contenu_Select=Recup_Contenu_Select(Requete_Principale) ;

I=0 ;

Tant que ( I < Contenu_Select.size())

Debut

Terme= Contenu_Select.get(I) ;

If (contenu(Terme).compose) then

Debut

{Dans ce cas la variable « Terme » est composée d’une relation et d’un attribut}

{Il se peut que la variable « Terme » soit composée de fonction et d’opérateur. Nous

supposons dans ce cas que les deux fonctions « Recup_Relation » et «Recup_Relation » permettent

d’extraire le nom de la relation ainsi que celui de l’attribut}

Relation = Recup_Relation(Terme) ;

Si Not(Relation.vide) Alors

Liste_Relation_Principale = Liste_Relation_Principale + Relation ;

Attribut = Recup_Attribut(Terme) ;

Si Not(Attribut.vide) Alors

Liste_Attribut_Principale = Liste_Attribut_Principale + Attribut;

Fin

94

Else Debut

{Nous supposons que le contenu de Terme simple dans le cas où il ne contient que le nom

d’un attribut}

Liste_Attribut_Principale = Liste_Attribut_Principale + Terme ;

Fin

I=I+1 ;

Fin

{Traitement de la clause From}

Contenu_From = Recup_Contenu_From(Requete_Principale) ;

I=0 ;

Tant que (I < Contenu_From.size())

Debut

Terme= Contenu_From.get(I) ;

If (contenu(Terme).compose) then

Debut

{Dans ce cas la variable « Terme » peut être composée d’une relation et d’un alias}

{Nous supposons dans ce cas que les deux fonctions « Recup_Relation » et «Recup_Alias»

permettent d’extraire le nom de la relation ou de l’alias}

Relation = Recup_Relation (Terme) ;

Si Not(Relation.vide) Alors

Liste_Relation_Principale = Liste_Relation_Principale + Relation ;

Alias = Recup_ Alias(Terme) ;

If Not(Alias.vide) then Creer_Lien_Alia(Alia, Relation);

Fin

Else Debut

{Nous supposons que le contenu de Terme simple dans le cas où il ne contient que le nom

dune relation}

Liste_Relation_Principale = Liste_Relation_Principale + Relation ;

Fin

I=I+1 ;

Fin

{Traitement de la clause Where}

Contenu_Where = Recup_Contenu_Where(Requete_Principale) ;

I=0 ;

95

Tant que (I < Contenu_Where.size())

Debut

Terme= Contenu_Where.get(I) ;

If (contenu(Terme).compose) then

Debut

{Dans ce cas la variable « Terme » peut être composée d’une relation et d’un attribut}

{Il se peut que la variable « Terme » soit également composée de constante, d’opérateur,

d’alias… Nous supposons dans ce cas que les deux fonctions « Recup_Relation » et

«Recup_Attribut» permettent d’extraire le nom de la relation ou de l’alias}

Relation = Recup_Relation (Terme) ;

Si Not(Relation.vide) Alors

Liste_Relation_Principale = Liste_Relation_Principale + Relation ;

Attribut = Recup_Attribut(Terme) ;

Si Not(Attribut.vide) Alors

Liste_Attribut_Principale = Liste_Attribut_Principale + Attribut;

Fin

Else Debut

{Nous supposons que le contenu de Terme est simple dans le cas où il ne contient que le nom

d’un attribut}

Liste_Attribut_Principale = Liste_Attribut_Principale + Terme;

Fin

I=I+1 ;

Fin

{Interaction avec l’ontologie de valeurs} I=0 ;

Tant que (I < Contenu_Where.size())

Debut

Valeur = Contenu_Where.get(I) ;

{trouvé la liste des termes équivalent à « Valeur » à partir de l’ontologie de valeurs « OV »}

List_Equiv=Rechec_Equival_Ontologie(OV, Valeur) ;

{Modification de la requête en lui insérant des opérateurs booléens}

Add_Requete_boolean (Valeur, Liste_Equiv, OR) ;

I=I+1 ;

Fin

96

{A ce stade nous avons la liste des relations et des attributs utilisés dans la requête principale}

{Traduction des requêtes}

I=0 ;

Tant que (I<listeBD.size()) faire

Debut

{A partir du document des règles de mapping, DocMapp, traduire les requêtes}

NomBD=listeBD.get(I).nom ;

{Traduction des relations}

J=0 ;

Tant que (j< Liste_Relation_Principale.size()) faire

Debut

{Récupérer l’élément du document des règles des mapping contenant les équivalents de la

relation en phase de traduction}

NomRelation = Liste_Relation_Principale.get(J).nom ;

ElementXML= Recup_Element_Rel(DocMapp, NomRelation) ;

{Rechercher le nom de la relation, appartenant à la base de données « NomBD », et

équivalente à la relation « NomRelation»}

NomRelation_Equivalent= Recherche_Equivalent_Rel(ElementXML, NomBD) ;

List_Relation_Equivalent = List_Relation_Equivalent + NomRelation_Equivalent ;

J=J+1 ;

Fin

{Traduction des attributs}

J=0 ;

Tant que (j< Liste_Attribut_Principale.size()) faire

Debut

{Récupérer l’élément du document des règles des mapping contenant les équivalents de

l’attribut en phase de traduction}

NomAttribut = Liste_ Attribut_Principale.get(J).nom ;

ElementXML= Recup_Element_Attribut(DocMapp, NomAttribut) ;

{Rechercher le nom de l’attribut, appartenant à la base de données « NomBD », et équivalent

à l’attribut « NomAttribut»}

NomAttribut_Equivalent= Recherche_Equivalent_Attribut(ElementXML, NomBD) ;

List_Attribut_Equivalent = List_ Attribut_Equivalent + NomAttribut_Equivalent ;

J=J+1 ;

97

Fin

{Une fois touts les attributs et relations équivalents à ceux de la requête principale trouvés, nous

traduisons cette dernière}

Requete_NomBD = Traduire_Requete(Requete_Principale, Liste_Relation_Principale,

Liste_Relation_Equivalent, Liste_Relation_Principale, liste_Attribut_Equivalent) ;

Liste_Requete_Equivalent = Liste_Requete_Equivalent + Requete_NomBD ;

I=I+1 ;

Fin

{Distribution et exécution des requêtes}

{Créer un document XML qui contiendra les résultats de l’exécution des requêtes}

Creer_Doc(Doc_Resultat) ;

I=0 ;

Tant que (I< Liste_Requete_Equivalent.size()) faire

Debut

Requete = Liste_Requete_Equivalent.get(I) ;

{Exécuter la requête sur sa base de données appropriée}

Resultat = Execute_Requete(Requete, BDI);

{Insérer dans le document contenant les résultats, un élément portant le nom de la base de données

« BDI »}

Insert_Element(Doc_Resultat, BDI);

{Insérer les résultats dans l’élément « BDI »}

Insert_Element(Doc_Resultat, BDI, Resultat);

I=I+1 ;

Fin

{Affichage des résultats}

Affiche_Doc(Doc_Resultat);

FIN

2.5 Conclusion

Dans cette partie nous avons présenté un médiateur qui exploite notre vue unifiée. Son

fonctionnement repose sur un algorithme permettant de traiter une requête formulée sur cette vue,

d’extraire les relations et attributs et de les traduire afin d’avoir des requêtes propres à chaque base

de données. Ce traitement terminé, nous exécutons chaque requête et nous recomposons le résultat

98

dans un document XML qui s’affiche à l’utilisateur. Les résultats sont regroupés selon la base de

données source.

3 Contrôle de données

3.1 Introduction

Une des difficultés dans l’exploitation des bases de données se situe au niveau de la saisie des

informations les alimentant. En effet l’utilisateur voulant saisir des données se retrouve devant des

formulaires de cases à remplir et il est difficile de retrouver la liberté que présente les textes libres.

Afin de résoudre cette problématique nous utilisons le système DRUID [BAD 03a] présenté dans

l’état de l’art.

Le deuxième problème qui se pose à nous est que la manipulation des données peut être faite

par divers utilisateurs ayant différentes autorisations. Ces données peuvent contenir des informations

confidentielles pouvant être saisies et consultées par différents types d’utilisateurs. Il est important de

prendre en compte les droits d’accès aux données à la fois dans la rédaction et dans la présentation

des documents. Nous proposons d’utiliser des DTDs différentes pour les documents aussi bien en

écriture qu’en lecture. Chaque document saisi ou consulté par un utilisateur devra être conforme à

une DTD. Chaque groupe d’utilisateurs possède ses propres DTDs pour les documents en rédaction

et d’autres pour les documents en consultation. Pour ce faire une DTD générique est tout d’abord

créée pour chaque type de document nécessaire [LAF 03]. Les DTDs sont ensuite construites

automatiquement à partir de la DTD générique et des droits et privilèges des groupes d’utilisateurs et

ce par un filtrage des éléments non autorisés [BOU 04]. Le but de notre travail est de proposer et de

réaliser une solution qui permet d’automatiser le plus possible la création des modèles de documents

ainsi que la protection des documents.

La structure de cette partie est comme suit. Après avoir présenté l’utilisation de DRUID par

notre système, nous détaillons en premier la création des DTD à partir de modèle de données et

ensuite, leur modification selon les droits des utilisateurs.

3.2 Utilisation de DRUID comme système d’entrée pour le médiateur

L’objectif de DRUID est d’alimenter des bases de données à partir de documents saisis par

l’utilisateur. Le problème qui se pose, à ce niveau, est que nous sommes devant des bases de données

existantes et que nous ne devons pas toucher à l’existant. Ceci nous amène à fabriquer des modèles

99

de document à partir des schémas existants afin de contrôler les informations insérées par les

utilisateurs. Chaque document saisi ou consulté sera conforme à un modèle (DTD) afin de mieux

contrôler les données saisies dans les documents. L’utilisateur saisit donc des documents XML

conformes à des DTDs [JFB 01]. Ces DTDs sont générés automatiquement à partir des schémas des

bases de données.

Il faut noter que notre système est utilisé par différents utilisateurs leur permettant ainsi de

rédiger et de consulter différents types de documents. L’utilisateur serait perdu dans le nombre de

balises disponibles si nous ne lui fournissons qu’un seul type de document qui permettrait de remplir

toute donnée prévue dans la base. Nous proposons donc de rédiger autant de types de documents

qu’il y a de thèmes pour les utilisateurs. Pour ce faire nous générons différentes DTDs selon le type

de document à saisir. Ce type de document se traduira ensuite par la relation racine choisie par

l’utilisateur-concepteur qui devient ensuite l’élément racine de la DTD. La génération automatique

des DTDs est présentée dans la partie 3.3.

3.2.1 Saisie des données avec DRUID

Le système DRUID permet aux utilisateurs de saisir des documents conformes à des DTDs,

et sous forme de paragraphes (document faiblement structuré), où chaque paragraphe est délimité par

une balise. Une fois le document saisi, l’analyseur de DRUID balise chaque données unitaire

présente dans les paragraphes pour donner naissance à un document structuré (document fortement

structuré). Ce document permet d’alimenter ensuite la base de données.

Figure 29 Les étapes suivies par un document avant la saisie de ses informations dans une base de données.

Les documents fortement structurés et faiblement structurés sont conformes à des DTDs ; le

premier est conforme à une DTD complète appelée DTD SSD (Strongly Structured Document), alors

que le deuxième est une DTD moins riche appelée DTD WSD (Weakly Structured Document) et qui

est déduite de la première DTD.

Base dedonnées

Document SSD

DTD SSD

DRUID

Document WSD

DTD WSD

Utilisateur

100

Au début de la saisie l’utilisateur choisit un type de document. Ce type de document et le

groupe auquel appartient l’utilisateur, permettent de déduire la DTD du document. Une fois la saisie

terminée, chaque paragraphe du document fera l’objet d’une analyse. Le résultat de l’analyse est

également un document XML contenant le texte saisi initialement, mais où les balises délimitent

chaque donnée des paragraphes insérés par l’utilisateur. Le document résultat est appelé document

fortement structuré. Les balises du document résultant sont insérées par l’analyseur et son contenu

alimentera ensuite les SGBD.

<?xml version='1.0' encoding='ISO-8859-1' ?> <!ELEMENT Rencontre (Lieu, dateheure, nommed, nompatient, Symptome*, Prescription+, Diagnostic?)> <!ATTLIST Rencontre Norenc #REQUIRED Nomedecin #REQUIRED Nopatient #REQUIRED> <!ELEMENT Lieu (#PCDATA)> <!ELEMENT dateheure (#PCDATA)> <!ELEMENT nommed(#PCDATA)> <!ELEMENT nompatient (#PCDATA)> <!ELEMENT Symptome (Libellé)> <!ATTLIST Symptome Codesymptome REQUIRED> <!ELEMENT Libellé (#PCDATA)> <!ELEMENT Prescription (qte?, Uqte?, Freq?, Ufreq?, nommedic Duree?, Uduree?)> <!ATTLIST Prescription Nomedic #REQUIRED> <!ELEMENT nommedic (#PCDATA)> <!ELEMENT qte (#PCDATA)> <!ELEMENT Uqte (#PCDATA)> <!ELEMENT Freq (#PCDATA)> <!ELEMENT Ufreq (#PCDATA)> <!ELEMENT Duree (#PCDATA)> <!ELEMENT Uduree (#PCDATA)> …

<?xml version='1.0' encoding='ISO-8859-1' ?> <!ELEMENT Rencontre (Lieu, dateheure, nommed, nompatient, Symptome*, Prescription+, Diagnostic?)> <!ATTLIST Rencontre Norenc #REQUIRED Nomedecin #REQUIRED Nopatient #REQUIRED> <!ELEMENT Lieu (#PCDATA)> <!ELEMENT dateheure (#PCDATA)> <!ELEMENT nommed(#PCDATA)> <!ELEMENT nompatient (#PCDATA)> <!ELEMENT Symptome (#PCDATA)> <!ELEMENT Prescription (#PCDATA)> <!ELEMENT Diagnostic (#PCDATA)>

DRUID

DTD correspondant au DOC SSD

DTD correspondant au DOC WSD

Saisi d’un document WSD

Figure 30 : Processus de saisie des informations avec le système

3.2.2 Consultation des données avec DRUID

Nous connectons à chaque base de données existante le système DRUID. Ce dernier présente

aux utilisateurs locaux une interface graphique leur permettant de saisir leurs informations sous

forme de documents faiblement structurés. DRUID est également composé d’une base

documentaire qui assure la traçabilité des documents entrant dans le système.

101

BD1 BD 2 BD3

MEDIATEUR

Tuples

---------URL-------

FILTRE

DTD-Utilisaeur

Tuples

---------URL-------

FILTRE

DTD-Utilisaeur

Figure 31 : Processus de consultation des données avec DRUID

Les utilisateurs voulant interroger les bases de données hétérogènes, formulent leurs requêtes

sur le schéma médiateur. Ces requêtes sont envoyées ensuite au médiateur qui les décompose afin

d’en extraire les noms des relations et attributs interrogés. Une fois ces derniers récupérés, nous nous

connectons au document XML contenant les différentes correspondances et nous effectuons la

traduction afin d’envoyer les requêtes sur les différentes bases de données pour être exécutées. Le

médiateur envoie chaque requête à chaque base de données. Chacune récupère les tuples et les liens

vers les documents sources des données ce qui permet aux utilisateurs de consulter les documents

rédigés qui ont alimenté la base de données. Nous recherchons ensuite, pour chaque profil utilisateur

et pour chaque document trouvé, la DTD de consultation lui correspondant. Une fois la DTD

chargée, DRUID modifie le document à envoyer en le rendant conforme à la DTD sélectionnée,

permettant ainsi de protéger les informations confidentielles. Le même traitement est refait dans

chaque base de données. Cette étape terminée, DRUID envoie les tuples ainsi que les documents au

médiateur. Ce dernier regroupe les tuples dans un document XML contenant les URLs des

documents sources, et le présente à l’utilisateur. Dans la partie 3.3.3 nous montrons comment les

documents sont filtrés et de quelle manière les informations sont protégées

102

3.3 Génération des DTDs

Comme présenter ci-dessus, chaque document saisi, est conforme à la DTD WSD. Une fois le

document saisi, DRUID le transforme en document fortement structuré afin de faciliter la phase de

remplissage de la base de données. Le document fortement structuré, quant à lui, est conforme à la

DTD SSD qui est directement déduite du modèle de la base de données. Dans notre problématique,

les bases de données existent déjà et nous ne pouvons effectuer aucune modification. Ainsi le

contenu des documents saisis ou consultés doit être conforme au contenu des bases de données. Dans

ce but, les DTDs des documents lus ou rédigés doivent être une image du schéma de la base de

données sous-jacente, et leur création peut être automatisée.

Afin d’exploiter au mieux le système DRUID nous avons proposé une solution permettant de

générer les DTDs à partir des schémas des bases de données existantes [LAF 03]. Nous générons en

premier les DTD SSD avant de les simplifier pour créer les DTD WSD. Une fois les deux types de

DTD générés, nous récupérons les droits et privilèges des utilisateurs afin de modifier les DTD

créées ci-dessus pour chaque type d’utilisateur.

Figure 32 : Les étapes de génération des DTDs

3.3.1 Génération des DTD SSD

3.3.1.1 Présentation des DTDs SSD

La génération de DTDs à partir de schémas de bases de données a déjà fait l’objet de

différentes études. Cependant, le contexte particulier dans lequel nous voulons les utiliser fait que

certaines adaptations doivent être apportées :

Les DTDs ne concernent pas l’intégralité du schéma de la base de données, mais sont

restreintes, pour chaque type de document : La thématique choisie par l’utilisateur-concepteur

constitue le sujet central du document. Elle se traduit par le choix d’une relation dans le schéma de la

base, qui sera la racine de la DTD. Seules les relations reliées à celle-ci pourront être présentes dans

la DTD. On peut parler d’une limite « en largeur » dans le schéma de la base de données.

GenDTD modification

DTD SSD

DTD WSD

103

Une limite doit également être mise en « profondeur » : Le développement des liens de référence

permettant la navigation de relation en relation ne doit pas être complet. En effet, dans le cadre d’une

prescription par exemple, les liens de référence permettent d’atteindre la relation « médicament » qui

elle-même est liée à la relation « Laboratoire_Pharmaceutique» contenant certainement des

informations administratives sur les laboratoires. Or dans la DTD de saisie de prescriptions, il est

inutile d’insérer des tags pour saisir des informations sur les laboratoires. Le développement de liens

de référence sera limité par l’utilisateur-concepteur. Par défaut, nous limiterons à un niveau 1 le

niveau de développement.

Le choix de présentation de certains attributs de la base sous forme d’éléments ou de sous-

éléments XML. Ce choix a des implications sur le fonctionnement de l’interface graphique de

saisie et de consultation des documents : En effet, les colonnes de la base de données qui

représentent des identifiants ou des références sur d’autres relations sont habituellement insérées

dans les DTDs de la même façon que les autres attributs. Cependant, dans une optique de saisie

d’informations, et comme cela est fait dans les formulaires, les identifiants ne sont pas présentés à

l’utilisateur. Ils sont cachés, et seuls les libellés correspondants sont affichés. Pour les mêmes raisons

de clarté et de simplicité, nous voulons que les identifiants n’apparaissent pas à l’utilisateur final. Le

standard HTML a déjà rencontré ce problème et l’a résolu avec la règle suivante : ne pas présenter

aux utilisateurs le contenu des attributs. Par exemple, le tag <A> a un contenu affiché et un attribut

interne HREF qui n’est pas présenté à l’utilisateur, mais utilisé par l’application sous-jacente. Nous

avons repris le même principe dans notre algorithme de génération de DTD : il génère pour les

identifiants, des attributs XML plutôt que des éléments. Un attribut de la relation référencée est

utilisé comme libellé et il est défini par l’utilisateur-concepteur.

Exemple : La Figure 34 présente une DTD SSD générée à partir du schéma de base de données de la

Figure 33. Le thème du document est « Prescription ». Nous avons limité le développement en

profondeur au niveau 1 (seul le N° de médicament et le nom sont présents dans le document). Le

Numéro de médicament est présent sous forme d’un attribut.

MEDECIN(Nomedecin, Noservice, Nommed, Prenom, Telephone) PATIENT(Nopatient, Noss, Sexe, Nompat, Prenom, Adresse, Telephone, Datenaissance) RENCONTRE(Norenc, Dateheure, Lieu, Codediag, Nomedecin , Nopatient) PRESCRIPTION(Norenc, Nomedic, Qte, Uqte, Freq, Ufreq, Duree, Uduree ) ANTECEDENT(Nopatient, Codemaladie, Lienparente, Dateantecedent) SERVICE(Noservice, Specialite) SYMPTOME(Norenc, Codesymptome)

Figure 33 Exemple de schéma de base de données

104

<?xml version='1.0' encoding='ISO-8859-1' ?> <!ELEMENT Prescription (qte?, uqte?, nomMedic, freq?, ufreq?, duree?, uduree?)> <!ATTLIST Prescription Nomedic #REQUIRED> <!ELEMENT qte (#PCDATA)> <!ELEMENT uqte (#PCDATA)> <!ELEMENT nomMedic (#PCDATA)> <!ELEMENT freq (#PCDATA)> <!ELEMENT ufreq (#PCDATA)> <!ELEMENT duree (#PCDATA)> <!ELEMENT uduree (#PCDATA)>

Figure 34 Exemple d’une DTD SSD

3.3.1.2 Le processus de génération des DTDs SSD

DTD Relation racine

Liste des relations et attributs

Récupération relations

BD

GestBD

Figure 35 : Processus de génération des DTDs SSD

Le processus de génération de DTD commence par la connexion à la base de données et la

récupération de la liste des relations. Une fois les noms des relations récupérés, l’utilisateur-

concepteur choisit une relation qui représente le thème du document pour lequel la DTD est générée.

Cette relation devient ensuite l’élément racine de notre DTD.

Relation

BD :

Elément XML

DTD :

105

Dans la deuxième étape nous traitons les attributs composant la relation racine, où les

attributs qui ne sont ni clé primaire ni clés étrangères deviennent des éléments PCDATA. Les Clés

primaires, quant à elles, deviennent des attributs de l’élément XML

Les clés étrangères qui n’appartiennent pas aux clés primaires subissent un traitement

particulier. Pour chaque attribut de la clé étrangère nous recherchons le nom de la relation Rel où a

été importée cette clé. Une fois la relation Rel trouvée, nous insérons dans l’élément racine un

élément XML ayant une cardinalité de 1 ou de 0 selon si la clé étrangère peut être nulle ou non.

Après avoir inséré l’élément, nous générons un élément XML dans la DTD portant le nom de la

relation Rel, cet élément subit le même traitement que l’élément racine.

Les clés étrangères faisant partie de la clé primaire, sont remplacées par le nom de leur

relation dans le cas où le développement n’serait pas de niveau 1, et la relation devient alors élément

XML. Cet élément subira ensuite le même traitement que l’élément racine. Dans le cas contraire,

c'est-à-dire où le développement est de niveau 1, la relation devient un élément PCDATA.

Une fois la relation traitée, nous nous intéressons aux relations référencées par la relation

Racine. Dans le monde du document, cela doit être traduit comme un ensemble de sous éléments. Par

exemple, il y a une colonne serviceId dans la relation Docteur, qui référence le service dans lequel

travaille le médecin. Écrire un document au sujet d'un service peut nécessiter l’ajout de la liste des

médecins qui travaillent dans ce service. Nous recherchons, alors, les relations dans lesquelles la clé

principale de la relation racine est référencée, et nous ajoutons un sous élément pour chaque relation

Attribut

BD :

Elément PCDATA

DTD :

Clé primaire

BD :

Attlist

DTD :

+Dév =1 Dév >1

Clé étrangère (ID)

BD :

Nom Rel (PCDATA )

DTD :

Elément XML Elément PCDATA

Clé étrangère

BD :

Elément PCDATA (0/1) +

Elément XML Nom Rel

DTD :

106

trouvée. La cardinalité de ces éléments est * ou +. Les nouveaux sous éléments subissent également

le même traitement.

3.3.1.3 L’algorithme de génération des DTD SSD:

Génération DTD SSD

DEBUT

{Récupérer la structure de la base de données}

Structure=Recup_Structure(BD) ;

{Afficher la liste des relations de BD}

Affichage (Structure.liste_Relation) ;

{L’utilisateur-concepteur choisi la relation racine}

R-Traite =Choix-Utilisateur() ;

{Création de la DTD avec le nom de la BD}

CreerDTD(DTD.BD) ;

L=0;

ListR-Traite =ListR-Traite + {R-Traite};

Tant que (L < List.size()) faire

Debut

nomRelation-Traite =R-Traite;

{Création dans la DTD DTD.BD, un élément XML portant le nom de la relation Racine}

Cree_ElementXML(nomRelation-Traite, DTD.BD) ;

{Traitement des attributs non identifiant}

{Extraire la liste des attributs non identifiant}

List_Attribut=Recup_.List_non_clé(R) ;

I=0 ;

Tant que (I < List_Attribut.size()) faire

Debut

{Récupérer un attribut de la liste}

Attribut= List_Attribut.get(I) ;

Nom_Att=Attribut.nom ;

References

BD :

Element XML (*/+)

DTD :

107

{Crée un élément nœud fils dans l’élément « nomRelation-Traite » ayant comme nom

« Nom_Att »}

Creer_Fils_ElementXML(nomRelation-Traite, Nom_Att) ;

{L’élément « Nom_Att » devient un PCDATA}

Créer_PCDATA(Nom_Att) ;

I=I+1 ;

Fin

{Traitement des attributs de la clé primaire}

{Extraire la liste des attributs composant la clé primaire}

List_Clep=Recup_.List_CLEP(R) ;

I=0 ;

Tant que (I<= List_Clep.size()) faire

Debut

{Récupérer un attribut de la liste}

Clep = List_Clep.get(I) ;

Nom_Att=Clep.nom ;

{Crée un attribut dans l’élément « nomRelation-Traite » ayant comme nom « Nom_Att »}

Creer_Attribut_ElementXML(nomRelation-Traite, Nom_Att) ;

I=I+1 ;

Fin

{Traitement des clés étrangères de la clé primaire}

{Extraire la liste des clés étrangères inclues dans la clé primaire}

List_ClePEtrang=Recup_.List_CLEP_CLE(R) ;

I=0 ;

Tant que (I<= List_ClePEtrang.size()) faire

Debut

{Récupérer un attribut de la liste}

Clep = List_ClePEtrang.get(I) ;

{Récupérer le nom de la relation d’où a été importé la clé }

NomRel=Recup_nom_Rel(CleP) ;

{Un nouveau sous élément est créé dans l’élément « nomRelation-Traite », portant le nom de

la relation référencée}.

Creer_Fils_ElementXML(nomRelation-Traite, NomRel) ;

{Demander à l’utilisateur, la profondeur du développement}

108

Dev = Lire_niveau_Dev(Utilisateur) ;

{Si le développement est à 1, L’élément « NomRel » devient un PCDATA, Sinon la

relation référencée sera, elle aussi, traitée afin de définir sa composition}

Si Dev=1 alors Créer_PCDATA(NomRel)

Sinon ListR-Traite =ListR-Traite + {NomRel};

I=I+1 ;

Fin

{Traitement des References}

{Rechercher la liste des relations vers lesquelles la clé primaire a été exportée}

List_Rel=Recherche_References(List_Clep);

I=0 ;

Tant que (I< List_Rel.size()) faire

Debut

NomR= List_Rel.get(I);

{Ajouter à notre élément un élément portant le nom de la relation où a été exportée la clé primaire}

Creer_Fils_ElementXML(nomRelation-Traite, NomR) ;

{Cet élément aura comme cardinalité "*" s’il peut être nul, sinon "+"}

Si (List_Clep.isNull) Alors Cardinalite(NomR) =’*’

Sinon Cardinalite(NomR) =’+’;

{La relation (NomR) est ensuite traitée afin de définir sa composition}

ListR-Traite =ListR-Traite + {NomR}

I=I+1;

Fin

{Traitement des clés étrangères n’appartenant pas à la clé primaire}

List_CleE=Recup_Cle_Etrang(nomRelation-Traite) ;

I=0 ;

Tant que (I< List_CleE.size()) faire

Debut

CleE= List_CleE.get(I);

{Rechercher la relation d’où a été importé la clé}

Nom_Rel_Ref= RecupRel_Refrences(CleE) ;

{Ajouter à notre élément un élément portant le nom de la relation où a été exportée la clé primaire}

Creer_Fils_ElementXML(nomRelation-Traite, Nom_Rel_Ref) ;

{Cet élément aura comme cardinalité " ?" s’il peut être nul, sinon "1"}

109

Si (CleE.isNull) alors Cardinalite(Nom_Rel_Ref) =’?’

I=I+1;

Fin

L=L+1 ;

R-Traite=ListR-Traite.get(L) ;

Fin

FIN

3.3.2 Génération des DTD WSD

3.3.2.1 Présentation des DTDs WSD

La DTD WSD n’est pas générée à partir de la base de données mais déduite de la DTD SSD

[LAF 01b]. Elle est une simplification de la DTD SSD. De ce fait, elle contient peu de balises.

Chaque élément de cette DTD contient un attribut de type PCDATA (c’est le paragraphe saisi par

l’utilisateur). Les documents WSD sont rédigés par les utilisateurs et au cours de cette rédaction, le

document n’est pas complètement conforme à la DTD WSD actuelle. En effet, l’utilisateur peut

choisir de baliser ses paragraphes quand il veut dans le processus de rédaction. Pour que le document

reste conforme à la DTD WSD, nous avons choisi de définir une balise "parag" qui est

automatiquement affectée à tout paragraphe qui n’a pas encore été balisé par l’utilisateur.

Un autre avantage de DRUID est qu’il permet à l’utilisateur de saisir les informations dans

n’importe quel ordre, par exemple le médecin peut recommencer à rédiger le paragraphe problème

avant le paragraphe antécédent ou vice-versa, ce qui nécessite une DTD non ordonnée.

Contrairement à SGML qui permet d’avoir des DTDs non ordonnées, XML ne le permet pas

facilement. Modifier notre DTD de telle façon qu’un document non ordonné puisse lui être conforme

est faisable mais très complexe.

La figure suivante présente un exemple de transformation de DTD, où dans la première partie

nous avons une DTD ordonnée qui ne valide pas un document non ordonné. Cette même DTD a été

modifiée dans la deuxième partie pour qu’un document contenant des paragraphes non ordonnés lui

soit valide. Cet exemple simple montre déjà la complexité du passage d’une DTD ordonnée à une

DTD non ordonnée. Nous proposons, de ce fait, de réordonner le document écrit par l’utilisateur

avant de le passer à l’analyseur, pour ce faire les paragraphes du document seront ordonnés

automatiquement afin qu’il soit conforme à la DTD WSD. Au cours de la rédaction du

document, la validation vis-à-vis de la DTD n’est pas une validation classique : elle vérifie

110

uniquement que les tags utilisés existent sans se préoccuper de leur ordre ni de leur composition (en

effet nous n’avons qu’un seul niveau de tag).

< !Element E(A+, B*, C*) < !Element E ((A, (B|C)*) | ((B|C)*, A, (B|C)*)| ((B|C)*, A))+ >

DTD pour un document ordonné : La même DTD pour un document non ordonné :

Figure 36 : DTD ordonnée et non ordonnée

La Figure 37 quant à elle, présente un exemple de DTD WSD créée pour valider les

documents de prescriptions rédigés par un médecin. Nous constatons bien que cette DTD est

faiblement structurée : l’utilisateur donne très peu d’informations structurelles et saisit des

paragraphes en texte libre.

<?xml version='1.0' encoding='ISO-8859-1' ?> <!ELEMENT Prescription (qte?, uqte?, nomMedic, freq?, ufreq?, duree?, uduree?)> <!ATTLIST Prescription Nomedic #REQUIRED> <!ELEMENT qte(#PCDATA)> <!ELEMENT uqte (#PCDATA)> <!ELEMENT nomMedic (#PCDATA)> <!ELEMENT freq (#PCDATA)> <!ELEMENT ufreq (#PCDATA)> <!ELEMENT duree (#PCDATA)> <!ELEMENT uduree (#PCDATA)>

<?xml version='1.0' encoding='ISO-8859-1' ?>

<!ELEMENT Prescription (#PCDATA)>

<!ELEMENT parag (#PCDATA)>

Figure 37 DTD WSD pour la saisie par un médecin d’un document prescription.

3.3.2.2 Le processus de génération des DTDs WSD

La création des DTDs WSD se fait en deux étapes. La première consiste à écrémer tous les

niveaux n+1, c’est-à-dire à enlever à chaque élément tous les éléments qui le composent [LAF 03].

Par exemple, si l’élément à traiter est Prescription (date, Medicament, qte, Uniteqte, Duree,

UniteDuree) alors l’élément devient < !Element Prescription( PCDATA)>. La deuxième étape, quant

à elle, permet de lui rajouter un élément parag permettant de gérer les paragraphes non encore

balisés.

Figure 38 : Processus de transformation d'une DTD SSD en une DTD WSD

Element EL(A, B, C, D)

DTD DCD :

Element EL(PCDATA) Element parag (PCDATA)

DTD WSD:

111

La

Figure 38 montre le processus de transformation de la DTD SSD en DTD WSD. Chaque

élément complexe de la DTD SSD devient un élément PCDATA dans la DTD WSD. Cette DTD

contiendra aussi un élément <Parag> de type PCDATA qui concerne les paragraphes en cours de

saisie.

3.3.2.3 L’algorithme de génération de la DTD WSD

DEBUT

{L’utilisateur-concepteur choisit une DTD SSD}

DocDTD=ChoixUtilisateur-DTD() ;

{Extraite la liste des élément de la DTD}

List_Elem=Recuplist_Element(DocDTD) ;

I=0 ;

Tant que (I<List_Elem.size())

Debut

{Extraire l’élément en phase de traitement}

Elem=List_Elem.Extraite(I) ;

{Enlèver tous les éléments qui composent l’élément « Elem »}

Elem=Ecremer_Elem(Elem) ;

{Ajouter à l’élément « Elem », un élément « Parag » de type PCDATA}

Inser-Element(Elem, Parag);

Créer_PCDATA(Parag);

Cardinalite(Parag) = ‘*’;

I=I+1 ;

Fin

FIN

3.3.3 Filtrage des DTDs

3.3.3.1 Problématique

112

Les droits de modification sur la base ont des implications sur les informations qui peuvent

être saisies par les différents types d’utilisateurs. Les documents peuvent ensuite être consultés par

interrogation de la base car l’utilisation de DRUID nous permet de les conserver et de les relier aux

données. Cette consultation peut être faite par divers utilisateurs, qu’ils aient été les rédacteurs des

documents ou non. Il est important de prendre en compte les droits d’accès aux données à la fois

dans la rédaction et dans la présentation des documents. Nous avons choisi de gérer cette

problématique par une différentiation des DTDs de création et de lecture, selon l’utilisateur, ainsi que

par le filtrage des documents existants en fonction des DTD de consultation.

3.3.3.2 Proposition

Nous proposons de définir des DTDs différentes pour les documents en lecture et en écriture

ainsi que pour chaque groupe d’utilisateurs [BOU 04]. Les DTDs sont filtrées, à partir des droits

d’accès des utilisateurs, à la base de données sous-jacente. Pour cela, la DTD de base présentée dans

la section précédente doit être aménagée : les éléments interdits aux utilisateurs seront enlevés de la

DTD de base pour former une DTD filtrée correspondante et les documents saisis ou consultés par

ces utilisateurs sont rendus conformes aux DTDs filtrées.

<?xml version='1.0' encoding='ISO-8859-1' ?> <!ELEMENT Rencontre (Lieu, dateheure, nommed, nompatient)> <!ATTLIST Rencontre Norenc #REQUIRED Nomedecin #REQUIRED Nopatient #REQUIRED> <!ELEMENT Lieu (#PCDATA)> <!ELEMENT dateheure (#PCDATA)> <!ELEMENT nommed(#PCDATA)> <!ELEMENT nompatient (#PCDATA)>

Droits du groupe d’utilisateurs

FiltreDTD

DTD filtrées

DTD globale

<?xml version='1.0' encoding='ISO-8859-1' ?> <!ELEMENT Rencontre (Lieu, dateheure, nommed, nompatient)> <!ATTLIST Rencontre Norenc #REQUIRED Nomedecin #REQUIRED Nopatient #REQUIRED> <!ELEMENT Lieu (#PCDATA)> <!ELEMENT dateheure (#PCDATA)> <!ELEMENT nommed(#PCDATA)> <!ELEMENT nompatient (#PCDATA)>

<?xml version='1.0' encoding='ISO-8859-1' ?> <!ELEMENT Rencontre (Lieu, dateheure, nommed, nompatient, Symptome*, Prescription+, Diagnostic?)> <!ATTLIST Rencontre Norenc #REQUIRED Nomedecin #REQUIRED Nopatient #REQUIRED> <!ELEMENT Lieu (#PCDATA)> <!ELEMENT dateheure (#PCDATA)> <!ELEMENT nommed(#PCDATA)> <!ELEMENT nompatient (#PCDATA)> <!ELEMENT Symptome (Libellé)> <!ATTLIST Symptome Codesymptome REQUIRED> <!ELEMENT Libellé (#PCDATA)> <!ELEMENT Prescription (qte?, Uqte?, Freq?, Ufreq?, nommedic Duree?, Uduree?)> <!ATTLIST Prescription Nomedic #REQUIRED> <!ELEMENT nommedic (#PCDATA)> <!ELEMENT qte (#PCDATA)> <!ELEMENT Uqte (#PCDATA)> <!ELEMENT Freq (#PCDATA)> <!ELEMENT Ufreq (#PCDATA)> <!ELEMENT Duree (#PCDATA)> <!ELEMENT Uduree (#PCDATA)> <!ELEMENT Diagnostic (Libelle)> <!ATTLIST Diagnostic Codemaladie #REQUIRED> <!ELEMENT Libelle (#PCDATA)> <!ELEMENT Antecedent (lienparente?, dateantecedent)> <!ATTLIST Antecedent Codemaladie #REQUIRED> <!ELEMENT lienparente (#PCDATA)> <!ELEMENT dateantecedent (#PCDATA)> <!ELEMENT codesymptome (#PCDATA)> <!ELEMENT codemaladie (#PCDATA)>

GestDTD

Figure 39 : Processus de filtrage des DTDs

113

A chaque saisie d’un document, la DTD filtrée correspondant au groupe auquel appartient

l’utilisateur est fournie (les balises défendues à l’utilisateur sont enlevées, empêchant ce dernier de

saisir les informations qui ne lui sont pas permises). Dans le cas d’une consultation ou d’un ajout de

données, le document demandé est filtré pour qu’il devienne conforme à la DTD filtrée

correspondante (chaque élément correspondant à l’information interdite à l’utilisateur est enlevé).

3.3.3.3 Algorithme de filtrage des DTDs

DEBUT

{Demander à l'utilisateur concepteur de fournir le nom du groupe pour lequel la DTD va être

filtrée}

NomGroupe = ChoixUtilisateur() ;

{L’utilisateur choisit la DTD à filtrer}

Nom_DTD_Traiter =ChoixUtilisateur() ;

{L'utilisateur choisi le type de la DTD à filtrer (écriture ou lecture)}

TypeDTD = ChoixUtilisateur() ;

{Récupération de la DTD à filtrer}

DTD_Traiter =Récup_DTD(Nom_DTD_Traiter) ;

{Recherche des droits de la base de données}

DroitBD=RecupDroit(NomGroupe, BD) ;

{Extraire la liste des éléments interdits}

List_El_Interdit = DRoitBD.interdit ;

{création d’une nouvelle DTD}

NewDTD(DTD_Filtre) ;

I=0 ;

{Parcourir la DTD et enlever les éléments interdits}

Tant que (I< DTD_Traiter.List_Element.size())

Debut

Element_filtrer = DTD_Traiter.List_Element.get(I) ;

{Vérifier si l’élément est interdit ou non}

Si non (Appartient (Element.nom, List_El_Interdit) alors

Debut

{Créer un l’élément portant le nom « Element.nom » dans la DTD filtrée}

114

Creat_Element(DTD_Filtre, Element_filtrer.nom);

{Vérifier si ses éléments fils sont interdit ou non}

J=0 ;

Tant que (J < Element_filtrer.Fils.size())

Debut

Element_fils = Element_filtrer.Fils.get(J) ;

{Vérifier si l’élément est interdit ou non}

Si (Non (Appartient (Element_fils.nom, List_El_Interdit)) alors

Debut

{Créer un l’élément « Element.fils.nom » dans l’élément

Element_filtrer}

Creat_Element(DTD_Filtre, Element.nom, Element_filtrer.nom);

Fin

J=J+1;

Fin

{Vérification des ses attributs}

J=0 ;

Tant que (J < Element_filtrer.Attribut.size())

Debut

Attribut_filtrer = Element_filtrer.Attribut.get(J) ;

{Vérifier si l’attribut est interdit ou non}

Si (Non (Appartient (Attribut_filtrer.nom, List_El_Interdit)) alors

Debut

{Créer un Attribut « Attribut_filtrer.nom » dans l’élément

Element_filtrer}

Creat_Attribut(DTD_Filtre, Element.nom, Attribut_filtrer.nom);

Fin

J=J+1;

Fin

Fin

{Passer à un autre élément}

I=I+1 ;

Fin

115

FIN

3.3.4 Modification du document

3.3.4.1 Filtrage d’un document en consultation

Comme présenté ci-dessus, aux réponses des utilisateurs sont rattachés les URLs des

documents sources qui ont alimenté les bases de données. Une fois que l’utilisateur choisit un

document, le processus suivant est exécuté :

1. L’URL du document est envoyée au module FiltreDoc,

2. Le module GestDocXML envoie le document à consulter, à FiltreDoc.

3. Le nom du profil utilisateur est envoyé au module GestDTD,

4. GestDTD récupère la DTD de consultation du document demandé, propre à l’utilisateur,

5. FiltreDoc crée un nouveau document DocNew,

6. FiltreDoc vérifie si la racine du document existe dans la DTD de l’utilisateur. Si cette

dernière existe, elle est recopiée dans le nouveau document,

7. Une fois l’élément racine créé, ses nœuds sont traités. Pour chaque nœud du document qui

n’a pas été traité, nous récupérons ses fils et nous vérifions s’ils existent dans la DTD ou non.

Dans le cas où ils apparaîtraient dans la DTD, ils seront recopiés dans le nouveau document.

Dans le cas contraire, nous ne traiterons pas ses fils,

8. Refaire 7, pour tous les nœuds ainsi que pour leur fils,

9. Envoi du document à l’interface utilisateur,

10. Affichage du document.

En ce qui concerne les documents en saisie, la DTD de l’utilisateur est récupérée et le

nouveau document ne contiendra que les balises existant dans la DTD.

116

Document à consulter Droits de l’utilisateur

DTD consultation

DTD consultation

GestDTD

DTDs BD

GestBD GestDocXML

DocXML

FiltreDoc

Interface Utilisateur

Récupération des droits Récupération du document

Document filtré

Figure 40 : Filtrage d'un document en consultation

3.3.4.2 Algorithme de filtrage

{Cette procédure est appelée avec les paramètres, nom de l’utilisateur, nom du document à consulter

ainsi que la valeur du type d’utilisation (L)}

Filtre Document (var NomUtilisateur, NomDoc_Consulté String, ‘L’ )

DEBUT

NomGroupe= Group_Utilisateur(NomUtilisateur) ;

{Rechercher la DTD filtrée de l’utilisateur, rattachée au document à consulter}

DTD_Filtre = RecupDTD(NomGroupe, ‘L’, NomDoc) ;

{Rechercher l’Url du document à consulter}

URL = URL(NomDoc) ;

{Créer un nouveau Document}

Doc_Filtre = New_Doc() ;

{Traitement de la racine}

{Vérifier, en premier, si la racine du document existe dans la DTD de l’utilisateur}

117

Si (Existe_Racine (DTD_Filtre)) Alors

Debut

{Prendre la racine du document à filtrer}

Element = Recup_Racine(URL) ;

{Insérer la racine dans le nouveau document}

Insert_Racine(Element, Doc_Filtre) ;

{Traitement des Nœuds}

I=0 ;

{Parcourir tous les nœuds du document à consulter}

Tant que (I < List_Noeud(URL).size()) Faire

Debut

{Prendre le nœud}

Noeud = List_Noeud(URL).get(I) ;

{Vérifier si le noeud existe dans la DTD de l’utilisateur avant de le recopier dans le

document}

Si (Existe_Noeud(DTD_Filtre, Noeud)) Alors

Insert_Element (Noeud, Doc_Filtre) ;

{Traitement des Feuilles du Nœud}

J=0 ;

Tant que (J < List_Feuille(URL, Noeud).size()) Faire

Debut

{Prendre une feuille}

Feuille = List_Feuille(URL, Noeud).get(J) ;

{Vérifier si la feuille existe dans la DTD de l’utilisateur avant de la recopier dans le

document}

Si (Existe_Feuille(DTD_Filtre, Nœud, Feuille)) Alors

Insert_Element (Nœud, Feuille, Doc_Filtre) ;

J=J+1 ;

Fin

I=I+1 ;

Fin

118

Fin

Fin

Close_Doc(Doc_Filtre) ;

Afficher_Doc(Doc_Filtre) ;

FIN

3.4 Conclusion

L’approche proposée dans cette section permet de remédier à quelques limites des différentes

approches existantes pour contrôler l’accès aux documents XML. La plupart des méthodes existantes

concernent uniquement les documents en lecture et non en écriture alors que notre approche prend en

compte les deux modes. Un autre inconvénient des systèmes existants concerne les politiques de

sécurité qui doivent être écrites par les administrateurs. Contrairement à notre proposition, où les

politiques de sécurité sont déduites automatiquement à partir des droits sur la base de données.

Différents utilisateurs manipulent différents documents contenant des informations

confidentielles. Ces données peuvent être défendues à des utilisateurs et permises à d’autres.

Durant notre recherche bibliographique (voir chapitre II) nous avons recensé deux types de

filtrages ; la première solution consiste à appliquer des règles de transformation [GAB 01a] [GAB

01b] sur le document qui va être consulté. La deuxième (dont notre proposition) est de poser des

filtres sur les DTDs, en utilisant les droits d’accès décrits dans la base, ce qui aura pour conséquence

la création de DTD spécifiques à chaque groupe d’utilisateurs et à chaque type d’action (écriture,

lecture). Notre choix s’est porté sur la deuxième solution car elle évite d’avoir des politiques de

sécurité pour chaque document. Une deuxième raison est qu’elle permet un filtrage automatique des

DTDs, contrairement aux différentes approches [GAB 02] [GAB 01a] [GAB 01b] présentées dans le

chapitre Etat de l’art, où l’écriture des règles est manuelle. Nous nous sommes limités à deux cas

(lecture, écriture) car dans notre domaine d’application (le médical) il est interdit de modifier les

données existantes : une modification de prescription n’entraîne pas la suppression de l’ancienne

mais ajoute de nouvelles informations. Notre proposition peut cependant être également utilisée dans

le cas des modifications

119

4 Conclusion du chapitre

Afin de valider la proposition de génération de schéma médiateur, nous avons conçu un

médiateur permettant à un utilisateur de formuler des requêtes sur une vue unifiée et de récupérer un

résultat provenant de leur exécution sur un ensemble de bases de données hétérogènes. Nous avons

aussi présenté une solution de protection de données qui repose sur l’utilisation de modèles de

document. En effet nos bases de données sont manipulées par divers utilisateurs ayant différents

droits. Nous avons proposé d’utiliser des DTDs différentes pour les documents en écriture et en

lecture. Chaque document saisi ou consulté par un utilisateur devra être conforme à une DTD. Notre

proposition est de générer automatiquement en premier une DTD globale, qui sera ensuite modifiée

selon les droits d’accès des utilisateurs.

Les documents XML que nous utilisons ont pour but de fournir une alternative à la saisie et à

la consultation de données sous forme de formulaires. L’utilisation de documents XML balisant

chaque paragraphe est un premier pas vers plus de souplesse pour l’utilisateur, et permet de ne pas

trop s’éloigner du schéma de la base de données sous-jacente.

120

Chapitre V : Prototypes 1 Introduction .................................................................................................................... 121 2 Architecture globale ....................................................................................................... 122

2.1.1 Générateur de schéma médiateur ................................................................... 123 2.1.2 Médiateur ....................................................................................................... 123 2.1.3 Contrôle de données ....................................................................................... 123 2.1.4 DRUID ........................................................................................................... 124

3 Vue unifiée ..................................................................................................................... 124 3.1 Introduction ............................................................................................................ 124 3.2 L’ontologie de structure ......................................................................................... 125 3.3 L’ontologie de valeurs............................................................................................ 127 3.4 Présentation du prototype 1 : Descripteur de bases de données............................. 129

3.4.1 Diagramme des classes du descripteur de base de données ........................... 129 3.4.2 Diagramme de séquence du processus de description ................................... 131

3.4.2.1 Description de la relation ........................................................................... 131 3.4.2.2 Description d’un attribut ............................................................................ 132

3.4.3 Exemple: Description d’une relation.............................................................. 133 3.5 Présentation du prototype 2 : Générateur de schéma médiateur ............................ 135

3.5.1 Diagramme des classes du générateur de schéma médiateur ......................... 135 3.5.2 Diagramme des séquences : Génération des relations ................................... 137 3.5.3 Diagramme de séquence : Génération des attributs ....................................... 138 3.5.4 Exemple: Génération du schéma médiateur................................................... 138

4 Médiateur ....................................................................................................................... 141 4.1 Présentation du prototype 3 : Médiateur ................................................................ 141 4.2 Fonctionnement du prototype................................................................................. 145

4.2.1 Règles des traitements des requêtes .............................................................. 145 4.2.2 Traitement de l’expression du FROM............................................................ 146 4.2.3 Traitement de l’expression du SELECT ........................................................ 147 4.2.4 Traitement de l’expression du WHERE......................................................... 147 4.2.5 Traduction des requêtes.................................................................................. 148

4.3 Diagrammes des classes du médiateur ................................................................... 149 4.4 Présentation des classes.......................................................................................... 149 4.5 Diagramme de séquences ....................................................................................... 150

5 Contrôle des données ..................................................................................................... 151 5.1 Introduction ............................................................................................................ 151 5.2 Présentation du prototype 4 : Génération et filtrage de DTDs............................... 152 5.3 Digrammes des classes........................................................................................... 153 5.4 Diagramme de séquences ....................................................................................... 155

6 Conclusion...................................................................................................................... 155

121

1 Introduction

L’objectif de notre thèse est de construire un système générique permettant d’intégrer

des bases de données hétérogènes. Nous avons proposé, dans le chapitre précédent, des

solutions permettant de résoudre cette problématique. Afin de valider ces solutions nous

avons conçu plusieurs prototypes suivant l’architecture montrée dans la Figure 41. Dans ce

chapitre, nous exposons nos différents prototypes. En premier nous abordons un prototype

permettant de décrire plusieurs bases de données implémentées sous MySQL [AQU 02] et de

générer des documents XML contenant leur description. Ces documents sont utilisés par un

deuxième prototype pour créer le schéma médiateur, employé par notre médiateur (prototype

3) pour répondre aux requêtes des utilisateurs. Le médiateur traduit des requêtes simples

formulées sur le schéma médiateur en plusieurs requêtes propres à chaque base de données,

les exécute et renvoie un résultat à l’utilisateur. Notre dernier prototype permet de générer

automatiquement des DTDs à partir d’un modèle de données. Ces DTDs sont ensuite filtrées à

partir des droits des utilisateurs sur la base de données. Comme présenté dans le chapitre

précédent, le filtrage des DTDs nous permet de contrôler l’accès aux données confidentielles

et pour ce faire chaque information saisie ou consultée doit être conforme à cette DTD.

12

2

2 A

rchi

tect

ure

glob

ale

BD

1 B

D3

DR

UID

D

RU

ID

Des

crip

teur

de

BD

D

escr

ipte

ur

de B

D

Doc

umen

t XM

L

Doc

umen

t XM

L

Gén

érat

eur

de

Sché

mas

M

ED

IAT

EU

R

Tup

les

--

----

---

UR

L--

----

-

Tup

les

--

----

---

UR

L--

----

-

1

2

4 4

Règ

les

de

map

ping

Sc

hém

a m

édia

teur

Gén

érat

eur

de

sché

ma

méd

iate

ur

Doc

umen

t gén

éré

Doc

umen

t rés

ulta

t

Mod

ule

déve

lopp

é

Ont

olog

ie

(XM

L-Sc

hem

a)

Lég

ende

:

FIL

TR

E

Doc

DT

D-U

tilis

ateu

r

Gen

DT

D

Mod

if.

DT

D W

SD

3

Gestion des DTD

DT

D S

SD

FIL

TR

E

DT

D

Fi

gure

41

: Arc

hite

ctur

e gl

obal

e du

syst

ème

2 Architecture globale

123

La Figure 41 présente l’architecture globale du système proposé pour notre problématique.

Elle se compose de trois parties principales :

1- Générateur de schéma médiateur

2- Médiateur

3- Contrôle de données

Nous utilisons le système DRUID [BAD 03a] afin d’alléger la saisie des informations (chapitre IV).

2.1.1 Générateur de schéma médiateur

Afin d’unifier les bases de données, nous présentons à l’utilisateur un schéma médiateur sur

lequel il formule sa requête. La création de cette vue est composée de deux parties, à savoir la

description de chaque base de données par le prototype « Descripteur de BD » et la génération du

schéma médiateur par le prototype « Générateur de Schéma ».

Le but des deux prototypes est de faciliter la création du schéma médiateur. Pour décrire

chaque schéma nous utilisons une ontologie de structure ainsi qu’une ontologie de valeurs. Le

processus de description rattache à chaque relation et attribut de la base de données un concept issu

de l’ontologie de structure. Une fois la description terminée, un document XML décrivant la base de

données est généré.

2.1.2 Médiateur

Le médiateur permet à l’utilisateur d’interroger nos bases de données hétérogènes et de

récupérer les résultats. Pour ce faire l’utilisateur formule sa requête, appelée requête principale, sur le

schéma médiateur, et l’envoie au médiateur, qui la traite. Le médiateur se connecte ensuite au

document contenant les règles de mapping, recherche pour chaque relation (ou attribut) l’élément

XML contenant ses correspondances ainsi que ses équivalents. Une fois terminé, les attributs et les

relations de la requête principale sont remplacés par leurs équivalents, et pour chaque base de

données une requête est créée. Ces requêtes sont ensuite distribuées sur les différentes bases de

données afin d’y être exécutées ; le résultat est alors regroupé dans un document XML et présenté à

l’utilisateur.

2.1.3 Contrôle de données

Dans notre problématique les données stockées dans nos bases de données sont manipulées

par divers utilisateurs ayant différentes autorisations. Ces données peuvent contenir des informations

confidentielles pouvant être saisies et consultées par différents types d’utilisateurs. Il est donc

124

important de préserver cette confidentialité. Pour ce faire nous proposons d’utiliser des DTDs

différentes pour les documents en écriture et en lecture. Chaque document saisi ou consulté par un

utilisateur devra être conforme à une DTD. Chaque groupe d’utilisateurs se verra attribuer ses

propres DTDs pour les documents en rédaction et d’autres pour les documents en consultation. Une

DTD globale est créée en premier pour chaque type de document. Les DTDs sont ensuite construites

automatiquement à partir de la DTD globale et des droits des groupes d’utilisateurs. Dans ce but,

nous enlevons de la DTD globale les éléments qui ne sont pas permis aux utilisateurs.

2.1.4 DRUID

La saisie reposant sur les formulaires est pénible pour les utilisateurs. Afin de rendre cette

tâche plus souple et plus facile nous avons incorporé dans notre architecture le système DRUID qui

combine la puissance des approches base de données et base documentaire et dont l’objectif est de

mettre à jour une base de données "classique" représentant un système d'information à partir de

documents saisis librement par l’utilisateur. Il propose à ce dernier de saisir ses informations dans un

document structuré où chaque paragraphe est balisé. Ce document est ensuite traité afin d’en extraire

les informations et de remplir la base de données. Il présente à l’utilisateur interrogeant une base de

données, les résultats sous formes de tuples ainsi que l’URL des documents sources, lui permettant

ainsi de consulter le document qui a alimenté la base de données. Afin de contrôler la saisie et de

faciliter l’analyse des documents ainsi que l’alimentation des bases de données, les documents saisis

doivent être conformes à des DTDs où chaque type de document a sa propre DTD selon le thème

choisi. Nous présentons dans la partie 5 comment ces DTDs sont générées automatiquement.

3 Vue unifiée

3.1 Introduction

Nous avons développé un prototype qui génère un schéma médiateur et qui est composé de

deux modules : « Descripteur de BD » et « Générateur de schéma médiateur ». Notre cas d’étude a

concerné le domaine médical. Afin de développer notre prototype nous avons utilisé langage de

programmation Java [SAU 03], et l’interface JDBC [REE 98]. Le module « Descripteur de BD »

décrit, de manière assistée, chaque base de données et ce en utilisant son dictionnaire de données et

ainsi que les ontologies. Le deuxième module génère le schéma médiateur ainsi que le document

XML contenant les règles de mapping en exploitant les documents XML construits par le

« Descripteur de BD ». La Figure 42 présente l’architecture du générateur de schéma médiateur.

125

Descripteur de BD

Ontologie De structure

Tables de valeurs

Générateur de Schémas

Document XML

Schéma médiateur

Règles de mapping

Figure 42 : Architecture du générateur de schéma médiateur

3.2 L’ontologie de structure

Pour les besoins du prototype nous avons conçu une ontologie sur la structure du dossier

médical et nous l’avons implémentée en XML-Schema [W3C 01]. Les concepts peuvent être

élémentaires ou complexes, c’est-à-dire composés d’autres concepts. Les concepts sont liés par des

liens, qui peuvent être de cinq types : généralisation, agrégation, composition, association et

synonymie. Pour notre cas d’étude, cette ontologie est composée de concepts issus de termes utilisés

dans le dossier médical ainsi que dans le milieu hospitalier tels que bilan, prescription, radiologie etc.

La Figure 43 expose une partie de notre ontologie de structure, et la Figure 44 montre son

diagramme de classes.

<?xml version="1.0" encoding="UTF-8"?> <!-- edited with XMLSPY v2004 rel. 3 U (http://www.xmlspy.com) by hamdi (lisi) --> <!--W3C Schema generated by XMLSPY v2004 rel. 3 U (http://www.xmlspy.com)--> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:simpleType name="TypeLien"> <xs:restriction base="xs:string"> <xs:enumeration value="Generalisation"/> <xs:enumeration value="Agregation"/> <xs:enumeration value="Composition"/> <xs:enumeration value="Association"/> <xs:enumeration value="synonyme"/> </xs:restriction> </xs:simpleType> <xs:element name="Lien_is_a"> <xs:complexType> <xs:sequence> <xs:element ref="personne"/> <xs:element ref="patient"/> <xs:element ref="Generalisation"/> </xs:sequence> </xs:complexType> </xs:element>

126

<xs:element name="personne"> <xs:complexType> <xs:sequence> <xs:element name="Nom" type="xs:string"/> <xs:element name="Sexe" type="xs:string"/> <xs:element name="date-naissance" type="xs:date"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Lien_synonyme"> <xs:complexType> <xs:sequence> <xs:element ref="patient"/> <xs:element ref="malade"/> <xs:element ref="synonyme"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="patient"> <xs:complexType> <xs:sequence> <xs:element name="profession" type="xs:string"/> <xs:element name="taille" type="xs:string"/> <xs:element name="poids" type="xs:string"/> </xs:sequence> <xs:attribute name="code-patient" type="xs:ID" use="required"/> </xs:complexType> </xs:element> <xs:element name="dossier-medical"> <xs:complexType> <xs:sequence> <xs:element name="Date_creation" type="xs:string"/> <xs:element ref="intervention"/> <xs:element ref="symptome"/> <xs:element ref="prescription"/> <xs:element ref="bilan"/> <xs:element ref="antecedant"/> <xs:element ref="diagnostic"/> </xs:sequence> <xs:attribute name="id-dossier" type="xs:ID" use="required"/> <xs:attribute name="code-medecin" type="xs:IDREF" use="required"/> <xs:attribute name="code-service" type="xs:IDREF" use="required"/> </xs:complexType> </xs:element>

Figure 43 : Une partie de notre ontologie de structure

127

Pays

Département

Date

Médicamentid_médicament

Numéro_rue Rue

Personnenomprenomlien-naissprofession

Date_naiss

Service

Medecincode_medgradespécialité

Radiologique Sanguin Urinaire Prescription chirurgicaleid_presChir

Arrêt de travailid_arrêt_trav

Ordonnanceid_ordonnance

Antécédent_familial Antécédent_personnel

Patientcode_patient

Interventionid_intervention

Bilan Diagnosticid_diagnostic

Prescription

Date_creationDossier_médicalid_dossier

Antécédent

Ville

Adresse

codepostal

commune

Figure 44 : Schéma des classes de l’ontologie de structure

3.3 L’ontologie de valeurs

Pour notre prototype nous avons utilisé des tables contenant des valeurs des concepts. Pour

notre cas d’étude, ces tables contiennent des listes de médicaments, des noms d’examens, de

radiologie, de diagnostics etc. Nous comptons, à l’avenir, rattacher à notre prototype une ontologie

médicale opérationnelle.

Afin de rendre la recherche des concepts durant le processus de description plus rapide, nous

faisons correspondre les deux ontologies. Pour ce faire, nous stockons les correspondances entre les

concepts de même type appartenant aux deux ontologies dans des tables. Ces dernières contiennent

les concepts des deux ontologies et font correspondre à chaque concept d’une des ontologies les

concepts appartenant à la seconde et qui peuvent lui être équivalents. Le Tableau 9 montre un

exemple de correspondances entre les concepts des deux ontologies où nous avons un lien entre le

concept Maladie de l’ontologie de valeurs et le concept Diagnostic de l’ontologie de structure. En

128

effet, le concept Diagnostic de l’ontologie de structure contenant les informations que nous pouvons

trouver dans le diagnostic d’un patient tel que le code du diagnostic ou son nom, est équivalent au

concept Maladie de l’ontologie de valeurs qui contiennent les maladies existantes. Même si ces deux

concepts sont différents dans leur contenu, ils sont tout de même reliés du fait qu’ils contiennent,

tous les deux, des informations sur les maladies.

Ce tableau nous permet donc lors de l’étude du contenu d’un attribut (processus de

description de base de données) de ne pas parcourir toute l’ontologie mais seulement les concepts

pouvant décrire l’attribut.

Ontologie\ Nom concept

Ontologie de valeurs

Ontologie de structure

Maladie Diagnostic Analyses Examens

Tableau 9 : Table reliant les concepts des deux ontologies

129

3.4 Présentation du prototype 1 : Descripteur de bases de données

3.4.1 Diagramme des classes du descripteur de base de données

OntologieBDDAttribut

Strinh nomAttributBoolean ClePBoolean CleE

Attribut()getRelRefrences()

LienOntoString nomLienString typeLienString nomConceptPereString ConceptFils

LienOnto()getConceptPere()getConceptFils()getnomLien()

RelationString nomRelationVector listeAttribut

Relation()getAttribut()

ConceptString nomConceptString typeConcept

Concept()getAttributConcept()

SchemaBDString driverString passwdString connexionResultSet resultsetString nomBDVector listeRel

SchemaBD()getDatabaseMetaData()getAttribut()getNom_BD()

RecupOntoInfo

RecupOntoInfo()afficheOnto()recupConcept()recupLienConcept()getConceptAscend()getConceptDescend()

ComparContenuTableString nomTableVector listeValeurs

RecupContenu()

DescripRelation

DescripRelation()etudContenuRel()AddRelation()

DescripAttribut

DescripAttribut()addCleP()AddCleE()AddAttribut()getConceptAtt()etudContenuAtt()

GestDocXML

GestDocXML()addAtt_Rel()AddRel_Doc()AddElem_Doc()creerELEM()creerDoc()loadDoc()

GenDescripBDString nomBDString nomFicXML

GenDescripBD()

InterfaceUtilisaeur

InterfaceUtilisateur()main()

Figure 45 : Schéma des classes du descripteur de bases de données

ComparContenuTable

Compare le contenu des relations et des attributs avec celui de l’ontologie de valeurs, afin de

connaître le type d’information qui est stockée.

Exemple : Si nous voulons étudier le contenu de l’attribut « observation » de la relation

« diagnostic ». Cette classe nous rendra les résultats sous la forme ci-dessous :

-le % de observation dans la table Symptomes est de : 50.0% -le % de observation dans la table Bilan est de : 0.0% -le % de observation dans la table Traitement est de : 0.0%

130

Les résultats de cette classe aident le concepteur dans sa validation des descriptions des bases de

données. Sa recherche sera étendue à l’avenir sur une ontologie médicale.

GestDocXML: Cette classe définit les méthodes de création et de manipulation du document XML contenant

la description d’une base de données. Elle est aussi utilisée par le prototype de génération de schéma

médiateur, où elle manipule les documents contenant la vue unifiée ainsi que les règles de mapping.

GenDescripBD

C’est la classe principale de notre prototype, elle interagit avec l’utilisateur-concepteur afin

de décrire le schéma de la base de données. Elle est composée des deux classes DescripRel et

DescripAtt.

DescripAtt & DescripRel

Ces classes décrivent chaque attribut et chaque relation de la base de données. Elles reçoivent

de la classe GenDescripBD une relation (resp. un attribut) afin de la décrire. Elles utilisent la classe

RecupOntoInfo pour trouver le concept équivalent, la classe GestDocXML pour modifier les

documents contenant les descriptions, ainsi que la classe ComparContenuTable afin de comparer le

contenu de la relation (resp. attribut) à décrire avec celui de l’ontologie de valeurs.

InterfaceUtilisateur

Présente à l’utilisateur une interface graphique lui permettant de choisir les concepts et de

valider les résultats.

Package : BDD

Ce package est une instance de la base de données, parmi ses classes principales :

- Attribut : Gère les instances des attributs des schémas des bases de données

- Relation : Gère les instances des relations des schémas des bases de données

- SchemaBD : C’est la classe principale de ce package, elle se connecte à la base de données

et récupère sa structure. Elle crée, par la suite,, les différentes instances des classes Attribut et

Relation.

Package : Ontologie

Ce package est une instance de l’ontologie, parmi ses classes principales :

- LienOnto : Contient les liens entre les différents concepts de l’ontologie. Elle est

constituée du nom du lien de son type ainsi que les noms des concepts qu’il relie.

- Concept : Gère les instances des concepts des ontologies, elle est définie par son nom et

son type.

131

- RecupOntoInfo : Cette classe définit les méthodes de manipulation de l’ontologie. Elle

permet de récupérer les concepts, leurs attributs, leurs concepts enfants (ou parents) dans le cas

de concepts complexes ainsi que les liens qui leur sont assignés.

3.4.2 Diagramme de séquence du processus de description

3.4.2.1 Description de la relation

1-2 : Le nom de la relation Rel, à décrire, est envoyé au module GenDescripRel

3 -5 : GenDescripRel fait appel à la classe Ontologie afin de rechercher les concepts qui peuvent

décrire la relation,

6-10 GenDescripRel détecte les types d’informations contenues dans la relation en comparant le

contenu de chaque attribut avec le contenu des concepts de l’ontologie de valeurs,

11-13 : GenDescripRel utilise le module SchemaBD afin de récupérer la description de la relation

Rel,

14-19 : Les résultats des différents traitements sont affichés à l’utilisateur-concepteur, qui choisit le

concept C décrivant la relation Rel,

132

20-21 : Une fois le concept choisi, un élément XML décrivant la relation Rel est créé, et inséré dans

le document décrivant la base de données. Cet élément porte le nom NomR de la relation Rel, et

contient deux autres éléments de type PCDATA. Le premier contient le nom du concept C décrivant

la relation Rel et le deuxième contient sa description, récupérée du dictionnaire de données.

3.4.2.2 Description d’un attribut

GenDescripAttInterfaceUtilisateur Ontologie SchemaBD GestDocXMLGenDescripBD

7: ontologie(contenu attribut)

8: comparaison(contenu attribut)9: resultat comparaison

5: schemaBD(Nom_Att)

6: contenu Attribut

14: affichage()

15: choix_uti l isateur()

1: genDescripAtt(Nom_Att)2: ontologie(Nom_Att)

3: Recherch_conceptEquiv(Nom_Att)4: Liste_conceptEquiv

10: schemaBD(Nom_Att)

11: recup_dic(Nom_Att)12: description attribut

13: resultat traitement

16: choix uti l isateur

18: ElemXML, nom_rel()

19: document modifié

17: creer_element(nom_concept)

1 : Le nom de l’attribut Att à décrire, est envoyé au module GenDescripAtt

2 -4 : GenDescripAtt récupère à partir de l’ontologie les concepts pouvant décrire l’attribut,

5-9 GenDescripAtt recherche les types d’informations contenues dans l’attribut en comparant son

contenu avec celui des concepts de l’ontologie de valeurs,

10-12 : GenDescripAtt récupère à partir du dictionnaire de données de la base de données, la

description de l’attribut Att, et ce en utilisant le module SchemaBD,

133

13-16 : Les résultats des différents traitements sont affichés à l’utilisateur-concepteur, qui choisi le

concept Catt, décrivant l’attribut Att,

17-19 : Une fois l’utilisateur choisit le concept, un élément XML décrivant l’attribut Att, est crée, et

inséré dans l’élément décrivant sa relation. Cet élément porte le nom NomAtt de l’attribut Att, et

contient deux autres éléments, le nom du concept Catt décrivant l’attribut Att, ainsi que sa

description, récupérée du dictionnaire de données. Si l’attribut est un identifiant, il est inséré dans

l’élément XML « CleP ».

3.4.3 Exemple: Description d’une relation La Figure 46 contient un exemple de description de la relation Patient présentée ci-dessous.

Patient (Numordre, nom, prenom, datenaiss, lieunaiss, profession, adresse, NSS)

• Souligné : clé primaire. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE schema SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD DESCRIPTION.dtd"> <schema> <Nom-schema>BD1</Nom-schema> <Relation nom-relation="Malade"> <Nom-concept> Patient </Nom-concept> <description> relation contenant les informations sur les patients</description> <attribut Nom-attribut="Code"> <Nom-concept> Code-Patient </Nom-concept> <description> Identifiant des patients </description> </attribut> <attribut Nom-attribut="Nom-malade"> <Nom-concept> nom </Nom-concept> <description> Nom de famille du patient </description> </attribut> <attribut Nom-attribut="Prenom-malade"> <Nom-concept> Prenom </Nom-concept> <description> prenom du patient </description> </attribut> <attribut Nom-attribut= "Datenaiss"> <Nom-concept> date-naissance </Nom-concept> <description> Date de naissance du patient </description> </attribut> <attribut Nom-attribut= "villenaissance"> <Nom-concept> Lieu-naissance </Nom-concept> <description> Lieu de naissance du patient </description> </attribut> <attribut Nom-attribut= "N_rue"> <Nom-concept> Num-rue </Nom-concept> <description> Numéro de la rue de l’adresse du patient </description> </attribut> <attribut Nom-attribut= "Rue">

134

<Nom-concept> Rue </Nom-concept> <description> La rue du patient </description> </attribut> <attribut Nom-attribut= "Codepostal"> <Nom-concept> Code-postal </Nom-concept> <description> Le code postal du patient </description> </attribut> <attribut Nom-attribut="NSS"> <Nom-concept> Num_sec_sociale </Nom-concept> <description> Le numéro de sécurité sociale du patient </description> </attribut> <CleP IDAttribut="Code"/> </Relation> </schema>

Figure 46 : Document XML décrivant la relation "Patient"

135

3.5 Présentation du prototype 2 : Générateur de schéma médiateur

3.5.1 Diagramme des classes du générateur de schéma médiateur

GenRelaltion

GenRelation()traitRelationMed()traiLienRel()

SchemaMediateurAttributMed

String nomAttributMedboolean clep

AttributMed()getAttributName()setAttributName()affiche()

SchemaMedString nomSchemaVector listeRelMed

SchemaMed()addRelationMed()getRelationMed()modifSchema()

LiensString nomBDString nomRelString nomAttVector listenomString fonctionConversion

Liens()getnomBD()getnomRel()getnomAttr()

RelationMedString nomRelationMedVector listeAttributMed

RelationMed()modifRelMed()ajoutAttribut()getAttribut()

Ontologie

LienOntoString nomLienString typeLienString nomConceptPereString ConceptFils

LienOnto()getConceptPere()getConceptFils()getnomLien()

ConceptString nomConceptString typeConcept

Concept()getAttributConcept()

RecupOntoInfo

RecupOntoInfo()afficheOnto()recupConcept()recupLienConcept()getConceptAscend()getConceptDescend()

Optimiser

Optimiser()optimiserRel()optimiserAttr()

GenMed

GenMed()

InterfaceUtilisaeur

InterfaceUtilisateur()main()

GenAttribut

GenAttribut()traitAttributMed()traitClePrim()

GestDocXML

Figure 47 : Schéma des classes du générateur de schéma médiateur

InterfaceUtilisateur

Présente à l’utilisateur une interface graphique lui permettant d’interagir avec le prototype et

de valider les résultats.

136

GenRelation & GenAttribut

Ces classes génèrent le schéma médiateur en exploitant les documents décrivant les bases de

données. La classe GenRelation (resp. GenAttribut) traite les relations (resp. les attributs) du schéma

médiateur ainsi que les liens qui existent entre elles.

Optimiser

Une fois le schéma médiateur généré, la classe Optimiser traite les redondances et les

relations hyponymes. Elle aide à résoudre les hétérogénéités structurelles.

GenMed

Interagit avec l’utilisateur dans la création du schéma médiateur. Une fois la création

terminée, fait appel à la classe Optimiser afin d’optimiser le schéma médiateur.

Package : SchemaMediateur

Ce package est une instance du schéma médiateur, parmi ses classes principales :

- AttributMed : Gère les instances des attributs des relations du schéma médiateur

- RelationMed : Gère les instances des relations du schéma médiateur

- Liens : Contient les correspondances entre les relations et attributs du schéma médiateur et

leurs équivalences dans les schémas sources (les règles de mapping). Elle est constituée du

nom de la base de données source, du nom de la relation sources, et de ceux des attributs

sources et des fonctions de conversion.

Notre prototype est également constitué de la classe GestDocXML et du package Ontologie,

présentés ci-dessus.

137

3.5.2 Diagramme des séquences : Génération des relations

GenAttributGenMed GenRelation GestDoc Optimiser RecupOntoInfo

1: genRelation(nom_concept)2: gestDoc(nom_concept, docBD)

3: Rech_relationEquiv(nom_concept)4: liste Relation Equivalente

5: CreationRelMediateur(nom_concept)

6: GestDoc(nom_concept, mediateur)7: inserRelationMediateur

8: schema médiateur modifié

9: creationRelMapp(nomconcept, listerelationequivalente)

10: gestDoc(RelMapp, Docmapping)11: inserRgMapp()12: document des mapping modifié

13: genAttribut()

14: Attributs médiateur générés

15: gestDoc(refrences, docBD)

16: recup_liste_lien()17: Liste des relation référencées

18: Modif_CleP19: schéma créé

20: optimiser(schéma_med)21 : recupOntoInfo

22: recherche_equivalent()23: liste equivalence

24 : modif_schemaMed()25 : schéma optimisé

Pour chaque relation R d’une base de données BD faire :

1 : GenMed envoie au module GenRelation le nom du concept C décrivant la relation R,

2-4 : GenRelation recherche à partir des documents décrivant les autres bases de données, la liste

ListR des relations décrites par le même concept C,

5-8 : GenRelation crée dans le document contenant le schéma médiateur, une relation portant le nom

du concept C,

9-12 : Une règle de mapping permettant de lier la relation du schéma médiateur aux relations sources

est créée dans le document des mappings,

13-14 : Traiter les attributs de la relation R,

15-19 : Reproduire les liens de la relation R dans le schéma médiateur,

20-25 : Enlever les redondances du schéma médiateur

138

3.5.3 Diagramme de séquence : Génération des attributs

GenRelation GenAttribut GestDoc

1: genattribut(nomRel, nom_conceptAtt)

2: gestDoc(nomRel, nom_conceptAtt, docBD)

3: Rech_AttributEquiv(nomRel, nom_conceptAtt)4: liste Attribut Equivalente

5: CreationAttMediateur(nom_conceptAtt)

7: inserAttMediateur(nomRel)

6: GestDoc(nomRel, nom_conceptAtt, mediateur)

8: schema médiateur modifié

9: creationAttMapp(nomRel, nomconceptAtt, listeAttequivalent)

10: gestDoc(AttMapp, Docmapping)11: inserRgMapp()12: document des mapping modifié

Pour chaque attribut Att de la relation R faire : 1 : GenRelation envoie au module GenAttribut le nom du concept Catt décrivant l’attribut Att de la

relation R,

2-4 : GenAttribut recherche à partir des documents décrivant les autres bases de données, la liste

ListAtt des attributs décrits par le même concept Catt,

5-8 : GenAttribut crée dans le document contenant le schéma médiateur, un attribut ayant le nom du

concept Catt,

9-12 : Une règle de mapping permettant de lier l’attribut du schéma médiateur aux attributs sources

est créée dans le document des mappings.

3.5.4 Exemple: Génération du schéma médiateur

Les figures 48 et 49 exposent respectivement les documents XML contenant la vue unifiée ainsi

que ses règles de mapping des deux parties de bases de données BD1 et BD2 présentées ci-dessous :

BD1 : Patient (Numordre, nom, prenom, datenaiss, lieunaiss, profession, adresse, NSS) BD 2 : Malade (code, nom-malade, prenom-malade, datenaissance, villenaissance, N_rue, rue, codepostal, ville, NSS) * Souligné : Clé primaire.

139

Schéma médiateur <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMed SYSTEM "C:\DTDSchemaMed.dtd"> <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMed SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD schemaMed.dtd"> <SchemaMed> <RelationMed nom-relation="Patient">

<AttributMed nom-attribut="Numordre"/> <AttributMed nom-attribut="code"/> <AttributMed nom-attribut="Nom"/> <AttributMed nom-attribut="Prenom"/> <AttributMed nom-attribut="Date-naissance"/> <AttributMed nom-attribut="Lieu-naissance"/> <AttributMed nom-attribut="profession"/> <AttributMed nom-attribut="Adresse"/> <AttributMed nom-attribut="Num_sec_sociale"/> <CleP IDAttribut="Numordre code"/>

</RelationMed> </SchemaMed>

Figure 48 : Document XML contenant le schéma médiateur

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMedMapping SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD MApping.dtd"> <SchemaMedMapping> <RelationMedMapping nom-relation="Patient"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Nom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Nom</nom-attrib> </LienAttribut> <LienAttribut>

140

<nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Nom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Prenom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Prenom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Prenom-malade</nom-attrib> </LienAttribut> </AttributMedMapping>

<AttributMedMapping nom-attribut="date-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>datenaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>datenaiss</nom-attrib> </LienAttribut> </AttributMedMapping>

<AttributMedMapping nom-attribut="Lieu-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>lieunaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Villenaissance</nom-attrib> </LienAttribut> </AttributMedMapping>

<AttributMedMapping nom-attribut="Num_sec_sociale"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>NSS</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>NSS</nom-attrib> </LienAttribut> </AttributMedMapping>

<AttributMedMapping nom-attribut="Adresse"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Adresse</nom-attrib> </LienAttribut> <LienAttribut>

141

<nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>N_rue</nom-attrib> <nom-attrib>Rue</nom-attrib> <nom-attrib>Codepostal</nom-attrib> <fctConv>Concatenate</fctConv> </LienAttribut> </AttributMedMapping> </RelationMedMapping> </SchemaMedMapping>

Figure 49 : Document XML contenant les règles de mapping

4 Médiateur

4.1 Présentation du prototype 3 : Médiateur

Interface graphique

Requête

MédiateurMap

FormatResult Résultats

Requête

BD1 BD2

Résultat

Requête Résultat

Document XML

DecomposReqNom tables et attributs

Processeur de requêtes

Requête

Résultats

Traducteur

Requête traduite

Figure 50: Architecture du médiateur

La Figure 50 présente l’architecture du système de médiation permettant aux utilisateurs

d’interroger plusieurs bases de données hétérogènes implémentées sous MySQL [AQU 02].

L’utilisateur formule une requête utilisant une interface graphique. Cette requête est envoyée au

médiateur qui la décompose en plusieurs parties (SELECT, FROM et WHERE) avant de la

transmettre au composant DecomposReq. Ce dernier traite chaque partie et extrait les noms des

relations et des attributs utilisés dans la requête. Une fois les noms trouvés, le composant Traducteur

remplace chaque relation et chaque attribut par son équivalent, et renvoie une requête pour chaque

142

base de données au médiateur. Le Processeur de requête exécute chaque requête et renvoie les tuples

au module FormatResultat qui les formate dans un document XML avant de les afficher à

l’utilisateur. Grâce à l’utilisation de DRUID, à chaque tuple est rattachée une URL permettant à

l’utilisateur de consulter le document source.

Les figures suivantes exposent l’exécution des requêtes par notre médiateur. La Figure 51

(resp. Figure 53) permet à l’utilisateur de formuler sa requête : « SELECT NOM FROM Medecin ; »

(resp. « SELECT idMedecin, Prescription.idPatient, Ordonnance.idPatient FROM Medecin,

prescription, Ordonnance WHERE Prescription.date-prescription=‘12/04/2002’; » ). Après

traitement et traduction, ces requêtes sont exécutées dans la Figure 52 (resp. Figure 54).

Figure 51 : Interface graphique permettant à l’utilisateur de formuler sa requête

143

Figure 52 : Résultats de l’exécution des différentes requêtes

Nous observons dans la Figure 52 que la requête principale est devenue « Select NOM_Med

FROM MEDECIN » dans la base de données BD1. Un message d’erreur est affiché à l’utilisateur

lors de la traduction de la requête sur la base de données BD2 car la relation MEDECIN n’a pas son

équivalent dans cette base de données.

144

Figure 53 : Interface graphique permettant à l’utilisateur de formuler sa requête

Figure 54 : Résultats de l’exécution des différentes requêtes

La Figure 54 présente la traduction et l’exécution de la deuxième requête qui devient dans la

base de données :

145

- BD1 : « SELECT CODEMED, Prescription.numordre FROM Medecin, prescription WHERE

Prescription.date-prescription=‘12/04/2002’; »

BD2 : « SELECT CODEMEDECIN, Prescription.code, Prescription-medicale.code FROM

Medecin, prescription, prescription-medicale WHERE Prescription.date = ‘12/04/2002’; »

4.2 Fonctionnement du prototype

L’utilisateur formule une requête sur la vue unifiée en utilisant le vocabulaire retenu dans son

schéma. La requête est envoyée ensuite au médiateur afin d’être décomposée en plusieurs requêtes

sur différentes sources de données. Le médiateur décompose la requête en trois parties, à savoir les

données à afficher qui sont entre les mots-clés SELECT et FROM, les relations interrogées qui se

trouvent entre les mots-clés FROM et WHERE ainsi que les relations et les attributs qui sont

contenus dans la condition et qui viennent après le mot-clé WHERE. Le traitement des requêtes se

repose sur les règles présentées ci-dessous.

4.2.1 Règles des traitements des requêtes

Règle 1 : Une requête Req est sous la forme : « SELECT Res FROM Tab WHERE Cond; » où Res

est l’ensemble des colonnes à afficher, Tab est l’ensemble des relations intérrogées et Cond la

condition,

Règle 2 : Il existe un ensemble d’opérateurs booléen (AND, OR…), d’algèbre (=, >,<, <>…)

Règle 3 : Une condition est sous la forme (Exp Op Exp) [Op Exp]n [Bool (Exp Op Exp)]n où Exp est

une expression pouvant être un nom d’attribut simple ou précédé par celui d’une relation ou d’un

alias, une constante (chaîne de caractère, nombre ou date). OP est un opérateur de comparaison et

Bool un opérateur logique.

Règle 4 : Le SELECT est sous la forme (Exp1, Exp2, ...) où ExpN est une expression pouvant être

une fonction, un nom d’attribut simple ou précédé par celui d’une relation ou d’un alias.

Règle 5 : Le FROM est sous la forme (Exp1, Exp2,..) où ExpN est une expression pouvant être un

nom d’une relation ou d’un alias.

Règle 6 : Si le contenu d’une expression en phase de traitement est une constante (chaîne de

caractère, nombre ou un opérateur booléen, arithmétique…) alors il n’est pas traduit et garde son

contenu dans toutes les requêtes

146

Règle 7 : Afin d’éviter les ambiguïtés dans la formulation des requêtes, tous les attributs sont

précédés par le nom de la relation les contenant

Règle 8 : Si le contenu du SELECT est de type « X, Y as z » où z est une chaîne de caractères alors

X et Y sont des attributs.

Règle 9 : Si le contenu du SELECT est de type « Fct (C) » où Fct est une fonction d’agrégat (Max,

Avg…) ou de conversion (Round()…) alors C est un attribut.

Règle 10 : Le contenu du SELECT n’est pas traduit dans le cas où il serait égal à «Fct (*)» où Fct est

une fonction d’agrégat (Max, Avg…) ou de conversion (Round()…).

Règle 11 : Si le contenu du SELECT est de type « F.a T.b » alors a et b sont des attributs et F et T

sont des relations ou des Alias.

Règle 12 : Si le contenu du SELECT est de type « X op Y, X op Nbr » où « op » est un opérateur

arithmétique et « Nbr » un nombre quelconque, alors X et Y sont des attributs

Règle 13 : Si le contenu du FROM est de type « X, Y » alors X et Y sont des relations.

Règle 14 : Si le contenu du FROM est de type « X a, Y AS b » alors X et Y sont des relations, a et

b sont des alias,

Règle 15 : Si le contenu du WHERE est sous la forme « X.a Op NBR » où NBR est une constante

alors X est une relation ou un alias et a est un attribut

Règle 16 : Si le contenu du WHERE est sous la forme « X Op Y » alors X et Y sont des attributs

4.2.2 Traitement de l’expression du FROM

Durant la première phase, le module DecomposeReq récupère l’expression de la clause FROM

qui est ensuite traitée afin d’en extraire la liste des relations et des alias qui se trouvent dans la

requête. Pour ce faire DecomposeReq étudie le contenu de l’expression TAB (Règle 1), qui est sous

la forme « A, B, C » et qui contient un ensemble de relations et d’alias séparés par des virgules

(Règle 5). Le résultat du traitement est différent selon le type du contenu de l’expression TAB :

Si TAB est de type : - « X, Y » alors X et Y sont des relations du schéma médiateur (Règle 13),

- « X a, Y AS b » alors X et Y sont des relations du schéma médiateur, a et b sont des alias

(Règle 14).

Les alias trouvés durant cette étape sont comparés avec ceux qui se trouvent dans les

expressions du SELECT et du WHERE afin de les remplacer par leurs équivalents.

147

4.2.3 Traitement de l’expression du SELECT

Dans la deuxième phase nous traitons l’expression du SELECT et nous extrayons l’ensemble des

relations et attributs à afficher à l’utilisateur. Cette expression est contenue dans la variable Res de la

requête principale (Règle 1). Les résultats du traitement sont différents selon le type du contenu de

l’expression du SELECT :

Si RES est de type :

- « X, Y as ‘nom de patient’» X et Y sont des attributs du schéma médiateur (Règle 8),

- « Fct (C) » où Fct est une fonction d’agrégat (SUM, AVG…) ou de conversion (Round()…)

et si C est différent de « * » alors C est considéré comme un attribut du schéma médiateur

(Règle 9 et Règle 10),

- « F.a T.b » alors a et b sont considérés comme des attributs et F et T sont considérés comme

des relations du schéma médiateur ou des Alias (Règle 11),

« X op Y, X op Nbr » où op est un opérateur arithmétique et Nbr un nombre quelconque. Dans ce cas

X et Y sont considérés comme des attributs du schéma médiateur (Règle 12).

4.2.4 Traitement de l’expression du WHERE Durant la troisième phase nous traitons les expressions existantes dans la condition de la requête.

Cette partie utilise les résultats de la première phase afin de remplacer les alias par leur relation

équivalente. Ces expressions sont composées des noms des attributs précédés, parfois, par les noms

des relations ou des alias et séparés par des opérateurs algébriques ou de comparaisons. Les

expressions sont séparées, entres elles, par des opérateurs logiques. Le contenu de la condition (cond)

est sous la forme (Exp Op Exp) [Op Exp]n [Bool (Exp Op Exp)]n où OP est un opérateur de

comparaison et Bool un opérateur logique (Règle 3). Exp est une expression pouvant être :

Un nom d’attribut simple

Un attribut précédé par une relation ou un alias,

Une chaîne de caractères,

Une constante (un nombre ou une date).

Les résultats du traitement sont différents selon le contenu de l’expression Exp:

Si Exp est de type :

« X Op Y » alors X et Y sont des attributs (

- Règle 16)

- « X.a Op NBR » où NBR est une constante alors X est une relation ou un alias et a est un

attribut (Règle 15),

A la fin de cette phase la liste des attributs et relations est renvoyée au médiateur.

148

Il faut noter qu’à chaque fin de traitement, la liste des relations et des attributs est vérifiée avec celle

du schéma médiateur. Si des anomalies sont détectées, un message d’erreur est affiché à l’utilisateur

qui corrige la liste des relations et attributs.

4.2.5 Traduction des requêtes

Dans la phase de traduction, nous remplaçons chaque terme de la requête par son équivalent

dans chaque base de données source. Ces équivalences sont stockées dans un document XML

conforme à la DTD du document de mapping. La traduction des requêtes est composée de deux

phases :

Traduction des relations :

Pour chaque relation R de la requête principale, nous recherchons son équivalent dans le

document contenant les règles de mapping. Pour ce faire, nous nous positionnons sur l’élément XML

contenant les correspondances de la relation R du schéma médiateur et nous récupérons la relation

R2 de la base de données BD qui lui est équivalente. La relation trouvée remplace la relation R dans

la requête principale. Ce traitement est appliqué pour chaque base de données à interroger. Une fois

toutes les relations traitées, nous traduisons les différents attributs contenus dans la requête.

Traduction des attributs :

Pour ce faire, nous nous positionnons sur l’élément XML équivalent à l’attribut Att du schéma

médiateur et nous récupérons le nom de l’attribut Att2 qui lui est équivalent ainsi que la fonction de

conversion si cette dernière existe. Une fois trouvé, l’attribut Att de la requête principale est

remplacé par Att2 ainsi que par la fonction de conversion, si elle existe. Ce traitement est applique

pour tous les attributs qui composent la requête principale. A la fin de ce traitement nous avons une

requête propre à chaque base de données.

149

4.3 Diagrammes des classes du médiateur

InterfaceUtilisateur

InterfaceUtilisateur()main()

TraiteRequeteString requeteVector termesString clauseSelectString clauseWhereString clauseFromString clauseGroupString clauseOrder

TraiteRequete()getTableAlias()gettermeSelect()gettermeFrom()gettermeWhere()gettermeOrder()gettermeGroup()opname2()

RecupSchemaMed

RecupSchemaMed()recupRelMed()recupAttMed()

AnalyseRequete

AnalyseRequete()

ExecuteRequeteString piloteString urlDB

ExecuteRequete()

FormatResult

formatResult()formatResult()

RecomposeRequete

RecomposeRequete()relMedMap()relAttMedMap()composeReq()

RecupMapping

RecupMapping()chargeDoc()getAttMapp()getRelMapp()

Figure 55 : Schéma des classes du médiateur

4.4 Présentation des classes Classe TraiteRequte :

C’est la classe principale de notre prototype. Elle affiche à l’exécution une interface qui

permet à l’utilisateur de saisir sa requête (selon les termes propre au schéma médiateur). Elle

récupère les différentes parties de la requête (Corps du SELECT, du FROM, du WHERE..) et traite

les termes qui y figurent afin de récupérer les noms des attributs et des relations. A la fin de

l’exécution de la requête, elle affiche le résultat à l’utilisateur.

Classe AnalyseRequete :

Elle analyse les termes issus du traitement de la classe TraiteRequete et vérifie, en utilisant la

classe RecupSchemaMed, si les noms des attributs et des relations sont issus du schéma médiateur.

Dans le cas contraire un message d’erreur avertit l’utilisateur qu’il a utilisé un terme non conforme

au schéma médiateur, et qu’il doit resaisir sa requête.

150

Classe RecomposeRequete :

Après avoir vérifié la validité des termes composant la requête, TraiteRequete fait appel à la

classe RecomposeRequete afin de construire la requête correspondant à chaque base de données.

Pour ce faire RecomposeRequete interagit avec le document XML contenant le schéma de mapping

ainsi que celui contenant le schéma médiateur, afin d’associer les relations et les attributs de la

requête issus du schéma médiateur à ceux contenus dans les bases de données à interroger. Elle

utilise les différentes méthodes définies dans les classes RecupMapping et RecupSchemaMed.

Apres avoir identifié les différentes associations, RecomposeRequete utilise la méthode

composeReq() afin de construire un vecteur d’objets (base de données, requête). Ce vecteur est

récupéré par la Classe ExecuteRequete qui se charge d’envoyer et d’exécuter chaque requête sur la

base de données qui lui est associée.

Classe ExecuteRequete

Appelée par la classe TraiteRequete, elle récupère le vecteur d’objets (base de données,

requête) que la classe RecomposeRequete a créé et distribue les requêtes sur les bases de données

correspondantes. Elle récupère ensuite le résultat de l’exécution.

Classe FormatRequete Appelée une fois l’exécution des requêtes terminées, elle formate les résultats dans un document XML avant de le présenter à l’utilisateur.

4.5 Diagramme de séquences InterfaceUtilisateur TraiteRequete ClauseSelect ClauseFrom ClauseWhere RecomposRequ RecupMapp ExecutReq FormatResult

1: traiteRequete(Req)

2: ClauseSelect(Req)3: traiteClause(Req)4: liste_att_Rel

5: ClauseFrom(Req)6: traiteClause(Req)7: liste_Rel

8: ClauseWhere(Req)9: traiteClause(Req)10: liste_att_Rel

11: recompoRequ(listeRel, listeAtt)12: recupMapp(listeRel, listeAtt)

13: Traduction(listeRel, listeAtt)14: traduction

15: executReq(listeReq, listBD)16 executeReq()

17: formatResult(resultat)18: FormatResultat19: document de resultats

20 : Affichage()

151

1 : La requête de l’utilisateur (requête principale) est envoyée au module TraiteRequete,

2-4 : TraiteRequete envoie la requête principale au module ClauseSelect, ce dernier la traite et extrait

les attributs et les relations qui se trouvent dans la clause select,

5-7 : La requête principale est envoyée au module ClauseFrom, ce dernier extrait les relations et les

alias à interroger,

8-10 : La requête principale est envoyée au module ClauseWhere, qui extrait les attributs et les

relations de la clause Where,

11 : La liste des relations et attributs trouvés ci-dessus (2..10), est envoyée au module RecomposReq,

12-14 : RecomposReq traduit les relations et attributs par leur correspondances dans les bases de

données sources, en utilisant le document contenant les mapping. A cette étape, nous avons des

requêtes propres à chaque base de données,

15-19 : ExecutReq exécute chaque requête sur sa propre bases de données, formatte les résultats

(FormatResult) dans un document XML, et le renvoie à l’interface utilisateur pour être affiché.

5 Contrôle des données

5.1 Introduction

Nous avons développé un prototype qui permet de contrôler les informations stockées dans

les bases de données sources. Pour ce faire nous générons à partir du schéma de la base de données

des modèles de documents. Ces modèles permettent de contrôler les informations saisies et

consultées. Une fois les modèles de documents (DTD) créés, notre prototype les modifie selon les

droits sur la base de données, nous aurons ainsi des DTD en lecture et en écriture propres à chaque

type d’utilisateur. Pour nos tests nous avons utilisé une base de données médicale implémentée sous

CLOUDSCAPE [CLO 00]. Dans ce qui suit nous allons présenter le prototype de gestion des droits

d’accès.

152

5.2 Présentation du prototype 4 : Génération et filtrage de DTDs

MonInterface

Base de données

Mastructure

GeneratorDTD

Relation

Attribut

Package DTD

FiltreDTD

Figure 56 : L'architecture du prototype de contrôle de données

L’interface utilisateur est le composant qui permet à l’utilisateur de communiquer avec le

système. Elle se compose principalement d’une zone d’affichage des DTDs générées ainsi que d’une

boîte de dialogue contenant les noms des relations de la base de données pour laquelle les modèles de

documents sont générés. Elle permet à l’utilisateur de choisir l’élément racine de la DTD à générer.

L’interface utilisateur transmet au module GeneratorDTD le nom de l’élément racine choisi par

l’utilisateur qui récupère la structure de la base de données en utilisant le module Mastructure. Une

fois les DTDs générées, le module FiltreDTD récupère les droits sur la base de données afin de

modifier la DTD globale et de créer les DTDs propres à chaque type d’utilisateurs.

Nous avons également utilisé un package DTD distribué sur Internet par Ronald Bourret

[BOU 00]. Son package fournit un parseur de DTD et un ensemble de classes qui modélise les DTDs

sous la forme d’objet Java.

153

Figure 57 Exemple de génération d’une DTD SSD

5.3 Digrammes des classes

La conception objet du prototype présente principalement les classes suivantes :

GeneratorDTD

C’est le noyau de l’application, elle s’appuie sur plusieurs classes (classe Champs, Table,

Mastructure, ainsi que le package de DTD)

Mastructure

Appelée au commencement de l’exécution, elle se connecte à la base de données pour extraire

toutes les informations concernant la structure de la base en utilisant l’interface JDBC.

Connection

Elle se connecte au schéma de la base de données et récupère sa structure

FiltreDTD

Récupère les droits des utilisateurs sur la base de données et modifie la DTD globale afin de

générer pour chaque type d’utilisateur une DTD en lecture et en écriture,

Privilege

Cette classe est appelée au début de l’exécution. Elle se connecte à la base de données pour

extraire les droits et privilèges des utilisateurs en utilisant l’interface JDBC.

154

MonInterface

Présente à l’utilisateur la liste des relations de la base de données afin de choisir l’élément

racine. A la fin du traitement elle affiche les DTDs générées.

MoninterfaceFiltreDTD filtredtd

Moninterface()actionPerformed()main()

GenDTDRelation relationBDD bddDTD maDTDString nomelementracine

GenDTD()creertable()rechAttribut()writeDTD()

FiltreDTDname

FiltreDTD()parseElement()

DTDs

DTDPcdata

DTDPcdata()write()

DTDElementString nom

DTDElement()getAttribute()getNom()setNom()

DTDdocString nomString type

DTDdoc()getDTDElement()write()

DTDAttributeString nomString type

DTDAttribute()getNom()getType()write()

AttributString nomboolean clePboolean cleEString tableref

Attribut()getNom()setNom()write()

ConnectionConnection connectionStatement statementPreparedStatement preparedStatementResultset resultsetString bddString driver

Connection()getBDD()getResultset()

BDDString nomVector relation

BDD()getListeRelation()getNom()write()

PrivilegeConnection connectionResultset resultset

Privilege()getGroups()getPrivilege()

RelationString nomVector clePVector cleEVector attribut

Relation()getNom()getCleP()getCleE()getAttribut()getTableRef()write()

Figure 58 : Diagramme de classes du prototype

155

5.4 Diagramme de séquences

Moninterface GenDTD DTDs Privilege ConnexionFiltreDTD

1:genDTD(typDoc, racine)2:connexion()

3:recupListRel()4: liste_relation

5:creat_DTD()

6 :DTDs(Element_DTD)7 :creat_doc_DTD()8: envois_DTD

9: envois_DTD

10: affichage

11: filtreDTD(DTD, utilisateur)12:privilege(utilisateur)

13: recup_Droit(utilisateur)14:envois_droit()

15:filtreDTDs()16:DTDs(DTDNew)

17: modif_doc_DTD()

1 : Le type du document pour lequel la DTD est à générer ainsi que le nom de la racine sont envoyé à

GenDTD,

2 - 4 : GenDTD se connecte à la base de données et récupère la liste des relations et attributs,

5- Création de la DTD,

6 – 8 : Le document XML contenant la DTD est créé en utilisant le package DTDs,

9 – 10 : La DTD est affichée à l’utilisateur concepteur,

11 : Une fois la DTD principale créée, nous la filtrons selon chaque groupe d’utilisateur,

12 -14 : FiltreDTD récupère les droits de l’utilisateur pour lequel la DTD va être filtrée,

15-17 : La DTD principale est modifiée selon les droits de l’utilisateur.

6 Conclusion

Nous avons conçu et développé un ensemble de prototypes composé de plusieurs modules.

Un prototype génère un schéma médiateur à partir de différentes bases de données hétérogènes. Il

présente, à l’utilisateur, un médiateur lui permettant de formuler une requête et d’interroger plusieurs

bases de données. Nous avons rattaché à notre prototype le système DRUID afin, d’une part, de lui

faciliter sa tâche de saisie, et d’autre part, de gérer la confidentialité des données stockées dans nos

bases de données. Pour ce faire nous avons conçu un prototype permettant de développer des DTDs

propres à chaque utilisateur selon ses droits de consultations et de saisie.

156

CHAPITRE VI : CONCLUSION 1 Contribution ...............................................................................................................................156

1.1 Schéma médiateur ..............................................................................................................156 1.2 Contrôle des données .........................................................................................................157

2 Perspectives................................................................................................................................157 2.1 Orienté-objet ......................................................................................................................158 2.2 Utilisation du système dans un cadre professionnel ..........................................................158 2.3 Enrichir l’ontologie............................................................................................................158 2.4 Un système d’apprentissage...............................................................................................158 2.5 Interface de validation........................................................................................................159 2.6 Interface d’interrogation ....................................................................................................159

Durant ma thèse je me suis intéressé à l’intégration de bases de données permettant

l’interrogation de bases de données hétérogènes. J’ai proposé une solution à cette problématique en

générant une vue unifiée de tous les schémas des bases de données à intégrer. Dans ce qui suit nous

résumons les différentes contributions de notre thèse et indiquons les perspectives.

1 Contribution

1.1 Schéma médiateur

Dans le chapitre d’état de l’art nous avons présenté différents systèmes d’intégration de bases

de données et nous avons montré leurs limites. Ces dernières sont dues dans la plupart du temps à la

création de la vue unifiée, qui est délicate et qui nécessite l’intervention des utilisateurs. Afin

d’améliorer cet état de fait nous avons proposé une approche pour la création d’un schéma

médiateur. Cette approche est composée de deux étapes. Dans la première nous construisons des

documents XML décrivant chaque schéma source à intégrer en utilisant des termes issus d’une

ontologie. Cette étape nous permet d’éliminer les différentes hétérogénéités sémantiques. Le schéma

médiateur est ensuite généré, non à partir des bases de données sources, mais à partir des documents

les décrivant. Durant cette étape nous traitons les hétérogénéités structurelles.

Notre proposition a permis de réduire sérieusement les interventions des utilisateurs dues à la

modification des schémas sources. En effet, il était difficile d’insérer une relation ou un attribut dans

un schéma source car cela nécessitait la régénération entière de la vue unifiée [ROU 04]. Avec notre

système nous n’avons plus à régénérer entièrement le schéma médiateur à chaque modification mais

157

seulement à le modifier, ainsi que le document XML contenant les règles de mapping. Nous avons

montré la simplicité de ce processus dans le chapitre IV.

Afin de valider notre proposition nous avons développé différents prototypes, dont un

médiateur qui utilise la vue unifiée pour interroger différentes bases de données. Pour ce faire, il

transforme une requête formulée sur un schéma médiateur en différentes requêtes propres à chaque

base de données source, les exécute et renvoie les résultats à l’utilisateur.

1.2 Saisie et Contrôle des données

Afin d’alléger le processus de saisie des informations par les utilisateurs, nous avons proposé

d’utiliser DRUID en tant que système d’entrée pour notre système de médiation. DRUID permet aux

utilisateurs de saisir les données non pas dans des formulaires mais sous forme de documents

conformes à des DTDs. Ces DTDs sont une image de la base de données à alimenter. Afin de

faciliter leur création, nous avons proposé une solution permettant de générer automatiquement, en

premier lieu, une DTD de document fortement structuré à partir du schéma de la base de données.

Cette DTD est transformée ensuite en DTD faiblement structurée pour les documents saisis.

Notre système est utilisé par des utilisateurs ayant différents profils et différents droits.

Devant cette différence de profil, il est impératif de protéger ces informations. Pour ce faire, nous

avons proposé de créer des modèles de documents (DTD) propres à chaque type d’utilisateur, et

différents pour les documents en écriture et en lecture. Chaque document saisi ou consulté par un

utilisateur devra être conforme à une DTD. Notre proposition est de générer automatiquement en

premier lieu une DTD globale, qui sera ensuite modifiée selon les droits d’accès des utilisateurs.

Lorsqu’un utilisateur veut consulter un document, DRUID récupère la DTD de l’utilisateur et

transforme le document afin qu’il soit conforme à cette DTD. Les éléments qui lui sont interdits sont

donc enlevés. De la même manière, il ne présente à l’utilisateur voulant saisir des données que les

balises qui lui sont permises.

2 Perspectives

Notre travail de thèse a donné suite à différentes perspectives, nous en citerons quelques-unes

unes ci-dessous.

158

2.1 Orienté-objet

Notre proposition de génération de schémas médiateurs n’est, pour le moment, appliquée que

sur les schémas relationnels. Il serait nécessaire de l’étendre sur les modèles orientés objets où nous

devrons gérer les héritages et autres liens entre objets.

2.2 Utilisation du système dans un cadre professionnel

Les bases de données utilisées dans le cadre de notre thèse ont été créées dans le but de

valider nos prototypes. Nous les avons créées de telle manière qu’elles soient les plus proches

possible de celles qui peuvent contenir des dossiers médicaux. Afin de rendre plus général notre

système, nous allons l’utiliser aussi bien sur des bases de données hospitalières que dans d’autres

domaines telles que les banques, les universités etc.

En effet notre système de médiation n’est pas conçu que pour le domaine médical, il peut

également être utilisé dans tout autre domaine nécessitant l’intégration de bases de données et la

protection des données

2.3 Enrichir l’ontologie

Notre ontologie n’étant pas encore complète, elle ne peut pour le moment contenir tous les

termes qui peuvent décrire les schémas des bases de données à intégrer. Il est donc impératif de

présenter à l’utilisateur un outil qui lui permette d’enrichir l’ontologie. Cet outil devra présenter à

l’utilisateur l’ontologie ainsi qu’un dictionnaire de synonymes afin que ce dernier puisse saisir un

concept ainsi que ses synonymes. Il devra aussi afficher les concepts contenus dans l’ontologie et qui

peuvent se rattacher au concept inséré.

2.4 Un système d’apprentissage

Durant le processus de description de schéma et de création de la vue unifiée, l’utilisateur-

concepteur intervient dans la validation des résultats et le choix des concepts décrivant les bases de

données. Il serait judicieux d’exploiter ces validations pour les utiliser dans les cas similaires. Nous

devrons donc définir un modèle d’apprentissage, qui dans les cas semblables, présente à l’utilisateur

en premier les informations déjà validées.

159

2.5 Interface de validation

Actuellement notre prototype ne présente pas à l’utilisateur d’interface lui permettant de

valider les règles de mapping lors de la création du schéma médiateur. Nous devons alors développer

cette interface et la rattacher au système d’apprentissage, permettant ainsi de garder trace des

différentes décisions de l’utilisateur.

2.6 Interface d’interrogation

Les requêtes envoyées à notre médiateur sont écrites en SQL. Nous devrons créer une

interface d’interrogation qui permette à l’utilisateur de créer sa requête en mode graphique. Il n’aura

plus à apprendre un langage de requêtes mais simplement à sélectionner les relations et attributs à

interroger.

160

CHAPITRE VII : Bibliographie [ALI 04] Alia, M., Collet, C., Lefebvre, A. Un Système d'intégration des données : Une approche à composants. Numéro spécial de la Revue des Sciences et Technologies de l'Information (STI), série L'objet, 2004. [en ligne] disponible sur <http://www.lifl.fr/jc2004/articles/alia-lefebvre-collet.pdf> [date de consultation : September 2004] [AMB 01] Ambite, J. L., Shahabi, C., Schmidt, R. R., Philpot A. Fast Approximate Evaluation of OLAP Queries for Integrated Satistical Data. In Proceedings of the First National Conference on Digital Government (dg.o 2001), Redondo Beach, May 2001. [en ligne] disponible sur <http://dimlab.usc.edu/DocsDemos/dgo2001.pdf> [date de consultation : Mai 2004] [AQU 02] Aquilina, J. M. MySQL : Aide mémoire. Edition. Paris : OEM-Eyrolles, 2002. 384 pages [ARE 97] Arens Y., Knoblock C. A., Hsu C.-N. Query Processing in the SIMS Information Mediator. In Michael N. Huhns and Munindar P. Singh, editors, Readings in Agents. San Francisco, CA, USA : Morgan Kaufmann, , 1997, p. 82-90. [ASH 99] Ashish, N., Knoblock, C. A., Shahabi, C. Selectively Materializing Data in Mediators by Analyzing User Queries. International Conference on Cooperative Information Systems, Edinburgh, Scotland, 1999 [en ligne] disponible sur http://citeseer.ist.psu.edu/ashish99selectively.html [date consultation 01/03/2003] [BAD 01] Badr, Y., Sayah, M., Laforest, F., Flory, A. Transformation rules from semi-structured XML documents to database model. In Proceedings of the ACS/IEEE International Conference on Computer Systems and Applications, Beirut, Lebanon. June 26-29, 2001, p.181-184 [BAD 03a] Badr, Y., Laforest, F., Flory, A. DRUID : coupling user written documents and databases. In Proceedings of the International Conference on Enterprise Information Systems (ICEIS), Angers, France, 2003, p. 191-196. [BAD 03b] BADR, Y. Etude d'un système d'alimentation automatique d'une base de données à partir de documents XML. Thèse de doctorat en informatique, Laboratoire LIRIS (INSA Lyon), soutenue en décembre 2003, 269 pages. [BAR 99] Baru, C., Gupta, A., Ludaescher, B., Marciano, R., Papakonstantinou, Y., Velikhov, P., Chu V. XML-Based Information Mediation with MIX. In Proceedings of ACM SIGMOD Conference on Management of Data, Philadelphia, Pennsylvania, June 1999, p. 540-543. [BAT 86] Batini, C., Lenzerini, M. and Navathe, S. B., A Comparative Analysis of Methodologies for Database Schema Integration, ACM Computing Surveys, December 1986, Vol. 18, Num. 4, p.323-364. [BEC 01] Bechhofer, S., Horrocks, I., Goble, C., Stevents, R. OilED: A Reasonable Ontology Editor for the Semantic Web. In Proceedings of the Joint Conference on Artificial Intelligence, German Austrian, 2001. Number 2174 in Lecture Notes In Artificial Intelligence, p. 396-408.

161

[BEC 02] Beck, H, Pinto, H. S. Overview of Approach, Methodologies, Standards, and Tools for Ontologies. 2002 [en ligne ]. Disponible sur <http://www.fao.org/agris/aos/Documents/BackgroundPaper.pdf>. [date de consultation : Sept 2003] [BEN 01] Beneventano, D., Bergamaschi, S., Guerra, F., Vincini, M. The MOMIS approach to Information Integration. IEEE and AAAI International Conference on Enterprise Information Systems, Setubal, Portugal, Juillet 2001 [en ligne] disponible sur <http://citeseer.ist.psu.edu/beneventano01momis.html> [date de consultation 20/04/2003] [BER 00] Bertino, E., Castano, S., Ferrari, E., Mesiti, M. Specifying and enforcing access control policies for XML document sources. In Journal World Wide Web 3, 2000, Vol. 3, Num. 3, p.139-151 [BER 01] Bergamaschi, S., Castano, S., Beneventano, D., Vincini, M. Semanitc integration of heterogenous information sources. Journal of Data and Knowledge Engineering, 2001, Vol. 36, Num. 3. p. 215-249 [BER 98] Bergamaschi, S., Castano, S., Vimeracati S.D.C.D., Vincini, M. An Intelligent Approach to Information Integration. In Proceedings of the International Conference on Formal Ontology in Information Systems (FOIS-98), Trento, Italy, 1998, p. 253-267. [BER 99a] Bergamaschi, S., Castano, S., Vincini, M., Beneventano D. Intelligent Techniques for the Extraction and Integration of Heterogeneous Information. IJCAI-99 Workshop on Intelligent Information Integration 31 July 1999, Stockholm. [en line] disponible sur http://www.dbgroup.unimo.it/prototipo/paper/ijcai99.pdf [date de consultation 20/04/2003] [BER 99b] Bergamaschi, S., Castano, S., Vincini, M. Semantic Integration of Semistructured and Structured Data Sources. SIGMOD Record, 1999, Vol. 28, Num. 1, p. 54-59. [BOU 00] Bourret, R. DTD Parser, Version 2.0, Disponible sur <http://www.rpbourret.com/schemas/index.htm> [Date de consultation : juin 2000] [BOU 01] Boumédiene, M. Etude de la construction automatique de modèles de document XML à partir d'un modèle de données. Mémoire de DEA, laboratoire LISI (INSA-LYON), soutenu le 12/07/2001, 27 pages. [BOU 04] Boumédiene, M. , Laforest, F. [en ligne] Contrôle d’accès aux documents XML en filtrant les DTDs. In Proceedings of the International Conference on Sciences of Electronic, Technology of Information and Telecommunications SETIT 2004, Sousse, Tunisie, 15-20 mars 2004. Disponible sur < http://liris.cnrs.fr/frederique.laforest/articles/SETITBoumedieneLaforest.pdf> [BOU 94] Bouaud, J., Bachimont, B., Charlet, J., Zweigenbaum, P. Acquisition And Structuring Of An Ontology Within Conceptual Graphs. In ICCS'94 Workshop on Knowledge Acquisition using Conceptual Graph Theory, University of Maryland, College Park, MD, 1994, p. 1-25. [BUG 97] Bugnion, E., Devine, S., Govil, K., and Rosenblum, M. Disco: Running Commodity Operating Systems on Scalable Multiprocessors. ACM Transactions on Computer Systems, November 1997, Vol. 15, Num. 4, p. 412-447.

162

[Car 95] Carey, M., Haas, L. Towards Heterogeneous Multimedia Information Systems: The Garlic Approach. In Proceedings of the International Workshop on Research Issues in Data Engineering: Distributed Object Management, Taipei, 1995, p. 124-131. [CAS 01] Castano, S., Bergamaschi, S., Vincini, M., Beneventano, D. Semantic integration of heterogeneous information sources. Data & Knowledge Engineering, 2001, Vol. 36, Num. 1, p. 215-249. [CAS 01b] Castano, S., De Antonellis, V., De Capitani diVemercati, S. Global viewing of heterogeneous data sources. In IEEE transactions on knowledge and data engineering, 2001, Vol. 13, Num. 2, p. 277–297. [CAS 97] Castano, S., De Antonellis, V. Semantic Dictionary Design for Database Interoperability. In Proceedings of the Thirteenth International Conference on Data Engineering, Heidelberg, Germany, 1997, p.43-54 [CAS 99] Castano, S., De Antonellis, V. A schema analysis and reconciliation tool environment. In Proceedings of the 1999 International Database Engineering and Applications Symposium (IDEAS'99), IEEE, Montreal, Canada, 1999, p. 53-62. [CAT 96] Cattell, R.G.G. The Object Database Standard : ODMG-93, San Francisco, CA : Morgan kaufman, 1996, 169p ( ISBN 1-558-60302-6) [CHA 96] Chaudhuri, S., Dayal, A. An Overview of Data Warehousing and OLAP Technology. Tutorial, In Proceedings of the 22th International Conference on Very Large Data Bases (VLDB'96), Mumbai, India, September 1996. [en ligne] disponible sur <http://www.cs.sfu.ca/CourseCentral/459/han/papers/chaudhuri97.pdf> [date de consultation 10/04/2003] [CLA 99] Clark, J., DeRose, S. XML Path Language (XPath) Version 1.0". [en ligne] World Wide Web Consortium (W3C), November 1999, disponible sur <http://www.w3c.org/TR/xpath> [Date de consultation : Juin 2003] [CLO 00] Cloudscape Documentation. Disponible sur <http://www.cloudscape.com/>, [Date de consultation : juin 2000] [COD 95 ] Cody, W., Haas, L., Niblack, W., Arya, M., Fagin, R., Flickner, M., Lee, D., Petkovic, D., Schwarz, P., Thomas, J., Tork Roth, M., Williams, J., Wimmers E. Querying Multimedia Data From Multiple Repositories By Content: The Garlic Project. In Proceedings of the IFIP Working Conference on Visual Database Systems, Lausanne, Switzerland, March 1995, p.17-35. [COH 03] Cohen, W., Ravikumar, P., Fienberg. S. A comparison of string metrics for matching names and records. [en ligne] In Proceedings of workshop on Data Cleaning and Object Consolidation at KDD, Washington, USA, 2003. Disponible sur <http://www-2.cs.cmu.edu/~wcohen/postscript/kdd-2003-match-ws.pdf> [date consultation : octobre 2004] [COT 93] Côté, RA., Rothwell, DJ., Palotay, JL., Beckett, RS., Brochu, L. , eds. The Systematised Nomenclature of Human and Veterinary Medicine: SNOMED International. College of American Pathologists, Northfield, 1993.

163

[DAM 00] Damiani, E., De Capitani di Vimercati, S., Paraboschi, S., Samarati, P. Securing XML Documents. In Proceedings of the 2000 Int'l Conference on Extending Database Technology (EDBT2000), Germany, March 27-31 2000. p.121-135 [DAM 01] Damiani, E., Samarati, P., De Capitani di Vimercati, S., Paraboschi S. Controlling Access to XML Documents. In IEEE Internet Computing, 2001, Vol. 5, Num. 6, p. 18-28. [Dev 02] Devignes MD, Schaaff A and Smaïl M (2002). Collecte et intégration de données biologiques hétérogènes sur le Web – Xmap : application dans le domaine de la cartographie du génome humain. In Revue des sciences et technologies de l’information (RSTI) – Série Ingéniérie des systèmes d’information (ISI), septembre, 2002, Vol. 7, p. 45-61. [DIE 04a] Dieng-Kuntz, R., Minier, D., Corby, F., Corby, O., Alamarguy, L., Luong, P.-H. Exploitation d'ontologies pour la gestion des connaissances et le travail collaboratif dans un réseau de soin. [En ligne] In deuxième Journée Web Sémantique Médical (WSM'2004), Rouen France, 2004. Disponible sur < http://www.chu-rouen.fr/l@stics/wsm2004/Dieng.rtf> [date de consultation : Sept 2003] [DIE 04b] Dieng-Kuntz, R., Minier, D., Corby, F., Corby, O., Alamarguy, L., Luong, P.-H. Ontologie Médicale et Staff Virtuel pour un Réseau de Soins. In Actes des 15èmes journées francophones d'Ingénierie des Connaissances (IC'2004), Lyon, 2004, p. 17-28. [DOA 00] Doan, AH., Domingos, P., Levy, A. Learning source descriptions for data integration. In Proceedings of the International Workshop on The Web and Databases (WebDB), Dallas, Texas, USA, 2000, p. 81–92. [DOA 01] Doan, AH., Domingos, P., Halevy, A. Reconciling schemas of disparate data sources: a machine-learning. SIGMOD Record, 2001, Vol. 30, Num. 2, p. 509-520. [DOA 02] Doan, A. Learning to Map between Structured Representations of Data. Thèse de doctorat en informatique, Université de Washington, 2000, 133 pages. [DOH 02] Do, H., Melnik, S., Rahm, E. Comparison of schema matching evaluations. [en ligne] In Proceedings of the 2nd International Workshop on Web Databases, Erfurt, Germany, 2002. Disponible sur < http://www.old.netobjectdays.org/pdf/02/papers/ws-webdb/02-Do.pdf>, [date consultation Mai 2003] [FLO 95] Florescu D., Raschid L., Valduriez P. Using Heterogeneous Equivalences for Query Rewriting in Multidatabase Systems. In Laufmann S., Spaccapietra S., Yokoi T. Eds., Proceedings of the Third International Conference on Cooperative Information Systems (CoopIS- 95), Vienna, Austria, May 1995. p. 158-169. [FLO 96] Florescu D., Raschid L., Valduriez P. A Methodology for Query Reformulation in CIS Using Semantic Knowledge. International Journal of Cooperative Information Systems (IJCIS), 1996, Vol. 5, Num. 4, p. 431-468. [GAB 01a] Gabillon, A., Bruno, E. Regulating Access to XML documents. In Proceedings of the 15th Annual IFIP 11.3 Working Conference on Database Security , Niagara on the Lake, Ontario, Canada , July 2001 , p. 311-328

164

[GAB 01b] Gabillon, A., Bruno, E. Contrôles d'accès pour documents XML. [en ligne ] In Proceedings of the Dix-septième Journées Bases de Données Avancées(BDA'2001). Agadir, Maroc, 29 octobre - 2 novembre 2001. Disponible sur < http://www.univ-pau.fr/~gabillon/articles/bda01.pdf> [Date de consultation : juillet 2003] [GAB 02] Gabillon, A., Munier, M., Bascou, J.-J., Gallon, L., Bruno, E. An Access Control Model for Tree Data Structures. In Proceedings of the 5th International Information Security Conference (ISC 2002) , Sao Paulo, Brazil, September-October 2002, p. 117-135 [GAN 96] Gangemi, A., Steve, G., Giancomelli, F. ONIONS: An Ontological Methodology for Taxonomic Knowledge Integration. [En ligne] In Van der Vet, P. eds. Proceedings of the Workshop on Ontological Engineering, ECAI96, Budapest, 1996. Disponible sur < http://citeseer.ist.psu.edu/cache/papers/cs/24114/http:zSzzSzwwwkbs.cs.utwente.nlzSzEcaiWorkshopzSz.zSzgangemi-final.pdf/gangemi96onions.pdf >, [Date de consultation : Juin 2003] [GAN 98] Gangemi, A., Pisanelli, D., Steve, G. Ontology Integration: Experiences with Medical Terminologies. In Proceedings of the 1st International Conference on Formal Ontology in Information Systems, FOIS'98, Trento, Italy, 1998, p. 163-178. [GAN 99] Aldo Gangemi, Domenico M. Pisanelli, and Geri Steve. An overview of the ONIONS project: Applying ontologies to the integration of medical terminologies. In Journal of Data and Knowledge Engineering, sept 1999, Vol. 31, Num. 2, p. 183–220 [GAR 97] Garcia-Molina H., Papakonstantinou Y., Quass D., Rajaraman A., Sagiv Y., Ullman J. D., Vassalos V., Widom J. The TSIMMIS Approach to Mediation: Data Models and Languages . In Journal of Intelligent Information System. 1997, Vol. 8, Num. 2, p. 117-132 [GAR 99] Gardarin, G., Sha F., Dang Ngoc, T. XML-based Components for Federating Multiple Heterogeneous Data Sources. In Proceeding of the 18th Int. Conf. On Conceptual Modeling, Paris, France, Nov. 1999, p. 506-519. [GEN 92] Genesereth, M., Fikes, R. Knowledge Interchange Format (Version 3.0) - Reference Manual, [en ligne] in Technical Report Logic-92-1, Computer Science Department, Stanford University, 1992. Disponible sur <http://www-ksl.stanford.edu/knowledge-sharing/kif/> [date de consultation : Juin 2004] [GEN 97a] Genesereth, M. R., Keller, A. M., Duschka O. Infomaster: An Information Integration System. In Peckham J. Eds., Proceedings ACM SIGMOD International Conference on Management of Data . ucson, Arizona, USA, ACM Press, May 1997, p. 539-542. [GIU 04a] Giunchiglia, F., Shvaiko, P., Yatskevich, M. S-Match: an algorithm and an implementation of semantic matching. In Proceedings of the 1st european semantic web symposium (ESWS'04), Heraklion, grece, 10-12 May, 2004, p. 61–75 [GMP 97] Garcia-Molina, H., Papakonstantinou, Y., Quass, D. The TSIMMIS Approach to Mediation : Data Models and Languages. In Journal of Intelligent Information System. 1997, Vol.. 8, Num. 2, p. 117-132. [GOA 98] Goasdoué F. “Assistance à la conception de bases de connaissances dédiées au médiateur PICSEL”, Mémoire de D.E.A. d’informatique, Université Paris 11, Sept. 1998, 77 pages.

165

[GOA 99] Goasdoue, F., Reynaud, C. Modeling information sources for information integration. In Fensel, D., Studer, R. Editors, Knowledge Acquisition, Modeling and Management, Lecture Notes in Artificial Intelligence, Berlin. Springer, 1999, p. 121-138. [GON 97] Goni, A., Mena, E., Illarramendi A. Querying Heterogeneous and Distributed Data Repositories using Ontologies. [en ligne] In proceedings of the 7th European-Japanese Conference on Information Modelling and Knowledge Bases(IMKB’97), Toulouse (France), May 1997. Disponible sur <http://sid.cps.unizar.es/PUBLICATIONS/POSTSCRIPTS/imkb97.ps.gz> [date de consultation : Mai 2002] [GRU 92] Gruber, T. R.: ONTOLINGUA: A Mechanism to Support Portable Ontologies, Technical Report KSL 91-66, Knowledge System Laboratory, Stanford University, 1992, 61 pages. [GRU 93] Grubber, T. A Translation Approach to Portable Ontology Specifications. In Knowledge Acquisition, An International Journal of Knowledge Acquisition for KnowledgeBased Systems, 1993, Vol. 5, Num. 2, p. 199-220. [GUH 99] Gu, H., Perl, Y., Geller, J., Halper, M. & Singh, M. (1999). A methodology for partitioning a vocabulary hierarchy into trees. In Journal of the Artificial Intelligence in Medicine, Janvier 1999, Vol. 15, Num. 1, p. 77-98.

[GUI 04b]. Giunchiglia, F., Yatskevich, M. Element level semantic matching. In Proceedings of the Workshop Meaning Coordination and Negotiation at 8th ISWC, Hiroshima, Japan, November 2004, p 37-48. [HAA 99] Haas, LM., Miller, RJ., Niswonger, B., Roth, T., Schwarz, PM., Wimmers, EL. Transforming heterogeneous data with database middleware: beyond integration. In IEEE Data Engeneering, bulletin, 1999, Vol. 22, Num. 1, p. 31-36. [HAK 01] Hakimpour, F., Geppert, A. Resolving Semantic Heterogeneity in Schema Integration: an Ontology Based Approach, In Proceedings of the International Conference on Formal Ontology in Information Systems (FOIS-01), Ogunquit, Maine, USA, 2001, p. 297-308. [HUM 92] Humphreys, BL., Lindberg, DAB. The Unified Medical Language System PROJECT: A distributed experiment in improving access to biomedical information. In Lun, KC, Degoulet, P., TEPiemme, Rienhoff, O. eds. In Proceedings of MEDINFO-92. Amsterdam, North Holland. 1992, p. 1496-1500. [IVE 99] Ives, Z., Florescu, D., Friedman, M., Levy, A., Weld. D. An adaptive query execution engine for data integration. In Proceedings of the ACM SIGMOD International Conference on Management of Data, Philadelphia, PA, June 1999, p. 299-310. [JAK 97] Jakobovits., R., Integrating autonomous heterogeneous information sources. Technical report, [en ligne] Computer Science Department, University of Washington, July 1997. Disponible sur <http://citeseer.nj.nec.com/jakobovits97integrating.html> [date de consultation : Mai 2004] [JFB 01] BELLET, J.-F. Etude, conception et réalisation d'un système alliant interface documentaire et base de données dans une architecture à base de composants. Mémoire de fin d’étude pour

166

l’obtention du diplôme d'Ingénieur CNAM en Informatique 2001. Date de soutenance Décembre 2001, 97 pages. [LAF 01a] Laforest, F., Flory, A. Using Weakly-Structured Documents to Fill in a Classical Database. In Journal of Database Management, Idea Group Publishing, Apr-Jun 2001, p.3-13 [LAF 01b] F. Laforest, A. Flory Using Weakly Structured Documents at the User-Interface Level to Fill in a Classical Database. In K. Siau (ed.), Advanced Topics in Database Research, Hershey, PA : Idea Group Publishing, 2002, Vol. 1, p.190-210. [LAF 03] Laforest, F., Boumédiene, M. Study of the automatic construction of XML documents models from a relational data model. [en ligne] In Proceedings of the WebS 2003 Workshop, IEEE publication, Prague, Sept 2003. Disponible sur < http://liris.cnrs.fr/frederique.laforest/articles/webS2003.pdf> [Date de consultation : sept 2003] [LAS 99] Lassila, Swick, R.R. Resource Description Framework (RDF) model and syntax specification, W3C Recommendation, February 22, 1999. Disponible sur <http://www.w3.org/TR/REC-rdf-syntax> [LCL 00] Li, W., Clifton, C., Liu, S. Database integration using neural network: implementation and experience. In Knowledge and Information Systems. 2000, Vol. 2, Num. 1, p. 73-96. [LCW 94] Li, W., Clifton, C. Semantic integration in heterogeneous databases using neural networks. In Proceedings of the Conference on Very Large Databases (VLDB), Santiago de Chile, Chile, 1994. p. 1–12 [LEV 00] Levy, A.Y. Logic-based techniques in data integration. In Jack Minker, editor, Logic Based Artificial Intelligence. Boston : Kluwer Academic Publisher, 2000. p. 575-595 [LEV 95] Alon Y. Levy, Divesh Srivastava, and Thomas Kirk. Data model and query evaluation in global information systems. In Journal of Intelligent Information Systems. 1995, Vol. 5, Num 2, p. 121-143. [LEV 96] Levy A. Y., Rajaraman A. et Ordille J., Querying Heterogeneous Information Sources Using Source Descriptions. In Proceedings of the 22th International Conference on Very Large Data Bases (VLDB 96), Bombay (India), September 1996, p. 251-262. [LEV 98] Levy, A., Rousset, M.C. “Combining Horn Rules and Description Logics in CARIN”, In Artificial Intelligence Journal, September 1998, Vol. 14, p. 165-209. [LIC 98] Li, C., Yerneni, R., Vassalos, V., Garcia-Molina, H., Papakonstantinou, Y., Ullman, J. D., Valiveti, M. Capability Based Mediation in TSIMMIS . In Haas L. M., Tiwary A. Eds, In Proceedings of the ACM SIGMOD International Conference on Management of Data, Seattle, Washington, USA, June 1998, p. 564-566. (ISBN 0-89791-955-5). [LIW 00] Li, W., Clifton, C. SemInt: A Tool for Identifying Attribute Correspondences in Heterogeneous Databases Using Neural Network. In Data and Knowledge Engineering, Avril 2000, Vol. 33, Num. 1, p.49-84.

167

[LIW 94] Li, W., Clifton, C. Semantic integration in heterogeneous databases using neural networks. In Proceedings of the 20th International Conference On Very Large Data Bases (VLDB), Santiago, Chile, 1994, p. 1-12. [LOI 04] A Healthcare Laboratory and a Community of Scholars, Logical Observation Identifiers Names and Codes [en ligne ]. Disponible sur <http://www.regenstrief.org/loinc/> [date de consultation : Juillet 2004] [LRO 96] Levy, A. Y., Rajaraman, A., Ordille, J. J. Query-answering algorithms for information agents. In Proceedings of the National Conference on Artificial Intelligence (AAAI), Portland, Oregon, Aout 1996. Vol. 1, p. 40-47. [LUD 99] Ludäscher E., Papakonstantinou Y., Velikhov P. A Framework for Navigation- Driven Lazy Mediators . In Proceedings of the ACM SIGMOD Workshop on The Web and Databases Philadelphia, Pennsylvania, USA. June 1999, p. 85-90. [MAC 91] MacGregor, R.M. Using a description classifier to enhance deductive inference. In Proceedings of the Seventh IEEE Conference on AI Applications, Miami, Florida, 1991, p.141–147. [MAD 00] Madhavan, J., Bernstein, P.A., Rahm, E. Generic Schema Matching with Cupid. In Proceedings of the 27th International Conference On Very Large Data Bases (VLDB), Roma, Italy, 2001, p.49 - 58 [MCB 03] McBrien, P., Poulovassilis, A. Data integration by bi-directional schema transformation rules. In Proceedings of the 19th International Conference on Data Engineering, ICDE'03, 5-8 March 2003, p 227-238 [Med 97] Medicomp Systems. MEDCIN. [en ligne ]. Disponible sur <http://www.medicomp.com/highbandwidth.htm>. [date de consultation : Sept 2003] [MEN 00] Mena, E., Kashyap, V., Sheth, A. Illarramendi, A. OBSERVER: An Approach for Query Processing in Global Information Systems based on Interoperation across Pre-existing Ontologies. In International journal Distributed and Parallel Databases, Avril 2000, Vol. 8, Num. 2, p. 223-271 [Men 96a] Mena, E., Kashyap, V., Sheth, A., Illarramendi, A. OBSERVER: An Approach for Query Processing in Global Information Systems based on Interoperation across Pre-existing Ontologies. In Proceedings of the First IFCIS International Conference on Cooperative Information Systems (CoopIS'96), Brussels, Belgium, 1996. p. 14-25. [Men 96b] Mena, E., Kashyap, V., Sheth, A. Illarramendi, A. Managing Multiple Information Sources through Ontologies : Relationship between Vocabulary Heterogeneity and Loss of Information.In Proceedings of Knowledge Representation Meets Databases (KRDB'96), ECAI'96 conference, Budapest, Hungary, August 1996, p. 50-52. [MIC 00] Michiharu, K., Satoshi, H. XML Document Security based on Provisional Authorization. In Proceedings of the 7th ACM Conference on Computer and Communications Security, Athens Greece, Nov 2000, p. 87-96 [MIL 00] Miller, R., Haas, L., Hernandez, M. Schema mapping as query discovery. In Proceedings of the 26th International Conference on Very Large Data Bases (VLDB 2000), Cairo, Egypt, 2000, p. 77-88.

168

[MIL 01] Miller, R. The Clio project: managing heterogeneity. In ACM SIGMOD Record, 2001, Vol. 30, Num. 1, p. 78-83. [MIL 95] Miller, A.G. Wordnet: A lexical database for english. In Communications of the ACM, 1995, p. 39–41, Vol. 38, Num. 11. Disponible sur : <http://www.cogsci.princeton.edu/~wn/> [Date de consultation : Juillet 2004] [MIL 98] Milo, T., Zohar, S. Using schema matching to simplify heterogeneous data translation. In Proceedings of the 24th International Conference on Very Large Databases (VLDB), New York, USA,1998, p.122–133 [NAA 99] Hubert Naacke, "Modèles de coût pour médiateurs de bases de données" , PhD. Thesis , Université de Versailles-Saint Quentin , Septembre, 1999, 151 pages [PAP 95] Papakonstatniou, Y., Garcia-Molina, H., Widom, J. Object exchange across heterogeneous information sources. In Proceedings of the 11th International Conference on Data Engineering, Taipei, 1995, p. 251-260. [PIS 99] Pisanelli, DM., Gangemi, A., Steve, G.A Medical Ontology Library that Integrates the UMLS Metathesaurus. In Proceedings of the Joint European Conference on Artificial Intelligence in Medicine and Medical Decision Making, AIMDM 99, Denmark, June 20-24, 1999. [POP 02] Popa, L., Velegrakis, Y., Hernandez, M., Miller, R. J., Fagin R. translating web data. In Proceedings of the 28th International Conference on Very Large Data Bases (VLDB 2002), Hong Kong SAR, China, 2002, p. 598-609. [RAH 01a] Rahm, E., Bernstein, P. A. On Matching Schemas Automatically. In The VLDB Journal, Dec. 2001, Vol. 10, Num. 4, p. 334-350. [RAH 01c] Rahm, E., Bernstein, P. A. A survey of approaches to automatic schema matching. In VLDB Journal, 2001, Vol. 10, Num. 4, p. 334-350. [REC 92] Rector, AL, Nowlan, WA, Kay, S. Conceptual knowledge: the core of medical information systems. In Lun, K., Degoulet. P., Pierre, T., Rienhoff, O., Eds. In Seventh World Congress on Medical Informatics, MEDINFO-92. Geneva: North-Holland Publishers, 1992, p.1420-1426. [REC 93] Rector, A., Nowlan, W., Glowinski, A. Goals for concept representation in the GALEN project. In Safran, C. eds. Proceedings of the 17th Annual Symposium on Computer Applications in Medical Care, Washington, DC. New York : McGraw-Hill, 1993, p. 414-418. [REC 94] A. Rector, W. Solomon, W. Nowlan, and T. Rush. A terminology server for medical language and medical information systems. In Methods of Information in Medicine (1995). First published in the Proceedings of IMIA WG6, Geneva, May 1994, p.147-157. [REE 98] Reese, G. JDBC et Java : Guide du programmeur. Edition Paris : O'Reilly, 1998. 203 pages.

169

[ROU 02] Rousset, M.C., Safar, B. Construction de Médiateurs pour Intégrer des Sources d'Information Multiples et Hétérogènes : le Projet PICSEL. In Journal I3 : Information - Interaction - Intelligence, France : 2002, Vol. 2, Num. 1, p. 9-59. [ROU 04] Rousset M. C., Reynaud, C. Knowledge Representation for Information Integration. In Information Systems International Journal, 2003, Vol. 29, Num. 1, p. 3-22 . [SAU 03] Saumont, P.-Y., Mirecourt, A. Le guide du développeur Java 2 : meilleures pratiques avec Ant, JUnit et les design patterns 5e éd. Edition. Paris : Eyrolles, 2003. 781 pages [SHE 90] Sheth, S.P. and J.A. Larson (1990), Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases. In ACM Computing Surveys, Sept 1990, Vol. 22, Num. 3, p. 183-236 [SHV 04] Shvaiko, P., Euzenat, J. A Survey of Schema-based Matching Approaches. [En igne] Technical Report # DIT-04-087, Department of Information and Communication Technology, University of trento, Italie, 2004, 22 p. Disponible sur <http://dit.unitn.it/~pavel/Publications/SurveyShvaikoEuzenat.pdf> [Date de consultation : Avril 2005] [SIM 04] Simonet, M., Bernard, D., Diallo, G., Palmer, P., Ferriol, S., Baldesare, F., Cool, H., Dhaen, C. Enrichissement d'une Ontologie multilingue à partir de textes pour le cancer du sein. [en ligne] In deuxième Journée Web Sémantique Médical WSM'04, Rouen France, Mars 2004. Disponible sur <http://www.chu-rouen.fr/l@stics/wsm2004/Simonet.doc> [date de consultation : Sept 2003] [STE 97] Steve, G., Gangemi, A., Pisanelli, D.M. Integrating Medical Terminologies with the ONIONS Methodology. [en ligne] In Kangassalo, H., Charrel, J.P., eds. In Information Modelling and Knowledge Bases VIII (IOS Press,) Amsterdam, 1997. Disponible sur < http://citeseer.ist.psu.edu/cache/papers/cs/20800/http:zSzzSzsaussure.irmkant.rm.cnr.itzSzontozSzpublzSzonions97zSzonions97.pdf/steve97integrating.pdf> [Date de consultation : Juin 2003] [TOM 96 ] Tomasic, A., Raschid, L., Valduriez, P. Scaling heterogeneous databases and the design of disco. [en ligne] In Proceedings of the International Conference on Distributed Computer Systems, Hong Kong, 1996, Disponible sur < http://citeseer.ist.psu.edu/tomasic96scaling.html> [Date de consultation : Avril 2003] [TOR 97] Tork Roth M., Schwarz. P. Don't Scrap it, Wrap it! A Wrapper Architecture for Legacy Data Sources. In Proceedings of the 23rd International Conference on Very Large Data Bases, Athens, 1997. p. 266- 275. [USC 96] Uschold, M., Gruninger, M. Ontologies: principles, methods and applications. IN Knowledge Engineering Review, juin 1996, Vol. 11, Num. 2, p. 93-155. [VAL 97] Valtchev, P., Euzenat, J. Dissimilarity measure for collections of objects and values. In Proceedings of the Second International Symposium on Advances in Intelligent Data Analysis, Reasoning about Data, Londres, Angleterre, 1997, P. 259 - 272 [VAL 99] Valtchev. P. Construction automatique de taxonomies pour l’aide à la représentation de connaissances par objets. Thèse en informatique, Université Grenoble 1, 1999, 292 pages.

170

[VIS 98] Visser, R.S., Jones, D.M., BenchCapon, T.J.M., Shave, M.J.R. Assessing Heterogeneity by Classifying Ontology Mismatches. In Guarino, N. Proceedings of 1st International Conference on Formal Ontologies in Information Systems, FOIS'98, Trento, Italy, June 1998, p. 148-162 [W3C 99] World Wide WEB. http://www.w3c.org/RDF [W3C 01] XML Schema Disponible sur <http://www.w3.org/XML/Schema> (2 May 2001) [date de consultation : Sept 2002] [W3C 98] Extensible Markup Language (XML) Disponible sur <http://www.w3.org/XML/> Depuis le 10 février 1998 modifié le 07/04/2005 [date de consultation : janvier 2001] [WEI 99] WEILL, A. Etude d’un système d’alimentation d’une base de données relationnelle à partir d’une base de documents semi-structurés. Mémoire de DEA, laboratoire LISI (INSA-LYON), soutenu le 13/07/1999, 42 pages. [WEL 98] Welty, C. The Ontological Nature of Subject Taxonomies. In Proceedings of 1st International Conference on Formal Ontologies in Information Systems, FOIS'98, Trento, Italy, 1998, p. 317-327. [WIE 92] G. Wiederhold. "Mediators in the Architecture of Future Information Systems." In the IEEE Computer Magazine, Mar. 1992. p. 38-49. [WIE 94] Wiederhold G. Interoperation, Mediation, and Ontologies . In Proceedings of the International Symposium on Fifth generation Computer Systems (FGCS94), Workshop on heterogeneous Cooperative Knowledge-Bases, Tokyo, Japan. December 1994, p. 33-48. [XME 02] Intégrer vos données avec XML :E-XMLMEDIA. [en ligne] disponible sur <www.e-xmlmedia.fr/Pres.%20offre%20e-XMLMedia.pdf> [Date de consultation : Octobre 2003] [YAN 01] Yan, L.L., Miller, R.J., Haas, L.M., Fagin, R. Data driven understanding and refinement of schema mappings. In Proceedings of the 2001 ACM SIGMOD international conference on Management of data, Santa Barbara, California, United States, 2001, p. 485 – 496. [YAT 03] Yatskevich, M. Preliminary Evaluation of Schema Matching Systems Technical Report DIT-03-028, Department of Information and Communication Technology, Trento (Italy), 2003, 14 13 p. Disponible sur <http://citeseer.ist.psu.edu/rd/0%2C584210%2C1%2C0.25%2CDownload/http://citeseer.ist.psu.edu/cache/papers/cs/27669/http:zSzzSzeprints.biblio.unitn.itzSzarchivezSz00000422zSz01zSz028.pdf/yatskevich03preliminary.pdf> [Date de consultation : Avril 2005] [ZAP 97] Zapletal, E., Sauquet, D., Degoulet, P. Exemples de projets de recherche dans le domaine de l’interopérabilité. In Degoulet, P., Fieschi, M. (Eds). L’interopérabilité des systèmes d’information de santé, Aspects syntaxiques et sémantiques. Paris : CNEH-CIHS, 1997, p. 41-111. [ZOH 97] Zohar, S. Schema-based data translation. Thèse de doctorat en informatique, Université Tel-Aviv, 1997, 77 pages.

171

172

ANNEXES

Annexe A : Algorithme (Description des bases de données Document XML)

Descrip_BD (BDD)

Var OV : Ontologie de valeurs,

OS : Ontologie de structure,

DTDdoc : DTD du document,

BDD : Base de données,

R : Relation,

Att : Attribut,

Debut

{Créer un document XML, porte le nom de la base de données à décrire et est conforme à la

DTD DTDdoc}

Creat_DocXML (BDD.nomBD, DTDdoc);

Tant que I<= (BDD.size()) faire

Debut

R=Lire_Relation(BDD(I)) ;

{Recherche dans l’ontologie de structure les concepts correspondant à la relation R}

List_Concept = Recherche_concept_corresp (OS, R.nom) ;

{Comparer le contenu de la relation avec celui de l’ontologie de valeurs}

result_cont = Comparer_contenu(R, OV) ;

{Récupère la description de la relation à partir du dictionnaire de données de la base de

données}

Desc = Descrip_Relation(BDD.dictionnaire, R) ;

Si (List_Concept <> null) Alors

Debut

Afficher (List_Concept) ;

Concept_Rel = Choix(Utilisateur) ;

{Un élément XML décrivant la relation R est inséré dans le document XML. Cet élément est

composé du nom de la relation, du concept la décrivant ainsi que de sa description}

173

Modif_ DocXML(R.nom, Concept_Rel, Desc) ;

Fin

Sinon Debut

{l’utilisateur recherche manuellement dans l’ontologie OS le concept correspondant à la

relation R}

Concept_Rel = Recherche_manuelle(OS) ;

Si (Concept_Rel = Null)

Debut

{L’utilisateur insère dans l’ontologie de structure le concept correspondant à la

relation R}

Saisir_concept(OS) ;

Fin

Fin

{Traitement des attributs}

J=0 ;

Tant que J<= (R.size()) faire

Debut

Att=Lire_Attribut (R(J)) ;

{Traitement des attributs identifiants}

Si Att.id()

Debut

{Recherche dans l’ontologie de structure les concepts correspondant à l’attribut Att}

List_Concept = Recherche_concept_corresp (OS, Att.nom) ;

Si (List_Concept =null) alors Concept_att=Att.nom ;

{Comparer le contenu de l’attribut avec celui de l’ontologie de valeurs}

result_cont = Comparer_contenu(Att, OV) ;

{Récupère la description de l’attribut à partir du dictionnaire de données de la base de

données}

Desc = Descrip_Relation(BDD.dictionnaire, Att) ;

Afficher (List_Concept) ;

Concept_Att = Choix(Utilisateur) ;

{Un élément XML décrivant l’attribut Att est inséré dans le document XML. Cet

élément est composé du nom de l’attribut, du concept le décrivant ainsi que de sa description}

174

Modif_ DocXML(R.nom, Att.nom, Concept_Att, Desc) ;

{Un élément XML CleP contenant les identifiants de la relation R est inséré dans le

document XML}

Modif_ DocXML(Att.nom, Clep, R.nom) ;

Fin

Fin

{Traitement des attributs non identifiants}

Sinon

Debut

{Recherche dans l’ontologie de structure les concepts correspondant à l’attribut Att }

List_Concept = Recherche_concept_corresp (OS, Att.nom) ;

{Comparer le contenu de l’attribut avec celui de l’ontologie de valeurs}

result_cont = Comparer_contenu(Att, OV) ;

{Récupère la description de l’attribut à partir du dictionnaire de données de la base de

données}

Desc = Descrip_Relation(BDD.dictionnaire, Att) ;

Si (List_Concept <> null) Alors

Debut

Afficher (List_Concept) ;

Concept_Att = Choix(Utilisateur) ;

{Un élément XML décrivant l’attribut Att est inséré dans le document XML. Cet élément est

composé du nom de l’attribut, du concept le décrivant ainsi que de sa description}

Modif_ DocXML(Att.nom, Concept_Att, Desc) ;

Fin

Sinon Debut

{L’utilisateur recherche manuellement dans les concepts composant le concept

(concept_Rel) décrivant la relation, le concept correspondant à l’attribut }

Concept_Att = Recherche_manuelle(Concept_Rel, OS) ;

Si (Concept_Att = Null)

Debut

{L’utilisateur recherche manuellement dans toute l’ontologie de structure, le

concept correspondant à l’attribut Att}

Concept_Att = Recherche_manuelle(OS) ;

Fin

175

Si (Concept_Att = Null)

Debut

{L’utilisateur insère dans l’ontologie de structure le concept correspondant à

l’attribut Att }

Saisir_concept(OS) ;

Fin

Fin

J=J+1

Fin

{Fin traitement des attributs}

I=I+1 ;

Fin

{ Traitement des « References » }

K=0 ;

Tant que K<= (BDD.size()) faire

Debut

R=Lire_Relation(BDD(K)) ;

{Récupérer les noms des relations où a été exportée la clé primaire de R}

List_Nom_Rel =Recherche_exporte (R.nom, R.clep) ;

{Un élément XML References contenant les noms des relations où a été exportée la clé

primaire de R est inséré dans le document XML}

Modif_doc_xml( R.nom, References, List_Nom_Rel);

K=K+1 ;

FIN

{FIN Traitement des « References » }

FIN Descrip_BD

176

Annexe B : Algorithme (Génération du schéma médiateur et des règles de mapping)

Gener_Schema ()

DEBUT

{Traitement des concepts dérivant les relations}

{Récupérer la liste des concepts ListConcept contenues dans un des documents XML décrivant

une base de données à intégrer}

ListConcept = Lire_list_Conc(Doc 0) ;

I=0 ;

Tant que I<= (ListConcept.size()) faire Debut {Initialisé la liste des relations équivalentes et des mapping}

ListR_Equiv = {};

ListMap = {}

ConceptR= ListConcept.getConcept(i) ; {Extraire l’élément XML ELXML dont le nom est Concept, à partir du document Doc 0}

ELXML = Recup_EL_Concept(Doc 0, ConceptR)

{Récupérer le nom de la relation R décrite par le concept ci-dessus }

R = ELXML.Relation.nom

{La variable Map contient le lien entre la relation source et celle du schéma médiateur} Map.nomBD = Recup_nom_BD(Doc 1) ; Map.nomRel = R.nom ; {ListMap contient les correspondances entre la relation source et celles du schéma médiateur} ListMap = ListMap + Map;

ListR_Equiv = ListR_Equiv+R ;

J=1 ;

Tant que J<= (List_Document.size()) faire Debut

Ouvrir_doc_XML(Doc J) ;

Map.nomBD = null ; Map.nomRel = null ; ListMap = ListMap + Map; SI Existe_EL(ConceptR, Doc J) alors

{Cette fonction vérifie l’existence d’un élément XML contenant le concept ConceptR

décrivant une relation quelconque}

Debut

177

{Récupérer à partir de document Doc J l’élément XML ELXML2 contenant le

concept Concept_R décrivant une relation R2}

ELXML2 = Recup_EL_Concept(ConceptR, Doc J)

Rj = ELXML2.Relation.nom ;

{Rj est la relation équivalente à R et décrite par le même concept}

ListR_Equiv = ListR_Equiv+Rj ;

Map.nomBD = Recup_nom_BD(Doc J) ; Map.nomRel = Rj.nom ;

Fin

ListMap = ListMap + Map; J=J+1 ;

Fin

RMed = New_Rel_Med (ConceptR); {Création de la relation du schéma médiateur}

RMapping = New_Lien_Med (ListMap); {Création de la règle de mapping}

{Insertion de la relation dans le document contenant le schéma médiateur}

Modif_Doc_Med(RMed);

{Insertion de la règle de mapping dans le document contenant les correspondances}

Modif_Doc_Mapp(RMapping);

{Traitement des attributs}

K=0 ;

ListeConcept_Att = ELXML.getlistAttribut() ;

Tant que K<= (ListeConcept_Att.size()) faire Debut

ListAtt_Equiv = {}; {initialisé la liste des attributs équivalents et des correspondances}

ListMapAtt = {} ;

ConceptAtt = ListeConcept_Att.getAttribut(K) ; {Extraire l’élément XML ELXMLAtt qui porte le nom du concept ConceptAtt }

ELXMLAtt = Recup_EL_Att(Doc 0, ConceptR, ConceptAtt) ;

{Récupérer le nom de lattribut décrit par ConceptAtt}

Attrib = ELXMLAtt.Attribut.nom ;

{La variable Map contient le lien entre l’attribut source et celui du schéma médiateur} Map.nomBD = Recup_nom_BD(Doc 0) ; Map.nomRel = R.nom ; Map.nomAtt = Attrib.nom ; {ListMap contient les correspondances entre l’attribut source et ceux du schéma médiateur} ListMap = ListMap + Map;

ListAtt_Equiv = ListAtt_Equiv+Att ;

J=1 ;

178

Tant que J<= (List_Document.size()) faire Debut

Ouvrir_doc_XML(Doc J) ;

Map.nomBD = null ; Map.nomRel = null ; Map.nomAtt = null ; ListMap = ListMap + Map; {Vérifie si la BDD j contient le concept ConceptR } Si Existe_Concept(ConceptR, Doc J) Debut {Vérifie le concept ConceptAtt existe dans le document, et s’il est contenu dans l’élément

ConceptR}

SI Existe_EL_Att (ConceptAtt, ConceptR, Doc J) alors

Debut

ELXML2 = Recup_EL_Concept(ConceptAtt, ConceptR, Doc J)

{Récupérer à partir de document Doc J l’élément XML ELXML2 dont le nom est

ConceptAtt}

Attj = ELXML2.Attribut.nom ; {Attj est l’attribut équivalent à Atrib }

ListAtt_Equiv = ListAtt_Equiv+Attj ;

Map.nomBD = Recup_nom_BD(Doc J) ; Rj=ListR_Equiv.get(J); Map.nomRel = Rj.nom ; Map.nomAtt = Attj.nom ;

Fin

ListMap = ListMap + Map; Fin

J=J+1 ;

Fin

AttMed = New_Att_Med (ConceptAtt); {Création de l’attribut du schéma médiateur}

RMappingAtt = New_Lien_Med (ListMap); {Création de la règle de mapping}

{Insertion de l’attribut AttMed dans la relation du schéma médiateur}

Modif_Doc_Med(RMed, AttMed);

Modif_Doc_Mapp(RMapping, RMappingAtt); {Modification des correspondances}

K=K+1 ; Fin

I=I+1 ;

{Traitement des liens}

{Récupérer la liste des relations du schéma médiateur}

179

ListRMed = Lire_list_Rel(Doc_Med);

F=0 ;

Tant que F<= (ListRMed.size()) faire

Debut RMed= ListRMed.getRelation(F) ; {Récupérer à partir du document contenant les règles de Mapping, la liste des relations

équivalentes RMed}

ListEquiv=Recup_RgMapp(Doc_Mapp, RMed);

L=0 ; Tant que L<= (ListEquiv.size()) faire

Debut {Rechercher le nom d’une des relations équivalentes} R= ListEquiv.getRelation(L) ; {Extraire l’élément XML décrivant la relation R}

ELXML = Recup_EL_Rel(Doc L, R) ;

{ListRel_Liée est la liste des noms des relations où la clé primaire de R a été exportée}

ListRel_Liée = ELXML.Refrences ;

{A partir des règles de mapping, recherche la liste des relations ListRMed_Liée

équivalente à celle de ListRel_Liée }

ListRMed_Liée = Recup_Rel_Equiv(ListRelLiée, Doc_Mapp) ;

{Exporter la clé primaire de la relation RMed dans les relations ListRMed_Liée}

Export_Clep_RMed(RMed, ListRMed_Liée);

{Mettre à jour le documents contenant le schéma médiateur et les règles de mapping}

Modif(Doc_Med);

Modif(Doc_Mapp);

L=L+1;

Fin

F=F+1;

Fin

Fin

180

Annexe C : L’ontologie de structure <?xml version="1.0" encoding="UTF-8"?> <!-- edited with XMLSPY v2004 rel. 3 U (http://www.xmlspy.com) by hamdi (lisi) --> <!--W3C Schema generated by XMLSPY v2004 rel. 3 U (http://www.xmlspy.com)--> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:element name="Adresse"> <xs:complexType> <xs:sequence> <xs:element name="Num_rue" type="xs:string"/> <xs:element name="Rue" type="xs:string"/> <xs:element ref="code-postal"/> <xs:element name="ville" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> <xs:simpleType name="TypeLien"> <xs:restriction base="xs:string"> <xs:enumeration value="Generalisation"/> <xs:enumeration value="Agregation"/> <xs:enumeration value="Composition"/> <xs:enumeration value="Association"/> <xs:enumeration value="Instanciation"/> <xs:enumeration value="Synonymie"/> </xs:restriction> </xs:simpleType> <xs:element name="Agregation" type="TypeLien"/> <xs:element name="Generalisation" type="TypeLien"/> <xs:element name="Composition" type="TypeLien"/> <xs:element name="Association" type="TypeLien"/> <xs:element name="Instanciation" type="TypeLien"/> <xs:element name="Synonymie" type="TypeLien"/> <xs:element name="Est_un_1"> <xs:complexType> <xs:sequence> <xs:element ref="personne"/> <xs:element ref="patient"/> <xs:element ref="Generalisation"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Personne_synonyme1"> <xs:complexType> <xs:sequence> <xs:element ref="personne"/> <xs:element name="Individu" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Personne_synonyme2"> <xs:complexType> <xs:sequence> <xs:element ref="personne"/> <xs:element name="Etre" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element>

181

<xs:element name="Personne_synonyme3"> <xs:complexType> <xs:sequence> <xs:element ref="personne"/> <xs:element name="Homme" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Personne_synonyme4"> <xs:complexType> <xs:sequence> <xs:element ref="personne"/> <xs:element name="Citoyen" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Est_un_10"> <xs:complexType> <xs:sequence> <xs:element ref="medecin"/> <xs:element ref="personne"/> <xs:element ref="Agregation"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Medecin_synonyme1"> <xs:complexType> <xs:sequence> <xs:element ref="medecin"/> <xs:element name="Thérapeute" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Medecin_synonyme2"> <xs:complexType> <xs:sequence> <xs:element ref="medecin"/> <xs:element name="Praticien" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Medecin_synonyme3"> <xs:complexType> <xs:sequence> <xs:element ref="medecin"/> <xs:element name="Clinicien" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="posse_une_1"> <xs:complexType> <xs:sequence> <xs:element ref="personne"/> <xs:element ref="Adresse"/> <xs:element ref="Composition"/>

182

</xs:sequence> </xs:complexType> </xs:element> <xs:element name="Affecte_a_1"> <xs:complexType> <xs:sequence> <xs:element ref="service"/> <xs:element ref="medecin"/> <xs:element ref="Composition"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="suivi_par_1"> <xs:complexType> <xs:sequence> <xs:element ref="patient"/> <xs:element ref="medecin"/> <xs:element ref="Agregation"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Patient_synonyme1"> <xs:complexType> <xs:sequence> <xs:element ref="patient"/> <xs:element name="Malade" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="possede_un_2"> <xs:complexType> <xs:sequence> <xs:element ref="patient"/> <xs:element ref="dossier-medical"/> <xs:element ref="Association"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Contient_un_1"> <xs:complexType> <xs:sequence> <xs:element ref="dossier-medical"/> <xs:element ref="intervention"/> <xs:element ref="Agregation"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Contient_un_2"> <xs:complexType> <xs:sequence> <xs:element ref="dossier-medical"/> <xs:element ref="prescription"/> <xs:element ref="Agregation"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Contient_un_3"> <xs:complexType> <xs:sequence>

183

<xs:element ref="dossier-medical"/> <xs:element ref="bilan"/> <xs:element ref="Agregation"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Contient_un_4"> <xs:complexType> <xs:sequence> <xs:element ref="dossier-medical"/> <xs:element ref="Diagnostic"/> <xs:element ref="Agregation"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Diagnostic_synonyme1"> <xs:complexType> <xs:sequence> <xs:element ref="Diagnostic"/> <xs:element name="Maladie" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Diagnostic_synonyme2"> <xs:complexType> <xs:sequence> <xs:element ref="Diagnostic"/> <xs:element name="Handicap" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Diagnostic_synonyme3"> <xs:complexType> <xs:sequence> <xs:element ref="Diagnostic"/> <xs:element name="Poussé" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Diagnostic_synonyme4"> <xs:complexType> <xs:sequence> <xs:element ref="Diagnostic"/> <xs:element name="lésion" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Diagnostic_synonyme5"> <xs:complexType> <xs:sequence> <xs:element ref="Diagnostic"/> <xs:element name="malaise" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element>

184

<xs:element name="Contient_un_5"> <xs:complexType> <xs:sequence> <xs:element ref="dossier-medical"/> <xs:element ref="antecedent"/> <xs:element ref="Agregation"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Antécédent_synonyme1"> <xs:complexType> <xs:sequence> <xs:element ref="antecedent"/> <xs:element name="Antériorité" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Antécédent_synonyme2"> <xs:complexType> <xs:sequence> <xs:element ref="antecedent"/> <xs:element name="Passé" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Antécédent_synonyme3"> <xs:complexType> <xs:sequence> <xs:element ref="antecedent"/> <xs:element name="Histoire-maladie" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Est_un_3"> <xs:complexType> <xs:sequence> <xs:element ref="antecedent"/> <xs:element ref="antecedent_personnel"/> <xs:element ref="Agregation"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Est_un_4"> <xs:complexType> <xs:sequence> <xs:element ref="antecedent"/> <xs:element ref="antecedent_familiaux"/> <xs:element ref="Agregation"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Est_un_5"> <xs:complexType> <xs:sequence> <xs:element ref="prescription"/> <xs:element ref="Prescription_chirurgicale"/> <xs:element ref="Agregation"/>

185

</xs:sequence> </xs:complexType> </xs:element> <xs:element name="Est_un_6"> <xs:complexType> <xs:sequence> <xs:element ref="prescription"/> <xs:element ref="ordonnance"/> <xs:element ref="Agregation"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Ordonnance_synonyme1"> <xs:complexType> <xs:sequence> <xs:element ref="ordonnance"/> <xs:element name="Prescription_médicale" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Est_un_7"> <xs:complexType> <xs:sequence> <xs:element ref="prescription"/> <xs:element ref="arret_travail"/> <xs:element ref="Agregation"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="est_compose_de_2"> <xs:complexType> <xs:sequence> <xs:element ref="ordonnance"/> <xs:element ref="medicament"/> <xs:element ref="Agregation"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Médicament_synonyme1"> <xs:complexType> <xs:sequence> <xs:element ref="medicament"/> <xs:element name="traitement" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Médicament_synonyme2"> <xs:complexType> <xs:sequence> <xs:element ref="medicament"/> <xs:element name="Medication" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Est_un_8"> <xs:complexType> <xs:sequence>

186

<xs:element ref="bilan"/> <xs:element ref="Bilan_Urinaire"/> <xs:element ref="Agregation"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Est_un_9"> <xs:complexType> <xs:sequence> <xs:element ref="bilan"/> <xs:element ref="bilan_sanguin"/> <xs:element ref="Agregation"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Est_un_11"> <xs:complexType> <xs:sequence> <xs:element ref="bilan"/> <xs:element ref="Radiologique"/> <xs:element ref="Agregation"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Radiologique_synonyme1"> <xs:complexType> <xs:sequence> <xs:element ref="Radiologique"/> <xs:element name="Radiographique" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Radiologique_synonyme2"> <xs:complexType> <xs:sequence> <xs:element ref="Radiologique"/> <xs:element name="Radioscopique" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Radiologique_synonyme3"> <xs:complexType> <xs:sequence> <xs:element ref="Radiologique"/> <xs:element name="Radiothérapique" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Pays_synonyme1"> <xs:complexType> <xs:sequence> <xs:element ref="pays"/> <xs:element name="territoire" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element>

187

<xs:element name="Pays_synonyme2"> <xs:complexType> <xs:sequence> <xs:element ref="pays"/> <xs:element name="Nation" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Symptômes_synonyme1"> <xs:complexType> <xs:sequence> <xs:element ref="Symptômes"/> <xs:element name="signe" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Symptômes_synonyme2"> <xs:complexType> <xs:sequence> <xs:element ref="Symptômes"/> <xs:element name="indication" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Symptômes_synonyme3"> <xs:complexType> <xs:sequence> <xs:element ref="Symptômes"/> <xs:element name="syndrome" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Profession_synonyme1"> <xs:complexType> <xs:sequence> <xs:element ref="profession"/> <xs:element name="travail" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Profession_synonyme2"> <xs:complexType> <xs:sequence> <xs:element ref="profession"/> <xs:element name="métier" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Profession_synonyme3"> <xs:complexType> <xs:sequence> <xs:element ref="profession"/> <xs:element name="emploi" type="xs:string"/> <xs:element ref="Synonymie"/>

188

</xs:sequence> </xs:complexType> </xs:element> <xs:element name="Est_compose_de_3"> <xs:complexType> <xs:sequence> <xs:element ref="Adresse"/> <xs:element ref="code-postal"/> <xs:element ref="Composition"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Est_compose_de_4"> <xs:complexType> <xs:sequence> <xs:element ref="Adresse"/> <xs:element ref="Rue"/> <xs:element ref="Composition"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Num_sec_sociale_synonyme1"> <xs:complexType> <xs:sequence> <xs:element ref="Num_sec_sociale"/> <xs:element name="NSS" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Nom_synonyme1"> <xs:complexType> <xs:sequence> <xs:element ref="Nom"/> <xs:element name="Nom_de_famille" type="xs:string"/> <xs:element ref="Synonymie"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="est_compose_de_1"> <xs:complexType> <xs:sequence> <xs:element ref="Adresse"/> <xs:element ref="Num_rue"/> <xs:element ref="Composition"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Bilan_Urinaire"> <xs:complexType> <xs:sequence> <xs:element name="libelle_Urinaire" type="xs:string"/> <xs:element name="resultat_Urinaire" type="xs:string"/> </xs:sequence> <xs:attribute name="code-medecin" type="xs:IDREF" use="required"/> <xs:attribute name="code-Urinaire" type="xs:ID" use="required"/> </xs:complexType> </xs:element> <xs:element name="antecedent_familiaux"> <xs:complexType>

189

<xs:sequence> <xs:element name="lien_familial" type="xs:string"/> <xs:element name="libelle_antecedent" type="xs:string"/> </xs:sequence> <xs:attribute name="code-medecin" type="xs:IDREF" use="required"/> </xs:complexType> </xs:element> <xs:element name="antecedent_personnel"> <xs:complexType> <xs:sequence> <xs:element name="libelle_antecedent" type="xs:string"/> </xs:sequence> <xs:attribute name="code-medecin" type="xs:IDREF" use="required"/> </xs:complexType> </xs:element> <xs:element name="antecedent"> <xs:complexType> <xs:sequence> <xs:element name="Date_antecedent" type="xs:date"/> <xs:element name="type_antecedent" type="xs:string"/> <xs:element ref="antecedent_personnel"/> <xs:element ref="antecedent_familiaux"/> </xs:sequence> <xs:attribute name="code-patient" type="xs:IDREF" use="required"/> <xs:attribute name="code-antecedent" type="xs:IDREF" use="required"/> </xs:complexType> </xs:element> <xs:element name="arret_travail"> <xs:complexType> <xs:sequence> <xs:element name="nombre_jour" type="xs:string"/> </xs:sequence> <xs:attribute name="code-arret_travail" type="xs:ID" use="required"/> </xs:complexType> </xs:element> <xs:element name="bilan"> <xs:complexType> <xs:sequence> <xs:element ref="Radiologique"/> <xs:element ref="Bilan_Urinaire"/> <xs:element ref="bilan_sanguin"/> <xs:element name="Date_bilan" type="xs:date"/> <xs:element name="type_bilan" type="xs:string"/> <xs:element name="Praticien_bilan" type="xs:string"/> <xs:element name="Resultat_bilan" type="xs:string"/> <xs:element name="Observation_bilan" type="xs:string"/> <xs:element name="Libellé_bilan" type="xs:string"/> </xs:sequence> <xs:attribute name="code-patient" type="xs:IDREF" use="required"/> </xs:complexType> </xs:element> <xs:element name="code-p"> <xs:complexType/> </xs:element> <xs:element name="code-postal"> <xs:complexType> <xs:sequence> <xs:element ref="code-p"/> <xs:element name="commune" type="xs:string"/> </xs:sequence>

190

<xs:attribute name="code-p" type="xs:ID" use="required"/> </xs:complexType> </xs:element> <xs:element name="departement"> <xs:complexType> <xs:sequence> <xs:element name="Libelle-departement" type="xs:string"/> <xs:element ref="pays"/> </xs:sequence> <xs:attribute name="code-departement" type="xs:ID" use="required"/> </xs:complexType> </xs:element> <xs:element name="Diagnostic"> <xs:complexType> <xs:sequence> <xs:element name="Date_diagnostic" type="xs:string"/> <xs:element name="Libelle_diagnostic" type="xs:string"/> <xs:element name="Observation_diagnostic" type="xs:string"/> </xs:sequence> <xs:attribute name="code_diagnostic" type="xs:ID" use="required"/> <xs:attribute name="code-medecin" type="xs:IDREF" use="required"/> </xs:complexType> </xs:element> <xs:element name="Symptômes"> <xs:complexType> <xs:sequence> <xs:element name="Date_symptome" type="xs:string"/> <xs:element name="libelle_symptome" type="xs:string"/> <xs:element name="Observation_symptome" type="xs:string"/> </xs:sequence> <xs:attribute name="code-symptome" type="xs:ID" use="required"/> </xs:complexType> </xs:element> <xs:element name="dossier-medical"> <xs:complexType> <xs:sequence> <xs:element name="Date_creation" type="xs:string"/> <xs:element ref="intervention"/> <xs:element ref="Symptômes"/> <xs:element ref="prescription"/> <xs:element ref="bilan"/> <xs:element ref="antecedent"/> <xs:element ref="Diagnostic"/> </xs:sequence> <xs:attribute name="id-dossier" type="xs:ID" use="required"/> <xs:attribute name="code-medecin" type="xs:IDREF" use="required"/> <xs:attribute name="code-service" type="xs:IDREF" use="required"/> </xs:complexType> </xs:element> <xs:element name="grade"> <xs:complexType> <xs:sequence> <xs:element name="Libelle-grade" type="xs:string"/> </xs:sequence> <xs:attribute name="code-grade" type="xs:ID" use="required"/> </xs:complexType> </xs:element> <xs:element name="indication" type="xs:string"/> <xs:element name="intervention"> <xs:complexType>

191

<xs:sequence> <xs:element name="Date_intevention" type="xs:string"/> <xs:element name="protocole-intervention" type="xs:string"/> <xs:element name="reultat-intervention" type="xs:string"/> </xs:sequence> <xs:attribute name="id-intervention" type="xs:ID" use="required"/> </xs:complexType> </xs:element> <xs:element name="medecin"> <xs:complexType> <xs:sequence> <xs:element ref="grade"/> <xs:element ref="specialite"/> <xs:element ref="service"/> </xs:sequence> <xs:attribute name="code-medecin" type="xs:ID" use="required"/> </xs:complexType> </xs:element> <xs:element name="Orientation"> <xs:complexType> <xs:sequence> <xs:element name="Libelle_Orientation" type="xs:string"/> <xs:element name="Type_Orientation" type="xs:string"/> <xs:element name="Motif_Orientation" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Examen_medical"> <xs:complexType> <xs:sequence> <xs:element name="Libelle_ Examen_medical" type="xs:string"/> <xs:element name="Type_Examen_medical" type="xs:string"/> <xs:element name="Motif_Examen_medical" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="medicament"> <xs:complexType> <xs:sequence> <xs:element name="libelle-medicament" type="xs:string"/> <xs:element name="forme-medicament" type="xs:string"/> <xs:element name="laboratoire" type="xs:string"/> <xs:element name="posologie" type="xs:string"/> <xs:element name="contre-indication" type="xs:string"/> <xs:element name="indication" type="xs:string"/> </xs:sequence> <xs:attribute name="code-medicament" type="xs:ID" use="required"/> </xs:complexType> </xs:element> <xs:element name="ordonnance"> <xs:complexType> <xs:sequence> <xs:element name="Dose" type="xs:string"/> <xs:element name="Quantite" type="xs:string"/> <xs:element name="unite-quantite" type="xs:string"/> <xs:element name="dure" type="xs:string"/> <xs:element name="unite-duree" type="xs:string"/> <xs:element name="frequence" type="xs:string"/> <xs:element name="unite-frequence" type="xs:string"/> </xs:sequence>

192

<xs:attribute name="code-ordonnance" type="xs:ID" use="required"/> <xs:attribute name="code-patient" type="xs:IDREF" use="required"/> <xs:attribute name="code-medicament" type="xs:IDREF" use="required"/> </xs:complexType> </xs:element> <xs:element name="patient"> <xs:complexType> <xs:sequence> <xs:element name="profession" type="xs:string"/> <xs:element name="taille" type="xs:string"/> <xs:element name="poids" type="xs:string"/> </xs:sequence> <xs:attribute name="code-patient" type="xs:ID" use="required"/> </xs:complexType> </xs:element> <xs:element name="pays"> <xs:complexType> <xs:sequence> <xs:element name="Libelle-pays" type="xs:string"/> </xs:sequence> <xs:attribute name="code-pays" type="xs:ID" use="required"/> </xs:complexType> </xs:element> <xs:element name="personne"> <xs:complexType> <xs:sequence> <xs:element name="Nom" type="xs:string"/> <xs:element name="Sexe" type="xs:string"/> <xs:element name="Situation_familiale" type="xs:string"/> <xs:element name="prenom" type="xs:string"/> <xs:element name="age" type="xs:decimal"/> <xs:element name="Num_sec_sociale" type="xs:string"/> <xs:element name="lieu-naissance" type="xs:string"/> <xs:element name="date-naissance" type="xs:date"/> <xs:element ref="Adresse" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="telephone-domicile" type="xs:string"/> <xs:element name="telephone-professionel" type="xs:string"/> <xs:element name="telephone-portable" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="prescription"> <xs:complexType> <xs:sequence> <xs:element name="Date-prescription" type="xs:string"/> <xs:element name="type-prescription" type="xs:string"/> <xs:choice> <xs:element ref="ordonnance"/> <xs:element ref="Prescription_chirurgicale"/> <xs:element ref="arret_travail"/> <xs:element ref="Orientation"/> <xs:element ref="Examen_medical"/> </xs:choice> </xs:sequence> <xs:attribute name="code-medecin" type="xs:IDREF" use="required"/> </xs:complexType> </xs:element> <xs:element name="Prescription_chirurgicale"> <xs:complexType> <xs:sequence>

193

<xs:element name="libelle-prescription_chirurgicale" type="xs:string"/> <xs:element name="observation" type="xs:string"/> <xs:element name="type-prescription_chirurgicale" type="xs:string"/> </xs:sequence> <xs:attribute name="code-prescription_chirurgicale" type="xs:ID" use="required"/> </xs:complexType> </xs:element> <xs:element name="profession" type="xs:string"/> <xs:element name="Radiologique"> <xs:complexType> <xs:sequence> <xs:element name="libelle_radiologie" type="xs:string"/> <xs:element name="resultat_radiologie" type="xs:string"/> </xs:sequence> <xs:attribute name="code-medecin" type="xs:IDREF" use="required"/> <xs:attribute name="code-radiologie" type="xs:ID" use="required"/> </xs:complexType> </xs:element> <xs:element name="bilan_sanguin"> <xs:complexType> <xs:sequence> <xs:element name="libelle_sanguin" type="xs:string"/> <xs:element name="resultat_sanguin" type="xs:string"/> </xs:sequence> <xs:attribute name="code-medecin" type="xs:IDREF" use="required"/> <xs:attribute name="code-sanguin" type="xs:ID" use="required"/> </xs:complexType> </xs:element> <xs:element name="service"> <xs:complexType> <xs:sequence> <xs:element name="Libelle-service" type="xs:string"/> <xs:element name="specialite-service" type="xs:string"/> <xs:element name="medecin-chef-service" type="xs:string"/> <xs:element name="adresse-service" type="xs:string"/> <xs:element name="pavillon" type="xs:string"/> </xs:sequence> <xs:attribute name="code-service" type="xs:ID" use="required"/> </xs:complexType> </xs:element> <xs:element name="specialite"> <xs:complexType> <xs:sequence> <xs:element name="Libelle-specialite" type="xs:string"/> </xs:sequence> <xs:attribute name="code-specialite" type="xs:ID" use="required"/> </xs:complexType> </xs:element> <xs:element name="ville"> <xs:complexType> <xs:sequence> <xs:element name="Libelle-ville" type="xs:string"/> <xs:element ref="departement"/> <xs:element name="commune" type="xs:string"/> </xs:sequence> <xs:attribute name="code-ville" type="xs:ID" use="required"/> </xs:complexType> </xs:element> </xs:schema>

194

Annexe D : Cas pratique Dans cette annexe nous allons présenter un cas pratique où nous déroulons nos étapes pour la

description d’une base de données et pour la création d’une vue unifiée sur deux parties de schémas,

que nous avons utilisés dans notre prototype. De chaque base de données nous allons prendre deux

relations, les décrire, les intégrer dans notre schéma médiateur, et créés les règles de mapping pour

chaque relation et chaque attribut créer dans le schéma médiateur.

1 Les bases de données Base de donnée 1 : Patient (Numordre, nom, prenom, datenaiss, lieunaiss, profession, adresse, NSS) Diagnostic (Numordre, code_diag, codemed, date_maladie, observation) Base de donnée 2 : Malade (code, nom-malade, prenom-malade, datenaissance, villenaissance, N_rue, rue, codepostal, ville, NSS) Dossier-medical (Code, id_dossier, date-creation) Maladie (code, id_dossier, code_diag, date_diag, observation)

• Souligné : clé primaire. • Italique : clé étrangère.

2 Le contenu des bases de données Diagnostic : Numordre Codemed Code_diag Date_maladie Observation N001 M05 M098 23/01/99 Rougeur à l’œil N003 M22 M987 4/06/03 Toux sèche

Tableau 10: Tableau contenant une partie du contenu de la relation Diagnostic de la base de données BD1

Patient : Numordre Nom Prenom Datenaiss Lieunaiss Profession N001 Crespo Janne 23/01/79 Argentine Footballeur N003 Kesman Jhoan 4/06/83 Hollande Footballeur Adresse NSS 26 rue paul bert 69003 117999909876 25 cours gambetta 69007 168399098766

Tableau 11: Tableau contenant une partie du contenu de la relation Patient de la base de données BD1

195

3 L’ontologie de structure

Nous exposons une partie de notre ontologie de structure qui contient les concepts que nous

allons utiliser pour la description et l’intégration des parties des bases de données présentées ci-

dessus. Cette ontologie est présentée dans l’annexe C <?xml version="1.0" encoding="UTF-8"?> <!-- edited with XMLSPY v2004 rel. 3 U (http://www.xmlspy.com) by hamdi (lisi) --> <!--W3C Schema generated by XMLSPY v2004 rel. 3 U (http://www.xmlspy.com)--> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:simpleType name="TypeLien"> <xs:restriction base="xs:string"> <xs:enumeration value="Generalisation"/> <xs:enumeration value="Agregation"/> <xs:enumeration value="Composition"/> <xs:enumeration value="Association"/> <xs:enumeration value="Instanciation"/> </xs:restriction> </xs:simpleType> <xs:element name="Agregation" type="TypeLien"/> <xs:element name="Generalisation" type="TypeLien"/> <xs:element name="Composition" type="TypeLien"/> <xs:element name="Association" type="TypeLien"/> <xs:element name="Instanciation" type="TypeLien"/> <xs:element name="Lien_is_a_1"> <xs:complexType> <xs:sequence> <xs:element ref="personne"/> <xs:element ref="patient"/> <xs:element ref="Generalisation"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Lien_is_a_6"> <xs:complexType> <xs:sequence> <xs:element ref="patient"/> <xs:element ref="dossier-medical"/> <xs:element ref="Association"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="diagnostic"> <xs:complexType> <xs:sequence> <xs:element name="Date_diagnostic" type="xs:string"/> <xs:element name="Libelle_diagnostic" type="xs:string"/> <xs:element name="Observation_diagnostic" type="xs:string"/> </xs:sequence> <xs:attribute name="code_diagnostic" type="xs:ID" use="required"/> <xs:attribute name="code-medecin" type="xs:IDREF" use="required"/> </xs:complexType> </xs:element> </xs:element> <xs:element name="patient"> <xs:complexType> <xs:sequence> <xs:element name="profession" type="xs:string"/> <xs:element name="taille" type="xs:string"/> <xs:element name="poids" type="xs:string"/> </xs:sequence> <xs:attribute name="code-patient" type="xs:ID" use="required"/> </xs:complexType>

196

</xs:element> <xs:element name="personne"> <xs:complexType> <xs:sequence> <xs:element name="Nom" type="xs:string"/> <xs:element name="Sexe" type="xs:string"/> <xs:element name="Situation_familiale" type="xs:string"/> <xs:element name="prenom" type="xs:string"/> <xs:element name="age" type="xs:decimal"/> <xs:element name="Num_sec_sociale" type="xs:string"/> <xs:element name="lieu-naissance" type="xs:string"/> <xs:element name="date-naissance" type="xs:date"/> <xs:element ref="Adresse" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="telephone-domicile" type="xs:string"/> <xs:element name="telephone-professionel" type="xs:string"/> <xs:element name="telephone-portable" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Lien_is_a_10"> <xs:complexType> <xs:sequence> <xs:element ref="dossier-medical"/> <xs:element ref="diagnostic"/> <xs:element ref="Agregation"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="dossier-medical"> <xs:complexType> <xs:sequence> <xs:element name="Date_creation" type="xs:string"/> <xs:element ref="intervention"/> <xs:element ref="Symptomes"/> <xs:element ref="prescription"/> <xs:element ref="bilan"/> <xs:element ref="antecedant"/> <xs:element ref="diagnostic"/> </xs:sequence> <xs:attribute name="id-dossier" type="xs:ID" use="required"/> <xs:attribute name="code-medecin" type="xs:IDREF" use="required"/> <xs:attribute name="code-service" type="xs:IDREF" use="required"/> </xs:complexType> </xs:element> </xs:schema>

Figure 59 : Une partie de l’ontologie du dossier médical

4 Déroulement de la proposition 4.1 Description de la base de données

Dans cette partie nous appliquons notre algorithme pour décrire les deux relations « Patient »

et « Diagnostic » de la base de données BD1.

I Relation Diagnostic

Etape A : Description de la relation

197

a- Recherche dans l’ontologie de structure les concepts qui décrivent la relation : « Maladie » (à partir des synonymes),

b- Dictionnaire des données : « Informations sur les maladies des patients », c- Choix du concept décrivant la relation : « Maladie » d- Création ou modification du document XML.

<?xml version="1.0" ?> <!DOCTYPE SYSTEM="descriptionBDD.dtd"> <schema> <Nom-schema BD1/> <Relation nom-relation="Diagnostic"> <Nom-concept>Maladie</Nom-concept> <description> Informations sur les maladies des patients</description> </Relation> </schema> Etape B : Description des Attributs Traitement de l’attribut : Numordre

a- Recherche dans l’ontologie de structure les concepts qui décrivent l’attribut « Numordre ». Nous somme devant le traitement d’une clé primaire qui n’a pas d’équivalent dans notre ontologie de structure. Dans ce cas elle garde son nom,

b- Comparaison du contenu de l’attribut : Null, c- Dictionnaire des données : Identifiant du patient, d- Choix du concept décrivant l’attribut : « Numordre », e- Création ou modification du document XML.

<?xml version="1.0" ?> <!DOCTYPE SYSTEM="descriptionBDD.dtd"> <schema> <Nom-schema BD1/> <Relation nom-relation="Diagnostic"> <Nom-concept>Maladie</Nom-concept> <description> Informations sur les maladies des patients</description> <attribut Nom-attribut="Numordre"> <Nom-concept>Numordre</Nom-concept> <description>Identifiant du patient</description> </attribut>

<CleP IDAttribut="Numordre"/> </Relation> </schema> Commentaire

Nous remarquons que dans le document décrivant la relation « Diagnostic » nous avons créé

un élément XML qui porte le nom « CleP ». Cet élément contient les attributs qui constituent clé

primaire de la relation.

Traitement de l’attribut : Code_diag

a- Recherche dans l’ontologie de structure les concepts qui décrivent l’attribut « Code_diag » : A partir des synonymes, code_diagnostic ≈ code_diag,

198

b- Comparaison du contenu de l’attribut : 100% du contenu de l’attribut Code_diag est contenu dans les valeurs du concept Maladie de l’ontologie de valeurs,

c- Dictionnaire des données : Code de la maladie du patient, d- Choix du concept décrivant l’attribut : « Code_diagnostic », e- Création ou modification du document XML.

<?xml version="1.0" ?> <!DOCTYPE SYSTEM="descriptionBDD.dtd"> <schema> <Nom-schema BD1/> <Relation nom-relation="Diagnostic"> <Nom-concept>Maladie</Nom-concept> <description> Informations sur les maladies des patients</description> <attribut Nom-attribut="Numordre"> <Nom-concept>Numordre</Nom-concept> <description>Identifiant du patient</description> </attribut> <attribut Nom-attribut="code_diag"> <Nom-concept>code_diagnostic</Nom-concept> <description>Code de la maladie du patient</description> </attribut>

<CleP IDAttribut="Numordre code_diag"/> </Relation> </schema> Traitement de l’attribut : codemed

a- Recherche dans l’ontologie de structure les concepts qui décrivent l’attribut « Codemed » : Nous somme devant le traitement d’une clé primaire qui n’a pas d’équivalent dans notre ontologie de structure. Dans ce cas elle garde son nom,

b- Comparaison du contenu de l’attribut : Null, c- Dictionnaire des données : Code du médecin, d- Choix du concept décrivant l’attribut : « Codemed », e- Création ou modification du document XML.

<?xml version="1.0" ?> <!DOCTYPE SYSTEM="descriptionBDD.dtd"> <schema> <Nom-schema BD1/> <Relation nom-relation="Diagnostic"> <Nom-concept>Maladie</Nom-concept> <description> Informations sur les maladies des patients</description> <attribut Nom-attribut="Numordre"> <Nom-concept>Numordre</Nom-concept> <description>Identifiant du patient</description> </attribut> <attribut Nom-attribut="code_diag"> <Nom-concept>code_diagnostic</Nom-concept> <description>Code de la maladie du patient</description> </attribut> <attribut Nom-attribut="codemed"> <Nom-concept>codemed</Nom-concept> <description>Code de médecin</description> </attribut>

<CleP IDAttribut="Numordre code_diag codemed"/> </Relation> </schema>

199

Traitement de l’attribut : Date_maladie

a- Recherche dans l’ontologie de structure les concepts qui décrivent l’attribut « Date_maladie » : Date_Diagnostic (Recherche par type de données)

b- Comparaison du contenu de l’attribut : 100% Date c- Dictionnaire des données : Date de la maladie du patient d- Choix du concept décrivant l’attribut : « Date_Diagnostic » e- Création ou modification du document XML.

<?xml version="1.0" ?> <!DOCTYPE SYSTEM="descriptionBDD.dtd"> <schema> <Nom-schema BD1/> <Relation nom-relation="Diagnostic"> <Nom-concept>Maladie</Nom-concept> <description> Informations sur les maladies des patients</description> <attribut Nom-attribut="Numordre"> <Nom-concept>Numordre</Nom-concept> <description>Identifiant du patient</description> </attribut> <attribut Nom-attribut="code_diag"> <Nom-concept>code_diagnostic</Nom-concept> <description>Code de la maladie du patient</description> </attribut> <attribut Nom-attribut="codemed"> <Nom-concept>codemed</Nom-concept> <description>Code de médecin</description> </attribut> <attribut Nom-attribut="date_maladie"> <Nom-concept>date_Diagnostic</Nom-concept> <description>la date du diagnostic du patient</description> </attribut>

<CleP IDAttribut="Numordre code_diag codemed"/> </Relation> </schema> Traitement de l’attribut Observation

a- Recherche dans l’ontologie de structure les concepts qui décrivent l’attribut « Date_maladie » : Observation_diagnostic

b- Comparaison du contenu de l’attribut : 33 % symptomes, 25% maladie, c- Dictionnaire des données : les observations sur la maladie du patient, d- Choix du concept décrivant l’attribut : « Observation_diagnostic », e- Création ou modification du document XML.

<?xml version="1.0" ?> <!DOCTYPE SYSTEM="descriptionBDD.dtd"> <schema> <Nom-schema BD1/> <Relation nom-relation="Diagnostic"> <Nom-concept>Maladie</Nom-concept> <description> Informations sur les maladies des patients</description> <attribut Nom-attribut="Numordre"> <Nom-concept>Numordre</Nom-concept> <description>Identifiant du patient</description> </attribut> <attribut Nom-attribut="code_diag">

200

<Nom-concept>code_diagnostic</Nom-concept> <description>Code de la maladie du patient</description> </attribut> <attribut Nom-attribut="codemed"> <Nom-concept>codemed</Nom-concept> <description>Code de médecin</description> </attribut> <attribut Nom-attribut="date_maladie"> <Nom-concept>date_Diagnostic</Nom-concept> <description>la date du diagnostic du patient</description> </attribut> <attribut Nom-attribut="Observation"> <Nom-concept>Observation _Diagnostic</Nom-concept> <description>Observation sur la maladie</description> </attribut>

<CleP IDAttribut="Numordre code_diag codemed"/> </Relation> </schema>

II Relation Patient

Etape A : Description de la relation

a- Recherche dans l’ontologie de structure les concepts qui décrivent la relation « Patient » : Patient (à partir des synonymes),

b- Dictionnaire des données : Relation contenant les informations sur les patients, c- Choix du concept décrivant la relation : « Patient », d- Création ou modification du document XML.

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE schema SYSTEM "DESCRIPTION.dtd"> <schema> <Nom-schema/> <Relation nom-relation="Patient"> <Nom-concept>Patient</Nom-concept> <description>relation contenant les informations sur les patients</description> </Relation> </schema> Etape B : Description des Attributs Traitement de l’attribut : Numordre

a- Recherche dans l’ontologie de structure les concepts qui décrivent l’attribut « Numordre » : Cet attribut a été traité ci-dessus, donc il garde le même concept,

b- Comparaison du contenu de l’attribut : Null, c- Dictionnaire des données : Identifiant du patient, d- Choix du concept décrivant l’attribut : « Numordre », e- Création ou modification du document XML.

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE schema SYSTEM "DESCRIPTION.dtd"> <schema> <Nom-schema/> <Relation nom-relation="Patient"> <Nom-concept>Patient</Nom-concept>

201

<description>relation contenant les informations sur les patients</description> <attribut Nom-attribut="Numordre"> <Nom-concept>Numordre</Nom-concept> <description>Identifiant du patient</description> </attribut> <CleP IDAttribut="Numordre"/> </Relation> </schema> Traitement de l’attribut : Nom

a- Recherche dans l’ontologie de structure les concepts qui décrivent l’attribut « Nom » : A partir des synonymes, Nom = Nom,

b- Comparaison du contenu de l’attribut : Null, c- Dictionnaire des données : Nom du patient, d- Choix du concept décrivant l’attribut : « Nom », e- Création ou modification du document XML.

Remarque : La recherche du concept décrivant l’attribut « Nom » s’effectuée en remontant le lien « généralisation » liant le concept « Patient » au concept « Personne » <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE schema SYSTEM "DESCRIPTION.dtd"> <schema> <Nom-schema/> <Relation nom-relation="Patient"> <Nom-concept>Patient</Nom-concept> <description>relation contenant les informations sur les patients</description> <attribut Nom-attribut="Numordre"> <Nom-concept>Numordre</Nom-concept> <description>Identifiant du patient</description> </attribut> <attribut Nom-attribut="Nom"> <Nom-concept>Nom</Nom-concept> <description>Nom du patient</description> </attribut> <CleP IDAttribut="Numordre"/> </Relation> </schema> Traitement de l’attribut : Prenom

a- Recherche dans l’ontologie de structure les concepts qui décrivent l’attribut « Prenom » : A partir des synonymes, prenom = prenom,

b- Comparaison du contenu de l’attribut : Null, c- Dictionnaire des données : Prenom du patient, d- Choix du concept décrivant l’attribut : « prenom», e- Création ou modification du document XML.

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE schema SYSTEM "DESCRIPTION.dtd"> <schema> <Nom-schema/> <Relation nom-relation="Patient"> <Nom-concept>Patient</Nom-concept> <description>relation contenant les informations sur les patients</description>

202

<attribut Nom-attribut="Numordre"> <Nom-concept>Numordre</Nom-concept> <description>Identifiant du patient</description> </attribut> <attribut Nom-attribut="Nom"> <Nom-concept>Nom</Nom-concept> <description>Nom du patient</description> </attribut> <attribut Nom-attribut="Prenom"> <Nom-concept>Prenom</Nom-concept> <description> Prenom du patient</description> </attribut> <CleP IDAttribut="Numordre"/> </Relation> </schema> Traitement de l’attribut : Datenaiss

a- Recherche dans l’ontologie de structure les concepts qui décrivent l’attribut « Datenaiss » : Date_Diagnostic (Recherche par type de données),

b- Comparaison du contenu de l’attribut : 100% Date, c- Dictionnaire des données : Date de naissance du patient, d- Choix du concept décrivant l’attribut : «Date-naissance », e- Création ou modification du document XML.

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE schema SYSTEM "DESCRIPTION.dtd"> <schema> <Nom-schema/> <Relation nom-relation="Patient"> <Nom-concept>Patient</Nom-concept> <description>relation contenant les informations sur les patients</description> <attribut Nom-attribut="Numordre"> <Nom-concept>Numordre</Nom-concept> <description>Identifiant du patient</description> </attribut> <attribut Nom-attribut="Nom"> <Nom-concept>Nom</Nom-concept> <description>Nom du patient</description> </attribut> <attribut Nom-attribut="Prenom"> <Nom-concept>Prenom</Nom-concept> <description>Prenom du patient</description> </attribut> <attribut Nom-attribut="Datenaiss"> <Nom-concept>Date-naissance</Nom-concept> <description>Date de naissance du patient</description> </attribut> <CleP IDAttribut="Numordre"/> </Relation> </schema> Traitement de l’attribut Lieunaiss

a- Recherche dans l’ontologie de structure les concepts qui décrivent l’attribut « Lieunaiss » : Lieu-naissance (recherche par synonyme Lieunaiss ≈ Lieu-naissance),

b- Comparaison du contenu de l’attribut : 100% Ville,

203

c- Dictionnaire des données : Lieu de naissance du patient, d- Choix du concept décrivant l’attribut : « Lieu-naissance », e- Création ou modification du document XML.

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE schema SYSTEM "DESCRIPTION.dtd"> <schema> <Nom-schema/> <Relation nom-relation="Patient"> <Nom-concept>Patient</Nom-concept> <description>relation contenant les informations sur les patients</description> <attribut Nom-attribut="Numordre"> <Nom-concept>Numordre</Nom-concept> <description>Identifiant du patient</description> </attribut> <attribut Nom-attribut="Nom"> <Nom-concept>Nom</Nom-concept> <description>Nom du patient</description> </attribut> <attribut Nom-attribut="Prenom"> <Nom-concept> Prenom</Nom-concept> <description> Prenom du patient</description> </attribut> <attribut Nom-attribut="Datenaiss"> <Nom-concept>Date-naissance</Nom-concept> <description>Date de naissance du patient</description> </attribut> <attribut Nom-attribut="Lieunaiss"> <Nom-concept>Lieu-naissance</Nom-concept> <description>Lieu de naissance du patient</description> </attribut> <CleP IDAttribut="Numordre"/> </Relation> </schema> Traitement de l’attribut : Profession

a- Recherche dans l’ontologie de structure les concepts qui décrivent l’attribut « Profession » : Profession (Recherche par synonyme),

b- Comparaison du contenu de l’attribut : Null, c- Dictionnaire des données : Profession du patient, d- Choix du concept décrivant l’attribut : « Profession », e- Création ou modification du document XML.

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE schema SYSTEM "DESCRIPTION.dtd"> <schema> <Nom-schema/> <Relation nom-relation="Patient"> <Nom-concept>Patient</Nom-concept> <description>relation contenant les informations sur les patients</description> <attribut Nom-attribut="Numordre"> <Nom-concept>Numordre</Nom-concept> <description>Identifiant du patient</description> </attribut> <attribut Nom-attribut="Nom"> <Nom-concept>Nom</Nom-concept> <description>Nom du patient</description>

204

</attribut> <attribut Nom-attribut="Prenom"> <Nom-concept> Prenom</Nom-concept> <description> Prenom du patient</description> </attribut> <attribut Nom-attribut="Datenaiss"> <Nom-concept>Date-naissance</Nom-concept> <description>Date de naissance du patient</description> </attribut> <attribut Nom-attribut="Lieunaiss"> <Nom-concept>Lieu-naissance</Nom-concept> <description>Lieu de naissance du patient</description> </attribut> <attribut Nom-attribut="Profession"> <Nom-concept>Profession</Nom-concept> <description>Profession du patient</description> </attribut> <CleP IDAttribut="Numordre"/> </Relation> </schema> Traitement de l’attribut : Adresse

a- Recherche dans l’ontologie de structure les concepts qui décrivent l’attribut « Adresse » : Adresse (Recherche par synonyme),

b- Comparaison du contenu de l’attribut : Null, c- Dictionnaire des données : Adresse du patient, d- Choix du concept décrivant l’attribut : « Adresse », e- Création ou modification du document XML.

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE schema SYSTEM "DESCRIPTION.dtd"> <schema> <Nom-schema/> <Relation nom-relation="Patient"> <Nom-concept>Patient</Nom-concept> <description>relation contenant les informations sur les patients</description> <attribut Nom-attribut="Numordre"> <Nom-concept>Numordre</Nom-concept> <description>Identifiant du patient</description> </attribut> <attribut Nom-attribut="Nom"> <Nom-concept>Nom</Nom-concept> <description>Nom du patient</description> </attribut> <attribut Nom-attribut="Prenom"> <Nom-concept> Prenom</Nom-concept> <description> Prenom du patient</description> </attribut> <attribut Nom-attribut="Datenaiss"> <Nom-concept>Date-naissance</Nom-concept> <description>Date de naissance du patient</description> </attribut> <attribut Nom-attribut="Lieunaiss"> <Nom-concept>Lieu-naissance</Nom-concept> <description>Lieu de naissance du patient</description> </attribut> <attribut Nom-attribut="Profession"> <Nom-concept>Profession</Nom-concept>

205

<description>Profession du patient</description> </attribut> <attribut Nom-attribut="Adresse"> <Nom-concept>Adresse</Nom-concept> <description>Adresse du patient</description> </attribut> <CleP IDAttribut="Numordre"/> </Relation> </schema> Traitement de l’attribut : NSS

a- Recherche dans l’ontologie de structure les concepts qui décrivent l’attribut « NSS » : Num_sec_sociale, (Recherche par synonyme),

b- Comparaison du contenu de l’attribut : Null, c- Dictionnaire des données : Le numéro de sécurité sociale du patient, d- Choix du concept décrivant l’attribut : « Num_sec_sociale », e- Création ou modification du document XML.

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE schema SYSTEM "DESCRIPTION.dtd"> <schema> <Nom-schema/> <Relation nom-relation="Patient"> <Nom-concept>Patient</Nom-concept> <description>relation contenant les informations sur les patients</description> <attribut Nom-attribut="Numordre"> <Nom-concept>Numordre</Nom-concept> <description>Identifiant du patient</description> </attribut> <attribut Nom-attribut="Nom"> <Nom-concept>Nom</Nom-concept> <description>Nom du patient</description> </attribut> <attribut Nom-attribut="Prenom"> <Nom-concept> Prenom</Nom-concept> <description> Prenom du patient</description> </attribut> <attribut Nom-attribut="Datenaiss"> <Nom-concept>Date-naissance</Nom-concept> <description>Date de naissance du patient</description> </attribut> <attribut Nom-attribut="Lieunaiss"> <Nom-concept>Lieu-naissance</Nom-concept> <description>Lieu de naissance du patient</description> </attribut> <attribut Nom-attribut="Profession"> <Nom-concept>Profession</Nom-concept> <description>Profession du patient</description> </attribut> <attribut Nom-attribut="Adresse"> <Nom-concept>Adresse</Nom-concept> <description>Adresse du patient</description> </attribut> <attribut Nom-attribut="NSS"> <Nom-concept>Num_sec_sociale</Nom-concept> <description>Le numéro de sécurité sociale du patient</description> </attribut>

206

<CleP IDAttribut="Numordre"/> </Relation> </schema>

Etape C : Description des liens entre les relations

Traitement des clés de la relation Diagnostic :

- Numordre est importé de la relation « Patient » - Modification du document XML.

<?xml version="1.0" ?> <!DOCTYPE SYSTEM="descriptionBDD.dtd"> <schema> <Nom-schema BD1/> <Relation nom-relation="Diagnostic"> <Nom-concept>Maladie</Nom-concept> <description> Informations sur les maladies des patients</description> <attribut Nom-attribut="Numordre"> <Nom-concept>Numordre</Nom-concept> <description>Identifiant du patient</description> </attribut> <attribut Nom-attribut="code_diag"> <Nom-concept>code_diagnostic</Nom-concept> <description>Code de la maladie du patient</description> </attribut> <attribut Nom-attribut="codemed"> <Nom-concept>codemed</Nom-concept> <description>Code de médecin</description> </attribut> <attribut Nom-attribut="date_maladie"> <Nom-concept>date_Diagnostic</Nom-concept> <description>la date du diagnostic du patient</description> </attribut> <attribut Nom-attribut="Observation"> <Nom-concept>Observation _Diagnostic</Nom-concept> <description>Observation sur la maladie</description> </attribut>

<CleP IDAttribut="Numordre code_diag codemed"/> <References IDrelation="Diagnostic"></References>

</Relation> </schema> Résultat de la description <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE schema SYSTEM "DESCRIPTION.dtd"> <schema> <Nom-schema/> <Relation nom-relation="Patient"> <Nom-concept>Patient</Nom-concept> <description>relation contenant les informations sur les patients</description> <attribut Nom-attribut="Numordre"> <Nom-concept-attribut>Numordre</Nom-concept-attribut> <description-attribut>Identifiant du patient</description-attribut> </attribut> <attribut Nom-attribut="Nom">

207

<Nom-concept-attribut>Nom</Nom-concept-attribut> <description-attribut-attribut>Nom du patient</description-attribut > </attribut> <attribut Nom-attribut="Prenom"> <Nom-concept-attribut> Prenom</Nom-concept-attribut> <description-attribut> Prenom du patient</description-attribut> </attribut> <attribut Nom-attribut="Datenaiss"> <Nom-concept-attribut>Date-naissance</Nom-concept-attribut> <description-attribut>Date de naissance du patient</description-attribut> </attribut> <attribut Nom-attribut="Lieunaiss"> <Nom-concept-attribut>Lieu-naissance</Nom-concept-attribut> <description-attribut>Lieu de naissance du patient</description-attribut> </attribut> <attribut Nom-attribut="Profession"> <Nom-concept-attribut>Profession</Nom-concept-attribut> <description-attribut>Profession du patient</description-attribut> </attribut> <attribut Nom-attribut="Adresse"> <Nom-concept-attribut>Adresse</Nom-concept-attribut> <description-attribut>Adresse du patient</description-attribut> </attribut> <attribut Nom-attribut="NSS"> <Nom-concept-attribut>Num_sec_sociale</Nom-concept-attribut> <description-attribut>Le numéro de sécurité sociale du patient</description-attribut> </attribut> <CleP IDAttribut="Numordre"/> </Relation> <Relation nom-relation="Diagnostic"> <Nom-concept>Diagnostic</Nom-concept> <description> Informations sur les maladies des patients</description> <attribut Nom-attribut="Numordre"> <Nom-concept-attribut>Numordre</Nom-concept-attribut> <description-attribut>Identifiant du patient</description-attribut> </attribut> <attribut Nom-attribut="code_diag"> <Nom-concept-attribut>code_diagnostic</Nom-concept-attribut> <description-attribut>Code de la maladie du patient</description-attribut> </attribut> <attribut Nom-attribut="codemed"> <Nom-concept-attribut>codemed</Nom-concept-attribut> <description-attribut>Code de médecin</description-attribut> </attribut> <attribut Nom-attribut="date_maladie"> <Nom-concept-attribut>date_Diagnostic</Nom-concept-attribut> <description-attribut>la date du diagnostic du patient</description-attribut> </attribut> <attribut Nom-attribut="Observation"> <Nom-concept-attribut>Observation _Diagnostic</Nom-concept-attribut> <description-attribut>Observation sur la maladie</description-attribut> </attribut>

<CleP IDAttribut="Numordre code_diag codemed"/> <References IDrelation="Diagnostic"></References>

</Relation> </schema>

Figure 60 : Document XML décrivant la base de données BD1

208

<?xml version="1.0" encoding="UTF-8"?> <!-- edited with XMLSPY v2004 rel. 3 U (http://www.xmlspy.com) by hamdi (lisi) --> <Document> <relation nom-relation ="Malade"> <nom-concept>Patient</nom-concept> <description>relation contenant les informations sur les patients</description> <attribut nom-attribut="Code"> <nom-concept-attribut>Code</nom-concept-attribut> <description-attribut>Identifiant des patients </description-attribut> </attribut> <attribut nom-attribut="nom-malade"> <nom-concept-attribut>Nom</nom-concept-attribut> <description-attribut>Nom de famille du patient</description-attribut> </attribut> <attribut nom-attribut="Prenom-malade"> <nom-concept-attribut>Prenom</nom-concept-attribut> <description-attribut>prenom du patient</description-attribut> </attribut> <attribut nom-attribut="Datenaiss"> <nom-concept-attribut>date-naissance</nom-concept-attribut> <description-attribut>Date de naissance du patient</description-attribut> </attribut> <attribut nom-attribut="villenaissance"> <nom-concept-attribut>Lieu-naissance</nom-concept-attribut> <description-attribut> Lieu de naissance du patient </description-attribut> </attribut> <attribut nom-attribut="N_rue"> <nom-concept-attribut>Num-rue</nom-concept-attribut> <description-attribut> Numéro de la rue de l’adresse du patient </description-attribut> </attribut> <attribut nom-attribut="Rue"> <nom-concept-attribut>Rue</nom-concept-attribut> <description-attribut>La rue du patient</description-attribut> </attribut> <attribut nom-attribut="Codepostal"> <nom-concept-attribut>Code-postal</nom-concept-attribut> <description-attribut>Le code postal du patient</description-attribut> </attribut> <attribut nom-attribut="NSS"> <nom-concept-attribut>Num_sec_sociale</nom-concept-attribut> <description-attribut> Le numéro de sécurité sociale du patient </description-attribut> </attribut> <cleP nom-attribut="Code"> </cleP> <Refrences> <relation nom-relation ="Dossier-medical"> </relation> <relation nom-relation ="Maladie"/> <relation nom-relation ="Prescription"> </relation> <relation nom-relation ="Prescription-médicale"> </relation> <relation nom-relation ="Prescription_chirurgicale"> </relation> </Refrences> </relation> <relation nom-relation ="Dossier-medical"> <nom-concept>Dossier-medical</nom-concept> <description> Informations sur le dossier médical du patient </description> <attribut nom-attribut="Code"> <nom-concept-attribut>Code</nom-concept-attribut> <description-attribut>Identifiant des patients</description-attribut> </attribut> <attribut nom-attribut="id-dossier"> <nom-concept-attribut>id-dossier</nom-concept-attribut> <description-attribut>Identifiant du dossier médical</description-attribut> </attribut> <attribut nom-attribut="Date_creation"> <nom-concept-attribut>Date-creation</nom-concept-attribut>

209

<description-attribut>Date de la création du dossier médical</description-attribut> </attribut> <cleP> <attribut nom-attribut="Code"> </attribut> <attribut nom-attribut="id_dossier"> </attribut> </cleP> <Refrences> <relation nom-relation ="Maladie"/> <relation nom-relation ="Prescription"> </relation> <relation nom-relation ="Prescription-médicale"> </relation> <relation nom-relation ="Prescription_chirurgicale"> </relation> </Refrences> </relation> <relation nom-relation ="Maladie"> <nom-concept>Diagnostic</nom-concept> <description>Informations sur les diagnostics du patient</description> <attribut nom-attribut="Code"> <nom-concept-attribut>Code</nom-concept-attribut> <description-attribut>Identifiant des patients</description-attribut> </attribut> <attribut nom-attribut="id-dossier"> <nom-concept-attribut>id-dossier</nom-concept-attribut> <description-attribut>Identifiant du dossier médical</description-attribut> </attribut> <attribut nom-attribut="code_diag"> <nom-concept-attribut>code_diagnostic</nom-concept-attribut> <description-attribut> Identifiant de la maladie du patient </description-attribut> </attribut> <attribut nom-attribut="Date_diag"> <nom-concept-attribut>Date_diagnostic</nom-concept-attribut> <description-attribut> Identifiant de la maladie du patient </description-attribut> </attribut> <attribut nom-attribut="observation"> <nom-concept-attribut>Observation_diagnostic</nom-concept-attribut> <description-attribut> observation sur la maladie du patient </description-attribut> </attribut> <cleP> <attribut nom-attribut="Code"> </attribut> <attribut nom-attribut="id_dossier"> </attribut> <attribut nom-attribut="code_diag"> </attribut> </cleP> </relation> </Document>

Figure 61 : Document XML décrivant la base de données BD2

4.2 Schéma médiateur

Dans cette partie, nous montrons le déroulement de notre algorithme de génération de schéma

médiateur sur les deux bases de données BD1 et BD2 à partir des documents XML les décrivant.

Etape I : Initialisation Nous récupérons la liste des concepts à partir de chaque document décrivant les bases de données BD1 et BD2. A- Liste 1 : Patient, Diagnostic

210

Liste 2 : Patient, Dossier-medical, Diagnostic ETAPE A : Relation A traiter : Patient Patient (Numordre, nom, prenom, datenaiss, lieunaiss, profession, adresse, NSS)

1- Pour chaque base de données BDi faire : nous récupérons la relation décrite par le concept Patient

BD2 : La relation est Malade 2- Modification du schéma médiateur a- Médiateur : Création de la relation « Patient » <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMed SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD schemaMed.dtd"> <SchemaMed> <RelationMed nom-relation="Patient"> </RelationMed> </SchemaMed> b- Mapping : Création des correspondances entre la relation du schéma médiateur et celles des schémas sources. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMedMapping SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD MApping.dtd"> <SchemaMedMapping> <RelationMedMapping nom-relation="Patient"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> </lienRelation> </RelationMedMapping> </SchemaMedMapping> ETAPE B: Traitement des attributs I : Traitement des clés primaires

En appliquons la règle 29 de la création du schéma médiateur nous fusionnons les clés primaires des relations « Patient » et « Malade » a- Médiateur <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMed SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD schemaMed.dtd"> <SchemaMed> <RelationMed nom-relation="Patient"> <AttributMed nom-attribut="Numordre"></AttributMed> <AttributMed nom-attribut="code"></AttributMed> <CleP IDAttribut="Numordre code"></CleP> </RelationMed> </SchemaMed>

211

b- Mapping <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMedMapping SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD MApping.dtd"> <SchemaMedMapping> <RelationMedMapping nom-relation="Patient"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> </RelationMed> </SchemaMed> II Traitement des attributs non identifiant

Dans cette partie nous aller traiter les attributs des relations. Chaque traitement est composé de 4 parties.

a- Nous récupérons le concept qui décrit l’attribut contenu dans la relation en phase de traitement (dans notre cas la relation « Patient » de la base de données BD1)

b- Nous récupérons les attributs décrit par le concept trouvé en (a) c- Ajout de l’attribut dans le schéma médiateur portant le nom du concept trouvé en

(a) d- Modifier les règles de mapping : les liens entre le concept inséré en (c) et les

attributs récupérés en (b) L’attribut à traiter : Nom a- Nom du concept le décrivant : Nom b- BD 2 : nom-malade c- Médiateur <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMed SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD schemaMed.dtd"> <SchemaMed> <RelationMed nom-relation="Patient"> <AttributMed nom-attribut="Numordre"></AttributMed> <AttributMed nom-attribut="code"></AttributMed>

212

<AttributMed nom-attribut="Nom"></AttributMed> <CleP IDAttribut="Numordre code"></CleP> </RelationMed> </SchemaMed> d- Mapping <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMedMapping SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD MApping.dtd"> <SchemaMedMapping> <RelationMedMapping nom-relation="Patient"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Nom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Nom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Nom-malade</nom-attrib> </LienAttribut> </RelationMed> </SchemaMed> L’attribut à traiter : Prénom a- Prenom b- Prenom-malade c- Médiateur <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMed SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD schemaMed.dtd"> <SchemaMed> <RelationMed nom-relation="Patient"> <AttributMed nom-attribut="Numordre"></AttributMed>

213

<AttributMed nom-attribut="code"></AttributMed> <AttributMed nom-attribut="Nom"></AttributMed> <AttributMed nom-attribut="Prenom"></AttributMed> <CleP IDAttribut="Numordre code"></CleP> </RelationMed> </SchemaMed> d- Mapping <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMedMapping SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD MApping.dtd"> <SchemaMedMapping> <RelationMedMapping nom-relation="Patient"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Nom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Nom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Nom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Prenom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Prenom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Prenom-malade</nom-attrib> </LienAttribut> </AttributMedMapping>

214

</AttributMedMapping> </RelationMed> </SchemaMed> L’attribut à traiter : Datenaiss a- Date-naissance b- Datenaiss c- Médiateur <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMed SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD schemaMed.dtd"> <SchemaMed> <RelationMed nom-relation="Patient"> <AttributMed nom-attribut="Numordre"></AttributMed> <AttributMed nom-attribut="code"></AttributMed> <AttributMed nom-attribut="Nom"></AttributMed> <AttributMed nom-attribut="Prenom"></AttributMed> <AttributMed nom-attribut="Date-naissance"></AttributMed> <CleP IDAttribut="Numordre code"></CleP> </RelationMed> </SchemaMed> d- Mapping <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMedMapping SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD MApping.dtd"> <SchemaMedMapping> <RelationMedMapping nom-relation="Patient"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Nom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Nom</nom-attrib>

215

</LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Nom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Prenom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Prenom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Prenom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="date-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>datenaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>datenaissance</nom-attrib> </LienAttribut> </AttributMedMapping> </RelationMed> </SchemaMed> L’attribut à traiter : Lieunaiss a- Lieu-naissance b- Villenaissance c- Médiateur <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMed SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD schemaMed.dtd"> <SchemaMed> <RelationMed nom-relation="Patient"> <AttributMed nom-attribut="Numordre"></AttributMed> <AttributMed nom-attribut="code"></AttributMed> <AttributMed nom-attribut="Nom"></AttributMed> <AttributMed nom-attribut="Prenom"></AttributMed> <AttributMed nom-attribut="Date-naissance"></AttributMed> <AttributMed nom-attribut="Lieu-naissance"></AttributMed> <CleP IDAttribut="Numordre code"></CleP> </RelationMed> </SchemaMed> d- Mapping <?xml version="1.0" encoding="UTF-8"?>

216

<!DOCTYPE SchemaMedMapping SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD MApping.dtd"> <SchemaMedMapping> <RelationMedMapping nom-relation="Patient"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Nom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Nom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Nom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Prenom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Prenom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Prenom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="date-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>datenaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>datenaissance</nom-attrib>

217

</LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Lieu-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>lieunaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Villenaissance</nom-attrib> </LienAttribut> </AttributMedMapping> </RelationMedMapping> </SchemaMedMapping> L’attribut à traiter : Profession a- Profession b- Null c- Médiateur <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMed SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD schemaMed.dtd"> <SchemaMed> <RelationMed nom-relation="Patient"> <AttributMed nom-attribut="Numordre"></AttributMed> <AttributMed nom-attribut="code"></AttributMed> <AttributMed nom-attribut="Nom"></AttributMed> <AttributMed nom-attribut="Prenom"></AttributMed> <AttributMed nom-attribut="Date-naissance"></AttributMed> <AttributMed nom-attribut="Lieu-naissance"></AttributMed> <AttributMed nom-attribut="Profession"></AttributMed> <CleP IDAttribut="Numordre code"></CleP> </RelationMed> </SchemaMed> d- Mapping <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMedMapping SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD MApping.dtd"> <SchemaMedMapping> <RelationMedMapping nom-relation="Patient"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Code</nom-attrib>

218

</LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Nom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Nom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Nom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Prenom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Prenom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Prenom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="date-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>datenaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>datenaissance</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Lieu-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>lieunaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Villenaissance</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Profession"> <LienAttribut> <nomBase>BD1</nomBase>

219

<nom-rel>Patient</nom-rel> <nom-attrib>Profession</nom-attrib> </LienAttribut> </AttributMedMapping> </RelationMedMapping> </SchemaMedMapping> L’attribut à traiter : Adresse a- Adresse b- Nous appliquons la règle 26. Adresse n’existe pas dans la relation, par contre, elle contient

N_Rue, Rue et Codepostal qui composent le concept « Adresse ».

c- Médiateur <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMed SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD schemaMed.dtd"> <SchemaMed> <RelationMed nom-relation="Patient"> <AttributMed nom-attribut="Numordre"></AttributMed> <AttributMed nom-attribut="code"></AttributMed> <AttributMed nom-attribut="Nom"></AttributMed> <AttributMed nom-attribut="Prenom"></AttributMed> <AttributMed nom-attribut="Date-naissance"></AttributMed> <AttributMed nom-attribut="Lieu-naissance"></AttributMed> <AttributMed nom-attribut="Profession"></AttributMed> <AttributMed nom-attribut="Adresse"></AttributMed> <CleP IDAttribut="Numordre code"></CleP> </RelationMed> </SchemaMed> d- Mapping <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMedMapping SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD MApping.dtd"> <SchemaMedMapping> <RelationMedMapping nom-relation="Patient"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel>

220

<nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Nom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Nom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Nom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Prenom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Prenom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Prenom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="date-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>datenaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>datenaissance</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Lieu-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>lieunaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Villenaissance</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Profession"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Profession</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Adresse"> <LienAttribut>

221

<nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Adresse</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>N_rue</nom-attrib> <nom-attrib>Rue</nom-attrib> <nom-attrib>Codepostal</nom-attrib> <fctConv>Concatenat()</fctConv> </LienAttribut> </AttributMedMapping> </RelationMedMapping> </SchemaMedMapping> L’attribut à traiter : NSS a- Numéro_de_sécurite b- NSS c- Médiateur <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMed SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD schemaMed.dtd"> <SchemaMed> <RelationMed nom-relation="Patient"> <AttributMed nom-attribut="Numordre"></AttributMed> <AttributMed nom-attribut="code"></AttributMed> <AttributMed nom-attribut="Nom"></AttributMed> <AttributMed nom-attribut="Prenom"></AttributMed> <AttributMed nom-attribut="Date-naissance"></AttributMed> <AttributMed nom-attribut="Lieu-naissance"></AttributMed> <AttributMed nom-attribut="Profession"></AttributMed> <AttributMed nom-attribut="Adresse"></AttributMed> <AttributMed nom-attribut="NSS"></AttributMed> <CleP IDAttribut="Numordre code"></CleP> </RelationMed> </SchemaMed> e- Mapping <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMedMapping SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD MApping.dtd"> <SchemaMedMapping> <RelationMedMapping nom-relation="Patient"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut>

222

</AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Nom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Nom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Nom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Prenom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Prenom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Prenom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="date-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>datenaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>datenaissance</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Lieu-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>lieunaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Villenaissance</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Profession"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel>

223

<nom-attrib>Profession</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Adresse"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Adresse</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>N_rue</nom-attrib> <nom-attrib>Rue</nom-attrib> <nom-attrib>Codepostal</nom-attrib> <fctConv>Concatenat()</fctConv> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Num_sec_sociale"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>NSS</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>NSS </nom-attrib> </LienAttribut> </AttributMedMapping> </RelationMedMapping> </SchemaMedMapping> ETAPE A : Relation A traiter : Diagnostic Diagnostic (Numordre, code_diag, codemed, date_maladie, observation)

1- Pour chaque base de données BDi faire : nous récupérons la relation décrite par le concept

Diagnostic

BD2 : La relation est Maladie 2- Modification du schéma médiateur

a- Médiateur : Création de la relation « Diagnostic » <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMed SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD schemaMed.dtd"> <SchemaMed> <RelationMed nom-relation="Patient"> <AttributMed nom-attribut="Numordre"></AttributMed> <AttributMed nom-attribut="code"></AttributMed> <AttributMed nom-attribut="Nom"></AttributMed> <AttributMed nom-attribut="Prenom"></AttributMed> <AttributMed nom-attribut="Date-naissance"></AttributMed> <AttributMed nom-attribut="Lieu-naissance"></AttributMed> <AttributMed nom-attribut="Profession"></AttributMed>

224

<AttributMed nom-attribut="Adresse"></AttributMed> <AttributMed nom-attribut="NSS"></AttributMed> <CleP IDAttribut="Numordre code"></CleP> </RelationMed> <RelationMed nom-relation="Diagnostic"> </RelationMed> </SchemaMed> b- Mapping : Création des correspondances entre la relation du schéma médiateur et celles des schémas sources. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMedMapping SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD MApping.dtd"> <SchemaMedMapping> <RelationMedMapping nom-relation="Patient"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Nom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Nom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Nom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Prenom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Prenom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase>

225

<nom-rel>Malade</nom-rel> <nom-attrib>Prenom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="date-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>datenaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>datenaissance</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Lieu-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>lieunaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Villenaissance</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Profession"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Profession</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Adresse"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Adresse</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>N_rue</nom-attrib> <nom-attrib>Rue</nom-attrib> <nom-attrib>Codepostal</nom-attrib> <fctConv>Concatenat()</fctConv> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Num_sec_sociale"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>NSS</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>NSS </nom-attrib>

226

</LienAttribut> </AttributMedMapping> </RelationMedMapping> <RelationMedMapping nom-relation="Diagnostic"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> </lienRelation> </RelationMedMapping> </SchemaMedMapping> ETAPE B: Traitement des attributs I : Traitement des clés primaires

En appliquons la règle 29 de la création du schéma médiateur nous fusionnons les clés primaires des relations « Diagnostic » et « Maladie » a- Médiateur <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMed SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD schemaMed.dtd"> <SchemaMed> <RelationMed nom-relation="Patient"> <AttributMed nom-attribut="Numordre"></AttributMed> <AttributMed nom-attribut="code"></AttributMed> <AttributMed nom-attribut="Nom"></AttributMed> <AttributMed nom-attribut="Prenom"></AttributMed> <AttributMed nom-attribut="Date-naissance"></AttributMed> <AttributMed nom-attribut="Lieu-naissance"></AttributMed> <AttributMed nom-attribut="Profession"></AttributMed> <AttributMed nom-attribut="Adresse"></AttributMed> <AttributMed nom-attribut="NSS"></AttributMed> <CleP IDAttribut="Numordre code"></CleP> </RelationMed> <RelationMed nom-relation="Diagnostic"> <AttributMed nom-attribut="code_diagnostic"></AttributMed> <AttributMed nom-attribut="id_dossier"></AttributMed> <CleP IDAttribut="Numordre code id_dossier code_diagnostic"></CleP> </RelationMed> </SchemaMed> b- Mapping <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMedMapping SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD MApping.dtd"> <SchemaMedMapping> <RelationMedMapping nom-relation="Patient"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase>

227

<nom-rel>Malade</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Nom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Nom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Nom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Prenom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Prenom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Prenom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="date-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>datenaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>datenaissance</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Lieu-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>lieunaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase>

228

<nom-rel>Malade</nom-rel> <nom-attrib>Villenaissance</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Profession"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Profession</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Adresse"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Adresse</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>N_rue</nom-attrib> <nom-attrib>Rue</nom-attrib> <nom-attrib>Codepostal</nom-attrib> <fctConv>Concatenat()</fctConv> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Num_sec_sociale"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>NSS</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>NSS </nom-attrib> </LienAttribut> </AttributMedMapping> </RelationMedMapping> <RelationMedMapping nom-relation="Diagnostic"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Numordre</nom-attrib>

229

</LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="id_dossier"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>id_dossier</nom-attrib> </LienAttribut> </AttributMedMapping> </RelationMedMapping> </SchemaMedMapping> II Traitement des attributs non identifiant L’attribut à traiter : Codemed a- Nom du concept équivalent : Codemed b- BD 2 : Null c- Médiateur <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMed SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD schemaMed.dtd"> <SchemaMed> <RelationMed nom-relation="Patient"> <AttributMed nom-attribut="Numordre"></AttributMed> <AttributMed nom-attribut="code"></AttributMed> <AttributMed nom-attribut="Nom"></AttributMed> <AttributMed nom-attribut="Prenom"></AttributMed> <AttributMed nom-attribut="Date-naissance"></AttributMed> <AttributMed nom-attribut="Lieu-naissance"></AttributMed> <AttributMed nom-attribut="Profession"></AttributMed> <AttributMed nom-attribut="Adresse"></AttributMed> <AttributMed nom-attribut="NSS"></AttributMed> <CleP IDAttribut="Numordre code"></CleP> </RelationMed> <RelationMed nom-relation="Diagnostic"> <AttributMed nom-attribut="code_diagnostic"></AttributMed> <AttributMed nom-attribut="id_dossier"></AttributMed> <AttributMed nom-attribut="codemed"></AttributMed> <CleP IDAttribut="Numordre code id_dossier code_diagnostic"></CleP> </RelationMed> </SchemaMed> d- Mapping <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMedMapping SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD MApping.dtd"> <SchemaMedMapping> <RelationMedMapping nom-relation="Patient"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> </lienRelation>

230

<AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Nom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Nom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Nom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Prenom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Prenom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Prenom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="date-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>datenaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>datenaissance</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Lieu-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>lieunaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Villenaissance</nom-attrib>

231

</LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Profession"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Profession</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Adresse"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Adresse</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>N_rue</nom-attrib> <nom-attrib>Rue</nom-attrib> <nom-attrib>Codepostal</nom-attrib> <fctConv>Concatenat()</fctConv> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Num_sec_sociale"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>NSS</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>NSS </nom-attrib> </LienAttribut> </AttributMedMapping> </RelationMedMapping> <RelationMedMapping nom-relation="Diagnostic"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping>

232

<AttributMedMapping nom-attribut="Codemed"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Codemed</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="id_dossier"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>id_dossier</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="code_diagnostic"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>code_diag</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>code_diag</nom-attrib> </LienAttribut> </AttributMedMapping> </RelationMedMapping> </SchemaMedMapping> L’attribut à traiter : Date_maladie a- Date_diagnostic b- BD 1 : Date_diag c- Médiateur <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMed SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD schemaMed.dtd"> <SchemaMed> <RelationMed nom-relation="Patient"> <AttributMed nom-attribut="Numordre"></AttributMed> <AttributMed nom-attribut="code"></AttributMed> <AttributMed nom-attribut="Nom"></AttributMed> <AttributMed nom-attribut="Prenom"></AttributMed> <AttributMed nom-attribut="Date-naissance"></AttributMed> <AttributMed nom-attribut="Lieu-naissance"></AttributMed> <AttributMed nom-attribut="Profession"></AttributMed> <AttributMed nom-attribut="Adresse"></AttributMed> <AttributMed nom-attribut="NSS"></AttributMed> <CleP IDAttribut="Numordre code"></CleP> </RelationMed> <RelationMed nom-relation="Diagnostic"> <AttributMed nom-attribut="code_diagnostic"></AttributMed> <AttributMed nom-attribut="id_dossier"></AttributMed> <AttributMed nom-attribut="codemed"></AttributMed> <AttributMed nom-attribut="Date_diagnostic"></AttributMed> <CleP IDAttribut="Numordre code id_dossier code_diagnostic"></CleP> </RelationMed> </SchemaMed>

233

d- Mapping <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMedMapping SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD MApping.dtd"> <SchemaMedMapping> <RelationMedMapping nom-relation="Patient"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Nom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Nom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Nom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Prenom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Prenom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Prenom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="date-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>datenaiss</nom-attrib> </LienAttribut> <LienAttribut>

234

<nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>datenaissance</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Lieu-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>lieunaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Villenaissance</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Profession"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Profession</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Adresse"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Adresse</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>N_rue</nom-attrib> <nom-attrib>Rue</nom-attrib> <nom-attrib>Codepostal</nom-attrib> <fctConv>Concatenat()</fctConv> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Num_sec_sociale"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>NSS</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>NSS </nom-attrib> </LienAttribut> </AttributMedMapping> </RelationMedMapping> <RelationMedMapping nom-relation="Diagnostic"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel>

235

</lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Codemed"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Codemed</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="id_dossier"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>id_dossier</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="code_diagnostic"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>code_diag</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>code_diag</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Date_diagnostic"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Date_maladie</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>Date_diag</nom-attrib> </LienAttribut> </AttributMedMapping> </RelationMedMapping> </SchemaMedMapping> L’attribut à traiter : Observation a- Observation-diagnostic b- BD 1 : Observation

236

c- Médiateur <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMed SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD schemaMed.dtd"> <SchemaMed> <RelationMed nom-relation="Patient"> <AttributMed nom-attribut="Numordre"></AttributMed> <AttributMed nom-attribut="code"></AttributMed> <AttributMed nom-attribut="Nom"></AttributMed> <AttributMed nom-attribut="Prenom"></AttributMed> <AttributMed nom-attribut="Date-naissance"></AttributMed> <AttributMed nom-attribut="Lieu-naissance"></AttributMed> <AttributMed nom-attribut="Profession"></AttributMed> <AttributMed nom-attribut="Adresse"></AttributMed> <AttributMed nom-attribut="NSS"></AttributMed> <CleP IDAttribut="Numordre code"></CleP> </RelationMed> <RelationMed nom-relation="Diagnostic"> <AttributMed nom-attribut="code_diagnostic"></AttributMed> <AttributMed nom-attribut="id_dossier"></AttributMed> <AttributMed nom-attribut="codemed"></AttributMed> <AttributMed nom-attribut="Date_diagnostic"></AttributMed> <AttributMed nom-attribut="observation-diagnostic"></AttributMed> <CleP IDAttribut="Numordre code id_dossier code_diagnostic"></CleP> </RelationMed> </SchemaMed> d- Mapping <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMedMapping SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD MApping.dtd"> <SchemaMedMapping> <RelationMedMapping nom-relation="Patient"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Nom"> <LienAttribut>

237

<nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Nom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Nom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Prenom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Prenom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Prenom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="date-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>datenaissance</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>datenaiss</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Lieu-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>lieunaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Villenaissance</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Profession"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Profession</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Adresse"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Adresse</nom-attrib> </LienAttribut> <LienAttribut>

238

<nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>N_rue</nom-attrib> <nom-attrib>Rue</nom-attrib> <nom-attrib>Codepostal</nom-attrib> <fctConv>Concatenat()</fctConv> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Num_sec_sociale"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>NSS</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>NSS </nom-attrib> </LienAttribut> </AttributMedMapping> </RelationMedMapping> <RelationMedMapping nom-relation="Diagnostic"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Codemed"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Codemed</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="id_dossier"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>id_dossier</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="code_diagnostic"> <LienAttribut>

239

<nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>code_diag</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>code_diag</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Date_diagnostic"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Date_maladie</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>Date_diag</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Observation-diagnostic"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Observation</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>Observation</nom-attrib> </LienAttribut> </AttributMedMapping> </RelationMedMapping> </SchemaMedMapping> ETAPE A : Relation A traiter : Patient : Dossier-medical Dossier-medical (Code, id_dossier, date-creation) 1- Pour chaque base de données BDi faire : nous récupérons la relation décrite par le concept

Dossier-medical

BD2 : aucune relation équivalente 2- Modification du schéma médiateur a- Médiateur : Création de la relation Dossier-medical <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMed SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD schemaMed.dtd"> <SchemaMed> <RelationMed nom-relation="Patient"> <AttributMed nom-attribut="Numordre"></AttributMed> <AttributMed nom-attribut="code"></AttributMed>

240

<AttributMed nom-attribut="Nom"></AttributMed> <AttributMed nom-attribut="Prenom"></AttributMed> <AttributMed nom-attribut="Date-naissance"></AttributMed> <AttributMed nom-attribut="Lieu-naissance"></AttributMed> <AttributMed nom-attribut="Profession"></AttributMed> <AttributMed nom-attribut="Adresse"></AttributMed> <AttributMed nom-attribut="NSS"></AttributMed> <CleP IDAttribut="Numordre code"></CleP> </RelationMed> <RelationMed nom-relation="Diagnostic"> <AttributMed nom-attribut="code_diagnostic"></AttributMed> <AttributMed nom-attribut="codemed"></AttributMed> <AttributMed nom-attribut="codemedecin"></AttributMed> <AttributMed nom-attribut="Date_diagnostic"></AttributMed> <AttributMed nom-attribut="observation-diagnostic"></AttributMed> <CleP IDAttribut="Numordre code id_dossier code_diagnostic"></CleP> </RelationMed> <RelationMed nom-relation="Dossier-medical"> </RelationMed> </SchemaMed> b- Mapping : Création des correspondances entre la relation du schéma médiateur et celles des schémas sources. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMedMapping SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD MApping.dtd"> <SchemaMedMapping> <RelationMedMapping nom-relation="Patient"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Nom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Nom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel>

241

<nom-attrib>Nom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Prenom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Prenom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Prenom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="date-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>datenaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>datenaissance</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Lieu-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>lieunaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Villenaissance</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Profession"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Profession</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Adresse"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Adresse</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>N_rue</nom-attrib> <nom-attrib>Rue</nom-attrib> <nom-attrib>Codepostal</nom-attrib> <fctConv>Concatenat()</fctConv> </LienAttribut>

242

</AttributMedMapping> <AttributMedMapping nom-attribut="Num_sec_sociale"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>NSS</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>NSS </nom-attrib> </LienAttribut> </AttributMedMapping> </RelationMedMapping> <RelationMedMapping nom-relation="Diagnostic"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Codemed"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Codemed</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="id_dossier"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>id_dossier</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="code_diagnostic"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>code_diag</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel>

243

<nom-attrib>code_diag</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Date_diagnostic"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Date_maladie</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>Date_diag</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Observation-diagnostic"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Observation</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>Observation</nom-attrib> </LienAttribut> </AttributMedMapping> </RelationMedMapping> <RelationMedMapping nom-relation="Dossier-medical"> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Dossier-medical</nom-rel> </lienRelation> </RelationMedMapping> </SchemaMedMapping> ETAPE B: Traitement des attributs I : Traitement des clés primaires a- Médiateur <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMed SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD schemaMed.dtd"> <SchemaMed> <RelationMed nom-relation="Patient"> <AttributMed nom-attribut="Numordre"></AttributMed> <AttributMed nom-attribut="code"></AttributMed> <AttributMed nom-attribut="Nom"></AttributMed> <AttributMed nom-attribut="Prenom"></AttributMed> <AttributMed nom-attribut="Date-naissance"></AttributMed> <AttributMed nom-attribut="Lieu-naissance"></AttributMed> <AttributMed nom-attribut="Profession"></AttributMed> <AttributMed nom-attribut="Adresse"></AttributMed> <AttributMed nom-attribut="NSS"></AttributMed> <CleP IDAttribut="Numordre code"></CleP> </RelationMed> <RelationMed nom-relation="Diagnostic"> <AttributMed nom-attribut="code_diagnostic"></AttributMed> <AttributMed nom-attribut="codemed"></AttributMed>

244

<AttributMed nom-attribut="codemedecin"></AttributMed> <AttributMed nom-attribut="Date_diagnostic"></AttributMed> <AttributMed nom-attribut="observation-diagnostic"></AttributMed> <CleP IDAttribut="Numordre code id_dossier code_diagnostic"></CleP> </RelationMed> <RelationMed nom-relation="Dossier-medical"> <AttributMed nom-attribut="id_dossier"></AttributMed> <CleP IDAttribut="Numordre code id_dossier"></CleP> </RelationMed> </SchemaMed> b- Mapping <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMedMapping SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD MApping.dtd"> <SchemaMedMapping> <RelationMedMapping nom-relation="Patient"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Nom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Nom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Nom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Prenom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Prenom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel>

245

<nom-attrib>Prenom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="date-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>datenaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>datenaissance</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Lieu-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>lieunaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Villenaissance</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Profession"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Profession</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Adresse"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Adresse</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>N_rue</nom-attrib> <nom-attrib>Rue</nom-attrib> <nom-attrib>Codepostal</nom-attrib> <fctConv>Concatenat()</fctConv> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Num_sec_sociale"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>NSS</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>NSS </nom-attrib> </LienAttribut>

246

</AttributMedMapping> </RelationMedMapping> <RelationMedMapping nom-relation="Diagnostic"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Codemed"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Codemed</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="id_dossier"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>id_dossier</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="code_diagnostic"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>code_diag</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>code_diag</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Date_diagnostic"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Date_maladie</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel>

247

<nom-attrib>Date_diag</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Observation-diagnostic"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Observation</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>Observation</nom-attrib> </LienAttribut> </AttributMedMapping> </RelationMedMapping> <RelationMedMapping nom-relation="Dossier-medical"> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Dossier-medical</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Dossier-medical</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="id_dossier"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Dossier-medical</nom-rel> <nom-attrib>id_dossier</nom-attrib> </LienAttribut> </AttributMedMapping> </RelationMedMapping> </SchemaMedMapping> II Traitement des attributs non identifiant L’attribut à traiter : date-creation a- Nom concept : date-creation b- BD 1 : null c- Médiateur <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMed SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD schemaMed.dtd"> <SchemaMed> <RelationMed nom-relation="Patient"> <AttributMed nom-attribut="Numordre"></AttributMed> <AttributMed nom-attribut="code"></AttributMed> <AttributMed nom-attribut="Nom"></AttributMed> <AttributMed nom-attribut="Prenom"></AttributMed> <AttributMed nom-attribut="Date-naissance"></AttributMed> <AttributMed nom-attribut="Lieu-naissance"></AttributMed> <AttributMed nom-attribut="Profession"></AttributMed> <AttributMed nom-attribut="Adresse"></AttributMed> <AttributMed nom-attribut="NSS"></AttributMed>

248

<CleP IDAttribut="Numordre code"></CleP> </RelationMed> <RelationMed nom-relation="Diagnostic"> <AttributMed nom-attribut="code_diagnostic"></AttributMed> <AttributMed nom-attribut="codemed"></AttributMed> <AttributMed nom-attribut="codemedecin"></AttributMed> <AttributMed nom-attribut="Date_diagnostic"></AttributMed> <AttributMed nom-attribut="observation-diagnostic"></AttributMed> <CleP IDAttribut="Numordre code id_dossier code_diagnostic"></CleP> </RelationMed> <RelationMed nom-relation="Dossier-medical"> <AttributMed nom-attribut="id_dossier"></AttributMed> <AttributMed nom-attribut="date-creation"></AttributMed> <CleP IDAttribut="Numordre code id_dossier"></CleP> </RelationMed> </SchemaMed> d- Mapping <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMedMapping SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD MApping.dtd"> <SchemaMedMapping> <RelationMedMapping nom-relation="Patient"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Nom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Nom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Nom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Prenom"> <LienAttribut>

249

<nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Prenom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Prenom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="date-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>datenaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>datenaissance</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Lieu-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>lieunaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Villenaissance</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Profession"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Profession</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Adresse"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Adresse</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>N_rue</nom-attrib> <nom-attrib>Rue</nom-attrib> <nom-attrib>Codepostal</nom-attrib> <fctConv>Concatenat()</fctConv> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Num_sec_sociale"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel>

250

<nom-attrib>NSS</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>NSS </nom-attrib> </LienAttribut> </AttributMedMapping> </RelationMedMapping> <RelationMedMapping nom-relation="Diagnostic"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Codemed"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Codemed</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="id_dossier"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>id_dossier</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="code_diagnostic"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>code_diag</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>code_diag</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Date_diagnostic"> <LienAttribut>

251

<nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Date_maladie</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>Date_diag</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Observation-diagnostic"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Observation</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>Observation</nom-attrib> </LienAttribut> </AttributMedMapping> </RelationMedMapping> <RelationMedMapping nom-relation="Dossier-medical"> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Dossier-medical</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Dossier-medical</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="id_dossier"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Dossier-medical</nom-rel> <nom-attrib>id_dossier</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="date-creation"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Dossier-medical</nom-rel> <nom-attrib>date-creation</nom-attrib> </LienAttribut> </AttributMedMapping> </RelationMedMapping> </SchemaMedMapping> ETAPE C : Traitement des liens Patient : Cette relation est liée à : BD1 : Diagnostic BD2 : Dossier_medical

252

Nous reproduissons dans le schéma médiateur entre la relation « Patient » et les relations « Diagnostic » et « Dossier_medical ». Pour ce faire nous leur rajoutons les attributs « Numordre » & « Code ». Diagnostic : Les clés existent déjà Dossier-medical : Modifier Dossier-medical (Numordre,Code, id_dossier, date-creation) Dossier-medical : Cette relation est liée à : BD 1 : Null BD 2 : Null Schéma médiateur <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMed SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD schemaMed.dtd"> <SchemaMed> <RelationMed nom-relation="Patient"> <AttributMed nom-attribut="Numordre"></AttributMed> <AttributMed nom-attribut="code"></AttributMed> <AttributMed nom-attribut="Nom"></AttributMed> <AttributMed nom-attribut="Prenom"></AttributMed> <AttributMed nom-attribut="Date-naissance"></AttributMed> <AttributMed nom-attribut="Lieu-naissance"></AttributMed> <AttributMed nom-attribut="Profession"></AttributMed> <AttributMed nom-attribut="Adresse"></AttributMed> <AttributMed nom-attribut="Num_sec_sociale"></AttributMed> <CleP IDAttribut="Numordre code"></CleP> </RelationMed> <RelationMed nom-relation="Dossier-medical"> <AttributMed nom-attribut="id_dossier"></AttributMed> <AttributMed nom-attribut="date-creation"></AttributMed> <CleP IDAttribut="Numordre code id_dossier"></CleP> </RelationMed> <RelationMed nom-relation="Diagnostic"> <AttributMed nom-attribut="code_diagnostic"></AttributMed> <AttributMed nom-attribut="codemed"></AttributMed> <AttributMed nom-attribut="codemedecin"></AttributMed> <AttributMed nom-attribut="Date_diagnostic"></AttributMed> <AttributMed nom-attribut="observation-diagnostic"></AttributMed> <CleP IDAttribut="Numordre code id_dossier code_diagnostic"></CleP> </RelationMed> </SchemaMed>

Figure 62 : Document XML contenant le schéma médiateur

Règles mapping <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE SchemaMedMapping SYSTEM "C:\Documents and Settings\HAMDI\Bureau\thèse juin\DTD MApping.dtd"> <SchemaMedMapping> <RelationMedMapping nom-relation="Patient"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel>

253

</lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Nom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Nom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Nom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Prenom"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Prenom</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Prenom-malade</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="date-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>datenaiss</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>datenaissance</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Lieu-naissance"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>lieunaiss</nom-attrib>

254

</LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>Villenaissance</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Profession"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Profession</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Adresse"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Adresse</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>N_rue</nom-attrib> <nom-attrib>Rue</nom-attrib> <nom-attrib>Codepostal</nom-attrib> <fctConv>Concatenat()</fctConv> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Num_sec_sociale"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>NSS</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Malade</nom-rel> <nom-attrib>NSS </nom-attrib> </LienAttribut> </AttributMedMapping> </RelationMedMapping> <RelationMedMapping nom-relation="Diagnostic"> <lienRelation> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> </lienRelation> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> </lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut>

255

<nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Codemed"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Codemed</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="id_dossier"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>id_dossier</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="code_diagnostic"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>code_diag</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>code_diag</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Date_diagnostic"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Date_maladie</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>Date_diag</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Observation-diagnostic"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Diagnostic</nom-rel> <nom-attrib>Observation</nom-attrib> </LienAttribut> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Maladie</nom-rel> <nom-attrib>Observation</nom-attrib> </LienAttribut> </AttributMedMapping> </RelationMedMapping> <RelationMedMapping nom-relation="Dossier-medical"> <lienRelation> <nomBase>BD2</nomBase> <nom-rel>Dossier-medical</nom-rel>

256

</lienRelation> <AttributMedMapping nom-attribut="Code"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Dossier-medical</nom-rel> <nom-attrib>Code</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="id_dossier"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Dossier-medical</nom-rel> <nom-attrib>id_dossier</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="Numordre"> <LienAttribut> <nomBase>BD1</nomBase> <nom-rel>Patient</nom-rel> <nom-attrib>Numordre</nom-attrib> </LienAttribut> </AttributMedMapping> <AttributMedMapping nom-attribut="date-creation"> <LienAttribut> <nomBase>BD2</nomBase> <nom-rel>Dossier-medical</nom-rel> <nom-attrib>date-creation</nom-attrib> </LienAttribut> </AttributMedMapping> </RelationMedMapping> </SchemaMedMapping>

Figure 63 : Document XML contenant les règles de mapping