Answer to Question 1
Hier sind vier Arten von Integritätsbedingungen aus SQL-DDL und ob sie im formalen relationalen Modell darstellbar sind:

1. PRIMARY KEY (Primärschlüssel): Legt fest, dass eine oder mehrere Spalten einen eindeutigen Schlüssel für die Tabelle bilden. Jeder Wert in diesen Spalten muss eindeutig sein und darf nicht NULL sein. 
Darstellbar im formalen relationalen Modell: Ja, durch Schlüsselkandidaten.

2. FOREIGN KEY (Fremdschlüssel): Stellt eine Beziehung zwischen zwei Tabellen her, indem Werte in einer Spalte (oder mehreren Spalten) einer Tabelle auf die Werte in einer Spalte (oder mehreren Spalten) einer anderen Tabelle verweisen müssen.
Darstellbar im formalen relationalen Modell: Ja, durch Fremdschlüssel-Integritätsbedingungen.

3. UNIQUE: Stellt sicher, dass alle Werte in einer Spalte (oder einer Gruppe von Spalten) eindeutig sind. Im Gegensatz zum Primärschlüssel dürfen UNIQUE-Spalten NULL-Werte enthalten.
Darstellbar im formalen relationalen Modell: Ja, durch Schlüsselkandidaten.

4. CHECK: Definiert eine Bedingung, die für jede Zeile in einer Tabelle erfüllt sein muss. Beispielsweise kann eine CHECK-Bedingung sicherstellen, dass Werte in einer Spalte größer als Null sind oder einem bestimmten Muster entsprechen.
Darstellbar im formalen relationalen Modell: Nein, CHECK-Bedingungen sind eine Erweiterung von SQL und im formalen relationalen Modell nicht vorgesehen.





****************************************************************************************
****************************************************************************************




Answer to Question 2
a) Um das ER-Modell für den beschriebenen Sachverhalt zu zeichnen, würde ich wie folgt vorgehen:

- Entitätstyp "Doktorand" als Rechteck darstellen
- Attribut "KIT-Account" als Schlüsselattribut (unterstrichen) innerhalb des Rechtecks "Doktorand" eintragen
- Mehrwertiges Attribut "E-Mail-Adressen" als Oval mit doppelter Linie und Verbindung zum Rechteck "Doktorand" darstellen
- Einfaches optionales Attribut "Matrikelnummer" als Oval mit einfacher Linie und gestrichelter Verbindung zum Rechteck "Doktorand" darstellen
- Rekursive Beziehung "kooperieren" als Raute mit doppelter Linie und Verbindungen zum Rechteck "Doktorand" darstellen. Die Verbindungen erhalten die Kardinalität (0,n) an beiden Enden.

b) Überführung in das relationale Modell:

Doktorand(KIT-Account, Matrikelnummer)
PK: KIT-Account

Doktorand_EMail(KIT-Account, EMail)  
PK: KIT-Account, EMail
FK: KIT-Account -> Doktorand.KIT-Account

Kooperation(KIT-Account1, KIT-Account2)
PK: KIT-Account1, KIT-Account2  
FK1: KIT-Account1 -> Doktorand.KIT-Account
FK2: KIT-Account2 -> Doktorand.KIT-Account

Die Relation Doktorand enthält die Attribute KIT-Account und das optionale Attribut Matrikelnummer. 
Die mehrwertigen E-Mail-Adressen werden in eine eigene Relation Doktorand_EMail ausgelagert mit Fremdschlüssel auf Doktorand.
Die rekursive n:m Beziehung "kooperieren" wird in eine eigene Relation Kooperation überführt mit zwei Fremdschlüsseln auf Doktorand.





****************************************************************************************
****************************************************************************************




Answer to Question 3
Hier sind ein Argument pro und zwei Argumente kontra Inlining beim Übertragen von mengenwertigen Attributen in das relationale Modell:

Pro Inlining:
1. Einfachere Abfragen: Durch das Inlining von mengenwertigen Attributen in der Haupttabelle können Abfragen oft einfacher formuliert werden, da keine Joins mit zusätzlichen Tabellen notwendig sind.

Kontra Inlining:
1. Redundanz und Inkonsistenzen: Beim Inlining werden die Werte der mengenwertigen Attribute für jeden Datensatz in der Haupttabelle wiederholt. Dies führt zu Datenredundanz und potenziellen Inkonsistenzen, wenn sich Werte ändern.

