企业官网建设流程全解析

简介：工资管理系统数据流程图文档，面向信息系统分析与设计学习者、软件开发人员及企业财务信息化从业者，系统梳理工资核算核心业务的数据流转与处理逻辑。文档以数据字典为基础，定义考勤日期、工资日期、职工编码、部门名称、基本工资等关键数据项；随后对变动工资表、基本工资表、工资计算表、福利费计提分配表、个人所得税申报表、工资费用分配表以及职员信息表、考勤表、工资计算标准表等存储结构逐一说明，完整覆盖考勤输入、变动工资计算、基本工资编制、工资汇总、银行代发、福利费计提、个人所得税扣缴与自动转账等主要数据流与处理逻辑，形成一套可供参照的数据流程图分析文档。资源为单份doc文档，大小95KB，便于查阅与二次编辑。目前已有2676人浏览学习，适合课程设计、毕业设计或系统开发前期的需求分析与数据库设计阶段。

1. 工资管理系统数据流程图：一份文档到底解决了谁的什么问题

每年答辩现场，最能看出有没有动过脑子的，就是那份工资管理系统数据流程图。很多人把需求文档抄一遍，流程图随便画几条箭头就交掉，被问“考勤数据从哪来”“个税在哪一步算”就卡住。工资管理系统数据流程图，就是用数据流图符号，把“员工入职—考勤采集—薪资核算—个税社保代扣—银行代发—工资条下发”这条链路上每个数据的起点、终点和加工过程画清楚。它解决的问题很具体：让评审或接手代码的人十分钟内看懂系统边界和数据走向，也让设计者提前发现表结构缺了什么。适合课程设计或毕业设计的学生、刚接手遗留薪资系统的开发，以及想补一份靠谱需求文档的工程师。

2. 数据流程图的分层逻辑：从上下文图到0层图再到1层图

数据流程图不难画，难的是分层。不分层直接画一张大图，进程十几二十个，数据流互相穿线，画完自己都不愿意看第二遍。工资管理系统数据流程图的正确打开方式是自顶向下拆成三到四层：先画系统边界，再画主干加工，最后只挑复杂的加工继续拆。评审最常问的就是“你这个图和上一层平不平衡”，所以这一章的每一层都要讲清楚。

2.1 四个符号与编号规范：外部实体、进程、数据存储、数据流

数据流图只有四种基本要素，多出来的都是画法不干净。画之前先把符号统一，国内管理信息系统教材大多用 Gane-Sarson 风格，也就是圆角矩形代表进程、矩形代表外部实体、两端开口的扁矩形代表数据存储、带箭头的线段代表数据流。也有的教材用 Yourdon 风格，进程是圆圈。建议直接跟随你手头教材，答辩时少解释一句是一句。

编号规范很关键。外部实体用 E 开头，比如 E1 员工、E2 人事/财务专员、E3 银行代发系统；进程用 P 开头，父图一个进程叫“0 工资管理系统”，0 层图拆成 P1、P2、P3、P4，继续往下拆用 P3.1、P3.2 这种点分写法；数据存储用 D 开头，D1 员工基础信息、D2 月考勤汇总、D3 社保公积金参数、D4 工资核算表、D5 工资发放记录。数据流一般不强制编号，但建议给有争议的流转附加编号，比如“D2→P3.2 考勤汇总数据”，答辩时能直接告诉评审这根线来自哪张存储。

注意数据流的命名要用名词短语，不能写动词。“计算工资”是进程的事，数据流上只能写“工资核算结果”“考勤汇总数据”这种名词。还有一条写图规则容易翻车：数据流不能画双向箭头。DFD 里一个数据流只有一个方向，从存储读出来和写进去是两条方向相反的线，不允许用一根带双箭头的线表示“读写”。一旦出现双向箭头，说明画的人还没把进程的数据读写想明白。

2.2 上下文图与0层图：先把系统边界画出来

上下文图是 DFD 的第一层，整张图只有一个进程，名字写成“0 工资管理系统”。它只解决一个问题：系统的边界在哪，谁和它交换数据。工资系统的外部实体通常有三个：员工、人事/财务专员、银行代发系统。员工向系统提交基础信息变更、收到工资条；人事/财务专员维护部门与员工档案、触发薪资核算、审核工资表；银行代发系统接收代发文件并返回发放结果。

