DBA 我想上一层楼，DFD 了解一下

活着绕不过修行，越简单越复杂，然后有可能是越复杂，越简单。DBA 做久了，貌似两个路径，运维DBA， 开发DBA，实际上还有另一条路，就是将其合二为一，让你自身升华一次，成为一个数据库架构师。那在软件项目中，除了去给硬件层次，或数据库层次做一个架构的规划以外， 从软件的开发角度，作为DB的层次也可以梳理和参与甚至是贴合软件来做一些事。

今天就从DFD 切入，两手都要抓，两手都能crash点的角度来看看。DFD 是什么，DFD 是data -flow diagram 数据流图，在开发软件的过程中，有需求，需求分析，有各种软件开发的流程图，但从DB的点位出发，除了在数据库选型以及表设计去符合你的软件项目需求，在软件的需求阶段，你也要根据软件设计的业务需求，来画出从DB 观点出发的 DFD 数据流图。软件人员可能会问，这有必要吗，因为从软件设计的角度很多企业是没有这个“项目”的。 

用大白话讲，DFD是将你软件项目中的数据从哪里来，数据到哪里去，数据在哪个节点有存储，数据在整体项目的流转，以数据库DB的视角来进行一个描绘，很逻辑的事情，好处也是有的，1 避免在设计表的时候，忘记某些数据表的设计之间的关联性，2 避免设计表时定位不清，造成一个表多个用途或多个表一个用途，最终导致 “一夫多妻“， 或者“一妻多夫”的可能性。

而这个图应该是在 UML 图之前要有的，a way of visualizing software systems before UML diagrams.  DFD 也是有两个种风格，

1 Yourdon&Coad  更加贴近系统分析和设计

2 Gane & Sarson   更贴近信息系统的可视化

通过这两种方式来描述 数据的存储，数据流， 外部实体。在绘制 DFD的时候会以四种图形来描述DFD的四个基本概念， 1 外部实体 2 过程  3 数据存储 4 数据流 来组成DFD，其中是可以用不同的图形来表达这四种实体的不同。

下面就以一个简单的订单系统作为 DFD 的入门

在一个订单发货系统里面，首先我们根据常识性的知识，外部的实体会存在

1 客户

2 库存

3 快递公司

4 管理

以及最后的我们的处理任务的process 订单发货处理系统，建模的最简单的DFD图，其中包含了系统中必要的实体，和流程，图看似简单，但是确定系统边界的方法。表名系统和上下文之间的关系，也是DFD的上下文数据流程图。也可以叫 0  LEVEL 图

在大方向确认的情况线下，就开始规划 LEVEL 1 的数据流图了，将LEVEL 0 的图细化。

从下图我们可以知道，发货系统的数据源来自于订单，实体有客户，快递公司，仓库，审批管理人， 而数据的存储位置有 库存，订单，涉及两个系统处理过程，订单发货处理过程，与订单出库单生成过程

其实在整个DFD图的产生的过程中就梳理了当前系统设计的数据流是否顺畅，是否贴近实际业务的信息流转。

在画DFD图的时候，需要注意以下几点：

1 过程模块应该使用动作，或动态的名词来表示--动的一个状态

2 数据存储位置至少应该与一个操作或者进程相关联

3 外部的实体也需要至少一个与操作或进程相关

4 数据存储不应该与外部实体有关

5 每个图必然有数据的流入和流出

6 所有的图必须以一个外部实体开始，以一个外部实体结束

7 外部实体之间不存在数据流转

实际上DFD图，是一个简单到复杂的过程将数据流，数据流转分层的进行分析绘制，将某个软件开发中的东西细化的过程。下面就是DFD的分层图

顶层数据流图只包含一个过程，表示整个系统

中层数据流图是对父层数据流中某个过程进行细化

底层是细化的过程，细化到不能在细化

OK 就先写到这，也编不出什么来了，如果写错了还请软件方面的大仙们指正，感谢。