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
(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 sotto- transazioni 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.
SOLUZIONE Esercizio 1
Ia PARTEFrammentazione 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 VENDITOREVENDITORE_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
(Napoli.Azienda.it)
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 PRODUZIONE_1@Torino.Azienda.it where NumeroSerie = “77Y6878”
if :empty then
select Qta into :Quan
from PRODUZIONE_2@Milano.Azienda.it where NumeroSerie = “77Y6878”
if :empty then
select Qta into :Quan
from PRODUZIONE_3@Roma.Azienda.it where NumeroSerie = “77Y6878”
if :empty then
select Qta into :Quan
from PRODUZIONE_4@Napoli.Azienda.it where NumeroSerie = “77Y6878”
end Procedure
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 PRELIEVO_1@Torino.Azienda.it where Venditore =”Bianchi”
if :empty then
select Cliente into :Cl
from PRELIEVO_2@Milano.Azienda.it where Venditore =”Bianchi”
if :empty then
select Cliente into :Cl
from PRELIEVO_3@Roma.Azienda.it where Venditore =”Bianchi”
if :empty then
select Cliente into :Cl
from PRELIEVO_4@Napoli.Azienda.it where Venditore =”Bianchi”
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 PRODUZIONE_1@Torino.Azienda.it
join PRELIEVO_1@Torino.Azienda.it 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
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 CLIENTE_3@Roma.Azienda.it where Nome = “Rossi”;
insert into CLIENTE_2@Milano.Azienda.it (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 PRELIEVO_3 union PRELIEVO_4 select Citta, sum(Ammontare)
from PRELIEVO join VENDITORE_1 on Venditore = Nome group by Città
union
select Citta, sum(Ammontare)
from PRELIEVO join VENDITORE_2 on Venditore = Nome group by Città
union
select Citta, sum(Ammontare)
from PRELIEVO join VENDITORE_3 on Venditore = Nome group by Città
end Procedure
Trasparenza di linguaggio:
Procedure Ordini2
create view PRELIEVO as
PRELIEVO_1@Torino.Azienda.it union PRELIEVO_2@Milano.Azienda.it union
PRELIEVO_3@Roma.Azienda.it union PRELIEVO_4@Napoli.Azienda.it select Citta, sum(Ammontare)
from PRELIEVO join VENDITORE_1@Torino.Azienda.it 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 VENDITORE_3@Roma.Azienda.it 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”
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.
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) UNDO = { T2,T3,T4,T5} REDO = {} READY = {}
B(T6) UNDO = { T2,T3,T4,T5,T6} REDO = {} READY = {}
R(T5) UNDO = { T2,T3,T4,T6} REDO = {} READY = {T5} B(T7) UNDO = { T2,T3,T4,T6,T7} REDO = {} READY = {T5} B(T8) UNDO = { T2,T3,T4,T6,T7,T8} REDO = {} READY = {T5} A(T7) UNDO = { T2,T3,T4,T6,T7,T8} REDO = {} READY = {T5} R(T6) UNDO = { T2,T3,T4 T7,T8} REDO = {} READY = {T5,T6} 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
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.
