Nadtyp / podtyp decydujący o kategorii: całkowite rozłączne lub niepełne nakładanie się

Buduję bazę danych inwentarza, która przechowuje sprzęt IT, taki jak komputery stacjonarne, laptopy, przełączniki, routery, telefony komórkowe itp. Używam wzorca nadtypu / podtypu, w którym wszystkie urządzenia są przechowywane w jednej tabeli, a także konkretnych informacji jest umieszczany w tabelach podtypów. Moim dylematem są dwa następujące projekty:

Na górnym schemacie wszystkie urządzenia mają wspólne podtypy. Na przykład komputery stacjonarne i laptopy miałyby rekordy w następujących tabelach: Urządzenie, NetworkDevice. Przełącznik miałby rekordy w: Device, NetworkDevice. Router ma zapisy w: Device, NetworkDevice, WANDevice. Każde urządzenie, dla którego śledzimy lokalizację, będzie miało zapis w lokalizacji. Niektóre zalety i wady, o których pomyślałem dla tej konfiguracji:

• Pro: WYBIERANIE rekordów na podstawie wspólnego pola, takiego jak nazwa hosta lub identyfikator lokalizacji jest łatwiejsze.
• Pro: Brak pól zerowych.
• Wada: tabele, które powinny być uwzględnione w operacjach CRUD dla konkretnego urządzenia, nie są oczywiste i mogą mylić przyszłe DBA.

Na dolnym schemacie wszystkie urządzenia mają swój własny podtyp (istnieje więcej klas urządzeń, których nie pokazano). W tej sytuacji oczywiste jest, które rekordy tabel zostaną wstawione lub wybrane. Komputery stacjonarne i laptopy działają w komputerze itp. Niektóre zalety i wady, o których pomyślałem dla tej konfiguracji:

• Pro: od razu wiadomo, których tabel użyć do operacji CRUD dla podtypów.
• Pro: Musisz używać tylko jednej tabeli do operacji CRUD.
• Przeciw: WYBÓR rekordów na podstawie wspólnych pól podtypów wymaga połączenia wszystkich tabel, na przykład wyszukiwania według nazwy hosta lub identyfikatora lokalizacji.

W obu sytuacjach pole ClassDiscriminator jest umieszczane w tabelach podtypów w celu użycia z ograniczeniem CHECK do kontrolowania, które typy można wstawić.

Czy są jakieś zalecenia, dla których projekt jest lepszy, czy też jest to całkowicie kwestia opinii i zależy od zamierzonego celu bazy danych?

EDYCJA: Szczególne pytanie, które mam, dotyczy nakładającego się charakteru tabeli „NetworkDevice”. Ta tabela służy do przechowywania informacji o sieci dla dowolnego urządzenia z nazwą hosta i / lub adresem IP, niezależnie od tego, czy jest to komputer, przełącznik czy router. Czy nakładający się charakter tej tabeli może powodować problemy, czy też jest w porządku, aby zaimplementować ją w ten sposób?

Z góry dziękuję za wszelkie przekazane informacje. Zapytaj, czy potrzebne są dodatkowe informacje.

Fizyczna implementacja podtypów w bazie danych jest złożonym problemem. Chyba że masz sytuację, w której oferuje on istotne zalety (patrz jeden lub dwa przykłady poniżej), zwiększa złożoność implementacji, a jednocześnie zapewnia stosunkowo niewielką wartość.

Po zrobieniu tego z bardzo złożonym podzbiorem (wnioski i wyroki w systemie zarządzania sprawami sądowymi, rozbieżne struktury umów ubezpieczenia komercyjnego o połączonym ryzyku), wydaje mi się, że mam na ten temat pewne spostrzeżenia. Niektóre znaczące przypadki narożne to:

• Jeśli całkowita liczba pól bazy danych w podtypach jest stosunkowo niska (powiedzmy: mniej niż 100) lub istnieje znaczna podobieństwo między podtypami, wówczas podział podtypów na osobne tabele fizyczne ma prawdopodobnie niewielką wartość. Spowoduje to znaczny narzut związany z raportowaniem zapytań i wyszukiwań. W większości przypadków najlepiej jest mieć jedną tabelę i zarządzać podtypami w aplikacji. (Prawdopodobnie najbliżej twojego problemu)

• Jeśli podtyp jest bardzo rozłączny, a różne podtypy mają zwisające z nimi struktury danych zależne od typu (tj. Tabele potomne lub bardziej złożone struktury), wówczas tabele podtypów mają sens. W takim przypadku każdy podtyp prawdopodobnie ma stosunkowo niewielką podobieństwo w aplikacji (tzn. Prawdopodobnie w aplikacji jest cały podsystem dedykowany temu podtypowi). Większość raportów i zapytań prawdopodobnie wystąpi w ramach danego podtypu, przy czym zapytania krzyżowe ograniczają się głównie do kilku wspólnych pól. (System zarządzania sprawami sądowymi)

• Jeśli masz dużą liczbę podtypów o odmiennych atrybutach i / lub wymogu skonfigurowania tej konfiguracji, bardziej odpowiednia może być ogólna struktura i dodatkowe metadane. Zobacz ten wpis SO w celu podsumowania niektórych możliwych podejść. (System zarządzania polisami ubezpieczeniowymi)

