0% ont trouvé ce document utile (0 vote)
19 vues13 pages

Intégration de données : enjeux et architectures

Transféré par

Animals Kingdom
Copyright
© All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd
0% ont trouvé ce document utile (0 vote)
19 vues13 pages

Intégration de données : enjeux et architectures

Transféré par

Animals Kingdom
Copyright
© All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd

Intégration de données

Dan VODISLAV

Université de Cergy-Pontoise
Master Informatique M2

Plan

• Objectifs, principes, enjeux, applications


• Architectures d’intégration de données
– Médiateurs et entrepôts
– Traitement des requêtes

• Schémas d’intégration
– Global-as-view
– Local-as-view

Page 2
Intégration de données
• Contexte
– Sources d’information nombreuses et variées
• SGBD relationnels/XML, pages HTML, LDAP, tableurs, fichiers, applications, …
– Interfaces d’accès variées
• Langages d’interrogation: SQL, XPath, XQuery, URL, …
• Modèle de données: relationnel, XML, HTML, tableurs
• Protocoles de communication: JDBC, ODBC, SOAP, HTTP
• Interfaces d’appel: ligne de commande, API, formulaire, interface graphique

• Objectif général : utiliser plusieurs sources comme si elles constituaient une


seule base de données homogène  l’intégration de données doit fournir
– un accès (requêtes, éventuellement mises-à-jour)
– uniforme (comme si c’était une seule BD homogène)
– à des sources (pas seulement des BD)
– multiples (déjà deux est un problème)
– autonomes (sans affecter leur comportement, indépendant des autres sources ou
du système d’intégration)
– hétérogènes (différents modèles de données, schémas)
– structurées (ou semi-structurées)
Page 3

Exemple

SQL
XQuery Moteur de
tuples OQL objets XML recherche HTML API instances

Fichiers Application
SGBD SGBD SGBD Fichiers
Fichiers
texte
relationnel objet Semi-Structuré texte
texte
Agence Chaine Site horaire Informations Météo
de voyage hôtelière des vols Pays
Page 4
Enjeux

• Dans l’entreprise
– Données dispersées dans une grande variété de sources hétérogènes:
• internes à l’entreprise (protégées)
• externes, chez des fournisseurs, des partenaires ou des clients
– Objectif « business intégration »: accès efficace, facile et sûr à ces données
– Études: une partie très importante des budgets IT sont dépensés en intégration
• Grand public
– Accès simple, rapide et efficace aux informations disponibles sur le web
• Texte/HTML, images, vidéo, XML, fils RSS, cartes
• Le web caché, services web
– Commerce électronique: comparateurs de prix, intégration de magasins en ligne

Page 5

Applications

Données d’entreprise

Données scientifiques

+ le Web !  moteurs de recherche, agrégateurs


Page 6
Caractéristiques des sources de données

• … qui rendent l’intégration de données difficile


 Distribution
• Répartition géographique des sources sur le réseau
• Échelle

 Autonomie
• Les sources décident de ce qu'elles partagent, comment et quand

 Hétérogénéité
• De format, de structure, de mode d'accès, de capacité de traitement

Page 7

Architecture générale d’intégration

Modèle global
requête réponse

Niveau d ’intégration Données


matérialisées

Adaptateur1 Modèle S1 Modèle Sn


Adaptateurn

........
Source1 Sourcen

Page 8
Degré d’intégration des données

Données transférées vers Données qui restent


le niveau d’intégration dans les sources

Intégration Intégration
matérialisée virtuelle

SGBD Entrepôt Système Système Recherche


universel de données fortement intégré faiblement intégré d’information
BD locale BD fédérée Moteur de recherche

Intégration forte Intégration faible

Page 9

Intégration matérialisée et virtuelle

• Intégration matérialisée  entrepôt de données


– Les données provenant des sources sont transformées et stockées sur un
support spécifique (entrepôt de données).
– L’interrogation s’effectue comme sur une BD classique

• Intégration virtuelle  médiateur


