Klausuraufgaben-WS-2023-24

Aufgabe 1: Gemischte Fragen

Aufgabenstellung

Gegeben sei das Relationenschema $R=(\underline{A},B,C,D)$. Wir wissen, dass $A$ der einzige Schlüsselkandidat ist. Über weitere funktionale Abhängigkeiten gibt es keine Informationen, es kann aber weitere funktionale Abhängigkeiten geben. Nehmen Sie an, dass $R$ die erste Normalform erfüllt.

(a) Können wir mit Sicherheit davon ausgehen, dass $R$ auch die zweite und dritte Normalform erfüllt? Begründen Sie Ihre Aussage jeweils in ein bis zwei Sätzen.

Lösung

2.NF

Für die 2. Normalform (2NF) muss gellten:

• jedes Nicht-Schlüssel-Attribut (NSA) ist voll funktional abhängig von jedem Schlüsselkandidaten

Diese Bedingung ist erfüllt, da $A$ der einzige Schlüssel ist und alle Attribute die vom Schlüsselkandidaten $A$ abhängig sind automatisch von allen Schlüsselkandidaten (also nur A) abhängig sind. Es kann also garkeinen Fall geben, dass ein Attribute nicht von allen Schlüsselattributen abhängig sind.

In der 2.NF sind zudem transitive Abhängigkeiten erlaubt wie z.B $B\to C$

3.NF

Für die 3. Normalform (3NF) muss gellten:

• Keine transitiven Abhängigkeiten (Kein Nichtschlüssel zu anderem Nichtschlüssel) wobei der eine Nichtschlüssel wiederum von einem Schlüsselkandidaten abhängt
• ”Vermittler” hängt also von Schlüsselkandidat ab ist aber selber keiner und hat eine Abhängigkeit zu einem Nichtschlüsselkandidaten
• Reicht wenn ein Nichtschlüssel Attribute von irgendeinem Schlüsselkandidaten abhängig ist

Die 3.NF ist hier nicht gegeben, da es eine Abhängigkeit $A\to B$ geben kann, und dann wiederum eine Abhängigkeit $B\to C$ wo $B$ also der Vermittler dient

(b) Gegeben seien die Relationen $R=(A,B,C)$ und $S=(B,C,D)$. Relation $R$ enthält 50 Tuple und Relation $S$ enthält 10 Tuple. Gegeben seien außerdem folgende Anfragen:

$A_1$:

SELECT DISTINCT *
FROM R, S;

$A_2$:

SELECT *
FROM R NATURAL JOIN S;

• $A_1$ ist das Kreuzprodukt von $R$ und $S$ $(R\times S)$ (CrossJoin in SQL)

• Minimale Anzahl von Ergebnistupel für Anfrage $A_1$:

Lösung

Berechnung und Erklärung:

Die minimale Anzahl der Ergebnistupel ist das Product der Anzahl der Tuple in den beiden beteiligten Relationen. Dies ergibt:

$$50\text{ Tupel in }R\times 10\text{ Tupel in }S=500\text{ Ergebnistupel}$$

• Maximale Anzahl von Ergebnistupel für Anfrage $A_1$:

Lösung

Berechnung und Erklärung:

Die maximale Anzahl der Ergebnistupel ist identisch zur minimalen, da es sich um eine Kreuzprodukt-Operation handelt, die alle Kombinationen der Tuple aus beiden Relationen erzeugt:

$$50\text{ Tupel in }R\times 10\text{ Tupel in }S=500\text{ Ergebnistupel}$$

• Anzahl der Attribute in der Ergebnisrelation von Anfrage $A_1$:

Lösung

• Ergebnis: 6 Attribute.

• Minimale Anzahl von Ergebnistupel für Anfrage $A_2$:

Lösung

• Ergebnis: Mindestens 0 Ergebnistupel, da es möglich ist, dass keine Übereinstimmungen in den gemeinsamen Spalten existieren.

