Answer to Question 1
a) Überführung des ER-Modells in ein relationales Modell:

Person(SteuerID, Name)
Verkäufer(SteuerID) mit Fremdschlüssel SteuerID auf Person.SteuerID
Käufer(SteuerID) mit Fremdschlüssel SteuerID auf Person.SteuerID
Interessent(UrkundenNr, SteuerID) mit Fremdschlüssel SteuerID auf Käufer.SteuerID
Immobilie(Expose, Adresse, SteuerID) mit Fremdschlüssel SteuerID auf Verkäufer.SteuerID
bietet_an(SteuerID, Expose) mit Fremdschlüssel SteuerID auf Verkäufer.SteuerID und Fremdschlüssel Expose auf Immobilie.Expose

b) Beispielhafte Instanziierung der Relationen, um das Problem zu illustrieren:

Person:
SteuerID, Name  
1, Max Mustermann
2, Erika Musterfrau

Verkäufer: 
SteuerID
1

Immobilie:
Expose, Adresse, SteuerID
1, Musterstraße 1, 2

bietet_an:
SteuerID, Expose
1, 1

Hier bietet der Verkäufer mit SteuerID 1 eine Immobilie an, die eigentlich der Person mit SteuerID 2 gehört.

c) Alternative ER-Modellierung der bietet_an-Beziehung:

Die bietet_an-Beziehung sollte als Attribut in die Immobilie-Entität integriert werden. Dann hat jede Immobilie direkt die SteuerID des Verkäufers als Attribut und es ist sichergestellt, dass eine Immobilie immer nur dem Verkäufer zugeordnet ist, der sie auch besitzt.

Die angepasste Immobilie-Entität sähe dann so aus:

Immobilie(Expose, Adresse, Verkäufer) mit Fremdschlüssel Verkäufer auf Verkäufer.SteuerID

Durch diese Modellierung ist die separate bietet_an Beziehung nicht mehr nötig. Die Zuordnung einer Immobilie zu ihrem Verkäufer ist direkt in der Immobilie-Entität abgebildet.





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




Answer to Question 2
a) Bei einer dreistelligen Beziehung mit Kardinalität 1:1:1 kann diese ohne Informationsverlust in drei zweistellige Beziehungen mit Kardinalität 1:1 zwischen Entity 1 und der Beziehung, 1:1 zwischen der Beziehung und Entity 3, sowie 1:1 zwischen Entity 3 und Entity 2 aufgeteilt werden.

b) Eine dreistellige Beziehung mit Kardinalität 1:1:n kann ebenfalls ohne Informationsverlust in drei zweistellige Beziehungen überführt werden. Dabei gilt: 1:1 zwischen Entity 1 und der Beziehung, 1:n zwischen der Beziehung und Entity 3, sowie 1:1 zwischen Entity 3 und Entity 2.

c) Bei einer Kardinalität von 1:n:n ist eine verlustfreie Überführung in zweistellige Beziehungen nicht möglich. Die n:n Beziehung zwischen der Beziehung und Entity 3 sowie zwischen Entity 3 und Entity 2 führt dazu, dass die Zuordnung der Entitäten zueinander nicht eindeutig abgebildet werden kann. Die dreistellige Beziehung ist hier notwendig, um die komplexen Zusammenhänge korrekt darzustellen.

d) Auch bei einer n:n:n Kardinalität ist eine Aufteilung in zweistellige Beziehungen nicht ohne Informationsverlust möglich. Die n:n Beziehungen zwischen allen beteiligten Entitäten erfordern die Beibehaltung der dreistelligen Beziehung, um die vielfältigen Verknüpfungen zwischen den Entitäten abbilden zu können. Eine Vereinfachung würde hier zu einem Verlust von Informationen über die genauen Zusammenhänge führen.





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




Answer to Question 3
a) Eine zweistellige Beziehung kann bei folgenden Kardinalitätsangaben in Standardkardinalität verschmolzen werden:
- (0,1) : (0,1)
- (0,1) : (1,1)
- (1,1) : (0,1)
- (1,1) : (1,1)

