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

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

    展开全文
  • 关系数据库设计:谈谈规范化技术

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

    在这里插入图片描述


    大家好,我是只谈技术不剪发的 Tony 老师。今天我们来聊聊关系数据库的规范化设计问题。本文不涉及数据库教材上晦涩难懂的各种公式,而是从实际应用出发,通过简单直白的方式介绍规范化的设计过程和常见范式。

    为什么需要规范化?

    很多教材和文章都是直接从第一范式开始介绍如何进行数据库设计,完全忽略了对事物前因后果的分析;从而导致我们看完之后,只知道要关系数据库要进行规范设计,但却不知道为什么要这么做。因此,我们首先来给大家介绍一下规范化之前发生了什么。

    假设我们需要为某公司设计一个数据库,用于管理员工、部门、职位等相关的信息。首先从直观上考虑,可以将员工信息、所在部门以及职位信息存储到一个表中,如下图所示:

    0nf
    每一行数据对应一个员工的信息,包括他/她所在的部门、职位等。如果真的这么设计,我们在实际应用中很快就会发现以下各种问题:

    • 数据冗余,同一个部门的信息存储了多份,这就需要占用更多的磁盘空间。另外,数据冗余有时候也可能是指在不同的表中存储了重复的信息;
    • 插入异常,假如现在需要成立一个新的部门,由于还没有增加新的员工,因此无法录入这个部门的信息;
    • 更新异常,如果需要修改某个部门信息,需要更新多行数据,效率低下;不小心忽略了某些记录的话,还会会导致数据不一致,尤其是当一个信息存储到多个表中时更容易出现这种情况。
    • 删除异常,如果某个部门的所有员工都被删除,将会导致这个部门的信息也将不复存在;

    关系数据库之父 Edgar F. Codd 显然意识到了这些问题,并且为此引入了规范化(Normalization)的设计过程。规范化使用范式(normal form)来定义和衡量,范式就是数据库设计时遵循的一种标准级别。Codd 最早提出了第一范式(1NF)、第二范式(2NF)以及第三范式(3NF),每个范式都基于前面的范式定义,例如第二范式需要先满足第一范式。

    📝更高级别的范式包括 BC 范式(BCNF)、第四范式(4NF)、基本元组范式(ETNF)、第五范式(5NF)、DK 范式(DKNF)以及第六范式(6NF);一般来说,满足第三范式的数据库就可以避免数据冗余和操作异常问题。

    通过以上介绍,我们知道了规范化是数据库设计过程中的一系列原理和技术,使用范式来定义和衡量,主要用于减少表中数据的冗余,消除异常,提高数据完整性和一致性

    下面我们基上面的非规范化数据库结构,逐步介绍第一范式到第三范式的实现过程。

    第一范式

    第一范式(First Normal Form)要求满足以下条件:

    • 表中的字段都是不可再分的单一属性;
    • 表需要定义主键(PRIMARY KEY)。

    简单来说,首先就是每个属性要有单独的字段。在上面的不规范设计中,员工的个人电话和工作电话存储在一个字段中,破坏了原子性。另外,还需要为表定义一个主键,用于唯一识别表中的每一行数据;假设每个部门中的员工不会同名,可以使用部门名称加员工姓名作为主键。

    将上面的示例修改成以下结构就可以满足第一范式:

    1nf
    第一范式要求表中的字段具有不可分割的原子特性;不过我们知道,原子是化学反应不可再分的基本微粒,但在物理状态中可以分割,它是由原子核和绕核运动的电子组成。因此,我们同样需要考虑字段不可分割到底是针对什么而言。

    例如,上面的“姓名”字段,实际上也可以拆分成两个字段:姓氏和名字。那么到达要不要拆分呢?显然这个取决于应用程序如何使用这些信息,一般我们将姓名作为一个字段存储;有些应用可能需要拆分,这样在给客户发送消息时可以方便地显示为“尊敬的刘先生/女生”。

    另一个类似的情况是地址信息,例如“XX省XX市XX区XX小区”,存储到一个字段还是拆分成多个字段?大部分情况下,应用程序可能需要统计不同地区的用户情况,拆分成多个字段便于分析。不过这时候需要注意的是如何确保数据的标准化,因为不同的用户虽然住在相同的小区,但会输入不一致的数据;所以最好提供一组标准的数据,提供下拉列表给用于进行选择。

    除了基本的数字、字符、日期等数据类型之外,SQL 还提供了一些复杂的类型,例如数组、XML、JSON 以及自定义类型等。假如我们使用一个 JSON 字段存储电话号码,数据如下所示:

    {
      "phoneNumbers": [
        {
          "type": "office",
          "number": "61238888"
        },
        {
          "type": "mobile",
          "number": "13612345678"
        }
      ]
    }
    

    那么这种设计算不算违反第一范式?从定义来说这显然不属于第一范式,因为这个字段中包含了多个可以分割的属性。

    但是,从 SQL 标准来说这些类型都属于原生类型,而且提供了对这种数据进行处理和查询的内置函数和方法;如果从应用程序的角度来看,例如电商平台中的产品信息、博客文章中的评论信息,可以将它们看作一个原子数据存储在 XML 或者 JSON 字段中,因为没有进行分割处理的需求。

    📝SQL 是关系数据库的标准语言,但 SQL 远远不只能够存储和处理关系模型,XML 或者 JSON 文档、多维数组、图形存储以及流数据处理已经成为了 SQL 标准中的一部分,具体可以参考这篇文章

    以上表结构满足第一范式,但仍然存在数据冗余(例如部门信息),可能导致插入异常、删除异常、修改异常等问题;所以我们还需要进一步规范化。

    第二范式

    第二范式(Second Normal Form)要求满足以下条件:

    • 满足第一范式;
    • 非主键字段必须完全依赖于主键或者候选键,不能只依赖于主键或者候选键的一部分。

    上面表结构中的“部门地址”取决于“部门名称”,也就是主键的一部分;这种依赖关系称为部分函数依赖(partial functional dependency)。显然,此时表中的部门信息存在冗余,可能导致各种操作异常。

    为此我们可以将部门信息单独存储到一张部门表中,并且在部门表和员工表之间维护一个一对多的关系。我们继续将表的结构修改如下:

    2nf
    我们将员工表拆成了 3 个表,员工表中的部门编号和职位编号是外键,分别引用了部门表的主键和职位表的主键。另外,我们为每个表增加了一个 id 主键字段(工号、部门编号、职位编号)。因为部门名称、职位名称等信息并不适合作为主键;如果使用部门名称作为主键,当需要修改某个部门的名称,员工表中可能需要相应修改多条记录。

    如果考虑到同一个部门中可能存在同名的员工,直接在员工表中增加一个 id 主键字段也可以满足第二范式的要求。

    2nf
    以上表结构满足第二范式,但仍然存在数据冗余(例如部门信息),可能导致插入异常、删除异常、修改异常等问题;所以我们还需要进一步规范化。

    第三范式

    第三范式要求满足以下条件:

    • 满足第二范式;
    • 属性不依赖于其它的非主属性,也就是非关键字段不依赖于其他非关键字段。

    当主键决定字段 A,字段 A 又决定字段 B 时,称为传递函数依赖(transitive functional dependency)。例如员工编号决定了部门编号,部门编号决定了部门名称;如果将部门信息和员工信息放在一张表中,就存在这种依赖。显然,在上一节中将员工表拆分成三个表之后就不存在这种问题,因此满足第三范式。

    最终,我们设计的公司数据库结构(ER 图)如下:

    erd
    其中,部门和员工的关系是一对多的关系;职位和员工的关系也是一对多的关系。

    现在我们来回顾一下非规范化设计时的几个问题:

    • 部门、员工以及职位信息分别存储一份,通过外键保持它们之间的联系。因此,不存在数据冗余的问题;
    • 如果想要成立一个新的部门,直接录入部门信息即可,解决了插入异常的问题;
    • 如果某个部门的所有员工都被删除,该部门的信息不会受到影响,不存在删除异常;
    • 如果需要修改部门信息,直接更新部门表即可,不会导致数据不一致。

    对于前三个范式而言,只需要将不同的实体/对象单独存储到一张表中,并且通过外键建立它们之间的联系即可满足。这也是大多数在线交易系统数据库理想的设计方法。

    反规范化

    简单来说,规范化就是将大表拆分成多个小表,并且通过外键建立它们之间的联系。但是,规范化可能导致连接查询(JOIN)过多。例如,为了查看员工所在的部门名称和职位名称,我们需要关联查询 3 个表:

    SELECT e.emp_name, e.hire_date, d.dept_name, j.job_title
    FROM employee e 
    JOIN department d ON (d.dept_id = e.dept_id)
    JOIN job j ON (j.job_id = e.job_id)
    WHERE e.emp_name = '孙尚香';
    
    emp_name|hire_date |dept_name|job_title|
    --------|----------|---------|---------|
    孙尚香   |2002-08-08|财务部    |财务经理  |
    

    如果表中的数据量很大,过多的表连接查询会增加数据库的 IO 操作,从而降低数据库的性能。因此,有时候为了提高某些查询或者应用的性能而故意降低规范反的程度,也就是反规范化(denormalization)。一般来说,数据仓库(Data Warehouse)和在线分析系统(OLAP)会使用到反规范化的技术,因为它们以复杂查询和报表分析为主。

    常用的反规范化方法包括增加冗余字段、增加计算列、将小表合成大表等。例如想要知道每个部门的员工数量的话,需要同时连接部门表和员工表;可以在部门表中增加一个字段(emp_numbers),查询时就不需要再连接员工表,但是每次增加或者删除员工时需要更新该字段。

    需要注意的是,反规范化会增加更新和修改数据的开销,导致数据存在冗余,可能带来数据完整性和一致性的问题;因此,通常我们应该先进行规范化设计,再根据实际情况考虑是否需要反规范化

    关于外键

    在数据库结构设计时,还有一个经常争论的问题就是需不需要使用外键(FOREIGN KEY)。外键是数据库用于实现参照完整型的约束,利用数据库的外键可以保证数据的完整性和一致性;外键的级联操作可以方便数据的自动处理,减少了程序出错的可能性。

    例如,员工属于部门,员工的部门字段上可以创建一个外键引用部门表的主键。此时,我们必须先创建部门,然后才能为该部门创建员工;不会出现员工属于一个不存在的部门的情况,保证了数据的完整性。同时,如果要删除一个部门的话,必须同时处理该部门下的员工;可以选择级联删除员工或者将员工的部门修改为其他部门等操作。

    既然外键拥有这么多好处,为什么我们还要讨论是否需要使用外键呢?主要是性能问题。因为任何事情都是有代价的,数据库为了维护外键需要牺牲一定的性能,尤其是在大数据量高并发的情况下。因此出现了另一种解决方案,就是将完整性检查放到应用层去实现,而应用程序相对比较容易扩展。

    不过,在应用端实现约束也可能导致一些问题。首先,无法百分之百保证不会出现问题,尤其是多个应用同时共享一个数据库时。缺失外键可能导致数据库的结构不明确,需要依赖相应的文档进行说明。

    总之,在系统的设计之初应该尽量使用外键确保完整性。如果随着业务增长出现性能问题,可以考虑在应用中实现约束。


    总结

    本文从非规范化数据库结构可能导致的问题出发,介绍了关系数据库为什么应该进行规范化设计以及常用的各种范式。同时,我们还讨论了特殊应用场景下的反规范化问题和外键的取舍。

    如果觉得文章对你有用,欢迎关注❤️、评论📝、点赞👍

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

    千次阅读 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、  对物理结构进行评价

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

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

    万次阅读 多人点赞 2016-09-29 13:27:42
    原文路径:...了解关系模式规范化的作用 掌握第一范式-重点 掌握第二范式-重点 掌握第三范式-重点 回顾关系
  • 关系数据库设计是对数据进行组织和结构的过程,核心问题是关系模型的设计。关系模型是数学的、用二维表格数据描述各实体之间的联系的模型;它是所有的关系模式、属性名和关键字的汇集,是关系模式描述的对象。...
  • 关系模式设计中的问题关系数据库设计要解决的主要问题 什么样的数据库模式才合理? 怎么分解才能满足要求?...解决方法是通过分解关系来消除其中不合适的数据依赖。数据依赖数据依赖的定义数据依赖是数据之间的
  • 数据库的规范化与非规范化比较

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

    千次阅读 2013-06-24 10:13:27
    1、反规范的好处  ...所以,关系有时故意保留成非规范化的,或者规范化以后又反规范了,这样做通常是为了改进性能。  例如帐户系统中的“帐户”表B-TB01,它的列busi-balance(企业帐户的总余额)就违
  • 为什么要学习关系数据库规范化理论?(1)基本概念回顾(2)关系模式的形式化定义(3)什么是数据依赖F?(4)数据依赖F对关系模式的影响1️⃣ 数据冗余(Data redundancy)2️⃣ 更新异常(update anomalies )3️⃣ ...
  • 原文地址:数据的规范化,归一化,标准化,正则化作者:打湿井盖  数据的规范化,归一化,标准化,正则化,... 规范化理论把关系应满足的规范要求分为几级,满足最低要求的一级叫做第一范式(1NF),在第一范式的
  • 【吐血整理】数据库的规范化

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

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

    千次阅读 2017-01-01 22:40:55
    通过需求工程化来降低需求工程的复杂度,让需求分析人员有章可循,与用户形成共同语义环境,也就是需求分析的规范化
  • 数据的规范化,归一化,标准化,正则化,... 规范化理论把关系应满足的规范要求分为几级,满足最低要求的一级叫做第一范式(1NF),在第一范式的基础上提出了第二范式(2NF),在第二范式的基础上又提出了第三范式(3NF),
  • 一、归一,标准和中心 广义的标准: (1)离差标准(最大最小值标准) (2)标准差标准 (3)归一标准 (4)二值标准 (5)独热编码标准 归一 (Normalization)、标准 ...
  • 【数据库】函数依赖和规范化

    千次阅读 2016-11-01 16:51:22
     在数据库中,关系模式中的属性值之间会发生联系。譬如每个学生只有一个姓名,每门课程只能有一个任课老师。这类联系就称为函数依赖(functional dependency,简记为FD)。 X→Y,读作X函数决定Y,即知道了X的值就...
  • 数据库规范化理论---模式分解

    千次阅读 2018-01-21 19:03:48
    这里主要讨论基础考试选择题,判断一个分解是有损无损、是否保持函数依赖。 一、公式法 无损分解⇔R1∩R2→(R1-R2)或R1∩R2→(R2-R1) 保持函数依赖⇔(F1∪F2)+=F+ 说明:这里的判断无损的→以及判断保持...
  • 关系(1)域(Domain)(2)笛卡尔积(Cartesian Product)(3)关系(Relation)(4)三类关系2.关系模式(1)什么是关系模式(2)定义关系模式3.关系模式和关系的对比4.关系数据库 0.思维导图 1. 关系 什么是...
  • 华为C语言编程规范(精华总结)

    万次阅读 多人点赞 2020-03-24 09:48:55
    在公司已有编码规范的指导下,审慎地编排代码以使代码尽可能清晰,是一项非常重要的技能。 如果重构/ / 修改其他风格的代码时,比较明智的做法是根据 现有 代码 的 现有风格继续编写代码,或者使用格式转换工具进行...
  • 数据规范化标准化 Normalizer 规范化、StandardScaler、 MinMaxScaler、 MaxAbsScaler label 与feature的重新编号(码)。 VectorIndexer、 StringIndexer、 IndexToString 、oneHotEncoder、bucketizer分箱,...
  • 构造器 与构造方法关系

    万次阅读 2020-06-28 22:48:42
    java中的构造器有两种:分别是 实例构造器和类构造器<cinit> . 构造器的作用: 构造器的产生过程实际...()方法中无须调用父类的()方法,虚拟机会自动保证父类构造器的执行,但在()方法中经常会生成调用java.lang.
  • B方法-拓展你形式化方法的视野

    千次阅读 2013-11-26 23:11:41
    非形式的自然语言描述软件规范容易引起二义性等其他问题,人们将数学引入软件开发,建立起了形式化方法。形式化方法在软件开发中有其特殊用途,为我们开发软件提供了更严格的数学逻辑。本文将通过B方法,让你对...
  • 主要敏捷开发方法

    千次阅读 2009-09-24 16:59:00
    主要的敏捷方法极限编程(XP) 极限编程(XP)的主要目的是降低需求变化的成本。它引入一系列优秀的软件开发方法,并将它们发挥到极致。比如,为了能及时得到用户的反馈,XP要求客户代表每天都必须与开发团队在一起...
  • Java后端自顶向下方法——Servlet规范

    万次阅读 2020-04-23 17:11:47
    Java后端自顶向下方法——Servlet规范 (一)简单介绍 Servlet是啥?Servlet是Sun公司提供的一门用于开发动态web资源的技术,按照一种约定俗成的称呼习惯,通常我们也把实现了servlet接口的java程序,称之为Servlet...
  • 最常见的标准化方法就是Z标准,也是SPSS中最为常用的标准化方法,spss默认的标准化方法就是z-score标准。 也叫标准差标准,这种方法给予原始数据的均值(mean)和标准差(standard deviation)进行数据的...
  • Servlet规范总结

    万次阅读 2016-10-08 08:49:39
    Servlet接口Servlet规范的核心接口即是Servlet接口,它是所有Servlet类必须实现的接口,在Java Servelt API中已经提供了两个抽象类方便开发者实现Servlet类,分别是GenericServlet 和 HttpServlet,GenericServlet...
  • 异步编程之Javascript Promises 规范介绍

    千次阅读 2016-04-19 10:11:10
    Promises是一种关于异步编程的规范,目的是将异步处理对象和处理规则进行规范化,为异步编程提供统一接口。
  • 具体的改进方法包括增加真实或者人工生成的实验数据、减小网络规模和正则,具体介绍了L_2正则、L_1正则、Dropout三种主要的正则化方法。最后从实际经验出发定性的分析了为什么正则可以减小过拟合的问题,

空空如也

空空如也

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

关系规范化的主要方法是