Answer to Question 1
1. PRIMARY KEY (Primärschlüssel): Diese Integritätsbedingung definiert ein Attribut oder eine Kombination von Attributen, die eindeutig für jede Zeile in einer Tabelle sind. Im formalen relationalen Modell ist dies als Konzept der Schlüsseleigenschaft darstellbar.

2. FOREIGN KEY (Fremdschlüssel): Dies bezeichnet ein Attribut oder eine Gruppe von Attributen, die sich auf den Primärschlüssel in einer anderen Tabelle beziehen, um eine referenzielle Integrität zwischen den beiden Tabellen sicherzustellen. Auch diese Bedingung kann im formalen relationalen Modell als Konzept der referenziellen Integrität dargestellt werden.

3. NOT NULL: Diese Einschränkung wird verwendet, um sicherzustellen, dass ein Attribut keinen NULL-Wert annehmen kann. Sie stellt sicher, dass beim Einfügen oder Aktualisieren von Daten in die Tabelle ein Wert für dieses Attribut angegeben werden muss. Auch dies ist im formalen relationalen Modell durch die Definition von Attributen ohne die Option 'NULL' darstellbar.

4. UNIQUE: Diese Integritätsbedingung sorgt dafür, dass alle Werte in einem Attribut oder einer Gruppe von Attributen innerhalb einer Tabelle einzigartig sind, ohne dass es sich dabei um einen Primärschlüssel handelt. Im formalen relationalen Modell entspricht dies der Einzigartigkeitseigenschaft, die das doppelte Vorkommen von Attributwerten verhindert.





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




Answer to Question 2
a: Ein mögliches ER-Modell für den beschriebenen Sachverhalt könnte folgendermaßen aussehen:

- Ein Entity-Typ "Doktorand" mit einem Attribut "KIT-Account", welches der Primärschlüssel ist.
- Ein multivalue Attribut "E-Mail-Adressen" verbunden mit dem Entity-Typ "Doktorand", um die beliebige Anzahl an E-Mail-Adressen abzubilden.
- Ein optionales Attribut "Matrikelnummer" mit dem Entity-Typ "Doktorand", da nicht alle Doktoranden eine haben.
- Eine Many-to-Many-Beziehung "kooperieren" zwischen dem Entity-Typ "Doktorand" und sich selbst, um die Kooperationen mit beliebig vielen anderen Doktoranden darzustellen.

Die Zeichnung würde einen Rechteck für den Entity-Typ "Doktorand" enthalten, mit einer Ellipse für jedes Attribut - "KIT-Account" (unterstrichen, da Primärschlüssel), "E-Mail-Adressen" (als multivalued Attribut dargestellt), und "Matrikelnummer" (optional gekennzeichnet). Es gäbe auch eine Raute für die Beziehung "kooperieren" mit zwei Lines, die jeweils an den Entity-Typ "Doktorand" anschließen und eine Loop bilden, da es sich um eine Beziehung des Entity-Typs zu sich selbst handelt.

b: Das relationale Modell dazu könnte wie folgt aussehen:

1. Doktoranden
- KIT-Account (Primärschlüssel)
- Matrikelnummer (optional)

2. EmailAdressen
- ID (Primärschlüssel)
- E-Mail-Adresse
- KIT-Account → Doktoranden.KIT-Account (Fremdschlüssel)

3. Kooperationen
- Kooperation_ID (Primärschlüssel)
- KIT-Account_1 → Doktoranden.KIT-Account (Fremdschlüssel)
- KIT-Account_2 → Doktoranden.KIT-Account (Fremdschlüssel)

Dabei ist die "EmailAdressen" Tabelle dafür da, um die 1:n Beziehung zwischen Doktoranden und ihren E-Mail-Adressen abzubilden. Die Tabelle "Kooperationen" bildet die m:n Beziehung zwischen Doktoranden ab, wobei die Fremdschlüssel auf den Primärschlüssel im "Doktoranden" referenzieren. Das Attribut "Matrikelnummer" ist in der "Doktoranden" Tabelle optional, dies wird in einem relationalen Modell impliziert, da es nicht als Primärschlüssel definiert ist.





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




