数据库范式

今天刚好回忆下范式，参考这篇 如何理解关系型数据库的常见设计范式？ 文章，我在此文章进一步改进。

什么是范式？

教材书这样定义：符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度。

实话实说，真不懂！！然后看了博主的文章解释的很好。也就可以理解为：一张数据表的表结构所符合的某种设计标准的级别。就比如王者荣耀的VIP，有VIP1，VIP2，VIP3等等，VPI2是基于VIP1而来的，而不是直接跳过VIP1直到VIP2，所以VIP1的奖励也可以领取。那么数据库范式也分为1NF，2NF，3NF，4NF，5NF。还有一种是BCNF，对于3NF进一步改进。

一般而已，对于数据库的设计，满足第三范式或者BC范式就足够了。

第一范式（1NF）

第一范式是对关系模型的最基本的要求，其定义就是数据库表的每一列都是不可再分割的。

举正例可能看不清楚，举个反例：

如上图，学生、系、课程这些列还可以再分，所以上表不满足第一范式，只要不满足第一范式的表都不是关系型数据库表。

正确的做法是：（顺便插入几条记录）

仅仅满足第一范式还是存在很多问题，比如数据冗余过大，插入异常，删除问题，修改冗余的问题。

• 数据冗余过大：一张表中，每个学生的学号，姓名，还有系名，系主任重复出现。
• 插入异常：假设新建一个系，那么这个系的信息在还没学生前不能提前录入表中，因为没有主键。

注１：根据三种关系完整性约束中实体完整性的要求，关系中的码（注２）所包含的任意一个属性都不能为空，所有属性的组合也不能重复。为了满足此要求，图中的表，只能将学号与课名的组合作为码，否则就无法唯一地区分每一条记录。

注２：码：关系中的某个属性或者某几个属性的组合，用于区分每个元组（可以把“元组”理解为一张表中的每条记录，也就是每一行）。

• 删除问题：假设某个系的学生都没有了，删除后那么该系的信息也都没有了。实际上，虽然没有学生了，但不代表这个系不存在。
• 修改冗余：假设某个学生转系，那么就得修改他的系信息，而且还得修改多次，比如上面的小山转系，那么得修改2次。

所以为了解决这些问题，出现了第二范式。

注：属性是否真的不可拆分，根据你的设计目标而定，比如说姓名，是否还得继续拆为性和名呢？看自己。

第二范式（2NF）

要了解第二范式，需要一些前置知识：

函数依赖

定义：若在一张表中，在属性（或属性组）X 的值确定的情况下，必定能确定 属性Y 的值，那么就可以说：Y函数依赖于X，记作 X ->