VB6.0+Access库存管理系统设计方案：数据库设计与出入库事务实践

简介：《库存管理系统设计方案》是一份面向信息管理、计算机相关专业学生及初阶开发者的课程设计与毕业设计参考文档，围绕企业库存管理中的入库、出库、库存查询与预警等业务，梳理从需求分析到系统实现的完整思路。压缩包共1个doc文件，约604KB，篇幅涵盖管理信息系统概述、数据库理论基础、SQL语言、Visual Basic与Access 2000开发工具、模块划分、数据库设计及应用程序设计等章节，目录结构较完整，便于按设计流程查阅。已有127人学习，适合需要理解MIS类系统设计框架、撰写方案文档或准备答辩的读者参考。文中结合数据一致性、安全性及界面与业务逻辑处理展开，可帮助读者把握库存管理系统的功能构成、表关系设计和开发工具选型，并了解设计总结中的改进方向。

1. 从一本手写台账说起：库存管理系统设计方案要解决的真问题

一个中型仓库，货品上千种，出入库靠三本手写台账，月底盘一次账要四个人对两天——这是库存管理系统设计方案这类题目最常见的原始场景。这套库存管理系统设计方案要做的不是把台账原样搬进电脑，而是先用关系模型把货品、仓库、供货单位、经办人员、入库单、出库单的关系固定下来，再用程序把每一次业务动作变成一次可回滚的数据写入，让库存在任何时刻都对得上账。技术栈用 VB 6.0 做前台、Access 2000 存数据，走信息管理系统（MIS）的典型路线：界面可视化、事件驱动、单机部署就能跑，插上电源配置好数据库文件就有系统用。它适合正在做毕设或课程设计、需要一套既能讲清架构又能真跑起来的同学，也适合手里有个小仓库、想要一份可以直接改的方案的开发者。下面按需求、选型、表结构、代码、避坑、验收的顺序把这套方案拆开，每一段都能对应到最终交出去的那份文档里。

2. 需求分析与技术选型：四条业务主线和 VB 6.0 + Access 2000 的适用边界

2.1 四条业务主线把需求框住

需求文档最容易写成一锅粥，什么都想要，最后什么都验收不了。我通常的做法是先切成四条主线，每条主线对应一组窗体、一组表和一批可演示的操作，后面的设计、编码、答辩全部围着这四条转。

第一条是登录与权限。仓库管理员、保管员、只读查询人员看到的东西必须不一样：管理员能维护货品主数据和系统用户，保管员只能做入库和出库，只读人员只能查询和打印报表。权限不是界面上摆着好看的装饰，它决定了每个窗体打开时菜单项是否可用，也决定了在数据层要不要再做一次校验。很多同学把权限做成一个登录框加一个“欢迎使用”标签，答辩老师第一个问的就是“我用只读账号能不能删数据”，这一问就翻车。

第二条是主数据维护，包括仓库信息、货品类别、货品信息、供货单位和经办人员。主数据的特点是“改一次影响很多处”，比如一个供货单位的联系电话变了，所有引用它的业务记录看到的都应该是新号码。这个特点直接决定了它必须独立成表，绝不能跟流水记录混在一张表里。

第三条是入库，第四条是出库。这两条是整套系统里最容易出问题的地方：入库要同时写流水、回写库存、记录供货单位和经办人；出库要先校验库存够不够、再写流水、再扣减库存。任何一步只做了一半，账面上从此就对不上，而且这种错误在演示时不一定当场暴露，往往等老师翻到第三页查询才露馅。

除此之外还有一条横切的需求——统计查询与报表：库存查询、短线货品（低于警戒下限）和超储货品（超过储位上限）的预警、月度出入库汇总、经办人员工作量统计。这一类需求不产生新数据，但它是整个系统里最能体现“这套东西真的有用”的部分，答辩时十有八九靠它拉分。

