简介：这份文档面向数据库课程设计的学习者与需要完成图书管理类项目的学生，提供一套基于关系型数据库的完整图书管理系统设计报告与代码实现，可用于课程作业参考、数据库设计练习或小型图书馆管理场景的方案借鉴。资源共1个doc文件，压缩包约709KB，内容以设计报告书形式组织，涵盖系统分析、数据库存储设计、E-R图、数据字典、关系模式与SQL实现等部分。文档围绕读者信息、图书信息、操作员信息三个基础模块展开，并延伸至借阅登记、还书记录、超期罚款等业务数据，给出书籍类别、读者、书籍、借阅、还书、罚款等关系模式及相应查询描述，读者可据此理解从需求分析到建表、查询、修改、删除的完整设计链路。目前已有2317人学习，适合作为数据库应用技术课程的实践参考材料。

1. 一份课程设计里的图书管理系统，为什么值得拿来跑一遍

翻到一份十几年前的数据库课程设计，文件名写着“SQL数据库图书管理系统(完整代码)”，打开一看，从建库建表、E-R 图、数据字典到初始化数据、单表查询结果，一条链路全在里面。很多人第一反应是“这不就是个学生作业”，但真正带过新人、或者自己从零搭过业务库的人会明白：能把六张表的关系、外键约束、借还书状态流转讲圆，比堆一堆花哨框架难得多。这份资源适合两类人——数据库刚入门、想找一个能完整跑通的 SQL 项目练手的同学，以及需要给团队做数据库设计示例、想找一个结构干净的小系统当模板的开发者。它不依赖任何前端框架，纯 SQL 就能把图书借阅、归还、超期罚款这条主线跑起来，拿来当“数据库设计第一课”的实物教材，比看十页理论都直接。

2. 系统定位与技术选型：六张表撑起一个借阅闭环

2.1 这个系统到底管什么

从设计报告里的任务角色划分看，系统面向三类人：读者、图书馆馆员、系统管理员。读者关心的是“我借了什么、什么时候还、有没有罚款”；馆员关心的是“这本书还在不在库、谁借走了”；管理员关心的是“读者信息、书籍信息、类别信息怎么维护”。这三类诉求落到数据上，就是基础数据加业务数据两条线。基础数据包括读者信息、图书信息、操作员信息；业务数据包括借还书记录登记和罚款登记；再往上还有一层统计数据，比如书籍借阅情况统计、读者借阅情况统计。这个分层很朴素，但它是后面所有表结构设计的依据——先想清楚谁在用、用来干什么，再决定表怎么拆。

技术选型上，这份资源用的是关系型数据库加标准 SQL，建库语句是CREATE DATABASE，建表用CREATE TABLE，外键用FOREIGN KEY ... REFERENCES，初始化数据用INSERT INTO，查询用SELECT。没有存储过程、没有触发器、没有 ORM 映射，全部是裸 SQL。这种选型在今天看确实“原始”，但对学习数据库设计的人来说反而是优点：每一层关系都摆在明面上，外键约束写没写对、主键选得合不合理，一眼就能看出来。常见做法是先用这种纯 SQL 版本把模型跑通，再考虑往上套应用层。

2.2 六张核心表的关系拓扑

整个系统的骨架是六张表：book_style（书籍类别）、system_books（书籍库存）、system_readers（读者）、borrow_record（借阅记录）、return_record（还书记录）、reader_fee（罚款记录）。它们之间的关系不是随便连的，而是围绕“一本书从入库到被借走、再被还回来、超期产生罚款”这条业务链展开的。

book_style是维度表，只存类别编号和类别名称，system_books通过bookstyleno外键指向它，这样一本书属于哪个类别不用在书籍表里重复写类别名。system_readers是读者主表，借书证编号做主键。borrow_record同时挂bookid和readerid两个外键，分别指向书籍表和读者表，一条借阅记录就是“某人在某时借了某书”。return_record结构类似，记录归还时间。reader_fee则把读者、书籍、罚款金额、借阅时间绑在一起，专门处理超期场景。

