我正在尝试将数据库从 ER 模型转移到关系数据库作为考试练习。
但是，我非常不确定我的解决方案是否有意义。尤其是location 和has 之间的两种关系会产生很大的问题。我想我可以将一个 ZipCode 作为常规主键添加到表中，并将第二个 ZipCode 作为外键。如果有人可以帮助我，我将不胜感激。
到目前为止我的解决方案：
【问题讨论】：
标签： relational-database entity-relationship
如果您使用此 Chen ER 图遵循 Chen ER 设计，那么您需要为每个实体类型框和每个关系（关联）类型菱形和一个关系类型的每个参与/角色行的 FK（外键）提供一个表.
（在 Chen 的上下文中将线/FK 称为“关系”或“关联”是一个坏主意，因为菱形/表格代表关系类型，而线/FK 代表参与。）
因此，您的 Ship tourID 将被删除以支持关系/表 takes 与行/FK 到 Ship 和 Tour。在has 到Location 的表中有两个FK。关系表中的列名与参与者表中的不同列名并不重要。 FK 只是说某些表和列列表中的值出现在其他表和列列表中。该图显示名称为start 和target；使用它们。
不要使用像 has 这样的软弱无用的名称。如果您选择了一个更好的名称和/或在三个实体满足has 关系时进行了解释，那么我们可以知道什么是合理的设计。例如，您可能没有正确使用基数。 Chen 的方式是，数字或范围告诉实体类型的某些实例它可以参与多少个关系实例。另一种方式是，数字或范围告诉您 other 参与实体类型 行的实体类型的多少实例可以参与。如果后者为零，则表示关系实例可以为 NULL。但这不可能出现在陈的设计中；参与实体实例组合识别关系实例并形成 PK（主键）。
然而，陈设计不能表达所有的关系设计。我们可以通过重新排列表来表示与 Chen ER 模式相同的数据。例如，删除不是 many:many 的二元关系表并将 FK（有时可为空）放入实体表中，就像您对 takes、Ship 和 Tour 所做的那样。一些方法具有直接表达这种设计的非陈图。其他人则允许它从陈图转移到模式。你必须问你的老师，他们是否关心陈风格的 ER 图和你被允许制作的相应模式的哪些变化。
（正是在显式 1:many 关系/关联及其由 FK 表示的非 Chen 方法中的这种下降导致 FK 被错误地（但通常）称为“关系”或“关联”。）
【讨论】：