BASES DE DONNEES

DISTRIBUEES ET REPARTIES

MM. Hodabalo AZOTI & Koffi SANI

Enseignants à l’Institut Africain d’Informatique

(IAI-TOGO)
BASES DE DONNEES DISTRIBUEES ET REPARTIES 2
CONTENU
Chapitre 1 : Besoins, objectifs, définitions (2h)
1.1 Problématique
1.2 Définitions
1.3 Buts ou avantages de la répartition des bases de données
1.4 Principes fondamentaux
1.5 Problèmes à surmonter
Chapitre 2 : conception des bases de données distribuées / répartie (2h)
2.1 Conception descendante
2.2 Conception ascendante
2.3 Architecture d’une base de données répartie
Chapitre 3 : Fragmentation
3.1 Les techniques de fragmentation
3.1.1 Fragmentation horizontale
3.1.2 Fragmentation verticale
3.1.3 Fragmentation hybride (mixte)
3.1.4 Fragmentation horizontale dérivée
3.1.5 Inconvénients et avantages des fragmentations
TD1 sur fragmentation
3.2 Définition des fragments
3.2.1 Définitions des fragments horizontaux
3.2.2 Définition des fragments verticaux
3.2.3 Schéma d’allocation
TD2 : techniques de fragmentation
Correction TD2 (2h)
Chapitre 4 : Exposé sur les bases de données mobiles (deux groupes) (4h)
1. Introduction
2. Bases de données embarquées
3. Bases de données SQLITE
4. Caractéristique SQLITE
5. Avantages et inconvénients SQLITE
6. Exemple d’utilisation
7. Conclusion
Pratique (8h)

BASES DE DONNEES DISTRIBUEES ET REPARTIES 3

 TP1 : Installation, création des bases de données, configuration de TNS et
création d’un réseau entre les 6 Pcs
TP2 : Mise en réseau des machines
TP3 : lier des bases de données pour la répartition et la distribution des BD

BASES DE DONNEES DISTRIBUEES ET REPARTIES 4

CHAPITRE 1 : BESOINS- OBJECTIFS- DEFINITIONS
1.1 Définitions
a) Base de données :

L’expression «base de données» est apparue vers 1964 pour désigner une
collection d’informations partagées par différents utilisateurs d’un système
d’informations militaire. En 1970, Edgar F. Codd apporte une contribution
substantielle à cette définition en y introduisant les concepts de l’algèbre
relationnelle donnant lieu aux «bases de données relationnelles». Il convient
d’affirmer sans équivoque, que cette notion de bases de données relationnelles a
été un apport significatif dans le domaine informatique, en permettant d’organiser
efficacement l’information de l’entreprise.

D’une manière générale, une base de données est un dépôt informatique qui
permet de sauvegarder l’information en format tabulaire conformément au
modèle de données basé sur les règles de l’algèbre relationnelle.

Parmi les avantages des bases de données dans les entreprises, on peut trouver :
− la capacité de partager des données. Ceci signifie que plusieurs utilisateurs
peuvent se servir simultanément des informations contenues dans la base
de données en accédant tous à la même information et en l’utilisant chacun
à des fins différentes.

Figure 1
− Les bases de données permettent d’éviter les redondances de données. La
redondance est une situation où les données sont répétées « inutilement ».
− On peut aussi éviter les incohérences des données. Le terme incohérence
signifie que deux ou plusieurs données dans la base de données contiennent
des valeurs différentes. D’habitude, cette incohérence est le résultat de la
mise à jour de données redondantes.

BASES DE DONNEES DISTRIBUEES ET REPARTIES 5

 − On a la structuration des données. La base de données de l’entreprise doit
à tout moment refléter la réalité le plus fidèlement possible, car cela aide à
comprendre sa structure et sa fonction. La conception de la base de données
est indispensable pour cette raison, et il est évident que la base de données
doit montrer la réalité, pas le contraire.
− La base de données permet de fournir un accès effectif aux données. La
base de données peut être parfaitement conçue et fonctionne de façon
optimale, mais le vrai potentiel des bases de données est la possibilité de
faire des requêtes qui peuvent combiner l’information de deux ou plusieurs
tables.
− Les bases de données ont l’avantage de la sécurité, c’est-à-dire, la possibilité
que l’administrateur applique des restrictions en matière de sécurité à
différents aspects de la base de données. Par exemple, il peut définir des
contrôles d’accès et des restrictions pour chaque utilisateur de l’information
de la base de données.
b) Bases de données centralisée
Une base de données centralisée est une collection d’informations à un seul endroit
à partir de nombreux points. Dans une base de données centralisée, il y a un seul
SGBD, un seul stockage physique, une seule unité de traitement. Une base de
données centralisée est gérée par un seul SGBD. Ses divers traitements sont confiés
à une seule et même unité de traitement.

