范式
数据库范式是一组规则。在设计关系型数据库的时候，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式。
关系型数据库有六种范式：第一范式（1NF），第二范式（2NF），第三范式（3NF），巴斯-科得范式（BCNF），第四范式和第五范式。越高的 范式数据库冗余越小。普遍人文范式越高虽然对数据关系有更好的约束性，但也可能导致数据库IO更繁忙，因此，在实际应用中，数据库设计通常只需要满足第三范式即可。
第一范式
- 数据库表的每一列都是不可分割的原子数据项，而不是集合，数组，对象等非原子数据
- 在关系型数据库的设计中，满足第一范式是对关系模式的要求。不满足的数据库不能成为关系型数据库
示例
定义一个学生表，需要记录学生信息和 学校信息
反例
这个学校是你可以继续拆分的，所以这不满足第一范式
正例
尽管他很丑陋，但是确实是满足第一范式在关系型数据库中，每一列都可以用基本数据类型表示，天然满足第一范式
第二范式
在满足第一范式的基础上，不存在非关键字对任意候选键的部分函数依赖。存在于表中定义了复合主键的情况。
候选键：可以唯一标识一行数据的列或者列的组合，可以从候选键中选一个或者多个当做表的主键
反例
- 这张表是使用学号+课程名定义复合索引唯一标识一个学生某门课程的乘积，这也是这张表的主要作用
- 学生是通过学号来确定的，学生的年龄、性别和课程没有关系，只依赖学号，不依赖课程名；学分是通过课程确定的，课程的学生和学生没有关系，学分只依赖课程名，不依赖学生；乘积同时依赖学号+课程名
- 对于使用符合主键的表，如果一行数据中有些列至于复合主键中一个或者其中几个列有关，那么就说他存在部分函数依赖，不满足第二范式
正例 - 设计表：针对需求应该设计三张表，学生表、课程表和成绩表
第二范式强调的是部分函数依赖，当一张表中的主键只有一列时，天然满足第二范式
不满足第二范式可能出现的问题
- 数据冗余
比如反例中的，学生的姓名、年龄、性别和课程学分重复出现，造成了大量的数据冗余。 - 更新异常
如果要调整MySQL的学分，那么就需要更新表中所有关于MySQL课程的记录，一旦执行终端导致某些记录更新成功，某些更新失败，就会造成一门课程出现不同学分的情况，数据不一致的问题。 - 插入异常
目前这样设计，成绩和每一门课和学生都有关系，也就是说学生参加选修课程考试取得成绩之后才能生成一条记录。当有一门新课还没有学生参加考试取得成绩之前，这么新课在数据库中是不存在的，因为成绩为空的记录没有意义。 - 删除异常
把毕业学生的考试数据全都删除，此时课程和学分的信息也会被删除掉，有可能导致一段时间内，数据库里没有某门课程和学分的信息。
第三范式
在满足第二范式的基础上，不存在非关键字段，对任意候选键的传递依赖
反例
- 因为要描述的是学生信息，并且在表中定义了ID，ID可以明确的标识每条学生信息
- 在这个表结构中，可以看出学生的学号、姓名、年龄、性别和主键ID强相关；学院的电话和学院也是强相关；在一个表中出现了两个强相关的关系，而且这两个强相关关系又存在传递现象——通过学生ID可以找到学生记录，学生记录中包含学院名，每个学院又有自己的电话和地址。
正例
需要查询的时候，只需要让学生表和学员表通过学院ID进行连接即可。此时所有的表满足第三范式。
排队刷机方案)
