Vous êtes sur la page 1sur 23

Chapitre 15

BASES DE DONNEES REPARTIES



1. Introduction a 1a repartition

2 Principes d'une Base de donnees rep artie 2.1 Utilisation d'une BD rep artie

2.2 Niveau de repartition

3 Conception de BD Reparties 3.1 Methode de conception

3.2 Techniques de fragmentation

3.2.1 Repartition des classes d'objet 3.2.2 Repartition des occurrences 3.2.3 Repartition des attributs

3.2.4 Repartition des valeurs

3.2.5 Repartition des Reseaux connexes d'occurrences 3.3 Schema de fragmentation

3.3.1 Definition des fragments horizontaux d'une classe 3.3.2 Definition des fragments verticaux d'une classe 3.4 Schema d'allocation

3.5 Techniques de repartition avancees 3.5.1 Allocation avec duplication 3.5.2 Allocation dynamique

3.5.3 Fragmentation dynamique 3.5.4 Cliches

4 Gestion des donnees reparties 4.1 Mise a jour de BD reparties

4.2 Execution de requetes sur BD reparties 4.2.1 Transferts de donnees

4.2.2 Traitement de requetes reparties

4.2.3 Optimisation dynamique des requetes 4.2.4 Semi-jointure

73

Chapitre 15

BASES DE DONNEES REPARTIES

1. Introduction a la repartition

Une base de donnees centralisee est geree par un seul SGBD, est stockee dans sa totalite a un emplacement physique unique et ses divers traitements sont confies a une seule et meme unite de traitement. Par opposition, une base de donnees distribuee! est geree par plusieurs processeurs, sites ou SGBD.

Les bases de donnees reparties, federees et paralleles sont trois domaines dis tincts mais qui ont une problematique commune, la distribution des donnees ou des traitements sur plusieurs unites qui cooperent pour gerer les informations.

Les objectifs de la distribution de donnees sont multiples:

- LimIter Ie transfert d'mformatIOn (en nombre et en volume) en repartlssant les donnees la ou elles sont Ie plus utlhsees. Ceci est partlcuherement Important pour une base de donnees dont les dIfferents utlhsateurs sont geOgraphlqUement dISperSes comme dans rexemple des agences d'une banque natIOnale, ou encore des gUlchets de reServatIOn d'une compagme aenenne ou ferrovlalfe.

- Accroitre les performances par la repartition de la charge de travail sur plusieurs unites de traitement operant en parallele.

- Augmenter la fIablhte en faIsant effectuer Ie meme traItement par plusleurs ordmateurs et en duphquant les donnees sur dIfferents sItes, lorsque la BD concerne un domame sensIble ou la momdre erreur peut aVOlf des consequences catastrophlques ( comptes bancalfes, centrales nUclealreS, lancement de fusees spatlales).

- Etendre la disponibilite des informations, en les dupliquant sur plusieurs sites. L'exemple type est l'annuaire telephonique national dont chaque ville importante possederait un exemplaire.

- Falfe croitre en souplesse une BD ou meme tout Ie systeme de base de donnees. Le but est ICI de ne pas modIfIer rexlstant lorsque ron deSIre transformer la structure des mformatIOns (evolutIOn du schema conceptuel), utlhser un nouveau support ou une nouvelle technologle pour Ie stockage en memOlre secondalfe, ou plus radlcalement utlhser un nouveau SGBD. L'evolutIOn progressive est

1 Ce terme generique englobe les BD reparties, les BD federees et les BD paralleles

75

alors assuree en faisant cooperer l'existant avec Ie "nouveau" au sein d'une BD repartie.

- FUSIOnner en douceur deux systemes d'mformatIOn en falsant cooperer leurs bases de donnees. Le pnnclpe est ICI de mamtemr les applIcatIOns existantes tout en permettant I'mteroperabilIte des deux systemes d'mformatIOn.

2 Principes d 'une Base de donnees rep artie

Definition: Une base de donnees repartie (BDR) est une base de donnees dont differentes parties sont stockees sur des sites, generalernent geographiquement distants, relies par un reseau. La reunion de ces parties forme la base de donnees repartie.

Un systeme de bases de donnees reparties ne doit done en aucun cas etre confondue avec un systeme dans lequel les bases de donnees sont accessibles a distance (selon Ie principe client serveur). II ne doit non plus etre confondu avec un systeme multibase. Dans ce dernier cas, chaque utilisateur accede a differentes bases de donnees en specifiant leur nom et adresse, et Ie systeme se comporte alors simplement comme un serveur de BD et n'apporte aucune fonctionnalite particuliere a la repartition.

Au contraire, un systeme de bases de donnees reparties est suffisamment complet pour decharger les utilisateurs de tous les problemes de concurrence, fiabilite, optimisation de requetes ou transaction sur des donnees gerees par differents SGBD sur plusieurs sites.

Par exemple, une banque peut posseder des agences a Geneve et a Lausanne. Dans une BD centralisee, Ie siege social de la banque gererait tous les comptes des clients et les agences devraient communiquer avec Ie siege social pour avoir acces aux donnees. Dans une BD repartie, les informations sur les comptes sont distribuees dans les agences et celles-ci sont interconnectees (entierement ou partiellement) afin qu'elles puissent avoir acces aux donnees externes (Figure 1). Cependant, la repartition de la base de donnees bancaire est invisible aux agences en tant qu'utilisateurs, et la seule consequence directe pour elles est que l'acces a certaines donnees est beaucoup plus rapide.

Geneve

Lausanne

FIgure I : Exemple de BD repartle

2.1 Utilisation d'une BD rep artie

Le principe fondamental des BDR est la transparence pour Tutilisateur. Cette transparence s'exprime so us trois formes:

Les utilisateurs accedent a la BD soit directement par Ie schema conceptuel soit indirectement au

travers de vues externes (Figure 2). Mais en aucun cas ils n'ont les moyens d'acceder aux schemas Iocaux m de preciser Ie site. C'est Ie pnncipe de transparence de localisation. Dans I'exempIe precedent, un client peut ouvrir un compte a Geneve et effectuer regulierement des operations a Lausanne. C'est Ie systeme qui recherche Ie site ou sont memorisees ses informations et non l'utilisateur qui doit l'indiquer.

De meme, les utilisateurs n'ont pas a connaHre les partitionnements de la base de donnees. C'est Ie pnncipe de transparence de partitionnement. Les utthsateurs ne dOl vent pas savoir SI tene information est fractionnee, et ne doivent done pas se preoccuper de la reunifier. C'est Ie systeme qui gere les partitionnements et les modi fie en fonction de ses besoins, et c'est done lui qui doit rechercher toutes les partitions et les integrer en une seule information logique presentee a l'utilisateur.

Utilisateurs

FIgure 2: ArchItecture de schemas d'une BDR

Enfm, Ies utlhsateurs n'ont pas a savoir SI pIusieurs copies d'une meme mformatIOn sont

77

dispombies. C'est Ie pnncipe de transparence de duplication. La consequence dlrecte est que Iors de la modification d'une information, c'est Ie systeme qui doit se preoccuper de mettre a jour toutes les copies.

