Правильный способ моделирования реляционной базы данных

Question

, чтобы объяснить мою проблему, я приведу простой пример:

В моей базе данных есть три таблицы:

[positions]
 - position_id INT
 - position VARCHAR

[employees]
 - employee_id INT
 - position_id INT - FK
 - name VARCHAR
 - birth_date DATE

[vehicles]
 - vehicle_id INT
 - model VARCHAR
 - year VARCHAR
 - color VARCHAR

Проблема в том, что я должен связать одно транспортное средство с одним сотрудником, у которогодолжность в компании - «Драйвер», и только в этом случае.

Я пытался использовать наследование и создать другую таблицу с именем «Драйвер», имеющую ForeignKey, связанный с одним сотрудником (отношение 1-1), но яне удалось заставить его работать, потому что на этапе программирования мне придется вручную проверять, является ли выбранный идентификатор позиции (в элементе выбора HTML) идентификатором «Driver».Я считаю, что это не очень хорошая практика программирования.

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

Заранее спасибо!И извините за плохой английский, это не мой основной язык.Я надеюсь, что вы можете понять.

Answer 1

Это бизнес-правило, которое гласит: «С транспортным средством может быть связан только сотрудник с положением = вождение». Бизнес-правила обычно реализуются в программировании, и это неплохая практика. Программирование сделано для написания бизнес-логики. В общем, вы получите тонны такого экземпляра, который невозможно реализовать на уровне базы данных при разработке какого-либо приложения.

Однако, если вы все еще хотите контролировать это на уровне БД, вы можете использовать триггер и проверить эту проверку на уровне вставки / обновления.

Answer 2

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

Answer 3

Есть несколько способов сделать это с различными компромиссами.У Скотта Эмблера есть отличная страница с перечнем альтернатив с диаграммами.

Answer 4

Лучший способ сделать это, вероятно, иметь таблицу EmployeeVehicles, которая соединяет сотрудников с транспортными средствами. Да, это означает, что ваше приложение (или, возможно, триггер или хранимая процедура) должны будут гарантировать, что только конкретные типы Employee будут иметь запись в EmployeeVehicles, но это, как правило, лучшие места для хранения вашей бизнес-логики. , База данных предназначена для хранения данных в максимально возможной степени, а не для отслеживания правил, специфичных для бизнеса. Насколько это необходимо знать, некоторые сотрудники (0 .. *) могут иметь транспортные средства (1 .. * или, возможно, 1..1).