医院管理信息系统数据库设计_医院住院信息管理系统的数据库设计-CSDN博客

该管理信息系统支持3类用户：医生、病人和系统管理员。医生通过工号和密码登录系统（工号即为医生编号）后,可进行的主要操作有：查看自己的排班情况、接诊病人、开具处方。病人通过用户名和密码登录系统（用户名即为病人编号）,可进行的主要操作有：挂号、缴费、就诊、查询自己的就诊记录和费用明细。系统管理员的主要职责是维护（添加、删除和修改等基本任务）医院的基本信息、科室的基本信息、医生的基本信息、药品的基本信息等工作。

1.2 主要业务处理流程

业务需求分析是根据现实世界对象需求,描述应用的具体业务处理流程,并分析哪些业务是计算机可以完成,而哪些业务是不能由计算机完成。

医院管理信息系统主要业务包括:图书信息发布与查询、订购图书、处理订单并通知配送公司送书等。本节只给出医院管理系统的核心业务“病人挂号”及“医生开处方”处理流程，如图 1所示。

1.3 功能需求分析

功能需求分析是描述系统应提供的功能和服务。根据上述需求概述和业务流程，通过与医务人员和数据库设计人员的沟通与交流，医院管理信息系统的主要功能需求分析如下。

（1）基本数据管理。主要提供科室、医生以及药品的基本信息录入、维护与查询等功能

（2）病人功能管理。主要提供病人登录、病人挂号、病人缴费、查询就诊记录等功能

（3）医生功能管理。主要提供医生登录、查看排班情况、查看需要接诊的病人和开具处方等功能。

（4）科室排班管理

（5）病人治疗情况管理

（6）查询医生工作量

医院管理信息系统的主要功能模块如图所示：

图1-1 医院管理信息系统主要功能模块

1.4 数据需求分析

根据功能需求分析的结果，医院管理信息系统的数据需求分析如下。

（1）科室信息：包括科室编号，科室名称。其中科室编号为科室的唯一标识，在插入数据时由系统按顺序自动生成。

（2）诊室信息：包括诊室编号，所属科室，地点，收费标准。其中诊室编号为诊室的唯一标识，在插入数据时由系统按顺序自动生成。

（3）病房信息：包括编号，所属科室，地点，收费标准。其中编号为病房的唯一标识，在插入数据时由系统按顺序自动生成。

（4）病床信息：包括床位号，病床编号。其中床位号在插入数据时由系统按顺序自动生成。需要注意的是，病床信息需要床位号，病床编号共同标识。

。。。。。。

1.5 业务规则及完整性约束分析

基于上述功能需求和数据需求，通过进一步了解，医院信息管理系统业务规则及完整性约束如下。

（1）门诊分不同科室，一个科室有若干名医生，一位医生只属于一个科室；

（2）病人去医院看医生，可能是初诊，也可能是复诊，复诊可选择原来看过的医生，也可选择其他医生，初诊也可以选择医生；看医生时，病人根据挂号进入相应诊室；

（3）医生坐诊的时间不定，根据排班，有时坐诊，有时需要去住院部治疗住院病人（排班时，门诊坐诊时间和住院部巡诊时间不能冲突）；

（4）病人在挂号时可填入医生编号来指定医生，但指定医生必须此时正在坐诊，若指定医生此时不在坐诊，则需要指定其他医生；

（5）病人在挂号时产生的挂号费自动从账户余额中扣取，若余额不足则挂号失败；

（6）医生为病人治疗，开出处方；处方内容包含症状描述及用药清单，用药清单中包括各种药品的名称、价格、数量、用法等信息，还包括诊疗费用，不同职称的医生诊疗费不同；如院长是100元，副院长是80元，组长是50元；

（7）病人根据处方缴费（本实验假设一律采用线上支付）去药房取药；

（8）病人在拿到处方后，登录账号后输入自己的处方号即可看到该处方需缴的诊疗费用、药品总价以及缴费状态。缴费状态为0则为未缴费，点击确认缴费后自动从病人的账户余额扣取对应的费用（诊疗费用+药品总价），之后该处方缴费状态变为1，提示缴费成功。若账户余额小于对应费用则提示余额不足。对缴费状态为1的账户点击缴费会提升“账单已支付，请勿重复支付”；

（9）药房药品有库存问题，无库存的药品不会出现在医生开处方上，药房管理人员可以查询库存情况；

（10）医生开出的药品数量不能超出库存的数量；

（11）医生在登录账号后可看到自己在挂号中指定自己的病人（即自己的接诊病人），在开处方时，医生可输入病人编号，再勾选上开出的药品及药品数量，点击确认即可开出处方；

（12）病人根据门诊部科室的诊断情况，决定是否住院（办理住院手续：建立住院档案）；

（13）住院部不同科室有固定病房，病人住院时需要安排相应病房的病床；

（14）住院部每位病人都有一位主治医生，而每一位医生可能给多名病人治病；

（15）一位病人可能多次住院，每次住院都建一个住院档案，而一份住院档案只能记载一个病人的情况；

（16）每间病房有多个床位，能住多位病人，而每一位病人只能安排在一间病房中的一个床位；

（17）病人办理住院手续时需要预缴纳住院费，计费系统根据每天的诊疗方案等信息计算当日费用（包括病房床位费等），不足时第二天停止医疗。

（18）医生只有在登录后才可看到仓库药品信息，每个医生只能看到自己的接诊病人以及排班信息。

（19）医生只能对自己接诊的病人开出处方。

2 数据库概念设计

2.1 确定基本实体集及属性

实体集是具有相同类型及相同性质(或属性)的实体集合。通常，一个实体对应一个事物,是名词。发现实体集的步骤可归纳为:

(1)找出需求分析中出现的具有一组属性的“名词”;

(2)分析这些“名词”信息是否需要存储。对于不需要存储的“名词”不必建模为实体集;

(3)分析这些“名词”是否依赖于其他对象存在。如果是,可考虑建模为依赖实体集弱实体集或联系集。

由1.4节的分析可知,医院管理信息系统中出现的“名词”主要有:科室、诊室、病房、病床、处方、药品、病人、医生、排班表、住院记录、排班信息、用药清单、住院档案、挂号单等。显然, 科室、诊室、病房、病床、药品、病人、医生等都是对应为有形的人、物或单位,且都具有一组属性且部分属性能唯一标识每个实体,而且它们需要存储到数据库中供查询用，因此可直接建模为基本实体集。

综上所述, 科室、诊室、病房、病床、药品、病人、医生等可建模为基本实体集。确定了基本实体集后,接下来就是确定各基本实体集的属性和主码。

确定属性的总原则是,只需要将那些与应用相关的特征建模为实体集的属性。确定了属性后,还要进一步分析属性是简单属性还是复合属性，是单值属性还是多值属性等。接下来,就是选择由哪些属性来构成实体集的主码,即能唯一标识各个实体的属性或属性集。

确定属性时一个容易犯的错误是:一实体集将其他实体集的主码作为其属性,而不是使用联系集。换句话说,当一实体集需将另一实体集的主码作为其属性时,需通过建模为联系集来解决。

根据上述原则,各基本实体集的属性定义如下。

(1)科室(Department)实体集。其属性有:科室编号(dNo)、科室名称(dName)。图2-1为科室(Department)实体集的数据字典。