数据库第三范式的定义，是这样的：

A table is in a third normal form when the following conditions are met −

  1. It is in second normal form.
  2. All nonprimary fields are dependent on the primary key.

第三范式定义

简单翻译过来，就是说：

一张遵守第三范式的数据库表，应该符合以下两个条件：

  1. 这张表遵守第二范式。
  2. 这张表中，所有非主属性都（仅）依赖于主属性。

也就是“在第二范式的基础上，消除了非主属性对主属性的传递依赖”。

虽然我们在建表时使用的主键大多是业务无关的字段（例如自增主键），但是在讨论数据库范式时，“主属性”、“非主属性”一般都是指的业务字段。否则，恐怕没有一张表是符合第二范式的，更遑论第三范式了。

隐藏的“传递依赖”

网上对第三范式的举例说明可谓比比皆是，这里就不赘述了。

我这里要举的例子有点特别。它不仅仅在表中引入了传递依赖，甚至还隐去了传递依赖的中间环节。

简略一点来说，这张表是这样的：

CREATE TABLE TB_CONTACTER(
    ID            INT              NOT NULL    AUTO_INCREMENT,
    USER_ID       INT              NOT NULL,
    CHANNEL_ID    VARCHAR(10),
    CONTACTER     VARCHAR(100),
    PRIMARY KEY (ID),
    KEY(USER_ID,CHANNEL_ID)
);

这张表的最大问题在于：CONTACTER并不是直接依赖于USER_ID+CHANNEL_ID的。它们之间存在着这样的一种传递依赖：

USER_ID+CHANNEL_ID --> USER_ID+PRODUCT_ID --> APPLY_ID --> CONTACTER。

翻译一下就是这样的：用户从某个渠道进入系统，选择一个产品，提交一笔申请，并给这个申请单指定一个收货的联系人。

这个依赖确实有点复杂。于是，这张表的设计者对它做了一个简化处理。

按照当时的业务约束，一个用户在一个渠道上，都只能选择一个产品；针对每个产品都提交一笔有效申请；而这笔申请单上，只能指定一个联系人。

用图形来表示就是这样的： 图片

既然这个依赖链是如此地一根筋，那我们就一竿子捅到底好了。于是，就有了前面的TB_CONTACTER表的设计。

当需求发生变化

可是，业务数据之间的依赖关系是由产品需求定义的。而只要数一数产品经理有多少次拍胸脯保证“这次的需求不会再改了”，我们就知道产品需求有多善变。

在如此善变的产品需求面前，让业务数据之间的依赖关系永远保持不变，真是一种奢望。

而这种不切实际的奢望，很快就让我们尝到了苦头。

不知道该说不出所料还是该说大出所料，赖以简化依赖关系的业务约束被后来的产品需求打破了，最终——应该说是目前——变成了这样：

一个用户不仅可以在多个渠道上申请同一个产品；而且在每一个渠道上，都可以选择多个产品、提交多笔有效申请；不过每一笔申请单上，仍然只能指定一个联系人。

同样用图来表示，就是这样的（注意最左边的数据关系，从原先的1:1变成了N:M）： 图片

于是乎，我们的这张TB_CONTACTER表就出现了一个问题：无论是根据USER_ID+CHANNEL_ID，还是根据APPLY_ID，我们都无法准确地查到申请单上关联的联系人了。

如果不做改造，这张表等于是废了。而真的改造起来，里面有几百上千万的存量数据，怎么处理都让人头大。

总结一下来说，虽然数据库范式算得上很“古老”的技术思想，但是俗话说得好，姜是老的辣，酒是陈的香。能够经历大浪淘沙、沉淀至今的技术，仍然值得我们认真钻研和严谨使用。

=================================