商品销售管理系统.doc

本科学生综合性实验报告

课程名称：数据库系统原理

数据库设计

姓 名 刘贵军 学 号 0082641
班 级 选课B01班
项目名称 商品销售管理系统设计
指导教师 吴京慧教授
开课学期 2010 至 2011 学年 第一 学期
完成时间 2010 年 12 月 日

目录
1 需求分析 2
1.1 系统目标 2
1.2 业务需求及处理流程 3
1.3 功能需求及数据需求分析 5
1.4 业务规则分析 7
2 概念设计 9
2.1 命名规范 9
2.2 实体集及属性 9
2.3 联系集及属性 11
2.4 系统总ER图 12
3 逻辑设计 13
3.1 数据字典设计 13
3.2 基本数据设计 14
3.3 业务数据设计 15
3.4 其它数据设计 17
3.5 视图设计 18
3.6 触发器设计 18
3.7 存储过程设计 19
4 模式求精 20
4.1 存在的问题 20
4.2 解决方案 20
5 物理设计 21
5.1 设计目标 21
5.2 数据分布 21
5.3 索引实现 21
6 安全设计 23
6.1 设计目标 23
6.2 用户设计 23
6.3 权限设计 23
7 附录1 数据库脚本 25
8 附录2 视图、触发器、存储过程和索引 34

1 需求分析
1.1 系统目标
近年来国际上，计算机在教育领域作为工具应用的一大发展，是作为教学过程中一种有效的认知工具。随着市场经济的不断发展和商品销售企业的发展将企业推向了峰尖浪口。 商品销售管理系统(CSMS,Commodity Sell Manage System )是处于生产层和供应层之后的管理系统，主要负责商品销售和供应协调。
销售管理是企业管理的一个重要管理环节，它的特点是信息量大，要求信息反馈迅速，对企业经济效益能够产生直接的影响。同时，它与他的其他管理环节如库存管理﹑销售账务管理等关系十分密切。采用传统的手工管理模式，其工作效率﹑管理质量和管理水平已不能满足当今经营管理发展的要求，也无法和国外的企业进行竞争。只有采用先进的计算机管理技术，把一些科学管理的技术及管理方式融入到企业销售管理中，才能提高工作效率和企业的管理水平，使企业能够随着市场的动态变化而随时调整自身的销售业务流程，在瞬息万变的市场竞争中脱颖而出。
鉴于这种需求，开发本系统，根据企业实际运营情况，设计出合理的解决方案，在业务与管理之间、产品与客户之间建立很好的信息共享渠道，提高企业运营效率；还有专门针对销售企业的日常事务管理，集合了进、销、存和退位一体的管理。本系统主要用于存储客户、商品信息以及销售记录，以便能够实时地进行订单跟踪、销售结算、库存管理和商品推荐，最大限度的实现商品销售管理的科学化、系统化和自动化。
1.2 业务需求及处理流程
根据本系统的系统目标，商品销售信息管理的主要业务包括：商品入库、商品出库、用户定购商品、处理订单、商品信息查询和浏览、订单跟踪、销售结算和商品推荐、退单管理、利润管理等。其中主要的业务是商品入库、商品出库和退单管理。处理流程如下：

1) 商品入库业务流程图如图1-1所示：
是否有入库单？
合格？
开出发票
财务结算
商品入库
Y
N
Y
N
商品验收

图 1-1商品入库

2): 订单处理业务流程图如图1-2所示：
N
财务结算
开出发票
商品出库
是否有订单？
Y

图 1-2 订单处理

3): 退单处理业务流程图如图1-3所示：
验收退单
是否有退单？
合格？
订单处理
财务结算
退还现金
N
Y
Y
N

图 1-3 退单处理

1.3 功能需求及数据需求分析
商品销售管理系统总的系统功能模块如图1-4所示：
商品销售管理系统
基本信息管理
业务信息管理
库存信息管理
销售信息管理
商品添加、删除及修改管理
报表生成及分析
出库信息管理
入库信息管理
财 务 结 算
退 单 处 理
订 单 处 理
商品查询及推荐
商品信息处理
供货商信息管理
职员信息管理
会员用户信息管理
发票信息管理

图 1-4商品销售系统功能模块

