对应于第三范式的定义是翻译成程序猿更易理解的话：一个表中的所有的非主键字段都不传递依赖于主键字段。

举个栗子：

　　学生表的设计：student(sno, sname, dno, dname, dlocation)（学号，学生姓名，系名，系地址），其中 sno->dno->dname->dlocation，所以就不符合第三范式。官方的说明是：但这关系肯定有大量的冗余，有关学生所在的几个属性DNO，DNAME，LOCATION将重复存储，插入，删除和修改时也将产生类似以上例的情况。所以就拆成两个表，student(sno, sname, dno) department(dno, dname, dlocation)

　　但是我觉得现在存储设备这么便宜的环境下，数据冗余应该不是考虑的。那要查询的时候就得连表了，这样是不是又会导致新的损耗呢？这是我不能理解的。为什么就不能将这两个表中的字段合合在一张表里面那么查询的时候就根据一个主键就将所有的信息全部查出来了。

 　　如果俩表合为一表。在插入更新时，就会导致冗余的字段插入，这也是对网络资源的一种损耗。也是不得不考虑的。但是如果把这种表就是专门作为查询用的，那不使用第一范式，而是使用第二范式，那是不是在实际的业务领域能够快速得到响应呢，这也是我的疑惑。

　　ps：工作刚满一年，上班时无聊想到的，第一篇博文，希望没有贻笑大方，希望得到各位指点。谢谢

对于数据库的三大范式的疑惑