Chapitre III : BASE DE DONNEES REPARTIE

III.1 DEFINITION
Base de données repartie :
Une base de données répartie est vue comme une collection des données qui sont
réparties sur différents ordinateurs d’un réseau informatique.

Une base de données répartie est aussi vue comme une collection de bases de données
logiquement reliées, distribuées sur un réseau et apparaissant à l’utilisateur comme une
base de données unique.

Cette observation met en évidence deux aspects :

1. Distribution : Les données ne résident pas dans le même site.

2. Corrélation logique : Les données possèdent des propriétés qui les tiennent
ensemble.

Exemple de BD répartie

III.2 CARACTERISTIQUES :
 1. Une structure de contrôle hiérarchique basée sur un administrateur de base de
données global, qui a la responsabilité centrale sur la base de données répartie
entière et sur les administrateurs des bases de données locales, qui ont la
responsabilité de leurs bases de données locales respectives.
2. À l’indépendance des données est ajoutée la transparence de répartition qui
signifie que les programmes peuvent être écrits comme si les données n’étaient
pas réparties.
3. La redondance des données est une caractéristique désirable pour croître
l’autonomie des applications et la disponibilité du système (fiabilité) du système
en cas de panne.
4. Un plan d’accès réparti peut être écrit par un programmeur ou produit
automatiquement par un optimiseur.

La conception d’un optimiseur est un problème qui peut être subdivisé en deux
catégories.

a) L’optimisation globale : qui consiste à déterminer les données à mettre dans

les sites, et celles qu’il faut transmettre entre les sites.

b) L’optimisation locale : qui consiste à décider comment développer les accès

aux bases de données locales au niveau de chaque site.

5. Dans une base de données répartie, la confidentialité ou la protection des données

est assurée par les administrateurs locaux. Les problèmes de sécurité sont
intrinsèques aux systèmes répartis.
6. Un système de bases de données réparties ne doit être confondu avec un
système multibase. Dans ce dernier cas, chaque utilisateur accède à différentes
bases de données en spécifiant leur nom et adresse, et le système se comporte
alors simplement comme un serveur de BD et n'apporte aucune fonctionnalité
particulière à la répartition.

Au contraire, un système de bases de données réparties est suffisamment complet pour

décharger les utilisateurs de tous les problèmes de concurrence, fiabilité, optimisation de
requêtes ou transaction sur des données gérées par différents SGBD sur plusieurs sites.

III.3 PRINCIPES D’UNE BASE DE DONNEES REPARTIE

Le principe fondamental des BDR est la transparence pour l'utilisateur. Cette
transparence s'exprime sous trois formes :
 a) Principe de transparence de localisation : Les utilisateurs accèdent à la BD soit
directement par le schéma conceptuel soit indirectement au travers de vues
externes (Figure ci-dessus). Mais en aucun cas ils n'ont les moyens d'accéder aux
schémas locaux ni de préciser le site. C'est le système qui recherche le site où
sont mémorisées les informations de l’utilisateur et non l'utilisateur qui doit
l'indiquer.
b) Le principe de transparence de partitionnement
De même, les utilisateurs n'ont pas à connaître les partitionnements de la base de
données. Les utilisateurs ne doivent pas savoir si telle information est
fractionnée, et ne doivent donc pas se préoccuper de la réunifier.

C'est le système qui gère les partitionnements et les modifie en fonction de ses
besoins, et c'est donc lui qui doit rechercher toutes les partitions et les intégrer
en une seule information logique présentée à l'utilisateur.

c) Le principe de transparence de duplication

Enfin, les utilisateurs n'ont pas à savoir si plusieurs copies d'une même
information sont disponibles. La conséquence directe est que lors de la
modification d'une information, c'est le système qui doit se préoccuper de mettre
à jour toutes les copies.

Dans une BDR, les sites ne sont donc pas autonomes, bien que chaque site possède
une machine (serveur) avec un SGBD et une partie de la base de données, et
pourraient effectuer certains traitements localement. En effet, les utilisateurs accèdent
aux données par l'intermédiaire du schéma conceptuel global et non par l'intermédiaire
du schéma d'un site, et c'est uniquement le système qui désigne le ou les sites qui sont
concernés par la demande de l'utilisateur.

L'indépendance physique, assurée dans les bases de données traditionnelles, est donc
conservée dans les BD réparties.

III.4 NIVEAU DE REPARTITION

La répartition d'une base de donnée intervient dans les trois niveaux de son architecture,
en plus de la répartition physique des données :

1. Niveau externe : Les vues (schémas externes) sont distribuées aux utilisateurs
sur leurs sites, les sites utilisateurs.
 2. Niveau conceptuel :Le schéma conceptuel des données (schéma logique) 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.
