详解数据库的第一范式、第二范式、第三范式、BCNF范式

出于复试的必要性，很努力地复习了数据库的内容，大学没好好学习的东西，后期都是要花费大量的时间去弥补的。不少东西都是逝去了才知道珍惜。
目录

• 第一范式
  • 定义以及分析:
  • 问题研究：
• 第二范式
  • 必备知识点
  • 定义
  • 分析：
  • 解决办法：
  • 问题研究：
• 第三范式：
  • 定义：
  • 分析：
  • 问题分析：
• BCNF范式
  • 分析
  • 问题研究
• 小结：
• 参考文献

第一范式

定义以及分析:

首先是第一范式（1NF）。符合1NF的关系（你能够理解为数据表。“关系模式”和“关系”的区别，相似于面向对象程序设计中”类“与”对象“的区别。”关系“是”关系模式“的一个实例，你能够把”关系”理解为一张带数据的表，而“关系模式”是这张数据表的表结构。1NF的定义为：符合1NF的关系中的每一个属性都不可再分。表1所示的状况，就不符合1NF的要求。范式一强调数据表的原子性。

表1
实际上，1NF是全部关系型数据库的最基本要求，你在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中建立数据表的时候，若是数据表的设计不符合这个最基本的要求，那么操做必定是不能成功的。也就是说，只要在RDBMS中已经存在的数据表，必定是符合1NF的。若是咱们要在RDBMS中表现表中的数据，就得设计为表2的形式：

编号	品名	进货数量	进货单价	销售数量	销售单价	备注

表2
可是仅仅符合1NF的设计，仍然会存在数据冗余过大，插入异常，删除异常，修改异常的问题，例如对于表3中的设计：

表3

问题研究：

可是表三中的设计咱们能看到许多的问题，如下：

• 每一名学生的学号、姓名、系名、系主任这些数据重复屡次。每一个系与对应的系主任的数据也重复屡次——数据冗余过大
• 假如学校新建了一个系，可是暂时尚未招收任何学生（好比3月份就新建了，但要等到8月份才招生），那么是没法将系名与系主任的数据单独地添加到数据表中去的 （注１）——插入异常

注１：根据三种关系完整性约束中实体完整性的要求，关系中的码（注２）所包含的任意一个属性都不能为空，全部属性的组合也不能重复。为了知足此要求，图中的表，只能将学号与课名的组合做为码，不然就没法惟一地区分每一条记录。注２：码：关系中的某个属性或者某几个属性的组合，用于区分每一个元组（能够把“元组”理解为一张表中的每条记录，也就是每一行）。

• 假如将某个系中全部学生相关的记录都删除，那么全部系与系主任的数据也就随之消失了（一个系全部学生都没有了，并不表示这个系就没有了）。——删除异常
• 假如李小明转系到法律系，那么为了保证数据库中数据的一致性，须要修改三条记录中系与系主任的数据。——修改异常。

正由于仅符合1NF的数据库设计存在着这样那样的问题，咱们须要提升设计标准，去掉致使上述四种问题的因素，使其符合更高一级的范式（2NF），这就是所谓的“规范化”。

第二范式

第二范式（2NF）在关系理论中的严格定义我这里就很少介绍了（由于涉及到的铺垫比较多），只须要了解2NF对1NF进行了哪些改进便可。其改进是，2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖。接下来对这句话中涉及到的四个概念——“函数依赖”、“码”、“非主属性”、与“部分函数依赖”进行一下解释。

必备知识点

函数依赖：
咱们能够这么理解（但并非特别严格的定义）：若在一张表中，在属性（或属性组）X的值肯定的状况下，一定能肯定属性Y的值，那么就能够说Y函数依赖于X，写做 X → Y。也就是说，在数据表中，不存在任意两条记录，它们在X属性（或属性组）上的值相同，而在Y属性上的值不一样。这也就是“函数依赖”名字的由来，相似于函数关系 y = f(x)，在x的值肯定的状况下，y的值必定是肯定的。
例如，对于表3中的数据，找不到任何一条记录，它们的学号相同而对应的姓名不一样。因此咱们能够说姓名函数依赖于学号，写做 学号 → 姓名。可是反过来，由于可能出现同名的学生，因此有可能不一样的两条学生记录，它们在姓名上的值相同，但对应的学号不一样，因此咱们不能说学号函数依赖于姓名。表中其余的函数依赖关系还有如：

