MEMOIRE
Présenté par
Melle SEDJELMACI
Wahiba
Pour obtenir
LE DIPLOME DE MAGISTER
Spécialité : Informatique
Option : Diagnostic, Aide à la Décision et Interaction Homme-Machine
Intitulé :
Membres de jury :
Mr
BOUAMRANE Karim Professeur, Université d’Oran, Algérie
(Président)
Mr
ATMANI Baghdad Docteur, Université d’Oran, Algérie
(Examinateur)
Mr
GHOMARI Abdelghani Docteur, Université d’Oran, Algérie
(Examinateur)
Mme
BABA-HAMED Latifa Docteur, Université d’Oran, Algérie
(Encadreur)
2012/2013
Détection des opérations de changement des
sources de données et leur impact sur un
système de médiation
DEDICACES
« Louange à Dieu, le tout puissant »
A mes très chers parents,
Pour leur soutien permanent et inépuisable,
Que Dieu les protège.
A mon adorable et très chère sœur
Djamila Manel que j’aime tant
Que Dieu la bénisse.
A son marie Raouf.
A mon frère bien aimé AbdelIleh.
A mon encadreur Mme Latifa Baba-Hamed
Que Dieu exauce ces vœux les plus chers.
A mes défunts grands parents
A mes tantes, mes oncles, mes cousins et cousines
A mes chères amies Samah, Fatima, Farah, Chahéra, Naima, Imène, Hassna,
Samira, Noura, Nessrine et Hanène
Et à tous ceux qui me sont chers.
A TOUS, je dédie ce travail en leur adressant tous mes sentiments
d’affection et de considération. i
REMERCIEMENTS
Je ne saurai remercier assez mon encadreur Madame Latifa Baba-
Hamed, Maître de Conférences à l’Université d’ESCENIA / Oran, pour m’avoir
proposé ce sujet et avoir dirigé mes travaux, pour sa constante disponibilité, pour
les conseils qu’elle n’a cessé de me prodiguer et surtout pour ses qualités
humaines et scientifiques, son encadrement privilégié, sa patience et ses
encouragements. Merci de tout cœur.
Que le Professeur Karim BOUAMRANE, trouve ici l’expression de ma
profonde reconnaissance et de ma très haute considération pour l’honneur qu’il
m’a fait en acceptant de présider le jury.
Tous mes remerciements accompagnés de ma gratitude vont aux membres
du jury Messieurs: Baghdad ATMANI et Abdelghani GHOMARI, pour la
célérité avec laquelle ils ont examiné, corrigé et critiqué ce travail.
Ma profonde reconnaissance va spécialement à ma famille: mon père, ma
mère, mon frère et ma sœur pour les orientations, la patience et l’intérêt qu’ils
m’ont toujours manifestés durant la progression de ce travail.
Une tendre pensée va à mes grands-parents qui, malheureusement, n’ont
pas pu voir l’aboutissement de mon travail.
Merci à mes chères collègues du département d’anglais, Karima et Naima
pour leur soutien moral.
Merci à mes amis de la promotion DADIHM 2009, Réda, Sid-Ahmed,
Naima, Nawel, Chahéra, Khadidja, Soumia et Imène. Sans oublier le membre des
enseignants de la PG- Dadihm: Mr Karim Bouamrane, Mme Djamila Hamdadou
, Mme Houria Taghzout, Mr Atmani et Mr Abdi.
Mes derniers remerciements et non les moindres, iront encore à mon encadreur
et à mes proches, et en particulier aux membres de ma petite famille qui m’ont
toujours apporté leur soutien sans faille. Je les remercie de toute l’affection et
tout l’amour qu’ils m’ont témoignés.
ii
La connaissance est un arbre de vie qui grandit à la lumière des autres.
Sommaire
Introduction générale………………………………………………………………………….1
Chapitre I : Intégration des données
Introduction :……………………………………………………………………………...……5
1. Problématique de l’Intégration de données……..………………………………………….5
1.1. Systèmes d’Intégration de données..…………………………………………………....6
1.2. Définition & Composante………………………………………………………….….6
1.3. Processus d’Intégration…………….…………………………………………………7
1.4. Tache d’un système d’Intégration...……………………………………………..……..8
2. Taxonomie de conflits d’Intégration………………………………………………...…....8
3. Classification des systèmes d’intégration...…………………………………………………9
3.1. Localisation de données intégrées……………………………………………………10
3.1.1. Entrepôts de données……………………………………………..……………10
3.1.2. Systèmes de médiation……………………………………………….…………11
3.1.3. Médiateurs / Entrepôt de données (Architecture Mixte/Hybride)………….……12
3.1.4. Systèmes P2P (Pair à Pair)……………………………………….……………..12
3.2. Mapping de données / Nature du mapping…………...………………………………13
3.2.1. GAV (Global as View)……………………………………………….………..13
3.2.2. LAV (Local as View)…………………….…………………………………….13
3.2.3. GlaV(Generalized Local as View)…….……………………………………….13
3.3. Processus d’Intégration / Automaticité du mapping…………………………………14
3.3.1. Manuel………………..…………………………………………………………14
3.3.2. Semi-automatique………………….……………………………………………14
3.3.3. Automatique……………………………………………………………………14
4. Traitement des requêtes dans un système d'Intégration…………………………………15
5. Comparaison entre les différentes approches d’Intégration…………………………..……15
Conclusion …………………………………………...………………………………………15
Sommaire
iii
Chapitre II : Etat de l’art: Génération & Adaptation des mappings
Introduction ..……………………………………………………… ……………………….16 1. Génération des Mappings…………………………………....……………………………16
1.1. Génération de Mappings dans des schémas Relationnels……………………………17
1.2. Génération de Mapping dans une représentation XML……………….………………20
1.3. Discussions……………….………………………………………………...…………24
1.4. Les limites des approches existantes……………..…………………………………26
2. Mapping d'Adaptation……………..…………………………..…………………………26
2.1. Approches Incrémentales……………………………………………………………..26
2.2. Approches de Composition de Mapping …………………………………………….31
2.3. Discussions………………………………………...………………….……………..34
2.4. Les limites des Approches Existantes………………………….……….………..…35
Conclusion …………………………………………………………………………………..36
Chapitre III : L’approche de détection et adaptation des mappings
Introduction……………………..………..………………………………………………….37
1. Principe général de l’approche……………………………………………………………37
2. Notions de métadonnées utilisées………………………………………………………..38
3. Description de l’algorithme MQG……………………………………………….……....40
3.1Relations de mapping de base (m-relation)…………………………………………..41
3.2 Relation de mapping étendues……………………………………………………...42
3.3 Relation de transition (t-relation)………………………….…………..……………42
3.4 Graphe d’opérations…………………………………………………………………43
3.5. Chemin de calcul…………………………………………………………...……….43
3.6. Génération de requêtes de médiation ………………………………………………...44
4. L’approche de détection et d’adaptation..…………..……………………………………45
4.1 Transformation et décomposition ………….………………………………………...46
4.2 Détection et identification des changements des schémas……………………………….47
4.2.1. Opérations de changement du schéma source …………….….………………..48
4.2.2 Comparaison de schémas………………………………………………………52
Sommaire
Sommaire
iv
4.2.3 Principe de l’algorithme de détection par inclusion …………...……………......58
4.3 La propagation des modifications vers le système de médiation………….56
4.3.1 Les primitives de propagation…………………………………………56
4.3.2 Les règles d’évolution ……………………………...………………….57
5 Processus de détection_propagation …………………..………………………………62
Conclusion…………………………………………………………………………………..63
Chapitre IV : Conception et Implémentation du Système
Introduction…………………………………………………………………………….....…65
1. Architecture de système……………………………………………………………..…..65
1.1. Description de la Méta-Base……………………..…………………………………66
1.2. Les différents modules du système………………………………………………......68
2. Conception du système MédiaSim…………………………………………………….…78
2.1 Diagramme d'état transition…………………………………………………………..78
2.2 Diagramme de classes…………………………………………………………………79
2.3 Diagramme de collaboration…………………………………………………………..82
2.4 Diagramme d'activité…………………………………………………………………83
Conclusion …………………………………………………………………………………...84
Chapitre V : Mise en œuvre et Implémentation
Introduction……………………………………...……………………………………….......86
1. Environnement de développement…………...…………………………………………...86
1.1. Pourquoi Oracle? ……………………………...…………………………………...86
1.2. Pourquoi Java ?………………………...…………………………………………....88
1.3. Communication Java Oracle (JDBC)……………………………………………….89
2. La synchronisation dans JAVA………………………...…………………………………91
2.1 Principe de la concurrence ……………………………………………………………91
2.1.1. L’exclusion mutuelle …………………………………………………………91
2.1.2. Définition de Ressource critique …………………………………………......91
v
2.1.3. Définition de Section critique …………………………………………….......92
2.1.4 Les caractéristiques des processus dans l’exclusion mutuelle ………………92
2.2 Les méthodes de synchronisation ………………………………………………….92
2.2.1 Les sémaphores……………………………………………………………………92
2.2.2 Exemple d’application de synchronisation……………………………………..92
2.3 La gestion de la synchronisation entre les processus du système de médiation…………97
2.4 La procédure de calcul d’une relation de médiation Rm …………………………………99
2.5 L’architecture générale de notre système de médiation……….……………….………..99
3. La description du fonctionnement de notre système MediaSim………………………….100
3.1 Diagramme des cas d'utilisation……………………………………………………..100
3.2 Accès à l’application…………………………………………………………………101
Conclusion…………………...……………………………………………………….……..104
Conclusion générale…………………………………………………………………………105
Références bibliographique…..…….……………………………………………………….107
Annexe………………………………………………………………………………………110
Sommaire
vi
Résumé
Le développement exponentiel d’échanges d’informations par le web a mis à jour les
difficultés pour retrouver l’information pertinente désirée par un utilisateur final. En effet, les
informations sont représentées et stockées dans une multitude de sources de données et cela
de façon très hétérogènes.
Les sources de données distribuées, hétérogènes et dynamiques sont autonomes et peuvent
subir des changements dans leurs schémas. Ces changements peuvent rendre les mappings
entre le schéma cible et les schémas des sources non cohérents, ce qui mène vers des réponses
incorrectes à l’utilisateur. L’adaptation de ces mappings s’avère donc nécessaire.
Dans cette thèse, nous proposons une nouvelle approche d’adaptation de mappings après la
détection des changements produits au niveau des sources dans un système de médiation. Le
processus adopté est réalisé en deux phases: une phase de détection des opérations de
changement et une phase de répercussion de ces changements au niveau des requêtes de
médiation.
Mots-clés : mapping, adaptation, détection, relation pertinente, règles de propagation,
grammaire de schéma, médiation, GAV, génération de requêtes de médiation.
Abstract
The exponential development of information exchanges over the Web had updated the
difficulties to find relevant information desired by a final user. Indeed, information is
represented and stored in a multitude of data sources with very heterogeneous way.
The distributed, heterogeneous data sources are autonomous and can undergo the
exchanges in his schemas. These exchanges can affect the mappings between mediation
schema and sources schemas which take not right response to user. The maintenance of these
mappings becomes necessary.
In this work, we propose a new approach to maintain the mappings after the exchanges
detected in source schemas. The adopted system is realized in too steps: step of detection of
exchanges operations and step of repercussion of these exchanges to the mediation level.
Key Words: mappings, adapt, detect, relevant entity, propagation rules, schema grammar,
mediator, mediation requests.
Résumé
9i
Table des figures
Chapitre I
Figure 1 : la structure d’un système de médiation……………………………………………………………..2
Figure 1.1 Système d’Intégration d’information. ........................................................................... ………....7
Figure 1.2 Architecture matérialisée vers architecture virtuelle………………………………………………12
Chapitre II
Figure 2.1 Exemple d’un graphe d’opération………………………………………………...18
Figure 2.2Approche de génération de requêtes dans le contexte relationnel………………..19
Figure 2.3 Utilisation des correspondances de valeurs pour relier deux attributs…………..19
Figure 2.4 Transformation schéma dans AutoMed…………………………………………20
Figure 2.5 Un schéma de médiation et trois schémas source dans le modèle de X-relation…23
Figure 2.6 Exemple de graphe d’opérations………………………………………………….24
Figure 2.7 La suppression des attributs…………………………………………………….....28
Figure 2.8 Trois règles d’évolution…………………………………………………………...30
Figure 2.9 Évolution de schéma source vers le schéma cible dans l'approche de composition du
mapping………………………………………………………………………………………...31
Figure 2.10 Deux schémas source HDM et un schéma global………………………...….......32
Figure 2.11 Évolution du schéma source S1 à S1 '……………………………………………33
Chapitre III
Figure 3.1 Principe de l’approche de détection et adaptation…………………………..…...38
Figure 3.2 Graphe d’opération pour associer à R1 et R2……………………………………..43
Figure 3.3 Processus de détection et d’adaptation des mappings...........................................45
Figure 3.4 Arbre général de la requête de médiation Q1 par niveau …………………….....46
Figure. 3.5 Les Arbres atomiques définies de l’arbre général AGQ1 …………………………47
Figure 3.6 (a) Schéma Src2……………………………………………………………………48
Figure 3.6 (b) nouvelle version de schéma Src2……………………………………………..48
Figure 3.7 (a)Schéma Src2 ……………………………………………………………………49
Figure 3.7 (b) nouvelle version de schéma Src2………………………………………………49
Figure 3.8 (a)- Schéma Src2 ………………………………………………………………….49
Figure 3.8 (b) – nouvelle version de schéma Src2………………………………....................49
Figure 3.9 (a)- Schéma Src2 ……………………………………………………......................50
Figure 3.9 (b) – nouvelle version de schéma Src2…………………………………………………….50
Figure 3.10 Comparaison entre les grammaires G1 et G2……………………………………………...51
Figure 3.11 Comparaison par inclusion entre les grammaires G1 et G2………………………………..51
Figure 3.12 les grammaires correspondantes aux arbres de Src2 et Q12 avant et après modification…..53
Figure 3.13 graphe d’opérations GR2 après la propagation de l’opération remove_attribute (S21,C)…..59
Figure 3.14 graphe d’opérations GR2 après la propagation de l’opération add_attribute (S21,B)……….60
Figure 3.15 graphe d’opérations GR2 après la propagation de l’opération rename_entity (S21, S2)……...61
Figure 3.19 Graphe d’opérations GR2 après la propagation de l’opération add_entity(S22, S2)…………..62
Chapitre IV
Figure. 4.1 Architecture globale du système d’évolution de schéma ............................................... …….66
Figure. 4. 2 étape de validation des dates de dernière modification …………….……………………………..69
Figure. 4.3 étape de validation de la requête atomique Q12………………………………………………..70
Table des figures
10ii
Figure. 4.4 Principe de base de l’algorithme d’inclusion……………………… …………………………..70 Figure 4.5 Réorganisation du graphe d’opérations de R2 après la détection des changements.....................72
Figure4.6.Structures utilisées dans la recherche des chemins de calcul de la relation de médiation R2…….74
Figure4.7 L’état des structures utilisées dans la recherche des chemins de calcul de la relation de médiation R2
après la rencontre du premier chemin………………………………………………………………..………..76
Figure 4.8 L’état des structures utilisées dans la recherche des chemins de calcul de la relation de médiation R2
après la rencontre du deuxième chemin……………………………………………………………………….77
Figure. 4.9 Diagramme d'état de l'étude préalable du système de médiation………………………………….79
Figure. 4.10 Diagramme de classes du système de médiation………………………………………………….81
Figure. 4.11 Diagramme de collaboration du système MédiaSim………………………...................................83
Figure. 4.12 Diagramme d'activité du système MédiaSim…………………………………………………….84
Chapitre V
Figure 5.1 la communication entre JAVA et JDBC………………………………90
Figure 5.2 LA description des primitive P(s) et V(s)……………………………..93
Figure 5.3 la structure d’un processus Pi…………………………………………94
Figure 5.4 Le contenue de processus P1 et P2 ……..…………………………………………...94
Figure 5.5 L’insertion des primitives P(S) et V(S) dans les codes de processus P1 et P2………94
Figure 5.6 : la structure de buffer…………………………………………………......................95
Figure 5.7 Les procédures de producteur-consommateur……………………………………….95
Figure 5.8 l’insertion des primitives P et V Cas un producteur et un Consommateur…………...96
Figure 5.9 : l’insertion des primitives P et V Cas p producteur et c consommateur……………..97
Figure 5.10 Déclaration d’un thread…………………………………………………...................98
Figure 5.11 Lancement d’un thread………………………………………………........................98
Figure 5.12 Architecture de MediaSim………………………………………………….............100
Figure 5.13 Diagramme des cas d'utilisation du système MédiaSim……………….…………..101
Figure 5.14 Représente la page de démarrage de MediaSim…………………………………...102
Figure 5.15 Représente l’interface principale de MediaSim……………………………………103
Table des figures
11x
Liste des tables
Chapitre I
Tableau 1.1 Taxonomie de conflits…………………………………………………................9
Tableau 1.2 Taxonomie de conflits…………………………………………………................5
Tableau 1.3 Comparaison entre les différentes approches d’Intégration………………........11
Chapitre II
Tableau 2.1 Les fonctions principales des différentes approches de génération de mapping.25
Tableau 2.2 Les descriptions des paramètres d’évolution d’une vue étendue……………….27
Tableau 2.3 Liste des primitives de propagation…………………………………………....29
Tableau 2.4 Les fonctions principales des différentes approches……………………………34
Tableau 2.5 Évolution de schéma source dans les différentes approches…………..…..….35
Chapitre III
Tableau 3.1 Notations utilisées……………………………….………………………….38
Tableau 3.2 la signification des assertions………………………………………………39
Tableau 3.3 Schémas des relations de médiation et des sources ...................................... ...41
Tableau 3.4 L’ensemble des relations de mapping de base pour la relation de médiation R1…41
Tableau 3.5 L’ensemble des relations de mapping étendu pour la relation de médiation R1. …..42
Tableau 3.6 Exemple de chemins de calcul pour chaque graphe d’opération……………..44
Tableau 3.7 les primitives de propagation des requêtes de médiation ..................... …..57
Chapitre IV
Tableau 4.1: Tableau décrivant les tables de la Méta-Base (niveau local) ……………67
Tableau 4.2: Tableau décrivant les tables de la méta base (niveau intermédiaire).........67
Tableau 4.3 : Tableau décrivant les tables de la Méta_Base (niveau global)………….68
Chapitre V
Liste des tables
x
Introduction Générale
« Plus s’étend et s’approfondie le champ de ma connaissance,
plus s’aiguise la conscience de l’étendu de mon ignorance. »
Michel Beaud
Quotidiennement, nous faisons appel à de différentes sources d’information pour obtenir
des éléments de réponse à des questions qui nous intéressent ou nous sont utiles. En général,
nos recherches d’information aboutissent rapidement car nous savons à quelles sources nous
adresser et comment interagir avec elles.
De plus en plus les sources d’information sont stockées sur des supports informatiques
sous forme de fichiers, bases de données ou pages Web. Ces sources hétérogènes et
distribuées sont intégrées via des systèmes, afin, de fournir une vue uniforme (appelée schéma
global) et de spécifier un ensemble de requêtes appelées requêtes de médiation ou mapping
opérationnels.
L’intégration de données est un domaine de recherche qui a pour but de proposer des
architectures pour la construction des systèmes de questions/réponses sur des informations
distribuées et hétérogènes provenant de multiples sources de données. Ces architectures de
données permettent aux utilisateurs d’accéder, à travers un schéma global unifié, à plusieurs
sources de données ayant chacune un schéma local. Ces sources de données sont le plus
souvent réparties, autonomes et hétérogènes.
Tout système d’intégration doit fournir les solutions aux problèmes suivants : (1)
Comment fournir une vue globale intégrée des données représentées à travers différentes
conceptualisations? (2) Comment identifier et spécifier le mapping entre des données
sémantiquement liées (c'est-à-dire prendre en compte l’hétérogénéité des sources de données
de façon à ce qu’elles soient conformes par rapport au schéma global) ? (3) Comment
propager les modifications détectées sur les différentes sources vers une telle vue globale
intégrée? Il a pour rôle d’offrir à l’utilisateur une vue uniforme et une interrogation
transparente des informations sans qu’il n’ait le souci de la provenance des informations ni de
leur format d’origine. Parmi ces systèmes d’intégration, nous distinguons les entrepôts de
données, les systèmes d’informations basés sur le web, ou encore les systèmes de médiation.
Un système de médiation est un système qui permet d’inter-opérer sur un ensemble de
sources hétérogènes et distribuées. La figure 1 illustre un exemple d’un système de médiation.
Ses composants essentiels sont :
Le schéma global (appelé schéma de médiation).
Introduction générale
Les mappings du schéma global avec les sources et les fonctions de transformation
concernant l’hétérogénéité des données. Les mappings du schéma global avec les sources
sont des requêtes, appelées requêtes de médiation.
La définition du schéma global, qui offre une vue uniforme des sources varie selon deux
approches :
L’approche ascendante (Global AS VIEW ou GAV) où chaque objet du schéma global
est défini par une requête sur les sources.
L’approche descendante (Local As View ou LAV) où chaque objet d’une source de
donnée est défini par une requête sur le schéma global.
Figure 1 : la structure d’un système de médiation
L’évolution de schéma dans un système de médiation est un domaine de recherche
d’actualité. Il s’agit de maintenir la cohérence du schéma global après un certain nombre
d’opérations de changements effectuées au niveau des sources de données. En effet, ces
Introduction générale
2
changements peuvent affecter certaines requêtes de médiation, et par conséquent, les réponses
aux requêtes des utilisateurs peuvent êtres erronées.
Très peu de travaux se sont intéressés à la détection d’opérations de changements
survenues sur les sources et à l’adaptation des mappings en même temps.
Ce travail, rentre dans le domaine de l’évolution des schémas, et plus précisément, à la
détection des changements (ajout, suppression et renommage d’une relation ou d’un attribut)
de plusieurs sources de données et à leurs propagations dans un système de médiation. Ce
problème revient à une gestion de concurrence entre les différents processus de détection,
d’adaptation et de génération de requêtes de médiation.
Pour ce faire, nous avons conçu une nouvelle méthode basée sur l’approche GAV, pour
définir les objets au niveau global, et sur le modèle relationnel, pour représenter les schémas
sources ainsi que le schéma global. Cette approche s’inspire de la méthodogie MQG
(Mediation Queries Generation) et combine deux processus principaux. Le premier est
consacré à la détection des changements opérés sur les schémas des sources. Le second
s’occupe de la propagation de ces changements sur les requêtes de médiation afin de garder la
cohérence du système. La méthode de synchronisation utilisée entre les processus pour gérer
la concurrence est la méthode des sémaphores.
Notre mémoire est organisé comme suit :
Dans le chapitre 1, nous présentons la problématique de l’intégration de données, quelques
définitions se rapportant aux systèmes d’intégration ainsi qu’une classification de ces
systèmes.
Le chapitre 2 constitue un état de l’art sur les principales approches des travaux de recherche
effectués dans le domaine de la génération automatique ou semi-automtique des requêtes de
médiation, et aussi, dans le domaine de l’évolution des mappings.
Le chapitre 3 est consacré à l’approche proposée de détection de changements et
d’adaptation des mappings. Nous exposons d’abord le principe de la méthode. Ensuite, nous
rappelons les étapes principales de l’algorithme MQG. Enfin, nous détaillons le
fonctionnement des deux processus (détection des changements et propagation de ces
changements vers le schéma global) en les déroulant sur un exemple.
Introduction générale
3
Le chapitre 4 décrit la conception détaillée de notre système. Nous commençons d’abord par
la présentation de l’architecture générale du système en expliquant ce que fait chaque module.
Ensuite, nous exposons la modélisation du système en UML.
Le chapitre 5 est dédié à la mise en œuvre et l’implémentation de notre système appelé
MediaSim. Il détaille, dans un premier temps, l’environnement de développement choisi.
Ensuite, il décrit les différentes méthodes utilisées pour la gestion des processus concurrents.
Il expose et explique le comportement de chacune et plus particulièrement celle portant sur les
sémaphores. Enfin, il termine avec la présentation de l’interface principale de MediaSim.
Dans l’annexe, nous rassemblons tous les algorithmes utilisés pour la réalisation de notre
projet.
Enfin nous terminons par une conclusion et quelques perspectives.
Introduction générale
4
Chapitre 1 Intégration des données
« Savoir pour bien Voir,
Bien voir pour Comprendre,
Et comprendre pour Savoir »
Introduction
Les systèmes d’intégration de données permettent aux utilisateurs d’accéder à travers un
schéma global unifié à plusieurs sources de données ayant chacune un schéma local. Bien que
les systèmes actuels puissent maitriser la difficulté principale d’intégration qui est
l’hétérogénéité des sources (XML, HTML, etc). Leur mise en œuvre pose des problèmes en
ce qui concerne la génération des liens sémantiques entre le schéma de médiation et les
sources de données (requêtes de médiation ou mappings), l’évolution de ces liens par rapport
aux changements définis dans le schéma de médiation ou bien dans les schémas des sources
ou la mesure de la qualité des données obtenues. Ces problèmes sont d’autant plus cruciaux
lorsque les sources sont nombreuses et hétérogènes.
Tout système d’intégration doit fournir les solutions aux problèmes suivants : (1)
Comment fournir une vue globale sur des données représentées à travers différentes
conceptualisations? (2) Comment identifier et spécifier le mapping entre des données
sémantiquement liées? (3) Comment mettre à jour les données de différentes bases avec une
telle vue globale intégrée? Dans ce premier chapitre, l’étude de ce type de systèmes est
abordée.
La suite de ce chapitre est organisée comme suit: dans la section 1, nous focalisons sur la
problématique de l’intégration de données. Dans la section2, une taxonomie des conflits est
présentée. La classification des systèmes d’intégration est abordée en section 3. Le traitement
de la requête en section 4 et un tableau de comparaison entre les approches d’intégration en
section 5.
1. Problématique de l’Intégration de données
Du fait du développement important de l'Internet, la recherche d'informations issues des
sources de données réparties sur le réseau devient de plus en plus difficile. En effet, grâce à la
révolution de nouvelles technologies de l’information, les entreprises aussi bien que les
individus disposent d’une grande quantité de données. Ces données sont stockées dans des
sources hétérogènes et autonomes.
Chaque source de données est décrite par sa localisation, le type de données qu'elle gère,
ses possibilités d'interrogation et le format des résultats.
Chapitre 1 Intégration des données
5
La localisation d'une source englobe toute la référence du site sur lequel se situe (URL,
adresse IP + port), ainsi que le protocole de communication utilisé (ex: TCP/IP), les
moyens d'accès à la base (ODBC, JDBC) ainsi que le support (pages Web, SGBD).
Le type de données géré par une source peut être structuré (base de données
relationnelles), semi structuré (sources XML) ou non structuré (images, texte libre).
Les possibilités d'interrogation définissent les langages de requêtes évolués et
standardisés (SQL, OQL) …
Enfin, les formats des résultats qui peuvent être définis suivant divers modèles standards
(XML, HTML, relationnel)…
Les sources de données auxquelles nous avons accès dans un contexte interconnecté, via
le Web, ont choisis leur propre représentation d’informations, de sorte que nous pouvons à
présent parler des sources de données Hétérogènes [1].
L’hétérogénéité se présente dans deux catégories :
(1) Structurelle : la manière dont sont représentées les données (par exemple: l’adresse peut
être représentée sur un seul champ, ou plusieurs : Rue, Code postal, Ville)
(2) Sémantique: en rapport avec la signification des données (synonymes, homonymes, etc.)
1.1. Systèmes d’Intégration de données
Les Systèmes d’Intégration de données offrent des architectures d’interopérabilité sur une
fédération de sources distribuées, autonomes et hétérogènes. Les entrepôts de données, les
systèmes de médiation et les architectures P2P sont des exemples d’infrastructures permettant
l’Intégration de données. À travers des schémas virtuels, des métadonnées et des
correspondances sémantiques, ils permettent l’accès à ces sources de façon uniforme et
transparente, en transformant les requêtes d’un utilisateur en sous requêtes envoyées aux
sources de données les plus appropriées.
1.2. Définition & Composante
Un système d'intégration permet l'accès à des données à travers une interface uniforme,
sans se soucier de leur structure ni de leur localisation.
Formellement, un système d’intégration de données est un triplé I: , où: G
représente le schéma global modélisant le schéma intégré, S est l’ensemble des schémas des
Chapitre 1 Intégration des données
6
sources décrivant la structure des sources participantes au processus d’intégration, M est une
correspondance entre G et S qui établit la connexion entre les éléments du schéma global et
ceux des sources.
Un système d'Intégration se compose de deux parties [2] (Voir figure 1.1):
Une partie (1) externe correspond aux utilisateurs du système intégré ou autres systèmes.
Une partie (2) interne et comprend des sources et une interface uniforme qui permet à la
partie externe d’interroger d'une manière transparente les sources de données, comme
s’il n’y avait qu’une seule source.
Figure 1.1 : Système d’Intégration d’information.
1.3. Processus d’Intégration
Etant donné un ensemble de sources hétérogènes {S1, S2, …, Sn}, le problème
d’intégration consiste à construire un schéma global à partir des schémas locaux. Ce problème
est lié au fait que les sources stockent des différents types de données, en différents formats,
ayant différentes significations et associées aux différents noms. Il convient d’abord
d’indiquer qu’il existe plusieurs méthodologies permettant l’intégration des bases de données
classiques. Nous présentons le processus dans le paragraphe suivant.
Le processus d’intégration est décomposé en trois phases distinctes :
La pré-intégration. Qui vise à préparer l’intégration des schémas en les rendant plus
homogènes. Elle consiste à traduire les schémas initiaux dans un modèle de données
commun.
L’identification des correspondances. Durant cette phase, les correspondances entre les
éléments des schémas source sont détectées et formalisées.
Chapitre 1 Intégration des données
7
L’Intégration. Cette phase finale produit le schéma intégré et fournit les règles de
traduction permettant de passer des schémas source au schéma intégré et
inversement « mapping».
1.4. Les tâches d’un système d’Intégration:
On peut distinguer quatre tâches principales d’un système d’Intégration. Les deux
premières concernent la traduction des données provenant des sources différentes en résolvant
le problème de l’hétérogénéité physique/logique des sources. Les deux dernières résolvent le
problème de l’hétérogénéité sémantique en reliant chaque source au schéma global. Ces
quatre tâches sont décrites ci-après :
1. Transformation de données (par exemple: la transformation de données relationnelles en
XML): Les problèmes devant être résolus à ce niveau sont la perte d’information, la taille des
données générées et la performance des traitements sur ces données.
2. Traduction de requêtes: La traduction des requêtes d’un langage (XQuery) en un autre
langage (SQL) est liée au problème de transformation de données.
3. Réécriture de requêtes: Cette tâche est différente de la tâche précédente et plus complexe
car elle doit prendre en compte l’hétérogénéité structurelle entre les schémas et
l’hétérogénéité sémantique (où la résolution consiste à identifier les objets sémantiquement
liés dans différentes sources et de résoudre la différence de schémas entre eux). Elle joue un
rôle important dans l’intégration de données sur le Web.
4. Fusion de données: essaye de répondre au problème de la représentation multiple d’une
même information dans différentes sources. Elle fait partie de la tâche de réécriture de
requête.
2. Taxonomie de conflits d’Intégration
Plusieurs types de conflits dus à l'hétérogénéité peuvent être considérés dans
l'établissement des correspondances entre schémas lors de l'intégration de données. De
nombreuses taxonomies de conflits sont abordées par les chercheurs dont six types sont
définis par Parent [25]. Qui sont décrit dans le tableau suivant:
Chapitre 1 Intégration des données
8
Tableau 1.1 Taxonomie de conflits
D’autres chercheurs proposent une autre classification des conflits qui peuvent apparaitre
lors de la mise en correspondance entre schémas. Ce sont détaillés dans le tableau suivant:
Tableau 1.2 Taxonomie de conflits Description
Type de conflits Description Exemple
Conflits de
nommage
Les différents schémas utilisent des
noms différents pour représenter le
même concept.
Les cas de présence de synonymes et d'homonymes.
Conflits de
graduation
Les concepts on la même signification
dans deux schéma mais sont différents
à cause de leur contexte.
On peut citer en exemple la mesure de température exemples : - Degrés Celsius
ou Fahrenheit. - Dollar $ ou l’Euro €.
Conflits de
confusion
Les concepts paraissent avoir la même
signification mais différent en réalité.
Ce type de confusion peut être causé par des contextes temporels différents. Par
exemple le poids d’une personne dépend de la date ou elle s’est pesée.
Conflits de
représentation
Deux schémas sources décrivent le
même concept de manière différente.
Dans une source, l'adresse peut être désignée par une chaine de caractères tandis
que dans une autre, par une structure composée du numéro et du nom de la rue,
du code postal et de la ville.
La diversification des sources de données, conduit à l'idée d'offrir à 1'utilisateur un système
permettant d'avoir une vue centralisée uniforme des données. Ainsi, les utilisateurs vont se
focaliser de spécifier ce qu’ils veulent et non pas perdre du temps en réfléchissant comment
obtenir la réponse, en interrogeant chaque source et en combinant les différents résultats
obtenus. A cet événement, les chercheurs se sont investis dans l'intégration des sources de
données qui est devenue un axe de recherche important.
3. Classification des systèmes d’intégration
Plusieurs approches et systèmes d’intégration ont été proposés dans la littérature, souvent
classifiés [3]. Il existe une classification des systèmes d’intégration en se basant sur trois
critères:
1 - Localisation de données intégrées: qu’elles restent dans les sources originales ou qu’elles
migrent vers le système global.
Chapitre 1 Intégration des données
9
2 - Nature de correspondance (mapping): entre le schéma global et les schémas locaux.
3 - L’automaticité du processus d’intégration: permet de produire le schéma global, le
mécanisme de médiation du schéma global et les schémas locaux, c’est-à-dire le système
d’intégration.
3.1. Localisation de données intégrées
Ce critère spécifie si les données des sources locales sont dupliquées au niveau du système
intégré ou pas. Les données du système intégré peuvent être matérialisées: l’architecture d’un
entrepôt de données (les données issues des différentes sources sont dupliquées au sein du
système). Ou virtuelles: l’architecture de médiateur (le système intégré fournit alors une
application chargée de jouer le rôle d’interface entre les bases de données locales et les
applications d’utilisateurs comme dans le projet TSIMMIS [4].
3.1.1. Entrepôts de données
Un entrepôt de données (Data Warehouse) se définit comme « une collection de données
intégrées, orientées sujet, non volatiles, historisées, résumées et disponibles pour
l’interrogation et l’analyse» [5]. Les entrepôts de données sont conçus dans un but particulier:
rassembler l’ensemble des informations d’une entreprise dans une base unique, pour faciliter
l’analyse et la prise de décision rapide.
Une illustration de l’architecture de ces Systèmes est présentée dans la figure 1.2. Les
données stockées dans l’entrepôt proviennent des sources multiples souvent hétérogènes.
Après leur extraction et leur transformation, elles sont stockées et organisées dans l’entrepôt
par sujet (clients, produits,…). Il existe donc une phase d’intégration lors de la conception
d’entrepôts mais cette intégration est matérialisée. Cela signifie qu’il y a une duplication des
données et qu’il n’est plus nécessaire d’accéder aux sources initiales pour répondre à une
requête.
Il existe également un schéma global dans un entrepôt de données qui est en effet
dynamique et de nouvelles sources sont susceptibles d’être intégrées fréquemment, des
données stockées peuvent être réorganisées (agrégées, ajoutées, supprimées, …), etc.
Dans un entrepôt de données on définit une approche LAV (Local-as-View: les sources
sont des vues sur le schéma global) pour l’intégration de données car toutes les informations
présentes dans les différentes sources ne sont pas nécessaires. Il est donc préférable de définir
Chapitre 1 Intégration des données
10
d’abord le schéma global de l’entrepôt qui reflète l’information nécessaire et puis établir la
correspondance avec les sources (approche descendante), plutôt que de se concentrer sur les
sources, avant de produire le schéma global (approche ascendante).
3.1.2. Systèmes de médiation
L’approche d’Intégration par médiation constitue aujourd’hui la solution la plus courante
pour relier différentes sources qui ne correspondent pas nécessairement à des bases de
données. La notion de médiateur a été initialement proposée par [6]. Il définit un médiateur
comme suit:
Un médiateur doit être vu comme une couche logicielle permettant d’accéder de manière
transparente aux différentes ressources (Bases de données, fichiers…) réparties et
hétérogènes. Pour ce faire, le médiateur exploite des connaissances (métadonnées) qui sont
utiles aux différents services (interrogation, localisation des ressources).
L’approche par médiation est fondée sur la définition de vues. Les données ne sont pas
stockées dans le système de médiation mais résident dans leur source d’origine. L’utilisateur
à une vision unifiée des données sources: l’interrogation se fait par l’intermédiaire d’un
schéma global. Il n’a pas de connaissance des schémas locaux.
L’architecture générale d’un système de médiation est présentée en figure 1.2. Une requête
globale est posée via le schéma global, celle-ci est ensuite décomposée en sous requêtes,
traduites pour être exécutées sur les différentes sources concernées.
Le médiateur est chargé de localiser les données pertinentes pour répondre à la requête (en
utilisant les métadonnées). L’interrogation effective des sources se fait par des adaptateurs qui
constituent une interface d’accès aux différentes sources. Ces adaptateurs traduisent les sous
requêtes exprimées dans le langage de requête spécifique de chaque source. Les résultats sont
ensuite renvoyés au médiateur qui se charge de les intégrer avant de les présenter à
l’utilisateur.
Chapitre 1 Intégration des données
11
Figure 1.2 Architecture matérialisée vers architecture virtuelle.
Les médiateurs se distinguent les uns des autres par la façon dont est établie la
correspondance (mapping) entre le schéma global et les schémas locaux. Deux approches
principales existent: l’approche Global as View (GAV) et l’approche Local as View (LAV).
Elles seront abordées dans les paragraphes suivants.
Il faut noter que la médiation ne s’adresse pas uniquement à des bases de données. De
nombreux médiateurs permettent d’intégrer des données semi structurées comme XML. Dont
le but est de construire un entrepôt de données dynamique regroupant des documents XML du
Web. L’utilisateur interroge les sources de données à travers une description abstraite des
documents. Cette description correspond au schéma global qui structure différents domaines
sous forme d’arbres.
3.1.3. Médiateurs / Entrepôt de données (Architecture Mixte/Hybride)
Avec le développement du Web, d'autres approches d'intégration tels que les systèmes
hybrides (approche mixte) ont été proposés. Ces Systèmes combinent à la fois l’approche
médiateur et l’approche entrepôt. Il s’agit, par exemple, d’un médiateur qui intègre plusieurs
sources de données externes et qui exploite un entrepôt de données contenant des données
conformes au schéma global du médiateur. Xylème en est un exemple de ce type
d’architecture.
3.1.4. Systèmes P2P (Pair à Pair)
L'émergence des systèmes de partage de fichiers pair à pair (Peer-to-Peer) a conduit les
chercheurs pour considérer l'architecture P2P dans le contexte de l'intégration et le partage de
données. Ces systèmes P2P suivent une approche décentralisée pour l'intégration des pairs
autonomes et distribués contenant des données qui peuvent être partagées. L'objectif principal
Chapitre 1 Intégration des données
12
de tels systèmes est de fournir une interopérabilité sémantique entre plusieurs sources en
l'absence de schéma global.
Chaque pair est interconnecté avec un certain nombre de pairs du réseau (appelés voisins) à
l'aide de formules de coordination. Détela [7], SomeWhere [8], PIAZZA [9] sont des
exemples de travaux récents sur les systèmes P2P.
3.2. Mapping de données / Nature du mapping
La méthode la plus ancienne pour définir la correspondance schéma global/schémas
locaux, consiste à utiliser le concept classique de "vue SQL" existante dans les bases de
données. GAV(Global-as-View), LAV(Local-as-View), GLAV(Generalized -Local-as-View),
représentent les méthodes de mapping les plus connues, que nous allons présenter dans les
sections suivantes.
3.2.1. GAV(Global as View)
Dans l'approche GAV (Global-as-View) chaque entité du schéma médiateur est une
requête sur les sources de données. L'approche GAV a l'avantage de faciliter
considérablement la reformulation de requêtes par un simple dépliement. Cependant, l'ajout
d'une nouvelle source peut engendrer des mises à jour complexes du médiateur.
3.2.2. LAV(Local as View)
Dans cette approche, les sources de données S sont définies comme un ensemble de vues
sur le schéma global G. Dans ce cas, la base de correspondance M associe à chaque élément
de S une requête sur G.
L'avantage principal de l'approche LAV (Local-as-View) est de faciliter l'ajout d'une
nouvelle source. Cependant l'évaluation des requêtes peut s'avérer complexe. Par ailleurs, tout
changement au niveau du schéma global peut être difficile à répercuter au niveau des vues
définissant les sources. Pour cette raison, l'approche est choisie dans le cas où le schéma
global n'est pas sujet à de fréquentes modifications.
3.2.3. GlaV (Generalized Local as View)
Les avantages des approches LAV et GAV ont été combinées dans une approche mixte.
Dans l'approche GlaV (Generalized-Local-as-View), qui utilise des règles de correspondance
Chapitre 1 Intégration des données
13
ayant plus d'un terme dans leur entête (l'entête peut être la combinaison d'un nombre
quelconque de prédicats, contrairement à l'approche LAV ou GAV).
Dans GlaV (Generalized-Local-as-View), on dispose de vues au niveau global et local.
Une correspondance entre les vues au niveau global et local est requise. Ces correspondances
s’appliquent dans les deux sens puisque les concepts dans l’ontologie globale sont considères
comme des vues. Dans l’approche hybride modélisée selon GlaV, nous gardons une
indépendance entre les sources (permet l’ajout et la suppression de sources), et nous pouvons
calculer indirectement les correspondances entre les sources. Cette caractéristique est
impérative si nous voulons avoir des résultats cohérents.
3.3. Processus d’Intégration / Automaticité du mapping
Un troisième critère important permet de caractériser l’automaticité de génération du
système intégré. La notion de passage à l’échelle, on peut caractériser cette automaticité par
l’automaticité d’Intégration d’une nouvelle source au sein d’un système intégré.
3.3.1. Manuel
Dans les Systèmes d’Intégration, la synthèse des schémas locaux et les correspondances
schéma global/schémas locaux sont faites manuellement. La signification des concepts
utilisés, au niveau global et au niveau local, étant explicite, aucun traitement automatique ne
peut être envisagé.
3.3.2. Semi-automatique
Un premier niveau d’automatisation devient possible lorsqu’on a utilisé (ensemble:
synonymes, homonymes, etc.). Une telle Intégration est qualifiée de semi-automatique car le
domaine visé par l’intégration est suffisamment limité et formalisé, l’ontologie de domaine
peut s’exprimer sous forme de prédicats de valeurs logiques. C’est le cas par exemple, dans
les approches orientées relations, des Systèmes tels que Manifold.
3.3.3. Automatique
Dans les deux types de mapping précédents, il suffit que la nouvelle source soit
explicitement exprimée en fonction de l’ontologie globale pour que l’Intégration automatique
soit possible.
Chapitre 1 Intégration des données
14
4. Traitement des requêtes dans un système d'Intégration
Dans un système d'intégration, l'interrogation s'effectue généralement en utilisant des
requêtes conjonctives (de type sélection-projection-jointure) à base de règles définies à l'aide
du vocabulaire du schéma global qui exprime les vues sur les différentes sources. On parle
alors d'interrogation basée sur les vues.
Dans un système d'Intégration, les requêtes étant posées sur le schéma médiateur en
utilisant un certain nombre de vues, le système essaie d'effectuer la réécriture des requêtes des
utilisateurs en s'assurant que les requêtes réécrites sont soit équivalentes aux requêtes initiales,
soit incluses en essayant de trouver la meilleure solution possible par rapport aux sources
disponibles.
5. Comparaison entre les différentes approches d’Intégration
Dans ce tableau, une classification des approches de mapping est proposée selon leur
automaticité, sociabilité, traitement des requêtes extension, maintenance, avantages et limites.
Tableau 1.3 Comparaison entre les différentes approches d’Intégration
Approches Passage à l’échelle Extension Avantage Limites
GAV Etude Maj. manuelle Réécriture facile des vues Ajout d’une source difficile
LAV Oui Maj manuelle Ajout d’une source facile Réécriture difficile
GLaV Oui Maj manuelle Réécriture facile des vues Ajout d’une source facile
Conclusion
Dans ce chapitre, nous avons défini la problématique de l’intégration de données, à savoir
l’hétérogénéité de données. La question fondamentale lorsque l’on veut faire interopérer des
bases de données hétérogènes est d’une part, l’identification de conflits entre les concepts
dans des sources différentes qui ont des liens sémantiques, d’autre part, la résolution de ces
conflits entre les concepts sémantiquement liés. Une taxonomie des conflits sémantiques qu’il
convient de résoudre a été présentée.
La suite de ce mémoire est consacré à représenter un état de l’art sur les différentes
approches de génération et adaptation des mapping dans le système d’intégration
«Médiateur».
Chapitre 1 Intégration des données
15
Chapitre 2 Etat de l’art
Génération & Adaptation Des mappings
« Dans la vie, il n’y a pas de solution.
Il y a des forces en marche :
Il faut les créer et les solutions suivent.»
Antoine de Saint-Exupéry
Introduction
Beaucoup d'applications exigent l'utilisation des données stockées dans des sources
multiples distribuées et hétérogènes. Considérant que les besoins des applications sont
représentés par un schéma cible, les mappings doivent être définies pour exprimer les
instances d'un schéma cible qui sont dérivées des instances des schémas source. Ces mappings
sont utilisés dans des différents contextes: Entrepôts de données et les systèmes de
médiation…etc.
La définition manuelle des mappings est une tâche difficile, en particulier si nous avons
un grand nombre de sources de données. Le concepteur doit définir des liaisons sémantiques
non seulement sur toutes les sources de données, mais aussi entre les sources et le schéma
cible. En parallèle, déterminer une méthode pour générer ces mappings. Pour cette fin,
beaucoup de recherches ont été proposées.
Les mappings dépendent des schémas qu'ils relient; quand un de ces schémas évolue, les
mappings existantes peuvent devenir obsolètes et ont besoin d’être redéfinis. La redéfinition
dans ce contexte est un processus coûteux, l'adaptation des mappings original par rapport aux
nouveaux schémas semblent être plus performant en termes d'exécution. Il y a quelques
solutions pour l'adaptation des mappings.
Dans le reste du chapitre, nous présentons un état de l'art sur la génération des mappings
dans la section 1. La section 2 décrira les approches d’adaptation des mappings et discutera
leurs solutions.
1. Génération des Mappings
Le principe de génération des mappings: consiste à produire des requêtes spécifiant des
instances d'un schéma cible dérivé des instances d'un ensemble de schéma sources.
La génération manuelle des mappings est difficile à réaliser, particulièrement en présence
de plusieurs schémas source car nous avons besoin de gérer un grand nombre de métadonnées
des schémas et toutes les liaisons entre ces schémas. Par conséquent, plusieurs chercheurs ont
proposé des solutions dans la génération de mapping semi-automatique ou automatique.
Parmi ces approches, nous distinguons entre les approches de génération dans les schémas
relationnels [10], [11] et [12] et celles dans la représentation XML [13] et [14]. Dans cette
Chapitre 2 Etat de l’art Génération & Adaptation des mappings
16
section, nous décrivons le principe des différentes approches de génération de mapping. Nous
présentons dans la section 1.1 celles qui se basent sur les schémas relationnels. Section 1.2
décrit celles qui génèrent les mappings dans une représentation XML. La section 1.3
commente les approches abordées. La section 1.3 présente les limites de ces approches.
1.1. Génération de Mappings dans des schémas Relationnels
Deux approches, Kedad et Bouzeghoub [10], Clio [11], ont proposé une méthode de
génération des mappings entre des schémas cibles et des schémas sources exprimés en
relationnel, détaillées dans ce qui suit.
Kedad and Bouzeghoub [10]
Leur approche était proposée dans le contexte des systèmes de médiation où les schémas
cibles sont appelés: schémas de médiation et les mappings sont appelés des requêtes de
médiation. L'objectif de cette approche est de générer un ensemble de requêtes de médiation
dérivées des schémas sources pour répondre au schéma de médiation. Le processus de
génération pour une relation de médiation comprend trois étapes: (i) recherche des sources
contributives; (ii) Identification des opérations candidates; (iii) définition des requêtes de
médiation.
L’étape de recherche des sources contributives déterminent toutes les relations sources qui
contribuent au calcul de la relation de médiation. Une relation source Si est contributive si elle
inclut quelques attributs de la relation de médiation. Dans ce cas, une relation de mapping est
extraite; ensuite, nous ajoutons les clefs primaires et étrangères de Si. Considérons l'exemple
suivant dans lequel il y a une relation de médiation Rm (#K, A, B, C) et quatre relations
sources S1 (#K, A, @X, Y), S2 (#X, B, Z), S3 (#B, C, W) et S4 (#B, C, U). Les clefs primaires
sont préfixés par # et les clefs étrangères par @. Dans cet exemple, quatre relations de
mapping sont obtenues de S1, S2, S3 et S4: T1(#K, A, @X), T2(#X, B), T3(#B, C) et T4(#B, C).
L’étape d'identification des opérations candidates cherche les jointures possibles entre les
relations de mapping. Une jointure est possible entre deux relations de mapping T1 et T2 (i) si
T1 et T2 sont dans la même source donc c’est une contrainte référentielle explicite entre eux
ou (ii) si T1 et T2 sont dans des sources différentes, la clef primaire de l’une a un attribut
équivalent dans l'autre. La figure 2.1 détermine ce cas, la jointure 1 est possible entre T1 et T2
car il y a une contrainte référentielle de T1 à T2 par l'attribut X. La jointure 2 est possible entre
T2 et T3 car l'attribut B existe dans T2 et T3 et B est défini comme une clef dans T3.
17
Chapitre 2 Etat de l’art Génération & Adaptation des mappings
Il existe des cas où nous ne pouvons pas retrouver des opérations candidates entre deux
relations de mapping, cependant, nous cherchons une troisième relation qui pourrait les relier.
Cette relation s’appelle relation de transition, contenant seulement des clefs primaires et des
clefs étrangères non communes avec les attributs de la relation de médiation. Par exemple,
considérons les deux relations de mapping T5 (#D, E) et T6 (#F, G): il n’est pas possible de
définir une jointure entre eux. Supposons qu'il y a une autre relation source S7 (#F, @D, H)
avec F, D et H n’appartiennent pas à la relation de médiation. Une relation de transition est
générée de S7; contenant des clefs étrangères et des clefs primaires: T7 (#F,@D). S7 peut être
utilisé pour relier T5 et T6 avec une jointure entre T5 et T7 avec l'attribut D et une jointure
entre T6 et T7 avec l'attribut F. L’ensemble des relations de mapping et des relations de
transition constituent l’ensemble des relations pertinentes.
Figure 2.1 Exemple d’un graphe d’opération
Les relations pertinentes et les jointures entre eux peut être représenté par un graphe
(appelé graphe d'opérations). Dans lequel chaque nœud est une relation pertinente et chaque
arrête est une jointure. Sur le graphe d'opération, la requête de médiation est définie par un
chemin de calcul, qui est un sous-graphe connecté, acyclique définissant tous les attributs de
la relation de médiation. La définition des requêtes de médiation consiste à énumérer tous les
chemins de calcul du graphe d'opérations. Dans l'exemple de la Figure 2.1, C1 = (1, 3) et C2 =
(1, 2) sont deux chemins de calcul. Leurs requêtes de médiation correspondantes sont
respectivement:
Les opérations telles que: l’union, la différence, l'intersection peut être utilisée sur les
requêtes de médiation pour dériver de nouvelles requêtes de médiation. Par exemple, une
troisième requête de médiation peut être générée en appliquant l'une union entre E1 et E2 :
Chapitre 2 Etat de l’art Génération & Adaptation des mappings
18
Miller et al. [15]
Proposent dans le contexte relationnel une approche de génération de requêtes de
médiation en utilisant l’outil CLIO. La figure suivante résume leur approche:
Figure 2.2 : Approche de génération de requêtes dans le contexte relationnel
Cette approche est basée sur des correspondances de valeurs définies entre les attributs
sources et les attributs du schéma global. Par exemple l’attribut caller de la relation calls et
l’attribut Artifact dans la relation du schéma global references sont reliés par une
correspondance de valeur f2.
Figure 2.3 Utilisation des correspondances de valeurs pour relier deux attributs
Les relations sources et la relation du schéma global représentent les nœuds du graphe, et
les liens entre un attribut source et un attribut du schéma global représentent les arcs du
graphe. La correspondance de valeur fi assignée à chaque arc est une correspondance de
valeur qui permet de relier deux attributs. Elle est soit déterminée par une technique de
matching particulière (d’apprentissage, statistiques, ontologie,… etc), soit définie au préalable
manuellement par le concepteur du système.
L’approche de génération de requêtes compte essentiellement quatre phases :
Chapitre 2 Etat de l’art Génération & Adaptation des mappings
19
1- partitionnement des correspondances: cette phase prend en entrée l’ensemble de
correspondances de valeurs noté V, qui sera partitionné en générant un autre ensemble P =
{C1, C2, Ci,…, Cn} où chaque Ci contient une seule correspondance possible pour un
attribut de la relation du schéma global. En d’autres termes si pour le même attribut du
schéma global il existe plus d’une correspondance avec les attributs sources, une seule
correspondance est prise en compte. Le résultat de cette phase est un ensemble de
correspondances potentiel au calcul d’une relation du schéma global.
2- Sélection des correspondances: cette phase prend en entrée l’ensemble de
correspondances potentiel et cherche des combinaisons candidates entre les relations
sources pour le calcul de la relation du schéma global. Elle est basée sur un algorithme qui
utilise des clés étrangères. Ces clés sont définies au préalable ou recherchés par un
algorithme de datamining. Le résultat de cette phase est un ensemble de correspondances
candidates noté C P.
3- Identification et choix d’une couverture: cette phase prend en entrée l’ensemble C de
combinaisons candidates et cherche un sous ensemble de C dit couverture où toutes les
correspondances de valeurs de l’ensemble V apparaissent une seule fois. Si plusieurs
couvertures sont identifiées la couverture qui contient le moins de combinaisons
candidates est choisie.
4- Génération de requêtes: cette dernière phase prend en entrée la couverture sélectionnée.
Pour chaque combinaison candidate une requête SQL est construite. Les requêtes générées par
le système CLIO et qui permettent de calculer la relation références sont les suivantes:
Q1: Select C.Caller, C.Callee, relname (c), F.File
From Function F,left outer join Calls C
Where C.Caller = F.Name
Q2: Select C.Caller, C.Callee, relname (c), F.File
From Function F,left outer join Calls C
WhereC.Callee = F.Name
1.2. Génération de Mapping pour Représentations XML
D’autres approches ont été proposé pour générer des mappings pour des schémas cibles et
source définis en modèle XML tel que: AutoMed [13] et Farias LóScio et Salgado [14]… qui
sont décrites dans ce qui suit :
Chapitre 2 Etat de l’art Génération & Adaptation des mappings
20
AutoMed [13]
Cette approche génère des transformations (des mappings) d'un schéma dans le système
AutoMed. Les schémas des sources de données sont représentés par XML Data Source
Schéma dans AutoMed. Quatre constructeurs sont définis dans XML Data Source Schéma:
éléments, attributs, rapports père-fils entre les éléments et les textes. La figure 2.4 montre un
exemple de transformation de schéma dans AutoMed entre deux schémas S1 et S2. Les deux
schémas contiennent les quatre constructeurs. Les éléments sont représentés par des rectangles
et les attributs sont représentés par ellipse.
Pour résoudre le problème des éléments multiples du même schéma ayant le même nom,
chaque élément ou attribut est suivi par un numéro unique dans le schéma. Les textes sont
représentés par des structures PCDATA. Les rapports père-fils entre les éléments sont
représentés par des arrêtes et des règles sont spécifiées pour des arrêtes ayant le même père.
Figure 2.4 Transformation schéma dans AutoMed
La transformation dans AutoMed est décrite par une séquence de transformations
primitives: chacune exprime un changement comme l'addition ou la suppression d'un attribut.
La génération des transformations primitives du schéma S1 vers le schéma S2 consistent en
trois phases: (i) la phase extensive qui ajoute à S1 le constructeur qui est dans S2, mais pas
dans S1; (ii) la phase restrictive qui enlève du résultat de la phase d’extension juste les
constructeurs qui ne sont pas dans S2; (iii) la phase de renommage qui renomme les éléments
et les arrêtes dans le résultat de la phase restrictive. Toutes ces transformations sont exprimées
en utilisant des opérateurs de transformation.
Chapitre 2 Etat de l’art Génération & Adaptation des mappings
21
L'ordre de toutes les transformations dans ces trois phases forme les transformations
primitives de S1 à S2. La figure 2.4 montre que les trois introduisent la transformation
incrémentale de S1 vers S2.
Farias Lóscio and Salgado [14]
Cette approche est proposée dans le contexte des systèmes de médiation dans lequel les
schémas de médiation et les schémas source sont exprimés en XML. L'approche génère un
ensemble de requêtes de médiation, en transformant les schémas des source et de le schéma
de médiation dans un modèle X-relation. Ensuite les requêtes de médiation sont générées pour
chaque relation du schéma de médiation [14]. La deuxième étape de l'approche est inspirée de
[10].
Le modèle de X-relation consiste en un ensemble de types de relation et un ensemble de
types de rapport de contenance. Chaque type de relation représente une relation composée par
des attributs. Chaque attribut est associé à un domaine et une cardinalité pour spécifier le
nombre minimum et maximal des instances de l'attribut qui peut être relié à une instance de la
relation.
La figure 2.5 montre un schéma de médiation et trois schémas sources dans le modèle de
X-relation. Les rectangles représentent des relations et les ellipses représentent des attributs.
Les lignes pointillées sont utilisées pour définir des attributs facultatifs et les lignes en gras
utilisées pour définir les attributs demandés. Les attributs multivalués sont représentés par des
doubles ellipses. Les rapports de contenance entre les types de relation spécifient que chaque
instance d'une relation contient des instances de l’autre.
Un diagramme de X-relation peut être dérivé automatiquement d'un schéma XML. Chaque
élément dans le schéma ayant un type défini de Type complexe qui est représenté comme une
relation. Pour chaque élément e1 du type Type complexe et son premier ascendant e2 du type
complexe, Il y a un rapport de contenance entre la relation de e1 et la relation de e2.
Chapitre 2 Etat de l’art Génération & Adaptation des mappings
22
Figure 2.5 Un schéma de médiation et trois schémas source dans le modèle de X-relation
Les requêtes de médiation sont générées pour chaque relation de médiation. Le processus
consiste en trois étapes: (i) choix des relations source pertinentes permettant de calculer la
relation de médiation; (ii) identification des opérations possibles pour relier ces relations
source pertinentes; (iii) génération de toutes les requêtes possibles par les relations source
choisies et les opérations.
Étant donné une relation de médiation Rm, une relation source Rs est pertinente au calcul
de Rm si Rs et Rm ont des attributs équivalents. Les vues des mappings V({X1.., Xn} {Y1..,
Yn}) sont définis pour spécifier comment Rm peut être calculé de Rs. Chaque attribut Xi est
équivalent à un attribut de Rm. Soit l'un ou l'autre appartient à Rs ou appartient à une autre
relation source qui est reliée à Rs par un rapport de contenance.
Pour chaque rapport de contenance de Rm à une autre relation de médiation R’m, il y a
aussi un rapport contenance entre deux relations source équivalentes à Rm et R’m ou un
chemin des rapports de contenance entre les deux relations sources respectivement. Pour
l'exemple de la figure 2.5, il y a trois mappings pour la relation de médiation Vmoviem des
trois relations source movie1, movie2 et movie3 respectivement
Dans Vmovie1, l'expression movie1.movie1_director1.director1.name1 spécifie l'attribut
name1 relié à movie1 par le chemin movie1.movie1_director1.director1.
L'expression (director3.director3_movie3.movie3)-1
.name3 spécifie l'attribut name3 qui est
relié à movie3 par le rapport director3.director3_movie3.movie3 dans un ordre inverse.
Chapitre 2 Etat de l’art Génération & Adaptation des mappings
23
Étant donné les vues de mapping pour une relation de médiation, la deuxième étape
identifie les opérations candidates entre ces mappings. Les auteurs considèrent trois
opérateurs entre le mapping de vues: unionp, intersection∩p, différencep. Les opérateurs
appliqués entre deux mappings de vues sont basées sur les assertions de correspondance qui
spécifient les rapports de contenance entre les relations sources. Par exemple, étant donné
deux mappings de vues V1 et V2, si V1 V2, l'union et l'intersection peuvent leur être
appliqués. Si V1 V2, ils peuvent être combinés en V1pV2 ou V1 p V2.
Figure 2.6 Exemple de graphe d’opérations
Les requêtes de médiation sont définies pour chaque relation de médiation. Mapping de
vues pour une relation de médiation et les opérations entre eux sont représentées par un
graphe d'opérations. La figure 2.6 donne un exemple d'un graphe d'opérations pour la relation
de médiation moviem.
Les chemins de calcul sont définis comme un sous-graphe connecté du graphe d'opérations
définissant tous les attributs de la relation de médiation. Une requête de médiation est un
chemin de calcul avec un ordre particulier sur les opérations dans le chemin. Dans la Figure
2.6, nous distinguons trois requêtes de médiation possibles définies comme suit:
1.3. Discussions
La table 2.1 expose certaines caractéristiques des approches abordées dans la génération
des mappings tel que le modèle de schéma choisi pour générer les mappings, les
caractéristiques des mappings résultantes et le type des processus de génération ainsi que les
limites de chaque approche.
Les modèles de schéma peuvent être relationnel, relationnel imbriqué ou bien en XML.
Pour caractériser les mappings résultants, nous considérons la sémantique et le format des
mappings résultants. En ce qui concerne la sémantique des mappings, nous distinguons entre
Chapitre 2 Etat de l’art Génération & Adaptation des mappings
24
les mappings qui relient des sources différentes (par des opérations inter-source) et ceux qui
ne relient pas entre des sources différentes. Pour le langage de description des mappings: il y
a ceux qui sont définis dans un langage standard, peuvent être directement utilisés dans les
systèmes supportant les langages. Et ceux qui sont produit dans un format de haut niveau et
exigent une traduction pour être utilisé dans ces systèmes. Le type de processus de génération
de mappings indique si le mapping est produit en générant directement les expressions
mappings ou en restructurant le schéma source.
Tableau 2.1 Les caractéristiques principales des différentes approches de génération de
mapping
Approches Modèle de
schéma
Caractéristiques des mappings résultants Type de génération des
mappings
Implication des jointures
inter-sources
Langage de description
Kedad et
bouzeghoub
Relationnel Oui SQL Génération de requêtes SQL
Clio’00 Relationnel Non SQL Génération de requêtes SQL
AutoMed Schéma XML Non Transformations primitives Restructuration de schéma
source
Faris Loscio et
Salgado’03
Schéma XML Oui Expressions algébriques Génération des expressions
algébriques
1.4. Les limites des approches existantes
Les approches proposées dans [10] et [14]] génèrent des mappings reliant entre des
sources différentes. L'approche [10] considère des schémas relationnels et l'approche [14]
considère des schémas XML; Un élément cible de type complexe peut seulement être dérivé
d’un élément équivalent de typecomplexe dans les sources. Cela représente une limite car le
Type complexe dans le schéma XML correspond seulement à une définition de grammaire et
les mêmes données peuvent être spécifiées comme des éléments Type complexe ou comme
des éléments Type simple avec des attributs. Nous pouvons Voir que dans l'exemple de la
Figure 2.5, aucune mapping ne peut être généré pour actorm utilisant S2 même s'il y a un
attribut actor2 dans S2 et actor2 équivalent avec namem d' actorm.
AutoMed et Clio génèrent des mappings exprimés dans un langage abstrait. Clio'02
génère un ensemble de mappings tel que chacun définis une partie du schéma cible. Deux
mappings définissant les mêmes schémas contenant des parties cibles différentes, peuvent se
chevaucher. Donc, le système ne peut pas générer un ensemble de mappings alternatives par
des sources et ne peut pas savoir non plus si la cible est satisfaite par ces sources.
25
Chapitre 2 Etat de l’art Génération & Adaptation des mappings
2. Adaptation des Mappings
Les mappings sont dérivés d’un ensemble de schémas source pour définir un schéma cible.
Cependant, dans un environnement distribué, les sources sont autonomes et changent leur
contenu sans contraintes, même les schémas cibles peuvent aussi évoluer pour intégrer de
nouveaux besoins. Quand un de ces schémas évolue, le mapping peut devenir obsolète et a
besoin d’être redéfini. L'adaptation des mappings consiste à adapter automatiquement le
mapping original par rapport aux nouveaux schémas.
Nous avons proposé plusieurs solutions pour l’adaptation automatique des mappings: EVE,
Bouzeghoub et all et AutoMed. Ils peuvent être classifiés selon deux catégories: approches
incrémentales et approches de composition de mapping. Les approches incrémentales consiste
à adapter le mapping en appliquant des modifications unitaires pour chaque changement
défini dans le système. L'approche de composition considère l'évolution et l'adaptation du
mapping en fa
Top Related