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).
Teil 1·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.
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.
Anmelden, um den Fortschritt zu speichern.
Nächster Schritt
Aktives Abrufen festigt Wissen schneller als nochmal lesen.
Diese Lerneinheit wurde für typische Bachelor-Klausuren konzipiert. So prüfen wir · Fehler entdeckt? Melde ihn uns oder markiere die fragliche Stelle direkt im Text oben.
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).
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.
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.
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.
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.
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).
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).
Drei Klassiker — werden in 8.5 isolation-levels vertieft, hier zur Einführung:
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!
Zwei Transaktionen lesen denselben Wert, beide schreiben ihn — eine überschreibt die andere. Siehe Isolation-Beispiel oben.
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!
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.
- 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).
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.
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:
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.
Drei Aufgaben-Typen: ACID-Eigenschaften zuordnen, Anomalien erkennen, Transaktions-Verhalten verstehen.
Klausurfragen mit Lösungen (6)
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.
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).
Zuordnungen:
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
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.
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
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
Klausurfragen mit Lösungen (6)
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.
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
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.
Richtige Reihenfolge:
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
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.
Lösungen pro Lücke:
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