数据库三大范式，数据库的设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简介的，结构明晰的，同时不会发生插入，删除，修改，操作异常
可以说是数据库规范程度的级别，比如打扫卫生，最低是扫地，二级标准是扫地加擦桌子，三级标准是扫地，擦桌子，加擦比例，标准不断上声中，高一级别的标准，是满足低一标准的，范式也是这样的
范式关系是：1NF < 2NF < 3NF < BCNF < 4NF
三大范式只是一般设计数据库的基本理念，可以建立冗余较小，结构合理的数据库，如果有特殊情况，当然要特殊对待，数据库设计最基本的是要看需求跟性能，需求>性能>表结构，所以不能一味的去追求范式建立数据库

第一范式（1NF）：列不可再分

1.每一列属性都是不可再分的属性值，确保每一列的原子性
2.两列的属性相近或相似或一样，尽量合并属性一样的列，确保不产生冗余数据
地址字段，河北省衡水市武邑县
应该分为三个字段，省 —- 市 ——- 县

第二范式（2NF）：属性完全依赖于主键

第二范式是在第一范式的基础上建立起来的，满足第二范式必须先满足第一范式，第二范式要求数据库表中的每个实例或行必须可以被唯一的区分，为实现区分通常愮为表加上一个列，以存储各个实例的唯一标识，这个唯一属性称为主键，但是主键有可能不是一个字段，有可能出现复合字段（多个）组成的
数据表中出现复合主键（多字段主键），而数据表中的有字段不是由整个主键确定的，而是由主键的某个字段确定的，存在字段依赖主键一部分的问题，这就是部分依赖，
第二范式就是不允许出现部分依赖

讲师 班级 代课时间 开始时间 结束时间 性别 教室
因为讲师没办法作为独立主键，需要结合班级，称为复合主键，（一个老师在以一个班级，只带一个阶段），代课时间，开始结束时间，都是依赖符合主键的，
但是性别是依赖复合主键中的讲师，教室依赖复合主键中的班级，这就是部分依赖，不符合第二范式
将性别与老师单独成表，班级与教室单独成表
讲师 班级 代课时间 开始时间 结束时间
讲师 性别
班级 教室

第三范式（3NF）：属性不依赖于其他非主属性，属性直接依赖于主键

数据不能存在传递关系，每个属性都跟主键有直接关系，而不是间接关系，像a->b->c，这样的不符合第三范式，在第二范式的前提下
接触依赖关系，直接依赖主键，第二范式主要是接触部份依赖
订单id 订单商品 用户 性别 手机号
此字段中，性别，手机号是依赖用户的，没有依赖主键，违背原则，需要拆分用户表
订单id 订单商品 用户id 用户id 用户 性别 手机号

BC范式（BCNF）

属于修正的第三范式，是防止主键的某一列会依赖于主键的其他列，当第三范式消除了主键属性对码的部分函数依赖和传递函数依赖称为BCNF
就是说复合主键中的多个字段不能形成依赖关系，
仓库 仓库管理员 货物 数量
仓库跟仓库管理员是复合主键，但是他们之间又存在依赖关系，管理员依赖仓库，这样就不行，需要分离表
仓库 货物 数量 仓库 仓库管理员

第四范式

非主属性不应该由多值，如果有多值就违背了第四范式，
第四范式是限制关系模式的属性间不允许有非平凡且非函数依赖的多值依赖
我的理解：字段不能重复
用户id 固定电话，移动电话，整个就是设计不合理，改为 用户id 电话类型 电话号码
说明：如果只考虑函数依赖，关系模式规范化程度最高的是BCNF，如果考虑多值依赖则是4NF

第五范式（5NF）

属于最终范式，消除了第四范式中的连接依赖，
要求：
必须满足第四范式
表必须可以拆分为较小的表，除非那些表在逻辑上拥有与原始表相同的主键
一般实际应用中不必考虑第五范式

反范式化

不满足范式的数据库设计，就是反范式化
用户关心的是方便，清晰的数据，所以在设计数据库时，设计人员跟客户在数据库的设计规范化和性能之间有一定的矛盾
通过三大范式分离表，分解成多个，但是为了满足业务需要，最终需要通过多个表的连接查询来得到数据，添加，修改依旧如此，这样数据操作的性能就会收到影响，
所以在实际的数据库设计中，既要考虑三大范式，避免数据的冗余跟操作异常，也要考虑数据访问性能，减少表连接，提高访问性能，也可以允许设当的数据冗余，提高数据的处理速度，这是以空间换时间的做法
比如商品表，有商品单价，数量，金额，这就不符合第三范式，金额可以通过数量跟单价计算出来，数据冗余字段，但是可以直接取数据，不需要就算得出，提高了查询效率
磁盘利用率与效率的对抗