简介：这份资源是面向高校计算机相关专业学生的数据库课程设计实践案例，围绕教务管理系统展开，采用MySQL与Java技术栈，帮助读者理解从需求分析、数据库设计到系统实现与测试的完整开发流程，适合正在学习数据库原理与应用、Java编程等课程、需要完成课程设计或提升动手能力的学生参考使用。压缩包共28个文件，约4.45MB，包含9个java源文件与9个class编译文件、properties配置、jar依赖包、sql建库脚本及工程配置文件等，覆盖源码、数据库脚本与工程结构，便于直接导入运行和二次修改。目前已有2649人学习下载，具备一定的参考热度。读者可从中获得教务管理场景下的数据库表结构设计思路、Java实现代码与工程组织方式，并据此完成个性化改造与功能扩展，为后续数据库应用开发打下实践基础。

1. 教务管理系统课程设计：从选课冲突到成绩归档的完整数据库方案

每年选课季，教务系统最怕的不是流量高峰，而是同一门课被两个班同时抢、一个学生选了两门时间重叠的课、成绩录到一半发现学号对不上。数据库课程设计如果只做增删改查，答辩时很难讲出深度；真正能撑住场面的，是把选课冲突检测、成绩归档、权限隔离这些教务场景里的硬骨头啃下来。这套基于 MySQL 与 Java 的教务管理系统，面向课程设计、毕设开题和需要交付完整数据库方案的读者，覆盖学生、教师、教务管理员三类角色，核心表结构、事务边界和冲突校验逻辑都按可落地的标准设计，不是玩具级 Demo。

2. 需求与数据模型：三类角色、六张核心表怎么定

2.1 先定业务边界，再画 E-R 图

教务管理系统的需求看起来杂，但落到数据库层面，真正需要建模的实体并不多。我一般先把业务边界收在三件事上：学生选课与退课、教师录入成绩、教务管理员维护课程与班级。超出这三件事的功能，比如排课算法、教室调度，课程设计阶段直接砍掉，否则表结构会膨胀到无法在答辩前讲清楚。

角色与权限的划分决定了后续表设计的粒度。学生只能看到自己的选课记录和成绩；教师只能操作自己任教课程的成绩；教务管理员拥有课程、班级、学生信息的维护权限。这个约束不是靠前端隐藏按钮实现的，而是要在数据库层通过外键关联和查询条件双重保证。很多同学翻车就翻在这里：前端把按钮藏了，后端接口却裸奔，答辩时老师随便构造一个请求就能改别人成绩。

E-R 图的核心关系可以这样梳理：学生与课程是多对多，通过选课表关联；教师与课程是一对多，一门课由一个教师主讲；班级与学生是一对多，一个班包含多名学生。选课表是整张图的枢纽，它同时承载了学生、课程、学期、成绩四个维度的信息，也是后面冲突检测和成绩归档的主战场。

2.2 六张核心表的结构与字段取舍

表结构设计最忌讳一上来就堆字段。我的习惯是先确定每张表的“主键 + 业务唯一键 + 状态字段”三件套，再往里填业务属性。下面这套结构经过课程设计场景验证，字段数量控制在可讲清楚的范围内。

