|
2. Normalform
Angenommen, der Pizzaservice will die Autos (Fahrzeugnr., Typ, Kilometerstand) mit in das Datenmodell aufnehmen. Da jeder Fahrer ein bestimmtes Auto fährt, könnte man eine Tabelle folgender Art konstruieren:
|
23 |
Maier |
A34729384 |
Opel Corsa |
67430 |
|
3 |
Müller |
V8347-1111 |
VW Polo |
32165 |
|
11 |
Valerius |
|
|
|
|
17 |
Walker |
A34729384 |
Opel Corsa |
67430 |
Die anderen Attribute des Angestellten wurden aus Übersichtlichkeitsgründen weggelassen.
"Valerius" ist kein Fahrer, deshalb hat er keine Autodaten in seinem Datensatz.
Aus dieser Tabelle, die die 1. Normalform erfüllt lassen sich weitere Nachteile ablesen:
- Update-Anomalie:
Nach mehreren Fahrten hat sich der Kilometerstand des Corsa geändert. Wenn man nicht genau aufpasst, dann kann es sein, dass man nicht alle Datensätze geändert hat und man erhält inkonsistente Daten (Maier mit anderem Kilometerstand als Walker).
- Einfüge-Anomalie:
Wo wird ein Auto eingetragen, dass noch keinen Fahrer hat?
- Lösch-Anomalie:
Angenommen, Müller verlässt die Firma, dann müsste sein Datensatz gelöscht werden. Ist dann auch der VW Polo verloren?
Die beschriebenen Probleme ergeben sich dadurch, dass bestimmte Attribute nicht mehr vom Primärschlüssel abhängen. Der "Corsa" wird z.B. nicht eindeutig durch "Walker" identifiziert.
Die Tabelle einer Datenbank befindet sich in 2. Normalform, wenn jedes Attribut eindeutig vom
Primärschlüssel identifiziert wird.
|