Le document présente une étude sur les bases de données fédérées (BDF), définissant leur architecture, caractéristiques et objectifs. Il aborde les types de fédérations, les procédures d'intégration des données, ainsi que les cas de conflits dans ce contexte. Enfin, il souligne que malgré les avantages des BDF, des problèmes subsistent avant leur adoption commerciale généralisée.

1. Présenté par:
- Bensmaine Yasser.
- Bouacha Oussama.
2011-2012

2. Plan de la présentation:
- Introduction.
- Définition.
- Caractéristiques.
- Objectifs.
- Types.
- Procédure d’intégration.
- Quelque cas de conflits.
- Transparence à la localisation
- Conclusion.
2

3. Plan de la présentation:
- Introduction.
- Définition.
- Caractéristiques.
- Objectifs.
- Types.
- Procédure d’intégration.
- Quelque cas de conflits.
- Transparence à la localisation
- Conclusion.
3

4. Introduction[2]
- Dans une entreprise moderne, il est presque
inévitable d’utiliser différents systèmes de
gestion de bases de données réparties
géographiquement , et décentraliser pour
stocker et rechercher les données critiques.
- Pourtant, c'est seulement en combinant les
informations provenant de ces systèmes que
l'entreprise peut réaliser la pleine valeur des
données qu'ils contiennent.
4

5. Introduction[2]
Problématique
comment offrir une vue uniforme
et transparente des données
stockées dans différentes bases
de données, tout en préservant
leur autonomie locale?
5

6. Plan de la présentation:
- Introduction.
- Définition.
- Caractéristiques.
- Objectifs.
- Types.
- Procédure d’intégration.
- Quelque cas de conflits.
- Transparence à la localisation
- Conclusion.
6

7. Définition: [4]
- Ensemble de base de donné hétérogènes
intégrées (interopérer) via un modèle
commun (vue commune) et un langage
commun.
- Un tel système peut être baptisé SGBDF :
possède de multiples points en commun avec
les SGBD traditionnels et répartis.
7

8. Définition: [4]
Architecture de BDDF
8

9. Définition:
[4]
Typologie des BDD
9

10. Comparaison: [1]
BDD réparti BDD fédéré
- Approche descendante. - Approche ascendante.
- un schéma global est une - Plusieurs BDD hétérogènes
collection de BDD capables d’interopérer via
logiquement reliées et un modèle commun.
réparties entre plusieurs
sites. - Maitrise de la Hétérogénéité
sémantique (BD) et
- Maitrise de la complexité de syntaxique (SGBD,
la distribution communications,….).
(fragmentation, duplication,
placement). - Intégration des schémas
locaux pour créer un schéma
- Définition des schémas global .
locaux à partir du schéma
global.
10

11. Comparaison:
[1]
11

12. Plan de la présentation:
- Introduction.
- Définition.
- Caractéristiques.
- Objectifs.
- Types.
- Procédure d’intégration.
- Quelque cas de conflits.
- Transparence à la localisation
- Conclusion.
12

13. Caractéristiques [6]
- Transparence.
- Hétérogénéité.
- Un degré élevé de la fonction.
- L'extensibilité et l'ouverture de la
fédération.
- Autonomie des sources de données.
- Des performances optimisées.
13

14. Plan de la présentation:
- Introduction.
- Définition.
- Caractéristiques.
- Objectifs.
- Types.
- Procédure d’intégration.
- Quelque cas de conflits.
- Transparence à la localisation
- Conclusion.
14

15. Objectifs[1]
- Donner aux utilisateurs une vue unique de données
implémentées sur plusieurs systèmes a priori
hétérogènes.
- Solution des problèmes rencontré lors de la fusion
des entreprises.
- Optimisation globale.
- Conserver les données où il réside, plutôt que de les
déplacer dans un magasin de données unique.
- Envoyer des requêtes réparties à plusieurs sources
de données dans une seule instruction SQL.
15

16. Objectifs [1]
* Les Wrappers sont un type de connecteur qui
permettra à la base de données fédérée d'interagir
avec des sources de données.
16

17. Plan de la présentation:
- Introduction.
- Définition.
- Caractéristiques.
- Objectifs.
- Types.
- Procédure d’intégration.
- Quelque cas de conflits.
- Transparence à la localisation
- Conclusion.
17

18. Types [4]
fédérations faiblement couplées
- Réalisant l’intégration des différentes bases de
données à l’aide des mécanismes des bases de
données multibases et réparties (et donc la tâche de
maintenir la fédération est laissée aux administrateurs
locaux).
18

19. Types [4]
fédérations fortement couplées
- Réalisant l’intégration à l’aide d’un SGBD fédéré
(le maintien de la fédération est sous le contrôle
de l’administrateur de la fédération).
- Le concept de fédération de données est en général,
ramené à l’approche fortement couplée.
19

20. Types[4]
fédérations fortement couplées
20

21. Plan de la présentation:
- Introduction.
- Définition.
- Caractéristiques.
- Objectifs.
- Types.
- Procédure d’intégration.
- Quelque cas de conflits.
- Transparence à la localisation
- Conclusion.
21

22. Procédure d’intégration[1]
1- Traitement de l’hétérogénéité sémantique (données
de la base).
2- Traitement de l’hétérogénéité syntaxique :
Traduction des schémas (SGBD, communication)
3- Intégration des schémas (pour créer un schéma
global).
22

