医院管理系统数据库设计：门诊住院链路与库存事务落地

简介医院管理系统数据库设计.docx是一份面向计算机专业数据库课程设计、毕业设计及医院信息系统建模入门者的参考文档重点解决医院业务复杂、实体关系多、表结构难以落地的问题。压缩包内仅含1个docx文件约398KB篇幅集中便于通读与摘录。文档从门诊、住院两大部门及药库、药房、财务、收费、检查、血库、病案等科室入手梳理挂号、就诊、处方、缴费、取药、检查、入院、转科、出院等业务流程并给出需求分析、部门关系图与业务流程图进而讨论病人、医生、科室、药品等实体的ER建模、表结构与外键关联以及索引优化、适度冗余、数据完整性、一致性、安全性、并发性能和法规遵从等设计要点。已有175人学习适合用作课程设计选题、需求分析章节和数据库表结构设计的对照材料也可帮助读者理解医院信息系统的整体数据流与模块边界。1. 需求先立住一张挂号单背后到底要落几个字段真正的争议点不是医院表多不多而是单个模型能不能讲清数据的流向。很多同学做医院管理系统数据库设计时第一反应是把所有科室、所有单据全摊开画一张铺满 A3 纸的 ER 图结果答辩时被问一句“初诊挂号之后挂号单里到底要不要存病人姓名”就卡住。答案其实很简单挂号单要能独立还原一笔业务但不需要冗余所有主数据姓名、性别、科室名这些字段在挂号环节只用于窗口核对业务关系靠病人号、科室号两个外键就够了。这类取舍背后是医院管理系统的核心矛盾——门诊和住院两条链路各自结算、各自统计又要在病人主索引上对齐。这套方案面向要交数据库课设或毕设的人也适用于给小型 HIS 做底层的工程师口径统一成“业务为先、模型其次、物理最后”后面几章按这个顺序推。2. 业务链路拆解门诊四态流转与住院闭环的实体抽取2.1 门诊链路挂号、缴费、诊疗、取药四次状态跃迁门诊业务拆成四段每一段以一次状态变更和一次单据落库为终点。第一段是挂号与挂号费。初诊病人在挂号处登记姓名、年龄、住址、联系方式生成一条病人记录并取病人号复诊病人凭身份证号或病历号匹配老记录不重复建人。挂号处随后生成挂号单写挂号类别、诊室号、当值医生号、挂号日期。挂号费作为第一笔收费明细落进收费项目表状态从「未缴」跳到「已缴」。第二段是诊疗。病人到对应诊室医生读挂号单与既往病历出诊断结论再决定开处方还是开检查单。门诊病历记录诊断内容处方和检查单各自独立成表并不合并到病历上。挂号单的 visit_status 从已挂号变为已就诊。第三段是处方与检查缴费。处方和检查单在收费处合并计费。计费不修改处方内容本身只生成收费明细处方状态从已开方变为已缴费。这一步是很多方案漏掉的关键——处方是该不该发药的依据缴费是钱有没有到账的依据两个状态分开管理退费逻辑才写得干净。第四段是取药或检查。药房按已缴费处方发药同时扣减药房库存检查科室按已缴费检查单做检查并回写报告结果。处方状态从已缴费变为已发药检查单从已缴费变为已出报告。四次跃迁对应到表上就是挂号单、门诊病历、处方含明细、检查项目四类主表加上收费项目、药房库存两类支撑表。一个容易判错的地方处方与处方明细必须拆表——一张处方通常包含 1 到 N 种药品每条明细要带药品编号、数量、单价、金额主表只保留处方号、医生号、病人号、开方时间和总金额。合并成一张表遇到三四种药一起开时列数就要膨胀而且明细的用法用量没地方放。2.2 住院链路入科、医嘱、手术、出院的封闭回路住院链路是闭环的起点在住院处中段在病区终点回到住院处再归档。入科住院处写住院登记住院号、病人号、病区号、床位号、预交款生成住院号并锁床位病区按科室和床位把病人分配到对应病区床位同时写病案主索引入院日期、入院诊断、入院科室。这里要强调病案与住院登记是两张表——住院登记回答“这个病人在不在院”生命周期到出院结算为止病案回答“这一次住院的诊疗结论”归档后长期保存后续再住院要另开新病案号。医嘱住院医生逐日下医嘱分用药和检查两类。用药类医嘱按天执行病区每日汇总护理执行记录把用药按药品归类形成药品申领单提交药库药库按申领单出库库存减少病区收到药后逐床发放并把执行情况回写医嘱执行记录。检查类医嘱按单次执行病区把检查单提交检查科室结果回传病区。手术病区提交手术申请给手术室手术室排日程后回手术通知单术中的麻醉记录、术中医嘱、材料器械使用记录全部挂住院号落库。这一步最容易漏的是手术材料——器械、耗材、麻醉药品都要计入本次住院的费用明细不能等到出院再补录。记账药品、检查、手术、床位每一项发生即记账。住院费用明细按住院号做实时聚合预交款不够时住院处给出余额提醒护士站可以看到避免出院结算时才发现欠费太多。出院先在病区办出科登记出院诊断、出院日期再到住院处办出院手续做最终结算病案状态从在院改为已归档。转科的话在原病区办出科、新病区办入科床位重排其余信息沿住院号平移不需要重建住院登记。整个闭环里判断是否建模完整最简单的办法是沿住院号从入院登记出发看能不能走到医嘱、手术、费用明细、病案四张表都要能走出去少一个就代表链路断裂。2.3 科室交叉矩阵与组织结构的表内表达门诊科室和住院科室是交叉的——内科、外科两个科室既有门诊诊室也有住院病区。如果在科室表里直接写「类型门诊/住院」那同一个科室要建两条记录医生归属、床位归属全乱。通常的做法是引入两个维度科室department只描述科室本身门诊与住院的归属通过诊室clinic和病区ward两张表挂到科室上医生、床位、挂号、住院登记都挂到诊室或病区不直接挂科室。科室门诊诊室住院病区内科内科门诊一诊室内科一病区外科外科门诊二诊室外科一病区骨科骨科门诊骨科一病区这样交叉就诊、转科、跨病区借床都不会让科室表变成无底洞。挂号单的科室号就指 clinic_no住院登记的科室号就指 ward_no含义清晰。组织结构也进表。门诊部、住院部这两个大部门用 org_unit 表达parent_no 自关联成树。药库、药房、设备科、财务科、后勤仓库、病案室、手术室、血库、检查科室、门诊收费处、门诊挂号处、问讯处、住院处、行政部门全部挂在这棵树里医生、药品、检查项目、采购订单都挂到具体单元号。日常差的场景是库存统计——如果各处传的是字符串「药房」「药库」代码里就要写一堆 if 分支挂到 org_unit 后按父节点聚合SQL 一句就出来了。3. 概念模型从数据字典到 ER 图的实体归并与关系判定3.1 编号体系为什么全部编号统一用 char(8)数据字典里几乎每个主键都是 char(8)比如挂号号 Gh_no、病历号 Bl_no、处方号 Cf_no、医生号 doctor_no、住院号 Zy_no、药品编号 kind_no。不少人第一反应是换成自增 bigint 或 UUID性能更好也更现代但在课设和中小型 HIS 场景里char(8) 定长编码反而是更稳的选择理由有三个。第一是业务可读。病人在窗口报「我的挂号号是 20240419」比报一长串数字好找得多窗口人员核对和改错成本都低。第二是跨环境同步方便初始化演示数据时可以直接把编码写进 SQL 脚本不依赖数据库自增序列从头开始跑也不会因为两台机器自增起点不同对不上。第三是定长索引的页利用率高小数据量下和 bigint 的性能差可以忽略但编码规则统一之后出错率低得多。编码本身建议用「日期前缀加当日序列」的规则例如挂号号形如 20240419其中前六位是日期、后两位是当日序列处方号走病人号后四位加当日序列递补保证至少唯一。这里有一条血泪经验——编号生成器一定要写成单例按业务类型分前缀不要每个模块各写一套System.currentTimeMillis()的拼接两个模块在同一毫秒生成就会撞车。订单号 Dd_no 是唯一例外char(20)原因是采购订单要和供应商编码、生产地点前缀拼接20 位留出空间。3.2 实体抽取14 类数据结构怎么归并成完整物理表数据字典里给出的数据结构共 14 类直接照抄会出问题原因是有些结构其实是关系、有些其实是视图。归并规则大致是挂号单、门诊病历、门诊处方、检查项目——各自成表成表依据是它们都有独立生命周期的单证订单、供应商——合入采购域供应商独立成表订单挂供应商号药品、药库——拆成药品主表、药房库存、药库库存三张表病人、医生——各自成表处理方案——保留为表和处方区分处方是门诊的药处理方案是医生的诊疗决策可以是建议、非药物治疗收费项目——成表按次生成不要用「挂号费、药品费、检查费」三列塞一张表那样加一个收费项就得改主表结构病案、手术、医嘱——各自成表科室——拆成 department、clinic、ward 三张见 2.3补充表也要提前规划好床位表、病区表、住院登记表、住院费用明细表、处方明细表。原料里这些没独立出现但住院链路一旦走通没有它们就会漏账。最终落到物理上大约是 21 张表覆盖病人、医生、科室、诊室、病区、床位、挂号单、门诊病历、处方、处方明细、检查项目、药品、药房库存、药库库存、收费项目、供应商、采购订单、住院登记、医嘱、手术、病案。课设里写「18 张」是为了对齐数据结构的数实际落地以能走通业务为准。3.3 关系基数与外键走向的判定依据一对多、多对多写反是这类设计最高频的错误。给三条判定规则比背概念快。规则一一张单据的主键进另一张单据如果是一对一那是外键如果是一对多用明细表而不是外键。比如处方1到明细N处方主键进明细表作外键反向不成立。规则二主数据进业务单一定是外键业务单进主数据一定是冗余快照字段。病人号和科室号进挂号单是外键姓名和科室名只在打印需要时保存快照不参与业务判断。规则三交叉关系用关联表不要用两个外键对拼。一个医生可以出诊多个诊室多个医生也可以出同一诊室这就是多对多要建 doctor_clinic 中间表。科室到病区、科室到诊室是一对多直接用外键挂。画完 ER 图再补一道反向校验从挂号单、处方、住院登记、医嘱、手术任何一张业务表出发能不能沿外键走回病人主表走不通说明中间少了一张关联表这是最常见的模型断裂。别等到物理建表时才发现。4. 逻辑与物理设计核心表 DDL、库存联动与索引落地4.1 五张主表的结构定义与字段选型说明下面用 MySQL 8.0 写法给核心表结构语法兼容 MariaDBSQL Server 只需把 AUTO_INCREMENT 换成 IDENTITY、去掉 ENGINE 子句即可。-- 病人主表只放稳定的身份信息不放当前是否住院这类状态 CREATE TABLE patient ( patient_no CHAR(8) NOT NULL COMMENT 病人号8位唯一编码, patient_name VARCHAR(32) NOT NULL COMMENT 姓名, sex CHAR(1) NOT NULL DEFAULT U COMMENT 性别 M/F/U, birth_date DATE NULL COMMENT 出生日期, id_card CHAR(18) NULL COMMENT 身份证号加密存储, address VARCHAR(128) NULL COMMENT 家庭住址, phone VARCHAR(20) NULL COMMENT 联系方式, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (patient_no), UNIQUE KEY uk_patient_idcard (id_card) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT病人主表;这张表最关键的一条纪律是不要放「是否住院」「当前床位」这类状态字段。病人可以在门诊和住院之间来回切他当前的状态放在挂号单或住院登记表上patient 表只承载身份主数据。一旦把状态也放进来每次状态变更就要回写两张表事务边界会扩大好几倍。-- 挂号单每挂一次号一条绝不合并到病人表 CREATE TABLE registration ( gh_no CHAR(8) NOT NULL COMMENT 挂号号, patient_no CHAR(8) NOT NULL COMMENT 病人号, clinic_no CHAR(8) NOT NULL COMMENT 诊室号, doctor_no CHAR(8) NULL COMMENT 当值医生号, gh_type TINYINT NOT NULL COMMENT 1初诊 2复诊 3急诊, gh_fee DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 挂号费, pay_status TINYINT NOT NULL DEFAULT 0 COMMENT 0未缴 1已缴 2已退, visit_status TINYINT NOT NULL DEFAULT 0 COMMENT 0已挂号 1已就诊 2已完成 3已取消, gh_date DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (gh_no), KEY idx_reg_patient (patient_no, gh_date), KEY idx_reg_clinic_status (clinic_no, visit_status, gh_date), CONSTRAINT fk_reg_patient FOREIGN KEY (patient_no) REFERENCES patient(patient_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT门诊挂号单;挂号单上的 pay_status 和 visit_status 一定要分开因为它们不是线性同步的——病人可以先就诊后补缴费欠费处理不能用一个字段表示两个维度。这是课设里最容易合并掉的字段。-- 处方主表只放头信息和总金额 CREATE TABLE prescription ( cf_no CHAR(8) NOT NULL COMMENT 处方号, gh_no CHAR(8) NOT NULL COMMENT 关联挂号号, patient_no CHAR(8) NOT NULL COMMENT 病人号, doctor_no CHAR(8) NOT NULL COMMENT 开方医生号, cf_date DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, total_fee DECIMAL(10,2) NOT NULL DEFAULT 0.00, cf_status TINYINT NOT NULL DEFAULT 0 COMMENT 0已开方 1已缴费 2已发药 3已作废, PRIMARY KEY (cf_no), KEY idx_cf_gh (gh_no), KEY idx_cf_status (cf_status, cf_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT门诊处方主表; -- 处方明细具体药品、数量、单价、金额 CREATE TABLE prescription_item ( cf_no CHAR(8) NOT NULL, seq INT NOT NULL COMMENT 明细序号, drug_no CHAR(8) NOT NULL, qty DECIMAL(10,2) NOT NULL COMMENT 数量, unit_price DECIMAL(10,2) NOT NULL COMMENT 单价, amount DECIMAL(10,2) NOT NULL COMMENT 金额数量×单价, usage_desc VARCHAR(128) NULL COMMENT 用法用量, PRIMARY KEY (cf_no, seq), KEY idx_pi_drug (drug_no), CONSTRAINT fk_pi_cf FOREIGN KEY (cf_no) REFERENCES prescription(cf_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT处方明细;提示处方主表和明细表的边界要以「能不能独立作废」来判。整张处方退费和单条药退费是两个业务动作明细表能承接单条退费主表只承接整张作废。4.2 药房与药库的库存联动事务边界与触发方式库存是这类系统里最容易对不上账的地方。设计的核心是两条规则。规则一药房库存pharmacy_stock和药库库存store_stock是两套账不合并成一张表用 location 字段区分。原因是扣减时机不同——药房库存在发药时扣药库库存在出库给药房或供应商时扣两种操作的事务边界不一样。规则二发药动作必须在一个事务里完成三件事扣药房库存、更新处方状态、写收费明细。任何一件失败整笔回滚。CREATE TABLE pharmacy_stock ( clinic_no CHAR(8) NOT NULL COMMENT 药房所在机构单元, drug_no CHAR(8) NOT NULL COMMENT 药品编号, qty DECIMAL(12,2) NOT NULL DEFAULT 0 COMMENT 当前库存, safety_qty DECIMAL(12,2) NOT NULL DEFAULT 0 COMMENT 安全库存阈值, unit_price DECIMAL(10,2) NOT NULL DEFAULT 0, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (clinic_no, drug_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT药房库存;发药的核心事务START TRANSACTION; -- 1) 锁定库存行防止并发超卖 SELECT qty INTO cur_qty FROM pharmacy_stock WHERE clinic_no :clinic_no AND drug_no :drug_no FOR UPDATE; -- 2) 应用层在这里判断 cur_qty :qty不满足直接 ROLLBACK 并提示库存不足 -- 3) 扣减库存 UPDATE pharmacy_stock SET qty qty - :qty WHERE clinic_no :clinic_no AND drug_no :drug_no; -- 4) 处方状态从已缴费切到已发药 UPDATE prescription SET cf_status 2 WHERE cf_no :cf_no AND cf_status 1; -- 5) 写收费明细药品费 INSERT INTO charge_item (item_no, patient_no, biz_type, biz_no, fee, pay_status, create_time) VALUES (:item_no, :patient_no, DRUG, :cf_no, :amount, 1, NOW()); COMMIT;FOR UPDATE在这一步是必须的不加的话两个窗口同时发同一种药就会出现库存负数。如果数据量变大可以改成UPDATE ... WHERE qty :qty再检查 affected_rows但课设环境用行锁足够逻辑更清楚。药房库存低于 safety_qty 时触发药房向药库申领的动作。这个动作放在发药事务结束之后异步判断不要塞进同一个事务里——库存预警是通知性动作失败不该回滚发药。申领单本身是药房库存与药库库存之间的唯一中间单据后续对账就靠它。注意库存联动里最忌讳的是「先发药后扣库存」的写法演示时看不出问题跑并发或者断网重试时库存就会莫名多出来。扣减动作永远本文还有配套的精品资源点击获取