【数据库原理及应用】——关系数据库的规范化理论(学习笔记)

数据库原理及应用(思维导图、索引、合集) 数据库基础 数据库原理及应用(一)基本概念和模式 数据库原理及应用(十四)三层模式和两级映像 数据模型 数据库原理及应用(二)数据模型 数据库原理及应用(九)数据模型详解 数据库设计 数据库原理及应用(三)数据库设计 数据库原理及应用(十三)E-R图、关系模式 数据库原理及应用(四)关系数据库 数据库原理及应用(七)关系数据库系统理论 SQL 数据库原理及应用(五)SQL 数据库原理及应用(十)SQL详解--select单表查询 数据库原理及应用(十一)SQL详解--sele.. 阅读详情

📖 前言:关系数据库的规范化理论是数据库设计的一个理论指南,提供了判断一个关系模式优劣的理论依据。本章讨论的关系数据库的规范化理论主要包含三方面内容:函数依赖、范式和模式分解准则。函数依赖起着核心作用,是模式分解的基础,而范式是模式分解的标准。

在这里插入图片描述


🕒 0. 思维导图

请添加图片描述

🕒 1. 问题的提出

关系数据库逻辑设计

  • 针对具体问题,如何构造一个适合于它的数据模式
  • 数据库逻辑设计的工具──关系数据库的规范化理论

在关系数据库中,关系模型包含一组关系模式,并且各个关系不是完全孤立的。那么,一个数据库模型应该构造几个关系模式,每个关系模式应该包含哪些属性,又如何将这些相互关联的关系模式组成一个合适的关系模型,确切的说,这是数据库逻辑设计要解决的问题。

关系模式是一个五元组: R ( U , D , D O M , F ) R(U, D, DOM, F) R(U,D,DOM,F)

  • 关系名R是符号化的元组语义
  • U为一组属性
  • D为属性组U中的属性所来自的域
  • DOM为属性到域的映射
  • F为属性组U上的一组数据依赖

由于 D 、 D O M D、DOM D、DOM与模式设计关系不大,因此在本章中把关系模式看作一个三元组: R < U , F > \color{red}R<U,F> R<U,F>

当且仅当U上的一个关系r满足F时,r称为关系模式 R < U , F > R<U,F> R<U,F>的一个关系

例1:学校要建立一个教学管理信息系统,假设有描述学生成绩管理情况的关系模式SCD:
SCD(Sno,Sname,Sage,Dept,Mname,Cno,Grade)
涉及的对象有:学号、学生姓名、学生年龄、所属系别、系主任,课程号,成绩。
该关系的码为:Sno、Cno

SCD表:
 Sno   Sname   Sage   Dept   Mname   Cno   Grade  20150101  孙涛  18  计算机   王伟  050201 94 20150101  孙涛  18  计算机   王伟  050202 88 20150101  孙涛  18  计算机   王伟  050203 75 20150105  李明  18  计算机   王伟  050201 76 20150105  李明  18  计算机   王伟  050202 92 20140103  张玲  19  网络   刘明  040301 82 20130106  汪东  20  电子   王伟  030101 70 20120109  陈艺  21  通信   肖杰  020202 89 20120109  陈艺  21  通信   肖杰  020203 90 ⋮ ⋮ ⋮ ⋮ ⋮ ⋮ ⋮ \begin{array}{|c|c|c|c|c|c|c|} \hline \text { Sno } & \text { Sname } & \text { Sage } & \text { Dept } & \text { Mname } & \text { Cno } & \text { Grade } \\ \hline 20150101 & \text { 孙涛 } & 18 & \text { 计算机 } & \text { 王伟 } & 050201 & 94 \\ \hline 20150101 & \text { 孙涛 } & 18 & \text { 计算机 } & \text { 王伟 } & 050202 & 88 \\ \hline 20150101 & \text { 孙涛 } & 18 & \text { 计算机 } & \text { 王伟 } & 050203 & 75 \\ \hline 20150105 & \text { 李明 } & 18 & \text { 计算机 } & \text { 王伟 } & 050201 & 76 \\ \hline 20150105 & \text { 李明 } & 18 & \text { 计算机 } & \text { 王伟 } & 050202 & 92 \\ \hline 20140103 & \text { 张玲 } & 19 & \text { 网络 } & \text { 刘明 } & 040301 & 82 \\ \hline 20130106 & \text { 汪东 } & 20 & \text { 电子 } & \text { 王伟 } & 030101 & 70 \\ \hline 20120109 & \text { 陈艺 } & 21 & \text { 通信 } & \text { 肖杰 } & 020202 & 89 \\ \hline 20120109 & \text { 陈艺 } & 21 & \text { 通信 } & \text { 肖杰 } & 020203 & 90 \\ \hline \vdots & \vdots & \vdots & \vdots & \vdots & \vdots & \vdots \\ \hline \end{array}  Sno 201501012015010120150101201501052015010520140103201301062012010920120109⋮​ Sname  孙涛  孙涛  孙涛  李明  李明  张玲  汪东  陈艺  陈艺 ⋮​ Sage 181818181819202121⋮​ Dept  计算机  计算机  计算机  计算机  计算机  网络  电子  通信  通信 ⋮​ Mname  王伟  王伟  王伟  王伟  王伟  刘明  王伟  肖杰  肖杰 ⋮​ Cno 050201050202050203050201050202040301030101020202020203⋮​ Grade 948875769282708990⋮​​

分析语义如下:
(1)一个系有若干学生,但一个学生只属于一个系;
(2)一个系只有一个系主任;
(3)一个学生可以选修多门课程,每门课程可以被多个学生选修;
(4)每个学生学习的每一门课程都有一个成绩。

该关系模式存在四类问题:

(1)数据冗余
每个系的系名和系主任名字存储的次数等于该系所有学生的所有课程成绩出现的次数,而且每个学生的姓名和年龄也都要重复存储多次,数据冗余度很大。数据冗余不仅造成存储空间的浪费,还为数据不一致问题埋下了隐患。
(2)插入异常
如果一个系刚成立,没有招生,则系名和系主任名字无法存入数据库中。因为这时没有学生,所以Sno、Cno无值,而SCD的主码(Sno,Cno)值不能为空,因此不能进行插入操作。简而言之,即应该插入的数据未被插入。
(3)删除异常
当某系学生全部毕业而又没有招新生时,需要把该表数据转入历史数据库,从而要在该表中删除全部学生的记录,这时系名、系主任名字也随之删除,虽然现实中这个系依然存在,但在数据库中却无法找到该系的信息。简而言之,即不该删除的数据被删除。
(4)更新异常
某系更换系主任后,必须修改与该系学生有关的所有元组。如果该系中有一个学生没有修改,则会出现同一个系,两个系主任的现象。

该关系模式是一个好的模式吗?不是

原因:由存在于模式中的某些数据依赖引起的
解决方法:通过分解关系模式来消除其中不合适的数据依赖

如何设计关系模式?

在这里插入图片描述
“好”的模式:

  • 不会发生插入异常、删除异常、更新异常,数据冗余应尽可能少(因为不可避免)

关系规范化理论正是用来改造关系模式,通过分解关系模式来消除其中不合适的数据依赖,以解决插入异常、删除异常、更新异常和数据冗余问题。

🕒 2. 关系规范化

🕘 2.1 函数依赖

🕤 2.1.1 定义

设 R ( U , F ) R(U,F) R(U,F)是属性集 U U U上的关系模式, F F F是 U U U上的函数依赖集, X X X和 Y Y Y是 U U U的子集, r r r是 R ( U , F ) R(U,F) R(U,F)中任一可能的关系, t 1 t_1 t1​和 t 2 t_2 t2​是 r r r中任意两个元组。如果 X X X的每一个具体值, Y Y Y都有唯一的具体值与之对应;也就是说,如果由 t 1 [ X ] = t 2 [ X ] t_1[X]=t_2[X] t1​[X]=t2​[X]可以推导出 t 1 [ Y ] = t 2 [ Y ] t_1[Y]=t_2[Y] t1​[Y]=t2​[Y],则称 Y Y Y函数依赖于 X X X,或 X X X函数确定 Y Y Y,记作 X → Y \color{red}X \to Y X→Y。

