数据库课设实战：小型超市管理系统源码与设计详解

简介：一套面向数据库课程设计、毕业设计及实训项目的小型超市管理系统完整工程，基于Java与Vue技术栈实现，涵盖前端页面、后端业务逻辑、数据库脚本与配置说明。项目经严格测试运行正常，答辩评审平均分达96分，适合需要快速复现、借鉴设计思路或进行二次开发的学生使用。资源包共369个文件，压缩包大小68.62MB，包含Java源码、Vue组件、JavaScript脚本、SVG图标、CSS样式及SQL数据库文件等，目录结构清晰，可按模块分层查阅。目前已有50人学习下载。内容提供完整源码、工程文件与说明文档，覆盖从环境准备到功能演示的完整链路。既可直接运行作为期末/课程设计成果，也可基于现有代码扩展会员管理、库存预警等功能；配套设计报告可作为课程设计文档的写作范本，帮助理解系统设计与实现细节。

1. 数据库课设小型超市管理系统：能直接跑通的源码工程长什么样

如果你是带着“数据库课设该做什么题目”或者“超市系统怎么把表设计得能答辩”这两个问题进来的，这份工程资源值得花十分钟看完。它的内核是一套完整的小型超市管理系统：商品档案、进货入库、库存流水、收银结算、会员积分这些业务全都有，数据库这边涉及多表关联、事务处理、视图查询，前端也不是那种只摆几个文本框的静态页面，而是带完整操作流程的可视化界面。最让我意外的是工程里还带了一套流程视图相关的前端样式资源，意味着系统里嵌了可交互的流程节点展示，这在课设项目里属于能拉高答辩印象分的设计。源码、工程文件、说明文档是一整套，适合数据库课程设计、期末大作业、毕设起步复刻，也适合想练全栈功底的开发者在上面接着加功能。

2. 数据库设计先行：从ER模型到能落地的核心业务表

2.1 为什么超市管理系统适合做数据库课设

选数据库课设题目是有思路的，太简单撑不起篇幅，太复杂又容易脱离课程范围。超市管理系统处于一个很合适的位置：它的每一步业务动作都会产生数据变化，比如进货会更新商品库存、收银会同时写销售单和销售明细、会员结算会联动积分增减。你在设计阶段能覆盖实体关系建模、外键约束、级联操作、事务回滚；在进阶阶段还能做存储过程、触发器、视图统计。数据量不需要太大，但每个表都有明确的业务含义，答辩时老师问“这张表为什么放在这里”，你能讲出实际业务依据，而不是对着空表硬编。

这个项目的表结构把实体拆得比较细：商品、商品分类、供应商、进货单、进货明细、销售单、销售明细、会员、积分流水、库存流水、用户（操作员）、权限角色，加起来十六张左右。这个数量做课设不多不少，刚好能让ER图有层次，又不至于把精力耗在冗余表上。

2.2 核心表结构与字段设计：冗余换来查询性能

商品表和销售相关表是整个系统的地基，字段设计直接决定后面写业务代码的难度。先看商品表：

