当我们有N:M递归关系时,创建关系模式的最佳方法是什么?
在我搜索的各种书籍中,他们分析了1:1和1:N的递归关系,但对于N:M几乎没有。
我是否应该像传统的N:M非递归关系一样对待它?
例如,在这种递归关系中,最好是:
A.创建一个新的关系
INVITE(InviterId,InviteeId,AcceptanceDate,InvitationDate) - 以粗体显示主键。在这种情况下,它们也是外键。
////
B.在Person Entity中包含此关系
PERSON(ID,密码,InviterId,InviteeId,AcceptanceDate,InvitationDate)。
///
定义是递归的,而不是关系/关联。您似乎在谈论FK(外键)循环或FK引用其自己的表的特殊情况。 FK约束表示值在别处显示为PK / UNIQUE。或者,满足一种关系的值仅以一种方式满足另一种关系。从关系设计的角度来看,没有什么特别之处。当显式/声明的FK图不是树时,大多数SQL DBMS都是不必要的。
是否可以或应该组合表取决于您使用的信息建模和数据库设计方法以及关系数据库设计原则。有许多不同的“传统”。查找并遵循已发布的关于信息建模,关系模型和数据库设计的学术教科书。 (有数十种免费在线,也有幻灯片和课程。)PS有关管理设计的工具的信息和手册不构成如何设计的介绍。
您给出的图是陈原始真正的纯ER(实体关系)图。在该方法下,您无法将实体和关系组合成关系,因为实体需要拥有自己的框和表。但是你可以在关系模型和伪ER方法和产品中使用不在图中使用钻石的方法和允许在陈图中进行更多选择的方法。