Een onderliggende tabel (A.K.A. zwakke entiteit ) is een tabel waarvan de primaire sleutelkenmerken afhankelijk zijn op een andere tafel, dus de onderliggende tafel is geïdentificeerd of gedeeltelijk geïdentificeerd door rijen in de tabel hangt het af van (ouder). Rijen in een onderliggende tabel kunnen niet bestaan zonder een overeenkomstige rij in de bovenliggende tabel.
Laten we ter illustratie een eenvoudig en volledig relevant voorbeeld nemen dat we allemaal kennen:Ouders en kinderen in de context van het gezin . We kunnen deze relatie met tabellen als volgt modelleren:
In het bovenstaande model is elke rij in de Parents tafel is uniek geïdentificeerd door een SSN . Het SSN is een intrinsiek en uniek attribuut voor elke ouder, dus het is een op zichzelf staande of "sterke" entiteit omdat het niet afhankelijk is van een andere tabel om zijn identiteit te definiëren.
Kinderen hebben echter vereisen een ouder om te kunnen bestaan (Parent_SSN moeten verwijzing naar een bestaand SSN in de Parents tafel).
Let op de samengestelde primaire sleutel (Parent_SSN, Name ) in de Children tafel. Dit betekent dat kinderen uniek worden geïdentificeerd door de combinatie van Parent_SSN en Name . U kunt niet naar een individueel kind zoeken op basis van alleen de Name omdat meerdere ouders kinderen met dezelfde naam kunnen hebben. Evenzo kunt u niet naar een individueel kind zoeken op basis van alleen de Parent_SSN veld omdat een ouder veel kinderen kan hebben. Als we dat in overweging nemen, worden kinderen gedeeltelijk geïdentificeerd door hun ouder, vandaar identificerend relatie.
Maar kunnen kinderen ook niet eenduidig geïdentificeerd worden met een BSN? Waarom ja, zeker. Laten we doorgaan en ons model aanpassen om het volgende op te nemen:
Merk op dat we in deze versie van het model de SSN . hebben geïntroduceerd veld voor Children . De unieke identiteit van de kinderen wordt nu gedefinieerd door hun eigen intrinsieke en unieke SSN . Hun identiteit hangt niet langer af op de Parents tafel. Hoewel de Parent_SSN veld verwijst nog steeds naar de SSN van de Parents tabel, heeft het geen deel aan de unieke identiteit van het kind, dus ouders hebben een niet-identificerende relatie met hun kinderen, en beide tabellen kunnen nu worden beschouwd als "sterke" zelfstandige entiteiten.
Even terzijde, deze versie van het model heeft een paar voordelen ten opzichte van de eerste:
- Eén ouder kan nu twee of meer kinderen met dezelfde naam hebben, terwijl de integriteit van de entiteit een> beperking in het vorige model zou dit niet toestaan.
- Je kunt de
Parent_SSN. toestaan veld datNULLmoet bevatten om rekening te houden met de gebeurtenis dat u gegevens over het kind heeft, maar niet weet wie zijn/haar ouder is.
In beide bovenstaande modellen, de Parents tabel wordt beschouwd als de bovenliggende tabel van de Children tafel. Echter, in niet-identificerend relaties zoals in het tweede model, Parents is alleen een bovenliggende tabel in de context van de refererende sleutel Parent_SSN omdat Parent_SSN referenties/afhankelijk op SSN in de Parents tafel, maar niet enige rol spelen bij het bepalen van de werkelijke identiteit van kinderen.
Om te illustreren waarom context belangrijk is bij het bepalen welke tabellen bovenliggende/onderliggende tabellen zijn, kunt u het volgende voorbeeld bekijken met een circulaire afhankelijkheid:
In dit voorbeeld worden medewerkers en afdelingen op unieke wijze geïdentificeerd door hun eigen kenmerken en ontlenen ze geen enkel deel van hun identiteit aan andere tabellen.
Hier hebben we twee niet-identificerende relaties:een medewerker werkt voor een afdeling (DeptNo in de Employee tabel), en een afdeling wordt beheerd door een medewerker (ManagerSSN in de Department tafel). Welke is de bovenliggende tafel? ...Kindertafel?
Het hangt af van de context - over welke buitenlandse sleutelrelatie heb je het? De Afdelingstabel wordt beschouwd als de bovenliggende tabel in de context van DeptNo in de Employee tabel omdat DeptNo is verwijzend/afhankelijk op de Department tafel.
De tabel Werknemer wordt echter beschouwd als de bovenliggende tabel in de context van ManagerSSN in de Department tabel omdat ManagerSSN is verwijzend/afhankelijk op de Employee tafel.