课外天地 李树青学习天地数据库系统原理课件 → [推荐]第五部分课堂讲稿——范式分析


  共有18220人关注过本帖树形打印复制链接

主题:[推荐]第五部分课堂讲稿——范式分析

帅哥哟,离线,有人找我吗?
admin
  1楼 博客 | 信息 | 搜索 | 邮箱 | 主页 | UC


加好友 发短信 管理员
等级:管理员 帖子:1938 积分:26572 威望:0 精华:34 注册:2003/12/30 16:34:32
[推荐]第五部分课堂讲稿——范式分析  发帖心情 Post By:2008/2/20 15:09:50 [只看该作者]

     1 简介
     范式理论是Codd研究并用来进行数据建模的方法,实践证明它适用于单个关系的微观分析,宏观分析还是使用后来推出的ER方法为好。
事实上,ER分析的强项也只是在于宏观分析,有时仅仅利用ER方法并不能保证结果一定有效。
     回忆以前的合同例子,有两种分析做法,一种是归纳出合同和货物两个实体,另外一种是归纳出合同、货物和厂商三个实体。前一种方案利用的准则是只要属性对于某个实体的一个实例而言是唯一的,就归入那个实体。后一种方案利用的准则是认为属性只要具有独立存在的意义和可能,就可以新建实体来表达。直接从方案来看,似乎第二种方案的实体更多而显得麻烦,但是从最终生成的关系模型来看,并非如此。如:
     合同(合同号,订货日期,厂商名称,厂商地址)
     只要厂商名称一样,厂商地址一定一样,存在一定的冗余。而第二种方案就没有此类冗余,如:
     合同(合同号,订货日期,厂商号)
     厂商(厂商号,厂商名称,厂商地址)

     范式分析就适合解决此类问题。在ER宏观分析基础之上,利用范式分析最终能够得到最优并且没有冗余的关系模型。

     2 基本概念
     这些基本概念是整个范式分析理论的基础内容。

     2.1 函数依赖(Functional Dependency)
     在关系中,常常存在一种决定和被决定的依赖关系,如非主属性对主属性的依赖关系。作为对应现实世界实体的关系而言,一个关系应该代表一个完整的概念,所以非主属性依赖于主属性是一件基本的要求。
     之所以叫做函数依赖,是因为这种依赖关系非常象函数中因变量依赖自变量的关系。

     2.2 平凡函数依赖与非平凡函数依赖
     属性自己决定自己的依赖关系被称为平凡函数依赖,显然意义不大,所以通常情况下所说的函数依赖都是指非平凡函数依赖。所谓非平凡函数依赖是指一个属性决定其他属性的依赖关系。

     2.3 完全函数依赖与部分函数依赖
     考察下面的关系:
     (学号,所在系,系主任名称,课程名,成绩)
     学号          所在系    系主任名称      课程名    成绩
     000001     计算机    程老师            Java        89
     000001     计算机    程老师            数据库     70
     000002     信息       丁老师            数据库     81
     000003     信息       丁老师            信息检索  90

     说明:
     一个系有若干学生, 一个学生只属于一个系;
     一个系只有一名主任;
     一个学生可以选修多门课程, 每门课程有若干学生选修;
     每个学生所学的每门课程都有一个成绩。

     关系的主键为(学号,课程号),非主属性中只有成绩属性是完全受主键决定的,这种依赖就属于完全函数依赖。而系别表面上受主键决定,但其实只受学号决定,这种依赖就属于部分函数依赖。

     2.4 传递函数依赖
     仍然考察上述关系,其中的系主任名表面上受主键决定,但其实只受所在系决定,而学号决定所在系,所以这种依赖就属于传递函数依赖。

     不论是部分函数依赖还是传递函数依赖,都表现为破坏关系中的内在一致性,事实上,上述数据中系别和系主任名是明显具有冗余的属性,而它们都具有非完全依赖的特点。

     3 范式的使用
     范式(Normal Form)就是规范的形式之意。按照达到的规范程度,可以得到不同的范式级别,如同身体体质达标一样,有不同的标准形成不同的级别。没有达到范式要求的关系被称为范式违例。

     3.1 2NF和3NF
     2NF就是消除了部分函数依赖的范式,3NF就是消除了传递函数依赖的范式。
     消除这些非完全依赖的方法都是一样的,利用拆的方法将现有关系分解为一个个独立而又完整的子关系,以实现完全依赖化。
     具体步骤为:
     1)找出主键属性组。
     2)找出所有的依赖,即包含完全函数依赖,也包含部分函数依赖和传递函数依赖。

     如关系:(学号,所在系,课程名,成绩)
     学号          所在系  课程名          成绩
     000001     计算机  Java              89
     000001     计算机  数据库           70
     000002     信息     数据库           81
     000003     信息     信息检索        90

     主键属性组为:学号,课程名
     完全函数依赖为:学号,课程名-〉成绩
     部分函数依赖为:学号-〉所在系
     上述做法已经形成拆开的关系:
     (学号,课程名,成绩)
     (学号,所在系)
     上述做法消除了部分函数依赖形成2NF。

     再如关系:(学号,所在系,系主任名称)
     学号         所在系  系主任名称
     000001     计算机  程老师
     000001     计算机  程老师
     000002     信息    丁老师
     000003     信息    丁老师

     主键属性组为:学号
     完全函数依赖为:学号-〉所在系
     传递函数依赖为:所在系-〉系主任名称
     上述做法已经形成拆开的关系:
     (学号,所在系)
     (所在系,系主任名称)
     上述做法消除了传递函数依赖形成3NF。

     3.2 BCNF
     不论是2NF还是3NF,都可以纳入BCNF范畴之内。
     BCNF是Boyce和Codd提出的一种涵盖面更广的范式概念。达到BCNF的标准为:任何非平凡函数依赖的左边必须包含键码。从概念上看,上述部分函数依赖和传递函数依赖都不满足BCNF的要求,所以2NF违例和3NF违例一定不是BCNF,BCNF一定是2NF和3NF。上述规范化做法都是BCNF的解决做法。

     3.3 4NF
     上述依赖都属于函数依赖的范畴。函数依赖是属于数据依赖的一个种类,除此以外,数据依赖还包含多值依赖。而BCNF只能做到在函数依赖范围内的最高程度分解,如遇到多值依赖无法解决,如同再好的抗病毒药也不能解决基因产生的疾病。
     如下面的影星信息表明显存在冗余:
     影星名称 所在街道  所在城市     电影名称    拍摄年代
     成龙   123号      香港           城市猎人    1990
     成龙       456号      上海           城市猎人    1990
     成龙       123号      香港           醉拳          1988
     成龙       456号      上海           醉拳          1988
     成龙       123号      香港           我是谁       1995
     成龙       456号      上海           我是谁       1995
     上述冗余产生的原因在于查询的要求,如下面的表格虽然简单,但是没法满足这样的查询“住在香港的影星拍过哪些电影?”
     影星名称   所在街道        所在城市        电影名称        拍摄年代
     成龙        123号             香港              城市猎人        1990
     成龙        123号             香港              醉拳              1988
     成龙        456号             上海              我是谁           1995
     但是,从BCNF的角度来分析,没有问题,因为主键属性居然包含全部的属性,所以不存在部分函数依赖和传递函数依赖等问题。
     造成冗余的原因在于它具有多值依赖,关系中明显将两组没有关系的内容放在一个关系中,即影星住址和影星拍摄的电影。这也需要利用拆的方式将其规范化。
     从上述问题可以看出,作为关系,如果不想出问题,应该尽量保证关系内在的一致性和完整性,主属性完全决定非主属性,而不要把许多本来不属于同一个概念的内容放入一个关系内部,那样做易产生范式违例和数据冗余。

     3.4 1NF
     所谓1NF是对关系模型的基本要求,即一个记录的一个字段只能有一个值。所谓一个值即是指可以将其赋予一个变量,显然多个值无法同时赋予一个变量。
     任何关系模型都要满足此条件,就像空气是人生存的基本条件一样。
     事实上,我们使用的关系型数据库管理系统不可能做出不满足1NF要求的记录。理解此范式的主要内容在于如何处理哪些具有多个值的字段。
     如学生基本情况信息表包括如下字段:
     (学号,姓名,性别,生日,家庭成员)
     对于家庭成员字段而言,从逻辑上看,必须为一个值。虽然用户可能会输入多个值,如“父亲:张XX,母亲:李XX”,但是既然作为一个字段处理,那就代表一个家庭成员的信息。
     如果需要进行个别家庭成员的查询,显然这时从逻辑上看,这个字段就不再是一个值。简单的单字段处理既不方便查询,也难以准确表达多个成员的区别。
     相应的处理方案有两个:
     一是横向扩展,如:
     (学号,姓名,性别,生日,父亲,母亲)
     这种方案较为简单,设计思路是将逻辑上不是整体的字段继续分割为逻辑上为整体的字段。但是存在不易扩展的问题,难以有效表达更多的家庭成员,既便可以表达,冗余也会很多。
     二是纵向扩展,如:
     (学号,姓名,性别,生日)
     (学号,家庭成员类别,姓名)
     这个思路是采用ER分析方法,将其分为学生和家庭成员两个实体,联系为一对多。

     4 范式的定义
     4.1 函数依赖
     4.1.1 定义
     设R(U)是一个属性集U上的关系模式,X和Y是U的子集。若对于R(U)的任意一个可能的关系r,r中不可能存在两个元组在X上的属性值相等,而在Y上的属性值不等, 则称“X函数确定Y”或“Y函数依赖于X”,记作X→Y。

     4.1.2 分解合并原则
     如X→Y1,X→Y2,则X→Y1,Y2
     主要用于规范分析时简化依赖的表达,注意只限于函数依赖的右边。

     4.1.3 转换规则
     如X→Y,Y→Z,则X→Z
     说明了传递函数依赖的存在,注意前提是没有Y→X。

     4.1.4 等价原则
     如X→Y,Y→X,则X和Y等价,记为X←→Y。
     等价属性无需考虑相互之间的依赖关系,如下面的关系:
     学生(学号,姓名,身份证号)
     不存在下述依赖:学号→身份证号,身份证号→姓名

     4.1.5 几个补充
     1)函数依赖是针对所有关系实例而言的,非部分满足。
     2)函数依赖是语义范畴的概念,会因时因地因需求而变化。

     4.2 平凡函数依赖和非平凡函数依赖
     4.2.1 定义
     在关系模式R(U)中,对于U的子集X和Y,如果X→Y,但Y属于X,则称X→Y是平凡的函数依赖。
     若X→Y,但Y不属于X,则称X→Y是非平凡的函数依赖。

     4.2.2 平凡依赖规则
     A1,A2…,An→B1,B2…,Bm等价于A1,A2…,An→C1,C2…,Ck,其中的C是B的子集,但C不包括在A中。
     如下面的函数依赖都是平凡依赖:
     学号→学号,姓名
     学号,课程号→学号,成绩
     皆可以化简为:
     学号→姓名
     学号,课程号→成绩

     4.3 完全函数依赖和部分函数依赖
     4.3.1 定义
     在关系模式R(U)中,如果X→Y,并且对于X的任何一个真子集X’,都没有X’→Y,则称Y完全函数依赖于X,记作X—f→Y(f表示full)。
     若X→Y,但Y不完全函数依赖于X,则称Y部分函数依赖于X,记作X—p→Y(p表示partial)。

     4.3.2 码的定义
     按照完全函数依赖的定义,可以给码下个严格定义:
     设K为关系模式R<U,F>中的属性或属性组合。若K—f→U,则K称为R的一个侯选码(Candidate Key)。
     若关系模式R有多个候选码,则选定其中的一个做为主码(Primary key)。
     如何选择主码是有讲究的,如:
     是选学号还是身份证号?
     是利用流水号还是有意义的字段?

     4.4 传递函数依赖
     在关系模式R(U)中,如果X→Y,Y→Z,且Y不包括在X中,并且没有Y→X,则称Z传递函数依赖于X。
     如果Y→X,即X←→Y,则Z直接依赖于X。
    
     4.5 范式
     4.5.1 1NF
     如果一个关系模式R的所有属性都是不可分的基本数据项,则R∈1NF。
     第一范式是对关系模式的最起码的要求。不满足第一范式的数据库模式不能称为关系数据库。但是满足第一范式的关系模式并不一定是一个好的关系模式。

     4.5.2 2NF
     若关系模式R∈1NF,并且每一个非主属性都完全函数依赖于R的码,则R∈2NF。
     从定义上看,2NF一定是1NF,反之并不一定。

     4.5.3 3NF
     关系模式R<U,F>中若不存在这样的码X、属性组Y及非主属性Z(Z不属于Y), 使得X→Y,Y→Z,但没有Y→X成立,则称R<U,F>∈3NF。
     从定义上看,3NF一定是2NF,因为部分函数依赖也可以理解为传递依赖,它的左边可以视为Y(X→Y),而右边可以视为Z,即如果存在部分函数依赖就不满足3NF定义要求,逆否命题即为3NF一定是2NF。
     反之并不一定,即2NF不一定是3NF。
    
     4.5.4 BCNF
     关系模式R<U,F>∈1NF,如果对于R的每个函数依赖X→Y,若Y不属于X,则X必含有候选码,那么R∈BCNF。
     从定义上看,BCNF一定是3NF和2NF。但是3NF不一定是BCNF,虽然很罕见,如下面的关系:
     Students   Teachers       Courses
     张亮          李玉山          管理学
     张亮          刘卫国          计算机基础
     王海          李玉山          管理学
     王海          魏芳             英语
     罗建军       刘卫国          计算机基础
     说明:
     1)一名教师只能带一门课程
     2)一旦学生选择了一门课程,就确定了一名教师
     相应的函数依赖为:
     Students,Courses→Teachers
     Teachers→Courses
     选择Students,Courses作为主码,Teachers→Courses的存在会破坏BCNF的规定,所以上述关系不是BCNF,但是在Teachers→Courses依赖中没有任何非主属性对码传递依赖和部分依赖,满足3NF的条件。这也说明3NF的“不彻底”性主要表现在可能存在主属性对码的部分依赖和传递依赖。

[此贴子已经被作者于2010-12-11 19:48:14编辑过]

 回到顶部