Normalisierung: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
Keine Bearbeitungszusammenfassung |
||
| Zeile 6: | Zeile 6: | ||
Es gibt verschiedene Grade der Normalisierung: Die so genannte erste, zweite, dritte usw. Normalform. Diese Normalformen sind durch formale Anforderungen definiert. | Es gibt verschiedene Grade der Normalisierung: Die so genannte erste, zweite, dritte usw. Normalform. Diese Normalformen sind durch formale Anforderungen definiert. | ||
Man bringt ein relationales Schema in eine Normalform, indem man für sie geltende [[funktionale Abhängigkeit]]en in einfachere Relationen zerlegt, bis keine weitere Zerlegung mehr möglich ist. Dabei dürfen jedoch keine Daten verloren gehen. | |||
Man bringt ein relationales Schema in eine Normalform, indem man für sie geltende funktionale | |||
Normalisiert wird vor allem in der Phase des Entwurfs einer [[Relationale Datenbank|relationalen Datenbank]]. Ein exakter Modellentwurf, wie das [[Entity-Relationship-Modell]] (ERM), macht eine Normalisierung eigentlich überflüssig, kann aber eingesetzt werden, um Anomalien zu beseitigen oder Redundanzen nachträglich zu minimieren. | Normalisiert wird vor allem in der Phase des Entwurfs einer [[Relationale Datenbank|relationalen Datenbank]]. Ein exakter Modellentwurf, wie das [[Entity-Relationship-Modell]] (ERM), macht eine Normalisierung eigentlich überflüssig, kann aber eingesetzt werden, um Anomalien zu beseitigen oder Redundanzen nachträglich zu minimieren. | ||
| Zeile 48: | Zeile 46: | ||
== Die 2. Normalform (2NF) == | == Die 2. Normalform (2NF) == | ||
Ein Relationenschema ist in der 2. Normalform (kurz '''2NF'''), wenn es in der 1. Normalform ist und jedes Nicht-Schlüsselattribut von einem [[Primärschlüssel]] [[Funktionale_Abhängigkeit|vollständig funktional abhängig]] ist. | Ein Relationenschema ist in der 2. Normalform (kurz '''2NF'''), wenn es in der 1. Normalform ist und jedes Nicht-Schlüsselattribut von einem [[Primärschlüssel]] [[Funktionale_Abhängigkeit#Volle_funktionale_Abhängigkeit|vollständig funktional abhängig]] ist. | ||
Zunächst muss also ein Primärschlüssel definiert werden. In diesem Beispiel lässt sich aber keine Attributkombination finden, für die sich immer jeder Datensatz identifizieren lässt. Denn es ist denkbar, dass ein Kunde beim gleichen Mitarbeiter am gleichen Datum zwei Friseurtermine wahrnimmt. | Zunächst muss also ein Primärschlüssel definiert werden. In diesem Beispiel lässt sich aber keine Attributkombination finden, für die sich immer jeder Datensatz identifizieren lässt. Denn es ist denkbar, dass ein Kunde beim gleichen Mitarbeiter am gleichen Datum zwei Friseurtermine wahrnimmt. | ||
Version vom 16. April 2026, 14:30 Uhr
Einführung
Unter Normalisierung eines relationalen Datenbankmodells versteht man die Aufteilung von Attributen in mehrere Relationen (Tabellen) mithilfe der Normalisierungsregeln und deren Normalformen, sodass ein Schema entsteht, das keine vermeidbaren Redundanzen mehr enthält.
Das Ziel ist die redundanzfreie Datenspeicherung. Ein Schema, das Redundanzen enthält, kann dazu führen, dass bei Änderungen die mehrfach enthaltenen Daten nicht konsistent, sondern nur teilweise und unvollständig geändert werden. Hierdurch können die Datenänderungen überflüssig oder widersprüchlich werden. Außerdem können Anomalien auftreten. Zudem belegt das mehrfache Speichern derselben Daten unnötig Speicherplatz.
Es gibt verschiedene Grade der Normalisierung: Die so genannte erste, zweite, dritte usw. Normalform. Diese Normalformen sind durch formale Anforderungen definiert.
Man bringt ein relationales Schema in eine Normalform, indem man für sie geltende funktionale Abhängigkeiten in einfachere Relationen zerlegt, bis keine weitere Zerlegung mehr möglich ist. Dabei dürfen jedoch keine Daten verloren gehen.
Normalisiert wird vor allem in der Phase des Entwurfs einer relationalen Datenbank. Ein exakter Modellentwurf, wie das Entity-Relationship-Modell (ERM), macht eine Normalisierung eigentlich überflüssig, kann aber eingesetzt werden, um Anomalien zu beseitigen oder Redundanzen nachträglich zu minimieren.
Beispiel der Normalisierungsschritte
Folgendes Schema wird exemplarisch aus einem denormalisierten Zustand in die 3. Normalform überführt.
Ausgangssituation (Nicht normalisiert)
In diesem Zustand gibt es Attribute mit mehreren Werten (Wiederholungsgruppen bei Termindatum) und nicht atomare Werte (Vor- und Nachname in einem Feld).
| Kundenname | Mitarbeitername | Salon | Termindatum |
|---|---|---|---|
| Klaus Meyer | Sabine Krause | Hammer Haare | 11.10.2012, 14.10.2012 |
| Paula Meyer | Claudia Schrotter | Friedrich List Frisuren | 09.11.2012 |
---
Die 1. Normalform (1NF)
Die 1. Normalform (kurz 1NF) ist erfüllt, wenn jedes Attribut einer Relation einen atomaren Wertebereich aufweist. Eine Relation befindet sich in der ersten Normalform, wenn alle Attribute nur einfache Attributwerte aufweisen. (Beispiel: Die Adresse darf nicht als ein Attribut verwendet werden, sondern muss in PLZ, Ort, Straße und Hausnummer aufgeteilt werden). Zudem darf es keine Wiederholungsgruppen geben.
Zur Bildung der ersten Normalform müssen die nicht atomaren Attribute umgewandelt werden. Dies kann durch Einfügen zusätzlicher Zeilen, Spalten oder neuer Relationen erfolgen.
Umsetzung: Um die 1NF zu erfüllen, müssen für Werte der Spalte Termindatum zusätzliche Zeilen eingefügt werden und die Inhalte der Spalten Mitarbeitername und Kundennamen müssen in jeweils zwei Spalten (MVorname und MNachname bzw. KVorname und KNachname) ausgelagert werden.
| KVorname | KNachname | MVorname | MNachname | Salon | Termindatum |
|---|---|---|---|---|---|
| Klaus | Meyer | Sabine | Krause | Hammer Haare | 11.10.2012 |
| Klaus | Meyer | Sabine | Krause | Hammer Haare | 14.10.2012 |
| Paula | Meyer | Claudia | Schrotter | Friedrich List Frisuren | 09.11.2012 |
Nun befindet sich die Tabelle in der 1NF!
---
Die 2. Normalform (2NF)
Ein Relationenschema ist in der 2. Normalform (kurz 2NF), wenn es in der 1. Normalform ist und jedes Nicht-Schlüsselattribut von einem Primärschlüssel vollständig funktional abhängig ist.
Zunächst muss also ein Primärschlüssel definiert werden. In diesem Beispiel lässt sich aber keine Attributkombination finden, für die sich immer jeder Datensatz identifizieren lässt. Denn es ist denkbar, dass ein Kunde beim gleichen Mitarbeiter am gleichen Datum zwei Friseurtermine wahrnimmt.
Umsetzung: Wird ein künstlicher Primärschlüssel für die Relation definiert, ist die Anforderung automatisch erfüllt. Man erweitert die Tabelle um eine Spalte `IdTermin`. Der künstliche Primärschlüssel generiert einen Autowert, anhand dessen sich jede Spalte eindeutig identifizieren lässt.
| IdTermin | KVorname | KNachname | MVorname | MNachname | Salon | Termindatum |
|---|---|---|---|---|---|---|
| 1 | Klaus | Meyer | Sabine | Krause | Hammer Haare | 11.10.2012 |
| 2 | Klaus | Meyer | Sabine | Krause | Hammer Haare | 14.10.2012 |
| 3 | Paula | Meyer | Claudia | Schrotter | Friedrich List Frisuren | 09.11.2012 |
Die Relation erfüllt nun die Anforderungen der 2NF. Sie befindet sich in der 1NF und es gibt kein Attribut in der Tabelle, das sich nicht eindeutig und voll funktional durch den Primärschlüssel IdTermin bestimmen lässt.
---
Die 3. Normalform (3NF)
Ein Relationenschema befindet sich in der 3. Normalform (kurz 3NF), wenn es in der 2NF ist und kein Attribut, das nicht zum Primärschlüssel gehört, von diesem transitiv abhängt.
Betrachten wir die Relation aus der 2NF: Mit Hilfe des Primärschlüssels `IdTermin` lässt sich eindeutig der Vorname eines Mitarbeiters, eines Kunden oder eines Salons bestimmen. Allerdings hängt der Salonname von der Salonnummer (SNR) ab und nur transitiv von `IdTermin`. Gleiches gilt für Kunden (KNR -> KVorname, KNachname) und Mitarbeiter (MNR -> MVorname, MNachname).
Umsetzung: Um das Schema in die 3NF zu überführen, müssen Kunden-, Mitarbeiter- und Saloninformationen in eine eigene Relation ausgelagert werden.
Tabelle: Salon
| SNR | Salonname |
|---|---|
| 1 | Hammer Haare |
| 2 | Friedrich List Frisuren |
Tabelle: Mitarbeiter
| MNR | MVorname | MNachname | FK_SNR |
|---|---|---|---|
| 1 | Sabine | Krause | 1 |
| 2 | Claudia | Schrotter | 2 |
Tabelle: Kunde
| KNR | KVorname | KNachname |
|---|---|---|
| 1 | Klaus | Meyer |
| 2 | Paula | Meyer |
Tabelle: Termin
| IdTermin | FK_KNR | FK_MNR | Termindatum |
|---|---|---|---|
| 1 | 1 | 1 | 11.10.2012 |
| 2 | 1 | 1 | 14.10.2012 |
| 3 | 2 | 2 | 09.11.2012 |
Das Schema befindet sich nun in der 3NF. Es herrschen nur direkte vollfunktionale Abhängigkeiten. Durch Fremdschlüsselbeziehungen bleibt der Bezug der Daten untereinander erhalten. Das Ziel der redundanzfreien Datenhaltung ist erreicht.