精华内容
下载资源
问答
  • 关系规范化的主要方法是
    千次阅读
    2019-09-09 20:50:36


         数据库设计的规范化能够经常被提及,但是反规范化很少被涉猎。实际应用中反规范化应用的场景很多。本文主要介绍一下数据库的反规范化。

    一、规范化

    常见的规范化有数据库设计的三范式。

    • 1NF 是最低的规范化要求。如果关系 R 中所有属性的值域都是简单域,属性不可再分。
    • 2NF 非主属性完全函数依赖于码
    • 3NF 非主属性不传递依赖于任何一个候选码

    二、反规范化

        数据库中的数据规范化的优点是减少了数据冗余,节约了存储空间,相应逻辑和物理的I/O 次数减少,同时加快了增、删、改的速度,但是对完全规范的数据库查询,通常需要更多的连接操作,从而影响查询速度。因此,有时为了提高某些查询或应用的性能而破坏规范规则,即反规范化(非规范化处理)。

    常见的反规范化技术包括:

    • (1)增加冗余列
      增加冗余列是指在多个表中具有相同的列,它常用来在查询时避免连接操作。例如:以规范化设计的理念,学生成绩表中不需要字段“姓名”,因为“姓名”字段可以通过学号查询到,但在反规范化设计中,会将“姓名”字段加入表中。这样查询一个学生的成绩时,不需要与学生表进行连接操作,便可得到对应的“姓名”。

    • (2)增加派生列
      增加派生列指增加的列可以通过表中其他数据计算生成。它的作用是在查询时减少计算量,从而加快查询速度。例如:订单表中,有商品号、商品单价、采购数量,我们需要订单总价时,可以通过计算得到总价,所以规范化设计的理念是无须在订单表中设计“订单总价”字段。但反规范化则不这样考虑,由于订单总价在每次查询都需要计算,这样会占用系统大量资源,所以在此表中增加派生列“订单总价”以提高查询效率。

    • (3)重新组表
      重新组表指如果许多用户需要查看两个表连接出来的结果数据,则把这两个表重新组成一个表来减少连接而提高性能。

    • (4)分割表
      有时对表做分割可以提高性能。表分割有两种方式。
      水平分割:根据一列或多列数据的值把数据行放到两个独立的表中。水平分割通常在下面的情况下使用。

      情况 1:表很大,分割后可以降低在查询时需要读的数据和索引的页数,同时也降低了索引的层数,提高查询效率。
      情况 2:表中的数据本来就有独立性,例如表中分别记录各个地区的数据或不同时期的数据,特别是有些数据常用,而另外一些数据不常用。
      情况 3:需要把数据存放到多个介质上。

    • (5)垂直分割:把主码和一些列放到一个表,然后把主码和另外的列放到另一个表中。如果一个表中某些列常用,而另外一些列不常用,则可以采用垂直分割,另外垂直分割可以使得数据行变小,一个数据页就能存放更多的数据,在查询时就会减少 I/O 次数。其缺点是需要管理冗余列,查询所有数据需要连接操作。


    END
    更多相关内容
  • 关系数据库设计:谈谈规范化技术

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

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

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

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

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


    总结

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

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

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

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

    原文路径:http://wenku.baidu.com/link?url=KzN3v3voao4ovz_izsiujMN8vMZMiArzgYbrue8tVL5L_ydc1B_6_1eEy7vfoSiO2-ORTXAXzVBxzWAaXJxiR68z6g4GMD_1AlZWzx46MSG

     

    了解关系模式规范化的作用

    掌握第一范式-重点

    掌握第二范式-重点

    掌握第三范式-重点

    回顾关系模式

    关系模式:关系模式相当于一张二维表的框架,在这个框架下填入数据,称为关系模式的一个实例,或者叫关系(R)

    R(A1,A2,A3..Ai):R是关系名,Ai是关系的属性名。一个关系名对应一张表,关系名对应表名,属性对应表中的列名。

    关系模型的简化表示法: R<U,F>

     

    关系模式规范化的作用

    关系型数据库的设计主要是关系模式的设计。关系模式设计的好坏直接影响关系型数据库设计的成败。将关系模式规范化是设计好关系型数据库的唯一途径。

    关系模式的规范化主要有范式来完成。

     

    关系模式

    所谓范式(Normal Form, NF)是指规范化的关系模式。由规范化程度不同而产生不同的范式。根据满足条件不同,经常称某一关系模式R为“第几模式”。

     

    为什么要设计规范化的数据库?

    未经规范化的数据库一般都有下述缺点:

    较大的数据冗余,数据一致性差,数据修改复杂,对表进行更新,插入,删除是会报异常。规范化的作用就在于尽量去除冗余,使数据保持一致,使数据修改简单,除去在表中进行插入、删除时产生的异常,规范化后的表一般都较小。

     

    第一范式(1NF)

    在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系型数据库。

    定义:在关系模型中的每一个具体关系R中,如果每个属性都是不可再分的,则称R属于第一范式(1NF),记作R属于1NF。

    第一范式(1NF):数据库表中的字段都是单一属性的,不可再分。

    e.g.如下的数据库表是符合第一范式的:

    字段1   字段2   字段3   字段4

    而这样的数据库表是不符合第一范式的:

    字段1   字段2   字段3(字段3.1,字段3.2)   字段4

    如职工号,姓名,电话号码组成一个表(一个人可能有一个办公室电话和一个家里的电话号码)规范成为1NF。

    总结:不能有重复的列,列不可再分。

    不满足第一范式条件的关系为非范式关系,在关系数据库中,凡非范式关系必须要化成范式关系。

     

    第二范式(2NF)

    第二范式是在第一范式的基础上建立起来的,即满足第二范式必须先满足第一范式(1NF)。

    定义:如果关系模式R属于1NF,且每一个非主属性都完全依赖于主码,则称关系R是属于第二范式的,记作R属于2NF。

    第二范式(2NF)说明:要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖于主关键字的一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。

    e.g.

    假定选修课关系表为SelectCourse(学号,姓名,年龄,课程名称,成绩,学分),关键字为组合关键字(学号,课程名称),因为存在如下决定关系:

    (学号,课程名称)->(姓名,年龄,成绩,学分)

    这个数据库表不满足第二范式,因为存在如下决定关系:

    (课程名称)->(学分)

    (学号)->(姓名,年龄)

    即存在学分和姓名,年龄部分依赖于主关键字。

    由于不符合2NF,这个选课关系表会存在如下问题:

    (1)数据冗余:

    同一门课程会有N个学生选修,“学分”就会重复N-1次;同一个学生选修了M门课程,那姓名和年龄会重复M-1次。

    (2)更新异常:

    若课程的学分更新,那必须把表中所有的学分值都更新,不然会出现同一课程出现不同的学分。

    (3)插入异常:

    假设要开设一门新的课程,但是目前还没有学生选修这门课程,由于没有学号导致数据无法录入到数据库中。

    (4)删除异常:

    假设一批学生已经完成课程的选修,这些选修记录就应该从数据库中删除,但是,同时,课程名称和学分信息也被删除了。很显然,这也会导致插入异常。

    所以我们将设计修改了一下,把选课关系表SelectCourse改为如下三个表:

    学生:Student(学号,姓名,年龄)

    课程:Course(课程名称,学分)

    选课关系:SelectCourse(学号,课程名称,成绩)

    这样的数据库表是符合第二范式的,消除了数据冗余,更新,插入,删除异常。

    注:所有的单关键字的数据库表都符合第二范式,因为不可能存在组合关键字,也就不可能存在非主属性部分依赖于主关键字了。

     

    第三范式

    定义:如果关系模式R属于2NF,并且R中的非主属性不传递依赖与R的主码,则称关系R是属于第三范式的。(个人总结,非主属性必须直接依赖于主码,不能存在通过其他非主属性传递依赖于主码)

    所谓传递依赖,就是A依赖于B,B依赖于C,则A传递依赖于C。

    因此,满足第三范式的数据库表应该不存在如下依赖关系:

    关键字段->非关键字段x->非关键字段y

    e.g.

    假定学生关系表为Student(学号,姓名,年龄,所在学院,学院地点,学院电话),关键字为单一的学号,所以肯定符合第二范式,但是因为存在非关键字学院地点和学院电话依赖于所在学院,即传递依赖于学号,所以此关系表不符合第三范式。同样会导致数据冗余,DDL操作异常等问题。

    所以我们可以对其进行修改:

    学生:(学号,姓名,年龄,所在学院)

    学院:(学院,地点,电话)

    这样的数据库表就符合第三范式了。

     

    总结:

    a. 规范化目的是使结构更合理,消除存储异常,减少数据冗余,便于插入,删除,更新。

    b. 原则:遵从概念单一化“一事一地”原则,即一个关系模式描述一个实体或实体建的一种联系。

    c. 方法:将关系模式投影,分解成两个或两个以上的关系模式。

    d. 分解后的关系模式集合应当与原关系模式保持等价关系,即通过自然联接可以恢复原关系而不丢失信息,并保持属性间合理的联系。

    注意:一个关系模式结合分解可以得到不同关系模式集合,也就是说分解方法不是唯一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现的。其根本膜表是节省存储空间,避免数据不一致性,提供对关系的操作效率,同事满足应用需求。实际上,并不一定要求全部模式都达到BCNF不可。有时候故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高,查询频率极高的数据库系统更是如此。在关系数据库中,除了函数依赖之外还有多值依赖,联接依赖的问题,从而提出了第四范式,第五范式等更高一级的规范化要求。

     

     

     

     

     

     

     

     

     

     

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

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

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

    展开全文
  • 规范化理论:模式分解

    千次阅读 2019-05-13 22:51:05
    什么是模式分解? 关系模式R<U, F>的一个分解是指:={<...把低一级的关系模式分解为若干个高一级的关系模式,分解方法并不是唯一的,在这些分解方法中,只有能够保证分解后的关系模式与原关...
  • 规范化、标准化、归一化、正则化

    千次阅读 2019-05-21 11:46:41
    规范化关系满足的规范要求分为几级,满足要求最低的是第一范式(1NF),范数的等级越高,满足的约束集条件越严格。 针对数据 数据的规范化包括归一化标准化正则化,是一个统称(也有人把标准化作为统称)。 2....
  • 第1章 多维数据输入时遇到的困境(为什么要标准化、规范化数据集) 1.1 多维输入的困境 在现实生活中,一个目标变量(Yi)可以认为是由多维特征变量(x)影响和控制的。如上图左图中的X1_i,X2_i,X3_i ,其中i = ...
  • 数据库系统原理(4)--数据依赖与关系模式规范化

    万次阅读 多人点赞 2017-03-26 23:11:43
    关系模式设计中的问题关系数据库设计要解决的主要问题 什么样的数据库模式才合理? 怎么分解才能满足要求?...解决方法是通过分解关系来消除其中不合适的数据依赖。数据依赖数据依赖的定义数据依赖是数据之间的
  • 为什么要学习关系数据库规范化理论?(1)基本概念回顾(2)关系模式的形式化定义(3)什么是数据依赖F?(4)数据依赖F对关系模式的影响1️⃣ 数据冗余(Data redundancy)2️⃣ 更新异常(update anomalies )3️⃣ ...
  • 数据库设计之反规范化

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

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

    千次阅读 2017-01-01 22:40:55
    通过需求工程化来降低需求工程的复杂度,让需求分析人员有章可循,与用户形成共同语义环境,也就是需求分析的规范化
  • 一、归一,标准和中心 广义的标准: (1)离差标准(最大最小值标准) (2)标准差标准 (3)归一标准 (4)二值标准 (5)独热编码标准 归一 (Normalization)、标准 ...
  • 近年来,与关系抽取相关的研究势头越来越大,本文讨论了关系抽取的发展过程,并对近年来的关系抽取算法进行了分类。此外,我们还讨论了深度学习、强化学习、主动学习和迁移学习。通过分析监督学习、无监督学习、半...
  • 华为C语言编程规范(精华总结)

    万次阅读 多人点赞 2020-03-24 09:48:55
    在公司已有编码规范的指导下,审慎地编排代码以使代码尽可能清晰,是一项非常重要的技能。 如果重构/ / 修改其他风格的代码时,比较明智的做法是根据 现有 代码 的 现有风格继续编写代码,或者使用格式转换工具进行...
  • 数据库的规范化与非规范化比较

    千次阅读 2014-10-02 18:36:54
    数据库设计的规范化与非规范化: (1)表格与面向对象: 表格包含各个字段,面向对象也是包含多个成员变量。两者有相似之处。 (2)E-R图向关系图转换: 一对一: 一对多: 多对多: (3)规范化与非...
  • 原文地址:数据的规范化,归一化,标准化,正则化作者:打湿井盖  数据的规范化,归一化,标准化,正则化,... 规范化理论把关系应满足的规范要求分为几级,满足最低要求的一级叫做第一范式(1NF),在第一范式的
  • 什么是前端工程

    万次阅读 多人点赞 2019-06-28 11:38:18
    前端越来越复杂,前端面试的要求也越来越高。如何提升前端开发水平?如何应对前端面试?我在日常工作中前端的开发框架以 ...对前端的要求相比几年前已经从单纯的 JavaScript、CSS 问题变成了更多以工程为主的问题。
  • 层次模型、网状模型、关系模型、面向对象数据模型、对象关系数据模型、半结构数据模型 描述数据在系统内部的表示方式和存取方法,或在磁盘或磁带上的存储方式和存取方法,是面向计算机系统的 ...
  • 最常见的标准化方法就是Z标准,也是SPSS中最为常用的标准化方法,spss默认的标准化方法就是z-score标准。 也叫标准差标准,这种方法给予原始数据的均值(mean)和标准差(standard deviation)进行数据的...
  • 构造器 与构造方法关系

    万次阅读 2020-06-28 22:48:42
    java中的构造器有两种:分别是 实例构造器和类构造器<cinit> . 构造器的作用: 构造器的产生过程实际...()方法中无须调用父类的()方法,虚拟机会自动保证父类构造器的执行,但在()方法中经常会生成调用java.lang.
  • 关系数据库设计是对数据进行组织和结构的过程,核心问题是关系模型的设计。关系模型是数学的、用二维表格数据描述各实体之间的联系的模型;它是所有的关系模式、属性名和关键字的汇集,是关系模式描述的对象。...
  • 数据模型是指数据库的组织形式,它决定了数据库中数据之间联系的表达方式,即把在计算机中表示...1、传统数据模型(层次模型、网状模型、关系模型) 2、面向对象模型 3、时态GIS模型 4、三维数据模型 二、传统数据模...
  • idea 查看类继承关系的快捷键

    千次阅读 2021-01-12 18:28:49
    类似eclipse ctrl+t的快捷键,idea中是ctrl+H…找到对应的类 查看类关系图…1.在想要查看的类上按 Ctrl + H -> Diagrams -> Show Diagrams -> Java Class Diagrams -> Show Implementations -> Ctrl +...
  • 关系数据库系列文章之到底什么是关系(一)

    千次阅读 多人点赞 2018-08-05 02:28:45
    在语言X中如何实现Y,像这种具体的只是(know-how)可快速提高你的工作效率。但是一旦语言发生变化,这种知识就无法再使用。... 作为程序员,在日常的开发中,我们避免不了的就要接触数据库这个概念,而关系...
  • 数据库实体联系模型与关系模型

    千次阅读 2020-03-02 19:11:33
    数据库设计是指根据用户的需求,在某一具体...这就需要规划课程、学生、老师、学习资料等数据构成以及相互之间的关系。因此,规划数据构成及数据间关系,并应用某一具体的数据库管理系统如MySQL构建数据库的过程就是...
  • Kubernetes和Docker的关系是什么?

    万次阅读 多人点赞 2020-08-20 20:00:00
    而这些编排对象正是Kubernetes定义容器间关系和形态的主要方法。 关于这些具体编排对象的介绍及应用场景,后面我将在本公众号的《Devops技术专栏》中陆续给大家介绍到,感兴趣的朋友可以点赞+关注! —————END...
  • 【数据库】函数依赖和规范化

    千次阅读 2016-11-01 16:51:22
     在数据库中,关系模式中的属性值之间会发生联系。譬如每个学生只有一个姓名,每门课程只能有一个任课老师。这类联系就称为函数依赖(functional dependency,简记为FD)。 X→Y,读作X函数决定Y,即知道了X的值就...
  • 缺失值的产生的原因多种多样,主要分为机械原因和人为原因。机械原因是由于机械原因导致的数据收集或保存的失败造成的数据缺失,比如数据存储的失败,存储器损坏,机械故障导致某段时间数据未能收集(对于定时数据...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 295,150
精华内容 118,060
热门标签
关键字:

关系规范化的主要方法是