Chapitre-3 BDD Réparties

Filière : Licence Génie Informatique
Prof : A. BENMAKHLOUF
Les Bases de Données Réparties (BDR)
Table des matières

I- Introduction ................................................................................................................................... 2
II- Objectifs & Définitions.............................................................................................................. 2
II-1 Objectifs des bases de données réparties ..................................................................................... 2
II-2 SGBD Répartie ............................................................................................................................... 3
II-3 Avantages et Inconvenants ........................................................................................................... 3
III- Conception d’une base de données répartie ............................................................................ 3
III-1 Conception descendante (top down design) ................................................................................ 3
III-2 Conception ascendante (bottom up design) ................................................................................ 4
- Accorder leurs types .................................................................................................................... 4
- Gérer leur cohérence…................................................................................................................ 4
- Interfacer ou adapter les SGBD… ............................................................................................... 4
III-3 Base de données fédérées & système multi base......................................................................... 5
IV- Fragmentation ........................................................................................................................... 6
IV-1 Types de Fragmentation ............................................................................................................. 6
IV-1-1- fragmentation par objet ...................................................................................................... 6
IV-1-2- fragmentation par occurrences (fragmentation horizontale FH) ........................................ 7
IV-1-3- fragmentation par attributs (fragmentation verticale FV) .................................................. 7
IV-1-4- fragmentation hybride (FHY) ............................................................................................... 8
IV-1-5- fragmentation des occurrences connexes (fragmentation dérivée FD) .............................. 8
IV-2 Définition de la fragmentation ................................................................................................... 9
IV-2-1 Définition des fragments horizontaux d'une classe ............................................................ 12
IV-2-2 Définition des fragments horizontaux d’un schéma ........................................................... 14
IV-2-3 Définition des fragments verticaux d'une classe ................................................................ 17
IV- 3 Processus d’allocation des fragments. .................................................................................... 18
IV-3-1- Types d’allocation .............................................................................................................. 18
IV-3-2- Répartition des fragments ................................................................................................. 22
1
IV-3-2- Types de réplication ........................................................................................................... 18

a- Réplication asymétrique ........................................................................................................ 18
b- Réplication symétrique .......................................................................................................... 19
IV-4 Les Requêtes Réparties ............................................................................................................. 26
IV-4-1 les requêtes d’insertion de mise à jour et de suppression .................................................. 26
IV-4-2 Optimisation des requêtes réparties................................................................................... 27
V- BD répartie avec Oracle.......................................................................................................... 32
V-1 DATABASE LINKS................................................................................................................. 32
V-2 Transparence de localisation (SYNONYM) .......................................................................... 33
V-3 Manipulation des données dans une BDD Oracle répartie .................................................. 33
I- Introduction
De nos jours les entreprises et les différents organismes ont besoin de plus en plus de gérer un
volume important de données. L’utilisation des bases de données centralisées avec un système
de gestion des BDD génère une lourdeur dans la réalisation et l’exécuter à distance des
différentes transactions surtout lorsqu’il s’agit des entreprises multinationales.
Pour surmonter ce problème, le recours à des bases de données réparties devient une
nécessité.
II- Objectifs & Définitions

II-1 Objectifs des bases de données réparties
Les bases de données réparties ont une architecture qui peut s’adapter à une décentralisation
des ressources des entreprises. Les objectifs des BDR sont :
Une indépendance à la localisation : permet l’exploitation des données dans les BDD
relationnelles indépendamment de la localisation des données. c.-à-d., exprimées des requêtes
en SQL similaires aux requêtes locales et simplifier la vue utilisateur et l’écriture de requêtes.
Une fiabilité élevée : permet de minimiser le risque lié à la centralisation des données dans un
seul serveur. Les bases de données réparties ont souvent des données répliquées. La panne
d’un site n’est pas très importante pour l’utilisateur, qui s’adressera à autre site.
Des performances : réduire le trafic sur le réseau est une possibilité d’accroître les
performances. Le but de la répartition des données est de les rapprocher de l’endroit où elles
sont accédées. Répartir une base de données sur plusieurs sites permet de répartir la charge
sur les processeurs et sur les entrées/ sorties.
2
II-2 SGBD Répartie

Une base de données centralisée est gérée par un seul SGBD, est stockée dans sa totalité dans
un emplacement physique unique et ses divers traitements sont confiés à une seule et même
unité de traitement. Par opposition, une base de données distribuée est gérée par plusieurs
processeurs, sites et SGBD.
II-3 Avantages et Inconvenants

Les principaux avantages d’une BDD_R sont :
1. Transparence pour l’utilisateur

2. Autonomie de chaque site
3. Absence de site privilégié
4. Continuité de service
5. Transparence vis à vis de la localisation des données
6. Transparence vis à vis de la fragmentation
7. Transparence vis à vis de la réplication
8. Traitement des requêtes distribuées
9. Indépendance vis à vis du matériel
10. Indépendance vis à vis du système d’exploitation
11. Indépendance vis à vis du réseau
12. Indépendance vis à vis du SGBD
Les principaux inconvenants sont :
1. Coût : la distribution entraîne des coûts supplémentaires en termes de communication,

et en gestion des communications (hardware et software à installer pour gérer les
communications et la distribution).
2. Problème de concurrence.
3. Sécurité : la sécurité est un problème plus complexe dans le cas des bases de données
réparties que dans le cas des bases de données centralisées.
III- Conception d’une base de données répartie

La création d’un schéma de répartition est la partie la plus délicate de la phase de conception
d'une BDD_R car il n'existe pas de méthode standard pour trouver la solution optimale.
L'administrateur doit donc prendre des décisions en fonction de critères techniques et
organisationnels avec pour objectif de minimiser le nombre de transferts entre sites, les temps
de transfert, le volume de données transférées, les temps moyens de traitement des requêtes, le
nombre de copies de fragments, etc.... on peut par ailleurs distinguer deux méthodes de
répartition :
III-1 Conception descendante (top down design)
3
Dans cette méthode on définit dans un premier temps un schéma conceptuel global de la base
de données répartie, puis on distribue sur les différents sites les schémas conceptuels locaux.
La répartition se fait donc en deux étapes, en première étape la fragmentation, et en deuxième
étape l’allocation de ces fragments aux sites. Cette méthode (top down) est utilisée dans le cas
où on veut faire la conception d’une nouvelle base de données dont les données vont être
réparties dans les différents sites.
Fig-1 : Conception descendante
III-2 Conception ascendante (bottom up design)

