• Transaktion
  Folge von Aktionen (read/write) die die DB von einem konsistenten Zustand in einen anderen Konsistenten Zustand überführt.
• Hauptaufgabe der Transaktionen - Verwaltung
  • Synchronisation (Koordination von mehreren Benutzerproxessen ⇒ Logische Einbenutzerbetrieb)
  • Recovery (Behebung von Fehlersituationen)
• Eigenschaften von Transaktionen (ACID-Prinzip)
  • Atomicy (Atomarität: EffektTransaktion trifft ganz oder gar icht in ???)
  • Consistency (Konsistenz/Integritätserhaltung: Konsistenter Zustand ⇒ Konsistenter Zustand)
  • Isolation (Isoliertheit: Logischer Einbenutzerbetrieb)
  • Durability (Dauerhaftigkeit, Persistenz)
• Schedule
  Folge von Aktionen (read/write) für eine Menge $\{T_1, \ldots, T_n\}$ von Transaktionen, die durch Mischen der Aktionen der Transaktionen entsteht, wobei die Reihenfolge innerhalb der Transaktionen beibehalten wird.
• Serieller Schedule
  Schedule S von $\{T_1, \ldots, T_n\}$, in dem die Aktionen der einzelnen Transaktionen nicht unter einander verzahnt sind, sondern sin Blöcken hintereinander ausgeführt werden
• Serialisierbarer Schedule
  Schedule S von $\{T_1, \ldots, T_n\}$, der die selbe Wirkung hat, wie ein belibiger serieller von $\{T_1, \ldots, T_n\}$ ⇒ Nur serialisierbarer Schedules dürfen zugelassen werden!

Mögliche Abhängigkeiten

• rw
• wr
• ww

Für $S_1$ $T_1$ = (r(v), w(v)) $T_2$ = (w(x), w(w), r(v)) $T_3$ = (w(z), r(y), w(x)) $T_4$ = (r(w), r(z), W(y))

⇒ Gleiche Tranasktions- & Aktionsmenge!

Abhängigkeiten:

• $S_1$: $rw_{4,2}(w), wr_{1,2}(v), wr_{3,4}(z), ww_{2,3}(x), rw_{3,4}(y)$
• $S_2$: $rw_{4,2}(w), wr_{1,2}(v), ww_{2,3}(x), rw_{4,3}(z), rw_{3,4}(y)$

⇒ $S_1$ & $S_2$ sind nicht Konfliktäquivalent!

⇒ Gleiche Tranasktions- & Aktionsmenge!

Abhängigkeiten:

• $S_1$: $rw_{4,2}(w), wr_{1,2}(v), wr_{3,4}(z), ww_{2,3}(x), rw_{3,4}(y)$
• $S_3$: $wr_{3,4}(z), wr_{1,2}(v), ww_{2,3}(x), rw_{4,2}(w), rw_{3,4}(y)$

⇒ $S_1$ & $S_2$ sind Konfliktäquivalent!

Serialisierungs-/Abhängigkeitsgraph:

• Knoten: Transaktionen
• Kanten: Abhängigkeiten
• Zyklenfrei: Topologische Ordnung = serielle Ausführung
• enthält zyklen: S ist nicht seriallisierbar

a) T1, T2, T4, T3 oder T1, T4, T2, T3 b) nicht serialisierbar

• a): Lost Update $S(r_1(x), w_2(x), w_1(x))$
  ⇒ Änderungen einer Transaktion werden durch eine andere Transaktion überschrieben und gehen verloren.
• b): Dirty Read/Write: $S(w_1(x), r_2(x), w_1(x))$
  ⇒ Zugriff auf “Schmutzige” Daten ⇒ Objekte, die von einer noch nicht beendenen Transaktion geändert werden
• c): Non-Repeatable Read: $S(r_1(x). w_2(x), r_1(x)$
  ⇒ Transaktion liest unterschiedliche Werte des selben Objekts

⇒ Annomalien können nur auftreten, wenn Isolation verletzt wird!

• DB-Anwendung
• DBS
  • DBMS
  • DB

• Integration einheitlicher Zugriff auf alle Daten einer Anwendung
• Operationen auf den Daten (ändern, löschen, …)
• Data Dictionary Schema anschauen
• Benutzersicheten views
• Konsistenzüberwachung bei Änderung
• Zugriffskontrolle
• Transaktionen
• Synchronisation (Mehrbenutzersystem)
• Datensicherung

• Datensystem (deskriptive Anfragen, Mengenzugriffe)
• Zugriffssystem (Satzzugriffe)
• Speichersystem (Seitenzugriffe)
• DB (Blocktransfer)

Neben an:

• Transfermanagement???
• Metadatenverwaltung

Drüber:

• Anwendung

• Atomic (Wenn, dann wird man als ganzes abgebrochen)
• Consistency (Konsistenter Zystand → Konsistenter Zustand)
• Isolation (Man muss sich aleine fühlen)
• Durability (Abgeschlossene Transaktionen sind von dauer)

Non-repeatable read mit Aggregiertem read

Graph Zeichen

• Knoten: Transaktionen
• Kanten: Abhängigkeiten

Kein rr(x)

Zyklenfrei? ⇒ Serialisierbar durch topologisches sorieren

• Pessimistische Ablaufsteuerung (Locking)
• Optimistische Ablaufsteuerung (Zeitstempelverfahren)
  Notfalls rollback