数据库第六章总结

6.1 问题的提出

关系数据库逻辑设计

针对具体问题，如何构造一个适合于它的数据模式
数据库逻辑设计的工具──关系数据库的规范化理论
关系模式由五部分组成，是一个五元组：
            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）
       一对一联系
设X，Y为关系中的属性或属性组，它们的所有可能取值组成两个集合。如果对于X中的任一具体值Y中至多有一个值与之对应，称X，Y这两个属性之间是一对一联系。
例：在读者关系中，借书证号是唯一的，如果读者没有重名的，姓名与借书证号两个属性之间是1：1联系。姓名可以确定借书证号，借书证号也可以确定姓名。
如果属性值集合X中的任一个具体值，至多与Y中的一个值相对应，而Y中的任一个具体值却可以和X中的多个值相对应，则称两个属性间从X到Y为m:1的联系或从Y到X是1:m的联系。
注意:这里指的是属性值个数的多少，而不是具有相同属性值的有多少个元组，二者正好相反。
例：在图书关系中，一本书有若干副本，它们有相同的书名、作者、分类号等，但每本书有唯一的总编号。书名与总编号之间是1:m，即同一个书名，有多个总编号与之对应。
在X，Y两个属性值集中，如果任一个值都可以至多和另一个属性值集中多个值对应，反之亦然，则称属性X和Y是m：n关系。
例：在借阅关系中，一个读者可以借多本书，即同一个借书证号有若干个图书总编号与之对应。由总编号标识的一本书在不同日期可以被不同的读者借阅。
数据依赖
是一个关系内部属性与属性之间的一种约束关系
通过属性间值的相等与否体现出来的数据间相互联系
是现实世界属性间相互联系的抽象
是数据内在的性质
是语义的体现
数据依赖的主要类型
函数依赖（Functional Dependency，简记为FD）
多值依赖（Multi-Valued Dependency，简记为MVD）
函数依赖普遍存在于现实生活中
描述一个学生关系，可以有学号、姓名、系名等属性。
一个学号只对应一个学生，一个学生只在一个系中学习
“学号”值确定后，学生的姓名及所在系的值就被唯一确定。
Sname=f(Sno)，Sdept=f(Sno)
即Sno函数决定Sname
Sno函数决定Sdept
记作Sno→Sname，Sno→Sdept
[例6.1] 建立一个描述学校教务的数据库。
涉及的对象包括： 
学生的学号（Sno）
所在系（Sdept）
系主任姓名（Mname）
课程号（Cno）
成绩（Grade）
假设学校教务的数据库模式用一个单一的关系模式Student来表示，则该关系模式的属性集合为：
    U ＝{Sno, Sdept, Mname, Cno, Grade} 

现实世界的已知事实（语义）：
一个系有若干学生， 但一个学生只属于一个系；
一个系只有一名（正职）负责人；
一个学生可以选修多门课程，每门课程有若干学生选修；
每个学生学习每一门课程有一个成绩。  
由此可得到属性组U上的一组函数依赖F：
       F={Sno→Sdept, Sdept→ Mname, (Sno, Cno)→ Grade}

关系模式Student<U, F>中存在的问题：

（1）数据冗余

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

数据冗余 ，更新数据时，维护数据完整性代价大。
某系更换系主任后，必须修改与该系学生有关的每一个元组。
（3）插入异常（Insertion Anomalies）

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

如果某个系的学生全部毕业了， 则在删除该系学生信息的同时，把这个系及其系主任的信息也丢掉了。
结论
Student关系模式不是一个好的模式。
一个“好”的模式应当不会发生插入异常、删除异常和更新异常，数据冗余应尽可能少。
原因
由存在于模式中的某些数据依赖引起的。
解决方法
用规范化理论改造关系模式来消除其中不合适的数据依赖
把这个单一的模式分成三个关系模式：
S(Sno,Sdept,Sno → Sdept);
SC(Sno,Cno,Grade,(Sno,Cno) → Grade);
DEPT(Sdept,Mname,Sdept → Mname);
这三个模式都不会发生插入异常、删除异常的问题，数据的冗余也得到了控制。
问题：  
插入异常：如果没有职工具有8级工资，则8级工资的工资数额就难以插入。
删除异常：如果仅有职工赵明具有4级工资，如果将赵明删除，则有关4级工资的工资数额信息也随之删除了。
数据冗余：职工很多，工资级别有限，每一级别的工资数额反复存储多次。
更新异常：如果将5级工资的工资数额调为1620，则需要找到每个具有5级工资的职工，逐一修改。
6.2 规范化

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

