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

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

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

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

    关系模式规范化的定义

    到目前为止,规范化理论已经提出了六类范式。范式级别可以逐级升高,而升高规范化的过程就是逐步消除关系模式中不合适的数据依赖的过程,使模型中的各个关系模式达到某种程度的分离。一个低一级范式的关系模式,通过模式分解转为若干个高一级范式的关系模式的集合,这种分解过程叫作关系模式的规范化(Normalization)。

     

    关系模式规范化的目的和原则

    一个关系只要其分量都是不可分的数据项,就可称它为规范化的关系,但这只是最基本规范化。规范化的目的就是使结构合理,消除存储异常,使数据冗余尽量小,便于插入、最除和更新。
    规范化的基本原则就是遵循“一事一地”的原则,即一个关系只描述一个实体或者实体间的联系。若多于一个实体,就把它“分离”出来。因此,所谓规范化,实质上是概念的单一化,即个关系表示一个实体。

     

    关系模式规范化的步骤

    规范化就是对原关系进行投影,消除决定属性不是候选键的任何函数依赖。具体可以分为以下几步。
    (1)对1NF关系进行投影,消除原关系中非主属性对键的部分函数依赖,将1NF关系转换成若干个2NF关系。
    (2)对2NF关系进行投影,消除原关系中非主属性对键的传递函数依赖,将2NF关系转换成若干个3NF关系。
    (3)对3NF关系进行投影,消除原关系中主属性对键的部分函数依赖和传递函数依赖,也就是说,使决定因素都包含一个候选键,得到一组BCNF关系。
    (4)对BCNF关系进行投影,消除原关系中的非平凡且非函数依赖的多值依赖,得到一组4NF的关系。

    关系规范化的基本步骤如图所示。

     

    规范化过程

     

     

    一般情况下,我们说没有异常弊病的数据库设计是好的数据库设计,一个不好的关系模式也总是可以通过分解转换成好的关系模式的集合。但是在分解时要全面衡量,综合考虑,视实际情况而定。对于那些只要求查询而不要求插入、删除等操作的系统,几种异常现象的存在并不影响数据库的操作。这时便不宜过度分解,否则当对系统进行整体查询时,需要更多的多表连接操作,这有可能得不偿失。在实际应用中,最有价值的是3NF和BCNF,在进行关系模式的设计时,通常分解到3NF就足够了。

     

    关系模式规范化的要求

    关系模式的规范化过程是通过对关系模式的投影分解来实现的,但是投影分解方法不是唯的,不同的投影分解会得到不同的结果。在这些分解方法中,只有能够保证分解后的关系模式与原关系模式等价的方法才是有意义的。
    判断对关系模式的一个分解是否与原关系模式等价可以有三种不同的标准。
    (1)分解要具有无损连接性;
    (2)分解要具有函数依赖保持性;
    (3)分解既要具有无损连接性,又要具有函数依赖保持性。

     

     


    参考资料:[1]陈志泊,王春玲,许福,范春梅.数据库原理及应用教程(第3版)[M].北京:人民邮电出版社,2014:159-160.
     

     

     

    展开全文
  • 概念模型与关系模型和关系规范化

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

    》概念模型

           概念模型用于信息世界的建模,是实现现实世界到信息世界的第一层抽象,是数据库设计人员进行数据库设计的有力工具,也是数据库设计人员和用户之间进行交流的语言,因此概念模型一方面具有较强的语义表达能力,能够方便、直接地表达应用中的各种语义知识;另一方面是表达简单、清晰、易于用户理解。

    》信息世界中的基本概念

        1、 实体(Entity

        客观存在并可相互区别的事物称为实体。实体可以是具体的人、事、物,也可以是抽象的概念或联系。

        2、 属性(Attribute

        实体所具有的某一特性称为属性。一个实体可以由若干个属性来刻画。

        3、 码(key

        唯一标识实体的属性集称为码。

         4、 域(Domain

         属性的取值范围称为该属性的域。

         5、 实体型(Entity Type

         具有相同属性的实体必然具有共同的特征和性质。用实体名与属性名集合来抽象和刻画同类实体,称为实体型。

          6、 实体集(Entity Set

         同型实体的集合称为实体集。

         7、 联系(Relationship

          在现实世界汇总,事物内部及事物之间是有联系的,这些联系在信息世界中反映为实体(型)内部的联系和实体(型)之间的联系。实体内部的联系通常是指组成实体的各属性之间的联系。实体之间的联系通常是指不同实体集之间的联系。

              #  一对一联系(1:1

                 如果对于实体集A中的每一个实体,实体集B中至多有一个(也可以没有)实体与之联系,反之亦然,则称实体集A与实体集B具有一对一的联系,记为1:1

              # 一对多联系(1:N

                 如果对于实体集A中的每一个实体,实体集B中有N个实体与之联系,反之,对于实体集B中的每一个实体,实体集A至多有一个实体与之联系,则称实体集A与实体集B具有一对多的联系,记为1:N

             #多对多联系(M:N

                 如果对于实体集A中的每一个实体,实体集B中有N个实体与之联系,反之,对于实体集B中的每一个实体,实体集A中有M个实体与之联系,则称实体集A与实体集B具有多对多的联系,记为M:N

               一对一联系是一对多联系的特例,一对多联系又是多对多联系的特例。

    》概念模型的表示方法

           概念模型是对信息世界的建模。最常用的是实体-联系方法(Entity-RelationshipApproach)。该方法用E-R图来描述现实世界的概念模型,E-R方法也称E-R模型。     

           E-R图提供了表示信息世界中实体、属性和联系的方法,具体为:

          实体型:用矩形表示,矩形框内写明实体的名称。

          属性: 用椭圆表示,并用无向边将其与相应的实体连接起来。

          联系:  用菱形表示,菱形框内写明联系的名称,并用无向边分别与有关实体连接起来,同时在无向边旁边标上联系的类型(1:1、1:N、M:N)。如果一个联系具有属性,则这些属性也要用无向边与该联系连接起来。

          E-R方法是抽象和描述现实世界的有力工具。用E-R图表示的概念模型独立于具体的DBMS所支持的数据模型,它是各种数据模型的共同基础,因而比数据模型更一般、更抽象、更接近现实世界。

    》关系模型

    数据模型是数据库系统的核心和基础,不同的数据模型提供了不同的模型化数据和信息的工具。

    现有的数据库系统均基于某种数据模型,其中关系数据库是采用关系模型作为数据组织方式的数据库。关系模型是目前数据库管理系统中实现最多的一类数据模型,它是用二维表结构来表现实体及实体间联系的模型,并以二维表的形式组织数据库中的数据。

     

        数据结构和术语=>关系模型

           关系:一个关系逻辑上对应一张二维表(格)。可以为每个关系取一个名称进行标识。与之同义的术语是“表”。

           元组:表中的一行即为一个元组。与之同义的术语是“行”。

           分量:元组中的一个属性值。与之同义的术语是“列值”。

           属性:表中的一列即为一个属性,给每一个属性起一个名称即属性名。与之同义的术语是“列”。

           域  :属性的取值范围。与之同义的术语是“数据类型”。

           主码:表中的某个属性组,它可以唯一确定一个元组。与之同义的术语就是“主键”。

           表  :由行和列组成。可以为每个表取一个表名进行标识。

           行  :表中的一条记录。表中的数据是按行存储的。

           列  :表中的一个字段。所有表都是由一个或多个列组成的。

           主键:表中的一列或一组列,其值能够唯一区分表中的每个行。其中,由一组列构成的主键称为组合主键。

           外键:表中的一列或一组列,其包含另一张表的主键值,主要用于定义两个表之间的关系。与之同义的术语是“外部码”。

           关系模式:对关系的描述,一般表示为“关系名(属性1,属性2,属性n)”。

           数据类型:所容许的数据的类型。每个表列都有相应的数据类型,它限制(或容许)该列中存储的数据。

        关系规范化的基本方法

              为了减少数据库中的数据冗余,增强数据的易操作性,消除数据插入、删除异常等现象,关系模型要求关系必须是规范化的。

              即要求数据库中的每张表都必须满足一定的规范条件。在实际应用中,这些规范条件从对表的基本约束到严格要求依次分为:

            #第一范式(1NF

                规则一:表中的每个列只包含具有原子性的值,即关系的每一个分量必须是一个不可分的数据项。

            #第二范式(2NF

                规则一:首先要符合第一范式。

                规则二:没有部分函数依赖性,即表中不存在非主键的列依赖于组合主键某个部分的现象

            #第三范式(3NF

                规则一:首先要符合第二范式。

                规则二:没有传递函数依赖性,即表中不存在任何非主键列与其他非主键列相互关联的现象。

            #修正的第三范式(BCNF

                规则一:首先要符合第三范式。

                规则二:表中不存在主键列对主键的部分函数依赖和传递函数依赖。

        关系规范化:

             一个低一级范式的关系模式,通过模式分解逐步消除数据依赖中不合适的部分,使模式中的各关系模式达到某种程度的分离,转换为若干个高一级范式的关系模式的集合,这种过程就是关系规范化。

             通过消除非主键列对主键的部分函数的依赖,将1NF表规范为2NF表。

             通过消除非主键列对主键的传递函数的依赖,将2NF表规范为3NF表。

             通过消除主键列对主键的部分函数依赖和传递函数依赖,将2NF表规范为BCNF表。

             另外,在关系模型中,满足关系规范化要求的表与表之间会存在以下三种形式的联系;

                  #一对一(1:1)的关联

                       一对一的关联从概念上表达的是一个数据对象与另外一个数据对象之间仅表现为一对一的关系;从逻辑上表达的是某个表中的一行数据行仅与另一个表中的某一数据行相对应。

                  # 一对多(1:N)的关联

                       一对多的关联从概念上表达的是一个数据对象与另外一个数据对象之间表现为一对多的关系;从逻辑上表达的是某个表中的一行数据行可与另外一个表中的多条数据行相对应。

                  #多对多(M:N)的关联

                       多对多的关联从概念上表达的是一个数据对象与另外一个数据对象之间表现为多对多的关系;从逻辑上表达的是某个表A中的一行数据行可与另外一个表B中的多条数据行相对应,同时这个表A中的多条数据行又与表B中的某一行数据行相对应。

          数据库设计

                需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实现、数据库运行和维护。

           概念结构设计

                概念结构设计就是将需求分析得到的用户需求抽象为信息结构(概念模型)的过程,通常使用E-R图来描述现实世界的概念模型。

                 概念结构是独立于任何一种(逻辑)数据模型的信息结构。

           逻辑结构设计

                在关系数据库设计中,逻辑结构设计的任务就是把概念结构设计阶段已设计好的基本E-R图转换为关系模型。

           基本E-R图向关系模型的转换

                关系模型的逻辑结构是一组关系模式的集合,而E-R图则是由实体、实体的属性和实体间的联系三个要素组成的。

                将E-R图转换为关系模型实际上就是要将实体、实体的属性、实体间的联系转换为关系模式。

                转换一般遵循一下原则:

                         1、  一个实体型转换为一个关系模式,实体的属性作为关系的属性,实体的码作为关系的码。

                         2、  一个一对一(1:1)联系可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式合并。如果转换为一个独立的关系模式,则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,每个实体的码均是该关系的候选码;如果与某一端实体对应的关系模式合并,则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性。

                         3、  一个一对多的(1:N)联系可以转换为一个独立的关系模式,也可以与N端对应的关系模式合并。如果转换为一个独立的关系模式,则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而关系的码为N端实体的码。

                        4、  一个多对多(M:N)联系转换为一个关系模式,与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而关系的码为各实体码的组合。

                        5、  三个或三个以上的实体间的一个多元联系可以转换为一个关系模式,与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而关系的码为各实体码的组合

                        6、  具有相同码的关系模式可以合并。

    数据模型的优化

    数据库逻辑设计的结果不是唯一的。

    为了进一步提高数据库应用系统的性能,还应该根据应用需要适当地修改、调整数据模型的结构,这就是数据模型的优化。

    关系数据模型的优化通常以关系规范化理论为指导:

    1、  确定数据依赖。

    2、  对于各个关系模式之间的数据依赖进行极小化处理,消除冗余的联系。

    3、  按照数据依赖的理论对关系模式逐一分析,考察是否存在部分函数依赖、传递函数依赖等,确定各关系模式分别属于第几范式。

    4、  按照需求分析阶段得到的处理要求,分析这些模式对于这样的应用环境是否合适,确定是否要对某些模式进行合并或分解。

    5、  对关系模式进行必要的分解,提高数据操作的效率和存储空间的利用率。

    设计用户子模式

    将概念模型转换为全局逻辑模型之后,可根据局部应用需求,利用视图(view)设计更符合局部用户需要的用户外模式。

    物理设计

    数据库在物理设备上的额存储结构和存取方式称为数据库的物理结构它依赖于给定的计算机系统。为一个给定的逻辑数据模型选定一个最合适应用要求的物理结构的过程,就是数据库的物理设计。

     

    数据库的物理设计通常分两步:

    1、  确定数据库的物理结构

    在关系数据库中主要指存取方法和存储结构,设计关系、索引等数据库文件的物理存储结构

    2、  对物理结构进行评价

    评价的重点是时间和空间效率。如果评价结果满足原设计要求,则可进入到物理实施阶段,否则需要重新设计或修改物理结构,有时甚至需要返回逻辑设计阶段修改数据模型。

    展开全文
  • 关系数据库设计是对数据进行组织和结构的过程,核心问题是关系模型的设计。关系模型是数学的、用二维表格数据描述各实体之间的联系的模型;它是所有的关系模式、属性名和关键字的汇集,是关系模式描述的对象。...
    关系数据库设计是对数据进行组织化和结构化的过程,核心问题是关系模型的设计。关系模型是数学化的、用二维表格数据描述各实体之间的联系的模型;它是所有的关系模式、属性名和关键字的汇集,是关系模式描述的对象。关系模式是指一个关系的属性名表,即二维表的表框架。关系模式的设计是关系模型设计的灵魂。所以,关系模式的设计是关系数据库设计核心的核心。 
    
    关系模式的设计直接决定着关系数据库的性能。目前,在指导关系模式的设计中规范化(normalization)设计占有主导地位,它是在数据库几十年的长期发展中产生并成熟的。但近年来这一领域出现了一种新的趋势,一种称为非规范化(denormalization)的关系模式设计引起业界的关注并已在一定的范围内得到应用。对这一新的设计思想,各方反应迥异褒贬不一,从而在相关的理论界掀起了一场不大不小的规范化与非规范化之争。本文简单介绍了规范化与非规范化设计的基本思想,综述了正反双方争论的要点,供国内业界相关人员参考。

    一、规范化设计
    关系模式规范化设计的基本思想是通过对关系模式进行分解,用一组等价的关系子模式来代替原有的关系模式,消除数据依赖(包括函数依赖和多值依赖)中不合理的部分,使得一个关系仅描述一个实体或者实体间的一种联系。这一过程必须在保证无损连接性、保持函数依赖性的前提下进行,即确保不破坏原有数据,并可将分解后的关系通过自然联接恢复至原有关系。
    具体地说,规范化设计的过程就是按不同的范式,将一个二维表不断地分解成多个二维表并建立表之间的关联,最终达到一个表只描述一个实体或者实体间的一种联系的目标。目前遵循的主要范式包括1 NF、 2 NF、3 NF、BCNF、4NF和5NF等几种;在工程中3NF、BCNF应用得最广泛,推荐采用 3 NF作为标准。
    规范化设计的优点包括可有效地消除数据冗余,理顺数据的从属关系,保持数据库的完整性,增强数据库的稳定性、伸缩性、适应性。通常认为规范化设计存在的主要问题是增加了查询时的连接库表运算,导致计算机时间、空间、系统及运行效率的损失。在大多数情况下,这一问题可通过良好的索引设计等方法得到解决。

    二、非规范化设计
    非规范化设计的基本思想是,现实世界并不总是依从于某一完美的数学化的关系模式。强制性地对事物进行规范化设计,形式上显得简单化,内容上趋于复杂化,更重要的是导致数据库运行效率的减低。非规范化要求适当地降低甚至抛弃关系模式的范式,不再要求一个表只描述一个实体或者实体间的一种联系。其主要目的在于提高数据库的运行效率。
    非规范化处理的主要技术包括增加冗余或派生列,对表进行合并、分割或增加重复表。一般认为,在下列情况下可以考虑进行非规范化处理:(1)大量频繁的查询过程所涉及的表都需要进行连接;(2) 主要的应用程序在执行时要将表连接起来进行查询;(3)对数据的计算需要临时表或进行复杂的查询。
    非规范化设计的主要优点是减少了查询操作所需的连接;减少了外部键和索引的数量;可以预先进行统计计算,提高了查询时的响应速度。非规范化存在的主要问题是增加了数据冗余;影响数据库的完整性;降低了数据更新的速度;增加了存储表所占用的物理空间。其中最重要的是数据库的完整性问题。这一问题一般可通过建立触发器、应用事务逻辑、在适当的时间间隔运行批命令或存储过程等方法得到解决。

    三、规范化与非规范化争论的要点
    支持非规范化设计的一方认为,数据库规范化的程度越高,其中表的数量越多,规范化程度与表的数量直接相关;表的数量越多,表的连接运算也越多;连接运算增多,必然降低数据库执行的速度,影响数据库的性能。只有通过非规范化设计,显著减少表的数量,从而减少对连接运算的依赖,加速数据库执行的速度,才能保证数据库性能的正常发挥。例如目前流行于决策支持系统的非规范化星型模式就远胜于应用规范化设计,是非规范化设计的最好范例。非规范化设计并不意味着混乱和无视规则,它也遵循保护信息完整性等软件工程的基本原则。
    支持规范化设计的一方认为,规范化与非规范化只是一个逻辑概念,强调非规范化设计者混淆了逻辑与物理的关系。数据库的性能是由物理水平决定的,即硬件、数据库的大小和物理设计、数据存储和访问的方法、数据库管理系统的优化程度、并发访问的数量等;非规范化设计并未改变数据库的物理水平,因此不可能提高数据库的性能。规范化并不只是为了避免数据冗余,更重要的是为了确保数据库的完整性。非规范化设计的最大问题是难以保证数据库中数据的一致性,存在着破坏数据的危险。此外,非规范化使一个表中存在多个实体,不同实体混合在一起强化了数据库的复杂性,提高了用户理解的难度,并导致描述问题上的困难,增加了正确响应的风险。只有规范化设计才是解决这些问题的根本途径。如果不摒弃非规范化设计理念,为了获得所谓的性能的提高而漠视数据库完整性被破坏的风险,就无法激励开发商去研究真正的完全规范化而高性能的关系数据库管理系统,其后果必然影响数据库的健康发展。
    从某种意义上说,数据库的规范化与非规范化设计并不是对立的、非此即彼的关系。也许其中一方会逐渐消亡,也许二者存在一条中间道路可走。认识事物原本存在一个螺旋式上升的过程。这场争论尚未结束,也无法对最终的结果进行预测。但可以肯定的是,无论结果如何,都将对未来数据库的发展方向产生深远的影响。            
    展开全文
  • 最近在学数据库原理,关系规范化中介绍了几个算法,最基础也最重要的就是求属性集X关于某个函数依赖集合F的闭包。 /*8周的功夫一本数据库基本原理就学完了,很快要考试了,所以5-1假期也没打算出去玩,就在学校了...
  • 输出:结果为满足第三范式的一个依赖保持的分解 条件: 1.如果R中有某些属性与F的最小覆盖Fmin中的左边右边都没有关系,则这个(些)属性构成一个关系模式。如果没有就进行2 2. 如果Fmin中有一个函数依赖涉及R中的...
  • 关系模式设计中的问题关系数据库设计要解决的主要问题 什么样的数据库模式才合理? 怎么分解才能满足要求? 衡量的标准是什么? 理论基础是什么? 如何进行实现? 关于好的数据库模式好的数据库模式是不会发生插入...
  • 规范化、标准化、归一化、正则化

    万次阅读 多人点赞 2018-07-18 21:52:39
    规范化关系满足的规范要求分为几级,满足要求最低的是第一范式(1NF),再来是第二范式、第三范式、BC范式和4NF、5NF等等,范数的等级越高,满足的约束集条件越严格。 针对数据 数据的规范化包括归一化标准化正则...
  • 数据库设计之反规范化

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

    万次阅读 多人点赞 2018-05-15 22:11:58
    数据规范化数据规范化(归一化)处理是数据挖掘的一项基础工作。不同评价指标往往具有不同的量纲,数值见的差别可能很大,不进行处理可能会影响到数据分析的结果。为了消除指标之间的量纲和取值范围差异的影响,需要...
  • 数据规范化(标准化)

    万次阅读 2018-01-24 16:57:36
    数据规范化(标准化) 在数据预处理时,这两个术语可以互换使用。(不考虑标准化在统计学中有特定的含义)。  下面所有的规范化操作都是针对一个特征向量(dataFrame中的一个colum)来操作的。  首先举一个...
  • 谈谈需求分析规范化

    千次阅读 2017-01-01 22:40:55
    通过需求工程化来降低需求工程的复杂度,让需求分析人员有章可循,与用户形成共同语义环境,也就是需求分析的规范化
  • 文本规范化(Text Normalization)

    千次阅读 2020-03-13 13:35:34
    文本规范化问题作为自然语言处理中的重要一步,很多人对此进行了各种研究。在本文中,我们提出了一种解决此问题的新模型,GRFE(Gated Recurrent Feature Extractor)。该模型充分利用了符号的类别信息,并据此规范...
  • mysql优化(三) 逆规范化与反三范式

    千次阅读 2017-01-06 11:48:45
    因为规范化越高,那么产生的关系就越多,关系过多的直接结果就是导致表之间的连接操作越频繁,而表之间的连接操作是性能较低的操作,直接影响到査询的速度,所以,对于査询较多的应用,就需要根据实际情况运用逆规范...
  • 在对数据库进行一些操作的时候我们可能会遇到以下的一些问题: 数据冗余(想修改一个属性,就要...其实这就是因为有数据依赖的原因,因为彼此之间有一些依赖关系,所以导致我们的操作总是牵涉颇多,处理不干净 数据依...
  • 一、归一,标准和中心 广义的标准: (1)离差标准(最大最小值标准) (2)标准差标准 (3)归一标准 (4)二值标准 (5)独热编码标准 归一 (Normalization)、标准 ...
  • 数据库规范化三个范式应用实例

    千次阅读 2004-10-14 22:16:00
    规范化为什么重要?目前很多的数据库由于种种原因还没有被规范化。本文中解释了其中一些原因,并用不同形式的范式(normal form)规范化了一个保险公司的理赔表。在这个过程中表的改变以及添加的一些附加表使数据库...
  • 转载自解决数据冗余,插入,删除更新异常——数据依赖与规范化 在对数据库进行一些操作的时候我们可能会遇到以下的一些问题: 数据冗余(想修改一个属性,就要更新多行数据) 插入异常(想要插入数据,结构因为表设计的...
  • 数据库规范化理论---求候选键

    千次阅读 多人点赞 2018-01-21 11:16:01
    关系模式R<U,F>中为F所逻辑蕴含的函数依赖的全体叫作F的闭包,记为F+。 属性集X关于函数依赖集F的闭包: 设F为属性集U上的一组函数依赖,XÍU,XF+ ={A|X→A能由F根据Armstrong公理导出},XF+称为属性...
  • 规范化。。。呃,这个东西看你要有多规范了,给你个cmmi定义的5个层次做参考吧。1. 手工作坊式,即产品质量全靠开发人员的个人英雄主义做法,无法保证开发新产品能有同样的质量。2. 已经有了一些流程,进行一定的...
  • 数据库规范化理论---模式分解

    千次阅读 2018-01-21 19:03:48
    如上题,如果分解的结果集中,只要有一个集合,能够通过现有的函数依赖,还原成原来的集合,则无损。 关键: 还原过程中,只能通过现有集合中的元素确定新元素加入,不能把新加入的元素再用来确定新元素。   ...
  • 关系模式R<U, F>中为F所逻辑蕴涵的函数依赖的全体叫做F的闭包(closure),记作。 设F为属性集U上的一组函数依赖,XU,={A|X→A能由F根据Armstrong公里导出},称为属性集X关于函数依赖集F的闭包。 另外...
  • 规范化。。。呃,这个东西看你要有多规范了,给你个cmmi定义的5个层次做参考吧。1. 手工作坊式,即产品质量全靠开发人员的个人英雄主义做法,无法保证开发新产品能有同样的质量。2. 已经有了一些流程,进行一定的...
  • 数据规范化标准化 Normalizer 规范化、StandardScaler、 MinMaxScaler、 MaxAbsScaler label 与feature的重新编号(码)。 VectorIndexer、 StringIndexer、 IndexToString 、oneHotEncoder、bucketizer分箱,...
  • 一文彻底搞懂前端模块:exports、module.exports、export、import、export default CommonJS规范、ES Module规范
  • 关系(1)域(Domain)(2)笛卡尔积(Cartesian Product)(3)关系(Relation)(4)三类关系2.关系模式(1)什么是关系模式(2)定义关系模式3.关系模式和关系的对比4.关系数据库 0.思维导图 1. 关系 什么是...
  • 范式是符合某一种级别的关系模式的集合,是衡量关系模式规范化程度的标准,达到的关系才是规范化的。 目前有6中范式: 第一范式(1NF):每个属性都是不可再分的 第二范式(2NF):不存在非主属性对主属性的...
  • 现阶段我们可以跳过这些规范化的设计阶段,直接在现有的经验的基础上粗略设计模块,节省设计时间,用之后的重构来替代设计的劣势。当然,这并不代表着永久的放弃这种规范化的操作,到了某个阶段,如果有必要,我们也...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 261,820
精华内容 104,728
关键字:

关系规范化的结果