在数据库设计中，第三范式（3NF）是一个重要的概念，它确保了数据表的结构既简洁又高效。第三范式是在第二范式（2NF）的基础上进一步优化数据表，消除了数据间的非传递依赖，从而避免了数据更新异常。本文将详细解释3NF的定义、重要性，并通过实例演示如何将现有数据库表结构调整至3NF。
一个数据表处于第三范式（3NF）的条件是：
这里的“非传递依赖”是指，表中的每一列的值不能通过其他非主键列间接依赖于主键。换句话说，如果一个列的值依赖于另一个列，而这个列又依赖于主键，那么这种依赖关系就是传递的，不满足3NF的要求。
要理解非传递依赖，首先需要了解什么是传递依赖。在逻辑学中，如果一个关系或属性在整体上成立，那么它在任何一个部分上也应该成立，这种关系就被称为传递的。例如，如果A大于B，B大于C，那么A必然大于C，这里的“大于”关系就是传递的。
在数据库中，如果一个列的值可以通过另一个列的值来确定，那么就说这个列依赖于那个列。例如，一个人的年龄依赖于他的出生日期。如果一个列的值依赖于另一个列，而这个列又依赖于主键，那么这种依赖关系就是传递的。
非传递依赖则是指，一个列的值直接依赖于主键，而不依赖于其他任何列。
让通过一些实例来进一步理解3NF。假设有一个包含以下列的数据表：
在这个例子中，FirstName和LastName都不依赖于其他列，只依赖于PersonID，因此这个表是满足3NF的。
再来看另一个例子：
在这个例子中，IsOverweight依赖于BodyMassIndex，而BodyMassIndex又依赖于PersonID，因此IsOverweight实际上是传递依赖于PersonID的，这个表不满足3NF。
在实际的数据库设计中，经常会遇到需要将现有数据模型调整至3NF的情况。例如，假设有一个客户表，包含以下列：
在这个例子中，CustomerCity依赖于CustomerPostalCode，而CustomerPostalCode又依赖于CustomerID，因此CustomerCity实际上是传递依赖于CustomerID的。为了满足3NF，需要将CustomerCity从客户表中移除，单独创建一个邮政编码表，包含邮政编码和城市名称。
调整后的客户表和邮政编码表如下：
这样，每个表中的列都只依赖于自己的主键，满足了3NF的要求。
虽然规范化是数据库设计中的一个重要步骤，但过度规范化可能会导致不必要的复杂性。例如，在某些情况下，保持数据表在2NF可能就足够了，因为某些依赖关系并不会导致数据更新异常。
在决定是否进行规范化时，需要权衡规范化带来的数据一致性优势和可能增加的复杂性。如果数据更新异常会对数据库应用的准确性或性能产生严重影响，那么进行规范化是值得的。否则，可以考虑依赖用户来确保相关字段的一致性。
在某些情况下，可能会有意地去规范化数据。例如，如果需要向用户展示汇总或编译的数据，而这些数据的生成非常耗时或资源密集，那么维护这些数据的单独副本可能是有意义的。
几年前，开发了一个大型的工程变更控制系统，该系统在主页上显示每个工程师需要关注的部件、问题和任务。这是一个数据库范围内的任务列表。任务列表是通过视图实时重建的，性能在最初几年是可以接受的。但随着用户基数的增长，每次用户访问主页时都需要重建列表，这消耗了越来越多的数据库资源。
最终，不得不重新设计数据库。用一个单独的表替换了视图，这个表最初用视图数据填充，然后通过代码维护，以避免异常。需要创建复杂的应用程序代码来确保它始终是最新的。