Ø 显这些函数依赖都是完全函数依赖。这些函数依赖说明了所有非主属性都完全函数依赖于码Eno，所以关系模式emp_info属于第二范式。但该关系模式还存在下列的函数依赖：
Eno→Dept
Dept→Dleader
Eno→Dleader
l 上述说明非主属性Dleader传递函数依赖于码Eno，即关系模式emp_info中存在传递函数依赖，它不属于第三范式。传递函数依赖的存在同样会导致一定程度的数据冗余以及插入异常和删除异常等问题。这体现在：
Ø 一个部门有多个员工，每一个员工在关系emp_info中都形成一个元组。该元组除了包含员工编号和姓名外，还包含所在部门和部门领导的信息。后两项信息会多次重复出现，重复的次数与部门的员工数相等。这是数据冗余的根源。
Ø 数据冗余的存在导致数据维护成本增加。
Ø 当一个部门刚成立时，如果还没有招员工，那么将无法输入部门和部门领导的信息（主码Eno的输入值不能为null）。这就造成了插入异常。
Ø 出于某些原因，部门的员工可能全部辞职，或者暂时全部转到其他部门去时，需要将所有的员工信息全部删除，这时部门和部门领导的信息也将被删除。这就导致了删除异常。
l 为消除传递函数依赖，可以使用投影分解法将关系模式分解成相应的若干个模式
【例子】根据存在的传递链“Eno→Dept→Dleader”，可以从节点“Dept”上将此传递链切开，形成以下两个模式：
emp_info2(Eno, Ename, Dept)
dept_info2(Dept, Dleader)
关系模式emp_info2的码为Eno，dept_info2的码为Dept。
l 在消除传递函数依赖后得到的两个关系模式emp_info2和dept_info2都属于第三范式，它们当中都不存在传递函数依赖。
【例子】可以在没有员工信息的前提下插入部门信息；可以删除所有的员工信息而不影响部门信息；数据冗余度也有所降低了，从而也简化了其他的一些操作等。
l 属于3NF的关系模式主要是消除了非主属性对于候选的传递函数依赖和部分函数依赖，但并没有考虑主属性和候选码之间的依赖关系。它们之间存在的一些依赖关系也会引起数据冗余和操作异常等问题。人们提出了更高一级的范式——BC范式。
2.5.4 BC范式（BCNF）
定义2.11 设R(U)是一个关系模式且R(U) ∈1NF，如果对于R(U)中任意一个非平凡的函数依赖B→C，B必含有候选码，则称R(U)属于BC范式，记为R(U)∈BCNF。
l 如果要求B→C为非平凡的且完全的，则要求该函数依赖的决定因素为候选码即可。
l 在BC范式的定义中并没有明确提出其中的关系要属于3NF，但是该定义确实保证了“其非主属性既不部分函数依赖于候选码，也不传递函数依赖于候选码”，因而BCNF为3NF的一个子集，即BCNF⊆3NF。
对于BC范式中的每一个关系R(U)，它们具有下列的性质：
u R(U)中的每一个非主属性都完全函数依赖于任何一个候选码。假设存在一个非主属性attr部分函数依赖于一个候选码B0，即B0 →^p attr。由部分函数依赖的定义，必存在B0的一个真子集B0′，使得B0′→attr。由于B0′→attr是一个非平凡函数依赖。根据BCNF的定义，B0′必包含某一个候选码C0。由于候选码B0的真子集包含该候选码C0，所以B0也包含C0且C0异于B0。这说明一个候选码包含一个异于自己的另外一个候选码，这是不可能的。
u R(U)中的每一个主属性完全函数依赖于任何一个不包含它的候选码。假设存在一个主属性attr并非完全函数依赖于某一个不包含它的候选码B0。当选择该候选码B0为主码时，attr也不完全函数依赖于主码B0。这与主码的定义相矛盾。
u R(U)中没有属性完全函数依赖于非候选码（包括主码）的属性集。假设存在一个异于任何一个候选码的属性集B0和某一个属性attr，使得属性attr完全函数依赖于B0，即B0 attr。但由于B0 →^f attr，所以显然有B→attr。由BCNF的定义，B0必包含某一个候选码C0。因为B0异于任何一个候选码，所以B0≠C0，因而B0真包含C0，C0为B0的一个真子集。由于C0为候选码，所以C0→attr。这说明，存在B0的一个真子集C0，使得C0→attr。但这与B0 →^f attr相矛盾。
定理2.3 设R(U)是一个关系模式，且R(U)Î3NF，如果R(U)只有一个候选码，则R(U)ÎBCNF。
证明：对于R(U)中任意一个非平凡函数依赖C→D，假设R(U)唯一的候选码为B，只要证明C包含B即可。