Intégration de Bases de données hétérogènes

Intégration de Bases de données hétérogènes par une
modélisation conceptuelle XML
Myriam LAMOLLE, Amar ZERDAZI
LINC – LIA
IUT de Montreuil – Université Paris 8
140, rue de la Nouvelle France
93100 – Montreuil
{m.lamolle, a.zerdazi}@iut.univ-paris8.fr
Abstract. 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ène. Notre
travail se situe dans le cadre de l’intégration de données hétérogènes avec la
définition d’un modèle de médiation structurelle et sémantique, pour
l’extraction et la modélisation des connaissances à partir de données sources,
appelé hyperschema XML (XHS). Cet article présente plus précisément la
phase d’extraction des schémas, en définissant les règles de base permettant
d’obtenir une structure logique XML. Cette structure logique sert de fondement
pour la phase d’intégration proprement dite.
1 Introduction
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ène. Les premières approches d’intégration de
ces sources de données pour les faire coopérer ont été réalisées dans le cadre de
système de bases de données (BDs) relationnelles, objets/relationnelles ou objets au
travers de la mise en place d’une fédération de bases de données [12], [18].
Cependant, dans le contexte du Web, les sources de données ont pour but principal de
fournir des capacités d’interrogation et non d’exportation des données. Ce contexte
nous oblige à repenser la façon dont nous devons intégrer ces différentes sources
d’informations pour connaître dès que possible la sémantique des données
mémorisées. Connaître cette sémantique, c’est pouvoir « filtrer » les sources qui sont
les plus adéquates pour répondre à une demande d’information.
Comment peut-on intégrer cette sémantique ? Comment peut-on en déduire les
concepts présents partiellement ou totalement dans plusieurs sources de données ?

Peux-t-on faciliter cette intégration lors de la phase d’extraction des concepts ? Après
un bref rappel sur les techniques d’intégration, nous proposons une solution
d’enrichissement sémantique des concepts lors de la phase d’extraction [20] facilitant
la mise en correspondances des schémas à intégrer [19].
1.1 Principes d’intégration
Dans le contexte du Web, il existe deux principales approches d’intégration à savoir :
- L’approche matérialisée (ou par entrepôt).
- L’approche virtuelle (ou par médiateur).
L’approche matérialisée extrait les données des sources à intégrer et après nettoyage
[10], les stocke dans un entrepôt de données. C’est ce dernier qui traite les requêtes
directement. Le temps de traitement des requêtes est meilleur que dans le cas de
l’approche virtuelle mais elle implique un coût de maintenance bien plus grand (dû à
la mise à jour des sources) [23].
L’approche virtuelle, quant à elle, est basée sur un ensemble de vues virtuelles
représentées par des médiateurs [3]. Les données ne sont stockées que dans leur
source d’origine. Mais, l’utilisateur final interroge la vue intégrée des différentes
sources par le schéma médiateur. Le médiateur se charge d’optimiser la requête en
sous-requêtes envoyées aux sources concernées. Cette approche n’entraîne pas un
surcoût de maintenance des données, mais se pénalise par le temps de réponse des
requêtes puisqu’il faut reconstruire le résultat final à partir des résultats des sous-
requêtes [8].
1.2 Exemples de systèmes d’intégration
Nous ne présenterons pas ici de manière exhaustive tous les systèmes existants pour
l’intégration mais ceux qui nous ont paru intéressant pour les problématiques qu’ils
soulèvent ou pour les solutions envisagées.
Dans le cadre de l’approche virtuelle, citons :
TSIMMIS1 [11] utilise un modèle global sous forme d’objets complexes (OEM,
Object Exchange Model) et un langage de règles (MSL, Mediator Specification
Language) pour l’interrogation. Les médiateurs et les wrappers peuvent être générés
automatiquement par l’utilisation de MSL. Un des objectifs de TSIMMIS [5] est
d’intégrer des sources qui sont très hétérogènes, qui peuvent être peu structurées et qui
sont susceptibles d’évoluer rapidement.
AGORA [14] s’appuie sur un médiateur dont le modèle de données est de type
relationnel et dont le langage d’interrogation commun est de type SQL.
1 The Stanford-IBM Manager of Multiple Information Sources.

Son objectif est de supporter les requêtes et l’intégration de sources relationnelles et
semi-structurées. Le schéma global de AGORA est une DTD XML et un schéma
relationnel générique est utilisé comme interface entre ce schéma et les sources. La
difficulté du modèle d’intégration relationnelle est l’adaptation des techniques
relationnelles (représentation relationnelle des documents XML), et la traduction des
requêtes XML vers SQL.
Dans le cadre de l’approche matérielle, citons :
XYLEME est un système d’entrepôt de données qui a pour ambition de stocker toutes
les données du Web [26]. Une classification par domaine est faite par l’intermédiaire
d’entrepôts spécialisés (dit datamart). Le schéma médiateur est défini par un
mécanisme de vues [21], [6]. Xylème intègre un outil d’intégration sémantique qui est
basé sur des DTDs abstraite relatives à un domaine, qui peuvent être construite
manuellement ou automatiquement (technique de datamining).
CASTOR [4] permet le « mapping » entre bases de données de n’importe quel type et
un objet Java, c’est-à-dire que chaque attribut est représenté par une classe Java,
manipulée par deux opérateurs : Get et Set (data binding). L’outil Castor (qui est un
logiciel libre) paraît intéressant dans le but de réaliser des transformations de bases de
données relationnelles ou objets en véritables objets Java et donc en un système de
gestion d’objets. CASTOR nécessite un fichier de mapping, (DTD XML) et
évidemment une base de données. En phase de développement, le modèle objet évolue
très vite, et il devient rapidement lourd de gérer à la main la synchronisation entre ces
différents éléments.
Enfin, citons e-XMLMédia qui permet de construire un système d’intégration par
approche virtuelle ou matérialisée. Ce système utilise XML comme modèle commun
[12] et trouve son origine dans le projet Miro-Web [9]. Il est constitué de 3 modules à
savoir e-XML Mediator comme outil de requêtes, savoir e-XMLLizer qui sert de
wrapper, e-XML Repositery pour stocker et interroger les documents XML dans une
BD relationnelles. La structure des documents n’est pas toujours connue mais si c’est
le cas, e-XML Repositery peut générer un schéma relationnel spécifique.
Nous proposons dans cet article une implémentation de la deuxième approche
(approche virtuellement intégrée) en créant un hypershéma de bases de données.
Nous prenons en compte le fait qu’intégrer les données ne consiste pas seulement à
homogénéiser les données en utilisant un format commun XML mais consiste aussi à
exprimer les relations entre les données des sources intégrées [1]. Cet hypershéma
porte la sémantique attachée aux schémas des bases de données hétérogènes intégrées.
Il est constitué de deux graphes portant respectivement une dimension structurelle et
une dimension sémantique des données [13]. Pour cela, lors de la phase d’extraction
des concepts, nous enrichissons les modèles traditionnels les plus courants faits par
des DTDs (voir Section 1.2), en utilisant le formalisme XML Schema [24]. Ce dernier
permet d’affiner d’une part la sémantique interne d’un concept (typage, contrainte
d’unicité, etc.) et d’autre part la sémantique inter-concepts (dépendance, association,
agrégation, etc.).