函数依赖有关的几个基本术语:
(1)决定因素:若 X → Y X \to Y X→Y,则X被称为决定因素。
(2)互相依赖:若 X → Y , Y → X X \to Y,Y \to X X→Y,Y→X,称 X X X和 Y Y Y互相依赖,记作 X ↔ Y X \leftrightarrow Y X↔Y。
(3)若 Y Y Y不依赖于 X X X,则记作 X ↛ Y X \nrightarrow Y X↛Y。
函数依赖本质上都是强调了X对Y的决定作用。若X相等,则Y一定相等;若X不等,Y可以相等,也可以不等。

例2:关系模式SCD函数依赖举例

分析得到关系模式SCD中的属性集合以及存在的一些依赖关系如下:
U={ Sno,Sname,Sage,Dept,Mname,Cno,Grade }
F={ Sno → \to → Sname,Sno → \to →Sage,Sno → \to → Dept,Dept → \to → Mname,(Sno,Cno) → \to → Grade}
函数依赖的含义是:
① Sno → \to → Sname的含义:如果学号确定,学生的姓名就确定;此时,学号函数确定学生姓名,或者说学生姓名函数依赖于学号;
② (Sno,Cno) → \to → Grade的含义:学号与课程号的属性组合决定了学生选修某门课的成绩。可见,决定因素X可以是单个属性,也可以是一个属性组。

🕤 2.1.2 平凡函数依赖与非平凡函数依赖

  • 一个函数依赖 X → Y X \to Y X→Y,如果满足 Y ⊈ X Y \nsubseteq X Y⊈X ,则称此函数依赖为非平凡函数依赖(Nontrivial Dependency);反之,若 X → Y X \to Y X→Y,但是 Y ⊆ X Y \subseteq X Y⊆X,则称之为平凡函数依赖(Trivial Dependency)。
  • 例如,关系模式SCD中Sno → \to → Sname,Sno → \to → Sage,Sno → \to → Dept,Dept → \to →Mname都是非平凡的函数依赖,(Sno,Sname) → \to →Sname则是平凡函数依赖。
  • 本书讨论的函数依赖都是非平凡的函数依赖。

🕤 2.1.3 完全函数依赖

  • 在 R ( U , F ) R(U,F) R(U,F)中,如果存在 X → Y X \to Y X→Y,且不存在 X X X的任何一个真子集 X ’( X ’ ⊂ X ) X’(X’\subset X) X’(X’⊂X),有 X ’ → Y X’\to Y X’→Y成立,则称Y对X完全函数依赖(Full Functional Dependency),记作 X ⟶ f Y X \stackrel{f}{\longrightarrow} Y X⟶f​Y。
  • 例如,关系模式SCD中,因为Sno Grade,Cno Grade,所以
    (Sno,Cno) ⟶ f \stackrel{f}{\longrightarrow} ⟶f​ Grade。

🕤 2.1.4 部分函数依赖

  • 在 R ( U , F ) R(U,F) R(U,F)中,如果存在 X → Y X\to Y X→Y,且 X X X中存在任何一个真子集 X ’( X ’ ⊂ X ) X’(X’\subset X) X’(X’⊂X),有 X ’ → Y X’→Y X’→Y成立,则称 Y Y Y对 X X X部分函数依赖(Partial Functional Dependency),记作 X ⟶ p Y X \stackrel{p}{\longrightarrow} Y X⟶p​Y。
  • 例如,在关系模式SCD中,因为Sno → \to → Sage,所以(Sno,Cno) ⟶ p \stackrel{p}{\longrightarrow} ⟶p​ Sage。

⚡ 注意:只有当决定因素是组合属性时,讨论部分函数依赖才有意义;当决定因素是单个属性时,只能是完全函数依赖。

例如,(Sno,Cno) ⟶ F \stackrel{F}{\longrightarrow} ⟶F​ Grade是完全函数依赖
(Sno,Cno) ⟶ P \stackrel{P}{\longrightarrow} ⟶P​Sdept是部分函数依赖
因为Sno → \to →Sdept成立,且Sno是(Sno,Cno)的真子集

❗ 转载请注明出处
作者:HinsCoder
博客链接:🔎 作者博客主页

🕤 2.1.5 传递函数依赖与直接函数依赖

  • 在 R ( U , F ) R(U,F) R(U,F)中, X 、 Y 、 Z X、Y、Z X、Y、Z是 U U U的不同的属性子集,设 X → Y , Y → Z X→ Y,Y → Z X→Y,Y→Z,如果 Y ↛ X Y \nrightarrow X Y↛X,且 Y ⊈ X Y \nsubseteq X Y⊈X,则称Z对X传递函数依赖(Transitive Functional Dependency),记作 X ⟶ t Z X \stackrel{t}{\longrightarrow} Z X⟶t​Z 。
  • 如果 Y → X Y →X Y→X,则 X ↔ Y X ↔ Y X↔Y,这时称 Z Z Z对 X X X直接函数依赖,而不是传递函数依赖。
  • 例如,在关系模式SCD中,Sno → \to → Dept,Dept → \to → Mname,且Dept ↛ \nrightarrow ↛ Sno,则有Sno ⟶ t \stackrel{t}{\longrightarrow} ⟶t​ Mname。当没有重名学生的情况下,Sno → \to → Sname,Sname → \to → Sno,则有Sno ↔ \leftrightarrow ↔ Sname,而Sname → \to → Dept,所以Dept对Sno是直接函数依赖。

🕘 2.2 关系模式中的码

  • 设 K K K为关系模式 R ( U , F ) R(U,F) R(U,F)中的属性或属性组,若 K ⟶ f U K \stackrel{f}{\longrightarrow} U K⟶f​U,则 K K K为 R R R的候选码(Candidate Key)。

⚡ 注意: K K K为决定 R R R中全部属性值的最小属性组,即 K K K的任意一个真子集都不是候选码。

  • 一个关系模式 R ( U , F ) R(U,F) R(U,F)中,可能有多个候选码,则选定其中的一个作为主码(Primary Key)。

①主属性:包含在任何一个候选码中的属性。
②非主属性:不包含在任何候选码中的属性。
③全码:候选码为整个属性组U。

⚡ 注意:主属性并不是只包含那些在主码中的属性,而是包含在所有候选码中的属性。

例3:关系模式S:学生(学号,姓名,性别,身份证号,年龄,所属系别)。
候选码为:学号,身份证号。
主码为:学号或者是身份证号。
主属性为:学号,身份证号。
非主属性为:姓名,性别,年龄,所属系别。

例4:关系模式C:授课(教师,教室,学生)
由于这三者之间是多对多的关系,所以,要确定元组中的任何一个属性,都必须使用这三个属性的集合。
候选码、主码均为:(教师,教室,学生)。
主属性为:教师,教室,学生。
没有非主属性。
这种情况下,称候选码是全部属性的表为全码表。

外码:若关系模式R(U,F)的属性或属性组X(X ⊆ \subseteq ⊆U)并非R的主码,而是另一个关系模式S的主码,则称X是R的外码(Foreign Key)。特殊情况下,R和S表可以是同一个表。

如在SC(Sno,Cno,Grade)中,Sno不是主码,但Sno是关系模式S(Sno,Sdept,Sage)的主码,则Sno是关系模式SC的外码 。

例5:TC(教师编号,课程编号,授课地点,授课时间)
T(教师编号,教师姓名,教师所属院系)   谁是外码?
解答:教师编号是关系模式TC的外码。

主码和外码提供了一个表示关系间联系的手段。如例5中教师编号体现了教师信息和教师授课信息之间的联系。

习题:
已知关系模式R(A,B,C,D,E)及其上的函数依赖集合FD={A → \to →D,B → \to →C ,E → \to →A },该关系模式的候选码是( )。
答案:BE

🕘 2.3 范式(Normal Form)

定义:范式实际上表示关系模式满足的某种级别。当关系模式满足某级别范式要求的约束条件时,就称这个关系模式属于这个级别的范式,记作R∈nNF。

范式的种类:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、 BC范式(BCNF)、第四范式(4NF)、第五范式(5NF)

在这里插入图片描述

