EMI – Ginf – S5 (TI & IQL)

Bases   de  données  Distribuée

D.  Chiadmi
2017-­‐2018
 Objectifs
Ø Introduire1 des  concepts,  des  algorithmes  et  des  techniques  
dans  le  domaine  BD  distribuée  utiles  pour  le  développement  
d’applications  autour  de  BDD
Ø Focus  sur
§ Les  concepts  et  les  architectures  de  système  de  BDD
§ Les  composants  importants  de  système  de  BDD
§ Les  transactions  et  leurs  traitements

1:  sensibliliser  

2017-2018 D. Chiadmi 2
 Références
§ Principles  of  Distributed  Database  Systems,  M.  Tamer  

Ozsu  &  P.  Valduriez,  Prentice-­‐Hall,  3e  édition,  2011

§ Distributed  Databases:  Principles  &  Systems,  S.  Ceri  &  G.  

Pelagatti,  McGraw-­‐Hill

§ Concurrency  Control  and  Recovery  in  Database  Systems,  

P.A.  Bernstein  et  al.,  Addison  Wesley

2017-2018 D. Chiadmi 3
 Plan  et  calendrier

29-11-17 Introduction et architecture

Architecture (suite)
06-12-17 Conception
13-12-17 Transactions : ACID, transactions
20-12-17 distribuées, 2PC

27-12-17
28-12-17 24 élèves : 12 exposés de 20 min
03-01-18 (présentation + Q/R et discusion) par binôme

4
2017-2018 D. Chiadmi
 Travaux  à  fAttention
aire   :  auen   binôme
copier/coller : invalidation
• Référence  bibliographique  
– Articles  ou  brevets   fournis  (Date  >=    2016)  
– Entre  2  à  3  autres  références   bibliographiques  complémentaires      
• Production   :  Rapport  et  exposé
– Fond :
Ø Problème  traité  et  sa  motivation  //  Article  fourni
Ø Apport  des  articles   complémentaires  
Ø Votre  Analyse  et  votre  synthèse   .
– Forme :  
Ø Fiche  synthétique  d’une  demi  page  
Ø Rapport  de  4  pages,  Times  New  Roman  12  et  interligne  1,5

2017-2018 D. Chiadmi 5
 Travaux  à  faire   :  en  binôme
Exposés
– Durée  de  l’exposé  :  20  min  au  total
– 15  min  d’exposé Remettre
– 5  min  de  discussions - Articles complémentaires
- Slides
- CR pour chaque exposé

Barême  (sur  100)

– Qualité  des  articles/brevets   complémentaires   : 14  pts
– Rapport  :  30  pts
– Exposé  :  30  pts    +  réponses   :  15  pts
– CR  des  11  travaux  :  1  par  CR  (soit  11  pts)  

2017-2018 D. Chiadmi 6
-­‐
Articles  
Method  and  apparatus  for  
e t   B revets
A  Prototype  Evaluation   of  a   Tamper-­‐
ensuring  consistent  outcomes  in   resistant  High  Performance  Blockchain-­‐
updates  to  distributed  DB,   based   Transaction   Log   for  a   Distributed   DB,  
https://eprints.soton.ac.uk/411955/1/edcc_camera_ready.pdf
https://www.google.com/patents/US9672266
An  Extended  Technique   for  Data  
-­‐ Managing  a  distributed  DB,  
https://www.google.com/patents/US9703824 Partitioning   and   Distribution   in   Distributed  
-­‐ Integrating  map-­‐reduce   into  a   DB  Systems   ,    
https://www.jctecs.com/index.php/com/article/viewFile/152/75
distributed  relational  DB,   A  Novel   Query-­‐Driven  Clustering-­‐Based  
https://www.google.com/patents/US9514188
Technique  for  Vertical   Fragmentation   and  
-­‐ Workload  balancing  in  a   distributed  
Allocation  in Distributed  Database Systems,  
DB,  https://www.google.com/patents/US9542429 https://www.igi-­‐global.com/article/a-­‐novel-­‐query-­‐driven-­‐c lustering-­‐based-­‐
technique-­‐for-­‐vertical-­‐fragmentation-­‐and-­‐allocation-­‐in-­‐distributed-­‐database-­‐
-­‐ Resource   estimation   for  queries  in   systems/176732
large-­‐scale  distributed   database   Towards  a   Non-­‐2PC  Transaction  
system   ,  https://www.google.com/patents/US20170213257 Management  in   Distributed   DB   Systems  ,  
http://delivery.acm.org/10.1145/2890000/2882923/p1659-­‐
-­‐ System  and   method   for  distributed   lin.pdf?ip=105.131.218.188&id=2882923&acc=OA&key=4D4702B0C3E38B35
database  query  engines  ,   %2E4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E15F56E1470BE2D9E&CF
ID=832839084&CFTOKEN=18454538&__acm__=1511438715_abdefb240d66
https://www.google.com/patents/US20160188677 0a9550b965aedf91f024      

Choisir   2  articles  dans  

https://pdfs.semanticscholar.org/874c/4958275c645e1261f92e42c3fbefd777
ec7d.pdf#page=29
2017-2018 D. Chiadmi 7
 Plan  et  calendrier

29-11-17 Introduction et architecture

Architecture (suite)
06-12-17 Conception
13-12-17 Transactions : ACID, transactions
20-12-17 distribuées, 2PC

27-12-17
28-12-17 24 élèves : 12 exposés de 20 min
03-01-18 (présentation + Q/R et discusion) par binôme

8
2017-2018 D. Chiadmi
 Cours   portant  sur  BD  antérieurs

Qu’avez  vous  appris  ?

2017-2018 D. Chiadmi 9
 Se  mettre  en  phase   :  BD  
« classique »
Intégration n’est pas
Application forcément centralisation
1
SGBD

description
Application manipulation
2 BD
contrôle
Intégration ??

Application
3 Source : Principles of Distributed Database Systems, M.
Tamer Ozsu & P. Valduriez, Prentice-Hall, 3e édition, 2011

2017-2018 D. Chiadmi 10
 BD  :  Intégration  de  données

• Intégration de données : moins de duplications

• Partage de données entre applications
• Fiabilité
Sourcede
: BDdonnées : transactions,
de Witold Litwin tolérance aux pannes
http://ceria.dauphine.fr/cours98/BD-wl-98.html

• Sécurité de données
2016-2017 D. Chiadmi 11
• Langages de requêtes : SQL, QBE
BD  Distribuées  :

– motivation  ?
– Problèmes  ?
– Défis  ?

2017-2018 D. Chiadmi 12
Etude  de  cas   :  magasins  de  mode
• La  chaîne  de  magasin  de  mode  « X »  dispose  de  plusieurs  
points  de  vente  :
– Rabat  :  Agdal,  Mégamall,  Marjane  Riad,  etc.
– Casa  :  Maarif,  Twin  center,  etc.
– Etc.
• Un  client  se  présente  à  un  point  de  vente  (Agdal)  trouve  
un  joli  pantalon  mais  ne  trouve  pas  la  bonne  taille  alors  
que  cette  taille  est  disponible  dans  un  autre  point  de  
vente  (Maarif)

2017-2018 D. Chiadmi 13
 Solution  centralisée
Intégration et centralisation

Agdal

Mégamall

Réseau
…

Maarif Twin center

2017-2018 D. Chiadmi 14
 Solution  répartie
BDR : Fragments sur
un système réparti

Agdal

…
Mégamall

Réseau

Maarif Twin center

2017-2018 D. Chiadmi 15
 Intégration/répartition
Intégration ne signifie pas
forcément centralisation
Technologie Réseau
BD
intégration Répartition

BD
Réparties

Integration/répartition
Source : Principles of Distributed Database Systems, M.
Tamer Ozsu & P. Valduriez, Prentice-Hall, 3e édition, 2011
2017-2018 D. Chiadmi 16
Répartition  de   données   :  pourquoi  
?  

• Nature  répartie  des  données  à  gérer  (Agdal,  Mégamall,  

etc.)

• Amélioration  de  la  disponibilité  (Si  site  de  Agdal  en  panne,  
le  reste  du  système  continue  de  fonctionner)

• Amélioration  de  la  performance  (Accès  simultanées  à  des  

fragments  différents)
(Plus de détail un peu plus loin)

2017-2018 D. Chiadmi 17
 Répartition  :  Rappel   (ou   pas  ?)

Système  réparti  :  différentes  entités  (ordi,  smart  phones,  

etc.)  en  collaboration  pour  réaliser  une  tâche  commune

Caractéristiques  :  entités  

• interconnectés  par  un  réseau  de  communication

• communicant  par  voie  de  messages

• ne  partageant  ni  mémoire  ni  horloge  communes

2017-2018 D. Chiadmi 18
 BD  Distribuée  ?
Base  de  Données Distribuée
v déployée sur un  système réparti

v composée  de  “BDs”  logiquement liées et  distribuées sur pluieurs

noeuds (pas  forcément géographiquement très distants).

Système de  Gestion de  Base  de  Données Distribuée

v gère une BDD  

v fournit les  mécanismes d’accès qui  rendent la  répartition transparente

aux  utilisateurs

Un  système de  BDD  =  BDD  +  SGBDD

Même SGBDR  (homogène)  /  différents  SGBDR  (hétérogène)  
2017-2018 D. Chiadmi 19
2016-2017 D. Chiadmi 20
 Les  différents   cas   de  BD  

• Les  bases  de  données  réparties,  fédérées  et  parallèles  

sont  trois  domaines  distincts  mais  qui  ont  une  
problématique  commune,  la  distribution  des  données et  
des  traitements  sur  plusieurs  entités  qui  coopèrent pour  
gérer les  informations.  

2017-2018 D. Chiadmi 21
Pbs  Distribuée Vs  Centralisé  

Discussion  ?

