Int

1
Intégration de données hétérogènes distribuées

• Tuyêt Trâm DANG NGOC
• Georges GARDARIN

Laboratoire PRiSM Université de
Versailles-Saint-Quentin
2
Plan

• Contexte
• Intégration de données
• Architecture de médiation
• Traitement des requêtes
• Conclusion

3
1. Contexte général

• Sources dinformation nombreuses et très
  diversifiées (SGBD-R, SGBD-O, Pages Web,
  Tableurs, système de fichiers, applications,
  etc.)
• Mode de consultation différents
• différentes façon dinterroger, c.a.d formuler
  une requête
• différentes manières pour la sources de répondre,
  c.a.d présenter un résultat
• exemple
• pages web avec URL
• tableurs avec formules
• SGBD-R avec requête SQL
• Interaction avec la source par des méthodes
  d accès.
• Différents protocoles de communication (ODBC,
  JDBC, IIOP)
• Différentes interfaces (interface de
  programmation, interface graphique, invites,
  etc.)

4
Exemple
Exemple Chercher où passer les vacances cet
été.
?
SGBD relationnel
SGBD objet
SGBD Semi-Structuré
Application
Fichiers texte
Fichiers texte
Fichiers texte
Agence de voyage
Chaine hotelière
Site horaire des vols
Météo
Informations Pays
5
Motivations

• Objectif fondamentaux
• lintégration intelligente des informations
• lexploitation des sources existantes
• Il faut traiter de
• lhétérogénéité des sources
• la distribution des sources

6
Hétérogénéité

• Indépendante de la distribution physique des
  données à travers un réseau (on peut avoir un
  système distribué et homogène)
• Un système est homogène si le logiciel qui
  manipule les données est identique pour toutes
  les sources et si toutes les données ont le même
  format (ou modèle)
• Un système hétérogène est un système qui nest
  pas homogène.
• Hétérogénéité des schémas représentations
  différentes des données
• Hétérogénéité des données codage et référentiel
  différents

7
Hétérogénéité des données

• Modèle logique
• Typages (ex adresse a pour type varchar2(64)
  sous Oracle, string sous PostgreSQL)
• Structures (ex dans une source, personne a pour
  attributs nom, prenom et age, dans une autre nom,
  adresse et no_secu)
• même nom pour désigner des entités différentes
• noms différents pour désigner la même entité
• Modèle physique
• Langage de requêtes (ex SQL, OQL, CGI-BIN)
• Restitution du résultat (ex tuples, page Web)

8
Hétérogénéité des modèles
Source 2 Repository XML
lt!ELEMENT Vin (Cru, Degre, Description)gt lt!ATTLIS
T Vin nv CDATA IMPLIEDgt lt!ELEMENT Buveur (Nom,
Place,Date, Type)gt lt!ATTLIST Buveur nb CDATA
IMPLIEDgt lt!ELEMENT Catalogue (Vin, Offre,
Publicité?)gt ...
Source 1 SGBDR
Nom DateN Pays Type
Buveurs
NV Cru Mill Degre
Vins
Source 4 LDAP
Source 3 WEB
?personne?
?buveur?
?service?
boire
?chef?
Personne
Boisson
?vins?
?employé?
?Région?
?Description?
Intégration de données
9
Hétérogénéité des langages
Source 1 RDBMS
Source 2 XML Repository
SOAP XQuery
ODBC/JDBC SQL
Source 4 LDAP
Source 3 WEB
LDAP QUERY
Google Text Queries
WEB Services
Intégration de données
10
Distribution des données

• Localiser quelle source fournira la donnée
  demandée
• Sources de puissance différentes (temps
  dexécution)
• Sources de puissance dinterrogation différentes
• Sources indisponibles temporairement

11
Avantages des architectures de médiation

• accès intégré par API et portail Web
• transparence à la localisation des données pour
  les applications
• disponibilité accrue des données en cas de pannes
  des serveurs