Dans l'exemple precedent, il est fort possible que lorsqu'un client possede des comptes (courant, epargne logement, ... ) a Geneve mais effectue regulierement des retraits d'argent a Lausanne, les informations Ie concernant soient reparties entre Geneve a Lausanne: l'historique des operations du compte courant est conserve a Lausanne, la gestion de ses autres comptes est assuree a Geneve , et Ie solde du compte courant est duplique a Geneve et Lausanne.

Dans une BDR, les sites ne sont done pas autonomes, bien que chaque site possede une machine avec un SGBD et une partie de la base de donnees, et pourraient effectuer certains traitements localement. En effet, les utilisateurs accedent aux donnees par l'intermediaire du schema conceptuel global et non par l'intermediaire du schema d'un site, et c'est uniquement Ie systeme qui designe Ie ou les sites qui sont concernes par la demande de l'utilisateur. L'independance physique, assuree dans les bases de donnees traditionnelles, est done conservee dans les BD reparties.

2.2 Niveau de repartition

La repartItIOn d'une base de donnee mtervlent dans Ies trois mveaux de son archItecture (vOIr Ie chapltre 1) en plus de Ia repartItIOn physIque des donnees :

- Niveau externe : les vues (schemas externes) sont distribuees aux utilisateurs sur leurs sites, les sites utilisateurs.

- Nlveau conceptuel : Ie schema conceptuel des donnees (schema Ioglque) est aSSOCle, par l'mtermectlalfe du schema de repartItIOn (1m meme decompose en un schema de fragmentatIOn et un schema d'allocation), aux schemas locaux qui sont reparties sur plusieurs sites, les sites physiques.

- niveau interne: Ie schema interne global n'a pas d'existence reelle mais fait place a des schemas internes locaux repartis sur differents sites (en principe les sites d'accueil des schemas logiques repartis),

Tous les niveaux doivent etre concernes par la repartition pour que l'on puisse parler d'une vrai BD repartie, Sinon on n'a affaire qu'a des clients eloignes (repartition externe) ou a un stockage physique multi machines (repartition interne). On doit aussi remarquer que la distribution de la base de donnee se fait plus ou moins conformement a la repartition logique des utilisateurs dans l'entreprise (en divisions, services, instituts, ... ) et a la repartition physique des moyens informatiques dans l'entreprise (en centres de calculs, salles des machines, ordinateurs).

3 Conception de BD Reparties

Une BDR reprend Ies memes pnnClpes generaux que ceux d'une BD centrahsee mats en etendant Ies techmques existantes ou en proposant certams concepts nouveaux qui sont partIcuhers a Ia repartItIOn des donnees.

3.1 Methode de conception

L'approche descendante pour la conception de base de donnee est conservee mais Iegerernent modifiee. Le but de la conception de la BD par l'administrateur est de placer physiquement les donnees la ou elles sont utilisees, II doit done associer les vues et les schemas locaux.

Le problerne principal est qu'il n'y a pas necessairement de bijection entre les groupes d'utilisateurs

78

(qui ont chacun leur vue) et les sites physiques (qui possedent chacun leur schema local) : plusieurs groupes peuvent utiliser Ie meme ordinateur, et un groupe peut avoir acces a differents ordinateurs.

1- Les (groupes d') utilisateurs expriment leurs besoins qui sont integres pour creer un schema conceptuel unique.

2- Des vues externes sont ensmte dehmes a partIr de ce schema conceptuel (FIgure 2). Ces vues correspondent a la repartItIOn logIque des utIlIsateurs.

3- Parallelement, l'administrateur de la base de donnee cree Ie schema de repartition. II definit les fragments et leur correspondance avec Ie schema conceptuel global (ce qui forme Ie schema de fragmentation), et il associe a chaque fragment un ou plusieurs sites d'accueil (ce qui forme Ie schema d'allocation).

4- Dans chacun des sItes est cree (automatlquement) Ie schema logIque local qm regroupe tous les fragments alloues sur ce sIte. L'admmlstrateur dehmt ensuite les schemas mternes (qm decnvent les hchlers, mdexes, cles d'acces, structures de stockage, ... ).

La dehmtIOn du schema de repartItIOn est la partIe la plus delIcate et la plus mteressante de la phase de conceptIOn d'une BDR car 11 n'exlste pas de methode mIracle pour trouver la solutIOn optImale. L'admmlstrateur dOlt donc prendre des deCISIOnS en fonctIOn de cnteres techmques et orgamsatIOnnels avec pour obJectif de mlmmlser Ie nombre de transferts entre SItes, les temps de transfert, Ie volume de donnees transferees, les temps moyens de traitement des requetes, Ie nombre de copies de fragments, etc ...

3.2 Techniques de fragmentation

La fragmentation est Ie processus de decomposition d'une base de donnee logique (telle que la voient les utilisateurs) en un ensemble de "sous" bases de donnees. Cette decomposition doit evidernent etre sans perte d'information pour etre acceptable.

Definition: Une fragmentation est sans perte d'information si la base de donnee logique peut etre entIerement recomposee a partIr de ses fragments. Cette recompositIOn est expnmee en utilIsant les mstructIOns du lang age de mampulatIOn de donnees aSSOCIe au modele de donnees utIlIse (par exemple l'algebre ou SQL pour une BD relatIOnnelle).·

De plus, les dltferents fragments dOlvent de preference etre excluslfs (leur mtersectIOn est vIde) pmsqu'une fragmentatIOn non exclUSIve ImplIque une duplIcatIOn. Dans ce cas II faut atfmer la fragmentatIOn en prodmsant des fragments plus petits.

Le schema de fragmentatIOn contient les fragments plus les correspondances bldirectIOnnelles avec Ie schema global. Celles ci sont, d'une part, la definition formelle des fragments, Ie partitionnement, expnmee en terme d'operateurs du LMD applIques sur Ie schema global; et d'autre part la dehmtIOn formelle de la recomposition du schema global, qui est aussi exprimee a l'aide du meme ensemble d'operateurs.

La base de donnee peut etre fragmentee de dltferentes fa~ons, tant au mveau du schema qu'au mveau des donnees. L'umte de fragmentatIOn determme Ie type d'element Ie plus grand dont les composants ne peuvent etre fragmentes.

Une granulante fme donne de grandes possibilItes pour la fragmentatIOn et autonse une repartItIOn flexIble et efhcace de la base de donnees, mats a l'mconvement de provoquer une certame lourdeur pour la recompositIOn des mformatIOns. A l'oppose, une granulante elevee permet une gestIOn sImple de la fragmentatIOn, mais fourmt des possibilItes tres restremtes pour la fragmentatIOn.

79

L'unite de fragmentation est generalement laissee au libre choix de l'administrateur, du moins dans les limites des possibilites du modele de donnees utilise.

II existe quatre unites de fragmentation de base, a partir desquelles il est possible de definir d'autres unites mieux adaptees pour certains types de modeles,

3.2.1 Repartition des classes d'objet

Ce sont les classes (relatIOn en relatIOnnel, type d'entlte et type d'associatIOn en Entlte-AssociatIOn, type d'artlcle en CODASYL, classe en Onente-obJet) qUI peuvent etre repartles dans des fragments differents. Toutes les occurrences d'une meme classe appartiennent au meme fragment.

• L'operatIOn de partltIOnnement est la defimtIOn de sous scliemas.

• L'operatIOn de recomposinon est la reumon de sous scliemas.

Dans I'exemple sUIvant (FIgures 3 a 5) la base de donnees relatIOnneIIe peut etre fragmentee en {Compte, ClIent} et {Agence}

NoClient Agence TypeCompte Somme
174723 Lausanne courant 123345.89
177498 Geneve courant 34564.00
201 639 Lausanne courant 45 102.50
201 639 Lausanne depot 325 100.00
203 446 Geneve courant 274882.95 FIgure 3 : RelatIOn Compte

NoClient NomClient Pre nom Age
174723 Villard Jean 29
177498 Cattell Blaise 38
201 639 Tsellis Alan 51
203 446 Kowalsky Vladimir 36 Figure 4 : Relation Client

Agence Adresse
Lausanne Rue du Lac, 3,1002 Lausanne
Geneve Avenue du Mont Blanc, 21,1200 Geneve Figure 5 : Relation Agence

3.2.2 Repartition des occurrences

Les occurrences d'une meme classe peuvent etre reparties dans des fragments differents (avec leur valeur complete). C'est la fragmentation horizontale.

• L'operateur de partitionnement est la selection

• L'operateur de recomposition est l'union

Dans l'exemple precedent, la relation Compte peut etre fractionnee en Compt l et Compt2 avec la fragmentation suivante

Compt l = O'[TypeCompte = 'courant']Compte

et Compt2 = O'[TypeCompte = 'depot'[Compte

et la recomposition suivante Compte = Compt l u Compt2

8D

3.2.3 Repartition des attributs

Ce sont les attributs d'une meme classe qui peuvent etre repartis dans des fragments differents. Toutes les valeurs des occurrences pour un meme attribut se trouvent dans Ie meme fragment. C'est la fragmentation vertic ale. La repartition des attributs dans differents fragments ne peut etre correcte que si l'identifiant (ou identite d'objet) est duplique dans chaque fragment. C'est la condition necessaire pour que les occurrences puis sent etre reconstruites (decomposition sans perte d'informations) .

