嗨伙计们，我正在尝试使用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.
所以这意味着当我尝试为任何关系创建表时，我必须从现有表中引入键（键）（如外键）。
但是当我抬起头时，几乎每个人都告诉我，我不应该使用引用的外键作为该表的主键（因为外键应该允许非唯一值）。这没有意义，因为各种关系必须引用实体集（关系）中的键。
我完全糊涂了，有人请帮助我！
您不应该使用关系表中的一个外键作为该表的主键。这会过度约束表，因为它会强制实体表之一和关系表之间的关系是一对一的。这不是你想要的。
但是，没有规则表明您不能将关系表的两个外键变为复合主键。如果您还没有了解复合主键（有时称为复合主键），您应该了解这一点。在你这样做之前，你会对关系模型本身感到有些困惑。
正如reaanb所说，一些数据库构建者更喜欢在关系表中添加一个单独的列作为主键。但有些人只是创建一个复合主键。
将ER模型转换为关系模型是相对机械的，但非常重要。如果您擅长这两种模型，您可能会发现使用ER模型分析主题和数据库设计的关系模型对您有利。
使用外键作为主键没有任何问题，并且没有规则说外键应该允许非唯一值。
有些人比复合键更喜欢代理标识符，复合键往往由外键组成。有人会争辩说，将一个外键作为主键的表可以非规范化为引用表。总之，这些方法可以消除外键作为主键。
另一方面，每个代理标识符添加无意义的间接级别并强制执行某些访问路径（谷歌“访问路径独立性”）。使用相同的主键对表进行非规范化也不总是一个好主意 - 它们可能正在记录具有不同生命周期的谓词，并且组合表可能需要引入添加其自身问题的空值。
简而言之，使用外键作为主键是一种有效的方法。无论你是否这样做，试着去了解你的决定的后果，而不是盲目地遵循规则。
PS。从技术上讲，我们不会将实体集转换为关系。实体集由实体键表示，实体键映射到关系模型中的域。实体关系是从实体集映射到值集的关系。这是一个微妙的差异，但在事实导向建模中是一个重要的差异。表/关系表示谓词的扩展，任何数量的谓词都可以描述单个实体集。
将关系映射到关系的更一般规则是使用“many”-roles中的实体集的键作为主键。这适用于二进制一对多和多对多关系，以及三元和更高关系。一对多关系通常被非规范化为实体关系，但在我看来，这是一种物理模型优化。