项目清单 包安装运行 官网地址 http://chenqi1990.site

ssm715基于java 的病房管理系统+vue

github 项目仓库 开源仅有后端代码

点击播放视频 ▼

第1章 绪论

1.1 选题动因

到现在为止，互联网已经进入了千家万户，最普通的平民百姓也有属于自己的智能设备，计算机各种技术的储备也是相当的丰富，并且实现也是没有难度，各行各业，包括一些个人，也积极拥抱互联网时代的到来，也可以说是互联网时代的到来把人们都给包在互联网之中。从刚开始的政府办公，国家企业的开头使用，到如今的老百姓都能用上，别说那些普通企业了。计算机就是有这样的魅力，互联网被称为浪潮不是浪得虚名的。采用计算机技术，开发一些软件，实现软件所在的目的，这是一个常理，这个基础的常理缩短了地域之间的联系，提高了地域竞争水准，减低了人力成本和数据存储成本。本课题研究的病房管理系统，也是采用了计算机技术，该系统能够提高病房信息数据的检索速度，使用起来非常的方便。

1.2 目的和意义

在病房管理系统实际操作中，使用者会发现使用起来相当的方便，并且对数据的管理者来讲，也能及时的获得自己想要的数据，对整个数据的所有者能提供强大的帮助，病房管理系统从操作者的角度出发，不管是在数据的接收以及传递，以及处理结果，都有一个很明显的要求，对有效数据的处理，并且形成集合，并且对有效数据集合进行固定化处理，可以得到更有效的数据，有了病房管理系统，让管理层不至于把大量的人力和财力资源消耗在数据处理整合方面，完全可以让不知疲倦的计算机来进行，不仅投入减低，并且产出也不少。互联网时代就是如此，顺之者昌，响应互联网时代，不至于说可以乘风破浪，起码可以降低直接淘汰出局的几率。病房管理系统的出现是顺应时代的。

1.3 论文结构安排

病房管理系统的论文结构将从6个章节进行阐述。具体结构安排如下：

第1章：本章节对本课题的选题动因，本课题的研究目的和意义进行说明。

第2章：本章节对本课题需要运用的环境和技术进行说明。

第3章：本章节对本课题性能，功能进行分析，对系统开发的经济，技术等条件是否可行进行说明。

第4章：本章节对本课题具体的功能进行设计，同时也对系统的数据库进行E-R图设计以及数据表设计。

第5章：本章节对实现的功能的运行效果图进行展示，同时对系统的功能进行说明。

第6章：本章节对系统功能上的测试进行说明，对测试的结果进行分析。

第2章 开发环境与技术

病房管理系统需要提前对功能进行调查分析，并且根据分析结果进行技术上的辩证，可以选择更合理的开发技术以及开发工具。

2.1 Tomcat 简介

只要学习Java Web项目就不得不学习Tomcat。Tomcat是一种免费的开源的一种Java Web项目的容器，完美继承了 Apache服务器的特性，并且里面添加可以自动化运行的Java Web组件，让Java Web项目可以完全的运行到Tomcat里面。对于特大型项目来讲，直接用Tomcat会造成启动变慢，处理有限等，所以对项目进行了前后端分离技术，但是对于需要称不上特大型的项目来讲，普通的大中型项目用Tomcat作为Java Web项目的运行容器是完全够资格的。最重要的是Tomcat完全跟着Java EE，每一次Java EE的升级，Tomcat都会有着对应的版本出现，版本更新速度是非常快的。更新速度快，代表着有技术方面的支持，值得用户使用的，让用户更加信赖Tomcat产品。

2.2 Eclipse简介

Eclipse这款开发工具最最重要的特点就是免费，不管是用来开发任何的东西，哪怕用来教学或者是生产，只要是能带了商业价值的生产都可以免费使用，这一点对于IDEA或者MyEclipse来讲，是非常的具有前瞻性的。免费的也许有很多不足，但是就是因为免费，所以很多人愿意贡献自己的力量，让这款免费的工具可以拥有更多的插件，用起来更加的舒心。可以这么说，Eclipse就是Java语言开发行业的鼻祖，只要是学过Java的人，对Eclipse没有不熟悉的。Eclipse操作起来非常的方便，可以不用安装，直接解压了就可以使用，并且可以在不同的操作系统上面都可以安装到对应的版本。Eclipse是真的不要钱，免费，下载就能用，这么多年以来长期占领着Java开发市场的半壁江山。Eclipse可以在官网上进行捐款，捐款可以支持Eclipse进一步发展，也可以不捐款直接使用，一切随心，不会强求。Eclipse真的是一款良心Java生产工具。