Une fragmentation vertic ale est utile pour distribuer les parties des donnees sur Ie site ou chacune de ces parties est utilisee. (Les guichets des banques n'ont besoin de connaitre que les soldes des comptes, tandis que les services de contentieux ont besoin de connaitre les informations completes sur chaque client)

• L'operateur de partitionnement est la projection

• L'operateur de recomposition est la jointure

Soit Ie partitionnement de la relation precedente Client en deux relations :

Clil = n[NoClient, NomClient]Client

et Cli2 = n[Noclient, Prenom, Age]Client

NoClient NomClient NoClient Pre nom Age
174723 Villard 174723 Jean 29
177498 Cattell 177498 Blaise 38
201 639 Tsellis 201 639 Alan 51
203446 Kowalsky 203446 Vladimir 36 Figure 6 : Relation Cli 1

Figure 7 : Relation Cli2

La relation d'origine est obtenue avec la recomposition suivante : Client = Cli1 * Cli2 3.2.4 Repartition des valeurs

C'est la combinaison des deux fragmentations precedentes, horizontale et verticale. Les occurrences et les attributs peuvent done etre repartis dans des partitions differentes.

• L'operation de partitionnement est une combinaison de projections et de selections.

• L'operation de recomposition est une combinaison de jointures et d'unions. La relation Client est obtenue avec: (Cli3 u Cli5) * Cli4 * Cli6

NoClient NomClient NoClient NomClient
174723 Villard 177498 Cattell
203446 Kowalsky 201 639 Tsellis FIgure 8 : RelatIOn Cll3

FIgure 9 : RelatIOn CllS

NoClient Prenom
174723 Jean
177498 Blaise
201 639 Alan
203 446 Vladimir NoClient Age
174723 29
177498 38
201 639 51
203 446 36 81

Figure 10 : Relation Cli4

Figure 11 : Relation Cli6

Ce sont les quatre unites de fragmentation de base. Mais d'autres unites de fragmentation interessantes sont a envisager, notamment Ie partitionnement selon les donnees connexes d'un so us schema (ensemble d'occurrences Iiees entre elles).

3.2.5 Repartition des Reseaux connexes d'occurrences

Dans Ie cas OU les occurrences forment plusieurs groupes de donnees independants, il serait possible de creer plusieurs bases de donnees. Comme c'est une condition tres restrictive et pas tres frequente dans Ie monde reel, on peut la restreindre a un sous schema. Dans ce cas, ce sont les groupes independants d'occurrences connexes relativement au sous schema qui sont les unites de repartitions. Ceci s'applique notamment tres bien pour tous les liens de type "One-Many", c'est a dire lorsque plusieurs occurrences d'un type ne sont Iiees qu'a une seule et meme occurrence d'un second type. Ces liens sont par exemple les identifiants externes en relationnel, les T A binaires avec un role monovalue, les types de set en CODASYL.

Dans l'exemple bancaire precedent, on peut fragmenter les agences avec leurs clients avec leurs

comptes.O bti 1 d 'd' lie (F 12 13)

no tient a ors eux reseaux occurrences lees rgures et
Agence Adresse
Lausanne Rue du Lac, 3,1002 Lausanne NoClient Agence TypeCompte Somme
174723 Lausanne courant 123345.89
201 639 Lausanne courant 45 102.50
201 639 Lausanne depot 325 100.00 NoClient NomClient Prenom Age
174723 Villard Jean 29
201 639 Tsellis Alan 51 FIgure 12 : Reseau d'occurrences hees a I'agence de Lausanne

Agence Adresse

Geneve Avenue du Mont Blanc, 21, 1200 Geneve

NoClient Agence TypeCompte Somme
177498 Geneve courant 34564.00
203446 Geneve courant 274882.95 NoClient NomClient Pre nom Age
177498 Cattell Blaise 38
203 446 Kowalsky Vladimir 36 FIgure 13 : Reseau d'occurrences hees a I'agence de Geneve

On pourralt tout aUSSI bIen tragmenter les chents avec leurs comptes. On obtlendraIt dans ce cas quatre reseaux connexes d'occurrences hees.

3.3 Schema de fragmentation

Le schema conceptuel doit etre decompose en un ensemble de fragments, qui constituent Ie schema de partitionnement. Le principe est de baser la fragmentation sur l'ensemble des requetes d'interrogation ou de mise a jour predefinies (celles que l'on prevoit deja lors de la definition de la base de donnees). II faut extraire de ces requetes toutes les conditions de selections, les attributs projetes et les jointures (naturelles ou non). Les operations de selection sont a la base des fragmentations horizontales, les operations de projection sont a la base des fragmentations verticales, et les operations de jointure avec des correspondances one-one ou one-many sont a l'origine des fragmentations sur reseaux d'occurrences Iiees. Chaque fragment final peut etre concerne par aucune, une seule ou plusieurs de ces requetes predefinies.

Pour eviter Ie risque d'emietter la base de donnees, on peut restreindre Ie nombre de requetes prises en consideration. On ne s'interesse alors qu'aux requetes les plus importantes, c'est a dire les plus courantes (regulierement appelees) ou les plus sensibles (celles pour lesquelles Ie temps de reponse maximum est borne).

3.3.1 Delinition des fragments horizontaux d'une classe

Soient ct, C2, ... , Cn les conditions de selection qui ont ete extraites des requetes. Comme les fragments horizontaux doivent etre exclusifs, on produit l'ensemble des 2n conjonctions de condition ou chaque condition elementaire est prise dans sa forme positive ou dans sa forme negative:

CC = { (\ Ci * ou Ci* est soit ci soit -,ci}. i=Ln

On ote de cet ensemble les conjonctions de condition qui sont toujours fausses, et on simplifie les autres.

On definit enfin la correspondance entre les conditions initiales et les conjonctions de condition produites. Une absence de condition de selection (equivalent a une condition toujours vraie) se traduit par la somme (v) de toutes les conjonctions.

Exemple: Sur la relation Compte (Figure 3) il est prevu d'appliquer les requetes suivantes :

RI = n[NoClient, Agence] a[TypeCompte = 'courant' /\ Somme > 100 000] Compte R2 = o[Agence = 'Lausanne'] Compte

R3 = n[NoClient, Somme] o[Agence = 'Geneve' /\ TypeCompte = 'courant'] Compte

On extrait done les conditions suivantes :

ct = TypeCompte = 'courant' /\ Somme > 100 000 cz = Agence = 'Lausanne'

c3 = Agence = 'Geneve' /\ TypeCompte = 'courant'

Sur Ies 8 conjOnctIOns de condItIon que I'on cree, certames sont fausses pUlsque Ies condItIOns ne sont pas orthogonales. AmsI, Ies conjonctions comportant c2 /\ c3 sont a oter, tandis que Ies conjonctions comportant -,c2 /\ c3 se simplifient.

L'ensemble des conjonctions de condItIon que I'on obtIent en utIhsant Ies regles de Ia IogIque du prermer ordre est donc :

CC = HTypeCompte = 'courant' /\ Somme > 100 000 /\ Agence = 'Lausanne'), ((TypeCompte· 'courant' v Somme· 100 000) /\ Agence = 'Lausanne'),

(TypeCompte = 'courant' /\ Somme > 100000/\ Agence = 'Geneve'), (Somme> 100000/\ Agence = 'Geneve' /\ TypeCompte = 'courant'),

(TypeCompte = 'courant' /\ Somme > 100000/\ Agence· 'Lausanne' /\ Agence> 'Geneve'), ((TypeCompte· 'courant' v Somme· 100000) /\ Agence· 'Lausanne'

/\ (Agence > 'Geneve' v TypeCompte· 'courant')) }

En utilisant la connaissance semantique des donnees ("on ne possede que deux agences, l'une a Lausanne et l'autre a Geneve") on optimise Ie decoupage horizontal en definissant cinq conjonctions de condItIOn ( cci) et donc cmq fragments (Fi) :

CC = {(TypeCompte = 'courant' /\ Somme > 100 000 /\ Agence = 'Lausanne'), ((TypeCompte· 'courant' v Somme > 100000) /\ Agence = 'Lausanne'), (TypeCompte = 'courant' /\ Somme > 100 000 /\ Agence = 'Geneve'), (Somme· 100 000 /\ Agence = 'Geneve' /\ TypeCompte = 'courant'), (Agence = 'Geneve' /\ TypeCompte· 'courant') }

(cc1) (cc2) (cc3) (cc4) (cc5)

NoClient Agence TypeCompte Somme
174723 Lausanne courant 123345.89 NoClient Agence TypeCompte Somme
201 639 Lausanne courant 45 102.50
201 639 Lausanne depot 325 100.00 NoClient Agence TypeCompte Somme
203446 Geneve courant 274882.95 NoClient Agence TypeCompte Somme
177498 Geneve courant 34564.00 NoClient

Agence

I TypeCompte

Somme

F5

FIgure 14 : RelatIOn Compte fragmentee honzontalement

Les correspondances entre les condItions ImtIales et les conjonctions de condItion sont : cl - ccj v cC3

c2 = cq v cC2

c3 = cC3 v cC4

Les correspondances entre les conjonctions de condition et les conditions initiales qu'elles concernentsont:

cq : c1, c2

ccz : c2

ccj : c1, c3

cca : c3 ccs : 7

La correspondance entre la relation initiale et ses fragments est:

Compte=FI u F2U F3U F4U FS

3.3.2 Definition des fragments verticaux d'une classe

Le pnncipe est, la encore, de baser la fragmentatIOn vertIcale sur l'ensemble des requetes d'mterrogatIOn ou de mIse a JOur prectehmes. MaiS la pnncipale dIfference est que l'on ne va affecter la fragmentatIOn vertIcale mdUIte par chaque requete qu'aux seuls fragments honzontaux concernes par cette requete, et non pas a toute la relatIOn.

Les fragments vertIcaux sont exclusIfs, sauf en ce qUI concerne Ie (ou les) attnbut(s) de Jomture (cle, Identihant, Old) qUI sont communs a tous les fragments pour que la decomposItIOn sort sans perte d'mformatIOn.

II faut prealablement extraue toutes les expreSSIOns de projectIOn concernees par les requetes. II faut aJouter a chacune d'elles le(s) attnbut(s) de Jomture SI elle ne les possecte pas. II faut aUSSI generer Ie complement de chaque expression (c'est a due les autres attnbuts) en ajoutant Ie (ou les) attnbut(s) de jointure.

L'etape suivante consiste, pour chaque fragment Fi produit par la fragmentation horizontale, a rechercher toutes les requetes qUI concernent ce fragment (l'mformatIOn est stockee par l'mtermediaue des correspondances entre les conjonctions de condItIOn et les condItIOns ImtIales) et a prendre les expressions de projection de ces requetes.

A partir des n expressions de projection qui concernent Fi, il faut produire l'ensemble2 des 2n mtersectIOns des expressions de projection ou chacune est sort l'expressIOn ImtIale sort son complement:

IPi = {I I ou p/ est soit Pj soit prJ·

Chaque Ipi,j de IPi correspond ala dehmtIOn d'un fragment vertIcal du fragment honzontal Fi.

Pour definir formellement ces fragments, on utilise la correspondance entre les expressions de projection initiales et les intersections des expressions de projection produites, en remarquant que l'union d'attributs se traduit par la jointure algebrique, Une absence de projection dans une requete equivaut a l'union de toutes les intersections de projections, ce qui se traduit par la jointure algebrique de tous les fragments.

Enfin, on definit la correspondance entre la relation initiale et ses differents fragments.

Exemple : En reprenant Ie cas precedent, on extrait des trois requetes les expressions de projection suivantes:

PI: N oClient, Agence P3 : NoChent, Somme

Comme ces expressions possedent deja un attribut de jointure, on passe a la phase suivante dans laquelle on genere les complements de ces expressions:

2 IFi est un ensemble, ce qui signifie que I'on ne conserve pas les doubles. Cette remarque conceme Ie (Ies) attributes) de jomture,

pr : NoClIent, TypeCompte, Somme P3 - : N oClIent, Agence, TypeCompte

F5 n'est concernee par aucune requete predehme et F2 est concernee par une requete sans projectIOn. Pour F4, qm est concernee par une requete avec projectIOn, on utIlIse P3 et P3-, tandis que pour F 1, ImplIquee dans deux requetes dont une seule avec projectIOn, on utIlIse PI et P 1-. Entm, pour F3, qm est utilIsees dans deux requetes avec projectIOn, on calcule les intersections des

expressions de projection, soient PI n P3, PI n P3-, Pl- n P3 et Pl- n P3-·

Les intersections de projection de chacun des fragments horizontaux, avec les fragments correspondants (Figure 15) sont donc:

IPI = {(NoClient, Agence), (No Client, TypeCompte, Somme) } IP2 = {(NoClient, Agence, TypeCompte, Somme) }

IP3 = HNoClient), (No Client, Agence), (NoClient, TypeCompte), (No Client, Somme) } IP4 = {(NoClient, Somme), (No Client, Agence, TypeCompte) }

