BASES DE DONNEES

DISTRIBUEES
Ce support de cours présente les concepts fondamentaux des bases de données
distribuées, partant des mécanismes aux outils de gestion des systèmes distribués et
fédérés

Sommaire

Leçon 1 : Généralités sur les bases de données distribuées.………………………………… P. 1

I. Définition………………………………………………………………….......... P. 1
II. Problématique…………………………………………………………………... P. 1 III. But
de la répartition……………………………………………………………… P. 2
IV. Architecture de la répartition des données………………………………………… P. 2
V. Avantages ………………………………………………………………………... P. 4
VI. Contraintes………..………………………………………………………………. P. 4
Leçon 2 : Conception d’une base de données distribuées…...……………………………… P. 5 I.
Conception descendante…………………………………………………………… P. 5 II.
Conception ascendante…………………………………………………………….. P. 6
Leçon 3 : Fragmentation……………………………………………………………………… P. 8
I. Généralités………………………………………………………………………… P. 8
II. Types de fragmentation……..……………………………………………………... P. 9
Leçon 4 : Allocation des fragments………………………………………………………..... P. 12 I.
Les schémas de répartition………………………………………………………... P. 12
II. Techniques de répartition avancée………………………………………………. P.
12
Leçon 5 : La réplication………………………………………………………........................ P. 14
I. Définition………………………………………………………………………….. P. 14 II.
Principe de réplication…………………………………………………………….. P. 14 III. Types
de réplication……………………………………………………………… P. 14 IV. Vue
matérialisée………………………………………………………………….. P. 16
V. Les avantages de la réplication…………………………………………………… P.
17
Leçon 6 : Gestion des données réparties…………………………………………………....... P. 18 I.
Mise à jour des données distantes…………………………………………………. P. 18
II. Contraintes déclarations…………………………………………………………… P.
18
Leçon 7 : Les transactions réparties………………………………………………………... P. 20 I.
Définition ………………………………………………………………………….. P. 20
II. Contrôle de concurrence…………………………………………………………. P. 21
III. Transactions réparties……………………………………………………………. P. 22
Leçon 8 : Les requêtes réparties………….…………………………………………………. P. 23
I. Définition ……......................................................................................................... P. 23
II. Optimisation …..…………………………………………………………………... P. 23
Leçon 9 : Architecture des systèmes parallèles…………………………………………….. P. 26 I.
Architecture à mémoire partagée…….……………………………………………. P. 26
II. Architecture à disque partagée………….…………………………………………. P. 27 III.
Architecture à mémoire distribuée………………………………………………… P. 27
IV. Architectures hybrides……………………………………………………………. P.
28

i
 Leçon 1 : Généralités sur les Bases de données
Distribuées

Objectif : Présenter les bases de données distribuées, les architectures

globales et les avantages et les contraintes liés à leur utilisation.

I. Définitions

 Une base de données est une collection de données organisées de façon à être accessibles,
administrées et mise à jour. Les bases de données peuvent être classées par le type de contenu
qu’elles renferment : données géographiques, données statistiques …

Cette définition englobe le concept de « centralisation », c’est-à-dire que la base de données est
stockée dans sa totalité à un emplacement physique unique.

 Le Système de gestion des bases de données (SGBD) est le logiciel destiné à stocker et à
partager les informations contenues dans une base de données. (MySQL, Oracle, PostGreSQL,
etc…). Une base de données centralisée est gérée par un seul SGBD.

 Une Base de données Distribuées (BDD), en anglais : DDB « Distributed DataBase », est une
base de données dont la gestion est traitée par un réseau d’ordinateurs interconnectés qui
stockent les données à différents emplacements physiques. Ce stockage peut être soit
partitionnée entre différents nœuds du réseau, soit répliqué entièrement sur chacun d’eux, soit
organisé de façon hybride. Une BDD est gérée par plusieurs processeurs, sites ou SGBD.

II. Problématique

Les BDD sont d'abords des bases de données normales. En fait, elles sont issues de l'évolution
de ces dernières. En effet, la gestion de bases de données avec le temps, s'est confrontée à divers
problèmes qui sont :

1
 - L'augmentation du volume de données ;
- l'augmentation du volume de traitements ;
- l'augmentation du volume de transactions ;

Cela a entraîné la lenteur des applications, car les périphériques de stockage submergés, ne
répondant pas assez vite. Aussi, il a été noté que les débits des liaisons réseaux évoluaient beaucoup
plus vite que les capacités des périphériques de stockage.

Ainsi, l'idée est venue de multiplier les sources de données et les faire communiquer par réseau,
afin de bénéficier de traitements parallèles, minimisant ainsi les temps de réponses. Aujourd'hui, les
BDDs sont de plus en plus répandus, et comblent largement les lacunes des bases de données classiques.

III. Buts de la répartition des bases de données

Les bases de données distribuées ont une architecture plus adaptée à l’organisation des
entreprises décentralisées. Elles offrent :

- Plus de fiabilité : les bases de données réparties ont souvent des données répliquées. Ainsi, la
panne d’un site n’est pas très importante pour l’utilisateur, qui s’adressera à autre site.

- De meilleures performances : la réduction du 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.

- Une possibilité d’évolution technique : par l’ajout de machines sur le réseau.

IV. Architecture de la répartition des données

Dans un environnement de bases de données réparties, il existe 2 principaux types

