《软件系统开发技术》课件第8章

8.1数据库设计过程8.2实体联系法(ER方法)8.3逻辑记录存取法(LRA方法)习题八一个软件系统必定包括两方面的问题：“数据”以及对数据进行的“加工”。这两个问题贯串整个开发过程(图8.1)：在需求分析阶段既要分析用户的“数据要求”(系统中需维持哪些数据、数据之间有什么联系、数据本身有什么性质等)SL要分析用户的“加工要求”(对数据作什么加工、每个加工的逻辑要求等)；在设计阶段要设计数据的结构也要设计程序模块的结构；在编程阶段也要考虑数据和算法等。当然这两方面不是相互独立的，其间有着密切的联系。8.1数据库设计过程第三章介绍的sA方法在分析和描述“数据要求”方面是不够的，第四章介绍的SD方法只考虑程序模块结构的设计，而不考虑数据结构的设计，所以在开发实际系统时，仅用SA、SD方法是不够的，还需结合一些数据库和数据结构的设计方法。70年代以来，数据库技术已被广泛接受，许多大型数据处理系统中的数据都组织成数据库的形式，所以本章专门讨论为用户建立数据库的方法，作为对第三、四章的补充。图8.1图8.2下面的介绍假定读者已具备数据库系统的基础知识(如参考文献[1])。

某个用户的数据库系统(如银行的数据处理系统)由模式、子模式、应用程序、数据库和数据库管理系统(DBMS)等几部分组成(图8.2)，其中模式、子模式、应用程序等必须根

据用户的具体要求进行分析和设计，这项工作称为“数据库设计”，它的核心问题是如何建立一个数据模式，使其满足下面几个条件：

(1)符合用户的要求，即能正确地反映用户的现实环境，它应包含用户需处理的所有“数据”，并能支持用户需进行的所有“加工”。

(2)能被某个现有的数据库管理系统所接受。

(3)具有较高的质量，如易于维护、易于理解、效率较高等。用“软件生命期”的观点来看待数据库设计的全过程，则可相应地把它分成4个阶段：

(1)分析用户要求。

(2)建立概念性数据模型。

(3)逻辑设计。

(4)物理设计。

前面两个阶段是面向“问题”的，后面两个阶段是面向“解答”的；前两个阶段对应于软件生命期中的分析阶段，后两个阶段对应于设计阶段。第(1)阶段是收集和分析用户的要求。用户要求包括数据要求、加工要求和种种限制条件等。

第(2)阶段是用一个“概念性数据模型”将用户的数据要求明确地表达出来，这一步与软件生命期中建立“系统说明书”相对应。

概念性数据模型是一种面向问题的数据模型，它描写了从用户角度看到的数据库，也反映了用户的现实环境，但与数据库将怎么实现无关。概念性数据模型在用户和设计人员

之间起到了桥梁作用，一方面它是明确地表达用户要求的一个模型，另一方面这个模型是设计数据结构的基础。建立概念性数据模型是数据库设计过程中的一个关键，70年代后期陆续出现了一些适合作概念性数据模型的所谓第二代数据模型，其中ER模型就是一个典型的代表，它们”比第一代数据模型(如网型、层次型、关系型等)更高级，语义表达能力更强。

第(3)、(4)阶段考虑数据库将怎样实现。第(3)阶段逻辑设计是设计数据的结构，它可以同软件生命期中设计阶段的“总体设计”相对应。在这一阶段，我们首先要根据用户要求的特点选购合适的数据库管理系统(D．BMS)，然后根据概念性数据模型以及选购的数据库管理系统的具体特点设计出这个管理系统能够接受的数据模式。本章将着重讨论数据库管理系统是DBTG，型的情况。第(4)阶段进一步设计数据模式的一些物理细节，如文件的基本结构、存取方式、索引的建立等。这一阶段可同软件生命期中设计阶段的“详细设计”相对应。这阶段考虑的主要问题是如何使数据库系统具有较高的效率，所采用的技术与选购的数据库管理系统的具体特点密切有关。

为一个大型的数据处理系统建立数据库是相当艰巨的任务，用户环境中包含的数据项相当多，数据之间又有复杂的关系，设计人员不仅要理解用户的要求，还要了解数据库管理系统的一些特点，所以这一工作必须有一定的方法来指导，70年代以来，随着数据库技术和软件工程技术的发展，出现了不少设计数据库的方法和工具，其中具有代表性的有：

ER．方法、．LRA方法和DBDA．系统等，本章8.2介绍ER方法，8.3介绍LRA方法。8.2.1基本思想