2.3 Navicat简介

Navicat是一款管理数据库的软件。众所周知，所有的数据库只是以特定的存放格式进行存放的，访问也需要特定的接口以及语句进行访问。如果访问数据库都用各种命令，不仅仅是开发效率上会大大的降低，并且看起来也不舒服，对于某些数据或者数据库来讲这样并不友好，如何对数据库进行友好的访问到现在为止，不同的数据库厂商都推出了适合自己数据库的管理工具，但是有一点就是，数据库厂商推出之后，只要能用就行，并没有符合人体工程学，所有的数据库厂商推出的数据库管理工具都是免费的，所以并没有对于数据库管理工具进行过多的优化，用起来相当的不友好，并且各个数据库工具是不能通用的，这一点数据库厂商肯定不会去做匹配其他数据库的管理工具，所以Navicat就应运而生，可以采用Navicat管理各种各样的数据库，可以同时访问各种数据库并且通过不同的连接进行访问，还可以访问不同电脑的数据库，页面操作简单，美观大方，用起来很好用，并且占用电脑资源很小，很适合作为替代其他数据库厂商推出的数据库管理工具使用。

第3章 系统分析

通过对系统的功能进行具体分析，可以参考已经发表过的具有参考价值的文章作为对比，这样能把功能分析的很透彻，并且也会因为功能的分析而对性能也有大致的了解，并且可以预测性能，实现性能分析的结果。

3.1 可行性分析

系统的设计必须符合正常逻辑，所以设计之处，也需要从其他方面来论证其可行性。

3.1.1 经济可行性

开发病房管理系统，存在经济上面的支持，必须经济上的支持才可以有序进行，比如是否需要额外购买开发工具，购买开发电脑，或者从开发技术上是否是免费开源，达到的效果上面是否支出与收入不匹配，这些都需要进行分析。由于开发本系统，开发技术开源且稳定，电脑用正在使用的电脑就能满足，不需要太多的经济支出就可以达到目的，经济可行性通过。

3.1.2 技术可行性

病房管理系统软件主要用到的一些工具，而这些工具正好在学校就使用过，并且网上有很多免费的并且符合的开发工具，技术方面也学过，并且有图书馆的资源和网络资源可以充分利用。所以在技术角度上面来分析是可以的。

3.1.3 操作可行性

操作方面分为开发过程，实现过程，项目具体操作流程。这些因为都学过，并且有其他的项目流程作为参考。总体实现一般就是用户的登录相关，权限分配，基础数据的变更体现。让不同的角色有不同的操作界面，符合正确角色定位，使用者在操作上面并不会感觉到很突兀，影响操作流程。所以操作方面是可以的。

通过以上不同角度的分析，最后论证分析了可行性是没有问题的，完全可以进行后续步骤。

3.2 系统流程分析

操作逻辑是一个可以用画图工具展示的，因为数据在录入过程中的不可见，只能看到返回结果，所以把流程画成图可以更好的理解其中的顺序。

在系统的各项操作中，其他的录入环节，会对操作者具体操作的每条信息都会提出验证要求，比如不能为空，只能是汉字，以及其他的要求等，这些都在前端需要编写清楚，达到友好提示的目的，有效的帮助操作人员理解操作。具体数据的流程如下面的图所示。当操作员输入信息后，点击提交后台就会接收操作员提交的信息，并且提前编写好的逻辑会继续验证，如果数据合格就存入到数据库里并且返回成功提示，这样一个录入环节就达到了设计要求。

图3.1 添加信息流程图

有时候录入的一些数据可能需要修改，修改就是纠正之前的操作，所以修改数据必须是先把想要修改的数据从数据库里获取出来，然后在这个之上进行修改，修改数据也有相应的操作流程。

图3.2 修改信息流程图

