软件完成后将拥有“字典维护”、“门诊管理”、“院长查询”三个模块，它针对软件所处的应用环境而发挥软件的高效作用，“字典维护”模块存储了药品信息和收费项目，以供药品的进存提供数据；“门诊管理”模块拥有门诊挂号、门诊划价、门诊收费、药房发药四个子功能；“院长查询”模块则提供了一个供医院高层领导直接查询医院任何时间的科室挂号量和药品库存量。
本系统的开发平台为Microsoft公司的开发工具——Microsoft Visual Studio 2005，以及结合了数据库软件——Microsoft SQL Serer作为系统中所用到的数据源的支撑平台。
关键字：医院管理系统；VC++.NET；数据库；数据库系统
目 录
引言 6
1 绪论 7
2 可行性分析 8
2.1 经济可行性 8
2.2 技术可行性 8
2.3 政策可行性 8
3 需求分析 9
3.1 业务流程 9
3.2 系统层次方框图 9
3.3系统中各模块层次图 10
3.3.1系统字典维护 10
3.3.2门诊挂号系统 11
3.3.3门诊划价管理 11
3.3.4药房管理系统 11
3.3.5院长综合查询系统 12
3.4 系统流程图 12
3.5 系统数据流图 13
3.5.1顶级流图 13
3.5.2 0层流图 13
3.6 数据字典 14
3.6.1数据流条目 14
4 概念结构设计 15
4.1 系统全局实体图 15
4.2 系统各实体图 15
4.3 系统表及其用途 17
5 逻辑结构设计 18
5.1 逻辑设计规范 18
5.2 逻辑结构表 18
6 物理结构设计 19
6.1 数据存储 19
6.2 创建索引 19
7 编码 20
7.1 前台功能设计 20
7.1.1字典维护 20
7.1.2门诊管理 21
7.1.3院长查询 21
8 系统测试 23
8.1 软件测试概述[5] 23
8.2 常用的软件测试方法[6] 23
8.2.1黑盒测试 23
8.2.2白盒测试 24
8.2.3基于模型的测试 24
8.3本系统的软件测试方法 25
9 结束语 26
9.1系统功能总结 26
9.2对系统的展望 26
谢 辞 27
参考文献 28
引言
医院管理系统（Hospital Information System，HIS）在国际学术界已经被公认为新兴的医学信息学（Medical Information）的重要分支。美国该领域的著名教授Morris Collen于1988年曾著文为医院信息系统下了如下定义：利用电子计算机和通讯设备，为医院所属各部门提供病人诊疗信息和行政管理信息的收集、存储、处理、提取和数据交换的能力，并满足所有授权用户的功能需求。[4]经过多年的发展，如今类似医院信息系统这样的企业级应用软件不仅能提供静态的信息和交互式的动态信息服务，还能提供应用程序的基础设施服务（如安全、事务、传输、缓冲、生存期管理等），目前这样的软件所采用N层结构进行构建，N层结构的优点是每一层可以被单独改变，而不影响到其它层，降低了部署与维护的开销[11]。
为了满足以上所述的问题，关键在不仅要重用旧的代码，而且要重用相似的分析设计结果和体系结构，来减少构造新软件系统的代价并提高软件的可靠性。框架技术就是这样一种面向特定领域的重用技术，框架由于提供了大力度的重用而被认为是一种最有前途的面向对象技术。单独的类的重用尽管有用，但由于重用力度小而不具备有意义的生产力的飞跃。基于框架的软件开发过程，把软件的开发看作一个组装过程，在软件框架的指导下寻找可复用构件（及开发一些新构件）并进行系统组装，这种开发过程是目前很受重视的研究方向。目前，针对企业级的应用提出了一些解决方案。微软的.NET框架和SUN公司的J2EE就是两个目前最为流行和成熟的可以简化企业应用中与开发、部署和管理相关复杂问题的体系结构。其中Microsoft.Net由微软在2000年开始推出，是新一代的Windows开发系统平台。.NET平台包含了以下主要特征：[10]
(1) 软件变服务
(2) 基于XML的共同语言
(3) 融合多种设备和平台
(4) 新一代的人机界面
(5) 托管代码公共语言运行库
本文参照软件工程中开发一款软件的相关步骤，结合数据库的有关知识，按照软件定义、软件开发、运行维护的三步骤进行软件的开发。其中软件开发步骤中有所不同，由数据库的概念结构设计、逻辑结构设计、物理结构设计组成。
1 绪论
医院信息管理系统的主要目标是建立一种新型的既能保障全体员工公平地获得基本医疗保健服务，又能有效调控浪费，合理利用医疗资源的社会保障制度。随着科学技术的进步，人民生活的提高，医院信息管理需要进一步的系统化、科学化，医院信息管理系统的建立已经是大势所趋。同时也为了更好的认真贯彻执行国家、省、地市医疗保险改革各项政策，建立职工正常基本医疗和补充医疗保险良好运行机制，经充分酝酿、研究论证，在吸取了各种式样的医院管理系统的经验后，开发了医院管理系统[2]。
预期系统完成后将达到以下六个目标：
(1) 标准化和开发性
(2) 统一性和实用性
(3) 参数化设计和灵活性
(4) 安全性和可靠性
(5) 通用性
我国医院信息系统研制始于20世纪80年代初，医院信息建设大致经历了单机 *** 作、局部网络化、全院信息网络化建设3个阶段。据卫生部信息中心2001年统计，我国应用信息管理系统的医院占医院总数的31%，其中省级医院投资信息管理系统高达84%,地市级和县级医院仅为37%和34%。在全国500多家三甲医院及1000多家县市以上二级医院中，有近900家大中小医院已经实施或正在实施医院信息系统[12]。
医院信息化管理的未来：医院信息化管理建设是一项长期艰巨的任务。医院信息管理系统是由多方面的系统组成，并不断地完善和扩大，使信息化建设覆盖医院各项业务建设。随着信息化技术的发展，医院信息话建设将更注重人性化服务，优化及提高信息化管理系统功能、性能、人机界面及智能化建设是医疗行业发展的必然趋势[13]。
医院信息化建设的根本目的是以病人为中心，实现医院的网络化管理，为临床医疗、经营和管理提供便捷有效的管理手段和管理模式[8]。医院信息化建设的内容包括医疗行为、行政组织、后勤保障等全方位管理模块，涉及挂号、收费、药库、药房、医生工作站、护士工作站、手术、麻醉、财务结算、检查、检验、病案处理、医保、自助信息查询等业务。只有对医院业务流程的优化和重组，进一步强化信息资源的加工、挖掘，才能不断提高医院的医疗服务质量和管理水平，以实现满意的经济效益和社会效益[14]。
2 可行性分析
2.1 经济可行性
鉴于现在的计算机设备价格的逐年下降，在各大中小型的医院中已经具备配备计算机及计算机 *** 作人员的能力。此外，使用一个良好的医院管理系统不仅能提高医院的管理效率、在很大程度上带给就医群众许多方便，最重要的是能使使用医院在未来两到三年内收回成本，从而进一步的盈利。综上几点，说明开发这样一个医院信息管理系统在经济上是可行的。
2.2 技术可行性
技术可行性又可以分为两类：开发本系统的技术可行性以及系统使用者的技术的可行性。本系统是使用.NET高级程序语言开发，基于Microsoft Visual Studio 2005为开发平台，结合Microsoft SQL Server 作为数据源的提供者，所以在系统的开发技术上是可行的；在系统使用者的技术的可行性方面，当今的大学本科毕业生基本上能够熟练掌握WINDOWS *** 作系统的使用，作为一名医学类本科毕业的使用者，只要结合用户说明书就可以熟练地掌握本管理系统的使用方法。可以说在技术上也是可行的。
2.3 政策可行性
卫生部于1997年印发公布的《医院信息系统基本功能规范》，对于加快医院信息化基础设施建设，规范管理，提高医院信息系统软件质量，保护用户利益，推动医院计算机应用的健康发展起到了重要的指导作用。随着计算机网络技术的迅速发展，卫生部重大医改政策的实施及医疗模式的转变，给开发本医院管理系统提供了坚强的政策可行性保障[9]。
3 需求分析
3.1 业务流程
医院管理的基本业务流程如图3.1所示：
图 3.1 医院管理中的业务流程图
3.2 系统层次方框图
该系统由“字典维护”、“门诊管理”、“院长查询”三个一级子模块，“字典维护”子模块由“药品信息维护”、“收费项目维护”两个模块组成；“门诊管理”子模块由“挂号管理”、“划价管理”、“收费管理”、“药房发药”四个模块组成；“院长查询”子模块由“科室挂号量”和“库存统计”两个模块组成。层次方框图如图3.2所示。
图3.2 医院管理系统层次方框图
3.3系统中各模块层次图
3.3.1系统字典维护
“系统字典维护”功能模块用于设置医院管理系统中的常用字典信息，包括了如图3.3所示的子功能模块。
图3.3 系统字典维护模块
3.3.2门诊挂号系统
“门诊挂号系统“功能模块用于建立和维护病人的主索引信息，分配病人的ID号，确保病人信息的唯一性，为病人建立就诊卡，对门诊病人进行挂号或者预约号处理，为门诊病人的后续活动以及门诊工作量统计提供信息。病人首次就医时可办理IC卡、磁卡等，实现一卡通看病，持卡病人就诊时通过刷卡代替频繁的排队交费，可以大大提高医院和病人双方的效率，减少病人的等待时间。挂号时计算机自动分配临时ID号，可选择输入病人姓名，挂号类型（普通号、专家号等）及就诊科室等信息，打印产生门诊挂号单，挂号单上的条码号将是病人接下来各环节就医的依据，这样将实现划价收费、项目检查、药房取药的一体化流水作业。
3.3.3门诊划价管理
“门诊划价收费系统”功能模块用于在门诊收费处记录病人的缴费信息，并执行相应的统计核算功能，所包含的自功能模块如图3.4所示。
图3.4 “诊划价收费系统”功能模块
“门诊划价”用于完成门诊病人各种处方、检查申请、治疗申请等诊治费用的计价工作，各种药品、检查的价格信息在字典管理中维护。
“门诊收费”用于完成门诊病人各种诊治费用的收取工作，能依据划价单（或其他方法）查询病人划价信息，进行费用收取、收据打印处理，并保存 *** 作记录以备查询。
“药品发放”用于药房预先打印需要发货的药品明细，并将药品准备好，这样病人取药时就可以直接给病人，避免医生拿到病人的缴费单后再去找相应的药品。
3.3.4药房管理系统
“药房管理模块”功能用于管理医院药房的采购、入库及出库等业务，包含的子模块如图3.5所示。
图3.5 药房管理模块
3.3.5院长综合查询系统
“院长综合查询系统”功能模块用于从医院信息系统加工处理出有关医院管理的医、教、研和人、财、物分析决策信息，以便院长及管理者决策提供依据。
3.4 系统流程图
医院管理系统的系统流程图如图3.6所示。
图3.6 系统流程图
3.5 系统数据流图
3.5.1顶级流图
根据图3.1的医院管理的基本业务流程图可以首先得出系统的顶级数据流图，如图3.7所示。
图3.7 医院管理系统顶级流图
3.5.2 0层流图
根据图3.7所示的医院管理系统的顶级流图，由软件工程知识：在对数据流图分层细化时必须保持信息连续性，也就是说，当把一个处理分解为一系列处理时，分解前和分解后的输入/输出数据流必须相同。[3]可以对顶级数据流图进行映射，从而得到医院管理系统的0层流图，如图3.8所示。
图3.8 医院管理系统0层流图
3.6 数据字典
3.6.1数据流条目
表3.1描述了系统中所用到的大部分的数据流条目，该表提供了对数据流名字、使用地点与方式、内容和补充信息的说明。
表3.1 数据流条目表
名字 使用地点与方式 内容描述
药品名称 药品信息查询，输入名称 如青霉素
药品编码 药品信息查询，输入编号 如1001
项目名称 收费项目查询，输入名称 如肝功能
项目编码 收费项目查询，输入编码 如8000
开始时间 科室挂号量查询，输入时间 如1998-7-15
结束时间 科室挂号量查询，输入时间 如2008-7-15
库房 药品库存量查询，输入库名 如西药房
药品编号 药品库存量查询，输入药名 如四环素
挂号类型 门诊挂号， 系统已定 分为普通号和专家号
费用类型 门诊挂号， 系统已定 分为公费，自费，离休三种
挂号科室 门诊挂号， 系统已定 分为中医科等16种
医生 门诊挂号，输入医生姓名以记入档案 在院医生的姓名
姓名 门诊挂号，记录病人的姓名 就诊病人的姓名，如张三
性别 门诊挂号，记录病人的性别 就诊病人的性别，如男
年龄 门诊挂号，记录病人的年龄 就诊病人的年龄，如36
民族 门诊挂号，记录病人的民族 就诊病人的民族，如瑶族
4 概念结构设计
4.1 系统全局实体图
系统的的全局实体图如图4.1所示。
图4.1 系统全局实体图
4.2 系统各实体图
根据图4.1 系统的全局实体图，分析系统即可得到系统的各个实体图，如下列图所示。
图4.2 病人实体图
图4.3 医生实体图
图4.4 医生处方实体图
图4.5 药品实体图
图4.6 药房实体图
4.3 系统表及其用途
系统共需要10张表，用途分别如表4.1所示
表4.1 系统表及其用途
表名称 表用途
药品资料 保存医院药品的基础信息，包括售价等
医生资料 保存医生信息，包括医生所属的科室
科室资料 保存科室分类信息，如分为内科、外科等
病人信息库 保存病人的基本信息，以后可以重复使用
门诊挂号 保存门诊病人挂号的信息
门诊挂号类型 保存门诊挂号类型分类信息及其挂号价格，如普通号、专家号等
门诊划价 门诊划价信息（主表）
门诊划价明细 门诊划价明细信息（从表）
门诊收费项目 保存门诊的收费项目及其价格信息，内容包括名称、类型、费用等
5 逻辑结构设计
5.1 逻辑设计规范
数据库逻辑设计就是将E-R图转换成关系模型的过程，即将所有实体和关系转换成一系列的关系模式，转换过程中常见规则有：
(1)一个实体型转换成一个关系模式。
(2)一个一对一的关系模型可转换成一个独立的关系模式，也可与任意一端对应的关系模式合并。
(3)一个一对多的联系可以转换成一个独立的关系模式，也可与多的那一端对应的关系模式合并。
(4)一个多对多的联系可以转换成一个关系模式。
5.2 逻辑结构表
经过数据库系统分析和逻辑设计后，数据库的结构已经非常清晰，首先在Microsoft SQL Server 2000 中建立一个数据库HisBook。然后，分别建立10个表：药品资料表、医生资料表、科室资料表、病人信息库表、门诊挂号表、门诊挂号类型表、门诊划价表、门诊划价明细表、门诊收费项目表、药品库存表，每个表与逻辑设计中一种的关系模式相对应。
表5.1 系统逻辑结构表
6 物理结构设计
6.1 数据存储
数据库采用的是微软MSSQL Server 数据库,安装的版本是:简体中文个人版,数据库文件名称为: hisbook_Data.MDF和日志文件hisbook_Log.LDF,分别存储于系统的默认文件夹下面。
6.2 创建索引
建立索引是加快查询速度的有效手段。用户可以根据应用环境的需要，在基本表上建立一个或多个索引，以提供多种存取路径，加快查找速度。[7]MSSQL Server的两种索引的类型是:聚集索引和非聚集索引,使用索引的优点是：加快查询的速度,不足之处是：它将占用磁盘空间，并且降低添加、删除和更新行的速度，故在使用索引的时候，需要慎重考虑。
针对本系统所涉及到数据库表，所创建的索引是：
表6.1 创建索引字段表
表名 创建聚集字段 创建非聚集索引字段
药品资料 MedID MedName
医生资料 DocID DocName
科室资料 OffID OffName
病人信息库 PatiID PatiName
门诊挂号 PatiRegID PatiRegTime
门诊挂号类型 PatiRegKID 无
门诊划价 PriceKind 无
门诊划价明细 ListID ListName
门诊收费项目 KindID 无
药品库存 MedID MedName
7 编码
7.1 前台功能设计
系统的主要功能有三类：字典维护，门诊管理，院长查询。字典维护功能中主要负责药品信息和收费项目的维护，这是医院为患者提供的最主要的两个服务项目。门诊管理中有门诊挂号、门诊划价、门诊收费、药房发药四个功能，这与平时去医院看病的时候在门诊处经历的过程是一样的，这四个功能处理患者从挂号直到取药离开的整个功能。院长查询主要包括医院各个科室挂号量和当前药品库存量的查询，这两个功能主要用于对医院总体状态的统计。
7.1.1字典维护
单击【字典维护】|【药品信息】命令，可以进入【药品信息】功能窗体，如图7.1所示。在其中可以管理医院目前所有的药品信息。通过单击工具栏上的【新增】、【修改】、或【删除】按钮可以新增药品，修改某个药品的规格，单位或者单价等信息。对数据记录的编辑和输入都是在窗体下方面板中的文本框中进行的，除编辑或新增记录时，窗体下方面板中的文本框都是不可编辑的。
图7.1【药品信息管理】功能窗体
进行药品信息维护之后，单击【字典维护】|【收费项目】命令则可以进入医院收费项目的管理窗体，如图7.2所示。该窗口和【药品信息】很类似，它主要管理医院中所有收费项目的信息。同样通过上面工具栏的按钮，可以对该表进行新增、修改、删除等 *** 作。这个表与药品信息表中数据的标编号是相连的，药品的四位编号首位从1到7，而收费项目编号首位是8开始，这是为了在后面的收费中方便进行处理，因为患者经常同时开药和接受一些检查。因此，在新增编号的时候，用户可以根据患者接受的医疗项目来确定首位编号。
图7.2【收费项目】功能窗体
7.1.2门诊管理
完成字典维护功能后，点击【门诊管理】可以进行门诊挂号、门诊划价、门诊收费、药房发药四项功能，这也是按照一个病人到医院就诊时的基本步骤设计的。
7.1.3院长查询
在【解决方案资源管理器】中，添加一个新的窗体，并将名称改为“RegQuery”，在其上放置控件如图7.3所示。
图7.3 【科室挂号量】窗体
同样的， 添加一个新的窗体，命名为“MedQuery”，在其上放置空间如图7.4所示。
图7.4 【药品库存量】窗体
8 系统测试
8.1 软件测试概述[5]
软件测试是软件开发过程的重要组成部分，是用来确认一个程序的品质或性能是否符合开发之前所提出的一些要求。软件测试的目的，第一是确认软件的质量，其中一方面是确认软件做了你所期望的事情，另一方面是确认软件以正确的方式来做了这个事件。第二是提供信息，比如提供给开发人员或程序经理的反馈信息，为风险评估所准备的信息。第三软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。因此软件测试的第三个目的是保证整个软件开发过程是高质量的。
软件质量是由几个方面来衡量的：一、在正确的时间用正确的方法把一个工作做正确。二、符合一些应用标准的要求，比如不同国家的用户不同的 *** 作习惯和要求，项目工程的可维护性、可测试性等要求。三、质量本身就是软件达到了最开始所设定的要求，而代码的优美或精巧的技巧并不代表软件的高质量。四、质量也代表着它符合客户的需要。作为软件测试这个行业，最重要的一件事就是从客户的需求出发，从客户的角度去看产品，客户会怎么去使用这个产品，使用过程中会遇到什么样的问题。只有这些问题都解决了，软件产品的质量才可以说是上去了。
测试人员在软件开发过程中的任务：
(1)寻找Bug
(2)避免软件开发过程中的缺陷
(3)衡量软件的品质
(4)关注用户的需求
总之，测试总的目标是确保软件的质量以达到用户所要求的水平。
8.2 常用的软件测试方法[6]
8.2.1黑盒测试
黑盒测试，顾名思义就是将被测系统看成一个黑盒，从外界取得输入，然后再输出。整个测试基于需求文档，看是否能满足需求文档中的所偶要求。黑盒测试要求测试者在测试时不能使用与被测系统内部结构相关的知识或经验，它适用于对系统的功能进行测试。黑盒测试的优点有：比较简单，不需要了解程序内部的代码及实现；与软件的内部实现无关；从用户角度出发，能和容易地知道用户会用到哪些功能，会遇到哪些问题；基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；在做软件自动化测试时较为方便。黑盒测试的缺点有：不可能覆盖所有的代码，覆盖率较低大概只能达到总代码量的30%；自动化测试的复用性较低。
8.2.2白盒测试
白盒测试是指在测试时能够了解被测对象的结构，可以查阅被测代码内容的测试工作。它需要知道程序内部的设计结构及具体的代码实现，并以此为基础来设计测试用例。如下例程序代码：
HRESULT Save(char* pszFileName)
{
If (NULL= = pszFileName)
Return
If (STATE_OPEND = =currentState)
{
SaveTheFile()
}
Return
}
读了代码之后可以知道，先要检查一个字符是否为空，然后再根据文件当前的状态来执行相应的动作。设计这样一些测试用例：当输入字符串为空时会出现什么情况；如果此时存储着的一个文件已经被打开，会有什么情况。这些是在做黑盒测试时不一定能做到的事情。
白盒测试的直接好处就是知道所设计的测试用例在代码级上哪些地方被忽略掉，它的优点是帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。白盒测试的缺点有：程序运行会有很多不同的路径，不可能测试所有的运行路径；测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求；系统庞大时，测试开销会非常大。
8.2.3基于模型的测试
基于风险的测试是指评估测试的优先级，先做高优先级的测试，如果时间或精力不够，低优先级的测试可以暂时先不做。有如下一个图8.2.3，横轴代表影响，竖轴代表概率，根据一个软件的特点来确定：如果一个功能出了问题，它对整个产品的影响有多大，这个功能出问题的概率有多大？如果出问题的概率很大，出了问题对整个产品的影响也很大，那么测试时就一定要覆盖到。对于用户很少用到的功能，出问题的概率很小，就算出了问题的影响也不是很大，那么如果时间比较紧的话，就可以考虑不测试[15]。
图 8.1 基于风险测试的两个决定因素
基于风险的两个决定因素就是：该功能出问题对用户的影响有多大，出了问题的概率有多大。其它一些影响因素还有复杂性、可用性、依赖性、可修改性等。测试人员主要根据事情的轻重缓急来决定测试工作的重点。
8.3本系统的软件测试方法
由于本程序是针对小型医院的，软件较小，功能比较简单，所以软件测试方法采用了黑盒测试方法。软件在初步完成后，交由第三者进行测试（这里我让同宿舍的同学进行了测试），第三者在实际使用中发现问题：如需补充功能，运行中出现的一些错误等等，程序开发人员根据第三者提出的意见进行修改，直至软件功能符合用户（系统使用者）为止。
9 结束语
9.1系统功能总结
这个小型的医院管理系统能够简单地完成医院的门诊、药房、院长查询基本功能。但是还没有发票打印的功能，在门诊管理部分还不够完善，没有实现用磁卡对病人进行登记的功能。本系统大致完成了需求分析中所提及的主要功能，对于在一种全新的开发语言的背景下完成这样一个数据库系统，工作量和难度还是非常大的，例如如何在.NET环境下连接数据库，不同模块之间还存在数据 *** 作的错误问题等。
由于在对系统进行设计时的起点和标准过高，在短暂的时间内未能完善全部的子功能、子模块，但是在建立数据库表结构时，始终按照一步到位、不轻易改动的原则，因为一旦表的结构变动了，相应的逻辑结构、前台的显示信息都必须跟着改动，这样带来的工作量是十分大的。
9.2对系统的展望
(1)数据结构问题
像在对系统功能总结中提及到的：没有实现用磁卡对病人进行登记的功能，还未能实现与硬件设备实现连接的接口。
(2)数据的备份和恢复
数据备份功能的实现主要是通过SQL语句BACKUP DATABASE完成的，数据恢复功能的实现主要是通过SQL语句RESTORE DATABASE完成的。由于时间仓促，我没能实现这两个功能。
(3)对.NET语言的认识
因为是第一次使用.NET语言进行相关软件的编程，在三个星期内开发这样一个数据库系统给了我很大的挑战和困难，但在谢老师的鼓励下我本着不断学习的心态，一步步的走了过来，希望这次经历在我以后的学习中将会产生很大的影响。
(4).NET中访问数据库的方法
这个系统是基于.NET框架设计与实现的，在.NET中访问数据库的方法我只是参照一些参考书给出的方法和代码来实现，自己却不是十分清楚它其中的原由。
(5)系统的可扩展性
这次开发的系统还存在着许多可以完善的功能，例如每月或每年一次的财务结算，医院在院职员的信息库的建立等，这都是一个完善的医院管理系统所必须的。
数据库设计
1、数据库需求分析
1）针对超市进销存管理系统，分别对采购部门、销售部门和库存保管部门进行详细的调研和分析，总结出如下的需求信息：
商品按类管理，所以需要有一商品类型信息。
商品必须属于一个商品类型。
如果一个商品类型存在商品，或存在下级商品类型，则该类型不可删除。
需要记录供应商品信息。
在涉及商品数量的地方，要给出相应的单位。
商品销售信息单中要包含登记商品销售数量、单价等信息。
在进货信息中要包含商品供应商等信息。
商品报损要有报损原因。
进货、销售、报损 *** 作要有相应 *** 作员信息。
只有管理员登录之后才可以使用系统。
默认的管理员不可以删除。
进货、销售、库存、报损信息都要可以添加、修改、删除、分类查找。
当进行进货、销售和报损 *** 作后，能相应更新库存。
需要对进货、销售、库存、报损进行分析，总结热门商品。
2）经上述系统功能分析和需求总结，考虑到将来功能的扩展，设计如下的数据项和数据结构：
商品类型信息，包括数据项有：商品类型编号、商品类型名称等。
商品信息，包括的数据项有：商品编号、商品名称、商品介绍、库存量等。
商品单位信息，包括单位编号、单位名称等。
供应商信息，包括供应商名称、介绍等。
进货信息，包括进货商品、数量、单位、单价、进货时间经手人等。
销售信息，包括销售商品、数量、单位、单价、登记时间等。
报损信息，包括报损商品、数量、单位、原因、登记时间等。
管理员信息，包括管理员账号、密码、是否是默认账号等。
2、数据库概念结构设计
本系统根据以上的设计规划出的实体有：商品类型信息实体、商品信息实体、商品单位信息实体、供应商信息实体、进货信息实体、销售信息实体、报损信息实体和管理员信息实体。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）