• Jeśli masz bardzo dużą liczbę pól o małej podobieństwa między podtypami i niewielkim wymogiem wykonywania zapytań w tabelach podtypów (tj. Nic w rodzaju wielostronnych połączeń zewnętrznych względem tabel podtypów), to pod- tabele typów mogą pomóc w zarządzaniu rozrostem kolumn. (Patologicznie złożona wersja twojego problemu)

• Niektórzy twórcy map O / R mogą obsługiwać tylko określone podejście do zarządzania podklasami.

W większości przypadków fizyczne tabele podtypów w schemacie bazy danych są nieco rozwiązaniem w poszukiwaniu problemu, ponieważ potencjalnie mają niepożądane skutki uboczne.

W twoim przypadku zakładam, że masz stosunkowo niewielką liczbę podtypów i możliwą do zarządzania liczbę atrybutów. Twój diagram i pytanie nie wskazują na zamiar powieszenia tabel podrzędnych poza rekordami. Sugerowałbym, aby rozważyć skorzystanie z pierwszej opcji sugerowanej powyżej i utrzymanie jednej tabeli i zarządzanie podtypami w aplikacji.

Rozważ najpierw opracowanie solidnego logicznego modelu danych przy użyciu reguł hierarchii klasyfikacji modelowania danych zawartych w książce David Model Hay. Podczas tworzenia hierarchii klasyfikacji każde wystąpienie (wiersz) musi być jednego i tylko jednego podtypu. Oznacza to, że podtypy wykluczają się wzajemnie. Klasyfikacja musi opierać się na jednej, fundamentalnej, niezmiennej charakterystyce. Korzystanie z tej podstawowej zasady zapewni modelowi dużą przejrzystość. W posiadanym modelu jedyną cechą, na podstawie której można dokonać klasyfikacji, jest przeznaczenie urządzenia - telefon, przełącznik sieciowy, komputer, router itp. Każde urządzenie musi być jednego i tylko jednego z tych typów. Na przykład lokalizacja nie byłaby podtypem. Atrybuty takie jak adres IP należą do typu super.

Myślę, że przekonasz się, że liczba typów urządzeń będzie wystarczająco duża, aby uzasadnić wzorzec EAV, jak wspomniano w innej odpowiedzi. Odnosząca się do mnie książka Davida Haya bardzo skutecznie omawia ten wzór. Jeśli jednak liczba podtypów jest niewielka, można zastosować ogólną regułę przy podejmowaniu decyzji o wdrożeniu tylko tabeli supertypowej z wieloma zerowalnymi kolumnami, tylko tabel podtypowych ze zduplikowanymi kolumnami lub obu. Jeśli każdy podtyp różni się znacznie pod względem atrybutów i nie ma żadnych relacji na poziomie supertypu, możesz użyć tylko tabel podtypu. Jeśli prawda jest odwrotna, możesz użyć tylko tabel supertypowych. Jeśli jest mieszanka, to zaimplementuj oba.

Zauważ wreszcie, że zawsze możesz zaimplementować wzorzec EAV jako schemat tabeli bazowej, a następnie utworzyć warstwę abstrakcji widoku, która przedstawia dane aplikacji jako tabele super i podtypów. Daje to elastyczność w warstwie pamięci, ale zrozumiałość w warstwie widoku aplikacji.

Produkt nie jest zapasem. Zapasy i produkty są różne.

Produkt jest tak naprawdę specyfikacją produktu, a nie rzeczą fizyczną.

Fizyczną rzeczą jest Zasób, który firma posiada (lub przechowuje). Możesz mieć zasoby, które śledzisz według numeru seryjnego (aktywa dyskretne) lub zasoby, które śledzisz tylko według ilości (zasoby magazynowe).

Chciałbym spojrzeć na książkę danych modelu danych Silverstona, tom 1. Ma dobry schemat dumy, funkcje, ceny, zapasy. Zaoszczędzi ci dużo czasu.

Jedno z pytań, które zadałbym, to dlaczego śledzisz różne atrybuty swoich przedmiotów w ekwipunku? - A dokładniej, co robisz z tymi informacjami o atrybutach?

Jeśli masz wiele raportów lub formularzy, które określają konkretne atrybuty, musisz zastosować podejście zalecane przez ConcernedOfTunbridgeWell. Z drugiej strony, jeśli te atrybuty są rejestrowane w celu ich wyszczególnienia lub porównania z podobnymi atrybutami podobnych urządzeń, wtedy możesz mieć (rzadką) dobrą wymówkę, aby używać EAV. Wiem, że „EAV jest czystym złem” z wielu powodów, z wyjątkiem bardzo rzadkich przypadków, gdy przyczyny te nie mają znaczenia dla konkretnego zastosowania. Twoja może być taka aplikacja.

Spójrz na tę odpowiedź dotyczącą projektu systemu inwentaryzacji urządzeń i tę odpowiedź dotyczącą projektu systemu katalogu produktów, aby zobaczyć, w jaki sposób podejście EAV może uprościć twoją aplikację wraz z dyskusją na temat dokładnie ryzyka EAV i jak ocenić, czy ryzyko to może nie dotyczyć konkretnego wniosku.