23. Procédure d’intégration[1]
1- Traitement de l’hétérogénéité sémantique.
- Origine : Résulte des conceptions
indépendantes des différentes BD.
- Effet : Désaccord sur la signification des
données.
- Solution : Analyse sémantique comparée des
données, préalable à la fédération (souvent
avec la phase de traduction).
23

24. Procédure d’intégration[1]
2- Traduction des schémas: une résolution de
l’hétérogénéité syntaxique
- Origine : utilisation de modèles différents dans
les BD composantes
- Effet : nécessite des traductions de tous les
modèles vers tous les modèles
- Solution : traduction de tous les schémas
dans un modèle commun (dit canonique ou
pivot).
24

25. Procédure d’intégration[1]
3- Intégration des schémas
-Identifier les éléments de base qui sont liés.
- Choisir la représentation la plus adéquate pour
le schéma global.
- Intégrer les éléments des schémas
intermédiaires
25

26. Procédure d’intégration[1]
Démarche
d’intégration 26

27. Procédure d’intégration[1]
 Passage par un modèle commun
Avantages Inconvénient
- Développement d’un seul - Difficulté de définir un
traducteur par SGBD. modèle canonique aussi
- Simplification de la riche que les modèles locaux.
modélisation. - Temps de réponse accru
- Transparence. pour les interrogations
locales.
27

28. Procédure d’intégration[1]
Exemple: Démarche
d’intégration 28

29. Procédure d’intégration[1]
29

30. Plan de la présentation:
- Introduction.
- Définition.
- Caractéristiques.
- Objectifs.
- Types.
- Procédure d’intégration.
- Quelque cas de conflits.
- Transparence à la localisation
- Conclusion.
30

31. Quelque cas de conflits dans l’integration[1]
 Conflits d’attributs :
 Conflit de nom : renommage.
 Conflit de type :  conversion.
 Attribut sans équivalent dans l’autre relation :
 Attribut optionnel :  valeur nulle.
 Attribut indispensable :  relation auxiliaire.
 Conflit de relation :
 Conflit multi-attribut : un attribut correspond à plusieurs
dans l’autre relation (ex : adresse et N°, rue, code, ville) :
 utilisation d’un calcul sur les attributs (ex : extraction)
 Conflit de clé :
•pas la même clé : changement de clé.
•La clé d’une des relations composantes n’est pas une
clé générale :  génération d’une nouvelle clé par ajout
d’un élément.
31

32. Plan de la présentation:
- Introduction.
- Définition.
- Caractéristiques.
- Objectifs.
- Types.
- Procédure d’intégration.
- Quelque cas de conflits.
- Transparence à la localisation
- Conclusion.
32

33. Niveaux de transparence à la
localisation[1]
Assurée par la définition des vues réparties :
- Les jointures inter-bases sont exécutées par le
système.
- Les mises à jour sont supportées au moyen des vues
réparties.
- Un protocole de validation à 2 phases est supporté.
33

34. Niveaux de transparence à la
localisation[1]
Exemple
:
Site 1 : Cartes grises.
Personne (N°personne, nom, prénom, adresse,…).
Voiture (N°véhicule, marque, type,….).
Conducteur (N°personne, N°véhicule, Nb-accidents,…).
Site 2 :
Accident (N°accident, date, département, N°véhicule,
N°personne,…).
Blessé (N° accident, N°personne, gravité,…).
34

35. Niveaux de transparence à la
localisation[1]
Exemple
Site: 3 : Vue répartie.
CREATE VIEW Accidenté-grave {N°personne, nom, prénom, adresse,
gravité, département, N° véhicule, marque, type}
AS SELECT P.N°personne, P.nom, P.prénom, P.adresse,
B.gravité, A.département, V.N° véhicule, V.marque, V.type
FROM S1.Personne P, S2.Blessé B, S2.Accident A, S1.Voiture V
WHERE P.N°personne = B.N°personne
AND B.gravité > « commotions »
AND A.N°véhicule = V.N°véhicule
AND A.N°.accident = B.N°accident
Requête sur la vue répartie (sur le site 3) : « Liste des blessés graves
dans une voiture yyy de marque xxx dans la région parisienne »
SELECT N°personne, nom, prénom, adresse
FROM Accidenté-grave
WHERE marque = « xxx »
AND type = « yyy » AND département IN (75, 78, 91, 92, 93, 94, 95).
35

36. Inconvénient
Malheureusement, ce système ne supporte pas
encore parfaitement l’écriture et est, en général,
seulement en lecture seule.
36

37. Plan de la présentation:
- Introduction.
- Définition.
- Caractéristiques.
- Objectifs.
- Types.
- Procédure d’intégration.
- Quelque cas de conflits.
- Transparence à la localisation
- Conclusion.
37

38. Conclusion
La BDDF a été le choix le plus judicieux
dans ce contexte, mais plusieurs
problèmes restent à résoudre avant que
cette approche devienne
commercialisable.
38

39. Bibliographie:
1- SGBDrepartisetSGBDfederes PDF.
2- These_Gesbert_2005 PDF.
3 « http://fr.wikipedia.org/w/index.php?title=Discussion:Architecture_f%C
3%A9d%C3%A9r%C3%A9e&action=edit&redlink=1.html»
4- « http://msdn.microsoft.com/fr-fr/library/default.aspx »
5- « http://www.ibm.com/developerworks/data/library/techarticle/0203haas/0203haas.html »
6 « http://publib.boulder.ibm.com/infocenter/iisinfsv/v8r5/index.jsp?topic=%2Fcom
.ibm.swg.im.iis.productization.iisinfsv.overview.doc%2Ftopics%2Fcisofedcloserwra
p.html »
39