Datenbanken in Rechnernetzen und Transaktionssysteme - Exam

Aufgabe 1)

Stelle Dir vor, Du arbeitest als Datenbankadministrator und Deine Aufgabe besteht darin, eine Datenbank für eine Online-Bibliothek zu entwickeln. Die Bibliothek verwaltet Bücher, Autoren, und Mitglieder, die Bücher ausleihen. Jedes Buch hat mehrere Attribute wie Titel, Genre, Veröffentlichungsjahr und eine einzigartige ISBN-Nummer (Schlüsselattribut). Autoren haben Attribute wie Name, Geburtsdatum und Nationalität. Mitglieder haben Attribute wie Name, Mitgliedsnummer (Schlüsselattribut) und Anmeldedatum. Eine Beziehung besteht zwischen Büchern und Autoren, wobei ein Autor mehrere Bücher schreiben kann und ein Buch von mehreren Autoren geschrieben werden kann. Eine weitere Beziehung besteht zwischen Mitgliedern und Büchern, wobei ein Mitglied mehrere Bücher ausleihen kann und ein Buch von mehreren Mitgliedern ausgeliehen werden kann.

a)

1) Entwerfe ein ER-Diagramm für die beschriebene Online-Bibliothek. Verwende dabei die korrekten Notationen für Entitäten, Attribute, Beziehungen und Schlüsselattribute. Erkläre kurz die Beziehungen zwischen den Entitäten und die Art der Beziehungen (z.B. 1:n, n:m).

Lösung:

Ein ER-Diagramm (Entity-Relationship-Diagramm) stellt alle Entitäten, ihre Attribute und die Beziehungen zwischen ihnen grafisch dar. Bevor wir mit der Visualisierung beginnen, listen wir die wichtigen Entitäten, Attribute und Beziehungen auf, die in der Online-Bibliothek existieren.

• Entitäten und Attribute:
  • Buch (Book):
    • ISBN (Schlüsselattribut)
    • Titel
    • Genre
    • Veröffentlichungsjahr
  • Autor (Author):
    • Name
    • Geburtsdatum
    • Nationalität
  • Mitglied (Member):
    • Mitgliedsnummer (Schlüsselattribut)
    • Name
    • Anmeldedatum
• Beziehungen:
  • Schreibt - Beziehung zwischen Autor und Buch (n:m): Ein Autor kann mehrere Bücher schreiben, und ein Buch kann von mehreren Autoren geschrieben werden.
  • Leiht aus - Beziehung zwischen Mitglied und Buch (n:m): Ein Mitglied kann mehrere Bücher ausleihen, und ein Buch kann von mehreren Mitgliedern ausgeliehen werden.

ER-Diagramm in Textform:

• Buch (Book):
  • ISBN (PK)
  • Titel
  • Genre
  • Veröffentlichungsjahr
  • - Schreibt:
    • Autor
  • - Leiht aus:
    • Mitglied
• Autor (Author):
  • Name (PK)
  • Geburtsdatum
  • Nationalität
  • - Schreibt:
    • Buch
• Mitglied (Member):
  • Mitgliedsnummer (PK)
  • Name
  • Anmeldedatum
  • - Leiht aus:
    • Buch

Beziehungen:

• Schreibt - Beziehung (n:m):
  • Autor 1..n --- schreibt --- 1..n Buch
• Leiht aus - Beziehung (n:m):
  • Mitglied 1..n --- leiht aus --- 1..n Buch

Das fertige ER-Diagramm sollte genau diese Entitäten, Attribute und die beschriebenen Beziehungen zwischen den Entitäten visualisieren. Ein typisches ER-Diagramm für diese Aufgabe würde folgendermaßen aussehen:

In der grafischen Darstellung wird jedes Rechteck eine Entität darstellen (z.B., Buch, Autor, Mitglied), jedes Oval ein Attribut (z.B., ISBN, Name), und jede Raute eine Beziehung (z.B., Schreibt, Leiht aus). Die Linien zwischen Rechtecken und Rauten zeigen die Kardinalitäten der Beziehungen an.

b)

2) Implementiere die ER-Modellierung in SQL. Schreibe SQL-Abfragen, um die Tabellen für Autoren, Bücher und Mitglieder zu erstellen. Verwende dabei die primären und fremden Schlüssel korrekt. Beispiel:

CREATE TABLE Autoren (    Autor_ID INT PRIMARY KEY AUTO_INCREMENT,    Name VARCHAR(100),    Geburtsdatum DATE,    Nationalität VARCHAR(50));CREATE TABLE Bücher (    ISBN VARCHAR(13) PRIMARY KEY,    Titel VARCHAR(200),    Genre VARCHAR(50),    Veröffentlichungsjahr INT);CREATE TABLE Mitglieder (    Mitgliedsnummer INT PRIMARY KEY AUTO_INCREMENT,    Name VARCHAR(100),    Anmeldedatum DATE);-- Weitere Tabellen und Beziehungen hinzufügen

Lösung:

Um die beschriebene Online-Bibliothek in SQL zu implementieren, müssen wir zunächst die Tabellen für Autoren, Bücher und Mitglieder erstellen. Danach müssen wir die Beziehungen zwischen diesen Tabellen durch Verknüpfungstabellen (Join-Tabellen) darstellen, um die n:m-Beziehungen abzubilden.

