目录
一、范式理论的命题：什么样的关系模式是"好"的
第14篇建立的Armstrong公理体系与属性集闭包算法，为函数依赖的形式化推理提供了完备的工具箱。然而，掌握工具本身并不等于知道该用工具解决什么问题。工具的价值在需求中显现。数据库设计者面临的核心问题是：在完成E-R模型向关系模式的转化之后，得到的一组关系模式是否"足够好"？如果不够好，应该朝着什么方向改进？
"好"的评判标准不能依赖于审美直觉，它必须植根于可客观验证的指标。范式理论为此提供了精确的测度：一个关系模式的设计质量，取决于它能否规避特定类型的存储异常。三种存储异常是衡量设计优劣的共同尺度：
插入异常：当设计者试图向关系中插入一条新记录时，由于主码尚未完全确定，或某些属性无法提供合法取值，导致插入操作被阻止------即使在现实世界中该事实已经存在且合法。例如，在未设置独立"院系"关系的设计中，新成立的院系因尚无任何教师而无法录入数据库。
删除异常：当设计者从关系中删除一条记录时，除了目标信息被移除之外，另有其他完全独立的信息随之永久丢失。例如，从"教师-院系"合并表中删除最后一位某院系的教师时，该院系的存在信息也一同被抹去。
更新冗余：同一事实在关系中多处重复存储，当该事实发生变化时，必须在所有副本处同步更新，任何一个遗漏都会导致数据不一致。
范式理论的分级体系------1NF、2NF、3NF、BCNF、4NF、5NF------正是针对不同类型的函数依赖和多值依赖，逐步收窄允许的依赖模式，从而逐级消除更复杂的异常类型。本文将聚焦于1NF至BCNF的晋级路径：从最基本的原子性要求，到消除非主属性对码的部分依赖和传递依赖，最终抵达BCNF这一许多工程实践的默认目标。
二、第一范式（1NF）：原子性的底线
第一范式的定义是所有范式要求的起点：一个关系模式R属于第一范式（1NF），当且仅当R的每个属性所基于的域都只包含原子值------即每个属性值在逻辑上不可再分，关系中的每一个行-列交叉点上有且仅有一个值。
这个定义看似朴素到近乎浅显，但它确立了一条不可妥协的底线：关系中不允许出现"表中表"的结构。一个属性不能包含多个值的列表（如一个"联系电话"列包含"138xxxx,139xxxx"），也不能包含结构化的子表（如一个"家庭成员"列包含姓名与关系的嵌套结构）。1NF要求所有数据被平坦化为二维表结构，这是关系模型区别于层次模型和网状模型的基本特征。
违反1NF的设计在实务中并不罕见------常见于从非结构化数据源导入数据时的初始形态。处理多值属性通常需要将其拆分为独立的关系（如将"联系电话"拆分为独立的"学生电话"表，包含学号外码和电话号码，二者共同构成复合主码）。处理复合属性则需要将子属性展开为独立的列（如将"地址"拆分为省、市、区、街道四列）。
1NF是关系模型的最低准入门槛。一个不符合1NF的关系甚至不能被称为关系------它与关系定义中"域必须由原子值组成"的要求直接冲突。然而，仅满足1NF的关系模式仍然可能充斥着严重的存储异常，必须通过更高层级的范式来约束属性之间的函数依赖结构。
三、第二范式（2NF）：告别部分依赖
在1NF的基础上，第二范式引入了对主码与属性之间依赖关系的第一层约束。2NF的定义涉及两个关键概念：主属性与非主属性。
设R是一个关系模式，R的任意一个候选码中的属性称为主属性 ；不属于任何候选码的属性称为非主属性。这一区分是理解所有高阶范式的基石------范式约束的核心就是规范非主属性与码之间的依赖关系。
第二范式的定义：R ∈ 2NF，当且仅当R ∈ 1NF，且R的每个非主属性完全函数依赖于R的每一个候选码。
这一定义隐含着2NF所针对的病症：部分依赖。如果一个非主属性仅依赖于复合候选码的一部分属性，而非整个候选码，就构成了部分依赖。部分依赖仅在候选码是复合属性集时才有可能出现------如果候选码是单属性，则不可能存在对"部分"码的依赖，2NF自动满足。
考虑一个违反2NF的典型实例。设关系模式：
选课-学生信息(学号, 课程编号, 成绩, 学生姓名, 学生院系)
该关系的候选码为(学号, 课程编号)。成绩完全依赖于整个候选码------仅知道学号或课程编号都无法确定成绩。然而，学生姓名和学生院系仅依赖于学号，即候选码的真子集------这就是部分依赖。
部分依赖引发的异常触目惊心：当一名新生尚未选修任何课程时，无法插入其基本信息（插入异常，因为课程编号作为主码的一部分不能为空）；当一名学生退选所有课程时，其个人信息随最后一门选课记录一同被删除（删除异常）；学生的姓名和院系信息在每一门选课记录中重复存储，变更院系时需同步更新所有行（更新冗余）。
2NF的分解策略 是直截了当的：将部分依赖的属性连同它们所依赖的那部分候选码一起，从原关系中分离出去，形成一个新的关系。上述关系分解为：
选课(学号, 课程编号, 成绩)------候选码(学号, 课程编号)，成绩完全依赖于此候选码。
学生(学号, 学生姓名, 学生院系)------候选码(学号)，非主属性完全依赖于整个候选码。
分解后的两个关系各自满足2NF。选课关系中不再包含仅依赖学号的属性，学生关系中候选码是单属性，2NF自动成立。原关系中的所有存储异常随之消除：新生可以先行录入学生表，退选全部课程不会丢失学生信息，学生姓名和院系只需在一处更新。
值得注意的是，如果一个关系模式的候选码是单属性，则它自动满足2NF------因为单属性候选码不可能存在真子集，部分依赖在逻辑上无从产生。这解释了为何许多设计良好的关系模式无需刻意考虑2NF：设计者在选择主码时已经尽可能采用了单属性码，从而自然规避了部分依赖的陷阱。
四、第三范式（3NF）：切断传递依赖
2NF消除了非主属性对码的部分依赖，但并未触及另一种同样致命的依赖结构------传递依赖。一个满足2NF的关系模式，仍然可能因为传递依赖的存在而遭受严重的存储异常。
第三范式的定义：R ∈ 3NF，当且仅当R ∈ 2NF，且R的每个非主属性都非传递依赖于R的每一个候选码。
传递依赖的形式化定义已在第14篇给出：如果X → Y成立，Y → Z成立，但Y → X不成立（Y不函数确定X），且Z ∉ X，则称Z传递依赖于X。在3NF的语境下，X是候选码，Z是非主属性，Y是起中介作用的属性集------通常是另一个非主属性或非主属性集。
考虑一个满足2NF却违反3NF的实例：
员工(工号, 姓名, 部门编号, 部门名称, 部门地点)
候选码为{工号}------单属性候选码自动满足2NF。函数依赖包括：工号 → {姓名, 部门编号, 部门名称, 部门地点}，部门编号 → {部门名称, 部门地点}。注意，部门名称和部门地点直接依赖于部门编号（非主属性），而部门编号又依赖于候选码工号，且部门编号→工号不成立（一个部门包含多名员工）。因此，部门名称和部门地点通过部门编号这一"桥梁"传递依赖于候选码工号------这正是3NF所禁止的结构。
传递依赖引发的异常与部分依赖同样严重：新成立的部门在尚未分配员工时无法录入数据库（部门编号作为非主属性可以为NULL，但作为部门信息的唯一载体，逻辑上不应允许部门独立存在）；当某部门最后一名员工被调离或删除时，部门的存在信息随之消散；部门名称和地点在每位该部门员工的记录中重复存储。
3NF的分解策略：将传递依赖链中的"桥梁"属性（此处为部门编号）及其决定的属性分离为新的关系，桥梁属性在新关系中担任候选码，在原关系中仅作为外码保留。
上述关系分解为：
员工(工号, 姓名, 部门编号)------候选码{工号}，外码部门编号引用部门关系。
部门(部门编号, 部门名称, 部门地点)------候选码{部门编号}。
分解后的两个关系各自满足3NF。部门信息的独立存在不再依赖于任何员工的在场，插入异常和删除异常随之消除，冗余被限制在外码列的唯一出现。
3NF与2NF之间的逻辑关系值得强调：3NF蕴含2NF。任何满足3NF的关系模式必定满足2NF，但反之不成立。范式晋级是逐层收紧约束的过程，每一层都在前一层的约束基础之上施加更严格的限制。
五、BC范式（BCNF）：当候选码不止一个
在绝大多数工程实践中，3NF已被视为"足够好"的设计标准。然而，当关系模式存在多个复合候选码且这些候选码之间出现属性重叠时，3NF可能仍不足以消除所有由函数依赖引发的异常。BC范式正是为填补这一理论缝隙而提出。
BC范式的定义（Boyce-Codd Normal Form，由Raymond Boyce与Edgar Codd于1974年提出）：R ∈ BCNF，当且仅当对于R上成立的每一个非平凡函数依赖X → Y（即Y ⊈ X），X都是R的一个超码。
这个定义形式上比3NF更简洁，逻辑上比3NF更严格。它不再区分主属性与非主属性，而是对所有非平凡函数依赖施加了一视同仁的硬约束：任何能函数确定其他属性的属性集，都必须具有超码的身份------即它必须能够唯一标识关系中的每一个元组。如果一个依赖的左部不是超码，即使它的右部是主属性，BCNF也不接受。
考虑一个违反3NF但满足BCNF的经典实例。然而，此处我们需要的是3NF已满足但BCNF未满足的实例。设关系模式：
授课安排(学生, 教师, 课程)
该关系的语义约束为：每位教师只教授一门课程，每门课程可由多位教师教授，每位学生可以选择多门课程但每门课程只有一位教师。由此导出候选码：(学生, 课程)和(学生, 教师)------两个候选码存在重叠（共享学生属性）。函数依赖包括：教师 → 课程（每位教师只教一门课），(学生, 课程) → 教师，(学生, 教师) → 课程。
关系中的所有属性都是主属性（因为两个候选码覆盖了全部三个属性），因此3NF自动满足------3NF仅约束非主属性，而此处无非主属性。然而，函数依赖"教师 → 课程"的左部"教师"并非超码（它不是候选码，也不能唯一标识一个元组------一名教师可以在多个学生的选课记录中出现），因此违反了BCNF。
教师→课程这一依赖导致的实际异常：如果某位教师尚未被任何学生选择，其教授的课程信息无法录入（插入异常）；当某教师的所有学生退课后，该教师与课程的关联信息随之丢失（删除异常）；当某教师更换所授课程时，需在其所有学生的记录中逐一更新（更新冗余）。
BCNF的分解策略：将违反BCNF的依赖左部提取为新关系的主码，将依赖的左部和右部共同构成新关系。上述关系分解为：
授课(教师, 课程)------候选码{教师}，教师→课程满足BCNF。
选课(学生, 教师)------候选码(学生, 教师)，该关系上无成立的非平凡函数依赖（教师已不再决定课程），满足BCNF。
分解后的两个关系各自满足BCNF，原有异常全部消除。但这一分解带来了一个需要警惕的副作用：原关系中(学生, 课程)的组合约束------即"每位学生每门课程只有一位教师"------在分解后的两个关系中无法通过局部约束来表达，必须通过跨关系的连接验证。这意味着BCNF分解可能无法保持函数依赖。这一问题将在下一篇中与保持依赖性和无损连接性的判定一同深入探讨。
六、逐级分解的实例全景
为让读者建立对规范化过程的结构性认知，以下呈现一个完整的逐级分解实例。原始关系模式取自高校教学管理场景：
学生选课(学号, 课程编号, 成绩, 学生姓名, 院系编号, 院系名称, 教师工号, 教师姓名)
分析函数依赖：从业务语义出发，确定以下依赖成立：
-
(学号, 课程编号) → 成绩 ------ 完全依赖
-
学号 → 学生姓名, 学号 → 院系编号 ------ 部分依赖
-
院系编号 → 院系名称 ------ 传递依赖（通过院系编号）
-
教师工号 → 教师姓名 ------ 部分依赖（教师工号依赖(学号, 课程编号)的部分？并非如此。此处的实际函数依赖结构需要谨慎分析：设课程编号 → 教师工号（每门课由一位教师讲授），则教师工号 → 教师姓名，且课程编号 → 教师工号 → 教师姓名。这构成传递依赖。）
1NF检查：所有属性均为原子值，满足1NF。
2NF检查：候选码为(学号, 课程编号)。非主属性包括：成绩、学生姓名、院系编号、院系名称、教师工号、教师姓名。学生姓名和院系编号仅依赖学号------部分依赖，违反2NF。
分解至2NF：
-
选课(学号, 课程编号, 成绩, 教师工号, 教师姓名)------仍包含部分依赖？
-
学生(学号, 学生姓名, 院系编号, 院系名称)
进一步分析选课关系：候选码(学号, 课程编号)。成绩完全依赖候选码。但教师工号和教师姓名如何依赖？若课程编号 → 教师工号，且课程编号是候选码的真子集，则教师工号部分依赖于候选码------仍违反2NF。若将教师工号视为完全依赖于候选码（每门课教师不同），则需重新考察函数依赖。此处假设更简单的场景：课程编号 → 教师工号，教师工号 → 教师姓名。
选课关系违反2NF（教师工号部分依赖课程编号），需要进一步分解：
-
选课(学号, 课程编号, 成绩)
-
课程(课程编号, 教师工号, 教师姓名)
学生关系中，候选码(学号)，院系编号 → 院系名称构成传递依赖，违反3NF。分解：
-
学生(学号, 学生姓名, 院系编号)
-
院系(院系编号, 院系名称)
课程关系中，候选码(课程编号)，教师工号 → 教师姓名构成传递依赖（课程编号 → 教师工号 → 教师姓名），违反3NF。分解：
-
课程(课程编号, 教师工号)
-
教师(教师工号, 教师姓名)
最终模式集合（全部满足3NF）：
-
学生(学号, 学生姓名, 院系编号)，外码：院系编号→院系
-
院系(院系编号, 院系名称)
-
课程(课程编号, 教师工号)，外码：教师工号→教师
-
教师(教师工号, 教师姓名)
-
选课(学号, 课程编号, 成绩)，外码：学号→学生，课程编号→课程
这一系列分解的每一步都精确消除了特定类型的函数依赖异常，最终产出了一组结构清晰、冗余最小化的关系模式。这一组模式就是规范化理论所追求的"好的设计"。
七、结语：范式晋级的设计哲学
从1NF到BCNF的晋级路径，揭示了数据库设计理论中一条深刻的逻辑链条：每一种存储异常的背后，都有一个不合规的函数依赖结构；每一种范式升级的背后，都是对某一类依赖结构的清零。
1NF清除的是属性内部的嵌套结构，它将数据强行压平为二维表。2NF清除的是非主属性对码的部分依赖，它要求每一个非主属性都忠诚于完整的候选码而非其一部分。3NF清除的是非主属性对码的传递依赖，它切断非主属性之间的决定关系，使它们直接依赖于候选码而非通过其他非主属性间接依赖。BCNF则更进一步，将所有有决定力的属性集都提升为超码------不论它是主属性还是非主属性，没有超码身份就没有决定资格。
然而，规范化的晋级并非可以无限追求的绝对目标。每一层分解都将一个关系拆分为多个更小的关系，这意味着原本可以在一次单表扫描中完成的查询，现在可能需要多表连接。规范化的收益（消除异常、减少冗余）需要与性能开销（连接操作的时间成本）进行权衡。在工程实践中，3NF或BCNF通常被视为规范化的"足够点"------更高的范式（4NF、5NF）针对的是更罕见的依赖类型（多值依赖和连接依赖），它们将在下一篇中展开。
此外，一个始终伴随分解过程的隐忧是：分解后的关系集合是否仍能表达原关系集合的所有约束？分解是否可逆？这就引出了衡量模式分解质量的两个核心判据------无损连接性 与保持依赖性。下一篇将对这两个判据进行严格的算法化探讨，为规范化理论画上闭环。