Как мы реализуем отношения IS-A?

Question

Мы реализуем отношение «один ко многим», добавляя PK одной таблицы как FK к другой таблице.Мы реализуем отношение «многие ко многим», добавляя 2-х ПК таблицы в третью таблицу.

Как мы реализуем отношение IS-A?

Объектами являются техник и администратор, которые обаРАБОТНИК.Я мог бы просто использовать дополнительное поле в таблице СОТРУДНИК (идентификатор, имя, фамилия, роль , ... AdminFields ..., ... TechFields ...)

но яхотел бы изучить вариант IS-A.

РЕДАКТИРОВАТЬ: я сделал, как предложил Донни, но без поля роли.

Answer 1

Я сделал, как предложил Донни, но без поля роль , потому что это усложняет ситуацию Это окончательная реализация:

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)
);

Диаграмма ER:

В этой модели нет сотрудников универсального типа. Здесь Сотрудник может быть только Административным или Техническим.

Answer 2

Я всегда делал это с полем role, а затем необязательными связями.

Т.е., таблица EMPLOYEE (id, ...generic fields... , role)

А затем для каждой роли:

стол ROLE1 (employeeid, ...specific fields...)

Это позволяет получать общую информацию о сотруднике с помощью одного запроса и требует объединения для получения информации о конкретной роли. Единственным (большим) недостатком этого является то, что если вам нужен один супер-отчет со всей информацией о роли, вы застряли с кучей внешних объединений.

Answer 3

Отношение IS-A также известно как шаблон проектирования gen-spec.Gen-spec - сокращение от «обобщающая специализация».

Реляционное моделирование gen-spec отличается от объектного моделирования gen-spec, поскольку в реляционной модели нет встроенного наследования.Вот хорошая статья, которая показывает, как реализовать gen-spec в виде набора таблиц.

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

Обратите особое внимание на настройку первичных ключей в специализированных таблицах.Вот что делает использование этих таблиц таким простым.

Вы можете найти множество других статей от googlin "Обобщение специализации реляционного моделирования".

Answer 4

Если у вас есть приложение OO, которое необходимо подключить к реляционной серверной базе данных, я бы порекомендовал получить Шаблоны архитектуры корпоративных приложений Мартина Фаулера .

Он также имеетнекоторые соответствующие заметки и диаграммы на его сайте.В частности, шаблоны Наследование отдельных таблиц , Наследование таблиц классов и Наследование бетонных таблиц описывают три тактики отображения IS-A в таблицах данных.

Если вы используете Hibernate или JPA, они поддерживают сопоставления для всех из них, хотя у них разные имена.

В этом конкретном случае я бы вообще не использовал IS-A.

Такие вещи, как роли сотрудников, лучше смоделированы как HAS-A, например

1. Возможно, вы захотите, чтобы у одного человека было несколько ролей.
2. Изменение роли будетпроще.

Answer 5

В этой статье описываются некоторые стратегии для преобразования обобщений в проект схемы.

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

Копия тезисов:

Более богатые модели данных объектно-реляционные базы данных открывает множество больше вариантов для логического проектирования схема базы данных, увеличивающая сложность логического проектирования баз данных чрезвычайно. Сосредоточение на обобщении конструкции концептуальных моделей мы изучить последствия производительности из различных вариантов дизайна для отображение обобщений в схема объектно-реляционной система баз данных.

Answer 6

Почему бы не реализовать это как отношение «один к нулю / одна таблица»?Допустим, у вас есть таблица, представляющая базовый класс Vehicle, с первичным ключом VehicleID.Затем вы можете иметь любое количество спутниковых таблиц, представляющих все подклассы Vehicle, и эти таблицы также имеют VehicleID в качестве их первичного ключа, имея отношение 1-> 0/1 от Vehicle-> Subclass.

ИлиЕсли вы хотите сделать это проще и вы точно знаете, что у вас когда-нибудь будет только несколько подклассов, и вероятность такого изменения невелика, вы можете просто представить всю структуру в одной таблице с полем типа дискриминатора.

Answer 7

Это зависит от того, строите ли вы моно-иерархию или поли-иерархию. Это жестко запрограммированный дизайн, который, я считаю, то, что вы хотели.

Для моно (дочерняя таблица имеет одну родительскую таблицу), где дочерний IS-A родитель, FK и PK одинаковы в дочерней таблице, и этот ключ также является PK в родительской таблице.

Для поли (дочерняя таблица имеет несколько родительских таблиц), где дочерний IS-A parent-1 и дочерний IS-A parent-2, у вас будет составной ключ (то есть несколько первичных ключей, чтобы сделать запись таблицы уникальной), где правило совпадает с моно-иерархией для каждого ключа.

Answer 8

Большинство ORM реализуют отношение IS-A, используя дискриминатор из одного столбца, выбирая, какой подкласс создавать, основываясь на значении в конкретном столбце. Что касается вашего примера, вы, вероятно, на самом деле не имеете в виду роль , поскольку обычно человек может выполнять много разных типов ролей. Роли обычно моделируются как отношения has-a . Если вы попытаетесь реализовать это, используя отношения is-a (или подклассы), вы неизбежно столкнетесь с необходимостью сделать что-то более сложное, чтобы справиться со случаями, когда у вас есть человек, занимающий гибридную должность - то есть секретарь который также функционирует как местный ИТ-специалист, которому требуются разрешения или атрибуты обоих.