精华内容
下载资源
问答
  • 关系数据库设计流程

    千次阅读 2018-03-11 10:28:23
    在需求分析设计阶段形成需求说明书,概念设计阶段形成概念数据模型(作为进一步设计数据库的依据),逻辑设计阶段形成逻辑数据模型(从 ER 图向关系模式转换、关系视图设计模式规范化),物理设计阶段形成数据库...

    关系数据库设计有需求分析设计、概念设计、逻辑设计、物理设计、编码、测试、运行、进一步修改等几个阶段。在需求分析设计阶段形成需求说明书,概念设计阶段形成概念数据模型(作为进一步设计数据库的依据),逻辑设计阶段形成逻辑数据模型(从 ER 图向关系模式转换、关系视图设计、模式规范化),物理设计阶段形成数据库内部模型(此时涉及具体软件硬件环境)。

    展开全文
  • 函数依赖 闭包 自反 增广 传递 范式 关系模式的分解来不及解释了,快上车!!~~~函数依赖1.函数依赖(FD)是关系模式内最常见的数据依赖,属于语义范畴的概念 2. 函数依赖定义为:设R(U)是属性集U上的关系模式。X,Y...

    函数依赖 闭包 自反 增广 传递 范式 关系模式的分解

    来不及解释了,快上车!!~~~

    函数依赖

    1.函数依赖(FD)是关系模式内最常见的数据依赖,属于语义范畴的概念
    2. 函数依赖定义为:设R(U)是属性集U上的关系模式。X,Y是U的子集,若对于R(U)的任意一个可能的关系r,r中不可能存在两个元组在X上的属性值相等,而在Y上的属性值不等,则成X函数确定Y或者Y函数依赖与X, 记作:X→Y。
    3. 平凡的函数依赖:如果X→Y,但Y∈X,则称X→Y是平凡的函数依赖
    4. 非平凡的函数依赖:如果X→Y,但Y∉X,则称X→Y是非平凡的函数依赖。通常情况下总是讨论非平凡的函数依赖
    5. 完全函数依赖:在R(U)中,如果X→Y,并且对于x的任何一个真子集X’,都有X´不能决定Y,则称Y对X完全函数依赖,记作:X-f->Y (f即 full)
    6. 部分函数依赖:在R(U)中,如果X→Y,但Y不完全函数依赖于X,则称Y对X部分函数依赖,记作:X-p->Y (p即part) 部分函数依赖也称为局部函数依赖
    7. 传递依赖:在R(U,F)中,如果X→Y,Y∉X,Y→Z,Y不完全函数依赖于X,则称Z对X传递依赖
    8. 候选码:设K为R(U,F)中属性的组合,若K-f->U,且对于K的任何一个真子集K’,都有K’不能决定U,则K为R的候选码(候选关键字)。若有多个候选码,则选其中一个座位主码(主键),包含在任何一个候选码中的属性称之为主属性,反之称之为非主属性

    函数依赖的逻辑蕴涵

    定义:设有关系模式R(U)及其函数依赖集F,如果对于R的任一个满足F的关系r函数依赖X→Y都成立,则称F逻辑蕴涵X→Y,或称X→Y可以由F推出。

    例:关系模式 R=(A,B,C),函数依赖集F={A→B,B→C}, F逻辑蕴涵A→C。
    证:设u,v为r中任意两个元组:
    若A→C不成立,则有u[A]=v[A],而u[C]≠v[C]
    而且A→B, B→C,知
    u[A]=v[A], u[B]=v[B], u[C]=v[C],
    即若u[A]=v[A]则u[C]=v[C],和假设矛盾。
    故F逻辑蕴涵A→C。
    满足F依赖集的所有元组都函数依赖X→Y(X→Y不属于F集),则称F逻辑蕴涵X→Y
    (X→Y由F依赖集中所有依赖关系推断而出)

    Armstrong公理

    1、定理:若U为关系模式R的属性全集,F为U上的一组函数依赖,设X、Y、Z、W均为R的子集,对R(U,F)有:
    F1(自反性):若X≥Y(表X包含Y),则X→Y为F所蕴涵;(F1’:X→X)
    F2(增广性): 若X→Y为F所蕴涵,则XZ→YZ为F所蕴涵;(F2’:XZ→Y)
    F3(传递性): 若X→Y,Y→Z为F所蕴涵,则X→Z为F所蕴涵;
    F4(伪增性):若X→Y,W≥Z(表W包含Z)为F所蕴涵,则XW→YZ为F所蕴涵;
    F5(伪传性): 若X→Y,YW→Z为F所蕴涵, 则XW→Z为F所蕴涵;
    F6(合成性): 若X→Y,X→Z为F所蕴涵,则X→YZ为F所蕴涵;
    F7(分解性): 若X→Y,Z≤Y (表Z包含于Y)为F所蕴涵,则X→Z为F所蕴涵。
    函数依赖推理规则F1∽F7都是正确的。

    2、Armstrong公理:
    推理规则F1、F2、F3合称Armstrong公理;
    F4 ∽ F7可由F1、F2、F3推得,是Armstrong公理的推论部分。

    函数依赖的闭包

     
    定义:若F为关系模式R(U)的函数依赖集,我们把F以及所有被F逻辑蕴涵的函数依赖的集合称为F的闭包,记为F+。
    即:F+={X→Y|X→Y∈F∨“应用Armstong公理从F中导出的任何X→Y”}

     △ F包含于F+,如果F=F+,则F为函数依赖的一个完备集。
     △ 规定:若X为U的子集,X→Φ 属于F+。
    
      例:R=ABC,F={A→B, B→C}, 求F+
      解: F+ ={A→Φ,AB→Φ,AC→Φ,ABC→Φ,B→Φ,C→Φ,
                A→A,AB→A,AC→A,ABC→A,B→B,C→C,
                A→B,AB→B,AC→B,ABC→B,B→C,
                A→C,AB→C,AC→C,ABC→C,B→BC,
                A→AB,AB→AB,AC→AB,ABC→AB,BC→Φ,
                A→AC,AB→AC,AC→AC,ABC→AC,BC→B,
                A→BC,AB→BC,AC→BC,ABC→BC,BC→C,
                A→ABC,AB→ABC,AC→ABC,ABC→A,BC→BC}
    
       例:已知关系模式R中
           U={A,B,C,D, E, G},
           F={AB→C, C→A, BC→D, ACD→B, D→EG, BE→C, CG→BD, CE→AG},判断BD→AC是否属于F+
    
       解:由D→EG知D→E,BD→BE             … ①
           又知BE→C,C→A 所以BE→A, BE→AC … ②
           由①、②知,BD→AC,所以BD→AC被F所蕴涵,即BD→AC属于F+
    
       例:已知关系模式R中
           U={A,B,C,E, H, P, G},
           F={AC→PE, PG→A, B→CE, A→P, GA→B, GC→A, PAB→G, AE→GB, ABCP→H},证明BG→HE属于F+
        证:由B→CE知B→C,B→E, BG→GC         … ①
            又知GC→A,A→P 所以BG→A, BG→ABCP … ②
            又ABCP→H,由①、②知BG→HE,所以BG→HE被F所蕴涵,
            即BG→HE属于F+
    

    属性集闭包

     
    1、定义:若F为关系模式R(U)的函数依赖集,X是U的子集,则由Armstrong公理推导出的所有X→Ai所形成的属性集

    例:设R=ABC,F={A→B, B→C}当X分别为A,B,C是求X+。
    解:当X=A时,X+=ABC
    当X=B时,X+=BC
    当X=C时,X+=C
    * X代表的属性集可以决定的属性集(包括本身)

    2、定理:当且仅当Y属于X+时,X→Y能根据Armstron公理由F导出。
    证:设Y=A1,A2,…,An
    ①充分条件:当Y属于X+时,对于每个i,X→Ai可由公理导出。
    再用合并规则可得X→Y。
    ②必要条件:若X→Y能够由公理导出,则根据分解规,
    X→Ai(i=1,2,…,n)成立,所以Y属于X+。

    3、计算X+
    (1)算法依据:若F为关系模式R(U)的函数依赖集,X,Z,W是U的子集,对于任意的Z→W∈F,若 X≥Z(表X包含Z),则X→XW。

    (2)算法:
    a.令X+ = X;
    b.在F中依次查找每个没有被标记的函数依赖,若“左边属性集”包含于X+ ,则令 X+ = X+∪“右边属性集”,为被访问过的函数依赖设置访问标记。
    c.反复执行b直到X+不改变为止。
    (先令X+等于本身,然后在F+中依次查找左边包含于X+的属性,把其右边的对应属性并到X中)

    (3)算法实现
    输入:关系模式R的子集X,R上的函数依赖集F。
    输出:X关于F的闭包X+

    算法伪语言描述:
    Closure(X,F)
    {
    olds=Φ; news=X; G=F;
    while (olds!=news)
    {
    olds=news;
    for (G中的每个函数依赖W→Z)
    {
    if (news包含W)
    {
    news=news∪Z;
    从G中删除函数依赖W→Z;
    }
    }
    }
    return news;
    }

    例:已知关系模式R中
    U={A,B,C,D, E, G},
    F={AB→C, C→A, BC→D, ACD→B, D→EG, BE→C, CG→BD, CE→AG},
    求(BD)+,判断BD→AC是否属于F+
    解:X+=BDEGCA
    结论:(BD)+=ABCDEG,BD→AC可由F导出,即BD→AC属于F+

    例:已知关系模式R中
    U={A,B,C,E, H, P, G},
    F={AC→PE, PG→A, B→CE, A→P, GA→B,GC→A, PAB→G, AE→GB, ABCP→H},
    证明BG→HE属于F+
    证:因为,(BG)+ =ABCEHPG,
    所以BG→HE可由F导出,即BG→HE属于F+

    4、结论
    判定函数依赖X→Y是否能由F导出的问题,可转化为求X+并判定Y是否是X+子集的问题。
    即求闭包问题可转化为求属性集问题。
    判定给定函数依赖X→Y是否蕴涵于函数依赖集F算法实现:

    输入:函数依赖集合F,函数依赖X→Y
    输出:若X→Y∈F+输出真,否则输出假

    算法伪语言描述:
    number(F,X→Y)
    { if (Y包含于close(X,F))
    return 真
    else
    return 假
    }

    {Ai|i=1,2,…}称为X对于F的闭包,记为X+。

    关系模式的分解

    1. 关系模式的分解有几个不同的衡量标准:①分解具有无损连接;②分解要保持函数依赖;③分解既要保持函数依赖,又要具有无损连接
    2. 无损连接性判定定理:关系模式R分解为两个关系模式R1和R2,满足无损连接性的充分条件是R1∩R2→(R1-R2)或R1∩R2→(R2-R1)
    3. 保持函数依赖的定义是:若满足(F1∪F2)+=F+,则分解保持函数依赖,其中Fi函数依赖集F在Ri上的投影
    4. 在泛关系模式R分解成数据库模式ρ={R1,R2…Rk}时,泛关系r在ρ的每一模式Ri(1≤i≤n)上投影后再连接起来,比原来r中多出来的元组,称为“寄生元组”或外元组。实际上,寄生元组表示错误的信息
    5. 先存在r(泛关系)的情况下,再去谈论分解,这是关系数据库理论中著名的泛关系假设
      在无泛关系假设时,对两个关系进行自然连接中被丢失的元组称为悬挂元组
    6. 悬挂元组是造成两个关系不存在泛关系的原因
    7. 模式分解的优点:①能消除数据冗余和操作异常的现象;②在分解了的数据库中可以存储悬挂元组,存储泛关系中无法存储的信息
    8. 模式分解的缺点:①分解以后,检索操作需要做笛卡尔积或链接操作,这将付出时间代价;②在有泛关系假设时,对数据库中的关系进行自然连接时,可能产生寄生元组(即损失了信息);在无泛关系假设时,由于数据库可能存在悬挂元组,因此有可能不存在泛关系
    9. 无损分解的测试方法。①输入:关系模式R=(A1,A2…An),F是R上成立的函数依赖集,ρ={R1,R2…Rn}是R的一个分解;②输出:判断ρ相对于F是否具有无损分解特性。无损分解的测试算法如下:

            1.构造一张k行n列的表格,每列对应一个属性Aj(1≤j≤n),每行对应一个模式Rj(1≤i≤k)。如果Aj在Ri中,那么在表格的第i行第j列处填上符号aj,否则填上bij。
            2.把表格看成模式R的一个关系,反复检查F中每个FD在表格中是否成立,若不成立,则修改表格中的值,修改方法为:对于F中一个函数依赖X→Y,如果表格中有两行在X值上相等,在Y值上不相等,那么把这两行在Y值上也改成相等的值,如果Y值中一个是aj,那么另一个也改成aj;如果没有aj那么用其中一个bij替换另一个字(尽量把下表ij改成较小的数)。一直到表格不能修改为止,这个过程成为chase(追踪)过程
            3.若修改后的最后一直表格中有一方全是a,即a1,a2...an,则称ρ相对于F是无损分解,否则称为损失分解
    

    10.如果某个分解能保持FD集,那么在数据输入或更新时,只要每个关系模式本身的FD约束被满足,就可以确保整个数据库中数据的语义完整性不受破坏
    11.关系模式在分解时应保持等价,有数据等价和依赖等价两种,分别用无损分解和保持依赖两个特征来衡量。
    12.数据等价是指两个数据库实例赢表示同样的信息内容。如果是无损分解,那么对泛关系反复的投影和连接都不会丢失信息
    13.依赖等价是指两个数据库模式应有相同的依赖集闭包,在依赖集闭包相等的情况下,数据的语义是不会出差错的

    范式

    a.范式是衡量关系模式优劣的标准,它表达了模式中数据依赖之间应满足的联系
    b.第一范式(1NF):若关系模式R的每一个分量是不可分的数据项,则R∈1NF
    c.2NF:若R∈1NF,且每一个非主属性完全函数依赖于码,则R属于2NF。换言之,当1NF消除了非主属性对码的部分函数依赖时,则称为2NF。典型有:捐赠信息(捐赠编号。捐赠校友,捐赠时间,受益人身份证号,受益人姓名),其中捐赠编号和受益人身份证号是主键,但是存在” 捐赠编号→捐赠校友,捐赠时间“和”受益人身份证号→受益人姓名“的部分依赖,所以这个不是2NF
    d.3NF:若R∈2NF,且每一个非主属性既不部分依赖于码,也不传递依赖于码,则R∈3NF。换言之:当2NF消除了非主属性对码的部分函数传递时,称为3NF。典型有:校友信息(校友编号,姓名,工作单位,职位,院系,班级,入学年份,身份证号)班级为班级编号,包含院系编号,入学年份和专业方向编号。可以知道 校友编号应该是主键,同时身份证号也是该关系模式的决定性因素,因此他们都是候选键。由“班级→入学年份 ”和“校友编号→班级”,出现了“ 校友编号→入学年份”,虽然每一个非主属性不部分依赖与码,但是传递依赖与码了,因此这不是3NF
    e.BCNF:关系模式R∈1NF,若X→Y且Y∉X时,X必含码,则R属于BCNF。换言之,当3NF消除了主属性对码的部分和传递函数依赖时,则称为BCNF。注意:BCNF是3NF消除主属性的部分和传递函数依赖,2NF 1NF晋级是消除非主属性的依赖
    他们之间的相互关系是:1NF⊃2NF⊃3NF⊃BCNF
    f.BCNF的关系模式都具有如下3个性质


    1.所有非主属性都完全函数依赖于每个候选码
    2.所有主属性都完全函数依赖于每个不包含于他的候选码
    3.没有任何属性完全函数依赖于非码的任何一组属性
    4.多值依赖MVD:设R(U)施属性集U上的一个关系模式,X,Y是U的子集,若对R(U)的任一关系r,对于X的一个给定的值存在着Y的一组值与其对应,同时Y的这组值又不以任何方式与U-X-Y中的属性相关,那么称Y多值依赖于X,记为X→→Y
    

    e.4NF:关系模式R∈1NF,若对于R的每个非平凡多值依赖X→→Y且Y∉X时,X必含码,则R∈4NF
    对于4NF关系进行投影,消除原关系中不是由候选码所蕴含的函数依赖,即可得到一组5NF关系,5NF是最终范

    g.规范化理论提供了一套完整的模式分解算法,按照这套算法可以做到:


    1.若要求分解具有无损连接性,那么模式分解一定能够达到4NF
    2.若要求分解保持函数依赖,那么模式分解一定能够达到3NF,但不一定能够达到BCNF
    3.若要求分解即具有无损连接性,又保持函数依赖,则模式分解一定能够达到3NF,但不一定能够达到BCNF。
    

    h.模式设计方法的原则:关系模式R相对于函数依赖集F分解成数据库模式ρ={R1,R2,..Rn},一般应具有以下特性。


    ρ中每个关系模式Ri是3NF或BCNF
    保持无损连接
    保持函数依赖集F
    ρ中模式个数最少和属性总数最少
    

    i.一个好的模式设计方法应符合3条原则:表达性、分离性和最小冗余性
    j.表达性设计两个数据库模式的等价性问题,即数据等价和依赖等价,分别用无损连接和保持函数依赖性来衡量
    k.分离性是指属性间的”独立联系“;应该用不同的关系模式表达
    l.最小冗余性要求在分解后的数据库,能表达原来数据库的所有信息这个前提下实现
    关系模式设计方法基本上可以分为分解与合成两大类。

    选自:

    函数依赖与关系模式分解的一些技巧整理

    函数闭包

    展开全文
  • 框架:软件框架是项目软件开发...设计模式:是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结,它强调的是一个设计问题的解决方法。 首先来说说MVC设计模型:1.定义:MVC 设计模型是一种使用 M...

    框架:软件框架是项目软件开发过程中提取特定领域软件的共性部分形成的体系结构,不同领域的软件项目有着不同的框架类型。框架不是现成可用的应用系统。而是一个半成品,提供了诸多服务,开发人员进行二次开发,实现具体功能的应用系统。

    设计模式:是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结,它强调的是一个设计问题的解决方法。

     

    首先来说说MVC设计模型

    1.定义:MVC 设计模型一种使用 Model View Controller( 模型-视图-控制器)设计创建 Web 应用程序的模式。由上主谓宾可以很容易看出,mvc模型是一种用来写web应用程序的样式,也就是说只能写web不能写其它?

    2.既然使用了 Model View Controller( 模型-视图-控制器),那么就很有必要来介绍一下该(模型-视图-控制器)到底是怎样的一个东西?

    Model(模型):是应用程序中用于处理应用程序数据逻辑的部分。

        通常模型对象负责在数据库中存取数据

     

    View(视图):是应用程序中处理数据显示的部分。
        通常视图是依据模型数据创建的。

     

    Controller(控制器):是应用程序中处理用户交互的部分。
        通常控制器负责从视图读取数据,控制用户输入,并向模型发送数据

     

    再来说说MVC框架

    1.MVC框架,它强制性的使应用程序输入、处理和输出分开。使用MVC应用程序被分成三个核心部件:模型、视图、控制器。它们各自处理自己的任务。

      由上可知,要使用MVC框架,则一定要遵守该框架的规则,它有它的强制性所在。聪明的读者一看就知道,它所使用的三个核心部件其实都是来自MVC模型。

      只不过在框架中让他们彼此更加独立了去处理各自的任务而已。

    2.最典型的MVC框架就是Spring MVC和 Struts2

     

    设计模型和框架的区别:(注意这里首先讨论的是总概念!)

    框架是代码重用,所以我们在使用框架的时候总是引入很多包。

    框架是软件,而设计模式是软件的“知识”。所以模式是框架的基础。

     

    MVC设计模式更像设计师手中的图纸(图纸上的东西往往更抽象),而MVC框架则更像是工程师以设计师的图纸而建造的产品!

    最终的产品也许比设计师原来的图纸有所出入,有些功能有所增强,有些又会适当的减弱,以此来更加适应大众的需求和体验!但是在整体上和本质上都是遵循设计师的构造的。

    展开全文
  • 一、范式 关系模式满足的确定约束条件称为范式,根据满足约束条件的级别不同, 范式由低到高分为1NF,2NF,3NF,BCNF,4NF,5NF等。 

       一、范式

     

            关系模式满足的确定约束条件称为范式,根据满足约束条件的级别不同,
        范式由低到高分为1NF,2NF,3NF,BCNF,4NF,5NF等。

            不同的级别范式性质不同

           关系模式的规范化:把一个低一级的关系模式分解为高一级关系模式的过程。

    第五节 关系模式的规范化

     


      二、概念


        1、第一范式(1NF)

               关系模式的所有域为简单域,其元素(即属性)不可再分,
           是属性项而不是属性组。

          
    4.5.1:

           4.5.2:工资(工号,姓名,工资(基本工资,年绩津贴,煤电补贴))

          △ 不满足1NF的关系称为非规范化关系。
          △ 关系数据模型不能存储上两个例子(非规范化关系),
             在关系数据库中不允许非规范化关系的存在。
          △ 转化方法:
           (1) A1,A2,A3,…,Ak1,Ak2,…,An
           (2) 工资(工号,姓名,基本工资,津贴,奖金)

        2、第二范式2NF):

               给定关系模式R及其上的函数依赖集F,
           如果R的任何一个非主属性都完全依赖于它的每一个侯选关键字,
           则称R是第二范式,简记为2NF。

           △ 若关系模型H包含的每一关系模式都是2NF的,则称该关系模型是2NF的。
           △ 2NF∈1NF

          
    例4.5.3:
               SCT(SNO,CNO,CN,GRADE,TNAME,BDATE,SALARY)
               F={SNO,CNO→GRADE
               CNO→CN,CNO→TNAME
               TNAME→BDATE,TNAME→SALARY} 非2NF

           存在问题:1.数据冗余;2.插入,删除异常 3.修改麻烦。 

           原因:非主属性部分依赖于侯选关键字,
                 关键字是一个元组区别其它元组的依赖,
                 同时也是一个元组赖以存在的依据。

           分解为:SC (SNO,CNO,GRADE),CT(CNO,CN,TNAME,BDATE,SALARY)

          
    4.5.4:
               R=(ABCD,{AB→C,C→D})

           答案:R为2NF


         3、第三范式3NF

              给定关系模式R及其上的函数依赖集F,
          如果R的任何一个非主属性都不传递依赖于它的任何一个侯选关键字,
          则称R是第三范式,简记为3NF。

          △ 若关系模型H包含的每一关系模式都是3NF的,则称该关系模型是3NF的。
          △ 定理:一个3NF的关系(模式)必定是2NF的(3NF∈2NF∈1NF) 。 

          证明:如果一个关系(模式)不是2NF的,那么必有非主属性Aj
            候选关键字X和X的真子集Y存在,使得Y→Aj。由于Aj是非主属性,
            故Aj-(XY)≠Φ,Y是X的真子集,所以YX,
            这样在该关系模式上就存在非主属性Aj传递依赖候选关键字X(X→Y→Aj),
            所以它不是3NF的,证毕。

         
    4.5.4:CT(CNO,TNAME,BDATE,SALARY)

            解:不能存放不开课的教师
    教师信息和课程数一样多。

          原因:传递函数依赖
               R={City,St,Zip}
               F={(City,St)→Zip,Zip→City} 3NF
               CT(CNO,TNAME, BDATE, SALARY)非3NF

          分解为:C(CNO,CNAME,TNAME), T(TNAME,BDATE,SALARY) 3NF

         4、BCNF改进的3NF

                给定关系模式R及其上的函数依赖集F,如果R的任意两个子集X、Y,
            当非平凡函数依赖X→Y为F所蕴涵,则决定因素X中
            必含有侯选关键字或X为超关键字,则称R是Boyde/Codd范式,
            简记为BCNF。

            BCNF的内涵:
             (1)非主属性对关键字完全函数依赖
             (2)主属性对不含它的关键字完全函数依赖
             (3)没有属性完全函数依赖于一组非主属性
             (4)主属性不传递依赖于任何一个侯选关键字
             (5)非主属性不传递依赖于任何一个侯选关键字

          △ 定理: BCNF满足3NF (BCNF∈3NF∈2NF∈1NF)

            反证法:
                R∈BCNF,但R∈BCNF
            设存在非主属性A,关键字X以及属性组Y,使得X→Y,Y→X,Y→A,
            由BCNF有Y→A,则Y为关键字,于是有Y→X,这与YX矛盾。

         
    4.5.6:
                 R={S,T,J}
                 F={T→J,ST→J,SJ→T}非BCNF
                 C(CNO,CNAME,TNAME),T(TNAME,BDATE,SALARY)  BCNF

          分解为:ST(S,T), TJ(T,J)

         5、总结:
             3NF→BCNF:消除主属性对侯选关键字的部分和传递函数依赖
             2NF→3NF :消除非主属性对侯选关键字的传递函数依赖
             1NF→2NF :消除非主属性对侯选关键字的部分函数依赖

         6、规范化的基本思想
                逐步消除不合适的函数依赖,使数据库中的各个关系模式
            达到某种程度的分离。


    第五节 关系模式的规范化

     


      三、分解算法


         1、分解的基本要求

               分解后的关系模式与分解前的关系模式等价,
           即分解必须具有无损联接和函数依赖保持性。

         2、目前分解算法的研究结论

          (1) 若要求分解具有无损联接性,那么分解一定可以达到BCNF。
          (2) 若要求分解保持函数依赖,那么分解可以达到3NF,
              但不一定能达到BCNF。
          (3) 若要求分解既保持函数依赖,又具有无损联接性,
              那么分解可以达到3NF,但不一定能达到BCNF。

         3、面向BCNF且具有无损联接性的分解(算法1)

          输入:关系模式R及其函数依赖集F。
          输出:R的一个无损联接分解,其中每一个子关系模式都满足
                  F在其上投影的BCNF。

          算法实现:
                 反复运用逐步分解定理,逐步分解关系模式R,
             使得每次分解都具有无损联接性,而且
             每次分解出来的子关系模式至少有一个是BCNF的,
               即:
              1)置初值ρ={R};
              2)检查ρ中的关系模式,如果均属BCNF,则转4);
              3)在ρ中找出不属于BCNF的关系模式S,那么必有X→A∈F+
                 (A不包含于X),且X不是S的关键字。因此XA必不包含
                 S的全部属性。把S分解为{S1,S2},其中S1=XA,S2=(S-A)X,
                 并以{S1,S2}代替ρ中的S,返回2)
              4)终止分解,输出ρ。

          定理:算法1正确

          证明:在上述算法的第3)步,

           ⑴由于S1∩S2=X,S1-S2=A,而且满足X→A∈F,
             S分解为{S1,S2}具有无损联接性。
           ⑵由于R中的属性有限,S1和S2所包含的属性个数都有比S少,
             所以经过有限次迭代,算法一定终止,ρ的每一个关系模式都满足BCNF,
             由于每步分解都具有无损联接性,最后分解当然是无损联接的。

         
    4.5.7:
              R=(ABCD,{BC→A}),分解R使分解后的关系达到BCNF且具有无损联接性。

          答案:R1=(ABC, {BC→A}), R2=(BCD, {Ф})

         
    4.5.8:
              无损联接地将CTHRSG分解为一组BCNF的关系模式,
          其中:C表示课程,T表示教师,H表示时间,R表示教室,
                S表示学生,G表示成绩。
          函数依赖集F及其所反映的语义分别为:
              C→T 每门课程仅有一位教师担任。
             HT→R 在任一时间,一个教师只能在一个教室上课。
             HR→C 在任一时间,每个教室只能上一门课。
             HS→R 在任一时间,每个学生只能在一个教室听课。
             CS→G 每个学生学习一门课程只有一个成绩。

          解:1) 关系模式CTHRSG侯选关键字为:HS;
                 由CS不包含侯选关键字,CS→G,
                 分解CTHRSG为CSG和CTHRS,并求得CSG和CTHRS上函数依赖最小集:
                 F11=πCSG(F) ={ CS→G }
                 F12=πCTHRS(F)={HS→R,HT→R,C→T,HR→C}
                 CSR(CSG,{CS→G})(BCNF)
                 CTHRS(CTHRS,{HS→R,HT→R,C→T,HR→C})
                 ρ={CSG, CTHRS}
              2) 关系模式CTHRS侯选关键字为:HS;
                 由C不包含侯选关键字,C→T,
                 分解CT为CSG和CHRS,并求得CT和CHRS上函数依赖最小集:
                 CT(CT,{C→T})(BCNF)
                 CHRS(CHRS,{HS→R,HT→R,HR→C})
                 ρ={CSG,CT, CHRS}
              3) 关系模式CHRS侯选关键字为:HS;
                 由HR不包含侯选关键字,HC→R,
                 分解CT为CSG和CHRS,并求得CT和CHRS上函数依赖最小集:
                 CHR(CH,{HC→R,HR→C})(BCNF)
                 CHS(HS,{HS→C})(BCNF)
              4) ρ={CSG,CT,CHR,CHS}

     

    图4.5.1 算法分解树

          算法1:存在两个问题:
      第一、分解结果不唯一
      例:最后一次分解时如果选择HR→C,
          则分解的最终结果为
            CSG、CT、HRC和HRS。
          所以分解要结合语义和实际应用
          来考虑。
      第二、分解不保证是保持函数依赖的
      例:TH→R未能保持,在分解后各模式的
         函数依赖的并集中没有逻辑蕴涵
         TH→R。


           4、面向3NF且保持函数依赖的分解(算法2)

             输入:关系模式R及其上的最小函数依赖集F。
             输出:R的保持函数依赖的分解,其中每一个关系模式是关于F在其上投影的3NF。

             算法实现:
                 1)如果R中存在一些不在F中出现的属性,
                   则将它们单独构成一个关系模式,并从模式R中消去;
                 2)如果F中有一个函数依赖X→A,且XA=R,则R不用分解,
                   算法终止;
                 3)对F中的每一个函数依赖X→A,构造一个关系模式XA。
                   如果X→A1,X→A2,…,X→An均属于F,则构造一个关系模式XA1A2…An

             定理:算法2正确(证明略)

            
    4.5.9:分解算法1例2关系模式CTHRSG,要保持函数依赖达到3NF。

             解:关系模式CTHRSG的最小函数依赖集F={C→T,CS→G,HR→C,
                 HS→R,TH→R}。该模式可以保持函数依赖地分解为如下一
                 组3NF的关系模式:ρ={CT,CSG,CHR,HSR,HRT}。

          5、面向3NF既有无损联接性又保持函数依赖的分解(算法3)

             输入:关系模式R及其上的最小函数依赖集F。
             输出:R的具有无损联接性及保持函数依赖的分解,
                  其中每一个关系模式均为3NF。

             算法实现:
                1) 按算法2对关系模式R进行分解,设结果为σ={R1,R2,…,Rk};
                2) X是R的关键字,τ=σ∪{X}是R的一个分解。
                3) 求τ式的最小集合(当Ri≤Rj∈τ时,消去Ri)。

             定理:算法3正确
                  设X是R的关键字,则τ=σ∪{X}是R的一个分解,
              且所有的关系模式均满足3NF,同时具有无损联接性和保持函数依赖性。
              由于σ中全部模式均为3NF,X中属性之间不存在传递和部分函数依赖,
              即X也是3NF的。分解τ具有无损联接性可以无损联接性检验算法验证。
              由于X为R的关键字,表中模式X所对应的行,应用修改规则处理后,
              将变成全部由а组成。

           
    4.5.10:
                    将算法1例2的关系模式CTHRSG分解为一组3NF的关系模式,
                要求分解既具有无损联接性又保持函数依赖。

            解:在算法2例中得σ={CT,CSG,CHR,HSR,HRT},
                而HS是原模式的关键字,所以τ={CT,CSG,CHR,HSR,HRT,HS}。
                由于HS是模式HSR的一个子集,所以
                消去HS后的分解{CT,CSG,CHR,HSR,HRT}
                就是具有无损联接性和保持函数依赖性的分解,
                且其中每一个模式均为3NF。
     
    展开全文
  • 数据库物理模型设计的其他模式

    千次阅读 2006-09-06 11:23:00
    连载之7原创:胖子刘(转载请注明作者和出处,谢谢)数据库物理模型设计的其他模式除了上面提到的四种主要设计模式,还有一些其他模式,在某些项目中可能会用到,在这里先简单做个说明,暂不做深入讨论,等到以后的...
  • 连载之7原创:胖子刘(转载请注明作者和出处,谢谢)数据库物理模型设计的其他模式除了上面提到的四种主要设计模式,还有一些其他模式,在某些项目中可能会用到,在这里先简单做个说明,暂不做深入讨论,等到以后的...
  • 数据库物理模型设计的其他模式 除了上面提到的四种主要设计模式,还有一些其他模式,在某些项目中可能会用到,在这里先简单做个说明,暂不做深入讨论,等到以后的项目用到这些模式的时候,再结合实际需求详细解说...
  • 两个不同实体间的1:n关系  上图中表示的是一辆汽车与零件之间的1:n关系,一辆汽车由许多个零件构成。“汽车”这个实体具有型号、单价和牌号等属性,“零件”这个实体具有名称、单价和厂家等属性,“数量”是它们...
  • 解释mvc的设计模式,以及react 与mvc的关系(仅代表个人观点) mvc模式 mvc是一种使用mvc(model view controller 模型-视图-控制器)设计创建web应用程序的模式 model(模型)表示应用程序核心(比如数据记录列表...
  • (六)数据库物理模型设计的其他模式之继承模式 原创:胖子刘(转载请注明作者和出处,谢谢)   数据库物理模型设计的其他模式 除了上面提到的四种主要设计模式,还有一些其他模式,在某些项目中可能会用到,在...
  • 设计模式:工厂方法模式

    万次阅读 2019-01-08 11:23:05
    简单的说,就是依据封闭-开放原则,对简单工厂模式进行了修改。 二、问题 为了能够和简单工厂模式进行比较,这次的问题还是设计一个简单了计算程序。 三、理解 我们用简单工厂模式进行设计, 可以先转至我的另一...
  • 设计模式之组合模式

    千次阅读 2020-09-13 20:25:12
    组合模式(Composite Pattern),又叫整体部分模式,它创建了对象组的树形结构,将对象组合成树状结构以表示“整体-部分”的层次关系。 组合模式依据树形结构来组合对象,用来表示部分以及整体层次,组合模式使得...
  • 一:补充知识 E-R图向关系模式的转换需要考虑的是:...一个实体对应一个关系模型,实体的名称即是关系模型的名称,实体的属性就是关系模型的属性, 实体的码就是关系模型的码。 实体转换时需要注意的: 1:属性域的问题。 2:
  • 张逸,软件设计精要与模式,电子工业出版社 邱郁惠,C++程序员UML实务手册,机械工业出版社 ★软件工程要点 软件工程层次模型EHM 软件设计分为两种:计划的设计与演进的设计。 架构设计需要...
  • 设计模式学习之访问者模式

    万次阅读 多人点赞 2017-04-23 22:15:52
    访问者模式是一种将数据操作与数据结构分离的设计模式,它可以算是 23 中设计模式中最复杂的一个,但它的使用频率并不是很高,大多数情况下,你并不需要使用访问者模式,但是当你一旦需要使用它时,那你就是需要使用...
  • Android设计模式-MVC模式设计

    千次阅读 2016-03-17 17:15:28
    我对开源的理解  首先,感谢Google 的开源系统,让我有了一份Android系统工程师的工作;第二,感谢开源系统,让我们以更加开放、自由的精神工作;... MVC 全名 Mode View Controller(模型-视图-控制器
  • 设计模式的分类

    2020-02-17 15:24:29
    设计模式的分类(主要针对GOF) ​ 分类划分依据模式的目的和模式的作用范围 按照目的分类 ​ 根据目的划分有3种,分别创建型模式、结构性模式以及行为型模式。 创建型模型 用于描述如何创建对象,主要特点是将...
  • 模式是一种复合设计模式,一种在特定场合用于解决某种实际问题来得出的可以反复实践的解决方案。巧合的是他也有三个事物组成,于是乎人们就有了一种想当然的对应关系:展示层-View;业务逻辑层-Control;持久层-...
  • ETL模型设计

    千次阅读 2009-12-16 11:03:00
    关系数据的基础是关系数据库模型,通过标准的SQL语言来加以实现。数据仓库是多维数据库,它扩展了关系数据库模型,以星形架构为主要结构方式的,并在它的基础上,扩展出理论雪花形架构和数据星座等方式,但不管是哪...
  • 大话设计模式设计原则

    千次阅读 多人点赞 2014-03-30 11:48:53
    在我们的大话设计模式中,介绍了六种原则,下面我们对这些原则进行一一讲解。  一、单一职责原则  一枚小小的环形戒指,一如永世不变的约定。戒指的爱情含义,令世间所有女性为之向往。香港戴瑞珠宝集团旗下品牌...
  • 类图用于描述系统中所包含的类以及它们之间的相互关系,帮助人们简化对系统的理解,它是系统分析和设计阶段的重要产物,也是系统编码和测试的重要模型依据。接下来我们就来谈谈类图的组成,在下一篇中我们将讨论一下...
  • 现在针对逻辑数据模型中所用到的三种数据模型---层次数据模型、网状数据模型以及关系数据模型做一个相信的介绍与对比分析。 一、层次数据模型 定义:层次数据模型是用树状<层次>结构来表示实体类型...
  • 设计模式分类

    2016-08-25 15:43:08
    一、目的准则模式依据目的准则可分为创建型(Creational)、结构性(Structural)、行为性(Behavioral) 三种。 创建型模式与对象的创建有关;结构性模式处理类或对象的组合;行为型模式对类或对象怎样交互和怎样...
  • 设计模式-组合模式

    千次阅读 2019-03-27 09:29:39
    组合模式依据树形结构来组合对象,用来表示部分以及整体层次。这种类型的设计模式属于结构型模式,它创建了对象组的树形结构。 如公司、子公司以及部门的例子,以及文件系统和书的目录等等,生活中的例子很多。 ...
  • JAVA设计模式介绍

    2007-05-24 10:13:00
     模型依据使用可以分为:类模式和对象模式。类模式处理类和子类之间的关系,这些关系通过继承建立,是静态的,在编译时刻就确定下来了。对象模式处理对象间的关系,这些关系在运行时确定。常用的设计模式 面向对象...
  • 设计模式总结

    千次阅读 2017-10-08 15:20:02
    简单总结了一下设计模式,没有举例子,只有工厂模式举例子了,做了一个ppt简单介绍了一下25种设计模式和j2ee设计模式(下载链接)六大原则1、开闭原则(Open Close Principle)开闭原则的意思是:对扩展开放,对修改...
  • 设计模式之前言

    万次阅读 2021-05-17 15:36:58
    设计是软件开发生命周期中的关键阶段,好的设计能产生好的产品,而不当的设计则会影响最终产品的质量。一个软件设计的优劣,往往越到后期拓展越能体现出差异。 再说一个我周边一个比较普遍的现象:   &...
  • 设计模式设计模式之结构型模式(适配器、桥接、组合、装饰、外观、享元、代理)1、设计模式1.1 设计模式介绍1.2 分类2、结构型模式2.1 概述2.2 七大结构型设计模式2.2.1 适配器模式 1、设计模式 1.1 设计模式...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 108,198
精华内容 43,279
关键字:

关系模型设计依据