Université Aube Nouvelle

Cours sur les bases de données reparties

Master1/ Management des systèmes d'information (M1MSI)

Mars 2024

OUEDRAOGO W. P. Eric
Expert en ingénierie, conception et gestion des Systèmes d’Information

Année Académique 2023-2024

1
Objectif global :

Permettre aux étudiants d'avoir des notions de base sur les systèmes repartis/distribués et de
pouvoir mettre en œuvre des bases de données repartis.

Objectifs spécifiques

A la fin de la leçon, l’étudiant doit être capable de :

 comprendre le vocabulaire et les concepts de base associés aux bases de données

repartis;

 maîtriser les méthodes et techniques de conception de base de données reparties;

 mettre en œuvre des bases de données reparties.

Contenu du cours

Le cours sur les bases de données reparties est structuré en 04 parties :

 Concepts généraux;

 Les bases de données réparties;

 Mise en œuvre d'une BD repartie;

Activités d’apprentissage

 l’étude des notes du cours ;

 la recherche d’informations ;

 l’application des travaux pratiques.

2
SOMMAIRE
Partie I : Concepts généraux ..................................................................................... 7

I LES SYSTEMES REPARTIS ..................................................................................................... 8

I.4 LES AVANTAGES DES SYSTEMES REPARTIS ................................................................. 9

I.5 INCONVENIENTS DES SYSTEMES REPARTIS ............................................................... 10

I.6 CARACTERISTIQUES DES SYSTEMES REPARTIS ........................................................ 10

I.6.1 LA LATENCE .................................................................................................................... 10

I.6.2 LA MEMOIRE REPARTIE ................................................................................................ 11

I.6.3 LES PANNES PARTIELLES ............................................................................................ 11

I.6.4 LA CONCURRENCE ........................................................................................................ 12

I.6.5 LA CONFIANCE ............................................................................................................... 12

I.7 LES DOMAINES D'APPLICATION DES SYSTEMES REPARTIS ..................................... 12

II LES APPLICATIONS REPARTIES.......................................................................................... 12

III SYSTEMES REPARTIS ET SGBD .................................................................................... 15

III.1 LE CLIENT SERVEUR COMME ARCHITECTURE OPERATIONNEL DES SGBD .... 15

III.2 LES ARCHITECTURES DE BASE DE DONNEES REPARTIES .................................... 16

III.3 LES ARCHITECTURES PEER-TO-PEER ....................................................................... 17

III.4 LES NIVEAUX DE SCHEMAS D’UNE ARCHITECTURE DE BASE DE DONNEES

REPARTIE......................................................................................................................................... 17

IV LA REPLICATION .......................................................................................................... 18

V LES MIDDLEWARES ............................................................................................................... 18

PARTIE II : LES BASES DE DONNEES REPARTIES ....................................... 20

I LES BASES DE DONNEES REPARTIES ................................................................................ 21

I.1 CONTEXTE .......................................................................................................................... 21

I.2 DEFINITION ......................................................................................................................... 21

I.3 BUTS DE LA REPARTITION DES BASES DE DONNEES ................................................ 21

I.4 INCONVENIENTS DE LA REPARTITION DES DONNEES ............................................... 21

I.5 CARACTERISTIQUES D'UNE BASE DE DONNEES REPARTIE ..................................... 22

I.6 LES OBJECTIFS DES BASES DE DONNEES REPARTIES .............................................. 22

3
I.7 LES CONTRAINTES ............................................................................................................ 23

I.8 DU SGBD AU SGBDR ..................................................................................................... 23

I.9 LES SGBD .......................................................................................................................... 23

I.10 LES SGBD REPARTIS ................................................................................................... 23

II METHODE DE CONCEPTION DES BASES DE DONNEES REPARTIES ............................. 24

II.1 PRINCIPE ............................................................................................................................. 24

II.2 ETAPES DE CONCEPTION D'UNE BASE DE DONNEES REPARTIE ............................. 25

III LA CONCEPTION DU SCHEMA GLOBALE ....................................................................... 25

III.1 POURQUOI ? ................................................................................................................... 25

III.2 COMPOSITION DU SCHEMA GLOBAL ......................................................................... 26

III.3 APPROCHE DE CONCEPTION ....................................................................................... 27

III.3.1 LA CONCEPTION DESCENDANTE (TOP DOWN DESIGN) .................................... 27

III.3.2 LA CONCEPTION ASCENDANTE (BOTTOM UP DESIGN) ..................................... 28

IV LA FRAGMENTATION......................................................................................................... 28

IV.1 DEFINITION ..................................................................................................................... 28

IV.2 OBJECTIF DE LA FRAGMENTATION ........................................................................... 29

IV.3 LES REGLES DE LA FRAGMENTATION ....................................................................... 29

IV.4 LES TYPES DE FRAGMENTATION ............................................................................... 29

IV.4.1 LA FRAGMENTATION HORIZONTALE..................................................................... 29

IV.4.2 FRAGMENTATION VERTICALE ................................................................................. 30

IV.4.3 FRAGMENTATION MIXTE .......................................................................................... 31

IV.5 MISE A JOURS DES BDDR ............................................................................................ 32

V ALLOCATION DES FRAGMENTS .......................................................................................... 32

V.1 DEFINITION ......................................................................................................................... 32

V.2 ALLOCATION SANS REPLICATION .................................................................................. 33

V.3 ALLOCATION AVEC REPLICATION .................................................................................. 33

V.4 TECHNIQUE DE REPARTITION AVANCEE ...................................................................... 33

V.4.1 ALLOCATION AVEC DUPLICATION ............................................................................. 34

V.4.2 ALLOCATION DYNAMIQUE ........................................................................................... 34

V.4.3 FRAGMENTATION DYNAMIQUE ................................................................................... 34

4
V.4.4 CLICHES .......................................................................................................................... 34

VI GESTION DES TRANSACTIONS REPARTIES................................................................. 34

VI.1 DEFINITION ..................................................................................................................... 35

VI.2 OPERATIONS DE NATURE TRANSACTIONNEL DANS LES SGBD......................... 35

VI.3 EXEMPLE DE TRANSACTION........................................................................................ 35

VI.4 LES PROPRIETES D’UNE TRANSACTION ................................................................... 35

VI.4.1 ATOMICITE .................................................................................................................. 36

VI.4.2 COHERENCE................................................................................................................ 36

VI.4.3 ISOLATION................................................................................................................... 36

VI.4.4 DURABILITE ................................................................................................................ 36

VI.5 THEORIE DE LA CONCURRENCE ................................................................................. 36

VI.5.1 OBJECTIFS .................................................................................................................. 36

VI.5.2 PROBLEMES A EVITER .............................................................................................. 37

VI.5.2.1 PERTE DE MISE A JOUR ....................................................................................... 37

VI.5.2.2 INCOHERENCE ........................................................................................................ 37
VI.5.2.3 NON-REPRODUCTIBILITE DES LECTURES ........................................................ 38
VI.6 LES OPERATIONS SUR GRANULE ............................................................................... 39

VI.6.1 DEFINITION ................................................................................................................. 39

VI.6.1.1 GRANULE ................................................................................................................. 39

VI.6.1.2 ACTION .................................................................................................................... 39

VI.6.1.3 EXECUTION DE TRANSACTIONS (SCHEDULE) ................................................ 39

VI.7 PROPRIETES DES OPERATIONS SUR GRANULE ...................................................... 40

VI.7.1 NOTION D’OPERATIONS ........................................................................................... 40

VI.7.2 NOTION DE RESULTAT ............................................................................................. 41

VI.7.3 OPERATIONS COMPATIBLES ................................................................................... 41

VI.7.4 OPERATIONS PERMUTABLES .................................................................................. 42

VI.8 CARACTERISATION DES EXECUTIONS CORRECTES............................................... 43

VI.8.1 SUCCESSION (SERIAL SCHEDULE) ....................................................................... 43

VI.8.2 EXECUTION SERIALISABLE (SERIALISABLE SCHEDULE) ................................. 43

VI.9 CONTROLE DE CONCURRENCE ................................................................................... 46

5
 VI.9.1 PRINCIPE DE BASE .................................................................................................... 46

VI.9.2 LES MECANISMES UTILISES .................................................................................... 47

VI.9.2.1 LES ESTAMPILLES ................................................................................................. 47

VI.9.2.2 LE VERROUILLAGE ................................................................................................ 47

