ACID (fra engelsk atomicitet, konsistens, isolation, holdbarhed ) er et sæt krav til et transaktionssystem, der sikrer dets mest pålidelige og forudsigelige drift - atomicitet , konsistens , isolation , stabilitet ; formuleret i slutningen af 1970'erne af Jim Gray [1] .
Sættet af krav betragtes som de facto-standarden for meget pålidelige systemer, primært relationelle DBMS'er , mens det i midten af 2000'erne, for at bygge distribuerede DBMS'er, antages, at en del af ACID-kravene vil blive opgivet (hvilket er berettiget ved hjælp af CAP'en ) sætning , PACELC - sætningen ) eller en reduktion af kravenes sværhedsgrad ( BASE ) .
Atomicity sikrer, at ingen transaktion er delvist forpligtet til systemet. Enten vil alle dets underoperationer blive eksekveret, eller ingen af dem vil blive eksekveret. Da det i praksis er umuligt samtidigt og atomært at udføre hele sekvensen af operationer inden for en transaktion, introduceres begrebet "rollback" ( rollback ): hvis transaktionen ikke kan fuldføres fuldstændigt, vil resultaterne af alle dens hidtil udførte handlinger annulleres, og systemet vil vende tilbage til "eksternt initial" tilstand - udefra ser det ud til, at der ikke var nogen transaktion (naturligvis kan tællere, indekser og andre interne strukturer ændre sig, men hvis DBMS er programmeret uden fejl, dette vil ikke påvirke dets ydre adfærd).
En transaktion, der når sin normale transaktionsslutning (EOT) og derved forpligter sine resultater, bevarer databasekonsistens. Med andre ord, hver succesfuld transaktion forpligter per definition kun gyldige resultater. Denne betingelse er nødvendig for at understøtte den fjerde ejendom.
Konsistens er et bredere begreb. Eksempelvis kan der i banksystemet være et krav om, at det beløb, der debiteres fra én konto, er lig med det beløb, der er krediteret en anden. Dette er en forretningsregel og kan ikke garanteres af integritetstjek alene, den skal overholdes af programmører, når de skriver transaktionskode. Hvis en transaktion debiterer, men ikke krediterer, forbliver systemet i en forkert tilstand, og konsistensegenskaben vil blive krænket.
Endelig er der endnu en bemærkning om, at der ikke kræves konsistens under udførelsen af en transaktion . I vores eksempel vil debitering og kreditering højst sandsynligt være to forskellige deloperationer, og mellem deres udførelse inden for transaktionen vil en inkonsistent tilstand af systemet være synlig. Vi skal dog ikke glemme, at hvis isolationskravet (se nedenfor) er opfyldt, vil denne inkonsistens ikke være synlig for andre transaktioner. Og atomicitet garanterer, at transaktionen enten bliver fuldstændig gennemført, eller at ingen af transaktionens operationer vil blive udført. Denne mellemliggende inkonsistens er således skjult.
Under udførelsen af en transaktion bør parallelle transaktioner ikke påvirke resultatet. Isolering er et dyrt krav, så i rigtige databaser er der tilstande, der ikke fuldstændigt isolerer en transaktion ( isolationsniveauer, der tillader fantomlæsninger og lavere).
Uanset problemer på de lavere niveauer (f.eks. strømafbrydelse af systemet eller hardwarefejl), bør ændringerne, der er foretaget af en vellykket gennemført transaktion, forblive gemt, efter at systemet vender tilbage til at fungere. Med andre ord, hvis brugeren modtog en bekræftelse fra systemet på, at transaktionen blev gennemført, kan han være sikker på, at de ændringer, han har foretaget, ikke vil blive annulleret på grund af en form for fejl.
| Database | |
|---|---|
| Begreber |
|
| Objekter | |
| Nøgler | |
| SQL | |
| Komponenter | |