View
6
Download
0
Category
Preview:
Citation preview
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
Recommended