Mirror/latexandmore
1
0
Fork 0
mirror of https://gitlab.cs.fau.de/ik15ydit/latexandmore.git synced 2024-11-26 05:35:03 +01:00
Code Issues Projects Releases Wiki Activity

typos in chap. 6, 7, 8, 9

Browse Source
This commit is contained in:
Christian Strate 2014-02-17 08:11:42 +01:00
parent 473b8187bf
commit 8bff52d98a
4 changed files with 22 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Anfrageverarbeitung.tex
View File

@ -80,7 +80,7 @@ Heuristik:
\item Selektionen mit mehreren Prädikat Termen separieren in Selektionen mit jeweils einem Prädikat Term (Regel 4) \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 so früh wie möglich ausführen (Regel 7 und 8)
\item Selektionen und Kreuzprodukt zu Verbund zusammenfassen, wenn \item Selektionen und Kreuzprodukt zu Verbund zusammenfassen, wenn
das Selektioinsprädikat Attribute aus den beiden Relationen verwendet (Regel 9) 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. \item Projektionen so früh wie möglich ausführen, allerdings nicht vor Selektion und Mengenoperationen.
\end{itemize} \end{itemize}

10
Relationale_Operatoren.tex
View File

@ -19,7 +19,7 @@ Die grundsätzliche Aufgabe besteht darin die logischen Operatoren
SQL erlaubt Anfragen über k-Relationen: SQL erlaubt Anfragen über k-Relationen:
\begin{itemize} \begin{itemize}
\item Ein Variablen Ausdrücke (eine Relation) \item Ein Variablen Ausdrücke (eine Relation)
\item Zwei Variablem AUsdrücke (zwei Relationen) \item Zwei Variablen Ausdrücke (zwei Relationen)
\item k-Variablen Ausdrücke (zerlegt in Ein- und Zwei Variablen Ausdrücke) \item k-Variablen Ausdrücke (zerlegt in Ein- und Zwei Variablen Ausdrücke)
\end{itemize} \end{itemize}
@ -72,7 +72,7 @@ fuer jeden Satz s, fuer den $P(s.SA)$ gilt:
Scan ueber $R$; //innere Schleife Scan ueber $R$; //innere Schleife
fuer jeden Satz r, fuer jeden Satz r,
fuer den P(r.SA) AND (r.VA $\Theta$ s.VA) gilt: fuer den P(r.SA) AND (r.VA $\Theta$ s.VA) gilt:
uebernimm kombinierten SAtz (r,s) uebernimm kombinierten Satz (r,s)
in das Ergebnis; in das Ergebnis;
\end{lstlisting} \end{lstlisting}
Komplexität: $\mathcal O(N^2)$ Komplexität: $\mathcal O(N^2)$
@ -156,7 +156,7 @@ Die Wichtigsten Kostenarten sind:
Ziel ist es eine möglichst guten Ausführungsbaum zu erstellen. Ziel ist es eine möglichst guten Ausführungsbaum zu erstellen.
Problematisch ist die riesige Anzahl an Möglichkeiten mit steigender Problematisch ist die riesige Anzahl an Möglichkeiten mit steigender
Komplexität der Anfrage (z.B. Query mit 15 Verbunden $10^{70}$ Möglichkeiten).\\ Komplexität der Anfrage (z.B. Query mit 15 Verbunden $10^{70}$ Möglichkeiten).\\
Diese Vielfalt entsteht durch verschiedene Implementierungen der Planoperatoren und der Operationsreiehenfolgen. Diese Vielfalt entsteht durch verschiedene Implementierungen der Planoperatoren und der Operationsreihenfolgen.
$\rightarrow$ \textbf{Ziel der Plangenerierung}: $\rightarrow$ \textbf{Ziel der Plangenerierung}:
\begin{itemize} \begin{itemize}
@ -178,11 +178,11 @@ Unterschiedliche Strategieklassen:
$\text{W}_{\text{CPU}}$ = \#Instr-pro-Aufruf-des-Zugriffsystems /\\ \#Instr-pro-I/O-Vorgang $\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:\\ \item{ I/O-bound : geringere I/O-, höherer CPU Aufwand:\\
$\text{W}_{\text{CPU}}$ = \#Instr-pro-Aufruf-des-Zugriffsystems /\\ (\#Instr-pro-I/O-Vorgang + Zugriffzeit $\times $ MIPS-Ratte) $\text{W}_{\text{IO}}$ = \#Instr-pro-Aufruf-des-Zugriffsystems /\\ (\#Instr-pro-I/O-Vorgang + Zugriffzeit $\times $ MIPS-Ratte)
} }
\end{itemize} \end{itemize}
\paragraph{Selektivitätsanschätzung} \paragraph{Selektivitätsabschätzung}
Der \textbf{Selektivitätsfaktor} beschreibt den erwarteten Anteil an Der \textbf{Selektivitätsfaktor} beschreibt den erwarteten Anteil an
Tupeln, die ein Prädikat p erfüllen.\\ Tupeln, die ein Prädikat p erfüllen.\\
Diese Trefferate gibt auch an, inwiefern eine vorhandene Indexstruktur Diese Trefferate gibt auch an, inwiefern eine vorhandene Indexstruktur