d'architectures :
- L’architecture client – serveur ; -
L’architecture serveur – serveur.

1) L'architecture client-serveur
2
 Dans cette architecture, l'application client se connecte au serveur de base de données (ici
Oracle 10g). Ce dernier à son tour, leur renvoie des réponses en fonction de leurs requêtes.

2) L'architecture serveur-serveur

Dans un système de bases de données réparties, il existe en général plusieurs serveurs de

données qui fonctionnent selon l'architecture suivante :

Chaque serveur gère sa base de données et échange les informations avec les autres. Le tout est
vu comme une seule base de données logique.

De façon globale voici comment fonctionne un système de base de données distribuées:

3
 Les clients se connectent à leurs serveurs respectifs, et ces derniers s'échangent les
informations si nécessaires.
V. Avantages

Les avantages dans la mise en place d’une BDD sont les suivantes :
- Transparence pour l’utilisateur ;
- Autonomie de chaque site ;
- Absence de site privilégié ;
- Continuité de service ;
- Transparence vis à vis de la localisation des données ;
- Transparence vis à vis de la fragmentation ;
- Transparence vis à vis de la réplication ;
- Traitement des requêtes distribuées ;
- Indépendance vis à vis du matériel ;
- Indépendance vis à vis du système d’exploitation ;
- Indépendance vis à vis du réseau ; - Indépendance vis à vis du SGBD.

VI. Contraintes

- 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).

- 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.

4
 Leçon 2 : Conception d’une Base de données
Distribuée

Objectif : Présenter les méthodes de conception d’une base de données

distribuée.

Avant de concevoir une base de données distribuée, il est nécessaire de bien comprendre les
étapes de conception, car différentes méthodes de conception existent et chacune d'elles nous offre une
approche très différente de l'autre.

Dans le cas d'une base de données distribuée, la difficulté réside dans le choix des
techniques de conception, un mauvais choix pourrait conduire à la création d'un système inefficace.

La conception d'une base de données répartie peut être le résultat de deux approches
totalement distinctes, soit d'une part le regroupement d'une multitude de bases de données déjà
existantes d'autre part, que cette dernière soit construite du zéro.

La définition du schéma de répartition est la partie la plus délicate de la phase de conception

d'une BDD, car il n'existe pas de méthode miracle pour trouver la solution optimale. L'administrateur
doit donc prendre des décisions dont l'objectif est 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.

5
 Deux approches fondamentales sont à l'origine de la conception des bases de données réparties
: la conception descendante 'Top down design' et la conception ascendante 'Bottom up design'.

I. Conception descendante (Top down design)

On commence par définir un schéma conceptuel global de la base de données répartie, puis on
distribue sur les différents sites en des schémas conceptuels locaux.

La répartition se fait donc en deux étapes :

- en première étape la fragmentation,
- en deuxième étape l’allocation de ces fragments aux sites.

Architecture de la conception descendante

L’approche top down est intéressante quand on part du néant. Si les BDs existent déjà la
méthode bottom up est utilisée.

II. Conception ascendante (bottom up design)

L’approche se base sur le fait que la répartition est déjà faite, mais il faut réussir à intégrer les
différentes BDs existantes en une seule BD globale. En d’autres termes, les schémas conceptuels locaux
existent et il faut réussir à les unifier dans un schéma conceptuel global.

6
 Architecture de la conception ascendante

La répartition d'une base de données intervient dans les trois niveaux de son architecture en
plus de la répartition physique des données :
- 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.

Schéma d’une BDD

7
 Leçon 3 : Fragmentation

Objectif : Présenter les règles et techniques de fragmentation ainsi que les

méthodes de gestion des fragments obtenus.

I. Généralités

1) Définition

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 sans perte d'information.

Les applications ne travaillent que sur des sous-ensembles des relations. Une distribution
complète des relations générerait soit beaucoup de trafic, soit une réplication des données avec tous les
problèmes que cela occasionne : problèmes de mises à jour, problèmes de stockage. Il est donc
préférable de mieux distribuer ces sous-ensembles.

L'utilisation de petits fragments permet de faire tourner plus de processus

simultanément, ce qui entraîne une meilleure utilisation des capacités du réseau d'ordinateurs.

8
 2) Règles de fragmentation

Les règles de fragmentation sont les suivantes :

- 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.

- La Disjonction : une donnée n'est présente que dans un seul fragment, sauf dans le cas de la
fragmentation verticale pour la clé primaire qui doit être présente dans l'ensemble des
fragments issus d'une relation.

3) Les problèmes de la fragmentation

La fragmentation peut être coûteuse s'il existe des applications qui possèdent des besoins
opposés. On est en quelque sorte dans le cas d'une exclusion mutuelle qui empêche une fragmentation
correcte.

Par ailleurs, la vérification des dépendances sur différents sites peut être une opération très
longue.

II. Types de fragmentation

Il existe plusieurs techniques de fragmentation, définies par l’unité de fragmentation. Les

techniques les plus utilisées sont :

- La fragmentation horizontale : basée sur des sélections

- La fragmentation verticale : basée sur des projections

1) Répartition des classes d'objet

9
 Cette technique de fragmentation consiste en la répartition de classes (relation en relationnel,
classe en Orienté-objet) qui peuvent être réparties sur différents fragments. Toutes les occurrences
d'une même classe appartiennent ainsi au même fragment.

