ERD - Диаграмма отношений сущностей - сложные и хитрые отношения

Вот сценарий.

Две совершенно разные Сущности независимо связаны с третьей Сущностью таким же образом. Как мы представляем это в ERD? или (Расширенный ER)

Ex:

  • Студенческая КНИГА "ЗАИМЫ" (из библиотеки)
  • КНИГА ОТДЕЛА "ЗАИМЫ" (из той же библиотеки).

Если я дважды определю отношение 'ЗАМЯТЫ', это будет неуклюже и неуклюже с точки зрения внешнего вида на диаграмме, а также усложнит реализацию.

В то же время я не могу объявить тернарную связь, так как СТУДЕНТ и ОТДЕЛ не взаимосвязаны в экземпляре отношения.

Однако лучшего способа я не нашел.

Как мне это решить?


database entity-relationship erd
person Firefox    schedule 23.09.2011    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Если верить Википедии, Enhanced ER допускает наследование. Почему бы вам не иметь объект ЗАЕМЩИК (с соответствующим отношением) и не иметь подклассов СТУДЕНТ и ОТДЕЛ?

person NPE    schedule 23.09.2011
comment
Спасибо за ответ aix. Это определенно решение. Меня просто интересует сложность при реализации, т.е. создание таблицы. Если бы это имело место в контексте программирования, то это было бы наиболее подходящим решением. Я все еще не уверен в контексте БД. - person Firefox; 23.09.2011
comment
@Firefox: Какую настоящую проблему вы пытаетесь решить, кроме неуклюжего и неуклюжего вида на диаграмме? - person NPE; 23.09.2011
comment
Я просто ищу решение, менее сложное во время реализации, но отвечающее всем требованиям. Когда я упомянул, неуклюжий и неуклюжий, это был случай с двумя повторяющимися отношениями, который также приводит к нескольким таблицам в БД. - person Firefox; 23.09.2011
comment
@Firefox: отношения не приводят к таблицам, это делают сущности. Я не вижу ничего плохого в том, чтобы иметь отношения с двумя заимствованиями. Если это вызывает проблемы (например, при именовании внешних ключей), дайте им немного другие имена. - person NPE; 23.09.2011
comment
Может быть, я что-то упускаю. Но, я считаю, что отношения приводят к таблице. Например: связь BORROWS приводит к некоторой таблице, такой как BORROW_RECORD, в которой хранятся внешние ключи STUDENT/DEPARTMENT и BOOK, а также некоторые атрибуты, такие как Start_date и т. д. - person Firefox; 23.09.2011
comment
@Firefox: Вы правы, я отзываю свой предыдущий комментарий: то, что вы говорите, конечно, верно для отношений «многие ко многим». Но тем не менее, я бы просто удостоверился, что генерируемые вещи просто получают разные имена, вот и все. - person NPE; 23.09.2011
comment
Наконец, я как бы представлял сущность ЗАЕМЩИКА в ERD. Поскольку отношение подкласса является непересекающимся и полным, по-видимому, нет необходимости создавать эту таблицу BORROWER в БД. ERD (концепции подкласса, суперкласса и т. д.) предназначен для добавления семантической ясности. - person Firefox; 26.09.2011

arrow_upward
0
arrow_downward

У меня была аналогичная проблема - где компания или человек может заказать продукт.

У вас есть order, который может принадлежать либо person, либо company — так с чем вы связываете отношения? Я думаю, что заказы будут иметь внешний ключ companyId и personId, но как сделать их эксклюзивными? Возвращаемые данные не обязательно будут одинаковыми — например, company не имеет поля first name/last name.

Я предполагаю, что это можно сделать, вернув name, а в случае person построить строку из firstname/lastname, а в случае company использовать поле companyname.

person Perry    schedule 21.11.2011
comment
Я сделал это путем обобщения. Например: в вашем случае я бы создал таблицу клиентов. Person & Company являются его подклассами. Клиент содержит идентификатор клиента. OrderInfo указывает на customerId, из которого вы можете узнать, был ли ваш заказчик компанией/человеком. - person Firefox; 28.11.2011