b) Zwei Gründe, warum Verschmelzung sinnvoll sein kann:
1. Reduktion der Anzahl der Relationen in der Datenbank, was zu einer kompakteren und übersichtlicheren Datenbankstruktur führt.
2. Vermeidung von Join-Operationen bei Abfragen, da die Daten bereits in einer Relation zusammengefasst sind, was die Performanz verbessern kann.

c) Zwei Nachteile von Verschmelzung:
1. Verlust der Normalisierung: Durch die Verschmelzung können redundante Daten entstehen, was zu Inkonsistenzen und Anomalien führen kann.
2. Einschränkung der Flexibilität: Wenn sich die Anforderungen an die Datenbank ändern und eine verschmolzene Relation wieder aufgeteilt werden muss, kann dies zu einem erhöhten Aufwand führen.





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




Answer to Question 4
Hier sind die Antworten auf die Fragen:

1. Um die Genres nach aufsteigendem Beliebtheitsgrad zu ordnen, müsste man die Gesamtzahl der verkauften Alben pro Genre aus der Tabelle "albums" aggregieren. Da die dafür nötigen Informationen in der gegebenen Aufgabenstellung fehlen, lässt sich diese Frage nicht beantworten.

2. Um alle Mitarbeiter zu nennen, die noch nie ein Album verkauft haben, müsste man die Tabellen "employees" und "sales" joinen und alle Mitarbeiter selektieren, die nicht in der Tabelle "sales" auftauchen. Auch hierfür fehlen die nötigen Informationen in der Aufgabenstellung, daher kann diese Frage ebenfalls nicht beantwortet werden.





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




Answer to Question 5
Hier sind die Antworten auf die Prüfungsfragen:

a) Um alle Mitarbeitenden auszugeben, die bisher noch nie ein Album verkauft haben, könnte man folgendes SQL-Statement verwenden:

SELECT e.EmployeeID, e.FirstName, e.LastName 
FROM Employee e
LEFT JOIN Sale s ON e.EmployeeID = s.EmployeeID
WHERE s.SaleID IS NULL

Dabei wird die Employee-Tabelle mit der Sale-Tabelle über die EmployeeID verknüpft. Durch den LEFT JOIN und die Bedingung s.SaleID IS NULL werden nur jene Mitarbeiter ausgegeben, für die kein zugehöriger Verkauf in der Sale-Tabelle existiert.

c) Um die IDs jener Kunden zu ermitteln, die an einem einzelnen Tag mehr als 3 Artikel vom selben Mitarbeiter gekauft haben:

SELECT c.CustomerID
FROM Customer c 
JOIN Sale s ON c.CustomerID = s.CustomerID
GROUP BY c.CustomerID, s.EmployeeID, DATE(s.SaleDate)
HAVING COUNT(*) > 3

Hier werden die Customer- und Sale-Tabellen verknüpft. Dann wird nach Kunde, Mitarbeiter und Verkaufsdatum gruppiert. Die HAVING-Klausel filtert jene Gruppen, die mehr als 3 Einträge haben, d.h. wo ein Kunde an einem Tag mehr als 3 Käufe beim selben Mitarbeiter getätigt hat.





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




Answer to Question 6
Hier sind die Antworten auf die Fragen:

a) Um die IDs der Kunden zu finden, die an einem einzigen Tag mehr als drei Produkte vom selben Mitarbeiter gekauft haben, würde ich folgende Schritte durchführen:

1. Tabelle mit Kundenkäufen nach Kunde, Mitarbeiter, Datum und Anzahl der gekauften Produkte gruppieren. 
2. Nur Einträge behalten, bei denen die Anzahl der gekauften Produkte an einem Datum vom selben Mitarbeiter größer als 3 ist.
3. Die Kunden-IDs aus dem Ergebnis ausgeben.

Das könnte in SQL etwa so aussehen:

SELECT CustomerID
FROM Sales
GROUP BY CustomerID, EmployeeID, Date
HAVING COUNT(*) > 3

b) Um die IDs und Vornamen der Mitarbeiter zu finden, die an mindestens 3 aufeinanderfolgenden Tagen Alben verkauft haben:

