Una transazione può essere definita come un gruppo di compiti. Un singolo compito è l’unità minima di elaborazione che non può essere suddivisa ulteriormente.
Facciamo un esempio di una semplice transazione. Supponiamo che un impiegato della banca trasferisca 500 Rs dal conto di A al conto di B. Questa transazione molto semplice e piccola coinvolge diversi compiti di basso livello.
Conto di A
Open_Account(A)Old_Balance = A.balanceNew_Balance = Old_Balance - 500A.balance = New_BalanceClose_Account(A)
Conto di B
Open_Account(B)Old_Balance = B.balanceNew_Balance = Old_Balance + 500B.balance = New_BalanceClose_Account(B)
Proprietà ACID
Una transazione è un’unità molto piccola di un programma e può contenere diversi compiti di basso livello. Una transazione in un sistema di database deve mantenere Atomicità, Consistenza, Isolamento e Durabilità – comunemente note come proprietà ACID – al fine di garantire l’accuratezza, la completezza e l’integrità dei dati.
-
Atomicità – Questa proprietà afferma che una transazione deve essere trattata come un’unità atomica, cioè, o vengono eseguite tutte le sue operazioni o nessuna. Non ci deve essere alcuno stato in un database in cui una transazione viene lasciata parzialmente completata. Gli stati dovrebbero essere definiti o prima dell’esecuzione della transazione o dopo l’esecuzione/interruzione/fallimento della transazione.
-
Consistenza – Il database deve rimanere in uno stato coerente dopo qualsiasi transazione. Nessuna transazione dovrebbe avere effetti negativi sui dati che risiedono nel database. Se il database era in uno stato coerente prima dell’esecuzione di una transazione, deve rimanere coerente anche dopo l’esecuzione della transazione.
-
Durabilità – Il database dovrebbe essere abbastanza durevole da mantenere tutti i suoi ultimi aggiornamenti anche se il sistema fallisce o si riavvia. Se una transazione aggiorna un pezzo di dati in un database e lo impegna, allora il database manterrà i dati modificati. Se una transazione si impegna ma il sistema fallisce prima che i dati possano essere scritti sul disco, allora quei dati saranno aggiornati una volta che il sistema torna in azione.
-
Isolamento – In un sistema di database dove più di una transazione viene eseguita simultaneamente e in parallelo, la proprietà di isolamento afferma che tutte le transazioni saranno effettuate ed eseguite come se fosse l’unica transazione nel sistema. Nessuna transazione influenzerà l’esistenza di qualsiasi altra transazione.
Serializzabilità
Quando più transazioni vengono eseguite dal sistema operativo in un ambiente di multiprogrammazione, ci sono possibilità che le istruzioni di una transazione siano intrecciate con qualche altra transazione.
-
Schedule – Una sequenza cronologica di esecuzione di una transazione è chiamata schedule. Una pianificazione può avere molte transazioni in essa, ciascuna comprendente un certo numero di istruzioni/task.
-
Serial Schedule – È una pianificazione in cui le transazioni sono allineate in modo tale che una transazione sia eseguita per prima. Quando la prima transazione completa il suo ciclo, allora viene eseguita la transazione successiva. Le transazioni sono ordinate una dopo l’altra. Questo tipo di schedulazione è chiamato schedulazione seriale, poiché le transazioni sono eseguite in modo seriale.
In un ambiente multi-transazione, le schedulazioni seriali sono considerate un punto di riferimento. La sequenza di esecuzione di un’istruzione in una transazione non può essere cambiata, ma due transazioni possono avere le loro istruzioni eseguite in modo casuale. Questa esecuzione non fa danni se due transazioni sono reciprocamente indipendenti e lavorano su diversi segmenti di dati; ma se queste due transazioni lavorano sugli stessi dati, allora i risultati possono variare. Questo risultato sempre variabile può portare il database ad uno stato incoerente.
Per risolvere questo problema, permettiamo l’esecuzione parallela di un programma di transazioni, se le sue transazioni sono serializzabili o hanno qualche relazione di equivalenza tra loro.
Schedulazioni di equivalenza
Una schedulazione di equivalenza può essere dei seguenti tipi –
Equivalenza di risultato
Se due schedulazioni producono lo stesso risultato dopo l’esecuzione, si dice che sono equivalenti di risultato. Possono produrre lo stesso risultato per qualche valore e risultati diversi per un altro insieme di valori. Ecco perché questa equivalenza non è generalmente considerata significativa.
Equivalenza di vista
Due programmi sarebbero equivalenti di vista se le transazioni in entrambi i programmi eseguono azioni simili in modo simile.
Per esempio –
-
Se T legge i dati iniziali in S1, allora legge anche i dati iniziali in S2.
-
Se T legge il valore scritto da J in S1, allora legge anche il valore scritto da J in S2.
-
Se T esegue la scrittura finale sul valore dei dati in S1, allora esegue anche la scrittura finale sul valore dei dati in S2.
Equivalenza di conflitto
Due programmi sono in conflitto se hanno le seguenti proprietà –
- Entrambi appartengono a transazioni separate.
- Entrambi accedono allo stesso elemento di dati.
- Almeno uno di essi è un’operazione “write”.
Due programmi che hanno più transazioni con operazioni in conflitto si dicono equivalenti se e solo se –
- Entrambi i programmi contengono lo stesso insieme di transazioni.
- L’ordine delle coppie di operazioni in conflitto è mantenuto in entrambi i programmi.
Nota – I programmi equivalenti sono serializzabili e i programmi equivalenti in conflitto sono serializzabili in conflitto. Tutti i programmi serializzabili in conflitto sono anche serializzabili alla vista.
Stati delle transazioni
Una transazione in un database può essere in uno dei seguenti stati –
-
Active – In questo stato, la transazione è in esecuzione. Questo è lo stato iniziale di ogni transazione.
-
Partially Committed – Quando una transazione esegue la sua operazione finale, si dice che è in uno stato parzialmente impegnato.
-
Failed – Una transazione si dice in uno stato di fallimento se uno qualsiasi dei controlli effettuati dal sistema di recupero del database fallisce. Una transazione fallita non può più procedere ulteriormente.
-
Aborted – Se uno dei controlli fallisce e la transazione ha raggiunto uno stato di fallimento, allora il recovery manager fa rollback di tutte le sue operazioni di scrittura sul database per riportare il database allo stato originale in cui era prima dell’esecuzione della transazione. Le transazioni in questo stato sono chiamate abortite. Il modulo di recupero del database può selezionare una delle due operazioni dopo che una transazione è abortita –
- Riavviare la transazione
- Cancellare la transazione
-
Committed – Se una transazione esegue tutte le sue operazioni con successo, si dice che è impegnata. Tutti i suoi effetti sono ora stabiliti in modo permanente sul sistema di database.