对引用相同主键的两个外键进行数据建模答案

【问题标题】：Data Modeling Two Foreign Keys Referencing the Same Primary Key对引用相同主键的两个外键进行数据建模
【发布时间】：2012-07-06 06:36:18
【问题描述】：

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

例如：

表作者有主键 AUTHOR_ID

Table Book 有两个外键 PRIMARY_AUTHOR_ID 和 SECONDARY_AUTHOR_ID 都引用 AUTHOR_ID

这是什么类型的关系？

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

【问题讨论】：

咳咳……两个外键关系？我不认为这个特殊的“构造”有任何花哨或吸引人的名字.....
但是在定义表之间的基数时，您会认为关系是 1..1 还是 1..n？
好吧，PRIMARY_AUTHOR_ID 很可能是 1:1（必需）关系，而 SECONDARY_AUTHOR_ID 很可能是 0:1（可选） - 但这只是我的猜测部分
也许我应该提到我正在尝试将其放在 ER 图中
添加关系两次！表之间有两种不同的关系。

标签： database data-modeling

【解决方案1】：

您在图书与其作者之间设置了 1..[1-2] 关系。换句话说，您在 Book 和主要作者之间具有 1..1 关系，并且您在 Book 和次要作者之间实际上具有 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) 的键和 AUTHORS (AUTHOR_ID) 的另一个键。您还可以添加一列来指定作者顺序，对作者进行排序，主要、次要、三级等...

（注意：我倾向于使用复数来命名表，例如 BOOKS，因为表是一个集合，而 Book 是作为 BOOKS 表成员的一行。当然，从 OOP 中，您倾向于命名使用单数的类，例如 BOOK，Book 是 BOOK 类的一个实例——主要是术语。）

【讨论】：