1): 基本信息管理
(1): 商品信息管理。商品信息管理主要是记录商品的基本信息。商品的基本信息分为商品主信息和明细信息。主信息包括商品编号、商品名称、商品类别、商品热门度、商品总数量、商品剩余数量、销售价格等；明细信息包括商品编号、商品序列号等。
(2): 供货商信息管理。供货商信息管理主要是记录各个供货商的基本信息，包括：供货商编号、名称、地址、联系电话、电子邮箱等。
(3): 职员信息管理。职员信息管理主要是记录每个职员在任职期间的基本信息，包括：职员编号、系统登录密码、姓名、性别、出生年月、住址、联系电话、电子邮箱、雇佣日期、所在部门、任职职务、月薪等。
(4): 会员用户信息管理。会员用户信息管理主要是提供用户更方便的服务，主要信息包括：用户登录账号、登录密码、姓名、性别、出生年月、住址、联系电话、电子邮箱等。
(5): 发票信息管理。发票信息管理主要使用来提供有保障的售后服务，主要信息包括：发票编号、发票类型、发票金额等。

2): 业务信息管理
(1): 退单处理。退单处理业务主要是给用户提供更有保障的售后服务。售后服务人员根据用户所提供的退单进行核实，如果确实属实，则查找已经受理完的订单，销毁该订单，并退还用户金额。受理完后进行财务结算。
(2): 订单处理。订单处理主要是给用户提供更方便、快捷的购物服务。用户可以浏览商品来选择要购买的商品，也可以根据系统提供的各种查询通道查询要购买的商品。销售员根据用户订购的商品进行受理，开出发票，库存管理人员根据订单发票准备用户所订购的商品，并进行商品出库。最后进行财务结算。
(3): 商品的查询和推荐。商品的查询主要是提供给用户更快捷的查询商品的通道。用户可以根据商品的信息来查询所需要的商品，而职员也可以方便的查询要处理的商品；商品的推荐主要是根据商品的热门度和商品的购买量来进行商品甄别，并将有价值的商品推荐给用户。

3): 库存信息管理
(1): 入库管理。入库管理主要是根据供货商提供的物品进行验收，并按照仓库存放的商品类别进行商品入库。
(2): 出库管理。库存管理人员根据销售人员开出的订单发票准备订单中的商品并进行商品出库。
(3): 商品的添加、删除和修改。库存管理人员根据进货员提供的发票上的商品信息进行商品的入库，在添加商品时，库存管理人员只需要扫描商品的编号，如果该编号不存在，则手动输入该商品的其他信息，否则不需要任何手工操作；库存管理人员可以通过输入商品的编号、名称等信息或者组合信息进行对商品的选择性删除；库存管理人员可以通过输入商品的编号、名称等信息或者组合信息进行对商品的修改。

