数据库设计理论及应用（3）——需求分析及数据流图

作者：最后一只恐龙 发表时间：2007-6-26

该系列计划包括5部分：完整性约束理论及应用、范式理论及应用、需求分析、概念结构设计、逻辑结构设计。本文是第三部分，介绍需求分析中如何借助数据流图发现存储对象的方法。

1．引言

不管对数据库设计还是对系统设计来说，需求分析都是第一步。需求的目的就是搞清楚用户要做什么，如果需求做的仔细，可以在后面的设计和实现中少做很多无用功，其重要性是不言自明的。

需求分析的方法在软件工程中都有说明，不管哪种方法，最重要的都是与用户的沟通和交流，引导用户正确的确认问题。做需求分析需要有点心理学的知识，这里我就不啰嗦了。

本文的重点在于如何通过需求分析，找出需要存储的数据。

2．工具选择

对于与用户的交流来说，需求分析阶段比较直观的工具是UML中的用例图。其优点非常明显，就是用图形方式表示功能和角色，需求分析人员和用户都能非常容易的读懂并以此交流（当然我说的是草图设计，不是蓝图设计或基于程序的设计）。

那么我们看一下UML是否能很好的支持数据库设计——这点要从UML设计过程分析。有了用例图，我们得到的是系统的功能需求，而且仔细的话，我们可以做的很好。那么下一步，一般是通过时序图（也有翻译成顺序图或序列图的）发现系统中的对象。这种图向用户简单说明也很容易理解和交流。发现了系统中的对象后，就可以进行类图的设计了。类图是系统中对象的抽象，一般可以与编码实现的类和对象对应起来。

这是一个完美的设计过程，方便交流，还容易转换为编码。但是，我们从这个过程也可以看到，UML没有涉及数据库的设计过程。那么是不是可以把在时序图中发现的对象转换为数据库实体（表）呢？我们分析一下这些对象的特点，会发现这些对象对应的是我们设计的应用程序内存中保存的对象，而内存中的对象，有些可以简单的和数据库表对应，但大部分却是几个表的组合——对应的是数据库中的视图。

对用户来说，表和视图是不必区分的，用户只关心看到的数据，这也是UML与用户容易交流的一个原因。但对于数据库设计人员来说，要使数据冗余尽量少，使编码时更新数据尽可能局限在局部范围内，就必须重新设计对象的存储方式，把表和视图区分开来。这一步的工作还包括视图如何分解为基本表的过程。这项工作没有什么方法值得信赖，只能依靠设计人员的经验和技巧了。这样得到的结果也很难让人信赖。

通过以上分析，我们可以了解，UML支持系统设计是非常好的工具，但在数据库设计中，其支持明显不足。

UML为什么难以支持数据库设计呢？主要原因在于UML是以功能为中心的，而不是以数据为中心的。这样我们需要找个以数据为中心的工具，这就是数据流图法。

数据流图表达了数据和处理的过程，其绘制总是围绕数据如何加工以及如何流转的，因此，它可以非常好的支持数据库的设计。

补充一点：有些教科书中把数据流图的绘制放到概念结构设计中，另一些则放到需求分析中。个人意见，数据库中存储的对象不是设计出来的，而是从用户那里获得的，所以我倾向于把数据流图归到需求分析过程中。不管哪种分法，在做需求时就需要做数据流图，以便把实体中的属性（字段）搞清楚。

3．需求分析的方法和过程

确定了工具后，就可以按照教科书上的方法和过程进行分析了。大家不要对教科书上呆板的叙述嗤之以鼻，那可是无数人经验和教训的总结，是有相当高的参考价值的。另一方面，也不要纸上谈兵，要用心去感受，思考这些方法如何使用。

需求分析的方法一般有跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录等。一般需要根据具体情况选用一种或多种方法，这里我就不罗嗦了。

需求分析的过程一般是：

（1）       调查组织机构总体情况；

（2）       熟悉业务活动；

（3）       明确用户需求；

（4）       确定系统边界。

这里容易忽略的是第一个步骤，主要是因为这个步骤太简单，看上去似乎也可有可无。但在实际需求分析中，这个过程很重要，这点要从组织机构的作用说起。一个单位的部门，不是因为有几个人，然后把他们组织起来就形成的。而是因为业务原因，需要有一个部门专门负责某项工作，然后才组织人手形成的部门。因此在实际系统中，部门是完成某项工作的核心，一个部门一般对应一个角色。如果把组织机构搞清楚了，总体业务逻辑基本也就清楚了，这样做可以起到事半功倍的效果。

其它几点的作用就不必说明了。

数据流图可以用作明确用户需求和确定系统边界两个步骤中，帮助设计者了解数据如何流动，并发现需要存储的对象。

4．数据流图图元

我们使用Visio 2003作为绘图工具。因为我们使用数据流图仅做草图设计，因此选择“软件”中的“数据流图模型”模版进行绘制。

