UML与数据流图

Ref: 《数​据​库​设​计​理​论​及​应​用​(​3​)​—​—​需​求​分​析​及​数​据》http://wenku.baidu.com/link?url=hbhJFytMKT8A1D_rKkQ-ABor7zqSJkpQkIsjcX5oxmeZN5cA_5vU8Iq1IWuNORrvLV7haoKCHVe-4YwxEp0C2EyHLwPvV8mihG25FeWuR2O

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

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

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

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

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

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

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

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