4): 销售结算管理
(1): 财务结算。财务人员根据商品入库业务数据和商品订单业务数据来设定结算的时期，计算机自动地对这一段时期计算进货总金额、销售总金额和利润结算；还可以统计各销售员的销售总金额。
(2): 报表生成和决策分析。计算机根据计算出来的各种财务数据生成各种财务报表，同时对各种商品进行决策分析，为用户推荐商品。
1.4 业务规则分析
业务规则分析主要是分析数据之间的约束以及数据库约束。基于上述功能需求，通过进一步了解，商品销售信息系统业务规则如下：
1): 所有客户均可以查询和浏览商品的信息。商品的编号编码规则为：商品标志+六位数字。如：’G000000’(注：’G’表示商品标志)。
2): 职员注册时，职员的员工号是通过计算机自动生成的，是职员的唯一标识。职员的员工号是职工表的唯一标识。员工号由系统按时间顺序生成，后生成的具有更大的员工号。职员编号编码规则为：职员标志+八位数字。如：’E00000000’(注：’E’表示商品标志)。
3): 会员用户注册时，会员用户的账号是通过计算机自动生成的，一个会员用户可以注册多个账号。会员用户的账号是用户表的唯一标识。用户账号由系统按时间顺序生成，后生成的具有更大的用户编号。会员用户编号编码规则为：会员用户标志+八位数字。如：’C00000000’ (注：’C’表示商品标志)。
4): 供货商编号的编码规则为：供货商标志+八位数字。如：’S00000000’(注：’S’表示供货商标志)。
5): 仓库编号的编码规则为：仓库标志+八位数字。如：’H00000000’(注：’H’表示仓库标志)。
6): 登陆系统时，职员通过员工号和设定的密码登陆系统，会员用户通过会员用户编号和密码登陆系统。
7): 订单编号是订单主表的唯一标识。订单编号由系统按时间顺序生成，后生成的订单具有更大的订单号。
8): 每张入库单和订单对应一张发票。发票编号是由税务局同意制定的。
9): 一种商品可以有多个供应商提供，一个供应商可以提供多种商品。
10): 一个销售员能受理多个订单，但一个订单只能被一个销售员受理。
11): 订单生成、商品入库、商品出库、发票生成和财务结算这五个过程是实时的，原子性的。生成一个订单，马上根据订单主表和订单明细表生成发票，再根据发票修改入库主表、入库明细表、出库主表和出库明细表，同时财务人员根据订单主表进行销售结算。
12): 会员用户可以凭会员卡享受一定的优惠。用户注册最初是零级VIP会员用户，不能享受任何优惠；当历史购买的总金额超过1000元，会员等级变为一级VIP会员，可享受9.5折优惠；当历史购买的总金额超过5000元，会员等级变为二级VIP会员，可享受9折优惠；当历史购买的总金额超过10000元，会员等级编程一级VIP会员，可享受8.5折优惠。会员等级最高为三级。
13): 订单生成后，用户不能再对订单进行添加、修改或删除。只有在退单检测正确时才能对订单进行添加、修改或删除。
14): 当库存的某种商品的数量少于某个阀值时，系统会自发出提示或者警报来提示数据库管理者进行补货。
15): 入库主表、入库明细表、出库主表和出库明细表的唯一标识是商品编号。
16): 只有在某个客户选定的商品都添加到了订单中，才能最后生成一张订单。
17): 当客户选定的商品的数量超过该库存商品的数量时，系统提示该信息，并禁止客户选择该商品。

2 概念设计
2.1 命名规范
概念设计中涉及到联系集和实体集。在我的商品销售管理系统中，一致将实体集的名称定义为与该实体集意义相关的名词，将联系集的名称定义为与该实体集意义相关的动词。每个单词的第一个字母大写，其后为小写(如：GoodsMaster)。将实体集或者联系集中包含的属性定义为与该属性意义相关的名词。每个名词的第一个单词首字母小写，第二、第三等之后的单词首字母大写(如：employeeTime)。
2.2 实体集及属性
根据以上命名规范的原则，各实体集的定义、属性和E-R图分别设计如下：
(1) 职员(Employee)实体集。其属性有：职员编号(employeeNo)、职员登录密码(employeePasswd)、姓名(employeeName)、性别(employeeSex)、出生年月(employeeBirthday)、住址(employeeAddress)、联系电话(employeeTel)、电子邮箱(employeeEmail)、雇佣时间(employeeTime)、部门(department)、职务(title)、薪水(salary)等。职员实体集的E-R图如图2-1所示：
职员
电子邮箱
密码
住址
联系电话
姓名
部门
出生年月月
性别
职务
编号
月薪
雇佣时间

图 2-1 职员实体集的E-R图

(2) 会员用户(Customer)实体集。其属性有：账号(customerNo)、用户登录密码(customerPasswd)、姓名(customerName)、性别(customerSex)、会员等级(class)、出生年月(customerBirthday)、住址(customerAddress)、联系电话(customerTel)、电子邮箱(customerEmail)等。会员用户实体集的E-R图如图2-2所示：
会员用户
电子邮箱
密码
住址
联系电话
姓名
出生年月月
性别
账号
会员等级

图 2-2 会员用户实体集E-R图

(3) 供货商(Supplier)实体集。其属性有：供货商编号(supplierNo)、公司名称(supplierName)、公司住址(supplierAddress)、联系电话(supplierTel)、电子邮箱(supplierEmail)等。供货商实体集的E-R图如图2-3所示：
供货商
电子邮箱
住址
联系电话
名称
供应商编号

图 2-3 供货商实体集E-R图

(4) 库存商品(Goods)实体集。其属性有：商品编号(goodsNo)、商品名称(goodsName)、商品类别(goodsClass)、商品热门度(goodsHot)、商品总数量(goodsNum)、销售价格(salePrice)等。商品实体集的E-R图如图2-4所示：
商品
商品类别
商品热门度
商品数量
商品名称
商品编号
销售价格