2017-2018 D. Chiadmi 22
SGBDR  fournit  davantage  de  fonctionnalités
• Maintien  d’un  schéma  conceptuel  global  de  la  BDR
• Exécution  de  requêtes  (transactions)  sur  des  données   de  
plusieurs  sites
• Gestion  transparente  de  la  répartition,  de  la  fragmentation  et  
de  la  réplication
• Maintien  d’un  catalogue  
• Amélioration  de  la  disponibilité  et  la  fiabilité
• Amélioration  de  la  performance
• Facilité  d’extension
• Recouvrement  en  cas  de  pannes suite
• Si  réplication  :  choix  de  la  copie,  maintien  de  la  consistence
2017-2018 D. Chiadmi 23
BDR Transpatrence à la répartition, la réplication et à la
fragmenation
répliqué
Interface
utilisateur
SGBD
Software
interface
Application
SGBD
Software

SGBD Réseau
Software

interface
Non SGBD Interface Application
répliqué Software utilisateur SGBD
Software

Interface
utilisateur
2017-2018 Source : Principles of Distributed Database Systems,24
D. Chiadmi M.
Tamer Ozsu & P. Valduriez, Prentice-Hall, 3e édition, 2011
 Transparence  
La  transparence   est  un    compromis   entre  (1)  simplicité  d’utilisation,   (2)  
difficulté  et  (3)  coût  induit
Retour

2017-2018 D. Chiadmi 25
 Amélioration   de  la  fiabilité
• Un  SBDD  peut  recourir  à  la  réplication  pour  éviter  qu’une  
donnée  devienne   inaccessible  en  cas  de  panne
• Les  utilisateurs  peuvent   continuer  à  utiliser  une  partie  des  
données  ʺ″avec  précautionʺ″  même  si  une  partie  des  
données  est  inaccessible
• Les  transactions  réparties  permettent   la  maintenance  de  
la  consitence  de  la  BD  même  en  cas  de  panne    retour

2017-2018 D. Chiadmi 26
 Amélioration   de  la    Performance
• le  taux  d’utilisation  du  CPU  et  des  ressources  d’E/S  est  
moins  critique  vu  que  chaque  site  ne  gère  qu’une   partie  
des  données  (vers  un  équilibrage  de  charge)
• l’utilisation  de  données  en  local  réduit  la  surcharge  due  à  
la  communication.
• Le  parallélisme  des  SR  peut  être  exploité  
– Parallélisme  inter-­‐requête
– Parallélisme  intra-­‐requête
• ..  retour

2017-2018 D. Chiadmi 27
 Quelques   difficultés
• Système  plus  complexe  à  gérer  

• Coût  :  Plus  de  hardware,  plus  de  software  

• Contrôle  réparti  :  problèmes  de  synchronisation  et  de  

coordination  pour  maintainir  la  consitence  des  données

• Sécurité  :  sécurité  de  la  BD  +  sécurité  du  réseau

2017-2018 D. Chiadmi 28
 Les  orientations  :  composants
• Conception  des  BDR  (fragmentation,  placement,  etc.)
• Traitement   des  requêtes    réparties  (réécriture,  validation,  etc.)
• Contrôle  de  la  concurrence  (synchronisation)
• Fiabilité
• Gestion  du  catalogue  (informations  sur  les  données,  etc.)
• Gestion  répartie  des  interblocages
• BD  hétérogènes Gestion du catalogue

Traitement des requêtes Conception BDR Fiabilité

Contrôle de concurrence
Source : H.Lu/HKUST

29
2017-2018 Gestion de l’interblocage
Partie  2   :  Architectures

2017-2018 D. Chiadmi 30
 Solution  centralisée
Agdal Maarif Méga Mall
…
ES ES ES

Architecture
Schéma conceptuel
ANSI-SPARC
Schéma interne

2017-2018 D. Chiadmi 31
Architecture  générique  d’un  SGBD  centralisé

2016-2017 D. Chiadmi 32
Example Source : Principles of Distributed Database Systems, M.
Tamer Ozsu & P. Valduriez, Prentice-Hall, 3e édition, 2011

EMP ASG

ENO ENAME TITLE ENO PNO RESP DUR

E1 J. Doe Elect. Eng. E1 P1 Manager 12
E2 M. Smith Syst. Anal. E2 P1 Analyst 24
E3 A. Lee Mech. Eng. E2 P2 Analyst 6
E4 J. Miller Programmer E3 P3 Consultant 10
E5 B. Casey Syst. Anal. E3 P4 Engineer 48
E6 L. Chu Elect. Eng. E4 P2 Programmer 18
E7 R. Davis Mech. Eng. E5 P2 Manager 24
Société d’ingénierie
E8
dispose d’agences
J. Jones Syst. Anal.
àE6Boston,
P4 Waterloo,
Manager Paris
48et San
E7 P3 Engineer 36
Francisco. Des projets sont menés dans E7
chaque
P5 site. Des données
Engineer 23 sur les
E8 P3 Manager 40
employés, PROJ
les projets et d’autres données liées sont
PAYintégrées dans une BD
PNO PNAME BUDGET TITLE SAL
P1 Instrumentation 150000 Elect. Eng. 40000
P2 Database Develop. 135000 Syst. Anal. 34000
P3 CAD/CAM 250000 Mech. Eng. 27000
P4 Maintenance 310000 Programmer 24000

2017-2018 D. Chiadmi 33
 Schèma   Conceptuel  (1)
ENO ENAME TITLE TITLE SAL

RELATION  EMP  [ RELATION  PAY  [

KEY  =  {ENO} KEY  =  {TITLE}
ATTIBUTES   =  { ATTIRBUTES   =  {
ENO  :  CHAR(9) TITLE  :  CHAR  (10)
ENAME  :  CHAR(15) SAL: NUMERIC(6)
TITLE  :  CHAR(10) } }
] ]

2017-2018 D. Chiadmi 34
 Schèma   Conceptuel  (2)
PNO PNAME BUDGET ENO PNO RESP DUR

RELATION  PROJ  [ RELATION  ASG  [

KEY  =  {PNO} KEY  =  {ENO,  PNO}
ATTIBUTES   =  { ATTIRBUTES   =  {
PNO  :  CHAR(7) ENO  :  CHAR(9)
PNAME  :  CHAR(20) PNO  :  CHAR(7)
BUDGET  :  NUMERIC(7) RESP  :  CHAR  (10)
} DUR: NUMERIC(3)
] }
]

2017-2018 D. Chiadmi 35
 Schèma Interne

RELATION  EMP  [ INTERNA_REL  E  [

KEY  =  {ENO} INDEX  ON  E#  
ATTIBUTES   =  { FIELD  =  {
ENO  :  CHAR(9) E#  :  BYTE(9)
ENAME  :  CHAR(15) ENAME:  BYTE(15)
TITLE  :  CHAR(10) TIT:  BYTE(10)
} }
] ]

2017-2018 D. Chiadmi 36
 Vues   externes
RELATION PROJ [
KEY = {PNO}
ATTIBUTES = {
PNO : CHAR(7)
PNAME : CHAR(20)
BUDGET : NUMERIC(7)
} ]

Create  a  BUDGET view  from  PROJ :

CREATE  VIEW  BUDGET (PNAME,  BUD)  

AS SELECT   PNAME,  BUDGET
FROM PROJ

2017-2018 D. Chiadmi 37
 Vues externes
RELATION EMP [
RELATION PAY [
KEY = {ENO}
KEY = {TITLE}
ATTIBUTES = {
ATTIRBUTES = {
ENO : CHAR(9)
TITLE : CHAR (10)
ENAME : CHAR(15)
SAL : NUMERIC(6) } ]
TITLE : CHAR(10) } ]

Create  a  PAYROLL view  from  EMP and  PAY :

CREATE  VIEW  PAYROLL (  EMP_NO,  EMP_NAME,   SAL)

AS  SELECT    EMP.ENO,  EMP.ENAME,   PAY.SAL
FROM EMP,  PAY
WHERE    EMP.TITLE =  PAY.TITLE

2017-2018 D. Chiadmi 38
Comment  répartir  cette  BD  ?

2017-2018 D. Chiadmi 39
Modèles   architecturaux   d’un  
SGBDR
Classification à 3 dimensions :
• Autonomie
• Répartition
• Hétérogénéité

2017-2018 D. Chiadmi 40
 Autonomie
Fait  référence à la  distribution  du  contrôle et  signifie que :
1.Les  opérations locales  du  SGBD  ne  sont pas  affectées par  sa
participation  au  système distribué
2.La  manière avec  laquelle le  SGBD  traite et  optimise les  requêtes
n’affecte pas  l’exécution globale d’une requête qui  utiliserait des  
données de  SGBDs  différents
3.La  cohérence n’est pas  altérée par  l’arrivée ou le  départ d’un  
SGBD

2017-2018 D. Chiadmi 41
 Autonomie   :  sous   dimensions  ?
1. Conception :  SGBD libre  d’utiliser  le  modèle  de  données  et  la  
gestion  de  transaction  préférés.
2. Communication :  chaque  SGBD est  libre  de  ses  décisions,  de  
la  nature  des  informations  à  fournir  aux  autres  SGBD  et  du  
protocole  de  contrôle  de  l’exécution  globale.
3. Exécution :  chaque  SGBD est  libre  de  choisir  la  manière  
d’exécuter   les  transactions  reçues