-- 学生表：学号作为业务唯一键，自增 id 仅作内部关联 CREATE TABLE student ( id BIGINT PRIMARY KEY AUTO_INCREMENT, stu_no VARCHAR(20) NOT NULL UNIQUE COMMENT '学号，业务唯一标识', name VARCHAR(50) NOT NULL, class_id BIGINT NOT NULL COMMENT '所属班级', password VARCHAR(64) NOT NULL COMMENT '存储加盐哈希，不存明文', status TINYINT DEFAULT 1 COMMENT '1在读 0离校', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_class (class_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 课程表：课程号唯一，容量字段用于选课人数上限校验 CREATE TABLE course ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_no VARCHAR(20) NOT NULL UNIQUE, name VARCHAR(100) NOT NULL, teacher_id BIGINT NOT NULL, credit DECIMAL(3,1) NOT NULL COMMENT '学分，支持0.5', capacity INT NOT NULL DEFAULT 60 COMMENT '选课容量上限', semester VARCHAR(20) NOT NULL COMMENT '如2024-2025-1', KEY idx_teacher (teacher_id), KEY idx_semester (semester) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 选课表：学生+课程+学期唯一，防止重复选课 CREATE TABLE enrollment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id BIGINT NOT NULL, course_id BIGINT NOT NULL, semester VARCHAR(20) NOT NULL, score DECIMAL(5,2) DEFAULT NULL COMMENT 'NULL表示未录入', status TINYINT DEFAULT 1 COMMENT '1已选 2已退', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_stu_course_sem (student_id, course_id, semester), KEY idx_course (course_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

教师表、班级表结构相对简单，这里不展开。重点说三个设计取舍。第一，选课表的唯一键包含学期字段，因为同一门课可能在不同学期重复开设，学生跨学期选同一门课是合法的，但同一学期内重复选必须被数据库拦住。第二，成绩字段允许为 NULL，用 NULL 表示“未录入”，而不是用 0 分，这个区别在统计及格率时非常关键，0 分和未录入是两回事。第三，所有表统一用 utf8mb4，避免学生姓名里的生僻字变成问号，这是血泪经验，答辩现场演示时名字乱码很尴尬。

提示：选课表的唯一键是防重复选课的最后一道防线，应用层的“先查再插”在高并发下会失效，必须靠数据库唯一约束兜底。

2.3 索引不是越多越好，按查询路径来建

课程设计里常见的误区是给每个字段都加索引，结果插入变慢、答辩时也说不清为什么建。正确的做法是按实际查询路径反推。教务系统的高频查询无非四类：按学号查学生、按学期查课程、按学生查选课记录、按课程查选课名单。对应的索引在上面的建表语句里已经埋好：student 表的 stu_no 唯一索引、course 表的 semester 索引、enrollment 表的 uk_stu_course_sem 联合唯一索引和 idx_course 索引。

联合唯一索引 uk_stu_course_sem 的顺序有讲究。把 student_id 放在最前面，是因为“查某个学生的所有选课”是最频繁的操作，这个索引可以直接覆盖该查询。如果反过来把 course_id 放前面，查学生选课就用不上这个索引，只能走 idx_course 再过滤，效率差一截。这类细节在答辩时讲出来，比背概念有说服力得多。

3. 选课与成绩模块实现：事务、冲突检测与批量录入

3.1 选课接口的事务边界与容量校验

选课是整套系统里唯一需要严格事务控制的操作。一次成功的选课要同时完成三件事：检查课程是否已满、检查是否与已选课程时间冲突、写入选课记录。这三步必须在一个事务里完成，否则会出现“容量检查通过但写入时已满”的超卖问题。

// 选课核心逻辑：事务内完成容量校验与写入 @Transactional(rollbackFor = Exception.class) public void enroll(Long studentId, Long courseId, String semester) { // 1. 行锁锁定课程记录，防止并发超卖 Course course = courseMapper.selectForUpdate(courseId); if (course == null) { throw new BizException("课程不存在"); } // 2. 统计当前已选人数（status=1 才算有效选课） int enrolled = enrollmentMapper.countActive(courseId, semester); if (enrolled >= course.getCapacity()) { throw new BizException("课程容量已满"); } // 3. 时间冲突检测：查该生本学期已选课程的时间段 List<TimeSlot> conflict = enrollmentMapper.findConflictSlots( studentId, semester, course.getTimeSlot()); if (!conflict.isEmpty()) { throw new BizException("与已选课程时间冲突"); } // 4. 写入选课记录，唯一键兜底防重复 enrollmentMapper.insert(studentId, courseId, semester); }

这段代码的关键在第一步的selectForUpdate。它会对课程行加排他锁，把并发选同一门课的请求串行化，容量校验才不会失效。很多同学只写了普通的 select，压测时两个请求同时读到“还剩 1 个名额”，结果都插入成功，课程超卖。这个坑在答辩演示时如果被问到并发，答不上来很扣分。

时间冲突检测依赖课程表里的时间段字段。实际设计中，一门课的时间可以存成“周一 3-4 节”这样的结构化字段，冲突判断就是比较两个时间段是否有交集。课程设计阶段不必做复杂的排课算法，把时间段简化为“星期 + 起止节次”两个字段，冲突判断用区间重叠逻辑即可，实现简单且能讲清楚。

3.2 成绩批量录入与归档的幂等设计

教师录入成绩的场景有两个特点：一是批量操作，一个班几十条记录一次提交；二是可能重复提交，网络抖动或误点都会导致同一批数据发两次。如果直接逐条 update，重复提交会把已经改过的成绩再覆盖一遍，虽然结果一样，但审计日志会乱。更稳妥的做法是用“课程 + 学生”作为幂等键，配合乐观锁版本号。

-- 成绩录入：带版本号的幂等更新 UPDATE enrollment SET score = #{score}, version = version + 1, updated_at = NOW() WHERE student_id = #{studentId} AND course_id = #{courseId} AND semester = #{semester} AND status = 1 AND version = #{expectedVersion};

更新影响行数为 0 时，说明版本号不匹配或记录不存在，应用层据此判断是重复提交还是数据异常。批量录入时，把整批更新放在一个事务里，任何一条失败就整体回滚，避免出现“录了一半”的中间状态。这个设计在答辩时可以作为亮点讲：幂等不是靠前端防重复点击，而是靠数据库层的版本控制。

成绩归档是另一个容易被忽略的点。学期结束后，成绩需要从“可编辑”状态转为“只读”状态。我的做法是在课程表加一个archived标记，归档操作把该学期所有选课记录的成绩锁定，后续任何更新请求先检查归档标记，已归档则直接拒绝。这样既保护了历史数据，又不需要额外的归档表，课程设计阶段足够用。

3.3 权限隔离在 SQL 层的落地方式

前面提到权限不能只靠前端。具体到 SQL 层，教师查询成绩时必须带上teacher_id = 当前登录教师的条件，学生查询成绩时必须带上student_id = 当前登录学生的条件。这个约束最好封装在 Mapper 层，而不是让每个 Service 方法自己拼，否则漏掉一处就是越权漏洞。

// 教师查成绩：强制拼接任教课程条件 public List<ScoreVO> listScoresByTeacher(Long teacherId, Long courseId) { return enrollmentMapper.selectScores( courseId, teacherId // SQL 中作为 course.teacher_id 的过滤条件 ); }

对应的 SQL 里，enrollment 表 join course 表，where 条件同时包含 courseId 和 teacherId。这样即使前端传了一个不属于该教师的 courseId，查询结果也是空，而不是报错泄露信息。这种“查不到”比“无权限”更安全的处理方式，在答辩时讲出来能体现安全意识。

4. 避坑与排查：课程设计里最容易翻车的五个点

4.1 中文乱码：从建库到连接串的全链路检查

现象是学生姓名、课程名在页面上显示为问号或乱码。原因通常出在三个环节之一：数据库字符集不是 utf8mb4、JDBC 连接串没指定字符集、表字段用了 latin1。解决顺序是先查库、再查表、最后查连接串。建库时统一CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci，连接串加上useUnicode=true&characterEncoding=utf8，两步做完基本不会再出问题。答辩前一定要用带生僻字的名字测一遍，别等演示时才发现。

4.2 选课超卖：容量校验没加锁

现象是课程容量 60，实际选上 62 人。原因是容量校验和插入之间没有锁保护，并发请求同时通过校验。解决办法是在事务内对课程行加SELECT ... FOR UPDATE，把校验和写入串行化。如果不想用行锁，也可以在课程表加一个已选人数字段，用UPDATE course SET enrolled = enrolled + 1 WHERE enrolled < capacity的原子更新来兜底，影响行数为 0 就说明满了。两种方案选一种，别混用。

4.3 成绩统计把 NULL 当 0 算

现象是及格率统计偏低，明明有人没录成绩却被算成不及格。原因是AVG(score)和score < 60都会把 NULL 排除或误判。正确做法是统计时显式过滤score IS NOT NULL，未录入的记录单独计数。这个坑很隐蔽，因为数据量小时看不出来，答辩时老师问一句“没录成绩的怎么算”就露馅了。

4.4 外键约束导致删除失败

现象是删除课程时报外键冲突。原因是选课表里有该课程的记录。课程设计阶段不建议直接物理删除课程，而是用状态字段标记“停开”，选课记录保留。如果确实要删，先删选课记录再删课程，且必须在事务里做。更稳妥的做法是建表时外键加ON DELETE RESTRICT，让数据库明确拒绝危险操作，而不是级联删除把成绩一起干掉。

4.5 事务不生效：注解加错位置

现象是@Transactional加了但回滚不生效。常见原因有三个：方法不是 public、同类内部调用绕过了代理、异常被 catch 后没重新抛出。排查时先确认方法修饰符，再检查调用路径是否经过 Spring 代理，最后看 catch 块里有没有throw。这个坑几乎每届都有人踩，答辩前用一次故意抛异常的测试验证回滚，比事后排查省事得多。

5. 验收与答辩：怎么用一套测试数据讲清设计价值

验收这套系统，我一般准备三组数据：一组正常流程数据，用来演示选课、录成绩、查成绩的完整链路；一组边界数据，包括容量刚好满的课程、时间冲突的两门课、成绩为 NULL 的记录；一组异常数据，用来演示重复选课被拒、越权查询返回空、已归档学期无法修改。三组数据覆盖了答辩老师最可能追问的场景，演示时按“正常→边界→异常”的顺序走，逻辑清晰且能主动暴露设计点。

答辩陈述的时间通常只有五到八分钟，结构比内容更重要。我的建议是按“业务痛点→表结构设计→关键实现→验证结果”四段讲。业务痛点用选课冲突和成绩误录两个场景切入，三十秒讲完；表结构只讲选课表这一个枢纽表，说清唯一键和索引的设计理由；关键实现挑事务选课和幂等录成绩两个点，配合代码片段讲；最后用测试数据的结果收尾，证明冲突被拦住、重复提交不产生脏数据。

下面这张验收清单可以直接对照检查，每项都对应一个可演示的操作：

这张表的价值在于，每一项都能在答辩现场用一条 SQL 或一次点击验证，老师问“你怎么保证不超卖”，你直接演示选满后再选被拒，比口头解释有说服力。我见过太多同学把时间花在界面美化上，结果被问一句“并发怎么处理”就卡住，很可惜。

从那以后我每次带课程设计，都要求学生在答辩前把这张验收表逐项跑一遍，跑不通的项就是答辩时的雷。数据库课程设计的分数，往往不取决于功能多少，而取决于你能不能把一两个关键设计讲透、演示清楚。这套方案的表结构和实现逻辑可以直接拿去改，把课程名、学期字段换成自己学校的口径就能跑。希望帮到你。

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