数据库结构设计.ppt

主任的姓名和系名与该系的每个学 生所选修的每一门功课的成绩出现的次数 一样多，这将造成存储空间的浪费和维护 代价太高。例如，该系有 100 名学生，每 个学生平均选 30 门课，则该系名和系主 任名要重复 100 x 30＝ 3000次。 这种数据重复存放造成空间浪费称为“数 据冗余”。
一个关系时，就会出现数据冗余和更新异常 等问题。主要表现如下： 1． 数据冗余。 2． 修改异常。 3． 删除异常。 4． 插入异常。
（1）问题的根源

关系的键码函数决定该关系的所有其它 属性。由于键码能唯一确定一个元组， 所以，也可以说关系的键码函数决定该 关系的所有属性。一个关系中的所有属 性都函数依赖于该关系的键码。不同的 属性在关系模式中所处的地位和扮演的 角色是不同的。把键码所在的属性称为 主属性，而把键码属性以外的属性称为 非主属性。
（一）数据库设计概述

数据库设计完全是人的问题，而不是数据 库管理系统的问题。 系统不管一个设计是好是坏，照样运行。 谁设计：在大型多用户共享数据库系统中， 数据库设计应当由数据库管理员和系统分 析员一起负责，和用户一道工作，了解各 个用户的要求，把所有要求合并起来，共 同为整个数据库做出恰当的、完整的设计。


我们可以组成一个关系名为UN 的关系模式：UN（学号，课程， 成绩，系名，系主任） 现实世界的事实告诉我们：

①一个系有若干学生，但一个学 生只属于一个系。 ②一个系只有一名系主任。 ③一个学生可以选修多门功课， 每门课程可有若干学生选修。 ④每个学生学习每门课程有一个 成绩。
当（学号，课程）组合属性值一 定时，也就确定了该学号和课 程对应的成绩、系名、系主任 的属性值，并且有唯一性，所 以（学号，课程）具有记录 （元组）标识作用，是该关系 的主键（关键字）。 这个关系模式在使用中会出现 什么问题呢？
（二）问题的提出



开发一个具体的数据库应用系统时，核心问题是设计数据 库结构，数据库结构的设计好坏是成败的关键所在。 当一个应用系统的数据库结构设计完成之后，就可利用我 们选定的关系数据库管理系统提供的数据定义语言去描述 库结构，即定义关系数据库模式及关系模式。 但是，由于设计者对现实世界的认识或看问题的方法不同， 同一个系统可以设计出不同的关系数据库结构。 那么，我们如何根据设计的对象去构造一个好的关系数据 库结构，即构造几个关系（表）呢？每个关系由哪些属性 组成，好坏如何评价呢？ 为了说明关系模式设计的性能好坏，让我们先看一个例子。 例如，某学校要建立一个学生管理数据库，有如下属性： 学号、系名、系主任、成绩、课程。


（三） 解决办法

上述模式为什么会发 生问题呢？这是因为 关系中属性之间存在 不好的联系。 假如我们把上述模式 改 造 分 解 为 SD，DM 和 SG 三个关系模式， 就会消除上述问题， 从而得到一个好的关 系模式。 三个关系模式如图所 示，下图是三个关系 模式填入数据的实例。


所以， 当我们企图把太多的信息存放在
资源信息系统 数据库原理及设计

同 学 们 好！
数 据 库 结 构 设 计
第 二 讲 ：
希望的田野
本节提要 第二节 资源数据库结构设计



数据库设计的规范化理论 数据库设计一般方法 资源数据库结构设计
一、数据库设计的规范化理论


数据库设计是建立数据库应用系统的核心问题。 设计的关键是如何使设计的数据库能合理地存储 用户的数据，方便用户进行数据处理。本章将对 数据库设计进行讨论，并给出关于如何进行设计 的一些基本理论和原则。 关系数据库：自从提出了关系数据库理论后，许 多专家学者对关系数据库理论进行了深入的研究 和发展，借助于数学工具规定了一整套的关系数 据库设计的理论和方法——函数依赖理论和关系 规范化理论。该理论使关系数据库设计方法走向 完备。
问题的根源（2）

不同的属性对键码函数依赖的性质和程 度是有差别的。有的属于直接依赖，有 的属于间接依赖（通常称为传递依赖）。 当键码由多个属性组成时，有的属性函 数依赖于整个键码属性集，而有的属性 只函数依赖于键码属性集中的一部分属 性。




从上述例子中，我们可以看到，用几个结构简单 的关系去取代原来结构复杂的关系，可有效地消 除“异常”，这种分解过程叫做关系的规范化。 分解时采用了关系规范化理论作指导。一般来说， 通过规范化理论可以把不好的关系数据库模式逐 步转变为一个好的关系数据库模式。 所以，任何一个设计关系数据库的人，都要熟悉 规范化技术与理论，了解规范化理论必须先了解 关系模式中各属性之间的相互函数依赖，因此， 下面将先讨论属性间（字段）的函数依赖关系， 然后讨论关系规范化理论，从而使大家掌握关系 数据库的设计理论，并将其用到具体的关系数据 库设计工作中去。
2. 修改异常

例中，如果要更换系主任，就必须逐一修 改每条记录。若有疏忽，则会造成数据的 不一致性（同一系的学生有不同的系主 任），当然也就破坏了数据的完整性（由 于修改失误，造成数据的不正确），这称 为“修改异常”或称为“潜在的不相容 性”。
3. 插入异常


在关系模式 UN 中，主键是（学号，课程）。 主键的特性不能为空或部分为空，主键为空 或部分为空的记录（元组）不能存入数据库 中，否则，就会因为失去标识而使关系中存 在相同元组，这是关系性质的完整性约束所 不允许的。 例中，如果一个系刚成立，尚无学生，或者 有了学生但还没有选课，我们就无法将该系 的系名和系主任插入到数据库中，这称为 “插入异常”。
4. 删除异常
反过来，如果某个系的学生全部毕业了，我们 删除该系学生及其选课信息的同时，会把系名和系 主任的信息同时删掉。 上述这些问题的出现显然是我们不希望的，因此我 们说，上述关系模式是一个“不好”的关系数据库 模式。“不好”的数据库设计在设计中应该避免。 可见，关系数据库中的各关系不能任意设计，关系 要按一定的要求去设计，如果设计不好，将大量的 字段（属性）放于一个关系模式中，这就使用户的 数据库要忍受着上述几个问题的干扰，运行效率低， 编程和维护工作量大。因此，用户必须对数据库设 计给予高度重视。