精华内容
下载资源
问答
  • 关系数据库设计:谈谈规范化技术

    千次阅读 多人点赞 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-03-16 22:53:23
    关系数据库规范化理论

    本文来源于:http://blog.sina.com.cn/s/blog_4d73b3a7010008st.html

    关系型数据库在设计时应该遵守一定的规则,即遵循数据库的范式理论。数据库的数据是一切操作的基础,如果数据库设计不好,利用其它方法来提高数据库性能的效果都将是有限的。而设计的关键是如何使数据库能合理地存储用户的数据,方便用户进行数据处理。
    规范化理论是将一个不合理的关系模式如何转化为合理的关系模式理论,规范化理论是围绕范式而建立的。规范化理论认为,一个关系型数据库中所有的关系,都应满足一定的规范。规范化理论把关系应满足的规范要求分为几级,满足最低要求的一级叫做第一范式(1NF),在第一范式的基础上提出了第二范式(2NF),在第二范式的基础上又提出了第三范式(3NF),以后又提出了BCNF范式,4NF,5NF。范式的等级越高,应满足的约束条件也越严格。规范的每一级别都依赖于它的前一级别,例如若一个关系模式满足2NF,则一定满足1NF。
    下面我按照范式设计级别依次介绍1NF(第一范式)、2NF(第二范式)、3NF(第三范式)和BCNF,4NF(第四范式)和5NF(第五范式)。
    第一范式(1NF):在数据库表中,要求每个属性值都是不可再分的,则该关系满足第一范式。
    如:某关系表SC由 STUDENT_ID(学生编号)和COURSE(课程名称)两个属性组成。这样的关系模式在实际应用过程中会存在这样问题,一个学生可以同时选择多门课程,现将此关系中STUDENT_ID作为关键字,COURSE字段中存在了多个值的情况,象这样:


    STUDENT_ID

    COURSE

    001

    中国文化史概要、音乐欣赏

    002

    音乐欣赏、程序设计

    这样的关系即不满足第一范式的要求。实际应用中,在设计表时,都应该满足第一范式要求。


    STUDENT_ID

    COURSE

    001

    中国文化史概要

    001

    音乐欣赏

    002

    音乐欣赏

    002

    程序设计

    解决方法:

     

     

     




    第二范式(2NF):如果某关系满足第一范式,而且它的所有非关键字属性都完全依赖于整个主关键字(不存在部分依赖),则该关系满足第二范式。
    如:关系LESSON(课程表):由SNO,CNO,GRADE,CREDIT四个属性组成,其中SNO为学号、CNO为课程号、GRADEGE为学生成绩、CREDIT为学分。根据这个关系,关键字为组合关键字(SNO、CNO)。
    在应用中使用这个关系模式可能存在以下问题:
    a.更新异常。若调整了某课程的学分,相应的元组CREDIT值都要更新,有可能会出现同一
    门课学分不同的情况。
    c.插入异常。如计划开新课,由于没人选修,没有学号关键字,只能等有人选修才能把课程
    和学分存入。
    d.删除异常。若学生已经结业,从当前数据库删除选修记录。某些门课程新生尚未选修,则
    此门课程及学分记录无法保存。
    分析原因:非关键字属性CREDIT仅依赖于CNO这个字段,也就是CREDIT部分依赖组合关键字(SNO,CNO)而不是完全依赖。
    解决方法:将其实原有关系分成两个关系STUDENT(SNO、CNO、GRADE),LESSON(CNO、CREDIT)。这样的两个关系都满足第二范式的要求。

    第三范式(3NF):如果某关系模式满足第二范式,而且它的任何一个非主属性都不传递依赖于任何关键字,则满足第三范式。
    例:关系S1(SNO、SNAME、DNO、DNAME、LOCATION) ,属性依次代表学号、姓名、所在系编号、系名称、系地址。 关键字SNO决定各个属性,满足2NF。但这样的关系肯定会使数据有大量的冗余,有关学生DNO,DNAME,LOCATION三个属性将重复插入、删除和修改。
    分析原因:关系中存在传递依赖造成的。即SNO决定DNO,DNO决定LOCATION,但SNO不能直接决定LOCATION, 而是通过DNO传递依赖实现的,所以不满足第三范式。
    解决方法:将其分为两个关系 S(SNO,SNAME,DNO),D(DNO,DNAME,LOCATION)。

    BCNF:如果关系R的所有属性中,若每个决定因素都包含候选关键字,则称关系R属于BCNF。
    例:关系SLT(SID、LESSON、TEACHER),SID为学生编号、LESSON为课程名称、TEACHER为授课教师,其中SID为关键字,经分析该关系满足第三范式,分析(SID、LESSON)决定授课教师,(SID、TEACHER)决定课程,TEACHER决定LESSON,由于TEACHER不是关键字,所以不满足BCNF。
    解决方法:;C(SID、TEACHER),T(TEACHER、LESSON)。

    第四范式(4NF):若关系模式R每个非平凡多值依赖X→→Y,X都含有候选键,则该关系模式满足第四范式。
    如:关系RR(SBM、CZDM、SCCJ),其中SBM设备名称、CZDM厂站代码、SCCJ生产厂家。
    分析:对于设备名称,无论生产厂家是谁,都会有一组值对应厂站代码即SBM→→CZDM,同理对设备名称,无论厂站代码是谁,都会有一组值对应生产厂家即SBM→→SCCJ。由于两个多值依赖的左端都不含候选键,所以不满足第四范式。
    解决方法:RR_1(SBM、SCCJ),RR_2(SBM、CZDM)。

    第五范式(5NF):如果关系模式中,每一个连接依赖,都包含由关系中候选键,则称为该关系模式满足第五范式。
    例如有一个关系R1中


    A

    B

    C

    A1

    B1

    C1

    A2

    B1

    C2

    A1

    B2

    C1

    A2

    B2

    C2

    分析:在关系中A、B、C均为关键字。从上表中可以看出,表中存在大量冗余的数据。
    解决方法:可以将其拆分成下面的三个关系RA、RB、RC。

    RA

    RB

    RC

    A

    B

    B

    C

    C

    A

    A1

    B1

    B1

    C1

    C1

    A1

    A1

    B2

    B1

    C2

    C1

    A2

    满足第五个范式。
    将一个关系分解成多个关系,要使得分解有意义,起码的要求是分解后不丢失原来的信息。这些信息不仅包括数据本身,而且包括由函数依赖所表示的数据之间的相互制约。进行分解的目标是达到更高一级的规范化程度,但是分解的同时必须考虑两个问题:无损联接性和保持函数依赖。有时往往不可能做到既有无损联接性,又完全保持函数依赖。需要根据需要进行权衡。

    小结:
    规范化目的是使结构更合理,消除插入、修改、删除异常,使数据冗余尽量小,便于插入、删除和更新。
    原则:遵从概念单一化 “一事一地”原则,即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。
    方法:将关系模式投影分解成两个或两个以上的关系模式。
    要求:分解后的关系模式集合应当与原关系模式“等价”,即经过自然联接可以恢复原关系而不丢失信息,并保持属性间合理的联系。
    注意:一个关系模式结这分解可以得到不同关系模式集合,也就是说分解方法不是唯一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现。其根本目标是节省存储空间,避免数据不一致性,提高对关系的操作效率,同时满足应用需求。实际上,并不一定要求全部模式都达到BCNF不可。有时故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高,查询频度极高的数据库系统更是如此。
    现在做数据库设计,很少有人可以做到很符合范式的。一般说来,第一范式大家都可以遵守,如果设计的数据库能遵守前三个范式,就可以啦,因为范式越高,可能也会BCNF的范式出现机会较少,而且会破坏完整性,你可以在做设计之时不考虑它。希望大家在设计数据库时,一定要全面考虑各方面的问题,根据实际情况出发,然后再确定是否应该满足更高范式。


    展开全文
  • 规范化会使实现变得更加复杂 逆规范化通常会降低灵活性 逆规范化会加快检索的速度,但却会降低更新的速度。(对数据库不需要经常更新,频繁检索的应用更合适!) 合并一对一联系 如果两个关系之间的联系是一对一,...

    目的:提升性能
    去规范化会使实现变得更加复杂
    逆规范化通常会降低灵活性
    逆规范化会加快检索的速度,但却会降低更新的速度。(对数据库不需要经常更新,频繁检索的应用更合适!)

    合并一对一联系

    如果两个关系之间的联系是一对一,并且经常被一起访问,很少单独访问其中的一个关系,那就应该考虑合并

    在一对多联系中复制非关键字属性以减少连接操作

    将父关系的一个或者多个非关键字属性复制到一对多联系的子关系,以减少连接操作
    在这里插入图片描述
    因复制而产生的一个相关问题是每当一个元组被插入、修改或者删除时,会带来维持数据一致性的额外开销
    因复制所带来的存储开销问题:目前二级存储器的价格很便宜,已不是一个很重要的问题,但这并不意味着可以随意复制

    使用查看表(lookup table)
    在这里插入图片描述
    为房产类型定义一个查看表PropertyType(父关系),并将表PropertyForRent (子关系)修改为右边形式

    使用查看表的好处

    • 减小子关系的大小:代码类型type属性只占1 个字节,而类型描述description属性需要5 个字节
    • 如果描述可能被修改(在本例子中不会),则只需要在查看表中修改一次,而不需要在子关系中修改多次
    • 查看表可以用来检查用户输入的有效性

    如果将查看表用于频繁执行的查询或者关键查询中,并且描述属性一般不会被修改,则可以考虑将查看表的描述属性复制到子关系中。

    在一对多联系中复制外键属性以减少连接操作

    在多对多联系中复制属性以减少连接操作

    每个多对多联系映射为了三个关系:由两个原始实体导出两个关系,另一个新关系则表示两个实体之间的联系。
    如果希望从多对多联系中提取信息,就不得不将这三个关系连接起来。
    某些情况下,将原实体中的属性复制到那个中间关系中,就可能减少参加连接操作的关系的个数。

    引入重复组(减少因为多值属性所产生的连接)

    一般来说,在下面的情况下可以考虑这种逆规范化:

    • 重复组中项的绝对数目是已知的(本例中最多有三个电话号码)
    • 该数目是静态的,不会随着时间的改变而改变(最多的电话号码个数是固定的,且不希望被改变) 。
    • 该数目不是很大,一般不会超过10(与前两个条件比起来,这个条件并不十分重要)

    创建抽取表

    • 有些时候可能需要在白天的峰值时刻运行报表程序。
      • 报表程序可能会访问某些导出数据,要在同一组基础关系上运行涉及了多个关系的连接操作
      • 报表所需要的数据可能是相对静止的,或者在某些情况下可以不必是当前的
    • 比如说几个小时之前或者前一天的数据都不影响
      • 可以基于报表所需的关系表,创建一个独立的、高度去规范化的抽取表
      • 用户可以直接访问抽取表,而不必访问基础关系

    常用的创建抽取表的方法是:在系统负载较轻时批量创建并装载这些表

    对关系进行分区(Partition)

    分区的好处

    • 改善负载平衡:各个分区可以被分配到二级存储器的不同区域,从而允许数据的并行访问。假设关系 没有被分区,则数据都存储在同一片区域,此时并行访问这片区域的数据的操作之间存在着竞争,关系的分区可将这种竞争最小化。
    • 提高性能:通过限制要访问和处理的数据量以及通过并行处理来提高系统性能。
    • 提高可用性:由于不同的分区存储在不同的区域,因此当一个存储区域不可用时,其他分区仍然可用
    • 提高可恢复性:小的分区可以更高效地恢复(DBA会发现备份小的分区比备份超大的关系更容易些) 。
    • 安全:对于分区中的数据,可以只允许需要访问它们的用户访问,不同的分区可以有不同的访问限制。

    分区的坏处

    • 复杂:分区对于终端用户和查询并不总是透明的,执行写操作时,使用多于一个分区会更加复杂。
    • 降低性能:查询时,合并多个分区中的数据要比从没被分区的关系中获取数据慢。
    • 复制的影响:垂直分区要复制主关键字,这不仅会增加存储空间的大小,而且会增加潜在的不一致性。

    去规范化设计的影响

    需要重新考虑被去规范化的关系上索引的选择

    • 是否去掉某些现存的索引
    • 是否需要增加新的索引

    需要考虑如何维护数据的完整性,常用的解决方法有:

    • 使用触发器,自动更新导出和复制的数据。
    • 在应用中使用事务,将被去规范化的数据的更新作为一个单一(原子)操作处理。
    • 完整性批处理:在适当的时候运行批处理程序维护去规范化数据的一致性

    去规范化优缺点

    展开全文
  • 第 7 章 关系规范化理论 一单项选择题 1关系规范化中的删除操作异常是指 插入操作异常是指 A 不该删除的数据被删除 B 不该插入的数据被插入 C 应该删除的数据未被删除 D 应该插入的数据未被插入 答案 A D 2设计性能...
  • 关系模式规范化(上)

    千次阅读 2013-03-19 13:45:11
    最近在学习数据库过程中,...选择,除法,元组关系演算等等,没有介绍如何合理设计一个数据库,可是如果作为一个数据库designer,必须了解如何设计与简化数据库,这都是数据模式规范化的内容。 如果不考虑数据库规范化

    最近在学习数据库过程中,发现几本教材大都是按照数据库系统概论->关系数据库基础->SQL语言->关系数据库理论(大都是介绍规范化)介绍,第二部分的关系数据库基础主要谈到了基本算术运算关系和域运算,比如交并差,投影,选择,除法,元组关系演算等等,没有介绍如何合理设计一个数据库,可是如果作为一个数据库designer,必须了解如何设计与简化数据库,这都是数据模式规范化的内容。

    如果不考虑数据库规范化,那么我们经常遇到的各种关系二维表,大都是易于理解与查阅,但是效率不高,主要体现在:

    1.数据冗余度高,比如一个关系R(学号,学生姓名,课程,教室)中,假若一个学生选修N个课程,那么该学生的学号、姓名就要被重复记录N次,显然冗余度过大,浪费存储空间(但是便于我们直观的理解)。

    2.数据修改复杂,再如上例中,假如需要修改学号,一个学生又修了N门课,那么需要修改N次姓名,效率何在?准确性谁能保证?

    3.数据插入,删除异常,比如上例中,我暂时不知道某学生的学号,但是其他信息都知道,但我还是没法插入进去,如果删除的话,假如所有学生中只有一位学生选修了张三老师的课,那么现在需要删除该学生所在元祖的话,张三也会被删掉,这样一来,张三就从关系R中彻底消失了!

    于是,这种低效率的关系表需要简化,需要拆分,需要规范化!

    在规范化之前,需要阐明一些基本概念,因为规范化定义中会用到这些概念,这些基本概念名词定义听起来都文绉绉的,不过其实含义都很简单很明确,下面是一些基本概念:

    1.函数依赖

    对于关系R(U),X,Y是U的子集,若对于一个具体关系r,r中有任意两个元组s,t,且s(X)=t(X)能导致s(Y)=t(Y),则称X决定Y,Y依赖于X,记为X->Y。

    含义就是:如果对于r中属性X中的每一个具体值,都有唯一的具体指Y与其对应,那么称Y依赖于X。类似于函数中的单值映射关系,反映了表中属性之间的决定关系。

    2.完全函数依赖,部分函数依赖

    若关系R(U)中,X->Y,且对于X的任意一个真子集X‘,X’不能->Y,那么说明Y完全依赖于X,否则,称为Y部分依赖于X。

    3.函数依赖集

    表中函数依赖的集合称为函数依赖集。

    4.候选码形式定义

    若在关系R(U,F)中,X是属性或属性集,U完全依赖于X,则X为R的候选码,简称码。

    这是形式化的定义,定义暗指:候选码具有唯一确定性,能够唯一决定表中任一行,其次,候选码是具有最小性的,因为定义中强调了U完全依赖于候选码X,也就是X的子集是不能决定每一行的,那么便会得到以下结论:若X和Y都是候选码(或者两者有一个是),那么不能说(X,Y)是候选码,因为(X,Y)的真子集X或Y可以决定U,此时U不是完全依赖于(X,Y)。

    下面先讨论第一、第二、第三范式。

    第一范式(1NF):

    如果关系R中的属性值都是不可再分的最小数据单位,则称为第一范式,记为R∈1NF。

    根据定义,我们分别从横向和纵向去看,发现第一范式具有两个特点:

    ①不存在重复组,也就是每行的元祖不能又“内含”多个“小组”。

    ②不存在组合属性,也就是每个属性是单一的,明确的,不能属性里面又包含“小属性”。

    1NF是很常见的,也是很容易设计的,只要保证每行每列都是单一的,不重复的即可。

    第二范式(2NF):

    若R中每个非属性组都完全依赖于R的任一候选码,且R∈1NF,则称为第二范式,R∈2NF。

    根据定义,若判断某关系R是否为2NF,首先看是否存在非主属性对候选码的部分函数依赖,一旦存在,则不是2NF。那么如果不是2NF,应该如何分解使其满足2NF呢?

    可以利用投影运算将其分解成三个关系(设候选码为XY),第一个是只依赖于X的子模式,第二个是只依赖于Y的子模式,第三个是完全函数依赖于XY的子模式。

    由于2NF仅仅是消除了非主属性对候选码的部分函数依赖,还是存在一些问题的。

    ①数据冗余②修改复杂③插入删除异常。

    之所以存在这些问题,因为2NF没有消除非主属性对候选码的传递函数依赖!因此需要继续分解……这就引入了下面的第三范式。

    第三范式(3NF):

    若关系R的任何一个非主属性都不传递函数依赖于任一候选码,则R∈3NF。

    上述定义只是说明3NF中不存在非主属性间的函数依赖,但是不代表主属性间不存在函数依赖,也就是3NF中主属性间可能存在函数依赖。

    还有一个性质,那就是3NF必然是2NF。

    要判别一个关系R是否为3NF,那么可以进行一下步骤:

    ①找出候选码和非主属性

    ②看看是否存在非主属性对候选码的部分函数依赖,若存在,说明不是2NF,也就不会是3NF,否则进行下一步。

    ③判断非主属性间是否存在函数依赖,若不存在,则是3NF。

    这么看来,经过上述2NF和3NF规范化后,似乎已经很“彻底”了,不过我们发现第二和第三范式只是将非主属性对候选码部分函数依赖和传递函数依赖消除了,还未消除主属性本身对候选码的部分函数依赖或者传递函数依赖,所以后来就有人提出了3NF的改进形式:BCNF。

    ……未完待续……

    展开全文
  • 关系型数据库规范化的通俗理解

    千次阅读 2019-05-26 11:17:35
    最近参加数据库系统工程师的考试,结合自己的工程经验,终于对数据库规范化理论有了一知半解。 本文试图从工程化的角度,用大白话去解释数据库规范化的结论,如果有不严谨之处,敬请指正。我不会去详细介绍每个范式...
  • SQL 规范化

    千次阅读 2019-01-09 18:22:02
    规范化关系数据库的概念是同时出现的。两者都来源于E.F.Codd(IBM)在1969年发表的著作。Codd提出这样的概念:数据库是由一系列无序的表组成的,可以对这些表进行非过程操作来返回表。 规范化实际上只是大型数据库...
  • 关系数据库设计规范化流程

    千次阅读 2011-09-15 14:59:42
    规范化:确保数据正确地分布到数据库的表中,防止操作异常及大量冗余信息的存储。数据冗余不仅占用物理空间,对数据的维护和一致性检查也带来了问题。   范式及举例:   第一范式:【数据库表中
  • 一、范式 关系模式满足的确定约束条件称为范式,根据满足约束条件的级别不同, 范式由低到高分为1NF,2NF,3NF,BCNF,4NF,5NF等。 
  • 数据库规范化过程

    千次阅读 2019-08-25 13:41:37
    关系数据库的规范化说的通俗一些就是对表的规范化规范化的必要性: 根据项目的需求,我们会创建相应的数据库表格来完成项目中的数据的存储。这已经成为做项目的固定流程了,但是在真正的开始处理业务需求的时候,...
  • 什么是数据库规范化 维基百科的定义如下: 数据库规范化,又称数据库或资料库的正规化、标准化,是数据库设计中的一系列原理和技术,以减少数据库中数据冗余,增进数据的一致性。 数据库范式是埃德加·科德设计...
  • 数据规范化(标准化)

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

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

    千次阅读 2017-01-01 22:40:55
    通过需求工程化来降低需求工程的复杂度,让需求分析人员有章可循,与用户形成共同语义环境,也就是需求分析的规范化
  • 数据规范化标准化 Normalizer 规范化、StandardScaler、 MinMaxScaler、 MaxAbsScaler label 与feature的重新编号(码)。 VectorIndexer、 StringIndexer、 IndexToString 、oneHotEncoder、bucketizer分箱,...
  • 系统设计规范化解决了什么问题

    千次阅读 2014-10-20 09:01:18
    系统设计规范化解决了什么问题(一) 大家好,今天总结下我从事开发工作这几年里,对于项目规范化的一点想法和感触. 在笔者心里,规范是为了解决问题而存在的,某些规范都是为了对应问题而存在的.所以只要是能解决问题的...
  • 数据库设计中反规范化技术的应用

    千次阅读 2011-11-14 09:26:37
    【摘 要】数据库的规范化理论不仅仅是关系模式设计的理论指导和强有力的工具,对其它数据模型数据库的逻辑设计也 同样有理论意义,数据的规范化不仅会带来空间上的效率,而且还有助于保证数据的正确性和一致性。它...
  • 一、归一,标准和中心 广义的标准: (1)离差标准(最大最小值标准) (2)标准差标准 (3)归一标准 (4)二值标准 (5)独热编码标准 归一 (Normalization)、标准 ...
  • 数据库---规范化理论、范式、模式分解

    千次阅读 多人点赞 2017-09-19 18:38:46
    关系化关系模式可能存在的问题 数据冗余、更新异常(数据不一致)、插入异常、删除异常 关系化关系的用途 解决非关系化模式存在的问题 键相关的概念超键: 唯一标识元组,可能存在冗余属性 候选键: 唯一标识...
  • 关系数据理论

    千次阅读 2019-09-03 23:03:47
    一、关系规范化理论背景 二、规范化理论
  • 规范化。。。呃,这个东西看你要有多规范了,给你个cmmi定义的5个层次做参考吧。1. 手工作坊式,即产品质量全靠开发人员的个人英雄主义做法,无法保证开发新产品能有同样的质量。2. 已经有了一些流程,进行一定的...
  • 数据库规范化三个范式应用实例

    千次阅读 2004-10-14 22:16:00
    规范化为什么重要?目前很多的数据库由于种种原因还没有被规范化。本文中解释了其中一些原因,并用不同形式的范式(normal form)规范化了一个保险公司的理赔表。在这个过程中表的改变以及添加的一些附加表使数据库...
  • 数据库规范化理论---模式分解

    千次阅读 2018-01-21 19:03:48
    这里主要讨论基础考试选择题,判断一个分解是有损无损、是否保持函数依赖。 一、公式法 无损分解⇔R1∩R2→(R1-R2)或R1∩R2→(R2-R1) 保持函数依赖⇔(F1∪F2)+=F+ 说明:这里的判断无损的→以及判断保持...
  • 这一篇是阐述如何选择可视图表的最后一部分,主要是以下几类数据的可视: 区间型数据:区间型数据一般是用来显示数据当前的进度情况,数据格式一般为数值或者百分比; 关系型数据:数据之间有包含关系、层级...
  • 数据库原理复习题(五)——规范化设计 1.在关系模式R(A,B,C)中,有函数依赖集F={(A,B)→C,(B,C)→A},则R最高达到(;;;;)。 (7分) A. BCNF   B. 3NF   C. 1NF   D. 2NF   正确答案:A. 你...
  • 数据库规范化理论---求候选键

    千次阅读 多人点赞 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. 已经有了一些流程,进行一定的...
  •  西安楚凡科技有限公司(Trufun)是全球领先的软件开发行业应用生命周期管理(ALM)和CASE工具解决方案提供商,倡导"实用、简洁"的产品理念,为企业实现产品开发与服务支持间的规范化应用平台,在管理软件研发全...
  • 码(Key):关系中的一个属性集合,其属性值可以唯一标识关系中的每个元组。 候选码(Candidate key):若一个码的任意一个真子集都不为码时,称其为候选码。 或者换一个定义:设K为R(U)中的属性或属性组,若K完全函数...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 253,491
精华内容 101,396
关键字:

关系可以选择是否进行规范化