数据流图语义比较简单，图元一共四个，图4.1为Visio中的表示法。

l        

l         进程：一般用椭圆表示，但Visio中用圆角矩形表示，可能是考虑椭圆中可以容纳的字比较少的原因。数据流图中的矩形一般表示一个功能模块或一个过程，对应一个或一组动作。

l         数据存储：用右边开口的矩形表示，表示数据库中存储的对象。另外在数据流图中，如果一个存储过程在同一个图中出现多次（主要是防止画的线交叉），还经常在在矩形左侧向右一点加个竖直线表示，但Visio中没有做区别。

l         数据流：用带箭头的直线表示，表示数据的流动方向。

5．数据流图举例

这是教科书上的一个例子（王珊，《数据库系统概论》），某厂管理信息系统包括三个模块：销售管理子系统、劳动人事管理子系统和物资子系统。其中销售子系统的基本需求是：

（1）       处理顾客和销售员送来的订单。

（2）       工厂是根据订货（订单）安排生产的。

（3）       交出货物同时开出发票，并记入应收帐款。

（4）       收到顾客付款后，根据发票存根和信贷情况进行应收帐款处理。

这个需求太笼统了，我们逐步细化这个需求，并采用数据流图作为辅助分析手段。

5.1 销售管理子系统第一层数据流图

（1）       不管是顾客还是销售员送来的订单，发起者都是顾客，销售员只是顾客的一个代理，因此系统都认为是顾客送来的订单。

（2）       顾客送来订单后，订单数据进入1.0（送进订单）模块进行处理。这里编号为1.0是为了后续分析方便，如果这个模块还能细分处其它子功能，则编号为1.n。

（3）       主管部门在送进订单模块对订单进行核对，主要核对价格是否正确，以及顾客账目状况（是否拖欠了太多应收帐款），因此要参考产品描述信息和应收帐款信息。这里我们就发现了两个需要存储的对象。

（4）       主管部门审核后，告知1.0模块（一般是点个按钮），不管批准与否，都要通知顾客。

（5）       已批准订单送入2.0模块进行处理。

（6）       2.0模块首先将订单信息保存，存入“订单记录本”。同时生成生产通知单，发送给生产部门以进行生产。

（7）       生产部门的生产是一个封闭过程，该系统无法控制。生产完成后，开具发票。

（8）       开发票时，一方面要调整应收帐款（财务术语，只要开了发票，就是应收帐款；付款后冲抵掉应收帐款）；另一方面，生成包装通知单（包括发票、产品说明等、配件说明等）发送给顾客。

（9）       顾客结算数据时，使用支付过账模块（4.0），调整应收帐款。

（10）   另外系统需要提供一个应收帐款辅助模块，用于：为主管部门生成应收帐款报表；若实际业务往来中出现漏操作的情况，手工调整未付差额，并将财务变动通知顾客。

图中两个“应收帐款”是同一个数据存储，画到一起数据线会出现大量交叉的情况，所以画了两个。

下面我们看一下各个功能模块是否可以细分。

5.2 接收订单

这个对应第一层数据流图的1.0模块，对顾客来说，在第一层数据流图中名为“送进订单”，但对于我们的系统来说，称为“接收订单”更确切一些。

这一步的过程是：主管部门拿着用户（或销售员）填写的订单，调出价格信息和该顾客账目信息进行核对，决定是否批准，然后将订单的某一联反馈给顾客（毕竟顾客没有操作这个系统的权限，只好手工处理了）。对已批准的订单，送入下一步进行处理（2.0）。

（1）      

（2）       价格核对后，核对顾客账目状况，看一下该顾客是否拖欠了太多款项，这时要参考“应收帐款”信息。

（3）       账目已核对的订单，将价格和账目的核对情况，发送给主管部门，由主管部门决定是否批准。

（4）       不管是否批准，都要通知顾客。

（5）       已批准订单送入2.0（处理订单）。

5.3 处理订单

已批准的订单进行登记，并分配工种（如车工、钳工、焊工、电工等），生成生产通知单发送给生产部门安排生产。同时生成待完成订货清单，供生产部门参考。

生产完成后由生产部门将数据送入下一环节：开发票（3.0）。

图5.3 处理订单

5.4 开发票

开发票后将发票分配一个发票号（当然现在的发票都是全国统一编号，每张发票事先都已经编好号了，呵呵），并记人发票记录本。

5.5 支付过账

顾客结算时有两种方式：支付货款或信贷。

支付货款后，系统记入贷方余额，具体操作是调整应收帐款信息。如果信贷，需要根据有个审批环节，如果批准，则记入借方余额，操作也是调整应收帐款（似乎这个地方不用调整，因为开发票时已经调整了）。

5.6 提供应收帐款

这步不能进一步细化，已经完成。 

5.7 小结

通过以上数据流图，我们明确了用户需求，并发现了几个要存储的对象。在下一节，我们考虑如何用发现的这些数据存储构造E-R图。