2017-2018 D. Chiadmi 42
Ces 3 alternatives ne sont pas les seules possibilités.
Classification  :  3  alternatives*  
Il s’agit des 3 les plus populaires
Intégration  forte  =  SGBDs  partagent  les  données  &  présentent  une  
vue  unique  à  tous  les  utilisateurs  :                //absence  d’indépendance
–Vue  :  données  logiquement  intégrées  dans  une  seule  BD.
–Contrôle  :  un  seul  gestionnaire  chargé  du  contrôle  du  traitement  
de  chaque  requête  même  si  elle  est  répartie.
Semi-­‐autonome   =  SGBDs  partagent  des  données  et  fonctionnent  
de  manière  indépendante. //  indépendance   partielle
Isolation  totale =  SGBD  individuel  ignore  l’existence  d’autres  SGBD  
et  la  manière  de  communiquer  avec  eux.  Aucun  contrôle  global  de  
traitement   rendant  l’exécution  des  transactions  difficile.
//  indépendance   Totale
*  Il  en  existe  d’autres 2017-2018 D. Chiadmi 43
 Distribution

Fait référence à la  distribution  physique  des  

données.  

Nous  en  illustrons le  C/S  et  le  P2P

2017-2018 D. Chiadmi 44
 Distribution en  C/S
• Gestion  de  données   assurée  par  le  Serveur
• Exploitation    (interface  utilisateur)  gérée  par  le  Client
• Communication  traitée  par  le  Client  Serveur

1 à plusieurs serveurs BD ; le client “voit” une seule BD

2016-2017 D. Chiadmi 45
 Distribution en  C/S
Avantages  dans  la  gestion  des  données  
•des  techniques  spécifiques  pour  améliorer  la  fiabilité  et  la  
disponibilité  peuvent   être  introduites
•la  performance  peut  être  améliorée  par  
– intégration   fortement   couplée
– implémentation  du  serveur  sur  une  machine  
multiprocesseurs  ou  un  clusters  de  PC  (la  disponibilité  
est  ainsi  améliorée)
Inconvénient :  classique  du  C/S

2017-2018 D. Chiadmi 46
 Distribution en   P2P
Chaque  pair  dispose  d’un  SGBD  complet  et  communique  avec  les  
autres  machines  pour  l’excécution  des  requêtes  ou  transactions.  

2017-2018 D. Chiadmi 47
 Hétérogénéité  
– Modèles de données : Recours possible à différents
outils de modélisation en raison de l’expressivité ou la
limitation d’un modèle par rapport à un autre

– Langages de requêtes : différents paradigmes d’accès

aux données liés aux modèles de données (relationnel,
Objet, etc.), même si SQL est un standard, différentes
implémentations (Vendor) existent

– Protocoles de gestion des transactions

2017-2018 D. Chiadmi 48
 Vers  l’architecture   Distribuée
Dans  tous  les  cas,  il  est  nécessaire  d’avoir  
-­‐vue  locale  des  données  d’un  site  définie  par  un  schéma  interne
:  schéma  local  interne  (LIS)
-­‐vue  globale  des  données   décrivant  la  structure  logique des  
données  de  tous  les  sites  :  schéma  conceptuel  global  (GCS)
•organisation  logique  locale  des  données  pour  passer  à  la  
répartition  (fragmentation,  placement  et  réplication)  :  schéma  
conceptuel  local  (LCS)
Ex  :  GCS  =  union  des  LCS
•Schéma  externe  (ES)  pour  chaque  application
ou  utilisateur  finaux  défini  sur  le  GCS.

2017-2018 D. Chiadmi 49
 Architecture  classique  SGBDR
Schéma global :
Schémas
ensemble de relations Schéma global GCS indépendants de
globales sans allusion à la localisation
la répartition. Schéma de fragmentation

Schéma d’allocation

Schéma local (LCS) Schéma local (LCS) ……

SGBD 1 SGBD2

Schéma local interne (LIS)

Site 1 DB 1 DB 2
Locale
Site 2 Locale
2017-2018 D. Chiadmi 50
 Architecture  classique  SGBDR
Relation globale “divisée”
en fragments (logiques)
Schéma global Schémas
disjoints avec un mapping indépendants de
(1: n) de la relation Schéma de fragmentation la localisation
globale R vers les
fragments Ri Schéma d’allocation

Schéma local Schéma local ……

DBMS 1 DBMS 2

Site 1 DB 1 DB 2
Locale
Site 2 Locale
2017-2018 D. Chiadmi 51
 Architecture  classique  SGBDR
mapping fragment-site 1:1 ou
1:n (en cas de réplication).
Schéma global Schémas
Les fragments décrits par la indépendants de
même relation Ri et la localisation
Schéma de fragmentation
alloués à différents sites j
sont des copies du même
Schéma d’allocation
fragment (noté Rji)

Schéma local Schéma local ……

DBMS 1 DBMS 2

Site 1 DB 1 DB 2
Locale Locale
2017-2018 D. Chiadmi 52
 Architecture  classique  SGBDR
Schéma global Schémas
indépendants de
la localisation
Mapping interne Schéma de fragmentation
manipulé par le
SGBD Schéma d’allocation

Schéma local Schéma local ……

SGBD 1 SGBD 2

Site 1 DB 1 DB 2
Locale
Site 2 Locale
2017-2018 D. Chiadmi 53
Récapitulatif  :  SchémaSchema  global  :  relations  
globales  sans  allusion  à  la  
répartition.
R
R1 R11 Schema  de  fragmentation  :  
R1 relation  globale  “divisée”  en  
fragments  (logiques)  disjoints  
R12 (Site 1) avec  un  mapping  (1:n)  de  la  
R2 relation  globale  R  vers  les  
R21
fragments  Ri
R2 Schema  d’allocation  :  mapping  
(Site2) fragment-­‐site  1:1  ou  1:n  (en  
R3 R22
cas  de  réplication).  Les  
fragments  “décrits”  par  la  
R23
même  relation  Ri  -­‐alloués  à  
Relation R3
Fragments (Site3)
plusieurs  sites  j-­‐ sont  
Globale considérés  comme  des  copies  
R33
du  même  fragment  (noté  Rji)
Images Physiques
Schema  local  (mapping)  :  
mapping  interne  manipulé  
par  le  SGBD.
2017-2018 D. Chiadmi 54
 Motivation
• Séparer  les  2  concepts  de  fragmentation  et  d’allocation
• Transparence   à  la  fragmentation
• Transparence   à  la  localisation
• Indépendance   des  “bout”  de  BD  locales  permettant  un  
maping  transparent

2017-2018 D. Chiadmi 55
 Fonctionnement

Zoom1

2017-2018 D. Chiadmi 56
 Processeur  utilisateur  
interface :  interprète  les  commandes  et  
met  en  forme  les  résultats  
Contrôle  sémantique  :  vérifie  les  
contraintes  d’intégrité  et  les  
permissions  définie  par  le  GCS
Optimisation :    réecrit  la  requête  globale  
en  sous  requêtes  locales  (utilisant  GCS,  
LCS  et  catalogue)  et  détermine   la  
“meilleure”    stratégie  d’exécution   en  
fonction  du  coût
Exécution :  coordonne  l’exécution  répartie,    
transmet  les  sous  requêtes  au  PDD,  et  
récupére  les  résultats  qu’il  soumet  à  
l’interface
2017-2018 D. Chiadmi 57
Processeur  de  
données
Processeur  local  de  la  requête  :  
sélectionne  le  chemin  d’accès  aux  
données  de  la  requête  locale
Recouvrement  local  :  garantit  la  
consistence  locale  de  la  BD  même  en  
cas  de  panne
Run-­‐time  :  assure  l’accès  physique  à  la  
BD  locale    en  fonction  du  plan  généré  
par  l’optimiseur.  Il  assure  l’interface  
avec  l’OS  qui  “supporte”   la  BD,  le  
cache,  etc.
2017-2018 D. Chiadmi 58
Autres  solutions  et  pistes  …

2017-2018 D. Chiadmi 59
 Architecture  Multi   base   de  Données
Requête globale

Requête
Requête Multi-SGBD Layer locale
locale
Sous requête Sous requête Sous requête
globale globale globale

SGBD1 SGBD2 SGBD3

60
2017-2018 D. Chiadmi
Architecture
Médiateur /
adaptateur

2017-2018 D. Chiadmi 61
Partie  3   :  Conception

2017-2018 D. Chiadmi 62
 Partage    :  3  dimensions