– Les données restent dans les sources
– Les requêtes sont exprimées sur le schéma global, puis décomposées en
sous-requêtes sur les sources
– Les résultats des sources sont combinés pour former le résultat final

• En pratique on peut avoir des architectures intermédiaires, entre


ces deux extrêmes

Page 10
Architecture d’entrepôt

Q R

Entrepôt D1+…+Dn

Migration de données
D1 Dn

Chargeur1 Chargeurn

Source1 ........ Sourcen

Page 11

Architecture de médiation

Q R=f(R1, …, Rn)

Médiateur
Migration de requêtes

Q1 R1 Qn Rn

Adaptateur1 Adaptateurn

........
Source1 Sourcen

Page 12
Entrepôt ou médiateur?

• Médiateur : accès direct aux sources


– approche « paresseuse », pas de matérialisation
– migration de requêtes vers les sources
– avantages : données toujours fraîches, plus facile d’ajouter de nouvelles
sources, plus grande échelle, distribution de l’effort
– inconvénients : performances, traduction de requêtes, capacités
différentes des sources

• Entrepôt de données : accès efficace à une copie des données


– matérialisation des sources au niveau du modèle global
– migration de données vers l ’entrepôt
– avantages : performances, personnalisation des données (nettoyage,
filtrage), versions
– inconvénients : données pas toujours fraîches, cohérence, gestion des
mises-à-jour, gestion de gros volumes de données

Page 13

Entrepôts de données

• L’approche la plus populaire d’intégration de données


– Gros avantages: performances, contrôle plus facile à réaliser sur
l’hétérogénéité des données

• Utilisation pour les systèmes décisionnels OLAP


• Transformation de données pour alimenter l’entrepôt
– Chargeurs = systèmes ETL (« Extract, Transform, Load »)
– Outils graphiques pour définir des flots de traitements/transformations
– Une fois le flot de traitement défini  appliqué au contenu des sources

Page 14
Exemple d’ETL : Kettle

Page 15

Médiateurs

• Bien que moins utilisés en pratique, ils ont plus de potentiel


– Meilleur passage à l’échelle
– Acceptent mieux les changements dynamiques (nouvelles sources)

 mieux adaptés à l’intégration de sources web


• En entreprise: EII
« Enterprise Information
Integration »
– Ex. BEA Liquid Data,
IBM Websphere
Information Integrator

Page 16
Architecture plus détaillée

Modèle de
données global Requête sur le schéma global

Traduction de requêtes
Requête sur l’ensemble des schémas des sources

Optimisation
Plan d’exécution réparti
Catalogue
Exécution

Requêtes sur les


Modèle de données schémas locaux exportés
local exporté
Adaptateur1 Adaptateurn
Requête sur le schéma local

Modèle de
données local Source1 ........ Sourcen

Page 17

Décomposition des requêtes

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

Source 1
Select no_carte_grise
from voiture Voiture (no_carte_grise,
where couleur = ‘vert’ couleur, immatriculation)
No_carte_grise Source 2
= no
Select no, Carte_Grise (no,
nom_conducteur nom_conducteur,
from Carte_grise date_etabl, prefecture)
Nom_conducteur
= nom
Select nom, adresse Source 3
from personne Personne (nom, prenom,
Union poids, adresse)
Select nom, adresse Source 1
from personne
Personne (nom, age, adresse)

Page 18
Schémas d’intégration

• Problèmes
– Intégration de schéma: comment définir un schéma global d’intégration à
partir des schémas des sources?
– Fusion de données: comment rendre compatibles, transformer les
données en provenance des sources?
– Mappings/vue d’intégration: comment décrire le lien entre le schéma
global et les schémas des sources?

Page 19

Définition de la vue d’intégration

• Le lien entre schéma global et schémas locaux est défini à


travers des vues
 Mapping entre ces schémas

• Deux façons principales de définir ce lien


– Le schéma global en fonction des schémas locaux  « global as view »
• Approche ascendante: on part des sources pour produire le schéma global
– Les schémas locaux en fonction du schéma global  « local as view »
• Approche descendante: on fixe le schéma global et on décrit les sources par
rapport à ce schéma fixé

