Database 数据建模引用同一主键的两个外键

如果一个表中有两个外键引用另一个表中的同一主键，这是什么类型的关系？一对多？还是一对一

例如：

表Author具有主键Author\u ID

TableBook有两个外键PRIMARY_AUTHOR_ID和SECONDARY_AUTHOR_ID都是引用AUTHOR_ID

这是什么关系

---

*我知道可以更好地处理作者书籍示例，我只是将这些字段用作示例。

看起来您在书籍与其作者之间建立了1..[1-2]关系。换句话说，一本书和一位主要作者之间存在着1..1的关系，而一本书和一位次要作者之间实际上存在着1..[0-1]的关系。有人可能会说，因此，一本书与其作者之间存在着1..[1-2]的关系

这只考虑了等式的一个方向，因为显然一个作者也可以有多本书，所以书（复数）和作者之间的真实关系更像N..[1-2]，这取决于所使用的符号和方法

我知道你刚刚设计了一个例子，以便你可以提出这个问题。关于这一结构的使用，我主张你应该考虑一种更一般的N.M关系的结构（在书和作者之间）。。从设计的角度来看，您不想做的一件事是将太多的业务逻辑硬编码到您的结构表示中。初始业务规则通常会建议您有一个有限的（1..1或1..N）关系，然后是业务需求（微妙地或不那么微妙地）进行更改，现在您需要能够建模N..M。这意味着模式更改，这当然是可能的，但在某些情况下可以预见，可以避免，您可以选择不那么脆弱。（这是另一种说法，过早优化是万恶之源。）

您可能已经知道这一点，但可能是为了其他人的利益，要访问N..M，您需要从BOOKS表中删除两个外键，并引入第三个表：BOOKS_AUTHORS，它将有一个表BOOKS（BOOK_ID）的外键和另一个表AUTHOR（AUTHOR_ID）的外键。您还可以添加一列来指定作者顺序，为主要、次要、三级等作者排序

---

（注意：我倾向于使用复数来命名表，例如BOOKS，因为表是一个集合，而Book是BOOKS表中的一个成员行。当然，从OOP来看，您倾向于使用单数来命名类，例如Book，Book是类Book的一个实例——主要是术语。）两个外键关系？我不认为这个特殊的“构造”有任何花哨或引人入胜的名字……但是，当定义表之间的基数时，你会认为这关系是1…1还是1…？嗯，很有可能< <代码> PrimaYuAuthIId < /C> >为1:1（要求）。关系，而

次要作者ID

最有可能是0:1（可选）-但这只是我的猜测也许我应该提到我正试图将其放在ER图上添加两次关系！表之间有两种不同的关系。