-- Tabelle für Autoren erstellenCREATE TABLE Autoren (    Autor_ID INT PRIMARY KEY AUTO_INCREMENT,    Name VARCHAR(100),    Geburtsdatum DATE,    Nationalität VARCHAR(50));-- Tabelle für Bücher erstellenCREATE TABLE Bücher (    ISBN VARCHAR(13) PRIMARY KEY,    Titel VARCHAR(200),    Genre VARCHAR(50),    Veröffentlichungsjahr INT);-- Tabelle für Mitglieder erstellenCREATE TABLE Mitglieder (    Mitgliedsnummer INT PRIMARY KEY AUTO_INCREMENT,    Name VARCHAR(100),    Anmeldedatum DATE);-- Verknüpfungstabelle für die n:m-Beziehung zwischen Autoren und BüchernCREATE TABLE Autoren_Buecher (    Autor_ID INT,    ISBN VARCHAR(13),    PRIMARY KEY (Autor_ID, ISBN),    FOREIGN KEY (Autor_ID) REFERENCES Autoren(Autor_ID),    FOREIGN KEY (ISBN) REFERENCES Bücher(ISBN));-- Verknüpfungstabelle für die n:m-Beziehung zwischen Mitgliedern und BüchernCREATE TABLE Mitglieder_Buecher (    Mitgliedsnummer INT,    ISBN VARCHAR(13),    PRIMARY KEY (Mitgliedsnummer, ISBN),    FOREIGN KEY (Mitgliedsnummer) REFERENCES Mitglieder(Mitgliedsnummer),    FOREIGN KEY (ISBN) REFERENCES Bücher(ISBN));

Dieser SQL-Code erstellt die benötigten Tabellen und definiert die Beziehungen zwischen ihnen:

• Die Autoren-Tabelle speichert Details über die Autoren.
• Die Bücher-Tabelle speichert Details über die Bücher.
• Die Mitglieder-Tabelle speichert Details über die Mitglieder.
• Die Autoren_Buecher-Tabelle stellt die n:m-Beziehung zwischen Autoren und Büchern dar.
• Die Mitglieder_Buecher-Tabelle stellt die n:m-Beziehung zwischen Mitgliedern und Büchern dar.

Die Beziehungen werden durch Verwendung von Fremdschlüsseln (Foreign Keys) korrekt implementiert, um die referenzielle Integrität zwischen den Tabellen aufrechtzuerhalten.

Aufgabe 2)

Du hast eine Datenbanktabelle Kunden mit den folgenden Attributen: KundenID, Name, Adresse, BestellID, BestellDatum, ProduktID, ProduktName, ProduktPreis. Um die Datenbank zu optimieren, musst Du sie normalisieren. Denke daran, dass Du dabei schrittweise verschiedene Normalformen erreichst.

a)

Normalisiere die Tabelle Kunden in die 1. Normalform (1NF). Entwickle das Schema und beschreibe, wie Du Wiederholungsgruppen eliminierst.

Lösung:

Normalisierung der Tabelle Kunden in die 1. Normalform (1NF)

Die 1. Normalform (1NF) erfordert, dass alle Attribute atomar sind, das heißt, jedes Attribut enthält nur einen einzelnen Wert und keine Wiederholungsgruppen oder Arrays. Folgende Schritte sind nötig, um die Tabelle Kunden in die 1. Normalform zu überführen:

• Schritt 1: Identifizierung der Nicht-atomaren Attribute

  Prüfe die Tabelle darauf, ob Spalten Wiederholungsgruppen oder mehrere Werte enthalten. In Deiner Kunden-Tabelle könnte folgendes Beispiel dies verdeutlichen:

  • Aktuelle Struktur:

    'KundenID | Name | Adresse | BestellID | BestellDatum | ProduktID | ProduktName | ProduktPreis'

• Schritt 2: Aufteilung in atomare Werte

  Die Zeilen sollten so strukturiert werden, dass jede Zeile eine einzelne Information zu einer Bestellung und einem Produkt enthält. Dies eliminiert Wiederholungsgruppen und stellt sicher, dass jedes Attribut nur einen Wert enthält.

  • Neues Schema:

    'KundenID | Name | Adresse | BestellID | BestellDatum | ProduktID | ProduktName | ProduktPreis'

  • Beachte, dass die Tabelle jetzt keine Attribute mehr enthält, die mehrere Werte haben könnten. Jede Zeile repräsentiert eine Bestellung eines einzelnen Produkts.

Beispiel für Daten in der 1. Normalform:

'1 | Max Mustermann | Musterstraße 1 | 1001 | 2023-01-01 | 501 | ProduktA | 10.00''2 | Erika Musterfrau | Beispielweg 2 | 1002 | 2023-01-02 | 502 | ProduktB | 15.00''1 | Max Mustermann | Musterstraße 1 | 1003 | 2023-01-03 | 503 | ProduktC | 20.00'

Durch die Umwandlung in die 1. Normalform (1NF) sorgen wir dafür, dass jede Zelle in der Tabelle einen einzigen Wert enthält und keine Listen oder Gruppen von Werten.

b)

Normalisiere die resultierende Tabelle aus der 1. Normalform in die 2. Normalform (2NF). Erstelle das Schema und erläutere, wie Du partielle Abhängigkeiten eliminierst.