1. Tabelle mit Albumverkäufen nach Mitarbeiter und Datum gruppieren.
2. Für jeden Mitarbeiter prüfen, ob es 3 oder mehr aufeinanderfolgende Tage mit Verkäufen gibt. Dafür könnte man z.B. die Differenz zwischen aufeinanderfolgenden Datumseinträgen berechnen und schauen, ob es eine Sequenz von mindestens 3 Einträgen mit Differenz 1 gibt.
3. IDs und Vornamen der Mitarbeiter ausgeben, die die Bedingung erfüllen.

In SQL mit Hilfe von Window-Funktionen:

SELECT DISTINCT EmployeeID, FirstName  
FROM (
  SELECT e.EmployeeID, e.FirstName,
         SaleDate,
         DATEDIFF(day, LAG(SaleDate) OVER (PARTITION BY e.EmployeeID ORDER BY SaleDate), SaleDate) AS diff
  FROM EmployeeSales es
  JOIN Employees e ON es.EmployeeID = e.EmployeeID
  WHERE AlbumID IS NOT NULL
) t
WHERE diff = 1
GROUP BY EmployeeID, FirstName
HAVING COUNT(*) >= 3

Das ist natürlich nur eine mögliche Lösung, es gibt sicher noch andere Wege, die Aufgaben umzusetzen. Ich hoffe, die Erklärungen sind soweit verständlich. Bei Rückfragen lassen Sie es mich gerne wissen.





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




Answer to Question 7
Hier sind die Antworten auf die Fragen:

a) Um die IDs und Vornamen der Mitarbeiter zu finden, die an mindestens drei aufeinanderfolgenden Tagen Alben verkauft haben, würde ich folgendes tun:

1. Für jeden Mitarbeiter die Tage ermitteln, an denen er Alben verkauft hat. 
2. Diese Tage chronologisch sortieren.
3. Prüfen, ob es 3 oder mehr aufeinanderfolgende Tage gibt.
4. Wenn ja, die ID und den Vornamen des Mitarbeiters ausgeben.

Dazu würde ich die Tabellen Mitarbeiter und Verkäufe verknüpfen, nach Mitarbeiter und Verkaufsdatum gruppieren und dann die beschriebene Logik anwenden.

b) Um die IDs und Nachnamen der Kunden mit den insgesamt höchsten Ausgaben zu ermitteln:

1. Für jeden Kunden die Gesamtausgaben berechnen, indem man die Preise aller seiner gekauften Alben aufsummiert. Dazu Tabellen Kunden, Verkäufe und Alben verknüpfen.
2. Die Kunden nach ihren Gesamtausgaben absteigend sortieren.
3. Die ID(s) und Nachname(n) des Kunden/der Kunden mit dem höchsten Wert ausgeben.

Bei mehreren Kunden mit gleich hohen Höchstausgaben würden alle ausgegeben werden.





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




Answer to Question 8
Um die IDs und Nachnamen der Kunden zu ermitteln, die seit Eröffnung des Geschäfts dort am meisten Geld ausgegeben haben, würde ich wie folgt vorgehen:

1. Ich würde eine SQL-Abfrage auf die Tabellen "Kunden" und "Bestellungen" (oder ähnlich benannte Tabellen, die Kunden- und Bestelldaten enthalten) ausführen. 

2. In der Abfrage würde ich die Tabellen über die Kunden-ID verknüpfen, um Kundendaten mit ihren jeweiligen Bestellungen zu verbinden.

3. Dann würde ich die Bestellsummen pro Kunde aggregieren (z.B. mit SUM(Bestellsumme)), um die Gesamtausgaben jedes Kunden zu berechnen.

4. Diese Aggregation würde ich in absteigender Reihenfolge (ORDER BY SUM(Bestellsumme) DESC) sortieren, um die Kunden mit den höchsten Gesamtausgaben zuerst zu erhalten.

5. Schließlich würde ich die Kunden-ID und den Nachnamen für die Top-Kunden ausgeben (z.B. mit SELECT Kunden_ID, Nachname), eventuell begrenzt auf die obersten N Ergebnisse (mit LIMIT N).

Die SQL-Abfrage könnte also in etwa so aussehen:

SELECT k.Kunden_ID, k.Nachname
FROM Kunden k
JOIN Bestellungen b ON k.Kunden_ID = b.Kunden_ID  
GROUP BY k.Kunden_ID, k.Nachname
ORDER BY SUM(b.Bestellsumme) DESC
LIMIT 10;

