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

    千次阅读 2019-05-26 14:18:10
    关系数据库中,所有的数据文件都以 二维表的形式...这种分解的过程就叫做规范化。 第一范式1NF 第一范式的目标是确保每列的原子性 如果每列都是不可再分的最小数据单元(也称为最小的原子单 元),则满足第一范...
    • 在关系数据库中,所有的数据文件都以 二维表的形式存在,这些二维表之间通常会 产生数据冗余,这样容易造成数据的不一致 或不完整,从而使数据的检索、插入、删除 和更新和等操作可能会出现错误。解决这种 问题的一个办法就是将这些关系进一步的分 解。这种分解的过程就叫做规范化。
    第一范式1NF
    • 第一范式的目标是确保每列的原子性 如果每列都是不可再分的最小数据单元(也称为最小的原子单 元),则满足第一范式(1NF)
    第二范式2NF
    • 如果一个关系满足1NF,并且除了主键以外的其他列,都依赖于该主键,则满足第二范式(2NF)第二范式要求每个表只描述一件事情
    • 这种关系不仅满足第一范式,而且所有非主属性完全依赖于其主键
    第三范式3NF
    • 如果一个关系满足2NF,并且除了主键以外的其他列 都不传递依赖于主键列,则满足第三范式(3NF)
    • 这种关系不仅满足第二范式,而且它的任何一个 非主属性都不传递依赖于任何主关键字。
    展开全文
  • 数据库设计中关系规范化理论总结

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


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

    千次阅读 2014-11-19 22:23:11
    关系数据理论 一、设计中的问题 1、数据冗余大 数据冗余大指的是数据会经常重复出现,浪费了大量的存储空间。 2、更新异常  在数据冗余度大的时候,会导致更新异常,系统需要付很大的代驾来维护数据库的完整性...

    关系数据理论

    一、设计中的问题

    1、数据冗余大

    数据冗余大指的是数据会经常重复出现,浪费了大量的存储空间。

    2、更新异常

       在数据冗余度大的时候,会导致更新异常,系统需要付很大的代驾来维护数据库的完整性,例如:当冗余的那一项的数据更新的时候会导致数据表中出现该数据的元组也要更新,这回消耗系统的资源,对于大型应用来说这是一种不可原谅的事。

    3、删除异常

    会导致数据丢失。

    4、插入异常

       某一条数据在设计的时候依赖于表的主键但是现实中该主键并不能决定该数据的时候,当想要插入该数据的时候会导致异常,无法插入。

     

    一个好的数据模式不应该发生以上4个问题。

     

     

     

    二、规范化

    1、函数依赖

    在一个关系模式中,如果X函数确定Y的时候,这个时候Y就函数依赖于X,记为X→YX是这个关系的决定因数。

     

    1.1、完全函数依赖

    在一个关系中,如果X→Y,并且X的任何一个真子集X’ 都不能确定Y,那么X→Y为完全函数依赖。

    如:

    学生(学号、课程号)-->成绩

    X=(学号、课程号),学号或者课程号都不能确定成绩。

     

    1.2、部分函数依赖

    在一个关系中,如果X→Y,并且X的某一个真子集X’ 确定Y,那么X→Y为部分函数依赖。

    如:学生(学号、课程号)-->

    但是只根据学号我们也能确定该学生属于哪一个系。

     

    2、码

    2.1、候选码

    在一个关系中,如果一个属性或者属性组能够确定其他属性或属性组的时候,它就是候选码。

    2.2、主码

    任意一个候选码都可以被选为主码。

    2.3、外码

    某一个关系中的属性(非码)是其他关系中的码,那么他就是外码。

     

    3、范式

    3.11NF

    每一个属性都是不可分割的项就能属于1NF

    2.22NF

    对于一个关系,每一个非主属性必须完全依赖于码,这就是2NF。再设计的时候应该找出该关系的候选码和依赖关系,然后判断,消除部分依赖。

    一个关系不属于2NF会导致插入异常,删除异常、修改麻烦。

    2.33NF

    在一个关系中,不存在这样的码X,属性组Y和主非属性Z使得X→Y,Y→Z成立。也就是所不能存在非主属性对主属性的传递依赖。

    如果一个关系存在传递依赖,那么也会有插入异常、删除异常、修改麻烦的问题。

    2.4BCNF

    若是一个关系模式中的每一个决定因数都含有码的时候,那么这个关系模式就满足BCNF

    BCNF的关系模式中。

    所有非主属性都完全依赖于主属性。

    所有的主属性对每一个不包含他的码也是完全依赖

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

    三、总结

    在数据库的设计过程中,满足第一范式的数据库就是一个合法的数据库,但是这样的不是一个好的数据库,这样的数据库在插入数据和更新、删除数据的时候会有出现一些问题,这些问题可能会导致数据库异常或则操作麻烦。

    数据库在设计过程中需要规范化,规范化的过程是一步一步来的,首先我们让我们的数据库满足1NF,然后去检查是否存在部分依赖,然后消除部分依赖,最后检查是否还有传递依赖,如果有在消除传递依赖。这样我们的数据库会满足3NF,这样的数据库已经算是一个不错的数据库了,当然如果对数据库的设计要求很高,那么我们再去看一下是否每一个决定因数都含有码,没有就继续分解,这样我们的数据库就能在满足BCNF,如果还要继续提高的话就去检查是否满足4NF吧。

    展开全文
  • 规范化是通过修改表以减少冗余和矛盾的一系列动作。 关系数据库定义了3中范式: 第一范式: 列仅包含原子值 没有重复的组 第二范式:满足第一范式 非部分函数依赖如果表中一些组合键的(但不是全部)值确定了一...
  • 关系数据库设计规范化流程

    千次阅读 2011-09-15 14:59:42
    规范化:确保数据正确地分布到数据库的表中,防止操作异常及大量冗余信息的存储。数据冗余不仅占用物理空间,数据的维护和一致性检查也带来了问题。   范式及举例:   第一范式:【数据库表中
  • 数据库关系模式的规范化

    千次阅读 2021-04-03 15:23:11
    在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。 所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即...
  • 逻辑设计:模型校验,设计规范化(生成关系表/二维表) 什么是不好的关系模式   函数依赖 数据依赖:在计算机科学中,数据依赖是指一种状态,当程序结构导致数据引用之前处理过的数据时的状态。其中最重要的是...
  • 关系数据库设计:谈谈规范化技术

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

    万次阅读 2016-10-20 16:27:14
    关系数据库规范化
  • 数据库——关系数据库规范化习题

    千次阅读 2019-06-29 16:39:00
    以下的关系模式, 分别写出:(1)码 ,主属性,非主属性?(2)函数依赖?(3)属于第几范式?为什么?(4)有什么问题?(5)如何分解?分解后能否达到几范式? 原问题是否解决?ps(函数依赖的方法: 1.先找出码,再写出码...
  • 4.1 数据依赖 4.1.1 关系模式中的数据依赖 概念回顾 关系模式的形式化定义 4.1.2 数据依赖对关系模式的影响 什么是数据依赖 关系模式的简化表示 数据依赖与关系模式 ...4.3.1 关系范式规范化的步骤
  • 数据库设计之规范化和反规范化

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

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

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

    千次阅读 2016-09-17 22:55:14
    第一范式(1NF):在关系模式R中的每一个具体关系r中,如果每个属性值 都是不可再分的最小数据单位,则称R是第一范式的关系。例:如职工号,姓名,电话号码组成一
  • 【吐血整理】数据库规范化

    千次阅读 多人点赞 2020-04-19 21:53:24
    工具:关系数据库规范化理论 (总结起来就是:规范化理论就是数据库中用来设计表的工具) 关系模式由五部分组成,是一个五元组:R(U, D, DOM, F) R 是符号化的元组语义(即表名) U 为一组属...
  • 数据库规范化与非规范化比较

    千次阅读 2014-10-02 18:36:54
    数据库设计的规范化与非规范化: (1)表格与面向对象: 表格包含各个字段,面向对象也是包含多个成员变量。两者有相似之处。 (2)E-R图向关系图转换: 一一: 一多: 多多: (3)规范化与非...
  • 数据库数据规范化

    千次阅读 2018-10-08 22:38:03
    Codd博士定义了6个范式来规范化数据库,范式由小到大来约束,范式越高冗余越小,但表的个数也越多。实验证明,三范式是性价比最高的。 2.1 第一范式:确保每列原子性 第一范式确保每个字段不可再分 如下表设计是否...
  • 关系数据库规范化理论---范式

    千次阅读 2017-11-08 15:27:02
    此篇博文是我的第一篇文章,在复习数据库范式...关系模式规范化的必要性:关系模式规范化,使之达到较高的范式是设计好关系模式的唯一途径。否则,所设计的关系数据库会产生一系列的问题。 关系模式应满足的基本要求:
  • 关系数据库规范化理论之范式

    千次阅读 2017-11-09 22:27:30
    因为在写项目时与同伴关于数据库到底建多少张表,每张表应包含哪些属性产生分歧,所以又好好研究了一下关系数据库在设计时应该遵守怎样的规则以提高数据库性能。 在阅读本篇文章前读者须掌握关系数据库结构基础及...
  • 什么是数据库规范化 维基百科的定义如下: 数据库规范化,又称数据库或资料库的正规化、标准化,是数据库设计中的一系列原理和技术,以减少数据库中数据冗余,增进数据的一致性。 数据库范式是埃德加·科德设计...
  • 数据库规范化过程

    千次阅读 2019-08-25 13:41:37
    关系数据库规范化说的通俗一些就是对表的规范化规范化的必要性: 根据项目的需求,我们会创建相应的数据库表格来完成项目中的数据的存储。这已经成为做项目的固定流程了,但是在真正的开始处理业务需求的时候,...
  • 1nf~4NF的理解模型。
  • 为什么要学习关系数据库规范化理论?(1)基本概念回顾(2)关系模式的形式化定义(3)什么是数据依赖F?(4)数据依赖F对关系模式的影响1️⃣ 数据冗余(Data redundancy)2️⃣ 更新异常(update anomalies )3️⃣ ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 189,567
精华内容 75,826
关键字:

对数据库关系规范化