3、第三范式3NF
定义：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合3NF。
我们来看上例中优化后的表3-1
|
StudentNo |
CardNo |
UserID |
UserLevel |
Date |
Time |
|
021101 |
001 |
Operator |
操作员 |
2011/10/03 |
09:00 |
在表中，一个UserID能确定一个UserLevel。这样，UserID依赖于StudentNo和CardNo，而UserLevel又依赖于UserID，这就导致了传递依赖，3NF就是消除这种依赖。
我们把3-1进行优化得到：
4-1
|
StudentNo |
CardNo |
UserID |
Date |
Time |
|
021101 |
001 |
Operator |
2011/10/03 |
09:00 |
4-2
|
UserID |
UserLevel |
|
Operator |
操作员 |
我们看到，第三范式规则查找以消除没有直接依赖于第一范式和第二范式形成的表的主键的属性。我们为没有与表的主键关联的所有信息建立了一张新表。每张新表保存了来自源表的信息和它们所依赖的主键。
------------------
3．第三范式(确保每列都和主键列直接相关,而不是间接相关)
第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。
比如在设计一个订单数据表的时候，可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息（比如姓名、所属公司等）的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表。
这样在查询订单信息的时候，就可以使用客户编号来引用客户信息表中的记录，也不必在订单信息表中多次输入客户信息的内容，减小了数据冗余。
----------------
第三范式
数据不能存在传递关系，即没个属性都跟主键有直接关系而不是间接关系。像：a-->b-->c 属性之间含有这样的关系，是不符合第三范式的。
比如Student表（学号，姓名，年龄，性别，所在院校，院校地址，院校电话）
这样一个表结构，就存在上述关系。 学号--> 所在院校 --> (院校地址，院校电话)
这样的表结构，我们应该拆开来，如下。
（学号，姓名，年龄，性别，所在院校）--（所在院校，院校地址，院校电话）
三、总结
数据库设计规范化能让我们更好地适应变化，使你能够改变业务规则、需求和数据而不需要重新构造整个系统。