Una transazione è una qualunque unità di programma in esecuzione nell'ambito di un DBMS. Essa consiste in una "serie" di operazioni elementari indivisibili che devono essere eseguite in blocco; per esse vale, infatti la proprietà del "tutto o niente" meglio detta: atomicità. Un DBMS deve assicurare 4 proprietà fondamentali per garantire il corretto mantenimento e la consistenza dei dati a fronte di guasti o accessi concorrenti, queste 4 proprietà sono racchiuse nell'acronimo ACID.

ACID

• Atomicità: Come detto, tutte le operazioni elementari "statement" che costituiscono una singola transazione devono essere eseguite tutte. Se durante l'esecuzione di una qualsiasi transazione, si verificano delle eccezioni, la transazione viene "abortita", e il database viene riportato nello stato(consistente) - antecedente alla transazione stessa, si dice in gergo che si effettua il rollback.

• Consistenza: Ogni transazione deve portare il database da uno stato consistente ad un altro, deve preservarne la consistenza.

• Isolamento: L'isolamento garantisce che ogni utente veda le transazioni come singole, anche in presenta di accessi multipli. Questo fa si che le singole transazioni, pur essendo inframezzate vengano protette "isolate" dalle altre; è ciò apparentemente ci da una percezione univoca dell'esecuzione delle transazioni sul DBMS.

• Durabilità: Una volta che il DBMS attua una transazione, ne fa il committ, le modifiche sul database sono persistenti, non si può più tornare allo stato precedente, se non tramite altre transazioni.

Schedule

Uno schedule è sostanzialmente, una lista ordinata di statement di transazioni, che possono includere operazioni di committ letture, scritture ecc.. La cosa importante e che lo schedule descrive le operazioni dal punto di vista del DBMS, di conseguenza cio che è enfatizzato sono principalemte le sole read e le write ossia le letture e le scritture, ciò non esclude, però che in una transazione possano esserci anche operazioni aritmetiche, letture di file ecc.. Di seguito è riportato un esempio di schedule di due transazioni \( T_1 \) e \( T_2 \). Osservate che l'ordine delle singole transazioni nello schedule rimane inalterato.

$$ \begin{array}{c|c} {\Large T_{1}} & {\Large T_2} \\ \hline R(A) & \\ W(A) & \\ & R(B) \\ & W(B) \\ \end{array} $$

Serializzazione

Per qualche motivazione correlata all'efficienza dei sistemi, i DBMS, in particolare gli scheduler, inframezzano le sotto-istruzioni nelle transazioni. Uno schedule è detto serializzabile se ne esiste almeno uno che per qualunque DBMS produce lo stesso effetto di quello di partenza. Stabilire la serializzabilità è un'operazione piuttosto complessa; perciò esistono diverse condizioni sufficienti per la serializzabilità. Consideriamo ad esempio il seguente schedule che effettua degli spostamenti di denaro da un conto \(A\) ad un conto \(B\): $$ \begin{array}{c|c} {\Large T_{1}} & {\Large T_2} \\ \hline R(A) & \\ A = A - 100 &\\ W(A) & \\ & R(A) \\ & tmp = A * \frac{1}{2} \\ & A = A - tmp \\ & W(A) \\ R(B) & \\ B = B + 50 & \\ W(B) & \\ & R(B) \\ & B = B + tmp \\ & W(B) \end{array} $$ Se provate ad eseguire in "serie" prima \( T_1 \) e poi \( T_2 \), otterrete lo stesso risultato eseguendo le istruzioni inframezzate come in figura. Questo è un esempio di schedule serializzabile: l'esecuzione inframezzata è analoga all'esecuzione in serie degli statement che compongono le transazioni \( T_1, T_2 \).

Un'altra tipologia di schedule, usati nelle applicazioni sono gli schedule conflict-serializable, ossia "serializzabili per conflitto". L'idea consiste nello stabilire la serializzabilità attraverso una semplice condizione sufficiente sugli statement. Due statement sono in conflitto quando a seguito di uno scambio di ordine non sono assicurato che il risultato finale sia identico. Questo accade quando almeno uno dei due statement è una write. Non scambiare operazioni in conflitto è condizione sufficiente a garantire l'invarianza sul risultato.

Due schedule sono conflict-equivalent quando è possibile ottenere l'uno dall'altro attraverso una sequenza finita di scambi senza conflitto. Se uno schedule è conflict-equivalent ad uno schedule serializzabile (si può ottenere lo schedule serializzabile a seguito di una serie di scambi senza conflitto) esso si dice conflict-serializable.