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



      在数据库设计的范例使用三时间,我一直认为它是第一个未完成ER画画。然后导出关系模型,否合理,but not!

我们在一開始画ER图的时候。就应当和三范式联系起来,将错误消灭在源头。为了能最早的检验出错误。我们就要对ER图转换成关系模式的算法和三范式是怎样消除冗余,避免冲突有深刻的了解,才干知道怎样最早发现错误。


     本文主要以机房收费系统数据库设计中的一些东西为例,结合三范式概念。简述下三范式。


   


    一,1NF

定义:

假设关系模式R的每一个关系r的属性值都是不可分的原子值,那么称R是第一范式。

 

简单来说。第一范式要求属性不可再分。来看一个比較常见的样例:

比如,在机房收费系统中,比方我们会遇到日期时间是该写成一个属性还是分开写呢?这时候我们就要依据第一范式来做出一个推断了,由于第一范式要求属性值不可再分,所以我们应该这样:




二,2NF

 

定义:

假设关系模式R1NF,且每一个非主属性全然函数依赖于候选键。那么称R是第二范式。

 

要明确第二范式,首先要明确什么是全然函数依赖?

 

全然函数依赖:

RU)中,假设XY,而且对于X的不论什么一个子集x,都有x不成立。则称YX全然函数依赖。

如图,(X1X2Y,而且,X1Y不成立。X2Y不成立。

 

 


 

可是,假设在全然函数依赖中,若XY,但Y不全然函数依赖于X。则称YX部分函数依赖。

 

比如,如图。此时。X1成立,则Y部分依赖于X1X2;

 

 


 

 

综上,我们能够得出,要满足第二范式,就要让每个非主键属性全然依赖于主键。

 

比如。我们在机房收费系统设计数据库的时候,对于学生表可能有过这种设计,最開始的时候,我们为了查询方便,把学生表和卡表这样做:

 


 

可是当我们再次重构数据库的时候。我们就要依据三范式来推断下了。

比如,卡内金额依赖于主键学号和卡号,而卡内金额也依赖于卡号,这里就不满足2NF,我们就要将两张表拆开。

 

 

 

 

三,3NF

 

定义:

R满足1NF。且每一个非主属性都不传递依赖R的候选键,则称实体E时第三范式。

 

 

什么是非主属性传递码?

如图所看到的,为传递函数依赖的示意图:

 



 

比如,

 



 

 

还是上面那张表,我们在这里选的是学号作为主键,则表中有:

学号卡号卡内金额,此时出现了传递依赖。

 

 

分析:

2NF3NF,不管是出现部分依赖还是出现传递依赖,都是要将关系模式进行分解,追究产生错误的根源,感觉还是E-R图没有画好的缘故。

 

 

 

小结:

1NF将属性拆成了原子值。2NF3NF都是为了消除冗余和异常问题;

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

 







  



版权声明:本文博客原创文章,博客,未经同意,不得转载。

你可能感兴趣的:(数据库设计——三范式概念+现实)