数据库原理与设计第六章知识点总结

数据库原理与设计


写在前面:最近数据库学到第六章了,本篇文章就把其中的知识点整理总结了一下,方便复习。若有纰漏还请多多谅解。

第6章 关系数据库设计理论

6.1 关系模式中可能存在的异常

关系模式中可能存在的4个问题(4个异常):

  1. 插入异常(insert anomaly)

    (1)元组插不进去;

    (2)插入一个元组,却要求插入多个元组。

  2. 删除异常(delete anomaly)

    (1)删除时,删掉了其他信息;

    (2)删除一个元组却删除了多个元组。

  3. 冗余(redundancy)

    冗余的表现是,某种信息在关系中存储多次。

  4. 更新异常(update anomaly)

    更新异常的表现是,修改一个元组,却要求修改多个元组。

    注:有时将冗余和更新异常合二为一,称为“冗余及更新异常”,因为如果存在冗余肯定会存在更新异常。

6.2 关系模式中存在异常的原因

​ 数据的语义不但在完整性方面有体现,在关系模式的设计方面也有体现。

​ 具体表现:在关系模式中的属性间存在一定的依赖关系,此即数据依赖。

数据依赖(Data Dependency):指通过一个关系中属性间值的相等与否体现出来的数据间的相互关系。

​ 数据依赖分类函数依赖(Functional Dependency, FD)、多值依赖(Multivalued Dependency,MVD)和连接依赖(Join Dependency,JD)。

​ 数据依赖决定因素:由现实系统中属性间相互联系的语义决定。

​ 异常现象产生的根源:关系模式中属性间存在的这些依赖关系。

​ 根源的体现及解决:如果将各种数据集中于一个关系模式中,各对象主键云集,极可能无法全部满足各主键约束等,从而造成异常。

​ 解决异常方法:利用规范化理论,对关系模式进行相应的分解,以消除这些异常。

6.3 函数依赖

6.3.1 函数依赖的定义

​ 为方便定义的描述,先给出如下约定

约定:设R是一关系模式,U是R的属性集合,X、Y ⊆ \subseteq U,r是R的一个关系实例,元组t ∈ \in R。则用t[X]表示元组t在属性集合X上的值。同时,将关系模式和关系实例统称为关系,XY表示X和Y的并集(实际上是X ∪ \cup Y的简写)。

​ 函数式决定:y=f(x),说明x→y。

​ 函数依赖定义:设R是一个关系模式,U是R的属性集合,X和Y是U的子集。对于R的任意实例r,r中任意两个元组t1和t2,如果t1[X] = t2[X] 则t1[Y] = t2[Y],那么称X函数地决定Y,或Y函数地依赖于X,记作:X→Y,X称为决定子(Determinant)或决定属性集

​ 函数依赖关心的问题:是一个或一组属性的值决定其他属性的值。

6.3.2 函数依赖分类及其定义

函数依赖类型:

  1. 平凡函数依赖(Trivial FD)
  2. 非平凡函数依赖(NonTrivial FD)
  3. 完全函数依赖(Full FD)
  4. 部分函数依赖(Partial FD)
  5. 传递函数依赖(Transitive FD)

​ 平凡函数依赖:如果Y ⊆ \subseteq X,则X→Y称为平凡函数依赖。平凡函数依赖不反映新的语义。

​ 非平凡函数依赖:如果X→Y,且Y不是X的子集,则称X→Y是非平凡函数依赖。如不特别声明,一般总是讨论非平凡函数依赖。

​ 决定属性集/决定子:如果X→Y,则称X为该函数依赖的决定属性集。

​ XY等价:如X→Y,且Y→X,则X与Y一一对应,记作X ↔ \leftrightarrow Y

​ 完全函数依赖:设R是一个具有属性集合U的关系模式,如果X→Y,并且对于X的任何一个真子集Z,Z→Y都不成立,则称Y完全函数依赖于X,记作: X ⟶ f Y \mathrm{X} \stackrel{f}{\longrightarrow} \mathrm{Y} XfY

X=(a, b), Y=(c),如果a ↛ \nrightarrow c,b ↛ \nrightarrow c,但(a, b)→c,则 X ⟶ f Y \mathrm{X} \stackrel{f}{\longrightarrow} \mathrm{Y} XfY

​ 部分函数依赖:若X→Y,但Y不完全函数依赖于X,则称Y部分函数依赖于X,记作: X ⟶ p Y \mathrm{X} \stackrel{p}{\longrightarrow} \mathrm{Y} XpY

X=(a, b), Y=(c),如果a→c 或 b→c,则 X ⟶ p Y \mathrm{X} \stackrel{p}{\longrightarrow} \mathrm{Y} XpY

:如果X为单个属性,则X→Y是完全函数依赖还是部分函数依赖?

:如果决定子只有一个属性,则与其有关的函数依赖是完全函数依赖

​ 传递函数依赖:设R是一个具有属性集合U的关系模式,X、Y、 Z ⊆ \subseteq U,X、Y、Z是不同的属性集。如果X→Y, Y→X不成立, Y→Z,则称Z传递地函数依赖于X。