Figure 2 : Bases de données centralisées

c) Bases de données distribuées :
Une base donnée distribuée est une base de données logique ou une collection
de base de données logiquement liées dont les données sont réparties sur plusieurs sites
tout en fournissant un moyen d’accès rendant la répartition transparente à l’utilisateur et
donc visible comme un tout. Lorsque les données sont dupliquées, on parle de base de
données répliquée.
Un système de gestion de base de données distribuée (SGBD Distribuée) est un système
ou application gérant une collection de bases de données (BD) logiquement reliées,
distribuées sur différents sites en fournissant un moyen d’accès rendant la distribution
transparente.
Un système de gestion de base de données distribuée (SGBDD) est une
application centrale qui administre une base de données distribuée comme si
toutes les données étaient stockées sur le même ordinateur.

BASES DE DONNEES DISTRIBUEES ET REPARTIES 6

Ce système synchronise toutes les données à des moments précis et lorsque
plusieurs utilisateurs souhaitent accéder à la même donnée, il s’assure que les
mises à jour, les modifications et suppressions opérées sur la donnée à un endroit,
sont automatiquement répliquées aux autres endroits de stockage.

Dans une base de données distribuée, il peut y avoir plusieurs SGBD, plusieurs sites
de stockage et plusieurs unités de traitement d’où la définition : une base de
données répartie est une base de données dont les différentes parties sont
stockées sur des sites distants reliés par réseau.

ou

Figure 2 : base de données distribuées

Dans les systèmes distribués, il faut faire la distinction entre une base de données
distribuée homogène et une autre qui est hétérogène.

Une base de données distribuée homogène est caractérisée par le fait que toutes
les instances ou nœuds démarrent sur un seul logiciel et partagent un seul matériel
informatique (hardware); de plus, le système peut être affiché dans une interface
unique comme s’il s’agissait d’une seule base de données.

Une base de données distribuée hétérogène peut avoir différents matériels

informatiques (hardware), systèmes d’exploitation, SGBD, et différents schémas de
base de données (la structure décrite dans un langage formel qui soutient le
modèle géré par le SGBD).

Les bases de données distribuées et réparties peuvent être confondues avec

d’autres types de bases de données comme les bases de données fédérées ou
les bases de données parallèles.

➢ Les bases de données reparties :

• Les données se trouvent sur plusieurs sites (nœuds)
• Les données sont réparties sur plusieurs sites, accessibles à partir du
site central ou de tous les sites
• Chaque site possède un certain degré d’autonomie
➢ Les bases de données fédérées :

BASES DE DONNEES DISTRIBUEES ET REPARTIES 7

 • Ensemble de bases de données intégrées (interopérer) via un modèle
commun (vue commune)
• Vue commune des données via un modèle global
• Chaque site a son schéma local, pas forcément inclus entièrement
dans le schéma global (il y a un site central)

➢ Les bases de données parallèles :

• Exploitent le parallélisme à l’intérieur d’un même site
• Peuvent utiliser plusieurs processeurs et/ou disques

1.2 Historique donnant naissance à la réplication :

A la fin des années 80 et au début des années 90, la plupart des fournisseurs de
SGBD avaient des projets voire des produits de versions distribuées de leur SGBD
et des capacités à fédérer des BD (homogènes et hétérogènes).

Les différentes expériences faites, par les utilisateurs des applications, avec ces
SGBD ont montrés leurs limites, en particulier dans un contexte de mise à jour.

Au début des années 2000, les fournisseurs ne mettent plus en avant les aspects
distribués.

Les fournisseurs ont évolués vers des solutions à base de réplication des bases de
données et des moyens d’accès à des bases de données distantes.

1.3 Problématique
La mise en place des bases de données a subit une évolution avec de nouvelles
versions de SGBD qui prennent en compte certaines contraintes comme les types
de données à accueillir. D’autres pressions en demeurent :
- augmentation du volume de l’information et des transactions
- impératif de décentralisation de l’information
Ces défis conduisent à une lenteur applicative (temps de réponde plus grand ou
pas d’accès à l’information). D’où la nécessité de serveurs de BD qui fournissent un

BASES DE DONNEES DISTRIBUEES ET REPARTIES 8

