3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。也就是说， 如果存在非主属性对于码的传递函数依赖，则不符合3NF的要求。
第三范式和第二范式不同的地方在于，在第三范式里，所有的非键属性都必须和每个候选键有直接相关。
例如对下表则不符合3NF
| StuNo | Name | Sex | bounsLevel | bouns |
|---|---|---|---|---|
| 1308200047 | Airing | 男 | 优 | 2000 |
| 1308200048 | Bob | 男 | 良 | 800 |
这个完全满足了第二范式,但是bounsLevel和bouns存在传递依赖。
所以该表应该拆分成以下两个表。
| StuNo | Name | Sex | bounsNo |
|---|---|---|---|
| 1308200047 | Airing | 男 | 1 |
| 1308200048 | Bob | 男 | 2 |
| bounsNo | bounsLevel | bouns |
|---|---|---|
| 1 | 优 | 2000 |
| 2 | 良 | 800 |
先前那个数据表的问题在于每提到一次bounsLevel就要多存一次它的bouns，而这就不符合第三范式的原则
下面提供了另一个例子：
| 订单编号(Order Number) | 客户名称 (Customer Name) | 单价(Unit Price) | 数量 (Quantity) | 小计(Total) |
|---|---|---|---|---|
| 1 | Airing | 20.00 | 3 | 60.00 |
| 2 | Bob | 10.00 | 2 | 20.00 |
在本例中，非主键字段完全依赖于主键订单编号,也就是说唯一的订单编号能导出唯一非主键字段值，符合第二范式。第三范式要求非主键字段之间不能有依赖关系，显然本例中小计依赖于非主键字段单价和数量，不符合第三范式。小计不应该放在这个数据表里面，只要把单价乘上数量就可以得到小计了；如果想要符合第三范式的话，就把小计拿掉吧。
不过在做查询的时候，本来用
SELECT Order.Total FROM Order就要改成用
SELECT UnitPrice * Quantity FROM Order| 订单编号(Order Number) | 客户名称 (Customer Name) | 单价(Unit Price) | 数量 (Quantity) |
|---|---|---|---|
| 1 | Airing | 20.00 | 3 |
| 2 | Bob | 10.00 | 2 |
问：范式的存在有什么好处？
范式可以避免数据冗余，减少数据库的空间，减轻维护数据完整性的麻烦。
其实到了3NF，基本上就已经消除了数据冗余以及插入异常，删除异常，修改异常的问题。不过，如上例，订单表中，在执行SQL语句的时候就要多计算一步，或者上上例的学生表中，如果想得到学生的奖金就需要查两张表。如果在需要查询数据量特别大或者是经常性需要得到这些数据的时候，那么就可以适当的反范式化，稍微放松一点3NF的要求，达到以空间换时间的目的。
按照范式的规范设计出来的表，等级越高的范式设计出来的表越多。如第一范式可能设计出来的表可能只有一张表而已，再按照第二范式去设计这张表时就可能出来两张或更多张表，如果再按第三范式或更高的范式去设计这张表会出现更多比第二范式多的表。表的数量越多，当我们去查询一些数据，必然要去多表中去查询数据，这样查询的时间要比在一张表中查询中所用的时间要高很多。
也就是说我们所用的范式越高，对数据操作的性能越低。所以我们在利用范式设计表的时候，要根据具体的需求再去权衡是否使用更高范式去设计表。在一般的项目中，我们用的最多也就是第三范式，第三范式也就可以满足我们的项目需求，性能好而且方便管理数据。
当我们的业务所涉及的表非常多，经常会有多表发生关系，并且我们对表的操作要时间上要尽量的快，这时可以考虑我们使用“反范式”。反范式，故名思义，跟范式所要求的正好相反，在反范式的设计模式，我们可以允许适当的数据的冗余，用这个冗余去取操作数据时间的缩短。也就是用空间来换取时间，把数据冗余在多个表中，当查询时可以减少或者是避免表之间的关联。
在数据库中，读写效率大概是1：3到1：4之间，所以控制好反范式化的比例对优化数据库尤其重要。
当我们开始着手一个项目后，范式的应用是这样的变化的：
第三范式数据库的设计—–>当数据量越来越大，达到百万级时，经常要对一些多表数据进行大范围高频率进行操作——->范式数据库的设计———->网站的数据量再持续增长———->范式和反范式的数据库设计
参考资料：