X→Y,Y ↛ \nrightarrow X,Y→Z,则X→Z。

:X→Y,Y ↛ \nrightarrow X,Y→Z,但Z→Y,那么X→Z

:正确。

6.3.3 函数依赖与属性关系

设R(U)是属性集U上的关系模式,X,Y是U的子集:

  • 如果X和Y之间是1:1关系(一对一关系)则存在函数依赖X→Y和Y→X ,如学号和身份证号之间就是1:1关系,学号->身份证号,身份证号->学号。
  • 如果X和Y之间是m:1关系(多对一关系),则存在函数依赖X→Y ,如学号和班级号之间就是m:1关系,学号->班级号。
  • 如果X和Y之间是m:n关系(多对多关系),如学号和课程号之间就是m:n关系,则X 和Y之间不存在函数依赖。
6.3.4 Armstrong公理系统

问题提出:在关系模式的规范化处理过程中,不仅要知道一个给定的函数依赖集合,还要知道由给定的函数依赖集合所蕴涵(或推导出)的所有函数依赖的集合。为此,需要一个有效而完备的公理系统,Armstrong公理系统即是这样的一个系统。

蕴含定义:设F是R上的函数依赖集合, X→Y是R的一个函数依赖 。如果R的一个关系实例满足F,则必然满足X→Y,则称F逻辑蕴含(Imply) X→Y。

闭包定义:函数依赖集合F所逻辑蕴含的函数依赖的全体,称为F的闭包(Closure), 记为F+

Armstrong公理:为从已知的函数依赖推导出其他的函数依赖,Armstrong提出了一套推理规则,称为Armstrong公理(Armstrong’s Axioms)。

公理包含如下三条推理规则:

  1. 自反律(Reflexivity):若Y ⊆ \subseteq X ⊆ \subseteq U,则X→Y。

  2. 增广律(Augmentation):若X→Y,Z ⊆ \subseteq U,则XZ→YZ。

  3. 传递律(Transitivity) :若X→Y和Y→Z,则X→Z。

引理 1:Armstrong公理是正确的,即:如F成立,则由F根据Armstrong公理所推导的函数依赖总是成立的。

引理 2:如下三条推理规则是正确的:

  1. 合并规则(Union):如果X→Y,X→Z,则X→YZ。
  2. 伪传递规则(Pseudo Transitivity):如果X→Y,YW→Z,则XW→Z。
  3. 分解规则(Decomposition):如果X→Y和Z ⊆ \subseteq Y,则X→Z。或:如X→YZ,则X→Y,X→Z。

6.4 关系模式的规范形式

6.4.1 范式

范式(Normal Form, NF):关系模式的规范形式。

关系模式中的范式:1NF、2NF、3NF、BCNF、4NF和5NF。

范式之间存在的关系或级别

1NF ⊃ \supset 2NF ⊃ \supset 3NF ⊃ \supset BCNF ⊃ \supset 4NF ⊃ \supset 5NF

函数依赖范畴 多值依赖范畴 连接依赖范畴

说明:

  1. 1NF级别最低,5NF级别最高。
  2. 高级别范式可以看成是低级别范式的特例。
  3. 一般来说,1NF是关系模式必须满足的最低要求。

范式级别与异常问题之关系:一般,级别越低,出现异常的程度越高。

6.4.2 规范化

规范化:将一个给定的关系模式转化为某种范式的过程称为关系模式的规范化过程,简称规范化(Normalization)。

规范化方法:一般采用分解的办法,将低级别范式向高级别范式转化,使关系的语义单纯化。

规范化目的:逐渐消除异常。

理想的规范化程度:范式级别越高则规范化程度也越高。

实际的规范化操作

  1. 1NF和2NF一般作为规范化过程的过渡范式。
  2. 规范程度不一定越高就越好。
  3. 设计中一般达到3NF或BCNF即可。
