\documentclass{bschlangaul-aufgabe}

\begin{document}
\bAufgabenMetadaten{
  Titel = {Aufgabe 1},
  Thematik = {Vermischte Fragen},
  Referenz = 66116-2021-F.T1-TA2-A1,
  RelativerPfad = Examen/66116/2021/03/Thema-1/Teilaufgabe-2/Aufgabe-1.tex,
  ZitatSchluessel = examen:66116:2021:03,
  BearbeitungsStand = mit Lösung,
  Korrektheit = unbekannt,
  Ueberprueft = {unbekannt},
  Stichwoerter = {Datenbank},
  EinzelpruefungsNr = 66116,
  Jahr = 2021,
  Monat = 03,
  ThemaNr = 1,
  TeilaufgabeNr = 2,
  AufgabeNr = 1,
}

Beantworten Sie die folgenden Fragen und begründen oder erläutern Sie
Ihre Antwort.
\index{Datenbank}
\footcite{examen:66116:2021:03}

\begin{enumerate}

%%
% a)
%%

\item Erläutern Sie die Begriffe Kardinalität und Partizipität. Welche
Arten von Partizipität gibt es in der ER-Modellierung? Nennen und
erklären Sie diese kurz.

\begin{bAntwort}
\begin{description}
\item[Kardinalitäten]

Für die noch genauere Darstellung der Beziehungen im ER-Modell verwendet
man Kardinalitäten (auch Grad der Beziehungen genannt). Diese geben an
wie viele Entitätsinstanzen mit wie vielen Entitätsinstanzen einer
anderen Entitätsinstanz in Beziehung stehen.
\bFussnoteUrl{https://usehardware.de/datenbanksysteme-iv-entity-relationship-modell-er-modell-datenbankdarstellungen-i/}

\item[Partizipation]

Die Partizipation eines Beziehungstyps (in einem
Entity-Relationship-Modell) bestimmt, ob alle Entities eines beteiligten
Entitätstyps an einer bestimmten Beziehung teilnehmen müssen.
\bFussnoteUrl{https://lehrbuch-wirtschaftsinformatik.org/glossar/kapitel03/Partizipation}

\begin{description}
\item[totale Partizipation:]

Wenn eine Beziehung Entität A und Entität B in Beziehung setzt, dann
muss ein Eintrag in Entität A existieren, damit ein Eintrag in Entität B
existiert und umgekehrt. Beide Entitäten müssen also an der Relation
teilnehmen. Eine Entitätsinstanz aus A kann also nicht ohne eine
in-Beziehung-stehende Entitätsinstanz aus B existieren und umgekehrt.

\item[partielle Partizipation:]

Wenn eine Beziehung Entität A mit Entität B in Beziehung setzt, dann
muss kein Eintrag in Entität A existieren, damit ein Eintrag in  Entität
B existieren kann und umgekehrt. Die beiden Entitäten müssen also nicht
an der Relation teilnehmen (enthalten sein).
\bFussnoteUrl{https://usehardware.de/datenbanksysteme-iv-entity-relationship-modell-er-modell-datenbankdarstellungen-i/}
\end{description}
\end{description}

Die Kardinalität definiert, wie viele Entities eines Typs mit wie vielen
Entities eines anderen Typs in Beziehung stehen können (siehe Schneider
et al., S. 446)\footcite[446]{schneider}

Partizipität – ein anderer Begriff dafür ist Totalität – beschreibt den
Grad der Teilnahmeverpflichtung zweier Entitäten an einer Beziehung. Sie
kann partiell, total oder einseitig total sein.

a. Totale P.: Jede Entity A und Entity B besteht nur dann, wenn sie an
dieser Beziehung teilnehmen.

b. Einseitige totale P.: Eine Entity A besteht nur dann, wenn sie an der
Beziehung zu Entity B teilnimmt. Entitäten von B dagegen können, müssen
aber nicht teilnehmen.

c. Partielle P.: Die Existenz der Entitäten ist unabhängig von der
Teilnahme an dieser Beziehung. Die Teilnahme ist nicht verpflichtend.

\end{bAntwort}

%%
% b)
%%

\item Mit welchen beiden Befehlen kann eine Transaktion beendet werden?
Nennen Sie diese und erklären Sie den Unterschied.

\begin{bAntwort}
Für den Abschluss einer Transaktion gibt es 2 Möglichkeiten:

\begin{itemize}
\item Den erfolgreichen Abschluss mit \texttt{commit}.
\item Den erfolglosen Abschluss mit \texttt{abort}
\end{itemize}\footcite[Kapitel 9.3, Seite 302-302]{kemper}
\end{bAntwort}

%%
% c)
%%

\item Erläutern Sie den Unterschied zwischen einer kurzen und einer
langen Sperre.

\begin{bAntwort}
\begin{description}
\item[lange Sperren:]

LOCKs werden erst nach dem commit zurückgegeben ($\rightarrow$ striktes 2PL)

\item[kurze Sperren:]

LOCKs werden direkt nach dem schreiben/lesen zurückzugeben
\end{description}
\bFussnoteUrl{https://www.dbs.ifi.lmu.de/Lehre/DBSII/SS2015/vorlesung/DBS2-03-Synchronisation.pdf}
\end{bAntwort}

%%
% d)
%%

\item Stellen Sie außerdem die Kompatibilitätsmatrix zur Umsetzung des
ACID-Prinzips mit den richtigen Werten dar. S stehe dabei für eine Lese-
und X für eine Schreibsperre.

\begin{bAntwort}
Kompatibilitätsmatrix zur Umsetzung des ACID-Prinzips (Atomicity,
Consistency, Isolation, Durability)

\begin{tabular}{llll}
                  & NL (no lock) & S (Lesesperre) & X (Schreibsperre) \\
S (Lesesperre)    & ja           & ja             & nein \\
X (Schreibsperre) & ja           & nein           & nein \\
\end{tabular}
\footcite[SX-Kompatibilitätsmatrix]{wiki:sperrverfahren}
\end{bAntwort}

%%
% e)
%%

