简介：这份数据库课程设计资料包面向高校计算机及相关专业学生与课程设计指导教师，围绕“学生宿舍管理系统”给出可参考的完整实现方案，对宿舍管理业务流程、双角色权限分配和数据库表单设计有较直观的示范。系统按寝室长与宿管员划分权限，登录后进入不同界面：寝室长可查看寝室人员信息、提交报修并修改密码；宿管员可检索与维护学生住宿信息、处理报修状态、管理学生账号及密码。配套数据库设计涵盖寝室长、宿管员、报修与学生信息等表单，便于理解表间关系与增删改查逻辑。压缩包共3个文件，包含rar源码包、sql建库脚本和docx文档模板，整体约2.96MB，可辅助完成环境搭建、数据库初始化与课设文档撰写。已有5057人学习，适合需要课程设计选题、功能拆解和报告模板的读者参考与二次完善。

1. 从一次“床位对不上”说起：这个课设真正要解决什么

带过几届数据库课程设计之后，我发现学生宿舍管理系统这个题目看似简单，翻车点却特别集中：有人把床号直接塞进学生表里，有人建了六张表却没写一条完整的事务，演示时一导入数据就报外键错误。这个题目的真正难点从来不是界面，而是把“一栋楼—一间房—一张床—一个学生—一次入住记录”这五层关系在关系模型里表达清楚，再让入住、调宿、退宿三条业务线在同一套约束下跑通。这套方案面向要交数据库课程设计、数据库实训或毕设预研的读者，配套的 sql 文件、源代码和 Word 模板可以对照着改。整套设计的重心放在数据模型和事务边界上，界面只做到够演示，避免把时间花在无谓的页面上。

2. 需求梳理与 E-R 设计：从三条业务线拆出六张核心表

学生宿舍管理系统常见的扁平化版本是：学生表里直接放楼号、房间号、床位号三列，入住时改这三列，退宿时清空。界面看着能跑，一问“这个学生上学期住哪”就答不上来，再问“这张床现在是谁”只能靠翻入住登记本。问题的根源在建模阶段——把“当前状态”当成了唯一状态，没给时间维度留位置。这一章先把三条业务线拆开，再倒推需要哪些实体，最后讨论两个最容易在答辩时被追问的取舍。

2.1 从入住、调宿、退宿三条业务线倒推实体

先不要打开建表工具，拿一张纸把业务动作列出来。住宿管理的核心动作只有三个：新生入住、学生调宿、毕业生退宿。每个动作背后对应一组必须被记录的事实。

入住这条线要回答的问题是：哪个学生在什么时间住进了哪张床，办理人是谁。调宿这条线要回答：学生从哪张床换到哪张床，什么时候换的，原床位什么时候释放。退宿这条线要回答：学生什么时候离开，床位释放后状态变成什么。此外还有两条查询线会贯穿始终：按楼、按房间统计入住率；按学生查历史住宿记录。

从这些事实出发，实体就清楚了。学生是一个实体，楼是一个实体，房间是一个实体，床位是一个实体。但光有这四个还不够——入住动作本身必须留下一条带时间戳的记录，否则历史查询无从谈起。所以我一般会再拆出两张表：入住记录表负责承载“谁在什么时间段占用哪张床”，系统用户表负责记录操作人，方便后续做简单的权限区分和操作留痕。六张表的骨架就是这么来的：student、dorm_building、dorm_room、bed、checkin_record、sys_user。

提示：如果课设要求里还提到报修或卫生检查，可以再加一张repair_record，但不要在核心事务没跑通之前就铺开。六张核心表加一张扩展表，是课程设计比较稳妥的规模。

这里有一个容易被忽略的点：房间和床位为什么要分开？有些同学会问，房间号加床号不就能定位一张床了吗。能定位，但无法独立表达“这张床当前是空闲、占用还是维修中”。把床位单独建表，状态字段才有地方落，调宿事务也才有明确的加锁对象。房间表的职责是描述物理空间（楼层、朝向、床位数），床位表的职责是描述可分配资源，两个粒度不要混在一起。

2.2 主键、外键与范式取舍：为什么床位表要保留状态字段

接下来是主键设计。学生表用学号做主键最自然，VARCHAR(12)足够覆盖大多数学号格式。楼用楼号做主键，房间和床位则建议用自增代理键BIGINT，再在业务列上加唯一约束。原因很实际：房间号在不同楼里会重复，如果拿“楼号+房间号”做联合主键，所有引用房间的外键都要带两列，写 SQL 和写代码都会变啰嗦。用代理键，外键只带一列，唯一性靠UNIQUE KEY (building_id, room_no)保证，既干净又不丢约束。