• non-intrusion au niveau des serveurs
• support de lhétérogénéité des sources

12
Système interopérable

• Propriétés fondamentales nécessaires à tout
  système interopérable Sheth et Larson 1990
• distribution les données gérées par le système
  proviennent de plusieurs sources. Chaque source
  met une partie de ses données à disposition des
  autres participants
• hétérogénéité chaque source choisie et conçue
  indépendamment des autres (matériel, système
  dexploitation, communication, performance,
  langages, schémas)
• autonomie une source participant à un système
  interopérable doit fonctionner comme avant sa
  participation.

13
2.Architecture de médiation
?
SGBD relationnel
SGBD objet
SGBD Semi-Structuré
Application
Fichiers texte
Fichiers texte
Fichiers texte
Agence de voyage
Chaine hotelière
Site horaire des vols
Météo
Informations Pays
14
Architecture de médiation DARPA I3
Application cliente
Application cliente
Application cliente

Niveau client
interaction
Facilitateur
Facilitateur
coordination
Niveau médiation
Médiateur
Médiateur
intégration
Adaptateur
Niveau source
Adaptateur
Adaptateur
traduction
Sources de données
Sources de données
Sources de données
accès
15
Sources de données

• Une source de données peut être décrite par
• localisation
• référence du site (URL, IPPort, annuaire LDAP)
• protocole de communication (TCP/IP, IPX,
  AppleTalk)
• moyen daccès (ODBC, JDBC, API)
• support (pages Web, SGBD)
• type de données quelle gère (structuré (SGBD-R,
  SGBD-O), semi-structuré (XML, OEM), non-structuré
  (images, multimédia, textes))
• possibilité dinterrogation (SQL, OQL,
  propriétaire, moteur de recherche web)
• format des résultats (XML, HTML, ResultSet
  (tuples), OEM, textes)

16
Communication médiateur/adaptateur

• Pour faciliter le travail dintégration, on
  définit
• un langage commun dans lequel le médiateur
  interrogera les adaptateurs
• un format de résultat commun dans lequel les
  adaptateurs répondront au médiateur.
• Ce langage et format de résultat communs peuvent
  être propriétaires ou standardisés
• Possibilité de s'appuyer sur les Web services

17
Adaptateur (Wrapper)

• Ladaptateur (Wrapper) soccupe de
  lhétérogénéité des sources. Cest un
  traducteur.
• Traduction du langage de requête commun en
  langage de requête natif (propre à la source)
• Traduction des résultats natifs en résultats au
  format commun

18
Médiateur

• Le médiateur soccupe de la distribution des
  sources
• Localisation des sources
• Décomposition des requêtes en requête adaptée
  pour chacune des sources
• Envoi des requêtes aux sources
• Recomposition des différents résultats provenant
  de chacune des sources

19
Intégration des schémas

• Comporte différents aspects
• Comparaison de schéma
• Unification de schéma
• Fusion de schéma
• Difficultés
• Conflit de niveau dabstraction
• Conflit de définition de classes
• Conflit de divergence schématique

20
Architecture GAV et LAV

• GAV Global as View
• Schéma global défini comme une vue intégrante sur
  schémas locaux
• Approche ascendante depuis les sources vers le
  médiateur
• Difficulté pour ajouter une source
• LAV Local As View
• Chaque source locale est définie comme une vue
  locale du schéma global
• Approche descendante depuis le médiateur vers les
  sources
• Difficulté pour réconcilier source et vue locale

21
Décomposition versus Recomposition
Base de données  vue universelle 
Schéma fédéré
Processeur de requête LAV
Vue complexe
Profil de la source
Profil de la source
GAV
LAV
22
Intégration des données

• Données disjointes
• regroupement par jointure externe
• Données dépendantes
• Regroupement par jointure
• Données similaires
• Regroupement par union
• Conflit de valeurs possible

23
3. Traitement des requêtes