图 2-4 库存商品实体集E-R图

(5) 仓库(WareHouse)实体集。其属性有：仓库编号(houseNo)、仓库容量(houseCapicity)、仓库描述(houseDescible)、仓库地址(houseAddress)等。仓库实体集的E-R图如图2-5所示：
仓库
仓库描述
仓库地址
仓库编号
仓库容量

图 2-5 仓库实体集E-R图
2.3 联系集及属性
根据上面设计得到的实体集，可确定如下联系集：
(1): 采购员、供货商和库存商品之间的“采购(Service)”联系集。他是多对多联系，其描述属性有：采购日期(buyTime)，成本价格(buyPrice)、采购数量(buyQuatity)等。
(2): 采购联系集、仓库管理员和仓库之间的“入库(Input)”联系集。他是多对多联系。其属性描述有：入库时间(inputTime)等。
(3): 销售员、会员用户和库存商品之间的“订购(Order)”联系集。他是多对多联系。其属性描述有：订购日期(orderTime)、销售价格(salePrice)、订单数量(orderQuatity)等。
(4): 订购联系集、仓库管理员和仓库之间的“出库(output)”联系集。他是多对多联系。其属性描述有：出库时间(outputTime)等。

2.4 系统总ER图
根据以上对实体集和联系集的设计得到了最终的完整的商品销售管理的E-R图如图2-8所示：
供货商
库存商品
职 员
会员用户
仓库
采购
入库
订购
出库
采购时间
订购时间
入库时间
出库时间
成本价格
采购数量
订购数量
销售价格

图 2-8 商品销售管理系统E-R图

3 逻辑设计
3.1 数据字典设计
数据库的重要部分是数据字典(Data dictionary)。它存放有数据库所用的有关信息，对用户来说是一组只读的表。本系统主要从以下几点来设计数据字典：
(1) 性别字典(DCSex)。其数据字典描述如图3-1所示：

属性名称
属性类型
是否允许为空
默认值
属性描述
sexNo
char(1)
否

性别编号
sexName
varchar(4)
是

性别名称
ifVoid
char(1)
是
0
是否有效
图 3-1 性别字典

(2) 所在部门字典(DCDpartment)。其数据字典描述如图3-2所示：

属性名称
属性类型
是否允许为空
默认值
属性描述
departmentNo
char(2)
否

部门编号
departmentName
varchar(8)
是

部门名称
ifVoid
char(1)
是
0
是否有效
图 3-2 所在部门字典

(3) 所任职务(DCHeadship)。其数据字典描述如图3-3所示：

属性名称
属性类型
是否允许为空
默认值
属性描述
headshipNo
char(2)
否

职务编号
headshipName
varchar(8)
是

职务名称
ifVoid
char(1)
是
0
是否有效
图 3-3 所任职务数据字典

(4) 商品热门度(DCGoodsHot)。其数据字典描述如图3-4所示：

属性名称
属性类型
是否允许为空
默认值
属性描述
goodsHotNo
char(1)
否

热门度编号
goodsHotName
varchar(8)
是

热门度名称
ifVoid
char(1)
是
0
是否有效
图 3-4 商品热门度字典

(5) 操作类型(DCClass)。其数据字典描述如图3-5所示：

属性名称
属性类型
是否允许为空
默认值
属性描述
classNo
char(2)
否

类型编号
className
char(10)
是

类型名称
ifVoid
char(1)
是
0
是否有效
图 3-5 操作类型数据字典

3.2 基本数据设计
通过上述的E-R图设计，得到了商品销售系统的基本数据，包括：职员(Employee)表、供货商(Supplier)表、会员客户(Customer)表、库存商品(Goods)表、仓库(WareHouse)表。

(1) 职员表：由职员强实体集转化而来，如图3-6所示：

属性名称
数据类型
是否为空
属性描述
employeeNo
char(9)
否
职员编号
employeePasswd
char(8)
否
职员登录密码
employeeName
varchar(12)
否
职员姓名
employeeSex
char(4)
否
职员性别
employeeBirthday
datetime
是
出生年月
employeeAddress
varchar(30)
否
职员住址
employeeTel
char(12)
是
联系电话
employeeEmail
varchar(20)
是
电子邮箱
employeeTime
datetime
否
雇佣时间
department
varchar(10)
是
所在部门
title
varchar(10)
是
现任职务
salary
smallInt
是
月薪
图 3-6职员表 Employee