把上下文图展开，就得到 0 层图。0 层图要把“0 工资管理系统”拆成四五个主干进程，我自己常用的拆法是：

• P1 基础数据维护：接收员工档案、部门信息，写入 D1。
• P2 考勤与异动处理：接收考勤记录和调薪、请假异动，产出 D2 月考勤汇总。
• P3 薪资核算与审核：从 D1、D2、D3 读取数据，计算工资，写入 D4。
• P4 工资发放与报表：从 D4 读取已审核数据，生成银行代发文件，生成工资条，写回 D5。

0 层图的数据流必须和上下文图对应得上。上下文图里“员工”流向“0 工资管理系统”的数据流，在 0 层图里一定要能落在某一个或某几个进程上；“银行代发文件”这条流必须从 P4 出发指向 E3。这条规则叫父图与子图平衡，是答辩时最高频的提问点。

2.3 1层子图：把“薪资核算与审核”拆到可落地的深度

0 层图里的 P3“薪资核算与审核”还是太粗，需要继续拆成 1 层子图。拆到这个深度，图才真正对写代码有指导意义。P3 的子图我通常分四个进程：

• P3.1 读取与校验数据：从 D1 取员工基础工资，从 D2 取考勤汇总，从 D3 取社保公积金参数。
• P3.2 计算应发工资：基本工资折算、加班工资、绩效奖金合计，生成应发数。
• P3.3 计算代扣项：社保公积金个人部分、个人所得税累计预扣。
• P3.4 生成核算表与审核：汇总实发工资，写入 D4，并把待审核工资核算表流向 E2 人事/财务专员。

子图不是随便拆的，拆完要做平衡检查。0 层图里 P3 有几条输入流、几条输出流，1 层子图必须一条不少、一条不多地出现。举例来说，0 层图里如果 P3 只有三条输入流“员工基础信息”“考勤汇总数据”“社保公积金参数”，外加两条输出流“工资核算表”“待审核工资明细”，那么 P3.1 到 P3.4 组成的子图里就不能凭空多出一条“绩效评分数据”。多出来的那条流，要么是 0 层图画漏了，要么是子图画错了，不管哪边错了，评审都会让你当场解释。

提示：检查平衡时只看进程与外部交换的数据流，不看进程内部存储之间的读写。D4 给 P3.4 写入和 P4 从 D4 读出，这两条流属于不同层级的存储交互，不要放在同一张子图里反复画。

分层拆到 P3 这一层，其实已经把工资计算的数据链路讲清楚了。再复杂的系统，进程内部继续拆 P3.4.1、P3.4.2 这种三级子图即可，但工资管理系统拆到 1 层通常足够，再往下拆反而让文档失去可读性。

好，前面两章相当于把标题里的“数据流程图”解释清楚了：这张图不是画完就交差的摆设，而是一个能反映系统边界、数据走向和加工逻辑的层次化模型。

3. 把数据流程图转成可落地的数据库设计：表结构、主外键与累计预扣个税脚本

流程图画得再漂亮，最终还是要落到数据库表和计算逻辑上。我在做课程设计辅导和实际项目时，最常见的做法是把 0 层图里的 D1 到 D5 直接映射成表，再把 P3 的计算过程写成可执行的脚本。这样一张数据流程图就能回答“表建几张、字段怎么定、个税怎么算”这三个落地问题。

3.1 数据存储到表结构的映射：D1到D5怎么建

我用 MySQL 语法建表，并把“图上叫什么、库里叫什么”用 COMMENT 写在字段旁边，这样文档和代码对不上时能快速定位。先建最核心的三张表，员工基础信息、考勤汇总、工资核算表。

