Hi,
zunächst: Beim lesen des Beitrags von ukulele müsste ich mal massiv grinsen - toll aufgebläht
.
Aber im Grunde ist die Antwort vollkommen richtig. ukulele beschreibt aber hier ein Modell der 4. bzw. der 5. NF, was in der Praxis im Regelfall nicht eingesetzt wird.
(Ich nehme CRM-Systeme oder Spezialfälle hier mal raus).
Man sollte aber ja nicht vergessen, dass wir hier von Modellen sprechen. Diese sind natürlich erst einmal rein theoretischer Natur.
Ob dein Beispiel der Mitarbeitertabelle tatsächlich die 2.NF verletzt hängt von der funktionalen Betrachtung ab.
Bei deinem Beispiel ist es ja in der Regel so, dass ein Mitarbeiter (wobei ich davon ausgehe, dass die PersNr der PKEY ist) immer nur einen Status annehmen kann.
Es gibt vom Mitarbeiter zum Status also eine definierte 1:1-Beziehung. Ich sehe hier eigentlich keine direkte Verletzung der 2.NF, da der Status aufgrund der 1:1-Beziehung direkt vom PKEY abhängt.
Wenn es jedoch so ist, dass ein Mitarbeiter mit der gleichen Personalnummer verschiedene Stati gleichzeitig annehmen kann, dann werden aufgrund der nun vorliegenden 1:n-Beziehung
zwischen PersNr und Status diese beiden Felder zu Schlüsselkandidaten, da nur über diese beiden Informationen ein Datensatz eindeutig identifiziert werden kann.
Ohne einen zusammengesetzten PKEY würde die Tabelle also bereits die 1.NF verletzen!
Mit diesem zusammengesetzten Primärschlüssel würden dann die Spalten Vorname, Nachname und Geburtsdatum die 2.NF verletzen, da diese nicht eindeutig vom gesamten PKEY abhängen.
Diese Daten würden dann redundant vorliegen. Wenn sich dann z.B. bei einer Frau der Nachname ändert, könnte die Tabelle inkonsistent werden, wenn bei der Ersetzung nicht für jeder PersNr dieser Name entsprechend mit berücksichtigt wird (wir sprechen hier von der Möglichkeit, dass dieser Fall eintreten kann.)
Damit die zweite 2.NF in diesem Falle nicht verletzt wird, muss der zusammengesetzte PKEY aufgelöst werden.
Bei der Angabe des Geschlechts ist es ja so, dass diese in der Regel nicht umbenannt wird und je Personalnummer entsprechend eindeutig ist. Außerdem gibt es für die Angabe des Geschlechts ja nun auch nicht grade unendlich viele Möglichkeiten
Hier gehen viele nur deshab auf eine Referenztabelle über, um unterschiedliche Schreibweisen zu vermeiden. Andere Möglichkeit sind natürlich definierte Kürzel mit nur einem Buchstaben.
Dies kann man aber bereits in der Datenbank mit einer Eintragsüberprüfung für das Feld festlegen, dazu benötigt man nicht zwingend eine Referenz. Man muss dies also im Modell nicht berücksichtigen.
Viele Grüße,
Tommi