- L'opération de partitionnement est la définition de sous-schémas.

- L'opération de recomposition est la réunion de sous-schémas.

Dans l'exemple suivant la base de données relationnelle peut être fragmentée en {Compte,
Client} et {Agence}

N°_client Agence Type_compte Somme

000123 Yaoundé Courant 1.345.628 Relation « Compte »
000234 Douala Courant 785.870
000345 Yaoundé Courant 987.546 Agence Adresse
000465 Yaoundé Dépôt 369.852 Yaoundé Avenue Germaine Ahidjo, 10325 Yaoundé
000798 Douala Courant 2.741.963 Douala Avenue Leclerc, 2358 Douala
Relation « Agence »

Relation « Client »

N°_client Nom_client Prénom Age

000123 Ntamack Odilon 32
000234 Demguia Carine 26
000345 Ongali Martin 45
000465 Essomba Juste 30
000798 Yawata Merlin 25
2) La fragmentation horizontale (Répartition des occurrences)

C'est un découpage d'une table en sous tables par utilisation de prédicats permettant de
sélectionner les lignes (tuples) appartenant à chaque fragment.

- L'opération de fragmentation est obtenue grâce à la sélection σ) des tuples d'une table
(
selon un ou des critères bien précis.

- L’opération de reconstitution de la relation initiale se fait grâce à l'union (U) des

sousrelations.

Exemple :
Compte

N°_client Agence Type_compte Somme

1
 000123 Yaoundé Courant 1.345.628
000234 Douala Courant 785.870
000345 Yaoundé Courant 987.546
000465 Yaoundé Dépôt 369.852
000798 Douala Courant 2.741.963

Compte1

N°_client Agence Type_compte Somme

000465 Yaoundé Dépôt 369.852

Compte2

N°_client Agence Type_compte Somme

000123 Yaoundé Courant 1.345.628
000234 Douala Courant 785.870
000345 Yaoundé Courant 987.546
000798 Douala Courant 2.741.963

= "courant" = "dépôt"

La reconstitution est : = ∪

3) La fragmentation verticale (Répartition des attributs)

Elle est le découpage d'une table en sous-tables par projection permettant de sélectionner les
colonnes composant chaque fragment.

- L'opération de fragmentation est obtenue grâce à la projection ( ) des colonnes d'une

table.

-L’opération de reconstitution de la relation initiale se fait grâce à la jointure (*) des

fragments.
Exemple :
Client

N°_client Nom_client Prénom Age

1
 000123 Ntamack Odilon 32
000234 Demguia Carine 26
000345 Ongali Martin 45
000465 Essomba Juste 30
000798 Yawata Merlin 25

N°_client Prénom Age

000123 Odilon 32
Client1
000234 Carine 26
000345 Martin 45
000465 Juste 30
000798 Merlin 25

N°_client Nom_client
000123 Ntamack
000234 Demguia Client2
000345 Ongali
000465 Essomba
000798 Yawata

! = "[$°_ !;$( !] !

La reconstitution est : ! = ! ∗ !

4) La fragmentation mixte ou hybride (Répartition des valeurs) :

Elle résulte de l'application successive d'opérations de fragmentation horizontale et verticale

sur une relation globale. Les occurrences et les attributs peuvent donc être répartis dans des partitions
différentes.

- L'opération de fragmentation est une combinaison de projections (π) et de sélections (σ .

- L'opération de reconstitution est une combinaison de jointures (*) et d'unions (U).

Exercice d’application :
En se référant à la table « Client », donner les tables dérivées (Cli3, Cli4, Cli5 et Cli6) issues
des fragmentations suivantes :
a) Relation Cli3 ="[$°_ !;$( !] ( [,-01]Client) ;
b) Relation Cli5 ="[$°_ !;$( !] ( [,-21]Client) ;
c) Relation Cli4 ="[$°_ !;$( !]Client ;
1
 d) Relation Cli6 ="[$°_ !;,-]Client.
Leçon 4 : Allocation des fragments

Objectif : Présenter les techniques de répartition des fragments obtenus

dans un schéma global.

Suite à la fragmentation des données, il est nécessaire de les placer sur les différentes
machines. Un schéma doit être élaboré afin de déterminer la localisation de chaque fragment
et sa position dans le schéma global, c'est ce qu'on appelle l'allocation.

I. Le schéma de répartition

Pour fragmenter les requêtes, il est nécessaire de connaître les règles de localisation
des données. Lors de l'exécution d'une requête, le SGBDR doit décomposer la requête globale
en sous requêtes locales en utilisant le schéma de répartition.

II. Techniques de répartition avancées

1) Allocation avec duplication

Cette technique consiste à dupliquer des parties de la base c'est-à-dire les fragments sont
dupliqués sur un seul site, voire plusieurs sites selon les besoins.

Cette approche est très intéressante car elle améliore considérablement les performances du
système, étant donné que les fragments sont dupliqués un peu partout et que les accès aux données
sont locaux, évitant ainsi la congestion du réseau et améliorant les temps de réponse.

Le principal inconvénient de cette technique est la difficulté des mises à jour de tous les
fragments dupliqués.

2) Allocation dynamique