-- D1 员工基础信息，对应外部实体 E1 员工 CREATE TABLE employee ( emp_id VARCHAR(32) PRIMARY KEY COMMENT '员工编号，对应DFD外部实体E1', emp_name VARCHAR(64) NOT NULL COMMENT '姓名', dept_id VARCHAR(16) NOT NULL COMMENT '部门编号', base_salary DECIMAL(10,2) NOT NULL COMMENT '基本工资', bank_card VARCHAR(32) NOT NULL COMMENT '银行代发卡号', hire_date DATE NOT NULL COMMENT '入职日期' ) COMMENT 'D1 员工基础信息'; -- D2 月考勤汇总数据，来自 P2 考勤与异动处理 CREATE TABLE attendance ( emp_id VARCHAR(32) NOT NULL COMMENT '员工编号，外键关联employee', stat_month CHAR(7) NOT NULL COMMENT '统计月份，格式YYYY-MM', work_days DECIMAL(4,1) DEFAULT 0 COMMENT '实际出勤天数', overtime_hours DECIMAL(6,1) DEFAULT 0 COMMENT '加班小时数', late_days INT DEFAULT 0 COMMENT '迟到次数', PRIMARY KEY (emp_id, stat_month) ) COMMENT 'D2 月考勤汇总数据'; -- D4 工资核算表，由 P3 薪资核算与审核产出 CREATE TABLE payroll ( id BIGINT AUTO_INCREMENT PRIMARY KEY, emp_id VARCHAR(32) NOT NULL COMMENT '员工编号，对应D1', stat_month CHAR(7) NOT NULL COMMENT '工资月份', gross DECIMAL(10,2) DEFAULT 0 COMMENT '应发工资', insurance DECIMAL(10,2) DEFAULT 0 COMMENT '社保公积金个人部分', tax DECIMAL(10,2) DEFAULT 0 COMMENT '个人所得税', net DECIMAL(10,2) DEFAULT 0 COMMENT '实发工资', status TINYINT DEFAULT 0 COMMENT '0草稿 1已审核 2已发放', UNIQUE KEY uk_emp_month (emp_id, stat_month) ) COMMENT 'D4 工资核算表';

表的注释直接写“D几”，是因为数据流程图评审时，评委往往拿着图指着一个存储问“这张表对应你数据库里哪张表”。把编号写进 COMMENT，答的时候打开数据库 show create table 就能指给对方看，省得现场翻代码。

payroll 表里的 status 字段值得多说一句。数据流程图里 P3.4 会把“待审核工资核算表”流向 E2，审核通过后 P4 才能读取数据去生成银行代发文件。这个“审核”动作落到表里就是 status 从 0 变 1，而不是像业务流程图那样画一个“人事审核”的判断框。数据流图里不需要判断分支，条件流转用存储上的状态字段表达，这一点和后面避坑章要讲的内容直接相关。

3.2 薪资计算链路：从考勤到实发工资的脚本怎么写

表格建好后，P3 的计算过程就可以用脚本复现了。工资计算里最容易写错的是日工资折算和个税累计预扣，前者用月计薪天数 21.75 天，后者用累计预扣法。下面这段 Python 脚本可以直接用在本地小系统或者课程设计里。

from decimal import Decimal # 累计预扣法税率表：上限、预扣率、速算扣除数 def calc_tax(accumulated_taxable_income): brackets = [ (36000, 0.03, 0), (144000, 0.10, 2520), (300000, 0.20, 16920), (420000, 0.25, 31920), (660000, 0.30, 52920), (960000, 0.35, 85920), (float('inf'), 0.45, 181920) ] if accumulated_taxable_income <= 0: return 0 for limit, rate, quick_deduct in brackets: if accumulated_taxable_income <= limit: return accumulated_taxable_income * rate - quick_deduct return 0 # 计算当月应预扣个税 # total_income：截至本月的累计收入 # total_deduction：截至本月的累计社保公积金+专项附加扣除 # months：已发放工资的月数 # already_withheld：累计已预扣税额 def calc_month_tax(total_income, total_deduction, months, already_withheld): taxable = Decimal(total_income) - Decimal(total_deduction) - Decimal(5000) * months tax = calc_tax(float(taxable)) return max(0, Decimal(tax) - Decimal(already_withheld)) # 单月工资核算：以考勤汇总表数据为输入 def compute_payroll(emp): base = Decimal(str(emp['base_salary'])) days = Decimal(str(emp['work_days'])) # 实际出勤天数 ot = Decimal(str(emp['overtime_hours'])) # 加班小时数 day_rate = base / Decimal('21.75') # 月计薪天数 base_pay = day_rate * days overtime_pay = day_rate * 2 * ot / Decimal('8') # 工作日加班按2倍 gross = base_pay + overtime_pay insurance = gross * Decimal('0.105') # 示例比例：养老8%+医疗2%+失业0.5% tax = calc_month_tax(gross, insurance, 1, 0) net = gross - insurance - tax return { 'gross': float(gross.quantize(Decimal('0.01'))), 'insurance': float(insurance.quantize(Decimal('0.01'))), 'tax': float(tax.quantize(Decimal('0.01'))), 'net': float(net.quantize(Decimal('0.01'))) }

