数据库设计——三范式概念+现实

在数据库设计的范例使用三时间，我一直认为它是第一个未完成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都是为了消除冗余和异常问题；

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