把这些写进需求表时，我习惯给每条需求配一个“操作—数据变化—可见结果”的三元组，写不出这三段就说明这条需求还没想清楚。以入库为例：操作是录入一张入库单并保存，数据变化是 in_record 新增一行、goods.StockQty 增加对应数量，可见结果是库存查询页上的数字变了、入库报表里能查到这张单。照着这个格式把四条主线全部过一遍，需求分析这一章基本就能交稿了，而且每一条后面都能直接对应到一个测试用例。

2.2 技术选型：VB 6.0 与 Access 2000 的适用边界

Visual Basic 6.0 在这个场景里的优势很实在。窗体加控件的可视化设计，把界面从“算坐标画按钮”里解放出来，拖一个 DataGrid 上去设个 DataSource 就能显示整张表；事件驱动模型让“点这个按钮该干什么”变成一段挂在 Click 事件上的代码，不用自己写消息循环；Data 控件、ADO Data 控件、DataGrid、MSChart 这些现成组件，几乎覆盖了记录导航、表格展示和图表输出的全部需求。对于课程设计这种周期只有几周、又要出成品界面的场景，这套组合的开发效率几乎没有对手。

Access 2000 的定位必须讲清楚：它是桌面级关系数据库，整个库就是一个 .mdb 文件，随程序一起拷走就能重建环境，建表、建索引、写 SQL、设主键外键全都能做，还自带查询设计器可以直接看结果。代价同样明确：它是文件级共享，多人同时往同一张表写的时候会出现锁等待甚至写入冲突，数据量上去以后查询也会变慢。

所以技术选型的结论应当带边界，而不是一味吹“技术先进”。单仓库、几个到十几个操作员、流水记录在几万条以内，这套组合完全够用，部署成本接近于零——把 exe 和 mdb 放进同一个文件夹，双击就能跑。如果未来要跨仓管理、要几十人同时在线录入、要接条码扫描枪做实时采集，数据库就得换到服务端产品，但前台窗体和业务逻辑可以原样保留。把这个边界明确写进方案，比含糊其辞地说“本系统采用先进技术”要可信得多，也顺便回答了答辩时“为什么不用 Java”这类问题——不是不会，是这套场景里它不划算。

还有一个容易被忽略的实际问题：数据访问方式。Data 控件用起来最省事，绑定单表或简单查询，配合文本框、标签这些数据察觉控件，一行代码不用写就能翻记录；但它不提供事务边界，做入库这种“写两张表”的操作时靠不住。需要事务、需要多表联合更新的时候，就得走 ADO 的 Connection 对象，自己 BeginTrans、CommitTrans。两套并存不是设计冗余，是按场景分工，后面第 4 章会把分工表列出来。

2.3 DFD 与数据字典：把需求翻译成可验收的条目

需求分析做完，下一步不是马上打开 Access 建表，而是画数据流图。顶层图只有一件事：外部实体是仓库管理员和工作人员，中间一个加工叫“库存管理系统”，进出的数据流是入库单、出库单、查询条件和各类报表。图画出来只有几个框，但它逼着你回答“谁给系统喂数据、系统吐什么给人”这两个问题。

把顶层图展开成第一层，加工拆成五个：登录校验、主数据维护、入库处理、出库处理、查询统计。每个加工下面挂上它读写的数据存储：用户表、货品表、仓库表、供货单位表、入库表、出库表。图画完，数据存储清单就是数据库表的清单，一个不能多也一个不能少——多出来的表通常意味着某个概念还没想清楚，少掉的表会在写代码写到一半时突然冒出来，那时候再改表结构就得连窗体一起改。

数据字典是配套的。每条数据流、每个数据存储都要写清楚由哪些数据项组成，例如：

• 货品信息 = 货品编号 + 货品名称 + 类别编号 + 规格型号 + 计量单位 + 参考单价 + 当前库存 + 警戒下限 + 储位上限
• 入库单 = 入库单号 + 货品编号 + 仓库编号 + 入库数量 + 入库单价 + 入库日期 + 经办人 + 供货单位