• Maximale Anzahl von Ergebnistupel für Anfrage $A_2$

Lösung

Berechnung:

Im schlimmsten Fall stimmt jedes Tuple in $R$ mit jedem Tuple in $S$ bezüglich der Werte in den Spalten $B$ und $C$ überein. Daher ist die Anzahl der Ergebnistupel das Product der Anzahl der Tuple in beiden Relationen:

$$50\text{ Tupel in }R\times 10\text{ Tupel in }S=500$$

- Anzahl der Attribute in der Ergebnisrelation von Anfrage $A_2$ >[!success] Lösung > >- **Ergebnis**: 4 Attribute. ## (c) Gegeben seien die Transaktionen $T_1$, $T_2$ und $T_3$, wobei Transaktion $T_1$ aus 5 Einzelaktionen, Transaktion $T_2$ aus 7 Einzelaktionen und Transaktion $T_3$ aus 8 Einzelaktionen besteht. Wie viele mögliche verschiedene serielle Schedules gibt es? - $T_{1}$ hat 5 Einzelaktionen - $T_2$ hat 7 Einzelaktionen - $T_3$ hat 8 Einzelaktionen >[!success] Lösung > >

serielle \ Schedules \ Anzahl: 3! = 6

(d) Was unterscheidet eine materialisierte View von einer gewöhnlichen View?

Lösung

• materialisierte Views kann man abspeichern und wie eine Art eigene Schema benutzen, die Ergebnisse der materialisierten View werden physisch in eienr Tabelle gespeichert
• Eine gewöhnliche View speichert keine Daten physisch. Stattdessen handelt es sich um eine Abfrage, die bei Bedarf ausgeführt wird, um die aktuellen Daten aus den zugrunde liegenden Tabellen zu generieren

Was ist der wesentliche Vorteil einer materialisierten View?

Lösung

• Verbesserte Abfrageleistung durch physische Speicherung der Abfrageergebnisse
• Schnellerer Zugriff auf Daten, da Abfrage nicht bei jedem Zugriff erneut ausgeführt werden muss
• Kürzere Antwortzeiten insbesondere bei komplexen Abfragen oder großen Datenmengen
• Möglichkeit zur Speicherung vorausberechneter Daten, was die Leistung weiter verbessert
• Effizientere Datenverarbeitung und -abfrage, besonders in Umgebungen mit großen Datenmengen oder komplexen Abfragen

(e) Was ist die maximale und minimale Anzahl von Schlüsseln, die ein innerer Knoten in einem B-Baum der Ordnung 10 haben kann?

Lösung

Minimal: 10 Maximal: 20

---

Aufgabe 2 SQL & Kalküle Tupelkalkül |Bereichskalkül | Erweiterte Abfragen in SQL

Aufgabenstellung

Gegeben sei das folgende Datenbankschema, das für die Speicherung der Daten eines Geheimdienstes verwendet wird. Zusätzlich ist ein Teil seiner Ausprägung gegeben. Die Primärschlüsselattribute sind jeweils unterstrichen. Die Attributnamen sind global eindeutig, d.h. Fremdschlüsselbeziehungen sind anhand des Attributnamens erkennbar.

In der Relation Agenten werden alle Agenten mit einer eindeutigen Nummer und ihrem Namen gespeichert. Die Relation Einsätze beschreibt Einsätze, die jeweils mit einem eindeutigen Namen beschrieben werden. Einsätze finden an einem bestimmten Datum und Ort statt und werden aufgrund einer Zielperson durchgeführt. Die Agenten tragen Decknamen (Relation Decknamen). Dabei ist einem Decknamen jeweils ein Agent eindeutig zuzuordnen. Ein Agent kann aber mehrere Decknamen haben. Agenten nehmen gegen Bezahlung an Einsätzen teil (Relation nimmt-teil). Außerdem kann ein Agent auch under mehreren Decknamen an einem Einsatz teilnehmen.