bon temps de réponse sur des gros volumes de données. Quel type d’architecture
faut-il adoptée pour répondre à ces attentes ? Quelles sont les aspects techniques
à prendre en compte pour faciliter la mise en œuvre ?
1.4 Buts de la distribution des données
Les bases de données distribuées ont une architecture plus adaptée à
l’organisation des entreprises décentralisées.
Les raisons qui président à la création des bases de données réparties sont
multiples :
• limiter le transfert d'informations
• augmenter la fiabilité : 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 à un autre site.
• augmenter la disponibilité
• faciliter l'interopérabilité
• Meilleures performances : la réduction du trafic sur le réseau, la répartition
de charge de travail entre plusieurs unités de traitement ou de stockage
permettent l’accroissement des 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.
• Faciliter l’accroissement: l’accroissement se fait par l’ajout de machines sur
le réseau.
1.5 Avantages et inconvénients de BD distribuées
• Amélioration du partage et de l’autonomie locale
• Amélioration de la disponibilité : une panne d’un SGBD dans un site ou une
rupture de ligne de communication isolant un ou quelques sites
n’immobilise pas l’ensemble du système
• Performances améliorées : Les données se trouvent près du site de la plus
grande demande/la concurrence pour les services de l’unité centrale et des
entrées sorties se trouve nettement réduite par rapport à un SGBD
centralisé
• Economie : l’ajout de stations de travail à un réseau est nettement moins
coûteux que l’extension d’un gros système centralisé
• Facilité d’accroissement (scalabilité)

Inconvénients
• Complexité : un SGBDD masque sa nature de répartition aux yeux des
utilisateurs et fournit un niveau acceptable de performance.
• Sécurité : dans un système centralisé, l’accès aux données est d’un contrôle
facile, tandis que dans un système distribué, non seulement il faut contrôler

BASES DE DONNEES DISTRIBUEES ET REPARTIES 9

 l’accès aux données dupliquées dans des emplacements multiples, mais le
réseau lui-même doit être centralisé.
• Contrôle d’intégrité de données plus difficile : l’intégrité de base de
données fait référence à la validité et la cohérence des données stockées.
• Complexité plus grande de design de base de données : le design d’une base
de données distribuée doit prendre en considération la fragmentation des
données, l’allocation des fragments à des sites spécifiques et la réplication
des données.
• Coût : la distribution entraine des coûts supplémentaires en termes de
communication, et en gestion des communications (hardware et software à
installer pour gérer des communications et la distribution)
• administration complexe
• distribution du contrôle

1.6 SGBD D Reparti

Une base de données centralisée est gérée par un seul SGBD, est stockée dans
sa totalité à 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 gérée par plusieurs processeurs, sites ou SGBD.
Un système de bases de données réparties ne doit donc en aucun cas être confondu
avec un système dans lequel les bases de données sont accessibles à distance. Il ne
doit non plus être confondu avec une multibase.
Dans une multibase, plusieurs BDs inter opèrent avec une application via un
langage commun et sans modèle commun.
Dans une BD fédérée, plusieurs BDs hétérogènes sont accédées comme une seule
via une vue commune.
Du point de vue organisationnel nous distinguons deux architectures :
1. Architecture Client-Serveur : les serveurs, ont pour rôle de réaliser une
tâche demandée par le client.

BASES DE DONNEES DISTRIBUEES ET REPARTIES 10

 2. Architecture Pair-à-Pair ou serveur-serveur (Peer-to-Peer, P2P) : par ce
terme on désigne un type de communication pour lequel toutes les machines
ont une importance équivalente.

1.7 Objectifs
Les principaux objectifs visés par une répartition des données sont :
− La transparence pour l’utilisateur
− Autonomie de chaque site
− Pas de site privilégié
− Continuité de service
− Traitement des requêtes distribuées
− Transparence vis-à-vis de :
• la localisation des donnés i.e. l’utilisateur accèdent au schéma
conceptuel via des vues ; il ne sait pas sur quel site se trouvent
physiquement les données
• la fragmentation ou partitionnement l’utilisateur ne sait pas
comment la base est partitionnée
• la réplication l’utilisateur ne sait pas s’il existe des copies des
informations, ni où elles se trouvent si elles existent
− Indépendance au niveau du
• matériel
• système d’exploitation
• réseau
• SGBD
1.8 Les problèmes à gérer
La mise place d’une base de données distribuée induit un coût, la concurrence
et la sécurité.

BASES DE DONNEES DISTRIBUEES ET REPARTIES 11

 − Coût : la distribution entraîne des coûts supplémentaires en terme 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.

BASES DE DONNEES DISTRIBUEES ET REPARTIES 12