Avec cette technique, l'allocation d'un fragment peut changer en cours d'utilisation de la
BDR, c'est-à-dire qu'un fragment qui se trouve sur un site A à un instant T, peut être retrouvé sur un
site B à un instant T+1. L’allocation dynamique est généralement employée dans une situation de
fragmentation dynamique.

1
 Dans certains cas, il est possible que deux fragments complémentaires (verticalement ou
horizontalement) se trouvent sur le même site suite au mouvement d'un fragment d'un site A vers un
site B. Donc, il est alors intéressant de les fusionner.
Cette technique est efficace mais exige le maintien du schéma d'allocation et des schémas
locaux.

L’allocation peut se faire avec réplication ou sans réplication. Sachant que la réplication
favorise les performances des requêtes et la disponibilité des données, mais est coûteuse en considérant
les mises à jour des fragments répliqués.

1
 Leçon 5 : La réplication

Objectif : Présenter concepts et techniques réplication (copie) des données

entre deux ou plusieurs bases de données.

I. Définition

La réplication consiste à copier les informations d'une base de données sur une autre. Elle
peut être accompagnée d'une transformation des données sources, voir souvent d'une agrégation. Dans
tous les cas, il s'agit d'une redondance d'information.

L'objectif principal de la réplication est de faciliter l'accès aux données en augmentant la

disponibilité, soit parce que les données sont copiées sur différents sites permettant de répartir les
requêtes, soit parce qu'un site peut prendre la relève lorsque le serveur principal s'écroule.

Une autre application tout aussi importante est l'amélioration des performances des
requêtes sur les données locales, et ceci permet d'éviter les transferts de données et d'accroître la
résistance aux pannes.

II. Principe de réplication

Le principe de la réplication, qui met en jeu au minimum deux SGBDs, est assez simple et se
déroule en trois étapes :

 La base « maître » reçoit un ordre de mise à jour (INSERT, UPDATE ou DELETE).

 Les modifications faites sur les données sont détectées et stockées dans un fichier ou une
file d'attente en vue de leur propagation.

 Le processus de réplication prend en charge la propagation des modifications à faire sur

une seconde base dite esclave. Il peut bien entendu y avoir plus d'une base esclave.

III. Type de réplication

1) Réplication asymétrique

1
 La réplication asymétrique distingue un site maître appelé site primaire, chargé de centraliser
les mises à jour. Il est le seul autorisé à mettre à jour les données, et chargé de diffuser les mises à
jour aux copies dites secondaires.

Le plus gros problème de la gestion asymétrique est la panne du site primaire. Dans ce cas,
il faut choisir un remplaçant si l'on veut continuer les mises à jour.
On aboutit alors à une technique asymétrique mobile dans laquelle le site primaire change
dynamiquement. On distingue l'asymétrie synchrone et l'asymétrie asynchrone :

- Réplication asymétrique synchrone : elle utilise un site primaire qui pousse les mises à jour
en temps réel vers un ou plusieurs sites secondaires. La table répliquée est immédiatement
mise à jour pour chaque modification par utilisation de trigger sur la table « maître ».

Réplication asymétrique synchrone.

- Réplication asymétrique asynchrone : elle pousse les mises à jour en temps différé via
une file persistante. Les mises à jour seront exécutées ultérieurement, à partir d'un
déclencheur externe, l'horloge par exemple.

Réplication asymétrique asynchrone.

2) Réplication symétrique

A l'opposé de la réplication précédente, la réplication symétrique ne privilégie aucune copie

c'est-à-dire chaque copie peut être mise à jour à tout instant et assure la diffusion des mises à jour
aux autres copies.

Cette technique pose problème de la concurrence d'accès risquant de faire diverger les
copies. Une technique globale de résolution de conflits doit être mise en œuvre. On distingue la
symétrie synchrone et la symétrie asynchrone :

- Réplication symétrique synchrone : Lors de la réplication symétrique synchrone, il n'y a pas

de table « maître ». L'utilisation de trigger sur chaque table doit différencier une mise à jour

1
 client à répercuter d'une mise à jour par réplication. Cette technique nécessite l'utilisation de
jeton.

Réplication symétrique synchrone.

- Réplication symétrique asynchrone : Dans ce cas, la mise à jour des tables répliquées est
différée. Cette technique risque de provoquer des incohérences de données.

Réplication symétrique asynchrone.

IV. Vue matérialisée

Une vue matérialisée (VM ; En Anglais : Materialized View) est un moyen simple de créer
une vue physique d'une table. Elle correspond à une photo instantanée des données au moment de
l'exécution de la requête. À la différence d'une vue standard, le résultat de la requête est
physiquement stocké dans la base de données.

Les vues matérialisées peuvent porter sur des tables, mais aussi des vues ou des vues
matérialisées.

Exemple:
CREATE MATERILIZED VIEW mz-relation REFRESH COMPLET
ON DEMAND
AS
SELECT col1, col2 ... FROM ma-table;

1) Objectif

L'utilisation des vues matérialisées permet l'amélioration des performances d'accès et la

réduction du trafic sur le réseau, elles sont mises à jour périodiquement, ce qui les rendent très
efficaces.

1
 2) Mise à jour des vues matérialisées
Afin d'assurer une certaine cohérence des données, il faut mettre à jour les vues matérialisées
et les tables périodiquement. Il existe trois façons de mises à jour qui sont la régénération complète,
rapide et forcée :

- Rafraîchissement complet : Il va ré-exécuter la requête basée sur la table de base et remplace

