MySQL - Normalisierung - 2. Normalform

1. Bedingung

Eine Datenbank/Relation befindet sich dann in der zweiten Normalform (2NF), wenn die erste Normalform erfüllt ist und für jeden Primärschlüssel eindeutige Attributwerte vorhanden sind. Schauen wir uns mal an, was von unserer ursprünglichen Tabelle noch übrig geblieben ist.

2. Unser Tabelle Bestellung

+--+------------+------+------+------+
|id|produkt     |preis |nummer|anzahl|
+--+------------+------+------+------+
| 1|Schlagbohrer|199.95|1000-1|1     |
| 2|Zement      |  5.95|1000-2|5     |
| 3|Kneifzange  | 19.95|1000-3|3     |
| 4|Brecheisen  | 49.95|1000-4|7     |
| 5|Hammer      | 19.95|1000-5|4     |
| 6|Zement      |  5.95|1000-2|9     |
| 7|Brecheisen  | 49.95|1000-4|2     |
+--+------------+------+------+------+

Sofort erkennt das geübte Auge, dass wir bestimmte Artikel (Zement, Brecheisen) doppelt eingetragen haben. Damit verstoßen wir gegen die zweite Normalform. Also gliedern wir die Produkte in eine separate Tabelle aus. Damit können wir jedem Primärschlüssel eindeutige Attribute zuordnen.

Tabelle Produkt

+--+------------+------+------+
|id|produkt     |preis |nummer|
+--+------------+------+------+
| 1|Schlagbohrer|199.95|1000-1|
| 2|Zement      |  5.95|1000-2|
| 3|Kneifzange  | 19.95|1000-3|
| 4|Brecheisen  | 49.95|1000-4|
| 5|Hammer      | 19.95|1000-5|
+--+------------+------+------+

3. Redundanzfreiheit

Der ein oder andere wird jetzt einwenden, dass wir aber doppelte Preise haben, also bei der Kneifzange und beim Hammer. Das stimmt, aber ist es sinnvoll, die Preise noch mal in eine eigene Tabelle zu packen? Bei 500 Produkten mit 400 verschiedenen Preisen? Was passiert zum Beispiel, wenn der Schlagbohrer auf einmal 209,95 kostet. Dann müssten wir erst die Tabelle Preise durchwühlen, sehen, ob der entsprechende Eintrag vorhanden ist, wenn ja, neue Verknüpfung, wenn nein, Preis anlegen und dann verknüpfen. Und erst die Abfragen. Redundanzfreiheit bedeutet auch immer ein Verlust von Geschwindigkeit.

4. Denormalisierung

Das ist ein gebräuchliches Mittel, um Performance-Verbesserungen bei der Datenbank zu erzielen. Man nimmt dabei bewusst Redundanzen in Kauf. Aber wann tut man das? Gute Frage, da weiß ich selber keine genaue Antwort. Ich glaube, dass es eine Frage der Erfahrung ist. Im Laufe der Zeit entwickelt man genug Routine, um das zu entscheiden. Bei Produktpreisen oder zum Beispiel beim Bestelldatum kann man aber getrost solche Redundanzen in Kauf nehmen.

zurück zum vorherigen Abschnitt weiter zum nächsten Abschnitt