BASES DE DONNÉES RÉPARTIES ET RÉPLIQUÉES 

1. INTRODUCTION.................................................................................................................................................

2. QU’EST­CE­QU’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 MULTI­CLIENTS MULTI­SERVEURS.........................................................................................................................

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 SSD­1.....................................................................................................................................

10.8 ALGORITHME DE R*............................................................................................................................................

11. CONCLUSION ET PERSPECTIVES..............................................................................................................

12. RÉFÉRENCES ET BIBLIOGRAPHIE...........................................................................................................
 Chapitre V

BASES DE DONNƒES RƒPARTIES ET

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

M. Tamer …zsu, Patrick Valduriez,

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

de la Navy amŽricaine. En France, ˆ la suite du projet Cyclades qui construisit le premier

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*

au centre de recherche d’IBM ˆ San-JosŽ (* signifie N systmes R interconnectŽs). Ces

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

[Landers82], MRDSM [Litwin87], ou encore Sabrina-Star [BrŽant90]. Aujourd’hui, une

nouvelle gŽnŽration de systmes basŽs sur le modle objet et une coopŽration plus l‰che

est en train de na”tre dans les laboratoires [Burkhres94].

La fŽdŽration de bases de donnŽes existantes est une nŽcessitŽ pour un grand nombre

d’entreprises. En effet, il faut souvent accŽder de manire intŽgrŽe ˆ des donnŽes

dissŽminŽes sur les diffŽrents calculateurs du sige et des usines. Plus

prŽcisŽment, il faut offrir un systme de gestion intŽgrant des sources de donnŽes

hŽtŽrognes en assurant la transparence ˆ la distribution et ˆ l’hŽtŽrogŽnŽitŽ, ceci afin

de faciliter les dŽveloppements pour l’utilisateur. Avec les grands rŽseaux internationaux

tels Internet, le besoin de fŽdŽration de donnŽes hŽtŽrognes (tables, textes, documents

audio-visuel, gŽomŽtrie, cartes, etc.) est immense. La recherche en bases de donnŽes

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

de conception de bases rŽparties et prŽcise les diffŽrents moyens de distribuer une

table. La section 6 aborde les problmes de gestion de transactions atomiques. Les

protocoles de validation en deux et trois Žtapes sont dŽcrits. Cette section conduit ˆ

examiner dans la section suivante l’architecture de systme transactionnel DTP qui

supporte le protocole XA et l’implŽmentation des moniteurs transactionnels. La section

8 dŽveloppe les principales techniques de contr™le de concurrence adaptŽes aux

systmes rŽpartis. Puis, la section 9 aborde les mŽthodes de rŽplication l‰che qui sont

aujourd’hui en plein dŽveloppement au niveau des produits. Nous terminons le chapitre

par la section 10 — qui prŽcde bien sžr la conclusion Žtablissant un bilan et Žvoquant les

perspectives nouvelles — en analysant les techniques d’optimisation de requtes, leurs

fondements et quelques algorithmes reprŽsentatifs, plus particulirement ceux de SDD1

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

(BDR). Nous introduisons les diffŽrentes formes possibles de coopŽration de bases de

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.

Notion 1 : Base de donnŽes rŽpartie (Distributed database)

Ensemble de bases de donnŽes gŽrŽes par des sites diffŽrents et apparaissant ˆ

l'utilisateur comme une base unique.

Une base de donnŽes rŽpartie peut aussi tre vue comme une collection de bases de

donnŽes logiquement reliŽes, distribuŽes sur un rŽseau. Cependant, la dŽfinition

prŽcŽdente est plus complte, car elle insiste sur le fait que la base rŽpartie doit

appara”tre comme une base unique ˆ l’utilisateur.

Afin d’illustrer, considŽrons un rŽseau d’ordinateurs localisŽs ˆ Paris, Dijon et Bordeaux.

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.

Figure 1 — Exemple de donnŽes rŽparties.

2.2SchŽma global

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

exemple, le schŽma global de la base de donnŽes rŽpartie prŽsentŽe en exemple ci-

dessus est dŽfini figure 2. Il s’agit d’une vision relationnelle de la base. Une vision plus

conceptuelle, en termes d’entitŽ et d’association est donnŽe figure 3. Le schŽma global

ignore les concepts d’implŽmentation. A ce titre, il est souvent appelŽ schŽma

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

locales sont les seules matŽrialisŽes sur des disques.

BUVEURS (NB, NOM, PRƒNOM, VILLE)

COMMANDES (NB, NV, DATE, QTƒ)
VINS (NV, CRU, ANNƒE, DEGRƒ)
PRODUCTEURS (NP, NOM, RƒGION)
PRODUIT (NV, NP, QTƒ)
Figure 2 — Exemple de schŽma global relationnel.

Figure 3 — SchŽma global associŽ entitŽ-association.

2.3Quelques dŽfinitions de base

Nous prŽcisons maintenant les composants essentiels nŽcessaires pour gŽrer des bases

de donnŽes rŽparties. Le Systme de Gestion de Bases de DonnŽes RŽparties