l'ensemble des données de la VM par les données obtenues et ceci même si la table de base n'a
pas été modifiée, selon le volume de données qui satisfait la requête, ce rafraîchissement peut
être gourmant en ressource.

- Rafraîchissement incrémental : Son principe est de propager uniquement les données

modifiées depuis le dernier rafraîchissement. Ce type de rafraîchissement dit aussi rapide
nécessite que la base de données stocke les modifications enregistrées sur les données des
tables de base, on utilise pour cela un journal (fichier Log). Ces données sont stockées
jusqu'à ce que le rafraîchissement ait été effectué.

Ce type de rafraîchissement est particulièrement efficace si les tables de base sont relativement
peu modifiées. On considère que si plus de la moitié des lignes sont modifiées un
rafraîchissement complet sera plus efficace.

- Rafraîchissement forcé : Dans ce type de rafraîchissement, lorsqu'une régénération rapide

n'est pas possible, alors une régénération complète est exécutée.

V. Les avantages de la réplication

Les avantages de la réplication sont assez nombreux, selon le type on trouve :

- Allégement du trafic réseau en répartissant la charge sur divers sites. Par conséquent, rapidité
des accès aux données.

- Amélioration des performances des requêtes.

- Résistance aux pannes par l'augmentation de la disponibilité des données

1
 Leçon 6 : Gestion des données réparties

Objectif : Présenter les mécanismes de mise à jour des données réparties

sur des sites distants.

I. Mise à jour des données distantes

1) Requêtes réparties en lecture

Lors de l'exécution d'une requête en lecture, la base de données répartie va décomposer la

requête globale en sous requêtes locales à l'aide des métas donnés de distribution.

2) Requêtes réparties en écriture

La mise à jour des données sur une base de données réparties nécessite la validation préalable
de chaque site avant la demande du site coordinateur. Ce protocole se nomme « Validation à deux
phases » 2PC (Two Phases Commit) et garantit le tout ou rien dans une base de données répartie.

- La première phase réalise la préparation de l'écriture des résultats des mises à jour dans la
base de données et la centralisation du contrôle.

- Par contre la seconde phase « phase de validation » n'est réalisée qu'en cas de succès de la
phase 1, elle intègre les résultats des mises à jour dans la base de données répartie. Le
contrôle du système réparti est centralisé sous la direction d'un site appelé coordinateur. Les
autres sites sont nommés des participants.

Protocole de validation à deux phases - 2PC.

1
 II. Contraintes déclaratives

Il est impératif dans une base de données répartie de placer des contraintes déclaratives
sur les données qui seront stockées dans le dictionnaire de données. Dans une base de données
répartie, il est nécessaire de dissocier deux types de contraintes :
- Les contraintes locales
- Les contraintes globales

1) Contraintes locales

Les contraintes locales sont des contraintes placées sur un seul site (schéma local).
Ces contraintes sont donc stockées dans le dictionnaire de chaque site.

2) Contraintes globales

Les contraintes globales doivent être placées sur la relation globale, il n'est pas
possible de les matérialiser. Nous pouvons dire qu'il est impossible de créer des contraintes
sur des vues, mais il est plus important de comprendre qu'une contrainte globale doit être
placée dans plusieurs dictionnaires.

Le schéma global n'étant pas physiquement implémenté, il n'est pas possible de mettre
en place ces contraintes de manière déclarative.

2
 Leçon 7 : Les transactions réparties

Objectif : Présenter les techniques de transaction et de contrôle des

données d’une base de données répartie.

I. Définitions

Une transaction désigne un ensemble d'opérations effectuées de manière indivisible 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.

Une transaction a une marque de début (Begin Of Transaction : BOT), et une marque de fin
(End Of Transaction : EOT).

Afin de garantir la stabilité du système, une transaction validée est garantie par quatre
propriétés indispensables (l’A.C.I.D.d’une transaction) :

- L'Atomicité : Cette propriété signifie que toutes les opérations d'une transaction sont menées
de façon indivisible ; toutes les 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.

Exemple de transaction : Cas de transfert d’argent d’un compte épargne vers un compte courant.

Begin Transaction TransfertCE/CC

2
Begin
Input(somme, numClt)
EXEC SQL UPDATE ComptesEpargne
SET solde = solde – somme
WHERE numClient = numClt ;
EXEC SQL UPDATE ComptesCourant
SET solde = solde + somme
WHERE numClient = numClt ;
Output(“Transfert compte épargne vers compte courant effectué ”)

End

II. Contrôle de concurrence

Afin d'améliorer les performances dans les traitements de bases de données, il est utile de
mener en parallèles plusieurs transactions. Dans ce cas, des mécanismes sont mis en place pour
gérer leurs accès concurrents aux données.

1) Les méthodes utilisées

a) Verrouillage

La méthode la plus utilisée pour gérer des accès concurrents est bien sûr celle des
verrouillages. Cette méthode est appelée verrouillage à 2 phases :

- La phase de croissance : Elle consiste pour chaque transaction avant de débuter de s'assurer
de la disponibilité des données requises en y plaçant des verrous.

- La phase de diminution : Si un objet est déjà verrouillé, la transaction ne peut débuter. ainsi
dans cette phase, les verrous sont enlevés.

b) Estampilles