3. 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 (en principe les
sites d'accueil des schémas logiques répartis).

Architecture de schémas d'une BDR

Tous les niveaux doivent être concernés par la répartition pour que l'on puisse parler
d'une vrai BD répartie. Sinon on n'a affaire qu'à des clients éloignés (répartition externe)
ou à un stockage physique multi machines ( répartition interne). On doit aussi
remarquer que la distribution de la base de donnée se fait plus ou moins conformément
à la répartition logique des utilisateurs et à la répartition physique des moyens
informatiques.
III.5. DIFFERENTS NIVEAUX DE TRANSPARENCE DE LA
REPARTITION

Définition :
La transparence de répartition est l’indépendance du programme d’application à la
répartition des données ; elle est équivalente, conceptuellement, à l’indépendance des
données dans les bases de données centralisées.

Il existe plusieurs niveaux de transparence de répartition :

1. Transparence globale : La transparence globale définit toutes les données qui

sont contenues dans la base de donnée répartie comme si la base de donnée n’était
pas répartie. Pour cette raison, la transparence globale peut être définie comme une
base de donnée non répartie.

Le modèle de données qui est utilisé pour la définition d’une transparence globale doit
être commode pour la définition de la présentation des autres niveaux de la base de
donnée répartie.

Si on utilise le modèle relationnel, la transparence globale consistera en la définition

d’un ensemble de relations globales.

2. Transparence de fragmentation : Chaque relation globale peut être répartie en

plusieurs portions (disjointes) appelées fragments. La fonction entre les relations
globales et les fragments est définie par la transparence de fragmentation. Cette
fonction est multivaluée, c'est-à-dire plusieurs fragments correspondent à une relation
globale, mais une seule relation globale correspond à un seul fragment.

Les fragments sont indiqués par un nom de relation globale et un indice de fragment,
par exemple : Ri indique le deuxième fragment de la relation globale R.

3. Transparence d’allocation : Les fragments sont des portions logiques des

relations globales qui sont physiquement situés dans un ou plusieurs sites du réseau.

La transparence d’allocation définit dans quel(s) site(s) est situé un fragment. Le type
de relation défini dans la transparence d’allocation définit si la base de donnée répartie est
redondante ou non.

Tous les fragments qui correspondent à la même relation globale et qui sont situés
dans le même site j constituent l’image physique de la relation globale R dans le site
j. Les images physiques peuvent être indiquées par un nom de relation et un indice de
site.
Pour les distinguer des fragments, nous utilisons la notation Rj qui indique l’image
physique de la relation globale R dans le site.

Le schéma ci-après représente les fragments et les images physiques pour une relation
globale.

Les fragments et les images physiques pour une relation globale

Dans ce schéma, une relation R est divisée en 4 fragments R1, R2, R3, R4.

Ces fragments sont dupliqués dans les 3 sites d’un réseau informatique. Ainsi sont
construites les images physiques R1, R2, R3.

Une copie d’un fragment dans le site donné sera noté en utilisant le nom d’une
relation globale et 2 indices (Un indice de fragment et un indice de site).
Par exemple la notation R32 indique la copie d’un fragment R2 situé dans le site 3. Deux
images physiques peuvent être identiques. Dans ces conditions, on dira qu’une image
physique est une copie d’une autre image physique. R1 est une copie de R2.

NB : Les trois niveaux ci-dessus sont indépendants des sites. Donc ils ne dépendent pas
des modèles de données des SGBD locaux.

4. Transparence conceptuelle locale :

A ce niveau il est nécessaire qu’il y ait une fonction qui associe chaque image
physique aux objets qui sont manipulés par les SGBD locaux.

Cette transparence dépend du type de SGBD local.

Les caractéristiques de cette architecture sont :

- La séparation des fragmentations et d’allocation des données.

- Le contrôle de la redondance et l’indépendance vis-à-vis des SGBD locaux.

III.6 INCONVENIENTS DES BASES DE DONNEES

REPARTIES
1. Complexité :
Un SGBD distribué qui masque sa nature répartie aux yeux des utilisateurs et fournit
un niveau acceptable de performances, de fiabilité et de disponibilité est à priori plus
complexe qu’un SGBD centralisé. La réplication des données ajoute également de la
complexité au SGBD distribué.

Si les logiciels ne gèrent pas correctement la réplication des données, ils engendrent
une dégradation de la disponibilité, de la fiabilité et des performances par rapport au
système centralisé, et les avantages cités plus haut deviennent des inconvénients.

2. Coût :
L’augmentation de complexité a un coût dont nous pouvons prévoir qu’il sera supérieur
en termes d’acquisition et de maintenance, au niveau SGBD, par rapport à un SGBD
centralisé. En outre, un SGBD distribué nécessite du matériel supplémentaire pour
établir les communications nécessaires sur un réseau entre sites.

Les communications entre sites présentent également un coût non négligeable, qui croît
en fonction de l’utilisation. Enfin, des coûts de main d’œuvre supplémentaire sont
induits, du fait de l’administration et de la maintenance des différents SGBD locaux et
du réseau sous-jacent.
 3. 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 l’accès aux données
dupliquées dans des emplacements multiples, mais le réseau lui-même doit être sécurisé.

Il n’y a guère, les réseaux étaient considérés comme un moyen de communication

insécurisé. Même si cela est encore partiellement vrai, des développements majeurs ont
été menés à bien et font que les réseaux ont acquis un peu plus de sécurité.

4. Manque de normes :
Bien que les SGBD distribués dépendent de télécommunications efficaces, nous
commençons seulement à voir apparaître des communications normalisées et des
protocoles d’accès aux données.

Ce manque de standards a remarquablement limité le potentiel des SGBD distribués. Il

n’existe en outre aucun outil ni méthodologie qui permettent aux utilisateurs de
convertir un SGBD centralisé en un SGBD distribué.

5. Complexité plus grande du design de bases de données :

En plus des difficultés habituelles de la conception d’une base de données centralisée,

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.

III.7 DIFFERENTS CONCEPTS

III.7.1 Bases de données distribuées :
Le terme base de données distribuées est un terme générique qui englobe les BD
réparties, les BD fédérées, systèmes multi bases de données et les BD parallèles.

Une base de données répartie n’implique pas forcément une parfaite homogénéité des
sites locaux. Dans la pratique, la mise en place d’une base de donnée répartie, par une
conception ascendante, impose de tenir compte des différents systèmes existants.

1. Hétérogénéité des nœuds :

Si les différents nœuds sont utilisés avec des systèmes d’exploitations différents, cela
apporte que très peu de problèmes au concepteur du système distribué. Cette
hétérogénéité est englobée dans un paramétrage correct du médiateur qui supporte
même différents protocoles de communication sur un même réseau (TCP/IP, DecNet, …).

2. Hétérogénéité des SGBD :

La normalisation du langage SQL facilite l’intégration de bases de données traitées par

différents constructeurs. La traduction des différents dialectes et la connexion
« technique » sont assurés par une passerelle dédiée. Plusieurs constructeurs proposent
des facilités de connections, mais il est plus rare de disposer d’outils qui intègre
l’hétérogénéité des méta données. Par Voie de conséquence, le SGBDR est également
hétérogène puisqu’il est constitué de SGBD de types différents.

3. Hétérogénéité de structures :

Le problème majeur et difficilement maîtrisable réside dans des différences de structure,

différents paradigme de gestion de données (relationnel, objet, hiérarchique, réseau).

Le terme base de données répartie homogène désigne généralement une base de donnée
répartie gérée par des SGBD identiques localisés sur des sites.

Lorsque les bases de données qui composent la base de données répartie reposent sur
des modèles de données différents (hiérarchique, réseau, relationnel, orienté objet), on
parle de base de donnée répartie hétérogène.

Le degré d’hétérogénéité d’une base de donnée répartie peut donc varier, selon que les
SGBD serveurs sont différents mais basés sur le même modèle ou basé sur des modèles
différents.

Les bases de données réparties hétérogènes sont un sujet d’étude intéressant, aussi bien
du point de vue des concepts que du point de vue des applications, particulièrement
afin de faire coopérer des bases données existantes. Le degré d’intégration des bases de
données locales participant à une base de donnée répartie hétérogène permet de
distinguer les multi base des bases fédérées.

III.7.1.1 Système multi bases de données

Plusieurs bases de données hétérogènes capables d’interopérer avec une application via
un langage commun, sans une vue commune (absence de modèle commun).

Dans ce cas, chaque utilisateur accède à différentes bases de données en spécifiant leur
nom et adresse, et le système se comporte alors simplement comme un serveur de BD
et n'apporte aucune fonctionnalité particulière à la répartition.
III.7.1.2 Base de données fédérées
Plusieurs bases de données hétérogènes accédées comme une seule via une vue
commune (un modèle commun).

Fédération :

Donner aux utilisateurs une vue unique des données implémentées sur plusieurs systèmes
a priori hétérogènes c'est-à-dire des plates-formes, des SGBD et des modèles de
données différents (hiérarchique, réseau, relationnel, orienté objet).

Cas typique rencontré lors de la concentration d’entreprises : faire cohabiter les

différents systèmes tout en leur permettant d’inter opérer.

III.7.1.3 Base de données parallèle

SGBD parallèle :
Un SGBD fonctionnant sur plusieurs processeurs et plusieurs disques, conçu pour
exécuter des opérations autant en parallèle que possible, de façon à améliorer les
performances.

Les SGBD parallèles partent du principe que les systèmes à un seul processeur ne
permettent plus de prendre en charge les exigences croissantes d’évolution économique,
de fiabilité et de performances. Une alternative puissante, et avantageuse d’un point de
vue financier, au SGBD monoprocesseur se présente sous la forme du SGBD parallèle géré
par plusieurs processeurs.

Les SGBD parallèles associent plusieurs machines plus modestes pour atteindre le
même débit qu’une seule machine plus ambitieuse, offrant en outre une meilleure
évolutivité et une meilleure fiabilité que les SGBD monoprocesseurs.

III.8. SYSTEME DE GESTION DE BASE DE DONNEES

REPARTIE (SGBDR)
III.8.1 DEFINITIONS
Un système de gestion des bases de données réparties est un ensemble de logiciels qui
gère des collections de bases de données logiquement reliées, distribuées sur un réseau
(bases de données réparties), en fournissant un mécanisme d’accès qui rend la
répartition transparente aux utilisateurs. Il cache aux applications l’existence de multiples
bases.

1. Client de SGBDR :
C’est une application qui accède aux informations distribuées par des interfaces du
SGBDR.

2. Serveur SGBDR :

SGBD gérant une base de données locale intégrée dans une base de donnée répartie.

3. Nœud ou site de SGBDR :

Calculateur dans un réseau participant à la gestion d’une base de données répartie.

Un SGBDR repose sur un système informatique réparti qui est constitué d’un ensemble
de processeurs autonomes appelés sites reliés par un réseau de communication qui lui
permet d’échanger des données. Un SGBDR suppose en plus que les données soient
stockées sur deux processeurs au moins, ceux-ci étant dotés de leur SGBD propre.

Extérieurement, le SGBD réparti doit offrir les mêmes services qu’un SGBD
monolithique, mais nous attendons d’un SGBDD qu’il apporte en plus les fonctionnalités
suivantes :

 Des services de communication étendus qui donnent accès à des sites distants et
permettent de transférer des requêtes et des données parmi les sites, par le biais
d’un réseau.
 Un catalogue système étendu qui emmagasine les détails de distribution et de
répartition (Dictionnaire des données réparties)
 Un traitement de requête distribuée, incluant l’optimisation des requêtes et l’accès
distant aux données.
 Un contrôle de sécurité étendu qui associe les autorisations et privilèges d’accès
aux données distribuées. Un contrôle de concurrence (simultanéité) étendu qui
conserve la cohérence des données distribuées et, éventuellement, répliquées.
 Des services de récupération étendus qui tiennent compte des défaillances des
sites individuels et des pannes des liaisons de communication
 Un ensemble de schémas externes globaux;
 Un schéma conceptuel global;
 Un schéma de fragmentation et un schéma d’attribution (ou d’« allocation »);
 Un ensemble de schémas pour chaque SGBD local qui se conforme à
l’architecture ANSI-SPARC à trois niveaux.

III.8.2 ORGANISATION DES SCHEMAS

1. Schéma conceptuel global :

Le schéma conceptuel global est la description logique de la base de données dans sa

totalité, comme si elle n’était pas distribuée. Ce niveau correspond en fait au niveau
conceptuel de l’architecture ANSI SPARC et renferme la définition des entités, des
associations, des contraintes, ainsi que les informations de sécurité et d’intégrité. Il
fournit l’indépendance physique des données par rapport à l’environnement distribué.
Les schémas externes globaux assurent l’indépendance logique des données.

2. Schémas de fragmentation et d’allocation :

Le schéma de fragmentation est une description de la manière logique dont les données
se partitionnent, tandis que le schéma d’allocation décrit les emplacements où se situent
les données, en tenant compte de la réplication, quelle qu’elle soit.

3. Schémas locaux :

Chaque SGBD local possède son propre ensemble de schémas. Les schémas conceptuel
local et interne local correspondent aux niveaux équivalents de l’architecture ANSI-
SPARC.

Le schéma de correspondance local fait correspondre les fragments du schéma

d’allocation aux objets externes de la base de données locale. Il ne dépend pas du
SGBD et constitue la base de compatibilité vis-à-vis des SGBD hétérogènes.

III.8.3 ARCHITECTURE DES COMPOSANTS D’UN SGBDR

Nous pouvons identifier une architecture de composants d’un SGBDR constituée de
quatre composants principaux

 Un SGBD local (SGBDL);

 Un composant de communications de données (CD);
  Un catalogue système global (CSG);
 Un composant de SGBD Distribué (SGBDD).

1. Composants du SGBD local :

Le composant SGBDL est un SGBD standard, responsable du contrôle des données

locales à chacun des sites qui possèdent une base de données. Il possède son propre
catalogue système local renfermant des informations sur les données emmagasinées dans
le site.

Dans un système homogène, le composant SGBDL est le même produit recopié dans
tous les sites. Dans un système hétérogène, au moins deux sites hébergent des produits
de SGBD et (ou) plates-formes différents.

2. Composant de communications de données :

Le composant CD est le logiciel qui permet à tous les sites de communiquer les uns
avec les autres. Il renferme des informations sur les sites, ainsi que les liaisons. Le
niveau communication est en fait un médiateur.

3. Catalogue système global (CSG) :

Le CSG possède les mêmes fonctionnalités que le catalogue système d’un système
centralisé. Il détient des informations spécifiques à la nature répartie du système,
comme les schémas de fragmentation, de réplication et d’allocation.

Il est éventuellement géré lui-même comme une base de données distribuée et, de ce
fait, peut être à son tour fragmenté et distribué. Il emmagasine les détails de distribution
et de répartition.

4. Composant SGBDD distribué :

Le composant SGBDD est l’unité de contrôle de tout le système. Ce composant permet

de formuler des requêtes mettant en jeu des vues intégrées de la base ; il assure la
décomposition des requêtes en sous requêtes ; il réalise l’intégration des différents
systèmes déjà uniformisés par le niveau local. C’est ce composant qui assure toutes les
quatre principaux types de transparence dans un SGBDR :

1. La transparence de distribution;

2. La transparence de transaction;

3. La transparence de performances;

4. La transparence de SGBD.
4.1 Transparence de distribution

La transparence de distribution permet à l’utilisateur de ne percevoir une base de

données que comme une seule entité logique. Lorsqu’un SGBDR expose une
transparence de distribution, l’utilisateur aucune conscience d’une éventuelle
fragmentation des données (transparence de fragmentation) ni de la localisation des
données (transparence de localisation).

a) Transparence de fragmentation