床位的状态字段是一个典型的“冗余换查询”的取舍。严格按第三范式，床位是否空闲完全可以从入住记录表推导：checkout_time IS NULL的记录存在就是占用，不存在就是空闲。但每次查空床位都要做一次反连接，演示时数据量一大就明显卡顿。通常的做法是在bed表上保留一个status字段，取值 0 空闲、1 占用、2 维修，由入住和退宿事务负责同步更新。

注意：这个冗余字段在答辩时几乎一定会被问到。要能说清楚两件事：第一，它不改变事实来源，入住记录仍然是权威数据；第二，一致性由事务保证，入住和退宿必须在同一个事务里同时改记录和床位状态，不能分两次提交。能把这层讲明白，比多写两个页面更能体现设计能力。

学生表里要不要放当前床位？我的建议是不放。放了就要在调宿时同步改学生表，多一处状态就多一处不一致的风险。查询当前床位时走checkin_record里checkout_time IS NULL的那条记录，配合(student_id, checkin_time)索引，性能完全够用。范式不是教条，但每引入一处冗余，都要能指出它换来了什么、由谁负责维护。

3. 建表与约束落地：SQL 脚本里每一条约束都有理由

建表脚本是数据库课设里最容易被草草带过的部分——很多提交上来的 sql 文件只有字段和类型，没有外键、没有索引、没有注释，答辩时被问“这条外键为什么加”就答不上来。这一章按核心表把 DDL 写出来，重点不在语法，而在每条约束背后的业务理由。下面的脚本按 MySQL 8.0 和 InnoDB 引擎来写，5.7 也基本能跑，字符集统一用utf8mb4。

3.1 六张核心表的建表语句与字段说明

先看学生表和床位表。这两张表是入住事务的两端，字段设计要能支撑校验。