逻辑说明：compute_payroll 里的 insurance 比例 0.105 是我这边的示例数，真实系统要从 D3 社保公积金参数表读取，每个城市的养老、医疗、失业比例不同，年底还有缴费基数上下限调整。calc_month_tax 里已经按累计预扣法处理了“前几个月交少、后面月份补税”的情况，参数 months 和 already_withheld 分别来自发放月数和 D5 工资发放记录表的累计值。

这段脚本和 P3.2、P3.3 两个进程是一一对应的：P3.2 算出 gross，P3.3 算出 insurance 和 tax，P3.4 汇总 net 写入 D4 表。写代码时如果有人问你“这个进程怎么实现的”，直接把这段代码给他看，比任何文字描述都清楚。

3.3 数据字典：让每一根数据流都有据可查

画完图、建完表，还差一个配套文件：数据字典。数据字典不是表结构说明书，它是针对每一条数据流和每一个存储，列出字段级定义的文档。工资管理系统至少要覆盖下面这些数据流。

数据字典的价值不在画图阶段，而在你写代码写到一半的时候。比如 P4 要生成银行代发文件，如果你没有在数据字典里定义“银行代发文件”包含“姓名、银行卡号、实发金额、批次号”这四个字段，代码里就很容易要么漏掉批次号，要么把员工编号当银行卡号导出。把数据字典放进 .doc 里作为第二页，数据流程图才有完整的解释力。

4. 用draw.io画出工资系统的数据流程图：编号规则、图层管理与导出Word的参数

工具选择上，我一般用 draw.io 桌面版，免费且能离线，也可以直接用网页版。课设和中小项目用这个工具足够，Visio 或亿图也可以，但导出到 Word 时要注意的参数都差不多。这一章讲清楚“打开软件到交出一份能进 Word 的图”需要做哪些设置，照着做就不会在导出环节翻车。

4.1 画布、网格线与符号库：设置好这四样再动手

新建绘图后不要急着拖形状，先把页面设置对。文件菜单里打开页面设置，页面尺寸选 A4 横向，因为数据流图是左右展开的，纵向容易把图挤得很窄。网格间距设成 20 像素，开启“网格”和“吸附”选项，这样拖出来的进程和箭头线会自动对齐，不用手动微调。

符号库在左侧形状面板里搜索“Gane-Sarson”，如果软件版本里没有这个库，就用基础形状代替：进程用圆角矩形，外部实体用普通矩形，数据存储用两端开口的矩形，这个开口矩形在 draw.io 的“通用形状”里叫“Curly Brace”？不对，直接搜“storage”或者用矩形加一条开口边都很别扭。更方便的做法是在形状搜索框里输“data store”，一般能直接找到。

正式动手前，把四类符号的尺寸统一，我习惯进程宽 160 高 80，外部实体宽 140 高 60，数据存储宽 140 高 60。选中多个形状后，用“排列”菜单里的“水平居中”“垂直居中”批量对齐。这一步很多人跳过，结果导出的图有的框大有的框小，Word 里看着像草稿。

4.2 图层与编号管理：从上下文图到子图怎么组织

draw.io 支持多标签页，一张图对应一个标签页。我个人的组织方式是建四个标签页：Context、L0、L1-P2、L1-P3。Context 放上下文图，L0 放 0 层图，P2 和 P3 各自复杂度够高时才单独拆 L1 子图页。这样组织的好处是答辩时切换标签页就能演示“父图到子图”的下钻过程，比把三张图堆在同一个画布上清晰得多。

