软件工程案例开发与实践 第7章 数据库设计

1、第7章 数据库设计/数据库设计环境一般有两种情况： （1）软件（DBMS）和硬件未确定的情况，这样的环境只能从用户的应用环境出发，先进行数据库设计然后再提出软件(包括DBMS)需求和硬件需求； （2）计算机软件与硬件环境以及DBMS已经确定，在此环境下进行数据库设计工作。这种情况属于普遍情况。/7/1 数据库设计概述/数据库设计的重要性 (1) 数据库设计直接影响软件编程质量， 从而导致开发走很多不应该走的弯路/ 反过来讲， 如果设计的好，可以提高软件编程效率/ (2) 数据库设计的好与差直接影响系统的维护性能。/***结构分析 数据流图 数据字典/7/2 需求分析阶段的设计/7/3 概念设计阶

2、段/6/3/1 概念模型的表示方法 通常我们用E-R图来表示数据库的概念模型。E-R图的构成要素为：实体、属性和联系。在E-R图中的基本图形符号为：/例子/如果要表示图书实体的属性关系如图6-2（a）所示的E-R图；要表示作者实体的属性关系如图6-2（b）所示的E-R图；要表示作者实体与图书实体之间联系如图6-2（c）所示的E-R图。/7/3/2 E-R图的绘制步骤/1/ 进行数据分析与抽象，确定实体、属性和联系。 2/ 设计局部E-R图，也称用户视图。 3/ 综合各局部E-R图，形成总的E-R图，即用户视图的集成。/1数据分析与抽象/数据抽象方法 ： （1）分类。定义某一类概念作为现实世界中

3、一组对象的类型，这些对象具有某些共同的特性和行为，它抽象了对象值和型之间的“is member of”的语义，在E-R模型中，实体型就是这种抽象。 （2）***。定义某一类型的组成成分，它抽象了对象内部类型和成分之间“is part of”的语义，在E-R模型中若干属性的***组成了实体型，就是这种抽象。 （3）概括。定义类型之间的一种子集联系，它抽象了类型之间的“is subset of”的语义，概括有一个很重要的性质：继承性。子类继承超类上定义的所有抽象（图6-3）。/图6-4 子类继承超类/如何抽象实体和属性/区分实体与属性一般原则是： 实体：是一个有着一系列显著的、易辨认的属性的客观对象。

4、现实世界中一组具有某些共同特性和行为的对象就可以抽象为一个实体。对象和实体之间是“is member of”的关系。 属性：对象类型的组成成分可以抽象为实体的属性。组成成分与对象类型之间是“is part of的关系。例：学号、姓名、专业、年级等可以抽象为学生实体的属性。其中学号为标识学生实体的码。/例子/职称通常作为教师实体的属性，但在涉及住房分配时，由于分房与职称有关，也就是说职称与住房实体之间有联系，这时把职称作为实体来处理会更合适些（图6-5）。/例子/仓库，货物和职工，货物存放在仓库，职工管理仓库。所以仓库，货物和职工分别作为实体比较好（图6-6）。/例子/教学管理系统应对学校中的教

5、师，学生，课程进行管理， 掌握课程设置和教师配备情况以及学生成绩的管理。 通过需求分析后， 可知该系统涉及的实体包括： 教师、系、学生和课程。 对于每一个实体集， 根据系统输出数据的要求， 抽象出如下的实体与属性： ）系（系号，系名，专业，职称，性别，年龄） ）教师（教师号，姓名，性别，出生日期，专业） ）学生（课程号， 课程名，学时，类别）/2确定局部E-R图/对于学校来说，作为一个系统内的实体集， 这些实体间并不完全相互***， 而存在一定联系， 我们对实体间的联系进行分析： 假定在一个学校内：1个系有多名教师， 而一个教师只能属于一个系， 因此系和教师之间是1对多的关系；1个系有多名学生，

6、 而一个学生只能属于一个系， 因此系和学生之间是1对多的关系；1个教师可以讲多门课程， 而一个课程可以由多个学生讲， 因此课程和教师之间是多对多的关系；1个学生可以选修多门课程， 而一门课程师可以被多个学生选修， 因此学生和课程之间是多对多的关系； 局部的E-R图如图6-7和图6-8 所示。/3全局E-R图的集成/（1）一次集成 一次集成多个分E-R图，通常用于局部视图比较简单的情况下。 （2）逐步累积式 首先集成两个局部视图（通常是比较关键的两个局部视图），然后每次将一个新的局部视图集成进来。 （3）首先设计各个局部E-R图，最后整理合并成一个完整的全局E-R图（图6-9）。/在合并局部E-

7、R图时需要注意如下几点：/（1）消除不必要的冗余实体、属性和联系。 例6-7 冗余属性。 教师工资单中包括该教师的基本工资、各种补贴、应扣除的房租水电费以及实发工资。由于实发工资可以由前面各项推算出来，因此可以去掉，在需要查询实发工资时根据基本工资、各种补贴、应扣除的房租水电费数据临时生成。 例6-8 冗余属性。 学生实体中的年龄属性可以由出生日期推算出来，属于冗余数据，应该去掉。这样不仅可以节省存储空间，而且当某个学生的出生日期有误，进行修改后，无须相应修改年龄，减少了产生数据不一致的机会。 学生：学号，姓名，出生日期，所在系，年级，平均成绩 例6-9 冗余属性。 学生实体中的平均成绩可以从

8、选修联系中的成绩属性中推算出来。/（）解决各分E-R图之间的冲突。 属性冲突： 属性冲突有两类 ：属性域冲突和属性值冲突。 A）属性域冲突是指属性值的类型、取值范围或取值***不同。 例6-11 属性域冲突。 对于学生来讲，由于学号是数字，因此某些部门（即局部应用）将学号定义为整数形式，而由于学号不用参与运算，因此另一些部门（即局部应用）将学号定义为字符型形式。 例6-12 属性域冲突。 某些部门（即局部应用）以出生日期形式表示学生的年龄，而另一些部门（即局部应用）用整数形式表示学生的年龄。 B）属性值冲突指属性取值单位在不同的E-R图中表示不一致。 例6-13 属性值冲突学生的身高，有的以米为

9、单位，有的以厘米为单位，有的以尺为单位。/2）命名冲突 命名冲突有两类：同名异义和异名同义。 A）同名异义：不同意义的对象在不同的局部应用中具有相同的名字 例6-14 同名异义。 局部应用C将教室称为房间 ，局部应用D中将学生办公室称为房间 。 B）异名同义（一义多名）：同一意义的对象在不同的局部应用中具有不同的名字 。 例6-15 异名同义。 -局部应用A中将宿舍成为寝室，局部应用B将宿舍称为房间。 -有的部门把教科书称为课本 ，有的部门则把教科书称为教材 。命名冲突可能发生在属性级、实体级、联系级上。其中属性的命名冲突更为常见。/3）结构冲突 结构冲突有三类： A)同一对象在不同应用中具有

10、不同的抽象。例如课程在某一局部应用中被当作实体，而在另一局部应用中则被当作属性。 B) 同一实体在不同局部视图中所包含的属性不完全相同，或者属性的排列次序不完全相同。 C) 实体之间的联系在不同局部视图中呈现不同的类型。/例6-16 同一对象在不同应用中具有不同的抽象。 “课程”在某一局部应用中被当作实体 ，在另一局部应用中则被当作属性 。解决方法：通常是把属性变换为实体或把实体变换为属性，使同一对象具有相同的抽象。变换时要遵循两个准则。 例6-17 同一实体在不同局部视图中所包含的属性不 完全相同，或者属性的排列次序不完全相同。 解决方法：使该实体的属性取各分E-R图中属性的并集，再适当设计

11、属性的次序。 产生原因：不同的局部应用关心的是该实体的不同侧面。/把图6-12，6-13，6-14中，实体“学生”在不同的局部E-R中属性不完全相同，合并后为图6-15 。/（3）根据情况修改或重构E-R图 局部E-R图经过合并生成的是初步E-R图。之所以称其为初步E-R图，是因为其中可能存在冗余的数据和冗余的实体间联系，即存在可由基本数据导出的数据和可由其他联系导出的联系。冗余数据和冗余联系容易破坏数据库的完整性，给数据库维护增加困难，因此得到初步E-R图后，还应当进一步检查E-R图中是否存在冗余，如果存在，应设法予以消除。修改、重构初步E-R图以消除冗余，主要采用分析方法。除此外，还可以用

12、规范化理论来消除冗余。/例6-5中 局部图6-7，6-8集成后的全局的E-R图见图6-17 所示。/7/4 逻辑设计阶段/逻辑设计阶段的任务是设计数据库的逻辑结构， 将概念结构转换为某个DBMS所支持的数据模型（例如关系模型），并对其进行优化。 在此期间应该选择最适于描述与表达相应概念结构的数据模型，然后选择最合适的DBMS。/7/4/1 逻辑模型的转换规则/1 一个实体型转换为一个关系模式。 例如：以上个单元的教学管理系统的E-R图为基础，有如下的关系模式： ）系（系别号，系名，专业， 系主任的教师号） ）教师（教师号，姓名，性别，出生日期，所在系别号，职称，职务） ）学生（学号，姓名，出生

13、日期，籍贯，性别，课程号， 系别号，专业） 4）课程（课程号，课程名，任课教师号）/2对于实体间的联系则有以下不同的情况 （1）1：1联系。 1）转换为一个***的关系模式。 例如：一个国家只有一个国旗，一个国旗只对应于一个国家，它们是一多一关系，它们的联系名是“对应”关系，转换为一个***的关系模式，有如下的关系模式： 对应（国家名，国旗名） 2）与任意一端对应的关系模式合并。 例如：比如把联系加到 “国旗”端，有如下的关系模式： 国旗（国旗名，颜色，设计人，启用日期，国家名）/（2）一个1：N联系可以转换为一个***的关系模式，也可以与N段对应的关系模式合并。 如果转换为一个***的关系模式，则与

14、该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为N端实体的码。 1）1端和n端分别可以转换为一个***的关系模式，然后与这2个实体的“联系”相连的各实体的关键字以及联系本身的属性也转换为一个关系的属性，而此关系的关键字为n端实体的关键字。 。 2）也可以与n端对应的关系模式合并为一个关系模式。 （3）一个M/N联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。/（4）三个或三个以上实体间的一个多元联系可以转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码

15、的组合。多元关系的外模式通过对这些基本的实体建立有效的视图模式得到。 （5）实体分类的关系模式可通过在子类中加入父类（超类）码。 （6） 概括类的分类通过垂直分解成几张数据库表，在通过联结得到所需的语义实体。 （7）***的转换：通过引入基本表进行转换。 （8）具有相同码的关系模式可合并：形成了一般的数据模型后，下一步就是向特定的RDBMS的模型转换。 3同一实体集的实体间的联系，即自联系，也可按上述1/1、1/n和m/n三种情况分别处理。/7/4/2 模式转换示例/这个E-R图中有四个实体：系，学生，教师，课程。 （1）系和学生，1：1关系。 （2）系和教师，1：N关系。 （3）教师和课程，N

16、：M关系。 （4）学生和课程，N：M关系。/按照前面的转换规则把E-R图转换为数据库的关系模式如下（下画线的是主键）： （1）系（系别号，系名，专业， 系主任的教师号） 主键：系别号 。 （2）教师（教师号，姓名，性别，出生日期，系别号，职称，职务，讲授的课程号） 主键：教师号 ， 外键：系别号。 （3）学生（学号，姓名，出生日期，籍贯，性别，选修的课程号， 系别号，专业，注册时间） 主键：学号 ，外键：系别号。 （4）课程（课程号，课程名，教师号） 主键：课程号，外键：教师号。 （5）注册（系别号，学号，注册时间） 主键：系别号，学号。/例子/7/2/2数据字典示例/下面以实例说明数据字典的应用。 （1）数据流条目： 例如， 某图书管理系统，其功能包括图书的购入、借阅、归还和注销。 在此系统中，入库单、借书单、还书单、注销单等都是数据流，现对“借书单”说明如下： 借书单=读者编号+分类目录号+借阅日期 （2）数据存储条目 在上例的图书管理系统中，“读者文件”是个数据存储，对它说明如下： 文件名：借书单 组成：读者编号+姓名+所在部门 数据存储***：按读者编号递增顺序排列 存储方式：关键码/（3）一些特殊联系的处理，可分为以下几情况： 当一个实体的存在是依赖于另一个实体的存在时，两个实体之间的联系便代表了两个实体间的一种所有关系。 当联系定义在同

免责声明：
1. 《软件工程案例开发与实践 第7章 数据库设计》内容来源于互联网，版权归原著者或相关公司所有。
2. 若《86561825文库网》收录的文本内容侵犯了您的权益或隐私，请立即通知我们删除。