数据库范式 Normal Forms

范式（Normalization）是关系数据库设计中的一种理论基础，它的主要作用是优化数据库结构、减少数据冗余、提高数据一致性和可维护性。换句话说，范式的目标是让数据库设计更科学、更健壮。

范式从低级到高级分为：1NF、2NF、3NF、BCNF（Boyce-Codd NF）、4NF 、 5NF、DKNF、6NF。

满足高级范式一定要满足它前面的所有范式。

现在数据库设计一般要求满足3NF就行了，范式过高，虽然具有对数据关系更好的约束性，但也导致数据关系表增加而令数据库IO更易繁忙。

因此本文只写到第五范式。

第一范式 (1NF)

要求：每个列都是原子性的（不可再分）

这里的不可再分是个”定义“的概念，不是真的不可再分，你定义好数据的表示方式，格式或范围，就叫做不可再分了。

例：定义了一个数据关系表，不符合第一范式

拆分：把联系方式拆开，当然也也可拆到单独的表中。

不符合第一范式的关系表，无法表现到关系数据库中。也就是常说的，只要你在数据库中建了表，肯定符合第一范式。我理解是从纸上设计到数据库实现的一个过程。

注：有些文章的例子中会出现比如”手机号“的列，内容是多个手机号，说还可以再分，但我觉得那是数据格式问题，不是表设计问题，如果定义就是固定分隔符分开的一组手机号，那也没问题。

注：还有把顺序无关、不可重复等算做第一范式的要求，我觉得这都是数据的要求不是表结构的要求。

第二范式（2NF）

要求：所有非主键列必须完全依赖于主键，不能只依赖主键的一部分，消除部分依赖。

这个讲的是消除依赖，但其实做的是减少主键，减少了主键不就不会依赖一部分了么。

例：主键当前是（学生号，老师编号），绿色部分依赖学生号，蓝色部分依赖老师编号，依赖部分主键。

图片

拆成：

图片

可以从面向对象角度看，如果可以把列分成多个对象的不同属性，那就不符合第二范式。

第二范式是把明显应分成两个表的数据组合成一个表的情况给解决掉。

拆解后，同一个老师信息就不会重复出现多次了，减少了冗余，修改某个老师信息只需修改一处，利于保持数据完整性，防止修改错误。

第三范式（3NF）

要求：消除传递依赖，即非主键列之间不应该有依赖关系。

就是不能存在X→Y→Z的关系。

例：物品→等级→水平

初等对应等级：1、2、3

中等对应等级：4、5、6

高等对应等级：7、8、9

也就是水平依赖等级。

拆成：

同样的例子还有，生日→年龄，省份→国家等。

注：有的文章举例子（学生号→系名→系主任），这个例子不太好，按第二范式拆成学生、系两个表就解决了。

BC范式（BCNF）

Boyce-Codd　NF

要求：所有决定因素必须是候选键，消除所有属性对非候选键的依赖。

也叫3.5NF，实际上基本找不到满足3NF但不满足BCNF的例子。

很多文章举的例子是学生选课。

例：

图片

（学生，课程号）→老师号

（学生，课程号）→老师姓名

所以满足第三范式，但是"老师号→老师姓名"，所以不满足BCNF。

拆解：

把"老师号→老师姓名"单独拆成一个表

例２：

图片

拆解：把“课程名→教师系名”单独拆成一个表。

也就是说当你看到一个X→Y→Z的情况，同时X→Z使它满足了3NF，它就是BCNF的特征了。

说是3.5NF，就是因为他们都有X→Y→Z吧。

第四范式（4NF）

要求：消除非平凡的多值依赖

平凡的依赖：如果箭头左侧的属性和箭头右侧的属性共同构成了表中的所有属性，则多值依赖关系被认为是平凡的。

多值依赖：X 确定一个 Y 的集合，与其他属性无关。

例子：

图片

如果增加一种模型，这个表会增加4行数据，同理增加颜色和样式也一样。所以冗余很大。

拆解：

图片

一个模型对应好几个颜色，又独立的对应好几个样式，他们是可以随意组合的，就要把它们拆分成多个数据表。

在第四范式，主键（模型）还是比较可控的，其属性自由组合，独立存在。

第五范式（5NF）

要求：5NF 要求关系中的数据不能被无损地分解为多个子关系并再重建，否则就要分解，消除冗余和插入/删除异常。

例：

图片

拆解：

图片

第五范式是在拆解所有属性都独立存在的情况。

最后

规范化减少数据冗余，但效率就低了，因此为了效率部分数据会采用”反规范化“故意冗余。所以不要看到不满足范式的就去批评，要看实际的环境。