Mysql详解——范式

一、数据库的设计规范

1. 范式

在关系型数据库中，关于数据库表设计的基本原则，规则被称为范式，范式的英文名称为Normal Form，简称NF。要想设计一个合理的关系型数据库，就需要满足一定的范式。

目前关系型数据库有六种常见范式，按照范式级别，从低到高有：第一范式（1NF），第二范式（2NF），第三范式（3NF），巴斯科德范式（BCNF），第四范式（4NF），第五范式（5NF，又称完美范式）。

数据库的范式设计得越高阶，冗余度就越低，同时高阶的范式一定满足低阶的范式的要求。

一般来说，在关系型数据库中，最高也就遵循到BCNF，普遍是3NF，但也不是绝对，有时候为了提高某些查询性能，我们还需要破坏范式规则，也就是反规范化。

一些概念：

• 超键：能唯一标识元组的属性集称为超键。
• 候选键：如果超键中不包含多余的属性，那么这个超键就称为候选键。
• 主键：用户可以从候选键中选择一个作为主键。
• 外键：如果数据表R1中的某属性不是R1的主键，但是是数据表R2的主键，那么这个属性就是R1的外键。
• 主属性：包含在任一候选键中的属性称为主属性。
• 非主属性：指不包含在任何一个候选键中的属性。

通常我们会将候选键称为码，把主键称为主码。

1.1 第一范式

第一范式主要确保数据表中每个字段的值都具有原子性，也就是说表中每个字段不能再被拆分。这个范式一定需要遵守。

例如某个字段user_info，包含了家庭住址，邮箱，电话，这显然是不可以的，需要将user_info拆分成对应的三个字段。

但是原子性事实上是主观的，例如姓名name可能有firstName，lastName，那是否需要拆分，再例如是否需要将地址拆分成省份，区域等，这取决于应用程序是否需要查询到哪种粒度。

1.2 第二范式

在满足第一范式的基础上，还要满足数据库表中的每一条数据，都是可唯一标识的。而且所有非主键字段，都必须完全依赖主键，不能只依赖主键的一部分。

举例1：

成绩表（学号，课程号，成绩）关系中，（学号，课程号）可以决定成绩，但是学号不能决定成绩，课程号也不能决定成绩，所以（学号，课程号）和成绩就是完全依赖关系。

举例2：

比赛表，里面包含了球员编号，姓名，年龄，比赛编号，比赛时间，比赛场地等属性，由于单单球员编号和比赛编号都无法确定唯一一条数据，因此需要将球员编号和比赛编号联合作为主键：

(球员编号，比赛编号) --> (姓名，年龄，比赛时间，比赛场地，得分)

但是这个表并不满足第二范式，因为数据表中的字段并不满足完全依赖主键的条件：

(球员编号)  --> (姓名，年龄)

(比赛编号)  --> (比赛时间，比赛场地)

不满足第二范式的问题：

• 数据冗余：如果一个球员参加了n场比赛，那么球员的姓名和年龄就重复了n次，一个比赛也有可能有m个球员参加，那比赛的时间和地点就重复了m次。
• 插入异常：如果我们想要添加一场新的比赛，但是这时球员还没有确定，那么就无法插入。
• 删除异常：如果我们想要删除某个球员编号，会将比赛信息删除掉。
• 更新异常：如果我们想要调整某个比赛的时间，那么数据库表中所有关于这个比赛的时间都需要进行调整，否则会出现一场比赛时间不同的情况。

因此为了避免上面的问题，我们可以将上面球员比赛表设计成三张表，这样每张表都符合了第二范式

球员表：球员编号，姓名，年龄等

比赛表：比赛编号，比赛场地，比赛时间等

球员比赛关系表：球员编号，比赛编号，得分等

1.3 第三范式

在第二范式的基础上，确保数据表中的每一个非主键字段都和主键字段直接相关，也就是说，要求数据表中的所有非主键字段不能依赖于其他非主键字段字段。（即不能存在非主属性A依赖非主属性B，非主属性B依赖于主键C的情况），通俗来说，该规则的意思是所有非主键属性之间不能有依赖关系，必须相互独立。

举例：

员工信息表：员工编号，姓名，部门编号，部门名称。

上面的员工信息表是符合第二范式的，因为姓名，部门编号，部门名称都完全依赖员工编号这个主键，但是并不符合第三范式，因为有非主键字段 部门名称 依赖于非主键字段 部门编号。因此需要将部门编号，部门名称再抽取成一张表。

1.4 小结

第一范式：确保每列的原子性

第二范式：非主键列完全依赖着主键列

第三范式：非主键列之间不存在依赖关系

范式的目的是为了降低数据的冗余，缺点是可能会降低了查询效率，因为范式等级越高，设计出来的表就越多，越精细，进行查询时就可能需要关联多张表。

实际上设计数据库时，并非会完全遵守这些标准，经常会为了性能违反范式原则，通过增加冗余的数据来提高数据库的性能。

2. 反范式化

有时候为了性能，并不一定会完全遵守范式标准。

举例1：

有员工表employee，和部门表department，如果经常需要查询员工的部门名称，并且员工很多，那么可以考虑在员工表中添加部门名称 这一冗余字段：

select emp_id, dept_name
from employee e join department d
on e.dept_id = d.dept_id;

反范式的问题：

• 存储空间变大了
• 一个表中的字段做了修改，另一个表中的冗余字段也需要做相应的修改。
• 在数据量小的情况下，反范式反而不能体现性能上的优势，可能还会让数据库的设计变复杂。

反范式的使用场景：

• 当加上冗余信息后能够大幅度提高查询效率
• 这个冗余字段不需要经常修改

3. 巴斯范式

人们在3NF的基础上进行了改进，提出了巴斯范式（BCNF）。

若一个关系达到了第三范式，并且它只有一个候选键，或者它每个候选键都是单属性，则为巴斯范式。简单来说就是主属性和其他主属性存在依赖关系。

一般来说，数据库设计达到第三范式或巴斯范式就可以了。

案例分析：

在这个表中，一个仓库只有一个管理员，并且一个管理员只管理一个仓库。

进行分析可知，（仓库名，物品名）或者（管理员，物品名）可以决定数量，因此（仓库名，物品名）或者（管理员，物品名）就是这个表的候选键。

符合第一范式：所有字段都是原子性的。

符合第二范式：表中非主属性 “数量” 完全依赖两个候选键

符合第三范式：并不存在非主属性依赖于非主属性。

存在的问题：

• 增加一个仓库，但是还没有存放物品，由于主键（仓库名，物品名）不能有空值存在，因此会插入异常。
• 如果仓库的物品全部卖完了，那么会导致仓库名和管理员名称也会随之删除。
• 如果仓库的管理员更换了，那么会有多条记录都需要更改。

因此，即便表符合了3NF，但是还是可能存在插入，删除，更新异常的问题。

问题出现的原因：

主属性仓库名对于候选键（管理员，物品名）有部分依赖，这样就导致有可能出现上面的问题，因此引入BCNF，它在3NF的基础上消除了主属性对候选键的部分依赖或者传递性依赖。

如何解决：

将仓库名和管理员拆分出来形成一张表，然后（仓库名，物品名，数量）形成一张库存表。

4. 第四范式

如果表中存在多个 1对多关系 时，需要进行拆分。

例如有职工表（职工编号，职工孩子，职工选修课程），在这张表中，每个职工可能有多个孩子，也有可能有多个选修课程，因此需要进行拆分成两张表：职工表一（职工编号，职工孩子），职工表二（职工编号，职工选修课程）。

5. 第五范式

。。。挖坑，不是很重点，有空再填。