精华内容
下载资源
问答
  • 关系模式的冗余和异常问题 数据冗余:同一数据在系统中重复出现,在数据库管理中,数据冗余一直是影响系统性能的大问题。 操作异常:由于数据冗余,对数据库的操作会引起各种异常(修改异常,插入异常,删除异常)...

    概念理解

    术语定义:范式是符合某一种级别的关系模式的集合

    通俗理解:相当于一个衡量数据库表关系模式设计优劣的一个标准,同教师的职称有初级、中级、高级、特级等等一样,范式同样分为几个级别

    关系模式的冗余和异常问题

    数据冗余:同一数据在系统中重复出现,在数据库管理中,数据冗余一直是影响系统性能的大问题。

    操作异常:由于数据冗余,对数据库的操作会引起各种异常(修改异常,插入异常,删除异常)

    范式

    由于关系模式的各种问题,所以就出现了一个衡量数据库关系模式的标准也就是范式

    第一范式(1NF)

    定义:数据库表中的字段都是单一属性的,不可再分的(段是最小的单元不可再分)

    1NF是关系模式应具备的最起码的条件

    第二范式(2NF)

    定义:在满足第一范式的情况下,且每个非主属性完全依赖于候选键

    理解这句话的时候,我们先理解一下其中的一些名词

    码(候选键):

    设 K 为某表中的一个属性或属性组,若除 K 之外的所有属性都完全函数依赖于 K(这个“完全”不要漏了),那么我们称 K 为候选码(候选键),简称为。在实际中我们通常可以理解为:假如当 K 确定的情况下,该表除 K 之外的所有属性的值也就随之确定,那么 K 就是码

    非主属性:包含在任何一个码中的属性成为主属性,其他的称为非主属性

    第三范式(3NF)

    定义:在满足第二范式的情况下,且每个非主属性都不传递对于码的函数依赖
     

    实例

    1、分析上表可知,上表属于第一范式(关系中的每个属性不可再分),但有许多问题,比如,数据冗余、插入异常、删除异常、修改异常等等

    2、现在我们将其规范到第二范式,即 达到每个非主属性完全依赖于候选键,大致有四个步骤。

    第一步:找出表中所有的码

     

    方法是当找出的码值确定,其他的数据也就确定了,可知码为(学号,课名)

    第二步:根据上一步找出的码,确定主属性

    码为(学号,课名),所以主属性为学号和课名

    第三步:根据表中,去除所有的主属性,剩下的就是非主属性了

    根据主属性学号和课名,可知非主属性为姓名、系名、系主任和分数

    第四步:查看是否存在非主属性对码的部分函数依赖

    对于(学号,课名) → 姓名,有 学号 → 姓名,存在非主属性 姓名 对码(学号,课名)的部分函数依赖

    对于(学号,课名) → 系名,有 学号 → 系名,存在非主属性 系名 对码(学号,课名)的部分函数依赖

    对于(学号,课名) → 系主任,有 学号 → 系主任,存在非主属性 系主任 对码(学号,课名)的部分函数依赖

    第五步:如果存在非主属性对码的部分函数依赖,将大数据表拆分成两个或者更多个更小的数据表

    下图表示了模式分解以后的新的函数依赖关系

     

    下图表示模式分解以后新的数据

     上述模式虽然有改进,但是仍然存在一些问题如

    1、当删除学生信息时候,把系别信息也删除了

    2、当插入新的系别时,由于没有学生信息,所以插入异常

    所以说,仅仅符合2NF的要求,很多情况下还是不够的,而出现问题的原因,在于仍然存在非主属性系主任对于码学号的传递函数依赖。为了能进一步解决这些问题,我们还需要将符合2NF要求的数据表改进为符合3NF的要求。

    对于学生表,主码为学号,主属性为学号,非主属性为姓名、系名和系主任。因为 学号 → 系名,同时 系名 → 系主任,所以存在非主属性系主任对于码学号的传递函数依赖,所以学生表的设计,不符合3NF的要求

    为了让数据表设计达到3NF,我们必须进一步进行模式分解为以下形式:

    选课(学号,课名,分数)

     学生(学号,姓名,系名)

    系(系名,系主任)

    转载于:https://www.cnblogs.com/luxiaojun/p/8509225.html

    展开全文
  • 3.1.1 关系模式的冗余和异常问题 “分解”是解决冗余的主要方法,也是规范化的一条原则:“关系模式有冗余问题,就分解它”。 3.1.2 关系模式的非形式化设计准则 准则3.1 关系模式的设计应尽可能只包含直接...

    3.1 关系模式的设计准则

    3.1.1 关系模式的冗余和异常问题

    “分解”是解决冗余的主要方法,也是规范化的一条原则:“关系模式有冗余问题,就分解它”。

    3.1.2 关系模式的非形式化设计准则

    准则3.1 关系模式的设计应尽可能只包含直接联系的属性,不要包含有间接联系的属性。

    准则3.2 关系模式的设计应尽可能使得相应关系中不出现插入、删除和修改等操作异常现象。

    准则3.3 关系模式的设计应尽可能使得相应关系中避免放置经常为空值的属性。

    准则3.4 关系模式的设计应尽可能使得关系的等值连接在主键和外键上进行,并且保证连接以后不会生成额外的元组。

    3.2 函数依赖

    3.2.1 函数依赖的定义

    定义3.1 设有关系模式R(U)XY是属性集U的子集,函数依赖(functional dependency,简记为FD)是形为X→Y的一个命题,只要r是R的当前关系,对r中任意两个元组t和s,都有t[X]=s[X]蕴涵t[Y]=s[Y],那么称FD X→Y在关系模式R(U)中成立。

    这里t[X]表示元组t在属性集X上的值,其余类同。X→Y读作“X函数决定Y”,或“Y函数依赖于X”。FD是对关系模式R的一切可能的关系r定义的。对于当前关系r的任意两个元组,如果X值相同,则要求Y值也相同,即有一个X值就有一个Y值与之对应,或者说Y值由X值决定。因而这种依赖称为函数依赖。

    定义3.2 如果X→Y和Y→X同时成立,则可记为X←→Y。也就是在关系中,X值和Y值具有一一对应关系。

    3.2.2 FD逻辑蕴涵

    3.2.3 FD的推理规则

    3.2.4 FD和关键码的联系

    3.2.5 属性集的闭包

    3.2.6 FD集的最小依赖集

    3.3 关系模式的分解特性

    3.3.1 关系模式的分解

    3.3.2 无损分解

    3.3.3 模式分解的优缺点

    3.3.4 无损分解的测试方法

    3.3.5 保持FD的分解

    3.3.6 模式分解与模式等价问题

    数据等价是指两个数据库实例应表示同样的信息内同,用“无损分解”衡量。

    依赖等价是指两个数据库模式应有相同的依赖集闭包。

    3.4 范式

    关系模式的好与坏,用什么标准衡量?这个标准就是模式的范式(Normal Forms,简记为NF)。

    3.4.1 第一范式(1NF)

    定义3.1.6 如果关系模式R中的每个关系r的属性值都是不可分的原子值,那么称R是第一范式(First Normal Form,简记为1NF)的模式。

    3.4.2 第二范式(2NF)

    定义3.18 如果A是关系模式R的候选键属性,那么称A是R的主属性;否则称A是R的非主属性。

    定义3.19 如果关系模式R是1NF,且每个非主属性完全函数依赖于候选键,那么称R是第二范式(2NF)的模式。如果数据库模式中每个关系模式都是2NF,则称数据库模式为2NF的数据库模式。

    3.4.3 第三范式(3NF)

    定义3.21 如果关系模式R是1NF,且每个非主属性都不传递依赖于R的候选键,那么称R是第三范式(3NF)的模式。如果数据库模式中每个关系模式都是3NF,则称数据库模式为3NF的数据库模式。

    3.4.4 BCNF

    定义3.23 如果关系模式Rshi 1NF,且每个属性都不传递依赖于R的候选键,那么称R是ECNF的模式。

    定义3.24 设F是关系模式R的FD集,如果对F中每个非评分的FD →Y,都有X是R的超键,那么称R是BCNF的模式。

    3.4.5 分解成BCNF模式集的分解算法

    3.4.6 分解成3NF模式集的合成算法

    3.4.7 模式设计方法小结

    3.5 多值依赖和第四范式

    3.5.1 多值依赖

    定义3.25 设U是关系模式R的属性集,X和Y是U的字节,Z=R-X-Y,小写xyz表示属性集XYZ的值。对于R的关系r,在r中存在元组(x,y1,z1)和(x,y2,z2)时,就也存在(x,y2,z1)和(x,y1,z2),那么称多值依赖(Multivalued Dependency,简记为MVD)X→→Y在模式R上成立。

    3.5.2 关于FD和MVD的推理规则集

    3.5.3 第四范式(4NF)

    定义3.28 设D是关系模式R上成立的FD和MVD集合。如果D中每个非平凡的MVD

    X→→Y的左部X都是R的超键,那么称R是4NF的模式。

    <!--EndFragment-->
    展开全文
  • 目的:解决关系模式中存在的数据冗余、插入和删除异常、删除异常、更新异常问题。 其基本思想是消除数据依赖中的不合适部分,使各关系模式达到某种程度的分离,使一个关系描述一个概念、一个实体或实体间的一种...

    在学习数据库知识的同时,梳理知识,也便于以后查找

    关系模式规范化

    目的:解决关系模式中存在的数据冗余、插入和删除异常、删除异常、更新异常等问题。
    其基本思想是消除数据依赖中的不合适部分,使各关系模式达到某种程度的分离,使一个关系描述一个概念、一个实体或实体间的一种联系。

    规范化的实质是概念的单一化。

    关系范式

    目前只要有六种范式。满足最低要求的叫第一范式,简称1NF。
    各范式之间存在的联系为前面的是后面的范式的真子集。
    一个低一级范式的关系模式,通过模式分解可以转换为若干个高一级范式的关系模式的集合,这个过程称为规范化。

    • 第一范式,每个属性都不可分
    • 第二范式,满足第一范式,且每个非主属性都完全函数依赖于码(候选码),则称R为满足第二范式的关系模式。
      • 在一个关系中,包含在任何候选码中的各个属性称为主属性,不包含在任何候选码中的主属性称为非主属性。
    • 第三范式,属于第二范式且没有一个非主属性传递函数依赖于码.
      • 如果关系模式属于1NF,且它每一个非主属性既不部分也不传递函数依赖于码,则属于3NF。
      • 不存在非主属性的关系模式一定属于3NF。
    展开全文
  • 第1节 关系模型的好坏 ER模型转换的关系是否...如果存在冗余,就需要对关系模式进行优化。 主要优化技术: 模式分解 (比如, ABCD 用 AB和BCD, 或者 ACD 和 ABD替代)。 如何正确地使用模式分解: 是否必要分解一

    第1节 关系模型的好坏

    • ER模型转换的关系是否就是最优的关系?不一定。

      关系模型潜在的问题:

      • 添加异常
    • 修改异常

      • 删除异常
      • 数据冗余

    冗余

    • 当数据的某些部分能由其他部分推导出来,就意味着存在冗余
    • 冗余的存在是因为存在完整性约束

    如何解决冗余问题

    • 由于存在约束,特别是函数依赖,导致冗余的产生。
    • 如果存在冗余,就需要对关系模式进行优化。
      • 主要优化技术: 模式分解 (比如, ABCD 用 AB和BCD, 或者 ACD 和 ABD替代)。
    • 如何正确地使用模式分解:
      • 是否有必要分解一个模式?
      • 分解以后会不会出现什么问题?

    如何评价一个关系是好的还是坏的?

    • 坏关系到好关系

      • 对关系模式进行优化
      • 主要优化技术:模式分解(比如ABCD用AB和BCD,或者ACD和ABD代替)

    第2节 函数依赖的概念

    • 函数依赖概念
      • 函数依赖可形式化表示为X->Y, 其中X and Y是属性集
      • 例如:rating->hrly_wage, AB->C
      • 如果对于关系实例r中的任意一对元组t1和t2,有t1.X = t2.X逻辑蕴含t1.Y = t2.Y,那么函数依赖X->Y在关系r中成立
      • 即关系r中给定两个元组,如果X属性值相等则Y的值也必须相等(X和Y是属性集)
      • 如果对关系R中的每个实例r,都满足函数依赖,则该函数依赖在关系R上成立。
        • 函数依赖必须由应用的语义所决定。
        • 对于给定关系R的某实例r,我们能判断它是否违反了某个函数依赖。
        • 但是不能仅仅根据一个满足函数依赖的实例来断定该函数依赖在关系模式R上成立。
    • 函数依赖起到检测冗余是否存在的作用

    完全函数依赖

    在一张表中,若 XYX \rightarrow Y,且对于 X 的任何一个真子集(假如属性组 X 包含超过一个属性的话),XYX' \rightarrow Y 不成立,那么我们称 Y 对于 X 完全函数依赖,记作 XFYX\mathop{\rightarrow}\limits ^F Y

    例如:

    • 学号F\mathop{\rightarrow}\limits ^F姓名
    • (学号,课名) F\mathop{\rightarrow}\limits ^F分数 (注:因为同一个的学号对应的分数不确定,同一个课名对应的分数也不确定)

    部分函数依赖

    假如 Y 函数依赖于 X,但同时 Y 并不完全函数依赖于 X,那么我们就称 Y 部分函数依赖于 X,记作 XPYX \mathop{\rightarrow}\limits ^P Y

    例如:

    • (学号,课名) P\mathop{\rightarrow}\limits ^P姓名

    主属性

    包含在任意一个码中的属性称为主属性。

    非主属性

    不包含在任何一个码中的属性称为非主属性。

    第3节 范式和Armstrong公理

    范式

    如果一个关系满足一种范式(BCNF,3NF等),就能判断该关系模式是否避免了某类问题。这样就能知道该关系是否需要分解。

    • 任何符合BCNF的关系也符合 2NF

    第一范式(1NF)

    • 每个属性都是原子属性
    • 本质上所有关系都满足第一范式

    第二范式(2NF)

    • 任何满足第二范式的关系满足第一范式
    • 所有非主属性必须依赖于整个主码而不能依赖于主码的部分属性
    • 例如:关系模式 Inventory(part, warehouse, quantity,warehouse_address).
      假设 {part, warehouse}是主码. warehsouse_address 单独依赖于 warehouse -则违反了第二范式。 解决方法: 分解关系模式

    第三范式(3NF)

    • 任何符合BCNF的关系也符合 3NF
    • 符合3NF要求的数据库设计,基本上解决了数据冗余过大,插入异常,修改异常,删除异常的问题。
    • 有一些情况
      • BCNF 不能保持函数依赖,
      • 在更新上有效的检查函数依赖是否违背是非常重要的。
    • 解决方法: 定义一个弱的关系, 叫做第三范式 (3NF)
      • 允许存在一些冗余

      • 函数依赖是否保持可以在单独的关系上检查,而不需要进行连接计算.

      • 3NF一般是保持无损连接分解和保持函数依赖

    • R符合BCNF, 那么R符合3NF
    • 如果 R 符合 3NF, 可能会存在一定的冗余,它是分解和性能的一种折中
    • 将R分解为满足3NF的关系集合,是保持了无损连接分解和保持函数依赖的
    3NF分解
    • 显然, 分解为BCNF的无损连接分解的算法能够用来获取无损连接分解的3NF.
    • 为了保持函数依赖, 一个思想是:
      • 如果 X → Y 不保持, 增加关系XY.
      • 问题是XY可能会违背 3NF!
    • 细化: 不考虑 FDs F, 而是使用F的最小的函数依赖集.

    图片42

    3NF分解算法的其它例子

    图片43

    Boyce-Codd 范式(BCNF)

    • 对于 R 有函数依赖集 FDs F ,如果R符合BCNF 当且仅当每一个非平凡的 FD

      • X → A in F , X 是R的超键 (i.e., X → R in F+).

      • 对于 FD X → A 是平凡的,当且仅当 A ⊆ X.

    • 也就是说, R 符合BCNF 当且仅当非平凡的FDs 箭头左侧是键.
      BCNF:

    • R中没有数据能够使用FDs预测.

    • Why:

      • X是超键, 不会有两个元组的X值相同
    • 如果R只有两个属性, 那么它符合BCNF

    • 如果F只包括R中的属性:

      • R 符合BCNF 当且仅当每一个F中的函数依赖 X → Y (not F+!), X 是 R的超键, i.e., X → R is in F+ (not F!).
    BCNF的检测
    • 列出所有的非平凡函数依赖
    • 确认每一个函数依赖箭头左边的属性集是R的超键。
    • 注意:我们需要首先找出R的超键!

    例:Courses(course_num, dept_name, course_name, classroom, enrollment, student_name, address) 符合BCNF?
    FDs 包括:

    • course_num, dept_name → course_name

    • course_num, dept_name → classroom

    • course_num, dept_name → enrollment

    那么(course_num, dept_name)+?

    • {course_num, dept_name, course_name, classroom, enrollm ent}
      Therefore, the key is {course_num, dept_name, student_name}

    不符合BCNF

    BCNF范式分解
    • 当一个关系不符合BCNF: 那么分解它.
    • 假定关系R 包含属性A1 … An. R的分解会分解为两个或者多个关系:
      • 每个新的关系的属性为R属性的子集 (不会有属性不属于 R), 并且R 中的每一个属性至少会在一个新的关系中.
    • 考虑关系R 和函数依赖集 FDs F. 如果F中的函数依赖 X → A 违背 BCNF, 那么: 分解R 为R – A 和XA.
    • 重复这个思想,我们会得到一个符合BCNF的关系集合.
    • 保持无损连接分解。
    将关系模式R<U,F>分解为一个BCNF的基本步骤

    image-20200608143938557

    快速求候选码的方法

    首先对于给定的R(U)和函数依赖集F,可以将它的属性划分为4类:

    • L类,仅出现在F的函数依赖左部的属性。
    • R类,仅出现在F的函数依赖右部的属性。
    • N类,在F的函数依赖左部和右部均未出现的属性。
    • LR类,在F的函数依赖左部和右部两部均出现的属性。

    根据以下定理和推论来求解候选码。

    • 定理1:对于给定的关系模式R及其函数依赖集F,若X(X∈R)是L类属性,则X必为R的任一候选码的成员。
    • 推论1:对于给定的关系模式R及其函数依赖集F,若X(X∈R)是L类属性,且X+包含了R的全部属性,则X必为R的唯一候选码。
    • 定理2:对于给定的关系模式R及其函数依赖集F,若X(X∈R)是R类属性,则X不在任何候选码中。
    • 定理3:设有关系模式R及其函数依赖集F,如果X是R的N类属性,则X必包含在R的任一候选码中。
    • 推论2:对于给定的关系模式R及其函数依赖集F,如果X是R的N类和L类组成的属性集,且X+包含了R的有属性,则X是R的唯一候选码。

    例:

    如设有关系模式R(U),其函数依赖集为F,其中:U={A,B,C,D,E}, F={A→C,C→A,B→AC,D→AC} 求R的候选码。
    解:
    根据函数依赖可得:
    属性B、D为L类,E为N类,因此属性B、D、E必为候选码的成员,
    且此三个属性的闭包:B+=ABC,(BD)+=ABCD,(BDE)+=ABCDE,根据推论2可得BDE是R的唯一候选码。
    所以R的候选码为BDE。
    

    如果把例题中关系模式R(U)中的属性E去掉,那么再求R的候选码的话可以根据推论1得出BD为R的唯一候选码。

    快速求解方法适用于判断有属性是属于L类、N类或其中一种的情况下求解。如果有L类和N类的属性,则求解候选码速度非常快。

    简而言之:

    L、R、N、LR类。根据定理,L、N类必为侯选码之一,如果L+包含全部R,则L为唯一侯选。R类不在任何侯选码中。

    L+N类且(L+N)+包含所有R,则L+N为唯一侯选。(适于有L、N类至少一种的情况。)

    例题:
    设有关系模式R(A,B,C,D,E),其函数依赖集F={A→BC,CD→E,B→D,E→A},求R的所有候选码。
    解:
    (1)Fm={A→B, A→C,CD→E,B→D,E→A}
    (2)A,B,C,D,E五个属性在F中各个函数依赖的右边和左边都出现了,所以候选码中可能包含A,B,C,D,E。
    (3)A+=ABCDE,即A→U,所以A是一个候选码   B+,C+,D+→U,所以B,C,D不是候选码   E+=ABCDE,即E→U,所以也E是一个候选码
    (4)除去A,E两个候选码,在B,C,D中查找两个属性的候选码   (BC)+=ABCDE,即BC→U,所以BC是一个候选码   (BD)+=BD,即BC→U,所以BD不是一个候选码   (CD)+=ABCDE,即CD→U,所以CD是一个候选码
    候选码有:A,E,BC,CD
    

    BCNF 和 依赖保持

    • 分解得到的关系,符合BCNF,但可能不满足保持函数依赖.
    • 例子: 关系CSZ (city, street_name, zip_code) 函数依赖 FDs: CS → Z, Z → C
      (city, street_name) → zip_code
      zip_code → city
    • 要保持CS → Z,则不能分解, 但是CSZ 不符合BCNF.

    函数依赖理论:Armstrong公理

    从一个给定的函数依赖集推导出它所逻辑蕴含的所有函数依赖

    图片28

    图片29

    图片30

    第4节 函数依赖集

    4.1 函数依赖和键

    • 给定R(A,B,C)

      • A->ABC意味着A是一个键(码)
    • 通常,

      • X → R 意味着 X 是一个超键.
    • 键的约束

      • ssn → did

    图片31

    4.2 函数依赖集的闭包F+

    • 函数依赖集的闭包?由F逻辑蕴含的所有函数依赖的集合
    • 计算函数依赖集的闭包:

    图片32

    F+例子

    F = {A → B, B → C, C D → E }

    • Step 1: F中的每一个函数依赖, 使用自反律
      • 得到:CD → C; CD → D

      • 加到F上: F = {A → B, B → C, C D → E; CD → C; CD → D }

    • Step 2: F中的每一个函数依赖, 使用增补率
      • A → B 得到: A → AB; AB → B; AC → BC; AD→ BD; ABC →BC; ABD → BD; ACD →BCD
      • B → C 得到: AB → AC; BC → C; BD → CD; ABC → AC; ABD → ACD, etc.
    • Step 3: 使用传递率
    • 重复1~3步骤…

    可以看出计算F+代价太高.

    4.3 求最小依赖集

    关系模式R(U,F)中,R=ABCDEG F={BE→G,BD→G,CD→A,CE→G,CDE→AB,BC→A,B→D}

    1. 首先把右边的属性都变成单个属性

      函数依赖集F={BE→G,BD→G,CD→A,CE→G,CDE→A,CDE→B,BC→A,B→D}

    2. 对于函数依赖F中的每个函数X->A,设G=F-{X->A},如果A属于关于函数依赖集G的闭包,将X->A从F中删除,否则保留,然后得出新的F。

      BE+=BEDG,包含G,删除。

      BD+=BD,不包含G,保留。

      CD+=CD,不包含A,保留。

      CE+=CE,不包含G,保留。

      CDE+=CDEAGBA,包含A,删除。

      CDE+=CDEAG,不包含B,保留。

      BC+=BCDGA,包含A,删除。

      B+=B,不包含D,保留。

      得到新的F={BD→G,CD→A,CE→G,CDE→B,B→D}

    3. 对于F中每一个左端包含多个属性的X->A(即去掉各依赖左部多余的属性。一个一个地检查函数依赖左部非单个属性的依赖),选择X的每个子集Z,如果A属于Z的闭包,则用Z->A代替X->A。

      BD→G:B+=BDG,包含G,去掉;D+=D,不包含G,保留。

      CD→A:C+=C,不包含A,保留;D+=D,不包含A,保留。

      CE→G:C+=C,不包含G,保留;E+=E,不包含G,保留。

      CDE→B:C+=C,不包含B,保留;D+=DG,不包含B,保留;E+=E,不包含B,保留。

    最后得出关系模式R(U,F)的最小依赖集Fm={D→G,CD→A,CE→G,CDE→B,B→D}

    4.3 属性集闭包

    • (函数依赖集闭包的大小是(属性的)指数级的)
    • 很多时候, 我们仅仅是想判断一个 FD X →Y 是否在F的闭包中. 一个有效的方式是:
      • 计算属性X的闭包 (记为X+) :
        • X的闭包 就是由X在F上蕴含的所有属性的集合。
        • 计算属性的闭包仅仅需要一个线性的时间算法就够了.
      • F = {A → B, B → C, C D → E } A → E成立吗?

    属性集闭包的作用

    1. 测试超键
      • – 判断X是否是一个超键?只需要计算 X+, 检查 X+ 是否包括R的所有属性.
    2. 检测函数依赖
      • 判断X → Y 是否成立 (或者说, 是否在F+中), 只需要判断Y ⊆ X+.
      • 因此, 我们计算X+, 然后检测这个属性集闭包是否包括 Y.
      • 简单有用的方法
    3. 计算F的函数依赖集闭包

    图片33

    图片34

    图片35

    图片37

    第5节 模式分解的基本标准

    分解的问题

    • 模式分解可能存在三种问题:

      1. 一些查询可能会代价变高.
        e.g., Attishoo 挣了多少钱? (earn = W*H)
      2. 分解后,根据分解的实例, 我们可能不能重新构建分解前的实例!
      3. 检查某些依赖需要考虑分解后的多个关系.
    • 折中: 考虑这些问题 vs. 冗余.

    分解

    • 将分解符合3NF或更高的范式是一种很好的保证方法.
    • 所有分解应该是无损的! (Avoids Problem (2))

    无损连接分解

    • 将R 分解为 R1 和R2 ,如果是无损连接分解,那么应该满足:

    图片38

    例子(不是无损的)

    图片39

    例子(无损的)

    图片40

    保持函数依赖

    • 保持函数依赖的分解(直观上):
      • R 分解为X, Y 和Z, 函数依赖集FDs在X,Y,Z上成立,那么FDs也会在R上成立。

    分解后的函数依赖?

    • 函数依赖集的投影: R 分解为 X, … F 在X上的投影 (denoted FX ) 是如下的 FDs U → V in F+ (closure of F ) ,U, V 是X中的属性.

    保持函数依赖的分解

    • 将R分解为X和Y是保持函数依赖的,当且仅当(FXFY)+=F+(F_X \cup F_Y)^+ = F^+
    • 注意是F+F^+,而不是FF
    • 保持函数依赖并不能保证保持无损连接分解
    • 反之亦然

    判断两个函数依赖集是否等价

    • 如果 F1+ = F2+, 那么F1和F2等价.
    • 例如, F1={A →B, A →C} 和 F2={A → BC}等价

    例子

    • F={ A → BC, B →C }. 判断 C →AB 是否在 F+?
    • Answer: 不在.
      Reason 1) C+=C, 不包括 AB.
      Reason 2) 反例,不存在 C → AB.

    BCNF和3NF的比较

    • 将一个关系分解为符合3NF的关系集合:
      • 分解是无损的
      • 分解是保持函数依赖的
    • 将一个关系分解为符合BCNF的关系集合:
      • 分解是无损的
      • 可能不保持函数依赖

    图片44

    设计目标

    • BCNF
    • 无损连接
    • 保持函数依赖

    如果不能得到这些

    • 函数依赖的保持
    • 使用3NF产生冗余

    Example

    图片45

    • R(A,B,F), F = {AC → E, B → F}.
      • Candidate key? AB
      • BCNF? No, because of B → F (B is not a superkey).
      • 3NF? No, because of B → F (F is not part of a candidate key).
    • R(D, C, H, G), F = {A → I, I → A}
      • Candidate key? DCHG
      • BCNF? Yes
      • 3NF? Yes

    图片46

    • R(A,B,C,D,E,F),F={A->C,C->A,B->AC,D->AC}
      • 找出R的键
      • 是否符合3NF,如果是,说明原因,如果否,分解。
    (1)R的候选码为BD
    (2)
    ①将F中的函数依赖都分解为右部为单属性的函数依赖.
    F={A→C,C→A,B→A,B→C,D→A,D→C,BD→A}
    ②去掉F中冗余的函数依赖.
    判断A→C是否冗余.
    设:G1={C→A,B→A,B→C,D→A,D→C,BD→A},得(A)G1+=A
    ∵C不属于(A)G1+   ∴ A→C不冗余
    判断C→A是否冗余.
    设:G2={A→C,B→A,B→C,D→A,D→C,BD→A},得(C)G2+=C
    ∵A不属于(C)G1+   ∴ C→A不冗余
    判断B→A是否冗余.
    设:G3={A→C,C→A,B→C,D→A,D→C,BD→A},得(B)G3+=BCA
    ∵A属于(B)G3+   ∴ B→A冗余
    判断B→C是否冗余.
    设:G4={A→C,C→A,D→A,D→C,BD→A},得(B)G4+=B
    ∵C不属于(B)G4+   ∴ B→C不冗余
    判断D→A是否冗余.
    设:G5={A→C,C→A,B→C,D→C,BD→A},得(D)G5+=DCA
    ∵A不属于(D)G5+   ∴ D→A冗余
    判断A→C是否冗余.
    设:G6={A→C,C→A,B→C,BD→A},得(D)G6+=D
    ∵C不属于(D)G6+   ∴ D→C不冗余
    判断BD→A是否冗余.
    设:G7={A→C,C→A,B→C,D→C},得(BD)G7+=BDCA
    ∵A不属于(BD)G7+   ∴ BD→A冗余
    F={A→C,C→A,B→C,D→C}
    ③由于各函数依赖左部都为单属性,故:
    Fm={A→C,C→A,B→C,D→C}
    (3)τ={AC,BC,DC,BD}
    
    • 解法一

    图片47

    • 解法二

    图片48

    展开全文
  • 总而言之,我们来判断什么是好的数据库关系模式?并自己也能设计出来! 先回答一个问题,为什么不直接全部都作为一个表来查询呢? 答案是会造成 数据冗余,更新异常,数据不一致啦~ 所以解决了上面三个点,就是一个...
  • 设计模式之单例模式2

    2021-03-04 21:41:20
    单例模式存在的问题 单例对 OOP 特性的支持不友好 单例会隐藏类之间的依赖关系 单例对代码的扩展性不友好 单例对代码的可测试性不友好 单例不支持参数的构造函数 如何解决构造参数问题 第一种解决思路是:创建...
  • 由此引出了关系数据库理论,一个有问题关系模式会带来: 1.数据冗余 2.更新异常 3.插入异常 4.删除异常 一个好的关系模式应当不会发生以上的异常,数据冗余尽可能的少。 因此需要规范化,由此产生了范式(在...
  • 我们探讨了引力异常在全息CFT中纠缠引力的出现。 更具体地说,从量子纠缠的角度研究了3D体中具有引力Chern-Simons项的拓扑质量引力(TMG)与二维... 来自量子信息的这些约束可能可能用于讨论TMG的紫外线不一致问题
  • 我们在设计表的关联关系,使用注解设置的时候,如果在注解上添加了一个***fetch = FetchType.LAZY***属性,就是设置为一个懒加载的模式,即什么时候需要使用这个数据,什么时候在在去查询,这个时候就会出现问题:...
  • 关系模式的存储异常问题 实例:假设一个关系模R(Sname,Cname,Tname,Taddress),其属性值分别表示学生姓名,选修课程名,任课教师姓名和任课教师地址。分析:该模式中,学生与课程直接联系,教师与课程也直接...
  • 关系模式包括哪些属性 从不良的设计模式到良好的设计模式的过程 不良的设计模式(各种异常) A)数据冗余:看图不解释 B)插入异常:如果某个新学院没有招生,尚无学生时,则学院名和院长的信息无法插入...
  • 由于在线调试模式,板子工作正常,无法通过在线调试的方式判断程序运行的异常状态。 分析可能的原因: 1、初始化过程中,程序陷入死循环。但程序初始化过程中,没有while(1)死循环的代码。 2、板子上电后不断...
  • 1、数据库范式的作用数据库范式主要是为解决关系数据库中数据冗余、更新异常、插入异常、删除异常问题而引入的设计理念。简单来说,数据库范式可以避免数据冗余,减少数据库的存储空间,并且减轻维护数据完整性的...
  • 1、数据库范式的作用数据库范式主要是为解决关系数据库中数据冗余、更新异常、插入异常、删除异常问题而引入的设计理念。简单来说,数据库范式可以避免数据冗余,减少数据库的存储空间,并且减轻维护数据完整性的...
  • 关系数据库(1NF 2NF 3NF BCNF 的定义)

    千次阅读 2019-06-19 09:29:34
    关系模式设计不合理带来的问题: 数据冗余 数据修改复杂 插入异常(应该插入的数据不能执行插入操作) 删除异常(不应该删除的数据被删除) 函数依赖的定义: X->Y 非平凡函数依赖/平凡函数依赖:Y不包含于X则为非...
  • 如果一个关系模式的所有属性都是不可分的基本数据项,则R∈1NF。简单的说,就是每一个列(属性),不能再分割成多个列(属性)。 第一范式(First Normal Form,1st NF)就是指在同一表中没有重复项出现,如果则应将...
  • 18.6.2 模式名称 18.6.3 模式被命名后有利于增进交流 18.7 GRAS:职责分配中通用原则的模式 18.8 UML类图表示法 18.9 专家 18.10 创建者 18.11 低耦合度 18.12 高聚合度 18.13 控制者 ...
  • 1、数据库范式的作用数据库范式主要是为解决关系数据库中数据冗余、更新异常、插入异常、删除异常问题而引入的设计理念。简单来说,数据库范式可以避免数据冗余,减少数据库的存储空间,并且减轻维护数据完整性的...
  • 34.3 有关层模式的其他问题 34.4 模型-视图分离和“向上”通信 34.5 参考资料 第35章 使用GoF模式完成更多对象设计 35.1 示例:NextGen POS 35.2 本地服务容错;使用本地缓存提高性能 35.3 处理故障 35.4 ...
  • 调试发现一个问题,当我用JLink调试模式时(即在IAR工程的Options->Debugger->Setup的Driver里面选择J-Link/J-Trace模式),启动调试后,程序会直接跑到CPU异常中断HardFaultException(硬故障)函数中,如下图: ...
  • 这个问题有原因有几个,一可能是服务器端的IP连接设置有问题;二是游戏更新有问题。 Q-Q457189 三十三、网狐荣耀版或其它安卓项目出现Application cannot be exported due to the erro 网狐荣耀版或其它安卓项目...
  • EAS总账应用问题集2013

    2013-08-14 16:34:22
    323 其他业务单据生成凭证,在凭证序时薄修改和删除凭证,提示获取关联关系出错 17 324在引入凭证提示未有符合过滤条件的凭证被引入 17 325设置数量核算的科目,在新增凭证界面无法带出计量单位和数量列 18 326凭证...
  • 数据库范式

    2020-12-31 22:41:13
    读书的时候,上数据库课,开头就讲范式。一直搞不懂这个范式,也不清楚是做什么...但范式越高,关系模式(即关系型数据库中的表)的粒度就越细,要获取完整数据需要连接的表就越多,时候为了提高性能,又需要增加冗余
  • 1.5 这样的声明什么问题?char*p1,p2;我在使用p2的时候报错了。 1.6 我想声明一个指针,并为它分配一些空间,但却不行。这样的代码什么问题?char*p;*p=malloc(10); 声明风格 1.7 怎样声明和定义全局变量和...
  • 《你必须知道的495个C语言问题

    热门讨论 2010-03-20 16:41:18
    1.5 这样的声明什么问题?char *p1, p2; 我在使用p2的时候报错了。 3 1.6 我想声明一个指针,并为它分配一些空间,但却不行。这样的代码什么问题?char *p; *p=malloc(10); 4 声明风格 4 1.7 怎样声明和...
  • 1.5 这样的声明什么问题?char *p1, p2; 我在使用p2的时候报错了。 3 1.6 我想声明一个指针,并为它分配一些空间,但却不行。这样的代码什么问题?char *p; *p=malloc(10); 4 声明风格 4 1.7 怎样声明和...
  • 知识点8. 关系的完整性约束 数据库的数据完整性是指数据库中数据的正确性、相容性、一致性 实体的完整性约束:关系的...关系模式中可能存在的问题有:数据冗余、更新异常、插入异常、删除异常 知识点2. 函数依赖与关
  • 8、运行时异常与一般异常有何异同?  异常表示程序运行过程中可能出现的非正常状态,运行时异常表示虚拟机的通常操作中可能遇到的异常,是一种常见运行错误。java编译器要求方法必须声明抛出可能发生的非运行时异常...

空空如也

空空如也

1 2 3 4 5 ... 13
收藏数 249
精华内容 99
关键字:

关系模式异常问题有