ER方法由P.Chen提出，它适用于设计数据库的第(1)、(2)、(3)阶段。

为一个企业(如银行或工厂)设计数据库的本质是将企业中的有关数据组织成一种具体的形式，这种形式必须同所使用的数据库管理系统的数据模式相符。目前常用的数据库管理系统有关系型、网型和层次型三大类。8.2实体联系法(ER方法)早期的数据库设计方法是直接将企业中的数据设计成关系型、网型、层次型的用户模式(图8.3(a))，这样得到的用户模式并不纯粹是现实世界的描述，而是混入了许多其他的因素，因为：

●设计人员受到具体某个DBMS表达能力的限制，例如有的DBMS很难直接表示多对多的联系；

●设计人员必须考虑存贮结构、存取方式等具体问题；

●为了使系统具有较高的效率，用户模式并不直接与现实相对应，例如现实中“职员”这个对象在用户模式中，可能是用两个记录类型表示的。

所以早期的设计方法存在以下两个问题：

●用户模式难以理解和修改；

●设计人员必须同时考虑许多问题，如用户环境、DBMS的表达能力、存贮结构、效率等，这就使得数据库设计工作难以进行。图8.3

图8.4(b)表示职员和项目之间存在两类联系，“负责”是一个一对多的联系，即每个项目只由一个职员负责，而每个职员可以负责几个项目；“参加”是多对多的联系，即每个职员可以参加多个项目，每个项目可以有多个职员参加。

图8.4(c)表示同一实体类型“零件”中存在着一种联系——“装配”，这个联系是多对多的。

联系也可能存在于三个以上的实体之间，图8.4(应)中的“供应”是存在于商店、设备、项目三个实体类型之间的联系。图8.4

3.属性

实体或联系的性质就是属性，例如职员有工号、姓名、职称、子女名等属性。属性具有值，ER图中可以用圆表示值类型，用实体与值类型间的连线表示属性(图8.5(a))。有的属性可能是多值的，如图8.5(a)中子女名就是多值的属性，因为一个职员可能有多个子女。ER图中在表示属性的连线边上注出N表示多值属性，图8.5(a)说明工号、姓名、职称是

职员的单值属性，而子女名是职员的多值属性。我们可以用某些属性来标识一个实体，例如每个职员的工号是各不相同的，所以就可用工号这个属性来唯一地标识职员。同样，我们可把属性学号作为实体学生的标识码。

联系也可能有属性，例如学生修某门课程所取得的成绩，成绩既不是学生的属性，也不是课程的属性，因为它依赖于某个特定的学生又依赖于某门特定的课程，所以它是学生与课程之间的联系“修”的属性(图8.5(b))。

又如某个职员每周有几天参加某个项目的工作是联系“参加”的属性，而不是职员的属性，也不是项目的属性(图8.5(c))。图8.5

“联系的属性”这个概念对理解数据的语义是非常重要的。

联系可用有关实体的标识码来标识，例如学生的标识码是学号，课程的标识码是课程号，这两个实体间的联系“修”就可用学号和课程号两个属性来标识。

由于人们通常就是用实体、联系和属性这三个概念来理解现实问题的，所以ER模型非常接近人的思维方式。又因为ER模型采用简单的图形来表达人们对现实的理解，所以

不熟悉计算机技术的用户都能够接受它，ER模型目前已成为一种使用较广的概念性数据模型。8.2.3从ER模型导出数据模式

参照下面几条基本规则，可以从描述用户要求的ER图导出DBTG数据库管理系统上的数据模式。

1)两仑实体类型之间一对多的联系：图8.6(a)转换成图8.6(b)，这里，ER图中的实体类型“部门"和“职员"转换成DBTG数据结构图中的记录类型，而联系“从属，，转换成DBTG’中的系。同样图8.6(c)转换成图8.6(z)。.

2)两个实体类型之间多对多的联系：图8.7(a)转换成图8.7(b)，这里，ER图中的实体类型“职员”和“项目”转换成DBTG中的记录类型，联系“参加”不是转换成系，而是转换成一个记录类型，这种记录类型不是实体记录类型(如前面的职员、项目等)而是联系记录类型。同样图8.7(c)转换成图8.7(d)。图8.6图8.7

3)K(K≥3)个实体类型之间的联系：图8.4(d)转换成图8.8，这里可不必考虑联系的类型。

4)一个实体类型上的联系：图8.9(a)转换成图8.9(b)。

应注意的是：上述转换规则是通常所使用的，但并不是唯一的规则，从同一ER图可以导出几种不同的DBTG模式。

