\section{Transaktionen und ihre Realisierung}

Transaktionen als Kooperationsmodell, Eigenschaften von Transaktionen
Isolation von Transaktionen:

\begin{itemize}
\item Terminologie und Formalisierung
\item Klassifikation der Probleme durch Verletzung der Isolation
\item Isolation durch Sperrprotokolle
\item Diskussion: Vor- und Nachteile niedriger Isolationsgrade
\end{itemize}

Datenmodelle und Kooperationsmodelle

Datenmodelle:
\begin{itemize}
\item Datenbanksprachen unterscheiden sich haupts"achlich in ihrer
  M"achtigkeit bei der Beschreibung der Struktur und des Zustandes der
  Datenbanken.

\item Ziel: (vgl. Kapitel 2-5): Problemangepa"ste Datenstrukturen und
  deklarative Anfragen f"ur Nutzer der Datenbank
\end{itemize}

Kooperationsmodelle:
\begin{itemize}
\item Weitgehend orthogonal zur Wahl des Datenmodells ist das
  Kooperationsmodell.

\item Ziel: Problemangepa"ste Mechanismen zur Synchronisation und
  Fehlererholung von nebenl"aufigen Aktivit"aten auf dem gemeinsamen
  Datenbankzustand

\item Transaktionen sind das allgemein in Theorie und Praxis akzeptierte Kooperationsmodell.

\item Andere Ans"atze: Private und "offentliche Arbeitsumgebungen
  (workspaces bei CASE), Message Passing (nebenl"aufige
  Programmierung), Replizierte Datenbanken mit manueller
  Konfliktaufl"osung (Groupware, sehr gut geeignet f"ur autonome mobile
  Aktoren).
\end{itemize}

Transaktionen f"ur kooperierende Aktivit"aten

\begin{itemize}
\item Kooperation mehrerer Gesch"aftsprozesse "uber Seiteneffekte auf
  gemeinsamen Daten

\item Idee: Der gemeinsame Datenbankzustand ist ein Abbild des
  aktuellen Zustands der gemeinsamen Realit"at der nebenl"aufigen
  Gesch"aftsprozesse.

  Beispiele: Buchhaltung, Lagerwirtschaft, Logistik, ...

\item Das Datenbanksystem sorgt implizit f"ur Synchronisation und
  Fehlererholung der Zustands"anderungen, die durch die
  Gesch"aftsprozesse ausgel"ost werden.

\item Der Programmierer ergreift keine expliziten Ma"snahmen zur
  Synchronisation und Fehlererholung.
\end{itemize}

Grunds"atzlich sind Transaktionen auch als Bausteine f"ur komplexere,
anwendungsbezogene Kooperationsmodelle geeignet (s. Beispiel
"betriebswirtschafltiche Transaktionen" in SAP R/3).

Definition: Transaktion Eine Transaktion ist eine Folge von
"zusammengeh"origen" Operationen auf dem Systemzustand, die die
folgenden Kriterien erf"ullt (ACID-Eigenschaften):

\begin{itemize}
\item Atomarit"at: Die "Anderungen des Systemzustands sind atomar, d.h.
  entweder finden alle oder keine statt. Diese "Anderungen umfassen
  Datenbankzustands"anderungen, Nachrichten und Aktionen auf externen
  Ger"aten.

\item Konsistenz: Eine Transaktion stellt eine konsistente
  Transformation des Datenbankzustands dar, wenn die Gesamtheit ihrer
  Aktionen keine der Integrit"atsbedingungen, die f"ur den
  Datenbankzustand definiert sind, verletzt.

\item Isolation: Obwohl Transaktionen nebenl"aufig ausgef"uhrt werden,
  erscheint es f"ur jede Transaktion T, als ob jede einzelne der
  nebenl"aufigen Transaktionen entweder als ganzes vor oder als ganzes
  nach T ausgef"uhrt wird. (Serialisierbarkeit)

\item Dauerhaftigkeit: Wenn eine Transaktion erfolgreich abgeschlossen
  ist, "uberleben ihre "Anderungen des Datenbankzustands auch alle
  sp"ateren Systemausf"alle.
