数据流图DFD画法：符号约定、分层分解与父子平衡校验

简介：这份数据流图（DFD）专题PPT课件面向信息系统分析与设计的初学者及课程教学场景，针对看不懂图形符号、不清楚自顶向下逐层分解逻辑的常见难点，系统梳理了DFD的建模方法。课件先从数据流、加工、数据存储、外部项四类基本符号讲起，说明编号规则与命名要点；再给出识别外部项、确定输入输出流、划分主要处理功能、逐层细化直至检查完善的完整绘制步骤，并归纳明确系统界面、合理布局等原则，以及数据流必须经过加工等易错事项。压缩包内仅1个PPT文件，约312KB，篇幅紧凑、图示与讲解配套，可直接用于课堂演示或自学通读。已有626人学习，其中银行取款业务的关联图、顶层图与二层分解示例较具参考价值，便于读者对照模仿，独立完成从关联图到分层DFD的绘制与自检。

1. 先弄清一个前提：数据流图到底画给谁看

带课程设计和毕设这几年，返工率最高的一张图不是架构图，也不是 ER 图，而是数据流图。有同学画银行取款，把现金画成一条数据流，导师扫一眼就打回来，整张图跟着重画。数据流图（DFD）的价值在于它不谈硬件、不谈软件、不谈数据结构和文件组织，只回答系统在信息处理上做什么，所以完全不懂技术的业务人员也能读懂；代价是它对符号约定和分层纪律极其挑剔，四种符号、四套编号、七步画法，任何一步偷懒，图就会从沟通工具变成只有画图的人自己看得懂的黑匣子。下面这套流程是我带项目时固定走的顺序，从符号约定到逐层分解再到验收，照着走能直接交作业，也能直接用在需求评审上。

2. 符号体系与建模约定：四类元素、四套编号和一张画布

很多人一上手就急着画，画到第二层发现线交叉成一团，改都改不动。问题几乎都出在前面：符号用法没统一，编号没规划，布局没约定。这三件事在动笔前花二十分钟定死，后面能省两天。我一般会先在一张草稿纸上写好本项目的符号约定和编号规则，贴在图旁边，谁来画都按这个来。

2.1 四类基本符号各自管什么，边界在哪

数据流由一个或一组确定的数据组成，线条加箭头表示流向。名字要能直观反映含义，"数据""信息""结果"这类名字等于没起名，读者看完还是不知道线上跑的是什么。数据流可以同名，但必须是不同的数据或不同的含义；同名同结构又同含义的两条流会让读者误以为是一条。两个符号之间允许同时存在多条数据流，DFD 不表达它们之间的次序和主次——有人习惯在两条流之间标注"先执行""后执行"，那是流程图的思维，混进来会让整张图的性质变掉。

加工是对数据流的操作，符号分上下两部分：上面是标识部分，写加工编号，编号以 P 开头且全局唯一；下面是功能描述部分，写加工名，要求简短、能概括对数据的加工行为，更细的规则不进图，全部放到数据词典里。加工必须逐层分解，一直分到"功能简单、易于理解"为止，这个终止条件后面会单独讲。

数据存储用来存数据，开口长方框，框内写存储名，概括说明里面主要放什么。有两条硬规矩：数据存储上一定要有数据流，只写不读是死数据，只读不写等于凭空产生；数据存储要编号，写在符号左端的小方格中，以 D 开头。为了避免图上出现交叉线，同一个数据存储可以在多处重复画出，用一个重复标记表示它们是同一个。

外部项又叫源点和终点，是系统之外的实体，可以是人，也可以是别的系统。从源点进系统的信息是输入，从系统到终点的是输出。外部项编号以 S 开头，图上不需要详细描述它——它的内部逻辑不属于本系统，写多了反而是越界。同一个外部实体在图上出现两次（既收又发）时，我一般左右各画一个同编号的符号，比拉一条横穿全图的长线干净得多。