6.2.1  函数依赖

1.函数依赖

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

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

4.传递函数依赖

定义6.1  设R(U)是一个属性集U上的关系模式，X和Y是U的子集。若对于R(U)的任意一个可能的关系r，r 中不可能存在两个元组在X上的属性值相等， 而在Y上的属性值不等， 则称“X函数确定Y”或“Y函数依赖于X”，记作X→Y。
函数依赖与属性间的联系类型有关
(1) 一对一联系：X←→Y
(2) 多对一联系：X→Y
(3) 多对多联系：不存在依赖关系
(4) 可从属性间的联系类型来分析属性间的函数依赖

1. 函数依赖不是指关系模式R的某个或某些关系实例满足的约束条件，而是指R的所有关系实例均要满足的约束条件。

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

    例如“姓名→年龄”这个函数依赖只有在不允许有同名人的条件下成立

3. 数据库设计者可以对现实世界作强制的规定。例如规定不允许同名人出现，函数依赖“姓名→年龄”成立。所插入的元组必须满足规定的函数依赖，若发现有同名人存在， 则拒绝装入该元组。

由下面的关系表, 能否得出Sno → Sname
函数依赖不是指关系模式R的某个或某些关系实例满足的约束条件，而是指R的所有关系实例均要满足的约束条件

X→Y，但Y⊈X则称X→Y是非平凡的函数依赖。
X→Y，但Y⊆X 则称X→Y是平凡的函数依赖。
例：在关系SC(Sno, Cno, Grade)中，
            非平凡函数依赖： (Sno, Cno) → Grade

            平凡函数依赖：     (Sno, Cno) → Sno

                                          (Sno, Cno) → Cno

若X→Y，则X称为这个函数依赖的决定因素（Determinant）。
若X→Y，Y→X，则记作X←→Y。
若Y不函数依赖于X，则记作X↛Y。
在R(U)中，如果X→Y，并且对于X的任何一个真子集X’, 都有 X’ ↛ Y, 则称Y对X完全函数依赖，记作X → Y。
若X→Y，但Y不完全函数依赖于X，则称Y对X部分函数依赖，记作X → Y
在R(U)中，如果X→Y(Y⊈X)，Y↛X，Y→Z，Z⊈Y, 则称Z对X传递函数依赖(transitive functional dependency)。记为：X → Z。
注: 如果Y→X, 即X←→Y，则Z直接依赖于X，而不是传递函数依赖。
[例] 在关系Std(Sno, Sdept, Mname)中，有：
Sno → Sdept，Sdept → Mname，

Mname传递函数依赖于Sno

找出职工工资表中的传递函数依赖。
6.2.2  码

设K为R<U,F>中的属性或属性组合。若K → U，则K称为R的一个候选码(Candidate Key)。
如果U部分函数依赖于K，即K → U,则K称为超码      （Surpkey）。候选码是最小的超码，即K的任意一个真子集都不是候选码。
若关系模式R有多个候选码，则选定其中的一个做为主码(Primary key)。
主属性与非主属性
包含在任何一个候选码中的属性 ，称为主属性          （Prime attribute）
不包含在任何码中的属性称为非主属性（Nonprime attribute）或非码属性（Non-key attribute）
全码：整个属性组是码，称为全码（All-key）
关系模式 R中属性或属性组X 并非 R的码，但 X 是另一个关系模式的码，则称 X 是R 的外部码（Foreign key）也称外码。
SC(Sno,Cno,Grade)中，Sno不是码
Sno是 S(Sno,Sdept,Sage)的码，则Sno是SC的外码
主码与外部码一起提供了表示关系间联系的手段