(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

intŽgrŽ en une base unique.

 Notion 2 : SGBD rŽparti ou SGBDR (Distributed DBMS ou DDBMS)

Systme qui gre des collections de BD logiquement reliŽes, distribuŽes sur un

rŽseau, en fournissant un mŽcanisme d'accs qui rend la rŽpartition transparente
aux utilisateurs.

Notion 3 : Client de SGBDR (DDBMS client)

Application qui accde aux informations distribuŽes par les interfaces du SGBDR.

Notion 4 : Serveur de SGBDR (DDBMS server)

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.

Notion 5 : Noeud ou Site de SGBDR (DDBMS node ou site)

Calculateur dans le rŽseau participant ˆ la gestion d’une base de donnŽes rŽpartie.

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.

2.4Quelques dŽfinitions complŽmentaires

La coopŽration de bases de donnŽes locales dissŽminŽes sur diffŽrents sites au sein

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

interopŽrables. Si un langage commun permet de les interroger sans cacher l’existence

de plusieurs bases, on parle de multibases : les bases de donnŽes sont alors faiblement

couplŽes, par l’intermŽdiaire du client.

Notion 6 : BD interopŽrables (Interoperable DB)

BD capable d'Žchanger des donnŽes en comprenant mutuellement ce qu'elles

reprŽsentent.

Plusieurs bases de donnŽes cooprent afin de rŽaliser une BD rŽpartie ou plus

simplement des BD interopŽrables. Les BD participantes peuvent tre de mme nature,

c’est-ˆ-dire gŽrŽes avec un mme modle et accŽdŽes par un mme langage, ou de nature

diffŽrentes. La BD rŽpartie est alors qualifiŽe d’homogne ou d’hŽtŽrogne. Plus

particulirement, le terme de BD rŽpartie homogne dŽsigne gŽnŽralement une BD

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

donnŽes locales participant ˆ une BD rŽpartie hŽtŽrogne permet de distinguer les

multibases des bases fŽdŽrŽes.

Notion 7 : Multibase (Multibase)

Plusieurs bases de donnŽes hŽtŽrognes capable d'interopŽrer avec une application

via un langage commun (sans modle commun).

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

Afin de souligner l’intŽrt de la coopŽration de bases hŽtŽrognes, nous introduisons

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

ou le modle rŽseau, stockant les donnŽes de gestion de l’entreprise, appelŽ systme

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.

Figure 4 — Exemple de bases de donnŽes ˆ intŽgrer.

2.6Avantages et inconvŽnients

L’intŽgration de bases de donnŽes homognes ou hŽtŽrognes dans une base de donnŽes

rŽpartie prŽsente de nombreux avantages, parmi lesquels :

· la possibilitŽ de prendre en compte la rŽpartition gŽographique des donnŽes ;

· la possibilitŽ de prendre en compte la distribution fonctionnelle des donnŽes ;

· une meilleure disponibilitŽ des donnŽes en prŽsence de panne ou de

dysfonctionnement des applications ;

 · une plus grande flexibilitŽ afin d’assurer le partage des donnŽes hŽtŽrognes et

rŽparties ;

· des performances espŽrŽes meilleures du fait de l’Žclatement des donnŽes sur

plusieurs bases gŽrŽes par des serveurs diffŽrents mieux adaptŽs ;

· une intŽgration du rŽseau qui est cachŽ par le SGBDR.

Cependant, l’intŽgration de bases de donnŽes rŽparties, particulirement de bases

hŽtŽrognes, prŽsente quelques difficultŽs majeures :

· la complexitŽ du SGBDR dont nous allons Žtudier les mŽcanismes dans la

suite ;

· le manque d'expŽrience notamment dans l’intŽgration de bases hŽtŽrognes ;

· la distribution du contr™le des donnŽes entre plusieurs sites, ce qui pose en

gŽnŽral des problmes de cohŽrence non triviaux ;

· la difficultŽ de changement, par exemple d’intŽgration d’un nouveau type de

SGBD, qui peut cependant tre moindre qu’avec un systme centralisŽ

nŽcessitant une migration.

Tout ceci conduit les utilisateurs ˆ prŽfŽrer les solutions multibases aux solutions bases

de donnŽes fŽdŽrŽes, bien que ces dernires soient plus prometteuses.

V.3.OBJECTIFS DES SGBDR

Dans cette section, nous prŽcisons les objectifs des SGBDR qui se rŽsument aux aspects

clŽs suivants :

· multi-clients multi-serveurs ;

· transparence ˆ la localisation des donnŽes ;

· meilleure disponibilitŽ des donnŽes ;

· autonomie locale des sites ;

 · support de l’hŽtŽrogŽnŽitŽ .

3.1Multi-clients multi-serveurs

Dans le contexte du client-serveur, un client peut demander l’exŽcution d’une requte ˆ un

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

de concurrence adaptŽs, garantissant que l’effet de l’exŽcution simultanŽe des

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.

Au-delˆ, un SGBDR doit permettre l’exŽcution de requtes distribuŽes, mettant en jeu

plusieurs serveurs.

Notion 9 : Requte distribuŽe (Distributed request)

Requte Žmise par un client dont l’exŽcution nŽcessite l’exŽcution de N sous-

requtes sur N serveurs avec N >1.

Une transaction qui met en Ïuvre plusieurs serveurs est appelŽe transaction distribuŽe.

A noter qu’une transaction distribuŽe peut simplement tre composŽe de plusieurs

requtes distantes, chacune Žtant exŽcutŽe par un serveur diffŽrent. Souvent, une

transaction distribuŽe comportera des requtes distribuŽes.

En rŽsumŽ, la figure 5 illustre les modes de fonctionnement multiclients multiserveurs.

Figure 5 — Fonctionnement multiclients multiserveurs.

3.2Transparence ˆ la localisation des donnŽes

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

contenant pas la localisation des donnŽes.

Notion 10 : Transparence ˆ la localisation (Location transparency)

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 avantages de la transparence ˆ la localisation sont tout d’abord de simplifier la vue

utilisateur et l’Žcriture des requtes, mais surtout d’introduire la possibilitŽ de dŽplacer

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 :

0SELECT NOM, PRŽNOM

1FROM BUVEURS B, VINS V, COMMANDES C

2WHERE CRU = 'VOLNAY' AND DEGRE > 12 AND C. QTŽ > 100

3AND C.NV = NV AND C.DATE ³ 1/10/92 AND B.NB = C.NB

4AND B.VILLE = "PARIS"

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

modifier la requte et plus gŽnŽralement les programmes d’application.

La transparence ˆ la localisation prŽsente cependant l’inconvŽnient de contraindre le

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

d’indŽpendance ˆ la localisation a ŽtŽ souvent mis en cause. Un compromis a pu tre

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

de table et <base> un nom de base. Le nom de base permet de dŽterminer de manire

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

nŽcessite de modifier le programme. L’utilisation d’une vue ou d’un alias permet de

retrouver cette indŽpendance. L’utilisation de nom hiŽrarchique avec vue ou/et alias est

donc un bon compromis adoptŽ par la plupart des SGBDR.

3.3Meilleure disponibilitŽ

Une des justifications essentielles d’un SGBDR est sans doute l’apport en matire de

disponibilitŽ des donnŽes. Tout d’abord, la rŽpartition permet de ne plus dŽpendre

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

Žvoluer indŽpendamment pour converger ultŽrieurement. Cette fonctionnalitŽ appelŽe

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

correctement exŽcutŽes, ou aucune ne doit l’tre. Dans le cas contraire, la base de

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.

La difficultŽ en rŽparti provient de la non centralisation du contr™le : un site peut

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

leurs consacreront une section particulire dans la suite.

Figure 6 — NŽcessitŽ de transactions atomiques.

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

de faciliter la coopŽration, il est nŽcessaire de conna”tre les schŽmas des objets ou

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

de dictionnaire sont illustrŽs figure 7 avec trois sites.

 Figure 7 — CoopŽration des dictionnaires de schŽmas.

3.5HŽtŽrogŽnŽitŽ

Nous avons dŽjˆ vu ci-dessus le besoin des entreprises en matire d’accs intŽgrŽ ˆ des

bases de donnŽes hŽtŽrognes existantes. Un SGBDR hŽtŽrogne doit tre capable

d’unifier modles et langages comme reprŽsentŽ figure 8, ceci afin de gŽrer des bases

fŽdŽrŽes. L’unification s’effectue en gŽnŽral par un langage pivot afin de limiter le

nombre de conversions de modles ˆ rŽaliser.

Figure 8 — Unification des modles et langages.

Au delˆ de la possibilitŽ d’unifier les modles de donnŽes et les langages d’accs pour

accŽder de manire uniforme ˆ des vues intŽgrŽes, le problme de l’intŽgration

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

reprŽsentation diffŽrente. A l’opposŽ, deux donnŽes de mme nom peuvent tre

sŽmantiquement diffŽrentes. Il faut donc tre capable de rapprocher des schŽmas,

d’isoler les structures identiques, de reconna”tre les donnŽes diffŽrentes, et d’intŽgrer

l’ensemble des schŽmas en un schŽma unique. Ces fonctions nŽcessitent un outil d’aide ˆ

l’intŽgration de schŽmas.

Notion 11 : IntŽgration de schŽmas (Schema integration)

ProcŽdŽ consistant ˆ rapprocher des schŽmas sŽmantiquement diffŽrents afin de

constituer un schŽma unique Žquivalent.

L’Žquivalence des schŽmas est une propriŽtŽ importante. Deux schŽmas sont

Žquivalent si toute instance de base correspondant ˆ un schŽma peut tre transformable

en une instance conforme ˆ l’autre schŽma et rŽciproquement. L’Žquivalence est difficile

ˆ vŽrifier.
V.4.ARCHITECTURE DES SGBDR

Dans cette section, nous Žtudions les composants essentiels d’un SGBDR d’un point de

vue fonctionnel. Nous en dŽduisons une architecture type de systme.

4.1Fonctions d’un SGBDR

Un SGBD reoit des requtes rŽfŽrenant des objets d’une base de donnŽes rŽparties. Il

assure la dŽcomposition des requtes distribuŽes en sous-requtes locales envoyŽes ˆ

chaque site. La dŽcomposition prend en compte les rgles de localisation. Lors de

l’Žvaluation globale de la requte, il faut ˆ la fois minimiser les transferts de donnŽes et

maximiser le parallŽlisme. L’Žvaluation et l’optimisation des requtes rŽparties est donc

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

sont stockŽs dans des dictionnaires aussi gŽrŽs par le SGBDR.

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

la gestion de l’atomicitŽ des transactions distribuŽes. En gŽnŽral, le SGBDR s’appuiera

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,

appelŽ schŽma local.

Notion 12 : SchŽma local (Local schema)

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

Notion 13 : SchŽma exportŽ (Export schema)

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

est en gŽnŽral toujours exprimŽ dans le modle pivot du SGBDR.

Notion 14 : SchŽma importŽ (Import schema)

SchŽma exportŽ reu par un site client.

L’ensemble des schŽmas exportŽs par tous ou certains sites clients peut tre intŽgrŽ dans

un schŽma unique exprimŽ dans le modle de rŽfŽrence du SGBDR et dŽcrivant

globalement la base rŽpartie. Un tel schŽma est appelŽ schŽma global.

Notion 15 : SchŽma global (Global schema)

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

importŽs, et sont de ce fait appelŽ vues intŽgrŽes (ou schŽmas intŽgrŽs).

Notion 16 : Vue intŽgrŽe (Integrated view)

SchŽma dŽcrivant dans le modle du SGBDR les donnŽes de la BDR accŽdŽe par
une application.

La figure 9 rŽsume les diffŽrents schŽmas introduits. La plupart des SGBDR

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

conception de la base. Dans un systme homogne, le schŽma exportŽ est un ensemble de

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.

Figure 9 — Les diffŽrents niveaux de schŽmas pour un SGBDR hŽtŽrogne.

4.3Architecture de rŽfŽrence

L’architecture de rŽfŽrence que nous proposons pour un SGBDR s’articule autour de

trois niveaux de fonctionnalitŽs :

· le niveau local prŽsent sur chaque serveur permet d’exporter les donnŽes

locales selon le modle pivot du SGBDR, par exemple en relationnel avec un

SGBDR basŽ sur le relationnel.

· le niveau communication permet de transmettre les sous-requtes en

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

inverse ce niveau transmet les rŽponses en conformitŽ au schŽma exportŽ.

· le niveau interopŽrable permet de formuler des requtes mettant en jeu des vues

intŽgrŽes de la base ; il assure la dŽcomposition des requtes en sous-requtes

et le passage des vues intŽgrŽes aux diffŽrents schŽmas importŽs ; il rŽalise

donc l’intŽgration des diffŽrents systmes dŽjˆ uniformisŽs par le niveau

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

aux serveurs et de dŽlivrer les rŽsultats au niveau interopŽrable matŽrialisŽ par un

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

local et les transmet au module client sous forme de messages.

Figure 10 — Architecture type d’un SGBDR avec niveaux de schŽmas.

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

du schŽma exportŽ au schŽma local et traduit les requtes en programmes d’accs au

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

l’architecture de rŽfŽrence proposŽe.

Figure 11 — Architecture type d’un SGBDR et requtes de manipulation.

4.4GŽnŽrations de prototypes

A partir de l’architecture de rŽfŽrence dŽfinie ci-dessus, diffŽrents choix sont possibles.

Un choix important est celui du modle pivot et du langage pivot. Un autre est le degrŽ

d’hŽtŽrogŽnŽitŽ permis, notamment les possibilitŽs de rŽconciliations sŽmantiques

offertes entre donnŽes hŽtŽrognes. Ces choix permettent de distinguer trois

gŽnŽrations de SGBDR.

La premire gŽnŽration est basŽe sur le modle relationnel qui offre l’avantage de

simplicitŽ et d’existence de standards reconnus. Il s’agit des systmes relationnels rŽpartis

dont les premiers ont ŽtŽ construits dans les annŽes 75-82, comme SDD1 [Rothnie80],

Sirius Delta [Litwin82], R* [Williams82] et Ingres/Star [Stonebraker77]. Ce sont ces

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

La seconde gŽnŽration est plus ambitieuse en matire d’hŽtŽrogŽnŽitŽ. Il s’agit des

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-

87 et ont pour noms Mermaid [Templeton87], Multibase [Landers82], MSQL [Litwin87],

Sabrina-Star [BrŽant90]. Ils sont capables de fŽdŽrer des BD hŽtŽrognes autour de SQL.

Ils implŽmentent les schŽmas exportŽs, importŽs et intŽgrŽs. L’objectif est de

permettre un accs intŽgrŽ ˆ des bases locales prŽsentant une large diversitŽ syntaxique

et sŽmantique. La diversitŽ syntaxique rŽsulte des diffŽrences dans les modles de

donnŽes locaux et impose des traductions. La diversitŽ sŽmantique rŽsulte des

diffŽrences de points de vues lors de la conception des bases locales, notamment du

point de vue structure, terminologie, et Žchelle. Ces diffŽrences rendent l’intŽgration de

schŽmas nŽcessaire. La dŽfinition d’un schŽma intŽgrŽ s’effectue en trois Žtapes :

· Comparaison des schŽmas. Elle permet d’isoler les similaritŽs et diffŽrences de

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

accro”tre les similaritŽs et marquer les diffŽrences.

· Fusion des schŽmas. Cette dernire Žtape intgre deux ou plusieurs schŽmas

exportŽs unifiŽs par l’Žtape prŽcŽdente en un schŽma intŽgrŽ.

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

dans des produits de middleware.

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

concepts de type et sous-type, d’opŽration, d’attribut multivaluŽ et d’association, le

modle objet permettrait une meilleure intŽgration de donnŽes hŽtŽrognes. Multibase,

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

rŽ-identification, l’intŽgration de SGBD relationnels dans un environnement objet,

l’optimisation de requtes objet distribuŽes, la gestion d'associations entre objets

intŽgrŽs, la mise ˆ jour d’objets intŽgrŽs, etc.

V.5.CONCEPTION DES BDR

Dans cette section, nous examinons les problmes soulevŽs par la conception des bases de

donnŽes rŽparties, notamment les diffŽrents types de rŽpartition de donnŽes possibles.

5.1Conception ascendante ou descendante

Deux approches se distinguent nettement pour concevoir une base de donnŽe rŽpartie.

La conception descendante est utilisŽe lors de la constitution de nouvelles bases de

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

conduit ˆ la dŽfinition des schŽmas locaux.

Au contraire, la conception ascendante permet l’intŽgration de BD locales existantes

dans une base fŽdŽrŽe. Elle consiste ˆ intŽgrer des schŽmas locaux existants afin de

constituer un ou plusieurs schŽmas globaux (voir figure 12.b). Dans ce cas, la

distribution des donnŽes est prŽexistante. Cette approche nŽcessite plus souvent une

rŽconciliation sŽmantique des schŽmas participants comme vu ci-dessus.

Figure 12 — Conception des bases rŽparties.

5.2Techniques de fragmentation

La conception descendante d’une base de donnŽes rŽpartie conduit ˆ distribuer sur

diffŽrents sites des parties appelŽs fragments d’une table globale. Par une approche

plus synthŽtique, la conception ascendante aboutit ˆ un rŽsultat similaire, une table

globale Žtant aussi divisŽe en fragments.

Notion 17 : Fragment (Fragment)

Sous-table obtenue par sŽlection de lignes et de colonnes ˆ partir d’une table

globale, localisŽe sur un site unique.

A partir d’une table globale, la fragmentation peut d’une part s’effectuer par sŽlection de

lignes : la fragmentation horizontale correspond ˆ ce type de dŽcoupage, comme

illustrŽ figure 13.a .

Notion 18 : Fragmentation horizontale (Horizontal fragmentation)

DŽcoupage d’une table en sous-table par utilisation de prŽdicats permettant de

sŽlectionner les lignes appartenant ˆ chaque fragment.

Ce type de fragmentation est adaptŽ ˆ la rŽgionalisation ou dŽpartementalisation dans

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,

par projections sur des colonnes.

Notion 19 : Fragmentation verticale (Vertical fragmentation)

DŽcoupage d’une table en sous-table par projections permettant de sŽlectionner les

colonnes composant chaque fragment.

La fragmentation verticale permet de dŽcomposer une table par projections comme

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

exemple, une table dŽcrivant des produits sera partitionnŽe en Produit_Sige et

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,

numŽro, descriptif, conditionnement). Par jointure sur l’attribut commun numŽro, la

