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

Tuyêt Trâm DANG NGOCGeorges GARDARIN

Laboratoire PRiSMUniversité 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 d’information 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 d’interroger, 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

SGBDrelationnel

ApplicationSGBDobjet

SGBDSemi-Structuré

Agencede voyage

Chainehotelière

Site horairedes vols

FichierstexteFichiers

texteFichiers

texteInformationsPays

Météo

SQL

tuples OQLobjets

XQueryXML

Moteur derecherches HTML API instances

?

Exemple : Chercher où passer les vacances cet été.

5

Motivations

Objectif fondamentaux l’intégration intelligente des informations l’exploitation des sources existantes

Il faut traiter de : l’hé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 n’est 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 1: SGBDR

NV Cru Mill Degre Vins

Nom DateN Pays Type Buveurs

Source 2: Repository XML <!ELEMENT Vin (Cru, Degre, Description+)><!ATTLIST Vin nv CDATA #IMPLIED><!ELEMENT Buveur (Nom, Place,Date, Type)><!ATTLIST Buveur nb CDATA #IMPLIED><!ELEMENT Catalogue (Vin, Offre, Publicité?)+> ...

Personne Boissonboire

Source 3: WEB

vins

Description

Région

personne

service

chef

buveur

employé

Source 4: LDAP

Intégration de données

9

Hétérogénéité des langages

ODBC/JDBCSQL

SOAPXQuery

GoogleText Queries

LDAPQUERY

Source 1: RDBMS Source 2: XML Repository

Source 3: WEBSource 4: LDAP

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 d’exécution)

Sources de puissance d’interrogation 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 l’hé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 d’exploitation, 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

SGBDrelationnel

ApplicationSGBDobjet

SGBDSemi-Structuré

Agencede voyage

Chainehotelière

Site horairedes vols

FichierstexteFichiers

texteFichiers

texteInformationsPays

Météo

SQL

tuples OQLobjets

XQueryXML

Moteur derecherches textes API instances

?

Médiateur

Adaptateur Adaptateur Adaptateur Adaptateur Adaptateur

SQLOQL

tuples objets API instancesMoteurde recherche

textesXQueryXML

14

Architecture de médiation DARPA I3

Facilitateur

Médiateur

Sourcesde données

Applicationcliente

Sourcesde données

Sourcesde données

Adaptateur AdaptateurAdaptateur

Médiateur

Facilitateur

Applicationcliente

Applicationcliente

accès

traduction

intégration

coordination

interactionNiveau client

Niveau médiation

Niveau source

15

Sources de données

Une source de données peut être décrite par : localisation

référence du site (URL, IP:Port, annuaire LDAP) protocole de communication (TCP/IP, IPX, AppleTalk) moyen d’accès (ODBC, JDBC, API) support (pages Web, SGBD)

type de données qu’elle gère (structuré (SGBD-R, SGBD-O), semi-structuré (XML, OEM), non-structuré (images, multimédia, textes))

possibilité d’interrogation (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 d’inté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)

L’adaptateur (Wrapper) s’occupe de l’hétérogénéité des sources. C’est 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 s’occupe 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 d’abstraction 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

Vue complexe

Schéma fédéré

Processeur de requête LAV

Base de données« vue universelle »

Profil de lasource

Profil de lasource

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 d’exécution

Un plan d’exécution décrit la méthode d’exécution d’une 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 d’exécuter une requête (toutes représentée par des plans d’exécution équivalents). L’ensemble des plans d’exécution permettant de résoudre une requête est appelé espace de recherche.

25

Décomposition des requêtes

Exemple : chercher l’adresse de tous les propriétaires de voiture verte

Voiture (no_carte_grise, couleur, immatriculation)

Carte_Grise (no, nom_conducteur,date_etabl, prefecture)

Personne (nom, prenom, poids, adresse)

Personne (nom, age, adresse)

No_carte_grise = no

Union

Nom_conducteur = nom

Source 1

Source 2

Source 3

Source 1

Select no_carte_grisefrom voiturewhere couleur like ‘vert’

Select no, nom_conducteurfrom Carte_grise

Select nom, adresse from personne

Select nom, adresse from personne

26

Puissance d’interrogation des sources

Toutes les sources n’ont pas les mêmes possibilités d’interrogation

SGBD : possibilité de requêtes souvent complexes Moteur de recherche : par mots-clefs Fichiers : via champ indexé

Le médiateur ou l’adaptateur 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 d’une 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 d’une requête Élaboration d'un plan optimisé

29

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

Reformulation dynamique du plan d’exé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 d’estimer le coût que prendra un plan d’exécution.

But : choisir parmi tous les plans d’exécution celui de coût minimal pour l’exécution

S’appuie sur les statistiques et des formules de coûts. Statistiques :