1.niveau  de  partage  (sharing  level)
2.mode  d’accès  (behaviour  of  access  pattern)
3.niveau  de  connaissance  sur  le  mode  d’accès  (level  of  
knowledge  about  the  behaviour  of  access  pattern

2017-2018 D. Chiadmi 63
 Niveau  de  partage   :  3  possibilités
1-­‐ no  sharing  :  application  et  données  sur  le  même  site.  Aucune  
communication  avec  d’autres  programmes  et  aucun  accès  à  
d’autres  données  
2-­‐ data  sharing*  :  programmes  répliqués  sur  tous  les  sites  mais  
pas  les  données.   En  fonction  de  la  requête,   les  fichiers  de  
données  requis  sont  transférées  sur  le  site  d’où  émane  la  
requête.
3-­‐ data  +  program  sharing*   :  données  et  pgs  partagés.  Ainsi,  un  
pg,  sur  un  1e site,  peut  invoquer  un  service  sur  un  2e site  qui  
peut  accéder  à  un  fichier  de  données  hébergé  sur  un  3e site.
*   Dans  un   environement   hétérogène,  il   est  difficile  voire  impossible  
d’excéuter  le   même   pg  sur   des   machines  ≠  
2017-2018 D. Chiadmi sous   des   OS  ≠.   Le   transfert  64

de   données  est   alors   une   solution   relativement   facile  

 Accès   :  2  modes
• Accès  statique              :  facile  à  gérer  mais  rares
• Accès  dynamique    :  quel  niveau  de  dynamicité  ?

2017-2018 D. Chiadmi 65
 Niveau  de  connaissance  
Le  concepteur
1-­‐ n’a  aucune   information  :  possibilité  théorique   mais  cas  
difficile  voire  impossible  à  traiter
2-­‐ a  toute  l’  information   :  prédiction  des  accès  possible  avec  
une  bonne  précision
3-­‐ a  une  information  partielle  :  prédiction  des  accès  
possible  mais  avec  une  déviation  probabale

66
2017-2018 D. Chiadmi
 Conception  de   BDR

En  comparaison  avec  le  cas  centralisé,  chacun  des  cas  cité,  sauf  
le  “no-­‐sharing”,  soulève  de  nouveaux  pbs

2017-2018 D. Chiadmi 67
 Deux   Approches  de  conception
BD • Descendant  (Top-­‐Down)
– Utilisée  si  conception  from  scratch
BD1 BD2 … BDn
– Utilisé  pour  des  données  
homogènes
– Applications  réelles  ne  sont  pas  tjs  
BD
aussi  simples  !!

BD1 BD2 … BDn

• Ascendant  (Bottom-­‐up)
– Utilisée  dans  le  cas  des  BD  
légataires (intégration  physique  ou  
virtuelle)
2017-2018 D. Chiadmi 68
Approches de  conception  descendante

2017-2018 D. Chiadmi 69
Identifier les besoins liés aux
données et aux traitements
des utilisateurs potentiels de
la BD afin de définir les
objectifs en termes de
performance, de fiabilité, de
disponibilité et de flexiblité

2016-2017 D. Chiadmi 70
 Définir les interfaces
utilisateurs
Définir le GCS en
déterminant les entités, leurs
attributs, les relations entre
eux

2016-2017 D. Chiadmi 71
“GCS” + “Access pattern
information” + “External
Scheme definitins” sont les
entrées de l’étape “conception
de la répartition”.
En sortie, on obtient les LCS
qui décrivent la répartition des
relations sur les sites (sous
relations, appelées fragments)
La conception de la répartition
se fait en 2 étapes séparées
(fragmentation et allocation)
pour mieux traiter à la
complexité du problème
2016-2017 D. Chiadmi 72
La conception au niveau
physique concerne
l’implémentation de chaque
LCS au niveau d’un élément de
stockage d’un site.
En entrée, on a les LCS + access
pattern information
2016-2017 D. Chiadmi 73
 Fragmentation
Plusieurs  questions
1.Pourquoi  fragmenter  ?
2.Comment  doit-­‐on  fragmenter  ?
3.Combien  de  fragments  doit  on  avoir  ?
4.Comment  tester  la  validité  d’une  décomposition  ?
5.Comment  doit-­‐on  procéder  à  leur  placement  ?
6.Quelles  sont  les  informations  nécessaires  pour  la  
fragmentation  et  le  placement  ?

2017-2018 D. Chiadmi 74
 Fragmentation
• Une  requête  interroge  le  plus  souvent  une  partie  d’une  
relation  et  non  une  relation  entière
• Une  requête  interrogeant  une  (partie  de)  relation  peut  
être  placée  sur  2  sites  :  S1  – placement  sur  un  site  
engendrant   des  accès  distants  ou  S2  – réplication  sur  les  2  
sites  engendrant   la  gestion  des  mises  à  jour
• La  décomposition  d’une   relation  en  fragments  permet  
l’exécution  concurrene  de  transactions
• La  fragmentation  de  relations  permet  aussi  l’exécution  
parallèle  d’une  requête  en  la  divisant  en  sous  requête  
traités  dans  différents  fragments.

2017-2018 D. Chiadmi 75
 Fragmentation:  difficultés    
• le  besoin  d’une  requête  peut  empêcher  la  décomposition  
d’une  relation  en  fragments  séparés  (conflit)

• Une  requête  qui  nécessite  d’interroger  plus  d’un  fragment  

peut  subir  une  dégradation  de  performance  :  une  jointure  
de  données  en  provenance  de  sites  différents  pourrait  
être  nécessaire  (couteuse)  

Réduire  le  nb  de  jointure  répartie  est  un  pb  de  la  
fragmentation

2017-2018 D. Chiadmi 76
 Fragmentation:  difficultés    
• La  vérification  de  l’intégrité  traitée  par  le  module  de  
contrôle  sémantique  peut  être  difficile  dans  le  cas  où  des  
attributs  dépendants   se  retrouvent  dans  différents  
fragments  placés  dans  des  sites  différents.  Dans  ce  cas,  le  
test  d’intégrité  devrait  “suivre” les  données  dépendantes  
sur  plusieurs  sites.

2017-2018 D. Chiadmi 77
 Conception  descendante  :  
Fragmentation
Construction  du  schéma  de  fragmentation :  découper  le  SCG  en  
plusieurs  SCL  avec  un  mapping entre  les  deux.
J Accès  réduits  à  des  données  non  pertinentes
J Utilisation  de  plusieurs  sites  favorise  l’équilibrage  de  charge
J Concurrence  intra-­‐requête   facilitée  
L Difficulté  d’avoir  des  fragments  disjoints
L Accès  à  plusieurs  fragments  nécessitent  des  jointures  ou  
des  unions
L Coût  induit  par  le  contrôle  de  la  sémantique   des  données  
(integrité)

2017-2018 D. Chiadmi 78
techniques  de  fragmentation

• Fragmentation   par  table

– Par  relation  (classe)
• Fragmentation   verticale
– Par  colonne  (attributs)
• Fragmentation   horizontale
– Par  ligne  (tuples,  occurrence)
• Fragmentation   mixte
– Combinaison  des  2  précédentes

2017-2018 D. Chiadmi 79
 Granularité   de  la  Fragmentation
• Elevée  :  

– Permet  une  gestion  simple  de  la  fragmentation

– possibilités  très  restreintes  pour  la  fragmentation.  

– répartir  les  relations  complètes  imposerait  soit  

beaucoup  de  trafic,  soit  une  réplication  des  données  
avec  tous  les  pbs  induits

2017-2018 D. Chiadmi 80
 Granularité   de  la  Fragmentation
• Faible  :  
– plusieurs  possibilités  pour  la  fragmentation
– répartition  flexible  et  efficace  de  la  BD.
– faire  tourner  plus  de  processus  simultanément,   d’où  
une  meilleure  utilisation  des  possibilités  du  réseau  
d'ordinateurs
– lourdeur  pour  la  recomposition  des  informations.

2017-2018 D. Chiadmi 81
 Granularité   de  la  Fragmentation

• Compromis  :
– Elevée  :  probabilité  d’accès  à  des  données  non  
pertinentes   élevée
– Fine  :  Coût  de  traitement   élevé  
– Besoin  de  trouver  un  degré  convenable  de  
fragmentation

2017-2018 D. Chiadmi 82
 Trois règles  
1-­‐ complétude :  pour  toute  donnée  de  la  relation  globale,  ∃ au  
moins  un  fragment  Ri  de  la  relation  R  qui  possède  cette  
donnée.  

2-­‐ recomposition :  pour  toute  relation  R  décomposée   en  

fragments  Ri,  ∃ 1  opération  de  recomposition  tq  
R  =  op  Ri,    ∀ Ri  ∈ {fragments}

3-­‐ fragments  disjoints :  il  est  recommandé  de  chercher  à  obtenir  

des  fragments  disjoints.  Le  cas  de  la  réplication  est  alors  traité  
au  niveau  du  placement.

2017-2018 D. Chiadmi 83
 Schéma  de  Fragmentation  

• Schéma  de  fragmentation  contient  les  fragments et  les  

correspondances  bidirectionnelles avec  le  schéma  global

• Nous  avons  alors  

– La  définition  formelle  des  fragments exprimée  en  terme  
d'opérateurs  du  LMD  appliqués  sur  le  schéma  global;  
– La  définition  formelle  de  la  recomposition  du  schéma  global  
exprimée  à  l'aide  du  même  ensemble  d'opérateurs  (ex:    SQL  
pour  une  BD  relationnelle)..

2017-2018 D. Chiadmi 84
Exemple Source : Principles of Distributed Database Systems, M.
Tamer Ozsu & P. Valduriez, Prentice-Hall, 3e édition, 2011

EMP ASG
ENO ENAME TITLE ENO PNO RESP DUR
E1 J. Doe Elect. Eng. E1 P1 Manager 12
E2 M. Smith Syst. Anal. E2 P1 Analyst 24
E3 A. Lee Mech. Eng. E2 P2 Analyst 6
E4 J. Miller Programmer E3 P3 Consultant 10
E5 B. Casey Syst. Anal. E3 P4 Engineer 48
E6 L. Chu Elect. Eng. E4 P2 Programmer 18
E7 R. Davis Mech. Eng. E5 P2 Manager 24
E8 J. Jones Syst. Anal. E6 P4 Manager 48
E7 P3 Engineer 36
E7 P5 Engineer 23
E8 P3 Manager 40

PROJ PAY
PNO PNAME BUDGET TITLE SAL
P1 Instrumentation 150000 Elect. Eng. 40000
P2 Database Develop. 135000 Syst. Anal. 34000
P3 CAD/CAM 250000 Mech. Eng. 27000
P4 Maintenance 310000 Programmer 24000

2017-2018 D. Chiadmi 85
 Relations  ou  Classes
Relations  (entières)  réparties  dans  différents  fragments  et  réparties  
sur  les  sites

• les  occurrences  d'une  même  classe  appartiennent   au  même  

fragment  
– fragmentation  :  définition  de  sous-­‐schémas.
– recomposition  :  réunion  des  sous-­‐schémas.
• Exemple  :  La  BD  peut  être  fragmentée  en  

{PROJ,  ASG} et {EMP,  PAY}

site  1               site  2

2017-2018 D. Chiadmi 86
 Exemple Source : Principles of Distributed Database Systems, M.
Tamer Ozsu & P. Valduriez, Prentice-Hall, 3e édition, 2011

EMP ASG
ENO ENAME TITLE ENO PNO RESP DUR
E1 J. Doe Elect. Eng.
Site 1 E2 M. Smith Syst. Anal.
E1 P1 Manager 12
E2 P1 Analyst 24
E3 A. Lee Mech. Eng. E2 P2 Analyst 6
E4 J. Miller Programmer E3 P3 Consultant 10
E5 B. Casey Syst. Anal. E3 P4 Engineer 48
E6 L. Chu Elect. Eng. E4 P2 Programmer 18
E7 R. Davis Mech. Eng. E5 P2 Manager 24
E8 J. Jones Syst. Anal. E6 P4 Manager 48
E7 P3 Engineer 36
E7 P5 Engineer 23
E8 P3 Manager 40

PROJ PAY
PNO PNAME BUDGET TITLE SAL
P1 Instrumentation 150000 Elect. Eng. 40000
P2 Database Develop. 135000 Syst. Anal. 34000
Site 2 P3 CAD/CAM 250000 Mech. Eng. 27000
P4 Maintenance 310000 Programmer 24000

2017-2018 D. Chiadmi 87
 Fragmentation  horizontale   =>

• Fragmentation   horizontale  :  Occurrences  d'une  classe  réparties  

dans  des  fragments  différents  (avec  leur  valeur  complète).
• Relations  divisées  en  sous-­‐relations,  chacune  contenant  des  n-­‐
uplets  d’1  relation  d’origine  (un  n-­‐uplet  doit  être  pris  dans  un  
même  fragment),

• =>  L'opérateur  de  Fragmentation   est  la  sélection,

PROJ1  =  σ  (BUDGET  <=  200000)  PROJ
PROJ2  =  σ  (BUDGET  >      200000)  PROJ

=>  L'opérateur  de  Recomposition  est  l’union,

PROJ  =  PROJ1  U  PROJ2,
=>

2017-2018 D. Chiadmi 88
 Répartition  des  occurrences
Relation PROJ

PNO         PNAME BUDGET

P1 Instrumentation 150000
P2 Database  develop 135000 Site 1

P3 CAD/CAM 250000
P4   Maintenance 310000 Site 2

retour
2017-2018 D. Chiadmi 89
 Discussion
• Que  se  passe  t-­‐il  si  les  prédicats  ne  sont  pas  exclusives  :
PROJ1  =  σ  (BUDGET   <=  150000)  PROJ
PROJ2  =  σ  (BUDGET   >      200000)  PROJ
Ou
PROJ1  =  σ  (BUDGET   <=  250000)  PROJ
PROJ2  =  σ  (BUDGET   >      200000)  PROJ
• Que  se  passe  t-­‐il  si  les  valeurs  sont  continues  et/ou  infinies  ?
• Que  se  passe  t-­‐il  si  un  nouveau  projet  est  ajouté  avec  un  
budget  de  60000  ?
• Autres  ??

2017-2018 D. Chiadmi 90
Fragmentation  horizontale  dérivée
• Exemple
EMP1  =  EMP PAY1
EMP2  =  EMP              PwAY2
v

où wv

PAY1  =  σ  (SAL    30000)  PAY

PAY2  =  σ  (SAL  >  30000)  PAY

Fragments  ?

2017-2018 D. Chiadmi 91
Fragmentation  horizontale  dérivée
EMP1 = EMP wv PAY1
EMP PAY EMP2 = EMP wv PAY2
ENO ENAME TITLE TITLE SAL où
E1 J. Doe Elect. Eng. Elect. Eng. 40000 PAY1 = σ (SAL 30000) PAY
E2
E3
M. Smith
A. Lee
Syst. Anal.
Mech. Eng.
Syst. Anal. 34000 PAY2 = σ (SAL > 30000) PAY
Mech. Eng. 27000
E4 J. Miller Programmer Programmer 24000
E5 B. Casey Syst. Anal.
E6 L. Chu Elect. Eng.
E7 R. Davis Mech. Eng.
E8 J. Jones Syst. Anal.

2017-2018 D. Chiadmi 92
 Critères  ?
- Fragmentation avec les meilleures caractéristiques de
jointure
- Fragmentation utilisée dans le plus grand nb
d’applications

- Traiter livre page 94 à 98

2017-2018 D. Chiadmi 93
 Fragmentation   verticale   =>

Fragmentation   “optimale” produit  un  schéma  qui  minimise  le  tps  

d’exécution   des  requêtes  qui  s’excéute   sur  ces  fragments.

– attributs  d'une  classe  sont  réparties  dans  plusieurs  fragments,

– correcte  si  l'identifiant  est  dupliqué  dans  chaque  fragment  :  
condition  de  recomposition  sans  perte  d’information
– utile  pour  distribuer  les  parties  des  données  sur  le  site  où  
elles  sont  utilisées.  (Ex  :  les  guichets  des  banques  n’utilisent  
que  les  soldes des  comptes,  les  services  de  contentieux  ont  
besoin  des  informations  complètes)

2017-2018 D. Chiadmi 94
 Attributs =>

L'opérateur  de  Fragmentation  est  projection,

PROJ1  =  π  (PNo,  PNAME)  PROJ
PROJ2  =  π  (PNo,  BUDGET)  PROJ

• L'opérateur de recomposition est la jointure,

PROJ= PROJ1 PROJ2
wv

=>

2017-2018 D. Chiadmi 95
Répartition  des   attributs
Relation PROJ

Site 1 Site 2

PROJ

PNO PNAME BUDGET

P1 Instrumentation 150000
P2 Database Develop. 135000
P3 CAD/CAM 250000
P4 Maintenance 310000

PROJ1 = π (PNo, PNAME) PROJ

PROJ2 = π (PNo, BUDGET) PROJ retour
96
2017-2018 D. Chiadmi
 Démarche  ?
Par  groupement  :  affecter  chaque  attribut  à  un  fragement,  et  
à  chaque  étape,  faire  une  jointure  de  quelques  fragments  en  
fonction  d’un    critère  donné  (convient  mieux  à  la  conception  
descendante).

Par  éclatement  :  Prendre  la  relation  complète  et  décider  

selon  un  critère  (besoin)  l’éclatement   possible  en  fonction  
des  besoins  des  requêtes  en  terme  d’attributs.

2017-2018 D. Chiadmi 97
• q1:  Find  the  budget  of  a  project,  given  its  identification  
number.
Soit A1 = PNO, A2 = PNAME,
SELECT  BUDGET
A3 = BUDGET, A4 = LOC
FROM  PROJ
WHERE  PNO=Value
• q2:  Find  the  names  and  budgets  of  all  projects.
SELECT  PNAME,  BUDGET
FROM  PROJ
• q3:  Find  the  names  of  projects  located  at  a  given  city.
SELECT  PNAME
FROM  PROJ
WHERE  LOC=Value
• q4:  Find  the  total  project  budgets  for  each  city. Que faire ?
SELECT  SUM(BUDGET)
FROM  PROJ
WHERE  LOC=Value Livre pages 100 à 102

2017-2018 D. Chiadmi 98
 Valeurs =>

Combinaison  des  fragmentations  horizontale  et  verticale  

d’une  relation  ou  d’un  fragment  obtenu  
antérieurement.  

Les  occurrences  et  les  attributs  peuvent  être  répartis  

dans  des  partitions  différentes.

• L'opération  de  fragmentation  est  une  combinaison  de  

projections  et  de  sélections.

•  L'opération  de  recomposition  est  une  combinaison  de  

jointures  et  d'unions.
=>
2017-2018 D. Chiadmi 99
 Répartition  des   valeurs
PROJ11 = π (PNo, PNAME) PROJ Site 1
PROJ21 = π (PNo, BUDGET) σ(BUDGET > 150 000) PROJ Site 21
PROJ22 = π (PNo, BUDGET) σ(BUDGET <= 150 000) PROJ Site 22
PNO PNAME BUDGET

P1 Instrumentation 150 000

P2
P2 Database develop 135 000

P3 CAD/CAM
P3 250 000
P4 Maintenance 310 000

PROJ = (PROJ21 U PROJ22) Client2

2016-2017 D. Chiadmi 100
 Allocation

L’allocation  des  fragments  est  traitée  selon  

l'origine  prévue  des  requêtes  qui  ont  servi  
à  la  fragmentation.  
Sur quels
sites ?
ou
But :  Placer  les  fragments  de  manière  
?
optimale

2017-2018 D. Chiadmi 101

 Allocation :  réplication  ?
• Réplication  totale  :  chaque  fragement  est  copié  
dans  tous  les  sites
• Réplication  Partielle  :  chaque  fragment  est  copié  
dans  quelques  sites
• Aucune  réplication  (Partition)  :  chaque  fragment  
est  stocké  dans  un  site  unique
• Si  req  lecture/req  maj  <<  1,  la  réplication  est  
avantageuse,  elle  ne  l’est  pas  sinon
2017-2018 D. Chiadmi 102
 Problème   de  l’allocation

• F    =  {F1  ,  F2  ,  ...,  Fn  }:  ensemble  de  fragments  

• S  =  {  S1  ,  S2  ,  ...,  Sm  }:  ensemble  de  sites
• Q  =  {  q1 ,   q2 ,  ....,  qp }:  ensemble  d’applications

• Le  problème  de  l’allocation  consiste  à  trouver  une  

distribution  optimale  entre  F  et  S  sachant  Q

2017-2018 D. Chiadmi 103

 Definition:  Optimisation  de  l’allocation
• 2  mesures  :  Coût  minimal  et  Performance
Coût de :
• stockage de chaque Fi à Sj ; Performance
• lecture de Fi à partir de Si temps de réponse;
• Mise à jour de Fi sur tous les
sites qui le stockent
• communication

Optimal ?
Minimise coût total
Modèle de coût : Minimise temps de réponse
??
2017-2018 D. Chiadmi 104
 Exemple  simple  d’allocation
• Pour  chaque  fragment  Fk:
– D  =  {d1,  d2,...  dm}  :  coût  de  stockage  de  Fk sur  S1 à  Sm
– T  =  {t1,  t2,  ...,tm}      :  trafic  généré  par  lire(Fk)  sur  S1 à  Sm
– U  =  {u1,  u2,  ...,um}:  trafic  généré  par  écrire(Fk)  sur  S1-­‐ Sm
– C(T)  =  {  c12 ,  c13,...,  c1m,....,  cm-­‐1,m }:  unité  de  coût  de  
communication  pour  une  lecture  entre  tt  couple  de  sites  
– C(U)  =  {  c'12 ,  c'13,...,  c'1m,....,  c'm-­‐1,m }:  unité  de  coût  de  
communication  pour  une  écriture  entre  tt  couple  de  sites  
– Aucune  contrainte  de  capacité  des  sites  ou  du  réseau

• Pb   :  Trouver l’ensemble de sites I ⊆ S | Fk minimise le

coût total de traitement de toutes les lectures et les
écritures 2017-2018 D. Chiadmi 105
Exple  de   modèle  de  coût

2017-2018 D. Chiadmi 106

 Synthèse
1-­‐ les  besoins  des  utilisateurs  (par  profil)  sont  intégrés  pour  créer  
un  schéma  conceptuel  unique.
2-­‐ les  vues  externes  sont  définies  à  partir  de  ce  schéma  conceptuel  
en  adéquation  avec  le  profil  des  utilisateurs.
3-­‐ la  définition  des  fragments  et  leur  correspondance  avec  le  
schéma  conceptuel  global  (schéma  de  fragmentation),  et  
l’association  à  chaque  fragment  d’un  ou  plusieurs  sites  
d'accueil  (schéma  d'allocation)  fournit  le  schéma  de  répartition    
4-­‐ Pour  chaque  site,  est  défini  
-­‐ schéma  logique  local  regroupant  les  fragments  alloués  au  site
-­‐ schéma  interne  décrivant  les  fichiers,  indexes,  clés  d'accès,  
structures  de  stockage,  ...).

