Benutzer-Werkzeuge

Webseiten-Werkzeuge


computer:tutorials:sql:normalisierung

Normalisierung beschreibt den Vorgang, Tabellen einer Datenbank dahingehend zu strukturieren, sodass sie keine vermeidbaren Redundanzen enthalten. Normalisierte Tabellen sorgen für eine konsistente und fehlerunanfällige Datenhaltung.

Beispiel

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:

KND_NameKND_FirmaKND_AdresseKND_NotizKND_Notiz2BST_DatumBST_BezahltART_1ART_2
Max MustermannMustermann ConsultingMusterstrasse 1, 12345 Musterstadt 10.10.2010110x Thin-Client BAER (1.6 Ghz,Sound,VGA,USB) 199.9915x Thin-Client NP (1.0 Ghz,Sound,VGA+DVI,USB) 179.99 Auslauf
Theodor TesterTest-Solutions AGTestweg 16, 55353 TestortOffene Rechnung 15.02.2011 1x Thin-Client BAER (1.6 Ghz,Sound,VGA,USB) 199.99
Theodor TesterTest-Solutions AGTestweg 16, 55353 TestortOffene Rechnung 15.02.2011 1x Thin-Client BAER (1.6 Ghz,Sound,VGA,USB) 199.99

1.Normalform

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:

IDKND_VornameKND_NachnameKND_FirmaKND_StrasseKND_HausNrKND_PLZKND_OrtKND_NotizBST_DatumBST_BezahltART_AnzahlART_BezART_DetailsART_AuslaufART_Preis
1MaxMustermannMustermann ConsultingMusterstrasse112345Musterstadt 10.10.2010ja10Thin-Client BAER1.6 Ghz,Sound,VGA,USBnein199.99
2MaxMustermannMustermann ConsultingMusterstrasse112345Musterstadt 10.10.2010ja15Thin-Client NP1.0 Ghz,Sound,VGA+DVI,USBja179.99
3TheodorTesterTest-Solutions AGTestweg1655353TestortOffene Rechnung15.02.2011nein1Thin-Client BAER1.6 Ghz,Sound,VGA,USBnein199.99

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.

2.Normalform

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:

IDKND_VornameKND_NachnameKND_FirmaKND_StrasseKND_HausNrKND_PLZKND_OrtKND_NotizBST_DatumBST_BezahltART_AnzahlART_BezART_DetailsART_AuslaufART_Preis
1MaxMustermannMustermann ConsultingMusterstrasse112345Musterstadt 10.10.2010ja10Thin-Client BAER1.6 Ghz,Sound,VGA,USBnein199.99
2MaxMustermannMustermann ConsultingMusterstrasse112345Musterstadt 10.10.2010ja15Thin-Client NP1.0 Ghz,Sound,VGA+DVI,USBja179.99
3TheodorTesterTest-Solutions AGTestweg1655353TestortOffene Rechnung15.02.2011nein1Thin-Client BAER1.6 Ghz,Sound,VGA,USBnein199.99

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
KUNDEN
KND_NrKND_VornameKND_NachnameKND_FirmaKND_StrasseKND_HausNrKND_PLZKND_OrtKND_Notiz
1MaxMustermannMustermann ConsultingMusterstrasse112345Musterstadt
2TheodorTesterTest-Solutions AGTestweg1655353TestortOffene Rechnung Nr.3
ARTIKEL
ART_NrART_BezeichnungART_DetailsART_AuslaufART_Einzelpreis
1Thin-Client BAER1.6 Ghz,Sound,VGA,USBnein199.99
2Thin-Client NP1.0 Ghz,Sound,VGA+DVI,USBja179.99
BESTELLUNGEN
BST_NrKND_NrBST_DatumBST_Bezahlt
1110.10.2010ja
2215.02.2011nein
BESTELL_POS
BPOS_NrBST_NrART_NrBPOS_Anzahl
11110
21215
3211

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

3.Normalform

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:

KUNDEN
KND_NrKND_VornameKND_NachnameKND_FirmaKND_StrasseKND_HausNrKND_OrtKND_Notiz
1MaxMustermannMustermann ConsultingMusterstrasse11
2TheodorTesterTest-Solutions AGTestweg162Offene Rechnung Nr.3
ORTE
ORT_NrORT_PLZORT_Name
112345Musterstadt
255353Testort

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

In dieser Tabelle wird explizit ein eigener Primärschlüssel definiert. Die Spalte ORT_PLZ eignet sich nicht als Primärschlüssel.

Warum? Ganz einfach - Postleitzahlen können auch durchaus mit einer 0 beginnen, in einem solchen Fall würde die 0 abgeschnitten werden und zu Fehlinformationen führen.

computer/tutorials/sql/normalisierung.txt · Zuletzt geändert: 2013/05/13 08:01 von christian