La fragmentation est le plus haut niveau de transparence de distribution. Si le SGBDD

assure la transparence de distribution, alors l’utilisateur n’est pas censé savoir que les
données sont fragmentées. Ceci implique que les accès à la base de données se fondent
sur le schéma global, de sorte que l’utilisateur ne spécifie pas de nom de fragment ni
d’emplacement des données.

b) Transparence de localisation

L’utilisateur ne doit pas tenir compte l’emplacement des données. C'est le système qui
recherche le site où sont mémorisées les informations de l’utilisateur et non l'utilisateur
qui doit l'indiquer.

c) Transparence de réplication

La transparence de réplication s’apparente fort à la transparence de localisation, en ce sens

que l’utilisateur n’est à priori pas conscient de la réplication des fragments.

4.2 Transparence de transaction

La transparence de transaction dans un environnement de SGBDD garantit que toutes

les transactions distribuées maintiennent l’intégrité et la cohérence de la base de
données distribuée. Une transaction distribuée accède aux données stockées dans plus
d’un emplacement physique.

a) Transparence de concurrence

La transparence de concurrence est assurée par le SGBDR si les résultats de toutes les
transactions concurrentes (distribuées ou non) se produisent indépendamment et sont
logiquement cohérents avec les résultats qui auraient été obtenus si les transactions
avaient été exécutées une à la fois, dans un ordre sériel, quel qu’il soit. Le SGBDD
doit assurer la cohérence de toutes les sous-transactions d’une même transaction globale.