CHAPITRE 2 : CONCEPTION- FRAGMENTATION-ALLOCATION

2.1 Méthodes de conception d’une base de données distribuées et répartie

Vu que la démarche de conception est délicate, la gestion complexe et
l’évolution du SI peut invalider la solution retenue, la mise en place d’une base de
données répartie n’est nécessaire qu’en cas de réel besoin (augmentation du
volume des données, sites distants, besoin de fusion des SI).
La définition du schéma de répartition est la partie la plus difficile de la
phase de conception d'une BDR car il n'existe pas de méthode figée pour trouver
la solution optimale. Le concepteur (souvent le DBA) doit donc prendre des
décisions en fonction de critères techniques et organisationnels, de la vision de
l’entreprise, 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...
Le rôle du concepteur est donc de définir les différents fragments de la base et,
leurs localisations ; d'évaluer les différents coûts de stockage et de transfert, et les
priorités à respecter. On distingue deux principaux types de conception : la
conception ascendante et la conception descendante.
2.1.1 Conception descendante (top down design)

Le top down consiste d'abord à définir les grandes lignes, à les diviser en
parties, puis à établir un cahier des charges pour chaque partie. Cela permet de
construire un tableau de bord, et surtout d'évaluer le coût global

Il s’agit donc de partir d’une seule base de données qu'il faut fragmenter et
allouer les fragments aux différents sites. On va donc d'un schéma global de
conception à des sous schémas locaux.

On commence alors par faire ressortie un schéma conceptuel global de la base

de données, puis on distribue sur les différents sites en fonction des schémas
conceptuels locaux.

Cette démarche s’effectue comme suit :

− Conception du schéma conceptuel global
− Distribution pour obtenir des schémas conceptuels locaux ou encore
fragmentation des tables du schéma global (processus de
fragmentation)
− Les fragments sont donc placés sur des sites (processus d’allocation)

BASES DE DONNEES DISTRIBUEES ET REPARTIES 13

 Figure : architecture de l’approche descendante
Avantage :
− Amélioration des performances de traitement (les traitements
s’effectuent au niveau du site local),
− Haute disponibilité grâce la multiplicité de copies
Inconvénient :

Cette méthode est surtout dans l'imprévisibilité du terrain : en effet, des difficultés
ou des modifications peuvent apparaître au cours de la réalisation, ce que
n'anticipe pas l'approche descendante qui se base sur une vision globale de départ.

Difficultés

− Complexité de la distribution et de la répartition (fragmentation,

duplication, placement au niveau des sites)
− Définition des schémas conceptuels locaux à partir du schéma global

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

BASES DE DONNEES DISTRIBUEES ET REPARTIES 14

 Figure : architecture approche ascendante
Cette approche nécessite une consolidation, uniformisation c'est-à-dire la
Réconciliation sémantique, identification des données semblables, accorder leurs
types, gérer leur cohérence.

Avantage :
− Amélioration des performances car les traitements sont réaliser en local
− Les utilisateurs ont un aperçu unique des données fonctionnant
(implémentées) sur plusieurs systèmes à priori hétérogènes
(plateformes et SGBD)
− Cohabitation de plusieurs systèmes (des entreprises) en permettant leur
interopérabilité
Inconvénient :

Difficultés
− Hétérogénéité sémantique (BD) et syntaxique (SGBD, connecteurs,
communications)
− Déduction d’un schéma global à partir des schémas locaux

BASES DE DONNEES DISTRIBUEES ET REPARTIES 15

 2.1.3 Architecture d’une base de données répartie

Figure : Architecture d’une base de données répartie

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.

BASES DE DONNEES DISTRIBUEES ET REPARTIES 16

Architecture de la répartition des données

a) Il existe deux grandes tâches dans la conception des bases de données

distribuées. Premièrement, il faut établir la manière dont les nœuds
communiquent entre eux. Selon l’exemple, les trois nœuds pourraient
être organisés soit d’une telle manière qu’un seul nœud opère comme
serveur et les autres comme clients, soit d’une manière où tous les
nœuds auront une importance équivalente (figure 3).

BASES DE DONNEES DISTRIBUEES ET REPARTIES 17

 Figure 3: Différents nœuds des bases de données distribuées

b) La deuxième tâche consiste à définir la manière de répartir les

données. Trois méthodes peuvent s’appliquer dans ce cas-ci : elles
peuvent être partitionnées, répliquées ou hybrides.

− Dans une base de données distribuée partitionnée, la base de données

entière est divisée en trois parties (A, B, C), où chacune des bases est stockée
dans des nœuds différents (figure 4).