这里有个设计细节值得注意：system_books里有一个isborrowed字段，用来标记这本书当前是否被借出。借书时把它置为0，还书时再改回来。这个字段本质上是借阅状态的冗余存储，严格来说可以从borrow_record和return_record推导出来，但在小系统里加一个状态位能省掉大量联表判断，属于典型的“用一点冗余换查询简单”。我一般会在设计文档里把这类冗余字段单独标出来，提醒后续维护的人：它不是业务真相，只是加速查询的缓存。

2.3 为什么用外键而不是应用层校验

建表语句里大量使用了FOREIGN KEY，比如借阅表的bookid引用system_books(bookid)，readerid引用system_readers(readerid)。很多现代项目会把外键去掉，改在应用层做校验，理由是外键影响写入性能、分库分表后不好维护。但在这个规模的教学系统里，外键是必须保留的——它能在数据库层面挡住“借了一本不存在的书”或者“一个不存在的读者来借书”这类脏数据。对新手来说，外键报错是最直观的反馈：插入一条bookid不存在的借阅记录，数据库直接拒绝，比在代码里写一堆if判断更能让人理解“参照完整性”到底是什么意思。

提示：如果你打算把这个库迁到 MySQL 8 或者 PostgreSQL 上跑，外键语法基本兼容，但datetime类型和自增策略需要按目标库调整，别直接复制粘贴就完事。

3. 从建库到初始化：把 SQL 脚本按顺序跑通

3.1 建库语句里的路径坑

原始脚本的建库部分是这样的：

