数据库设计的三范式和反三范式

三范式

在数据库设计中我们经常会遵循三范式的规则

1.第一范式（1NF）

在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
　 所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，
即实体中的某个属性不能有多个值或者不能有重复的属性。 如果出现重复的属性，就可能需要定义一个新的实体，
新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含 一个实例的信息。
简而言之，第一范式就是无重复的列。

是不是看起来很烦？？
是了
上面是我抄的。
咱们来点通俗解释：一个字段只存储一项信息 eg:班级：高三年1班，应改为2个字段，一个年级、一个班级，才满足第一范式

					学号	姓名	班级
					0001	小红	高三年1班
					改成
					学号	姓名	年级	班级
					0001	小红	高三年	1班

是不是看起来舒坦多了，我们接着看

2.第二范式（2NF）

我就不抄那么多不好理解的了。
第二范式（属性完全依赖于主键） 定义：在满足第一范式的前提下，当存在多个主键的时候，才会发生不符合第二范式的情况。
比如有两个主键，不能存在这样的属性，它只依赖于其中一个主键，这就是不符合第二范式
通俗解释：任意一个字段都只依赖表中的同一个字段 eg:比如不符合第二范式

					学生证 名称	学生证号	学生证办理时间	借书证名称	借书证号	借书证办理时间

					改成2张表如下 学生证表
					学生证	学生证号	学生证办理时间

					借书证表
					借书证	借书证号	借书证办理时间

这里面分明有两个主体信息，学生 证 和 借书证，我们不能讲借书证的信息挂到学生证上，所以要拆分。

3.第三范式（3NF）

第三范式（属性不能传递依赖于主属性） 定义：在满足第二范式的前提下，如果某一属性依赖于其他非主键属性，
而其他非主键属性又依赖于主键，那么这个属性就是间接依赖于主键，这被称作传递依赖于主属性。
简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。

员工信息表： 	员工id	员工姓名	员工编号	部门编号 部门名称

改成 
员工信息表：员工id	员工姓名	员工编号 部门id
部门信息表：部门id	部门编号 部门名称

那我们看到，原员工信息表中，包含了大量的部门信息，这些信息在部门表中已经有了，这样会有大量的冗余数据

反三范式

没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。
具体做法是： 在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。
降低范式就是增加字段，减少了查询时的关联，提高查询效率，因为在数据库的操作中查询的比例要远远大于DML的比例。
但是反范式化一定要适度，并且在原本已满足三范式的基础上再做调整的。
简单来说，比如我们的表结构是线性的，有一定的依赖性，比如
A–B--C–D--E–F--G
我们有这么长的关联项，当我使用G表操作时，我同时要使用 A表的一个列时，那我就需要往回找六张表才能找到这个列
那这个时候，我们的操作就变得过于复杂，我们就可以考虑在 G表中冗余一个 A表的列，这样可以简化操作