Esercizi proposti a lezione cap. 6 – rev. nov. 2007 da Atzeni ed altri - Basi di dati vol. 2/2ed 2007
BASI DI DATI DISTRIBUITE
Esercizio n. 1
Si consideri la base dati:
PRODUZIONE (NumeroSerie, TipoParte, Modello, Qta, Macchina)
PRELIEVO (NumeroSerie, Lotto, Cliente, Venditore, Ammontare)
CLIENTE (Nome, Città Indirizzo)
VENDITORE (Nome, Città Indirizzo)
Progettare la frammentazione orizzontale delle tabelle PRODUZIONE e PRELIEVO in base al
tipo di parte (che assume quattro valori: “Tastiera”, “Schermo”, “CPU” e “Cablaggio”),
prevedendo quattro stabilimenti di produzione disposti a Milano, Torino, Roma e Napoli, e
delle tabelle CLIENTE e VENDITORE in base a tre bacini di vendita, centrati su Torino,
Milano e Roma; si supponga che le vendite siano distribuite per bacini geografici (quindi,
clienti di Milano sono serviti solo da venditori di Milano; si assuma che il bacino di vendita di
Roma comprenda anche Napoli) e che ciascuna area geografica abbia una propria base di
dati (cioè che sia disponibile una base di dati a Milano, Torino, Roma e Napoli). Esprimere a
livello di trasparenza di frammentazione, di allocazione e di linguaggio le interrogazioni:
1. Determinare la quantità disponibile del prodotto 77Y6878
2. Determinare i clienti che hanno comprato qualche lotto dal rivenditore Bianchi, che ha
ufficio a Roma.
3. Determinare le macchine utilizzate per la produzione dei pezzi di tipo “Tastiera” venduti
al cliente Rossi.
4. Modificare l’indirizzo del cliente Rossi, che si trasferisce da “Via Po 45” di Milano a
“Viale Trastevere 150” di Roma
5. Calcolare la somma degli importi degli ordini ricevuti a Milano, Torino e Roma (si noti
che anche le funzioni aggregate sono disponibili)
Scrivere poi, ipotizzando di usare il DBMS di “Milano”, una richiesta remota, una transazione
remota, una transazione distribuita e una richiesta distribuita.
Esercizio n. 2
Descrivere come l'organizzazione di una riunione (di un insieme di persone che debbono
essere tutte presenti) possa essere basata su un protocollo con le stesse caratteristiche del
commit a due fasi.
Esercizio n. 3
Si consideri il protocollo di commit a due fasi (2PC).
1. Spiegare perché:
(a) un guasto del coordinatore (TM) può avere conseguenze molto pesanti anche sulle
prestazioni dei partecipanti (RM);
(b) un guasto di un partecipante non ha conseguenze particolari sulle prestazioni degli
altri partecipanti
1
Esercizi proposti a lezione cap. 6 – rev. nov. 2007 da Atzeni ed altri - Basi di dati vol. 2/2ed 2007
(a parte l’eventuale abort di transazioni).
Per ovviare alle conseguenze negative di un guasto del coordinatore, alcune implementazioni
del 2PC prevedono la possibilità di comunicazione fra i partecipanti (mentre la versione base
prevede solo comunicazione fra il coordinatore e ciascuno dei partecipanti). In particolare, un
partecipante che abbia una transazione in stato di “ready” può chiedere agli altri partecipanti
informazioni sullo stato di tale transazione (che può essere “prima-del-ready”, “ready”,
“commit” o “abort”) presso di loro.
2. In tale contesto indicare
(a) come (e in quali casi) il partecipante può trarre profitto dalle risposte ottenute;
(b) quali insiemi di risposte il partecipante può ricevere e quali invece no.
Esercizio n. 4
Descrivere come si modifica il protocollo di ripresa a caldo tendo presente che alcune sottotransazioni distribuite possono essere in stato di ready.
Esercizio n. 5
Applicare il protocollo di ripresa a caldo dopo la caduta di un nodo assumendo un algoritmo di
commit a due fasi, a fronte del seguente input (ove r(ti) indica la presenza del record di
ready):
B(T1), B(T2), B(T3), I(T1,O1,A1), D(T2,O2,B2), B(T4), R(T1), U(T4,O3,B3,A3), C(T1), CK(T2,T3,T4),
B(T5), B(T6), U(T5,O5,B5,A5), R(T5), B(T7), U(T7,O6,B6,A6), B(T8), U(T6,O1,B7,A7), A(T7), R(T6),
guasto
Esercizio n. 6
Descrivere un esempio di comportamento di una base di dati replicata che produce
disallineamento tra i dati.
Esercizio n. 7
Descrivere un esempio di replicazione simmetrica che produce inconsistenza dei dati.
2
Esercizi proposti a lezione cap. 6 – rev. nov. 2007 da Atzeni ed altri - Basi di dati vol. 2/2ed 2007
SOLUZIONE Esercizio 1
Ia PARTE
Frammentazione orizzontale della tabella PRODUZIONE (4 tabelle)
PRODUZIONE _1 = σTipoParte= ‘Tastiera’ (PRODUZIONE)
PRODUZIONE _2= σTipoParte=’Schermo’ (PRODUZIONE)
PRODUZIONE _3= σTipoParte=’CPU’ (PRODUZIONE)
PRODUZIONE _4= σTipoParte=’Cablaggio’ (PRODUZIONE)
Frammentazione orizzontale (derivata) della tabella PRELIEVO (4 tabelle)
PRELIEVO_1= Π NumeroSerie, Lotto, Cliente, Venditore, Ammontare (σTipoParte=’Tastiera’ (PRELIEVO
NumeroSerie = SN SN← NumeroSerie (PRODUZIONE)))
PRELIEVO_2= Π NumeroSerie, Lotto, Cliente, Venditore, Ammontare (σTipoParte=’Schermo’ (PRELIEVO
NumeroSerie = SN SN← NumeroSerie (PRODUZIONE)))
PRELIEVO_3= Π NumeroSerie, Lotto, Cliente, Venditore, Ammontare (σTipoParte=’CPU’ (PRELIEVO
NumeroSerie = SN SN← NumeroSerie (PRODUZIONE)))
PRELIEVO_4= Π NumeroSerie, Lotto, Cliente, Venditore, Ammontare (σTipoParte=’Cablaggio’ (PRELIEVO
NumeroSerie = SN SN←NumeroSerie (PRODUZIONE)))
Frammentazione orizzontale della tabella CLIENTE (3 tabelle)
CLIENTE_1= σCittà =‘Torino’ (CLIENTE)
CLIENTE_2= σCittà =‘Milano’ (CLIENTE)
CLIENTE_3= σCittà =‘Roma’ V Città =‘Napoli’ (CLIENTE)
Frammentazione orizzontale della tabella VENDITORE
VENDITORE_1= σCittà =‘Torino’ (VENDITORE)
VENDITORE _2= σCittà =‘Milano’ (VENDITORE)
VENDITORE _3= σCittà =‘Roma’ V Città =‘Napoli’ (VENDITORE)
Le tabelle PRODUZIONE_1, PRELIEVO_1, CLIENTE_1, VENDITORE_1 potranno essere
allocate a Torino (Torino.Azienda.it)
Le tabelle PRODUZIONE_2, PRELIEVO_2, CLIENTE_2, VENDITORE_2 potranno essere
allocate a Milano (Milano.Azienda.it)
Le tabelle PRODUZIONE_3, PRELIEVO_3, CLIENTE_3, VENDITORE_3 potranno essere
allocate a Roma (Roma.Azienda.it)
Le tabelle PRODUZIONE_4, PRELIEVO_4 potranno essere allocate a Napoli
3
Esercizi proposti a lezione cap. 6 – rev. nov. 2007 da Atzeni ed altri - Basi di dati vol. 2/2ed 2007
(Napoli.Azienda.it)
4
Esercizi proposti a lezione cap. 6 – rev. nov. 2007 da Atzeni ed altri - Basi di dati vol. 2/2ed 2007
Punto 1: Determinare la quantità disponibile del prodotto 77Y6878
Trasparenza di frammentazione:
Procedure QueryDispo1 ( :Quan)
select Qta into :Quan
from PRODUZIONE
where NumeroSerie = “77Y6878”
end Procedure
Trasparenza di allocazione:
Procedure QueryDispo2 ( :Quan)
select Qta into :Quan
from PRODUZIONE_1
where NumeroSerie = “77Y6878”
if :empty then
select Qta into :Quan
from PRODUZIONE_2
where NumeroSerie = “77Y6878”
if :empty then
select Qta into :Quan
from PRODUZIONE_3
where NumeroSerie = “77Y6878”
if :empty then
select Qta into :Quan
from PRODUZIONE_4
where NumeroSerie = “77Y6878”
end Procedure
Trasparenza di linguaggio:
Procedure QueryDispo3 ( :Quan)
select Qta into :Quan
from [email protected]
where NumeroSerie = “77Y6878”
if :empty then
select Qta into :Quan
from [email protected]
where NumeroSerie = “77Y6878”
if :empty then
select Qta into :Quan
from [email protected]
where NumeroSerie = “77Y6878”
if :empty then
select Qta into :Quan
from [email protected]
where NumeroSerie = “77Y6878”
end Procedure
5
Esercizi proposti a lezione cap. 6 – rev. nov. 2007 da Atzeni ed altri - Basi di dati vol. 2/2ed 2007
Punto 2: Determinare i clienti che hanno comprato qualche lotto dal rivenditore Bianchi, che
ha ufficio a Roma.
Trasparenza di frammentazione:
Procedure QueryLotto1 ( :Cl)
select Cliente into :Cl
from PRELIEVO
where Venditore =”Bianchi”
end Procedure
Trasparenza di allocazione:
Procedure QueryLotto2 ( :Cl)
select Cliente into :Cl
from PRELIEVO_1
where Venditore =”Bianchi”
if :empty then
select Cliente into :Cl
from PRELIEVO_2
where Venditore =”Bianchi”
if :empty then
select Cliente into :Cl
from PRELIEVO_3
where Venditore =”Bianchi”
if :empty then
select Cliente into :Cl
from PRELIEVO_4
where Venditore =”Bianchi”
end Procedure
Trasparenza di linguaggio:
Procedure QueryLotto3 ( :Cl)
select Cliente into :Cl
from [email protected]
where Venditore =”Bianchi”
if :empty then
select Cliente into :Cl
from [email protected]
where Venditore =”Bianchi”
if :empty then
select Cliente into :Cl
from [email protected]
where Venditore =”Bianchi”
if :empty then
select Cliente into :Cl
from [email protected]
where Venditore =”Bianchi”
6
Esercizi proposti a lezione cap. 6 – rev. nov. 2007 da Atzeni ed altri - Basi di dati vol. 2/2ed 2007
end Procedure
Punto 3: Determinare le macchine utilizzate per la produzione dei pezzi di tipo “Tastiera”
venduti al cliente Rossi.
Trasparenza di frammentazione:
Procedure QueryMacchinePerTastiere1 ( :mac)
select Macchine into :mac
from PRODUZIONE join PRELIEVO On
PRODUZIONE.NumeroSerie = PRELIEVO.NumeroSerie
where Cliente = ”Rossi” and TipoParte = ”Tastiera”
end Procedure
Trasparenza di allocazione:
Procedure QueryMacchinePerTastiere2 ( :mac)
select Macchine into :mac
from PRODUZIONE_1 join PRELIEVO_1 On
PRODUZIONE_1.NumeroSerie =
PRELIEVO_1.NumeroSerie
where Cliente = ”Rossi”
end Procedure
Trasparenza di linguaggio:
Procedure QueryMacchinePerTastiere3 ( :mac)
select Macchine into :mac
from [email protected]
join [email protected] On
PRODUZIONE_1.NumeroSerie =PRELIEVO_1.NumeroSerie
where Cliente = ”Rossi”
end Procedure
Punto 4: Modificare l’indirizzo del cliente Rossi, che si trasferisce da “Via Po 45” di Milano a
“Viale Trastevere 150” di Roma
Trasparenza di frammentazione:
Procedure ModificaIndirizzo1
update CLIENTE
set Indirizzo=”Via Po 45”, Città=”Milano”
where Nome = ”Rossi”
end Procedure
Trasparenza di allocazione:
Procedure ModificaIndirizzo2
7
Esercizi proposti a lezione cap. 6 – rev. nov. 2007 da Atzeni ed altri - Basi di dati vol. 2/2ed 2007
delete from CLIENTE_3
where Nome = “Rossi”;
insert into CLIENTE_2 (Nome, Indirizzo, Città) values
(“Rossi”, ”Via Po 45”, ”Milano”)
end Procedure
Trasparenza di linguaggio:
Procedure ModificaIndirizzo2
delete from [email protected]
where Nome = “Rossi”;
insert into [email protected]
(Nome, Indirizzo, Città) values
(“Rossi”, ”Via Po 45”, ”Milano”)
end Procedure
Punto 5: Calcolare la somma degli importi degli ordini ricevuti a Milano, Torino e Roma (si noti
che anche le funzioni aggregate sono disponibili)
Trasparenza di frammentazione:
Procedure Ordini1
select Citta, sum(Ammontare)
from PRELIEVO join VENDITORE on Venditore = Nome
group by Città
end Procedure
Trasparenza di allocazione:
Procedure Ordini2
create view PRELIEVO as
PRELIEVO_1 union PRELIEVO_2 union
select Citta, sum(Ammontare)
from PRELIEVO join VENDITORE_1 on
group by Città
union
select Citta, sum(Ammontare)
from PRELIEVO join VENDITORE_2 on
group by Città
union
select Citta, sum(Ammontare)
from PRELIEVO join VENDITORE_3 on
group by Città
end Procedure
PRELIEVO_3 union PRELIEVO_4
Venditore = Nome
Venditore = Nome
Venditore = Nome
Trasparenza di linguaggio:
Procedure Ordini2
create view PRELIEVO as
[email protected] union
[email protected] union
8
Esercizi proposti a lezione cap. 6 – rev. nov. 2007 da Atzeni ed altri - Basi di dati vol. 2/2ed 2007
[email protected] union
[email protected]
select Citta, sum(Ammontare)
from PRELIEVO join [email protected]
on Venditore = Nome
group by Città
union
select Citta, sum(Ammontare)
from PRELIEVO join VENDITORE_2@ Milano.Azienda.it
on Venditore = Nome
group by Città
union
select Citta, sum(Ammontare)
from PRELIEVO join [email protected]
on Venditore = Nome
group by Città
end Procedure
IIa PARTE
Richiesta Remota
select *
from PRODUZIONE_2
where Qta > 100
Transazione Remota
update CLIENTE_2
set Indirizzo = “Via Fogazzaro 11”
where Nome = “Verdi”
Transazione Distribuita
delete from CLIENTE_2
where Nome = “Bianchi”
insert into CLIENTE_1 (Nome, Indirizzo, Città) values
(“Bianchi”, ”Via Ponente 45”, ”Milano”)
Richiesta Distribuita
select Nome
from PRELIEVO_1 join CLIENTE_3 on Cliente = Nome
where NumeroSerie = “458X411”
9
Esercizi proposti a lezione cap. 6 – rev. nov. 2007 da Atzeni ed altri - Basi di dati vol. 2/2ed 2007
Soluzione Esercizio n.2
Un coordinatore contatta tutti i partecipanti che rispondono comunicando la propria
disponibilità (in modo irrevocabile). Se le risposte sono ricevute tutte entro un tempo limite
prefissato e sono tutte positive, allora il coordinatore fissa la riunione (altrimenti la disdice)
comunicando la decisione a tutti i partecipanti.
Soluzione Esercizio n.3
1(a) un guasto del coordinatore (TM) può avere conseguenze molto pesanti anche sulle
prestazioni dei partecipanti (RM) perché questi ultimi potrebbero avere transazioni in stato di
“ready" (cioè nella “finestra di incertezza"), con i lock acquisiti sulle risorse coinvolte, in attesa
di risposta da parte del TM;
1(b) un guasto di un partecipante non ha conseguenze particolari sulle prestazioni degli altri
partecipanti (a parte l'eventuale abort di transazioni), perché:
- se il guasto avviene prima del ready, allora il partecipante stesso non risponde al prepare
e quindi, scattato il time-out della prima fase, il coordinatore decide per l'abort;
- se il guasto avviene dopo il ready, l'unica complicazione è la necessità di ripetere la
seconda fase
2(a) se riceve almeno una risposta che contenga una decisione, può basarsi su di essa: se
riceve almeno una risposta “commit," può assumere che la transazione sia andata a buon
fine, se riceve almeno una risposta “abort," può assumere che essa sia fallita;
2(b) non è possibile che riceva “abort" da un partecipante e “commit" da un altro; né che
riceva prima-del-ready" da uno e “commit" da un altro.
Soluzione Esercizio n.4
Protocollo di ripresa a caldo in sistemi distribuiti:
1) Si accede all’ultimo blocco del log e si ripercorre il log all’indietro fino al record di
checkpoint.
Si costruiscono 3 insiemi, detti di UNDO, di REDO e di READY. Gli insiemi REDO e READY
sono vuoti, mentre quello di UNDO contiene le transazioni indicare nel record di checkpoint.
2) Si ripercorre il log in avanti, aggiungendo all’insieme di UNDO tutte le transazioni di cui è
presente il record di begin.
Se viene rilevato un record ready, la corrispondente transazione viene spostata in READY.
Se viene trovato un record di commit si sposta la transazione corrispondente nell’insieme di
REDO (viene rimossa da READY o da UNDO).
Se si trova un record abort e la transazione corrispondente si trova in READY, essa viene
tolta da
READY e messa in UNDO.
3) Se l’insieme READY non è vuoto, il sistema deve chiedere al TM (Transaction Manager) l’esito
delle transazioni di questo insieme, che si trovano in uno stato incerto. Il TM indica quali
transazioni hanno effettuato il commit e quali l’abort. Queste transazioni saranno quindi trasferite
negli insiemi di REDO o di UNDO e i rispettivi record scritti nel log.
10
Esercizi proposti a lezione cap. 6 – rev. nov. 2007 da Atzeni ed altri - Basi di dati vol. 2/2ed 2007
4) Il protocollo continua come in un sistema non distribuito.
Soluzione Esercizio n.5
1) Il log viene ripercorso all’indietro sino al record di checkpoint CK(T2,T3,T4) e si creano i tre
insiemi di UNDO, REDO e READY.
UNDO = { T2,T3,T4} REDO = {} READY = {}
2) Il record viene percorso in avanti, aggiornandogli insiemi.
B(T5)
B(T6)
R(T5)
B(T7)
UNDO = { T2,T3,T4,T5}
UNDO = { T2,T3,T4,T5,T6}
UNDO = { T2,T3,T4,T6}
UNDO = { T2,T3,T4,T6,T7}
REDO = {}
REDO = {}
REDO = {}
REDO = {}
B(T8)
A(T7)
R(T6)
UNDO = { T2,T3,T4,T6,T7,T8}
UNDO = { T2,T3,T4,T6,T7,T8}
UNDO = { T2,T3,T4 T7,T8}
REDO = {} READY = {T5}
REDO = {} READY = {T5}
REDO = {} READY = {T5,T6}
READY = {}
READY = {}
READY = {T5}
READY = {T5}
3) A questo punto dovremmo chiedere al Transaction Manager l’esito delle transazioni in
stato di READY. Supponendo che il TM indichi un global commit per T5 e T6 otteniamo:
UNDO = { T2,T3,T4, T7,T8} REDO = {T5,T6}
I record C(T5) e C(T6) sono scritti nel log.
4) Il record viene ripercorso all’indietro sino a D(T2,O2,B2), eseguendo le operazioni di
UNDO.
O6 = B6
O3 = B3
Insert O2 = B2
5) Infine il log viene percorso in avanti e vengono eseguite le operazioni di REDO.
O5 = A5
O1 = A7
Soluzione esercizio n.6
Con riferimento allo schema data base descritto nell' Esercizio 1., supponiamo che ciascun
frammento della tabella PRODUZIONE sia allocata a tutti i DBMS. Ciascun DBMS usa solo
11
Esercizi proposti a lezione cap. 6 – rev. nov. 2007 da Atzeni ed altri - Basi di dati vol. 2/2ed 2007
un frammento e trasmette tutte le variazioni di questo frammento agli altri DBMS In questa
maniera tutti i DBMS posseggono un intera copia del database.
Nel caso di guasto di uno dei DBMS il Database è ancora completamente accessibile dagli
altri sistemi:se tutte le query sono correttamente re-dirette, il guasto è trasparente al Cliente
del Database.
Tuttavia se si verifica un guasto della rete, questo può generare una partizione della rete, per
esempio con due sottoreti indipendenti.In questa situazione è possibile un'inconsistenza dei
dati : supponiamo che la tabella PRODUZIONE contiene una ennupla:
NumeroSerie
TipoParte
Modello
Qta
Macchina
12345
CPU
Pentium II
1000
A
se due transazioni volessero entrambe sottrarre 800 dalla quantità di questa parte, una delle
transazioni (la seconda in ordine temporale) fallirebbe, ma se le due transazioni sono presenti
i due differenti DBMS che non sono connessi, essi non falliranno ma produrranno
un'inconsistenza nel data base completo.
Soluzione esercizio n.7
Se nel contesto di una replicazione simmetrica, ciascun DBMS ha una copia dell'intero
DATABASE e può accedere ad essa completamente, allora le copie sono riconciliate.
Questa situazione può produrre lo stesso effetto di un singolo database senza il controllo di
concorrenza. Le due transazioni descritte nell' esercizio 4 possono produrre una
inconsistenza anche senza un guasto di rete se le variazioni non sono comunicate
immediatamente alle altre copie.
12