\end{itemize}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/111.eps}
\caption{Beispiel: Projektdatenbank}
\label{Beispiel: Projektdatenbank}  
\end{center}
\end{figure}

Einstellung Mitarbeiter:
\begin{xple}
\key{begin work}
   SQL-Anfragen
   SQL-"Anderungsoperationen
\key{end work}
\end{xple}

\subsection{Atomarit"at}

Vorteile:
\begin{itemize}
\item Klare Fehlersemantik in komplexen Systemen.

\item Schutz des gesamten Datenbestands, der meist wesentlich
  wertvoller als die einzelnen Zustands"anderungen einer Transaktion
  ist.

\item M"oglichkeit zum R"ucksetzen von Anwendungstransaktionen im Falle
  von Verklemmungen, "Uberlastsituationen, ...
\end{itemize}

Probleme:
\begin{itemize}
\item R"ucksetzbarkeit von "realen" Operationen (Geld auszahlen, Rakete
  abschie"sen, ...)

\item Programmgesteuerte Reaktion auf ROLLBACK
  \begin{itemize}
  \item Restaurieren des Bildschirminhalts, des Zustands von Dateien, ...
  \item Benachrichtigung des Benutzers, ...
  \end{itemize}
\end{itemize}

\subsection{Konsistenz}

\begin{itemize}
\item In der Praxis ein rein syntaktisches Kriterium: Jede
  sequentielle Anweisungsfolge zwischen \key{begin work} und \key{commit work}
  erzeugt im Einbenutzerbetrieb aus einem konsistenten
  Datenbankzustand einen konsistenten Datenbankzustand.

\item Alternativ: Test statischer semantischer Konsistenzbedingungen
  durch den Datenmanager (Schl"usselintegrit"at, ...)

\item Au"serdem: Transaktionen wahren dynamische Konsistenzbedingungen
  (z.B. "Geh"alter fallen nie").

\item Das R"ucksetzen von Transaktionen f"uhrt immer zu einem
  konsistenten Zustand.
\end{itemize}

Probleme:
\begin{itemize}
\item Wer sichert die Konsistenz zwischen Datenbankzustand und
  Realit"at ("Korrektheit von Transaktionen")?
\end{itemize}

\subsection{Isolation}

Durch die ungesch"utzte parallele Ausf"uhrung der
Transaktionensanweisungen k"onnen Inkonsistenzen entstehen, auch wenn
die einzelnen Transaktionen konsistent sind.

Idee: 

\begin{itemize}
\item Transaktionen enthalten keine expliziten Synchronisationsbefehle
  (Zugriff auf Semaphore, Mutexe, Sperren, Nachrichtenschlangen, ...)

\item Es existieren keine relevanten Reihenfolgeabh"angigkeiten
  zwischen nebenl"aufigen Transaktionen (s. Beispiel: Einstellung /
  Gehaltserh"ohung), d.h.  jede serielle Ausf"uhrungsreihenfolge ist
  "erlaubt".
\end{itemize}

"Uberblick:
\begin{itemize}
\item Modellbildung (Transaktionsabh"angigkeiten)

\item Klassifikation der Probleme aufgrund fehlender Isolation
  (Anomalien)

\item Formalisierung des Begriffs der Isolation (Serialisierbarkeit)

\item Techniken zur Isolation von Transaktionen (Sperren)
\end{itemize}

\subsection{Dauerhaftigkeit und Fehlererholung}

R"ucksetzen der Transaktion (\key{rollback}, \key{undo}), falls

\begin{itemize}
\item Systemfehler oder Integrit"atsverletzung w"ahrend der
  Transaktionsausf"uhrung oder w"ahrend \key{commit work}

\item \ky{rollback}-Befehl
\end{itemize}

Wiederherstellen der Transaktionseffekte (\key{redo}), falls
\begin{itemize}
\item Systemfehler nach erfolgreichem \key{commit work} basierend auf
  Logdateien, Archivkopien, dem Zustand von Spiegelsystemen, ...
\end{itemize}

Betrifft eine Transaktion mehr als einen Datenmanager, so mu"s am
Transaktionsende ein Zwei-Phasen-Commit-Protokoll stattfinden:

\begin{description}
\item[Phase 1:] Feststellen der Commitf"ahigkeit: Der
  Transaktionsmanager schickt allen Datenmanagern eine \e{prepare to
  commit} Nachricht. Nur wenn alle Datenmanager mit "JA" antworten,
  wird die Commitf"ahigkeit festgestellt.

\item[Phase 2:] Propagieren der getroffenen Entscheidung: Der
  Transaktionsmanager schickt allen Datenmanagern eine \e{commit} bzw.
  eine \e{abort} Nachricht.
\end{description}


\subsection{Transaktionen}

Transaktionen sind Folgen von Einzelaktionen, die zwischen \ky{begin}
und \key{commit} oder \key{rollback} stattfinden.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/112.eps}
\caption{Beipiel zweier Transaktionen}
\label{Beipiel zweier Transaktionen}
\end{center}
\end{figure}
  
Symbolische Repr"asentation einer Transaktion:
$< < t, a_i, o_k > | i = 1, ..., n; k = 1, ..., m >$

Der i-te Schritt der Transaktion t f"uhrt die Einzelaktion ai  auf dem Objekt ok durch.

Isolation von Transaktionen

Ziel:
\begin{itemize}
\item Datenbankhistorien: Beschreibung der nebenl"aufigen
  ("verzahnten") Ausf"uhrung von Transaktionen.
\end{itemize}

Hilfsbegriffe:
\begin{itemize}
\item Datenbankzustand

\item Operation auf Objekt (Komponente des Datenbankzustands)

\item Abh"angigkeiten zwischen Operationen

\item Transaktion (mit impliziter und expliziter Fehlererholung)

\end{itemize}

Parallel wird das Konzept der Sperren auf Objekten eingef"uhrt.

Anschlie"send wird gezeigt, da"s durch geeignete Sperrprotokolle (=
Sperralgorithmen) nur "erw"unschte" Datenbankhistorien zugelassen
werden.

Einzelaktionen

Generische Aktionen:
\begin{table}
\begin{center}
\begin{tabular}{|l|l|}
\hline
&  \\
\raisebox{1.5ex}[0cm][0cm] {\bf{Generische Aktion}}
 & \raisebox{1.5ex}[0cm][0cm] {\bf{Beschreibung}} \\
\hline
\hline
\key{begin}&   Legt den Anfang einer Transaktion fest.\\
\hline
\key{commit}&  Beendet eine erfolgreich ausgef"uhrte Transaktion.\\
\hline
\key{rollback}&Auf Objekten innerhalb einer Transaktion durchgef"uhrte\\
&                  Manipulationen werden r"uckg"angig gemacht, anschlie"send\\
&                  wird die Transaktion beendet.\\
\hline
\end{tabular}
\caption{}
\label{}
\end{center}
\end{table}

\begin{table}
\begin{center}
\begin{tabular}{|l|l|}
\hline
&   \\
\raisebox{1.5ex}[0cm][0cm] {\bf{Aktionen auf Objekten}}
 & \raisebox{1.5ex}[0cm][0cm] {\bf{Beschreibung}} \\
\hline
\hline
\key{read A} & Liefert den Wert des benannten Objekts A.\\
\hline
\key{write B}& Weist dem benannten Objekt B einen Wert zu und \\
             & erzeugt neue Objektversion.\\
\hline
\key{xlock B}& Setzt X-Sperre (exklusiv) f"ur Manipulation des Objekts B.\\
\hline
\key{slock A}& Setzt S-Sperre (shared) f"ur Lesen des Objekts A.\\
\hline
\key{unlock B}& Gibt Sperre f"ur Objekt B frei.\\
\hline
\end{tabular}
\caption{}
\label{}
\end{center}
\end{table}

Sperrkompatibilit"atsmatrix

Ziel von Sperrprotokollen:
\begin{itemize}
\item Erzeugung von serialisierbaren Historien

\item Dazu m"ussen Lese- und Schreibaktionen in einer bestimmten
  Systematik verwendet werden (Zweiphasen-Sperrprotokoll).
\end{itemize}

\begin{table}
\begin{center}
\begin{tabular}{|l|l|l|}
\hline
& &   \\
\raisebox{1.5ex}[0cm][0cm] {\bf{Sperranforderung}}
 & \raisebox{1.5ex}[0cm][0cm] {\bf{Sperrmodus}}
 & \raisebox{1.5ex}[0cm][0cm] {\bf{Kompatibilit"at}} \\
\hline
\hline
shared & shared &kompatibel \\
\hline
exklusiv & shared&Konflikt\\
\hline
shared & exklusiv&Konflikt\\
\hline
exklusiv & exklusiv&Konflikt\\
\hline
\end{tabular}
\caption{}
\label{}
\end{center}
\end{table}

\begin{itemize}
\item Ist eine Sperranforderung gew"ahrt worden, wird die Exekution
  fortgesetzt.

\item Ist eine Sperranforderung nicht gew"ahrt worden, wird die
  Exekution vorerst angehalten.
\end{itemize}

Notation
\begin{itemize}
\item Folgen S, T

\item Konkatenation S || T

\item i-tes Element einer Folge S

\item Teilfolge S' von S

\item Geordnetes Paar als zweielementige Folge

\item Zustand Z eines Systems
\end{itemize}

\subsection{Transaktionsvereinfachung}

Transaktionen k"onnen dadurch vereinfacht werden, da"s die Aktionen
\key{begin}, \key{commit} und \key{rollback} durch die Aktionen
\key{read}, \key{write}, \key{lock} und \key{unlock} substituiert
sind.

Transaktionsvereinfachung:
\begin{itemize}
\item Verzichte auf \key{begin}.

\item Ersetze \key{commit} durch:
   $<$ \key{unlock A} | falls \key{slock A} oder \key{xlock A} in T vorkommt $>$

\item Ersetze \key{rollback} durch:
   $<$ \key{write A} | falls \key{write A} in T vorkommt $>$ ||
   $<$ \key{unlock A} | falls \key{slock A} oder \key{xlock A} in T vorkommt $>$

\item Beispiel: T1' und T2' auf der n"achsten Folie
\end{itemize}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/113.eps}
\caption{Beipiel einer Transaktionsvereinfachung}
\label{Beipiel einer Transaktionsvereinfachung}
\end{center}
\end{figure}
  
\subsection{Zweiphasige und wohlgeformte Transaktionen}

Wohlgeformte Transaktion:

\begin{itemize}
\item Jede lock Aktion korrespondiert in systematischer Weise mit den
  Lese- und Schreibaktionen der Transaktion.

\begin{itemize}
\item Vor Leseaktionen erfolgt ein \key{slock}.

\item Vor Schreibaktionen erfolgt ein \key{xlock}.
\end{itemize}

\item Eine Transaktion fordert eine Sperre, die sie schon besitzt,
  nicht erneut an.

\item Sperren anderer Transaktionen m"ussen beachtet
werden (Sperrkompatibilit"atsmatrix).

\item Jede \key{read}, \key{write} und \key{unlock} Aktion
  korrespondiert mit einer \key{lock} Aktion.

\item Auf jede lock Aktion erfolgt eine korrespondierende unlock
  Aktion.

\item Bei EOT mu"s eine Transaktion sp"atestens alle ihre Sperren
  zur"uckgeben.
\end{itemize}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/114.eps}
\caption{Beipiel einer nicht wohlgeformten Transaktion}
\label{Beipiel einer nicht wohlgeformten Transaktion}
\end{center}
\end{figure}

Zweiphasen-Sperrprotokoll:
\begin{itemize}
\item Alle lock Aktionen gehen ihren unlock Aktionen voraus.

\item In der Wachstumsphase $T[1], \ldots , T[j]$ der Transaktion T
  werden Sperren angefordert (lock).

\item In der Schrumpfungsphase $T[j+1], \ldots , T[n]$ werden die
  Sperren zur"uckgegeben (unlock).

\item Wohlgeformte, zweiphasige Transaktionen gen"ugen dem
  Zweiphasen-Sperrprotokoll.
\end{itemize}

Striktes Zweiphasen-Sperrprotokoll:
\begin{itemize}
\item Spezielle Zusatzanforderungen an den Verlauf der Phasen (s.
  n"achste Folie) l"osen Probleme, die "uber die Anforderungen der
  Isolation von Transaktionen hinausgehen (Dauerhaftigkeit,
  Verklemmung, ...).
\end{itemize}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/115.eps}
\caption{Zweiphasen-Sperrprotokoll}
\label{Zweiphasen-Sperrprotokoll}
\end{center}
\end{figure}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/116.eps}
\caption{Striktes Zweiphasen-Sperrprotokoll}
\label{Striktes Zweiphasen-Sperrprotokoll}
\end{center}
\end{figure}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/117.eps}
\caption{Striktes Zweiphasen-Sperrprotokoll mit preclaiming}
\label{Striktes Zweiphasen-Sperrprotokoll mit preclaiming}
\end{center}
\end{figure}

Historien
\begin{itemize}
\item Ziel: Modellierung der parallelen Ausf"uhrung von Transaktionen

\item Folge von Aktionen bestehend aus einer Menge von Transaktionen
  unter Beibehaltung der Teilfolgen innerhalb der einzelnen
  Transaktionen

\item Notation: $H = < < t, a_i, o_k > | i = 1, ..., n; k = 1, ..., m >$
  Ein Schritt einer Historie entspricht einer Aktion $a_i$ der
  Transaktion $t$ auf dem Objekt $o_k$.

\item Serielle Historie: Die Transaktionen werden vollst"andig
  nacheinander ausgef"uhrt. Es entstehen keine Inkonsistenzen aufgrund
  von Nebenl"aufigkeit.

\item Serialisierbare Historie: Eine Historie, die "aquivalent zu einer
  seriellen Historie ist. ("Aquivalenz noch zu definieren!)

\item Sperr-Bedingungen schr"anken die Menge der erlaubten Historien
  ein. Zum Beispiel kann eine Exklusivsperre auf ein Objekt f"ur eine
  Aktion nur dann genehmigt werden, wenn f"ur dieses Objekt nicht schon
  eine Sperre im Rahmen einer anderen Transaktion besteht (s.
  Kompatibilit"at zwischen Anforderungsmodus und Sperrmodus auf Folie
  Sperrkompatibilit"atsmatrix).

\item Legale Historie: Sperren werden ber"ucksichtigt (s.
  Sperrkompatibilit"atsmatrix).
\end{itemize}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/118.eps}
\caption{Beispiel einer legalen und seriellen Historie}
\label{Beispiel einer legalen und seriellen Historie}
\end{center}
\end{figure}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/120.eps}
\caption{Beispiel einer legalen und nicht seriellen Historie}
\label{Beispiel einer legalen und nicht seriellen Historie}
\end{center}
\end{figure}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/122.eps}
\caption{Beispiel einer nicht legale und nicht seriellen Historie}
\label{Beispiel einer nicht legale und nicht seriellen Historie}
\end{center}
\end{figure}

