Module 215

Bases de Donnes Avances

Bases de donnes rparties

1 - Introduction 2 - Fragmentation 3 - Optimisation des requtes

Exercices Bibliographie

Grard-Michel Cochard cochard@u-picardie.fr

Introduction
Contenu : 1. Besoins 2. Aspects caractristiques 3. Dmarche de conception

1. Besoins
Dans une base de donnes centralise, il y a un seul SGBD, un seul stockage physique, une seule unit de traitement. Dans une base de donnes rparties, il peut y avoir plusieurs SGBD, plusieurs sites de stockage et plusieurs units de traitement. Les raisons qui prsident la cration des bases de donnes rparties sont multiples :
q q q q q

limiter le transfert d'informations rpartir la charge de travail entre plusieurs units de traitement ou de stockage augmenter la fiabilit augmenter la disponibilit faciliter l'interoprabilit

dfinition : une base de donnes rpartie est une base de donnes dont les diffrentes parties sont stockes sur des sites distants relis par rseau.

2 - Aspects caractristiques
On peut reprsenter trs schmatiquement une base de donnes rparties par l'image suivante :

Cette base doit obir 3 principes de "transparence" :

q

q q

transparence de localisation : lutilisateur accdent au schma conceptuel via des vues ; il ne sait pas sur quel site se trouvent physiquement les donnes transparence de partitionnement : lutilisateur ne sait pas comment la base est partitionne transparence de duplication : lutilisateur ne sait pas sil existe des copies des informations, ni o elles se trouvent si elles existent

Une base de donnes est usuellement modlise en 3 niveaux : externe, conceptuel, interne. Pour une base de donnes rparties, la rpartition a lieu dans les trois niveaux :

les vues des utilisateurs sont prsentes sur leur site (site utilisateur) ; elles correspondent au niveau externe. Il y a donc rpartition des vues. le schma conceptuel (global) est associ aux schmas locaux des sites physiques via un schma de fragmentation (la manire dont la base est dcoupe) et un schma d'allocation (la manire dont les fragments sont rpartis). il n'y a pas de schma interne global, mais des schmas locaux internes.

3 - Dmarche de conception
Pour concevoir une base de donnes rparties, il faut commencer par les deux tapes standards de conception des bases de donnes centralises. 1) Recueillir l'expression des besoins des utilisateurs et en dduire les vues externes prvoir. 2) Intgrer ces vues dans un schma conceptuel global et unique

Les deux phases suivantes sont des phases critiques et dlicates pour des bases de donnes rparties : 3) Cration du schma de fragmentation : la base de donnes sera dcoupe en fragments distincts constituant une partition de la base : l'intersection des fragments doit tre vide et leur runion doit redonner le schma global. 4) Cration du schma d'allocation : les fragments doivent tre distribus "au mieux" entre les diffrents sites. Les deux dernires phases concernent les sites locaux : 5) Cration d'un schma local pour chaque site, relatif aux fragments dvolus ce site. 6) Cration des schmas internes : implmentation des donnes des fragments sur les supports physiques de stockage.

Fragmentation
1. Dcomposition en fragments 2. Rpartition par classes d'objets 3. Fragmentation horizontale 4. Fragmentation verticale 5. Fragmentation par valeurs Contenu : 6. Mthodologie de la fragmentation horizontale 7. Mthodologie de la fragmentation verticale 8. Schma de localisation 9. Mises jour

1. Dcomposition en fragments
Il s'agit de dcomposer la base de donnes en fragments sans perte d'information. On procde de la manire suivante :
q

la non perte d'informations est vrifie par recomposition de la base en utilisant le langage de manipulation de donnes (SQL par exemple). les fragments doivent tre exclusifs (il ne s'agit pas de duplication)

Pour dcouper la base, il faut descendre un certain degr de granularisation aboutissant des units de fragmentation (considres comme inscables). On peut procder de 4 manires (ventuellement combinables) :
q q q q

la rpartition par classes d'objets la rpartition par occurrences (tuples) ou fragmentation horizontale la rpartition par attributs ou fragmentation verticale la rpartition par valeurs qui combine les deux prcdentes.

Pour dfinir le schma de fragmentation, il faudra

q q q q