• Analyse syntaxique et sémantique
• Décomposition des requêtes
• Exécution des requêtes sur les sources
• transformation de la requête en langage commun
  vers le langage de la source
• transformation du résultat au format de la source
  vers le format commun
• Recomposition des résultats
• combinaison des résultats locaux
• requêtes de recomposition sur système global ou
  un des sites composants.

24
Plans dexécution

• Un plan dexécution décrit la méthode dexécution
  dune requête. Il est souvent représenté par un
  arbre algébrique.
• Un arbre algébrique est un arbre où les nœuds
  sont des opérateurs algébrique et les feuilles
  les sources de données.
• Il peut exister plusieurs voire une infinité de
  façon dexécuter une requête (toutes représentée
  par des plans dexécution équivalents).
  Lensemble des plans dexécution permettant de
  résoudre une requête est appelé espace de
  recherche.

25
Décomposition des requêtes

• Exemple chercher ladresse de tous les
  propriétaires de voiture verte

26
Puissance dinterrogation des sources

• Toutes les sources nont pas les mêmes
  possibilités dinterrogation
• SGBD possibilité de requêtes souvent complexes
• Moteur de recherche par mots-clefs
• Fichiers via champ indexé
• Le médiateur ou ladaptateur de la source doit
  pallier aux déficiences de la sources
• si adaptateur implémentation complexes de
  chaque adaptateur, intégration simple au niveau
  médiateur
• si médiateur implémentation simple des
  adaptateurs, intérgation complexe au niveau
  médiateur. Nécessite une communication des
  capacités de la source au médiateur.

27
Optimisation des requêtes

• Stratégies classiques de remonté de projection,
  restriction, etc.
• Ordonnancement des jointures
• Stratégie sur les jointures inter-sites
• par interrogation multiples dune source avec les
  résultats du premier
• par boucles imbriqués
• par tri fusion

28
Optimisation statique de requêtes hétérogènes

• Ajout de vues transitoires
• Décomposition d'une requête
• Simplification d'une requête
• Prise en compte des capacités réduites des
  sources
• Parallélisation dune requête
• ?Élaboration d'un plan optimisé

29
Optimisation dynamique de requêtes hétérogènes

• Reformulation dynamique du plan dexécution
• Prise en compte de sources indisponibles
• Ordonnancement dynamique des jointures
• Optimisation adaptative

30
Modèles de coûts

• Un modèle de coût permet destimer le coût que
  prendra un plan dexécution.
• But choisir parmi tous les plans dexécution
  celui de coût minimal pour lexécution
• Sappuie sur les statistiques et des formules de
  coûts.
• Statistiques
• Du système Système dexploitation (CPU, E/S),
  SGBD (taille dune page, taille cache)
• Des données cardinalité dune collection,
  sélectivité dun attribut, etc.

31
Modèle de coût au niveau médiateur

• Cout dexécution dune requête
• coût_communication
• opération_médiateur
• coûts_sur_les_adaptateurs
• congestion_du_réseau

32
Coût sur les adaptateurs

• Les sources sont indépendantes et ne communiquent
  pas forcément leurs informations de coûts.
• Différentes stratégies permettant destimer le
  coût dune requête sur une source
• Estimation analytique
• Soumission de formules
• Apprentissage progressif
• Gestion d'historique

33
Modèle de coût

• Coût dune architecture de médiation
• Calibration PEGASUS
• requêtes types pour calibrer paramètres de la
  source
• affinée avec échantillonnage
• pour données objets IRO-DB
• Historique HERMES
• sappuie sur les statistiques des requêtes
  précédentes
• Défini par les adaptateurs GARLIC
• modèle de coût défini séparément pour chaque
  adaptateur
• Générique DISCO
• intégrer modèle de coût des adaptateurs
  hiérarchie de coût et coût par défaut pour coût
  manquant dun adaptateur
• Coût sur données semi-structurées
• Coût sur modèle semi-structuré dans un entrepôt
  LORE

34
Gestion de Cache

