关系数据库的三大范式

---

引言

数据库设计是指对于一个给定的应用环境，构造最右的数据库模式，建立数据库及其应用系统，使其能够有效存储数据，满足用户的需求

• 为了实现设计的数据库能够更加合理规范、且拥有较好的性能，诞生了一系列的规范，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小
• 目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）
• 一般来说，数据库只需满足第三范式（3NF）即可满足大部分应用需求
• 基本名词请参考：https://blog.youkuaiyun.com/Bryce_Liu/article/details/89739112

一、第一范式（1NF）

第一范式是指在一个关系中，要求每个属性都是不可再分割的

如上图所示的表格中，成绩实际可以继续分割，因而不满足第一范式的要求；如果将其转化成第一范式，则可以将成绩继续分割，如下图所示：

二、第二范式（2NF）

如果某个关系满足第一范式，而且它所有的非码属性都完全依赖于整个候选码（不存在部分依赖），则满足第二范式
第二范式也可理解为，在第一范式的基础上，每个表只描述一件事情

举例说明：
如果存在下面的一张学生选课表，由于表的候选码组是（学号，课程名称），其中姓名字段就是部分依赖于候选码组（姓名字段仅依赖学号属性也成立），不满足第二范式的规定
实际上，除了姓名字段，专业、班主任字段也都是对候选码存在部分依赖的关系

由于标的不完全依赖关系，会导致许多的问题出现：

1. 数据冗余
   当学生数量较多时，课程名称将会重复出现，形成冗余的数据
2. 更新异常
   如果部分课程需要更改课程名称，那么该课程对应的所有学生选课表中的数据都需要更新，容易出现更新异常，且需要增加工作量
3. 插入异常
   如果增加一个新的课程，且暂时没有学生选择这个课，则导致这个课程的数据无法录入系统
4. 删除异常
   假如学生选课表的数据全部被删除，那么所有的课程信息也不复存在，这就是删除异常

基于上述的问题，依照第二范式要求对其进行转换，得到下面两张表：

• 学生信息表
  
• 课程分数表：
  

三、第三范式（3NF）

在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖），则满足第三范式

回顾第二范式中列举出来的学生信息表，虽然能够满足第二范式的要求，但还是存在传递依赖，也即是非主属性班主任依赖于非主属性专业；也可以认为非主属性专业依赖于主属性学号，则班主任依赖于学号，所以存在传递依赖

第三范式的要求就是消除这样的依赖关系，因此要满足第三范式的规则，则需要讲上述的表格继续划分，得到下面的表：

• 学生信息表
  
• 专业信息表
  

参考内容：https://blog.youkuaiyun.com/lzbhnr/article/details/78469923