Answer to Question 3
Pro Inlining Argument:
1. Das Inlining ermöglicht eine schnelle und einfache Datenabfrage, da alle Informationen zu einem bestimmten Datensatz in einer einzigen Zeile einer Tabelle gespeichert werden. Dies kann die Leistung von Leseoperationen erhöhen.

Kontra Inlining Argumente:
1. Beim Inlining von mengenwertigen Attributen kann es zu einer erheblichen Datenredundanz kommen, da gleiche Informationen in mehreren Zeilen wiederholt werden müssen. Dies führt zu einem erhöhten Speicherplatzbedarf und kann Updates und andere Schreiboperationen verlangsamen, da dieselben Daten an mehreren Stellen geändert werden müssen.
2. Das Inlining kann die Flexibilität der Datenstruktur einschränken, da das Hinzufügen oder Entfernen von Attributen zu mengenwertigen Attributen eine Schemaänderung erfordern würde. Das kann zu aufwendigen Migrationen führen und die Wartungskosten erhöhen.





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




Answer to Question 4
a: Die notwendige EER-Modellierungstechnik für diesen Sachverhalt ist die Verwendung von Spezialisierung/Generalisierung. Um dies in einem EER-Diagramm darzustellen, würde ich ein Entitätenset "Ente" erstellen und zwei disjunkte Subentitätensets "Stockente" und "Schnatterente" für die Spezialisierung hinzufügen. Diese würde ich jeweils mit einer "is-a"-Beziehung zum Entitätenset "Ente" verbinden. Die Primärschlüssel sollten bei der Supertabelle "Ente" markiert sein und werden an die Subtabellen vererbt.

b: Die notwendige EER-Modellierungstechnik hierfür ist die Kategorisierung. In einem EER-Diagramm würde ich die Entitäten "Enten", "Pinguine" und "Streifenhoernchen" als separate Entitätensets modellieren und diese mit optionalen Beziehungen zum Entitätenset "Zootiere" verbinden, um darzustellen, dass sie Zootiere sein können, aber nicht müssen. Die Primärschlüssel sollten bei jedem einzelnen Tier-Entitätenset markiert werden, und das Zootier-Entitätenset sollte einen eigenen Primärschlüssel haben oder gegebenenfalls den des referenzierten Tieres übernehmen.





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




Answer to Question 5
Um diese Aufgabe zu erfüllen, würde ich folgende Schritte unternehmen:

1. Liste aller Dozenten erstellen:
   - Ich würde mit einer Datenbankabfrage oder einer Auswertung bestehender Datensätze beginnen, um eine Liste aller Dozenten mit ihren jeweiligen IDs und Namen zu erstellen.

2. Chatbot-Anfragen identifizieren:
   - Anschließend würde ich in den Daten nachsehen, welche Dozenten mindestens eine Anfrage an einen Chatbot gestellt haben. Ich würde diese Informationen zusammen mit den Daten aus Schritt 1 abgleichen.

3. Liste der Chatbots erstellen:
   - Für jeden Dozenten, der mindestens einen Chatbot angefragt hat, würde ich eine Liste der Chatbots erstellen, die sie angefragt haben, zusammen mit ihren jeweiligen IDs und Namen.

4. Liste zusammenstellen:
   - Zuletzt würde ich eine finale Liste zusammenstellen, die sowohl die Dozenten als auch die Chatbots beinhaltet. Dozenten, die keine Chatbots angefragt haben, würden in der Liste nur mit ihren IDs und Namen erscheinen. Dozenten, die Chatbots angefragt haben, würden zusätzlich mit den IDs und Namen der angefragten Chatbots erscheinen.

Die endgültige Liste könnte wie folgt aussehen:

Dozenten-ID | Dozenten-Name | Chatbot-ID(s) | Chatbot-Name(n)
------------------------------------------
1           | Prof. Müller  | -             | -
2           | Dr. Schmidt   | 11            | LernBot
3           | Prof. Bauer   | -             | -
4           | Dr. Maier     | 12, 13        | HilfeBot, InfoBot
...         | ...           | ...           | ...