Figure 4: Bases de données distribuées partitionnées.

− Dans les bases de données distribuées répliquées, la base de données entière

est répliquée dans chaque nœud. Il est évident que cette méthode réduit les
coûts de communication et augmente les performances du système en
éliminant le besoin pour la transmission de données à des nœuds différents.
Malheureusement, cette méthode est très chère à cause de la mise à jour des
données (figure 5).

Figure 5: Bases de données distribuées répliquées

BASES DE DONNEES DISTRIBUEES ET REPARTIES 18

 − Les bases de données distribuées hybrides, quant à elles, sont une
combinaison des méthodes précédentes. La base de données se divise sur
un modèle d’utilisation, c’est-à-dire, les données sont stockées dans des
nœuds où il est possible d’accéder plus fréquemment (figure 6).

Figure 6: Bases de données distribuées hybrides

Évidemment, les bases de données distribuées sont un sujet très vaste qui
nécessite plus d’un article pour être traitées en profondeur.

2.1.1 Répartition des données

2.1.2 Démarche de conception

Pour concevoir une base de données repartie, il faut commencer par les deux
étapes standards de conception des bases de données centralisées.

BASES DE DONNEES DISTRIBUEES ET REPARTIES 19

 1. Recueillir l'expression des besoins des utilisateurs et en déduire les vues
externes à prévoir.
2. Intégrer ces vues dans un schéma conceptuel global et unique

Les deux phases suivantes sont des phases critiques et délicates pour des bases de
données réparties:
3. Création du schéma de fragmentation : la base de données sera découpée en
fragments distincts constituant une partition de la base : l'intersection des
fragments doit être vide et leur réunion doit redonner le schéma global.
4. Création du schéma d'allocation : les fragments doivent être distribués "au
mieux" entre les différents sites.

Les deux dernières phases concernent les sites locaux :

5. Création d'un schéma local pour chaque site, relatif aux fragments dévolus à
ce site.
6. Création des schémas internes : implémentation des données des fragments
sur les supports physiques de stockage.

2.2 Fragmentation

2.2.1 Définition

La fragmentation désigne le découpage de la base globale en sous bases

selon les critères d'analyse.
C’est donc 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. La fragmentation peut être coûteuse s'il existe des applications qui
possèdent des besoins opposés. Le concepteur choisi entre un découpage
horizontal, vertical ou mixte.

2.2.2 Objectif de la fragmentation

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.

2.2.3 Les problèmes de la fragmentation

BASES DE DONNEES DISTRIBUEES ET REPARTIES 20

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.

2.2.4 Techniques de fragmentation

a. La fragmentation horizontale :

C'est un découpage d'une table en sous tables par utilisation de prédicats

permettant de sélectionner les lignes 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 et la reconstitution de la relation initiale se fait grâce a
l'union (U) des sous-relations. C’est une décomposition de la table en groupe de
lignes.

Exemple

Table Client (NCL, Nom, Ville)

Il existe deux types de fragmentation horizontale:

- Primaire
- Dérivée

Fragmentation horizontale primaire :

La Fragmentation horizontale est définie par l’opération de sélection

Exemple
Client (NCL, Nom, Ville) peut être fragmenté :
R1 : Client1= SELECT * FROM Client WHERE Ville = “VOGAN”
R2 : Client2= SELECT * FROM Client WHERE Ville <> “VOGAN”
Reconstruction de la relation initiale:

Client = Client1 ∪ Client2

R= R1 ∪ R2 avec R2=˥R1

Client

NCL Nom Ville

C1 AGBO KPALIME
C2 TINGA VOGAN
C3 MALEBOU SOKODE
C4 KREPIN VOGAN

BASES DE DONNEES DISTRIBUEES ET REPARTIES 21

Client1

NCL Nom Ville

C1 AGBO KPALIME
C4 KREPIN VOGAN

Client2

NCL Nom Ville

C1 AGBO KPALIME
C3 MALEBOU SOKODE

FIG. Exemple de fragmentation horizontale.

Fragmentation horizontale dérivée :

La Fragmentation d’une table en fonction des fragments horizontaux d’une autre table.
(Cette fragmentation est obtenue dans le cas de lien père_fils)

Exemple
Commande (NCL, NProduit, Date, Qte, NReprésentant)
Commande1= SELECT * FROM Commande
WHERE NCL IN
(SELECT NCL FROM CLIENT1)
Commande2= SELECT * FROM Commande
WHERE NCL IN
(SELECT NCL FROM CLIENT2)
Reconstruction de la relation initiale:
Commande = Commande1 ∪ Commande2

