MySQL范式&逆范式化

范式

Normal format，是一种离散数学中都知识，是为了解决一种数据的存储与优化的问题，保证数据的存储之后，凡是能够通过关系寻找出来的数据，坚决不再重复存储，其终极目标是为了减少数据的冗余。
范式：是一种分层结构的规范，分为六层：每一层都比上一层更加严格，若要满足下一层范式，前提示满足上一层范式

六层范式 ：1NF，2NF，3NF…..6NF,1NF是最底层，要求最低6NF最高层最严格

Mysql属于关系型数据库，有空间浪费，也是致力于节省存储空间，与范式所有解决的问题不谋而合，在设计数据库的时候，会利用范式来指导设计。

但是数据库不但是要解决空间问题，要保证效率问题，范式只是为了解决空间问题，所以数据库的设计又不可能完全按照范式的要求实现：一半情况下，只有前三种范式需要满足

范式在数据库的设计当中是有指导意义：但是不是强制规范

1NF

第一范式，在设计表存储数据的时候，如果表中设计的字段存储的数据，在取出来使用之前，还需要额外的处理（拆分），那么说表的设计部满足第一范式，第一范式要求字段的数据具有原子性：不可再分。

上表设计不存在问题：但是如果需求是将数据查出来之后，要求显示一个老师从什么时候山课到什么时候结课，需要将代课时间进行拆分：不符合1NF，数据不具有原子性，可以在拆分
解决方案，将代课时间分为两个字段就能解决问题

2NF

第二范式：在数据表设计的过程中，如果有复合主键（多字段主键），且表中有字段并不是有整个主键来确定，而是依赖主键的某个字段（主键的部分），存在字段历来主键的部分的问题，称之为部分依赖，第二范式就是要解决表设计不允许出现部分依赖

以上表中，因为讲师无法作为独立主键，需要集合班级才能作为主键（复合主键：一个老师在一个班永远只带一个阶段的课）；代课时间，开始和结束字段都与当前的代课主键（讲师和班级）；但是性别并不依赖班级，教师不依赖讲师；性别只依赖讲师，教师只依赖班级，出现了性别和教师依赖主键中的一部分，部分依赖，不符合第二范式

解决方案：1. 可以将性别与讲师单独单独成表，班级和教室也单独成表；
解决方案：2取消复合主键，使用逻辑主键

Id =讲师+班级

3NF

要满足第三范式，必须满足第二范式

第三范式，理论上讲，应该一张表中的所有字段都应该直接依赖主键（逻辑主键：代表的是业务主键。无传递依赖），如果表设计中存在一个字段，并直接依赖主键，而是通过某个非主键字段依赖，最终实现依赖主键，把这种不是直接依赖主键，而是依赖非主键字段的依赖关系称之为传递依赖。
讲师带课表

以上设计方案中：性别依赖讲师存在，讲师依赖主键，教师依赖班级，班级依赖主键，性别和教师都存在传递依赖。
解决方案：将存在传递依赖的字段，以及依赖的字段本身单独取出，形成一个单独的表，然后在需要对应的信息的时候，使用对应的实体表的主键加进来。
讲师代课表

讲师表 班级表

讲师表：id=讲师 班级表中：id = 班级

逆规范化

有时候，在设计表的时候，如果一张表中有几个字段是需要从另外的表中去获取信息，理论上讲，的确可以获取到想要的数据，但是就是效率低一点，会刻意的在某些表中，不去保存另外一张表的主键（逻辑主键）而是直接保存想要的数据信息，这样一来，在查询数据的时候，一张表可以直接提供数据，而不需要多表查询（效率低），但是会导致数据冗余

如讲师代课信息表

逆规范化：磁盘利用率与效率的对抗