ACID (z anglického atomicity, konzistence, izolace, trvanlivost ) je soubor požadavků na transakční systém , který zajišťuje jeho nejspolehlivější a předvídatelný provoz - atomicita , konzistence , izolace , stabilita ; formuloval koncem 70. let Jim Gray [1] .
Soubor požadavků je považován za de facto standard pro vysoce spolehlivé systémy, především relační DBMS , zatímco v polovině 2000 se při budování distribuovaných DBMS předpokládá, že část požadavků ACID bude opuštěna (což je odůvodněné použitím CAP teorém , PACELC teorém ) nebo snížení závažnosti požadavků ( BASE ) .
Atomicita zajišťuje, že žádná transakce není částečně zavázána systému. Buď budou provedeny všechny jeho dílčí operace, nebo nebude provedena žádná z nich. Protože v praxi není možné současně a atomicky provádět celou sekvenci operací v rámci transakce, zavádí se pojem „rollback“ ( rollback ): pokud transakci nelze zcela dokončit, výsledky všech jejích dosud provedených akcí budou bude zrušeno a systém se vrátí do „externě počátečního“ stavu - zvenčí se bude zdát, že nedošlo k žádné transakci (přirozeně se mohou změnit čítače, indexy a další vnitřní struktury, ale pokud je DBMS naprogramován bez chyb, to neovlivní jeho vnější chování).
Transakce, která dosáhne svého normálního konce transakce (EOT), a tím potvrdí své výsledky, zachovává konzistenci databáze. Jinými slovy, každá úspěšná transakce podle definice potvrzuje pouze platné výsledky. Tato podmínka je nezbytná pro podporu čtvrté vlastnosti.
Konzistence je širší pojem. Například v bankovním systému může existovat požadavek, aby se částka odepsaná z jednoho účtu rovnala částce připsané na jiný účet. Toto je obchodní pravidlo a nelze jej zaručit pouze kontrolami integrity, musí ho dodržovat programátoři při psaní transakčního kódu. Pokud se nějaká transakce odečte, ale nepřipíše, systém zůstane v nesprávném stavu a vlastnost konzistence bude narušena.
Nakonec ještě jedna poznámka se týká skutečnosti, že při provádění transakce není vyžadována žádná konzistence . V našem příkladu budou debetování a připisování s největší pravděpodobností dvě různé dílčí operace a mezi jejich provedením v rámci transakce bude viditelný nekonzistentní stav systému. Neměli bychom však zapomínat, že pokud je splněn požadavek na izolaci (viz níže), tato nekonzistence nebude viditelná pro žádné jiné transakce. A atomicita zaručuje, že transakce bude buď zcela dokončena, nebo nebude provedena žádná z operací transakce. Tato mezilehlá nekonzistence je tedy skryta.
Během provádění transakce by paralelní transakce neměly ovlivnit její výsledek. Izolace je nákladný požadavek, takže ve skutečných databázích existují režimy, které transakci úplně neizolují ( úrovně izolace, které umožňují fantomové čtení a nižší).
Bez ohledu na problémy na nižších úrovních (například výpadek napájení systému nebo selhání hardwaru) by změny provedené úspěšně dokončenou transakcí měly zůstat uloženy i po návratu systému do práce. Jinými slovy, pokud uživatel obdržel potvrzení ze systému, že transakce byla dokončena, může si být jistý, že změny, které provedl, nebudou kvůli nějakému selhání zrušeny.
Databáze | |
---|---|
Koncepty |
|
Objekty |
|
Klíče | |
SQL | |
Komponenty |