Диаграммы ER используются для двух разных целей. Одна из целей - проиллюстрировать субъекты субъекта и отношения между ними, как это понимают эксперты по предмету. Это называется концептуальной моделью данных.
Другая цель - проиллюстрировать предлагаемый проект базы данных, где отношения не только выражены, но и реализованы каким-то образом. Если дизайн является реляционным (как правило, он), отношения «многие ко многим» выражаются путем создания промежуточной таблицы. Это называется физической моделью данных (в какой-то литературе она называется логической моделью). Это то, что вы сделали на своей второй диаграмме.
Ваша первая диаграмма может быть очищена немного, исключив коробку с именем «разрешения» и поместив воронку на обоих концах линии, соединяющей Менеджеров и Здания.
Теперь вернемся к вашему вопросу: какой из них «лучше»? Это зависит. иногда концептуальная диаграмма лучше обсуждает предмет с конечными заинтересованными сторонами: нетехническими менеджерами, которые работают с данными все время и могут называться «экспертами по предмету».
Физическая схема обычно лучше при обсуждении предлагаемого дизайна среди архитекторов данных и программистов. Это объясняет не только то, как данные работают в концепции, но также и то, как должна строиться база данных. Эта деталь детализирована концептуальной моделью.
Таким образом, вы можете получить две диаграммы и использовать соответствующую в зависимости от вашей аудитории.
Возможно, это потому, что я не «джентльмен», но я с трудом понимаю, что вы хотите использовать ** Permissions ** table. Кажется, что ваши ERD имеют ограниченное представление о том, как управлять отношениями «многие ко многим» в базе данных. Вы хотите, чтобы ** Менеджеры ** имели много ** Зданий ** _through_ ** Разрешения **? это то, что показывает ваш второй ERD? Это должны быть FK, а не PK – eriese
@eriese Приношу свои извинения. Согласно wiki, «большинство систем управления базами данных поддерживают только отношения« один ко многим ». Именно по этой причине я пытаюсь избавиться от многих-ко-многим между зданиями и менеджерами.Да, я хочу управлять, какие менеджеры управляют зданиями через таблицу разрешений. BuildingID и ManagerID в таблице Permisions является составной PK. – koryakinp
У вас есть представление о том, какие языки/фреймворки и базы данных вы будете использовать для его создания? Я привык к Ruby on Rails с Postgresql, который использует activerecord для очень простого управления отношениями и обрабатывает многих для многих. – eriese