各种范式之间存在联系: 1 N F ⊃ 2 N F ⊃ 3 N F ⊃ B C N F ⊃ 4 N F ⊃ 5 N F 1NF \supset 2NF \supset 3NF \supset BCNF \supset 4NF \supset 5NF 1NF⊃2NF⊃3NF⊃BCNF⊃4NF⊃5NF

一个低一级范式的关系模式,通过模式分解可以转换为若干个高一级范式的关系模式的集合,这种过程就叫规范化。
在实际规范过程中,应注意以下几点:
(1)1NF和2NF一般作为规范化过程的过渡范式。
(2)规范化程度,不一定越高越好。
(3)4NF和5NF主要用于理论研究,设计关系模式时,一般只要求达到3NF或BCNF。

🕤 2.3.1 第一范式(1NF)

定义:若关系模式R中所有的属性均为简单属性,即每个属性都是不可再分的,则称R为第一范式,简记为 R ∈ 1 N F \color{red}R∈1NF R∈1NF。如前面提到的原始的SCD表

1NF的关系模式要求属性不能再分,这和记录类型的文件是不同的,在文件记录类型中的数据项允许由组项或向量组成。而且,关系数据库管理系统(如SQL Server、Oracle)都只支持第一范式及以上级别范式的关系模式。因此,满足第一范式是最基本的规范化要求。

例6:左图所示的关系不是第一范式。因为表中“高级职称人数”是由2个基本数据项:教授和副教授组成的一个复合数据项。而右图符合第一范式。
在这里插入图片描述
然而,一个关系模式仅仅属于第一范式是不实用的。在上节给出的关系模式 S C D ∈ 1 N F SCD∈1NF SCD∈1NF,但它存在大量的数据冗余,存在插入异常、删除异常和更新异常。 为什么会存在这些问题呢?接下来分析一下SCD(Sno,Sname,Sage,Dept,Mname,Cno,Grade)中的函数依赖关系。其中它的主码是(Sno,Cno),存在一些函数依赖关系下图所示。

在这里插入图片描述
学生成绩管理子系统的函数依赖图,用实线、虚线分别表示完全和部分函数依赖。由图可见,SCD中既存在完全函数依赖,又存在部分函数依赖和传递函数依赖。这种情况在数据库中往往是不允许的,会导致操作异常。

🕤 2.3.2 第二范式(2NF)

定义:若关系模式 R ∈ 1 N F \color{red}R ∈ 1NF R∈1NF,且R中的每一个非主属性都完全函数依赖于主码,则称R为第二范式,简记为 R ∈ 2 N F \color{red}R∈2NF R∈2NF。
从上述定义可以得到两个结论:
① 从1NF关系中消除非主属性对主码的部分函数依赖,则可得到2NF关系;
② 如果R的主码只由一个属性组成,那么这个关系就是2NF关系。

分析:SCD∈2NF?
SCD(Sno,Sname,Sage,Dept,Mname,Cno,Grade)就不是2NF的。前面已经介绍过这个关系存在若干操作异常,而这些操作异常就是由于它存在部分函数依赖造成的。可以遵循“一事一地”的原则,让一个关系只描述一个实体或者实体间的联系。如果多于一个实体或联系,则进行模式分解,将一个非2NF分解成多个2NF的关系模式。

例7:1NF规范化到2NF的过程
将关系模式SCD(Sno,Sname,Sage,Dept,Mname,Cno,Grade)规范化为2NF。去掉部分函数依赖关系的分解过程为:
① 用组成主码的属性集合的每一个子集作为主码构成一个新的关系模式;
对SCD表,首先分析得到如下3个关系模式:
SD(Sno,…)
C(Cno,…)
SC(Sno,Cno,…)

② 将完全函数依赖于这些主码的属性放到相应的关系模式中;
据此,得到3个关系模式如下:
SD(Sno,Sname,Sage,Dept,Mname)
C(Cno)
SC(Sno,Cno,Grade)

③ 去掉只由主码自己构成的关系模式,也就是去掉C(Cno)。

综上所述,SCD分解为如下2个关系模式:
SD(Sno,Sname,Sage,Dept,Mname),描述学生实体;
SC(Sno,Cno,Grade),描述学生与课程的关系。

上述两个关系SD和SC的主码分别为Sno和(Sno,Cno),分析可知非主属性对主码完全函数依赖。因此,SD∈2NF,SC∈2NF。

在这里插入图片描述
分析:SD,SC是否还存在问题?

SD表:
 Sno   Sname   Sage   Dept   Mname  20150101  孙涛  18  计算机   王伟  20150105  李明  18  计算机   王伟  20140103  张玲  19  网络   刘明  20130106  汪东  20  电子   王伟  20120109  陈艺  21  通信   肖杰  ⋮ ⋮ ⋮ ⋮ ⋮ \begin{array}{|c|c|c|c|c|} \hline \text { Sno } & \text { Sname } & \text { Sage } & \text { Dept } & \text { Mname } \\ \hline 20150101 & \text { 孙涛 } & 18 & \text { 计算机 } & \text { 王伟 } \\ \hline 20150105 & \text { 李明 } & 18 & \text { 计算机 } & \text { 王伟 } \\ \hline 20140103 & \text { 张玲 } & 19 & \text { 网络 } & \text { 刘明 } \\ \hline 20130106 & \text { 汪东 } & 20 & \text { 电子 } & \text { 王伟 } \\ \hline 20120109 & \text { 陈艺 } & 21 & \text { 通信 } & \text { 肖杰 } \\ \hline \vdots & \vdots & \vdots & \vdots & \vdots \\ \hline \end{array}  Sno 2015010120150105201401032013010620120109⋮​ Sname  孙涛  李明  张玲  汪东  陈艺 ⋮​ Sage 1818192021⋮​ Dept  计算机  计算机  网络  电子  通信 ⋮​ Mname  王伟  王伟  刘明  王伟  肖杰 ⋮​​

SC表:
 Sno   Cno   Grade  20150101 050201 94 20150101 050202 88 20150101 050203 75 20150105 050201 76 20150105 050202 92 20140103 040301 82 20130106 030101 70 20120109 020202 89 20120109 020203 90 ⋮ ⋮ ⋮ \begin{array}{|c|c|c|} \hline \text { Sno } & \text { Cno } & \text { Grade } \\ \hline 20150101 & 050201 & 94 \\ \hline 20150101 & 050202 & 88 \\ \hline 20150101 & 050203 & 75 \\ \hline 20150105 & 050201 & 76 \\ \hline 20150105 & 050202 & 92 \\ \hline 20140103 & 040301 & 82 \\ \hline 20130106 & 030101 & 70 \\ \hline 20120109 & 020202 & 89 \\ \hline 20120109 & 020203 & 90 \\ \hline \vdots & \vdots & \vdots \\ \hline \end{array}  Sno 201501012015010120150101201501052015010520140103201301062012010920120109⋮​ Cno 050201050202050203050201050202040301030101020202020203⋮​ Grade 948875769282708990⋮​​

从上表中的数据可以看出仍然存在以下问题:
① 数据冗余:一个系有多少学生,就会重复存储多少次系别和系主任名。
② 插入异常:一个系新成立,没有招生,有关该系的信息无法插入SD表。
③ 删除异常:一个系学生全部毕业而又没有招新生时,把毕业生数据备份到历史数据中,删除该系所有学生记录时也删除了该系别和系主任名,此时SD表中没有该系的信息了。
④ 更新异常:系主任换人时,需要改动所有该系学生的信息,仍需改动较多学生记录。

习题:关系模式Activities(ID,Activity,Fee)是否属于2NF?

 ID   Activity   Fee(dollar)  2006001  Gplff  5 2006001  Swim  3 2006002  tennis  1 2006003  Swim  3 2006003  Tennis  1 \begin{array}{|c|c|c|} \hline \text { ID } & \text { Activity } & \text { Fee(dollar) } \\ \hline 2006001 & \text { Gplff }& 5 \\ \hline 2006001 & \text { Swim }& 3 \\ \hline 2006002 & \text { tennis }& 1 \\ \hline 2006003 & \text { Swim }& 3 \\ \hline 2006003 & \text { Tennis }& 1 \\ \hline \end{array}  ID 20060012006001200600220060032006003​ Activity  Gplff  Swim  tennis  Swim  Tennis ​ Fee(dollar) 53131​​

