简介：一份面向计算机专业学生、系统设计人员及课程设计/毕业设计开发者的图书馆管理系统数据流图文档。文档围绕图书馆核心业务，详述读者管理、图书管理、借书、续借、预约、处分、催还等模块，并给出顶层进程、第一层子系统及P1借书证管理、P2离校注销、P3图书借阅等逐级分解图，配合DFD与ER图直观展示数据流向与实体关系，可用于系统分析与数据库设计参考。资源为单个doc文件，压缩包仅889KB，便于下载、打印和标注。目前已有107人学习下载，特别适合需要快速掌握图书馆业务流或绘制数据流图的读者。文档内容层次分明，覆盖从借书证办理、挂失补办、离校注销到借阅、续借、预约、催还的全流程，并包括逾期罚款、遗失赔偿等处分管理细节。通过顶层图与逐层展开的DFD，读者可清晰理解模块划分、数据存储与接口关系，为完整的系统建模提供有力支撑。
1. 为什么我劝你先画清楚数据流图再写代码
做图书馆管理系统这类课程设计，最常见的翻车点不是数据库表设计，也不是界面写不出来，而是需求分析阶段就把顶层数据流图画错了。数据流图一旦画错，后面的 P1、P2、P3 逐层分解全是错的，代码写得越多返工越重。这份《图书馆数据流图.doc》的价值在于，它把整个系统的数据流转拆成了顶层图、一层图、P2 借还书管理分解图、P3 读者管理分解图，连 ER 图的问题都顺手标出来了。适合正在做软件工程课程设计、毕业设计前期需求分析的人，也适合刚入职还不会画 DFD 的初级开发。拿到它，你基本能把"读者、图书管理员、图书、借阅信息"这条主线的数据流向抄近路理清，省掉自己从零建模试错的时间。
2. 读懂这份 DFD 的分层结构：从顶层图到 P3.2 借书核查的逐级展开
2.1 顶层图到一层图：先找准外部实体和三条主数据流
顶层图是整张 DFD 的起点，它只交代系统与外界的边界。这份文档里的顶层图只有两个外部实体：读者和图书管理员，中间一个"图书馆管理系统"的加工，数据流也很简单——读者把"图书申请表"送进系统，系统把"图书借阅信息"和"读者借阅信息"送回给读者；图书管理员往系统里录入"新书"，系统把"读者资料"和"图书信息"交给管理员。
这个顶层图画对了一个关键点：外部实体只出现在顶层图，一层图及以下不再出现外部实体。很多新手在画一层图时把"管理员"当加工画进去，这会把数据流图的边界搞混。正确的理解是，读者和管理员是系统外面的角色，所有和他们交互的数据流都只在顶层图表达，一层图里只画加工、数据存储和数据流。
文档里的一层图把系统拆成了三个加工：
| 加工编号 | 加工名 | 职责范围 |
|---|---|---|
| P1 | 图书管理 | 新书登记、维护图书基本信息、剔除旧书 |
| P2 | 借还书管理 | 预约、撤销预约、借书、还书、续借 |
| P3 | 读者管理 | 办理新卡、挂失补办、离校处理 |
三条主数据流分别是"图书/新书信息"（P1 与图书管理员之间）、"索书单、借书卡/借阅信息"（P2 与读者之间）、"读者资料/借书卡"（P3 与读者之间）。这个划分的逻辑依据是职责边界：图书信息流归 P1，借还行为流归 P2，读者身份流归 P3，三者互不交叉。如果借书时要查读者资料，比如 P3.2.1 核查读者身份，它通过"读者信息"数据流去读数据存储，而不是直接去调用 P3 加工，这种跨模块的数据读取在 DFD 里只能通过数据存储发生，不能画加工到加工的直连虚线。
2.2 P1 图书管理的三层分解：数据流编号规则与存储设计
P1 分解为 P1.1 新书登记、P1.2 维护图书基本信息、P1.3 剔除旧书。注意文档里给出的数据流编号是 8、9、10、11，这是整套 DFD 的全局编号，不是每个加工内部单独编号。实操时我一般会用"加工编号-序号"的格式，比如 P1.1-1、P1.1-2，这样在写数据字典时比较容易回溯。
P1.1 新书登记这条流的输入是"新书"数据和"图书管理员"的录入动作，输出是写入"图书信息"数据存储。P1.2 维护图书基本信息，输入是"图书信息"存储里的已有数据，输出是更新后的"图书信息"。P1.3 剔除旧书，读取"图书信息"，输出"图书"实体信息到图书管理员。
这一层最大的设计点在于数据存储只有一个"图书信息"。很多人会把"新书待登记表"和"图书基本信息表"拆成两个存储，这在 DFD 层面是多余的。DFD 里的数据存储是逻辑存储，不是物理表，只要数据流的读写方向一致，一个"图书信息"存储就能覆盖新增、修改、删除三种操作。拆多了反而会让图面混乱，而且会导致数据字典里出现大量没必要的存储条目。
画 P1 分解时还要注意一个细节：P1.1 新书登记和 P1.2 维护图书基本信息之间的顺序关系。DFD 不画顺序，只用数据流表达依赖。也就是说，P1.1 写入"图书信息"存储，P1.2 从同一存储读取，存储本身就约束了"先登记才能维护"的逻辑。如果你把这条先后关系画成 P1.1 到 P1.2 的箭头，就变成数据流图里典型的"控制流混入"错误。
2.3 P2 借还书管理分解：五个子加工的存储划分
P2 是整套系统里最复杂的一块，文档拆分出 P2.1 预约、P2.2 撤销预约、P2.3 借书、P2.4 还书、P2.5 续借五个子加工。数据存储也有四个：预约登记表、读者预约情况、借阅情况、图书信息。
这里值得分析的是"读者预约情况"和"预约登记表"为什么是两个存储。"预约登记表"是预约记录的原始数据，读者提交"预约请求"后写入；"读者预约情况"是借书时要查询的读者预约状态汇总。严格来说，这张 DFD 里两者可以合并成一个存储，但它们被拆开了，原因是 P2.3.4 检查预约记录时只关心"该读者对这本书是否有预约资格"，需要一个面向读者视角的查询视图，而非面向预约流水。理解这个区分有助于你写数据字典时把存储的属性和用途定义清楚，避免一张表塞下所有字段。
P2.4 还书加工读入"还书请求"和"借阅情况"存储，输出"归还信息"和新的"借阅情况"，同时把"借阅情况"更新。这里注意还书流程还隐含了一个催还判断——文档没把催还单独画在 P2 层，而是放到后面文字描述里，这在 DFD 分层里是允许的，因为催还是 P3.6 的职责，P2.4 只负责登记还书动作。
2.4 P2.3 借书子系统的四步核查：文档里最值得抄的流程
P2.3 借书管理被拆成五个加工，是最细的一层分解，也是全书最有价值的一段。它的处理逻辑是顺序网关式的审查链：
| 加工编号 | 加工名 | 输入 | 输出 | 判定条件 |
|---|---|---|---|---|
| P2.3.1 | 核查读者身份 | 读者资料、读者信息 | 合法借书卡 | 读者资料存在且状态正常 |
| P2.3.2 | 核查读者违规情况 | 违规情况 | 无违规 / 违规处罚通知 | 存在未处理违规则拦截 |
| P2.3.3 | 检查读者借书限额 | 借阅情况、读者信息 | 限额内 / 额度已满通知 | 当前借阅数小于上限 |
| P2.3.4 | 检查预约记录 | 预约登记表、图书预约信息 | 预约情况 | 该书有预约且此读者为预约人 |
| P2.3.5 | 登记借阅情况 | 借书卡、图书信息 | 借阅情况（新记录） | 以上四步全部通过 |
这条链的判定条件是顺序依赖的，前一步不通过就不进入下一步。画 DFD 时，P2.3.1 到 P2.3.5 之间的数据流用的是"合法借书卡""无违规""限额内""预约情况"这些条件性数据。有人会把"通过/不通过"当成两条数据流画出来，这会让图面爆炸。常见做法是：只在通过条件下画数据流到下一个加工，不通过则画一条数据流到输出端（比如"违规处罚通知"直接流向读者），DFD 里不需要为每个判定分支都画箭头。
P2.3.4 检查预约记录里有个隐蔽细节——它读的是"预约登记表"和"图书预约信息"，输出"预约情况"给 P2.3.5。"图书预约信息"和"预约登记表"的差别在文档里没明说，我按实际经验理解是这样：预约登记表是按读者维度记录"谁约了什么书"，图书预约信息是按图书维度记录"这本书被谁约了"。借书时要同时读两个视图，才能判断"读者确实预约且优先权轮到该读者"。如果你在数据字典里只定义一张预约表，这个双视图模型就丢了。
3. 读者管理与图书管理的边界：P3 分解图里容易被忽略的三个设计决策
3.1 P3 三层分解：新卡、挂失补办和离校处理的数据流走向
P3 读者管理分解为 P3.1 办理新卡、P3.2 挂失补办、P3.3 离校处理。输入分别是"读者资料"（新读者信息）和"补办申请表""毕业登记表"。P3.1 输出"新卡号"，写入"读者资料"存储。P3.2 挂失补办读取"读者资料"和"读者借阅情况、违规情况"，输出"补办申请表"处理结果。P3.3 离校处理是全书里最特殊的一个加工——它不只是读数据，还写了"读者借阅情况、违规情况"。
这里有一个很多初学者没意识到的问题：离校处理发生在读者已毕业离校之后，此时读者与图书馆的借贷关系已经结束，如果按正常业务逻辑，离校处理应该读取"借阅情况"来判断未还书，再输出"注销读者资料"的结果。但这份文档里 P3.3 把"读者借阅情况、违规情况"同时作为输入和输出，我的理解是：离校处理不仅要判断是否有未还图书，还要更新读者的违规记录（比如离校时缴纳罚款后的状态变更），同时做读者状态位的置为"已注销"。数据流图里一个数据流同时作为输入和输出是允许的，常见于"更新型"加工，这是 DFD 里合法的表达方式，不是文档画错了。
3.2 读者与图书的关系建模：为什么直接多对多会出问题
文档最后特别指出：ER 图存在缺陷，读者和图书的关联应该是多对多，或者将借书单与图书关联，而图书管理员与读者借书规则和图书借阅期限不应建立关联。这句话值得展开。
读者和图书之间确实是多对多：一个读者可以借多本图书，一本图书也可以被多个读者先后借阅。但直接把读者和图书之间画多对多关系有一个缺陷——"借阅时间点"放哪里。如果读者与图书是多对多，需要在关系中带属性，比如借书日期、还书日期、到期日期。ER 图的标准做法是把这种多对多关系提升为一个实体，也就是"借书单"或"借阅记录"。
所以这份文档里第二段话实际上给了两个可选的修正方案：
方案一是保留读者与图书多对多，关系命名为"借阅"，关系上挂"借书日期""应还日期""实际还书日期"属性。这种建模方式适合概念模型阶段，表达直观，但在做数据库逻辑设计时要转换成中间表。
方案二是不画读者到图书的直接关系，而是引入"借书单"实体，读者与借书单是一对多，借书单与图书是一对一（或一对多，视多本书合并成一单还是一本书一单而定）。这种建模方式更接近业务流程，因为一次借书行为确实会产生一张借书单。
图书管理员与"读者借书规则"和"图书借阅期限"不应建立关联，这句话的意思是：借书规则（比如最多借几本、借期多长）是一种配置数据，它不属于管理员实体的属性，而应该是独立实体。管理员只是操作这些规则的人，不是规则的拥有者。你在画 ER 图时如果把"借书规则"挂在管理员上，后续规则调整时的操作逻辑就会纠缠不清。
3.3 数据流字典里必须定义的字段：以索书单和借书卡为例
读完这份文档你会发现，文本描述里反复出现"索书单""借书卡""读者资料"这些词，但 DFD 图里它们只是箭头上的标签。要真正落地到数据库，需要给每个数据流写数据字典。以我画这类图的做法，至少要为以下数据流定义字段：
索书单的字段结构建议定义为：图书编号、书名、作者、出版社、ISBN、馆藏位置、索书号。借书卡定义为：卡号、读者编号、读者类型、办卡日期、有效截止日期、状态（正常/挂失/注销）。读者资料定义为：读者编号、姓名、证件号、院系、年级、联系方式、借书限额、当前借阅数、违规累计次数。
文档正文里没给出这些字段，但数据流图承载的信息密度不足以直接建表，你必须靠数据字典补齐。这也是我劝你不要只下载 DFD 就开写代码的原因——图解决的是流程和边界，字典才能定义数据结构。
4. 避坑与排查：画图书馆数据流图最常见的五个错误
4.1 顶层图把"图书"当成外部实体，导致一层图实体重影
现象：有人画顶层图时把"图书"也画成一个外部实体，理由是图书管理员要从系统里取书给读者。
原因：外部实体必须是系统边界之外的角色，图书是被系统管理的资源对象，不是参与者。图书的数据流应该通过"图书信息"存储流转，而不是作为实体进出系统。
解决：删掉"图书"这个外部实体。如果觉得缺了图书信息展示，把"图书信息"改成数据存储，只有管理员和读者才能作为外部实体出现在顶层图里。
4.2 一层图直接出现 P2.3.1，跳过了 P2 这一层
现象：画一层图时，为了省事直接把借书核查流程画进一层图，从读者直接连到"核查读者身份"加工。
原因：没有理解分层规则。每一层加工都是上一层的展开，跳层会让图的可读性崩溃，别人读图时无法判断 P2.3.1 到底属于哪个模块。
解决：严格按 P1、P2、P3 三层骨架走，一层图只画到二级加工，继续展开时另起一张子图单独画 P2 的分解。一般一张 DFD 图不要超过 7 个加工，超过就继续分层。
4.3 借书核查链遗漏"违规情况"数据流，导致核查变摆设
现象：P2.3.2 核查读者违规情况时，没有从"读者违规记录"存储拉数据流，加工被画成一个没有输入只有输出的空壳。
原因：照猫画虎抄图时漏掉了数据流线。这类漏线在 DFD 里属于"悬空加工"——加工必须有输入流和输出流，否则它无法完成任何数据处理。
解决：自查加工时逐个核对：每个加工至少有一条输入流、一条输出流，输入流必须来自其他加工或存储，输出流也必须去往其他加工或存储。P2.3.2 的输入是"违规情况"存储，输出是"无违规/违规处罚通知"，这条线缺失就补上。
4.4 数据流命名含糊，同一个流叫法不一致
现象：顶层图叫"读者借阅信息"，到了 P2 层却叫"借阅信息"，数据字典里没法对齐。
原因：文档在不同层级用了不同粒度命名，这在原始 DFD 里允许，但在落地建表时会造成字段映射混乱。
解决：我习惯在做数据字典时给每个数据流一个全局编号，命名只保留一个官方名称，其他层级的叫法全部统一过去。例如顶层图"读者借阅信息"在 P2.4 中改叫"借阅情况"，以"借阅情况"为标准流入流出。
4.5 ER 图画完没检查是否有多对多关系未实体化
现象：读者和图书之间只画了单箭头，标识"读者借图书"，数据库设计时只建了两张表，借阅记录无处存放。
原因：ER 图里把多对多直接画成一条线，没有把关系转成关联实体，也没有在关系上挂属性，导致后续建表缺少借书信息表。
解决：按文档提示，要么把借阅关系实体化为"借书单"，要么在读者与图书关联线上明确标注 M:N 并列出关系属性。推荐方案是独立建一张"借阅记录"表，字段至少包括读者编号、图书编号、借书日期、应还日期、实际还书日期、续借次数、状态。
5. 用 Visio 把 DFD 画出来：图层管理、数据流编号与排版三件套
5.1 先搭好四个图层，再画加工和数据流
用 Visio 画数据流图时，我通常先把图层结构定下来，而不是直接开画。推荐开四个图层：外部实体层、加工层、数据存储层、数据流层。
图层顺序从下到上是外部实体层、数据存储层、加工层，数据流永远画在最上层。原因很简单：外部实体和数据存储是静态元素，加工是动态元素，数据流覆盖在上面不会遮挡底层的静态节点。
Visio 里的具体操作是这样：在"视图"选项卡里点击"图层面板"，新建四个图层，然后把每个形状选中并指定所在图层。外部实体（读者、图书管理员）放在"外部实体层"，加工放在"加工层"，数据存储（图书信息、借阅情况等）放在"数据存储层"，所有的箭头连线选中后设为"数据流层"。设置完成后，画连线时默认落在数据流层，后续批量调整颜色和线型时一键操作。
提示：连线一定不要画在加工层。如果你后续要做图面批量布局，连线设错了图层会跟着加工一起移动，半天排好的版一夜回到解放前。
5.2 数据流编号规范与数据字典模板
Visio 画完图之后，真正交付的不是图形本身，而是数据字典。文档里 DFD 图没有给每个数据流配数据字典，你需要自己补，这恰恰是课程设计里拿分的地方。
数据流编号我建议分两级：第一位是加工编号，第二位是数据流序号。比如 P1.2-1 表示图书管理模块里"维护图书基本信息"加工的第 1 条数据流。存储编号用 S 开头，S1 是图书信息、S2 是借阅情况、S3 是预约登记表、S4 是读者资料。
| 编号 | 数据流名 | 来源 | 去向 | 数据组成 |
|---|---|---|---|---|
| P1.1-1 | 新书信息 | 图书管理员（外部） | P1.1 | 图书编号+书名+作者+ISBN+馆藏位置 |
| P2.3-1 | 借书请求 | 读者（外部） | P2.3.1 | 读者编号+图书编号 |
| P2.3-5 | 借阅情况（新） | P2.3.5 | S2 借阅情况 | 读者编号+图书编号+借书日期+应还日期 |
数据字典的条件项要跟 DFD 图里判定条件对齐。P2.3.1 到 P2.3.5 之间的输出条件在数据字典里写成"数据组成 + 触发条件"，比如"合法借书卡（读者资料存在且状态正常）"，这样看字典的人能反推出加工的逻辑。
5.3 排版检查清单：不重名、不悬空、数据流有方向
画完图不是终点，我用一张检查清单做交付前的自动化检查。每个加工至少一条输入流一条输出流；没有两条数据流重名；数据流必须有箭头，禁止无向线段；数据存储至少被一个加工读写；外部实体不再出现在一层以下；同一层图里加工数量不超过 7 个。
6. 验证 DFD 正确性：用数据流方向追踪法查漏补缺
图画完并写完数据字典之后，最有效的验证方法不是反复看图,而是沿着某一条具体业务路径做一次"行走"，检查数据流是否能在加工之间完整传递。
拿"读者预约→到馆借书"这条路径举例。读者先发起预约请求，进入 P2.1 预约加工，P2.1 写"预约登记表"存储。预约成功后读者到馆提出借书请求，进入 P2.3.1 核查读者身份，再到 P2.3.2 核查违规情况，下一步 P2.3.3 检查借书限额，再下一步 P2.3.4 检查预约记录，此时必须能从"预约登记表"里读出该读者的预约数据。如果 P2.3.4 的输入存储画成了"读者预约情况"而不是"预约登记表"，会表现为同一数据在图上出现两次却没有关联。
根据这些细节，我会对每个加工的输出和输入做一轮"变量追踪"：把这个加工输出的数据流名，去所有下游加工里找同名的流入；如果找不到，说明数据流断了，需要检查是命名不一致还是确实漏画了。还有一个我自己常用的技巧是倒着查：从最末端的数据存储开始，逐个加工反向追踪输入来源，看每条输入的来源加工是否确实会产生这个输出。反向追踪能查出"凭空产生数据"的问题，这在正向画图时经常被漏掉。
借书完成的瞬间，系统要把新的借阅情况写回存储，同时更新读者的当前借阅数。如果 DFD 里只画了"借阅情况"的写入流，没有同步"读者信息"的更新流，那 P3.2 挂失补办时读到的读者借阅数就是旧值，限额检查会失灵。这类问题在静态检查时很难发现，只有按路径追踪才能暴露。
我建议你拿到这份文档后，先按文中列出的数据字典模板补全所有数据流，再用路径追踪法把"预约→借书→还书→续借"和"新书登记→借出→还回→剔除"两条主链路走一遍，凡是追踪过程中出现断点的位置，就是 DFD 图需要修正的地方。这套验证做完，你的课程设计需求分析部分基本就夯实了。从那以后我每次画完数据流图都强制走一遍路径追踪，这习惯帮我在答辩前救回过好几个漏画的存储。希望帮到你。
本文还有配套的精品资源，点击获取