Lösung:

Normalisierung der Tabelle Kunden in die 2. Normalform (2NF)

Die 2. Normalform (2NF) erfordert, dass die Tabelle bereits in der 1. Normalform (1NF) ist und dass sie keine partiellen Abhängigkeiten enthält. Eine partielle Abhängigkeit liegt vor, wenn ein Nicht-Schlüsselattribut nur von einem Teil des Primärschlüssels abhängt (nicht vom gesamten Primärschlüssel).

• Schritt 1: Identifizierung der partiellen Abhängigkeiten

  Bei der Tabelle Kunden in der 1NF haben wir einen zusammengesetzten Primärschlüssel, der aus den Attributen KundenID und BestellID besteht. Wir müssen analysieren, ob alle Nicht-Schlüsselattribute vollständig von diesem Primärschlüssel abhängen.

  • Aktuelle Struktur in 1NF:

    'KundenID | Name | Adresse | BestellID | BestellDatum | ProduktID | ProduktName | ProduktPreis'

• Schritt 2: Finden und Beseitigen von partiellen Abhängigkeiten

  Wir erkennen, dass Attribute wie Name und Adresse nur von KundenID abhängen, nicht aber von BestellID. Ebenso hängen die Produktattribute nur von der ProduktID und< strong>BestellID ab. Um partielle Abhängigkeiten zu eliminieren, teilen wir die Tabelle in mehrere Tabelle auf.

  • Neue Tabellenstrukturen:

    Teile die Tabelle Kunden in drei Tabellen auf:

    1. Tabelle Kunden

       'KundenID | Name | Adresse'

    2. Tabelle Bestellungen

       'BestellID | KundenID | BestellDatum'

    3. Tabelle Produkte

       'ProduktID | ProduktName | ProduktPreis'

    4. Tabelle BestellDetails (Verknüpfung von Bestellungen und Produkten)

       'BestellID | ProduktID'

Beispiele für die neuen Tabellen:

Kunden

'1 | Max Mustermann | Musterstraße 1''2 | Erika Musterfrau | Beispielweg 2'

Bestellungen

'1001 | 1 | 2023-01-01''1002 | 2 | 2023-01-02''1003 | 1 | 2023-01-03'

Produkte

'501 | ProduktA | 10.00''502 | ProduktB | 15.00''503 | ProduktC | 20.00'

BestellDetails

'1001 | 501''1002 | 502''1003 | 503'

Durch diese Aufteilung werden partielle Abhängigkeiten entfernt, da nun alle Nicht-Schlüsselattribute vollständig vom jeweiligen Primärschlüssel abhängen. Damit haben wir die Tabellenstruktur in die 2. Normalform (2NF) überführt.

c)

Normalisiere die resultierende Tabelle aus der 2. Normalform in die 3. Normalform (3NF). Gib das Schema an und erkläre, wie Du transitive Abhängigkeiten eliminierst.

Lösung:

Normalisierung der Tabelle Kunden in die 3. Normalform (3NF)

Die 3. Normalform (3NF) erfordert, dass die Tabelle bereits in der 2. Normalform (2NF) vorliegt und dass sie keine transitiven Abhängigkeiten enthält. Eine transitive Abhängigkeit liegt vor, wenn ein Nicht-Schlüsselattribut von einem anderen Nicht-Schlüsselattribut abhängt.

• Schritt 1: Überprüfung auf transitive Abhängigkeiten

  Zunächst überprüfen wir die Tabellen, die wir in der 2. Normalform (2NF) erstellt haben:

  • Tabelle Kunden

    'KundenID | Name | Adresse'

  • Tabelle Bestellungen

    'BestellID | KundenID | BestellDatum'

  • Tabelle Produkte

    'ProduktID | ProduktName | ProduktPreis'

  • Tabelle BestellDetails

    'BestellID | ProduktID'

• Schritt 2: Identifizierung und Beseitigung transitiver Abhängigkeiten

  Nun suchen wir nach möglichen transitiven Abhängigkeiten. Eine transitive Abhängigkeit würde bedeuten, dass ein Attribut über ein weiteres Attribut von einem Schlüssel abhängig ist.

  • In der Tabelle Kunden gibt es keine transitiven Abhängigkeiten, da Name und Adresse direkt vom Schlüssel KundenID abhängen.
  • In der Tabelle Bestellungen gibt es ebenfalls keine transitiven Abhängigkeiten, da alle Attribute direkt vom Schlüssel BestellID abhängen.
  • In der Tabelle Produkte können wir eine transitive Abhängigkeit feststellen:

    Das Attribut ProduktPreis hängt indirekt von ProduktID über ProduktName ab. Diesen Fall können wir jedoch tatsächlich als fehlerfrei betrachten, da ProduktPreis direkt von ProduktID abhängt.

  • Die Tabelle BestellDetails ist korrekt strukturiert und weist keine transitiven Abhängigkeiten auf.

Da in den Tabellen keine intransitiven Abhängigkeiten gefunden wurden, bleiben die Tabellenstrukturen unverändert:

1. Tabelle Kunden

   'KundenID | Name | Adresse'

2. Tabelle Bestellungen

   'BestellID | KundenID | BestellDatum'

3. Tabelle Produkte

   'ProduktID | ProduktName | ProduktPreis'

