医院药品进销存系统

医院药品进销存系统数据库设计医院药品进销存系统数据库设计 一一 需求分析需求分析 1.11.1 需求调查需求调查 由于对医院和药品编码等信息不是很熟悉，我们在网上和附近的医院进行了系统的调查， 以使我们的设计更符合实际包括以下几个方面： 1、医院药品进销存业务状况：系统需求、组织结构、管理内容、业务过程等。 2、数据的规范与统一：详细了解了药品统一编码的规范，对于同一种编码的药品它的通 用名，剂型，规格是相同的。而与其它属性(质量层次，价格等)无关。 3、其他要求：对数据保密性、数据完整性的要求，对数据精度和数据吞吐量的要求，对 来功能、应用范围扩展性的要求等。 1.21.2 基本功能分析基本功能分析 第 1 页 共 12 页 本设计要实现的是医院药品进销存系统,在设计该系统时,应尽可能贴近实际、便于用户 1.系统要示用户必须输入正确的用户名和密码才能进入系统. 2.主要功能模块 A.新药品的入库。 B.过期药品的出库登记、处理记录。 C.药品库存检索。 D.供货商信息检索。 E.药品采购记录管理。 F.药品用药说明信息管理。 G.输出相应的数据报表。 H.*具有数据备份和数据恢复功能。 操作.系统在实现上应该具有如下功能: 其功能模块图如下： 医院药品进销存系统医院药品进销存系统 新药品入新药品入 库库 药品出库药品出库 管管 理理 ( ( 包包 括过期处括过期处 理理) ) 药品库存药品库存 检索检索 供货商信供货商信 息检索息检索 药品采购药品采购 记录管理记录管理 药品用药药品用药 说明信息说明信息 管理管理 二二 概念设计概念设计 在需求分析的基础上，我们对医院药品进销存系统有了一定的了解。在分析设计概念模 型时，首先找出模型所需的实体，然后找到各实体之间的关系，画出 E—R 模型图。 2.12.1、实体及其间的关系设计、实体及其间的关系设计 对于医院药品进销存系统，我们设计了药品，供货商，仓库，操作员四个实体。 结合实际情况及对数据库设计的方便，各个实体之间的关系如下： 供货商和药品之间应该是存在 Offer 关联，它们之间为多对多关系。 供货商，仓库，药品之间存在 Order 关联，它们之间为多对多关系。 药品，仓库之间存在 Own 关联，它们之间为多对多关系。 药品，操作员，仓库之间存在 InStore 和 OutStore 关联，它们之间为多对多关系。 药品和操作员之间存在 Medicine_Useinfo 关联，它们之间为多对多关系。 2.2 E-R2.2 E-R 模型图的设计模型图的设计 根据较为详细的需求分析,我们设计出了以下 E-R 模型图如下. 第 2 页 共 12 页 三三 逻辑设计逻辑设计 逻辑结构设计的目的是将 ER 模型向关系模型转换，注意转换时关系的主键、外键的设置 以保持原有的 ER 模型中实体与实体之间的关系，另外还应当进行规范化处理以消除数据冗 余。 3.1 ER3.1 ER 图向关系模型的转化图向关系模型的转化（主键已标出下划线） Medicine(M_NO,M_ID，M_Name, M_Type,M_Spec,M_Qlevel,M_Price,M_Date,M_Date,M_Funtime） 存在冗余，根我们把它拆分成两张表 Medicine(M_ID,M_Name,M_Type,M_Spec) Medicine_Sub(M_NO,M_ID,M_Price,P_ID,M_Date,M_Date,M_OutTime,M_Qlevel) 注：M_ID 为外键 其他关系模型如下 StoreRoom(S_ID,S_Addr) 第 3 页 共 12 页 Operator(O_ID,O_Name,O_sex) Provider(P_ID,P_Name,P_Addr,P_Post,P_Tel,P_Email,P_Fax,P_Conp,P_ConTel) Offer(M_ID,P_ID) 注 M_ID,P_ID 为外键 Own(M_NO,S_ID,Own_Mount) 注：M_NO,S_ID 为外键 InStore(S_ID,O_ID,In_Mount,In_Date) 注：S_ID，O_ID 为外键 OutStore(O_ID,S_ID,Out_Mount,Out_Date,Out_Type) 注：O_ID，S_ID 为外键 Order(P_ID,S_ID,Od_ID,Od_Mount,Od_Date,Od_Price) 注：P_ID，S_ID 为外键 Medicine_Useinfo(M_NO,O_ID,Patient_Name,Use_Mount,Use_Price,Use_Date) 注：M_NO,O_ID 为外键 3.23.2、、E E－－R R 图转换成关系模型所遵循的原则图转换成关系模型所遵循的原则 我们把 E－R 图转换成关系模型所遵循的原则： 1 1）） 每一个实体类型转换成一个关系模式。如实体 Medicine，StoreRoom，Operator， Provider，都可以转化成对应的一个关系模式。关系模型的主键是E－R 模型的标识符，其 他属性一样。 2 2）） 一个联系可转化为一个关系模式，那么，两端关系的标识符及该联系属性为关系的 属性，而关系的标识符为两端实体标识符的组合。 3)3)三个或三个以上的多对多的联系可转化为一个关系模式，那么，该关系的标识符及联 系的属性为关系的属性，而关系的标识符为各实体标识符的组合。 4)4)我们还涉及到了引用完整性约束，也就是外键的约束，外码的约束贯穿着我们设计的 始终，它把我们建立的关系紧密的联系在了一起。 5 5）） 我们对关系模式进行了消除数据冗余的处理。应符合第三范式，不允许出现传递依 赖、冗余、异常等等。在逻辑设计中形成了关系表后需要对关系作规范化处理，使每个关 系表至少满足第三范式的要求。 对违反第三范式的关系我们进行了分析并作了相应的调整。 对各关系模式之间的数据依赖进行了极小化处理，消除了冗余。对违反第三范式的关系模 式进行了必要的分解和合并。 3.33.3 数据表的详细信息数据表的详细信息 以下是各个数据表的详细信息（还附加了一个表来存放管理员的信息.以便于管理员用 户的登录操作）: 第 4 页 共 12 页 Medicine 信息表 Medicine_Sub 信息表 Provider 信息表 Operator 信息表 StoreRoom 信息表 第 5 页 共 12 页 DealOutDate 表 Own 信息表 Orders 信息表 InStore 信息表 第 6 页 共 12 页 OutStore 信息表 Offer 信息表 Medicine_Useinfo 信息表 UserList 信息表 四四 物理设计物理设计 4.1.4.1.索引设计索引设计 关系属性 A 上的索引是一种数据结构， 它可以提高查找在属性 A 上具有某个特定值的 元祖的效率。索引通常有助于包含有属性 A 和常量的查询，但当关系变得很大时，通过扫 描关系中所有的元祖来找出那些匹配给定条件的元祖的操作方式代价太高。故我们设计索 引需要对一下两方面折中选择。 首先，对某个属性使用索引能极大的提高对该属性值