数据的查询是在任何程序上都是一个常规的操作，面对的数据量不一样，想要获取想要的数据时间也不一样，都是尽快的获取自己想要的结果，所以数据查询就需要有个查询条件作为查询关键词，这样可以更好的获取符合关键词的数据。

图3.3 查询信息流程图

3.3 系统性能分析

关于病房管理系统从性能需求方面来分析，主要从五个角度分析。五个角度分别从设计的实用性，设计的操作性，设计的安全性，设计的适应性和维护性这五个角度来进行分析。

首先分析第一点，设计的实用性。本设计的目的就是让管理员可以综合的处理各种基础信息，并且有相应的权限来进行操作，达到数据同步，集中管理的目的，并且可以让用户处理用户相关信息，符合设计的既定目标，达到使用效果。

其次分析第二点，设计的操作性。开发出来的系统必须有操作性，如果操作起来丢三落四，出现各种不符合流程的操作，那么就是不符合设计规则的，设计的操作性必须符合人体工程学使用原则，从上到下，从左到右，让操作起来更加的有逻辑性，不需要不符合逻辑的页面数据体验和操作流程，让设计的操作性体现出来，看到操作界面就会有相应的下一步理解。

再次是安全性，虽然从任何角度来讲，安全性应该放到第一位，但是有些时候安全性是在数据量大并且数据重要的前提下才会对数据的安全性来进行设计，正常的软件使用过程只要数据设计合理，并且目标单一，让黑客不屑于或者付出不成正比的情况下，安全性自然可以稍微降低一点，毕竟面对的使用群体决定了安全性的强度。本设计主要是从毕业设计的角度出发，增加一点数据校验的安全性就行，没必要设置硬件防火墙之类的资源，所以安全性上面也是符合的。

再次是适应性。适应性主要是面对各种平台的操作系统，目前本设计的开发可以使用本人电脑进行开发，服务器可以架设到任何地方，并且有对应的服务器软件版本。而用户方面只需要能上网，有最新版本的浏览器进行支持即可，所以适应性是相当不错的。

最后是分析维护性。这一点只需要维护服务端代码即可，每次服务端代码维护都可以先把服务器停止，然后在开发电脑上进行测试，最后测试无误再在服务器上进行部署，维护性并不会增加多少成本。

3.4 系统功能分析

当设计人员通过参考各种文献以及其他类似项目的调研后，就会对项目具体的功能进行分析，这样有的放矢可以更快的设计程序的功能。

病房管理系统的操作者有管理员，分析的管理员功能将使用用例图进行展示。图3.4展示了管理员用例图。管理员对开方类型，药品类型，职位等基础数据进行管理，对病床，病床使用，患者，医护人员，药品，开方等信息进行管理。

图3.4 管理员用例图

病房管理系统的操作者有医生，分析的医生的功能将使用用例图进行展示。图3.5展示了医生用例图。医生增删改查病例，开方，药品信息，查看病床信息以及病床使用信息。

图3.5 医生用例图

病房管理系统的操作者有医护人员，分析的医护人员的功能将使用用例图进行展示。图3.6展示了医护人员用例图。医护人员主要是查看患者，病例，开方信息以及药品信息，查看病床信息以及病床使用信息。

图3.6 医护人员用例图

病房管理系统的操作者有患者，分析的患者的功能将使用用例图进行展示。图3.7展示了患者用例图。患者查看病例，查看开方信息，查看病床使用信息。

图3.7 患者用例图

第4章 系统设计

在系统设计环境，业务的处理逻辑和数据的设计逻辑虽然是重中之重，但是这些都是用户看不见摸不着的，用户也只是能看到部署好的项目运行起来的结果，所以用户对界面布局以及界面功能比较看重。所以说，如今只要是开发网站不仅仅是需要懂一点页面设计就行，也需要懂得UI设计的人群。传统的网页设计其实就是换几个颜色，放几张图片，然后来充实操作页面，让操作页面不至于太单调，但是互联网发展至今，开发也越来越精细化，用户越来越挑剔，还用凑合方式来进行程序开发，已经是属于落后的状态了。

4.1 布局设计原则

布局不是传统的把页面分分类，输入和显示页面，调整调整间距这些笼统的说法了，布局设计也是有一定的原则的。

