Конструкция БД надтипов / подтипов с перекрестными ссылками подтипов

Question

Это, вероятно, простая проблема для опытного разработчика баз данных, но я изо всех сил ... У меня проблемы с переводом определенной диаграммы ER в модель DB, любая помощь приветствуется.

У меня естьнастройки, аналогичные слайду 17 данной презентации: http://www.cbe.wwu.edu/misclasses/mis421s04/presentations/supersubtype.ppt

Слайд 17 показывает диаграмму ER с супертипом Employee, имеющим атрибут Employee Type, и в качестве подтипов сами типы сотрудников (Hourly, Salaried and Consultant), который являетсяочень похоже на мою ситуацию с дизайном.

В моем случае, предположим, что Наемные работники - это единственные, кто может быть начальниками других сотрудников, и я хотел как-то указать, является ли некий наемный работник боссом почасового и /или наемный работник и / или консультант (либо нет, либо оба), как это может быть спроектировано в модели базы данных, также учитывая, что это отношения один ко многим?

Я могу поставить отношение PK-FKмежду ними, что привело бы ко всем таблицам, имеющим два FKeys и (как у консультанта, имеющего FK_Employee и FK_SalariedEmployee) и SalariedEmployee ссылаются на себя, но я продолжаю думать, что это может быть не самым мудрым решением .... хотя я не уверен почему (проблемы целостности?).

Это или является приемлемым решением илиЕсть ли лучший?

Заранее спасибо за любую помощь!

Answer 1

Ваш случай выглядит как пример шаблона проектирования, известного как «Специализация обобщения» (Gen-Spec для краткости).Шаблон gen-spec знаком для объектно-ориентированных программистов.Он описан в уроках по обучению наследованию и подклассам.

Дизайн таблиц SQL, которые реализуют шаблон gen-spec, может быть немного сложным.Учебники по дизайну баз данных часто затмевают эту тему.Но на практике это происходит снова и снова.

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

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

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

В вашем конкретном случае, для того, чтобы сделать трюк, достаточно объявить «босса» FK ссылкой на PK в таблице Salaried Employees,Это создаст двустороннюю ассоциацию, которую вы хотите, а также предотвратит ссылки на сотрудников, которые не получают зарплату, в качестве начальников.