\item Nennen und erklären Sie kurz die Armstrong-Axiome. Sind diese
vollständig und korrekt?

\begin{bAntwort}

\begin{description}
\item[Reflexivität:]
%
Eine Menge von Attributen bestimmt eindeutig die Werte einer Teilmenge
dieser Attribute (triviale Abhängigkeit), das heißt,
$\beta \subseteq \alpha \Rightarrow \alpha \rightarrow \beta$ .

\item[Verstärkung:]
%
Gilt
$\alpha \rightarrow \beta$, so gilt auch
$\alpha \gamma \rightarrow \beta \gamma$
für jede Menge von Attributen
$\gamma$ der
Relation.

\item[Transitivität:]
%
Gilt
$\alpha \rightarrow \beta$
und
$\beta \rightarrow \gamma$,
so gilt auch
$\alpha \rightarrow \gamma$.
\end{description}

Die Armstrong-Axiome sind korrekt und vollständig: Diese
Regeln sind gültig (korrekt) und alle anderen gültigen Regeln können von
diesen Regeln abgeleitet werden (vollständig).
\bFussnoteUrl{https://dbresearch.uni-salzburg.at/teaching/2019ss/db1/db1_06-handout-1x1.pdf}
\end{bAntwort}

%%
% f)
%%

\item Was versteht man unter einem (Daten-)Katalog (Data Dictionary)
und was enthält dieser (es genügt eine Auswahl zu nennen)?

\begin{bAntwort}
Bei einer relationalen Datenbank ist ein Datenkatalog eine Menge von
Tabellen und Ansichten, die bei Abfragen  nur
gelesen werden. Das Data-Dictionary ist wie eine Datenbank
aufgebaut, enthält aber nicht Anwendungsdaten, sondern Metadaten, das
heißt Daten, welche die Struktur der Anwendungsdaten beschreiben (und
nicht den Inhalt selbst).

Zu einem Data-Dictionary zur physischen Datenmodellierung gehören genaue Angaben zu:

\begin{itemize}
\item Tabellen und Datenfeldern
\item Primär- und Fremdschlüsselbeziehungen
\item Integritätsbedingungen, \zB Prüfinformationen
\end{itemize}
\bFussnoteUrl{https://de.wikipedia.org/wiki/Data-Dictionary}
\end{bAntwort}

%%
% g)
%%

\item Erklären Sie das konservative und das strikte
Zwei-Phasen-Sperrprotokoll.

\begin{bAntwort}
\begin{description}

\item[Konservatives 2-Phasen-Sperrprotokoll]

Das konservative 2-Phasen-Sperrprotokoll (Preclaiming), bei welchem zu
Beginn der Transaktion alle benötigten Sperren auf einmal gesetzt
werden. Dies verhindert in jedem Fall Deadlocks, führt aber auch zu
einem hohen Verlust an Parallelität, da eine Transaktion ihre erste
Operation erst dann ausführen kann, wenn sie alle Sperren erhalten hat.

\item[Striktes 2-Phasen-Sperrprotokoll]

Das strikte 2-Phasen-Sperrprotokoll, bei welchem alle gesetzten
Write-Locks erst am Ende der Transaktion (nach der letzten Operation)
freigegeben werden. Dieses Vorgehen verhindert den Schneeballeffekt,
also das kaskadierende Zurücksetzen von sich gegenseitig beeinflussenden
Transaktionen. Der Nachteil ist, dass Sperren häufig viel länger
gehalten werden als nötig und sich somit die Wartezeit von blockierten
Transaktionen verlängert. Die Read-Locks werden entsprechend dem
Standard-2PL-Verfahren entfernt.
\footcite{wiki:sperrverfahren}
\end{description}
\end{bAntwort}

%%
% h)
%%

\item Erklären Sie die Begriffe „Steal/NoSteal“ und „Force/NoForce“ im
Kontext der Systempufferverwaltung eines DBS.

\begin{bAntwort}
\begin{description}
\item[No-Steal]

Schmutzige Seiten dürfen nicht aus dem Puffer entfernt und in die
Datenbank übertragen werden, solange die Transaktion noch aktiv ist. Die
Datenbank enthält keine Änderungen nicht-erfolgreicher Transaktionen.
Eine UNDO-Recovery ist nicht erforderlich. langen
Änderungs-Transaktionen können zu Problemen führen, da große Teile des
Puffers blockiert werden

\item[Steal]

Schmutzige Seiten dürfen jederzeit ersetzt und in die Datenbank
eingebracht werden. Die Datenbank kann unbestätigte Änderungen
enthalten. Eine UNDO-Recovery ist erforderlich. Es handelt sich um eine
effektivere Puffernutzung bei langen Transaktionen mit vielen
Änderungen.\footcite[Kapitel 10.2.1 Ersetzung von
Puffer-Seiten Seite 311-312]{kemper}

\item [Force]

Alle geänderten Seiten werden spätestens bei EOT (vor COMMIT) in die
Datenbank geschrieben. Bei einem Systemfehler ist keine REDO-Recovery
erforderlich. Die Force-Strategie benötigt einen hohen I/O-Aufwand, da
Änderungen jeder Transaktion einzeln geschrieben werden. Die Vielzahl an
Schreibvorgängen führt zu schlechteren Antwortzeiten, länger gehaltenen
Sperren und damit zu mehr Sperrkonflikten. Große Datenbank-Puffer werden
schlecht genutzt.\footcite[Kapitel
10.2.2 Einbringen von Änderungen einer Transaktion Seite
312-313]{kemper}

\item[No-Force]

Änderungen können auch erst nach dem COMMIT in die Datenbank geschrieben
werden. Die Änderungen durch mehrere Transaktionen werden „gesammelt“.
Beim COMMIT werden lediglich REDO-Informationen in die Log-Datei
geschrieben. Bei einem Systemfehler ist eine REDO-Recovery erforderlich.
Die Änderungen auf einer Seite über mehrere Transaktionen hinweg können
gesammelt werden.\footcite[Seite 25]{db:fs:5}
\end{description}
\end{bAntwort}

\end{enumerate}
\end{document}