-- 学生信息表：入住时校验学籍状态 CREATE TABLE student ( student_id VARCHAR(12) NOT NULL COMMENT '学号，主键', student_name VARCHAR(20) NOT NULL COMMENT '姓名', gender CHAR(1) NOT NULL COMMENT '性别：M男 F女', dept_name VARCHAR(50) NOT NULL COMMENT '院系', class_name VARCHAR(30) NOT NULL COMMENT '班级', phone VARCHAR(15) DEFAULT NULL COMMENT '联系电话', enroll_status TINYINT NOT NULL DEFAULT 1 COMMENT '学籍状态：1在籍 0离校', PRIMARY KEY (student_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生信息表'; -- 床位表：调宿事务的加锁对象 CREATE TABLE bed ( bed_id BIGINT NOT NULL AUTO_INCREMENT COMMENT '床位主键', room_id BIGINT NOT NULL COMMENT '所属房间', bed_no TINYINT NOT NULL COMMENT '房间内床位序号，从1开始', status TINYINT NOT NULL DEFAULT 0 COMMENT '状态：0空闲 1占用 2维修', PRIMARY KEY (bed_id), UNIQUE KEY uk_room_bed (room_id, bed_no), KEY idx_room (room_id), CONSTRAINT fk_bed_room FOREIGN KEY (room_id) REFERENCES dorm_room (room_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='床位表';

student.enroll_status不是摆设。入住校验的第一步就是查这个字段，离校学生不允许再办理入住。bed.status的默认值设成 0（空闲），新建床位时不用额外写初始化脚本。uk_room_bed这个唯一约束防止同一房间出现两个“1号床”，idx_room则是给“按房间查床位”的列表页准备的——外键本身在 InnoDB 里会自动建索引，但显式写出来更利于答辩时说明设计意图。

再看入住记录表，这张表承载时间维度，是历史查询的唯一事实来源。

-- 入住记录表：checkout_time 为 NULL 表示仍在住 CREATE TABLE checkin_record ( record_id BIGINT NOT NULL AUTO_INCREMENT COMMENT '记录主键', student_id VARCHAR(12) NOT NULL COMMENT '学号', bed_id BIGINT NOT NULL COMMENT '床位', checkin_time DATETIME NOT NULL COMMENT '入住时间', checkout_time DATETIME DEFAULT NULL COMMENT '退宿时间，NULL表示在住', operator_id VARCHAR(20) DEFAULT NULL COMMENT '办理人账号', PRIMARY KEY (record_id), KEY idx_student_time (student_id, checkin_time), KEY idx_bed (bed_id), CONSTRAINT fk_record_student FOREIGN KEY (student_id) REFERENCES student (student_id), CONSTRAINT fk_record_bed FOREIGN KEY (bed_id) REFERENCES bed (bed_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='入住记录表';

checkout_time允许为空是整张表的关键设计。一条记录从插入到退宿，只改这一个字段，不删行、不搬数据。历史记录因此天然保留，查“某人住过哪些床”只需要按student_id过滤，按checkin_time排序即可。idx_student_time是复合索引，顺序不能反——先按学号定位，再按时间排序，正好匹配最常见的查询模式。

3.2 “一个学生只能有一条在住记录”怎么用生成列兜住

MySQL 没有部分索引，没法直接写“只对checkout_time IS NULL的行建唯一索引”。如果不做任何约束，同一个学生可能被插进两条在住记录，演示时就会出现“一人占两床”的尴尬数据。课程设计里常见的补救办法是在应用层查一次再插入，但并发下并不可靠。

我一般会用生成列加唯一索引把这个约束下沉到数据库层：

-- 在住学生学号：在住时为学号，退宿后为 NULL，多个 NULL 不冲突 ALTER TABLE checkin_record ADD COLUMN active_student VARCHAR(12) GENERATED ALWAYS AS (IF(checkout_time IS NULL, student_id, NULL)) STORED, ADD UNIQUE KEY uk_active_student (active_student);

生成列active_student会在每次插入或更新时自动计算：checkout_time为 NULL 时取student_id，否则取 NULL。唯一索引允许多个 NULL 并存，所以退宿后的历史记录不会互相冲突，而在住记录会被强制唯一。这个写法在 MySQL 5.7 及以上都支持，答辩时拿出来讲，能直接说明“约束不只写在代码里，也写在表结构里”。

提示：如果学校机房用的是较老的 MySQL 版本，生成列可能不可用，那就退回到触发器方案，或者至少在入住事务里用SELECT ... FOR UPDATE锁住学生记录再判断。方案可以降级，但“约束下沉到数据库”这个思路要保留。

4. 入住、调宿、退宿的事务实现：三条业务线的代码骨架

数据库课设的代码部分不需要写得多花哨，但事务边界必须清楚。很多同学把三条 update 语句依次执行，中间不做任何控制，演示时一旦某一步失败，床位状态和入住记录就对不上。这一章用 Java + JDBC 把三条业务线的骨架写出来，重点看加锁顺序和提交时机。下面的代码假设已经有一个DataSourceUtil负责拿连接，业务异常用自定义的BizException表达。

4.1 入住登记：三步校验与事务边界

入住要做的三件事是：确认学生在籍、确认床位空闲、写记录并改床位状态。三步必须在一个事务里完成，任何一步失败都整体回滚。

public void checkIn(String studentId, long bedId, String operatorId) throws SQLException { Connection conn = null; try { conn = DataSourceUtil.getConnection(); conn.setAutoCommit(false); // 关闭自动提交，事务从这里开始 // 第一步：锁定学生行，确认在籍。FOR UPDATE 防止并发下状态被改 String sqlStudent = "SELECT enroll_status FROM student WHERE student_id = ? FOR UPDATE"; try (PreparedStatement ps = conn.prepareStatement(sqlStudent)) { ps.setString(1, studentId); try (ResultSet rs = ps.executeQuery()) { if (!rs.next()) throw new BizException("学生不存在"); if (rs.getInt("enroll_status") != 1) throw new BizException("学生已离校"); } } // 第二步：锁定床位行，确认空闲 String sqlBed = "SELECT status FROM bed WHERE bed_id = ? FOR UPDATE"; try (PreparedStatement ps = conn.prepareStatement(sqlBed)) { ps.setLong(1, bedId); try (ResultSet rs = ps.executeQuery()) { if (!rs.next()) throw new BizException("床位不存在"); if (rs.getInt("status") != 0) throw new BizException("床位已被占用或维修中"); } } // 第三步：写入住记录 + 更新床位状态，两条语句同一事务 String sqlInsert = "INSERT INTO checkin_record(student_id, bed_id, checkin_time, operator_id) " + "VALUES (?, ?, NOW(), ?)"; try (PreparedStatement ps = conn.prepareStatement(sqlInsert)) { ps.setString(1, studentId); ps.setLong(2, bedId); ps.setString(3, operatorId); ps.executeUpdate(); } String sqlUpdate = "UPDATE bed SET status = 1 WHERE bed_id = ?"; try (PreparedStatement ps = conn.prepareStatement(sqlUpdate)) { ps.setLong(1, bedId); ps.executeUpdate(); } conn.commit(); // 三步全部成功才提交 } catch (Exception e) { if (conn != null) conn.rollback(); // 任一步失败整体回滚 throw e; } finally { if (conn != null) { conn.setAutoCommit(true); conn.close(); } } }

这段代码有三个值得在文档里写清楚的点。第一，FOR UPDATE的顺序是先学生后床位，全系统所有涉及这两张表的事务都按这个顺序加锁，避免两个事务互相等待形成死锁。第二，checkin_time用NOW()由数据库生成，不用应用服务器的时钟，避免演示机时间不准导致记录时间错乱。第三，提交放在所有写操作之后，回滚放在 catch 里，finally只负责恢复连接状态，不承担业务回滚。

参数上，studentId和bedId都来自前端选择，operatorId从登录会话里取。如果课设要求里没有登录模块，可以把operator_id允许为空，但字段保留，答辩时说明这是为后续权限扩展预留的位置，比直接删掉更显完整。

4.2 调宿与退宿：状态流转与锁顺序

调宿本质上是“退旧床 + 入新床”的组合动作。它比入住多一个风险点：如果先锁新床位再锁旧床位，两个学生互相调换床位时就可能死锁。所以调宿事务统一约定先锁bed_id较小的那张床，再锁较大的，用一个确定的顺序把死锁概率压到最低。

public void changeBed(String studentId, long oldBedId, long newBedId) throws SQLException { long first = Math.min(oldBedId, newBedId); long second = Math.max(oldBedId, newBedId); Connection conn = null; try { conn = DataSourceUtil.getConnection(); conn.setAutoCommit(false); // 按 bed_id 升序加锁，所有调宿事务遵守同一顺序 lockBed(conn, first); lockBed(conn, second); // 关闭旧记录：只改 checkout_time，不删行 String sqlClose = "UPDATE checkin_record SET checkout_time = NOW() " + "WHERE student_id = ? AND bed_id = ? AND checkout_time IS NULL"; try (PreparedStatement ps = conn.prepareStatement(sqlClose)) { ps.setString(1, studentId); ps.setLong(2, oldBedId); if (ps.executeUpdate() != 1) throw new BizException("未找到在住记录，无法调宿"); } // 释放旧床位，占用新床位，并插入新记录 updateBedStatus(conn, oldBedId, 0); updateBedStatus(conn, newBedId, 1); insertRecord(conn, studentId, newBedId); conn.commit(); } catch (Exception e) { if (conn != null) conn.rollback(); throw e; } finally { if (conn != null) { conn.setAutoCommit(true); conn.close(); } } }

退宿则简单得多，只锁一张床，改一条记录，释放一个床位：

public void checkOut(String studentId, long bedId) throws SQLException { // ... 事务开启 // 1. UPDATE checkin_record SET checkout_time = NOW() // WHERE student_id = ? AND bed_id = ? AND checkout_time IS NULL // 2. UPDATE bed SET status = 0 WHERE bed_id = ? // 3. 两步行数都必须为 1，否则回滚并提示“该学生不在此床位” // ... 提交 }

退宿的校验点在影响行数上。如果checkout_time IS NULL的条件没命中，说明学生本来就不在这张床上，这时候必须回滚，不能把床位状态改了。很多演示翻车就是因为退宿语句没加checkout_time IS NULL条件，把一条历史记录的退宿时间覆盖了，查历史时出现时间倒挂。

注意：三条业务线的状态流转要能画成一张图写进文档：床位 0→1 对应入住，1→0 对应退宿，1→1 对应调宿（旧床释放、新床占用）。答辩时被问“状态机在哪”，能直接指到事务代码和表字段，比空谈“用了状态模式”更有说服力。

5. 常见问题与排查：四个最容易翻车的点

课程设计的调试时间往往比编码时间还长，问题却高度集中。这一章按“现象 → 原因 → 解决”把四个最常见的问题拆开，前两个出在建表和初始化阶段，后两个出在联调和演示阶段。

5.1 建表与初始化阶段的两个坑

坑一：导入 sql 文件报外键错误。

现象：执行初始化脚本时，前面的表建好了，后面的表报Cannot add or update a child row或errno 1452。

原因：建表顺序或插入顺序不满足外键依赖。checkin_record引用了student和bed，bed又引用了dorm_room，如果脚本里先插记录再插学生，约束就会拦下来。

解决：脚本按依赖顺序组织——先建dorm_building，再建dorm_room，再建bed，再建student，最后建checkin_record。插入初始数据时同样按这个顺序。如果确实需要临时打乱，可以在脚本头部加SET FOREIGN_KEY_CHECKS = 0;，结束时再置回 1，但这种方法只适合本地调试，交上去的脚本最好保持依赖顺序清晰。

坑二：中文姓名和楼名显示成问号。

现象：插入的中文数据查出来是???，或者排序结果不符合拼音顺序。

原因：库、表、连接三处的字符集不一致。常见情况是建库时用了默认的latin1，建表时指定了utf8mb4，JDBC 连接串又没带字符集参数。

解决：建库语句显式写DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_general_ci，每张表也带上同样的声明，JDBC URL 加上useUnicode=true&characterEncoding=utf8。三处对齐之后，中文和排序都正常。已经建好的库可以用ALTER DATABASE ... CHARACTER SET utf8mb4补救，但表级和列级要逐张检查，不如一开始就写对。

5.2 功能演示与联调阶段的两个坑

坑三：演示时刚入住的学生查不到，刷新后又出现。

现象：点完“办理入住”，列表页没变化，手动刷新或者重启应用后数据又在了。

原因：事务提交时机或连接自动提交设置有问题。常见写法是conn.setAutoCommit(false)之后忘记commit()，连接关闭时被驱动回滚；另一种是用了连接池，业务代码提交了但查询走了另一个未提交的会话。

解决：在入住、调宿、退宿三个方法里统一用try-catch-finally结构，commit()放在所有写操作之后、catch之外，rollback()放在catch里。调试时可以在提交前后各打一条日志，确认提交确实执行了。连接池配置里把autoCommit显式设为false，避免业务代码和池配置打架。

坑四：本地跑得好好的，到答辩教室就报驱动或时区错误。

现象：换一台机器启动，报Unknown system variable 'serverTimezone'或者时间字段差 8 小时。

原因：本地和演示机的 MySQL 版本、JDBC 驱动版本不一致，或者连接串没指定时区。

解决：把驱动版本和连接串一起写进项目说明文档。连接串统一加serverTimezone=Asia/Shanghai，驱动包跟着项目一起提交，不要依赖演示机上的全局配置。答辩前在演示机上完整跑一遍初始化脚本和三条业务流程，这一步花十分钟，能省掉现场手忙脚乱。

6. 验收与答辩：演示流程、追问清单与文档对照

验收前我一般会做一张对照表，把 Word 文档里的设计和实际提交的 sql、代码逐项对齐。评审老师最常做的动作就是翻到文档某一页，问“这个表在脚本里在哪”，对不上就会扣分。下面这张表可以直接拿去用。

答辩演示按“一条主线、三个动作”来组织，不要逐个页面点。主线是“一名新生从入住到调宿再到退宿”，三个动作依次演示：入住时展示床位状态从空闲变占用、入住记录新增一条；调宿时展示旧记录checkout_time被填上、新记录插入、两张床位状态互换；退宿时展示记录关闭、床位释放。每个动作演示完停两秒，让老师看清列表变化，比快速点完十个页面有效得多。

追问环节高频问题集中在三处。第一处是范式：“床位状态字段是不是冗余？”回答要点是承认冗余、说明它换来了查询效率、指出一致性由事务保证。第二处是并发：“两个管理员同时给一个学生办入住会怎样？”回答要点是FOR UPDATE行锁加在住唯一索引双保险，并说明锁顺序。第三处是扩展：“如果要做报修功能怎么改？”回答要点是新增repair_record表，外键指向bed，不改动现有三张核心表的结构。

Word 模板的使用也有讲究。不要把模板当成填空表，章节目录要跟自己的设计走：需求分析、概念设计、逻辑设计、物理设计、功能实现、测试与总结，六章对应六张核心表的推导过程。表结构说明那一节，每张表配一段“为什么这样设计”的文字，比单纯贴字段列表更能体现思考。sql 文件按schema.sql和data.sql分开提交，源代码目录里放一个README说明启动步骤和数据库连接配置，这三样东西齐了，验收时被翻到任何一处都能对上。

从那以后我每次带课设，都会在提交前强制走一遍“文档翻到哪、脚本指到哪、代码跑到哪”的三点对照，宁可少做一个页面，也不让设计和实现对不上。希望这套结构能帮到你，把时间花在数据模型和事务上，答辩时自然有东西可讲。

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