Datenbank Schema für Gebrauchtwagen

Der Autohändler Huber möchte seinen Bestand gebrauchter Wagen in einem relationalen Datenbanksystem organisieren. Die Anforderungsanalyse ergibt eine ganze Liste zu speichernder Informationen für jedes Fahrzeug, die Huber direkt in ein relationales Schema umsetzt. Sofort beginnt er mit der Erfassung seiner Daten und erhält die folgende Relation Auto:

mnrhnrherstellertyppsfznrbaujahrkm-standn-preish-preisek-preis
11OpelKadett60K674199010000180001300012000
11OpelKadett60K63419883400018000120009000
21OpelVectra90V459199015000250001800017000
31OpelOmega110O634198745000300002200015000
42VWGolf90G789199111000250002100016000
42VWGolf90G713199131000250001600013000
52VWGolf105G762199228000280001900017000
62VWKäfer60K63419867100019000100008000

Die verschiedenen Modelle werden von Huber fortlaufend nummeriert (mnr). Ein bestimmtes Model ist charakterisiert durch Hersteller, Typ und Motorleistung (ps). Für jedes Model ist ferner die Fahrzeugnummer (fznr) eindeutig. Beide Attribute zusammen werden daher also Primärschlüssel gewählt. Nach kurzer Zeit stellt Huber fest, dass ihm seine neue Datenbank nicht so recht Freude machen will, die Datenmodellierung scheint nicht gut durchdacht.

Aufgabe 10-1 Problem bei nicht normalisierten DB

Aufgabenstellung

Beschreiben Sie die Problem (Redundanzen, Anomalien), die bei Nutzung des o.g. Relationenschemas in der Datenbank des Autohandlers auftreten können.

  • Redundanz:
    • Hersteller und hnr geben beide die gleiche Information wieder und sind somit redundant.
    • mnr und typ geben auch die gleichen Daten wieder.
    • ps ist redundant, da es für jede mnr und typ die gleiche Information speichert.
  • Einfügeanomalie:
    • Man kann beispielsweise keinen Hersteller hinzufügen, ohne dass diesem ein Typ vom Auto zugewiesen wird (partielle Einfügung nicht möglich).
  • Entfernungsanomalie:
    • Man kann keinen Typ vom Auto löschen, ohne auch Informationen über den Hersteller zu verlieren.
  • Änderungsanomalie:
    • Änderungen der PS eines Modells müssen in allen Tupeln eingetragen werden, oder bei Änderungen des Namens des Herstellers müssen alle Tuple geändert werden.

Aufgabe 10-2 2. Normalform (2NF)

Aufgabenstellung

Die Menge der vollen und nicht-trivialen funktionalen Abhängigkeiten sei im Folgenden gegeben durch:

  • mnr → hnr, hersteller, typ, ps
  • hnr → hersteller
  • mnr, fznr → baujahr, km-stand, n-preis, h-preis, ek-preis

a) Erläutern Sie, warum das gegebene Schema nicht der 2. Normalform (2.NF) genügt. [2. Normalform (2NF)]

2. NF besagt: - Für jedes Attribute A gilt: - A ist primär oder - A ist voll funktional abhängig von jedem Schlüsselkandidaten.

  • Schlüsselkandidaten sind
  • Voll funktionale Attribute, die von jedem Schlüsselkandidaten abhängig sind, sind

→ Attribute die keine Schlüsselkandidaten sind, sind also Da es also Attribute gibt die nicht prim oder voll funktional abhängig von jedem Schlüsselkandidaten sind und , ist die 2.NF nicht erfüllt

b) Überführen Sie die Relation in die 2.NF und geben Sie die so entstehenden Relationen an.

  1. Relation: Modell - Erstelle eine neue Relation für jeden partiellen Schlüssel mit seinen abhängigen Attribute - mnr → hnr, hersteller, typ, ps - hnr → hersteller
  2. Relation: Fahrzeug - Attribute, die voll funktional vom (ursprünglichen) Schlüssel abhängig sidn, bleiben in der ursprünglichen Relation - mnr, fznr → baujahr, km-stand, n-preis, h-preis, ek-preis

Aufgabe 10-3 3. Normalform (3NF)

Aufgabenstellung

