将ER模型转换为RDB时将外键作为主键答案

【问题标题】：Foreign Key as Primary Key when converting ER model to RDB将ER模型转换为RDB时将外键作为主键
【发布时间】：2018-05-25 00:06:44
【问题描述】：

大家好，我正在尝试使用 mysql 实现数据库模型。当我尝试将 E/R 数据库模型转换为关系数据库模型时，有一件事让我印象深刻。那么问题来了。

*请记住，ERDB 的“关系”和 RDB 的“关系”是不同的。

据我所知，以下是ER实体集和关系转RDB关系的标准。

Entity Sets
: Simply use all the attributes as columns (key attributes become the primary key).

Relationships (Many-Many)
: Use key attributes (from both entity sets) as table columns.

所以这意味着当我尝试为任何关系创建表时，我必须从现有表中获取键（键）（如外键）。

但是当我查看时，几乎每个人都告诉我我不应该使用引用的外键作为该表的主键（因为外键应该允许非唯一值）。这没有意义，因为各种关系都必须引用实体集（关系）中的键。

我很困惑，请有人帮帮我！

【问题讨论】：

ER 到底是什么意思？ True Chen ER 具有明确的关系类型，所有参与实体类型。（可能是关联的，即关系类型的具体化）。即（非关联）实体关系/表中没有外键。而其他（伪）ER 方法将多：1 关系关系/表推入多方关系/表。在真正的 ER 术语中，这将实体转换为关系并将所有关系具体化为关联实体。但真正的 ER 是一种不必要的限制性方法，无论如何都不能正确使用关系模型。

标签： database-design entity-relationship rdbms

【解决方案1】：

使用外键作为主键没有任何问题，也没有规定外键应该允许非唯一值。

有些人更喜欢代理标识符而不是复合键，后者往往由外键组成。有些人会争辩说，可以将具有单个外键作为主键的表非规范化为引用的表。总之，这些方法可以消除外键作为主键。

另一方面，每个代理标识符都添加了一个无意义的间接级别并强制执行某些访问路径（谷歌“访问路径独立性”）。对具有相同主键的表进行非规范化也不总是一个好主意 - 它们可能记录具有不同生命周期的谓词，并且组合表可能需要引入空值，这会增加它们自己的问题。

简而言之，使用外键作为主键是一种有效的方法。无论您是否这样做，都请尝试了解您的决定的后果，不要盲目地遵循规则。

PS。从技术上讲，我们不会将实体集转换为关系。实体集由映射到关系模型中的域的实体键表示。实体关系是从实体集映射到值集的关系。这是一个微妙的区别，但在面向事实的建模中很重要。表/关系表示谓词的扩展，任意数量的谓词都可以描述单个实体集。

将关系映射到关系的更一般规则是使用“许多”角色中实体集的键作为主键。这适用于二元一对多和多对多关系，以及三元和更高的关系。一对多关系通常被非规范化为实体关系，但在我看来，这是一种物理模型优化。

【讨论】：

我将实体集和值集视为域。您介意指出陈的论文的具体部分吗？
见2.3.2前段“EMPLOYEE-NO值集合中的每个值代表一个实体”，2.3.2小节，对比图4和图7，后者代表一个实体关系没有前者中存在的概念实体集列。
您的引述谈论的是代表信息而不是代表实体，我看不出它如何支持您的论点。图 4 区分了实体集和实体关系，图 5 清楚地显示了实体集在关系中的角色，由图 8 中对应的值集表示。
我决定我真的不知道你在你的 PS 中想说什么。我不明白您所说的“转换”、“表示”或“映射”是什么意思。（显然，当您的意思是每个元素都转换/映射到事物时，您有时会说集合转换/映射到事物。）所以我不会保持任何立场，除非您的 PS 不清楚。我希望我的 cmets 没有做出我所说的那种不清楚的措辞。（PS 我想说一个表代表给定情况下谓词的扩展（满足元组）。）
很抱歉您删除了您的 cmets - 即使我们无法达成协议，其他人也可以从比较不同的观点中受益。不过，我可以同意你最后的 PS。

【解决方案2】：

您不应使用关系表中的一个外键作为该表的主键。这会过度约束表，因为它会强制实体表之一和关系表之间的关系是一对一的。这不是你想要的。

但是，没有规则说您不能将关系表的两个外键变成复合主键。如果您还没有了解复合主键（有时称为复合主键），您应该了解它。在你这样做之前，你会对关系模型本身有些困惑。

正如 reaanb 所说，一些数据库构建者更喜欢在关系表中添加一个单独的列作为主键。但有些只是创建一个复合主键。

将 ER 模型转换为关系模型是相对机械的，但并非微不足道。如果你擅长这两种模型，你可能会发现使用 ER 模型分析主题和使用关系模型进行数据库设计对你有利。

【讨论】：

顺便说一下，我将“foo bar”追溯到大约 1961 年的 Tech Model Railroad Club。