MySQL+Java Swing学生宿舍管理系统课程设计：从建表到事务的完整方案

简介：这份资源面向高校计算机相关专业学生与Java初学者，提供一套可直接运行的学生宿舍管理系统课程设计完整方案，帮助解决MySQL课程设计选题难、代码与文档不配套的问题。压缩包共334个文件，约112.72MB，以202个class编译文件、47个java源码、22张png界面截图、9个xml配置及数据库db文件为主，另含少量C++工程残留文件，源码、图表与文档一并打包。已有268人学习下载，说明该方案在同类课设中具备一定参考价值。读者可从中获得基于Java Swing的桌面端界面实现、管理员与学生信息管理、宿舍分配等模块的源码结构，以及配套图表和设计文档，便于对照理解数据库表设计与前后端交互逻辑，也可作为二次开发或答辩演示的基础模板。

1. 从一次答辩被问到哑口无言的经历说起

很多同学做 MySQL 课程设计，第一反应是去网上找一份“能跑就行”的源码，改个标题就交。我见过一个典型场景：某同学把学生宿舍管理系统的登录页跑通了，答辩时老师只问了一句“你这个床位分配，两个人同时点确认会怎样”，当场卡住。问题不在代码量，而在这套方案从需求到数据一致性根本没想清楚。这份基于 MySQL + Java + Swing 的学生宿舍管理系统，要解决的就是“课程设计既要能演示、又要经得起追问”这件事，适合正在做数据库课设、Java 课设，或者需要一份完整方案模板照着改的同学和初级开发者。它把建库建表、事务处理、界面交互、文档图表打包在一起，让你不用从零拼凑，而是有一套能讲明白来龙去脉的底稿。

2. 需求与选型：为什么是 MySQL + Java Swing 这套组合

2.1 先把业务边界划清楚

宿舍管理系统的功能看着简单，真拆开并不少。我一般会先画一张业务边界图，把角色和动作列全：管理员负责楼栋、房间、床位的基础数据维护，宿管负责入住、退宿、调宿的日常操作，学生只能查自己的住宿信息和报修记录。这三类角色对应三套权限，如果一开始不分开，后面界面和 SQL 都会乱。

具体到功能点，核心是四块：楼栋房间床位管理、学生入住退宿调宿、报修与维修记录、统计报表（入住率、空床位、报修处理率）。课程设计不需要做成商业系统，但这四块必须闭环，否则演示时数据对不上。比如退宿之后床位状态要变回空闲，报修单要能关联到具体房间，这些联动关系就是老师最爱追问的地方。

提示：需求阶段就把“哪些操作会改多张表”标出来，后面设计事务时直接对应，省得返工。

2.2 技术选型不是拍脑袋

选 MySQL 是因为课程设计本身就要体现数据库能力，建表、索引、视图、存储过程、事务都能用上，评分点覆盖得全。选 Java Swing 而不是 Web 框架，理由很实际：课设周期短，Swing 不用配服务器、不用写前端页面，一个 main 方法就能跑起来演示，答辩现场不依赖网络环境，翻车概率低。JDBC 直连数据库，把 SQL 写清楚，反而更能体现对数据库的理解。

这套组合的短板也要心里有数：Swing 界面偏朴素，并发能力弱。但课程设计的验收重点是数据模型和业务逻辑，不是高并发，所以这个取舍是合理的。如果老师明确要求 B/S 架构，那就得换方案，这点在开题时确认清楚。

2.3 环境与依赖清单

动手前把环境固定下来，避免“我这能跑你那不能跑”的玄学问题。通常的做法是：

依赖就一个 JDBC 驱动 jar，放进项目 lib 目录并加到构建路径。别小看这一步，驱动版本不匹配是新手最常见的启动失败原因，报错信息还特别绕。

3. 数据库设计：从 E-R 图到建表脚本的落地

3.1 实体关系怎么拆

宿舍管理的核心实体有六个：楼栋、房间、床位、学生、住宿记录、报修单。关系上，一栋楼含多个房间，一个房间含多个床位，一个床位同一时间只能被一个学生占用，住宿记录就是“学生—床位—时间段”的关联表，报修单挂在房间上并关联提交学生。