Dies würde die IDs und Nachnamen der 10 umsatzstärksten Kunden seit Geschäftseröffnung zurückgeben.





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




Answer to Question 9
a) Die Anfrage kann ausgeführt werden. Sie liefert für jeden Mitarbeiter (identifiziert durch Nachname und Vorname) die Anzahl der ihm zugeordneten Alben, sortiert nach dieser Anzahl. Die Ausgabe enthält die Spalten last_name, first_name und album_id.

Die genaue Anzahl der Tupel im Ergebnis hängt von den konkreten Daten in den Tabellen E und I ab und kann ohne diese Informationen nicht exakt bestimmt werden.

b) Die Anfrage führt einen Natural Join zwischen den Tabellen I und C durch. Das Ergebnis enthält alle Spalten aus beiden Tabellen für die Tupel, bei denen die Werte in den gleichnamigen Spalten übereinstimmen.

Auch hier hängt die genaue Anzahl der Tupel im Ergebnis von den konkreten Daten in den Tabellen I und C ab und kann ohne diese Informationen nicht exakt bestimmt werden.

c) Die Anfrage kann nicht ausgeführt werden. Die GROUP BY-Klausel muss vor der WHERE-Klausel stehen. Die korrekte Reihenfolge lautet:

SELECT id 
FROM A
WHERE price > 0.99
GROUP BY id

Wenn man die Reihenfolge korrigiert, liefert die Anfrage die id-Werte aus der Tabelle A für die Tupel, deren price-Wert größer als 0.99 ist, gruppiert nach id. Die Anzahl der Ergebnistupel entspricht dann der Anzahl der verschiedenen id-Werte, die die Bedingung price > 0.99 erfüllen.





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




Answer to Question 10
a) Um die Menge aller Schlüsselkandidaten zu bestimmen, müssen wir die Attribute finden, die nicht funktional von anderen Attributen abhängen und von denen alle anderen Attribute funktional abhängen.

Aus den gegebenen funktionalen Abhängigkeiten lässt sich ableiten:
- A ist kein Schlüsselkandidat, da es von keinem anderen Attribut abhängt und auch kein anderes Attribut bestimmt.
- B ist kein Schlüsselkandidat, da C von B abhängt, aber B nicht von C.
- C ist kein Schlüsselkandidat, da B von C abhängt, aber C nicht von B.
- D ist kein Schlüsselkandidat, da es von B und C abhängt.
- E ist kein Schlüsselkandidat, da es von F abhängt.
- F ist kein Schlüsselkandidat, da es von keinem anderen Attribut abhängt und auch kein anderes Attribut vollständig bestimmt.
- G ist kein Schlüsselkandidat, da es von D und F abhängt.

Somit lässt sich schließen, dass die Kombination der Attribute ACF der einzige Schlüsselkandidat der Relation R ist, da von ACF alle anderen Attribute funktional abhängen.

b) Anwendung des Synthesealgorithmus zur Überführung von R in die 3. Normalform:

Schritt 1: Kanonische Überdeckung der funktionalen Abhängigkeiten F bestimmen
F' = {
  ACF → D,
  B → C, 
  B → D,
  C → B,
  C → D, 
  CD → B,
  CD → E,
  DF → G,
  F → E
}

Schritt 2: Für jede funktionale Abhängigkeit X → Y in F' eine Relation R_i(X,Y) bilden
R1(ACF,D)
R2(B,CD) 
R3(C,BD)
R4(CD,BE)
R5(DF,G)
R6(F,E)

Schritt 3: Vereinigung aller Relationen R_i, die einen Schlüssel von R enthalten
Da ACF der einzige Schlüsselkandidat ist, bleibt nur R1 übrig.

Schritt 4: Eliminierung überflüssiger Attribute in den Relationen
R1(ACF,D) bleibt unverändert, da alle Attribute benötigt werden.
R2(B,C) und R3(C,B) können zu R23(B,C) zusammengefasst werden.  
R4(CD,E) bleibt unverändert.
R5(DF,G) bleibt unverändert.
R6(F,E) bleibt unverändert.

Ergebnis:
R1(A,C,F,D)
R23(B,C)
R4(C,D,E) 
R5(D,F,G)
R6(F,E)

