ACID

ACID ist ein Akronym fuer vier grundlegende Eigenschaften, die zuverlaessige Datenbanktransaktionen garantieren: Atomicity (Atomaritaet), Consistency (Konsistenz), Isolation und Durability (Dauerhaftigkeit). Diese Prinzipien stellen sicher, dass Datenbanken auch bei Systemausfaellen, Stromausfaellen oder gleichzeitigen Zugriffen in einem konsistenten Zustand bleiben.

Das ACID-Konzept wurde erstmals 1983 von den Informatikern Theo Haerder und Andreas Reuter in ihrem Artikel "Principles of Transaction-Oriented Database Recovery" formalisiert. Seitdem bildet es das Fundament fuer die Zuverlaessigkeit relationaler Datenbanksysteme wie MySQL, PostgreSQL und Oracle.

Die vier ACID-Eigenschaften

Jede der vier ACID-Eigenschaften erfuellt eine spezifische Aufgabe bei der Sicherstellung der Datenintegritaet. Erst das Zusammenspiel aller vier Eigenschaften garantiert zuverlaessige Transaktionen.

Atomicity (Atomaritaet)

Atomicity bedeutet, dass eine Transaktion als unteilbare Einheit behandelt wird - entweder werden alle Operationen erfolgreich ausgefuehrt (Commit), oder keine einzige (Rollback). Es gibt keine Zwischenzustaende, in denen nur ein Teil der Aenderungen gespeichert ist.

Stell dir eine Bankueberweisung vor: Du moechtest 100 Euro von Konto A auf Konto B ueberweisen. Diese Operation besteht aus zwei Schritten - dem Abbuchen von Konto A und dem Gutschreiben auf Konto B. Atomaritaet stellt sicher, dass niemals Geld "verschwindet", weil nur der erste Schritt ausgefuehrt wurde.

-- Beispiel: Atomare Bankueberweisung
START TRANSACTION;

UPDATE konten SET saldo = saldo - 100 WHERE konto_id = 1;
UPDATE konten SET saldo = saldo + 100 WHERE konto_id = 2;

-- Bei Erfolg: Beide Aenderungen werden gespeichert
COMMIT;

-- Bei Fehler: Beide Aenderungen werden verworfen
-- ROLLBACK;

Consistency (Konsistenz)

Consistency garantiert, dass eine Transaktion die Datenbank von einem gueltigen Zustand in einen anderen gueltigen Zustand ueberfuehrt. Alle definierten Regeln und Constraints - wie Primaerschluessel, Fremdschluessel, CHECK-Constraints oder Trigger - muessen vor und nach der Transaktion erfuellt sein.

Wenn in einer E-Commerce-Datenbank festgelegt ist, dass der Lagerbestand nie negativ werden darf, verhindert die Konsistenz-Eigenschaft, dass eine Bestellung mehr Artikel verkauft, als auf Lager sind. Die Transaktion wird abgebrochen, bevor ein ungueltiger Zustand entstehen kann.

-- Beispiel: Constraint verhindert negativen Lagerbestand
CREATE TABLE lagerbestand (
    artikel_id INT PRIMARY KEY,
    menge INT CHECK (menge >= 0)  -- Constraint
);

-- Diese Transaktion schlaegt fehl, wenn menge negativ wuerde
UPDATE lagerbestand 
SET menge = menge - 10 
WHERE artikel_id = 42;

Isolation

Isolation sorgt dafuer, dass parallel laufende Transaktionen sich nicht gegenseitig beeinflussen. Jede Transaktion arbeitet so, als waere sie die einzige im System. Die Aenderungen einer Transaktion werden erst nach dem Commit fuer andere sichtbar.

Ohne Isolation koennten verschiedene Anomalien auftreten: Ein Dirty Read bedeutet, dass eine Transaktion Daten liest, die noch nicht committed wurden. Bei einem Non-Repeatable Read liefert dieselbe Abfrage unterschiedliche Ergebnisse, weil eine andere Transaktion dazwischen Daten geaendert hat.

Datenbanken bieten verschiedene Isolationslevel, die einen Kompromiss zwischen Sicherheit und Performance ermoglichen:

