ACID-Eigenschaften

In Lektion 4 haben wir Transaktionen als „ganz-oder-gar-nicht-Bündel" kennengelernt. Diese Beschreibung ist intuitiv, aber wenn man als Informatiker präzise sein will, nutzt man ein etablierteres Akronym: ACID. Diese vier Buchstaben fassen die Garantien zusammen, die eine ordentliche relationale Datenbank für ihre Transaktionen abgibt.

ACID steht für Atomicity, Consistency, Isolation, Durability – auf Deutsch Atomarität, Konsistenz, Isolation, Dauerhaftigkeit. Geprägt wurde der Begriff 1983 von Andreas Reuter und Theo Härder. Heute ist er der Standard, an dem sich alle ernstzunehmenden relationalen Datenbanken messen lassen müssen – und ein absoluter Klassiker in IHK-Prüfungen.

1) Die vier Buchstaben im Überblick

Klick einen Buchstaben um die Eigenschaft mit Definition, Merksatz und typischem Schadensbild zu sehen:

2) A wie Atomicity – ganz oder gar nicht

Atomicity heißt: eine Transaktion ist unteilbar. Das griechische atomos bedeutet wörtlich „unzerschneidbar". Eine Transaktion mit zehn Schritten hat exakt zwei mögliche Ausgänge – alle zehn werden wirksam oder keiner –, nicht 2¹⁰ verschiedene Halbzustände.

3) C wie Consistency – die Spielregeln gelten immer

Consistency heißt: vor der Transaktion war die Datenbank in einem regelkonformen Zustand, nach der Transaktion ist sie es wieder. „Regeln" sind alle definierten Integritätsbedingungen – Primary Keys, Foreign Keys, NOT NULL, CHECK-Constraints, plus deine Geschäftsregeln. Während der Transaktion darf die Datenbank kurzfristig „in der Schwebe" sein – das sieht aber von außen niemand.

4) I wie Isolation – Transaktionen stören sich nicht

Isolation heißt: wenn mehrere Transaktionen parallel laufen, sehen sie einander nicht (oder nur kontrolliert). Aus Sicht jeder einzelnen Transaktion sieht es so aus, als wäre sie allein im System. Echte Strenge wäre teuer – das DBMS müsste alle Transaktionen seriell abarbeiten – deshalb bietet SQL verschiedene Isolationsstufen (Thema L6).

5) D wie Durability – einmal gespeichert, immer gespeichert

Durability (Dauerhaftigkeit) heißt: sobald die Datenbank den Erfolg eines COMMIT bestätigt hat, sind die Daten dauerhaft – auch wenn unmittelbar danach der Strom ausfällt, der Server abstürzt oder die Platte voll läuft. „Committed" ist eine harte Garantie, kein „wahrscheinlich gespeichert". Realisiert wird das über das Write-Ahead-Log: vor dem COMMIT-Ack wird das Log per fsync auf die Platte gezwungen.

6) Was passiert, wenn ACID fehlt?

Jede Eigenschaft adressiert eine konkrete Klasse von Bugs. Wer eine weglässt, lädt diese Bugs verlässlich ein. Die typischen Schadensbilder:

• Ohne Atomicity: halb durchgeführte Operationen – Geld weg, Bestellung ohne Position, Sitz reserviert aber nicht bezahlt. Die Anwendung muss kompliziert kompensieren, was nie sauber funktioniert.
• Ohne Consistency: Regeln werden verletzt, niemand merkt's. Verwaiste Fremdschlüssel, doppelte IDs, negative Werte trotz CHECK. Reports liefern absurde Zahlen.
• Ohne Isolation: Lost Updates, Dirty Reads, „Phantom"-Zeilen. Klassiker: zwei gleichzeitige Buchungen auf denselben letzten Sitzplatz gehen beide durch. Schwer zu reproduzieren, schwer zu debuggen.
• Ohne Durability: committed Daten verschwinden bei Crashs. Vertrauen ist weg. Kunde sagt „ich hab bezahlt!", System sagt „kein Eintrag".

Moderne relationale Datenbanken (PostgreSQL, MySQL/InnoDB, MariaDB, Oracle, SQL Server, SQLite) sind alle ACID-konform. Das ist nicht selbstverständlich, sondern Ergebnis jahrzehntelanger Arbeit. Die ältere MyISAM-Engine in MySQL war z.B. nicht ACID – darum ist InnoDB seit langem der Default.

