基本概念：
码：
码是数据系统中的基本概念。所谓码就是能唯一标识实体的属性，是整个实体集的性质，而不是单个实体的性质。它包括超码，候选吗，主码。
候选码：
(又称候选码，候选关键字,码 ，candidate key)：
设K是一个R(U)中的属性或属性集合(注意可以是属性集合，也即多个属性的组合)，若K完全函数确定U，则K为R的候选键(Candidate key);
通俗地说就是，能够确定全部属性的某个属性或某组属性，称为候选键。若候选键多于一个，则选定其中一个作为主键。
主属性：
包含在任何一个候选键中的属性，叫做主属性(Prime attribute),不包含在任何候选键中的属性称为非主属性或非键属性或非关键字段。
函数依赖：
设R(U)是属性集U上的关系模式。X，Y是U的子集。若对于R(U)的任意一个可能的关系r,r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不相等，则称X函数确定Y或者Y函数依赖于X。记为X->Y。
通俗来讲就是，确定属性X之后就可以确定Y，Y=f（X）。
部分/完全函数依赖：
在R(U)中，如果Y函数依赖于X,并且对于X的任何一个真子集X'，都有Y不函数依赖于X'， 则称Y对X完全函数依赖。否则称Y对X部分函数依赖。
传递函数依赖：
在R(U)中，如果X->Y, Y->Z, 则称Z对X传递函数依赖。
下面通过一个例子来理解关系数据库中1、2、3NF。
关系模型：（学号，姓名，系名，系主任，课名，分数）
第一范式（1NF）：
数据库表的每一个属性都是不可分解的。
该关系模型符合第一范式。码为：（学号，课名）
但是存在以下几个问题：
1、数据冗余，一个学生可以选择多节课，在存储的过程中会有大量的重复数据（学号，姓名等）。
2、系名、系主任不能独立存在。在删除所有同一个系的学生信息之后，该系的信息将消失；在插入一个新的系的时候，由于没有学生，所以插入操作不能进行。
3、学生在转系的时候，需要修改每一条与该学生相关的数据。（系名，系主任）
因此我们需要更加规范的设计。
第二范式（2NF）：
解决的关键就是，在1NF的基础上，消除非主属性对码的部分函数依赖。
可以看到（学号，课名）决定了（分数）是完全函数依赖，（学号）决定了（姓名，系名，系主任）是部分函数依赖；
改进之后的关系模型为：（学号，课名，分数）、（学号，姓名，系名，系主任）。
我们在来看存在的那三个问题：
1、有改进。在选课之后，重复的数据减少（只有学号）。
2、无改进。
3、有改进，学生的系信息只有一条，所以只需要修改一次。
换个说法就是，2NF要求数据表里的所有非主属性都要和该数据表的主键有完全依赖关系。所有非主属性都依赖于R的任意候选码。
第三范式（3NF）：
解决第二范式遗留的问题关键在于，系名可以单独的决定系主任，也就是说非主属性之间存在函数依赖导致了。
改进之后的关系模型：（学号，课名，分数）、（学号，姓名，系名）、（系名，系主任）。
那么问题2，就已经解决了。
所以3NF就是指表中的所有数据元素不但要能惟一地被主关键字所标识,而且它们之间还必须相互独立,不存在其他的函数关系。
BCNF：
eg：假设仓库管理关系表为StorehouseManage(仓库ID， 存储物品ID， 管理员ID，数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。
主属性：仓库ID, 存储物品ID, 管理员ID；非主属性：数量。候选码为（仓库ID，存储物品ID）、（ 存储物品ID, 管理员ID）。
显然，非主属性依赖于任意候选码，且非主属性之间不存在函数依赖，符合第三范式。
但是存在的问题是：
1、先新增加一个仓库，但尚未存放任何物品，是否可以为该仓库指派管理员？ ——不可以，因为物品名也是主属性，根据实体完整性的要求，主属性不能为空。
2、某仓库被清空后，需要删除所有与这个仓库相关的物品存放记录，会带来什么问题？ ——仓库本身与管理员的信息也被随之删除了。
3、如果某仓库更换了管理员，会带来什么问题？ ——这个仓库有几条物品存放记录，就要修改多少次管理员信息。
原因是：存在主属性对码的部分函数依赖。在此例中就是存在主属性（仓库名）对于码（管理员，物品名）的部分函数依赖。
改进之后的关系模型是（仓库ID，管理员ID）、（仓库ID， 存储物品ID，数量）。
所以BCNF意味着在关系模式中每一个决定因素都包含候选键，在3NF的基础上，消除主属性对码的部分函数依赖。
BCNF范式排除了任何属性(不光是非主属性，2NF和3NF所限制的都是非主属性)对候选键的传递依赖与部分依赖。
参考链接：
https://blog.csdn.net/gui951753/article/details/79609874#第一范式
https://www.cnblogs.com/ybwang/archive/2010/06/04/1751279.html