4
Speicherung.tex
View File

@ -14,7 +14,7 @@
\begin{itemize} \begin{itemize}
\item Menge von Sätzen mit gleicher Struktur $\rightarrow$ einmalige \item Menge von Sätzen mit gleicher Struktur $\rightarrow$ einmalige
Beschreibung im Systemkatalog Beschreibung im Systemkatalog
\item beim speichern eines Satzes wird im ein Satztyp zugeordnet \item beim Speichern eines Satzes wird ihm ein Satztyp zugeordnet
\item Länge der Sätze zumeist variabel \item Länge der Sätze zumeist variabel
\end{itemize} \end{itemize}
\textbf{Annahme: Reihenfolge der Felder egal} \textbf{Annahme: Reihenfolge der Felder egal}
@ -30,7 +30,7 @@
\textbf{direkter Zugriff auf Felder}: \textbf{direkter Zugriff auf Felder}:
\begin{itemize} \begin{itemize}
\item ohne vorher andere Felder lesen zu müssen \item ohne vorher andere Felder lesen zu müssen
\item direkt zur Anfangs-Byte Position innerhalb des Satzes \item direkt zur Anfangs-Byte-Position innerhalb des Satzes
\end{itemize} \end{itemize}

24
Transaktionen.tex
View File

@ -23,7 +23,7 @@ Nebenläufigkeitsprobleme auftauchen.
\subsection{Konsistenzen:} \subsection{Konsistenzen:}
\subsubsection{Physische Konsistenz:} \subsubsection{Physische Konsistenz:}
Alle Speicheurngsstrukturen sind korrekt. Alle TID's stimmen etc. Alle Speicherungsstrukturen sind korrekt. Alle TID's stimmen etc.
\subsubsection{Logische Konsistenz:} \subsubsection{Logische Konsistenz:}
Setzt Physische Konsistenz voraus.\\ Setzt Physische Konsistenz voraus.\\
@ -64,7 +64,7 @@ Bedingungen sind erfüllt (Assertions).
\subsubsection{Serialisierung} \subsubsection{Serialisierung}
Hintereinanderausführung aller TA's. Problem werden Hintereinanderausführung aller TA's. Problem werden
sehr große Wartezeiten. Allgemein ist deine Datenbank für Mehrbenutzerbetrieb sehr große Wartezeiten. Allgemein ist deine Datenbank für Mehrbenutzerbetrieb
ausgelegt, dies würde ab adsurdum geführt durch Serialisierung. ausgelegt, dies würde ad adsurdum geführt durch Serialisierung.
Was tun im Fehlerfall Was tun im Fehlerfall
\subsubsection{Serialisierbarkeit} \subsubsection{Serialisierbarkeit}
@ -214,7 +214,7 @@ Arten:
Wann werden geänderte Daten aus dem Puffer auf die Platte geschrieben? Wann werden geänderte Daten aus dem Puffer auf die Platte geschrieben?
\begin{itemize} \begin{itemize}
\item {STEAL:\\ \item {STEAL:\\
Bei Verdrängung au dem Puffer, auch vor ende der Transaktion} Bei Verdrängung aus dem Puffer, auch vor Ende der Transaktion}
\item {NO STEAL:\\ \item {NO STEAL:\\
Frühestens am Ende der Transaktion $\rightarrow$ kein UNDO erfoderlich (aber großen Puffer)} Frühestens am Ende der Transaktion $\rightarrow$ kein UNDO erfoderlich (aber großen Puffer)}
@ -222,7 +222,7 @@ Wann werden geänderte Daten aus dem Puffer auf die Platte geschrieben?
Spätestens am Ende der Transaktion $\rightarrow$ kein Partial Redo erfoderlich} Spätestens am Ende der Transaktion $\rightarrow$ kein Partial Redo erfoderlich}
\item {NO FORCE:\\ \item {NO FORCE:\\
Erst bei Verdränung aus dem Puffer} Erst bei Verdrängung aus dem Puffer}
\end{itemize} \end{itemize}
Wie werden geänderte Daten aus dem Puffer auf Platte geschrieben? Wie werden geänderte Daten aus dem Puffer auf Platte geschrieben?
\begin{itemize} \begin{itemize}
@ -247,13 +247,13 @@ wiederherzustellen.
\paragraph{Wann wird in Protokolldatei geschrieben?} \paragraph{Wann wird in Protokolldatei geschrieben?}
\begin{itemize} \begin{itemize}
\item{UNDO-Information:\\ \item{UNDO-Information:
\begin{itemize} \begin{itemize}
\item bevor die zugehörigen Änderungen in Datenbestand eingebracht werden \item bevor die zugehörigen Änderungen in Datenbestand eingebracht werden
\item sonst rücksetzen unmöglich \item sonst Rücksetzen unmöglich
\end{itemize} \end{itemize}
} }
\item{REDO-Information:\\ \item{REDO-Information:
\begin{itemize} \begin{itemize}
\item muss geschrieben sein (in tmp Log Datei und Archivdatei), bevor der Abschluss der TA \item muss geschrieben sein (in tmp Log Datei und Archivdatei), bevor der Abschluss der TA
an Programm bzw Benutzer gemeldet wird an Programm bzw Benutzer gemeldet wird
@ -266,7 +266,7 @@ wiederherzustellen.
\item{ Forward:\\ \item{ Forward:\\
Änderungen sind noch nicht in DB, aber schon in Log. Bevor Änderungen sind noch nicht in DB, aber schon in Log. Bevor
diese auf DB geschrieben werden, wird ein Commit-Record in 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 wiedehrolt und ansonsten nichts getan, da alte Version noch in DB steht.} 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:\\ \item{ Backward:\\
Ins Log kommt immer \textbf{alte} Version eines Wertes. Bei Ins Log kommt immer \textbf{alte} Version eines Wertes. Bei
einem Commit wird gewartet bis alle neuen werte in DB stehen. einem Commit wird gewartet bis alle neuen werte in DB stehen.
@ -304,7 +304,7 @@ Sammlung und Pufferung im HS:
\begin{itemize} \begin{itemize}
\item $+$ reduzierter E/A Aufwand \item $+$ reduzierter E/A Aufwand
\item $-$ komplexeres und zeitaufwändigeres Recovery\\ \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 andersweitig genutzt werden können 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} \end{itemize}
\subsubsection{Sicherungspunkte} \subsubsection{Sicherungspunkte}
@ -314,10 +314,10 @@ erfolgreichen Änderungen die im Puffer verloren gegangen sind müssen wiederhol
\begin{itemize} \begin{itemize}
\item{ \textbf{Transaction-Oriented Checkpoint}\\ \item{ \textbf{Transaction-Oriented Checkpoint}\\
Geänderte Seiten einer TA nach TA-ende sofort in DB bringen (siehe FORCE) $\rightarrow$ zu hohe Belastung} Geänderte Seiten einer TA nach TA-ende sofort in DB bringen (siehe FORCE) $\rightarrow$ zu hohe Belastung}
\item{ \textbf{ Transaction-COnsisten Checkpoint} \item{ \textbf{ Transaction-Consisten Checkpoint}
\begin{itemize} \begin{itemize}
\item Einbringung aller Änderung erfolgreicher TA's \item Einbringung aller Änderung erfolgreicher TA's
\item Lesesperee auf ganzer DB zum Zeitpunkt des Sicherungspunktes \item Lesesperre auf ganzer DB zum Zeitpunkt des Sicherungspunktes
\item Verzögerung von TA's \item Verzögerung von TA's
\item Sicherungspunkt begrenzt Undo und Redo Recovery \item Sicherungspunkt begrenzt Undo und Redo Recovery
\end{itemize} \end{itemize}
@ -332,7 +332,7 @@ erfolgreichen Änderungen die im Puffer verloren gegangen sind müssen wiederhol
\subsubsection{Allgemeine Restart Prozedur} \subsubsection{Allgemeine Restart Prozedur}
\textbf{3-phasiger Ansatz} \textbf{3-phasiger Ansatz}
\begin{enumerate} \begin{enumerate}
\item Analyse Lauf \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 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 \\ \item Undo Lauf \\
Rücksetzen der Verlierer TA's durch Rückwärtslesen des Logs bis zum BOT Satz der ältesten Verlierer TA Rücksetzen der Verlierer TA's durch Rückwärtslesen des Logs bis zum BOT Satz der ältesten Verlierer TA