精华内容
下载资源
问答
  • 关系数据库规范化理论

    千次阅读 2016-03-16 22:53:23
    关系数据库规范化理论

    本文来源于:http://blog.sina.com.cn/s/blog_4d73b3a7010008st.html

    关系型数据库在设计时应该遵守一定的规则,即遵循数据库的范式理论。数据库的数据是一切操作的基础,如果数据库设计不好,利用其它方法来提高数据库性能的效果都将是有限的。而设计的关键是如何使数据库能合理地存储用户的数据,方便用户进行数据处理。
    规范化理论是将一个不合理的关系模式如何转化为合理的关系模式理论,规范化理论是围绕范式而建立的。规范化理论认为,一个关系型数据库中所有的关系,都应满足一定的规范。规范化理论把关系应满足的规范要求分为几级,满足最低要求的一级叫做第一范式(1NF),在第一范式的基础上提出了第二范式(2NF),在第二范式的基础上又提出了第三范式(3NF),以后又提出了BCNF范式,4NF,5NF。范式的等级越高,应满足的约束条件也越严格。规范的每一级别都依赖于它的前一级别,例如若一个关系模式满足2NF,则一定满足1NF。
    下面我按照范式设计级别依次介绍1NF(第一范式)、2NF(第二范式)、3NF(第三范式)和BCNF,4NF(第四范式)和5NF(第五范式)。
    第一范式(1NF):在数据库表中,要求每个属性值都是不可再分的,则该关系满足第一范式。
    如:某关系表SC由 STUDENT_ID(学生编号)和COURSE(课程名称)两个属性组成。这样的关系模式在实际应用过程中会存在这样问题,一个学生可以同时选择多门课程,现将此关系中STUDENT_ID作为关键字,COURSE字段中存在了多个值的情况,象这样:


    STUDENT_ID

    COURSE

    001

    中国文化史概要、音乐欣赏

    002

    音乐欣赏、程序设计

    这样的关系即不满足第一范式的要求。实际应用中,在设计表时,都应该满足第一范式要求。


    STUDENT_ID

    COURSE

    001

    中国文化史概要

    001

    音乐欣赏

    002

    音乐欣赏

    002

    程序设计

    解决方法:

     

     

     




    第二范式(2NF):如果某关系满足第一范式,而且它的所有非关键字属性都完全依赖于整个主关键字(不存在部分依赖),则该关系满足第二范式。
    如:关系LESSON(课程表):由SNO,CNO,GRADE,CREDIT四个属性组成,其中SNO为学号、CNO为课程号、GRADEGE为学生成绩、CREDIT为学分。根据这个关系,关键字为组合关键字(SNO、CNO)。
    在应用中使用这个关系模式可能存在以下问题:
    a.更新异常。若调整了某课程的学分,相应的元组CREDIT值都要更新,有可能会出现同一
    门课学分不同的情况。
    c.插入异常。如计划开新课,由于没人选修,没有学号关键字,只能等有人选修才能把课程
    和学分存入。
    d.删除异常。若学生已经结业,从当前数据库删除选修记录。某些门课程新生尚未选修,则
    此门课程及学分记录无法保存。
    分析原因:非关键字属性CREDIT仅依赖于CNO这个字段,也就是CREDIT部分依赖组合关键字(SNO,CNO)而不是完全依赖。
    解决方法:将其实原有关系分成两个关系STUDENT(SNO、CNO、GRADE),LESSON(CNO、CREDIT)。这样的两个关系都满足第二范式的要求。

    第三范式(3NF):如果某关系模式满足第二范式,而且它的任何一个非主属性都不传递依赖于任何关键字,则满足第三范式。
    例:关系S1(SNO、SNAME、DNO、DNAME、LOCATION) ,属性依次代表学号、姓名、所在系编号、系名称、系地址。 关键字SNO决定各个属性,满足2NF。但这样的关系肯定会使数据有大量的冗余,有关学生DNO,DNAME,LOCATION三个属性将重复插入、删除和修改。
    分析原因:关系中存在传递依赖造成的。即SNO决定DNO,DNO决定LOCATION,但SNO不能直接决定LOCATION, 而是通过DNO传递依赖实现的,所以不满足第三范式。
    解决方法:将其分为两个关系 S(SNO,SNAME,DNO),D(DNO,DNAME,LOCATION)。

    BCNF:如果关系R的所有属性中,若每个决定因素都包含候选关键字,则称关系R属于BCNF。
    例:关系SLT(SID、LESSON、TEACHER),SID为学生编号、LESSON为课程名称、TEACHER为授课教师,其中SID为关键字,经分析该关系满足第三范式,分析(SID、LESSON)决定授课教师,(SID、TEACHER)决定课程,TEACHER决定LESSON,由于TEACHER不是关键字,所以不满足BCNF。
    解决方法:;C(SID、TEACHER),T(TEACHER、LESSON)。

    第四范式(4NF):若关系模式R每个非平凡多值依赖X→→Y,X都含有候选键,则该关系模式满足第四范式。
    如:关系RR(SBM、CZDM、SCCJ),其中SBM设备名称、CZDM厂站代码、SCCJ生产厂家。
    分析:对于设备名称,无论生产厂家是谁,都会有一组值对应厂站代码即SBM→→CZDM,同理对设备名称,无论厂站代码是谁,都会有一组值对应生产厂家即SBM→→SCCJ。由于两个多值依赖的左端都不含候选键,所以不满足第四范式。
    解决方法:RR_1(SBM、SCCJ),RR_2(SBM、CZDM)。

    第五范式(5NF):如果关系模式中,每一个连接依赖,都包含由关系中候选键,则称为该关系模式满足第五范式。
    例如有一个关系R1中


    A

    B

    C

    A1

    B1

    C1

    A2

    B1

    C2

    A1

    B2

    C1

    A2

    B2

    C2

    分析:在关系中A、B、C均为关键字。从上表中可以看出,表中存在大量冗余的数据。
    解决方法:可以将其拆分成下面的三个关系RA、RB、RC。

    RA

    RB

    RC

    A

    B

    B

    C

    C

    A

    A1

    B1

    B1

    C1

    C1

    A1

    A1

    B2

    B1

    C2

    C1

    A2

    满足第五个范式。
    将一个关系分解成多个关系,要使得分解有意义,起码的要求是分解后不丢失原来的信息。这些信息不仅包括数据本身,而且包括由函数依赖所表示的数据之间的相互制约。进行分解的目标是达到更高一级的规范化程度,但是分解的同时必须考虑两个问题:无损联接性和保持函数依赖。有时往往不可能做到既有无损联接性,又完全保持函数依赖。需要根据需要进行权衡。

    小结:
    规范化目的是使结构更合理,消除插入、修改、删除异常,使数据冗余尽量小,便于插入、删除和更新。
    原则:遵从概念单一化 “一事一地”原则,即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。
    方法:将关系模式投影分解成两个或两个以上的关系模式。
    要求:分解后的关系模式集合应当与原关系模式“等价”,即经过自然联接可以恢复原关系而不丢失信息,并保持属性间合理的联系。
    注意:一个关系模式结这分解可以得到不同关系模式集合,也就是说分解方法不是唯一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现。其根本目标是节省存储空间,避免数据不一致性,提高对关系的操作效率,同时满足应用需求。实际上,并不一定要求全部模式都达到BCNF不可。有时故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高,查询频度极高的数据库系统更是如此。
    现在做数据库设计,很少有人可以做到很符合范式的。一般说来,第一范式大家都可以遵守,如果设计的数据库能遵守前三个范式,就可以啦,因为范式越高,可能也会BCNF的范式出现机会较少,而且会破坏完整性,你可以在做设计之时不考虑它。希望大家在设计数据库时,一定要全面考虑各方面的问题,根据实际情况出发,然后再确定是否应该满足更高范式。


    展开全文
  • 4.1 数据依赖 4.1.1 关系模式中的数据依赖 概念回顾 关系模式的形式化定义 4.1.2 数据依赖对关系模式的影响 什么是数据依赖 关系模式的简化表示 数据依赖与关系模式 ...4.3.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 关系模式的分解

    将关系模式分解为范式

    展开全文
  • 关系数据库规范化的通俗理解

    千次阅读 2019-05-26 11:17:35
    最近参加数据库系统工程师的考试,结合自己的工程经验,终于对数据库规范化理论有了一知半解。 本文试图从工程化的角度,用大白话去解释数据库规范化的结论,如果有不严谨之处,敬请指正。我不会去详细介绍每个范式...

    在大学的时候就已经对数据库范式的概念有所耳闻,但是一直是仅仅知道有这么一个概念。最近参加数据库系统工程师的考试,结合自己的工程经验,终于对数据库规范化理论有了一知半解。
    本文试图从工程化的角度,用大白话去解释数据库规范化的结论,如果有不严谨之处,敬请指正。我不会去详细介绍每个范式的严格定义,重复别人的结论没有意义;也不会去解释为什么是这个结论,因为我这种俗人已经没办法理解那些神仙证明了!

    第一范式(1NF)

    这个很容易理解,就4个字,原子属性。如果你的关系模式连1NF都不满足,那就是有各种对象嵌套了,这种情况选择一个NoSql数据库可能更合适。

    第二范式(2NF)

    在1NF基础上,每一个非主属性完全依赖于码(主键)。

    概念解释:
    1、非主属性:在某关系模式的一组属性中,如果一个属性有可能被选中作为主键(包括多主键的其中一个),它就是主属性,否则就是非主属性

    2、依赖:依赖和决定是一对,符号表示X→Y,我们可以说X决定Y或Y依赖于X,例如身份证号与姓名的关系即为:身份证号→姓名。注意要把X和Y当做集合来看待,而不是单一属性!由此可以引申出一些概念:X→Y且Y是X的子集,就是平凡的函数依赖(工程实践中很少见),否则就是非平凡的函数依赖。如果X的任何真子集都不能决定Y,那么Y对X就是完全函数依赖,否则就是部分函数依赖

    理解了上述的概念2NF也就很容易理解了。很多关系模式中的码往往是一个属性集合,只有它的所有非主属性对码都是完全函数依赖,这个关系模型才符合2NF。下面这个例子就是不符合2NF的:

    工作经历(公司ID身份证号,姓名,开始时间,结束时间)

    关系“工作经历”的码是{公司ID,身份证号},这里面的“身份证号→姓名”显然就是部分函数依赖关系,因此不符合2NF。

    第三范式(3NF)

    在2NF基础上,不存在非主属性对码的传递函数依赖。

    概念解释:

    1、传递函数依赖:若X→Y,Y→Z,则X→Z成立,Z对X是传递函数依赖。非常简单的概念。

    因此3NF也并不难理解,一个不符合3NF的典型例子就是用户管理的场景,在设计开发用户管理模块的过程中,展示用户往往需要同时展示用户所属的组织机构,这时如果设计用户关系如下:

    用户(用户ID,姓名,机构ID,机构名称)

    主键为“用户ID”,存在传递函数依赖:用户ID→机构ID→机构名称,显然不符合3NF。

    巴克斯范式(BCNF)

    在3NF的基础上,消除了主属性对码的部分函数依赖和传递函数依赖。

    说白了,就是把2NF和3NF留下的坑给填上了,因为2NF和3NF说的都是非主属性和码之间的依赖关系,BCNF则把主属性也加入到相应的约束之中,可以说,在满足BCNF的关系中,部分函数依赖和传递函数依赖是完全不存在的。因此从函数依赖的角度来说,BCNF就是规范化程度最高的关系模式!

    在工程实践中,传统的信息系统数据库设计会要求满足3NF,而且我们习惯于用自增序列或UUID去生成单一的主键,因此我们设计的数据库一般都是符合BCNF的。

    第四范式(4NF)

    属性间不允许有非平凡且非函数依赖的多值依赖。

    我查阅了一些资料和案例,发现资料上的描述很枯燥晦涩,而案例的描述又语焉不详,为了彻底理解4NF,此处采用官方定义与案例结合的方式。下面的多值依赖定义是官方定义。

    概念解释:

    1、多值依赖

    设R(U)是属性集U上的一个关系模式。X,Y,Z是U的子集,并且Z=U-X-Y。关系模式R(U)中多值依赖X→→Y成立,当且仅当对R(U)的任一关系r,给定的一对(x,z)值有一组Y的值,这组值仅仅决定于x值而与z值无关。

    上述的定义简单理解就是属性之间存在多对多关系。但是之前我一直不明白的是为什么要引入一个看似无关的Z,实际上Z的作用就是判断这个多值依赖是不是平凡的。

    若X→→Y,而Z为空集,则称X→→Y为平凡的多值依赖;若Z不为空,则称其为非平凡的多值依赖。

    我们现在构建如下场景:公司安排招聘面试,同一个职位可以属于多个部门,同一个部门拥有多个职位,面试官由员工担任,同一个面试官可以负责多个职位的面试,一个职位也可以由多个面试官参与面试。得到如下关系模式(3属性主键):

    面试安排(职位编码部门编码面试官工号

    此时设X={职位编码},Y={部门编码},Z={面试官工号};

    显然存在X→→Y,而Z不为空集,因此这个多值依赖是非平凡的;函数依赖要求Y的值是被X的一个或一组值唯一确定的,X→Y只是X→→Y的一个特例,因此X→→Y是非函数依赖的多值依赖。X→→Y这个依赖关系是非平凡且非函数依赖的多值依赖,所以关系模式“面试安排”不符合4NF。同理,X→→Z也是非平凡且非函数依赖的多值依赖。

    对关系模式“面试安排”进行符合4NF的分解为:

    面试安排1(职位编码面试官工号)面试安排2(职位编码部门编码

    则上述两个关系模式中的多值依赖退化成了平凡的多值依赖(因为第三方的Z变成了空集),也就满足了4NF的定义。

    还可以对照4NF的官方定义对比:

    4NF定义:关系模式R<U,F>∈1NF,如果对于R的每个非平凡多值依赖X→→Y(Y 不包含于X),X必含有码,则R∈4NF。

    对于X必含有码,也就是说主键是它的子集这个要求似乎很难达到了,因此实际工作中我们大多数情况下都致力于消除非平凡的多值依赖,让它退化成平凡多值依赖也就脱离了4NF的限制了。

    有人提出一个简单的判断4NF的方法就是,对于一个有3个属性的表,给定其中某属性一个值,另外两个属性对应的两列没有多对多关系,那就是4NF。这个方法用于快速判断4NF还是很可取的。

    第五范式(5NF)

    这个还没研究过,没有任何工程经验和体会,考试也不会考,想了解的自行修仙吧哈哈!

    总结:

    在传统的信息系统的构建过程中,数据库的范式标准越高,对应的数据冗余度就越低,但是系统的关联关系会更加复杂。范式的选择实际上就是数据冗余度与系统复杂度之间的平衡。从经验上来说,选择3NF或BCNF可能是实践的最优解了,但即使如此,依然给应用程序的开发带来了很大的麻烦,当你需要获取业务数据时,往往需要编写大量的连接查询的SQL语句。其实数据库的设计应该提供一套完整的解决方案,应该具备配套的视图、存储过程、触发器以及外键的删除更新级联等以减轻应用开发人员的负担,而非只是完成建表就万事大吉。

    最后,作为技术人员,一定不要完全放弃编码,就像战士永远不要放下手中的剑。保持手感,保持对技术的敏感,不断思考总结,一定会有量变到质变的那一天。

    展开全文
  • 关系数据库规范化理论之范式

    千次阅读 2017-11-09 22:27:30
    因为在写项目时与同伴关于数据库到底建多少张表,每张表应包含哪些属性产生分歧,所以又好好研究了一下关系型数据库在设计时应该遵守怎样的规则...在阅读本篇文章前读者须掌握关系数据库结构基础及函数依赖与键的定义。

    因为在写项目时与同伴关于数据库到底建多少张表,每张表应包含哪些属性产生分歧,所以又好好研究了一下关系型数据库在设计时应该遵守怎样的规则以提高数据库性能。

    在阅读本篇文章前读者须掌握关系数据库结构基础及函数依赖与键的定义。
    可直戳以下目录空降相关知识点↓↓↓


    首先要明确关系模型可能存在的异常有:**数据冗杂,更新异常,插入异常,删除异常。**所有范式存在的意义不过是为了消除这些异常。满足最低要求的一级叫做第一范式(1NF),在第一范式的基础上提出了第二范式(2NF),在第二范式的基础上又提出了第三范式(3NF),以后又提出了BCNF范式,4NF,5NF。范式的等级越高,应满足的约束条件也越严格。规范的每一级别都依赖于它的前一级别。

    首先我们给出一张数据表,该表涵盖我们所要记录的所有属性
    该关系模式为:
    SLC(Sno,Sname,Sdept(所在系),Loca(住处),Cno(课程号),Grade(成绩))
    Sno | Sname |Sdept|Loca|Cno|Grade
    -------- | —
    03001 | 甲|网络工程|A|C1|95
    03001 | 甲|网络工程|A|C2|88
    04001 | 乙|计算机科学与技术|B|C2|93
    04001 | 乙|计算机科学与技术|B|C4|75
    03002 | 丙|网络工程|A|C1|77
    02001 | 丁|网络工程|A|C5|82
    02002 | 戊|计算机科学与技术|B|C2|87

    第一范式(1NF)

    如果关系模式R中的所有属性都是不可分的数据项,则称R属于第一范式,记为R∈1NF。

    对数据表进行分析,可知其每个属性都不可再分,既满足1NF,但由于只有属性Grade对键(Sno,Cno)是完全函数依赖,而其他非主属性都是对键的部分函数依赖,也正是因为关系中存在部分函数依赖,导致数据操作中必然会存在异常,故需要运用投影运算将关系模式SLC进行分解,转向更高一级范式。

    第二范式(2NF)

    若关系模式R∈1NF,且每个非主属性都完全依赖于R的键,则R∈2NF。

    关系SLC中,Sno、Cno为主属性,Sname,Sdept,Loca,Grade均为非主属性,Grade对键是完全函数依赖,其余非主属性对键均为部分函数依赖,所以SLC∉2NF。
    为消除关系模式SLC中的部分函数依赖,我们采用投影分解法,将部分函数依赖从SLC中分解出来,得到以下两个关系模式:
    SC:(Sno,Cno)->[f]Grade
    SL:(Sno->[f]Sname, Sno->[f]Sdept, Sno->[f]Loca)
    分解后关系模式SC和SL的非主属性对键都是完全函数依赖,所以SC∈2NF,SL∈2NF。

    满足2NF后我们再分析对数据进行操作时可能出现的异常问题是否得到有效解决:
    ①插入异常:
    【已解决】若学生未选课,仍能将相关信息插入表SL中。
    【未解决】若某系还未进行招生,即Sno为空时,该系相关信息无法插入。
    ②删除异常:
    【已解决】即使删除SC表中某个学生的全部选课信息,但表SL中仍有其其余信息存在。
    【未解决】若某系所有学生毕业,删除全部学生信息的同时,该系的相关信息也被删除了。
    ③更新异常:
    【已解决】因为学生的选课信息与基本信息分别存储在两张表中,基本信息在SL表中只保存了一次,所以当学生的基本信息(如姓名)产生变化时,Sname的值只需要修改一次,减少了数据冗杂。
    【未解决】若某系改名,则要对每个学生记录中的Sdept进行修改。
    ④数据冗杂
    【未解决】一个系中有多个学生,对每个学生记录,相关的Sdept和Loca都要储存一次。

    因此SL仍不是一个好的关系模式,需要对其进行进一步分解,转化为更高一级的范式。

    第三范式(3NF)

    对于关系模式R,每一个非主属性键既不部分函数依赖于键,也不传递函数依赖于键,则R∈3NF。

    关系模式SC中非主属性Grade既不部分函数依赖于键,也不传递函数依赖于键,所以SC∈3NF,但在关系模式SL中,由于Sno->Sdept, Sdept->Loca, Sdept-(×)>Sno,所以Sno->[t]Loca,所以SL∉3NF。因此仍要对SL进行投影分解,得到以下两个关系模式
    S(Sno,Sname,Sdept)
    L(Sdept,Loca)
    现在关系模式S和L中既不存在部分函数依赖,也不存在传递函数依赖,所以S∈3NF,L∈3NF。

    通常情况下,数据库的设计满足3NF即已达到标准,此时所有异常问题都能得到解决,但由于3NF只是规定了非主属性对键的依赖关系,没有限制主属性对键的依赖关系,若存在主属性对键的部分函数依赖和传递函数依赖关系,同样会出现数据冗杂,插入异常,更新异常,删除异常等问题,因此我们引入BC范式。

    BC范式(BCNF)

    关系模式R∈1NF,若X->Y,且Y∉X时X必为键(),则R属于BCNF。即在关系模式R中,若每一个决定因素都为键,则R一定属于BCNF。

    对于满足BCNF的关系模式,具有以下性质:
    ①所有非主属性都完全函数依赖于每个候选键。
    ②所有主属性都完全函数依赖于每个不包含它的键。
    ③没有任何属性完全函数依赖于非键的任何一组属性。

    简单来说,相比3NF,BCNF更为严格的一点就是要求R的每一个属性都不部分函数依赖于候选键且不传递函数依赖于候选键
    若R∈BCNF则R一定∈3NF,但反之不一定成立。

    例如对关系模式S(Sno,Sname,Sdept),S∈3NF,同时S中Sno是唯一的决定性因素,因此S∈BCNF。

    再例如,有一个关系模式City(Cname,Street,Code),其中Cname表示城市名,Street表示街道名,Code表示街道所在地区的邮政编码,其上所具有的函数依赖关系为:
    (Cname,Street)->Code, Code->Cname
    候选键为(Cname,Street)和(Code,Street),不存在非主属性,故City∈3NF,但决定因素Code不是键,所以City∉BCNF。

    再举一例,有一个关系模式STJ(S,T,J),其中S表示学生,T表示教师,J表示课程,每个教师只讲授一门课程,每门课程可由多个教师讲授,某一学生选定某门课程,就对应一个确定的教师,因此可得如下函数依赖:
    (S,J)->T,(S,T)->J,T->J
    (S,J)和(S,T)都是候选键,所以该关系中的S、T、J均为主属性,不存在非主属性键,也就不存在非主属性对键的部分函数依赖和传递函数依赖,STJ∈3NF,但STJ∉BCNF,因为在T->J中,T是决定因素,但T不是键。

    对于关系模式STJ,我们可举一条实例分析不是BCNF的关系模式将会存在怎样的异常问题
    学生S |教师T|课程J
    -------- | —
    甲 | 教授A|大学语文
    乙 | 教授A|大学语文
    丙 | 教授B|大学语文
    丁 | 教授B|大学语文
    乙 | 教授C|大学英语
    乙 | 教授D|大学英语
    乙 | 教授E|C语言

    数据冗杂:每个教师只讲授一门课程,但选修了该门课程的多个学生记录中都要存储教师信息。
    插入异常:若学生还没有选课,则教师及课程的信息无法录入,因为主属性此时为空。
    更新异常:当课程改名后,所有选修了该课程的学生纪录需要逐条修改属性J的值,容易造成数据的不一致,破坏数据库完整性。
    删除异常:若选修了某门课程的所有学生毕业,在删除所有学生信息的同时,有关课程的信息也被删除了。
    因此,将该关系模式分解为以下两个关系模式:ST(S,T)和TJ(T,J),他们间存在的函数依赖为S->T,T->J
    此时关系模式ST和TJ均达到BCNF,从而解决上述提到的异常。

    一个关系模式如果达到了BCNF,那么在函数依赖范畴内,它就已经实现了彻底的分离,消除数据操作中可能出现的异常。

    多值依赖与第四范式(4NF)

    ###①多值依赖

    在关系模式中,函数依赖不能表示属性值之间的一对多联系,这些属性之间有些虽然没有直接关系,但存在间接的关系,把没有直接联系、但有间接的联系称为多值依赖的数据依赖。
    简单来说,在函数依赖中,X与Y是否存在函数依赖关系,只需考察X,Y的两组属性,与别的属性无关。而在多值依赖中,X与Y是否存在多值依赖还需看属性Z。
    数学定义: 设R(U)是一个属性集合U上的一个关系模式,X, Y, 和Z是U的子集,并且Z=U-X-Y,多值依赖X->->Y成立当且仅当对R的任一个关系r,r在(X,Z)上的每个值对应一组Y的值,这组值仅仅决定于X值而与Z值无关。
    平凡的多值依赖与非平凡的多值依赖:
    若X->->Y,而Z为空集,则称X->->Y为平凡的多值依赖;若Z不为空,则称其为非平凡的多值依赖。
    多值依赖的缺点在于数据冗杂太大。

    举例:有这样一个关系 <仓库管理员,仓库号,库存产品号> ,假设一个产品只能放到一个仓库中,但是一个仓库可以有若干管理员,那么对应于一个 <仓库管理员,库存产品>有一个仓库号,而实际上,这个仓库号只与库存产品号有关,与管理员无关,就说这是多值依赖。

    多值依赖具有以下性质:
    ①对称性:若X->->Y,则X->->Z,其中Z=U-X-Y
    ②传递性:若X->->Y,Y->->Z,则X->->Z-Y
    ③合并性:若X->->Y,X->->Z,则X->->YZ
    ④分解性:若X->->Y,X->->Z,则X->->(Y∩Z),X->->Z-Y,X->->Y-Z均成立,也就是说两个相交的属性子集均多值依赖于另一个属性子集,则这两个属性子集因相交而分割成的3部分也都多值依赖于该属性子集。
    **⑤函数依赖可以看作是多值依赖的特例。**若X->Y,则X->->Y,因为,当X->Y时,对X的每一个取值x,Y有一个确定的值y与之相对应,所以X->->Y。

    那么若想上例中的关系模式消除多值依赖,作模式分解,使子模式的Z=Ø,仅有平凡多值依赖,即子模式为R1(仓库号,仓库管理员),R2(仓库号,库存产品号)
    ###②第四范式4NF
    在多值依赖的基础上我们引入第四范式的概念

    设关系R(X,Y,Z),其中X,Y,Z是成对的、不相交属性的集合。若存在非平凡多值依赖,则意味着对R中的每个属性Ai(i=1,2…n)存在有函数依赖 X->Ai(X必包含键)。那么R∈4NF。
    第四范式限制关系模式的属性之间不允许出现非平凡且非函数依赖的多值依赖。因为对于每一个非平凡的多值依赖X->->Y,X都含有键,所以X->Y,故4NF所允许的非平凡的多值依赖实际上就是函数依赖。
    若关系属于4NF,则它必属于BCNF;而属于BCNF的关系不一定属于4NF

    在上述关系模式 <仓库管理员,仓库号,库存产品号>中,键是(仓库管理员,仓库号,库存产品号),仓库号->->仓库管理员,仓库号->->库存产品号,但仓库号并不是一个键,因此该关系不是4NF,而分解成R1(仓库号,仓库管理员),R2(仓库号,库存产品号)后,虽然仍存在仓库号->->仓库管理员,仓库号->->库存产品号,但他们是平凡的多值依赖,所以R1∈4NF,R2∈4NF。

    如果只考虑函数依赖,则BCNF的关系模式规范程度已经达到最高
    如果考虑多值依赖,那么4NF的关系模式规范化程度最高
    另外还有其他数据依赖如连接依赖,多值依赖是连接依赖的一种特殊情况。在消除4NF关系模式中存在的连接依赖后则可进一步达到5NF,这里不再赘述。

    关系模式的规范化步骤

    (1)取原始的1NF关系投影,消去非主属性对键的部分函数依赖,从而产生一组2NF关系。
    (2)取2NF关系的投影,消去非主属性对键的传递函数依赖,产生一组3NF关系。
    (3)取这些3NF的投影,消去决定因素不是键的函数依赖。产生一组BCNF关系。
    (4)取这些BCNF关系的投影,消去其中不是函数依赖的非平多值依赖,产生一组4NF关系。

    总结

    规范化程度越高,分解就越细,所得关系的数据冗杂就越小,异常情况也就越少,但同时也增大了系统对数据检索的开销,降低了数据检索的效率。系统只有对这些细分的关系进行自然连接,才能获取所需的信息,而连接操作所需的系统资源和开销是比较大的,因此,规范化程度越高的关系模式并非是最好的。
    规范化应满足的基本原则是由低到高,逐步规范,权衡利弊,适可而止。通常以满足第三范式为基本要求。

    参考文献:孟彩霞. 数据库系统原理与应用[M]. 人民邮电出版社: 2008.

    展开全文
  • 什么是数据库规范化 维基百科的定义如下: 数据库规范化,又称数据库或资料库的正规化、标准化,是数据库设计中的一系列原理和技术,以减少数据库中数据冗余,增进数据的一致性。 数据库范式是埃德加·科德设计...
  • 指出了从关系数据库、面向对象数据库到XML数据库等各发展阶段中数据库规范化问题的特点、主要思想和关键方法,描述了数据库规范化理论的重要研究成果以及存在的问题,指出将形式概念分析方法引入数据库规范化中,...
  • 逻辑设计:模型校验,设计规范化(生成关系表/二维表) 什么是不好的关系模式   函数依赖 数据依赖:在计算机科学中,数据依赖是指一种状态,当程序结构导致数据引用之前处理过的数据时的状态。其中最重要的是...
  • 数据库规范化理论

    千次阅读 2018-06-24 09:57:39
    本文版权归作者AlvinZH和博客园所有,欢迎转载和商用,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律...其中D、DOM与模式设计关系不大,可以看作三元组R&lt;U,F&gt;...
  • 数据库设计中关系规范化理论总结

    千次阅读 多人点赞 2020-07-31 11:08:14
    数据库是一门对数据进行有效管理的技术,它研究信息资源如何被...经过科学家的讨论研究,最终形成我们今天所看到的关系数据库规范化理论。本文通过例举具体事例来探讨关系规范化理论在数据库逻辑设计中的形成和方法。
  • 数据库规范化(范式)(一)

    千次阅读 2018-04-01 15:45:58
    ——转自:https://blog.csdn.net/hbrqlpf/article/details/1887204关系数据库规范化理论一个关系数据库由一组关系模式组成,一个关系由一组属性名组成,关系数据库设计就是如何把已给定的相互关联的一组属性名分组...
  • 根据候选码判断关系F中的函数关系是否满足第二范式,若不满足则为关系模式的规范化最高为第一范式 然后判断是否存在非主属性传递依赖,如果存在则不满足第二范式,如果不存在则关系模式的规范化最高为第三范式. 通俗...
  • 关系数据库设计是对数据进行组织和结构的过程,核心问题是关系模型的设计。关系模型是数学的、用二维表格数据描述各实体之间的联系的模型;它是所有的关系模式、属性名和关键字的汇集,是关系模式描述的对象。...
  • 数据库关系模式规范化

    千次阅读 2014-05-18 19:39:58
    第三范式的定义:如果关系模式R中的所有非主属性对任何候选关键字都不存在传递依赖,则称关系R是属于第三范式的。记作R 3NF。 如:学生关系模式S1(学号,姓名,系号,系名,系地址) (学号)为关键字,因是单属性...
  • 为什么要学习关系数据库规范化理论?(1)基本概念回顾(2)关系模式的形式化定义(3)什么是数据依赖F?(4)数据依赖F对关系模式的影响1️⃣ 数据冗余(Data redundancy)2️⃣ 更新异常(update anomalies )3️⃣ ...
  • 概念模型与关系模型和关系规范化

    万次阅读 2017-05-20 16:18:34
     概念模型用于信息世界的建模,是实现现实世界到信息世界的第一层抽象,是数据库设计人员进行数据库设计的有力工具,也是数据库设计人员和用户之间进行交流的语言,因此概念模型一方面具有较强的语义表达能力,能够...
  • 数据库规范化 (1NF, 2NF, 3NF, BCNF)

    千次阅读 2020-04-25 22:53:42
    最近在了解数据库规范化的四个等级, 一直有点模糊, 写个文章记录一下学习历程. 文章内容会时刻更新, 欢迎和感谢大家的一起交流
  • 数据库规范化设计理论摘要

    千次阅读 2011-06-02 19:15:00
    对于一个大项目来讲,数据库的设计命名规范是很重要的一个环节,好的表设计,让人看得很舒服,一看就明白是什么意思了,下面看到一篇很不错的数据库对象命名参考文档,所以整理分享给大家。 引言 ...
  • 数据库规范化设计理论摘要要

    千次阅读 2010-05-20 09:09:00
    SQL数据库设计规范参考之数据库对象命名详细文档时间:2009-12-16 13:23:29 来源:www.cnblogs.com 作者: -对于一个大项目来讲,数据库的设计命名规范是很重要的一个环节,好的表设计,让人看得很舒服,一看就明白是...
  • 数据库规范化理论---求候选键

    千次阅读 多人点赞 2018-01-21 11:16:01
    1、概念型算法 F的闭包: 在关系模式R<U,F>中为F所逻辑蕴含的函数依赖的全体叫作F的闭包,记为F+。 属性集X关于函数依赖集F的闭包: 设F为属性集U上的一组函数依赖,XÍU,XF+ ={A|X→A能由F根据...
  • 关系模式设计中的问题关系数据库设计要解决的主要问题 什么样的数据库模式才合理? 怎么分解才能满足要求? 衡量的标准是什么? 理论基础是什么? 如何进行实现? 关于好的数据库模式好的数据库模式是不会发生插入...
  • 文章目录关系数据库关系数据库简介关系数据结构及形式化定义关系操作关系模型的完整性关系代数 关系数据库 ...1972年提出了关系的第一、第二、第三范式的规范化理论 1974年提出了关系的BC范式 奠定
  • 关系代数 基本概念 传统的集合运算 专门的关系运算;1. 基本概念 1域 域是一组具有相同数据类型的值的集合 例如自然数整数实数一个字符串{男女}大于 10 小于等于 90 的正整数等都可以是域 ;2笛卡尔积 设D1D2Dn为任意...
  • 数据库设计之反规范化

    千次阅读 2013-06-24 10:13:27
    1、反规范的好处  ...所以,关系有时故意保留成非规范化的,或者规范化以后又反规范了,这样做通常是为了改进性能。  例如帐户系统中的“帐户”表B-TB01,它的列busi-balance(企业帐户的总余额)就违
  • 数据库知识基本概念

    万次阅读 2017-11-15 13:18:38
    数据库知识基本概念最近在学习数据库原理与应用,自己理解着整理出了一些基础的概念,有不同意见可以留言讨论: 数据和信息 数据库系统的组成 数据管理技术的发展阶段 *数据库系统的发展过程和发展趋势 数据模型 ...
  • 关系模式规范化(上)

    千次阅读 2013-03-19 13:45:11
    最近在学习数据库过程中,发现几本教材大都是按照数据库系统概论->关系数据库基础->SQL语言->关系数据库理论(大都是介绍规范化)介绍,第二部分的关系数据库基础主要谈到了基本算术运算关系...如果不考虑数据库规范化
  • 数据库概念

    千次阅读 2019-05-30 14:59:51
    分类: 数据库分为关系数据库和非关系数据库,常用的关系数据库有mysql和oracle数据库,nosql有redis等。 作用: 数据库技术是用来存储数据和管理数据的 数据库管理系统和数据库系统: 数据库管理系统是位于...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 102,484
精华内容 40,993
关键字:

关系数据库规范化的概念