mirror of
https://gitlab.cs.fau.de/ik15ydit/latexandmore.git
synced 2024-11-22 11:49:32 +01:00
IDB Braindump finished
This commit is contained in:
parent
b69fbc2447
commit
b090d65e16
Binary file not shown.
@ -1,157 +1,194 @@
|
||||
\documentclass{article}
|
||||
\usepackage[final]{pdfpages}
|
||||
\usepackage{listings}
|
||||
\usepackage{graphicx}
|
||||
|
||||
\usepackage[ngerman]{babel}
|
||||
|
||||
\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}
|
||||
|
||||
\section{Disclaimer}
|
||||
Dies ist selbstverstaendlich alles studentisch blabla, Fehler = nicht rumweinen sondern Pullrequest machen. README lesen fuer mehr Info.
|
||||
\section{Disclaimer Bitches}
|
||||
\subsection{What's this}
|
||||
Dies ist eine studentische Prüfungsschwierigkeit immitierende Aufgabenzusammenfassung die Themen der Vorlesung Implementieren von Datenbanken. Es handelt sich insbesondere nicht um einen sogenannten "Braindump". Die Aufgaben oritieren sich an den Aufgaben in der ursprünglichen Klausur insofern, dass hier zum Beipsiel anstatt der Frage "Sind Kühe Lila?" die Frage "Machen Kuehe Schokolade?" steht. Auf beide Fragen ist die Antwort: Nein, du schaust zuviel Milkawerbung.
|
||||
|
||||
\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]
|
||||
\subsection{Allgemeiner Sicherheitshinweis}
|
||||
Vorsicht ist die Mutter der Porzelankiste bei dieser Klausur, auch im WS1617 (der Nachfolgeklausur von dieser hier) kam mit R-Baumen z.B. ein voellig neuer Aufgabentyp in die Klausur, es ist naheliegen, dass dies auch in Zukunf passieren wird. Ausserdem koennen hier natuerlich selbstverstaendlich Fehler enthalten sein.
|
||||
|
||||
\subsection{Anything else?}
|
||||
Schaut auf meinem gitlab vorbei wenn ihr dieses Dokument verbesser wollte, Pullrequest werden gerne gesehen. \textit{gitlab.cs.fau.de/ik15ydit/latexandmore} Außerdem bedanke ich mich beim Lehrstuhl fuer Datenbanksystem der Uni Erlangen fuer ihre Umfassenden Lernmaterialien und exzelennte Literaturempfehlung die Erstellung von Loesung und erarbeiten von Alternativen Frage und Aufgabenstellungen so stark erleichtert haben. Falls ihr ueber diese Klausur diskutieren wollte koennt ihr dafuer das bereitsexistierende \textit{https://pad.stuve.fau.de/p/idb} verwenden.\\\\\\
|
||||
\includegraphics[width=1\textwidth]{idb_done.png} %70% der Textbreite
|
||||
\newpage
|
||||
% ---------------------------- PAGEBREAK ----------------------------
|
||||
\section{Aufgabe 1 - Kunterbunte Schic *hicks* ten}
|
||||
Begründe warum folgende Aussage korrekt oder inkorret ist. Es gibt nur einen Punkt wenn Antwort UND Begruendung richtig sind.
|
||||
\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{a)} Ein Sektor auf einem Speicherzylinder ist genau groß genug fuer einen Satz.
|
||||
\vspace{1cm}
|
||||
\solution{
|
||||
Ja, weil ist schneller.
|
||||
Nein, die größe eines Sektors ist nicht definiert, er ist wahrscheinlich größer.
|
||||
}
|
||||
\item \textbf{b)} Die von der Schicht der Speicherstrukturen angebotenen Adressierungseinheiten umfassen unter anderem Tupel, Relationen und Sichten.\\
|
||||
\vspace{1cm}
|
||||
\item \textbf{b)} Blockt- und Seitenabellen sind in den Speicherzuordnungstrukturen angesiedelt.\\
|
||||
\vspace{1cm}
|
||||
\solution{
|
||||
Nein, das waere die Schicht der logischen Datenstruckturen
|
||||
Nein, bei den Seitenzuordnungsstrukturen.
|
||||
}
|
||||
\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\\
|
||||
\vspace{1cm}
|
||||
\item \textbf{c)} Blöcke müssen nur bei direkter Seitenzuordnung gleich groß sein.\\
|
||||
\vspace{1cm}
|
||||
\solution{
|
||||
Ja, denn alle Seiten sind gleich groß und liegen hintereinander im Speicher.
|
||||
Nein, theoretisch könnten mit entsprechenden Verwaltungsoverhead verschieden große Blöcke verwendet werden.
|
||||
}
|
||||
\item \textbf{d)} Das Problem der Seitenersetzungsstrategie LFU (Least frequently used) fuer den Datenbankpuffer ist, dass Seiten im Puffer nicht alt werden.\\
|
||||
\vspace{1cm}
|
||||
\item \textbf{d)} Die Seitenersetzungsstrategie LFU (Least frequently used) hat der Vorteil, dass sich der Puffer schnell an neue Datenlokalitaeten anpasst.\\
|
||||
\vspace{1cm}
|
||||
\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.
|
||||
Nein, 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.\\
|
||||
\vspace{1cm}
|
||||
\item \textbf{e)} Eine Seite im Datenbankpuffer muss irgendwann auf die Platte zurueckgeschrieben werden..\\
|
||||
\vspace{1cm}
|
||||
\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.\\
|
||||
\vspace{1cm}
|
||||
\item \textbf{f)} Bei der Verlaengerung eines Satzes kann es vorkommen, dass sich dessen TID aendert.\\
|
||||
\vspace{1cm}
|
||||
\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. \\
|
||||
\vspace{1cm}
|
||||
\item \textbf{g)} Ein Zugriff ueber einen Index ist immer schneller als ein Table-Scan. \\
|
||||
\vspace{1cm}
|
||||
\solution{
|
||||
Nein, bei genau einem Eintrag nicht.
|
||||
}
|
||||
\item \textbf{h)} Felder variabler Laenge koennen nicht als Schluessel in einem Index verwendet werden.\\
|
||||
\vspace{1cm}
|
||||
\item \textbf{h)} Ein Schluessel in einem Index, darf nicht nicht von fester Laenge sein verwendet werden. [Das - nicht nicht - ist beabsichtigt]\\
|
||||
\vspace{1cm}
|
||||
\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.\\
|
||||
\vspace{1cm}
|
||||
\item \textbf{i)} Die Hashtabelle beim Linearen Hashing, wird, wenn sie vergroessert wird, jedes mal um den einen festen Wert n erhoeht.\\
|
||||
\vspace{1cm}
|
||||
\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.\\
|
||||
\vspace{1cm}
|
||||
\item \textbf{j)} Wenn in einem B*-Baum Werte gesucht werden, muss immer bis zu einem Knoten ohne Kind abgestiegen werden.\\
|
||||
\vspace{1cm}
|
||||
\solution{
|
||||
Ja, denn nur in den Blattknoten werden Daten gespeichert.
|
||||
Nein, denn nur in den Blattknoten werden Daten gespeichert.
|
||||
}
|
||||
\item \textbf{k)} Ein B-Baum enthaelt Verweise auf Saetze, aber nie ganze Saetze.\\
|
||||
\vspace{1cm}
|
||||
\item \textbf{k)} Ein B-Baum kann keine variablen Daten enthalten.\\
|
||||
\vspace{1cm}
|
||||
\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. \\
|
||||
\vspace{1cm}
|
||||
\item \textbf{l)} In einem R-Baum kann es vorkommen, dass wir auf der Suche nach einen Wert mehrere Blattknoten betrachten muessen. \\
|
||||
\vspace{1cm}
|
||||
\solution{
|
||||
Swag.
|
||||
Nein, R-Baume sind Suchbaeume, daher wissen wir immer in welchen Ast wir absteigen muessen, und es kann nicht sein, dass wir uns mehrere Blaetter auf der Suche nach einem Wert anschauen muessen.
|
||||
}
|
||||
\item \textbf{m)} Materialisierte Sichten koennen die Ausfuehrung von Anfragen beschleunigen.\\
|
||||
\vspace{1cm}
|
||||
\item \textbf{m)} Sichten beschleunigen die Aussfuehrung von Anfragen.\\
|
||||
\vspace{1cm}
|
||||
\solution{
|
||||
Ja, weil materialisierte Sichten, tatsaechlich im Speicher liegen.
|
||||
Nein, nur materialisierte Sichten die tatsaechlich im Speicher liegen.
|
||||
}
|
||||
\item \textbf{n)} Das C in den ACID-Eigenschaften von Transaktionen steht fuer Concurrency.\\
|
||||
\vspace{1cm}
|
||||
\item \textbf{n)} In den ACID-Eigenschaften einer Transaktionen steht das A fuer Authencity.\\
|
||||
\vspace{1cm}
|
||||
\solution{
|
||||
Nein, fuer Consitency.
|
||||
Nein, fuer Atomacy.
|
||||
}
|
||||
\item \textbf{o)} Bei reiner Forward-Recovery duerfen Aenderungen einer Transaktion erst nach deren erfolgreichem Commit in den Datenbestand eingebracht werden.\\
|
||||
\vspace{1cm}
|
||||
\item \textbf{o)} Bei Forward-Recovery darf kein "steal" stattfinden.\\
|
||||
\vspace{1cm}
|
||||
\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.
|
||||
Ja, steal beudetet, dass Dinge aus dem Puffer vor Ende der Transaktion zurueckgeschrieben werden, damit haette man evt. einen Inkonsitenten Zustand auf der Platte den man nicht rueckgaengig machen kann weil man Forward-Recovery hat.
|
||||
}
|
||||
\end{itemize}
|
||||
|
||||
\newpage
|
||||
% ---------------------------- PAGEBREAK ----------------------------
|
||||
|
||||
\section{Aufgabe 2 Datenbankpuffer}
|
||||
\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. \\
|
||||
\section{Aufgabe 2 Ich weiss wo deine TID wohnt}
|
||||
\subsection{a)}
|
||||
Deine Mutter hat \textbf{Clock} als Seitenersetzungsstrategie verwendet und kapiert jetzt ihren eigenen Code nicht mehr, deswegen musst du die Seitenersetzungsstrategie jetzt unten nachbauen. Du hast 3 Plaetze in deinem Haupspeicher, die haben jeweils einen Kontrollzustand (also auch 3 insgesamt) unten ist dann noch dein Pointer bei welchem Platz du gerade bist. GoGoGo!!!\\\\
|
||||
|
||||
\hspace{2cm}
|
||||
\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
|
||||
Input & ... & 4 & 7 & 2 & 1 & 5 \\\hline
|
||||
& & & & & & \\
|
||||
Hauptspeicher & & & & & & \\\hline
|
||||
Kachel A & ... & 8 & & & & \\\hline
|
||||
Kachel B & ... & 3 & & & & \\\hline
|
||||
Kachel C & ... & 7 & & & & \\\hline
|
||||
Speicherplatz A & ... & 4 & & & & \\\hline
|
||||
Speicherplatz B & ... & 1 & & & & \\\hline
|
||||
Speicherplatz C & ... & 9 & & & & \\\hline
|
||||
& & & & & & \\
|
||||
Kontrollzustaende & & & & & & \\\hline
|
||||
Kachel A & ... & 1 & & & & \\\hline
|
||||
Kachel B & ... & 1 & & & & \\\hline
|
||||
Kachel C & ... & 1 & & & & \\\hline
|
||||
Auswahlzeiger auf Kachel & ... & C & & & & \\\hline
|
||||
Platz A & ... & 1 & & & & \\\hline
|
||||
Platz B & ... & 1 & & & & \\\hline
|
||||
Platz C & ... & 1 & & & & \\\hline
|
||||
Cur. Pointer & ... & 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
|
||||
Input & ... & 4 & 7 & 2 & 7 & 5 \\\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
|
||||
Speicherplatz A & ... & 4 & 4 & 2 & 2 & 2 \\\hline
|
||||
Speicherplatz B & ... & 1 & 1 & 1 & 1 & 5 \\\hline
|
||||
Speicherplatz C & ... & 9 & 7 & 7 & 7 & 7 \\\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
|
||||
Platz A & ... & 1 & 0 & 1 & 1 & 1 \\\hline
|
||||
Platz B & ... & 1 & 0 & 0 & 0 & 1 \\\hline
|
||||
Platz C & ... & 1 & 1 & 1 & 1 & 1 \\\hline
|
||||
Cur. Pointer & ... & C & A & B & B & C \\\hline
|
||||
\end{tabular}
|
||||
}
|
||||
\vspace{1cm}
|
||||
\subsection*{b)}
|
||||
Gebe an welche Schnittstellen ein Datenbankpuffer \textbf{nach oben im Schichtenmodell} anbieten muss. (Welche Parameter, welche Rueckgabewerte und wozu sie dient.)
|
||||
|
||||
\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 \\ \\ \\
|
||||
& & & \\\hline \\ \\ \\
|
||||
& & & \\\hline \\ \\ \\
|
||||
& & & \\\hline \\ \\ \\
|
||||
& & & \\\hline
|
||||
\end{tabular}
|
||||
}{
|
||||
\solution{
|
||||
\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
|
||||
fix & Datei, BlockNo, Mode & Pointer auf Seite & laed in Puffer, lockt fuer andere \\\hline
|
||||
unfix & Pointer auf Seite im Puffer & void & gibt Block im Puffer fuer Ersetzung frei \\\hline
|
||||
\end{tabular}
|
||||
}
|
||||
|
||||
% ---------------------------- PAGEBREAK ----------------------------
|
||||
\newpage
|
||||
\section{Aufgabe 3 TID-Adressierung - 14 Punkte}
|
||||
Ergaenzen sie in den folgenden Teilaufgaben die Skizzen so, dass sie den Zustand nach der jeweils angegebenen Operation darstellen. Geben sie ausserdem die TIDs der Saetze mit den angegebenen Laengen nach der Ausfuerung der Operation an.\\ \\
|
||||
Die Saetze werden ueber TIDs adressiert. Eine TID benoetigt 2 Beyte und ein Indexeintrag 1 Byte Speicherplatz. Jeder Block hat eine Groesse von 16 Bytes. ein Byte ist jeweils durch ein Kaestchen repraesentiert. Die Frespeicherverwaltung durchsucht die Seiten in der Reihenfolge 0,1,2 nach freiem Platz. Freier Speicher innerhalb einer Seite befindet sich immer nur am Seitenende. \\ \\
|
||||
Es muss keine Laengen- oder Headerinformtion zu den Saetzen gespeichert werden. Diese sei dem System bekannt. Saetze werden nur fragmenteirt, wenn es notwendig ist. Verweise zwischen Fragmenten und bei Verschiebungen sind einzutragen, in der Form \textbf{TID(3,2)}. Die ersten Fragmente eines fragmentierten Satzes belegen immer ganze Bloecke. Nur das letze Fragment kann in einem schon teilwese belegten Block abgelegt werden. \\ \\
|
||||
Die Teilaufgaben sind voneinander unabhaengig. Ein F steht fuer bereits voll. \\
|
||||
|
||||
\section{Aufgabe 3 TID-Adressierung}
|
||||
TIDs nach Regeln aus der Vorlesung ergaenzen/eintragen und TID angeben.
|
||||
Teilaufgaben sind unabhaengig. Buchstaben stehen fuer bereits vorhandene Saetze \\
|
||||
|
||||
\begin{itemize}
|
||||
% a ------------------------------------------------------------------------------------ a%
|
||||
\item \textbf{a)} Die Seiten enthalten zum Ausgangszeitpunkt einen Satz der Laenge 5 mit TID(0,0). Fuegen sie einen Satz mit Laenge 10 ein.\\ \\
|
||||
\item \textbf{a)} Fuegen einen Satz A mit Laenge 12 ein.\\ \\
|
||||
%\textbf{Seite 1}
|
||||
\begin{tabular}{c|c|c|c}
|
||||
F & F & F & F \\\hline
|
||||
F & & & \\\hline
|
||||
F & F & F & \\\hline
|
||||
& & & \\\hline
|
||||
& & & \\\hline
|
||||
& & & 0
|
||||
\end{tabular}
|
||||
\hspace{10mm}
|
||||
%\textbf{Seite 1}
|
||||
%\textbf{Seite 2}
|
||||
\solswitch{
|
||||
\begin{tabular}{c|c|c|c}
|
||||
& & & \\\hline
|
||||
@ -163,12 +200,10 @@ F & & & \\\hline
|
||||
\begin{tabular}{c|c|c|c}
|
||||
x & x & x & x \\\hline
|
||||
x & x & x & x \\\hline
|
||||
x & x & & \\\hline
|
||||
x & x & x & x \\\hline
|
||||
& & & 0
|
||||
\end{tabular}
|
||||
}
|
||||
%\textbf{Seite 2}
|
||||
\hspace{10mm}
|
||||
}\hspace{10mm}
|
||||
\begin{tabular}{c|c|c|c}
|
||||
& & & \\\hline
|
||||
& & & \\\hline
|
||||
@ -176,22 +211,27 @@ x & x & & \\\hline
|
||||
& & & 0
|
||||
\end{tabular}\\\\
|
||||
-\hspace{8mm} Seite 0 \hspace{2cm} Seite 1 \hspace{2cm} Seite 2 \hspace{2cm} -\\\\
|
||||
\solswitch{ \textbf{Laenge 20: TID(\hspace{5mm},\hspace{5mm})} }{ { \textbf{Laenge 20: TID( 2 , 0 })} }
|
||||
\solswitch{ \textbf{Satz A: TID(\hspace{5mm},\hspace{5mm})} }{ { \textbf{Satz A: TID( 2 , 0 })} }
|
||||
\vspace{1cm}
|
||||
|
||||
|
||||
|
||||
% 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.\\ \\
|
||||
|
||||
|
||||
\item \textbf{b)} Ausgangsbelegung mit Saetzen F und X. Fuegen den Satz B, Laenge 14 ein.\\ \\
|
||||
\begin{tabular}{c|c|c|c}
|
||||
F & F & F & F \\\hline
|
||||
F & F & F & F \\\hline
|
||||
F & F & F & F \\\hline
|
||||
F & F & F & \\\hline
|
||||
& & & 0
|
||||
\end{tabular}
|
||||
\hspace{10mm}
|
||||
\solswitch{
|
||||
%\textbf{Seite 1}
|
||||
\begin{tabular}{c|c|c|c}
|
||||
F & F & F & F \\\hline
|
||||
F & F & & \\\hline
|
||||
X & X & X & X \\\hline
|
||||
X & X & X & X \\\hline
|
||||
& & & \\\hline
|
||||
& & &
|
||||
\end{tabular}
|
||||
@ -207,30 +247,34 @@ F & F & & \\\hline
|
||||
%\textbf{Seite 1}
|
||||
\begin{tabular}{c|c|c|c}
|
||||
F & F & F & F \\\hline
|
||||
F & F & x & x \\\hline
|
||||
x & x & x & x \\\hline
|
||||
x & & 6 & 0
|
||||
F & F & B & \\\hline
|
||||
& & & \\\hline
|
||||
& & 5 & 0
|
||||
\end{tabular}
|
||||
%\textbf{Seite 2}
|
||||
\hspace{10mm}
|
||||
\begin{tabular}{c|c|c|c}
|
||||
TID & (1,1) & x & x \\\hline
|
||||
x & x & x & x \\\hline
|
||||
x & x & x & x \\\hline
|
||||
x & x & x & 0
|
||||
TID & (1,1) & B & B \\\hline
|
||||
B& B & B & B \\\hline
|
||||
B& B & B & B \\\hline
|
||||
B& B & B & 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 -
|
||||
\solswitch{ \textbf{Laenge 20: TID(\hspace{5mm},\hspace{5mm})} }{ { \textbf{Laenge 20: TID( 1 , 1 })} }
|
||||
% c ------------------------------------------------------------------------------------ c%
|
||||
\solswitch{ \textbf{Satz A: TID(\hspace{5mm},\hspace{5mm})} }{ { \textbf{Satz A: TID( 1 , 1 })} }
|
||||
|
||||
% ---------------------------- PAGEBREAK ----------------------------
|
||||
\newpage
|
||||
\item \textbf{c)} Die Seiten enthalten zum Ausgangszeitpunkt zwei Saetze mit TID(0,0), Laenge 4 und TID(0,1), Laenge 8.\\ \\
|
||||
\textbf{Ausganszustand (Loesung nicht hier sondern unten eintragen)}\\\\
|
||||
% c ------------------------------------------------------------------------------------ c%
|
||||
|
||||
\newpage
|
||||
\item \textbf{c)} Die Satze F,C und X sind bereits vorhanden.\\ \\
|
||||
\textbf{Ausganszustand}\\\\
|
||||
\begin{tabular}{c|c|c|c}
|
||||
F & F & F & F \\\hline
|
||||
X & X & X & X \\\hline
|
||||
X & X & X & X \\\hline
|
||||
& & 4 & 0
|
||||
F & X & X & X \\\hline
|
||||
X & C & C & C \\\hline
|
||||
& 9 & 5 & 0
|
||||
\end{tabular}
|
||||
\hspace{10mm}
|
||||
%\textbf{Seite 1}
|
||||
@ -249,7 +293,9 @@ X & X & X & X \\\hline
|
||||
& & &
|
||||
\end{tabular}\\\\
|
||||
- \hspace{8mm} Seite 0 \hspace{2cm} Seite 1 \hspace{2cm} Seite 2 \hspace{2cm} -\\\\ %dont ask and dont try yo remove the -
|
||||
Vergroessern sie den Satz TID(0,1) auf Laenge 12.\\\\
|
||||
Satz C@TID(0,2) auf Laenge 15.\\\\
|
||||
|
||||
\solswitch{
|
||||
\begin{tabular}{c|c|c|c}
|
||||
& & & \\\hline
|
||||
& & & \\\hline
|
||||
@ -272,131 +318,211 @@ Vergroessern sie den Satz TID(0,1) auf Laenge 12.\\\\
|
||||
& & & \\\hline
|
||||
& & &
|
||||
\end{tabular}\\\\
|
||||
}{
|
||||
\begin{tabular}{c|c|c|c}
|
||||
F & F & F & F \\\hline
|
||||
F & X & X & X \\\hline
|
||||
X & TID & (1,0) & \\\hline
|
||||
& 9 & 5 & 0
|
||||
\end{tabular}
|
||||
\hspace{10mm}
|
||||
%\textbf{Seite 1}
|
||||
\begin{tabular}{c|c|c|c}
|
||||
x & x & x & x \\\hline
|
||||
x & x & x & x \\\hline
|
||||
x & x & x & x \\\hline
|
||||
x & x & x & 0
|
||||
\end{tabular}
|
||||
%\textbf{Seite 2}
|
||||
\hspace{10mm}
|
||||
\begin{tabular}{c|c|c|c}
|
||||
& & & \\\hline
|
||||
& & & \\\hline
|
||||
& & & \\\hline
|
||||
& & &
|
||||
\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 4: TID(\hspace{5mm},\hspace{5mm}), Laenge 12: TID(\hspace{5mm},\hspace{5mm})}
|
||||
\solswitch{ \textbf{Satz F: TID(\hspace{5mm},\hspace{5mm}), Satz X: TID(\hspace{5mm},\hspace{5mm}), Satz C: TID(\hspace{5mm},\hspace{5mm})} }{ \textbf{Satz F: TID( 0 , 0 ), Satz X: TID( 0 , 1 ), Satz C: TID( 0 , 2)} }
|
||||
|
||||
\end{itemize}
|
||||
|
||||
\section{Aufgabe 4 Indexstrukturen - 26 Punkte}
|
||||
\subsection{Ankreuzerino}
|
||||
\subsubsection*{Kreuzen sie an wie viele Primaerorganisationen es fuer eine Satzmenge ohne Redundanz maximal geben kann}
|
||||
\begin{itemize}
|
||||
\item keine
|
||||
\item eine
|
||||
\item zwei
|
||||
\item beliebig viele
|
||||
\end{itemize}
|
||||
\subsubsection*{Kreuzen sie an wie viele Sekundaerorganisationen es fuer eine Satzmenge ohne Redundanz maximal geben kann}
|
||||
\begin{itemize}
|
||||
\item keine
|
||||
\item eine
|
||||
\item zwei
|
||||
\item beliebig viele
|
||||
\end{itemize}
|
||||
\subsection{Baumabfuck}
|
||||
\textbf{a)} Fuegen sie in einen anfangs leeren \textbf{B*-Baum} mit $k_{inner}=2$ und $k_{leaf}=1$ die Tupel
|
||||
\textbf{\hspace{1cm}(7,B)\hspace{1cm}(42,A)\hspace{1cm}(2,X) \hspace{1cm}} in dieser Reihenfolge ein. Die gegebenen Tupel sind nach dem Schema \textbf{(Schluessel,Wert)} aufgebaut. Zeichnen sie den entstandenen Baum nach dem Einfuegen aller Tupel. \\\\
|
||||
\textbf{b)} Loeschen sie aus dem gegebenen B-Baum den Schluessel 36. Zeichnen sie den entstandenen Baum nach dem komplett ausgefuehrten Loesungsweg.\\\\
|
||||
\textit{$->$ siehe Teilaufgabe c) f\"ur Baum}\\\\
|
||||
\textbf{c)} Nennen sie drei gruende, warum der folgende Baum kein korrekter \textbf{B-Baum} ist.\\\\
|
||||
\includepdf[pages=-]{BAUM.pdf}
|
||||
\textbf{d)} Gegeben ist eine Tabelle mit dem folgendem Schema, mit der Studentenwohnheimszimmer verwaltet werden:\\\\
|
||||
\textbf{Zimmer(Zimmernummer, Etage, MitKueche, MitBad, GehirngeschaedigteVollspassten)}\\\\
|
||||
Um die Suche nach Zimmern mit bestimmten Eigenschaften (z.B. Zimmer im Erdgeschoss mit Kueche und Bad) zu beschleunigen sollen ueber die Attribute \textbf{Etage, MitKueche, MitBad und GehirngeschaedigteVollspassten} Indizies angelegt werden. Kreuzen sie an, welche der folgenden Indexarten sich hierfuer am Besten eignet.
|
||||
\begin{itemize}
|
||||
\item B-Baum-Index
|
||||
\item B*-Baum-Index
|
||||
\item Hash-Index
|
||||
\item Bitmap-Index
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\section{Aufgabe 5 Transaktionen - Punkte 32}
|
||||
\subsection*{a) Nennen sie die Eigenschaft, die eine Real World Action erfuellen muss, damit sie als solche bezeichnet wird.}
|
||||
\vspace{1cm}
|
||||
\subsection*{b) Real World Actions muessen mindestens eine von zwei Eigenschaften erfuellen, damit sie im Rahmen einer Transaktion ausgefuehrt werden koennen. Nennen sie diese beiden Eigenschaften.}
|
||||
\vspace{1cm}
|
||||
\subsection*{c) Gegeben ist der folgende Ablauf dreier Transaktionen T1, T2, T3:}
|
||||
rN(x) bedeutet, Transaktion N liest Element x. wN(x) bedeutet, Transaktion N schreiben Element x.
|
||||
\begin{itemize}
|
||||
\item r2(a)
|
||||
\item r3(b)
|
||||
\item r3(c)
|
||||
\item r1(a)
|
||||
\item r3(a)
|
||||
\item w2(a)
|
||||
\item w3(b)
|
||||
\item r1(b)
|
||||
\item w1(c)
|
||||
\item w2(b)
|
||||
\end{itemize}
|
||||
Zeichnen sie den vollstaendigen Abhaengigkeitsgraphen und notieren sie an den kanten alle Datenobjekte, aufgrund derer die jeweiligen Abhaengigkeit besteht.\\\vspace{1cm}
|
||||
\subsection*{d) Begruenden sie in einem Satz warum der in Teilaufgabe-C gegebene Ablauf serialisierbar oder nicht serialisierbar ist.}
|
||||
% ---------------------------- PAGEBREAK ----------------------------
|
||||
\newpage
|
||||
\subsection*{e) Ein Programm in einer Supermarktkasse hat den im Folgenden beschriebenen Ablauf. Das eingesetzte Datenbanksystem garantiert die ACID-Eigenschaft von Transaktionen.}
|
||||
\begin{enumerate}
|
||||
\item Falls einer der folgenden Schritte scheitert, gib eine Fehlermeldung aus und springe zurueck zu \textbf{1.}
|
||||
\item DB-Transaktion starten
|
||||
\item Lokale Variable Gesamtpreis auf 0 setzen
|
||||
\item Wiederhole bis Ende-Taste gedrueckt
|
||||
\begin{enumerate}
|
||||
\item Artikelnummer von Kassierer Abfragen
|
||||
\item Artikel in der Datenbanktabelle aller Artikel ueber die Artikelnummer suchen
|
||||
\item Variable Gesamtpreis um Artikelpreis erhoehen
|
||||
\item Attribut Bestand des Artikels in der Datenbanktabelle aller Artikel um 1 verringern
|
||||
\end{enumerate}
|
||||
\item Gesamtpreis anzeigen
|
||||
\item Neuen Eintrag mit dem Gesamtpreis zur tabelle Umsaetze in der Datenbank hinzufuegen
|
||||
\item Transaktion mit Commit beenden und Erfolg oder Misserfolg des Commit dem Kassierer anzeigen
|
||||
\end{enumerate}
|
||||
Erklaeren sie in ein zwei bis drei Saetzen das Problem, das in Bezug auf Transaktionen (unter Vernachlaessigung etwaiger Real World Actions) bei diesem Ablauf auftreten kann. \\\vspace{1cm}
|
||||
\subsection*{f) Erklaeren sie in ein zwei bis drei Saetzen eine Moeglichkeit, den Programmablauf aus Aufgabe e) zu aendern, um das dort auftretende Problem zu vermeiden}\vspace{1cm}
|
||||
\subsection{Ankreuzehuehueriono}
|
||||
Gegeben ist ein Datenbanksystem, das sowohl ein Redo- also auch ein Undo-Log einsetzt und Action Consisten Checkpoints (d.h. es sind keine Aenderungsoperationen zum Sicherungspunkt aktiv) verwendet.
|
||||
\subsubsection*{Kreuzen sie and, bis zu welcher Stelle das Undo-Log waehrend des Undo-Laufs gelesen werden muss. Beachten sie die Leserichtung.}
|
||||
\begin{itemize}
|
||||
\item BOT-Eintrag der aeltesten Gewinner-Transaktion
|
||||
\item BOT-Eintrag der aeltesten Verlierer-Transaktion
|
||||
\item BOT-Eintrag der juengsten Gewinner-Transaktion
|
||||
\item BOT-Eintrag der juengsten Verlierer-Transaktion
|
||||
\item Beginn des Logs
|
||||
\item Ende des Logs
|
||||
\item Sicherungspunkt
|
||||
\end{itemize}
|
||||
\subsubsection*{Kreuzen sie an, beginnend ab welcher Stelle das Redo-Log waehrend des Redo-Laufs gelesen werden muss. Beachten sie die Leserichtung.}
|
||||
\begin{itemize}
|
||||
\item BOT-Eintrag der aeltesten Gewinner-Transaktion
|
||||
\item BOT-Eintrag der aeltesten Verlierer-Transaktion
|
||||
\item BOT-Eintrag der juengsten Gewinner-Transaktion
|
||||
\item BOT-Eintrag der juengsten Verlierer-Transaktion
|
||||
\item Beginn des Logs
|
||||
\item Ende des Logs
|
||||
\item Sicherungspunkt
|
||||
\end{itemize}
|
||||
|
||||
\section{Aufgabe 6 Anfragenverarbeitung - Punkte 18}
|
||||
\subsubsection*{a) Gegeben ist die folgende SQL-Anfrage. Zeichnen sie den nicht-optimierten Operatorengraphen.}
|
||||
\section{Aufgabe 4 Indrexsstrukturen}
|
||||
\subsubsection*{a) Erklaeren sie den Unterschied zwischen Primaer und Sekundaerorganisation im Bezug auf Datenspeicherung.}
|
||||
\vspace{1cm}
|
||||
\solution{Bei der Primaerorganisation werden die Daten tatsaechlich gespeichert, bei der Sekundaerorganisation werden sie nur referenziert, es kann also mehrere Sekundaerorganisationen ohne Datenredundanz geben.
|
||||
}
|
||||
\vspace{1cm}
|
||||
\textbf{b)} Fuege in einen leeren \textbf{B*-Baum} mit $k_{inner}=2$ und $k_{leaf}=1$ die Tupel
|
||||
\textbf{\hspace{1cm}(8,A)\hspace{1cm}(17,Z)\hspace{1cm}(1,U) \hspace{1cm}} in dieser Reihenfolge ein. Einzelschritte sind nicht noetig.\\\\
|
||||
\begin{lstlisting}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
.
|
||||
\end{lstlisting}
|
||||
\solution{
|
||||
\lstinputlisting{tree1.ascii}
|
||||
}
|
||||
\textbf{c)} Loesche aus dem folgenden B-Baum den Schluessel 10. Zwischenschritte sind nicht noetig.\\\\
|
||||
\solswitch{\lstinputlisting{tree2.ascii}}{
|
||||
\textbf{Wenn mir das wer baut fueg ichs ein.}
|
||||
}
|
||||
|
||||
% ---------------------------- PAGEBREAK ----------------------------
|
||||
\newpage
|
||||
|
||||
\noindent \textbf{d)} Nennen sie vier Gruende, warum der folgende Baum kein korrekter \textbf{B-Baum} ist.\\
|
||||
\solswitch{\lstinputlisting{tree3.ascii}\vspace{4cm}}{
|
||||
\begin{itemize}
|
||||
\item nicht balanciert
|
||||
\item 20 steht auf der falschen Seite, es haette oben bei 18 \textbf{rechts} eingetragen werden muessen
|
||||
\item es gibt kein $k_{inner}$ fuer das min/max in Knoten hinhaut
|
||||
\end{itemize}
|
||||
}
|
||||
\textbf{e)} Wir haben eine Tabelle in der wir Studenten verwalten wollen, darin gibt es folgende Attribute.\\\\
|
||||
\textbf{Student(Geschlecht, Jahrgang, Dumm, FSI-Mitglied, Gehirngeschaedigt)}\\\\
|
||||
Weil wir jetzt schnell die Korrelanz zwischen einer FSI-Mitgliedschaft und dem geistigen Zustand eines Studenten rausfinden wollen moechten wir einen Index ueber diese Attribute anlegen: \textbf{Dumm, FSI-Mitglied, Gehirngeschaedigt}. Welche Indexform eignet sich dafuer besonders gut?
|
||||
\solution{Bitmap-Index}
|
||||
|
||||
% ---------------------------- PAGEBREAK ----------------------------
|
||||
\newpage
|
||||
|
||||
\section{Aufgabe 5 Transaktionen}
|
||||
|
||||
\subsection*{a) Was ist eine Real-World-Action im Datenbank Kontext}
|
||||
\vspace{1cm}
|
||||
\solution{ Eine in der Realen Welt stattfindende, nicht rueckgaenig machbare Aktion. (?)}
|
||||
\vspace{1cm}
|
||||
|
||||
\subsection*{b) Welche Eigenschaften hat eine RWA die als Transaktion modeliert wurde wahrscheinlich gehabt?}
|
||||
\solution{ Sie war wahrscheinlich pruefbar oder wiederholbar.}
|
||||
\vspace{1cm}
|
||||
|
||||
\vspace{1cm}
|
||||
\subsection*{c) Ablauf von Transaktionen}
|
||||
rN(x) bedeutet, Transaktion N liest Element x. wN(x) bedeutet, Transaktion N schreiben Element x. Zeichne einen Abhaengigkeitsgraphen, es muss bei jeder Kante ersichtlich sein wie sie Zustande gekommen ist.
|
||||
\begin{itemize}
|
||||
\item w3(c)
|
||||
\item r3(b)
|
||||
\item w3(a)
|
||||
\item w2(b)
|
||||
\item r1(a)
|
||||
\item r2(b)
|
||||
\item w3(b)
|
||||
\item r1(a)
|
||||
\item w1(b)
|
||||
\item r2(c)
|
||||
\end{itemize}
|
||||
% ---------------------------- PAGEBREAK ----------------------------
|
||||
\newpage
|
||||
\subsection*{d) Wann ist ein Ablauf serialisierbar?}
|
||||
\vspace{1cm}
|
||||
\solution{ Wenn kein Zyklus im Abhaengigkeitsgraphen. }
|
||||
\vspace{1cm}
|
||||
\subsection*{e) Gegeben ist der folgende Ablauf im Kontext einer fiktiven Lagerverwaltung: (repraesentativ in Java-like Syntax, alle Methoden des fiktiven Datenbank Frameworks scheissen eine "Failure"-Exception.)}
|
||||
\begin{lstlisting}[language=java]
|
||||
class Failure extends Exception;
|
||||
class Gegenstand{...};
|
||||
while(true}{
|
||||
try{
|
||||
startTransaction();
|
||||
setLocalCounterToZero();
|
||||
while(!terminatedByOperator()){
|
||||
Gegenstand g = queryInputFromOperator(); //RWA
|
||||
if(isInInventory(g)){
|
||||
incrementLocalCounter();
|
||||
decrementInventoryCountInDatabase();
|
||||
}else{
|
||||
displayErrorMessage();
|
||||
continue;
|
||||
}
|
||||
}
|
||||
writeNewEntryToDatabase(getUser(),getLocalCounter());
|
||||
commitTransaction(); //die Transaktion wird beendet
|
||||
}catch(Failure f)
|
||||
continue;
|
||||
}
|
||||
}
|
||||
\end{lstlisting}
|
||||
\textbf{Erklaere welches Problem hier Problem hier auftreten kann und wie es zu loesen waere.}
|
||||
\solution{
|
||||
Während der Transaktion wird auf Eingabedaten von des Operators gewartet und währenddessen sind alle anderen Transaktionen auf die gleiche Datenbanktabelle blockiert. Es kann passieren, dass der Operator extrem lange mit der Eingabe braucht und derweil sind andere DB-Zugriffe blockiert. Die Loesung ist die Transaktion kleiner zu machen und den lokalen counter irgendwie mit in die DB zu commiten sobald man etwas am Bestand aendert.
|
||||
}
|
||||
\newpage
|
||||
% ---------------------------- PAGEBREAK ----------------------------
|
||||
\subsubsection*{f) Inwiefern begrenzen Action-Consisten-Checkpoints Undo- und Redooperationen?}
|
||||
\vspace{1cm}
|
||||
\solution{
|
||||
TODO
|
||||
}
|
||||
\vspace{1cm}
|
||||
|
||||
\section{Aufgabe 6 SQL und Mengen}
|
||||
\subsubsection*{a) Operatorengraphen zu SQL-Kot unten. (muss nicht optimiert werden)}
|
||||
\begin{lstlisting}[language=SQL]
|
||||
SELECT *
|
||||
FROM (
|
||||
SELECT R.a, R.b, S.c
|
||||
FROM R JOIN S on R.p = S.p
|
||||
WHERE S.d = 42
|
||||
SELECT X.b, X.e, Z.c
|
||||
FROM R JOIN S on R.k = S.k
|
||||
WHERE S.u = "¯\_(ツ)_/¯"
|
||||
UNION
|
||||
SELECT T.a, T.b, T.c
|
||||
SELECT T.b, T.e, T.c
|
||||
FROM T
|
||||
) X
|
||||
WHERE X.b > 10;
|
||||
WHERE X.b < 0;
|
||||
\end{lstlisting}
|
||||
\subsubsection*{b) Gegeben sind zwei Relationen R und S, die beide ueber die gleichen Attribute verfuegen. E sei eine echte Teilmenge der Attributmenge von R bzw. S. Begruenden sie, warum die folgende Behauptung gilt oder nicht gilt.}
|
||||
\newpage
|
||||
% ---------------------------- PAGEBREAK ----------------------------
|
||||
\subsubsection*{b) Warum gilt folgendes nicht allgemein? (ein bis zwei Saetze, Gegenbeispiel reicht nicht)}
|
||||
\begin{lstlisting}[language=SQL]
|
||||
PROJ( R - S , E ) = PROJ( R , E) - PROJ( S , E)
|
||||
PROJ( A - B , X ) = PROJ( A , X) - PROJ( B , X)
|
||||
\end{lstlisting}
|
||||
Umgangssprachlich: Duerfen Mengendifferenz und Projektion vertauscht werden? \\\\
|
||||
\textit{'-' steht hier fuer die Differenz zweier Mengen}
|
||||
\solswitch{\vspace{3cm}}{\vspace{1cm}Nein, denn es gehen bei der Projection Informationen verloren, die spaeter fuer die Differenz der Mengen einen Unterschied machen koennten. (Eine Tabelle mit drei Attributen die auf zwei Attribute reduziert/projeziert wurde und in der nur Zeilen gleich scheinen weil das unterscheidende dritte Attribut nicht mehr sichtbar/vorhanden ist.\vspace{1cm}}
|
||||
|
||||
\section{Aufgabe 7 Programmschnittstelle - Punkte 10}
|
||||
\subsubsection*{a) Geben sie in ein bis zwei Saetzen an, warum das unten dargestellte Programm anfaellig fuer SQL-Injections ist.}
|
||||
[ Sinngemaess stand hier ein Programm bei dem der Nutzer einen String in einem nicht-escape'ten String kontrollieren konnte ]\\\\
|
||||
\subsection*{b) Wie kann man sich generell gegen SQL-Injections schuetzen?}
|
||||
\section{Aufgabe 7 Programmschnittstelle}
|
||||
\subsubsection*{a) Ist das folgende Programm anfaellig fuer SQL-Injections? Begruenden sie.}
|
||||
|
||||
\begin{lstlisting}[language=java]
|
||||
public static void main(String[] args) {
|
||||
Connection conn = null;
|
||||
Statement stmt = null;
|
||||
try{
|
||||
Class.forName("com.mysql.jdbc.Driver");
|
||||
conn = DriverManager.getConnection(DB_URL, USER, PASS);
|
||||
stmt = conn.createStatement();
|
||||
Scanner s = new Scanner();
|
||||
String tmp = s.readLine();
|
||||
String a = Integer(Integer.parseInt(tmp)).toString();
|
||||
sql = "INSERT INTO Trololololol VALUES(" + a + ")";
|
||||
stmt.executeUpdate(sql);
|
||||
}
|
||||
}
|
||||
\end{lstlisting}
|
||||
\solution{
|
||||
Eher nicht, weil jede versuchte SQL Injection am Integer.parseInt() zerschellt. In der Klausur wars eine, aber ich wollte mal trollen. Man koennte auch argumentieren, dass das hier einen DOS-Angriff ermoeglichen koennte.
|
||||
}
|
||||
\vspace{2.5cm}
|
||||
\textbf{b)} Wie kann man das obrige Program SICHER gegen SQL-Injections schuetzen?
|
||||
\solution{
|
||||
\begin{lstlisting}[language=java]
|
||||
preparedStmt.setInt(1, a)
|
||||
preparedStmt.execute();
|
||||
\end{lstlisting}
|
||||
Aber alleine die Aussage Prepared-Statements empfinde ich hier als wichtig.
|
||||
}
|
||||
\end{document}
|
||||
|
BIN
IDB/braindump_SS16/idb_done.png
Normal file
BIN
IDB/braindump_SS16/idb_done.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 186 KiB |
3
IDB/braindump_SS16/tree1-sol.ascii
Normal file
3
IDB/braindump_SS16/tree1-sol.ascii
Normal file
@ -0,0 +1,3 @@
|
||||
[8]
|
||||
/ \
|
||||
[1,U][8,A] [17,Z]
|
5
IDB/braindump_SS16/tree2.ascii
Normal file
5
IDB/braindump_SS16/tree2.ascii
Normal file
@ -0,0 +1,5 @@
|
||||
29
|
||||
/ \
|
||||
10 53,57
|
||||
/ \ / | \
|
||||
1,8 18 39 55 67
|
7
IDB/braindump_SS16/tree3.ascii
Normal file
7
IDB/braindump_SS16/tree3.ascii
Normal file
@ -0,0 +1,7 @@
|
||||
18
|
||||
/ \
|
||||
0,6,7,12 22,30
|
||||
\ / \
|
||||
20 21 58,67,89
|
||||
|
|
||||
22
|
Loading…
Reference in New Issue
Block a user