Falls das in Aufgabe 10-2 entstandene Relationenschema noch nicht der 3. Normalform (3.NF) genügt, führen Sie dieses in die 3.NF über und geben Sie die so entstehenden Relationen an. Andernfalls begründen Sie, warum das Relationenschema aus Aufgabe 10-2 bereits der 3.NF genügt.

  • mnr → hnr, hersteller, typ, ps
  • hnr → hersteller
  • mnr, fznr → baujahr, km-stand, n-preis, h-preis, ek-preis

3.NF besagt:

  • 2.NF ist erfüllt.
  • Für alle nicht-trivialen funktionalen Abhängigkeiten 𝑋 → 𝑌 muss 𝑋 einen Schlüsselkandidaten enthalten, oder
  • 𝑌 muss ein Primärattribut sein.

Basierend auf der Musterlösung und der Analyse der Relationen aus Aufgabe 10-2 erkennen wir, dass die Relation Fahrzeug bereits der 3. Normalform entspricht. Die Relation Model hingegen erfüllt die 3. Normalform nicht, da die funktionale Abhängigkeit hnr → hersteller eine transitive Abhängigkeit darstellt, die in 3NF nicht zulässig ist. Um das Schema vollständig in die 3. Normalform zu überführen, wird folgende Anpassung vorgenommen:

Korrigierte und ergänzte Relationen für 3NF:

  1. Relation Fahrzeug bleibt unverändert, da sie bereits die 3NF Kriterien erfüllt:$$ Fahrzeug(\underline{mnr}, \underline{fznr}, baujahr, km-stand, n-preis, h-preis, ek-preis)

    \underbrace{\underbrace{mnr,fznr}{Schlüsselkandidaten}→ baujahr, km-stand, n-preis, h-preis, ek-preis}{Erfüllt \ 3.NF}

  2. Relation Model wird angepasst, um die transitive Abhängigkeit zu entfernen. Dazu wird die Abhängigkeit hnr → hersteller in eine eigene Relation extrahiert:

  3. Neue Relation Hersteller wird eingeführt, um die transitive Abhängigkeit aufzulösen:

Durch diese Änderung wird sichergestellt, dass:

  • Jedes Attribute in Fahrzeug und Model entweder ein Primärattribut ist oder voll funktional von dem Primärschlüssel abhängt, ohne transitive Abhängigkeiten.
  • Die neue Relation Hersteller speichert die Zuordnung zwischen hnr und hersteller, wobei hersteller direkt von hnr abhängig ist und somit die 3NF erfüllt.

Zusammenfassend:

Das überarbeitete Schema erfüllt nun die Kriterien der 3. Normalform. Es wurden alle transitiven Abhängigkeiten entfernt, indem die Informationen in separate Relationen aufgeteilt wurden, wodurch die Datenintegrität und die Reduktion von Redundanzen verbessert werden.

  1. Für die funktionale Abhängigkeit innerhalb der Relation Model:

\underbrace{hnr \rightarrow hersteller}_{\text{Erfüllt \ 3.NF, da die linke Seite (hnr) ein Schlüsselkandidat der Relation Hersteller ist}}

\underbrace{\underbrace{mnr, fznr}{\text{Schlüsselkandidaten}} \rightarrow baujahr, km-stand, n-preis, h-preis, ek-preis}{\text{Erfüllt \ 3.NF}}

--- # Aufgabe 10-4 [[Normalformen und Synthesealgorithmus#boycecodd-normalform-bcnf|Boyce–Codd Normalform (BCNF)]] >[!note] Aufgabenstellung > >Geben Sie ein beliebiges Beispiel an, bei dem das Einhalten der 3.NF noch nicht zu einem "guten" Datenbankdesign führt, sondern erst die Zerlegung in ein der Boyce-Codd-NF genügendes Schema alle Redundanzen beseitigt. **Beispiel:**

FLS={\underline{Fach},Lehrer,\underline{Schüler}}