2017-2018 D. Chiadmi 107

 Transactions dans les BDR

• Transaction  répartie
• Propriétés  ACID  
• Contrôle  des  accès   concurrents
• Contrôle  de  l'atomicité  :  2PC  -­‐ 3PC
• Gestion  de  la  réplication

2017-2018 D. Chiadmi 108

 Transaction   T
Suite  d'opérations  qui  fait  passer  la  BD  d’un  état  
cohérent  à  un  autre  état  cohérent.  Les  états  
intermédiaires  pouvant  être  incohérents

Modélisation :  suite  finie  d’actions  sur  des  objets

T  =  {  Oi.Aj,  |  i  =  1..n  ;  j  =  1..p  }
i  :  site  visité  par  T  ;  
Oi  :  objet  du  site  i
Oi.Aj  :  action  j  exécutée  sur  l'objet  Oi
2017-2018 D. Chiadmi 109
 Opérations  Transaction   T
Début_transaction :   initialise   la   séquence   transactionnelle
Valider_transaction :  termine   de   la   séquence   transactionnelle
Annuler_transaction :   arrêt  de   la  transaction

Lire (obj)        :  chargement   d’1  image   de  l'objet  dans   l'espace   de  

W
Ecrire (obj)  :  sauvegarde  d’1  image   de  l'obj.  en   mém.  secondaire