命名规范在 2.1 节已经定了，这里补充一个图层管理的细节：给每个进程设置“复制为”模板。draw.io 里可以右键进程选择“编辑数据”或“属性”，把进程名称提前写成“P3.2 计算应发工资”，后续从形状库拖出来就能直接复用。数据流的命名在箭头上右键“编辑文本”写入，字体大小统一设为 12 号，进程名用 14 号加粗，这样导出后 Word 里的层级关系一眼能看明白。

4.3 导出Word的参数：DPI、字体和保留源文件

画完之后导出 PNG 插入 Word，这一步的坑集中在 DPI 和字体上。文件菜单选择“导出为 → PNG”，弹出对话框里推荐这样设置：缩放 100%，DPI 填 200，阴影选项关闭，透明背景关闭。DPI 200 插到 Word 里打印清晰，一般不会模糊；DPI 再高比如 400，同一张图文件体积会翻几倍，Word 文档打开都卡。

字体是一个容易忽略的点。draw.io 默认字体是 Arial，如果画布里有中文，导出的 PNG 在 Windows 上显示正常，但换到 Mac 上打开 Word 文档，字体可能被替换成苹方，行距和宽度都会变。解决办法是在画图前把全局字体改成“微软雅黑”，在“样式”标签页的 Text 里设置，改完再导出。

导出设置调整好，还有最后一步后悔药：保留 .drawio 源文件。Word 里插入的是 PNG 图片，评审或导师如果当场要求改一个进程名字，图片没法直接改，得回到源文件改完再导。把 .drawio 和 .doc 放进同一个项目目录，或者提交到 git 仓库，这是个成本极低但能救大命的习惯。

5. 绘制与实现中的避坑记录：5个让评审和联调翻车的典型问题

这一章写的都是实际交付数据流程图时反复出现的问题，每一条都是先看现象，再说原因，最后给解决动作。拿这份清单自检一遍，比反复改图效率高得多。

5.1 0层图凭空多出一个数据存储：“考勤汇总表”到底存在哪

现象：0 层图里 D2“月考勤汇总数据”没有和任何进程相连，或者 P2 和 P3 之间直接画了一个存储块，但 0 层图根本没有 D2 这个符号。评审问“这个存储哪来的”，答不上来。

原因：画图时先画了 1 层子图，子图里为了让 P3.2 能取到考勤数据，随手加了一个存储，然后忘记回 0 层图同步。父图子图不平衡，是 DFD 最常见的错误。

解决：每画完一层子图，立即执行一次“输入输出流对照”：把 0 层图中某个进程的所有输入流和输出流列出来，再打开子图逐条核对。D2 如果出现在 P3 的子图里，0 层图的 P3 进程旁边就必须有 D2 这个存储，并且要有数据流把它和 P3 连起来。宁可多花五分钟，也不要抱着“评审不会细看”的侥幸。

5.2 一条数据流挂两个名字，评审问“你到底传的是什么”

现象：一条箭头上写着“员工信息和考勤记录”，或者同一根线上用顿号列了三四个字段名。现场问“这条流到底是哪些数据”，画图人自己也说不准。

原因：画图时嫌箭头太多，图面杂乱，想把同方向的几根线合并成一根，于是把多个数据流名称堆在一条线上。这在数据流图里属于语义错误，一条数据流只能携带一个明确定义的数据结构。

解决：拆线。员工基础信息和考勤记录即使方向相同，也是两条独立的数据流，各自命名。如果觉得箭头过多影响布局，可以把相同起止点的数据流画成平行线，间距拉到最小，而不是共用一根线。

5.3 数据存储名称和数据库表名对不上，联调时翻车

现象：数据流程图里写“D4 工资核算表”，数据库里建的表叫 payroll，代码注释里又写“工资明细表”。项目联调的时候，新人按图找表，查不到，按表找图，对不上，全靠人工翻译。

原因：图和库分开维护，画图的人用中文业务名，建表的人用英文表名，中间缺少一张映射表。短项目还好，项目一长，文档就失效了。

