Bisher haben wir uns mit dem 'Handwerkszeug' einer relationalen Datenbank beschäftigt. Jetzt lernen wir etwas Datenbanktheorie, die bisher zu kurz gekommen ist. Das Normalisieren einer Datenbank verhindert doppelte (redundante) Daten. Eine Datenbank soll gemäß folgender sog. 'Normalformen' Schritt für Schritt geplant werden. Die Datenbanktheorie kennt noch weitere Normalformen, aber in der Praxis kommen Datenstrukturen, die eine weitergehende Normalisierung erforderlich machen, weniger häufig vor.
Eine Tabelle soll keine Felder enthalten, die aus anderen Feldern berechnet werden können (Dafür sind Abfragen zuständig).
Sehen wir uns folgende Tabelle an:
| Verkaeufe | ||||
|---|---|---|---|---|
| VerkaufsNr | Verkaufsdatum | Nettopreis | MwSt | Bruttopreis |
| 1 | 19.12.2007 | 100 | 19% | 119 |
| 2 | 05.12.2010 | 50 | 12% | 60 |
Während der erste Datensatz in sich stimmig scheint, ist der Mehrwertsteuersatz des zweiten Datensatzes definitiv falsch. Und egal, wie man rechnet, der Bruttopreis kann auch nicht stimmen. MwSt und Bruttopreis gehören auch gar nicht erst in die Tabelle, denn anhand des Datums kann jederzeit der Mehrwertsteuersatz und damit auch der Bruttopreis errechnet werden.
Die erste Normalform bestimmt, wofür jeweils ein Feld benötigt wird: Eine Tabelle befindet sich in der ersten Normalform, wenn die Werte in jedem Feld und in jedem Datensatz atomar sind, d.h. sich nicht mehr in kleinere Einheiten zerlegen lassen.
Hier ein Negativbeispiel:
| Personen | ||||
|---|---|---|---|---|
| IDKunde | Name | Anschrift | ||
| 1 | Bilbo Beutlin | Beutelsend 1; 12345 Hobbingen | ||
| 2 | Petra Roth | Berliner Str. 5a), 60123 Frankfurt am Main | ||
Name und Anschrift lassen sich noch weiter zerlegen, nämlich in Vorname, Nachname, Straße, HausNr, PLZ und Ort. Wollte man aus dieser Tabelle alle Personen mit einer bestimmten Postleitzahl abfragen, wäre man vor eine unlösbare Aufgabe gestellt: Mal befindet sich vor der Postleitzahl ein Semikolon, mal ein Punkt, und den Benutzern würden bestimmt noch ein paar andere lustige Trennzeichen einfallen - falls sie überhaupt an eine PLZ denken...
Eine Tabelle befindet sich in der zweiten Normalform, wenn sie der ersten Normalform entspricht und darüber hinaus jeder Datensatz nur Felder enthält, die sich auf das Objekt beziehen, das durch den Primärschlüssel dargestellt wird.
In der folgenden Beispieltabelle gibt es zwar ein Primärschlüsselfeld (IDKunde), das aber keinen Bezug zu den Autokennzeichen hat.
| Werkstattkunden | |||
|---|---|---|---|
| IDKunde | Nachname | Auto-KZ1 | Auto-KZ2 |
| 1 | Junker | F J-2000 | F J-2001 |
| 2 | Becker | SB AF-123 | |
Bei den Kunden haben die Auto-KZ nichts zu suchen. Gemäß der zweiten Normalform
müssen sie aus obiger Tabelle entfernt werden. Sie gehören in eine eigene Tabelle.
Dann können auch mehr als zwei Kennzeichen pro Kunde dargestellt werden.
Auto-KZ ist dann das Primärschlüsselfeld der neuen Tabelle.
| PKWs | |
|---|---|
| IDKunde | Auto-KZ |
| 1 | F J-2000 |
| 1 | F J-2001 |
| 2 | SB AF-123 |
Eine Tabelle befindet sich in der dritten Normalform, wenn sie der zweiten Normalform entspricht und darüber hinaus alle Felder nur einmal vorkommen und alle Felder, die nicht den Primärschlüssel bilden, voneinander unabhängig sind.
Auch hier wieder ein Beispiel, wie es nicht sein sollte:
| Orte | |||
|---|---|---|---|
| IDOrt | txtOrt | lngLand | txtLand |
| 1 | München | 2 | Bayern |
| 2 | Bamberg | 2 | Baiern |
| 3 | Berlin | 3 | Berlin |
Hier wurde nicht nur die Nummer des Bundeslandes, sondern auch noch der
Klartext dazu abgelegt. txtLand ist aber von lngLand
abhängig, also wurde gegen die dritte Normalform verstoßen. So konnte sich auch
der Tippfehler 'Baiern' einschleichen. Mehr als lngLand hätte nicht
in diese Tabelle gehört.