Warto rozważyć model danych typu/podtypu. Jest to bardzo podobne do klasy/podklas w programowaniu obiektowym, ale jest o wiele bardziej niewygodne w implementacji i żaden RDBMS (o którym jestem świadomy) natywnie ich nie obsługuje. Ogólna idea to:
- Określasz typ (budynek), tworzysz dla niego tabelę, nadajesz klucz podstawowy
- Definiujesz dwa lub więcej podtypów (tutaj, Szpital, Klinika, Szkoła, Uniwersytet), tworzysz tabele dla każdego z nich, tworzysz klucze podstawowe… ale klucze podstawowe są również kluczami obcymi, które odwołują się do tabeli Building
- Twoja tabela z jedną kolumną „ObjectType” może być teraz zbudowana za pomocą klucza obcego w tabeli Building. Musiałbyś dołączyć do kilku stołów, aby ustalić, jaki to jest budynek, ale i tak musiałbyś to zrobić. To lub przechowuj nadmiarowe dane.
Zauważyłeś problem z tym modelem, prawda? Co sprawi, że budynek nie będzie zawierał wpisów w dwóch lub więcej tabelach podtypów? Cieszę się, że zapytałeś:
- Dodaj kolumnę, być może „BuildingType”, do budynku, powiedzmy char(1) z dozwolonymi wartościami {H, C, S, U} wskazującymi (duh) typ budynku.
- Utwórz unikalne ograniczenie dla BuildingID + BuildingType
- Umieść kolumnę BulidingType w podtabelach. Umieść na nim ograniczenie sprawdzające, aby zawsze mogło być ustawione na wartość (H dla tabeli Szpitale itp.). Teoretycznie może to być kolumna obliczona; w praktyce to nie zadziała z powodu następującego kroku:
- Zbuduj klucz obcy, aby powiązać tabele za pomocą obu kolumn
Voila:Biorąc pod uwagę zestaw wierszy BUILDING z typem H, wpis w tabeli SCHOOL (z typem S) nie może odnosić się do tego budynku
Przypominasz sobie, że powiedziałem, że było to trudne do wdrożenia.
W rzeczywistości najważniejsze pytanie brzmi:czy warto to robić? Jeśli ma sens zaimplementowanie czterech (lub więcej, w miarę upływu czasu) typów budynków jako typu/podtypu (dalsze korzyści z normalizacji:jedno miejsce na adres i inne atrybuty wspólne dla każdego budynku, z atrybutami charakterystycznymi dla budynku przechowywanymi w podtabelach), może być warta dodatkowego wysiłku, aby zbudować i utrzymać. Jeśli nie, to wracasz do punktu wyjścia:logicznego modelu, który jest trudny do wdrożenia w przeciętnym współczesnym RDBMS.
