数据库应用系统3-5

数据库应用系统需求分析与规划

第三章

数据库应用系统的总体设计§1总体设计目标和任务§2总体设计的过程§3模块化§4从数据流程图导出结构图§5数据库概念结构设计§6数据库逻辑结构设计§7数据库设计的其它因素§8总体设计阶段文档返回§5数据库概念结构设计

5.1数据库设计过程5.2局部视图设计5.3视图的集成返回5.1数据库设计过程返回根据用户需求研制一个数据库结构的过程称为数据库设计。上图表示了数据库设计过程的输入和输出。

数据库设计员一般信息需求处理要求DBMS说明书操作系统和硬件配置数据库结构应用程序指南数据库设计过程的输入和输出一般信息需求包括数据库系统的目的说明、数据元素的定义以及企业组织中数据元素的使用描述。这些要求并不只限于某些特殊用户，因此，在这个基础上进行的数据库结构设计能适应应用上的变化。处理要求由三个部分组成：每个应用所要求的数据项、数据量（数据项的值的数量）和处理频率。这三部分的每一部分对数据库设计都是十分重要的。另外，在设计过程中还要使用一些其它信息，如DBMS说明书、操作系统和硬件环境说明等。当然，性能约束会对数据库设计产生影响。通常把性能约束看作是需求的一部分。一些典型的约束是指：进行查询的响应时间、系统破坏后的恢复时间以及对安全性和完整性的特殊要求等。数据库设计过程得到的主要结果是完整的数据库结构，以及应用程序员应该遵循的一些原则。返回数据库设计的步骤

数据库设计过程可分为若干阶段或若干步骤：需求分析与数据分析

概念设计

逻辑设计

物理设计

返回物理结构逻辑结构概念结构需求说明与数据说明需求分析与数据分析概念设计逻辑设计物理设计需求分析与数据分析需求分析与数据分析（数据分析也可看作需求分析的一部分）是整个设计过程中最困难的一步。但是，因为以后的各个设计阶段都依赖于这一步，所以它也是最重要的一步。这阶段的主要任务是从所有数据库用户那里收集信息内容和处理要求。需求分析既要保证企业组织的信息流观点的一致性，同时，也要保证用户目标的一致性。返回概念设计概念设计是通过对用户信息需求的综合归纳，形成一个不依赖于DBMS的信息结构的设计。概念设计结果得到的是数据库概念结构，或称概念模型。由于它是从用户世界的角度进行的一种描述，所以不依赖于任何DBMS或硬件环境。

返回逻辑设计逻辑设计得到的数据库结构是DBMS可以处理的数据模型，通常用数据定义语言表示，我们称它为数据库逻辑结构。逻辑设计与概念设计不同，概念设计仅仅是对客观世界的描述，与实现无关；而逻辑设计却与实现有关，依赖于实现的基础DBMS，所以有些书上把这一阶段称为实现设计。

返回物理设计物理设计是选择物理数据库结构，得到一个完整的、可实现的数据库结构。

返回评审检查应该注意，设计过程的每一阶段的末尾，都要进行评审检查。尽可能使设计错误在早期发现并在早期予以纠正。整个设计过程的各阶段也不是完全“线性”发展的，而是迭代式的，逐步求精的，允许重复前面的步骤。

返回第一步第二步第三步第四步5.2局部视图设计

在数据分析基础上，可以使用E－R图作为工具来进行视图设计。所谓视图是反映了某一用户或某一类用户对数据库的要求；或者说，视图是某用户所看到的数据库，因而视图设计所得到的结果是单用户的概念结构。视图设计时，首先要在该用户的应用领域内，确定实体、属性（包括标识码属性及属性间的数据依赖）和实体间的联系。然后用E－R方法来描述所确定的实体、属性和实体间联系。返回实体和属性是相对而言的，很难有截然的界限，某一事物，在一种应用环境中可能作为“属性”出现；在另一种应用环境中可能作为“实体”出现。例如，饭店中的客房，在某种应用环境中，它只是作为“旅客住宿表”实体的一个属性——住宿地点；而在另一种环境中，可能需要考虑客房的面积、设备、价格、当前状态等性质，则它就作为实体出现了。一般来说，凡是能够作为属性的事物就尽量作为属性对待，作为属性的事物不能再具有需要描述的性质或与其它事物具有联系。返回数据流程图作为视图设计的基础数据流程图及其有关的数据说明和处理说明可以作为视图设计的基础。后图是一个数据流图的例子，它描述了中小型饭店的散客入住流程。返回当散客要入住时，必须提交身份证和住宿登记单，在接到入住请求后，首先进行身份证检验，与公安部门协查名单存储文件和黑名单存储文件比较，进行身份证检验，一旦发现有问题，则通知安全保卫部处理，如果身份证检验没有问题，则根据住宿登记单查看是否已订房以及所有符合条件的客房的当前状态和参考价格，这些可以从订房委托书存储文件和客房资料存储文件得到，在分配适当的客房后将结果通知收银员进行预付款收取，旅客登记单数据进入旅客登记存储文件备查，旅客到达数据进入旅客到达单存储文件通知有关人员，旅客分房数据通知客房部并进入客房资料存储文件。返回该数据流图其它部分的含义可以类似地解释。图中还画了“旅客登记单”、“公安部门协查名单”、“黑名单”、“订房委托书”、“客房资料”、“旅客到达单”等存储数据，这些存储数据都应有文档进行说明，这里不再详述。返回散客入住处理的数据流图

返回住宿查询结果检验结果住宿登记单有误住宿数据住宿数据订房数据住宿查询身份证查询黑名单数据协查名单数据住宿登记单身份证旅客登记存储接待员安全保卫部收银员客房部公安部门协查名单黑名单订房委托书旅客到达单客房资料身份证检验住宿登记旅客安全通知来客通知身份证查询结果通知数据应收预付款数据住宿数据住宿数据住宿数据客房数据确定实体、属性和实体间的联系在数据流图基础上我们可以作进一步的分析，以便确定所需的实体、属性和实体间的联系。以“住宿登记”为例，要完成这一步处理，必须涉及“旅客”实体、“客房”实体以及这两实体间的“住宿”联系，它们可以用E－R方法表示为图（a）的形式。当然，旅客可能已经预订了客房，因此又有“旅客”实体、“客房”实体以及这两实体间的“预订”联系，如图（b）所示。返回确定实体、属性和实体间的联系11旅客客房住宿(a)n1旅客客房预订(b)返回视图设计逐步地进行分析和综合，对应于上述数据流图所反映的应用领域，我们可以有下图所示的视图设计。其中每个实体所包含的属性及其说明可以从已经建立的有关文档中得到。返回视图设计旅客客房住宿预订公安部门协查人员黑名单对比对比返回5.3视图的集成

各个视图建立以后，需要对它们进行合并，集成为一个整体的数据概念结构。某一事物在不同视图中作为实体所包含的内容可以是不同的。即实体所包含的属性可以有区别。例如，一个饭店中的“客房”，在视图中可以作为实体，但在前厅部的视图中关心的是“是否已售”、“是否已预订”等属性，而在客房部的视图中所关心的是“是否已打扫”等属性，工程部的视图中所关心的是“是否可用”等属性。而合并以后，“客房”实体必须既包含“是否已售”、“是否已预订”等属性，又包括““是否已打扫””等属性，还要包括“是否可用”等属性。返回前厅部的视图中“客房”实体

客房价格是否已售是否已预订客房号返回客房部和工程部的视图中“客房”实体······客房客房客房号是否已打扫客房号是否可用客房部的视图工程部的视图返回合并后的“客房”实体

客房···客房号价格是否已售是否已预订是否已打扫是否可用返回联系的合并

如果两个实体之间，在一个视图中存在着一种联系，而在另一个视图中存在着另一种联系，那么在合并时，这两种联系都必须保留。例如，在一个饭店里“旅客”与“客房”之间存在着联系，对处理预订的人员来说，关心的是旅客“预订”客房；而对处理入住的人员来说，关心的是旅客“住宿”客房；当然对整个饭店来说，“预订”和“住宿”都需要关心。下图显示了这种合并的过程。合并后的E－R图中，“旅客”与“客房”存在着“预订”和“住宿”的双重联系。

返回联系的合并

(a)处理预订的人员视图中旅客与客房的联系11旅客客房住宿(b)处理入住的人员视图中旅客与客房的联系n1旅客客房预订n111(c)合并后的双重联系旅客住宿预订客房返回消除不一致性

在视图合并过程中，必须消除不一致性和冗余。消除不一致性就得消除同名异义和同义异名。同名异义和同义异名现象可能发生在实体和联系这一级，也可能发生在属性这一级。如果同一事物在不同视图中作为实体，而实体的名字又不一致，那么应该把名字统一，然后进行合并。如果不同事物在不同视图中作为实体，而实体的名字却相同，那么，必须重新命名加以区别。对于实体间的联系也有类似的情况，需要进行类似的处理。在属性一级，同名异义和同义异名更是经常发生。例如，饭店内客房的编号，在不同视图中，可能会有“客房编号”、“客房代码”、“客房编码”、“客房号”等各种名字，也必须加以统一，消除不一致性。

返回消除冗余

在视图合并时，可能存在冗余的数据和实体间冗余的联系。所谓冗余的数据指可以由基本数据导出的数据；冗余的联系是指可由基本联系导出的联系。冗余信息的存在会影响数据库的完整性，给数据库的管理增加困难，应当设法予以消除。

返回消除冗余要根据整体需求进行消除冗余的问题比较复杂，有些冗余信息的存在，虽然对数据库的管理带来不便，但却对提高数据库的效率性能有好处，因而在设计一个实用的数据库过程中，视图合并时，哪些冗余信息必须消除，哪些冗余信息允许存在，这要根据整体需求来确定。例如在一个企业的管理信息系统中，具有“台帐”性质一类的数据往往是冗余的，它们一般不属于基本数据，大多可以由具有“票据单证”性质一类的基本数据导出。例如，“库存帐”是“台帐”数据，可以由“入／出库单”数据导出；“记帐凭证”数据也可以导出各种“台帐”帐本数据。这些“台帐”数据是否消除要视具体系统需求而定。实体间的联系也有类似的情况。

返回验证数据库概念结构

视图合并后形成了一个整体的数据库概念结构，对该整体概念结构必须进