简介：一份针对酒店员工管理系统的计算机专业毕业论文设计文档，适合计算机相关专业学生参考选题、结构撰写与系统开发实现。内容围绕SSM框架、MySQL数据库、HTML及B/S架构展开，完整覆盖课题背景、可行性分析、系统流程图、用例图、数据库设计、界面实现和系统测试等章节，并提供了管理员、普通管理员、员工三种角色的权限划分与功能模块说明，对毕业设计或课程项目的落地具有较强的参考价值。资源为1个docx文档，大小约970KB，包含论文全文共32页，目录结构清晰，便于直接查阅和续写。目前已吸引201人浏览学习，适合需要快速搭建毕设框架或借鉴论文格式与设计思路的读者。
1. 酒店员工管理系统为什么值得自研而不是采购通用人事 SaaS
酒店一线员工的排班规则，远比写字楼里的固定工时复杂：客房部按当天退房清房量安排班次，餐饮部同时排早中晚三班，前台经常需要跨零点换班。通用人事软件把排班考勤收敛在“固定上下班时间 + 加班审批”这套模型里，到了酒店场景就出现班次结束时间早于开始时间、月度工时浮动、换班需多人确认等兼容成本。与其年年付定制开发费用，不如按酒店的真实流程做一套员工管理系统，把排班、打卡、考勤汇总和人员状态放进同一个数据库。这篇内容要做的就是从一个可落地的设计和实现出发，先讲清楚数据库表怎么设计，再给出后端接口写法、前端操作界面，最后落到上线前必须处理的冲突检测、权限和离职交接问题。
2. 数据库模型设计：员工档案、排班、考勤三张表的约束关系
决定一个酒店员工管理系统的开发成本，通常先看数据模型。人、某一天、某个时间段这三类信息，如果混在一张表里，后期加需求时往往要重构。常见做法是拆成三张核心表：员工表存相对静态的档案；排班表描述未来某个员工在哪个时间段应该在岗；考勤表记录实际的打卡结果。下面是这套设计的建表 SQL 和字段取舍。
2.1 员工表：员工工号与部门关联的取舍
CREATE TABLE emp ( emp_no VARCHAR(20) NOT NULL COMMENT '员工工号，全局唯一', emp_name VARCHAR(50) NOT NULL COMMENT '员工姓名', dept_id INT NOT NULL COMMENT '部门ID，关联dept表', position VARCHAR(30) NULL COMMENT '岗位：前台/客房/餐饮/工程', phone VARCHAR(15) NULL COMMENT '手机号，用于登录和通知', hire_date DATE NULL COMMENT '入职日期', status TINYINT NOT NULL DEFAULT 1 COMMENT '1在职 0离职', PRIMARY KEY (emp_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;员工表的主键建议直接用员工工号，不使用自增 ID。酒店行业里员工工号本身就有业务含义，比如前台以 Q 开头、客房以 K 开头，并且员工离职后工号会被回收给后续入职的人。如果使用自增主键，回收工号会导致历史和未来数据关联混乱。dept_id 单独存，不要直接写“客房部”这样的字符串，因为部门改名字时只需要改部门表一行记录。
2.2 排班表：用 shift_date 加 start_time/end_time 表达跨天班次
CREATE TABLE schedule ( id BIGINT NOT NULL AUTO_INCREMENT, emp_no VARCHAR(20) NOT NULL COMMENT '关联emp.emp_no', dept_id INT NOT NULL COMMENT '冗余部门ID，按部门快速过滤', shift_date DATE NOT NULL COMMENT '班次日期', start_time TIME NOT NULL COMMENT '上班时刻', end_time TIME NOT NULL COMMENT '下班时刻，允许小于start_time表示跨天', shift_type VARCHAR(10) NULL COMMENT '早班/中班/夜班', PRIMARY KEY (id), UNIQUE KEY uk_emp_date (emp_no, shift_date), KEY idx_dept_date (dept_id, shift_date) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;排班表有两个容易踩坑的设计点。第一，UNIQUE KEY uk_emp_date限制了同一个员工同一天只能有一条排班，这是防重复录入最便宜的手段，排班界面后端保存时不用再做一次存在性检查。第二，end_time 允许小于 start_time，用来表示跨天班次，比如前台夜班 22:00 到次日 06:00，就存 start_time='22:00'、end_time='06:00'。查询展示时前端能直接显示，但计算工时或做冲突检测时需要对这种记录单独处理，后面第 5 章会给出具体做法。dept_id 冗余在这里，是为了避免每次按部门查排班都要先关联员工表再取部门。
2.3 考勤表：打卡记录的幂等约束
CREATE TABLE attendance ( id BIGINT NOT NULL AUTO_INCREMENT, emp_no VARCHAR(20) NOT NULL COMMENT '关联emp.emp_no', work_date DATE NOT NULL COMMENT '出勤日期，以排班shift_date为准', clock_in DATETIME NULL COMMENT '实际上班打卡时间', clock_out DATETIME NULL COMMENT '实际下班打卡时间', is_late TINYINT NOT NULL DEFAULT 0 COMMENT '1迟到', is_early TINYINT NOT NULL DEFAULT 0 COMMENT '1早退', source VARCHAR(10) NULL COMMENT '打卡来源：ipad/手机/门禁', PRIMARY KEY (id), UNIQUE KEY uk_emp_workdate (emp_no, work_date) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;考勤表的唯一键是 (emp_no, work_date)，一个员工同一天只能有一条考勤汇总。实际打卡时，如果已经存在记录就更新 clock_in 或 clock_out，而不是再插入一行，否则月度统计时同一个人的迟到次数会被重复累计。work_date 使用排班表中的 shift_date，而不是自然日。原因在于跨天班次：夜班员工 22:00 上班、次日 06:00 下班，两次打卡跨了两个自然日，但如果按自然日拆分，一次班次就会被拆成两条考勤记录，统计口径会乱。
三张表的约束关系可以汇总成下面这个表，用于评审时快速对齐：
| 表名 | 唯一键 | 约束目的 |
|---|---|---|
| emp | emp_no | 员工身份全局唯一 |
| schedule | (emp_no, shift_date) | 一人一天只能有一条排班 |
| attendance | (emp_no, work_date) | 一人一天只能一条考勤汇总 |
3. 后端接口设计与实现：排班查询、打卡校验与月度汇总
后端部分，常见实现是 Spring Boot 3.x 配合 MyBatis。选择 Spring Boot 是因为排班、打卡这类接口本质上是少量表的新增和查询，它的自动配置能省掉大量模板代码；MyBatis 则方便把复杂 SQL 写在 XML 里，后续调整统计口径不用重新编译依赖的 service 层。下面按接口拆开讲。
3.1 工程结构与依赖：按接口划分模块
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> </dependency>代码里我习惯按接口组织 controller 和 service，而不是按实体类组织。一个排班相关接口对应 ScheduleController、ScheduleMapper，一个考勤相关接口对应 AttendanceController、AttendanceService。这样加需求时影响面最小，比如“排班增加批量复制上周”只改 Schedule 相关文件，不会碰考勤逻辑。Mapper XML 放在 resources/mapper 目录，接口和 SQL 分开，方便 DBA 评审慢查询时直接打开 XML 看语句。
3.2 按部门查询一周排班：时间范围参数化
@RestController @RequestMapping("/api/schedule") public class ScheduleController { private final ScheduleMapper scheduleMapper; public ScheduleController(ScheduleMapper scheduleMapper) { this.scheduleMapper = scheduleMapper; } @GetMapping("/week") public List<ScheduleVO> week(@RequestParam Long deptId, @RequestParam String weekStart) { LocalDate start = LocalDate.parse(weekStart); LocalDate end = start.plusDays(6); return scheduleMapper.selectByDeptAndRange(deptId, start, end); } }<select id="selectByDeptAndRange" resultType="ScheduleVO"> SELECT s.emp_no, e.emp_name, s.dept_id, s.shift_date, s.start_time, s.end_time, s.shift_type FROM schedule s JOIN emp e ON s.emp_no = e.emp_no WHERE s.dept_id = #{deptId} AND s.shift_date BETWEEN #{start} AND #{end} AND e.status = 1 ORDER BY s.shift_date, s.start_time </select>这里 weekStart 由前端传周一日期，格式固定为 yyyy-MM-dd，后端用LocalDate.parse解析，再加 6 天得到周日。接口返回的是平铺的排班记录，不是组装好的日历结构，因为不同门店的排班展示方式不同，有的按周表格看，有的按人看列表，后端只返回原始排班记录，由前端决定怎么渲染。SQL 里BETWEEN是闭区间，正好覆盖一周七天。JOIN emp 并过滤 status=1，是为了不把已离职员工的排班展示给排班主管。
3.3 打卡校验：迟到判定的时间基准来自排班而非固定时刻
public Attendance clockIn(String empNo, LocalTime clockTime) { LocalDate today = LocalDate.now(); Schedule schedule = scheduleMapper.selectByEmpAndDate(empNo, today); if (schedule == null) { throw new BizException("今天没有排班，不能打卡"); } boolean isLate = clockTime.isAfter(schedule.getStartTime()); Attendance att = attendanceMapper.selectByEmpAndDate(empNo, today); if (att == null) { att = new Attendance(); att.setEmpNo(empNo); att.setWorkDate(today); att.setClockIn(LocalDateTime.of(today, clockTime)); att.setIsLate(isLate ? 1 : 0); attendanceMapper.insert(att); } else { att.setClockIn(LocalDateTime.of(today, clockTime)); if (isLate) { att.setIsLate(1); } attendanceMapper.update(att); } return att; }这段逻辑的核心是“早退和迟到都是相对于这个员工当天的排班时间来判断的”，而不是统一用 9 点作为迟到线，否则夜班员工永远会被判迟到。isLate一旦置为 1 就不再清除，因为员工发现迟到后重新打卡不应该把迟到覆盖掉，这是酒店考勤管理的常见规则。同一个员工一个自然日内的第二次打卡走 update 分支，保证 attendance 不会出现重复记录。
3.4 月度考勤汇总：在 SQL 里聚合而不是在内存里计数
<select id="summaryMonthly" resultType="AttendanceSummaryVO"> SELECT emp_no, COUNT(*) AS work_days, SUM(is_late) AS late_days, SUM(is_early) AS early_days, SUM(TIMESTAMPDIFF(MINUTE, clock_in, clock_out)) AS work_minutes FROM attendance WHERE work_date BETWEEN #{startDate} AND #{endDate} GROUP BY emp_no </select>月度汇总直接在 SQL 里做聚合，而不是把所有考勤记录加载到内存再一层层 for 循环加总。几十个员工的单月记录看起来不多，但按年查询或连锁酒店多门店汇总时，内存方式会把单次请求的耗时从几十毫秒拉到几秒。注意work_minutes对这个统计方式是基于打卡的实际时间差计算的，跨天班次因为 clock_out 是完整的 DATETIME，包含日期，所以 TIMESTAMPDIFF 结果天然正确；真正需要修正跨天问题的是排班冲突检测，也就是第 5 章的内容。
4. 前端管理界面与交互：部门树、排班表格和编辑状态
酒店员工管理系统的前端，最重要的页面就是“排班管理”。它要同时解决两个问题：让排班主管快速看清一周内每个部门的人怎么安排，以及让修改班次的操作尽量少点几下鼠标。常见实现是 Vue 3 + Element Plus，左侧部门树，右侧排班表格。
4.1 页面结构：左侧部门树加右侧排班表格
<template> <el-container> <el-aside width="220px"> <el-tree :data="deptTree" node-key="id" :props="{ label: 'name', children: 'children' }" @node-click="onSelectDept" /> </el-aside> <el-main> <el-table :data="scheduleRows" border> <el-table-column prop="empName" label="员工" width="100" /> <el-table-column prop="shiftDate" label="日期" width="110" /> <el-table-column prop="startTime" label="上班" width="80" /> <el-table-column prop="endTime" label="下班" width="80" /> <el-table-column label="班次" width="120"> <template #default="{ row }"> <el-select v-model="row.shiftType" size="small"> <el-option label="早班" value="早班" /> <el-option label="中班" value="中班" /> <el-option label="夜班" value="夜班" /> </el-select> </template> </el-table-column> </el-table> </el-main> </el-container> </template>部门树的数据结构是{ id, name, children }，与后端 dept 表的父子关系对应。排班表格每一行代表一个员工某一天的排班。el-select直接放在表格列里，主管点开下拉就能改班次，不需要先选中行再点“编辑”按钮。这个交互对高频换班的酒店场景很重要：早餐班临时缺人时，主管能在 10 秒内改完三四个人的班次。
4.2 数据加载：调用一周排班接口并对应渲染
import { ref, onMounted } from 'vue' const deptId = ref(null) const weekStart = ref('') const scheduleRows = ref([]) async function loadWeek() { const params = new URLSearchParams({ deptId: deptId.value, weekStart: weekStart.value }) const res = await fetch(`/api/schedule/week?${params}`) if (!res.ok) { throw new Error('加载排班失败') } scheduleRows.value = await res.json() } onMounted(() => { weekStart.value = getMonday(new Date()) loadWeek() })这里的 fetch 调用对应第 3.2 节的排班接口，前端把当前选中部门和本周周一日期传给后端。getMonday是一个工具函数，把当前日期规整到本周周一。接口返回的每个字段直接映射到表格列，后端返回 null 的 end_time 字段表格会显示为空，代表这个员工当天没有排班。
实际操作中，点击左侧部门树节点就重新调一次loadWeek()，并把 scheduleRows 清空，避免上一个部门的排班残留显示在表格里。给表格加v-loading指令，在请求发出期间显示 loading 遮罩，防止主管在数据还没回来时误改旧数据。
4.3 批量保存：编辑后的排班如何提交到后端
async function saveRows() { const body = scheduleRows.value.map(row => ({ empNo: row.empNo, shiftDate: row.shiftDate, startTime: row.startTime, endTime: row.endTime, shiftType: row.shiftType })) const res = await fetch('/api/schedule/batch', { method: 'PUT', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(body) }) if (!res.ok) { alert('保存失败，请检查是否有重复排班') } }前端不按行提交，而是把当前表格所有行做成数组一次提交，对应后端批量更新接口。这样做的好处是主管可以连续改多行后统一保存，网络请求次数少，数据库也能用事务保证这一批排班要么全部成功要么全部失败。后端 batch 接口的常见做法是逐条执行 upsert，即存在则更新、不存在则插入，然后整体提交事务。
前端交互动作与后端接口的对应关系可以整理成一张表，新成员接手时看这张表就能定位代码：
| 前端动作 | 请求地址 | 方法 |
|---|---|---|
| 切换部门/加载一周排班 | /api/schedule/week?deptId=&weekStart= | GET |
| 修改班次下拉框 | 无请求，本地暂存 | - |
| 批量保存排班 | /api/schedule/batch | PUT |
| 查看员工某月考勤 | /api/attendance?empNo=&month= | GET |
5. 上线前必做的三类验证与参数调优
系统能跑通不等于能上线。酒店员工管理系统最容易在三个边界出问题：排班重叠、越权查看、离职员工的排班残留。这三类问题都和数据写入规则有关，放到上线前去验证比事后补数据要轻松得多。
5.1 排班重叠检测：用分钟化区间处理跨天班次
跨天排班让冲突检测不能直接用 TIME 比较，否则 22:00 到次日 06:00 和 05:00 到 07:00 会被误判为不重叠。我一般会在接口层把时间转成当天分钟数再比较：
private boolean isOverlap(Schedule existing, LocalTime newStart, LocalTime newEnd) { int exStart = existing.getStartTime().toSecondOfDay() / 60; int exEnd = existing.getEndTime().toSecondOfDay() / 60; if (exEnd <= exStart) { exEnd += 1440; } int nStart = newStart.toSecondOfDay() / 60; int nEnd = newEnd.toSecondOfDay() / 60; if (nEnd <= nStart) { nEnd += 1440; } return nStart < exEnd && exStart < nEnd; }核心思路是把跨天班次的结束时间加上 1440 分钟，再判断两个区间是否重叠。这个判断要嵌在批量保存接口里，对每个员工的每条新排班与库里已有排班遍历比较，发现有重叠就整批回滚，并提示是哪一天冲突。
5.2 权限边界：部门主管接口必须带数据范围参数
酒店员工管理系统的排班权限通常按部门隔离，客房部主管不应该看到餐饮部的排班。后端查询 SQL 里，除了 deptId 还要加一个当前登录人可管理的部门校验：
AND s.dept_id = #{deptId} AND EXISTS ( SELECT 1 FROM dept_manager dm WHERE dm.emp_no = #{loginEmpNo} AND dm.dept_id = s.dept_id )如果这两个条件只保留一个，就会出现接口能查到数据但前端不展示的情况，数据仍然泄露。正确的做法是后端直接从登录会话里取 emp_no，而不是信任前端传的管理员标识，并且对 dept_manager 表建 (emp_no, dept_id) 联合唯一键，防止一个主管被重复授权。
5.3 离职交接：软删除与历史排班保留
处理离职员工时，不要物理删除 emp 记录，否则历史排班表通过 emp_no 关联不到姓名，考勤汇总也会丢失人员信息。常见做法是只更新 status 字段，并把排班查询统一带上 status = 1 条件，这样员工一离职立刻从排班界面消失，但历史数据完整保留：
UPDATE emp SET status = 0, leave_date = CURRENT_DATE WHERE emp_no = #{empNo}离职前未履行的未来排班，需要单独清理 schedule 表中该员工 shift_date 大于当天的记录，否则月底统计时会把离职后的排班也算进去。这个清理动作放在同一个事务里执行，确保离职状态和未来排班的删除要么一起成功，要么一起失败。权限配置里还要把该员工的登录账号禁用，具体可以在登录查询 emp 表时增加 status 校验，status 为 0 直接拒绝登录，这样即使手机号没变也无法继续使用系统。
本文还有配套的精品资源，点击获取