7) Wer setzt welche Eigenschaft um?

Im DBMS arbeiten verschiedene Komponenten zusammen, um die ACID-Garantien zu erfüllen. Die grobe Aufteilung:

• Atomicity & Durability werden vom Transaktionslog (WAL) gemeinsam realisiert. Alte Werte zum Rückrollen, neue Werte zum Nachholen.
• Consistency wird vom Constraint-Manager sichergestellt – jeder Insert/Update wird gegen alle Regeln geprüft.
• Isolation wird vom Lock-Manager oder per MVCC (Multi-Version Concurrency Control) erreicht – das DBMS hält je nach Stufe Sperren oder verteilt Snapshots.

Im Zusammenspiel: eine Transaktion startet → der Lock-Manager vergibt Sperren (Isolation) → jeder Schritt wird geloggt (Atomicity, Durability) → der Constraint-Manager prüft (Consistency) → bei COMMIT wird das Log per fsync auf Platte gezwungen (Durability) → Sperren werden freigegeben (Isolation). Bei ROLLBACK werden die alten Werte aus dem Log wiederhergestellt (Atomicity) und Sperren freigegeben.

8) ACID vs. BASE – die NoSQL-Welt

In den 2000ern entstanden viele NoSQL-Datenbanken (MongoDB, Cassandra, DynamoDB), die nicht alle ACID-Garantien bieten. Statt strenger Konsistenz versprechen sie BASE: Basically Available, Soft state, Eventually consistent. Heißt grob: das System ist meist verfügbar, sein Zustand kann zwischenzeitlich abweichen, und wenn man lang genug wartet, gleicht sich alles an.

BASE ist okay für Social Media (eine Sekunde Verzögerung beim Like ist egal) – nicht okay für Banktransaktionen. Verwandt ist das CAP-Theorem: ein verteiltes System kann von Consistency, Availability und Partition Tolerance nur zwei gleichzeitig vollständig garantieren. ACID-Systeme wählen meist CA/CP, BASE-Systeme wählen AP. Wer mehr darüber wissen will: K37 NoSQL behandelt das ausführlich.

9) ACID in der IHK-Prüfung

ACID ist ein Lieblingsthema der Prüfer und kommt in nahezu jedem Stil vor. Diese fünf Fragen solltest du auf Knopfdruck beantworten können:

1. Wofür stehen die vier Buchstaben? – Atomicity, Consistency, Isolation, Durability.
2. Was bedeutet jede Eigenschaft in einem Satz? – siehe die Merksätze in den Panels oben.
3. Welche Befehle steuern Transaktionen? – BEGIN, COMMIT, ROLLBACK, optional SAVEPOINT (siehe L7).
4. Was passiert wenn eine Eigenschaft fehlt? – die typischen Schadensbilder aus Abschnitt 6.
5. Unterschied ACID vs. Integritätstypen? – ACID sichert Transaktionen, Integritätstypen sichern Daten. ACID baut auf den Integritätstypen auf.

Klassische Falle: ACID und die vier Integritätstypen werden verwechselt. ACID hat vier Eigenschaften einer Transaktion. Integrität hat vier Typen von Datenkorrektheit. Beides sind je vier Dinge, beides hat mit Datenbank-Verlässlichkeit zu tun – aber es ist nicht dasselbe.

Zusammenfassung

ACID fasst die vier Garantien einer relationalen Transaktion zusammen: Atomicity (Transaktion ist unteilbar – ganz oder gar nicht, realisiert durch Transaktionslog), Consistency (Datenbank vor und nach Transaktion regelkonform, alle Integritätsbedingungen erfüllt), Isolation (parallele Transaktionen stören sich nicht – per Locking oder MVCC, mit verschiedenen Isolationsstufen), Durability (committed Daten überleben Crashs – Write-Ahead-Log mit fsync vor COMMIT-Ack). Jede Eigenschaft adressiert eine konkrete Bug-Klasse; Komponenten im DBMS (WAL, Constraint-Manager, Lock-Manager) setzen sie um. Alle modernen RDBMS sind ACID-konform; NoSQL-Systeme entscheiden sich teilweise für BASE-Semantik zugunsten von Skalierbarkeit. Eine IHK-relevante Pflichtlektion.