b. La fragmentation verticale :

Elle est le découpage d'une table en sous tables par projection permettant de
sélectionner les colonnes composant chaque fragment. La relation initiale doit
pouvoir être recomposée par la jointure des fragments.

C’est donc une décomposition de table en groupes de colonnes.

BASES DE DONNEES DISTRIBUEES ET REPARTIES 22

Exemple
Client (N°Client, Nom, Sexe,Ville) peut être fragmentée :
R1 : Client1= SELECT N°Client, Nom FROM Client
R2 : Client2= SELECT N°Client, Sexe, Ville FROM Client
Reconstruction de la relation initiale:
Client = Client1 join Client2
R=R1 ∞ R2
Client

NCL Nom Sexe Ville

C1 AGBO MASCULIN KPALIME
C2 TINGA FEMININ VOGAN
C3 MALEBOU MASCULIN SOKODE
C4 KREPIN MASCULIN VOGAN

Client1

NCL Nom
C1 AGBO
C2 TINGA
C3 MALEBOU
C4 KREPIN
Client2

NCL Sexe Ville

C1 MASCULIN KPALIME
C2 FEMININ VOGAN
C3 MASCULIN SOKODE
C4 MASCULIN VOGAN

Exemple :

BASES DE DONNEES DISTRIBUEES ET REPARTIES 23

FIG. 2.4 - Exemple de fragmentation verticale.

c. La fragmentation mixte :

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

et verticale sur une relation globale.

2.2.5 Avantages et inconvénients de la fragmentation

a) Avantages

Réduction des accès non pertinents

Parallélisme intra-requête
Combinée avec d’autres techniques d’optimisation (index, vues
matérialisées, etc.)

b) Inconvénients

BASES DE DONNEES DISTRIBUEES ET REPARTIES 24

 Génération des fragments disjoints est un problème difficile
Accès multiples aux fragments nécessitent des opérations de jointure et
d’union
La migration des données (conséquence d’une mauvaise fragmentation
horizontale)

2.1.3 Comment Fragmenter ?

a. Fragmentation horizontale
Deux catégories de méthodes de fragmentation
• Data-driven partitioning
Hash-partitioning (Oracle10g)
Range partitioning (Oracle10g)
List Partitioning (Oracle10g)
• Query-Driven Partitioning
Prédicats définis dans les requêtes

❖ Fragmentation dirigée par des requêtes

La méthode préconise d’optimiser les requêtes les plus fréquentes, avec
connaissance préalable des requêtes ainsi que les fréquences d’accès des
requêtes.
Mais un changement de requêtes peut entraîner une re-fragmentation
Procédure (Algorithme) de fragmentation
⇒ Informations sur la base de données : Avoir les prédicats simples :
Définition :
Étant donnée une relation R (A1 , A2 , ..., An )
Un prédicat simple pj défini sur R est défini:
Pj : Ai θ valeur
Avec: θ ∈ {=, <, >, =, =, ≠}; et valeur ∈ domaine(Di)
Exemple
p1: Ville = ‘’LOME ‘’
p2: Salaire = 10 000

BASES DE DONNEES DISTRIBUEES ET REPARTIES 25

Soit
Pr = {p1, p2, ..., pm} un ensemble de prédicats simples définis sur la
relation Ri,
L’ensemble de minterms M = {m1, m2, ..., mz} est défini comme suit:
M = {mi | mi = Pj Pr p*j}, 1≤i ≤ z, 1≤j≤z;
where p*j = pj or pj

Exemple:
m1 : (Ville =“Alger ”)  (Salaire ≤ 10 000)
m2 : NOT (Ville=“ Alger ”)  (Salaire ≤ 10 000)
m3 : (Ville =“ Alger ”)  NOT (Salaire ≤ 10 000)
m4 : NOT (Ville =“ Alger ”)  NOT (Salaire ≤ 10 000)

Pour appliquer cet algorithme, il faut suivre les étapes suivantes :

• Génération des minterms
• élimination des minterms contradictoires

