vault backup: 2025-02-05 12:19:57

basi di dati 1/16 - file con indice.md

@@ -125,4 +125,13 @@ Visto che non si può mantenere il file principale ordinato, se si vuole seguire
 Per alcune operazioni può essere utile definire altri indici oltre alla chiave primaria - ma come si tiene un doppio indice?
 Invece di un modello a **indice sparso** (come quello visto sopra, con un record per ogni blocco del file principale), si può usare un **indice denso** --> un record indice per ogni *record* del file principale - così, si può mantenere un ordinamento per entrambi (non avrei potuto ordinare blocchi sia per la chiave primaria che per una secondaria).
 
-![[indice-denso.jpeg|center|400]]
+![[indice-denso.jpeg|center|400]]
+
+## domande orale
+>[!question] possibili domande orale 
+>- struttura ISAM
+>- ricerca binaria e interpolazione
+>- nella ricerca binaria, devo o non devo considerare il blocco corrente quando rifaccio la divisione?
+>- costo operazioni
+>- ISAM con record puntati - come funziona? costo operazioni? (non so se l'abbia mai chiesto)
+>- indice sparso e indice denso

basi di dati 1/17 - B-tree.md

@@ -152,4 +152,9 @@ Quindi, il limite superiore dell'altezza dell'albero è $\log_{d}\left( \frac{N}
 >$$BI=B_{1}+B_{2}+B_{3}+B_{4}=2464+108+5+1=2578$$
 >blocchi.
 > 
->Il costo della ricerca sarà $5$ (un blocco per ognuno dei $4$ livelli di indice $+1$ blocco per il file principale)
+>Il costo della ricerca sarà $5$ (un blocco per ognuno dei $4$ livelli di indice $+1$ blocco per il file principale)
+## domande orale
+>[!question] possibili domande orale 
+>- struttura B-tree
+>- costo operazioni
+>- quando ha altezza massima? quant'è l'altezza massima?

basi di dati 1/18 - Il controllo della concorrenza.md

@@ -35,7 +35,7 @@ Visto che quando un item viene letto, esso viene portato nella memoria centrale
 - se un'altra transazione leggerà lo stesso dato, lo porterà nella sua propria zona di memoria - avremmo quindi due copie dello stesso dato che verranno modificate, e potremmo avere dati sbagliati (una sovrascriverà l'altra)
 
 I possibili problemi sono:
-- **ghost update**
+- **lost/ghost update**
 - **dato sporco**
 - **aggregato non corretto**
 
@@ -55,6 +55,7 @@ Avviene quando si perde un aggiornamento di un dato.
 >Invece, con questo schedule, otteniamo $X_{0}-N+M$.
 >- l'aggiornamento di $X$ prodotto da $T_{1}$ viene quindi perso
 
+(risolto dal [[19 - il meccanismo di lock, lock binario|lock binario]])
 ### dato sporco (rollback a cascata)
 Avviene quando un valore è il risultato di una transazione fallita (che va quindi "annullata")
 
@@ -63,6 +64,7 @@ Avviene quando un valore è il risultato di una transazione fallita (che va quin
 >  
 > A causa dell'atomicità delle transazioni, se $T_{1}$ fallisce, il valore di $X$ deve essere riportato a quello iniziale (quindi il `write` di $T_{2}$ dovrebbe dare risultato $X_{0}+M$ - ma, visto che $T_{2}$ ha usato il dato sporco prima del fallimento di $T_{1}$, il risultato sarà $X_{0}-N+M$)
 
+(risolto dal [[20 - deadlock e livelock, lock a due fasi stretto#locking a due fasi stretto|locking a due fasi stretto]])
 ### aggregato non corretto
 Avviene quando l'ordine delle operazioni fa sì che alcuni dati vengano processati dopo le operazioni che li richiedono.
 
@@ -71,6 +73,7 @@ Avviene quando l'ordine delle operazioni fa sì che alcuni dati vengano processa
 >
 > La somma $Y:= Y+N$ viene eseguita dopo $somma := somma + Y$, quindi in $somma$ mancherà $N$.
 
+risolto dal [[19 - il meccanismo di lock, lock binario|locking a due fasi]]
 ## serializzabilità
 - *tutti gli schedule seriali sono corretti*
 
@@ -111,4 +114,13 @@ Gli "oggetti" della base di dati si chiamano **item** - possono essere tabelle,
 
 Le dimensioni degli item utilizzate da un sistema sono dette la sua **granularità**.
 - una granularità grande permette una gestione efficiente della concorrenza
-- una granularità piccola può sovraccaricare il sistema, ma aumenta il livello di concorrenza (consente l'esecuzione concorrente di molte transizioni)
+- una granularità piccola può sovraccaricare il sistema, ma aumenta il livello di concorrenza (consente l'esecuzione concorrente di molte transizioni)
+
+## domande orale
+>[!question] possibili domande orale 
+>- cos'è una transazione?
+>- per cosa sta ACID/quali sono le proprietà delle transazioni?
+>- cos'è uno schedule? cos'è uno schedule serializzabile?
+>- che problemi possono sorgere nel controllo della concorrenza?
+>- cosa vuol dire schedule serializzabile?
+>- cos'è un item?

basi di dati 1/19 - il meccanismo di lock, lock binario.md

@@ -37,7 +37,7 @@ Attraverso il lock binario risolviamo il primo dei problemi visti: la *perdita d
 
 ### equivalenza, serializzabilità
 La proprietà di equivalenza degli schedule dipende dal protocollo di locking adottato - vediamo il caso del locking binario.
-- serve adottare un modello di transazioni che *sia astragga dalle specifiche operazioni* e si basi su quelle rilevanti, per valutare le *sequenze degli accessi* (lock e unlock)
+- serve adottare un modello di transazioni che *si astragga dalle specifiche operazioni* e si basi su quelle rilevanti, per valutare le *sequenze degli accessi* (lock e unlock)
 
 Una transazione viene quindi interpretata come sequenza di `lock` e `unlock`:
 - ogni `lock(X)` implica la lettura di `X`
@@ -98,7 +98,7 @@ Esiste un algoritmo per testarla:
 > Uno schedule $S$ è serializzabile se e solo se il suo grafo di serializzazione è aciclico.
 
 >[!example]- esempio
-per esempio, tracciamo archi tra le transizioni di questo codice:
+> per esempio, tracciamo archi tra le transizioni di questo codice:
 >
 >![[codice-grafo.png|center|300]]
 >![[grafo-codice.png|center|300]]
@@ -120,6 +120,18 @@ Una transazione obbedisce al protocollo di locking a due fasi se:
 >
 >![[dim-due-fasi.png|center|200]]
 >
->Entriamo subito in una contraddizione: infatti, il ciclo si chiude solo nel caso una transizione $T_{k}$ abbia fatto un unlock e, subito dopo, $T_{1}$ un lock. Ma questo non è possibile se ogni transazione è a due fasi --> abbiamo dimostrato che due fasi $\implies$ ogni schedule serializzabile
+>Entriamo subito in una contraddizione: infatti, il ciclo si chiude solo nel caso una transizione $T_{k}$ abbia fatto un unlock e, subito dopo, $T_{1}$ un lock. Ma questo non è possibile se ogni transazione è a due fasi ($T_{1}$ ha già chiesto i suoi lock).
+> Ovvero, due fasi $\implies$ ogni schedule serializzabile
 ### vantaggi
-Il lock a due fasi **risolve il problema dell'aggregato non corretto** (una transazione $T_{2}$ non ha accesso ai dati `locked` di $T_{1}$ fino a quando essa non li rilascia, e $T_{1}$ legge prima tutti i dati di cui ha bisogno, e poi li usa)
+Il lock a due fasi **risolve il problema dell'aggregato non corretto** (una transazione $T_{2}$ non ha accesso ai dati `locked` di $T_{1}$ fino a quando essa non li rilascia, e $T_{1}$ legge prima tutti i dati di cui ha bisogno, e poi li usa)
+## domande orale
+>[!question] possibili domande orale 
+> - cos'è un lock?
+> - quando uno schedule si dice legale?
+> - come funziona il lock binario?
+> - quando uno schedule che usa lock binario è serializzabile?
+> - come si testa la serializzabilità? (nel caso di lock binario)
+> - cosa risolve il lock binario?
+> - cos'è il locking a due fasi?
+> - dimostrazione due fasi $\implies$ serializzabile
+> - cosa risolve il locking a due fasi?

basi di dati 1/20 - deadlock e livelock.md → basi di dati 1/20 - deadlock e livelock, lock a due fasi stretto.md

@@ -3,10 +3,12 @@ Un **deadlock** si verifica quando:
 - ogni transazione in un insieme $T$ è in attesa di ottenere un lock su un item sul quale qualche altra transazione dell'insieme detiene un lock, 
 - quindi ogni transazione rimane bloccata, non rilascia i propri lock, e può bloccare anche transazioni che non sono in $T$
 
+> [!info] grafo d'attesa
+> Per verificare il sussistere di una situazione di stallo, si mantiene il **grafo d'attesa**, che ha come
+> - **nodi**: le transazioni
+> - **archi**: c'è un arco $T_{1}\to T_{2}$ quando la transazione $T_{1}$ è in attesa di ottenere un lock su un item su cui $T_{2}$ mantiene un lock
+
 ### soluzioni risolutive
-Per verificare il sussistere di una situazione di stallo, si mantiene il **grafo d'attesa**, che ha come
-- **nodi**: le transazioni
-- **archi**: c'è un arco $T_{1}\to T_{2}$ quando la transazione $T_{1}$ è in attesa di ottenere un lock su un item su cui $T_{2}$ mantiene un lock
 
 #### roll-back
 Per risolvere il sussistere di una situazione di stallo, una transazione nel ciclo viene *rolled-back* e successivamente fatta ripartire.
@@ -54,9 +56,9 @@ Per risolvere questo problema, quindi, serve che le transazioni obbediscano a re
 
 ## locking a due fasi stretto
 Una transazione soddisfa il protocollo di locking a due fasi stretto se:
-1) non scrive sulla base di dati fino a quando non ha raggiunto il suo punto di commit 
+1) **non scrive** sulla base di dati fino a quando non ha **raggiunto il suo punto di commit** 
 	- questo assicura che, se una transazione viene abortita, non ha modificato nessun item nella base di dati
-2) non rilascia un lock finché non ha finito di scrivere sulla base di dati
+2) **non rilascia** un lock finché non ha **finito di scrivere** sulla base di dati
 	- in questo modo, se una transazione legge un item scritto da un'altra transazione, quest'ultima sarà sicuramente una transazione che non può essere abortita
 
 > [!example] esempio
@@ -91,3 +93,13 @@ La scelta tra protocolli conservativi e aggressivi si basa principalmente sulla
 Se essa è
 - **alta** --> conviene un protocollo *conservativo*, che evita il sovraccarico dovuto alla gestione del deadlock (rilevarlo, risolvere lo stallo, eseguire parzialmente transazioni che poi verranno abortite, rilascio dei lock)
 - **bassa** --> conviene un protocollo *aggressivo*, che evita il sovraccarico dovuto alla gestione dei lock (decidere se garantire un lock, gestire la tavola dei lock, mettere e togliere transazioni da una coda)
+## domande orale
+>[!question] possibili domande orale 
+>- quando si verifica un deadlock? e un livelock?
+>- come si verifica il sussistere di una situazione di stallo?
+>- quali sono le soluzioni risolutive e gli approcci preventivi per il deadlock?
+>- come si risolve il livelock?
+>- quando avviene l'abort di una transazione?
+>- come funziona il locking a due fasi stretto?
+>- cosa risolve il locking a due fasi stretto?
+>- protocolli conservativi e aggressivi

basi di dati 1/21 - timestamp.md

@@ -56,13 +56,15 @@ Ogni volta che una transazione $T$ cerca di eseguire un `read(X)` o un `write(X)
 T cerca di eseguire una `write(X)`.
 1. se $read\_TS(X)>TS(T)$ (ovvero se una transazione più giovane l'ha già letta) $X$ viene rolled back
 2. se $write\_TS(X)>TS(T)$, invece di fare un rollback, semplicemente non si effettua l'operazione di scrittura <small>(ignorando l'atomicità)</small>
+	- (vuol dire che una transazione più giovane ha già scritto)
 3. se nessuna delle condizioni precedenti è soddisfatta, allora:
 	- si esegue `write(X)` e si sovrascrive il write timestamp di $X$: $write\_TS(X):= TS(T)$
 
 ###### lettura:
 T cerca di eseguire una `read(X)`.
-1. se $write\_TS(X)>TS(T)$, $T$ viene rolled back
-2. se $write\_TS(X)\leq TS(T)$, allora:
+
+1) se $write\_TS(X)>TS(T)$, $T$ viene rolled back
+2) se $write\_TS(X)\leq TS(T)$, allora
 	- si esegue `read(X)` e, se $read\_TS(X)<TS(T)$, si sovrascrive: $read\_TS(X):= TS(T)$
 
 >[!example] esempio 1
@@ -91,12 +93,17 @@ Notiamo che lo schedule delle transazioni superstiti è equivalente allo schedul
 >[!bug] ignorare l'atomicità
 >Perché possiamo **ignorare l'[[18 - Il controllo della concorrenza#transazioni|atomicità]]** saltando l'operazione di scrittura di una transazione $T$? 
 >L'atomicità serve a garantire la *coerenza* in una base di dati. 
->Le transazioni che potrebbero trovare una situazione incoerente (a causa della non-scrittura) sono quelle che avrebbero dovuto leggere i dati scritti da $T$ (e si sarebbero ritrovate invece i dati di una transazionie più giovane $T'$) 
+>Le transazioni che potrebbero trovare una situazione incoerente (a causa della non-scrittura) sono quelle che avrebbero dovuto leggere i dati scritti da $T$ (e si sarebbero ritrovate invece i dati di una transazione più giovane $T'$) 
 > - ma non esiste una transazione $T''$ arrivata dopo $T$ ma prima di $T'$ (con $TS(T')>TS(T'')>TS(T)$) che ha letto il dato: altrimenti, $T$ sarebbe stata rolled-back <small>(avrebbe cercato di scrivere quando una transazione più giovane aveva già letto)</small>.
-> - se poi dovesse arrivare una transazione $T''$ che vuole leggere il valore di $X$, questa sarebbe rolled back per il primo passo dell'algoritmo di controllo della lettura (troverebbe $write\_TS(X)$ maggiore del proprio)
+> - se poi dovesse arrivare $T''$ che vuole leggere il valore di $X$, questa sarebbe rolled back per il primo passo dell'algoritmo di controllo della lettura (troverebbe $write\_TS(X)$ maggiore del proprio perché scritto da $T'$)
 
 >[!question]- perché non il timestamp dell'ultima transazione?
 >![[timestamp-domanda.png|center|400]]
 >
 >Prendiamo come esempio questo caso, con i timestamp $T1<T2<T3$.
->Se il write timestamp e il read timestamp fossero quelli dell'ultima transazione anziché della più giovane, $T2$ scriverebbe il valore di un item ($X$) già letto da $T3$, quando $T3$ avrebbe dovuto leggere il valore di $T2$.
+>Se il write timestamp e il read timestamp fossero quelli dell'ultima transazione anziché della più giovane, $T2$ scriverebbe il valore di un item ($X$) già letto da $T3$, quando $T3$ avrebbe dovuto leggere il valore di $T2$.
+
+## domande orale
+>[!question] possibili domande orale 
+>- come funziona il timestamp?
+>- quando una transazione c

basi di dati 1/basi di dati 1.md

@@ -18,5 +18,7 @@
 > - [[17 - B-tree]]
 > - [[18 - Il controllo della concorrenza]]
 > - [[19 - il meccanismo di lock, lock binario]]
-> - [[20 - deadlock e livelock]]
-> - [[21 - timestamp]]
+> - [[20 - deadlock e livelock, lock a due fasi stretto]]
+> - [[21 - timestamp]]
+>
+>([[99 - domande orale, raccolte]])