Je hoeher das Isolationslevel, desto sicherer sind die Daten, aber desto mehr wird die parallele Verarbeitung eingeschraenkt. In der Praxis ist Read Committed der Standardwert bei den meisten Datenbanksystemen.

Durability (Dauerhaftigkeit)

Durability garantiert, dass erfolgreich committete Transaktionen permanent gespeichert bleiben - auch bei Systemabstuerzen, Stromausfaellen oder Hardware-Defekten. Sobald das Datenbanksystem den Commit bestaetigt hat, sind die Daten sicher.

Datenbanken erreichen Dauerhaftigkeit durch Write-Ahead Logging (WAL): Bevor eine Aenderung in die eigentlichen Datenbankdateien geschrieben wird, landet sie zuerst in einem Transaction Log. Bei einem Systemausfall kann die Datenbank anhand dieses Logs alle committeten Transaktionen wiederherstellen.

Praktisches Beispiel: Online-Bestellung

Ein typisches Szenario, in dem alle ACID-Eigenschaften zusammenspielen, ist eine Online-Bestellung. Hier muessen mehrere Tabellen gleichzeitig aktualisiert werden - und das zuverlaessig.

START TRANSACTION;

-- 1. Neue Bestellung anlegen
INSERT INTO bestellungen (kunde_id, datum, status) 
VALUES (42, NOW(), 'offen');

-- 2. Bestellpositionen hinzufuegen
INSERT INTO bestellpositionen (bestell_id, artikel_id, menge) 
VALUES (LAST_INSERT_ID(), 101, 2);

-- 3. Lagerbestand reduzieren
UPDATE lagerbestand 
SET menge = menge - 2 
WHERE artikel_id = 101;

-- 4. Kundenpunkte gutschreiben
UPDATE kunden 
SET treuepunkte = treuepunkte + 50 
WHERE id = 42;

COMMIT;

Durch ACID ist sichergestellt, dass niemals eine Bestellung ohne Lagerbestandsaenderung existiert, keine Punkte ohne Bestellung gutgeschrieben werden, und alle Aenderungen auch nach einem Serverausfall erhalten bleiben.

ACID vs. BASE

Waehrend relationale Datenbanken auf ACID setzen, verfolgen viele NoSQL-Datenbanken einen anderen Ansatz namens BASE (Basically Available, Soft state, Eventually consistent). BASE akzeptiert temporaere Inkonsistenzen zugunsten hoeherer Verfuegbarkeit und Skalierbarkeit.

Die Wahl zwischen ACID und BASE haengt vom Anwendungsfall ab. Fuer Banktransaktionen, medizinische Daten oder E-Commerce-Bestellungen ist ACID unverzichtbar. Fuer Social-Media-Feeds oder Echtzeit-Analytics kann BASE die bessere Wahl sein.

ACID in der Praxis

Fast alle relationalen Datenbanksysteme implementieren die ACID-Eigenschaften, allerdings mit unterschiedlichen Standardeinstellungen und Optimierungen. Als Entwickler solltest du wissen, wie dein DBMS Transaktionen handhabt.

• MySQL/MariaDB: ACID-konform mit InnoDB-Storage-Engine (Standard seit MySQL 5.5)
• PostgreSQL: Vollstaendige ACID-Unterstuetzung mit MVCC (Multi-Version Concurrency Control)
• Microsoft SQL Server: ACID-konform mit verschiedenen Isolationslevels
• Oracle Database: Vollstaendige ACID-Implementierung mit umfangreichen Recovery-Optionen
• SQLite: ACID-konform, auch bei eingebetteten Anwendungen

Bei der Entwicklung von Anwendungen mit Java, C# oder anderen Sprachen nutzt du oft Frameworks, die die Transaktionsverwaltung abstrahieren. Spring in Java oder Entity Framework in .NET bieten deklarative Transaktionen per Annotation.

Quellen und weiterfuehrende Links

• Wikipedia: ACID - Ausfuehrliche Erklaerung des Konzepts
• PostgreSQL: Transaction Isolation - Offizielle Dokumentation zu Isolationslevels
• MySQL: ACID Compliance - MySQL-spezifische ACID-Implementierung
• IBM: ACID Properties - IBM-Dokumentation zu Transaktionseigenschaften