La présentation de notre travail est organisée de la manière suivante : La section 2
présente l’architecture générale de notre système suivie par l’étape de pré-intégration
[20] qui consiste en l’extraction des schémas des sources à intégrer. Nous détaillons
les règles d’extraction mises en place pour homogénéiser la représentation des
schémas des sources de données. Nous conclurons sur le travail déjà réalisé et les
différents points que nous devons développer dans le futur.
2 Extraction des Schémas
Notre architecture est constituée de deux parties bien distinctes à savoir le module
d’extraction d’un schéma de base de données et le module de comparaison/intégration
de concepts déterminant le degré de similitude entre deux concepts afin de constituer
l’hyperschéma. Au final, cet hyperschéma est constitué d’un ensemble de schémas
XML et d’un ensemble d’opérateurs de correspondances [7], [2] stipulant les règles
sémantiques entre les concepts exprimés dans chaque schéma [16].
Fig. 1. Architecture d’intégration via XML
Comme nous pouvons le voir sur la figure 1, la phase d’extraction homogénéise la
représentation des différents schémas des BDs à intégrer en l’exprimant sous la forme
d’une définition de schéma XML (i.e XSDi) [24]. Une fois cette transformation faite,
chaque concept est représenté selon deux dimensions à savoir une dimension
structurelle et une dimension sémantique.
X
XS SD D2 2
Requêtes
SQL
Résultats
Requêtes
Liens sémantiques (XSL)
Génération des
schémas des
source de
données
Source1
Source2 Source3
X
XS SD D1 1
Hyperschéma
XML
X
XS SD D2 2
X
XS SD D2 2
Module
d’Extraction
X
XS SD D1 1
X
XS SD D2 2
X
XS SD D3 3

Dans cette phase, la partie sémantique est affinée par l’adjonction de métaconnaissan-
ces soient déduites du catalogue des données, soient précisées par les experts de la
BD. Ces deux dimensions sont prises en compte dans le calcul du degré de similitude
de concepts qui nous permet de mettre en place les opérateurs de transformation
(appelés liens sémantiques sur la figure 1) de la représentation d’un concept dans un
schéma d’une BD à une autre représentation de ce concept. Remarquons que tout
opérateur de transformation à son opérateur inverse [15]. Il est à noter que la par-
tie « liens sémantiques entre schémas XSD » ne rentre pas dans le cadre du présent
article.
Au final, l’hyperschéma XML (noté XHS) est constitué de l’ensemble des schémas des
BDs sous forme XSD et de l’ensemble des opérateurs de transformation d’un schéma
à un autre sous forme XSL [25]. L’extraction des différents schémas suit des règles
précises pour les dimensions statiques et dynamiques d’un concept. Nous allons
présenter maintenant plus en détail ces différentes règles.
2.1 Règles d’Extraction
Les règles d’extraction de base sont issues de la modélisation des BDs relationnelles
que nous étendons dans le cas d’autres types de BDs.
2.1.1 Extraction de la partie statique d’un concept
La dimension statique d’un concept est constituée de son nom et des propriétés qui le
caractérisent. Par exemple, un concept prend la forme d’une table et de ses champs
dans le cas d’une BD relationnelle, d’une classe et de ses attributs dans le cas d’une
BD objet, d’une balise et de ses attributs et/ou de balises de niveau immédiatement
inférieur dans le cas d’une BD XML. De plus, il se peut qu’un concept contienne lui-
même d’autres concepts (BDOR, BDOO, BDXML).
Règle 1. Toute table, toute classe, toute balise directement au-dessous de la balise
racine de la BD considérée représente un concept est traduit par un type complexe
(complexType) XSD.
Règle 2. Tout attribut de concept (nommé c) ne portant pas de contrainte d’intégrité
fonctionnelles (CIF) est traduit par un élément du complexType XSD vu dans la règle
1. Les occurrences possibles pour cet élément dans le complexType sont égales à 1.
transAttr(source, concept, attribut) : transforme les attributs sans CIF.
∀ c∈bd, ∀ att∈c ∧ att ⊄ CIF /
transAtt(bd, c, att) = element 〈name, type, [minOccurs, maxOccurs]〉
où
name : nom de l’attribut.
type : type de l’attribut.