医院住院数据库设计Word文档下载推荐.docx
《医院住院数据库设计Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《医院住院数据库设计Word文档下载推荐.docx（19页珍藏版）》请在冰豆网上搜索。
医院业务规则：
●病房（编号、地点、收费标准，所属科室）
●病床（病房编号、床位号）
●病人（病案号、姓名、性别、地址、电话号码、病房编号）
●医生（编号、姓名、性别、职称、电话号码、部门）
●住院（日期、病案号、入院时间、出院时间、病房编号、床位号）
●治疗（时间、病案号、医生编号、诊断、治疗方案）
一位病人可能有多位治疗医生，而每一位医生又可能给多名病人治病。
每一个病房可能住多位病人，而每一位病人只能住在一间病房中。
一位病人可能有多个住院登记，而一份住院登记只能有一个病人。
病房中有多个床位、一个床位只能在一个病房中。
一个床位可以出现在不同的住院登记上，而一份住院登记只能给病人分配一张病床。
要求完成的主要任务：
1.根据上述的初始条件，进行调查分析并设计适当的属性。
设计一个医院住院数据库，DBMS可选MsSQLServer、Access、VFP等。
2.完成课程设计说明书，其格式遵守学校今年的新规定。
主要内容包括：
需求分析，概念设计，逻辑设计，物理实现等。
3.基于该数据库，最好实现一个或多个应用程序（自己确定功能），程序设计语言（工具）任选。
这一项是选作，不作硬性要求。
时间安排：
本学期第18周：
1.消化资料、系统调查1天
2.系统分析1天
3.总体设计，实施计划2天
4.撰写报告1天
指导教师签名：
年月日
系主任（或责任教师）签名：
年月日
1系统概述
1.1概述
近年来，随着我国人民生活水平的迅速提高，科学技术的进一步发展，医院对医院管理信息系统（HMIS）的需求就越来越迫切，一套好的HMIS在全面提高医院的医疗、教学、科研水平，提高医院整体工作效率，为病人提供方便快捷全面的服务等方面都能发挥出重要作用。
然而由于种种原因，在国内HMIS的使用尚不普及，许多小型医院还是完全依靠手工操作在管理病人和医院员工的一切信息，这不仅劳动强度大且工作效率低，医师护士和管理人员的大量时间都消耗在事务性工作上，对其所掌握的信息也无法很好地统计应用起来，这样既无法提高医院自身的医疗水平，同时又无法很好地为病人服务。
从“医院”概念上来看，住院部是医院的基本组成单位；
从医院管理角度看，住院诊疗是医院业务工作的核心部分。
因此，建立一个高效可靠的住院业务管理系统，不仅可以在一定程度上减轻医务人员的劳动强度，提高工作效率和工作质量，而且可以更及时、准确和有效地分析统计各种临床数据及管理数据，供上级主管部门作出科学的管理决策，促进医院管理水平的进一步提高。
而在整个住院业务管理系统，住院数据库的设计是必不可少的。
1.2可行性分析
首先，硬件和软件要求不高，目前市场上的一般计算机软硬件资源均能满足系统开发需要。
其中软件主要有VB，数据库采用MicrosoftSQLServer2008。
对于该数据库的设计主要以MicrosoftSQLServer2008为主要开发工具，通过ADO方式与VB程序前台相连接，建立了一个基于C/S（客户/服务器）的数据库应用管理系统。
维护工作方便，由于SQL2008的易用性，使得后台的操作十分便捷，操作人员可以在短时间内完全掌握系统的维护工作。
由于医院住院病人数量众多，因而通过电脑化操作可以减少纸张的使用，同时由于数据直接通过局域网传输，可以减少信息传递时间，提高效率，同时也方便医生，病人搜查相关住院信息，提高医院工作透明度和工作效率
2系统目标和建设原则
2.1系统目标
1.方便医院管理病人的住院费用。
2.方便医院管理病人住院期间的病情变化。
3.便于医生根据具体病情及时对病人采取必要的治疗。
2.2基本原则
1.采用生命周期法和原型法相结合的方法开发系统由于本系统开发设计过程中受到各方条件的影响，在开发初期采用生命周期法进行设计开发，严格按照系统规划，系统分析，系统设计，系统实施和系统维护这五个阶段，系统能正常运行后，再进一步调查和分析，其中如有不足之处，再进行合理解决。
2.注重系统的易用性本系统设计过程中力求人性化，结合强大的搜索功能帮助医生、护士、病人随时查找到各自所需的信息，同时在数据录入过程中，尽可能减少人工输入部分，降低人工输入错误的可能性。
3.注重系统的可移植性由于医院整体系统庞大复杂，可以根据需要实际取系统中的部分功能。
同时由于数据库采用微软的SQLServer2008，可以很方便地备数据，转移数据。
3支撑环境计划
3.1网络逻辑结构
本次设计基于的网络逻辑结构是客户/服务器（C/S）体系结构。
C/S是基于资源不对等，并且为了实现共享而提出来的，它由三个主要部分构成：
数据库服务器、客户应用程序和网络。
C/S体系结构的优点在于系统的客户应用程序和服务器构件分别运行在不同的计算机上，这对硬件和软件的变化显示出极强的适应性和灵活性，而且易于对系统进行扩充和缩小。
基于C/S的住院管理系统的结构示意图如图3-1所示
3.2软件支撑环境及开发工具
这次课程设计基本是都是在WINDOWSXP操作系统下完成的。
包括应用程序的开发、数据库的设计以及设计报告的编写。
在这一过程中，应用的开发工具有：
1.VB程序设计语言
2.SQLServer2008
3.MicrosoftOfficeWord2007
4系统总体结构
4.1数据流图的设计
数据流图可以表示现行系统的信息流动和加工处理等详细情况，是现行系统的一种逻辑抽象，独立于系统的实现。
对于本次设计，我将根据系统的业务流程分别来设计数据流图。
对于入院处理的数据流图如图4-1所示
对于治疗处理的数据流图如图4-2所示
对于出院处理的数据流图如图4-3所示
4.2功能结构设计
设计一个系统是要事先了解系统的基本功能，将其分成几个模块分别设计，能够提高设计效率。
对于住院业务管理系统来说，其基本业务功能应该包括：
1）入院管理功能
2）治疗管理功能
3）出院管理功能
4）收费管理功能（收费常常伴随着入院、治疗以及出院管理而发生）
4.2.1入院管理功能流程
对于曾在本医院住院的病人，系统会根据其提供的病案号自动在病案首页表中调出病人基本资料；
而对于第一次在本院住院病人则系统会自动为其产生病案号，工作人员会要求其填写基本资料，填写无误后，将基本资料存入数据库。
其业务流程如图4-4所示。
4.2.2治疗管理功能流程
病人在住院期间，接受医生的治疗是不可避免的。
因此熟悉治疗的流程，对于住院数据库的设计也是必要的。
其业务流程如图4-5所示。
4.2.3出院管理功能流程
病人要住院，当然也要出院。
出院时，系统调出病人的基本资料，对于病人住院期间的各项费用进行统计，开收费单要求病人缴费。
其业务流程如图4-6所示
4.3数据库结构设计
4.3.1数据字典
数据字典是系统中各类数据描述的集合，是进行详细的数据收集和数据分析所获得的主要成果，并且数据字典的内容将在数据库的设计过程中不断的修改、充实和完善。
根据对住院管理系统业务流程的了解，可以定义以下数据结构：
病人、病房、病床、医生、治疗记录和住院登记。
其中在病人、治疗记录和住院登记中都涉及病案号，对于一个病人唯一对应一个病案号，而病案就是治疗记录和住院登记的集合。
4.3.2E-R图设计
E-R图提供了表示实体型、属性和联系的方法。
1）实体型：
用矩形表示，矩形框内写明实体名；
2）属性：
用椭圆形表示，并用无向边将其与相应的实体连接起来；
3）联系：
用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体型连接起来，同时在无向边旁标上联系的类型。
注意：
如果一个联系也具有属性，则这些属性也要用无向边与该联系连接起来。
下面将根据要设计的住院数据库对其中涉及到的实体、实体属性和实体间的联系进行分析和设计。
（1）实体及其属性分析根据本次课程设计所给出的初始条件，目前有以下实体：
病人实体、病房实体、病床实体、医生实体和住院登记实体。
对于这些实体，它们的实体及属性图如图4-7所示：
（2）分E-R图设计在本次设计中，根据任务书所提供的业务规则，实体和实体之间可以有以下几种联系：
1）医生与病人之间的联系，它们之间的联系图如图4-8所示；
2）病人与病房以及病房与病床之间的联系，它们之间的联系图如图4-9所示；
3）病人与住院登记以及住院登记与病床之间的联系，它们之间的联系图如图4-10所示
（3）基本E-R图设计对于分E-R图，它们之间往往存在一些不一致的地方，即冲突。
合并时不能简单的将上述的各个分E-R图画在一起，必须要消除各个分E-R图中的不一致，以形成一个能为全系统所有用户所共同理解和接受的统一的概念模型。
在上述分E-R图上可以做出修改,最终形成的基本E-R图如图4-11所示：
4.3.3关系模型设计
关系模型的逻辑结构是一组关系模式的集合。
将E-R图转换为关系模型实际上就是将实体型、实体型的属性和实体之间的联系转换为一组关系模式，这种转换需要遵守以下原则：
1.一个实体型转换为一个关系模式。
实体的属性就是关系的属性，实体的码就是关系的码。
2.对于实体之间的联系有以下几种情况：
（1）一个1：
1的联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
（2）一个1：
n的联系可以转换成为一个独立的关系模式，也可以与n端对应的关系模式合并。
（3）一个m:
n的联系转换为一个关系模式。
（4）3个或者3个以上的实体之间的一个多元联系可以转换为一个关系模式。
（5）具有相同码的关系模式可以合并。
按照上述的原则，根据设计好的E-R图，可以将其转换为以下一组关系模式，其中关系模式的码用下横线标出。
病房（病房编号，地点，收费标准，所属科室）
此为病房实体型所对应的关系模式。
其中病房编号唯一确定一个病房，所以为该关系模式的码。
病床（病房编号，床位号）
此为病床实体型所对应的关系模式。
由于病房编号是病房关系模式的码，所以在该关系模式中病房编号为外码。
病人（病案号，姓名，性别，地址，电话号码，病房编号）
此为病人实体型所对应的关系模式。
其中病案号为次关系模式的码，而病房编号为该关系模式的外码。
医生（医生编号，姓名，性别，职称，电话号码，部门）
此为医生实体型所对应的关系模式。
其中医生编号唯一确定一个医生，所以为该关系模式的码。
住院登记（日期，病案号，入院时间，出院时间，病房编号，床位号）
此为住院登记实体型所对应的关系模式。
其中，日期和病案号共同确定一个住院登记，病房编号为该关系模式的外码。
治疗记录（治疗时间，病案号，医生编号，诊断，治疗方案）
此为联系“治疗”所对应的关系模式。
其中，病案号和医生编号都是该关系模式的外码。
5总体实施计划
5.1基本表的设计
完成数据库的逻辑和物理设计后，需要运用SQL语言对数据库中所涉及的表进行定义，同时要考虑与表有关的完整性约束条件。
1.建立病人表：
CREATETABLE病人（病案号VARCHAR（15）PRIMARYKEY，姓名VARCHAR（20）NOTNULL，
性别CHAR
（2）CHECK（性别IN（‘男’，‘女’）），
地址VARCHAR（100）NOTNULL，
电话VARCHAR（12），
病房编号CHAR（4）NOTNULL，
FOREIGNKEY病房编号REFERENCES病房（病房编号））；
2.建立医生表：
CREATETABLE医生（医生编号VARCHAR（10）PRIMARYKEY，姓名VARCHAR（20）NOTNULL，
职称VARCHAR（20）NOTNULL，
部门VARCHAR（20）NOTNULL）；
3.建立病房表：
CREATETABLE病房（病房编号CHAR（4）PRIMARYKEY，地点VARCHAR（40）NOTNULL，
收费标准INTNOTNULL，
所属科室VARCHAR（20）NOTNULL）；
4.建立病床表：
CREATETABLE病床（病房编号CHAR（4）NOTNULL，床位号INTNOTNULL，
PRIMARYKEY（病房编号，床位号），
FOREIGNKEY病房编号REFERENCES病房（病房编号））；
5.建立住院登记表：
CREATETABLE住院登记（日期DATENOTNULL，病案号VARCHAR（15）NOTNULL，
入院时间DATENOTNULL，
出院时间DATENOTNULL，
病房编号CHAR（4）NOTNULL，
床位号INTNOTNULL，
PRIMARYKEY（日期，病案号），
FOREIGNKEY病案号REFERENCES病人（病案号），FOREIGNKEY病房编号REFERENCES病房（病房编号））；
6.建立治疗记录表：
CREATETABLE治疗记录（治疗时间DATENOTNULL，病案号VARCHAR（15）NOTNULL，
医生编号VARCHAR（10）NOTNULL，
诊断VARCHAR（50）NOTNULL，
治疗方案VARCHAR（200）NOTNULL，
PRIMARYKEY（治疗时间，病案号，医生编号），
FOREIGNKEY病案号REFERENCES病人（病案号），FOREIGNKEY医生编号REFERENCES医生（医生编号））
5.2关系图设计
根据5.1中所建立的表及其它们之间的关系可以用图5-1来表示
5.3角色的创建
由于不用的系统用户会拥有不同的权限，这样才能保证数据库的安全性。
在这次住院数据库的设计中，主要用户包括管理员、医生和病人。
管理员应该具有超级用户的权限，而医生和病人只能对数据进行简单的查询，不能修改数据库中的数据。
因此在数据库中分别建立3个角色：
role_adin,role_doctor和role_br。
管理员角色的权限设置如图5-2所示，医生角色的权限如图5-3所示，病人角色的权限如图5-4所示。
5.4数据的载入和应用程序调试
在本次住院数据库的设计中，数据载入并不是一次性全部入库的。
对于第一次来医院住院的病人，要为其新建病案，将该病人的信息写进数据库中，而对于已经在医院住过院的病人，只需要调出其病案，当有病人信息需要更改时，须更新数据库。
对于医生的信息的载入，可以先将所有现有医生的资料入库。
如果有新医生的到来或者有医生离开，则需要添加或者删除部分数据。
下表是一个简单的数据入库表：
对于病房和病床资料的录入，基本与医生信息载入相似，下面两张表表现了部分病房与病床的资料：
对于住院登记和治疗记录的数据的载入，它们分别伴随病人住院和医生为病人治疗而产生的。
因此在数据库刚刚设计完成后，只有将原有系统或者手工处理的数据进行转换使之符合新系统的数据模式，从而完成数据输入工作。
由于本次课程设计主要是医院住院数据库的设计，对应用程序的设计不做要求，所以对于应用程序的调试和运行不做描述。
6课程设计小结
这次课程设计，主要是根据教材所讲述的数据库设计步骤，从需求分析到概念结构设计到逻辑结构设计再到物理实现，最后到数据库实施，按照任务书的要求一步步完成的。
因为本次设计主要是数据库的设计，所以仅对应用程序进行了叙述，并没有进行详细设计，这一点应该算是这次课程设计的一个缺陷吧。
尽管没有应用程序的详细设计，但是从课程设计的要求来看，这个住院数据库的设计是满足系统设计要求的。
因此，从总体上看，这次医院住院数据库的设计是比较成功的。
通过本次课程设计我再理论的基础上进一步加强了对于能力的锻炼，从一开始的需求分析，概念设计，逻辑设计，物理实现等，到最后的数据载入、程序调试，其中遇到的种种困难，在自己动手翻阅资料，进行尝试以及同学的帮助下，都一一解决了，最终完成了设计的任务。
7参考文献
1.王珊.数据库系统简明教程.北京：
高等教育出版社，2004
2.王珊，陈红.数据库系统教程.北京：
清华大学出版社，1998
3.互联网
本科生课程设计成绩评定表
序号
评分项目
满分
实得分
学习态度认真、遵守纪律
10
2
设计分析合理性
3
设计方案正确性、可行性、创造性
20
4
设计结果正确性
40
5
设计报告的规范性
6
设计验收
总得分/等级
评语：
注：
最终成绩以五级分制记。
优（90-100分）、良（80-89分）、中（70-79分）、
及格（60-69分）、60分以下为不及格
指导教师签名：
20年 月 日
升级会员 