如果 city 和 region 之间存在关系，其中 region -> city 是一对多映射。
以下是数据库设计：
城市
地区
region_id 是Region 表的外键
我想知道 region_id 和 city_id 是否是候选键。由于 city_name 对候选键的部分依赖，关系不在 2 NF 中。
如何处理一对多映射的规范化？
【问题讨论】：
city_id 是一个自动增量 ID（你应该明确地清除它，但除非这是某种家庭作业问题，否则它应该是一个自动增量 ID，以免你的表格太复杂），@ 987654324@ 是city 的（唯一）候选键（尽管(city_name, region_id) 也可能是一个，取决于您的区域有多大，但我认为这没有多大逻辑意义）并且您的表排在第 5 位正常形式。
由于 city_name 对候选键的部分依赖，关系不在 2 NF 中
那么你的数据是这样的吗？：
Region ( key = region_id ):
{ region_id = 'R01', region_name = 'France' };
{ region_id = 'R02', region_name = 'Texas' };
City ( key = ??? ):
{ city_id = 'C01', city_name = 'Paris', region_id = 'R01' }; -- Paris, France
{ city_id = 'C01', city_name = 'Paris', region_id = 'R02' }; -- Paris, Texas
换句话说，您只想要一个名为“巴黎”的城市，因为所有巴黎人都是同一个实体？我认为这是一种奇怪的世界观！
我认为大多数人会认为每个巴黎都是独立的实体，因此会有不同的标识符来区分它们：
Region ( key = region_id ):
{ region_id = 'R01', region_name = 'France' };
{ region_id = 'R02', region_name = 'Texas' };
City ( key = ??? ):
{ city_id = 'C01', city_name = 'Paris', region_id = 'R01' };
{ city_id = 'C02', city_name = 'Paris', region_id = 'R02' };
即使有上面的表格，我也对城市的钥匙有点不清楚。我认为关系变量“做得太多”；理想情况下，我们应该有第二个 relvar 来模拟城市与其区域之间的关系：
Region ( key = region_id ):
{ region_id = 'R01', region_name = 'France' };
{ region_id = 'R02', region_name = 'Texas' };
City ( key = city_id ):
{ city_id = 'C01', city_name = 'Paris' };
{ city_id = 'C02', city_name = 'Paris' };
CityRegion ( key = city_id ):
{ city_id = 'C01', region_id = 'R01' };
{ city_id = 'C02', region_id = 'R02' };
以上内容现已完全标准化（实际上在 6NF 中）。
【讨论】：
city_id 和 region_id 字段的组合可以是 city 中的候选键，具体取决于您如何定义这两个字段（您的帖子没有说明），因为
候选键可以是可以作为数据库中唯一键的任何列或列组合。一张表中可以有多个候选键。每个候选键都可以作为主键。
来源：Difference Between Candidate Keys and Primary Key In Simple Words
您可以将 city_id 单独定义为唯一的（可能是 auto_increment），但您也可以仅定义 2 个字段的组合唯一。
但是，我不会做后者，因为如果您重新分类一个城市（从一个地区移动到另一个地区），那么您可能还必须更改 city_id 组件。
【讨论】：