数据库规范化中部分依赖与传递依赖冲突问题求解

基础信息确认 #

原始关系与依赖规则如下：

• 关系模式：AB(a, b, c, d, e, f, g)
• 复合主键：(a, b)
• 完整函数依赖集：
  • b → c, e
  • c → e, g
  • a → d
  • (a,b) → f（属性f未出现在其他依赖中，说明其必须由完整主键才能确定，属于完全依赖主键的属性）

核心规则说明 #

规范化严格按照从低阶范式到高阶范式逐层校验拆分的逻辑推进，不存在“依赖冲突”的问题：你观察到的属性e同时存在部分依赖、传递依赖，只是该属性同时违反2NF、3NF的约束要求，按顺序处理即可，不需要跳步。

• 2NF的唯一校验标准：所有非主属性必须完全依赖完整主键，不存在对主键部分字段的依赖，此阶段不需要处理传递依赖
• 3NF的唯一校验标准：所有非主属性必须直接依赖主键，不存在对其他非主属性的依赖（即消除传递依赖）

第一步：拆分至2NF #

逐一排查非主属性对主键的部分依赖，将仅依赖主键单字段的属性拆分为独立表，保留外键做关联：

1. 拆分仅依赖a的属性：
   • 表结构：Table_A(a, d)
   • 主键：a
   • 说明：属性d由a唯一确定，与b无关，拆分后无部分依赖
2. 拆分仅依赖b的属性：
   • 表结构：Table_B_Init(b, c, e, g)
   • 主键：b
   • 说明：属性c、e由b唯一确定，与a无关；g虽然依赖c，但2NF阶段不校验传递依赖，因此暂时归入该表，拆分后该表主键为单字段，不存在部分依赖
3. 保留完全依赖完整主键的属性：
   • 表结构：Table_AB(a, b, f)
   • 主键：(a, b)
   • 说明：属性f必须同时确定a、b才能取值，无部分依赖；a、b作为外键分别关联前两张拆分出的表

以上三张表全部满足2NF要求。

第二步：从2NF拆分至3NF #

逐一排查2NF拆分后的所有表，消除非主属性之间的传递依赖：

1. Table_A(a, d)仅包含一个非主属性d，无传递依赖，保留即可
2. Table_AB(a, b, f)仅包含一个非主属性f，无传递依赖，保留即可
3. Table_B_Init(b, c, e, g)存在传递依赖：b → c，c → e, g，即非主属性e、g依赖另一个非主属性c，因此继续拆分：
   • 拆分为Table_B(b, c)：主键为b，c直接依赖b，无传递依赖，c作为外键关联下一张表
   • 拆分为Table_C(c, e, g)：主键为c，e、g直接依赖c，无传递依赖

最终得到的满足3NF的表结构共4张：

• Table_A(a, d)
• Table_B(b, c)
• Table_C(c, e, g)
• Table_AB(a, b, f)

以高校学生实验课选课与耗材管理场景为例，属性与业务字段完全映射：

• a：学生学号
• b：实验课程编号
• 复合主键(a,b)：唯一标记“某学生选某门实验课”的一条选课记录
• d：学生姓名，由学号唯一确定（对应a→d）
• c：实验课固定开课的实验室编号，由课程编号唯一确定（对应b→c）
• e：实验室负责人工号，既可以通过课程编号直接关联得到，也可以通过实验室编号关联得到（就是你遇到的e同时存在部分依赖、传递依赖的场景）
• g：实验室所在位置，由实验室编号唯一确定（对应c→g）
• f：学生选该门实验课的个人耗材领用配额，必须同时确定学生身份、课程信息才能核定（比如过敏学生选化学实验课的防护耗材配额与普通学生不同，对应(a,b)→f）

如果不做规范化，把所有字段存在同一张表里，会出现大量冗余：每有一个学生选某门实验课，就会重复存储一遍课程对应的实验室编号、负责人、位置，以及学生姓名；更新时如果实验室换了负责人，需要修改所有选了该实验室对应课程的学生记录，很容易出现数据不一致。按上述流程拆分后的表结构完全消除了这类异常。

内容的提问来源于stack exchange，提问作者Mustafa Muhammad