Разложение тернарных отношений на бинарные отношения

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

  • Аккаунт имеет много пользователей
  • Пользователь принадлежит многим учетным записям
  • У аккаунта много проектов
  • Проект принадлежит только одному аккаунту
  • Пользователь участвует во многих проектах (лишнее примечание: каждый из них принадлежит своей учетной записи).

Другими словами, пользователь может сотрудничать во многих проектах одной и той же учетной записи. Но поскольку пользователь может принадлежать нескольким учетным записям, то пользователь может сотрудничать во многих проектах нескольких учетных записей. Это приводит меня к троичной связи collaborates:

введите здесь описание изображения

Прочитав пару статей о преобразовании троичных отношений в бинарные, я пришел к следующим эквивалентным отношениям:

введите здесь описание изображения

Тут возникает два вопроса:

  1. Правильно ли это преобразование? Я обнаружил, что мне нужно добавить дополнительные проверки на уровне приложения для обработки вставок. Например, перед добавлением нового (User,Project) я должен убедиться, что пользователь принадлежит к той же учетной записи, которой принадлежит проект.

  2. Действительно ли необходимо устанавливать связь между Account и User? Как только отношения между User и Project будут добавлены, не можем ли мы узнать, к какой учетной записи принадлежит пользователь, получив доступ к проекту?

Спасибо!!


database-design entity-relationship
person elitalon    schedule 15.05.2012    source источник

Ответы (1)


arrow_upward
14
arrow_downward

Правильно ли это преобразование?

Если под "правильным" ты подразумеваешь "эквивалентный", то нет.

Ничто не мешает вам соединить проект и учетную запись без подключения пользователя (и т. д.), что было бы невозможно в реальных троичных отношениях.

Действительно ли необходимо устанавливать отношения между Аккаунтом и Пользователем? ... разве мы не можем узнать, к какой учетной записи принадлежит пользователь, войдя в проект?

На самом деле мы знали бы только, какие учетные записи являются «кандидатами» для подключения к пользователю, но у нас не было бы хорошего способа выбрать одну из них.

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

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

введите здесь описание изображения

Обратите внимание, что AccountId находится за пределами Collaboration ПК. Это означает, что каждая комбинация проекта/пользователя должна быть связана только с одним аккаунтом (другая комбинация может быть связана с другим аккаунтом).

person Branko Dimitrijevic    schedule 15.05.2012
comment
Мне нравится ваш подход, но многие рекомендуют декомпозировать по умолчанию, отсюда и мой вопрос. - person elitalon; 15.05.2012
comment
Кто рекомендует раскладывать по умолчанию? - person Tony Andrews; 15.05.2012
comment
@elitalon Никогда не делайте что-то только потому, что кто-то (включая меня!) говорит вам об этом. Всегда понимайте, что вы делаете и почему, иначе вы будете программирование по совпадению. - person Branko Dimitrijevic; 15.05.2012
comment
@TonyAndrews Вы удивитесь после тщательного поиска в Google: p - person elitalon; 15.05.2012
comment
@elitalon - я только что провел поиск в Google и получил много результатов, но все они, похоже, включали покупку PDF-файла, чтобы увидеть ответ! У вас есть ссылка на что-нибудь в свободном доступе? Мне любопытно, но не настолько, чтобы сунуть руку в карман! - person Tony Andrews; 15.05.2012
comment
@elitalon Позвольте мне процитировать заключение Джонса и Сонга «Бинарные эквиваленты троичных отношений в моделировании отношений сущностей: подход к логической декомпозиции»: В этой статье мы показали, что логические (полностью эквивалентные) декомпозиции существуют для определенных комбинаций. троичных/бинарных мощностей, но у большинства нет полных (логических и практических) эквивалентов. - person Branko Dimitrijevic; 15.05.2012
comment
Какое совпадение! Эта статья была одним из источников, которые я читал, чтобы попытаться разложить тройные отношения. Это предложение было именно тем, что заставило меня задать этот вопрос - person elitalon; 15.05.2012
comment
Настоящая проблема с этой схемой заключается в том, что она позволяет подключить пользователя к учетной записи, не связанной ни с одним из проектов пользователя. Вот почему elitalon написал, что вы должны размещать проверки на уровне приложений. Есть ли преимущества разложения? Возможно, устранение избыточности, но хороший ли это компромисс? - person VJune; 27.09.2012
comment
@aryan Я не уверен, как вторая модель OP устраняет избыточность. Как правило, декларативная целостность на уровне базы данных предпочтительнее целостности на уровне приложения. Причин много, но в двух словах: ограничения БД минимизируют вероятность ошибок (благодаря своей декларативной природе), способствуют повторному использованию (поскольку они централизованы и не могут быть обойдены приложением с ошибками) и, как правило, более производительны и масштабируемы. Есть случаи, когда целостность на уровне приложения оправдана, но целостность базы данных определенно должна быть вашим выбором по умолчанию. - person Branko Dimitrijevic; 27.09.2012