Abh"angigkeiten zwischen Transaktionen in Historien
\begin{itemize}
\item Ziel: Definition des Datenflusses zwischen Transaktionen und
  Vergleich zweier Historien miteinander

\item Eine Transaktion T h"angt von einer Transaktion T' innerhalb
  einer Historie H ab, falls

\begin{itemize}
\item T' Objekte beschrieben hat, die anschlie"send von T gelesen
  oder beschrieben werden oder

\item T' Objekte gelesen hat, die anschlie"send von T beschrieben
  werden.
\end{itemize}

\item "Aquivalente Historie: Zwei Historien besitzen die selben
  Abh"angigkeiten, d.h. ihre Transaktionen greifen lesend und
  schreibend in beiden Historien in der gleichen Reihenfolge auf die
  gleichen Objekte zu.

\item Abh"angigkeitsgraphen beschreiben die Abh"angigkeiten zwischen
  Transaktionen in Historien (s. n"achste Folie).

\item Schmutzige Daten sind Daten, auf die Transaktion T zugreifen
  kann, die aber potentiell von nebenl"aufigen Transaktionen T'
  ge"andert werden k"onnen.
\end{itemize}

\subsection{Abh"angigkeitsgraphen}

Kritische Elementarsituationen

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/124.eps}
\caption{Ausf"uhrungssequenzen}
\label{Ausf"uhrungssequenzen}
\end{center}
\end{figure}

Abgehende Leseabh"angigkeiten (READ�READ) werden nicht ber"ucksichtigt.

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/125.eps}
\caption{Anormale T1/T2 -Abh"angigkeiten (Zyklen)}
\label{Anormale T1/T2 -Abh"angigkeiten (Zyklen)}
\end{center}
\end{figure}

\subsection{Abh"angigkeitszyklen}

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsffile{Bilder/PostScript/126.eps}
\caption{Abh"angigkeitsgraph mit m"oglicher serieller Historie (T1, T2, T3, T4, T5, T6)}
\label{Abh"angigkeitsgraph mit m"oglicher serieller Historie (T1, T2, T3, T4, T5, T6)}
\end{center}
\end{figure}

\begin{figure}[hbt]
\begin{center}
\leavevmode \epsffile{Bilder/PostScript/127.eps}
\caption{Abh"angigkeitsgraph ohne m"ogliche serielle Historie}
\label{Abh"angigkeitsgraph ohne m"ogliche serielle Historie}
\end{center}
\end{figure}

F"ur die linke Seite (s. vorige Folie) gilt:

\begin{itemize}
\item $VOR(T4) = \{T1, T3\}$ und $NACH(T4) = \{T6\}$.  T2 und T5 sind deshalb
  weder vor noch nach T4 und k"onnen deshalb nebenl"aufig zu T4
  ausgef"uhrt werden.

  T2, T4 und T5 k"onnen in beliebiger Reihenfolge und beliebig
  "uberlappend ausgef"uhrt werden.

\item Die Relation $<<<$ hat keine Zyklen und definiert eine partielle
  Ordnung der Transaktionen.
\end{itemize}

F"ur die rechte Seite (s. vorige Folie) gilt:

\begin{itemize}
\item $VOR(T4) = \{T1, T3, T4, T5, T6\}$

\item Die Relation $<<<$ hat Zyklen (keine Serialisierbarkeit)
\end{itemize}

Folgende Aussagen sind "aquivalent (ohne Beweis):

\begin{itemize}
\item Wenn f"ur zwei Transaktionen T und T' gilt, da"s Teile von T
  vor T' und Teile von T' vor T ausgef"uhrt werden, dann liegt
  eine Nebenl"aufigkeitsanomalie vor, anderenfalls gibt es keine
  Nebenl"aufigkeitsanomalie.

\item Hat der Abh"angigkeitsgraph Zyklen, gibt es keine "aquivalente
  serialisierbare Historie; ist er zyklenfrei, so existiert mindestens
  eine serialisierbare Historie.

\item Eine serialisierbare Historie entsteht (genau) dann, wenn alle
  nebenl"aufigen Transaktionen dem Zweiphasen-Sperrprotokoll gen"ugen.
\end{itemize}

\subsection{Niedrige Grade der Isolation}

\begin{itemize}
\item Isolation wird von den meisten Systemen aus Performanzgr"unden
  nicht in vollem Umfang geboten.  Es werden nur
  WRITE$\rightarrow$WRITE und WRITE$\rightarrow$READ Abh"angigkeiten
  ber"ucksichtigt (\e{cursor stability}, \e{repeatable reads}).
  READ$\rightarrow$WRITE Abh"angigkeiten werden meist ignoriert.

\item Der ANSI SQL-Standard schreibt volle Isolation vor (Grad 3).
\end{itemize}

\begin{description}
\item[Grad 0:] Eine 0� Transaktion "uberschreibt keine schmutzigen
  Daten einer anderen Transaktion, wenn diese mindestens Grad 1 hat.

\item[Grad 1:] 1� Transaktionen haben keine verlorengegangenen "Anderungen.

\item[Grad 2:] 2� Transaktionen haben keine verlorengegangenen
  "Anderungen und keine schmutzige Leseoperationen.

\item[Grad 3:] 3� Transaktionen haben keine verlorengegangenen
  "Anderungen und nur wiederholbare Leseoperationen.
\end{description}

Sperrprotokolle der Isolationsgrade haben die folgenden Eigenschaften:
\begin{description}
\item[Grad 0:] Wohlgeformt in bezug auf Schreiboperationen (anarchy)

\item[Grad 1:] Zweiphasig in bezug auf exklusive Sperren und
  wohlgeformt in bezug auf Schreiboperationen (browse)

\item[Grad 2:] Zweiphasig in bezug auf exklusive Sperren und
  wohlgeformt (cursor stability)

\item[Grad 3:] Zweiphasig und wohlgeformt (isolated, serializable,
  repeatable reads)
\end{description}

Die Isolationsgrade entsprechen den Abh"angigkeiten: 

1� "O WRITE$\rightarrow$WRITE
2� "O WRITE$\rightarrow$WRITE, WRITE$\rightarrow$READ
3� "O WRITE$\rightarrow$WRITE, WRITE$\rightarrow$READ, READ$\rightarrow$WRITE


Isolationstheorem:

Erf"ullt eine Transaktion das 0�, 1�, 2� oder 3� Sperrprotokoll, so
erreicht sie Isolationsgrad 1�, 2� oder 3� in jeder legalen Historie,
wenn alle anderen Transaktioen mindestens vom Grad 1� sind.

\begin{itemize}
\item In der Praxis bedeutet dies: Der Grad der eigenen Transaktion
  kann unabh"angig von anderen Transaktionen gew"ahlt werden.

\item Ausnahme: Eingabedaten von 1� Transaktionen sind m"oglicherweise
  schmutzig.  Werden diese Daten zum Aktualisieren der Datenbank
  verwendet, k"onnen andere Transaktionen inkonsistente Daten bekommen.
  Das Theorem geht deshalb davon aus, da"s 1� Transaktionen "wissen,
  was sie tun".

\item Konklusion: Auch wenn eine Transaktion schmutzig Daten liest,
  nimmt man an, da"s sie die Datenbank in einen konsistenten Zustand
  transformiert. Viele Systeme lassen 1� Isolationverhalten nur f"ur
  Lese-Transaktionen zu.
\end{itemize}
 
\subsection{Grade der Isolation in SQL}

\begin{itemize}
\item Transaktionen mit niedrigen Isolationsgraden ben"otigen weniger
  Sperren, halten diese f"ur eine k"urzere Zeit und sorgen somit f"ur
  bessere Performanz.

\item 2� Isolation erlaubt es Transaktionen, die gesamte Datenbank
  abzusuchen und dabei wenig Sperren zu halten und somit andere
  Transaktionen nicht zu st"oren.
\end{itemize}

\begin{itemize}
\item Volle Isolation kann nur bei Grad 3 erreicht werden.

\item SQL stellt die folgenden Optionen bereit:
\key{set transaction}
\key{isolation level}
\end{itemize}

\begin{table}
\begin{center}
\begin{tabular}{|l|l|}
\hline
&   \\
\raisebox{1.5ex}[0cm][0cm] {\bf{Kommando}}
 & \raisebox{1.5ex}[0cm][0cm] {\bf{Isolationsgrad}} \\
\hline
\hline
\key{read uncommitted} & Grad 1 \\
\hline
\key{read committed} & Grad 2 \\
\hline
\key{repeatable read} & Grad 2,9999 \\
\hline
\key{serializable} & Grad 3 \\
\hline
\end{tabular}
\caption{Isolationsgrade in SQL}
\label{Isolationsgrade in SQL}
\end{center}
\end{table}

\subsection{Cursor stability}

\begin{itemize}
\item In SQL wird "ublicherweise eine Islolation implementiert, die
  mehr Konsistenz als Grad 2 bietet (cursor stability).
\end{itemize}

\begin{figure}[hbt]
\hrule \medskip
\footnotesize{
\begin{xple}
\key{exec} \key{sql} \key{declare} \key{cursor} c \key{for}
         \key{set} gehalt
         \key{from} mitarbeiter
         \key{where} no = nr;
\key{exec} \key{sql} \key{open} c;
\key{exec} \key{sql} \key{fetch} c \key{into} :gehalt;
gehalt = gehalt * 1.5;
\key{exec} \key{sql} \key{update} mitarbeiter
         \key{set} gehalt = :gehalt;
         \key{where} no = nr;
\key{exec} \key{sql} \key{close} c;
\end{xple}}
\hrule
\caption{Cursor stability}
\label{Cursor stability}
\end{figure}   

\begin{figure}[hbt]
\hrule \medskip
\footnotesize{
\begin{xple}
\key{exec} \key{sql} \key{select} gehalt
         \key{into} :gehalt
         \key{from} mitarbeiter
         \key{where} no = nr;
gehalt = gehalt * 1.5
\key{exec} \key{sql} \key{update} mitarbeiter
         \key{set} gehalt = :gehalt
         \key{where} no = nr;
\end{xple}}
\hrule
\caption{Verlorengegangene "Anderungen mit 2� Isolation}
\label{Verlorengegangene "Anderungen mit 2� Isolation}
\end{figure}   

\begin{figure}[hbt]
\hrule \medskip
\footnotesize{
\begin{xple}
\key{exec} \key{sql} \key{update} mitarbeiter
         \key{set} gehalt = gehalt * 1.5
         \key{where} no = nr;
\end{xple}}
\hrule
\caption{Searched Update f"ur 1� oder 2�}
\label{Searched Update f"ur 1� oder 2�}
\end{figure}   

Zusammenfassung: Niedrige Isolationsgrade 

Vorteile:

\begin{itemize}
\item Daten sind nur kurze Zeit gesperrt.

\item Weniger Daten werden gesperrt.

\item Potentiell h"ohere Nebenl"aufigkeit
\end{itemize}

Nachteile:

\begin{itemize}
\item M"oglicherweise inkonsistente Eingabe- und Ausgabedaten

\item Eine \key{rollback} Operation mu"s f"ur ihre Aktionen Sperren setzen.

\item 0� Transaktionen unterst"utzen kein ROLLBACK.

\item F"ur reine Lesetransaktionen gilt 0� = 1�.
\end{itemize}

Die Eigenschaften niedriger Isolationsgrade sind in den folgenden
Tabellen nochmals gegen"ubergestellt.
 
\begin{table}
\begin{center}
\begin{tabular}{|l|p{3cm}|p{3cm}|p{3cm}|p{3cm}|}
\hline
& & & &  \\
\raisebox{1.5ex}[0cm][0cm] {\bf{}}
& \raisebox{1.5ex}[0cm][0cm] {\bf{Grad 0}}
& \raisebox{1.5ex}[0cm][0cm] {\bf{Grad 1}}
& \raisebox{1.5ex}[0cm][0cm] {\bf{Grad 2}}
 & \raisebox{1.5ex}[0cm][0cm] {\bf{Grad 3}} \\
\hline
\hline
Name &Chaos&Browse&Cursor Stability&Repeatable Read (Serialisierbar \\ \hline
Schutz&St"ort keine Trasaktionen h"oheren Grades&
       0� und keine verlorengegangenen "Anderungen&
       Keine verlorengegangenen "Anderungen, keine schmutzigen Leseoperationen&
       Keine verlorengegangenen "Anderungen, keine schmutzigen Leseoperationen,
       wiederholbare Leseoperationen \\ \hline
\end{tabular}
\caption{}
\label{}
\end{center}
\end{table}
