MySQL三大范式

关系数据库共有六大范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。

一般来说，关系数据库只需要满足第三范式就可以了。

第一范式：原子性，字段不可再分。

 

数据表的每一列都要保持它的原子特性，也就是列不能再被分割。

这张表就不符合第一范式规定的原子性，不符合关系型数据库的基本要求，在关系型数据库中创建这个表的操作就不能成功。不得不将数据表设计为如下形式。

第二范式：字段完全依赖主键，不能存在部分依赖。

就是说一张表中只有一个主键。除了主键外的任何字段都完全依赖于主键。

下满这张表不符合第二范式的要求。

缺点

 

表一中分数完全依赖于学号和课程的属性
表二中姓名、系名、系主任完全依赖于学号的属性
第二范式消除了第一范式的部分依赖

• 表中的第一行数据都存储了系名、系主任,数据的冗余太大
• 如果有一个新的系还没有开始找到学生，那么不能讲该系的信息添加到数据表中去，从数据表中看不到该系的存在
• 如果将某个系的学生信息全部删除，那么这个系在数据表里也就不存在了，但这个系还存在。

• 如果某个人要转系，那么为了保证数据库中数据的一致性，需要修改三条记录中系与系主任的数据

  依赖

  在数据表中，属性（属性组）X确定的情况下，能完全推出来属性Y完全依赖于X。
  完全依赖
  完全依赖是针对于属性组来说，当一组属性X能推出来Y的时候就说Y完全依赖于X。
  部分依赖
  一组属性X中的其中一个或几个属性能推出Y就说Y部分依赖于X。
  结论:当一个第一范式的候选码只有一个属性的时候，那它就是第二范式(2NF)

• 表可以有多个候选码
  一般只选一个候选码作为主键
  从表中找到两个属性：学号和课程
  学号可以推出姓名、系名、系主任。
  课程可以推出成绩。
  将它们两个设置为联合主键
  

• 存在的部分依赖

• 姓名对学号存在部分依赖
• 系名对学号存在部分依赖
• 系主任对学号存在部分依赖
• 这显然不符合第二范式的要求，做出修改：
  

第三范式：没有传递依赖。

表中字段不包含其他表的字段，否则该表会被推断出来，因此经常将一张表分成多张表。

即满足第二范式前提，如果某一属性依赖于其他非主键属性，而其他非主键属性又依赖于主键，那么这个属性就是间接依赖于主键，这被称作传递依赖于主属性。 通俗解释就是一张表最多只存两层同类型信息。

下图中分类描述依赖于分类，分类又依赖于商品名称，这就是存在传递依赖。

使用：

六大范式在第一范式的基础上要求逐渐严格，表的数量增多，冗余减少。查询时关联增多，查询效率降低。

所以一般选用第三范式就可以，既保证了数据安全，也保持了一定的查询速度。

 

参考自：https://www.cnblogs.com/mr-wuxiansheng/p/6910754.html

https://www.cnblogs.com/gdwkong/p/9012262.html