b) Transparence de défaillance

Nous devons tenir compte dans un environnement distribué, de :

 La perte d’un message;

  La panne d’une liaison de communication;
 La panne d’un site;
 Le partitionnement du réseau.

4.3 Transparence de performances

La transparence de performances requiert d’un SGBDD qu’il se comporte comme si

c’était un SGBD centralisé.

Dans un environnement distribué, le système risque de souffrir de n’importe quelle

dégradation de performances due à l’architecture distribuée, notamment au niveau du
réseau. La transparence de performances exige aussi du SGBDD qu’il détermine la
stratégie la plus efficace en terme de coût d’exécution d’une requête.

Il subit la charge de prendre en compte les schémas de fragmentation, de réplication et

d’allocation. Le processeur de requêtes distribuées doit décider :

 Du fragment auquel il doit accéder;

 De la copie d’un fragment à utiliser, si le fragment est dupliqué;
 De l’emplacement à employer.

Le processeur de requêtes distribuées génère une stratégie d’exécution optimisée en

respect d’une certaine fonction de coût. D’une façon type, les coûts associés à une requête
distribuée sont :

 Le coût du temps d’accès (entrées-sorties) lors de l’accès physique aux données

sur disque;
 Le coût du temps d’unité centrale (UC) induit lors des opérations sur les
données en mémoire principale;
 Le coût des communications associées à la transmission des données via le réseau.

4.4 Transparence du SGBD

La transparence du SGBD évite la connaissance des éventuelles particularités du SGBD

et ne s’applique qu’aux SGBDR hétérogènes. C’est l’une des transparences les plus
difficiles à assurer en toute généralité.

III.8.4 CONCEPTION DES BASES DE DONNEES REPARTIES

La Conception d’une base de données centralisée peut se résumer de la manière

suivante :
 a) Concevoir le schéma conceptuel qui décrit la base de donnée intégrée, c'est-à-
dire toutes les données qui seront utilisées par les applications de la base de
donnée.
b) Concevoir la base de données physique ; c'est-à-dire le passage du schéma
conceptuel aux environnements de stockage et spécifier les méthodes d’accès
appropriées.

Dans une base de donnée répartie, ces deux problèmes deviennent la conception du
schéma global et la conception des bases de données physiques locales dans chaque
site.

On peut également ajouter 2 aspects qui caractérisent entièrement la conception des

