目前关系数据库有六种范式：
1、第一范式（1NF）
2、第二范式（2NF）
3、第三范式（3NF）
4、巴斯-科德范式（BCNF）
5、第四范式(4NF）
6、第五范式（5NF，又称完美范式）
第一范式（1NF）
规定：强调属性的原子性约束，要求属性具有原子性，不可再分解
口语化解释：其实说白了，就是需要保证在数据库中的一个字段不可再分割的状态；
好比说，我们现在存储了一个地区字段，例如：广东省-广州市-天河区；
如果你将这一段信息存储在数据表中的一个字段了里面，就表示不合规范的，因为在该段信 息内，是可以将字段再拆分的；比如，将信息拆分成为 广东省、广州市、天河区，三个字段来进行存储到数据库中去；
第二范式（2NF）
规定：在1NF的基础上，需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关
口语化解释：记住第二范式的是基于第一范式的标准下，而不能脱离第一范式的范畴之外；
比如，现在我们有一张订单表，表中存在字段：订单ID、产品ID、产品数量、订单总价格、订单时间，以上五个字段
那么我们可以很清楚的知道，在上表中是订单表和产品表的结合而产生的，而且在上表中 订单总价格和订单时间，跟产品ID、产品数量，其实会导致表中的数据存在两个职能，因为订单金额和订单时间其实与产品ID和产品数量存在不同的职能， 一个是定义了产品和数量，一个是定义了订单金额、订单时间；
那么第二范式的规定，就是需要我们单一化表里面字段的定义的职能范围；
根据第二范式的规定，我们可以将表拆成两张表：
1）、订单ID、产品ID、产品数量
2）、订单ID、订单金额、订单时间
第三范式（3NF）
规定：在2NF的基础上，任何非主属性不依赖于其它非主属性
口语化解释：通俗点讲，就是我们数据里表里面的任何字段都必须跟该表中的主键的含义具有强关联性，而是不能说表中的字段是跟主键之外的字段具有强关联性；
比如，我们现在有一张学生表：
ID、学生编号、学生名称、归属班级、班级老师
在以上的表中我们定义的是学生表，那么学生对应的班级信息：ID、学生编号、学生名称、归属班级，这四个字段本身是不存在问题的，但在班级老师这个字段中就会存在一些问题，我们下面列举部分数据来体现一下问题
1、0001、张三、小A老师编号、小A老师、男、28
2、0002、李四、小A老师编号、小A老师、男、28
3、0003、王五、小A老师编号、小A老师、男、28
4、0004、狗蛋、小B老师编号、小B老师、女、24
5、0005、铁蛋、小B老师编号、小B老师、女、24
在以上数据中，我们会发现，学生表中存在学生的信息，也存在老师的信息，其实老师的信息跟学生没有多大关联，那么我们可以将以上数据表拆分成了两个表
1、0001、张三、小A老师编号
2、0002、李四、小A老师编号
3、0003、王五、小A老师编号
4、0004、狗蛋、小A老师编号
5、0005、铁蛋、小A老师编号
1、小A老师编号、小A老师、男、28
2、小B老师编号、小B老师、女、24
以上内容，就是我们平常所属的数据库设计三大范式，基本上面试的时候很多可能只是问了你数据库设计的三大范式就OK了，但其实在除了以上的三大范式之外，其实还存在另外三个范式
巴斯-科德范式（BCNF）
规定：在关系模式中每一个决定因素都包含候选键
口语化解释：规定很拗口，我们用口语化+举例来说明一下；
我个人在一开始看这个范式规定的时候，其实很别扭，因为我看着好像跟第三范式没有啥区别，但有好像有一点点区别；其实理解BC范式，你只需要知道BC模式跟第三范式的区别，你就很好理解和记忆了。
其实在BC范式可以说是包含了第三范式，如果一个数据库设计也许能够满足第三范式，但不一定满足BC范式；可以理解为BC范式是3NF的补充
例子： 学生ID、专业学科、导师ID，其实学生ID和专业学科为联合主键
student_01、 java开发、 导师_A01
student_02、 java开发、 导师_A01
student_03、 java开发、 导师_A01
student_04、 C开发、 导师_B01
student_05、 C开发、 导师_B01
在以上例子中，如果我们去根据第三范式的规定来看的，其实这个表的设计是满足的；
导师ID根据联合主键是强关联性的，但如果这边表将联合主键拆开之后呢，是存在两个关联关系的；
学生ID、专业学科 以及 专业学科、导师ID
第四范式(4NF）
规定：设关系R（X，Y，Z），其中X，Y，Z是成对的、不相交属性的集合。
口语化解释：如果你理解了，上面的几种范式，其实第四范式也很容易理解，就是说表的结构以及都是符合BC范式情况下，再去除不包含多个值的依赖关系就好了
例子：好比如说，我们现在一个人都有一个固定电话和移动电话；那么如果在规定一个人每个类型只能拥有一个的话，我们数据库表设计应该是
user_id、home_phone、modile_phone 这三个字段所属同一张表，但是我们的实际情况呢，往往是固定电话和移动电话，都不可能是只存在一个的，那么表就会变成一下这种情况
张三、8000000、18888888888
张三、8000001、18888888887
其实在上面的情况，表的设计模式是满足第三范式和BC范式的，但我们看着数据体现出来的话，其实怪别扭的；那么4NF的定义就是防止这种情况出现下的规定；
在以上的情况下，其实我们应该将表拆成两个或者改成一下这种设计：
张三、8000000、固定电话
张三、8000001、固定电话
张三、18888888888、移动电话
张三、18888888887、移动电话
第五范式（5NF，又称完美范式）
规定：消除了4NF中的连接依赖
口语化解释：我们来做一个例子说明哈
例子：订单表（订单ID、产品ID、用户ID）
其实在以上的数据库表中其实合乎我们的以上的所讲范式定义；但是第五范式的意思，就是需要们不要再同一张表里面，将这种关系全部定义在一个地方，需要拆分出来
订单ID、用户ID
订单ID、产品ID
但是在我们实际的开发以及设计中，其实这种情况我们会考虑各种查询效率的得失情况下去做设计，不会为了范式而去设计；一般我的话，汇考虑第一种设计的，因为它可以提高我的查询效率；
个人觉得第五范式还是比较鸡肋的；这种需要按照实际情况来看是否使用； 但是我们所有的设计，只要是为了提高效率之后，机会都会触犯到第五范式；
如果哪位同学觉得我表述的有问题，欢迎提出建议哈，共同进步。
