table 的外键约束是否只是为了解决多值属性的良好设计而创建的？
Is a foreign key constraint on a table created just to resolve a multi valued attribute good design?
在我的 ER 模型中，我有一个实体类型 'City'，它具有 ZIPCode 的多值属性。到目前为止，还不错。
现在，当我将我的 ER 模型转换为关系模式时，我创建了一个额外的 table 来解析多值 ZIPCode 属性。类似于 CityZIP(CityID, ZIPCode) 的复合主键：CityID、ZIPCode
现在假设，我将雇员的地址存储在必须存储城市和邮政编码的雇员 table 中。一种方法是在我的员工 table 中有两列 CityID，ZIP，在 CityZIP table.
上有一个外键约束
但这甚至被允许吗？我引用了一个 table，根据我的 ER 图，它本身不是一个实体，但只是为了解析多值 ZIP 属性而创建的。
是的，是"allowed"。这是一个非常合理的设计，至少只要邮政编码可以跨越城市（即功能依赖性 { ZIPCode } -> { CityID } 不成立）。
table 不直接对应于 ER 模型中的实体，并不意味着您不能在关系模型中使用外键引用它。这些模型在这方面是独立的，它们之间没有单一的 "correct" 映射。
在我的 ER 模型中，我有一个实体类型 'City'，它具有 ZIPCode 的多值属性。到目前为止，还不错。
现在，当我将我的 ER 模型转换为关系模式时，我创建了一个额外的 table 来解析多值 ZIPCode 属性。类似于 CityZIP(CityID, ZIPCode) 的复合主键：CityID、ZIPCode
现在假设，我将雇员的地址存储在必须存储城市和邮政编码的雇员 table 中。一种方法是在我的员工 table 中有两列 CityID，ZIP，在 CityZIP table.
上有一个外键约束但这甚至被允许吗？我引用了一个 table，根据我的 ER 图，它本身不是一个实体，但只是为了解析多值 ZIP 属性而创建的。
是的，是"allowed"。这是一个非常合理的设计，至少只要邮政编码可以跨越城市（即功能依赖性 { ZIPCode } -> { CityID } 不成立）。
table 不直接对应于 ER 模型中的实体，并不意味着您不能在关系模型中使用外键引用它。这些模型在这方面是独立的，它们之间没有单一的 "correct" 映射。