数据库设计三大范式

什么是三大范式：

第一范式：当关系模式R的所有属性都不能在分解为更基本的数据单元时，称R是满足第一范式的，简记为1NF。满足第一范式是关系模式规范化的最低要求。

第二范式：如果关系R满足第一范式，并且R的所有非主属性完全依赖于R的每一个候选关键属性，称R满足第二范式，简记为2NF。

第三范式：设R是一个满足第一范式条件的关系模式，X是R的任意属性集，如果X非传递依赖于R的任意一个候选关键字，称R满足第三范式，简记为3NF.

注：关系实质上是一张二维表，其中每一行是一个元组，每一列是一个属性

数据库第一范式

数据原子性很好理解，就是表中的字段不可再分。符合数据库第一范式的表，每个字段表意明确，看个例子：

这是一张简单的员工信息表，其中有工号、姓名、电话三个字段。通过电话这个字段获得的信息有可能是家庭电话，或是工作地点的电话，或是手机，因此表达的信息并不明确，我们可以改成这样：

数据库第二范式

在满足第一范式的基础上，实体的每个非主键属性完全函数依赖于主键属性（消除部分依赖），部分依赖当主键由两个或两个以上字段构成，而表中的某些信息通过主键的一个字段就能唯一确定，我们称这样的依赖关系为部分依赖，比如这个例子：

学生选课（学号，姓名，专业，课程号，课程名，成绩），该表中一个学生可以选多门课，一门课有多个学生。学号和课程号可以唯一确定一条记录，因此用学号和课程号做主键。

表中的姓名、专业通过主键中的学号就能唯一确定，而课程名通过课程号唯一确定，这就是部分依赖，这样的设计不符合第二范式。

不符合第二范式会带来哪些问题呢？

1、数据信息冗余

2、增删改会出现问题，比如有一门《微机原理》没有人选，那么由于缺少学号（主键之一）那么这门课程就不能出现在表里。

 

数据库第三范式

传递依赖：A依赖于B，B依赖于C，就可以说A依赖C。看这样一张表：

这张表中有如下决定关系： 学号-->姓名，性别，系号-->决定系名，宿舍号-->决定宿舍电话，也有 学号-->系名，学号-->宿舍电话。

在这样一张表中则存在着传递依赖。也就是系名依赖系号，系号依赖学号，那么间接的系名依赖学号，宿舍号、宿舍电话和学号之间也有同样的关系。这样设计表的同样会带来数据冗余，操作异常等问题。那么我们同样可以用关系分解的分解的方法来消除传递依赖，将这张表分成三张表：