dfinir les fragments, c'est dire constituer un partition nement de la base dfinir la correspondance schma global --> fragments dfinir la correspondance fragments --> schma global (recomposition)

2 - Rpartition par classes d'objets

Le mot "classe" est utilis ici de manire trs gnrique ; il peut dsigner une "vraie" classe (modle objet), une entit (modle entit-association), une relation ou table (modle relationnel), ... Les fragments sont dfinis partir des "classes" de la base de donnes. exemple : soit une base de donnes constitue de 3 tables EQUIPE, CUISINIER, RESTAURANT. Ces trois tables correspondront trois fragments.

3 - Fragmentation horizontale

Encore appele fragmentation par occurrences, la fragmentation horizontale est base sur un dcoupage des tuples des "classes". exemple : Considrons la table CUISINIER. Elle peut tre divise en deux fragments par rpartition des tuples en deux catgories :

La recomposition s'effectuera par une simple opration d'union.

4 - Fragmentation verticale
Dans la fragmentation verticale ou fragmentation par attributs, les fragments sont construits partir de quelques attributs d'une "classe". exemple : la table CUISINIER peut tre rpartie en 2 fragments, l'un avec les attributs numero, nom, prenom, l'autre avec les attributs numero, numeq. On constatera que l'attribut numero est commun ; c'est une ncessit car numero est la cl de la table et la recomposition n'est possible que grce cet attribut (par jointure).

5 - Fragmentation par valeurs

Cette fragmentation combine la fragmentation horizontale et verticale. exemple :

La recomposition s'effectuera avec l'opration : cuisinier = (fragment 1 ><fragment 2) U (fragment 3><fragment 4)

6 - Mthodologie de fragmentation horizontale

Pour tudier comment dcomposer une base de donnes en fragments horizontaux on se basera sur un exemple concret (et exotique). exemple : On considre la table CUISINIER des exemples prcdents que l'on se propose de rpartir en fragments horizontaux. On commencera par se baser sur les requtes les plus frquentes :
q

q q

R1 : SELECT numero, numeq FROM CUISINIER WHERE prenom = 'Jean' AND nom LIKE '%R%'; R2 : SELECT * FROM CUISINIER WHERE numeq = '1'; R3 : SELECT numero, nom FROM CUISINIER WHERE numeq = '2' AND prenom = 'Jean';

Pour effectuer la fragmentation horizontale on se base sur les critres de recherche, c'est dire les conditions exprimes dans les "WHERE" des ordres SQL. On a C1 = AB, C2 = C, C3 = DA o dsigne le "ET LOGIQUE" et A, B, C, D reprsentent les prdicats suivants : A : prenom = 'Jean' B : nom LIKE '%R%' C : numeq = '1' D : numeq = '2' On a videmment CD = , CD = D, CD = C o C et D dsignent les contraires de C et D. A partir des conditions Ci, on peut construire l'ensemble des conjonctions CCj de conditions : CC = { Ci* pour i = 1,n et Ci* = Ci ou Ci} Concrtement : CC = {C1C2C3, C1C2C3, C1C2C3, C1C2C3, C1C2C3, C1C2C3, C1C2C3, C1C2C3} Evaluons chacun des termes : C1C2C3 = C1C2C3 = C1C2C3 = ABD C1C2C3 = ABC

C1C2C3 = ABD C1C2C3 = ABCD C1C2C3 = (AB)C C1C2C3 = (AC)(BCD)

o dsigne le "OU LOGIQUE". Supposons, comme hypothse supplmentaire, qu'il n'y a que deux quipes de cuisiniers (1 et 2) ce qui implique CD = , C = D, D = C. On a alors les 5 conjonctions significatives de conditions : CC1 = C1C2C3 = ABD CC2 = C1C2C3 = ABC CC3 = C1C2C3 = ABD CC4 = C1C2C3 = (AB)C CC5 = C1C2C3 = AD Ces 5 conditions dfinissent les fragments horizontaux (exclusifs) :

7 - Mthodologie de fragmentation verticale

Pour la fragmentation horizontale, on s'intresse ce que l'on cherche comme valeurs des

