mysql - 多个外键 ERD

Question

我对架构中使用相同的 FK 有疑问。问题来了

|=======================================|
|                 Book                  |
|=======================================|
| Book_ID (PK)| Cover_Paper | Page_Paper|
|-------------|-------------|-----------|

|====================================|
|                Paper               |
|====================================|
| Paper_ID (PK)| Paper_Type | weight |
|--------------|------------|--------|

比方说，我有不同类型、不同重量的纸张用于打印封面和页面。

所以我需要将 Paper_ID 作为 FK 插入 Book 表中。问题是，使用与 FK 不同的列名是错误的。如果我将表更改为相同的列名，那就太奇怪了。

|==========================================|
|                   Book                   |
|==========================================|
| Book_ID (PK)| Paper_ID(FK) | Paper_ID(FK)|
|-------------|--------------|-------------|

对这个问题有什么帮助吗？

Answer 1

列名与列的域名不同并没有错。事实上，很多时候这是必要的。

替代方案 - 具有相同名称的两列 - 是不好的。您如何知道哪一列表示封面纸和哪一页纸？按职位？这将内容的含义与数据的物理表示联系起来。如果我选择 Book_ID 并仅选择 Paper_ID 列之一，会发生什么情况？如果没有额外的外部信息，人们不会知道这些数据意味着什么。相反，附加信息应该是表示的一部分，以便它尽可能具有 self 描述性。

在每个角色都由唯一域填充的关系中，很容易将域名称用作角色名称，而不会造成混淆。如果一本书由单一类型的纸张组成，那么谈论这本书的纸张是有意义的。 自行车座椅和人的 Nose 也是如此。

但是，当一个关系有多个相同类型的事物时，我们需要指示每个事物的角色。像您一样区分 Cover_Paper 和 Page_Paper 是正确的方法。 (SQL DBMS 没有为每一列提供单独的角色和域名，这太糟糕了，但我离题了。)

您可以将其称为 Cover_Paper_ID 和 Page_Paper_ID，这是一种将 ID 附加到代理标识符列的行业惯例，尽管我认为没有它读起来更好。在其他关系中，通常只写角色而不写域就足够了 - 例如在 Marriage 中，我们可能会有 Husband 和 Wife 列，而不是写 Husband_Person 和 Wife_Person.

Edgar Codd(大型共享数据库数据关系模型的作者)和 Peter Chen(实体关系模型 - 走向统一数据 View 的作者 em>)讨论他们论文中的角色。我强烈建议学习两者，特别是因为很少有在线资源提到这个主题。