ACID (din engleza atomicitate, consistență, izolare, durabilitate ) este un set de cerințe pentru un sistem tranzacțional care asigură funcționarea sa cea mai fiabilă și previzibilă - atomicitate , consistență , izolare , stabilitate ; formulată la sfârșitul anilor 1970 de Jim Gray [1] .
Setul de cerințe este considerat standardul de facto pentru sistemele extrem de fiabile, în primul rând SGBD-uri relaționale , în timp ce la mijlocul anilor 2000, pentru a construi SGBD-uri distribuite, se presupune că o parte din cerințele ACID vor fi abandonate (ceea ce se justifică prin utilizarea CAP ). teorema , teorema PACELC ) sau o reducere a severității cerințelor ( BASE ) .
Atomicitatea asigură că nicio tranzacție nu este parțial angajată în sistem. Fie vor fi executate toate suboperațiunile sale, fie niciuna dintre ele nu va fi executată. Deoarece în practică este imposibil să se efectueze simultan și atomic întreaga secvență de operațiuni în cadrul unei tranzacții, se introduce conceptul de „rollback” ( rollback ): dacă tranzacția nu poate fi finalizată complet, rezultatele tuturor acțiunilor efectuate până acum vor va fi anulat și sistemul va reveni la starea „inițială externă” - din exterior, se va părea că nu a existat nicio tranzacție (în mod firesc, contoarele, indexurile și alte structuri interne se pot schimba, dar dacă SGBD-ul este programat fără erori, acest lucru nu va afecta comportamentul său extern).
O tranzacție care ajunge la sfârșitul normal al tranzacției (EOT) și, prin urmare, își angajează rezultatele, menține consistența bazei de date. Cu alte cuvinte, fiecare tranzacție de succes, prin definiție, angajează doar rezultate valide. Această condiție este necesară pentru a susține a patra proprietate.
Consecvența este un concept mai larg. De exemplu, în sistemul bancar poate exista o cerință ca suma debitată dintr-un cont să fie egală cu suma creditată pe altul. Aceasta este o regulă de afaceri și nu poate fi garantată doar prin verificări de integritate, trebuie respectată de programatori atunci când scriu codul tranzacției. Dacă orice tranzacție debitează, dar nu creditează, sistemul va rămâne într-o stare incorectă și proprietatea de consistență va fi încălcată.
În sfârșit, încă o notă se referă la faptul că nu este necesară consecvența în timpul executării unei tranzacții . În exemplul nostru, debitarea și creditarea vor fi cel mai probabil două sub-operațiuni diferite, iar între execuția lor în cadrul tranzacției va fi vizibilă o stare inconsecventă a sistemului. Cu toate acestea, nu trebuie să uităm că, dacă cerința de izolare (vezi mai jos) este îndeplinită, această inconsecvență nu va fi vizibilă pentru nicio altă tranzacție. Iar atomicitatea garantează că tranzacția fie va fi complet finalizată, fie că nici una dintre operațiunile tranzacției nu va fi efectuată. Astfel, această inconsecvență intermediară este ascunsă.
În timpul executării unei tranzacții, tranzacțiile paralele nu ar trebui să afecteze rezultatul acesteia. Izolarea este o cerință costisitoare, așa că în bazele de date reale există moduri care nu izolează complet o tranzacție ( nivele de izolare care permit citiri fantomă și mai mici).
Indiferent de problemele de la nivelurile inferioare (de exemplu, o întrerupere de curent a sistemului sau defecțiuni hardware), modificările efectuate printr-o tranzacție finalizată cu succes ar trebui să rămână salvate după ce sistemul revine la funcționare. Cu alte cuvinte, dacă utilizatorul a primit confirmarea din partea sistemului că tranzacția a fost finalizată, poate fi sigur că modificările pe care le-a făcut nu vor fi anulate din cauza unui fel de eșec.
| Bază de date | |
|---|---|
| Concepte |
|
| Obiecte |
|
| Chei | |
| SQL |
|
| Componente | |