MySQL Datenbankhandbuch: Tutorial Normalisierung von Datenbanken: Praxisanwendung Normalisierung

44.5 Praxisanwendung Normalisierung

Wir werden nun Herrn Krämers Datenbankentwurf der Prozedur der Normalisierung unterwerfen.

Hier noch einmal der ursprüngliche Datenbankentwurf:


Auftragsnr.     Datum   Kunde                   Artikelnr.      Bezeichnung     Menge
1               1.1.99  1 Schmitt, Bonn         134             Coxorange       4 Kisten
....
4               2.2.99  45 Lehmenn, Jülich      27              Ananas          60 Stück

Hier nun die Datenbank in der 1. Normalform:


AuftrNr.        Datum   KundenNr.       Name    Ort     ArtNr.  Bez.    Menge

Es wurde in der Spalte Kunde die Abhängigkeit von Kundennummer, Name und Ort aufgelöst. Dafür sind weitere Spalten entstanden. Nach der Trennung entspricht der Forderung nach atomaren Werten (von atomos = unteilbar).

Nun folgt die 2. Normalform:


1. Tabelle:     AuftrNr.        Datum   KundenNr.       Name    Ort     

2. Tabelle:     AuftrNr.        ArtNr.  Bez.            Menge

Es wurde die Datenbank in zwei Teile aufgeteilt. Der Grund liegt darin, daß hier verschiedene, unerlaubte Abhängigkeiten in einer Tabelle enthalten sind. Zum einen gehören Kundennummer, Name, Ort (und Anschrift) und Artikelnummer, Bezeichnung und Menge jeweils zusammen. Die Auftragsnummer in der 1. Tabelle ist der sogenannte Primärschlüssel, die Auftragsnummer in der 2. Tabelle ist der Fremdschlüssel. Wir müssen diese beiden Tabellen durch eine Relation miteinander vernüpft betrachten: Kunde x (kauft) Ware y (Siehe ER-Diagramm). Der Vorgang wird mit Kauf bezeichnet und erhält eine laufende Nummer, damit man diese später sauber voneinander trennen kann. Diese laufende Nummer ist die Auftragsnummer, die in beiden Tabellen als Bindeglied enthalten sein muß. Ohne Bindeglied kann man die Waren nicht mehr dem Käufer zuordnen. Die Forderung, daß alle Attribute von dem Schlüssel voll funkional abhängig sein sollten, konnte nur dadurch erfüllt werden, daß die Tabelle in 2 Tabellen aufgeteilt wurde, bei denen die Attribute von ihrem Schlüssel funktional voll abhängig sind. Hierbei war dann der Schlüssel der einen Tabelle auch in der anderen verwendbar, nämlich als Fremdschlüssel.

Die Dritte Normalform ist etwas komplexer:


1. Tabelle:     ArtNr.          Bez.

2. Tabelle:     AuftrNr.        Menge           ArtNr.

3. Tabelle:     AuftrNr.        KundenNr.       Datum

4. Tabelle:     KundenNr.       Name    Ort     (Anschrift...)

Bei dem Versetzen der Datenbank in die 3. Normalform wurde die Forderung nach der Abhängigkeit der Attribute nur vom Schlüsselattribut erfüllt. Es durften zwischen den Attributen keinerlei Abhängigkeiten geben. So ist es z.B. nicht erlaubt gewesen, daß der Name des Kunden von der Artikelnummer abhängig gespeichert wird, oder daß Ort und Datum immer zusammen abgelegt werden. Stattdessen wurden nur die wirklich zusammengehörenden Attribute, wie Kundennummer, Name, Ort, (Anschrift) in einer Tabelle gespeichert, und eines dieser Attribute als Schlüsselattribut definiert. Hier ist es die Kundennummer, die als eindeutiger Schlüssel die Verknüpfung zur Tabelle 3 herstellen kann. Damit also alle Attribute in 4 Tabellen miteinander abfragbar werden, müssen zumindest 2 Tabellen jeweils über einen Primärschlüssel und einen Fremdschlüssel verfügen, während die restlichen beiden nur über einen Primärschlüssel verfügen müssen. Hier nun obige Tabellendefinitionen mit der Angebe der Primärschlüssel (PS) und Fremdschlüssel (FS):


1. Tabelle:     ArtNr.(PS)      Bez.

2. Tabelle:     AuftrNr.(PS)    Menge           ArtNr.(FS)

3. Tabelle:     AuftrNr.(PS)    KundenNr.(FS)   Datum

4. Tabelle:     KundenNr.(PS)   Name    Ort     (Anschrift...)

Anhand dieses Beispiels Herrn Krämers haben Sie nun gelernt, wie man Datenbanken von Anfang an so strukturiert, daß die gefürchteten Anomalien nicht eintreten können. Nun können Sie z.B. mit dem Tutorial Einsteiger Tutorial LINUX MySQL Server fortfahren.

Online Suche im Handbuch