数据库设计(2)

设计一个性能良好的数据库系统，明确应用环境对系统的要求是首要的和基本的。因此，应该把对用户需求的收集和分析作为数据库设计的第一步。

需求分析的主要任务是通过详细调查要处理的对象，包括某个组织、某个部门、某个企业的业务管理等，充分了解原手工或原计算机系统的工作概况及工作流程，明确用户的各种需求，产生数据流图和数据字典，然后在此基础上确定新系统的功能，并产生需求说明书。值得注意的是，新系统必须充分考虑今后可能的扩充和改变，不能仅仅按当前应用需求来设计数据库。

如图1.2所示，需求分析具体可按以下几步进行：

(1)   用户需求的收集。

(2)   用户需求的分析。

(3)   撰写需求说明书。

图1.2  需求分析的过程

需求分析的重点是调查、收集和分析用户数据管理中的信息需求、处理需求、安全性与完整性要求。信息需求是指用户需要从数据库中获得的信息的内容和性质。由用户的信息需求可以导出数据需求，即在数据库中应该存储哪些数据。处理需求是指用户要求完成什么处理功能，对某种处理要求的响应时间，处理方式指是联机处理还是批处理等。明确用户的处理需求，将有利于后期应用程序模块的设计。

调查、收集用户要求的具体做法是：

(1)   了解组织机构的情况，调查这个组织由哪些部门组成，各部门的职责是什么，为分析信息流程做准备。

(2)   了解各部门的业务活动情况，调查各部门输入和使用什么数据，如何加工处理这些数据。输出什么信息，输出到什么部门，输出的格式等。在调查活动的同时，要注意对各种资料的收集，如票证、单据、报表、档案、计划、合同等，要特别注意了解这些报表之间的关系，各数据项的含义等。

(3)   确定新系统的边界。确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。

在调查过程中，根据不同的问题和条件，可采用的调查方法很多，如跟班作业、咨询业务权威、设计调查问卷、查阅历史记录等。但无论采用哪种方法，都必须有用户的积极参与和配合。强调用户的参与是数据库设计的一大特点。

收集用户需求的过程实质上是数据库设计者对各类管理活动进行调查研究的过程。设计人员与各类管理人员通过相互交流，逐步取得对系统功能的一致的认识。但是，由于用户还缺少软件设计方面的专业知识，而设计人员往往又不熟悉业务知识，要准确地确定需求很困难，特别是某些很难表达和描述的具体处理过程。针对这种情况，设计人员在自身熟悉业务知识的同时，应该帮助用户了解数据库设计的基本概念。对于那些因缺少现成的模式、很难设想新的系统、不知应有哪些需求的用户，还可应用原型化方法来帮助用户确定他们的需求。就是说，先给用户一个比较简单的、易调整的真实系统，让用户在熟悉使用它的过程中不断发现自己的需求，而设计人员则根据用户的反馈调整原型，反复验证最终协助用户发现和确定他们的真实需求。

调查了解用户的需求后，还需要进一步分析和抽象用户的需求，使之转换为后续各设计阶段可用的形式。在众多分析和表达用户需求的方法中，结构化分析(Structured Analysis，SA)是一个简单实用的方法。SA方法采用自顶向下，逐层分解的方式分析系统，用数据流图(Data Flow Diagram，DFD)、数据字典(Data Dictionary，DD)描述系统。

1. 使用数据流图分析信息处理过程

数据流图是软件工程中专门描绘信息在系统中流动和处理过程的图形化工具。因为数据流图是逻辑系统的图形表示，即使不是专业的计算机技术人员也容易理解，所以是极好的交流工具。图1.3 给出了数据流图中所使用的符号及其含义。

图1.3  数据流图的符号

 

数据流图是有层次之分的，越高层次的数据流图表现的业务逻辑越抽象，越低层次的数据流图表现的业务逻辑则越具体。在SA方法中，我们可以把任何一个系统都抽象为    图1.4所示的形式。它是最高层次抽象的系统概貌，要反映更详细的内容，可将处理功能分解为若干子功能，每个子功能还可继续分解，直到把系统工作过程表示清楚为止。在处理功能逐步分解的同时，它们所用的数据也逐级分解，形成若干层次的数据流图，如图1.5所示。

图1.4  系统高层抽象图

图1.5  数据流图的建立

为了更好地说明SA方法，下面举一个简单的设计实例。假定某工厂要设计一个数据库查询系统。其中，主管生产的部门要掌握产品的性能、各种零件的用料和每种产品的零件组成情况，并据此编制工厂的生产计划。主管供应的部门需要了解产品的价格、各种零件的用料情况以及这些材料的价格与库存量，并根据这些资料提出材料的采购计划。