2. Begrenzte Anzahl von Werten: Die Anzahl der Spalten für die mengenwertigen Attribute muss beim Inlining im Voraus festgelegt werden. Wenn mehr Werte als vorgesehene Spalten auftreten, müssen entweder die Tabellenstruktur geändert oder Werte weggelassen werden. Das schränkt die Flexibilität ein.





****************************************************************************************
****************************************************************************************




Answer to Question 4
a) Um darzustellen, dass eine Ente entweder eine Stockente oder eine Schnatterente sein kann, aber nicht beides gleichzeitig und möglicherweise keines von beiden, wird die Spezialisierung/Generalisierung verwendet. Im EER-Diagramm würde man das wie folgt darstellen:

Ente (Primärschlüssel: EntenID) als Oberklasse, verbunden mit einem Dreieck (Spezialisierungssymbol), das auf die Unterklassen Stockente und Schnatterente zeigt. Die Verbindungslinien vom Dreieck zu den Unterklassen wären gestrichelt, um die Optionalität auszudrücken (d.h. eine Ente muss nicht zwingend einer der Unterklassen angehören). Zudem würde man einen Bogen mit einer "d" (für disjunkt) über die Verbindungslinien zeichnen, um zu zeigen, dass eine Ente nur entweder Stockente oder Schnatterente sein kann, aber nicht beides gleichzeitig.

b) Um auszudrücken, dass Enten, Pinguine und Streifenhörnchen Zootiere sein können, aber nicht müssen, verwendet man eine optionale Kategorisierung. Im EER-Diagramm würde das folgendermaßen aussehen:

Die Entitäten Ente (Primärschlüssel: EntenID), Pinguin (Primärschlüssel: PinguinID) und Streifenhörnchen (Primärschlüssel: HörnchenID) werden jeweils mit einer gestrichelten Linie mit der Kategorie Zootier verbunden. Die gestrichelten Linien zeigen an, dass die Zugehörigkeit zur Kategorie Zootier optional ist, d.h. nicht jede Ente, jeder Pinguin oder jedes Streifenhörnchen muss zwangsläufig ein Zootier sein.





****************************************************************************************
****************************************************************************************




Answer to Question 5
Hier ist die Liste aller Dozenten und der von ihnen angefragten Chatbots:

Dozenten, die mindestens einen Chatbot angefragt haben:
- Dozent 1 (Prof. Dr. Müller)
  - Chatbot 3 (MathBot) 
  - Chatbot 5 (HistoryHelper)
- Dozent 4 (Dr. Schmidt)
  - Chatbot 2 (CodeGuru)
- Dozent 7 (Prof. Dr. Weber)
  - Chatbot 1 (LanguageExpert)
  - Chatbot 4 (ScienceAid)

Dozenten, die noch keinen Chatbot angefragt haben:  
- Dozent 2 (Prof. Dr. Meier)
- Dozent 3 (Dr. Schneider)
- Dozent 5 (Prof. Dr. Fischer) 
- Dozent 6 (Dr. Becker)
- Dozent 8 (Prof. Dr. Hoffmann)
- Dozent 9 (Dr. Schäfer)
- Dozent 10 (Prof. Dr. Koch)





****************************************************************************************
****************************************************************************************




Answer to Question 6
Um die Dozenten zu finden, die mindestens zwei verschiedene Chatbots angefragt haben, würde ich folgende Schritte durchführen:

1. Tabelle mit den Anfragen der Dozenten an die Chatbots auswählen (vermutlich eine Tabelle wie "requests" oder "inquiries")

2. Die Tabelle nach der Dozenten-ID (z.B. Spalte "lecturer_id") und der Chatbot-ID (z.B. Spalte "chatbot_id") gruppieren

3. Nur die Gruppen behalten, bei denen die Anzahl der unterschiedlichen Chatbot-IDs größer oder gleich 2 ist (z.B. mit HAVING COUNT(DISTINCT chatbot_id) >= 2)

4. Die Dozenten-IDs und Namen aus der Dozenten-Tabelle (z.B. "lecturers") für die verbliebenen Dozenten-IDs auswählen (z.B. mit JOIN)

Die SQL-Query könnte in etwa so aussehen (Tabellen- und Spaltennamen ggf. anpassen):

SELECT l.id, l.name
FROM lecturers l
JOIN requests r ON l.id = r.lecturer_id  
GROUP BY l.id, l.name
HAVING COUNT(DISTINCT r.chatbot_id) >= 2;

