医院药品进销存系统

医院药品进销存系统数据库设计

一需求分析

1.1需求调查

由于对医院和药品编码等信息不是很熟悉，我们在网上和附近的医院进行了系统的调查，以使我们的设计更符合实际包括以下几个方面：

1、医院药品进销存业务状况：系统需求、组织结构、管理内容、业务过程等。

2、数据的规范与统一：详细了解了药品统一编码的规范，对于同一种编码的药品它的通用名，剂型，规格是相同的。而与其它属性(质量层次，价格等)无关。

3、其他要求：对数据保密性、数据完整性的要求，对数据精度和数据吞吐量的要求，对来功能、应用范围扩展性的要求等。

1.2 基本功能分析

本设计要实现的是医院药品进销存系统,在设计该系统时,应尽可能贴近实际、便于用户操作.系统在实现上应该具有如下功能:

1.系统要示用户必须输入正确的用户名和密码才能进入系统.

2.主要功能模块

A.新药品的入库。

B.过期药品的出库登记、处理记录。

C.药品库存检索。

D.供货商信息检索。

E.药品采购记录管理。

F.药品用药说明信息管理。

G.输出相应的数据报表。

H.*具有数据备份和数据恢复功能。

其功能模块图如下：

二概念设计

在需求分析的基础上，我们对医院药品进销存系统有了一定的了解。在分析设计概念模型时，首先找出模型所需的实体，然后找到各实体之间的关系，画出E—R模型图。

2.1、实体及其间的关系设计

对于医院药品进销存系统，我们设计了药品，供货商，仓库，操作员四个实体。

结合实际情况及对数据库设计的方便，各个实体之间的关系如下：

供货商和药品之间应该是存在Offer关联，它们之间为多对多关系。

供货商，仓库，药品之间存在Order关联，它们之间为多对多关系。

药品，仓库之间存在Own关联，它们之间为多对多关系。

药品，操作员，仓库之间存在InStore和OutStore关联，它们之间为多对多关系。

药品和操作员之间存在Medicine_Useinfo关联，它们之间为多对多关系。

2.2 E-R模型图的设计

根据较为详细的需求分析,我们设计出了以下E-R模型图如下.

三逻辑设计

逻辑结构设计的目的是将ER模型向关系模型转换，注意转换时关系的主键、外键的设置以保持原有的ER模型中实体与实体之间的关系，另外还应当进行规范化处理以消除数据冗余。

3.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)

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.2、E－R图转换成关系模型所遵循的原则

我们把E－R图转换成关系模型所遵循的原则：

1）每一个实体类型转换成一个关系模式。如实体Medicine，StoreRoom，Operator，Provider，都可以转化成对应的一个关系模式。关系模型的主键是E－R模型的标识符，其他属性一样。

2）一个联系可转化为一个关系模式，那么，两端关系的标识符及该联系属性为关系的属性，而关系的标识符为两端实体标识符的组合。

3)三个或三个以上的多对多的联系可转化为一个关系模式，那么，该关系的标识符及联系的属性为关系的属性，而关系的标识符为各实体标识符的组合。

4)我们还涉及到了引用完整性约束，也就是外键的约束，外码的约束贯穿着我们设计的始终，它把我们建立的关系紧密的联系在了一起。

5）我们对关系模式进行了消除数据冗余的处理。应符合第三范式，不允许出现传递依赖、冗余、异常等等。在逻辑设计中形成了关系表后需要对关系作规范化处理，使每个关系表至少满足第三范式的要求。对违反第三范式的关系我们进行了分析并作了相应的调整。对各关系模式之间的数据依赖进行了极小化处理，消除了冗余。对违反第三范式的关系模式进行了必要的分解和合并。

3.3 数据表的详细信息

以下是各个数据表的详细信息（还附加了一个表来存放管理员的信息.以便于管理员用户的登录操作）: