Eine untergeordnete Tabelle (auch bekannt als schwache Entität ). ) ist eine Tabelle, deren Primärschlüsselattribute abhängen auf einer anderen Tabelle, somit wird die untergeordnete Tabelle identifiziert oder teilweise identifiziert nach Zeilen in der Tabelle, von denen es abhängt (Eltern). Zeilen in einer untergeordneten Tabelle können nicht ohne eine entsprechende Zeile in ihrer übergeordneten Tabelle existieren.
Nehmen wir zur Veranschaulichung ein einfaches und durchaus relevantes Beispiel, mit dem wir alle vertraut sind:Eltern und Kinder im Familienkontext . Wir können diese Beziehung mit Tabellen wie folgt modellieren:
Im obigen Modell jede Zeile in den Parents Tabelle ist eindeutig identifiziert durch eine SSN . Die SSN ist ein intrinsisches und einzigartiges Attribut für jeden Elternteil, daher ist es eine eigenständige oder "starke" Entität, da es nicht auf eine andere Tabelle angewiesen ist, um seine Identität zu definieren.
Kinder jedoch erfordern ein Elternteil, um zu existieren (Parent_SSN müssen Verweis auf eine bestehende SSN in den Parents Tisch).
Beachten Sie den zusammengesetzten Primärschlüssel (Parent_SSN, Name ) in den Children Tisch. Das bedeutet, dass Kinder eindeutig identifiziert werden durch die Kombination von Parent_SSN und Name . Sie können nicht nur anhand des Name nach einem einzelnen Kind suchen Feld, da mehrere Eltern Kinder mit demselben Namen haben können. Ebenso können Sie nicht nur anhand der Parent_SSN nach einem einzelnen Kind suchen Feld, weil ein Elternteil viele Kinder haben kann. In Anbetracht dessen werden Kinder teilweise von ihren Eltern identifiziert, also identifizierend Beziehung.
Aber können Kinder nicht auch durch eine Sozialversicherungsnummer eindeutig identifiziert werden? Warum ja, sicherlich. Lassen Sie uns fortfahren und unser Modell so anpassen, dass es Folgendes enthält:
Beachten Sie, dass wir in dieser Version des Modells den SSN eingeführt haben Feld für Children . Die einzigartige Identität der Kinder wird jetzt durch ihren eigenen intrinsischen und eindeutigen SSN definiert . Ihre Identität hängt nicht mehr davon ab auf den Parents Tisch. Obwohl die Parent_SSN Feld verweist immer noch auf SSN der Parents Tabelle, es hat keinen Anteil an der eindeutigen Identität des Kindes, somit haben die Eltern eine nicht-identifizierende Beziehung zu ihren untergeordneten Elementen, und beide Tabellen können nun als "starke" eigenständige Entitäten angesehen werden.
Abgesehen davon hat diese Version des Modells einige Vorteile gegenüber der ersten:
- Ein Elternteil kann jetzt zwei oder mehr Kinder mit demselben Namen haben, wohingegen die Entitätsintegrität Einschränkungen im vorherigen Modell ließen dies nicht zu.
- Sie können die
Parent_SSNzulassen Feld, dasNULLenthält um den Fall zu berücksichtigen, dass Sie Daten über das Kind haben, aber nicht wissen, wer sein Elternteil ist.
In beiden oben genannten Modellen die Parents Tabelle wird als übergeordnete Tabelle der Children angesehen Tisch. Allerdings nicht identifizierend Beziehungen wie im zweiten Modell, Parents ist nur eine übergeordnete Tabelle im Kontext des Fremdschlüssels Parent_SSN weil Parent_SSN Referenzen/abhängig auf SSN in den Parents Tabelle, aber nicht irgendeinen Anteil an der Definition der tatsächlichen Identität von Kindern haben.
Um zu veranschaulichen, warum der Kontext wichtig ist, wenn es darum geht, zu entscheiden, welche Tabellen Eltern-/Kind-Tabellen sind, betrachten Sie das folgende Beispiel mit einer zirkulären Abhängigkeit:
In diesem Beispiel werden Mitarbeiter und Abteilungen durch ihre eigenen Attribute eindeutig identifiziert und leiten keinen Teil ihrer Identität von anderen Tabellen ab.
Hier haben wir zwei nicht identifizierende Beziehungen:Ein Mitarbeiter arbeitet für eine Abteilung (DeptNo im Employee Tabelle), und eine Abteilung wird von einem Mitarbeiter geleitet (ManagerSSN in der Department Tisch). Welche ist die übergeordnete Tabelle? ...Kindertisch?
Es hängt vom Kontext ab – von welcher Fremdschlüsselbeziehung sprechen Sie? Die Department-Tabelle würde im Kontext von DeptNo als übergeordnete Tabelle betrachtet im Employee Tabelle, weil DeptNo ist referenzierend/abhängig in der Department Tisch.
Die Employee-Tabelle würde jedoch im Kontext von ManagerSSN als übergeordnete Tabelle betrachtet in der Department Tabelle, weil ManagerSSN ist referenzierend/abhängig auf Employee Tabelle.