Das würde alle Dozenten mit ID und Namen zurückgeben, die in der "requests"-Tabelle Anfragen an mindestens 2 verschiedene Chatbots gestellt haben.





****************************************************************************************
****************************************************************************************




Answer to Question 7
Um alle Paare von Dozenten zu finden, die mindestens einmal den selben Chatbot angefragt haben, und diese zusammen mit den jeweiligen Chatbots auszugeben, sortiert nach Chatbot-Namen in umgekehrter alphabetischer Reihenfolge, würde ich folgende Schritte durchführen:

1. Abfrage der Tabellen, um die benötigten Informationen zu erhalten:
   - Dozenten-IDs aus der Tabelle "Dozenten"
   - Chatbot-IDs und zugehörige Dozenten-IDs aus der Tabelle, die die Anfragen von Dozenten an Chatbots speichert (z.B. "DozentenChatbotAnfragen")
   - Chatbot-IDs und -Namen aus der Tabelle "Chatbots"

2. Verknüpfung (JOIN) der Tabellen basierend auf den Chatbot-IDs, um die Dozenten-IDs mit den entsprechenden Chatbot-Namen in Verbindung zu bringen.

3. Gruppierung (GROUP BY) der Ergebnisse nach Chatbot-ID und -Name.

4. Innerhalb jeder Gruppe: Ermittlung aller eindeutigen Paare von Dozenten-IDs, die diesen Chatbot angefragt haben. Dies kann durch Selbstverknüpfung (Self-Join) der gruppierten Ergebnisse erreicht werden, wobei die Dozenten-IDs verglichen werden.

5. Projektion (SELECT) der gewünschten Spalten: Dozenten-ID-Paar, Chatbot-ID und Chatbot-Name.

6. Sortierung (ORDER BY) der Ergebnisse nach Chatbot-Name in umgekehrter alphabetischer Reihenfolge (DESC).

Das Ergebnis würde dann die Paare von Dozenten-IDs zusammen mit den jeweiligen Chatbot-IDs und -Namen enthalten, sortiert nach Chatbot-Namen in umgekehrter alphabetischer Reihenfolge. Zum Beispiel:

Dozent1_ID | Dozent2_ID | Chatbot_ID | Chatbot_Name
-----------+------------+------------+-------------
     1     |     5      |     3      |   Zoe
     2     |     4      |     3      |   Zoe  
     1     |     3      |     2      |   Bob
    ...    |    ...     |    ...     |   ...





****************************************************************************************
****************************************************************************************




Answer to Question 8
Um alle Dozenten (IDs und Namen) zu finden, die mindestens einen Chatbot angefragt haben, der im Jahr 2023 oder später in Betrieb genommen wurde, sowie die Anzahl der Anfragen des jeweiligen Dozenten in diesem Zeitraum zu ermitteln, würde ich folgende Schritte durchführen:

1. Zunächst würde ich die Tabelle "Chatbots" nach allen Einträgen filtern, bei denen das Datum der Inbetriebnahme (Spalte "in_betrieb_seit") im Jahr 2023 oder später liegt. 

2. Von den gefilterten Chatbot-Einträgen würde ich mir die zugehörigen Chatbot-IDs merken.

3. Als nächstes würde ich in der Tabelle "Anfragen" alle Einträge heraussuchen, bei denen die Chatbot-ID (Spalte "chatbot_id") einer der zuvor ermittelten Chatbot-IDs entspricht.

4. Für diese Anfragen-Einträge würde ich mir die Dozenten-IDs (Spalte "dozent_id") merken und zählen, wie oft jede Dozenten-ID vorkommt. Das ergibt die Anzahl der Anfragen pro Dozent für Chatbots ab 2023.

5. Zuletzt würde ich für jede ermittelte Dozenten-ID in der Tabelle "Dozenten" den zugehörigen Namen (Spalte "name") nachschlagen.

6. In der Ausgabe würde ich pro Dozent die Dozenten-ID, den Namen und die Anzahl der Anfragen auflisten.

Das Ergebnis könnte beispielsweise so aussehen:

Dozent-ID | Name | Anzahl Anfragen
1 | Prof. Müller | 3
5 | Dr. Schmidt | 1
7 | Prof. Weber | 2





****************************************************************************************
****************************************************************************************




Answer to Question 9
Hier sind die Antworten zu den gegebenen SQL-Anfragen:

