根据设计情况以及数据字典，画出该子系统的分E-R图。
实体属性如下：
每次售出的药品（编号、药名、单价、数量、总价、经手人、日期）
每次退回的药品（编号、药名、单价、数量、总价、经手人、日期）
销售报表的查询（编号、药名、单价、数量、总价、经手人、日期）
财务统计子系统
子系统功能：
1、 记录每天支出和收入的详细情况、相关细则以及结算情况。记录尽可能详细，以方便管理。主要记录售出或退回的药品的编号、药名、发票号、单价、数量、总价、经手人、日期以及备注等。
2、 记录每月支出和收入的详细情况、相关细则以及结算情况。主要包括上月余额、当月的收入、支出、余额、经手人和日期。能实现随时查询的功能。
3、 记录每年支出和收入的详细情况、相关细则以及结算情况。主要包括上年余额、当年的收入、支出、净收入、经手人和日期。能实现随时查询的功能。
根据设计情况以及数据字典，画出该子系统的分E-R图。
实体属性如下：
4、 每天的收入、支出记录（编号、发票号、数额、经手人、日期）
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图。
逻 辑 结 构 设 计
一、关系模式：
药品信息（编号、药名、单价、数量、总价、供应商、备注）
员工信息（员工号、姓名、用户名、密码、职位、权限）
客户信息（客户号、类别、联系人、所在城市、联系方式）
供应商信息（供应商号、名称、联系人、所在城市、联系方式）
药品销售信息（编号、药名、单价、数量、总价、经手人、日期）
二、关系模式优化：
在上述关系模式中，每一个分量都是不可分割的数据项所以都符合第一范式；在员工信息关系模式中，员工是按照权限分类的，职位不同权限也不同，这样该关系模式就存在了非主属性对码的传递依赖：员工号->职位，职位->权限，所以就将用员工信息分解为如下现个模式：
①员工信息（员工号、姓名、职位）
②职位权限信息（职位、权限）
本系统不考虑职工信息的管理，为了使销售员编号与销售员的职工号连系起来，并能通过职工姓名和职位来修改用户信息所以把员工的部分信息（员工号、姓名、职位）和用户信息(用户名、密码、权限）合成了员工信息（员工号、姓名、用户名、密码、职位、权限）以便系统功能的实现，所以在此不采用模式分解。
三、用户子模式设计
1、经理子系统用户子模式
员工(员工号、姓名、用户名、密码、职位、权限)；
因为经理对于员工其他情况不会经常关注，经常使用的只有以上各项，所以在经理子系统上设立员工关系。
2、库房管理子系统用户子模式
药品（编号、药名、单价、数量、备注）
因为管理员对药品的其他信息不会经常使用。经常使用的只有以上各项，所以在库房管理子系统上设立药品关系。
3、销售管理用户子模式
销售记录（编号、药品、单价、数量、总价、经手人、日期）
因为在销售员对销售记录中的其他信息不会经常使用，经常使用的只有以上各项，所以在销售管理子系统上设立销售记录关系。
物 理 结 构 设 计
一. 存储结构设计
经过分析可知,本药品销售管理系统中信息处理的特点如下：
（１）销售和库房管理两个部门的数据不仅经常需要查询,而且更新速度快,例如销售系统中药品的销售记录、库房管理中对于库存中的药品信息。
（２）各个部门信息要求共享的信息较多。例如员工信息、药品的基本信息等。但财务信息一般不共享。
（３）经理部门有一定的特殊职能：汇总财务信息；对于被辞退的员工从系统中级联删除其信息、如从员工表中删除其基本信息、从它所服务的工作部门中删除该员工的工作名额，结算支付其工资、奖金；同时补充新的员工，代替它的工作。
针对这些特点，设计如下:
1. 确定数据库的存放位置
为了提高系统性能，现根据应用情况将数据按照易变部分和稳定部分、经常存取部分和存取频率较低的部分分别在两个磁盘上存放。同时，考虑到本系统是多用户的，为了提高效率，数据库的备份的数据和日志文件将保存在磁带中。
经常存取部分：
药品基本信息（编号、药名、单价、数量、总价、供应商、备注）
供应商基本信息（供应商号、名称、联系人、所在城市、联系方式）
客户基本信息（客户号、类别、联系人、所在城市、联系方式）
员工基本信息（员工号、姓名、用户名、密码、职位、权限）
对入库的药品进行登记（编号、药名、数量、单价、总价、备注）
对仓库中的药品进行查询（编号、药名、库存数量、单价、备注）
对每一次销售行为进行登记（编号、药名、单价、数量、总价、经手人、日期）
对销售报表进行查询（编号、药名、单价、数量、总价、经手人、日期）
存取频率较低的部分：
账单（编号、发票号、数额、经手人、日期）；
总帐(编号、上月余额、收入、支出、余额、经手人、日期)；
财务状况（收入、支出、净收入、经手人、日期）；
进行退货处理（编号、药名、退货数量、单价、备注）；
对销售退货进行处理（编号、药名、单价、数量、总价、经手人、日期）；
2. 确定系统配置
药品销售管理系统需要的微机数量和规模都不必太大，但在系统设计时应考虑到酒店的发展需求，在选择硬件设备、服务器操作系统、数据库时都考虑到能够逐步的增加和扩展。
本药品销售管理系统选用了Windows9x系统作为微机的操作系统，它能够有较好的使用界面并能够充分发挥出微机硬件的作用，比较适合药店这样的机构；另外，选用了目前应用最多的ORACLE 数据库。
由于涉及到药店的财务管理，数据的完整性和安全性显得尤其重要。系统中的数据一旦丢失，将需要很长时间进行恢复，有时甚至使信息系统不得不从系统初始化阶段重新开始运行。每天进行数据备份是保障系统安全的重要手段。数据备份需要严格按照事先制定的备份与故障恢复策略进行，并落实备份登记和检查措施。
具体的系统配置应当根据系统实际运行情况做进一步的调整。
二 存取路径设计
在本系统中，主要的操作是查询、更新等操作。在各个子系统中都会涉及到相关的操作。所以在本系统中采用索引方法，即根据应用要求确定对关系的哪些属性列建立索引、哪些属性列建立组合索引、哪些索引要设计为唯一索引等。具体设计如下：
1、对以下经常在查询中出现的关系的码建立索引<说明：下加横线部分表示关系的码>
药品基本信息（编号、药名、单价、数量、总价、供应商、备注）
供应商基本信息（供应商号、名称、联系人、所在城市、联系方式）
客户基本信息（客户号、类别、联系人、所在城市、联系方式）
员工基本信息（员工号、姓名、用户名、密码、职位、权限）
对入库的药品进行登记（编号、药名、数量、单价、总价、备注）
对仓库中的药品进行查询（编号、药名、库存数量、单价、备注）
对销售报表进行查询（编号、药名、单价、数量、总价、经手人、日期）
2、以下经常进行连接操作的关系的码建立索引:
编号、供应商号、客户号、员工号等
3、由于下面几个关系模式的更新频率很高,所以没有定义索引:
对每一次销售行为进行登记（编号、药名、单价、数量、总价、经手人、日期）
账单（编号、发票号、数额、经手人、日期）；
总帐(编号、上月余额、收入、支出、余额、经手人、日期)；
财务状况（收入、支出、净收入、经手人、日期）；
课程小结
在这次课程设计过程中，我首先对医药管理进行了了解，仔细分析了该管理对系统功能的要求，并根据这些功能要求对系统进行定义，确定系统必须做什么。但由于对医药管理了解不多，需求分析难免不够完善。之后着手对系统的设计工作，首先是概念结构设计，根据需求分析结果总结系统内实体及联系并绘制系统的局部ER图然后画出全局ER图。结合需求分析与概念结构设计把设计好的ER图转换为DBMS所支持的数据模型所符合的逻辑结构，运用SQL数据库管理系统建好表和相关约束。
本系统最终能够基本实现绝大多数功能，但是也有很多不足之处，如药品进库信息功能，对新进药品进行入库存储，但是由于进价跟有效期的变化不能只是对该药品的库存量更改。进价可以运用加成定价法更改。
在这次课程设计中虽然遇到过很多的困难，但我从中学到了很多有用的知识，通过不断的翻阅资料，各个问题的解决使我对系统的设计越来越感兴趣。相信我从这次课程设计所学到的东西可以让我在以后的学习及工作中受益无限。
参考文献：
[1]．李晓喆,张晓辉. SQL Server 2000管理及应用系统开发.人民邮电出版社，2002
[2]．徐松林,路斌,王冬.PowerBuilder数据库应用开发教程.清华大学出版社，2003 |
