精华内容
下载资源
问答
  • 关系模式2NF3NF,BCNF的判定

    千次阅读 2020-03-04 22:40:57
    2NF:每一个非主属性都完全依赖于码 判定:不存在非主属性对关键字的部分依赖 例如:R(A,B,C,), F={A→B,B→A,C→A} ...3NF:非主属性函数依赖于超码 判定:不存在非主属性对码的传递函数依赖或部分...

           2NF:每一个非主属性都完全依赖于码

           判定:不存在非主属性对关键字的部分依赖

           例如:R(A,B,C,), F={A→B,B→A,C→A}

    第2范式,主码是C,不存在非关键字部分依赖关键字,所以属于第2范式。存在非关键字对任一候选关键字传递函数依赖,所以不符合第3范式。

    3NF:非主属性函数依赖于超码

    判定:不存在非主属性对码的传递函数依赖或部分函数依赖性

    例如:AB-C,A->C  码为(A,B),A,B是主属性,C是非主属性,C部分函数依赖于码,即不满足3NF

    BCNF:所有函数依赖要么平凡,要么对超码依赖

    每个决定因素都包含码(相比于3NF,优点是加上了对主属性的限制)

                         另一种说法:①主属性完全函数依赖于不含它的码

                                               ②没有任何属性完全函数依赖于非码的任何一组属性

                                               ③所有非主属性对每一个码都是完全函数依赖

     

    展开全文
  • 模式分解之前,首先对于1NF,2NF,3NF,BCNF做一个简明扼要的介绍。 1NF是指数据库表的每一列都是不可分割的基本数据项,即实体中的某个属性不能有多个值或者不能有重复的属性。 2NF要求属性...

    本来是为了复习数据库期末考试,结果找了一圈都没有发现比较好的解释,通过查阅资料和总结,为大家提供通俗易懂的解法,一听就会!并且配有速记口诀!介是你没有玩过的船新版本包含最小依赖集求法候选码求法

    在模式分解之前,首先对于1NF,2NF,3NF,BCNF做一个简明扼要的介绍。

    1NF是指数据库表的每一列都是不可分割的基本数据项,即实体中的某个属性不能有多个值或者不能有重复的属性。

    2NF要求属性完全依赖于主键,不能存在仅依赖主关键字一部分的属性。

    3NF要求每一个非主属性既不部分依赖于码也不传递依赖于码。

    BCNF消除了主属性对候选码的部分和传递函数依赖。

    注:1.相对于BCNF,3NF允许存在主属性对候选码的传递依赖和部分依赖。

    2.BCNF比较抽象,略作解释:在学生信息表里,学号是一个候选码,学号可确定学生姓名;(班级,学生姓名)也是一组候选码,有(班级,学生姓名)->学号,因此在主属性间形成了传递依赖。

    3.若对概念不清晰,关于码、候选码、主属性、非主属性的解释可参看:

    https://blog.csdn.net/sumaliqinghua/article/details/85872446#commentBox

    我们的重点是讲解范式分解:

    一、3NF分解

    分为保持依赖和无损连接

    为了说明求解保持依赖,我们先要会求最小依赖集

    (1)最小依赖集求法:

    口诀:右侧先拆单,依赖依次删。

               还原即可删,再拆左非单。

    通过求下面的最小依赖集对口诀进行解释,

    (2)3NF分解:

    口诀:

    保函依赖分解题,先求最小依赖集。

    依赖两侧未出现,分成子集放一边,剩余依赖变子集。

    若要连接成无损,再添候选做子集。

    下面通过几道例题讲解口诀:

    例1.已知R(ABCDE), F={A ->D,E->D,D->B,BC->D,DC->A}求保持函数依赖的3NF分解,和具有无损连接性及保持函数依赖的3NF分解

    第一步:保函依赖分解题,先求最小依赖集。先求出R的最小依赖集,可得F={A ->D,E->D,D->B,BC->D,DC->A}

    第二步:依赖两侧未出现,分成子集放一边。首先可以发现没有不出现在两侧的元素不用单独分出一个子集,“剩余依赖变子集”然后我们将各依赖分别划分为子集得到:{AD} {ED} {DB} {BCD} {DCA},即为所求保持函数依赖的3NF分解

    第三步:若要连接成无损,再添候选做子集。

    (1)候选码的求解:所谓候选码即能决定整个关系的,我们通过找未出现在依赖右边的和两侧均未出现的元素即可求得,

    (2)可以发现C E未出现在右边,因此候选码为{CE}。故所求具有无损连接性及保持函数依赖的3NF分解为{AD} {ED} {DB} {BCD} {DCA} {CE}

     

    例2.关系模式R,有U={A,B,C,D,E,G},F={B->G,CE->B,C->A,CE->G,B->D,C->D},将关系模式分解为3NF且保持函数依赖

    将关系模式分解为3NF且保持函数依赖:

    第一步:保函依赖分解题,先求最小依赖集。先求出R的最小依赖集,

    假设B->G冗余,则(B)+=BD,没有G故不冗余。

    假设CE->B冗余,则(CE)+=CEGDA,没有B故不冗余。

    假设C->A冗余,则(C)+=CD,故不冗余。

    一次可以得到最小函数依赖集Fm={B->G,CE->B,C->A,B->D,C->D}

    第二步:依赖两侧未出现,分成子集放一边,剩余依赖变子集。首先可以发现没有不出现在两侧的元素,然后我们将各依赖分别划分为子集得{BG} {CEB} {CA} {BD} {CD},即为所求保持函数依赖的3NF分解

    第三步:若要连接成无损,再添候选做子集。找到R的一个候选码为{CE}。故所求具有无损连接性及保持函数依赖的3NF分解为{BG} {CEB} {CA} {BD} {CD} {CE} (注:范式分解并不唯一,正确即可)

     

    二、BCNF分解:

    将关系模式R<U,F>分解为一个BCNF的基本步骤是

    1)先求最小依赖集,候码非码成子集

    3)余下左侧全候码,完成BCNF题。

    例.关系模式R,有U={A,B,C,D,E,G},F={B->G,CE->B,C->A,CE->G,B->D,C->D},将关系模式分解为3NF且保持函数依赖

    将关系模式分解为3NF且保持函数依赖:

    第一步:先求最小依赖集。可以发现CE->G多余,因此最小依赖集为F={B->G,CE->B,C->A,B->D,C->D}。

    第二步:候码非码成子集。由于候选码为(CE)因此将CE->B划分出子集(BCE),而B->G,B->D左侧均不含主属性(C、E)中的任何一个故划分出(BG),(BD)

    第三步:此时剩余依赖F={C->A,C->D}剩余元素{A,C,D}检查发现函数依赖左侧都是候选码即完成BCNF分解,如果不满足则继续分解余下的。

    于是BCNF分解的最后结果为{(BG),(BD),(ACD),(BCE)}。

    如有疑问请在评论区留言,如有帮助麻烦右上角点个赞~~蟹蟹

    三、总结

    1.闭包

    2.候选码

    3.最小依赖集

    4.3NF分解

    5.BCNF分解

    展开全文
  • 数据仓库的3NF模型

    千次阅读 2018-09-11 14:42:24
    3NF的基本解释 (1)1NF-无重复的列  数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。  如果出现重复的属性,就可能需要定义一个新的...

    3NF的基本解释

    (1)1NF-无重复的列

      数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。

      如果出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多关系。在第一范式(1NF)中表的每一行只包含一个实例的信息。简而言之,第一范式就是无重复的列。

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

    (2)2NF-部分依赖

      非主属性完全依赖于主键[消除非主属性对主码的部分函数依赖]。

      第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的唯一标识。例如员工信息表中加上了员工编号(emp_id)列,因为每个员工的员工编号是唯一的,因此每个员工可以被唯一区分。这个唯一属性列被称为主关键字或主键、主码。

      第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列,以存储各个实例的唯一标识。简而言之,第二范式就是属性完全依赖于主键。

    (3)3NF-传递依赖

     属性不依赖于其它非主属性[消除传递依赖]。

      满足第三范式(3NF)必须先满足第二范式(2NF)。简而言之,第三范式(3NF)要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如,存在一个部门信息表,其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表,则根据第三范式(3NF)也应该构建它,否则就会有大量的数据冗余。简而言之,第三范式就是属性不依赖于其它非主属性。

    三、实例

      下面以一个学校的学生系统为例分析说明,这几个范式的应用。首先第一范式(1NF):数据库表中的字段都是单一属性的,不可再分。这个单一属性由基本类型构成,包括整型、实数、字符型、逻辑型、日期型等。在当前的任何关系数据库管理系统(DBMS)中,傻瓜也不可能做出不符合第一范式的数据库,因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此,你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。

      首先我们确定一下要设计的内容包括那些。学号、学生姓名、年龄、性别、课程、课程学分、系别、学科成绩,系办地址、系办电话等信息。为了简单我们暂时只考虑这些字段信息。我们对于这些信息,说关心的问题有如下几个方面。

      学生有那些基本信息

      学生选了那些课,成绩是什么

      每个课的学分是多少

      学生属于那个系,系的基本信息是什么。

      3.1 第二范式(2NF)实例分析

      首先我们考虑,把所有这些信息放到一个表中(学号,学生姓名、年龄、性别、课程、课程学分、系别、学科成绩,系办地址、系办电话)下面存在如下的依赖关系。

      问题分析

      因此不满足第二范式的要求,会产生如下问题

      数据冗余: 同一门课程由n个学生选修,”学分”就重复n-1次;同一个学生选修了m门课程,姓名和年龄就重复了m-1次。

      更新异常:

      1)若调整了某门课程的学分,数据表中所有行的”学分”值都要更新,否则会出现同一门课程学分不同的情况。

      2)假设要开设一门新的课程,暂时还没有人选修。这样,由于还没有”学号”关键字,课程名称和学分也无法记录入数据库。

      删除异常 : 假设一批学生已经完成课程的选修,这些选修记录就应该从数据库表中删除。但是,与此同时,课程名称和学分信息也被删除了。很显然,这也会导致插入异常。

      解决方案

      把选课关系表SelectCourse改为如下三个表:

      学生:Student(学号,姓名, 年龄,性别,系别,系办地址、系办电话);

      课程:Course(课程名称, 学分);

      选课关系:SelectCourse(学号, 课程名称, 成绩)。

      3.2第三范式(3NF)实例分析

      接着看上面的学生表Student(学号,姓名, 年龄,性别,系别,系办地址、系办电话),关键字为单一关键字”学号”,因为存在如下决定关系:

      (学号)→ (姓名, 年龄,性别,系别,系办地址、系办电话)

      但是还存在下面的决定关系

      (学号) → (所在学院)→(学院地点, 学院电话)

      即存在非关键字段”学院地点”、”学院电话”对关键字段”学号”的传递函数依赖。

      它也会存在数据冗余、更新异常、插入异常和删除异常的情况。 (数据的更新,删除异常这里就不分析了,可以参照2.1.1进行分析)

      根据第三范式把学生关系表分为如下两个表就可以满足第三范式了:

      学生:(学号, 姓名, 年龄, 性别,系别);

      系别:(系别, 系办地址、系办电话)。
      

    数据仓库的3NF的特点

    数据仓库之父Immon的方法从全企业的高度设计一个3NF模型,用实体加关系描述的数据模型描述企业业务架构,在范式理论上符合3NF,它与OLTP系统中的3NF的区别,在于数据仓库中的3NF上站在企业角度面向主题的抽象,而不是针对某个具体业务流程的实体对象关系抽象,它更多的是面向数据的整合和一致性治理,正如Immon所希望达到的:“single version of the truth”。

    但是要采用此方法进行构建,也有其挑战:

    • 需要全面了解企业业务和数据
    • 实施周期非常长
    • 对建模人员的能力要求也非常高
    展开全文
  • 1 范式的基本概念 设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,...目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF...

    1 范式的基本概念

    设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小。没有冗余的数据库未必是最好的数据库, 有时为了提高运行效率,就必须降低范式标准,适当保留冗余数据。

    目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。各范式之间的联系如下:

    5NF\subset 4NF\subset BCNF\subset 3NF\subset 2NF\subset 1NF

    满足最低要求的范式是第一范式(1NF)。在第一范式的基础上进一步满足更多规范要求的称为第二范式(2NF),其余范式以次类推。一般说来,数据库只需满足第三范式(3NF)就行了。

     


     

    函数依赖

    比如描述一个学生的关系,可以有学号(Sno),姓名(Sname)、系名(Sdept)等几个属性。由于一个学号对应一个学生,一个学生只在一个系学习。因此,学号确定以后,学生的姓名和其所在的系的值 也就被唯一的确定了。这种属性间的依赖关系,类似于数学中的 y=f(x),自变量x确定以后,相应的函数值y也就唯一确定了。

    也就是 Sname=f(Sno),Sdept=f(Sno),即Sno函数决定Sname,Sno函数决定Sdept。或者说,Sname和Sdept函数依赖于Sno。记作 Sno→Sname,Sno→Sdept。

    X→Y,Y→Z,则称为Z对X传递函数依赖。记为X\overset{t}{\rightarrow}Z

     

    X→Y,但Y\nsubseteq X则称X→Y是非平凡的函数依赖。如:关系R(Sno, Cno),依赖关系(Sno, Cno)→Sno(Sno, Cno)→Cno都是平凡函数依赖。

    X→Y,但Y\subseteq X则称X→Y是平凡的函数依赖。如:关系R(Sno, Cno, Grade),依赖关系(Sno, Cno)→Grade是非平凡函数依赖。

     

    完全函数依赖:每一个非主属性,函数依赖于主键中的全部属性,而不能仅依赖主键一部分的属性。因为主键可能有多个属性构成,比如主键有三个属性,某个非主属性仅依赖主键的三个属性中的两个,那么就不能被称为完全函数依赖。

    部分函数依赖:X→Y,但Y不完全函数依赖于X,则称Y对X部分函数依赖。

     


     

    码(key)

    关系模式R<U,F>。关系名R,一组属性U,属性组U上的一组数据依赖F。

    K为R中的属性或属性组合。若U完全函数依赖于K,则称K为R的候选码。候选码可能多于一个,则选定其中一个为主码(主键)

    例如一个学生,身份证可以唯一表示一个学生,学号也可以唯一标识一个学生,(身份证,学号)这个集合可以唯一标识一个学生。我们可以选学号来作为这个学生的主键,那么学号、(身份证、学号)就是候选码

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

    最简单的情况,单个属性是码。最极端的情况,整个属性组U是码,称为全码

    外码:一个属性(或属性组),它不是码,但是它别的表的码,它就是外码

     


     

    第一范式(1NF)

    定义:数据库表的每一列(也称为属性)都是不可分割的原子数据项,不能是集合,数组,记录等非原子数据项。即实体中的某个属性有多个值时,必须拆分为不同的属性。在符合第一范式(1NF)表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之,第一范式就是无重复的域。


     

    第二范式(2NF)(在1NF基础上,消除 非码属性 对码的部分函数依赖

    定义:在1NF基础上,每一个的非码属性(不在主键中的列),都必须完全函数依赖于候选码。在1NF基础上,消除 非码属性 对码的部分函数依赖,也就是让非码属性 函数依赖于 候选码中的全部属性)。不能有任何一列与主键没有关系。即一个表只描述一件事情。

    举个例子,若有一数据表为(学号, 课程名称,姓名, 年龄, 成绩, 学分)。假设(学号, 课程名称) 是主键,就可能有如下依赖关系:

    (学号, 课程名称) → (姓名, 年龄, 成绩, 学分)

    可以看出,姓名和年龄不依赖于课程即 非主属性 不完全依赖于主属性因此,该主码不满足第二范式的要求。

     


     

    第三范式(3NF)(在2NF基础上,消除非码属性对候选码的传递函数依赖

    定义:在2NF基础上,每个非主属性 不依赖于 其它非主属性(在2NF基础上,消除非码属性对候选码的传递函数依赖)。也就是说,任何非主属性都直接依赖于主属性,不能传递依赖于主属性。即 表中的每一列 只与主键直接相关,而不是间接相关,(表中的每一列只能依赖于主键)。每一个非码属性既不部分依赖于码,也不传递依赖于码

    简而言之,第三范式(3NF)要求:一个关系中不包含 已在其它关系中包含的非主关键字信息。

    例如,存在一个部门信息表,其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后,就不能再将部门名称、部门简介等 与部门有关的信息,加入到员工信息表中。(减少了冗余)。

    假设:“部门名称”加入到员工信息表

    员工信息表(员工ID,姓名,部门编号,部门名称)

    会出现,员工ID→部门编号→部门名称,的情况。

    即 部门名称(非主属性) 传递依赖于 员工ID(主属性)。

    非主属性“部门编号” 依赖于 非主属性“部门名称”

    这既不符合每个非主属性 不依赖于 其它非主属性,也不符合任何非主属性都直接依赖于主属性,不能传递依赖于主属性

    综上,员工信息表(员工ID,姓名,部门编号,部门名称),不符合第三范式。

    还有就是,如果不存在部门信息表,则根据第三范式(3NF)也应该构建它,不然就会有大量的数据冗余。

     

    区分1NF、2NF、3NF:第二范式是说一张表中包含了多种不同的实体属性,那么要必须分成多张表。(一张表只表示一个实体)

     第三范式是要求已经分成了多张表,那么一张表中只能有另一张表中的id(外键),而不能有其他的任何信息(其他的信息一律用该外键在另一表查询)。

     


     

    巴斯-科德范式(BCNF,Boyce-Codd Normal Form):在3NF基础上,消除主属性(候选码中的属性)候选码部分函数依赖传递函数依赖

    在某些特殊情况下,即使关系模式符合 3NF 的要求,仍然存在着插入异常,修改异常与删除异常的问题。BCNF由Boyce与Codd提出,通常被认为是修正的第三范式。

    在3NF基础上,消除主属性(候选码中的属性)候选码部分函数依赖传递函数依赖

    定义:关系模式R<U,F>∈1NF,若X→Y 且Y不是X的子集时 X必含有码,则R<U,F>∈BCNF。也就是说,关系模式R<U,F>中,若每一个决定因素都包含码,则R<U,F>∈BCNF。

    由BCNF的定义可以得到结论,一个满足BCNF的关系模式有:

    -所有非主属性对每一个码都是完全函数依赖。

    -所有主属性对每一个不包含它的码也是完全函数依赖。

    -没有任何属性 完全函数依赖于 非码的任何一组属性。

    若R∈BCNF,按定义排除了任何属性对码的传递依赖与部分依赖,所以R∈3NF。

    注意:若R∈BCN,则R∈3NF。 若R∈3NF,R不一定属于BCNF!
     


     

    多值依赖

    多值依赖是属性之间的一对多关系,记为K→→A。

    函数依赖事实上是单值依赖,所以不能表达属性值之间的一对多关系。(有人称函数依赖为多值依赖的特例)

    平凡的多值依赖:全集U=K+A,一个K可以对应于多个A,即K→→A。此时整个表就是一组一对多关系。

    非平凡的多值依赖:全集U=K+A+B,一个K可以对应于多个A,也可以对应于多个B,A与B互相独立,即K→→A,K→→B。整个表有多组一对多关系,且有:“一”部分是相同的属性集合,“多”部分是互相独立的属性集合。

     


     

    第4范式(4NF)

    当关系R的属性集合X是非平凡多值依赖的域,它就包含关系R的键。则 R\in 4NF

    在BCNF的基础上,消除非平凡且非函数依赖的多值依赖。4NF就是限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。4NF所允许的多值依赖实际上是函数依赖。

     

    不严谨地说,只要两个独立的1:N联系出现在一个关系中,那么就有可能出现多值依赖。

    例如:

    一个表中存在三个数据:“课程、学生、先修课”。假设2019级的计算机专业学生想要学习JAVA课程,那么他们需要先学习VB、C#、BS三门课,才可以选择进行JAVA课程。存在关系:

    课程→学生

    课程→先修课

    两个均是1:N的关系,当出现在一张表的时候,会出现大量的冗余所以就我们需要分解它,减少冗余。分解后如下:

           

     


     

    第五范式(5NF)

    如果关系模式R中的每一个连接依赖均由R的候选码所隐含,则称此关系模式符合第五范式。(在4NF的基础上,消除不是由候选码所蕴含的连接依赖

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

    函数依赖是多值依赖的一种特殊的情况,而多值依赖实际上优势连接依赖的一种特殊情况。但连接依赖不像函数依赖和多值依赖可以由语义直接导出,而是在关系连接运算时才反映出来。存在连接依赖的关系模式仍可能遇到数据冗余及插入、修改、删除异常等问题。

     


    总结

    规范化过程
    1NF
    消除非主属性对码的部分函数依赖
    2NF
    ↓ 消除非主属性对码的传递函数依赖
    3NF
    ↓ 消除主属性对码的部分和传递函数依赖
    BCNF
    ↓ 消除非平凡且非函数依赖的多值依赖
    4NF
    ↓ 消除不是由候选码所蕴含的连接依赖
    5NF


     


     

    2 范式的应用实例

    下面以一个学校的学生系统为例分析说明,这几个范式的应用。

     

    第一范式(1NF)

    数据库表中的字段都是单一属性的,不可再分。这个单一属性由基本类型构成,包括整型、实数、字符型、逻辑型、日期型等。在当前的任何关系数据库管理系统(DBMS)中,傻瓜也不可能做出不符合第一范式的数据库,因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此,你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。

    首先我们确定一下要设计的内容包括那些。学号、学生姓名、年龄、性别、课程名称、课程学分、系别、学科成绩,系办地址、系办电话等信息。为了简单我们暂时只考虑这些字段信息。我们对于这些信息,所关心的问题有如下几个方面。

    学生有那些基本信息?

    学生选了那些课,成绩是什么?

    每个课的学分是多少?

    学生属于那个系,系的基本信息是什么?

     

    第二范式(2NF)

    首先我们考虑,把所有这些信息放到一个表中(学号,学生姓名、年龄、性别、课程、课程学分、系别、学科成绩,系办地址、系办电话)下面存在如下的依赖关系。

    (学号, 课程名称) → (姓名, 年龄, 成绩, 学分)

    问题分析:

    姓名和年龄不依赖于课程不完全依赖于主属性,因此不满足第二范式的要求,会产生如下问题:

    1.数据冗余:同一门课程由n个学生选修,"学分"就重复n-1次;同一个学生选修了m门课程,姓名和年龄就重复了m-1次。

    2.更新异常

    (1)若调整了某门课程的学分,数据表中所有行的"学分"值都要更新,否则会出现同一门课程学分不同的情况。

    (2)假设要开设一门新的课程,暂时还没有人选修。这样,由于还没有"学号"关键字,课程名称和学分也无法记录入数据库。

    3.删除异常 :假设一批学生已经完成课程的选修,这些选修记录就应该从数据库表中删除。但是,与此同时,课程名称和学分信息也被删除了。很显然,这也会导致插入异常。

     

    解决方案

    把选课关系表SelectCourse改为如下三个表:

    学生:Student(学号,姓名,年龄,性别,系别,系办地址、系办电话);

    课程:Course(课程名称,学分);

    选课关系:SelectCourse(学号,课程名称,成绩)。

     

    第三范式(3NF)

    接着看上面的学生表Student(学号,姓名,年龄,性别,系别,系办地址、系办电话),关键字为单一关键字"学号",因为存在如下决定关系:

    (学号)→ (姓名,年龄,性别,系别,系办地址、系办电话)

    但是还存在下面的决定关系:

    (学号) → (系别)→(系办地点,系办电话)

    即存在非关键字段"系办地点"、"系办电话"对关键字段"学号"的传递函数依赖。

    它也会存在数据冗余、更新异常、插入异常和删除异常的情况。

    根据第三范式把学生关系表分为如下两个表就可以满足第三范式了:

    学生:(学号,姓名,年龄,性别,系别);

    系别:(系别,系办地址、系办电话)。

    上面的数据库表就是符合1NF,2NF,3NF的,消除了数据冗余、更新异常、插入异常和删除异常。

     


     

    BCNF的例子

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

    若:

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

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

     

    已知,

    函数依赖集:仓库名 → 管理员,管理员 → 仓库名,(仓库名,物品名)→ 数量

    (管理员,物品名)(仓库名,物品名)

    主属性:仓库名、管理员、物品名

    非主属性:数量


    因为 不存在 非主属性 对码的部分函数依赖和传递函数依赖,所以 此关系模式属于3NF。

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

    preview

    好,既然此关系模式已经属于了 3NF,那么这个关系模式是否存在问题呢?

    我们来看以下几种操作:

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

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

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

    解决办法就是拆分成两个表,要在 3NF 的基础上,消除主属性【仓库名】对于【(管理员,物品名)】的部分与传递函数依赖。

    将原来的仓库(仓库名,管理员,物品名,数量)

    修改为:

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

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

     


    3 参考文献:

    王珊 萨师煊.《数据库系统概论》第四版

    数据库范式

    数据库的三大范式以及五大约束

    如何解释关系数据库的第一第二第三范式?

    数据库范式简单讲解(1NF、2NF、3NF、4NF、BCNF)

    展开全文
  • 文章目录数据库的设计范式都包括哪些数据表中的那些键从 1NF3NF总结 在日常工作中,我们都需要遵守一定的规范,比如签到打卡、审批流程等,这些规范虽然有一定的约束感,却是非常有必要的,这样可以保证正确性...
  • 数据库3范式(3NF)的理解

    千次阅读 2016-09-06 15:29:49
    标准化表示从你的数据存储中移去数据冗余(redundancy)的过程。如果数据库设计达到了完全的标准化,则把所有的表通过关键字连接在一起时,不会出现任何数据的复本(repetition)。...第一范式(1NF;The First Norma
  • 2.在保证F是最小函数依赖集的前提下,将关系模式转为3NF且保持函数依赖:①按左部相同原则分组;②将具有包含关系的依赖集进行合并;③判断最后的依赖集是否包含候选键,不包含的话为3NF且保持函数依赖 3.不包含的话...
  • 4NF详析引言范式种类第一范式(1NF)符合1NF关系中的每个属性都不可再分存在问题第二范式(2NF)在1NF基础上消除了非主属性对码的部分函数依赖二范式判断步骤优缺点第三范式(3NF)在2NF基础上消除非主属性对码的...
  • 文章目录一、范式分类二、规范化(提高关系模式级别)3NF分解方法BCNF分解方法 一、范式分类 第一范式(1NF):字段都是单一属性的,分量不可再分。这个单一属性由基本类型构成,包括整型、实数、字符型、逻辑型、...
  • 关系模式的范式主要有4种,即第一范式(1NF)、第二范式(2NF)、第三范式(3NF)和BCNF范式。满足这些范式条件的关系模式可以在不同程度上避免冗余问题、插入问题、更新问题和删除问题。 符合高一级范式的设计,...
  • 关系数据库(1NF 2NF 3NF BCNF 的定义)

    千次阅读 2019-06-19 09:29:34
    关系模式设计不合理带来的问题: 数据冗余 数据修改复杂 插入异常(应该插入的数据不能执行插入操作) 删除异常(不应该删除的数据被删除) 函数依赖的定义: X->Y 非平凡函数依赖/平凡函数依赖:Y不包含于X则为非...
  • 星型模型、雪花模型3NF、OLAP

    千次阅读 2020-02-03 17:45:04
    关系型数据库管理系统中实现的维度模型称为星型模型,其中每个维度表都直接和事实表连接,数据存在冗余。 星型模型的两个关键部件 1、 事实表 事实表存储组织业务过程事件的性能度量结果。来源于同一个业务过程的...
  • 3NF、BCNF和4NF基本概念和分解

    万次阅读 多人点赞 2018-01-20 19:28:13
    定义:如果关系模式R∈2NF,且每个非主属性都不传递函数依赖于R的主关系键,则称R属于第三范式,简称3NF。 1、把一个关系模式分解成3NF,使它具有保持函数依赖性 算法如下: 其中提到了最小函数依赖集,那么最小...
  • 1NF是所有关系型数据库的最基本要求, 第二范式(2NF) 2NF在1NF的基础之上, 消除了非主属性对于码的部分函数依赖。 第三范式(3NF3NF在2NF的基础之上,消除了非主属性对于码的传递函数依赖。
  • 一、缘由:  要做好DBA,就要更好地理解数据库设计范式。数据库范式总结概览:   ... 为了更好地理解数据库的设计范式,这里借用一下知乎刘慰... 首先要明白”范式(NF)”是什么意思。按照教材中的定义,范式...
  • ◆ 第一范式(1NF):强调的是列的原子性,即列不能够...◆ 第三范式(3NF):首先是 2NF,另外非主键列必须直接依赖于主键,不能存在传递依赖。 首先主键列A,和非主键B都完全依赖于主键。(先满足2NF) 同时不能存在
  • 所谓第一范式(1NF)是指在关系模型中,对于添加的一个规范要求,所有的域都应该是原子性的,即数据库表的每一列都是不可分割的原子数据项,而不能是集合,数组,记录等非原子数据项。即实体中的某个属性有多个值时...
  • 模式分解(2NF3NF

    千次阅读 多人点赞 2019-03-19 14:53:04
    3、判断是否等于U,若相等,则。判断是否等于,若相等,则。否则继续执行第二步,i++。 例:有关系,,,求。 令 由得, 由得, 故 求候选码 1、把函数依赖集F中的属性分为L类、R类、LR类和N类。 L类:只...
  • [MySQL] 关系型数据库的设计范式 1NF 2NF 3NF BCNF 一、缘由:  要做好DBA,就要更好地理解数据库设计范式。数据库范式总结概览:    为了更好地理解数据库的设计范式,这里借用一下知乎刘慰老师的解释,很...
  • 数据仓库可能大家非常熟悉的两位建模理论的创始人:William H.Inmon 和 Ralph Kimball,对应的 Inmon 主要的模型是:实体-关系模型, Kimball主导的模型是:维度模型 本片文章的目录: 0.数据库三范式回顾 1...
  • 人们常说的3NF是什么?

    千次阅读 2019-07-30 12:58:43
    所以在建立数据模型时,经常会考虑是否符合Codd提出的前三个范式,也就是人们常说的3NF建模。下面就详细说明一下三大范式: 第一范式 第一范式要求表中的行是唯一的,也就是不存在两个完全一样的行。如果一个表可以...
  • 一个优秀的关系模式的分解应当满足三个条件:消除异常(冗余、更新异常、删除异常),信息的可恢复以及依赖的保持。  对关系数 据库模式进行BCNF分解之后可以消除FD带来...在BCNF的基础上引入3NF,放松对BCNF条件的限
  • 数据库中转化为3NF的几个分解算法

    千次阅读 多人点赞 2019-03-03 17:11:35
    【例】关系模型R&lt;U,F&gt;,U={A,B,C,D,E},F={A→BC,ABD→CE,E→D} 算法一:将关系R转化3NF的保持函数依赖的分解 第一步:首先计算出F的最小依赖集(算法详见最小函数依赖),得到F'={A→BC,...
  • 模式分解详解,分解为3NF与分解为BCNF

    千次阅读 多人点赞 2020-03-04 23:06:04
    3NF:不存在非主属性对码的传递函数依赖或部分函数依赖。 如AB-C,A->C 码为(A,B),A,B是主属性,C是非主属性,C部分函数依赖于码,即不满足3NF BCNF:每个决定因素都包含码(相比于3NF,优点是加上了对主...
  • 数据库三范式3NF指什么?

    千次阅读 多人点赞 2020-04-21 14:24:54
    三范式面试的时候问的比较多,概念需要了解下: 第一范式(1NF):要求数据库表的每一列都是不可分割的...第二范式(2NF):在1NF的基础上,非码属性必须完全依赖于候选码(在1NF基础上消除非主属性对主码的部分函数...
  • (4)数据依赖F对关系模式的影响1️⃣ 数据冗余(Data redundancy)2️⃣ 更新异常(update anomalies )3️⃣ 插入异常(insertion anomalies )4️⃣ 删除异常( deletion anomalies)2.规范化---改造关系模式,解决插入...
  • 数据库范式讲解(1NF、2NF3NF、4NF、BCNF)

    千次阅读 多人点赞 2018-05-23 09:45:05
    一、概念 R-关系模式 r-关系 U-属性集 FD-函数依赖 X→Y:"X函数决定Y","Y函数依赖于X"。 A⊆B A包含于B,A小,B大,B→A 元组:二维表中的行 属性:二维表中的列 超键:能唯一标识...
  • 一、关系  表与表之间的关系,有三种:  一对一:A表的一条记录只能与B表的一条记录相对应,反之亦然。  一对多(多对一):A表的一条记录能与B表的多条记录相对应,B表的一条记录只能与A... 范式有6层(1NF,...
  • (1):要确保R是BCNF,就要在3NF的基础上,满足条件消除主属性对码的部分依赖与传递依赖。 则:当属性组BC也是关系模式R的候选码时,R是BCNF。 此时有:A →BC,BC →A成立。 (2):对于左侧为多属性的函数依赖集求...
  • 说明:在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。 2NF 第二范式是指在1NF基础上,消除部分函数依赖。看定义可能不好理解,看看下面例子,再...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 26,678
精华内容 10,671
关键字:

关系模型3nf