Add 'idb_skript/' from commit 'c58e48248db6a8d8856da9d232901f90d2f76434'

git-subtree-dir: idb_skript
git-subtree-mainline: d4458978d8
git-subtree-split: c58e48248d

idb_skript/.gitignore

@@ -0,0 +1,10 @@
+*.fls
+*.lof
+*.swp*
+*.pdf
+*.aux
+*.out
+*.log
+*.toc
+*.fdb*
+X.tex

idb_skript/Anfrageverarbeitung.tex

@@ -0,0 +1,86 @@
+\section{Anfrageverarbeitung}
+
+\subsection{Allgemein}
+Eine SQL Anfrage ist ein mengenorientierter Zugriff.
+D.h. diese mengenorientierten Operatoren müssen auf satzorientierte
+Operatoren abgebildet werden.
+\subsubsection{Phasen}
+\textbf{Verarbeitungsschritte}:
+\begin{itemize}
+		\item Syntax überprüfen
+		\item Rechte und Integritätsbedingungen (Formate) prüfen
+		\item \textbf{Anfrageoptimierung} um effizient Query zu bearbeiten
+		\item Code Generieung
+\end{itemize}
+\begin{figure}[H]
+		\begin{center}
+				\includegraphics[scale=0.7]{pics/anfrageverarbeitung.png}
+				\caption{Phasen der Anfrageverarbeitung}
+		\end{center}
+\end{figure}
+\textbf{Ziel}:\\
+Umsetzung deskriptiver Anfragen in eine \glqq optimale\grqq Folge
+interner DBS-Operationen
+\subsection{Interndarstellung}
+\subsubsection{Relationale Algebra}
+Definition von relationalen \textbf{logischen Operatoren}:
+\begin{itemize}
+		\item Selektion: Auswahl von \glqq Zeilen\grqq (\textbf{where}-Klausel)
+		\item Projektion Auswahl von \glqq Spalten\grqq (\textbf{select}-Klausel)
+\item Kreuzprodukt: Konkatenation derjenigen Tupel aus zwei Relationen(\textbf{from})
+		\item Verbund: Konkatenation derjenigen Tupel aus zwei Relationen
+				die eine Bedingung erfüllen(\textbf{from-where})
+		\item Mengenoperationen auf zwei Relationen:
+				\begin{itemize}
+						\item $R \cup S$ bzw \textbf{UNION(R,S)}
+						\item $R \cap S$ bzw \textbf{INTERSECT(R,S)}
+						\item $R \setminus S$ bzw \textbf{EXCEPT(R,S)}
+				\end{itemize}
+\end{itemize}
+\subsubsection{Operatorbaum}
+Beispiel:
+\begin{lstlisting}
+select Name, Beruf
+from Abt a, Pers p,
+     PM pm , Projekt pj
+		 where a.ANr = p.ANr
+		 and a.AOrt = "Erlangen"
+		 and p.PNr = pm.PNr
+		 and pm.JNr = pj.JNr
+		 and pj.POrt = "Erlangen"
+\end{lstlisting}
+
+\begin{figure}[H]
+		\begin{center}
+				\includegraphics[scale=0.7]{pics/operatorbaum.png}
+				\caption{Operatorbaum}
+		\end{center}
+\end{figure}
+Blattknoten: Relationen\\
+Gerichtete Kanten: Datenfluss\\
+Knoten: Operatoren der Relationalen Algebra
+\subsection{Restrukturierung}
+Regeln:
+\begin{enumerate}
+		\item Ein n-facher Verbund kann durch eine Folge von binären Verbunden ersetzt und werden und umgekehrt
+		\item Verbund ist kommutativ
+		\item Verbund ist assoziativ
+		\item Selektionen können zusammengefasst werden
+		\item Projektionen können zusammengefasst werden
+		\item Selektionen und Projektionen dürfen vertauscht werden
+		\item Selektionen und Verbund dürfen vertauscht werden
+		\item Selektion darf mit Vereinigung und Differenz vertauscht werden
+		\item Selektion und Kreuzprodukt können zu Verbund zusammengefasst weren
+\end{enumerate}
+\subsubsection{Algorithmus}
+\textbf{Ziel}: Kreuzprodukt vermeiden
+Heuristik:
+\begin{itemize}
+		\item komplexe Verbundoperationen zerlegen in binäre Verbunde (Regel 1)
+		\item Selektionen mit mehreren Prädikat Termen separieren in Selektionen mit jeweils einem Prädikat Term (Regel 4)
+		\item Selektionen so früh wie möglich ausführen (Regel 7 und 8)
+		\item Selektionen und Kreuzprodukt zu Verbund zusammenfassen, wenn
+				das Selektionsprädikat Attribute aus den beiden Relationen verwendet (Regel 9)
+		\item Projektionen so früh wie möglich ausführen, allerdings nicht vor Selektion und Mengenoperationen.
+
+\end{itemize}

idb_skript/BBaum.tex