répartitions des données.

c) Concevoir la fragmentation, c'est-à-dire spécifier comment les relations globales

sont subdivisées en fragments horizontaux, verticaux ou mixtes.
d) Concevoir l’allocation des fragments, c'est-à-dire spécifier comment les fragments
sont liés aux images physiques ; de cette manière la duplication des fragments
est aussi spécifiée.

Il convient de bien distinguer ces deux derniers problèmes :

 Le premier traite du « critère logique » qui motive la fragmentation d’une relation

globale
 Le second traite de l’emplacement physique des données dans divers sites.

Conception ascendante et conception descendante

a) Conception descendante

Cette conception est utilisée lors de la constitution de nouvelles bases de données

réparties. La démarche consiste à partir du schéma global, de construire des schémas
locaux, c'est-à-dire qu’un schéma conceptuel global est tout d’abord élaboré, puis les
diverses entités de ce schéma sont distribuées sur les sites, ce qui conduit à, la
définition des schémas locaux. Ces différentes entités du schéma conceptuel global
distribuées sur les différents sites sont appelées les fragments.
 Conception descendante d’une base de donnée répartie

b) Conception ascendante

La conception ascendante permet l'intégration de bases de données locales existantes

dans une base distribuée. Il s'agit cette fois de construire un schéma global à partir de
schéma locaux, généralement existants.

Cette démarche est la plus difficile puisqu'en plus des problèmes techniques identiques
à ceux inhérent à une conception descendante, il faudra résoudre des problèmes
d'hétérogénéité des systèmes ou même sémantiques de l'information. Cette approche
nécessite plus souvent une réconciliation sémantique des schémas participants.

Conception ascendante d’une base de donnée répartie

III.8.5 TECHNIQUES DE FRAGMENTATION
1. Définition :
La fragmentation est le processus de décomposition d'une base de donnée logique (telle
que la voient les utilisateurs) en un ensemble de "sous" bases de données appelées
fragments. Cette décomposition doit évidemment être sans perte d'information pour être
acceptable.

Une fragmentation est sans perte d'information si la base de donnée logique peut être
entièrement recomposée à partir de ses fragments. Cette recomposition est exprimée en
utilisant les instructions du langage de manipulation de données associé au modèle de
données utilisé (par exemple l'algèbre ou SQL pour une BD relationnelle).

De plus, les différents fragments doivent de préférence être exclusifs (leur intersection
est vide) puisqu'une fragmentation non exclusive implique une duplication. Dans ce cas
il faut affiner la fragmentation en produisant des fragments plus petits.

Les règles à suivre pour déterminer les fragments

a) La complétude :

Toutes les données de la relation globale doivent être reprises dans les fragments.
C'est-à-dire pour toute donnée d'une relation R, il existe au moins un fragment Ri de la
relation R qui possède cette donnée.

b) La reconstruction :

Il faut une possibilité de reconstruire chaque relation globale à partir de ses fragments.
Tous les fragments qui correspondent à la même relation globale R, et qui sont situés
dans le même site j constituent l’image physique de la relation globale R dans le site j.

c) La disjonction :

La disjonction permet de contrôler la redondance au niveau de l’allocation. Il est

souhaitable d’avoir des fragments disjoints.

Une donnée n'est présente que dans un seul fragment.

2. Schéma de fragmentation

Le schéma conceptuel doit être décomposé en un ensemble de fragments, qui constituent

le schéma de partitionnement.

Le principe est de baser la fragmentation sur l'ensemble des requêtes d'interrogation ou

de mise à jour prédéfinies (celles que l'on prévoit déjà lors de la définition de la base
de données). Il faut extraire de ces requêtes toutes les conditions de sélections, les
attributs projetés et les jointures (naturelles ou non).

Les opérations de sélection sont à la base des fragmentations horizontales, les

opérations de projection sont à la base des fragmentations verticales. Chaque fragment
final peut être concerné par aucune, une seule ou plusieurs de ces requêtes prédéfinies.

Pour éviter le risque d'émietter la base de données, on peut restreindre le nombre de

requêtes prises en considération. On ne s'intéresse alors qu'aux requêtes les plus
importantes, c'est à dire les plus courantes (régulièrement appelées) ou les plus
sensibles (celles pour lesquelles le temps de réponse maximum est borné).

a) La fragmentation horizontale

La fragmentation horizontale consiste à partitionner les tuples (lignes) d’une relation

globale en des sous ensembles ( sous schéma). C’est important en base de données répartie
où chaque sous ensemble peut contenir les données ayant les mêmes propriétés.

Chaque fragment est défini comme une opération de sélection sur une relation globale.
La relation initiale sera obtenue par union des fragments.

 L'opérateur de partitionnement est la sélection

 L'opérateur de recomposition est l'union

Client
Numéro Nom Localité
1 Marc I Lubumbashi
2 Antoine Lubumbashi
3 Paguy Kinshasa
4 Alain Kinshasa
NB : On fragmente horizontalement par rapport à la Localité

Client 1
Numéro Nom Localité
1 Marc I Lubumbashi
2 Antoine Lubumbashi

Client 2
Numéro Nom Localité
3 Paguy Kinshasa
4 Alain Kinshasa
b) La fragmentation verticale

La fragmentation verticale d’une relation globale est la subdivision de ses attributs

(colonnes) en groupes. Les fragments sont obtenus par projection de la relation globale
sur chaque groupe. C’est important en base de données répartie car chaque groupe
d’attributs peut contenir les données ayant des propriétés communes.
  L'opérateur de partitionnement est la projection
 L'opérateur de recomposition est la jointure

Commande
no_cmde client produit qté
1 1 54 10
2 1 62 12
3 2 64 25
4 45 18 51

Commande 1
no_cmde produit
1 54
2 62
3 64
4 18

Commande 2
no_cmde qté
1 10
2 12
3 25
4 51

c) La fragmentation mixte

La fragmentation mixte résulte de l’application successive de fragmentation horizontale