• 系名 → 系主任
• 学号 → 系主任
• （学号，课名） → 分数

但如下函数依赖关系则不成立：

• 学号 → 课名
• 学号 → 分数
• 课名 → 系主任
• （学号，课名） → 姓名

由函数依赖，咱们引出下面的一些概念
部分函数依赖：设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’→Y，则称Y部分函数依赖于X。

例1：

学号	身份证号	姓名

表4
上表中（学号，身份证号，姓名）固然学号属性取值是惟一的，在R关系中，（学号，身份证号）->（姓名），（学号）->（姓名），（身份证号）->（姓名）；因此姓名部分函数依赖与（学号，身份证号）.
例2：

sno	grade	cno

表5
在上表中，由于Sno不能函数决定Grade，Cno也不能函数决定Grade，但(Sno，Cno)能够惟一地函数决定Grade，因此(Sno，Cno)→Grade是彻底函数依赖。由于Sno能够函数决定Sage，因此(Sno，Cno)→Sage是部分函数依赖。
例3:

Sno	Sname	Sage	Sdept

表6
在上表中，函数依赖的决定方是Sno，是单属性，因此Sno→(Sname，Sage，Sdept)是彻底函数依赖，不存在着部分函数依赖。
由此，咱们知道。只有当函数依赖的决定方是组合属性时，讨论部分函数依赖才有意义，当函数依赖的决定方是单属性时，只能是彻底函数依赖。
彻底函数依赖：设X,Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每个X’都有X’!→Y，则称Y彻底函数依赖于X。

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

传递函数依赖：在关系模式R(U)中，设X，Y，Z是U的不一样的属性子集，若是X肯定Y、Y肯定Z，且有X不包含Y，Y不肯定X，（X∪Y）∩Z=空集合，则称Z传递函数依赖(transitive functional dependency) 于X。
例子：

学号	宿舍	费用
062201	A	900
062230	B	1200
062240	B	1200

表7
学号肯定宿舍、宿舍肯定费用，且有学号不包含宿舍，宿舍不肯定学号，符合传递函数依赖条件。

因此以上关系R存在添加异常（建了C宿舍可是没人住没法添加了）删除异常（学生062201退学了宿舍A也删除掉）若是存在传递函数依赖，以下更改:将上表拆解为两个表

学号	宿舍
062201	A
062230	B
062240	B

表8

宿舍	费用
A	900
B	1200
B	1200

表9
码：设 K 为某表中的一个属性或属性组，若除 K 以外的全部属性都彻底函数依赖于 K（这个“彻底”不要漏了），那么咱们称 K 为候选码，简称为码。在实际中咱们一般能够理解为：假如当 K 肯定的状况下，该表除 K 以外的全部属性的值也就随之肯定，那么 K 就是码。一张表中能够有超过一个码。（实际应用中为了方便，一般选择其中的一个码做为主码） 例如：对于表3，（学号、课名）这个属性组就是码。该表中有且仅有这一个码。（假设全部课没有重名的状况）
非主属性
包含在任何一个码中的属性成为主属性。除了主属性之外的就是非主属性。例如：对于表3，主属性就有两个，学号 与 课名。

定义

第二范式(Second Normal Form,2nd NF)是指每一个表必须有一个(并且仅有一个)数据元素为主关键字(Primary key),其余数据元素与主关键字一一对应。一般称这种关系为函数依赖(Functional dependence)关系，即表中其余数据元素都依赖于主关键字,或称该数据元素唯一地被主关键字所标识。第二范式是数据库规范化中所使用的一种正规形式。它的规则是要求数据表里的全部非主属性都要和该数据表的主键有彻底依赖关系；若是有哪些非主属性只和主键的一部份有关的话，它就不符合第二范式。同时能够得出：若是一个数据表的主键只有单一一个字段的话，它就必定符合第二范式(前提是该数据表符合第一范式)

分析：

根据2NF的定义，判断的依据实际上就是看数据表中是否存在非主属性对于码的部分函数依赖。若存在，则数据表最高只符合1NF的要求，若不存在，则符合2NF的要求。判断的方法是：