IP5 = HNoClient, Agence, TypeCompte, Somme) }

174723

Agence

NoClient

Lausanne

Fll

,

NoClient TypeCompte Somme
174723 courant 123345.89 F12

,

NoClient Agence TypeCompte Somme
201 639 Lausanne courant 45 102.50
201 639 Lausanne depot 325 100.00 NoClient NoClient Agence
203446 203446 Geneve F31

,

F32

,

NoClient TypeCompte NoClient Somme
203446 courant 203446 274882.95 F33

,

F34

,

177498

Somme

34564.00

NoClient

NoClient Agence TypeCompte
177498 Geneve courant NoClient

Agence

TypeCompte

Somme

F5

FIgure 15 : RelatIOn Compte tragmentee honzontalement et verticalement 8b

La definition formelle des fragments est:

Fl,l = n[NoClient, Agence]

cr[TypeCompte = 'courant' /\ Somme > 100 000 /\ Agence = 'Lausanne'] Compte Fl,2 = n[NoChent, TypeCompte, Somme]

cr[TypeCompte = 'courant' /\ Somme > 100 000 /\ Agence = 'Lausanne'] Compte F2 = cr[(TypeCompte· 'courant' v Somme > 100000) /\ Agence = 'Lausanne'] Compte

F3 1 = n[NoChent]