attributs, c'est dire aux projections des relations sur certains attributs. Nous allons reprendre l'exemple prcdent pour expliciter concrtement la mthodologie de fragmentation verticale. exemple : Reprenons les requtes les plus frquentes :
q

q q

R1 : SELECT numero, numeq FROM CUISINIER WHERE prenom = 'Jean' AND nom LIKE '%R%'; R2 : SELECT * FROM CUISINIER WHERE numeq = '1'; R3 : SELECT numero, nom FROM CUISINIER WHERE numeq = '2' AND prenom = 'Jean';

Les projections sont : P1 : (numero, numeq) P3 : (numero, nom) P2 n'est pas considre comme une projection car tous les attributs sont demands dans la requte R2. A partir de P1 et P3, on construit l'ensemble IP des intersections de projections : IP = { IPj* pour j = 1,n et Pj* = Pj ou ~Pj} o ~Pj dsigne le complment de Pj sur l'ensemble des attributs de la table CUISINIER avec l'incorporation obligatoire de la cl numero : ~P1 = (numero, nom, prenom) ~P3 = (numero, prenom, numeq) Concrtement IP = {P1IP1, ~P1I~P1, P3IP3, ~P3I~P3, P1IP3, P1I~P3, ~P1I~P3} avec P1IP1 = P1 = (numero, numeq) ~P1I~P1 = ~P1 = (numero, nom, prenom) P3IP3 = P3 = (numero, nom) ~P3I~P3 = ~P3 = (numero, prenom, numeq) P1IP3 =(numero) ~P1IP3 = (numero, nom) P1I~P3 = (numero, numeq) ~P1I~P3 = (numero, prenom) On reprend chaque fragment et on regarde quelles sont les requtes qui les concernent :

Le fragment 1 est concern par les requtes R1 et R3, donc par tous les lments de l'ensemble IP construits partir de P1 et P3, soit P1IP3, ~P1IP3, P1I~P3, ~P1I~P3 IP1 = {(numero), (numero, nom), (numero, numeq), (numero, prenom)} Le fragment 2 est concern par les requtes R1 et R2, donc seulement par les projections P1 et ~P1, donc par les lments de IP P1IP1 = P1 et ~P1I~P1 = ~P1, donc : IP2 = {(numero, numeq), (numero, nom, prenom)} Le fragment 3 est concern par la requte R3 donc seulement par les projections P3 et ~P3, donc par les lments de IP P3IP3 = P3 et ~P3I~P3 = ~P3, donc : IP3 = {(numero, nom), (numero, prenom, numeq)} Le fragment 4 est concern par la requte R2, donc par tous les attributs : IP4 = {(numero, nom, prenom, numeq)} Le fragment 5 n'est concern par aucune des requtes, donc par tous les attributs : IP5 = {(numero, nom, prenom, numeq)} On dduit de ces considrations les divers fragments :

8 - Schma de localisation
Pour dfinir le schma de localisation, on recherche 1) d'o sont mises les requtes (priorit 1) 2) d'o sont faites les mises jour (priorit 2)

exemple : reprenons l'exemple prcdent et supposons que deux sites soient pris en considration. Supposons que la requte R1 soit mise de A ou B, que la requte R2 soit mise de A seulement et que la requte R3 soit mise de B seulement. Pour les trois requtes, les fragments suivants sont concerns : R1 --> fragment 13, fragment 21 R2 --> fragment 21, fragment 22, fragment 41 R3 --> fragment 12, fragment 31 On fera donc les affectations site A : fragment 13, fragment 21, fragment 22, fragment 41 site B : fragment 12, fragment 31 On notera que l'on a fait un choix arbitraire pour le fragment 21. Pour les autres fragments, on cherche quilibrer les sites : site A : fragment 11, fragment 51 site B : fragment 14, fragment 32 On peut alors constater que certains fragments peuvent tre recombins : site A : fragment 11, fragment 13, fragment 2, fragment 4, fragment 5 site B : fragment 12, fragment 14, fragment 3

9 - Mises jour
Les mises jour consistent en les trois oprations d'insertion (INSERT), de suppression (DELETE) et de modification (UPDATE). Insertion

