Составная таблица первичных ключей с подтипами

Question

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

Скажем, у нас есть две таблицы Employee и Project.Мы создаем составную таблицу Employee_Project с составным первичным ключом обратно в Employee и Project.

Существует ли допустимый способ для Employee_Project иметь подтипы?Или вы можете вспомнить какой-либо сценарий, в котором составная таблица ключей может иметь подтипы?

Для меня отношение составного ключа - это отношение «Is A» (Employee_Project - это Employee и Project).Подтипы также являются отношениями "Is A".Так что если у вас есть составной ключ с подтипом, то есть два отношения «Is A» в одном предложении, что заставляет меня поверить, что это плохая практика.

Answer 1

Сотрудник-проект немного сложен, но можно представить что-то вроде этого - хотя я не большой химик.

Или что-то вроде этого,которые потребовали бы различные юридические формы (поля) для владения одним лицом по сравнению с совместной (доля времени).

Или как это, при условии, что различные формы необходимы для полной занятости итемпература

Answer 2

Проекты сотрудников имеют подтипы, если подтипы-кандидаты

• не сильно отличаются, но
• не совсем похожи

Это означает, что

• Каждый проект сотрудника имеет несколько общих атрибутов (столбцов).Таким образом, они не совершенно отличаются.
• Некоторые проекты сотрудников имеют другие атрибуты, чем другие.Таким образом, они не точно похожи.

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

Наиболее распространенный пример бизнес-супертипа / подтипа касается организаций и отдельных лиц.Они не очень разные.

• У обоих есть адреса.
• У обоих есть телефонные номера.
• Оба могут быть истцами и ответчиками в суде.

Но они не совсем похожи.

• Физические лица могут поступать в колледж.
• Организации могут иметь генерального директора.
• Физические лица могут вступать в брак.
• У отдельных лиц могут быть дети.
• Организации (в США) могут быть ликвидированы.

Таким образом, вы можете выражать отдельных лиц и организации как подтипы супертипа, называемогоскажем, "вечеринки".Все атрибуты, которые имеют все подтипы, относятся к супертипу.

• У сторон есть адреса.
• У сторон есть номера телефонов.
• Стороны могут быть истцами и ответчиками всуд.

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

Для меня отношение составного ключа - это отношение "Is A" (Employee_Project - Employee and Project).

Разработчики баз данных так не думают.Мы думаем в терминах предиката таблицы.

Answer 3

Если у сотрудника может быть много проектов, а в проекте может быть много сотрудников, это соединение многих со многими, которое RDBM может легко представить только одним способом (как вы обрисовали выше). Это можно увидеть в ER Диаграмма ниже (сотрудник / отделы - один из классических примеров «многие ко многим») показывает, что в ней нет отдельного компонента ER. Отдельная таблица - это утечка абстракций СУРБД (вероятно, поэтому вам трудно ее моделировать).

http://www.library.cornell.edu/elicensestudy/dlfdeliverables/fallforum2003/ERD_final.doc

Мост сущностей

Когда экземпляр объекта может быть связан с несколькими экземплярами другого объекта, и наоборот, это называется отношением «многие ко многим». В приведенном ниже примере поставщик может предоставить много разных продуктов, и каждый Тип продукта может быть предложен многими поставщиками:

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

http://users.csc.calpoly.edu/~jdalbey/205/Lectures/ERD_image004.gif

Здесь они не беспокоятся об отдельном блоке, хотя они добавляются позже (на этом этапе это «чистая» диаграмма ER). Он также может быть явно представлен коробкой и ромбом, наложенным друг на друга.