精华内容
下载资源
问答
  • [MySQL]关系规范化中的操作异常理解

    千次阅读 2019-01-02 19:25:58
    插入失败:该插入的没插入; 插入异常:不该插入的被插入; 删除失败:该删除的没删除; 删除异常:不该删除的被删除; 简单地说:失败:有心栽花花不开,异常:无心插柳柳成荫...

    插入失败:该插入的没插入;

    插入异常:不该插入的被插入;

    插入异常:该插入的没插入;

    删除失败:该删除的没删除;

    删除异常:不该删除的被删除;

    简单地说 对于删除来说: 失败:有心栽花花不开,异常:无心插柳柳成荫

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

    千次阅读 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了。

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

    千次阅读 多人点赞 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)。外键是数据库用于实现参照完整型的约束,利用数据库的外键可以保证数据的完整性和一致性;外键的级联操作可以方便数据的自动处理,减少了程序出错的可能性。

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

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

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

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


    总结

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

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

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

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

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

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

    千次阅读 多人点赞 2020-07-31 11:08:14
    数据库是一门对数据进行有效管理的技术,它研究信息资源如何被安全地储存和如何被高效地利用,它是现代计算机科学的一个重要分支。...本文通过例举具体事例来探讨关系规范化理论在数据库逻辑设计中的形成和方法。
  • 关系模式的规范化

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

    千次阅读 2018-05-16 22:21:49
    关系模式:关系模式相当于一张二维表的框架,在这个框架下填入数据,称为关系模式的一个实例...•未经规范化的数据库一般都有下述缺点: 较大的数据冗余,数据一致性差,数据修改复杂,对表进行插入、删除、更新时会...
  • 关系数据库规范化理论

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

    千次阅读 2013-03-19 13:45:11
    最近在学习数据库过程中,发现几本教材大都是按照数据库系统概论->关系数据库基础->SQL语言->关系数据库理论(大都是介绍规范化)介绍,第二部分的关系数据库基础主要谈到了基本算术运算关系和域运算,比如交并差,...
  • 文章目录0.思维导图1.为什么要学习关系数据库规范化理论?(1)基本概念回顾(2)...规范化---改造关系模式,解决插入异常、删除异常、更新异常和数据冗余问题。(1)规范化研究什么?(2)函数依赖① 函数依赖② 平
  • 第三篇:更新异常规范化设计

    千次阅读 2018-07-21 15:16:53
    ER建模,关系建模与规范化设计 小结 回到顶部 前言  在前两篇中,主要讲了ER建模和关系建模。在具体分析如何用数据库管理软件RDBMS(Relational Database Management System)实现这些关系前,我想有必要思考下面...
  • 关系数据库的规范化

    千次阅读 2014-11-19 22:23:11
    关系数据理论 一、设计中的问题 1、数据冗余大 数据冗余大的是数据会经常重复出现,浪费了大量的存储空间。 2、更新异常 ... 在数据冗余度大的时候,会导致更新异常,...3、删除异常 会导致数据丢失。 4、插入
  • 关系数据库规范化理论---范式

    千次阅读 2017-11-08 15:27:02
    范式规范化关系模式,由于规范程度不同,产生了不同的范式、 一个低一级的关系范式通过模式分解可以转换成若干高一级范式的关系模式的集合。这个过程称为关系模式的规范化关系模式规范化的必要性:关系...
  • 关系数据库设计规范化流程

    千次阅读 2011-09-15 14:59:42
    规范化:确保数据正确地分布到数据库的表中,防止操作异常及大量冗余信息的存储。数据冗余不仅占用物理空间,对数据的维护和一致性检查也带来了问题。   范式及举例:   第一范式:【数据库表中
  • 关于好的数据库模式好的数据库模式是不会发生插入异常、删除异常、更新异常,同时数据冗余尽可能少的模式。产生不好模式的根本原因是数据之间存在着某些数据依赖。解决方法是通过分解关系来消除其中不合适的数据依赖...
  • 关系模式规范化(设计范式)

    千次阅读 2020-10-28 19:13:56
    关系数据库中的关系满足一定要求的,满足不同程度要求的为不同的范式。满足最低要求的叫第一范式,简称1NF;在第一范式的基础上满足进一步要求的称为第二范式,简称2NF,其余范式以此类推。对于各种范式之间有如下...
  • 规范化理论:范式等级

    千次阅读 2019-05-12 16:14:48
    关系模式规范化的基本思想是消除关系模式中的数据冗余,消除数据依赖中的不合适的部分,解决数据插人、删除时发生的异常现象。这就要求关系模式要满足一定的条件。我们把关系模式规范化过程中为不同程度的规范化要求...
  • 数据库规范化理论

    千次阅读 2018-06-24 09:57:39
    本文版权归作者AlvinZH和博客园所有,欢迎转载和商用,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律...其中D、DOM与模式设计关系不大,可以看作三元组R<U,F>...
  • 数据库题目之关系数据理论

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

    千次阅读 2019-05-12 21:04:11
    假设学校中一门课程可由多名教师讲授,教学中他们使用相同的一套参考书,这样我们可用下图的非规范化关系来表示课程C、教师T和参考书B间的关系关系CTB 如果关系CIB转化成规范化关系,如图所示。 ...
  • 数据库规范化(范式)(一)

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

    千次阅读 多人点赞 2019-11-18 14:36:23
    参考资料:Wiki百科、百度百科、Google、博客园等,定义性的内容,直接引用了官方介绍。 本文参照以下目录进行内容组织: 什么是好的数据库设计?...关系模型的分解特性 模式分解存在的问题...
  • 规范化理论:模式分解

    千次阅读 2019-05-13 22:51:05
    的一个分解是:={<,>, ... ,<,>},其中=...,并且,1i,jn,是在上的投影。相应地将R储存在二维表r中的数据分散到二维表,,... ,中去,其中是属性r在属性集上的投影。 把低一级的关系模式分解为...
  • 关系数据理论

    千次阅读 2019-09-03 23:03:47
    一、关系规范化理论背景 二、规范化理论
  • **2018博客之星评选,如果喜欢我的文章,请投我一票,编号:No....(1)数据清理:填写空缺值,平滑噪声数据,识别,删除孤立点,解决不一致性 (2)数据集成:集成多个数据库,数据立方体,文件 (3)数据变换:...
  • 数据库规范化三个范式应用实例

    千次阅读 2004-10-14 22:16:00
    规范化为什么重要?目前很多的数据库由于种种原因还没有被规范化。本文中解释了其中一些原因,并用不同形式的范式(normal form)规范化了一个保险公司的理赔表。在这个过程中表的改变以及添加的一些附加表使数据库...
  • 数据库的设计范式是数据库设计所需要满足的规范,满足这些规范的数据库是简洁的、结构明晰的,同时,不会发生插入(insert)、删除(delete)和更新(update)操作异常。反之则是乱七八糟,不仅给数据库的编程人员...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 42,925
精华内容 17,170
关键字:

关系规范化的删除异常是指