et de la fragmentation verticale sur une relation globale. La recomposition de la
relation initiale se fait par une succession inverse d’unions (recomposition des fragments
horizontaux) et de jointures (recomposition des fragments verticaux.

3. Allocation des fragments

Suite à la fragmentation des données, il est nécessaire de les placer sur les différentes
machines. C’est l'allocation.

3.1 Schéma d'allocation

L'affectation des fragments sur les sites est décidée en fonction de l'origine prévue des
requêtes qui ont servi à la fragmentation. Le but est de placer les fragments sur les sites
où ils sont le plus utilisés, pour minimiser les transferts de données entre les sites.

Là encore, si on désire éviter une allocation trop complexe, on peut se restreindre à ne

prendre en considération pour chaque requête que les origines les plus importantes (les
sites qui émettent régulièrement cette requête ou ceux dont le résultat doit leur être
fourni très rapidement).

Pour chaque requête, on connaît l'ensemble des sites qui sont susceptible d'émettre cette
requête, et on possède l'ensemble des fragments qui sont concernés par la requête. On
associe donc à chaque fragment l'ensemble des sites qui peuvent "réclamer" ce fragment.

L'allocation consiste simplement à choisir pour chaque fragment le site de réception le

plus adéquat. Lorsque plusieurs fragments complémentaires d'une même relation se
retrouvent sur le même site, ces fragments peuvent être réunifiés pour simplifier les
schémas de fragmentation et d'allocation.

Le schéma d'allocation conserve l'assignation des fragments sur les sites, tandis que le
schéma local de chaque site définit la partie de la base de données (l'image physique
des fragments) qui est stockée sur ce site.

IL existe des critères généraux qui peuvent être utilisés pour allouer des fragments.

Il est important de distinguer si la conception de l’allocation finale est redondante ou nom.

a) Allocation finale redondante

Premièrement, il est possible de répliquer totalement les données. Déterminer l’ensemble

de tous les sites où le profit d’allouer une copie du fragment est plus élevé, et allouer
une copie du fragment à chaque élément de cet ensemble Cette stratégie possède
l'avantage de rendre fiable l'accès aux données. En effet les données sont sur plusieurs
sites, et un site peut donc tomber en panne sans entraîner une impossibilité de
travailler.

Cette méthode est surtout efficace lorsque les requêtes sont principalement en lecture
seule (read only). Les problèmes sont importants lors des mises à jour, lorsque le
système doit s'assurer d'écrire de façon cohérente les données, sur tous les sites.

Il faut donc éviter de répliquer les données qui sont trop souvent mises à jour.

b) Allocation finale non redondante

Une deuxième stratégie est donc de ne pas répliquer les données du tout. C'est une
stratégie qui peut être payante dans le cas de mises à jour très nombreuses. Cette
stratégie est évidemment moins fiable que la précédente (si un site tombe, l'ensemble
peut être bloqué).

Une troisième stratégie combine les deux autres. Dans une base de données, certaines
données sont statiques et gagneraient à être répliquées, alors que d'autres sont
généralement écrites et il vaudrait donc mieux ne pas les répliquer. C'est pourquoi une
stratégie de compromis peut être payante.
 c) Allocation dynamique

Avec cette technique, l'allocation d'un fragment peut changer en cours d'utilisation de la
BDR. Ce peut être le cas suite à une requête par exemple.

Dans ce cas, le schéma d'allocation et les schémas locaux doivent être tenus à jour.
Cette technique est une alternative à la duplication qui se révèle plus efficace lorsque la
base de données est sujette à de nombreuses mises à jour.

d) Fragmentation dynamique

Dans le cas où le site d'allocation peut changer dynamiquement, il est possible que
deux fragments complémentaires (verticalement ou horizontalement) se retrouvent sur le
même site. Il est alors normal de les fusionner.

A l'inverse, si une partie d'un fragment est appelé sur un autre site, il peut être
intéressant de décomposer ce fragment et de ne faire 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.

e) Clichés

Un cliché (snapshot) est une copie figée d'un fragment. Il représente l'état du fragment
à un instant donné et n'est jamais mis à jour contrairement aux vues et aux copies qui
répercutent toutes les modifications qui ont lieu sur le fragment original.

L'intérêt (la pertinence) d'un cliché diminue donc au fur et à mesure que le temps passe.
L'utilisation de clichés est intéressante lorsque l'on juge que la gestion de copies
multiples se révélerait trop lourde pour la base de données considérée alors que des
copies même un peu anciennes et non à jours seraient largement suffisantes.

On peut en effet se passer de l'information exacte pour diverses raisons. D'une part
l'information contenue dans la base de données peut ne pas refléter tout à fait la réalité
(cas d'un changement d'adresse non signalé, par exemple). D'autre part, certaines
informations ne subissent pas souvent de modification (comme le nom de famille,
l'adresse ou le nombre d'enfants des employés) et par conséquent une copie même
ancienne de ces informations est, dans sa grande majorité, encore exacte.

Enfin, certaines informations dans un certain contexte ne sont pas de caractère sensible
et par conséquent une information erronée n'aura pas de répercussion grave : le
changement d'adresse d'un employé non répercuté n'aura pas d'incidence, les services
postaux se chargeant du bon acheminement du courrier pendant plusieurs semaines.

A l'inverse, le même changement d'adresse, non répercuté par la Poste (PTT), pourrait
avoir des conséquences graves.
Les deux critères qui sont à prendre en compte pour définir l'intérêt d'un cliché sont
d'une part l'ancienneté du cliché, et d'autre part le temps d'attente qui serait nécessaire
avant d'obtenir l'information originale (à jour). Ces deux informations, l'ancienneté et le
temps d'attente, peuvent être pondérées par un taux de satisfaction pour le système
d'information.

III.9. TRANSACTIONS DANS LES BASES DE DONNEES

REPARTIES
1. Définition des transactions

Une transaction est un traitement cohérent et fiable. Dans le cas des bases de données,
c'est une action qui transforme la base de données d'un état stable cohérent en un autre état
stable cohérent.

En cas d'interruption pour une raison quelconque, la transaction garantit de laisser la

base de données dans l'état dans lequel elle l'avait trouvée. Une transaction a quatre
types d'opérations : un début de transaction, la lecture, l'écriture, et enfin la terminaison.