• $Agenten(\underline{ANr},Name)$
• $Eins\ddot{a}tze(\underline{EName},Datum,Ort,Zielperson)$
• $Decknamen(\underline{Deckname},ANr)$
• $nimmt-teil(\underline{EName},\underline{Deckname},Bezahlung)$

(a) Geben Sie die Anweisung in SQL-DDL an, die notwendig ist, um die Relation “nimmt-teil” wie beschrieben zu erzeugen. Achten Sie dabei auf Fremdschlüsselbeziehungen und wählen Sie anhand der gegebenen Ausprägungen sinnvolle Datentypen. Die Bezahlung ist ganzzahlig und darf niemals negative sein. Gehen Sie davon aus, dass alle Zeichenketten eine maximale Länge von 20 haben.

Lösung

• Kurzform:

  CREATE TABLE nimmt-teil
  (
      EName VARCHAR(20) REFERENCES Einsätze,
      Deckname VARCHAR(20) REFERENCES Decknamen,
      Bezahlung INTEGER CHECK (Bezahlung >= 0),
      PRIMARY KEY (EName,Deckname)
  )

• Längere Form:

  CREATE TABLE nimmt-teil
  (
      EName VARCHAR(20) REFERENCES Einsätze(EName),
      Deckname VARCHAR(20) REFERENCES Decknamen(Deckname),
      Bezahlung INTEGER CHECK (Bezahlung >= 0),
      PRIMARY KEY (EName,Deckname)
  )

• Ausführliche Form:

  CREATE TABLE `nimmt-teil`
  (
      EName VARCHAR(20),
      Deckname VARCHAR(20),
      Bezahlung INTEGER CHECK (Bezahlung >= 0),
      PRIMARY KEY (`EName`, `Deckname`),
      FOREIGN KEY (`EName`) REFERENCES `Einsätze`(`EName`),
      FOREIGN KEY (`Deckname`) REFERENCES `Decknamen`(`Deckname`)
  )

Alle drei Formen sind korrekt, aber die kürzeste Form ist am prägnantesten.

(b) Erstellen Sie eine Liste aller Einsätze, an denen der Agent under dem Decknamen 007 beteiligt war. Die Liste soll den Einsatznamen, das Datum, den Ort und die Zielperson enthalten. Sortieren Sie die Liste absteigend nach dem Namen der Zielperson und bei gleicher Zielperson aufsteigend nach dem Datum.

• $Agenten(\underline{ANr},Name)$
• $Eins\ddot{a}tze(\underline{EName},Datum,Ort,Zielperson)$
• $Decknamen(\underline{Deckname},ANr)$
• $nimmt-teil(\underline{EName},\underline{Deckname},Bezahlung)$

Lösung

SELECT EName,Datum,Ort,Zielperson FROM Einsätze
JOIN nimmt-teil ON Einsätze.EName = nimmt-teil.EName
WHERE Deckname = "007"
ORDER BY Zielperson DESC, Datum ASC

(c) Geben Sie zu jedem Agenten den Realnamen und dessen Einsatzorte an. Nehmen Sie jedoch nur diejenigen Orte auf, an denen noch kein anderer Agent einen Einsatz hatte.

• $Agenten(\underline{ANr},Name)$
• $Eins\ddot{a}tze(\underline{EName},Datum,Ort,Zielperson)$
• $Decknamen(\underline{Deckname},ANr)$
• $nimmt-teil(\underline{EName},\underline{Deckname},Bezahlung)$

Lösung

SELECT Name, Ort
FROM Agenten A1
JOIN Decknamen D1 ON D1.ANr = A1.ANr
JOIN nimmt-teil NT1 ON NT1.Deckname = D1.Deckname
JOIN Einsätze E1 ON NT1.EName = E1.EName
WHERE NOT EXISTS ( SELECT * FROM Agenten A2
				   JOIN Decknamen D2 ON D2.ANr = A2.ANr
				   JOIN nimmt-teil NT2 ON NT2.Deckname = D2.Deckname
				   JOIN Einsätze E2 ON NT2.EName = E2.EName
				   WHERE E1.Ort = E2.Ort AND NOT(A1.Name = A2.Name)
				 )

