三大范式

也可以用反范式，用空间换时间。避免大表的关联查询。

参考BLOG：
https://zhuanlan.zhihu.com/p/20028672?refer=niuwa

• 第一范式：所有的属性均不可被再分割，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项

这和MongoDB有很大区别，比如：商品的负责人，而负责人又分为 负责人姓名、负责人联系方式。
Product (id，price，负责人姓名，负责人联系方式, ….) 这就是符合第一范式的数据库设计
Product (id，price，负责人, ….) 这就是不符合第一范式的数据库设计

• 第二范式：如果依赖于主键，则需要依赖于所有主键，不能存在依赖部分主键的情况
  比如成绩表: Score（学生ID，课程ID，成绩，课程名称)
  主键是 学生ID，和课程ID， 课程成绩同时依赖这2个条件，符合第二范式，但是课程名称仅依赖课程ID，所以是不符合第二范式的。
  改进之后 Score（学生ID，课程ID，成绩)

  Course（课程ID，课程名称)
  

  改进的好处在于，修改课程名称的时候不需要修改所有的Score表，开一门新课，也可以插入到课程表中

• 第三范式
  非主属性之间不能有依赖关系
  Student(stID,Name,DepartmentID,DepartmentName)
  主属性是stID，stID确定，就可以确定 姓名，学院，学院名称。
  非主属性学院ID和学院名称非主属性之间存在依赖关系，会虽然满足第二范式，但是不满足第三范式
  Student(stID,Name,DepartmentID)
  Department(DepartmentID，DepartmentName）

• BCNF 范式
  如果一个表中有一个以上的主键或者联合主键，则需要剥离开来

比如：
Store(仓库，保管员，货品名称，货品数量）
主键可以是（仓库，货品名称），也可以是（保管员，货品名称） 因为保管员和仓库是一一对应的。
这个时候剥离出来
Store（仓库，货品名称，货品数量）
StoreManagment（仓库，保管员）

剥离的好处是：

1. 仓库更换保管员的时候，不需要同时更换所有的Store里面的数据
2. 新建一个仓库，招到保管员的时候，没进货，也可以存储相关信息了
3. 删除该仓库里面的所有物品的话，仓库名和保管员的信息也可以在StoreManagment表中查的到

单表也存在这种情况，但是剥离并没有任何好处，所以BCNF也不一定都适用。
Emp(ID,EMAIL,NAME,DEPARTMENTID,AGE）
主键可以是ID，也可以是Email，都是唯一的，应该把Email单独建一张表，虽然这样做不会有任何好处