Dans cette méthode il faut réussir à regroupe les schémas conceptuels déjà existant locaux
dans un schéma conceptuel global. Cette approche est utilisée si on a déjà des données qui
sont réparties dans des bases de données existantes et on veut les intégrées dans une base de
données centrale et globale.
L’utilisation de cette approche est moins fréquent puis qu’elle difficile à mettre en œuvre. En
effet, les BDDs existante sont en générale hétérogènes et sont gérés par déférents SGBD.
Donc nécessité d’uniformiser puis de consolider les données des différents sites. Pour faire on
doit par exemple :
- Identifier les données identiques

- Accorder leurs types
- Gérer leur cohérence…
- Interfacer ou adapter les SGBD…
4
Fig-2 : Conception ascendante
III-3 Base de données fédérées & système multi base

Les Base de données fédérées & les systèmes multi base sont différents des BDD
réparties. En effet :
Dans une BDD fédérée chaque site a son schéma local. Ces schémas ne sont pas
forcément tous inclus dans le schéma global. Ce dernier peut être obtenu par une
approche ascendante partielle. Il y a donc un site central qui gère les données qui sont
concernées par le schéma global.
Dans un système multi-bases il n’y a pas de schéma global, pas de site central.
L’accès à une partie ou à la totalité des données peut de faire à distance via une
application qui utilise un langage commun.
III-4 Architecture d’une BDR
En plus de la répartition physique des données, la répartition d'une base de données intervient
dans les trois niveaux de son architecture.
Niveau externe : les vues sont distribuées sur les sites utilisateurs.
Niveau conceptuel : le schéma conceptuel des données est associé, par l'intermédiaire du
schéma de répartition (lui-même décomposé en un schéma de fragmentation et un schéma
d'allocation), aux schémas locaux qui sont réparties sur plusieurs sites, les sites physiques.
Niveau interne : le schéma interne global n'a pas d'existence réelle mais fait place à des
schémas internes locaux répartis sur différents sites.
5
IV- Fragmentation
La fragmentation est le processus de décomposition d'une base de données en un ensemble de
sous-bases de données. Cette décomposition doit être faite sans perte de données ou/et
d'information. Il y a deux règles principales pour assurer une fragmentation sans cette perte de
données.
La complétude : pour toute donnée d’une relation R, il existe un fragment Ri de la relation R
qui possède cette donnée.
La reconstruction : pour toute relation décomposée en un ensemble de fragments Ri, il existe
une opération de reconstruction.
IV-1 Types de Fragmentation
Il existe plusieurs techniques de fragmentation :
IV-1-1- fragmentation par objet

Cette technique consiste en la répartition des objets dans les différents serveur objet par objet.
Toutes l’occurrences d’une classe (n-uplet d’une relation) appartient ainsi au même fragment.
• L’opération de fragmentation sera donc la définition des sous-schémas
• L’opération de recomposition des informations sera l’union entre les objets des sous-
schémas à l’aide des jointures.
6
Exemple : pour le schéma de BDD suivant :
Client(NoClient, NomClient, PrénomClient, VilleClient, Age)

Agence(NomAgence, Adresse, Ville)
Compte(NCompte, TypeCompte, Solde, NoClient, NomAgence)
Ce schéma peut être fragmenté de la manière suivante :
, dans le serveur-1
dans le serveur-2
IV-1-2- fragmentation par occurrences (fragmentation horizontale FH)
Les tuples d’une même classe vont être réparties sur plusieurs Serveurs.
•
L’opération de recomposition des informations sera l’union des sous-classes ∪
L’opération de fragmentation sera donc la sélection
•
Exemple : dans l’exemple précédent on peut réaliser la FH suivante :
1 !"
2 % &
IV-1-3- fragmentation par attributs (fragmentation verticale FV)
Les attributs de la même classe sont fragmentés dans plusieurs serveurs. Dans ce cas toutes
les valeurs des occurrences pour un même attribut se trouvent dans le même fragment. Des
attributs sont dupliqués dans les fragments pour assurer leurs jointures.
• L’opération de fragmentation sera donc la projection '

•
entre sous-classes ⋈ ou ⋉
L’opération de recomposition des informations sera les jointures ou les semi-jointure
1 '*+, !&, +,- !&, ./ !,- !&0

Exemple : dans l’exemple précédent on peut réaliser la FV suivante :
2 '*+, !&, !&, 1230
La recomposition de la table Client est réalisée par l’opération : 1 ⋈ 2
7
IV-1-4- fragmentation hybride (FHY)
Dans cette fragmentation seulement quelques valeurs des occurrences pour un même attribut
se trouvent dans le même fragment. C’est donc une combinaison entre la FH et la FV.
• L'opération de partitionnement est une combinaison de projections et de sélections.

• L'opération de recomposition est une combinaison de jointures et d'unions.
Exemple : dans l’exemple précédent on peut réaliser la FHY suivante :
1 '*+, !&, +,- !&, ./ !,- !&0 123456
2 '*+, !&, !&, 1230 123456
3 '*+, !&, !&, 1230 123856
4 '*+, !&, +,- !&, ./ !,- !&0 12856
La recomposition de la table Client est réalisée par l’opération :
1 ⋈ 2 ∪ 3 ⋈ 4
IV-1-5- fragmentation des occurrences connexes (fragmentation dérivée FD)
La fragmentation d’une relation R s’accompagne avec une fragmentation des
: ⋉ :; .
relations jointes Rj. Cette dernière se fait en générale en utilisant des semi jointures
Exemple :
, ,
Créer deux procédures PL/SQL qui permet de fragmenter les tables clients et comptes
la base de données selon les règles suivantes :
1: = !& !"
1: 1⋉
2: = !&> !"
1: 2⋉
Réponses :
8
create or replace procedure DIVIDEClients is create or replace procedure

cursor cur1 is DIVIDEcompte is
select clients.* from clients cursor cur1 is
where VILLECLIENT='Casablanca'; select comptes.* from clients1, comptes
cursor cur2 is where
select clients.* from clients clients1.NCLIENT=comptes.NCLIENT;
where VILLECLIENT!='Casablanca'; cursor cur2 is
type str is RECORD(L clients%rowtype); select comptes.* from clients2, comptes
E1 str; where
E2 str; clients2.NCLIENT=comptes.NCLIENT;
begin type str is RECORD(L comptes%rowtype);
open cur1; E1 str;
open cur2; E2 str;
FETCH cur1 into E1.L; begin
while cur1%found loop DIVIDECLIENTS;
insert into clients1 values E1.L; open cur1;
FETCH cur1 into E1.L; open cur2;
end loop; FETCH cur1 into E1.L;
commit; while cur1%found loop
FETCH cur2 into E2.L; insert into comptes1 values E1.L;
while cur2%found loop FETCH cur1 into E1.L;
insert into clients2 values E2.L; end loop;
FETCH cur2 into E2.L; commit;
end loop; FETCH cur2 into E2.L;
commit; while cur2%found loop
end; insert into comptes2 values E2.L;
FETCH cur2 into E2.L;
end loop;
commit;
end;
IV-2 Définition de la fragmentation
La fragmentation sera basée sur l’ensemble des requêtes d’interrogation ou de mise à jour les
plus utilisées. Il faut extraire de ces requêtes toutes les conditions de sélection, les attributs de
projection et les jointures.
Les conditions de sélection seront à la base de la FH et les attributs de projections seront à la
base de la FV, les jointures donneront une information sur la fragmentation par objet. Une
fragmentation doit respecter les deux critères de reconstitution et complétude.
9
- Reconstitution : possibilité de reconstituer les BDD initiale à partir des fragments en

utilisant les opérations algébriques relationnelles « UNION » et « JOINTURE ».
- Complétude : il faut éviter les pertes d’information après la fragmentation toute en
préservant la normalisation des schémas des BDD fragmentées. Dans la FH, chaque n-
uplet d’une relation R doit être dans un fragment. Dans la FV chaque attribut de R doit
être dans un fragment.
Pour éviter le risque d'émietter la base de données, on doit restreindre le nombre de requêtes
prises en considération dans la fragmentation. On ne s'intéresse alors qu'aux requêtes les plus
fréquentes ou les plus sensibles et celle qui demande un temps d’exécution élevé.
Exemple1 : Soit les deux relations suivantes :
La fragmentation suivante va engendrer une perte d’information.
RB1 : SELECT B1, B3 FROM RB;

RB2: SELECT B2, B3 FROM RB;
10
:?@ ⋈
⏟
%BC .?E %BF .?E
:?G
H
Exemple2:
En prenant les mêmes relations de l’exemple-1. La fragmentation suivante va

engendrer une perte d’information.
RB1: SELECT * FROM RB WHERE B2='Y1' and B3=1;

RB2: SELECT * FROM RB WHERE B2!='Y1' and B3!=1;
11
:?@ ∪ :?G
H
IV-2-1 Définition des fragments horizontaux d'une classe
Pour éviter de perdre des données dans une FH. On construit tous les min-termes des
variables logiques représentant les conditions de sélection dans les requêtes. Chaque min-
terme doit représenter une condition de sélection pour insérer les données dans les tables
fragmentées. Puisque la somme (union) de tous les min-termes vaut 1, nous serons sûr que
l’union des tables fragmentées va nous permettre la reconstitution de la table initiale sans
perte de données. Parfois, pour ne pas sur-fragmenter une table, on peut rassembler par union
les min-termes qui ne sont pas vérifiés par les requêtes de sélection.
Soient C1, C2, …, Cn les conditions de sélection qui ont été extraites des requêtes. Comme les
fragments horizontaux doivent être exclusifs, on produit l'ensemble des 2n min-termes :
IJ ∗
L ∗
L NM O
@,!
On supprime de cette ensemble les termes qui sont toujours fausses et on simplifie les autres.
Soient la requête suivante dont l’exécution est fréquente dans un site :
:P1: @⋀ G RST
L’ensemble des conditions se compose de C1 et C2. Les fragmentations possibles sont :
RST 1: @. G RST
RST 2: @.UUUU
G RST
RST 3: UUUU
@. G RST
RST 4: UUUU
@.UUUU
G RST
12
On peut rassembler les tables Table2, Table3, Table4 en une seule table.
1. UUUU
2 V UUUU
1. 2+UUUU
1. UUUU
2 UUUU
1 V UUUU
2
Le schéma de fragmentation devient :
RST 1: @. G RST
RST 2: UUUU G RST
@WUUUU
Exercice : Soit la base de données relationnelles suivantes :
Client(NoClient, NomClient, PrénomClient, VilleCLient, Age)

Agence(CodeAgence, NomAgence, Adresse, Ville)
Compte(IdCompte, NCompte, Solde, NoClient, CodeAgence)
Proposer un schéma de fragmentation horizontale en tenant compte des requêtes suivantes :
Dans le site1 : :@ !& !" 1+X 123856
Dans le site2 : :G !& % & 1+X 123YE6
Correction :
Soit les variables logiques représentant les conditions élémentaires suivantes :
S@ !& !"
T@ Z[ \ 40
SG !& % &^
TG Z[ _ 30
On note x et y les conditions de sélection des deux requêtes R1 et R2. Les min-termes sont :
`̅ bU UUU@ V TN@ dcS

cS UUUG V T UUUG d
`bU S@ T@ cS
UUUG V T UUUG d
`̅ b UUU@ V TN@ dSG TG
cS
`b S@ T@ SG TG
D’après les conditions élémentaires on a :
S@ T@ UUU
SG S@ T@
13
et
S@ T@ UUU
TG S@ T@
Donc
`bU S@ T@
De même pour le min-terme
`̅ b SG TG
Le dernier min-terme est toujours faux :
`b 0
La fragmentation proposée est :
1 !& !" 1+X 123856

eff1: g
1 1⋉
2 !& % & 1+X 123YE6

eff2: g
1 2⋉
3 c !&! !" i% 123456d1+Xc !&! % & i% 123jE6d

eff3: g
1 3⋉
IV-2-2 Définition des fragments horizontaux d’un schéma
sélection avec jointure 1 à plusieurs :@ 1 ⋈∗ :G il faut respecter les règles suivantes :

Dans les fragmentations horizontales qui prennent en considération des conditions de
1. Pour avoir des fragments de schéma qui respecte les conditions de sélection, il faut
commencer à fragmenter la table R2 puis récupérer le fragment associé de la table
source R1 par semi-jointure.
2. Pour ne pas perdre des données de la table R1 il faut tenir compte des n-uplets de R1
qui n’existe pas dans la table destination (plusieurs)
Soit la requête de sélection à prendre en considération dans la fragmentation :
14
: PLê : %C. %F :@ ⋈ :G
Avec R1 est la table source et R2 est la table destination.
m1 :G
eff1: l %G %C . %F
m1%@ :@ ⋉ m1%G
m2%G :G
eff2: l
UUUUUU
%C WUUUUUU
%F
m2%@ :@ ⋉ m2%G
m3 :@ ⧑ :G
eff3: l %@ nopF +qrr
Exercice1 :
:@ !& !" 1+X t, o Y6 ⋈
:G !& % & 1+X t, o j 6 ⋈
Solution : le schéma sera réparti de la manière suivante :
1 !& !" 1+X t, o Y6

uvvw: g
1 ⋉ 1
2 !& % & 1+X t, o j6

uvvx: g
2 ⋉ 2
3 c !&> !" i% t, o j6d 1+X !&> % & i% t, o Y6

uvvy: g
3 ⋉ 3
uvvz: { 4 no ,-|& +qrr ⧑
15
Exercice2 :
:@ !& !" 1+X 123Y56
:G !& !" 1+X t, o Y6 ⋈

:E !& % &
Solution : le schéma sera réparti de la manière suivante :
Soient les variables logiques suivantes :
S } S ST S S^
^
S ^
} ^
:STS ^
T Z[ _ 40
~ • _0
Après calcul et simplification des mintermes on obtient le schéma réparti suivant :
1 .
uvvw: g
1 1⋉
2 . U ."
uvvx: g
2 ⋉ 2
3
uvvy: g
3 3⋉
4 UW U . UW"̅ .UUU
uvvz: g
4 ⋉ 4
uvv€: { 5 no ,-|& +qrr ⧑
16
IV-2-3 Définition des fragments verticaux d'une classe
Les fragments verticaux sont exclusifs, sauf en ce qui concerne le (ou les) attribut(s) de
jointure qui sont insérés dans tous les fragments, et ce pour une décomposition sans perte
d'information.
On procède comme suit,

1. Extraire toutes les expressions de projection concernées par les requêtes.
2. Ajouter à chacune d'elles le(s) attribut(s) de jointure si elle ne les possède pas.
3. Générer le complément de chaque expression (c'est à dire les autres attributs) en
ajoutant le (ou les) attribut(s) de jointure.
4. Pour chaque fragment Fi produit par la fragmentation horizontale, on recherche toutes
les requêtes qui concernent ce fragment et à prendre les expressions de projection de
ces requêtes.
5. A partir des n expressions de projection qui concernent Fi, il faut produire l'ensemble
des 2n intersections des expressions de projection.
Exercice :
Exercice : Soit la base de données relationnelles suivantes :
Client(NoClient, NomClient, PrénomClient, VilleCLient, Age)

Agence(CodeAgence, NomAgence, Adresse, Ville)
Compte(IdCompte, NCompte, Solde, NoClient, CodeAgence)
:@ '*+, !&,+,- !&,./é!,- r !&0 !& !" ⋈

1+X t, o Y6
:G '*+, !&, !&,1230 !& !" 1+X t, o j 6 ⋈
La fragmentation est :
1 !& !" 1+X t, o Y6

uvvw: g
11 '*+, !&,+,- !&,./é!,- r !&0 ⋉ 1
2 !& !" 1+X t, o j6

uvvx: g
22 '*+, !&, !&,1230 ⋉ 2
17
3 !&> !"
uvvy: g
3 ⋉ 3
12 '*+, !&, !&,1230 ⋉ 1

uvvz: g
21 '*+, !&,+,- !&,./é!,- r !&0 ⋉ 2
uvv€: { 5 no ,-|& +qrr ⧑
IV- 3 Processus d’allocation des fragments.
L’affectation des fragments sur les sites est décidée en fonction de l’origine prévue des
requêtes qui ont servi à la fragmentation. Le but est de placer les fragments pour minimiser
les transferts de données entre les sites.
IV-3-1- Types d’allocation
a- Allocation sans réplication
Un fragment ne peut exister que dans un seul site. Ici, 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.
b- Allocation avec réplication des données
Pour des raisons de fiabilité et d’optimisation on peut décider de répliquer les données sur
tous les sites. Ainsi, si un site est temporairement ou définitivement défaillant, on utilise
simplement un autre. Il existe deux types de réplication
a. Types de réplication
Dans le cas d’une allocation avec duplication, La diffusion des mises à jour appliquée à une
copie aux autres copies doit être assurée automatiquement par le SGBD réparti. Cette
diffusion peut être basées sur la diffusion de l'opération de mise à jour ou sur la diffusion du
résultat de l'opération. Un ordonnancement identique des mises à jour dans tous les sites
est nécessaire afin d'éviter les pertes de mises à jour.
i. Réplication asymétrique
Un site primaire seul autorisé à mettre à jour et chargé de diffuser les mises à jour aux
autres copies dites secondaire. Le site primaire effectue les contrôles et garantit
18
l'ordonnancement correct des mises à jour. On distingue l'asymétrique synchrone et

l'asymétrique asynchrone.
ii. Réplication symétrique
A l'opposé de la réplication asymétrique on ne privilégie aucune copie. Chaque copie peut

être mise à jour à tous instant et assure la diffusion des mises à jour aux autres copies. On
distingue aussi la symétrique synchrone et la symétrique asynchrone.
iii. Réplication synchrone (synchronous replication) :
Dans ce cas Une transaction est validée seulement lorsque tous les sites ont été mis à jour.
Ce type de réplication peut se faire à l’aide des triggers.
Exercice: Soient les fragments de la BDD Bank :
1 !& !" 1+X t, o Y6

uvvw: g
1 ⋉ 1
2 !& % & 1+X t, o j6
uvvx: g
2 ⋉ 2
3 c !&> !" i% t, o j6d 1+X !&> % & i% t, o Y6
uvvy: g
3 ⋉ 3
La répartition avec réplication des fragments sera faite dans trois sites distants suivant le
schéma de la figure-2. Pour assurer des opérations d’écriture synchronisées dans les différents
fragments on doit créer deux types de triggers.
19
- Des triggers de réplication qui permettent de synchroniser les insertions et les

suppressions dans les fragments répliqués SiteB2.BDD1 et SiteB3.BDD1 avec
l’insertion dans SiteB1.BDD1
- Des triggers de répartitions qui permettent d’automatiser les insertions des nouveaux
comptes dans les fragments concernés à partir d’une insertion dans la BDD globale.
Une proposition de répartition des différents triggers dans les trois sites est donnée par la
figure-3.
Figure-2 : Schéma de répartition de la base BDD
20
Figure-3 : Schéma de répartition des triggers dans les différents Sites.
Le trigger de la synchronisation de la réplication de BDD1 dans BDD2 et dans BDD3 est donné par :
create or replace TRIGGER Synchron_insert_Comptes

BEFORE INSERT on SiteB1.Comptes_B1
for EACH ROW
BEGIN
DECLARE
BEGIN
INSERT INTO SiteB2.comptes_B1 VALUES (:NEW.IDCOMPTE, :NEW.NCOMPTE, :NEW.SOLDE,
:NEW.NCLIENT, :NEW.CODEAGENCE);
INSERT INTO SiteB3.comptes_B1 VALUES(:NEW.IDCOMPTE, :NEW.NCOMPTE, :NEW.SOLDE,
:NEW.NCLIENT, :NEW.CODEAGENCE);
END;
END;
iv. Duplication asynchrone (asynchronousreplication) :
Les sites de réplication sont mis-à-jour en différé, à partir de la copie primaire, après la
confirmation de la transaction. Ce type de réplication peut se faire à l’aide des vues
matérialisées.
syntaxe :
CREATE MATERIALIZED VIEW TableCopie [REFRESH {FAST|COMPLETE|FORCE} [ON

COMMIT|ON DEMAND]] [FOR UPDATE] AS Select * from Table
21
Les Vue Matérialisées
Une vue matérialisée (VM) est un moyen simple de créer une vue physique d’une table. La
différence d’une vue standard c’est que les données sont dupliquées. On l’utilise pour, des
fins d’optimisation de performance, lorsqu’une requête demande l’exécution d’un ensemble
de sous-requêtes, ou pour faire des réplications de table.
La ‘fraicheur’ des données de la VM dépend des options choisies. Le décalage entre les
données de la table maître et la VM peut être nul (rafraichissement synchrone) ou d’une durée
planifiée : heure, jour,etc.
 Les méthodes de rafraichissement de la VM
FAST: mise-à-jour partielle de la copie locale. C’est la méthode la plus efficace, elle utilise
des journaux spécifiques traçant les modifications de la table maître.
COMPLETE: effectue le refresh complet en exécutant le SELECT de définition de la MV
FORCE: effectue un FAST si possible, sinon un COMPLET. C’est la méthode par défaut.
 Les modes de rafraichissement de la VM
ON COMMIT: synchrone, rafraîchissement lorsqu’une transaction modifiant les tables

maîtresses fait un commit
ON DEMAND asynchrone (défaut): rafraîchissement sur demande de l’usager (l’instant peut

être spécifié avec les clauses START et NEXT)
FOR UPDATE: permet de mettre à jour la copie locale (les changements sont propagés aux
tables maîtresses).
IV-3-2- Répartition des fragments
Le problème d’allocation consiste à définir une répartition des fragments sur les sites afin de
réduire le temps de réponse des requêtes sur des données distribuées avec ou sans
réplication sur plusieurs sites.
a- Méthode ABS (ALL Beneficial Sites): Cas de la réplication
La méthode ABS se base sur le principe de stocker un fragment sur tous les sites où le
bénéfice du stockage est supérieur à son coût.
Bénéfice = (temps de lecture distant - temps de lecture local)
Coût = coût de la mise à jour locale + coût des mises à jour distantes
22
Dans le cas d’une réplication des données :

- Une requête d’écriture (insertion, mise à jour et suppression) doit être effectuée sur
tous les sites où les données concernées par cette requête sont dupliquées.
- Une requête de lecture (sélection, projection) doit être effectuée à partie du site
local si les données consternées existent sinon à partir du site le plus rapidement
accessible.
Soient :
- : :@ , :G , … . . , :! Un ensemble de fragment d’une BDD
- R R@ , RG , … . . , R- Un ensemble de transactions qui peuvent être effectués en local

ou à distance sur chaque fragment.
- ~ {~@ , ~G , … . . , ~| „ Un ensemble de site à partie des quelles on peut exécuter des

transactions.
Définitions
- Une transaction est un ensemble d’opérations menées sur une BD,
- Ces opérations peuvent être en lecture et/ou écriture,
- Une opération est atomique, c’est donc une unité indivisible de traitement,
- Une transaction est soit validée par un commit, soit annulée par un rollback, soit
interrompue par un abort,
Le Temps totale pour exécuter un sous-ensemble de transaction R… R…@ , R…G , … . . , R… dans

un fragment Rk stocké dans un site Sh est donné par :
‡/C ,‡/F ,….‡/ˆ
~† ‰⎯⎯⎯⎯⎯⎯⎯‹ :Œ
R "" S RS • mP ŽS Ž~
@
Avec :
Fqi : fréquence d’une transaction Tri.

Nacci : nombre d’accès (en lecture ou en Ecriture) aux données d’un fragment Rk à partir d’une
transaction Ti
NSi : nbre de site (Local ou Distant) réalisant une transaction Ti en utilisant les données d’un
fragment Rk. Dans le cas d’un accès en locale ou en lecture NSi est toujours égal à 1
Tacc : temps d’accès en local ou à distance en lecture ou en écriture à un fragment Rk.
23
Le calcul doit se faire pour les accès Local et Distant, et pour les deux cas les accès en Lecture et
en Ecriture. Le temps total des accès en Ecriture représente un coût puisqu’il doit être réalisé
dans tous les sites où le fragment Rk est stocké. Par contre, si on retranche du temps d’accès
Distant en lecture le temps des accès Local en Lecture cela représente un bénéfice.
û R "" S 3r VR "" S 3X
eé é• R "" S rX ‘ R "" S rr
EL : Ecriture Local
ED : Ecriture Distant
LL: Lecture Local
LD : Lecture Distant
Exemple :
Soit une base de données fragmentée en R1, R2 et R3 et considérons cinq sites (S1, S2, .., S5). Les
données concernant les transactions effectuées sur les fragments sont données par les tableaux
suivant :
Fragment TACC_LL (ms) TACC_EL (ms) TACC_LD (ms) TACC_ED (ms)

R1 100 150 500 600
R2 150 200 650 700
R3 200 250 1000 1100
Table-1 : temps d’accès en Lecture et en Ecriture (Local et Distant) à un fragment Rk.
Transaction Sites Fréquence Accès Lecture Accès Ecriture

R1 T1 S1, S4, S5 1 3 1
T2 S2, S4 2 2
T3 S3, S5 3
R2 T1 S1, S4, S5 1 2
T2 S2, S4 2
T3 S3, S5 3 3 1
R3 T1 S1, S4, S5 1
T2 S2, S4 2 3 1
T3 S3, S5 3 2
Table-2 : Les Sites, Les fréquences, les nombre d’accès en lecture et en Ecriture par transaction et par fragment.
24
Ecriture Lecture
EL ED NsiteL NsiteD TaccEL TaccED Coût LL LD NsiteL NsiteD TaccLL TaccLD Benef Benef-Coût
R1 S1 T1 T1 de S4 et S5 1 2 150 1200 1350 T1 T1 de S4 ou S5 1 1 300 1500 1200 -150
S2 T1 de S1, S4 et S5 3 0 1800 1800 T2 T2 de S4 1 1 400 2000 1600 -200
S3 T1 de S1, S4 et S5 3 0 1800 1800 0 0 0 -1800
S4 T1 T1 de S1 et S5 1 2 150 1200 1350 T1, T2 T1 de S1 ou S5 1 1 700 3500 2800 1450
T2 de S2
S5 T1 T1 de S1 et S4 1 2 150 1200 1350 T1 T1 de S1 ou S4 1 1 300 1500 1200 -150
R2 S1 T3 de S3 et S5 2 0 4200 4200 T1 T1 de S4 ou S5 1 1 300 1300 1000 -3200
S2 T3 de S3 et S5 2 0 4200 4200 0 0 -4200
S3 T3 T3 de S5 1 1 600 2100 2700 T3 T3 de S5 1 1 1350 5850 4500 1800
S4 T3 de S3 et S5 2 0 4200 4200 T1 T1 de S1 ou S5 1 1 300 1300 1000 -3200
S5 T3 T3 de S3 1 1 600 2100 2700 T1, T3 T1 de S1 ou S4 1 1 1650 7150 5500 2800
T3 de S3
R3 S1 T2 de S2 et S4 2 0 4400 4400 -4400
S2 T2 T2 de S4 1 1 500 2200 2700 T2 T2 de S4 1 1 1200 6000 4800 2100
S3 T2 de S2 et S4 2 0 4400 4400 T3 T3 de S5 1 1 1200 6000 4800 400
S4 T2 T2 de S2 1 1 500 2200 2700 T2 T2 de S2 1 1 1200 6000 4800 2100
S5 T2 de S2 et S4 2 0 4400 4400 T3 T3 de S3 1 1 1200 6000 4800 400
25
Donc d’après cette analyse la répartition est :

R1  S4
R2  S3 et S5
R3  S2, S3, S4 et S5
IV-4 Les Requêtes Réparties

Les règles d'exécution et les méthodes d'optimisation de requêtes appliquées pour des BDD
centralisé sont toujours valables, mais il faut prendre en compte, d'une part, la
fragmentation et la répartition des données sur différents sites, et d'autre part le problème
du coût des communications entre sites pour transférer les données.
Les requêtes d’insertion de mise à jour et de suppression vont être concernées par le
problème de la fragmentation avec ou sans duplication tandis que les requêtes de sélection
et de projection vont être concernées par le problème des coûts des communications entre
les sites.
IV-4-1 les requêtes d’insertion de mise à jour et de suppression
- Insertion
Il faut retrouver le fragment horizontal concerné en utilisant les conditions qui définissent
les fragments horizontaux, puis insertion du tuple dans tous les fragments verticaux
correspondants.
- Suppression
Rechercher le tuple dans les fragments qui sont susceptibles de contenir le tuple concerné,
et supprimer les valeurs d'attribut du tuple dans tous les fragments verticaux.
- Modification
Rechercher le tuple dans les fragments qui sont susceptibles de contenir le tuple concerné,
et modifier les valeurs d'attribut du tuple dans tous les fragments verticaux.
Exemple : trigger pour suppression des données dans les fragments répliqués :
create or replace TRIGGER NomTrigger

AFTER DELETE on BDD1.Table
for EACH ROW
BEGIN
DECLARE
BEGIN
DELETE from BDD2.Table WHERE BDD2.Table.Attribut=:old.Attribut;
DELETE from BDD2.Table WHERE BDD3.Table.Attribut=:old.Attribut;
……
DELETE from BDD2.Table WHERE BDDn.Table.Attribut=:old.Attribut;
END;
END;
26
Exemple2 : trigger pour la mise à jour des données dans les fragments répartis :
Soient C1 et C2 les conditions de répartition des données dans respectivement dans « Site1 »
et « Site2 ». Les données qui ne respectent pas C1 et C2 sont stockées dans « Site ».
L’algorithme du trigger responsable à la répartition de la mise à jour est donné par :
Si (OLD.données vérifient C1) alors

Si(NEW.données vérifient C1) alors
Update les données du Site1
sinon
DELETE les données du Site1
INSERT les données dans Site2
Fin SI
Fin SI
Sinon Si (OLD.données vérifient C2) alors
Update les données du Site2
sinon
DELETE les données du Site2
Fin SI
Fin SI
Sinon Si (NEW.données vérifient C1) alors
Sinon Si(NEW.données vérifient C2) alors
Fin Si
IV-4-2 Optimisation des requêtes réparties
Dans le cas des requêtes locales le coût provient principalement du nombre d’entrée et sortie en
mémoire secondaire. À ce coût s’ajoute celui de transfert de données entre les sites dans le cas
des requêtes réparties.
a- Optimisation des requêtes dans une BDD centrale.
Dans les SGBD l’optimiseur restructure les arbres algébriques des requêtes afin de minimiser
le temps de réponse des requêtes complexe demandant plusieurs jointures. On préfère toujours
faire des produits cartésiens avec le minimum de tuples possible. On cherche donc à
remplacer les jointures par les semi-jointures.
27
Soit deux relations suivantes :
R1(a, b, c, d)
R2(x, y, z)
Soit la requête suivante :
’Y6 ' , :@ ⨝:G
En SQL cette requête peut être écrite suivant trois algorithmes :
En utilisant des restrictions sur le produit cartésien :

SELECT a, b
FROM R1, R2
WHERE R1.a=R2.x AND y<0
En utilisant une restriction sur la jointure :

SELECT a, b
FROM R1 INNER JOIN R2
ON R1.a=R2.x
WHERE y<0
En utilisant une semi-jointure

SELECT a, b
FROM R1 WHERE a IN (SELECT x FROM R2 WHERE y<0) ;
Bien évidemment le dernier algorithme est celui qui sera utilisé par l’optimiseur pour
répondre à la requête.
Exemple :
Soit le schéma d’une BDD
Clients(codeclient, Société, Adresse, Tel)

Commandes(N°Commande, DateCommande, codeClient)
Produits(Réf, Designation, Stock, PrixUnitaire)
DétailCommandes(N°Commande, Réf, Quantité)
Question traitée : Quel sont les clients qui ont commandé le produit « Tarte au sucre »
avec une quantité par commande >20
Réponse en SQL
28
SELECT DISTINCT Clients.Codeclient, Société

FROM Clients, Commandes, Produits, [Détails Commandes]
WHERE Clients.Codeclient = Commandes.Codeclient
AND Commandes.N°commande = [Détails Commandes].N°commande
AND Produits.Réfproduit = [Détails Commandes].Réfproduit
AND Quantité > 20
AND Designation="Tarte au sucre"
ORDER BY Société;
L’arbre algébrique de l’exemple traité est donné par :
Clt = Client
Cde = Commande
DC = DétailsCommande
Ref = RéfProduit
Désig = Désignation
Qt = Quantité
Hypothèse :
Si on suppose que :
La table Client dispose de 1000 tuples.
La table Commande dispose de 4000 tuples
La table Détail Commande 8000 tuples
La table Produit 10000 tuples.
Dans ce cas les restrictions vont se faire sur une table de 1000×4000×8000×10000.
Restructuration de l’arbre algébrique
Afin de réduire le nombre de ligne des relations utilisées dans les jointures et par conséquent
réduire le coût de la requête, on propose la restructuration suivante de l’arbre algébrique.
29
On peut donc écrire la requête de l’exemple précédent de la manière suivante :
SELECT DISTINCT Clients.Codeclient, Société FROM (Clients INNER JOIN

Commandes ON Clients.Codeclient = Commandes.Codeclient) WHERE N°commande IN
(SELECT DISTINCT N°commande FROM [Détails Commandes] WHERE Quantité>20
AND Réfproduit IN (SELECT Réfproduit FROM produits WHERE designation="Tarte au
sucre"));
b- Optimisation des requêtes dans une BDD réparties.
Le parallélisme des opérations, c.-à-d. le calcule simultanément plusieurs opérations d’une

même requête, reste avantageux dans le contexte réparti. Pour effectuer ces opérations il faut
transférer entre les sites une quantité minimale de données.
Optimisation globale.
La règle est de transférer la plus petite table d’abord.
Soient des jointures entre les tables T1, T2 etT3. Chaque site « Si » contient une seule table
« Ti ».
Algo 1 :
Transférer T1 au site 2
30
R=T1 ⋈ T2 au site 2
R ⋈ T3 est le Résultat final au site 3

Transférer R au site 3
Algo 2 :
R=T1 ⋈ T2 au site 1
R ⋈ T3 est le Résultat final au site 3

Algo 3 :
T1 ⋈ T2 ⋈ T3 est le Résultat final au site 3

Si on suppose que le nombre de tuples de chaque relation est donné de telle sorte qu’on a :
NT1<NT2<NT3. L’algorithme algo-3 sera donc le plus optimal.
Optimisation par semi-jointure
la réglé est d’effectuer une semi-jointure au lieu d’une jointure complète.
Pour effectuer la jointure T1⨝T2 :
Algo 1 (sans optimisation) :
T1 ⨝ T2 = Résultat final au site 1

Transférer '1 R2 au site 1

Algo 2 (Optimisation par semi-jointure):
R1 ⨝ '1 R2 R1 ▷ R2 : au site 2
R ⨝ T2 = Résultat final au site 2

Il faut donc transférer au site1 seulement les colonnes de « T2 » nécessaires à la semi-jointure

(ensemble A). Renvoyer ensuite au site2 le résultat de la semi-jointure pour compléter la
jointure avec les autres colonnes.
Optimisation par Parallélisme inter-opération et inter-site
Soit les opérations : T1 ⨝ T2 ⨝ T3 ⨝ T4
Algorithme :
Transférer T2 au site1
31
R = T1 ⨝ T2 au site1
S = T3 ⨝ T4 au site 3
En parallèle, transférer T4 au site3
Ensuite, R ⨝ S = Résultat final au site 1

Transférer S au site 1
V- BD répartie avec Oracle
V-1 DATABASE LINKS
Un DBlink est un objet Oracle permettant de créer un lien entre plusieurs bases de données
Oracle, ce lien peut être sur le même hôte, sur un hôte appartenant au même domaine ou sur
tout autre hôte joignable par le protocole TCP/IP. Les BD link permettent de manipuler les
d’une BDD répartie sur plusieurs sites distant comme si c’était une BDD centrale stocké dans
un seul serveur. Pour créer un DBLink, il faut que les fichiers de configuration
« tnsname.ora » et « lestener.ora » soit correctement renseigné sur le service de connexion à
distance :
- Adresse : Protocol, Host et le Port
- Connexion des data : nom du serveur et le nom du service
Syntaxe :
CREATE [SHARED] [PUBLIC] DATABASE LINK nomLien CONNECT TO

compteUtilisateur IDENTIFIED BY “motDePasse” USING
‘Host:serveur/nomService’
- SHARED: permet de partager la connexion entre plusieurs usagers

- PUBLIC : rend le lien disponible à tous les usagers locaux
- nomService : Spécifie le nom de service d'une base de données distante. Si on spécifie
uniquement le nom de la base de données, Oracle ajoute implicitement le domaine de la
base de données à la chaîne de connexion pour créer un nom de service complet. Par
conséquent, si le domaine de la base de données distante est différent de celui de la base
de données actuelle, on doit spécifier le nom du service complet. Le nonService doit être
défini dans un fichier de configuration de la BDD Oracle (Listener.ora et tnsname.ora).
Exemple : soit deux sites distants appartements à un réseaux :
Dans Site1:
32
CREATE PUBLIC DATABASE LINKSITE2

CONNECT TO USERSITE2 IDENTIFIED BY ''1111'' USING 'SITE2';
On peut écrire la requête suivante pour interroger la BDD_Site2 à partir de SITE1.
Dans SITE1: SELECT * from BDD_SITE2.Table@LINKSITE2.
V-2 Transparence de localisation (SYNONYM)
Les synonymes fournissent à la fois l'indépendance des données et la transparence de

l'emplacement. Synonymes permet principalement de cacher la localisation des tables
distantes et donc de n’utiliser dans les requêtes que les noms des tables distantes.
CREATE [PUBLIC] SYNONYM BDD_SITE2.Table

FOR BDD_SITE2.Table@LINKSITE2.
SELECT * FROM BDD_SITE2
V-3 Manipulation des données dans une BDD Oracle répartie
Voir TP5
33

Chapitre-3 BDD Réparties

Transféré par

Informations du document

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Chapitre-3 BDD Réparties

Transféré par

Droits d'auteur :

Filière : Licence Génie Informatique

Les Bases de Données Réparties (BDR)

Table des matières

IV-3-2- Types de réplication ........................................................................................................... 18

II- Objectifs & Définitions

II-2 SGBD Répartie

II-3 Avantages et Inconvenants

1. Transparence pour l’utilisateur

Les principaux inconvenants sont :

1. Coût : la distribution entraîne des coûts supplémentaires en termes de communication,

III- Conception d’une base de données répartie

III-1 Conception descendante (top down design)

Fig-1 : Conception descendante

III-2 Conception ascendante (bottom up design)

- Identifier les données identiques

Fig-2 : Conception ascendante

III-3 Base de données fédérées & système multi base

III-4 Architecture d’une BDR

IV-1 Types de Fragmentation

Il existe plusieurs techniques de fragmentation :

IV-1-1- fragmentation par objet

Exemple : pour le schéma de BDD suivant :

Client(NoClient, NomClient, PrénomClient, VilleClient, Age)

Ce schéma peut être fragmenté de la manière suivante :

IV-1-2- fragmentation par occurrences (fragmentation horizontale FH)

Exemple : dans l’exemple précédent on peut réaliser la FH suivante :

IV-1-3- fragmentation par attributs (fragmentation verticale FV)

• L’opération de fragmentation sera donc la projection '

1 '*+, !&, +,- !&, ./ !,- !&0

2 '*+, !&, !&, 1230

La recomposition de la table Client est réalisée par l’opération : 1 ⋈ 2

IV-1-4- fragmentation hybride (FHY)

• L'opération de partitionnement est une combinaison de projections et de sélections.

Exemple : dans l’exemple précédent on peut réaliser la FHY suivante :

1 '*+, !&, +,- !&, ./ !,- !&0 123456

2 '*+, !&, !&, 1230 123456

3 '*+, !&, !&, 1230 123856

4 '*+, !&, +,- !&, ./ !,- !&0 12856

La recomposition de la table Client est réalisée par l’opération :

IV-1-5- fragmentation des occurrences connexes (fragmentation dérivée FD)

La fragmentation d’une relation R s’accompagne avec une fragmentation des

create or replace procedure DIVIDEClients is create or replace procedure

IV-2 Définition de la fragmentation

- Reconstitution : possibilité de reconstituer les BDD initiale à partir des fragments en

Exemple1 : Soit les deux relations suivantes :

La fragmentation suivante va engendrer une perte d’information.

RB1 : SELECT B1, B3 FROM RB;

En prenant les mêmes relations de l’exemple-1. La fragmentation suivante va

RB1: SELECT * FROM RB WHERE B2='Y1' and B3=1;

IV-2-1 Définition des fragments horizontaux d'une classe

Soient la requête suivante dont l’exécution est fréquente dans un site :

L’ensemble des conditions se compose de C1 et C2. Les fragmentations possibles sont :

Le schéma de fragmentation devient :

Exercice : Soit la base de données relationnelles suivantes :

Client(NoClient, NomClient, PrénomClient, VilleCLient, Age)

Proposer un schéma de fragmentation horizontale en tenant compte des requêtes suivantes :

Dans le site1 : :@ !& !" 1+X 123856

Dans le site2 : :G !& % & 1+X 123YE6

Soit les variables logiques représentant les conditions élémentaires suivantes :

`̅ bU UUU@ V TN@ dcS

D’après les conditions élémentaires on a :

La fragmentation proposée est :

1 !& !" 1+X 123856

2 !& % & 1+X 123YE6

3 c !&! !" i% 123456d1+Xc !&! % & i% 123jE6d

IV-2-2 Définition des fragments horizontaux d’un schéma

sélection avec jointure 1 à plusieurs :@ 1 ⋈∗ :G il faut respecter les règles suivantes :