Die Relation R wurde somit verlustfrei und abhängigkeitsbewahrend in die 3. Normalform überführt.





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




Answer to Question 11
a) Berechnung der Projektionen und des Natural Joins:

$R_1 := \\proj_{[A,B,D]}(R)$:
A       B       D
α1      β1      δ1
α1      β3      δ3
α2      β2      δ2

$R_2 := \\proj_{[A,C]}(R)$:  
A       C
α1      γ1
α1      γ2
α1      γ3
α2      γ4
α2      γ5 
α2      γ6

$R_3 := R_1 \\join R_2$:
A       B       D       C
α1      β1      δ1      γ1
α1      β1      δ1      γ2
α1      β3      δ3      γ1
α1      β3      δ3      γ3
α2      β2      δ2      γ4
α2      β2      δ2      γ5
α2      β2      δ2      γ6

Beobachtung: $R_3$ enthält mehr Tupel als die ursprüngliche Relation $R$. Die Zerlegung ist nicht verbundtreu.

d) Eine verbundtreue Zerlegung von $R$ wäre:
$S(A,B,C)$ und $T(A,D)$

b) Überprüfung auf Verbund- und Abhängigkeitstreue:

Verbundtreue: 
- $Q_1 \\cap Q_2 = \\{H\\}$
- $H$ ist Schlüssel in $Q_2$
$\\rightarrow$ Zerlegung ist verbundtreu

Abhängigkeitstreue:
- $EI \\rightarrow H$ gilt in $Q_2$
- $H \\rightarrow GI$: $H \\rightarrow I$ gilt in $Q_1$, aber $H \\rightarrow G$ gilt weder in $Q_1$ noch $Q_2$
$\\rightarrow$ Zerlegung ist nicht abhängigkeitstreu

c) Siehe Antwort zu a)





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




Answer to Question 12
a) Ein äquivalenter Ausdruck zu $R \join S$ in relationaler Algebra ohne Verwendung des Join-Operators:

$\proj_{a_1,a_2,a_3,a_4}(\sigma_{R.a_1 = S.a_1 \land R.a_3 = S.a_3}(R \times S))$

Erklärung: Zuerst wird das kartesische Produkt $R \times S$ gebildet. Dann werden mit der Selektion $\sigma$ die Tupel ausgewählt, bei denen die Attribute $a_1$ und $a_3$ in beiden Relationen übereinstimmen. Schließlich werden mit der Projektion $\proj$ nur die gewünschten Attribute $a_1, a_2, a_3, a_4$ ausgewählt.

b) Ein äquivalenter Ausdruck zu $Q \cap S$ in relationaler Algebra ohne Verwendung des Durchschnitts-Operators:

$Q - (Q - S)$

Erklärung: Der Durchschnitt von $Q$ und $S$ entspricht allen Tupeln, die in $Q$ enthalten sind, aber nicht in der Differenz von $Q$ und $S$ ($Q - S$). Indem man diese Differenz wiederum von $Q$ abzieht, erhält man den gewünschten Durchschnitt.

c) Die Aussage ist richtig.

Begründung: Der Natural Join ist distributiv über die Vereinigung. Das bedeutet, dass das Ergebnis des Natural Joins von $R$ mit der Vereinigung von $S$ und $Q$ gleich der Vereinigung der Ergebnisse des Natural Joins von $R$ mit $S$ und $R$ mit $Q$ ist. Dies gilt, da der Natural Join die übereinstimmenden Attribute verbindet und die Vereinigung die Tupel beider Relationen kombiniert, unabhängig davon, in welcher Reihenfolge die Operationen ausgeführt werden.





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




Answer to Question 13
Entschuldigung, aber in der von Ihnen gestellten Frage fehlen die konkreten Beispiele, für die ich beurteilen soll, ob es sich um Transaktionen gemäß der Definition aus der Vorlesung handelt oder nicht.

Um Ihre Frage vollständig beantworten zu können, benötige ich die spezifischen Beispiele, die ich dann anhand der Transaktionsdefinition aus der Vorlesung einzeln analysieren und bewerten kann.

Bitte ergänzen Sie die fehlenden Beispiele in Ihrer JSON-formatierten Prüfungsfrage, damit ich Ihnen eine aussagekräftige Antwort geben kann. Vielen Dank!





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




