Proprietà ACID
Le proprietà ACID (tradotto in acide in italiano), sono quattro proprietà fondamentali che le transazioni devono godere per eseguire operazioni sulla base di dati in maniera corretta e sicura.
L'acronimo è coniato per la prima volta da Andreas Reuter and Theo Härder nel 1983[1].
Il nome deriva dalle iniziali delle proprietà:
- Atomicity
- Consistency
- Isolation
- Durability
Le sottolezioni Controllo di concorrenza e Controllo di affidabilità spiegano il funzionamento dei componenti del DBMS che garantiscono le suddette proprietà.
Atomicità[modifica]
L'atomicità di una transazione è la sua proprietà di essere eseguita in modo atomico, cioè con un approccio "tutto o niente". I suoi effetti sulla base di dati devono essere resi visibili del tutto (cioè al termine della transazione) oppure nessun effetto deve essere mostrato. Questa proprietà è garantita dal DBMS attraverso la sua capacità di annullare (operazione di UNDO) una transazione che ha subito un ABORT prima del commit, e la sua capacità di rifare (operazione di REDO) una transazione che è incorsa in un errore dopo il commit. L'ABORT può essere causato da:
- omicidio: la transazione viene terminata dal sistema per vari motivi (violazione di vincoli, guasto del sistema, ecc.);
- suicidio: la transazione raggiunge un'istruzione ROLLBACK, quindi richiede l'annullamento degli effetti prodotti da se stessa.
In questo modo l'istruzione COMMIT fissa in modo definitivo e indivisibile il momento in cui la transazione ha avuto successo, quindi se essa avrà o meno effetto sulla base di dati.
Consistenza[modifica]
La consistenza di una transazione è la sua capacità di non violare i vincoli referenziali e di integrità della base di dati. Una transazione che violi questi vincoli deve essere abortita e i suoi effetti annullati. Questo controllo può essere eseguito per via immediata, se fatto direttamente sulla singola istruzione della transazione, oppure per via differita se effettuato al termine della transazione (cioè al raggiungimento del comando di COMMIT).
La consistenza deve essere inoltre garantita dopo l'esecuzione di trigger e altri eventi immediatamente successivi al commit della transazione (altrimenti l'intera transazione deve essere annullata). I trigger verranno analizzati in dettaglio nella lezione sulle Regole attive per basi di dati.
Isolamento[modifica]
L'isolamento è la garanzia che il DBMS esegua le transazioni in maniera indipendente ed isolata, in particolare che non interferiscano tra di loro se l'esecuzione è contemporanea. Questa proprietà deve essere garantita anche in caso qualche transazione effettui ROLLBACK, senza che le altre ne siano influenzate.
L'isolamento è garantito se l'esecuzione di transazioni in contemporanea genera lo stesso effetto sulla base di dati che avrebbero se venissero eseguite in maniera sequenziale. Il componente del DBMS che si occupa di garantire questa proprietà è il controllore di concorrenza.
Persistenza[modifica]
La persistenza si ottiene garantendo che l'effetto delle transazioni che hanno eseguito con successo l'istruzione COMMIT sia mantenuta per sempre nel database, anche in caso di guasti e malfunzionamenti. Idealmente la persistenza deve essere assicurata anche in caso di eventi catastrofici, come incendi o allagamenti, oltre che a mancanze di alimentazione. Ovviamente questo goal può essere raggiunto solo distribuendo la base di dati in più server farm (e il DBMS deve essere in grado di gestirle).
Il componente del DBMS che si occupa di garantire questa proprietà è il controllore di affidabilità.
Note[modifica]
- ↑ Haerder, T.; Reuter, A., Principles of transaction-oriented database recovery, ACM Computing Surveys, 1983.
Altri progetti[modifica]
Wikipedia contiene informazioni su Proprietà ACID
