wghbeyond / ORACLE设计 / 数据库三大范式的理解

0 0

   

数据库三大范式的理解

2012-07-12  wghbeyond

一: 引言

       作为一个数据库的学习者,搞懂关系数据库的三大范式是很有用的。然而教科书上有关数据库范式的介绍都是采用学术性的定义,语法羞涩,让人难懂,故写下自己对数据库范式的理解,给初学者提供帮助,也备日后查看。

       本文不介绍规范化程度高于3NF的范式,因为其在实际应用中基本不会用到,原因也是很明显的(查询代价变大),因此,对于很多大型复杂的系统,其数据库设计都没有遵循所谓的范式,这也是为什么会出现所谓的逆规范化,好了,进入正题吧。

 

二: 范式介绍

    a:第零范式

         第零范式就是指没有使用任何范式的设计,其添加数据的行为非常诡异,看看下表便知:

         假设一个学生学习了三门课程,每门课程都有成绩,那么,采用第零范式的设计将会是如下情况                          

                           表a_0

         这样的话,会使得往表中添加数据变得非常麻烦,每次添加一个新的数据,都要添加相应的字段,而且,因为表中其他的记录可能不需要这么多字段,因此会浪费

         很多空间。如表a_1所示。

                       表a_1

         由此可以看出,不对数据库任用任何范式是非常愚蠢的,因为不仅会产生大量无用的表字段,而且会使得表结构非常难以维护。由此,引出第一范式的介绍

    b:  第一范式

         第一范式就是在第零范式的基础上进行的改进,网上有很多人认为,所谓第一范式就是指表中的所有字段都是原子的、不可再分的,我个人认为此种理解也是正确的,原因不解释,我对第一范式的理解是,将

     第零范式中重复的字段抽取出来,作为表的数据,从而形成一个稳定的、冗余数据少得表结构。

        由此,可以得出符合第一范式的表结构应该是:

 

        此时,表的结构变得稳定了,而且表中的冗余信息相对第零范式也少了很多。可是,第一范式只是关系数据库设计的最低满足的范式,第一范式中仍然有很多的冗余信息,由此,需要引入第二范     式。

 

    c: 第二范式

         第二范式是满足属性对主键是完全函数依赖的,因此,满足第二范式的表当然也是满足第一范式的,第二范式的目的就是消除表中的部分依赖。

         这里,有几个概念要解释下, 

              1: 完全函数依赖

                   设有属性集K和P,若K中的所有属性共同能够推出P中的任意属性,且对于K的任何真子集,都不能推出P中的任意属性,则成K完全函数依赖P。

              2: 部分函数依赖

                   与上相似,只是,K中存在真子集使得,该子集能推出p中任意属性。

         概念性的东西,往往都难懂,举个例子,方便大家理解:

         假如有一张学生成绩表,包含如下属性(学生Id,课程Id,课程分数,学生名字),其中,主键为(学生id,课程id),表中的数据如下:

 

         那么,此时这张表的设计就不满足第二范式, 因为 主键(学生id,课程id) 能够唯一确定学生的姓名,因此,不满足属性完全函数依赖主键,因此不是第二范式。

         从上面的表数据易知,不满足第二范式的表至少有以下几个缺点:

             1:数据重复,浪费空间,因为每存一条记录,都要存学生的名字,这样就是得存在大量重复的数据。

             2: 插入异常,若学生还没有成绩,那么这个学生就没有名字。

             3:  更新异常,删除异常等

        解决方法:

             将student_name字段放入学生表中,即消除表中的部分依赖。

   d: 第三范式

       第三范式是指在满足第二范式的情况下,消除表中的传递依赖。

       所谓传递依赖,就是指x-->y,y-->z,那么可以得到y-->z.

       传递依赖常发生在主键、外键、外键相关的属性上,例如,假设有这样的表

               学生表(学生id,学生姓名,院系id,院系名)  ,此处主键为(学生id),外键为(院系id)

               院系表(院系id,院长名称),主键为 (院系id)

       很明显,此处存在传递依赖,因为 学生id  可以唯一确定  院系id,而 院系id 可以唯一确定 院系名。

       表中的数据如下

         



       从上面的表数据易知,不满足第三范式的表至少有以下几个缺点:

            1 :  数据重复,浪费空间,因为学生表每存一条记录,都会记录住院系的名字,存在大量的重复数据。

            2:  插入异常,若新建一个院系,而该院系没有学生的话,该院系就没有名字。

            3:  更新异常,删除异常等                 



三: 数据库设计的经验

       1: 表的数目不要太多,一般20-30张就够了。如果表的数目太多,则可以考虑采用同化操作,即将大体相同的实体放入到一张表中。

       2:当数据库中的信息非常庞大时,不要使用外键(逆规范化),因为由此可能带来非常大的性能损失。

       3:一般以消耗存储空间来换取效率。

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。如发现有害或侵权内容,请点击这里 或 拨打24小时举报电话:4000070609 与我们联系。

    猜你喜欢

    0条评论

    发表

    请遵守用户 评论公约

    类似文章
    喜欢该文的人也喜欢 更多