table pourra tre recomposŽe.

Figure 13 — Techniques de fragmentation.

Enfin, une table peut tre rŽpliquŽe sur diffŽrents sites.

Notion 20 : RŽplication (Replication)

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.

5.3Extension de la fragmentation horizontale

La fragmentation horizontale permet donc de dŽcouper une table R en fragments F i tels

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

propriŽtŽs suivantes doivent donc tre vŽrifiŽes :

· " ij Pi Ç Pj = Faux Žquivalent ˆ Fi(R) Ç Fj(R) = ¯ ;

· Èi Pi = Vrai Žquivalent ˆ Èi Fi(R) = R.

Une fragmentation horizontale par des prŽdicats de restrictions {P i} constitue une

fragmentation primaire ˆ partir de laquelle il est possible de dŽriver une autre

fragmentation par semi-jointure avec une autre relation. Rappelons que la semi-jointure

de S par R est une jointure suivie d’une projection sur les tuples de S. On obtient alors

une fragmentation horizontale dŽrivŽe d’une fragmentation horizontale primaire d’une

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

appliquŽe ˆ partir de n’importe quelle table fragmentŽe, donc de manire rŽcurrente. Un

des problmes de la fragmentation dŽrivŽe est de prouver la disjonction des fragment et

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

suffisante pour la complŽtude est alors l’existence d’une contrainte rŽfŽrentielle

stipulant que S rŽfŽrence R par la clŽ : tout tuple de S sera sur le site du tuple de R qu’il

rŽfŽrence. Ce mode de partitionnement est particulirement frŽquent dans les

applications.

5.4Fragmentation mixte

La fragmentation mixte rŽsulte de l’application successive d’opŽrations de

fragmentation horizontale FH et de fragmentation verticale FV sur une relation globale.

La recomposition de la relation initiale se fait par une succession inverse d’unions

(recomposition des fragments horizontaux) et de jointures (recomposition des fragments

verticaux). Elle peut donc tre dŽfinie comme une vue ˆ partir des relations composant les

fragments. La figure 14 illustre la dŽcomposition d’une relation R en fragments R 3,R4, R5,

R8, R10, R11 et R7. L’arbre de dŽcomposition permet de retrouver l’expression permettant

de reconstruire R par jointures et unions ˆ partir de ses fragments comme indiquŽ.

 Figure 14 — Fragmentation mixte d’une relation R.

5.5Allocation des fragments

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

un SGBDR doit permettre la dŽfinition et la localisation des fragments par une

commande mise ˆ la disposition des administrateurs. Une telle commande a ŽtŽ

proposŽe par exemple dans le systme R* avec la syntaxe suivante :

5DISTRIBUTE TABLE <NOM_DE_RELATION>

6{HORIZONTALLY | VERTICALLY} [REPLICATED]

7INTO <NOM>[(<ATTRIBUT>[,<ATTRIBUT>]É)] [WHERE <QUALIF> ]

8IN SEGMENT <NOM_DE_SEGMENT>@<SITE>

9[INTO <NOM>[(<ATTRIBUT>[,<ATTRIBUT>]É)] [WHERE <QUALIF> ]

10IN SEGMENT <NOM_DE_SEGMENT>@<SITE>]É

Cette commande est utilisŽe figure 17 afin de partitionner verticalement la table

COMMUNE en deux fragments VILLE et MAIRIE. Le segment permet de prŽciser la

partition et le site de stockage. Plusieurs segments sont allouŽs en cas de rŽplication

d’un fragment.

Figure 15 — Localisation des fragments.

 Soit la table :
COMMUNE (N¡C, NOM, N¡D, POPU, TYPE, É, NOM, PRŽNOM, INSCRIPTION, É)

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

fragmente verticalement COMMUNE en :

VILLE (N¡C, NOM, N¡D, POPU, TYPE, É)
MAIRE (N¡C, NOM, PRŽNOM, INSCRIPTION, É)

Figure 16 — Exemple de fragmentation verticale avec R*.

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

fragments. Puis elle demande de trouver la distribution optimale de F sur S. L’optimum

est atteint lorsque la distribution minimise les cožts de communication, stockage et

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

communication unitaire de Si ˆ Sj. Le cožt de stockage du fragment F k sur le site Si est

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

minimisent les cožts de communication et stockage cumulŽs, donnŽs par la formule :

 cožt =Si ( Sj (Xj x Uj x Cij + Rj x min {Cij|xj=1} ) ) + Si Xi x Di.

Le problme est NP-complet. De plus, il peut tre sujet ˆ des contraintes de capacitŽ

stockage, de dŽbit de communication et de temps de rŽponse. L’assignation optimale

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

au cožt (perte en Žcriture).

V.6.GESTION DE TRANSACTIONS

Dans cette section, nous Žtudions les problmes liŽs ˆ la gestion de transactions dans les

systmes de bases de donnŽes rŽparties.

6.1PropriŽtŽs des transactions

Une transaction est composŽe d’une suite de requtes dŽpendantes de 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. Nous rŽsumons ces propriŽtŽs ci-dessous.

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

d’Žchec, l'Žtat cohŽrent initial doit tre restaurŽ.

6.1.1.3Isolation

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

modifications seront conservŽes en cas de panne.

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

d’annuler une transaction. Il faut donc coordonner les validations.

6.2Validation en deux phases

6.2.1Principe

Le protocole de validation en deux phases a ŽtŽ proposŽ [Lampson76] afin de

coordonner l’exŽcution des commandes Ç COMMIT È par tous les sites participant ˆ une

