药品销售管理系统需求分析一背景说明医药作为民生的基本保障之一。
是我们生活中不可缺少的部分。
近来，越来越多的医药销售点普及。
规模各不一样。
但总的来说，免不了两个部分：进购药品和销售药品。
为了实现这两个部分的功能和要求，需设计出功能细致的完整系统。
该系统需包含对药品信息的管理、对财务状况的管理等。
医药管理是一项琐碎、复杂而又十分细致的工作。
手工进行企业日常的药品销售、出入库的工作，容易出现“开空单”的现象，且呆账、错账时有发生，而且费时费力。
本系统在设计中考虑和克服了上诉问题，实现了企业管理工作的系统化、规范化和自动化。
在本次课程设计中，基于对资料的调查了解和自身的主观认识粗略设计出如下医药销售系统。
以达到实现简单的医药销售的各个功能的目的。
二部门划分1、进药部门该部门是医药销售的基础。
只有保证该部门的正常的运行，才能更好的完成药品销售的顺利进行。
在该部门中，需要对入库的药品进行细致入微的药品信息登记。
其中包括每次进购的药品信息和财务、每次取出用于销售的药品信息和财务、过期药品的信息和财务以及处理情况。
到一定的阶段还需要对所有的数据进行汇总分析。
2、售药部门该部门是医药销售的直接部门。
是面向顾客的一种服务。
会比较直观的体现整个医药的销售情况。
虽然该部门需要了解和学习不少的销售技巧方面的知识，以到达提高销售业绩的目的。
但对于本系统来讲，该部门主要实现对每次进柜的药品信息登记、每售出一件药品的信息登记、回收过期药品的信息登记等。
只有每次细致的记录相关信息，才能更有条理的顺利完成各个要求。
三子系统功能该系统总的方面分为两个大的板块，就是上面讲的进药部门和售药部门。
但在具体实施过程中。
会涉及到不同的子系统及相关的数据属性等。
这样更细致全面的罗列出各个方面的信息和要求，有助于系统的完整性和操作的有效性。
在医药销售中，首先会涉及到基本的药品信息，包括其基本属性信息以及价格信息等。
销售都会涉及到财务状况，因此必须做好相关的财务信息记录。
另外，还会涉及到销售管理和仓库管理的相关数据。
因此在该系统中，会有以下几个子系统：基本信息子系统、库房管理子系统、销售管理子系统、财务统计子系统、总经理子系统。
四各子系统的功能基本信息子系统1、药品基本信息（编号、药名、单价、数量、总价、供应商、备注）2、供应商基本信息（供应商号、名称、联系人、所在城市、联系方式）3、客户基本信息（客户号、类别、联系人、所在城市、联系方式）4、员工基本信息（员工号、姓名、用户名、密码、职位、权限）库房管理子系统1、对入库的药品进行登记（编号、药名、数量、单价、总价、备注）2、对仓库中的药品进行查询（编号、药名、库存数量、单价、备注）3、进行退货处理（编号、药名、退货数量、单价、备注）销售管理子系统1、对每一次销售行为进行登记（编号、药名、单价、数量、总价、经手人、日期）2、对销售报表进行查询（编号、药名、单价、数量、总价、经手人、日期）3、对销售退货进行处理（编号、药名、单价、数量、总价、经手人、日期）财务统计子系统1、每天的收入、支出记录（编号、发票号、数额、经手人、日期）2、每月的结算（编号、上月余额、收入、支出、余额、经手人、日期）3、年终结算（编号、收入、支出、净收入、经手人、日期）总经理子系统1、查询销售情况和财务状况以便了解本企业的经营状况，做出相应的决策;2、管理员工，了解不同员工的上班时间和他的相关的业绩；3、客户的管理，了解客户的数量，注销有问题的客户；4、供应商的管理，了解供应信息，选择最合适的供应商。
五数据字典概念结构设计过程本次课程设计开发医药销售管理系统，经过可行性分析、详细调查以及多次讨论，确定了该系统主要由进购药品和销售药品两部分组成。
具体来说分为五个子系统，分别是：基本信息子系统、库房管理子系统、销售管理子系统、财务统计子系统、总经理子系统。
各个子系统各司其职，独立完成自身的任务又与其他子系统紧密联系。
本结构设计过程采用自顶向下的设计方法，即首先定义全局概念结构的框架，然后逐步细化。
下面给出各个子系统的分析及分E-R图的设计及对其进行的各项调整基本信息子系统子系统功能：1、收集药品、员工、顾客和供应商的基本信息并做好相应的记录和管理。
其中包括对当前信息的添加、修改、删除等管理。
2、定期对各种信息进行整理。
比如对过了保质期的药品信息和过了一定时限的员工、顾客和供应商信息的删除。
以减少资源的浪费。
3、对系统自身的维护管理。
比如系统的修复和升级等。
根据设计情况以及数据字典，画出该子系统的分E-R图。
员工信息分E-R图：药品信息分E-R 图:有效期供应商 名称n 药品n售价库存量查询编号进价一■顾客信息E-R 图: 联系方式楓名称联系人实体属性如下: 员工（员工号、姓名、性别、年龄、工龄、级别、职务、权限、备注） 药品（编号、药名、类别、供应商、库存量、进价、售价、有效期、备注）顾客（客户号、名称、联系人、联系方式、所在城市、备注） 供应商（供应商号、名称、联系人、联系方式、所在城市、备注）库房管理子系统子系统的功能：1、 对入库的药品进行编号登记管理。
将各种药品分类编号登记其名称、数量及进购价格等 相关信息，便于查询的方便和效率。
2、 对每次从仓库取出的药品进行详细的登记管理。
主要包括其药名、数量、经手人、取出 日期等管理。
3、实现随时查询仓库情况的功能。
要求能即使登入界面、 准确查询相关的仓库当前的信息。
4、能做好对不合要求的药品的退货管理。
要求记录退掉的药品的名称、数量、所值金额和退货原因等相关信息。
根据设计情况以及数据字典，画出该子系统的分E-R 图。
实体属性如下：入库合出库药品（编号、药名、数量、单价、总价、备注） 对仓库中药品的查询（编号、药名、库存量、单价、备注） 退货处理（编号、药名、退货数量、单价、备注）销售管理子系统子系统功能：1、及时对每次销售行为的准确记录。
包括药品的编号、名称、数量、金额、经手人、经手日期等相关信息的准确登记。
方便整个的管理和其他的查询工作的完成。
2、 对每次退货进行详细的记录。
除了药品的基本信息之外，还需要对退货原因进行详细的 登记。
以便找出原因并尽力解决其原因。
以减少以后的退货率。
3、 能够实现月终和年终的总的数据统计以及能实现随时对销售报表的查询功能。
其中数据查询 *n./1供应商号*所在城市1供应商-联系方式/'j ”"1\ 、合格・存量4 药品 -• 存放 货号 单价 存量＞供应商仓库号 面积的统计主要包括编号、药名、数量、金额、经手人、统计截止日期等。
而对报表的查询时需 要有如下属性的总的统计。
比如：某种药品的售出数量、总的售出金额、统计截止日期、负 责人证明。
根据设计情况以及数据字典，画出该子系统的分E-R 图。
顾客—L 支付、_』应收帐订货一4 n订单实体属性如下: 每次售出的药品（编号、药名、单价、数量、总价、经手人、日期） 每次退回的药品（编号、药名、单价、数量、总价、经手人、日期） 销售报表的查询（编号、药名、单价、数量、总价、经手人、日期） 财务统计子系统 子系统功能:1、 记录每天支出和收入的详细情况、相关细则以及结算情况。
记录尽可能详细，以方便管 理。
主要记录售出或退回的药品的编号、药名、发票号、单价、数量、总价、经手人、 日期以及备注等。
2、 记录每月支出和收入的详细情况、相关细则以及结算情况。
主要包括上月余额、当月的 收入、支出、余额、经手人和日期。
能实现随时查询的功能。
3、 记录每年支出和收入的详细情况、相关细则以及结算情况。
主要包括上年余额、当年的 收入、支出、净收入、经手人和日期。
能实现随时查询的功能。
根据设计情况以及数据字典，画出该子系统的分E-R 图。
顾客支付；i-n —应收账1订货n订单■..产品实体属性如下:折扣规则参照1产品描述组成n参照24、 每天的收入、支出记录（编号、发票号、数额、经手人、日期）5、 每月的结算（编号、上月余额、收入、支出、余额、经手人、日期）6、 年终结算（编号、收入、支出、净收入、经手人、日期）总经理子系统子系统功能：1、 能随时查询销售情况和财务状况具体情况以便了解本企业的经营状况,2、 管理员工，了解不同员工的上班时间和他的相关的业绩；3、 客户的管理，了解客户的数量，注销有问题的客户；4、 供应商的管理，了解供应信息，选择最合适的供应商。
根据设计情况以及数据字典，画出该子系统的分E-R 图。
实体属性如下：药品信息（编号、药名、单价、数量、总价、供应商、备注） 财务信息（编号、发票号、支出、收入、净收入、经手人、日期） 销售信息（编号、药名、单价、数量、总价、经手人、日期） 供应商（供应商号、名称、联系人、所在城市、联系方式） 顾客（客户号、类别、联系人、所在城市、联系方式） 对E-R 图调整的准则：现实世界中的事物能作为属性对待的尽量作为属性对待；属性和实体的划分：属性中不具有需要描述的信息，即属性是不可分的数据项，不再 包含其他信息。
具体调整如下：员工应对应一个领导关系，但为了简便起见，就用员工的“等级”属性来表示员工之间的 领导关系。
视图集成以上便是五个子系统的分 E-R 图设计及其调整的整个过程，接着要做的就是将所有的 分 E-R 图进行综合 ,合成一个系统的总 E-R 图 .由于本系统比较简单 ,分 E-R 图规模也比较小 , 所以 E-R 图合成过程采用一次将五个子 系统分 E-R 图集成总 E-R 图的方式 .分两步进行：做出相应的决策;第一步：合并。
解决各分E-R 图之间的冲突，将各分E-R 图合并起来生成初步E-R 图。
各分E-R 图之间的冲突主要有三类：1、属性冲突：（1 ）属性域冲突，即属性值的类型、取值范围或取值集合不同。
由于本系统较简单，所以并不存在这种冲突；（2 ）属性取值单位冲突。
由于本系统较简单，不存在这类冲突；2、命名冲突：（1）同名异义：由于本系统较简单，所以不存在这类冲突；（2）异名同义：由于本系统较小，所以不存在这类冲突；3、结构冲突：（1）同一对象在不同应用中具有不同的抽象：本系统在需求分析阶段原本存在这种冲突，考虑到后期的简化合并，我们在设计各个分E-R 图就早先解决了这个问题，即将在任何一个分E-R 图中作为实体出现的属性全部作为实体；（2）同一实体在不同分E-R 图中所包含的属性个数和属性排列次序不完全相同：由于本系统较简单，所以并不存在这种冲突；第二步：修改和重构。
消除不必要的冗余，生成基本E-R 图。
由于本系统涵盖的内容比较少，基本不存在冗余的现象，所以初步E-R 图就是基本E-R 图，不必再进行调整。
下面给出E-R 图。
逻辑结构设计一、 关系模式：药品信息（编号、药名、单价、数量、总价、供应商、备注） 员工信息（员工号、姓名、用户名、密码、职位、权限） 客户信息（客户号、类别、联系人、所在城市、联系方式） 供应商信息（供应商号、名称、联系人、所在城市、联系方式） 药品销售信息（编号、药名、单价、数量、总价、经手人、日期） 二、 关系模式优化：在上述关系模式中，每一个分量都是不可分割的数据项所以都符合第一范式；在员工信息关系模式中，员工是按照权限分类的， 职位不同权限也不同， 这样该关系模式就存在了非 主属性对码的传递依赖： 员工号-> 职位，职位-> 权限，所以就将用员工信息分解为如下现个 模式： ① 员工信息（员工号、姓名、职位） ② 职位权限信息（职位、权限）本系统不考虑职工信息的管理，为了使销售员编号与销售员的职工号连系起来，并能通过 职工姓名和职位来修改用户信息所以把员工的部分信息（员工号、姓名、职位）和用户信息（用户名、密码、权限）合成了员工信息（员工号、姓名、用户名、密码、职位、权限）以 便系统功能的实现，所以在此不采用模式分解。