基于Web的教师调停课系统：双部门审核与SQL Server建表实战

简介这份毕业设计文档面向高校计算机相关专业学生与教学管理人员围绕基于Web的教师调停课系统展开管理分析与设计帮助读者理解如何用信息化手段替代传统人工调课流程解决审批环节繁琐、信息传递滞后与调课冲突等问题。资源包内含1个doc文件约200KB属于典型的毕业论文与系统分析类文档结构上涵盖可行性分析、需求分析、功能描述与UML建模等章节便于直接参考写作框架与设计思路。文档中具体梳理了显示今日课程、调停课申请、双部门审核、教室使用记录统计及系统管理与设置等模块并借助用例图、类图、序列图等建模方式呈现业务流程对需要完成同类选题或学习面向对象分析与数据库设计的学生具有较高参考价值。目前已有75人学习适合作为毕业设计选题、系统分析章节撰写与UML建模练习的辅助材料。1. 从一份教务处的“跑签表”说起这套 Web 调停课系统到底能解决什么如果你在高校教务处待过大概率见过这样的场景一位老师临时要出差需要调课于是拿着一张三联单先找院办教学主任签字再找主管教学副院长签字然后跑到教务处找分管副处长签字签完再把其中一联送到排课部门等教室安排另一联送评估办最后一联拿回学院存档。一圈跑下来半天没了赶上领导不在两天也正常。更麻烦的是排课部门拿到单子后还要手动翻教室占用表确认目标时间段有没有空教室稍不留神就撞车两个班抢同一间教室的事并不罕见。这份《基于 Web 的教师调停课系统管理分析与设计》毕业设计文档针对的正是这个流程。它把上面那套“人肉跑签”搬到浏览器里教师在线提交调停课申请系统自动校验教室占用情况申请提交后按双部门审核机制流转审核结果自动通告教室使用记录按周次、班级、科目、教师等维度统计。技术栈上文档明确采用面向对象方法设计、SQL Server 2000 做数据存储用 UML 完成用例图、顺序图、状态图、活动图和类图建模数据库层面给出了完整的建表语句。适合谁看如果你是计算机相关专业正在做教务管理类毕业设计的学生这份文档能直接当需求分析和数据库设计的参考模板如果你是教务系统的初级开发者想理解调停课业务的真实流转逻辑和表结构设计里面的用例描述和 E-R 设计能帮你少走弯路。需要提前说明的是文档偏重分析与设计阶段不是一套拿来就能跑的完整源码但它的建模思路和 SQL 建表脚本足够支撑你从零搭出一个可用的原型。2. 双部门审核怎么落库从用例图到 SQL Server 建表2.1 先理清角色和用例别急着写代码文档里用 UML 用例图把系统角色拆成三类教师、教务主管、系统管理员。教师能做的事包括注册登录、查询教室信息、提交调停课申请、查看调停课信息教务主管负责审核申请、发布调停课通告、查看教室和调停课信息系统管理员管人员权限、数据备份和系统维护。这里有个容易被忽略的设计点文档在用例分析里专门写了“调停课申请”的正常基本事件流——教师登录后先查教室使用信息确认目标教室在指定日期未被占用再提交申请。这个顺序很关键它意味着教室占用校验必须发生在申请落库之前而不是审核阶段才去查。很多同学做毕设时习惯先把申请存进去、审核时再判断冲突结果就是审核员看到一堆无效申请体验很差。调停课申请用例的前置条件是“合法的教师已经登录系统确定好要调停课的教室”后置条件虽然没有展开写但从功能描述看提交成功后系统要自动发邮件通知审核人员。备选事件流里提到“教师若未能登录系统则先需要注册”说明注册和登录是申请的前置门槛。2.2 双部门审核的状态流转逻辑文档明确写了“实行双部门审核机制”一个申请通过一个部门审核后需要另一部门再审核才能生效如果任一部门审核不通过并填写事由无需另一部门审核申请自动转入未通过页面通告。这个逻辑落到数据库里核心是申请表的 status 字段设计。常见做法是用一个整型或字符型字段表示状态比如状态值含义可执行操作0待教务主管审核教务主管通过/驳回1待教室管理部门审核教室管理部门通过/驳回2审核通过已生效发布通告3审核未通过查看驳回理由注意状态 1 只在教务主管通过后才出现状态 3 可以从状态 0 或状态 1 跳转过来。这种设计比用两个布尔字段部门 A 通过、部门 B 通过更清晰因为布尔字段无法表达“谁先审、谁后审”的顺序关系也容易在并发审核时出现状态不一致。2.3 建表脚本里的外键约束和主键选择文档第五章给出了物理设计的建表语句我把它整理成可直接在 SQL Server 里执行的版本并补上注释说明每个字段的用途-- 教学楼表一栋楼对应多条教室记录 CREATE TABLE building ( bno CHAR(20) PRIMARY KEY, -- 教学楼编号 bname CHAR(20) -- 教学楼名称 ); -- 教室表通过 bno 外键关联到教学楼 CREATE TABLE classroom ( clno CHAR(20) PRIMARY KEY, -- 教室编号 bno CHAR(20), -- 所属教学楼编号 floor CHAR(10), -- 楼层 FOREIGN KEY (bno) REFERENCES building(bno) ); -- 院系表 CREATE TABLE department ( deptno CHAR(20) PRIMARY KEY, -- 院系编号 deptname CHAR(20) -- 院系名称 ); -- 课程表注意文档原文此处外键写的是 building(deptno)实际应为 department(deptno) CREATE TABLE lesson ( cno CHAR(20) PRIMARY KEY, -- 课程编号 cname CHAR(20), -- 课程名称 credit CHAR(1), -- 学分 category CHAR(10), -- 课程类别 deptno CHAR(20), -- 开课院系 FOREIGN KEY (deptno) REFERENCES department(deptno) ); -- 教师表 CREATE TABLE teacher ( tno CHAR(20) PRIMARY KEY, -- 教师工号 tname CHAR(20), -- 教师姓名 sex CHAR(2), -- 性别 deptno CHAR(20), -- 所属院系 title CHAR(10), -- 职称 tid CHAR(20), -- 身份证号 FOREIGN KEY (deptno) REFERENCES department(deptno) ); -- 管理员表含教务主管 CREATE TABLE manager ( mno CHAR(20) PRIMARY KEY, -- 管理员编号 mname CHAR(20), -- 管理员姓名 deptno CHAR(20), -- 所属部门 mid CHAR(20), -- 身份证号 FOREIGN KEY (deptno) REFERENCES department(deptno) ); -- 教师调停课表核心业务表记录谁在什么时间用什么教室上什么课 CREATE TABLE tclass ( tno CHAR(20), -- 教师工号 clno CHAR(20), -- 教室编号 cno CHAR(20), -- 课程编号 deptno CHAR(20), -- 院系编号 weekday CHAR(8), -- 星期几 period CHAR(20), -- 节次 PRIMARY KEY (clno, weekday, period), -- 联合主键同一教室同一时段只能排一门课 FOREIGN KEY (deptno) REFERENCES department(deptno), FOREIGN KEY (tno) REFERENCES teacher(tno), FOREIGN KEY (clno) REFERENCES classroom(clno), FOREIGN KEY (cno) REFERENCES lesson(cno) ); -- 教室借用表 CREATE TABLE cborrow ( clno CHAR(20), -- 教室编号 sno CHAR(20), -- 学生学号 usedate CHAR(10), -- 使用日期 weekday CHAR(8), -- 星期几 period CHAR(20), -- 节次 uses CHAR(100), -- 用途说明 usestatus CHAR(10), -- 使用状态 PRIMARY KEY (clno, sno, usedate, period), FOREIGN KEY (clno) REFERENCES classroom(clno) );这段脚本里有几个值得展开说的点。第一tclass表的联合主键(clno, weekday, period)是防冲突的关键——它从数据库层面保证了同一间教室在同一时段的排课记录唯一任何调课申请在插入前只要查这个组合是否存在就能判断冲突。第二文档原文中lesson、teacher、manager三张表的外键都写成了REFERENCES building(deptno)这明显是笔误因为building表根本没有deptno字段正确写法应该是引用department(deptno)我在上面的脚本里已经修正。第三cborrow表的主键包含sno学生学号但文档没有给出学生表的建表语句实际使用时需要补一张student表并建立外键。提示如果你的 SQL Server 版本较新CHAR类型建议根据实际数据长度改为VARCHAR或NVARCHAR避免定长字段浪费空间。另外weekday用CHAR(8)存“星期一”这类中文值时要注意数据库排序规则是否支持中文。3. 教室占用校验和邮件通知两个最容易翻车的实现细节3.1 教室占用校验的 SQL 写法与并发问题教师提交调停课申请前系统要展示“指定日期未被占用的教室”。这个查询的本质是从classroom表里排除掉在目标weekday和period已经被tclass表占用的教室。常见写法有两种我一般用NOT EXISTS-- 查询 2025-06-10假设是星期二第 3-4 节未被占用的教室 DECLARE targetWeekday CHAR(8) 星期二; DECLARE targetPeriod CHAR(20) 3-4节; SELECT c.clno, c.bno, c.floor FROM classroom c WHERE NOT EXISTS ( SELECT 1 FROM tclass t WHERE t.clno c.clno AND t.weekday targetWeekday AND t.period targetPeriod );逻辑说明外层遍历所有教室内层子查询检查该教室在目标时段是否有排课记录NOT EXISTS返回 true 的即为空闲教室。参数targetWeekday和targetPeriod由前端传入对应教师选择的调课时间。这里有个血泪经验从“查询空闲教室”到“教师点击提交”之间存在时间窗口如果另一个教师同时提交了同一间教室的申请就可能出现两个申请都通过校验、最终排课冲突的情况。文档没有提到并发控制但实际做的时候要么在tclass表上加唯一约束联合主键已经做到了要么在插入申请时用事务加锁。我一般会在申请表的插入逻辑里包一层事务先SELECT ... WITH (UPDLOCK)锁定目标教室行再执行插入这样能避免大部分并发冲突。3.2 邮件通知的触发时机和内容模板文档在功能描述里写了“提交申请成功后系统再自动发送邮件给相关审核人员”。这个功能在毕设里通常用 SMTP 实现触发时机是申请记录成功插入数据库之后。常见做法是写一个sendMail方法在申请提交的 Service 层调用# 伪代码示例申请提交后发送通知邮件 import smtplib from email.mime.text import MIMEText def notify_reviewer(application): # 根据申请类型决定收件人教务主管或教室管理部门 if application.status 0: receiver 教务主管邮箱 else: receiver 教室管理部门邮箱 subject f新的调停课申请待审核{application.teacher_name} body f 教师{application.teacher_name} 课程{application.teacher_course} 原上课时间{application.original_time} 拟调整时间{application.new_time} 调课原因{application.reason} 请登录系统进行审核。 msg MIMEText(body, plain, utf-8) msg[Subject] subject msg[From] 系统发件邮箱 msg[To] receiver # SMTP 服务器地址和端口根据实际环境配置 with smtplib.SMTP(smtp.example.com, 25) as server: server.login(发件账号, 发件密码) server.send_message(msg)参数说明application对象包含申请的所有字段status决定收件人subject和body是邮件内容。注意邮件发送是耗时操作如果同步执行会阻塞用户请求常见做法是丢到消息队列或后台线程里异步发送。另外邮件服务器地址、端口、账号密码这些配置不要硬编码在代码里放到配置文件或环境变量中。注意文档没有给出邮件通知的具体实现细节上面是基于常见做法的补全。如果你的毕设环境不允许外发邮件可以改成站内消息通知逻辑类似。3.3 审核通告的查询与展示审核通告页面要展示三类记录审核通过的课程、等待审核的课程、未通过的课程并附加理由。这对应tclass表和申请表的不同状态查询。文档在功能描述里提到“显示审核通过的课程、等待审核的课程、未通过的课程并附加理由”实现时通常用三个独立的查询或一个带WHERE status IN (...)的查询前端按状态分组渲染。未通过记录需要展示驳回理由所以申请表里要有一个reject_reason字段在审核不通过时由审核人填写。这个字段在文档的类图描述里没有明确列出但从“填写主要事由后自动转入未通过页面”的功能描述可以推断出来。4. 避坑与排查这份设计文档里那些容易踩的坑4.1 外键引用错表文档原文的building(deptno)笔误现象照着文档第五章的建表语句执行lesson、teacher、manager三张表的外键约束创建失败报错提示building表中不存在deptno列。原因文档原文写的是foreign key deptno references building(deptno)但building表只有bno和bname两个字段deptno应该引用department表。解决把这三处外键改为REFERENCES department(deptno)同时确认department表已经在之前创建。如果先建了lesson再建department需要调整建表顺序先建被引用的表。4.2 联合主键导致的插入失败同一教室同一时段重复排课现象教师提交调停课申请时系统报主键冲突错误申请无法保存。原因tclass表的联合主键(clno, weekday, period)保证了同一教室同一时段只能有一条记录。如果目标教室在该时段已经有排课插入就会失败。解决这其实是设计上的保护机制不是 bug。正确的处理方式是在插入前先执行第 3.1 节的空闲教室查询确认无冲突后再插入。如果业务上允许同一教室同一时段有多条调课记录比如原课停掉、新课补上那需要重新考虑主键设计比如加一个自增 ID 作为主键把联合唯一约束改为普通唯一索引。4.3 双部门审核的状态跳转遗漏现象教务主管审核通过后申请状态没有变成“待教室管理部门审核”而是直接变成了“审核通过”。原因审核逻辑里只判断了“通过/不通过”没有根据当前状态决定下一个状态。状态 0 通过后应该变成状态 1状态 1 通过后才变成状态 2。解决在审核方法里加一个状态机判断根据当前status和审核结果计算新状态。建议把状态流转规则写成一个独立的函数或配置表避免散落在多处代码里。4.4 教室使用记录统计的维度缺失现象按“班级人次”统计教室使用情况时查询结果为空或数据不对。原因文档提到统计维度包括周次、班级人次、科目、教师但tclass表里没有班级字段只有教师、教室、课程、星期、节次。班级信息需要通过teacher表关联到教师所带班级或者通过cborrow表的sno关联到学生表再关联班级。解决如果要做班级维度统计需要补一张班级表和学生表建立教师-班级、学生-班级的关联关系。文档在类图描述里提到teacher类有teacher_class属性但建表语句里没有体现这是文档前后不一致的地方实际实现时需要补全。4.5 SQL Server 2000 的兼容性问题现象在新版 SQL Server 上执行文档的建表语句部分语法报错。原因SQL Server 2000 的语法和后续版本有差异比如CHAR类型的中文支持、外键约束的默认行为等。解决如果只是做毕设建议直接用 SQL Server 2008 或更高版本把CHAR改为NVARCHAR以支持中文外键约束加上ON DELETE CASCADE或ON UPDATE CASCADE根据业务需要决定。文档里的建表语句作为逻辑参考即可不必逐字照搬。5. 从设计文档到可运行原型补全缺失模块的实操建议文档给的是分析设计阶段的成果要变成能跑的系统还有几块需要自己补。第一块是前端页面文档只描述了功能没有给出页面原型。我一般会先用 Axure 或手绘把“今日课程”“调停课申请”“审核通告”三个核心页面画出来确认交互流程后再写代码。第二块是权限控制文档提到系统管理员和教务主管两级操作但没写具体怎么实现。常见做法是用角色字段加拦截器登录时把角色写入 Session每次请求检查当前角色是否有权限访问目标接口。第三块是数据备份功能文档在系统管理员用例里提到了“数据备份”但没展开。SQL Server 环境下可以用BACKUP DATABASE语句实现定时任务用 SQL Server Agent 配置。如果只是毕设演示做一个“导出当前所有表数据为 SQL 文件”的功能也能满足要求。验证系统是否可用的方法很简单造几条测试数据走一遍完整流程——教师登录、查空闲教室、提交申请、教务主管审核通过、教室管理部门审核通过、通告页面显示通过记录、教室使用记录里能查到这条排课。如果每一步都能正常流转说明核心逻辑没问题。我自己的习惯是每次改完数据库脚本或审核逻辑都强制走一遍这个全流程避免改 A 坏 B。希望帮到你。本文还有配套的精品资源点击获取