Bachtarzi.

C Cours : bases de données avancées

Filière SITW Niveau : Master 1

Chapitre II Concepts de bases de données Distribuées

I- Introduction :
Les systèmes de gestion des bases données distribuées ont été inventés à la fin des années 70
afin d’intégrer les bases de données et les réseaux.

Définition : Une base de données distribuée est un ensemble de bases stockées sur plusieurs
machines dans le but de se comporter vis-à-vis des applications comme une base de données
unique.
D’une façon plus générale, lorsque le déroulement d’une transaction, invoque plus d’un
serveur, on parle de BD distribuée.

II- Objectifs des systèmes distribués :

II-1 Indépendance à la localisation : Le but est de permettre à l’utilisateur d’écrire ses

programmes sans se soucier de l’emplacement des données de façon à rendre les programmes
indépendants du stockage physique des données. Les vues utilisateur sont simplifiées ainsi
que l’écriture des requêtes.

II-2 Indépendance à la fragmentation : Une relation peut être fragmentée en plusieurs parties
chacune dans un site différent et là aussi, l’écriture des requêtes ne doit pas dépendre de cette
fragmentation.

II-3- Indépendance aux SGBD : Chaque base de données est gérée par son propre SGBD
(Oracle, Ingres …) et ceci ne doit pas se répercuter sur les programmes utilisateurs. Ceci
exige un mécanisme de traduction du modèle de données et du langage de requêtes de chaque
base de données.

II-4 Autonomie des sites : Chaque serveur participant dans la base de données distribuée doit
contrôler et gérer ses propres données de manière locale (gestion des schémas, contrôle des
transactions, les reprises après panne,…) indépendamment des autres sites.

Un SGBD distribué permet de gérer une BD distribuée en faisant appel à des SGBD locaux.
Pour cela, il a à sa disposition :
- dictionnaire de données réparties
- traitement des requêtes réparties
- gestion des transactions réparties
- communication de données inter-sites
- gestion de cohérence et de sécurité

III- Concepts de base des SGBD distribués :

III-1- Schéma local : chaque base de données locale met à la disposition des autres sites son
propre schéma.

III-2- Schéma global : Il définit la structure de la BDD indépendamment des concepts

d’implémentation.

1
Bachtarzi.C Cours : bases de données avancées
Filière SITW Niveau : Master 1
III-3- Niveaux de couplage : Il existe plusieurs niveaux de couplage dans un système
distribué.
Premier cas : la base n’est accessible que par le schéma global.
- La base Master ne contient que les méta-données
- Les accès aux sites locaux sont interdits.
- Couplage fort

Deuxième cas : Le site maître peut aussi contenir des données.

- autonomie des sites locaux
- couplage moyen

Troisième cas : Système faiblement couplé.

- Pas de schéma global.

IV- Conception d’une base de données distribuée : On distingue deux approches différentes.

IV-1- Conception descendante : utilisée lors de la constitution de nouvelles BD.

- On part du schéma global pour construire les schémas locaux.
- Facile à construire.

Etapes :
- Conception du schéma conceptuel global
- Distribution pour obtenir des schémas conceptuels locaux
- Fragmentation
- Affectation aux sites – Allocation

2
Bachtarzi.C Cours : bases de données avancées
Filière SITW Niveau : Master 1

IV-2- Conception ascendante : Intégration de BD existantes en une base distribuée.

- Le schéma global est construit à partir de schémas locaux.
- Nécessité d’une réconciliation sémantique due à l’hétérogénéité des données

Conception descendante Conception ascendante

BD- Repartie BD- Repartie

BD locale1 BD local2 BDlocale3 BD locale1 BD locale2 BD locale3

La distribution des données peut se faire de différentes manières :

- Distribution par fragmentation
- Distribution par réplication.

V- Fragmentation :
Consiste à distribuer sur différents sites des parties appelées fragments d’une table globale.

Pourquoi fragmenter ?
- De meilleures performances
- Réduire le trafic sur le réseau, donc une meilleure utilisation de ses possibilités
- répartir l'impact sur les processeurs et sur leurs entrées/sorties.
- L'utilisation de petits fragments permet de faire tourner plus de processus
simultanément

