.2销售管理的细化流程图
图2.3仓库管理的细化流程图
图2.4日常管理的细化流程图
2.4数据字典
●数据存储及数据流
名字:销售信息
别名:销售单
描述:一次销售结束后所存储的信息并生成单据
定义:销售信息=销售编码+药品编码+药品名称+单价+数量+单位+销售日期+总额+销售员编号
位置:存储
输出给顾客
名字:药品信息
别名:
描述:仓库内存储的所有药品信息(包括所有药品查询的所需信息)
定义:药品信息=药品编码+药品名称+药品类别+售价+厂价+单位+库存量+有效期至
位置:存储
输出供查询
名字:用户信息
别名:
描述:系统用户的信息
定义:用户信息=职工号+姓名+用户名+用户口令+职位+权限
位置:存储
输出供查询及维护
名字:供应商信息
别名:
描述:药品供应商的信息
定义:供应商信息=供应商号+供应商名称+联系人+联系电话+所在城市
位置:存储
输出供查询及维护
名字:查询信息
描述:用户所提出的查询请求
定义:查询信息=[销售管理查询信息|仓库管理查询信息|日常管理查询信息]
销售管理查询信息=[药品名称|药品类别]
仓库管理查询信息=[药品编码|药品名称|药品类别|过期药品]
日常管理查询信息=[药品编码|药品名称|药品类别|过期药品]
位置:销售管理系统
仓库管理系统
日常管理系统
名字:更新信息
描述:用户操作对库存信息的添加、删除、修改
定义:更新信息=[销售管理更新信息|仓库管理更新信息|日常管理更新信息]
销售管理更新信息=药品编码+新库存量
仓库管理更新信息=药品编码+药品名称+药品类别+售价+厂价+单位+库存量+有效期至
日常管理更新信息=[用户更新信息|供应商更新信息]
用户更新信息=职工号+姓名+用户名+用户口令+职位+权限
供应商更新信息=供应商号+供应商名称+联系人+联系电话+所在城市
位置:销售管理系统
仓库管理系统
日常管理系统
名字:查询结果
描述:系统完成用户查询请求后所得结果
定义:查询结果=[销售管理查询结果|仓库管理查询结果|日常管理查询结果]
销售管理查询结果=药品编码+药品名称+药品类别+售价+单位+库存量+有效期至
仓库管理查询结果=药品编码+药品名称+药品类别+售价+厂价+单位+库存量+有效期至
日常管理查询结果=[药品信息查询结果|销售记录查询结果|用户查询结果|供应商查询结果]
药品信息查询结果=药品编码+药品名称+药品类别+售价+厂价+单位+库存量+有效期至
销售记录查询结果=销售信息=销售编码+药品编码+药品名称+单价+数量+单位+销售日期+总额+销售员编号
用户信息查询结果=职工号+姓名+用户名+用户口令+职位+权限
供应商信息查询结果=供应商号+供应商名称+联系人+联系电话+所在城市
位置:销售管理系统
仓库管理系统
日常管理系统
●处理
名字:处理信息
编号:1.1
输入:销售信息
输出:销售信息
名字:生成单据
编号:1.2
输入:销售信息
输出:销售信息+销售单
名字:查询处理
编号:1.4
输入:药品信息
输出:查询结果
名字:更新库存
编号:1.3
输入:销售信息
输出:更新信息
●数据项
名字:药品编码
别名:
描述:唯一地标识库存清单中一种特定药品的关键域
定义:药品编码=6{字符}6
位置:药品信息
销售管理查询信息及结果
仓库管理查询信息及结果
日常管理查询信息及结果
名字:库存量
别名:
描述:仓库内药品的实际数量
定义:库存量=1{数字}4
位置:药品信息
销售管理更新信息
仓库管理更新信息
查询结果
名字:总额
别名:总金额
描述:记录每张销售单的总销售额
定义:总额=8{货币}8
位置:销售信息
名字:销售日期
别名:
描述:记录药品销售的时间
定义:销售日期=8{时间}8
位置:销售信息
第三章总体设计
3.1系统E-R图
3.1.1系统局部E-R图
图3.1供应商、药品实体联系图
图3.2药品、药品类别实体联系图
图3.3仓库、药品实体联系图
图3.4职工、药品实体联系图
3.1.2.系统全局E-R图
通过对系统局部ER图的优化设计系统的基本ER图如下:
图3.5
3.2关系模式
1.关系模式设计
该设计以概念结构设计中的E-R图为主要依据,设计出相关的整体逻辑结构。根据总E-R图有五个实体但仓库实体在本系统中作用不大而且仅涉及到一个仓库,所以仓库不再单独设计一张表。再加上一个多对多关系(本系统不考虑供应关系)总共五个关系模式:
药品信息(药品编码,药品名称,药品类别代码,售价,厂价,库存量,单位,有效期至)
药品类别索引(药品类别代码,类别说明)
供应商信息(供应商编码,供应商名称,联系人,联系电话,所在城市)
用户信息(职工号,姓名,用户名,用户口令,职位,权限)
药品销售信息(销售编码,销售日期,药品编码,药品名称,单价,数量,单位,总额,销售员编码)
2.关系模式优化
3.2.1中的关系模式中的每一个分量都是不可分的数据项所以都符合第一范式;而且所有的前四个关系模式都是由单个属性作为码,没有任何属性对码部分依赖,在药品销售信息内虽由三个属性作为码,但也不存在属性对码的部分依赖,所以上述模式都符合第二范式;药品信息、药品类别索引、供应商信息三个关系模式中不存在传递依赖,都属于第三范式。
在用户信息关系模式中,用户是按照权限分类的,职位不同权限不同,这样该关系模式就存在了非主属性对码的传递依赖:职工号→职位,职位→权限,所以应将用户信息分解为:
用户信息(职工号,姓名,用户名,用户口令,职位)
职位权限信息(职位,权限)
但本系统不考虑职工信息的管理,为了使销售员编号与销售员的职工号连系起来,并能通过职工姓名和职位来修改用户信息所以把员工的部分信息(职工号,姓名,职位)跟用户基本信息(用户名,用户口令,权限)合成了用户信息(职工号,姓名,用户名,用户口令,职位,权限)以便于系统功能的实现,所以在此不采用分解模式,仍采用原模式。
药品销售信息中有大量的数据冗余,且不够明确。现将其分解为:
药品销售主表(销售编码,销售日期,销售员编号,总金额)
药品销售子表(销售编码,销售日期,药品编码,药品名称,单价,数量,单位,金额)
其中"金额"由"单价"和"数量"乘积求得,"总金额"由同一销售单内不同药品的"金额"求和得到。这样不仅方便查询销售总额,也加快了合计数据的速度,也有利于程序的实现。
用户信息模式和药品销售子表模式是为了降低连接操作,减少外键和索引数目对原模式进行重建或分割得来的。更重要得是,这样不但可以提高查询速度,而且有利于系统实现。
3.3数据表设计
通过对关系模式的优化,得到六个基本表:
表3-1药品信息表
字段名
字段类型
长度
主键或外键
字段值约束
对应中文属性名
MedicineCode
Char
6
PrimaryKey
NotNull
药品编码
MedicineName
Varchar
32
NotNull
药品名称
MedKindCode
Char
1
Foreignkey
NotNull
药品类别代码
Price
Money
8
售价
ListPrice
Money
8
厂价
Number
Int
4
库存量
Unit
Char
2
单位
UsefulLife
Datetime
8
有效期至
表3-2供应商信息
字段名
字段类型
长度
主键或外键
字段值约束
对应中文属性名
FirmCo
上一篇:
vb试题库自动组卷系统(论文和程序)
下一篇:
课外阅读活动方案