Am einem Ausschnitt von Beispiel 1 deutlich gemacht, die notwendige Zerlegung von V_NAME und V_ANSCH wird aktuell ignoriert:
U_NR | A_NAME | A_PREIS | A_STUECK | DATUM | V_NAME | V_ANSCH |
---|---|---|---|---|---|---|
1 | Oberhemd | 39,80 | 40 | 24.06.1999 | Meyer, Emil | Wendeweg 10, 2800 Bremen |
2 | Mantel | 360,00 | 10 | 24.06.1999 | Meier, Franz | Kohlstr. 1, 2800 Bremen |
3 | Oberhemd | 44,20 | 70 | 24.06.1999 | Meyer, Emil | Wendeweg 10, 2800 Bremen |
4 | Oberhemd | 44,20 | 20 | 25.06.1999 | Schulze, Fritz | Gemüseweg 3, 2800 Bremen |
Offenkundig ist es wesentlich, welcher Vertreter diesen Umsatz erbracht hat. Also gehört bei einer Umsatz-Zeile die Spalte V_NAME zum Schlüssel mit hinzu. Die Vertreteranschrift V_ANSCH hat jedoch nichts mit dem aktuellen Umsatz zu tun, ist also ein Nicht-Schlüssel-Attribut. V_ANSCH hängt nur von V_NAME, nicht vom einzelnen Umsatz, dessen Datum oder dem beteiligten Artikel ab - im Gegensatz zu A_STUECK, das offenbar für die einzelne Umsatzzeile charakteristisch ist. Also können V_NAME und V_ANSCH in eine kleine Tabelle herausgezogen und um einen Primärschlüssel ergänzt werden, der in eine zusätzliche Spalte hinzugefügt wird.
Wurden die beteiligten 'Handlungspartner' oder die 'agierenden Instanzen' korrekt identifiziert und in eigene Tabellen ausgelagert, so scheint die zweite Normalform trivial zu sein. Denn sie ist automatisch erfüllt, wenn die Attribute, also die Spalten einer Tabelle, 'sinnvoll' zum Primärschlüssel gehören und der Primärschlüssel aus einer Spalte besteht, es also keinen zusammengesetzten Primärschlüssel gibt.
Um ein interessantes Beispiel für die Nicht-Erfüllung der zweiten Normalform zu finden, muß nach einem Beispiel gesucht werden, bei dem ein Attribut scheinbar von einem zusammengesetzten Schlüssel abhängt, eine tiefere Analyse jedoch lehrt, daß das Attribut in Wirklichkeit nur von einem Teilschlüssel abhängt.
Betrachtet man die obige Tabelle, so liegt es nahe, die Artikel mit ihren Preisen in eine eigene Tabelle herauszuziehen und durch eine Spalte mit den Artikelnummern zu ersetzen. Wird dasselbe mit den Vertreter-Informationen durchgeführt, so ergibt sich die bereits bekannte Tabelle UMSATZ:
UMSATZ_NR | V_NR | A_NR | A_STUECK | DATUM |
---|---|---|---|---|
1 | 8413 | 12 | 40 | 24.06.1999 |
2 | 5016 | 22 | 10 | 24.06.1999 |
3 | 8413 | 11 | 70 | 24.06.1999 |
4 | 1215 | 11 | 20 | 25.06.1999 |
5 | 5016 | 22 | 35 | 25.06.1999 |
6 | 8413 | 13 | 35 | 24.06.1999 |
7 | 1215 | 13 | 5 | 24.06.1999 |
8 | 1215 | 12 | 10 | 24.06.1999 |
9 | 8413 | 11 | 20 | 25.06.1999 |
Es gibt also Artikel mit festen Preisen, ein eindeutiger Schlüssel in der Tabelle UMSATZ ist eine Kombination aus V_NR, A_NR, A_STUECK und DATUM. Da sich eine solche Aufteilung gut eignet, um Erfahrungen mit dem Sql-Select-Befehl zu sammeln, wurde diese Normalisierung den befehlsbezogenen Beispielen zugrundegelegt.
Ein Problem dieser zunächst plausiblen Aufteilung wird deutlich, falls sich der Preis eines Artikels ändert. Wird dies direkt in der Tabelle ARTIKEL durchgeführt, so werden auch bereits abgeschlossene Verkäufe geändert, dies ist offenkundig falsch. Um dieses Problem zu vermeiden, könnte man den Preis in der UMSATZ-Tabelle belassen, also die folgende Tabelle verwenden:
UMSATZ_NR | V_NR | A_NR | A_STUECK | A_PREIS | DATUM |
---|---|---|---|---|---|
1 | 8413 | 12 | 40 | 39.80 | 24.06.1999 |
2 | 5016 | 22 | 10 | 360.00 | 24.06.1999 |
Damit ist A_PREIS ein Nichtschlüssel-Attribut in der Tabelle UMSATZ. Würden nach diesem Muster viele Einzelumsätze aufgezeichnet werden, so sind zwei Alternativen denkbar.
A_NR | DATUM | A_PREIS |
---|---|---|
11 | 01.06.1999 | 44.20 |
12 | 01.06.1999 | 39.80 |
11 | 25.06.1999 | 29.90 |
11 | 27.06.1999 | 44.20 |
Hier sind A_NR und DATUM die beiden Schlüsselspalten, A_PREIS ist Nicht-Schlüsselattribut. Der Artikel mit der Nummer 11 wurde am 25.06.1999 für zwei Tage mit einem reduzierten Preis angeboten. Die Tabelle UMSATZ behält die Spalten A_NR sowie DATUM, die Spalte A_PREIS wird entfernt.