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 sousrequê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].
Source1
Source2
Source3
Requêtes
SQL
Résultats
Requêtes
Module d’Extraction
Génération des
schémas des
source de
données
XSSD
D11
X
XSSD
D22
X
XSD23
Hyperschéma
XML
Liens sémantiques (XSL)
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.
Dans cette phase, la partie sémantique est affinée par l’adjonction de métaconnaissances 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 partie « 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 luimê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.
minOccurs, maxOccurs : occurrences minimale et maximale de l’attribut.
Exemple 1. Soit le schéma partiel d’une BDR gestion de commandes dont le modèle
relationnel est :
enseignant [idEns, nom, adresse, grade]
module [idMod, libelle, coef, classe, #responsable]
où idEns et idMod sont les clés primaires et responsable est une clé étrangère dont
l’ensemble de ses valeurs appartient à l’ensemble des valeurs de idEns.
transAtt(université, module, libelle) = element ⟨libelle, "xsd :string", 1, 1⟩
<xsd:element name="libelle" type="xsd:string"
minOccurs="1" maxOccurs="1"/>
2.1.2
Extraction de la partie dynamique d’un concept
La dimension dynamique d’un concept est constituée des contraintes d’intégrité et des
opérations. Par exemple, dans le cas d’une BD relationnelle, l’aspect dynamique est
constitué des clés primaires et étrangères, des triggers et des procédures cataloguées.
2.1.2.1 Cas des contraintes d’intégrité fonctionnelle
Règle 3.a. Tout attribut identifiant unique du concept de la BD considérée est traduit
par un attribut (Attribute) XSD du complexType construit d’après la règle 1 dont
l’usage est obligatoire.
transCIF(source, concept, attribut) : transforme les attributs contenant des CIF.
∀ c∈bd, ∀ att∈c ∧ att ⊂ CIF / transCIF(bd, c, att) = attribute ⟨name, type⟩
où
name: nom de la CIF.
type : type de la CIF.
Exemple 2.
transCIF(univérsité, module, idMod) = attribute ⟨idMod, "xsd:positiveInteger"⟩
<xsd:attribute name="idMod"
type="xsd:positiveInteger"/>
Règle 3.b. Tout attribut identifiant la BD considérée intègre le type complexe représentant la BD elle-même par l’élément XSD key.
transCIF_bd(source, concept, attribut) : transforme les identifiant dans le
complexType de la BD.
∀ c∈bd, ∀ att∈c ∧ att ⊂ CIF /
transCIF_bd(bd, c, att) = key ⟨name, selector ⟨xpath⟩, field ⟨xpath⟩ ⟩
Exemple 3.
transCIF_bd(université, module, idMod) =
key ⟨IDmodule, selector ⟨.//module⟩, field ⟨./@idMod⟩ ⟩
1. <xsd:key name="IDmodule">
2.
<xsd:selector xpath=".//module"/>
3.
<xsd:field xpath="./@idMod"/>
4. </xsd:key>
1. le nom de la contrainte sera constitué du nom du concept précédé par ID afin de le
distinguer des autres types de contraintes.
2. l’expression xpath employée récupère le nom du concept concerné par cette
contrainte. Pour cela, nous utilisons l’élément XSD <xsd:selection>.
3. Une deuxième expression xpath est définie avec l’élément <xsd:field> afin de
spécifier le nom de l’attribut identifiant qui doit être obligatoirement identique au nom
de <xsd:attribute> du complexType du concept.
Règle 4.a. Tout lien d’association (agrégation, composition, dépendance) intégré
directement dans un concept de la BD considérée est traduit par la contrainte XSD
keyref.
transAsso(source, concept, attribut) : transforme les associations entre concepts.
∀ c∈bd, ∀ att∈c ∧ att ⊂ CIF /
transAsso(bd, c, att) = keyref ⟨name, selector ⟨xpath⟩, field ⟨xpath⟩ ⟩
Exemple 4.
transAsso(université, enseignant, idEns) =
keyref ⟨IDREFenseigant, selector ⟨.//module⟩, field ⟨./@responsable⟩ ⟩
1. <xsd:keyref name="IDREFenseigant"
2.
refer="IDenseigant">
3.
<xsd:selector xpath=".//module"/>
4.
<xsd:field xpath="./@responsable"/>
5. </xsd:keyref>
A la ligne numéro 1, l’attribut XSD keyref permet la création d’une référence à une
association existante dans le même schéma. Le nom de l’association est composée de
IDREF suivie du nom du concept afin de bien exprimer la notion d’association.
L’attribut refer de l’élément <xsd:keyref> représente le nom de l’attribut identifiant
(key) auquel il est renvoyé (ligne numéro 2).
La ligne numéro 3 stipule le nom du concept source concerné par cette association.
La spécification du nom de l’attribut jouant le rôle d’attribut identifiant dans l’autre
concept est définie dans la ligne numéro 4.
Règle 4.b. (cas des tables servant d’association dans les BDR). Toute clé étrangère
exprimée indirectement dans un concept « fictif » de liaison de la BD considérée est
traduite par un type complexe XSD possédant un marqueur de liaison.
2.1.2.2 Cas des opérations
Le cas général des opérations concerne les procédures cataloguées des BDR et des
méthodes de classes des BDs objets.
Règle 5. (Cas de BDR). Toute procédure cataloguée ou toute méthode de la BD
considérée est traduite par un type élément (element) XSD et cet élément est référencé
par le concept « propriétaire ».
transOp(source, opération) : transforme les opérations d’une base de données.
∀ bd, op ∈ bd /
transOp(bd, op) = element ⟨name, type, sequence ⟨in, out, action⟩ ⟩
Nous opérons de la même façon pour traiter le cas des triggers pour les BDs
relationnelles.
2.2 Adjonction de métaconnaissances
Les règles d’extraction présentées précédemment uniformisent la représentation des
concepts essentiellement sur leur dimension statique et structurelle. la dimension
sémantique des concepts est enrichie par l’apport de métaconnaissances [17] lors
d’une étude plus approfondie de l’état du concept (structure incomplète, incertaine,
valeurs optionnelles, etc.), de niveau d’encapsulation du concept qui précise sa visibilité et son type d’association avec d’autres concepts (dépendance, utilisation, agrégation/composition, etc.). L’objectif de cet enrichissement est de représenter des
concepts selon des niveaux de granularité différents. Ces métaconnaissances sont
utilisées lors de la phase d’intégration proprement dite pour obtenir des mises en
correspondances plus précises. Pour cela, nous rajoutons des facettes, autrement dit
des attributs (nom/valeur) à notre hyperschéma XML au même niveau que la définition des concepts.
2.2.1 Complétude d’un concept
Dans le cas des BDs de type XML native, la structure des données est irrégulière,
contrairement aux BDs traditionnelles. En d’autres terme, le concept change de forme
et/ou de contenu d’un document XML à un autre. Pour pallier cette différence de
structuration de concepts, nous introduisons une facette de type logique dans le
complexType représentant le concept, qui porte le nom « complete ».
Exemple 5.
<xsd:complexType name="moduleConcept" complete="false"
…>
Nous remarquons que le concept module dans l’exemple ci-dessus est incomplet du
fait qu’il pourra changer de structure (forme, hiérarchie des propriétés, etc.) d’un
schéma XSD à un autre.
2.2.2 Visibilité d’un concept
Afin de garder la structure hiérarchique, notamment dans le cas des BDs XML
(comme un document XML peut posséder une structure arborescente parfois très
profonde), nous devons mémoriser le niveau d’apparition du concept. En effet, ceci
traduit la visibilité du concept par rapport aux autres, c’est-à-dire est-ce qu’un concept
pertinent ou non pour le domaine représenté. C’est par la facette « level » de type
entier dans la définition du concept que ce niveau d’encapsulation est sauvegardé.
Exemple 6.
<xsd:complexType name="moduleConcept" level="1"…>
le concept module est de niveau 1 dans le schéma XSD, ce qui explique son
importance dans les schémas des BDs (level="1", c’est-à-dire une table dans une BDR
ou un élément global (concept pertinent) dans une BDXML).
2.2.3 Propriétés obligatoires d’un concept
De même, les propriétés des concepts, représentées par des attributs, portent des
contraintes d’intégrités dans les BDs. Ces contraintes doivent être présentes dans
l’hyperschéma XML. En particulier, ces attributs doivent être déclarés avec la facette
de spécification « use » qui prendra la valeur required, signifiant que l’attribut (la
contrainte) doit toujours être présent. Pour les autres attributs (qui ne portent pas de
contraintes) la restriction peut prendre la valeur optional ou fixed.
Exemple 7.
<xsd:attribute name="nom" type="xsd:string"
use="required"/>
Dans ce cas, la présence de la propriété nom appartenant au concept enseignant est
obligatoire du fait qu’elle représente un attribut dont la valeur est toujours renseignée
dans la table enseignant (BDR de l’exemple 1).
3 Opérations de transformation
L’hétérogénéité dans l’ensemble des schémas XML de l’hyperschéma est de nature
logique ou sémantique [2]. Pour lever une partie des ambiguïtés, nous utilisons les
métaconnaissances dans les algorithmes des opérations de transformations primitives.
Les opérateurs mis à disposition concernent les concepts et leurs propriétés, ainsi que
les relations entre concepts. Ces opérateurs exploités par les règles de passage XSL
entre schémas XML obtenu lors de la phase d’extraction, sont :
- Ajout : permet d’ajouter une entité : concept, propriété d’un concept ou relation
existante entre concepts, du schéma source XSDi dans le schéma destination XSDj.
- Suppression : permet de supprimer une entité lors du processus de correspondance
entre XSDi → XSDj. La suppression est l’opérateur inverse de l’ajout.
- Fusion: permet de fusionner des entités. Généralement, la fusion porte sur des
propriétés afin d’obtenir un concept distinct lors de la transformation. Dans ce cas,
nous fusionnons des propriétés appartenant au schéma XSDi et qui forment un concept
dans le schéma XSDj (pn→c).
- Eclatement : est l’opérateur inverse de la fusion. Un concept (c) dans le schéma
XSDi, peut être éclaté en un ensemble de propriétés (p1, p2,..pn) dans le schéma
destination XSDj (c→pn).
- Equivalence : quand deux entités de même type (ci→cj; pi→pj) possèdent la même
structure et le même domaine de définition, elles sont équivalentes.
- Identité: quand deux entités sont équivalentes et de plus qu’elles ont le même nom
(syntaxe) et le même domaine de définition, alors elles sont identiques.
4 Conclusion et perspectives
L’intégration de source de données hétérogènes dans le contexte du Web est un
problème d’actualité. L’apport du langage XML comme standard d’échange et de
représentation de ces données est indéniable et facilite la mise en place des différentes
approches proposées. En effet, XML permet de représenter des données
indépendamment de leurs présentations et de leurs stockages. Aussi, tous les systèmes
d’intégration actuels par médiateur utilisent XML comme modèle pivot. Cependant,
XML ne permet pas d’éviter les problèmes de conflits structurels et sémantiques.
Notre travail de recherche consiste donc à proposer une formalisation de l’intégration
pour diminuer ces types de conflits. La phase de pré-intégration s’appuie sur la
puissance de représentation XML.
Nous cherchons à l’heure actuelle à affiner la gestion des règles d’intégration et de
résolution de conflits pour avoir des correspondances entre concepts plus précises. La
phase de fusion détecte les conflits structurels et sémantiques possibles par
l’application de mesure de distance entre concepts selon les deux dimensions
structurelle et sémantique [13]. Pour cela, nous nous appuyons sur la théorie des
graphes et sur la théorie des catégories [7]. Ces mesures sont en fait des opérateurs qui
génèrent des liens structurels et sémantiques entre sources de données.
L’automatisation partielle des opérateurs devrait s’appuyer sur l’application des
techniques d’acquisition de connaissances.
Références
1.
2.
3.
4.
5.
6.
Boucelma, O., Lacroix Z.: InterMed–interface de médiation pour les systèmes
d’information. ISI-NIS, Vol 6, n°3, (2001) 33-60
Boukottaya, A., Vanoirbeek, C., Paganelli, F., Abou-Khaled, O.: Automating XML
documents transformations: a conceptual modelling based approach. Proceedings of the
first Asian-Pacific conference on Conceptual modelling , ACM Volume 31, Dunedin, New
Zealand (2004) 81-90
Bouguettaya, A., Benatallah, B., Elmagarmid, A.: An overview of multidatabase systems:
Past and present. In A. Elmagarmid, M. Rusinkiewick et A. Sheth, éditeurs, Management
of Heterogeneous and Autonomous Database Systems, The Morgan Kaufmann Series in
Data Management Systems, chapitre 1. Morgan- Kaufmann (1999)
Castor: Web site of Castor Project, http://castor.exolab.org/
Chawathe, S., Garcia-Molina H, and al.: The TSIMMIS: Project: Integration of
heterogeneous information sources.16th Meeting of the Information Processing Society of
Japan. Tokyo, Japan (1994)
Cluet, S., Veltri, P., Vodislav, D.: Views in a Large Scale XML Repositery. Proceedings
of 27th International Conference on Very Large Data Bases VLDB’01, Roma, Italy
(2001) 271-280
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
Cousin, R.: Apport de la théorie des catégories à la représentation des connaissances.
Thèse de doctorat, Université Pierre et Marie Curie, Paris VI, (1988)
Domenig, R., Dittrich K.R.: An overview and classification of mediated query systems.
ACM SIGMOD Record, 28(3), March (1999)
Fankhauser, P., Gardarin, G., Lopez, M., Muntz, J., Tomasic A.: Experiences in Federated
Databases : From IRO-DB to MIRO-DB. Proceedings of the 24 th International Conference
on Very Large Data Bases VLDB’98, (1998) 655-658
Galhardas, H., Florescu, D., Shasha, D., Simone, E.: Declaratively cleaning your data
using AJAX. Proceeding of the 16th journées Bases de Données Avancées, Blois, France
(2000) 97-116
Garcia-Molina, H., Papakonstantinou, Y., Quass, D., Rajamaran A., Sagiv Y., Ullman, J.,
Vassalos, V., Windom, J.: The TSIMMIS Approach to mediation : Data Models and
Languages. Journal of Intelligent Information Systems, (1997)
Gardarin, G., Sha, F., Ngoc, T.: XML-based Conponents for Federating Multiple
Heterogeneous Data Sources. Proceedings of ER’99, 18 th International Conference on
Conceptual Modeling, (1999) 506-519
Lamolle, M., Mellouli, N. : Intégration de bases de données hétérogènes via XML.
EGC’2003, Atelier fouille de données, Lyon (2003)
Manolescu, I., Florescu, D., Kossmann, D., Olteanu, D., Xhumari F.: Agora: Living with
XML and Relational. Proc. of the Int'l Conf. on Very Large Databases (VLDB), Cairo,
Egypt (2000)
McBrien, P.: A Semantic Approach to Integrating XML and Structured Data Sources. In
Proc. of the 13th Intl. Conf. On Advanced Information Systems Engineering, (2001) 330345
McBrien, P., Poulavassilis, A.: Schema Evolution in Heterogeneous Database
Architectures, A Schema Transformation Approach. In Proc. CAiSE'02, Toronto, Ontario,
Canada (2002)
Melnik, S., Rahm, E., Bernstein, P.A.: Developing metadata-intensive applications with
Rondo. Journal of web semantics, (2003)
Millan, T., Mulatéro, F., Lamolle, M.: Design, Share and Re-use of Data and Applications
into a Federate Database System. Onzièmes Journées Internationales le Génie Logiciel et
ses Applications, Paris, France(1998)
Papotti, P., Torlone R.: An Approach to Heterogeneous Data Translation based on XML
Conversion. Journal of Web Engineering, (2003)
Parent, C., Spaccapietra, S.: Intégration de bases de données: Panorama des problèmes et
des approches. Ingénierie des systèmes d'information Vol.4, N°3. Lavoisier (1996)
Reynaud, C., Sirot, J., Vodislav, D.: Semantic Integration of XML Heterogeneous Data
Sources. Proceedings of International Database Engineering and Applications Symposium
IDEAS’01, IEEE Computer Society, Grenoble (2001)
Sheth, A., Larson, J.: Federated database systems for managing Distributed,
heterogeneous, and autonomous databases. ACM Computing Surveys, Septembre 1990.
Vargas-Solar G., Doucet, A. : Médiation de données: solutions et problèmes ouverts,
Actes des deuxièmes assises nationales du GdRI3, (2002)
XML Schema, W3C Recommendation: XML Schema Primer, W3 Consortium, available
at http://www.w3.org/TR /xmlschema-0, (2001)
XSLT 1.0. W3C Recommendation : XSL Transformations XSLT Version 1.0, Available
at http://www.w3.org/TR/xslt, (2002)
Xylème: Web site of Xyleme Project, http://www-rocq.inria.fr/xyleme, (2003)