Du système : Système d’exploitation (CPU, E/S), SGBD (taille d’une page, taille cache)

Des données : cardinalité d’une collection, sélectivité d’un attribut, etc.

31

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

Cout d’exécution d’une requête = coût_communication + opération_médiateur + coûts_sur_les_adaptateurs + congestion_du_réseau

Dépend du débit, de la taille desdonnées à transférer

Formule classiques de coûtde calcul d’opérateursen mémoire

coûts_fils [max (coût_filsi),

(coût_filsi)]suivant degré de parallélisme

Difficile à gérer : latence ettemps d’attente au moment de

l’exécution de la requêteOpérateur

fils1 … fils

n

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 d’estimer le coût d’une requête sur une source Estimation analytique

Soumission de formules Apprentissage progressif

Gestion d'historique

33

Modèle de coût

Coût d’une 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] s’appuie 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 d’un 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 qu’autre (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 livrewhere date > 1966 and date < 1981

select *from livrewhere date > 1976 and date < 1980

cache = Rsource = Ø

select *from livrewhere date > 1977 and date < 2000

cache = Rsource = R – Rc

cache = Øsource = R

select *from livrewhere date > 2002

36

Médiateur existants

Génération relationnelle (1975-1990) Souvent centré sur un SGBD qui joue le rôle d’un 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

XQuery Requests

SQLAdapter

SQLAdapter

Sub-requestsFull XQuery

Sub-requestsXQuery SQL

Sub-requestsXQuery SQL

XMLDocuments

XLive Mediator

Sub-requestsXQuery Text

MySQL Oracle Xyleme

Application

Google WSAdapter

Xdbc

Xdbc Xdbc

Xdbc

Xdbc

Web

42

Detailed Architecture

Parser

Normalization

Canonization

Atomization

OptimizerParametrized

Execution Plan

XQuery Compiler

Metadata

Executor

XQuery RunTime

Evaluator

Cache

Queries

XML

Path

Com

munication

Interface

XQuery

XML

Query decomposition

43

Internal model : XRelation

person

addressstreet town

nameBruce Wayne

lastname

Gotham17

nameBatman

person

addressstreet town

nameLois Lane

lastname

Metropolis28person

addressstreet town

nameParker

New York121

nameSpiderman

person

addressstreet town

nameClark Kent

lastname

Metropolis42

nameSuperman

person/name person/addressperson/lastname

Reference Part ( R ) Tree Part ( T )

XAttributes

XTu

ples

car/color

car

bluecolor

657age

car

bluecolor

1age

car

bluecolor

4age

car

bluecolor

13age

44

The XML algebra

45

Physical Operators

46

Meta-data

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

Collections

NameSource Address Path Set

…

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/clubreturn

<result><player>{$p/player/name}</player> <club>{$t/club}</club> {for $s in collection ("STADIUMS")where $s/stadID = $t/staderef and $s/capacity > 70000return

<stade> {$s/name}</stade> } </result>

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

pc

52

Example of Navigation Graphs

$p0

$p1

$p2

player

teamname

$p30

$t0

$t1

club

PLAYERS(1)

staderef

$t20

TEAMS (1)

$s0

$s1>70000

capacitystadeID $s2

$s30

name

$r3 STADIUMS 2(1)

player

result

club stadium

$r20 $r40

$r0

$r1

RESULTS

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

$p0

$p1

$p2

player

teamname

$p30

$t0

$t1

club

PLAYERS(1)

staderef

$t20

TEAMS (1)

$s0

$s1>70000

capacitystadeID $s2

$s30

name

$r3 STADIUMS 2(1)

player

result

club stadium

$r20 $r40

$r0

$r1

RESULTS

$p3=$r2

$t1=$r2

$p2=$t1

$t20=$s2

$r3=$s3

55

The bigraph

$p0

$p1

$p2

player

teamname

$p30

$t0

$t1

club staderef

$t20

TEAMS (1)

$s0

$s1>70000

capacitystadeID $s2

$s30

name

$r3 STADIUMS 2(1)

player

result

club stadium

$r20 $r40

$r0

$r1

RESULTS

$p30=$r20

$r40=$s30

$t1=$r2$p2=$t1 $t20=$s2

PLAYERS(1)

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],...)

$T=TEAMS.XSource (($t/club1, $t/staderef0), ...) $S= STADIUMS.XSource ((name0,

stadeID1),...capacity>70000) $J1= $P.XJoin ($p/player/team1=$t/club1,$T) $J2= $J1.XJoin ($t/staderef0=$S/stadeID1,$S) $Result= XConstruct(<player>{$p/player/name0}</player> <club>{$t/club1}</club> <stade>{$s/name0}<stade>)

58

5. Conclusion

Internet s’étend Sources d’information 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 d’information moteur de recherche spécifiques

XLive est un médiateur opérationnel développé à PRiSM