精华内容
下载资源
问答
  • 数据依赖是一个关系内部属性与属性之间的一约束关系,这种关系是通过属性间值的相等与否体现的数据相关的关系。 多种类型的数据依赖:函数依赖和多值依赖 例如:Sname和Sdept函数依赖于Sno,记做Sno -> Sname...

    目录

    一、什么是数据依赖?

    完全函数依赖

    部分函数依赖

    二、码

    三、范式

            1.第一范式(1NF)

            2.第二范式(2NF)

            3.第三范式(3NF)

            4.BC范式(BCNF)-- 也叫作修正的第三范式

    四、关系模式规范化总结


    什么是数据依赖?

    如下左图,这样的一张关系表如果一个系八百个人,同一个系主任名字可能被重复八百遍!所以为了避免冗余,我们可以使用右图的关系依赖:

    学号确定了所在系,所在的系对应其系主任。学号和课程序号加起来就确定了某人的成绩啦(右图:函数依赖)

    什么是规范化理论?

    找出关系模式中不合适的数据依赖,消除它们,可以在不同程度上解决插入异常,删除异常、更新异常和数据冗余问题。就是设计合适的数据库逻辑模式。
     

    函数依赖

    • 平凡函数依赖
    • 非平凡函数依赖

    完全函数依赖

    在一个关系中,若某个非主属性数据项依赖于全部关键字称之为完全函数依赖。

    :成绩表(学号,课程号,成绩)关系中,

    完全函数依赖:(学号,课程号)→ 成绩,学号 -\→ 成绩,课程号 -\→ 成绩,所以(学号,课程号)→ 成绩 是完全函数依赖

    部分函数依赖

    例1 在关系模式Student中,因为Sno不能函数决定Grade,Cno也不能函数决定Grade,但(Sno,Cno)可以唯一地函数决定Grade,所以(Sno,Cno)→Grade是完全函数依赖。因为Sno可以函数决定Sage,所以(Sno,Cno)→Sage是部分函数依赖。

    传递函数依赖:这样婶儿哒↓↓↓

     

    详见:数据库系统概论 | 第二章:关系数据库

     

    范式

    符合某一种级别的关系模式的集合

     

    第一范式(1NF)

    一个关系所有属性都是不可分的基本数据项

    期初余额 本期发生额 期末余额
    借方 贷方 借方 贷方 借方 贷方
    12 23 55 35 56 35
    134 435 534 35 35 566
    245 245 35 56 53 53

     如上图就不是第一范式:期初余额、本期发生额、期末余额都可分

    第一范式是对关系模式最起码的要求,不满足第一范式的数据库模式不能称为关系数据模式。

     

    第二范式(2NF)

    若关系模式R∈1NF,并且每一个非主属性都完全函数依赖于R的码,则R∈2NF

    • 不符合第二范式的例子

    货物类型 货物ID 货物名称 注意事项
    瓷碗 1 白色瓷碗 易碎品
    瓷碗 2 青花瓷碗 易碎品
    瓷碗 3 雕花瓷碗 易碎品
    三合板 1 普通三合板 易燃物品,注意防火

    在该表中主键为(货物类型,货物ID),货物名称字段完全依赖于这个主键,换句话说,货物的名称完全是取决于这个主键的值的。但注意事项”这一列,仅依赖于一个主键中”货物类型“这一个属性简单地说,第二范式要求每个非主属性完全依赖于主键,而不是仅依赖于其中一部分属性。

    那么,既然表中存在一个对主键不是完全依赖的字段,那么我们就可以确定,该表不符合第二范式。

    • 符合第二范式的例子

    货物类型 货物ID 货物名称
    瓷碗 1 白色瓷碗
    瓷碗 2 青花瓷碗
    瓷碗 3 雕花瓷碗
    三合板 1 普通三合板

    在该表中的主键依然是(货物类型、货物ID),非主键字段“货物名称”,完全依赖于这两个主键,那么我们就可以说,该表是符合数据库第二范式的。

     

    例:不符合第二范式的可以使用投影分解法,把关系模式分解为两个(或多个)关系模式,消除部分函数依赖:

     

    第三范式(3NF)

    在第二范式的基础上消除传递依赖,就是第三范式。

    • 不符合第三范式的例子

    这样的传递依赖使Sloc不能随意修改,Sdept不能随意删除等等,存在冲突!

    可以使用投影分解法修改为第三范式,消除传递依赖,如下图小方块↓↓↓

     这样就不存在刚才那些异常了,变成了这样,解决了上述冲突:

    • 符合第三范式的例子

     下面正式介绍3NF:

     

     

    BC范式(BCNF)-- 也叫作修正的第三范式

    满足BC范式的关系将消除任何属性(主属性和非主属性)对关系键的部分函数依赖和传递函数依赖。在函数依赖的范畴内,它实现了模式的彻底分解,达到了最高的规范化程度,消除了操作异常诸多问题。

    • 不符合第三范式的例子

    这样的传递使没有学生的老师不能入数据库等等问题。

    可以使用投影分解法修改为BC范式,消除传递依赖,如下图小方块↓↓↓

    总之,如果不存在 –>C , B–>C 类似这样的情况,也就是说部分函数依赖。 A–>B , B–>C 这种情况,也就是传递函数依赖,不管这些ABC属性是主属性还是非主属性,反正就是不存在 “部分函数依赖和传递函数依赖” ,这就是

     

    关系模式规范化总结

     

    展开全文
  • 关系模式分解

    千次阅读 2020-01-02 12:14:10
    模式设计不好,存在数据冗余、插入异常、删除异常和更新异常 p1 = {S-C(学号,班级),C-M(班级,班主任)} p2 = {S-C(学号,班级),C-M(学号,班主任)} p3 = {S-C(学号,班主任),C-M(班级,班主任)} 规范化理论...

    模式分解


    模式S-C-M (S 学号,C 班级,M 班主任)

    该模式设计不好,存在数据冗余、插入异常、删除异常和更新异常

    p1 = {S-C(学号,班级),C-M(班级,班主任)}
    p2 = {S-C(学号,班级),C-M(学号,班主任)}
    p3 = {S-C(学号,班主任),C-M(班级,班主任)}



    规范化理论:

    1. 检测是否在一个表中聚集了过多的属性的过程
    2. 模式分解来消除违反范式规则而带来的影响(插入、更新、删除异常,冗余大),构造合适的(更好的)数据模式
    3. 概念建模过程中规范化用于检验却总是很有帮助


    数据依赖

    1. 一个关系内部属性与属性之间的一种约束关系(属性值时候相同)
    2. 现实世界属性间相互联系的抽象
    3. 数据内在性质
    4. 语义的体现

    函数依赖FD

    Sno Sname Ssex Sage
    a value b1 value c value d value
    a2 value b2 value c2 value d2 value
    an value bn value cn value dn value

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

    For example:
    Sno → Ssex, Sno → Sage
    假设不允许重名 Sno ←→ Sname


    1. 非平凡函数依赖

      X → Y ,但 Y ⊈ X 则称 X → Y 为非平凡函数依赖
      Y ⊈ X 换为 Y ⊆ X ,则 X → Y 为平凡函数依赖 (对于任一关系模式,必然成立)

    2. 完全函数依赖

      如果 X → Y ,并且对于 X 的任何一个真子集 X’ , 都有 X’ ↛ Y , 则称 Y 对 X 完全函数依赖,

    3. 部分函数依赖
    4. 传递函数依赖

    在这里插入图片描述
    在这里插入图片描述

    多值依赖MVD


    关系模式

    五元组 :R(U,D,DOM,F)R(U, D, DOM, F)

    • R:符号化的元组语义
    • U:一组属性
    • F:属性组U中属性所来自的域
    • DOM:属性到域的映射
    • F:属性组U上的一组数据依赖

    把关系模式看作一个三元组:R<U,F>R<U,F>

    U ={Sno, Sdept, Mname, Cno, Grade}// 数据冗余、更新异常、插入异常、删除异常
    // 分解
    S(Sno,Sdept,Sno → Sdept);
    SC(Sno,Cno,Grade,(Sno,Cno) → Grade);
    DEPT(Sdept,Mname,Sdept → Mname)
    

    范式

    范式: 是符合某种基本的关系模式的集合
    在这里插入图片描述
    在这里插入图片描述

    • 1NF:每个分量必须是不可分开的数据项
    • 2NF:符合1NF,每一个非主属性都完全函数依赖于任何一个候选码
    • 3NF:符合2NF,消除非主属性对于码传递函数依赖
    • BCNF:符合3NF,消除主属性对于码的部分与传递函数依赖

    4NF:设R是一个关系模型,D是R上的多值依赖集合。如果D中存在凡多值依赖 X->Y时,X必是R的超码,那么称R是第四范式的模式

    满足BCNF:

    • 实现了模式的彻底分解
    • 最高的规范化程度
    • 消除了插入异常和删除异常。

    规范化: 低级范式的关系模式通过模式分解,可以转换为若干个高一级范式的关系模式集合的过程。

    3NF 和 BCNF的区别
    BCNF:如果关系模式R(U,F)的所有属性(包括主属性和非主属性)都不传递依赖于R的任何候选关键字,那么称关系R是属于BCNF的。或是关系模式R,如果每个决定因素都包含关键字(而不是被关键字所包含),则BCNF的关系模式。
    例:配件管理关系模式 WPE(WNO,PNO,ENO,QNT)分别表仓库号,配件号,职工号,数量。有以下条件
    a.一个仓库有多个职工。
    b.一个职工仅在一个仓库工作。
    c.每个仓库里一种型号的配件由专人负责,但一个人可以管理几种配件。
    d.同一种型号的配件可以分放在几个仓库中。

    分析:由以上得 PNO 不能确定QNT,由组合属性(WNO,PNO)来决定,存在函数依赖(WNO,PNO) -> ENO。由于每个仓库里的一种配件由专人负责,而一个人可以管理几种配件,所以有组合属性(WNO,PNO)才能确定负责人,有(WNO,PNO)-> ENO。因为 一个职工仅在一个仓库工作,有ENO -> WNO。由于每个仓库里的一种配件由专人负责,而一个职工仅在一个仓库工作,有 (ENO,PNO)-> QNT。
    找一下候选关键字,因为(WNO,PNO) -> QNT,(WNO,PNO)-> ENO ,因此 (WNO,PNO)可以决定整个元组,是一个候选关键字。根据ENO->WNO,(ENO,PNO)->QNT,故(ENO,PNO)也能决定整个元组,为另一个候选关键字。属性ENO,WNO,PNO 均为主属性,只有一个非主属性QNT。它对任何一个候选关键字都是完全函数依赖的,并且是直接依赖,所以该关系模式是3NF。

    分析一下主属性。因为ENO->WNO,主属性ENO是WNO的决定因素,但是它本身不是关键字,只是组合关键字的一部分。这就造成主属性WNO对另外一个候选关键字(ENO,PNO)的部 分依赖,因为(ENO,PNO)-> ENO但反过来不成立,而P->WNO,故(ENO,PNO)-> WNO 也是传递依赖。
    虽然没有非主属性对候选关键辽的传递依赖,但存在主属性对候选关键字的传递依赖,同样也会带来麻烦。如一个新职工分配到仓库工作,但暂时处于实习阶段,没有独立负责对某些配件的管理任务。由于缺少关键字的一部分PNO而无法插入到该关系中去。又如某个人改成不管配件了去负责安全,则在删除配件的同时该职工也会被删除。

    解决办法:分成管理EP(ENO,PNO,QNT),关键字是(ENO,PNO)工作EW(ENO,WNO)其关键字是ENO。
    缺点: 分解后函数依赖的保持性较差。如此例中,由于分解,函数依赖(WNO,PNO)-> ENO 丢失了, 因而对原来的语义有所破坏。没有体现出每个仓库里一种部件由专人负责。有可能出现 一部件由两个人或两个以上的人来同时管理。因此,分解之后的关系模式降低了部分完整性约束。


    模式分解实例

    在这里插入图片描述
    在这里插入图片描述

    函数依赖理论

    • 函数依赖集的闭包
      • 用于发现所有蕴含的函数依赖
    • 属性集的闭包
      • 用于判断某属性集能够函数确定的其他因素
    • 最小函数依赖集
      • 用于寻找等价( 闭包相同) 的最小集,便于降低检测开销
    • 无损分解
      • 能够通过自然连接恢复原关系的分解策略
    • 保持依赖
      • 分解后的各子关系函数依赖集并集的闭包与分解前某关系函数依赖集的闭包相同
        在这里插入图片描述

    相关计算

    实例:求解函数依赖集的闭包
    在这里插入图片描述

    算法:求属性集X 关于函数依赖集F 的闭包
    在这里插入图片描述
    实例:

    在这里插入图片描述

    展开全文
  • 关系模式的分解与范式

    万次阅读 多人点赞 2017-05-08 16:40:26
    因此为了完善数据库的增删改查的功能,需要寻找一等价的关系模式,使得以上弊端得以解决。 2. 如何实现关系模式的分解? 答:以上的这种等价关系需要满足两个条件:1》保持无损连接性。A.解释:在分解之后,n个...

    1.     为什么要研究数据库关系模式的分解?

    答:因为现有的模式可能会存在一些数据增删改的弊端,比如说:数据冗余太大,更新异常,插入异常,删除异常。因此为了完善数据库的增删改查的功能,需要寻找一种等价的关系模式,使得以上弊端得以解决。

    2.     如何实现关系模式的分解?

    答:以上的这种等价关系需要满足两个条件:1》保持无损连接性。A.解释:在分解之后,n个分解关系通过自然连接(自然连接是在等值连接的基础上去掉相同的列,如果自然连接中找不到等值信息那么自然连接就等价于笛卡尔积)形成的二维表和没分解之前关系的二维表是等价的(元组没有增加也没有减少),则称这种分解形成的关系模式保持无损连接性;B.如何判断无损连接性:2》保持函数依赖性。解释:若分解之后的关系模式中仍然存在和没分解之前属性的函数依赖关系则称保持分解的函数依赖性.

    1) B1: 对于分解为多个关系模式的方法如例1(适用于所有情况):

    无损分解的测试方法。输入:关系模式R=A1A2...An),FR上成立的函数依赖集,ρ={R1,R2...Rn}R的一个分解;输出:判断ρ相对于F是否具有无损分解特性。无损分解的测试算法如下: 

    1.      构造一张kn列的表格,每列对应一个属性Aj1≤j≤n),每行对应一个模式Rj1≤i≤k)。如果AjRi中,那么在表格的第i行第j列处填上符号aj,否则填上bij

    2.      把表格看成模式R的一个关系,反复检查F中每个FD在表格中是否成立,若不成立,则修改表格中的值,修改方法为:对于F中一个函数依赖X→Y,如果表格中有两行在X值上相等,在Y值上不相等,那么把这两行在Y值上也改成相等的值,如果Y值中一个是aj,那么另一个也改成aj;如果没有aj那么用其中一个bij替换另一个字(尽量把下表ij改成较小的数)。一直到表格不能修改为止,这个过程成为chase(追踪)过程

    3.      若修改后的最后一直表格中有一方全是a,a1a2...an,则称ρ相对于F是无损分解,否则称为损失分解

     

    2) B2: 对于只分解为二个关系模式的还可以使用例2的方法:

    关系模式R的一个分解 ρ = { R11,F1>R22,F2>}如果U1∩U2→ U1U2属于F+的子集 U1∩U2 → U2U1属于F+的子集 ,那么ρ具有无损连接性。

    此定理可用于一分为二的模式分解无损连接性的判定

    2:学生关系S ( Sno,Sname, Ssex, Dept, DeptManager )分解为S(Sno,Sname, Ssex, Sdept) D(Dept,DeptManager), D∩S = Dept , DS = DeptManager, Dept→DeptManager为原关系中的函数依赖,此分解为无损连接的分解。

     

     

    3.     关系模式的范式:

    主要有4种范式,1NF2NF3NFBCNF,按从左至右的顺序一种比一种要求更严格。要符合某一种范式必须也满足它前边的所有范式。一般项目的数据库设计达到3NF就可以了,而且可根据具体情况适当增加冗余,不必教条地遵守所谓规范。

    简单而言,1NF就是要求一张表里只放相互关联的字段,一个字段里只放一条信息,这只是最基本的要求。

    1)第一范式

    在关系模式R中的每一个具体关系r中,如果每个属性值都是不可再分的最小数据单位,则称R是第一范式的关系。

    在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。 

    例:如职工号,姓名,电话号码组成一个表(一个人可能有一个办公室电话和一个家里电话号码)规范成为1NF有两种方法:

    一是职工号为关键字,电话号码分为单位电话和住宅电话两个属性

    二是职工号为关键字,但强制每条记录只能有一个电话号码。

     

    2)第二范式(2NF)

    如果关系模式R1NF,并且R中的每一个非主属性都完全依赖于R的某个候选关键字,则称R是第二范式的,简记为2NF

    . 设有关系模式R(学号S#,课程号C#,成绩G,任课教师TN,教师专长TS),基于R的函数依赖集F={(S#,C#)→G,C#→TN,TN→TS},判断R是否为2NF

    解:(1) 容易看出,关系模式R1NF。因为R符合关系的定义,R的所有属性值都是不可再分的原子值。

    R是否为2NF,应根据2NF的定义来判断。                                          

    首先要确定关系模式R中各属性间的函数依赖情况。如果没有直接给出R的函数依赖集,就要按照语义把它确定下来。在本例中,已直接给出基于R的函数依赖集F,我们可使用阿氏推理规则并结合下面介绍的方法,进一步确定R中哪些是主属性、哪些是非主属性、侯选关键字由哪些属性构成。

    写出函数依赖集F中的各个函数依赖以帮助分析

     用阿氏推理规则由F可推出:(S#,C#)→{S#,C#,G,TN,TS},即属性组合(S#,C#)R的候选关键字(R只有这一个候选键)(S#,C#)的一个值可惟一标识R中的一个元组(并且没有多余的属性)

    R中,S#,C#是主属性;其余的属性G,TN,TS为非主属性。

    非主属性G对键是完全依赖:(S#,C#)→G。但非主属性TN,TS对键是部分依赖(他们仅依赖于键的真子集C#)由于R中存在非主属性对候选键的部分依赖,所以关系模式R不是2NF

    R中存在非主属性对候选键的部分依赖,将会引起数据冗余、数据操作异常等问题。可以把关系R无损联接地分解成两个2NF的关系模式:

    ρ={R1,R2}R1={S#.C#,G},R2={C#,TN,TS}

     

    3)第三范式(3NF)

    如果关系模式R2NF,并且R中的每一个非主属性都不传递依赖于R的某个候选关键字,则称R是第三范式的,简记为3NF

    例续上例(R(学号S#,课程号C#,成绩G,任课教师TN,教师专长TS)),判断关系模式R1={S#.C#,G},R2={C#,TN,TS} 是否为3NF

    解:

    (1) 在关系模式R1={S#,C#,G},候选关键字是(S#,C#),主属性是S#,C#,非主属性是G,函数依赖为(S#,C#)→G  由于R1中不存在非主属性对候选关键字的传递依赖,所以关系模式R13NF

    (2) 在关系模式R2={C#,TN,TS},候选关键字是C#,主属性是C#,非主属性是TN,TS,函数依赖为C#→TNTN→TS。由于R2中存在非主属性对候选关键字的传递依赖C#TS,所以关系模式R2不是3NF

    可以把关系R2无损联接地分解成两个3NF的关系模式:

    ρ={R3,R4}R3={C#,TN},R4={TN,TS}

     

    4Boyce-Codd范式(BCNF)

    如果关系模式R1NF,并且R中的每一个函数依赖X→Y(YÏX),必有XR的超关键字,则称RBoyce-Codd范式的,简记为BCNF

    BCNF的定义中,可以明显地得出如下结论:

    (1) 所有非主属性对键是完全函数依赖;

    (2) 所有主属性对不包含它的键是完全函数依赖;

    (3)没有属性完全函数依赖于非键的任何属性组合。

    2NF,3NF的定义不同,BCNF的定义直接建立在1NF的基础上。但实质上BCNF3NF的改进形式。3NF仅考虑了非主属性对键的依赖情况,BCNF把主属性对键的依赖情况也包括进去。BCNF要求满足的条件比3NF所要求的更高。如果关系模式RBCNF的,那么R必定是3NF,反之,则不一定成立。

    续前例(学号S#,课程号C#,成绩G,任课教师TN,教师专长TS,判断两个3NF关系模式R3={C#,TN},R4={TN,TS}是否为BCNF

    解:在关系模式R3中有函数依赖C#→TN,决定因素C#R3的键;

    在关系模式R4中有函数依赖TN→TS,决定因素TNR4的键;

         R3,R4都满足BCNF的定义,所以,这两个关系模式都是BCNF

     

    4.     总结

    第一范式(1NF):数据库表中的字段都是单一属性的,不可再分。这个单一属性由基本类型构成,包括整型、实数、字符型、逻辑型、日期型等。 

     第二范式(2NF):数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖(部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况),也即所有非关键字段都完全依赖于任意一组候选关键字 

     第三范式(3NF):在第二范式的基础上,数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖,指的是如果存在"A → B → C"的决定关系,则C传递函数依赖于A。因此,满足第三范式的数据库表应该不存在如下依赖关系:  关键字段非关键字段x → 非关键字段

    BCNF: 3NF的基础上不存在关键字段决定关键字段的情况。

     

    1、第一范式(1NF):一个关系模式R的所有属性都是不可分的基本数据项。 

    2、第二范式(2NF):关系模式R属于第一范式,且每个非主属性都完全函数依赖于键码。 

    3、第三范式(3NF):关系模式R属于第一范式,且每个非主属性都不传递依赖于键码。 

    4 BC范式(BCNF):关系模式R属于第一范式,且每个属性都不传递依赖于键码。

    展开全文
  • 1NF 2NF 3NF BCNF 模式分解

    1. 问题的提出

    关系数据库逻辑设计

    • 针对具体问题,如何构造一个适合于它的数据模式
    • 数据库逻辑设计的工具──关系数据库的规范化理论

    1.1 概念回顾

    • 关系
    • 关系模式
    • 关系数据库
    • 关系数据库的模式

    1.2 关系模式的形式化定义

    关系模式由五部分组成,即它是一个五元组:
    R(U, D, DOM, F)
    R:       关系名
    U:       组成该关系的属性名集合
    D:       属性组U中属性所来自的域
    DOM: 属性向域的映象集合
    F:       属性间数据的依赖关系集合

    1.3 什么是数据依赖

    1.3.1 完整性约束的表现形式

    限定属性取值范围:例如学生成绩必须在0-100之间
    定义属性值间的相互关连(主要体现于值的相等与否),这就是数据依赖,它是数据库模式设计的关键

    1.3.2 数据依赖

    • 一个关系内部属性与属性之间的约束关系
    • 现实世界属性间相互联系的抽象
    • 数据内在的性质
    • 语义的体现

    1.3.3 数据依赖的类型

    • 函数依赖(Functional Dependency,简记为FD)
    • 多值依赖(Multivalued Dependency,简记为MVD)
    • 其他

    1.4 关系模式的简化定义

    关系模式R(U, D, DOM, F)
    简化为一个三元组:R(U, F)
    当且仅当U上的一个关系r满足F时,r称为关系模式 R(U, F)的一个关系

    1.5 数据依赖对关系模式影响

    1.5.1 [例1]

    建立一个描述学校教务的数据库:
    学生的学号(Sno)、所在系(Sdept)
    系主任姓名(Mname)、课程名(Cname)
    成绩(Grade)

    单一的关系模式 :   Student <U、F>
    U ={ Sno, Sdept, Mname, Cname, Grade }
    属性组U上的一组函数依赖F:
    F ={ Sno → Sdept,  Sdept → Mname,  (Sno, Cname) → Grade }

    1.5.2 关系模式Student<U, F>中存在的问题 

    1. 数据冗余太大
    2. 更新异常(Update Anomalies)
    3. 插入异常(Insertion Anomalies)
    4. 删除异常(Deletion Anomalies)

    结论:Student关系模式不是一个好的模式。
    “好”的模式:不会发生插入异常、删除异常、更新异常,数据冗余应尽可能少
    原因:由存在于模式中的某些数据依赖引起的
    解决方法:通过分解关系模式来消除其中不合适的数据依赖

    1.5.3 分解关系模式

    把这个单一模式分成3个关系模式:
         S(Sno,Sdept,Sno → Sdept);
         SC(Sno,Cno,Grade,(Sno,Cno) → Grade);
         DEPT(Sdept,Mname,Sdept→ Mname) 


    2. 规范化

    规范化理论正是用来改造关系模式,通过分解关系模式来消除其中不合适的数据依赖,以解决插入异常、删除异常、更新异常和数据冗余问题。

    2.1  函数依赖

    2.1.1 函数依赖

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

    1. 所有关系实例均要满足
    2. 语义范畴的概念
    3. 数据库设计者可以对现实世界作强制的规定

    2.1.2 平凡函数依赖与非平凡函数依赖

    定义:在关系模式R(U)中,对于U的子集X和Y,
    如果X→Y,但Y \nsubseteq X,则称X→Y是非平凡的函数依赖
    若X→Y,但Y ⊆ X,   则称X→Y是平凡的函数依赖
    例:在关系SC(Sno, Cno, Grade)中,
    非平凡函数依赖: (Sno, Cno) → Grade
    平凡函数依赖:     (Sno, Cno) → Sno 
                                   (Sno, Cno) → Cno

    • 若X→Y,则X称为这个函数依赖的决定属性组,也称为决定因素(Determinant)。
    • 若X→Y,Y→X,则记作X←→Y。
    • 若Y不函数依赖于X,则记作X→Y。

    2.1.3 完全函数依赖与部分函数依赖

    定义:在R(U)中,如果X→Y,并且对于X的任何一个真子集X’,都有X’ !\rightarrowY, 则称Y对X完全函数依赖,记作X \overset{F}{\rightarrow}Y。
    若X→Y,但Y不完全函数依赖于X,则称Y对X部分函数依赖,记作X\overset{P}{\rightarrow}Y。

    [例1]   (Sno,Cno)\overset{F}{\rightarrow}Grade是完全函数依赖,

          (Sno,Cno)\overset{P}{\rightarrow}Sdept是部分函数依赖

          因为SnoSdept成立,且Sno是(SnoCno)的真子集

    2.1.4 传递函数依赖

    定义:在R(U)中,如果X→Y,(Y\nsubseteqX) ,Y!→X Y→Z, 则称Z对X传递函数依赖。
        记为:X \overset{t}{\rightarrow} Z

    注: 如果Y→X, 即X←→Y,则Z直接依赖于X。

    例: 在关系Std(Sno, Sdept, Mname)中,有:
          Sno → Sdept,Sdept → Mname
          Mname传递函数依赖于Sno

    2.2  码

    2.2.1 码

    定义:设K为R<U,F>中的属性或属性组合。若K\overset{F}{\rightarrow}U,  则K称为R的侯选码(Candidate Key)。若候选码多于一个,则选定其中的一个做为主码(Primary Key)。

    主属性与非主属性

    • 包含在任何一个候选码中的属性 ,称为主属性(Prime attribute) 
    • 不包含在任何码中的属性称为非主属性(Nonprime attribute)或非码属性(Non-key attribute) 

    全码

    • 整个属性组是码,称为全码(All-key) 

    [例2]
        关系模式S(Sno,Sdept,Sage),单个属性Sno是码,
        SC(Sno,Cno,Grade)中,(Sno,Cno)是码
    [例3]
           关系模式R(P,W,A)
           P:演奏者     W:作品    A:听众
           一个演奏者可以演奏多个作品
           某一作品可被多个演奏者演奏
           听众可以欣赏不同演奏者的不同作品
           码为(P,W,A),即All-Key  

    2.2.2 外部码

    定义:关系模式 R 中属性或属性组X 并非 R的码,但 X 是另一个关系模式的码,则称 X 是R 的外部码(Foreign key)也称外码

    • 如在SC(Sno,Cno,Grade)中,Sno不是码,但Sno是关系模式S(Sno,Sdept,Sage)的码,则Sno是关系模式SC的外部码 
    • 主码与外部码一起提供了表示关系间联系的手段

    2.3  范式

    范式是符合某一种级别的关系模式的集合
    关系数据库中的关系必须满足一定的要求。满足不同程度要求的为不同范式
    范式的种类:    

    • 第一范式(1NF)
    • 第二范式(2NF)
    • 第三范式(3NF)
    • BC范式(BCNF)
    • 第四范式(4NF)
    • 第五范式(5NF)

    各种范式之间存在联系:

    某一关系模式R为第n范式,可简记为R∈nNF。
    一个低一级范式的关系模式,通过模式分解可以转换为若干个高一级范式的关系模式的集合,这种过程就叫规范化 

    2.4  2NF

    2.4.1 1NF的定义

    如果一个关系模式R的所有属性都是不可分的基本数据项,则R∈1NF
    第一范式是对关系模式的最起码的要求。不满足第一范式的数据库模式不能称为关系数据库但是满足第一范式的关系模式并不一定是一个好的关系模式

    2.4.2 S-L-C不是一个好的关系模式

    [例4] 关系模式 S-L-C(Sno, Sdept, Sloc, Cno, Grade)
    Sloc为学生住处,假设每个系的学生住在同一个地方

    函数依赖包括:
               (Sno, Cno) \overset{F}{\rightarrow}Grade
               Sno → Sdept
               (Sno, Cno) \overset{P}{\rightarrow}Sdept
               Sno → Sloc
               (Sno, Cno) \overset{P}{\rightarrow}Sloc
               Sdept → Sloc

    • S-L-C的码为(Sno, Cno)
    • S-L-C满足第一范式。
    • 非主属性Sdept和Sloc部分函数依赖于码(Sno, Cno)

    S-L-C不是一个好的关系模式

    1. 插入异常
    2. 删除异常
    3. 数据冗余度大
    4. 修改复杂

    原因
          Sdept、 Sloc部分函数依赖于码。
    解决方法
         S-L-C分解为两个关系模式,以消除这些部分函数依赖 
                    SC(Sno, Cno, Grade)
                    S-L(Sno, Sdept, Sloc)

    • 关系模式SC的码为(Sno,Cno)
    • 关系模式S-L的码为Sno
    • 这样非主属性对码都是完全函数依赖

    2.4.2 2NF的定义

     定义 :若R∈1NF,且每一个非主属性完全函数依赖于码,则R∈2NF。

     例:S-L-C(Sno, Sdept, Sloc, Cno, Grade) ∈1NF
            S-L-C(Sno, Sdept, Sloc, Cno, Grade) \notin2NF     
            SC(Sno, Cno, Grade) ∈ 2NF
            S-L(Sno, Sdept, Sloc) ∈ 2NF

    采用投影分解法将一个1NF的关系分解为多个2NF的关系,可以在一定程度上减轻原1NF关系中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。

    将一个1NF关系分解为多个2NF的关系,并不能完全消除关系模式中的各种异常情况和数据冗余。

    2.5  3NF

    2.5.1 3NF的定义

    定义:关系模式R<U,F> 中若不存在这样的码X、属性组Y及非主属性Z(Z  Y), 使得X→Y,Y→Z成立, Y !→ X,则称R<U,F> ∈ 3NF。

    • 若R∈3NF,则每一个非主属性既不部分依赖于码也不传递依赖于码

    2.5.2 2NF存在的问题

    例:2NF关系模式S-L(Sno, Sdept, Sloc)中
    函数依赖:
              Sno→Sdept
              Sdept → Sno
              Sdept→Sloc
     可得:          
              Sno→Sloc,即S-L中存在非主属性对码的传递函数依赖,S-L \notin 3NF

    解决方法
    采用投影分解法,把S-L分解为两个关系模式,以消除传递函数依赖:
             S-D(Sno, Sdept)
             D-L(Sdept,Sloc)
    S-D的码为Sno, D-L的码为Sdept。
    分解后的关系模式S-D与D-L中不再存在传递依赖 

    • S-L(Sno, Sdept, Sloc) ∈ 2NF
    • S-L(Sno, Sdept, Sloc)  \notin 3NF 
    • S-D(Sno,Sdept) ∈ 3NF
    • D-L(Sdept, Sloc)∈ 3NF

    采用投影分解法将一个2NF的关系分解为多个3NF的关系,可以在一定程度上解决原2NF关系中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。

    将一个2NF关系分解为多个3NF的关系后,仍然不能完全消除关系模式中的各种异常情况和数据冗余。

    2.6  BCNF

    2.6.2 BCNF的定义

    定义:关系模式R<U,F>∈1NF,若X !→Y且Y \subseteq X时X必含有码,则R<U,F> ∈BCNF。

    等价于:每一个决定属性因素都包含码

    若R∈BCNF 

    • 所有非主属性对每一个码都是完全函数依赖
    • 所有的主属性对每一个不包含它的码,也是完全函数依赖
    • 没有任何属性完全函数依赖于非码的任何一组属性

    2.6.2 举例说明

    [例8]在关系模式STJ(S,T,J)中,S表示学生,T表示教师,J表示课程。
    函数依赖:
            (S,J)→T,(S,T)→J,T→J
    (S,J)和(S,T)都是候选码

    STJ∈3NF 
    没有任何非主属性对码传递依赖或部分依赖 
    STJ \notin BCNF
    T是决定因素,T不包含码

    解决方法

    将STJ分解为二个关系模式:
         ST(S,T) ∈ BCNF, TJ(T,J)∈ BCNF

    没有任何属性对码的部分函数依赖和传递函数依赖

    如果R∈3NF,且R只有一个候选码

    2.7  多值依赖

    2.8  4NF

    2.9  规范化小结

    关系数据库的规范化理论是数据库逻辑设计的工具

    目的:尽量消除插入、删除异常,修改复杂,数据冗余

    基本思想:逐步消除数据依赖中不合适的部分

    实质:概念的单一化

    关系模式规范化的基本步骤

    • 不能说规范化程度越高的关系模式就越好
    • 在设计数据库模式结构时,必须对现实世界的实际情况和用户应用需求作进一步分析,确定一个合适的、能够反映现实世界的模式
    • 上面的规范化步骤可以在其中任何一步终止

    3. 数据依赖的公理系统

    3.1 逻辑蕴含

    定义:对于满足一组函数依赖 F 的关系模式R <U,F>,其任何一个关系r,若函数依赖X→Y都成立, (即r中任意两元组t,s,若t[X]=s[X],则t[Y]=s[Y]),则称F逻辑蕴含X →Y

    3.2 Armstrong公理系统

    关系模式R <U,F >来说有以下的推理规则:

    • A1.自反律(Reflexivity):若Y \subseteq X \subseteq U,则X →Y为F所蕴含。
    • A2.增广律(Augmentation):若X→Y为F所蕴含,且Z  U,则XZ→YZ为F所蕴含。
    • A3.传递律(Transitivity):若X→Y及Y→Z为F所蕴含,则X→Z为F所蕴含。

    3.2.1 自反律

    自反律: 若Y  \subseteq X  \subseteq U,则X →Y为F所蕴含

    证: 设Y  X  U 
    对R <U,F> 的任一关系r中的任意两个元组t,s:
    若t[X]=s[X],由于Y  X,有t[y]=s[y],
    所以X→Y成立,自反律得证

    3.2.2 增广律

    增广律: 若X→Y为F所蕴含,且Z \subseteq U,则XZ→YZ 为F所蕴含。

     证:设X→Y为F所蕴含,且Z  \subseteq U。
    设R<U,F> 的任一关系r中任意的两个元组t,s:
    若t[XZ]=s[XZ],则有t[X]=s[X]和t[Z]=s[Z];
    由X→Y,于是有t[Y]=s[Y],所以t[YZ]=s[YZ],
    所以XZ→YZ为F所蕴含,增广律得证。

    3.2.3 传递律

    传递律:若X→Y及Y→Z为F所蕴含,则X→Z为 F所蕴含。

    证:设X→Y及Y→Z为F所蕴含。
    对R<U,F> 的任一关系 r中的任意两个元组 t,s:
    若t[X]=s[X],由于X→Y,有 t[Y]=s[Y];
    再由Y→Z,有t[Z]=s[Z],所以X→Z为F所蕴含,传递律得证。

    3.3 导出规则

    根据A1,A2,A3这三条推理规则可以得到下面三条推理规则:

    • 合并规则:由X→Y,X→Z,有X→YZ。(A2, A3)
    • 伪传递规则:由X→Y,WY→Z,有XW→Z。(A2, A3)
    • 分解规则:由X→Y及 Z \subseteq Y,有X→Z。(A1, A3)

    根据合并规则和分解规则,可得引理
    引理: X→A1 A2…Ak成立的充分必要条件是X→Ai成立(i=l,2,…,k)

    3.4 函数依赖闭包

    3.4.1 Armstrong公理系统是有效的、完备的

    有效性:由F出发根据Armstrong公理推导出来的每一个函数依赖一定在F+中;
    完备性:F+中的每一个函数依赖,必定可以由F出发根据Armstrong公理推导出来

    3.4.2 函数依赖闭包

    定义: 在关系模式R<U,F>中为F所逻辑蕴含的函数依赖的全体叫作 F的闭包,记为F+。
    定义:设F为属性集U上的一组函数依赖,X \subseteq U, XF+ ={ A|X→A能由F 根据Armstrong公理导出},XF+称为属性集X关于函数依赖集F 的闭包

    F={X\rightarrowA1, …… , X\rightarrowAn}的闭包F+计算是一个NP完全问题

    3.4.3 闭包的引理

    引理:设F为属性集U上的一组函数依赖,X,Y \subseteq U,X →Y能由F 根据Armstrong公理导出的充分必要条件是Y \subseteq XF+
    用途:将判定X→Y是否能由F根据Armstrong公理导出的问题,转化为求出XF+ 、判定Y是否为XF+的子集的问题

    3.4.4 求闭包的算法

    算法:求属性集X(X \subseteq U)关于U上的函数依赖集F 的闭包XF+ 

    输入:X,F 

    输出:XF+

    步骤:
    (1)令X(0)=X,i=0
    (2)求B,这里B = { A |(\exists V)( \exists W)(V→W \in F∧V \subseteq X(i)∧A \in W)};
    (3)X(i+1)=B∪X(i) 
    (4)判断X(i+1)= X (i)吗?
    (5)若相等或X(i)=U , 则X(i)就是XF+ , 算法终止。
    (6)若否,则 i=i+l,返回第(2)步。

    [例1]  已知关系模式R<U,F>,其中
    U={A,B,C,D,E};
    F={AB→C,B→D,C→E,EC→B,AC→B}。
    求(AB)F+ 。

    解:设X(0)=AB;
    (1) X(1)=AB∪CD=ABCD。

    (2) X(0)≠ X(1)
         X(2)=X(1)∪BE=ABCDE。

    (3) X(2)=U,算法终止
        (AB)F+ =ABCDE。

    [例2] 设有关系模式R(A,B,C,D,E),其上的函数依赖集:F={A→BC,CD→E, B→D,E→A}
    (1)计算B+;(2)求出R的所有候选关键字

    解:
    (1)X={B},X(0)={B}, X(1)={BD}, X(2)={BD},所以B+={BD}
    (2)根据候选关键字定义,R的候选关键字只可能由F中各函数依赖的只出现在左边属性和未出现在函数依赖中的属性构成,但是除此以外,对于即出现在左边,又出现在右边的属性,也可能构成候选关键字。所以可进行组合分析得到A,BC,CD ,E也为候选关键字
    综上,候选关键字为:A,BC,CD,E

    3.4.5 函数依赖依赖集等价

    定义:如果G+=F+,就说函数依赖集F覆盖G(F是G的覆盖,或G是F的覆盖),或F与G等价。
    引理:F+ = G+ 的充分必要条件是F \subseteq G+ ,和G \subseteq F+ 

    3.4.6 最小依赖集

    定义:如果函数依赖集F满足下列条件,则称F为一个极小函数依赖集。亦称为最小依赖集或最小覆盖。

    1. F中任一函数依赖的右部仅含有一个属性。
    2. F中不存在这样的函数依赖X→A,使得F与F-{X→A}等价。
    3. F中不存在这样的函数依赖X→A, X有真子集Z使得F-{X→A}∪{Z→A}与F等价。 

    [例2] 关系模式S<U,F>,其中:
              U={ Sno,Sdept,Mname,Cno,Grade },
              F={ Sno→Sdept,Sdept→Mname,(Sno,Cno)→Grade }
             设F’={Sno→Sdept,Sno→Mname,Sdept→Mname,(Sno,Cno)→Grade,(Sno,Sdept)→Sdept}
    F是最小覆盖,而F’不是。
    因为:F ’ - {Sno→Mname}与F ’等价
              F ’ - {(Sno,Sdept)→Sdept}也与F ’等价       

    3.4.7 极小化过程

    定理:每一个函数依赖集F均等价于一个极小函数依赖集Fm。此Fm称为F的最小依赖集。
    证明: 构造性证明,找出F的一个最小依赖集。

    (1)逐一检查F中各函数依赖FDi:X→Y,若Y=A1A2 …Ak,k > 2,
        则用 { X→Aj |j=1,2,…, k} 来取代X→Y。

    (2)逐一检查F中各函数依赖FDi:X→A,令G=F-{X→A},
        若A \in XG+, 则从F中去掉此函数依赖。

    (3)逐一取出F中各函数依赖FDi:X→A,设X=B1B2…Bm,
        逐一考查Bi (i=l,2,…,m),若A \in(X-Bi )F+ ,
        则以X-Bi 取代X。

    [例3]  F = {A→B,B→A,B→C,A→C,C→A}
              Fm1、Fm2都是F的最小依赖集:
                      Fm1= {A→B,B→C,C→A}  
                      Fm2= {A→B,B→A,A→C,C→A} 

    • F的最小依赖集Fm不唯一
    • 极小化过程也是检验F是否为极小依赖集的一个算法

    [例4] 设关系模式R<A,B,C,D>,函数依赖集F={A→C,C→A, B→AC,D→AC,BD→A}
    求出F的最小函数依赖集。

    1. 将F中的函数依赖都分解为右部为单属性的函数依赖。
      F={A→C,C→A, B→A,B→C,D→A,D→C,BD→A}
    2. 去掉F中冗余的函数依赖。
      判断A→C是否冗余。
      设:G1={C→A,B→A,B→C,D→A,D→C,BD→A},得:A+ =A 
      ∵C  不属于A+ ∴A→C不冗余
      判断C→A是不冗余。
      设:G2={A→C,B→A,B→C,D→A,D→C,BD→A},得: C+ =C
      ∵A不属于 ∴C→A不冗余
      判断B→A是否冗余。
      设:G3={A→C,C→A,B→C,D→A,D→C,BD→A},得: B+ =BCA
      ∵A属于∴B→A冗余
      判断B→C是否冗余。
      设:G4={A→C,C→A, D→A,D→C,BD→A}, 得: B+ =B
      ∵C不属于  ∴B→C不冗余
      判断D→A是否冗余。
      设:G5={A→C,C→A, B→C,D→C,BD→A}, 得: D+ =DCA
      ∵A不属于   ∴D→A不冗余
      判断D→C是否冗余。
      设:G6={A→C,C→A, B→C,BD→A}, 得: D+ =D 
      ∵C不属于  ∴D→C不冗余
      判断BD→A是否冗余。
      设:G7={A→C,C→A, B→C,D→C}, 得: BD+ =BDCA
      ∵A属于  ∴BD→A冗余
      F={A→C,C→A,B→C,D→C}
    3. 由于各函数依赖在部都为单属性.故:
      Fm={A→C,C→A,B→C,D→C}。

    [例5] 设关系模式R<A,B,C,D,E,F>,函数依赖集F={AB→E,BC→D,BE→C,CD→B,CE→AF,CF→BD,C→A,D→EF},
    求F的最小函数依赖集。

     

    1. 将F中的函数依赖都分解为右部为单属性的函数依赖。
      F={AB→E,BC→D,BE→C,CD→B,CE→A,CE→F,CF→B,CF→D,C→A,D→E,D→F}
    2. 去掉F中冗余的函数依赖。
      判断AB→E是否冗余。
      设:G1={ BC→D,BE→C,CD→B,CE→A,CE→F,CF→B,CF→D,C→A,D→E,D→F}
      得: AB+ =AB
      ∵ E不属于AB+  ∴AB→E不冗余
      判断BC → D是否冗余
      设:G2={ AB→E,BE→C,CD→B ,CE→A,CE→F,CF→B,CF→D,C→A, D→E,D→F}、
      得: BC + =BCAEFD
      ∵ D属于BC +  ∴BC→D冗余
      判断BE→C是否冗余。
      设:G3={ AB→E,CD→B,CE→A ,CE→F,CF→B,CF→D,C→A,D→E,D→F}
      得: BE + =BE
      ∵ C不属于BE +  ∴BE→C不冗余
      判断CD → B是否冗余。
      设:G4={ AB→E,BE→C,CE→A ,CE→F,CF→B,CF→D,C→A,D→E,D→F}
      得: CD + =CDAEFB
      ∵ B属于CD +   ∴CD→B冗余
      判断CE → A是否冗余。
      设:G5={ AB→E,BE→C,CE→F,CF→B,CF→D,C→A,D→E,D→F}
      得: CE + =CEFBDA
      ∵ A属于CE +  ∴CE→A冗余
      判断CE → F是否冗余。
      设:G6={ AB→E,BE→C,CF→B,CF→D,C→A,D→E,D→F}、
      得: CE + =CEA
      ∵ F不属于CE +  ∴CE→F不冗余
      判断CF → B是否冗余。
      设:G7={ AB→E,BE→C,CE→F,CF→D,C→A,D→E,D→F}
      得: CF + =CFDEF
      ∵ B不属于CF +  ∴CF→B不冗余、
      判断CF→D是否冗余。
      设:G8={ AB→E,BE→C,CE→F,CF→B,C→A,D→E,D→F}
      得: CF + =CFABE
      ∵ D不属于CF +  ∴CF→D不冗余
      判断C→A是否冗余。
      设:G9={ AB→E,BE→C,CE→F,CF→B,CF→D,D→E,D→F}
      得: C + =C
      ∵ A不属于C +  ∴C→A不冗余
      判断D → E是否冗余。
      设:G10={ AB→E,BE→C,CE→F,CF→B,CF→D,C→A,D→F}
      得: D + =DF
      ∵ E不属于D +   ∴D→E不冗余
      判断D → F是否冗余。
      设:G11={ AB→E,BE→C,CE→F,CF→B,CF→D,C→A,D→E}
      得: D + =DE
      ∵ F不属于D +  ∴D→F不冗余
      F={ AB→E,BE→C,CE→F,CF→B,CF→D,C→A,D→E,D→F}
    3. 去掉F中冗余的属性。
      对于CF→D ,在决定因素中去掉C,D不属于属性F的闭包   不能以F→D代替CF→D;
      在决定因素中去掉F。 求得:CF=CA,D不属于属性C的闭包    不能以C→D代替CF→D
      同样验证AB→E, BE→C,CE→F,CF→B
      最终得到最小依赖集为
      {AB→E,BE→C,CE→F,CF→B,CF→D,C→A,D→E,D→F

    4. 模式的分解

    把低一级的关系模式分解为若干个高一级的关系模式的方法不是唯一的
    只有能够保证分解后的关系模式与原关系模式等价,分解方法才有意义

    4.1 关系模式分解

    三种模式分解等价的定义:

    1. 分解具有无损连接性
    2. 分解要保持函数依赖
    3. 分解既要保持函数依赖,又要具有无损连接性

    定义:关系模式R<U,F>的一个分解:ρ={ R1<U1,F1>,R2<U2,F2>,…,Rn<Un,Fn>}  ,且不存在  Ui \subseteq Uj,Fi 为 F在 Ui 上的投影

    定义:函数依赖集合{X→Y | X→Y \in F+∧XY \subseteq Ui} 的一个覆盖 Fi 叫作 F 在属性 Ui 上的投影

    例1: 已知R<U,F>,U={A,B,C,D}, F={A->BD, D->C}, 如果将R分解为R1(U1, F1)和R2(U2, F2), 其中U1={A,B,D}, U2={A,C}, 则F1,F2分别是?

    例:S-L(Sno, Sdept, Sloc)
            F={ Sno→Sdept,Sdept→Sloc,Sno→Sloc}
            S-L∈2NF  

    分解方法可以有多种:
    1. S-L分解为三个关系模式:SN(Sno)
                                                  SD(Sdept)
                                                  SO(Sloc)
    2.  S-L分解为下面二个关系模式:NL(Sno, Sloc)
                                                          DL(Sdept, Sloc)
    3. 将S-L分解为下面二个关系模式:ND(Sno, Sdept)
                                                            NL(Sno, Sloc)

    4.1.1

    S-L分解为三个关系模式:SN(Sno)
                                                  SD(Sdept)
                                                  SO(Sloc)

    • 分解后的数据库丢失了许多信息
    • 例如无法查询95001学生所在系或所在宿舍。
    • 如果分解后的关系可以通过自然连接恢复为原来的关系,那么这种分解就没有丢失信息

    4.1.2

    2.  S-L分解为下面二个关系模式:NL(Sno, Sloc)
                                                          DL(Sdept, Sloc)

    • NL∞DL比原来的SL关系多了3个元组无法知道95002、95004、95005究竟是哪个系的学生
    • 元组增加了,信息丢失了

    4.1.3

    3. 将SL分解为下面二个关系模式:
                   ND(Sno, Sdept)
                   NL(Sno, Sloc)
    分解后的关系为:

    与SL关系一样,因此没有丢失信息。

    4.1.4 具有无损连接性的模式分解

    • 关系模式R<U,F>的一个分解 ρ={ R1<U1,F1>,R2<U2,F2>, …,Rn<Un,Fn>} 若R与R1、R2、…、Rn自然连接的结果相等,则称关系模式R的这个分解ρ具有无损连接性(Lossless join)
    • 具有无损连接性的分解保证不丢失信息
    • 无损连接性不一定能解决插入异常、删除异常、修改复杂、数据冗余等问题

    第3种分解方法具有无损连接性

    问题:这种分解方法没有保持原关系中的函数依赖

    • SL中的函数依赖Sdept→Sloc没有投影到关系模式ND、NL上

    4.1.5 保持函数依赖的模式分解

    设关系模式R<U,F>被分解为若干个关系模式
    R1<U1,F1>,R2<U2,F2>,…,Rn<Un,Fn> 
    (其中U=U1∪U2∪…∪Un,且不存在Ui \subseteq Uj,Fi为F在Ui上的投影),若F所逻辑蕴含的函数依赖一定也由分解得到的某个关系模式中的函数依赖Fi所逻辑蕴含,则称关系模式R的这个分解是保持函数依赖的(Preserve dependency)

    4.将SL分解为下面二个关系模式:
                   ND(Sno, Sdept)
                   DL(Sdept, Sloc)
    这种分解方法就保持了函数依赖

    4.1.6 小结

    • 如果一个分解具有无损连接性,则它能够保证不丢失信息
    • 如果一个分解保持了函数依赖,则它可以减轻或解决各种异常情况
    • 分解具有无损连接性和分解保持函数依赖是两个互相独立的标准。具有无损连接性的分解不一定能够保持函数依赖;同样,保持函数依赖的分解也不一定具有无损连接性。

    第1种分解方法既不具有无损连接性,也未保持函数依赖,它不是原关系模式的一个等价分解
    第2种分解方法保持了函数依赖,但不具有无损连接性
    第3种分解方法具有无损连接性,但未持函数依赖
    第4种分解方法既具有无损连接性,又保持了函数依赖

    4.2 分解算法

    • 算法1 判别一个分解的无损连接性
    • 算法2 (合成法)转换为3NF的保持函数依赖的分解。
    • 算法3 转换为3NF既有无损连接性又保持函数依赖的分解
    • 算法4 (分解法)转换为BCNF的无损连接分解
    • 算法5 达到4NF的具有无损连接性的分解  

    4.2.1 算法1 判断一个分解的无损连接性

    (1)构造初始表:构造一个k行n列的初始表,其中每列对应于R的一个属性,每行用于表示分解后的一个模式组成。如果属性Aj属于关系模式Ri, 则在表的第一i行第j列置符号aj,否则置符号bij 。
    (2)根据F中的函数依赖修改表内容:  考察F中的每个函数依赖X→Y,在属性组X所在的那些列上寻找具有相同符号的行,如果找到这样的两行或更多的行, 则修改这些行,则使这些行上属性组Y所在的列上元素相同。

    • 修改规则是:如果y所在的要修改的行中有一个为aj, 则这些元素均变成aj;否则改动为bmj(其中m为这些行的最小行号)。
    • 注意:若某个bij被改动,则该列中凡是与bij相同的符号均做相同的改动。 循环地对F中的函数依赖进行逐个处理,直到发现表中有一行 变为a1,a2,…an或不能再被修改为止。

    (3)判断分解是否为无损联接:如果通过修改,发现表中有一行变a1,a2,… an,  则分解是无损联接的,否则分解不具有无损联接性。


    例1:

    简易方法:只画关注数据

    结果:具有无损连接性


    例2:

    设关系模式R(A,B,C,D,E,F),函数依赖集F={A→B,C→F,E→A,CE→A},将R分解为P={ABE,CDEF}。判断p是否是无损连接。

    (1) {A→B,C→F,E→A,CE→A}

    (2) {A→B,C→F,E→A,CE→A}

    结果:不具有无损连接性


    4.2.2 算法2 3NF+依赖保持

     

     


    5. 小结

    关系模式的规范化,其基本思想: 

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

    规范化理论为数据库设计提供了理论的指南和工具
    也仅仅是指南和工具

    并不是规范化程度越高,模式就越好
    必须结合应用环境和现实世界的具体情况合理地选择数据库模式

    展开全文
  • 数据库 - 关系模式函数依赖

    千次阅读 2015-05-07 09:09:45
    关系数据库逻辑设计 ...关系模式由五部分组成,即它是一个五元组: R(U, D, DOM, F) R: 关系名 U: 组成该关系的属性名集合 D: 属性组U中属性所来自的域 DOM: 属性向域的映象集合 F: 属性间数据的
  • (2)关系模式

    万次阅读 2019-08-24 22:04:48
    目录 1.关系模式数据结构 ...关系模式是一组织层数据模式。从数据模式三要素(数据结构,数据操作,数据完整性约束)来进行分析: 1.关系模式数据结构 关系模式用二维表来组织数据,这个二...
  • 关系模式规范化

    千次阅读 2019-03-22 21:26:43
    3NF规范化:通过该算法可以获得一个保持函数依赖性并满足3NF的关系模式分解 先求出Fmin 1、X->A,XA=R 那么XA单独构成一个关系模式 2、如果关系模式R中的某些属性与函数依赖集F的左右部属性均无关的话,将他们...
  • 数据库复习11——关系模式与范式

    千次阅读 2015-06-30 16:53:34
    数据库复习CH11 数据库模式(Schema)是数据库中全体数据的逻辑结构和特征的描述,关系型数据库的模式又叫关系模式,我所理解的关系模式就是数据库中表结构的定义以及多张表之间的逻辑联系关系模式的设计就是根据一...
  • Activity的四种启动模式应用场景

    万次阅读 2018-03-30 23:42:52
    在这金三银的时间里一个哥们忽然一本正经的问我Activity的启动模式和具体的应用模式;我也一想是啊,平是不太注意结果到了 关键的时刻卡壳了,感觉未雨绸缪一下,做个记录: Activity启动模式有四中: 1,...
  • ER图转关系模式

    千次阅读 2019-03-28 00:34:49
    一个m:n联系转换为一个关系模式,关系的码为各实体码的组合;一个1:n联系转换为一个关系模式,关系的码为n端实体的码;一个1:1联系转换为一个关系模式,关系的码为任意一端实体的码。 参考链接 ...
  • 关系模式的规范化

    万次阅读 多人点赞 2016-09-29 13:27:42
    原文路径:...了解关系模式规范化的作用 掌握第一范式-重点 掌握第二范式-重点 掌握第三范式-重点 回顾关系
  • 关系模式的规范化理论

    千次阅读 2019-05-11 19:43:44
    关系模式规范化的定义 到目前为止,规范化理论已经提出了六类范式。范式级别可以逐级升高,而升高规范化的过程就是逐步消除关系模式中不合适的数据依赖的过程,使模型中的各个关系模式达到某种程度的分离。一个低一...
  • 创建型模式 51.单例模式(Singleton)单例模式确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。eg.数据库。连接数据库很耗时,...
  • 关系模式及其范式

    千次阅读 2011-06-15 08:46:00
    关系的描述称为关系模式(Relation Schema)。一个关系模式应当是一个五元组。它可以形式化地表示为:R(U, D, DOM, F)。其中R为关系名,U为组成该关系的属性名集合,D为属性组U中属性所来自的域,DOM为属性向域的...
  • java 23设计模式详解

    万次阅读 多人点赞 2016-07-01 14:45:14
    设计模式的分类总体来说设计模式分为三大类:创建型模式,共五:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。结构型模式,共七:适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合...
  • 关系模式设计中的问题关系数据库设计要解决的主要问题 什么样的数据库模式才合理? 怎么分解才能满足要求? 衡量的标准是什么? 理论基础是什么? 如何进行实现? 关于好的数据库模式好的数据库模式是不会发生插入...
  • 函数依赖与关系模式分解的一些技巧整理

    万次阅读 多人点赞 2018-01-21 19:58:27
    函数依赖与关系模式分解的一些技巧整理 关系数据库设计理论的核心是数据间的函数依赖,衡量的标准是关系规范化的程度及分解的无损连接性和保持函 数依赖性。 数据依赖是通过一个关系中属性间值的相同与否体现...
  • 23设计模式全解析

    千次阅读 2015-07-09 18:02:25
    一、设计模式的分类 ...行为型模式,共十一:策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 其实还有两类
  • 数据库关系模式规范化

    千次阅读 2014-05-18 19:39:58
    第三范式的定义:如果关系模式R中的所有非主属性对任何候选关键字都不存在传递依赖,则称关系R是属于第三范式的。记作R 3NF。 如:学生关系模式S1(学号,姓名,系号,系名,系地址) (学号)为关键字,因是单属性...
  • 设计模式 | 适配器模式及典型应用

    万次阅读 多人点赞 2018-09-20 01:37:29
    适配器模式 ...在适配器模式中,我们通过增加一个新的适配器类来解决接口不兼容的问题,使得原本没有任何关系的类可以协同工作。 根据适配器类与适配者类的关系不同,适配器模式可分为对象适配器和类适...
  • ORM:对象关系映射 一:MTV开发模式 把数据存取逻辑、业务逻辑和表现逻辑组合在一起的概念有时被称为软件架构的Model-View-Controller(MVC)模式。 在这个模式中,Model 代表数据存取层,View 代表的是系统中选择...
  • 关系模式无损分解的测试方法

    千次阅读 热门讨论 2014-11-03 10:40:48
    关系模式无损分解的测试方法 上周在看数据库原理的时候,对于无损分解的测试方法,看完两遍还是不明其中的真意,和同学探讨了一下,此博文说说我的理解。  先明确无损分解中的“损”指的是信息的丢失。 分解的优点 ...
  • 一个优秀的关系模式的分解应当满足三个条件:消除异常(冗余、更新异常、删除异常),信息的可恢复以及依赖的保持。  对关系数 据库模式进行BCNF分解之后可以消除FD带来的冗余,并满足信息的可恢复(通过自然连接...
  • 关系模型潜在的问题 1.添加异常(当在关系中添加数据时可能会导致数据的不一致) 2.修改异常(随意的修改关系中的一行记录也可能导致数据的不一致) 3.删除异常(当删除一定数量的记录时可能会导致一些其他信息的...
  • Java中23设计模式的详细介绍

    千次阅读 多人点赞 2019-12-17 10:50:52
    Java开发中23设计模式详细介绍设计模式介绍设计模式分类设计模式六大原则开闭原则(Open Close Principle)里氏代换原则 ...项目中合理运用设计模式可以完美的解决很多问题,每种模式都有相应的原理...
  • 23设计模式总结

    万次阅读 多人点赞 2018-09-25 15:34:13
    【转】https://www.cnblogs.com/geek6/p/3951677.html 【转】https://www.cnblogs.com/tongkey/p/7170826.html 【转】... 总体来说设计模式分为三大类: 创建型模式,共五:工厂方法模式...
  • 关系模式设计的好与坏的区别

    千次阅读 2015-09-30 21:53:10
    一、关系模式应满足的基本条件 1.元组的每个分量必须是不可分的数据项 关系数据库特别强调,关系中的属性不能是组合属性,必须是基本项,并把这一要求规定为鉴别表格是否为“关系”的标准。 2.数据库中的数据冗余...
  • 近来翻了翻uC/OS-II官网给出来的ARM7-ARM9移植手册(AN-104),分析了在ARM中移植的问题,想想从来没有认真的学习过ARM的汇编,趁着这个机会复习复习吧。...在官网中提供的移植过程中存在异常处理机制,这个本不是在移

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 304,820
精华内容 121,928
关键字:

关系模式的四种异常问题