Académique Documents
Professionnel Documents
Culture Documents
réparties
Anne Doucet
Anne.Doucet@lip6.fr
1
Plan
• Intégration de données
• Architectures d’intégration
– Approche matérialisée
– Approche virtuelle
• Médiateurs
– Conception et intégration
– Traitement des requêtes
– Systèmes existants
• Médiation et architectures P2P
2
Intégration de données
• Contexte
• Caractéristiques
• Taxonomie des systèmes existants
• Processus d’intégration de données
3
Problématique
Infrastructures
de médiation
6
Exemple
SQL Moteur de
OQL XQuery recherches API
Fournir
un accès (requêtes, éventuellement mises à jour)
uniforme (les sources sont transparentes à l’utilisateur)
à des sources (pas seulement des BD)
multiples (même 2 est un problème)
autonomes (sans affecter le comportement des sources)
hétérogènes (différents modèles de données, schémas)
structurées ( ou au moins semi-structurées)
8
Caractéristiques des sources
• Distribution
• Hétérogénéité
• Autonomie
• Interopérabilité
Distribution
Interopérabilité
Autonomie
Hétérogénéité
9
Distribution
• Système hétérogène :
• n’adhère pas à toutes les caractéristiques d’un système
homogène
• langages de programmation et d’interrogation différents,
modèles différents, SGBD différents
11
Hétérogénéité des données
• Sémantique
– Signification, interprétation ou utilisation différente de la
même donnée
– Types de relations sémantiques
• R1 identique à R2 : même constructeur, même concept
• R1 équivalente à R2 : constructeurs différents, même concept
• R1 compatible avec R2 : ni identiques, ni équivalents
• R1 incompatible avec R2 : contradictoires
• Structurelle
12
Hétérogénéité des données
• Sémantique
• Structurelle
– Représentation différente des mêmes concepts
dans des bases différentes
– Conflits de noms, types de données, attributs,
unités
13
Autonomie
• Conception : sources locales avec des
• modèles de données propres,
• langage d’interrogation
• Interprétation sémantique des données, contraintes, fonctions …
• Communication : les sources de données locales décident
quand et comment répondre aux questions d’autres sources
• Exécution : pas d’information provenant des sources locales
sur
• l’ordre d’exécution des transactions locales ou des opérations
externes
• pas de distinction entre les opérations locales et globales
• Association :
• connexion et déconnexion des sources
• partage de données et des fonctions
14
Interopérabilité
• Systèmes interopérables :
• échange de messages et de requêtes
• fonctionnent comme une unité pour une tâche commune
• partagent les fonctions
• Communiquent même avec des composants internes
incompatibles
• Propriétés fondamentales à tout système interopérable :
– Distribution
– Hétérogénéité
– Autonomie
15
Taxonomie de SGBD hétérogènes et répartis
Distribution
SGBD
homogènes SGBD Multi-SGBD
répartis Fédérés répartis
Répartis
Multi-SGBD
Hétérogènes oui
Localement intégrés
Systèmes de requêtes
Pour sources hétérogènes
Les données sont transférées Les données restent sur le site où elles se trouvent
Intégration Intégration
matérialisée virtuelle
Données natives Données structurées Données structurées Données natives Données natives
structurées Natives et dérivées Structurées Non structurées
Semi-structurées
Non structurées
faible fort
18
Processus d’Intégration
Processus semi automatisable permettant d’intégrer des données
structurellement et sémantiquement hétérogènes.
Problème ancien (voir état de l’art dans A.P.Sheth and J.A Larson.
Federated database systems for managing distributed, heterogeneous, and
autonomous databases. ACM Computing Surveys, 22(1):183-236, Mars 90).
Pbs : hétérogénéité des modèles de données, des puissances
d’expression, des modélisations.
Un système d’intégration comprend 4 tâches principales :
- intégration de schéma
- fusion de données
- traduction de requêtes
- réécriture de requêtes
19
Intégration de schéma
– Pré intégration
• Analyse des schémas :
– identification des éléments semblables dans les schémas initiaux, et
description des liens inter-schémas.
– unifier les types en correspondance en un schéma intégré et produire les règles
de traduction associées entre le schéma intégré et les schémas initiaux.
• Ordre d’intégration
• Définition de contraintes globales
– Comparaison
• Identification de relations entre attributs
• Homonymes, synonymes, types de données, dépendances
• Propriétés (assertions) de correspondance inter schémas
(dépendances d’inclusion, exclusion, union)
• S’assurer que l’ensemble d’assertions est cohérent et minimum.
20
Fusion de données
21
Représentation des aspects sémantiques
• Logique de description
• Méta attributs et valeurs à représentation d’un contexte
• Dictionnaires de données à vocabulaire utilisé dans les bases
de données
• Ontologies décrivant des domaines de discours (concepts,
relations, valeurs)
22
Architectures d’intégration
• Intégration matérialisée
– Les données provenant des sources à intégrer sont stockées
sur un support spécifique (entrepôt de données).
– L’interrogation s’effectue comme sur une BD classique
(relationnelle).
• Intégration virtuelle
– Les données restent dans les sources
– Les requêtes sont faites sur un schéma global, puis
décomposées en sous-requêtes sur les sources. Les
différents résultats des sources sont de la requête sont
combinés pour former le résultat final.
23
Architecture d’entrepôt de données
utilisateur
requête réponse
Entrepôt
(BD relationnelle)
Intégrateur
Extraction et
nettoyage
de données
24
Architecture de médiateur
utilisateur
requête réponse
Schéma global
Médiateur
• Architectures matérialisées
– Bonnes performances
– Données pas toujours fraîches
– Nettoyage et filtrage des données
• Architectures virtuelles
– Les données sont toujours fraîches
– Traitement de requêtes peut être coûteux
– Défi principal : performances
26
Entrepôts de données
27
Motivations
• Réconciliation sémantique
– Dispersion des sources de données au sein d’une entreprise
– Différents codage pour les mêmes données
– L’entrepôt rassemble toutes les informations au sein d’un unique
schéma
– Conserve l’historique des données
• Performance
– Les données d’aide à la décision nécessitent une autre organisation
des données
– Les requêtes complexes de l’OLAP dégradent les performances
des requêtes OLTP.
• Disponibilité
– La séparation augmente la disponibilité
– Une bonne façon d’interroger des sources de données dispersées
• Qualité des données
28
Systèmes légués
• gros système, critique, sur environnement ancien. Souvent peu documenté.
Interactions entre les différents modules peu claires. Très cher à maintenir.
• Il faut l'intégrer (migration) au système actuel (Entrepôt) = architecture cible.
• Contraintes : migration sur place, garder opérationnel, corriger et améliorer
pour anticiper, le moins de changements possibles (diminuer le risque),
flexible sur les évolutions futures, utiliser les technologies modernes.
• Approche classique : tout réécrire dans l'architecture cible
– promesses à tenir dans des conditions changeantes
– problème de transfert de très gros fichiers (plusieurs jours) dans
système critique
– gros projet, retard mal vus, risque d'abandon
• Approche incrémentale :
– isoler des sous-systèmes a migrer
– établir des passerelles pour que les modules déjà migrés puissent
communiquer avec les modules encore dans le système légué
(traducteur de requêtes et de données).
29
– coordonner les mises à jour pour garder la cohérence.
Bases de Données/Entrepôts de données
Types de
données de gestion données d’analyse
données (données courantes) (données historiques)
31
Bases de données / Entrepôts
• intégrées :
Les données, provenant de différentes sources (systèmes légués) sont souvent
structurées et codées de façons différentes. L'intégration permet d'avoir une
représentation uniforme, cohérente et transparente. Lorsque les données sont
agrégées, il faut s’assurer que l’intégration est correcte.
• historiques :
Un datawarehouse contient des données "anciennes", datant de plusieurs années,
utilisées pour des comparaisons, des prévisions, etc.
• non volatiles :
Une fois chargées dans le datawarehouse, les données ne sont plus modifiables. Elles
sont uniquement accessibles en lecture (pour l'instant...).
33
Fonctions des entrepôts
•interrogation
•visualisation
•analyse
34
Structure des données
fortement résumées
M faiblement résumées
E
T
A
D
O données courantes
N
N
E
E données anciennes
S
35
Métadonnées
36
Architecture
données externes
(connaissances, règles) datamart
olap
entrepôt
datamart
données de production
(y.c. Systèmes légués)
datamart
META-MODELES
37
Architecture à 3 niveaux
• Serveur de la BD de l’entrepôt
– Presque toujours relationnel
• Data marts /serveur OLAP
– Relationel (ROLAP)
– Multidimensionel (MOLAP)
• Clients
– Outils d’interrogation et de rapports
– Outils d’analyse et d’aide à la décision
38
Construction d’un entrepôt de données
Trois phases principales
1. Acquisition:
Extraction : collection de données utiles
Préparation : transformation des caractéristiques des données
du système opérationnel dans le modèle de l’entrepôt
Chargement : nettoyage (élimination des dupliqués, incomplétudes,
règles d’intégrité, etc.) et chargement dans l’entrepôt (trier, résumer, calculs,
index).
2. Stockage :
Les données sont chargées dans une base de données pouvant
traiter des applications décisionnelles.
3. Restitution des données :
Il existe plusieurs outils de restitution (tableaux de bord, requêteurs
SQL, analyse multidimensionnelle, data mining ...)
39
Maintenance
• Les données de l’entrepôt sont stockées sous forme de vues
matérialisées sur les différentes sources de données.
• Quand répercuter les mises à jour des sources ?
– À chaque modification ?
– Périodiquement ?
– À définir par l’administrateur
• Comment les répercuter ?
– Tout recompiler périodiquement ?
– Maintenir les vues de façon incrémentale
• Détecter les modifications (transactions, règles actives, etc.)
• Les envoyer à un intégrateur qui détermine les vues concernées,
calcule les modifications et les répercute.
40
Outils d’extraction de données
41
Evolution
Pourquoi ?
- nouvelles données (extension géographique, changement de fréquence des
historiques, changement du niveau de détail, etc.)
- ajout de nouveaux éléments de données au modèle (l'ajout d'un attribut
pour 2millions de n-uplets représente une augmentation considérable!)
- création de nouveaux index, résumés
- ajout de nouveaux outils (générateurs de requêtes, outils OLAP, etc.)
- nouveaux utilisateurs
- complexité des requêtes
Les prototypes ne sont guère utiles (ne dépassent pas 20giga), les estimations
sont souvent erronées...
Trois aspects majeurs sont concernés :
la base de données doit être extensible, disponible (plus de batch),
facilement gérable (optimisation, indexation, gestion du disque
automatiques).
le middleware (gestionnaire de transactions, gestionnaire d'accès,...)
doit être performant et cohérent. Là aussi, extensibilité, disponibilité,
facilité de gestion.
l'intégration des outils doit se faire avec un souci de compatibilité.
Les outils doivent être conformes au plus grand nombre de standards.
43
Problèmes ouverts dans les DW