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

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

An account has many users A user belongs to many accounts An account has many projects A project belongs to only one account A user collaborates in many projects (redundant note: each one of them belonging to its own account).

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

enter image description here

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

enter image description here

Здесь возникает два вопроса:

Is this conversion correct? I have found that I have to add additional checks at application level to handle insertions. For instance, before adding a new (User,Project) I have to check that the user belongs to the same account that the project belongs to.

Is it really necessary to establish the relationship between Account and User? Once the relationship between User and Project has been added, couldn't we know the account a user belongs to by accessing the project?

Спасибо!!

Ответы на вопрос(1)

Решение Вопроса

Если по & quot; исправить & quot; Вы имеете в виду «эквивалент», а затем нет.

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

Is it really necessary to establish the relationship between Account and User? ... couldn't we know the account a user belongs to by accessing the project?

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

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

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

enter image description here

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

 elitalon15 мая 2012 г., 15:25
@TonyAndrews Вы будете удивлены после тщательного поиска в Google: p
 15 мая 2012 г., 14:50
Кто рекомендует разложить по умолчанию?
 27 сент. 2012 г., 11:42
@aryan Я не уверен, как вторая модель OP устраняет избыточность. Как правило, декларативная целостность на уровне базы данных должна быть предпочтительнее целостности на уровне приложения. Причин множество, но в двух словах: ограничения БД минимизируют вероятность ошибок (благодаря их декларативному характеру), способствуют повторному использованию (поскольку они централизованы и не могут быть обойдены ошибочным приложением) и, как правило, более производительны и масштабируемы. Существуют случаи, когда целостность на уровне приложения оправдана, но целостность БД должна определенно быть вашей "по умолчанию". выбор.
 elitalon15 мая 2012 г., 14:48
Мне нравится ваш подход, но многие люди рекомендуют разложить по умолчанию, поэтому мой вопрос.
 15 мая 2012 г., 14:54
@elitalon Никогда не делай что-то только потому, что кто-то (включая меня!) говорит тебе Всегда понимаю, что ты делаешь иwhyв противном случае вы будетеprogramming by coincidence.

Ваш ответ на вопрос