这份东西看着枯燥，却是后面所有工作的验收基准。表建完了，字段和数据字典对不上就是设计漏项；代码写完了，某个字段从头到尾没有任何窗体读写过，那就是冗余字段，答辩被问到会很难解释。我一般把数据字典做成两列对照表，左边数据项、右边取值范围和来源，写代码时随手翻，比回头翻文档快得多。

3. 数据库设计：七张核心表怎么切、字段怎么约束、SQL 怎么写

3.1 从 E-R 图到表结构：实体边界怎么切

先说一个很多人踩过的反例。图省事把所有信息塞进一张大表，字段写成“货品编号、货品名称、类别、仓库、供货单位、联系电话、入库数量、出库数量……”，看起来一张表搞定，实际上它同时描述了三四个主题。后果很快就会显现：同一个供货单位在几百行里重复出现，电话一改要改几百行，漏改一行数据就不一致；某个货品这个月没入库，它的基本信息在表里根本查不出来；想统计某个类别的库存总量，得先想办法去重。

正确的切法是按实体切。这套系统识别出七个实体：类别、货品、仓库、供货单位、系统用户（经办人员）、入库单、出库单。关系用一对多表达：一个类别下挂多种货品，一种货品可以有多条入库和多条出库记录，一个仓库承接多条出入库，一个供货单位供应多条入库，一个用户经办多条出入库。E-R 图画出来就是五个主数据实体围着一张货品表、两张流水表打转，结构非常干净。

这里有个判断标准，我自己一直在用：如果某个字段会因为“另一个实体的属性变了”而需要批量更新，那它就放错表了。联系电话属于供货单位，不属于入库单；货品名称属于货品表，不属于流水表。流水表只回答“什么时候、谁、对哪个货品、做了多少数量”这件事，不回答“这个东西长什么样”。

还有一个取舍：入库和出库要不要合成一张流水表？合并的好处是汇总查询少一次联合，坏处是字段要么冗余要么大量留空——出库没有供货单位，入库没有领用单位。这里按原方案的思路拆成 in_record 和 out_record 两张表，字段各自干净，报表各写各的 SQL，代价是“出入库汇总”这种查询要多写一次 UNION。在课程设计的规模下，字段清晰比少写一条联合更重要，因为代码是要被人看和被人问的。

3.2 表结构与字段约束：把类型、主键、外键钉死

七张表的职责划分如下：

其中货品表是全系统的核心，字段约束要写死，不能含糊：

几个细节值得单独说。StockQty 是唯一一个会被业务操作修改的字段，它的修改权必须收归入库处理和出库处理两个加工，任何“货品维护”窗体都不允许直接编辑它，否则库存数字就没有可信来源了。编码规则用“类别码 + 顺序号”，好处是从编号就能看出类别，报表分组时省一步关联，但类别关联仍然要用 CategoryID 做外键，不要拿编号前缀当外键用，那是把展示格式当成了数据模型。

流水表的外键要齐：GoodsID、WarehouseID、OperatorID 三个都必须有，SupplierID 只在入库表出现。这些外键在 Access 里可以建立关系并勾上“实施参照完整性”，好处是删一个还在被引用的货品会被直接拒绝，坏处是删除操作要按依赖顺序来。我的做法是主数据一律做逻辑废弃处理（加一个停用标记），物理删除只留给录错的流水，这样既保住了完整性，也保住了历史账。

3.3 SQL 落地：查询、预警与报表的写法

数据库建好之后，真正体现设计水平的是 SQL。系统里最常用的三条查询，一条都不能含糊。

第一条是库存预警，进系统就该看到：

