在利用三范式设计数据库的时候，以前总以为是先画完ER图，然后导出关系模式，最后用三范式去检验数据库设计的是否合理，but not！我们在一开始画ER图的时候，就应当和三范式联系起来，将错误消灭在源头。为了能最早的检验出错误，我们就要对ER图转换成关系模式的算法和三范式是如何消除冗余，避免冲突有深刻的了解，才能知道如何最早发现错误。
本文主要以机房收费系统数据库设计中的一些东西为例，结合三范式概念，简述下三范式。
一，1NF
定义:
如果关系模式R的每个关系r的属性值都是不可分的原子值，那么称R是第一范式。
简单来说，第一范式要求属性不可再分，来看一个比较常见的例子：
例如，在机房收费系统中，比如我们会遇到日期时间是该写成一个属性还是分开写呢？这时候我们就要根据第一范式来做出一个判断了，因为第一范式要求属性值不可再分，所以我们应该这样：
二，2NF
定义：
如果关系模式R是1NF，且每个非主属性完全函数依赖于候选键，那么称R是第二范式。
要明白第二范式，首先要明白什么是完全函数依赖？
完全函数依赖：
在R（U）中，如果X→Y，并且对于X的任何一个子集x,都有x→不成立，则称Y对X完全函数依赖。
如图，（X1，X2）→Y,并且，X1→Y不成立，X2→Y不成立。
但是，如果在完全函数依赖中，若X→Y，但Y不完全函数依赖于X，则称Y对X部分函数依赖。
例如，如图，此时，X1→成立，则Y部分依赖于X1X2;
综上，我们可以得出，要满足第二范式，就要让每一个非主键属性完全依赖于主键。
例如，我们在机房收费系统设计数据库的时候，对于学生表可能有过这样的设计，最开始的时候，我们为了查询方便，把学生表和卡表这样做：
但是当我们再次重构数据库的时候，我们就要根据三范式来判断下了。例如，卡内金额依赖于主键学号和卡号，而卡内金额也依赖于卡号，这里就不满足2NF了,我们就要将两张表拆开。
三，3NF
定义:
R满足1NF，且每个非主属性都不传递依赖R的候选键，则称实体E时第三范式。
什么是非主属性传递码？
如图所示，为传递函数依赖的示意图：
例如，
还是上面那张表，我们在这里选的是学号作为主键，则表中有：
学号→卡号→卡内金额，此时出现了传递依赖。
分析：
2NF和3NF，无论是出现部分依赖还是出现传递依赖，都是要将关系模式进行分解，追究产生错误的根源，感觉还是E-R图没有画好的缘故。
小结：
1NF将属性拆成了原子值；2NF和3NF都是为了消除冗余和异常问题；
所以，三范式有两个作用：一是可以衡量一个数据库的好坏；二是可以作为数据库设计的一个基本原则。