首先，布局一定要清晰合理。布局的清晰不是说图片清晰或者文字清晰，而是说用户在使用过程中，看到导航的布局，就能明白所有功能模块都可以在导航里寻找，打开一个页面，就能知道重要与不重要的资料，必须与不必须的填写，甚至是输入的格式是什么规格，都可以让用户使用的时候一目了然。因为界面是有限的，所以说布局是相当重要的一点设计原则。

其次，布局的体现要符合大众审美，比如说导航，尽量都是网页的上方或者左侧。如果把导航放到网页下方或者右方，这些代码都是可以实现，但是不符合正常人的思维定向。现代人的读写习惯都是从上而下，从左到右的阅读方式，人们身体和心灵已经习惯了这种方式，如果布局到其他方向首先用户会感到新颖，但是却不会买账，因为操作几遍后就会不习惯。

最后，布局也要考虑这个软件是用来做什么的，常用这个软件的人员的年龄划分，性别划分，以及职业划分。划分了使用人群，就可以对背景进行调色填充，如果是长时间用电脑的人群尽量设计的有护眼功能，不至于看一会眼睛就受不了，尽量要区分长时间使用和短时间使用的背景，这一点很重要。

综上所述，系统设计需要考虑方方面面，布局设计也是需要精细化考虑，系统设计需要考虑太多，但是实现却不能弄得操作上太复杂，系统设计尽量的要满足用户需要，提高用户满意度。

4.2 功能结构设计

在基于系统功能分析的基础之上，开始对系统的详细功能进行设计，最终将使用结构图的形式对设计的结果进行展示。

管理员具备的详细功能将参照最终的设计结果，即图4.1所示的管理员功能结构图。其中管理员对开方类型，药品类型，职位等基础数据进行管理，对病床，病床使用，患者，医护人员，药品，开方等信息进行管理。

图4.1 管理员功能结构图

医生具备的详细功能将参照最终的设计结果，即图4.2所示的医生功能结构图。其中医生增删改查病例，开方，药品信息，查看病床信息以及病床使用信息。

图4.2 医生功能结构图

医护人员具备的详细功能将参照最终的设计结果，即图4.3所示的医护人员功能结构图。其中医护人员主要是查看患者，病例，开方信息以及药品信息，查看病床信息以及病床使用信息。

图4.3 医护人员功能结构图

患者具备的详细功能将参照最终的设计结果，即图4.4所示的患者功能结构图。其中患者查看病例，查看开方信息，查看病床使用信息。

图4.4 患者功能结构图

4.3 数据库设计

数据库的选用方面肯定要选一个市场反应比较好，性价比比较高的数据库，不能凭空想象数据库，要结合程序设计的需求来选择对应的数据库。目前来讲，市面上常用的关系型数据库足够达到需求。

4.3.1 数据库E-R图设计

想好更好的设计出数据库使用效果，那么就要对数据的存放格式以及存放关系作出调查和梳理，所以通过分析E-R图之间的数据实体关系是最好不过的。而设计数据库E-R图是有下面几点好处：

第一点：数据的冗余是一件很恐怖的事情，所以要对有些数据进行冗余筛选；

第二点：防止内存溢出，数据量太大，需要提前做好预测并且设定好规则；

第三点：数据库一定要完整，非完整数据也只是数据垃圾而已，没有任何作用；

第四点：提高数据检索性能；

这节主要是描述对系统的E-R模型的设计，数据存储格式的判断，实现的方法，用户的需要，这些都要统一，不能想当然。并且各个模型中间的关系尤其要突出。

（1）把患者具备的属性通过属性图进行展示，绘制的属性图见图4.4。

图4.4 患者实体属性图

（2）把开方具备的属性通过属性图进行展示，绘制的属性图见图4.5。

图4.5 开方实体属性图

（3）把医生具备的属性通过属性图进行展示，绘制的属性图见图4.6。

图4.6 医生实体属性图

（4）把病例具备的属性通过属性图进行展示，绘制的属性图见图4.7。

图4.7 病例实体属性图

（5）上述实体间关系见图4.8。

图4.8 实体间关系E-R图

4.3.2 数据库表结构设计

数据库设计必须符合规范，那就是三大范式，这样能确保数据的合理：

第一范式：保证表之间的字段关系不存在混淆的描述，必须描述准确，并且单一，不能分解；