2. Condition de terminaison

Une transaction n'échoue pas, elle est interrompue pour diverses raisons, ou arrive à
son terme prévu. Pour assurer la cohérence de la base de données, en cas d'interruption
de la transaction (si elle est interne le mécanisme d'interruption se nomme abort), un
mécanisme se charge de défaire toutes les actions qui ont déjà été effectuées, c'est le
rollback.

Si la transaction n'est pas interrompue, elle se finit correctement et la base de données

peut prendre en compte les changements. On appelle généralement ce signal que donne
la transaction : commit ou validation.

3. Formalisation du concept de la transaction

Même si le concept est intuitivement clair, il peut être utile de le préciser de façon plus
formelle.

 Une transaction est un ensemble d'opérations menées sur une base de données.
 Ces opérations peuvent être la lecture ou l'écriture.
 Une opération est atomique, elle est donc une unité indivisible.
 Une transaction se termine soit par un commit, soit par un abort
 Deux opérations distinctes peuvent s'exécuter en mène temps. Une opération de
lecture et d'écriture doivent s'exécuter l'une après l'autre.
 La dernière opération effectuée est la terminaison.

4. ACID, les propriétés d'une transaction

La cohérence et la fiabilité d'une transaction sont garanties par quatre propriétés :
l'Atomicité, la Cohérence, l'Isolation, la Durabilité qui font l'ACIDité d'une transaction.

4.1 Atomicité

Cette propriété signifie qu'une transaction est traitée comme une seule opération.

Toutes les actions d'une transaction sont donc menées à bien ou aucune d'entre elles.
C'est le tout ou rien. Après un problème, le SGBD doit soit terminer la transaction
commencée, soit défaire tout ce qui a été entrepris. On peut rencontrer deux types de
problèmes durant l'exécution de la transaction :

 la transaction peut s'interrompre d'elle-même. Par exemple, dans le cas où

l'écriture dépend d'une condition sur une lecture, non remplie, la transaction est
annulée de façon interne. On parle de abort. Le SGBD peut également lui-même
décider d'interrompre la transaction en cours (dans le cas d'un inter-blocage par
exemple). On parle alors de reprise de transaction (transaction recovery).
 La transaction peut également être interrompue en raison d'une panne du système
ou du réseau. On parle dans ce cas de reprise de crash.

4.2 Cohérence

La cohérence d'une transaction est simplement sa correction. En d'autres termes, une

transaction est un programme correct qui amène la base de données d'un état cohérent
à un autre état cohérent. En cas d’échec, l’état cohérent initial doit être restauré.

La vérification de la cohérence des transactions est le rôle du contrôleur de sémantique.

Assurer la cohérence des transactions est l'objectif des mécanismes de contrôle de la
concurrence.

4.3 Isolation

L'isolation est la propriété qui impose à chaque transaction de voir une base de
données cohérente à tout moment. Une transaction en train de s'exécuter ne peut donc
révéler ses résultats à d'autres transactions concurrentes (simultanées) avant d'avoir
effectué son commit.

Autrement dit, les résultats d’une transaction ne doivent être visibles aux transactions
qu’une fois la transaction validée, ceci afin d’éviter les interférence avec les autres
transactions.

4.4 Durabilité

La durabilité est la propriété qui garantit lorsqu'une transaction a effectué son commit,
le résultat sera permanent et ne pourra pas être effacé de la base de données quelques
soient les pannes du système rencontrées.

5. Classification des transactions

 1) La requête distante;
2) L’unité de travail distante;
3) L’unité de travail distribuée;
4) La requête distribuée.

Dans ce contexte, la requête est équivalente à une instruction SQL et l’unité de travail
correspond à une transaction, telle que nous la connaissons

5.1 La requête distante

Une application sur un site envoie une requête sous la forme d’une instruction

SQL à un site distant pour qu’elle s’y exécute. La requête est totalement exécutée sur le
site distant et a tout le loisir de faire référence aux données situées sur ce seul site.

5.2 L’unité de travail distante

Une application sur un site (local) envoie toutes ses instructions SQL sous forme d’une
unité de travail (une transaction) à un site distant pour qu’elles s’y exécutent. Toutes
les instructions SQL sont entièrement exécutées sur le site distant et ne peuvent faire
référence à des données que situées dans ce site. C’est toutefois le site local qui
décide si la transaction doit être validée ou annulée.

5.3 L’unité de travail distribuée

Une application sur un site (local) envoie certaines ou toutes les instructions SQL
d’une transaction à un ou plusieurs sites distants en vue de leur exécution sur ceux-ci.

Chaque instruction SQL s’exécute en totalité sur le site distant et ne peut faire
référence à des données que de ce seul site. Cependant, des instructions SQL
différentes peuvent s’exécuter sur des sites distincts. Ici aussi, le site local décide de la
validation ou de l’annulation de la transaction.

5.4 La requête distribuée.

Une application à un site (local) envoie une partie ou toutes les instructions SQL d’une
transaction à un ou plusieurs sites distants en vue de leur exécution. Ici, une
instruction SQL peut éventuellement accéder à des données de plus d’un site (par
exemple, l’instruction demande de joindre ou d’unir des relations et (ou) fragments
situés dans des sites différents).

6. Validation en deux phases

6.1 Principe

Le principe consiste à diviser la validation en deux phases. La phase 1 réalise la

préparation de l’écriture des résultas des mises à jour dans la base de données et la
centralisation du contrôle.
La phase 2, réalisée seulement en cas de succès de la phase 1, intègre effectivement
les résultats de mise à 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é coordonnateur, les autres étant
des participants.

a) Coordonnateur de validation

Composant système d’un site qui applique le protocole (lance la transaction, la découpe
en sous-transactions à exécuter sur les différents sites, coordonne la terminaison de la
transaction). Il dirige le protocole en centralisant le contrôle.

b) Participant à validation

Nœud d’un système réparti qui exécute des mises à jour de la transaction et obéit aux
commandes de préparation, validation ou annulation du coordonnateur. Il participe dans
l'exécution de la transaction.

7. Protocole de validation en deux phases

Protocole permettant de garantir l’atomicité des transactions dans un système réparti,