Exemple
Considérons les prédicats simples suivants:
A<10, A>5, Loc = “Poitiers”, Loc = “Paris”
Les minterms à générer sont :
(1) A<10  A>5  Loc=SA  Loc=SB
(2) A<10  A>5  Loc=SA  ¬(Loc=SB)
(3) A<10  A>5  ¬(Loc=SA)  Loc=SB
(4) A<10  A>5  ¬(Loc=SA)  ¬(Loc=SB)
(5) A<10  ¬(A>5)  Loc=SA  Loc=SB
(6) A<10  ¬(A>5)  Loc=SA  ¬(Loc=SB)
(7) A<10 ∧ ¬(A>5) ∧ ¬(Loc=SA) ∧ Loc=SB
(8) A<10 ∧ ¬(A>5) ∧ ¬(Loc=SA) ∧ ¬(Loc=SB)
(9) ¬(A<10) ∧ A>5  Loc=SA  Loc=SB
(10) ¬(A<10)  A>5  Loc=SA ¬(Loc=SB)
(11) ¬(A<10)  A>5 ¬(Loc=SA)  Loc=SB
(12) ¬(A<10)  A>5 ¬(Loc=SA) ¬(Loc=SB)
(13) ¬(A<10) ¬(A>5)  Loc=SA  Loc=SB
(14) ¬(A<10) ¬(A>5)  Loc=SA ¬(Loc=SB)
(15) ¬(A<10) ¬(A>5) ¬(Loc=SA)  Loc=SB
(16) ¬(A<10) ¬(A>5) ¬(Loc=SA) ¬(Loc=SB)
Après éliminations des fragments contradictoires, les fragments finaux sont :

F2: 5 < A < 10  Loc=SA

F3: 5 < A < 10  Loc=SB
F6: A = 5  Loc=SA
F7: A = 5  Loc=SB

BASES DE DONNEES DISTRIBUEES ET REPARTIES 26

 F10: A = 10 ∧ Loc=SA
F11: A = 10 ∧ Loc=SB
b. Fragmentation verticale

Nous signalons que pour une relation avec m attributs (non-primary key), le
nombre de fragments verticaux possible est approximativement égal à mm
Techniques de fragmentation
• Groupement: (1) chaque attribut forme un fragment, (2) jointure des
fragments tant qu’un critère de performance est satisfait.
• Splitting: on débute par la relation globale, on génère ensuite des
partitions en se basant sur le comportement des applications (requêtes).

Principe de l’algorithme
Un fragment vertical contient des attributs fréquemment utilisés.
Les informations dont on aura besoin sont les suivantes :

• Q = {q1, q2, ..., qm}: ensemble de requêtes fréquentes

• R (A1, A2, ..., An): relation R avec n attributs, et l sites
• Matrice d’usage m×n: Uij : 1 si attribut Aj est référencé par qi sinon 0
• Matrice d’accès m × l : accik : fréquence d’accès de la requête i sur le site k
• Matrice de référence m× l : ref ik : le nombre d’accès aux attributs pour
chaque exécution de la requête qi sur le site k
Exemple

Soit la relation PROJ(PNO,PNAME,BUDGET,LOC),

Sachant qu’on a 3 sites, 4 requêtes SQL :

q1: SELECT BUDGET FROM PROJ WHERE PNO = val;
q2: SELECT PNAME, BUDGET FROM PROJ;
q3: SELECT PNAME FROM PROJ WHERE LOC = val;
q4: SELECT SUM(BUDGET) FROM PROJ WHERE LOC=val

U (colonne=qi et ligne = attribut)

BASES DE DONNEES DISTRIBUEES ET REPARTIES 27

Après avoir la matrice d’usage ainsi que la matrice d’accès, on calcule alors
Mesure d’affinité entre deux attributs Ai et Aj (affij ) d’une relation R qui est
définie comme:

affij = S{ k|Uki = 1 ∧ Ukj =1} Sl acclk

Matrice d’affinité et son rôle pour la Fragmentation verticale (FV)

• La matrice d’affinité est utilisée pour guider la génération des fragments

verticaux
• les attributs ayant une grande affinité seront groupés pour former un
fragment vertical
Remarque
On peut utiliser la théorie des graphes pour former les fragments et plus
précisément prendre les nœuds formant un cycle.

2.2.6 Les règles de la fragmentation

Un problème qui se pose pour la fragmentation est comment définir un bon

degré de fragmentation. Il existe trois règles pour la fragmentation :

1. Complétude : pour toute donnée d'une relation globale R, il existe au moins un

fragment Ri de la relation R qui possède cette donnée.

2. Reconstruction : pour toute relation R décomposée en un ensemble de

fragments Ri, il existe une opération de reconstruction à définir en fonction de la
fragmentation. Pour les fragmentations horizontales, l'opération de reconstruction
est une union. Pour les fragmentations verticales c'est la jointure.

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

BASES DE DONNEES DISTRIBUEES ET REPARTIES 28

 2.2.7 L'allocation des fragments

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. [Spa98]

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

2.3 Techniques de répartition avancées

