将三元关系分解为二元关系
eli*_*lon 9 database-design entity-relationship
我正在设计一个数据库,使用以下关系和约束来处理用户,帐户和项目:
- 一个帐户有很多用户
- 用户属于许多帐户
- 一个帐户有很多项目
- 一个项目只属于一个帐户
- 用户在许多项目中进行协作(冗余注释:每个项目都属于自己的帐户).
换句话说,用户可以在同一帐户的许多项目中进行协作.但由于用户可以属于多个帐户,因此用户可以在多个帐户的许多项目中进行协作.这引导我建立三元合作关系:
在阅读了几篇关于将三元关系转换为二元关系的论文之后,我想出了以下等价关系:
这里出现两个问题:
这种转换是否正确？我发现我必须在应用程序级别添加额外的检查来处理插入.例如,在添加新内容之前,
(User,Project)我必须检查用户是否属于项目所属的同一帐户.难道真的有必要建立的关系
Account和User？一旦添加了User和之间的关系Project,我们不能通过访问项目知道用户所属的帐户吗？
谢谢!!
Bra*_*vic 13
这种转换是否正确？
如果"正确"你的意思是"等同",那么没有.
如果没有连接用户(等等),没有什么可以阻止你连接项目和帐户,这在真正的三元关系中是不可能的.
是否真的有必要建立帐户和用户之间的关系？...我们不能通过访问项目知道用户所属的帐户吗？
实际上,我们只知道哪些帐户是与用户连接的"候选人",但我们没有办法选择一个.
此方案的真正问题在于,它允许您将用户连接到与任何用户项目无关的帐户.
在我看来,如果你需要一个三元关系,那就继续直接在物理模型中表示它.如果我正确理解您的要求,这将看起来像这样:
注意AccountId外面的CollaborationPK 怎么样.这意味着每个项目/用户组合必须只连接到一个帐户(不同的组合仍然可以连接到不同的帐户).
- @elitalon不要因为某人(包括我!)告诉你的事情而做某事.总是明白你在做什么,**为什么**,否则你将[巧合编程](http://pragprog.com/the-pragmatic-programmer/extracts/coincidence). (2认同)
- @aryan我不确定OP的第二个模型如何"消除冗余".作为一般规则,数据库级声明完整性应优先于应用程序级完整性.原因很多,但简而言之:数据库约束可以最大限度地减少错误的机会(通过它们的声明性质),促进重用(因为它们是集中的,不能被错误的应用程序绕过),并且通常性能更高,可扩展性更高.在某些情况下,应用程序级完整性是合理的,但数据库完整性最终应该是您的"默认"选择. (2认同)