特别地，在一个属于3NF的关系中，当仅有一个属性能够唯一标识每个元组时，则这个关系属于BCNF，且该属性为唯一的候选码（也只能以它为主码）。
【例2.11】观察例2.10中分解后形成的关系模式：emp_info2(Eno, Ename, Dept)
u 该关系模式中既没有部分函数依赖也没有传递依赖，所以属于3NF。且由于仅有唯一的属性Eno能够唯一标识每一个元组，所以这个关系属于BCNF。
u 定理2.3看起来非常简单，但它非常有用。在许多情况下，设计的关系往往都是有且仅有一个能够唯一标识每一个元组的属性，这时只要保证不存在对该属性的部分函数依赖和传递函数依赖即可保证该关系属于BCNF，而不用对BCNF的定义进行验证，从而避免了复杂的验证过程，提高设计效率。
u 定理2.3中的条件只是一个关系属于BCNF的充分条件，但不是必要条件。也就是说，满足该定理条件的关系必属于BCNF，但不满足该定理条件的关系也可能属于BCNF，如例2.12。
【例2.12】 对于学生住宿关系模式StuDom(学号, 姓名系别, 宿舍)而言，假定“姓名”属性也具有唯一性，那么关系模式StuDom拥有两个由单属性组成的候选码，分别是“学号”和“姓名”。由于非主属性，即“系别”和“宿舍”，不存在对任一候选码的部分或传递函数依赖，所以关系模式StuDom属于第三范式。同时关系模式StuDom中除“学号”和“姓名”外没有其它决定因素，所以StuDom关系模式属于BC范式。
u此例中，关系模式StuDom有两个候选码，分别是“学号”和“姓名”，而不是只有一个候选码（不满足定理2.3的条件），但它却属于BC范式。
u那么有没有属于第三范式的关系模式却不属于BC范式的情况呢？
【例2.13】对教学关系模式Teach(学生, 教师, 课程)，若每一名教师只教授一门课，每门课可由多名任课教师教授，某一名学生选定某门课即对应一个固定的教师。得到下述函数依赖集：
{学生, 课程}→教师
{学生, 教师}→课程
教师→课程
Ø {学生, 课程}和{学生, 教师}均是候选码。因为没有任何非主属性对码的传递函数依赖或部分函数依赖，故关系模式Teach属于三范式。关系模式Teach不属于BC范式，因为函数依赖“教师→课程”的决定因素——“教师”不含任一候选码。
u 如果一个关系模型中的关系模式都属于BCNF，则称该关系模型满足BCNF，称基于该关系模型的关系数据库满足BCNF。
u 一个满足BCNF的关系数据库已经极大地减少数据的冗余，对所有关系模式实现了较为彻底的分解，消除了插入异常和删除异常，已经达到了基于函数依赖为测度的最高规范化程度。
2.6 关系模式的分解和规范化 l 2.6.1 关系模式的规范化
Ø 关系模式的规范化实际上就是通过模式分解将一个较低范式的关系模式转化为多个较高范式的关系模式的过程。
从范式变化的角度看，关系模式的规范化是一个不断增加约束条件的过程；
从关系模式变化的角度看，规范化是关系模式的一个逐步分解的过程。
Ø 关系模式的分解是关系模式规范化的本质问题，其目的是实现概念的单一化，即使得一个关系仅描述一个概念或概念间的一个种联系。通过分解可以将一个关系模式分成多个满足更高要求的关系模式，这些关系模式可以在一定程度上解决或缓解数据冗余、更新异常、插入异常、删除异常等问题。
Ø 关系模式分解实际上又是一个关系模式的属性投影和属性重组的过程，又称投影分解。投影和重组的基本指导思想是逐步消除数据依赖中不适合的成分，结果将产生多个属于更高级别范式的关系模式。
u 投影分解的步骤就是低级范式到高级范式转化的步骤，具体步骤是：