4. Tabelle BestellDetails (Verknüpfung von Bestellungen und Produkten)

   'BestellID | ProduktID'

Durch die Überprüfung und Bestätigung, dass keine transitiven Abhängigkeiten vorhanden sind, bestätigen wir, dass die Tabelle nun in der 3. Normalform (3NF) vorliegt.

Aufgabe 3)

Gegeben sei ein Datenbanksystem, das nach den ACID-Prinzipien arbeitet. Betrachte eine Bankapplikation, in der Geld zwischen verschiedenen Konten transferiert wird. Dabei wird folgende Transaktion T definiert: 1. Reduziere den Kontostand eines Ausgangskontos um einen bestimmten Betrag. 2. Erhöhe den Kontostand eines Zielkontos um denselben Betrag. Diese Transaktion soll die Einhaltung der ACID-Prinzipien gewährleisten.

a)

Diskutiere detailliert, wie das Prinzip der Atomicity (Atomarität) in der oben beschriebenen Transaktion T implementiert werden kann. Gehe dabei insbesondere auf Fehlerzustände ein, die auftreten können, und wie diese behandelt werden.

Lösung:

Implementierung des Prinzips der Atomicity (Atomarität) in der Transaktion T

• Um das Prinzip der Atomarität in der Transaktion T sicherzustellen, muss gewährleistet sein, dass alle Änderungen entweder vollständig durchgeführt oder überhaupt nicht durchgeführt werden. Das bedeutet, dass die Reduktion des Kontostands des Ausgangskontos und die Erhöhung des Kontostands des Zielkontos als eine untrennbare Einheit behandelt werden müssen.
• Fehlerzustände und deren Behandlung
• Zwischenabbruch (Partial Failure): Es könnte passieren, dass die Reduktion des Kontostands des Ausgangskontos erfolgreich durchgeführt wird, aber ein Fehler auftritt, bevor die Erhöhung des Kontostands des Zielkontos abgeschlossen ist.
• Implementierungsmöglichkeiten:

1. Transaktionsprotokoll (Transaction Log): Durch die Verwendung eines Transaktionsprotokolls kann jedes Teilschritt der Transaktion protokolliert werden. Wenn ein Fehler auftritt, bevor die gesamte Transaktion abgeschlossen ist, kann das System mithilfe des Protokolls die vorherigen Schritte rückgängig machen. Dieses Rollback stellt sicher, dass das System keinen inkonsistenten Zustand hinterlässt.
2. Zwei-Phasen-Commit-Protokoll (Two-Phase Commit): Dieses Protokoll verwendet zwei Phasen, um sicherzustellen, dass alle beteiligten Systeme die Transaktion entweder vollständig ausführen oder komplett zurücksetzen. In der ersten Phase (Prepare Phase) werden alle Ressourcen auf ihre Bereitschaft überprüft. Wenn alle Systeme zustimmen, wird in der zweiten Phase (Commit Phase) die Transaktion vollständig durchgeführt. Tritt ein Fehler auf, wird die Transaktion vollständig zurückgesetzt (Rollback).
3. Optimistisches Protokoll: Dabei wird die Transaktion ohne Sperrmechanismen durchgeführt. Erst am Ende wird geprüft, ob Konflikte auftreten. Bei einem Fehler wird die gesamte Transaktion zurückgesetzt und der Prozess möglicherweise erneut gestartet.
4. Sperrmechanismen (Locks): Durch die Verwendung von Sperrmechanismen kann sichergestellt werden, dass während der gesamten Transaktion keine anderen Prozesse auf die betroffenen Konten zugreifen können. Dies verhindert inkonsistente Zustände aufgrund von konkurrierenden Änderungen.

b)

Erkläre, wie die Consistency (Konsistenz) in der Bankapplikation durch Transaktion T gewährleistet wird. Welche Konsistenzbedingungen müssen erfüllt sein und warum?

Lösung:

Gewährleistung der Consistency (Konsistenz) in der Bankapplikation durch Transaktion T