第二范式：在上述的满足条件上，主键的设计必须要在固定的列上，不能忽前忽后；

第三范式：继续满足上个条件，保证每个字段都可以根据主键获取到，并且在一个数据表里体现。

所以说，三个范式是一脉相承的，不是说零碎的，从第一个范式上就会发现，第一个永远是基础，后面的设定就是后者的实现必须在前面范式的基础之上的要求，这些设计可以最大化的减少数据冗余，提高数据库运行效率。

表4.1 病床表

字段	注释	类型	空
id (主键)	主键	int(11)	否
bingchuang_uuid_number	病床编号	varchar(200)	是
fangjian_name	房间名	varchar(200)	是
fangjian_address	房间位置	varchar(200)	是
chuanghao	床号	varchar(200)	是
shifoushiyong_types	是否使用	int(11)	是
insert_time	记录时间	timestamp	是
create_time	创建时间	timestamp	是
表4.2 病床使用表

字段	注释	类型	空
id (主键)	主键	int(11)	否
huanzhe_id	患者	int(11)	是
bingchuang_id	病床	int(11)	是
bingli_uuid_number	病房使用唯一编号	varchar(200)	是
ruzhu_time	入住时间	timestamp	是
likai_time	离开时间	timestamp	是
zhuangtai_types	状态	int(11)	是
insert_time	记录时间	timestamp	是
create_time	创建时间	timestamp	是
表4.3 病例表

字段	注释	类型	空
id (主键)	主键	int(11)	否
huanzhe_id	患者	int(11)	是
bingli_uuid_number	病例编号	varchar(200)	是
zhuyuan_time	住院时间	timestamp	是
yichuan_text	遗传史	text	是
zhusu_text	患者主诉	text	是
zhenduan_text	诊断结果	text	是
insert_time	记录时间	timestamp	是
create_time	创建时间	timestamp	是
表4.4 患者表

字段	注释	类型	空
id (主键)	主键	int(11)	否
username	账户	varchar(200)	是
password	密码	varchar(200)	是
huanzhe_name	患者姓名	varchar(200)	是
huanzhe_phone	患者手机号	varchar(200)	是
huanzhe_id_number	患者身份证号	varchar(200)	是
huanzhe_photo	患者照片	varchar(200)	是
sex_types	性别	int(11)	是
age	年龄	int(11)	是
huanzhe_email	电子邮箱	varchar(200)	是
hunyin_types	婚姻	int(11)	是
xian_address	现住址	varchar(200)	是
huji_address	户籍地址	varchar(200)	是
create_time	创建时间	timestamp	是
表4.5 开方表

字段	注释	类型	空
id (主键)	主键	int(11)	否
huanzhe_id	患者	int(11)	是
kaifang_uuid_number	开方编号	varchar(200)	是
kaifang_name	药方名称	varchar(200)	是
kaifang_types	开方类型	int(11)	是
kaifang_content	开方内容	text	是
insert_time	开方时间	timestamp	是
create_time	创建时间	timestamp	是
表4.6 管理员表

字段	注释	类型	空
id (主键)	主键	bigint(20)	否
username	用户名	varchar(100)	否
password	密码	varchar(100)	否
role	角色	varchar(100)	是
addtime	新增时间	timestamp	否
表4.7 药品表

字段	注释	类型	空
id (主键)	主键	int(11)	否
yaopin_uuid_number	药品编号	varchar(200)	是
yaopin_name	药品名称	varchar(200)	是
yaopin_photo	药品照片	varchar(200)	是
yaopin_types	药品类型	int(11)	是
yaopin_kucun_number	库存数量	int(11)	是
yaopin_content	药品详细介绍	text	是
create_time	创建时间	timestamp	是
表4.8 医护人员表

字段	注释	类型	空
id (主键)	主键	int(11)	否
username	账户	varchar(200)	是
password	密码	varchar(200)	是
yihurenyuan_name	医护人员姓名	varchar(200)	是
yihurenyuan_phone	医护人员手机号	varchar(200)	是
yihurenyuan_id_number	医护人员身份证号	varchar(200)	是
yihurenyuan_photo	医护人员头像	varchar(200)	是
sex_types	性别	int(11)	是
yihurenyuan_email	电子邮箱	varchar(200)	是
yihurenyuan_zhiwei_types	医护职位	int(11)	是
create_time	创建时间	timestamp	是
表4.9 医生表

