(7.1)--6.1问题的提出数据库原理.pptVIP

问题的提出

关系数据库逻辑设计

针对具体问题，如何构造一个适合于它的数据模式

数据库逻辑设计的工具──关系数据库的规范化理论

问题的提出（续）

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

R(U,D,DOM,F)

关系名R是符号化的元组语义

U为一组属性

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

DOM为属性到域的映射

F为属性组U上的一组数据依赖

由于D、DOM与模式设计关系不大，因此在本章中把关系模式看作一个三元组：RU,F

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

作为二维表，关系要符合一个最基本的条件：每个分量必须是不可分开的数据项。满足了这个条件的关系模式就属于第一范式（1NF）

问题的提出（续）

数据依赖

是一个关系内部属性与属性之间的一种约束关系

通过属性间值的相等与否体现出来的数据间相互联系

是现实世界属性间相互联系的抽象

是数据内在的性质

是语义的体现

问题的提出（续）

数据依赖的主要类型

函数依赖（FunctionalDependency，简记为FD）

多值依赖（Multi-ValuedDependency，简记为MVD）

问题的提出（续）

函数依赖普遍存在于现实生活中

描述一个学生关系，可以有学号、姓名、系名等属性。

一个学号只对应一个学生，一个学生只在一个系中学习

“学号”值确定后，学生的姓名及所在系的值就被唯一确定。

即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}

问题的提出（续）

关系模式StudentU,F中存在的问题：

（1）数据冗余

浪费大量的存储空间

每一个系主任的姓名重复出现，重复次数与该系所有学生的所有课程成绩出现次数相同。

问题的提出（续）

（2）更新异常（UpdateAnomalies）

数据冗余，更新数据时，维护数据完整性代价大。

某系更换系主任后，必须修改与该系学生有关的每一个元组。

问题的提出（续）

（3）插入异常（InsertionAnomalies）

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

问题的提出（续）

（4）删除异常（DeletionAnomalies）

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

问题的提出（续）

结论

Student关系模式不是一个好的模式。

一个“好”的模式应当不会发生插入异常、删除异常和更新异常，数据冗余应尽可能少。

原因

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

解决方法

用规范化理论改造关系模式来消除其中不合适的数据依赖

问题的提出（续）

把这个单一的模式分成三个关系模式：

S(Sno,Sdept,Sno→Sdept);

SC(Sno,Cno,Grade,(Sno,Cno)→Grade);

DEPT(Sdept,Mname,Sdept→Mname);

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

问题的提出（续）