• Cache de pages adapté à des SGBD classiques,
  peu adapté aux autres sources (Web, ou opaques)
• Cache de tuples faisable pour les pages web
  (proxy). Mais difficile de préciser quels sont
  les tuples déjà dans le cache.
• Cache sémantique Garder un historique des
  prédicats de requêtes déjà posées.
• requête dans le cache local
• requête complémentaire
• actualiser le cache

35
Prédicat sémantique

• Prédicat plus ou moins restrictif quautre
  (where)
• requête dans le cache local
• requête complémentaire
• Résultat renvoyé (select)
• demander les attributs qui ne sont pas dans le
  cache quelque soit le prédicat
• Exemple

select from livre where date gt 1966 and
date lt 1981
36
Médiateur existants

• Génération relationnelle (1975-1990)
• Souvent centré sur un SGBD qui joue le rôle dun
  médiateur
• SDD1, Sirius Delta, R, Ingres/Star
• Mermaid, Multibase, MSQ
• Génération relationnelle étendue (1990-2000)
• Fédère des BD hétérogènes autour de SQL3
• Objet OLE-DB, pegasus, IRO-DB
• XML Medience Server, Information Integrator
  (IBM)
• Génération XML XQuery (2000- )
• OLE-DB.NET (Microsoft), Nimble, Xquark Fusion,
• Liquid Data (BEA), Enosys Software

37
4. XLive

• A mediator developed at PRiSM as a research
  vehicle
• Previous industrial version in a start-up
• e-XMLMedia closed in march 2003
• XQuark version in open source (Object Web
  Consortium)
• New light version
• Clear architecture and query transformations
• limited support of XQuery but extensible
• Support of new features, e.g., text and functions
• Focus on research topics

38
4.1 Objectives (1)

• Integrated access to multiple heterogeneous data
  sources
• Java XML/DBC API
• Web Services API
• Transparency to data localization
• Determine sources by element names
• Simple registration of sources on demand
• Data integration through XQuery
• Each source is XQuery wrapped
• Sources may have different capabilities

39
Objectives (2)

• Performance with large number of sources
• Query optimization and compilation
• XML processed as event flows (SAX)
• Integration of different join algorithms
• Support of web services
• Search web services, e.g., Google
• Operation requests as query functions
• Support of full text queries
• Semi-structured text best applications
• XQuery Text in development

40
Objectives (3)

• Explore parallelism for query processing
• External parallelism
• extend XQuery to support workflow construction
  (e.g, BPEL)
• Internal parallelism
• Extend algebra to process queries in parallel
• Mediator should include workflow engine

41
4.2 Architecture Overview
Application
XML Documents
XQuery Requests
Xdbc
XLive Mediator
Sub-requests XQuery Text
Sub-requests XQuery SQL
Sub-requests XQuery SQL
Sub-requests Full XQuery
Xdbc
Xdbc
Xdbc
SQL Adapter
SQL Adapter
Google WS Adapter
Xdbc
Web
Xyleme
MySQL
Oracle
42
Detailed Architecture
XQuery Compiler
XQuery RunTime
XQuery
Path
Metadata
Parser
Queries
Executor
Normalization
Communication Interface
Query decomposition
Canonization
XML
Evaluator
Atomization
Cache
Optimizer
Parametrized Execution Plan
XML
43
Internal model XRelation
44
The XML algebra
45
Physical Operators
46
Meta-data
Collections
Path Set
Name Source Address

• Collection name given at registration
• Path set loaded on demand (datasource.describe)
• Used to parse and route XQuery
• Could be extended with schemas

47
4.3 Query Decomposition

• Normalization
• Elimination of LET clauses
• Simplification of queries
• Canonization
• Generation of source queries
• Possible joins and unions
• Result reconstruction
• Atomization
• Isolation of physical sources
• Delegation according to capabilities

48
Normalization

• Many simplification rules can be applied
• Example Remove of LET clauses
• Unique variable attached to each graph nodes
• Hidden constraints exhibited