Activities(ID,Activity,Fee) ∉ \notin ∈/ 2NF
主码(ID,Activity) ⟶ P \stackrel{P}{\longrightarrow} ⟶P​ Fee ,因为 Activity → \to → Fee

🕤 2.3.3 第三范式(3NF)

定义:若关系模式R∈1NF,且每个非主属性都不传递依赖于主码,则称R为第三范式,简记为 R ∈ 3 N F \color{red}R∈3NF R∈3NF。
由定义可知,若R∈3NF,则每个非主属性既不部分函数依赖于主码,也不传递依赖于主码,即若R∈3NF,则必有R∈2NF。

分析:SD∈3NF?SC∈3NF?
关系模式SD(Sno,Sname,Sage,Dept,Mname),因为Sno → \to → Dept ,Dept → \to → Mname,所以存在Sno ⟶ t \stackrel{t}{\longrightarrow} ⟶t​ Mname,得出 S D ∉ 3 N F SD \notin3NF SD∈/3NF。
而关系模式SC(Sno,Cno,Grade),非主属性Grade既不部分依赖于主码,也不传递依赖于主码,所以 S C ∈ 3 N F SC\in3NF SC∈3NF。

在这里插入图片描述

例8:2NF规范化到3NF的过程

将关系模式SD(Sno,Sname,Sage,Dept,Mname)规范化为3NF。
去掉传递函数依赖关系的分解过程为:
① 对于不是候选码的每个决定因子,从关系模式中删去依赖于它的所有属性。
对SD表,首先得到关系模式:S(Sno,Sname,Sage,Dept)

② 新建一个关系模式,新关系模式中包含在原来关系模式中所有依赖于该决定因子的属性,并将该决定因子作为新关系的主码。
故得到一个新的关系: D(Dept,Mname)

综上所述,SCD关系分解得到3个关系模式如下:

S(Sno,Sname,Sage,Dept),描述学生实体,Dept为引用D关系的外码;
D(Dept,Mname),描述系别实体,没有外码;
SC(Sno,Cno,Grade),描述学生与课程的关系,Sno为引用S关系的外码。

分析:S,D,SC三个关系模式

S,D,SC三个关系模式中每个非主属性既不部分函数依赖于主码,也不传递依赖于主码。因此,S ∈ 3NF,D ∈3NF,SC ∈3NF。函数依赖关系如图所示。

在这里插入图片描述
☆☆ ☆ 习题:设关系模式R(职工号,日期,日营业额,部门名,部门经理),该关系用来统计商店每个职工的日营业额,以及记载职工所在的部门和经理是谁。如果规定:
每个职工每天只有一个营业额;每个职工只在一个部门工作;每个部门只有一个经理。
请回答下列问题:
(1)根据上述规定,写出模式R的基本FD和候选码。
(2)分析R是否为2NF。
(3)分析R是否为3NF,如果不是请将R分解成3NF。

解答:
(1) 基本FD:(职工号,日期)→日营业额 ;职工号→部门名 ;部门名→部门经理。候选码为:(职工号,日期)
(2)不是2NF,因为存在非主属性“部门名”部分依赖于码“(职工号,日期)”,因为职工号→部门名。
(3)不是3NF,因为存在非主属性“部门经理”传递依赖于候选码“(职工号,日期)”,因为(职工号,日期)→部门名 ;部门名→部门经理。
分解如下:
R1(职工号,日期 ,日营业额)
R2(职工号,部门名)
R3(部门名,部门经理)

第三范式还有问题吗?

  • 假设关系模式STJ(S学生,T教师,J课程)
  • 其包含的语义是:每位教师只开一门课程,每门课程可由多位教师讲授,存在课程名相同而由不同的教师开设的情况。学生选定课程的同时,可以确定是由哪位教师来教。
  • 根据语义有如下的函数依赖:
    F={(S,T) → \to → J, (S,J) → \to → T, T → \to → J}
  • 该关系模式属于第几范式?
  • 此关系的码是(S,T)或(S,J)
  • 该关系有没有传递函数依赖和部分函数依赖?

结论:STJ模式,因为没有非码属性(非主属性)部分函数依赖或传递函数依赖于码,所以∈3NF

 S   T   J  S1  王建   数据结构(计算机) S2  赵颖   数据结构(电子) S3  赵颖   数据结构(电子) S1  陈讯   C语言程序设计 S2  陈讯   C语言程序设计 \begin{array}{|c|c|c|} \hline \text { S } & \text { T } & \text { J } \\ \hline \text{S1} & \text { 王建 }& \text { 数据结构(计算机)} \\ \hline \text{S2} & \text { 赵颖 }& \text { 数据结构(电子)} \\ \hline \text{S3} & \text { 赵颖 }& \text { 数据结构(电子)} \\ \hline \text{S1} & \text { 陈讯 }& \text { C语言程序设计} \\ \hline \text{S2} & \text { 陈讯 }& \text { C语言程序设计} \\ \hline \end{array}  S S1S2S3S1S2​ T  王建  赵颖  赵颖  陈讯  陈讯 ​ J  数据结构(计算机) 数据结构(电子) 数据结构(电子) C语言程序设计 C语言程序设计​​

  • 问题1:教师开设课程信息重复、冗余;
  • 问题2:如果S1不想选修王老师的课,删除(S1,王建,数据结构)的同时,丢失了王老师讲授数据结构的信息。
  • 问题3:如果田老师计划开设一门新课,但因为还没有让学生选修他的课,因此无法插入田老师开新课的信息。

Boyce新发现

  • 已经属于第三范式的关系模式仍会出现冗余、插入异常、删除异常等问题。
  • STJ已经属于第三范式了,仍然会出冗余、异常问题。原因是:T J,但是T不是码。

🕤 2.3.4 BC范式(BCNF)

定义:若关系模式 R ∈ 1 N F R∈ 1NF R∈1NF,所有的函数依赖 X → Y X→Y X→Y且 Y ∉ X Y\notin X Y∈/X,决定因素X都含有候选码,则 R ∈ B C N F R∈ BCNF R∈BCNF。
通俗的说,当且仅当关系R中的每个函数依赖的决定因子都是候选码时,该范式即为BCNF。
等价于:每一个决定属性因素都包含码

说明:
① 3NF和BCNF之间的区别在于,对一个函数依赖X→Y,3NF允许Y是主属性,而X不是候选码。但BCNF要求X必须是候选码。
② 若R∈BCNF,则R∈3NF。但是,若R∈3NF,则未必有R∈BCNF。
在这里插入图片描述
③ 如果一个关系数据库的所有关系模式都属于BCNF,那么在函数依赖范畴内,它已经达到了最高的规范化程度,一定程度上消除了冗余、更新异常、插入异常和删除异常。

注:第四范式是基于多值依赖的,我们不学

思考:S,D,SC是BCNF吗?
回顾前面SCD的例子,通过模式分解得到三个关系模式:S,D,SC。它们都是3NF关系,同时也是BCNF关系,因为它们都只有一个决定因子。
S(Sno,Sname,Sage,Dept),描述学生实体,Dept为引用D关系的外码;
D(Dept,Mname),描述系别实体,没有外码;
SC(Sno,Cno,Grade),描述学生与课程的关系,Sno为引用S关系的外码。

3NF和BCNF

  • 大多数情况下,3NF的关系都是BCNF的,只有在以下特殊情况下,3NF的关系违反BCNF:
    ① 关系中包含2个或以上复合候选码;
    ② 候选码有重叠,通常至少有一个重叠的属性。

3NF关系转换成BCNF的方法:消除主属性对候选码的部分和传递函数依赖,即可将3NF关系分解成多个BCNF关系模式。

例9:在关系模式STJ(S,T,J)中,S表示学生,T表示教师,J表示课程。
函数依赖: (S,J)→T,(S,T)→J,T→J
(S,J)和(S,T)都是候选码

在这里插入图片描述

S T J ∈ 3 N F STJ\in 3NF STJ∈3NF

  • 没有任何非主属性对码传递依赖或部分依赖

S T J ∉ B C N F STJ\notin BCNF STJ∈/BCNF

  • T是决定因素,T不包含码

解决方法:将STJ分解为二个关系模式: ST(S,T) ∈ BCNF, TJ(T,J)∈ BCNF