VI.9.3 NOTION D’INTERBLOCAGES .................................................................................... 47

PARTIE III : MISE EN ŒUVRE D'UNE BD REPARTIE ..................................... 49

I LE SGBD ORACLE ................................................................................................................ 50

I.1 PRESENTATION .................................................................................................................. 50

I.2 CONNEXION AU SERVEUR ORACLE ............................................................................... 50

I.3 LE PROCESSUS D'ECOUTE ORACLE (LISTNER) ....................................................... 50

I.4 LE TNS ................................................................................................................................ 51

I.5 LES LIENS DE BASE DE DONNEES .................................................................................. 51

I.6 MECANISME DE TRANSPARENCE ................................................................................... 52

I.6.1 LES VUES......................................................................................................................... 52

I.6.2 LES SYNONYMES ........................................................................................................... 52

I.6.3 LES PROCEDURES.......................................................................................................... 52

I.6.4 LES DECLENCHEURS (TRIGGERS).............................................................................. 52

II TECHNIQUE DE REPARTITION............................................................................................. 52

II.1 PREALABLES ...................................................................................................................... 52

II.2 PRINCIPES DE SECURITE ................................................................................................. 53

6
Partie I : Concepts généraux

7
I LES SYSTEMES REPARTIS

I.1 CONTEXTE

La problématique de la répartition est née avec l'idée de faire communiquer des ordinateurs
via un réseau de communication.
Depuis l’apparition des premiers ordinateurs jusque maintenant, l’informatique définie
comme étant le traitement automatisé de l’information n’a cessé d’évoluer et est devenue
presque incontournable dans tous les secteurs. Les masses d’informations ont également suivi
cette évolution, ce qui a permis le passage jadis du traitement séquentiel au traitement
distribué aujourd’hui, afin de bénéficier de la disponibilité des ressources et l’efficacité du
traitement. C’est ainsi que les systèmes distribués ou répartis ont vu le jour pour répondre à
ces critères (disponibilité, efficacité, etc). Des exemples de tels systèmes sont : les systèmes
pairs à pair (P2P), les service réseaux (DNS), les systèmes de routage etc.
Pour atteindre ces critères, ces systèmes mettent en interaction via un réseau de
communication des milliers de machines autonomes souvent dispersées géographiquement et
constitués de plusieurs domaines d’administration.
La figure ci-dessous présente un système distribué constitué de trois (03) domaines
d’administration.

I.2 DEFINITION

La répartition est la mise à disposition d'un ensemble de ressources et services connectés via
un réseau pour tous les usagers qui possèdent un droit d'accès en un point quelconque.

8
Un système reparti est constitué d’un ensemble d’ordinateurs indépendants reliés par un
moyen de communication. Les machines sont autonomes et les utilisateurs ont l’impression
d’utiliser un seul système.
Un système réparti est un système informatique dans lequel les ressources ne sont pas
centralisées. Ces ressources sont notamment :
- les moyens de stockage (données, fichiers) ;
- la mémoire physique (sinon c'est un système parallèle) ;
- la charge CPU ;
- les utilisateurs ;
- les traitements …

I.3 LES EXIGENCES

La construction des systèmes repartis impose certaines exigences :

- Hétérogénéité : un système reparti doit pouvoir gérer l’hétérogénéité concernant le
matériel, les systèmes d’exploitations, les langages de programmation.
- Interopérabilité : deux systèmes répartis sont interopérables lorsque des entités
définies dans l’un et l’autre peuvent interagir afin de coopérer à la réalisation d’un but.
- Sécurité : elle permet d’assurer le bon fonctionnement des applications et de respecter
les droits d’accès aux ressources disponibles sur le système.
- Extensibilité : un système reparti doit faciliter l’intégration de nouvelles entités dans
le système.

I.4 LES AVANTAGES DES SYSTEMES REPARTIS

Partage et Mise à disposition : partager des ressources et des services disponibles (ex: les
systèmes d'exploitation répartis qui permettent de mettre en place un service de gestion
de fichiers partagés et répartis)
Répartition géographique : mettre à disposition des usagers les moyens informatiques
locaux en même temps que ceux distants de leurs collègues (ex: un système de réservation
d'hôtel répartis en différents pays, compagnies ou agences; autre ex: un système bancaire avec
ses agences régionales et son siège social)
Puissance de calcul : paralléliser les algorithmes de calcul avec des environnements
d'exécution spécifique comme PVM (Parallel Virtual Machine) ou MPI (Message Passing
Interface)