(d) Geben Sie für jeden Einsatz den Einsatznamen sowie die Gesamtkosten aller Bezahlungen für die Agenten aus. Jedoch sollen dabei nur die Bezahlung der Agenten mitgezählt werden, die schon an mehr also zwei unterschiedlichen Einsätzen beteiligt waren.

• $Agenten(\underline{ANr},Name)$
• $Eins\ddot{a}tze(\underline{EName},Datum,Ort,Zielperson)$
• $Decknamen(\underline{Deckname},ANr)$
• $nimmt-teil(\underline{EName},\underline{Deckname},Bezahlung)$

Lösung

SELECT E.EName, SUM(NT.Bezahlung) AS Gesamtkosten FROM Einsätze E
JOIN nimmt-teil NT ON E.EName = NT.EName
JOIN Decknamen D ON NT.Deckname = D.Deckname
WHERE D.ANr IN (SELECT D2.ANr FROM Decknamen D2
               JOIN nimmt-teil NT2 ON D2.Deckname = NT2.Deckname
               GROUP BY D2.ANr
               HAVING COUNT(DISTINCT NT2.EName) > 2)
GROUP BY E.EName;

Schritte zur Erstellung der SQL-Abfrage

• Verknüpfung der Tabellen: Verbinde die Einsätze-, nimmt-teil- und Decknamen-Tabellen, um Einsätze mit den zugehörigen Bezahlungen und Agenten zu assoziieren.
  • FROM Einsätze E JOIN nimmt-teil NT ON E.EName = NT.EName: Jeder Einsatz wird mit den Details seiner Teilnahme verknüpft.
  • JOIN Decknamen D ON NT.Deckname = D.Deckname: Die Teilnahmeinformationen werden über Decknamen mit den Agenten verbunden.
• Filtern von Agenten: Wähle nur die Agenten aus, die an mehr also zwei verschiedenen Einsätzen beteiligt waren.
  • WHERE D.ANr IN (…): Es wird eine Unterabfrage verwendet, die die Agenten filtert.
  • SELECT D2.ANr FROM Decknamen D2 JOIN nimmt-teil NT2 ON D2.Deckname = NT2.Deckname: Diese Unterabfrage sammelt alle Agenten und deren Einsätze.
  • GROUP BY D2.ANr: Gruppierung der Agenten, um die Einsätze je Agent zu zählen.
  • HAVING COUNT(DISTINCT NT2.EName) > 2: Agenten, die an mehr also zwei unterschiedlichen Einsätzen teilgenommen haben, werden ausgewählt.
• Aggregieren der Kosten: Berechne die Gesamtkosten der Bezahlungen für jeden Einsatz.
  • SUM(NT.Bezahlung) AS Gesamtkosten: Summiert alle Bezahlungen, die den oben genannten Kriterien entsprechen.
  • GROUP BY E.EName: Die Ergebnisse werden nach Einsatzname gruppiert, um die Kosten pro Einsatz auszugeben.

Ziel der Abfrage

• Die Abfrage liefert den Namen jedes Einsatzes zusammen mit den Gesamtkosten der Zahlungen an Agenten, die intensiv (mehr also zwei verschiedene Einsätze) involviert waren.

(e) Geben Sie die Namen der Zielpersonen an, gegen die under dem Decknamen 007 im Jahr 1956 (zwischen dem 01.01.1956 und 31.12.1956 einschließlich) ermittelt wurde. Hinweis: Datumsangaben können mit Hilfe der Operatoren <, <=, >, >= und = verglichen werden.

Aufgabenstellung