在这里插入图片描述

没有任何属性对码的部分函数依赖和传递函数依赖

例10:关系模式Book(Bisbn,Bname,Author)的属性分别表示书的ISBN号、书名和书的作者。如果规定,每个书号只对应一个书名,但不同的书号可以有相同的书名;每本书可以有多个作者合作编写,但每个作者参与编著的书名应该不同。这样规定可以得出有如下两个函数依赖:
(Author,Bname)→Bisbn \hspace{3cm} Bisbn→Bname

BOOK是不是BC范式呢?不是

关系模式Book(Bisbn,Bname,Author)怎样分解为BCNF呢?

Book的候选码是(Bisbn,Author)或(Author,Bname),因而Book的属性都是主属性,Book属于3NF。但是Bisbn→Bname,决定因子不包含候选码,即:属性Bname传递函数依赖于候选码(Author,Bname),因此Book不是BCNF模式。例如,一本书由多个作者编写时,其书名与书ISBN号间的联系在关系中将多次出现,带来冗余和操作异常。
将Book模式分解成R1(Bisbn,Bname)和R2(Bisbn,Author),能解决上述问题,且R1和R2都是BCNF。

结论:BCNF与3NF的关系
在这里插入图片描述

如果R∈3NF,且R只有一个候选码

R ∈ B C N F ⇄  充分   必要  R ∈ 3 N F \begin{array}{l} \mathrm{R} \in \mathrm{BCNF} \underset{\text { 必要 }}{\stackrel{\text { 充分 }}{\rightleftarrows}} \mathrm{R} \in 3 \mathrm{NF} \\ \end{array} R∈BCNF 必要 ⇄ 充分 ​​R∈3NF​

3NF的“不彻底性”表现在可能存在主属性对候选码的部分函数依赖和传递函数依赖。
一个关系模型中所有的关系模式都属于BCNF,那么在函数依赖的范畴内,就已经实现了彻底的分离,消除了操作异常。

🕘 2.4 小结

  • 基本思想:逐步消除函数依赖中不合适的部分,使模式中的各关系模式达到某种程度的“分离”,即“一事一地”的模式设计原则:让一个关系描述一个实体或者实体间的一种联系,若多于一个实体就把它“分离”出去。
  • 目的:使结构合理,消除存储异常,使数据冗余尽量小,便于插入、删除和更新。

规范化过程:
在这里插入图片描述

  • 不能说规范化程度越高的关系模式就越好
  • 在设计数据库模式结构时,必须对现实世界的实际情况和用户应用需求作进一步分析,确定一个合适的、能够反映现实世界的模式
  • 上面的规范化步骤可以在其中任何一步终止
  • 关系模式的规范化过程是通过对关系模式的分解来实现的,即将低一级的关系模式分解为若干个高一级的关系模式。这种分解不是唯一的,下节将讨论模式分解的准则。

🕒 3. 关系模式的分解准则

用三个不同的准则来衡量关系模式分解的“等价”性:

  • 分解具有“无损连接性”

无损连接性是指分解后的关系通过自然连接可以恢复成原来的样子,即通过自然连接得到的关系与原来的关系相比,既不多出信息,又不丢失信息。

  • 分解具有“函数依赖保持性”

函数依赖保持性是指在模式的分解过程中,函数依赖不能丢失的特性,即模式分解不能破坏原来的语义。

  • 分解既具有“无损连接性”,又具有“函数依赖保持性”

那么,模式分解是否总能既保证无损连接,又保持函数依赖呢?答案是否定的。一个关系模式可能有多种分解方案,究竟怎样对关系模式进行分解才是好方案呢?

例11:关系模式分解方案优劣
关系模式SDM (Sno,Dept,Mname),各属性的含义分别为学号、系别、系主任名,则有函数依赖:Sno → Dept,Dept → Mname。
显然这个关系模式不是第三范式的。对于此关系模式我们至少可以有三种3NF方案:
方案1:S-M(Sno,Mname),D-M(Dept,Mname);
方案2:S-D(Sno,Dept),S-M(Sno,Mname);
方案3:S-D(Sno,Dept),D-M(Dept,Mname);

将一个关系模式R(U,F)分解为若干个关系模式R1(U1,F1),R2(U2,F2),…,Rn(Un,Fn),
其中, U = U 1 ⋃ U 2 ⋃ U 3 … ⋃ U n , F i ( i = 1 , 2 , … , n ) U = U1⋃U2⋃U3 …⋃Un,Fi(i=1,2,…,n) U=U1⋃U2⋃U3…⋃Un,Fi(i=1,2,…,n)是 F F F在 U i Ui Ui上的投影,这意味着将存储在一张二维表r中的数据分散到若干个二维表 r 1 , r 2 , … , r n r1, r2,…,rn r1,r2,…,rn中( r r ri是 r r r在属性组 U i Ui Ui上的投影)。当然希望这样的分解不丢失信息,也就是说,希望能通过对关系R1,R2,…,Rn的自然连接运算重新得到关系R中的所有信息。

某一时刻关系模式SDM的一个实例,此关系用r表示。

SDM关系模式的某一时刻数据(r)
 Sno   Dept   Mname  20150101  计算机   王伟 20140103  网络   刘明 20140105  网络   刘明 20130106  电子   王伟 \begin{array}{|c|c|c|} \hline \text { Sno } & \text { Dept } & \text { Mname } \\ \hline \text{20150101} & \text { 计算机 }& \text { 王伟} \\ \hline \text{20140103} & \text { 网络 }& \text { 刘明} \\ \hline \text{20140105} & \text { 网络 }& \text { 刘明} \\ \hline \text{20130106} & \text { 电子 }& \text { 王伟} \\ \hline \end{array}  Sno 20150101201401032014010520130106​ Dept  计算机  网络  网络  电子 ​ Mname  王伟 刘明 刘明 王伟​​

方案1:将SDM投影到S-M和D-M属性上,得到关系 r 11 r_{11} r11​和 r 12 r_{12} r12​,并做自然连接 r 11 ⋈ r 12 r_{11}\Join r_{12} r11​⋈r12​得到 r 1 r_1 r1​。

r 11 表 r_{11}表 r11​表
 Sno   Mname  20150101  王伟 20140103  刘明 20140105  刘明 20130106  王伟 \begin{array}{|c|c|} \hline \text { Sno } & \text { Mname } \\ \hline \text{20150101} & \text { 王伟} \\ \hline \text{20140103} & \text { 刘明} \\ \hline \text{20140105} & \text { 刘明} \\ \hline \text{20130106} & \text { 王伟} \\ \hline \end{array}  Sno 20150101201401032014010520130106​ Mname  王伟 刘明 刘明 王伟​​

r 12 表 r_{12}表 r12​表
 Dept   Mname  计算机  王伟 网络  刘明 电子  王伟 \begin{array}{|c|c|} \hline \text { Dept } & \text { Mname } \\ \hline \text{计算机} & \text { 王伟} \\ \hline \text{网络} & \text { 刘明} \\ \hline \text{电子} & \text { 王伟} \\ \hline \end{array}  Dept 计算机网络电子​ Mname  王伟 刘明 王伟​​

r 1 表 r_{1}表 r1​表
 Sno   Dept   Mname  20150101  计算机   王伟 20150101  电子   王伟 20140103  网络   刘明 20140105  网络   刘明 20130106  计算机   王伟 20130106  电子   王伟 \begin{array}{|c|c|c|} \hline \text { Sno } & \text { Dept } & \text { Mname } \\ \hline \text{20150101} & \text { 计算机 }& \text { 王伟} \\ \hline \text{20150101} & \text { 电子 }& \text { 王伟} \\ \hline \text{20140103} & \text { 网络 }& \text { 刘明} \\ \hline \text{20140105} & \text { 网络 }& \text { 刘明} \\ \hline \text{20130106} & \text { 计算机 }& \text { 王伟} \\ \hline \text{20130106} & \text { 电子 }& \text { 王伟} \\ \hline \end{array}  Sno 201501012015010120140103201401052013010620130106​ Dept  计算机  电子  网络  网络  计算机  电子 ​ Mname  王伟 王伟 刘明 刘明 王伟 王伟​​

