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

关系数据库规范化理论

关系数据库规范化是为了告诉你如何才能设计出合适的库和表。

关系模式由五部分组成，即它是一个五元组

R(U,D,DOM,F)

R: 关系名

U: 组成该关系的属性名集合

D: 属性组U中属性所来自的域

DOM: 属性向域的映像集合

F: 属性间数据的依赖关系集合

关系数据库规范化理论研究的就是R、F、U,之间的关系。

因为D和DOM对研究表的设计关系不大，所以在学习关系数据库规范化理论时可以将五元组简化成三元组

R （U,F）

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

数据依赖

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

这种约束关系说通过属性间值的相等与否体现出来的数据间相关联系

它说现实世界属性间相互联系的抽象，是数据内在的性质，是语义的体现

数据依赖分类

1.函数依赖（Functional Dependency,简记为FD）

函数依赖极为普遍地存在于现实生活中。

属性间的这种依赖关系类似于数学中的函数y=f(x),自变量x确定之后，相应的函数值y也就唯一地确定了

2.多值依赖（Multivalued Dependency,简记为MVD）

3.其他

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

因为关系数据库规范化理论主要研究的是三元组R(U,F)，最重要的是F

【例】建立一个描述学校教务的数据库，数据库涉及的对象有：

学生的学号（Sno）、所在系（Sdept）、系主任姓名（Mname）、课程名（Cname）、成绩（Grade）

用单一的关系模式Student来表示做些对象：Student<U、F>

该关系的属性集合：U={Sno,Sdept,Mname,Cname,Grade}

关于这些对象之间的联系：

一个系有若干个学生，但一个学生只能属于一个系
一个系只有一名负责人
一个学生可以选修多门课程，每门课程用若干个学生选项
每个学生学习每一门课程只有一个成绩

属性组U上的一组函数依赖：

F={Sno->Sdept,Sdept->Mname,(Sno,Cname)->Grade}

这个关系模式设计的并不好，存在以下问题：

数据冗余（Date redundancy）

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

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

如果一个系刚成立，尚无学生，则无法把这个系及其系主任的信息存入数据库
删除异常（deletion anomalies）

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

得出结论：Student关系模式不是一个好的模型

好的模式不会发生插入异常、删除异常、更新异常，数据冗余应该尽可能少

原因：由存在于模式中的某些数据依赖引起的

解决方法：通过分解关系模式来消除其中不合适的数据依赖

可以把这个单一模式分成3个关系模式：

S（Sno,Sdept,Sno->Sdept）;

SC (Sno,Cname,Grade,(Sno,Cname)->Grade)

DEPT(Sdept,Mname,Sdept->Mname)

这三个模式都不会方式插入异常、删除异常的问题，数据的冗余也得到了控制。

一个模式的数据依赖会有哪些不好的性质，如何改造一个不好的模式，就是规范化要讨论的内容

规范化

规范化研究什么

规范化讨论如何根据属性间依赖情况来判定关系是否具有某些不合适的性质

通常按属性间依赖情况来区分关系规范化程度为第一范式、第二范式、第三范式和第四范式等用来改造关系模式

通过分解关系模式来消除其中不合适的数据依赖，以解决插入异常、删除异常、更新异常和数据冗余问题

函数依赖

数据依赖F中的函数依赖，分为以下几种类型：

函数依赖
平凡函数依赖与非平凡函数依赖
完全函数依赖与部分函数依赖
传递函数依赖

设R(U)是一个属性集U上的关系模式，X和Y是U的子集

若对于R(U)的任意一个可能的关系r，r中不可能存在两个元组这X上的属性值相等，而这Y上的属性值不等，则称“X函数确定Y”或“Y函数依赖于X”，记作X->Y

码

码是一个或多个属性的集合。包括超码，候选码，主码等。

超码

是一个或多个属性的集合，超码中的这些属性可以让我们这一个实体集中唯一地标识一个实体。

例如在{a,b,c,d}中，假设知道a的值就能确定a,b,c,d的值，假设知道c,d的值也可以确定a,b,c,d的值，那么{a}就是超码，{c,d}就是超码。并且{a,b},{a,c},{a,b,c},{a,b,c,d}等也都是超码，因为它们也可以确定一个元组的所有值，即使很多冗余。虽然超码可以唯一标识一个实体，但是可能大多数超码中含有多余的属性。所以我们需要候选码。

候选码

候选码是极小的超码集，也就是它的任意真子集都不是超码，而他本身是超码。

