Ein Entwickler hat die Aufgabe bekommen, die Datenbank für das Wirtschaftssystem der Firma Failution zu implementieren. Die Firma möchte folgenden Informationen seiner Kunden speichern:

• Kunden
  • Name
  • Firma
  • Adresse
  • Notiz (Hinweis auf offene Rechnung)
• Bestellung
  • Datum
  • Bezahlung schon abgeschlossen - ja/nein?
• Artikel
  • Bezeichnung
  • Details
  • Einzelpreis
  • Auslaufartikel - ja/nein?

Der Entwurf des Entwicklers sieht wie folgt aus:

Die erste Normalform liegt vor, wenn eine Tabelle die folgenden Bedingungen erfüllt:

• Es dürfen keine Spalten mit gleichen Inhalten vorliegen
• Die Werte dürfen nicht weiter teilbar sein (man sagt auch, sie müssen atomar sein)
• Es dürfen keine doppelten Einträge/Zeilen enthalten sein

Der oben angezeigt Entwurf erfüllt keine der drei Bedingungen - die Gründe sind:

• Es sind Spalten mit gleichen Inhalten vorhanden - es gibt zwei Spalten für Kundennotizen und bestellte Artikel: KND_Notiz und KND_Notiz2 sowie ART_1 und ART_2.
• Es gibt Werte, die sich weiter teilen lassen.
  • Das Feld KND_Name lässt sich in zwei seperate Felder für den Vor- und Nachnamen des Kunden aufteilen
  • Das Feld KND_Adresse vereint neben der Adresse auch die Hausnummer, die PLZ und den Ortnamen.
  • Es gibt zwei Felder ART_1 und ART_2 - diese enthalten neben der Artikelbezeichnung noch Artikeldetails, den Einzelpreis und die Anzahl der erworbenen Artikel
    • Da es nur zwei Spalten gibt, können Bestellungen nur zwei Positionen umfassen - oder alle Posistionen müssen in die beiden Spalten geschrieben werden
• Es gibt doppelte Einträge - die letzten beiden Datensätze sind identisch - hier hat sich der Entwickler wohl vertippt und somit eine unnötige Redundanz erschaffen. Solche Mehrfach-Einträge lassen sich mit dem Verwenden eines Primärschlüssels vermeiden.

Beherzigt man die oben genannten drei Regeln lässt sich das Konzept wie folgt überarbeiten:

Was wurde geändert?

• Es wurde ein Primärschlüssel ID eingefügt, somit gibt es einzigartige Einträge (kein Eintrag gleicht dem anderen, da er eine andere ID hat)
• Die Felder für den Kundennamen, die Kundenadresse, Kundennotizen und das Feld mit Informationen über die bestellten Artikel wurden in atomare Felder aufgeteilt
• Die Felder KND_Notiz und KND_Notiz2 sowie ART1 und ART2 waren „doppelt“, es waren zwei Felder mit dem selben informationstechnischen Nutzen - sie sollten Informationen über bestellte Artikel beinhalten. Sie wurden aufgeteilt, für alle Artikelinformationen (Bezeichnung, Details, Auslaufartikel, Preis) gibt es nun dedizierte Felder.

Die zweite Normalform liegt vor, wenn die folgenden Bedingungen erfüllt werden:

• Erfüllung der 1.Normalform
• alle Spalten sind vom Primärschlüssel abhängig
• alle Informationen werden an einer Stelle und nicht mehrfach gesichert (keine Datenredundanz)

Diese Bedingungen werden vom aktuellen Entwurf nicht erfüllt:

Es sind Spalten vorhanden, die nicht vom Primärschlüssel ID (Kunde) abhängig sind:

• BST_Datum
• BST_Bezahlt
• ART_Anzahl
• ART_Bez
• ART_Details
• ART_Auslauf
• ART_Preis

Abgesehen davon, dass die Tabelle sehr unübersichtlich ist, werden Informationen mehrfach definiert (beispielsweise die Kunden- und Artikelinformationen, unnötige Datenredundanz) und sind somit anfällig für Anomalien.

Diese Tabelle muss in mehrere Tabellen aufgeteilt werden - ein korrekter Ansatz wäre:

Dedizierte Tabellen für:

• Kunden
• Artikel
• Bestellungen
• Bestellungspositionen

Was wurde geändert?

• Es gibt nun seperate Tabellen für Kunden, Artikel, Bestellungen und Bestellungspositionen (Definition gekaufter Artikeln)
• Alle Informationen in den Tabellen sind vom Primärschlüssel abhängig

Die dritte Normalform liegt vor, wenn die folgenden Bedingungen erfüllt werden:

• Erfüllung der 2.Normalform
• Auslagerung aller Felder die inhaltlich nicht vom Primärschlüssel abhängig sind

Die Tabellen ARTIKEL, BESTELLUNGEN und BESTELL_POS liegen bereits in der dritten Normalform vor - lediglich die Tabelle KUNDEN liegt noch nicht in der dritten Normalform vor.

Der Grund ist das Feld KND_Ort. Der Name eines Orts ist von seiner zugehörigen Postleitzahl, KND_PLZ, und nicht vom Kunden abhängig. Dieses Feld wird also in einer weiteren dedizierten Tabelle ausgelagert:

Orte werden nun in einer dedizierten Tabelle gesichert - eine Verknüpfung zu den Kundeninformationen erfolgt über einen Fremdschlüssel.