composé d’une préparation de la validation et de centralisation du contrôle, et d’une
étape d’exécution.

7.1 Validation normale

Validation normale
 7.2 Panne d’un participant avant d’être prêt

Panne d’un participant avant d’être prêt

7.3 Panne d’un participant après s’être déclaré prêt

 Panne d’un participant après s’être déclaré prêt

7.4 Panne du coordonnateur

Panne du coordonnateur

8. Contrôle de concurrence

L’objectif général est de rendre aux clients le partage simultané des données. Ceci
s’effectue au moyen de protocoles spéciaux permettant de synchroniser les mises à jour
afin d’éviter pertes de mise à jour.

Plusieurs utilisateurs accèdent simultanément à la base de données. Les transactions décrites

précédemment étaient considérées comme séquentielles. L'accès aux données par
plusieurs transactions simultanées est un point capital pour l'efficacité d'une base de
données. L'accès concurrent permet de partager les ressources machines et d'optimiser le
temps CPU.

Deux modules permettent de gérer l'exécution de transactions : le gestionnaire de

transactions (transaction manager) et l'ordonnanceur (scheduler).

Le gestionnaire de transactions (transaction manager) est responsable de la coordination de

l'exécution des opérations spécifiques à la base de données. L'ordonnanceur (scheduler)
est responsable de l'implémentation d'un algorithme de contrôle de concurrence afin de
synchroniser l'accès à la base de données.
Le contrôle de concurrence est un mécanisme du SGBD qui contrôle l'exécution
simultanée de transactions de manière à produire les mêmes résultats qu'une exécution
séquentielle. Cette propriété est la sérialisabilité (serializability).

1. La sérialisabilité des transactions :

Une exécution d'un ensemble de transaction est dite sérialisable si elle donne pour chaque
transaction participante, le même résultat que l'exécution en séquentielle de ces mêmes
transactions.

2. Le verrouillage

L'outil le plus répandu pour sérialiser les transactions est basé sur l'utilisation de
verrous (lock). On impose que l'accès aux données se fasse de manière mutuellement
exclusive. Un verrou est posé sur chaque donnée accédée par une transaction afin
d'empêcher les autres transactions d'y accéder. Mais les verrous ne sont pas tous
équivalents.

Il existe des verrous pour les lectures et d'autres pour les écritures, dont la
compatibilité est résumée dans le tableau qui suit, appelé matrice des compatibilités de
verrouillage :

lecture écriture
lecture compatible non compatible
écriture non compatible non compatible
Verrouillage

3. Le verrouillage deux phases

Le verrouillage deux phases est une technique de prévention des conflits basée sur le
verrouillage des objets en lecture ou en écriture avant d’effectuer une opération de
sélection ou de mise à jour.

C’est une technique de contrôle des accès concurrences consistant à verrouiller les
objets au fur et à mesure des accès par une transaction et à relâcher les verrous
seulement après obtention de tous les verrous.

III.10. REPLICATION DANS LES BASES DE DONNEES

REPARTIES
Les techniques de réplication permettent la gestion de copies multiples pouvant diverger
c’est-à-dire présenter des valeurs différentes à un instant donné, mais convergeant vers
les mêmes valeurs à termes.
Nous examinons ci – dessous les différentes formes de réplication possibles et les
techniques de gestion de la cohérence des copies associées.

1. Avantages

La réplication améliore les performances et augmente la disponibilité des données.

Grâce à la réplication, les lectures sont exécutées sur le site disposant de la copie la
plus proche du client ce qui peut éviter des transferts inutiles, par exemple si le client
dispose d’une copie.

Aussi bien pour les lectures que pour les écritures, la réplication permet d’éviter le
goulot d’étranglement que constitue le serveur unique en partageant la charge.

La réplication favorise aussi d’une part les lectures qui sont alors locales, et d’autres
par la résistance à la panne.

2. Problèmes

Si la réplication présente de nombreux avantages, les problèmes soulevés sont multiples.

Tout d’abord, il faut assurer la convergence des copies. Si les copies peuvent être
différentes à un instant donné, elles doivent converger vers le même état cohérent où
toutes les mises à jour sont exécutées partout dans le même ordre.

Ensuite, il faut offrir la transparence de gestion aux utilisateurs. Les clients doivent
croire à l’existence d’une seule copie : en conséquence, le SGBD doit assurer la
diffusion des mises à jour aux copies et le choix de la meilleure copie lors des accès.

3. Mise à jour synchrone et asynchrone

3.1 Mise à jour synchrone

Mode de distribution dans lequel toutes les sous opérations locales effectuées suite à
une mise à jour globale sont accomplie pour le compte de la même transaction.

Dans le contexte des copies, ce mode de distribution est très utile lorsque les mises à
jours effectuées sur un site doivent être prises en compte immédiatement sur les autres
sites.

L’avantage essentiel de la mise à jour synchrone est de garder toutes les données au
dernier niveau de mise à jour.

Le système peut alors garantir la fourniture de la dernière version des données quelque
soit la copie accédée. Les inconvénients sont cependant multiples, ce qui conduit
beaucoup d’application à éviter la gestion des copies synchrones.
Ce sont d’une part la nécessité de gérer les transactions multi listes coûteuses en
ressources, et d’autres parts la complexité des algorithmes de gestion de concurrence et
de panne d’un site c’est pour cela que l’on préfère souvent le mode de mise à jour
asynchrone (encore appelé mise à jour différé)

3.2 Mise à jour asynchrone

Mode de distribution dans le quel certaines sous opérations locales effectuées suite à
une mise à jour globale sont accomplies dans des transactions indépendantes en temps
différé.

Le temps de mise à jour des copies peut être plus ou moins différé : les transactions
de report peuvent être lancées dès que possible où à des instants fixés, par exemple le
soir ou en fin de semaine.

Les avantages sont la possibilité de mettre en jour en temps choisi des données tout en
autorisant l’accès aux versions anciennes avant la mise à niveau. Les inconvénients sont
bien sûr que l’accès à la dernière version n’est pas garanti, ce qui limite les possibilités
de mise à jour.

4. Techniques de diffusion des mises à jour