USE master GO CREATE DATABASE librarysystem ON ( NAME = librarysystem, FILENAME = 'c:\', SIZE = 10, MAXSIZE = 50, FILEGROWTH = 5 ) LOG ON ( NAME = 'library', FILENAME = 'c:\', SIZE = 5MB, MAXSIZE = 25MB, FILEGROWTH = 5MB ) GO

这段是 SQL Server 的写法，FILENAME = 'c:\'只给了目录没给文件名，在真实环境里会直接报错。正确做法是补全.mdf和.ldf文件名，比如FILENAME = 'c:\data\librarysystem.mdf'。SIZE单位默认是 MB，FILEGROWTH = 5表示每次增长 5MB。如果你用的是 MySQL，整段要换成CREATE DATABASE librarysystem DEFAULT CHARACTER SET utf8mb4;，文件路径那套完全不需要。这一步是新手最容易翻车的地方——脚本跑不下去，后面全白搭。

3.2 六张表的建表顺序不能乱

建表必须按依赖关系来：先建被引用的表，再建引用别人的表。顺序是book_style→system_books→system_readers→borrow_record→return_record→reader_fee。如果先建borrow_record，它引用的system_books还不存在，外键约束会直接失败。

-- 1. 书籍类别表，被 system_books 引用 CREATE TABLE book_style ( bookstyleno VARCHAR(30) PRIMARY KEY, bookstyle VARCHAR(30) ); -- 2. 书籍库存表，外键指向类别表 CREATE TABLE system_books ( bookid VARCHAR(20) PRIMARY KEY, bookname VARCHAR(30) NOT NULL, bookstyleno VARCHAR(30) NOT NULL, bookauthor VARCHAR(30), bookpub VARCHAR(30), bookpubdate DATETIME, bookindate DATETIME, isborrowed VARCHAR(2), FOREIGN KEY (bookstyleno) REFERENCES book_style(bookstyleno) ); -- 3. 读者表 CREATE TABLE system_readers ( readerid VARCHAR(9) PRIMARY KEY, readername VARCHAR(9) NOT NULL, readersex VARCHAR(2) NOT NULL, readertype VARCHAR(10), regdate DATETIME );

参数说明：bookid用VARCHAR(20)而不是自增整数，是因为原始数据里书籍编号是'901'、'902'这种业务编号，不是数据库生成的。isborrowed用VARCHAR(2)存'1'和'0'，严格说用BIT或TINYINT更合适，但原脚本这么写，迁移时保留原样能减少数据转换的麻烦。readername给VARCHAR(9)偏紧，中文姓名三个字在 UTF-8 下占 9 字节刚好卡住，实际项目里我一般直接给VARCHAR(50)，避免生僻字或复姓撑爆字段。

借阅表和还书表的结构几乎对称：

CREATE TABLE borrow_record ( bookid VARCHAR(20) PRIMARY KEY, readerid VARCHAR(9), borrowdate DATETIME, FOREIGN KEY (bookid) REFERENCES system_books(bookid), FOREIGN KEY (readerid) REFERENCES system_readers(readerid) ); CREATE TABLE return_record ( bookid VARCHAR(20) PRIMARY KEY, readerid VARCHAR(9), returndate DATETIME, FOREIGN KEY (bookid) REFERENCES system_books(bookid), FOREIGN KEY (readerid) REFERENCES system_readers(readerid) );

这里有个设计问题要提前说清楚：borrow_record把bookid设成了主键，意味着一本书在借阅表里只能有一条记录。如果一本书被借了还、还了再借，第二次插入就会主键冲突。原系统靠“还书后删借阅记录”或者“只保留当前借阅”来绕开，但这在真实场景里是站不住的。二次开发时第一件事就是把主键改成自增 ID 或者(bookid, readerid, borrowdate)联合主键，这个后面第 5 章会展开。

3.3 初始化数据怎么灌才不出错

初始化分三批：先灌类别，再灌书籍和读者，最后灌借阅记录并同步更新isborrowed状态。

-- 类别数据 INSERT INTO book_style(bookstyleno, bookstyle) VALUES ('1', '修真小说'); INSERT INTO book_style(bookstyleno, bookstyle) VALUES ('2', '穿越小说'); -- ... 其余类别同理 -- 书籍数据，注意 isborrowed 初始为 '1' 表示在库 INSERT INTO system_books(bookid, bookname, bookstyleno, bookauthor, bookpub, bookpubdate, bookindate, isborrowed) VALUES ('901', '飘渺之旅', '1', '萧潜', '鲜网', '2005-09-01', '2013-05-25', '1'); -- 读者数据 INSERT INTO system_readers(readerid, readername, readersex, readertype, regdate) VALUES ('Q', '李雷', '男', '学生', '2013-01-18 12:20');

灌完基础数据后，脚本里有一段“添加已借书读者记录”的逻辑，先插borrow_record，再UPDATE system_books SET isborrowed = 0。这两步必须放在同一个事务里，否则中途失败会出现“借阅记录有了但书还标着在库”的不一致状态。原脚本没写事务，实际跑的时候建议手动包一层：

BEGIN TRANSACTION; INSERT INTO borrow_record(bookid, readerid, borrowdate) VALUES ('901', 'Q', '2013-01-18 12:20'); UPDATE system_books SET isborrowed = '0' WHERE bookid = '901' AND isborrowed = '1'; COMMIT;

WHERE后面带上AND isborrowed = '1'是个防御性写法，防止重复执行时把已经借出的书再“借”一次。这种小细节在课程设计里容易被忽略，但它是真实项目里避免脏数据的基本功。

4. 核心业务 SQL 拆解：借书、还书、罚款三条链路

4.1 借书操作：一次插入加一次状态更新

借书在数据层面就两件事：往borrow_record插一条记录，把对应书籍的isborrowed改成'0'。但插之前得先确认这本书当前是可借状态，否则会出现“同一本书被两个人同时借走”的超卖问题。

-- 借书前检查：这本书是否在库 SELECT bookid, bookname, isborrowed FROM system_books WHERE bookid = '901' AND isborrowed = '1'; -- 确认在库后执行借阅 BEGIN TRANSACTION; INSERT INTO borrow_record(bookid, readerid, borrowdate) VALUES ('901', 'Q', GETDATE()); UPDATE system_books SET isborrowed = '0' WHERE bookid = '901' AND isborrowed = '1'; COMMIT;

GETDATE()是 SQL Server 取当前时间的函数，MySQL 对应NOW()，PostgreSQL 用CURRENT_TIMESTAMP。UPDATE的WHERE条件里带isborrowed = '1'是关键——如果两个人几乎同时借同一本书，第一个事务把状态改成'0'后，第二个事务的UPDATE影响行数为 0，应用层就能据此判断“这本书刚被别人借走了”。这是最朴素的乐观锁思路，不用加锁也能挡住大部分并发问题。

4.2 还书操作：状态回写加超期判断

还书比借书多一步：要判断有没有超期。原系统没有在 SQL 里写死借阅期限，罚款表reader_fee是手动登记的。实际改造时我一般会把期限做成可配置，比如 30 天，还书时用DATEDIFF算差值。

-- 还书：插入还书记录，恢复书籍状态 BEGIN TRANSACTION; INSERT INTO return_record(bookid, readerid, returndate) VALUES ('901', 'Q', GETDATE()); UPDATE system_books SET isborrowed = '1' WHERE bookid = '901'; -- 超期判断：借出超过 30 天则登记罚款 INSERT INTO reader_fee(readerid, readername, bookid, bookname, bookfee, borrowdate) SELECT b.readerid, r.readername, b.bookid, s.bookname, CAST(DATEDIFF(DAY, b.borrowdate, GETDATE()) - 30 AS VARCHAR(10)) + '元', b.borrowdate FROM borrow_record b JOIN system_readers r ON b.readerid = r.readerid JOIN system_books s ON b.bookid = s.bookid WHERE b.bookid = '901' AND DATEDIFF(DAY, b.borrowdate, GETDATE()) > 30; COMMIT;

DATEDIFF(DAY, 借出时间, 当前时间)返回天数差，减 30 就是超期天数。罚款金额这里简单按“超期一天一元”拼了个字符串，真实项目里应该用DECIMAL(10,2)存金额，别用VARCHAR——原表bookfee是VARCHAR(30)，排序和求和都会出问题，这是二次开发时要改的点。

4.3 罚款查询与借阅统计

罚款查询是典型的联表：

SELECT f.readerid, f.readername, f.bookid, f.bookname, f.bookfee, f.borrowdate FROM reader_fee f JOIN system_readers r ON f.readerid = r.readerid WHERE r.readertype = '学生' ORDER BY f.borrowdate DESC;

借阅统计则按书籍或读者聚合：

-- 每本书被借了多少次 SELECT s.bookid, s.bookname, COUNT(b.bookid) AS borrow_count FROM system_books s LEFT JOIN borrow_record b ON s.bookid = b.bookid GROUP BY s.bookid, s.bookname ORDER BY borrow_count DESC; -- 每个读者当前借了几本 SELECT r.readerid, r.readername, COUNT(b.bookid) AS current_borrow FROM system_readers r LEFT JOIN borrow_record b ON r.readerid = b.readerid GROUP BY r.readerid, r.readername;

LEFT JOIN保证没被借过的书、没借过书的读者也能出现在结果里，计数为 0。如果用INNER JOIN，零借阅的记录会被过滤掉，统计就不完整了。这类细节在写报表 SQL 时经常被忽略，跑出来的数字对不上，回头查半天才发现是连接类型选错了。

5. 避坑与排查：这份脚本直接跑会遇到的五个问题

5.1 建库语句路径不完整导致创建失败

现象：执行CREATE DATABASE时报“文件名无效”或“路径不存在”。原因：FILENAME = 'c:\'只给了盘符根目录，没有具体文件名，SQL Server 无法确定数据文件落在哪。解决：补全为FILENAME = 'c:\data\librarysystem.mdf'，并确保c:\data目录已存在；或者干脆去掉ON子句，用默认路径建库。

5.2 借阅表主键设计导致二次借阅冲突

现象：同一本书还了再借，插入borrow_record时报主键重复。原因：bookid被设为主键，一本书只能有一条借阅记录。解决：把主键改成自增列id INT IDENTITY(1,1) PRIMARY KEY，bookid降为普通外键字段；或者用(bookid, readerid, borrowdate)联合主键。改完之后还书逻辑也要跟着调整，不能再靠bookid定位唯一借阅记录。

5.3 初始化数据里读者编号重复

现象：灌读者数据时部分INSERT失败。原因：脚本里多个读者的readerid都写成了'Q'，而readerid是主键。解决：给每个读者分配唯一编号，比如'Q001'到'Q005'，同时把借阅记录里对应的readerid一起改掉，保证外键能对上。

5.4 外键顺序错误导致建表中断

现象：执行到borrow_record建表时报“引用的对象不存在”。原因：建表顺序没按依赖走，先建了引用表后被引用表还没建。解决：严格按book_style→system_books→system_readers→borrow_record→return_record→reader_fee的顺序执行；如果脚本已经跑了一半，先删掉已建的表再从头来，别试图跳步补。

5.5 金额字段用 VARCHAR 导致统计失真

现象：罚款汇总时SUM(bookfee)报类型错误，或者排序结果按字符串排而不是按数值排。原因：bookfee定义成VARCHAR(30)，存的是'5元'这种带单位的字符串。解决：改成DECIMAL(10,2)，插入时只存数值，单位在展示层拼；历史数据用UPDATE ... SET bookfee = REPLACE(bookfee, '元', '')清洗后再改类型。

6. 二次开发改造：从课程设计到能用的借阅系统

这份脚本最大的价值不是“能跑”，而是“结构清楚到可以当改造起点”。我拿到手第一件事是把borrow_record和return_record合并成一张borrow_log表，用status字段区分借出和归还，主键改成自增 ID。这样一本书的完整流转历史都在一张表里，查“这本书被谁借过几次”一条 SQL 就够，不用两张表来回UNION。

CREATE TABLE borrow_log ( id INT IDENTITY(1,1) PRIMARY KEY, bookid VARCHAR(20) NOT NULL, readerid VARCHAR(9) NOT NULL, borrowdate DATETIME NOT NULL, returndate DATETIME NULL, status TINYINT NOT NULL DEFAULT 0, -- 0借出 1已还 FOREIGN KEY (bookid) REFERENCES system_books(bookid), FOREIGN KEY (readerid) REFERENCES system_readers(readerid) );

还书时不再插新表，而是UPDATE borrow_log SET returndate = GETDATE(), status = 1 WHERE bookid = ? AND status = 0。配合system_books.isborrowed的状态位，借还链路就闭环了。验证方法很简单：借一本书，查borrow_log应该有一条status = 0的记录；还书后再查，同一条记录status变1、returndate有值；再借一次，应该新增一条记录而不是覆盖旧的。这三步跑通，说明改造没破坏原有业务语义。

第二个改造点是罚款逻辑。原系统罚款靠手动插reader_fee，我一般会加一个视图或者定时查询，把超期未还的记录自动算出来：

SELECT b.id, b.bookid, b.readerid, r.readername, DATEDIFF(DAY, b.borrowdate, GETDATE()) - 30 AS overdue_days FROM borrow_log b JOIN system_readers r ON b.readerid = r.readerid WHERE b.status = 0 AND DATEDIFF(DAY, b.borrowdate, GETDATE()) > 30;

这个查询可以直接喂给前端做“超期提醒”，也可以定时落库生成罚款单。overdue_days乘上日罚金就是应缴金额，比原脚本里拼字符串的做法靠谱得多。

最后一个习惯：每次改表结构之前，先把原始脚本完整备份一份，改完在新库上从零跑一遍全量脚本，确认建表、初始化、借还、统计四条链路都通，再往已有数据上迁移。从那以后我每次接手这种“课程设计级”的库，都强制走一遍“空库全量重建 + 抽样数据验证”，因为这类脚本最容易在初始化顺序和主键设计上埋雷，跑一遍比读十遍都管用。希望这份拆解能帮你把这份 SQL 资源真正跑起来，而不是停在“下载了但没打开”的状态。

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