数据库范式

数据库范式是为了解决如下的问题：1.减少数据冗余2.消除异常（插入、删除、更新）

 

第一范式（1NF）：（属性值都是不可分割的原子值）

所谓第一范式（1NF）是指数据库库表的每一列都是不可分割的基本数据项。例如一个实体，实体的一个属性不能有多个值或不能有重复的属性。

举例1：

说明：这个表中的属性值“分'了。“电话”这个属性里对于“小明：属性值分成了了两个。

举例2：

说明：“电话”这个属性里对于“小明”，属性值分成了了两个。

改进：

说明：以上这两种情况都不满足第一范式。针对上述情况可以是这样的表

 

第二范式（2NF）：属性完全依赖于主键（消除函数部分依赖）

第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式必须先满足第一范式。第二范式要求数据库表中的每个属性或行必须可以被唯一的区分。为实现区分，通常需要为表加上一个列，一存储各个实例的唯一标识。

第二范式要求实体的属性完全依赖主键。不能存在仅依赖主关键字一部分的属性。如果存在，这个属性和主关键字的这一部分应该分离出来形成一个新的实体。这就是所谓的消除部分依赖。

举例1：

说明：这里有两个函数依赖:①（S#，C#）→（T#，TITLE）和C#→（T#，TITLE）。因此前第一个函数依赖是局部依赖，因此上述图中的关系模式就不满足第二范式。

改进：

将上图分解为如下的两个表格

R1：

R2：

第三范式（3NF）：属性不依赖于其它非主属性（消除传递依赖）

 满足第三范式必须先满足第二范式。第三范式要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（D#）、部门名称、部门简介等信息。那么在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。

举例:

一个教师一定能确定一个教师职称。（学生，课程）->教师姓名->教师职称。

问题：

1、老师升职了，变教授了，要改数据库，表中有N条，改了N次……（修改异常）

2、没人选这个老师的课了，老师的职称也没了记录……（删除异常）

3、新来一个老师，还没分配教什么课，他的职称记到哪？……（插入异常）

那应该怎么解决呢？和上面一样，投影分解：

ＢＣＮＦ：Boyce—Codd NF（排除主属性对候选键的传递依赖）

举例：如果规定，每个书号只有一个书名，但不同书号可以有相同书名；每本书可以有多个作者合写，但每个作者参与编著的书名应该互不相同。函数依赖如下：①B#→BNAME，②（AUTHOR，BNAME）→B#

 

由上可知，函数依赖如下：①B#→BNAME，②（AUTHOR，BNAME）→B#；关键码：（AUTHOR，BNAME）或（B#，AUTHOR），因此本模式的属性都是主属性，本模式是第三范式。但是从上述的函数依赖知道属性BNAME传递依赖与关键码（AUTHOR，BNAME），因此本模式不是BCNF模式。例如一本书由多个作者编写时，其书名与书号间的联系在关系中将多次出现，带来荣誉和操作异常现象。

改进：

R1：

R2：

但是，第三范式在很大程度上减少了数据冗余，并且减少造成插入异常，更新异常，和删除异常。所以应用到第三范式就已经足够了。