• 第一步：找出数据表中全部的码。
• 第二步：根据第一步所获得的码，找出全部的主属性。
• 第三步：数据表中，除去全部的主属性，剩下的就都是非主属性了。
• 第四步：查看是否存在非主属性对码的部分函数依赖。

对于表3，根据前面所说的四步，咱们能够这么作：
第一步：

（1）查看全部每一单个属性，当它的值肯定了，是否剩下的全部属性值都能肯定。
（2）查看全部包含有两个属性的属性组，当它的值肯定了，是否剩下的全部属性值都能肯定。
（3） ……
（4） 查看全部包含了六个属性，也就是全部属性的属性组，当它的值肯定了，是否剩下的全部属性值都能肯定。

小技巧：就是假如A是码，那么全部包含了A的属性组，如（A，B）、（A，C）、（A，B，C）等等，都不是码了（由于做为码的要求里有一个“彻底函数依赖”）。
咱们根据第一个步骤肯定出函数依赖关系，并画图以下（表3的函数关系）

图1
由此能够获得，表3的码只有一个，就是（学号、课名）。
第二步：
主属性有两个：学号 与 课名
第三步：
非主属性有四个：姓名、系名、系主任、分数
第四步：

• 对于（学号，课名） → 姓名，有 学号 → 姓名，存在非主属性 姓名 对码（学号，课名）的部分函数依赖。
• 对于（学号，课名） → 系名，有 学号 → 系名，存在非主属性 系名 对码（学号，课名）的部分函数依赖。
• 对于（学号，课名） → 系主任，有 学号 → 系主任，存在非主属性 对码（学号，课名）的部分函数依赖。

因此表3存在非主属性对于码的部分函数依赖，最高只符合1NF的要求，不符合2NF的要求。

解决办法：

为了让表3符合2NF的要求，咱们必须消除这些部分函数依赖，只有一个办法，就是将大数据表拆分红两个或者更多个更小的数据表，在拆分的过程当中，要达到更高一级范式的要求，这个过程叫作”模式分解“。
模式分解部分，很难，参考不少文献不得甚解。但愿后来者能答疑解惑
大概以为相关的具体操做能够从如下几点来考量：

1.码（码就是候选码）是多个的时候，通常每个码须要进行分解，基于每个候选码的函数依赖要归并到与当前候选码一致的分解中去。
2.码中有多个元素的时候，而且存在基于该码的部分函数依赖的时候，将其进行分解
3.根据函数依赖分解完属性组以后进行化简，去掉每个分组的重复选项
4.尝试将化简以后的分组从新进行链接操做，对比分解以前的关系模式是否是一致
5.一致则能够认为这种化简是有效的
咱们根据以上准则对表3进行分解
1.码只有一个（学号，课号），无需分解
2.码中有部分函数依赖，将其进行分解，分解为两个模式。以下图所示

图2
3.无重复项，无需分解
4.从新链接，对比分析前，关系一致。
5.该模式分解有效。

分解后的表的形式以下

表10

问题研究：

如今咱们来看一下，进行一样的操做，是否还存在着以前的那些问题？
一、李小明转系到法律系只须要修改一次李小明对应的系的值便可。——有改进数据冗余是否减小了？
二、学生的姓名、系名与系主任，再也不像以前同样重复那么屡次了。——有改进
三、删除某个系中全部的学生记录该系的信息仍然所有丢失。——无改进
四、插入一个尚无学生的新系的信息。由于学生表的码是学号，不能为空，因此此操做不被容许。——无改进

因此说，仅仅符合2NF的要求，不少状况下仍是不够的，而出现问题的缘由，在于仍然存在非主属性系主任对于码学号的传递函数依赖。为了能进一步解决这些问题，咱们还须要将符合2NF要求的数据表改进为符合3NF的要求。

第三范式：

定义：

第三范式(Third Normal Form,3rd NF)就是指表中的全部数据元素不但要能唯一地被主关键字所标识,并且它们之间还必须相互独立,不存在其余的函数关系。也就是说，对于一个知足2nd NF 的数据结构来讲，表中有可能存在某些数据元素依赖于其余非关键字数据元素的现象,必须消除。
通俗的说，第三范式（3NF）3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。也就是说， 若是存在非主属性对于码的传递函数依赖，则不符合3NF的要求。

