Normalformen
Nur atomare Attributwerte
Titelliste, Interpret und Album liegen nicht atomar vor,
sondern sind in einem Attribut "kombiniert" gespeichert.
Man kann Titel oder Interpreten hier nicht direkt abfragen,
sondern muss innerhalb des Abfrageergebnisses weiter
"trennen".
Alle wesentlichen Eigenschaften der modellierten Miniwelt
liegen in getrennten Attributen vor.
Wie "fein"" das sein muss hängt vom Modell ab (Datum?
Tag/Monat/Jahr?)
1. Normalform und Nicht-Schlüsselattribute sind von
keinem Teil eines Schlüssels abhängig.
(Einfacher aber ungenauer: "Für jeden Primärschlüssel sind alle
Attributwerte eindeutig"")
Redundante Speicherung der Attributwerte für Albumtitel, Interpret → Notwendigkeit mehrfacher Änderungen. Gefährdung der Integrität.
Überführung in 2. Normalform durch Aufteilung in mehrere Tabellen → eine Tabelle pro Entität.
Die 2NF entsteht oft schon "automagisch"" beim DB-Design mit einem ER-Diagramm, wenn man beim Überführen in Relationen den Grundsatz
1 Entität ↔ 1 Tabelle
einhält und die Attribute hinreichend atomar wählt.
2. Normalform erfüllt und kein Nichtschlüsselattribut hängt von einem Schlüsselattribut transitiv ab.
Man kann schließen: CD_ID
→
Interpret
→ Gründungsjahr
Wenn man den Interpreten kennt, ist das Gründungsjahr immer
gleich.
Das Gründungsjahr hängt "transitiv" über den Interpreten vom
Schlüsselattribut CD_ID
ab - das erzeugt eine
Redundanz!
Überführung in 3. Normalform durch Einführung einer weiteren Tabelle.
3NF verhindert bei guter Modellierung Redundanzen und Anomalien und sorgt dadurch für Zielerreichung unter den Gesichtspunkten Redundanz, Performance und Flexibilität.
3NF verhindert bei guter Modellierung Redundanzen und Anomalien und sorgt dadurch für Zielerreichung unter den Gesichtspunkten Redundanz, Performance und Flexibilität.
3NF kann gut erweitert werden, um neue Anforderungen des Modells zu erfüllen, ohne die Konsistenz zu zerstören.
SQL-Abfragen werden durch weitere Normalisierung komplexer, weil noch mehr Tabellen abgefragt und verknüpft werden müssen.