Escolar Documentos
Profissional Documentos
Cultura Documentos
1. INTRODUCTION.................................................................................................................................................
2. QU’ESTCEQU’UNE BDR ?.............................................................................................................................
2.1 DÉFINITION ET EXEMPLE........................................................................................................................................
2.2 SCHÉMA GLOBAL...................................................................................................................................................
2.3 QUELQUES DÉFINITIONS DE BASE...........................................................................................................................
2.4 QUELQUES DÉFINITIONS COMPLÉMENTAIRES.........................................................................................................
2.5 EXEMPLE DE BD FÉDÉRÉES...................................................................................................................................
2.6 AVANTAGES ET INCONVÉNIENTS............................................................................................................................
3. OBJECTIFS DES SGBDR...................................................................................................................................
3.1 MULTICLIENTS MULTISERVEURS.........................................................................................................................
3.2 TRANSPARENCE À LA LOCALISATION DES DONNÉES..............................................................................................
3.3 MEILLEURE DISPONIBILITÉ.....................................................................................................................................
3.4 AUTONOMIE LOCALE..............................................................................................................................................
3.5 HÉTÉROGÉNÉITÉ....................................................................................................................................................
4. ARCHITECTURE DES SGBDR........................................................................................................................
4.1 FONCTIONS D’UN SGBDR.....................................................................................................................................
4.2 ORGANISATION DES SCHÉMAS...............................................................................................................................
4.3 ARCHITECTURE DE RÉFÉRENCE..............................................................................................................................
4.4 GÉNÉRATIONS DE PROTOTYPES..............................................................................................................................
5. CONCEPTION DES BDR...................................................................................................................................
5.1 CONCEPTION ASCENDANTE OU DESCENDANTE.......................................................................................................
5.2 TECHNIQUES DE FRAGMENTATION.........................................................................................................................
5.3 EXTENSION DE LA FRAGMENTATION HORIZONTALE...............................................................................................
5.4 FRAGMENTATION MIXTE........................................................................................................................................
5.5 ALLOCATION DES FRAGMENTS...............................................................................................................................
5.6 ALLOCATION OPTIMALE.........................................................................................................................................
6. GESTION DE TRANSACTIONS.......................................................................................................................
6.1 PROPRIÉTÉS DES TRANSACTIONS............................................................................................................................
6.2 VALIDATION EN DEUX PHASES...............................................................................................................................
6.2.1 Principe.........................................................................................................................................................
6.2.2 Protocole C/S................................................................................................................................................
6.2.3 Commit distribué ou centralisé.....................................................................................................................
6.2.4 Actions du Protocole.....................................................................................................................................
6.3 COMMIT EN TROIS PHASES.....................................................................................................................................
6.4 PROTOCOLE ARBORESCENT TP..............................................................................................................................
6.5 BILAN SUR LA GESTION DE TRANSACTIONS...........................................................................................................
7. MONITEURS TRANSACTIONNELS...............................................................................................................
7.1 LES OBJECTIFS........................................................................................................................................................
7.2 MODÈLE DE MONITEUR TRANSACTIONNEL.............................................................................................................
7.3 INTERFACE APPLICATIVE TX.................................................................................................................................
7.4 L’INTERFACE APPLICATIVE TX SE COMPOSE DES PRIMITIVES SUIVANTES :...........................................................
7.5 INTERFACE RESSOURCE XA...................................................................................................................................
7.6 PRINCIPAUX MONITEURS........................................................................................................................................
8. CONTRÔLE DE CONCURRENCE..................................................................................................................
8.1 OBJECTIFS..............................................................................................................................................................
8.2 LA THÉORIE DE BASE.............................................................................................................................................
8.3 LE VERROUILLAGE DEUX PHASES...........................................................................................................................
8.4 DEGRÉ D'ISOLATION EN SQL2...............................................................................................................................
8.5 PROBLÈMES DE CONTRÔLE DU VERROUILLAGE EN RÉPARTI..................................................................................
8.6 LES SOLUTIONS AU PROBLÈME DU VERROU MORTEL.............................................................................................
8.6.1 Prévention du verrou mortel.........................................................................................................................
8.6.2 Détection du verrou mortel...........................................................................................................................
8.7 ORDONNANCEMENT PAR ESTAMPILLAGE...............................................................................................................
8.8 CERTIFICATION OPTIMISTE.....................................................................................................................................
8.9 BILAN SUR LA CONCURRENCE................................................................................................................................
9. RÉPLICATION DANS LES BD RÉPARTIES.................................................................................................
9.1 RÉPLICATION : AVANTAGES ET PROBLÈMES...........................................................................................................
9.2 MISE À JOUR SYNCHRONE ET ASYNCHRONE...........................................................................................................
9.3 TECHNIQUES DE DIFFUSION DES MISES À JOUR......................................................................................................
9.4 RÉPLICATION ASYMÉTRIQUE..................................................................................................................................
9.5 RÉPLICATION SYMÉTRIQUE....................................................................................................................................
9.6 CONVERGENCE DE COPIES SYMÉTRIQUES..............................................................................................................
9.7 PROBLÈMES DE FIABILITÉ ET REPRISE....................................................................................................................
9.8 COPIES DÉRIVÉES ET CLICHÉS................................................................................................................................
10. OPTIMISATION DES REQUÊTES RÉPARTIES........................................................................................
10.1 OBJECTIFS DE L’OPTIMISATION............................................................................................................................
10.2 FONCTION DE COÛT À OPTIMISER.........................................................................................................................
10.3 DÉCOMPOSITION ET OPTIMISATION ÉLÉMENTAIRE DES REQUÊTES.......................................................................
10.4 LOCALISATION DES DONNÉES..............................................................................................................................
10.5 ALGORITHME ÉLÉMENTAIRE................................................................................................................................
10.6 OPTIMISATIONS POSSIBLES...................................................................................................................................
10.7 ALGORITHMES DE SSD1.....................................................................................................................................
10.8 ALGORITHME DE R*............................................................................................................................................
11. CONCLUSION ET PERSPECTIVES..............................................................................................................
12. RÉFÉRENCES ET BIBLIOGRAPHIE...........................................................................................................
Chapitre V
RƒPLIQUƒES
Ç Distributed database systems technoology is one of the major recent developments in the
database system area. There are claims that in the next ten years centralized database managers
will be an Ç antique curiosity È and most organizations will move toward distributed database
managers. È
in […zsu91].
V.1.INTRODUCTION
Les systmes de gestion de bases de donnŽes rŽparties ont ŽtŽ inventŽs ˆ la fin des
annŽes 70 afin d’intŽgrer les bases de donnŽes et les rŽseaux. Le premier grand projet
fut SDD1 [Rothnie80] lancŽ en 1976 pour gŽrer des donnŽes embarquŽes sur les bateaux
rŽseau national, fut lancŽ le projet Sirius [Litwin82] ds 1977. Dans la mme pŽriode a ŽtŽ
lancŽ le projet Ingres/Star ˆ Berkeley [Stonebraker77], puis un peu plus tard le projet R*
projets ont en gŽnŽral abouti ˆ des produits dont les reprŽsentants sont aujourd’hui les
versions distribuŽes de Oracle, Ingres ou Sybase. Au milieu des annŽes 80, l’intŽrt des
chercheurs s’est dŽplacŽ vers les systmes hŽtŽrognes, avec par exemple Multibase
nouvelle gŽnŽration de systmes basŽs sur le modle objet et une coopŽration plus l‰che
La fŽdŽration de bases de donnŽes existantes est une nŽcessitŽ pour un grand nombre
de faciliter les dŽveloppements pour l’utilisateur. Avec les grands rŽseaux internationaux
rŽparties — dont un des aboutissement est dŽjˆ le client-serveur — a donc encore un bel
avenir.
Dans ce chapitre, nous apportons une synthse des techniques connues et implŽmentŽes
dans les systmes d’aujourd’hui. Nous prŽcisons dans la section 2 ce qu’est une base de
donnŽes rŽparties et dŽfinissons les diffŽrents termes qualifiant souvent des variantes.
La section 3 est centrŽe sur les objectifs des SGBD rŽpartis ; elle mne naturellement ˆ la
section 4 qui introduit une architecture type de systme. La section 5 aborde les problmes
protocoles de validation en deux et trois Žtapes sont dŽcrits. Cette section conduit ˆ
systmes rŽpartis. Puis, la section 9 aborde les mŽthodes de rŽplication l‰che qui sont
par la section 10 — qui prŽcde bien sžr la conclusion Žtablissant un bilan et Žvoquant les
et R*.
V.2.QU’EST-CE-QU’UNE BDR ?
Dans cette section, nous prŽcisons et illustrons le concept de base de donnŽes rŽpartie
donnŽes.
2.1DŽfinition et exemple
Une base de donnŽes rŽpartie permet de rassembler des ensembles de donnŽes plus ou
moins hŽtŽrognes, dissŽminŽs dans un rŽseau d’ordinateurs, sous forme d’une base de
donnŽes globale, homogne et intŽgrŽe. Une dŽfinition classique est donnŽe ci-dessous.
Une base de donnŽes rŽpartie peut aussi tre vue comme une collection de bases de
prŽcŽdente est plus complte, car elle insiste sur le fait que la base rŽpartie doit
Chaque ordinateur est muni d’un SGBD, supposŽ relationnel pour simplifier. L’ensemble
est utilisŽ pour gŽrer une coopŽrative vinicole, afin de gŽrer les commandes des clients,
appelŽs pour l’exemple buveurs. Les vins sont produits par des producteurs ˆ Dijon
(rŽgion Bourgogne) et ˆ Bordeaux (rŽgion Bordelais). Les commandes sont passŽes par
les buveurs depuis Paris aux producteurs. La figure 1 illustre une rŽpartition possible des
donnŽes.
Comme toute base de donnŽes, une base de donnŽes rŽpartie possde un schŽma appelŽ
schŽma global qui permet de dŽfinir l’ensemble des types de donnŽes de la base. Par
dessus est dŽfini figure 2. Il s’agit d’une vision relationnelle de la base. Une vision plus
conceptuel. Dans une base de donnŽes rŽpartie, le schŽma global ou conceptuel n’est
pas forcŽment matŽrialisŽ. Chaque base locale implŽmente une partie. Ces parties
Nous prŽcisons maintenant les composants essentiels nŽcessaires pour gŽrer des bases
(SGBDR) cache aux applications l’existence de multiples bases. Il fournit aux clients du
SGBDR l’illusion que l’ensemble des bases gŽrŽes par les serveurs du SGBDR est
Application qui accde aux informations distribuŽes par les interfaces du SGBDR.
SGBD gŽrant une base de donnŽes locale intŽgrŽe dans une base de donnŽes
rŽpartie.
Au-delˆ des notions de client de SGBDR et de serveur, un calculateur gŽrant la base est
appelŽ noeud ou site. Un site peut tre ˆ la fois client et serveur du SGBDR : il exŽcute
des applications et gre une partie de la base. C’est sans doute le cas le plus frŽquent.
En rŽsumŽ, un SGBDR est donc un ensemble de logiciels systmes gŽrant des donnŽes
rŽparties sur un ensemble de sites, intŽgrant des modules clients et des modules
serveurs. Clients et serveurs collaborent bien sžr par des mŽdiateurs spŽcifiques.
d’une base de donnŽes rŽparties est une forme ultime de coopŽration qui nŽcessite
l’intŽgration des bases. Il est possible de faire coopŽrer des bases de donnŽes sans les
intŽgrer. Des bases de donnŽes capables d’Žchanger des donnŽes sont dites
c’est-ˆ-dire gŽrŽes avec un mme modle et accŽdŽes par un mme langage, ou de nature
rŽpartie gŽrŽe par des SGBD identiques localisŽs sur des sites diffŽrents. Le degrŽ
d’hŽtŽrogŽnŽitŽ d’une base de donnŽes rŽpartie peut donc varier, selon que les SGBD
serveurs sont diffŽrents mais basŽs sur le mme modle, ou basŽ sur des modles
diffŽrents.
Les bases de donnŽes rŽparties hŽtŽrognes sont un sujet d’Žtude intŽressant, aussi bien
du point de vue des concepts que du point de vue des applications, particulirement afin
de faire coopŽrer des bases de donnŽes existantes. Le degrŽ d’intŽgration des bases de
Par opposition, et afin de souligner le plus fort degrŽ d’intŽgration, des bases de
donnŽes sont dites fŽdŽrŽes lorsqu’elles sont perues par le client comme une base de
donnŽes unique, via un modle et un langage commun. Les bases sont alors fortement
couplŽes.
Notion 8 : BD fŽdŽrŽe (Federated database)
Plusieurs bases de donnŽes hŽtŽrognes accŽdŽes comme une seule via une vue
commune (un modle commun).
2.5Exemple de BD fŽdŽrŽes
figure 4 un exemple de rŽseau typique des besoins actuels des entreprises. Il existe en
effet souvent des bases de donnŽes traditionnelles, construites selon le modle relationnel
lŽgataire car hŽritŽ du passŽ (legacy system). Il peut aussi exister des bases de donnŽes
techniques dŽcrivant les produits fabriquŽs et leurs composants, des bases de donnŽes
textuelles contenant par exemple les manuels d’opŽrations, et des bases de donnŽes
gŽographiques contenant la localisation des usines et des clients. Le problme qui se pose
est de faire collaborer toutes ces bases construites avec des systmes, des modles et des
langages diffŽrents. Selon que l’on fournit seulement un langage d’accs commun, ou que
l’on donne une vision globale unifiŽe, on parlera de multibase ou de base fŽdŽrŽe.
2.6Avantages et inconvŽnients
rŽparties ;
suite ;
Tout ceci conduit les utilisateurs ˆ prŽfŽrer les solutions multibases aux solutions bases
Dans cette section, nous prŽcisons les objectifs des SGBDR qui se rŽsument aux aspects
clŽs suivants :
· multi-clients multi-serveurs ;
3.1Multi-clients multi-serveurs
serveur. La requte, appelŽe requte distante, peut par exemple tre exprimŽe en SQL.
Bien sžr, un SGBDR doit permettre l’accs simultanŽ de plusieurs clients aux donnŽes.
Pour assurer l’objectif multi-clients, le SGBDR doit fournir des mŽcanismes de contr™le
transactions est le mme que celui d’une exŽcution sŽquentielle : cette propriŽtŽ est
appelŽe la sŽrialisabilitŽ des transactions. Nous lui consacreront une section ci-
dessous.
plusieurs serveurs.
Une transaction qui met en Ïuvre plusieurs serveurs est appelŽe transaction distribuŽe.
requtes distantes, chacune Žtant exŽcutŽe par un serveur diffŽrent. Souvent, une
Un des objectifs clŽ des SGBDR est de permettre d’Žcrire des programmes d’application
sans conna”tre la localisation physique des donnŽes. Dans ce but, les noms des objets
(par exemple le nom des tables) doivent tre indŽpendants de leurs localisations. Les
requtes seront en gŽnŽral exprimŽes en SQL de manire similaire aux requtes locales.
Elles rŽfŽrenceront des vues de la base rŽpartie ; ces vues porteront un nom ne
PropriŽtŽ d’un SGBDR permettant d’Žcrire des requtes avec des noms d’objets
rŽfŽrencŽs (les tables en relationnel) ne contenant pas la localisation des donnŽes.
les objets (par exemple les tables) sans modifier les requtes. Par exemple, sur la base de
donnŽes rŽpartie dont le schŽma global a ŽtŽ dŽfini figure 2, on exprimera la question
Ç Noms et prŽnoms des buveurs parisiens ayant passŽ une commande de Volnay de
degrŽ ³ 12 en quantitŽ supŽrieure ˆ 100 depuis le 1er Janvier 1992 È comme suit :
2WHERE CRU = 'VOLNAY' AND DEGRE > 12 AND C. QTŽ > 100
et ceci quelle que soit la localisation des tables BUVEURS, VINS ET COMMANDES. Cette
localisation sera fixŽe par les administrateurs locaux. Ceux-ci pourront, sous rŽserve
d’accord, dŽplacer une table par une commande du type MOVE <table> TO <site> sans
SGBDR ˆ rechercher les sites capables de gŽnŽrer des ŽlŽments de rŽponse ˆ une requte
pour l’exŽcuter. Ceci n’est pas une fonction Žvidente, si bien que l’objectif
trouvŽ [Williams82] en utilisant un nom hiŽrarchique pour les tables qui constituent
souvent l’unitŽ de localisation. Ce nom est du type <table>@<base>, o <table> est un nom
unique un nom de site. Si l’utilisateur utilise directement un tel nom composŽ, il n’y a
plus indŽpendance ˆ la localisation : la migration d’une table d’une base ˆ une autre
retrouver cette indŽpendance. L’utilisation de nom hiŽrarchique avec vue ou/et alias est
3.3Meilleure disponibilitŽ
Une des justifications essentielles d’un SGBDR est sans doute l’apport en matire de
d’un site central unique. Surtout, elle permet de gŽrer des copies, de se replier sur une
copie lorsqu’une autre est indisponible (site en panne), et mme de mettre ˆ jour de
manire indŽpendante des copies. Les copies deviennent alors des rŽplicats qui peuvent
rŽplication est tellement importante que nous lui consacreront une section ci-dessous.
Assurer une meilleure disponibilitŽ des donnŽes, c’est aussi garantir l’atomicitŽ des
transactions. Une transaction est en effet un ensemble de requtes, dont certaines sont des
mises ˆ jour. Ces requtes — plus particulirement les mises ˆ jour — doivent tre toutes
donnŽes rŽpartie serait seulement partiellement mise ˆ jour. Par exemple, figure 6, seul
le compte de Bordeaux pourrait tre incrŽmentŽ si l’on arrte aprs la premire mise ˆ jour.
exŽcuter une opŽration alors qu’un autre peut refuser l’opŽration liŽe, chacun gardant le
contr™le sur ce qu’il exŽcute. Les protocoles assurant l’atomicitŽ sont essentiels : nous
3.4Autonomie locale
Un autre objectif des SGBDR est d’Žviter la nŽcessitŽ d’une administration centralisŽe
des bases. L’autonomie locale vise ˆ garder une administration locale sŽparŽe et
indŽpendante pour chaque serveur participant ˆ la BD rŽpartie. Ainsi, les reprises aprs
panne doivent tre accomplies localement et ne pas impacter les autres sites. Les mises ˆ
niveau de logiciel sur un site doivent tre possibles sans impacter les autres sites. Bien que
chaque base puisse travailler avec les autres, les gestions de schŽmas doivent rester
indŽpendantes.
Chaque base conservera donc son dictionnaire local contenant les schŽmas locaux. Afin
tables distantes utilisŽs dans les requtes. Ceci se fera par adjonction d’une extension du
dictionnaire qui sera remplie lors du premier accs ˆ un objet distant par importation du
schŽma, ou plus explicitement lors de la crŽation d’un lien avec une base ou un objet
distant. L’autonomie nŽcessite une mise ˆ niveau automatique des schŽmas importŽs.
Ceci peut tre effectuŽ par un mŽcanisme de version : lors de l’accs ˆ une table, la version
du schŽma importŽ sera contr™lŽe ; dans le cas ou le schŽma aura ŽtŽ modifiŽ sur le
site gŽrant la table, il sera mis ˆ niveau sur le site client. Ces mŽcanismes de coopŽration
3.5HŽtŽrogŽnŽitŽ
Nous avons dŽjˆ vu ci-dessus le besoin des entreprises en matire d’accs intŽgrŽ ˆ des
d’unifier modles et langages comme reprŽsentŽ figure 8, ceci afin de gŽrer des bases
Au delˆ de la possibilitŽ d’unifier les modles de donnŽes et les langages d’accs pour
sŽmantique des bases se pose. En effet, celles-ci ont souvent ŽtŽ conues
indŽpendamment si bien qu’une mme donnŽe peut porter un nom diffŽrent et avoir une
l’ensemble des schŽmas en un schŽma unique. Ces fonctions nŽcessitent un outil d’aide ˆ
l’intŽgration de schŽmas.
L’Žquivalence des schŽmas est une propriŽtŽ importante. Deux schŽmas sont
ˆ vŽrifier.
V.4.ARCHITECTURE DES SGBDR
Dans cette section, nous Žtudions les composants essentiels d’un SGBDR d’un point de
Un SGBD reoit des requtes rŽfŽrenant des objets d’une base de donnŽes rŽparties. Il
une des fonctions essentielles qui permet d’Žlaborer des plans d’exŽcution quasi
optimaux pour les requtes. Dans le contexte de BD hŽtŽrognes, le SGBDR doit aussi
assurer la traduction des requtes exprimŽes dans un langage pivot (e.g., SQL) en requtes
comprŽhensibles par le SGBD local. Les paramtres des requtes et les rŽsultats doivent
tre convertis pour tre ŽchangŽs dans des formats conformes aux schŽmas. Ces schŽmas
Pour ce qui concerne les mises ˆ jour, le SGBDR doit bien sžr les router vers le ou les sites
concernŽs, mais il doit aussi assurer la gestion des transactions rŽparties. Ceci inclut la
vŽrification des rgles d’intŽgritŽ multibases, le contr™le des accs concurrents, et surtout
sur les fonctions locales de gestion de transactions pour accomplir les fonctions globales.
Il peut se heurter ˆ des problmes d’incompatibilitŽ entre SGBD dans le cas de SGBD
hŽtŽrognes.
4.2Organisation des schŽmas
Une base de donnŽes rŽpartie est dŽcrite par diffŽrents niveaux de schŽmas illustrŽs
figure 9. Tout d’abord, chaque base locale comporte un schŽma gŽrŽ par le SGBD local,
SchŽma dŽcrivant les donnŽes d’une BD locale gŽrŽe par le SGBD local.
Lors de la constitution d’une base de donnŽes rŽpartie, chaque base locale rend visible
une partie de la base aux sites clients. Cette partie doit tre dŽcrite dans le modle pivot
servant de modle d’Žchange au niveau du SGBDR. Cette description est appelŽe schŽma
exportŽ.
SchŽma dŽcrivant les donnŽes exportŽes par un site vers les sites clients.
Vue d’un site client, un schŽma exportŽ par un serveur devient un schŽma importŽ. Il
L’ensemble des schŽmas exportŽs par tous ou certains sites clients peut tre intŽgrŽ dans
SchŽma constituŽ sur un site client par intŽgration globale des schŽmas importŽs
dŽcrivant la BDR vue depuis ce site.
Le schŽma global n'est gŽnŽralement pas matŽrialisŽ sur chaque site client d’un
SGBDR. On prŽfre plut™t dŽfinir des vues externes de la BDR pour chaque application
ou groupe d’applications. De telles vues rŽalisent une intŽgration partielle de schŽmas
SchŽma dŽcrivant dans le modle du SGBDR les donnŽes de la BDR accŽdŽe par
une application.
n’implŽmentent pas tous les niveaux de schŽmas. Comme indiquŽ, le schŽma global
d’un site (ou de tous les sites) n’est pas matŽrialisŽe ; il sert seulement de support ˆ la
vues de la base locale et est donc directement gŽrŽ par le SGBD local ; le schŽma
importŽ devient alors un ensemble de schŽmas de tables dont une version est gardŽe
dans un cache au niveau du SGBD sur le site client, comme indiquŽ dans la section
prŽcŽdente. Les vues intŽgrŽes sont alors des vues au niveau du SGBD client construites
ˆ partir des tables importŽes combinŽes Žventuellement aux tables gŽrŽes par le SGBD
du site client. Les diffŽrents niveaux de schŽmas sont donc bien simplifiŽs dans les
architectures homognes.
4.3Architecture de rŽfŽrence
· le niveau local prŽsent sur chaque serveur permet d’exporter les donnŽes
provenance d’un site client au serveur dans le langage pivot d’Žchange ; ces
sous-requtes rŽfŽrencent le schŽma exportŽ vers ce site client ; en sens
· le niveau interopŽrable permet de formuler des requtes mettant en jeu des vues
local.
La figure 10 prŽcise chacun des niveaux et les schŽmas associŽs dŽcrivant les donnŽes.
Soulignons que le niveau communication est en fait un mŽdiateur comme introduit aux
chapitres II et III. Il combine un module d’accs aux objets distants sur le client et un
module d’accs aux objets locaux sur le serveur. Le premier permet d’envoyer des requtes
module de gestion d’objets intŽgrŽs. Le second reoit les requtes envoyŽes par le module
d’accs aux objets distants et les transmet au niveau local ; il reoit les rŽponses du niveau
Le niveau local est chargŽ d’exŽcuter les requtes exprimŽes en langage pivot sur un
SGBD local. Il est constituŽ par un adaptateur local. Ce module rŽalise donc le passage
SGBD local. En sens inverse, il traduit aussi les rŽponses aux requtes dans le modle
pivot. Chaque SGBD local possde un adaptateur spŽcifique qui peut tre trs rŽduit si le
SGBD est conforme au standard imposŽ par le SGBDR. L’adaptateur unifie les SGBD
locaux d’un point de vue fonctionnalitŽs (langage et modle). Il est vŽritablement une
passerelle depuis le SGBDR vers un SGBD local. La figure 11 montre les diffŽrents types
de requtes de manipulation de donnŽes ŽchangŽes entre les diffŽrents niveaux de
4.4GŽnŽrations de prototypes
Un choix important est celui du modle pivot et du langage pivot. Un autre est le degrŽ
gŽnŽrations de SGBDR.
La premire gŽnŽration est basŽe sur le modle relationnel qui offre l’avantage de
dont les premiers ont ŽtŽ construits dans les annŽes 75-82, comme SDD1 [Rothnie80],
systmes qui ont donnŽ naissance aux produits industriels tels Oracle*s-Stars et
Ingres/Star. Ces produits sont souvent centrŽs autour d’un SGBD prŽsent sur le site
client et sur les serveurs, qui gre les schŽmas importŽs au niveau d’un cache associŽ ˆ sa
mŽtabase. Les vues intŽgrŽes sont confondues avec celle de ce SGBD client. Ces systmes
rŽpartis permettent un degrŽ limitŽ d’hŽtŽrogŽnŽitŽ par des passerelles qui adaptent
les autres SGBD en rapatriant leurs donnŽes au sein du SGBD de base. Ils ne grent gure
d’objets complexes autres que les champs binaires longs (Binary Large Objects — BLOB).
systmes fŽdŽrŽs toujours construits autour du relationnel, mais pas centrŽs sur un
SGBD particulier. Les prŽcurseurs de ces systmes ont ŽtŽ construits dans les annŽes 80-
permettre un accs intŽgrŽ ˆ des bases locales prŽsentant une large diversitŽ syntaxique
noms, de structures et d’Žchelles entre les donnŽes dŽcrites par les schŽmas
exportŽs.
· Unification des schŽmas. Cette Žtape consiste ˆ transformer les schŽmas pour
· Fusion des schŽmas. Cette dernire Žtape intgre deux ou plusieurs schŽmas
Bien que trs prometteurs, les systmes fŽdŽrŽs de deuxime gŽnŽration ne sont gure
passŽs dans l’industrie. Des idŽes qu’ils dŽfendent commencent cependant ˆ Žmerger
Alors que la deuxime gŽnŽration de SGBD rŽpartis n’est gure industrielle, on parle dŽjˆ
d’une troisime gŽnŽration basŽe sur le modle objet [Burkhres94]. En effet, avec ces
plut™t basŽ sur un modle fonctionnel, fut un prŽcurseur des nouvelles architectures
intŽgrant des sources de donnŽes variŽes autour d’un modle sŽmantiquement riche.
Des systmes objets fŽdŽrŽs tels Pegasus, Omega et IRO-DB, comportant des schŽmas
exportŽs et intŽgrŽs basŽs sur un modle objet et un langage pivot dŽrivŽ d’un SQL
Žtendu aux objets, sont aujourd’hui en cours de construction. L’uniformisation des
SGBD participants autour d’un modle objet pose cependant des problmes difficiles tels
que le support d'identifiants globaux pour les objets permettant la migration d'objet sans
Dans cette section, nous examinons les problmes soulevŽs par la conception des bases de
Deux approches se distinguent nettement pour concevoir une base de donnŽe rŽpartie.
donnŽes. Elle est illustrŽe figure 12.a. 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
dans une base fŽdŽrŽe. Elle consiste ˆ intŽgrer des schŽmas locaux existants afin de
distribution des donnŽes est prŽexistante. Cette approche nŽcessite plus souvent une
diffŽrents sites des parties appelŽs fragments d’une table globale. Par une approche
A partir d’une table globale, la fragmentation peut d’une part s’effectuer par sŽlection de
une entreprise. Chaque rŽgion (ou dŽpartement) A dŽfinit un prŽdicat du type REGION
= A, qui par sŽlection dŽfinit le fragment associŽ ˆ la rŽgion. Celui-ci est localisŽ sur le
site de la rŽgion.
A partir d’une table globale, la fragmentation peut d’autre part s’effectuer verticalement,
illustrŽ figure 13.b. Afin de ne pas perdre d’informations, la table initiale doit pouvoir tre
recomposŽe par jointure des fragments. Une telle fragmentation est adaptŽe au
dŽcoupage fonctionnel, chaque fonction Fi gŽrant des attributs Ai1, Ai2, ÉAini. Par
Produit_Usine par projections respectivement sur les attributs concernant le sige (par
exemple, numŽro, type produit et cožt) et celle concernant l’usine (par exemple,
Technique de rŽpartition consistant ˆ gŽrer des copies sur diffŽrents sites, les
copies pouvant tre diffŽrentes ˆ un instant donnŽ, mais devant converger vers une
mme valeur si l’on arrte la production de transactions de mises ˆ jour.
Le problme de synchronisation des copies lors des mises ˆ jour est un problme difficile
que nous Žtudions ci-dessous dans une section dŽdiŽe aux copies.
que Fi(R) = sPi(R). Les prŽdicats de restrictions {Pi} doivent composer un ensemble de
prŽdicats disjoints et complets afin d’Žviter les doubles et les pertes d’informations. Les
de S par R est une jointure suivie d’une projection sur les tuples de S. On obtient alors
relation R par dŽfinition d’un ensemble de fragment {F i(S)} comme suit : Fi (S) = pS (S Ä
Fi(R)).
La fragmentation horizontale dŽrivŽe permet de localiser les tuples d’une table sur le
mme site que ceux d’une autre table avec qui ils ont des attributs communs. Elle peut tre
l’existence d’un fragment pour tout tuple. Une condition suffisante pour la disjonction
est que l’attribut de jointure soit une clŽ de R : dans ce cas, un tuple de S sera localisŽ sur
au plus un site de R, celui ayant le tuple correspondant ˆ la valeur de clŽ. Une condition
stipulant que S rŽfŽrence R par la clŽ : tout tuple de S sera sur le site du tuple de R qu’il
applications.
5.4Fragmentation mixte
verticaux). Elle peut donc tre dŽfinie comme une vue ˆ partir des relations composant les
R8, R10, R11 et R7. L’arbre de dŽcomposition permet de retrouver l’expression permettant
Chaque fragment est placŽ ou rŽpliquŽ sur un site. Aprs la fragmentation, le problme
qui se pose est celui de la localisation du fragment. Un schŽma doit tre ŽlaborŽ afin de
dŽterminer la localisation de chaque fragment comme indiquŽ figure 15. A partir de lˆ,
d’un fragment.
La commande :
DISTRIBUTE TABLE COMMUNE VERTICALLY
INTO VILLE(N¡C, NOM, N¡D, POPU, TYPE, É)
IN SEGMENT VILLE@SITE1,
INTO MAIRE (N¡C, NOM, PRŽNOM, INSCRIPTION, É)
IN SEGMENT MAIRE@SITE2
5.6Allocation optimale
ƒtant donnŽe une base de donnŽes rŽparties localisŽe sur un ensemble de sites S = {S1,
S2, É, Sm} et un ensemble de fragments F = {F1, F2, É, Fn} composant la base, le problme
thŽorique qui se pose lors de la conception de la base est de localiser les fragments sur
les sites. La conception descendante de la base consiste tout d’abord ˆ isoler les
traitement.
Le problme thŽorique peut tre dŽfinit comme suit. On examine le trafic par fragment
Fk nŽcessitŽ par les transactions. Soient Ri le trafic en lecture depuis le site S i pour Fk et
Ui le trafic en Žcriture depuis S i pour le mme fragment F k. On dŽsigne par Cij le cožt de
dŽsignŽ par Di. Le problme est de dŽterminer les variables d'assignation du fragment F k
{X1, X2, É Xm} telles que Xj = 1 si Fk est assignŽ sur Sj et 0 sinon, dont les valeurs
Le problme est NP-complet. De plus, il peut tre sujet ˆ des contraintes de capacitŽ
des fragments est donc un problme trs difficile. Une approche consiste ˆ choisir d’allouer
une copie de fragment ˆ un site si le bŽnŽfice (gain en lecture notamment) est supŽrieur
V.6.GESTION DE TRANSACTIONS
Dans cette section, nous Žtudions les problmes liŽs ˆ la gestion de transactions dans les
Une transaction est composŽe d’une suite de requtes dŽpendantes de la base qui doivent
6.1.1.1AtomicitŽ
Une transaction doit effectuer toutes ses mises ˆ jour ou ne rien faire du tout. En cas
d'Žchec, une transaction doit annuler toutes les modifications qu'elle a engagŽes.
6.1.1.2CohŽrence
La transaction doit faire passer la base de donnŽe d'un Žtat cohŽrent ˆ un autre. En cas
Les rŽsultats d'une transaction ne doivent tre visibles aux autres transactions qu'une fois
la transaction validŽe, ceci afin d’Žviter les interfŽrences avec les autres transactions.
6.1.1.4DurabilitŽ
Ds qu'une transaction valide ses modifications, le systme doit garantir que ces
Comme vu ci-dessus, ces propriŽtŽs doivent tre garanties dans le cadre d’un systme
rŽparti. En particulier, il faut assurer que toutes les mises ˆ jour d'une transaction sont
exŽcutŽes sur tous les sites ou qu'aucune ne l'est. Le problme essentiel ˆ rŽsoudre est le
risque d’incohŽrences liŽ au contr™le rŽparti : chaque site peut dŽcider de valider ou
6.2.1Principe
coordonner l’exŽcution des commandes Ç COMMIT È par tous les sites participant ˆ une
effectivement les rŽsultats des mises ˆ jour dans la BD rŽpartie. Le contr™le du systme
rŽparti est centralisŽ sous la direction d’un site appelŽ coordinateur, les autres Žtant
Noeud d'un systme rŽparti qui exŽcute des mises ˆ jour de la transaction et obŽit
aux commandes de prŽparation, validation ou annulation du coordinateur.
6.2.2Protocole C/S
Lors de l’Žtape 1, le coordinateur demande aux autres sites s’ils sont prts ˆ commettre
leurs mises ˆ jour par l’intermŽdiaire du message PREPARER (PREPARE). Si tous les
est diffusŽ : tous les participants effectuent leur validation sur ordre du client. Si un
participant n’est pas prt et rŽpond nŽgativement ( KO), le coordinateur demande ˆ tout
Le protocole nŽcessite la journalisation des mises ˆ jour prŽparŽes et des Žtats des
transactions dans un journal local propre ˆ chaque participant, ceci afin d’tre capable de
retrouver l’Žtat d’une transaction aprs une Žventuelle panne et de continuer la validation
Žventuelle. Le protocole est illustrŽ figure 17 dans le cas favorable ou un site client
demande la validation ˆ deux sites serveurs avec succs. Notons qu’aprs exŽcution de la
demande de validation (COMMIT), les participants envoient un acquittement ( ACK) au
Le cas de la figure 18 est plus difficile : le participant 2 est en panne et ne peut donc
Le cas de la figure 19 est encore plus difficile : le participant 2 tombe en panne aprs avoir
message COMMIT qui n’est pas reu par le participant 2. Heureusement, celui-ci a dž
sauvegarder l’Žtat de la sous-transaction et ses mises ˆ jour dans un journal fiable sur
dŽtectŽe prte ˆ commettre, son Žtat sera demandŽe au coordinateur (ou ˆ un participant
confirmŽe et les mises ˆ jour seront appliquŽes ˆ partir du journal. Les deux sous-
coordinateur qui centralise le contr™le. Afin de dŽcider, il compte les messages OK suite
prise de manire identique par chaque participant. Il suffit de diffuser le message OK Žmis
par tout participant ˆ tous les autres. Chacun peut alors compter le nombre de OK reu et
d’annulation est alors prise suite ˆ une absence de OK (ABORT ou time-out). On obtient
ainsi une version dŽcentralisŽe du protocole illustrŽe figure 20. Ce protocole assure la
convergence des dŽcisions sur un rŽseau sans perte de message. En cas de perte d’un
message OK, les sites peuvent diverger. C’est pourquoi, les systmes prŽfrent en gŽnŽral
6.2.4Actions du Protocole
Les Žtats successifs du coordinateur sont INITIAL, WAIT, COMMIT ou ABORT. Ceux du
participant sont PREPARE, READY, COMMIT ou ABORT. La logique des sites est dŽtaillŽe
figure 21. Les transitions d'Žtats s’effectuent suite ˆ une rŽception suivie d’un envoi
Bien que garantissant la convergence des acteurs vers un mme Žtat ( COMMIT ou ABORT),
le protocole prŽsente des risque de blocage. Pour cela, il suffit que le coordinateur tombe
en panne aprs Žmission du message PREPARE. Tout participant ayant votŽ prt (OK) est
alors bloquŽ. La question qui se pose est, plus gŽnŽralement, que doit faire un site en
cas de doute ? Il est possible de demander l’Žtat aux autres participants par un message
STATUS, mais tous peuvent tre bloquŽs en attente du coordinateur ! Une solution consiste
ˆ forcer la transaction locale ˆ l’Žtat ABORT puis ˆ l’ignorer. Sous conditions qu’aprs une
panne avant passage ˆ l’Žtat COMMIT le coordinateur choisisse ABORT et que le rŽseau
optimiste consisterait ˆ forcer la transaction locale ˆ l’Žtat COMMIT en cas de doute. Un tel
Afin de lever l’inconvŽnient du protocole de validation ˆ deux phases qui est donc qu’en
trois phases a ŽtŽ proposŽ [Skeen81]. Celui-ci Žvite les blocages. Les messages de la
validation ˆ trois phases sont PREPARE, PRECOMMIT, COMMIT et ABORT. Les transitions
d’Žtats des sites sont reprŽsentŽes figure 23. En cas de doute, tout site bascule dans
l’Žtat terminal le plus proche. Tout Žtat Žtant adjacent d’un seul Žtat terminal, il n’y a
pas d’ambigu•tŽ. Le protocole permet ainsi d’assurer la convergence des sites vers un
6.4Protocole arborescent TP
TP est le protocole standard proposŽ par l’ISO dans le cadre de l’architecture OSI afin
protocole est arborescent en ce sens que tout participant peut dŽclencher une sous-
choisi. Un coordinateur est responsable de ses participants pour la phase 1 et collecte les
site appelŽ point de validation qui est responsable de la phase 2 : c’est le point de
validation qui envoie les COMMIT aux participants. L’intŽrt du protocole, outre l’aspect
hiŽrarchique, est que le point de validation peut tre diffŽrent du coordinateur : ce peut
tre un nÏud critique dans le rŽseau dont la prŽsence ˆ la validation est nŽcessaire. La
Nous avons ci-dessus ŽtudiŽ les techniques implŽmentŽes dans les SGBD rŽpartis pour
assurer l’atomicitŽ des transactions. Ces techniques sont aujourd’hui bien connues et
opŽrationnelles pour les transactions en gestion. Le problme des reprises aprs pannes n’a
pas ŽtŽ abordŽ. C’est un problme connexe rŽsolu ˆ partir de sauvegardes et de journaux
Les techniques de gestion de transactions atomiques sont trop limitŽes dans le cas de
d’elle pouvant tre validŽe ou annulŽe. Une transaction de niveau N doit pouvoir
commettre bien que certaines sous-transactions de niveau N-1 soient annulŽes. Des
transactions de compensation viendront plus tard refaire les portions de travail non
permettant une plus grande flexibilitŽ que le tout ou rien [Bancilhon85]. De tels modles
V.7.MONITEURS TRANSACTIONNELS
vu ci-dessus dans le cadre de systmes hŽtŽrognes. Au-delˆ, ils ont d’autres objectifs et
Au-delˆ du support de transactions ACID sur des donnŽes hŽtŽrognes, les moniteurs
transactionnels essaient d’assurer un accs continu aux donnŽes et des reprises rapides du
systme rŽparti en cas de panne. Ils accroissent aussi la sŽcuritŽ des accs en proposant
leurs propres contr™les. Ils visent aussi ˆ amŽliorer les performances en introduisant des
25. La gestion de transaction ACID pour un programme d’application AP est assurŽe par
L’architecture propose deux interfaces pour lesquelles ont ŽtŽ ŽlaborŽs des standards :
moniteur transactionnel.
Ces interfaces et plus gŽnŽralement l’architecture DTP permettent de mettre en Ïuvre le
7.3Interface applicative TX
commencer une transaction et de la terminer avec succs ou en Žchec. Elle est globale et
7.5Interface ressource XA
L’interface XA est celle que doit fournir toute ressource. Il s’agit de fait des primitives
· xa_end qui indique au RM qu’il n’y aura plus de requtes pour le compte de la
transaction courante ;
Toute ressource implŽmentant ces primitives peut donc s’intŽgrer dans un moniteur
7.6Principaux moniteurs
Il existe plusieurs moniteurs transactionnels qui implŽmentent les principes ci-dessus. Ils
sont donc utiles dans des contextes hŽtŽrognes pour coordonner l’exŽcution de
· Top End de AT&T. Celui-ci supporte des agents Ç 3270 È, prend en compte des
sous Motif.
· CICS/6000 de IBM. C’est une nouvelle version du vieux moniteur CICS d’IBM. Il
reprendre les moniteurs existants CICS sur machine IBM, par exemple avec le
systme MVS.
· Tuxedo de USL. Il s’agit d’un moniteur ŽprouvŽ sous UNIX qui permet
Les moniteurs transactionnels peuvent parfois dialoguer entre eux, ceci afin de supporter
une plus grande hŽtŽrogŽnŽitŽ ; c’est par exemple le cas pour Encina et CICS.
V.8.CONTRÏLE DE CONCURRENCE
atomiques distribuŽes, nous abordons dans cette section les problmes connexes de
8.1Objectifs
L’objectif gŽnŽral est de rendre invisible aux clients le partage simultanŽ des donnŽes.
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 T 1. La mise ˆ jour de T 2 est
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 ˆ violer la
contrainte. Par exemple, soit deux donnŽes A et B devant rester Žgales. L’exŽcution de la
Un autre problme liŽ aux accs concurrents est la non reproductibilitŽ des lectures :
deux lectures d’une mme donnŽe dans une mme transaction peuvent conduire ˆ des
valeurs diffŽrentes si la donnŽe est modifiŽe par une autre transaction entre les deux
lectures. Le problme ne survient pas si les mises ˆ jour sont isolŽes, c’est-ˆ-dire non
visible par une autre transaction avant la fin de la transaction. Il en va de mme des pertes
de l’apparition d’incohŽrence. 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
La rŽsolution des problmes ŽvoquŽs dans un systme rŽparti nŽcessite tout d’abord une
concurrence. Ceci n’est en gŽnŽral pas suffisant car il existe des risques de conflits
Afin de mieux caractŽriser les exŽcutions simultanŽes correctes, une condition plus
Une exŽcution sŽrialisable est correcte car elle donne un rŽsultat que l’on obtiendrait en
exŽcutant les transactions l’une aprs l’autre. Lorsqu’on examine une sŽquence
appara”t que l’ordre de certaines opŽrations ne peut tre changŽ sans changer le rŽsultat,
multiplication).
Les chercheurs ont ainsi aboutit ˆ dŽfinir la notion de prŽcŽdence de transactions dans
d’Žcriture. Les prŽcŽdences sont alors induites par les sŽquences comportant lecture
puis Žcriture, Žcriture puis lecture, Žcriture puis Žcriture, d’une mme donnŽe. Plus
· Ti : lire(D) É Tj : Žcrire(D) ;
· Ti : Žcrire(D) É Tj : Žcrire(D) ;
· Ti : Žcrire(D) É Tj : lire(D) ;
La relation de prŽcŽdence entre transactions peut tre reprŽsentŽ par un graphe comme
illustrŽ figure 26. Il a ŽtŽ montrŽ qu’une condition suffisante de sŽrialisabilitŽ est que le
graphe de prŽcŽdence doit rester sans circuit. Par exemple, l’exŽcution simultanŽe
circuit.
Le verrouillage deux phases est une technique de prŽvention des conflits basŽe sur le
sŽlection ou mise ˆ jour. En thŽorie, une transaction ne peut rel‰cher de verrous avant
Technique de contr™le des accs concurrents consistant ˆ verrouiller les objets au fur
et ˆ mesure des accs par une transaction et ˆ rel‰cher les verrous seulement aprs
obtention de tous les verrous.
Une transaction comporte donc deux phases (voir figure 27) : une phase d’acquisition de
verrous, et une phase de rel‰chement. Cette condition garantit un ordre identique des
transactions sur les objets accŽdŽs en mode incompatible. Cet ordre est celui
l’isolation des mises ˆ jour, les verrous sont seulement rel‰cher en fin de transaction,
lors de la validation.
verrouillage. Les compatibilitŽs entre opŽrations dŽcoulent des prŽcŽdences ; elles sont
dŽcrites par la matrice reprŽsentŽe figure 28. Lors d’une demande de verrouillage, si
l’objet demandŽ est verrouillŽ, la transaction demandante est mise en attente jusqu’ˆ
libŽration de l’objet. Ainsi, toute transaction attend la fin des transactions incompatibles,
ce qui garantit un graphe de prŽcŽdence sans circuit. Une analyse fine montre que les
verrouillage. Dans une base de donnŽes relationnelles, les objets ˆ verrouiller peuvent tre
des tables, des pages ou des tuples. Une granularitŽ variable des verrous est souhaitable,
bien sžr les risques de conflits. Elle maximise cependant la gestion du systme de
verrouillage.
Une granularitŽ variable est possible. La technique consiste ˆ dŽfinir un graphe acyclique
jusqu’aux feuilles dŽsirŽes qui sont verrouillŽes en mode explicite. Par exemple, une
intention d’Žcriture, puis la page en intention d’Žcriture, et enfin le tuple. Les modes
d’intentions obŽissent aux mmes rgles de compatibilitŽs que les modes explicites, mais
sont compatibles entre eux. Le verrouillage en intention permet simplement d’Žviter les
conflits avec les modes explicites. Le graphe d’inclusion pour les objets table, page et
Le verrouillage, tel que prŽsentŽ ci-dessus, est trs limitatif du point de vue des
degrŽ de verrouillage souhaitŽ est choisi par le dŽveloppeur de la transaction parmi les
suivants :
· Le degrŽ 0 garantit les non perte des mises ˆ jour ; il correspond ˆ la pose de
Ainsi, le dŽveloppeur peut contr™ler la pose des verrous. Un choix autre que le degrŽ 3
doit tre effectuŽ avec prŽcaution dans les transactions de mises ˆ jour, car il implique des
risques d’incohŽrence.
Les techniques dŽcrites ci-dessus sont implŽmentŽes dans tous les serveurs de bases de
donnŽes. Le problme qui se pose dans systmes rŽpartis est celui du contr™le des
dŽcentralisŽ o chaque serveur gre les verrous de ses donnŽes. La solution centralisŽe est
non praticable pour des verrous fins (pages, tuples), si bien que les SGBD rŽpartis
retiennent en gŽnŽral le verrouillage dŽcentralisŽ. Chaque serveur gre donc ses propres
verrous avec son gŽrant de verrous (Lock Manager), comme illustrŽ figure 30. Ceci ne va
Une transaction Ti attend une transaction T j si Ti a demandŽ l’obtention d’un verrou sur
prŽsence d’un circuit dans le graphe d’attente. Un verrou mortel peut tre causŽ par des
Deux classes de solutions sont possibles dans les SGBD rŽpartis afin de rŽsoudre le
verrous mortels de survenir ; la seconde, appelŽ dŽtection, est une solution curative qui
problme ne survient pas. Il existe classiquement deux approches, l’une basŽe sur
des ressources (tables, pages, tuples) de sorte ˆ les allouer dans un ordre fixŽ aux
concatŽnŽe avec le numŽro de site sur lequel elle est lancŽe, ceci afin d’empcher
l’ŽgalitŽ des estampilles pour deux transactions lancŽes au mme instant : celles-ci
A partir des estampilles, deux algorithmes ont ŽtŽ proposŽs [Rosenkrantz78] pour
prŽvenir les verrous mortels. Tous deux consistent ˆ dŽfaire plus ou moins directement
une transaction dans le cas d’attente, de sorte ˆ ne permettre que des attentes sans risque
de circuit. L’algorithme WAIT-DIE consiste ˆ annuler les transactions qui demandent des
ressources tenues par des transactions plus anciennes. La transaction la plus rŽcente est
alors reprise avec la mme estampille ; elle finit ainsi par devenir ancienne et par passer. Il
ne peut y avoir de verrou mortel, les seules attentes possibles Žtant dans l’ordre
transaction ancienne attend transaction rŽcente. Le contr™le des attentes imposŽ par
Algorithm WAIT-DIE
Attendre (Ti,Tj) {
// Ti rŽclame un verrou tenu par Tj
if ts(Ti) < ts(Tj) then Ti waits else Ti dies }
Figure 32 — Contr™le des attentes dans l’algorithme WAIT-DIE.
L’algorithme WOUND-WAIT est un peu plus subtil. Tout type d’attente est permis.
Mais, dans le cas ou une transaction plus ancienne attend une plus rŽcente, la rŽcente est
blessŽe (wounded), ce qui signifie qu’elle ne peut plus attendre : si elle rŽclame un verrou
tenu par une autre transaction, elle est automatiquement dŽfaite et reprise. Le contr™le
des attentes imposŽ par l’algorithme est reprŽsentŽ figure 33 ; de plus, une transaction
Algorithm WOUND-WAIT
Attendre (Ti,Tj) {
// Ti rŽclame un verrou tenu par Tj
if ts(Ti) < ts(Tj) then Tj is wounded else Ti waits }
Figure 33 — Contr™le des attentes dans l’algorithme WOUND-WAIT.
Les deux algorithmes empchent les situations de verrous mortels en donnant prioritŽ
dŽfont des transactions alors que les verrous mortels ne sont pas sžrs d’appara”tre. Au
annule certaines transactions afin de rompre les circuits d’attente. Il existe deux types
d’algorithmes : les algorithmes centralisŽs qui collectent les Žtats afin de construire le
graphe d’attente ; les algorithmes distribuŽs qui procdent par propagation d’enqutes
auprs des contr™leurs de concurrence afin de parcourir les circuits d’attente ˆ l’aide de
messages envoyŽs sur le rŽseau. Les algorithmes distribuŽs sont prŽfŽrables car ils
Žvitent de dŽtecter de faux verrous mortels obtenus par comparaisons d’Žtats collectŽs ˆ
verrou fournit une procŽdure Enqute avec n paramtre une liste de transactions T i1.Ti2.
ÉTin telle que Ti1 attend Ti2, Ti2 attend Ti3, etc. La dŽtection du verrou mortel est lancŽe
Enqute du site contr™lant Ti avec une liste {Ti, ¯}. L’enqute est propagŽe aux sites
contr™lant une transaction qui attend T i s’il en existe. Si l’enqute revient au site initial
pour Ti, c’est que Ti est prise dans un verrou mortel. Un verrou mortel est dŽtectŽ : il faut
Bien que le verrouillage avec prŽvention ou dŽtection du verrou mortel soit la technique
gŽnŽralement appliquŽe dans les SGBD rŽpartis ou centralisŽs, d’autres techniques ont
ŽtŽ proposŽes. En particulier, l’ordonnancement par estampille peut tre utilisŽ non
seulement pour rŽsoudre les verrous mortels, mais plus compltement pour garantir la
Une mŽthode simple consiste ˆ conserver pour chaque objet accŽdŽ (tuple ou page),
1. que les accs en Žcriture s’effectuent dans l’ordre croissant des estampilles de
l’Žcrivain W et le lecteur R ;
2. que les accs en lecture s’effectuent dans l’ordre croissant des estampilles de
transactions par rapport aux opŽrations crŽant une prŽcŽdence, donc par
rapport ˆ l’Žcrivain W.
transaction ayant crŽŽ le dŽsordre. Les contr™les nŽcessaires en lecture et Žcriture sont
Lire(Ti,O) {
// la transaction Ti demande la lecture de l’objet O ;
si ts(Ti) < W(O) alors abort(T i)
sinon exŽcuter_lire(Ti,O) } ;
Figure 35 — Algorithme d’ordonnancement des accs par estampillage.
estampilles W et R associŽes ˆ chaque objet remplacent les verrous. Il n’y a pas d’attente,
celles-ci Žtant remplacŽes par des reprises de transaction en cas d'accs ne respectant pas
reprises. Une amŽlioration possible consiste ˆ garder d’anciennes versions des objets.
Dans le cas ou l’estampille du lecteur ne dŽpasse pas celle du dernier Žcrivain, on peut
lecteur. Ainsi, il n’y a plus de reprise lors des lectures. La mŽthode est cependant difficile
La certification optimiste est une mŽthode de type curative, qui laisse les transactions
Une transaction est divisŽe en trois phases : phase d’accs, phase de certification et phase
contr™leur vŽrifie l'absence de conflits (L/E ou E/E sur un mme objet) avec les
transactions certifiŽe pendant la phase d'accs. S’il y a conflit, la certification est refusŽe
En rŽsumŽ, cette mŽthode optimiste est similaire au verrouillage, mais tous les verrous
sont laissŽs passants et les conflits ne sont dŽtectŽs que lors de la validation des
dans les systmes centralisŽs et rŽpartis. MalgrŽ le grand nombre de solutions proposŽes
par les chercheurs, les systmes continuent ˆ appliquer le verrouillage deux phases avec
prŽvention ou dŽtection des verrous mortels. Les degrŽs d’isolation choisis par les
vers les mmes valeurs ˆ termes. Nous examinons ci-dessous les diffŽrentes formes de
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
Du point de vue disponibilitŽ, lors d'une panne d'un serveur, on peut se replier sur un
autre disposant d’une copie des donnŽes. Avec N copies sur des serveurs diffŽrents, la
disponibilitŽ = 1 - probabilitŽ_panneN.
Par exemple, avec une probabilitŽ de panne Žgale ˆ 5%, la gestion de deux copies fait
passer la disponibilitŽ des donnŽes de 95% ˆ 99,75%. Les gains sont donc trs
importants. La disponibilitŽ peut aussi tre amŽliorŽe par une meilleure tolŽrance aux
fautes. Avec plus de deux copies, il est imaginable de dŽtecter des fautes diffuses en
mettant en Ïuvre des techniques de contr™le de rŽsultats et de vote majoritaire. Les
sites n’ayant pas un rŽsultat concordant avec la majoritŽ sont alors ignorŽs.
Tout d’abord, il faut assurer la convergence des copies. Si les copies peuvent tre
diffŽrentes ˆ un instant donnŽe, elles doivent converger vers un mme Žtat cohŽrent o
toutes les mises ˆ jour sont exŽcutŽes partout dans le mme ordre. La convergence peut
tre longue, mais elle doit survenir si l’on arrte la production de transactions dans le
systme. 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 accs.
Jusque-lˆ, nous avons supposŽ que toute mise ˆ jour de la base demandŽe depuis un
nÏud Žtait effectuŽe en temps rŽel sur les autres nÏuds, c’est-ˆ-dire pour le compte de la
mme transaction atomique. Ceci correspond au mode de mise ˆ jour synchrone qui
Mode de distribution dans lequel toutes les sous-opŽrations locales effectuŽes suite
ˆ une mise ˆ jour globale sont accomplies pour le compte de la mme transaction.
Dans le contexte des copies, ce mode de distribution est trs utile lorsque les mises ˆ jour
effectuŽes sur un site doivent tre prises en compte immŽdiatement sur les autres sites.
Par exemple, la gestion de copies d’une table des cours des devises nŽcessite en gŽnŽral
des mises ˆ jour synchrones. En effet, les cours devant rester identiques sur tout les sites
dernier niveau de mise ˆ jour. Le systme peut alors garantir la fourniture de la dernire
version des donnŽes quelque soit la copie accŽdŽe. Les inconvŽnients sont cependant
concurrence et de panne d’un site. C’est pour cela que l’on prŽfre souvent le mode de
Le temps de mise ˆ jour des copies peut tre plus ou moins diffŽrŽ : les transactions de
report peuvent tre lancŽes ds que possible ou ˆ des instants fixŽs, par exemple le soir ou
en fin de semaine.
Les applications qui supportent un tel mode de distribution, avec gestion de copies
diffusion d’informations, etc. Les avantages sont la possibilitŽ de mettre ˆ jour en temps
choisi des donnŽes, tout en autorisant l’accs aux versions anciennes avant la mise ˆ
niveau. Les inconvŽnients sont bien sžr que l'accs ˆ la dernire version n'est pas garanti, ce
La diffusion automatique des mises ˆ jour appliquŽe ˆ une copie aux autres copies doit
tre assurŽe par le SGBD rŽparti. Plusieurs techniques de diffusion sont possibles, parmi
lesquelles on distinguera celles basŽes sur la diffusion de l’opŽration de mise ˆ jour de
l’inconvŽnient de nŽcessiter un ordonnancement identique des mises ˆ jour sur tous les
sites afin d’Žviter les pertes de mises ˆ jour. Le report d’opŽration est plus flexible,
Comment diffuser les mises ˆ jour est un autre problme auquel les constructeurs de
l’implŽmentation : un tel dŽclencheur permet de faire suivre toute mise ˆ jour sur une
table vers ses copies. L’utilisation de files persistantes rend praticable le report
asynchrone des mises ˆ jour. Une file persistante permet de mŽmoriser une transaction
de report et de la conserver — mme en cas de panne — jusqu’ˆ Žmission par une t‰che
pŽriodiquement par une t‰che de fond chargŽ des Žmissions des transactions de
report au moment opportun. Enfin, l’utilisation d’appels pŽriodiques (polling) par les
sites gŽrant les copies vers un site (ou plusieurs sites) chargŽ de centraliser les mises ˆ
jour autorise la scrutation de journaux. A chaque appel, le site appelŽ transmet les mises
ˆ jour enregistrŽes dans le journal depuis le dernier appel au site gŽrant la copie. Celui-ci
applique alors les mises ˆ jour. Cette technique permet un fonctionnement asynchrone
En rŽsumŽ, les techniques de diffusion des mises ˆ jour sont multiples. On peut
schŽma tirer (pull) ˆ l’initiative du site gŽrant la copie. Les avantages et inconvŽnients de
Au-delˆ des techniques de diffusion des mises ˆ jour se pose le problme du choix de la
copie sur laquelle appliquer les mises ˆ jour. La rŽplication asymŽtrique rompt la
symŽtrie entre les copies en distinguant un site chargŽ de centraliser les mises ˆ jour.
Technique de gestion de copies basŽe sur un site primaire seul autorisŽ ˆ mettre ˆ
jour et chargŽ de diffuser les mises ˆ jour aux autres copies dites secondaires.
Le site primaire effectue les contr™les et garantit l'ordonnancement correct des mises ˆ
catalogues, de listes de prix, etc. AppliquŽ dans l’autre sens, ˆ partir de copies de
dissŽminŽes ; par exemple l’Žtats des stocks sera transmis au sige par copie du fragment
local dŽsignŽ comme copie ma”tre. Il permet aussi la diffusion de donnŽes vers des
A noter que le choix d’une technique asymŽtrique est orthogonal au choix d’un mode de
figure 36 o un site primaire pousse les mises ˆ jour en temps rŽel vers deux sites
secondaires. La deuxime est illustrŽe figure 37 ; cette fois, les mises ˆ jour sont poussŽes
en temps diffŽrŽ via une file persistante. Dans les deux cas, des problmes surviennent
ce cas, il faut choisir un remplaant si l’on veut continuer les mises ˆ jour. Celui-ci peut tre
aboutit alors ˆ une technique asymŽtrique mobile dans laquelle le site primaire change
dynamiquement selon des critres qui peuvent tre liŽs ˆ l’application. Le droit de mise ˆ
jour se dŽplace de site en site, par exemple au fur et ˆ mesure de l’Žvolution des
donnŽes. Ceci va vers des applications de type flots de travaux (workflow) comme illustrŽ
figure 38 : le site responsable de la mise ˆ jour des commandes change au fur et ˆ mesure
pannes qui provoquent des Žchecs de transactions et l’Žvolution des travaux, ce qui
nŽcessite des langages de scripts afin de contr™ler le flot des travaux [Bernstein90]. Les
9.5RŽplication symŽtrique
aucune copie. Elle permet les mises ˆ jour simultanŽes de toutes les copies par des
transactions diffŽrentes.
Technique de gestion de copies o chaque copie peut tre mise ˆ jour ˆ tout instant et
assure la diffusion des mises ˆ jour aux autres copies.
Bien sžr, ceci pose des problmes de concurrence d’accs risquant de faire diverger les
copies. Une technique globale de rŽsolution de conflits doit donc tre mise en Ïuvre. Cette
approche convient bien aux applications ˆ responsabilitŽ distribuŽe telles que la saisie de
diffŽrence rŽside dans le passage des mises ˆ jour par une file persistante.
La convergence de copies asymŽtriques est assurŽe par le site ma”tre. Celui-ci rgle les
problmes de concurrence et envoie les mises ˆ jour dans l’ordre o ils les appliquent aux
sites secondaires. Encore faut-il que ces derniers appliquent les mises ˆ jour dans le bon
Dans le cas de copies symŽtriques, la convergence est plus difficile ˆ assurer. En effet, les
mises ˆ jour simultanŽes risquent d'tre accomplies dans un ordre diffŽrent sur une mme
donnŽe. On obtient alors deux Žtats diffŽrents : les copies divergent comme illustrŽ
figure 41. La sŽrialisabilitŽ de l’exŽcution globale des transactions n’est pas respectŽe,
d’o la divergence.
Des techniques applicables dans le cas de mise ˆ jour synchrones dŽcoulent des
chacune des copies. Les risques de verrous mortels sont alors importants si
plusieurs transactions mettent ˆ jour simultanŽment. Les verrous mortels
synchronisŽes pour ne pas favoriser un site plut™t qu’un autre. Les risques de
utilisables en synchrone.
l’utilisateur qui doit alors mettre en Ïuvre une technique de rŽsolution de conflits.
Comment tout d’abord dŽtecter les conflits ? Deux approches sont possibles : utiliser des
estampilles ou vŽrifier les valeurs avant mise ˆ jour. Nous les dŽtaillons ci-dessous.
La premire approche consiste donc ˆ utiliser des estampilles afin de vŽrifier que les mises
ˆ jour des objets s’effectuent en ordre croissant des estampilles de transactions. Ceci
nŽcessite d’estampiller ˆ la fois les copies des objets et les messages diffusant les mises ˆ
jour pour contr™ler que l’estampille de l’Žcrivain est supŽrieure ˆ celle de la copie de
estampillage vu dans la section contr™le de concurrence ci-dessus, ˆ ceci prs que l’on ne
reprend pas les transactions mais reporte le problme ˆ l’utilisateur afin qu’il corrige les
donnŽes.
La seconde approche consiste donc ˆ utiliser la valeur avant mise ˆ jour de l’objet afin de
vŽrifier que la valeur de la copie correspond bien ˆ celle sur laquelle est basŽe la mise ˆ
jour. Chaque message de mise ˆ jour doit donc comporter la valeur avant mises ˆ jour et
la valeur aprs. Dans le cas o la valeur avant est diffŽrente de celle figurant dans la base,
un conflit est dŽtectŽ. C’est qu’en effet une autre transaction a effectuŽ une mise ˆ jour
concurrente. La technique peut ignorer des conflits provoquŽs par des transactions qui
changent et rŽtablissent ensuite les donnŽes. Elles n’est donc pas totalement sžre mais
s’agit de rŽconcilier les copies qui ont divergŽ. La rŽconciliation peut tre purement
valeur rŽsultant de la mise ˆ jour la plus rŽcente pour application sur tous les sites. Il est
aussi possible de revenir vers une solution asymŽtrique en cas de conflit en choisissant
un site prioritaire. La rŽconciliation peut faire appel ˆ la signification des donnŽes et des
sŽmantique. celle-ci peut consister ˆ ajouter les valeurs (par exemple, en cas de
(par exemple, en cas de conflit sur une note), ˆ choisir le minimum, ˆ prendre la moyenne
(pour des statistiques), etc. RŽconcilier les copies est en fait un problme laisser au bon
doit continuer ˆ fonctionner malgrŽ les pannes de sites. Le problme est qu’un site en
panne ne reoit plus les mises ˆ jour. Lors de la reprise, il doit se resynchroniser en
demandant ou en recevant les mises ˆ jour qu’il a manquŽes. Le rŽseau peut aussi se
partitionner suite ˆ des pannes de nÏuds ou de moyens de communication. Le risque est
Comment garantir la non divergence en prŽsence de panne ? Pour cela, il faut tre sžr de
l’existence d'une copie ˆ jour recevant toutes les mises ˆ jour. Dans le contexte de copies
symŽtriques ˆ mises ˆ jour synchrone, ceci est difficile. Une solution a ŽtŽ proposŽe ds
1979 [Gifford79] basŽe sur le vote majoritaire. L’idŽe est d’accepter la validation d’une
par suite a exŽcutŽ correctement les mises ˆ jour demandŽes. Bien sžr, un site ne peut
accepter des mises ˆ jour et rŽpondre positivement au prŽ-commettre que s’il est en
phase avec la majoritŽ des sites. Deux majoritŽs ayant toujours un ŽlŽment commun,
ceci garantit qu’au moins une copie a reu toutes les mises ˆ jour de toutes les transactions
ˆ chaque vote acceptŽ. Ainsi, le rŽseau ne peut se diviser en partitions divergentes. Par
exemple, avec trois sites, une transaction peut commettre ds que deux des sites ont
efficacement des copies rŽpliquŽes. Ces mŽcanismes a priori utilisŽs pour gŽrer des
copies compltes de tables peuvent tre Žtendus afin de gŽrer des vues concrtes.
Notion 33 : Copie dŽrivŽe (Derived copy)
Il s’agit donc de copier le rŽsultat d'une question plut™t qu'une table entire. Une copie
dŽrivŽe correspond en fait ˆ une vue d’une base concrŽtisŽe sur un autre site que celui
gŽrant la base. Ce type de copie permet une meilleure adŽquation aux besoins de
l'utilisateur en copies et diminue les volumes de donnŽes ˆ transfŽrer pour assurer les
Il est utile de distinguer les copies dŽrivŽes simples des copies dŽrivŽes complexes. Une
copie dŽrivŽe est simple si ˆ chaque ligne d'une table ma”tre correspond un tuple
dŽrivŽ ; une copie est complexe si plusieurs tuples sont regroupŽs, par exemple par des
fonctions d’agrŽgats. Les copies simples sont faciles ˆ mettre ˆ jour en calculant et
contraire, les copies dŽrivŽes complexes sont difficiles ˆ mettre ˆ jour car il n’est en
type de copie.
Un clichŽ correspond ˆ une photo instantanŽe de la base, comme son nom l’indique. Il
est mis ˆ jour pŽriodiquement par envoi des mises ˆ jour groupŽes, ce qui le rend trs
efficace. Le clichŽ permet donc de gŽrer des vues concrtes et distantes d’une base en les
mettant ˆ jour en temps diffŽrŽ, selon une pŽriodicitŽ dŽfinie lors de la crŽation du
accessibles en lecture seule (read-only snapshot), alors que la version symŽtrique est
reprŽsentŽe par le clichŽ mettable ˆ jour (updatable snapshot). Ce dernier type de clichŽ
Dans cette section, nous Žtudions les techniques d’optimisation de requtes mises en
place dans les systmes de bases de donnŽes rŽparties. Nous prŽcisons tout d’abord les
objectifs de l’optimisation, puis nous rappelons brivement les principes de base. Nous
10.1Objectifs de l’optimisation
L’objectif de l’optimiseur d’un SGBD rŽparti est d’Žlaborer un plan d'exŽcution rŽparti
exŽcutables sur un mme site. Les opŽrations peuvent tre des sous-requtes, ou plus fines,
telles par exemples des opŽrations de l’algbre relationnelle, comme nous le supposons
dans la suite. Le r™le de l’optimiseur est donc de trouver le Ç meilleur È plan. Le plan
ou des morceaux de plans liŽs peuvent tre ensuite distribuŽs aux diffŽrents sites, soit
exŽcution.
Afin de gŽnŽrer et optimiser le plan, l’optimiseur doit prendre en compte les rgles de
localisation des donnŽes. Une prise en compte simple peut consister ˆ associer ˆ chaque
relation la liste des sites disposant de fragments. Plus finement, la dŽfinition des
fragments en termes de requte sur la table globale permettra en gŽnŽral une meilleure
optimisation, par exemple afin d’Žviter d’envoyer des requtes ˆ des sites ne pouvant
gŽnŽrer de rŽponses.
les transferts de donnŽes. Ceux-ci sont en effet gŽnŽralement plus cožteux que les
entrŽes-sorties. Le modle de cožt utilisŽ par l’optimiseur doit donc les intŽgrer.
Un autre objectif est de profiter au maximum du parallŽlisme possible entre les sites
pour Žvaluer les sous-requtes. Des sŽlections pourront ainsi tre appliquŽes en parallle
sur des fragment distincts d’une table. Des algorithmes sophistiquŽs de jointures par
Comme en centralisŽ, chaque plan d’exŽcution rŽparti peut tre ŽvaluŽ par une fonction
de cožt permettant d’estimer son efficacitŽ. Cette fonction doit tre du type :
Ces ŽlŽments ont diffŽrents poids a, b, et c selon les environnements, par exemple
rŽseaux longues distances, rŽseaux locaux, etc. La plupart des algorithmes ignorent les
facteurs cožt(E/S) et cožt(CPU) qui sont seulement pris en compte par les SGBD locaux.
Ceci est de moins en moins acceptable suite au progrs des performances des rŽseaux.
diminuer les tailles de donnŽes ˆ transfŽrer entre opŽrations. Ainsi, les opŽrations
Elles peuvent tre exŽcutŽes localement sur chacun des sites disposant d’un
fragment des relations rŽfŽrencŽes. Ainsi, Le SGBD rŽparti exŽcutera d'abord les
opŽrations rŽductrices de taille, ce qui diminuera les donnŽes ˆ transfŽrer. La figure 45
Pour dŽterminer le ou les sites ˆ qui envoyer une opŽration, il faut prendre en compte les
relations. Elles sont normalement dŽfinies par l’administrateur. Une syntaxe simple peut
consister ˆ dŽfinir un fragment comme une question SQL exprimŽe sur le schŽma
global. Un ou plusieurs sites (en cas de copies) doivent tre assignŽs ˆ un fragment. Une
commande du type :
13AS <QUESTION>
sera mise ˆ disposition de l’administrateur. Par exemple, pour la base dŽgustation, la
commande :
15ON DIJON
16AS SELECT *
L’optimiseur doit prendre en compte les rgles de localisation. Pour optimiser les
restrictions, il est en effet inutile d'appliquer une restriction si le critre est contradictoire
avec la rgle de localisation. Par exemple, il faudra Žviter d’aller chercher des vins
de producteurs de la rŽgion Bordelais ˆ Dijon, du fait que seul les Bourgogne sont
ˆ Dijon. De mme, il faut optimiser les jointures. Il est donc inutile de joindre deux
fragments a priori disjoints de par les critres de localisation, comme illustrŽ figure 46.
Toutes ces optimisations sont difficiles : elles demandent une analyse logique des
certaines contraintes d’intŽgritŽ peut tre intŽressante. Par exemple, si l’on est capable de
devient possible d’Žviter l’envoi d’une sous-requte de recherche des Volnay ˆ Bordeaux.
De telles optimisation sont trs difficiles ˆ rŽaliser et aujourd’hui aucun systme n’en est
capable.
10.5Algorithme ŽlŽmentaire
algŽbrique. Chaque sŽlection dŽtachŽe est ensuite envoyŽe aux sites susceptibles de
fournir des rŽsultats ˆ la sŽlection. Les sŽlections pendantes sont alors exŽcutŽes en
parallle sur les sites concernŽs. Les rŽsultats sont ensuite regroupŽs sur le site client.
Les jointures et projections finales ainsi que les Žventuels calculs d’agrŽgats sont
exŽcutŽs sur le site client. Les rŽsultats sont finalement dŽlivrŽs ˆ l'utilisateur. Un tel
volumes de transferts puisque toutes les donnŽes — certes aprs sŽlection — sont
10.6Optimisations possibles
Tout d’abord, il est souhaitable de prendre en compte plus finement les rgles de
localisation, notamment pour dŽtecter les jointures locales. Celles portant sur des
relations localisŽes sur un mme site peuvent tre dŽtachŽes simultanŽment aux
sŽlections et envoyŽes pour tre exŽcutŽes localement. Ceci maximise les traitements
locaux, mais ne minimise pas forcŽment la taille des donnŽes transfŽrŽes, la jointure
pouvant tre de taille supŽrieure aux relations rŽsultats des sŽlections qu’elle joint.
Une optimisation plus intŽressante consiste ˆ mieux choisir le site de transfert. Aprs
dŽtachement des sŽlections pendantes, la taille des rŽsultats distribuŽs sur les
diffŽrents sites peut tre ŽvaluŽe. Deux solutions pour ce faire : (1) dŽvelopper un modle
de taille de sŽlection basŽ sur une approche statistique comme vu pour les systmes
centralisŽs ; (2) faire effectivement exŽcuter les sŽlections et rŽcupŽrer les tailles des
rŽsultats en rŽponse. La premire approche qui peut tre compilŽe est mieux adaptŽe aux
requtes statiques, la deuxime plus interprŽtŽe convient plus aux requtes dynamiques.
permet de choisir le site de transfert optimal. Pour chacun des sites, on peut dŽterminer
un cožt de transfert prenant en compte les types de liaisons ; le site de cožt minimum est
alors retenu. Le cožt peut mme intŽgrer un cožt de traitement local. Soulignons qu’un
transfert final est nŽcessaire vers le site client pour rŽcupŽrer le rŽsultat final.
Au-delˆ, il est possible d’utiliser l’opŽration de semi-jointure pour rŽduire encore les
volumes ˆ transfŽrer. Rappelons qu’une semi-jointure notŽe R1 |>< R2 est une jointure de
R1 et R2 suivie d’une projection sur les attributs de R1. Donc, la semi-jointure rŽalise le
filtrage de R1 par R2 en sŽlectionnant tout les tuples de R1 dont la valeur figure dans la
colonne de R2 sur laquelle est rŽalisŽe la jointure. Dans certains cas la semi-jointure
permet de rŽduire les tailles des relations ˆ transfŽrer. La figure 47 illustre les
Soient R1 et R2 deux relations situŽes sur des sites diffŽrents ˆ joindre sur les attributs
dŽnotŽs tout deux Aj pour simplifier. La colonne R1.Aj peut tre envoyŽe au site de R2
jointure de R2 par R1. D’o la formule de calcul du gain indiquŽe, les doubles barres
dŽsignant la taille d’une relation. A noter que comme indiquŽ figure 47, la semi-jointure
symŽtrique de R1 par la colonne de R2 peut aussi apporter un gain. Bien sžr, une semi-
jointure ne sera intŽressante ˆ ajouter au plan que si le gain est positif. Introduire les
semi-jointures de gain positif permet donc parfois de rŽduire les tailles avant transfert,
10.7Algorithmes de SSD-1
L’algorithme implŽmentŽ dans le systme SDD1 est un des plus anciens connus qui
profite des semi-jointures [Wong77]. La fonction de cožt considŽrŽe est rŽduite aux
seuls cožts de communication. L’algorithme est basŽ sur une exŽcution initiale des
opŽrations locales pendantes de l’arbre algŽbrique optimisŽ par des descentes des
calcul de cožt pour chaque site. Le plan ainsi gŽnŽrŽ est progressivement amŽliorŽ par
chaque ajout, il est nŽcessaire de recalculer les gains des semi-jointures puisque le plan
est changŽ. Le site de transfert optimal est choisi pour l'assemblage. Avant de lancer les
d'assemblage sont ŽliminŽes. Cet algorithme trs intŽressant est dŽcrit en dŽtails dans
[Bernstein81].
10.8Algorithme de R*
est basŽ sur une compilation distribuŽe des questions. Celle-ci gŽnre des plans
optimisŽs stockŽs par partie dans les catalogues des serveurs. Les dŽcisions intersites
sont prises par le site initiateur de la question et les dŽcisions locales par les sites gŽrant
Le cožt de chaque plan est ŽvaluŽ ˆ partir de statistiques sur les bases et d’un modle de
imbriquŽes peut tre appliquŽ sur le rŽseau selon plusieurs variantes. L’une ou les deux
ensuite des accs disques. On obtient ainsi trois algorithmes diffŽrents ˆ Žvaluer :
Les mŽthodes avec semi-jointures sont aussi exploitŽes ˆ partir de l’algorithme des
boucles imbriquŽes ; pour cela, l’algorithme est modifiŽ afin d’envoyer les valeurs de la
transfert de tuples ; les tuples sont alors seulement en cas de jointure effective. L’envoi de
la colonne est possible ˆ chaque tuple ou pour un groupe de tuples afin d’Žviter un
surnombre de messages.
maximum des chemins d’accs locaux pour chaque sous-question locale [Selinger80]. Il
utilise aussi des stratŽgies de type pipeline qui permettent de dŽclencher une opŽration
avant d’avoir obtenu tous les rŽsultats, en profitant ainsi du parallŽlisme. Le choix du
plan de cožt minimum est effectuŽ par construction progressive du plan avec un
V.11.CONCLUSION ET PERSPECTIVES
Dans ce chapitre, nous avons ŽtudiŽ les problmes clŽs des systmes de bases de donnŽes
rŽparties. Aprs avoir rappelŽ les objectifs, nous avons prŽsentŽ une architecture de
rŽfŽrence, puis ŽtudiŽ les problmes de conception. Nous avons ensuite abordŽ la
permettent de mettre en Ïuvre des protocoles de validation en deux Žtapes dans des
progressŽ ces dernires annŽes, si bien que des systmes comme Oracle ou Sybase
permettent de gŽrer des copies symŽtriques, pouvant tre mises ˆ jour en parallle, capable
Une nouvelle gŽnŽration de systmes rŽpartis devraient voir le jour dans les prochaines
annŽes. Les deux points clŽs ˆ rŽsoudre sont un meilleur support de l’hŽtŽrogŽnŽitŽ et
une prise en compte de l’approche objet. Ainsi, on peut penser fŽdŽrer autour de
objets, etc. L’accs ˆ Internet et aux documents gŽrŽs sous forme d’hypertextes distribuŽs
(World Wide Web — W3) est aussi ˆ considŽrer. Les travaux menŽs dans le cadre du projet
future.Rƒfƒrences et bibliographie
[Adiba81] Adiba M., Ç Derived Relations : A Unified Mechanism for
Views, Snapshots and Distributed Data È, 7th Int. Conf. on Very Large
Data Bases, IEEE Ed., Cannes, France, Septembre 1981.
clichŽs dans le cadre d’un systme de bases de donnŽes rŽparties. Un prototype a ŽtŽ
[Bancilhon85] Bancilhon F., Korth H., Won Kim, Ç A Model of CAD Transactions È, 11th
Int. Conf. on Very Large data Bases, Stockholm, Sude, Aožt 1985.
Cet article propose un modle de transactions longues pour les bases de donnŽes en CAO. Il fut
[Bernstein81] Bernstein Ph., Goodman N., Wong E., Reeve C.L., Rothnie J.B., Ç Query
SDD-1 fut un des premiers SGBD rŽparti implŽmentŽ par Computer Corporation of America
(CCA) aux ƒtats-Unis, ˆ la fin des annŽes 1970, pour la Navy. Son optimiseur de requte est
particulirement dŽcrit dans cet article. Il est basŽ sur l’exŽcution locale des sŽlections, la
[Bernstein90] Bernstein Ph., Hsu M., Mann B., Ç Implementing Recoverable Requests
Using Queues È, ACM SIGMOD Int. Conf., ACM Ed., SIGMOD Record 19, N¡ 2, June
1990.
Cet article propose un protocole rŽsistant aux pannes pour gŽrer les flots de requtes de
transactions entre clients et serveurs. Il discute une implŽmentation en utilisant des files
Sept. 1990.
Sabrina-Star est un prototype de SGBDR rŽalisŽ ˆ l’EDF ˆ la fin des annŽes 1980 pour
interroger des bases de donnŽes hŽtŽrognes, particulirement IDS2 et DB2. Il a ŽtŽ conu ˆ
partir du noyau du SGBD relationnel Sabrina, rŽalisŽ de 1980 ˆ 1986 ˆ l’Inria, dans le projet
dirigŽ par G. Gardarin. Il offre un outil basŽ sur un systme expert pour dŽfinir des schŽmas
Ce livre, Žcrit en 1994 mais publiŽ en 1995, est une collection d’articles sur les systmes
multibases orientŽs objets. On y trouve aussi bien des descriptions de systmes que des articles de
IRO-DB est un systme fŽdŽrant bases de donnŽes relationnelles (Ingres, Oracle, etc.) et objets
(O2, Ontos, Matisse, etc.) par le biais d’un modle pivot basŽ sur les recommandations de
adaptateurs locaux faisant appara”tre chaque SGBD local comme conforme ˆ l’ODMG, protocole
de communication permettant d’Žmettre une requte OQL depuis un client vers un serveur
intŽgrŽes et un optimiseur de requtes rŽparties. Ce systme est rŽalisŽ dans le cadre d’un projet
Esprit.
[Gifford79] Gifford K., Ç Weighted Voting for Replicated Data È, Proc. of the Seventh
ACM Symposium on Operating Systems Principles, ACM Ed., pp. 150-162, Dec. 1979.
Cet article fut le premier a proposer un protocole par vote majoritaire pour la gestion de donnŽes
rŽpliquŽes synchronisŽes en temps rŽel. Une implŽmentation pour une application de type
[Lamport78] Lamport L., Ç Time, Clocks and the Ordering of Events in a Distributed
System È, Comm. of the ACM, Vol. 21, N¡7, pp. 558-565, 1987.
Cet article de rŽfŽrence proposa pour la premire fois une mŽthode simple pour gŽrer un temps
global dans un environnement rŽparti. Cette technique est aujourd’hui retenue par beaucoup de
systmes. L’idŽe consiste ˆ envoyer les temps locaux entte de chaque message, et ˆ se synchroniser
en avant sur chaque site rŽcepteur. Des garde-fous peuvent tre introduits pour Žviter les
dŽrives. L’article fait appel ˆ la thŽorie de la relativitŽ pour expliquer les mŽcanismes proposŽs.
[Lampson76] Lampson B., Sturgis H., Crash Recovery in Distributed Data Storage System,
Žtapes. Lampson et Sturgis sont connus comme Žtant les inventeurs de ce fameux protocole.
RŽalisŽ ˆ la suite de SDD-1, Multibase fut l’un des premiers SGBDR fŽdŽrant des bases
hŽtŽrognes. Le modle pivot est un modle fonctionnel connu sous le nom de Daplex.
[Litwin82] Litwin W., Esculier C., Ferrier A., Glorieux A.M., La Chimia J., Stangret C., et.
al., Ç SIRIUS Systems for Distributed Data Management È, in Distributed Data Bases, H-J.
SIRIUS fut dirigŽ par Jean Lebihan ˆ l’INRIA. L’objectif Žtait de fŽdŽrer un ensemble de
SGBD plus ou moins hŽtŽrognes et d’assurer la transparence ˆ la rŽpartition des donnŽes. Une
des principales rŽalisation fut Sirius*Delta, un SGBDR homogne construit autour du systme
RŽalitŽ 2000, systme de base de donnŽes spŽcifique intŽgrŽe au systme d’exploitation Pike.
Le projet BaBa (Base des Bases) de Witold Litwin a pris la suite de Sirius ˆ l’INRIA. L’objectif
Žtait d’interroger des bases multiples en laissant visible la multiplicitŽ. MDL est un langage
[Lohman85] Lohman G., Mohan C., Haas L., Daniels D., Lindsay B., Selinger P., Wilms
P., Ç Query Processing in R* È, in Query Processing in Database Systems, Won Kim Ed.,
Cet article dŽcrit les algorithmes implŽmentŽs dans R*, le prototype de SGBD rŽparti d’IBM,
analysŽes. Ces techniques sont ˆ la base des produits actuels d’IBM, tel DataJoiner.
[…zsu91] …zsu M.T., Valduriez P., Principles of Distributed Database Systems, Prentice
Cet ouvrage est le livre de rŽfŽrence en anglais sur les bases de donnŽes rŽparties. Il couvre en
gestion de transactions, fiabilitŽ et concurrence, bases de donnŽes fŽdŽrŽes. Chaque aspect est
traitŽ de manire trs complte. Les algorithmes sont esquissŽs et une formalisation minimum est
souvent introduite.
[Rafi91] A. Rafi, P. DeSmedt, W. Kent, M. Ketabchi, W. Litwin, M-C Shan. Ç Pegasus : A
Pegasus est un systme rŽalisŽ au centre de recherche de Hewlett Packard en Californie pour
fŽdŽrer des bases de donnŽes hŽtŽrognes autour d’un modle objet. Il est dŽcrit dans cet article.
Le langage d’interrogation est une extension de SQL en intŽgrant des appels de fonctions dans
les requtes.
[Rothnie80] Rothnie J.B., Bernstein A., S. Fox, Goodman N., Hammer M., Landers T.,
Reeve C., Shipman W., Wong E., Ç Introduction to a System for Distributed Databases
Cet article de synthse prŽsente le premier SGBDR rŽalisŽ par CCA aux ƒtats-Unis, nommŽ
SDD-1. Il devait permettre de gŽrer des bateaux pour la Navy, les systmes locaux pouvant tre
embarquŽs. Le projet a beaucoup apportŽ, notamment les techniques d’optimisation par semi-
jointures, des techniques de concurrence un peu complexes et des approches ˆ la gestion de copies
[Rosenkrantz78] Rosenkrantz D., Stearns R., Lewis P., Ç System Level Concurrency
Control for Distributed Database Systems È, ACM Transactions on Database Systems, Vol.
dŽcrites ci-dessus.
[Selinger79] Selinger P., Astrahan M., Chamberlin D., Lorie R., Price T., Ç Access Path
systme R d’IBM. Il prŽsente un modle de cožt basŽ sur des hypothses d’uniformitŽ et une
[Selinger80] Selinger P., Adiba M., Ç Access Path Selection in Distributed Database
Management Systems È, First Intl. Conf. on Databases, British Comp. Soc. Ed., Aberdeen,
Scotland, 1980.
Cet article dŽcrit le mŽcanisme de gŽnŽration des plans d’exŽcution optimisŽs dans R*, la
version distribuŽe du systme R d’IBM. Il insiste plus particulirement sur la prise en compte des
chemins d’accs locaux aux donnŽes, aspect que les optimiseurs avaient prŽcŽdemment souvent
ignorŽ.
[Sheth90] A.P. Sheth and J.A. Larson, Ç Federated Database Systems for Managing
Cet article du numŽro spŽcial de Computer Surveys sur les BD fŽdŽrŽes prŽsente une vue
[Shipman81] D. Shipman, Ç The Functional Data Model and the Data Language
Cet article prŽsente le modle fonctionnel de donnŽes et le langage Daplex associŽ. Daplex intgre
une formulation des donnŽes en terme d’entitŽs, une reprŽsentation fonctionnelle des
associations, une notion de sous-typage entre entitŽs et des constructions fonctionnelles variŽes
pour exprimer les critres de sŽlection. Il a ŽtŽ utilisŽ pour fŽdŽrer des bases de donnŽes dans
le projet Multibase.
[Skeen81] Skeen D., Ç Nonblocking Commit Protocols È, ACM SIGMOD Int. Conf., Ann
Des protocoles non bloquants, en particulier le protocole en trois Žtapes dŽcrit ci-dessus, sont
Ingres È, Proc. 2nd Berkeley Workshop on Distributed Data Management and Computer
Ingres/Star fut la premire version rŽpartie du systme Ingres, rŽalisŽe ˆ Berkeley. Cet article en
Cet article prŽsente le systme Mermaid, systme permettant de fŽdŽrer des bases de donnŽes
Cet autre article du numŽro spŽcial de Computer Surveys sur les BD fŽdŽrŽes prŽsente une
globales avec validation en deux Žtapes. Il respecte l’autonomie locale des sites participants. Ce
projet est ˆ l’origine des architectures de bases de donnŽes rŽparties commercialisŽe par IBM
autour de DB2.
[Wong77] Wong E., Ç Retrieving Dispersed Data from SDD-1 È, Proc. 2nd Berkeley
Workshop on Distributed Data Management and Computer Networks, Berkeley, Calif. 1977.
Une premire version de l’optimiseur de requtes distribuŽes de SDD-1 est proposŽe dans cet
article.
Transaction Management È, ACM Transactions on Database Systems, Vol. 16, N¡1, 1991.
Cet article dŽcrit un protocole de gestion de transactions imbriquŽes et distribuŽes, avec des
sphres d’influence dŽfinies pour chaque transaction : sphre de validation des sous-transactions
devant tre validŽes, sphre d’annulation des sous-transaction devant tre annulŽes, ceci en cas de