从ER图也很容易导出关系型数据模式：只须将ER图中的每一个实体和联系都转换成关系型模式中的一个关系就可以了。.图8.8图8.98.2.4步骤

用ER方法设计数据库的基本步骤是：

(1)确定实体类型。

(2)确定联系类型。

(3)画ER图。

(4)确定属性。

(5)从ER图导出数据结构图。

(6)设计记录格式。下面以一个工厂管理系统的数据库为例，说明这。一过程。

1.确定实体类型

通过调查了解到该工厂中需要管理的实体类型有零件、商店、项目、职员、部门、仓库等等。

2.确定联系类型

在这个系统中，以下这些联系是同管理有关的：

·部门和职员之间有个联系“从属”，它是一对多的；

·项目和职员之间有个联系“负责”，它是一对多的；

·项目和职员之间还有个联系“参加”，它是多对多的；

·项目、商店和零件之间有个三元联系“供应”，它是多对多的；

·零件和商店之间有个联系“将供应”，它是多对多的；

·零件和仓库之间有个联系“存贮”，它是多对多的；

·零件这个实体类型上有个联系“装配”，它是多对多的。

3.画ER图

对于比较复杂的例子，ER.图可以采用简化的形式，即用方框表示实体，用方框之间的直线段表示联系，属性则不在图中画出而另用文字(或表格)作出说明。

本例中用这种简化的表达方式将前两步确定的实体和联系画出则得图8.10(a)。

4.确定属性

经调查了解到：部门有部门号、今年预算、去年预算等3个属性；职员有工号、姓名、职称、工龄4个属性；项目有编号、项目名、预算3个属性；……。又了解到：联系“供应”有供应号、地点、数量等属性；“存贮”有数量这个属性；“从属”有“进入本部门日期”、“参加”有“每周工作几天”等属性。上述实体和联系的属性可用表8.1的表格说明，表格中还应指出每个属性的值类型，为简单起见，表8.1中省略了这一部分。

至此为止，我们获得了描述工厂管理这一用户环境的概念性数据模型。

5.从ER图导出DBTG数据结构

参照8.2.3的4条基本规则，从图8.10(a)的ER图导出图8.10(6)的数据结构图。

6.设计记录格式

设计记录格式时可以参考以下几条原则：

1)将一个实体的所有属性放在同一记录类型中，例如部门的所有属性(部门号、今年预算、去年预算)都处理成部门这个记录类型中的数据项(图8.11)。

2)如果联系是一对多的，则联系的属性处理成系的成员记录类型中的数据项，如部门和职员间的联系“从属”是一对多的，所以“从属”的属性“进入本部门日期”处理成职

员记录类型中的数据项(图8.11)。图8.10图8.11

3)如果某个联系转换成一个联系记录类型，则联系的属性处理成这个记录类型中的数据项，如职员和项目之间的联系“参加”转换成一个记录类型，所以“参加”的属性“每周工作几天”处理成记录类型“参加”中的数据项(图8.11)。

这样，我们就确定了数据结构图中有哪些记录类型和系类型，也确定了每个记录类型中有哪些数据项，DBTG型数据模式的逻辑设计就完成了。对于大型复杂的系统，直接获得整个系统的ER模型可

能会困难，此时ER方法可按以下三步进行(图8.12)：

1)为每个应用建立一个局部ER模型，即将每个应用所

需的数据画成一张局部ER图。

2)将局部ER模型综合成一个整体ER模型，此时必须注意发现各个局部模型之间的不一致性，如命名冲突等，还应去除冗余的信息。

3)从整体ER．模型导出DBTG的数据结构图。

假定前面讨论的工作管理系统有3个应用，第1个应用关心的是部门、职员、项目等对象，以及其间的“从属”、“参加”等联系。第2个应用关心的是仓库、零件及其间的联系“存贮”、“装配”等。第3个应用关心的是商店、项目和零件等对象及其间的联系“供应”。我们可以按照上述3步为这个系统设计数据库：先为每个应用分别建立局部ER模型(图8.13(a)、(b)、(c))，然后将3个局部ER模型综合成整体ER模型(图8.10(a)，假定这3个局部模型之间没有不一致性)，最后从整体ER模型导出DBTG，型数据结构图(图8.10(b))。[小结]

实际使用中已经证明了ER方法是非常有效的，它的优点是：

(1)将数据库设计过程分为两步(图8.3(b))，相对地说，每一步都比较简单更易于进行了。由于第一步得到的企业模式纯粹是现实世界的反映，而与DBMS的特点无关，所以它比用户模式更易理解、更易维护、也更稳定。