*Es gilt:* - Jeder Schüler hat einen Lehrer pro Fach: - 𝑆𝑐ℎü𝑙𝑒𝑟, 𝐹𝑎𝑐ℎ → 𝐿𝑒ℎ𝑟𝑒r - Jeder Lehrer Vertritt nur ein Fach (aber zu jedem Fach kann es mehrere Lehrer geben: - 𝐿𝑒ℎ𝑟𝑒𝑟 → 𝐹𝑎𝑐ℎ - X ist primär aber Y primär → <span style="color:red">Kein BCNF</span> [[Normalformen und Synthesealgorithmus#boyce-codd-normalform-bcnf|(siehe Merkhilfe)]] *Schlüsselkandidaten sind:*

SKs = {{Schüler,Fach},{Schüler, Lehrer}}

*Diese funktionalen Abhängigkeiten führen zu den Schlüsselkandidaten:* - {Schüler, Fach}, weil ein Schüler für jedes Fach genau einen Lehrer hat. Dieses Attributpaar kann jede Tuple in der Relation eindeutig identifizieren. - {Schüler, Lehrer}, weil, obwohl ein Lehrer nur ein Fach unterrichtet, ein Schüler bei verschiedenen Lehrern in unterschiedlichen Fächern sein kann. Daher kann die Kombination aus Schüler und Lehrer auch jede Tuple eindeutig identifizieren. ## Normalformen: ### 2.NF: Jedes Attribute ist prim ### 3NF: ((Schüler,Fach) Enthält SK und Fach ist prim) -> auch 2NF und 1NF ### BCNF: (Lehrer enthält keinen SK) → <span style="color:red">Kein BCNF</span> ## Anomalien: - Einfügen: kein Lehrer mit zugehörigem Fach ohne Schüler - Entfernen: mit letztem Schüler wird Info über Lehrer und Fach gelöscht ## BCNF: Die Relationen in BCNF sind:

LehrerFach(\underline{Lehrer}, Fach)

SchülerLehrer(\underline{Schüler}, \underline{Lehrer})

\rightarrow Nicht abhängigkeitserhaltend

### Was bedeutet "nicht abhängigkeitserhaltend"? Eine Zerlegung einer Relation in eine Normalform ist "nicht abhängigkeitserhaltend", wenn nach der Zerlegung nicht alle ursprünglichen funktionalen Abhängigkeiten direkt in den zerlegten Relationen abgebildet werden können. Das bedeutet, dass manche funktionalen Abhängigkeiten möglicherweise nur durch das Joinen mehrerer Relationen rekonstruiert werden können. Dies kann die Integrität und die Konsistenz der Datenbank beeinträchtigen, da zusätzliche Einschränkungen erforderlich sind, um sicherzustellen, dass die ursprünglichen Abhängigkeiten gewahrt bleiben. --- # Aufgabe 10-5 [[Normalformen und Synthesealgorithmus#synthesealgorithmus|Synthesealgorithmus]] >[!note] Aufgabenstellung > >Gegeben sei das Relationenschema `R(A, B, C, D, E, F)`, sowie die Menge `F` der zugehörigen >nicht-trivialen funktionalen Abhängigkeiten: >`{ C, A → D ; C → F, D ; B → A, E ; E → F, A }` ## a) Begründen Sie, warum `{B, C}` der einzige Schlüsselkandidat ist. ### Gedankengang: Abzudecken sind: $A,B,C,D,E,F$ - $B$ deckt folgende ab: $A,E$ - welche wiederum folgende abdecken: $D,F$ - Es fällt also weg $\not A,\not B, C,\not D,\not E,\not F$ und es bleibt nur noch C übrig was keine Herleitung hat - Dies hat zur Folge, dass C auch ein Schlüsselkandidat werden muss - B und C sind die Minimalsten Attribute die alle anderen abdecken. ### Formelle Schreibweise: $$\mathcal{F} = \{C, A \rightarrow D \;|\; C \rightarrow F, D \;|\; B \rightarrow A, E \;|\; E \rightarrow F, A\}
  1. Eindeutigkeit:
  2. Minimalität

1. Bestimmung der kanonischen Überdeckung 𝐹𝑐 zu 𝐹

a) Linksreduktion

    • wird zu da gilt:
      • auch ohne A wird D abgedeckt durch C in 2.

b) Rechtsreduktion

    • wird zu da:

    • D wird abgedeckt durch 2.

    • wird zu

    • A wird abgedeckt durch 4.

c) Entfernung von rechtsleeren Abhängigkeiten

d) Zusammenfassen von Abhängigkeiten mit gleicher linker Seite

2. Erzeugen eines neues Relationenschemas aus 𝐹𝑐

3. Rekonstruktion eines Schlüsselkandidaten:

Neue Relation für Schlüsselkandidaten

4. Elimination überflüssiger Relationen

In diesem Schritt nix zu tun

Finale Relationen: