Wie jetzt, geht es um die Relation 1:1 oder geht es um die Kontenfrage?
1:1 macht man normalerweise so, daß man einen gemeinsamen PK definiert. Mit Normalform läßt sich 1:1 nicht darstellen, das ist da ein bißchen Sonderform.
Beispiel, ich hab Mitarbeiter und ich hab Vorgesetzte, aber aus welchem Grund auch immer hab ich für die Vorgesetzten signifikant mehr Attribute, die ich da brauche.
Jetzt kann das natürlich alles in eine Tabelle und sollte gemäß Normalform auch in eine Tabelle. Aber dann hab ich tonnenweise Nullen wegen sehr viel mehr Vorgesetzten als MA und tonnenweise Attributen, die bei den MA leer bleiben.
Dennoch sind Vorgesetzte natürlich auch Mitarbeiter.
Deshalb baue ich
A eine Tabelle für die MA mit allen Attributen für die MA und NUR für die MA, dh ich begreife das Personal pauschal als Mitarbeiter und ignoriere erstmal die Tatsache, daß darunter auch Vorgesetzte existieren. Die nehm ich zwar auch alle mit, aber die Tatsache, daß es V.
sind, ist aus der MA-Tabelle
nicht ersichtlich.
PK wird die Mitarbeiter-ID. Wie die beschaffen ist, ist egal.
B Eine Tabelle für die Vorgesetzten. In OO und in Postgres könnte man das einfach ableiten, aber in RDBMS nicht, daher kommen hier alle Attribute rein, die die Vorgesetzten
zusätzlich brauchen.
PK bleibt die Mitarbeiter-ID.
Dann kann ich das hinterher zusammenfügen über die MA-ID, die den MA eh eindeutig identifiziert, ich kann den Vorgesetzten bestimmen, wenn der MA in der V.Tabelle existiert, bzw kann feststellen, daß der MA kein V. ist, wenn er dort
nicht existiert.
1:1 Relationen muß man händisch bauen. Sie sind nicht immer sinnvoll, aber können aus Performancegründen relevant werden, insbesondere, wenn BLOB-Daten ins Spiel kommen.
Aus der NF leiten sie sich aber NICHT her.
