Диаграмма ER - избегая взаимных отношений

Question

Я работаю над диаграммой ER для университетского проекта. Речь идет о транспортной компании. Эта компания выполняет конкретные задания для других компаний и для каждой работы, существует три типа документов, и эти документы имеют уникальные идентификаторы среди других документов того же типа. Таким образом, я сделал эти типы документов как отдельные объекты. Теперь, когда я хочу присоединиться к ним (назовите их Doc1, Doc2, Doc3) в одну сущность (назовите это Job), они в основном сделаны только для одной работы и ни для кого другого. Кроме того, эта работа имеет только один из каждого из этих документов, поэтому, похоже, отношения между документами и заданием являются взаимно однозначными. Однако, когда профессор преподавал нам ER-модели, он сказал, что мы всегда должны избегать рисования отношений «один к одному» (что должен быть способ сделать эти документы видными атрибутами работы). Поэтому я хочу знать, правильно ли использовать идентификаторы этих документов в качестве атрибутов задания, а затем сделать их внешними ключами, ссылающимися на соответствующие поля в таблице документов (в модели отношений)? Или есть ли другой, более элегантный способ связать их, как-то избегая этих отношений «один-к-одному»? Кроме того, если я так делаю, я должен сделать все 3 столбца, представляющие идентификаторы документов UNIQUE в таблице Job, правильно? Чтобы я не делал двух заданий, например, одного Doc1? Спасибо!

Answer 1

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

Примером является взаимосвязь между Домом и Лотом. Дом должен быть расположен на Лоте, и только один Дом может быть расположен на любом Лоте, но Лот может существовать до того, как Дом будет построен. Если вы моделируете эти отношения, у вас должно быть отношение «один к нулю» или «один» между Lot и Home. Было бы показано, как это:

В вашем случае у вас есть три отдельных зависимостей, так что это будет выглядеть так:

Физически эти отношения могут быть представлены двумя способами :

1. Нулевой внешний ключ в строке «один» (Лот, в моем примере выше), или
2. Не-обнуляемым внешний ключ в строке «ноль или один» (Home, в моем примере выше)

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

Вы можете решить, чтобы база данных обеспечивала ограничение уникальности (тот факт, что только один Дом может находиться на Лоте). В некоторых базах данных значение null принимает участие в ограничениях уникальности (другими словами, уникальный индекс может иметь только одну запись Null). В такой базе данных вам будет ограничен второй подход. В MySQL это не так; ограничение уникальности игнорирует нулевые значения, поэтому вы можете выбрать любой из них. Второй подход более распространен.