解决：建表时把 DFD 编号直接写进表注释，就是 3.1 节里那种做法。同时单独维护一份映射文档，至少包含四列：DFD 存储编号、DFD 名称、数据库表名、维护负责人。每次改库表结构，同步更新这张映射表，不接受“以后再说”的延期。

5.4 把数据流程图画成了业务流程图，菱形分支到处都是

现象：图里出现了菱形判断框，比如“是否需要缴纳个税”，或者有带条件的循环箭头“审核不通过→退回修改”。整张图看起来像业务流程图而不是数据流图。

原因：把业务流程的决策逻辑错误地塞进了数据流图。DFD 表达的是数据的加工与流动，不是业务的先后顺序和分支条件，它里面没有判断框。

解决：把所有菱形删掉。判断和分支落到数据存储的状态字段上，“个税是否缴纳”表现为 P3.3 计算出的 tax 是否为 0，“审核不通过退回”表现为 payroll.status 从 1 被改为 0，并触发 P3.4 重新生成核算表。数据流图里允许一个数据流复制到多个进程，也可以一个进程有条件地启动，但这些不是用菱形图画出来的。

5.5 没有数据字典，流转字段全靠猜，交接像拆黑匣子

现象：图只有进程和箭头，没有任何字段级定义。接手的人看着“银行代发文件”这根箭头，不知道里面的银行卡号是代发卡号还是员工付款卡号，也不知道文件名是否带批次号。项目交接三个月后再看文档，和看黑匣子一样。

原因：画流程图的精力投在布局和美观上，忽略了只有数据字典才能约束数据流的字段构成。没有数据字典，图就只是装饰。

解决：把数据字典作为 .doc 文档的一部分随图交付，不用很厚，每个数据流给出“字段名、类型、长度、来源、去向”五列即可。工资管理系统里最可能被追问的“银行代发文件”“工资条”“考勤汇总数据”这三条流，必须写清楚。这一条既是避坑，也是给第 6 章的一致性校验提供输入。

6. 用数据字典做一致性校验：让流程图、数据库和代码对得上

文档交付前最后一步，是系统性检查图、字典、数据库三者是否一致。我一般先人工做一遍分层核对，再用脚本把数据字典和数据库 schema 做一次自动化比对。

6.1 三层核对清单：从上下文图到1层图逐项过

把三张图摊开，按下面的清单逐项检查，有一项不过就不能定稿。

6.2 用脚本比对数据字典和数据库 schema

图上的数据字典是人工维护的，数据库是实际建的，两者很容易悄悄跑偏。写一个简单的 Python 脚本，把数据字典导成 CSV，再从数据库 information_schema 导出字段清单，逐一比对。脚本不长，但能节省靠肉眼翻几十张表的时间。

import csv, json # data_dictionary.csv 每行: table,field,type # 示例: payroll,gross,decimal(10,2) dict_rows = {} with open("data_dictionary.csv", encoding="utf-8") as f: for row in csv.DictReader(f): dict_rows[f"{row['table']}.{row['field']}"] = row["type"] # schema.json 由数据库导出生成 # [{"table": "payroll", "field": "gross", "type": "decimal(10,2)"}] with open("schema.json", encoding="utf-8") as f: schema = json.load(f) schema_map = {} for item in schema: schema_map[f"{item['table']}.{item['field']}"] = item["type"] issues = [] for key, dtype in dict_rows.items(): if key not in schema_map: issues.append(f"字典有但数据库缺少字段: {key}") elif schema_map[key].upper() != dtype.upper(): issues.append(f"类型不一致: {key} 字典={dtype} 数据库={schema_map[key]}") for key in schema_map: if key not in dict_rows: issues.append(f"数据库有但字典未记录: {key}") for msg in issues[:100]: print(msg) print(f"共发现 {len(issues)} 个不一致项")

这段脚本输出三类问题：字典里有但库里没有的字段、类型不一致、库里有但字典漏记的字段。我通常把它放到项目脚本目录里，改一次表结构就跑一遍。之前接手一个缺文档的工资系统，靠这个脚本把图、字典、数据库对齐，省下了整整一周联调排错时间。数据流程图做到这个程度，已经不是一份应付检查的文档，而是一份能指导后续开发和维护的可靠地图。希望帮到你。

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