(2)ER模型是很自然又很简单的图形表示，所以容易被人们接受(包括用户和软件人员)，它可以作为企业管理人员和软件人员之间有效的交流工具。图8.12图8.13建立了数据模式之后，如果发现数据库系统的性能尚不能满足用户的要求，则需要对数据模式进行优化，即适当地修改、调整数据模式的结构，使数据库系统的效率得以提高。

对数据模式进行优化，需要解决下面两个问题：

(1)如何衡量数据库系统的效率，需要有具体的评价标准。

(2)如何对数据模式进行修改，以获得一些候选方案。8.3逻辑记录存取法(LRA方法)8.3.1数据库系统性能的评价标准

LRA(LogicalRecord.Access)方法由美国密执安大学的T.Teorey和J.Fry提出，它适用于对DBTG型或层次型数据模式进行比较和评价。

LRA方法提出以LRA、TV和SS这三个数量作为比较数据库系统性能的标准，下面分别讨论这三个量。

1.LRA(I,ogicallRecordAccess)

它是指单位时间内所需存取的逻辑记录个数。

第i个应用每执行一次所需存取的逻辑记录个数是：

这里LRAij是第i个应用每执行一次所需存取的第j个记录类型的逻辑记录个数，N是数据库中的记录类型数。所以单位时间内所有应用需存取的逻辑记录总数是：

这里FREQi是第i个应用的执行频率，即单位时间内这个应用要执行几次，似是应用的个数。

2.TV(TransportVolume)

是指单位时间内所需存取的数据量(字节数)。.

第i个应用每执行一次所需存取的数据量是：这里RECSIZE歹是第歹个记录类型的长度(字节数)。所以单位时间内所有应用需存取的数据量总数是：

3.SS(StorageSpace)它是指数据库所占的存贮空间，包括两部分：一部分是数据所占的空间，另一部分是指针所占的空间。数据所占的空间是’这里NREC歹是第歹个记录类型的记录个数。指针所占的空间是：这里NRTRj是第j个记录类型包含的指针数，PTRSIZE是指针的长度(字节数)。由于数据的逻辑结构与物理结构存在着差别，LRA、TV与SS这三个量并不能精确地估计数据库系统的物理性能，它们只能用来比较几个模式的相对性能(如果这几个模式的存取方式是相似的)，LRA、TV和SS的值越小，则可认为这个模式的性能越好。8.3.2计算表格

LRA方法就是用表8.2的表格计算一个数据库系统的LRA、TV和SS。其计算过程如下：

(1)在应用和频率这两列，分别填入每个应用的名称和执行频率。

(2)根据每个应用的具体操作，估算出它每次需存取多少个逻辑记录，将结果填入LRAij并将总个数填入第4列。

(3)将总个数乘以该应用的执行频率则得出单位时间内每个应用需存取的逻辑记录总个数，将结果填)LRAi。

(4)按LRA巧及记录的长度算出TVi。

(5)将LRAi这一列相加则得LRA，将TVi这一列相加则得TV，SS可按8.3.1中的公式直接算出。在计算过程中往往可以发现有些应用的LRAi或TVi明显地比其他应用大得多，我们称这些应用为“主应用”。找到主应用就是找到了主要矛盾，只要能减少主应用的LRAi和

TVi，整个系统的LRA和TV就会大大减少，所以对模式的修改围绕着与主应用有关的一些数据结构来进行将是最有效的。8.3.3步骤

运用LRA方法的过程是反复执行下面2步：

(1)对某个数据模式和一组应用，用8.3.2的计算表格计算出LRA、TV和SS等三项指标，并找出主应用。

(2)以减少主应用的LRA.i或TVi为目标，对数据模式的某些部分作适当修改，得到数据模式的另一个候选方案。

使用LRA方法带有较大的试探性，一般要经过多次修改、计算，并对各种可能的候选方案作反复比较后，才能获得性能较好的数据模式。

8.3.5将给出使用LRlA方法的实例。8.3.4数据模式的改进

为了使数据库系统具有更好的性能，需要对数据模式作适当的修改。本节以DBTG型数据模式为例，讨论几种常用的手段。

1.垂直分割

图8.14(a)中，职员记录为工号、姓名、职称、住址、电话、工资等数据项，如果经常需要存取的只是工号、姓名和职称等3项，而住址、电话等用得很少，此时可将这个记录

类型垂直分割成两个记录类型(图8.14(b))，这就减少应用程序存取的数据量。

