Warum Normalformen?

Redundanzen im DB-Schema erzeugen Anomalien in Datenbanksystemen
- Änderungsanomalie → Wenn eine Änderung vergessen wird, entsteht eine Inkonsistenz.
- Einfügeanomalie → Das Einfügen eines partiellen Eintrags ist nicht möglich.
- Entfernungsanomalie → Das Entfernen des letzten Eintrags löscht ungewollt Informationen.
Ziele:
- Vermeidung von Redundanzen und Anomalien.
- Schrittweise Beseitigung funktionaler Abhängigkeiten (außer vom gesamten Schlüssel).

→ Zerlegen des Schemas in ein äquivalentes Schema ohne Redundanzen und Anomalien ist gleichbedeutend mit der Normalisierung.

Funktionale Abhängigkeiten

Seien 𝑋, 𝑌 Attributmengen des Relationenschemas 𝑅, d.h. 𝑋, 𝑌 ⊆ 𝑅. Y ist von X funktional abhängig (oder X bestimmt Y funktional), das heißt 𝑋 → 𝑌 gilt genau dann, wenn für alle möglichen Ausprägungen von R gilt: Zu jedem Wert in X existiert genau ein Wert in Y. Formal ausgedrückt: 𝑋 → 𝑌 ⇔ ∀𝑟1, 𝑟2 ∈ 𝑅: 𝑟1.𝑋 = 𝑟2.𝑋 ⇒ 𝑟1.𝑌 = 𝑟2.𝑌.

Beispiele für funktionale Abhängigkeiten

Triviale funktionale Abhängigkeit: 𝑋 → 𝑌, falls 𝑌 eine Teilmenge von 𝑋 ist. Beispiel: Passnummer → Passnummer.
Voll funktionale Abhängigkeit: 𝑋 → 𝑌, falls keine echte Teilmenge 𝑋’ von 𝑋 existiert, sodass 𝑋’ → 𝑌. Beispiel: Passnummer → Name.
Partiell funktionale Abhängigkeit: Wenn eine Teilmenge 𝑋’ von 𝑋 existiert, sodass 𝑋’ → 𝑌. Beispiel: Passnummer, Land → Name.
Transitive funktionale Abhängigkeit: Wenn 𝑋 → 𝑌 und 𝑌 → 𝑍, dann gilt auch 𝑋 → 𝑍. Beispiel: Passnummer → Ort, da Passnummer → PLZ und PLZ → Ort.

Schlüssel

Eine Teilmenge 𝑆 der Attribute eines Relationenschemas 𝑅 heißt Schlüssel, falls gilt:

Eindeutigkeit: Keine mögliche Ausprägung von 𝑅 kann zwei verschiedene Tuple enthalten, die sich in allen Attribute von 𝑆 gleichen.
Minimalität: Keine echte Teilmenge von 𝑆 erfüllt bereits Bedingung (1). Ein Attribute heißt primär, falls es Teil eines Schlüsselkandidaten ist.

Attributhülle

Eingabe: Eine Menge F von funktionalen Abhängigkeiten und eine Menge X von Attribute. Ausgabe: Die vollständige Menge von Attribute 𝑋+ für die gilt 𝑋 → 𝑋+, also die Menge an Attribute, die man von X mit allen F herleiten kann. Solange es Änderungen an 𝑋+ gibt, geht man jede FD 𝑌 → 𝑍 aus F durch. Wenn die linke Seite eine echte Teilmenge von aktueller 𝑋+ ist, dann ist Z in der neuen 𝑋+.

Zerlegung von Relationen

Eine Zerlegung von Relation 𝑅 in 𝑅1, … , 𝑅𝑛 ist:

Verlustlos, falls gilt: Jede mögliche Ausprägung 𝑟 von 𝑅 lässt sich durch den natürlichen Join der Ausprägungen 𝑟1, … , 𝑟𝑛 konstruieren: 𝑟 = 𝑟1 ⋈ ⋯ ⋈ 𝑟𝑛.
Abhängigkeitserhaltend, falls gilt: Alle FD ∈ F auf 𝑅 bleiben in den lokalen funktionalen Abhängigkeiten Fi bewahrt: F = F1 ∪ ⋯ ∪ Fn.

Normalformen Erklärvideo

1. Normalform (1NF)

Merkhilfe

Alle Attribute sind atomar

Was die 1NF bricht

Die Verwendung der Zeilenreihenfolge zur Übermittlung von Informationen verstößt gegen die 1.NF.

Gemischte Datentypen innerhalb von Spalten.

Eine Tabelle ohne Primärschlüssel.

Wiederholende Gruppen sind in Spalten nicht erlaubt (z.B. Inventory1, Inventory2,…).

Erklärung:

Alle Attribute enthalten atomare Werte (String, Integer, …) und keine Tuple, Listen, usw. In relationalen Datenbanken sind nicht-atomare Werte nicht erlaubt/möglich, daher sind relationale Datenbanken immer in 1. Normalform.

