关系数据库的第一第二第三范式

<数据库原理> 中涉及到关系数据库的第一第二第三范式的解释，以下做些简单的理解

在解释之前，做一个简单的介绍，为什么要理解范式，是因为要设计数据库，而设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小.

范式的概念(NF)

教材中的定义:
符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度

简单理解: 一张数据表的表结构所符合的某种设计标准的级别

形象的比喻: 家里装修买地板，从最高到最低级别，可以分为甲乙丙等等各种级别，数据库也分为1NF，2NF，3NF，BCNF，4NF，5NF， 举个例子，符合3NF的关系模式，也肯定符合2NF和1NF，也就是说，符合高一级范式的设计，必定符合低一级范式.范式级别越高，冗余数据越少.

有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余。（最典型的就是在一些数据表中不仅存作为外键的user_id,同样存user_name,这样虽然违反数据库范式增加了user_name字段，但是却提高了效率，减少了获取user_id后再去user表中获取user name的操作）

一般数据库操作使用第三范式就可以,当然具体情况具体对待.

在介绍范式的使用方式之前，先简单了解下数据库的构成部分；

实体：现实世界中客观存在并可以被区别的事物。比如“一个学生”、“一本书”、“一门课”等等。值得强调的是这里所说的“事物”不仅仅是看得见摸得着的“东西”，它也可以是虚拟的，不如说“老师与学校的关系”。

属性：教科书上解释为：“实体所具有的某一特性”，由此可见，属性一开始是个逻辑概念，比如说，“性别”是“人”的一个属性。在关系数据库中，属性又是个物理概念，属性可以看作是“表的一列”。

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

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

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

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

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

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

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

候选码： 若关系中的某一属性或属性组的值能唯一的标识一个元组，而其任何真子集都不能再标识，则称该属性组为（超级码）候选码。

下面介绍三种NF:

第一范式(1NF)

1NF的定义为：符合1NF的关系中的每个属性都不可再分

下面这张表就不属于第一范式,那如果要修改为符合第一范式，该如何修改呢?

下面是修改后的图标，符合第一范式，如果不按照范式的要求去设计表，会出现什么情况，就是你的CRDU操作都会失败，数据添加不到数据库表中，不管是Mysql,Oracle,还是SqlServer;

仔细观察上面这张表，的确符合1NF，但是一个很明显的问题，冗余数据过多,可能插入，删除，修改会出现异常,接下来我们需要2NF来解决这个问题.

2NF:

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

第二范式需要理解4个名词:“函数依赖”、“码”、“非主属性”、与“部分函数依赖”

函数依赖

若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y

举个简单的例子: 学号与姓名， 学号是唯一的，大家没有异议吧，姓名可能有同名，姓名依赖于学号，这句话没毛病，但是学号依赖于姓名，这个就不成立;

函数依赖又可以分为:完全函数依赖，部分函数依赖，传递函数依赖;

码

假如当 K 确定的情况下，该表除 K 之外的所有属性的值也就随之确定，那么 K 就是码

但是这个码可能是一个属性或者是属性组,

非主属性

包含在任何一个码中的属性成为主属性

那么问题来了，我怎么判断这个是1NF,还是2NF，其实就一句话，是否存在非主属性对于码的部分函数依赖

判断的具体步骤:

第一步：找出数据表中所有的码。

第二步：根据第一步所得到的码，找出所有的主属性。

第三步：数据表中，除去所有的主属性，剩下的就都是非主属性了。

第四步：查看是否存在非主属性对码的部分函数依赖。

第二范式 其实就是去掉非主属性对于码的部分函数依赖

对于选课表，其码是（学号，课名），主属性是学号和课名，非主属性是分数，学号确定，并不能唯一确定分数，课名确定，也不能唯一确定分数，所以不存在非主属性分数对于码（学号，课名）的部分函数依赖，所以此表符合2NF的要求。

对于学生表，其码是学号，主属性是学号，非主属性是姓名、系名和系主任，因为码只有一个属性，所以不可能存在非主属性对于码 的部分函数依赖，所以此表符合2NF的要求。

第二范式的确能够解决一些问题，但是我们通常涉及数据库使用的是3NF

3NF:

3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。也就是说， 如果存在非主属性对于码的传递函数依赖，则不符合3NF的要求。

参考2NF 的表格涉及，我们发现

对于选课表，主码为（学号，课名），主属性为学号和课名，非主属性只有一个，为分数，不可能存在传递函数依赖，所以选课表的设计，符合3NF的要求。

对于学生表，主码为学号，主属性为学号，非主属性为姓名、系名和系主任。因为 学号 → 系名，同时 系名 → 系主任，所以存在非主属性系主任对于码学号的传递函数依赖，所以学生表的设计，不符合3NF的要求。

对数据表进行拆分:
选课（学号，课名，分数）
学生（学号，姓名，系名）
系（系名，系主任）

符合3NF的表格参考如下:


使用这样的表格操作的话，优势比之前，具体体现在哪里:

对第三张表的操作不会影响其他的表;
CRUD 明显一目了然;

我还是想说； 没有数据冗余的数据库并不一定是最好的数据库，所以有没有冗余的设计，要综合来考虑。

最后再提一下BCNF范式:
简单使用一句话概括:在3NF 的基础上消除主属性对于码的部分与传递函数依赖