En underordnet tabel (A.K.A. svag enhed ) er en tabel, hvis primære nøgleattributter afhænger på et andet bord, således er den underordnede tabel identificeret eller delvist identificeret efter rækker i tabellen afhænger det af (forælder). Rækker i en undertabel kan ikke eksistere uden en tilsvarende række i dens overordnede tabel.
For at illustrere det, lad os tage et enkelt og fuldstændig relevant eksempel, som vi alle kender:Forældre og børn i familiesammenhæng . Vi kan modellere dette forhold med tabeller som sådan:
I modellen ovenfor, hver række i Parents tabellen er entydigt identificeret med en SSN . SSN er en iboende og unik egenskab for hver forælder, så den er en selvstændig eller "stærk" enhed, fordi den ikke er afhængig af en anden tabel til at definere sin identitet.
Børn kræver dog en forælder for at eksistere (Parent_SSN skal reference til en eksisterende SSN i Parents bord).
Bemærk den sammensatte primærnøgle (Parent_SSN, Name ) i Children bord. Det betyder, at børn er entydigt identificeret ved kombinationen af Parent_SSN og Name . Du kan ikke forespørge efter et individuelt barn kun baseret på Name felt, fordi flere forældre kan have børn med samme navn. Ligeledes kan du ikke forespørge efter et individuelt barn udelukkende baseret på Parent_SSN felt, fordi den ene forælder kan have mange børn. Når det tages i betragtning, identificeres børn delvist af deres forælder, og derfor identificeres forhold.
Men kan børn ikke også identificeres entydigt af et SSN? Hvorfor ja, bestemt. Lad os gå videre og justere vores model til at inkludere det:
I denne version af modellen skal du bemærke, at vi har introduceret SSN felt for Children . Den entydige identitet af børn er nu defineret af deres egen iboende og unikke SSN . Deres identitet afhænger ikke længere på Parents bord. Selvom Parent_SSN feltet henviser stadig til SSN af Parents tabel, har den ingen del i den unikke identitet af barnet, således har forældre en ikke-identificerende forhold til deres børn, og begge tabeller kan nu betragtes som "stærke" selvstændige enheder.
Derudover har denne version af modellen et par fordele i forhold til den første:
- En forælder kan nu have to eller flere børn med samme navn, hvorimod entitetsintegriteten a> begrænsning i den tidligere model ville ikke tillade dette.
- Du kan tillade
Parent_SSNfelt til at indeholdeNULLat redegøre for den hændelse, at du har data om barnet, men ikke ved, hvem hans/hendes forælder er.
I begge ovenstående modeller er Parents tabel anses for at være den overordnede tabel for Children bord. Men i ikke-identificerende relationer som i den anden model, Parents er kun en overordnet tabel i konteksten af fremmednøglen Parent_SSN fordi Parent_SSN referencer/afhænger på SSN i Parents tabel, men ikke have nogen del i at definere børns faktiske identitet.
For at illustrere, hvorfor kontekst er vigtig, når du skal beslutte, hvilke tabeller der er overordnede/underordnede tabeller, kan du overveje følgende eksempel, der involverer en cirkulær afhængighed:
I dette eksempel er medarbejdere og afdelinger unikt identificeret ved deres egne attributter og henter ikke nogen del af deres identitet fra andre tabeller.
Her har vi to ikke-identificerende relationer:en medarbejder arbejder for en afdeling (DeptNo i Employee tabel), og en afdeling ledes af en medarbejder (ManagerSSN i Department bord). Hvilken er forældretabellen? ...Barnebord?
Det afhænger af kontekst - hvilket fremmednøgleforhold taler du om? Afdelingstabellen vil blive betragtet som den overordnede tabel i sammenhæng med DeptNo i Employee tabel fordi DeptNo er henvisende/afhængig på Department bord.
Employee-tabellen vil dog blive betragtet som den overordnede tabel i sammenhæng med ManagerSSN i Department tabel fordi ManagerSSN er henvisende/afhængig på Employee tabel.