(2) 会员用户表：由会员用户强实体集转化而来，如图3-7所示：

属性名称
数据类型
是否为空
属性描述
customerNo
char(9)
否
用户账号
customerPasswd
char(6)
否
用户登录密码
customerName
varchar(12)
否
用户姓名
customerSex
char(4)
是
用户性别
customerBirthday
datetime
是
出生年月
class
int
是
会员等级
customerAddress
varchar(30)
否
用户住址
customerTel
char(12)
是
联系电话
customerEmail
varchar(20)
是
电子邮箱
图 3-7会员用户表 Customer

(3) 供货商表：由供货商强实体集转化而来，如图3-8所示：

属性名称
数据类型
是否为空
属性描述
supplierNo
char(9)
否
供货商编号
supplierName
varchar(20)
否
公司名称
supplierAddress
varchar(30)
否
公司住址
supplierTel
char(12)
否
联系电话
supplierEmail
varchar(20)
是
电子邮箱
图 3-8 供货商表 Supplier

(4) 库存商品表：由库存商品实体集转化而来，如图3-9所示：

属性名称
数据类型
是否为空
属性描述
goodsNo
char(9)
否
商品编号
goodsName
varchar(20)
否
商品名称
goodsClass
varchar(12)
是
商品类别
goodsHot
char(4)
是
商品热门度
goodsNum
int
是
商品总数量
salePrice
numeric(7,2)
是
销售价格
houseNo
char(9)
否
仓库编号
图 3-9 商品主表 GoodsMaster

(5) 仓库表：由商品明细强实体集转化而来，如图3-10所示：

属性名称
数据类型
是否为空
属性描述
houseNo
char(9)
否
仓库编号
houseDescible
Text
是
仓库描述
houseAddress
varchar(30)
是
仓库地址
houseCapicity
int
是
仓库容量
图 3-10 仓库表 WareHouse
3.3 业务数据设计
通过上述的E-R图设计，得到了商品销售系统的业务数据，包括：采购主表(BuyMaster)、采购明细表(BuyDetail)、入库主表(InputMaster)、入库明细表(InputDetail)、订单主表(OrderMaster)、订单明细表(OrderDetail)、出库主表(OutputMaster)、出库明细表(OutputDetail)。

(1) 采购主表：由职员实体集和供货商实体集转化而来，由于供货商和职员之间是多对多联系，涉及到的主码太多，所以为采购主表定义一个主码：采购编号(buyNo)，如图3-11所示：

属性名称
数据类型
是否为空
属性描述
buyNo
char(9)
否
采购单编号
buySum
double
是
采购总金额
buyTime
datetime
否
采购时间
employeeNo
char(9)
否
职员标号
supplierNo
char(9)
否
供货商编号
图 3-11 采购主表 BuyMaster

(2) 采购明细表：由采购联系集和库存商品强实体集转换而来，如图3-12所示：

属性名称
数据类型
是否为空
属性描述
buyNo
char(9)
否
采购单编号
goodsNo
char(9)
否
商品编号
buyPrice
numeric(7,2)
是
成本价格
buyQuatity
int
是
采购数量
图 3-12 采购明细表 BuyDetail

(3) 入库主表：由采购联系集、职员实体集和仓库实体集转换而来，采购联系集、职员和仓库之间是多对多联系，涉及到的主码太多，所以为入库主表定义一个主码：入库编号(inputNo)，如图3-13所示：

属性名称
数据类型
是否为空
属性描述
inputNo
char(9)
否
入库编号
inputTime
datetime
否
入库时间
buyNo
char(9)
否
采购单编号
employeeNo
char(9)
否
职员标号
houseNo
char(9)
否
仓库编号
图 3-13 入库主表 InputMaster
(4) 入库明细表：由采购明细联系集和入库联系集转换而来，如图3-14所示：

