产品销售管理系统

总结了好久以前 2015年10月份 的数据库课程设计,重点放在数据库依照范式的建表过程。

功能性需求分析

  1. 商品管理功能
    • 商品种类设置
    • 商品余量设置
    • 商品回收情况
    • 商品销售情况
  2. 客户管理功能
    • 完善客户信息
    • 用户账户管理
    • 用户信用评级
  3. 销售管理功能
    • 报价管理
    • 订单管理
    • 收款管理
    • 退单申请
  4. 决策管理功能
    • 权限管理
    • 库存查询
    • 销售汇总

概念结构设计(E-R模型)

概念结构设计

数据库的建表过程

该管理系统最主要的形式为订单,由订单出发:

销售报表

该销售报表内容有:

  • 销售报表(报表编号、日期、客户编号、客户名、商品编号、商品名称、单价、数量)

第一范式

第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。因此,使用第一范式,将关系上述关系进行规范化,分割为销售表和销售明细表:

  • 销售表-1 (报表编号、日期、客户编号、客户名称)
  • 销售明细表-1 (报表编号、商品编号、商品名称、单价、数量)

第二范式

第二范式(2NF)是数据库规范化中所使用的一种正规形式。它的规则是要求数据表里的所有数据都要和该数据表的主键有完全依赖关系;如果有哪些数据只和主键的一部份有关的话,它就不符合第二范式。因此可知在第一范式生成的 销售明细表-1 并不符合第二范式,再次将其分割,得出商品表和销售明细表:

  • 商品表 (商品编号、商品名称、单价)
  • 销售明细表 (报表编号、商品编号、数量)

第三范式

第三范式(3NF)规定,每个非关键字列都独立于其他非关键字列,并依赖于关键字,即数据库中不能存在传递函数依赖关系。而第一范式生成的 销售表-1 中明显有销售与客户的依赖关系,则应将其分割,得出销售表和客户表:

  • 销售表 (报表编号、日期、客户编号)
  • 客户表 (客户编号、客户名称)

主键确立

  • 商品表商品编号、商品名称、单价)
  • 客户表客户编号、客户名称)
  • 销售表报表编号、日期、客户编号)
  • 销售明细表报表编号商品编号、数量)

报价问题

由于销售管理子系统可进行报价管理,因为修改价格涉及到退单退款问题。因此在销售明细表加入下单时商品单价的数据项。

  • 销售明细表报表编号商品编号、数量、下单时单价)

退单问题

由于该销售管理系统可进行退单操作,涉及到货物与金额问题。于是在销售表加入三个布尔数据项:pay、goods、order,它们组成的位图可表示为:

Pay Goods Order 状态
0 0 0 未下单未付款未发货 ×
0 1 0 未下单未付款已发货 √
1 0 0 未下单已付款未发货 ×
1 1 0 未下单已付款已发货 ×
0 0 1 已下单未付款未发货 √
0 1 1 已下单未付款已发货 ×
1 0 1 已下单已付款未发货 √
1 1 1 已下单已付款已发货 √

删除冗余项,修改部分逻辑意义,可表示为:

Pay Goods Order 状态
0 1 0 未付款已发货,订单未完成
0 0 1 退单完成状态
1 0 1 退单商品未退回
1 1 1 订单完成状态

权限问题

将各个表单操作以及系统权限分发给各个不同的管理员,需要建立权限表进行功能管理分配,可得:

  • 权限表账户编号、账户名称、账户密码、权限、备注)

最终结果

  • 权限表账户编号、账户名称、账户密码、权限、备注)
  • 商品表商品编号、商品名称、商品价格、商品产地、库存数量、备注)
  • 客户表客户编号、客户名称、客户地址、客户电话、信用状态、预付款、备注)
  • 销售表报表编号、日期、客户编号、付款情况、货物情况、订单状态、备注)
  • 销售明细表报表编号商品编号、购买数量、下单时的价格)

系统功能实现

框架目录

www WEB部署目录(或者子目录)
├─index.php 入口文件
├─README.md README文件
├─composer.json Composer定义文件
├─App 应用目录
├─Runtime 运行缓存目录
├─Public 资源文件目录
└─ThinkPHP 框架目录

应用目录

App 默认应用目录
├─Common 公共模块(不能直接访问)
├─Home 主体模块
│ ├─Conf 配置文件目录
│ ├─Common 公共函数目录
│ ├─Controller 控制器目录
│ │ ├─IndexController.class.php 前台控制器
│ │ ├─AdminController.class.php 后台控制器
│ │ ├─SmscoController.class.php 商品前台控制器
│ │ ├─SmscuController.class.php 客户前台控制器
│ │ ├─SmssaController.class.php 销售前台控制器
│ │ ├─UserController.class.php 权限管理控制器
│ │ ├─CustomerController.class.php 客户后台控制器
│ │ ├─ProductController.class.php 商品后台控制器
│ └───SalesController.class.php 销售后台控制器
│ ├─Model 模型目录
│ │ ├─CustomerModel.class.php D函数客户模型
│ │ ├─ProductModel.class.php D函数产品模型
│ └───UserModel.class.php D函数权限模型
│ └─View 视图目录
│ │ ├─Public 公共目录
│ │ ├─Index 前台目录
│ │ ├─Admin 后台目录
│ │ ├─Smsco 商品管理目录
│ │ ├─Smscu 客户管理目录
│ │ ├─Smssa 销售管理目录
└─└─└─layout.html 布局模板

总结

该项目使用了ThinkPHP3.2.3作为后端框架,MySQL作为数据库,并且使用Pure作为前端框架。实现的过程中学新的后端框架就像学一门新的语言,但正因为是框架的原因学起来非常快,且对于数据库操作,MVC模式都有特定的类、函数、规范,因此省去了很多冗余的代码来实现这个项目。
但这个系统还是有几个不足:一是没有进行过大量的压力测试。二是没有使用上信用问题,仅仅当信用为差时不可下订单而已。

具体代码见:https://coding.net/u/gcusky/p/psms/git

文章目录
  1. 1. 功能性需求分析
  2. 2. 概念结构设计(E-R模型)
  3. 3. 数据库的建表过程
    1. 3.1. 第一范式
    2. 3.2. 第二范式
    3. 3.3. 第三范式
    4. 3.4. 主键确立
    5. 3.5. 报价问题
    6. 3.6. 退单问题
    7. 3.7. 权限问题
    8. 3.8. 最终结果
  4. 4. 系统功能实现
    1. 4.1. 框架目录
    2. 4.2. 应用目录
  5. 5. 总结

20170116-project-1/

本页二维码