MySQL~范式概述、12345范式+巴斯范式（BCNF）、反范式化

范式概述

范式：

• 关系型数据库中，数据表设计的规则就是范式
• 要想设计一张合理的数据表，必须满足某种范式

范式分类：
关系型数据库中，有6种：
12345范式+巴斯范式（BCNF）

从低到高阶：123+巴斯+45

• 范式越高阶，冗余度越低
• 高阶一定符合低阶要求
• 满足最低要求的是第一范式，有更多规范要求的是第二范式，以此类推，越来越严格
• 实际开发中，一般都是3NF，最多到巴斯范式，剩下的45范式很少涉及

键和相关属性

• 超键：标识元组的属性集

可以理解为主键 或者 主键+其他字段 的组合就是超键
只要能唯一确定这条数据的字段/字段组合就可以叫超键

• 候选键：如果超建没有其他属性，就是候选键

可以理解为 最小的超键。
只要能唯一确定这条数据的单一字段就是候选键

• 主键：用户可以从候选键中选一个作为主键
• 外键：如果表1中某个属性不是主键，是表2的主键，那这个属性就是表1外键
• 主属性：在任一候选键中的属性

可以作为主键的字段就是主属性

• 非主属性：不在任意候选键中的属性

第一范式（1NF）

主要确保每个字段值具有原子性，放在数据表中每个字段的值都是最小的，不可以进行拆分的.

错误举例：手机号字段中只能放一个手机号，不能存放两个手机号

第二范式（2NF）

• 要求：
  1.必须满足范式1
  2.表中任意数据，必须可唯一标识
  3.所有非主键字段，必须完全依赖主键，不能部分依赖主键。比如主键是联合主键A+B，现在要查找C，必须知道A和B才能确认C是完全依赖，知道A或B中的一个就可以确认C是部分依赖

举例：
成绩表中 ，主键是（学号+课程），要想查询成绩，必须知道哪个课，哪个学生。只知道学号或者课程都无法确认成绩，这就是完全依赖.

如果非主属性不是完全依赖主键，会出现下列问题：

• 数据冗余：出现大量重复数据
• 插入异常：无法确定插入那个记录中
• 删除异常：删除时会删除其他记录
• 更新异常：更新一条记录会导致其他记录更新

1NF指出字段属性需要是原子性的
2NF指出一张表就是一个独立的对象，一张表值表达一个意思

举例：

总结：第2范式就是要求表中的字段必须完全依赖主键字段，如果不完全依赖，应该分离出去，建立一个新表，旧表和新表之间是一对多关系

第三范式（3NF）

• 要求：
  1.必须符合第2范式
  2.数据表中所有非主键字段不能依赖于其他非主键字段。主键是A或B，那么C可以依赖A，或者依赖B，但是不能依赖D，或表里其他字段

非主键字段之间不能互相依赖，必须相互独立

巴斯范式（BCNF）

全名巴斯科德范式，因为没有新的规范加入，只是在3NF的基础上稍微严格了一些，所以不被称为第四范式，可以理解为是对第三范式的一个扩充.

• 要求：
  1.符合3NF
  2.只有一个主键，主键只有一个字段

通常数据库的设计就到3NF或者BC就可以了

举例：
学生导师表中，学生+专业是联合主键

该表符合三范式：字段值不可分、字段完全依赖主键、非主键字段相互独立。但有一个问题是 专业依赖导师，知道了导师，自然就知道了学生专业.这不符合BC范式，所以拆成2个表：

第四范式（4NF）

在巴德范式的基础上，把同一表内多对多的关系删除

举例：
职工表（职工编号，职工姓名，职工选修课）
该表中，同一个职工可能有多个孩子，也可能选修多个课程，这就是多对多的关系，不符合4NF
如果想要符合4NF，可以将上表拆成2个表：
职工表1（职工名，职工孩子姓名）
职工表2（职工名，职工选修课程）
这样每个表都是一对多的关系，符合4NF

第五范式（5NF）了解即可

第五范式又叫完美范式，在4NF的基础上，消除非候选键的连接依赖

如果关系模式R中每一个连接依赖都是和R的候选键相关，那么R就符合完美范式.

5NF针对的是无损连接问题，由于无损连接在实际中很少出现，所以没啥意义，了解即可。

反范式化

• 概述
  1.遵循业务优先原则,不能只遵循范式，随机应变
  2.数据量非常大，系统访问频次高时，如果只遵循范式，会产生大量关联查询，影响数据库性能，这时需要反范式化

• 可能带来的问题
  1.空间换时间，存储空间变大
  2.表中字段修改，如果另一张表中有冗余字段，也需要修改，否则数据不同步
  3.数据量非常小的情况下，不适合用反范式，体现不出性能优势，反而让数据表变得复杂

• 使用场景：冗余信息非常有价值的时候

• 什么字段适合做冗余字段：必须用，不需要经常修改