字段	注释	类型	空
id (主键)	主键	int(11)	否
username	账户	varchar(200)	是
password	密码	varchar(200)	是
yisheng_name	医生姓名	varchar(200)	是
yisheng_phone	医生手机号	varchar(200)	是
yisheng_id_number	医生身份证号	varchar(200)	是
yisheng_photo	医生头像	varchar(200)	是
sex_types	性别	int(11)	是
yisheng_email	电子邮箱	varchar(200)	是
keshi_types	科室	int(11)	是
zhiwei_types	职位	int(11)	是
yisheng_shanchang	擅长	varchar(200)	是
yisheng_rongyu	所获荣誉	varchar(200)	是
create_time	创建时间	timestamp	是

第5章 系统实现

下面主要是对系统实现的功能进行描述，一般在系统实现阶段只算是一个粗略的功能实现，可能符合开发人员的设计预期，但是对于具体使用者来讲还是需要其他人进行发现的，所以这个环节是很有必要进行描述的。

5.1 管理员功能实现

5.1.1 患者管理

实现患者管理功能，其界面运行的效果图见图5.1。患者信息有现住址，户籍地址，婚姻，患者照片，性别等信息，管理员可以修改有错误数据的患者信息，以及使用删除功能删除需要删除的患者信息等。

图5.1 患者管理界面

5.1.2 病床管理

实现病床管理功能，其界面运行的效果图见图5.2。病床信息有房间名，房间位置，床号，是否使用等信息，管理员修改有错误数据的病床信息，使用删除功能删除需要删除的病床信息，或者使用床号，房间名实现对病床信息的查询。

图5.2 病床管理界面

5.1.3 病床使用管理

实现病床使用管理功能，其界面运行的效果图见图5.3。病床使用信息也需要管理员登记，其中包括病床编号，患者手机号，患者入住时间，状态等信息，病床使用信息有错误，管理员需要修改，对于需要清理的病床使用信息，管理员使用删除功能即可删除。

图5.3 病床使用管理界面

5.2 医生功能实现

5.2.1 病例管理

实现病例管理功能，其界面运行的效果图见图5.4。医生为患者看病之后，为患者添加病例信息，包括患者主诉，诊断结果，住院时间等信息，医生也能修改登记错误的病例信息，以及通过病例编号实现对患者病例的查询。

图5.4 病例管理界面

5.2.2 开方管理

实现开方管理功能，其界面运行的效果图见图5.5。医生针对患者病情的诊断结果开具处方，其中包括药方类型，开发类型，开方时间等信息，以及医生对开方信息进行修改，查询等。

图5.5 开方管理界面

5.2.3 药品管理

实现药品管理功能，其界面运行的效果图见图5.6。在该界面，医生负责添加药品，修改添加错误的药品信息，删除需要删除的药品信息，以及管理药品的库存，主要管理方式是增加药品的库存，或对药品库存进行减少等操作。

图5.6 药品管理界面

5.3 医护人员功能实现

5.3.1 病床使用查看

实现病床使用查看功能，其界面运行的效果图见图5.7。医护人员查询病床使用信息，查询前，可以提供患者姓名，病床编号，状态等查询条件来查询病床使用信息。

图5.7 病床使用查看界面

5.3.2 病例查看

实现病例查看功能，其界面运行的效果图见图5.8。医护人员查询患者病例，查看病例的诊断结果，住院时间，患者主诉信息等。

图5.8 病例查看界面

5.3.3 开方查看

实现开方查看功能，其界面运行的效果图见图5.9。医护人员查询医生为患者开具的药方，以及对开方的药方名称，开方时间等信息进行查看。

图5.9 开方查看界面

5.4 患者功能实现

5.4.1 病例查看

实现病例查看功能，其界面运行的效果图见图5.10。患者查询病例，查看诊断结果等详细信息。

图5.10 病例查看界面

5.4.2 开方查看

实现开方查看功能，其界面运行的效果图见图5.11。患者查询开方，查看药方名称，开方编号，开方类型等信息。

图5.11 开方查看界面