数据库讲稿演示第三章.pptVIP

97-10-7 数据库系统基础 97-10-7 构造物理模拟实验室汇报 构造物理模拟实验室汇报 第三章 关系数据库设计理论 一、规范化问题 二、函数依赖 三、关系范式 §3.1规范化问题 数据库是一组相关数据的集合。它不仅包括数据本身，而且包括关于数据之间的联系，即数据模型。给出一组数据，如何构造一个适合的数据模型，在关系数据库中应该组织成几个关系模式，每个关系模式包括那些属性。这是数据库逻辑设计要解决的问题。 §3.2函数依赖 现实世界中的事物是彼此联系，互相制约的。这种联系分为二类，一类是实体与实体之间的联系；另一类是实体内部各属性之间的联系。概念模型和数据模型中讨论实体之间的联系，用数据模型来描述概念模型。函数依赖则是讨论属性之间的联系。 例1：有关系R(职工号，基本工资，奖金)，一个职工号唯一确定一个基本工资数额或一个奖金额，即一个人不能拿两种工资或奖金，但几个人的工资可能相同。 例：设有关系模式选课 SCl(S#，C#，GRADE，CREDIT)其中，S#表示学号，C#表示课程号，GRADE表示成绩，CREDIT表示学分。 在这个选课关系模式中，由于一个学生可以选修多门课程，一门课程可有多个学生选修，因此S#或C#都不能单独确定GRADE。成绩只能由属性组合(S#，C#)来确定。课程学分CREDIT是 C#决定的，CCREDIT。由此可知： (S#，C#)？？GRADE (S#，C#)？？CREDIT §3.3关系范式 范式即模式分解标准。 规范化：一个低一级范式的关系模式，通过模式分解转换为若干个高一 级范式的关系模式的集合，这种过程称为规范化。 设计关系数据库时，关系模式不可以随意建立，它们必须满足一定的规范化要求。一个关系模式满足某一指定的约束，称此关系模式为特定范式的关系模式。满足不同程度的要求构成不同的范式级别。 关系模式有下列几种范式： 第一范式(1NF) 第二范式(2NF) 第三范式(3NF) BCNF 第四范式(4NF) 第五范式(5NF) 例：将下表规范成1NF 本章小结 这一章，介绍了函数依赖的概念，包括函数依赖、完全函数依赖、传递依赖。以函数依赖为基础的关系范式包括第一范式、第二范式、第三范式和BCNF。只有掌握关系数据库设计理论，在数据库设计过程中才能克服盲目性，做到目标明确。在进行关系模式的分解过程中应当注意到分解的无损联接性和保持函数依赖两个问题。要使分解具有无损联接性必须使分解结果满足判定无损分解的法则。否则，分解后不能通过自然联接恢复原来的关系。 2533886（O） 2046543（H） 刘大维 1003 5001287 张伟 1002 7012633（H） 7146688（O） 李明 1001 电话 姓名 职工号 二、第二范式(2NF) 例：设有关系模式 SCl(S#，C#，GRADE，CREDIT)其中CREDIT表示学分。存在函数依赖：(S#，C#)→GRADE， C#→CREDIT，关键字是(S#，C#)。 上述在插入、删除或修改元组时产生的异常与本章开始时所分析的例子类似。在此例中，原因在于关系模式中的非主属性CREDIT函数依赖于组合关键字(S#，C#)的一部分，而不是全部，即(S#，C#)？？CREDIT。 定义3.8 如果关系模式R（U，F）中的所有非主属性都完全函数依赖于任—候选关键字，则称关系R是第二范式的。记为R∈2NF。 将上述非2NF的关系SCl规范化为2NF关系，应设法消除部分依赖。通过投影把它分解为以下两个关系模式：SCl(S#，C#，GRADE)，C2(C#，CREDIT) 三、第三范式(3NF) 例：关系模式Sl(S#，SNAME，D#，DNAME，LOCATION)，关键字是S#，不存在部分依赖，属于2NF。但仍然存在大量冗余，关于系的重复值随着学生的增加而增加。在插入、删除或修改元组时也将产生类似例3的异常情况。分析其原因，由于关系中存在传递依赖S#→LOCATION，（S#→D#，D#→S#，D#→LOCATION）。 定义3.9 如果关系模式R（U，F）中的所有非主属性对任何候选关键字都不存在传递依赖，则称关系只是第三范式的。记为R∈3NF。 通过投影分解将S1分解成如下两个关系后则满足3NF的要求。S(S#，SNAME，D#)，D(D#，DNAME，LOCATION) 必须注意，投影时不能从关系S中遗漏外关键字D#，否则这两个关系之间将失去联 系，就不能通过自然联接再恢复原来的关系了。 由于部分依赖必然是传递依赖，所以如果一个关系模式不存在传递依赖，则必不存在 部分依赖。换言之，满足3NF的关系模式必然满足2NF。 四、规范化小结 规范化的过程是逐步消除关系模式中不合适的数据依赖的过程，使模型中的各个关系