表示多值属性答案

【问题标题】：representing multivalued attributes表示多值属性
【发布时间】：2014-06-30 09:39:20
【问题描述】：

我正在阅读 Teorey、Simison 等人的《数据库设计》一书。在某一点上，它解释了如何将具有多值属性的实体映射到关系表中。示例如下，其中多值属性为 hobby。

 Employee(Employee_ID(PK),name,surname,hobby)

导致两个表

 Employee(Employee_ID(PK),name,surname)
 Hobby(Employee_ID(PK),hobby(PK))

这本书或多或少说“给定一个具有主键 p 的实体 E，附加到 ER 图的多值属性 E 被映射到一个它自己的表，其主键由 p 和属性值组成（ s) 一个"。这是一般规则吗？考虑与多值属性书的以下关系。

 Author(Author_ID(PK),name,book)

创建以下两个表还不够吗，其中书的 PK 只是 Book_ID 和 Author_ID 是一个 FK 而不会成为书的 PK 的一部分？

 Author(Author_ID(PK),name)
 Book(Book_ID,book,Author_id(FK))

【问题讨论】：

【解决方案1】：

你是对的；您没有必须在 Hobby 或 Book 中使用复合主键，但如果您愿意，当然可以。 this question 的公认答案很好地概述了您何时可能希望使用其中一个。

顺便说一句，如果您要实际实现您的示例，您可能需要三个表：Author、Book 和它们之间的 associative entity，因为一个作者可能写很多书，而一本书可能有很多作者.

【讨论】：

但是如果不同的员工有相同的爱好呢？如果仅将爱好名称用作 PK，则会导致重复密钥。我也在其他地方看到过这个爱好的例子，比如这里tomjewett.com/dbdesign/dbdesign.php?page=hobbies.php
我不确定 Teorey 是如何处理这个问题的，但我认为区分“多值属性”和“多对多关系”很有用。我还认为区分 ER 建模和关系建模很有用。在关系建模中，FK 是实现关系的手段。在 ER 建模中，关系被指出，但未实现。
@AlfioCastorina：您是正确的，在您在问题中提出的两表结构中，您不能单独使用爱好名称作为主键，因为它可能会为不同的员工重复。但是，与您的 Book/Author 示例一样，您可以引入另一个字段作为主键，例如 Hobby_ID。这称为surrogate key，其唯一目的是唯一标识一个爱好；它并没有告诉你任何关于爱好本身的信息。
显然，如果仅将 hobby 名称用作键，则会出现问题，因为我可能有类似 (001,fishing)、(002,fishing) 之类的东西，但如果两个值都用作键，则一切正常.在某种程度上，组合键的作用类似于多对多关系中关联表的属性。
@JoeFarrel 代理键不会导致同样的问题吗？？？不同的员工显然可以有相同的爱好（即03），所以我会有类似（01,03），（02,03）的东西。

【解决方案2】：

创建以下两个表是否足够，其中书籍的 PK 只是 Book_ID 和 Author_ID 是 FK 而不会成为书籍 PK 的一部分？

你错了，拥有候选键 {book_id} 就足够了，因为只有当作者的书集不重叠时才会如此。如果它们确实重叠，您需要 {book_id, author_id}。

尽管新的 PK 必然是两列的组合，但您的书是错误的。（同理，如果员工的爱好不重叠，那么hobby_id就是Hobby的候选键。）所以书中的列变换是正确的，但是你必须自己确定每个新表的候选键。

请参阅this answer 重新关联设计。

【讨论】：