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

Posted 我带你们打代码

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了数据库原理与设计第六章知识点总结相关的知识,希望对你有一定的参考价值。

数据库原理与设计


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

第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。

以上是关于数据库原理与设计第六章知识点总结的主要内容,如果未能解决你的问题,请参考以下文章

Python 编程快速上手 第六章总结

超详细的计算机网络基础知识总结 第六章:应用层

201771010124 王海珍 《实验六 继承定义与使用》第六章实验总结

201771010143 张云飞《面向对象程序设计(java)》第六章学习总结

20145334赵文豪 《Java程序设计》第4周学习总结

总结20230328