为什么不在ER模型中关联具有主键的属性？

Question

为什么在ER模型中，关联不应具有主键属性？

我知道稍后，关联通常映射到数据库表，其中主键由连接到该关联的两个（或更多）实体的外键形成。

但从纯粹的ER建模角度来看，原因是什么？有没有？

Answer 1

当允许关联表具有多个具有相同外键组合的行时，会出现问题。如果发生这种情况，那么对各种不同的属性值应用什么含义？

有时这就是你想要的。可能是两个实体可能具有多个具有不同属性的同时关系。但那将是非常不寻常的。

数据库设计在自然地模拟现实世界关系时效果最佳，特别是如果数据库设计可以自动和结构上排除错误或无意义的数据。

Answer 2

我同意Jeffrey Whitledge的所有回答。也：

您的问题与代理键的问题有关，代理键是为索引表而生成的，例如SQL Server IDENTITY列。您应该坚持使用候选键，例如：如果你想留在“纯ER”建模的领域，由外键形成的复合键。如果您正在使用候选键，那么您可能不在结构上排除了Whitledge先生所指出的不良或无意义的数据。这适用于协会以及其他类型的实体。

也就是说，候选键确实具有一些实际优势，具体取决于您正在使用的环境。例如，MS Access处理代理键比正确定义的复合键更容易。在其他环境中，能够存储对行的引用，因为32位int很有用。我实际上已经看到了向所有实体应用代理键的演示文稿被提出作为“最佳实践”，这使得事情有点远。关键是你从代理人那里获得了一些简单性。您可以将候选项与候选键上正确定义的唯一索引结合使用。附注 - 使用IDENTITY列作为您创建的实体（如发票）的主键是有效的：在这种情况下，IDENTITY列实际上不是代理项。

如果您的关联不有任何属性，那么我怀疑添加代理密钥将有任何好处，无论您喜欢代理密钥多少。如果要向关系实体添加非外键属性，则可能会看到添加代理项的一些好处，因为您可能需要选择关系本身。在这种情况下，您应该在外键上定义唯一索引，除非您想允许重复关系。

Answer 3

谁说它不应该？模型应具有所需的任意数量的属性和键，以表示正在建模的任何内容。每个表（或实体）应至少有一个密钥。