Transaction  centralisée :  les   objets  sont   sur   un   seul   site

Transaction  répartie :  les   objets  (et   actions)   sont  sur   +sieurs  
2016-2017 D. Chiadmi 110
sites
 Exemple  de   transaction  centralisée
Méthode  Virement  (Cpte_débiter,   Cpte_créditer,   Montant)
Début_transaction
Créditer(Cpte_créditer,  Montant)
si  Cpte_débiter  <  montant  alors  Annuler_transaction
sinon  Débiter(Cpte_débiter,  Montant)  ,  Valider_transaction
fsi

Méthode  Créditer(Cpte_créditer,   Montant)

cpte_créditer:=  cpte_créditer+montant

Méthode  Débiter(Cpte_débiter,   Montant)

cpte_débiter:=  cpte_débiter  -­‐ montant
2016-2017 D. Chiadmi 111
 En  environnement  réparti
A
T   s'exécute  sur   différents  sites

B //   Sur  l'agent  principal   A  

Crédit Méthode   Virement   (Cpte_débiter,   Cpte_créditer,   Mont)
Site X

C //   Sur  l'agent  crédit  B

Débit Méthode   Créditer(Cpte_créditer,   Mont)
Site Y

//Sur   l'agent   débit   C

Méthode   Débiter(Cpte_débiter,   Mont)
2016-2017 D. Chiadmi 112
 Propriétés  ACID
Pour  garantir  une  exécution  correcte  des  
transactions,  celles-­‐ci   doivent  respecter  les  4  
propriétés  A.C.I.D.
• Atomicité
• Consistence  (Coherency)
• Isolation
• Durabilité

2016-2017 D. Chiadmi 113

 Atomicité

La  séquence  d’opérations  de  la  transaction  

doit  être  indivisible  :  toutes  les  mises  à  jour  sont  

effectuées  ou  aucune  (unité  de  cohérence)

Mécanisme  de  validation  (commit)

2016-2017 D. Chiadmi 114
 Atomicité

En  cas  de  défaillance,  il  faut  garantir    :

-­‐ exécution  totale  :  {actions}  de  T  est  effectué  et  amène  la  
BD  à  un  nouvel  état.
ou
-­‐ exécution  sans  effet   :  les  modifications  partielles  
engagées  sont  annulées  avec  retour  à  la  version  
précédente

Ex  :  soient un  fichier  F  de  10  octets  et  une  T  qui  y  ajoute    des  
éléments
-­‐ Les  processus  qui  lisent  F  pendant  l’exécution  de  T  ne  voient  que  
les  10  octets  d'origine  indépendamment   du  nombre  d'octets  
ajoutés.  
2016-2017 D. Chiadmi 115
-­‐ Lorsque  T  est  validée,  F  grossit  instantanément.
 Consistence

Etat cohérent
Le   résultat  de   T   doit   être  consistant   (coherency)     i Contraintes
d'intégrité
avec   les   spécifications   de   l’application. T

-­‐ T  ne  viole  pas  les   invariants  du   système.   Etat cohérent
i +1 Contraintes
-­‐ T  est   correcte   selon  la   sémantique   de   d'intégrité

cohérence  de  l’ensemble  des  objets  si   elle  

amène  la   BD  d’un   état  cohérent   à  un   autre

2016-2017 D. Chiadmi 116

 Consistence

Cas de l’Invariant bancaire

- Après un transfert interne, la somme des soldes doit

toujours être la même.

-Toutefois, pendant un bref instant (durée d’exécution de

T) cet invariant est violé.

La violation n'est pas visible en dehors de la

transaction.

2016-2017 D. Chiadmi 117

 Isolation

Résultats  d'une  transaction  ne  sont  visibles  aux  

autres  transactions  qu'une  fois  celle-­‐ci  validée.

contrôle  d'accès  concurrents

2016-2017 D. Chiadmi 118

 Isolation

Propriété  de  sérialisabilité  

Permet  à  un  ensemble  de  transactions  de  s'exécuter  en  

parallèle  dans  le  même  environnement  et  d'apparaître  
comme  s'exécutant  indépendamment  les  unes  des  
autres  (sérialisables).  

2016-2017 D. Chiadmi 119

 Isolation

Ex   :
début-­‐Transaction début-­‐Transaction début-­‐Transaction
x=0 x=0 x=0
x=x+1 x=x+2 x=x+4
fin-­‐Transaction fin-­‐Transaction fin-­‐Transaction

Différents  ordonnancements   possibles  :

O1    x=0 x=x+1 x=0              x=x+2 x=0            x=x+4 légal

O2    x=0 x=0 x=x+1 x=x+2 x=0 x=x+4 légal
O3    x=0 x=0 x=x+1 x=0 x=x+2 x=x+4 illégal

2016-2017 D. Chiadmi 120

 Durabilité

Les  modifications  d’une  transaction  validée  ne  seront  

jamais  perdues.  Le  résultat  est  durable  (persistant)  même  
en  cas  de  défaillance  de  processeurs  ou  de  
communication
Mécanisme  de  reprise  après  panne  (recovery)

La  durabilité  garantit  que  les  effets  des  opérations  ne  sont  

altérés  par  aucune  sorte  de  panne.

La  fin  d'une  transaction  est  un  point  de  non-­‐retour.

2016-2017 D. Chiadmi 121
Contrôle  des  accès  concurrents :   éxécution   ||   de   2   T  sur   1  objet

T1  et   T2   exécutent   Débiter sur   cpte   N   de   solde  initial  S0

T1:   Débiter(N,100) et T2:   Débiter(N,200)

TpsT   Actions   Valeur   du   solde  sur   disque

t0             T1   Début_transaction
t1   T2   Début_transaction
t2   T1   Lire(N) S0 L'état cohérent
t3   T2   Lire(N)   S0 après exécution
t4   T1   C.Solde:=C.Solde-­‐100 de T1 et T2 est
t5   T2   C.Solde:=C.Solde-­‐200 S0-300 !
t6   T1   Ecrire(N,C)   S0-­‐100
t7 T1   Fin_transaction
t8   T2   Ecrire(N,C)   S0-­‐200
t9Violation de la propriété d'isolation : Mise en œuvre
T2   Fin_transaction
des mécanismes de contrôle d'accès concurrents
2016-2017 D. Chiadmi 122
 Contrôle  réparti  de  concurrence  :

• Objectif  :  compromis  entre  (1)  consistence  

dela  BD  et  (2)  niveau  élevé de  concurrence