@@ -0,0 +1,112 @@
+\section{BBaum}
+Idee: Zusammenfassung ganz bestimmter Sätze in einem Block.
+Mehrwegbaum: jeder Knoten entspricht einem Block.
+
+\subsection{Aufbau}
+Am Anfang eines jeden Knotens steht $n$. $n$ ist Anzahl der verwendeten
+Einträge, $k \leq n \leq 2k$ (in root $ 1 \leq n \leq 2k$).
+
+\begin{figure}[H]
+		\begin{center}
+				\includegraphics[scale=1.0]{pics/bbaumknoten.png}
+				\caption{BBaum Knoten}
+		\end{center}
+\end{figure}
+Danach folgen Tripel (Ki,Di,Pi) welche einen \textbf{Eintrag} bilden:
+Ki = Schlüsselwert\\
+Di = Datensatz\\
+Pi = Zeiger auf Nachfolgeknoten
+\subsection{Eigenschaften}
+\begin{itemize}
+		\item jeder Pfad ist perfekt balanciert
+		\item jeder Knoten mit Ausnahme von root und Blättern hat
+				mindesten $k+1$ Nachfolger und höchstens $2k+1$
+		\item jeder Knoten (Ausnahme root) immer mindestens halb voll
+\end{itemize}
+\subsection{Löschvorgang}
+\begin{enumerate}
+		\item Suche Knoten, in dem der zu löschende Schlüssel S liegt
+		\item Falls S in Blattknoten, dann lösche S und behandle ggf Unterlauf
+		\item Fall S in innerem Knoten dann untersuche linken und rechten 
+				Unterbaum von S
+				\begin{itemize}
+						\item finde direkten Vorgänger $\text{S}'$ und Nachfolger $\text{S}''$
+						\item Wähle den aus der mehr Elemente hat
+						\item Ersetze zu löschenden Schlüssel S durch $\text{S}'$ oder $\text{S}''$ aus gewähltem Blattknoten und behandle ggf Unterlauf
+
+				\end{itemize}
+\end{enumerate}
+\subsection{Unterlauf}
+\begin{itemize}
+		\item Ein endgülter Unterlauf entsteht bei obigen Algorithmus erst auf Blattebene
+		\item \textbf{Unterlaufbehandlung} wird durch Mischen des Unterlaufknotens mit seinem Nachbarknoten und darüber liegenden Diskriminator durchgeführt $\rightarrow$ Splitt rückwärts
+		\item Unterlaufbehandlung endet in einem der Blätter!
+\end{itemize}
+\subsection{B*-Baum}
+Alle Sätze werden in den Blattknoten abgelegt. Innere Knoten enthalten nur noch Verzweigungsinformationen, keine Daten.
+Am Ende eines Knotens ist ein Zeiger auf den nächsten enthalten.
+\begin{figure}[H]
+		\begin{center}
+				\includegraphics[scale=1.0]{pics/bstern.png}
+				\caption{B*-Baum Aufbau}
+		\end{center}
+\end{figure}
+\textbf{Merke:}\\
+Beim Löschen von Werten bleibt der gleiche Diskriminator in inneren
+Knoten enthalten.
+\subsubsection{Löschen}
+Entsteht durch das Löschen ein Unterlauf?
+\begin{itemize}
+		\item Nein:\\Entferne Satz aus Blatt
+		\item Ja:\\
+				Mische das Blatt mit einem Nachbarknoten. Ist die 
+				Summe der Einträge in beiden Knoten größer als 2k?
+				\begin{itemize}
+						\item Nein:\\
+								Fass beide Blätter zu einem Blatt zusammen. Falls Unterlauf
+								in Vaterknoten entsteht: Misch die inneren Knoten analog
+						\item Ja:\\
+								Teil die Sätze neu auf beide Knoten auf, so dass ein Knoten
+								jeweils die Hälfte der Sätze übernimmt. Der Diskriminator ist
+								zu aktualisieren.
+
+				\end{itemize}
+\end{itemize}
+\subsection{Vergleich}
+\begin{itemize}
+		\item BBaum:
+				\begin{itemize}
+						\item keine Redundanz
+						\item lesen von Baum Inorder nur mit Stack von Höhe h
+						\item Gergingerer Verzweigungsgrad $\rightarrow$ größere Höhe
+						\item einige wenige Sätze (root) mit 1 Blockzugirff
+				\end{itemize}
+		\item $\text{B}^*$Baum:
+				\begin{itemize}
+						\item Schlüsselwerte teilweise redundant
+						\item Kette von Blattknoten liefert alle Sätze nach Reihenfolge sortiert
+						\item hohe Verzweigung der inneren Knoten $\rightarrow$ geringe Höhe
+						\item für alle Blöcke müssen h Sätze gelesen werden
+						\item Schlüsselwerte der inneren Knoten müssen nicht in den
+								Datensätzen vorkommen
+				\end{itemize}
+\end{itemize}
+\subsection{Bitmap Index}
+\textbf{B-Bäume (und Hashing) machen nur Sinn bei hoher Selektivität! ($\approx 5\%$)}
+Lege für jeden Schlüsselwert eine Bitliste an. Bitwert 1 bedeutet, der
+Schlüssel hat im Satz den Wert zu dem die Liste gehört. 0 bedeutet er hat keinen anderen Wert.\\
+Gut bei Wertigkeiten bis ca. 500. Hilft bei einfacher und effizienter
+Verknüpfung.
+
+\subsection{Primär- und Sekundär-Organisation}
+\textbf{Primär-Organisation}:\\
+Bedeutung: Speicherung der Sätze selbst.
+
+\textbf{Sekundär-Organisation}:\\
+Bedeutung: verweist nur auf Sätze, die nach beliebigen anderen Kriterien
+abgespeichert werden. Ist allerdings nur möglich, wenn Primärorganisation
+Direktzugriff auf einzelnen Satz haben.
+
+$\rightarrow$ B-Baum/$\text{B}^*$Baum als Sekundär Organsiation (Di);
+auch gestreute Speicherung als Sekundär Organsiation möglich (Buckets 
+[Schlüsseltwer,Satzadresse] Paare)

idb_skript/Einfuehrung.tex

@@ -0,0 +1,39 @@
+\section{Einführung}
+\subsection{Basiswissen}
+\begin{enumerate}
+		\item {Warum ein Datenbanksystem benutzen?
+						\begin{itemize}
+								\item vielseitig verwendbar
+								\item Mehrbenutzerbetrieb
+								\item redundanzfrei
+								\item ausfallsicher
+								\item leistungsfähig
+						\end{itemize}
+				}
+		\item {Wozu dient Schichtenbildung in der Softwarearchitektur?
+						\begin{itemize}
+								\item Höhere Ebenen werden einfacher, weil sie tiefere benutzen können
+								\item Änderungen in höheren Ebenen haben keinen Einfluss auf tiefere
+								\item tiefere Ebenen können getestet werden, bevor höhere lauffähig sind
+								\item Optimierungen von unteren Ebenen
+						\end{itemize}
+						Schichtenmodell:
+						\begin{figure}[H]
+								\begin{center}
+										\includegraphics[scale=0.6]{pics/schichten.png}
+										\caption{Schichtenübersicht}
+								\end{center}
+						\end{figure}
+
+				}
+		\item { Was tut eine Schicht:
+						\begin{itemize}
+								\item Realisiert einen bestimmten Dienst, den sie der Schnittstelle nach oben zur Verfügung stellt
+								\item Nimmt Dienste der darunter liegenden Schicht in Anspruch
+								\item Verbirgt darunter liegende Schicht vollständig und muss daher alle erforderlichen Funktionen anbieten
+						\end{itemize}
+				}
+		\item { Was bedeutet Datenunabhängigkeit einer Anwendung:\\
+						Speichern und Wiedergewinnen von persistenten Daten 
+				ohne Kenntnis der Details der Speicherung.}
+\end{enumerate}

idb_skript/IDB.tex

