Database design 将三元关系分解为二元关系

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

• 一个帐户有许多用户
• 一个用户属于多个帐户
• 一个帐户有许多项目
• 一个项目只属于一个帐户
• 用户在许多项目中进行协作（冗余说明：每个项目都属于自己的帐户）

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

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

这里出现了两个问题：

这个转换正确吗？我发现我必须在应用程序级别添加额外的检查来处理插入。例如，在添加新的

（用户，项目）

之前，我必须检查该用户是否属于该项目所属的同一帐户

是否确实需要在

帐户

和

用户

之间建立关系？一旦添加了

用户

和

项目

之间的关系，我们就不能通过访问项目来知道用户所属的帐户吗

谢谢

这个转换正确吗

如果你所说的“正确”是指“同等”，那么就不是

没有任何东西可以阻止您在不连接用户（等）的情况下连接项目和帐户，这在真正的三元关系中是不可能的

是否真的有必要建立帐户和用户之间的关系。。。我们不能通过访问项目来知道用户所属的帐户吗

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

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

---

在我看来，如果你需要一个三元关系，就直接在物理模型中表示它吧。如果我正确理解了您的要求，这将类似于：

---

注意

AccountId

如何在

Collaboration

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

我喜欢你的方法，但很多人建议默认分解，因此我的问题是。谁建议默认分解？@elitalon永远不要因为有人（包括我！）告诉你。始终了解你在做什么以及为什么要这样做，否则你会这样做。@TonyAndrews经过彻底的谷歌搜索后，你会大吃一惊：p@aryan我不确定OP的第二种型号如何“消除冗余”。作为一般规则，数据库级别的声明性完整性应优先于应用程序级别的完整性。原因有很多，但简单来说：DB约束最小化了出错的机会（通过其声明性），促进了重用（因为它们是集中的，不能被有缺陷的应用程序绕过）在某些情况下，应用程序级别的完整性是合理的，但DB完整性应该是您的“默认”选择。