简介这是一份数据库系统课程设计完整报告主题为图书借阅管理系统适用于计算机相关专业学生、数据库初学者以及需要课程设计范本的开发者。整个设计基于MySQL完成报告从系统需求分析、数据字典出发逐步覆盖概念结构设计、逻辑结构设计、物理实现包含实体属性联系分析、PDM图转化、表与完整性约束代码、视图索引存储过程等核心内容并附有功能调试和界面展示帮助读者系统掌握数据库设计的完整流程。资源仅含1个docx文档大小约575KB文档章节完整、目录清晰便于直接参考和修改。目前已有51人学习。读者既能借鉴图书借阅管理系统的表结构设计与SQL实现思路也可将其作为课程设计报告模板规范撰写需求分析、设计过程和调试总结为答辩和验收提供有力支撑。1. 图书借阅管理系统的核心不在界面而在关系建模数据库系统课程设计里图书借阅管理系统是出现频率最高的选题之一但真正动手时第一关往往不是前端页面而是“借阅者与图书是多对多出版社与图书是一对多”这句话怎么变成可落地的表。很多人打开 MySQL 直接建表建到借阅关系时才发现一个人借多本书的记录没法在“读者表”里用一列存下于是回头补中间表一改就是全局返工。这篇以一份完整的课程设计报告为底稿把从 E-R 图到逻辑模型、再到 MySQL 物理实现和联调验证的完整链路拆开讲。适合正在赶数据库系统课程设计的人也适合想快速复习关系数据库建模、索引与存储过程边界的一线开发。2. E-R 模型与关系模式映射多对多关系拆分的三条规则2.1 实体与属性先划边界再谈字段课程设计报告中的实体划分是典型的四实体模型借阅人、图书、出版社、借阅。借阅人实体属性是借阅证号、姓名、单位图书实体属性是书号、书名、数量、位置、出版社名出版社实体属性是出版社名、电报编号、电话、邮编、地址借阅实体属性是借书日期、还书日期。实体边界划分看起来直白但有一个常见分歧出版社名同时出现在图书实体和出版社实体的属性里这是有意设计还是冗余答案是后者。图书表里保留出版社名作为外键出版社表以出版社名作为主键出版社的电话、地址只在出版社表里保存一份修改出版社信息时只改一处即可。图书表里的出版社名只是为了关联查询不再承担存储完整出版社信息的职责这就是去除传递依赖的基本动作。另一个容易被忽略的边界是“单位”。原报告把单位作为借阅人实体的属性没有单独拆单位表。如果按第三范式严格处理单位信息应该独立成表借阅人表只存单位编号但课程设计场景下单位仅有名称一个字段需要维护拆表的收益有限保留为借阅人表的属性字段是合理的简化处理。什么时候该拆当单位信息还要存地址、负责人、成立时间等多个属性时再拆。2.2 联系分析三种基数映射到表的具体方式借阅者与图书之间是多对多关系。多对多不能直接落成字段必须拆出中间表 Borrow中间表至少包含借阅证号和书号两个字段分别引用借阅人表和图书表的主键。原报告把借书日期、还书日期也放进中间表这是正确的做法——借阅这个行为本身的属性不属于读者也不属于图书只能挂在关系和中间表上。出版社与图书之间是一对多关系转换规则很固定在“多”的一方加外键。图书是“多”的一方所以在图书表里放出版社主键作为外键字段。多对多拆分时会遇到一个常见误用一些人把“借阅记录”建成读者表里的一个字段比如在借阅人表加一列 book_no_list用逗号拼接多个书号。这直接违背了字段不可再分的原子性要求所有对“借阅”的统计查询都会变成字符串操作性能和正确性都无从谈起。书号与书籍之间是一对一关系实际建模时很少为它单独建映射表。书号是图书实体的主键一对一关系通常表现为“某实体的唯一标识属性”直接并入主表即可。原报告里专门列了“一对一关系的转化”一小节划重点一对一关系真正需要单独建表的情况很少除非要做字段级权限隔离。课程设计阶段把主键直接落在实体表上就是最干净的转化。2.3 主键选择与规范化检查Borrow 表以 (J_No, B_No) 作为联合主键有一个前提同一读者借同一本书不能有两条同时有效的记录。这个前提在“续借”场景下不成立——续借意味着同书号再次出现联合主键会直接冲突。原报告把 R_day还书日期标注为“唯一性”也是同样的隐患同一天还书的多条记录会触发唯一约束冲突。规范化处理是把“同一读者同一本书只能有一条未归还记录”这一业务规则交给应用层或触发器判断而不是把整个借阅表的悬挂记录都锁死在唯一性上。保持 3NF 的关键点有三个借阅人表里单位名直接依赖借阅证号图书表里出版社名依赖书号借阅表里不应出现读者姓名、书名这类可从其他表推导的字段。满足这三点后新增字段时先问一句“它依赖哪个主键”就能避开大部分冗余设计。提示E-R 图中先画实体与联系的基数再按“一对多放外键、多对多拆中间表”的方式转换能省下大量返工。顺序反了后面每改一次表结构都要连带改视图和存储过程。3. MySQL 建表与完整性约束四张表的 DDL 怎么一次写对3.1 字段类型选型与表结构核对原报告的表设计分散在不同章节直接落库前值得先做一次类型核对。借阅证号和书号都选 char(6)因为编号位数固定char 的检索效率优于 varchar姓名、出版社名、单位这类长度不固定的用 varchar数量用 int借书日期与还书日期用 datetime可以保留时分秒如果只关心到天也可以换 date但 datetime 在后续算超期天数时更灵活。书号不用 int 的一个现实原因是 ISBN 可能带字母前缀int 表达不了int 还会引入自增、负数等与业务无关的属性。各表字段与约束汇总如下表名字段类型约束说明BorrowerJ_Nochar(6)主键借阅证号BorrowerJ_Namevarchar(20)非空借阅人姓名BorrowerJ_Departmentchar(11)非空、唯一单位BookB_Nochar(6)主键书号BookB_Namevarchar(20)非空书名BookB_Numint无图书数量BookB_Herechar(20)无存放位置BookC_Namechar(20)外键出版社名PubC_Namechar(20)主键出版社名称PubC_Telechar(10)非空电报编号PubC_Phonechar(8)无电话PubC_Addrchar(20)无地址PubC_Stchar(6)无邮编BorrowJ_Nochar(6)联合主键、外键借阅证号BorrowB_Nochar(6)联合主键、外键书号BorrowG_daydatetime无借书日期BorrowR_daydatetime无还书日期字段数值对不上的地方以报告正文的需求分析为准比如出版社电话在数据字典里写 11 位表设计里写成 char(8)实体落库时按实际需求保留 11 位字符容量即可。3.2 MySQL 8.0 可运行的完整 DDL原报告里的建表语句是 SQL Server 风格而且 Borrow 表没有加外键。落到 MySQL 8.0外键补全后的完整脚本如下CREATE TABLE Borrower ( J_No CHAR(6) PRIMARY KEY, J_Name VARCHAR(20) NOT NULL, J_Department CHAR(11) NOT NULL UNIQUE ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE Pub ( C_Name CHAR(20) PRIMARY KEY, C_Tele CHAR(10) NOT NULL, C_Phone CHAR(11), C_Addr VARCHAR(20), C_St CHAR(6) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE Book ( B_No CHAR(6) PRIMARY KEY, B_Name VARCHAR(20) NOT NULL, B_Num INT, B_Here CHAR(20), C_Name CHAR(20), CONSTRAINT fk_book_pub FOREIGN KEY (C_Name) REFERENCES Pub(C_Name) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE Borrow ( J_No CHAR(6), B_No CHAR(6), G_day DATETIME, R_day DATETIME, PRIMARY KEY (J_No, B_No), CONSTRAINT fk_borrow_reader FOREIGN KEY (J_No) REFERENCES Borrower(J_No), CONSTRAINT fk_borrow_book FOREIGN KEY (B_No) REFERENCES Book(B_No) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;逻辑说明Borrow 表通过两条 FOREIGN KEY 约束把联合主键的两个字段分别绑定到 Borrower 和 Book 的主键上保证不存在的读者不能借书、不存在的书不能被借。ENGINEInnoDB 是必须的MyISAM 不支持外键约束也不支持事务DEFAULT CHARSETutf8mb4 解决中文乱码问题也比 utf8 多覆盖生僻字和特殊符号。约束命名统一用 fk_ 前缀删除约束时可以直接 DROP FOREIGN KEY fk_book_pub不用去系统表里查自动生成的随机名。3.3 外键策略选择与“唯一索引”误用外键默认删除策略是 RESTRICT删除出版社时如果已有图书指向它删除会报错。课程设计场景下被借阅的图书、被引用的出版社都不应该被随意删除RESTRICT 正好符合预期。如果改用 ON DELETE CASCADE删除出版社时会连带删除该社全部图书借阅记录也会因为书不存在而悬空一般不建议。原报告在归还记录表的“应还日期”列上建了唯一索引这个设计在 MySQL 里暴露两个问题。语法上CREATE UNIQUE INDEX 必须指定索引名CREATE UNIQUE INDEX idx_should_return ON return_record(shouldreturn)缺名称会直接报语法错误。业务上多个读者的应还日期完全相同是常态“唯一索引”会让同一天应还的多条借阅记录互相冲突还书操作直接失败。唯一性约束只应加在真正有唯一性要求的字段上比如借阅证号、出版社名“某天应还”是高频重复值不是唯一值。4. 视图、索引、存储过程与触发器把借阅查询封装成可复用接口4.1 视图四表联查的只读封装原报告创建了两个视图一个展示图书与借阅者编号信息一个展示归还日期信息。实际开发中更常用的做法是把 Borrow、Borrower、Book、Pub 四张表连成一个“借阅明细视图”让管理员查询、前端展示都只对着一个视图写 SQL不用每处重复写 join。CREATE VIEW v_borrow_detail AS SELECT b.J_No, r.J_Name, r.J_Department, b.B_No, k.B_Name, k.B_Here, k.C_Name, b.G_day, b.R_day FROM Borrow b JOIN Borrower r ON b.J_No r.J_No JOIN Book k ON b.B_No k.B_No;逻辑说明三个 JOIN 的关联条件就是表设计里建立的外键关系查询口径统一由视图维护。视图只提供 SELECT 能力插入、修改、删除仍然走原表因此不会绕过外键约束。字段名前缀 b、r、k 是别名简写用来区分同名字段比如书号 B_No 在 Book 和 Borrow 里都存在不写别名前缀 MySQL 会报字段歧义错误。4.2 索引用 EXPLAIN 验证不要靠感觉堆借阅表的联合主键是 (J_No, B_No)主键索引支持“按借阅证号查记录”的前缀查询因为 J_No 是最左列。但“某本书被谁借走”这类查询条件落在 B_No 上B_No 是联合索引第二列无法走主键索引需要单独建二级索引CREATE INDEX idx_borrow_bno ON Borrow(B_No);图书表的 B_Name 是高频模糊查询字段但 LIKE %数据库% 这种写法无法走普通索引课程设计阶段可以不建。索引生效与否用 EXPLAIN 验证EXPLAIN SELECT * FROM Borrow WHERE B_No B001;返回结果里 type 是 ref说明二级索引命中了type 是 ALL就是全表扫描数据量上来之后延迟会明显增加。索引不是越多越好每一条索引都会拖慢 INSERT、UPDATE、DELETE 的写入速度普通索引只加在真实查询条件的列上。4.3 存储过程读者借阅记录查询接口原报告的存储过程语句不是 MySQL 方言create procedure reader ...落到 MySQL 里需要处理分隔符问题。用 DELIMITER 改写重定义分隔符再创建按借阅证号查询的存储过程DELIMITER // CREATE PROCEDURE sp_reader_borrow(IN p_J_No CHAR(6)) BEGIN SELECT b.G_day, b.R_day, k.B_Name, k.B_Here FROM Borrow b JOIN Book k ON b.B_No k.B_No WHERE b.J_No p_J_No; END // DELIMITER ;调用方式为 CALL sp_reader_borrow(R001); 前端应用只需要传一个读者编号join 逻辑固化在数据库端避免把表关联散落到业务代码里。参数 p_J_No 的 p_ 前缀只是命名习惯主要作用是避免与表字段 J_No 产生同名歧义。MySQL 的存储过程不支持默认参数调用时每个 IN 参数都必须传值这是和 SQL Server 的差异点。4.4 触发器应还日期自动计算借书时默认借期 30 天可以用 BEFORE INSERT 触发器在写入 Borrow 前自动填充 R_day前端和存储过程都不用手动计算DELIMITER // CREATE TRIGGER trg_borrow_duedate BEFORE INSERT ON Borrow FOR EACH ROW BEGIN IF NEW.R_day IS NULL THEN SET NEW.R_day DATE_ADD(NEW.G_day, INTERVAL 30 DAY); END IF; END // DELIMITER ;逻辑说明NEW 代表即将插入的新行NEW.R_day 是这一行的还书日期。IF 判断保证显式传入还书日期时不覆盖只对空值补默认。DATE_ADD(NEW.G_day, INTERVAL 30 DAY) 表示在借书日期上加 30 天。触发器的优势是任何入口写入都生效包括存储过程、JDBC 直接 INSERT缺点是排错时多一层隐式逻辑所以触发器只适合这种简单且无争议的规则。5. 用一组回归 SQL 验证借书还书流程课程设计验收时很多人提交的是界面截图加一段演示视频但数据库行为是否真的正确截图说明不了。更可靠的做法是把功能调试转成可重复执行的 SQL 测试脚本每次改完表结构后重跑终端输出全部符合预期才算通过。先准备最小种子数据覆盖出版社、图书、借阅人各两三条INSERT INTO Pub(C_Name, C_Tele, C_Phone, C_Addr, C_St) VALUES (机械工业, 010-1234, 12345678, 北京, 100000); INSERT INTO Book(B_No, B_Name, B_Num, B_Here, C_Name) VALUES (B001, 数据库系统概论, 5, A区01架, 机械工业); INSERT INTO Borrower(J_No, J_Name, J_Department) VALUES (R001, 张明, 计算机系);场景一验证借书和触发器执行 INSERT INTO Borrow(J_No, B_No, G_day) VALUES (R001, B001, NOW()); 后查询 SELECT * FROM v_borrow_detail预期出现一行R_day 自动等于当前日期加 30 天。场景二验证重复借阅拦截再次执行同样的 INSERT预期主键冲突报错说明联合主键确实在起作用而不是靠应用层判断。场景三验证外键约束尝试 DELETE FROM Book WHERE B_No B001; 预期外键约束报错拒绝删除仍被借阅的图书再尝试 DELETE FROM Pub WHERE C_Name 机械工业; 预期同样被拦。这个测试能证明外键不是摆设。场景四验证超期查询把某条借阅记录的直接 SQL 更新成 R_day DATE_SUB(NOW(), INTERVAL 5 DAY)然后执行SELECT J_No, B_No, DATEDIFF(NOW(), R_day) AS overdue_days FROM Borrow WHERE R_day NOW();预期返回该记录且 overdue_days 为 5。把这几组 SQL 保存为 test.sql每次改表结构后重跑一遍输出完全符合预期后再提交验收。本文还有配套的精品资源点击获取