在调查、分析用户的业务活动并确定系统边界后，得到了如图1.6和图1.7所示的业务流程图。

根据实际应用环境对系统在功能上进行分解，如图1.8所示。

图1.6  生产部门业务流程图

 

图1.7  供应部门业务流程图

 

图1.8  系统功能的分解

 

在功能分解的同时，不断细化数据流图。这里以“缺料查询”为例，经过需求分析得到如下信息：系统一旦收到缺料查询请求，接受所查询产品的有关数据后，首先要查询单件产品的用料数据，并按产品生产数量算出各种材料的需用量，然后从库存记录中减去这一需用量，即可找出缺料的名称和数量。根据语义，画出相应的数据流图，如图1.9所示。显然，每一种应用需要一张这样的流程图。

图1.9  缺料查询数据流图

2. 使用数据字典汇总各类数据

数据字典是结构化设计方法的另一个工具，它用来对系统中的各类数据进行详尽的描述。对数据库设计来讲，数据字典是进行详细的数据收集和数据分析所获得的主要成果。数据字典中的内容在数据库设计过程中还要不断的修改、充实、完善。

数据字典是各类数据描述的集合，它通常包括以下5个部分。

l          数据项：数据项是数据最小的组成单位。

l          数据结构：是若干数据项有意义的集合。它反映了数据之间的组合关系。

l          数据流：可以是数据项，也可以是数据结构。表示某一处理过程的输入和输出。

l          数据存储：处理过程中存储的数据。常常是手工凭证、手工文档或计算机文件。

l          处理过程。

表1.3是一个数据字典的示例，它描述了缺料查询数据流图(图1.9)中一些数据项。

表1.3  数据字典示例

数 据 项	类  型	长  度	值 范 围
产品名	字符型	20	任何字母和数字
材料名	字符型	10	任何字母和数字
库存量	正整数	5	0～99 999
缺料数量	正整数	5	0～99 999
生产数量	正整数	3	0～999

 

概念结构设计的任务是在需求分析阶段产生的需求说明书的基础上，按照特定的方法把它们抽象为一个不依赖于任何具体机器的数据模型，即概念模型。概念模型使设计者的注意力能够从复杂的实现细节中解脱出来，而只集中在最重要的信息的组织结构和处理模式上。

概念模型具有以下的特点：

l          概念模型是对现实世界的抽象和概括，它真实、充分地反映了现实世界中事物和事物之间的联系，能满足用户对数据的处理要求。

l          由于概念模型简洁、明晰、独立于计算机，很容易理解，因此可以用概念模型和不熟悉计算机的用户交换意见，使用户能积极参与数据库的设计工作，保证设计工作顺利进行。

l          概念模型易于更新，当应用环境和应用要求改变时，容易对概念模型修改和扩充。

l          概念模型很容易向关系、网状、层次等各种数据模型转换。

描述概念模型的有力工具是E-R图。E-R模型是一个面向问题的概念模型，即用简单的图形方式(E-R图)描述现实世界中的数据。这种描述不涉及数据在数据库中表示和存取方法，非常接近人的思维方式。后来又提出了扩展实体联系模型(Extend Entity-Relationship Model)，简称为“EER模型”。EER模型目前已经成为一种使用广泛的概念模型，为面向对象的数据库设计提供了有效的工具。

在E-R模型中，信息由实体型、实体属性和实体间的联系三种概念单元来表示。

实体型表示建立概念模型的对象，用长方形表示，在框内写上实体名。例如学生实体用图1.10表示。

图1.10  学生实体表示方法

实体属性是实体的说明。用椭圆形表示实体的属性，并用无向边把实体与其属性连接起来。例如学生实体有学号、姓名、年龄、性别、出生年月等属性，则其E-R图如图1.11所示。

图1.11  学生实体及其属性

实体间的联系是两个或两个以上实体类型之间的有名称的关联。实体间的联系用菱形表示，菱形内要有联系名，并用无向边把菱形分别与有关实体相连接，在无向边旁标上联系的类型。例如可以用E-R图来表示某学校学生选课情况的概念模型，如图1.12所示。

图1.12  实体、实体属性及实体联系模型图

一个学生可以选修多门课程，一门课程也可以被多个学生选修，因此，学生和课程之间具有多对多的联系。

如果概念模型中涉及的实体带有较多的属性而使实体联系图非常不清晰，可以将实体联系图分成两部分，一部分是实体及其属性图，另一部分是实体及其联系图。如图1.13所示，只给出学生实体与课程实体的联系图，而二者的属性可以单独画出。

图1.13  实体及其联系图