Jak powinienem modelować relację „albo / albo”?

Powiedzmy, że mam podmiot o nazwie Oprogramowanie i dwa podtypy FreeSoftware i NonFreeSoftware. Jednostka NonFreeSoftware ma atrybuty takie jak data zakupu, dostawca itp. Jednostka FreeSoftware ma atrybuty takie jak licencja, adres URL kodu źródłowego itp.

Więc jeśli chcę modelować inny byt, OperatingSystem, jak mam to zrobić? Istnieje „związek” z oprogramowaniem, ale „albo / lub” związek z FreeSoftware i NonFreeSoftware.

Myślę, że coś pomijam w sposobie, w jaki analizuję tę hierarchię.

database-design subtypes

— jl6
źródło

Przejrzyj tę odpowiedź . Obejmuje szczegóły implementacji modelowania tego rodzaju relacji.

— Nick Chammas,

Odpowiedzi:

Sposób zarządzania tym polega na tym, że twoje podtypy muszą być określone przez nadtyp (tj. PK podtypu jest również FK od podtypu do nadtypu).

Wyzwanie polega na zrozumieniu, czy coś naprawdę wyklucza się wzajemnie, czy nie. Atrybuty podtypów powinny mieć zastosowanie tylko do tych podtypów, ale może się zdarzyć, że niektóre podtypy wzajemnie się wykluczają, a inne nie.

Jeśli masz niektóre wzajemnie wykluczające się podtypy, możesz użyć atrybutu partycjonowania na supertypie, aby wskazać, który z dwóch (lub więcej) wzajemnie wykluczających się podtypów ma zastosowanie. Tego atrybutu partycjonowania można używać z ograniczeniami lub wyzwalaczami w celu wymuszenia wzajemnej wyłączności.

Jeśli masz podtypy, które nie wykluczają się wzajemnie, mogą istnieć bez użycia atrybutu partycjonowania.

Rozważ ten model danych:

ERD

Masz trzy supertypy, ale typy FREE_SOFTWAREi NON-FREE_SOFTWAREwzajemnie się wykluczają, na podstawie SOFTWARE.free_not_freeatrybutu podziału flagi. Każde oprogramowanie jest również potencjalnie OPERATING_SYSTEM, niezależnie od tego, czy jest bezpłatne.

— Joel Brown
źródło

Nieco OT: czego użyłeś, aby zrobić ten schemat ER?

— Daniel Serodio

@DanielSerodio - używałem Visio z inteligentnymi kształtami, które zbudowałem na podstawie notacji James Martin ERD. Kształty używają niestandardowej tekstury linii, aby nadać im nieformalny wygląd, co uważam za pomocne w przypominaniu ludziom, gdy diagram jest szkicem lub szkicem.

— Joel Brown

@JoelBrown Czy zechciałbyś udostępnić swoje szablony? To naprawdę ładne kształty

— imoatama,

@imoatama - Minęło trochę czasu, ale w końcu udało mi się opublikować szablon tutaj: moosewarevisioerd.codeplex.com Uwaga: jak w opisie, inteligentne kształty szablonu zostały zbudowane dla starszej wersji Visio i niektórych zachowań kształty łączników relacji mogą być nieco płatkowe. Pewnego dnia zajmę się naprawieniem tego.

— Joel Brown,

Dlaczego OperatingSystem miałby być zupełnie nowym bytem? Powinien należeć do Oprogramowania, ponieważ tak właśnie jest. A system operacyjny (jeśli zamknięty kod źródłowy) miałby datę zakupu, dostawcę itp. A system operacyjny open source miałby licencję, adres URL kodu źródłowego itp.

Poleciłbym związek z SoftwareTypeczymś podobnym. To wtedy możesz / powinieneś określić, czy Oprogramowanie jest systemem operacyjnym, aplikacją lub jakimkolwiek innym obsługiwanym oprogramowaniem.

— Thomas Stringer
źródło

Chciałbym, aby OperatingSystem był odrębną jednostką, ponieważ jest to specjalizacja oprogramowania. Może mieć atrybuty, których nie będzie miało żadne inne Oprogramowanie (takie jak typ jądra, flaga RTOS-or-not, flaga wielu użytkowników itp.).

— jl6

@ jl6 Nadal błagam się tutaj różnić. Każde oprogramowanie (czy to system operacyjny, czy nie) będzie miało określone atrybuty. Można je przechowywać gdzie indziej. Minimalizujesz skalowalność, oddzielając system operacyjny.

— Thomas Stringer,

Jeśli dobrze rozumiem, zalecamy encję Software i encję SoftwareType. Czy mówisz, że Free, NonFree i OperatingSystem to po prostu różne wystąpienia SoftwareType? Jestem pewien, że masz rację, ale gdzie przechowujesz różne atrybuty różnych typów?

— jl6