transaction. Le principe consiste ˆ diviser la validation en deux phases. La phase 1 rŽalise

la prŽparation de l’Žcriture des rŽsultats des mises ˆ jour dans la BD et la centralisation

du contr™le. La phase 2, rŽalisŽe seulement en cas de succs de la phase 1, intgre

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

des participants. Nous rŽsumons ces concepts ci-dessous.

 Notion 21 : Protocole de validation en deux Žtapes (Two Step Commit)

Protocole permettant de garantir l’atomicitŽ des transactions dans un systme

rŽparti, composŽ d’une prŽparation de la validation et de centralisation du
contr™le, et d’une Žtape d’exŽcution.

Notion 22 : Coordinateur de validation (Commit Coordinator)

Noeud d'un systme rŽparti qui dirige le protocole en centralisant le contr™le.

Notion 23 : Participant ˆ validation (Commit Participant)

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

Le protocole client-multiserveurs de validation en deux Žtapes dŽcoule des concepts

prŽcŽdents. Le client joue le r™le de coordinateur et les serveurs celui de participants.

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

participants rŽpondent positivement (OK), le message COMMETTRE (en anglais COMMIT)

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

les autres sites de dŽfaire la transaction (message ABORT).

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

coordinateur afin de lui signaler que la transaction est maintenant terminŽe.

Figure 17 — Validation en deux Žtapes avec succs.

Le cas de la figure 18 est plus difficile : le participant 2 est en panne et ne peut donc

rŽpondre au message de demande de prŽparation. Une non rŽponse est assimilŽe ˆ un

refus. Le coordinateur annule donc la transaction et envoie le message ABORT. Le

participant 1 annule la transaction. Le participant 2 l’annulera lorsqu’il repartira aprs la

panne, une transaction non prte Žtant toujours annulŽe.

Figure 18 — Validation en deux Žtapes avec panne totale du participant 2.

Le cas de la figure 19 est encore plus difficile : le participant 2 tombe en panne aprs avoir

rŽpondu positivement ˆ la demande de prŽparation. Le coordinateur envoie donc le

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

disque. Lors de la procŽdure de reprise, le journal sera examinŽ. La transaction Žtant

dŽtectŽe prte ˆ commettre, son Žtat sera demandŽe au coordinateur (ou ˆ un participant

quelconque) par un message appelŽ STATUS. En rŽponse ˆ ce message, la validation sera

confirmŽe et les mises ˆ jour seront appliquŽes ˆ partir du journal. Les deux sous-

transactions seront donc finalement validŽes.

Figure 19 — Validation en deux Žtapes avec panne partielle du participant 2.

6.2.3Commit distribuŽ ou centralisŽ

En principe, la dŽcision de valider ou d’annuler une transaction est prise par le

coordinateur qui centralise le contr™le. Afin de dŽcider, il compte les messages OK suite

au PREPARE. La dŽcision est positive ( COMMIT) si le nombre de OK reus est Žgal au

nombre de participants. Dans un rŽseau sans perte de message, cette dŽcision peut tre

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Žcider de valider lorsque ce nombre est Žgal au nombre de participants. La dŽcision

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

la version centralisŽe du protocole, rŽputŽe plus fiable.

Figure 20 — Validation ˆ deux phases centralisŽe ou distribuŽe.

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

(rŽception/envoi) de messages, comme illustrŽ figure 22.

Figure 21 — Logiques du coordinateur et des participants.

Figure 22 — Etats et transitions d’Žtats de la validation en deux Žtapes.

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

soit sans perte de message, ce protocole pessimiste garantit la cohŽrence. Un protocole

optimiste consisterait ˆ forcer la transaction locale ˆ l’Žtat COMMIT en cas de doute. Un tel

protocole ne garantit pas la cohŽrence avec le coordinateur.

6.3Commit en trois phases

Afin de lever l’inconvŽnient du protocole de validation ˆ deux phases qui est donc qu’en

cas de time-out en Žtat Ready, le participant est bloquŽ, un protocole de validation 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

mme Žtat terminal.

Figure 23 — ƒtats et transitions d’Žtats de la validation en trois Žtapes.

6.4Protocole arborescent TP

TP est le protocole standard proposŽ par l’ISO dans le cadre de l’architecture OSI afin

d’assurer une validation cohŽrente des transactions dans un systme distribuŽ. Le

protocole est arborescent en ce sens que tout participant peut dŽclencher une sous-

transaction distribuŽe. Un site responsable de la validation de la sous-transaction est

choisi. Un coordinateur est responsable de ses participants pour la phase 1 et collecte les

PREPARE. Il demande ensuite la validation ou l’annulation selon la dŽcision globale ˆ un

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

figure 24 illustre ce type de protocole hiŽrarchique avec point de validation.

Figure 24 — Le protocole hiŽrarchique avec point de validation TP.

6.5Bilan sur la gestion de transactions

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

des mises ˆ jour effectuŽes depuis la dernire sauvegarde.

Les techniques de gestion de transactions atomiques sont trop limitŽes dans le cas de

transactions longues. Il faut alors dŽcouper la transaction en sous-transactions, chacune

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

validŽes. Ces principes conduisent ˆ dŽfinir un modle de transactions imbriquŽes

permettant une plus grande flexibilitŽ que le tout ou rien [Bancilhon85]. De tels modles

ne sont pas encore implŽmentŽs dans les SGBD rŽpartis.

V.7.MONITEURS TRANSACTIONNELS

Les moniteurs transactionnels implŽmentent le protocole de validation en deux Žtapes

vu ci-dessus dans le cadre de systmes hŽtŽrognes. Au-delˆ, ils ont d’autres objectifs et

obŽissent ˆ des standards que nous prŽsentons ci-dessous.

7.1Les objectifs

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

gestions de caches et un support multifilires aux requtes.

7.2Modle de moniteur transactionnel

Un modle de moniteur transactionnel a ŽtŽ proposŽ par l’X/OPEN : il s’agit du modle

DTP (Distributed Transaction Processing). Ce modle d’architecture est reprŽsentŽ figure

25. La gestion de transaction ACID pour un programme d’application AP est assurŽe par

le gestionnaire de transactions TM (Transaction Manager). Celui-ci est distribuŽ entre le

client et le serveur. Ses composants dialoguent par l’intermŽdiaire d’un gestionnaire de

communication CRM (Communication Request Manager). Le composant serveur s’adresse ˆ

des gestionnaires de ressources RM (Request Manager) qui assurent les fonctions de

validation pour les ressources gŽrŽes. Un gestionnaire de ressources peut reprŽsenter un

gestionnaire de fichiers, un SGBD ou un pŽriphŽrique recouvrable.

Figure 25 — Modle d’architecture DTP.

L’architecture propose deux interfaces pour lesquelles ont ŽtŽ ŽlaborŽs des standards :

· TX est l’interface du gestionnaire de transaction TM avec l’applicatif ; il s’agit

d’une API permettant d’invoquer le moniteur transactionnel.

· XA est l’interface du gestionnaire de ressource RM. Il s’agit donc d’une interface

que tout gestionnaire de donnŽes doit offrir afin de s’interfacer avec un

moniteur transactionnel.
Ces interfaces et plus gŽnŽralement l’architecture DTP permettent de mettre en Ïuvre le

protocole de validation en deux Žtapes hiŽrarchique TP vu ci-dessus.

7.3Interface applicative TX

7.4L’interface applicative TX se compose des primitives suivantes :

· tx_open qui ordonne au TM d’initialiser la communication avec tous les RM

dont les librairies d’accs ont ŽtŽ liŽes ˆ l’application ;

· tx_begin qui ordonne au TM de demander aux RM de dŽbuter une transaction ;

· tx_commit ou tx_rollback qui ordonne au TM de coordonner soit la validation

soit l’abandon de la transaction sur tous les RM impliquŽs ;

· tx_set_transaction_timeout qui positionne un timeout sur les transactions ;

· tx_info qui permet d’obtenir des informations sur l’Žtat de la transaction.

En dehors des primitives de service, cette API permet donc essentiellement de

commencer une transaction et de la terminer avec succs ou en Žchec. Elle est globale et

simple et cache les protocoles tels TP mis en Ïuvre au sein du moniteur.

7.5Interface ressource XA

L’interface XA est celle que doit fournir toute ressource. Il s’agit de fait des primitives

que doit tre capable de comprendre un participant au protocole de validation en deux

Žtapes. Ces primitives sont :

· xa_open qui ouvre un contexte pour l’application ;

· xa_start qui dŽbute une transaction ;

· xa_end qui indique au RM qu’il n’y aura plus de requtes pour le compte de la

transaction courante ;

· xa_prepare qui lance l’Žtape de prŽparation du commit ˆ deux phases ;

· xa_commit qui valide la transaction ;

 · xa_rollback qui abandonne la transaction et demande l’annulation de ses effets.

Toute ressource implŽmentant ces primitives peut donc s’intŽgrer dans un moniteur

transactionnel conforme ˆ l’architecture DTP.

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

transactions rŽparties. Les principaux moniteurs transactionnels sont :

· Top End de AT&T. Celui-ci supporte des agents Ç 3270 È, prend en compte des

bases hŽtŽrognes distribuŽes et offre des outils d’administration graphique

sous Motif.

· CICS/6000 de IBM. C’est une nouvelle version du vieux moniteur CICS d’IBM. Il

tourne sous UNIX, est capable d’intŽgrer l’architecture distribuŽe DCE et de

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

l’asynchronisme des clients, gre des prioritŽs et assure le routage de requtes

dŽpendant des donnŽes.

· Encina de Transarc. Celui-ci propose une approche bo”te ˆ outils pour

