《数据库系统概论》6.0——关系数据理论 大学生笔记

1.思维导图

2.问题提出

（1） 数据库规范化理论发展

• 针对一个具体问题，应如何构建一个适合的数据库模式。
• 这是数据库设计问题，也是关系数据库逻辑设计问题。
• 人们通常以关系模型为背景来讨论问题，形成了——关系数据库的规范化理论。

下面我们回顾一下 关系模型.

（2）概念回顾

• 关系：可简单的理解为二维表。
• 关系模式：即二维表的逻辑结构。
• 关系数据库：指采用了关系模型来组织数据的数据库，其以行和列的形式存储数据，关系型数据库这一系列的行和列被称为表，一组表组成了数据库。
• 关系数据库的模式：即关系数据库的逻辑结构。

（3）关系模型的形式化定义

三元组 R(U,F)

R：是符号化的元组语义。
U：为一组属性。
F：为属性U上的一组数据依赖。

（4）数据依赖

定义

 数据依赖是一个关系内部属性与属性之间的一种约束关系。

分类

• 函数依赖

函数依赖极为普遍地存在于现实生活中。
比如描述一个学生，可以用学号(Sno)、姓名(Sname)、 系名(Sdept) 等几个属性。
由于一个学号只对应一个学生，一个学生只在一一个系学习。因而当“学号”值确定之后，学生的姓名及所在系的值也就被唯一地确定了。
属性间的这种依赖关系类似于数学中的函数y=f(x)，自变量x确定之后，相应的函数值y也就唯一地确定 了。

• 多值依赖

有这样一个关系 （仓库管理员，仓库号，库存产品号） ， 假设一个产品只能放到一个仓库中，但是一个仓库可以有若干管理员，那么对应于一个 （仓库管理员，库存产品号）有一个仓库号，而实际上，这个仓库号只与库存产品号有关，与管理员无关，就说这是多值依赖

（5）数据依赖F对关系模式的影响

• 因为关系数据库规范化理论主要研究的是三元组R(U,F)，U我们都好理解，最重要的是F，这里我们简单的了解一下F对关系模式，即表的逻辑结构的影响，让我们理性的认识为什么学习关系数据库规范化理论.

举个例子：

首先 建立一个描述学校教务的数据库,数据库涉及的对象有：
学生的学号（Sno）、所在系（Sdept）、系主任姓名（Mname）、课程名（Cname）、成绩（G）

关系模式的属性集合

U={Sno,Sdept,Mname,Cno,G}

现实世界告诉我们，已知事实（语义）告诉我们：

①一个系有若干学生，但一个学生只属于一个系。
②一个系只有一名(正职)负责人。
③一个学生可以选修多门课程，每门课程有若干学生选修。
④每个学生学习每一门课程有一个成绩。

于是得性组U上的一组函数依赖F(如图6.1所示)

如果只考虑函数依赖这一种数据依赖， 可以得到一个描述学生的关系模式Student <U,F>。表6.1是某一时刻关系模式Student的一个实例，即数据表。

这个关系模式存在以下问题：

(1)数据冗余（Data redundancy）

比如，每一个系的系主任姓名重复出现，重复次数与该系所有学生的所有课程成绩出现次数相同， 这将浪费大量的存储空间。

(2)更新异常(update anomalies)

由于数据冗余，当更新数据库中的数据时，系统要付出很大的代价来维护数据库的完整性，否则会面临数据不一致的危险。比如，某系更换系主任后，必须修改与该系学生有关的每一个元组。

(3)插入异常(insertion anomalies)

如果一个系刚成立，尚无学生，则无法把这个系及其系主任的信息存入数据库。

(4)删除异常(deletion anomalies)

如果某个系的学生全部毕业了，则在删除该系学生信息的同时，这个系及其系主任的信息也丢掉了。

鉴于存在以上种种问题，可以得出这样的结论：

• Student关系模式不是一个好的模式。
• 好模式标准
  1. 不会发生插入异常。
  2. 不会发生删除异常和更新异常。
  3. 数据冗余应尽可能少。

一个模式的数据的依赖有那些不好的性质，如何改造不好的模式，这就是下面所讨论的话题了。

3.规范化

（1）函数依赖

设R（u）是属性集u上的关系模式，x,y是u的子集。若对于R（u）的任意一个可能关系r，r 中不能存在x上属性相同，而在y上属性不同。则称y函数依赖与x，记作x→y.

