学校图书借阅管理系统数据库设计：书目馆藏拆分与约束落地

简介：学校图书借阅管理系统数据库系统设计课程设计报告，面向计算机相关专业学生及数据库课程设计学习者，围绕图书馆借阅业务给出从需求分析、数据字典、数据流图到E-R图、概要设计与功能实现的完整方案，可用于课程设计参考、项目模仿与答辩准备。压缩包共1个doc文件，约4.16MB，内容以课程设计报告文档为主，集中呈现欢迎界面、读者与管理员登录、图书信息录入修改、读者注册管理、图书查询借阅归还、数据备份恢复及系统管理等模块的设计说明与代码片段。已有11186人学习下载，说明其在该类课程设计中具有较高参考热度。读者可从中获取系统结构图、主要功能说明、E-R图、主程序与各窗体代码等具体内容，便于理解图书借阅管理系统的数据库设计思路，并对照整理自己的课程设计文档与实现流程。

1. 学校图书借阅管理系统数据库设计：先拆“书目”和“馆藏册”再画表

学校图书借阅管理系统的数据库系统设计，真正难的不是把书、读者、借阅三张表画出来，而是让“同一册书不能同时借给两个人”“还书后册状态立刻回正”“逾期统计不靠人工改状态”这三件事在数据库层成立。一个模拟项目里，借书接口返回成功，书架上的册状态却还是可借，最后靠对账 SQL 才把问题找出来。这个方向适合做课程设计、毕设和中小型馆内系统的人：表不多，但约束、事务、索引一个都不能省。

2. 从借阅业务到 ER 模型：读者、书目、馆藏册、借阅记录怎么抽

做学校图书借阅管理系统，最容易上来就画三张表：书、读者、借阅。表能跑，关系却经常画反。书是“书目”，还是“手上这一本”？借阅记录挂到书目上，还是挂到某一册上？这两个问题不先定，后面库存、条码、破损赔偿都会打架。我一般先把业务话术翻成实体，再画关系，不急着写建表 SQL。

2.1 需求访谈只问四类问题：谁借、借什么、借多久、异常谁处理

第一类问题是“谁借”。读者分不分教师、学生、校外人员？借书证丢了能不能挂失？冻结状态是禁止借书，还是只禁止预约？这些答案最后会落到reader.status、reader.card_no和读者类型字段上。不要只问“读者表要哪些字段”，要问“读者状态变化时，哪些操作必须被拦住”。比如冻结读者还能不能还书，通常能还，不能借，这就是业务规则，不是界面规则。

第二类问题是“借什么”。读者看到的是书名，管理员操作的是条码。预约时选书名，借书时扫条码，这两个动作在数据库里不是同一张表。很多课程设计把“书名、条码、库存数量”塞进一张 book 表，刚开始能跑，一旦同一本书到馆五册，就无法知道哪一册被借走、哪一册破损、哪一册在预约架上。问清楚“按书目借还是按册借”，ER 图基本就不会画偏。

第三类问题是“借多久”。借期是 30 天还是 60 天？能不能续借？续借几次？预约到书后保留几天？到期日是在借出时算好写入due_at，还是每次查询时动态算？我一般把到期时间落到借阅记录里，因为罚款、催还、报表都要一个稳定的时间点。续借时更新due_at和renew_count，不要只在前端显示“已续借”。

第四类问题是“异常谁处理”。逾期、丢失、破损、赔偿、批量导入脏数据，这些才是数据库设计的分水岭。逾期是每天批量改状态，还是查询时按due_at < NOW()算？丢失后册状态改成“遗失”，借阅记录还保不保留？赔偿金额用DECIMAL还是整数分？这些问题问完，字段类型和状态机基本就定了。

注意：需求访谈不要只记录“要有一个借阅表”，要记录“哪些动作必须在一个事务里完成”。借书时锁册、写借阅、改册状态，这三步拆开，库存就会对不上。

2.2 把“书”拆成书目与馆藏册：ISBN 与条码各管什么

ISBN 是书目级标识，条码是册级标识。一个 ISBN 对应一种书，一种书可以有多册；每一册有自己的条码、馆藏位置、状态和借阅历史。把这两层拆开，借阅记录挂到book_copy.copy_id上，才能回答“张三借走的是哪一册”“这一册现在是不是在维修”“这本书还有几册可借”。

常见做法是book_title存 ISBN、书名、作者、分类、出版社；book_copy存条码、title_id、馆藏位置、册状态。查询“某本书可借数量”时，按title_id关联book_copy，统计status = 可借的册数。查询“某读者借了什么”时，从loan关联book_copy，再关联book_title，这样既能看到册条码，也能看到书名。

如果只建一张 book 表，把stock库存数量放在里面，借书时stock = stock - 1，还书时stock = stock + 1，看起来简单，实际会遇到三个问题：第一，无法定位具体哪一册被借走；第二，同一册书重复借出时只能靠应用层查重；第三，丢失或破损时库存数量无法表达“这一册不可借”。所以库存数量适合做查询结果，不适合做唯一事实来源。

2.3 用最小关系草图验证：一对多、多对多和借阅记录的位置

最小关系可以这么画：reader一对多loan，book_copy一对多loan，book_title一对多book_copy，reservation连接reader和book_title。借阅记录是读者和馆藏册之间的多对多桥，不是读者和书目之间的直接多对多。把这个关系画对，后面的外键和唯一索引才有地方落。

验证模型是否够用，可以拿三个问题去套：第一，给定一个条码，能不能查到它当前是否在借、借给谁、什么时候到期？第二，给定一个读者，能不能查到他全部历史借阅，包括已还和未还？第三，给定一个书目，能不能算出可借册数、在借册数、预约人数？三个问题都能用一张主表加两次 JOIN 回答，模型基本够用；如果第三个问题需要扫全表或读冗余字段，说明书目和馆藏册还没拆干净。

字段清单我一般先写三列：字段名、业务含义、是否允许为空。比如loan.returned_at允许为空，因为未还书时没有归还时间；book_copy.barcode不允许为空，而且要有唯一约束；loan.due_at不允许为空，因为借出时就必须确定到期时间。先写这三列，再决定类型，比直接打开建表工具更稳。

3. 借阅库表结构落地：主键、外键、唯一约束和借阅状态机

ER 图能跑通，不代表建表能跑通。数据库系统设计的硬活在这里：主键用什么类型，时间字段用DATETIME还是TIMESTAMP，金额能不能用FLOAT，借阅状态到底存几个值。表结构一旦上线，后面改类型的成本比改 SQL 高得多，所以这一层要把约束尽量前置。

3.1 五张核心表的字段类型：BIGINT、DATETIME、DECIMAL 怎么选

book_copy的status我一般用四个值：1 可借，2 在借，3 维修，4 遗失。loan的status用另外一组：1 在借，2 已还，3 逾期未还，4 丢失。两套状态不要混用，因为“册状态”描述实物能不能借，“借阅状态”描述这笔借阅处在哪个流程。混成一个字段，后面报表口径一定乱。

3.2 建表 SQL：先落约束再补索引，顺序反了会返工

建表顺序按依赖走：先reader、book_title，再book_copy，最后loan、reservation。外键列要有索引，InnoDB 会自动给外键建索引，但复合查询索引要自己补。下面这段 SQL 的关键不是字段多，而是把“同一册书不能有两条未还记录”交给数据库兜底。

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