洗浴中心管理系统课程设计拆解：B/S架构与数据库设计实战

简介《洗浴中心管理系统》课程设计说明书是一份面向软件工程专业学生及Web系统开发者的完整设计文档内容详实、结构规范。文档基于实际业务需求详细阐述了一个采用Java、Oracle数据库和Apache服务器实现、基于B/S架构的洗浴中心管理系统的设计过程。内容覆盖部门管理、员工管理、消费管理、会员管理、服务项目管理、商品管理、结账业务及统计管理等核心功能模块并给出了技术架构、设计原则与关键实现说明。包内含1个doc格式文档压缩包大小515KB结构完整包含摘要、目录、系统分析与总体设计等章节适合作为课程设计说明书撰写参考或系统开发初期的需求分析蓝本。目前已有106人学习浏览适合正在筹备相关课题或希望了解传统C/S向B/S迁移思路的读者参考。1. 洗浴中心管理系统一份 22 页课程设计能拆出多少能直接用的东西这份《洗浴中心管理系统.doc》我拿到手第一反应是2013 年的课程设计说明书还是文档格式能有多少货拆完发现判断下早了。它本质是一份完整的 B/S 架构收费系统设计蓝图——从技术选型、11 张表的数据结构、模块划分到前后台权限边界全部写了唯一缺的是把设计落到代码的那一步。对正在做软件工程课程设计、毕业设计的人或者想快速搭一套门店收银管理系统原型的开发者来说这份文档的价值在于你不需要从零想业务建模直接照着它的模块和表结构还原能省下大量需求分析时间。下面我会把它拆成三层架构怎么选、数据库怎么建、业务闭环怎么走最后给出复现时要避开的坑。2. B/S 架构与技术选型为什么是 JAVA ORACLE Apache 而不是 C/S2.1 从浴室收费场景看 C/S 与 B/S 的取舍文档里说得很直白市面上的美萍这类浴室收费系统数据存在独立电脑上突然断电可能丢数据所谓网络版也局限在单一局域网内老板离开店面就看不到经营情况。这个痛点决定了选型方向——必须用 B/S。B/S 架构下数据库集中在服务器端客户端只是浏览器断电丢的是客户端本地缓存而不是服务器数据只要服务器有公网地址或者内网穿透经营者在任何地方打开浏览器就能看营业额。这是 C/S 系统做不到的。这个判断到今天依然成立。我做门店类管理系统时只要客户提出我人不在店里也要看数据这个需求基本直接排除 C/S。文档里选的 B/S 不是跟风是业务场景推着技术走。值得注意的一点是文档把断电不丢数据归功于 B/S严格说这是数据库集中管理的功劳但结论没错——B/S 强制把数据收敛到服务端客观上规避了本地存储的丢数据风险。2.2 JAVA ORACLE Apache选型理由与真实代价文档列了 JAVA 的六个优势简单、面向对象、平台无关、解释型、多线程、安全。这些是教科书说法放到 2013 年的课程设计选型里真正起决定作用的三点其实是跨平台JVM 屏蔽操作系统差异、类库丰富写 Web 层不用从零造轮子、当时高校课程体系里 Java Web 是主流教学内容。文档里选了 ORACLE 作为数据库理由是处理速度快、安全级别高、支持故障恢复和负载均衡。ORACLE 这些能力是真的但对一个洗浴中心管理系统来说明显过重——一个门店级应用数据量撑死百万行用 ORACLE 属于典型的课程设计要求用什么就用什么。真实复现时我一般会建议保留 JAVA B/S 的架构结论数据库换成 MySQL理由放在最后一章展开。但如果你是为了还原课程设计原貌ORACLE 也不是不行只是要忍受安装体积大、内存占用高、驱动配置繁琐这三个老问题。Apache 作为 Web 服务器在文档里的角色是 HTTP 服务层真正处理 Java 业务逻辑的是 Tomcat 容器文档没写清楚这一点实际部署时两者是搭配使用的——Apache 负责静态资源和请求转发Tomcat 跑 JSP 和业务代码。2.3 环境搭建从文档描述到可运行的最小组合文档 1.2 节讲环境搭建只说了装 Apache 和 ORACLE没提 JDK 和 Tomcat这是课程设计说明书常见的省略——默认读者已经配好 Java 开发环境。实际还原这套系统需要的最小环境组合是JDK 1.6 及以上 Tomcat 6/7 ORACLE 10g/11g或 MySQL 5.x。第一步不是写代码而是先把环境通起来。我习惯先做一个连接测试页面确认 JDBC 驱动能连上数据库再开始写业务代码// DbConn.java - 数据库连接测试类 import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.Statement; public class DbConn { public static void main(String[] args) { // 驱动类ORACLE 用 oracle.jdbc.driver.OracleDriver // MySQL 用 com.mysql.jdbc.Driver这里以 ORACLE 为例 String driver oracle.jdbc.driver.OracleDriver; // 连接串//主机IP:端口/服务名1521 是 ORACLE 默认端口 String url jdbc:oracle:thin://localhost:1521/ORCL; String user bath; String password bath123; try { Class.forName(driver); Connection conn DriverManager.getConnection(url, user, password); Statement stmt conn.createStatement(); // 查系统表验证连接dual 是 ORACLE 的虚表 ResultSet rs stmt.executeQuery(SELECT 1 FROM dual); while (rs.next()) { System.out.println(Database connect OK: rs.getInt(1)); } rs.close(); stmt.close(); conn.close(); } catch (Exception e) { e.printStackTrace(); } } }这段代码的逻辑很直白先用Class.forName加载 JDBC 驱动然后通过DriverManager.getConnection建立连接最后查一条dual虚表验证连通性。四个参数里最容易出错的是 URL——ORACLE 的 thin 模式连接串格式是jdbc:oracle:thin://主机:端口/服务名如果写错成jdbc:oracle:thin:主机:端口:SID这种旧格式高版本 ORACLE 会报连接失败。跑通这个类只说明 JDBC 能连库离系统能跑还差一步把连接参数抽到配置文件里。课程设计可以偷懒硬编码但你要真想把这套系统跑起来连接信息放db.properties里是基本习惯。文档在数据库章节直接跳到建库跳过了这一层复现时自己补上即可。3. 数据库设计还原bath 库 11 张表怎么支撑手牌、会员和结账3.1 表清单与业务映射文档 3.2 节列出了一张完整的表清单共 11 张表这是这份说明书里含金量最高的部分。很多课程设计写到数据库就一两张用户表糊弄过去这份把业务对象拆得很清楚——操作员、操作记录、会员、服务项目、商品、手牌、服务人员、选择服务、选择商品、部门、账单每个业务实体都有对应的表。把这些表和业务对应起来看表名业务实体核心职责operators操作员前台收银员与系统管理员账号opereсords操作记录谁在什么时间做了什么操作审计用vips会员会员卡基础信息与余额projects服务项目搓澡、按摩等项目的名称与单价goods商品饮料、毛巾等销售商品signs手牌手牌号与空闲/占用状态waiters服务人员技师、服务员信息selectfws选择服务客人与服务项目的关联记录selectgoods选择商品客人与商品的关联记录departments部门组织结构bills账单一次消费的结算汇总这套表设计有个值得学习的点它把选择服务和选择商品单独拆表而不是在账单表里冗余存明细。这样设计的直接好处是一个手牌对应多个服务、多个商品中间表的粒度足够细结账时从selectfws和selectgoods按手牌汇总金额再写入bills数据流是单向清晰的。缺点是查询要 join 多张表但以这个数据量级完全不是问题。文档没有给出每张表的字段明细下面按业务和表名还原出基本结构。3.2 核心表字段设计手牌表与选择服务表的联动手牌表是整个浴室管理系统的核心状态表它记录每个手牌当前处于什么状态。还原出来的字段结构大致是这样的-- signs 手牌表 CREATE TABLE signs ( sign_id NUMBER(10) PRIMARY KEY, -- 手牌编号例如 001 sign_state NUMBER(1) DEFAULT 0, -- 0空闲 1占用 2待结账 open_time DATE, -- 开牌时间 close_time DATE, -- 结账销牌时间 operator_id NUMBER(10) -- 开牌操作员关联 operators 表 );字段里sign_state是业务的关键——文档 5.1.1 节说手牌在界面里显示为黑白两种状态图片黑代表空置白代表占用状态切换的本质就是改这个字段。open_time和close_time不是为了展示而是为了统计浴室按小时计费的话营业日报里的手牌使用时长直接从这两个字段算。operator_id在排班冲突时可以追溯到人。选服务表和商品表是消费记录的明细层设计上有两个选择一是像文档这样按业务类型拆两张表二是在一张消费明细表里加类型字段区分。文档拆两张表的方案有个隐性好处——服务项目通常按次计费商品按件数计费两表可以有不同的数量字段语义不会混在一起。联动的完整链路是开牌 → 选服务/选商品 → 各表插入消费记录 → 结账时汇总生成账单 → 手牌状态置回空闲中间任何一步断了手牌状态和消费明细就对不上。3.3 从表间关系到数据一致性边界11 张表的关系可以分成三层第一层是人员组织departments挂operators操作员归属部门第二层是客户消费signs作为主索引通过selectfws和selectgoods关联projects和goods第三层是结算审计bills汇总消费operecords记录所有敏感操作。文档里没提外键约束这是课程设计常见的坑——建表时为了图省事不加外键程序里靠代码保证关联一旦某条删除逻辑写漏就会出现孤儿数据。我复现这套表结构时会坚持加物理外键至少在手牌表和消费明细表之间加。额外的好处是删手牌时如果还有未结账的消费记录数据库会直接报错这比业务代码里if判断可靠得多。代价是删除数据时必须先删明细再删主表操作顺序要反过来这正好倒逼代码逻辑更严谨——先结账清明细再回收手牌顺序天然就是对的。4. 业务闭环拆解开手牌到结账的完整链路与权限边界4.1 模块清单与功能职责划分文档第五章按五个模块详细描述了功能加上第二章提到的部门管理和结账统计完整的模块地图是这样的模块操作入口关键功能手牌管理前台查看手牌列表、开手牌、状态图片切换商品管理前台添加、修改、查询商品前台只读列表会员管理前台会员卡列表、卡类型管理、开卡、注销、查余额员工管理后台工作人员列表、添加入职、按工号修改信息服务项目管理后台项目列表、添加服务项目、修改删除部门管理后台部门增删改查结账与统计前台后台账单汇总、营业收入统计注意表里的权限逻辑商品管理和会员管理都出现在前台入口但前台对商品通常只有查看和选择的权限真正的增删改在管理员的职责范围内。文档 2.2 节明确写了非管理员无法进入后台前台管理员拥有操作权限后台管理员拥有所有权限这句话是整个权限设计的纲领。4.2 从开手牌到结账一次完整消费的数据流把模块串起来看业务闭环会更清晰。一个客人进店消费的完整链路是前台操作员进入手牌管理界面看到一个空闲手牌点击启用开牌——这个动作在数据库里同时发生三件事signs表插入一条新记录且状态置为 1占用operecords表写入开牌操作记录手牌列表界面上对应格子的状态图片从黑变白。客人消费过程中每点一个服务项目selectfws插入一条记录每买一件商品selectgoods插入一条记录。客人走时结账系统做的事是把selectfws和selectgoods里该手牌对应的所有记录汇总算出总金额写入bills同时把signs状态改回 0。这个流程看起来简单但每个环节都有一个容易被新手忽略的细节。开牌时如果只插signs不写operecords出了纠纷查不到是谁开的牌结账时如果只汇总金额不改signs状态下一个客人会拿到一张被占用的手牌中间任何环节数据库事务没包住断电瞬间可能出现手牌占用但无消费记录的脏数据。文档没提事务控制但实际代码里结账这个动作必须加事务——要么全部成功要么全部回滚。4.3 前后台界面设计权限在页面层还是逻辑层文档第四章把管理界面分为前台管理界面和后台管理界面登录接口是同一个login.jsp登录时记录用户权限后续每个操作都做权限校验。这个设计思路是对的但有一个课程设计里普遍存在的问题权限校验通常只做了页面隐藏——菜单里不显示没权限的入口却忽略了 URL 直访的问题。前台操作员如果直接输入后台管理页面的 URL后端没拦截的话照样能打开页面。这个问题的根源在于权限控制放错了层。页面隐藏是用户体验层的措施真正的权限校验必须放在服务端逻辑里。我见过太多课程设计系统,登录页写得挺像样点进去发现直接改 URL 就能越权。复现这套系统时要么用 Filter 拦截器统一校验 session 里的用户角色要么在每个后台操作的方法入口加角色判断二选一绝不能只靠前端藏菜单。文档里登录同时记录权限系统控制操作权限这句话就是后端校验的意思但要在实现时真正落地。5. 复现避坑指南从文档还原成可运行系统的 5 个常见翻车点5.1 数据库层面的坑坑 1ORACLE 环境装不上或者装上跑不动现象按文档选型装了 ORACLE 11g安装耗时两小时启动后电脑明显卡顿随后连接报错ORA-12541: TNS:no listener。 原因ORACLE 对内存要求高默认配置在普通开发机上会占用大量资源TNS:no listener一般是监听服务没启动常见于装完没执行lsnrctl start或者主机名解析异常。 解决学习阶段直接用 MySQL 5.7 替代驱动和连接串改两个地方即可表结构和业务代码不需要动如果必须用 ORACLE安装后手动启动监听服务并把 SGA 内存调小到 256M 以内。坑 2日期字段格式导致报表统计出错现象open_time字段存进去的数据带时分秒按天分组统计时发现当天数据不全或者把前一天的记录也算进来了。 原因在代码里用new Date()直接拼 SQL日期被隐式转换不同时区的数据库会话对DATE类型的处理有差异更隐蔽的是 ORACLE 的DATE本身就带时分秒按天分组必须截断。 解决统一用TO_CHAR(open_time,YYYY-MM-DD)做分组字段入库前也把时间格式规范成yyyy-MM-dd HH:mm:ss不要在 SQL 里依赖数据库默认格式。这个坑在 MySQL 里相对轻但 SQL 写法注意了能省很多后面排错的功夫。5.2 部署与运行层面的坑坑 3JSP 页面中文乱码手牌号和商品名全是问号现象界面上的中文全部显示为????但数据库里用 SQL 查询中文正常。 原因JSP 页面编码和 HTTP 请求编码不一致。页面文件是 UTF-8但 Tomcat 默认的请求编码是 ISO-8859-1表单提交的中文到了后台就成了乱码再写回数据库就彻底坏了。 解决所有 JSP 页面头加% page contentTypetext/html; charsetUTF-8 %同时在 Tomcat 的server.xml里给 Connector 加URIEncodingUTF-8参数。这属于写 Java Web 的血泪经验每次环境一换就重犯一次建议直接在项目里放一个统一的编码 Filter。坑 4Apache 和 Tomcat 端口冲突服务起不来现象启动 Tomcat 后访问页面报Connection refused查看日志发现Port 8080 was already in use或者 Apache 和 Tomcat 同时装好后只有一个能访问。 原因Apache 默认占用 80 端口Tomcat 默认占用 8080本身不冲突但很多教程里把 Apache 配成转发到 Tomcat 的 AJP 端口如果httpd.conf里mod_proxy_ajp配置写错或者 Tomcat 的server.xml里 AJP 端口被别的进程占了就会互相抢。 解决Apache 配转发时确认proxy_ajp_module已启用Tomcat 的 AJP 端口默认 8009没被占用更省事的方案是直接用 Tomcat 单跑去掉 Apache 一层。文档里写用 Apache但对课程设计来说纯 Tomcat 也能达到同样的演示效果。5.3 业务逻辑层的坑坑 5并发开牌导致手牌号重复两个客人拿同一张牌现象两个前台同时点击开牌系统分配了同一个手牌号客人进场后撞牌。 原因开牌逻辑是先查询最大手牌号再 1两步之间没有锁。并发请求同时读到同一个最大值各自 1 后插入必然重复。这是典型的查询后再插入并发问题。 解决手牌号字段建唯一索引这是数据库层面的兜底更好的做法是手牌号由数据库序列SEQUENCE或自增主键生成程序里完全不管编号生成。如果你硬要程序生成编号给分配编号的方法加synchronized也只是单机有效分布式的场景就没用了——不过以洗浴中心的并发量唯一索引加自增序列已经足够。6. 进阶改造把课程设计升级成能实际用的收银系统的三个技巧6.1 数据库迁移从 ORACLE 到 MySQL 的具体改法文档选 ORACLE 是课程要求实际做门店收银系统不可能这么重。迁移的核心就三处驱动类名、连接串、SQL 方言里的函数差异。驱动和连接串在 2.3 节已经给了对照这里说 SQL 差异。ORACLE 的分页用ROWNUMMySQL 用LIMITORACLE 的字符串拼接用||MySQL 用CONCAT()日期函数更是完全不同。改表结构时把NUMBER(10)换成BIGINTDATE换成DATETIME别的字段类型基本能直接对应。迁移完记得做一次全量数据校验重点是账单金额写个 SQL 把selectfws和selectgoods按手牌汇总和bills表逐笔比对。这个动作看似多此一举实际上能一次性发现迁移过程中的精度丢失问题——比如 ORACLE 的NUMBER(10,2)在 MySQL 里如果建成了INT小数点后的金额全被截掉账就对不上。6.2 统计报表 SQL从手工查库到自动经营日报结账统计模块是文档里写了但没展开的部分。经营日报的核心是一张按天聚合的报表统计手牌使用数、服务项目收入、商品销售收入和会员充值额。下面这个 SQL 是把服务收入按天汇总的核心部分-- 服务项目收入日报按日期分组统计每个项目的收入 SELECT TO_CHAR(f.svc_time, YYYY-MM-DD) AS biz_date, -- 消费日期 p.project_name AS project_name, -- 服务项目名称 COUNT(f.svc_id) AS order_count, -- 服务次数 SUM(p.price) AS total_amount -- 项目收入合计 FROM selectfws f JOIN projects p ON f.project_id p.project_id WHERE f.svc_time SYSDATE - 30 -- 最近30天 GROUP BY TO_CHAR(f.svc_time, YYYY-MM-DD), p.project_name ORDER BY biz_date DESC, total_amount DESC;这段 SQL 的逻辑是通过selectfws和projects的关联把每次服务消费换算成金额后按天和项目分组统计。GROUP BY里必须用TO_CHAR处理后的日期而不是原始时间列否则同一客户在同一天多次消费会被当成多个分组。报表统计的坑大多集中在分组字段的粒度上——按天、按小时、按项目每组一个粒度SQL 就要重写一次。6.3 手牌状态机从两态到三态的改进方案文档里的手牌只有空闲和占用两个状态实际运营中这个模型有漏洞客人已经消费完在收银台排队结账这时候手牌算占用还是空闲算占用统计手牌使用时长时会把排队时间算进去算空闲另一个客人可能误开这张牌。实际做法是加一个待结账状态状态流转从两态变成三态空闲 → 占用 → 待结账 → 空闲。这个改动在数据库层面只是sign_state多加一个值但带来的收益是实打实的——管理者能准确统计客人离场但未结账的时间窗口这在高峰期是衡量收银效率的关键指标。我后来做任何带状态流转的系统都习惯先把状态列出来画一张流转图再写代码这个习惯就是从那套洗浴系统的教训里来的——最开始直接按两态写上线第三天就发现结账排队时手牌状态对不上只好加班改表。从那以后我每次设计状态字段都强制自己走一遍完整生命周期从哪开始、到哪结束、中间有没有中间态这个流程再急也不跳。希望帮到你——如果你正在还原这套系统先把状态机想清楚再动手你的排错时间至少省一半。本文还有配套的精品资源点击获取