医院住院管理系统课设报告.docx
《医院住院管理系统课设报告.docx》由会员分享,可在线阅读,更多相关《医院住院管理系统课设报告.docx(32页珍藏版)》请在冰豆网上搜索。
医院住院管理系统课设报告
成绩
课程设计报告
题目医院住院管理系统
课程名称数据库应用程序课程设计
院部名称
专业计算机科学及技术(软件工程)
课程设计地点
课程设计学时
指导教师
设计项目名称:
数据库应用程序课程设计学时:
摘要4
一、课程设计目的和要求5
二、课程设计的仪器和设备5
三、课程设计过程5
1.需求分析阶段5
1.1应用背景5
1.2系统可行性分析5
1.3系统的设计目标6
1.4系统设计概要6
1.5具体系统的业务过程及功能要求6
1.6数据流图7
2.概念结构设计阶段11
3.逻辑结构设计阶段14
3.1把系统的图转换成数据库关系模式如下:
14
3.2数据库中的关系表:
14
4.物理结构设计阶段16
4.1关系模式存取方法的选择16
4.2确定数据库的存储结构16
5.数据库实施16
5.1创建数据库16
5.2创建表17
6.界面设计及程序逻辑代码设计18
6.1开发工具简介18
6.2系统的主界面图19
6.3访问 数据库的方法19
6.4本系统模块以及详细说明19
7.数据库运行维护21
7.1系统运行维护21
7.2系统维护及运行22
7.3数据库备份22
7.4系统测试及出现的问题23
7.5系统存在的不足24
实验体会25
参考文献26
用户系统使用说明书27
摘要
随着科学技术的不断提高,计算机科学已进入人类社会的各个领域并发挥着越来越重要的作用。
作为计算机应用的一部分,使用计算机对信息进行管理,具有手工管理所无法比拟的优点。
医院住院管理系统是现代化医院运营的必要技术支撑和基础设施,实现医院住院管理系统的目的就是为了以更现代化、科学化、规范化的手段来加强医院的管理,提高医院的工作效率,改进医疗质量,从而树立现代医院的新形象,这也是未来医院发展的必然方向。
该系统的实施将在整个医院建设企业级的计算机网络系统,并在其基础上构建企业级的应用系统,实现整个医院的人、财、物等各种信息的顺畅流通和高度共享,为全院的管理水平现代化和领导决策的准确化打下坚实的基础。
该系统的设计主要包括需求分析,概念结构设计,逻辑结构设计,物理结构设计,数据库实施,数据库运行及维护六个阶段。
本系统主要的模块有:
系统设置、入院管理、病房管理、计费管理、出院管理。
本系统前端开发工具使用2008,后台数据库采用2005。
关键词:
医院住院管理;数据库;数据字典;图;2008;2005
一、课程设计目的和要求
课程设计是为了增强学生对所学课程的理解,学会综合地、灵活地运用所学课程知识的一个重要的实践环节。
本课程设计是应用程序设计语言进行数据库应用系统的开发,用进行后台数据库的管理,编写出某一个小型的管理信息系统。
通过本课程设计可以达成如下目标:
1、能够自觉运用数据库原理的理论知识指导软件设计;
2、学会数据库的设计,并能对设计结果的优劣进行正确的评价;
3、学会如何组织和编写信息系统软件设计文档和软件系统的操作说明;
4、具有一定的独立分析问题、解决问题的能力;
5、掌握2005数据库在信息系统开发过程中的应用。
6、掌握使用访问后台数据库的方法。
二、课程设计的仪器和设备
586以上计算机、要求内存256以上2.0以上内存128以上奔腾以上,装有相关数据库软件(本系统后台数据库是2005)和2008以上中文版软件。
该软件可以在98﹑2000、等系统中运行。
三、课程设计过程
本实验根据数据库设计的六个步骤来设计的,即需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施、数据库运行维护。
1.需求分析阶段
1.1应用背景
医院住院管理系统内容对于医疗机构的管理者来说是至关重要的,所以医院住院管理系统应该能够为每一个医疗机构的管理者提供充足的信息和快捷的查询手段,大大的方便医疗机构的管理者的合理管理。
随着科学技术的不断提高,计算机科学日渐成熟,其强大的功能已为人们深刻认识,它已进入人类社会的各个领域并发挥着越来越重要的作用。
作为计算机应用的一部分,使用计算机对病人及医师进行管理,具有着手工管理所无法比拟的优点,如:
检索迅速、查找方便、可靠性高、存储量大、保密性好、寿命长、成本低等。
这些优点能够极大地提高病人及医师管理的效率,也是医疗机构理财的科学化、正规化管理,及先进科学技术接轨的重要条件。
因此,开发这样一套软件是很有必要的事情,对于我们即将计算机专业毕业的学生来说,也是一次将计算机应用于现实的一次很有意义的实践活动。
1.2系统可行性分析
本系统从以下三个方面进行分析:
1.2.1技术可行性
根据现有的和准备充实的设备条件及技术力量来分析系统在技术上实现的可能性,弄清楚现有技术条件能否保证顺利完成开发工作。
医院住院管理系统在技术可行性上完全可以胜任,由于本系统采用单机版,对网络的研究不高,采用2005数据库和编程环境。
在设备条件上,主要考虑计算机的内存容量,外在容量,运算速度,数据精度,汉字功能,多媒体功能,可行性以及对数据传送及通信网络,数据库的需求以及实现的可能性
1.2.2经济可行性
对于每个住院部门,可以根据自己需要,配置性能一般的计算机作为终端,向服务器存储数据或搜索数据。
这些电脑的费用对整个住院系统来说并不是一个很重要的负担。
因此开发本系统是可行的。
1.2.3操作可行性
我们所做的系统是为医院管理人员开发的,所有设定的用户对象是医院的工作人员,而且我们设计了友好的界面,同时写出了详细的使用说明,用户只需懂得简单的计算机操作知识,就能自由应用本软件。
综上所述:
经分析本系统满足以上几个方面的要求,所以开发本系统是完全可行的。
1.3系统的设计目标
系统开发的总体任务是实现医院住院管理的系统化、规范化、自动化、简便化,从而达到医院管理高效率的目的。
1.4系统设计概要
本系统主要有五大模块:
系统设置、入院管理、病房管理、计费管理、出院管理。
详细功能如下:
1、系统设置:
密码修改、用户权限设置、系统备份、退出;
2、住院病人及预交费基本录入、查询、修改管理;
3、医生信息录入、查询和修改;
4、药品信息的录入、查询和修改;
5、科室信息及床位的添加、查询、修改;
6、出院结账的汇总及处理等。
1.4.1系统功能模块图
图1.4.1系统功能模块图
1.5具体系统的业务过程及功能要求
通过对医院住院管理的实际调查分析,得到以下业务流程图:
图1.5医院住院系统处理流程图
1.6数据流图
1.6.1数据流程图
该系统的顶层数据流图下如图所示:
图1.6.1.1顶层数据流图
该系统的第一层数据流图下如图所示:
图1.6.1.2系统设置
图1.6.1.3入院管理
图1.6.1.4病房管理
1.6.2系统的数据字典
1.6.2.1数据流的描述
表1.6.2.1.1
数据流编号:
01
数据流名称:
授予权限
简述:
系统管理员提出权限设置请求
数据流来源:
系统管理员
数据流去向:
权限设置模块
数据项组成:
管理员用户名+普通用户名+权限
表1.6.2.1.2
数据流编号:
02
数据流名称:
密码修改
简述:
修改系统用户的密码
数据流来源:
系统用户
数据流去向:
密码修改模块
数据项组成:
用户名+旧密码+新密码
表1.6.2.1.3
数据流编号:
03
数据流名称:
录入病人信息
简述:
病人申请住院,系统用户录入病人基本信息
数据流来源:
病人本人信息
数据流去向:
电子病历
数据项组成:
住院号+姓名+年龄+科室+床位号+主治医生+血型+住址+科主任
表1.6.2.1.4
数据流编号:
04
数据流名称:
病人信息查询
简述:
系统用户提出查询病人信息请求
数据流来源:
系统用户
数据流去向:
电子病历
数据项组成:
住院号+姓名+年龄+科室+床位号+主治医生+血型+住址+科主任
表1.6.2.1.5
数据流编号:
05
数据流名称:
病床信息管理
简述:
输入科室名,添加、减少病床数
数据流来源:
系统用户
数据流去向:
病床信息表
数据项组成:
科室名+科室号+科主任+病床地址+病床使用情况+病床单价
表1.6.2.1.6
数据流编号:
06
数据流名称:
病床信息查询
简述:
根据病床号,查询显示出病床的使用情况
数据流来源:
系统用户
数据流去向:
病床信息表
数据项组成:
科室名+科室号+科主任+病床地址+病床使用情况+病床单价
表1.6.2.1.7
数据流编号:
07
数据流名称:
费用管理
简述:
输入住院号,记录病人预交费
数据流来源:
系统用户
数据流去向:
病人账单
数据项组成:
住院号+姓名+科室号+药品费用+床位费用+水电费用+检查费用+总费用+预交费+操作员
表1.6.2.1.8
数据流编号:
08
数据流名称:
账单查询
简述:
输入住院号,显示病人费用账单
数据流来源:
系统用户
数据流去向:
病人账单
数据项组成:
住院号+姓名+科室号+药品费用+床位费用+水电费用+检查费用+总费用+预交费+操作员
1.6.2.2处理过程的描述
表1.6.2.2.1
处理过程编号:
01
处理过程名称:
授予权限
简述:
为相应的用户设置相应的权限
输入数据流:
用户名
处理描述:
将某些权限授予选中的用户
输出数据流:
用户权限表
最高流量:
1/秒
平均流量:
1/秒
表1.6.2.2.2
处理过程编号:
02
处理过程名称:
密码修改
简述:
修改系统用户的密码
输入的数据流:
系统用户
处理描述:
用户登录系统,提出密码修改请求,输入旧密码,输入两次新密码,确认提交。
输出的数据流:
用户的新密码
最高流量:
10/秒
平均流量:
5/秒
表1.6.2.2.3
处理过程编号:
03
处理过程名称:
录入病人信息
简述:
病人申请住院,系统用户录入病人基本信息
输入的数据流:
病人本人信息
处理描述:
根据病人提供的个人信息,填写病人信息表,确认提交,存储到数据库
输出的数据流:
电子病历
最高流量:
100/秒
平均流量:
50/秒
表1.6.2.2.4
处理过程编号:
04
处理过程名称:
病人信息查询
简述:
系统用户提出查询病人信息请求
输入的数据流:
病人住院号
处理描述:
输入病人信息,提交,查询显示出病人的信息
输出的数据流:
电子病历
最高流量:
100秒
平均流量:
50秒
表1.6.2.2.5
处理过程编号:
05
处理过程名称:
病床信息管理
简述:
输入科室名,添加、减少病床数
输入的数据流:
科室号或科室名
处理描述:
输入科室号或科室名,添加空病床号和删除不可再使用的病床号,输入地点和单价
输出的数据流:
病床使用情况表
最高流量:
100/秒
平均流量:
50/秒
表1.6.2.2.6
处理过程编号:
06
处理过程名称:
病床信息管理
简述:
输入科室名,显示病床信息
输入的数据流:
科室号或科室名
处理描述:
输入科室号或科室名,显示该科室病床的使用情况,地点和单价
输出的数据流:
病床使用情况表
最高流量:
100/秒
平均流量:
50/秒
表1.6.2.2.7
处理过程编号:
07
处理过程名称:
费用管理
简述:
输入住院号,记录病人预交费
输入的数据流:
系统用户
处理描述:
输入病人的住院号,根据病人实际缴费情况,登记预交费
输出的数据流:
费用账单
最高流量:
100/秒
平均流量:
50/秒
表1.6.2.2.8
处理过程编号:
08
处理过程名称:
账单查询
简述:
输入住院号,显示病人费用账单
输入的数据流:
住院号
过程描述:
输入病人住院号,显示出数据库中病人的账单
输出的数据流:
费用账单
最高流量:
100/秒
平均流量:
80/秒
2.概念结构设计阶段
本系统的图如图下所示:
图2.1医院住院管理总体E—R图
以下是分图:
图2.2病历表图
图2.3床位表
图2.4科室
图2.5收费单据
图2.6药品信息表
图2.7医生
3.逻辑结构设计阶段
3.1把系统的图转换成数据库关系模式如下:
病历(,1,
)
收费单据(收据号,床位费用,餐饮费用,药品费用,检查费用,总金额实收金额,操作员,工号,日期)
处方明细()
床位()
登录表格()
科室()
药品信息()
医生()
属于()
包含(,)
管理()
3.2数据库中的关系表:
表3.1科室
表3.2收费单据表
表3.3病历表
表3.4药品信息表
表3.5床位表
表3.6医生表
4.物理结构设计阶段
数据库在物理设备上的存储结构及存取方法称为数据库的物理结构,它依赖于选定的数据库管理系统。
为一个给定的逻辑数据模型选取一个最适合的应用要求的物理结构的过程,就是数据库的物理设计。
数据库的物理设计的内容包括:
(1)为关系模型选择存取方法;
(2)设计关系、索引等数据库文件的物理存储结构。
4.1关系模式存取方法的选择
确定数据库的存取方法,就是确定建立哪些存储路径以实现快速存取数据库中的数据。
现行的一般都提供了多种存取方法,如索引法、法等。
其中,最常用的是索引法,本系统也采用的是索引法。
我们在经常需要搜索的列和主关键字上建立了唯一索引。
4.2确定数据库的存储结构
由于不同机所安装的数据库软件位置不一定相同,所以数据文件及日志文件的存放位置也不一定相同。
我们存放数据文件及日志文件的位置在:
f:
\。
5.数据库实施
5.1创建数据库
创建数据库
[]
(=N'',=N'F:
\\',=3072,=,=10%)
(=N'',=N'F:
\\',=2816,=2048,=10%)
5.2创建表
创建入库信息表-病历
[].[病历](
[][],
[][],
[][](10),
[][](20),
[][]
(2),
[][],
[][](4),
[][](20),
[][](18),
[1][](11),
[][](6),
[][]
(1),
[][],
[][](20),
[][](10),
[][],
[][](20),
[][](20),
[][],
[][](40),
[][](20),
[][](20),
[][](20),
[][](20),
[014935]
(
[]
)[]
)[]
创建出库信息表-床位表
[].[床位表](
[][](10),
[][](20),
[][][床位表]((0)),
[][],
[床位表_1]
(
[]
)[]
)[]
创建库存信息表-科室
[].[科室](
[][](20),
[][](20),
[][](10),
[][](11),
[科室]
(
[]
)[]
)[]
供应商信息表医生
[].[医生](
[][](10),
[][](20),
[][](20),
[][]
(2),
[][](10),
[][](30),
[][](11),
[03317E3D]
(
[]
)[])
6.界面设计及程序逻辑代码设计
6.1开发工具简介
本系统前端开发工具我们选择2008,后台数据库采用2005。
简介:
是公司最新的2008开发套件中最流行的开发工具,是一种完全面向对象的开发工具。
数据组件以不同方式封装数据访问功能,它具有平台无关性、可伸缩性和高性能的数据访问优点。
、和操作系统的完全兼容决定了它拥有越来越庞大的使用群体,并且能够和2005无缝连接。
2005简介:
2005是公司推出的新一代数据库管理及商业智能平台,是企业级的关系型数据库管理系统。
此版本是微软2000~2005年这5年来具有里程碑意义的企业级数据库产品。
它在企业级支持、商业智能应用、管理开发效率等诸多方面,较2000均有质的飞跃,是集数据库管理及商业智能()分析于一体的极具前瞻性的下一代数据库管理及分析平台。
6.2系统的主界面图
如图6.2所示为系统的主界面图。
主界面图有系统的总功能描述,有对当前使用者及其时间的描述。
图6.2系统主界面图
6.3访问 数据库的方法
本系统是通过语句进行连接的,因为是用的2005所以连接的时候先开头的语句。
进行连接的语句如下:
="()";
=();
();
上面是用本地连接对数据库进行连接的,在连接之前要先添加头文件:
。
6.3.1接连字符串
对象最重要的属性是连接字符串,这也是对象唯一的非只读属性,用于提供登录数据库和指向特定数据库所需的信息。
格式如下:
=”();”
指定服务器名,指定数据库的名字,指明访问它的一种安全机制。
6.3.2创建并使用连接对象
在定义了连接字符串之后,即可进行连接,要先加载头文件:
。
();
连接数据库的两个主要方法是()和()方法使用属性中的信息联系数据源,并建立一个打开的连接.而方法是关闭已打开的连接。
6.4本系统模块以及详细说明
6.4.1系统设置
6.4.1.1密码修改
系统设置包括密码修改,用于修改当前用户的密码。
6.4.1.2数据库备份和恢复
包括数据库的备份和日志文件的备份,可以随时将数据备份到硬盘或优盘保存,以免以后系统出现故障,可以借助这些备份文件进行恢复。
当数据丢失或出现其他故障后,可以从备份文件恢复数据。
6.4.1.3权限管理
用于设置普通用户或是管理员,根据权限不同,所拥有的操作权限不同。
6.4.1.4退出
退出该库存管理信息系统。
6.4.2入院管理
6.4.2.1电子病历
电子病历包括电子病历的录入、修改、删除。
对于病入基本信息及入院信息的录入,修改和删除操作。
若病人曾住院有病史,当输入病人入院号时,会将病人的病史信息显示在里面,当点击任意单元格时,信息会被显示到对应的里面。
用于信息的增加和修改,节省了时间。
若没有病史,会生成新的页面用于信息的录入。
6.4.2.2病人资料查询
用于病人基本信息的查询,可以输入住院号进行查询,也可以输入一个关键字进行模糊查询。
6.4.2.3预交费管理
预交费管理用于病人费用进行管理,可以进行费用的录入和费用的查询。
可以查询病人最近一段时间的费用使用情况。
6.4.3病房管理
6.4.3.1床位管理
床位管理用于各科室床位的添加,删除。
当点击床位管理的时候,系统会自动的将床位信息显示到里面,可以点击修改床位的信息,也可以点击删除,或者添加。
当添加成功之后会有提示信息。
会重新加载,用户可以看到更新之后的情况。
6.4.3.2医嘱管理
医嘱管理有医嘱的查询和医嘱的修改。
6.4.3.3住院信息查询
根据查询类别,包括按住院号,病人姓名,入院信息查询。
查询条件“”和“=”分别对病历表进行模糊查询和绝对查询。
6.4.4计费管理
账本查询:
可以根据输入的住院号进行查询预交费,和费用清单。
也可以点击显示所有患者,在显示的所有患者中,点击自己要查看的病人,即会显示他们的预交费及费用清单。
6.4.5出院管理
出院结算:
病人费用的结算,所有信息的查询。
6.4.6信息管理
6.4.6.1科室管理
用于科室信息的修改,科室的添加和删除。
6.4.6.2医务人员的管理
用于医务人员的添加,删除及以他们信息的修改。
6.4.6.3药品管理
用于药品的管理,添加药品,删除药品,修改药品信息。
对于6.4.6的功能只有管理员才可以操作。
6.4.7登录界面
登录界面:
有新用户的注册,用户登录
7.数据库运行维护
7.1系统运行维护
7.1.1系统维护的定义
系统维护是系统生存周期的最后一个阶段,就是系统开发期后的运行维护期。
它是指在管理信息系统交付使用后,为了改正错误、改进性能和其他属性、满足新的需要而对系统进行修改的过程。
7.1.2工作中常见的问题
“系统维护”是软件生命周期中的一个重要部分,在软件生存周期的头两个时期没有严格而又科学的管理和规划,必然会导致在最后阶段出现问题。
下面列出维护工作中常见的问题。
7.1.2.1软件难以看懂
原来的软件代码的书写习惯非常差,很难阅读,例如使用无规律的变量名称、过长的函数等;而且反复的修改使软件结构混乱,层层嵌套的注释更是难以匹配;没有可以参考的文档,或者文档不全,或者文档太老;现在的维护人员都不知道系统原有的业务逻辑。
7.1.2.2修改带来不良影响
对某一功能模块的修改,需要做多大范围的测试才能保证它没有给其他模块带来负作用呢?
由于各种成本的限制,很多时候只能以“打补丁”的方式来进行修改,而不是全面解决问题,以至于积累了很多潜伏的风险;跟踪软件版本的演化是一件非常困难的事;对程序的修改,导致了文档的不一致。
7.1.2.3原来的软件质量有缺陷
软件本身就有质量问题,只是日常维护已经很不容易,更不要说修改;软件设计时为维护工作考虑得太少,例如对错误给出的提示很不清楚,过分依赖输入数据的正确性;软件的可移植性、可扩展性很差。
设备、软件的更新换代对软件的兼容性提出了巨大的考验。
可是,有几个软件在设计时充分考虑了可移植性呢?
将一套系统从32位机上移到64位机上,即使没有对任何语句进行修改,也必须做全面的测试以保证不会突然当机;软件的易用性不高,必须要专业人员才能维护。
7.1.2.4客户需求不断变化
软件更新的速度赶不上需求变化的速度;原来的技术、模式、结构不能满足新的需求;多次变化后连客户也不清楚到底要什么;层层堆叠的补丁给系统带来了预料之外的负担。
例如不断增加的、过多的报表降低了系统效率。
上述种种问题在现有的没采用结构化思想开发出来的软件中,都或多或少的存在着。
使用结构化分析和设计的方法进行开发工作可以从根本上提高软件的可维护性。
7.1.3维护的内容
7.1.3.1程序的维护
程序的维护是指因业务处理的变化使系统业务出现故障或用户对系统有更高的要求,需要修改部分或全部程序。
修改以后,必须书写修改设计报告。
修改后的原程序,必须在程序首部的序言性注释语句中进行说明,指出修改的日期、人员。
同时,必须填写程序修改登记表,填写内容包括:
所修改程序的所属子系统名、程序名、修改理由、修改内容、修改人、批准人和修改日期等。
7.1.3.2数据的维护
数据维护指对数据有较大的变动。
如安装及转换新的数据库;或者某些数据文件或数据库出现异常时的维护工作,如文件的容量太大而出现数据溢出等。
7.1.3.3代码的维护
随着系统的变化,旧的代码不能适应新的要求,需要修改旧的代码体系或制定新的代码体系。
代码维护的困难往往不在代码本身的更改,而在于新代码的贯彻。
7.1.3.4硬件的维护
硬件的维护主要指对机器、设备的维护,包括日常的保养和发生故障的修复工作。
硬件人员应加强设备的保养以及定期检修