精华内容
下载资源
问答
  • 关系模式的规范化理论

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

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

    展开全文
  • 规范化-数据库设计原则

    千次阅读 2017-10-22 21:20:55
    关系型数据库是当前广泛应用的数据库类型,关系数据库设计是对数据进行组织和结构的过程,核心问题是关系模型的设计。对于数据库规模较小的情况,我们可以比较轻松的处理数据库中的表结构。然而,随着项目规模的...

    摘要

    关系型数据库是当前广泛应用的数据库类型,关系数据库设计是对数据进行组织化和结构化的过程,核心问题是关系模型的设计。对于数据库规模较小的情况,我们可以比较轻松的处理数据库中的表结构。然而,随着项目规模的不断增长,相应的数据库也变得更加复杂,关系模型表结构更为庞杂,这时我们往往会发现我们写出来的SQL语句的是很笨拙并且效率低下的。更糟糕的是,由于表结构定义的不合理,会导致在更新数据时造成数据的不完整。因此,就有必要学习和掌握数据库的规范化流程,以指导我们更好的设计数据库的表结构,减少冗余的数据,借此可以提高数据库的存储效率,数据完整性和可扩展性。本文将结合具体的实例,介绍数据库规范化的流程。

    序言

    本文的目的就是通过详细的实例来阐述规范化的数据库设计原则。在DB2中,简洁、结构明晰的表结构对数据库的设计是相当重要的。规范化的表结构设计,在以后的数据维护中,不会发生插入(insert)、删除(delete)和更新(update)时的异常。反之,数据库表结构设计不合理,不仅会给数据库的使用和维护带来各种各样的问题,而且可能存储了大量不需要的冗余信息,浪费系统资源。

    要设计规范化的数据库,就要求我们根据数据库设计范式――也就是数据库设计的规范原则来做。但是一些相关材料上提到的范式设计,往往是给出一大堆的公式,这给设计者的理解和运用造成了一定的困难。因此,本文将结合具体形象的例子,尽可能通俗化地描述三个范式,以及如何在实际工程中加以优化应用。

    规范化

    在设计和操作维护数据库时,关键的步骤就是要确保数据正确地分布到数据库的表中。 使用正确的数据结构,不仅便于对数据库进行相应的存取操作,而且可以极大地简化应用程序的其他内容(查询、窗体、报表、代码等)。正确进行表设计的正式名称就是"数据库规范化"。后面我们将通过实例来说明具体的规范化的工程。关于什么是范式的定义,请参考附录文章 1.

    数据冗余

    数据应该尽可能少地冗余,这意味着重复数据应该减少到最少。比如说,一个部门雇员的电话不应该被存储在不同的表中, 因为这里的电话号码是雇员的一个属性。如果存在过多的冗余数据,这就意味着要占用了更多的物理空间,同时也对数据的维护和一致性检查带来了问题,当这个员工的电话号码变化时,冗余数据会导致对多个表的更新动作,如果有一个表不幸被忽略了,那么就可能导致数据的不一致性。

    规范化实例

    为了说明方便,我们在本文中将使用一个SAMPLE数据表,来一步一步分析规范化的过程。

    首先,我们先来生成一个的最初始的表。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    CREATE TABLE "SAMPLE" (
               "PRJNUM" INTEGER NOT NULL,
               "PRJNAME" VARCHAR(200),
               "EMYNUM" INTEGER NOT NULL,
               "EMYNAME" VARCHAR(200),
               "SALCATEGORY" CHAR(1),
               "SALPACKAGE" INTEGER)  
              IN "USERSPACE1";
     
    ALTER TABLE "SAMPLE"
         ADD PRIMARY KEY
             ("PRJNUM", "EMYNUM");
     
    Insert into SAMPLE(PRJNUM, PRJNAME, EMYNUM, EMYNAME, SALCATEGORY, SALPACKAGE)
    values(100001, 'TPMS', 200001, 'Johnson', 'A', 2000), (100001, 'TPMS', 200002,
    'Christine', 'B', 3000), (100001, 'TPMS', 200003, 'Kevin', 'C', 4000), (100002,
    'TCT', 200001, 'Johnson', 'A', 2000), (100002, 'TCT', 200004, 'Apple', 'B',
    3000);
    表1-1
    表1-1

    考察表1-1,我们可以看到,这张表一共有六个字段,分析每个字段都有重复的值出现,也就是说,存在数据冗余问题。这将潜在地造成数据操作(比如删除、更新等操作)时的异常情况,因此,需要进行规范化。

    第一范式

    参照范式的定义,考察上表,我们发现,这张表已经满足了第一范式的要求。

    1、因为这张表中字段都是单一属性的,不可再分;

    2、而且每一行的记录都是没有重复的;

    3、存在主属性,而且所有的属性都是依赖于主属性;

    4、所有的主属性都已经定义

    事实上在当前所有的关系数据库管理系统(DBMS)中,都已经在建表的时候强制满足第一范式。因此,这张SAMPLE表已经是一张满足第一范式要求的表。考察表1-1,我们首先要找出主键。可以看到,属性对<Project Number, Employee Number>是主键,其他所有的属性都依赖于该主键。

    从一范式转化到二范式

    根据第二范式的定义,转化为二范式就是消除部分依赖。

    考察表1-1,我们可以发现,非主属性<Project Name>部分依赖于主键中的<Project Number>; 非主属性<Employee Name>,<Salary Category>和<Salary package>都部分依赖于主键中的<Employee Number>;

    表1-1的形式,存在着以下潜在问题:

    1. 数据冗余:每一个字段都有值重复;

    2. 更新异常:比如<Project Name>字段的值,比如对值"TPMS"了修改,那么就要一次更新该字段的多个值;

    3. 插入异常:如果新建了一个Project,名字为TPT, 但是还没有Employee加入,那么<Employee Number>将会空缺,而该字段是主键的一部分,因此将无法插入记录;

    Insert into SAMPLE(PRJNUM, PRJNAME, EMYNUM, EMYNAME, SALCATEGORY, SALPACKAGE) values(100003, 'TPT', NULL, NULL, NULL, NULL)

    4. 删除异常:如果一个员工 200003, Kevin 离职了,要将该员工的记录从表中删除,而此时相关的Salary信息 C 也将丢失, 因为再没有别的行纪录下 Salary C的信息。

    Delete from sample where EMYNUM = 200003
    Select distinct SALCATEGORY, SALPACKAGE from SAMPLE

    因此,我们需要将存在部分依赖关系的主属性和非主属性从满足第一范式的表中分离出来,形成一张新的表,而新表和旧表之间是一对多的关系。由此,我们得到:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    CREATE TABLE "PROJECT" (
               "PRJNUM" INTEGER NOT NULL,
               "PRJNAME" VARCHAR(200))
              IN "USERSPACE1";
     
    ALTER TABLE "PROJECT"
         ADD PRIMARY KEY
             ("PRJNUM");
     
    Insert into PROJECT(PRJNUM, PRJNAME) values(100001, 'TPMS'), (100002, 'TCT');
    表1-2
    表1-2
    表 1-3
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    CREATE TABLE "EMPLOYEE" (
               "EMYNUM" INTEGER NOT NULL,
               "EMYNAME" VARCHAR(200),
    "SALCATEGORY" CHAR(1),
    "SALPACKAGE" INTEGER)
              IN "USERSPACE1";
     
    ALTER TABLE "EMPLOYEE"
         ADD PRIMARY KEY
             ("EMYNUM");
     
    Insert into EMPLOYEE(EMYNUM, EMYNAME, SALCATEGORY, SALPACKAGE) values(200001,
    'Johnson', 'A', 2000), (200002, 'Christine', 'B', 3000), (200003, 'Kevin', 'C',
    4000), (200004, 'Apple', 'B', 3000);
     
    Employee Number Employee Name   Salary Category Salary Package
    200001  Johnson A   2000
    200002  Christine   B   3000
    200003  Kevin   C   4000
    200004  Apple   B   3000
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    CREATE TABLE "PRJ_EMY" (
               "PRJNUM" INTEGER NOT NULL,
               "EMYNUM" INTEGER NOT NULL)
              IN "USERSPACE1";
     
    ALTER TABLE "PRJ_EMY"
         ADD PRIMARY KEY
             ("PRJNUM", "EMYNUM");
     
    Insert into PRJ_EMY(PRJNUM, EMYNUM) values(100001, 200001), (100001, 200002),
    (100001, 200003), (100002, 200001), (100002, 200004);

    同时,我们把表1-1的主键,也就是表1-2和表1-3的各自的主键提取出来,单独形成一张表,来表明表1-2和表1-3之间的关联关系:

    表 1-4
    表 1-4

    这时候我们仔细观察一下表1-2, 1-3, 1-4, 我们发现插入异常已经不存在了,当我们引入一个新的项目 TPT 的时候,我们只需要向表1-2 中插入一条数据就可以了, 当有新人加入项目 TPT 的时候,我们需要向表1-3, 1-4 中各插入一条数据就可以了。虽然我们解决了一个大问题,但是仔细观察我们还是发现有问题存在。

    从二范式转化到三范式

    考察表前面生成的三张表,我们发现,表1-3存在传递依赖关系,即:关键字段< Employee Number > --> 非关键字段< Salary Category > -->非关键字段< Salary Package >。而这是不满足三范式的规则的,存在以下的不足:

    1、 数据冗余:<Salary Category>和<Salary Package>的值有重复;

    2、 更新异常:有重复的冗余信息,修改时需要同时修改多条记录,否则会出现数据不一致的情况;

    3、 删除异常:同样的,如果员工 200003 Kevin 离开了公司,会直接导致 Salary C 的信息的丢失。

    Delete from EMPLOYEE where EMYNUM = 200003
    Select distinct SALCATEGORY, SALPACKAGE from EMPLOYEE

    因此,我们需要继续进行规范化的过程,把表1-3拆开,我们得到:

    表 1-5
    表 1-5

    表 1-6
    表 1-6

    这时候如果 200003 Kevin 离开公司,我们只需要从表 1-5 中删除他就可以了, 存在于表1-6中的Salary C信息并不会丢失。但是我们要注意到除了表 1-5 中存在 Kevin 的信息之外, 表1-4中也存在 Kevin 的信息, 这很容易理解, 因为 Kevin 参与了项目 100001, TPMS, 所以当然也要从中删除。

    至此,我们将表1-1经过规范化步骤,得到四张表,满足了三范式的约束要求,数据冗余、更新异常、插入异常和删除异常。

    在三范式之上,还存在着更为严格约束的BC范式和四范式,但是这两种形式在商业应用中很少用到,在绝大多数情况下,三范式已经满足了数据库表规范化的要求,有效地解决了数据冗余和维护操作的异常问题。

    结束语

    在本文描述的过程中,我们通过结合实例的方法,通俗地演绎了数据表规范化的过程,并展示了在此过程中数据冗余、数据库操作异常等问题是如何得到解决的。

    在具体的工程应用中,运用数据库规范化的方法来设计数据库表,将是具有现实意义的。

    相关主题

    from: https://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0605jiangt/index.html
    陈博和蒋韬
    展开全文
  • 关系数据库规范化理论

    千次阅读 2018-03-01 22:54:50
    1、关系规范化的作用所谓规范化,就是用形式更为简洁、结构更加规范的关系模式取代原有关系的过程。2、函数依赖2.1、属性间的联系实体间的联系有两类:一类是实体与实体之间的联系;另一类是实体内部各属性间的联系...
    关系数据库规范化理论
    一个关系数据库由一组关系模式组成,一个关系由一组属性名组成,关系数据库设计就是如何把已给定的相互关联的一组属性名分组,并把每一组属性名组织成关系的问题。
    1 、关系规范化的作用
    所谓规范化,就是用形式更为简洁、结构更加规范的关系模式取代原有关系的过程。
    2 、函数依赖
    2.1 、属性间的联系
    实体间的联系有两类:一类是实体与实体之间的联系;另一类是实体内部各属性间的联系。
    属性间的联系可分为以下三类:
    (1 )一对一联系(1 ∶1
    以职工模式为例:职工(职工号,姓名,职称,部门)。如果该企业(或单位)中职工无重名,则属性职工号与姓名之间是1∶1联系。一个职工号唯一地决定一个姓名,一个姓名也可决定唯一的职工号。
    设X、Y是关系R的两个属性(集)。如果对于X中的任一具体值,Y中至多有一个值与之对应,且反之亦然,则称X、Y两属性间是一对一联系。
    (2 )一对多联系(1 ∶ m
    在职工模式中,职工号和职称间是一对多联系。一个职工号只对应一种职称(如胡一民只能对应工程师),但一种职称却可对应多个职工号(如工程师可对应多名职工)。
    设X、Y是关系R的两个属性(集)。如果对于X中的任一具体值,Y中至多有一个值与之对应,而Y中的一个值却可以和X中的n个值相对应,则称Y对X是一对多联系。
    (3 )多对多联系(m ∶ m
    在职工模式中,职称和部门之间是多对多联系。一种职称可分布在多个部门中(如每一个部门中均可有工程师),而一个部门中也可有多个职称。
    设X、Y是关系R的两个属性(集)。如果对于X中的任一具体值,Y中有m个值与之对应,而Y中的一个值也可以和X中的n个值相对应,则称Y对X是多对多联系。
    上述属性间的三种联系实际上是属性值之间相互依赖又相互制约的反映,称为属性间的数据依赖。
    数据依赖共有三种:函数依赖( FunctionalDependency ,简称 FD )、多值依赖( Multiva-luedDependency ,简称 MVD )和连接依赖( JoinDependency ,简称 JD ),其中最重要的是函数依赖和多值依赖。
    2.2 、函数依赖
    函数依赖是属性之间的一种联系。假设给定一个属性的值,就可以唯一确定(查到)另一个属性的值。
    定义:所谓函数依赖是指在关系 R 中, X Y R 的两个属性或属性组,如果对于 R 的任一关系 r 都存在:对于 X 的每一个具体值, 都只有一个具体值与之对应,则称属性 Y 函数依赖于属性 X 。或者说,属性 X 函数决定属性 Y ,记作 X à Y 其中X叫决定因素,Y叫被决定因素。当Y是X的子集时,称为平凡函数依赖。由于平凡函数依赖总是成立的,因此,若不作特殊声明,本书后面提到的函数依赖,都不包含平凡函数依赖。
    此定义可简单表述为:如果属性X的值决定属性Y的值,那么属性Y函数依赖于属性X。
    前面讨论的属性间的三种联系,并不是每一种联系中都存在函数依赖。
    (1)如果两属性集X、Y 间是1∶ 1联系,则存在函数依赖:X ß>Y。
    (2)如果两属性集X、Y间是m∶ 1联系,则存在函数依赖:X àY。
    (3)如果两属性集X、Y间是m∶ n联系,则不存在函数依赖。
    2.3 、码的定义
    定义  K  是关系模式  R U F )中的属性或属性组, K ′是  K  的任一真子集。若 K à U ,而不存在 K à U ,则 K R 的候选码( CandidateKey ),简称为码。
    · 若候选码多于一个,则选定其中的一个为主码(PrimaryKey);
    · 包含在任一候选码中的属性,叫做主属性(PrimeAttribute);
    · 不包含在任何候选码中的属性称为非主属性(NonprimeAttribute)或非码属性(Non KeyAttribute);
    · 关系模式中,最简单的情况,单个属性是码,称为单码(SingleKey);最极端的情况,整个属性组是码,称为全码(All Key)。
    定义 设有两个关系模式R和S,X是R的属性或属性组,并且X不是R的码,但X是S的码(或与S的码意义相同),则称X是R的外部码(ForeignKey),简称外码。
    2.4 、函数依赖和码的唯一性
    码是由一个或多个属性组成的可唯一标识元组的最小属性组。码在关系中总是唯一的,即码函数决定关系中的其他属性。因此,一个关系中,码值总是唯一的(如果码的值重复,则整个元组都会重复)。否则,违反实体完整性规则。
    与码的唯一性不同,在关系中,一个函数依赖的决定因素可能是唯一的,也可能不是唯一的。如果我们知道A决定B,且A和B在同一关系中,但我们仍无法知道A是否能决定除B以外的其他所有属性,所以无法知道A在关系中是否是唯一的。
    3 、关系模式的规范化
    3.1 、关系模式的规范化
    当一个关系中的所有分量都是不可分的数据项时,该关系是规范化的
    关系按其规范化程度从低到高可分为5级范式,分别称为1NF、2NF、3NF(BCNF)、4NF、5NF。规范化程度较高者必是较低者的子集
    3.2 、第一范式(1NF
    定义 如果关系模式 R 中不包含多值属性,则 R 满足第一范式,简称 1NF FirstNor-malForm ),记作 R 属于 1NF
    1NF是规范化的最低要求,不满足1NF的关系是非规范化关系
    3.3 、第二范式(2NF
    定义 X Y 是关系 R 的两个不同的属性或属性组,且 X 属于 Y 。如果存在 X 的某一个真子集 X ′,使 X ′属于成立,则称 Y 部分函数依赖于 X ,反之,则称 Y 完全函数依赖于 X
    定义 如果一个关系 R 属于 1NF ,且它的所有非主属性都完全函数依赖于 R 的任一候选码,则 R 属于第二范式,记作 R 属于 2NF
    推论:如果关系模式R‑1NF,且它的每一个候选码都是单码,则R属于2NF。
    3.4 、第三范式(3NF
    定义 在关系 R 中, X Y Z R 的三个不同的属性或属性组,如果 X à Y Y à Z ,但 Y/-->X Y 不是 X 的子集,则称 Z 传递依赖于 X
    定义 如果关系模式 R 属于 2NF ,且它的每一个非主属性都不传递依赖于任何候选码,则称 R 是第三范式,记作 R 属于 3NF
    推论1 如果关系模式R属于1NF,且它的每一个非主属性既不部分依赖,也不传递依赖于任何候选码,则R属于3NF。
    推论2 不存在非主属性的关系模式一定为3NF。
    3.5 、改进的3NF ——BCNF
    定义 设关系模式R(U,F)属于NF,若F的任一函数依赖X àY(Y不是X的子集)中X都包含了R的一个码,则称R属于BCNF。
    换言之,在关系模式R中,如果每一个决定因素都包含码,则R属于BCNF。
    由BCNF的定义可以得到以下推论:如果R属于BCNF,则
    · R中所有非主属性对每一个码都是完全函数依赖;
    · R中所有主属性对每一个不包含它的码,都是完全函数依赖;
    · R中没有任何属性完全函数依赖于非码的任何一组属性。
    定理:如果R属于BCNF,则R属于3NF一定成立。
    一个关系模式如果达到了BCNF,那么在函数依赖范围内,它已实现了彻底的分离,消除了数据冗余、插入和删除异常。
    4 、多值依赖和第四范式
    定义 设R(U)是属性集U上的一个关系模式,X、Y、Z是U的子集,且Z=U-X-Y。如果对R(U)的任一关系r,给定一对(x,z)值,都有一组Y值与之对应,这组Y值仅仅决定于x值而与z值无关。称Y多值依赖于X,或X多值决定Y,记作X ààY。
    定义中如果Z为空集,则称X ààY为平凡的多值依赖,否则为非平凡多值依赖。
    定义 如果关系模式R属于1NF,对于R的每个非平凡的多值依赖X ààY(Y不是X的子集),X含有码,则称R是第四范式,即R属于4NF。
    一个关系模式如果属于4NF,则一定属于BCNF,但一个BCNF的关系模式不一定是4NF的,R中所有的非平凡多值依赖实际上是函数依赖。
    5 、关系的规范化度
    关系规范化的目的是解决关系模式中存在的数据冗余、插入和删除异常、更新繁琐等问题。其基本思想是消除数据依赖中的不合适部分,使各关系模式达到某种程度的分离,使一个关系描述一个概念、一个实体或实体间的一种联系。因此,规范化的实质是概念的单一化。
    规范化的基本原则是:由低到高,逐步规范,权衡利弊,适可而止。通常,以满足第三范式为基本要求。
    把一个非规范化的数据结构转换成第三范式,一般经过以下几步:
    (1)把该结构分解成若干个属于第一范式的关系。
    (2)对那些存在组合码,且有非主属性部分函数依赖的关系必须继续分解,使所得关系都属于第二范式。
    (3)若关系中有非主属性传递依赖于码,则继续分解之,使得关系都属于第三范式。
    关系模式的规范化过程是通过投影分解实现的,即用投影运算把一个模式分解成若干个高一级的关系模式。这种投影分解不是唯一的。
    展开全文
  • 关系数据库设计的核心问题是关系模型的设计。本文将结合具体的实例,介绍数据库设计规范化的流程。 摘要 关系型数据库是当前广泛应用的数据库类型,关系数据库设计是对数据进行组织...规范化-数据库设计原则(案例).pdf
  • 关系模式的规范化

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

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

    千次阅读 2017-11-09 22:27:30
    因为在写项目时与同伴关于数据库到底建多少张表,每张表应包含哪些属性产生分歧,所以又好好研究了一下关系型数据库在设计时应该遵守怎样的规则以提高数据库性能。 在阅读本篇文章前读者须掌握关系数据库结构基础及...
  • 数据库规范化设计的五个原则

    千次阅读 2014-11-20 19:43:48
    很明显,这不符合数据库设计规范化的需 求。  遇到这种情况时,笔者建议可以把上面这张表分解成三种独立的表,分别为图书基本信息表、作者基本信息表、图书与作者对应表等等。如此设计以后,以上遇到的所有问题就...
  • 关系数据库设计是对数据进行组织和结构的过程,核心问题是关系模型的设计。关系模型是数学的、用二维表格数据描述各实体之间的联系的模型;它是所有的关系模式、属性名和关键字的汇集,是关系模式描述的对象。...
  • 规范化技术

    2011-11-14 16:31:06
    数据库的规范化理论不仅仅是关系模式设计的理论指导和强有力的工具,对其它数据模型数据库的逻辑设计也 同样有理论意义,数据的规范化不仅会带来空间上的效率,而且还有助于保证数据的正确性和一致性。它是现在...
  • 最近在学数据库原理,关系规范化中介绍了几个算法,最基础也最重要的就是求属性集X关于某个函数依赖集合F的闭包。 /*8周的功夫一本数据库基本原理就学完了,很快要考试了,所以5-1假期也没打算出去玩,就在学校了...
  • 软件开发编程规范原则

    万次阅读 2016-12-07 22:05:54
    相信大家看到标题都应该能明白编程的规范原则对于每一个软件开发的工程师来说是多么重要。   初学者编写测试程序、小的模块程序也许不能感受它的重要性;但有经验及大型项目开发的人就知道程序的规范性对...
  • 规范化理论:范式等级

    千次阅读 2019-05-12 16:14:48
    关系模式规范化的基本思想是消除关系模式中的数据冗余,消除数据依赖中的不合适的部分,解决数据插人、删除时发生的异常现象。这就要求关系模式要满足一定的条件。我们把关系模式规范化过程中为不同程度的规范化要求...
  • 原文地址:数据的规范化,归一化,标准化,正则化作者:打湿井盖  数据的规范化,归一化,标准化,正则化,... 规范化理论把关系应满足的规范要求分为几级,满足最低要求的一级叫做第一范式(1NF),在第一范式的
  • 数据库规范化(范式)(一)

    千次阅读 2018-04-01 15:45:58
    ——转自:https://blog.csdn.net/hbrqlpf/article/details/1887204关系数据库规范化理论一个...1、关系规范化的作用所谓规范化,就是用形式更为简洁、结构更加规范的关系模式取代原有关系的过程。2、函数依赖2.1...
  • 谈谈需求分析规范化

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

    千次阅读 2014-10-08 11:36:31
    在我们的日常生活和工作中,常会用到"标准化,规范化,系统化"这些词汇,我们在使用这些词汇时究竟有没有真正理解它们的含义?这些词都是动词,当我们在使用这些词汇时,是否知道究竟意味着要做什么? 下面...
  • 关系数据理论

    千次阅读 2019-09-03 23:03:47
    一、关系规范化理论背景 二、规范化理论
  • 【数据库】函数依赖和规范化

    千次阅读 2016-11-01 16:51:22
     在数据库中,关系模式中的属性值之间会发生联系。譬如每个学生只有一个姓名,每门课程只能有一个任课老师。这类联系就称为函数依赖(functional dependency,简记为FD)。 X→Y,读作X函数决定Y,即知道了X的值就...
  • 前端设计原则 一致性 Consistency   与现实生活一致:与现实生活的流程、逻辑保持一致,遵循用户习惯的语言和概念; 在界面中一致:所有的元素和结构需保持一致,比如:设计样式、图标和文本、元素的位置等。...
  • 企业规范化建设的五个步骤

    千次阅读 2008-02-21 13:43:00
    根据软件工程和CMMI的理论,公司项目的良性发展需要完善一系列措施,在刚实施项目规范化的时候,开发效率会有一定程度的降低,毕竟,习惯的力量是巨大很难改变的,很多时候,我们往往认为自己的开发模式是正确地,...
  • 数据库题目之关系数据理论

    千次阅读 2019-01-10 15:14:46
    1、关系规范化中的删除操作异常是指 ① ,插入操作异常是指 ② 。  A.不该删除的数据被删除 B.不该插入的数据被插入 C.应该删除的数据未被删除 D.应该插入的数据未被插入【答案:】①A ②D 2、设计性能较优...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 118,185
精华内容 47,274
关键字:

关系规范化的原则