Answer to Question 14
Um zu bestimmen, ob die Historien $H_1$, $H_2$ und $H_3$ konfliktäquivalent zu $H_0$ sind, müssen wir prüfen, ob sie die gleichen Konflikte aufweisen.

$H_0$: Keine Angabe gegeben, daher kann keine Aussage über Konfliktäquivalenz getroffen werden.

$H_1$: Es liegen keine Informationen über die Operationen und ihre Reihenfolge in $H_1$ vor. Ohne diese Angaben ist es nicht möglich festzustellen, ob $H_1$ die gleichen Konflikte wie $H_0$ enthält. Daher kann keine Aussage über Konfliktäquivalenz getroffen werden.

$H_2$: Auch für $H_2$ fehlen die notwendigen Informationen zu den enthaltenen Operationen und ihrer Anordnung. Somit ist eine Bestimmung der Konfliktäquivalenz zu $H_0$ nicht möglich.

$H_3$: Ebenso sind für $H_3$ keine Angaben zu den Operationen und ihrer Reihenfolge vorhanden. Folglich kann nicht beurteilt werden, ob $H_3$ konfliktäquivalent zu $H_0$ ist.

Zusammenfassend lässt sich sagen, dass aufgrund der fehlenden Informationen über die Operationen und ihre Reihenfolge in den Historien $H_0$, $H_1$, $H_2$ und $H_3$ keine Aussage darüber getroffen werden kann, ob $H_1$, $H_2$ und $H_3$ zu $H_0$ konfliktäquivalent sind. Um die Konfliktäquivalenz bestimmen zu können, müssten die genauen Abfolgen der Operationen in jeder Historie bekannt sein.





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




Answer to Question 15
Hier sind die Serialisierbarkeitsgraphen und Analysen für die vier gegebenen Schedules:

Schedule H1:
T1 → T2
Der Schedule ist serialisierbar, da es nur eine Kante von T1 nach T2 gibt. Die Transaktionen können in der Reihenfolge T1, T2 ausgeführt werden, ohne die Ergebnisse zu verändern.

Schedule H2:
T1 → T2 → T3
Auch dieser Schedule ist serialisierbar. Die Kanten bilden einen gerichteten azyklischen Graphen, was bedeutet, dass es eine Reihenfolge gibt, in der die Transaktionen seriell ausgeführt werden können (T1, T2, T3).

Schedule H3:
T1 → T2
↑     ↓
T3 ←←←←
Dieser Schedule ist nicht serialisierbar. Der Graph enthält einen Zyklus zwischen T1, T2 und T3. Es gibt keine Reihenfolge, in der diese Transaktionen seriell ausgeführt werden können, ohne die Ergebnisse zu verändern.

Schedule H4:
T1 → T2
↑     
T3     
Dieser Schedule ist serialisierbar. Obwohl T2 abbricht, gibt es keine Zyklen im Graphen. Die Transaktionen können in der Reihenfolge T3, T1 seriell ausgeführt werden. T2 hat keinen Einfluss auf die Serialisierbarkeit, da es keine Abhängigkeiten zu den anderen Transaktionen gibt und es abbricht, bevor es Änderungen festschreibt.





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




Answer to Question 16
Für das schwache 2PL würde ich den Verlauf der Sperrenbelegung wie folgt in das Koordinatensystem einzeichnen:

- Auf der x-Achse wird die Zeit dargestellt
- Auf der y-Achse werden die Sperren (Shared Locks und Exclusive Locks) eingezeichnet
- In der Wachstumsphase werden nach und nach die benötigten Sperren (Shared und Exclusive Locks) angefordert und gewährt. Dies wird durch eine ansteigende Treppe im Diagramm dargestellt.
- Am Ende der Wachstumsphase wird ein Punkt markiert, der den Übergang zur Schrumpfungsphase kennzeichnet.
- In der Schrumpfungsphase werden die Sperren nach Abschluss der Transaktionen wieder freigegeben. Dies wird durch eine absteigende Treppe bis auf 0 dargestellt.

