Jupiter超市管理系统
[!readme]
项目周期：20180401-20180606
项目介绍：Jupiter超市管理系统是基于GUI的一个桌面应用
项目资料：
GUI相关学习参考
技术栈：
Jupiter超市管理系统
0.摘要
现代社会生活节奏越来越快，人们也越来越注重生活的速度与品质。快捷方便、价格合理且质量有所保障的购物方式逐渐渗入人们的日常生活，然而，随着人们对生活品质和日常购物的需求越来越大，作为提供方的商家又该如何把握机遇，在困难和挑战中制定好相应的战略方案，顺势而上。在这种背景下，我们以日常生活中最常见的、最普遍的实例——超市为对象进行思考和分析，采用一个超市管理系统可以相应地提高超市的运作效率，通过全面的信息采集和处理辅助提高超市的决策水平，迅速提高超市的管理水平会降低超市的经营成本、从而达到提高效益、增强超市扩张力的目的。
本系统建设的主要目标是通过建立一个数据库应用系统，设计出一款通用性极强的超市管理系统，软件覆盖超市商品的采购、 销售、 库存、管理决策支持等各个环节，能够接洽食品、服装、保健品、电子、电器、物资、化妆品等各个商业领域的信息，软件的采购管理、销售管理、库存管理、员工管理等功能强大、灵活，同时为用户提供方便实用的模糊查询功能，用户可以在最短时间内找到自己所需要的信息。
关键词：超市管理; 数据库; 信息管理; 桌面系统应用
1. 需求分析
1.1. 项目背景
现代社会生活节奏越来越快，人们也越来越注重生活的速度与品质。快捷方便、价格合理且质量有所保障/的购物方式逐渐渗入人们的日常生活，然而，随着人们对生活品质和日常购物的需求越来越大，作为提供方的商家又该如何把握机遇，在困难和挑战中制定好相应的战略方案，顺势而上。在这种背景下，我们以日常生活中最常见的、最普遍的实例——超市为对象进行思考和分析，一家超市的管理涉及到许多方面，例如人员的管理、商品信息的管理、库存的管理、信息的统计等各个方面。其中每个方面又涵盖了不同的需求和功能，随着超市规模的壮大，传统的纸质管理由于工作量巨大、操作繁琐、数据不方便管理且容易丢失，俨然不能满足现代超市管理的需求。于是，我们小组选择开发一个操作便捷、存储简单、安全性高的超市管理系统。
采用一个超市管理系统可以相应地提高超市的运作效率，通过全面的信息采集和处理辅助提高超市的决策水平，迅速提高超市的管理水平会降低超市的经营成本、从而达到提高效益、增强超市扩张力的目的。
1.2. 项目定义与用户期望
1.2.1. 项目定义
“Jupiter”超市管理系统是基于对市场的调研而开发，针对超市的员工和管理层人员而设计，主要为他们提供方便快捷的服务。管理人员可以在线对员工和信息进行管理，并且能够对不同员工进行不同的权限的设置；财务部员工可以对员工的工资进行管理，并且能够生成月工资的结算报表，使得管理层人员能够一目了然的了解到情况；人事部员工能够对各个员工信息进行管理，并且能够在不同的部门下设置不同的职位，同时也将能查看各个员工的绩效考核；营销部的员工能够查看销售的统计报表，管理商品的销售情况，并且设置回收站防止员工误删重要信息；物流部员工能够对商品信息进行管理，还能对仓库中的商品进行管理，包括商品的出库、入库、上架、下架等，同时设立了监督机制，防止商品的丢失；客服部员工能够对顾客的信息进行管理，也能够管理退换货的商品。
项目组根据需求分析、可行性分析将系统分为前端管理和后端管理两大服务平台。
1.2.1. 前端管理
前端管理服务于营销部员工、物流部员工、客服部员工，包括商品销售管理、销售统计管理、商品信息管理、商品库存管理、商品退换管理、顾客信息管理等。
营销部员工能够通过刷商品的条形码将商品销售出去，同时会生成销售单，供超市留底。除此之外，还能够对每种商品的周销售、月销售情况通过图表的形式展现出来，也能够查看即将售完的商品，供超市管理层对超市的进货需求作出及时的调整。同时也设置了回收站，使得员工能够恢复不小心删除的信息。
物流部的员工能够对商品的信息和商品供应商的信息进行管理，并且能够按照商品的属性和所属的仓库进行商品的查询，方便快捷的查找到自己所需要的商品信息。同时也能够对商品的上下架和出库入库进行管理，在这之中添加了监督机制，防止商品在运输过程中的丢失。
客服部员工主要能够在商品售出之后，对商品的退换货进行管理，并且提供在线的售后服务。
1.2.1. 后端管理
后端管理服务于人事部管理员、财务部管理员和管理层人员，包括员工管理、部门管理、工资管理、用户账号管理。
管理层人员能够对员工进行不同权限的分配，使得公司的分工明确，管理便捷。除此之外，管理层人员还能够对员工基本信息进行管理，但是对各个员工的密码进行了加密设置，使得员工的私密得到了保障。
人事部管理人员能够对员工的信息和部门信息进行管理，并且能在不同的部门下添设不同的职位，让公司管理变得更加的有效率，能够及时的对职位进行调整。同时还设置了绩效考核，对员工的出勤率进行记录，在结算奖金的时候进行相应的计算，使得公司内部管理更加公平、透明。
财务部管理人员能够对公司各个员工的工资进行结算，主要是基本工资以及提成的的计算，同时能将各个部门的员工的工资总额计算出来，让公司的管理层人员能够了解情况。
2. 总体设计
2.1. 项目功能性分析
“Jupiter”超市管理系统根据用户需求，将系统分为前端管理和后端管理两大服务平台。前端管理主要为营销部员工、物流部员工、客服部员工提供了商品销售管理、销售统计管理、商品信息管理、商品库存管理、商品退换管理、顾客信息管理等功能；后端管理主要为人事部管理员、财务部管理员和管理层人员提供了员工管理、部门管理、工资管理、用户账号管理等功能。系统功能图如图所示：
2.1.1. 前端管理模块
描述：前端管理模块主要包括商品销售管理、销售统计、销售单管理、商品信息管理、商品管理、库存管理、顾客管理等，界面简洁，易上手。前端管理模块功能结构图如图所示：
营销部员工
描述：主要负责商品的出售和销售的统计。
营销部员工用例图
营销部员工序列图
物流部员工
描述：主要负责仓库中商品的管理，包括出库、入库、上架、下架。
物流部员工用例图
物流部员工序列图
客服部员工
描述：主要负责商品出售后的售后服务，商品的退换货等。
客服部员工用例图
客服部员工序列图
2.1.2. 后端管理模块
描述：后端管理模块主要包括员工管理、部门管理、绩效考核、工资管理、收支结算、账号管理等模块，操作简单。后端管理模块功能结构图如图所示：
超级管理员
描述：拥有最高权限，能进行多种操作，主要是给各个员工分配权限。
超级管理员用例图
超级管理员序列图
人事部管理员
描述：主要是对员工和部门的管理，包括员工信息和部门信息的管理。
人事部管理员用例图
人事部管理员序列图
财务部管理员
描述：主要是管理公司财务这一方面，包括工资和公司的收支总结。
财务部管理员用例图
财务部管理员序列图
3. 数据库设计
3.1. 数据库概念设计
数据库概念设计图
3.2. 数据库逻辑设计
数据库逻辑设计图
3.1. 数据库物理设计
部门表：department
| 部门信息 | 定义变量 | 数据类型 | 约束 |
|---|---|---|---|
| 部门id(随机10int) | department_id | varchar2(10) | primary key |
| 部门名称 | department_name | varchar2(30) | not null |
| 部门主管 | manager_id | varchar2(32) | default:空 |
| 部门描述 | department_descr | varchar2(200) | default:空 |
说明：
部门id作为主键
职位表：job
| 职位信息 | 定义变量 | 数据类型 | 约束 |
|---|---|---|---|
| 职位id(随机10int) | job_id | varchar2(10) | primary key |
| 职位名称 | job_name | varvhar2(30) | not null |
| 基本工资 | base_salary | number(8,2) | not null |
| 提成 | commission_rate | number(3,2) | default:0.00 |
| 职位描述 | job_descr | varchar2(200) | default:空 |
| 所属部门 | department_id | varchar2(10) | foreign key |
说明：
职位id作为主键，每个部门对应着不同的职位信息
员工账号表：accounts
| 员工账号 | 定义变量 | 数据类型 | 约束 |
|---|---|---|---|
| 账号id（随机10char） | account_id | varchar2(10) | primary key |
| 用户名 | username | varchar2(20) | unique |
| 密码 | password | varchar2(20) | defalut:000000 |
| 用户权限 | limits | number(3) | default:0 |
说明：
账号id作为主键，每个部门的员工均只能对应一个账号（在录入员工的时候生成对应编号的账号信息，账号名默认为员工编号，密码默认为000000），不同部门的员工拥有不同的权限
员工表:employee
| 员工信息 | 定义变量 | 数据类型 | 约束 |
|---|---|---|---|
| Id（随机32char） | employee_id | varchar2(32) | primary key |
| 员工编号（自定义10int） | employee_num | varchar2(10) | unique |
| 姓名 | employee_name | varvhar2(20) | not null |
| 身份证号 | id_card | varchar2(20) | not null |
| 年龄 | age | number(3) | check |
| 性别 | gender | varvhar2(4) | check |
| 联系方式 | phone | varvhar2(20) | not null |
| 邮箱 | varvhar2(30) | default:空 | |
| 住址 | address | varchar2(30) | default:空 |
| 雇佣日期（入职日期） | hire_date | date | default:当前系统时间 |
| 账号id（随机10char） | account_id | varchar2(10) | foreign key |
| 职位id | job_id | varchar2(10) | foreign key |
| 部门id | department_id | varchar2(10) | foreign key |
说明：
员工id作为主键，每个员工拥有属于自己的基本信息，且有相应的员工账号、部门、职位信息，不同的员工有着不同的管理权限
考勤表：checking
| 考勤信息 | 定义变量 | 数据类型 | 约束 |
|---|---|---|---|
| 流水号（自定义10int） | flow_id | varchar2(10) | primary key |
| 打卡员工 | employee_id | varchar2(32) | foreign key |
| 打卡时间 | start_time | date | default:当前系统时间 |
| 下班时间 | end_time | date | default:当前系统时间 |
| 考勤状态 | check_state | number(1) | check、default:0 |
说明：
流水号作为主键（此处由于员工考勤具有时间属性作为参考，可以考虑不设置主键），每个员工在登录点击打卡或者是选择下机之后会自动记录相应的时间信息作为考勤记录
商品单位表：units
| 单位信息 | 定义变量 | 数据类型 | 约束 |
|---|---|---|---|
| 单位id（随机10char） | units_id | varchar2(10) | primary key |
| 单位名称 | units_name | varchar2(20) | not null |
| 删除标识 | delete_flag | number(1) | check、default:0 |
说明：
单位id作为主键，标识不同的商品拥有不同的规格、单位、计量标准，此处考虑到详细的内容，但涉及具体的设计还是要参考实际情况进行分析
商品分类表：category
| 分类信息 | 定义变量 | 数据类型 | 约束 |
|---|---|---|---|
| 分类id（随机10char） | category_id | varchar2(10) | primary key |
| 分类名称 | category_name | varchar2(20) | not null |
| 删除标识 | delete_flag | number(1) | check、default:0 |
说明：
分类id作为主键，标识不同的商品拥有不同的分类，此处简单地进行分类，随着之后技术的成熟可以考虑通过设计相应的算法真正实现“智能分类”（根据商品的不同属性提供不同的分类标准）
仓库表：warehouse
| 商品信息 | 定义变量 | 数据类型 | 约束 |
|---|---|---|---|
| 仓库ID（随机10char） | warehouse_id | varchar2(10) | primary key |
| 仓库名称 | warehouse_name | varchar2(20) | not null |
| 删除标识 | delete_flag | number(1) | check、default:0 |
说明：
仓库id作为主键，标识不同的商品存储在相应的仓库，可尝试着通过对不同的分类进行判断，将其存储在对应的仓库中，从而实现智能选择
供应商表：vendor
| 供应商信息 | 定义变量 | 数据类型 | 约束 |
|---|---|---|---|
| 供应商ID（随机32char） | vendor_id | varchar2(32) | primary key |
| 供应商名称 | vendor_name | varchar2(50) | not null |
| 联系方式 | vendor_phone | varchar2(20) | default:空 |
| 邮箱 | vendor_email | varchar2(20) | default:空 |
| 传真 | vendor_fax | varchar2(20) | default:空 |
| 供应商位址 | vendor_address | varchar2(30) | default:空 |
说明：
供应商id作为主键，拥有供应商的相关信息，由物流部的仓库管理人员与其进行交接，实现商品的进购和退换
供应商联系人表：vendor_contact
| 供应商联系人信息 | 定义变量 | 数据类型 | 约束 |
|---|---|---|---|
| 供应商联系人ID（随机32char） | contact_id | varchar2(32) | primary key |
| 供应商联系人名称 | contact_name | varchar2(20) | not null |
| 联系方式 | contact_phone | varchar2(20) | not null |
| 邮箱 | contact_email | varchar2(20) | not null |
| 所属供应商id | vendor_id | varchar2(32) | foreign key |
| 身份标识（是否为负责人） | owner_flag | number(1) | check、default:0 |
说明：
供应商联系人id作为主键，用于标识不同的供应商可拥有一个或者是多个联系人，还可通过不同的身份信息对联系人进行标识，初次创建供应商联系人默认为0,如果身份标识为0则视为普通的联系人，如果身份标识为1则视为主要的负责人
商品表：product
| 商品信息 | 定义变量 | 数据类型 | 约束 |
|---|---|---|---|
| 商品id（随机32char） | prod_id | varchar2(32) | primary key |
| 条形码（随机10int） | flow_id | varchar2(10) | unique |
| 商品名称 | prod_name | varchar2(30) | not null |
| 商品成本 | prod_cost | number(10,2) | default:0.00 |
| 商品售价 | prod_price | number(10,2) | default:0.00 |
| 已上架商品库存 | putaway_stock | number(10) | default:0 |
| 商品当前仓库库存 | current_stock | number(10) | default:0 |
| 商品安全库存 | safe_stock | number(10) | default:0 |
| 商品单位 | prod_unit | varchar2(10) | foreign key |
| 商品产地 | prod_origin | varchar2(30) | not null |
| 生产日期 | prod_date | date | not null |
| 商品描述 | prod_descr | varchar2(100) | default:空 |
| 商品折扣 | prod_discount | number(3,2) | default:1.00 |
| 促销标识 | promotion_flag | number(1) | check、default:0 |
| 促销价格 | promotion_price | number(10,2) | default:0.00 |
| 删除标识 | delete_flag | number(1) | check、default:0 |
| 商品分类id | category_id | varchar2(10) | foreign key |
| 供应商id | vendor_id | varchar2(32) | foreign key |
| 仓库id | warehouse_id | varchar2(10) | foreign key |
说明：
商品id作为主键，与此同时，还有相应的“条形码”用以唯一标识商品信息，此外拥有商品的各种基本信息，此外还包括商品相应的单位、分类、存储位置、供应商等信息
入库主表（进货）/出库主表（处理商品）：stock_master
| 出入库信息 | 定义变量 | 数据类型 | 约束 |
|---|---|---|---|
| 出入库订单id(随机32char) | stock_master_id | varchar2(32) | primary key |
| 订单编号（自增10int） | order_num | varchar2(10) | unique |
| 经手人id | handler_id | varchar2(32) | foreign key |
| 负责人id | contact_id | varchar2(32) | default:空 |
| 处理时间/退货时间 | handle_time | date | default:当前系统时间 |
| 标志 | sign | number(1) | check |
| 删除标识 | delete_flag | number(1) | check、default:0 |
| 订单状态 | state | number(1) | check、default:0 |
说明：
出入库主表id作为主键，有相应的订单编号作为简单标识，每条订单对应着相应的处理者、处理时间、供应商以及相应的负责人，此外还定义了sign标识用以判断当前订单属于出库还是入库。
此处出库、入库涉及两个概念：一方面是仓库管理员相对于供应商进行入库（进购商品）和出库（商品退货）管理另一方面是商品理货员进行商品的上架、下架管理（此处直接进行操作，没有作记录）
1.仓库管理员：商品出库、入库管理（对商品的当前库存进行管理）
入库：商品入库（如果商品信息存在则更新商品库存，如果商品信息不存在则完善商品信息）
出库：入库商品退货处理（对应负责人为供应商联系人）
2.超市理货员：商品上架、下架管理由理货员进行商品上架管理、下架管理（对商品的当前库存、上架库存进行管理）
商品上架：自定义规则：商品上架数目为0默认为商品尚未上架商品下架：如果理货员在管理的过程中发现商品过期则进行下架处理此外，此处引入流程监督机制，在出入库中添加相应的标识state用以表示当前订单的处理状态：
0表示当前订单处理中（审核中）
1表示当前订单通过审核可以执行相应的出库入库操作
-1表示当前订单未通过审核，可以再次通过提交进行处理，也可通过删除进行取消不同级别的物流部员工拥有不同地对订单处理权限
入库明细表（进货）/出库明细表（处理商品）：stock_order
| 出入库信息 | 定义变量 | 数据类型 | 约束 |
|---|---|---|---|
| 出入库订单id | stock_master_id | varchar2(32) | foreign key |
| 产品id | product_id | varchar2(32) | foreign key |
| 处理数量 | quantity | number(10) | not null |
| 处理单价 | unit_price | number(8,2) | not null |
| 处理金额 | amount | number(8,2) | not null |
| 删除标识 | delete_flag | number(1) | check |
| 说明：此处设计出入库订单明细表用以详细列举不同的出入库订单主表对应不同的明细 |
采购记录表：puchase_note
| 采购记录 | 定义变量 | 数据类型 | 约束 |
|---|---|---|---|
| 订单编号 | order_num | varchar2(10) | foreign key |
| 实付金额 | actual_amount | number(8,2) | / |
| 支付方式 | payment | number(1) | / |
说明：
此处采购记录表用以记录、统计采购单的总额，最后用以财务部汇总、总计
顾客消费等级表：consume_class
| 等级 | 定义变量 | 数据类型 | 约束 |
|---|---|---|---|
| 等级 | class_id | number(1) | primary key |
| 等级名称 | class_name | varchar2(20) | not null |
| 优惠 | class_off | number(4) | not null |
| 折扣 | class_discount | number(3,2) | not null |
说明：
顾客消费等级id作为主键，用于标识不同的顾客拥有不同的消费等级，不同的消费等级对应着不同的优惠模式对于消费对象为商家或者是公司等大量消费的顾客处理，采用的是会员制，相应的由商家或公司负责人（代表）进行交互，相应的如果办卡的话则有相应的优惠5个等级消费制度
1.尊享卡--100--0.02
2.钻石卡--100--0.02
3.铂金卡--50--0.01
4.黄金卡--30--0.01
5.普通卡--20--0.00
在结算的时候如果是会员则按照会员享有的专属优惠进行打折，如果折后的价格满1000则按照相应的满减优惠进行部分减免
顾客表:customer
| 顾客信息 | 定义变量 | 数据类型 | 约束 |
|---|---|---|---|
| 顾客id（随机32char） | customer_id | varchar2(32) | primary key |
| 名称 | customer_name | varchar2(50) | not null |
| 地址 | customer_address | varchar2(30) | default:空 |
| 联系方式 | customer_phone | varchar2(30) | not null |
| 邮箱 | customer_email | varchar2(30) | default:空 |
| 积分 | integrate | number(10) | default:0 |
| 余额 | balance | number(10,2) | default:0 |
| 等级id | class_id | number(1) | foreign key |
说明：
顾客id作为主键，拥有基本的顾客信息和相应的积分卡的信息
销售主表：sale_master
| 销售信息 | 定义变量 | 数据类型 | 约束 |
|---|---|---|---|
| 销售记录id（随机32char） | sale_master_id | varchar2(32) | primary key |
| 订单编号（自增10int） | order_num | varchar2(10) | unique |
| 经手人id | handler_id | varchar2(32) | foreign key |
| 顾客id | customer_id | varchar2(32) | foreign key |
| 销售时间/退货时间 | handle_time | date | default:当前系统时间 |
| 删除标识 | del_flag | number(1) | check、default:0 |
| 订单状态 | state | number(1) | check、default:0 |
说明：
销售主表id作为主键，相应的拥有订单编号作为简单标识，每条销售订单有相应的售货员、销售时间、顾客等信息，在销售的过程中可以考虑如果顾客信息不存在，则提示是否要办相应的会员进行积分，如果选择不办会员默认是不需要存储该顾客信息，只需要记录相应的销售明细即可
销售明细表：sale_order
| 出入库信息 | 定义变量 | 数据类型 | 约束 |
|---|---|---|---|
| 销售记录id | sale_master_id | varchar2(32) | foreign key |
| 产品id | product_id | varchar2(32) | foreign key |
| 处理数量 | quantity | number(10) | not null |
| 处理单价 | unit_price | number(8,2) | not null |
| 处理金额 | amount | number(8,2) | not null |
| 删除标识 | delte_flag | number(1) | Check |
说明：
此处设计销售订单明细表用以详细列举不同的销售订单主表对应不同的明细
销售记录表：sale_note
| 采购记录 | 定义变量 | 数据类型 | 约束 |
|---|---|---|---|
| 订单编号 | order_num | varchar2(10) | foreign key |
| 实付金额 | actual_amount | number(8,2) | / |
| 支付方式 | payment | number(1) | / |
说明：
此处销售记录表用以记录、统计销售单的总额，最后用以财务部汇总、总计
4. 程序模块设计
4.1. 登录模块
描述：系统登录模块主要分为前台登录和后台登录，通过设置不同的用户权限，每个部门的员工只能操作相应部门的功能模块，此处设置超级管理员拥有绝对权限，可以进入任何一个模块进行功能的调试和分析。
4.1.1. 前台登录模块
描述：只有所属部门为营销部、物流部、客服部的员工能够通过前台登录进入到相应的模块。同时超级管理员可以通过前台登录进入到相应的模块进行功能测试等（超级管理员可隶属于系统维修部）。