第三范式

　　每个非关键字列都独立于其他非关键字列，并依赖于关键字，第三范式指数据库中不能存在传递函数依赖关系。
第三范式关系模式R<U，F> 中若不存在这样的码X、属性组Y及非主属性Z（Z ? Y）, 使得X→Y，Y→Z，成立，Y→X不成立，则称R<U，F> ∈ 3NF。
若R∈3NF，则R的每一个非主属性既不部分函数依赖于候选码也不传递函数依赖于候选码。
如果R∈3NF，则R也是2NF。
采用投影分解法将一个2NF的关系分解为多个3NF的关系，可以在一定程度上解决原2NF关系中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。
将一个2NF关系分解为多个3NF的关系后，并不能完全消除关系模式中的各种异常情况和数据冗余。

　　例：如S1（SNO，SNAME，DNO，DNAME，LOCATION） 各属性分别代表学号，姓名，所在系，系名称，系地址。 
关键字SNO决定各个属性。由于是单个关键字，没有部分依赖的问题，肯定是2NF。但这关系肯定有大量的冗余，有关学生所在的几个属性DNO，DNAME，LOCATION将重复存储，插入，删除和修改时也将产生类似以上例的情况。 
原因：关系中存在传递依赖造成的。即SNO -> DNO。 而DNO -> SNO却不存在，DNO -> LOCATION, 因此关键字 SNO 对 LOCATION 函数决定是通过传递依赖 SNO -> LOCATION 实现的。也就是说，SNO不直接决定非主属性LOCATION。 
解决目地：每个关系模式中不能留有传递依赖。 
解决方法：分为两个关系 S（SNO，SNAME，DNO），D（DNO，DNAME，LOCATION） 
注意：关系S中不能没有外关键字DNO。否则两个关系之间失去联系。 
将第一，第二范式化为第三范式的步骤：
（1）求出R的最小函数依赖集Fmin
（2）找出不在Fmin中出现的属性，并将这些属性从R中去掉，构成一个关系模式
（3）若Fmin中有一个函数依赖涉及R的全部属性，则R不能分解
（4）否则，若Fmin中有X->A,则分解应包含{XA};若有X->A1,X->A2....X->An均属于Fmin，则分解应包含{XA1A2...An}