Zweite Normalform - volle funktionale Abhängigkeit der Attribute vom Primärschlüssel

Ein System von Tabellen ist dann in der zweiten Normalform (NF2), wenn die Tabellen in der ersten Normalform sind und wenn zusätzlich alle Nichtschlüssel-Attribute voll funktional vom Primärschlüssel abhängig sind. Umgekehrt formuliert heißt dies: Eine Tabelle ist noch nicht in zweiter Normalform, wenn sie einen zusammengesetzten Primärschlüssel hat und ein Nichtschlüssel-Attribut nicht vom ganzen Primärschlüssel, sondern nur von einem Teilschlüssel abhängt. In diesem Fall wird das Nichtschlüssel-Attribut mit dem Primärschlüssel-Teil, von dem es funktional abhängig ist, in eine eigene Tabelle herausgezogen.

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.

• Der Preis eines Artikels ändert sich jede Minute. Man denke an den Preis eines Artikels, der von Währungsschwankungen abhängt und dessen Preis sich aus dem aktuellen, minutengenauen Währungsverhältnis ergibt. In diesem Fall ist der Preis ein unabhängiges Nicht-Schlüssel-Attribut von Datum und Uhrzeit, ein Artikel kann an einem Tag zu verschiedenen End-Preisen verkauft werden. A_PREIS wäre ein korrektes Attribut in der Tabelle UMSATZ.
• Der Preis eines Artikels ändert sich höchstens einmal pro Tag oder höchstens zu einem Termin in der Woche bzw. zu Monatsbeginn. In diesem Fall ist der Preis nicht von der Uhrzeit, sondern vom Datum abhängig, das Datum ist ein Schlüsselattribut. Derselbe Artikel wird zwar nicht an allen, jedoch an vielen aufeinanderfolgenden Tagen zu demselben Preis verkauft. Damit ist der Preis als Nicht-Schlüssel-Attribut nicht abhängig vom gesamten, zusammengesetzten Schlüssel, sondern bloß abhängig von der Kombination aus Datum und Artikel-Nummer, unabhängig dagegen vom Vertreter. Man würde eine neue Tabelle erstellen, die wie folgt aussieht:

  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.

Man sieht an diesem Beispiel, daß die Frage nach abhängigen Attributen nicht ausschließlich unter mathematischen Gesichtspunkten oder anhand vorhandener Daten entschieden werden kann. Bei Preisen, die über lange Zeiträume stabil sind, könnten die Preise auch in der Artikel-Tabelle belassen werden und bei Preisänderungen ein neuer Artikel eingeführt werden. Ebenso könnten die aktuellen Werte von A_NAME (Hose, Mantel, Oberhemd) in eine schmale, zwei Spalten (Id und Begriff) umfassende Tabelle herausgezogen werden und als Kategorie-Begriffe verwendet werden. Ein Artikel ist dann nur noch durch eine Nummer gekennzeichnet, ihm wird eine Kategorie und ein Preis in ARTIKEL zugeordnet, bei einer Preisänderung wird ein neuer Artikel definiert. Werden dagegen Lagerbestände mitberücksichtigt, so darf diese Technik des 'neuen Artikels' bei einer Preisänderung offenkundig nicht verwendet werden, da das einzelne Objekt nicht verschwunden ist, sondern nur einen anderen Preis erhält.