Alle Tabs der Lerneinheit (Erklärung · Timeline · Praxis-Übung · Klausur-Quiz) als durchgehender Text. Ideal zum Wiederholen vor der Klausur, und für Suchmaschinen wie Google, Bing und KI-Suche (ChatGPT, Perplexity).
Erklärung
Du überweist 100 € von Konto A nach Konto B. Das System bucht die 100 € bei A ab, und stürzt ab, bevor B die Gutschrift bekommt. Das Geld ist weg. Genau so etwas verhindern Transaktionen: eine Folge von Operationen, die entweder vollständig oder gar nicht ausgeführt wird. Klausur-Pflicht in 10/12 WInf-DB-Klausuren.
Wir gehen die 4 ACID-Eigenschaften systematisch durch, mit konkreten Banking- und Studi-Beispielen, und schauen am Ende, welche Anomalien passieren, wenn ACID verletzt wird.
Die Transaktion in einem Satz
Transaktion: eine Folge von Datenbank-Operationen, die als eine logische Einheit ausgeführt wird, alle oder keine.
Klassische Syntax:
BEGIN TRANSACTION;
UPDATE Konten SET Saldo = Saldo - 100 WHERE ID = 'A';
UPDATE Konten SET Saldo = Saldo + 100 WHERE ID = 'B';
COMMIT;
Wenn zwischen den beiden UPDATEs etwas schiefgeht (Crash, Fehler), führt die DB einen ROLLBACK durch, beide UPDATEs werden rückgängig gemacht. Resultat: nichts passiert ist, Geld ist sicher.
ACID, die 4 Eigenschaften
A, Atomicity (Atomarität)
Alles oder nichts. Eine Transaktion wird komplett durchgeführt oder komplett rückgängig gemacht.
Beispiel. Überweisung A → B: entweder beide Konten werden korrekt geändert, oder keines. Server-Crash mitten in der Transaktion → Rollback, Geld bleibt bei A.
Wie wird das implementiert? Klassisch: Log-Datei. Vor jeder Änderung schreibt die DB einen Eintrag "Was werde ich gleich ändern, alter Wert war X". Nach Crash kann sie aus dem Log alle unfertigen Transaktionen zurückrollen.
C, Consistency (Konsistenz)
Datenbank bleibt in gültigem Zustand. Vor und nach der Transaktion müssen alle Integritätsregeln (Fremdschlüssel, Constraints, Checks) erfüllt sein.
Beispiel. Konto-Saldo darf nicht negativ werden (CHECK-Constraint). Eine Transaktion, die das verletzen würde, wird abgebrochen, nicht halb durchgeführt.
Wichtig: Consistency ist eine Eigenschaft, die die DB plus die Anwendung gemeinsam sicherstellen. Die DB sorgt nur für die definierten Constraints; semantische Regeln (z.B. "Bonus = 10% vom Gehalt") muss die App durchsetzen.
I, Isolation (Isolation)
Parallele Transaktionen dürfen sich nicht in die Quere kommen. Das Ergebnis muss aussehen, als wären sie nacheinander ausgeführt worden.
Beispiel-Anomalie ohne Isolation. Zwei Transaktionen T₁ und T₂ wollen beide Saldo von 100 € auf 150 € setzen. Ohne Isolation:
T1: Lies Saldo (100€)
T2: Lies Saldo (100€) ← T2 sieht den alten Wert
T1: Schreibe 150€
T2: Schreibe 150€ ← T2 überschreibt T1, eine Aktualisierung ist verloren
Das ist die Lost-Update-Anomalie. Echte DBs verhindern das mit Sperren (Locks) oder Optimistic Concurrency Control. Mehr dazu in isolation-levels (Welle 8.5).
D, Durability (Dauerhaftigkeit)
Was committed ist, bleibt committed. Auch bei Strom-Ausfall oder Crash darf eine bestätigte Transaktion nicht verloren gehen.
Implementierung: vor dem COMMIT schreibt die DB alle Änderungen ins Log auf Festplatte (Write-Ahead Logging). Wenn der Server crashed, kann beim Neustart aus dem Log der DB-Zustand rekonstruiert werden.
Klausur-Test: Wenn nach COMMIT der Server crashed, geht nichts verloren. Wenn vor COMMIT crashed, ist die Transaktion komplett weg (durch Atomicity).
Anomalien bei fehlender Isolation
Drei Klassiker, werden in 8.5 isolation-levels vertieft, hier zur Einführung:
1. Dirty Read
T1 ändert einen Wert (noch nicht committed), T2 liest den neuen Wert, T1 macht Rollback. T2 hat einen Wert gelesen, der nie offiziell existiert hat.
T1: UPDATE Saldo = 1000€ (nicht committed)
T2: SELECT Saldo (sieht 1000€)
T1: ROLLBACK
T2: führt Logik mit 1000€ aus, falsch!
2. Lost Update
Zwei Transaktionen lesen denselben Wert, beide schreiben ihn, eine überschreibt die andere. Siehe Isolation-Beispiel oben.
3. Non-Repeatable Read
T1 liest einen Wert, T2 ändert ihn und committed, T1 liest noch mal, und bekommt einen anderen Wert. Innerhalb einer Transaktion sieht T1 inkonsistente Daten.
T1: SELECT Saldo (100€)
T2: UPDATE Saldo = 200€, COMMIT
T1: SELECT Saldo (200€) ← anders als beim ersten Read!
Visualisierung, paralleler Transaktionsablauf
Schau dir an, wie zwei Transaktionen parallel laufen und welche Anomalien dabei entstehen können:
Interaktive Visualisierung
Interaktive Komponente: probiere sie im Topic-Player oben aus.
Klausur-Faustregeln
- ACID auswendig: Atomicity (alles oder nichts), Consistency (gültiger Zustand), Isolation (parallele unabhängig), Durability (bleibt nach Crash).
- Anomalien-Trio: Dirty Read, Lost Update, Non-Repeatable Read, sind die häufigsten Klausur-Fragen zur Isolation.
- Atomicity ≠ Schnelligkeit. Atomar heißt "ungeteilt", nicht "schnell".
- Log-Konzept verstanden = halbe ACID-Klausur bestanden. Write-Ahead Logging löst Atomicity + Durability.
- COMMIT vs. ROLLBACK: COMMIT macht alles dauerhaft, ROLLBACK macht alles ungeschehen. Default in vielen DBs: AUTO-COMMIT (jede einzelne SQL-Anweisung ist eine eigene Transaktion).
Typische Stolpersteine
1. Consistency mit Durability verwechseln. Beide klingen ähnlich. Consistency = Constraints werden eingehalten. Durability = Daten überleben Crash.
2. ACID ist kein Garant für Performance. Echte parallele Systeme haben Trade-off: strenge ACID = langsam, gelockerte (z.B. eventual consistency) = schnell aber weniger sicher.
3. AUTO-COMMIT-Falle. Viele DB-Clients machen nach jeder SQL-Anweisung automatisch COMMIT. Wenn du eine echte Transaktion willst, explizit BEGIN schreiben.
4. Anomalien sind Implementation-Detail. Welche Anomalie wann auftritt, hängt vom Isolation Level ab (Welle 8.5). Höchster Level (Serializable) verhindert alle, niedrigster (Read Uncommitted) erlaubt alle.
Timeline
Transaktions-Timeline
Schau, wie zwei parallel laufende Transaktionen T₁ und T₂ aufeinander wirken. Wähle ein Szenario, der Visualizer zeigt die Schritte als Timeline und markiert, wo die Anomalie passiert.
Szenarien:
- Lost Update, beide schreiben denselben Wert
- Dirty Read, T2 liest unfertigen T1-Wert
- Non-Repeatable Read, T1 sieht denselben Wert zweimal verschieden
- Saubere Transaktion, alles funktioniert wie erwartet (für Vergleich)
Interaktive Visualisierung
Interaktive Komponente: probiere sie im Topic-Player oben aus.
Klausur-Tipp: Bei "welche Anomalie ist das?", schau auf den entscheidenden Schritt: Lesen-vor-Commit = Dirty Read, beide-Schreiben = Lost Update, zwei-Lese-Werte-unterschiedlich = Non-Repeatable Read.
Praxis-Übung
Transaktionen + ACID, Praxis-Übung
Drei Aufgaben-Typen: ACID-Eigenschaften zuordnen, Anomalien erkennen, Transaktions-Verhalten verstehen.
Klausurfragen mit Lösungen (6)
- F1.Welche ACID-Eigenschaft sorgt dafür, dass eine Transaktion entweder vollständig oder gar nicht ausgeführt wird?
Antwort: Atomicity
Erklärung: Atomicity = 'unteilbar'. Eine Transaktion läuft als eine Einheit; bei Fehler wird per Rollback alles rückgängig gemacht. Implementierung über Write-Ahead Logging.
- F2.Welche Eigenschaft sorgt dafür, dass committed-Daten auch nach einem Crash erhalten bleiben?
Antwort: Durability
Erklärung: Durability = 'Dauerhaftigkeit'. Wenn COMMIT durch ist, sind die Daten auf der Festplatte und überleben jeden Crash. Vor COMMIT crashen heißt: Transaktion ist weg (durch Atomicity).
- F3.Ordne die ACID-Eigenschaft der richtigen Implementation zu:
Zuordnungen:
- Atomicity → Write-Ahead Logging / Rollback
- Consistency → Constraints + Trigger / CHECK
- Isolation → Sperren (Locks) / Versionierung
- Durability → Log auf Festplatte vor COMMIT
Erklärung: ACID ist nicht nur ein Akronym, jede Eigenschaft hat eine konkrete Implementation. Atomicity + Durability nutzen Logging, Isolation nutzt Locks/MVCC, Consistency nutzt die SQL-Constraints.
Typ: Zuordnung
- F4.T1 ändert Saldo auf 1000€ (nicht committed), T2 liest 1000€, T1 macht ROLLBACK. Welche Anomalie?
Antwort: Dirty Read
Erklärung: Dirty Read: T2 hat einen Wert gelesen, der nie offiziell existiert hat (weil T1 zurückgerollt wurde). Das ist die schwerste Anomalie, verhindert durch Isolation Level READ COMMITTED oder höher.
- F5.Wenn nach einem COMMIT der Server crashed, sind die Daten der committed-Transaktion verloren.
Antwort: Falsch
Erklärung: FALSCH. Durability garantiert: nach COMMIT sind Daten dauerhaft auf Festplatte. Crash kann nichts mehr verlieren. Genau das ist der Sinn von Write-Ahead Logging + fsync vor COMMIT.
Typ: Wahr/Falsch
- F6.Welche Aussagen über Transaktionen sind RICHTIG?
Richtige Antworten: COMMIT macht alle Änderungen einer Transaktion dauerhaft; ROLLBACK macht alle Änderungen einer Transaktion rückgängig; Atomicity garantiert: bei Crash mitten in der Transaktion ist nichts geändert
Erklärung: Richtig: COMMIT/ROLLBACK-Semantik, Atomicity-Garantie bei Crash. Falsch: AUTO-COMMIT kann meist ausgeschaltet werden; Transaktionen können beliebig viele Statements enthalten; ACID gilt für ALLE Transaktionen (lesend + schreibend).
Typ: Multi-Select
Klausur-Quiz
Klausurfragen mit Lösungen (6)
- F1.T1 liest Saldo (100€). T2 ändert auf 200€ und committed. T1 liest erneut (200€). Welche Anomalie?
Antwort: Non-Repeatable Read
Erklärung: Non-Repeatable Read: T1 bekommt bei wiederholtem SELECT verschiedene Werte. T1 sieht innerhalb derselben Transaktion inkonsistente Daten. Verhindert durch REPEATABLE READ oder SERIALIZABLE.
- F2.Atomicity garantiert, dass eine Transaktion schnell ausgeführt wird.
Antwort: Falsch
Erklärung: FALSCH. Atomicity = 'ungeteilt', nicht 'schnell'. Eine atomare Transaktion kann sehr langsam sein (z.B. eine große Batch-Update-Transaktion). Schnelligkeit ist eine andere Eigenschaft (Performance, nicht ACID).
Typ: Wahr/Falsch
- F3.Welche Implementation gewährleistet Durability?
Antwort: Write-Ahead Logging mit fsync vor COMMIT
Erklärung: WAL + fsync: vor jedem COMMIT wird das Log explizit auf Festplatte geschrieben (fsync). Erst dann meldet die DB COMMIT erfolgreich. Damit überleben committete Daten jeden Crash. Replikation ist ZUSÄTZLICH (High Availability), nicht das eigentliche Durability-Mittel.
- F4.Sortiere die Schritte einer Banking-Transaktion (A → B Überweisung 100€):
Richtige Reihenfolge:
- BEGIN TRANSACTION
- UPDATE Konto A: Saldo -= 100
- UPDATE Konto B: Saldo += 100
- Constraint-Check: alle Salden ≥ 0?
- COMMIT (Daten dauerhaft)
Erklärung: Standard-Workflow. Wichtig: Constraint-Check passiert VOR COMMIT, wenn er fehlschlägt, wird Rollback durchgeführt. Das ist Atomicity in Aktion.
Typ: Reihenfolge
- F5.Eine Transaktion T1 hat Saldo geändert (nicht committed) und T2 wartet auf eine Sperre. Welche Eigenschaft ist hier aktiv?
Antwort: Isolation
Erklärung: Isolation: T1 blockiert T2, damit beide nicht durcheinander kommen. Sperren sind die klassische Implementation von Isolation. Alternativ: Multi-Version Concurrency Control (MVCC), jede Transaktion sieht einen 'Schnappschuss' der DB.
- F6.Die {{1}}-Anomalie tritt auf, wenn eine Transaktion einen Wert liest, der noch nicht committed war und später zurückgerollt wurde. Die {{2}}-Anomalie tritt auf, wenn zwei Transaktionen denselben Wert lesen, beide ändern, und eine die andere überschreibt.
Lösungen pro Lücke:
- {{1}}: Dirty Read / Dirty-Read / Schmutzig-Lese
- {{2}}: Lost Update / Lost-Update / Verloren
Erklärung: Die zwei häufigsten Klausur-Anomalien. Dirty Read = lesen vor Commit. Lost Update = parallel Schreiben ohne Locks. Dritte häufige Anomalie ist Non-Repeatable Read.
Typ: Lückentext
