在利用三范式设计数据库的时候，以前总以为是先画完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都是为了消除冗余和异常问题；

所以，三范式有两个作用：一是可以衡量一个数据库的好坏；二是可以作为数据库设计的一个基本原则。