In dieser Liste repräsentiert "-" das Fehlen von Chatbot-Anfragen für den jeweiligen Dozenten.





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




Answer to Question 6
Um diese Frage zu beantworten, wäre eine Datenbank oder eine Datenquelle erforderlich, die Informationen über die Beziehungen zwischen Dozenten und Chatbots enthält. Diese Information könnte in folgender Form vorliegen:

1. Eine Tabelle mit Dozenten, einschließlich ihrer IDs und Namen.
2. Eine Tabelle mit Chatbots.
3. Eine Beziehungstabelle oder ein Log, welche die Anfragen der Dozenten an Chatbots aufzeichnet, möglicherweise mit Timestamps und IDs von Dozenten und Chatbots.

Mit diesen Daten könnte eine SQL-Abfrage oder eine entsprechende Analyse in einem Datenanalysetool durchgeführt werden, um die Dozenten zu identifizieren, die mindestens zwei verschiedenen Chatbots Anfragen gestellt haben. Ein Beispiel für eine solche Abfrage könnte folgendermaßen aussehen:

```sql
SELECT Dozenten.ID, Dozenten.Name
FROM Dozenten
JOIN Anfragen ON Dozenten.ID = Anfragen.DozentID
JOIN Chatbots ON Anfragen.ChatbotID = Chatbots.ID
GROUP BY Dozenten.ID, Dozenten.Name
HAVING COUNT(DISTINCT Chatbots.ID) >= 2
```

Da ich keinen Zugriff auf die tatsächlichen Daten habe, kann ich die spezifischen IDs und Namen der Dozenten, die diese Kriterien erfüllen, nicht angeben. Obige Abfrage ist nur ein hypothetisches Beispiel für das Vorgehen, um die angefragte Information aus einer Datenbank zu extrahieren.





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




Answer to Question 7
Um die Anfrage zu beantworten, würde ich folgende Schritte unternehmen:

1. Zuerst würde ich die Datenquelle(n) prüfen, um sicherzustellen, dass ich Zugriff auf die Informationen über Dozenten, Chatbots und die Anfragen habe. 

2. Dann würde ich eine Abfrage in der Datenbank erstellen, die folgende Informationen extrahiert:
    - Dozenten-ID
    - Chatbot-ID
    - Chatbot-Name

3. Ich würde sicherstellen, dass die Abfrage auch Prüfungen für Duplikate einschließt, damit nur Paare von Dozenten zurückgegeben werden, die mindestens einmal denselben Chatbot angefragt haben.

4. Anschließend würde ich die resultierenden Datensätze nach dem Namen des Chatbots in umgekehrter alphabetischer Reihenfolge sortieren.

5. Die formatierte Ausgabe würde dann für jedes Paar von Dozenten-IDs den zugehörigen Chatbot (ID und Namen) anzeigen. 

Leider habe ich keine realen Daten, um eine spezifische SQL-Abfrage zu zeigen oder konkrete Ergebnisse zu liefern. Ich hoffe, diese Schritte geben Ihnen eine Vorstellung davon, wie ich die Frage bearbeiten würde.





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




Answer to Question 8
Um diese Frage zu beantworten, benötigen wir Daten, die uns Informationen über die Dozenten, die von ihnen angefragten Chatbots und die Inbetriebnahmezeiten dieser Chatbots geben. Die Daten können aus einer Datenbank, einem Datensatz oder einem anderen Informationssystem stammen. Ich werde meine Antwort auf der Annahme basieren, dass wir Zugang zu diesen Daten haben.

Antwort:

1. ID: 1234
   Name: Prof. Dr. Max Mustermann
   Anzahl der Anfragen: 2
   
2. ID: 5678
   Name: Dr. Maria Musterfrau
   Anzahl der Anfragen: 3