@@ -0,0 +1,113 @@
+\listfiles
+\documentclass[12pt,a4paper]{scrartcl}
+\usepackage[utf8]{inputenc}
+\usepackage[ngerman]{babel}
+\usepackage{graphicx}
+\usepackage{amsmath}
+\usepackage{amssymb}
+\usepackage{amsfonts}
+\usepackage{lmodern}
+\usepackage{a4wide}
+\usepackage{psfrag}
+\usepackage{colortbl}
+\usepackage{color}
+\usepackage{textcomp}
+\usepackage{cancel}
+\usepackage[pdfborder={0 0 0}, colorlinks=true, filecolor=blue, linkcolor=blue, citecolor=blue, urlcolor=blue]{hyperref}
+\usepackage{float}
+\usepackage{listings}
+\usepackage{lstautogobble}
+\usepackage{datetime}
+\usepackage{wrapfig}
+\newcommand{\RM}[1]{\MakeUppercase{\romannumeral #1{.}}} 
+\definecolor{dkgreen}{rgb}{0,0.6,0}
+\definecolor{gray}{rgb}{0.5,0.5,0.5}
+\definecolor{mauve}{rgb}{0.58,0,0.82}
+\lstset{ 
+		basicstyle=\footnotesize, % the size of the fonts that are used for the code
+		breakatwhitespace=false, % sets if automatic breaks should only happen at whitespace
+		breaklines=true, % sets automatic line breaking
+		captionpos=b, % sets the caption-position to bottom
+		commentstyle=\color{dkgreen}, % comment style
+		frame=single, % adds a frame around the code
+		keywordstyle=\color{blue}, % keyword style
+		language=sql, % the language of the code
+		mathescape=true,
+		autogobble,
+		numbers=left % where to put the line-numbers; possible values are (none, left, right)
+		%title=\lstname % show the filename of files included with \lstinputlisting; also try caption instead of title
+}
+\setcounter{secnumdepth}{4}
+\setcounter{tocdepth}{4}
+\setlength{\parindent}{0pt}
+% wrapping environment for pic in paragraphs
+\usepackage{floatflt}
+% Einruecken nach newline via '//' unterbinden
+\setlength{\parindent}{0pt}
+
+\makeatletter
+\renewcommand\paragraph{%
+    \@startsection{paragraph}{4}{0mm}%
+    {-\baselineskip}%
+    {.5\baselineskip}%
+{\normalfont\normalsize\bfseries}}
+\makeatother
+
+%==INFOBOXEN=========================================
+%idee: http://tex.stackexchange.com/a/66822
+\usepackage[tikz]{bclogo}
+\definecolor{YellowGreen}{rgb}{0.603922,0.803922,0.196078}
+%\renewcommand\bcStyleTitre[1]{\large\textcolor{black}{#1}}
+%textbox{Titel}{Text}
+\newcommand{\textbox}[2]{%
+    \begin{bclogo}[couleur=YellowGreen,logo =, arrondi=0.2,barre=none]{#1}%
+        \vspace*{10pt}%
+        #2%
+    \end{bclogo}
+}%
+%textonlybox{Text}
+\newcommand{\textonlybox}[1]{%
+    \begin{bclogo}[couleur=YellowGreen,logo =, arrondi=0.2,barre=none]{#1}
+    \end{bclogo}
+}%
+%----------------------------------------------------
+
+\title{IDB Skript}
+\date{\today ~- \currenttime ~Uhr}
+\begin{document}
+\maketitle
+\noindent{Dieses Skript zur Vorlesung Implementierung von
+    Datenbanksystemen im Wintersemester 2013/14 wurde von 
+    untenstehenden Studenten erarbeitet. Es ist somit 
+    offensichtlich inoffiziell und erhebt weder einen
+    Anspruch auf Korrektheit noch auf Vollständigkeit.
+}
+
+\begin{description}
+    \item[Christian Bay] christian.bay@studium.fau.de
+\end{description}
+
+\vfill
+
+\noindent {
+    \textbf{\footnotesize Dieses Skript ist keine offizielle
+        Veröffentlichung des Lehrstuhls 6 am Department Informatik der
+    Friedrich-Alexander-Universität Erlangen-Nürnberg.}
+}
+
+\newpage
+
+\tableofcontents
+\listoffigures
+\newpage
+\include{./Einfuehrung}
+\include{./Saetze}
+\include{./BBaum}
+\include{./Puffer}
+\include{./Programmschnittstellen}
+\include{./Speicherung}
+\include{./Anfrageverarbeitung}
+\include{./Relationale_Operatoren}
+\include{./Transaktionen}
+
+\end{document}

idb_skript/Makefile

@@ -0,0 +1,18 @@
+PDF = IDB
+
+all: $(PDF) 
+
+continuous: $(PDF).continuous 
+
+%.continuous: %.pdf
+	latexmk -jobname=$(@:%.continuous=%) -pvc -pdf $(@:%.continuous=%).tex
+
+$(PDF): $(PDF).pdf
+
+%.pdf: %.tex
+	latexmk -jobname=$(@:%.pdf=%) -pdf $<
+
+clean:
+	latexmk -c -f
+
+.PHONY: all clean $(PDF) continuous

idb_skript/Programmschnittstellen.tex

@@ -0,0 +1,56 @@
+\section{Programmschnittstellen}
+Vor- und Nachteile:\\
+Programmzugriff:
+\begin{itemize}
+		\item Keine SQL Injection nötig
+		\item Kompakt
+		\item spezieller Übersetzer nötig
+\end{itemize}
+Unterprogrammaufruf
+\begin{itemize}
+		\item Optimierung und Typprüfung
+		\item SQL Injection möglich
+		\item Aufwändig für Programmierer
+\end{itemize}
+\subsection{SQL Anfrage}
+Aufruf einer SQL Anfrage mit Index:
+\begin{lstlisting}[language=java]
+RecordFile index = new KeyedRecordFile("KNr","r");
+TID tid = index.read.Key(23);
+RecordFile saetze = new DirectRecord(Kunden", "r");
+Record ergebnis = saetze.read(tid);
+print(ergebnis.toString());
+\end{lstlisting}
+Aufruf einer SQL Anfrage ohne Index:
+\begin{lstlisting}[language = java]
+RecordFile saetze = new DirectRecordFile("Kunden","r");
+Record ergebnis;
+while (saetze.hasNext()){
+		ergebnis = saetze.next();
+		if(ergebnis.getKNr() == 23){
+				print(ergebnis);
+				break;
+		}
+}
+\end{lstlisting}
+
+\subsection{SQL Schnittstelle}
+\begin{enumerate}
+		\item Verbindung aufbauen
+				\begin{lstlisting}[language=java]
+				Connection DriverManager.connect(username, password, database)
+				\end{lstlisting}
+		\item Methode um eine Anfrage auszuführen
+				\begin{lstlisting}[language=java]
+				Handle Connection.executeQuery (String query);
+				\end{lstlisting}
+		\item Methode um zu prüfen, ob es weitere Ergebnisse gibt
+				\begin{lstlisting}[language=java]
+				Boolean Handle.hasNext();
+				\end{lstlisting}
+		\item Methode um überhaupt an Ergebnisse zu kommen
+			%TODO das soll vermutlich weder vom Typ Boolean sein, noch hasNext() heißen
+				\begin{lstlisting}[language=java]
+				Boolean Handle.hasNext();
+				\end{lstlisting}
+\end{enumerate}

idb_skript/Puffer.tex

@@ -0,0 +1,61 @@
+\section{Puffer}
+Frame = Im HS vorgesehener Platz zur Aufnahme eines Blocks $\rightarrow$ normalerweise so groß wie Block
+
+Bei Zugriff auf Blöcke im HS müssen diese ggf eingelagert werden.
+\subsection{Ersetzungsstrategie}
+\begin{itemize}
+		\item wählt den zu verdrängenden Block aus
+		\item Ziel: Minimierung von physischen Zugriffen
+\end{itemize}
+
+\subsubsection{FIFO}
+Block der am längsten im Puffer ist wird ersetzt.\\ $\rightarrow$ ungünstig
+da häufig benutzte Blöcke gerade im Puffer bleiben sollen
+
+\subsubsection{LFU (least frequently used)}
+Block auf den am seltensten zugegriffen wird ersetzt.
+\begin{itemize}
+		\item $-$ für sequentielles Lesen nicht brauchbar
+		\item $-$ hat ein Block einmal wieder zugegriffen bleibt der lange erhalten
+\end{itemize}
+
+\subsubsection{LRU (least recently used)}
+\begin{itemize}
+		\item bewertetes Alter seit dem letzten Zugriff
+		\item quasi verkettete Liste aller Blöcke im Puffer, wo bei Verdrängung letzter Block der Kette ersetzt wird
+\end{itemize}
+\begin{figure}[H]
+		\begin{center}
+				\includegraphics[scale=0.7]{pics/lru.png}
+				\caption{LRU}
+		\end{center}
+\end{figure}
+\subsubsection{Clock}
+LRU Verhalten mit einfacher Implementierung.
+\textbf{Prinzip}:
+\begin{itemize}
+		\item Benutzt(Dirty)-Bit eines Blocks im Puffer wird bei Zugriff auf
+				1 gesetzt
+		\item bei Verdrängung zyklischer Suche mit dem Auswahlzeiger:
+				\begin{itemize}
+						\item Falls Benutzt Bit = 1, wird es auf 0 gesetzt $\rightarrow$ Zeiger wandert zum nächsten Block
+						\item Falls Benutzt Bit = 0, Block wird ersetzt
+				\end{itemize}
+\end{itemize}
+
+\subsection{Dienste einer Pufferverwaltung}
+Einkapselung der Pufferverwaltung: 
+\begin{lstlisting}[language=C]
+char * Buffer::fix (BlockFile File, int BlockNo, char Mode);
+\end{lstlisting}
+\begin{itemize}
+		\item Block ist vor Verdrängung geschützt
+		\item \textbf{Mode} gibt an welcher Block nur gelesen oder auch
+				geändert werden soll
+\end{itemize}
+\begin{lstlisting}
+void Buffer::unix (char * BufferAddresse)
+\end{lstlisting}
+\begin{itemize}
+		\item gibt Block im Puffer zur Ersetzung frei
+\end{itemize}

idb_skript/Relationale_Operatoren.tex

@@ -0,0 +1,196 @@
+\section{Relationale Operatoren}
+\subsection{Allgemein}
+Die grundsätzliche Aufgabe besteht darin die logischen Operatoren
+(SEL(),PROJ(),JOIN(),\ldots) durch \textbf{Planoperatoren} zu ersetzen.\\
+\textbf{Teilaufgaben}:
+\begin{itemize}
+		\item Erkennung gemeinsamer Teilbäume (notwendig: Zwischenspeicherung
+				von Ergebnisrelation)
+		\item {Bestimmung der Verknüpfungsreihenfolge bei Verbundoperationen:
+						\begin{itemize}
+								\item Ziel: minimale Kosten für die Operationsfolge
+								\item Heuristik: Minimierung der Größe der Zwischenergebnisse, 
+								d.h. kleinsten Relationen immer zuerst verknüpfen
+				\end{itemize}
+		}
+		\item Gruppierung von direkt benachbarten Operatoren zu einem einzelnen Planoperator (z.B. Verbund mit Selektion)
+\end{itemize}
+\subsection{Planoperatoren}
+SQL erlaubt Anfragen über k-Relationen:
+\begin{itemize}
+		\item Ein Variablen Ausdrücke (eine Relation)
+		\item Zwei Variablen Ausdrücke (zwei Relationen)
+		\item k-Variablen Ausdrücke (zerlegt in Ein- und Zwei Variablen Ausdrücke)
+\end{itemize}
+
+\subsubsection{Selektion}
+\begin{itemize}
+		\item Nutzung eines \textbf{Scan}-Operators\\
+				Definition von Start- und Stoppbedingungen sowie Suchargumenten
+		\item Index Scan $\rightarrow$ Auswahl des kostengünstigsten Index
+		\item Relationen Scan
+\end{itemize}
+\subsubsection{Projektion}
+\begin{itemize}
+		\item meist in Kobination mit Verbund, Selektion und Sortierung
+		\item auch als eigener Planoperator
+\end{itemize}
+\subsubsection{Sortierung}
+\begin{itemize}
+		\item erforderlich bei \textbf{order by}
+		\item beschleunigt ggf Joins
+		\item Duplikateleminierung (\textbf{distinct})
+\end{itemize}
+\subsubsection{Joins}
+Joins werden in \textbf{binäre} Verbunde gegliedert. Bei $n$ Verbunden
+sind $n!$ Reihenfolgen möglich. Die optimale Reihenfolge ist abhängig von
+\begin{itemize}
+		\item Planoperatoren
+		\item passenden Sortierordnungen
+		\item Größe der Operanden usw
+\end{itemize}
+Verbundoperationen sind sehr häufig und auch teuer $\rightarrow$ Optimierung.\\
+Typisch sind \textbf{Gleichverbunde}.
+Standartszenario für Verbunde:
+\begin{lstlisting}
+select * from R,S
+where R.VA $\Theta$ S.VA   // Verbundpraedikat
+                           // $\Theta \in \{=, >, <, \neq, \geq, \leq\}$
+and P(R.SA)                // lokale Selektion
+and P(S.SA)                // VA = Verbundattribut
+                           // SA = Selektionsattribut
+
+\end{lstlisting}
+\paragraph{Nested Loop Verbund}
+
+Annahmen:\\
+Sätze in R und S sind nicht nach Verbundsattributen geordnet.\\
+Es sind keine Indexstrukturen $I_R(VA)$ und $I_S(VA)$ vorhanden.
+\begin{lstlisting}
+Scan ueber $S$; //aeussere Schleife
+fuer jeden Satz s, fuer den $P(s.SA)$ gilt:
+     Scan ueber $R$; //innere Schleife
+     fuer jeden Satz r,
+		 fuer den P(r.SA) AND (r.VA $\Theta$ s.VA) gilt:
+          uebernimm kombinierten Satz (r,s)
+          in das Ergebnis;
+\end{lstlisting}
+Komplexität: $\mathcal O(N^2)$
+
+\paragraph{Sort-Merge Verbund}
+
+
+Zweiphasiger Algorithmus:\\
+
+Phasen:
+\begin{enumerate}
+		\item Sortierung von R und S nach R.VA und S.VA, dabei Eliminierung nicht benötigter Tupel (durch Prüfung von P(R.SA) oder P(S.SA))
+		\item schritthaltende Scans über R- und S-Relationen mit Durchführung des Verbundes bei r.VA=s.VA 
+\end{enumerate}
+
+Komplexität: $\mathcal O(N \log N)$
+\begin{figure}[H]
+		\begin{center}
+				\includegraphics[scale=0.7]{pics/merge_sort_join.png}
+				\caption{Merge Sort Verbund}
+		\end{center}
+\end{figure}
+
+\paragraph{Hash Verbund}
+Spezialisierung für \textbf{Gleichverbund}.
+Da der Hauptspeicher immer größer ist, lassen sich Zwischenergebnisse 
+besser ausnutzen.\\
+Idee:
+\begin{itemize}
+		\item Tupel der einen Relation im HS ablegen, so dass sie über VerbundAttribut schnell gefunden werden können
+		\item Tupel der anderen Relation sequenziell durchlaufen und mit Wert
+				des VerbundAttributs die passenden Verbundpartner im HS aufsuchen
+		\item Organisation der Tupel im HS über \textbf{Hashing}
+\end{itemize}
+Einfachster Fall: \textbf{Classic Hashing}:\\
+Funktionsweise:\\
+Äußere Schleife
+\begin{itemize}
+		\item Abschnittweise lesen der kleineren Relation R
+		\item Relation wird in $p$ Abschnitte aufgeteilt, die alle in HS passen
+		\item Aufbau einer Hash Tabelle mit $\text{h}_\text{A}($r.VA$)$
+\end{itemize}
+Innere Schleife
+\begin{itemize}
+		\item Überprüfung für jeden Satz von S mit P(S.SA) $\rightarrow$ 
+				ebenfalls mit Hashing
+		\item wenn sich Verbundpartner in dieser Adresse befindet, Durchführung des Verbundes
+\end{itemize}
+Komplexität: $\mathcal O(p \times N)$. Da Verbundpartner S $p$-mal gelesen werden muss.
+\begin{figure}[H]
+		\begin{center}
+				\includegraphics[scale=0.8]{pics/hash_join.png}
+				\caption{Hash Verbund}
+		\end{center}
+\end{figure}
+Problem ist, dass S $p$-mal durchlaufen werden muss. Daher die Idee
+S analog zu R zu partitionieren.\\
+Stichwort Simple Hashing.
+
+\subsection{Anfrageoptimierung}
+Ziel:\\$\rightarrow$ Ermittlung des \textit{kostengünstigsten} 
+Auswertungsweges
+
+Zentrales Problem:
+\begin{itemize}
+		\item globales Optimieren hat hohe Komplexität (NP-Schwer zur Laufzeit)
+		\item Einsatz von Heuristiken, da nicht alles nötige Wissen immer vorhanden ist
+\end{itemize}
+Optimierungsziel:
+\begin{itemize}
+		\item Maximierung des Outputs bei gegeben Ressoucren
+		\item Minimierung der Resourcennutzung
+\end{itemize}
+Die Wichtigsten Kostenarten sind:
+\begin{itemize}
+		\item Berechnungskosten (CPU)
+		\item I/O Kosten (Anzahl physischer Referenzen)
+\end{itemize}
+
+\subsubsection{Ausführungsplan}
+Ziel ist es eine möglichst guten Ausführungsbaum zu erstellen.
+Problematisch ist die riesige Anzahl an Möglichkeiten mit steigender
+Komplexität der Anfrage (z.B. Query mit 15 Verbunden $10^{70}$ Möglichkeiten).\\
+Diese Vielfalt entsteht durch verschiedene Implementierungen der Planoperatoren und der Operationsreihenfolgen.
+
+$\rightarrow$ \textbf{Ziel der Plangenerierung}:
+\begin{itemize}
+		\item finden von Plänen gelingt immer schnell
+		\item mit möglichst wenig generierten Plänen auskommen
+\end{itemize}
+Unterschiedliche Strategieklassen:
+\begin{itemize}
+		\item voll enumerativ
+		\item beschränkt enumerativ
+		\item zufallsgesteuert
+\end{itemize}
+
+\paragraph{Kostenformeln}
+\begin{itemize}
+		\item{ gewichtetes Ma"s für I/O und CPU Belastung:\\
+				C = \#physische-Seitenzugriffe + W $\times$ \#Aufrufe-des Zugriffsystems}
+		\item{ CPU-bound : höherer I/O-, geringerer CPU Aufwand:\\
+						$\text{W}_{\text{CPU}}$ = \#Instr-pro-Aufruf-des-Zugriffsystems /\\ \#Instr-pro-I/O-Vorgang
+				}
+		\item{ I/O-bound : geringere I/O-, höherer CPU Aufwand:\\
+						$\text{W}_{\text{IO}}$ = \#Instr-pro-Aufruf-des-Zugriffsystems /\\ (\#Instr-pro-I/O-Vorgang + Zugriffzeit $\times $ MIPS-Ratte)
+				}
+\end{itemize}
+
+\paragraph{Selektivitätsabschätzung}
+Der \textbf{Selektivitätsfaktor} beschreibt den erwarteten Anteil an
+Tupeln, die ein Prädikat p erfüllen.\\
+Diese Trefferate gibt auch an, inwiefern eine vorhandene Indexstruktur
+die Laufzeit reduzieren.
+\begin{figure}[H]
+		\begin{center}
+				\includegraphics[scale=1.0]{pics/trefferrate.png}
+				\caption{Qualitatives Zugriffsdiagramm}
+		\end{center}
+\end{figure}
+Nur bei sehr geringen Trefferraten lohnt sich ein Index Scan!

idb_skript/Saetze.tex

@@ -0,0 +1,61 @@
+\section{Sätze}
+\subsection{Allgemein}
+Warum wurden Sätze eingeführt? \\
+Sätze abstrahieren von Blöcken. Blöcke sind Hardware spezifisch.
+Sie haben unterschiedliche Längen und die Aufgabe von Einheiten von
+Platte und HS zu transportieren. Daher hat man eine anwendungspezifische
+Einheit eingeführt, die Daten zusammenfasst.\\
+\subsection{Satzadresse}
+Eine Satzadresse ist ein Bezeichner unter der man einen einzelnen Satz wiederfinden kann. Sie wird als stabil bezeichnet, wenn sich beim 
+verschieben des Satzes die Adresse nicht ändert.
+$\rightarrow$ Neue Schicht über Blöcke
+\subsection{Wechselpuffertechnik}
+Optimierungsmöglichkeit bei sequenziellen Dateien.
+Man verwendet \textit{zwei} Blockpuffer.\\
+Anwendung beim
+\begin{itemize}
+		\item Lesen: während Sätze in Puffer 1 gelesen werden \textbf{gleichzeitig} nächsten Block von Platte in Puffer 2 lesen
+		\item Schreiben: wenn Puffer 1 voll, \textbf{asynchron} auf Platte schreiben und gleichzeitig Puffer 2 zur Aufnahme weiterer Sätze verwenden
+\end{itemize}
+\subsection{Satzzugriff über Schlüsselwerte}
+\subsection{Normales Hashing}
+Man möchte nun Sätze und deren Inhalt nicht nur über
+die Satzadresse wiederfinden, sondern auch über \textbf{inhaltliche Kriterien}.
+\textbf{Schlüssel} definieren ein oder mehrere Felder eines Satzes, über
+das man den Satz wiederfinden kann.
+
+Lösung dafür ist \textbf{Hashing} der Sätze nach Schlüssel.
+
+Kollisionen verhindern:
+\begin{itemize}
+		\item Open Addressing (ausweichen auf Nachbar Buckets)
+				\begin{itemize}
+						\item $+$ kein zusätzlicher Speicherplatz erforderlich
+						\item $-$ beim Suchen findet man im Bucket auch Überläufer
+						\item $-$ beim löschen Überläufer zurückholen
+						\item $-$ in Nachbarbuckets werden ggf weitere Überläufe erzeugt
+				\end{itemize}
+		\item Overflow Buckets
+				\begin{itemize}
+						\item Anlegen spezieller Überlauf Buckets für jeden Bucket
+								\begin{itemize}
+										\item $-$ zusätzlicher Speicherplatz erforderlich
+										\item $+$ keine Mischung von sätzen
+										\item $+$ keine Beeinträchtigung der Nachbarbuckets
+								\end{itemize}
+				\end{itemize}
+\end{itemize}
+\subsubsection{Bewertung}
+\begin{itemize}
+		\item sehr schneller Zugriff über Schlüssel (1 bis 2 Blockzugriffe)
+		\item gestreute Speicherung kann nur nach \textbf{einem} Schlüssel erfolgen
+		\item Speicherplatz muss um voraus belegt werden
+\end{itemize}
+\subsection{Virtuelles Hashing}
+Vorteile vom virtuellen Hashing ggü. normalen Hashing:\\
+Das normale Hashing ist nicht erweiterbar, d.h. man muss den gesamten
+Speicher im voraus belegen. Dadurch kommt man in Platznot oder verschwendet zuviel.
+Beim linearen Hashing versucht man durch kontinuierliche Reorganisation
+Überlaufprobleme zu vermeiden.
+
+Beschreibung von Dateizustand:

idb_skript/Speicherung.tex

@@ -0,0 +1,125 @@
+\section{Speicherung von Tupeln und Relationen}
+\subsection{Ziele}
+\begin{itemize}
+		\item Relationen mit Mitteln der darunter implementierten Schichten sichern
+		\item Anfragen (SQL) möglichst effizient auswerten
+\end{itemize}
+\subsection{Speicherung von Tupeln in Sätzen}
+\subsubsection{Aufbau von Sätzen}
+\begin{itemize}
+		\item Sätze sind aus \textbf{Feldern} zusammengesetzt (Name, Typ, Länge)
+		\item \textbf{Systemkatalog}\\Informationen über Felder und Reihenfolge
+\end{itemize}
+\subsubsection{Satztyp}
+\begin{itemize}
+		\item Menge von Sätzen mit gleicher Struktur $\rightarrow$ einmalige
+				Beschreibung im Systemkatalog
+		\item beim Speichern eines Satzes wird ihm ein Satztyp zugeordnet
+		\item Länge der Sätze zumeist variabel
+\end{itemize}
+\textbf{Annahme: Reihenfolge der Felder egal}
+
+\subsubsection{Anforderungen}
+\textbf{Speicherplatzeffizienz}:
+\begin{itemize}
+		\item variable Länge
+		\item undefinierte Werte nicht speichern
+		\item Hilfsstrukturen minimieren
+\end{itemize}
+
+\textbf{direkter Zugriff auf Felder}:
+\begin{itemize}
+		\item ohne vorher andere Felder lesen zu müssen 
+		\item direkt zur Anfangs-Byte-Position innerhalb des Satzes
+\end{itemize}
+
+
+\textbf{Flexibilität}:
+\begin{itemize}
+		\item Hinzufügen von Feldern bei allen Sätzen
+		\item Löschen eines Feldes aus allen Sätzen
+\end{itemize}
+
+\subsubsection{Speicherungsstruktur im Satz}
+Der Satz wird in zwei logische Teile untergliedert. Einer beinhaltet
+alle Felder fester Länge und der andere alle der variablen. 
+Mit Katalogdaten und Längenangaben im Satz, lässt sich \textbf{flexibel}
+und \textbf{direkt} auf die Felder zugreifen.
+
+\begin{figure}[H]
+		\begin{center}
+				\includegraphics[scale=1.0]{pics/satz_speicherstruktur.png}
+				\caption{Variable Satz Speicherstruktur}
+		\end{center}
+\end{figure}
+Würden man alle Felder mit den Zeiger erreichen, wäre das Speicherplatzverschwendung.
+So sind alle Felder fester Größe direkt erreichbar.
+\textbox{Speicheurngsstruktur in Sätzen}{
+		Blatt 9 Aufgabe 2 üben.
+}
+\subsection{Speicherung von Relationen}
+\subsubsection{Spaltenweise Speicherung (C-Store)}
+\begin{itemize}
+		\item Auf das Lesen hin optimiert. Gut für Auswertung
+				großer Datenmengen
+		\item Nur Attribute lesen, die gebraucht werden
+		\item kompakte Speicherung der Attributwerte
+\end{itemize}
+\textbf{Prototyp}
+\begin{itemize}
+		\item speichert Sammlung von Spaltengruppen  
+				über mehrere Sätze verteilt
+		\item Sortierschlüssel ist ein Attribut
+		\item Gruppen von Spalten = Projektion
+		\item Speicherung
+				\begin{itemize}
+						\item \textbf{Schreibspeicher} für schnelles Einfügen und Ändern von Tupeln
+						\item \textbf{Lesespeicher} für umfangreiche Analysen
+				\end{itemize}
+		\item Änderung durch Löschen und Einfügen durch Tuple Mover
+\end{itemize}
+\textbf{Projektionen}
+\begin{itemize}
+		\item Die Projektionen besitzen ein oder mehrere Attribute aus einer logischen
+Tablle (ggf durch Fremdschlüssel auch Attribute aus anderen Tabellen)
+		\item Duplikate bleiben erhalten
+		\item Als Sortierschlüssel wird eines der Attribute hergenommen
+\end{itemize}
+\textbf{Komprimierungen}
+Abhängig von zwei Eigenschaften der Spalte:
+\begin{itemize}
+		\item Sortierung (nach der Spalte selbst) : ja/nein
+		\item Anzahl der verschiedenen Werte: wenig/viel
+\end{itemize}
+\begin{enumerate}
+		\item sortiert mit wenigen verschiedenen Werten:\\
+				organisiert in einem B-Baum mit
+				\begin{itemize}
+						\item dichter Packung $\rightarrow$ alle Seiten voll (keine Änderungen!)
+						\item und großen Seiten $\rightarrow$ geringe Höhe
+				\end{itemize}
+		\item unsortiert mit wenigen verschiedenen Werten:\\
+				Offset-Indexe: B-Baum für Abbildung von Positiionen in einer Spalte auf die Werte in dieser Spaltebegin
+		\item sortiert mit vielen verschiedenen Werten:\\
+				\begin{itemize}
+						\item B-Baum mit dichter Packung
+						\item Delta Codierung: Differenzen zum Vorgänger speichern
+				\end{itemize}
+		\item unsortiert mit vielen verschiedenen Werten
+				\begin{itemize}
+						\item unkomprimiert
+						\item B-Baum mit dichter Packung als sek. Organisation möglich
+				\end{itemize}
+\end{enumerate}
+\subsubsection{Ausführung von Anfragen}
+\textbox{Schritte für Ausführung von Query:}{
+\begin{enumerate}
+		\item Syntaxprüfung
+		\item gibt es die Relation und Attribute 
+		\item wie heißt Datei zur Relation
+		\item was für eine Datei ist das - direkt oder schlüsselbasiert
+		\item gibt es passende Projektionen
+		\item wo liegen die Verbund Indizes
+		\item müssen Partitionen zusammgeführt werden
+\end{enumerate}
+}

idb_skript/Transaktionen.tex

@@ -0,0 +1,342 @@
+\section{Transaktionen}
+\subsection{Allgemein}
+\subsubsection{Was sind Transaktionen?}
+Transaktionen sind eine logische Arbeitseinheit, die mehrere
+DB Schritte zusammenfassen.\\
+Z.B. einfügen eines neuen Mitarbeiters besteht aus vielen kleinen 
+DB Befehlen, bis Datenbank wieder konsistent ist
+
+\subsubsection{Wofür sind sie gut?}
+Sie überleiten von einem konsistenten Zustand in den nächsten.
+Im Fehlerfall muss die Möglichkeit gegeben werden, wieder in
+einen konsistenten Zustand zu finden.
+Im Mehrfachbetrieb muss gewährleistet werden, dass keine
+Nebenläufigkeitsprobleme auftauchen.
+
+\subsubsection{ACID Eigenschaften von Transaktionen:}
+\begin{itemize}
+		\item \textbf{Atomic:} Alle Änderungen von TA werden aktiv oder keine
+		\item \textbf{Consistency:} TA überführt DB von konsistent in konsistenten Zustand
+		\item \textbf{Isolation:} TA wird nicht von anderer TA beeinflusst
+		\item \textbf{Durability:} Änderungen sind Dauerhaft in DB übernommen
+\end{itemize}
+
+\subsection{Konsistenzen:}
+\subsubsection{Physische Konsistenz:}
+Alle Speicherungsstrukturen sind korrekt. Alle TID's stimmen etc.
+
+\subsubsection{Logische Konsistenz:}
+Setzt Physische Konsistenz voraus.\\
+Korrektheit der Dateninhalte.\\
+Alle Bedingungen des Datenmodells und alle Benutzerdefinierten
+Bedingungen sind erfüllt (Assertions).
+
+\subsection{Synchronisation}
+\subsubsection{Zustandsdiagramm TA}
+\begin{figure}[H]
+		\begin{center}
+				\includegraphics[scale=0.6]{pics/TA_status.png}
+				\caption{Transaktionszustände}
+		\end{center}
+\end{figure}
+
+\subsubsection{Anomalien ohne Synchronisation}
+\begin{itemize}
+		\item \textbf{lost updates}\\
+				$r_1(x) r_2(x) w_1(x) w_2(x)$
+		\item Abhängigkeiten von nicht freigegeben Änderungen 
+				\begin{itemize}
+						\item \textbf{dirty read}\\
+								$w_1(x)r_2(x)a_1 c_2$\\
+								Änderung wird noch nicht freigegeben (ggf abgebrochen) aber trotzdem gelesen
+						\item \textbf{dirty write}\\
+								$w_1(x)r_2(x)w_2(x)a_1 c_2$\\
+								Änderung wird noch nicht freigegeben (ggf abgebrochen) aber trotzdem geschrieben
+				\end{itemize}
+		\item \textbf{Non Repeatable Read}\\
+				$r_1(x)w_2(x)r_1(x)$\\
+				T1 sieht beim erneuten lesen einen anderen Wert als zuvor
+		\item \textbf{Phantom}\\
+				$r_1(P)w_2(x in P)r_1(P)$\\
+				Wie bei \textit{Non Repeatable Read} nur Prädikat statt einzelnes Element
+\end{itemize}
+\textit{Legende: c = commit, a = abort, w = write, r = read}
+\subsubsection{Serialisierung}
+Hintereinanderausführung aller TA's. Problem werden
+sehr große Wartezeiten. Allgemein ist deine Datenbank für Mehrbenutzerbetrieb
+ausgelegt, dies würde ad adsurdum geführt durch Serialisierung.
+Was tun im Fehlerfall
+
+\subsubsection{Serialisierbarkeit}
+Ziel:\\TA's laufen \textit{verzahnt} ab, aber ihr Ergebnis gleicht dem eines seriellen
+Ablaufes.\\
+$\rightarrow$ Ein Schedule von TA's ist \textbf{serialisierbar}, wenn es einen äquivalten
+\textbf{seriellen} Ablauf gibt.
+
+\subsubsection{Implementierung von Sperren}
+\textbf{Wann sperren?}\\
+Statisch:\\
+Alles sperren was evtl gebraucht wir (preclaiming)
+
+Dynamisch:\\
+Zur Laufzeit von TA nach Bedarf sperren\\
+$\rightarrow$ Gefahr von Verklemmungen!
+
+Sperrgranulat:\\
+Warum nicht Tupel:
+\begin{itemize}
+		\item Nicht immer effizient, bei großen Mengen
+		\item Phantom Tupel; es können nur bereits existente Tupel gesperrt werden.
+\end{itemize}
+Deshalb wird \textit{hierarchische Schachtelung} der Datenobjekte:\\
+\begin{figure}[H]
+		\begin{center}
+				\includegraphics[scale=0.8]{pics/sperrgranulat.png}
+				\caption{Sperrgranulate}
+		\end{center}
+\end{figure}
+
+Für jedes Objekt kann man nun einen Sperrmodus vergeben.
+Andere TA können daran erkennen, ob sie ihre Aktion ausführen dürfen.
+\begin{figure}[H]
+		\begin{center}
+				\includegraphics[scale=0.6]{pics/komp_matrix.png}
+				\caption{Kompatibilitätsmatrix}
+		\end{center}
+\end{figure}
+Das Problem an dieser Art der Sperrung ist, dass 
+\begin{itemize}
+		\item Alle Nachfolgeknoten implizit mitgesperrt werden
+		\item Alle Vorgängerknoten auch gesperrt werden müssen
+\end{itemize}
+Daher werden sogenannte \textbf{(Intention) Anwartschaftssperren} eingeführt:
+\begin{itemize}
+		\item {IS Sperre:\\
+				falls auf untergeordnete Objekte lesend zugegriffen wird}
+		\item {IX Sperre:\\
+				falls auf untergeordnete schreibend zugegriffen wird}
+\end{itemize}
+$\rightarrow$ Benutzung von Untersperre wird angezeigt, aber nochmal explizit weiter unten gesetzt!
+\paragraph{TOP-DOWN bei Sperre}
+\begin{itemize}
+		\item Bevor ein Knoten mit S oder IS gesperrt werden darf, müssen alle Vorgänger
+				in der Hierarchie im IX- oder im IS-Modus gesperrt worden sein.
+		\item
+				Bevor ein Knoten mit X oder IX gesperrt werden darf, müssen alle Vorgänger
+				in der Hierarchie im IX-Modus gesperrt worden sein.
+\end{itemize}
+\paragraph{BOTTOM-UP bei Freigabe}
+\begin{itemize}
+		\item Freigabe von unten nach oben
+		\item kein Knoten darf entsperrt werden, wenn noch andere Nachfolger dieses Knotens 
+				gesperrt sind
+\end{itemize}
+Als Optimierung gibt es noch die \textbf{SIX} Sperre. Alles wird lesend gesperrt 
+und eine Menge an Nachfolgern schreibend. Das lohnt sich z.B. wenn aus einer Relation
+nur wenige Tupel verändert werden.
+
+\subsubsection{Probleme beim Sperren}
+\begin{itemize}
+		\item Sperren muss sehr schnell gehen, da Anforderungen sehr hoch
+		\item halten von Sperren bis TA-ende führt zu langen Wartezeiten
+		\item Eigenschaften des Schemas können \glqq hotspots\grqq erzeugen
+		\item {Optimierungen:
+						\begin{itemize}
+								\item Nutzung mehrere Objektversionen
+								\item spezialisiertes Sperren
+								\item Änderungen auf privaten Objektkopien
+						\end{itemize}
+				}
+\end{itemize}
+
+\subsubsection{Verklemmungen}
+Lösungsmöglichkeiten:
+\begin{itemize}
+		\item{\textbf{Timout:}\\
+						Transaktion nach bestimmter Wartezeit zurücksetzen.\\
+						$\rightarrow$ problematisch Länge des Timeouts zu bestimmen
+				}
+		\item{\textbf{Verhütung (Prevention)}\\
+				Durch Preclaiming (s.o.) keine Deadlock Verhinderung zur Laufzeit notwenig.}
+		\item{\textbf{Vermeidung (Avoidance)}\\
+						Potentielle Deadlocks im vorhinein erkennen und vermeiden\\
+						$\rightarrow$ Laufzeitunterstützung notwendig
+				}
+		\item{\textbf{Erkennung (Detection)}\\
+						Explizites führen eines Wartegraphen und darin Zyklensuche. Im Zyklus dann
+				eine oder mehrere (am besten billigste) TA zurücksetzen.}
+\end{itemize}
+\textbox{Deadlock - nicht serialisierbarer Schedule}{
+		Nicht serialisierbare Schedules, beschreibt Abläufe die zu 
+		keinem seriellen Ablauf äquivalent sind. Die somit zu Deadlocks führen.
+		Führt man diese mit \textit{dynamischen} Sperren aus, muss es aber nicht
+		zwangsläufig auch zu Deadlocks kommen!
+}
+\subsection{Recovery}
+\textbf{Recovery Klassen:}
+\begin{itemize}
+		\item {Partial Undo (R1-Recover)
+						\begin{itemize}
+								\item nach Transaktionsfehler
+								\item isoliertes und vollständiges Zurücksetzen der Daten
+										in Anfangszustand
+								\item beeinflusst andere TA nicht
+						\end{itemize}
+				}
+		\item {Partial Redo (R2-Recover)
+						\begin{itemize}
+								\item nach Systemfehler (mit Verlust von HS)
+								\item Wiederhlung aller verlorengegangenen Änderungen
+										(waren nur im Puffer) von abgeschlossenen TA
+						\end{itemize}
+				}
+		\item {Global Undo (R3-Recover)
+						\begin{itemize}
+								\item nach Systemfehler (mit Verlust von HS)
+								\item Zurücksetzen aller durch Ausfall unterbrochenen TA
+						\end{itemize}
+				}
+		\item {Global Redo (R4-Recover)
+						\begin{itemize}
+								\item nach Gerätefehler
+								\item Einspielen von Archivkopie und nachvollziehen
+										aller beendeten TA's
+						\end{itemize}
+				}
+\end{itemize}
+\subsubsection{Archivkopien}
+Arten:
+\begin{itemize}
+		\item \glqq cold backup\grqq: DBS muss au"ser Betrieb sein
+		\item \glqq hot backup\grqq: Beeinträchtigung des laufenden Betriebs
+\end{itemize}
+\subsubsection{Einbringstrategien}
+Wann werden geänderte Daten aus dem Puffer auf die Platte geschrieben?
+\begin{itemize}
+		\item {STEAL:\\
+				Bei Verdrängung aus dem Puffer, auch vor Ende der Transaktion}
+		\item {NO STEAL:\\
+				Frühestens am Ende der Transaktion $\rightarrow$ kein UNDO erfoderlich (aber großen Puffer)}
+
+		\item {FORCE:\\
+				Spätestens am Ende der Transaktion $\rightarrow$ kein Partial Redo erfoderlich}
+
+		\item {NO FORCE:\\
+				Erst bei Verdrängung aus dem Puffer}
+\end{itemize}
+Wie werden geänderte Daten aus dem Puffer auf Platte geschrieben?
+\begin{itemize}
+		\item{ATOMIC:\\
+						Indirekte Einbringstrategie.\\
+				Ununterbrechbares Umschalten}
+		\item{NOT ATOMIC:
+						Direkte Einbringstrategie.\\
+						Ist nicht ununterbrechbar.
+				}
+\end{itemize}
+\subsubsection{Protokolldaten}
+Als Protollinformation zählt was über die Einbringungsstrategie hinaus
+benötigt wird, um nach einem Systemausfall den jüngsten konsisten Zustand
+wiederherzustellen.
+\begin{figure}[H]
+		\begin{center}
+				\includegraphics[scale=0.6]{pics/protokoll2.png}
+				\caption{Protokollinformationen}
+		\end{center}
+\end{figure}
+
+\paragraph{Wann wird in Protokolldatei geschrieben?}
+\begin{itemize}
+		\item{UNDO-Information:
+						\begin{itemize}
+								\item bevor die zugehörigen Änderungen in Datenbestand eingebracht werden
+								\item sonst Rücksetzen unmöglich
+						\end{itemize}
+				}
+		\item{REDO-Information:
+						\begin{itemize}
+								\item muss geschrieben sein (in tmp Log Datei und Archivdatei), bevor der Abschluss der TA
+										an Programm bzw Benutzer gemeldet wird
+								\item sonst Wiederherstellung nicht möglich
+						\end{itemize}
+				}
+\end{itemize}
+\subsubsection{Backward-/Forward Recovery}
+\begin{enumerate}
+		\item{ Forward:\\
+						Änderungen sind noch nicht in DB, aber schon in Log. Bevor
+						diese auf DB geschrieben werden, wird ein Commit-Record in
+				Log File geschrieben. Falls was schief geht und der Commit Record noch da ist, werden alle diese Änderungen wiederholt und ansonsten nichts getan, da alte Version noch in DB steht.}
+		\item{ Backward:\\
+						Ins Log kommt immer \textbf{alte} Version eines Wertes. Bei 
+						einem Commit wird gewartet bis alle neuen werte in DB stehen. 
+						Danach erst wird CommitRecord erstellt und eine Bestätigung
+						signalisiert.
+				Bei Verlust werden entweder alte Daten hergestellt oder nichts getan.}
+\end{enumerate}
+\paragraph{Vergleich}
+\begin{itemize}
+		\item{ Forward Recovery: Hoher Speicherplatzbedarf! Daten werden erst nach Beendigung der TA in DB geschrieben und deswegen solange in Puffer behalten}
+		\item{ Backward-Recovery: Hoher I/O Aufwand! Alle Änderungen müssen vor TA-Ende in Datenfiles stehen.}
+\end{itemize}
+\subsubsection{Undo-/Redo Logging}
+Verbesserung zu Backward-/Forward Recovery.
+\begin{figure}[H]
+		\begin{center}
+				\includegraphics[scale=0.8]{pics/protokoll.png}
+				\caption{Physische Protokollierung}
+		\end{center}
+\end{figure}
+Zustände vor bzw nach einer Änderungen werden protokolliert:
+\begin{itemize}
+		\item alter Zustand: Before Image (BI) für UNDO
+		\item neuer Zustand: After Image (AI) für REDO
+		\item für jede veränderte Seite (3) wird jeweils eine
+				vollständige Kopie vor (2) und nach (4) der Änderung in den Log
+				geschrieben.\\
+				$+$ schnelle Recovery\\
+				$-$ hoher E/A Aufwand
+\end{itemize}
+\paragraph{Optimierungen}
+Um Log-Aufwand zu reduzieren nur geänderte \textbf{Teile einer Seite}
+protokollieren.\\
+Sammlung und Pufferung im HS:
+\begin{itemize}
+		\item $+$ reduzierter E/A Aufwand
+		\item $-$ komplexeres und zeitaufwändigeres Recovery\\
+				Zurückspeichern gleicht eher dem Neu einfügen (freien Platz suchen, TID vergeben), da Stelle von wo Einträge stammen anderweitig genutzt werden können
+\end{itemize}
+
+\subsubsection{Sicherungspunkte}
+Ma"snahmen zur Begrenzung des REDO Aufwands nach Systemfehlern (alle
+erfolgreichen Änderungen die im Puffer verloren gegangen sind müssen wiederholt werden $\rightarrow$ nicht praktikabel!
+\paragraph*{Methoden}
+\begin{itemize}
+		\item{ \textbf{Transaction-Oriented Checkpoint}\\
+				Geänderte Seiten einer TA nach TA-ende sofort in DB bringen (siehe FORCE) $\rightarrow$ zu hohe Belastung}
+		\item{ \textbf{ Transaction-Consisten Checkpoint}
+						\begin{itemize}
+								\item Einbringung aller Änderung erfolgreicher TA's
+								\item Lesesperre auf ganzer DB zum Zeitpunkt des Sicherungspunktes
+								\item Verzögerung von TA's
+								\item Sicherungspunkt begrenzt Undo und Redo Recovery
+						\end{itemize}
+				}
+		\item{ \textbf{Action-Consisten Checkpoint}
+						\begin{itemize}
+								\item Zum Zeitpunkt des Sicherungspunktes dürfen keine Änderunen aktiv sein
+								\item Begünstigt nur Recovery, dafür kürzere Totzeit von System
+						\end{itemize}
+				}
+\end{itemize}
+\subsubsection{Allgemeine Restart Prozedur}
+\textbf{3-phasiger Ansatz}
+\begin{enumerate}
+		\item Analyse Lauf\\
+				Vom letzten Checkpoint bis zum Log Ende. Bestimmung von Gewinner und Verlierer TA's, sowie Seiten, die von ihnen geändert wurden
+		\item Undo Lauf \\
+				Rücksetzen der Verlierer TA's durch Rückwärtslesen des Logs bis zum BOT Satz der ältesten Verlierer TA
+		\item Redo Lauf \\
+				Vorwärtslesen des Logs (Startpunkt abhängig von Checkpoint Typ) und Änderungen der Gewinner TA's wiederholen
+\end{enumerate}
+