超市收银系统数据库设计：从E-R图到建表SQL实战

简介超市收银系统设计说明书是一份面向毕业设计场景的完整课程设计文档适合计算机、信息管理相关专业学生参考用于完成超市管理系统的需求分析、架构设计与数据库建模。文档配套介绍 C# 与 Visual Studio 2013 的技术选型内容涵盖系统需求分析、数据流图、数据字典、实体联系图、概要设计、数据库概念与逻辑结构设计、收银与后台管理模块的详细设计、人机界面设计以及软件测试等核心环节可作为撰写设计说明书和答辩材料的范文模板。压缩包内共 1 个 PDF 文件大小约 756KB即该设计说明书正文便于直接打开阅读或按需打印。当前已有 303 人学习说明其在毕业设计选题中具有一定参考价值。通过阅读读者可以快速掌握超市收银系统的功能划分、数据库表结构设计思路和前后台交互逻辑同时借鉴其文档目录组织方式辅助完成自己的课程设计或毕业论文。1. 超市收银系统设计说明书课程设计文档里最值得抄的六张表说实话看到“超市收银系统设计说明书.pdf”这个文件名第一反应是又一份凑字数的课程设计。真翻完发现不是这份文档把前台收银、后台进货、库存预警、会员折扣、权限控制这些要点全串起来了还有完整的数据库表结构设计和人机界面设计原则。对于正在做课程设计或毕业设计的在校生以及想快速搭一个 C/S 架构收银系统做内部工具的小团队这份文档的价值在于代码你可以自己写但需求边界、表结构、权限粒度这些框架性东西直接照着抄能省两三个晚上的返工时间。摘要里的关键字也写得很清楚C#、VS2013、MySQL文档追求的是“开放体系结构、易扩充、易维护、人机交互友好”这四句话就是超市收银这类管理软件的验收底线。2. 从需求分析到数据字典先把业务流程和数据边界画清楚2.1 需求分析到底分析什么前台、后台和权限边界文档的第 2 章把系统掰成了前台操作和后台管理两大块这个划分不是随便分的。前台面向收银员操作要求快、准、容错低后台面向店长和管理员操作要求全、可追溯、能控权。两类角色对系统的诉求完全不同所以数据库设计、界面布局、权限控制都得分开考虑。前台操作里商品录入支持三种方式输入唯一编号、扫描条形码、输入商品名称。这是很务实的设定因为超市收银员的电脑水平参差不齐条码枪是主力输入设备但遇到条码损坏或者散装商品时手输编号和名称就是保底方案。收银业务默认按“一次录入加数量”的模式处理同类多件商品扫描后自动算总金额、自动算找零、打印交易清单清单包括流水账号、商品名、数量、总金额、交易时间和收银员工号。注意这里有个细节会员卡要在交易前扫描所有商品直接打 95 折同时把金额累计到会员总消费额里会员卡有效期一年满一年未续卡自动注销。后台管理这边进货管理强调“根据销售及库存情况自动制定进货计划亦可手工制定修改”这条直接命中超市的积压货痛点——盲目进货导致商品积压是小超市最常见的资金浪费。销售管理支持促销、限量、限期、禁止销售四种控制还能按多种方式统计生成销售排行榜察看打印日、月、年报表。库存管理要求库存状态自动告警库存过剩、少货、缺货三种状态分别预警这对应数据库里的报警值字段。人员管理管四类人员工、会员、供货商、厂商重点是员工操作权限和客户销售权限。提示文档里“权限控制”这个词出现了至少五次。前台可改单价、可折扣、可抹零、可删单全部标注“权限控制”说明这套系统的安全模型是把操作敏感度和用户权限绑定而不是默认所有收银员一个权限。做课设时把这个点写进需求分析答辩老师会高看你一眼。2.2 数据流图与数据字典三张核心数据流的走向文档第 3 章给了一张数据流图DFDData Flow Diagram这张图值得细看。图里出现了三条核心数据流第一条是收银员扫描商品后生成销售信息销售信息去更新商品库存同时写入销售记录第二条是仓库管理员录入进货信息进货信息更新库存并写入进货记录第三条是前台经理根据库存情况产生进货单交给采购员执行进货。顺着这三条流就能把超市业务压缩成“进—销—存”一个闭环。数据字典部分定义了六条核心数据商品信息、销售清单、入库记录、用户信息、供应商信息、会员信息。每条都按“名称—别名—描述—定义—位置”五个维度展开比如商品信息定义为“商品编号类型编号商品名称库存量售价报警值商品规格计量单位”位置是“输出到打印机保存到磁盘”。写数据字典时有个容易被忽略的讲究定义里的字段顺序要和数据库表结构的字段顺序保持一致这不是强迫症而是为了让数据字典能直接当建表依据用。销售清单定义为“货物编号名称销售日期数量售价”入库记录定义为“入库编号货物编号供应商编号操作员进价数量”——多看两眼就会发现这两条记录里销售清单没有单价对应的总金额入库记录没有总价金额是后面数据库结构里才补的。这说明数据字典阶段只是梳理数据元素字段粒度的完善要等到数据库设计阶段。2.3 实体联系图从E-R图到关系模型的收敛路径文档图 4 到图 6 给了三张 E-R 图分别画了核心业务实体、用户实体和会员实体。核心 E-R 图里有商品、供应商、入库记录、销售记录四个实体商品和入库记录是 1:n一种商品可多次进货供应商和入库记录是 1:n一个供应商供多种货——这张图实际上已经把数据库的主外键关系画出来了。用户实体只有用户编号、用户名、密码三个属性这是因为用户登录者是系统主体不直接参与业务数据流会员实体有会员编号、会员名、积分、等级、电话、起始日期六个属性和业务相关但也不参与库存流转。读这张图的时候要注意一条线E-R 图里“商品—销售记录”的关系在文本里没写完整但结合数据字典能推断出是 1:n 关系。做课设时如果 E-R 图连关系基数都不标注数据库设计阶段必然会返工。把 E-R 图转成关系模型常规做法是每个实体一张表1:n 关系在 n 端加外键——商品表加商品编号外键到销售记录表入库记录表同时加商品编号和供应商编号两个外键这就是文档里入库记录表“备注主键、外键”的来源。3. 数据库结构设计从六张表到字段明细3.1 六张核心表的结构字段、类型、主外键一次看清数据库逻辑结构设计章节给出了六张表的完整字段设计这是全文档最有价值的部分。先看用户信息表和会员信息表用户表字段是 UserID、UserName、UserPassword、UserRight分别对应编号、姓名、密码、权限编号是 Int 类型主键长度没标会员表字段是 VipId、VipName、VipScore、VipRank、VipNumber、VipData对应编号、姓名、积分、等级、电话、成为会员时间全部非空。注意 VipScore 和 VipRank 在这个设计里都是 varchar(50)这个后面会讲到是个坑。销售信息表的字段有点意思GoodsId商品编号、SellPrice单价、GoodsNum数量、zongsell总价、Remark备注、DataTime销售时间。字段命名出现了中英混杂的现象GoodsNum 是英文驼峰zongsell 是拼音这种命名不一致在课程设计文档里非常常见但你要真拿它建库建议统一改成 sell_total 或者 total_amount。另一个重点是 zongsell 在表结构里类型也是 varchar(50)金额用字符串存会导致排序、求和、比较全部出错——这就是照着课设文档抄代码最容易翻车的地方。商品信息表是六张表里字段最多的GoodsId编号、TypeId类型号、GoodsName名称、GoodsUnit计量单位、GoodsNorm规格、GoodsSellprice售价、GoodsNum库存量、AlarmNum报警值、GoodsRemard备注。报警值这个字段对应需求里的库存预警功能当库存量小于报警值时生成缺货报告这个设计很典型。入库记录表有 StockId、GoodsId、CompanyId、Operator、GoodsPrice、DataTime、GoodsNum、Remark同时标注了主键和外键外键分别是商品编号和供应商编号。供应商信息表字段最少CompanyId、CompanyName、CompanyDirector、CompanyPhone、CompanyFax、CompanyAdd、HzDataTime对应的备注是“合作时间”。六张表放在一起超市管理系统的数据底座基本就齐了。3.2 用户编号从 1000 自增一个小设计习惯背后的思考文档里有一句很容易被扫过去的话“用户编号通过自增方式实现无需用户手动编号编号从 1000 起始。”很多人建表时直接写 AUTO_INCREMENT从 1 开始觉得无所谓。实际上从 1000 起始有三个实际好处第一预留前 1000 个编号给系统内置账号或测试数据避免和真实用户混淆第二编号位数固定为 4 位以上后期打印报表、按编号排序时格式更规整第三如果以后要和其他系统对接编号区间不容易冲突。我在实际项目里通常会把编号区间留得更大比如从 10000 起步因为小超市虽然只有几个收银员但供货商、会员的数量增长会比你预想快得多。就课设而言从 1000 起步已经是一个能写进答辩加分项的设计细节了。另一个和自增相关的问题是会员表和商品表没有写自增规则文档里只在用户表提到了“编号从 1000 起始”。这说明作者的设计意图是用户表用数据库自增其他表可能由程序生成或手工录入。实际做的时候建议统一用数据库自增省去程序里维护序列的麻烦因为 C# 这类 C/S 程序多实例并发时程序生成编号容易撞号。3.3 把 ER 图翻译成建表 SQL一份可直接运行的 MySQL 脚本文档里给了表结构但没有给建表 SQL实操时这一步必须自己补。我一般会把类型修正为合理的 MySQL 类型金额用 DECIMAL(10,2)数量用 INT日期用 DATETIME布尔用 TINYINT(1)字符串长度按业务调整。下面是按文档表结构整理的一套建表脚本可以直接在 MySQL 5.7 以上版本执行CREATE DATABASE IF NOT EXISTS supermarket DEFAULT CHARSET utf8mb4; USE supermarket; -- 用户信息表 CREATE TABLE user_info ( UserID INT AUTO_INCREMENT PRIMARY KEY COMMENT 用户编号自增起始1000, UserName VARCHAR(50) NOT NULL COMMENT 用户名, UserPassword VARCHAR(50) NOT NULL COMMENT 密码, UserRight VARCHAR(50) NOT NULL COMMENT 权限admin/operator ) AUTO_INCREMENT 1000 COMMENT 系统登录用户信息; -- 会员信息表 CREATE TABLE vip_info ( VipId INT AUTO_INCREMENT PRIMARY KEY COMMENT 会员编号, VipName VARCHAR(50) NOT NULL COMMENT 会员姓名, VipScore VARCHAR(50) NOT NULL COMMENT 会员积分, VipRank VARCHAR(50) NOT NULL COMMENT 会员等级, VipNumber VARCHAR(50) NOT NULL COMMENT 联系电话, VipData DATETIME NOT NULL COMMENT 成为会员时间 ) COMMENT 会员信息; -- 销售信息表 CREATE TABLE sell_info ( GoodsId INT NOT NULL COMMENT 商品编号外键, SellPrice DECIMAL(10,2) NOT NULL COMMENT 单价, GoodsNum INT NOT NULL COMMENT 销售数量, sell_total DECIMAL(10,2) NOT NULL COMMENT 总金额, Remark VARCHAR(50) COMMENT 备注, DataTime DATETIME NOT NULL COMMENT 销售时间, PRIMARY KEY (GoodsId, DataTime) ) COMMENT 销售信息; -- 商品信息表 CREATE TABLE goods_info ( GoodsId INT AUTO_INCREMENT PRIMARY KEY COMMENT 商品编号, TypeId INT NOT NULL COMMENT 商品类型编号, GoodsName VARCHAR(50) NOT NULL COMMENT 商品名称, GoodsUnit VARCHAR(50) NOT NULL COMMENT 计量单位, GoodsNorm VARCHAR(50) COMMENT 商品规格, GoodsSellprice DECIMAL(10,2) NOT NULL COMMENT 售价, GoodsNum INT NOT NULL COMMENT 库存量, AlarmNum INT NOT NULL DEFAULT 10 COMMENT 库存报警值, GoodsRemard VARCHAR(50) COMMENT 备注 ) COMMENT 商品信息; -- 入库记录表 CREATE TABLE stock_info ( StockId INT AUTO_INCREMENT PRIMARY KEY COMMENT 入库编号, GoodsId INT NOT NULL COMMENT 商品编号外键, CompanyId INT NOT NULL COMMENT 供应商编号外键, Operator VARCHAR(50) NOT NULL COMMENT 操作员, GoodsPrice DECIMAL(10,2) NOT NULL COMMENT 进价, DataTime DATETIME NOT NULL COMMENT 入库时间, GoodsNum INT NOT NULL COMMENT 入库数量, Remark VARCHAR(50) COMMENT 备注 ) COMMENT 入库记录; -- 供应商信息表 CREATE TABLE company_info ( CompanyId INT AUTO_INCREMENT PRIMARY KEY COMMENT 供应商编号, CompanyName VARCHAR(50) NOT NULL COMMENT 供应商名称, CompanyDirector VARCHAR(50) NOT NULL COMMENT 联系人, CompanyPhone VARCHAR(50) NOT NULL COMMENT 联系电话, CompanyFax VARCHAR(50) COMMENT 传真, CompanyAdd VARCHAR(50) COMMENT 地址, HzDataTime DATETIME COMMENT 合作起始时间 ) COMMENT 供应商信息;这段 SQL 里有几个地方是照着文档建表时容易出错的关键点。第一销售信息表我把主键设成了复合主键GoodsId DataTime这是因为原文档的销售表没有单独的销售流水号字段如果只用 GoodsId 做主键同一种商品在同一时间点多次销售就会冲突用“商品编号销售时间”做复合主键才能保证流水唯一第二sell_total 是 DECIMAL(10,2)原文档的 varchar(50) 必须改掉金额计算、报表汇总都依赖数值类型第三所有日期字段统一用 DATETIME原文档没有给 DataTime 定具体类型用 DATETIME 才能在测试阶段做范围查询比如“查某月销售额”第四商品表的 AlarmNum 我加了 DEFAULT 10默认库存告警阈值设为 10这个值后续可以在后台管理界面里针对不同商品单独调整。注意MySQL 里外键约束会影响删除和批量导入的效率课设项目数据量小加上外键能体现设计规范但如果是真实超市系统建议只保留逻辑外键物理外键在高峰期会拖慢写入。4. 详细设计与避坑登录权限、界面交互和常见翻车点4.1 登录模块的流程设计盒图表达和权限校验逻辑文档第 6 章用盒图N-S 图描述了登录流程输入用户名和密码与数据库比对一致则打开主窗体不一致则提示错误并要求重新输入。盒图没有箭头、不允许随意转移控制这种表达方式在课程设计说明书里很常见它能强制程序员用结构化思维写代码嵌套层次一眼就能看清。落实到 C# 代码登录校验的核心逻辑是参数化查询 权限字段判断。一般做法是先在数据库里查用户是否存在、密码是否匹配然后取出 UserRight 字段决定主窗体开放哪些菜单按钮。示范代码如下using (SqlConnection conn new SqlConnection(connectionString)) { string sql SELECT UserID, UserName, UserRight FROM user_info WHERE UserNamename AND UserPasswordpwd; using (SqlCommand cmd new SqlCommand(sql, conn)) { cmd.Parameters.AddWithValue(name, txtUserName.Text.Trim()); cmd.Parameters.AddWithValue(pwd, txtPassword.Text); conn.Open(); using (SqlDataReader reader cmd.ExecuteReader()) { if (reader.Read()) { // 登录成功记录用户权限加载主窗体 GlobalUser.UserID Convert.ToInt32(reader[UserID]); GlobalUser.UserName reader[UserName].ToString(); GlobalUser.UserRight reader[UserRight].ToString(); // 根据 UserRight 控制菜单可见性 MainForm mainForm new MainForm(); mainForm.InitByRight(GlobalUser.UserRight); mainForm.Show(); } else { MessageBox.Show(用户名或密码错误请重新输入, 登录失败); } } } }这段代码里的要点第一用 Parameters.AddWithValue 做参数化查询避免拼接 SQL 字符串导致注入答辩时老师问“安全性怎么做”这是标准答案第二登录成功后把 UserID、UserName、UserRight 存到全局对象 GlobalUser后面的操作记录、权限判断都要从这里取值第三InitByRight 这个方法根据权限控制主窗体的菜单和按钮文档里说的“前台收银员权限严格控制”“可直接修改销售数量、单价、折扣等权限控制”就是在这个方法里做拦截。需要注意的是AddWithValue 在 SQL Server 里对 NVARCHAR 和 VARCHAR 的隐式转换有时会引发索引失效数据量小无所谓量大了建议用 SqlDbType 显式声明类型——这只是个优化空间不影响课设功能。4.2 人机界面设计三原则一致性、反馈、防误操作文档 6.2 节列了三条设计规范一般交互设计、信息显示设计、数据输入设计。一般交互设计有七条我最看重的是“执行有较大影响的操作前提示用户确认”和“允许犯错误”。超市收银场景里删单、删行、改单价都属于高风险操作如果点一下就执行顾客还在旁边等着收银员非常容易误操作且无法挽回。文档里提到“删单、删行、查单权限控制”“特殊操作记录防止前台作弊”说明系统不只是对删除操作做提示还要求记录到底是哪个员工删的、什么时候删的、删的哪一笔——这让界面设计和权限设计联动起来了。信息显示设计有一条“产生有意义的错误信息”这条很容易被课设忽略。很多学生做的系统出错时弹一个“Exception occurred”或者干脆什么都不显示这份文档明确要求“给用户返回一个容易理解的错误信息”实操时我一般是 catch 异常后分类处理数据库连接失败提示“网络连接异常请检查服务器”外键冲突提示“该商品已被销售记录引用无法删除”库存不足提示“库存不足当前仅剩 X 件”。数据输入设计的核心是“尽量减少用户的输入动作”和“绝对不要要求用户提供程序可以自动获得的信息”最典型的例子是销售时间字段——收银员不需要手输时间系统取当前时间就行总金额也不该由收银员输入应该是单价乘数量自动算出来。文档里前台操作提到“支持电子称散装商品销售”这类商品没有标准条码输入动作就越少越好最好是称重数据直接通过串口进系统。4.3 避坑清单照着这份说明书实现时最常踩的四个坑坑一数据库选型前后矛盾。文档 5.4 节写“选取 MySQL 作为后台数据库”但摘要部分提到“如 SQL Server”系统构架图里也画着 SQL Server 服务器设备选型表里同样出现 SQL Server。现象是你照着文档写前言和结论时数据库名不一致会被答辩老师当场指出来。原因大概率是作者做课设过程中换了数据库或者从网上参考了不同来源的资料没统一。解决方式很简单全文档统一用 MySQL理由写“开源免费、部署简单、课设演示环境满足需求”然后建表脚本按 MySQL 语法走。坑二销售信息表字段类型错乱。原文档里 GoodsNum、zongsell总金额都是 varchar(50) 类型随之而来的现象是统计报表算不准、按金额排序时出现“10 9”的字符串比较结果。原因是作者没想清楚 varchar 只能存文本不能参与数值运算。解决方式是建表时金额字段用 DECIMAL(10,2)数量字段用 INT并且在前台录入时用 int.TryParse / decimal.TryParse 做类型校验输非法字符直接拦截。坑三会员折扣没有落库。需求里写“会员卡消费全部 95 折”积分字段 VipScore 也设计了但六张表里没有任何一张表存折扣率。现象是会员等级和折扣只能写死在代码里以后想改成“金卡 9 折、银卡 95 折”就得动代码。原因是设计者把折扣当成固定业务规则没当成本可配置的参数。解决方式是业务上是“若传人 data 表有该字段则为 0.95 折算后续可扩展”的做法但更规范的是加一张会员等级规则表字段至少包含 VipRank、DiscountRate、MinScore。坑四删单、改价没有操作日志表。文档反复强调“特殊操作记录防止前台作弊”但数据库设计里根本没有操作日志表。现象是做完了权限控制删单时却查不到是谁删的。原因是文档需求阶段提到了这个功能数据库设计阶段漏掉了。解决方式是在数据库里加一张的操作记录表LogId、OperatorId、OperateType改价/删单/抹零/作废、OrderId、OldValue、NewValue、OperateTime然后在前台“权限控制”的操作里统一写一条日志。提示课设答辩时主动说出这四个坑并附上解决方案效果远比念 PPT 好——老师会觉得你真把这份设计读透了。5. 从说明书到可运行系统用验收清单和补丁脚本把文档落地文档最后章节是软件测试但只列了测试流程没给测试用例。我自己把这份说明书当作验收清单用的方式是把第 2 章“任务需求分析”的每个功能点拆成一条验收项逐条对着实现打勾。比如前台操作里“挂单/取单”是一条验收项“会员卡 95 折”是一条验收项“权限控制下的删单”是一条验收项。这样做的好处是不会漏功能——数据库表都建好了但挂单没实现系统依然跑得起来只有对照验收项才能发现这个缺口。还要检查一份清单里的“边界情况”数量输入负数、库存为 0 时继续销售、会员卡过期后消费、供应商编号不存在时入库——每一条都能对应到一个具体的代码分支或者 SQL 约束。把文档里没有写出来的这些测试点列成表格逐条跑通会比空泛地写“系统测试通过”有说服力得多。数据库层面前面第 4 章提到的补丁脚本也要一起执行会员等级规则表和操作日志表建议在初始化数据时就建好字段统一用 utf8mb4 字符集。另外给作者最初设计的表结构做一个兼容性收尾所有表的主键统一为 INT AUTO_INCREMENT所有时间字段统一 DATETIME所有代码里拼接 SQL 的写法统一换参数化别等答辩前一晚一起改那种状态下出的 bug 是玄学很难追。我做这类课设文档二次开发时有个习惯拿到文档先做一次“数据字典 vs 建表脚本”的逐字段比对把不一致的地方全部标红改完再动手写 C# 代码。那次照着这份说明书建表一开始没在意 zongsell 的类型程序写完一跑报表求和全是 0查了两个多小时才发现是 varchar 求和被 MySQL 自动转 0 了。从那以后我每次拿到任何课程设计文档第一步永远是把字段类型、主外键、默认值全部过一遍确认无误才开始写业务代码——这个习惯帮我省掉的排查时间比写文档的时间多得多。希望这份说明书也能帮你少走几个类似的弯路。本文还有配套的精品资源点击获取