,

cr[TypeCompte = 'courant' /\ Somme > 100 000 /\ Agence = 'Geneve'] Compte F3,2 = n[NoClient, Agence]

-cr'"'[T"'y-p-e---C...-o-m-pc-te-=----., c-o-u-r-an---Ct-'-' -/\---,S.,--o-m-m-e->----.-I"O"O-,-O""O"'O.---/\------.Ac-g-e-n-c-e-=~'.,..G..--e-n~e-v~e'rr] "'C"--o-m-p---CtC-e

F3,3 = n[NoChent, TypeCompte]

cr[TypeCompte = 'courant' /\ Somme > 100 000 /\ Agence = 'Geneve'] Compte F3 4 = n[NoClient, Somme]

,

cr[TypeCompte = 'courant' /\ Somme > 100 000 /\ Agence = 'Geneve'] Compte ~F~4~1---n~[N~oC~h-en~t.---,~S-o-m-m-e~]

,

o'[Somme s 100000/\ Agence = 'Geneve' /\ TypeCompte = 'courant'] Compte F4,2 = n[NoClient, Agence, TypeCompte]

cr[Somme· 100 000 /\ Agence - 'Geneve' /\ TypeCompte - 'courant'] Compte FS = cr[Agence = 'Geneve' /\ TypeCompte· 'courant'] Compte

La correspondance entre la relation initiale et ses fragments est:

Compte = (Fl,1 * Fl,2) u F2 u (F3,1 * F3,2 * F3,3 * F3,4) U (F4,1 * F4,2) u FS

3.4 Schema d'allocation

L'affectatIOn des fragments sur les sItes est decidee en fonctIOn de l'ongme prevue des requetes qUI ont serVI a la fragmentatIOn. Le but est de placer les fragments sur les sItes OU Ils sont Ie plus utIhses, pour mimmiser les transferts de donnees entre les sItes. La encore, SI on desIre eVIter une allocatIOn trop complexe, on peut se restremdre a ne prendre en consIderatIOn pour chaque requete que les ongmes les plus Importantes (les sItes qUI emettent reguherement cette requete ou ceux dont Ie resultat dOlt leur etre fourm tres rapidement).

Pour chaque requete, on connait l'ensemble des SItes qUI sont susceptIble d'emettre cette requete, et on possecte l'ensemble des fragments qUI sont concernes par la requete. On aSSOCIe donc a chaque fragment l'ensemble des SItes qUI peuvent "reclamer" ce fragment. L'allocatIOn consiste simplement a chOlsn pour chaque fragment Ie SIte de receptIOn Ie plus adequat. Lorsque piusleurs fragments compiementalres d'une meme relatIOn se retrouvent sur Ie meme SIte, ces fragments peuvent etre reumhes pour sImphher les schemas de fragmentatIOn et d'allocatIOn.

Le schema d'allocatIOn conserve l'assignatIOn des fragments sur les SItes, tandis que Ie schema local de chaque SIte dehmt la partie de la base de donnees (l'Image physIque des fragments) qUI est stockee sur ce SIte.

Exemple : Nous aSSOCIOns aux requetes precectentes RI, R2 et R3 les ongmes survantes :

RI peut etre emise de Geneve ou de Lausanne, R2 est presque exclusivement emise de Lausanne,

R3 est Ie plus souvent emise de Geneve, maiS peut aUSSI provemr de Lausanne. Les mises a JOur des comptes de Lausanne sont faites a partIr de Lausanne,

et les mises a JOur des comptes de Geneve sont faItes a Geneve.

Les nuses a jours sont secondanes par rapport aux requetes dans Ie sens ou elles peuvent etre

effectuees en differe, L'allocation des fragments est done basee en priorite sur les sites des requetes et en second sur les sites de mises a jour.

Deux sites, G et L (pour Geneve et Lausanne), sont done pris en consideration. Nous definissons alors les correspondances suivantes :

RI concerne les fragments FIlet F3 2, et est rattachee aux sites G et L

, ,

R2 concerne les fragments FI 1, FI 2 et F2, et est rattachee au site L

, ,

R3 concerne les fragments F3 4 et F4 1, et est rattachee au site G

, ,

Les associations entre fragments et sites sont done :

FIlet F3 2 sont aSSOCIeS a Let G

, ,

F I 2 et F2 sont aSSOCIeS a L

,

F3 4 et F4 1 amsi que F3 1 , F3 3 , F4 2 et FS sont aSSOCIeS a G

" '"

Seul les fragments Fl,l et F3,2 qUi sont aSSOCIeS a deux sItes posent un probleme. Dans Ie but d'eqUIlIbrer Ie nombre de fragments sur chaque sIte, on peut deCIder de stocker FI,1 et F3,2 sur L. Dans ces condItIons, les fragments complementaues peuvent etre reumfIes. Amsi FI,1 , Fl,2 et F2 peuvent etre recomposes en Fa. De meme F3,1 , F3,3 et F3,4 peuvent etre recomposes en F3,b, et F4,1 , F4,2 et FS peuvent etre recomposes en Fc.

Le schema de fragmentation devient done :

Fa = O'[Agence = 'Lausanne'] Compte F3,2 = n[NoClIent, Agence]

O'[TypeCompte = 'courant' /\ Somme > 100 000 /\ Agence = 'Geneve'] Compte F3,b = n[NoClient, TypeCompte, Somme]

O'[TypeCompte = 'courant' /\ Somme > 100 000 /\ Agence = 'Geneve'] Compte Fc = O'[Agence = 'Geneve' /\ (TypeCompte· 'courant' v Somme s 100000)] Compte

Compte = Fa U (F3,2 * F3,b) u Fc

Le schema d'allocatIOn est donc :

F; qui est l'allocation de Fa sur Ie site L,

F3 2 qui est l'allocation de F3,2 sur le site L,

,

Ffb qui est l'allocation de F3,b sur le site G, et

,

F~ qui est l'allocation de F c sur le site G

Le schema local de L est compose de I'lmage physIque de la relatIOn Compte sur L qui est Comptel- = {F;, F} 2}

,

Le schema local de G est compose de I'lmage physIque de la relatIOn Compte sur G qui est

G G G

Compte = {F3 b: F c }

,

3.5 Techniques de repartition avancees

Dans Ie cas ou la methode classique de fragmentatIOn-allocatIOn ne s'avere pas satIsfaisante, des techmques plus pUIssantes maiS plus complexes a mettre en oeuvre dOl vent etre envisagees :

I'allocatIOn avec duplIcatIOn de fragments, I'allocatIOn dynamique des fragments ou meme la fragmentatIOn dynamique.

3.5.1 Allocation avec duplication

Certains fragments peuvent etre dupliquees sur plusieurs sites (eventuellement sur tous les sites) ce qui procure l'avantage d'ameliorer les performances en terme de temps d'execution des requetes (en evitant certains transferts de donnees). Elle permet aussi une meilleure disponibilite des informations (connues de plusieurs sites), et une meilleure fiabilite contre les pannes. Par contre, l'inconvenient majeur est que les mises a jour doivent etre effectuees sur toutes les copies d'une meme donnee.

En consequence, moins un fragment est sujet a des modifications et plus il est predispose a la duplication.

3.5.2 Allocation dynamique

Avec cette technique, l'allocation d'un fragment peut changer en cours d'utilisation de la BDR. Ce peut etre le cas suite a une requete par exemple. Dans ce cas, le schema d'allocation et les schemas locaux doivent etre tenus a jour. Cette technique est une alternative a la duplication qui se revele plus efficace lorsque la base de donnees est sujette a de nombreuses mises a jour.

3.5.3 Fragmentation dynamique

Dans le cas ou le site d'allocation peut changer dynamiquement, il est possible que deux fragments complementaires (verticalement ou horizontalement) se retrouvent sur le meme site. II est alors normal de les fusionner. A l'inverse, si une partie d'un fragment est appele sur un autre site, il peut etre interessant de decomposer ce fragment et de ne faire migrer que la partie concernee. Ces modifications du schema de fragmentation se repercutent sur le schema d'allocation et sur les schemas locaux.

3.5.4 Cliches

Un cliche (snapshot) est une copie figee d'un fragment. II represente l'etat du fragment a un instant donne et n'est jamais mis a jour contrairement aux vues et aux copies qui repercutent toutes les modifications qui ont lieu sur le fragment original. L'interet (la pertinence) d'un cliche diminue done au fur et a mesure que le temps passe. L'utilisation de cliches est interessante lorsque l'on juge que la gestion de copies multiples se revelerait trop lourde pour la base de donnees consideree alors que des copies meme un peu anciennes et non a jours seraient largement suffisantes.

On peut en effet se passer de l'information exacte pour diverses raisons. D'une part l'information contenue dans la base de donnees peut ne pas refleter tout a fait la realite (cas d'un changement d'adresse non signale, par exemple). D'autre part, certaines informations ne subissent pas souvent de modification (comme le nom de famille, l'adresse ou le nombre d'enfants des employes) et par consequent une copie meme ancienne de ces informations est, dans sa grande majorite, encore exacte. Enfin, certaines informations dans un certain contexte ne sont pas de caractere sensible et par consequent une information erronee n'aura pas de repercussion grave: le changement d'adresse d'un employe non repercute n'aura pas d'incidence, les services postaux se charge ant du bon acheminement du courrier pendant plusieurs semaines. A l'inverse, le meme changement d'adresse, non repercute par la Poste (PTT), pourrait avoir des consequences graves.

Les deux criteres qui sont a prendre en compte pour definir l'interet d'un cliche sont d'une part l'anciennete du cliche, et d'autre part le temps d'attente qui serait necessaire avant d'obtenir l'information originale (a jour). Ces deux informations, l'anciennete et le temps d'attente, peuvent etre ponderees par un taux de satisfaction pour le systeme d'information.

Exemple : Dans un milieu bancaire les retraits d'argent par un client ne devraient etre autorises que si le compte est suffisamment approvisionne. Comme les ordres de virement et cheques emis au cours des heures ecoulees ne sont pas encore connus et done non debites, la situation reelle du compte peut etre bien differente de l'etat correspondant dans la base de donnees. Par consequent, la

89

decision d'autoriser un retrait d'argent peut etre prise en fonction d'un cliche legerement ancien plutot que d'acceder a l'information originale qui ne sera que legerement plus fiable. Cependant, une information exacte permettrait de contrecarrer des retraits d'argent successifs dans deux distributeurs a quelques minutes d'intervalle. Nous pouvons done definir les fonctions suivantes :

Taux de satisfaction du cliche par rapport a l'original en fonction de l'age du cliche:

5 minutes: 0.95 3 jour: 0.3

1 Heure : 0.9 1 semaine : 0.1

1 jour: 0.7 1 mois : 0.01 (information tres peu utile)

Taux de satisfaction du temps d'attente pour obtenir l'original :

jusqu'a 30 sec: 1 2 min: 0.5

45 sec: 0.9 3 min: 0.1

1 min: 0.7 5 min: 0.01

Si l'on dispose d'un cliche vieux d'un jour, le temps d'attente maximum pour la reception de l'original est de une minute. Passe ce delai, l'information contenue dans le cliche sera utilisee,

4 Gestion des donnees reparties

Les regles d'eXeCUtIOn et les methodes d'optImisatIOn de requetes dehmes pour un contexte centrahse sont touJours valables, mats 11 faut mamtenant prendre en compte d'une part la fragmentatIOn et la repartItIOn des donnees sur ditferents SItes et d'autre part Ie probleme du cout des commumcatIOns entre SItes pour transferer les donnees. Le probleme de la fragmentatIOn avec ou sans duphcatIOn concerne pnncipalement les nuses a jours tandis que Ie probleme des couts des commumcations concerne surtout les requetes.

4.1 Mise it jour de BD reparties

La principale difficulte reside dans le fait qu'une mise a jour dans une relation du schema global se traduit par plusieurs mises a jours dans differents fragments. II faut done identifier les fragments concernes par l'operation de mise a jour, puis decomposer en consequence l'operation en un ensemble d'operation de mise a jour sur ces fragments.

4.1.11nsertion

Retrouver le fragment horizontal concerne en utilisant les conjonctions de condition qui definissent les fragments horizontaux.

Insertion du tuple dans tous les fragments verticaux correspondants.

Exemple:

Creation d'un nouveau compte pour un client.

INSERT INTO compte

VALUES (184177, Geneve, courant, 350000.00)

C'est la conjonction de conditions cc3 qui est verifiee avec ce tuple.

On ajoute donc (184 177, Geneve) dans F3 2 et (184 177, courant, 350000.00) dans F3 b.

, ,

4.1.2 Suppression

Rechercher le tuple dans les fragments qui sont susceptibles de contenir le tuple concerne (en utilisant, dans la mesure du possible les conjonctions de condition).

Supprimer les valeurs d'attribut du tuple dans tous les fragments verticaux.

4.1.3 Modification

Rechercher lees) tuple(s) dans les fragments qui sont susceptibles de contenir ce(s) tuple(s) (en utilisant, dans la mesure du possible les conjonctions de condition).

Modifier la (les) valeur(s) d'attribut du (des) tuple(s).

Verifier que lees) nouveau(x) tuple(s) ainsi produit verifiemt) toujours la conjonction de condition qui definit le fragment horizontal dans lequel se trouve(nt) ce(s) tuple(s), et si ce n'est pas le cas, deplacer lees) tuple(s) concerners) (suppression puis insertion) dans le bon fragment horizontal.

