【数据库系统设计】关系数据理论（函数依赖、码、范式、模式分解）

最新推荐文章于 2024-07-06 18:00:47 发布

萌宅鹿同学

最新推荐文章于 2024-07-06 18:00:47 发布

阅读量3.4k

点赞数 12

CC 4.0 BY-SA版权

分类专栏： # 数据库系统设计文章标签：数据库

本文链接：https://blog.csdn.net/weixin_43734095/article/details/105320804

数据库系统设计专栏收录该内容

12 篇文章

订阅专栏

本文深入探讨了关系数据理论的重要性，解析了好的数据库逻辑设计的标准，并通过实例展示了不当设计带来的问题。介绍了数据依赖、函数依赖、多值依赖、连接依赖等概念，详细解释了候选码、超码、主码、外码等关键术语。文章还涵盖了第一范式到BC范式等关系模式的规范化理论，以及数据依赖的公理系统和模式分解算法。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

笔记目录点这里：南邮计算机专业基础

6.1 为什么要学习关系数据理论

什么是好的数据库逻辑设计

举一个反面例子：

学校开发一个学校教务的数据库，涉及的对象有：
学生的学号（Sno）、所在系（Sdept）、系主任姓名（Mname）、课程号（Cno）和成绩（Grade）。

语义：

一个系有若干学生，但一个学生只属于一个系；
一个系只有一名主任；
一个学生可以选修多门课程，每门课程有若干学生选修；
每个学生所学的每门课程都有一个成绩。

设计了一个关系模式：STUDENT（Sno, Sdept, Mname, Cno, Grade）
在这里插入图片描述

这个关系模式存在很多问题：

数据冗余度太大，浪费存储空间
如：系主任的姓名重复出现，重复次数与该系所有学生的所有课程成绩出现次数相同。
更新异常（Update Anomalies）
数据冗余，更新数据时，维护数据完整性代价大；
如果某系更换系主任，系统必须修改与该系学生有关的每一个元组。
插入异常（Insertion Anomalies），该插入的数据插不进去
如果新成立一个软件工程系，还没有招生，我们就无法把这个系及其系主任的信息存入数据库。
删除异常（Deletion Anomalies），不该删除的数据也删去了
如果某个系的学生全部毕业了，我们在删除该系学生信息的同时，把这个系及其系主任的信息也丢掉了。

很明显这不是一个好的关系模式。
问题的原因：由于模式中的某些数据依赖引起的。
解决方法：把这个单一模式分成3个关系模式。

S ( Sno，Sdept ) ;
Sno → Sdept
SC ( Sno，Cno，Grade ) ;
( Sno，Cno ) → Grade
DEPT ( Sdept，Mname ) ;
Sdept → Mname

这3个模式不会发生插入异常、删除异常毛病；数据冗余得到控制。

再把观察、经验上升为理论：用规范化理论改造关系模式，消除其中不合适的数据依赖。

什么是数据依赖

数据依赖是完整性约束的一种表现形式。
数据依赖是通过一个关系中属性间值的相等与否体现出来的数据间的相互关系。

例如：存在关系 STUDENT ( Sno ,Sdept, Mname,Cno,Grade )

该关系模式的属性集合记为U：

U ＝{ Sno, Sdept, Mname, Cno, Grade }

数学中的函数 y = f(x)，自变量 x 确定之后，相应的函数值 y 也就唯一地确定了。
Sdept = f(Sno)，Sno 函数确定 Sdept，记为 Sno → Sdept；
Mname = f(Sdept)，Sdept 函数确定 Mname，记为 Sdept → Mname；
Grade = f((Sno, Cno)) , (Sno, Cno) 函数确定 Grade，记为 (Sno, Cno) → Grade；

属性组U上的函数依赖集合，记为F：

F ＝{ Sno → Sdept, Sdept → Mname, (Sno, Cno) → Grade }

用一个图表示数据依赖：在这里插入图片描述

数据依赖的主要类型

函数依赖(Functional Dependency，简记为FD)
多值依赖(Multivalued Dependency，简记为MVD)
连接依赖
… …

数据依赖对关系模式的影响

不合适的数据依赖，造成插入异常、删除异常、更新异常和数据冗余问题

关系模式的简化表示

关系模式的形式化定义：R ( U, D, DOM, F )

