Wir gehen ein komplettes Beispiel zur Normalisierung einer relationalen Datenbank durch in der einhundertvierundvierzigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

Theoretische Grundlagen

Wir normalisieren Datenbanken um Redundanzen zu vermeiden, die zu Anomalien führen können. Mehr dazu in Podcast-Episode 18.

Grundlagen wie Schlüssel, Kardinalitäten usw. erkläre ich in Podcast-Episode 17.

Merksatz: "The key, the whole key, and nothing but the key."

Beispieldaten

Wir verwenden ein "klassisches" Beispiel, das so oder ähnlich in vielen IHK-Prüfungen genutzt wird.

Umfeld: Kunden bestellen Artikel aus verschiedenen Artikelgruppen.

Ein Kunde kann mehrere Bestellungen durchführen. Eine Bestellung wird immer von genau einem Kunden getätigt.

Zu den Kunden werden Name und Adresse erfasst.

Jede Bestellung hat ein Bestelldatum.

In einer Bestellung können mehrere Artikel enthalten sein. Ein Artikel kann auch in mehreren Bestellungen auftauchen.

Artikel haben eine Bezeichnung und einen Preis.

Ein Artikel kann zu genau einer Artikelgruppe gehören. Eine Artikelgruppe kann mehrere Artikel enthalten.

Artikelgruppen haben eine Bezeichnung und einen Rabatt.

Ausgangssituation (nicht normalisiert)

Alle Bestellungen stehen in einer einzelnen Tabelle. Jede Bestellung steht komplett inkl. mehrerer Artikel in einer Zeile. Die Adresse steht komplett in einem einzigen Attribut.

Beispiele für Probleme: Viele Redundanzen (z.B. Adressen, Artikelbezeichnungen), Sortierung nach Ort ist nicht möglich, Selektion aller gekaufter Fernseher ist nicht möglich.

1. Normalform

Definition: Es gibt 1) nur atomare Attribute und 2) keine Wiederholungsgruppen.

"the key": Alle Datensätze sind eindeutig über einen Primärschlüssel identifizierbar.

Durch 2) werden Redundanzen zunächst eingeführt, da aus einer Zeile nun mehrere Zeilen mit redundanten Inhalten werden.

Vorgehen: Nicht-atomare Attribute auf mehrere Spalten aufteilen. Wiederholungsgruppen auf mehrere Zeilen aufteilen.

Ein Datensatz ist über einen zusammengesetzten Schlüssel aus drei Attributen identifizierbar.

Redundanzen: Kunden-, Bestell- und Artikeldaten sind jeweils mehrfach vorhanden.

Ursache: Tabelle enthält drei Konzepte (Kunde, Bestellung, Artikel), die alle nur von Teilen des Schlüssels abhängen und nicht vom gesamten.

2. Normalform

Definition: (1. Normalform erfüllt und) alle Attribute sind voll funktional vom Primärschlüssel abhängig.

"the whole key": Alle Attribute hängen vom gesamten Schlüssel ab (und nicht nur von seinen Teilen).

Vorgehen: Alle drei Konzepte auf einzelne Tabellen aufteilen. Fremdschlüssel für Referenzen einführen. Zuordnungstabelle Position mit zusammengesetztem Schlüssel aus Fremdschlüsseln einführen.

m:n-Beziehungen werden aufgelöst.

Menge gehört an die Kombination aus Bestellung und Artikel und weder an das eine noch das andere allein.

Redundanzen: Artikelgruppe und Rabatt gehören zusammen und sind mehrfach vorhanden.

Ursache: Rabatt hängt von Artikelgruppe ab und nicht von der Artikelnummer (=transitive Abhängigkeit).

3. Normalform

Definition: (2. Normalform erfüllt und) es gibt keine transitiven Abhängigkeiten.

"and nothing but the key": Kein Nicht-Schlüssel-Attribut hängt von einem anderen Nicht-Schlüssel-Attribut ab.

Vorgehen: Artikelgruppe in eigene Tabelle extrahieren und Fremdschlüssel für Referenz einführen.

1:n-Beziehungen werden aufgelöst.

Ergebnis

Jede Tabelle enthält genau ein Konzept.

Keine Daten sind mehr redundant.

In jeder Tabelle gibt es einen eindeutigen Primärschlüssel.

Fremdschlüssel werden für Referenzen auf Datensätze in anderen Tabellen verwendet.

Literaturempfehlungen

Zum Einstieg ins Thema Datenbanken inkl. Modellierung, Normalisierung und SQL empfehle ich Einstieg in SQL* von Michael Laube.

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Relationale Datenbanken - Häufige Fragen im Fachgespräch

Normalisierung - Häufige Fragen im Fachgespräch

Normalisierung (Datenbank)