2.水平分割

图8.15(a)的学生记录类型中包括有本科生和研究生两类，如果有的应用只关心本科生而不关心研究生，有的应用只关心研究生而不关心本科生，此时可将学生这个记录类型

水平分割成本科生和研究生两个记录类型(图8.15(b))，这也将减少应用程序存取的记录个数。图8.14图8.15图8.16

3.将重复组扩充成系

图8.16(a)的职员记录中有一个重复组(子女名和子女年龄)，如果将它改成图8.16(b)的结构，即将重复组扩充成系，则可减少某些应用程序存取的数据量。

4.将系压缩成重复组

如果将图8.16(b)的结构改为图8.16(a)的结构，即将系压缩成重复组，则可减少某些应用程序存取的记录个数。图8.17

5.建立新的系

图8.17(a)中，如果有些应用是根据职称来查找职员，此时建立一个新的系(图8.17(b))，则可减少这些应用程序存取的记录个数。

应该注意的是，一个数据库系统要支持多个应用，对数据模式作了某些修改后，某个应用的存取记录个数或数据量可能减少了，但其他应用的这些指标则可能增加，一般说来，我们应优先考虑主应用及一些要求快速响应的应用(如在线的应用)；此外，LRA、TV、SS等指标也可能是相互冲突的，如为了减少LRA，TV却可能要增加一些，或者SS要增加一些，所以设计人员必须根据具体情况，全面地作出权衡和决策。8.3.5实例——生产管理系统

某公司要建立一个对其下属工厂进行管理的系统，该公司有50个下属工厂，分布在40个地区，职工人数共100000人。每个工厂有许多个工作站，工作站总数为500个。日常生产中有20种不同类型的工种。每个职工一天内可在不同的工作站完成几件不同类型的工作。另外，有5个社会团体，每个工人都参加其中的一个团体。管理系统要支持以下这些应用：

T1：新职工进入工厂时，向系统输入姓名、住址、出生年月、工厂名、团体名、工号和当天的日期。

T2：职工离职时，向系统输入姓名、工号、当天日期、系统将离职人员的记录存到另一个专门的文件中去。

T3：职工每完成一件工作，向系统输入工号、工作站号、工种类型、日期和小时数。

T4：工资调整时，修改职工的记录。

R1：每季度为每个团体产生一份报告，列出本季度该团体的成员数、总的工作时数和总收入，还要为每个团体提供一张清单，列出成员姓名、住址、工作天数、本季的平均月薪。

R2：每年为每个地区产生一份报告，列出居住在该地区的职工姓名、总收入。

R3：每月为每个地区产生一份报告，列出在该地区的工厂名、本月进入的新职工数，离职人数，以及本月最后一天的职工数。

R4：每月给公司经理一份各工厂的情况报告，列出工厂名、总工作时数、总工资收入，以及每个工厂每一种工种的工作时数、工种描述。

R5：每天给公司经理一份报告，列出职工姓名、每一工种的工作时数、每一工作站的工作时数。

R6：为每个职工产生月工资单，列出姓名、住址和工资。

R7：人事部门需进行在线查询：某一职工(给出姓名)今年的工作天数、收入和工作时数。

我们可以先用ER方法设计出初始的数据模式。初始模式经过以下3步获得：

1)为每个应用建立局部ER模式，共得11个局部模式，图8.18(a)和(b)分别是应用T2和R5的局部模型。图8.18

2)将11个局部ER模型综合成整体ER模型(图8.18(c))。

3)从图8.18(c)导出DBTG。型数据模式(图8.18(d))。表8.3是其中每个记录类型包含的数据项及其长度。

下面我们用LRA方法对图8.18(d)的数据模式进行优化。

先用表8.2的计算表格计算数据模式图8.18(d)的LRA、TV和SS等三项指标，结果列在表8.4。这里我们假定每个记录类型的存放方式都是CALC型，每个系用一个向前指

针实现，每个指针占4个字节，并以“天”作为单位时间。从表8.4看出，T3和R5的LRAi和TVi最大，所以它们可看作是主应用。另外，因为R7是在线的查询，需要快速响应，所以也需引起注意，其他应用则处于次要的地位。数据存贮空间=11.63×106字节指针空间=4.01l×106字节总空间=15.64×l06字节注：每年工作240天

数据存贮空间＝l2.43×l06字节指针空间=3.2l×l06字节总空间=l5.64×l06字节

为了降低T3、R5和R7的LRAi和TVi可以对图8.18(d)的数据模式作下列改进：

1)记录“工作站”的字长仅