construire des applications transactionnelles distribuŽes sur des

environnements hŽtŽrognes ; il supporte DCE, un service de sŽcuritŽ, et

permet une gestion de fichiers transactionnels.

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

Aprs avoir ŽtudiŽ les protocoles et architectures pour la gestion de transactions

atomiques distribuŽes, nous abordons dans cette section les problmes connexes de

gestion des accs concurrents. 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).

8.1Objectifs

L’objectif gŽnŽral est de rendre invisible aux clients le partage simultanŽ des donnŽes.

Ceci s’effectue au moyen de protocoles spŽciaux permettant de synchroniser les mises a

jour afin d'Žviter pertes de mises ˆ jour et apparitions d’incohŽrences.

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

donc ŽcrasŽe par celle de T1.

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

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.

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

une mme donnŽe.

La rŽsolution des problmes ŽvoquŽs dans un systme rŽparti nŽcessite tout d’abord une

rŽsolution au niveau de chaque serveur par application d’algorithmes de contr™le de

concurrence. Ceci n’est en gŽnŽral pas suffisant car il existe des risques de conflits

globaux, ce qui rend nŽcessaire la synchronisation des sites.

8.2La thŽorie de base

Afin de mieux caractŽriser les exŽcutions simultanŽes correctes, une condition plus

formelle appelŽe sŽrialisabilitŽ des transactions a ŽtŽ introduite.

Notion 24 : SŽrialisabilitŽ des transactions (Transaction Serializability)

PropriŽtŽ stipulant que toute exŽcution simultanŽe de transactions doit donner le

mme rŽsultat qu'une exŽcution sŽquentielle dans un ordre quelconque.

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

d’opŽrations rŽsultant d’une exŽcution simultanŽe d’un ensemble de transactions, il

appara”t que l’ordre de certaines opŽrations ne peut tre changŽ sans changer le rŽsultat,

du fait de la non commutativitŽ des opŽrateurs exŽcutŽs (par exemple, addition et

multiplication).

Les chercheurs ont ainsi aboutit ˆ dŽfinir la notion de prŽcŽdence de transactions dans

une exŽcution simultanŽe.

 Notion 25 : PrŽcŽdence (Precedence)

PropriŽtŽ stipulant qu’une transaction a accompli une opŽration Oi sur une

donnŽe avant qu’une autre transaction accomplisse une opŽration O j, Oi et Oj
n’Žtant pas commutative ({Oi ; Oj} {Oj ; Oi}).

La notion de prŽcŽdence est gŽnŽrale et s’applique ˆ tout type d’opŽrations. En

pratique, les systmes ne considrent d'ordinaire que les opŽrations de lecture et

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

prŽcisŽment , l’une des sŽquences :

· Ti : lire(D) É Tj : Žcrire(D) ;

· Ti : Žcrire(D) É Tj : Žcrire(D) ;

· Ti : Žcrire(D) É Tj : lire(D) ;

implique que Ti prŽcde Tj.

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

reprŽsentŽe figure 26 n’est pas sŽrialisable puisque le graphe de prŽcŽdence possde un

circuit.

Figure 26 — Exemple de graphe de prŽcŽdence.

8.3Le verrouillage deux phases

Le verrouillage deux phases est une technique de prŽvention des conflits basŽe sur le

verrouillage des objets en lecture ou Žcriture avant d’effectuer une opŽration de

sŽlection ou mise ˆ jour. En thŽorie, une transaction ne peut rel‰cher de verrous avant

d’avoir obtenus tous les verrous qui lui sont nŽcessaires.

 Notion 26 : Verrouillage deux phases (Two Phase Locking)

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

d’exŽcution des points de verrouillage maximum Fi. En pratique, afin de garantir

l’isolation des mises ˆ jour, les verrous sont seulement rel‰cher en fin de transaction,

lors de la validation.

Figure 27 — Comportement des transactions deux phases.

Les verrous sont demandŽs au moyen de l’opŽration LOCK(O,M) et rel‰chŽs au moyen

de l’opŽration UNLOCK(O), O Žtant l’objet ˆ verrouiller/dŽverrouiller et M le mode de

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

circuits sont transformŽs en verrous mortels.

Figure 28 — CompatibilitŽ des opŽrations de lecture/Žcriture.

L’application du verrouillage dans un systme pose le problme du choix de l’unitŽ de

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,

les transactions accŽdant beaucoup de tuples pouvant verrouiller au niveau table ou

page, celles accŽdant ponctuellement quelques tuples ayant la capacitŽ de verrouiller au

niveau tuple. Le choix d’une unitŽ de verrouillage fine (par exemple le tuple) minimise

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

d’objets embo”tŽs et ˆ verrouiller ˆ partir de la racine dans un mode d’intention

jusqu’aux feuilles dŽsirŽes qui sont verrouillŽes en mode explicite. Par exemple, une

transaction dŽsirant verrouiller un tuple en mode Žcriture verrouillera la table en

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

tuple et la matrice de compatibilitŽ des lectures et Žcritures avec modes explicites et

intentions est reprŽsentŽe figure 29.

Figure 29 — Modes explicites et modes intentions.

8.4DegrŽ d'isolation en SQL2

Le verrouillage, tel que prŽsentŽ ci-dessus, est trs limitatif du point de vue des

exŽcutions simultanŽes possibles. Afin de proposer une approche plus permissive et de

laisser s’exŽcuter simultanŽment des transactions prŽsentant des dangers limitŽs de

corruption des donnŽes, le groupe de normalisation de SQL2 a dŽfini des degrŽs

d'isolation embo”tŽs, du moins contraignant au plus contraignant, ce dernier

correspondant au verrouillage deux phases. Le groupe distingue les verrous rel‰chŽs

aprs exŽcution de l’opŽration des verrous longs rel‰chŽs en fin de transaction. Le

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

verrous courts exclusifs lors des Žcritures.

· Le degrŽ 1 garantit la cohŽrence des mises ˆ jour ; il gŽnre la pose de verrous

longs exclusifs en Žcriture par le systme.

· Le degrŽ 2 assure la cohŽrence des lectures individuelles ; il ajoute la pose de

verrous courts partagŽs en lecture ˆ ceux du degrŽ 1.

· Le degrŽ 3 atteste de la reproductibilitŽ des lectures ; il complte avec la pose de

verrous longs partagŽs en lecture.

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.

8.5Problmes de contr™le du verrouillage en rŽparti

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

verrous. Autrement, qui verrouille ? On distingue le verrouillage centralisŽ o un site

unique est responsable des verrous au moins ˆ un instant donnŽ et le verrouillage

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

pas sans problme.

Figure 30 — Gestion dŽcentralisŽe des verrous.

Le problme essentiel est le risque de verrous mortels intersites.

 Notion 27 : Verrou mortel (Deadlock)

Situation dans laquelle un groupe de transactions est bloquŽ, chaque transaction du

groupe attendant qu’une autre transaction du groupe rel‰che un verrou pour
pouvoir continuer.

Une transaction Ti attend une transaction T j si Ti a demandŽ l’obtention d’un verrou sur

un objet verrouillŽ par T j en mode incompatible. Le verrou mortel correspond ˆ la

prŽsence d’un circuit dans le graphe d’attente. Un verrou mortel peut tre causŽ par des

transactions s’exŽcutant sur des sites diffŽrents (voir figure 31).

Figure 31 — Exemple de verrou mortel intersites.

8.6Les solutions au problme du verrou mortel

Deux classes de solutions sont possibles dans les SGBD rŽpartis afin de rŽsoudre le

problme du verrou mortel : la premire, appelŽ prŽvention, empche les situations de

verrous mortels de survenir ; la seconde, appelŽ dŽtection, est une solution curative qui

consiste ˆ supprimer les verrous mortels par reprise de transactions.

8.6.1PrŽvention du verrou mortel

La prŽvention consiste ˆ appliquer une stratŽgie de verrouillage garantissant que le

problme ne survient pas. Il existe classiquement deux approches, l’une basŽe sur

l’ordonnancement des ressources, l’autre sur celui des transactions. L’ordonnancement

des ressources (tables, pages, tuples) de sorte ˆ les allouer dans un ordre fixŽ aux

transactions est impraticable vu le grand nombre d’objets distribuŽs. L’ordonnancement

des transactions est possible ˆ partir d’une estampille.

 Notion 28 : Estampille de transaction (Transaction Timestamp)

NumŽro unique attribuŽ ˆ une transaction permettant de l’ordonner strictement

par rapport aux autres transactions.

En gŽnŽral, l’estampille attribuŽe ˆ une transaction est son horodate de lancement

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

diffrent alors par le numŽro de site en poids faibles.

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

l’algorithme est donnŽ figure 32.

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

blessŽe ne peut donc attendre.

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Ž

aux transactions les plus anciennes. L’algorithme WOUND-WAIT provoque en principe

moins de reprise de transactions et sera en gŽnŽral prŽfŽrŽ.

8.6.2DŽtection du verrou mortel

La prŽvention provoque en gŽnŽral trop de reprises de transactions, car les mŽthodes

dŽfont des transactions alors que les verrous mortels ne sont pas sžrs d’appara”tre. Au

contraire, la dŽtection laisse le problme se produire, dŽtecte les circuits d'attente et

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 ˆ

des instants diffŽrents.

Nous donnons figure 34 un algorithme de dŽtection par enqute : chaque gŽrant de

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

lorsqu’une transaction Ti a attendu depuis trop longtemps par appel de la procŽdure

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

alors annuler et reprendre une transaction de la liste.

// ProcŽdure de dŽtection par enqutes propagŽes sur le graphe

DŽtecter (Ti) { Enqute(Ti ¯) }
// Chaque LM fournit une procŽdure Enqute
// Enqute est exŽcutŽe par le site contr™lant T in