边界这条最容易被忽略：现金、发票、纸质存折、货物这类实物不是数据。数据流跑的是信息，不是物流。银行取款里现金从柜台递到储户手上，这件事在 DFD 里根本不出现；真正上线的是存折、利息单、结算清单这些承载信息的单据。

提示：判断一条线该不该画，问一句"这条线上跑的是能被记录、存储、加工的信息，还是实物或动作"。是实物或动作，就别进 DFD。

2.2 编号规则：P / D / F / S 四套前缀怎么定

编号不是为了好看，是为了评审时能一句话定位。"P2.3 少了一条输入"比"那个分类处理好像缺点什么"高效太多，尤其在多人协作时，编号就是共同语言。

数据流编号有个好用的习惯：同一条数据流在父子图之间保持同一编号和同一名字，只在细化时加点号。父图上 F1 是"取款单、存折"，子图拆成 F1.1"合格存折、取款单"和 F1.2"不合格存折、取款单"，点号一看就知道血缘关系。反例是把父图的 F1 在子图里改名成 F7，评审的人得来回对照才敢确认这是同一条流，这种改动除了给自己添麻烦没有任何收益。

加工编号的层级要统一。顶层是 P1、P2、P3，P2 分解出来的二层图就是 P2.1、P2.2、P2.3、P2.4，绝不允许出现 P2 下面挂 P5 的情况。数据存储编号通常不分层，D1 在第一层叫图书目录，到第二层还是 D1，因为它是同一个物理文件在不同层被读写。

2.3 画布布局与防交叉线的约定

布局有套稳定的排法：外部项贴画布四边，源点在左、终点在右；加工居中偏上；数据存储靠下或贴两侧。这么排是因为读图的人眼睛习惯从左到右、从上到下扫，边界在边上，一眼就能看出系统管到哪儿为止。反过来把外部项堆在中间、加工甩到角落，读者第一眼就找不到边界。

线尽量走直线，拐弯只拐直角，斜线会让整张图看起来像蜘蛛网。实在避不开交叉时，断开来画：把被穿过的数据存储在图的两侧各画一个重复符号，中间那条穿过去的线就不存在了。这条技巧在小图上无所谓，到二层图、三层图就是救命用的。

每层单独一张画布，关联图一张、顶层图一张、二层图一张或数张，绝不混画。混画的典型症状是一张图上既有总的系统框，又有拆开之后的子系统框，编号还混着用，评审时没法判断这是哪一层。分层的意义在于每一层都能单独拿出来讲，一张图讲一件事。

命名和布局要一起做。画完先别急着往下分解，把每条数据流的名字逐条念一遍，念出来像人话就留，念出来像"数据 1""处理结果"就改。名字改在图上是两分钟的事，等到数据词典写完再改，就是牵一发动全身。

3. 分层分解的落地路线：从关联图到二层图的七步操作

七步听着像仪式，其实每一步都有明确交付物：第一步交出外部项清单，第二步交出关联图，第三步交出子系统划分说明，第四步交出各层子图，第五步交出分解终止判定，第六步交出检查记录，第七步交出用户确认意见。有交付物，进度才可控；没有交付物，画到哪儿算哪儿，最后只能推倒重来。

3.1 前三步：定外部项、画关联图、划分子系统

第一步确定外部项，就是找系统的数据来源和去处。做法很土但管用：把业务方提到的所有角色、所有外部单位、所有上游下游系统列成一张清单，逐条问"它给系统什么数据""系统给它什么数据"，答不上来的先划掉。清单出来后统一编号，这是后面所有图的基准。

第二步画关联图。把整个系统当成一个加工环节（画一个框就行，可以不编号），把第一步整理出的全部输入输出数据流画上去。关联图的作用是锁定系统边界，这张图跟用户确认过之后，后面所有分解都不许越界。很多返工都是因为关联图上多画了一个外部项，导致后面每一层都要跟着改。