→ In dieser Vorlesung oft schon erfüllt.

2. Normalform (2NF)

Merkhilfe

1.NF +

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

$⟹$ ! Transitive Abhängigkeiten zwischen nicht Schlüsselkandidaten sind erlaubt, nur falls eine Abhängigkeit zu einem Schlüsselkandidaten besteht muss eine Abhängigkeit zu allen Schlüsselkandidaten auch bestehen!

(Each non-key attribute must depend on the entire primary key)

Was die 2NF bricht

Nicht alle Nicht-Primärattribute hängen vollständig von jedem Teil des Schlüssels ab.

Attribute, die nicht vom Schlüssel abhängen, sollten nicht in der gleichen Tabelle sein.

Erklärung:

Für jedes Attribute A in einer Relation gilt in der 2. Normalform, dass:

A ein Primärattribut ist (also Teil eines Schlüsselkandidaten) oder
A voll funktional abhängig von jedem Schlüsselkandidaten ist.

Primärattribut bedeutet, dass das Attribute Teil eines Schlüsselkandidaten ist. Ein Schlüsselkandidat ist eine minimale Menge von Attribute, die eindeutig jede Tuple in einer Relation identifizieren kann.

Voll funktional abhängig bedeutet, dass die Abhängigkeit zwischen einem Attribute und einem Schlüsselkandidaten komplett ist. Das heißt, das Attribute kann nur eindeutig identifiziert oder abgeleitet werden, wenn der gesamte Schlüsselkandidat bekannt ist, nicht nur ein Teil davon.

Die 2NF beseitigt partielle funktionale Abhängigkeiten von Nicht-Primärattributen von einem Teil eines zusammengesetzten Schlüssels, indem sichergestellt wird, dass jedes Nicht-Primärattribut vollständig von jedem Schlüsselkandidaten abhängt. Das führt zu einer Reduzierung von Redundanzen und Anomalien bei der Datenmanipulation.

Ein einfaches Beispiel für die 2. Normalform (2NF) in einer Datenbank könnte eine Tabelle für Studentenleistungen sein:

Student_ID	Vorname	Nachname	Kurs_ID	Kursname	Dozent_ID	Dozent_Name
001	Max	Mustermann	101	Mathematik	201	Dr. Schmidt
002	Maria	Müller	102	Englisch	202	Prof. Wagner
003	Ali	Khan	101	Mathematik	201	Dr. Schmidt

In diesem Beispiel ist die Spalte “Student_ID” ein Primärattribut, da sie Teil des Schlüssels ist und jede Zeile eindeutig identifiziert. Die Spalten “Kurs_ID” und “Dozent_ID” sind ebenfalls Teil des Primärschlüssels.

Um sicherzustellen, dass die Tabelle die 2NF erfüllt, müssen wir prüfen, ob jedes Nicht-Primärattribut voll funktional von jedem Schlüsselkandidaten abhängt.

In diesem Fall hängt der “Kursname” von der “Kurs_ID” ab, und der “Dozent_Name” hängt von der “Dozent_ID” ab. Beide erfüllen die Anforderungen der 2NF, da sie voll funktional von ihren jeweiligen Schlüsselattributen abhängen.

Die 2NF ist wichtig, um Redundanzen zu vermeiden und die Datenintegrität zu gewährleisten, indem partielle funktionale Abhängigkeiten eliminiert werden.

3. Normalform (3NF)

Merkhilfe

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

Z.B. $R = (\underline{A}, B, C, D)$ 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 (Beispiel aus Klausur WS23-24)

Every non-key attribute in a table should depend on the key,the whole key, and nothing but the key

BCNF: Every ~~non-key~~ attribute in a table should depend on the key,the whole key, and nothing but the key

Was die 3NF bricht

Transitive Abhängigkeiten von Nicht-Schlüsselattributen.

Nicht-Schlüsselattribute, die nicht direkt vom Primärschlüssel abhängen, sondern von anderen Nicht-Schlüsselattributen.

Fehlende Normalisierung von wiederholten Gruppen von Attribute in separate Tabellen.

$E r f \overset{u}{¨} llt 3. NF S c h l \overset{u}{¨} sse l kan d i d a t e n mn r, f z n r \to ba u jah r, km - s t an d, n - p re i s, h - p re i s, e k - p re i s$

>

\underbrace{hnr → hersteller}_{\text{Erfüllt nicht 3. NF, da linke Seite kein Schlüsselkandidat bzw. rechts kein primäres Attribut}}

\underbrace{SK \rightarrow A}_{\text{Erfüllt BCNF, da linke Seite ein Superkey}}

>

\underbrace{X \rightarrow Y}_{\text{Erfüllt nicht BCNF, da X kein Superkey}}

