intégration de données hétérogènes distribuées
Post on 21-Mar-2016
38 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related