R：关系名，是符号化的元组语义
U：该关系的属性集合
D：属性组U中属性所来自的域
DOM：属性向域的映象集合
F：属性间数据的依赖关系集合

关系模式的简化表示：R<U, F>
将关系模式简化为一个三元组，影响数据库模式设计的主要是 U 和 F。
当且仅当 U 上的一个关系 r 满足 F 时，r 称为关系模式 R(U, F) 的一个关系。

例如：关系模式 STUDENT<U, F>

属性集合 U = { Sno, Sdept, Mname, Cno, Grade }
依赖关系 F =｛ Sno → Sdept, Sdept → Mname, (Sno, Cno) → Grade｝
STUDENT ( Sno, Sdept, Mname, Cno, Grade,
Sno → Sdept, Sdept → Mname, (Sno, Cno) → Grade )
该关系模式 STUDENT<U,F> 存在诸多问题。

如何解决关系模式中存在的问题？
规范化理论 — 找出关系模式中不合适的数据依赖，消除它们，可以在不同程度上解决插入异常、删除异常、更新异常和数据冗余问题。

6.2 规范化 — 关系的规范化理论

6.2.1 函数依赖

1.函数依赖

定义：
设 R(U) 是一个属性集 U 上的关系模式，X 和 Y 是 U 的子集。若对于 R(U) 的任意一个可能的关系 r，r 中不可能存在两个元组在 X 上的属性值相等，而在 Y 上的属性值不等则称 “X函数确定Y” 或 “Y函数依赖于X” ，记作X → Y。X 称为这个函数依赖的决定属性组，也称为决定因素(Determinant)。
在这里插入图片描述
反例：

问：由下面的关系表, 能否得出 Sname → Sno ?
在这里插入图片描述
答：只由关系表不能得出依赖关系。函数依赖不是指关系模式R的某个或某些关系实例r满足的约束条件，而是指R的所有关系实例r均要满足的约束条件。

如何确定函数依赖?
函数依赖是语义范畴的概念。只能根据数据的语义来确定函数依赖。

如Sname →Sno函数依赖只有在“学生不允许有重名”的条件下成立。

数据库设计者可以对现实世界作强制的规定。

例如设计者可以强行规定不允许学生有重名，因而使函数依赖
Sname → Sno，Sname → Ssex， Sname → Sage，Sname → Sdept 成立。

函数依赖是指关系模式R在任何时刻的关系实例均要满足的约束条件。

不是指某个或某些关系实例r满足的约束条件，而是指R的所有关系实例r均要满足的约束条件。

2.平凡函数依赖与非平凡函数依赖

定义：
在这里插入图片描述
示例：

对于任一关系模式，平凡函数依赖都是必然成立的，它不反映新的语义，因此若不特别声明， 我们总是讨论非平凡函数依赖。

3.完全函数依赖与部分函数依赖

定义：
在这里插入图片描述
示例：

4.传递函数依赖

定义：
在这里插入图片描述
示例：

6.2.2 码

候选码、超码

候选码、超码定义：
在这里插入图片描述
候选码、超码示例：

主码

在这里插入图片描述

主属性、非主属性

主属性、非主属性定义：
在这里插入图片描述
主属性、非主属性示例：

全码

在这里插入图片描述

外码

外码定义：
在这里插入图片描述
外码示例：

6.2.3 范式

范式是符合某一种级别的关系模式的集合。
关系数据库中的关系必须满足一定的要求。满足不同程度要求的为不同范式。

范式的种类：

第一范式(1NF)
第二范式(2NF)
第三范式(3NF)
BC范式(BCNF，Boyce和Codd共同提出的范式）
第四范式(4NF)
第五范式(5NF)

各种范式之间存在联系：
在这里插入图片描述
第一范式：
1NF的定义：如果一个关系模式R的所有属性都是不可分的基本数据项，则R∈1NF。

第一范式是对关系模式的最起码的要求。不满足第一范式的数据库模式不能称为关系数据模式。（不能表中有表）

6.2.4 第二范式（2NF）

只满足第一范式的关系模式并不一定是一个好的关系模式。
在这里插入图片描述
2NF定义：

2NF示例：

一个关系模式R不属于2NF，就会产生问题。

原因： SLC(Sno, Sdept, Sloc, Cno, Grade) 中
Sdept、 Sloc 部分函数依赖于码。SLC的码为(Sno, Cno)