détection des opérations de changement des sources de ... · « louange à dieu, le tout puissant...

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


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.


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.


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.


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


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.


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:


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.


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


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.


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


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


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.


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


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


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 :


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 :


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 :


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.


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.


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.


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


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


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

détection des opérations de changement des sources de ... · « louange à dieu, le tout puissant...

Documents