ACID: differenze tra le versioni

Versione delle 00:44, 14 mag 2015

Versione attuale delle 19:11, 22 giu 2025

(47 versioni intermedie di 31 utenti non mostrate)

Riga 1:

{{Nota disambigua|lail paginasoftware|ACID di test per i [[browser]] webPro|[[Acid1]], [[Acid2]] o [[Acid3]]}}

{{portaleNN|informatica|marzo 2024}}

Nell'ambito dei [[database]], '''ACID''' deriva dall'acronimo inglese '''Atomicity''', '''Consistency''', '''Isolation''', e '''Durability''' ('''A'''tomicità, '''C'''onsistenza, '''I'''solamento e '''D'''urabilità) ed indica le proprietà logiche che devono avere le [[transazione (basi di dati)|transazioni]].

{{S|sistema operativo}}

Nell'ambito dei [[database]], '''ACID''' è un [[acronimo]] che riassume quattro proprietà particolarmente desiderabili in un [[DBMS]], ovvero: '''A'''tomicità, '''C'''oerenza, '''I'''solamento e '''D'''urabilità ({{lett|Atomicity, Consistency, Isolation, and Durability|lingua=en}}). Queste vengono tipicamente soddisfatte attraverso l'[[implementazione]] del meccanismo delle [[transazione (basi di dati)|transazioni]].

Perché le transazioni operino in modo corretto sui dati è necessario che i meccanismi che le implementano soddisfino queste quattro proprietà:

* '''atomicità''': la transazione è indivisibile nella sua esecuzione e la sua esecuzione deve essere o totale o nulla, non sono ammesse esecuzioni parziali;

* '''consistenza''': quando inizia una transazione il database si trova in uno stato consistente e quando la transazione termina il database deve essere in un altro stato consistente, ovvero non deve violare eventuali [[vincolo di integrità|vincoli di integrità]], quindi non devono verificarsi contraddizioni (''inconsistenza'') tra i dati archiviati nel DB;

* '''isolamento''': ogni transazione deve essere eseguita in modo isolato e indipendente dalle altre transazioni, l'eventuale fallimento di una transazione non deve interferire con le altre transazioni in esecuzione;

* '''durabilità''': detta anche '''persistenza''', si riferisce al fatto che una volta che una transazione abbia richiesto un ''commit work'', i cambiamenti apportati non dovranno essere più persi. Per evitare che nel lasso di tempo fra il momento in cui la base di dati si impegna a scrivere le modifiche e quello in cui li scrive effettivamente si verifichino perdite di dati dovuti a malfunzionamenti, vengono tenuti dei registri di log dove sono annotate tutte le operazioni sul DB.

== Descrizione ==

Nei sistemi di [[DBMS]] le [[transazione (basi di dati)|transazioni]] vengono processate dal [[transaction processing]]. Una [[query]] (ovvero un'interrogazione alla base di dati) ed altre azioni vengono raggruppate in una transazione che deve essere eseguita ''atomicamente'', isolatamente dalle altre e comportando eventualmente una modifica permanente del database. Tale comportamento è assicurato dal

=== Atomicità ===

* '''Concurrency Control Manager''' o '''WorkSpace Privato''' che garantisce l'atomicità e isolamento

* '''Logging / Recovery Manager''' che garantisce la durabilità e coerenza.

Il processo deve essere suddivisibile in un numero finito di unità indivisibili, chiamate ''transazioni''. L'esecuzione di una transazione perciò deve essere per definizione o totale o nulla, e non sono ammesse esecuzioni parziali; un processo, anche parziale, invece, in quanto insieme di transazioni può non essere elementare.

=== Coerenza ===

Il database rispetta i [[vincolo di integrità|vincoli di integrità]], sia a inizio che a fine transazione. Non devono verificarsi contraddizioni (incoerenza dei dati) tra i dati archiviati.

=== Isolamento ===

* '''isolamento''': ogniOgni transazione deve essere eseguita in modo isolato e indipendente dalle altre transazioni, l'eventuale fallimento di una transazione non deve interferire con le altre transazioni in esecuzione;.

== Isolamento ==

Sono previsti quattro livelli di isolamento:

# ''' read uncommitted''':

#* consente transazioni in sola lettura, senza bloccare in lettura i dati

#* una transazione può leggere dati ''sporchi'', perché potrebbero sparire se la transazione che li ha generati abortisce

#:<tt> Esempi:

#: T1 aggiorna una riga r1

#: * T2 accede a r1

#: * T1 termina con un rollback

#: * T2 ha avuto accesso ad un dato che non è mai esistito </tt>

# '''read committed:'''

#* prevede il rilascio immediato dei dati in lettura, ritardando quelli in scrittura

#* letture non ripetibili all'interno della stessa transazione

# '''repeatable read:'''

#* vengono bloccati sia i dati in lettura che quelli in scrittura ma solo sulle ennuple della tabella coinvoltecoinvolta

#* genera il fenomeno dei fantasmi (phantoms)

# '''serializable:'''

#: Potrebbe garantitiregarantire l'effettiva serializzabilità del codice bloccando gli accessi alle tabelle in gioco, tuttavia si tratta di soluzioni troppo inefficienti per essere utilizzate in applicazioni critiche, in realtà la modalità serializzata si limita a evitare i fenomifenomeni esaminati per i livelli più bassi di isolamento.

=== Durabilità ===

== Concurrency Control Manager o WorkSpace Privato ==

* '''durabilità''': dettaDetta anche '''"persistenza'''", si riferisce al fatto che una volta che una transazione abbia richiesto un ''commit work'', i cambiamenti apportati non dovranno essere più persi. Per evitare che nel lasso di tempo fra il momento in cui la base di dati si impegna a scrivere le modifiche e quello in cui lile scrive effettivamente si verifichino perdite di dati dovuti a malfunzionamenti, vengono tenuti dei registri di log dove sono annotate tutte le operazioni sul DB.

