Normalisierung Teil 3 die 2. Normalform

von tantetoni2 am 27. Februar 2011 um 10:28 Uhr. »
Kommentare (0)  | Drucken

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, 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.

Merksatz 2. Normalform
Die zu speichernden Daten sind so in Tabellen aufzuteilen, dass jedes Nichtschlüsselattribut voll von einem Primärschlüssel abhängig ist.


zu Teil 1 Normalisierung
zu Teil 2 1. Normalform
zu Teil 4 3. Normalform
zu Teil 5 Eine normalisierte Datenbank

Diesen Beitrag teilen

RSS-Feed  auf Twitter.com teilen  auf delicious.com teilen  auf Digg.com teilen   auf Facebook.com teilen


Kommentare
noch keine Kommentare vorhanden