Sto leggendo le proprietà ACID di un database. Atomicità e Consistenza sembrano essere strettamente correlati. Mi chiedo se ci siano scenari in cui dobbiamo solo supportare l'Atomicità ma non la Consistenza o viceversa. Un esempio potrebbe davvero aiutare!Un database può supportare "Atomicity" ma non "Consistency" o viceversa?
Essi sono un po 'correlati ma c'è una sottile differenza.
Atomicità significa che la transazione si verifica o non si verifica.
Per coerenza si intende l'applicazione di integrità referenziale.
Diciamo che si avvia una transazione per aggiungere due righe (un credito e un debito che costituisce una singola transazione bancaria). L'atomicità di questo non ha nulla a che fare con la coerenza del database. Tutto ciò significa che verranno aggiunte entrambe le righe o nessuna riga.
Sul fronte della consistenza, supponiamo di avere un vincolo di chiave esterna da orders a products. Se si tenta di aggiungere un ordine che fa riferimento a un prodotto inesistente, è quando l'uniformità viene attivata per impedirne l'esecuzione.
Entrambi riguardano il mantenimento del database in uno stato lavorabile, quindi la loro somiglianza. L'esempio precedente garantirà che la banca non perda denaro (o che non rubi a te), quest'ultimo garantirà che la tua applicazione non venga sorpresa dagli ordini per prodotti di cui non sai nulla.
Atomicity:
In una transazione atomica, una serie di operazioni di database o tutti si verificano, o non accade nulla. Una garanzia di atomicità impedisce che gli aggiornamenti al database si verifichino solo parzialmente, , che possono causare problemi maggiori rispetto allo rifiutando l'intera serie a titolo definitivo.
Consistenza:
Nei sistemi di database, un consistente transazione è uno che non violare i vincoli di integrità durante la sua esecuzione. Se una transazione lascia il database in uno Stato illegale, è interrotta e un errore viene segnalato
un database che supporta atomicity ma non coerenza avrebbe permesso le transazioni che lasciano il database in uno stato incoerente (che è , violare i referenziali o altri controlli di integrità), a condizione che la transazione sia completata con successo. Ad esempio, è possibile aggiungere una stringa a una colonna int a condizione che la transazione che esegue questo sia stata completata correttamente.
Al contrario, un database che supporta la coerenza ma non l'atomicità consente il completamento di transazioni parziali, a condizione che gli effetti di tale transazione non interrompano alcun controllo di integrità (ad esempio, le chiavi esterne devono corrispondere a un'identità esistente). Ad esempio, potresti provare ad aggiungere una nuova riga che includeva valori stringa e int, e anche se l'inserimento falliva a metà perdendo metà dei dati, la riga sarebbe consentita a condizione che nessuno dei dati persi fosse per le colonne richieste e no i dati sono stati inseriti in una colonna erroneamente digitata.
Detto questo, la coerenza si basa sull'atomicità per l'inversione delle transazioni incoerenti.
: una transazione non può lasciare il database in uno stato che viola i vincoli dopo il suo completamento. Tuttavia, vi sono casi in cui una transazione viola temporaneamente vincoli, ma risolve la violazione prima del suo completamento. –
Grazie Graphain e Walter! – rkg
@WalterMitty: un database che supporta l'atomicità e la coerenza potrebbe consentire una transazione atomica le cui parti costituenti, se eseguite singolarmente, lascerebbero il database in uno stato incoerente.Non penso che un database che non supporta almeno alcune transazioni atomiche potrebbe consentire "incoerenze temporanee". Inoltre, mentre la possibilità di rinviare l'applicazione dei vincoli fino a quando un "commit" è certamente utile, non so che tale capacità sia implicita dal fatto che un particolare database supporta l'atomicità e la coerenza; Penso che il database Jet possa essere un controesempio. – supercat
Ho una diversa comprensione di coerenza nel contesto ACID:
all'interno di una transazione, se un determinato elemento di dati vengono recuperati e recuperato più tardi nella stessa transazione, nessun cambiamento è visto. Cioè, alla transazione viene dato uno stato consistente del database durante tutta la transazione. Gli unici aggiornamenti che possono modificare i dati visibili alla transazione sono gli aggiornamenti effettuati dalla transazione stessa.
Nella mia mente, questo equivale alla serializzabilità.
Mi sono anche confuso leggendo sulla consistenza di atomicità &. Diciamo che c'è uno scenario per inserire in batch 1000 record nella tabella degli account.
Atomicità del lotto è se tutti i 1000 record sono inseriti o nessuno dei record è inserito se c'è un errore.
Coerenza del lotto sarà violata se a livello di account di registrazione, abbiamo messo la logica di rendere l'inserto di successo, anche se il tipo di dati non corrisponde, record correlato è stato inserito nella tabella chiave esterna e più tardi cancellato dopo l'aggiornamento del record dell'account.
Speriamo che questo esempio chiarisca la confusione.
C'è infatti una forte relazione tra Atomicità e coerenza, ma non sono la stessa cosa:
Un DBMS può (teoricamente) sostenere coerenza e non Atomicity: per esempio, si consideri una transazione che consiste SQL operazioni O1, O2 e O3. Ora, supponiamo che dopo O1 e O2 il DB sia già in uno stato coerente. Quindi il DBMS può interrompere la transazione dopo O1 e O2 senza O3 e conserva ancora la coerenza. Chiaramente, tale DBMS non supporta l'atomicità (poiché O3 non è stato eseguito da O1 e O2 era).
Un DBMS può (teoricamente) supportare Atomicità e non Consistenza: questo può verificarsi in uno scenario multiutente, dove l'atomicità garantisce solo che tutte le azioni di una transazione vengano eseguite (o nessuna di esse) ma non garantire che le azioni di una transazione eseguite contemporaneamente a un'altra transazione non possano finire in uno stato incoerente.
Tuttavia, ciò che credo (ma non l'ho provata formalmente) è che se il DBMS garantisce sia Atomicità e isolamento, allora deve anche garantire la coerenza.
Grazie Paxdiablo! Correzione – rkg