违反数据库第三范式引发的一个问题

2024-01-15 13:44:10

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

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

It is in second normal form.

All nonprimary fields are dependent on the primary key.

简单翻译过来，就是说：

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

这张表遵守第二范式。

这张表中，所有非主属性都（仅）依赖于主属性。

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

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

<hr/>

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

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

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

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。

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

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

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