9
Disponibilité d'un service : continuer un service globalement même dégradé Exemple
courant: la réplication d'un même service par l'installation de plusieurs serveurs équivalents.
Flexibilité
- par nature modulaire
- continuité de service pendant la maintenance (remplacement d'un noeud)
- l'informatique nomade : portable et points d'accès mobiles sur un réseau réparti aux
frontières floues (Internet)
- les problèmes posés sont :
 la localisation
 l'identification
 l'authentification
 l'optimisation des temps de connexion
Adaptabilité à une forte croissance des besoins informatiques d'une entreprise.

I.5 INCONVENIENTS DES SYSTEMES REPARTIS

- Plusieurs points de défaillance;

- Sécurité;
- Difficulté pour le système d’avoir un état global;
- Complexité accrue.

I.6 CARACTERISTIQUES DES SYSTEMES REPARTIS

Un système reparti possède quatre caractéristiques fondamentales à savoir :

- la concurrence ;
- les pannes partielles ;
- la mémoire répartie ;
- la latence.
A cela s’ajoute une cinquième qui paraît pertinente: la confiance.
L’ordre dans lequel nous les présentons ne reflète aucune importance ou hiérarchie entre ces
caractéristiques. Toutes constituent un obstacle ou une difficulté. Pourtant, on peut remarquer
qu’elles ne sont pas toutes de même nature. Certaines sont directement liées à des
phénomènes physiques, d’autres sont constitutives des systèmes repartis ou sont une
conséquence de la repartition.

I.6.1 LA LATENCE

10
La latence correspond à un phénomène physique. Le transport d’une information d’un noeud
A vers un nœud B sur un réseau nécessite le déplacement d’éléments appartenant au monde
physique : électrons, ondes radio, photons. La vitesse de ces déplacements est bornée par la
vitesse de la lumière. En pratique, elle est également bornée par l’organisation et
l’architecture du réseau : temps de traitement par des routeurs intermédiaires, temps de
négociation du média lorsqu’il est partagé par plusieurs machines, etc. Le délai induit par
l’ensemble de ces phénomènes physiques et/ou techniques forme ce qu’on appelle la
latence. La latence est une caractéristique intrinsèque d’un système reparti de par
l’éloignement physique ou topologique des machines.
La latence étant une caractéristique liée à des phénomènes physiques ou matériels, elle ne
peut ni être masquée, ni être réduite. On peut faire une brève comparaison avec la notion
de bande passante, qui représente la quantité de données qui peut transiter sur un
support pendant une période donnée. Si la bande passante entre deux machines est trop
faible par rapport à l’application visée, il est toujours possible de l’augmenter en ajoutant un
lien supplémentaire. Pour autant, la latence de ce lien n’aura pas changé.

I.6.2 LA MEMOIRE REPARTIE

La mémoire répartie est une caractéristique constitutive des systèmes repartis. Chaque
machine participant à un système reparti possède sa propre mémoire, son propre espace
d’adressage et éventuellement ses propres périphériques de stockage permanents.
La mémoire de l’ensemble du système est donc répartie dans le sens où une partie des
données se trouve sur un site, une autre partie sur un autre et certaines données peuvent
éventuellement être dupliquées. La prise en charge de cette répartition implique la mise en
œuvre de mécanismes de communication pour l’échange de données entre les différents sites.

I.6.3 LES PANNES PARTIELLES

Les pannes partielles peuvent être considérées comme une conséquence de la distribution. Le
fait même qu’un ensemble de machines soit utilisé implique que ces dernières puissent tomber
en panne indépendamment les unes des autres. Cette notion de panne partielle s’associe à
celle de fonctionnement partiel qui peut être vue comme un atout par rapport à un système
local. En effet, si un service est hébergé sur une seule machine, la panne de celle-ci implique
l’arrêt du service. Si on imagine qu’il est déployé sur un ensemble de machines distinctes, il
devient alors possible de profiter de la notion de panne partielle, ou plutôt de fonctionnement
partiel, pour maintenir le service même dans le cas où l’une des machines ne fonctionne plus.

11
I.6.4 LA CONCURRENCE

La concurrence correspond au fait qu’un ensemble de machines indépendantes tentent

d’accéder simultanément à une même ressource ou à un ensemble de ressources partagées. Il
est alors nécessaire de conserver cette ou ces ressources dans un état cohérent.

I.6.5 LA CONFIANCE

La confiance entre les différentes machines d’un système reparti est un élément essentiel.
Nous ajoutons donc cette caractéristique aux quatre précédentes. Dès lors que l’ensemble des
machines participant à un système reparti ne sont pas toutes gérées et administrées par la
même organisation, des problèmes de confiance entre ces machines apparaissent. Il est
nécessaire de proposer des mécanismes pour gérer cette confiance et assurer une certaine
protection en son absence.

I.7 LES DOMAINES D'APPLICATION DES SYSTEMES REPARTIS

Le monde des systèmes informatiques répartis /distribués sont en constantes évolutions : les
réseaux évoluent, les techniques logicielles sont en constantes révolutions, la prolifération du
logiciel libre accentue cette évolution, les performances sont en constante croissance. Les
systèmes repartis s’appliquent à plusieurs domaines :
- Mathématique, base de données, algorithmique, puissance de calcul ;
- Innovations (agents, collaboration, …) ;
- Intelligence Artificielle (utilise les principes algorithmiques des systèmes répartis dans
les réseaux de neurones avec pour objectif de répartir la connaissance et ses
mécanismes et non les centraliser) ;
- Systèmes d'information d'entreprise ;
- Les particuliers : partager ses données, jeux, accès et collaboration avec des services
communs, …
- Sites Internet : un site est un lieu de partage de l'information et de distribution de
service.

II LES APPLICATIONS REPARTIES

II.1 PRINCIPES

12
Le terme Application Répartie désigne un ensemble d'au moins deux processus qui coopèrent
via un système de communication, en s'échangeant des informations conformément à un
protocole défini. Ces processus sont généralement répartis sur autant de machines physiques.

II.2 LE MODELE CLIENT/SERVEUR

Le modèle le plus connu d'application répartie est le modèle Client/Serveur, dans lequel
intervient un processus dit Serveur effectuant des traitements à la demande d'un ou plusieurs
processus de type Client.

Un processus Client, hébergé sur une machine A, envoie sa requête au processus Serveur,
hébergé sur la machine B. Celui-ci renvoie à son tour le résultat de la requête.

II.3 LE MODELE N-TIERS

Le modèle n-tiers est une extension du modèle Client/Serveur dans lequel un processus
Serveur peut à son tour devenir le Client d'un autre processus au cours du traitement de la
requête. Avec le développement croissant des communications, en particulier du réseau
Internet, ce modèle est aujourd'hui largement répandu.

II.4 LES APPELS DE PROCEDURES A DISTANCE (RPC)

Les divers protocoles de communication physique (TCP/IP, UDP/IP...), l’hétérogénéité des

systèmes d'exploitation, de leurs versions et librairies, les différentes architectures matérielles

13
(CISC, RISC), représentations des données (Big Endian, Little Endian) et la variété des
langages de programmation alourdissent la mise en oeuvre d'applications réparties et peuvent
être sources d’erreurs.
Dans le but d'en faciliter le développement sont apparus dans les années 1980 les mécanismes
de RPC (Remote Procedure Call). Reposant sur les sockets, cette technologie permet de
mettre en place un mécanisme d'appel de procédure à distance de manière transparente, en
prenant en charge les aspects de communications bas niveau.

II.5 LES BUS MIDDLEWARE ORIENTES OBJET

Tout comme le RPC, le bus middleware représente un ensemble de couches logicielles qui
permet de faciliter l'interaction entre processus distants et de masquer certains détails liés à
l’environnement d'exécution des applications, comme par exemple le système d'exploitation.
Le processus de création de l'application reste assez similaire que pour la technologie RPC, à
savoir, la définition des services fournis par un objet, puis une génération de souches pour la
mise en place des moyens de communication entre les différentes entités de l'application.
En outre, le bus middleware fournit généralement des propriétés et des concepts
supplémentaires sur lesquels le concepteur peut se reposer pour bâtir l'application et en
faciliter le déploiement, parmi lesquels nous pouvons citer :
- La séparation des interfaces et de l’implémentation des objets : la notion
d'interface permet au concepteur d'avoir accès à des services sans se préoccuper de
l'implémentation qui les fournit. Ce principe permet de mettre à jour et d'étendre les
fonctionnalités de l'implémentation des services sans que le client n'ait à changer la
manière d'y accéder.

- La transparence au protocole de communication : la couche bas-niveau utilisée

pour les communications est prise en charge par le bus middleware. Les souches
générées à partir de la définition des services assurent la liaison physique entre
l'implémentation qui fournit le service et l'objet qui l'utilise. Ainsi, la conception de
l'application est indépendante de la technologie de communication utilisée, et ne

14
 souffre pas d'un éventuel changement de support, si toutefois le middleware le
supporte.
- La transparence à la localisation des objets : grâce à des mécanismes tels que le
service de nommage, les objets distants peuvent être localisés sans avoir recours aux
adresses physiques des nœuds sur lesquels ils sont hébergés.

Dans la figure ci-dessus, un Service s'enregistre auprès du service de nommage (1). Un client,
lorsqu'il veut utiliser un tel service, peut en faire la demande au service de nommage (2).
Celui-ci localise l'instance du service, et met en relation les souches côté client et côté serveur
(3). Les interactions entre les deux objets peuvent alors commencer.
Il existe diverses implémentations d'architectures middleware orientées objet. Parmi les plus
répandues, on peut citer CORBA de l'Object Management Group (OMG) , Java RMI de Sun
Microsystem, ou encore le Framework.Net/Remoting de Microsoft. Dans le principe, ces trois
architectures fonctionnent d'une manière similaire, ainsi on y retrouve la plupart des notions
évoquées précédemment. Les différences apparaissent principalement, de notre point de vue,
dans la manière de spécifier les fonctionnalités du service, de générer les couches
intermédiaires ou de retrouver les objets distants.

III SYSTEMES REPARTIS ET SGBD

III.1 LE CLIENT SERVEUR COMME ARCHITECTURE OPERATIONNEL DES SGBD

D’un point de vue opérationnel, un SGBD est un ensemble de processus et de tâches qui
supportent l’exécution du code du SGBD pour satisfaire les commandes des utilisateurs.
Depuis le milieu des années 80, les SGBD fonctionnent selon l’architecture client-serveur,
cela faisant suite à l’avènement des architectures distribuées.
L’architecture client-serveur inclut le noyau d’un SGBD, appelé DMCS (Description
Manipulation and Control Sub-system), qui fonctionne en mode serveur. Autour de ce serveur

15
s’articulent des processus attachés aux utilisateurs supportant les outils et les interfaces
externes. Le DMCS (noyau du SGBD qui fonctionne en mode serveur) est construit sur le
gestionnaire de fichiers ou de disques virtuels du système opératoire.
Il existe différentes variantes de l’architecture client-serveur, selon qu’un processus serveur
est associé à chaque utilisateur, ou que plusieurs utilisateurs partagent un même processus
serveur. Dans le premier cas, le serveur est mono tâche. Chaque processus client a un
processus serveur associé. La machine supportant les serveurs doit partager son temps entre
eux. Les commutations de processus peuvent être lourdes (quelques millisecondes sur UNIX).
De plus, les processus serveurs partageant les mêmes données, il est nécessaire de les
synchroniser, par exemple par des sémaphores, afin d’éviter les problèmes de concurrence
d’accès. Cela peut entraîner des pertes de temps importantes, et donc de mauvaises
performances en présence d’usagers multiples.
Aujourd’hui, plusieurs systèmes proposent un serveur multitâche, capable de traiter plusieurs
requêtes d’utilisateurs différents en parallèle. Cela est réalisé grâce à un multiplexage du
serveur en tâches, les commutations de tâches étant assurées par le serveur lui-même, au
niveau d’un gestionnaire de tâches optimisé pour les bases de données. Une telle architecture
multitâche (en anglais, multi-thread) permet de meilleures performances en présence d’un
nombre important d’utilisateurs.

III.2 LES ARCHITECTURES DE BASE DE DONNEES REPARTIES

Afin de répondre à la tendance centralisatrice de l’approche client-serveur, certains SGBD

préconisent une architecture répartie. Une architecture répartie fait interagir plusieurs serveurs
gérant un ensemble de bases perçu comme une seule base par les utilisateurs.
C’est une architecture composée de plusieurs serveurs coopérant à la gestion de bases de
données composées de plusieurs sous-bases gérées par un seul serveur, mais apparaissant
comme des bases uniques centralisées pour l’utilisateur.
La figure ci-dessous illustre une architecture répartie. Celle-ci est composée de différents
serveurs munis de SGBD différents et spécialisés. C’est un exemple de base de données
répartie hétérogène, encore appelée base de données fédérée.

16
III.3 LES ARCHITECTURES PEER-TO-PEER

Dans ces systèmes, chaque pair agit à la fois comme un client et un serveur pour donner des
services de base de données. Les pairs partagent leur ressource avec d'autres pairs et
coordonnent leurs activités.

III.4 LES NIVEAUX DE SCHEMAS D’UNE ARCHITECTURE DE BASE DE DONNEES

REPARTIE

L’architecture d’une base de donnée repartie a généralement quatre niveaux de schémas :

- Schéma Conceptuel Global : Décrit la vue des données logique globale.
- Schéma Conceptuel Local: Décrit l'organisation logique de données à chaque
emplacement.
- Schéma Interne Local: Décrit l'organisation physique de données à chaque
emplacement.
- Schéma Externe: Décrit la vue d'utilisateur des données.

17
IV LA REPLICATION

La réplication désigne la reproduction identique de données d'un site à un autre. Elle a

pour but d'assurer la fiabilité du système et diminuer les trafics réseaux, dans le cadre de
systèmes distribués. Ainsi, si un site est momentanément inaccessible, un autre peut
valablement le remplacer sans que les utilisateurs ne s'en aperçoivent. Aussi, au lieu de faire
des requêtes réparties, qui occupent la bande passante, les requêtes se font au niveau local.

Le mode le plus courant de la réplication dans les bases de données est la notion de clichés en
anglais snapshots. Un snapshot est une photo de la base de données partiellement ou
totalement à un instant donné. Afin de garder une certaine cohérence de la base, les clichés
doivent régulièrement être mis à jour. Ainsi, plus le cliché est récent, plus il est fiable.

V LES MIDDLEWARES

Dans les métiers de l’ingénierie des logiciels, une abstraction de l’aspect matériel est faite, ce
sont les logiciels/services qui communiquent entre eux grâce aux protocoles des couches
applicatives. Certains logiciels ont pour rôle d’interconnecter d’autres logiciels :Nous
employons le terme d’« intergiciel », ou « middleware » en anglais pour qualifier ces
logiciels.

Les middlewares peuvent avoir plusieurs fonctions :

- Echange/transformation de messages ;
- Appel de procédure à distance ;
- Manipulation d’objets ;
- Gestion des transactions.

18
Voici un schéma de plusieurs applications interconnectées par le biais d’un middleware :

19
PARTIE II : LES BASES DE DONNEES

REPARTIES

20
I LES BASES DE DONNEES REPARTIES

I.1 CONTEXTE

Le développement des techniques informatiques depuis ces dernières années a permis

d'appliquer les outils informatiques dans l'organisation des entreprises. Vu, l’immense volume
de données maniées par ces dernières, la puissance des micro-ordinateurs, les performances
des réseaux et la baisse considérable des coûts du matériel informatique ont permis
l'apparition d'une nouvelle approche afin de remédier aux difficultés causées par la
centralisation des données, et ce en répartissant les ressources informatiques tout en
préservant leur cohérence.

I.2 DEFINITION

Une base de données répartie (BDR) est une base de données dont différentes parties sont
stockées sur des sites, généralement géographiquement distants, reliés par un réseau. La
réunion de ces parties forme la base de données répartie.

I.3 BUTS DE LA REPARTITION DES BASES DE DONNEES

Les bases de données réparties ont une architecture plus adaptée à l’organisation des
entreprises décentralisées.

- Plus de 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.
- Meilleures performances : réduire le trafic sur le réseau est une possibilité
d’accroître les performances. Le but de la répartition des données est de les rapprocher
de l’endroit où elles sont accédées. Répartir une base de données sur plusieurs sites
permet de répartir la charge sur les processeurs et sur les entrées/sorties.
- Faciliter l’accroissement: l’accroissement se fait par l’ajout de machines sur le
réseau.

I.4 INCONVENIENTS DE LA REPARTITION DES DONNEES

L'inconvénient majeur de la répartition des données d'une BD entre plusieurs sites est la
complexité résultant de leur coordination. Cette complexité se répartit de la façon suivante :

21
 - Le coût de mise au point du logiciel;
- Le nombre d'erreurs logicielles plus important;
- Les servitudes du système accrues pour la coordination.
o Echange de messages.
o Calcul supplémentaire.
o Récupération de système plus complexe après panne (Réintégration des sites
ou liaison en pannes).

I.5 CARACTERISTIQUES D'UNE BASE DE DONNEES REPARTIE

- La distribution de données : les données ne résident pas dans le même site.

- Corrélation logique des données: les données possèdent les propriétés qui les
tiennent ensemble.
- Une structure de contrôle hiérarchique basée sur un administrateur des bases de
données globales qui est le responsable central sur les bases de données réparties
entières et sur les administrateurs des bases de données locales, qui ont la
responsabilité de leur base de données respective.
- L'indépendance des données et la transparence de répartition.
- La redondance des données qui permet l'accroissement de l'autonomie des
applications et la disponibilité des informations en cas de panne d'un site.
- Un plan d'accès réparti écrit soit par le programmeur ou produit automatiquement
par un optimiseur.

I.6 LES OBJECTIFS DES BASES DE DONNEES REPARTIES

- Transparence pour l’utilisateur ;

- Autonomie de chaque site ;
- Absence de site privilégié ;
- Continuité de service ;
- Transparence vis à vis de la localisation des données ;
- Transparence vis à vis de la fragmentation ;
- Transparence vis à vis de la réplication ;
- Traitement des requêtes distribuées ;
- Indépendance vis à vis du matériel ;
- Indépendance vis à vis du système d’exploitation ;
- Indépendance vis à vis du réseau ;

22
 - Indépendance vis à vis du SGBD.

I.7 LES CONTRAINTES

- 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).
- Problème de concurrence.
- 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.