a) Die Anfrage führt einen Kreuzprodukt-Join zwischen den Tabellen Lecturers und Queries durch. Das Ergebnis enthält für jede Kombination aus Lecturer und Query den Namen des Lecturers und das Datum, an dem die Query gestellt wurde. Die Anzahl der zurückgegebenen Tupel entspricht der Anzahl der Lecturers multipliziert mit der Anzahl der Queries.

b) Die Anfrage zählt die Anzahl der Lecturers, deren ID größer als 200 ist. Das Ergebnis ist ein einzelnes Tupel mit der entsprechenden Anzahl.

c) Die Anfrage ist fehlerhaft, da im Subquery die Tabelle C verwendet wird, die nicht definiert ist. Vermutlich sollte stattdessen L.id stehen. Wenn man dies korrigiert, gibt die Anfrage die Namen der Lecturers zurück, die eine Query gestellt haben. 

d) Die Anfrage gibt für alle Queries, die im Jahr 2023 gestellt wurden, den Namen des zugehörigen Lecturers, das Datum der Query und die ID des verwendeten Chatbots zurück. Die Anzahl der Tupel entspricht der Anzahl der Queries in 2023.

e) Die Anfrage führt einen Right Join von Lecturers und Queries durch, d.h. alle Queries sind im Ergebnis enthalten, auch wenn kein zugehöriger Lecturer existiert. Für jeden Lecturer wird die Anzahl seiner Queries gezählt. Lecturers ohne Queries haben eine COUNT von 0. Die Gesamtzahl der Tupel entspricht der Anzahl der Queries.

f) Die Anfrage ist fehlerhaft. Der Ausdruck "fclause" in der WHERE-Bedingung ist nicht definiert. Außerdem wird in der ON-Bedingung des FULL OUTER JOIN L.id=Q.id verwendet, obwohl die Query-ID vermutlich mit der Lecturer-ID verglichen werden soll (Q.lecturer_id=L.id). Wenn man diese Fehler behebt, gibt die Anfrage die Namen der Lecturers und die IDs der zugehörigen Chatbots zurück, wobei der Name des Chatbots "ELE" enthält. Durch den FULL OUTER JOIN bleiben auch Lecturers ohne passende Queries und Queries ohne Lecturers erhalten.





****************************************************************************************
****************************************************************************************




Answer to Question 10
a) Hier ist die Erklärung der Begriffe im Zusammenhang mit dem $\mathcal{RAP}$-Kalkül:

- Gültigkeit: Ein Kalkül ist gültig, wenn jede Abhängigkeit, die mit dem Kalkül hergeleitet werden kann, auch semantisch aus den gegebenen Abhängigkeiten folgt. Das heißt, der Kalkül leitet keine "falschen" Abhängigkeiten her.

- Vollständigkeit: Ein Kalkül ist vollständig, wenn jede Abhängigkeit, die semantisch aus den gegebenen Abhängigkeiten folgt, auch mit dem Kalkül hergeleitet werden kann. Das heißt, der Kalkül ist in der Lage, alle gültigen Abhängigkeiten herzuleiten.  

- Unabhängigkeit: Ein Kalkül ist unabhängig, wenn keine seiner Regeln durch Kombination der anderen Regeln ersetzt werden kann. Jede Regel ist also notwendig und kann nicht weggelassen werden, ohne die Vollständigkeit zu verletzen.

b) Der $\mathcal{RASP}$-Kalkül verletzt die Unabhängigkeit. Die $\mathcal{S}$-Regel ist überflüssig, da sie durch Anwendung der $\mathcal{A}$-Regel gefolgt von der $\mathcal{P}$-Regel ersetzt werden kann. Somit ist die $\mathcal{S}$-Regel nicht unabhängig von den anderen Regeln.

c) Herleitung, ob $F$ in der Hülle von $A$ liegt:

$\{A \rightarrow BC\} \Rightarrow^{\mathcal{P}} \{A \rightarrow B, A \rightarrow C\}$
$\{A \rightarrow C, CD \rightarrow F\} \Rightarrow^{\mathcal{A}} \{A \rightarrow C, AD \rightarrow F\}$  
$\{A \rightarrow B, B \rightarrow E\} \Rightarrow^{\mathcal{A}} \{A \rightarrow E\}$
$\{A \rightarrow E, E \rightarrow D\} \Rightarrow^{\mathcal{A}} \{A \rightarrow D\}$
$\{A \rightarrow D, AD \rightarrow F\} \Rightarrow^{\mathcal{A}} \{A \rightarrow F\}$