🕘 3.1 无损连接性

定义: ρ = R 1 ( U 1 , F 1 ) , R 2 ( U 2 , F 2 ) , … , R n ( U n , F n ) \rho={R1(U1, F1), R2(U2, F2),…, Rn(Un, Fn)} ρ=R1(U1,F1),R2(U2,F2),…,Rn(Un,Fn)是关系模式 R ( U , F ) R(U, F) R(U,F)的一个分解,若对 R ( U , F ) R(U, F) R(U,F)任何一个关系 r r r均有 r = m ρ ( r ) r=mρ(r) r=mρ(r)成立, m ρ ( r ) = ⋈ i = 1 n π R q ( r ) m \rho (r)=\Join_{\mathrm{i}=1}^{n} \pi_{R_{q}}(r) mρ(r)=⋈i=1n​πRq​​(r),则分解 ρ \rho ρ具有无损连接性。

方案1不具有无损连接性,所以它不是一个好方案。

方案2:将SDM分解为S-D和S-M,则将SDM投影到S-D和S-M属性上,得到关系 r 21 r_{21} r21​和 r 22 r_{22} r22​,并做自然连接 r 21 ⋈ r 22 r_{21}\Join r_{22} r21​⋈r22​得到 r 2 r_2 r2​。

r 21 表 r_{21}表 r21​表
 Sno   Dept  20150101 计算机 20140103 网络 20140105 网络 20130106 电子 \begin{array}{|c|c|} \hline \text { Sno } & \text { Dept } \\ \hline 20150101 & 计算机 \\ \hline 20140103 & 网络 \\ \hline 20140105 & 网络 \\ \hline 20130106 & 电子 \\ \hline \end{array}  Sno 20150101201401032014010520130106​ Dept 计算机网络网络电子​​

r 22 表 r_{22}表 r22​表
 Sno   Mname  20150101 王伟 20140103 刘明 20140105 刘明 20130106 王伟 \begin{array}{|c|c|} \hline \text { Sno } & \text { Mname } \\ \hline 20150101 & 王伟 \\ \hline 20140103 & 刘明 \\ \hline 20140105 & 刘明 \\ \hline 20130106 & 王伟 \\ \hline \end{array}  Sno 20150101201401032014010520130106​ Mname 王伟刘明刘明王伟​​

r 2 表 r_{2}表 r2​表
 Sno   Dept   Mname  20150101  计算机   王伟 20140103  网络   刘明 20140105  网络   刘明 20130106  电子   王伟 \begin{array}{|c|c|c|} \hline \text { Sno } & \text { Dept } & \text { Mname } \\ \hline \text{20150101} & \text { 计算机 }& \text { 王伟} \\ \hline \text{20140103} & \text { 网络 }& \text { 刘明} \\ \hline \text{20140105} & \text { 网络 }& \text { 刘明} \\ \hline \text{20130106} & \text { 电子 }& \text { 王伟} \\ \hline \end{array}  Sno 20150101201401032014010520130106​ Dept  计算机  网络  网络  电子 ​ Mname  王伟 刘明 刘明 王伟​​

分析方案2:从 r 2 r_2 r2​表可以看出:分解后的关系经过自然连接后恢复成原来的关系,因此,方案2具有无损连接性。现在,我们对方案2做进一步分析。假设学生20140105从网络系转到了电子系,于是需要将 r 21 表 r_{21}表 r21​表中(20140105,网络)改为(20140105,电子), r 22 表 r_{22}表 r22​表中(20140105,刘明)改为(20140105,王伟)。如果这两个修改不同步,则数据库中就会出现数据不一致性。为什么?因为这样分解得到的两个关系模式没有保持原来的函数依赖关系。原来的函数依赖Dept → Mname在分解后既没有投影到S-D关系中,也没有投影到S-M关系中。因此,方案2没有保持原有的函数依赖关系,不是好方案。

方案3:S-D(Sno,Dept),D-M(Dept,Mname);
经过简单分析可以看出方案3具有无损连接性,也有保持原有的函数依赖,因此,它是一个好方案。
一般情况下,在模式分解式时,应该将有直接依赖关系的属性放在同一个关系模式中,如方案3,这样得到的分解结果往往能具有无损连接性,并同时保持原有的函数依赖关系。

结论:

  • 通过分析以上3种方案可以看出,如果一个分解具有无损连接性,则能够保证不丢失信息;如果一个分解具有函数依赖保持性,则可以减轻或解决各种异常情况。
  • 无损连接性和函数依赖保持性是两个相互独立的标准。具有无损连接性的分解不一定具有函数依赖保持性。同样,具有函数依赖保持性的分解也不一定具有无损连接性。
  • 规范化理论提供了一套完整的模式分解方法,如果分解既具有无损连接性,又具有函数依赖保持性,则分解一定能够达到3NF,但不一定能够达到 BCNF。所以在3NF的规范化中,既要检查分解是否具有无损连接性,又要检查分解是否具有函数依赖保持性。只有这两条都满足,才能保证分解的正确性和有效性,才能既不会发生信息丢失,又保证关系中的数据满足完整性约束。

🕒 4. 总结

  • 1NF:原子性,属性不能再分,即不能出现表中表
  • 2NF:不存在部分函数依赖,如(A, B, C, D),(A,B)为候选键,不能由候选关键字的一部分决定非关键字,如B->C
  • 3NF:不存在传递函数依赖,如A->B->C
  • BCNF:进一步消除主属性的传递依赖(A, B, C, D), 候选键有(A,B)和(B,C),所以主属性为A,B,C,不存在(A,B)->C,