I.8 DU SGBD AU SGBDR

I.9 LES SGBD

Le SGBD (Système de Gestion des Bases de Données) est l'outil principal de gestion d'une
base de données. Il permet d'insérer, de modifier et de rechercher efficacement des données
spécifiques dans une grande masse d'informations. C'est une interface entre les utilisateurs et
la mémoire de masse. Il facilite ainsi le travail des utilisateurs en leur donnant l'impression
que l'information est organisée comme ils le souhaitent. Le SGBD est composé de plusieurs
couches :

- Le SGBD externe (user interface handler) : Sa tâche est d'interpréter les

commandes utilisateurs.
- Le contrôleur sémantique des données (sémantic data controler) : Il utilise les
différentes contraintes définies sur la base de données afin de vérifier qu'une requête
d'un utilisateur peut être effectuée.
- Le processeur de requêtes (query processor) : Il détermine une stratégie afin de
minimiser le temps d'exécution d'une requête.
- Le gestionnaire de transactions (transaction manager) : Il assure la coordination
des différentes demandes des utilisateurs.
- Le gestionnaire de reprise (recovery manager) : Il s'occupe d'assurer la cohérence
des données lorsque des pannes surviennent.
- Le système de gestion des fichiers (run-time support processor) : Il gère le
stockage physique de l'information. Il est dépendant du matériel utilisé.

I.10 LES SGBD REPARTIS

23
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 est gérée par plusieurs
processeurs, sites ou SGBD.

Come déjà souligné, 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 pas être confondu avec une multibase ou une BD fédérée.

Dans une multibase, plusieurs BDs interopé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 :

- Architecture Client-Serveur : les serveurs, ont pour rôle de servir les clients. Par
servir, on désigne la réalisation d’une tâche demandée par le client.
- Architecture Pair-à-Pair (Peer-to-Peer, P2P) : par ce terme on désigne un type de
communication pour lequel toutes les machines ont une importance équivalente.
Un SGBD réparti doit rendre la répartition des bases de données transparentes aux
utilisateurs. La base de données étant répartie, il faut également répartir certaines
fonctionnalités du SGBD. Le schéma d'un SGBD réparti est résumé dans la figure ci-dessous :