CREATE TABLE goods ( id INT AUTO_INCREMENT PRIMARY KEY COMMENT '商品ID', barcode VARCHAR(32) NOT NULL COMMENT '条码', name VARCHAR(64) NOT NULL COMMENT '商品名称', category_id INT NOT NULL COMMENT '所属分类', sale_price DECIMAL(10,2) NOT NULL COMMENT '销售单价', purchase_price DECIMAL(10,2) NOT NULL COMMENT '进货单价', stock INT NOT NULL DEFAULT 0 COMMENT '当前库存', status TINYINT NOT NULL DEFAULT 1 COMMENT '1上架 0下架', UNIQUE KEY uk_barcode (barcode), KEY idx_category (category_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品基本信息表';

条码字段加了唯一索引，因为超市场景里扫码枪输入的就是条码，查询频率极高；category_id建普通索引用于商品分类筛选；库存直接冗余在商品表上，而不是每次都用SUM去流水表里算。这种冗余是有代价的，后续所有库存变更必须在事务里同步更新该字段，但换来的好处是收银台查询商品时一次IO就能拿到价格和库存。

销售单主表和销售明细表的拆分是经典的主从结构：

CREATE TABLE sale_order ( id INT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL COMMENT '订单号', member_id INT DEFAULT NULL COMMENT '会员ID，无会员为NULL', total_amount DECIMAL(10,2) NOT NULL COMMENT '原价合计', discount_amount DECIMAL(10,2) NOT NULL DEFAULT 0 COMMENT '优惠金额', pay_amount DECIMAL(10,2) NOT NULL COMMENT '实付金额', create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '下单时间', UNIQUE KEY uk_order_no (order_no), KEY idx_member (member_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='销售单主表'; CREATE TABLE sale_item ( id INT AUTO_INCREMENT PRIMARY KEY, order_id INT NOT NULL COMMENT '所属订单', goods_id INT NOT NULL COMMENT '商品ID', goods_name VARCHAR(64) NOT NULL COMMENT '成交时商品名快照', price DECIMAL(10,2) NOT NULL COMMENT '成交单价快照', qty INT NOT NULL COMMENT '数量', sub_total DECIMAL(10,2) NOT NULL COMMENT '小计', KEY idx_order (order_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='销售明细表';

细节在明细表里冗余了goods_name和price快照字段。这个设计很重要：商品改价或改名后，历史订单依然能还原当时的成交信息，这是业务系统的基本要求，也是答辩时能说出口的设计亮点。total_amount、discount_amount、pay_amount三个字段分开记录，方便后面做日销售报表时按不同口径统计。

2.3 外键约束与索引设计：别让MySQL帮你做选择

很多课设代码建表时不用外键，全凭Java代码控制关联，理由是“外键影响性能”。这话在高并发互联网场景下有一定道理，但课设项目是低并发教务环境，外键不仅无害，反而是加分项。

我的建议是物理外键用在关键引用上，不滥用：

ALTER TABLE sale_item ADD CONSTRAINT fk_saleitem_order FOREIGN KEY (order_id) REFERENCES sale_order(id) ON DELETE CASCADE, ADD CONSTRAINT fk_saleitem_goods FOREIGN KEY (goods_id) REFERENCES goods(id); ALTER TABLE sale_order ADD CONSTRAINT fk_saleorder_member FOREIGN KEY (member_id) REFERENCES member(id) ON DELETE SET NULL;

ON DELETE CASCADE用在了订单和订单明细之间——删主单自动清明细，符合业务直觉；会员ID这里用了SET NULL，会员被注销后订单记录保留，只是关联置空，这样销售历史不会因为会员删除而丢失。这两条规则设计好之后，程序里就要按这些语义来写，不要绕过约束去手动删明细。

2.4 初始化数据脚本：造数据也要有业务合理性

项目工程里通常带一份数据初始化脚本，这份脚本的质量会直接影响你第一次启动项目的体验。我拿到这个资源后先看了它的数据脚本，商品数据覆盖了食品、日用品、饮料几个分类，价格和成本之间保持着合理毛利空间，库存数也模拟了实际超市的存量水平。会员表和积分流水有对应的历史累积关系，这是很多人造数据时容易忽略的——积分余额应该等于该会员所有积分流水之和，否则一运行报表聚合就露馅。

3. 后端业务实现：库存扣减与销售结算的事务边界

3.1 技术栈选型：Spring Boot + MyBatis + MySQL是课设的稳妥组合

这个工程的后端采用Spring Boot + MyBatis + MySQL的组合，前端是浏览器管理的后台页面，登录后按角色进入不同菜单。这套选型在课设里已经非常成熟：Spring Boot负责接口和事务控制，MyBatis把SQL写在XML里方便你对着数据库调优，MySQL做数据存储。三层结构清晰，老师一眼就能看出你理解了分层思想。

我一般提醒别人，课设框架不要用太冷门的东西。用主流框架的好处是出了问题搜索解决方案容易，答辩时老师也熟悉这套技术栈，你讲代码逻辑时不需要额外解释框架本身。

3.2 销售下单的Service层代码：事务注解下的四步操作

收银结算是整个系统最核心的业务，也是最能体现事务控制能力的场景。下面这段代码就是这个场景的业务逻辑，精简了参数校验和日志部分：

@Transactional(rollbackFor = Exception.class) public PayResult checkout(CheckoutRequest req) { // 1. 生成销售单主表记录，状态为“未结算” SaleOrder order = new SaleOrder(); order.setOrderNo(generateOrderNo()); order.setMemberId(req.getMemberId()); saleOrderMapper.insert(order); BigDecimal total = BigDecimal.ZERO; BigDecimal discount = BigDecimal.ZERO; // 2. 遍历购物车明细，逐条写入销售明细并扣减库存 for (SaleItemDTO item : req.getItems()) { Goods goods = goodsMapper.selectByIdForUpdate(item.getGoodsId()); if (goods == null || goods.getStatus() != 1) { throw new BizException("商品不存在或已下架，请刷新购物车"); } BigDecimal subtotal = goods.getSalePrice() .multiply(BigDecimal.valueOf(item.getQty())); total = total.add(subtotal); SaleItem saleItem = new SaleItem(); saleItem.setOrderId(order.getId()); saleItem.setGoodsId(goods.getId()); saleItem.setGoodsName(goods.getName()); saleItem.setPrice(goods.getSalePrice()); saleItem.setQty(item.getQty()); saleItem.setSubTotal(subtotal); saleItemMapper.insert(saleItem); int rows = goodsMapper.deductStock(item.getGoodsId(), item.getQty()); if (rows == 0) { throw new BizException("商品[" + goods.getName() + "]库存不足，当前可用库存为" + goods.getStock()); } } // 3. 按会员折扣计算实付金额 BigDecimal pay = calcPayAmount(total, req.getMemberId()); discount = total.subtract(pay); // 4. 回写销售单金额 saleOrderMapper.updateAmount(order.getId(), total, discount, pay); // 5. 记录积分流水（会员存在时） if (req.getMemberId() != null) { memberService.addPoints(req.getMemberId(), pay); } return PayResult.success(order.getOrderNo(), pay); }

先说明事务边界：@Transactional把从生成订单到扣库存到回写金额的全过程锁在同一个数据库事务里，任何一步抛异常，前面的所有写操作全部回滚。这在销售场景里是必须的，你不能出现“订单生成了但库存没扣”这种脏数据。

selectByIdForUpdate是关键——它加了行级悲观锁。两个收银台同时结算同一件商品时，第二个请求会等待第一个事务提交后再读取，避免超卖。deductStock的SQL是条件更新，只有库存充足时才真正扣减：

UPDATE goods SET stock = stock - #{qty} WHERE id = #{goodsId} AND stock >= #{qty}

MyBatis的执行结果rows等于1表示更新成功，等于0表示库存不足。这里的判断是绝不能用“先查库存再手动比较”替代的，那会存在时间窗口，并发场景一定会翻车。

3.3 库存扣减的并发坑：悲观锁和乐观锁怎么选

上面代码用的是悲观锁方案，selectForUpdate把数据行锁住直到事务结束。优点是实现简单、逻辑直白，缺点是并发吞吐低。超市收银场景的并发量很低，课设演示也只有一个客户端操作，悲观锁完全够用。

如果你的扩展方向是电商秒杀那种高并发场景，才需要换成乐观锁：不在SELECT阶段加锁，而是在UPDATE时带上版本号条件：

UPDATE goods SET stock = stock - #{qty}, version = version + 1 WHERE id = #{goodsId} AND version = #{oldVersion}

因为这份资源定位是课设超市系统，我没有在工程里看到引入Redis或消息队列的必要性——加了反而增加部署复杂度。如果你基于这个项目扩展，记住这条边界：悲观锁解决低并发下的强一致性，乐观锁解决高并发下的吞吐问题，选型先看业务量级。

3.4 金额计算与会员积分：别用Double计算钱

代码里所有金额都用BigDecimal，这是从第一版就定下的规矩。Double和Float在计算机里是二进制浮点，做加减乘除会有精度误差，比如0.1 + 0.2得到0.30000000000000004，这在金额场景是不可接受的。DECIMAL(10,2)在数据库层面也限定了精度，Java代码里用BigDecimal的字符串构造方法来运算。

积分计算按实付金额算：每消费1元积1分，不足1元舍去。这听起来简单，但写实现时要注意结算顺序：先算折扣、再算实付、最后用实付金额产生积分流水，积分流水写入成功后会员表积分累计值同步更新。这个顺序反过来就会造成折扣金额也参与积分，被懂行的答辩老师问住。

4. 前端页面与流程视图：让答辩老师看到完整系统而不是登录页

4.1 页面规划：七个功能模块怎么串起来

这个工程的前端是浏览器管理后台，页面模块划分如下：

每个模块单独拆页面文件维护，命名清晰，方便你在上面改样式或加组件。这个工程前端目录里有index.css、app.css这种全局样式文件，也有专门的控制台样式文件，说明页面早就过了“能用就行”的阶段，视觉上是完整打磨过的。

4.2 bpmn-embedded.css和diagram-js.css：工程里的流程视图从哪里来

我看到工程文件列表里出现了bpmn-embedded.css、diagram-js.css、bpmn.css这几个文件时愣了一下，因为这些是BPMN流程建模前端库的资源文件。对应关系是：diagram-js提供画布和节点拖拽基础能力，bpmn.css负责BPMN图形元素默认样式，bpmn-embedded.css用于把流程图嵌入普通页面的场景。这说明这套超市系统里除了增删改查之外，还嵌入了一个可视化的流程图页面——这类页面在实际项目里通常用来展示进货审批流程、退货流程，或者系统整体业务流转路径。

答辩演示时，这个页面是很好的讲解切入点。不是每个课设都有流程可视化，打开页面让老师看到进货申请从提交到主管审批到入库确认的节点流转，比嘴上描述“我的系统有权限控制”具象得多。你可以在工程里搜索bpmn这个关键词，找到加载了这些样式文件的HTML页面，改成自己的业务场景文案即可。

4.3 收银台页面的交互逻辑：先计算展示后提交落库

收银台的交互逻辑体现了前后端分离的边界意识。前端不替后端做任何金额权威计算，但要把已知数据算出来展示给操作员确认：

function calculateCart(cartItems, member) { let total = 0; cartItems.forEach(item => { // 后端返回的单价已经是Decimal，前端只做展示计算 item.subtotal = roundMoney(item.price * item.qty); total += item.subtotal; }); let discount = 0; let pay = total; if (member && member.discountRate) { // 实际折扣以后端结算接口返回为准，这里仅用于界面预览 discount = roundMoney(total * (1 - member.discountRate)); pay = roundMoney(total - discount); } renderSummary({ total, discount, pay }); return { total, discount, pay }; }

roundMoney是封装好的两位小数舍入函数，前端不依赖它做最终金额。操作员点了结算按钮之后，前端把购物车明细和会员ID发给后端，后端返回的orderNo和实付金额才是系统最终认定的结果。这种写法保证了就算有人改前端代码绕过页面直接调接口，后端事务依然能拦住非法请求。

5. 避坑与排查：部署运行和答辩演示的五个典型问题

5.1 现象：SQL脚本在Navicat里能跑通，通过Java连接就执行失败

原因：本地MySQL的字符集或时区配置与初始化脚本不一致，出现中文乱码或日期时间差8小时的诡异现象。工程说明文件的部署步骤通常要求utf8mb4字符集，但有些机器MySQL默认还是utf8mb3或者latin1。

解决：连接串上显式声明参数：

jdbc:mysql://localhost:3306/supermarket?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

顺便检查MySQL的my.ini里default-character-set是否设置为utf8mb4。自从我习惯在连接串上把时区写死之后，这种问题就再没出现过。

5.2 现象：商品库存变成了负数，收银还能正常出单

原因：扣库存前没有校验库存量，或者校验后到更新之间隔了查询操作，存在并发时间窗口。上一版代码先查出商品判断库存大于0再执行update，结果两个请求同时通过校验，把库存压成了负数。

解决：用条件更新解决，就是前面说的UPDATE goods SET stock = stock - #{qty} WHERE id = #{goodsId} AND stock >= #{qty}。这一步是底线，任何环境下都不能省。

5.3 现象：页面引用了bpmn-embedded.css后整页样式错乱

原因：BPMN流程库的样式是全局样式，里面设置了部分类名的通用规则，比如.djs-container下的一些元素覆盖逻辑，直接引入没做样式隔离会和现有组件样式互相覆盖。

解决：把流程图页面拆成独立入口，iframe方式嵌入主页面，样式互不干扰。你要复用工程里的流程图，不要直接在原有管理页面里追加外链，单独开一个页面展示。

5.4 现象：启动项目后首页能开，但一点登录就报数据库连接失败

原因：数据库服务没启动，或账号密码与application.yml配置不一致。这个听着低级，但发生频率极高。我排查过好几个类似情况，最终都是本机装了多个MySQL版本，服务启动的是老版本端口。

解决：先看控制台完整异常，连接被拒先查MySQL服务状态，通信链路断了再查端口和账号权限。不要一上来就怀疑代码，数据库连接失败九成是环境问题。

5.5 现象：运行项目时的页面展示和工程截图对不上

原因：拿到资源后电脑分辨率和浏览器缩放比例不同，或者项目用了本机绝对路径加载图片资源，导致部分模块显示空白。

解决：按说明文件要求的浏览器版本打开，推荐Chrome按100%缩放。项目里静态资源若是用相对路径引入的就没这个问题，如果页面引用了外链图片，替换成工程里自带资源即可。

6. 答辩演示的黄金路径与数据校验技巧

这套系统演示时不要按菜单顺序平铺，按业务闭环走。我的习惯路径是：登录页用管理员账号进入，先打开商品管理翻两页展示分页和筛选；然后进进货模块做一次进货单录入，演示供应商选择和入库提交，顺便展示库存流水；接下来开收银台，用扫码搜索把刚入库的商品加进购物车，输入会员ID触发折扣，点结算后展示订单号；最后切到统计报表，当日销售数据图里能看到刚才那笔订单。这一套下来就是完整的采购到销售闭环，全程不到十分钟，比挨个页面念菜单有说服力得多。

演示前一定要准备一个库存不足的商品做校验展示。把某个商品库存改成1，收银台加入两个，结算时后端返回库存不足的报错提示，窗口弹出来那一刻，比任何语言都能说明系统做了事务和校验。同样，会员结算时可以故意选一张积分不足的卡做余额校验演示。

数据校验技巧上还有一点：演示前重置一份干净的初始化数据，不要用自己反复测试产生的脏数据。我每次答辩前都强制做一次数据库重置，用项目自带的初始化脚本重新灌数据，然后按演示路径完整走一遍，确认每一步都和预期一致。这样的现场不会有任何意外，也让我对每一张表的数据来龙去脉心里有数。

从那以后我每次拿到课设工程资源，第一件事就是跑通初始化脚本、走一遍核心业务闭环，再进代码看事务边界，最后才碰页面。这套工程的完整度在课设资源里属于优质级别，代码能跑、表有设计、页面有视觉、流程有亮点，你花一个下午复现，收获的东西不只是答辩学分。希望帮到你。

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