属性名称
数据类型
是否为空
属性描述
inputNo
char(9)
否
入库编号
GoodsNo
char(9)
否
商品编号
inputQuatity
int
是
入库数量
图 3-14 入库明细表 InputDetail
(5) 订单主表：由职员实体集和会员用户实体集转化而来，由于职员和会员用户之间是多对多联系，涉及到的主码太多，所以为订单主表定义一个主码：订购单编号(orderNo)，如图3-15所示：

属性名称
数据类型
是否为空
属性描述
orderNo
char(9)
否
订单购编号
orderSum
numeric(9,2)
是
订单总金额
orderTime
datetime
否
订单时间
employeeNo
char(9)
否
职员标号
customerNo
char(9)
否
客户账号
图 3-15 订单主表 OrderMaster

(6) 订单明细表：由订单联系集和库存商品强实体集转换而来，如图3-16所示：

属性名称
数据类型
是否为空
属性描述
orderNo
char(9)
否
订单编号
GoodsNo
char(9)
否
商品编号
salePrice
numeric(7,2)
是
销售价格
orderQuatity
int
是
订单数量
图 3-16 订单明细表 OrderDetail
(7) 出库主表：由订购联系集、职员实体集和仓库实体集转换而来，采购联系集、职员和仓库之间是多对多联系，涉及到的主码太多，所以为入库主表定义一个主码：入库编号(outputNo)，如图3-17所示：

属性名称
数据类型
是否为空
属性描述
outputNo
char(9)
否
出库编号
outputTime
datetime
否
出库时间
orderNo
char(9)
否
订单编号
employeeNo
char(9)
否
职员标号
houseNo
char(9)
否
仓库编号
图 3-17 入库主表 InputMaster
(8) 出库明细表：由订购明细联系集和出库联系集转换而来，如图3-18所示：

属性名称
数据类型
是否为空
属性描述
outputNo
char(9)
否
出库编号
GoodsNo
char(9)
否
商品编号
outputQuatity
int
是
出库数量
图 3-18 入库明细表 outputDetail

3.4 其它数据设计
其他数据主要是：日志文件、审计数据、用户权限和统计数据。
(1) 用户表:如图3-19所示：

属性名称
数据类型
是否为空
属性描述
userNo
char(6)
否
用户标识
userName
varchar(12)
否
用户名称
userPwd
char(20)
否
用户口令
图3-19 用户表 User

(2) 系统功能表：如图3-20所示：

属性名称
数据类型
是否为空
属性描述
functionNo
char(6)
否
功能编号
functionName
varchar(12)
否
功能名称
图3-20 系统功能表 Function
(3) 权限表:如图3-21所示：

属性名称
数据类型
是否为空
属性描述
userNo
char(6)
否
用户标识
functionNo
char(6)
否
功能编号
classNo
char(2)
否
操作类型编号
图3-21 权限表 Permission
3.5 视图设计
数据库的视图设计可以在一定层次上提高数据库的安全性，来达到业务的透明性；也可以降低脚本设计的复杂度。安全性主要涉及到商品的入库、订单生成、退单处理、商品推荐等业务，同时用户没有访问涉及到业务关系到的基本表的权限，所以建立各种试图来处理各种业务，这样既不破坏数据库的安全性设计，又达到了预期的效果；降低脚本设计的复杂度主要是对一些统计数据如销售人员的销售量、财务结算等进行视图设计，来减少涉及到该操作的表的数量。以下是一些本系统涉及的视图：
(1) 视图一CustomerView：统计各用户的购买商品金额。
(2) 视图二SupplierView：统计各供货商提供的商品的总金额。
(3) 视图三ProfitView：统计各种商品的利润。

3.6 触发器设计
数据库的触发器设计主要是在数据的插入、删除和更新操作场合下来进行更为复杂的检查和操作，一次来保证数据库的正确性和一致性。本系统涉及到商品的入库、商品的出库、商品的更新等操作，对应于不同的操作建立不同的触发器来限定各种操作的范围。为此设计了如下触发器：
(1) 触发器一trgInsert：在入库明细表中规定每次只能一次插入一条商品记录。
(2) 触发器二trgUpdate：在商品信息更新时商品的销售价格大于成本价格。
(3) 触发器三trgChange： 在订单表中保证该用户在达到一定消费金额时改变会员用户的等级。