• Konsistenzbedingungen in der Bankapplikation:
• Korrektheit der Beträge: Der Betrag, der von einem Konto abgezogen wird, muss identisch mit dem Betrag sein, der auf ein anderes Konto gutgeschrieben wird. Dies stellt sicher, dass keine Gelder verloren gehen oder unberechtigt erzeugt werden.
• Kontostandsbeschränkungen: Die Transaktion muss sicherstellen, dass keine Kontostände negativ werden, es sei denn, dies ist explizit erlaubt (beispielsweise durch einen Dispositionskredit). Dies ist essenziell, um finanzielle Integrität zu gewährleisten.
• Integrität der Kontodaten: Die Kontodaten selbst, wie Kontonummern und persönliche Informationen, dürfen durch die Transaktion nicht verändert werden.
• Implementierung der Konsistenz:
• Vorbedingungen: Die Transaktion T sollte nur ausgeführt werden, wenn die notwendigen Vorbedingungen erfüllt sind. Beispielsweise muss überprüft werden, ob das Ausgangskonto über ausreichendes Guthaben verfügt, um die Überweisung durchzuführen.
• Postbedingungen: Nach Abschluss der Transaktion müssen bestimmte Postbedingungen erfüllt sein. Dazu gehört, dass die Summe der Kontostände der beteiligten Konten derselbe ist wie vor der Transaktion (unter Berücksichtigung von Bearbeitungsgebühren, wenn vorhanden).
• Integritätsprüfungen: Während und nach der Transaktion sollten Integritätsprüfungen durchgeführt werden, um sicherzustellen, dass keine Datenbankbeschränkungen verletzt wurden. Beispielsweise müssen Fremdschlüssel- und Not-Null-Bedingungen überprüft werden.
• Beispiel für Konsistenzprüfung:
• Vor der Transaktion: Annahme, dass Konto A 100 € und Konto B 50 € hat. Überweise 20 € von Konto A zu Konto B.
• Nach der Transaktion: Konto A sollte 80 € und Konto B 70 € haben. Die Gesamtsumme der Kontostände (100 € + 50 € = 150 €) bleibt unverändert nach der Transaktion (80 € + 70 € = 150 €).
• Zusammenfassung: Die Konsistenz in der Bankapplikation wird durch die Einhaltung von Vor- und Nachbedingungen sowie regelmäßigen Integritätsprüfungen gewährleistet. Jede Transaktion muss sicherstellen, dass die Summe der Kontostände unverändert bleibt, keine negativen Kontostände entstehen (außer explizit erlaubt) und dass die Kontodaten intakt bleiben. Dadurch wird verhindert, dass die Datenbank in einen ungültigen oder inkonsistenten Zustand gerät.

c)

Stelle dar, wie das Prinzip der Isolation (Isolation) zwischen parallelen Transaktionen umgesetzt wird. Gehe dabei auf mögliche Konkurrenzsituationen ein und wie das Datenbanksystem diese verhindert.

Lösung:

Umsetzung des Prinzips der Isolation (Isolation) zwischen parallelen Transaktionen

• Ziel der Isolation: Das Prinzip der Isolation stellt sicher, dass parallele Transaktionen so ausgeführt werden, als ob sie nacheinander (seriell) ausgeführt würden. Dies verhindert, dass Transaktionen sich gegenseitig inkonsistente Zustände hinterlassen oder sehen.
• Mögliche Konkurrenzsituationen:
• Lost Update: Zwei Transaktionen aktualisieren dieselben Daten. Eine Änderung wird überschrieben und somit verloren.
• Dirty Read: Eine Transaktion liest Daten, die von einer anderen nicht abgeschlossenen Transaktion geändert wurden. Falls diese Transaktion abbricht, sind die gelesenen Daten ungültig.
• Non-repeatable Read: Eine Transaktion liest die gleichen Daten zweimal und erhält unterschiedliche Werte, weil eine andere Transaktion die Daten geändert hat.
• Phantom Read: Eine Transaktion liest eine Menge von Zeilen, aber eine andere Transaktion fügt Zeilen hinzu oder löscht Zeilen in dieser Menge, wodurch sich die Ergebnismenge der ersten Transaktion verändert.
• Mechanismen zur Umsetzung der Isolation:
• Sperren (Locks): Sperrmechanismen sind eine weit verbreitete Methode zur Implementierung von Isolation. Es gibt verschiedene Arten von Sperren:

1. Exklusive Sperren (Write Locks): Diese verhindern, dass andere Transaktionen die Daten ändern oder lesen können, solange die Sperre aktiv ist.
2. Gemeinsame Sperren (Read Locks): Diese erlauben anderen Transaktionen, die Daten zu lesen, aber nicht zu ändern.
3. Intentionale Sperren: Diese ermöglichen eine hierarchische Sperrstrategie, um gleichzeitig Lese- und Schreiboperationen auf verschiedenen Ebenen einer Datenbankstruktur zu erlauben.

1. Read Uncommitted: Ermöglicht Dirty Reads, die Daten sind nicht isoliert.
2. Read Committed: Verhindert Dirty Reads, aber ermöglicht Non-repeatable Reads.
3. Repeatable Read: Verhindert Non-repeatable Reads, aber Phantom Reads können auftreten.
4. Serializable: Höchste Isolationsebene, verhindert alle oben genannten Probleme, ermöglicht jedoch die geringste Parallelität.

• Zwei Transaktionen versuchen gleichzeitig, Geld von demselben Konto A zu transferieren. Angenommen, Transaktion T1 reduziert den Kontostand von A um 50 €, während Transaktion T2 zur gleichen Zeit den Kontostand von A um 30 € reduziert.
• Ohne Isolation könnten beide Transaktionen denselben ursprünglichen Kontostand lesen und gleichzeitig Änderungen vornehmen, die zu einem inkonsistenten Endzustand führen.
• Durch Sperren könnte zuerst T1 eine exklusive Sperre auf das Konto A setzen, Änderungen vornehmen und abschließen. Erst dann darf T2 den Kontostand von A lesen und seine Transaktion durchführen.

d)

Beschreibe, wie das Prinzip der Durability (Dauerhaftigkeit) in der beschriebenen Bankapplikation sichergestellt wird. Gehe auf Szenarien ein, bei denen Systemabstürze oder Datenverlust drohen, und wie diese verhindert werden können.

Lösung:

Gewährleistung des Prinzips der Durability (Dauerhaftigkeit) in der beschriebenen Bankapplikation