II METHODE DE CONCEPTION DES BASES DE DONNEES REPARTIES

II.1 PRINCIPE

24
Comme dans tous les mécanismes, la phase de conception est la plus importante et
déterminante dans la mise en place d'une base de données reparties. Le rôle du concepteur est
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.

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

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

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

II.2 ETAPES DE CONCEPTION D'UNE BASE DE DONNEES REPARTIE

La mise en place d'une base de données répartie se résume en quatre étapes :

- La conception du schéma globale

- La conception de la fragmentation
- La conception de l'allocation des fragments
- La conception de base de données physique locale dans chaque site

III LA CONCEPTION DU SCHEMA GLOBALE

III.1 POURQUOI ?

Dans une entreprise, privée ou publique, les bases de données réparties ou distribuées
(distributed data bases, en anglais) permettent de réaliser des applications qui nécessitent le
stockage, la maintenance et le traitement des données en plusieurs endroits différents.

Une base de données est décentralisée ou répartie lorsqu'elle est modélisée par un seul
schéma logique de base de données, mais implémentée dans plusieurs fragments de tables
physiques sur des ordinateurs géographiquement dispersés.

L'utilisateur d'une base de données répartie se focalise sur sa vue logique des données et n'a
pas besoin de se préoccuper des fragments physiques.

25
C'est le système de bases de données qui se charge lui-même d'exécuter les opérations, soit
localement, soit en les distribuant sur plusieurs ordinateurs en cas de besoin.

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

conception d'une base de données car il n'existe pas de méthode miracle pour trouver la
solution optimale.

L'administrateur doit donc prendre des décisions dont l'objectif est de minimiser le nombre de
transferts entre sites, les temps de transfert, le volume de données transférées, les temps
moyens de traitement des requêtes, le nombre de copies de fragments, etc...

III.2 COMPOSITION DU SCHEMA GLOBAL

Le schéma global se subdivise en trois schémas qui sont :

 Le Schéma interne
Le schéma interne décrit l'accès physique aux occurrences des relations, il est constitué de
l'ensemble des descriptions des fichiers et/ou par un ensemble des Schémas de relations
internes. 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).

 Le Schéma conceptuel
Le schéma conceptuel est l'ensemble des schémas des relations de base et l'ensemble des
contraintes d'intégrités, c'est la vue globale de la base de données.

Le schéma conceptuel est composé de relations fragmentées ou d'une relation composée d'une
ou de plusieurs sous-relations, la distinction de deux approches dans sa mise en œuvre.

 Le Schéma Externe
Les schémas externes (vues) sont distribués aux utilisateurs sur leurs sites, les sites
utilisateurs.

26
Tous les schémas doivent être concernés par la répartition pour que l'on puisse parler
d'une vrai BD répartie.

III.3 APPROCHE DE CONCEPTION

On distingue deux principales approches de conception : la conception ascendante et la

conception descendante.

III.3.1 LA CONCEPTION DESCENDANTE (TOP DOWN DESIGN)

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

La répartition se fait donc en deux étapes, en première étape la fragmentation, et en deuxième

étape l’allocation de ces fragments aux sites. L’approche top down est intéressante quand on
part du néant.

L'approche descendante permet de maitriser la complexité de la répartition (fragmentation,

duplication, placement) et la définition des schémas locaux à partir du schéma global.

27
III.3.2 LA 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. Si
les BDs existent déjà la méthode bottom up est utilisée.

La différence la plus importante avec l'approche descendante précédente est que la

fragmentation est conditionnée par la structure des fragments. On rencontre deux problèmes
importants, celui de duplication partielle de n-uplets et celui des valeurs indéfinies des
certains attributs.

IV LA FRAGMENTATION

IV.1 DEFINITION

La fragmentation est un processus de décomposition d'une base de données logique en un

ensemble de « sous » base de données logiques appelées « fragments », donc d'un schéma

28
global en un ensemble des schémas locaux sans perte d'informations c'est-à-dire qu'on peut
recomposer le schéma conceptuel global en partant des schémas conceptuels locaux.

Cette décomposition doit évidemment être sans perte d'information pour être acceptable.

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. D'où, il faudra affiner
la fragmentation en produisant des fragments plus petits.

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

IV.3 LES REGLES DE LA FRAGMENTATION

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

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

IV.4 LES TYPES DE FRAGMENTATION

IV.4.1 LA FRAGMENTATION HORIZONTALE

La fragmentation horizontale consiste à partitionner les n-uplets d'une relation globale en des
sous-ensembles. Une relation globale est fragmentée horizontalement lorsqu'elle est formée

29
par l'union des fragments des relations locales qui peuvent être considérés comme des
restrictions de la relation globale.

- L'opération de partitionnement est la sélection.

- L'opération de recomposition est l'union.

 Fragmentation horizontale dérivée

IV.4.2 FRAGMENTATION VERTICALE

30
La fragmentation verticale est la subdivision de certains attributs de la relation globale en
groupe. Les fragments sont obtenus par projection de la relation globale sur chaque groupe,
donc une relation globale est fragmentée verticalement quand elle est formée par une
composition de plusieurs relations locales.

La fragmentation verticale est utile pour distribuer les parties des données sur les sites ou
chacune de ces parties est utilisée.

- L'opération de partitionnement est la projection

- L'opération de recomposition est la jointure

IV.4.3 FRAGMENTATION MIXTE

La fragmentation mixte est la combinaison de deux fragmentations précédentes, dont

l'opérateur de partitionnement est la combinaison de la projection et de la sélection et celui de
la recomposition, la combinaison de la jointure et de l'union.

31
IV.5 MISE A JOURS DES BDDR

La principale difficulté réside dans le fait qu'une mise à jour dans une relation du schéma
global se traduit par plusieurs mises à jour dans différents fragments.

Il faut donc identifier les fragments concernés par l'opération de mise à jour, puis décomposer
en conséquence l'opération en un ensemble d'opération de mise à jour sur ces fragments.

 Insertion
Retrouver le fragment horizontal concerné en utilisant les conditions qui définissent les
fragments horizontaux, puis insertion du tuple dans tous les fragments verticaux
correspondants.

 Suppression
Rechercher le tuple dans les fragments qui sont susceptibles de contenir le tuple concerné, et
supprimer les valeurs d'attribut du tuple dans tous les fragments verticaux.

 Modification
Rechercher les tuples, les modifier et les déplacer vers les bons fragments si nécessaires.

V ALLOCATION DES FRAGMENTS

V.1 DEFINITION

32
L'allocation des fragments est une méthode qui permet d'affecter les fragments sur les sites
donnés en fonction de l'origine (sites d'émission) des requêtes enfin de minimiser les
transferts des données entre les sites.

L'allocation peut se faire de deux manières, l'allocation sans réplication et l'allocation avec
réplication.

V.2 ALLOCATION SANS REPLICATION

L'allocation sans réplication est facile à réaliser, il suffit d'associer à chaque allocation une
mesure et à chaque site une meilleure mesure. C'est une solution qui ne tient pas compte de
l'effet naturel, il faut placer un fragment dans un site donné si un autre fragment apparenté est
aussi dans ce site.

V.3 ALLOCATION AVEC REPLICATION

L'allocation avec réplication est réalisée en appliquant l'une de deux méthodes suivantes :

- Déterminer l'ensemble de tous les sites dont l'importance d'allouer une copie est
d'intérêt plus élevé que le coût de transfert puis allouer une copie de fragment à
chaque élément de cet ensemble.
- Déterminer premièrement la solution du problème qui n'est pas la réplication et
introduire progressivement les copies en commençant par celles qui sont plus
avantageuses. Le processus prend fin si aucune réplication additionnelle n'est
avantageuse.
L'allocation avec réplication favorise les performances des requêtes et la disponibilité de
données.

V.4 TECHNIQUE DE REPARTITION AVANCEE

Dans le cas où la méthode classique d'allocation des fragments ne s'avèrent pas satisfaisante,
des techniques plus puissantes mais aussi complexes à mettre en œuvre doivent être
envisagées :

- Allocation avec duplication des fragments

