简介这份数据库应用课程设计资源面向高校计算机相关专业学生与Web开发入门者围绕教室管理系统这一典型课程大作业场景提供从数据库建模到前后端实现的完整实践素材。压缩包共39个文件、约1.94MB以8个jsp页面文件、4个css样式与4个js脚本为主体配套Java源文件、classpath与project工程配置以及mdf、ldf数据库数据与日志文件另有docx设计文档和字体、图标等静态资源构成可直接导入IDE运行的Web项目骨架。资源已有2113人学习下载说明其在同类课程设计中具备较高参考价值。读者可据此对照E-R概念设计、关系模式与表结构定义理解MVC分层下视图与控制逻辑的组织方式并结合SQL查询、索引优化与登录权限校验等环节完成课程报告撰写与系统二次开发也可作为数据库应用综合训练的自学范本。1. 一份数据库课程设计为什么值得单独拆开看上学期帮 A 同学救一个数据库课程设计压缩包解压出来是个教室管理系统的 Web 大作业他卡在「预约时段重叠」的 SQL 上三天没有推进。这大概是数据库课程设计最典型的形态需求本身不复杂但表结构、约束、事务、索引这些关键内容全藏在几行 SQL 里。这份资源就是一个完整可跑的教室管理系统前面是浏览器里的排课、预约、审批页面后面是 MySQL 里六张互相关联的表覆盖了 Web 大作业从建库到联表查询的主要考点。适合正在赶数据库课程设计的本科生也适合想拿一个「整体规模不大但各模块齐全」的 CRUD 项目练手 Spring Boot MyBatis 的开发者。跑通大概半小时读懂那几段 SQL 需要两小时改造成自己能交的版本按下面的路子走。2. 技术栈与表结构教室管理系统的骨架是怎么搭的2.1 需求边界这个系统到底管几件事教室管理系统听起来简单真排需求的时候会发现边界很容易含糊。什么算「占用」、临时借用算不算排课、教室坏了之后还能不能预约这些问题不先定清楚写到一半就会返工。这份课程设计把范围收得很克制只做四件事教室台账记录哪个楼哪个房间、能坐多少人、有没有投影和空调排课占用记录哪个班的哪门课、在周几第几节、用哪间教室临时预约社团活动、补课、考试借用都走这条路报修登记教室设备坏了谁报的、处理到哪一步。四件事对应四类使用者。学生只做两件查空教室、提交预约。教师看自己的课表和名下学生的预约。教务管理员维护教室和课程审批预约。系统管理员管账号。这种按角色切分权限的设计在课程设计里几乎是标配好处是权限表可以做得简单用户表加一个role字段就够不需要复杂的 RBAC 五张表答辩时也讲得清。我一般建议学生在动手写代码之前先把这份边界写成一张纸的用例表标清楚每个用例对应哪张表、读还是写。这一步花二十分钟能省掉后面两天改表结构的痛苦。教室管理这类系统的通病是「删教室」——直接DELETE会撞外键所以t_classroom里必须留一个status字段做软删除0 正常、1 停用删的时候只改状态。这个坑后面第 5 章还会再说一次。2.2 技术选型Spring Boot MyBatis MySQL 三件套后端是 Spring Boot 2.7 MyBatis MySQL 8JDK 8Maven 构建。持久层选 MyBatis 而不是 JPA理由很实际答辩的时候老师会问「你这个查询怎么写的」用 MyBatis 你可以直接把 XML 里的 SQL 摊开讲用 JPA 生成的 SQL 反而解释不清。课程设计的评分点本来就偏向数据库设计选一个能把 SQL 摆在明面上的框架更合适。前端没有做前后端分离用的是 Thymeleaf 模板加 Layui 静态资源登录后的列表页、表单页都是服务端渲染。这个选择对课程设计极其友好一个java -jar起来浏览器直接访问不用再单独起一个 Node 服务演示的时候也不会因为前端环境没装好而失败。代价是页面交互比较传统但对一个要交作业的项目来说能在任何一台装了 JDK 和 MySQL 的机器上十分钟内跑起来比交互炫酷重要得多。目录结构大致是这样认准几个关键位置就不会迷路classroom-management/ ├── src/main/java/com/demo/room/ │ ├── ClassroomApplication.java # 启动类 │ ├── config/ # 拦截器、跨域、MyBatis 配置 │ ├── controller/ # 按角色分包admin / teacher / student │ ├── service/ service/impl/ # 业务逻辑事务加在这一层 │ ├── mapper/ # 接口方法名和 XML 的 id 一一对应 │ ├── entity/ # 与表一一对应的实体 │ └── common/ # 统一返回体、异常、常量 ├── src/main/resources/ │ ├── application.yml │ ├── mapper/ # 所有 XML 放这里别和接口混在 java 目录 │ ├── templates/ # Thymeleaf 页面 │ └── static/ # layui、css、js └── sql/ ├── schema.sql # 建表语句 └── data.sql # 初始数据含默认账号有一点值得单独提醒mapper的 XML 放在resources/mapper下application.yml里配mybatis.mapper-locations: classpath:mapper/*.xml。新手最常见的错误是把 XML 和 Java 接口放同一个包里本地 IDE 能跑打成 jar 之后路径就变了直接在演示机器上出现问题。2.3 六张表外键、状态位和那几个容易漏的字段整个系统的数据模型是六张表t_user、t_classroom、t_course、t_schedule、t_reservation、t_repair。前四张是基础数据后两张是业务流程流程表通过外键挂在基础表上。表名作用关键字段关联t_user账号与角色username、password、role、class_id被预约/报修引用t_classroom教室台账room_no、building、capacity、type、status被排课/预约引用t_course课程字典course_name、teacher_id、semester被排课引用t_schedule固定排课course_id、classroom_id、week_day、start_section、end_section、week_range外键指向课程和教室t_reservation临时预约classroom_id、user_id、use_date、start_time、end_time、status、auditor_id外键指向教室和用户t_repair报修记录classroom_id、reporter_id、description、status外键指向教室和用户两个最容易漏的字段我拎出来说。第一个是t_reservation.status它是整个审批流程的状态机载体0 待审批、1 已通过、2 已驳回、3 已取消。没有它就做不了「已取消的预约应该释放时段」这个逻辑冲突校验会误判。第二个是t_schedule.week_range存的是「1-16」这种周次范围字符串表示这门课只在第 1 到 16 周上。很多同学图省事只存一个week_day结果单双周课程完全没法表达。关键的建表语句大概长这样注意时间字段用TIME而不是VARCHARCREATE TABLE t_reservation ( id BIGINT PRIMARY KEY AUTO_INCREMENT, classroom_id BIGINT NOT NULL COMMENT 教室ID, user_id BIGINT NOT NULL COMMENT 申请人, use_date DATE NOT NULL COMMENT 使用日期, start_time TIME NOT NULL COMMENT 开始时刻, end_time TIME NOT NULL COMMENT 结束时刻, purpose VARCHAR(200) NOT NULL COMMENT 用途, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待审批 1通过 2驳回 3取消, auditor_id BIGINT NULL COMMENT 审批人, audit_time DATETIME NULL, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_room_date (classroom_id, use_date, status), -- 冲突校验的命门 CONSTRAINT fk_res_room FOREIGN KEY (classroom_id) REFERENCES t_classroom(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT教室预约;idx_room_date这个联合索引不是可选项。冲突校验的 SQL 永远是按「教室 日期 状态」三段过滤没有这个索引几千条数据就开始明显变慢有了它查询基本走索引答辩演示时翻页也是瞬间出结果。索引列的顺序也有讲究区分度高的classroom_id放最左status放最右因为它的取值只有四种选择性最低。3. 环境搭建与跑通从建库到浏览器打开首页3.1 建库导数据字符集和时区先定死第一步永远是建库。字符集用utf8mb4而不是utf8因为后者在 MySQL 里其实是utf8mb3存不了 emoji 和部分生僻字教室里带个「㙟」字的名字就能把插入搞挂这种问题在答辩现场出现会很难看。CREATE DATABASE classroom_db DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci; USE classroom_db; SOURCE /path/to/sql/schema.sql; -- 建表 SOURCE /path/to/sql/data.sql; -- 初始数据三个角色各一个账号data.sql里会预置三个账号学生、教师、管理员各一个密码是加密后的串登录页面上有提示。这里有个细节密码字段不要存明文课程设计里用 MD5 加固定盐也算及格用 BCrypt 更好BCryptPasswordEncoder.matches()一行就能验证。存明文的项目在答辩时被问一句「你这个密码怎么存的」就很被动了。如果不想用命令行用 Navicat 或者 DataGrip 右键「运行 SQL 文件」也行注意执行顺序必须是先 schema 后 data因为 data 里有外键引用反过来会报Cannot add or update a child row。3.2 配置连接连接串里三个参数决定能不能连上application.yml是第二个容易出问题的地方。很多同学照着网上的模板抄抄完发现不是连不上就是乱码问题基本都在连接串的参数上。server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://127.0.0.1:3306/classroom_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue username: root password: 你的密码 thymeleaf: cache: false # 开发阶段关掉模板缓存改页面不用重启 prefix: classpath:/templates/ suffix: .html mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.demo.room.entity configuration: map-underscore-to-camel-case: true # room_no 自动映射到 roomNo四个参数逐个解释一下。useUnicodetruecharacterEncodingutf8保证连接层不乱码serverTimezoneAsia/Shanghai是 MySQL 8 的必需项少了它经常报The server time zone value is unrecognized或者查出来的时间莫名差 8 小时useSSLfalse在本地关掉省事allowPublicKeyRetrievaltrue是 MySQL 8 默认认证方式caching_sha2_password需要的一个开关不开会报公钥检索失败。map-underscore-to-camel-case: true这一行看着不起眼但省掉大量手写resultMap的工作。t_classroom表的room_no会自动映射到Classroom.roomNo不用再一个个写result columnroom_no propertyroomNo/。3.3 启动自检从登录页到第一张列表配置改完mvn clean package -DskipTests打包java -jar target/xxx.jar启动。控制台出现Started ClassroomApplication in 3.2 seconds并且 Tomcat 起了 8080 端口说明服务本身没问题。这时候别急着用浏览器先做三步自检能少走很多弯路。第一步浏览器访问/login页面能出来说明静态资源和 Thymeleaf 模板路径没问题。第二步用管理员账号登录能跳转到教室列表说明数据库连通、MyBatis 的 XML 被扫描到了。第三步打开教室列表后随便按一个条件筛选能出结果说明动态 SQL 条件拼装正确。这三步分别对应静态资源、持久层、业务层三条链路卡在哪一步基本就能定位到哪一层。启动时如果报Invalid bound statement (not found)九成是 XML 没被打进 jar或者mapper-locations路径写错去target/classes/mapper/底下看一眼文件在不在就清楚了。4. 核心模块拆解一个预约请求从进入到落库的完整链路4.1 登录与角色拦截别只靠前端藏按钮课程设计里权限做不严是最常见的扣分点。页面上的按钮按角色隐藏了但地址栏直接敲/admin/room/list一样能进去这种「前端权限」在老师眼里等于没做。正确做法是加一个HandlerInterceptor在服务端做一次拦截。// config/LoginInterceptor.java public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session request.getSession(); User user (User) session.getAttribute(loginUser); // 未登录统一踢回登录页注意带上 contextPath if (user null) { response.sendRedirect(request.getContextPath() /login); return false; } // 管理员路径做二次角色校验防止学生直接敲 URL 进后台 String uri request.getRequestURI(); if (uri.startsWith(/admin) !ADMIN.equals(user.getRole())) { response.sendError(403, 无权访问); return false; } return true; } }拦截器写完后必须在WebMvcConfigurer里注册并且用excludePathPatterns放行/login、/logout、/static/**否则登录页自己也过不去会陷入死循环跳转。这个坑非常经典注册完拦截器登录页白屏或者报重定向次数过多回来检查一下放行名单就行。登录校验本身不复杂用 MyBatis 按username查一条记录然后把提交的明文密码和库里的哈希比对。比对成功后把整个User对象塞进 session后续所有页面从 session 里取当前用户不需要每次请求都查库。4.2 预约冲突校验一行 SQL 决定整个模块成不成立整个系统最核心的一段逻辑就是时段重叠判定。它的原理不难但写法上差异很大写错了会出现「明明没人用却提示冲突」或者更糟的「两个人都约上了同一间教室」。判断两个时间区间是否重叠标准写法是A.start B.end AND A.end B.start而不是BETWEEN。原因很简单BETWEEN只能处理「被包含」的情况无法处理「包含」和「部分交叉」。比如已有预约是 8:00-12:00新预约 9:00-10:00 用BETWEEN能判出来但新预约 7:00-13:00 就漏了。!-- resources/mapper/ReservationMapper.xml -- select idcountConflict resultTypeint SELECT COUNT(1) FROM t_reservation WHERE classroom_id #{classroomId} AND use_date #{useDate} AND status IN (0, 1) !-- 只有待审批和已通过占时段 -- AND start_time lt; #{endTime} !-- 注意 XML 里要转义 lt; gt; -- AND end_time gt; #{startTime} /select这段 SQL 有三个地方值得逐条说明。第一status IN (0, 1)只把「待审批」和「已通过」算作占用已驳回和已取消的必须排除否则用户取消预约后时段永远释放不出来。第二lt;和gt;是 XML 转义直接写会被 XML 解析器当成标签开头报SAXParseException。第三参数全部用#{}不要用${}后者是字符串拼接会被 SQL 注入。光校验预约表还不够固定排课的时段也得算进去否则用户可以约到正在上课的教室里。这一段用week_day加节次的区间判断select idcountScheduleConflict resultTypeint SELECT COUNT(1) FROM t_schedule WHERE classroom_id #{classroomId} AND week_day #{weekDay} AND start_section lt; #{endSection} AND end_section gt; #{startSection} AND semester #{semester} /select两次校验都通过才允许写库整个方法包在事务里。这里有一个容易被忽略的点两次查询和一次插入之间理论上存在并发窗口两个用户同时提交可能都通过校验。课程设计层面用Transactional加数据库默认的REPEATABLE READ基本够用真要做到严格互斥得靠唯一索引或者SELECT ... FOR UPDATE锁住教室行这一点在第 6 章展开。4.3 动态 SQL 与空教室查询条件拼装怎么写才不出错学生最常用的页面是「查空教室」条件有楼栋、容量、教室类型、日期、节次用户可能只填其中一两个。这种场景必须用 MyBatis 的动态 SQL不然就得在 Java 里拼字符串可读性和安全性都差。select idselectFreeRooms resultTypecom.demo.room.entity.Classroom SELECT c.* FROM t_classroom c WHERE c.status 0 if testbuilding ! null and building ! AND c.building #{building} /if if testminCapacity ! null AND c.capacity gt; #{minCapacity} /if if testroomType ! null and roomType ! AND c.type #{roomType} /if !-- 排除已被预约的 -- AND c.id NOT IN ( SELECT classroom_id FROM t_reservation WHERE use_date #{useDate} AND status IN (0,1) AND start_time lt; #{endTime} AND end_time gt; #{startTime} UNION SELECT classroom_id FROM t_schedule WHERE semester #{semester} AND week_day #{weekDay} AND start_section lt; #{endSection} AND end_section gt; #{startSection} ) ORDER BY c.building, c.room_no /selectif的判断条件必须同时判null和空串。只判null的话前端传过来一个building会拼出AND building 结果永远为空页面看着像「没有空教室」实际是 SQL 拼错了。UNION在这里比OR更清晰两个子查询各自走各自的索引执行计划也好读。分页用 PageHelper 最省事PageHelper.startPage(pageNum, pageSize)放在查询前一行返回的PageInfo里直接带total和list。手写分页的话要记住 count 查询和 list 查询的WHERE条件必须完全一致否则会出现「列表 5 条、总数显示 200」这种数据对不上的情况第 5 章会细说。4.4 审批流转状态机加乐观锁预约提交后进入待审批状态管理员在后台处理。这个环节看着只是改一个字段实际是整个系统里并发问题最集中的地方——两个管理员同时打开同一条待审批记录都点了「通过」如果没有防护审批人会互相覆盖。Service public class ReservationServiceImpl implements ReservationService { Override Transactional(rollbackFor Exception.class) public void audit(Long reservationId, Long auditorId, int result, String remark) { Reservation r reservationMapper.selectById(reservationId); if (r null) { throw new BizException(预约记录不存在); } // 只有待审批状态才允许处理已通过/已驳回的直接拒绝 if (r.getStatus() ! 0) { throw new BizException(该预约已处理不能重复审批); } // 乐观锁WHERE 带上旧状态影响行数为 0 说明被别人抢先改了 int rows reservationMapper.updateStatus(reservationId, 0, result, auditorId, remark); if (rows 0) { throw new BizException(审批冲突请刷新后重试); } } }update idupdateStatus UPDATE t_reservation SET status #{result}, auditor_id #{auditorId}, audit_time NOW() WHERE id #{reservationId} AND status #{expectStatus} !-- 乐观锁的关键旧状态作为条件 -- /updateTransactional(rollbackFor Exception.class)里的rollbackFor不能省。Spring 默认只在遇到RuntimeException时回滚自定义的BizException如果继承了Exception而不是RuntimeException抛出去之后事务照样提交数据就脏了。这个细节我在别人的项目里见过不止一次。状态流转的合法性也要在服务层卡死0 → 1、0 → 2允许1 → 3已通过后取消也允许但要记录操作人2 → 1直接拒绝。把这几个转换写成一个MapInteger, SetInteger常量表比散落在各个if里好维护得多。5. 避坑与排查跑不起来先看这五处5.1 启动阶段连不上库和页面 404现象一启动报Access denied for user rootlocalhost。原因通常不是密码错了而是 MySQL 8 的root默认只允许localhost走 socket 认证而 JDBC 走的是 TCP。解决办法是用 root 登录后执行ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 你的密码;然后FLUSH PRIVILEGES;或者干脆新建一个业务账号只授权classroom_db库权限最小化也更符合课程设计文档里写的安全设计。现象二登录页能打开一登录就 500日志里是Invalid bound statement (not found)。这是 XML 没被加载。先确认target/classes/mapper/目录下有没有对应的 XML再确认 XML 里的namespace写的是 Mapper 接口的全限定名少一个包名就绑不上最后确认接口方法名和 XML 的id完全一致包括大小写。现象三本地 IDE 里跑得好好的打成 jar 之后页面 404。Thymeleaf 模板放在src/main/resources/templates下才能被打进BOOT-INF/classes/templates如果放到了webapp或者项目根目录IDE 因为工作目录的关系能找到jar 里就找不到了。判断方法很简单jar tf target/xxx.jar | grep templates看看你的页面在不在里面。5.2 数据与 SQL 层面冲突误判和分页错乱现象四明明没人用的时段提交预约却提示「教室已被占用」。原因有两个方向。一是冲突 SQL 里status过滤条件写错了把3已取消也算进占用导致取消过的时段永远释放不出来二是时间字段建成了VARCHAR9:00 10:00这种字符串比较在位数不齐的时候会出错比如9:00 10:00是true因为字符9大于1。检查方法是在 MySQL 里直接跑那条countConflict把参数换成具体值看返回几如果是 1 就去查是哪条记录占的一下就能定位。现象五列表页只显示 5 条但分页控件显示总共 200 条翻到第 3 页就空了。这是手写分页时 count 查询和 list 查询的WHERE条件不一致导致的。典型场景是 list 查询里有NOT IN (SELECT ...)排除已占用的教室而 count 查询里忘了加这段总数就被算多了。用 PageHelper 的话这个问题会自动规避因为它基于原 SQL 生成 count 语句手写的话就把条件抽成一个sql idbaseWhere片段两处都include refidbaseWhere/从根上避免重复。现象六想删一间停用的教室报Cannot delete or update a parent row。这是外键约束在起作用t_reservation或t_schedule里还有引用。正确做法根本不该物理删除教室是历史数据删了之后往期预约查出来就是空的。改成软删除把status置为 1列表查询默认加WHERE status 0导出报表时再放开。这一点我在第 2 章提过一次实际踩坑率很高。提示排查这类问题最快的办法不是看 Java 日志而是打开 MyBatis 的 SQL 打印。在application.yml里把com.demo.room.mapper包的日志级别调成debug控制台会输出实际执行的 SQL 和参数值复制到数据库客户端里跑一遍问题立刻现形。6. 二次开发把课程设计改成能拿得出手的东西这份代码跑通只是起点真要交上去或者写进简历还得动几刀。按投入产出比排序我建议从下面几个方向改改造点具体做法难度收益冲突校验加固用唯一索引或时间片表替代应用层判断中高能讲并发空教室查询加缓存按「日期节次」做 Redis 缓存预约成功即失效中中能讲缓存一致性报表统计按楼栋/时段统计教室使用率写一条 GROUP BY低高答辩加分项操作日志AOP 切面记录谁在什么时候改了哪条记录中高体现工程意识接口化抽出一层 REST API前端换 Vue高视目标而定我最推荐先做冲突校验的加固因为它是这个项目里唯一有真正技术含量的地方也是面试官最可能追问的点。前面说的应用层「先查再插」在并发下是有窗口的真正的解法是把时间切成固定粒度的片比如以 30 分钟为单位一门课 8:00-9:40 就占 8:00、8:30、9:00、9:30 四个片建一张t_room_slot表(classroom_id, use_date, slot_index)建唯一索引。插入冲突时数据库直接抛DuplicateKeyException捕获后返回「时段已被占用」并发问题从根上消失了。// 时间片占用靠数据库唯一索引兜底比应用层判断可靠 Transactional(rollbackFor Exception.class) public void occupy(Long roomId, LocalDate date, LocalTime start, LocalTime end, Long reservationId) { ListInteger slots SlotUtils.split(start, end); // 30 分钟一片向上取整 for (Integer slot : slots) { try { slotMapper.insert(roomId, date, slot, reservationId); } catch (DuplicateKeyException e) { // 任意一片插入失败整个事务回滚之前的片自动释放 throw new BizException(时段 slot 已被占用请重新选择); } } }这段代码的关键在于异常被捕获后必须继续往外抛让Transactional感知到失败并回滚。如果吞掉异常继续循环前面的片就留在库里了反而制造了幽灵占用。改完之后记得在论文或者设计文档里补一张时间片表的 ER 图这才是真正的「数据库设计」比堆一堆 CRUD 页面有说服力。验证方法也简单开两个浏览器窗口用两个学生账号同时提交同一间教室同一时段一个成功一个必须失败。这一步走通了说明你的方案在并发下站得住。从那以后我每次拿到这种课程设计类的项目都强制先做一件事把最核心的那条业务 SQL 单独拎出来在数据库客户端里用极端参数跑一遍——时间边界相等、状态全是取消、跨天、容量刚好卡线。这几组参数能过代码基本就稳了。希望帮到你。本文还有配套的精品资源点击获取