这里有个容易设计错的地方：很多人把“当前住的是谁”直接塞进床位表的一个字段，结果历史记录全丢了，退宿再入住就查不到过去。正确的做法是床位表只存状态（空闲/占用/维修），谁在住由住宿记录表用时间区间表达。这样调宿、退宿、历史查询都能支持，答辩时被问“怎么查某个学生住过哪些床位”也能答上来。

3.2 建表脚本与关键约束

下面这段是核心表的建表语句，字段和约束都按上面说的关系来：

-- 楼栋表 CREATE TABLE building ( building_id INT PRIMARY KEY AUTO_INCREMENT, building_name VARCHAR(50) NOT NULL UNIQUE, floors INT NOT NULL DEFAULT 6 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 房间表，楼栋外键 CREATE TABLE room ( room_id INT PRIMARY KEY AUTO_INCREMENT, building_id INT NOT NULL, room_no VARCHAR(20) NOT NULL, capacity INT NOT NULL DEFAULT 4, CONSTRAINT fk_room_building FOREIGN KEY (building_id) REFERENCES building(building_id), UNIQUE KEY uk_building_room (building_id, room_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 床位表，状态用枚举约束 CREATE TABLE bed ( bed_id INT PRIMARY KEY AUTO_INCREMENT, room_id INT NOT NULL, bed_no VARCHAR(10) NOT NULL, status ENUM('FREE','OCCUPIED','REPAIR') NOT NULL DEFAULT 'FREE', CONSTRAINT fk_bed_room FOREIGN KEY (room_id) REFERENCES room(room_id), UNIQUE KEY uk_room_bed (room_id, bed_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 住宿记录表，时间区间表达占用关系 CREATE TABLE accommodation ( acc_id INT PRIMARY KEY AUTO_INCREMENT, student_id INT NOT NULL, bed_id INT NOT NULL, start_date DATE NOT NULL, end_date DATE DEFAULT NULL, CONSTRAINT fk_acc_student FOREIGN KEY (student_id) REFERENCES student(student_id), CONSTRAINT fk_acc_bed FOREIGN KEY (bed_id) REFERENCES bed(bed_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

几个设计点值得说明。第一，所有表用 InnoDB，因为要事务和外键，MyISAM 不支持，这是课设里常被扣分的地方。第二，房间号在楼栋内唯一而不是全局唯一，用联合唯一索引表达，符合真实业务。第三，住宿记录的 end_date 允许为空，表示“当前仍在住”，查询当前住宿就是end_date IS NULL，比额外加状态字段更简洁。第四，床位状态用 ENUM 限制取值，防止程序写错状态值。

3.3 索引与视图的加分项

课程设计想拿高分，索引和视图是性价比很高的加分点。常用查询比如“按楼栋统计入住率”“查某学生的住宿历史”，对应的索引要建上：

-- 加速按学生查住宿历史 CREATE INDEX idx_acc_student ON accommodation(student_id); -- 加速按床位查当前占用 CREATE INDEX idx_acc_bed_end ON accommodation(bed_id, end_date); -- 入住率统计视图 CREATE VIEW v_occupancy AS SELECT b.building_id, b.building_name, COUNT(bd.bed_id) AS total_beds, SUM(CASE WHEN bd.status = 'OCCUPIED' THEN 1 ELSE 0 END) AS used_beds FROM building b JOIN room r ON r.building_id = b.building_id JOIN bed bd ON bd.room_id = r.room_id GROUP BY b.building_id, b.building_name;

视图把统计逻辑封装起来，界面层直接查视图，SQL 干净很多。索引这里要注意别乱建，住宿记录表数据量不大，两个索引足够，建多了反而拖慢写入，答辩时被问“为什么建这个索引”要能说出对应的查询场景。

4. 功能模块实现：入住退宿的事务与界面联动

4.1 入住操作的事务处理

入住是整套系统里最需要小心的地方，因为它同时改床位状态和插住宿记录，任何一步失败都会导致数据不一致。我一般用 JDBC 手动控制事务，核心逻辑如下：

// 入住：改床位状态 + 插住宿记录，同一事务 public boolean checkIn(int studentId, int bedId) throws SQLException { Connection conn = null; PreparedStatement ps1 = null, ps2 = null; try { conn = DBUtil.getConnection(); conn.setAutoCommit(false); // 关闭自动提交，开启事务 // 1. 只有空闲床位才能入住，条件更新防止并发重复占用 ps1 = conn.prepareStatement( "UPDATE bed SET status='OCCUPIED' WHERE bed_id=? AND status='FREE'"); ps1.setInt(1, bedId); int updated = ps1.executeUpdate(); if (updated == 0) { conn.rollback(); return false; // 床位已被占用或不存在 } // 2. 插入住宿记录，end_date 为空表示在住 ps2 = conn.prepareStatement( "INSERT INTO accommodation(student_id, bed_id, start_date) VALUES(?,?,CURDATE())"); ps2.setInt(1, studentId); ps2.setInt(2, bedId); ps2.executeUpdate(); conn.commit(); return true; } catch (SQLException e) { if (conn != null) conn.rollback(); throw e; } finally { // 关闭资源，恢复自动提交 if (ps1 != null) ps1.close(); if (ps2 != null) ps2.close(); if (conn != null) { conn.setAutoCommit(true); conn.close(); } } }

这段代码的关键在第一步的WHERE status='FREE'。它不是先查再改，而是把判断条件写进 UPDATE 语句，靠数据库的行锁保证同一床位不会被两个人同时占上。这就是第 1 章那个答辩问题的答案：并发下第二个请求的 UPDATE 影响行数为 0，直接回滚返回失败。参数上，studentId 和 bedId 由界面传入，日期用数据库的 CURDATE() 避免客户端时间不准。失败时看什么？先看 updated 是否为 0，再看异常堆栈里是不是外键约束报错（学生或床位不存在）。

4.2 退宿与调宿的联动

退宿是入住的逆操作：把住宿记录的 end_date 填上当前日期，床位状态改回 FREE，同样放在一个事务里。调宿稍微复杂，本质是“退旧床 + 入新床”，可以复用上面两个方法，但要注意顺序——先退再入，如果新床入住失败，旧床的退宿也要回滚，所以调宿应该包在一个更大的事务里，而不是简单调两个独立方法。

// 调宿：退旧床 + 入新床，整体一个事务 public boolean changeBed(int studentId, int oldBedId, int newBedId) throws SQLException { Connection conn = DBUtil.getConnection(); try { conn.setAutoCommit(false); // 结束旧住宿记录 try (PreparedStatement ps = conn.prepareStatement( "UPDATE accommodation SET end_date=CURDATE() " + "WHERE student_id=? AND bed_id=? AND end_date IS NULL")) { ps.setInt(1, studentId); ps.setInt(2, oldBedId); ps.executeUpdate(); } // 旧床置空闲 try (PreparedStatement ps = conn.prepareStatement( "UPDATE bed SET status='FREE' WHERE bed_id=?")) { ps.setInt(1, oldBedId); ps.executeUpdate(); } // 新床占用，条件更新 try (PreparedStatement ps = conn.prepareStatement( "UPDATE bed SET status='OCCUPIED' WHERE bed_id=? AND status='FREE'")) { ps.setInt(1, newBedId); if (ps.executeUpdate() == 0) { conn.rollback(); return false; } } // 插入新住宿记录 try (PreparedStatement ps = conn.prepareStatement( "INSERT INTO accommodation(student_id, bed_id, start_date) VALUES(?,?,CURDATE())")) { ps.setInt(1, studentId); ps.setInt(2, newBedId); ps.executeUpdate(); } conn.commit(); return true; } catch (SQLException e) { conn.rollback(); throw e; } finally { conn.setAutoCommit(true); conn.close(); } }

这里用 try-with-resources 管理 PreparedStatement，比手动 close 干净。注意调宿方法里没有单独捕获异常后继续执行，任何一步抛异常都直接回滚，保证要么全成要么全不成。这种“大事务包小步骤”的写法，是课程设计里体现事务理解的最好素材。

4.3 Swing 界面与数据层解耦

Swing 最容易写成一坨：按钮监听里直接拼 SQL、直接弹窗。这样代码没法维护，答辩时也不好讲。我一般分三层：界面层（JFrame/JPanel）只负责收集输入和展示结果，业务层（Service）负责事务和校验，数据层（DAO）只写 SQL。界面按钮里只调 Service 方法，拿到布尔结果再决定弹什么提示。

// 界面层按钮监听，只调业务层，不碰 SQL checkInBtn.addActionListener(e -> { int studentId = Integer.parseInt(studentIdField.getText().trim()); int bedId = Integer.parseInt(selectedBedId); try { boolean ok = accommodationService.checkIn(studentId, bedId); if (ok) { JOptionPane.showMessageDialog(this, "入住成功"); refreshBedTable(); // 刷新床位列表 } else { JOptionPane.showMessageDialog(this, "该床位已被占用，请刷新后重试"); } } catch (SQLException ex) { JOptionPane.showMessageDialog(this, "操作失败：" + ex.getMessage()); } });

这样拆的好处是，老师问“事务写在哪”，你直接指 Service 层；问“界面怎么刷新”，你指 refreshBedTable。职责清晰，代码量也不大。表格数据用 DefaultTableModel 从 ResultSet 填充，注意把列名和数据库字段对应好，别在界面里硬编码一堆字符串。

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

5.1 中文乱码，查出来全是问号

现象：界面输入中文，存进数据库变成???，或者查出来显示乱码。原因通常是三处字符集不一致：数据库/表没设 utf8mb4、JDBC 连接串没指定编码、Swing 源文件编码不对。解决：建库时DEFAULT CHARSET=utf8mb4，连接串加?useUnicode=true&characterEncoding=utf8，IDE 里把文件编码统一设成 UTF-8。三处对齐，基本不会再犯。

5.2 驱动加载失败或时区报错

现象：启动就抛ClassNotFoundException或The server time zone value is unrecognized。原因：MySQL 8.0 的驱动类名是com.mysql.cj.jdbc.Driver，老写法com.mysql.jdbc.Driver会警告甚至失败；时区问题则是连接串没配 serverTimezone。解决：驱动类名换成 cj 版本，连接串加serverTimezone=Asia/Shanghai。这类报错信息其实很明确，照着改就行，别急着怀疑代码逻辑。

5.3 外键顺序导致建表失败

现象：执行建表脚本报Cannot add or update a child row或建表时外键引用失败。原因：建表顺序不对，先建了子表后建父表，或者插入测试数据时先插了住宿记录再插学生。解决：建表按“楼栋→房间→床位→学生→住宿记录→报修单”的顺序，删表反着来；插数据同理。脚本开头加SET FOREIGN_KEY_CHECKS=0只在明确知道后果时用，课设里不建议，容易掩盖问题。

5.4 事务没生效，退宿后床位还是占用

现象：调了退宿方法，界面提示成功，但床位状态没变。原因多半是连接用了自动提交，或者事务提交前连接被关闭，也可能是 UPDATE 的 WHERE 条件写错导致影响行数为 0 却没检查。解决：确认setAutoCommit(false)在操作前执行、commit()在最后执行，每个 UPDATE 都检查返回值。排查时在关键步骤打印影响行数，比盯着界面猜快得多。

5.5 界面卡死或数据不刷新

现象：点按钮后界面无响应，或者操作成功但表格还是旧数据。原因：Swing 的事件线程里做了耗时数据库操作，或者操作后忘了重新查数据填充表格。解决：课设数据量小，一般不至于卡死，但养成“操作成功后统一调 refresh 方法重查”的习惯；如果确实慢，把数据库操作放到 SwingWorker 里。刷新方法要覆盖所有受影响的表格，别只刷一个。

6. 验收与答辩：怎么把这份方案讲成自己的

验收前我一般会做一张自查表，按评分点逐项过：

答辩时最容易被问的三个问题，提前准备好答案：一是“并发入住怎么防重复”，答条件更新加事务，最好能现场演示两个窗口抢同一床位；二是“为什么用住宿记录表而不是床位表存学生”，答历史可追溯、支持调宿；三是“索引为什么建这两个”，答对应学生查历史和床位查当前占用两个高频查询。演示流程建议按“建库→登录→入住→调宿→退宿→看统计视图”走一遍，中间故意触发一次床位已占用的失败提示，反而显得你考虑周全。

血泪经验是：答辩前一定在干净环境里从零跑一遍建表脚本和程序，别依赖你本地已经改过的数据库。我有一次就是本地数据是手动补的，换台机器演示直接崩，从那以后每次交付前都强制走一遍“删库→执行脚本→跑主流程”的完整链路。希望这份方案的结构和这些踩坑记录，能帮你把课程设计交得踏实、讲得清楚。

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