Sql-und-Xml - Home

Sql-Tutorial

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_NRA_NAMEA_PREISA_STUECKDATUMV_NAMEV_ANSCH
1Oberhemd39,804024.06.1999Meyer, EmilWendeweg 10, 2800 Bremen
2Mantel360,001024.06.1999Meier, FranzKohlstr. 1, 2800 Bremen
3Oberhemd44,207024.06.1999Meyer, EmilWendeweg 10, 2800 Bremen
4Oberhemd44,202025.06.1999Schulze, FritzGemü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_NRV_NRA_NRA_STUECKDATUM
18413124024.06.1999
25016221024.06.1999
38413117024.06.1999
41215112025.06.1999
55016223525.06.1999
68413133524.06.1999
7121513524.06.1999
81215121024.06.1999
98413112025.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_NRV_NRA_NRA_STUECKA_PREISDATUM
18413124039.8024.06.1999
250162210360.0024.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_NRDATUMA_PREIS
    1101.06.199944.20
    1201.06.199939.80
    1125.06.199929.90
    1127.06.199944.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.

© 2003-2017 Jürgen Auer, Berlin.