2016-2017 D. Chiadmi 123

 Plan  d’exécution  de   transaction

Les  opérations  d’une  transaction  sont  

exécutées  selon  un  ordre  (schedule).  

Les  entrelacements  des  opérations  de  lecture  

et  d'écriture  de  transactions  concurrentes  
permet  de  gagner  sur  l'aspect  performance.  Il  
faut   toutefois  veiller  à  maintenir  la  cohérence

2016-2017 D. Chiadmi 124

 Ex  :  Soient  3  Ts  T1,T2,T3  opérant  sur  2  objets  X  et  Y
Temps T1 T2 T3 Exécution
t1 Début concurrente de T1
Cohérence
et T2 valide? :
t2   Début
t3 équivalente à
Début Equivanlence
l'exécut° en à une
t4 Ecrire X exécution séquentielle
séquence de T2 puis
t5 Lire Y des
T1 transactions sans
t6 Lire X Exécution
t7 entrelacement.
Ecrire Y concurrente de T2
t8   Lire Y et T3 incorrecte : ne
t9 Lire X correspond à aucune
t10 Fin des 2 séquences {T2,
t11 Fin T3} ou {T3 puis T2}
t12 Fin
L'apparition d'un conflit (à t5) crée une relation de dépendance
2016-2017 D. Chiadmi 125
 Rappel  :  sérialisabilité
•Une  exécution  concurrente  est  dite  sérialisable si  son  
résultat  est  le  même  que  celui  d’une  des  exécutions  
séquentielles.

•2  plans  d’excéution  de  T1  et  T2  sont  équivalents si  

– (Intuitivement)  ils  ont  le  même  effet  sur  la  BD
– (Formellement)  pour  chaque  couple  d’opérations  en  
concurrence,  ces  opérations  sont  commutatives.
– Aucune  transaction  n’aborte
2016-2017 D. Chiadmi 126
 Cohérence
Cohérence    (sans  réplication)
– Chaque  T  exécutée  seule  maintient  la  cohérence.
– Exécution  selon  un  ordre qui  garantit  que  les  exécutions  
concurrentes  sont  sérialisableS

•Cohérence  (Réplication)
– Toutes  les  copies  sont  identiques
– Le  plan  d’exécution   qui  maintient  la  cohérence  des  copies  
est  :  one-­‐copy  serializable.
– Un  plan  d’exécution   est  “one-­‐copy  serializable”  si  chaque  
plan  est  sérialisable  et  si  tt  couple  d’opérations   en  conflits  se  
retrouvent  dans  le  même  ordre  dans  les  plans  locaux  
d’exécution

2016-2017 D. Chiadmi 127

Exemple

2016-2017 D. Chiadmi 128

2016-2017 D. Chiadmi 129
2016-2017 D. Chiadmi 130
 Algorithmes  de  contrôle  de  concurrence  
(CC)
Algorithmes CC

Pessimiste Optimiste

Verrouillage Estampille

Verrouillage Estampille Hybride

2016-2017 D. Chiadmi 131

 Technique   de  verrouillage

Principe  similaire  aux  BD  centralisées  :  poser  des  

verrous  au  début  de  chaque  transaction  

2016-2017 D. Chiadmi 132

 Technique   d’estampillages

Ordre  de  sérialisation  obtenu  par  association  d’une  

estampille  à  chaque  Transaction.  Si  conflit,  vérifier  que  
les  accès  concurrents  se  font  dans  l'ordre  des  
estampilles

Fonctionnement :  Chaque  fragment  garde  trace  de  la  

dernière  transaction  qui  l’a  utilisé  (Tj)

2016-2017 D. Chiadmi 133

 1-­‐ Technique  d’estampillages   et  Rollback

Ordonnancement :  
//  Ti accède  à  un  fragment  estampillé  j
-­‐ Si  j  ≤  i  alors  Ti peut  s’exécuter  //  Ti postérieure  à  Tj
Sinon  annuler  Tj,   exécuter  Ti &  
reprise  ultérieure  de  Tj avec  estampille  e  >  j

-­‐ Conflits  gérés  par  des  rollbacks

-­‐ Risque  de  cascade  de  rollbacks  

2016-2017 D. Chiadmi 134

 2-­‐ Conservation  de  l’ordre  des   estampilles
Retarder  les  opérations  jusqu’au  moment  où  elles  
pourraient  être  exécutées  sans  avortement.  Pas  de  
cascade  de  rollbacks  

-­‐ Retarder  Lire(X)  par  Ti

-­‐ si  Tj veut  Ecrire(X)  et  Estamp  (Tj)  <  Estamp(Ti )

-­‐ Retarder  Ecrire(X)  par  Ti

-­‐ si  Tj veut  Lire(X)  et  Estamp  (Tj)  <  Estamp  (Ti )

-­‐ Gestion  locale  des  files  de  lectures/écritures  à  retarder

2016-2017 D. Chiadmi 135

 Techniques  de  contrôle  :  méthode   optimiste
Dépendances   enregistrées   pendant  l'exécution   et   contrôlées  
à  posteriori   à  la   fin   de   T   (ϕ de   certification   pendant   la  ϕ de  
validation)

On   ne   recherche   l'existence   de   circuits   que   :

-­‐ dans  le  graphe  de  dépendance   des   Ts  validées
-­‐ au  moment  de   la   validation   d'une  nouvelle   transaction

S'il  existe  un   circuit,   la   transaction   qui   valide  est  rejetée

Lectures Phase de Etape d'écriture
écritures Certification dans la base

tdébut tfin Point de validation

2016-2017 D. Chiadmi 136
 Conclusion   de  Contrôle   de  
Concurrence
Performance
-­‐Les  paramètres  clés  du  comportement  des  méthodes  de  
contrôle  sont  le  taux  de  conflit  et  la  durée  des  Ts

-­‐les  méthodes  de  certification  donnent  de  bons  résultats  

lorsque  le  taux  de  conflit  est  faible

-­‐ le  verrouillage  est  préférable  lorsque  le  taux  de  conflit  

est  fort  ou  lorsque  les  transactions  sont  longues.

2016-2017 D. Chiadmi 137

 Contrôle   de  l'atomicité
Rappel  :  Pour  un  observateur  extérieur,  toutes  les  actions  
associées  à  l'action  atomique  sont  soient  réalisées  
complètement  soient  pas  du  tout.

T  interrompue  avant  sa  terminaison  viole  l’atomicité  avec

nécessité  de  restaurer  l'état  initial  :  défaire  les  actions  
exécutées
Crédit M
S1 L'atomicité locale de T est
Journalisat°
validati° assurée par chaque site, mais
S2
l'atomicité globale est violée
S3 débit M abondan

2016-2017 D. Chiadmi 138

 Contrôle   de  l'atomicité

En  réparti,  il  faut  une  coordination  pour  

garantir  l'atomicité

But  :  arriver  à  une  décision  unanime  de  

terminaison  d'une  transaction   répartie  (abandon  
ou  validation)  par  vote  
=>  atomicité  globale  répartie

2016-2017 D. Chiadmi 139

Protocole  de  validation   à  2  ϕ (2PC)
• Exécuté  par  chaque  site
• Contrôlé  par  un  site  maître  (coordonnateur)
• Assure  l’atomicité  
• ϕ de  Préparation :  coordonnateur  demande  aux  sites  
de  se  préparer
• ϕ de  Validation :  coordonnateur  ordonne  la  
validation  ou  l’avortement  en  fonction  des  résultats  
de  la  commit
prépare 1ère  ϕcommitted prépare abort aborted
S1 S1
prêt prêt
C C
prêt committed S2 attente aborted S2
2016-2017 D. Chiadmi 140
 2PC  :  Règles  du  Vote
-­‐ chaque  participant  (P)  fournit  un  vote  :  commit  ou  abort
-­‐ ayant  voté,  un  P  ne  peut  plus  changer  son  vote
-­‐ si  P  vote  abort,  il  peut  annuler  sa  T  immédiatement.
-­‐ si  P  vote  commit,  il  doit  attendre  la  décision  globale  
diffusée  par  C
-­‐ Si  ts  les  P  votent  commit,  la  décision  globale  est  commit
-­‐ Ts  les  P  sont  tenus  d ’adopter  la  décision  globale

2016-2017 D. Chiadmi 141

 Protocole  de  Validation  à  2  ϕ
PHASE 1 :  
Ci :    
– Journalise  <Prépare  T  >  
– Envoie  <Prepare  to  Commit  >  aux  sites  Sj  impliqués  
– Attend  les  ack  

Chaque  Sj :
– Si  validation  possible  alors  
journalisation  et  envoie  <Prêt  T>  à  Ci  
Sinon  
journalisation  <no  T>  et  envoie  <Abort  T>  à  Ci
2016-2017 D. Chiadmi 142
 Protocole  de  Validation  à  2  ϕ
PHASE 2
CAS  REUSSITE :
T  validée  si  tous  les  <Prêt  T>  parvenus  
– Journalisation  <Commit  T>  sur  Ci
– Envoie  <  Commit  >  aux  sites  Sj  impliqués
– Les  Sj  envoie  ACKj  à  Ci  
– Ci  journalise  <Complète   T>  après  réception  des  ACK

CAS  ECHEC :  
Si  un  des  Sj  répond  <Abort  T>  ou  tous  les  <Prêt  T>  non  parvenus  à  Ci  
dans  un  délai  d  
– Ci  journalise  <Abort  T>  
– envoie  <Abort  T>  aux  Sj
– Les  Sj  envoie  ACKj  à  Ci  
– Ci  journalise  <Complète   T>  après  réception  des  ACK
2016-2017 D. Chiadmi 143
 2PC  :  Algorithme   coordonateur  