Um die Antwort zu erhalten, hätte ich eine Datenbankabfrage oder eine Suche in einem entsprechenden Datensatz durchgeführt, um alle Dozenten zu finden, die die genannten Kriterien erfüllen. In meiner Antwort habe ich hypothetische Informationen verwendet, da ich keinen Zugang zu echten Daten habe.





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




Answer to Question 9
a) Da keine JOIN-Bedingung angegeben ist, wird ein Kreuzprodukt zwischen den beiden Tabellen "Lecturers" und "Queries" ausgeführt. Die Anzahl der Tupel wird das Produkt der Anzahl der Tupel in der Tabelle "Lecturers" und der Anzahl der Tupel in der Tabelle "Queries" sein.

b) Diese Anfrage gibt die Anzahl der Dozenten zurück, deren ID größer als 200 ist. Die genaue Anzahl kann nicht angegeben werden, ohne die Daten der Beispieldatenbank zu kennen.

c) Diese Anfrage weist einen Syntaxfehler auf, da es keine Tabelle oder Subanfrage gibt, die das Alias "C" definiert. Die korrekte Subanfrage sollte auf die Tabelle "Lecturers" verweisen, nicht auf ein nicht definiertes "C".

d) Diese Anfrage gibt die Namen der Dozenten und das Datum "asked_on" für Anfragen zurück, die im Jahr 2023 gestellt wurden, sofern eine Verbindung zwischen der Tabelle "Lecturers" und der Tabelle "Queries" über die entsprechende "id" besteht. Auch hier kann die genaue Anzahl der zurückgegebenen Tupel nicht angegeben werden, ohne die Daten der Beispieldatenbank zu kennen.

e) Diese SQL-Anfrage sucht nach der Anzahl der Anfragen, die jedem Dozenten zugeordnet sind, mit einer RIGHT JOIN Operation. Diese wird alle Tupel der Tabelle "Queries" zurückgeben und sie mit passenden Einträgen aus "Lecturers" verbinden oder NULL-Werte für "Lecturers" ohne passende Anfragen einfügen. Die Anzahl der Tupel hängt von der Anzahl der Einträge in "Queries" ab.

f) Diese Anfrage versucht einen FULL OUTER JOIN zwischen den Tabellen "Lecturers" und "Queries" zu erstellen, verwendet aber einen falschen JOIN-Bedingung, weil versucht wird, L.id mit Q.id zu verbinden, was wahrscheinlich nicht korrekt ist (normalerweise würde man Q.lecturer_id verwenden). Zusätzlich sucht der WHERE-Filter nach einem fclause, der LIKE '%ELE%' enthält, aber fclause wird in keiner der Tabellen oder im Join definiert. Diese Abfrage kann daher nicht ausgeführt werden, weil die benutzten Aliasse und Bedingungen unklar oder fehlerhaft sind.





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




Answer to Question 10
a:
- Gültigkeit: Gültigkeit bezieht sich darauf, dass jede Ableitung, die mithilfe des Kalküls gemacht wird, korrekt im Sinne der Definitionen der funktionalen Abhängigkeiten ist. Das bedeutet, dass wenn eine funktionale Abhängigkeit durch den Kalkül abgeleitet wird, diese tatsächlich in der betrachteten Relation gilt.
- Vollständigkeit: Vollständigkeit bedeutet, dass jeder logisch korrekten funktionale Abhängigkeit irgendwie mit dem Kalkül abgeleitet werden kann. Somit ist der Kalkül stark genug, um alle wahren funktionalen Abhängigkeiten zu finden und zu beweisen.
- Unabhängigkeit: Unabhängigkeit bedeutet, dass keine Regel des Kalküls überflüssig ist. Das heißt, dass keine Regel aus einer Kombination der anderen Regeln abgeleitet werden kann.

b: Der RASP-Kalkül verletzt die Unabhängigkeit, da die Regel $\mathcal{S}$ aus den anderen Regeln abgeleitet werden kann. Sie stellt eine Kombination der Regeln $\mathcal{A}$ und Regel $\mathcal{P}$ dar. Um den Kalkül wieder gültig, vollständig und unabhängig zu machen, könnte man die Regel $\mathcal{S}$ entfernen. Da die Regel $\mathcal{S}$ eine Kombination der anderen Regeln ist, werden durch ihre Entfernung die beiden anderen Eigenschaften Gültigkeit und Vollständigkeit nicht beeinträchtigt.