Für das strikte 2PL sieht die Einzeichnung ähnlich aus, mit folgenden Unterschieden:
- Die Wachstumsphase verläuft identisch zum schwachen 2PL
- Der Übergang zur Schrumpfungsphase wird wieder markiert
- In der Schrumpfungsphase werden aber die Sperren bis zum erfolgreichen Commit der Transaktion gehalten
- Erst nach dem Commit werden alle Sperren auf einmal freigegeben, was durch eine senkrechte Linie auf 0 dargestellt wird

Zusammengefasst sind die Hauptunterschiede:
- Schwaches 2PL: Schrittweise Freigabe der Sperren in der Schrumpfungsphase
- Striktes 2PL: Sperren werden bis zum Commit gehalten und dann auf einmal freigegeben





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




Answer to Question 17
a) Hier sind die Schedules $S_1$ und $S_2$ ergänzt um die nötigen Aktionen zum Setzen und Freigeben von Sperren unter Anwendung des strikten 2PL:

$S_1 = wl_1[B] \\ \\ w_1[B] \\ \\ r_1[B] \\ \\ c_1 \\ \\ ul_1[B]$

$S_2 = rl_2[A] \\ \\ r_2[A] \\ \\ rl_5[A] \\ \\ r_5[A] \\ \\ rl_2[B] \\ \\ r_2[B] \\ \\ c_2 \\ \\ ul_2[A] \\ \\ ul_2[B] \\ \\ r_5[A] \\ \\ c_5 \\ \\ ul_5[A]$

b) Hier ist der Schedule $S_3$ ergänzt um die nötigen Aktionen zum Setzen und Freigeben von Sperren unter Anwendung des schwachen 2PL, so dass der Schedule ausführbar ist:

$S_3 = rl_3[A] \\ \\ r_3[A] \\ \\ wl_3[B] \\ \\ w_3[B] \\ \\ wl_4[A] \\ \\ w_4[A] \\ \\ w_3[B] \\ \\ c_3 \\ \\ ul_3[A] \\ \\ ul_3[B] \\ \\ r_4[A] \\ \\ c_4 \\ \\ ul_4[A]$

c) Nein, der Schedule $S_3$ ist unter Anwendung des strikten 2PL nicht ausführbar. Der Grund ist, dass die Transaktion $T_4$ die Sperre auf $A$ anfordert, nachdem $T_3$ bereits committed wurde. Beim strikten 2PL müssen aber alle Sperren bis zum Commit gehalten werden. Daher ist dieser Schedule nicht strikt 2PL-konform.





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




Answer to Question 18
Nein, Konfliktäquivalenz impliziert nicht die Zugehörigkeit zur gleichen Rücksetzbarkeitsklasse.

Begründung:
Zwei Transaktionen sind konfliktäquivalent, wenn sie die gleichen Konflikte erzeugen, d.h. wenn sie auf die gleichen Datenelemente in der gleichen Reihenfolge lesend und schreibend zugreifen. Dabei spielt es keine Rolle, ob die Transaktionen zurückgesetzt werden oder nicht.

Die Rücksetzbarkeit betrachtet hingegen, ob eine Transaktion zurückgesetzt werden kann, ohne dass andere Transaktionen, die von ihr gelesene Werte verwendet haben, ebenfalls zurückgesetzt werden müssen. Eine Transaktion gehört zur Rücksetzbarkeitsklasse RC (Read Committed), wenn sie nur committed Daten liest. Sie gehört zur Rücksetzbarkeitsklasse RU (Read Uncommitted), wenn sie auch uncommitted Daten lesen darf.

Zwei konfliktäquivalente Transaktionen können durchaus unterschiedlichen Rücksetzbarkeitsklassen angehören. Betrachten wir folgendes Beispiel:

T1: R(x), W(x), Commit
T2: R(x), W(x), Abort

T1 und T2 sind konfliktäquivalent, da sie die gleichen Konflikte auf x erzeugen. Aber T1 gehört zur Klasse RC, da sie nur committed Daten liest und schreibt, während T2 zur Klasse RU gehört, da sie auch uncommitted Daten von T1 liest, bevor sie selbst abbricht.

Somit ist Konfliktäquivalenz unabhängig von der Rücksetzbarkeit. Konfliktäquivalente Transaktionen müssen nicht derselben Rücksetzbarkeitsklasse angehören.





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




