[第四章第二讲数据库结构设计.ppt

本节提要 数据库设计的规范化理论 数据库设计一般方法 资源数据库结构设计 一、数据库设计的规范化理论 数据库设计是建立数据库应用系统的核心问题。设计的关键是如何使设计的数据库能合理地存储用户的数据，方便用户进行数据处理。本章将对数据库设计进行讨论，并给出关于如何进行设计的一些基本理论和原则。 关系数据库：自从提出了关系数据库理论后，许多专家学者对关系数据库理论进行了深入的研究和发展，借助于数学工具规定了一整套的关系数据库设计的理论和方法——函数依赖理论和关系规范化理论。该理论使关系数据库设计方法走向完备。 数据库设计完全是人的问题，而不是数据库管理系统的问题。 系统不管一个设计是好是坏，照样运行。 谁设计：在大型多用户共享数据库系统中，数据库设计应当由数据库管理员和系统分析员一起负责，和用户一道工作，了解各个用户的要求，把所有要求合并起来，共同为整个数据库做出恰当的、完整的设计。 （二）问题的提出 开发一个具体的数据库应用系统时，核心问题是设计数据库结构，数据库结构的设计好坏是成败的关键所在。 当一个应用系统的数据库结构设计完成之后，就可利用我们选定的关系数据库管理系统提供的数据定义语言去描述库结构，即定义关系数据库模式及关系模式。 但是，由于设计者对现实世界的认识或看问题的方法不同，同一个系统可以设计出不同的关系数据库结构。 那么，我们如何根据设计的对象去构造一个好的关系数据库结构，即构造几个关系（表）呢？每个关系由哪些属性组成，好坏如何评价呢？ 为了说明关系模式设计的性能好坏，让我们先看一个例子。例如，某学校要建立一个学生管理数据库，有如下属性：学号、系名、系主任、成绩、课程。 我们可以组成一个关系名为UN的关系模式：UN（学号，课程，成绩，系名，系主任） 现实世界的事实告诉我们： ①一个系有若干学生，但一个学生只属于一个系。 ②一个系只有一名系主任。 ③一个学生可以选修多门功课，每门课程可有若干学生选修。 ④每个学生学习每门课程有一个成绩。 当（学号，课程）组合属性值一定时，也就确定了该学号和课程对应的成绩、系名、系主任的属性值，并且有唯一性，所以（学号，课程）具有记录（元组）标识作用，是该关系的主键（关键字）。 这个关系模式在使用中会出现什么问题呢？ （1） 数据冗余 每个系主任的姓名和系名与该系的每个学生所选修的每一门功课的成绩出现的次数一样多，这将造成存储空间的浪费和维护代价太高。例如，该系有100名学生，每个学生平均选 30门课，则该系名和系主任名要重复 100 x 30＝ 3000次。 这种数据重复存放造成空间浪费称为“数据冗余”。 2. 修改异常 例中，如果要更换系主任，就必须逐一修改每条记录。若有疏忽，则会造成数据的不一致性（同一系的学生有不同的系主任），当然也就破坏了数据的完整性（由于修改失误，造成数据的不正确），这称为“修改异常”或称为“潜在的不相容性”。 3. 插入异常 在关系模式UN中，主键是（学号，课程）。主键的特性不能为空或部分为空，主键为空或部分为空的记录（元组）不能存入数据库中，否则，就会因为失去标识而使关系中存在相同元组，这是关系性质的完整性约束所不允许的。 例中，如果一个系刚成立，尚无学生，或者有了学生但还没有选课，我们就无法将该系的系名和系主任插入到数据库中，这称为“插入异常”。 4. 删除异常 反过来，如果某个系的学生全部毕业了，我们删除该系学生及其选课信息的同时，会把系名和系主任的信息同时删掉。 上述这些问题的出现显然是我们不希望的，因此我们说，上述关系模式是一个“不好”的关系数据库模式。“不好”的数据库设计在设计中应该避免。 可见，关系数据库中的各关系不能任意设计，关系要按一定的要求去设计，如果设计不好，将大量的字段（属性）放于一个关系模式中，这就使用户的数据库要忍受着上述几个问题的干扰，运行效率低，编程和维护工作量大。因此，用户必须对数据库设计给予高度重视。 （三） 解决办法 上述模式为什么会发生问题呢？这是因为关系中属性之间存在不好的联系。 假如我们把上述模式改造分解为SD，DM和SG三个关系模式，就会消除上述问题，从而得到一个好的关系模式。 三个关系模式如图所示，下图是三个关系模式填入数据的实例。 所以，当我们企图把太多的信息存放在一个关系时，就会出现数据冗余和更新异常等问题。主要表现如下： 1．? 数据冗余。 2．? 修改异常。 3．? 删除异常。 4． 插入异常。 （1）问题的根源 关系的键码函数决定该关系的所有其它属性。由于键码能唯一确定一个元组，所以，也可以说关系的键码函数决定该关系的所有属性。一个关系中的所有属性都函数依赖于该关系的键码。不同的属性在关系模式中所处的地位和扮演的角色是不同的。把键码所在的属性称为主属性，而把键码属性以外