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

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

    写在前面:大家好K。首先为你点进这篇有趣的文章点赞👍!文章在撰写过程中难免有疏漏和错误,欢迎你在下方留言指出文章的不足之处;如果觉得这篇文章对你有用,也欢迎你点赞和留下你的评论。更多内容请点进👉我的博客K。👈阅览。

    本文亮点:本文尽量使用通俗易懂的语言,避免教材式语言描述。本文较长,请耐心阅读。

    摘要:数据库是一门对数据进行有效管理的技术,它研究信息资源如何被安全地储存和如何被高效地利用,它是现代计算机科学的一个重要分支。其中关系数据库是目前被应用最广泛的数据库类型,它看起来类似于一张二维表,通过应用数学的方法来处理数据库中的数据。在关系数据库的设计过程中,最重要的莫过于对数据库的逻辑设计,即针对一个具体的问题,我们应该如何去构造一个适合它的数据库模式。经过科学家的讨论研究,最终形成我们今天所看到的关系数据库的规范化理论。本文通过例举具体事例来探讨关系规范化理论在数据库逻辑设计中的形成和方法。
    关键词:数据库;关系规范化理论;范式;函数依赖;属性

    1 关系规范化理论的几个相关概念

    1.1 数据依赖

    数据库的一张表中,数据之间存在着某种相互关系,也就是数据依赖,是各属性之间的相互约束的关系。把真实世界某一实体的属性的语义抽象出来,换句话说就是对某事物现实属性含义的数字化。研究者到目前为止已经提出了各种类型的许多种的数据依赖,函数依赖(Functional Dependency,FD)和多值依赖(Multi-Valued Dependency,MVD)是其中需要我们重点了解和学习的。

    1.1.1 函数依赖

    假设当前有个关系R(U),如有以下学生关系,属性有学生姓名、学号、学生年龄、科目和科目成绩,即用关系模型符号语言描述为Students(Sname, Sno, Sage, Subject, Grade),再假设属性集合有这两个子集,如X=Sno、Y=Sage。函数依赖是指,两个元组的Sno相同,则Sage一定相同,此时称Sno函数确定Sage或Sage函数依赖于Sno。
    只能根据对真实世界的某一具体关系的描述(语义)来确定一个函数依赖。例如如果说Sname函数确定Sage(两个相同的学生姓名,各自对应的年龄也一定相同),那么就一定要事先说明,在这个关系中,不能存在同名同姓的两同学,否则就会出现两个相同的学生姓名,各自对应的年龄不同的情况,这就不是Sname函数确定Sage。
    同理,此例中就不能说Subject函数确定Grade,因为通常学生选修相同的课程,最后的成绩是不相同的,即同一Subject对应了多个Grade的值,而前一个例子中Sno学号就只对应了该学生自己的Sage年龄。

    1.1.1.1 非平凡函数依赖

    如果X=(Sno, Sname)、Y=Sage,Sage是函数依赖于(Sno, Sname)这个属性集合的,类似这样Y不包含于X的函数依赖,称之为Y非平凡函数依赖于X。如果没有明确说明,一般是只在非平凡函数依赖的范围中讨论。

    1.1.1.2 平凡函数依赖

    如果X=(Sno, Sname, Sage)、Y=Sage,Sage是函数依赖于(Sno, Sname, Sage)这个属性集合的,可以看到Y是X的一个子集,X包含了Y,类似的函数依赖被称为平凡函数依赖。平凡函数依赖在所有的关系模式中都是一定成立的,它是固有的一种函数依赖,并不生成新的语义。

    1.1.1.3 完全函数依赖

    如果存在同名同姓的情况,且X=(Sname, Sage)、Y=Grade,X的真子集有空集∅、Sname和Sage,它们各自都不能函数确定Grade,显然空集∅不能函数确定科目成绩Grade,学生姓名Sname也不能函数确定科目成绩Grade,因为存在同名同姓的情况,学生年龄Sage也不能函数确定科目成绩Grade。类似于这样的,X的任何一个真子集都不能函数确定Y,那么称这样的函数依赖为Y对X的完全函数依赖。

    1.1.1.4 部分函数依赖

    如果存在同名同姓的情况,且X=(Sname, Sage, Sno, Subject)、Y=Grade,X的真子集有空集∅、Sname、Sage、Sno、(Sname, Sage)、(Sno, Subject)等15个,经过前面的讨论,空集∅、Sname和Sage等14个真子集都不能函数确定Grade,但是X的(Sno, Subject)这个子集可以函数确定Grade,因为根据实际语义来说,一个学生有唯一的一个学号,并且本学期只选修一次这门课程,所以学号Sno和课程Subject确定下来时,成绩Grade也将被确定。类似于这样的,X的存在一个真子集能函数确定Y,那么称这样的函数依赖为Y对X的部分函数依赖。

    1.1.1.5 传递函数依赖

    假设有如下学生-系别信息关系,属性有学号、系别、系主任,记为R(Sno, Sdept, Mname)。在这个关系中Sno函数确定Sdept(反之不是,因为一个系别有很多学生),Sdept函数确定Mname(反之不是,因为一个管理人员可能管理多个系别),可以推导出Sno函数确定Mname,类似关系R(U)中U的子集X、Y、Z存在X函数确定Y,Y不函数确定X,Y函数确定Z,Z不函数确定Y这样得出X函数确定Z的,称之为传递函数依赖。如果去掉“Y不函数确定X”、“Z不函数确定Y”这两个限制,那么可以看到X实际上是一般的直接函数确定Z的,就不能称之为传递函数依赖。

    1.1.2 多值依赖

    表1 多值依赖例题表格

    科目C 教练T 参考书B
    科目一 托尼 交通标志讲解
    科目一 托尼 交通处罚讲解
    科目一 托尼 科目一练习题
    科目一 凯文 交通标志讲解
    科目一 凯文 交通处罚讲解
    科目一 凯文 科目一练习题
    科目四 托尼 现场急救讲解
    科目四 托尼 文明驾驶讲解
    科目四 托尼 科目四练习题
    科目四 露西 现场急救讲解
    科目四 露西 文明驾驶讲解
    科目四 露西 科目四练习题

    在上面的关系模型DTeaching(C, T, B)中,当需要给一个科目(例科目一)添加一名教练时(例艾伦),这里必须插入三个元组:(科目一, 艾伦, 交通标志讲解)、(科目一, 艾伦, 交通处罚讲解)和(科目一, 艾伦, 科目一练习题)。同样在去掉一个科目(例科目四)的参考书(例现场急救讲解)时,必须要删除两个元组:(科目四, 托尼, 现场急救讲解)和(科目四, 露西, 现场急救讲解)。
    像这样增删改相关数据是非常不方便的,有非常大的数据冗余。对于(T, B)对应一个科目C,而实际上参考书B只与科目C有关,与教练T无关,这说的就是多值依赖。令DTeaching关系中所有属性为U,那么T=U-B-C。这时关系模式DTeaching(U)中多值依赖B→→C成立。即C的值只是取决于B,而与T无关。
    例如对于DTeaching关系,(科目一, 交通标志讲解)对应了有两个教练T{托尼, 凯文}的一个组,这一组的值只是取决于科目C的值。即对(科目一, 科目一练习题)来说,对应的教练T也是{托尼, 凯文}这一组,可以发现,即使参考书B变了,科目C也还是对应{托尼, 凯文}这一组教练,说明与参考书B无关。

    1.2 码

    码是数据库概念模型和关系模式中一个非常重要的概念。

    1.2.1 候选码

    如果能用最少的几个属性可以唯一地确定一个元组,换句话说,几个属性的集合K,能够完全函数确定一个元祖,那么这个属性集合K,就是关系R的候选码。例如在上文学生关系Students(Sname, Sno, Sage, Subject, Grade)中,属性集合{Sno, Subject}可以完全函数确定一个学生,例如通过Sno、Subject可以确定某个学生的信息和他这个科目的成绩,则(Sno, Subject)是候选码。

    1.2.2 超码

    通过候选码的介绍可知,候选码是最少的几个属性,集合K是完全函数确定一个元组的。超码与之不同,超码的属性集合J是部分函数确定一个属性。超码的属性集合元素个数比候选码的多,超码的某些真子集可能是候选码。例如上一个例子,候选码是(Sno, Subject),超码可以是(Sno, Subject, Sage),其中Sage属性对于确定一个元组是不必要的一个属性。

    1.2.3 主属性与非主属性(非码属性)

    候选码可能有很多个,例如学生关系Students(Sname, Sno, Sage, Subject, Grade)中,如果不考虑同名同姓的情况,那么通过候选码(Sno, Subject)、(Sname, Subject)都可以唯一确定一个元组。这时候选码有多个,就需要人为选定一个主码来供数据库操作使用。几个候选码中所有的属性都称为主属性,反之为非主属性或非码属性。

    1.2.4 全码

    在某些特殊情况下,某些关系的候选码的就是整个属性组,这称为全码。全码包含的属性数量是做多的;最简单的码是只有单个属性。假设存在一个课程关系,一个任课老师可能教授不同的科目,一个科目可能由多课老师来教,该关系表示为Course(Subject, Teacher),如果想要唯一确定一个元组,则必须要提供两个属性,所以该Course关系的码是全码。

    1.2.5 外部码(外码)

    如果一个关系模式R的某个属性或属性组K不是它的码,但是K是另外一个关系模式的码,那么K就是关系模式R的外部码。例如上文的学生关系Students(Sname, Sno, Sage, Subject, Grade)的码是(Sno, Subject),单独的属性Sno不能作为Students关系的码,但是Sno可以作为学生信息关系模式SInfo(Sno, Sname, Sage, Sex)的码。

    2 关系数据库的规范化

    关系数据库的形式是一张二维表,关系数据库的关系必须要满足一定的要求,最基本的一定要满足第一范式,满足的范式越高级,则该关系数据库的规范化程度就越高。最早E.F.Codd研究范式理论,并里提出了第一范式、第二范式、第三范式,后来他和Boyce提出来更高级的BC范式,随后Fagin提出来第四范式,后面又有一些关系数据库研究人员提出了第五范式。所有范式的级别由高到低是5NF>4NF>BCNF>3NF>2NF>1NF,规范化的过程就是由一个第一级的范式的关系模式,通过模式分解,转化成更高一级范式的关系模式。

    2.1 1NF(第一范式)

    第一范式是关系数据库设计必须要满足的最基本要求,如果没有满足第一范式,那么这个数据库设计就是错误的。第一范式要求关系的每一个分量或称属性必须是不可以再分的。如果把关系型数据库看成一张普通二维表,那么就不能存在一个属性再包含多个子属性。
    例如假设存在一个错误的老师学生的关系,属性有老师姓名、专业和学生姓名,表示为Relationship(Tname, Sdept, Students),如果Students是另一个关系Students(Sname1, Sname2…),这里Students被分为Sname1,Sname2…, 那么就是错误的。所以换句话说,不能使两个关系有嵌套联系。

    2.2 2NF(第二范式)

    2.2.1 定义

    首先某关系R符合第一范式,如果关系R的任何一个候选码能完全函数确定每一个非主属性,那么关系R就符合第二范式。
    假设存在一个集团员工的考核和住处信息关系,每个公司的员工住在一个地方,属性有工号WNum、所在公司WCom、住处WLoc、考核项目Project和考核成绩Grade,表示为W-L-P(WNum, WCom, WLoc, Project, Grade)。
    显然W-L-P关系的候选码是(WNum, Project)。(WNum, Project)能完全函数确定Grade;WCom能函数确定WLoc(因为每个公司的员工住在一个地方);因为Wnum能函数确定WCom,所以(WNum, Project)是部分函数确定WCom;因为Wnum能函数确定WLoc,所以(WNum, Project)是部分函数确定WLoc。可以看到存在两个候选码部分函数确定非主属性,所以关系W-L-P是不符合第二范式的。

    2.2.2 问题提出和解决

    如果某关系不符合第二范式,那么就会产生一些问题。
    插入异常。如果在W-L-P关系中,新插入WNum=123,WCom=AliPay,WLoc=10B303,但是该员工还没设置考核项目,即没有Project,缺少主属性的值,所以就无法插入到该关系中。
    删除异常。如果某员工要删除他的考核项目,但是Project是主属性,一旦删除了,该员工的所有信息都会被删除,这就造成了删除异常。
    修改复杂。如果某员工要转到该集团下的其他公司,那么就要修改该元组的WCom值,那么住处WLoc也需要修改。如果这个员工的考核项目Project有多个,那么WCom和WLoc的值也会被存储多个,转公司时也需要全部修改。这就是数据冗余度大导致数据修改无比复杂。
    显然,我们可以把关系模式W-L-P分解成两个关系模式:WP(WNum, Project, Grade)和WL(WNum, WCom, WLoc)。关系WP的码是(WNum, Project),关系WL的码是WNum,这样各自的码就能完全函数确定各自的非主属性了。

    2.3 3NF(第三范式)

    2.3.1 定义

    上文关系模式WL(WNum, WCom, WLoc)存在传递依赖。WNum能函数确定WCom(反之不能),WCom能函数确定WLoc,所以WNum是传递函数确定WLoc。这不符合第三范式。类似这样的某关系模式R,首先符合第一范式,并且不存在码X,能函数确定任意属性组Y(反之不能),Y能函数确定任意非主属性Z,就符合第三范式。上文中WP是符合第三范式的。

    2.3.2 问题和解决方法

    如果某关系模式不符合第三范式,就会产生类似于不满足第二范式时的问题。以WL关系为例,分解成WC(WNum, WCom)和CL(WCom, WLoc)。这样就不存在传递依赖了,分解结果符合第三范式。

    2.4 BC(Boyce-codd)范式

    BC范式有时被称为扩充的第三范式。符合第三范式的关系有些符合BC范式,有些不符合BC范式。

    2.4.1 定义

    假设一个关系模式R满足第一范式,其中一个属性或属性组X能函数确定一个属性或属性组Y,X不包含Y且X中一定含有码,那么这个关系模式R是符合BC范式的。
    假设存在一个员工、领导和部门的关系WMD(W, M, D),一个领导M只管理一个部门D,一个部门D有多个领导M,一个员工W加入一个部门D,就对应了一个固定的领导M。通过语义可以得出:(W, D)能函数确定M,(W, M)能函数确定D,M能函数确定D。所以该关系的候选码有两个,分别是(W, D)和(W, M)。没有非主属性对码的传递函数依赖或部分函数依赖,该关系是符合第三范式的。但是M能函数确定D,M在这里是决定因素,而M不包含码,所以该关系不符合BC范式。

    2.4.2 问题和解决方法

    关系模式WMB是不符合BC范式的,可以通过把该关系分解成WM(W, M)和MD(M, D),这下它们都满足了BC范式。
    如果某关系模式R不属于BC范式,那么它仍然可能有数据修改复杂的特点。第三范式和BC范式是函数依赖范围内模式分解的最高程度。但是还没有完全解决插入和删除异常。

    2.5 4NF(第四范式)

    第四范式就是对于给定任意关系模式R,R符合第一范式,当任意的属性或属性组X和Y,X→→Y,且X不包含Y、X都含有码,那么这个关系模式R是符合第四范式的。
    例如上文1.1.2节多值依赖的DTeaching关系模式,一个科目如果是有m个教练n本参考书,那么每个科目的元组就一定有m×n个。每个教练被重复存储n次,中参考书被重复存储m次,数据量一多时,数据冗余度非常大,因此即使满足了BC范式,还应该继续规范化使该关系模式达到第四范式。
    如果只考虑函数依赖,BC范式是规范化程度最高的;如果考虑多值依赖,第四范式是规范化程度最高的。还有其他的数据依赖例如连接依赖,会在关系的连接运算中体现出异常问题。满足了第四范式但可能会存在连接依赖,需要用到第五范式来解决,因作者水平有限,这里不再讨论第五范式。

    2.6 小结:关系规范化理论的必要性和重要性

    规范化理论的中心思想是逐渐分步消除数据间依赖中的不妥当部分,使其能够在操作效率上有所提高。模式中的各个关系模式能够变得更纯粹,让一个关系只联系一个概念,使一个具体问题中的概念单一化,来解决更新复杂、删除异常、数据冗余高以及插入异常等问题。2NF、3NF、BCNF、4NF是对于这一认识的逐步深化。数据库设计人员对具体问题设计的规范化的程度直接影响了数据库逻辑设计的成功与否,所以我们研究关系规范化理论对数据库的逻辑设计是非常有必要和重要的。

    3 总结

    关系数据库的规范化理论是数据库逻辑设计的一个强有力的工具,为数据库设计提供了一个理论的指南。 经过了规范化处理的模式通常结构都变得比较简单,数据间的联系也变得更清晰。但是在这里必须要明确的一点是,评价一个数据库设计的是否“得体”,规范化并不是唯一的标准,如果某关系模式在一些应用上不必要地被分解得太高级,极有可能消耗数据库查询的性能,会花太多时间在表的连接操作上。根据具体的问题,数据库的设计者在规范化程度与操作数据库时应有良好的性能之间找到一个恰到好处的平衡点,这时设计质量才是比较高的。而不是单纯地理解为规范化程度越高设计就越好。

    参考文献

    [1] 王珊,萨师煊.数据库系统概论(第5版)[M].高等教育出版社,2014。
    [2] 田进华,杨志强.关系规范化理论在数据库设计中的重要性[J].电脑知识与技术,2009,(24):6616-6617+6624.
    [3] 梅红.浅析规范化理论在数据库设计中的重要作用[J].数字技术与应用,2019,(10):217-218.
    [4] 李志强,苗振青,刘丽萍.关系规范化理论在MIS系统数据库设计中的应用[J].郑州纺织工学院学报,2000,(01):75-78.

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

    千次阅读 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的范式出现机会较少,而且会破坏完整性,你可以在做设计之时不考虑它。希望大家在设计数据库时,一定要全面考虑各方面的问题,根据实际情况出发,然后再确定是否应该满足更高范式。


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

    千次阅读 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.

    展开全文
  • 数据库规范化理论

    千次阅读 2018-05-11 16:59:31
    函数依赖的定义设关系模式R(U,F),U是属性全集,F是U上的函数依赖集,X和Y是U的子集,如果对于R(U)的任意一个可能的关系r,对于X的每一个具体值,Y都有唯一的具体值与之对应,则称X函数决定Y,或Y函数依赖于X,记做.....
    函数依赖的定义

    设关系模式R(U,F),U是属性全集,F是U上的函数依赖集,X和Y是U的子集,如果对于R(U)的任意一个可能的关系r,对于X的每一个具体值,Y都有唯一的具体值与之对应,则称X函数决定Y,或Y函数依赖于X,记做X→Y。我们称X为决定因素,Y为依赖因素。当Y不依赖于X时,记做X→Y。若X→Y且Y→X,记做:X↔Y。

    1.函数依赖是语义范畴

    2.函数依赖与属性之间的联系类型有关

    3.函数依赖关系的存在于时间无关

    关系的键

    设K为关系模式R(U,F)中的属性或属性集合

    1.K→U

    2.K的任意真子集都不能函数决定R的其他属性,即K满足最小化条件

    函数依赖的公理系统(解决数据冗余)

    只考虑给定的函数依赖集F是不够的,可以证明有其他的函数依赖也是成立的,这些函数依赖被称为F所“逻辑蕴含”

    定义:对于满足一组函数依赖F的关系模式R(U,F),其任何一个关系r,若函数依赖X→Y都成立,则称F逻辑蕴含X→Y


                             

    引理:X→A1A2……An成立的充分必要条件是X→Ai成立,i=1,2,…,n。(合并规则和分解规则)

    属性集的闭包

    定义:设F为属性集U上的一组函数依赖,X⊆U,X+={A|X→A能由F根据Armstrong公理系统导出},称X+为属性集X关于函数依赖集F的闭包。

    关系模式的规范化

    好的关系:尽可能少的数据冗余、没有插入异常、没有删除异常、没有更新异常

    1.完全依赖与部分依赖(冗余和更新异常)


    2.传递依赖

    范式
    第1范式

    每个属性不可再分

    第2范式

    不允许关系模式中的非主属性部分函数依赖于候选键(如果R的关系键为单属性,或R的全体属性均为主属性,则属于第二范式)

    1.找出对候选键部分依赖的非主属性所依赖的候选键的真子集,然后吧这个真子集与其函数决定的非主属性组合成一个新的模式

    2.对候选键完全依赖的所有非主属性与候选键组成另一个关系模式

                             

    第3范式

    每个非主属性都不传递依赖于R中的每个关系键

    E_S(员工编号, 员工名称, 工资级别, 工资)中“工资”对“员工编号”的传递依赖。

    继续分解成  E(员工编号, 员工名称, 工资级别)  和S(工资级别, 工资)

    BC范式

    限制主属性对键的依赖关系

    定义:如果关系模式R∈1NF,且所有的函数依赖X→Y,决定因素X都包含了R的一个候选键,则称R属于BC范式。

    性质:1.满足BCNF的关系将消除任何属性(主属性或非主属性)对键的部分函数依赖和传递函数依赖。

               2.如果R3NF,且R只有一个候选码,则R∈BCNF

                      

                    



    展开全文
  • 规范化理论:范式等级

    千次阅读 2019-05-12 16:14:48
    关系模式规范化的基本思想是消除关系模式中的数据冗余,消除数据依赖中的不合适的部分,解决数据插人、删除时发生的异常现象。这就要求关系模式要满足一定的条件。我们把关系模式规范化过程中为不同程度的规范化要求...
  • 为什么要学习关系数据库规范化理论?(1)基本概念回顾(2)关系模式的形式化定义(3)什么是数据依赖F?(4)数据依赖F对关系模式的影响1️⃣ 数据冗余(Data redundancy)2️⃣ 更新异常(update anomalies )3️⃣ ...
  • 规范化理论:模式分解

    千次阅读 2019-05-13 22:51:05
    什么是模式分解? 关系模式R<U, F>的一个分解是指:={<...把低一级的关系模式分解为若干个高一级的关系模式,分解方法并不是唯一的,在这些分解方法中,只有能够保证分解后的关系模式与原关...
  • 关系型数据库规范化的通俗理解

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

    千次阅读 2019-01-10 15:14:46
    一、选择题 1、关系规范化中的删除操作异常是指 ① ,插入操作异常是指 ② 。  A.不该删除的数据被删除 B....关系规范化理论 B.关系运算理论 C.关系代数理论 D.数理逻辑 【答案:】A 3、规范化...
  • 数据库---规范化理论、范式、模式分解

    千次阅读 多人点赞 2017-09-19 18:38:46
    解决关系化模式存在的问题 键相关的概念超键: 唯一标识元组,可能存在冗余属性 候选键: 唯一标识元组 超键与候选键的差异 比如:(SNo,SName,SSex) 其中(SNo,SName)超键 主键: 在候选键中任意选择一个作为...
  • 关系数据库设计是对数据进行组织和结构的过程,核心问题是关系模型的设计。关系模型是数学的、用二维表格数据描述各实体之间的联系的模型;它是所有的关系模式、属性名和关键字的汇集,是关系模式描述的对象。...
  • 关系数据库设计理论

    千次阅读 2018-07-11 18:32:27
    关系数据库设计理论 设计一个好的关系数据库系统,关键是要设计一个好的数据库模式(数据库逻辑设计问题) 数据库逻辑设计主要解决的问题 关系数据库应该组织成几个关系模式 关系模式中包括哪些属性 ...
  • 数据依赖是一个关系内部属性与属性之间的一种约束关系,这种关系是通过属性间值的相等与否体现的数据相关的关系。 多种类型的数据依赖:函数依赖和多值依赖 例如:Sname和Sdept函数依赖于Sno,记做Sno -> Sname...
  •  关系规范化理论 B. 关系代数理论 C.数理逻辑 D. 关系运算理论  2. 规范化理论是关系数据库进行逻辑设计的理论依据,根据这个理论,关系数据库中的关系必须满足:每一个属性都是(B) 。  A. 长度不变...
  • 关系模式设计中的问题关系数据库设计要解决的主要问题 什么样的数据库模式才合理? 怎么分解才能满足要求? 衡量的标准是什么? 理论基础是什么? 如何进行实现? 关于好的数据库模式好的数据库模式是不会发生插入...
  • 什么是数据库规范化 维基百科的定义如下: 数据库规范化,又称数据库或资料库的正规化、标准化,是数据库设计中的一系列原理和技术,以减少数据库中数据冗余,增进数据的一致性。 数据库范式是埃德加·科德设计...
  • 【吐血整理】数据库的规范化

    千次阅读 多人点赞 2020-04-19 21:53:24
    工具:关系数据库的规范化理论 (总结起来就是:规范化理论就是数据库中用来设计表的工具) 关系模式由五部分组成,是一个五元组:R(U, D, DOM, F) R 是符号化的元组语义(即表名) U 为一组属...
  • 数据建模的过程是将现实中的业务不断地进行抽象(Abstraction),实现从现实世界(RealWorld)中的业务为概念世界(Conception World)中的模型,再到计算机世界(ComputerWorld)中的表的转换过程。 将...
  • 原文地址:数据的规范化,归一化,标准化,正则化作者:打湿井盖  数据的规范化,归一化,标准化,正则化,... 规范化理论关系应满足的规范要求分为几级,满足最低要求的一级叫做第一范式(1NF),在第一范式的
  • 关系数据库基础理论

    千次阅读 2018-08-06 11:02:06
    mysql系列之一关系数据库基础理论 正是数据库管理的需要催生了数据库管理系统DBMS,而关系型数据库管理系统为RDBMS 常见的数据模型有三种: - 层次模型 - 网状模型 - 关系模型 一、关系数据库的产生 在...
  • 数据库系统概论——第六章 关系数据理论 (零)引言 基于某个数据库管理系统设计...(2)数据库逻辑设计的工具——关系数据库的规范化理论 二、关系模式由五部分组成,是一个五元组: R(U,D,DOM,F) 关系名R是符...
  • 数据的规范化,归一化,标准化,正则化,... 规范化理论关系应满足的规范要求分为几级,满足最低要求的一级叫做第一范式(1NF),在第一范式的基础上提出了第二范式(2NF),在第二范式的基础上又提出了第三范式(3NF),
  • 1.关系规范化中的操作异常有哪些?它是由什么引起的?解决的办法是什么? 答:增、删、改异常。数据冗余引起。解决办法:模式分解。 2.第一范式、第二范式和第三范式的定义分别是什么? 答:第一范式:每个列都是...
  • 数据库的规范化——让你读懂什么是范式

    千次阅读 多人点赞 2019-11-18 14:36:23
    参考资料:Wiki百科、百度百科、Google、博客园等,定义性的内容,直接引用了官方...函数依赖理论 函数依赖的定义 完全函数依赖与部分函数依赖 传递函数依赖 键(码) 关系模型的分解特性 模式分解存在的问题...
  • 第5章 关系数据理论 练习

    万次阅读 2007-06-22 15:27:00
    第5章 关系数据理论 练习 1.规范化理论关系数据库进行逻辑设计的理论依据,根据这个理论,关系数据库中的关系必须满足:每 一个属性都是( )。 A.长度不变的 B.不可分解的 C.互相关联的 D.互不相关的 

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 70,335
精华内容 28,134
关键字:

关系规范化理论是为了解决