ACID

aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 4. August 2016 um 17:48 Uhr durch Crazy1880 (Diskussion | Beiträge) (Vorlagen-fix (Parameter:DOI)). Sie kann sich erheblich von der aktuellen Version unterscheiden.
Zur Navigation springen Zur Suche springen

ACID, deutsch auch AKID, ist eine Abkürzung in der Informatik. Es beschreibt häufig erwünschte Eigenschaften von Verarbeitungsschritten in Datenbankmanagementsystemen (DBMS) und verteilten Systemen. Es steht für englisch atomicity, consistency, isolation und durability. Man spricht im Deutschen auch von AKID-Eigenschaften (Atomarität, Konsistenz, Isolation und Dauerhaftigkeit). Sie gelten als Voraussetzung für die Verlässlichkeit von Systemen. Das Akronym ACID zur Charakterisierung von Transaktionen wurde 1983 von den Informatikern Theo Härder und Andreas Reuter geprägt.[1]

Eigenschaften

Atomarität (Abgeschlossenheit)

Von einer atomaren Operation spricht man, wenn eine Sequenz von Daten-Operationen entweder ganz oder gar nicht ausgeführt wird (Alles-oder-nichts-Eigenschaft).[2] Dies wird üblicherweise durch Verwendung von Transaktionen erreicht. Das DBMS verhält sich dabei gegenüber dem Benutzer so, als ob die Transaktion eine einzelne elementare Operation wäre, die nicht von anderen Operationen unterbrochen werden kann. Praktisch werden die einzelnen Datenbankanweisungen, aus denen sich die Transaktion zusammensetzt, natürlich nacheinander ausgeführt, aber global erst dann „für gültig erklärt und in Kraft gesetzt“, wenn sie erfolgreich vollständig abgeschlossen sind. Sollte sich jedoch während der Transaktion herausstellen, dass diese nicht vollständig abgeschlossen werden kann, wird der ursprüngliche Bereich als gültig erklärt und ein Rollback durchgeführt, d. h., alle bisherig ausgeführten Anweisungen wieder rückgängig gemacht, sofern notwendig – oder einfach der zwischenzeitlich für die Änderungen genutzte Speicherbereich wieder freigegeben und die Gültigkeit beim bisherigen belassen.

Konsistenzerhaltung

Konsistenz heißt, dass eine Sequenz von Daten-Operationen nach Beendigung einen konsistenten Datenzustand hinterlässt, falls die Datenbank davor auch konsistent war. Dies wird durch Normalisierung des Datenbestands, sowie explizit definierte Integritätsbedingungen, insbesondere von Schlüssel- und Fremdschlüsselbedingungen, erreicht.

Das Konsistenz-Kriterium bezieht sich vor allem auf die inhaltliche und referentielle Integrität eines Datenbestandes, die vor und nach einer Sequenz von Daten-Operationen gewährleistet bleiben muss. Während die Wahrung der inhaltlichen Integrität hauptsächlich von den verwendeten Datenbank-Operationen abhängt, lässt sich die referentielle Integrität automatisch gewährleisten, solange alle Redundanzen im Datenbestand automatisiert gehandhabt werden.

Die Normalisierung eines Datenbestands hat zum Ziel, dass dort alle Redundanzen außer durch Primärschlüssel und Fremdschlüssel vermieden werden. Letztere Art von Redundanz ist unvermeidlich, da sie zur Definition von Relationen benötigt wird. Alle nach der Normalisierung übrig bleibenden Redundanzen (Fremdschlüssel, absichtlich erhaltene Redundanzen, usw.) müssen dann durch Integritätsbedingungen so gehandhabt werden, dass die referentielle Integrität bei allen möglichen Daten-Operationen gewahrt bleibt.

Isolation (Abgrenzung)

Durch das Prinzip der Isolation wird verhindert/eingeschränkt, dass sich nebenläufig in Ausführung befindliche Daten-Operationen gegenseitig beeinflussen. Realisiert wird dies üblicherweise durch Anwendung von Transaktionen bei gemischten Lese- und Schreib-Sequenzen, sowie insbesondere auch bei reinen Lesesequenzen. Der transaktionale Isolationsgrad definiert dabei die erlaubte Art der Beeinflussung, verbreitete Einstellungen sind dabei READ COMMITTED, REPEATABLE READ sowie SERIALIZABLE.

Dauerhaftigkeit

Der Begriff Dauerhaftigkeit sagt aus, dass Daten nach dem erfolgreichen Abschluss einer Transaktion garantiert dauerhaft in der Datenbank gespeichert sind. Die dauerhafte Speicherung der Daten muss auch nach einem Systemfehler (Software-Fehler oder Hardware-Ausfall) garantiert sein. Insbesondere darf es nach einem Ausfall des Hauptspeichers nicht zu Datenverlusten kommen. Dauerhaftigkeit kann durch das Schreiben eines Transaktionslogs sichergestellt werden. Ein Transaktionslog erlaubt es, nach einem Systemausfall alle in der Datenbank fehlenden Schreib-Operationen zu reproduzieren.

Probleme und Einschränkungen

In verteilten Datenbanken kommt es zu Problemen, wenn alle ACID-Eigenschaften erfüllt werden sollen. Diese Probleme wurden in dem CAP-Theorem von Brewer formuliert. Im Umfeld der NoSQL-Datenbanken wird daher häufig das BASE-Prinzip (Basically Available, Soft state, Eventual consistency) verfolgt.

Siehe auch

Einzelnachweise

  1. Alfons Kemper, André Eickler: Datenbanksysteme. 5. Auflage. Oldenbourg, ISBN 3-486-27392-2, S. 272. (Erstmals erwähnt wurde ACID im Paper Theo Haerder, Andreas Reuter: Principles of Transaction-oriented Database Recovery. In: ACM Comput. Surv. Band 15, Nr. 4, 1983, S. 287–317, doi:10.1145/289.291 (uni-jena.de [PDF; 2,6 MB]).)
  2. Erhard Rahm: Mehrrechner-Datenbanksysteme. Oldenbourg, 1994, ISBN 978-3-486-24363-5, Kapitel 1.1.2 (Onlineausgabe [abgerufen am 2. August 2010]).