Die **Boyce-Codd-Normalform (BCNF)** ist eine Verschärfung der 3. Normalform, die zusätzlich verlangt, dass: - 3.NF ist erfüllt - *Für alle nicht-trivialen funktionalen Abhängigkeiten 𝑋 → 𝑌 in einer Relation, muss 𝑋 ein Superkey sein*. bzw. *𝑋 enthält Schlüsselkandidaten.* - Ein *Superkey* ist eine Attributkombination, die so erweitert ist, dass sie alle Attribute in einer Relation eindeutig identifiziert. Jeder Superkey ist auch ein Schlüsselkandidat, aber nicht jeder Schlüsselkandidat ist ein Superkey. BCNF zielt darauf ab, verbleibende Anomalien zu beseitigen, die in 3NF noch möglich sind, insbesondere solche, die aus funktionalen Abhängigkeiten resultieren, bei denen die linke Seite kein Schlüsselkandidat ist. Dies stellt sicher, dass keine Abhängigkeiten von Nicht-Superkeys zu anderen Attribute bestehen, wodurch Redundanzen und Anomalien weiter reduziert werden. [[DBS-Blatt 10#aufgabe-10-4-normalformen-boycecodd-normalform-bcnf|Anwendungsbeispiel]] <details> <summary>### Weiteres Beispiel</summary> Ein Beispiel, das oft zur Illustration von BCNF verwendet wird, betrifft eine Tabelle `Vorlesung` mit folgenden Attribute: - `Dozent` - `Fach` - `Raum` Angenommen, die funktionalen Abhängigkeiten sind wie folgt: - `Dozent, Fach → Raum` - `Raum → Dozent` Hier erfüllt die Tabelle die 3NF, da keine transitiven Abhängigkeiten zwischen Nicht-Schlüsselattributen bestehen. Jedoch ist `Raum` kein Superkey, was zu Redundanz führen kann, da derselbe Dozent in verschiedenen Fächern denselben Raum nutzen könnte. **Um BCNF zu erreichen**, könnte die Tabelle wie folgt aufgeteilt werden: 1. `DozentFach`: - `Dozent` - `Fach` - (Primärschlüssel könnte hier eine Kombination aus Dozent und Fach sein) 2. `RaumZuweisung`: - `Raum` - `Dozent` - (Primärschlüssel wäre hier `Raum`, wenn wir annehmen, dass ein Raum zu einer Zeit nur von einem Dozenten genutzt werden kann) Durch diese Aufteilung wird sichergestellt, dass in jeder Relation alle nicht-trivialen funktionalen Abhängigkeiten von einem Superkey abhängen, wodurch die BCNF erfüllt wird. </details> <!-- DISQUS SCRIPT COMMENT START --> <!-- DISQUS RECOMMENDATION START --> <div id="disqus_recommendations"></div> <script> (function() { // REQUIRED CONFIGURATION VARIABLE: EDIT THE SHORTNAME BELOW var d = document, s = d.createElement('script'); // IMPORTANT: Replace EXAMPLE with your forum shortname! s.src = 'https://myuninotes.disqus.com/recommendations.js'; s.setAttribute('data-timestamp', +new Date()); (d.head || d.body).appendChild(s); })(); </script> <noscript> Please enable JavaScript to view the <a href="https://disqus.com/?ref_noscript" rel="nofollow"> comments powered by Disqus. </a> </noscript> <!-- DISQUS RECOMMENDATION END --> <hr style="border: none; height: 2px; background: linear-gradient(to right, #f0f0f0, #ccc, #f0f0f0); margin-top: 4rem; margin-bottom: 5rem;"> <div id="disqus_thread"></div> <script> /** * RECOMMENDED CONFIGURATION VARIABLES: EDIT AND UNCOMMENT THE SECTION BELOW TO INSERT DYNAMIC VALUES FROM YOUR PLATFORM OR CMS. * LEARN WHY DEFINING THESE VARIABLES IS IMPORTANT: https://disqus.com/admin/universalcode/#configuration-variables */ /* var disqus_config = function () { this.page.url = PAGE_URL; // Replace PAGE_URL with your page's canonical URL variable this.page.identifier = PAGE_IDENTIFIER; // Replace PAGE_IDENTIFIER with your page's unique identifier variable }; */ (function() { // DON'T EDIT BELOW THIS LINE var d = document, s = d.createElement('script'); s.src = 'https://myuninotes.disqus.com/embed.js'; s.setAttribute('data-timestamp', +new Date()); (d.head || d.body).appendChild(s); })(); </script> <noscript>Please enable JavaScript to view the <a href="https://disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript> <!-- DISQUS SCRIPT COMMENT END -->

🎓 MyUniNotes

Explorer

Normalformen und Synthesealgorithmus

Warum Normalformen?

Funktionale Abhängigkeiten

Beispiele für funktionale Abhängigkeiten

Schlüssel

Attributhülle

Zerlegung von Relationen

Normalformen Erklärvideo

1. Normalform (1NF)

Erklärung:

2. Normalform (2NF)

Erklärung:

3. Normalform (3NF)

Graph View

Table of Contents

Backlinks