Database Reference
In-Depth Information
Es wird dem Leser überlassen, ob er die Abhängigkeiten aus
mathematischer oder aus praktischer Sicht anwenden möchte.
Entscheidend dafür, ob Tabellen aufgeteilt werden müssen, ist
die Erfahrung des Anwenders sowie die Kenntnisse des Umfel-
des. Es gibt kein Schema F, mit dem alle Probleme gelöst wer-
den könnten. Dies schlägt sich auch im Abschnitt 3.2.6 „opti-
male Normalformen“ nieder.
Ein weiteres Beispiel für eine transitive Abhängigkeit wird im
Abschnitt 3.3 bei der Strukturregel 6 beschrieben.
3.2.2
Die 1. Normalform
Der Normalisierungsprozess verläuft über die Bildung so ge-
nannter Normalformen und soll an folgendem Beispiel erklärt
werden:
Eine Autoverkaufsstelle möchte eine Datenbank einrichten, in
der alle Autos mit Modellangabe und Seriennummer gespei-
chert sind. Ausserdem sollen alle Verkäufer und alle Kunden
erfasst werden. Ein Kunde muss mindestens ein Auto gekauft
haben, bevor er in der Datenbank erfasst wird. Die Datenbank
soll Auskunft darüber geben, welcher Kunde welche Autos von
welchem Verkäufer wann gekauft hat.
Alle diese Informationen könnte man in einer einzigen Tabelle
darstellen, wie dies Bild 3.58 zeigt.
Bild 3.58:
Einfache Liste
mit Geschäfts-
daten
Kunden-
name
Adresse
Auto-
marke
Typ
Serien-
nummer
Verkäufer
Datum
Meier
Planeten-
weg 7
VW
Opel
Golf
Astra
123456
345678
Schmid
Plüss
23.4.08
7.8.08
Müller
Altstadt 12
VW
Golf
388721
Frey
17.6.08
Steffen
Gartenstr. 7
VW
Bora
222245
Schmid
15.7.08
Steffen
Augasse 12
Audi
A6
122154
Frey
13.11.08
Opel
Antara
445321
Schenk
Der Opel Antara wurde noch nicht verkauft, muss jedoch für
das Inventar in der Datenbank existieren. Das Gleiche gilt für
den Verkäufer Schenk, welcher noch kein Auto verkauft hat.
Die Tabelle ist in dieser Form jedoch nicht zulässig, da pro Tu-
Search WWH ::




Custom Search