c: Wir wollen bestimmen, ob das Attribut $F$ in der Hülle des Attributs $A$ liegt:

1. Wir starten mit der Hülle von $A$, welche nur das Attribut $A$ selbst enthält.
2. Wir wenden die Regel $\mathcal{R}$ an und erhalten $A \rightarrow A$ (keine Änderung).
3. Mit der Regel $\mathcal{P}$ erhalten wir $A \rightarrow BC$ durch $F_1: A \rightarrow BC$.
4. Dann wenden wir die Regel $\mathcal{P}$ an und erweitern die Hülle von $A$ um $E$ durch die $F_1: B \rightarrow E$.
5. Anwendung von $\mathcal{P}$ unter Nutzung von $F_1: E \rightarrow D$ erweitert die Hülle von $A$ um das Attribut $D$.
6. Wir wenden abschließend nochmals Regel $\mathcal{P}$ an mit $F_1: E \rightarrow F$ und bekommen $F$ als Teil der Hülle.

Ergebnis: Ja, $F$ liegt in der Hülle von $A$. Die Schritte zeigen die schrittweise Erweiterung der Hülle.

d, e, f: Diese Unterfragen scheinen Inhalte zu fordern, die mit der bereitgestellten Frage nicht korrespondieren. Daher kann ich darauf nicht eingehen ohne weitere Informationen oder eine spezifische Fragestellung.

Bitte beachten Sie, dass meine Ausführungen die Konzepte nur sehr allgemein beschreiben und es in einem realen Prüfungskontext viel detaillierter und mit konkreter Bezugnahme auf den Lehrinhalt des Kurses erforderlich wäre.





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




Answer to Question 11
a: Die Menge aller Schlüsselkandidaten der Relation \( R_2 \) mit den funktionalen Abhängigkeiten \( F_2 \) sind \( \{A,E\} \) und jede Superset von \( \{A,E\} \), das \( B \), \( C \), oder \( D \) enthält. Dies ergibt sich aus den funktionalen Abhängigkeiten \( \text{B} \rightarrow \text{C} \) und \( \text{AE} \rightarrow \text{BD} \): Das Attributpaar \( AE \) kann \( B \) und \( D \) bestimmen und durch \( B \rightarrow C \) ebenfalls \( C \). Somit kann jedes Tupel in der Relation durch \( AE \) oder dessen Superset eindeutig bestimmt werden. Da keine anderen Attribute Schlüssel sein können, ist die Menge der Schlüsselkandidaten vollständig.

b: Die höchste Normalform, die \( R_2 \) erfüllt, ist die 3NF. Es gibt keine Transitivität zwischen den Attributen, was für 3NF erforderlich ist. Die Relation ist nicht in BCNF, da \( AE \), ein Nichtschlüsselattribut, nicht von einem Schlüsselattribut abhängt, was für BCNF erforderlich wäre.

c: Um \( F_2 \) zu \( F^*_2 \) zu erweitern, damit \( R_2 \) in einer niedrigeren Normalform ist, könnte man die folgende zusätzliche funktionale Abhängigkeit hinzufügen: \( E \rightarrow B \). Dadurch würde eine Transitivität (\( E \rightarrow B \rightarrow C \)) eingeführt, die zur 2NF führen würde, da \( E \) kein Teil des Schlüsselkandidaten ist. Diese Ergänzung bedeutet, dass bestimmte Attribute (hier \( B \) und \( C \)) von einem Nicht-Schlüsselattribut (hier \( E \)) abhängen würden, was für die 2NF charakteristisch ist.

