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