V-1- Fragmentation verticale : Découpage d’une table en relations par projection permettant
de sélectionner les colonnes composant chaque fragment. La table initiale doit pouvoir être
recomposée par jointure des fragments.

V-2- Fragmentation horizontale : Découpage d’une table en relations par utilisation de

prédicats permettant de sélectionner les lignes appartenant à chaque fragment.
- Adapté à la régionalisation d’une entreprise.

V-3- Fragmentation mixte : Application successives d’opérations de fragmentation

horizontale et verticale sur une relation globale.

VI- Schéma de répartition : Chaque fragment est placé sur un site. Un schéma doit être
élaboré afin de déterminer la localisation de chaque fragment et sa position dans le schéma
global. Lors de l’exécution d’une requête distribuée, le SGBDR doit décomposer sa requête
globale en plusieurs requêtes locales en utilisant son schéma de répartition.

3
Bachtarzi.C Cours : bases de données avancées
Filière SITW Niveau : Master 1

Requête répartie en lecture :

Requête répartie en SELECT nom

Lecture FROM client
Where numéro = 234

Schéma de Fragmentation
fragmentation

SELECT nom FROM client1

WHERE numéro = 234
UNION
SELECT nom FROM client2
WHERE numéro = 234

Schéma Optimisation
D’allocation
SELECT nom FROM client1@site1
WHERE numéro = 234
UNION
SELECT nom FROM client2@site2
WHERE numéro = 234

4
Bachtarzi.C Cours : bases de données avancées
Filière SITW Niveau : Master 1
VII- Outils de distribution :

VII-1- Data base link :

Les bases de données doivent se connaître via leurs meta-données. Ces liens logiques sont
appelés database links.
C’est un chemin de communication unidirectionnel d’une BD à une autre.
Il est contenu dans les meta-données de la BD.
Le chemin inverse n’est pas possible.

BD1 BD2

BD2 connaît BD1 mais l’inverse n’est pas vrai.

Si les deux BD doivent se connaître mutuellement, il faut créer deux database link.

BD1 BD2

Lien de BD1 sur BD2 est contenu dans BD1.

Lien de BD2 sur BD1 est contenu dans BD2.

Syntaxe de définition : (sous ORACLE)

CREATE [PUBLIC] DATABASE LINK dblink
[CONNECT TO user IDENTIFIED BY password]
[USING connect_string];

Types de database link:

Public database link: tous les utilisateurs PL/SQL de la base pourront utiliser ce lien
pour accéder aux données et aux objets de la BD distante correspondante.

Private database link: appartient à un schéma. Seul le propriétaire du lien pourra

l’utiliser afin d’accéder aux données de la BD distant.

VII-2- Transparence à la localisation des données :

Les programmes d’application ne doivent pas connaître la localisation physique des
données.
Les noms des objets doivent être indépendants de leur localisation.
Le concept d’indépendance à la localisation peut être traité avec des synonymes.
CREATE [PUBLIC] SYNONYM synonyme
FOR objet [@dblink] ;

5
Bachtarzi.C Cours : bases de données avancées
Filière SITW Niveau : Master 1

Exemple : CREATE SYNONYM ma-table

FOR mon-fragment@mondblink;

Le fragment peut alors être utilisé sans connaître sa localisation.

VII-3- Lecture de données distribuées :

Cas d’une fragmentation horizontale :

-- Création des db_link :

CREATE DATABASE LINK bd1.world
CONNECT TO mon-user IDENTIFIED BY mon-password
USING ‘bd1’;

CREATE DATABASE LINK bd2.world

CONNECT TO mon-user IDENTIFIED BY mon-password
USING ‘bd2’;
-- Independence à la localisation:
CREATE SYNONYM d_tab2 FOR d_tab2@bd2;
CREATE SYNONYM d_tab1 FOR d_tab1@bd1;

CREATE OR REPLACE VIEW d-tab_fh AS SELECT code, libelle

FROM d_tab1
UNION
SELECT code, libelle
FROM d_tab2;
Cas d’une fragmentation verticale :
CREATE SYNONYM d_tab3 FOR d_tab3@bd3;

CREATE OR REPLACE VIEW d-tab_fv AS SELECT t1.code, libelle, libelle2

FROM d_tab1 t1 d_tab3 t3
WHERE T1.code = t3.code ;

