第三范式
从上面的例子来看，通过第二范式的改造，之前提到的问题已经得到了解决。那么为什么又要有第三范式呢？首先我们来看一个满足第二范式但是仍然存在前面问题的例子。
这个关系模式的主键是图书名，显然它满足第一范式。因为主键只有一个字段，非主属性对于所有主属性一定是完全函数依赖，所以它也满足第二范式。但是如果在给这张表增加一本人民邮电出版社出版的《深入理解 MySQL》，我们就会发现出版商的地址会存在冗余！为了消除这种冗余，第三范式就被提出来了。
第三范式需要满足以下两点：
- 满足第二范式
- 非主属性对于主码不存在传递函数依赖
什么是传递函数依赖呢？这里不给形式化的定义，而以前面的例子来解释。前面的例子中因为图书名是主键，所以函数(图书名) -> (出版商)是成立的。同时我们知道出版商的地址是确定的，所以函数(出版商) -> (出版商地址)也是成立的。所以就有(图书名) -> (出版商) -> (出版商地址)成立。这个时候我们也称出版商地址函数依赖于图书名。
为了消除非主属性对于主码的传递函数依赖，我们将上面的表拆分为两个表：