• Ziel der Dauerhaftigkeit: Das Prinzip der Dauerhaftigkeit stellt sicher, dass einmal abgeschlossene Transaktionen auch bei Systemabstürzen oder anderen Fehlern dauerhaft und sicher in der Datenbank gespeichert bleiben.
• Szenarien, bei denen Dauerhaftigkeit wichtig ist:
• Systemabsturz: Durch einen Hardware- oder Softwarefehler kann das System unerwartet herunterfahren.
• Stromausfall: Ein plötzlicher Stromausfall kann das System zum Stillstand bringen, bevor alle Daten geschrieben wurden.
• Datenverlust: Hardwarefehler wie defekte Festplatten können zu Datenverlust führen.
• Methoden zur Sicherstellung der Dauerhaftigkeit:
• Write-Ahead Logging (WAL): Bevor eine Transaktion tatsächlich auf die Datenbank geschrieben wird, werden alle Änderungen zunächst in ein Transaktionslog geschrieben. Dieses Log wird persistent gespeichert. Im Falle eines Systemabsturzes oder Stromausfalls kann das System beim Neustart das Log verwenden, um nicht abgeschlossene Transaktionen zu identifizieren und entweder vollständig abzuschließen oder rückgängig zu machen.
• Checkpoints: Regelmäßige Checkpoints sorgen dafür, dass der aktuelle Zustand der Datenbank gesichert wird. Dieses beinhaltet das Schreiben aller im Speicher befindlichen Daten auf Festplatten und das Minimieren der Anzahl der im Log gespeicherten Transaktionen, die nach einem Absturz wiederhergestellt werden müssen.
• Redundante Speichersysteme: Datenspeicherung in redundanten Systemen wie RAID (Redundant Array of Independent Disks) oder verteilten Dateisystemen kann helfen, Datenverlust durch Hardwarefehler zu verhindern. Falls eine Festplatte ausfällt, verbleiben die Daten auf einer oder mehreren anderen Festplatten.
• Backup and Restore: Regelmäßige Backups der Datenbank auf externe Speichermedien oder Cloud-Speicher sorgen dafür, dass im Falle eines schwerwiegenden Fehlers oder Datenverlusts die Datenbank aus einem früheren Zustand wiederhergestellt werden kann.
• Notstromversorgung (USV): Eine unterbrechungsfreie Stromversorgung stellt sicher, dass das System auch bei Stromausfällen weiterläuft, damit Transaktionen ordnungsgemäß abgeschlossen und gespeichert werden können.
• Beispiel:
• Eine Transaktion T überweist 100 € von Konto A zu Konto B.
• Bevor die Änderung auf die Datenbank geschrieben wird, werden die Details der Transaktion (Reduktion von 100 € von Konto A, Erhöhung von 100 € auf Konto B) in ein Transaktionslog geschrieben und auf der Festplatte gespeichert.
• Im Falle eines Systemabsturzes, wird beim Neustart das Transaktionslog gelesen. Da die Transaktion vollständig im Log erfasst ist, kann das System die Transaktion korrekt abschließen oder bei unvollständigen Aktionen einen Rollback durchführen.
• Zusammenfassung: Die Dauerhaftigkeit der Transaktion T wird durch Mechanismen wie Write-Ahead Logging, Checkpoints, redundante Speichersysteme, regelmäßige Backups und Notstromversorgung erreicht. Diese Methoden stellen sicher, dass abgeschlossene Transaktionen auch bei Systemabstürzen, Stromausfällen oder Hardwarefehlern sicher und dauerhaft gespeichert werden.

Aufgabe 4)

Du bist Systemadministrator eines großen verteilten Datenbanksystems, das Datenreplikation verwendet, um die Datenverfügbarkeit und Fehlertoleranz zu erhöhen. Dieser Ansatz hat jedoch einige Herausforderungen bei der Sicherstellung der Konsistenz und Handhabung von Konflikten. Angenommen, Dein System verwendet eine Mischung aus synchroner und asynchroner Datenreplikation mit einer Master-Slave-Konfiguration, um verschiedene Anforderungen an Latenz und Konsistenz zu erfüllen. Für die Konfliktbehandlung nutzt Dein System den Two-Phase Commit (2PC)-Protokoll und hat eine hybride Konsistenzstrategie, die sowohl starke Konsistenz als auch eventual consistency in verschiedenen Szenarien verfolgt.

a)

Erläutere den Unterschied zwischen synchroner und asynchroner Datenreplikation und gib, unter Berücksichtigung von Latenz und Verfügbarkeit, je ein Beispiel für ein Szenario, in dem der Einsatz der jeweiligen Strategie sinnvoll ist.

Lösung:

• Synchrone Datenreplikation: Bei der synchronen Datenreplikation werden die Daten sofort auf alle replizierten Systeme übertragen. Dies bedeutet, dass eine Transaktion auf dem Master erst dann als abgeschlossen gilt, wenn alle Slaves die Daten erfolgreich erhalten und bestätigt haben. Hierdurch wird eine starke Konsistenz sichergestellt, da alle Knoten zu jedem Zeitpunkt dieselben Daten enthalten. Allerdings kann dies zu höherer Latenz führen, insbesondere wenn die replizierten Systeme geographisch weit verteilt sind.