🕒 5. 课后习题

  1. 【单选题】在一个关系中,能够惟一确定一个元组的属性或属性组合的叫做()。
    A、索引码
    B、关键字
    C、属性域
    D、排序码

  2. 【单选题】下列说法正确的是( )。
    A、属于BCNF的关系模式不存在存储异常
    B、函数依赖可由属性值决定,不由语义决定
    C、超键就是候选键
    D、码是唯一能决定一个元组的属性或属性组

  3. 【填空题】如果模式是BCNF,则模式R必定是________,反之,则___________成立。

  4. 【填空题】若有关系R(A,B,C),存在的函数依赖是{(A,C)→B,(A,B ) → C,B →C },则R的候选码是( ),R∈( )NF。

  5. 【填空题】若有关系R(S#,SD,SL,SN),其存在函数依赖为{S#→SD,S# →SN , S#→SL, SD→SL},则关系R的候选码为( ),R∈( )NF

  6. 【填空题】若有关系R(X,Y,Z),其存在函数依赖为F={Y→Z,XZ→Y},则关系R的候选码为( ),R∈( )NF。

  7. 【填空题】设有关系模式R(ABCD),F是R上成立的函数依赖集,F={A→B,C→B},则相对于F,R的候选码为( )。
    (注意:直接给出字母,不要用连接符号,如ABC)

  8. 【判断题】设有关系模式R,它主码只由一个属性组成。如果R∈1NF,则R是否一定属于2NF。

  9. 设有关系模式R(职工名,项目名,工资,部门号,部门名,部门经理)
    如果规定:
    每个职工可参加多个项目,每个项目各领一份工资;
    每个项目只属于一个部门,即项目名可确定部门号;
    每个部门只有一个经理。
    试回答下列问题:
    (1)根据上述规定,写出模式R的基本函数依赖FD和候选码。
    (2)请分析该模式是不是一个好的关系模式?为什么?
    (3)试问关系模式R最高已经达到第几范式?如果该模式不是一个好的模式,试用规范化理论对其进行分解使之达到第三范式。

  10. 设某商业集团数据库中有一个关系模式R(商店编码,顾客编码,消费总额,顾客单位,地址,电话),该模式的关系记载每个顾客在每个商店的累计消费总额。如果规定:每个顾客在每个商店只有一个消费总额; 每个顾客只属于一个单位; 每个顾客单位只有一个地址、一个电话。请回答下列问题:
    (1)根据上述规定,写出模式R的基本函数依赖FD和候选码。
    (2)分析R是否属于3NF,如果不是请将R规范化成3NF,并指出分解后的每个关系模式的主外码。


答案:1.B 2.D(解析:A.BC范式在函数依赖的范畴是没问题;B.是由语义觉得;C.候选键就是候选码,候选码有两个条件,①唯一性,也就是能根据候选码属性或属性组唯一确定一个元组的值;②最小特性,属性或属性组的最小组合就可以唯一的确定一个元组;超键只满足候选码的唯一性,不满足最小特性) 3.3NF、不一定 4.(A,C)或(A,B)、3(解析:都是主属性,那么就不存在非主属性对码的传递函数依赖和部分函数依赖,至少属于3NF;而因为B→C,BCNF要求每一个确定因素都是码,所以不符合BCNF) 5.S#、2(解析:码只有单个属性列,因此不存在非主属性对码的部分函数依赖;存在传递函数依赖,不属于3NF) 6.(X,Z)或(X,Y)、3 7.ACD 8.√
9.
(1)FD:(职工名,项目名)→工资;项目名→部门号;部门号→部门名;部门号→部门经理
其候选码为:职工名和项目名
(2)R(职工名,项目名,工资,部门号,部门名,部门经理)不是一个好的关系模式,因为:通过图中关系依赖图可以发现其码为(职工号,项目名)
①插入异常
假设职工号为07102,部门号为S1的职工还未参加项目,因项目名是主属性,因此该学生的信息无法插入R。
②删除异常
假定某个职工本来只参加了项目名为“三建”的一个工程。现在因某种原因,他连“三建”工程也不参加了。因项目名是主属性,此操作将导致该职工信息的整个元组都要删除。
③数据冗余度大
如果一个职工参加了10个工程,那么他的部门名称和部门经理的值就要重复存储了10次。
④修改复杂
例如由于某种原因,某职工要改变所参与的项目,在修改此职工元组的项目名的同时,还可能需要修改其部门号,部门名称和部门经理。如果这个职工参加了K个工程,则必须无遗漏地修改K个元组中全部部门号,部门名称和部门经理信息。
(3)职工名,项目名,工资,部门号,部门名,部门经理
由于部门名,部门经理部分函数依赖于码,因此该模式只满足第一范式,
所以采用投影分解法将一个1NF的关系分解为多个2NF的关系,即分解为两个关系模式,以消除这些部分函数依赖
R11(职工名,项目名,工资) ∈ 2 N F \in 2NF ∈2NF
R12(项目名,部门号,部门名,部门经理) ∈ 2 N F \in 2NF ∈2NF
但是2NF关系模式R2中,部门名和部门经理传递函数依赖于项目名,即R12中存在非主属性对码的传递函数依赖。所以进一步分解为两个关系模式,以消除传递函数依赖:
R22(项目名,部门号)∈3NF
R23(部门号,部门名,部门经理)∈ 3NF

(1)首先分析该模式的基本函数依赖FD为:
(商店编码,顾客编码)→消费总额,顾客编码→顾客单位,顾客单位→地址,顾客单位→电话
然后分析出关系模式R的候选码为:(商店编码,顾客编码)
(2)因为存在非主属性顾客单位对码的部分函数依赖与传递函数依赖,R不满足3NF。
首先消除非主属性对于码的部分函数依赖,将其分解为第二范式,则关系R分解为:R11 (商店编码,顾客编码,消费总额)
R12(顾客编码,顾客单位,地址,电话)
经分析可知,R11∈3NF,R12∈2NF,继续分解R12,消除非主属性对于码的传递函数依赖,则为R22(顾客编码,顾客单位)∈3NF
R23(顾客单位,地址,电话)∈3NF
故将R分解为第三范式后为:
R11(商店编码, 顾客编码 ∼ ∼ ∼ ∼ ∼ ∼ ∼ \underset{\sim\sim\sim\sim\sim\sim\sim}{\text{顾客编码}} ∼∼∼∼∼∼∼顾客编码​,消费总额) ∈ 3 N F \in 3NF ∈3NF
R22(顾客编码, 顾客单位 ∼ ∼ ∼ ∼ ∼ ∼ ∼ \underset{\sim\sim\sim\sim\sim\sim\sim}{顾客单位} ∼∼∼∼∼∼∼顾客单位​) ∈ 3 N F \in 3NF ∈3NF
R23(顾客单位,地址,电话) ∈ 3 N F \in 3NF ∈3NF


OK,以上就是本期知识点“关系数据库的规范化理论”的知识啦~~ ,感谢友友们的阅读。后续还会继续更新,欢迎持续关注哟📌~
💫如果有错误❌,欢迎批评指正呀👀~让我们一起相互进步🚀
🎉如果觉得收获满满,可以点点赞👍支持一下哟~

❗ 转载请注明出处
作者:HinsCoder
博客链接:🔎 作者博客主页

【数据库原理与应用 - 第四章】关系数据库规范化理论 数据库笔记系列——第四章:关系数据库规范化理论,包含函数依赖、1NF、2NF、3NF、BCNF范式、求候选码方法、求最小函数依赖集方法,5000+字详细总结! 阅读详情

相关推荐

关系数据库设计的规范化与非规范化之争

          关系数据库设计是对数据进行组织化和结构化的过程,核心问题是关系模型的设计。关系模型是数学化的、用二维表格数据描述各实体之间的联系的模型;它是所有的关系模式、属性名和关键字的汇集,是关系模式描述的对象。关系模式是指一个关系的属性名表,即二维表的表框架。关系模式的设计是关系模型设计的灵魂。所以,关系模式的设计是关系数据库设计核心的核心。关系模式的设计直接决定着关系数据库

Wish神思者的专栏 7797

数据库系统-关系数据理论

数据库系统-关系数据理论 关系数据库规范化理论 关系数据库规范化是为了告诉你如何才能设计出合适的库和表。 关系模式由五部分组成,即它是一个五元组 ​ R(U,D,DOM,F) R: 关系名 U: 组成该关系的属性名集合 D: 属性组U中属性所来自的域 DOM: 属性向域的映像集合 F: 属性间数据的依赖关系集合 关系数据库规范化理论研究的就是R、F、U,之间的关系。 因为D和DOM对研究表的设计关系不大,所以在学习关系数据库规范化理论时可以将五元组简化成三元组 R (U,F) 当且仅当U上的一个关系r满足

小旺的博客 4835

【数据库原理及应用】经典题库附答案(14章全)——第五章:关系数据理论

文章目录一、选择题二、简答题 一、选择题 为了设计出性能较优的关系模式,必须进行规范化,规范化主要的理论依据是( ) . A. 关系规范化理论 B. 关系代数理论 C.数理逻辑 D. 关系运算理论 规范化理论是关系数据库进行逻辑设计的理论依据,根据这个理论,关系数据库中的关系必须满足:每一个属性都是( ) . A. 长度不变的 B. 不可分解的 C.互相关联的 D. 互不相关的 已知关系模式R(A,B,C,D,E)及其上的函数相关性集合F={A→D,B→C ,E→A },该关系模式的候选关键字是( )

智慧空间实验室 3781

数据库原理及设计:第三章 关系数据模型 思维导图

由于第三章内容复杂且繁多,后续整理发布中……

Prosperity_c的博客 1102

(最新更新!)2024全国大学生数学建模竞赛(国赛)B题决策优化+鲁棒模型完整建模全解全析

2024全国大学生数学建模竞赛(国赛)B题完整建模全解全析(已更新!)

Yilu264的博客 9417

Andriod应用开发基础项目——记账本

本项目采用Java语言编写,是一款基于Android Studio开发的简易项目,本项目可以提高Java语言编写软件的能力,同时加深对开发软件Android studio有了更深层次的掌握,很适合初学者。在项目过程中,遇到了一些挑战和问题,但通过不断的努力和学习,最终取得了成功。未来,可以还可以继续优化App的功能和性能,增加更多实用的功能,提升用户体验。

eryasd的博客 3467

数据库设计思维导图

rylovend的博客 1991

华为私有云HCS 8.1.1实战:从镜像制作到云主机发放全流程指南

本文详细解析了华为私有云HCS 8.1.1从镜像制作到云主机发放的全流程实战指南。内容涵盖制作标准化QCOW2镜像、配置云主机规格与主机组、规划外部网络,以及在运营面为租户初始化资源、配置审批流与产品目录。最后,通过用户视角演示了从创建VPC网络到申请、审批并最终绑定EIP访问云主机的完整操作步骤,为运维人员和架构师提供了一套清晰、可落地的HCS部署与管理实践方案。

weixin_29305313的博客 1128

数据库设计中关系规范化理论总结

数据库是一门对数据进行有效管理的技术,它研究信息资源如何被安全地储存和如何被高效地利用,它是现代计算机科学的一个重要分支。其中关系数据库是目前被应用最广泛的数据库类型,它看起来类似于一张二维表,通过应用数学的方法来处理数据库中的数据。在关系数据库的设计过程中,最重要的莫过于对数据库的逻辑设计,即针对一个具体的问题,我们应该如何去构造一个适合它的数据库模式。经过科学家的讨论研究,最终形成我们今天所看到的关系数据库的规范化理论。本文通过例举具体事例来探讨关系规范化理论在数据库逻辑设计中的形成和方法。

K。的博客 9919

ADRC自抗扰算法优化(PLC梯形图篇)

ADRC自抗扰算法PLC梯形图完整源代码请参看下面博客文章:ADRC自抗扰控制算法(含梯形图完整源代码和算法公式)_adrc算法_RXXW_Dor的博客-优快云博客PLC的自抗扰控制(ADRC)算法_RXXW_Dor的博客-优快云博客_adrc算法1、自抗扰控制算法,网上很多文章有所讲解,大家也可以关注韩京清教授的论文和书籍,这里就不赘述了,下面给出梯形图+SCL代码。

RXXW_Dor的博客 2282

DSI3协议介绍

分布式系统接口(DSI)是一种通用且功能强大的总线协议,旨在将多个遥感器和执行器设备互连到中央控制模块。该网络的主要目标应用是汽车安全系统。这种应用的一些特点是需要低成本、高鲁棒性、中速互连,仅限于两根导线。此外,它必须具有故障安全性、确定性和良好的EMC特性。即使具有所有级别的智能和可编程性的设备都可以连接到网络,远程设备也必须能够通过简单的状态机实现。由于模块尺寸非常重要,因此中央模块和远程单元中的最小组件至关重要。

汽车电子软件领域知识分享 1万+

关系数据库规范化理论

 关系数据库规范化理论一个关系数据库由一组关系模式组成,一个关系由一组属性名组成,关系数据库设计就是如何把已给定的相互关联的一组属性名分组,并把每一组属性名组织成关系的问题。1、关系规范化的作用所谓规范化,就是用形式更为简洁、结构更加规范的关系模式取代原有关系的过程。2、函数依赖2.1、属性间的联系实体间的联系有两类:一类是实体与实体之间的联系;另一类是实体内部各属性间

hbrqlpf的专栏 2万+

【Unity 实用工具篇】✨| 受击插件Feel 详细教程,开发游戏时更好的操控 游戏打击感

在一个游戏中,游戏手感对于游戏的整体游玩体验是非常重要的,而游戏手感中有一个很重要的点:打击感 那本篇文章就来讲一下打击感中的受击反馈部分。 在游戏中经常会用到攻击敌人,敌人扣血,执行某些受击功能的执行,尤其是对于有战斗场景的游戏来说,这就是标准的受击反馈。 所以引出本篇文章的主角:受击插件 Feel 的使用,2D和3D游戏都可以使用。

努力前行,总会成为自己心中的那道光 3万+

数据库规范化理论详解

规范化理论是用来改造关系模式,通过分解关系模式来消除其中不合适的数据依赖,以解决数据冗余、插入异常、更新异常、删除异常这些问题。

junsuyiji的博客 5787

笔试题-2023-星宸-数字IC设计【纯净题目版】

4 笔试题-2023-星宸-数字IC设计【纯净题目版】

w0shishabi的博客 1171

JS逆向-7881游戏平台Lb-Sign参数和Lb-Timestamp参数

本文是该专栏的第79篇,后面会持续分享python爬虫干货知识。本文以7881游戏平台为例,通过JS逆向获取它的lb-sign参数和lb-timestamp参数生成规律。针对lb-sign和lb-timestamp两个参数具体的“逆向”思路逻辑,笔者将在本文进行详细说明,并且将在正文结合“完整代码”来详细介绍。废话不多说,具体细节部分以及详细思路逻辑,跟着笔者直接往下看正文部分。(附带完整代码)

Python进阶专栏《爬虫实战进阶》,《Pyppeteer从入门到精通》原创作者 1220

【数据库学习笔记】Day06 - 关系数据库规范化理论

【数据库学习笔记】Day06 - 关系数据库规范化理论 一、关系数据库中可能存在的问题: 以学生信息表为例:

oo00Z00oo的博客 5051

IDEA的使用指南

IDEA基于java的使用手册,可以最快速的上手,在使用中不断的丰富自己的使用技巧.

6.0 《数据库系统概论》之关系数据库的规范化理论(数据依赖对表的影响[插入-删除-修改-冗余]、1NF-2NF-3NF-BCNF-4NF、函数依赖与多值依赖)

文章目录0.思维导图1.为什么要学习关系数据库规范化理论?(1)基本概念回顾(2)关系模式的形式化定义(3)什么是数据依赖F?(4)数据依赖F对关系模式的影响1️⃣ 数据冗余(Data redundancy)2️⃣ 更新异常(update anomalies )3️⃣ 插入异常(insertion anomalies )4️⃣ 删除异常( deletion anomalies)2.规范化---改造关系模式,解决插入异常、删除异常、更新异常和数据冗余问题。(1)规范化研究什么?(2)函数依赖① 函数依赖② 平

BitHachi 3万+

efm32 入门.pdf

本PDF共计22页,介绍的是操作驱动API,下载与否自己斟酌。

Camera2Demo

在Camera2 的基础上进行封装,使得Camera2一堆初始化逻辑与Activity分离,降低耦合度,完成预览拍照并保存的操作

规范化理论

关系数据库规范化理论 前言 此处的知识点为递进关系,函数依赖->候选码->范式,缺一不可。 在关系模型中,一个数据库模式是关系模式的集合。关系数据理论是指导数据库设计的基 础,关系数据库设计是数据库语义学的问题。通常,要保证构造的关系既能准确地反映现实世 界,又有利于应用和具体的操作。关系数据库设计理论的核心是数据间的函数依赖,衡量的标 准是关系规范化的程度及分解的无损连接和保持函数依...

Masterheaven的博客 3549

jdk-8u144-linux-x64.tar.gz.

该资源为搭建Linux系统Java环境用,资源的后缀为tar.gz格式的压缩包

关系数据库理论

关系数据库理论 关系模式的组成 一个关系模式应当是一个五元组R(U,D,DOM,F) 这里R是符号化的元组语义 U为一组属性 D为属性组U中的属性所来自的域 DOM为属性到域的映射 F为属性组U上一组数据依赖(是一组数据依赖的集合) 由于D,DOM与模式涉及关系不大,因此本章中把关系模式看作一个三元组:R<U, F>,当且仅当U上一个关系r满足F时,r称为关系模式R<U, F>的一个关系 第一范式1NF 每一个分量必须是不可分的数据项 数据依赖 定义:数据依赖是一个关系内部属性和

Weightlessly的博客 5825

关系数据库规范化理论(转)

转载自:https://blog.csdn.net/weixin_37799190/article/details/79418322 关系数据库规范化理论一个关系数据库由一组关系模式组成,一个关系由一组属性名组成,关系数据库设计就是如何把已给定的相互关联的一组属性名分组,并把每一组属性名组织成关系的问题。1、关系规范化的作用所谓规范化,就是用形式更为简洁、结构更加...

如是说的博客 1239

数据库原理及应用(MySQL)

数据库原理及应用(MySQL)

Luxmlb的博客 8435

关系数据库设计:谈谈规范化技术

通过实际案例介绍关系数据库设计中的规范化技术(Normalization),为什么需要规范化,常见的第一范式、第二范式和第三范式,反规范化应用的场景以及外键的取舍问题。

Tony.Dong的专栏 5478
上一篇: 【现代密码学原理实验】——CrypTool2与OpenSSL的使用(学习笔记)
下一篇: 【人工智能与机器学习】——K近邻(KNN)与模型选择(学习笔记)
HinsCoder
博客等级 码龄5年 1万+粉丝 220原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值