数据库范式

数据库范式

范式（NF）：范式是“符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度”。简单来说就是一张表的表结构所符合的某种设计标准的级别。数据库范式分为1NF，2NF，3NF，BCNF，4NF，5NF。一般在设计关系型数据库时，最多考虑到BCNF。符合高一级范式的设计，必定符合低一级范式。

关系数据库基本概念

基本概念

实体：现实世界客观存在并可以被区别的事物

属性：实体所具有的某一特性，在关系数据库中可以看做表的一列

元组：表中的一行就是一个元组

码：表中可以唯一确定一个元组的某个属性（或者属性组），如果这样的码有不止一个，那么大家都叫候选码，我们从候选码中挑一个出来做老大，叫主码。

全码：如果一个码包含了所有的属性，这个码就是全码。

主属性：一个属性只要在任何一个候选码中出现过，这个属性就是主属性。

非主属性：与上面相反，没有在任何候选码中出现过，这个属性就是非主属性。

外码：一个属性（或属性组），它不是码，但是它别的表的码，它就是外码。

关键码:

​ 主键：用户选作元组标识的候选键称为主键。一般不加说明，键就是指主键
​ 外键：如果模式R中属性K是其他模式的主键，那么K在模式R中称为外键

​ 超键：在关系中能唯一标识元组的属性或属性集称为关键模式的超键
​ 候选键：不含有多余属性的超键称为候选键
​

函数依赖

**部分函数依赖：**设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）：

属性不可分。第一范式的数据表必须是二维数据表，表的每一列都是不可分割的基本数据项。

不满足第一范式的数据库不是关系数据库。

第二范式（2NF）

2NF建立在1NF的基础上，也就是满足第二范式的一定满足第一范式

2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖

2NF要求数据表的每一个实例或者行必须被唯一标识

要求表必须有一个主键，没有包括在主键中的列必须完全依赖于主键

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

第三范式（3NF）

3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。如果存在非主属性对于码的传递函数依赖，则不符合3NF的要求。若某一范式是第二范式，且每一个非主属性都不传递依赖于该范式的候选键，则称为第三范式，即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。

符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。当然，在实际中，往往为了性能上或者应对扩展的需要，经常只需做到2NF或者1NF。

BC范式（BCNF）

在第三范式的基础上，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式。

（1）所有非主属性对每一个码都是完全函数依赖；
（2）所有的主属性对于每一个不包含它的码，也是完全函数依赖；
（3）没有任何属性完全函数依赖于非码的任意一个组合。

R属于3NF，不一定属于BCNF，如果R属于BCNF，一定属于3NF。