Jak wdrożyć relację IS-A?

Implementujemy relację jeden do wielu, dodając PK jednej tabeli, jako FK do drugiej tabeli. Realizujemy relację Many-to-Many, dodając 2 PKs tabeli do trzeciej tabeli.

Jak wdrożyć związek IS-A ?

Podmioty są technicznymi i administracyjnymi, które są zarówno pracownikami. Przydałoby mi się Dodatkowe pole w tabeli Pracownik (id, imię, nazwisko, rola,...AdminFields..., ...TechFields...)

Ale chciałbym zbadać IS-A opcja.

EDIT: zrobiłem tak, jak sugerował Donnie, ale bez pola ról.

Author: Eric Lavoie, 2010-12-06
Source

8 answers

Zrobiłem tak, jak sugerował Donnie, ale bez pola roli , ponieważ to komplikuje sprawy. Jest to ostateczna implementacja:

DDL: 

CREATE TABLE Employee (
ast VARCHAR(20) not null,
firstname VARCHAR(200) not null,
surname VARCHAR(200) not null,
...
PRIMARY KEY(ast)
);

CREATE TABLE Administrative (
employee_ast VARCHAR(20) not null REFERENCES Employee(ast),
PRIMARY KEY(employee_ast)
);

CREATE TABLE Technical (
employee_ast VARCHAR(20) not null REFERENCES Employee(ast),
...
PRIMARY KEY(employee_ast)
);

Schemat ER:

ERD

W tym modelu nie ma pracowników typu generycznego. Tutaj pracownik może być tylko administracyjny lub Techniczny.

 23
Author: athspk,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-01-12 09:16:34

Zawsze robiłem to z polem role, a następnie opcjonalnymi relacjami.

Tj. tabela EMPLOYEE (id, ...generic fields... , role)

I wtedy, dla każdej roli:

Tabela ROLE1 (employeeid, ...specific fields...)

Pozwala to uzyskać ogólne informacje o pracownikach za pomocą jednego zapytania i wymaga dołączenia, aby uzyskać informacje specyficzne dla danej roli. Jedynym (dużym) minusem tego jest to, że jeśli potrzebujesz jednego super-raportu ze wszystkimi informacjami o roli, utkniesz z kilkoma zewnętrznymi połączeniami.

 7
Author: Donnie,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-12-05 21:45:18

Zależność IS-a jest również znana jako wzorzec projektowy gen-spec. Gen-spec to skrót od "specjalizacji generalizacyjnej".

Modelowanie relacyjne Gen-spec różni się od modelowania obiektowego gen-spec, ponieważ model relacyjny nie ma wbudowanego dziedziczenia.

Oto dobry artykuł, który pokazuje, jak zaimplementować gen-spec jako zbiór tabel.

Http://www.javaguicodexample.com/erdrelationalmodelnotes1.html

Pay particular zwróć uwagę na sposób ustawienia podstawowych klawiszy w tabelach specjalistycznych. To właśnie sprawia, że korzystanie z tych tabel jest tak łatwe.

Możesz znaleźć wiele innych artykułów googlina "generalization specialization relational modeling".

 6
Author: Walter Mitty,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-12-06 12:23:44

Jeśli masz aplikację OO, którą musisz połączyć z relacyjną bazą danych, polecam pobranie wzorców architektury aplikacji korporacyjnych Martina Fowlera.

Ma również kilka istotnych notatek i diagramów na swojej stronie internetowej. W szczególności, wzorce dziedziczenie pojedynczej tabeli, dziedziczenie tabel klasy i Concrete Table Inheritance opisują trzy taktyki mapowania IS-A w tabelach danych.

Jeśli używasz Hibernate lub JPA, obsługują mapowania dla wszystkich z nich, choć mają dla nich różne nazwy.

W tym konkretnym przypadku w ogóle nie używałbym IS-A.

Rzeczy takie jak role pracowników są lepiej modelowane jako HAS-A, jako

  1. możesz chcieć, aby jedna osoba pełnią wiele ról.
  2. zmiana roli osoby będzie łatwiej.
 5
Author: Don Roby,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-12-05 22:37:57

W niniejszym artykule opisano niektóre strategie odwzorowania uogólnień na Schematy.

Http://www.sztaki.hu/conferences/ADBIS/3-Eder.pdf

Kopia abstraktu:

Bogatsze modele danych z obiektowe relacyjne bazy danych otwiera wiele więcej opcji dla logicznego projektowania schemat bazy danych zwiększający złożoność logicznego projektowania baz danych ogromnie. Skupienie się na uogólnieniu konstruowanie modeli koncepcyjnych we poznaj wpływ na wydajność różnych alternatyw projektowych dla odwzorowanie uogólnień na schemat obiektu-relacyjny system baz danych.

 3
Author: Ronnis,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-12-05 22:42:25

Dlaczego nie zaimplementować tego jako relacji jeden do zera/jeden tabeli? Załóżmy, że masz tabelę przedstawiającą klasę podstawową zwaną Vehicleid, z kluczem podstawowym VehicleID. Następnie możesz mieć dowolną liczbę tabel satelitarnych reprezentujących wszystkie podklasy pojazdu, a tabele te mają również VehicleID jako klucz główny, mający relację 1->0/1 z podklasy pojazdu.

Lub, jeśli chcesz to uprościć i wiesz na pewno, że będziesz miał tylko kilka podklas i nie ma większych szans, aby to się zmieniło, możesz po prostu reprezentować całą strukturę w jednej tabeli z polem typu dyskryminatora.

 2
Author: mattmc3,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-12-05 21:54:39

Większość ORMs implementuje relację IS-a używając dyskryminatora pojedynczej kolumny, wybierając podklasę do utworzenia instancji na podstawie wartości w danej kolumnie. Jeśli chodzi o twój przykład, prawdopodobnie nie masz na myśli roli , ponieważ zazwyczaj osoba może wypełnić wiele różnych rodzajów ról. Role zazwyczaj modelowane są jako relacja has-a. Jeśli spróbujesz zaimplementować to używając is-a relacji (lub podklasowania), nieuchronnie będziesz musiał coś bardziej skomplikowanego do obsługi spraw, w których masz osobę zajmującą stanowisko hybrydowe - czyli sekretarza, który działa również jako lokalna osoba informatyczna, wymagająca uprawnień lub atrybutów obu.

 1
Author: tvanfosson,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-12-05 21:51:56

To zależy czy budujesz mono-hierarchię czy poly-hierarchię. To jest mocno zakodowany projekt, który, jak sądzę, jest tym, czego chciałeś.

Dla mono (tabela potomna ma jedną tabelę rodzica), gdzie child jest-rodzicem, FK i PK są takie same w tabeli potomnej, a ten klucz jest również PK w tabeli rodzica.

Dla poly (tabela potomna ma wiele tabel rodzicielskich), gdzie child to-rodzic-1, a child to-rodzic-2, będziesz miał klucz złożony (co oznacza wiele kluczy podstawowych do utworzenia table record unique), gdzie reguła jest taka sama jak Monochromatyczna hierarchia dla każdego klucza.

 1
Author: MacGyver,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-12-09 16:09:39