Step C1 : Ordre vote
Write ‘begin global commit’ message to log // journal
Send ‘vote’ message to all participants
Wait until vote received from all participants
On timeout go to step C2b
Step C2a : Global commit
If all votes are ‘commit’
Then Write ‘global commit’ record to log
Send ‘global commit’ to all participants
Step C2b : Global abort
Else //si au -1participant abort ou temporisateur(C)expire
Write ‘global abort’ record to log
Send ‘global abort’ to all participants End-if
Step C3 : Terminaison
Wait until ack received from all participants
Write ‘ end global’ transaction record’ to log

2016-2017 D. Chiadmi 144

 2PC  :  Algorithme   Participant  
Step P0 : Wait for vote instruction
Wait until ‘vote’ instruction received from C

Step P1 : Vote
If vote = ‘commit’ then send ‘commit’ to C
Else send ‘abort’ and goto step P2b
Wait until global vote received from C

Step P2a : commit

If globalvote =‘commit’ then perform local commit processing
Step P2b : abort
Else Perform local abort processing //au -1 P a abort
End-if

Step P3 : Terminaison
Send ack to C
Finish
2016-2017 D. Chiadmi 145
 Pbs  
• Coordonnateur  ne  reçoit  pas  le  vote  (réglé  
par  temporisateur)
• Participant  vote  mais  ne  reçoit  pas  la  
décision  :  ??
• Participant  a  subi  une  panne  pendant  le  
process  :  ??

• Il  n’existe  pas  de  protocole  résolvant  le  problème  de  

l’accord   avec  un  nb  fini  de  messages  si  la  communication  
n’est  pas  fiable
2016-2017 D. Chiadmi 146
 2PC  :  Algorithme  de  terminaison  coopérative
Do while P0 is blocked
//P0 sends a message to Pi asking for help to un-block
STEP 1 : help requested from Pi

If Pi knows the decision

//Pi receveid global-commit/abort or Pi unilaterally aborted
Then Pi conveys decision to P0
P0 unblocks and finishes End-if

STEP 2 : Has Pi voted ?

If Pi has not voted
Then Pi unilaterally aborts
P0 told to abort
P0 unblocks and finishes End-if

STEP 3 : Pi cannot help ; // Try Pi+1

Next Pi Etat incertain
End-do 2016-2017 D. Chiadmi 147
 2PC  :  Algorithme  reprise  après  échec  d’un  P
Do while Pr is blocked

STEP 1 : Statut du Pr avant l’échec

If Pr voted commit Then goto step 2
Else
//Pr a voté ‘abort’ avant l’échec ou n’a pas voté
Pr aborts unilaterally
Pr recovers independently and finishes End-if

STEP 2 : Is global decision know ?

If Pr knows global decision
Then Pr takes action in accordance with global decision
Pr recovers independently and finishes End-if

STEP 3 : Pr cannot recover independently and asks for help

//P0 sends a message to Pi asking for help to un-block
Pr asks for help from Pr+1 using cooperative termination alg.

End-do 2016-2017 D. Chiadmi 148

 2PC  au  3PC
2PC est bloquant : terminaison est non assurée
Ex : si le temporisateur d’un P expire après l’expression du
'commit', mais avant la réception de l'ordre global de C . Ce P
sera bloqué s'il ne peut communiquer qu’avec les sites qui
(comme lui) ignorent la décision globale.

3PC est un protocole non bloquant en présence d’échecs de

sites, excepté en cas de l'échec de tous les sites.

Les pannes de communication peuvent causer une violation de

l'atomicité des transactions globales si différents sites
prennent des décisions différentes
2016-2017 D. Chiadmi 149
 3PC  :  Algorithme   coordonateur
Step C1 : vote
Write ‘begin transaction’ in log
Send ‘vote’ message to all participants
Do until all vote received
Wait
On timeout go to step C2b
End-do
Step C2a : Pre-commit
If all votes are ‘commit’
Then Write ‘pre-commit‘ message to log
Send ‘pre-commit’ message to all participants
Step C2b : Global abort
Else //si au -1participant exprime abort ou temporisateur
du C expire
Write ‘global abort‘ message in log
Send ‘global abort’ to all participants
Goto step C4
End-if 2016-2017 D. Chiadmi 150
 3PC  :  Algorithme   coordonateur

Step C3 : Global commit

Do until all (pre-commit) acknowledgement received
Wait
End-do
Write ‘global commit‘ to log
Send ‘global commit’ to all participants

Step C4 : Terminaison
Do until acknowledgements received from all participants
Wait
End-do
Write ‘ end transaction’ entry in log
Finish

2016-2017 D. Chiadmi 151

 3PC  :  Algorithme   coordonateur
Step C1 : vote
Write ‘begin T’ in log ;
Send ‘vote’ message to all P
Do until all vote received
Wait
On timeout go to step C2b
End-do

Step C2a : Pre-commit

If all votes are ‘commit’
Then Write ‘pre-commit‘ message to log
Send ‘pre-commit’ message to all
participants

Step C2b : Global abort //au -1 P abort ou timer(C) expire

Else Write ‘global abort‘ message in log
Send ‘global abort’ to all participants
Goto step C4 End-if
2016-2017 D. Chiadmi 152
 3PC  :  Algorithme   Participant
Step P0 : Wait for vote instruction
Do until ‘vote’ instruction received from C
Wait End-do
Step P1 : Vote
If participant is prepared to ‘commit’
then send ‘commit’ message to C
Else send ‘abort’ message to C and goto stepP2b
Do until global instruction received from C Wait End-do
Step P2a : Pre-commit
If globalinstruction =‘precommit’
then goto step P3 (and wail for global commit) end-if
Step P2b : abort //au -1participant a exprimé abort
Perform local abort processing ; Goto step P4
Step P3 : commit
Do until ‘global commit’ instruction received from C
Wait End-do
Perform local commit processing
Step P4 : Terminaison
Send acknowledgement to C ; Finish
2016-2017 D. Chiadmi 153
 Autres
• Linear  2PC  

• Distributed  2PC  

• Unsolicited  V  ote  (UV)

• Early  Prepare  (EP)  

• Coordinator  Log  (CL)  

• Implicit  oui  V  ote  (IYV)  

• Two-­‐Phase  Abort  (2P  A)  

2016-2017 D. Chiadmi 154

 Gestion  de  données  répliquées
• Intérêt  de  la  réplication,  
• Gestion  de  la  cohérence  des  copies,  
• ROWA
• QC,  

2016-2017 D. Chiadmi 155

 Intérêt  de  la  réplication
• Intérêt
– Augmenter  la  disponibilité  des  données
– Améliorer  la  performance  grâce  à  
• Un  meilleur  partage  de  charge
• Un  accès  local  aux  données   «  rapide  »

• Inconvénient
– Gestion  des  copies  (l’exécution  concurrente  de  
transactions  doit  être  équivalent  à  l’exécution  
concurrente  de  ces  transactions  sur  une  BD   à  
copie  unique)

2016-2017 D. Chiadmi 156

Cohérence  mutuelle  des  copies  d’une  BD  répliquée
• 2  classes d’algorithmes  
-­‐ ROWA  :  Read  One,  Write  All
-­‐ Quorum  Consensus  :  
• Quorum  lecture
• Quorum  écriture

2016-2017 D. Chiadmi 157

 Algorithmes   Réplication  
Taxonomie :

-­‐ Architecture :  maître/esclaves,  P2P

-­‐ stratégie  de  lecture :
lire  un/  lire  partie  (quorum  lecture)
-­‐ stratégie  de  propagation :  
écrire  tout/partie  (quorum  écriture)
-­‐ Mode : synchrone/Asynchrone

2016-2017 D. Chiadmi 158

 Algorithmes   ROWA  
-­‐ Architecture
Site  maître :  copie  primaire  ou  copie  maître
Sites  esclaves   :  copies  backups  /  copies  secondaires  

-­‐ Stratégie   de  lecture :

lire  copie  primaire  (backup)  /  lire  une  copie  quelconque

-­‐ Stratégie   de  propagation :  écrire  toutes les  copies

-­‐ Mode :
Synchrone :  inclure toutes  les  écritures  dans  une  même  
transaction  répartie
Asynchrone :  chaque  écriture  est  réalisée  par  une  transaction  
indépendante avec  éventuellement   des  rollbacks  en  cas  de  
pbs. 2016-2017 D. Chiadmi 159
 Algorithmes   Quorum   Consensus  
-­‐ Architecture :   Sites  équivalents  (n  copies)
chaque  copie  est  dotée  d’un  numéro  de  version
-­‐ Stratégie   de  lecture :
Demander  le  numéro  de  version  à  QL copies,  lire  à  partir  de  la  
copie  la  plus  fraîche

-­‐ Stratégie   de  propagation :  Demander   le  n° version  à  QW copies,  

-­‐ Mettre  à  jour  les  copies  les  plus  fraîches  
-­‐ Répercuter  les  écritures  manquantes  dont  l’écriture  
courante  aux  autres

Condition  :  QL +  QW ≥  n  +1   (peut  être  relâché)

QW ≥  n/2

2016-2017 D. Chiadmi 160

 Processus  de  conception  
ascendante BD

Analyse des besoins BD1 BD2 … BDn

Niv. physique Objectifs

Schémas
locaux
conceptuels
Niv. intégration* Niv. Vues

Schéma Spécialisation en vues

conceptuel Vues externes
global

2016-2017 D. Chiadmi 161

 Processus  de  conception  
descendante   BD

Analyse des besoins BD1 BD2 … BDn

Objectifs

Conception conceptual Intégration des vues

Conception des vues

Schéma Information d’accès Vues externes

conceptuel
global Niv. Répartition*
-SCG-
Schémas Niv. Physique
conceptuels
locaux Schémas
* Fragmentation + allocation -SCL- locaux
2016-2017 D. Chiadmi internes 162