-- 库存预警：低于警戒下限或超过储位上限的货品，登录后首页直接展示 SELECT g.GoodsID AS 货品编号, g.GoodsName AS 货品名称, c.CategoryName AS 类别, g.StockQty AS 当前库存, g.WarnQty AS 警戒下限, g.MaxQty AS 储位上限, IIf(g.StockQty < g.WarnQty, '短线', '超储') AS 预警类型 FROM goods g INNER JOIN category c ON g.CategoryID = c.CategoryID WHERE g.StockQty < g.WarnQty OR g.StockQty > g.MaxQty ORDER BY g.StockQty;

这条语句的关键在于把两种异常合并在一个 WHERE 里，用 IIf 分出类型，前端只需要一个 DataGrid 就能同时展示短线货品和超储货品两个列表。IIf 是 Access 的内置函数，等价于其他数据库的 CASE WHEN；如果以后迁库，这一处需要改写——方案里最好注明。

第二条是月度出入库汇总，报表模块的底表：

-- 月度汇总：按货品统计指定区间的入库合计与出库合计 SELECT g.GoodsID AS 货品编号, g.GoodsName AS 货品名称, Nz((SELECT SUM(InQty) FROM in_record WHERE GoodsID = g.GoodsID AND InDate BETWEEN #2024-01-01# AND #2024-01-31#), 0) AS 入库合计, Nz((SELECT SUM(OutQty) FROM out_record WHERE GoodsID = g.GoodsID AND OutDate BETWEEN #2024-01-01# AND #2024-01-31#), 0) AS 出库合计 FROM goods g ORDER BY g.GoodsID;

这里用子查询而不是 LEFT JOIN 加 GROUP BY，原因是两张流水表都做左连接再分组会产生笛卡尔放大，入库 3 条、出库 5 条会变成 15 行参与求和，数字直接错。Nz 是 Access 的判空函数，没有它，某个货品这个月一次都没出入库就会显示空白而不是 0，导到图表里就是断点。日期常量在 Access 里必须用 # 包裹，写成 '2024-01-01' 这种字符串形式在某些区域设置下会解析失败，这是血泪经验。

第三条是单个货品的出入库明细，用来追账：

-- 出入库明细：按时间轴合并两类业务，谁办的、跟谁往来、备注都带出来 SELECT '入库' AS 业务类型, i.InDate AS 发生日期, i.InQty AS 数量, s.SupplierName AS 往来单位, u.UserName AS 经办人, i.Remark AS 备注 FROM (in_record i INNER JOIN supplier s ON i.SupplierID = s.SupplierID) INNER JOIN users u ON i.OperatorID = u.UserID WHERE i.GoodsID = '0100000001' UNION ALL SELECT '出库' AS 业务类型, o.OutDate AS 发生日期, o.OutQty AS 数量, o.Receiver AS 往来单位, u.UserName AS 经办人, o.Remark AS 备注 FROM out_record o INNER JOIN users u ON o.OperatorID = u.UserID WHERE o.GoodsID = '0100000001' ORDER BY 发生日期;

UNION ALL 而不是 UNION，因为两类业务本来就不会重复，用 ALL 省一次去重排序；ORDER BY 只能写在最后一段，中间那段写了会报错。这两点在 Access 里都是硬规定，写错一次就要调半天。

3.4 索引、事务与权限：一致性和安全的三件套

索引要建在该建的地方，不能凭感觉。这套系统里真正需要索引的是三个位置：goods.GoodsName（模糊查询和排序都走它）、in_record.GoodsID 与 out_record.GoodsID（明细查询和汇总子查询反复按它过滤）、in_record.InDate 与 out_record.OutDate（按时间区间统计）。建索引的代价要写进方案里——每插入一行流水，索引也要跟着更新，所以流水表上不要见字段就建索引，三五个足够。Access 的主键默认带索引，外键字段记得手动补上，否则明细查询会退化成全表扫描。

事务是这套系统的生命线。入库和出库都是“写流水 + 改库存”两个动作，必须同生共死。VB 里通过 ADO 的 Connection 对象控制，BeginTrans 开始、CommitTrans 提交、RollbackTrans 回滚，三段缺一不可，而且回滚必须放在错误处理里，不是放在正常流程里。这一点第 4 章会给完整代码。

权限分三层来做。第一层是登录校验，用户名密码对上才放行，角色写进全局变量；第二层是界面层，根据角色禁用或隐藏菜单项和按钮，只读角色进不去入库窗体；第三层是数据层，关键操作在保存前再判断一次角色，防止有人绕过界面直接调用。第三层经常被省略，但它是唯一能挡住误操作的一层，方案里写上会让设计显得完整很多。

备份策略属于部署文档的一部分，但设计阶段就要定：每天下班前把 .mdb 文件复制一份到另一个目录，文件名带日期；每月做一次压缩修复，Access 的库文件反复增删之后会膨胀，不压缩体积能翻好几倍。这两条写进方案的操作手册里，答辩时被问“数据丢了怎么办”就有话可说。

4. 应用程序结构设计：MDI 窗体分层与三段关键代码

4.1 窗体结构：MDI 主窗体加业务子窗体的分工

界面结构采用的是 VB 里最经典的多文档界面：一个 MDI 主窗体作为容器，登录窗体先弹出，验证通过后主窗体显示，各个业务模块以子窗体形式在容器里打开。这样做的直接好处是菜单和工具栏只有一份，切换模块时不用重复登录，用户看着也像一个完整的系统而不是一堆散窗口。

主窗体上挂菜单栏，按四条业务主线分组：系统管理（用户维护、修改密码、退出）、基础数据（仓库、类别、货品、供货单位）、业务处理（入库登记、出库登记）、查询报表（库存查询、预警列表、出入库汇总、明细追账）。每个菜单项在 Form_Load 时按 g_intRole 判断是否可用，只读角色的“业务处理”整组灰掉。这个初始化函数不长，但它是权限设计的落点，代码里要写清楚每个角色对应哪些菜单。

子窗体各自独立成文件，命名统一前缀：frmGoods、frmInRecord、frmOutRecord、frmQuery、frmReport。每个子窗体只做三件事：收集用户输入、调用数据访问函数、刷新自己的显示。不要把 SQL 直接写满整个窗体代码，否则改一个字段名要翻十几个文件。公共的东西放进标准模块 basMain：全局连接对象 g_conn、当前用户 g_lngUserID 和 g_strUserName、当前角色 g_intRole、以及一个 RefreshGrid 之类的通用刷新过程。这个分层看着简单，但它决定了后面改需求时是改一处还是改十处。

4.2 控件分工：Data 控件与 ADO Data 控件各管一段

VB 6.0 里能连数据库的控件有好几个，混着用会乱，按场景分工才稳：

Data 控件是 VB 里最基础的数据库控件，它通过 Recordset 对象访问数据，本身不显示内容，需要配合 TextBox、Label、DataGrid 这些数据察觉控件才有意义。当 Data 控件的当前记录变化时，绑定到同一数据源的文本框内容会跟着变，这个联动是自动的，不需要写一行代码。它适合货品维护这种单表增删改的窗体。

ADO Data 控件更适合查询页，因为它的 RecordSource 可以直接赋一条多表联合的 SQL，结果塞进 DataGrid 里展示，列宽、列标题在属性页里配好就不用管了。它和 Data 控件的区别在于连接方式更现代（走 OLE DB），对 Access 的支持也没问题。

真正做写入的时候两者都不够用，因为事务控制必须落到 Connection 上。所以入库、出库两个窗体里的“保存”按钮，走的是 ADO Connection 手写 SQL 的路线，DataGrid 只负责展示，不负责写入。这个分工在方案里写清楚，代码审阅时就不会有人问“为什么这里不用 Data 控件”。

4.3 三段关键代码：登录校验、入库事务、查询刷新

第一段是登录。它要

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