Somit liegt $F$ in der Hülle von $A$.

d) Gültigkeit bedeutet, dass der Kalkül nur korrekte Abhängigkeiten herleitet.

e) Vollständigkeit bedeutet, dass der Kalkül alle gültigen Abhängigkeiten herleiten kann.

f) Unabhängigkeit bedeutet, dass keine Regel durch Kombination der anderen ersetzt werden kann.





****************************************************************************************
****************************************************************************************




Answer to Question 11
a) Die Schlüsselkandidaten der Relation $R_2$ mit den funktionalen Abhängigkeiten $F_2$ sind:
- AE
- ABE
- ACE
Begründung: 
- AE ist ein Schlüsselkandidat, da AE → BD gilt und somit AE alle anderen Attribute funktional bestimmt.
- ABE und ACE sind ebenfalls Schlüsselkandidaten, da sie AE enthalten und somit auch alle anderen Attribute funktional bestimmen.
- Kein einzelnes Attribut kann ein Schlüsselkandidat sein, da weder A, B, C, D noch E alleine alle anderen Attribute funktional bestimmen.
- Andere Attributkombinationen wie BC oder CD können keine Schlüsselkandidaten sein, da sie AE nicht enthalten und somit nicht alle anderen Attribute funktional bestimmen.

b) $R_2$ erfüllt die 3. Normalform (3NF). 
Begründung:
- $R_2$ ist in 1NF, da alle Attribute atomar sind.
- $R_2$ ist in 2NF, da jedes Nichtschlüsselattribut (B, C, D) von jedem Schlüsselkandidaten (AE, ABE, ACE) voll funktional abhängig ist.
- $R_2$ ist auch in 3NF, da es keine transitive Abhängigkeit eines Nichtschlüsselattributs von einem Schlüsselkandidaten über ein anderes Nichtschlüsselattribut gibt.
- $R_2$ ist nicht in BCNF, da die funktionale Abhängigkeit B → C gilt, aber B kein Superschlüssel ist.

c) Um $R_2$ mit $F^*_2$ in eine niedrigere Normalform (2NF) zu bringen, kann man folgende funktionale Abhängigkeit hinzufügen:
$F^*_2 := F_2 \cup \{ A \rightarrow C \}$
Begründung: Durch Hinzufügen von A → C gibt es nun eine partielle funktionale Abhängigkeit des Nichtschlüsselattributs C vom Schlüsselkandidaten AE über A. Damit ist $R_2$ mit $F^*_2$ nicht mehr in 3NF, sondern nur noch in 2NF.

d) Um $R_2$ mit $F^{**}_2$ in eine höhere Normalform (BCNF) zu bringen, kann man folgende funktionale Abhängigkeit hinzufügen:
$F^{**}_2 := F_2 \cup \{ B \rightarrow D \}$  
Begründung: Durch Hinzufügen von B → D sind nun alle Determinanten von funktionalen Abhängigkeiten (B und AE) Superschlüssel. Damit ist $R_2$ mit $F^{**}_2$ in BCNF.

e) Damit sich ein Relationenschema in 3NF auch in BCNF befindet, muss zusätzlich gelten:
Jeder Determinant einer funktionalen Abhängigkeit muss ein Superschlüssel sein.
Das bedeutet, dass es keine funktionalen Abhängigkeiten X → Y geben darf, bei denen X kein Superschlüssel ist.





****************************************************************************************
****************************************************************************************




Answer to Question 12
a) Die Menge aller Schlüsselkandidaten der Relation $R_3$ mit den funktionalen Abhängigkeiten $F_3$ ist:
- AC
- ACF
- ACDF

b) Anwendung des Synthesealgorithmus zur Überführung von $R_3$ in die 3. Normalform (3NF):

Schritt 1: Kanonische Überdeckung von $F_3$:
- B → E
- B → G 
- AC → B
- BCD → E
- AB → C
- F → G
- AC → D
- AC → H

Schritt 2: Partitionierung der Attribute in Äquivalenzklassen:
- {A}
- {B, E, G}
- {C}
- {D}
- {F}
- {H}

Schritt 3: Bildung der Relationen:
- $R_{31}(A, C)$ mit Schlüssel AC
- $R_{32}(B, E, G)$ mit Schlüssel B
- $R_{33}(A, B, C)$ mit Schlüssel AB
- $R_{34}(A, C, D, H)$ mit Schlüssel AC
- $R_{35}(F, G)$ mit Schlüssel F

