简介这份医院管理系统数据库设计文档面向计算机相关专业学生及数据库初学者围绕HIS系统的核心需求梳理了医院门诊、住院、药房、财务、检查等部门的业务流程与数据关系适合用作课程设计、毕业设计或数据库原理课程的项目参考。压缩包内共1个docx文档体积约398KB内容完整、可直接阅读。文档从用户需求出发详细介绍了组织机构、业务活动、实体关系建模、表结构转化、外键关联、索引优化以及数据冗余平衡等关键环节并对数据完整性、一致性、安全性、系统性能与法规遵从性做了说明。目前已有173人学习下载对于希望快速理解医院信息系统数据库设计思路、完成数据库建模作业或撰写设计文档的读者具有较强的实用价值。1. 医院管理系统数据库设计一份能直接推导出 20 张核心表的完整需求文档做数据库设计最怕的不是不会画 ER 图而是拿到需求清单后不知道该拆成几张表、表之间怎么挂外键。这份医院管理系统数据库设计文档把我见过的大多数课程设计文档最薄弱的环节补齐了它把门诊和住院两条主线的业务流拆到了单据级从挂号单、门诊病历、门诊处方到医嘱、手术、病案每一类业务对象都给出了明确的数据结构和属性字段。顺着这份文档走一遍你能推导出一套覆盖病人、医生、药品、检查、收费、病区的完整数据库模型而不是只拿到一张空洞的总 E-R 图。文档定位是数据库设计参考不是上线代码。它适合正在做数据库课程设计、刚接触 HIS 系统、或者想把 ER 模型练扎实的人。我拆这份文档时最大的感受是需求分析写得足够细但数据字典部分有前后命名不一致的地方恰恰是这些不一致能帮你把设计规范补得更完整。2. 业务模型先行门诊与住院两条主线的流程拆解2.1 门诊主线从初诊登记到取药离院的单据链路门诊业务流程在文档里描述得最完整。初诊病人到挂号处登记基本信息包括姓名、年龄、住址、联系方式复诊病人不会再次登记直接挂号和就诊排号由挂号处处理病历管理。这里有个容易被忽略的设计要点挂号处承担了建立病人档案和每次就诊排号两件事落到表设计上就应该拆成病人主表和挂号流水表而不是把信息全塞进一张表。病人缴完挂号费后持证明到相应科室就医医生开出诊断结果、处方或检查申请单。这一步是整个门诊流程的分叉点如果开的是处方病人到收费处交费后去药房取药如果开的是检查申请单病人交费后到检查科室做检查检查结果填入结果报告单再交回病人手中病人再回原科室复诊。数据流图里把这步画得很清楚检查科室要做检查记录药房要记录药品出库处方信息从门诊医生流向收费处再到药房。药房的库存是这套流程里的隐含约束。当库存药品减少到一定量时药房需要到药库办理药品申领药库负责出库、入库和采购。也就是说从门诊医生开处方到病人取药中间其实经过了处方、缴费、发药记录、库存扣减、申领单五个环节。做表设计时处方表、收费表、发药记录表、药品库存表、请领单表都需要独立存在不能靠一张药品流水糊弄过去。2.2 住院主线医嘱如何驱动床位、检验、手术和发药住院流程比门诊复杂的地方在于多了病区这个中间层。病人接到入院通知后到住院处办理手续登记基本信息并交预交款或押金然后由病区科室根据病人就诊的科室安排床位录入缴费信息并维护。文档里特意提到病区科室要按照医生开出的医嘱执行医嘱内容包括用药和检查申请这两条分支分别触发不同的下游业务。用药这条分支上病区科室把医嘱中的用药分类综合统计形成药品申领单统一向药库领药再按时按量发给住院病人同时记录发药情况。检查这条分支上病区科室把检查申请单发给检查科室检查科室处理后将检查通知发回病区科室由病区科室通知病人去做检查。这里能看出来住院用药和门诊取药的核心差异门诊是病人自己拿着处方去交费取药住院是病区汇总医嘱后统一申领所以住院侧的药品消耗天然需要申领单-发药记录-病人用药记录三层结构。手术流程的驱动关系也值得注意。病区科室提交手术申请给手术室手术室安排手术日程、准备材料和器械然后发出手术通知回病区科室由病区科室通知病人进入手术室。手术室要记录麻醉记录、术中医嘱、材料器械使用情况。这意味着手术申请表、手术通知单、手术记录、麻醉记录都需要独立建模且都要通过住院号或病人号与住院主记录关联否则一台手术涉及多个病人时数据就乱了。2.3 支撑系统运转的辅助部门与库存闭环门诊和住院两条主线跑通后还要看支撑部门之间的数据关系。药库负责药品贮存、发放和采购药房负责根据处方生成领药单向药库领药同时管理自身库存。文档里明确提到药库要处理药品申领单、管理出库入库和对供应商的采购订单。财务科管医院所有财务业务门诊收费处和住院处分别处理门诊和住院的费用环节检查科室负责检查项目的执行和设备维护病案室保存病人病案手术室管理手术排程和器械耗材。这些辅助部门的业务最终都会沉淀到三张核心表药品相关表、收费相关表和病案相关表。药品供给侧有供应商表和订单表药库有入库出库记录药房有库存和发药记录收费侧有收费项目表挂号费、药品费、检查费作为三个独立金额字段存在病案侧有病人入院科室、入院日期、入院诊断、出院日期、出院诊断这些关键字段。做系统边界划分时文档明确说原始数据录入、数据更新和日常维护由人工完成统计工作交给计算机完成这就是信息系统和手动台账的分工边界。3. 核心模块拆解从数据字典到表结构的设计推导3.1 十六个核心数据项的编码规约文档给了一套完整的数据项清单绝大多数主键采用 char(8) 定长编码挂号号 Gh_no、病历号 Bl_no、处方号 Cf_no、检查序号 Jc_no、药品编号 kind_no、医生号 doctor_no、病人号 People_no、住院号 Zy_no、医嘱号 Yiz_no、药品请领号 B_no。唯一例外是订单号 Dd_no类型长度是 char(20)原因是订单号需要承载供应商、订货批次等更多信息8 位不够表达。这套编码规约在实际建表时有明显的好处所有主键都是定长字符串索引效率比自增整数主键低但可读性好得多业务人员看到编号能直接判断出是哪类单据。缺点是命名风格没有统一医生号有时叫 doctor_no有时叫 Ys_no供应商号同时出现了 Gys_no 和 Trader_no 两种写法。我拆文档时专门做了一张对照表把这些别名对应的字段统一到一套命名规范下否则后面写 JOIN 条件很容易翻车。3.2 数据结构到表的映射一张数据结构一张表文档给出的 15 组数据结构基本可以直接映射成物理表。挂号单包含挂号号、挂号类别、主治医师、挂号人姓名、挂号科室、挂号日期门诊病历包含病历号、病人姓名、主治医师、诊断时间、病历内容门诊处方包含处方号、主治医师、病人姓名、病人性别、病人年龄、处方内容。这些结构里的病人姓名字段在表设计时要从病人表的主键派生不能作为冗余字段直接存否则病人改名或者录入错误时会产生数据不一致。检查项目结构值得单独说一下它包含检查序号、检查医师、检查时间、检查内容、检查分析、检查结果、检查收费。这段设计的亮点是把检查结果和检查收费放在同一张表里好处是统计检查收入时不需要 JOIN 多张表坏处是检查项目单价变化时需要靠冗余记录来保留历史价格。处理方案表包含处理方案号、医师号、开出时间、处理方案内容其中医师号指向医生表这就是典型的外键设计。收费项目表是这套模型里最简练的一张收费项目号、挂号费、药品费、检查费三个金额字段。实际场景里收费项目应该拆成收费明细表但这份文档用单表承载三类费用的设计简化了课程设计复杂度可以接受。3.3 关系与外键病人、医生、药品的关联路径实体关系层面的设计要点集中在几个方向。病人与挂号单是 1 对 N 关系一个病人可以产生多条挂号记录病人与门诊病历是 1 对 N复诊病人的病历应通过病人号关联而不是通过挂号号关联。医生与处方是 1 对 N一个医生可以开出多张处方药库与药品是 1 对 N一张药库库存记录对应一种药品。数据流图里有一条容易忽略的路径药品请领单由药房流向药库药库再把药品出库给病区科室。这条路径在表设计上至少涉及请领单主表、请领明细表、出库记录表而文档的数据字典只有请领单号 B_no 这个字段没有展开明细。做二次开发时这部分要补否则药房和药库之间对账没有数据支撑。3.4 建表 SQL核心表的 CREATE TABLE 示例把上面的映射落到 MySQL我给出核心表的建表语句按这份文档的数据字典来写CREATE TABLE patient ( people_no CHAR(8) NOT NULL COMMENT 病人号唯一编码, name VARCHAR(30) NOT NULL COMMENT 病人姓名, sex CHAR(1) NOT NULL COMMENT 性别M/F, age INT(3) NOT NULL COMMENT 年龄, id_card CHAR(18) NOT NULL COMMENT 身份证号, birth_date DATE NOT NULL COMMENT 出生日期, address VARCHAR(100) DEFAULT NULL COMMENT 住址, phone VARCHAR(20) DEFAULT NULL COMMENT 联系方式, PRIMARY KEY (people_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT病人主表; CREATE TABLE register ( gh_no CHAR(8) NOT NULL COMMENT 挂号号, gh_category CHAR(8) NOT NULL COMMENT 挂号类别, doctor_no CHAR(8) NOT NULL COMMENT 主治医师编号, patient_no CHAR(8) NOT NULL COMMENT 挂号人编号, dept_name VARCHAR(30) NOT NULL COMMENT 挂号科室, reg_date DATETIME NOT NULL COMMENT 挂号日期, PRIMARY KEY (gh_no), KEY idx_register_patient (patient_no), KEY idx_register_doctor (doctor_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT门诊挂号单;注意两处细节病人主表的主键用 people_no挂号单通过 patient_no 外键指向病人表这样同一个病人多次挂号只会在 register 表产生多条记录不会造成病人信息重复存储。挂号日期选用 DATETIME 而不是 DATE因为一天之内可能有多轮挂号只存到日期会丢失时间维度。索引方面挂号单表要给 patient_no 和 doctor_no 建普通索引因为这两列是高频查询条件。4. 从文档到库建库、初始化与统计查询落地4.1 建库与字符集选择建库第一步是把字符集定下来。医院系统的病人姓名、住址、诊断内容都会出现中文如果建库时用了 latin1 或者 utf8生僻字会在写入时报错或变成乱码。我一般会用 utf8mb4它兼容 utf8 全部字符还能处理生僻字和特殊符号排序规则选 utf8mb4_general_ci 即可查询性能比 utf8mb4_unicode_ci 略好中文字段排序需求也不高。CREATE DATABASE his_design DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci;建库时还要注意一个约定表名尽量用业务英文名不要用中文字段注释写清楚中文含义。这份文档的数据字典字段名已经给了英文代码比如 Gh_no、Bl_no直接沿用到建表语句里保持可追溯性即可。4.2 初始化基础字典表建完核心业务表之后需要先初始化一批基础数据。文档里反复出现科室、医生职称、收费项目、药库、供应商这五类基础信息它们不是业务流水表而是业务表的外键依赖。科室表至少要包含科室代码、科室名称、所属部门门诊或住院、负责人医生职称可以简单用代码表存收费项目表则要把挂号费、药品费、检查费三个费用项的当前标准值预置进去。CREATE TABLE dept ( dept_code CHAR(8) NOT NULL COMMENT 科室代码, dept_name VARCHAR(50) NOT NULL COMMENT 科室名称, dept_type CHAR(4) NOT NULL COMMENT 所属部门门诊/住院, leader VARCHAR(30) DEFAULT NULL COMMENT 科室负责人, PRIMARY KEY (dept_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT科室字典表; INSERT INTO dept (dept_code, dept_name, dept_type) VALUES (D001, 口腔科, 门诊), (D002, 内科, 门诊), (D003, 外科, 住院), (D004, 骨科, 住院);有一种常见的做法是把收费项目直接做成一张价目表挂号费、检查费、药品费各是一行带生效日期。这样会比文档里的收费项目表更灵活因为药品价格会调整只保留一个金额字段的话历史对账根本拉不出来。如果想把这份文档升级成能长期用的库这步建议直接做。4.3 统计查询的代表性 SQL业务能跑起来之后真正常用的是三类统计查询门诊收入汇总、药品库存预警、医生工作量统计。门诊收入可以从收费项目表直接聚合因为挂号费、药品费、检查费三个字段都在同一行一条 SUM 就能算出门诊的日收入SELECT DATE(reg_date) AS biz_date, SUM(gh_fee) AS total_gh_fee, SUM(yp_fee) AS total_yp_fee, SUM(jc_fee) AS total_jc_fee, SUM(gh_fee yp_fee jc_fee) AS total_income FROM register r JOIN charge_item c ON r.gh_no c.sfxm_no WHERE reg_date 2024-06-01 GROUP BY DATE(reg_date) ORDER BY biz_date;这段 SQL 的 GROUP BY 落在 DATE(reg_date) 上如果数据量大要考虑加一个日期字段做冗余否则每次统计都要对 datetime 做函数运算索引会失效。药品库存预警可以用条件查询直接做库存量低于阈值就输出到管理端提醒。医生工作量统计则以医生号为分组键统计开处方数和涉及金额支撑文档里提到的根据统计数字完成工资计算这个需求。5. 避坑指南医院数据库设计的高频踩坑记录5.1 现象病历号和挂号号被当成同一个东西用拆这份文档之前我见过好几个照着类似需求做出来的系统复诊时把新挂号号直接当作病历号覆盖写入结果同一个病人的历史病历被新记录顶掉医生复诊时根本看不到以前的诊断内容。原因在于挂号流程里挂号处同时承担了登记病人基本资料和病历管理两件事而数据字典里挂号单和门诊病历是两个独立结构。挂号号标识的是某一次就诊病历号标识的是这个病人的病历档案一个病人可以有多条挂号记录但病历档案只有一份。解决方式是把病历号上升到病人主档层面初诊登记时分配一次之后所有复诊记录都通过病人号关联回同一份病历而不是每次挂号都生成新的病历号。5.2 现象药房库存被并发扣成负数模拟并发发药场景时两个窗口同时给病人发同一种药品执行 UPDATE 后库存变成了负数。文档里的药品表只有数量一个字段完全没有并发控制而药房发药恰恰是医院系统并发最高的操作之一。原因是扣库存的 SQL 写成了先 SELECT 再 UPDATE两条语句之间没有事务包裹也没有条件约束。解决方式是把扣减写成原子操作在一条 UPDATE 里完成判断和扣减。这也是为什么文档里要求当药房库存的药品减少到一定量的时候药房人员应到药库办理药品申领——负数库存会把库存预警逻辑直接打穿。START TRANSACTION; UPDATE drug SET quantity quantity - 1 WHERE kind_no K000001 AND quantity 1; COMMIT;如果影响行数为 0说明库存不足事务需要回滚不允许把负数写进去。更进一步的做法是建一张药品出入库流水表每次发药先记流水再更新库存对账的时候靠流水倒推库存而不是直接信任库存字段。5.3 现象订单号用 8 位不够用文档数据项里出现了两次供应商号一次是 Gys_no一次是 Trader_no类型都是 char(8)但订单号 Dd_no 类型是 char(20)。这里其实暴露了一个常见问题课程设计阶段的数据量预估是每年 10000 张char(8) 能容纳 1 亿个组合看着够用但订单号如果再夹带日期、供应商区域、采购类型这些信息8 位很快就见底。解决方式是直接把订单号设计成业务前缀 日期 序列的组合比如 PO20240601-0001。这样订单号从编码上就能看出是采购订单还天然支持按日期范围检索。供应商号也要统一命名Gys_no 和 Trader_no 二选一否则后续写关联查询时同一个供应商得同时维护两个编号极易踩坑。5.4 现象科室和手术室被设计成字符串字段文档的手术数据结构里直接写了手术室作为组成字段挂号单里有挂号科室医生表里有所在医科这些本来应该指向科室表或手术室表的字段全部做成了普通字符串。如果只是做展示问题不大但一旦要做跨科室统计、手术室排班、科室工作量核算字符串字段就完全使不上力。解决方式是把这类场所/机构概念全部实体化成表。科室表至少要有科室代码、科室名称、所属部门三个字段手术室表要有手术室号、位置、当前状态、可用时段然后业务表里只存代码外键。文档里没有给出这些表但基于流程描述这是最合理的补全方向。设备科、血库、后勤仓库同理凡是后续要按谁、在哪个场所、干了什么事来统计的都拆出来建表。5.5 现象医嘱和处方结构混用文档的医嘱数据结构里写的是诊断单序号、诊断类别、启动日期、处理日期、遗嘱内容注意这里写的是遗嘱但从上下文看显然是医嘱。门诊处方和住院医嘱在业务上差异很大门诊处方是病人自己拿着去交费取药住院医嘱是病区汇总后统一申领药品两者生成时间和执行路径完全不同。如果建表时图省事把医嘱和处方合成一张表就会出现同一个字段一会儿存门诊处方内容一会儿存住院医嘱内容类型长度和状态流转都对不上。解决方式是分成医嘱表、处方表两张表通过统一的病人号关联到病人主档各自维护独立的单据状态这样门诊收费和住院记账也能各走各的流程。6. 二次开发思路把课程设计升级成可用的 HIS 子系统6.1 用视图封装高频统计口径这套设计跑起来之后第一件值得做的事是把第 4 章的统计查询封装成视图。文档是给数据库课程设计用的但实际二次开发时应用层不会直接写复杂的 GROUP BY 和 JOIN视图可以把口径固定下来门诊日收入、住院日费用、医生工作量、药品库存预警。视图的最大价值不是性能而是让多个开发人员写出来的统计结果一致避免同一天收入两个版本。6.2 补药品批次与效期管理文档里药品表只设计了数量、单价、生产日期、保质期但真实药房发药会遵循近效期先出同一药品不同批次的进价也可能不一样。我的做法是把药品表拆成药品档案表和药品批次库存表药品档案表存通用信息批次库存表存批次号、生产日期、有效期、批次数量。发药时从批次库存表按效期排序扣减库存预警按批次维度触发。这一步做完原来的单表库存模型升级成了进销存模型也就有了和供应商订单对账的基础。6.3 挂号与收费界面层的字段对齐最后一步是把表结构和应用层界面做一次字段级对齐。挂号界面录入的是挂号类别、科室、医生、病人基本信息收费界面录入的是收费项目、金额、支付方式。界面字段和表字段之间会有映射差异我一般会画一张界面字段到表字段的对照表逐个确认。最容易翻车的是日期时间格式和金额精度界面传进来的是字符串入库前必须统一转成 DATE、DATETIME 或 DECIMAL(10,2)否则排序和聚合结果全乱。这套文档最值钱的地方是把业务流程拆到了单据级我后来每次做管理系统设计都强制自己先把业务里的每一种单据枚举出来再开始建表。单据列清楚了表结构基本就顺了。希望帮到你。本文还有配套的精品资源点击获取