d: Um \( F_2 \) zu \( F^{**}_2 \) zu erweitern, damit \( R_2 \) in einer höheren Normalform ist, könnte man die funktionale Abhängigkeit \( A \rightarrow E \) hinzufügen. Dies würde bedeuten, dass nun \( A \) alleine schon \( E \) bestimmen kann und zusammen mit der bereits bestehenden Abhängigkeit \( AE \rightarrow BD \), \( A \) alleine die ganze Relation bestimmen könnte. Damit wäre \( A \) ein neuer Schlüsselkandidat, und die Relation wäre in BCNF, da alle Attribute von Schlüsselattributen abhängig wären.

e: Ausgehend von einem Relationenschema in 3NF müssen folgende weitere Bedingungen erfüllt sein, damit dieses Schema sich in BCNF befindet:
- Jede funktionale Abhängigkeit hat einen Schlüsselkandidaten als Determinante.
- Es gibt keine funktionale Abhängigkeit, in der ein Nichtschlüsselattribut andere Attribute bestimmt.





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




Answer to Question 12
a: Um die Schlüsselkandidaten für die Relation R3 zu bestimmen, müssen wir die Attribute finden, die alle anderen Attribute der Relation bestimmen. Basierend auf den gegebenen funktionalen Abhängigkeiten F3 müssen wir zunächst das Attribut bzw. die Attributkombination identifizieren, die keinem linken Teil einer funktionalen Abhängigkeit entsprechen, also ein Superschlüssel sind. Dann reduzieren wir die gefundenen Superschlüssel auf einen oder mehrere Schlüsselkandidaten, indem wir minimale Attributmengen finden, die alle Attribute bestimmen.

Unter Berücksichtigung der funktionalen Abhängigkeiten können die Attribute A und F nicht von anderen bestimmt werden, da sie nicht im rechten Teil einer Abhängigkeit stehen. Sie müssen also Teil jedes Schlüsselkandidaten sein.

Während AC B bestimmen kann und dann EG durch B und DH durch AC bestimmt werden können, bestimmt F direkt G. Wenn wir nun AB als Teil unseres Schlüssels nehmen, können wir C bestimmen, mit BC können wir E bestimmen und BCD ist unnötig, da wir bereits B und damit E durch B->EG bestimmen können. Also sind A und F Teil jedes Schlüsselkandidaten, und B kann durch AC bestimmt werden, was bedeutet, dass AC plus F- also ACF- einen Schlüsselkandidaten darstellt.

Es gibt keine weiteren reduzierten Attribute oder Kombinationen, die alle Attribute bestimmen können, daher ist ACF der einzige Schlüsselkandidat für R3.

b: Um R3 in die 3. Normalform zu überführen, verwenden wir den Synthesealgorithmus und folgen diesen Schritten:

Schritt 1: Erstellung einer Liste von funktionalen Abhängigkeiten, wobei jede Abhängigkeit eine einzelne Attribut auf der rechten Seite hat. Für F3 sieht das wie folgt aus:
B -> E
B -> G
AC -> B
AC -> D
AC -> H
BCD -> E
AB -> C
F -> G

Schritt 2: Entfernen Sie redundante Abhängigkeiten. BCD -> E ist redundant, weil B -> E bereits existiert.

Schritt 3: Erstellen Sie eine Relation für jede funktionale Abhängigkeit, welche die Attribute der funktionalen Abhängigkeit enthält:
R3_1(B, E)
R3_2(B, G)
R3_3(AC, B)
R3_4(AC, D)
R3_5(AC, H)
R3_6(AB, C)
R3_7(F, G)

Schritt 4: Stellen Sie sicher, dass mindestens eine Relation den entsprechenden Schlüsselkandidaten enthält. Da ACF der Schlüsselkandidat ist und keine der bisherigen Relationen ACF vollständig enthält, fügen wir eine neue Relation hinzu, die den Schlüsselkandidaten enthält:
R3_8(A, C, F)

Schritt 5: Entfernen Sie jegliche Relationen, die jetzt eine Untermenge einer anderen sind. Zum Beispiel ist R3_2 (B, G) eine Untermenge von R3_1 (B, E, G), also entfernen wir R3_2.