(2)函数依赖举例

例如：设一个职工关系为(职工号，姓名，性别，年龄，职务)
职工号用来标识每个职工，选作为该关系的主码。
对于该关系中每个职工的职工号，都对应着姓名属性中的唯一值，即该职工的姓名。
或者说一个职工的姓名由其职工号唯一确定，所以称职工号函数决定姓名，或称姓名函数依赖于 职工号，记作“职工号→姓名”。

4.码

（1)定义

• 码是关系模式中的一个重要概念。在 码的定义中有关码的若干定义， 这里用函数依赖的概念来定义码。
• 码唯一决定一个实体集。

（2） 候选码 超码 主码

说直白点：

• 候选码 就是k属与于u上的属性。并且U对K完全依赖。
• 超码 就是U对K 部分依赖。
• 主码 就是候选码太多，要选一个是主要的。

5.范式（重要）

（1)定义

• 关系数据库中，关系要满足一定要求。
• 满足不同程度要求的为不同范式。

（2）1NF

1NF的定义:

• 如果一个关系模式R的所有属性都是不可分的基本数据项，则R∈1NF
• 第一范式是对关系模式的最起码的要求。不满足第一范式的数据库模式不能称为关系数据库
• 但是满足第一范式的关系模式并不一定是一个好的关系模式

以下是一个满足1NF，但不是好的关系模式的例子：

关系模式 S-L-C(Sno, Sdept, Sloc, Cno, Grade) Sloc为学生住处，
假设每个系的学生住在同一个地方

这个例子中存在函数依赖，不是一个好的关系模式

图形化表示：

 S-L-C不是一个好的关系模式，一个关系模式 R不属于2NF,就会产生以下几个问题:

(1)插入异常。假若要插入一个学生Sno=S7， Sdept =PHY， Sloc =BLD2， 但该生还未选课，即这个学生无Cno,这样的元组就插不进S-L-C中。因为插入元组时必须给定码值，而这时码值的一部分
为空，因而学生的固有信息无法插入。
(2)删除异常。假定某个学生只选一门课，如S4就选了一门课C3，现在C3这门课他也不选了，那么C3这个数据项就要删除。而C3是主属性，删除了C3，整个元组就必须一起删除，使得S4的其他信息也被删除了，从而造成删除异常，即不应删除的信息也删除了。
(3)修改复杂。某个学生从数学系(MA)转到计算机科学系(CS)，这本来只需修改此学生元组中的Sdept分量即可，但因为关系模式S-L-C中还含有系的住处Sloc属性，学生转系将同时改变住处，因而还必须修改元组中的Sloc分量。另外，如果这个学生选修了k门课，Sdept、
Sloc重复存储了k次，不仅存储冗余度大，而且必须无遗漏地修改k个元组中全部Sdept、Sloc 信息，造成修改的复杂化。

为什么会有这些问题呢？

原因：
Sdept、 Sloc部分函数依赖于码。
解决方法(也就是2NF的处理方法)
S-L-C分解为两个关系模式，以消除这些部分函数依赖
SC（Sno， Cno， Grade）
S-L（Sno， Sdept， Sloc）

2NF

• 采用投影分解法将一个1NF的关系分解为多个2NF的关系，可以在一定程度上减轻原1NF关系中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。

将一个1NF关系分解为多个2NF的关系，并不能完全消除关系模式中的各种异常情况和数据冗余。所以又引入了3NF。

3NF

这里我们对上面的2NF例子再次进行剖析：

解决方法：

采用投影分解法，把S-L分解为两个关系模式，以消除传递函数依赖： S-D（Sno， Sdept） D-L（Sdept，Sloc）
S-D的码为Sno， D-L的码为Sdept。 分解后的关系模式S-D与D-L中不再存在传递依赖

采用投影分解法将一个2NF的关系分解为多个3NF的关系，可以在一定程度上解决原2NF关系中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。

将一个2NF关系分解为多个3NF的关系后，仍然不能完全消除关系模式中的各种异常情况和数据冗余。

BCNF

BCNF ( Boyce Codd Normal Form)是由Boyce与Codd提出的，比上述的3NF又进了一步，通常认为BCNF是修正的第三范式，有时也称为扩充的第三范式。