分析：

接下来咱们看看表10中的设计，是否符合3NF的要求。对于选课表，主码为（学号，课名），主属性为学号和课名，非主属性只有一个，为分数，不可能存在传递函数依赖，因此选课表的设计，符合3NF的要求。
对于学生表，主码为学号，主属性为学号，非主属性为姓名、系名和系主任。由于 学号 → 系名，同时 系名 → 系主任，因此存在非主属性系主任对于码学号的传递函数依赖，因此学生表的设计，不符合3NF的要求。为了让数据表设计达到3NF，咱们必须进一步进行模式分解为如下形式：选课（学号，课名，分数）学生（学号，姓名，系名）系（系名，系主任）对于选课表，符合3NF的要求，以前已经分析过了。对于学生表，码为学号，主属性为学号，非主属性为系名，不可能存在非主属性对于码的传递函数依赖，因此符合3NF的要求。对于系表，码为系名，主属性为系名，非主属性为系主任，不可能存在非主属性对于码的传递函数依赖（至少要有三个属性才可能存在传递函数依赖关系），因此符合3NF的要求。。
咱们画出新的函数依赖关系图以下：

图3
咱们获得新的关系表以下：

表11

问题分析：

如今咱们来看一下，进行一样的操做，是否还存在着以前的那些问题？

• 删除某个系中全部的学生记录，该系的信息不会丢失。——有改进
• 插入一个尚无学生的新系的信息。由于系表与学生表目前是独立的两张表，因此不影响。——有改进
• 数据冗余更加少了。——有改进

BCNF范式

分析

要了解 BCNF 范式，那么先看这样一个问题：
若：某公司有若干个仓库；每一个仓库只能有一名管理员，一名管理员只能在一个仓库中工做；一个仓库中能够存放多种物品，一种物品也能够存放在不一样的仓库中。每种物品在每一个仓库中都有对应的数量。那么关系模式 仓库（仓库名，管理员，物品名，数量） 属于哪一级范式？
答：已知函数依赖集：仓库名 → 管理员，管理员 → 仓库名，（仓库名，物品名）→ 数量码：（管理员，物品名），（仓库名，物品名）主属性：仓库名、管理员、物品名非主属性：数量∵ 不存在非主属性对码的部分函数依赖和传递函数依赖。∴ 此关系模式属于3NF。基于此关系模式的关系（具体的数据）以下表所示：

表12

问题研究

好，既然此关系模式已经属于了 3NF，那么这个关系模式是否存在问题呢？咱们来看如下几种操做：

• 先新增长一个仓库，但还没有存听任何物品，是否能够为该仓库指派管理员？
  ——不能够，由于物品名也是主属性，根据实体完整性的要求，主属性不能为空。
• 某仓库被清空后，须要删除全部与这个仓库相关的物品存放记录，会带来什么问题？
  ——仓库自己与管理员的信息也被随之删除了。
• 若是某仓库更换了管理员，会带来什么问题？
  ——这个仓库有几条物品存放记录，就要修改多少次管理员信息。

从这里咱们能够得出结论，在某些特殊状况下，即便关系模式符合 3NF 的要求，仍然存在着插入异常，修改异常与删除异常的问题，仍然不是 ”好“ 的设计。
形成此问题的缘由：存在着主属性对于码的部分函数依赖与传递函数依赖。（在此例中就是存在主属性【仓库名】对于码【（管理员，物品名）】的部分函数依赖。解决办法就是要在 3NF 的基础上消除主属性对于码的部分与传递函数依赖。
仓库（仓库名，管理员）库存（仓库名，物品名，数量）
这样，以前的插入异常，修改异常与删除异常的问题就被解决了。
以上就是关于 BCNF 的解释。

小结：

至今为止没有亲自设计过数据库，最多也就是在课堂上作过数据库课程设计。未来若是本身设计数据库了，再回头看这一篇博客。修改修改。本文中大量内容和案例，来自于知乎上刘老师，后文附有参考连接。

参考文献

• 连接：https://www.zhihu.com/question/24696366/answer/29189700 来源：知乎
  做者：刘老师
• 连接：http://blog.csdn.net/rl529014/article/details/48391465 来源：CSDN