精华内容
下载资源
问答
  • 关系模式规范化理论

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

    关系模式规范化的定义

    到目前为止,规范化理论已经提出了六类范式。范式级别可以逐级升高,而升高规范化的过程就是逐步消除关系模式中不合适的数据依赖的过程,使模型中的各个关系模式达到某种程度的分离。一个低一级范式的关系模式,通过模式分解转为若干个高一级范式的关系模式的集合,这种分解过程叫作关系模式的规范化(Normalization)。

     

    关系模式规范化的目的和原则

    一个关系只要其分量都是不可分的数据项,就可称它为规范化的关系,但这只是最基本规范化。规范化的目的就是使结构合理,消除存储异常,使数据冗余尽量小,便于插入、最除和更新。
    规范化的基本原则就是遵循“一事一地”的原则,即一个关系只描述一个实体或者实体间的联系。若多于一个实体,就把它“分离”出来。因此,所谓规范化,实质上是概念的单一化,即个关系表示一个实体。

     

    关系模式规范化的步骤

    规范化就是对原关系进行投影,消除决定属性不是候选键的任何函数依赖。具体可以分为以下几步。
    (1)对1NF关系进行投影,消除原关系中非主属性对键的部分函数依赖,将1NF关系转换成若干个2NF关系。
    (2)对2NF关系进行投影,消除原关系中非主属性对键的传递函数依赖,将2NF关系转换成若干个3NF关系。
    (3)对3NF关系进行投影,消除原关系中主属性对键的部分函数依赖和传递函数依赖,也就是说,使决定因素都包含一个候选键,得到一组BCNF关系。
    (4)对BCNF关系进行投影,消除原关系中的非平凡且非函数依赖的多值依赖,得到一组4NF的关系。

    关系规范化的基本步骤如图所示。

     

    规范化过程

     

     

    一般情况下,我们说没有异常弊病的数据库设计是好的数据库设计,一个不好的关系模式也总是可以通过分解转换成好的关系模式的集合。但是在分解时要全面衡量,综合考虑,视实际情况而定。对于那些只要求查询而不要求插入、删除等操作的系统,几种异常现象的存在并不影响数据库的操作。这时便不宜过度分解,否则当对系统进行整体查询时,需要更多的多表连接操作,这有可能得不偿失。在实际应用中,最有价值的是3NF和BCNF,在进行关系模式的设计时,通常分解到3NF就足够了。

     

    关系模式规范化的要求

    关系模式的规范化过程是通过对关系模式的投影分解来实现的,但是投影分解方法不是唯的,不同的投影分解会得到不同的结果。在这些分解方法中,只有能够保证分解后的关系模式与原关系模式等价的方法才是有意义的。
    判断对关系模式的一个分解是否与原关系模式等价可以有三种不同的标准。
    (1)分解要具有无损连接性;
    (2)分解要具有函数依赖保持性;
    (3)分解既要具有无损连接性,又要具有函数依赖保持性。

     

     


    参考资料:[1]陈志泊,王春玲,许福,范春梅.数据库原理及应用教程(第3版)[M].北京:人民邮电出版社,2014:159-160.
     

     

     

    展开全文
  • 4.1.1 关系模式中的数据依赖 概念回顾 关系模式的形式定义 4.1.2 数据依赖对关系模式的影响 什么是数据依赖 关系模式的简化表示 数据依赖与关系模式 4.1.3 有关概念 函数依赖 码 外码 4.2 范式 4.2.1 第一范式(1...

    学习网址中国大学MOOC

    https://www.icourse163.org/spoc/learn/ZZULI-1207222804?tid=1450316458#/learn/content?type=detail&id=1214896542&cid=1250541363&replay=true

    目   录

    4.1 数据依赖

    4.1.1 关系模式中的数据依赖 

    概念回顾

    关系模式的形式化定义

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

    什么是数据依赖

    关系模式的简化表示

    数据依赖与关系模式

    4.1.3 有关概念

    函数依赖

    外码

    4.2 范式

    4.2.1 第一范式(1NF) 

    4.2.2 第二范式(2NF)

    4.2.3 第三范式(3NF)

    4.2.4 BC范式(BCNF)

    4.2.5 多值依赖与第四范式

    多值依赖

    多值依赖的性质

    二、第四范式(4NF)

    4.3 关系范式的规范化

    4.3.1 关系范式规范化的步骤

    范式的条件的讨论

    4.3.2 关系模式的分解

    将关系模式分解为范式


     

    6.1 --- 函数依赖

    4.1 数据依赖

     

    4.1.1 关系模式中的数据依赖 

    概念回顾

    关系模式的形式化定义

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

    什么是数据依赖

    关系模式的简化表示

    数据依赖与关系模式

    4.1.3 有关概念

    函数依赖

    外码

    4.2 范式

    4.2.1 第一范式(1NF) 

    6.2 --- 关系规范化

    4.2.2 第二范式(2NF)

    4.2.3 第三范式(3NF)

    4.2.4 BC范式(BCNF)

    4.2.5 多值依赖与第四范式

    多值依赖

    多值依赖的性质

    6.3 --- 小结

    二、第四范式(4NF)

    4.3 关系范式的规范化

    4.3.1 关系范式规范化的步骤

    范式的条件的讨论

    4.3.2 关系模式的分解

    将关系模式分解为范式

    展开全文
  • 后经深入的研究形成了系统的设计理论 关系数据库系统中关系模型包括一组关系模式各个关系模式相互有联系 一个合适的关系数据库系统的设计关键是关系数据库模式的设计 ;关系数据库的设计理论-前言;关系数据库的设计...
  • 关系模式规范化设计范式)

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

    目录

    数据库之六大范式详解

    1. 第一范式 1NF

    规范化: 

    2. 第二范式 2NF

    候选码: 

    主属性: 

    函数依赖: 

    判断一个关系是否属于第二范式:

    改进:

    3. 第三范式 3NF

    改进

    结论

    4. BC范式 BCFN

    要了解 BCNF 范式,那么先看这样一个问题:

    改进

    5. 第四范式 4NF

    6. 第五范式 5NF


    数据库之六大范式详解

    关系数据库中的关系满足一定要求的,满足不同程度要求的为不同的范式。满足最低要求的叫第一范式,简称1NF;在第一范式的基础上满足进一步要求的称为第二范式,简称2NF,其余范式以此类推。

    首先要明白”范式(NF)”是什么意思。按照教材中的定义,范式是“符合某一种级别的关系模式的集合,表示一个关系内部各属性之间的联系的合理化程度”。

    很晦涩吧?实际上你可以把它粗略地理解为一张数据表的表结构所符合的某种设计标准的级别。就像家里装修买建材,最环保的是E0级,其次是E1级,还有E2级等等。

    数据库范式也分为1NF,2NF,3NF,BCNF,4NF,5NF。

    一般在我们设计关系型数据库的时候,最多考虑到BCNF就够。符合高一级范式的设计,必定符合低一级范式,例如符合2NF的关系模式,必定符合1NF。

    关系模式”和“关系”的区别,类似于面向对象程序设计中”类“与”对象“的区别。”关系“是”关系模式“的一个实例,你可以把”关系”理解为一张带数据的表,而“关系模式”是这张数据表的表结构。


    1. 第一范式 1NF

    定义: 属于第一范式关系的所有属性都不可再分,即数据项不可分。

    理解: 第一范式强调数据表的原子性,是其他范式的基础。如下图所示数据库就不符合第一范式:

    实际上,1NF是所有关系型数据库的最基本要求,你在关系型数据库管理系统(RDBMS),例如SQL Server,Oracle,MySQL中创建数据表的时候,如果数据表的设计不符合这个最基本的要求,那么操作一定是不能成功的。也就是说,只要在RDBMS中已经存在的数据表,一定是符合1NF的。如果我们要在RDBMS中表现表中的数据,就得设计为下表的形式:

    但日常生活中仅用第一范式来规范表格是远远不够的,依然会存在数据冗余过大、删除异常、插入异常、修改异常的问题,此时就需要引入规范化概念,将其转化为更标准化的表格,减少数据依赖。

    规范化: 

    1. 每一名学生的学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次——数据冗余过大
    2. 假如学校新建了一个系,但是暂时还没有招收任何学生(比如3月份就新建了,但要等到8月份才招生),那么是无法将系名与系主任的数据单独地添加到数据表中去的 (注1)——插入异常

      注1:根据三种关系完整性约束中实体完整性的要求,关系中的码(注2)所包含的任意一个属性都不能为空,所有属性的组合也不能重复。为了满足此要求,图中的表,只能将学号与课名的组合作为码,否则就无法唯一地区分每一条记录。

      注2:码:关系中的某个属性或者某几个属性的组合,用于区分每个元组(可以把“元组”理解为一张表中的每条记录,也就是每一行)
    3. 假如将某个系中所有学生相关的记录都删除,那么所有系与系主任的数据也就随之消失了(一个系所有学生都没有了,并不表示这个系就没有了)。——删除异常
    4. 假如李小明转系到法律系,那么为了保证数据库中数据的一致性,需要修改三条记录中系与系主任的数据。——修改异常

    正因为仅符合1NF的数据库设计存在着这样那样的问题,我们需要提高设计标准,去掉导致上述四种问题的因素,使其符合更高一级的范式(2NF),这就是所谓的“规范化”。

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


    2. 第二范式 2NF

    定义: 若某关系R属于第一范式,且每一个非主属性完全函数依赖于任何一个候选码,则关系R属于第二范式。

    此处我们需要理解非主属性、候选码和完全函数依赖的概念。

    候选码: 

    若关系中的某一属性组的值能唯一地标识一个元组,而其子集不能,则称该属性组为候选码。若一个关系中有多个候选码,则选定其中一个为主码。

    以下所有内容中,主码或候选码都简称为码。

    例如下图所示的学生表中,学号和姓名都可以唯一标识一个元组,故该表的候选码为学号和姓名,主码我们可以随便选定其中一个,则选学号为主码。

    学号姓名年龄性别
    101刘晨19
    102王琪21
    103张宇20
    104李琛19
    105欧阳慧20

    主属性: 

    所有候选码的属性称为主属性。不包含在任何候选码中的属性称为非主属性或非码属性。

    在上面的学生表中,学号和姓名就是该关系的主属性,年龄和性别就是非主属性。

    函数依赖: 

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

    完全函数依赖: 

    设R(U)是属性集U上的关系模式,X、Y是U的子集。如果Y函数依赖于X,且对于X的任何一个真子集X’,都有Y不函数依赖于X’,则称Y对X完全函数依赖。记作:如果Y函数依赖于X,但Y不完全函数依赖于X,则称Y对X部分函数依赖
    记号

    传递依赖:

    传递依赖

    理解: 第二范式是指每个表必须有一个(有且仅有一个)数据项作为关键字或主键(primary key),其他数据项与关键字或者主键一一对应,即其他数据项完全依赖于关键字或主键。由此可知单主属性的关系均属于第二范式。

    判断一个关系是否属于第二范式:

    1. 找出数据表中的所有码;
    2. 找出所有主属性和非主属性;
    3. 判断所有的非主属性对码的部分函数依赖。

    表示了表中所有的函数依赖关系:

    码只有一个,就是(学号、课名)
    主属性有两个:学号 课名
    非主属性有四个:姓名系名系主任分数
    对于(学号,课名) → 姓名,有 学号 → 姓名,存在非主属性 姓名 对码(学号,课名)的部分函数依赖。
    对于(学号,课名) → 系名,有 学号 → 系名,存在非主属性 系对码(学号,课名)的部分函数依赖。
    对于(学号,课名) → 系主任,有 学号 → 系主任,存在非主属性 对码(学号,课名)的部分函数依赖。

    所以存在非主属性对于码的部分函数依赖,最高只符合1NF的要求,不符合2NF的要求。

    改进:

    为了符合2NF的要求,我们必须消除这些部分函数依赖,只有一个办法,就是将大数据表拆分成两个或者更多个更小的数据表,在拆分的过程中,要达到更高一级范式的要求,这个过程叫做”模式分解“。模式分解的方法不是唯一的,以下是其中一种方法:
    选课(学号,课名,分数)
    学生(学号,姓名,系名,系主任)

    我们先来判断以下,选课表与学生表,是否符合了2NF的要求?

    对于选课表,其码是(学号,课名),主属性是学号课名,非主属性是分数学号确定,并不能唯一确定分数课名确定,也不能唯一确定分数,所以不存在非主属性分数对于码 (学号,课名)的部分函数依赖,所以此表符合2NF的要求。

    对于学生表,其码是学号,主属性是学号,非主属性是姓名、系名系主任,因为码只有一个属性,所以不可能存在非主属性对于码 的部分函数依赖,所以此表符合2NF的要求。

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

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

    现在我们来看一下,进行同样的操作,是否还存在着之前的那些问题?

    1. 李小明转系到法律系
      只需要修改一次李小明对应的系的值即可。——有改进
    2. 数据冗余是否减少了?
      学生的姓名、系名与系主任,不再像之前一样重复那么多次了。——有改进
    3. 删除某个系中所有的学生记录
      该系的信息仍然全部丢失。——无改进
    4. 插入一个尚无学生的新系的信息。
      因为学生表的码是学号,不能为空,所以此操作不被允许。——无改进

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


    3. 第三范式 3NF

    定义: 非主属性既不传递依赖于码,也不部分依赖于码。

    理解: 第三范式要求在满足第二范式的基础上,任何非主属性不依赖于其他非主属性,即在第二范式的基础上,消除了传递依赖。

    接下来我们看看上表中的设计,是否符合3NF的要求。

    对于选课表,主码为(学号,课名),主属性为学号课名,非主属性只有一个,为分数,不可能存在传递函数依赖,所以选课表的设计,符合3NF的要求。

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

    改进

    为了让数据表设计达到3NF,我们必须进一步进行模式分解为以下形式:
    选课(学号,课名,分数)
    学生(学号,姓名,系名)
    系(系名,系主任)

    对于选课表,符合3NF的要求,之前已经分析过了。

    对于学生表,码为学号,主属性为学号,非主属性为系名,不可能存在非主属性对于码的传递函数依赖,所以符合3NF的要求。

    对于表,码为系名,主属性为系名,非主属性为系主任,不可能存在非主属性对于码的传递函数依赖(至少要有三个属性才可能存在传递函数依赖关系),所以符合3NF的要求。。

    新的函数依赖关系如图

    新的数据表如下表

    现在我们来看一下,进行同样的操作,是否还存在着之前的那些问题?

    1. 删除某个系中所有的学生记录
      该系的信息不会丢失。——有改进
    2. 插入一个尚无学生的新系的信息。
      因为系表与学生表目前是独立的两张表,所以不影响。——有改进
    3. 数据冗余更加少了。——有改进

    结论

    由此可见,符合3NF要求的数据库设计,基本上解决了数据冗余过大,插入异常,修改异常,删除异常的问题。当然,在实际中,往往为了性能上或者应对扩展的需要,经常 做到2NF或者1NF,但是作为数据库设计人员,至少应该知道,3NF的要求是怎样的。


    4. BC范式 BCFN

    定义: 关系模式R<U,F>中,若每一个决定因素都包含码,则R<U,F>属于BCFN。

    理解: 根据定义我们可以得到结论,一个满足BC范式的关系模式有:

    1. 所有非主属性对每一个码都是完全函数依赖;
    2. 所有主属性对每一个不包含它的码也是完全函数依赖;
    3. 没有任何属性完全函数依赖于非码的任何一组属性。

    要了解 BCNF 范式,那么先看这样一个问题:

    1. 某公司有若干个仓库;
    2. 每个仓库只能有一名管理员,一名管理员只能在一个仓库中工作;
    3. 一个仓库中可以存放多种物品,一种物品也可以存放在不同的仓库中。每种物品在每个仓库中都有对应的数量。

    那么关系模式 仓库(仓库名,管理员,物品名,数量) 属于哪一级范式?

    答:已知函数依赖集:仓库名 → 管理员,管理员 → 仓库名,(仓库名,物品名)→ 数量
    码:(管理员,物品名),(仓库名,物品名)
    主属性:仓库名、管理员、物品名
    非主属性:数量
    ∵ 不存在非主属性对码的部分函数依赖和传递函数依赖。∴ 此关系模式属于3NF。

    基于此关系模式的关系(具体的数据)可能如图所示:

    好,既然此关系模式已经属于了 3NF,那么这个关系模式是否存在问题呢?我们来看以下几种操作:

    1. 先新增加一个仓库,但尚未存放任何物品,是否可以为该仓库指派管理员?——不可以,因为物品名也是主属性,根据实体完整性的要求,主属性不能为空。
    2. 某仓库被清空后,需要删除所有与这个仓库相关的物品存放记录,会带来什么问题?——仓库本身与管理员的信息也被随之删除了。
    3. 如果某仓库更换了管理员,会带来什么问题?——这个仓库有几条物品存放记录,就要修改多少次管理员信息。

    从这里我们可以得出结论,在某些特殊情况下,即使关系模式符合 3NF 的要求,仍然存在着插入异常,修改异常与删除异常的问题,仍然不是 ”好“ 的设计。

    改进

    造成此问题的原因:存在着主属性对于码的部分函数依赖与传递函数依赖。(在此例中就是存在主属性【仓库名】对于码【(管理员,物品名)】的部分函数依赖。

    解决办法就是要在 3NF 的基础上消除主属性对于码的部分与传递函数依赖。

    仓库(仓库名,管理员)
    库存(仓库名,物品名,数量)

    这样,之前的插入异常,修改异常与删除异常的问题就被解决了。

    以上就是关于 BCNF 的解释。


    5. 第四范式 4NF

    定义: 限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。

    理解: 显然一个关系模式是4NF,则必为BCNF。也就是说,当一个表中的非主属性互相独立时(3NF),这些非主属性不应该有多值,若有多值就违反了4NF。


    6. 第五范式 5NF

    第五范式有以下要求:
    (1)必须满足第四范式;
    (2)表必须可以分解为较小的表,除非那些表在逻辑上拥有与原始表相同的主键。

    第五范式是在第四范式的基础上做的进一步规范化。第四范式处理的是相互独立的多值情况,而第五范式则处理相互依赖的多值情况。

    展开全文
  • 一、范式 关系模式满足的确定约束条件称为范式,根据满足约束条件的级别不同, 范式由低到高分为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。
     
    展开全文
  • 数据库设计关系规范化理论总结

    千次阅读 多人点赞 2020-07-31 11:08:14
    数据库是一门对数据进行有效管理的技术,它研究信息资源如何被安全地储存和如何被高效地利用,它是现代计算机科学的一个重要分支。...本文通过例举具体事例来探讨关系规范化理论在数据库逻辑设计中的形成和方法。
  • 关系模式规范化(上)

    千次阅读 2013-03-19 13:45:11
    最近在学习数据库过程中,...选择,除法,元组关系演算等等,没有介绍如何合理设计一个数据库,可是如果作为一个数据库designer,必须了解如何设计与简化数据库,这都是数据模式规范化的内容。 如果不考虑数据库规范化
  • 关系数据库规范化理论

    千次阅读 2018-03-01 22:54:50
    关系数据库规范化理论一个关系数据库由一组关系模式组成,一个关系由一组属性名组成,关系数据库设计就是如何把已给定的相互关联的一组属性名分组,并把每一组属性名组织成关系的问题。1、关系规范化的作用所谓规范...
  • 插入操作异常是指 A 不该删除的数据被删除 B 不该插入的数据被插入 C 应该删除的数据未被删除 D 应该插入的数据未被插入 答案 A D 2设计性能较优的关系模式称为规范化规范化主要的理论依据是 A 关系规范化理论 B ...
  • 关系模式设计理论

    千次阅读 热门讨论 2014-09-28 11:16:10
     一个低级范式,通过模式分解可以转化为若干个高级范式的关系模式,即为规范化。  范式:  目前关系数据库有六种范式,咱们最常用的是第一到第三范式。各范式呈递次规范,越高的范式数据冗余越小。  第一范式:...
  • 关系数据库规范化理论---范式

    千次阅读 2017-11-08 15:27:02
    此篇博文是我的第一篇文章,在复习数据库范式...关系模式规范化的必要性:关系模式规范化,使之达到较高的范式是设计好关系模式的唯一途径。否则,所设计的关系数据库会产生一系列的问题。 关系模式应满足的基本要求:
  • 数据库设计及其规范化理论,包括关系模式设计问题、函数依赖、范式等,还有数据库设计的各个阶段
  • 关于关系型数据库的设计规范与实例介绍. pdf,希望对大家有用
  • 数据库关系模式规范化

    千次阅读 2021-04-03 15:23:11
    在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。 所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即...
  • 规范化理论

    2012-12-10 20:05:01
    关系数据库逻辑设计 针对具体问题,如何构造一个适合于它的数据模式 数据库逻辑设计的工具──关系数据库的规范化理论
  • 数据库规范化设计理论摘要

    千次阅读 2011-06-02 19:15:00
    对于一个大项目来讲,数据库的设计命名规范是很重要的一个环节,好的表设计,让人看得很舒服,一看就明白是什么意思了,下面看到一篇很不错的数据库对象命名参考文档,所以整理分享给大家。 引言 ...
  • 关系模式设计中的问题关系数据库设计要解决的主要问题 什么样的数据库模式才合理? 怎么分解才能满足要求? 衡量的标准是什么? 理论基础是什么? 如何进行实现? 关于好的数据库模式好的数据库模式是不会发生插入...
  • 关系数据库规范化理论 函数依赖与范式理论
  • 数据库设计规范化,很好的数据库规范规则
  • 如何设计一个适合的关系数据库系统关键是关系数据库模式的设计一个好的关系数据库模式应该包括多少关系模式而每一个关系模式又应该包括哪些属性又如何将这些相互关联的关系模式组建一个适合的关系模型这些工作决定了...
  • 数据依赖是一个关系内部属性与属性之间的一种约束关系,这种关系是通过属性间值的相等与否体现的数据相关的关系。 多种类型的数据依赖:函数依赖和多值依赖 例如:Sname和Sdept函数依赖于Sno,记做Sno -> Sname...
  • 关系数据库规范化理论之范式

    千次阅读 2017-11-09 22:27:30
    因为在写项目时与同伴关于数据库到底建多少张表,每张表应包含哪些属性产生分歧,所以又好好研究了一下关系型数据库在设计时应该遵守怎样的规则以提高数据库性能。 在阅读本篇文章前读者须掌握关系数据库结构基础及...
  • 关于关系模式设计中需要的规范化问题,范式的分解
  • 关系数据库设计理论

    千次阅读 2018-07-11 18:32:27
    关系数据库设计理论 设计一个好的关系数据库系统,关键是要设计一个好的数据库模式(数据库逻辑设计问题) 数据库逻辑设计主要解决的问题 关系数据库应该组织成几个关系模式 关系模式中包括哪些属性 ...
  • 数据库规范化理论

    千次阅读 2018-06-24 09:57:39
    本文版权归作者AlvinZH和博客园所有,欢迎转载和商用,但未经作者同意必须保留此段声明,且在...一个关系模式是一个五元组,形如R(U,D,DOM,F)。其中D、DOM与模式设计关系不大,可以看作三元组R&lt;U,F&gt;...
  • 关系数据库是以关系模型为基础的...由于关系模型有严格的数学理论基础,并且可以向别的数据模型转换,因此人们往往用关系模型为背景来讨论这一问题,形成了数据库逻辑设计的一个有力工具——关系数据库的规范化理论

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 53,502
精华内容 21,400
关键字:

关系模式的规范化设计理论