关系模式S(S# , SN , SD , DEAN , C# , G)

主码：（S#，C#）

函数依赖：

                       （S#，C#）          G

® SN，（S#，C#）       SN
® SD，（S#，C#）        SD
® DEAN， S# ® DEAN
                     （S#，C#）            DEAN

6.2.3  范式

范式是符合某一种级别的关系模式的集合。
关系数据库中的关系必须满足一定的要求。满足   不同程度要求的为不同范式。
范式的种类：               
第一范式(1NF)
第二范式(2NF)
第三范式(3NF)
BC范式(BCNF)
第四范式(4NF)
第五范式(5NF)
各种范式之间存在联系：
某一关系模式R为第n范式，可简记为R∈nNF。
一个低一级范式的关系模式，通过模式分解（schema decomposition）可以转换为若干个高一级范式的关系模式的集合，这种过程就叫规范化（normalization）。
 

6.2.4  2NF

定义6.6  若关系模式R∈1NF，并且每一个非主属性都完全函数依赖于任何一个候选码，则R∈2NF
[例6.4]  S-L-C(Sno,Sdept,Sloc,Cno,Grade)， Sloc为学生的住处，并且每个系的学生住在同一个地方。S-L-C的码为(Sno,Cno)。
       函数依赖有

(Sno,Cno)→Grade
Sno→Sdept, (Sno,Cno)→Sdept
Sno→Sloc, (Sno,Cno)→Sloc
Sdept→Sloc
S-L-C的码为(Sno, Cno)
S-L-C满足第一范式。
非主属性Sdept、Sloc并不完全依赖于码
关系模式S-L-C不属于2NF
一个关系模式不属于2NF，会产生以下问题：
插入异常
如果插入一个新学生，但该生未选课，即该生无Cno，由于插入元组时，必须给定码值，因此插入失败。
删除异常
如果S4只选了一门课C3，现在他不再选这门课，则删除C3后，整个元组的其他信息也被删除了。
修改复杂
如果一个学生选了多门课，则Sdept，Sloc被存储了多次。如果该生转系，则需要修改所有相关的Sdept和Sloc，造成修改的复杂化。
出现这种问题的原因
例子中有两类非主属性：
一类如Grade，它对码完全函数依赖
另一类如Sdept、Sloc，它们对码不是完全函数依赖
解决方法：
用投影分解把关系模式S-L-C分解成两个关系模式
SC(Sno,Cno,Grade)
S-L(Sno,Sdept,Sloc)
SC的码为(Sno,Cno),SL的码为Sno，这样使得非主属性对码都是完全函数依赖了
6.2.5  3NF

设关系模式R<U,F>∈1NF,若R中不存在这样的码X、属性组Y及非主属性Z（Z ⊇ Y）, 使得X→Y，Y→Z成立，Y ↛ X不成立，则称R<U,F> ∈ 3NF。
SC没有传递依赖，因此SC ∈ 3NF

不良特性
插入异常：如果系中没有学生，则有关系的信息就无法插入。
删除异常：如果学生全部毕业了，则在删除学生信息的同时有关系的信息也随之删除了。
更新异常：如果学生转系，不但要修改SDept，还要修改Sloc，如果换Sloc，则该系每个学生元组都要做相应修改。
数据冗余：每个学生都存储了所在系的Sloc的信息。
解决方法
   采用投影分解法，把S-L分解为两个关系模式，以消除传递函数依赖：

            S-D（Sno， Sdept）

                D-L（Sdept，Sloc）

S-D的码为Sno， D-L的码为Sdept。

分解后的关系模式S-D与D-L中不再存在传递依赖
说明
       (1) 每个非主属性既不部分依赖，也不传递依赖于R的任何码。

       (2) 从1NF→2NF：消除非主属性对码的部分函数依赖

       (3) 从2NF→3NF：消除非主属性对码的传递函数依赖

              (4) 从一个表中删去不依赖于主码的数据列。

6.2.6  BCNF

BCNF（Boyce Codd Normal Form）由Boyce和Codd提出，比3NF更进了一步。通常认为BCNF是修正的第三范式，有时也称为扩充的第三范式。
定义6.8  设关系模式R<U,F>∈1NF，若X →Y且Y ⊆ X时X必含有码，则R<U,F>∈BCNF。
换言之，在关系模式R<U,F>中，如果每一个决定属性集都包含候选码，则R∈BCNF。
不良特性
插入异常：如果没有学生选修某位老师的任课，则该老师担任课程的信息就无法插入。
删除异常：删除学生选课信息，会删除掉老师的任课信息。
更新异常：如果老师所教授的课程有所改动，则所有选修该老师课程的学生元组都要做改动。
数据冗余：每位学生都存储了有关老师所教授的课程的信息。