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

Ответ 1

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

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:

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

Ответ 2

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

I.e., table EMPLOYEE (id, ...generic fields... , role)

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

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

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

Ответ 3

Связь IS-A также известна как шаблон дизайна gen-spec. Gen-spec не подходит для "специализации обобщения".

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

Вот хорошая статья, в которой показано, как реализовать ген-spec как набор таблиц.

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

Обратите особое внимание на то, как первичные ключи настраиваются в специализированных таблицах. Это облегчает использование этих таблиц.

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

Ответ 4

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

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

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

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

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

• Возможно, вам понадобится один человек имеют несколько ролей.
• Изменение роли человека будет проще.

Ответ 5

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

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

Копия реферата:

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

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

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