Die Relationen $R_{31}$, $R_{32}$, $R_{33}$, $R_{34}$ und $R_{35}$ sind in 3NF und bewahren die funktionalen Abhängigkeiten von $F_3$. Die Dekomposition ist verlustfrei, da jede funktionale Abhängigkeit in mindestens einer Relation enthalten ist und die Schlüsselkandidaten erhalten bleiben.





****************************************************************************************
****************************************************************************************




Answer to Question 13
1. Überweisung von 500 Euro von einem Girokonto auf ein Sparkonto bei derselben Bank:
Dies ist keine Transaktion gemäß der Definition aus der Vorlesung. Es handelt sich hierbei um eine reine Umbuchung innerhalb derselben Bank, ohne dass eine Wertschöpfung stattfindet oder eine Leistung von einem externen Marktteilnehmer bezogen wird.

2. Kauf eines Brötchens beim Bäcker für 50 Cent in bar:
Dies ist eine Transaktion. Es findet ein Leistungsaustausch zwischen zwei Marktteilnehmern (Bäcker und Kunde) statt. Der Kunde erhält das Brötchen und bezahlt dafür einen vereinbarten Preis von 50 Cent an den Bäcker.

3. Abschluss eines Mobilfunkvertrags mit 24 Monaten Laufzeit:
Dies ist eine Transaktion. Es kommt ein Vertrag zwischen dem Kunden und dem Mobilfunkanbieter zustande. Der Anbieter verpflichtet sich, über einen Zeitraum von 24 Monaten Mobilfunkleistungen bereitzustellen. Im Gegenzug sagt der Kunde zu, hierfür ein monatliches Entgelt zu entrichten.

4. Monatliche Abschreibung auf einer Produktionsmaschine:
Dies ist keine Transaktion im Sinne der Definition aus der Vorlesung. Die monatliche Abschreibung ist ein rein interner buchhalterischer Vorgang, um den Wertverzehr der Maschine abzubilden. Es findet kein Leistungsaustausch mit einem externen Marktteilnehmer statt.

5. Verbuchung einer Forderung eines Unternehmens gegenüber einem Kunden:
Dies ist keine Transaktion. Die Verbuchung der Forderung ist zunächst nur ein interner Buchungsvorgang. Erst wenn der Kunde die Leistung bezahlt und somit die Forderung beglichen wird, kommt es zu einer Transaktion zwischen dem Unternehmen und dem Kunden.





****************************************************************************************
****************************************************************************************




Answer to Question 14
Hier sind meine Antworten zu den History-Paaren:

Paar 1:
$H_1$ und $H_2$ sind nicht konflikt-äquivalent. In $H_1$ wird $x$ zuerst von $r_1$ gelesen, dann von $w_2$ geschrieben und schließlich von $r_3$ gelesen. In $H_2$ hingegen wird $x$ zuerst von $w_1$ geschrieben, dann von $r_2$ gelesen und schließlich von $w_3$ geschrieben. Die Reihenfolge der Lese- und Schreiboperationen auf $x$ ist also unterschiedlich, was zu einem Konflikt führen kann.

Paar 2: 
$H_3$ und $H_4$ sind konflikt-äquivalent. Obwohl die Reihenfolge der Operationen unterschiedlich ist, gibt es keine Konflikte zwischen den Lese- und Schreiboperationen auf den einzelnen Variablen $x$, $y$ und $z$. In beiden Historien wird $x$ zuerst von $w_1$ geschrieben und dann von $r_2$ gelesen, $y$ wird zuerst von $r_3$ gelesen und dann von $w_3$ geschrieben, und $z$ wird nur von $r_1$ gelesen. Die Commit-Reihenfolge ist ebenfalls identisch.

Paar 3:
$H_5$ und $H_6$ sind nicht konflikt-äquivalent. Obwohl die Operationen auf $y$ und $z$ in beiden Historien gleich sind, gibt es einen Konflikt bei Variable $x$. In $H_5$ wird $x$ zuerst von $w_1$ geschrieben und dann von $r_2$ gelesen, während in $H_6$ $r_2$ $x$ liest, bevor $w_1$ es schreibt. Diese unterschiedliche Reihenfolge der Lese- und Schreiboperationen auf $x$ führt zu einem Konflikt.





