关系型数据库三个范式

关系型数据库三个范式

相关概念

候选关键字：

​ 二维表中，可以唯一肯定记录的一个字段或几个字段的组合被称为“超关键字”。“超关键字”虽然能惟一肯定记录，可是它所包含的字段多是有多余的。 若是一个超关键字去掉其中任何一个字段后再也不能惟一地肯定记录，则称它为 候选关键字。候选关键字既能惟一地肯定记录，它包含的字段又是最精炼的。也就是说候选关键字是最简单的超关键字。

主关键字(primary key)：

​ 是表中的一个或多个字段，它的值用于惟一地标识表中的某一条记录。 好比在一张成绩表中，有字段：学号，科目，成绩，任课老师。 学号+科目+任何其余字段就是超关键字，可是若是去掉学号或者科目中的一个就没法肯定成绩，因此学号和科目是两个候选关键字。 只有知道了学号和科目你才能肯定一条记录，因此学号和科目两个字段组成了主关键字

部分函数依赖

​ 设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’→Y，则称Y部分函数依赖于X。

​ 举个例子：学生基本信息表R中（学号，身份证号，姓名）固然学号属性取值是惟一的，在R关系中，（学号，身份证号）->（姓名），（学号）->（姓名），（身份证号）->（姓名）；因此姓名部分函数依赖与（学号，身份证号）；

彻底函数依赖

​ 设X,Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每个X’都有X’!→Y，则称Y彻底函数依赖于X。

​ 例子：学生基本信息表R（学号，班级，姓名）假设不一样的班级学号有相同的，班级内学号不能相同，在R关系中，（学号，班级）->（姓名），可是（学号）->(姓名)不成立，（班级）->(姓名)不成立，因此姓名彻底函数依赖与（学号，班级）；

传递函数依赖

​ 设X,Y,Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。

举例：在关系R(学号 ,宿舍, 费用)中，(学号)->(宿舍),宿舍！=学号，(宿舍)->(费用),费用!=宿舍，因此符合传递函数的要求；

第一范式（1NF）

​ 第一范式是指数据库中每一列都不可再次分割，某一属性不能拥有几个值，保证每一列的原子性。

​ 例如：好比一个员工表，员工表有，姓名，地址，电话属性（可能有座机号码和移动电话号码），这个时候就电话属性就不符合第一范式，须要拆分为座机号码和移动号码2个属性。

第二范式（2NF）

第二范式是创建在第一范式的基础上的，及知足第二范式必定知足第一范式。

第二范式要求：

1. 每个实例 (及每一行) 必需要有一个惟一标识符,必需要有主键。
2. 没有包含在主键中的列必须彻底依赖于主键，而不能只依赖主键的一部分。

例如： 若是数据库是联合主键，有的列只依赖联合主键中的一部分，而不是所有，那么只有分表才能符合第二范式。在选课关系表(学号，课程号，成绩，学分)，关键字为组合关键字(学号，课程号)，但因为非主属性学分仅依赖于课程号，对关键字(学号，课程号)只是部分依赖，而不是彻底依赖，所以此种方式会致使数据冗余以及更新异常等问题

第三范式（3NF）

​ 若某一范式是第二范式，且每个非主属性都不传递依赖于该范式的候选键，则称为第三范式，即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的状况 。

例如： Employee(emp_id,emp_name,emp_age,dept_id,dept_name,dept_info)，当员工表中emp_id可以惟一肯定员工员工信息，可是dept_name可由dept_id惟一肯定，此时，该表不符合第三范式，此时能够删除除了dept_id以外的其余部门信息，把全部部门信息单独创建一张部门表 。

BCNF范式

​ BCNF是比第三范式更严格一个范式。它要求关系模型中全部的属性（包括主属性和非主属性）都不传递依赖于任何候选关键字。也就是说，当关系型表中功能上互相依赖的那些列的每一列都是一个候选关键字时候，该知足BCNF。

BCNF其实是在第三范式的基础上，进一步消除了主属性的传递依赖。

​ 举例：有这样一个配件管理表WPE(WNO,PNO,ENO,QNT),其中WNO表示仓库号，PNO表示配件号，ENO表示职工号，QNT表示数量。

有如下约束要求：

1. 一个仓库有多名职工；

2. 一个职工仅在一个仓库工做；

3. 每一个仓库里一种型号的配件由专人负责，但一我的能够管理几种配件；

4. 同一种型号的配件能够分放在几个仓库中。

分析表中的函数依赖关系，能够获得：

1. ENO->WNO;

2. （WNO，PNO）->QNT

3. （WNO，PNO）->ENO

4. （ENO，PNO）->QNT

​ 能够看到，候选键有：（ENO,PNO）;(WNO,PNO)。因此，ENO,PNO,WNO均为主属性，QNT为非主属性。显然，非主属性是直接依赖于候选键的。因此此表知足第三范式。

​ 而咱们观察一下主属性：（WNO,PNO）->ENO;ENO->WNO。显然WNO对于候选键（WNO,PNO）存在传递依赖，因此不符合BCNF.

​ 解决这个问题的办法是分拆为两个表：管理表EP（ENO，PNO，QNT）；工做表EW（ENO，WNO）。但这样作会致使函数依赖（WNO,PNO）->ENO丢失。

​