- Allocation dynamique des fragments
- Fragmentation dynamique
- Clichés

33
V.4.1 ALLOCATION AVEC DUPLICATION

Certains fragments peuvent être dupliqués sur plusieurs sites (éventuellement sur tous les
sites) ce qui procure l'avantage d'améliorer les performances en termes de temps d'exécution
des requêtes (en évitant certains transferts de données). Elle permet aussi une meilleure
disponibilité des informations (connues de plusieurs sites), et une meilleure fiabilité contre les
pannes. Par contre, l'inconvénient majeur est que les mises à jour doivent être effectuées sur
toutes les copies d'une même donnée. En conséquence, moins un fragment est sujet à des
modifications, plus il est prédisposé à la duplication.

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

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

V.4.4 CLICHES

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 d'un cliché diminue donc au fur et à mesure que le temps passe. L'utilisation des
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 peu anciennes et non à
jours seraient largement suffisantes.

VI GESTION DES TRANSACTIONS REPARTIES

34
VI.1 DEFINITION

En bases de données, le concept de transaction est fondamental pour maintenir la cohérence

des données. Une transaction est une unité de mise à jour composée de plusieurs opérations
successives qui doivent être toutes exécutées ou pas du tout. Le SGBD doit garantir les
fameuses propriétés ACID des transactions.

VI.2 OPERATIONS DE NATURE TRANSACTIONNEL DANS LES SGBD

Un modèle simplifié de SGBD se compose de programmes utilisateurs, d’un système et de

mémoires secondaires. Les programmes accèdent aux données au moyen d’opérations du
SGBD (Select, Insert, Update, Delete), généralement en SQL. Ces opérations déclenchent
des actions de lecture et écriture sur disques (Read, Write), qui sont exécutées par le
système, et qui conduisent à des entrées-sorties sur les mémoires secondaires. Afin de
pouvoir déterminer les parties de programmes correctement exécutées, le concept de
transaction a été proposé depuis longtemps.

- Une transaction est un ensemble d’opérations menées sur une BD ;

- Ces opérations peuvent être en lecture et/ou écriture ;
- Une opération est atomique, c’est donc une unité indivisible de traitement
- Une transaction est soit validée par un commit, soit annulée par un rollback, soit
interrompue par un abort,
- Une transaction a une marque de début (Begin Of Transaction BOT), et une marque de
fin (End Of Transaction EOT).

VI.3 EXEMPLE DE TRANSACTION

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

EXEC SQL UPDATE ComptesEpargne

SET solde = solde – somme
WHERE numClient = numClt ;

EXEC SQL UPDATE ComptesCourant

SET solde = solde + somme
WHERE numClient = numClt ;

VI.4 LES PROPRIETES D’UNE TRANSACTION

35
Une transaction est composée d’une suite de requêtes dépendantes à la base qui doivent
vérifier les propriétés d’atomicité, de cohérence, d’isolation et de durabilité, résumées par le
vocable ACID.

VI.4.1 ATOMICITE

Une transaction doit effectuer toutes ses mises à jour ou ne rien faire du tout. En cas d’échec,
le système doit annuler toutes les modifications qu’elle a engagées. L’atomicité est menacée
par les pannes de programme, du système ou du matériel, et plus généralement par tout
événement susceptible d’interrompre une transaction en cours.

VI.4.2 COHERENCE

La transaction doit faire passer la base de données d’un état cohérent à un autre. En cas
d’échec, l’état cohérent initial doit être restauré. La cohérence de la base peut être violée par
un programme erroné ou un conflit d’accès concurrent entre transactions.

VI.4.3 ISOLATION

Les résultats d’une transaction ne doivent être visibles aux autres transactions qu’une fois la
transaction validée, afin d’éviter les interférences avec les autres transactions. Les accès
concurrents peuvent mettre en question l’isolation.

VI.4.4 DURABILITE

Dès qu’une transaction valide ses modifications, le système doit garantir qu’elles seront
conservées en cas de panne. Le problème essentiel survient en cas de panne, notamment lors
des pannes disques.

VI.5 THEORIE DE LA CONCURRENCE

VI.5.1 OBJECTIFS

L’objectif général est de rendre invisible aux clients le partage simultané des données. Cette
transparence nécessite des contrôles des accès concurrents au sein du SGBD.

Ceux-ci s’effectuent au moyen de protocoles spéciaux permettant de synchroniser les mises à

jour afin d’éviter les pertes de mises à jour et l’apparitions d’incohérences.

36
Les solutions proposées permettent de garantir la cohérence et l’isolation des mises à jour des
transactions (le C et le I de ACID). Elles sont basées sur la théorie de la sérialisabilité des
transactions.

VI.5.2 PROBLEMES A EVITER

VI.5.2.1 PERTE DE MISE A JOUR

Une perte de mise à jour survient lorsqu’une transaction T1 exécute une mise à jour calculée à
partir d’une valeur périmée de donnée, c’est-à-dire d’une valeur modifiée par une autre
transaction T2 depuis la lecture par la transaction T1. La mise à jour de T2 est donc écrasée
par celle de T1. Une perte de mise à jour est illustrée dans la figure ci-dessous. La mise à jour
de la transaction T2 est perdue.

Exemple de perte de mise à jour

VI.5.2.2 INCOHERENCE

Une incohérence apparaît lorsque des données liées par une contrainte d’intégrité sont mises à
jour par deux transactions dans des ordres différents, de sorte à enfreindre la contrainte. Par
exemple, soient deux données A et B devant rester égales. L’exécution de la séquence
d’opérations {T1 : A = A+1 ; T2 : B = B*2 ; T2 : A = A*2; T1: B=B+1} rend en général A
différent de B, du fait de la non-commutativité de l’addition et de la multiplication. Elle
provoque donc l’apparition d’une incohérence.

37
 Exemple d’introduction d’incohérence

VI.5.2.3 NON-REPRODUCTIBILITE DES LECTURES

Un autre problème lié aux accès concurrents est la non-reproductibilité des lectures : deux
lectures d’une même donnée dans une même transaction peuvent conduire à des valeurs
différentes si la donnée est modifiée par une autre transaction entre les deux lectures. Le
problème ne survient pas si les mises à jour sont isolées, c’est-à-dire non visibles par une
autre transaction avant la fin de la transaction. Il en va de même de l’apparition
d’incohérences. Pour les pertes de mise à jour, l’isolation des mises à jour n’est pas suffisante
: il faut aussi ne pas laisser deux transactions modifier simultanément une même donnée.

Exemple de non-reproductibilité des lectures

38
VI.6 LES OPERATIONS SUR GRANULE

VI.6.1 DEFINITION

VI.6.1.1 GRANULE

Pour éviter perte d’opérations, incohérences et non reproductibilité des lectures, le SGBD doit
contrôler l’accès aux données. L’unité de données contrôlée dépend du SGBD. De plus en
plus de SGBD permettent des contrôles variables selon le type de transactions. Nous
appellerons cette unité granule de concurrence ; le terme objet est parfois aussi employé.

Granule de concurrence : Unité de données dont les accès sont contrôlés individuellement
par le SGBD.

Un granule au sens de la concurrence peut être une ligne, une page ou une table dans un
système relationnel. Ce peut être un objet ou une page dans un SGBD objet. Nous discuterons
de la taille du granule de concurrence plus loin.

Les granules de concurrence sont lus et écrits par les utilisateurs, éventuellement par parties.

VI.6.1.2 ACTION

On appelle action un accès élémentaire à un granule. Une action est une Unité indivisible
exécutée par le SGBD sur un granule pour un utilisateur, constituée généralement par une
lecture ou une écriture.

VI.6.1.3 EXECUTION DE TRANSACTIONS (SCHEDULE)

Un système de bases de données exécute donc une suite d’actions résultant de transactions
concurrentes. Après complétude d’un ensemble de transactions (T1, T2…Tn), une histoire du
système peut être représentée par la suite des actions exécutées. Plus généralement, toute suite
d’actions pouvant représenter une histoire possible sera appelée simplement exécution.

Une exécution de transaction est une séquence d’actions obtenues en intercalant les
diverses actions des transactions T1, T2 …Tn tout en respectant l’ordre interne des
actions de chaque transaction.

