MySQL：面试问的范式设计

范式的好处

应用数据库范式可以带来许多好处，但是最重要的好处归结为三点：

1）减少数据冗余（这是最主要的好处，其他好处都是由此而附带的）
2）消除异常（插入异常，更新异常，删除异常）
3）让数据组织的更加和谐

但是数据库范式绝对不是越高越好，范式越高，意味着表越多，多表联合查询的机率就越大，SQL的效率就变低。

第一范式(1NF)

每一列保持原子特性

列都是基本数据项，不能够再进行分割，否则设计成一对多的实体关系。例如表中的地址字段，可以再细分为省，市，区等不可再分割（即原子特性）的字段，如下：

上图的表就是把地址字段分成更详细的city，country，street三个字段，注意，不符合第一范式不能称作关系型数据库。

第二范式(2NF)

属性完全依赖于主键-主要针对联合主键

非主属性完全依赖于主关键字，如果不是完全依赖主键，应该拆分成新的实体，设计成一对多的实体关系。

例如：选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，（学号，课程名称）是联合主键，但是学分字段只和课程名称有关，和学号无关，相当于只依赖联合主键的其中一个字段，不符合第二范式。

第三范式(3NF)

属性不依赖于其它非主属性

要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。

示例：学生关系表为Student（学号， 姓名， 年龄， 所在学院， 学院地点， 学院电话），学号是主
键，但是学院电话只依赖于所在学院，并不依赖于主键学号，因此该设计不符合第三范式，应该把学院专门设计成一张表，学生表和学院表，两个是一对多的关系。

注意：一般关系型数据库满足第三范式就可以了。

BC范式（BCNF）

每个表中只有一个候选键

简单的说，BC范式是在第三范式的基础上的一种特殊情况，即每个表中只有一个候选键 （在一个数据库中每行的值都不相同，则可称为候选键） ，在上面第三范式的noNF表（上面图3）中可以看出，每一个员工的email都是唯一的（不可能两个人用同一个email），则此表不符合BC范式，对其进行BC范式化后的关系图为:

第四范式(4NF)

消除表中的多值依赖

简单来说，第四范式就是要消除表中的多值依赖，也就是说可以减少维护数据一致性的工作。比如图4中的noNF表中的skill技能这个字段，有的人是“java，mysql”，有的人描述的是“Java，MySQL”，这样数据就不一致了，解决办法就是将多值属性放入一个新表，所以满足第四范式的关系图如下：

从上面对于数据库范式进行分解的过程中不难看出，应用的范式越高，表越多。表多会带来很多问题：
1、 查询时需要连接多个表，增加了SQL查询的复杂度
2 、查询时需要连接多个表，降低了数据库查询性能

因此，并不是应用的范式越高越好，视实际情况而定。第三范式已经很大程度上减少了数据冗余，并且基本预防了数据插入异常，更新异常，和删除异常了。