第三步划分子系统。划分依据是主要信息处理功能，按业务动作切——审核、处理、汇总、发送，而不是按部门切，也不是按技术模块切。按部门切出来的图，一旦组织结构调整，图就废了；按业务动作切，动作本身是稳定的。切完给每个子系统编号 P1、P2、P3，同时确定每个加工的输入输出数据流，以及跟这些加工有关的数据存储。

3.2 第四到第五步：逐层分解与父子平衡

分解遵循自顶向下、逐层细化的原则，对上层图中的全部或部分加工继续拆。这里有个判断标准：什么时候停？当这个加工的功能简单到能用一句话说清、且不需要再拆就能直接写进数据词典时，就可以停。行业里管这种叫基本加工。拆过头的典型是把"审核"再拆成"读单据""比对""返回结果"，那是程序设计的层次，不是 DFD 的层次。

父子平衡是这一阶段最硬的约束：父图上某个加工的输入流集合，必须等于子图上该加工所有外部输入流之和（允许细化，不允许凭空多出或消失）。举个例子，父图 P2 的输入是 F1，输出是 F2 和 F3；那么二层图里 P2.1 到 P2.4 这几个加工，它们与子图外部相连的流加起来，必须正好对应 F1（或其细化 F1.1、F1.2）、F2、F3。如果子图里冒出一条父图没有的 F9，或者父图的 F3 在子图里彻底消失，就是不平衡。

不平衡是评审时最容易被抓的点，因为它可以被机械检查出来，不需要理解业务。我见过最典型的一次，是子图上多画了一条"内部通知"流，作者觉得顺手，但在父图层面它没有对应的出入口，整条链就断了——要么在父图补上，要么在子图删掉，没有第三种选择。

3.3 第六到第七步：布局检查与用户走查

第六步是检查与合理布局，检查项有四类：分解是否恰当彻底，各层是否有遗漏、重复、冲突，各层之间以及同层各图之间关系是否正确，命名与编号是否确切合理。这一步不要自己闷头看，最好找一个没参与画图的人对着图讲一遍，讲不通的地方就是问题所在。

第七步是跟用户交流。顺序是：先拿关联图讲边界，问"你们的数据来源和去处就这些吗"；再拿顶层图讲子系统划分，问"这几块业务是这么分的吗"；最后逐条念数据流的名字，问"你们平时是这么叫的吗"。用户说"我们不管这个叫取款单，叫凭条"，那就改名字，别争。名字错了，后面数据词典、界面设计、字段设计全跟着错，这是血泪经验。

注意：走查不是一次性的。每分解一层就该走一次，等到全部画完再拿去给用户看，改动成本会翻好几倍。

3.4 用一份元素清单做机械校验

人工检查容易漏，尤其是流多的时候。我一般会把图上的元素先录入一份清单，再用脚本跑一遍，把断线、黑洞、只读不写的存储挑出来。清单直接用一个 Python 字典表示，改起来比数据库快。

# dfd_model.py # 用字典描述单张 DFD：元素 + 连线，脚本负责机械校验 dfd_top = { "name": "取款处理顶层图", "externals": {"S1": "储户"}, "processes": {"P1": "取款审核", "P2": "取款处理"}, "stores": {"D1": "账目库", "D2": "取款记录"}, # 每条流: 编号 -> (起点, 终点)，端点必须是上面三类里定义过的编号 "flows": { "F1": ("S1", "P1"), # 取款单、存折 进入审核 "F1.1": ("P1", "P2"), # 合格单据送取款处理 "F1.2": ("P1", "S1"), # 不合格单据退回储户 "F2": ("P2", "S1"), # 存折、利息单、结算清单交储户 "F4": ("D1", "P1"), # 审核时查账目 "F5": ("P2", "D1"), # 处理后改账目 "F6": ("P2", "D2"), # 取款单存档 }, }

校验函数做四件事：端点是否存在、加工是否有进有出、数据存储是否既被读也被写、父子图边界流是否对得上。