Exemple:

Ajout de 80 000 francs sur le compte courant d'un client.

UPDATE Compte

SET somme = somme + 80 000.00

WHERE NoChent = 177 498 AND TypeCompte = 'courant'

On effectue une recherche dans tous les fragments pUlsque les mformatIOns connues (N oChent et TypeCompte) ne permettent pas de hItrer les fragments non concernes.

On trouve un seul tuple concerne par la modification, dans le fragment F c.

La modIhcatIOn de la valeur de la somme provoque une nngrauon du tuple (177 498, Geneve, courant, 114564.00). On supprime done (177 498, Geneve, courant, 114564.00) de Fc et on ajoute

(177498, Geneve) dans F3 2 et (177 498, courant, 114564.00) dans F3 b.

, ,

-.4"'.2.----rR,.--e-q-u-,e..-te-s-s-u-r-BT>TD-----re-,-' p-a-r--'t'--ie-s

Comme pour le traitement de requetes en Bases de donnees centralisees, on produit l'arbre algebrique de la requete que l'on optimise avec les memes criteres. Chaque feuille de l'arbre represente une relation, et chaque noeud represente une operation algebrique (operateur + operandes). Cette requete algebrique optimisee est ensuite enrichie avec les informations sur la repartition des donnees sur les differents sites, et sur le lieu (site) ou chaque operation de la requete doit etre executee.

