En underordnad tabell (A.K.A. svag enhet ) är en tabell vars primära nyckelattribut beroende på ett annat bord, därför är den underordnade tabellen identifierad eller delvis identifierad efter rader i tabellen beror det på (förälder). Rader i en underordnad tabell kan inte existera utan en motsvarande rad i dess överordnade tabell.
För att illustrera, låt oss ta ett enkelt och helt relevant exempel som vi alla är bekanta med:Föräldrar och barn i familjesammanhang . Vi kan modellera detta förhållande med tabeller så här:
I modellen ovan, varje rad i Parents tabellen är unikt identifierad med en SSN . SSN är ett inneboende och unikt attribut för varje förälder, så det är en fristående eller "stark" enhet eftersom den inte förlitar sig på en annan tabell för att definiera sin identitet.
Barn kräver dock en förälder för att existera (Parent_SSN måste referens till en befintlig SSN i Parents tabell).
Lägg märke till den sammansatta primärnyckeln (Parent_SSN, Name ) i Children tabell. Det betyder att barn är unikt identifierade genom kombinationen av Parent_SSN och Name . Du kan inte fråga efter ett enskilt barn endast baserat på Name eftersom flera föräldrar kan ha barn med samma namn. På samma sätt kan du inte fråga efter ett enskilt barn endast baserat på Parent_SSN eftersom en förälder kan ha många barn. Med hänsyn till detta identifieras barn delvis av sin förälder, och därför identifierar förhållande.
Men kan inte barn också identifieras unikt av ett SSN? Varför ja, absolut. Låt oss gå vidare och justera vår modell så att den inkluderar det:
I den här versionen av modellen, notera att vi har introducerat SSN fält för Children . Den unika identiteten barn definieras nu av deras egen inneboende och unika SSN . Deras identitet beror inte längre på på Parents tabell. Även om Parent_SSN fältet hänvisar fortfarande till SSN av Parents tabellen har den ingen del i den unika identiteten av barnet, alltså föräldrar har en icke-identifierande relation till sina barn, och båda tabellerna kan nu betraktas som "starka" fristående enheter.
Dessutom har den här versionen av modellen några fördelar jämfört med den första:
- En förälder kan nu ha två eller flera barn med samma namn, medan entitetsintegriteten a> begränsning i den tidigare modellen skulle inte tillåta detta.
- Du kan tillåta
Parent_SSNfältet ska innehållaNULLatt redogöra för händelsen att du har uppgifter om barnet, men inte vet vem hans/hennes förälder är.
I båda ovanstående modeller är Parents tabellen anses vara den överordnade tabellen för Children tabell. Men i icke-identifierande relationer som i den andra modellen, Parents är bara en överordnad tabell i sammanhanget med den främmande nyckeln Parent_SSN eftersom Parent_SSN referenser/beror på SSN i Parents tabell, men gör det inte ha någon del i att definiera barns faktiska identitet.
För att illustrera varför sammanhanget är viktigt när man bestämmer vilka tabeller som är överordnade/underordnade tabeller, överväg följande exempel som involverar ett cirkulärt beroende:
I det här exemplet identifieras anställda och avdelningar unikt med sina egna attribut och hämtar inte någon del av sin identitet från andra tabeller.
Här har vi två icke-identifierande relationer:en anställd arbetar på en avdelning (DeptNo i Employee tabell), och en avdelning hanteras av en anställd (ManagerSSN i Department tabell). Vilken är föräldertabellen? ...Barnbord?
Det beror på sammanhanget — vilken främmande nyckelrelation pratar du om? Avdelningstabellen skulle betraktas som den överordnade tabellen i sammanhanget DeptNo i Employee tabell eftersom DeptNo är refererande/beroende på Department tabell.
Employee-tabellen skulle dock betraktas som den överordnade tabellen i sammanhanget ManagerSSN i Department tabell eftersom ManagerSSN är refererande/beroende på Employee bord.