L'autre méthode de contrôle de concurrence est la méthode des estampilles. Ici, à chaque
transaction est attribué un numéro par un compteur. Les transactions s'exécutent par ordre
croissant.

Dans le cas de systèmes distribués, l'ordre global est partiel, mais total sur chaque site. En effet
chaque site a son compteur. L'ordre global peut devenir total si à chaque site est attribué aussi un
numéro.

2) Inter blocages

Lorsqu'on applique un système de verrouillage, on doit toujours penser au problème d'inter

blocage. En effet supposons qu'une transaction a mis un verrou sur un objet A et attend un objet B

2
verrouillé par un autre, qui a son tour attends de verrouiller l'objet A. Dans ce cas de figure, il est clair
que les deux transactions vont s'attendre indéfiniment : c'est l'inter blocage.

Afin de gérer les inter-blocages, trois principales actions peuvent être effectuées :

- Détecter les inter-blocages et les résoudre

- Prévenir les inter-blocages avant qu'ils n'apparaissent !
- Eviter les inter-blocages, par la façon d'allouer les ressources.

La méthode la plus utilisée est la première, qui consiste à attendre que les inter-blocages
arrivent, les détecter, et décanter la situation. Pour cela, il est utilisé un graphe qui représente l'état
d'attente des transactions : c'est le WFG (Wait For Graph). Chaque nœud représente une transaction
en cours. Et les arcs entre les nœuds sont les attentes d'une transaction par rapport à l'autre.

Lorsqu’un cycle est détecté, on a un inter-blocage. La solution consiste à retirer (abort) une
transaction, afin de libérer ses ressources. Encore faudrait-il faire le meilleur choix, qui génère moins
de coûts.

Graphe attente locale 1 Graphe attente locale 2 Graphe attente globale

III. Transactions reparties

Dans le cadre de systèmes répartis, les algorithmes cités ci-dessus sont aussi valables. La
différence est qu'ici, une transaction peut être en attente pas seulement par rapport à une transaction
locale, mais située sur autre site. La gestion en est donc un peu plus compliquée.

Aussi, on peut avoir le cas d’une transaction répartie ; c'est-à-dire une transaction constituée
de plusieurs transactions locales. Dans ce cas, on utilise un protocole de validation à 2 phases.

- Dans la première phase dite phase de préparation, le site coordonnateur demande aux sites
participants de se préparer à la validation.

- Lorsqu'il reçoit les notifications positives il lance alors la phase de validation en donnant
l'ordre correspondant aux sites. Dans le cas contraire il donne l'ordre d'interrompre les
transactions.

2
 Validation à deux phases

Les transactions distribuées présentent deux avantages :

- Les données situées sur d’autres serveurs, peuvent être mises à jour, et les instructions
UPDATE peuvent être gérées comme étant une seule unité. - Utilisation du 2-PC
transparente à l’utilisateur.

Leçon 8 : Les requêtes réparties

Objectif : Présenter les mécanismes efficaces et efficients d’exécution des

requêtes dans une base de données répartie.

I. Définition

Une requête répartie est une requête s'effectuant sur une base de données répartie. Comme
une requête normale, elle se base sur les relations de la base et leurs champs, en utilisant l'algèbre
relationnel. Mais elle doit tenir compte en plus de certains paramètres essentiels de fragmentation, de
localisation afin d'optimiser le temps de réponse global de la requête.

Dans le cadre d'une base de données locale, 2 principaux paramètres sont considérés pour
l'optimisation des résultats à savoir :

- Les coûts d'accès aux entrées sorties ; -

Les capacités de traitement du CPU.

Pour une base de données distribuée, en plus de ces indices, il faut aussi tenir compte des coûts
de communication réseaux.

2
 II. Optimisation

L’Optimisation consiste à choisir parmi de nombreuses possibles, une stratégie d'exécution de

requête tant efficace que efficiente. En effet, lorsque l'utilisateur soumet une requête au SGBD, le
composant appelé le Query Processor entre en action pour récrire la requête sous une forme plus
simple, et optimale.

L'optimisation d'une requête intervient à deux principaux niveaux :

1) Décomposition de la requête

a) Normalisation
La normalisation consiste à écrire la partie critère (contenu dans la clause WHERE) sous
forme d'une conjonction de coordination ou disjonction de conjonction de prédicats. Ceci afin de
simplifier la clause et faciliter ainsi l'analyse et l'optimisation.

WHERE (a et b) ou (c et d).

b) Analyse
Après la normalisation, il est question d'analyser la requête afin de détecter et éliminer les
erreurs. Parmi elles on peut citer, la présence de champs ou relations inexistants, l'incohérence des
valeurs données avec les types réels des champs, etc.
c) Elimination des redondances
Ensuite, la requête est simplifiée en éliminant les redondances. En effet dans certains cas,
plusieurs formules identiques peuvent se retrouver au sein de la même requête.

Exemple : NON (NON A) == A

A ET A == A
A OU A ==A

Ainsi lorsque de tels cas sont détectés, le Query processor les simplifie et obtient une formule
finale plus claire.

d) Réécriture
La dernière phase de cette première partie consiste à réécrire la requête en une forme qui
améliore ou optimise le temps de traitement global. En effet, les opérations de l'algèbre relationnel à
savoir : l'Union, la Sélection, la Projection, la Différence, la jointure, le Produit cartésien n'ont pas les
mêmes complexités (voir tableau1). Alors il est plus avantageux d'exécuter de les exécuter dans l'ordre
de complexités croissantes.