exemple : insrer un nouveau cuisinier dans la table CUISINIER : INSERT INTO CUISINIER VALUES(21, 'DUBOUT', 'Jean', 2); Le fragment horizontal concern peut tre retrouv avec les CC (pour le cas prsent, il s'agit de CC3) ; ensuite il faut insrer le tuple dans tous les fragments verticaux.

Suppression exemple : suppression du cuisinier Jean DUBOUT : DELETE FROM CUISINIER WHERE nom = 'DUBOUT' AND prenom = 'Jean' ; On utilise "au mieux" les conditions CC : -- pas de "R' dans le nom : B -- prenom = 'Jean' : A Donc CC3 et CC4 sont concernes. On cherchera donc dans les fragments correspondants exemple : supprimer le cuisinier de numro 21 DELETE FROM CUISINIER WHERE numero = 21 ; On est ici oblig de chercher dans tous les segments Modification

exemple : modification de l'affectation du cuisinier DUBOUT UPDATE CUISINIER SET numeq = 1 WHERE nom = 'DUBOUT' ; La condition de slection est B ; il faut donc chercher dans les fragments concerns par CC3, CC4, CC5. On trouve l'enregistrement dans le fragment 3. On modifie puis on vrifie que la CC est toujours vrifie ; ce n'est plus le cas ici puisque numeq = 1. La nouvelle condition est BC soit CC4. On dplace alors le tuple dans le fragment 4.

Optimisation des requtes

Une requte sur une base de donnes rparties ncessite gnralement des transferts de donnes entre sites. Ces transferts sont responsables au premier chef d'un allongement du temps de rponse car les traitements internes sont bien plus rapides que le transport des donnes. On raisonnera sur un exemple pour illustrer la problmatique. exemple : soit une base de donnes compose de deux tables et rpartie sur 4 sites S1, S2, S3, S4.

Supposons que la requte soit formule sur un site S0 : SELECT prenom FROM CUISINIER, EQUIPE WHERE CUISINIER.numeq = EQUIPE.numeq AND nomeq = "les chefs" ; On peut envisager plusieurs stratgies dont les deux suivantes :

Dans la stratgie 1, on commence par slectionner les tuples sur l'attribut nomeq='les chefs' dans les fragments E1 et E2 sur les sites S3 et S4 respectivement. Les rsultats E'1 et E'2 sont ensuite transfrs sur les sites S1 et S2 respectivement. Sur ces sites les jointures avec C1 et C2 sont effectues. Les rsultats C'1 et C'2 sont ensuite transfres sur le site de consultation S0. L'union des tuples est effectue puis la projection sur l'attribut prenom. Dans la stratgie 2, on commence par transfrer tout sur le site de consultation o l'on effectue les oprations adquates pour obtenir le rsultat cherch.

Comparons les deux stratgies en supposant les donnes suivantes : le temps d'accs ta un tuple ncessite 1 unit de temps, le temps de transfert d'un tuple entre deux sites ncessite 10 units de temps. On suppose que C1 et C2 contiennent chacun 50 tuples et que E1 et E2 contiennent chacun 10 tuples ce qui signifie qu'une quipe possde en moyenne 5 cuisiniers. stratgie 1 temps de cration de E'1 : 10ta temps de cration de E'2 : 10ta E'1 contient 0 ou 1 tuple E'2 contient 1 ou 0 tuple temps de transfert de E'1 : 0 ou tr temps de transfert de E'2 : tr ou 0 temps de cration de C'1 : 0 ou 50ta temps de cration de C'2 : 50ta ou 0 C'1 contient 0 ou 5 tuples C'2 contient 5 ou 0 tuples temps de transfert de C'1 : 0 ou 5tr temps de transfert de C'2 : 5tr ou 0 temps de cration de R : 5ta En dfinitive le temps de rponse est 75ta + 6tr, soit 135 units. Bien que notre calcul soit grossier et approximatif, il permet de faire une nette distinction entre les deux stratgies : la stratgie 1 est bien meilleure que la stratgie 2.

stratgie 2 temps de transfert de C1 : 50tr temps de transfert de C2 : 50tr temps de transfert de E1 : 10tr temps de transfert de E2 : 10tr temps de cration de E' : 20ta temps de cration de R : 100ta + 5ta = 105ta En dfinitive, le temps de rponse est 125ta + 120tr soit 1325 units.