W jaki sposób relacje super-i podtyp na diagramach ER są reprezentowane jako tabele?

To, co powiedzieli inni respondenci, plus następujące, które idą do kluczy głównych dla tabel podklasowych.

Twój przypadek wygląda jak przykład wzorca projektowego znanego jako" specjalizacja Generalizacyjna " lub w skrócie Gen-Spec. Pytanie, jak modelować gen-spec za pomocą tabel bazodanowych pojawia się cały czas w SO.

Gdybyś modelował Gen-spec w OOPL, takim jak Java, użyłbyś funkcji dziedziczenia podklasy, aby zająć się szczegółami dla Ciebie. Po prostu zdefiniuj klasę zajmującą się uogólnionymi obiektami, a następnie zdefiniuj zbiór podklas, po jednej dla każdego typu obiektu specjalistycznego. Każda podklasa rozszerzy klasę uogólnioną. To proste i proste.

Niestety relacyjny model danych nie ma wbudowanego dziedziczenia podklas, a systemy bazodanowe SQL nie oferują takiego obiektu, według mojej wiedzy. Ale nie masz pecha. Tabele można zaprojektować tak, aby modelowały modele gen-spec w sposób równoległy struktura klasowa OOP. Następnie musisz zorganizować wdrożenie własnego mechanizmu dziedziczenia, gdy nowe elementy są dodawane do klasy uogólnionej. Szczegóły poniżej.

Struktura klas jest dość prosta, z jedną tabelą dla klasy gen i jedną tabelą dla każdej podklasy spec. Oto fajna ilustracja ze strony Martina Fowlera. Dziedziczenie Tabeli Klas. zauważ, że na tym diagramie Cricketer jest zarówno podklasą, jak i superklasą. Musisz wybrać, które atrybuty w których stolikach. Diagram pokazuje jeden przykładowy atrybut w każdej tabeli.

Trudnym szczegółem jest sposób definiowania kluczy podstawowych dla tych tabel. Tabela klasy gen otrzymuje klucz podstawowy w zwykły sposób (chyba, że ta tabela jest specjalizacją jeszcze innej uogólnienia, np.). Większość projektantów nadaje kluczowi głównemu standardową nazwę, taką jak "Id". Używają funkcji autonumber do wypełnienia pola Id. Tabele klasy spec otrzymują klucz podstawowy, który może być nazwany "Id", ale funkcja autonumber nie jest używana. Zamiast tego klucz podstawowy każdej tabeli podklasy jest ograniczony do odniesienia się do klucza podstawowego tabeli uogólnionej. To sprawia, że każdy z wyspecjalizowanych kluczy podstawowych jest zarówno kluczem obcym, jak i kluczem podstawowym. Należy pamiętać, że w przypadku krykiecistów, pole Id będzie odwoływać się do pola Id w Players, ale pole Id w Bowlers będzie odwoływać się do pola Id w Cricketers.

Teraz, gdy dodajesz nowe elementy, musisz zachować integralność odnośników, Oto jak.
Najpierw wstawiasz nowy wiersz do tabeli gen, dostarczając dane dla wszystkich jej atrybutów, z wyjątkiem klucza podstawowego. Mechanizm autonumber generuje unikalny klucz podstawowy. Następnie wstawiasz nowy wiersz do odpowiedniej tabeli specyfikacji, w tym dane dla wszystkich jej atrybutów, w tym klucz główny. Klucz podstawowy, którego używasz, jest kopią nowo wygenerowanego klucza podstawowego. Tę propagację klucza pierwotnego można nazwać "dziedzictwem ubogiego człowieka".

Teraz kiedy chcesz wszystkie dane uogólnione wraz ze wszystkimi danymi specjalistycznymi z jednej podklasy, wszystko, co musisz zrobić, to połączyć dwie tabele nad wspólnymi kluczami. Wszystkie dane, które nie odnoszą się do podklasy, o której mowa, znikną z join. Jest gładka, łatwa i szybka.

Zazwyczaj, gdy wykonujesz relację typu Super-Typ/pod-typ w projekcie bazy danych, musisz utworzyć oddzielną tabelę dla ogólnego typu encji (Super-typ) i oddzielne tabele dla wyspecjalizowanych wersji encji (pod-Typ), które są wyłączone lub nie. W Twoim przypadku musisz utworzyć tabelę dla pojazdu i klucza podstawowego oraz niektóre atrybuty, które są wspólne lub wspólne dla wszystkich podtypów. Następnie musisz utworzyć oddzielne tabele dla 2WD i 4WD wraz z określonymi atrybutami tylko do tych stołów. Na przykład

Następnie możesz odpytywać te tabele za pomocą łączników SQL

Nie zawsze jest tylko jeden sposób implementacji konkretnego modelu danych. Często zachodzi transformacja, która następuje po przejściu z modelu logicznego do modelu fizycznego.

Standardowy SQL nie ma czystego sposobu na wymuszenie disjoint ograniczeń podtypu.

Jeśli twoim celem jest wyegzekwowanie jak największej liczby reguł modelu za pomocą schematu, to standardowym podejściem do implementacji modelu jest użycie tabeli dla supertype i po jednej dla każdego z podtypy. Zapewnia to, że dla każdej jednostki używane są tylko odpowiednie atrybuty.

Istnieje mniej lub bardziej standardowa sztuczka SQL służąca do wymuszania ograniczenia rozłącznego. Zniechęca niektórych ludzi, ponieważ narusza zasady normalizacji w nieistotny sposób. Mimo to, niektórzy uważają technikę za estetycznie obraźliwą, ponieważ istnieje techniczne naruszenie 2NF.

Ta technika polega na dodaniu atrybutu partycjonowania do supertype i włączeniu tego partycjonowania atrybut w każdym podtypie, dodając go do klucza głównego podtypu. Wraz z ograniczeniami sprawdzania, które nakładają określone wartości dla atrybutów partycjonowania, zapewnia to, że każda jednostka może mieć co najwyżej jeden podtyp. Technika jest szczegółowo udokumentowana w wielu miejscach, takich jak ten blog .