Module 215
Bases de Données Avancées
Bases de données réparties
1 - Introduction 2 - Fragmentation 3 - Optimisation des requêtes
Exercices Bibliographie
Gérard-Michel Cochard
[email protected]
Introduction Contenu :
1. Besoins 2. Aspects caractéristiques 3. Démarche de conception
1. Besoins Dans une base de données centralisée, il y a un seul SGBD, un seul stockage physique, une seule unité de traitement. Dans une base de données réparties, il peut y avoir plusieurs SGBD, plusieurs sites de stockage et plusieurs unités de traitement. Les raisons qui président à la création des bases de données réparties sont multiples : ● ● ● ● ●
limiter le transfert d'informations répartir la charge de travail entre plusieurs unités de traitement ou de stockage augmenter la fiabilité augmenter la disponibilité faciliter l'interopérabilité
définition : une base de données répartie est une base de données dont les différentes parties sont stockées sur des sites distants reliés par réseau.
2 - Aspects caractéristiques On peut représenter très schématiquement une base de données réparties par l'image suivante :
Cette base doit obéir à 3 principes de "transparence" : ●
● ●
transparence de localisation : l’utilisateur accèdent au schéma conceptuel via des vues ; il ne sait pas sur quel site se trouvent physiquement les données transparence de partitionnement : l’utilisateur ne sait pas comment la base est partitionnée transparence de duplication : l’utilisateur ne sait pas s’il existe des copies des informations, ni où elles se trouvent si elles existent
Une base de données est usuellement modélisée en 3 niveaux : externe, conceptuel, interne. Pour une base de données réparties, la répartition a lieu dans les trois niveaux :
●
●
●
les vues des utilisateurs sont présentées sur leur site (site utilisateur) ; elles correspondent au niveau externe. Il y a donc répartition des vues. le schéma conceptuel (global) est associé aux schémas locaux des sites physiques via un schéma de fragmentation (la manière dont la base est découpée) et un schéma d'allocation (la manière dont les fragments sont répartis). il n'y a pas de schéma interne global, mais des schémas locaux internes.
3 - Démarche de conception Pour concevoir une base de données réparties, il faut commencer par les deux étapes standards de conception des bases de données centralisées. 1) Recueillir l'expression des besoins des utilisateurs et en déduire les vues externes à prévoir. 2) Intégrer ces vues dans un schéma conceptuel global et unique
Les deux phases suivantes sont des phases critiques et délicates pour des bases de données réparties : 3) Création du schéma de fragmentation : la base de données sera découpée en fragments distincts constituant une partition de la base : l'intersection des fragments doit être vide et leur réunion doit redonner le schéma global. 4) Création du schéma d'allocation : les fragments doivent être distribués "au mieux" entre les différents sites. Les deux dernières phases concernent les sites locaux : 5) Création d'un schéma local pour chaque site, relatif aux fragments dévolus à ce site. 6) Création des schémas internes : implémentation des données des fragments sur les supports physiques de stockage.
Fragmentation 1. Décomposition en fragments 2. Répartition par classes d'objets 3. Fragmentation horizontale 4. Fragmentation verticale 5. Fragmentation par valeurs Contenu : 6. Méthodologie de la fragmentation horizontale 7. Méthodologie de la fragmentation verticale 8. Schéma de localisation 9. Mises à jour
1. Décomposition en fragments Il s'agit de décomposer la base de données en fragments sans perte d'information. On procède de la manière suivante : ●
●
la non perte d'informations est vérifiée par recomposition de la base en utilisant le langage de manipulation de données (SQL par exemple). les fragments doivent être exclusifs (il ne s'agit pas de duplication)
Pour découper la base, il faut descendre à un certain degré de granularisation aboutissant à des unités de fragmentation (considérées comme insécables). On peut procéder de 4 manières (éventuellement combinables) : ● ● ● ●
la répartition par classes d'objets la répartition par occurrences (tuples) ou fragmentation horizontale la répartition par attributs ou fragmentation verticale la répartition par valeurs qui combine les deux précédentes.
Pour définir le schéma de fragmentation, il faudra ● ● ● ●
définir les fragments, c'est à dire constituer un partition nement de la base définir la correspondance schéma global --> fragments définir la correspondance fragments --> schéma global (recomposition)
2 - Répartition par classes d'objets Le mot "classe" est utilisé ici de manière très générique ; il peut désigner une "vraie" classe (modèle objet), une entité (modèle entité-association), une relation ou table (modèle relationnel), ... Les fragments sont définis à partir des "classes" de la base de données. exemple : soit une base de données constituée de 3 tables EQUIPE, CUISINIER, RESTAURANT. Ces trois tables correspondront à trois fragments.
3 - Fragmentation horizontale
Encore appelée fragmentation par occurrences, la fragmentation horizontale est basée sur un découpage des tuples des "classes". exemple : Considérons la table CUISINIER. Elle peut être divisée en deux fragments par répartition des tuples en deux catégories :
La recomposition s'effectuera par une simple opération 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 répartie 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 nécessité car numero est la clé de la table et la recomposition n'est possible que grâce à cet attribut (par jointure).
5 - Fragmentation par valeurs Cette fragmentation combine la fragmentation horizontale et verticale. exemple :
La recomposition s'effectuera avec l'opération : cuisinier = (fragment 1 >
6 - Méthodologie de fragmentation horizontale Pour étudier comment décomposer une base de données en fragments horizontaux on se basera sur un exemple concret (et exotique). exemple : On considère la table CUISINIER des exemples précédents que l'on se propose de répartir en fragments horizontaux. On commencera par se baser sur les requêtes les plus fréquentes : ●
● ●
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 critères de recherche, c'est à dire les conditions exprimées dans les "WHERE" des ordres SQL. On a C1 = A∧B, C2 = C, C3 = D∧A où ∧ désigne le "ET LOGIQUE" et A, B, C, D représentent les prédicats suivants : A : prenom = 'Jean' B : nom LIKE '%R%' C : numeq = '1' D : numeq = '2' On a évidemment C∧D = Φ, ¬C∧D = D, C∧¬D = C où ¬C et ¬D désignent 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} Concrètement : CC = {C1∧C2∧C3, ¬C1∧C2∧C3, C1∧¬C2∧C3, C1∧C2∧¬C3, ¬C1∧¬C2∧C3, C1∧¬C2∧¬C3, ¬C1∧C2∧¬C3, ¬C1∧¬C2∧¬C3} Evaluons chacun des termes : C1∧C2∧C3 = Φ ¬C1∧C2∧C3 = Φ C1∧¬C2∧C3 = A∧B∧D C1∧C2∧¬C3 = A∧B∧C
¬C1∧¬C2∧C3 = A∧¬B∧D C1∧¬C2∧¬C3 = A∧B∧¬C∧¬D ¬C1∧C2∧¬C3 = (¬A∨¬B)∧C ¬C1∧¬C2∧¬C3 = (¬A∧¬C)∨(¬B∧¬C∧¬D) où ∨ désigne le "OU LOGIQUE". Supposons, comme hypothèse supplémentaire, qu'il n'y a que deux équipes de cuisiniers (1 et 2) ce qui implique ¬C∧¬D = Φ, ¬C = D, ¬D = C. On a alors les 5 conjonctions significatives de conditions : CC1 = C1∧¬C2∧C3 = A∧B∧D CC2 = C1∧C2∧¬C3 = A∧B∧C CC3 = ¬C1∧¬C2∧C3 = A∧¬B∧D CC4 = ¬C1∧C2∧¬C3 = (¬A∨¬B)∧C CC5 = ¬C1∧¬C2∧¬C3 = ¬A∧D Ces 5 conditions définissent les fragments horizontaux (exclusifs) :
7 - Méthodologie de fragmentation verticale Pour la fragmentation horizontale, on s'intéresse à ce que l'on cherche comme valeurs des
attributs, c'est à dire aux projections des relations sur certains attributs. Nous allons reprendre l'exemple précédent pour expliciter concrètement la méthodologie de fragmentation verticale. exemple : Reprenons les requêtes les plus fréquentes : ●
● ●
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 considérée comme une projection car tous les attributs sont demandés dans la requête 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 désigne le complément 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) Concrètement 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 requêtes qui les concernent :
Le fragment 1 est concerné par les requêtes R1 et R3, donc par tous les éléments 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 requêtes R1 et R2, donc seulement par les projections P1 et ~P1, donc par les éléments de IP P1IP1 = P1 et ~P1I~P1 = ~P1, donc : IP2 = {(numero, numeq), (numero, nom, prenom)} Le fragment 3 est concerné par la requête R3 donc seulement par les projections P3 et ~P3, donc par les éléments de IP P3IP3 = P3 et ~P3I~P3 = ~P3, donc : IP3 = {(numero, nom), (numero, prenom, numeq)} Le fragment 4 est concerné par la requête R2, donc par tous les attributs : IP4 = {(numero, nom, prenom, numeq)} Le fragment 5 n'est concerné par aucune des requêtes, donc par tous les attributs : IP5 = {(numero, nom, prenom, numeq)} On déduit de ces considérations les divers fragments :
8 - Schéma de localisation Pour définir le schéma de localisation, on recherche 1) d'où sont émises les requêtes (priorité 1) 2) d'où sont faites les mises à jour (priorité 2)
exemple : reprenons l'exemple précédent et supposons que deux sites soient pris en considération. Supposons que la requête R1 soit émise de A ou B, que la requête R2 soit émise de A seulement et que la requête R3 soit émise de B seulement. Pour les trois requêtes, les fragments suivants sont concernés : 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 recombinés : 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 opérations d'insertion (INSERT), de suppression (DELETE) et de modification (UPDATE). Insertion
exemple : insérer 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 présent, il s'agit de CC3) ; ensuite il faut insérer 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 concernées. On cherchera donc dans les fragments correspondants exemple : supprimer le cuisinier de numéro 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 sélection est ¬B ; il faut donc chercher dans les fragments concernés par CC3, CC4, CC5. On trouve l'enregistrement dans le fragment 3. On modifie puis on vérifie que la CC est toujours vérifiée ; ce n'est plus le cas ici puisque numeq = 1. La nouvelle condition est ¬B∧C soit CC4. On déplace alors le tuple dans le fragment 4.
Optimisation des requêtes Une requête sur une base de données réparties nécessite généralement des transferts de données entre sites. Ces transferts sont responsables au premier chef d'un allongement du temps de réponse car les traitements internes sont bien plus rapides que le transport des données. On raisonnera sur un exemple pour illustrer la problématique. exemple : soit une base de données composée de deux tables et répartie sur 4 sites S1, S2, S3, S4.
Supposons que la requête soit formulée sur un site S0 : SELECT prenom FROM CUISINIER, EQUIPE WHERE CUISINIER.numeq = EQUIPE.numeq AND nomeq = "les chefs" ; On peut envisager plusieurs stratégies dont les deux suivantes :
●
●
Dans la stratégie 1, on commence par sélectionner les tuples sur l'attribut nomeq='les chefs' dans les fragments E1 et E2 sur les sites S3 et S4 respectivement. Les résultats E'1 et E'2 sont ensuite transférés sur les sites S1 et S2 respectivement. Sur ces sites les jointures avec C1 et C2 sont effectuées. Les résultats C'1 et C'2 sont ensuite transférées sur le site de consultation S0. L'union des tuples est effectuée puis la projection sur l'attribut prenom. Dans la stratégie 2, on commence par transférer tout sur le site de consultation où l'on effectue les opérations adéquates pour obtenir le résultat cherché.
Comparons les deux stratégies en supposant les données suivantes : le temps d'accès ta à un tuple nécessite 1 unité de temps, le temps de transfert d'un tuple entre deux sites nécessite 10 unités 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 possède en moyenne 5 cuisiniers. stratégie 1 temps de création de E'1 : 10ta temps de création 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 création de C'1 : 0 ou 50ta temps de création 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 création de R : 5ta
stratégie 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 création de E' : 20ta temps de création de R : 100ta + 5ta = 105ta En définitive, le temps de réponse est 125ta + 120tr soit 1325 unités.
En définitive le temps de réponse est 75ta + 6tr, soit 135 unités. Bien que notre calcul soit grossier et approximatif, il permet de faire une nette distinction entre les deux stratégies : la stratégie 1 est bien meilleure que la stratégie 2.
