Tabela podrzędna (znana również jako słaba jednostka ) to tabela, której atrybuty klucza podstawowego zależą na innym stole, dzięki czemu tabela podrzędna jest zidentyfikowana lub częściowo zidentyfikowane wierszami w tabeli, od której zależy (rodzic). Wiersze w tabeli podrzędnej nie mogą istnieć bez odpowiedniego wiersza w tabeli nadrzędnej.
Aby to zilustrować, weźmy prosty i całkowicie trafny przykład, który wszyscy znamy:Rodzice i dzieci w kontekście rodziny . Możemy wymodelować tę relację za pomocą tabel w następujący sposób:
W powyższym modelu każdy wiersz w Parents tabela jest jednoznacznie zidentyfikowana przez SSN . SSN jest nieodłącznym i unikalnym atrybutem każdego rodzica, dlatego jest samodzielną lub "silną" jednostką, ponieważ nie opiera się na innej tabeli w celu zdefiniowania swojej tożsamości.
Dzieci jednak wymagają rodzic, aby istnieć (Parent_SSN musi odniesienie do istniejącego SSN w Parents stół).
Zwróć uwagę na złożony klucz podstawowy (Parent_SSN, Name ) w Children stół. Oznacza to, że dzieci są jednoznacznie identyfikowane przez kombinację z Parent_SSN i Name . Nie możesz zapytać o indywidualne dziecko tylko na podstawie Name pole, ponieważ wielu rodziców może mieć dzieci o tym samym imieniu. Podobnie nie można wysyłać zapytań o indywidualne dziecko na podstawie tylko Parent_SSN pole, ponieważ jeden rodzic może mieć wiele dzieci. Biorąc to pod uwagę, dzieci są częściowo identyfikowane przez rodzica, stąd identyfikacja związek.
Ale czy dzieci nie mogą być również jednoznacznie identyfikowane przez numer SSN? Dlaczego tak, na pewno. Przejdźmy dalej i dostosujmy nasz model, aby uwzględnić to:
Zauważ, że w tej wersji modelu wprowadziliśmy SSN pole dla Children . Unikalna tożsamość dzieci jest teraz definiowanych przez ich własny wewnętrzny i unikalny SSN . Ich tożsamość już nie zależy na Parents stół. Chociaż Parent_SSN pole nadal odwołuje się do SSN Parents tabeli, nie ma udziału w unikalnej tożsamości dziecka, więc rodzice mają nieidentyfikujący związek z ich dziećmi, a obie tabele można teraz uznać za „silne” samodzielne jednostki.
Poza tym ta wersja modelu ma kilka zalet w porównaniu z pierwszą:
- Jeden rodzic może teraz mieć dwoje lub więcej dzieci o tym samym imieniu, podczas gdy integralność podmiotu ograniczenia w poprzednim modelu na to nie pozwalały.
- Możesz zezwolić na
Parent_SSNpole, które ma zawieraćNULLaby uwzględnić zdarzenie, w którym masz dane o dziecku, ale nie wiesz, kim jest jego rodzic.
W obu powyższych modelach Parents tabela jest uważana za tabelę nadrzędną Children stół. Jednak w nieidentyfikującym relacje jak w drugim modelu, Parents jest tylko tabelą nadrzędną w kontekście klucza obcego Parent_SSN ponieważ Parent_SSN odniesienia/zależności na SSN w Parents tabeli, ale nie mieć jakikolwiek udział w określaniu rzeczywistej tożsamości dzieci.
Aby zilustrować, dlaczego kontekst jest ważny przy podejmowaniu decyzji, które tabele są tabelami nadrzędnymi/podrzędnymi, rozważmy następujący przykład dotyczący zależności cyklicznej:
W tym przykładzie pracownicy i działy są jednoznacznie identyfikowane przez ich własne atrybuty i nie czerpią żadnej części swojej tożsamości z innych tabel.
Tutaj mamy dwie nieidentyfikujące relacje:pracownik pracuje w dziale (DeptNo w Employee tabeli), a działem zarządza pracownik (ManagerSSN w Department stół). Który z nich jest tabelą nadrzędną? ...Stół dziecięcy?
To zależy od kontekstu — o jakiej relacji klucza obcego mówisz? Tabela Department byłaby uważana za tabelę nadrzędną w kontekście DeptNo w Employee tabela, ponieważ DeptNo jest odwołujący się/zależny na Department stół.
Jednak tabela Employee byłaby uważana za tabelę nadrzędną w kontekście ManagerSSN w Department tabela, ponieważ ManagerSSN jest odwołujący się/zależny o Employee tabela.
