该系列计划包括5部分：完整性约束理论及应用、范式理论及应用、需求分析、概念结构... - EaBIM

该系列计划包括5部分：完整性约束理论及应用、范式理论及应用、需求分析、概念结构设计、逻辑结构设计。本文是第三部分，介绍需求分析中如何借助数据流图发现存储对象的方法。
1．引言
不管对数据库设计还是对系统设计来说，需求分析都是第一步。需求的目的就是搞清楚用户要做什么，如果需求做的仔细，可以在后面的设计和实现中少做很多无用功，其重要性是不言自明的。
需求分析的方法在软件工程中都有说明，不管哪种方法，最重要的都是与用户的沟通和交流，引导用户正确的确认问题。做需求分析需要有点心理学的知识，这里我就不啰嗦了。
本文的重点在于如何通过需求分析，找出需要存储的数据。
2．工具选择
对于与用户的交流来说，需求分析阶段比较直观的工具是UML中的用例图。其优点非常明显，就是用图形方式表示功能和角色，需求分析人员和用户都能非常容易的读懂并以此交流（当然我说的是草图设计，不是蓝图设计或基于程序的设计）。
那么我们看一下UML是否能很好的支持数据库设计——这点要从UML设计过程分析。有了用例图，我们得到的是系统的功能需求，而且仔细的话，我们可以做的很好。那么下一步，一般是通过时序图（也有翻译成顺序图或序列图的）发现系统中的对象。这种图向用户简单说明也很容易理解和交流。发现了系统中的对象后，就可以进行类图的设计了。类图是系统中对象的抽象，一般可以与编码实现的类和对象对应起来。
这是一个完美的设计过程，方便交流，还容易转换为编码。但是，我们从这个过程也可以看到，UML没有涉及数据库的设计过程。那么是不是可以把在时序图中发现的对象转换为数据库实体（表）呢？我们分析一下这些对象的特点，会发现这些对象对应的是我们设计的应用程序内存中保存的对象，而内存中的对象，有些可以简单的和数据库表对应，但大部分却是几个表的组合——对应的是数据库中的视图。
对用户来说，表和视图是不必区分的，用户只关心看到的数据，这也是UML与用户容易交流的一个原因。但对于数据库设计人员来说，要使数据冗余尽量少，使编码时更新数据尽可能局限在局部范围内，就必须重新设计对象的存储方式，把表和视图区分开来。这一步的工作还包括视图如何分解为基本表的过程。这项工作没有什么方法值得信赖，只能依靠设计人员的经验和技巧了。这样得到的结果也很难让人信赖。
通过以上分析，我们可以了解，UML支持系统设计是非常好的工具，但在数据库设计中，其支持明显不足。
UML为什么难以支持数据库设计呢？主要原因在于UML是以功能为中心的，而不是以数据为中心的。这样我们需要找个以数据为中心的工具，这就是数据流图法。
数据流图表达了数据和处理的过程，其绘制总是围绕数据如何加工以及如何流转的，因此，它可以非常好的支持数据库的设计。
补充一点：有些教科书中把数据流图的绘制放到概念结构设计中，另一些则放到需求分析中。个人意见，数据库中存储的对象不是设计出来的，而是从用户那里获得的，所以我倾向于把数据流图归到需求分析过程中。不管哪种分法，在做需求时就需要做数据流图，以便把实体中的属性（字段）搞清楚。
3．需求分析的方法和过程
确定了工具后，就可以按照教科书上的方法和过程进行分析了。大家不要对教科书上呆板的叙述嗤之以鼻，那可是无数人经验和教训的总结，是有相当高的参考价值的。另一方面，也不要纸上谈兵，要用心去感受，思考这些方法如何使用。
需求分析的方法一般有跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录等。一般需要根据具体情况选用一种或多种方法，这里我就不罗嗦了。
需求分析的过程一般是：
（1）    调查组织机构总体情况；
（2）    熟悉业务活动；
（3）    明确用户需求；
（4）    确定系统边界。
这里容易忽略的是第一个步骤，主要是因为这个步骤太简单，看上去似乎也可有可无。但在实际需求分析中，这个过程很重要，这点要从组织机构的作用说起。一个单位的部门，不是因为有几个人，然后把他们组织起来就形成的。而是因为业务原因，需要有一个部门专门负责某项工作，然后才组织人手形成的部门。因此在实际系统中，部门是完成某项工作的核心，一个部门一般对应一个角色。如果把组织机构搞清楚了，总体业务逻辑基本也就清楚了，这样做可以起到事半功倍的效果。
其它几点的作用就不必说明了。
数据流图可以用作明确用户需求和确定系统边界两个步骤中，帮助设计者了解数据如何流动，并发现需要存储的对象。
4．数据流图图元
我们使用Visio 2003作为绘图工具。因为我们使用数据流图仅做草图设计，因此选择“软件”中的“数据流图模型”模版进行绘制。
数据流图语义比较简单，图元一共四个，图4.1为Visio中的表示法。

图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）。