简介：《数据库课程设计(图书管理系统)实验报告》是面向大学本科数据库原理课程设计及SQL大作业的完整参考资料，以图书管理系统为案例，覆盖从项目背景、需求分析、概念结构设计到逻辑结构设计、数据库建表与主要模块代码实现的全过程。报告详细展示了ER图、数据字典、关系模式、视图与索引设计，并对管理员、读者、图书等核心数据项做了说明，需求分析部分还包含信息要求、处理要求、安全性与完整性要求，适合正在选题或需要搭建管理系统架构的读者参考。压缩包内包含单份Word文档，大小约1.05MB，内容可二次标记和打印，便于按课程要求修改成自己的实验报告，也可直接作为数据库课程设计报告的格式模板。目前已有89人学习下载，既可直接借鉴图书管理系统的设计思路，也可作为课程设计选题方向与实验报告撰写的参考范文。
1. 数据库课程设计为什么总在“图书管理系统”上栽跟头
如果你正在为一学期的数据库课程设计发愁，大概率绕不开这个经典题目：图书管理系统。这个题目看起来简单——不就是书的增删改查嘛，可真正动手才发现，从需求分析到ER图，从建表到写存储过程，再到最后凑出一份像样的实验报告，每一步都在考验你对数据库设计最基础也最关键的认知。很多人的成绩不是差在代码量上，而是差在表设计不合理、借阅流程有逻辑漏洞、报告里连范式分析都没写清楚。
这篇笔记从一个做过多年课程设计指导的视角出发，沿着“数据库课程设计(图书管理系统)实验报告.doc”这个标题背后真正要交付的东西来拆解：图书管理系统该设计几张表、外键怎么挂、借书还书的事务怎么写、实验报告的每一章该填什么内容。不论你是要用 MySQL、SQL Server 还是 Python + SQLite 交差，这篇文章都能让你少走弯路，把一份能拿得出手的课程设计从头到尾落地。
2. 图书管理系统的数据库设计：先画ER图，再谈建表
2.1 从“借书还书”这个核心业务推导数据表
很多同学一上来就建一张book表、一张user表，然后开始写代码，结果做到借阅历史的时候发现字段不够用，做到统计的时候发现缺数据，只能推倒重来。图书管理系统再怎么变，核心业务绕不开这几个动作：读者借书、读者还书、管理员维护图书信息、查询某本书被谁借走、统计某类书的借阅热度。
围绕这些业务，我一般会拆出五张核心表：图书表（book）、读者表（reader）、管理员表（admin）、借阅记录表（borrow_record）、图书分类表（category）。为什么需要单独一张分类表？因为“计算机类”“文学类”这种分类字段如果直接塞在book表里，会出现大量重复字符串，数据冗余不说，将来改一个分类名还得批量UPDATE，这就在第一范式上站不住脚。
借阅记录表是整个系统的核心，它不直接存“书名”和“读者名”，而是存book_id和reader_id两个外键，这样设计的好处是：一本书被借走的信息发生变化时，只需要改book表，借阅记录无需变动；同时借阅记录可以JOIN出书名、读者姓名、借书日期、应还日期等完整视图。这种“用外键关联代替冗余存储”的思想，就是范式的价值所在。
2.2 用SQL把六张表的DDL写出来：主键、外键、约束一次到位
下面这组DDL语句是我在 MySQL 8.x 环境下常用的版本，如果你用的是 SQL Server，语法差异不大，主要是自增字段的写法不同。按顺序执行，不要先建子表再建父表，否则外键会报错。
-- 图书分类表 CREATE TABLE category ( category_id INT PRIMARY KEY AUTO_INCREMENT, category_name VARCHAR(50) NOT NULL UNIQUE, description VARCHAR(200) ); -- 图书表 CREATE TABLE book ( book_id INT PRIMARY KEY AUTO_INCREMENT, isbn VARCHAR(20) NOT NULL UNIQUE, title VARCHAR(100) NOT NULL, author VARCHAR(50) NOT NULL, publisher VARCHAR(50), publish_date DATE, category_id INT, total_count INT DEFAULT 1, available_count INT DEFAULT 1, FOREIGN KEY (category_id) REFERENCES category(category_id) ); -- 读者表 CREATE TABLE reader ( reader_id INT PRIMARY KEY AUTO_INCREMENT, reader_name VARCHAR(50) NOT NULL, phone VARCHAR(20), email VARCHAR(50), register_date DATE DEFAULT (CURRENT_DATE) ); -- 管理员表 CREATE TABLE admin ( admin_id INT PRIMARY KEY AUTO_INCREMENT, admin_name VARCHAR(50) NOT NULL, password_hash VARCHAR(255) NOT NULL ); -- 借阅记录表 CREATE TABLE borrow_record ( record_id INT PRIMARY KEY AUTO_INCREMENT, book_id INT NOT NULL, reader_id INT NOT NULL, borrow_date DATE NOT NULL, due_date DATE NOT NULL, return_date DATE, status TINYINT DEFAULT 0, FOREIGN KEY (book_id) REFERENCES book(book_id), FOREIGN KEY (reader_id) REFERENCES reader(reader_id) );这段DDL有几个参数值得说清楚。available_count字段用于标记当前可借数量，总册数total_count减去它就能算出被借走多少本，这是课程设计里最容易漏掉的设计。status字段用TINYINT而不是VARCHAR，0表示借出未还，1表示已还，2表示逾期——用数字做状态枚举，后续写WHERE条件更高效，也不容易出现大小写不一致的问题。UNIQUE约束加在isbn上，为的是防止同一本书重复录入。
2.3 范式检查：为什么这张表设计到了第三范式
把建表语句写完，需要在实验报告里补一段范式分析，这是评分老师最爱看的部分。第一范式要求字段不可再分，上面的表没有任何一个字段内部还藏着复合结构，比如“author”如果写成“作者1/作者2”就不合规了。第二范式要求非主键字段完全依赖于主键，在borrow_record表里，record_id是主键，book_id和reader_id都只依赖record_id而不互相依赖，满足要求。
第三范式是重点：非主键字段不能传递依赖。在book表里，category_name是通过category_id关联到category表的，book表只保留category_id这个外键，这就是消除了传递依赖——如果book表里直接存了category_name，那么category_name依赖category_id，category_id依赖book_id，就成了传递依赖，需要拆表。把这段分析写进实验报告的数据设计章节，拿分比贴一百行代码都管用。
3. 借书还书核心流程落地：从INSERT到事务处理的完整链路
3.1 借书操作：一次涉及三张表的联动修改
图书管理系统的核心操作是借书和还书。借书这个动作，表面上是INSERT一条记录，实际上要同时做三件事：往borrow_record里插入记录、把book表里available_count减1、检查读者是否有逾期未还的图书。如果这三步操作分开执行，中间任何一步失败都会让数据不一致，比如记录插入了但库存没减，或者库存减了但记录没插入。
所以借书操作必须放在事务里。下面以 MySQL 的存储过程为例：
DELIMITER // CREATE PROCEDURE borrow_book( IN p_book_id INT, IN p_reader_id INT, IN p_days INT ) BEGIN DECLARE v_available INT; DECLARE v_overdue INT; START TRANSACTION; -- 检查库存 SELECT available_count INTO v_available FROM book WHERE book_id = p_book_id FOR UPDATE; IF v_available <= 0 THEN ROLLBACK; SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '该书无可借库存'; END IF; -- 检查该读者是否有逾期未还的记录 SELECT COUNT(*) INTO v_overdue FROM borrow_record WHERE reader_id = p_reader_id AND status = 0 AND due_date < CURDATE(); IF v_overdue > 0 THEN ROLLBACK; SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '该读者存在逾期未还图书'; END IF; -- 插入借阅记录 INSERT INTO borrow_record (book_id, reader_id, borrow_date, due_date, status) VALUES (p_book_id, p_reader_id, CURDATE(), DATE_ADD(CURDATE(), INTERVAL p_days DAY), 0); -- 扣减库存 UPDATE book SET available_count = available_count - 1 WHERE book_id = p_book_id; COMMIT; END // DELIMITER ;这段存储过程涵盖了课程设计评审时最看重的事务处理逻辑。FOR UPDATE是关键中的关键，它把选出来的库存行锁住，防止两个客户端同时借最后一本书时都读到“还有1本”，然后双双执行成功。SIGNAL SQLSTATE '45000'是手动抛出异常，事务回滚后，应用程序能捕获到这个错误信息并提示用户。如果是在 Python 端实现，可以用pymysql的cursor.execute调这个存储过程，或者把事务逻辑直接写在 Python 的with conn.cursor()上下文里。
3.2 还书操作：状态更新与库存回补的时序问题
还书操作和借书相比，逻辑简单一些，但有一个容易踩坑的时序问题。还书时应当先UPDATE借阅记录的return_date和status，再UPDATE book表的available_count，这个顺序不能反过来。因为在业务语义上，“还书”这个事实发生在“库存恢复”之前，如果先加库存后改记录，一旦第二步失败，系统会出现库存多了但记录仍显示借出的脏数据。
DELIMITER // CREATE PROCEDURE return_book(IN p_record_id INT) BEGIN DECLARE v_book_id INT; DECLARE v_reader_id INT; START TRANSACTION; SELECT book_id, reader_id INTO v_book_id, v_reader_id FROM borrow_record WHERE record_id = p_record_id FOR UPDATE; IF v_book_id IS NULL THEN ROLLBACK; SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '借阅记录不存在'; END IF; UPDATE borrow_record SET return_date = CURDATE(), status = 1 WHERE record_id = p_record_id; UPDATE book SET available_count = available_count + 1 WHERE book_id = v_book_id; COMMIT; END // DELIMITER ;3.3 前端连着后端调：给 Python + Flask 的最小接口实现
如果你打算用 Python 做前端展示，下面这段 Flask 接口是图书管理系统里借书接口的最小实现。它做的事情就是接收POST请求，解析参数，调存储过程，然后把结果返回给前端页面。
from flask import Flask, request, jsonify import pymysql app = Flask(__name__) DB_CONFIG = { 'host': 'localhost', 'user': 'root', 'password': 'your_password', 'database': 'library_db', 'charset': 'utf8mb4' } @app.route('/api/borrow', methods=['POST']) def borrow(): data = request.get_json() book_id = data.get('book_id') reader_id = data.get('reader_id') days = data.get('days', 30) conn = pymysql.connect(**DB_CONFIG) try: with conn.cursor() as cursor: cursor.callproc('borrow_book', (book_id, reader_id, days)) conn.commit() return jsonify({'code': 0, 'message': '借书成功'}) except Exception as e: conn.rollback() return jsonify({'code': 1, 'message': str(e)}) finally: conn.close() if __name__ == '__main__': app.run(debug=True, port=5000)这里的cursor.callproc是 PyMySQL 调用存储过程的专用方法，参数按存储过程定义的顺序传入。连接池的配置没有写进来，因为课程设计通常单机运行，但如果期末答辩时要演示并发借书，用DBUtils库的PooledDB替换普通连接是更健壮的做法。事务失败后的conn.rollback()一定要放在catch块里，很多初学者只捕获异常却不回滚，导致数据库里留下一半的数据变更。
3.4 把“增删改查”四个字扩展成完整的接口清单
课程设计的文档要求里常出现“实现图书管理系统的增删改查功能”这句话。这里的增删改查不是只针对book表，而是针对所有核心实体。我给学生的接口清单一般是这样的：图书增加、图书信息修改、图书删除（逻辑删除，不是物理DELETE）、读者注册、读者信息维护、借书、还书、按书名模糊查询、按分类统计借阅次数。每个接口对应SQL中一种主要的DML语句，把它们列进实验报告的功能模块表，评审老师一眼就能看出你的系统覆盖了课程要求的全部操作类型。
4. 实验报告文档怎么写：把“.doc”的每一章填到让老师挑不出毛病
4.1 实验报告的标准结构：需求分析、概念设计、逻辑设计、物理设计
数据库课程设计的实验报告通常有固定的章节要求，这和你在网上搜到的“图书管理系统实验报告.doc”模板是对应的。最标准的骨架是：需求分析、概念结构设计（ER图）、逻辑结构设计（关系模式）、物理结构设计（索引与存储）、系统功能实现、测试与总结。每一章的字数不需要夸张，但必须有实质性内容。
需求分析这一章要写清楚系统的用户角色和业务流程，比如读者能查书、借书、还书、查看个人借阅史，管理员能上架图书、处理逾期、维护读者信息。很多学生把需求分析写成功能列表，这不是不行，但如果能在里面加一条“非功能需求”，比如“系统需支持并发借书操作且保证库存数据一致”，就会明显比其他人的报告高一个档次。这个点正好呼应前面存储过程里的事务设计，前后一致，老师在答辩时问起来你也能答得上来。
概念结构设计就是ER图，用Visio或draw.io画出来。实体是图书、读者、管理员、分类，联系是借阅。ER图里要标清楚每个实体的属性，并把主键用下划线标出来。注意：管理员和借阅记录之间没有直接的联系，很多初学者画ER图时给每个实体两两连线，这是错的——管理员只是维护图书信息和读者信息，不直接参与借阅行为。
逻辑结构设计就是把ER图转换成关系模式，每个实体一张表，联系如果是多对多也要单独成表。借阅关系本质上是一个多对多联系（一个读者可以借多本书，一本书可以被多个读者先后借阅），所以借阅记录表必须有自己独立的主键record_id，而不能用(book_id, reader_id)联合主键——因为同一本书可以被同一个读者在不同时间借多次。把这个点想明白，你的逻辑设计就不会出现主键冲突的问题。
4.2 物理结构设计与索引选择：不要说“没做优化”
物理结构设计这一章是拉开分数差距的地方。这里要写清楚你建了哪些索引、为什么建这些索引。刚才DDL里的主键都是聚簇索引，InnoDB里每一个主键索引的叶子节点就存着整行数据，这个是大前提。此外我一般会在borrow_record表的(reader_id, status)上建一个普通索引，因为查询“某个读者的未还记录”是一个非常高频的检索场景；在book表的title字段上建普通索引，因为系统主要靠书名做模糊查询。
CREATE INDEX idx_reader_status ON borrow_record(reader_id, status); CREATE INDEX idx_book_title ON book(title);这里有一个课程设计里常见的误区：索引不是越多越好。每张表适合建的索引一般不超过五六个，因为每次INSERT和UPDATE都要同步维护所有索引，索引太多会导致写入变慢。联合索引的字段顺序也有讲究，(reader_id, status)的意思是先按reader_id排序再按status排序，所以它可以支持“按读者查所有记录”的查询，也可以支持“按读者+状态”的查询。但如果你的查询条件只带status不带reader_id，这个索引就废了。
物理设计部分还可以补一句“存储引擎选择InnoDB的理由”——支持事务、支持行级锁、支持外键约束。如果你用的是MyISAM，事务和外键都没有，那整个课程设计算是白做了。
4.3 把SQL语句和截图按“功能模块”组织进报告里
实验报告的后半部分要放系统功能实现的截图和代码。这里最忌讳的是把所有代码一股脑贴在附录里，正文里没有任何说明。我建议每个功能模块这样组织：先用一两句话说明这个页面实现了什么业务规则，然后贴核心SQL语句，最后放运行截图。比如图书检索模块，先写“本模块支持按书名进行模糊查询，通过LIKE '%关键词%'实现”，然后贴SQL和截图，注意截图要带上查询结果和SQL执行结果，不要只截一个空页面。
数据库连接部分如果用了配置文件，也可以把这部分内容写进报告里。JDBC连接字符串、或者Python的DB_CONFIG字典都可以展示，同时说明字符集设置的重要性——很多系统出现中文乱码，根源就在连接参数里少写了characterEncoding=utf8。这一句话写进报告，老师就知道你踩过这个坑也填掉了这个坑。
4.4 测试用例设计：别只写“功能正常”
实验报告的测试章节是很多人随便糊弄的部分。至少要有这样几条测试用例：正常借书流程测试、库存不足时借书失败测试、存在逾期图书时借书失败测试、相同读者并发借同一本书的测试。每条测试用例要包括“输入数据、预期结果、实际结果、是否通过”四列。如果能画一张测试用例表格，这个章节就非常专业了。更重要的是，你亲手跑过这些边界测试，答辩时老师随便问一个细节你都能答得上来，这种真实感是编不出来的。
5. 避坑手册：图书管理系统课程设计最常见的七个翻车点
5.1 外键约束与“逻辑删除”的冲突总是把人弄懵
现象：你对book表执行DELETE删除一条记录时，报错“Cannot delete or update a parent row: a foreign key constraint fails”。原因：这条图书记录在borrow_record表里存在关联子记录，外键约束阻止了删除。解决：不要做物理删除，给book表增加一个is_deleted字段，删除时执行UPDATE book SET is_deleted = 1 WHERE book_id = ?，查询时统一带WHERE is_deleted = 0条件。这是企业级开发的标准做法，写进报告里反而加分。
5.2 还书日期算错：DATE_ADD与直接加数字是两回事
现象：借书时设定30天借期，部分记录到期日比预期晚一天或早一天。原因：有人在代码里直接用borrow_date + 30计算，这在不同数据库里可能被解释为“加30天”或“加30个数字”。解决：一律使用DATE_ADD(borrow_date, INTERVAL 30 DAY)这种数据库原生的日期函数，可读性和正确性都有保证。
5.3 库存变成负数：没做FOR UPDATE的并发事故
现象：系统的available_count字段出现了负数，或者借书本数超出馆藏册数。原因：两个管理员同时操作，都读到了“还剩1本”的旧值，都执行了-1操作。解决：借书的事务里对book行加FOR UPDATE锁，让第二个事务等待第一个事务提交后再读取。如果你的数据库是SQLite这种支持并发较弱的嵌入式库，可以考虑用Python端的threading.Lock来模拟这种互斥。
5.4 中文乱码问题：数据库、连接、页面三层都要对齐
现象：命令行查询数据库正常，网页页面却显示问号。原因：字符集在三个层出现了不一致，数据库表是utf8mb4，JDBC或PyMySQL连接串没指定字符集，前端页面又是GBK。解决：建库语句用CREATE DATABASE library_db DEFAULT CHARACTER SET utf8mb4;，连接参数带上charset='utf8mb4'，页面里加<meta charset="utf-8">。一个经验命令：在MySQL里执行SHOW VARIABLES LIKE 'character_set%';，看到所有变量都是utf8mb4或utf8才说明数据库这一层没有设置问题。
5.5 SQL注入：别把字符串拼进SQL里
现象：在检索框输入1' OR '1'='1，返回了所有图书数据。原因：代码里用字符串拼接的方式写SQL查询。解决：所有SQL语句一律用参数化查询。MySQL的写法是cursor.execute("SELECT * FROM book WHERE title LIKE %s", ('%' + keyword + '%',))，JDBC的写法是preparedStatement.setString(1, keyword)。parameterized query不是可选项而是必选项，课程设计里用原始拼接字符串的写法一旦被老师注意到，轻则扣分重则重做。
5.6 登录密码明文存储：报告里“安全设计”几乎交了白卷
现象：admin表里password字段存的是肉眼可读的明文。原因：图省事，或者想演示时方便直接看到密码。解决：在Python端用hashlib.pbkdf2_hmac加盐哈希后再存，校验时重新计算哈希比对。哪怕课程设计不要求多高的安全性，存哈希这个动作本身就能让你的报告在“安全设计”章节有话可写。
5.7 查询性能翻车：Testing时只看了50条数据，答辩演示时却卡顿
现象：演示时执行JOIN查询超过了一秒，场面一度尴尬。原因：没有建立合适的索引，或者大表JOIN小表时where条件没走索引。解决：给所有外键字段建索引，给高频查询字段建索引，在MySQL里用EXPLAIN SELECT ...语句查看执行计划，看到type列为ALL就走不了索引，需要优化。执行计划这一步能写到实验报告里，就已经超过了90%的同期作品。
6. 进阶验证方法：用索引、存储引擎和事务隔离让系统达到“答辩不怕追问”
完成了基本功能和实验报告，你还有几步可以让自己在答辩环节从容应对。第一，用EXPLAIN逐一验证核心查询是否走索引，把自己对每条SQL执行计划的解释写在报告的物理设计部分——这会成为你口头答辩时的护身符。第二，把SHOW ENGINE INNODB STATUS的输出格式学会，当老师问到锁竞争和事务问题时，你能说清楚当前的事务隔离级别是REPEATABLE READ，InnoDB默认用间隙锁防止幻读，这就是真正理解数据库的表现。
第三，做一个简单的压测脚本：模拟30个并发用户同时借书，用Python的concurrent.futures线程池去调借书接口，观察是否有库存负数、是否有死锁报错。这个测试在Linux下跑时，可以用nohup让它后台运行，日志写到文件里，跑完统一分析。我习惯先跑一组不设FOR UPDATE的代码看错误率，再跑一组加锁的代码对比结果，两组数据的差异会非常直观地告诉你事务隔离与行锁到底值不值得写进实验报告。
做完以上三步，你交付的就不再是一个“能跑的小demo”，而是一个数据结构设计合理、事务边界清晰、查询性能经过验证的课程设计作品。这份工作量的价值在于：即使将来不做图书管理系统，你掌握的“按业务推导表结构、用事务保证一致性、用索引支撑查询”这三板斧，在做任何数据库应用时都会反复用到。
回顾我自己带过的学生作品，分数高且答辩顺利的，普遍有一个共性：实验报告不是最后几天编出来的，而是每一步做完立刻记下来的。建表时顺手把ER图画了，写存储过程时顺手把事务边界写清楚，测试时把每个边界场景都留下记录，到答辩前只需要整理排版而不用通宵赶工。这篇笔记给到你的，正是这条路线的完整走法——希望帮到你。
本文还有配套的精品资源，点击获取