def check(dfd): nodes = set(dfd["externals"]) | set(dfd["processes"]) | set(dfd["stores"]) in_flow, out_flow = {}, {} for fid, (src, dst) in dfd["flows"].items(): if src not in nodes or dst not in nodes: print(f"[断线] {fid}: {src} -> {dst}，端点未定义") in_flow.setdefault(dst, []).append(fid) out_flow.setdefault(src, []).append(fid) # 加工不允许只有输入（黑洞）或只有输出（奇迹） for pid, pname in dfd["processes"].items(): if not in_flow.get(pid): print(f"[奇迹] 加工 {pid} {pname} 没有输入") if not out_flow.get(pid): print(f"[黑洞] 加工 {pid} {pname} 没有输出") # 数据存储必须有读有写 for did, dname in dfd["stores"].items(): if not in_flow.get(did): print(f"[只读] 存储 {did} {dname} 没有任何写入") if not out_flow.get(did): print(f"[死数据] 存储 {did} {dname} 没有任何读取")

父子平衡单独一个函数，思路是把子图里所有跨越子图边界的流，按编号前缀归并回父级编号，再跟父图上该加工的进出流比对。

def check_balance(parent_flows, child_flows, pid): # parent_flows: 父图上与加工 pid 相关的流编号集合，如 {"F1", "F2", "F3"} # child_flows: 子图中所有一端在子图内部、另一端在子图外部的流编号 base = lambda f: f.split(".")[0] # F1.1 -> F1 child_base = {base(f) for f in child_flows} missing = set(parent_flows) - child_base # 父图有、子图没了 extra = child_base - set(parent_flows) # 子图凭空多出来的 if missing: print(f"[不平衡] {pid} 子图缺少父图的流: {sorted(missing)}") if extra: print(f"[不平衡] {pid} 子图多出父图没有的流: {sorted(extra)}")

参数说明：parent_flows填父图上挂在这个加工上的流编号，child_flows填子图里所有跨边界的流。split(".")[0]是为了把 F1.1、F1.2 归并回 F1，因为父子平衡允许细化，只禁止增减。跑完输出为空，说明这张图在结构上站得住；有输出就照着编号回去改图，比盯着画布找问题快得多。

4. 两个案例走一遍：银行取款与图书预订的逐层拆解

光看规则记不住，得有两三个实例走一遍全流程。银行取款适合讲边界（什么不能画成数据流），图书预订适合讲分解（为什么顶层画完还得多走一层）。这两个例子吃透，换成教务系统、图书管理系统、设备报修系统，套路是一样的。

4.1 银行取款：现金是实物，不是数据流

业务描述：储户把填好的取款单和存折交给银行，银行审核并查对账目，不合格的存折和取款单退回储户，合格的送取款处理；处理取款时修改账目，把存折、利息单、结算清单和现金交给储户；同时把取款单存档。

第一步，关联图。外部项只有储户一个，但要注意它既是源点也是终点：储户给出 F1"取款单、存折"，系统返回 F2"存折、利率单、结算清单"。现金在这里不出现，它属于实物交接，不进 DFD。这一步画完就该拿去跟业务方确认"进出系统的信息就这两条吗"，确认了再往下走。

第二步，顶层图。把系统拆成两个加工：P1 取款审核、P2 取款处理；两个数据存储：D1 账目库、D2 取款记录。数据流这么连：

这里有两个设计点值得说。P1 只读不写，它是纯判定加工，这在 DFD 里完全允许，但必须保证它有进有出，否则就是黑洞。F1 在子图里被细化成 F1.1 和 F1.2，编号带点号，评审时一眼能看出它们是从 F1 分出来的，这就是 2.2 节那套编号习惯的实际收益。

4.2 图书预订：顶层画完还得多走一层

业务描述：书店向顾客发放订单，顾客填好交回系统；系统依据图书目录检查订单，合格订单进入处理；处理时根据顾客情况和订单数目把订单分成优先订单和正常订单，优先订单随时处理，正常订单定期处理；最后汇总已处理订单，按出版社要求发给出版社。

