精华内容
下载资源
问答
  • 2020-03-31 00:06:23

    在这里插入图片描述

    一. 关系模式的设计问题

    1.1 数据依赖

    关系数据库是以关系模型为基础的数据库,它利用关系描述现实世界。一个关系既可用 来描述一个实体及其属性,也可用来描述实体间的一种联系。关系模式是用来定义关系的, 一个关系数据库包含一组关系,定义这组关系的关系模式的全体就构成了该数据库的模式。
    关系模式的核心问题是数据依赖性.数据依赖是对可能成为关系模式当前值的那些关系 的约束,是一个关系中属性(或属性组)与属性(或属性组)之间的相互依赖关系,是客观 存在着的语义。
    数据依赖是通过一个关系中属性间值的依赖与否体现出数据间的相互关系,它是现实世 界属性间相互联系的抽象 ,是数据内在的性质,是语义的体现。
    其中最重要的是函数依赖 (Functional Dependency,FD)和多值依赖(Multivalued Dependency, MVD)。

    1.2 数据依赖对关系模式的影响

    函数依赖普遍地存在于现实生活中。比如,描述一个学生的关系,可以有学号(Sno)、 姓名(Sname)、所在系(Sdept)等几个属性。由于一个学号只对应一个学生,一个学生只在一 个系。因而当“学号”值确定之后,姓名及其所在系的值也就被唯一地确定了。属性间的这 种依赖关系类似于数学中的函数

    理想的模式应当不会发生插入异常,删除异常,更新异常,数据冗余应尽可能少.一个关系 模式之所以会产生上述问题,是由存在于模式中的某些数据依赖引起的.规范化理论正是用 来改造关系模式,通过分解关系模式来消除其中不合适的数据依赖,以解决插入异常,删除 异常,更新异常和数据冗余问题

    二. 数据的函数依赖

    2.1 函数依赖

    2.1.1 函数依赖的定义

    设 R(U)是属性集 U 上的关系模式,X、Y 是 U 的一个子集。r 是 R(U)中的任意给定的 一个关系。若对于 r 中任意两个元组 s 和 t,当 s[X]=t[X]时,就有 s[Y]=t[Y],则称属性子集 X 函数决定属性子集 Y 或者称 Y 函数依赖于 X,否则就称 X 不函数决定 Y 或者称 Y 不函 数依赖于 X。

    1. 如果 Y 函数依赖于 X,则记为 X→Y。
    2. 如果 X→Y,则称 X 为决定因素( determinant)。
    3. 如果 X→Y,且 Y→X,则记为 X←→Y。
    4. 如果 Y 不函数依赖于 X,则记为 X↛Y。

    比如在学习生活中:

    学号→姓名(每个学号只能有一个学生姓名) 
    学号→系别(每个学号只能在一个系) 
    学号→图书证号(每个学号只能有一个图书证号) 
    系别→系主任(每个系只能由一名系主任
    

    2.1.2 函数依赖的3种基本情形

    (1)平凡与非平凡函数依赖

    如果 X→Y,但 Y 不是 X 的子集,则称 X→Y 是非平凡函数依赖(nontrivial functional dependency), 一般都讨论非平凡

    在关系 SC(Sno,Cno,Grade)中,
    非平凡函数依赖:(Sno,Cno) →Grade

    如果 X→Y,但 Y 是 X 的子集,则称 X→Y 是平凡函数依赖(nontrivial functional dependency)

    在关系 SC(Sno,Cno,Grade)中
    平凡函数依赖:(Sno,Cno) →Sno;(Sno,Cno) →Cno

    (2)部分与完全函数依赖
    如果 X→Y,但对于 X 中的任意一个真子集 X′,都有 Y 不依赖于 X′,则称 Y 完全依赖 ,记为 X F→ Y

    在关系 SC(Sno,Cno,Sname,Grade)中,
     完全函数依赖: (Sno,Cno) →Grade

    如果X→Y,但Y不完全函数依赖于X,则称Y对X部分函数依赖,记为 X P→ Y

    在关系 SC(Sno,Cno,Sname,Grade)中,
    部分函数依赖:(Sno,Cno) → Sname

    (3)传递与直接函数依赖

    在 R(U)中,如果 X→Y,(Y⊈X),Y↛X,Y→Z,则称 Z 对 X 传递函数依赖。记为 X 传递→ Z。 加上条件 Y↛X,是因为如果 Y→X,则 X←→Y,实际上是== X 直接→Z==,即直接函数依赖而不是传递函数依赖。

    指出关系 S (学号,姓名,图书证号,系别,系主任)中存在的传递函数依赖。 
    传递函数依赖:学号→系别, 系别→系主任,系主任传递函数依赖于学号

    2.2 函数依赖和码(关键字)的联系

    码是在关系模式 R 中,可以唯一标识一个元组的属性或属性组。

    从函数依赖的角度,给出码的形式化定义。 设 K 为关系模式 R<U,F>中的属性或属性组,若 K F→U 则 K 为 R 的候选码( Candidate Key),也简称为码(Key)

    关系模式的每个候选码具有下列两个特性:
    (1) 唯一性:在关系模式 R(U)中,K 为 R 的候选码,对于关系模式 R 对应的任何一个关 系 r,都不存在候选码属性值相同的两个元组,即候选码的取值是唯一的。
    (2) 最小特性:在关系模式 R(U)中,K 为 R 的候选码,在不破坏候选码的唯一性的情况 下,没有任何一个属性能从候选码里面删除。

    
    设 R(A,B,C,D,E),F={AB→CDE,E→ABCD},确定 R 的主属性及非 主属性。
    解:该关系模式有 2 个候选码:AB,E。所以 A、B、E 是主属性,C、D 是非主属性。

    2.3 最小函数依赖集

    函数依赖集 F 中包含若干个函数依赖,为了得到最为精简的函数依赖集,应该去掉其中平凡的,无关的函数依赖和多余的属性.
    条件

    (1)F 中的每一个函数依赖的依赖因素(右边)只含有单个属性。
    (2)F中没有冗余的函数依赖,即在F中不存在这样的函数依赖X→Y,使得F与F-{X→Y} 等价。
    (3)每个函数依赖的左边没有冗余的属性,即 F 中不存在这样的函数依赖 X→Y,X 有真 子集 W 使得 F-{X→Y}{W→Y}与 F 等价。

    设有关系模式 R(U,F),其中 U={A,B,C,D,E,G),F={AD→E,AC→E, BCD→AG,AB→G,A→C},求 F 的最小函数依赖集?

    第一步:将 F 中的所有的依赖因素化为单个属性。 AD→E,AC→E,BCD→A,BCD→G,AB→G,A→C
    第二步:去掉 F 中的冗余函数依赖。 (
    1)由于 F 中去掉 AD→E,得 F1={AC→E,BCD→A,BCD→G,AB→G,A→C}, AD F1+ =ACDE,包含 E,因此该函数依赖是冗余的,可以从 F 中去掉。
    (2)由于 F1中去掉 AC→E,得 F2={ BCD→A,BCD→G,AB→G,A→C},AC F2+ =AC, 不包含 E,因此该函数依赖不是冗余的,不能从 F1中去掉。
    (3) 由 于 F1 中 去 掉 BCD→A , 得 F3={AC→E , BCD→G , AB→G , A→C} , BCD F3+=BCDG,不包含 A,该函数依赖不是冗余的,不能从 F1中去掉。
    (4) 由 于 F1 中 去 掉 BCD→G , 得 F4={AC→E , BCD→A , AB→G , A→C} , BCD F4+ =ABCDEG,包含 G,因此该函数依赖是冗余的,可以从 F1中去掉。
    (5)由于 F4中去掉 AB→G,得 F5={ AC→E,BCD→A,A→C}, **AB F5+**=ABCE,不 包含 G,因此该函数依赖不是冗余的,不能从 F4中去掉。
    (6)由于 F4中去掉 A→C,得 F6={AC→E,BCD→A,AB→G}, A F6+=A,不包含 C, 因此该函数依赖不是冗余的,不能从 F4中去掉。 因此,F4={AC→E,BCD→A,AB→G,A→C}。
    第三步:去掉 F4中的所有决定因素的冗余属性。方法是在某个决定因素中去掉其中的 一个属性,看看是否依然能决定依赖因素。
    (1)对于 AC→E,若去掉 A,C 的闭包不含 E,故 A 不是冗余属性,不能去掉;若去掉 C,A 的闭包含 E,故 C 是冗余属性,可以去掉。
    (2)对于 BCD→A,若去掉 B,CD 的闭包不含 A,故 B 不是冗余属性,不能去掉;同理 C 和 D 也不是冗余属性。
    3)对于 AB→G,若去掉 A,B 的闭包不含 G,故 A 不是冗余属性,不能去掉,同理 B 也不是冗余属性。 因此,Fm={A→E,BCD→A,AB→G,A→C}

    结论:
    F 与它的最小函数依赖集是等价的。
    由于在求解过程中对属性和函数依赖的 处理顺序的关系,
    因此每个函数依赖集 F 不一定只有一个最小函数依赖集!

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

    更多相关内容
  • 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

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

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

    展开全文
  • 数据依赖是一个关系内部属性与属性之间的一约束关系,这种关系是通过属性间值的相等与否体现的数据相关的关系。 多种类型的数据依赖:函数依赖和多值依赖 例如: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)

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

    期初余额本期发生额期末余额
    借方贷方借方贷方借方贷方
    122355355635
    1344355343535566
    24524535565353

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

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

     

    第二范式(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

    SnoSnameSsexSage
    a valueb1 valuec valued value
    a2 valueb2 valuec2 valued2 value
    an valuebn valuecn valuedn 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 , D O M , F ) R(U, D, DOM, F) R(U,D,DOM,F)

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

    把关系模式看作一个三元组: R < U , F > 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 的闭包
    在这里插入图片描述
    实例:

    在这里插入图片描述

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

    千次阅读 2019-04-20 17:41:41
    1.     为什么要研究数据库关系模式的分解? 答:因为现有的模式可能会...因此为了完善数据库的增删改查的功能,需要寻找一等价的关系模式,使得以上弊端得以解决。 2.  &nb...
  • 异常的几处理方式

    千次阅读 2021-08-22 11:52:14
    异常的声明不能从根本上解决问题 声明一个编译时异常类型之后,系统不会在编译期间检查这段代码,但是在运行阶段,如果传入的数据不正确,也有可能出现错误情况 异常的声明只能处理编译时异常 ...
  • 本文借鉴了范式的作用:... 如果一个关系模式R的所有属性都是不可分的基本数据项,则R∈1NF。 数据库表中的字段都是单一属性的,不可再分。这个单一属性由基本类型构成,包括整型、实数、字符型、逻辑型、日期..
  • 数据库系统原理-函数依赖和关系模式分解 目录数据库系统原理-函数依赖和关系模式分解第一范式如何处理非原子值原子性关系数据库设计中易犯的错误模式分解无损连接分解优化关系模式的步骤函数依赖函数依赖定义函数...
  • 数据库原理-关系模式的规范化

    千次阅读 2021-08-26 12:29:02
    常、删除异常、修改复杂、数据冗余等问题,解决方法就是对其进行规范化, 转换成高级范式。 一个低一级范式的关系模式,通过模式分解可以转换为若干个高一级范式的 关系模式集合,这种过程就叫关系模式的规范化。 1....
  • 关系模式的范式(带例题详细解析)

    万次阅读 多人点赞 2020-08-09 19:11:57
    一些概念 1.码:码是一个或多个属性的集合,是唯一标识实体的属性 2.超码:一个或多个属性的集合,超码中的属性可以在一个实体集中唯一地标识一个实体 ...如果关系模式R中所有的属性均为原子属性,即每个属性都是
  • 关系模式

    千次阅读 2019-09-17 21:46:58
    关系模式 第一范式(1NF):关系模式 R 的每一个分量是不可再分的数据项,则关系模式 R 属于第一范式。 第二范式(2NF):若关系范式 R∈1NFR\in1NFR∈1NF ,并且每一个非主属性完全依赖于码,则关系模式 R∈2NFR\in...
  • 关系模式的规范化

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

    千次阅读 多人点赞 2020-10-28 19:13:56
    关系数据库中的关系满足一定要求的,满足不同程度要求的为不同的范式。满足最低要求的叫第一范式,简称1NF;在第一范式的基础上满足进一步要求的称为第二范式,简称2NF,其余范式以此类推。对于各种范式之间有如下...
  • 数据库题目之关系数据理论

    千次阅读 多人点赞 2019-01-10 15:14:46
    一、选择题 1、关系规范化中的删除操作异常是...2、设计性能较优的关系模式称为规范化,规范化主要的理论依据是 。  A.关系规范化理论 B.关系运算理论 C.关系代数理论 D.数理逻辑 【答案:】A 3、规范化...
  • 关系模型潜在的问题 1.添加异常(当在关系中添加数据时可能会导致数据的不一致) 2.修改异常(随意的修改关系中的一行记录也可能导致数据的不一致) 3.删除异常(当删除一定数量的记录时可能会导致一些其他信息的...
  • [MySQL]关系规范化中的操作异常理解

    千次阅读 2019-01-02 19:25:58
    插入失败:该插入的没插入; 插入异常:不该插入的被插入; 删除失败:该删除的没删除; 删除异常:不该删除的被删除; 简单地说:失败:有心栽花花不开,异常:无心插柳柳成荫...
  • 函数依赖和关系模式分解

    千次阅读 2020-06-23 10:11:40
    文章目录一,第一范式关系数据库设计中易犯的错误数据冗余插入、删除、修改异常模式分解函数依赖(FD)函数依赖的...如果关系模式R中的所有属性的域是原子的,则R称为属于第一范式(1NF) 非原子值存储复杂并易导致数
  • 在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系型数据库。 例如,这样是符合的:student(id,name,age,class) 而这样就不符合:student(id,...
  • 【单选题】关系模式中数据依赖问题的存在,可能会导致库中数据插入异常,这是指( )。 A插入了不该插入的数据 B数据插入后导致数据库处于不一致状态 C该插入的数据不能实现插入 D以上都不对 填空题 判断题 35 【判断题...
  • 数据库 - 关系模式函数依赖

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

    千次阅读 2019-03-22 21:26:43
    3NF规范化:通过该算法可以获得一个保持函数依赖性并满足3NF的关系模式分解 先求出Fmin 1、X->A,XA=R 那么XA单独构成一个关系模式 2、如果关系模式R中的某些属性与函数依赖集F的左右部属性均无关的话,将他们...
  • 1:求关系模式候选码的方法 设关系模式R中的属性集U=ABC…,有N个属性,判断U中属性在FD中出现的位置 (1)左右出现; (2)只在左部出现; (3)只在右部出现; (4)不出现; 方法:按以下几步来求候选键 1.只在FD右部出现的属性...
  • 第1节 关系模型的好坏 ER模型转换的关系是否...如果存在冗余,就需要对关系模式进行优化。 主要优化技术: 模式分解 (比如, ABCD 用 AB和BCD, 或者 ACD 和 ABD替代)。 如何正确地使用模式分解: 是否有必要分解一
  • 关系模式的规范化理论

    千次阅读 2019-05-11 19:43:44
    关系模式规范化的定义 到目前为止,规范化理论已经提出了六类范式。范式级别可以逐级升高,而升高规范化的过程就是逐步消除关系模式中不合适的数据依赖的过程,使模型中的各个关系模式达到某种程度的分离。一个低一...
  • 常用的几设计模式详解

    千次阅读 2021-04-09 15:01:27
    设计模式的概述 设计模式分类 创建型模式 特点是将对象的创建与使用分离(解耦),有 单例、原型、工厂方法、抽象工厂、建造者等5。 结构型模式 用于描述如何将类或对象按某种布局组成更大的结构,代理、...
  • 快速梳理23常用的设计模式

    千次阅读 多人点赞 2018-11-17 22:54:34
    本文旨在快速梳理常用的设计模式,了解每个模式主要针对的是哪些情况以及其基础特征,每个模式前都有列举出一个或多个可以深入阅读的参考网页,以供读者详细了解其实现。 快速回忆 一、创建型 单例(Singleton...
  • Activity的四种启动模式应用场景

    万次阅读 2018-03-30 23:42:52
    在这金三银的时间里一个哥们忽然一本正经的问我Activity的启动模式和具体的应用模式;我也一想是啊,平是不太注意结果到了 关键的时刻卡壳了,感觉未雨绸缪一下,做个记录: Activity启动模式有四中: 1,...
  • 一、ARM处理器的7工作模式用户模式(USR):正常程序执行模式,不能直接切换到其他模式系统模式(SYS):运行操作系统的特权任务,与用户模式类似,但具有可以直接切换到其他模式等特权快中断模式(FIQ):支持...
  • 数据库复习11——关系模式与范式

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

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 346,125
精华内容 138,450
关键字:

关系模式的四种异常问题