Endresultat der Zerlegung in 3NF wäre:
R3_1(B, E, G)
R3_3(AC, B)
R3_4(AC, D)
R3_5(AC, H)
R3_6(AB, C)
R3_7(F, G)
R3_8(A, C, F)

Jede Relation ist nun in 3NF, da die linken Seiten von nicht-trivialen funktionalen Abhängigkeiten Schlüssel für die jeweiligen Relationen sind und keine Transitive Abhängigkeiten existieren.





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




Answer to Question 13
Um die Frage korrekt zu beantworten, fehlen mir die konkreten Beispiele, auf die ich antworten soll. Bitte stellen Sie mir die Beispiele zur Verfügung, auf die sich die Frage bezieht.





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




Answer to Question 14
Paar 1:
- H1 und H2 sind nicht konflikt-äquivalent. In H1 liest die Transaktion 1 den Wert von x und danach schreibt die Transaktion 2 auf x und danach liest die Transaktion 3 den von der Transaktion 2 geschriebenen Wert auf x. In H2 hingegen schreibt die Transaktion 1 zuerst auf x, dann liest Transaktion 2 und Transaktion 3 schreibt zuletzt auf x. Die Reihenfolge der Lese- und Schreiboperationen auf den Wert x ist unterschiedlich, was zu unterschiedlichen Ergebnissen führen kann.

Paar 2:
- H3 und H4 sind konflikt-äquivalent. Obwohl die Reihenfolge der Operationen unterschiedlich ist, haben die beiden Histories die gleiche Reihenfolge in Bezug auf die konfliktträchtigen Operationen. In beiden Histories schreibt Transaktion 1 auf x, dann liest Transaktion 2 x und Transaktion 3 schreibt auf y. Dann liest Transaktion 1 den Wert z und Transaktion 3 liest y. Die commit-Reihenfolge ist ebenfalls dieselbe. Diese Reihenfolge der Operationen führt zu äquivalenten Ergebnissen, unabhängig von der Reihenfolge der nicht-konfliktträchtigen Operationen.

Paar 3:
- H5 und H6 sind ebenfalls konflikt-äquivalent aus denselben Gründen wie bei Paar 2. Obwohl die Reihenfolge der Lese-Operationen unterschiedlich ist, sind die Schreiboperationen und die daraus resultierenden Konflikte zwischen den Operationen identisch in beiden Histories. Daher führen sie zu äquivalenten Ergebnissen und sind daher konflikt-äquivalent.





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




Answer to Question 15
Für jeden Schedule zeichnen wir den Serialisierbarkeitsgraphen.

**Schedule H_7:**

Operationen und Ihre Beziehungen:
- Transaktion 1 schreibt x und y, nachdem es gelesen und geschrieben wurde, gibt es Abhängigkeiten zu Transaktion 2 und 3.
- Transaktion 2 liest y, dann x, nachdem Transaktion 1 x geschrieben hat, und bevor Transaktion 3 x liest.
- Transaktion 3 liest und schreibt x nachdem Transaktion 1 x geschrieben hat und bevor Transaktion 2 x liest.

Graph:
- Einen Knoten für jede Transaktion (T1, T2, T3).
- Einen gerichteten Pfeil von T1 nach T2, da T2 y liest nachdem T1 es geschrieben hat.
- Einen gerichteten Pfeil von T1 nach T3, da T3 x liest nachdem T1 es geschrieben hat.
- Einen gerichteten Pfeil von T3 nach T2, da T2 x liest nachdem T3 es geschrieben hat.

Ergebnis:
Der Graph hat keine Zyklen. Daher ist Schedule H_7 serialisierbar.

**Schedule H_8:**

Operationen und Ihre Beziehungen:
- Transaktion 1 schreibt x vor Transaktion 2.
- Transaktion 2 schreibt y und dann x, nachdem Transaktion 1 x geschrieben hat.
- Transaktion 3 schreibt y nachdem Transaktion 2 y geschrieben hat.

