将三元关系分解为二元关系答案

【问题标题】：Decomposing a ternary relationship into binary relationships将三元关系分解为二元关系
【发布时间】：2012-05-22 18:51:08
【问题描述】：

我正在设计一个数据库来处理具有以下关系和约束的用户、帐户和项目：

换句话说，用户可以在同一个帐户的多个项目中进行协作。但是由于一个用户可以属于多个账户，因此一个用户可以在多个账户的多个项目中进行协作。这将我引向三元合作关系：

在阅读了几篇关于将三元关系转换为二元关系的论文后，我提出了以下等价关系：

这里有两个问题：

这种转换是否正确？我发现我必须在应用程序级别添加额外的检查来处理插入。例如，在添加新的(User,Project) 之前，我必须检查用户是否属于项目所属的同一帐户。
Account和User之间真的有必要建立关系吗？加上User和Project之间的关系后，我们不能通过访问项目知道用户所属的帐户吗？

谢谢！！

【问题讨论】：

【解决方案1】：

这个转换正确吗？

如果“正确”是指“等价”，则不是。

没有什么可以阻止您连接项目和帐户没有连接用户（等...），这在真正的三元关系中是不可能的。

真的有必要建立Account和User之间的关系吗？ ...我们不能通过访问项目知道用户所属的帐户吗？

实际上，我们只知道哪些帐户是连接到用户的“候选”帐户，但我们没有好办法选择一个。

这种方案的真正问题在于它允许您将用户连接到与用户的任何项目无关的帐户。

在我看来，如果需要三元关系，直接在物理模型中表示即可。如果我正确理解您的要求，这将如下所示：

注意AccountId 如何在Collaboration PK 之外。这意味着每个项目/用户组合都必须连接到一个帐户（不同的组合仍然可以连接到不同的帐户）。

【讨论】：

我喜欢你的方法，但很多人建议默认分解，因此我的问题。
谁推荐默认分解？
@elitalon 永远不要仅仅因为有人（包括我！）告诉你就去做某事。始终了解您在做什么以及为什么，否则您将成为programming by coincidence。
@TonyAndrews 彻底的谷歌搜索后你会感到惊讶：p
@aryan 我不确定 OP 的第二个模型如何“消除冗余”。作为一般规则，数据库级别的声明完整性应该优先于应用程序级别的完整性。原因有很多，但简而言之：DB 约束最大限度地减少出错的机会（通过它们的声明性），促进重用（因为它们是集中的并且不能被有缺陷的应用程序绕过）并且通常具有更高的性能和可扩展性。在某些情况下，应用程序级别的完整性是合理的，但数据库完整性绝对应该是您的“默认”选择。