Une exécution respecte donc l’ordre des actions de chaque transaction participante et est, par
définition, séquentielle. Par exemple, considérons les transactions T1 et T2 de la figure ci-
39
dessous, modifiant les données A et B reliées par la contrainte d’intégrité A = B ; A et B
appartiennent à deux granules distincts, maximisant ainsi les possibilités de concurrence.

Deux transactions T1 et T2

Une exécution correcte de ces deux transactions est représentée dans la figure a ci-dessous.
Une autre exécution est représentée dans la figure b, mais celle-là est inacceptable car elle
conduit à une perte d’opérations.

Deux exécutions des transactions T1 et T2

VI.7 PROPRIETES DES OPERATIONS SUR GRANULE

VI.7.1 NOTION D’OPERATIONS

40
Un granule accédé concurremment obéit à des contraintes d’intégrité internes. Lors des
modifications de la base de données, les granules sont modifiés par des suites d’actions
constituant des unités fonctionnelles appelées opérations. Les opérations respectent la
cohérence interne du granule, c’est-à-dire les contraintes d’intégrité qui relient les données
appartenant au granule.

Une opération est une suite d’actions accomplissant une fonction sur un granule en
respectant sa cohérence interne.

Par exemple, si le granule est la page, les opérations de base sont souvent LIRE (page) et
ECRIRE (page), qui sont également dans bien des systèmes des actions indivisibles.

Si le granule est l’article, des opérations plus globales nécessitant plusieurs actions
indivisibles sont LIRE (article) et ECRIRE (article), mais aussi MODIFIER (article) et
INSERER (article). Avec ces opérations de base, il est possible d’en construire d’autres plus
globales encore. Sur un objet typé, tel un compte en banque, on peut distinguer des
opérations, créer, créditer, débiter, détruire, etc.

VI.7.2 NOTION DE RESULTAT

L’application d’opérations à des granules conduit à des résultats. Le résultat d’une opération
est constitué par l’état du granule concerné après l’application de l’opération considérée et par
les effets de bords qu’elle provoque. Par exemple, le résultat d’une opération LIRE est
représenté par la valeur du tampon récepteur après exécution, alors que le résultat d’une
transaction modifiant une base de données est l’état des granules modifiés après exécution
ainsi que la valeur des messages édités.

VI.7.3 OPERATIONS COMPATIBLES

Les opérations sont enchevêtrées au niveau des actions lors de l’exécution simultanée de
transactions. Deux opérations qui ne modifient aucun granule et qui appartiennent à deux
transactions différentes peuvent être enchevêtrées de manière quelconque sans modifier les
résultats de leur exécution. Autrement dit, toute intercalation d’opérations n’effectuant que
des lectures conduit à des résultats identiques à une exécution successive de ces opérations.
Plus généralement, il est possible de définir la notion d’opérations compatibles.

41
Opérations compatibles : Opérations 0i et 0j dont toute exécution simultanée donne le
même résultat qu’une exécution séquentielle 0i suivie de 0j ou de 0j suivie de 0i (à noter que
les résultats 0i puis 0j, et 0j puis 0i peuvent être différents).

Considérons par exemple les opérations représentées ci-dessus. Les opérations O11 et O21
sont compatibles ; O11 et O12 ne le sont pas.

Il est important de remarquer que deux opérations travaillent sur deux granules différents sont
toujours compatibles. En effet, dans ce cas aucune perte d’opérations ne peut survenir si l’on
intercale les opérations. Or il est simple de voir que deux opérations sont incompatibles
lorsque qu’il existe une possibilité d’intercalation générant une perte d’opérations.

VI.7.4 OPERATIONS PERMUTABLES

Les problèmes surviennent avec les opérations incompatibles, lorsqu’une au moins modifie un
granule auquel l’autre a accédé. L’ordre d’exécution des deux opérations peut alors changer
les résultats. Dans d’autres cas, il peut être indifférent. Plus généralement, nous définirons la
notion d’opérations permutables, qu’il faut bien distinguer de celle d’opérations compatibles
(la première est une notion indépendante de l’ordre d’exécution, alors que la seconde est
définie à partir de la comparaison des ordres d’exécution).

Opérations permutables : Opérations 0i et 0j telles que toute exécution de 0i suivie par 0j

donne le même résultat que celle de 0j suivie par 0i.

Par exemple, les opérations O11 et O31 représentées par la figure ci-dessus sont permutables
alors que les opérations O11 et O12 ne le sont pas. Soulignons que deux opérations travaillant

42
sur des granules différents sont toujours permutables. En effet, dans ce cas, l’exécution de la
première ne peut modifier le résultat de la seconde et réciproquement.

Plus généralement, deux opérations compatibles sont permutables, mais la réciproque n’est
pas vraie.

VI.8 CARACTERISATION DES EXECUTIONS CORRECTES

VI.8.1 SUCCESSION (SERIAL SCHEDULE)

Certaines exécutions introduisent des pertes d’opérations ou des inconsistances, comme nous
l’avons vu ci-dessus. L’objectif du contrôle de concurrence consiste à ne laisser s’exécuter
que des exécutions sans pertes d’opérations ou inconsistances. Il est bien connu que
l’exécution successive de transactions (sans simultanéité entre transactions) est un cas
particulier d’exécution sans perte d’opérations ni inconsistances.

Une telle exécution est appelée succession et peut être définie plus formellement comme suit :

Exécution E d’un ensemble de transactions {T1, T2…Tn} telle qu’il existe une permutation π
de (1,2…n) telle que : E = < T π(1) ; Tπ(2) ; …T π(n) >

VI.8.2 EXECUTION SERIALISABLE (SERIALISABLE SCHEDULE)

Afin d’assurer l’absence de conflit, il est simple de ne tolérer que les exécutions qui donnent
le même résultat qu’une succession pour chaque transaction. De telles exécutions sont
dites sérialisables :

Exécution sérialisables :

Exécution E d’un ensemble de transactions {T1, T2…Tn} donnant globalement et pour

chaque transaction participante le même résultat qu’une succession de (T1, T2…Tn).

Trouver une exécution qui donne le même résultat qu’une succession.

Le problème du contrôle de concurrence est donc d’assurer qu’un système reparti (ou
centralisé) ne peut générer que des exécutions sérialisables.

Afin de caractériser les exécutions sérialisables, nous introduisons deux transformations de

base d’une exécution de transactions. Tout d’abord, la séparation d’opérations compatibles Oi

43
et Oj exécutées par des transactions différentes consiste à remplacer une exécution simultanée
des opérations E (Oi, Oj) par la séquence donnant le même résultat, soit < Oi ; Oj > ou < Oj ;
Oi >. La séparation d’opérations permet donc de mettre en succession des opérations
compatibles exécutées par des transactions différentes.

Ensuite, la permutation d’opérations permutables Oi et Oj exécutées par des transactions

différentes consiste à changer l’ordre d’exécution de ces opérations ; par exemple la séquence
< Oi ; Oj > est remplacée par la séquence < Oj ; Oi >.

Une condition suffisante pour qu’une exécution soit sérialisable est qu’elle puisse être
transformée par séparation des opérations compatibles et permutations des opérations
permutables en une succession des transactions composantes. En effet, par définition,
séparations et permutations conservent les résultats. Par suite, si l’exécution peut être
transformée en une succession, elle donne le même résultat que cette succession pour chaque
transaction et est donc sérialisable. La condition n’est pas nécessaire car, au moins pour
certaines valeurs des données, des opérations incompatibles ou non permutables peuvent être
exécutées simultanément sans conflits.

À titre d’exemple, considérons l’exécution représentée figure a. En représentant seulement

globalement les opérations, cette exécution s’écrit :

T1 : A + 1→ A

T2 : A * 2 → A

T1 : B + 1 → B

T2 : B * 2 → B

Les opérations A *2 → A et B + 1 → B sont permutables car elles agissent sur des granules
différents. Par suite, cette exécution peut être transformée en :

T1 : A + 1 → A

T1 : B + 1 → B

T2 : A * 2 → A

T2 : B * 2 → B

44
qui est une succession de T1 puis T2. Par suite, l’exécution figure a est sérialisable.

Resumé

 Opérations compatibles
- Oi et Oj, 2 opérations. Toute exécution simultanée donne le même résultat qu'une
exécution séquentielle Eij= Oi suivie de Oj ou de Eji=Oj suivie de Oi. Les résultats de
Eij et Eji peuvent être différents.
- O1 et O2 sont compatibles, pas O1 et O3.

 Opérations permutables