3.7 存储过程设计
数据库的存储过程设计主要是为了完成特定功能汇集而成的一组SQL语句集合，该集合编译后存放在数据库中。由于存储过程可以直接运行，也可以远程运行，所以存储过程拥有对业务操作封装、便于事务管理和一定程度上的安全性保护的优点。由于本系统主要是面向广大用户的系统，所以数据库的访问量肯定比较大。为解决能及时的响应用户的各种操作，本系统将创建各种存储过程来增加对用户的响应操作。如：当用户需要查询某种商品时，向服务器发出查询请求，服务器接受到请求直接调用存储过程来处理用户的请求，提高了查询效率。为此设计了如下存储过程：
(1) 存储过程一proCustomerMsg：根据输入的用户账号来查找该用户的历史订单信息。
(2) 存储过程二proSupplierMsg：根据输入的供货商编号来查找该供货商的历史成交信息。
(3) 存储过程三proEmployeeMsg：根据输入的销售人员编号来查找该销售人员的历史销售业绩。
(4) 存储过程四proGoodsName：根据输入的商品名称来查询符合该条件的各商品的信息。
(5) 存储过程五proProfit：根据输入的商品编号来查询该商品的销售信息和盈利信息。

4 模式求精
4.1 存在的问题
至此基本上给出了一个比较完整的商品销售管理系统的需求分析、概念设计（E-R模型）和逻辑设计的全过程。在每一步设计中都反复的修改，讨论还有什么不足的情况。但万事不能尽善尽美。在本实例系统中，只考虑到商品的入库、商品的储藏、用户的订购、商品的出库、用户退单、订单追踪和商品推荐等业务，而在某些方面还是不能考虑的周全。
1) 通过关系数据理论和模式求精知识，结合本系统的逻辑设计，本系统的关系模式是属于第一范式(1NF)。因为本系统只保证了此关系模式的每一个属性对应的阈值都是不可分的,而在库存商品表和订单明细表中都存在销售价格，而订单明细表中的销售价格可以由订单明细表和库存商品表做自然连接而得到，所以订单明细表中的销售价格冗余了。不过这种冗余对于本系统是必要的。因为本系统要经常统计商品销售情况，包括销售总量、销售总金额、利润结算等，如果要订单明细表中添加销售价格属性，将更方便的做统计工作。
2) 通过进一步的思考，还可以增加以下功能：
(1) 对职员是否能胜任他所在的植物没有一个明确的评判标准；
(2 ) 知识根据商品销售的业绩来决定公司的决策，而忽略了对历史数据的分析和市场的变化；
(3) 在商品推荐中设置的商品推荐指标比较片面，无法真正的代表用户真正的想法；
(4) 在供货商的信誉上没有做太多的思考，而是比较笼统的一概而论；
(5) 在客户的注册过程中，对顾客的信誉度没什么具体的要求。
4.2 解决方案
通过分析以上产生的问题，再结合上述的数据库设计，对每个问题提供了大体的解决方案。
(1) 其实在商品销售管理中还要对职员进行基本的培训和考核措施；
(2 ) 对历史数据的分析来更好的决策；
(3) 在商品推荐中设置的商品推荐指标比较片面，无法真正的代表用户真正的想法。因此可以通过设定一些更具代表性的商品推荐指标来满足客户的需要；
(4) 在供货商的信誉上没有做太多的思考，而是比较笼统的一概而论。因此可以增加一些供货的门槛来限定一些供货商提供商品；
(5) 在客户的注册过程中，对顾客的信誉度没什么具体的要求，因此可以根据用户的信誉度提供不同程度的优惠策略，从而提高用户的购买力。

5 物理设计
5.1 设计目标
一个商品销售管理系统，其数据库的物理设计是至关重要的，他涉及到各方面的利益：客户的利益、销售商的利益、供货商的利益等等。所以怎么为数据库选取一个最合适应用环境的物理结构成为了本系统的一个重要的方面。本系统数据库物理设计的目标为：
(1) 提高数据库的性能，以满足应用的性能需求；
(2) 有效利用存储空间；
(3) 在性能和代价之间做出最优平衡。
5.2 数据分布
本系统数据库中要存储的数据主要包括：关系表、数据字典、索引、日志和备份等。
为了提高系统性能，因此，对于数据备份和日志文件的备份，由于他们只是在故障恢复时才使用，而且数据量很大，因此存放在三级存储介质上