[数据库] 第一范式、第二范式、第三范式、BC范式

要搞清楚常见范式,需得先了解如下概念web

数据描述术语对应表
这里写图片描述 数据库

关键码
1) 超键:在关系中能惟一标识元组的属性或属性集称为关键模式的超键。
2) 候选键:不含有多余属性的超键称为候选键。也就是在候选键中在删除属性就不是键了。
3) 主键:用户选做元组标识的候选键称为主键。通常不加说明,键就是指主键。
4) 外键:若是模式R中属性K是其余模式的主键,那么K在模式R中称为外键。svg

彻底依赖、部分依赖、传递依赖
部分函数依赖:设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(学号 ,宿舍, 费用)中,(学号)->(宿舍),宿舍!=学号,(宿舍)->(费用),费用!=宿舍,因此符合传递函数的要求;xml

1NF 一言以蔽之:“第一范式的数据表必须是二维数据表”,第一范式是指数据库的每一列都是不可分割的基本数据项,强调列的原子性,试题中某一属性不能拥有几个值。好比数据库的电话号码属性里面不能够有固定电话和移动电话值,以下图:
违反第一范式的示例blog

说明:在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不知足第一范式(1NF)的数据库就不是关系数据库。 图片

2NF 第二范式创建在第一范式的基础上,即知足第二范式必定知足第一范式,第二范式要求数据表每个实例或者行必须被惟一标识。除知足第一范式外还有两个条件,一是表必须有一个主键;二是没有包含在主键中的列必须彻底依赖于主键,而不能只依赖于主键的一部分。it

每一行的数据只能与其中一列相关,即一行数据只作一件事。只要数据列中出现数据重复,就要把表拆分开来。基础

举例来讲:当数据表中是联合主键,可是有的列只依赖联合主键中的一个或一部分属性组成的联合主键,此时须要拆表才能复合第二范式。webkit

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 在第三范式的基础上,数据库表中若是不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式。

(1)全部非主属性对每个码都是彻底函数依赖;
(2)全部的主属性对于每个不包含它的码,也是彻底函数依赖;
(3)没有任何属性彻底函数依赖于非码的任意一个组合。

R属于3NF,不必定属于BCNF,若是R属于BCNF,必定属于3NF。

假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量),且有一个管理员只在一个仓库工做;一个仓库能够存储多种物品。这个数据库表中存在以下决定关系:

(仓库ID, 存储物品ID) →(管理员ID, 数量)

(管理员ID, 存储物品ID) → (仓库ID, 数量)

因此,(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字,表中的惟一非关键字段为数量,它是符合第三范式的。可是,因为存在以下决定关系:

(仓库ID) → (管理员ID)

(管理员ID) → (仓库ID)

即存在关键字段决定关键字段的状况,因此其不符合BCNF范式。