Page 20
« Global-as-View »

• Le modèle global = vue sur les sources


– élément global = f(éléments des sources)
M = V(S1, …, Sn)

• Avantages
– approche naturelle
– la traduction de requêtes se fait facilement

• Inconvénients
– nouvelle source → modification du modèle global
• il faut considérer l ’interaction de la nouvelle source avec les autres

Page 21

Exemple « Global-as-View »

• Sources de données :
– S1: FilmTitre (fid, titre)
FilmDetails (fid, année, genre, réalisateur)
Acteur (aid, nom, pays)
Joue (aid, fid)
– S2: FilmInfo (titre, année, genre)
– S3: Realisateur (nom, titre)
• Modèle global du médiateur GAV:
– M: Film (titre, année, genre, réalisateur)
Acteur (nom, titre)
• Description GAV:
– M:Film(t, a, g, r) :- S1:FilmTitre(fid, t) S1:FilmDetails(fid, a, g, r)
:- S2:FilmInfo(t, a, g) S3:Realisateur(r, t)
– M:Acteur(n, t) :- S1:FilmTitre(fid, t) S1:Joue(aid, fid) S1:Acteur(aid, n, p)

Page 22
Requêtes GAV

• Exemple: les titres des films de James Cameron


– Q(t) = M:Film(t, a, g, "James Cameron")

• Méthode: remplacement direct dans la description du médiateur


– M:Film(t, a, g, "James Cameron")
:- S1:FilmTitre(fid, t) S1:FilmDetails(fid, a, g, "James Cameron")
:- S2:FilmInfo(t, a, g) S3:Realisateur("James Cameron", t)

• Remarque: l’interrogation de S2 est inutile!


• Résultat:
– Q(t)  S1:FilmTitre(fid, t) FilmDetails(fid, a, g, "James Cameron") ∪
S3:Realisateur("James Cameron", t)

Page 23

« Local-as-View »

• Les sources = vues matérialisées du modèle global


– une source décrit les données du modèle global qu’elle peut fournir
– élément source = f(éléments modèle global)
Si ⊆ Vi (M)

• Avantages
– les sources sont décrites indépendamment les unes des autres
• très simple de rajouter une nouvelle source

• Inconvénients
– traduction de requêtes plus complexe

Page 24
Exemple « Local-as-View »

• Modèle global du médiateur LAV:


– M: Film (titre, année, genre, réalisateur)
Acteur (nom, titre)
• Sources de données :
– S1: titre, années et réalisateurs de comédies
– S2: acteurs avec le titre et année des films où ils ont joué
– S3: réalisateurs, titres des films et acteurs qui y jouent
– S4: titre et genre de films français d'avant 1970
• Description LAV:
– S1(t, a, r) ⊆ M:Film(t, a, "comédie", r)
– S2(n, t, a) ⊆ M:Acteur(n, t) M:Film(t, a, g, r)
– S3(r, t, n) ⊆ M:Film(t, a, g, r) M:Acteur(n, t)
– S4(t, g) ⊆ M:Film(t, a, g, r), a < 1970

Page 25

Requêtes LAV

• Exemple: les acteurs dirigés par James Cameron


– Q(n) = M:Acteur(n, t) M:Film(t, a, g, "James Cameron")

• Algorithme Bucket
– identifier les sources pour chaque sous-requête
• Acteur(n, t) : S2(n, t, a’), S3(r’, t, n)
• Film(t, a?, g?, r) : S1(t, a’, r), S3(r, t, n’) (a, g inutiles, S2/S4 n’ont pas r)
– union de toutes les combinaisons valides des sources avec élimination des
redondances
Q(n)  S2(n, t, a’) S1(t, a’’, "James Cameron") ∪
S3("James Cameron", t’, n)
Les combinaisons S2-S3 et S3-S1 sont plus restrictives que la solution S3 seule !

• Remarque : dans GAV, les jointures entre sources sont déjà


exprimées, dans LAV il faut les déduire

Page 26

Vous aimerez peut-être aussi