关联图：S1 顾客给出 F1 订单，系统返回 F3 不合格订单；系统向 S2 出版社发出 F2 汇总订单。三条流，边界干净。

顶层图：P1 订单检查、P2 订单处理、P3 发送订单；数据存储四个：D1 图书目录（P1 读）、D2 合格订单（P1 写、P2 读）、D3 待发出订单（P2 写、P3 读）、D4 出版社要求（P3 读）。这张图已经能讲清系统有哪几块业务，但 P2 仍然不是基本加工——它内部同时干了数目统计、订单分类、处理优先订单、处理正常订单四件事，一句话说不清，必须再分解一层。

二层图把 P2 拆成四个加工：P2.1 数目统计（读 D2，写 D5 订单数目）、P2.2 订单分类（读 D2、D5 订单数目、D6 顾客情况，分出 D7 优先订单和 D8 正常订单）、P2.3 随时处理优先订单（读 D7）、P2.4 定期处理正常订单（读 D8，写 D3 待发出订单）。这里体现了一条重要原则：数据存储一般作为两个加工之间的界面来安排。分类和处理之间不直接拉线，而是用 D7、D8 两个存储承接，好处是以后要加一种订单类型，只需在分类里加一个输出，处理侧不受影响。

对比一下就能看出两个例子的分工：银行取款重点在边界判断，图书预订重点在分解深度。同一个套路，一个用来练"什么不该画"，一个用来练"什么时候该继续拆"。

4.3 数据词典怎么跟图配套

图上的名字必须有地方落定，否则答辩时被问"合格订单里到底有哪些字段"就卡住了。我一般用三张表把图和词典钉在一起。

-- 元素表：图上的每一个符号都在这 CREATE TABLE dfd_element ( elem_id VARCHAR(16) PRIMARY KEY, -- P2.2 / D7 / S1 elem_type CHAR(1) NOT NULL, -- P加工 D存储 F数据流 S外部项 elem_name VARCHAR(64) NOT NULL, parent_id VARCHAR(16), -- 所属父加工，顶层为 NULL remark VARCHAR(255) ); -- 连线表：外键保证不会出现悬空的线 CREATE TABLE dfd_flow ( flow_id VARCHAR(16) PRIMARY KEY, -- F1.1 flow_name VARCHAR(64) NOT NULL, src_id VARCHAR(16) NOT NULL, dst_id VARCHAR(16) NOT NULL, FOREIGN KEY (src_id) REFERENCES dfd_element(elem_id), FOREIGN KEY (dst_id) REFERENCES dfd_element(elem_id) ); -- 数据项表：数据词典的正文本 CREATE TABLE data_item ( item_id VARCHAR(16) PRIMARY KEY, flow_id VARCHAR(16), -- 属于哪条流或哪个存储 item_name VARCHAR(64) NOT NULL, item_type VARCHAR(32), -- 字符/数值/日期 item_len VARCHAR(16), rule VARCHAR(255) -- 取值规则、校验规则 );

dfd_element.parent_id撑起分层树，任意一层都能顺着字段往上找父加工；dfd_flow的两个外键把"端点必须存在"这条约束交给数据库，插入一条指向不存在加工的流会直接报错；data_item是词典本体，答辩被问订单字段就翻这张表。

要查某个加工的所有进出流，一条 SQL 就够：

SELECT flow_id, flow_name, src_id, dst_id FROM dfd_flow WHERE src_id = 'P2' OR dst_id = 'P2';

把'P2'换成任意加工编号即可复用。这种查法在评审前特别好用：把每个加工查一遍，输出为空的那一行，就是图上漏画的加工。

5. 避坑与常见问题排查：五类最容易被退回的图

这些年看过的图里，出问题的就那么几类，反复出现。下面每条按"现象—原因—解决"写，对着自查基本能挡掉大部分返工。