La transazione effettua le modifiche su una copia della risorsa database. Se essa non termina con successo la copia viene distrutta, altrimenti le modifiche fatte sulla copia vengono rese permanenti attraverso l'operazione di commit. Il sistema ne garantisce in questo modo l'''atomicità''.

Le transazioni devono essere eseguite in isolamento le une dalle altre ma spesso molte transazioni vengono eseguite concorrentemente nello stesso sistema. Il concurrency control manager si assicura che le singole azioni delle varie transazioni vengano eseguite in un ordine tale da non interferire le une con le altre (''isolamento'').

Il Concurrency Control Manager viene realizzato tramite due istruzioni primitive:

* '''lock''', istruzione tramite la quale si afferma che una risorsa è bloccata da una determinata transazione;

* '''unlock''', istruzione tramite la quale si afferma che una risorsa è stata liberata da una determinata transazione.

La serie dei lock viene memorizzata nella lock table (sezione del DBMS apposita). Il concurrency control manager ha anche il compito di risolvere i [[deadlock]] causati dai lock facendo abortire una o più transazioni.

Per prevenire i lock e gestire al meglio le transazioni si introduce il concetto di scheduler. Lo scheduler ha il compito di garantire l'isolamento, accogliere una transazione ed assegnarle un identificatore unico, chiedere al buffer manager del DBMS di leggere/scrivere sul database secondo una particolare sequenza.

== Logging / Recovery Manager ==

Per assicurare '''persistenza''' dei dati del database anche in caso di crash (p.e. stalli nell'accesso delle transazioni alla risorsa), ogni modifica al database viene registrata separatamente sul disco.

Il log manager registra queste modifiche per consentire in qualsiasi momento (in seguito ad un crash) al recovery manager di ripristinare il database in uno stato consistente.

Il ''log manager'' scrive i suoi dati attraverso il Buffer Manager ma prima di continuare si assicura che siano stati effettivamente scritti su disco. ''Timestamping'' associa ad ogni transazione e ad ogni risorsa una marca temporale con la quale consentire e controllare l'accesso delle transazioni alle risorse del database.

== Bibliografia ==

* {{cita libro|autore = Paolo Atzeni|autore2 = Stefano Ceri|autore3 = Piero Fraternali|autore4 = Stefano Paraboschi|autore5 = Riccardo Torlone|titolo = Basi di dati|editore = McGraw-Hill|anno = 2018|edizione = 5|città = Milano|ISBN = 978-88-386-9445-5|cid = Atzeni 2018}}

* {{cita libro|titolo = Dictionary of E-Business|editore = Wiley|città = Hoboken|anno = 2003|lingua = inglese|capitolo = ACID (Atomicity, Consistency, Isolation, and Durability.)}}

* {{cita libro|autore = Francis Botto|titolo = Dictionary of Multimedia and Internet Applicationse‐Business: A Definitive Guide forto DevelopersTechnology and UsersBusiness Terms|url = https://archive.org/details/dictionaryofebus00bott|editore = Wiley|città = Hoboken|anno = 19992003|lingua = ingleseen|capitolodoi = ACID (Atomicity, Consistency, Isolation, and= 10.1002/0470861886|ISBN = Durability)9780470844700}}

* {{cita libro|autore = Francis Botto|titolo = Dictionary of Multimedia and Internet Applications: A Guide for Developers and Users|url = https://archive.org/details/isbn_9780471986249|editore = Wiley|città = Hoboken|anno = 1999|lingua = en|ISBN = 9780471986249}}

== Altri progetti ==

{{interprogetto|v=Proprietà ACID}}

== Collegamenti esterni ==

{{portale|informatica}}

* {{FOLDOC}}

{{Portale|informatica}}

[[Categoria:Teoria delle basi di dati]]