ACID
ACID, deutsch auch AKID, ist ein Akronym in der Informatik. Es beschreibt erwünschte Eigenschaften von Transaktionen in Datenbankmanagementsystemen (DBMS) und verteilten Systemen. Es steht für atomicity, consistency, isolation und durability. Man spricht im Deutschen auch von AKID-Eigenschaften (Atomarität, Konsistenz, Isoliertheit 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
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 der sich die Transaktion zusammensetzt, natürlich nacheinander ausgeführt – sobald sich jedoch herausstellt, dass die Transaktion nicht abgeschlossen werden kann, wird ein Rollback durchgeführt, also werden alle bisherigen Anweisungen wieder rückgängig gemacht.
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
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 COMMITED, REPEATABLE READ, und SERIALIZABLE.
Dauerhaftigkeit
Das Ergebnis einer Daten-Operation ist dauerhaft. Dies betrifft, im Gegensatz zur Atomarität, primär die Wirkung auf nachfolgende Daten-Operationen. Es darf keine erfolgreiche Schreiboperation geben, die bei einer nachfolgenden Änderung nur deshalb ignoriert wird, weil diese auf mittlerweile veralteten Daten beruht. Realisiert wird dies beispielsweise durch spezielle Sperrverfahren oder Zeitstempelverfahren.
Ohne Anwendung von Sperrverfahren oder Zeitstempelverfahren verhalten sich zwei nebenläufige Sequenzen von Datenoperationen gegen das gleiche Datum (z.B. lese Daten, erlaube Benutzer deren Veränderung, dann speichere geänderte Daten) so, dass die erste Änderung von der zweiten Änderung überschrieben wird. Dies ist vollkommen inakzeptabel, da dadurch grobe Fehler (z.B. Doppel-Reservierungen bei Reservierungsverfahren) entstehen können. Durch Anwendung von Sperrverfahren wird sichergestellt, dass nur die zuerst sperrende Operations-Sequenz das Recht auf Änderung erhält, während bei Anwendung von Zeitstempelverfahren nur die zuerst schreibende Operations-Sequenz erfolgreich zu Ende geführt werden kann.
Dauerhaftigkeit sollte in solchen Szenarien speziell nicht durch Transaktionen mit Isolationsgrad SERIALIZABLE hergestellt werden, da Transaktionen aus technischen Gründen Kurzläufer sein müssen: Jede laufende Transaktion blockiert eine wertvolle Datenbank-Verbindung und zudem nicht unerhebliche Mengen an reserviertem Hauptspeicher. Daher ist die Anwendung einer Transaktion für einen Vorgang, der eine Benutzer-Interaktion beinhaltet, im Normalfall nur im Client/Server Programmiermodell erlaubt. Stattdessen sollten zwei aufeinanderfolgende Transaktionen verwendet werden (eine vor, und eine nach der Benutzerinteraktion), während die zur Synchronisation verwendete Maßnahme (Sperrverfahren oder Zeitstempelverfahren) über beide Transaktionen hinweg bestehen bleibt.
Siehe auch
Einzelnachweise
- ↑ Alfons Kemper, André Eickler: Datenbanksysteme. Oldenbourg Verlag, 5. Aufl. ISBN 3-486-27392-2, Seite 272. Erstmals erwähnt wurde ACID im Paper Principles of Transaction-Oriented Database Recovery.
- ↑ Erhard Rahm: Mehrrechner-Datenbanksysteme. Oldenbourg, 1994, ISBN 978-3-486-24363-5, Kapitel 1.1.2 (Onlineausgabe [abgerufen am 2. August 2010]).