Opérations Complexité en nombre de

données
- Sélection

2
 - O (n)
Projection (sans élimination des doublons)

Opérations Complexité en nombre de

données
- Projection (avec élimination des doublons)

- Union

- Jointure O (n*log n)

- Semi-jointure Quotient

- Opérations de mises à jour

- Produit Cartésien O (n2)

Tableau des complexités des opérations

Ainsi, le Query Processor reformule la requête dans ce sens, en appliquant les règles logiques
de commutativité, associativités, distributions, idempotence, etc ...

2) Répartition de la requête

Après la première partie citée ci-dessus, il faut tenir compte de la répartition des données :
c'est-à-dire de la fragmentation et de la localisation. En effet, il faut décomposer la requête globale en
requêtes sur les fragments. Ainsi des reconstructions sont encore faites afin d'annuler les formules dont
les conditions ne respectent pas les restrictions des fragments auxquelles elles font référence. Dans
certains cas aussi, on peut remplacer certaines opérations par d'autres, comme la jointure par la semi -
jointure car moins coûteuse.

Selon la localisation de chaque fragment et l'existence ou non de relations répliquées, une

stratégie d'exécution est mise en place afin de minimiser au maximum les trafics réseaux et bénéficier
de rapides accès aux données et traitements du CPU. Ainsi, en fonction de la topologie du réseau et de
son architecture il peut être plus avantageux d'exécuter tel fragment de requête sur tel site et pas sur un
autre. Par exemple dans le cas d'une architecture client Serveur, il faut choisir quels fragments
s'exécutera sur le client et quel autres sur le serveur. Aussi les coûts de communication n'étant pas les
mêmes sur un LAN que sur un WAN, les stratégies utilisées dans ces cas peuvent être différentes.

3) Schéma général de l'optimisation

2
 Maintenant, nous allons récapituler tout ce qui a été dit plus haut dans un schéma général
d'optimisation. Tout d'abord, il est important de mentionner que dans un système distribué,
l'optimisation peut se faire de trois manières principales :

- Une optimisation centralisée où un site central détermine la stratégie d'exécution sur tous les
autres sites. Dans ce cas, l'optimisation est plus facile mais souvent peu efficace car il faudrait
connaître exactement les indices de chaque site, ce qui n'est pas évident.

- Une optimisation distribuée où chaque site a sa propre stratégie d'optimisation

- Enfin on peut joindre les deux premières méthodes pour en faire une optimisation hybride.
Ainsi, dans un premier temps, un site décide de l'optimisation globale et ensuite chaque site
optimise à son tour, à son niveau. C'est cette dernière possibilité que nous illustrons dans le
schéma suivant.

