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

    千次阅读 2020-07-04 21:24:15
    关系规范化的目的 关系规范化的目的是为了消除储存异常,减少数据冗余,以保证数据的完整性,正确性,一致性和储存效率,一般讲关系规范到III范式即可 1NF范式 一个关系的每个属性都是不可再分的基本数据项,则该...

    关系规范化的目的

    关系规范化的目的是为了消除储存异常,减少数据冗余,以保证数据的完整性,正确性,一致性和储存效率,一般讲关系规范到III范式即可

    1NF范式

    一个关系的每个属性都是不可再分的基本数据项,则该关系是I范式

    2NF范式

    II范式首先要满足I范式,而且关系中的每一个非主属性完全函数依赖于主关键字,则该关系是II范式

    个人理解:就是表中除主键其他的所有属性都要完全依赖主键,不能不完全

    实例:
    在这里插入图片描述

    将非II范式规范为II范式的方法

    将部分函数依赖关系中的主属性(决定方)和非主属性从关系中提取出来,单独构成一个关系

    实例分析: 学生成绩表主关键字/主键(学号,课程名称),成绩完全依赖主关键字。姓名不完全依赖主键,只依赖学号,所以讲学号和姓名单独构建成一个表

    3NF范式

    III范式首先要满足II范式,且关系中的每一个非主属性都不完全函数传递依赖主关键字,则此关系是III范式

    在这里插入图片描述

    展开全文
  • MySQL关系规范化

    千次阅读 2020-10-21 21:07:08
    MySQL关系规范化 作者:就叫易易好了 时间:2020/10/21 指导老师:桃群老师 一、关系规范化 1、函数依赖 什么是函数依赖?比如学生管理系统数据库,有学生姓名(Sname)、学生系名(Sdept)、学生学号(Sno)等等。一...

    MySQL关系规范化

    作者:就叫易易好了
    时间:2020/10/21
    指导老师:桃群老师
    

    一、关系规范化

    1、函数依赖

    什么是函数依赖?比如学生管理系统数据库,有学生姓名(Sname)、学生系名(Sdept)、学生学号(Sno)等等。一个学号只能唯一确定一个学生,一个学生只在一个系学习。所以,当“学号”确定后,学生姓名和该学生所在系也被唯一确定了。

    这时我们可以说

    Sno函数决定Sname和Sdept,或者说Sname,Sdept函数依赖于Sno

    可记作:Sno->Sname,Sno->Sdept

    1.1 完全函数依赖

    在R(U)中,若X->Y,并且对于X的任意一个真子集X’,都有Y不依赖于X’,那么称Y对X完全函数依赖

    比如一个学生的学号和课程号才能共同决定一个学生该门课的成绩,即(Sno,Cno)->Grade,但X的真子集为Sno或者Cno,他们无法单独决定该门课的成绩,所以学号和课程号完全函数依赖成绩

    2.2 部分函数依赖

    在R(U)中,若X->Y,对于X的任意一个真子集X’,有Y依赖于X’ ,那么称Y对X部分函数依赖。

    比如(Sno,Cno)->Sname,X的真子集Sno和Cn都能单独决定学生姓名,所以学号和课程号部分函数依赖学生姓名。

    2.3 传递函数依赖

    在R(U)中,如果Y依赖于X,X不依赖于Y,Z依赖于Y,则称Z对X传递函数依赖;

    比如:Sno->Sdept,Sdept不依赖于Sno,Sdept->Manager,则Sno传递函数依赖于Manager

    2.4 直接函数依赖

    在R(U)中,如果Y依赖于X,X依赖于Y,Z依赖于Y,则称Z对X直接函数依赖

    比如:Sno->Sdept,Sdept->Sno,Sdept->Manager,则Sno直接函数依赖于Manager

    二、范式

    范式是衡量关系的规范化程度。

    • 满足最低要求的是第一范式,简称1NF。在第一范式中满足进一步要求为第二范式,简称2NF,以此类推。
    • 1NF<2NF <3NF <BCNF <4NF <5NF
    • 一个低一级的范式关系模式,通过模式分解可转换为更高一级的范式关系模式集合,这个过程就叫规范化。

    1、第一范式 (1NF)

    若一个关系模式R的所有属性都是不可再分项,则该关系属于第一范式

    学号 姓名 班级 正班长 副班长
    2018029 成小白 5班 龙龙 豫豫
    2018030 晨小美 5班 龙龙 豫豫

    在上面这个表格中,所有属性都是不可再分项,所以该关系为1NF。

    2、第二范式(2NF)

    1NF是关系数据库中对关系最基本的要求,但不是理想的结构形式,仍然有大量的数据冗余和操作异常。所以为了解决这些问题,就要消除模式中属性之间存在的部分函数依赖,将其转化成更高一级的第二范式。

    若关系模式R属于1NF,且R中每个非主属性都完全函数依赖于主关键字,则称R是第二范式(2NF)

    也就是说当1NF消除了非主属性对关键字的部分函数依赖,则称为2NF

    案例:
    学生关系S(Sno,Sname,Sdept,Manager,Cno,Grade)
    ·关系S属于第一范式
    ·关系S不属于第二范式,存在非主属性对(Sno,Cno)的部分函数依赖
    ·如果将该学生关系S分解成以下两个关系S1和S2,
     -S1(Sno,Cno,Grade),这时Grade完全依赖于主码
      没有部分函数依赖,所以属于第二范式
     -S2(Sno,Sname,Sdept,Manager)
      主码是Sno,其他非主关键字都是完全函数依赖于主码
      属于第二范式
    

    3、第三范式(3NF)

    当第二范式消除了非主属性对码的传递函数依赖,则称为第三范式

    举例:

    • 关系S1(Sno,Cno,Grade),不存在非主属性对主属性的部分函数依赖个传递函数依赖,所以S1属于第三范式。

    • 关系S2(Sno,Sname,Sdept,Manager),存在非主属性Manager对码Sno的传递函数依赖,即Sno->Sdept,Sdept不依赖于Sno,Sdept->Manager,Sno传递函数依赖于Manager。所以S2不属于第三范式。

    • 若将S2分解成下述两个关系S3和S4,即:

      S3(Sno,Sname,Sdept),消除了非主属性对主属性的部分函数依赖和传递函数依赖,属于第三范式。

      S4(Sdept,Manager),消除了非主属性对主属性的部分函数依赖和传递函数依赖,属于第三范式。
      解决了删除异常、更新异常和冗余度大等问题

    4、BC范式(BCNF)

    当第三范式消除了主属性对码的部分和传递函数依赖,称为BCNF

    • 如果关系R是BCNF,那么R一定是3NF
    • 如果R是第三范式,并且R只有一个候选码,则R必属于BCNF
    • 二元关系模式R必定是BCNF
    • 都是主属性的关系并非一定属于BCNF

    从数据库设计的角度看,在函数依赖的基础上,分解最高范式BCNF的模式中仍然勋在数据冗余问题,这时就需要更高的范式来解决这个问题,本篇文章先到这里,后面再更新多值依赖,连接依赖和更高范式喔~

    展开全文
  • 数据库设计中关系规范化理论总结

    千次阅读 多人点赞 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.

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

    千次阅读 2013-06-12 14:59:24
    关系规范化理论 1 规范化 1.1 为什么要规范化? 关系模式用五元组表示,R(U,D,DOM,F),U表示属性,D表示域,DOM表示属性到域上的映射。一般不用研究关系的域以及属性到域上的映射,但是需要研究内部属性的...

    关系规范化理论

    1  规范化

    1.1 为什么要规范化?

    关系模式用五元组表示,R(U,D,DOM,F)U表示属性,D表示域,DOM表示属性到域上的映射。一般不用研究关系的域以及属性到域上的映射,但是需要研究内部属性的依赖关系-函数依赖R(U,F)

    不好的关系模式会引发数据冗余,插入,更新,删除的异常,所以,需要研究如何解决这些问题。

    1.2 非平凡的函数依赖

    实际上就是定义了两部分属性(x,y,如果x分量上相等,那么y上必须相等,例如资产表,ip地址和mac,序列号,实际上是相互函数依赖的关系。

    1.3 完全函数依赖和部分函数依赖

    完全函数依赖指的是Y函数依赖X,但是不函数依赖X的真子集,那么Y完全函数依赖于X。如果Y还函数依赖X的某个真子集,那么叫做部分函数依赖。

    1.4 

    码的概念其实就是,如果R(U,F)对与某组属性XU完全函数依赖X,那么X叫做关系的候选码,如果有多个候选码,可以选取一个码作为主码。如果R中某个属性是另外一个关系的主码,那么这个属性叫做这个关系的外码。

    2范式理论

    关系数据库中的关系要满足于一定的要求,满足不同程度的要求叫做满足不同范式。

    一个低一级的范式通过模式分解,转换为若干高一级的范式,叫做规范化。

    2.1 1NF:

    关系中每个属性都是不能再分的数据项,也就是不允许表中有表

    例如,学生成绩一列,不能再分为期中成绩和期末成绩。

    2.2 2NF

    所谓2范式,指的是关系中每个非主属性都要完全函数依赖主属性。

    再如:

    员工效率表:

    员工   零件          工时       零件存放仓库  仓库负责人

    在这个关系中,(员工,零件)是组合主属性。同时,由于零件只能在一个仓库,所以仓库也函数依赖零件,也就是说仓库对(员工,零件)来说,是部分函数决定,这就不满足二范式。

    异常情况:增加仓库,这个仓库并没有零件,由于没有主键,所以没法添加

    修改某个零件的仓库时,需要修改一大堆记录;

    删除零件时候,把对应的仓库都删掉了;

    需要分解成两个关系,消除部分函数依赖:

    (员工,零件,工时),(零件,仓库 仓库负责人)

    2.3 3NF

    考虑上面分解后的关系:(零件,仓库 仓库负责人)

    零件只属于一个仓库,一个仓库只能有一个负责人,所以零件就间接决定了仓库负责人。也就是说,这个关系存在非主属性对主属性的传递函数依赖。

    异常情况:

    增加了一个仓库,但是还没有放零件,那么这个仓库就添加不进去。

    删除了一个零件,把仓库都删没了

    修改一个仓库的负责人,由于数据冗余严重,可能需要修改很多行。

    使用属性投影分解法进行规范化:

    (零件,仓库),(仓库,仓库负责人)

    这样,分解后的3范式就消除了传递函数依赖,也就是消除了非主属性之间的完全函数依赖。

    2.4 BC范式

    每一个决定因素都必须包含码!

    考察表(学生姓名 课程 教师)

    每个学生可以选多课程:(学生-课程)--》教师

    每个老师教一门课,每一门课程可以由多个老师教授:教师》课程

    学生      课程    教师

    李四      数学    黎明

    王五      数学     刘德华

    这个关系的主属性是(学生-课程)

    这个关系满足1NF,2NF,3NF,因为没有非主属性对码传递依赖或者部分依赖。这里需要注意的是,教师虽然可以函数决定课程,但是它不能决定学生,所以它并不是码。这不满足决定因素必须包含码的规范。

    一般而言,满足3范式就ok了。

    展开全文
  • 关系规范化设计(范式)

    千次阅读 2014-06-10 00:50:31
    关系规范化设计(范式) 标准化表示从你的数据存储中移去数据冗余(redundancy)的过程。如果数据库设计达到了完全的标准化,则把所有的表通过关键字连接在一起时,不会出现任何数据的复本(repetition)。标准化的优点...
  • 概念模型与关系模型和关系规范化

    万次阅读 2017-05-20 16:18:34
     一个低一级范式的关系模式,通过模式分解逐步消除数据依赖中不合适的部分,使模式中的各关系模式达到某种程度的分离,转换为若干个高一级范式的关系模式的集合,这种过程就是关系规范化。  通过消除非主键列对...
  • [MySQL]关系规范化中的操作异常理解

    千次阅读 2019-01-02 19:25:58
    插入失败:该插入的没插入; 插入异常:不该插入的被插入; 删除失败:该删除的没删除; 删除异常:不该删除的被删除; 简单地说:失败:有心栽花花不开,异常:无心插柳柳成荫...
  • 最近在学数据库原理,关系规范化中介绍了几个算法,最基础也最重要的就是求属性集X关于某个函数依赖集合F的闭包。 /*8周的功夫一本数据库基本原理就学完了,很快要考试了,所以5-1假期也没打算出去玩,就在学校了...
  • 关系规范化之分解的无损连接判定

    万次阅读 2016-04-29 17:06:25
    定义:无损联接分解是将一个关系模式分解成若干个关系模式后,通过自然联接和投影等运算仍能还原到原来的关系模式,则称这种分解为无损联接分解。 无损分解的判定算法 输入:一个关系模式R(A1,A2,A3,...,An),R...
  • 输入:关系模式R和函数依赖集合F 输出:结果为满足第三范式的一个依赖保持的分解 条件: 1.如果R中有某些属性与F的最小覆盖Fmin中的左边右边都没有关系,则这个(些)属性构成一个关系模式。如果没有就进行2 2. ...
  • 关系数据库规范化理论

    千次阅读 2018-03-01 22:54:50
    1、关系规范化的作用所谓规范化,就是用形式更为简洁、结构更加规范的关系模式取代原有关系的过程。2、函数依赖2.1、属性间的联系实体间的联系有两类:一类是实体与实体之间的联系;另一类是实体内部各属性间的联系...
  • 数据库关系规范化

    千次阅读 2019-05-26 14:18:10
    关系数据库中,所有的数据文件都以 二维表的形式...这种分解的过程就叫做规范化。 第一范式1NF 第一范式的目标是确保每列的原子性 如果每列都是不可再分的最小数据单元(也称为最小的原子单 元),则满足第一范...
  • 关系模式的规范化理论

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

    千次阅读 2019-03-22 21:26:43
    3NF规范化:通过该算法可以获得一个保持函数依赖性并满足3NF的关系模式分解 先求出Fmin 1、X->A,XA=R 那么XA单独构成一个关系模式 2、如果关系模式R中的某些属性与函数依赖集F的左右部属性均无关的话,将他们...
  • 关系数据库设计:谈谈规范化技术

    千次阅读 多人点赞 2020-08-19 21:42:31
    通过实际案例介绍关系数据库设计中的规范化技术(Normalization),为什么需要规范化,常见的第一范式、第二范式和第三范式,反规范化应用的场景以及外键的取舍问题。
  • 关系模式的规范化

    万次阅读 多人点赞 2016-09-29 13:27:42
    原文路径:...了解关系模式规范化的作用 掌握第一范式-重点 掌握第二范式-重点 掌握第三范式-重点 回顾关系
  • 关系数据库规范化

    千次阅读 2016-09-17 22:55:14
    第一范式(1NF):在关系模式R中的每一个具体关系r中,如果每个属性值 都是不可再分的最小数据单位,则称R是第一范式的关系。例:如职工号,姓名,电话号码组成一
  • 4.1 数据依赖 4.1.1 关系模式中的数据依赖 概念回顾 关系模式的形式化定义 4.1.2 数据依赖对关系模式的影响 什么是数据依赖 关系模式的简化表示 数据依赖与关系模式 ...4.3.1 关系范式规范化的步骤
  • 关系模式规范化(上)

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

    万次阅读 2016-10-20 16:27:14
    关系数据库规范化
  • 数据库设计之规范化和反规范化

    千次阅读 2019-09-09 20:50:36
    文章目录一、规范化二、反规范化      数据库设计的规范化能够经常被提及,但是反规范化很少被涉猎。实际应用中反规范化应用的场景很多。本文主要介绍一下数据库的反规范化。 一、规范化 ...
  • 关系型数据库规范化的通俗理解

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

    千次阅读 2017-11-08 15:27:02
    此篇博文是我的第一篇文章,在复习数据库范式...关系模式规范化的必要性:关系模式规范化,使之达到较高的范式是设计好关系模式的唯一途径。否则,所设计的关系数据库会产生一系列的问题。 关系模式应满足的基本要求:
  • 根据候选码判断关系F中的函数关系是否满足第二范式,若不满足则为关系模式的规范化最高为第一范式 然后判断是否存在非主属性传递依赖,如果存在则不满足第二范式,如果不存在则关系模式的规范化最高为第三范式. 通俗...
  • 数据库关系模式的规范化

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

    千次阅读 2014-05-18 19:39:58
    第三范式的定义:如果关系模式R中的所有非主属性对任何候选关键字都不存在传递依赖,则称关系R是属于第三范式的。记作R 3NF。 如:学生关系模式S1(学号,姓名,系号,系名,系地址) (学号)为关键字,因是单属性...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 418,329
精华内容 167,331
关键字:

关系规范化