docs: add obsidian hwr docs

Datenbanken/Zusammenfassungen/f_Transaktionen - zusammenfassung.md

@@ -0,0 +1,273 @@
+# Transaktionen – Zusammenfassung
+**Dozent:** A. Zimmermann | HWR Berlin | 2026 | **Folien 1–31**
+
+---
+
+## 1. Definition (Folien 1–2)
+
+### Integrität und Transaktionen
+
+**Integrität (Konsistenz)** der Datenbank = Zustand der Daten, in dem sie **korrekt, vollständig und widerspruchsfrei** sind.
+
+**Transaktion** = Mehrere Operationen, die:
+- Entweder **alle erfolgreich** durchgeführt werden
+- Oder, falls ein Fehler vorliegt, die schon durchgeführten **rückgängig gemacht** werden müssen
+
+### Eigenschaften
+
+- Transaktionen gewährleisten einen **konsistenten Zustand** der Datenbank
+- Sie versetzen den Datenbestand von einem konsistenten Zustand in einen **anderen konsistenten Zustand**
+- Eine Transaktion wird als **atomare (ununterbrechbare) Operation** betrachtet
+- Bei Fehlern werden Komponenten nicht rückgängig gemacht (zeitintensiv), sondern der **zuvor gespeicherte Zustand** wird wiederhergestellt
+
+---
+
+## 2. Beispiel (Folie 3)
+
+Zwei ganze Zahlen A und B (Datenbestand):
+
+```
+T1 = { A=A+100; B=B+100; }
+T2 = { A=A*2;   B=B*2;   }
+```
+
+- **Sequenzielle Ausführung** → Konsistenz gewährleistet
+- **Gemischte Operationen** → Konsistenz **nicht** mehr gewährleistet
+
+---
+
+## 3. Anforderungen (Folien 4–5)
+
+### Allgemeine Anforderungen (Folie 4)
+
+| Anforderung | Beschreibung |
+|---|---|
+| Gleichzeitige Verarbeitung | Mehrere Transaktionen müssen **quasi-parallel** verarbeitet werden |
+| Fehlerbehandlung | Abgeschlossene Transaktionen bleiben bestehen, offene werden rückgängig gemacht |
+| Organisation | Manuell (im Source-Code) oder automatisch |
+| Zwischenpunkte | Daten erfolgreich durchgeführter Operationen können gespeichert werden |
+| Abschlussarten | Nur **COMMIT** (erfolgreich) oder **ROLLBACK** (erfolglos) |
+
+**Gründe für ROLLBACK:** Systemfehler, Integritätsverletzungen, Deadlock, Benutzeranweisung.
+
+### ACID-Eigenschaften (Folie 5)
+
+| Eigenschaft | Beschreibung |
+|---|---|
+| **A**tomicity (Atomarität) | Entweder **alle** Befehle oder **gar keine** werden ausgeführt |
+| **C**onsistency (Konsistenz) | Transaktion hinterlässt nach Beendigung einen **konsistenten Datenzustand**, ansonsten komplettes Zurücksetzen |
+| **I**solation | Nebenläufige Transaktionen beeinflussen sich **nicht gegenseitig**; jede wird logisch so ausgeführt, als wäre sie die einzig aktive |
+| **D**urability (Dauerhaftigkeit) | Wirkung einer erfolgreich abgeschlossenen Transaktion bleibt **dauerhaft** erhalten, auch nach Systemfehler |
+
+---
+
+## 4. Zustände einer Transaktion (Folie 6)
+
+```
+BoT → Active → Committing → Änderungen festgeschrieben → EoT
+         ↓          ↓
+    Waiting for   ERROR
+    resources       ↓
+         ↓      Rolling back → Änderungen rückgängig gemacht → EoT
+      DEADLOCK
+         ↓
+    ROLLBACK → Rolling back
+```
+
+| Zustand | Beschreibung |
+|---|---|
+| **BoT** | Begin of Transaction |
+| **Active** | Transaktion führt Operationen aus |
+| **Waiting for resources** | Wartet auf gesperrte Ressourcen |
+| **DEADLOCK** | Gegenseitige Blockierung erkannt |
+| **Committing** | Änderungen werden festgeschrieben (COMMIT) |
+| **Rolling back** | Änderungen werden rückgängig gemacht (ROLLBACK) |
+| **EoT** | End of Transaction |
+
+---
+
+## 5. Synchronisation (Folien 7–8)
+
+### Definition
+
+**Synchronisation (Mehrbenutzersynchronisation)** = Koordinierung von mehreren Benutzerprozessen, eng verbunden mit der Ausführung der Transaktionen.
+
+### Ausführungsarten
+
+| Art | Beschreibung | Eigenschaft |
+|---|---|---|
+| **Seriell** | Transaktionen nacheinander | Absolut sicher, aber **langsam**; blockiert nachfolgende Transaktionen |
+| **Parallel** | Transaktionen gleichzeitig | Nutzt Ressourcen **besser** aus |
+| **Serialisierung** | Anordnung paralleler Operationen | Entspricht in der Wirkung der seriellen Ausführung, garantiert Konsistenz |
+
+---
+
+## 6. Probleme bei paralleler Ausführung (Folien 9–26)
+
+### Übersicht (Folie 10)
+
+Bei Zugriff auf **denselben Datenbestand** können folgende Probleme entstehen:
+1. **Lost Update**
+2. **Dirty Read**
+3. **Non-Repeatable Read**
+4. **Phantom Read**
+
+Diese Probleme können durch **Isolation** (verschiedene Sicherheitsstufen) vermieden werden.
+
+### Isolationsstufen – allgemein (Folie 11)
+
+- Die Isolationsstufe betrifft den **Schreibvorgang nicht** – eine Transaktion bekommt immer eine **exklusive Sperre** für alle zu ändernden Daten
+- Die Isolationsstufe wirkt auf die **Lesevorgänge** – definiert, wie Lesevorgänge von anderen Transaktionen abhängig sind
+
+### 6.1 Lost Update (Folien 12–17)
+
+**Problem:** Die von einer Transaktion geänderten Daten werden von einer anderen Transaktion überschrieben.
+
+**Variante 1 – Direkt (Folie 12):**
+```
+T1: update TabX set V=42;       T2: ...
+T1: ...                          T2: update TabX set V=53;
+T1: ...                          T2: commit;
+T1: commit;                      T2: ...
+```
+→ Update von T2 geht verloren. Kommt in Datenbanken **nicht vor**, da T2 auf Freigabe wartet.
+
+**Variante 2 – Über lokale Variable (Folie 13):**
+```
+T1: select V from TabX into W;  T2: ...
+T1: W := W+1;                   T2: update TabX set V=53;
+T1: update TabX set V=W;        T2: commit;
+T1: commit;                     T2: ...
+```
+→ Update von T2 geht verloren. Kann durch **höhere Isolationsstufe** vermieden werden.
+
+**Lösung:** `SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;`
+- Die Transaktion merkt sich die Daten, die zum **Start der Transaktion** festgeschrieben waren
+- Ändert eine andere Transaktion diese Daten, bricht die erste ab
+- Fehler: `ORA-08177: can't serialize access for this transaction`
+
+### 6.2 Dirty Read (Folien 18–19)
+
+**Problem:** Eine Transaktion liest Daten, die eine andere Transaktion geändert, aber **noch nicht festgeschrieben** hat.
+
+```
+T1: ...                          T2: update TabX set V=42;
+T1: select V from TabX;          T2: ...        ← T1 liest V=42
+T1: ...                          T2: rollback;  ← V=42 war ungültig!
+```
+
+**Lösung:** Standard-Isolationsstufe in Oracle ist **READ COMMITTED** → verhindert Dirty Read automatisch.
+
+Dirty Read ist nur möglich mit `READ UNCOMMITTED` (in Oracle nicht verfügbar).
+
+### 6.3 Non-Repeatable Read (Folien 20–21)
+
+**Problem:** Eine Transaktion liest **zweimal dieselben Daten** und bekommt **unterschiedliche Ergebnisse**.
+
+```
+T1: select V from TabX;         T2: ...
+T1: ...                          T2: update TabX set V=42;
+T1: ...                          T2: commit;
+T1: select V from TabX;          T2: ...        ← anderer Wert!
+```
+
+**Lösung:** Isolationsstufe **SERIALIZABLE** (Standard READ COMMITTED lässt dies zu).
+
+### 6.4 Phantom Read (Folie 22–23)
+
+**Problem:** Ähnlich Non-Repeatable Read, aber mit **Anzahl der Zeilen** statt Werten.
+
+```
+T1: select count(*) from TabX;  T2: ...
+T1: ...                          T2: insert into TabX ...;
+T1: ...                          T2: commit;
+T1: select count(*) from TabX;   T2: ...        ← anderer Count!
+```
+
+**Lösung:** Isolationsstufe **SERIALIZABLE** löst auch dieses Problem in Oracle.
+
+### Trade-off der Isolationsstufen (Folie 24)
+
+| Niedrigere Stufe | Höhere Stufe |
+|---|---|
+| Erlaubt gleichzeitigen Zugriff | Vermindert Probleme |
+| Mehr mögliche Nebenwirkungen | Mehr Systemressourcen |
+| Höhere Performance | Höhere Blockierungswahrscheinlichkeit |
+
+### Isolationsstufen nach ANSI/ISO SQL92 (Folien 25–26)
+
+| Isolationsstufe | Verhindert | Besonderheit |
+|---|---|---|
+| **READ UNCOMMITTED** | — | Dirty Read erlaubt; **fehlt in Oracle** |
+| **READ COMMITTED** | Dirty Read | Standard in Oracle; Lesesperren werden kurz gesetzt und aufgehoben |
+| **REPEATABLE READ** | Dirty Read, Non-Repeatable Read | Sperren für gesamte Transaktion; **fehlt in Oracle** |
+| **SERIALIZABLE** | Dirty Read, Non-Repeatable Read, Phantom Read, Lost Update | Höchste Stufe; keine weiteren schreibenden Transaktionen auf dieselben Daten |
+
+**Hinweis:** Der SQL-Standard schreibt diese Stufen vor, aber konkrete Datenbanken unterstützen sie **unterschiedlich**.
+
+---
+
+## 7. Synchronisationsstrategien (Folie 27)
+
+Der **Scheduler** steuert die Ausführungsreihenfolge von Operationen verschiedener Transaktionen.
+
+| Strategie | Beschreibung |
+|---|---|
+| **Pessimistisch** | Scheduler **verzögert** Operationen, legt optimale Reihenfolge fest |
+| **Optimistisch** | Scheduler schickt Operationen **sofort** zur Ausführung |
+
+---
+
+## 8. Synchronisationsverfahren (Folien 28–30)
+
+### 8.1 Sperrbasierte Synchronisation (Folie 28)
+
+Wird **oft eingesetzt**. Idee:
+
+| Regel | Beschreibung |
+|---|---|
+| Jedes Datenobjekt hat eine Sperre | Tabelle, Datensatz, Attribut, Index, View |
+| Sperren vor Benutzung | Jedes Objekt muss vor Zugriff gesperrt werden |
+| Warten bei Sperre | Ist Objekt schon gesperrt, muss die Transaktion warten |
+| Exklusivität | Nur **eine** Transaktion kann die Sperre halten |
+| **Lesesperre** (shared lock) | Andere Transaktionen dürfen die Daten **lesen** |
+| **Schreibsperre** (exclusive lock) | Andere Transaktionen dürfen Daten **weder lesen noch ändern** |
+| Sperren aufheben | Am Ende der Transaktion werden **alle Sperren** aufgehoben |
+
+**Löst:** Alle Probleme **außer Phantom Read**.
+
+### 2-Phasen-Sperrprotokoll – 2PL (Folie 29)
+
+| Phase | Beschreibung | Sicherste Variante |
+|---|---|---|
+| **Wachstumsphase** | Viele Sperren werden **angefordert**, wenige freigegeben | Sperren werden nur **gesetzt**, nicht aufgehoben |
+| **Minderungsphase** (Schrumpfphase) | Viele Sperren werden **freigegeben**, wenige angefordert | Sperren werden nur **aufgehoben**, nicht gesetzt |
+
+### 8.2 Zeitstempelbasierte Synchronisation (Folie 30)
+
+Wird **selten eingesetzt**. Idee:
+
+| Regel | Beschreibung |
+|---|---|
+| Eindeutiger Zeitstempel | Jede Transaktion bekommt einen eindeutigen Zeitstempel |
+| Ordnung | Scheduler ordnet konkurrierende Operationen nach Zeitstempel |
+| Objektstempel | Zu jedem Datenobjekt wird der Zeitstempel der letzten Operation gespeichert |
+| Abweisung | Operation mit **früherem** Zeitstempel als der des Objektes wird **abgewiesen** |
+| Reihenfolge | Transaktionen müssen laut Zeitstempelreihenfolge beendet werden |
+
+**Löst:** Alle Probleme **außer Phantom Read**.
+
+---
+
+## Zusammenfassung
+
+| Konzept | Beschreibung |
+|---|---|
+| **Transaktion** | Atomare Operation: alles oder nichts (COMMIT/ROLLBACK) |
+| **ACID** | Atomicity, Consistency, Isolation, Durability |
+| **Lost Update** | Überschreiben von Änderungen → SERIALIZABLE |
+| **Dirty Read** | Lesen nicht festgeschriebener Daten → READ COMMITTED |
+| **Non-Repeatable Read** | Unterschiedliche Leseergebnisse → SERIALIZABLE |
+| **Phantom Read** | Geänderte Zeilenanzahl → SERIALIZABLE |
+| **Sperrbasiert (2PL)** | Wachstums- und Schrumpfphase, shared/exclusive locks |
+| **Zeitstempelbasiert** | Ordnung nach Transaktions-Zeitstempeln |