VII-4- Mise à jour de données distantes et distribuées :

Le protocole RPC (Remote Process Call) est un protocole de mise à jour.

C’est l’appel d’un processus sur un système distant.
Dans le cas des BDD, il s’agit d’appeler une procédure stockée dans une autre BD.

L’appel se fait comme suit : EXECUTE map-roc@mon-alias;

mon-alias : alias de database link.

Le protocole se déroule comme suit :( pour INSERT, UPDATE, DELETE)

6
Bachtarzi.C Cours : bases de données avancées
Filière SITW Niveau : Master 1
- Le client émet la requête
- Il valide la transaction
- Il récupère un éventuel message d’erreur, mais n’attend pas de valeurs en retour
-- Mise à jour d’un fragment distant :
UPDATE ma-table@mon-alias
SET col = value WHERE condition;

Distribution des mises à jour :

La mise à jour dans une BD distribuée, nécessite que la base maître transforme une requêtes
en sous requêtes sur les fragments. Il faut donc connaître la localisation des fragments.
Si la localisation des fragments est stockée dans les méta-données, la distribution de la requête
de mise à jour peut être réalisée.

Cas particulier : ORACLE.

- Oracle ne dispose pas de méta-données de localisation des fragments.
- La solution apportée par ORACLE est l’utilisation des triggers (déclencheurs).
- Le programmeur devra écrire un trigger qui se déclenchera à la place de l’instruction de
mise à jour. Il permet de diviser la requête en sous- requêtes sur les fragments.

Triggers INSTEAD OF : Possibilité de modification des vues qui ne peut avoie lieu avec les
commandes SQL.
• Le trigger devra implémenter la règle de distribution.
• Le trigger devra rédiger la requête et la diviser vers les fragments.
Exemple : Règle de distribution sur le code. Fragment dans BD1 pour code de ‘A’ à ‘M’

Table
Numéro
Code
Libellé

Table1 Table2
Numéro Numéro
Entre A et M Code Code Entre N et Z
Libelle libelle

Trigger pour l’opération INSERT:

CREATE TRIGGER tr_tab
INSTEAD OF INSERT ON d_tab
BEGIN
IF :New.code <= ‘M’ THEN
INSERT INTO d_tab1 (numéro, code, libelle)
VALUES ( :New.numéro, :New.code, :New.libellé) ;
ELSE
INSERT INTO d_tab2 (numéro, code, libelle)
VALUES ( :New.numéro, :New.code, :New.libellé) ;
END IF ;
END;
/

7
Bachtarzi.C Cours : bases de données avancées
Filière SITW Niveau : Master 1

VIII- Notions de réplication:

La réplication consiste à créer des copies des tables on d’une partis des tables sur différents
sites.
Pourquoi répliquer ?
- Augmenter la tolérance aux pannes
- Améliorer la disponibilité des données.
- Diminuer l’engorgement au niveau d’un même serveur
- Avoir un meilleur temps de réponse
- Réduit les transferts de données
Principale fonction : maintenir les différentes copies dans un état cohérent.
Gestion des mises à jour (échange de messages inter-sites)

VIII-1- Définitions :

• Réplique : copie d’un ensemble de données de référence.

• Site primaire (ou maître ou référence)
- Application: accès en lecture/écriture,
- Transaction de mise à jour: plusieurs ordres select, update, insert, delete
•Site secondaire (ou esclave ou cible)
- Application: accès en lecture seule
- Requête: plusieurs ordres select
• Le SGBD (ou le réplicateur) gère la mise à jour
• Propagation: répercuter la mise à jour d’une donnée de référence, sur une donnée cible.

VIII-2- Comment répliquer ? Moyens :

• Caractéristiques des solutions de réplication :

- Selon l’endroit où les applications envoient leurs transactions
 un seul maître reçoit toutes les transactions
 plusieurs maîtres: une transaction xn est envoyée sur un des maîtres.
• Selon le moment où les mises à jour sont propagées (quand répliquer ?)
 propagation synchrone ou asynchrone des mises à jour
 Transactions réparties ou non (si réplication totale)

VIII-2-1- Réplication mono-maître :

• un seul maître par donnée:
Référence (R ou S)
• plusieurs esclaves : ri, si
(R) (r1) (r2)
(R) (S) (r1, s1)
(R), (S), (r1, s1), (r2, s2)
• un site esclave peut être maître pour une autre donnée
(R) (r1, S) (s1)

