IT Wissen nicht nur für die Ausbildung

Datenbank Normalisierung

Mit den Methoden der Normalisierung ist es möglich, ein redundanzfreies relationales Modell aus einer Objektsammlung zu erstellen. Hält man diese Regeln ein, ist eine spätere Erweiterung der Datenbank ohne Schwierigkeiten möglich. Welche Normalformen es gib, erfährst du in diesem Beitrag.

Zielsetzung der Normalisierung ist, das jedes Datenfeld nur einmal vorhanden ist. Dadurch werden Redundanzen beseitigt und die Datenkonsistenz bleibt erhalten. Auch sollen alle Abhängigkeiten zwischen den Spalten einer Tabelle beseitigt werden um eine einfache Erweiterung der Datenbank jederzeit gewährleisten zu können.

1. Normalform

Die erste Normalform besagt, dass jede Tabelle eine feste Breite besitzt. Jeder Datensatz hat somit die gleiche Anzahl an Attributen. Zudem muss jedes Attribut atomar, also allein stehend, sein. Dieser Zustand wird erreicht, in dem man den Datensatz in mehrere Tabellen aufteilt bzw. dupliziert.

Jedes Datenfeld darf nur einen Wert enthalten. Anschrift: „Dresdner Str. 15 01574 Nirgendsdorf“ ist also laut Definition unzulässig und muss in Strasse, Hausnummer. PLZ und Ort aufgeteilt werden um die erste Normalform herzustellen.

2. Normalform

Bevor man sich der zweiten Normalform widmet muss die erste erfüllt sein, dies ist Bedingung!

Jede Tabelle enthält nur Daten eines Themengebiets. Sollte dies nicht der Fall sein, müssen die Daten wie in der ersten Normalform weiter aufgeteilt werden.

Jeder Datensatz ist durch einen Primärschlüssel eindeutig identifizierbar. Es muss also für jede Tabelle ein Attribut gefunden werden, dass einmalig ist. Beispiel wäre eine Kundennummer oder eine ISBN-Nummer. Sollte es keine redundanzfreien Werte geben muss eine künstliche Spalte erstellt werden. Beliebt ist in diesem Zusammenhang eine ID-Spalte.

3. Normalform

Es muss erst die vorangegangene zweite Normalform erfüllt sein bevor die dritte in Kraft treten kann.

Alle Datenfelder dürfen nur vom Primärschlüssel abhängen. Es darf daher keine so genannten transitiven (kettenartige) Abhängigkeiten geben. Eine transitive Abhängigkeit besteht immer dann, wenn ein Attribut über ein anderes Attribut (also nicht direkt) vom Primärschlüssel abhängig ist.

Falsche Normalisierung

Sollten die Normalisierungsschritte nicht richtig oder in der richtigen Reihenfolge ausgeführt worden sein, kann es zu Mutationsanomalien kommen. An folgendem Beispiel sind die drei üblichsten Anomalien veranschaulicht:

ArtNr Bezeichnung Kategorie
 
1 Pizza Salami Pizza
2 Pizza Bolognese Pizza
3 Käsecracker Snacks

Änderungs-Anomalie:

Beim ändern der Kategorie „Pizza“ in „Steinofenpizza“ könnte vergessen werden die Bezeichnung bei allen betroffenen Artikeln umzuschreiben. Bzw. könnten Schreibfehler auftreten und so zu Verwirrung und Datendurcheinander führen.

Löschanomalie:
Wenn angenommener Weise die „Käsecracker“ der letzte Artikel in der Kategorie „Snacks“ wären und man jenen Artikel löscht würde im gleichen Zug die Kategorie verschwinden. Es ist in unserem Beispiel also nicht möglich den Artikel zu Löschen ohne die Kategorie zu vernichten.

Einfügeanomalie:
Im Beispiel oben ist es nicht Möglich eine Kategorie hinzuzufügen ohne einen Artikel einzufügen.

Lösung für Einfügeanomalie:
In diesem Fall müsste es eine separate Tabelle „Kategorie“ geben, deren Primärschlüssel als Fremdschlüssel in der Tabelle „Artikel“ auftaucht.

ArtNr Bezeichnung Kategorie
 
1 Pizza Salami 1
2 Pizza Bolognese 1
3 Käsecracker 2
KategorieNr. Bezeichnung
 
1 Pizza
2 Snacks

Ähnliche Artikel

2 Kommentare und Links

  1. loptr

    6. Mai 2011

    geht doch mal weg von diesen furchtbaren numerischen primärschlüsseln!

    die kategorie ist doch schon eindeutig, wozu braucht man dann noch eine numerische zuweisung?

    ARTIKEL {ArtNr PK INT, Bezeichnung VCHAR, Kategorie VCHAR FK(Kategorien.catID)}

    KATEGORIEN {catID PK VCHAR}

    da kann dann wunderschön „pizza“ als kategorie stehen bleiben und man hat die möglichkeit zu kaskadieren. zudem sind die daten deutlich leichter lesbar!

  2. Christian

    6. Mai 2011

    Du hast in diesem Fall Recht. In der Tabelle „Kategorie“ ist die Bezeichnung bereits eindeutig genug. Ich bin mir aber nicht sicher ob es in anderen Anwendungsbereichen nicht auch gleiche Kategorie-Bezeichnungen geben könnte.

Schreibe einen Kommentar

Keine Chance unser IT-Wissen zu verpassen: