From 8bff52d98a5410bc2e35a7dac37d706c818440b7 Mon Sep 17 00:00:00 2001 From: Christian Strate Date: Mon, 17 Feb 2014 08:11:42 +0100 Subject: [PATCH] typos in chap. 6, 7, 8, 9 --- Anfrageverarbeitung.tex | 6 +++--- Relationale_Operatoren.tex | 10 +++++----- Speicherung.tex | 4 ++-- Transaktionen.tex | 24 ++++++++++++------------ 4 files changed, 22 insertions(+), 22 deletions(-) diff --git a/Anfrageverarbeitung.tex b/Anfrageverarbeitung.tex index a169cff..4acece2 100644 --- a/Anfrageverarbeitung.tex +++ b/Anfrageverarbeitung.tex @@ -25,8 +25,8 @@ interner DBS-Operationen \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 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}) @@ -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 so früh wie möglich ausführen (Regel 7 und 8) \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. \end{itemize} diff --git a/Relationale_Operatoren.tex b/Relationale_Operatoren.tex index d66ee8b..17f8c8c 100644 --- a/Relationale_Operatoren.tex +++ b/Relationale_Operatoren.tex @@ -19,7 +19,7 @@ Die grundsätzliche Aufgabe besteht darin die logischen Operatoren SQL erlaubt Anfragen über k-Relationen: \begin{itemize} \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) \end{itemize} @@ -72,7 +72,7 @@ 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) + uebernimm kombinierten Satz (r,s) in das Ergebnis; \end{lstlisting} 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. 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 Operationsreiehenfolgen. +Diese Vielfalt entsteht durch verschiedene Implementierungen der Planoperatoren und der Operationsreihenfolgen. $\rightarrow$ \textbf{Ziel der Plangenerierung}: \begin{itemize} @@ -178,11 +178,11 @@ Unterschiedliche Strategieklassen: $\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{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} -\paragraph{Selektivitätsanschätzung} +\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 diff --git a/Speicherung.tex b/Speicherung.tex index 49875b0..bee5118 100644 --- a/Speicherung.tex +++ b/Speicherung.tex @@ -14,7 +14,7 @@ \begin{itemize} \item Menge von Sätzen mit gleicher Struktur $\rightarrow$ einmalige 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 \end{itemize} \textbf{Annahme: Reihenfolge der Felder egal} @@ -30,7 +30,7 @@ \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 + \item direkt zur Anfangs-Byte-Position innerhalb des Satzes \end{itemize} diff --git a/Transaktionen.tex b/Transaktionen.tex index 246e7fc..0dc4461 100644 --- a/Transaktionen.tex +++ b/Transaktionen.tex @@ -23,7 +23,7 @@ Nebenläufigkeitsprobleme auftauchen. \subsection{Konsistenzen:} \subsubsection{Physische Konsistenz:} -Alle Speicheurngsstrukturen sind korrekt. Alle TID's stimmen etc. +Alle Speicherungsstrukturen sind korrekt. Alle TID's stimmen etc. \subsubsection{Logische Konsistenz:} Setzt Physische Konsistenz voraus.\\ @@ -64,7 +64,7 @@ Bedingungen sind erfüllt (Assertions). \subsubsection{Serialisierung} Hintereinanderausführung aller TA's. Problem werden 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 \subsubsection{Serialisierbarkeit} @@ -214,7 +214,7 @@ Arten: Wann werden geänderte Daten aus dem Puffer auf die Platte geschrieben? \begin{itemize} \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:\\ 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} \item {NO FORCE:\\ - Erst bei Verdränung aus dem Puffer} + Erst bei Verdrängung aus dem Puffer} \end{itemize} Wie werden geänderte Daten aus dem Puffer auf Platte geschrieben? \begin{itemize} @@ -247,13 +247,13 @@ wiederherzustellen. \paragraph{Wann wird in Protokolldatei geschrieben?} \begin{itemize} - \item{UNDO-Information:\\ + \item{UNDO-Information: \begin{itemize} \item bevor die zugehörigen Änderungen in Datenbestand eingebracht werden - \item sonst rücksetzen unmöglich + \item sonst Rücksetzen unmöglich \end{itemize} } - \item{REDO-Information:\\ + \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 @@ -266,7 +266,7 @@ wiederherzustellen. \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 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:\\ Ins Log kommt immer \textbf{alte} Version eines Wertes. Bei einem Commit wird gewartet bis alle neuen werte in DB stehen. @@ -304,7 +304,7 @@ 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 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} \subsubsection{Sicherungspunkte} @@ -314,10 +314,10 @@ erfolgreichen Änderungen die im Puffer verloren gegangen sind müssen wiederhol \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} + \item{ \textbf{ Transaction-Consisten Checkpoint} \begin{itemize} \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 Sicherungspunkt begrenzt Undo und Redo Recovery \end{itemize} @@ -332,7 +332,7 @@ erfolgreichen Änderungen die im Puffer verloren gegangen sind müssen wiederhol \subsubsection{Allgemeine Restart Prozedur} \textbf{3-phasiger Ansatz} \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 \item Undo Lauf \\ Rücksetzen der Verlierer TA's durch Rückwärtslesen des Logs bis zum BOT Satz der ältesten Verlierer TA