Schéma général de l`optimisation

Leçon 9 : Architectures des Systèmes Parallèles

Objectif : Présenter les types d’architecture des bases de données

parallèles.

Dans ce qui suit, trois architectures parallèles, définies selon le critère de partage de
ressources, et une architecture hybride sont présentées.

I. Architecture à mémoire partagée (Shared-Memory)

Les disques et les mémoires centrales sont partagés par les processeurs du système.

2
 1) Avantages

- L’espace d’adressage global rend le système facile à implanter pour les vendeurs de SGBDs.
La communication inter-processeurs est rapide, vu l’accès partagé aux mémoires centrales.

- Equilibre de charge entre les processeurs facile à réaliser.

2) Inconvénients

L’échec d’un processeur n’entraîne pas la non-possibilité d’accès à données.

- Coût du système.

- Accès conflictuels aux mémoires centrales peuvent dégrader les performances.

- Le nombre de processeurs est limité à 20-30, un nombre supérieur crée des goulots
d’étranglements.

- Architecture non scalable.

Exemples de SGBD // : XPRS (U. de berkeley), DBS3 (Bull).

II. Architecture à disque partagé (Shared-Disk ou cluster)

Chaque processeur a sa mémoire centrale privée, mais les disques sont partagés par tous les
processeurs du système.

1) Avantages

- Equilibre de charge facile à réaliser.

- L’échec d’un processeur n’entraîne pas la non-disponibilité des données. 2) Inconvénients

2
 - L’inconvénient majeur est lié à la complexité du maintien de la cohérence des caches des
processeurs.

- L’accès aux disques peut créer un goulot d’étranglement, dû à la limite de la capacité du bus.

Exemples : IMS/VS (IBM), VAX DBMS (DEC) …

III. Architecture à mémoire distribuée (Shared-Nothing)

Chaque processeur a sa propre mémoire centrale et disque.

1) Avantage

- Coût abordable, vu que le système est une collection de PCs.

2) Inconvénients

- La haute disponibilité pose un problème. En effet, l’échec d’un processeur rend l’accès aux
données impossibles. D’où la nécessité de techniques de haute disponibilité (redondance ou
duplication). Ceci fait émerger un autre problème de maintien de la consistance des miroirs ou
des disques de redondance.

- Problème d’équilibre de charge dû au placement prédéterminé des données.

- Coût de transfert sur le réseau de grand volume de données, étant le résultat d’une requête.

Exemples : GAMMA (U. de Wisconsic), BUBBA (MCC),

IV. Architectures hybrides

2
 Une architecture hybride à deux niveaux, peut être au niveau interne une architecture à
mémoire partagée, et au niveau externe une architecture à mémoire distribuée. De telles architectures
combinent les avantages de chaque architecture, et compensent les inconvénients respectifs des
architectures.

L’architecture hybride illustrée ci-dessous combine l’équilibrage de la charge des architectures

à mémoire partagée et l’extensibilité des architectures à mémoire distribuée.

Les techniques de distribution des données sont au nombre de 3 :

- Par intervalle,

- Hachage,

- Donneur de carte (round robin).

3
 Table des matières

Sommaire………………………………………………………………………………………. P. i
Leçon 1 : Généralités sur les bases de données distribuées.………………………………… P. 1
VII. Définition………………………………………………………………….......... P. 1
VIII. Problématique…………………………………………………………………... P. 1
IX. But de la répartition……………………………………………………………… P. 2
X. Architecture de la répartition des données………………………………………… P. 2 1)
Architecture client/serveur……………………………………………………. P. 2
2) Architecture serveur/serveur………………………………………………… P. 3 XI.
Avantages ………………………………………………………………………... P. 4
XII. Contraintes………..………………………………………………………………. P.
4
Leçon 2 : Conception d’une base de données distribuées…...……………………………… P. 5 III.
Conception descendante…………………………………………………………… P. 5
IV. Conception ascendante…………………………………………………………….. P.
6
Leçon 3 : Fragmentation……………………………………………………………………… P. 8
III. Généralités………………………………………………………………………… P. 8
1) Définition……………………………………………………………………….. P.
8
3) Règles de fragmentation…..…………………………………………………... P. 8
4) Les problèmes de la fragmentation……………………………………………. P. 8
IV. Types de fragmentation……..……………………………………………………... P. 9 1)
Repartition des classes d’objets……………………………………………….. P. 9
2) Fragmentation horizontale…………………………………………………….. P. 10
3) Fragmentation verticale ………………………………………………………. P. 10
4) Fragmentation mixte ou hybride……………………………………………… P. 11
Leçon 4 : Allocation des fragments………………………………………………………..... P. 12 III.
Les schémas de répartition………………………………………………………... P. 12
IV. Techniques de répartition avancée………………………………………………. P.
12
1) Allocation avec duplication……..…………………………………………….. P. 12
2) Allocation dynamique……..…………………………………………………. P. 12
Leçon 5 : La réplication………………………………………………………........................ P. 14
VI. Définition………………………………………………………………………….. P. 14 VII.
Principe de réplication…………………………………………………………….. P. 14
VIII. Types de réplication……………………………………………………………… P. 14 1)
Réplication asymétrique……………………………………………………… P. 14
2) Réplication symétrique……………………………………………………….. P. 15
IX. Vue matérialisée………………………………………………………………….. P. 16 1)
Objectif………………………………………………………………………. P. 16
2) Mise à jour des vues matérialisées…………………………………………… P. 16
X. Les avantages de la réplication…………………………………………………… P. 17
Leçon 6 : Gestion des données réparties…………………………………………………....... P. 18
III. Mise à jour des données distantes…………………………………………………. P. 18
 1) Requêtes réparties en lecture………………………………………………….. P. 18
2) Requêtes réparties en écriture……………..………………………………….. P. 18
IV. Contraintes déclarations…………………………………………………………… P. 18
1) Contraintes locales……..……………………………………………………... P. 19
2) Contraintes globales…………………………………………………………. P. 19
Leçon 7 : Les transactions réparties………………………………………………………... P. 20 IV.
Définition ………………………………………………………………………….. P. 20
V. Contrôle de concurrence…………………………………………………………. P. 21

I
1) Méthodes utilisées…………………………………………………………… P. 21 a)
Verrouillage …………..…………………………………………………. P. 21
b) Estampilles…………….…………………………………………………. P. 21
2) Inter-blocages………………………………………………………………... P. 21
VI. Transactions réparties……………………………………………………………. P. 22
Leçon 8 : Les requêtes réparties………….…………………………………………………. P. 23
III. Définition ……......................................................................................................... P. 23
IV. Optimisation …..…………………………………………………………………... P. 23
1) Décomposition de la requête ………………………………………………….. P. 23 a)
Normalisation……….…………………………………………………….. P. 23
b) Analyse …...……………………………………………………………….
P. 23
c) Elimination des redondances………………………………………………
P. 24
d) Réécriture………………………………………………………………….
P. 24
2) Répartition de la requête …….………………………………………………... P. 25
3) Schéma général de l’optimisation……………………………………………... P. 25
Leçon 9 : Architecture des systèmes parallèles…………………………………………….. P. 26
V. Architecture à mémoire partagée…….……………………………………………. P. 26 1)
Avantages ……..………………………………………………………………. P. 26
2) Inconvénients………………………………………………………………... P. 26
VI. Architecture à disque partagée………….…………………………………………. P. 27 1)
Avantages……………………………………………………………………. P. 27
2) Inconvénients………………………………………………………………... P. 27
VII. Architecture à mémoire distribuée………………………………………………… P. 27
1) Avantages ……………………………………………………………………. P. 27
2) Inconvénients…..……………………………………………………………... P. 27
VIII. Architectures hybrides……………………………………………………………. P. 28 Table
des matières……………………………………………………………………………... P. I
II