数据库的三种常用范式

范式可以看做为我们数据库中的关系（表）定义的一种标准，为了达到不同的标准需要满足不同程度的范式，我们最常用的范式有三种：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）。

 

第一范式：若关系模式满足：每一属性应具有原子性，既不可再分性，则称该关系模式是第一范式的关系模式。

比如：我们想创建一个人的关系模式，我们将该关系定义为（姓名、性别、身材）。显然，该关系中“身材”属性可以继续分解为“体重”、“身高”，所以该关系不满足1NF，为了使其满足1NF，我们将可继续分解的属性分解为不可再分的属性后再写入表中，则人的关系模式修改后为（姓名、性别、体重、身高）。

 

第二范式：若关系模式满足第一范式，而且它的所有非主属性完全函数依赖于主属性，既不存在非主属性部分依赖于主属性，则称该关系模式是第二范式的关系模式。

比如：对于一个选课关系（学号，学生姓名，课程号，课程名，学分）来说，它的候选键为（学号，课程号），所以主属性为{学号，课程号}，非主属性为{学生姓名，课程名，学分}，其中“学生姓名”依赖“学号”，“课程名”与“学分”依赖于“课程号”，既该关系存在非主属性部分依赖主属性，所以该关系不满足第二范式。为使其满足第二范式，我们可将该关系拆分为三个关系：（学号，课程号）、（学号，学生姓名）、（课程号，课程名，学分）。

 

第三范式：若关系模式满足第二范式，且它的非主属性都不传递依赖于任何主属性，则称该关系模式是第三范式的关系模式。

比如：对于一个公司的员工表（员工号，部门，部门经理），其中员工号为主键，部门依赖员工号，员工号不依赖部门，部门经理依赖部门，所以部门经理传递依赖于员工号，则该关系不满足第三范式。为使其满足第三范式，我们可将原关系拆分为（员工，部门），（部门，部门经理）。

 

不满足范式要求可能会给我们数据库带来插入异常、删除异常、更新异常、数据冗余等诸多问题，但从上述几个例子中不难发现，为了解决不满足范式的问题，我们增加了关系的属性，或则增加了关系，因此在实际运用中，我们要根据实际情况来使自己的数据库满足某一范式。

 

附上一些名词解释供大家参考：

以关系模式（身份证号码（ID），指纹（fingerprint），姓名（name），性别（sex））为例：

超键：能唯一标识元组的属性集称为超键，如（ID，name）、（ID，sex）、（name，fingerprint）等均为上述关系超键子集。

候选键：能唯一标识远组且不含多余属性的属性集称为候选键。ID 与fingerprint为上述关系的候选键。

候选键与超键均能唯一标识元组，其唯一区别在于超键可以包含多余属性而候选键不可以。

主键：从众多候选键中选取出的一个。

主属性：候选键中的所有属性。

非主属性：不在候选键中的属性。

设A、B、C是关系模式R的属性集，

函数依赖：如果不存在两个元组在A上的属性相等而在B上的不等，也就是说如果有两个元组在B上不等，那么在A上也一定不等，就称为A函数确定B或B函数依赖A。

完全函数依赖：如果B函数依赖于A，并且不存在A的一个真子集a，使得B函数依赖于a，那么就成B完全函数依赖A。

部分函数依赖：如果B函数依赖于A，且B不完全函数依赖A，就成B部分函数依赖A。

传递函数依赖：如果B依赖A，A不依赖B，C依赖B，则称C传递函数依赖A。