简介这是一份面向软件工程、信息管理类专业课程设计与毕业设计的图书馆管理系统设计文档系统梳理了图书馆管理系统的完整开发设计方案。内容覆盖需求分析、系统目标、功能结构图、业务流程图、顶层与分层数据流图、总体ER图及数据字典完整呈现从用户管理、书籍类型管理、书籍管理、借阅管理、读者管理到系统管理的模块划分与数据交互关系文档对借书、还书、图书查询等核心流程均有详细说明并对系统管理员、图书管理员、借阅管理员三类角色的功能需求做了清晰定义同时给出书籍类别标准的制定、类别信息与书籍信息的增删改查等具体操作要求可作为课程设计文档写作或实际开发的直接参考。压缩包内包含1个doc文档大小约1MB图文并茂便于直接查看和修改。已有3099人学习适合需要快速梳理系统设计思路并完成课程报告或毕业设计文档的同学参考。1. 图书馆管理系统先画对图业务流程、DFD、ER图是一套而不是三套很多人拿到“图书馆管理系统”这类题目习惯性动作是打开数据库工具先建表表建完了再回头补 ER 图业务流程图和数据流程图干脆凭印象画个大概。等到交付《图书馆管理系统业务流程图 数据流程图 ER图.doc》这种文档时才发现三张图各说各话评审一追问“逾期拦截”在数据流程图里为什么没有对应加工当场卡壳。这三张图不是三种画法而是同一套系统三次逼近业务流程图回答“谁在什么条件下做什么”数据流程图回答“数据从哪来、经过哪些加工、存到哪里”ER 图回答“这些数据长什么样、彼此什么关系”。顺序只能是从业务到数据再到 ER最后落到表结构。反着做大概率返工。这篇按这个顺序拆开讲每一步给可直接抄的动作、图符规范和参数约定适合正在做系统分析文档、课程设计或接单交付这类文档的从业者。2. 业务流程图怎么画借书场景的泳道拆解与流程编号规则2.1 先分清业务流程图和数据流程图判断点该留在哪张图业务流程图Business Process Diagram很多教材里简写为 TFD解决的是“业务动作怎么分工”。它面向业务方画的是角色、动作、判断和单据流转目的是确认需求有没有漏。常见画法是泳道图横向泳道代表角色矩形是任务菱形是判断箭头是流转方向开始和结束用圆角矩形或椭圆。这里有一个最容易串的门槛业务流程图可以画判断分支数据流程图不能画。判断属于控制流是“谁拍板、卡不卡”DFD 只管“输入什么数据、输出什么数据、存到哪里”。所以如果你在业务流程图里把“读者信息存储”画成一个文件柜符号或者把“系统自动写入借阅记录”当成一个判断菱形说明两张图的边界还没分清。业务流程图里的判断到 DFD 里会变成加工内部的校验逻辑不会作为菱形出现。符号这块不需要自己发明。Visio 的“跨职能流程图”模板、ProcessOn 或 Draw.io 都能直接拖拽。文档里至少固定一套图例并写进前言后面每张图严格按图例来。图例建议用这张表元素图形含义开始/结束圆角矩形流程的起点或终点任务矩形一个业务动作例如“办理借出登记”判断菱形条件分支例如“是否有逾期未还”数据或单据矩形带折角借阅凭条、罚款单等实物单据流转带箭头实线动作之间的先后顺序泳道横向分区读者、馆员、书库管理员等角色分工流程编号规则建议一步到位流程代码加两位序号。借书主线用 BK 开头还书用 RT预约用 RS罚款用 FN。例如 BK-01 表示借书流程第一步D-01 表示第一个判断点。这个编号后面会用到数据字典里做追溯别嫌麻烦。2.2 借书主流程一张泳道图把角色和决策点钉死借书是图书馆管理系统的主干线也最容易被画乱。我一般把参与者分成三列泳道读者、前台馆员、系统自动任务很多模板把“系统”单独拉一条泳道但要注意系统动作和馆员动作不要混在同一行否则读者看不懂是谁在干。借书主线建议按下面这张步骤走第一步读者选书并出示读者证。这是读者泳道里的动作不需要展开到“打开手机App出示二维码”这种页面粒度。第二步馆员验证读者证有效性这里放第一个判断 D-01证件有效还是挂失、过期第三步查读者借阅状态放判断 D-02有无逾期未还图书或欠款超限有则拦截并引导去还书和交罚款这一步在业务流程图里必须画出来否则后面 DFD 里对应的“校验读者资格”加工就没有业务依据。第四步查询馆藏副本状态判断 D-03副本是在馆、已借出还是已被预约其中“已被预约”的副本要保留给预约读者不能借出这是很多初版流程图漏掉的分支。第五步办理借出登记记录读者证号、馆藏副本号、借出日期和应还日期。第六步更新副本状态为“借出”打印借阅凭条。第七步交付图书流程结束。应还日期的计算建议在文档里写成一个参数约定借期 30 天应还日期 借出日期 30 天预约图书到期前 3 天通知保留 7 天。这些数字会直接影响 ER 图里“应还日期”到底该存成属性还是派生值以及罚款计算用的逾期天数所以文档里一定写清楚不能留到写 SQL 时才随便定。这一步容易犯的错是把判断画得太碎。比如“读者证号是否输入正确”“图书条码是否扫描成功”这类系统校验属于页面交互不是业务流程图该关心的事。业务流程图画到事件级一次借书请求、一次还书请求、一次罚款结算这个粒度刚好够后续 DFD 展开。2.3 还书、预约、罚款三条支线画到事件级就够了还书支线不比借书简单。完整动作是读者交回图书馆员验收图书状态判断有没有破损、缺页或涂画验收通过则更新副本状态为“在馆”然后查借阅记录判断是否逾期逾期按 0.1 元/天/册生成罚款单最后打印还书回执。这里有两个细节容易被漏画一是还书时的“验收图书”判断它对应未来馆藏副本表上的“状态”字段破损图书不应直接回到可借状态二是逾期不是读者主动交钱才触发而是在还书记录里自动算出罚款单所以罚款支线的起点在还书支线里。预约支线的完整路径是读者发现某本书全部副本已借出提交预约申请系统把预约排进队列按预约时间排序有还书还回时通知第一顺位读者到馆办理到馆后保留 7 天超时自动释放给下一位。这里的判断点是“是否为第一顺位”和“是否在保留期内”画分支时只要这两个菱形。罚款支线的触发点有两个一个是还书时计算逾期费另一个是读者再次借书时D-02 判断发现欠款超限。罚款单要有独立编号、金额、缴纳状态缴纳状态又影响下一次借书资格。这条支线如果流程图里没有画出来ER 图里就不需要“罚款单”实体后面建表自然少一张表。业务流程图的价值就是让你早点意识到不做罚款模块很多流程走不通。这三条支线在文档里可以用文字加参数表述也可以并成一张支线参数表。参数建议这样写借期 30 天续借次数最多 1 次续借期 15 天如果业务里允许续借逾期费 0.1 元/天/册预约保留 7 天押金或欠款上限 10 元。别小看这些数字它们是后面所有图里判断条件的来源。“图书馆座位管理系统”这类同构系统也一样把“馆藏副本”换成“座位”“借阅”换成“预约使用”流程骨架完全相同。3. 数据流程图DFD怎么分层用加工、存储把业务图译成数据图3.1 DFD 的四要素和业务流程图的三条翻译规则数据流程图Data Flow DiagramDFD是结构化系统分析的产物很多人从业务流程图直接跳到 ER 图中间缺了它导致实体和属性没有来源。DFD 只有四类元素外部实体方框、加工圆角矩形或圆圈带编号、数据存储开口矩形、数据流带箭头实线必须命名。从业务流程图翻译成 DFD 有三条规则每一条都对应一类常见返工。第一外部实体来自业务流程图里的角色但“馆员”不一定都是外部实体馆员操作“借出登记”时馆员是外部实体馆员在系统内做“编目审核”这个审核本身就是加工馆员只是触发者加工的所有权和数据转换才是 DFD 的重点。第二业务流程图里的每个判断菱形在 DFD 里变成加工内部的一组条件处理菱形不画。比如“判断读者是否有逾期”在 DFD 里是加工“校验读者资格”输入“读者证号”输出“校验通过或拒绝原因”控制流消失在加工内部。第三业务流程图里的实物单据如果不需要存储备查就不出现在 DFD 里借阅凭条打印给读者这个数据流出加工到外部实体“读者”即可不需要画一个“凭条存储”。工具选择上传统结构化分析常用 Yourdon 或 Gane-Sarson 记号Visio 自带 DFD 模板Draw.io 里也能选。早年有人用 Rational Rose 画这类图但它更多服务于 UML 用例和类图画 DFD 并不顺手现在主流是通用绘图工具直接套模板。3.2 顶层图、0 层图、1 层图父子图必须平衡DFD 的核心方法是分层不是一张图画到底。顶层图也叫上下文图只有一个加工就是整个“图书馆管理系统”。外部实体建议画三个起点读者、馆员、图书供应商。读者发来借阅请求、还书请求、查询请求接收凭条和通知馆员发来借阅登记操作、还书验收结果接收操作反馈图书供应商提供书目和到馆批次数据接收采访订单。如果系统包含缴费功能还可以加“财务”作为外部实体但不建议一开始就铺开外部实体越多评审时被追问的边界问题越多。0 层图把顶层加工拆成五个主要加工1 采访、2 编目、3 流通、4 检索、5 统计报表。这一层的输入输出流要和顶层图严格对应。比如顶层图里“借阅请求”流进系统在 0 层图里必须进到加工 3 流通不能跑进采访。1 层图只挑最复杂的加工展开通常展开 3 流通3.1 借出登记、3.2 还书处理、3.3 续借、3.4 预约、3.5 罚款结算。分层对照表可以这样写层次加工编号加工名称主要输入流主要输出流涉及数据存储顶层无图书馆管理系统借阅请求、还书请求、书目信息借阅凭条、通知、订单无0 层1采访采购申请、供应商书目订单、退货单供应商存储、订单存储0 层2编目到馆批次、书目原始信息编目后的书目记录书目存储、馆藏副本存储0 层3流通借阅请求、还书请求借阅记录、罚款单读者存储、馆藏副本存储、借阅记录存储0 层4检索检索条件查询结果书目存储、馆藏副本存储0 层5统计报表统计口径报表文件借阅记录存储、罚款存储1 层3.1借出登记读者证号、馆藏副本号借阅记录、状态更新写借阅记录存储、写馆藏副本存储1 层3.2还书处理馆藏副本号、归还日期状态更新、逾期标记读借阅记录存储、写馆藏副本存储1 层3.3续借借阅记录号、续借申请新的应还日期读写借阅记录存储1 层3.4预约读者证号、书目标识预约记录、到馆通知写预约存储、读馆藏副本存储1 层3.5罚款结算罚款单号、缴纳信息缴纳记录读写罚款存储、读读者存储分层有个铁律叫父子平衡父图中某个加工的所有输入输出流必须和它的子图边界流完全一致。最常见的翻车现场是0 层图里“3 流通”的输入只有借阅请求和还书请求但 1 层子图边界上却多画了续借请求、预约请求两根新箭头。只要出现这种情况评审一眼就能看出图是分两次画的彼此没对上。解决方法是先定 0 层加工清单和每个加工的输入输出再动笔展开子图子图边界一个流都不能加也不能少。3.3 数据字典DFD 里的箭头不是猜出来的是查出来的DFD 画完只是骨架肉是数据字典。没有数据字典的 DFD每个箭头都经不起追问“借阅请求”这个数据流组成部分到底是什么是读者证号加馆藏副本号还是再加预计归还日期写清楚的人很少被评审问倒的人很多。数据字典条目至少包含五项名称、别名、组成、来源、去向。拿借阅记录存储举例条目写成名称“借阅记录存储”别名“BORROW”组成为“借阅流水号 读者证号 馆藏副本编号 借出日期 应还日期 实际归还日期 经办馆员编号”来源“3.1 借出登记”去向“3.2 还书处理、3.3 续借、5 统计报表”。注意不要把“是否逾期”放进组成里它是派生项由实际归还日期和应还日期比较得出存不存是 ER 图阶段的事数据字典里先标注为派生属性。给一本书的迁移就不展开了但建议你把所有数据存储、以及每个 1 层加工的主要输入输出流都写成条目。文档里数据字典单独成节放在 DFD 图之后。这样 ER 图的每个实体和属性都能指着数据字典说“我在这里有依据”评审就算想挑刺也无从下口。4. ER 图怎么画从 DFD 存储抽实体把“借阅”正确建模成联系4.1 实体清单从数据字典的存储里挑名词而不是把表搬过来很多人的 ER 图是从建表语句反推的画出来的只是表结构图形化不是真正的 ER 图。标准的做法是从 DFD 的数据存储和加工输入输出里抽名词先问一个问题这个名词离开其他概念能不能独立存在按这个标准过一遍图书馆管理系统得到的实体集通常是读者、馆员、书目、馆藏副本、出版社、供应商、罚款单、预约单。注意“借阅记录”暂时不放进实体列表因为它是读者和馆藏副本之间的 M:N 联系在 ER 图里应该画成菱形加属性而不是矩形。属性也不要照抄数据字典。字典里“读者证号 姓名 手机号 读者类型 注册日期 状态”都留下了但“当前欠款金额”别放进读者实体它是罚款联系统计出来的派生值“在借数量”同理属于可用查询推导的内容。多值属性单独处理如果读者允许留多个联系电话要么拆一个“读者电话”弱实体或独立表要么在文档里明确约定只保留一个让模型保持单值属性。这个选择没对错但必须写清楚否则建表时又纠结。实体清单可以整理成表格作为文档里的核心交付物实体关键属性来源说明读者读者证号、姓名、手机号、读者类型、注册日期、状态读者存储主键读者证号馆员馆员编号、姓名、岗位馆员存储主键馆员编号书目书目ID、ISBN、书名、作者、分类号、出版社ID书目存储一本书的逻辑描述馆藏副本副本流水号、书目ID、入馆日期、状态馆藏副本存储每本物理书一条记录出版社出版社ID、名称、地址书目辅助数据可选但建议保留供应商供应商ID、名称、联系人订单存储采访模块需要罚款单罚款单号、金额、生成日期、缴纳状态罚款存储依赖借阅记录存在预约单预约单号、读者证号、书目ID、预约时间、通知状态预约存储可并入借阅联系单独建模更清晰4.2 联系与基数当前借出、历史借阅、罚款别混成一个菱形ER 图的核心不是实体而是联系。图书馆管理系统里最容易画错的就是“借阅”。按业务语义一个读者能借多本书一本书能被多个读者借过所以直观联系是读者与书目或馆藏副本之间的 M:N。但如果把联系画成“读者 M:N 书目”会丢掉一个重要维度同一本书有多个副本读者借的是那个物理副本不是书目。因此正确的联系应该建立在“读者”和“馆藏副本”之间。马上去建模还有第二个坑同一读者和同一副本之间历史上可能有多次借阅还了再借。如果只画一个 M:N 联系无法表达“这是第一次借还是第二次借”。所以建议拆成两个语义第一个是“历史借阅”联系读者与馆藏副本之间 M:N联系属性是借出日期、应还日期、实际归还日期。它对应借阅记录存储是流水数据。第二个是“当前持有”状态它不是一个真正的 ER 联系而是可以由“历史借阅”联系中实际归还日期为空推导出来的派生状态。如果你在 ER 图上额外画一个“当前借出”的 1:N 联系我也见过不少教材这么干但要明确标注它是冗余建模只在查询性能成为瓶颈时才值得加。其他联系按基数逐个理清书目 1:N 馆藏副本一本书包含多个物理副本馆员 1:N 借阅记录一个馆员办理多次借阅登记读者 1:N 罚款单一个读者可能有多个逾期记录罚款单与借阅记录之间是 1:1 或 1:N取决于一次逾期是否允许多次分期缴纳建议文档里写一个业务假设一次逾期产生一张罚款单缴纳状态只记录“未缴/已缴”不允许分期模型就保持 1:1。预约联系建议画成读者 M:N 书目带属性预约时间、通知状态、排队顺位。基数标注建议直接用 (min, max) 写在联系两端例如读者参与借阅的基数 (0, N)馆藏副本参与借阅的基数 (0, 1)后者表达“同一副本同一时刻最多只能有一个未归还的借阅记录”。这个 (0,1) 比写成 N 要准确得多也是评审爱问的点。列表整理如下联系名参与实体基数属性说明包含书目、馆藏副本1 : N无书目下的物理副本借阅读者、馆藏副本M : N借出日期、应还日期、实际归还日期历史流水可重复当前持有读者、馆藏副本1 : N借出日期派生联系建议不建模经办馆员、借阅记录1 : N无谁办理的借阅产生借阅记录、罚款单1 : 1罚款单号、金额、状态逾期还书触发预约读者、书目M : N预约时间、通知状态排队队列4.3 弱实体与联系属性馆藏副本和借阅日期该怎么画图书馆管理系统里有一个标准弱实体馆藏副本。一本物理书离开书目就没有独立标识你没法只说“第 3 本”而不说是哪本书的第 3 本。所以在 ER 图里馆藏副本用双矩形表示主键由书目ID 副本流水号组成副本流水号在书目内唯一。画法上弱实体和它依赖的书目之间用双菱形连接主键里依赖实体提供的部分加双下划线。这个细节在《数据库系统概论》的 ER 图例题里几乎是必考交付文档里建议专门用一小段文字说明为什么这么画。罚款单算不算弱实体它有自己的单号可以独立标识是强实体但它在业务上强制依赖借阅记录存在没有借阅就没有罚款。这种情况在 ER 图里用普通矩形和 1:1 联系表达不需要双矩形。判断标准只有一个离开依赖方实体能否凭自己的属性唯一标识一个实例。联系属性是最容易画歪的地方。借出日期、应还日期、实际归还日期应该挂在“借阅”联系菱形上不能挂到“读者”或“馆藏副本”实体上。原因是这些日期完全依存于一次借阅行为本身离开“哪位读者在什么时候借了哪个副本”这个组合日期没有意义。如果把它们放到读者实体里一个读者多次借书时这些日期就没处存放到馆藏副本实体里同一副本不同时期的借阅日期会互相覆盖。考试题里“画出电影评分与评价的 ER 图”考的是同一个道理评分值属于“评价”联系不属于用户也不属于电影。工具方面不多纠结。现在用 Draw.io、ProcessOn 画 ER 图都很方便早年用 Rational Rose 画 ER 图的习惯已经很少见了。重要的是建模过程不是图面美观。如果系统已经上线、数据库里已有表可以用 MySQL Workbench 的 Reverse Engineer 反向导出 ER 图但反向图只反映现状不会替你判断弱实体和派生联系文档里的 ER 图还是要手工整理成“设计态”而不是“现状快照”。5. ER 图转 MySQL 的避坑自查四个最常见建模坑画完就踩5.1 转换规则先钉死外键放在 N 端M:N 单独建中间表ER 图到关系模式的转换是有标准规则的先把规则焊死在文档里表结构就不会跑偏。1:1 联系在任意一端加对方主键作为外键并给外键加唯一约束1:N 联系外键一定放在 N 端M:N 联系单独建一张中间表两端外键联合做主键或自增主键联系属性作为中间表的列弱实体弱实体表的主键由依赖实体主键加判别字段拼接其中依赖部分同时是外键。用本项目举例ER 图元素转换结果书目 1:N 馆藏副本馆藏副本表加 book_title_id 外键读者 M:N 馆藏副本借阅建 borrow_record 中间表含 reader_id、copy_id 和三个日期读者 1:N 罚款单罚款单表加 reader_id 外键借阅记录 1:1 罚款单罚款单表加 borrow_id 外键并加唯一约束馆藏副本弱实体主键为 book_title_id copy_seqbook_title_id 同时是外键这五条转完表清单就齐了reader、librarian、book_title、book_copy、publisher、supplier、purchase_order、borrow_record、reservation、fine。借阅记录在这一步定生死下面四个坑全围着它转。5.2 坑一联合主键挡了“还了再借”的同一本书现象设计 borrow_record 表时用 reader_id 加 copy_id 做联合主键看起来很合理。等系统跑起来读者把一本书还了之后再去借同一本第二条记录插入直接报主键冲突应用日志里一片 Duplicate entry业务上完全没做错任何事。原因联合主键表达的不变量是“同一个读者和同一个副本之间只能有一条记录”这更接近“当前借出”状态而不是“历史借阅”流水。把它用在流水表上等于把状态和流水混在一个模型里。解决borrow_record 改用自增主键 borrow_id每次借书都是一条新流水。当前借出状态靠查询“return_date IS NULL”得出也可以靠馆藏副本表的 status 字段辅助判断。如果担心并发下同一副本被重复借出不要回到联合主键用数据库的条件唯一索引兜底MySQL 8.0 可以给 copy_id 加函数索引条件限定 return_date IS NULLMySQL 5.7 的折中做法是加一个虚拟列 current_flag虚拟列在 return_date 为 NULL 时取 copy_id有值时取 copy_id 的反码。这个细节写进文档就够了不要为了省事退回联合主键。5.3 坑二联系上的日期被下放到实体表冗余夹着脏数据来现象文档里 ER 图明明把借出日期画在“借阅”菱形上建表时有人图省事在 reader 表加了一个 last_due_date 列又在 book_copy 表加了一个 current_borrow_date 列。结果还书时只更新了 borrow_record忘记同步 reader 表上的 last_due_date第二天统计逾期报表两张表数据对不上。原因联系属性在 ER 图阶段没有真正被理解到建表时凭着“这个字段哪哪都用得上”的感觉乱放。如果 ER 图里棱形上的属性要复制到实体表除非有明确的冗余建模理由否则就是脏数据源头。解决借出日期、应还日期、实际归还日期只存在于 borrow_record 表。读者当前欠款金额、在借数量这类派生值一律不建列需要时用聚合查询现算。文档里要加一句设计约定除唯一索引和性能优化外不允许出现可由其他列推导的冗余列。5.4 坑三馆藏副本表上放“当前借阅人”表之间环环相扣删不动现象为了查询方便给 book_copy 表加了一个 current_reader_id 外键同时 borrow_record 表里又有 copy_id 外键指向 book_copy。这样 book_copy 和 borrow_record 形成了双向引用。删除一个读者时数据库报外键约束错误得先手工清掉一堆关联记录代码越写越复杂。原因这是典型的循环外键。当前借阅人这个信息本来就可以通过 borrow_record 的 return_date IS NULL 查出来单独在 book_copy 上留外键列只是给并发查询省一点事却让删除路径变得一团糟。解决删掉 book_copy.current_reader_id借出状态用 status 字段表达在馆、借出、预约保留、维修。业务上需要查“谁借了某本书”时join borrow_record 即可。删除顺序上也做个约定先删子表记录borrow_record、fine、reservation再删父表reader、book_copy、book_title。如果外键都设了 ON DELETE CASCADE顺序问题不大但 DELETE CASCADE 不要乱用连锁删除在审计时很难恢复数据。5.5 坑四工具正向工程把中间表的联系属性丢光文档和 SQL 对不上现象用可视化 ER 工具画完图点一下“正向工程”生成建表 SQL生成的 borrow_record 表只有 reader_id 和 copy_id 两个外键列借出日期、应还日期、实际归还日期全部消失。建表能成功业务 SQL 一写就发现没有 borrow_date 列。原因很多 ER 工具把 M:N 联系自动转成中间表但联系属性需要挂在联系上才能在转换时生成列如果画图时把日期属性拖到了实体上或者工具本身对联系属性支持不佳生成结果就会丢属性。工具不是建模者它只是照着图上的显式内容翻译。解决中间表不能全自动生成联系属性必须手工核对。下面这段 SQL 是我按本项目落地的标准版本可以直接抄进文档的附录CREATE TABLE borrow_record ( borrow_id INT AUTO_INCREMENT PRIMARY KEY COMMENT 借阅流水号自增主键, reader_id INT NOT NULL COMMENT 读者ID外键指向reader表, copy_id INT NOT NULL COMMENT 馆藏副本ID外键指向book_copy表, borrow_date DATE NOT NULL COMMENT 借出日期, due_date DATE NOT NULL COMMENT 应还日期借出日期加30天, return_date DATE DEFAULT NULL COMMENT 实际归还日期NULL表示仍在借, operator_id INT NOT NULL COMMENT 经办馆员ID外键指向librarian表, KEY idx_reader_borrow (reader_id, return_date), KEY idx_copy_return (copy_id, return_date), CONSTRAINT fk_borrow_reader FOREIGN KEY (reader_id) REFERENCES reader (reader_id), CONSTRAINT fk_borrow_copy FOREIGN KEY (copy_id) REFERENCES book_copy (copy_id), CONSTRAINT fk_borrow_operator FOREIGN KEY (operator_id) REFERENCES librarian (librarian_id) ) COMMENT 借阅流水表同一读者可对同一副本多次借阅;主键选择自增 borrow_id 而不是联合主键理由在坑一里已经说明。idx_reader_borrow 覆盖“查某读者当前在借哪些书”的场景idx_copy_return 覆盖“查某副本当前是否可借”的场景两个索引都把 return_date 带进去因为条件里总要判断是否为空。日期用 DATE 类型不存时间逾期天数由 DATEDIFF 现算罚款金额不要在库里冗余存储计算结果的列除非你明确要做历史快照。operator_id 不要允许 NULL每笔借阅必须知道是谁办的这是审计要求。6. 交付前的对图检查一套三张图互相追溯的核对表文档画完别急着交先做一次“对图检查”。核心思路是拿一支笔从业务流程图上随便挑一个事件顺着它往下追这个事件在 DFD 里有没有对应加工加工的数据流在 ER 图里有没有对应联系联系在表结构里有没有外键或中间表承载每一步都追得到三张图才算闭环。下面这张表是我每次交付前必过的六项检查项怎么查典型反例流程图的判断点都能在 DFD 找到加工从借书流程的“逾期拦截”出发找流通模块的校验加工业务图有判断DFD 里查无此人每个数据存储至少一写一读检查预约存储是否有“到馆通知”读取流只写不读业务闭环断了一半ER 图每个联系都有表结构承载罚款联系对应 fine 表里的 borrow_id 外键联系画了表没建三张图同名同义读者证号从流程图、DFD 到 ER 图都用 reader_id 或统一中文名一会 reader_code 一会 card_id派生数据不单独建存储或列在借数量、欠款总额由查询得出在 reader 表加 current_borrow_count还书忘记减一父图子图输入输出一致0 层图“流通”的输入输出与 1 层子图边界逐项对照0 层图没有续借请求1 层图边界多了续借请求这个检查动作放到文档交付前半小时做基本能拦下八成返工。我自己的习惯是打印一份纸质文档在借书、还书、预约、罚款四条主线上各走一遍任何一环断掉就先改图再走直到一条主线全程勾通才发出去。文档里的图不是画得多漂亮就合格而是要能互相印证。做到这一步评审最多追问业务假设不会再问“你这个加工从哪来的”这种让你当场卡壳的问题。希望帮到你。本文还有配套的精品资源点击获取