Enqute (Ti1.Ti2. ÉTin)

{ si Tin = Ti1 alors DŽtecter = Vrai
sinon
{ si Tin est attendue alors
{ Pour chaque Tij attendant Tin
Faire Enqute (Ti1.Ti2. ÉTin.Tij) ; }
sinon DŽtecter = Faux } ;
Figure 34 — DŽtection du verrou mortel par enqute.

8.7Ordonnancement par estampillage

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

sŽrialisabilitŽ des transactions.

Une mŽthode simple consiste ˆ conserver pour chaque objet accŽdŽ (tuple ou page),

l’estampille du dernier Žcrivain W et celle du plus jeune lecteur R. Le contr™leur de

concurrence vŽrifie alors :

1. que les accs en Žcriture s’effectuent dans l’ordre croissant des estampilles de

transactions par rapport aux opŽrations crŽant une prŽcŽdence, donc

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.

On aboutit donc ˆ un contr™le trs simple d’ordonnancement des accs conformŽment ˆ

l’ordre de lancement des transactions. En cas de dŽsordre, il suffit de reprendre la

transaction ayant crŽŽ le dŽsordre. Les contr™les nŽcessaires en lecture et Žcriture sont

rŽsumŽs figure 35.

// Contr™le d'ordonnancement des transactions

ƒcrire(Ti, O) {
// la transaction Ti demande l’Žcriture de l’objet O ;
si ts(Ti) < W(O) ou ts(T i) < R(O) alors abort(T i)
sinon exŽcuter_Žcrire(Ti,O) } ;

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.

L’algorithme d’ordonnancement par estampillage soulve plusieurs problmes. De fait, les

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

l’ordre de lancement des transactions. Ceci conduit en gŽnŽral a beaucoup trop de

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

dŽlivrer une ancienne version, plus exactement, la premire infŽrieure ˆ l’estampille du

lecteur. Ainsi, il n’y a plus de reprise lors des lectures. La mŽthode est cependant difficile

ˆ mettre en oeuvre et n’est pas aujourd’hui utilisŽe.

8.8Certification optimiste

La certification optimiste est une mŽthode de type curative, qui laisse les transactions

s’exŽcuter et effectue un contr™le garantissant la sŽrialisabilitŽ en fin de transactions.

Une transaction est divisŽe en trois phases : phase d’accs, phase de certification et phase

d’Žcriture. Pendant la phase d’accs, chaque contr™leur de concurrence garde les

rŽfŽrences des objets lus/Žcrits par la transaction. Pendant la phase de certification, le

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

et la transaction dŽfaite puis reprise. La phase d'Žcriture permet l’enregistrement des

mises ˆ jour dans la base pour les seules transactions certifiŽes.

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

transactions. L’avantage est la simplicitŽ du contr™leur de concurrence qui se rŽsume ˆ

mŽmoriser les objets accŽdŽs et ˆ un test simple d'intersection d'ensembles de

rŽfŽrences lors de la validation. L’inconvŽnient majeur est la tendance ˆ reprendre

beaucoup de transactions en cas de conflits frŽquents. La mŽthode optimiste est donc

seulement valable pour les cas o les conflits sont rares.

8.9Bilan sur la concurrence

Nous avons ci-dessus rŽsumŽ les techniques essentielles de contr™le de concurrence

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

transactions permettent de maximiser le partage des donnŽes en limitant le contr™le. La

granularitŽ variable du verrouillage amŽliore aussi les possibilitŽs d’accs concurrents. La

recherche sur ces sujets continue et des solutions applicables restent ˆ trouver pour les

transactions longues notamment.

V.9.RƑPLICATION DANS LES BD RƑPARTIES

Les techniques de rŽplication permettent la gestion de copies multiples pouvant diverger

— c’est-ˆ-dire prŽsenter des valeurs diffŽrentes — ˆ un instant donnŽ, mais convergeant

vers les mmes valeurs ˆ termes. Nous examinons ci-dessous les diffŽrentes formes de

rŽplication possibles et les techniques de gestion de la cohŽrence des copies associŽes.

9.1RŽplication : avantages et problmes

Pourquoi rŽpliquer ? Deux intŽrts majeurs se dŽgagent : amŽliorer les performances et

augmenter la disponibilitŽ des donnŽes. Gr‰ce ˆ la rŽplication, les lectures sont

exŽcutŽes sur le site disposant de la copie la plus proche du client, ce qui peut Žviter

des transferts inutiles, par exemple si le client dispose d’une copie. Aussi bien pour les

lectures que pour les Žcritures, la rŽplication permet d’Žviter le goulot d'Žtranglement

que constitue le serveur unique en partageant la charge.

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Ž augmente selon la formule :

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.

Si la rŽplication prŽsente de nombreux avantages, les problmes soulevŽs sont multiples.

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.

9.2Mise ˆ jour synchrone et asynchrone

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

s’avre souvent trop contraignant pour les applications.

Notion 29 : Mise ˆ jour synchrone (Synchronous update)

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

le systme se doit de garder une cohŽrence forte.

L’avantage essentiel de la mise ˆ jour synchrone est de garder toutes les donnŽes au

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

multiples, ce qui conduit beaucoup d’applications ˆ Žviter la gestion de copies

synchrones. Ce sont d’une part la nŽcessitŽ de gŽrer des transactions multisites

cožteuses en ressources, et d’autres parts la complexitŽ des algorithmes de gestion de

concurrence et de panne d’un site. C’est pour cela que l’on prŽfre souvent le mode de

mise ˆ jour asynchrone (encore appelŽ mise ˆ jour diffŽrŽe).

Notion 30 : Mise ˆ jour asynchrone (Asynchronous update)

Mode de distribution dans lequel certaines sous-opŽrations locales effectuŽes suite

ˆ une mise ˆ jour globale sont accomplies dans des transactions indŽpendantes, en
temps diffŽrŽ.

Le temps de mise ˆ jour des copies peut tre plus ou moins diffŽrŽ : les transactions de

report peuvent tre lancŽes 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

mises en cohŽrence seulement pŽriodiquement — on parle de cohŽrence l‰che — sont

nombreuses. Citons par exemple la modification des prix de catalogues de produits, la

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

qui limite les possibilitŽs de mise ˆ jour.

9.3Techniques de diffusion des mises ˆ jour

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

celles basŽes sur la diffusion du rŽsultat de l’opŽration. Diffuser le rŽsultat prŽsente

l’avantage de ne pas devoir rŽexŽcuter l’opŽration sur le site de la copie, mais

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,

notamment dans le cas d’opŽrations commutatives.

Comment diffuser les mises ˆ jour est un autre problme auquel les constructeurs de

SGBD rŽpartis doivent faire face. L’utilisation de dŽclencheurs du type WHEN

<OPŽRATION> ON <TABLE> THEN FORWARD <OPŽRATION> ON <COPIE> facilite

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

de fond ˆ un instant dŽterminŽ par l’administrateur. La file doit tre scrutŽe

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

avec mise ˆ niveau pŽriodique.

En rŽsumŽ, les techniques de diffusion des mises ˆ jour sont multiples. On peut

distinguer principalement le schŽma pousser (push) ˆ l’initiative du site mettant ˆ jour du

schŽma tirer (pull) ˆ l’initiative du site gŽrant la copie. Les avantages et inconvŽnients de

ces mŽthodes ne sont pas clairs ; plus d’expŽriences sont nŽcessaires.

9.4RŽplication asymŽtrique

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.

Notion 31 : RŽplication asymŽtrique (Asymetric replication)

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 ˆ

jour. Ce mode de rŽplication convient bien aux applications ˆ responsabilitŽ centralisŽe.

Il permet la distribution de l'information centralisŽe, par exemple la diffusion de

catalogues, de listes de prix, etc. AppliquŽ dans l’autre sens, ˆ partir de copies de

fragments horizontaux d’une table, il permet la consolidation d'informations

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

entrep™ts pour l’aide au dŽcisionnel et l’historisation.

A noter que le choix d’une technique asymŽtrique est orthogonal au choix d’un mode de

diffusion synchrone ou asynchrone des mises ˆ jour : on peut donc distinguer

l’asymŽtrique synchrone et l’asymŽtrique asynchrone. La premire technique est illustrŽe

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

lorsque le site primaire tombe en panne.

Figure 36 — Mises ˆ jour de copies asymŽtriques synchrones.

Figure 37 — Mises ˆ jour de copies asymŽtriques asynchrones.

Un problme de la gestion de copie asymŽtrique est donc la panne du site primaire. Dans

ce cas, il faut choisir un remplaant si l’on veut continuer les mises ˆ jour. Celui-ci peut tre

fixŽ par l’administrateur ou Žlu par un protocole spŽcifique de vote majoritaire. On

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

du traitement de la commande. Il devient nŽcessaire de gŽrer ˆ la fois les problmes de

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

techniques asymŽtriques mobiles peuvent donc se sophistiquer ˆ l’extrme et dŽboucher

sur des approches encore mal ma”trisŽes.

9.5RŽplication symŽtrique

A l’opposŽ de la rŽplication asymŽtrique, la rŽplication symŽtrique ne privilŽgie

aucune copie. Elle permet les mises ˆ jour simultanŽes de toutes les copies par des

transactions diffŽrentes.

Notion 32 : RŽplication symŽtrique (Symetric replication)

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

commandes ˆ de multiples sites, la gestion de clients mobiles, la gestion de comptes par

des agences multiples, la mise ˆ jour de documents stratŽgiques en groupe, etc.

Lˆ encore, il est possible de distinguer le symŽtrique synchrone du symŽtrique

asynchrone. La premire technique est illustrŽe figure 39 et la seconde figure 40. La

diffŽrence rŽside dans le passage des mises ˆ jour par une file persistante.

Figure 39 — Exemple de symŽtrique synchrone.

Figure 40 — Exemple de symŽtrique asynchrone.

9.6Convergence de copies symŽtriques

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

ordre, ce qui peut prŽsenter quelques difficultŽs facilement solubles.

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.

Figure 41 — Exemples de copies en cours de divergence.

Des techniques applicables dans le cas de mise ˆ jour synchrones dŽcoulent des

mŽcanismes de contr™le de concurrence ŽtudiŽs ci-dessus. Ce sont :

· La prŽvention des conflits par verrouillage des copies. Le mŽcanisme consiste ˆ

demander ˆ toute transaction mettant ˆ jour, d’obtenir un verrou en Žcriture sur

chacune des copies. Les risques de verrous mortels sont alors importants si
 plusieurs transactions mettent ˆ jour simultanŽment. Les verrous mortels

peuvent tre prŽvenus en ordonnant l’ordre de visite des sites.

· La dŽtection des conflits par ordonnancement des mises ˆ jour.

L’ordonnancement s’effectue par un mŽcanisme d’estampillage ou de

certification comme vu ci-dessus. Le systme doit alors utiliser des estampilles

synchronisŽes pour ne pas favoriser un site plut™t qu’un autre. Les risques de

reprises multiples de transactions sont importants.

Les deux mŽcanismes ci-dessus sont consommateurs en ressources et seulement

utilisables en synchrone.

En asynchrone, il est impossible de dŽfaire des transactions validŽes. Les approches

proposŽes se contentent alors de dŽtecter les conflits et de reporter ceux-ci vers

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

l’objet mis ˆ jour. La technique n’est pas diffŽrente de l’ordonnancement par

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

garantit en gŽnŽral la convergence.

Au-delˆ de la dŽtection des conflits, la convergence nŽcessite de rŽsoudre les conflits. Il

s’agit de rŽconcilier les copies qui ont divergŽ. La rŽconciliation peut tre purement

syntaxique, et ne pas prendre en compte la signification des donnŽes. Par exemple, la

procŽdure dŽclenchŽe en cas de conflit dŽtectŽ par estampillage pourra diffuser la

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

mises ˆ jour : il s’agit alors de mettre en oeuvre une procŽdure de rŽconciliation

sŽmantique. celle-ci peut consister ˆ ajouter les valeurs (par exemple, en cas de

mouvements simultanŽs sur un compte), ˆ multiplier les valeurs, ˆ choisir le maximum

(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

soin de l’utilisateur qui peut appliquer des procŽdures spŽcifiques.

9.7Problmes de fiabilitŽ et reprise

Afin d’amŽliorer la disponibilitŽ des donnŽes comme indiquŽ en objectifs, le systme

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

que plusieurs sites ou groupes de sites divergent aprs des pannes.

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

transaction lorsqu’une majoritŽ de site a rŽpondu positivement au prŽ-commettre, et

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

exŽcutŽ correctement les mises ˆ jour de cette transaction. La figure 42 illustre la

propagation de l’ŽlŽments commun entre deux majoritŽs.

Figure 42 — Propagation d’un ŽlŽment commun entre majoritŽs.

9.8Copies dŽrivŽes et clichŽs

Nous avons ŽtudiŽ ci-dessus les mŽcanismes essentiels permettant de gŽrer

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)

Copie de sous-ensembles intŽgrŽs de plusieurs tables ma”tres dŽfinie par une

question portant sur ces tables.

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

mises ˆ jour en restreignant les donnŽes copiŽes.

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

appliquant le diffŽrentiel de la vue correspondant ˆ la copie ˆ chaque mise ˆ jour. Au

contraire, les copies dŽrivŽes complexes sont difficiles ˆ mettre ˆ jour car il n’est en

gŽnŽral pas possible de procŽder par application du diffŽrentiel. On Žvitera donc ce

type de copie.

Un cas particulier important des copies dŽrivŽes est le clichŽ [Adiba81].

Notion 34 : ClichŽ (Snapshot)

Copie dŽrivŽe asynchrone, donc mise ˆ jour pŽriodiquement selon le choix de

l’administrateur.

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

clichŽ. Il existe deux variations : la version asymŽtrique correspond aux clichŽs

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Ž

est intŽressant mais difficile ˆ piloter dans un SGBD rŽparti.

V.10.OPTIMISATION DES REQUÆTES RƑPARTIES

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

prŽsentons enfin diffŽrents algorithmes plus ou moins sophistiquŽs.

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

optimal de la requte composŽ de sous requtes et de transferts.

Notion 35 : Plan d’exŽcution rŽparti (Distributed Execution Plan)

Arbre d’opŽrations dont certaines correspondent ˆ des opŽrations locales ˆ un site

et d’autres ˆ des transferts de donnŽes depuis un site vers un autre site.

Dans l’arbre, on peut en gŽnŽral isoler diffŽrents sous-arbres composŽs d’opŽrations

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

statiquement lors de la compilation de la requte, soit dynamiquement ˆ chaque

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.

Un des objectifs essentiels de l’optimiseur dans un contexte distribuŽ est de minimiser

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

pipeline peuvent tre mis en oeuvre.

10.2Fonction de cožt ˆ optimiser

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 :

Cožt Total = a x cožt(E/S) + b x cožt(CPU) + c x cožt(communication).

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.

10.3DŽcomposition et optimisation ŽlŽmentaire des requtes

De manire gŽnŽrale, comme dŽjˆ vu en centralisŽ, un optimiseur dŽcompose une requte

en une arborescence d'opŽrations de l'algbre relationnelle. Ces opŽrations sont

projection, restriction, jointure, union et diffŽrence. En pratique, elles doivent tre

enrichies par les tris, dŽdoublage et calculs d’agrŽgats.

La figure 43 donne un exemple de base et de requte. L’arbre rŽsultant d’une traduction

directe de cette requte en opŽrations algŽbriques est reprŽsentŽ figure 44.

Figure 43 — Exemple de requte sur la base rŽpartie dŽgustation.

Figure 44 — Arbre rŽsultant d’une traduction directe de la requte.

Une optimisation ŽlŽmentaire consiste ˆ appliquer la mŽthode de restructuration

algŽbrique. L'optimiseur descend alors les couples restriction - projection afin de

diminuer les tailles de donnŽes ˆ transfŽrer entre opŽrations. Ainsi, les opŽrations

rŽductrices en taille que sont restriction et projection se trouve au bas de l’arbre.

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

illustre l’arbre optimisŽ par cette heuristique simple.

Figure 45 — Arbre optimisŽ par restructuration algŽbrique.

10.4Localisation des donnŽes

Pour dŽterminer le ou les sites ˆ qui envoyer une opŽration, il faut prendre en compte les

rgles de localisation des donnŽes. Celles-ci permettent de localiser des fragments de

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 :

11CREATE FRAGMENT <NOM>

12ON <LISTE DE SITES>

13AS <QUESTION>
sera mise ˆ disposition de l’administrateur. Par exemple, pour la base dŽgustation, la

commande :

14CREATE FRAGMENT VINS@DIJON

15ON DIJON

16AS SELECT *

17FROM VINS V, PRODUCTEURS P, PRODUITS R

18WHERE NV = R.NV AND R.NP = P.NP

19AND P.REGION = "BOURGOGNE"

aura permis de localiser les Bourgogne ˆ Dijon.

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

prŽdicats de restriction, jointure et localisation, ceci afin de dŽterminer les

contradictions ou les inclusions.

Figure 46 — Fragments ˆ jointures vides.

Au-delˆ des rgles de localisation, une optimisation sŽmantique prenant en compte

certaines contraintes d’intŽgritŽ peut tre intŽressante. Par exemple, si l’on est capable de

dŽcouvrir ou gŽrer la contrainte CRU = "VOLNAY" implique P.REGION = "BOURGOGNE", il

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

Un algorithme ŽlŽmentaire peut tre ŽlaborŽ par dŽtachement des sŽlections

(projections et restrictions groupŽes) pendantes de l’arbre obtenu aprs restructuration

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

algorithme est simple ˆ mettre en oeuvre. Malheureusement, il ne minimise gure les

volumes de transferts puisque toutes les donnŽes — certes aprs sŽlection — sont

rapatriŽes sur le site initiateur de la requte.

10.6Optimisations possibles

Plusieurs types d’optimisation peuvent tre apportŽs ˆ l’algorithme ŽbauchŽ ci-dessus.

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.

Quoiqu’il en soit, la connaissance des tailles des relations intermŽdiaires ˆ transfŽrer

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

possibilitŽs de gains en utilisant les semi-jointures.

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

pour filtrer la relation R2 avant Žmission. Le gain de l’opŽration est la rŽduction

apportŽe ˆ R2 diminuŽe du transfert additionnel opŽrŽ, soit de la taille de la colonne

R2.Aj. La rŽduction apportŽe ˆ R2 est la taille de R2 diminuŽe de la taille de la semi-

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,

ce qui est trs intŽressant.

Figure 47 — Introduction de semi-jointures avant jointure.

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

restrictions et projections. Ensuite, le site de transfert optimal est dŽterminŽ par un

calcul de cožt pour chaque site. Le plan ainsi gŽnŽrŽ est progressivement amŽliorŽ par

introduction de mouvement intermŽdiaire et de jointures partielles.

L’optimisation par semi-jointures consiste ˆ sŽlectionner les semi-jointures de gains

positifs et ˆ ajouter successivement au plan de la semi-jointure la plus profitable. A

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

transferts, les semi-jointures inutiles concernant les relations localisŽes au site

d'assemblage sont ŽliminŽes. Cet algorithme trs intŽressant est dŽcrit en dŽtails dans

[Bernstein81].

10.8Algorithme de R*

Le systme R* [Williams82] dŽveloppŽ au centre de recherche d’IBM au dŽbut des

annŽes 80 faisait coopŽrer plusieurs systmes R interconnectŽs. L’optimiseur [Lohman85]

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

chaque relation. La programmation dynamique est utilisŽe pour choisir la meilleure

stratŽgie ˆ partir d’une fonction de cožt du type :

Fonction de cožt = Cožt Local + Cožt Communication.

Le cožt de chaque plan est ŽvaluŽ ˆ partir de statistiques sur les bases et d’un modle de

distribution uniforme, comme dans systme R [Selinger79].

Un effort d’optimisation des jointures multisites a ŽtŽ accompli. Plusieurs algorithmes

sont proposŽs et l’optimiseur choisit le moins cožteux. L’algorithme des boucles

imbriquŽes peut tre appliquŽ sur le rŽseau selon plusieurs variantes. L’une ou les deux

relations doivent tre envoyŽes au site de jointure. Lors de la rŽception de la relation

interne, le systme peut garder un maximum de donnŽes en mŽmoire, ce qui Žvite

ensuite des accs disques. On obtient ainsi trois algorithmes diffŽrents ˆ Žvaluer :

· envoi de la relation externe au site de l'interne sans mŽmorisation ;

· envoi de la relation interne au site de l'externe avec mŽmorisation de l’interne ;

· envoi des 2 relations ˆ un 3e site avec mŽmorisation de la relation interne.

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

colonne de jointure de la relation externe au site de la relation interne afin d’effectuer le

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.

En rŽsumŽ, l’algorithme de R* optimise les jointures distribuŽes par application de

diffŽrentes variantes de l’algorithme des boucles imbriquŽes sur le rŽseau. Il profite au

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

algorithme de programmation dynamique.

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

gestion de transactions rŽparties et montrŽ l’intŽrt des moniteurs transactionnels qui

permettent de mettre en Ïuvre des protocoles de validation en deux Žtapes dans des

contextes hŽtŽrognes. Le contr™le de concurrence reste un problme critique,

gŽnŽralement rŽsolu par un mŽcanisme de verrouillage. La rŽplication a beaucoup

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

d’tre remise ˆ niveau pŽriodiquement. L’optimisation de requtes restent un problme

critique qui limite souvent les possibilitŽs de requtes.

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

mŽdiateurs orientŽs objets des sources de donnŽes variŽes, fichiers, relationnelles,

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

Esprit IRO-DB [Gardarin94] vise ˆ dŽvelopper un exemple de systme de la gŽnŽration

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.

Cet article prŽsente un mŽcanisme de dŽfinition et de maintenance de vues concrtes et de

clichŽs dans le cadre d’un systme de bases de donnŽes rŽparties. Un prototype a ŽtŽ

implŽmentŽ dans le cadre du projet R* ˆ San-JosŽ.

[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

un des prŽcurseurs des modles de transactions imbriquŽs dŽveloppŽs par la suite.

[Bernstein81] Bernstein Ph., Goodman N., Wong E., Reeve C.L., Rothnie J.B., Ç Query

Processing in a System for Distributed Databases (SDD-1) È, ACM Transactions on

Database Systems, Vol 6, N¡4, DŽcembre 1981.

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

recherche du site de transfert optimal et l’introduction de semi-jointures bŽnŽfiques.

[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

d’attente persistantes reprenables aprs panne.

[BrŽant90] BrŽant C., Ç Sabrina-Star : A Cooperation System for Heterogeneous and

Pre-existing Databases È, 6e journŽes Bases de DonnŽes AvancŽes, INRIA Ed., Montpellier,

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

intŽgrŽs. Cet article en donne une description dŽtaillŽe.

[Burkhres94] O. Bukhres, A. Elmagarmid, Object Oriented Multibase Systems : A Solution

for Advanced Applications, Springer-Verlag Ed., 1995.

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

synthses sur la dŽfinition de schŽma intŽgrŽs orientŽs objets.

[Gardarin94] G. Gardarin, B. Finance, P. Fankhauser, W. Klas Ç IRO-DB : A Distributed

System Federating Object and Relational Databases È, in [Burkhres94] Chapitre 11.

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

l’ODMG et le langage d’interrogation OQL. Le systme est organisŽ en trois couches :

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

quelconque, intŽgrateur de bases interopŽrables offrant des outils de dŽfinition de vues

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

gestion de calendrier fut rŽalisŽe ˆ Xerox Research ˆ Palo-Alto en Californie.

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

Technical report, Palo Alto, Xerox Research Center, 1976.

Cet article de base prŽsente la premire implŽmentation du protocole de validation en deux

Žtapes. Lampson et Sturgis sont connus comme Žtant les inventeurs de ce fameux protocole.

[Landers82] Landers T., Rosenberg R., Ç An Overview of Multibase È, in Distributed

Data Bases, H-J. Schneider Ed., North-Holland, Amsterdam, 1982.

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.

Schneider Ed., North-Holland, Amsterdam, 1982.

Lancer en 1976 ˆ la suite de Cyclades (le premier projet de rŽseau d’ordinateurs franais), le projet

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.

Cet article donne une vue partielle des rŽsultats du projet.

[Litwin87] Litwin W., Abdellatif A., Ç An Overview of the Multidatabase Manipulation

Language MDL È, Proceedings of the IEEE, IEEE Ed., Mai 1987.

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

d’interrogation de bases multiples avec des facilitŽs de conversion intŽgrŽes.

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

Springer Verlag, 1985.

Cet article dŽcrit les algorithmes implŽmentŽs dans R*, le prototype de SGBD rŽparti d’IBM,

pour l’optimisation de requtes. DiffŽrentes mŽthodes de jointure distribuŽe sont en particulier

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

Hall, Englewood Cliffs, New Jersey, 562 p., 1991.

Cet ouvrage est le livre de rŽfŽrence en anglais sur les bases de donnŽes rŽparties. Il couvre en

particulier les aspects architecture, conception, contr™le sŽmantique, optimisation de requtes,

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

system for seamless integration of heterogeneous information sources È, IMS

International Conference, Vienna, Austria, 1991.

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

(SDD-1) È, ACM Transactions on Database Systems, Vol 5, N¡1, Mars 1980.

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

dans le cadre d’un rŽseau pouvant se partitionner.

[Rosenkrantz78] Rosenkrantz D., Stearns R., Lewis P., Ç System Level Concurrency

Control for Distributed Database Systems È, ACM Transactions on Database Systems, Vol.

3, N¡ 2, pp. 178-198, Juin 1978.

Cet article prŽsente les techniques de contr™le de concurrence WAIT-DIE et WOUND-WAIT

dŽcrites ci-dessus.

[Selinger79] Selinger P., Astrahan M., Chamberlin D., Lorie R., Price T., Ç Access Path

Selection in a Relational Database Management System È, ACM SIGMOD Int. Conf.,

Boston, Mai 1979.

Cet article dŽcrit le mŽcanisme de gŽnŽration de plans d’exŽcution optimisŽs dans le fameux

systme R d’IBM. Il prŽsente un modle de cožt basŽ sur des hypothses d’uniformitŽ et une

stratŽgie de recherche de type programmation dynamique pour retrouver le meilleur plan.

[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

Distributed, Heterogeneous, and Autonomous Databases È, ACM Computing Surveys,

22(3) :183--236, September 1990.

Cet article du numŽro spŽcial de Computer Surveys sur les BD fŽdŽrŽes prŽsente une vue

d’ensemble des architectures de systmes de gestion de bases de donnŽes fŽdŽrŽes. Il discute en

particulier les diffŽrents niveaux de schŽmas et de langages possibles.

[Shipman81] D. Shipman, Ç The Functional Data Model and the Data Language

DAPLEX È, IEEE Transactions on Database Systems, 6(1) :140--173, March 1981.

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

Arbor, pp. 133-142, ACM Ed., Mai 1981.

Des protocoles non bloquants, en particulier le protocole en trois Žtapes dŽcrit ci-dessus, sont

introduits dans cet article.

[Stonebraker77] Stonebraker M., Neuhold E., Ç A Distributed Database Version of

Ingres È, Proc. 2nd Berkeley Workshop on Distributed Data Management and Computer

Networks, Berkeley, Calif., Mai 1977.

Ingres/Star fut la premire version rŽpartie du systme Ingres, rŽalisŽe ˆ Berkeley. Cet article en

donne une premire spŽcification.

[Templeton87] M. Templeton et. al., Ç Mermaid : A Front-End to Distributed

Heterogeneous Databases È, in Proceedings of the IEEE, 75(5), p. 695--708, May 1987.

Cet article prŽsente le systme Mermaid, systme permettant de fŽdŽrer des bases de donnŽes

hŽtŽrognes autour du modle relationnel.

[Thomas90] G. Thomas, Ç Heterogeneous Distributed Database Systems for

Production Use È, ACM Computing Surveys, 22(3), p. 237--266, September 1990.

Cet autre article du numŽro spŽcial de Computer Surveys sur les BD fŽdŽrŽes prŽsente une

autre classification des architectures des principaux systmes connus.

[Williams82] Williams R. et. al., Ç R* : An Overview of the Architecture È, in Improving

Database Usability and Responsiveness, Academic Press Ed., New-York, 1982.

Une synthse du projet R*, la version distribuŽe de systme R, est dŽcrite dans cet article. R*

apporte l’indŽpendance ˆ la localisation, l’optimisation de requtes distribuŽes et les transactions

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.

[Weikum91] G. Weikum, Ç Principles and Realization Strategies of Multi-Level

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

validation ou d’annulation de la transaction ma”tre.