3. Introduction
BDR c’est un ensemble de bases localisées sur
différents sites (géographiquement distants),
perçues par l'utilisateur comme une base unique.
Chaque site contient des données de la base,
peut exécuter des transactions locales et
participer à l’exécution de transactions globales.
3
4. Motivation
s
Augmentation du volume d’information
Augmentation du volume de transactions.
Limites de l’architecture centralisée
4
5. Objectifs
Limiter le transfert d'informations (en nombre et en
volume) en répartissant les données les plus utilisées.
Augmenter la fiabilité : les BDR sont souvent répliquées.
La répartition de la charge de travail sur plusieurs unités
de traitement opérant en parallèle et sur les E/S.
5
7. SGBDDistribué
Le système logiciel qui permet la gestion de la
base de données distribuée et assure la
transparence de la distribution vis-à-vis des
utilisateurs.
Rendre la distribution (ou répartition) des BD
locales « transparente ».
7
9. Conception des bases
réparties
Conception ascendante
o Maîtrise de l’intégration des schémas locaux pour créer
un schéma global.
Conception descendante
o Maîtrise de la complexité de la répartition
(fragmentation, duplication).
o Définition des schémas locaux à partir du schéma
global.
9
10. Fragmentation
Pourquoi fragmenter?
o Avantages de la distribution : performances, disponibilité,
tolérance aux pannes, localité...
o Utilisation de petits fragments permet de faire tourner plus d’un
processus simultanément.
Comment fragmenter? On distingue deux possibilité de fragmentation:
o Fragmentation Horizontale
o Fragmentation Verticale
o Fragmentation
Hybride
10
11. Fragmentation horizontale
Cette fragmentation consiste à faire une séparation selon les
enregistrements. On définit le critère de sélection suivant les
valeurs d'un ou plusieurs champs et la division est faite.
Fragmentation verticale
La division est faite non au niveau des données, mais de la
structure même de la base. Certains champs sont envoyés
dans un fragments et d'autres ailleurs.
11
12. Les 3 règles de la
fragmentation
Pour toute donnée de la relation originale R il doit
avoir une sous relation Ri la contenant.
Pour toute fragmentation de la relation R en
plusieurs sous relations Ri il doit avoir un procédé
inverse de reconstitution de la relation principale R.
Aucune donnée ne doit se trouver dans plus d'un
fragment sauf dans le cas d'une fragmentation
verticale ou la clé primaire doit être présente partout.12
13. Allocation
Lorsque le concepteur a fini de fragmenter sa
base, il lui faut ensuite allouer chaque fragment
sur son site correspondant.
L'allocation peut être faite de plusieurs façons :
La réplication totale des données
L'absence de réplication
La méthode hybride
13
14. Allocation
• La réplication totale des données
Cette méthode n'est pas très efficace lorsque les données sont
régulièrement mises à jour car il se pose le problème de cohérence de
données
• L'absence de réplication
Chaque donnée est mise à jour sur un seul site. Cette méthode est plus
efficace quand les données sont beaucoup plus modifiées que lues.
• La méthode hybride
Afin de bénéficier des deux méthodes citées à la fois, celle hybride
peut être utilisé. Ainsi les données en Read Only peuvent être
répliquées et les données en Read Write pas du tout. 14
15. Réplication
Principe de la réplication
X est répliquée signifie qu’il existe une copie de X sur un
autre serveur.
En cas de panne du serveur qui héberge R, toutes les requêtes
sont redirigées au serveur qui héberge la copie de R.
La copie de X doit être rafraichie, pour être pertinente.
Avantages et inconvénients
(+) Haute disponibilité
(+) Equilibre de charge par l’ interrogation des réplicas.
(-) Coût du stockage.
(-) Coût de mise à jour des réplicas. 15
16. Mise à jour synchrone et asynchrone
Synchrone :
+ Maintenir toutes les copies en cohérence
- Perte de performance du fait de la mise en œuvre de la
validation à deux phases
Asynchrone : mise à jour différées des copies
+ Incidence minime sur les performances
- Nécessité de mise à niveau de la copie ou des copies en
cas de reprise
Réplication
16
17. Les transactions réparties
Une transaction désigne un ensemble d'opérations
effectuées sur une base de données.
Une transaction est soit validée par un Commit, soit
annulé par un Rollback soit interrompue par
un Abort.
Afin de garantir la stabilité du système, une
transaction doit validée quatre propriétés
indispensables : 17
18. L'Atomicité
Toutes les opérations d'une transaction sont menées de façon indivisible ,
toutes le opérations doivent être validées, si non tout est annulé
La cohérence
La transaction doit amener le système d'un état cohérent vers un état
cohérent, telles que toutes les contraintes d'intégrités soient respectées.
L'isolation
Une transaction en cours ne peut révéler ses résultats à d'autres transactions
si toutes ces opérations n'ont pas été validées.
La durabilité
Tout résultat produit par une transaction doit être permanent et ne doit
souffrir d'aucune altération, quelques soient les pannes du système. 18
19. Conclusio
n Les SDBDs distribuées offre une autonomie des
sites ainsi que une distribution de
l’administration.
La distribution des données entraine la révision
des notions de stockage des données, du
traitement des requêtes, du contrôle de l’accès
simultané ainsi que de la reprise.
19