“Y为素属性”的3NF判定条件如何消除数据冗余？

背景设定 #

给定关系模式 R(A,B,C,D,E)，对应的函数依赖集为：

• AB → ABCDE（AB是超键，可唯一标识所有元组）
• C → B（B是超键AB的组成部分，按3NF定义，该模式满足3NF）

1. B作为超键AB组成部分的作用 #

B是超键AB的核心组成单元，主要作用是参与实现元组的唯一标识：

• 超键AB必须能唯一区分R中的每一条元组，B的存在补充了A的标识能力——如果仅靠属性A无法唯一确定元组，搭配B后就能满足超键的唯一性要求。
  但在本案例中，由于C→B的存在，B的取值完全由C决定，这使得AB作为超键的合理性存在冗余隐患。

2. 满足3NF为何仍存在冗余？ #

3NF并非完全消除所有冗余，它仅解决非素属性对超键的传递依赖冗余，素属性之间的依赖导致的冗余不在其约束范围内。
比如用户给出的示例：
存在元组(1,2,3,4,5)和(2,2,3,4,5)，其中C为部门编号，B为部门员工数。

• 按照C→B，同一部门（C=3）对应的员工数B必须一致，因此两个元组中B的值重复存储，这就是冗余。
• 即便C是素属性，3NF也允许这种素属性之间的依赖存在，因此无法消除这类冗余；C是非素属性时情况同理。

3. 3NF定义中“Y为素属性”条款的冗余消除逻辑 #

3NF的完整约束规则：对于任意非平凡函数依赖X→Y，要么X是超键，要么Y是素属性（Y属于某个候选键）。

• 该条款的核心作用是禁止非素属性通过非超键传递依赖于超键，比如若存在AB→C且C→D（D为非素属性），这属于传递依赖，3NF会要求拆分模式来消除D的冗余存储。
• 但对于素属性之间的依赖（如本案例的C→B，B是素属性），3NF并不限制，这类依赖带来的冗余需要更高范式（如BCNF）来解决。

4. 矛盾案例的合理性分析 #

用户给出的冲突示例：元组(1,2,3,4,5)和(1,x,3,4,6)

• 根据C→B，C=3对应的B值必须为2，因此x必须等于2；但此时AB=(1,2)，按照AB→ABCDE，AB对应的D、E值必须唯一，即D=4、E=5，而第二个元组的E=6，这直接违反了AB→ABCDE的函数依赖约束。
• 这种情况在符合给定函数依赖的关系中不可能存在，因为所有元组必须严格满足函数依赖规则，要么调整x为2并将E改为5，要么修改C的值，否则就违反了数据库的约束要求。

内容的提问来源于stack exchange，提问作者Marvin Mar