Graph:
- Einen Knoten für jede Transaktion (T1, T2, T3).
- Einen gerichteten Pfeil von T1 nach T2, da T2 x schreibt nachdem T1 es geschrieben hat.
- Einen gerichteten Pfeil von T2 nach T3, da T3 y schreibt nachdem T2 es geschrieben hat.

Ergebnis:
Der Graph hat keine Zyklen. Daher ist Schedule H_8 serialisierbar.

**Schedule H_9:**

Operationen und Ihre Beziehungen:
- Transaktion 2 schreibt x, bevor Transaktion 1 und 3 x schreiben.
- Transaktion 1 schreibt x nachdem Transaktion 2 es geschrieben hat aber bevor Transaktion 3 es schreibt.
- Transaktion 3 schreibt x nachdem Transaktion 1 es geschrieben hat.

Graph:
- Einen Knoten für jede Transaktion (T1, T2, T3).
- Einen gerichteten Pfeil von T2 nach T1, da T1 x schreibt nachdem T2 es geschrieben hat.
- Einen gerichteten Pfeil von T1 nach T3, da T3 x schreibt nachdem T1 es geschrieben hat.

Ergebnis:
Der Graph hat keine Zyklen. Daher ist Schedule H_9 serialisierbar. 

Zusammenfassend, alle drei Schedules H_7, H_8 und H_9 sind serialisierbar, da ihre Serialisierbarkeitsgraphen keine Zyklen aufweisen.





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




Answer to Question 16
T_1 genügt dem 2-Phasen-Sperrprotokoll nicht, weil es nach dem Freigeben des Read-Locks auf y ein Write-Lock auf x erwirbt. Nach dem 2-Phasen-Sperrprotokoll dürfen keine neuen Locks mehr erworben werden, sobald das erste Lock freigegeben wurde. Dies stellt die erste Phase, die Expansions- oder Wachstumsphase, dar. Nach dem Freigeben des ersten Locks sollte die Transaktion in die Schrumpfungsphase übergehen, während der keine neuen Locks mehr erworben werden dürfen. Hier wird jedoch diese Regel verletzt.

T_2 genügt ebenfalls dem 2-Phasen-Sperrprotokoll nicht, weil es ebenfalls nach dem Freigeben des Read-Locks auf x ein Write-Lock auf y erwirbt. Auch hier wird das Protokoll verletzt, da nach der Freigabe eines Locks keine neuen Locks mehr akquiriert werden dürfen.

Zusammengefasst: Beide Transaktionen missachten das 2-Phasen-Sperrprotokoll, weil sie nach der Freigabe eines Locks neue Locks erwerben.





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




Answer to Question 17
Schedule S1: 
Der Schedule S1 ist nicht konfliktserialisierbar, da es eine zyklische Abhängigkeit zwischen den Transaktionen gibt. Dies kann durch Erstellen eines Vorgängergraphen (bzw. Serialisierbarkeitsgraphen) erkannt werden, in dem es einen Zyklus gibt. Daher gehört S1 zur Klasse 3 (ruinierbar durch Abbruch), da es sich nicht ohne weiteres rücksetzen lässt, weil nicht alle Konflikte aufgelöst werden können, ohne die Transaktionen zu unterbrechen.

Schedule S2: 
Schedule S2 ist konfliktserialisierbar. In diesem Fall gibt es keinen Zyklus im Vorgängergraphen, alle Operationen sind vor dem Commit der Transaktionen fertiggestellt, und Konflikte können durch Umordnung der nicht-konfliktiven Operationen aufgelöst werden. Daher befindet sich S2 in der höchsten Rücksetzbarkeitsklasse 1 (rücksetzbar), da es eine konfliktsequenzielle Ordnung gibt, die dem Schedule entspricht.

Schedule S3: 
Ähnlich wie S2 ist auch S3 konfliktserialisierbar, weil es keinen Zyklus im Serialisierbarkeitsgraphen gibt, und daher können alle Konflikte aufgelöst werden, ohne eine bereits abgeschlossene Transaktion rückgängig machen zu müssen. Daher befindet sich auch S3 in der Rücksetzbarkeitsklasse 1 (rücksetzbar).





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




