在数据库设计的范例使用三时间，我一直认为它是第一个未完成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都是为了消除冗余和异常问题；
所以，三范式有两个作用：一是能够衡量一个数据库的好坏。二是能够作为数据库设计的一个基本原则。
版权声明：本文博客原创文章，博客，未经同意，不得转载。