对于关系型数据库三大范式+BC范式的理解。
范式的定义
关系型数据库中的关系是需要满足一定条件的，满足这些不同程度的规范化就叫做范式。
范式按照规范化程度从低到高排序为第一范式，第二范式，第三范式，BC范式，第四范式，第五范式。
本文主要对最常见的第一范式，第二范式，第三范式以及BC范式进行解释S。
第一范式
说明
第一范式满足关系表中的属性不可分割。属性即关系表中的字段；不可分割即该属性/字段已经是不可分割的最小单位了。
例子
学生信息表：由学号、姓名、年龄、性别等字段组成。该表的这些字段都不能再拆分为更小的属性了。
一范式是关系数据库的基础。
第二范式
说明
第二范式是建立在第一范式的基础之上的，也就是说第二范式首先要满足关系表的属性不可分。在此基础之上，第二范式规定每个关系表都要有主键，且其他字段都依赖于主键，具体来说关系表的每个非主属性都完全函数依赖于主键。
为什么要有主键？没有主键就没有唯一性，没有唯一性在集合中就定位不到这行记录，所以要主键。
其他字段为什么要依赖于主键？因为不依赖于主键，就找不到他们。更重要的是，其他字段组成的这行记录和主键表示的是同一个东西，而主键是唯一的，它们只需要依赖于主键，也就成了唯一的。
什么是主属性和非主属性？主属性就是候选键中的每一个属性，候选键可能是多个属性（候选键可以有多组，例如候选键为AB或者AC，属性ABC都包含在候选键中，即ABC都是主属性）。不包含在候选键的属性叫非主属性。
什么是完全函数依赖和部分函数依赖？（学号， 身份证号）-> 姓名，身份证号 -> 姓名，则姓名部分函数依赖于（学号， 身份证号）。（身高，体重）-> 身体指数，身高或者体重单属性并不能确定身体指数，所以身体指数完全函数依赖于（身高，体重）。
例子
学号、姓名、年龄、性别等字段组成学生信息表。姓名字段可以作为主键么？不能！因为同名的话，就不能唯一确定一条记录了，需要学号这样的唯一编码才能作为学生信息表的主键。
第三范式
说明
在第二范式的基础上，消除属性之间的传递依赖。即在第二范式的基础上，关系表若满足每个非主属性都不传递函数依赖于主键，就是第三范式。
什么是非主属性都不传递函数依赖于主键？关系表中有非主属性C依赖于非主属性B，非主属性B依赖于主键A，则非主属性C传递函数依赖与主键A。
例子
简单来说，消除传递依赖，可以看做是“消除冗余”。即相关信息只能存储于一张表中，而不应该重复出现于多张表中。
例如大学分了很多系（中文系、英语系、计算机系……），系别管理表由以下字段系编号，系主任，系简介，...... 组成。在学生信息表（学号、姓名、年龄、性别）中，我们能不能把学生的系编号，系主任、系简介添加至每条学生记录中？第三范式不允许！在组合表中，学号是主键，系编号依赖于学号，而系主任、系简介依赖于系编号，所以存在学号->系编号->系主任、系简介的函数传递依赖。因为系编号，系主任、系简介已经存在系别管理表中，你再存入学生信息表，就是冗余了。
解决该问题以满足第三范式的方法，就是在学生信息表中只存放系别管理表的主键，作为学生信息表的外键以消除冗余。
BC范式
说明
满足以下三点：
1）所有非主属性对每一个码都是完全函数依赖。（也是第二范式要求）
2）所有主属性对每一个不包含它的码也是完全函数依赖。（也就是排除了所有属性对码的部分依赖）
3）没有任何属性完全函数依赖于非码的任何一组属性。（排除传递函数依赖）
例子
假设仓库管理关系表(仓库ID, 存储物品ID, 管理员ID, 数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。
此关系模式已经属于了3NF，那么这个关系模式是否存在问题呢？我们来看以下几种操作：
1.先新增加一个仓库，但尚未存放任何物品，是否可以为该仓库指派管理员？——不可以，因为物品名也是主属性，根据实体完整性的要求，主属性不能为空。
2.某仓库被清空后，需要删除所有与这个仓库相关的物品存放记录，会带来什么问题？——仓库本身与管理员的信息也被随之删除了。
3.如果某仓库更换了管理员，会带来什么问题？——这个仓库有几条物品存放记录，就要修改多少次管理员信息。
从这里我们可以得出结论，在某些特殊情况下，即使关系模式符合3NF的要求，仍然存在着插入异常，修改异常与删除异常的问题，仍然不是 ”好“ 的设计。
具体原因是该数据库表中存在如下依赖关系：
(仓库ID, 存储物品ID) →(管理员ID, 数量)
(管理员ID, 存储物品ID) → (仓库ID, 数量)
所以，(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下依赖关系：
(仓库ID) → (管理员ID)
(管理员ID) → (仓库ID)
即存在关键字段依赖关键字段的情况，不满足说明中的第二条，所以其不符合BCNF范式。
