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

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

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

[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

Проблема в том, что одно транспортное средство я должен связать с одним сотрудником, чья должность в компании "Водитель", и только в этом случае.

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

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

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


inheritance database relational
person Philipe    schedule 25.06.2010    source источник

Ответы (4)


arrow_upward
1
arrow_downward

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

person Andy Dent    schedule 25.06.2010
comment
Спасибо, Энди, эта страница действительно помогла мне! Именно то, что я искал. В моем случае я использовал общую структуру таблицы, которая также позволяет пользователям добавлять дополнительные поля для различных типов должностей в компании. Спасибо всем за все ответы. - person Philipe; 25.06.2010

arrow_upward
5
arrow_downward

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

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

person Ramesh Soni    schedule 25.06.2010

arrow_upward
2
arrow_downward

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

person S..    schedule 25.06.2010

arrow_upward
0
arrow_downward

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

person drharris    schedule 25.06.2010