• Beispiel: Ein Finanzdienstleistungsunternehmen benötigt in Echtzeit konsistente Datenübertragungen, um Transaktionen ohne Diskrepanzen durchzuführen. Hier ist synchrone Replikation sinnvoll, um sicherzustellen, dass alle beteiligten Systeme die gleichen Informationen haben.
• Asynchrone Datenreplikation: Bei der asynchronen Datenreplikation wird erst am Master eine Transaktion abgeschlossen und anschließend, möglicherweise mit einer gewissen Verzögerung, die Daten zu den Slaves übertragen. Dies führt zu geringerer Latenz, aber es besteht die Möglichkeit von Inkonsistenzen, da die Slaves nicht sofort die neuesten Daten haben.
• Beispiel: Bei einem sozialen Netzwerk können Benutzer Kommentare posten oder Beiträge liken. Dabei ist es akzeptabel, wenn es zu einer geringen zeitlichen Verzögerung kommt, bis alle Datenbankknoten die Änderungen übernehmen. Hier bietet sich asynchrone Replikation an, um die Latenz für den Endbenutzer niedrig zu halten und trotzdem genügend Verfügbarkeit zu gewährleisten.

b)

Beschreibe den Ablauf des Two-Phase Commit (2PC)-Protokolls und erkläre, wie dieses Protokoll dabei hilft, Konsistenz in Deinem verteilten Datenbanksystem sicherzustellen.

Lösung:

• Two-Phase Commit (2PC)-Protokoll: Ablauf und Konsistenzsicherung
• Ablauf des Two-Phase Commit (2PC)-Protokolls:
• Das 2PC-Protokoll besteht aus zwei Hauptphasen: der Vorbereitungsphase (Prepare Phase) und der Abschlussphase (Commit Phase).
• 1. Vorbereitungsphase (Prepare Phase):
• Der Koordinator (meist der Master) sendet eine 'Prepare'-Nachricht an alle Teilnehmer (Slaves).
• Jeder Teilnehmer führt die Transaktion lokal aus, hält die Änderungen jedoch so lange zurück, bis er eine endgültige Entscheidung erhält.
• Daraufhin sendet jeder Teilnehmer eine 'Vote-Commit'- oder 'Vote-Abort'-Nachricht basierend auf dem Erfolg seiner lokalen Operationen zurück an den Koordinator.
• 2. Abschlussphase (Commit Phase):
• Falls der Koordinator von allen Teilnehmern 'Vote-Commit'-Nachrichten erhält, sendet er eine 'Global-Commit'-Nachricht, woraufhin alle Teilnehmer ihre lokalen Transaktionen festschreiben und damit endgültig machen.
• Erhält der Koordinator jedoch eine 'Vote-Abort'-Nachricht von einem oder mehreren Teilnehmern, sendet er eine 'Global-Abort'-Nachricht. Alle Teilnehmer verwerfen daraufhin ihre lokalen Änderungen und ziehen die Transaktion zurück.
• Wie 2PC Konsistenz sicherstellt:
• Vermeidung von Inkonsistenzen: Durch die zweiphasige Natur des 2PC-Protokolls können nur Transaktionen, die von allen beteiligten Knoten erfolgreich lokal durchgeführt wurden, global festgeschrieben werden. Dies sichert die Konsistenz der Daten, da entweder alle Knoten die Transaktion übernehmen oder keiner.
• Gesicherte Fehlertoleranz: Selbst wenn während der Protokollausführung ein Fehler auftritt (z.B. ein Teilnehmer oder der Koordinator fällt aus), kann das System zum letzten stabilen Punkt (den Vorbereitungsnachrichten) zurückkehren und auf das erneute Verbindungsaufbau oder auf die Unbesiegbarkeit der Transaktion warten.
• Atomizität: Das Protokoll stellt sicher, dass die Transaktionen atomar sind, d.h. entweder werden alle Tatsachen festgeschrieben oder keine. Dies verhindert Teilschreibvorgänge, die Daten inkonsistent machen könnten.

c)

In Deinem System treten häufig Konflikte bei der Datenreplikation auf. Erkläre, wie Konflikte in einer Master-Slave-Replikation festgestellt und mit Hilfe des Two-Phase Commit (2PC)-Protokolls aufgelöst werden können.

Lösung:

