数据库-数据库范式

基本概念：

实体：现实世界中客观存在并可以被区别的事物。在数据库中往往是一个数据表。

属性：教科书上解释为：“实体所具有的某一特性”，在关系数据库中，属性又是个物理概念，属性可以看作是“表的一列”。

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

分量：元组的某个属性值。在一个关系数据库中，它是一个操作原子，即关系数据库在做任何操作的时候，属性是“不可分的”。否则就不是关系数据库了。

候选码和主码：表中可以唯一确定一个元组的某个属性（或者属性组）叫候选码，我们从许多个候选码中挑一个就叫主码。

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

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

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

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

数据库范式的作用：

是进行数据库设计时字段，库表划分的依据，是数据库的规范。
满足这些规范的数据库是简洁的，结构清晰的，同时，不会发生insert，delete，updata操作异常。

函数依赖与属性的关系：

设R(U)是属性集U上的关系模式，X、Y是U的子集。

如果X和Y之间是一对一（1:1）关系，如学校和校长，则存在函数依赖X→Y和Y→X。

如果X和Y之间是一对多（1:n）关系，如年龄和姓名，则存在函数依赖Y→X。

如果X和Y之间是多对多（m:n）关系，如学生和课程，则X和Y之间不存在函数依赖

第一范式(1NF): 无重复列/每一列保持原子性

数据库表中的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个系的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多的关系。 不满足第一范式不能称之为关系型数据库。
数据库表中的字段都是单一属性的，不可再分。这一单一属性由基本类型构成。包括整型，浮点型，字符型，二进制，日期型。因此，在现在任何关系型数据库(DBMS)中，不可能做出不符合第一范式的数据库。因为其不允许将一列分拆成多项。

例：

学生表(学号，用户名，性别，年龄，地址)
地址信息包含省市区可以拆分，不满足第一范式
拆分改造：
学生表(学号，用户民，性别，年龄，地址ID)
地址表（地址ID,省，市，区）
这样就满足第一范式

第二范式(2NF): 属性完全依赖主键(消除非主属性对键的部分依赖，针对联合主键)

2NF在1NF基础上建立起来，即满足2NF必满足1NF。
2NF要求数据库表的每个实例或者行必须可以被唯一区别。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。这个唯一属性被称为主键/主码。
所谓完全依赖是指不能存在仅依赖主关键字一部分的属性。如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。

例：

学生选课表(学生ID,学生姓名，学生性别，课程名称，课程成绩)
主键(学生ID,课程名称)-》联合主键
学生姓名-》学生ID(查找姓名) -》部分依赖 -》不满足第二范式
学生性别-》学生ID(查找性别) -》部分依赖-》不满足第二范式
课程成绩-》学生ID,课程名称(两个主键联合起来才能查找)-》完全依赖-》满足第二范式
拆分改造：
学生表(学生ID,学生姓名，学生性别)-》主键:学生ID
课程成绩表(课程ID,课程名字，学生ID,成绩) 主键：课程ID

所有单关键字的数据库表都符合第二范式，因为不可能存在组合关键字

第三范式(3NF): 在2NF基础上，属性不依赖其它非主属性

传递依赖：

A->B->C 那么C传递函数依赖于A。

满足第三范式不该存在如下依赖关系：

关键字段-》非关键字段x-》非关键字段y

例：

student(学号，姓名，年龄，所在学院，学院地点，学院电话) ->关键字：学号
此表存在如下关系：
学号->(姓名，年龄，所在学院，学院地点，学院电话)
这个数据库符合2NF，不存在部分依赖。
学号-》学院-》(学院地点，学院电话)
即非主键字段（学院地点，学院电话）对“关键字学号”存在传递依赖。
拆分改造:
学生表：（学号，姓名，年龄，所在学院）->主键学号
学院表：（学院，地点，电话）-》主键学院

BC范式(BCNF)

符合3NF,并且主属性内部不能有部分传递依赖。这将消除对主属性子集的依赖，使主属性最简，bc范式即检查非主属性，又检查主属性。当只检查非主属性使就变成第三范式。
若一个关系达到了第三范式，并且它只有一个候选码，或者它的每个候选码都是单属性，则该关系自然达到BC范式。

例：

一张表的数据包括：“书号、书名、作者”其中，书号是唯一的，书名允许相同，一个书号对应一本书。一本书的作者可以多个，但是同一个作者所参与编著的书名应该是不同。

存在关系：
书号->书名
（书名，作者）->书号
其中，每一个属性都为主属性，但是上述关系存在传递依赖，因此不是BCNF。即：
（书名，作者）-》书号-》书名
（书名，作者）-》书名。
拆分处理:

第四范式(4NF)： 4NF是在BCNF的基础上消除了属性间的非平凡且非函数依赖的多值依赖。

NF就是限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。对每一个出现的非平凡的多值依赖K→→A，K→→B，分表。即消除多值依赖，只允许函数依赖。也就是说，当一个表中的非主属性互相独立时（3NF），这些非主属性不应该有多值。若有多值就违反了第四范式。显然一个关系模式是4NF，则必为BCNF。

例:

一个表中存在三个数据：“课程、学生、先修课”。假设2017级的计算机专业学生想要学习JAVA课程，那么他们需要先学习VB、C#、BS三门课，才可以选择进行JAVA课程。存在关系：

课程-》学生
课程-》先修课
两个均是1：N的关系，当出现在一张表时，就会出现冗余。因此需要分解它：

第五范式(5NF)：最终范式

消除连接依赖，并且必须保证数据完整性。

要求:

必须满足第四范式；表必须可以分解为较小的表，除非那些表在逻辑上与原始表拥有相同的主键。

范式优化路线：

1NF：

非码的非平凡 | ↓ 消除非主属性对码的部分函数依赖

2NF：

↓ 消除非主属性对码的传递函数依赖

3NF：

↓ 消除主属性对码的部分和传递函数依赖

BCNF：

↓ 消除非平凡且非函数依赖的多值依赖

4NF：

↓消除不是由候选码所蕴含的连接依赖

5NF

注意：

一般我们设计数据库，大部分到第三范式，因为满足范式越高，需要拆分表越多，越影响性能。

感觉文章不错的同学麻烦动动小手点点关注订阅呗,您的肯定是对我持续更新最大的支持!