Le temps total d'execution d'une requete tient compte du temps de calcul CPU necessaire pour executer les operations algebriques (jointures, selections ... ), mais aussi et surtout du temps de transfert entre les sites des donnees necessaires a la requete,

4.2.1 Transferts de donnees

Le temps de transmission d'un message tient compte du temps d'acces et de la duree de la transmission (volume des donnees I debit de transmission). Le temps d'acces est negligeable sur un reseau local, mais peut atteindre quelques secondes pour des transmissions sur de longues distances ou via satellite. Dans ces conditions, un traitement ensembliste des donnees s'impose. L'unite de transfert entre sites est done une relation ou un fragment, et non une occurrence.

Exemple : Soit la BDR composee des relations suivantes :

P (NP, NOMP, MADE_IN, COULEUR, POIDS) U (NU, VILLEU, NOMU)

F (NF, NOMF, VILLEF, ADRESSE, PAYS, COEF) PUF (NP, NU, NF, DATE, QUANTITE)

Les relations U et PUF sont sur le site A. Les relations F et P sont sur le site B.

Le reseau reliant les deux sites A et Bales caracteristiques techniques suivantes : - temps d'acces d'un site a un autre: 0,5 seconde

- debit de transmission : 9 600 bauds (soit > 1 000 octets d'informations utiles I

secondes)