2.3.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.3.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. Cette technique est
efficace mais exige le maintien du schéma d'allocation et des schémas locaux.

2.3.3 Fragmentation dynamique

Cette technique consiste à profiter de l'allocation dynamique des fragments,

c'est-à-dire que 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.

A l'inverse, si une partie d'un fragment est appelée sur un autre site, il peut être
intéressant de décomposer ce fragment et de ne migrer que la partie concernée.
Ces modifications du schéma de fragmentation se répercutent sur le schéma
d'allocation et sur les schémas locaux.

BASES DE DONNEES DISTRIBUEES ET REPARTIES 29

2.4 La réplication

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. [Mey05]

2.4.1 Principe

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

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

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

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

BASES DE DONNEES DISTRIBUEES ET REPARTIES 30

2.4.2 Type de réplication

2.4.2.1 Réplication asymétrique

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. [Gui04]

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. [Mey05]

FIG. 2.5 - 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. [Mey05]

BASES DE DONNEES DISTRIBUEES ET REPARTIES 31

FIG. 2.6 Réplication asymétrique asynchrone.
24

2.4.2.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. [Gui04]

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 oeuvre.
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 client à répercuter d'une mise à jour par réplication. Cette
technique nécessite l'utilisation de jeton. [Mey05]

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

BASES DE DONNEES DISTRIBUEES ET REPARTIES 32

FIG. 2.8 Réplication symétrique asynchrone.

Tableau récapitulatif des réplications

BASES DE DONNEES DISTRIBUEES ET REPARTIES 33

2.4.3 Vue matérialisée

Une vue matérialisée (VM3) 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. [Del08]

Exemple :

CREATE MATERILIZED VIEW mz-relation REFRESH COMPLET

BASES DE DONNEES DISTRIBUEES ET REPARTIES 34

ON DEMAND

AS

SELECT col1, col2 ... FROM ma-table;

2.4.3.1 Objectifs

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. [Del08]

2.4.3.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. [Wos05]

· 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,

3Vue Matérialisée/En Anglais : Materialized View

on utilise pour cela un journal (fichier Log). Ces données sont stockées jusqu'à ce
que le rafraîchissement ait été effectué. [Wos05]

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. [Wos05]

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

BASES DE DONNEES DISTRIBUEES ET REPARTIES 35

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

2.5 Gestion des données réparties

2.5.1 Mise à jour des données distantes

2.5.1.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.5.1.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' 2PC4 et garantit le tout ou rien dans
une base de données répartie. [Mey03]

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.

4Two Phases Commit

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. [BM07]

BASES DE DONNEES DISTRIBUEES ET REPARTIES 36

FIG. 2.9 - Protocole de validation à deux phases - 2PC.

2.5.2 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 :

2.5.2.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. [Mey03]

2.5.2.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. [Mey03]

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

Les bases de données réparties constituent un domaine important pour la gestion

des informations stockées sur différents sites.

Dans ce chapitre, nous avons présenté les principes de la répartition des données.
Cette répartition peut se faire selon différents scénarios choisis par le concepteur,
tout en prenant en compte les restrictions et les obligations de conception.

Nous avons vu également, comment gérer une base de données répartie avec les
principes de réplication symétrique et asymétrique.

Exemple d’une architecture d’une base de données réparti de gestion de résidence

BASES DE DONNEES DISTRIBUEES ET REPARTIES 37

Annexe
BD réparti BD fédérée
Approche descendante Approche ascendante
Un schéma global est une collection Plusieurs BD hétérogènes capable
de base de données logiquement d’interopérer via un modèle commun
reliées et réparti entre plusieurs
sites
Maîtrise de la complexité de la Maîtrise de la hétérogénéité
distribution (fragmentation, sémantique (BD) et syntaxique (SGBD,
duplication, placement) communication)

BASES DE DONNEES DISTRIBUEES ET REPARTIES 38

 Définition des schémas locaux à Intégration des schémas locaux pour
partir du schéma global créer un schéma global

Bibliographie :
− Base de Données Réparties (BDR) Master2 : Systèmes informatiques
distribués de Mme S.MECHID, Université M’hamed Bougara de Boumerdes
Département de Physique. Infotronique 2011 2012
− Base_de_donnees_distribuees-3 de « le CNAM »

BASES DE DONNEES DISTRIBUEES ET REPARTIES 39

Annexe

BASES DE DONNEES DISTRIBUEES ET REPARTIES 40

BASES DE DONNEES DISTRIBUEES ET REPARTIES 41
BASES DE DONNEES DISTRIBUEES ET REPARTIES 42