就上面的例子而言，{a}是候选码，{c,d}是候选码，因为它们的真子集中不存在超码。而诸如{a,b}并不是候选码，因为它的真子集中含有{a},且{a}是超码。

主码

主码就是主键的意思，主码是被选中用来这一个关系中区分不同元组的候选码。也就是是主码是任意一个会候选码。

主码是候选码{a},{c,d}中的其中一个。只能有一个。

主属性和非主属性

包含这任何一个候选码中的属性，称为主属性（Prime attribute）

不包含这任何候选码中的属性称为非主属性（Nonprime attribute）

外码

学生（学号，姓名，性别，专业号，出生日期）

专业（专业号，专业名）

学生关系模式中的专业号引用了专业关系模式中的专业号（且专业号这专业关系模式中是主码），显然学生关系中的专业号必须是个存在的专业号（可以为空表示未分配专业）。即学生关系模式中的专业号是引用了专业关系模式中的专业号的外码。

全码

整个属性组是主码，称为全码（All-key）

范式

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

第一范式（1NF）

第二范式（2NF）

第三范式（3NF）

BC范式（BCNF）

第四范式（4NF）

第五范式（5NF）

一个低一级范式的关系模式，通过模式分解可以转换为若干个高一级范式的关系模式的集合，这种过程就叫规范化。

1NF的定义

如果一个关系模式R的所有属性都是不可分的基本数据项，则R是1NF

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

但是满足第一范式的关系模式并不一定是一个好的关系模式。

1NF指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性

弊端：

数据的冗余很大，有大量的数据会重复，重复占空间。
字段名确定了，插入数据的时候但其他有些字段无值就会造成一些问题
删除某个字段具体值的时候，相应的并联字段会受到影响

2NF的定义

若R是1NF，且每一个非主属性完全函数依赖于码，则R是2NF。

在第一范式(1NF)的基础上，实体的属性完全函数依赖于关键字（混合主键），不能存在部分依赖函数与主关键字（混合主键）

3NF的定义

商品ID字段依赖与订单ID，商品的颜色和商品的尺寸依赖与商品ID，使用订单ID字段和商品颜色，商品尺寸操作一个传递依赖，所以，不满足于第三范式。

BCNF

也叫修正的第三范式，在3NF的基础上消除主属性对于码的部分与传播函数依赖。

若：某公司有若干个仓库；每个仓库只能有一名管理员，一名管理员只能在一个仓库中工作；一个仓库中可以存放多种物品，一种物品也可以存放这不同的仓库中。每种物品在每个仓库中都有对应的数量。

那么关系模式仓库（仓库名，管理员，物品名，数量）属于哪一级范式？

已知函数依赖集：仓库名->管理员，管理员->仓库名，（仓库名，物品名）->数量

码：（管理员，物品名），（仓库名，物品名）

主属性：仓库名、管理员、物品名

非主属性：数量

从这里可以得出结论，在某些特殊情况下，即使关系模式符合3NF的要求，仍然存在着插入异常，修改异常与删除异常的问题，仍然不是“好”的设计。存在着主属性对于码的部分函数依赖与传递函数依赖。（在此例中就是存在主属性｛仓库名｝对于码｛（管理员，物品名）｝的部分函数依赖）

解决方法就是要在3NF的基础上消除主属性对于码的部分与传递函数依赖

仓库（仓库名，管理员）

库存（仓库名，物品名，数量）

这样，插入异常，修改异常与删除异常的问题就被解决了

多值依赖

用一个例子引入多值依赖：

【例】学校中某一门课程由多个教师讲授，他们使用相同的一套参考书。每个教员可以讲授多门课程，每种参考书可以供多门课程使用

可以看出规范后的关系模式CTB的键是(C,T,B),即全码，CTB属于BC范式。但是，进一步分析可看出，CTB还存在着如下弊端。

但是当某一课程（如物理）增加一名讲课教师（如周英）时，必须插入多个（这里是三个）元组：（物理，周英，普通物理学），（物理，周英，光学原理），（物理，周英，物理习题集）。同样，某一门课（如数学）要去掉一本参考书（如积分方程），则必须删除多个（这里是两个）元组：（数学，李勇，微分方程），（数学，张平，微分方程）。可以看出对数据的增删改很不方便，数据的冗余也十分明显。这类关系模式具有一种称为多值依赖（Multi-Valued Dependency,MVD）的数据依赖。