Un message est done transfere en ( 0,5 + Nb-d'octets-du-message 11000) secondes. 91

A la requete "Donner les numeros et les noms des fournisseurs qui ont livre un produit italien a une usine situee a Lausanne", qui provient du site B, correspond la requete algebrique suivante :

R = I1(NOMF, NF) (a(VILLEU = "Lausanne")U * PUF * a(MADE_IN = "Italy")P * F)

Soient les deux strategies d'execution envisagees :

81 : Selectionner les produits italiens sur B. Pour chacun de ces enregistrements, interroger A pour savoir si le produit a he livre dans une usine de Lausanne et par qui. La reponse contient les numeros (NF) des fournisseurs qui livrent ce produit a Lausanne.

S2 : SeLectionner les numeros (NP) des produits ita liens sur B. Transmettre ces numeros au site A en lui demandant qu'iZ rrenvoie les numeros des journisseurs qui ont livre un de ces produits a une usine de Lausanne. Le site A transmet un ensemble de numeros de journisseurs a B.

F contient 100 fournisseurs. P contient 500 produits italiens, qui concernent 800 livraisons a Lausanne. Les numeros (NP et NF) sont codes sur 2 octets.

Avec la premiere strategie, 500 messages contenant un numero de produit sont envoyes de B vers A et autant de reponses (contenant 800 numero de fournisseurs, dont beaucoup de doubles) sont renvoyees (Figure 16). Le temps de transfert de donnees est done au total:

T1 = 500 * (0,5 + 2/ 1000) + 500 * 0,5 + 800 * 2/ 1000 = 503 secondes (8 minutes)

B

Figure 16 : transferts individuels des occurrences

Avec la strategic S2, un message contenant 500 numero est envoye au site A (Figure 17), qui renvoie a B un message contenant au plus 100 numeros de fournisseurs (puisqu'il n'y a que 100 fournisseurs dans la BD !).

Le temps de transfert de donnees est done au total:

T2 = 0,5 + (500 * 2) /1000 + 0,5 + (100 * 2) /1000 soit 1,7 seconde

l\JF

A

B

Figure 17 : Transferts ensemblistes des donnees

4.2.2 Traitement de requetes reparties

Le but est d'affecter de maniere optimale un site d'execution pour chacune des operations algebriques de l'arbre. Pour cela, on associe a chacune des feuilles le site sur lequel la relation va etre puisee. Lorsqu'une relation est dupliquee, le choix du site de depart est un element d'optimisation (la decision peut alors etre laissee en suspend). On cherche ensuite a associer a chaque noeud de l'arbre le site sur Iequel l'operation algebrique associee a ce noeud sera executee, Generalement, il faut faire localement tous les traitements qui peuvent y etre faits. Ainsi, lorsque tous les operandes d'une meme operation algebrique sont situes sur le meme site, la solution la moins couteuse pour executer cette operation est le plus souvent de l'executer sur ce site. Ceci est

notamment toujours vrai pour les operateurs unaires qui font diminuer le volume d'informations (selection, projection).

Pour diminuer le volume de donnees transmis d'un site a un autre, il faut limiter les transferts d'information aux seules informations utiles. Pour cela il faut systematiquement rajouter des projections dans l'arbre algebrique pour abandonner les attributs inutiles. II faut aussi noter que les parties de requetes independantes peuvent etre executees en parallele sur des sites differents et done abaisser le temps total d'execution.

Exemple : La requete de l'exemple precedent est decomposee pour etre executee sur la BD rep artie (Figure 18).

r------------------------------,

I1 [NOMF, NF]

I

*

~

F

I1 [NF]

I

-: /*~

*

cr [VILLEU = "Lausanne"]

I

PUF

A

U

I1 [NP]

I

cr [MADE_IN = "Italy"]

I

P

Figure 18 : Execution d'une requete repartie Ceci correspond a la sequence suivante :

sur B : Rl = I1[NP] cr(MADE_IN = "Italy")P transmettre RIa A

sur A: R2 = I1[NF] (cr(VILLEU = "Lausanne")U * PUF) * Rl transmettre R2 a B

sur B : I1(NOMF, NF) (R2 * F)

4.2.3 Optimisation dynamique des requetes

B

La principale difference entre un SGBD et un SGBDR au point de vue de l'optimisation des requetes se trouve dans le fait que l'optimisation de requete en centralise est principalement statique, c'est a dire calcule avant l'execution en se basant sur les criteres de volume de donnees, pour savoir si telle operation peut etre effectuee en memoire centrale, et moyens d'acces (index, ordonnancement, tri). Au contraire, l'optimisation de requete dans un environnement reparti se base aussi sur le temps de communication qui est fonction des criteres suivants : volume de donnees transfere, nombre de communications, temps d'acces et temps de reponse, temps de calcul UC sur chacun des sites.

Elle peut done etre fortement dynamique: apres avoir initialement genere un arbre de requete, la strategic adoptee pour l'execution est ascendante. C'est a dire que l'affectation de chaque noeud de l'arbre a un site peut etre decide en cours d'execution en fonction des differents volumes de donnees intermediaires obtenus sur les sites. On part done des feuilles, ou l'on connait les donnees (type,

volume, stausuqucs sur la repartition des occurrences dans les domaines de valeurs ... ) pour remonter au niveau superieur et prendre une decision sur Ie site d'affectation de l'operateur. Et ainsi de suite pour les niveaux superieurs jusqu'a la racine. II faut cependant noter que cette strategie n'est pas optimale si elle est effectuee en aveugle : il faut en effet prendre en compte tout l'arbre de la requete pour regarder si une decision d'affectation qui semble bonne ponctuellement ne risquerait pas de reposer des problemes aux niveaux superieurs,

D'une maniere generale, il faut tenir compte des volumes de donnees de chaque relation, et de leur composition. II est en effet parfois interessant de tenir compte du calcul effectue par un site avant que les autres sites se mettent a travailler. Dans l'exemple precedent, si l'on n'est pas sur qu'il existe des produits italiens, Ie site A peut attendre que Bait fini la selection (et fait connaitre son resultat ) pour savoir s'il est necessaire de calculer la jointure entre les Usines et les livraisons. Ceci peut etre un critere de decision pour tous les operateurs qui peuvent produire une relation vide (selection, jointure, intersection).

4.2.4 Semi-jointure

Les BDR ont abouti a la definition d'un nouvel operateur, la serru-jornture, qu'il est parfois interessant d'utiliser. II s'agit en fait d'une double jointure : Ie principe est d'effectuer deux petites jointures plutot qu'une grosse; c'est a dire deux petites transmissions de donnees plutot qu'une seule beaucoup plus volumineuse.

Soit R et S deux relations ayant X comme ensemble d'attributs en commun.

La semi-jointure entre R et S est R * I1[X]S. C'est a dire que l'on ne garde dans R que les occurrences ayant pour X une valeur qui est presente dans au moins une occurrence de S.

Exemple : Sur la base de donnees precedente, on recherche sur Ie site A les couples (fournisseur, usine) tels que Ie fournisseur habite dans la ville ou se trouve l'usine.

On se propose done d'optimiser la requete suivante: F' * U' ou F' = a [VILLEF: VILLE]F

et U' = a[VILLEU:VILLE]U

Les 100 fournisseurs habitent dans 60 villes differentes. Les 1000 usines sont reparties dans 840 villes differentes,

5 fournisseurs habitent dans une ville ou se trouve au moins une usine

100 usines sont situees dans une ville ou habitent un ou plusieurs fournisseurs Les occurrences des fournisseurs ont une longueur de 120 octets.

Les occurrences des usines ont une longueur de 60 octets.

Si Ie site A envoie U a B (Figure 18), il transmet 60 000 octets.

*
~ ~
a [VILLEF: VILLE]
a [VILLEU : VILLE] I
I
U F
A B FIgure 18 : EXecutIOn de U' * (F' * I1[VILLE]U')

Avec une semI Jomture (FIgure 19), A enVOle aBies 840 noms de vIlles d'usme (25 200 octets) et B renvoie les 5 fourmsseurs retenus (600 octets). SOlt un total de 25 800 octets transferes entre sites.

*

*

II [VILLE]

/

I

a [VILLEF : VILLE

I

a [VILLEU : VILLE]

I

F

A

U

B

Figure 19 : Execution de U' * (F' * rr[VILLE]U')

Avec une double semi jointure (Figure 20), B transmet a A 60 noms de ville differents (soit 1800 octets) et A lui renvoie Ie resultat de la (semi-)jointure (equivalente a l'intersection dans ce cas precis) entre ces villes des fournisseurs et les villes des usines. Ce resultat contient au maximum 5 villes (puisque l'on sait a posteriori que seulement 5 fournisseurs seront retenus) soit entre 30 et 150 octets.

Enfin B fait la seconde semi-jointure et envoie a Ales 5 fournisseurs retenus soit 600 octets. Ce qui fait au maximum 1800 + de 30 a 150 + 600 soient entre 2 430 et 2 550 octets.

* ...-..
-
~*
-
r~ r-,
II [VILLE] II [VILLE]
/ ~
a [VILLEU : VILLE] a [VILLEF : VILLE]
A I I B
U F Figure 20: Execution de U' * (F' * (rr[VILLE]U' * rr[VILLE]F'))