71街

范式设计是关系数据库的一个延伸理论。目的是在关系数据库的基础上，减少重叠数据的冗余，并且在将列(属性) 逐渐拆分成表(关系) 的过程中，从理论上减少了异常数据产生的几率。增强了数据的关系性能，在一定程度上，增强了关系查询效率。

术语：通常在具体的 RDBMS 如 MySQL 的应用开发中，将一个关系叫做表，一条元组（tuple） 称为行，一个属性叫做列。 因为范式（NF） 设计主要是讲理论，所以在本文中，一律将表称为关系，将行称为tuple，将列称为属性。

如图：

1.1] First Normal Form(1NF)

1NF(第一范式) 的目的是将数据拆分成原子状态。例如 一个大型文章发布系统的文章序列号的组成是 8 位用户名 + 该用户所属的文章号，如某用户的用户名是 ID_001 ，他发表的某一篇文章，在他的文章列表中的序列号是 15 ，这篇文章在该系统中唯一序列号是 ID_00115 。

将文章序列号存储到关系中去，通常的做法是这样的：

错误的方式

+———————-+—————–+—————+

some属性…… | 文章序列号 | other 列……

———————-+—————–+—————-

……| ID_00115 |

这么做是不符合 1NF 规范的。因为文章序列号是两部分组成的，如果存成一个属性那么就违反了 1NF 的原子性原则。

符合 1NF 的属性划分方法如下：

正确方式：

+———————-+————–+——–+—————+

some属性…… | 用户号 | 文章号 | other 列……

———————-+—————+——–+—————-

……| ID_001 | 15 |

+———————-+————-+——–+—————+

1.2] Second Normal Form（2NF）

2NF 划分关系的原则是：一个关系中的所有非 Key属性s 必须完全的依赖于 Key。如果是多主键的话，那么非主键属性s 必须完全依赖所有的主键.

1NF 的范围是同一关系的不同属性之间的划分。而 2NF(第二范式) 的范围是将一个大的，数据相互重叠与冗余的关系拆分成众多小的，关系 ，他们之间相互的联系就是 Key ，Key 是一个关系中唯一标示一个tuple 的标识。而且在 2NF 中，所有有效的单一的 Key 默认都是 Primary key。(多个 Key 唯一定位一个tuple ,那么这些Key 称为复合主键) 。

另外一点需要特别注意的是，范式是属性递增的，因此，只有在完成了 1NF 之后，才能进行 2NF 的划分。

例如某文章系统中，一个存储某一篇文章的关系，有如下字段

错误方式：

+————————–+————+———-+———–+———–+————–+—————-+———–+——————

..some属性s | 用户号 | 文章号 | 文章标题 | 文章内容 | 文章创建时间 | 用户发表文章数 | 用户登录数| other 列 …

+————————–+————+———-+———–+———–+————–+—————-+———–+——————

……| ID_001 | 15 | Article | Cnt … | 1223372589 | 4 | 20 | ……

其中，‘用户号’和‘文章号’对于 ‘文章标题’、‘文章内容’、‘文章创建时间’来说，可以算是复合主键，因为要查出这些属性，必须完全依赖 ‘文章号’和 ‘用户号’这两个属性，缺一不可。

而 ‘用户发表文章数’和 ‘用户登录数’这两个属性仅依靠 ‘用户号’就可以出来，所以 ‘用户号’是 ‘用户发表文章数’和 ‘用户登录数’的主键，而 ‘文章号’则和这两个属性没有关系。也可以说 ‘用户发表文章数’和 ‘用户登录数’没有完全依赖于复合主键，所以这个表不符合 2NF 标准(但是所有属性都是原子不可分状态，因此这个表符合 1NF 标准)。

如果要符合 2NF 标准，就需要将这个关系拆分成两个关系

正确方式：

+————————–+————+———-+———–+———–+————–+————————–

..some属性s | 用户号 | 文章号 | 文章标题 | 文章内容 | 文章创建时间 | other 列 …

+————————–+————+———-+———–+———–+————–+————————–

……| ID_001 | 15 | Article | Cnt … | 1223372589 | ……

+————————–+————+———-+———–+———–+————–+—————————

正确方式：

+————————–+————+—————–+———–+——————-

..some属性s | 用户号 | 用户发表文章数 | 用户登录数| other 列 …

+————————–+————+—————–+———–+——————-

……| ID_001 | 4 | 20 | ……

+————————–+————+—————–+———–+——————-

这样，Right way one . 中剔出了不符合完全依赖的两个属性s ，所有的属性s 都完全依赖 composite primary key ，可以认为 Right way one. 符合 2NF 标准。

另外，将 Wrong way. 中剔出的两个属性s 划分到了 Right way two. 里面，primary key 是 ‘用户号’。因此 Right way two. 仅就一个 primary key ，并且所有内容都依赖于 primary key 查询，所以可以说 Right way two. 符合 2NF 的要求。

1.2.1] 关系模式

经过 2NF 的拆分，现在关系的数量在增加，但是属性之间的关系趋向于更加的简单明了。

关系之间根据对应联系的不同，有三种不同的关系模式：

· 一对一

· 一对多

· 多对多

·一对一 ， 既一个属性仅可以对应一个其他的属性

例如：一个用户号和用户之间就是一对一的关系，一个用户只能有一个用户号，一个用户号只能指定某一个用户。

·一对多 ， 既一个属性可以对应多个其他的属性

例如: 一个用户号可以对应多个文章号,因为用户可以发表多篇的文章.

·多对多 ， 既多个属性可以对应多个其他的属性

完全多对多就是 Cartesian product(笛卡尔积或直积)。

例如: 一个用户可以发相同标题的不同文章。而拥有相同标题的文章，可以由不同的用户发。