《医院药品进销存系统》由会员分享，可在线阅读，更多相关《医院药品进销存系统（13页珍藏版）》请在金锄头文库上搜索。
1、医院药品进销存系统数据库设计一需求分析1.1需求调查由于对医院和药品编码等信息不是很熟悉，我们在网上和附近的医院进行了系统的调查， 以使我们的设计更符合实际包括以下几个方面：1、医院药品进销存业务状况：系统需求、组织结构、管理内容、业务过程等。2、数据的规范与统一：详细了解了药品统一编码的规范，对于同一种编码的药品它的通 用名，剂型，规格是相同的。而与其它属性 （质量层次，价格等）无关。3、其他要求：对数据保密性、数据完整性的要求，对数据精度和数据吞吐量的要求，对 来功能、应用范围扩展性的要求等。1.2基本功能分析本设计要实现的是医院药品进销存系统，在设计该系统时，应尽可能贴近实际、便于用户
2、操作.系统在实现上应该具有如下功能：1. 系统要示用户必须输入正确的用户名和密码才能进入系统2. 主要功能模块A. 新药品的入库。B. 过期药品的出库登记、处理记录。C. 药品库存检索。D. 供货商信息检索。E. 药品采购记录管理。F. 药品用药说明信息管理。G. 输出相应的数据报表。H. *具有数据备份和数据恢复功能。二 概念设计在需求分析的基础上，我们对医院药品进销存系统有了一定的了解。在分析设计概念模 型时，首先找出模型所需的实体，然后找到各实体之间的关系，画出ER 模型图。2.1 、实体及其间的关系设计对于医院药品进销存系统，我们设计了药品，供货商，仓库，操作员四个实体。 结合实际情况
3、及对数据库设计的方便，各个实体之间的关系如下： 供货商和药品之间应该是存在 Offer 关联，它们之间为多对多关系。 供货商，仓库，药品之间存在 Order 关联，它们之间为多对多关系。药品，仓库之间存在Own关联，它们之间为多对多关系。 药品，操作员，仓库之间存在 InStore 和 OutStore 关联，它们之间为多对多关系。 药品和操作员之间存在 Medicine_Useinfo 关联，它们之间为多对多关系。2.2 E-R 模型图的设计根据较为详细的需求分析，我们设计出了以下E-R模型图如下.MedicineM IDAl 6M_MOAfiM_NlaneVA5OM_TypeWA1OMS
4、pecWAWWA10M_RriGeF10WI.D融电DMOutTi m eTIdtntifitrjlP IDvplA ASF_N-amiVA50P_AddrVA5DP_PcstABF_TelVA14刑AP.E 耐ilVA5DFFaxVA1OP_MPVA20PConTalVA14iPrwiderOfferMedieine UseinfoOrderVA2O I wn Mcumt II JD阳I.Mount1F1 0JI OdOTT.FncsF1 0PatientBNannei UsejAount l_F rirp itfOnlri_Wount I InDTOirtSio n ut_Wou nt I
5、QaLU* qtOut_Tjxpa VA20 Store loomidentifieLl pi IrtS-tiffe三逻辑设计逻辑结构设计的目的是将 ER模型向关系模型转换，注意转换时关系的主键、外键的设置 以保持原有的ER模型中实体与实体之间的关系，另外还应当进行规范化处理以消除数据冗 余。3.1 ER图向关系模型的转化(主键已标出下划线)Medicine(M NO,MD， M_Name, M_Type,M_Spec,M_Qlevel,M_Price,M_Date,M_Date,M_Funtime )存在冗余，根我们把它拆分成两张表Medicine(M ID,M Name,M Type,M
6、Spec)Medicine Sub(M NO,MD,M_Price,P_ID,M_Date,M_Date,M_OutTime,M_Qlevel)注：MD为外键其他关系模型如下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_Co np,P_Co nTel)Offer(MD,P_ID)注MD,P_ID为外键Own(M_N O,S_ID,Own_ Mount)注：M_NO,S_ID为外键In Store(S_ID,O_ID,In_Mou
7、 nt,In_Date)注：S_ID, O_ID为外键OutStore(O_ID,S_ID,Out_Mou nt,Out_Date,Out_Type)注：O_ID, S_ID为外键Order(P_ID,S_ID,Od_ID,Od_Mou nt,Od_Date,Od_Price)注：P_ID, S_ID为外键Medici ne_Usei nfo(M_NO,O_ID,Patie nt_Name,Use_Mou nt,Use_Price,Use_Date)注：M_NO,O_ID为外键3.2、E- R图转换成关系模型所遵循的原则我们把E- R图转换成关系模型所遵循的原则：1) 每一个实体类型转换成一个
8、关系模式。如实体 Medicine , StoreRoom, Operator , Provider，都可以转化成对应的一个关系模式。关系模型的主键是 E- R模型的标识符，其 他属性一样。2) 一个联系可转化为一个关系模式，那么，两端关系的标识符及该联系属性为关系的 属性，而关系的标识符为两端实体标识符的组合。3) 三个或三个以上的多对多的联系可转化为一个关系模式，那么，该关系的标识符及联 系的属性为关系的属性，而关系的标识符为各实体标识符的组合。4) 我们还涉及到了引用完整性约束，也就是外键的约束，外码的约束贯穿着我们设计的 始终，它把我们建立的关系紧密的联系在了一起。5) 我们对关系模式
9、进行了消除数据冗余的处理。应符合第三范式，不允许出现传递依 赖、冗余、异常等等。在逻辑设计中形成了关系表后需要对关系作规范化处理，使每个关 系表至少满足第三范式的要求。对违反第三范式的关系我们进行了分析并作了相应的调整。 对各关系模式之间的数据依赖进行了极小化处理，消除了冗余。对违反第三范式的关系模 式进行了必要的分解和合并。3.3数据表的详细信息以下是各个数据表的详细信息(还附加了一个表来存放管理员的信息.以便于管理员用户的登录操作)：Medicine信息表列塔數据类型按度允许空31char1&varchar50M_Typ&vay ttiar10M_5pcvar chai-1CIMedici
10、ne_Sub 信息表刊名散据类型长度|允许空M_HDckar8U_IDchar匹MJriceitimericg2 F_IDuh牡sMJ atedats卜M_0u tilinglata time8N_9Levelv ar char10 一 .Provider信息表列名数据类型长度允许空飞P_IEcharS?_Namevar char50Uddr时 archer50P_postchar6F_Telyar charHf_Errailvarchar502 J?_F axvarchar10P_CcnPvarchir20f_ConTelv&rcharIQ1Operator信息表StoreRoom信息表列名
11、数据类型长度允许空?S_IDchtr5S Adirvsr chr50DealOutDate 表数招类型长度允许空5_IDchar5cIl&t160 ID5D&sl_Typ&50D&slEatedatetime8D&sl_A.ddrvar char50D el_H owlint4Own信息表列名I数詰类型长度允许空M_IDhr165_IDchar5卜ini4厂rOrders信息表In Store信息表列名1r 数据类凰|长度允许空IOd_IDchai*16F IEchar5S_IDchar5lfl IDchar160 d_M ountint4Od_D&t8UdFfi cenumeric9OutS
12、tore信息表Offer信息表Medic in e_Usei nfo 信息表列名数据类型檢度允许空厦M_IDchar0_IDchir5Tati entNajnevarchar20Use Mount4UseFricenumeric38UserList 信息表列名嫂据类型r长度允许空Vvsrchar50Fasti! ordvarchar50m i la+Fp四物理设计4.1.索引设计关系属性A上的索引是一种数据结构，它可以提高查找在属性A上具有某个特定值的元祖的效率。索引通常有助于包含有属性A和常量的查询，但当关系变得很大时，通过扫描关系中所有的元祖来找出那些匹配给定条件的元祖的操作方式代价太高。
13、故我们设计索 引需要对一下两方面折中选择。首先，对某个属性使用索引能极大的提高对该属性值的检索效率，使用该属性时，还 可以加快连接。其次，对关系上某个属性的索引会使得对关系的插入、删除、修改变得复杂和费时。因此经过分析本系统的功能和需求可知，本系统的药品表中的记录可能相当的庞大，而且基于药品名称或编码的查询和修改相当的频繁，加之在数据库更新和维护过程中对供货 商的更新和查询也比较的频繁，而且供货商的数量也可能比较大，综合考量后应为本系统 建立如下3个索引，已达到操作的便捷和系统功能的优化。create unique index M_ID_index on Medicine(M_lD);create uni