VIII-2-2- Réplication multi-maîtres :

• Plusieurs maîtres pour une donnée (R1, R2)
• Mises à jour sur R1 et R2
• Pb: propagation des mises à jour. Plus difficile à sérialiser que mono-maître

8
Bachtarzi.C Cours : bases de données avancées
Filière SITW Niveau : Master 1

VI-2-3- Propagation des mises à jour :

• Les mises à jour de R sont réparties sur plusieurs maîtres (R1) … (Rn)
• Une réplique (r) doit recevoir toutes les mises à jour reçues par les maîtres
• Propagation : - gérée par le SGBD réparti
- Synchronisée ou non, avec la transaction

1. Le site maître reçoit un ordre de mise à jour (INSERT, UPDATE ou DELETE).

2. Les modifications faites sur les données sont enregistrées dans une table ou un fichier
en vue de leur propagation.
3. Le processus de réplication se charge de propager les modifications sur le ou les sites
esclaves.

Synchrone ou asynchrone: détermine quand les mises à jour sont propagées vers tous les sites:

VIII-2-4- Propagation synchrone (eager):

Les mises à jour sont propagées durant la transaction (avant le commit).
• Avant la validation de la transaction
• L’application obtient une réponse après la propagation
1) transaction locale  2) propagation  3) validation  4) réponse
• Propagation : nombre de messages échangés entre sites
- Immédiate après chaque opération (L, E)
1 message par opération (L/E): interaction linéaire
- Différée juste avant la fin de la transaction
1 message par transaction : interaction constante

VIII-2-5- Propagation asynchrone (lazy):

Les mises à jour sont propagées après la fin de la transaction (après le commit).
• L’application obtient une réponse avant la propagation
1) transaction locale  2) validation locale  3) réponse
4) propagation  5) validation
• Pessimiste : Mises à jour et propagations faites dans un ordre sérialisable prédéfini
pour les transactions
• Optimiste : Ordre entre transactions calculé en cours d’exécution en fonction des
opérations commutatives, conflictuelles.
Possibilité d’abandon

Solution implémentée par oracle : (Snapshot)

o Lecture: maintenir plusieurs versions d’une donnée
- Marquer une version avec le n de transaction qui a créé la version
- Lire la version marquée de la dernière transaction ayant modifié X et validé.

o Ecriture
- Vérifier la version : si X modifié depuis le début de T, alors abandon

Architecture client/serveur :
Portion client : application frontale qui converse avec le client.
Le client émet les requêtes.
Portion serveur : gère les fonctions liées aux accès concurrents
Accepte les instructions SQL et PL/SQL émises par les applications clientes.

9
Bachtarzi.C Cours : bases de données avancées
Filière SITW Niveau : Master 1
Traite les requêtes et transmet les résultats aux clients

Exemple :

Serveur Réseau Serveur

de de
BD liaison BD

Table serv BD Table EMP BD

Siège Ventes

Un noeud peut se comporter comme client, serveur ou les deux en fonction de la situation.
Si requête : DELETE FROM Serv….  nœud siège sera le serveur.
Si requête : INSERT INTO Emp@Ventes….  nœud siège sera le client.

Les BD oracle utilisent le logiciel Net8 qui leur permet de communiquer en réseau et de
prendre en charge les txns distantes et distribuées.

Oracle utilise le principe de réplication grâce à des instantanés (Snapshots).

Il existe plusieurs niveaux de réplication.
o Réplication de base : des réplicas de tables sont gérés pour l’accès en lecture seule.
Pour les mises à jour, on ne peut accéder aux données que sur un seul site primaire.
o Réplication avancée : permet aux applications de mettre à jour des réplicas de tables
à travers une BDD répliquée. Les données peuvent être lues et mises à jour sur
n’importe quel site.

Un snapshot génère une copie d’une partie de la base au moyen d’une requête :
CREATE SNAPSHOT Ventes.Commandes AS
SELECT * FROM ventes.commandes;

Si la requête de définition contient une clause GROUP BY ou des opérations JOIN ou SET, il
s’agit d’un snapshot complexe qui nécessite un traitement supplémentaire.

10