6.4.3 函数依赖范畴的范式
  1. 第一范式(1NF)

    定义:设R是一个关系模式。如果R的每个属性的值域都是不可分的简单数据项的集合,则称该关系模式为第一范式关系模式,记作1NF。

    第一范式仅仅满足了关系属性的原子性,即不允许复合属性的出现。但仍可能出现插入、删除、冗余及更新异常。

  2. 第二范式(2NF)

    定义:若关系模式R是1NF,而且每一个非键属性都完全函数依赖于R的键,则称该关系模式为第二范式关系模式,记作2NF。

    2NF实质:不存在非键属性“部分函数依赖”于键的情况。

    非2NF关系或1NF关系向2NF的转换:消除其中的部分函数依赖,一般是将一个关系模式分解成多个2NF的关系模式。即:将部分函数依赖于键的非键属性及其决定属性移出,另成一关系,使其满足2NF。

    2NF关系可能的异常:仍可能存在插入异常、删除异常、更新异常和冗余。因为,还可能存在“传递函数依赖”。

  3. 第三范式(3NF)

    定义:若关系模式R是2NF,而且它的任何一个“非键属性”都不传递依赖于R的任何候选键,则称该关系模式为第三范式关系模式,记作3NF。

    相对于第二范式,第三范式即为其消除了传递函数依赖后所得到的关系模式。

    3NF关系可能的异常:仍可能存在插入异常、删除异常、更新异常和冗余。因为,还可能存在“主属性”“部分函数依赖”于键。(仅仅保证了非主属性)

  4. BC范式(BCNF)

    BC范式又称增强第三范式,由Boyce和Codd提出而得名,有时也归入第三范式。

    定义:若关系模式R是1NF,如果 对于R的每个函数依赖X→Y, X必为候选键,则R为BCNF范式。

    性质

    1. 所有非键属性都完全函数依赖于每个候选键;
    2. 所有键属性都完全函数依赖于每个不包含它的候选键;
    3. 没有任何属性完全函数依赖于非键的任何一组属性。

    BCNF与3NF的关系

    • 如果关系模式R ∈ \in BCNF,则必定有R ∈ \in 3NF;
    • 如果R ∈ \in 3NF,且R只有一个候选码,则必定有R ∈ \in BCNF。

    性质

    1. 所有非键属性都完全函数依赖于每个候选键;
    2. 所有键属性都完全函数依赖于每个不包含它的候选键;
    3. 没有任何属性完全函数依赖于非键的任何一组属性。

    BCNF与3NF的关系

    • 如果关系模式R ∈ \in BCNF,则必定有R ∈ \in 3NF;
    • 如果R ∈ \in 3NF,且R只有一个候选码,则必定有R ∈ \in BCNF。
  • 3
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 3
    评论
数据库范式(范式,数据库设计范式,数据库设计范式)是符合某一种级别的关系模式 的集合。构造数据库必须遵循一定的规则。在关系数据库中,这种规则就是范式。关系 数据库中的关系必须满足一定的要求,即满足不同的范式。目前关系数据库有六种范式 :第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、第四范式(4NF)、第五范 式(5NF)和第六范式(6NF)。满足最低要求的范式是第一范式(1NF)。在第一范式的 基础上进一步满足更多要求的称为第二范式(2NF),其余范式以次类推。一般说来,数 据库只需满足第三范式(3NF)就行了。下面我们举例介绍第一范式(1NF)、第二范式 (2NF)和第三范式(3NF)。 在创建一个数据库的过程中,范化是将其转化为一些表的过程,这种方法可以使从数据 库得到的结果更加明确。这样可能使数据库产生重复数据,从而导致创建多余的表。范 化是在识别数据库中的数据元素、关系,以及定义所需的表和各表中的项目这些初始工 作之后的一个细化的过程。 下面是范化的一个例子 Customer Item purchased Purchase price Thomas Shirt $40 Maria Tennis shoes $35 Evelyn Shirt $40 Pajaro Trousers $25 如果上面这个表用于保存物品的价格,而你想要删除其中的一个顾客,这时你就必须同 时删除一个价格。范化就是要解决这个问题,你可以将这个表化为两个表,一个用于存 储每个顾客和他所买物品的信息,另一个用于存储每件产品和其价格的信息,这样对其 中一个表做添加或删除操作就不会影响另一个表。 关系数据库的几种设计范式介绍 1 第一范式(1NF) 在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式 (1NF)的数据库就不是关系数据库。 所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能 有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的 属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之 间为一对多关系。在第一范式(1NF)中表的每一行只包含一个实例的信息。例如,对于 图3-2 中的员工信息表,不能将员工信息都放在一列中显示,也不能将其中的两列或多列在一 列中显示;员工信息表的每一行只表示一个员工的信息,一个员工的信息在表中只出现 一次。简而言之,第一范式就是无重复的列。 2 第二范式(2NF) 第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必 须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以 被惟一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。如 图3-2 员工信息表中加上了员工编号(emp_id)列,因为每个员工的员工编号是惟一的,因此 每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。 第二范式(2NF)要求实体的属性完全依赖于主关键字。(即主关键字就代表了所有属性 ,决定 了所有属性)所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那 么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之 间是一对多的关系。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识 。简而言之,第二范式就是非主属性非部分依赖于主关键字。 3 第三范式(3NF) 满足第三范式(3NF)必须先满足第二范式(2NF)。简而言之,第三范式(3NF)要求一 个数据库表中不包含已在其它表中已包含的非主关键字信息。例如,存在一个部门信息 表,其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在图3- 2的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再 加入员工信息表中。如果不存在部门信息表,则根据第三范式(3NF)也应该构建它,否 则就会有大量的数据冗余。简而言之,第三范式就是属性不依赖于其它非主属性。 数据库设计三大范式应用实例剖析 数据库设计范式是数据库设计所需要满足的规范,满足这些规范的数据库是简洁的、 结构明晰的,同时,不会发生插入(insert)、删除(delete)和更新(update)操作 异常。反之则是乱七八糟,不仅给数据库的编程人员制造麻烦,而且面目可憎,可能存 储了大量不需要的冗余信息。   设计范式是不是很难懂呢?非也,大学教材上给我们一堆数学公式我们当然看不懂 ,也记不住。所以我们很多人就根本不按照范式来设计数据库。   实质上,设计范式用很形象、很简洁的话语就能说清楚,道明白。本文将对范式进 行通俗地说明,并以笔者曾经设计的一个

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值