本文整理的网上比较符合本人理解的关于范式的解释，参考链接如下：
https://blog.csdn.net/u013164931/article/details/79692402， https://www.cnblogs.com/lca1826/p/6601395.html 以及https://www.2cto.com/database/201404/290140.html
第一范式：简单说 列不能再分
第二范式：简单说 建立在第一范式基础上，消除部分依赖
第三范式：简单说 建立在第二范式基础上，消除非主属性对候选码的传递依赖。
BCNF：在第三范式的基础上，消除主属性对其他主属性的传递函数依赖。
一个满足BCNF的关系模式的条件:
1.所有非主属性对每一个码都是完全函数依赖。
2.所有的主属性对每一个不包含它的码,也是完全函数依赖。
3.没有任何属性完全函数依赖于非码的任何一组属性。
进一步举例子解释BCNF：（来自链接，写的非常生动易懂）
BCNF：中文叫巴斯范式，是由Boyce和Codd提出的,比3NF又进了一步,通常认为是修正的第三范式。
例如：设关系模式R<U，F>∈1NF，如果对于R的每个函数依赖X→Y，若Y不属于X，则X必含有超码，那么R∈BCNF。
假设仓库管理关系表 (仓库ID, 存储物品ID, 管理员ID, 数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。
这个数据库表中存在如下决定关系：
(仓库ID, 存储物品ID) →(管理员ID, 数量)
(管理员ID, 存储物品ID) → (仓库ID, 数量)
所以，(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：
(仓库ID) → (管理员ID)
(管理员ID) → (仓库ID)
即存在关键字段决定关键字段的情况，所以其不符合BCNF范式。
3NF和BCNF的区别：一句话就是3NF是要满足不存在非主属性对候选码的传递函数依赖，BCNF是要满足不存在任一属性（包含非主属性和主属性）对候选码的传递函数依赖。
相关知识点：
码：表中可以唯一确定一个元组的某个属性（或者属性组），如果这样的码有不止一个，那么大家都叫候选码，我们从候选码中挑一个出来做老大，它就叫主码。
主属性：一个属性只要在任何一个候选码中出现过，这个属性就是主属性。
非主属性：与上面相反，没有在任何候选码中出现过，这个属性就是非主属性。
完全函数依赖
定义：设X,Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每一个X’都有X’!→Y，则称Y完全函数依赖于X。
比如，一个学生上一门课，一定是特定某个老师教。所以有（学生，课程）－>老师
这就是完全依赖。
部分函数依赖
定义：设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’→Y，则称Y部分函数依赖于X。
码用(学号+课程),为什么要加课程呢？因为不同课程成绩是通过学号查不出来的。
不过用(学号+课程)当作码是不是有些问题？
(学号+课程)->姓名，但是学号->姓名
(学号+课程)->系名，但是学号->系名
(学号+课程)->系主任，但是学号->系主任
这个就是部分依赖
要是上面那张表符合第二范式。需要将表拆分为两张表。
一张是 学号、课程、分数表
另外一张是 学号、姓名、系名、系主任表
传递函数依赖
设X,Y,Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。
https://blog.csdn.net/rl529014/article/details/48391465
采用这位大佬的例子
在关系R(学号 ,宿舍, 费用)中，(学号)->(宿舍),宿舍！=学号，(宿舍)->(费用),费用!=宿舍，所以符合传递函数的要求