Formulieren Sie die folgende Anfrage im Tupelkalkül. Zusätzlich soll das Schema aller freien Variable angegeben werden.

$Agenten(\underline{ANr},Name)$ $Eins\ddot{a}tze(\underline{EName},Datum,Ort,Zielperson)$ $Decknamen(\underline{Deckname},ANr)$ $nimmt-teil(\underline{EName},\underline{Deckname},Bezahlung)$

Lösung

$$Schema(ein)=Schema(Eins\ddot{a}tze)$$ $$\{[ein.Zielperson]|ein\in Eins\ddot{a}tze,(\exists nt\in \text{nimmt teil}):$$ $$nt.Deckname=\text{"007"}\wedge$$ $$\mathrm{01.01.1956}\le ein.Datum\wedge ein.Datum\le \mathrm{31.12.1956}$$

---

Aufgabe 3 Relationale Algebra

(a) Gegeben seien die zwei Relationen R und S. Bilden Sie die folgenden Operationen durch Verwendung der fünf relationalen Grundoperationen (Vereinigung. Differenz, Kartesisches Product. Selektion, Projektion) nach

1. Durchschnitt

Lösung

$$R\cap S=\{t|t\in Rundt\in S\}$$ $$oder$$ $$R\cap S=R-(R-S)$$ $$oder$$ $$R\cap S=(R\cup S)-((R-S)\cup (S-R))$$

2. Join mit Bedingung $\varphi$

Lösung

$$R\underset{\varphi }{\bowtie }S={\sigma }_{\varphi }(R\times S)$$

3. Quotient

Lösung

$$R÷S={\pi }_{R{}^{\prime }}(R)-{\pi }_{R{}^{\prime }}(({\pi }_{R{}^{\prime }}(R)\times S)-R)$$

(b) Gegeben sind nun folgende Relationen

Aufgabenstellung

• $Personen(\underline{PersId},Name,Verm\ddot{o}gen)$
• $Wohnung(\underline{WhgId},ort,Wohnfl\ddot{a}che,Besitzer)$

Hierbei verweist das Attribute Besitzer in Wohnung auf das Attribute Persld in Personen. Formulieren Sie die folgenden Anfragen in der relationalen Algebra.

1. Ermitteln Sie die Namen und das Vermögen aller Personen, die eine Wohnung in Hamburg und in München besitzen.

Lösung

$$P_{M\ddot{u}nchen}={\Pi }_{Name,Verm\ddot{o}gen}({\sigma }_{\text{ort="Mu¨nchen"}}(Personen\underset{Besitzer=PersId}{\bowtie }Wohnung)$$ $$P_{Hamburg}={\Pi }_{Name,Verm\ddot{o}gen}({\sigma }_{\text{ort="Hamburg"}}(Personen\underset{Besitzer=PersId}{\bowtie }Wohnung)$$ $$P_{M\ddot{u}nchen\cap Hamburg}=P_{M\ddot{u}nchen}\cap P_{Hamburg}$$

2. Bestimmen Sie die Ids aller Personen, die keine Wohnung besitzen

Lösung

$${\Pi }_{PersId}(Personen)\backslash {\Pi }_{PersId}(Personen\underset{Besitzer=PersId}{\bowtie }Wohnung)$$

---

Aufgabe 4 ER-Modell

Note

ER-Modellierung (8 Punkte) Stadt, Land, Fluss einmal anders: Die relationale Datenbank eines geographischen Informationssystems beinhaltet Städte, Länder und Flüsse mit folgenden Einzelheiten:

• Eine Stadt wird durch ihren Namen und das Land gekennzeichnet, in dem sie liegt. Außerdem hat jede Stadt eine Einwohnerzahl.
• Ein Land hat einen eindeutigen Namen, eine Fläche und ebenfalls eine Einwohnerzahl. Ein Land kann an mehrere Länder angrenzen. In einem Land liegt mindestens eine Stadt, wobei jede Stadt nur in genau einem Land liegt. Außerdem hat jedes Land eine Hauptstadt.
• Ein Fluss wird durch seinen Namen bestimmt und hat eine gewisse Länge. Jeder Fluss kann durch mehrere Städte und auch durch mehrere Länder fließen. Hierbei wird gespeichert, wie viele Kilometer ein Fluss ein Land durchfließt. Des Weiteren kann ein Fluss in einen anderen Fluss münden, in den auch weitere Flüsse münden können. Eine Stadt kann an mehreren Flüssen liegen und durch ein Land können mehrere Flüsse fließen.

Erstellen Sie ein Entity-Relationship-Diagramm für die oben beschriebene Datenbank. Markieren Sie die Funktionalitäten der Relationships und unterstreichen Sie den Primärschlüssel jeder Entität. Vermeiden Sie es, zusätzliche, nicht geforderte Attribute einzuführen.

Nutzen Sie also Grundlage für das Entity-Relationship-Diagramm nur die unten aufgeführten Entitäten.

> Scrollen und zoomen mit STRG gedrückt >Auf das 3. Icon von links klicken falls Skizze nicht zu sehen ist

Lösung

---

Aufgabe 5 Transaktionen

Aufgabenstellung

Gegeben sei der folgende Schedule:

$$S_1=(w_1(c),w_4(a),r_3(b),r_1(d),w_2(e),r_2(c),r_3(e),w_4(d),r_2(a),w_3(e),r_4(b))$$

(a) Geben Sie den Abhängigkeitsgraphen von $S_1$ an. Nutzen Sie hierzu die unten dargestellte Vorlage.

**Lösung **

Tabelle anfertigen zur leichteren Skizze

$$\begin{array}{ccccc}a& b& c& d& e\\ & & w_1& & \\ w_4& & & & \\ & r_3& & & \\ & & & r_1& \\ & & & & w_2\\ & & r_2& & \\ & & & & r_3\\ & & & w_4& \\ r_2& & & & \\ & & & & w_3\\ & r_4& & & \end{array}$$

Scrollen und zoomen mit STRG gedrückt Auf das 3. Icon von links klicken falls Skizze nicht zu sehen ist

(b) Ist der Schedule S, serialisierbar? Falls ja, geben Sie alle möglichen seriellen Schedules an. Falls der Schedule nicht serialisierbar ist, begründen Sie Ihre Antwort.

Lösung

Der Schedule ist serialisierbar, da er zyklenfrei ist

$$T_1\to T_4\to T_2\to T_3$$

(c) Welche Anomalien treten im Schedule $S_2$ auf? Geben Sie für jede Anomalien an, ob diese auftritt und falls ja, bezüglich welchen Objekten. Jede Anomalie kann entweder keinmal, einmal oder mehrmals auftreten.

Aufgabenstellung

Betrachten Sie nun folgenden Schedule:

$$S_2=(r_2(b),r_2(c),w_1(c),r_1(c),w_1(b),r_2(a),w_2(c),r_1(c),r_2(b),w_2(b),w_2(a),w_2(a))$$

Anomalien:

• Dirty Read
• Lost-Update
• Non-repeatable Read

Ultimative Anomalien Zusammenfassung --- Erklärung der Transaktionsanomalien: Lost Update, Dirty Read, Non-Repeatable Read

Lost Update RWW

Bei einem “Lost Update” wird eine Änderung von einer anderen Transaktion überschrieben, ohne dass diese Änderungen wahrgenommen wurden:

$$x=100$$ $$\begin{array}{cc}{T}_1& T_2\\ r(x)& \\ x=x+10& \\ & r(x)\\ & x=x-20\\ w(x)& \\ & w(x)\end{array}$$

• T1 und T2 lesen x (100).
• T1 erhöht x auf 110, aber bevor es schreibt, liest T2 den alten Wert (100) und verringert ihn auf 80.
• T1 schreibt 110, aber T2 überschreibt es mit 80.
• Das führt dazu, dass die Änderung von T1 verloren geht.

$$Merkhilfe:$$ $$\begin{array}{cc}{T}_1& T_2\\ r& \\ & r\\ w& \\ & w\end{array}$$

Dirty Read WRW

Ein “Dirty Read” beschreibt das Lesen von Daten, die von einer anderen Transaktion geändert wurden, aber noch nicht festgeschrieben sind:

$$x=100$$ $$\begin{array}{cc}{T}_1& T_2\\ r(x)& \\ x=x+10& \\ w(x)& \\ & r(x)\\ & x=x-20\\ & w(x)\\ FAIL& \end{array}$$

• T1 erhöht x auf 110 und schreibt.
• T2 liest den neuen Wert 110, verringert ihn auf 90 und schreibt.
• T1 scheitert und macht seine Änderungen rückgängig.
• T2 hat Daten basierend auf einem noch nicht festgeschriebenen Wert geändert.

$$Merkhilfe:$$ $$\begin{array}{cc}{T}_1& T_2\\ r& \\ w& \\ & r\\ & w\\ FAIL& \end{array}$$

Non-Repeatable Read RWR

Ein “Non-Repeatable Read” tritt auf, wenn eine Transaktion denselben Datensatz mehrmals liest und unterschiedliche Werte feststellt:

$$x=100$$ $$\begin{array}{cc}{T}_1& T_2\\ r(x)& \\ & w(x)\\ & x=x+10\\ r(x)& \end{array}$$

• T1 liest x, welches 100 ist.
• T2 ändert x auf 110 und schreibt.
• T1 liest x erneut und findet den Wert 110, anders also beim ersten Mal.

$$Merkhilfe:$$ $$\begin{array}{cc}{T}_1& T_2\\ r& \\ & w\\ r& \end{array}$$

Diese Anomalien verdeutlichen unterschiedliche Risiken und Herausforderungen im Umgang mit Transaktionen in Datenbanksystemen, die es durch geeignete Isolationslevel und Sperrmechanismen zu managen gilt.

Lösung

Merkhile

DR: WRW LU: RWW NRR: RWR

---

Aufgabe 6 Normalformen und Synthesealgorithmus

(a) Gegeben sind die folgenden Relationen, deren funktionale Abhängigkeiten und ihre Schlüsselkandidaten.

1. $R_1(A,B,C,D)$

Aufgabenstellung

Funktionale Abhängigkeiten:

• $(F1)A,C\to B$
• $(F2)B\to D$
• $(F3)D\to A$
• Schlüsselkandidaten: $(A,C),(B,C),(C,D)$

Entscheiden Sie, ob das Relationenschema die 3. Normalform erfüllt und begründen Sie Ihre Antwort.

Lösung

→ Das Relationenschema $R_1(A,B,C,D)$ erfüllt die 3. Normalform. Es existieren keine transitiven Abhängigkeiten zwischen Nicht-Schlüsselattributen. Alle funktionalen Abhängigkeiten, in denen ein Attribute von anderen abhängt, betreffen entweder Schlüsselkandidaten oder sind zwischen Attribute, die Teil von Schlüsselkandidaten sind. Daher gibt es keine Verletzungen der Bedingungen der 3. Normalform.

2. $R_2(A,B,C,D,E)$

Aufgabenstellung

Funktionale Abhängigkeiten:

• $(F1)A,C\to B$
• $(F2)C\to D$
• $(F3)D,E\to B$
• Schlüsselkandidaten: $(A,C,E)$

Entscheiden Sie, ob das Relationenschema die 3. Normalform erfüllt und begründen Sie Ihre Antwort.

Lösung

→ $F_2$ $D$ ist abhängig von partiellem Schlüsselkandidaten und nicht von allen. Dadurch ist die 2.NF nicht gegeben und somit auch nicht die 3.NF

(b) Gegeben sei das Relationenschema $R_3(U,V,W,X,Y,Z)$ sowie die Menge $F$ der zugehörigen nicht-trivialen funktionalen Abhängigkeiten:

Aufgabenstellung

Funktionale Abhängigkeiten:

• $W,X\to Y$
• $V,X,Y\to Z$
• $U,V\to W$
• $X\to U$
• $Z\to V,X$

Bestimmen Sie alle Schlüsselkandidaten der Relation $R_3$ und begründen Sie jeweils, warum es sich um einen Schlüsselkandidaten handelt. Begründen Sie auch, weshalb es keine weiteren Schlüsselkandidaten gibt.

Schlüsselkandidaten für die Relation R_3

Schlüsselkandidat: $\{Z\}$

• Funktionale Abhängigkeiten:
• $W,X\to Y$
• $V,X,Y\to Z$
• $U,V\to W$
• $X\to U$
• $Z\to V,X$

Begründung:

• $Z\to V,X$ deckt $V$ und $X$ ab.
• $X\to U$ ermöglicht, dass $Z$ auch $U$ abdeckt, da $X$ durch $Z$ bestimmt wird.
• $U,V\to W$ und da sowohl $U$ also auch $V$ durch $Z$ bestimmt sind, wird auch $W$ abgedeckt.
• $W,X\to Y$ ermöglicht, dass $Z$ auch $Y$ abdeckt, indem $W$ und $X$ (bereits durch $Z$ bestimmt) verwendet werden.
• $V,X,Y\to Z$ ist redundant, da $Z$ selbst verwendet wird, um alles abzudecken.

Vollständigkeit der Abdeckung: $\{Z{\}}^{+}=\{U,V,W,X,Y,Z\}$

Minimalität: Keine echte Teilmenge von $\{Z\}$ kann die gesamte Relation abdecken.

Schlüsselkandidat: $\{V,X\}$

• Funktionale Abhängigkeiten:
• $W,X\to Y$
• $V,X,Y\to Z$
• $U,V\to W$
• $X\to U$
• $Z\to V,X$

Begründung:

• $X\to U$ deckt $U$ ab.
• $U,V\to W$ deckt $W$ ab, da sowohl $U$ (bereits durch $X$ abgedeckt) also auch $V$ in der Attributmenge enthalten sind.
• $W,X\to Y$ deckt $Y$ ab, da sowohl $W$ (über $U,V$ abgedeckt) also auch $X$ in der Attributmenge enthalten sind.
• $V,X,Y\to Z$ deckt $Z$ ab, sobald $Y$ bestimmt ist.

Vollständigkeit der Abdeckung: $\{V,X{\}}^{+}=\{U,V,W,X,Y,Z\}$

Minimalität: Keine echte Teilmenge von $\{V,X\}$ kann die gesamte Relation abdecken.

Fazit

Die Analyse zeigt, dass sowohl $\{Z\}$ also auch $\{V,X\}$ minimale Schlüsselkandidaten für die Relation $R_3$ sind. Beide Attributmengen decken die gesamte Relation funktional ab und erfüllen die Kriterien der Minimalität für Schlüsselkandidaten.

Warum keine weiteren Kandidaten?

• Attribute allein oder in anderen Kombinationen: Kein einzelnes Attribute außer $Z$ und keine andere Kombination außer $\{V,X\}$ können alle anderen Attribute bestimmen. Beispielsweise reicht $X$ allein nicht aus, um $V$, $W$, $Y$ und $Z$ zu bestimmen. Ebenso kann eine Kombination wie $\{U,V\}$ oder $\{W,X\}$ nicht $Z$ und somit nicht alle Attribute abdecken.
• Redundanzfreie Kombinationen: Alle anderen Kombinationen, die die gesamte Relation abdecken könnten, würden zusätzliche, unnötige Attribute enthalten und somit nicht minimal sein.

---