数据库范式

首先看看各种键的定义：

超键(super key)：在关系中能唯一标识元组的属性集称为关系模式的超键（只要有一个键唯一，再随便组其他的键，合起来叫主键）

候选键(candidatekey)：不含有多余属性的超键称为候选键(最小的超键，ID,身份证号)

主键(primary key)：关系型数据库中的一条记录中有若干个属性，若其中某一个属性集(注意是集)能唯一标识一条记录，该属性组就可以成为一个主键 （在超键选取一个作为主键，如果有多个字段的叫为联合主键）

外键(foreign key)：如果关系模式R1中的某属性集不是R1的主键，而是另一个关系R2的主键则该属性集是关系模式R1的外键。

1. 第一范式【1NF】

第一范式是最基本的范式，符合数据表的原子性
简单的说，第一范式就是每一个属性都不可再分

• 表中的同一列的类型相同
• 一个列名只能对应到一列
• 并且每一列都不可分
• 行的上下文关系互不影响

上表中歌手和经纪公司有两个字段第三行都有两个名称，明显不符合数据表的原子性，应该进行如下的拆分：

2. 第二范式【2NF】

2NF在1NF的基础之上，消除了非主属性对于主属性的部分函数依赖
简单的说，是表中的非主属性必须完全依赖于主属性（所谓完全依赖是指不能存在仅依赖候选键一部分的属性）
学生基本信息表（学号，身份证号，姓名）中，当然学号属性取值是唯一的，而（学号，身份证号）->（姓名），（学号）->（姓名），（身份证号）->（姓名），所以姓名部分函数依赖于（学号，身份证号）；
所以只有一个主属性的表如果符合第一范式，那一定是第二范式。
判断一个关系是否属于第二范式：
1.找出数据表中的所有候选键；
2.找出所有主属性和非主属性；
3.判断所有的非主属性对候选键的部分函数依赖

1.{歌曲名字，歌手}可以组成候选键
2.{经纪公司}不是候选键的一部分，是非主属性
3.{经纪公司}依赖于{歌手}，但并不依赖于{歌曲名称}
4.所以非主属性{经纪公司}部分依赖于候选键{歌手名称，歌手}
不满足2NF——>方法：拆分表！

此时消除了部分依赖，满足2NF

3.第三范式【3NF】

第三范式（3NF）也就是指表中的所有数据元素不但要能够唯一地被主关键字所标识，而且它们之间还必须相互独立，不存在其他的函数关系。
也就是说，在2NF的基础上消除传递函数依赖
所谓传递函数依赖，指的是如果存在“A->B->C”的决定关系，则C传递函数依赖于A。

不满足3NF——>方法：拆分表！

符合第三范式的数据表，消除了数据冗余、更新异常、插入异常和删除异常

4. BCNF：消除主属性对主键的部分与传递依赖

5. 第四范式

第四范式是消除表中的多值依赖
以解决信息冗余，达到“一事一地”也就是一对一的关系。

{专辑发表时间}与{专辑类别}都依赖于{所属专辑}，
但是其二者之间并没有太大的关系，
定位时需要其他各列作为主键，
产生了多值依赖
不满足4NF！

回顾

1NF保证原子性
2NF去除非主属性对于主属性的部分依赖
3NF去除非主属性对于主属性的传递依赖
BCNF消除主属性对主键的部分与传递依赖
4NF消除表中的多值依赖