• Konflikte in einer Master-Slave-Replikation:
• Konflikte können auftreten, wenn:
• Mehrere Slaves unterschiedliche Versionen derselben Daten haben.
• Es gleichzeitige Schreibzugriffe gibt, die widersprüchlich sind.
• Daten auf einem Slave nicht wie auf dem Master aktualisiert werden (inkonsistente Zustände).
• Feststellung von Konflikten:
• Synchronisation überprüft die Konsistenz der Daten. Asynchrone Replikation erkennt Konflikte durch Vergleich der letzten Schreibvorgänge und Zustände.
• Leistungsüberwachung kann Abweichungen in Transaktionszeitstempeln oder Versionen entdecken.
• Auflösung von Konflikten mit dem Two-Phase Commit (2PC)-Protokoll:
• Das 2PC-Protokoll hilft, Konflikte zu vermeiden, indem es alle Teilnehmer (Slaves) einer Transaktion dazu zwingt, entweder gemeinsam festzuschreiben oder zurückzurollen. Das geschieht in folgenden Schritten:
• 1. Vorbereitungsphase (Prepare Phase):
• Der Koordinator (Master) sendet eine 'Prepare'-Nachricht an alle Slaves, um sie über die geplante Transaktion zu informieren.
• Jeder Slave prüft, ob die Transaktion lokal ohne Konflikte durchgeführt werden kann, und sendet eine 'Vote-Commit'- oder 'Vote-Abort'-Nachricht zurück.
• 2. Abschlussphase (Commit Phase):
• Erhält der Koordinator von allen Slaves 'Vote-Commit'-Nachrichten, sendet er ihnen eine 'Global-Commit'-Nachricht. Nun führen die Slaves die Transaktion durch.
• Erhält der Koordinator eine 'Vote-Abort'-Nachricht, sendet er 'Global-Abort' an alle Slaves. Die Transaktion wird durch die Slaves verworfen, und es erfolgt kein Update.
• Beispiel für Konfliktauflösung allgemein:
• Ein Slave hat eine neuere Version als der Master. Der Koordinator sendet 'Prepare'-Nachrichten an alle Slaves.
• Ein Slave erkennt den Versionskonflikt und antwortet mit 'Vote-Abort'.
• Der Koordinator sendet daraufhin 'Global-Abort' an alle Slaves, die Transaktion wird abgebrochen, und ein Konflikt wird vermieden.
• Spezielle Strategien:
• Retry Mechanisms: Der Koordinator könnte die Transaktion nach einer kurzen Wartezeit erneut versuchen.
• Versionierung: Bewahren von Versionen zur Auflösung von Konflikten.

d)

Betrachte ein Szenario, in dem Dein System eine hybride Konsistenzstrategie verwendet. Erkläre, wie das System zwischen starker Konsistenz und eventual consistency wechselt und welche Auswirkungen diese Strategien auf Latenz und Durchsatz haben können. Führe dazu relevante Leistungsmetriken an.

Lösung:

• Hybride Konsistenzstrategie in einem verteilten Datenbanksystem:
• In einem System mit hybrider Konsistenzstrategie werden Kontextinformation und Anforderungskriterien genutzt, um zwischen starker Konsistenz und eventual consistency zu wechseln. Dies erfolgt dynamisch basierend auf bestimmten Faktoren wie der Art der Daten, der aktuellen Workload oder den Anforderungen der Anwendung.
• Wechsel zwischen starker Konsistenz und eventual consistency:
• Starke Konsistenz: Hierbei werden alle Änderungen sofort auf alle replizierten Knoten angewendet, und die Datenbanken halten denselben Zustand. Dies wird typischerweise durch synchrone Replikation erreicht. Der Two-Phase Commit (2PC)-Protokoll stellt sicher, dass Transaktionen atomar und konsistent sind.
• Vorteil: Keine Inkonsistenzen, da alle Knoten immer denselben Zustand haben.
• Nachteil: Erhöhte Latenz, da jeder Schreibvorgang bestätigt werden muss, bevor er abgeschlossen ist. Dies kann den Durchsatz verringern, insbesondere bei hoher Netzwerkverzögerung.
• Eventual Consistency: Hierbei werden Änderungen asynchron repliziert. Das bedeutet, dass die Daten über eine gewisse Zeitspanne inkonsistent sein können, bevor sie schließlich konsistent werden.
• Vorteil: Geringere Latenz, da Schreibvorgänge schnell abgeschlossen werden können, ohne auf Bestätigungen von allen Knoten zu warten. Erhöhter Durchsatz durch schnellere Verarbeitung von Schreiboperationen.
• Nachteil: Potenzielle Inkonsistenzen zwischen den Knoten während des Zeitraums, in dem die Replikation noch nicht vollständig ist.
• Leistungsmetriken und Auswirkungen:
• Latenz: Dies ist die Zeit, die eine Transaktion benötigt, um abgeschlossen zu werden.
• Bei starker Konsistenz: Höhere Latenz aufgrund der Notwendigkeit, Bestätigungen von allen Knoten zu erhalten.
• Bei eventual consistency: Niedrigere Latenz, da Schreibvorgänge schneller abgeschlossen werden können.
• Durchsatz: Dies ist die Anzahl der Transaktionen, die vom System in einer bestimmten Zeitspanne verarbeitet werden können.
• Bei starker Konsistenz: Potentiell niedrigerer Durchsatz aufgrund der zusätzlichen Kommunikation und Synchronisationsanforderungen.
• Bei eventual consistency: Höherer Durchsatz, da die Transaktionen schneller verarbeitet und abgeschlossen werden können.
• Verfügbarkeit: Die Fähigkeit des Systems, Anfragen zu verarbeiten, auch im Fehlerfall.
• Stärkere Konsistenz verlangt oft höhere Verfügbarkeit, was jedoch durch Netzwerk- und Synchronisationsprobleme beeinträchtigt werden kann.
• Eventual consistency bietet bessere Verfügbarkeit, da die Knoten unabhängig operieren können, indem sie später synchronisiert werden.
• Relevante Metriken:
• Average Latency: Durchschnittliche Zeit, die benötigt wird, um eine Transaktion abzuschließen.
• Throughput (TPS - Transactions per Second): Anzahl der Transaktionen, die das System pro Sekunde verarbeiten kann.
• Consistency Window: Zeitspanne, in der Daten inkonsistent sein können, bevor sie synchronisiert werden.
• Availability: Prozentsatz der Zeit, in der das System verfügbar ist für Anfragen.