mirror of
https://gitlab.cs.fau.de/ik15ydit/latexandmore.git
synced 2024-11-22 03:49:31 +01:00
begann to add solutions
This commit is contained in:
Sheppy
parent
a9721b2771
commit
58daf101f1
@ -2,28 +2,77 @@
|
||||
\usepackage[final]{pdfpages}
|
||||
\usepackage{listings}
|
||||
\newcommand{\solution}[1]{\ifdefined\withsolutions #1 \fi}
|
||||
\newcommand{\solswitch}[2]{\ifdefined\withsolutions #2 \else #1 \fi}
|
||||
\newcommand{\s}[1]{\solution{ \textit{#1} }}
|
||||
%use like \solution{ $SOLUTION }
|
||||
\begin{document}
|
||||
\solution{\section{test}}
|
||||
|
||||
\section{Disclaimer}
|
||||
Dies ist selbstverstaendlich alles studentisch blabla, Fehler = nicht rumweinen sondern Pullrequest machen. README lesen fuer mehr Info.
|
||||
|
||||
\section{Aufgabe 1}
|
||||
Antworte mit richtig oder falsch und Begruendung. [4P pro Aufgabe, es wurden aber immer nur 4 oder 0 vergeben und nur bei (dem Lehrstuhl nach) richtiger Begruendung]
|
||||
\begin{itemize}
|
||||
\item \textbf{a)} Bei Verwendung von Magnetplatenlaufwerken zur Speicherung von Datenbanken ist es guenstig haeufig, zusammen gebrauchte Daten auf dem selben Zylinder abzulegen.
|
||||
\item \textbf{b)} Die von der Schicht der Speicherstruckturen angebotenen Adressierungseinheiten umfassen unter anderem Tupel, Relationen und Sichten.
|
||||
\item \textbf{c)} Bei direkter Seitenzuordnung genuegt es, die Blocknummer der ersten Seite eines Sgmentes zu kennen, um die Blocknummer einer beliebigen Seite dieses Segments ermitten zu koennen
|
||||
\item \textbf{d)} Das Problem der Seitenersetzungsstrategie LFU (Least frequently used) fuer den Datenbankpuffer ist, dass Seiten im Puffer nicht alt werden.
|
||||
\item \textbf{e)} Jede Seite, die aus dem Datenbankpuffer verdreangt wird, muss auf den persistenten Speicher geschrieben werden.
|
||||
\item \textbf{f)} Bei der Verschiebung eines Satzes in eine andere Seite aendert sich dessen TID, so dass sie die Nummer der neuen Seite enthaelt.
|
||||
\item \textbf{g)} Wenn in einer Anfrage ein Attribut auf Gleichheit mit einer Konstanten geprueft wird (z.B. alter = 42) und es existiert ein Index fuer dieses Attribut, dann ist der Zugriff ueber den Index grundsaetzlich schneller als ein Table-Scan.
|
||||
\item \textbf{h)} Felder variabler Laenge koennen nicht als Schluessel in einem Index verwendet werden.
|
||||
\item \textbf{i)} Bei der Vergroesserung der Hashtabelle bei Linear Hashing, wird die Zahl der Buckets jedes mal verdoppelt.
|
||||
\item \textbf{j)} Bei der Suche nach einem Wert in einem B*-Baum muss immer bis zu einem Blattknoten abgestiegen werden.
|
||||
\item \textbf{k)} Ein B-Baum enthaelt Verweise auf Saetze, aber nie ganze Saetze.
|
||||
\item \textbf{l)} Bei der Suche in einem R-Baum nach Objekten in einem bestimmten rechteckigen Bereich muss an jedem Knoten in maximal einen Ast abgestiegen werden.
|
||||
\item \textbf{m)} Materialisierte Sichten koennen die Ausfuehrung von Anfragen beschleunigen.
|
||||
\item \textbf{n)} Das C in den ACID-Eigenschaften von Transaktionen steht fuer Concurrency.
|
||||
\item \textbf{o)} Bei reiner Forward-Recovery duerfen Aenderungen einer Transaktion erst nach deren erfolgreichem Commit in den Datenbestand eingebracht werden.
|
||||
\item \textbf{a)} Bei Verwendung von Magnetplatenlaufwerken zur Speicherung von Datenbanken ist es guenstig haeufig, zusammen gebrauchte Daten auf dem selben Zylinder abzulegen. \\
|
||||
\solution{
|
||||
Ja, weil ist schneller.
|
||||
}
|
||||
\item \textbf{b)} Die von der Schicht der Speicherstrukturen angebotenen Adressierungseinheiten umfassen unter anderem Tupel, Relationen und Sichten.\\
|
||||
\solution{
|
||||
Nein, das waere die Schicht der logischen Datenstruckturen
|
||||
}
|
||||
\item \textbf{c)} Bei direkter Seitenzuordnung genuegt es, die Blocknummer der ersten Seite eines Sgmentes zu kennen, um die Blocknummer einer beliebigen Seite dieses Segments ermitten zu koennen\\
|
||||
\solution{
|
||||
Ja, denn alle Seiten sind gleich groß und liegen hintereinander im Speicher.
|
||||
}
|
||||
\item \textbf{d)} Das Problem der Seitenersetzungsstrategie LFU (Least frequently used) fuer den Datenbankpuffer ist, dass Seiten im Puffer nicht alt werden.\\
|
||||
\solution{
|
||||
Ja, denn die Puffereffizients kann dadurch beeintraechtigt werden, dass es sehr lange dauert bis eine, zeitweise stark aber dann ie wieder genutzte Seite aus dem Puffer verdraengt wird.
|
||||
}
|
||||
\item \textbf{e)} Jede Seite, die aus dem Datenbankpuffer verdreangt wird, muss auf den persistenten Speicher geschrieben werden.\\
|
||||
\solution{
|
||||
Nein, mitunter wurde sie nicht veraendert oder es gibt andere Gruende warum man sie nicht auf die Platte schreiben moechte (rollback aus hoeherer Ebene?).
|
||||
}
|
||||
\item \textbf{f)} Bei der Verschiebung eines Satzes in eine andere Seite aendert sich dessen TID, so dass sie die Nummer der neuen Seite enthaelt.\\
|
||||
\solution{
|
||||
Nein, denn die TID wird mitunter bereits woanders verwendet und darf deshalb nichtmehr geaendert werden.
|
||||
}
|
||||
\item \textbf{g)} Wenn in einer Anfrage ein Attribut auf Gleichheit mit einer Konstanten geprueft wird (z.B. alter = 42) und es existiert ein Index fuer dieses Attribut, dann ist der Zugriff ueber den Index grundsaetzlich schneller als ein Table-Scan. \\
|
||||
\solution{
|
||||
Nein, bei genau einem Eintrag nicht.
|
||||
}
|
||||
\item \textbf{h)} Felder variabler Laenge koennen nicht als Schluessel in einem Index verwendet werden.\\
|
||||
\solution{
|
||||
Nein, (also doch) denn es gibt Indexstrukturen die das ermoeglichen.
|
||||
}
|
||||
\item \textbf{i)} Bei der Vergroesserung der Hashtabelle bei Linear Hashing, wird die Zahl der Buckets jedes mal verdoppelt.\\
|
||||
\solution{
|
||||
Nein, sie wird jedes mal um eins erhoeht.
|
||||
}
|
||||
\item \textbf{j)} Bei der Suche nach einem Wert in einem B*-Baum muss immer bis zu einem Blattknoten abgestiegen werden.\\
|
||||
\solution{
|
||||
Ja, denn nur in den Blattknoten werden Daten gespeichert.
|
||||
}
|
||||
\item \textbf{k)} Ein B-Baum enthaelt Verweise auf Saetze, aber nie ganze Saetze.\\
|
||||
\solution{
|
||||
Nein, ein B-Baum kann im Allgemeinen beliebige Daten und Datenmengen enthalten, also auch Saetze.
|
||||
}
|
||||
\item \textbf{l)} Bei der Suche in einem R-Baum nach Objekten in einem bestimmten rechteckigen Bereich muss an jedem Knoten in maximal einen Ast abgestiegen werden. \\
|
||||
\solution{
|
||||
Swag.
|
||||
}
|
||||
\item \textbf{m)} Materialisierte Sichten koennen die Ausfuehrung von Anfragen beschleunigen.\\
|
||||
\solution{
|
||||
Ja, weil materialisierte Sichten, tatsaechlich im Speicher liegen.
|
||||
}
|
||||
\item \textbf{n)} Das C in den ACID-Eigenschaften von Transaktionen steht fuer Concurrency.\\
|
||||
\solution{
|
||||
Nein, fuer Consitency.
|
||||
}
|
||||
\item \textbf{o)} Bei reiner Forward-Recovery duerfen Aenderungen einer Transaktion erst nach deren erfolgreichem Commit in den Datenbestand eingebracht werden.\\
|
||||
\solution{
|
||||
Ja, denn wuerde man den commit Einbringen haette man evt. einen Inkonsitenten Zustand auf der Platte den man nicht rueckgaengig machen kann weil man nur Forward-Recovery hat.
|
||||
}
|
||||
\end{itemize}
|
||||
|
||||
|
||||
@ -31,26 +80,44 @@ Antworte mit richtig oder falsch und Begruendung. [4P pro Aufgabe, es wurden abe
|
||||
\subsection{a) - 12 Punkte}
|
||||
Fuer einen Puffer stehen drei Kacheln im Hauptspeicher zur Verfuegung. Die unten angegebene Referenzreihenfolge stellt einen Auszug aus dem Protokoll der Seitenzugriffe des Datenbanksystems dar. Vervollstaendigen Sie die Tablle: Geben Sie an, welche Seiten zu welchem Zeitpunkten in den Kacheln des Prozesses eingelagert sind, wenn das Datenbanksystem \textbf{Clock} als Seitenersetzungsstrategie verwendet. Notieren Sie auch die Kontrollzustaende fuer jede Belegung. \\
|
||||
|
||||
|
||||
\solswitch{
|
||||
\begin{tabular}{|r|r|r|r|r|r|r|}\hline
|
||||
Zeitpunkt & ... & n & n+1 & n+2 & n+3 & n+4 \\\hline
|
||||
Referenzfolge & ... & 3 & 9 & 3 & 5 & 2 \\\hline
|
||||
& & & & & & \\
|
||||
Hauptspeicher & & & & & & \\\hline
|
||||
Kachel A & ... & 8 & & & & \\\hline
|
||||
Kachel B & ... & 3 & & & & \\\hline
|
||||
Kachel C & ... & 7 & & & & \\\hline
|
||||
Kachel A & ... & 8 & & & & \\\hline
|
||||
Kachel B & ... & 3 & & & & \\\hline
|
||||
Kachel C & ... & 7 & & & & \\\hline
|
||||
& & & & & & \\
|
||||
Kontrollzustaende & & & & & & \\\hline
|
||||
Kachel A & ... & 1 & & & & \\\hline
|
||||
Kachel B & ... & 1 & & & & \\\hline
|
||||
Kachel C & ... & 1 & & & & \\\hline
|
||||
Kachel A & ... & 1 & & & & \\\hline
|
||||
Kachel B & ... & 1 & & & & \\\hline
|
||||
Kachel C & ... & 1 & & & & \\\hline
|
||||
Auswahlzeiger auf Kachel & ... & C & & & & \\\hline
|
||||
\end{tabular}
|
||||
}{
|
||||
\begin{tabular}{|r|r|r|r|r|r|r|}\hline
|
||||
Zeitpunkt & ... & n & n+1 & n+2 & n+3 & n+4 \\\hline
|
||||
Referenzfolge & ... & 3 & 9 & 3 & 5 & 2 \\\hline
|
||||
& & & & & & \\
|
||||
Hauptspeicher & & & & & & \\\hline
|
||||
Kachel A & ... & 8 & 8 & 8 & 5 & 5 \\\hline
|
||||
Kachel B & ... & 3 & 3 & 3 & 3 & 2 \\\hline
|
||||
Kachel C & ... & 7 & 9 & 9 & 9 & 9 \\\hline
|
||||
& & & & & & \\
|
||||
Kontrollzustaende & & & & & & \\\hline
|
||||
Kachel A & ... & 1 & 0 & 0 & 1 & 0 \\\hline
|
||||
Kachel B & ... & 1 & 0 & 1 & 1 & 1 \\\hline
|
||||
Kachel C & ... & 1 & 1 & 1 & 1 & 0 \\\hline
|
||||
Auswahlzeiger auf Kachel & ... & C & A & A & B & C \\\hline
|
||||
\end{tabular}
|
||||
}
|
||||
|
||||
\subsection{b) - 8 Punkte}
|
||||
Ergaenzen sie die folgende Tabelle um alle Funktionen mit ihren Parametern und ihrem Rueckgabewert, die ein Datenbankpuffer an seiner Schnittstelle zur verfuegung stellen muss. Beschreiben sie jede Funktion kurz, so dass eindeutitg erkennbar ist, was sie tut und welche Bedeutung die Parameter haben. Moeglicherweise benoetigen sie nicht alle Zeilen der Tabelle. \\ \\
|
||||
|
||||
\solswitch{
|
||||
\begin{tabular}{|r|r|r|r|}
|
||||
\textbf{Funktion} & \textbf{Parameter} & \textbf{Rueckgabewert} & \textbf{Beschreibung} \\\hline \\ \\
|
||||
& & & \\\hline \\ \\ \\
|
||||
@ -59,6 +126,13 @@ Ergaenzen sie die folgende Tabelle um alle Funktionen mit ihren Parametern und i
|
||||
& & & \\\hline \\ \\ \\
|
||||
& & & \\\hline
|
||||
\end{tabular}
|
||||
}{
|
||||
\begin{tabular}{|l|l|l|l|}
|
||||
\textbf{Funktion} & \textbf{Parameter} & \textbf{Rueckgabewert} & \textbf{Beschreibung} \\ \hline
|
||||
fix & Datei, BlockNo, Mode & Pointer auf Seite im Puffer & laed in Puffer, lockt fuer andere \\\hline
|
||||
unfix & Pointer auf Seite im Puffer & void & gibt Block im Puffer fuer Ersetzung frei \\\hline
|
||||
\end{tabular}
|
||||
}
|
||||
|
||||
\newpage
|
||||
\section{Aufgabe 3 TID-Adressierung - 14 Punkte}
|
||||
@ -78,12 +152,21 @@ F & & & \\\hline
|
||||
\end{tabular}
|
||||
\hspace{10mm}
|
||||
%\textbf{Seite 1}
|
||||
\solswitch{
|
||||
\begin{tabular}{c|c|c|c}
|
||||
& & & \\\hline
|
||||
& & & \\\hline
|
||||
& & & \\\hline
|
||||
& & & 0
|
||||
\end{tabular}
|
||||
}{
|
||||
\begin{tabular}{c|c|c|c}
|
||||
x & x & x & x \\\hline
|
||||
x & x & x & x \\\hline
|
||||
x & x & & \\\hline
|
||||
& & & 0
|
||||
\end{tabular}
|
||||
}
|
||||
%\textbf{Seite 2}
|
||||
\hspace{10mm}
|
||||
\begin{tabular}{c|c|c|c}
|
||||
@ -93,7 +176,7 @@ F & & & \\\hline
|
||||
& & & 0
|
||||
\end{tabular}\\\\
|
||||
-\hspace{8mm} Seite 0 \hspace{2cm} Seite 1 \hspace{2cm} Seite 2 \hspace{2cm} -\\\\
|
||||
\textbf{Laenge 10: TID(\hspace{5mm},\hspace{5mm})}
|
||||
\solswitch{ \textbf{Laenge 20: TID(\hspace{5mm},\hspace{5mm})} }{ { \textbf{Laenge 20: TID( 1 , 0 })} }
|
||||
|
||||
% b ------------------------------------------------------------------------------------ b%
|
||||
\item \textbf{b)} Die Seiten enthalten zum Ausgangszeitpunkt zwei Saetze mit TID(0,0), Laenge 12 und TID(1,0), Laenge 6. Fuegen sie einen Satz mit Laenge 20 ein.\\ \\
|
||||
@ -104,6 +187,7 @@ F & F & F & F \\\hline
|
||||
& & & 0
|
||||
\end{tabular}
|
||||
\hspace{10mm}
|
||||
\solswitch{
|
||||
%\textbf{Seite 1}
|
||||
\begin{tabular}{c|c|c|c}
|
||||
F & F & F & F \\\hline
|
||||
@ -119,8 +203,25 @@ F & F & & \\\hline
|
||||
& & & \\\hline
|
||||
& & &
|
||||
\end{tabular}\\\\
|
||||
}{
|
||||
%\textbf{Seite 1}
|
||||
\begin{tabular}{c|c|c|c}
|
||||
F & F & F & F \\\hline
|
||||
F & F & TID & (2,0) \\\hline
|
||||
x & x & x & x \\\hline
|
||||
x & x & 6 & 0
|
||||
\end{tabular}
|
||||
%\textbf{Seite 2}
|
||||
\hspace{10mm}
|
||||
\begin{tabular}{c|c|c|c}
|
||||
x & x & x & x \\\hline
|
||||
x & x & x & x \\\hline
|
||||
x & x & x & x \\\hline
|
||||
x & x & & 0
|
||||
\end{tabular}\\\\
|
||||
}
|
||||
- \hspace{8mm} Seite 0 \hspace{2cm} Seite 1 \hspace{2cm} Seite 2 \hspace{2cm} -\\\\ %dont ask and dont try yo remove the -
|
||||
\textbf{Laenge 20: TID(\hspace{5mm},\hspace{5mm})}
|
||||
\solswitch{ \textbf{Laenge 20: TID(\hspace{5mm},\hspace{5mm})} }{ { \textbf{Laenge 20: TID( 1 , 1 })} }
|
||||
% c ------------------------------------------------------------------------------------ c%
|
||||
\newpage
|
||||
\item \textbf{c)} Die Seiten enthalten zum Ausgangszeitpunkt zwei Saetze mit TID(0,0), Laenge 4 und TID(0,1), Laenge 8.\\ \\
|
||||
|
||||
@ -14,6 +14,6 @@ cleanup:
|
||||
@latexmk -quiet -jobname=$(@:%.continuous=%) -pvc -pdf $(@:%.continuous=%).tex
|
||||
|
||||
%.pdf: %.tex
|
||||
@latexmk -quiet -jobname=$(@:%.pdf=%) -pdf -halt-on-error $< 1>/dev/null
|
||||
@latexmk -jobname=$(@:%.pdf=%) -pdf -halt-on-error $<
|
||||
|
||||
.PHONY: all continuous cleanup single clean rmpdf solutions
|
||||
|
||||
Loading…
Reference in New Issue
Block a user