Sie überdenken die Verbindung zwischen Optionalität und Identität. Bis Ihnen das Ganze natürlicher erscheint, ist es am besten, sie als völlig unabhängig zu betrachten .
Bei der Optionalität ist es wichtig, sich daran zu erinnern, dass die Optionalität gerichtet ist. Um Ihr Beispiel von employee_equipment zu verwenden :Sicher, Mitarbeiter brauchen keine Ausrüstung. Die Eins-zu-Viele-Beziehung von employee zu employee_equipment es ist optional. Gleichzeitig ist die Beziehung, wenn man es aus der entgegengesetzten Perspektive betrachtet, zwingend. Sie können keinen Eintrag in employee_equipment haben es sei denn, es gibt einen employee damit zu verknüpfen.
Identität hat nichts mit Optionalität zu tun, außer zufällig eine identifizierende Beziehung zwischen dem Kind und dem Elternteil ist obligatorisch. Ob es auch von den Eltern gegenüber dem Kind verpflichtend ist, ist weder hier noch dort, was die Identität betrifft.
Was eine Beziehung identifiziert, ist, dass Sie wissen müssen, über welchen Elternteil Sie sprechen (sowie einige andere Dinge), um zu wissen, über welches Kind Sie sprechen. Das heißt, der Primärschlüssel des untergeordneten Elements muss einen Fremdschlüssel für das übergeordnete Element enthalten.
Reine Schnittmengentabellen (z.B. employee_equipment ) sind gute Beispiele dafür. Der Primärschlüssel einer reinen Schnittmenge ist die Kombination der Fremdschlüssel zu beiden Elterntabellen. Beachten Sie, dass einige Leute diesen Tabellentypen auch einen Ersatzschlüssel hinzufügen können. Aus Sicht der Identität spielt es keine so große Rolle, ob es mehrere Kandidatenschlüssel gibt. Wichtig bei der Bestimmung der Identität ist, ob der Fremdschlüssel Teil eines Kandidatenschlüssels ist, ob dieser Kandidatenschlüssel zufällig der Primärschlüssel ist oder nicht.
Ein weiteres gutes Beispiel wäre so etwas wie der Metadatenkatalog einer Datenbank, in dem eine Spalte durch die Tabelle identifiziert wird, zu der sie gehört, genauso wie die Tabelle durch das Schema identifiziert wird, in dem sie sich befindet, und so weiter. Zu wissen, dass eine Spalte NAME heißt sagt Ihnen nicht, welche Spalte es ist. Zu wissen, dass es der NAME ist Spalte in CUSTOMER Tabelle hilft. (Sie müssen auch wissen, welches Schema CUSTOMER ist in usw.).