- Oi et Oj, 2 operations. Toute execution de Oi suivie de Oj donne le meme resultat que
celle de Oj suivie de Oi.
- O1 et O3 ne sont pas permutables.
- O1 et O4 sont permutables.

 Opérations compatibles/permutables
- 2 opérations travaillant sur 2 granules différents sont toujours compatibles.
- 2 opérations travaillant sur 2 granules différents sont toujours permutables.
- 2 opérations compatibles sont permutables, mais la réciproque n'est pas vraie.
 Sérialisation des transactions
- L'état final d'une BD après exécutions en parallèle de transactions doit être identique à
une exécution en série des transactions.
- L'exécution de transactions entremêlées est correcte si elle est équivalente à une
exécution des mêmes transactions en série
- Pour caractériser la sérialisation, 2 transformations sont introduites:

45
 o Séparation d'opérations compatibles : Ex: exécution simultanée de Oi,Oj
devient une séquence Oi;Oj ou Oj;Oi.
o Permutation d'opérations permutables Oi et Oj exécutées par des transactions
différentes consiste à changer l'ordre de l'exécution.
- Condition suffisante pour qu'une exécution soit sérialisable: possibilité de
transformation par séparation des opérations compatibles et permutations des
opérations permutables en une succession de transactions.

VI.9 CONTROLE DE CONCURRENCE

VI.9.1 PRINCIPE DE BASE

Le contrôle de concurrence est un mécanisme du SGBDR, 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é. Une exécution d’un ensemble de transactions est dite
sérialisable si elle donne pour chaque transaction participante, le même résultat que
l’exécution en séquentiel de ces mêmes transactions.

Deux méthodes sont utilisées pour forcer la sérialisabilité :

- Verrouillage
- Estampillage

46
VI.9.2 LES MECANISMES UTILISES

VI.9.2.1 LES ESTAMPILLES

Les estampilles permettent d’installer un ordre total entre les actions, et ainsi de les sérialiser.
L’estampille est donc un identifiant unique des transactions qui permet en plus de les
ordonner.

Chaque transaction est repérée par un numéro d’ordre unique dans le système. L’estampille
est le couple (valeur compteur : horloge locale, numéro du site).

L’inconvénient majeur est la difficulté de synchroniser des sites de différentes horloges.

VI.9.2.2 LE VERROUILLAGE

La technique la plus répandue pour sérialiser les transactions est basée sur l’utilisation de
verrous. On impose que l’accès aux données se fasse de manière mutuellement exclusive.

VI.9.3 NOTION D’INTERBLOCAGES

Toute méthode basée sur le verrouillage peut donner des interblocages lorsque deux
transactions s'entre-attendent. Pour illustrer ce cas, on peut prendre un exemple. Une
transaction Ti détient un verrou en lecture ou en écriture sur la donnée x. Une transaction Tj
détient un verrou en lecture ou en écriture sur la donnée y. La transaction Ti attend un verrou
en écriture sur la donnée y et la transaction Tj attend un verrou en écriture sur la donnée x. Il y
a dans ce cas un interblocage.

Un outil de grande utilité dans l'analyse des interblocages est le graphe des attentes. Les
noeuds du graphe des attentes sont des transactions simultanées et les arcs orientés qui les
relient représentent l'attente d'une transaction pour une autre. Grâce à cette représentation, il
est facile de caractériser les interblocages : ce sont les cycles sur le graphe. Dans un
environnement réparti, les interblocages peuvent mettre en jeu différents sites. Le graphe des
attentes local est donc insuffisant et il faut également en maintenir un au niveau global.

47
La solution est d’annuler des transactions concurrentes jusqu'à suppression de cycles, et de les
reprendre plus tard.

48
PARTIE III : MISE EN ŒUVRE D'UNE

BD REPARTIE

49
I LE SGBD ORACLE

I.1 PRESENTATION

Oracle a établi sa réputation comme serveur de données, sur de multiples plates-

formes(windows, linux …).
Le SGBD Oracle permet un réel fonctionnement en mode client-serveur, ce qui fait de lui une
plate-forme privilégiée pour le déploiement de base de données reparties.

I.2 CONNEXION AU SERVEUR ORACLE

Pour se connecter au SGBD Oracle, il faut fournir trois paramètres:

- Le nom d'utilisateur
- Le mot de passe
- L'alias qui renseigne sur plusieurs données à la fois:
o Le protocole réseau utilisé pour accéder à la machine cible,
o Le nom ou l'adresse de la machine cible sur laquelle se situe le serveur,
o Le SID cible ou le nom global de la base,
o Le port d'écoute du serveur.

I.3 LE PROCESSUS D'ECOUTE ORACLE (LISTNER)

Le processus d'écoute Oracle est un service permettant à des clients d'utiliser le protocole TCP
pour accéder une base de données distante. Le fichier de configuration du LISTENR se trouve
dans $ORACLE_HOME/Network/Admin/ et senomme «listener.ora». Dans cefichier on peut
configurer: le nom de la machine (HOST), le port (par défaut est 1521) et le nom du service
d’écoute (DEFAULT_SERVICE_LISTENER).

50
I.4 LE TNS

Le TNS (Transparent Network Substrate) est une sous-couche d’Oracle Net qui reçoit les
requêtes et émet des ouvertures ou fermetures de session, envoie les requêtes et reçoit des
réponses.

I.5 LES LIENS DE BASE DE DONNEES

Pour interroger une BD distante, il faut créer un lien de base de données.

Un lien de base de données est un chemin unidirectionnel d’un serveur à un autre. En effet, un
client connecté à une BD A, peut utiliser un lien stocké dans la BD A pour accéder à la BD
distante B, mais les utilisateurs connectés à B ne peuvent pas utiliser le même lien pour
accéder aux données sur A.
Lorsqu’un lien est référencé par une instruction SQL, Oracle ouvre une session dans la base
distante et y exécute l’instruction. La session demeure ouverte au cas où elle serait de
nouveau nécessaire.
En créant un lien de BD, on doit indiquer le nom du compte auquel on se connecte, le mot de
passe de ce compte, et le nom de service associé à la base distante. En l’absence d’un nom de

51
compte, Oracle utilise le nom et le mot de passe du compte local pour la connexion à la base
distante.

I.6 MECANISME DE TRANSPARENCE

Après avoir créé les liens de bases de données, plusieurs objets : les vues, les synonymes , les
déclencheurs et les procédures stockées, peuvent servir à cacher la distribution des données
aux utilisateurs

I.6.1 LES VUES

Les vues peuvent fournir une transparence par rapport aux tables locales et distantes. Par
exemple, supposons que la table Employé est sur une BD locale et la table Département est
sur une BD distante. Pour rendre ces tables transparentes aux utilisateurs. Nous pouvons créer
une vue dans la BD locale qui fait la jointure des données locales et distantes, comme ci-
dessous : Les utilisateurs accédant à cette vue n’ont pas besoin de savoir où les données sont
stockées.

I.6.2 LES SYNONYMES

Les synonymes sont des noms simples qui permettent d’identifier de façon unique dans un
système distribué les objets qu’ils nomment. Les synonymes peuvent être, crées pour
différents objets : Tables, Types, Views, Snapshots, Procedures, Functions, Packages. Ils
figurent dans le dictionnaire de données.

I.6.3 LES PROCEDURES

Les unités de programmes PL/SQL, peuvent servir à référer à des données distantes, appeler
des procédures distantes, utiliser des synonymes pour référer à des procédures distantes.

I.6.4 LES DECLENCHEURS (TRIGGERS)

II TECHNIQUE DE REPARTITION

II.1 PREALABLES

Dans un SGBDRéP, on suppose que les données soient stockées sur au moins deux sites.
Dans notre exemple , nous allons utiliser au moins deux ordinateurs (on peut utiliser un

52
ordinateur et une machine virtuelle) avec Oracle installé sur chacun. Les deux ordinateurs
utilisés doivent être reliés grâce à un réseau TCP/IP.

II.2 PRINCIPES DE SECURITE

- Ne pas travailler avec les véritables comptes propriétaires des données ;

- Chaque site distant doit créer un compte ayant accès aux objets répartis locaux ;
- Ces comptes miroir sont créés par le DBA et reçoivent les droits d’accès par les
propriétaires des données réparties ;
- Chaque responsable local de la BDR ne connaît que le password des comptes miroir
distants.

53