49
Canonization

• Based on Bi-level Query Graphs (bigraph)
• Extension of Generalized Tree Pattern Chen et.
  al.
• Navigation graphs
• Isolation of collections including result one
• Exhibition of structural constraints in
  collection
• mandatory (conditions) or optional (results)
• Composition graph
• Exhibition of join constraints
• Composition of result fragments

50
Query Example

• for p in collection ("PLAYERS"), t in
  collection ("TEAMS")
• where p/player/team t/club
• return
• ltresultgt
• ltplayergtp/player/namelt/playergt
• ltclubgtt/clublt/clubgt
• for s in collection ("STADIUMS")
• where s/stadID t/staderef
• and s/capacity gt 70000 return
• ltstadegt s/namelt/stadegt
• lt/resultgt

51
Navigation Graph

• One per collection instance in query, including
  result
• Show structural and unary constraints on
  collections
• Each node is labelled by a variable
• Nodes binding are optional0, mandatory(1) or
  every
• Each edge is labelled by a tag (or attribute)
• Structural joins are of two types
• Parent or ancestor
• Unary constraints
• Attached to node variable

52
Example of Navigation Graphs
PLAYERS(1)
TEAMS (1)
t0
p0
staderef
club
player
t20
t1
p1
name
team
RESULTS
s0
p30
capacity
r0
p2
stadeID
result
s1gt70000
s2
name
r1
player
stadium
s30
club
r20
r40
STADIUMS 2(1)
r3
53
Composition Graph

• Nodes Navigation graphs
• Value joins (binary predicates)
• Edges labelled by binary predicates
• Variables quantified by 0 (optional), 1
  (mandatory,
• Results
• Edges labelled by binary predicates
• Means extraction and renaming

54
Example of Composition Graphs
PLAYERS(1)
TEAMS (1)
t0
p0
p2t1
staderef
club
player
t20
t1
t20s2
p1
name
t1r2
team
RESULTS
s0
p30
capacity
r0
p2
stadeID
result
s1gt70000
s2
name
r1
p3r2
player
stadium
s30
club
r20
r40
r3s3
STADIUMS 2(1)
r3
55
The bigraph
PLAYERS(1)
TEAMS (1)
t0
p0
staderef
club
player
t20
t1
p1
p2t1
t20s2
name
t1r2
team
RESULTS
s0
p30
capacity
r0
p2
stadeID
result
s1gt70000
s2
p30r20
name
r1
player
stadium
s30
r40s30
club
r20
r40
STADIUMS 2(1)
r3
56
Generation of Query Plan Principles

• Xsource operator for each collection
• with XRestrict embedded (restriction predicates)
• with XProject embedded (Keep only useful paths)
• Xjoin for join predicates
• Full join or outer-join according to variable
  optionality
• with XProject embedded (Keep only useful part of
  trees)
• Construction of results
• XConstruct operator
• Note Mandatory, Optional, Grouping
• Should be maintained and inferred to join
  (outer-join)

57
Generation of Query Plan Example

• P PLAYERS.XSource (p/player/name0,
  p/player/team1,...)
• TTEAMS.XSource ((t/club1, t/staderef0), ...)
• S STADIUMS.XSource ((name0, stadeID1),...capacit
  ygt70000)
• J1 P.XJoin (p/player/team1t/club1,T)
• J2 J1.XJoin (t/staderef0S/stadeID1,S)
• Result XConstruct(ltplayergtp/player/name0lt/pla
  yergt
• 
  ltclubgtt/club1lt/clubgt
• 
  ltstadegts/name0ltstadegt)

58
5. Conclusion

• Internet sétend
• Sources dinformation de plus en plus nombreuses
• Informations de plus en plus hétérogènes
• Médiation de plus en plus nécessaire
• base de connaissances
• portails dinformation
• moteur de recherche spécifiques
• XLive est un médiateur opérationnel développé à
  PRiSM