超市信息管理系统数据库设计：从ER图到JDBC事务的完整实践

简介这份资源是数据库课程设计完整报告《小型超市信息管理系统.docx》适合需要完成数据库系统课程设计的信息管理、计算机相关专业学生使用。内容从需求分析、功能模块划分、面向对象用例设计到概念结构、逻辑结构、物理结构设计再到数据库创建、编码测试与进度安排给出了一套可直接参考的超市进销存管理方案。文档重点覆盖供应商、商品、库存、人事、销售与财务等核心表结构及其关系模式优化并根据不同用户角色说明权限划分便于理解数据库从建模到落地的全过程。资源为单个docx文档大小约282KB适合下载后查阅、修改或作为课程设计报告模板。当前已有321人浏览学习对于正在准备数据库课程设计或复习数据库设计流程的同学这份报告能提供较为清晰的思路和体系化的结构参考。1. 数据库课程设计里的超市系统为什么最后交的那份 docx 才是重点每到学期末数据库课程设计就把人分成两拨一拨在熬夜调程序一拨在熬夜编文档。超市信息管理系统是数据库课程设计里出镜率最高的题目没有之一因为它业务链完整、表结构有实体有联系、增删改查样样都沾。但很多人的状态是代码能跑、表能建最后交上去的“数据库课程设计超市信息管理系统.docx”却漏洞百出ER 图画错、关系模式缺外键、范式分析一笔带过答辩被老师一问就卡壳。这篇笔记从需求拆解开始一路走到建表、连接池、事务、库存预警和统计报表最后落回那份 docx 的组织方式。适合正在做课程设计的人照着复现也适合想快速搭一个进销存原型的人参考。2. 先把数据模型立住从 ER 图到关系模式的落地2.1 需求边界一张销售小票背后要挂几张表超市信息管理系统听起来很大但课程设计阶段的业务边界其实非常固定。核心就四件事进货、销售、管库存、管会员。信息管理系统最忌讳一上来就堆表先梳理业务动作再反推实体关系。我一般会先列一张业务动作表把每个动作涉及的数据写清楚。业务动作涉及数据落到的表供应商供货商品、进价、数量、日期商品表、进货表、供应商表收银台结账商品、数量、单价、收银员销售主表、销售明细表库存查询商品、库存量、预警阈值商品表会员积分会员、消费金额会员表、销售主表一张销售小票在数据库里不是一条记录而是两张表配合销售主表记“这次消费的订单号、收银员、总金额”销售明细表记“这个订单里每一样商品买了几件、多少钱”。主表和明细表是一对多关系这是超市系统数据模型的核心后面所有统计、报表都依赖这个拆分。2.2 关系模式设计六张核心表的字段与约束做完需求梳理关系模式就顺理成章了。常见做法是至少拆出六张表商品、供应商、员工、会员、销售主表、销售明细再加一张进货表也完全合理。字段设计有一个原则能用业务语义表达的不绕弯能不加冗余字段的坚决不加。商品表的核心字段包括商品编号主键、条码唯一索引、名称、类别、进价、售价、库存量、预警阈值、供应商编号外键。这里有一个关键选择主键用自增整数还是商品条码。条码在超市场景里确实唯一但条码位数长且可能变更课程设计里用自增主键更稳妥条码单独加唯一索引即可。金额字段必须用DECIMAL(10,2)这是血泪经验。FLOAT在累计求和时会出精度问题对账对不上后面避坑章节细说。会员表要存手机号、积分、等级员工表要存账号、密码、角色角色决定登录后看到的是收银界面还是管理界面。关系模式设计完要过一遍 3NF 检查每个非主属性完全依赖于主键没有传递依赖。商品表的供应商名称就不该存在商品表里通过供应商编号关联销售明细表的商品名称也不该冗余存在一律用商品编号关联。课程设计报告里能正确写出这个分析比多写两张表有价值得多。2.3 用 MySQL 把六张表建出来DDL 与关键索引选型上课程设计最常见的是 MySQL也有学校机房装 SQL Server。MySQL 8.0 语法通用下面的 DDL 可以直接执行。建库时务必指定字符集否则后面中文乱码就是一场灾难。CREATE DATABASE supermarket_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE supermarket_db; CREATE TABLE supplier ( supplier_id INT AUTO_INCREMENT PRIMARY KEY, supplier_name VARCHAR(50) NOT NULL, contact_name VARCHAR(20), phone VARCHAR(20) ) ENGINEInnoDB; CREATE TABLE product ( product_id INT AUTO_INCREMENT PRIMARY KEY, barcode VARCHAR(30) NOT NULL UNIQUE, product_name VARCHAR(100) NOT NULL, category VARCHAR(30), purchase_price DECIMAL(10,2) NOT NULL, sale_price DECIMAL(10,2) NOT NULL, stock_quantity INT NOT NULL DEFAULT 0, warn_threshold INT NOT NULL DEFAULT 10, supplier_id INT, CONSTRAINT fk_product_supplier FOREIGN KEY (supplier_id) REFERENCES supplier(supplier_id) ON DELETE RESTRICT ON UPDATE CASCADE ) ENGINEInnoDB; CREATE TABLE employee ( employee_id INT AUTO_INCREMENT PRIMARY KEY, emp_no VARCHAR(20) NOT NULL UNIQUE, emp_name VARCHAR(20) NOT NULL, password VARCHAR(64) NOT NULL, role VARCHAR(10) NOT NULL DEFAULT cashier ) ENGINEInnoDB; CREATE TABLE member ( member_id INT AUTO_INCREMENT PRIMARY KEY, phone VARCHAR(20) NOT NULL UNIQUE, member_name VARCHAR(20), points INT NOT NULL DEFAULT 0, member_level VARCHAR(10) NOT NULL DEFAULT normal, register_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB; CREATE TABLE sale_order ( order_id INT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(30) NOT NULL UNIQUE, employee_id INT, member_id INT, total_amount DECIMAL(10,2) NOT NULL DEFAULT 0, sale_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_sale_employee FOREIGN KEY (employee_id) REFERENCES employee(employee_id), CONSTRAINT fk_sale_member FOREIGN KEY (member_id) REFERENCES member(member_id) ) ENGINEInnoDB; CREATE TABLE sale_item ( item_id INT AUTO_INCREMENT PRIMARY KEY, order_id INT NOT NULL, product_id INT NOT NULL, quantity INT NOT NULL, unit_price DECIMAL(10,2) NOT NULL, CONSTRAINT fk_item_order FOREIGN KEY (order_id) REFERENCES sale_order(order_id) ON DELETE CASCADE, CONSTRAINT fk_item_product FOREIGN KEY (product_id) REFERENCES product(product_id) ) ENGINEInnoDB; CREATE TABLE purchase ( purchase_id INT AUTO_INCREMENT PRIMARY KEY, product_id INT NOT NULL, supplier_id INT, quantity INT NOT NULL, unit_cost DECIMAL(10,2) NOT NULL, purchase_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_purchase_product FOREIGN KEY (product_id) REFERENCES product(product_id), CONSTRAINT fk_purchase_supplier FOREIGN KEY (supplier_id) REFERENCES supplier(supplier_id) ) ENGINEInnoDB;几个参数说明。ENGINEInnoDB是为了支持外键和事务MyISAM 不支持事务课程设计只要涉及销售下单就一定用 InnoDB。ON DELETE RESTRICT的意思是供应商下面还有商品时禁止删供应商防止产生孤儿数据sale_item用CASCADE是因为删订单主表时明细应该跟着删。索引方面外键列 MySQL 会自动建索引但sale_item表建议手动加一个(order_id, product_id)联合索引订单明细查询、统计都会受益。代码里的约束如果嫌多可以删掉外键改用应用层逻辑但课程设计不推荐这么做。数据库信息管理系统的实质就是让数据库承担数据一致性外键是答辩时能讲清楚的点。3. 让数据活起来JDBC 连接池与增删改查的工程化写法3.1 为什么课程设计要用连接池从 DriverManager 到 HikariCP很多课程设计示例代码还在用DriverManager.getConnection()每次操作都新建连接、用完关闭。这个写法在单机 Demo 里没问题但有两个明显的坑一是频繁建连开销大二是连接不关闭会直接把数据库连接数打满报 “Too many connections”。数据库课程设计只要涉及真实界面操作就应该引入连接池。HikariCP 是 Java 生态里最常见的连接池实现配置简单、性能好。用 Maven 引入com.zaxxer:HikariCP和mysql:mysql-connector-java初始化一个连接池只需要几行配置。HikariConfig config new HikariConfig(); config.setJdbcUrl(jdbc:mysql://localhost:3306/supermarket_db?useSSLfalseserverTimezoneAsia/Shanghai); config.setUsername(root); config.setPassword(your_password); config.setMaximumPoolSize(10); config.setMinimumIdle(2); config.setConnectionTimeout(30000); config.setIdleTimeout(600000); HikariDataSource dataSource new HikariDataSource(config);参数说明maximumPoolSize是连接池里最多同时存在的连接数课程设计单机运行 10 足够minimumIdle是空闲时保持的最小连接数设 2 能避免刚启动时频繁建连connectionTimeout是拿不到连接时的等待时间30 秒比较合理idleTimeout是空闲连接被回收前能存活的最长时间注意它要小于数据库自己的wait_timeout否则连接被 MySQL 断开后池里还在用又会出现连接失效的报错。连接池的关键逻辑是应用自己不关连接只从池里借、用完还回去。下面的 CRUD 代码配合这个池子使用资源由池统一管理。3.2 商品与供应商的增删改查PreparedStatement 模板数据库课程设计的功能主体就是增删改查。商品管理是最标准的例子新增、修改、删除、按名字模糊查询四个方法写出来其他模块照着套就行了。public int insertProduct(Product p) throws SQLException { String sql INSERT INTO product (barcode, product_name, category, purchase_price, sale_price, stock_quantity, warn_threshold, supplier_id) VALUES (?, ?, ?, ?, ?, ?, ?, ?); try (Connection conn dataSource.getConnection(); PreparedStatement ps conn.prepareStatement(sql)) { ps.setString(1, p.getBarcode()); ps.setString(2, p.getProductName()); ps.setString(3, p.getCategory()); ps.setBigDecimal(4, p.getPurchasePrice()); ps.setBigDecimal(5, p.getSalePrice()); ps.setInt(6, p.getStockQuantity()); ps.setInt(7, p.getWarnThreshold()); ps.setInt(8, p.getSupplierId()); return ps.executeUpdate(); } }增删改查的四个操作本质上都是这个模板拿到连接、预编译 SQL、绑定参数、执行、自动关闭资源。try-with-resources写法保证了连接一定会归还连接池不会因为异常漏关。注意String sql里一律用?占位不要用字符串拼接。一方面防 SQL 注入另一方面PreparedStatement有预编译缓存频繁执行的 SQL 性能更好。查询接口需要分页时用LIMIT ?, ?第一个参数是偏移量第二个是每页条数。删除商品时如果该商品已经被销售明细引用直接 DELETE 会触发外键限制要么提示“商品有销售记录不能删除”要么做逻辑删除——商品表加一个status字段删的时候改成下架状态。3.3 销售下单的事务边界扣库存与记账不能拆销售结账是超市系统里唯一必须用事务的地方。一个完整下单动作包含五步查库存是否够、插入销售主表、插入销售明细、扣减商品库存、累加会员积分。这五步要么全成功要么全失败不能出现明细写进去了但库存没扣的情况。这就是为什么前面建表要选 InnoDB。public boolean checkout(SaleOrder order, ListSaleItem items) throws SQLException { Connection conn dataSource.getConnection(); try { conn.setAutoCommit(false); // 1. 检查并锁定库存 String checkSql SELECT stock_quantity FROM product WHERE product_id ? FOR UPDATE; // 2. 插入销售主表拿到自增 order_id String insertOrderSql INSERT INTO sale_order (order_no, employee_id, member_id, total_amount) VALUES (?, ?, ?, ?); // 3. 插入销售明细逐条绑定 order_id String insertItemSql INSERT INTO sale_item (order_id, product_id, quantity, unit_price) VALUES (?, ?, ?, ?); // 4. 原子扣减库存库存不够则更新行数为 0 String deductSql UPDATE product SET stock_quantity stock_quantity - ? WHERE product_id ? AND stock_quantity ?; // 5. 累加会员积分 String pointsSql UPDATE member SET points points ? WHERE member_id ?; conn.commit(); return true; } catch (SQLException e) { conn.rollback(); throw e; } finally { conn.setAutoCommit(true); conn.close(); } }这个流程里有两个容易被忽略的细节。一是SELECT ... FOR UPDATE它的作用是把商品行锁住防止两个收银员同时卖最后一件商品时都查到库存有货二是扣库存的 SQL 用WHERE stock_quantity ?做条件更新返回 0 表示库存不足这件事必须放在事务里否则会出现库存减成负数的翻车现场。事务提交前如果任何一步抛异常conn.rollback()会把前面所有操作全部撤销。finally里把autoCommit恢复为 true 再关闭连接是避免连接归还连接池后还带着事务状态。课程设计答辩时这段事务代码是可以讲五分钟的核心内容。4. 超市场景特有的三个功能点库存预警、会员积分、销售统计4.1 库存预警低于阈值就高亮库存预警是超市信息管理系统区别于一般图书管理系统的标志性功能。实现不复杂一张商品表加一个预警阈值字段就能做但查询的写法有讲究。-- 预警列表库存小于等于阈值的商品 SELECT product_id, barcode, product_name, stock_quantity, warn_threshold, supplier_id FROM product WHERE stock_quantity warn_threshold ORDER BY stock_quantity ASC;界面拿到结果后把预警商品的记录行背景色标红或者在表格前加一段提示文字。注意这个查询要配合库存变动后的主动刷新常见做法是在商品扣减成功、进货入库之后都调用一次预警查询刷新界面。还有一种做法是建一个视图v_warning_product把这个查询固化下来界面直接查视图逻辑更清晰。课程设计报告里可以把“预警的判定放在数据库层还是应用层”作为设计点写一段分析放在 SQL 里做减少数据传输量放在应用层做逻辑直观但每条商品都要查出库存量。4.2 会员积分存储过程还是应用层计算会员积分在超市系统里的规则一般是消费满一元积一分结账时由收银员录入会员手机号判断积分等级。这个功能在课程设计里建议用存储过程实现答辩时是一个加分项。DELIMITER // CREATE PROCEDURE sp_add_points(IN m_phone VARCHAR(20), IN consume_amount DECIMAL(10,2)) BEGIN DECLARE p INT DEFAULT 0; SET p FLOOR(consume_amount); UPDATE member SET points points p WHERE phone m_phone; -- 积分达到阈值升级会员等级 UPDATE member SET member_level CASE WHEN points 500 THEN gold WHEN points 200 THEN silver ELSE normal END WHERE phone m_phone; END // DELIMITER ;这个存储过程的逻辑有两点值得在报告里说明一是FLOOR(consume_amount)把消费金额向下取整成积分避免小数积分二是等级升级用CASE表达式一次性算出来比先查再算两步更稳妥。Java 端调用存储过程用CallableStatement传入手机号和销售额即可。不过存储过程也有代价调试不方便而且数据库迁移时存储过程要单独处理。课程设计用它可以展示“数据库不只是存数据还能做业务逻辑”的理解但要控制数量一两个足以。4.3 销售统计按日期、按类别、按收银员三条 SQL统计报表是信息管理系统最拿得出手的功能也最容易被做成摆设。常见做法是只贴一张“今日销售额”的截图但真正合理的统计模块应该有三张报表按日期汇总销售额、按类别汇总销量、收银员交班汇总。三条 SQL 分别如下。-- 按日期统计销售额 SELECT DATE(sale_time) AS sale_date, COUNT(DISTINCT order_id) AS order_count, SUM(total_amount) AS daily_sales FROM sale_order WHERE sale_time 2024-01-01 GROUP BY DATE(sale_time) ORDER BY sale_date DESC; -- 按商品类别统计销量取 TOP 10 SELECT p.category, SUM(si.quantity) AS sold_quantity, SUM(si.quantity * si.unit_price) AS category_sales FROM sale_item si JOIN product p ON si.product_id p.product_id GROUP BY p.category ORDER BY category_sales DESC LIMIT 10; -- 收银员某日交班汇总 SELECT e.emp_name, COUNT(o.order_id) AS order_count, SUM(o.total_amount) AS total_sales FROM sale_order o JOIN employee e ON o.employee_id e.employee_id WHERE DATE(o.sale_time) CURDATE() GROUP BY e.employee_id;这三条 SQL 覆盖了GROUP BY、JOIN、聚合函数三个必考知识点。第一个报表注意DATE()函数的使用它把DATETIME截断成日期才能按天分组如果按小时分组则用HOUR(sale_time)。第三个报表用于交班对账实际超市里每班收银员要打出交班小票和系统里的total_sales核对差额要能查明细。统计查询的性能依赖索引。sale_order.sale_time和sale_item.product_id是高频查询条件建议手动补索引。课程设计数据量小有没有索引差别不明显但报告里写一句“在大数据量下需为时间列建索引”会让老师觉得你考虑过扩展性。5. 数据库课程设计避坑指南从建库到答辩的常见翻车点5.1 建库没指定字符集中文全变问号现象插入中文商品名页面显示正常但用 Navicat 打开表看到一堆??或者反过来表里看是中文界面查出来是乱码。原因MySQL 安装默认字符集可能是latin1建库建表时没显式指定utf8mb4客户端连接也没指定编码。字符集问题在数据库课程设计里是最常见的翻车点没有之一。解决建库时加上DEFAULT CHARACTER SET utf8mb4JDBC 连接串加characterEncodingUTF-8界面连接也确认选的是 utf8mb4。已经建好的表用ALTER TABLE product CONVERT TO CHARACTER SET utf8mb4;补救但已有乱码数据需要删除后重新插入。5.2 外键约束报错删不掉父表数据现象想删除某个供应商执行 DELETE 直接报错 “Cannot delete or update a parent row: a foreign key constraint fails”。原因这是外键生效的正常表现。供应商表是父表商品表通过supplier_id引用它只要存在商品引用这个供应商直接删父表记录就会撞墙。解决业务上正确的做法是先转移或删除子表数据再删父表。代码里捕获SQLIntegrityConstraintViolationException提示“该供应商下有商品请先处理商品再删除”。课程设计中不要图省事删外键这个报错在答辩时能讲成“数据库完整性约束起到了作用”。5.3 金额用 FLOAT月底对账对不上现象销售统计的总金额和手工计算的小票金额差几分钱时间越久差得越多。原因FLOAT和DOUBLE是浮点数某些十进制小数在二进制里无法精确表示累加后误差放大。这是计算机组成原理的经典问题但课程设计里不少人栽在上面。解决金额字段一律使用DECIMAL(10,2)Java 端用BigDecimal接收。商品表、销售主表、销售明细表的所有价格、金额列全部统一不要在部分表用 DECIMAL、部分表用 DOUBLE否则 JOIN 之后会作妖。5.4 高并发扣库存超卖现象两个人同时买最后一件商品两个下单请求都显示成功库存变成 -1。原因先 SELECT 查库存、再 UPDATE 扣减两步之间有时间差两个事务都看到库存大于 0。解决用前面给出的条件更新UPDATE product SET stock_quantity stock_quantity - ? WHERE product_id ? AND stock_quantity ?更新行数为 0 则说明库存不足回滚事务。课程设计里用一个线程循环模拟并发请求就能把这个坑演示出来。这属于数据库并发锁的应用场景报告里可以展开写。5.5 设计文档与代码脱节ER 图字段对不上现象答辩时老师翻开 docx问“你的商品表里有个 warn_threshold 字段代码里怎么没用到”当场翻车。原因先写代码后补文档ER 图和关系模式是随便画的没和建表 SQL 比对。解决文档里的 ER 图、关系模式表、DDL 三处必须严格一致。建议先设计再写代码或者写完代码后反向检查一遍每个实体对应一张表每个字段都能在 DDL 里找到每个外键在关系模式里标了。docx 交付前留出半小时做这件事比多写一个功能更值。6. 让那份 docx 为你加分ER 图规范与文档组织的三个技巧课程设计的评分很大程度落在那份 docx 上代码反而是辅助材料。文档组织的第一条原则是控制在 30 到 50 页不要凑页数。ER 图用 draw.io 或 Visio 画实体用矩形、联系用菱形、基数标在连线两端商品和销售明细之间标 1:n销售主表和销售明细之间也标 1:n不要画成多对多。关系模式表按“表名 字段列表 主键 外键”四列排主键加下划线、外键加波浪线这是数据库课程设计报告的硬规格。第二个技巧是每个功能模块截图两张操作前和操作后配一段 SQL 和运行结果说明。比如销售下单模块先展示商品库存为 10下单数量 3 之后再查库存为 7附上UPDATE product SET stock_quantity stock_quantity - 3的日志截图。这种前后对照在答辩现场比空口解释有用得多老师能快速确认功能真实可用。第三个技巧是附录放关键代码而不是全量代码。核心事务那 30 行放附录加上连接池配置和三条统计 SQL其他的不要贴。全量贴代码只会让老师觉得你没筛选能力。docx 里的文字部分重点写清楚三件事业务需求和超市实际场景的对应关系、范式分析为什么满足 3NF、事务边界为什么这样切。最后说一个我的习惯交付前花一小时用 Navicat 打开数据库把每张表的字段和 docx 里的关系模式表逐项核对一遍再顺手清掉测试数据。数据库课程设计做到最后技术差距其实不大差别就在这些检查里。希望这篇笔记帮你把代码和文档都打磨到能站住脚答辩顺利。本文还有配套的精品资源点击获取