第一类，实物和动作混进数据流。现象是图上出现"现金""发票""货物""发货"这类名字。原因是画图的人把 DFD 当成了业务流程图，觉得业务里发生的都该画上去。解决办法是回到定义：数据流由一个或一组确定的数据组成，必须是可记录、可存储、可加工的信息。现金交接不画，但现金对应的"结算清单"要画；发货动作不画，但"出库单"要画。判断方法就一句：这条线上跑的东西能被存进数据库吗。

第二类，数据流绕过加工。现象是外部项直接连到数据存储，或者外部项之间拉一条线。原因是图省事，觉得"反正数据就是从这儿到那儿"。解决：数据流必须通过加工，外部项跟数据存储之间不存在直接通路，中间一定要有一个加工在做转换。外部项之间更不能有流，它们分属系统内外两侧，跨过整个系统的连线说明边界没划清。

第三类，父子图不平衡。现象是父图上 P2 有两条输入，子图里对不上；或者子图里凭空冒出一条父图没有的流。原因多半是分层时改图只改了子图，忘了回头同步父图，也可能是分解时顺手加了个"内部通知"之类的流。解决：用 3.4 节那个check_balance跑一遍，按编号前缀归并后比对，缺的补、多的删，删不掉就在父图补上对应出入口。

第四类，加工黑洞与数据存储只读不写。现象是某个加工只有输出没有输入，或者某个存储从头到尾只有箭头指向它。原因是分解到一半思路断了，先画个框占位，后来忘了补。解决：跑check函数，输出里出现[黑洞]、[奇迹]、[只读]、[死数据就回去补。特别提醒纯判定类加工（比如审核），它们可以不写存储，但必须有进有出，这一点最容易误判成"它不写库所以没问题"。

第五类，分解失控与命名含糊。分解失控有两种表现：一种是一层画到底，把几十个加工全塞在顶层图上，读者根本看不出层次；另一种是拆到原子级，把"审核"拆成"读单据—比对—返结果"，这已经进入程序设计层面，不是 DFD 该管的。命名含糊则是通病，加工叫"处理数据"，数据流叫"信息"，数据存储叫"数据库"。解决办法：加工名用动宾结构，能一句话说清动作对象；数据流名用名词或名词短语，能念出来像业务里的人说的话；存储名概括里面主要放什么。分解终止条件统一为"功能简单到不需要再拆即可写进数据词典"，全组按这一个标准执行，别各拆各的。

6. 验收与答辩：十分钟里证明这张图是对的

图交上去之前，我一般会走一遍固定自查，六项，对着表打勾，比凭感觉靠谱得多。

答辩的讲法比图本身还重要。十分钟的场子我通常这么排：先用三十秒讲关联图，只讲系统边界——谁是数据来源、谁是数据去处、进出各几条流，讲完评审就知道你把范围框住了；接着两分钟讲顶层图，重点讲子系统划分依据，为什么按审核、处理、发送这么切，而不是按别的切法；然后三分钟挑一条主线数据流走到底，比如"一张取款单从储户填单开始，进审核、查到账目、合格后送处理、改账目、写取款记录、最后生成结算清单回到储户"，一条线走完，整张图的连贯性就立住了；最后两分钟讲终止条件，说明为什么在这一层停、哪些加工已经是基本加工。

剩下的时间留给提问。常被问的三类问题提前准备好答案：某个数据存储为什么放在这一层而不是上一层，某个加工为什么不再往下拆，某个外部项为什么不算系统内部模块。这三问本质上都在考你有没有想清楚边界和层次，而不是考你画得漂不漂亮。

从那以后我每次交图前都强制走两件事：把元素清单丢进校验脚本跑一遍，再把关联图拿给一个完全不懂技术的同学讲三分钟，他能复述出系统边界和数据流向，这张图才算过关。希望帮到你。

本文还有配套的精品资源，点击获取