关系模式teacher的候选码只有“课程名”，而“任课教师名”和“任课教师职称”都是非主属性。显然有函数依赖集{课程名→任课教师名, 任课教师姓名→任课教师职称, 课程名
上例中关系模式teacher属于2NF，仍存在数据冗余和插入、删除操作异常。
【例子】若某任课教师上多门课，则需要在teacher表中存储多次该教师的职称信息（数据冗余）；对于一个新来教师，如果其还没有排课，那么将无法输入该教师的信息，因为课程名作为主码不能为空（插入异常）；又如删除一个任课教师的所有任课记录，则找不到该任课教师姓名和职称信息了（删除异常）。导致这种数据冗余和操作异常的原因在于该关系模式中存在传递函数依赖，这将在2.5.3节举例说明。
2.5.3 第三范式（3NF）
定义2.10 设R(U)是一个关系模式，如果R(U)∈2NF且每个非主属性都不传递函数依赖于任一候选码，则称R(U)属于第三范式，记为R(U)∈3NF。
注意，如果一个关系模式的属性全是主属性，那该关系模式肯定属于第三范式，因为该关系模式不存在非主属性。
【例2.9】假设有一个关于学生选课信息的关系模式——s_c(学号, 课程号, 名次)，其相关语义是：学号和课程号分别是学生和课程的唯一标识属性，每一名学生选修的每门课程有一个名次，且名次不重复。
Ø 其函数依赖包括：{学号, 课程号} → 名次，{课程号, 名次} → 学号。{学号, 课程号}和{课程号, 名次}是此关系的候选码。其所有的属性都是主属性，此关系模式属于第三范式。
l 第三范式是在第二范式的基础上，增加了条件“每个非主属性都不传递函数依赖于任一候选码”而得到的。
【例2.10】假设有一个关于员工信息的关系模式：emp_info(Eno, Ename, Dept, Dleader)。其中，Eno为员工编号，Ename为员工姓名，Dept为员工所在部门，Dleader为部门领导。请说明该关系模式属于第几范式以及它存在的问题。
Ø 员工编号是唯一的，每个员工只属于一个部门，每个部门只有一个领导（这里假设领导不属于员工范畴，且不考虑纵向领导关系）。员工编号（Eno）为唯一的码，由此容易推出：
Eno → Ename
Eno → Dept
Eno → Dleader
Ø 显这些函数依赖都是完全函数依赖。这些函数依赖说明了所有非主属性都完全函数依赖于码Eno，所以关系模式emp_info属于第二范式。但该关系模式还存在下列的函数依赖：
Eno→Dept
Dept→Dleader
Eno→Dleader
l 上述说明非主属性Dleader传递函数依赖于码Eno，即关系模式emp_info中存在传递函数依赖，它不属于第三范式。传递函数依赖的存在同样会导致一定程度的数据冗余以及插入异常和删除异常等问题。这体现在：
Ø 一个部门有多个员工，每一个员工在关系emp_info中都形成一个元组。该元组除了包含员工编号和姓名外，还包含所在部门和部门领导的信息。后两项信息会多次重复出现，重复的次数与部门的员工数相等。这是数据冗余的根源。
Ø 数据冗余的存在导致数据维护成本增加。