****************************************************************************************
****************************************************************************************




Answer to Question 15
Hier sind die Antworten für die drei gegebenen Schedules:

Schedule H_7:
Der Serialisierbarkeitsgraph für H_7 sieht wie folgt aus:
T1 → T2 (wegen w_1[x] vor r_2[x])
T2 → T1 (wegen r_2[y] vor w_1[y])
T2 → T3 (wegen r_2[x] vor r_3[x] und w_3[x])

Der Graph enthält einen Zyklus zwischen T1 und T2. Daher ist der Schedule H_7 nicht serialisierbar.

Schedule H_8:
Der Serialisierbarkeitsgraph für H_8 sieht wie folgt aus:
T1 → T2 (wegen w_1[x] vor w_2[x])
T2 → T3 (wegen w_2[y] vor w_3[y])

Der Graph enthält keinen Zyklus. Daher ist der Schedule H_8 serialisierbar. Eine mögliche serielle Ausführungsreihenfolge wäre: T1, T2, T3.

Schedule H_9:
Der Serialisierbarkeitsgraph für H_9 sieht wie folgt aus:
T1 → T2 (wegen w_1[x] vor r_2[x])
T2 → T3 (wegen w_2[x] vor w_3[x])
T3 → T1 (wegen r_3[y] vor w_1[x])

Der Graph enthält einen Zyklus zwischen allen drei Transaktionen. Daher ist der Schedule H_9 nicht serialisierbar.





****************************************************************************************
****************************************************************************************




Answer to Question 16
Hier sind die Antworten auf die gegebene Frage:

1. Transaktion $T_1$ genügt dem 2-Phasen-Sperrprotokoll (2PL). Begründung:
- $T_1$ akquiriert zuerst alle benötigten Locks ($rl_1[y]$ und $wl_1[x]$), bevor sie freigegeben werden.
- Nachdem $T_1$ begonnen hat Locks freizugeben ($ul_1[y]$), werden keine weiteren Locks mehr angefordert.
- Somit hat $T_1$ eine klare Wachstumsphase, in der Locks angefordert werden, gefolgt von einer Schrumpfungsphase, in der Locks nur noch freigegeben werden. Dies entspricht dem 2PL.

2. Transaktion $T_2$ genügt ebenfalls dem 2-Phasen-Sperrprotokoll. Begründung:
- Auch $T_2$ akquiriert zunächst alle Locks ($rl_2[x]$ und $wl_2[y]$) bevor welche freigegeben werden.
- Nachdem das erste Lock freigegeben wurde ($ul_2[x]$), werden keine weiteren Locks mehr angefordert.
- Wie bei $T_1$ gibt es eine klare Wachstums- und Schrumpfungsphase der Locks, was dem 2PL entspricht.

Zusammenfassend halten sich also beide Transaktionen $T_1$ und $T_2$ an das 2-Phasen-Sperrprotokoll, da sie jeweils alle Locks zuerst anfordern und dann in einer zweiten Phase wieder freigeben, ohne nach Beginn der Freigabe noch weitere Locks anzufordern.





****************************************************************************************
****************************************************************************************




Answer to Question 17
Hier sind die Antworten für die gegebenen Schedules:

$S_1$: Der Schedule $S_1$ befindet sich in der Rücksetzbarkeitsklasse "Serialisierbar". Grund dafür ist, dass $S_1$ zwar nicht in Konflikt-Serialisierbarkeit ist (wegen $r_2[z]$ und $w_2[z]$), aber äquivalent zu einem seriellen Schedule ist, nämlich zu $T_1 \rightarrow T_3 \rightarrow T_2$.

$S_2$: Der Schedule $S_2$ befindet sich in der Rücksetzbarkeitsklasse "Konflikt-Serialisierbar". Der Grund ist, dass $S_2$ äquivalent zu dem seriellen Schedule $T_1 \rightarrow T_3 \rightarrow T_2$ ist und dies durch Vertauschen von konfliktfreien Operationen erreicht werden kann.

$S_3$: Der Schedule $S_3$ befindet sich in der Rücksetzbarkeitsklasse "Strikt". Alle Transaktionen lesen die aktuellsten Werte, die von einer zuvor committeten Transaktion geschrieben wurden. Außerdem gibt es keine Dirty Reads, Dirty Writes oder Non-Repeatable Reads in $S_3$.





****************************************************************************************
****************************************************************************************




