第04讲 关系数据库设计理论.pptVIP

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