简介：这份文档面向计算机专业学生与数据库初学者，聚焦医院管理系统数据库设计这一典型课程设计场景，帮助读者理清从需求分析到关系模型落地的完整思路。内容围绕门诊与住院两大部门展开，梳理挂号、收费、药房、检查、病案等科室的业务流程，并归纳数据完整性、一致性、安全性、系统性能、可扩展性与法规遵从等设计要点，同时给出ER图转表、外键关联与索引优化的实践方向。资源包共1个docx文件，约398KB，以文字与结构图形式呈现需求分析与机构组织关系，便于直接参考或改写为课程报告。目前已有174人学习下载，适合需要完成数据库课程设计、撰写设计文档或准备相关答辩的读者对照使用，可从中获取业务流程梳理、实体关系划分与文档组织结构的参考范例。
1. 从一份“仅供参考”的文档说起：医院管理系统数据库设计到底交付了什么
拿到这份《医院管理系统数据库设计.docx》的时候，我第一反应是把它当成一份普通的课程作业——封面写着“文档仅供参考，不当之处，请联系改正”，指导教师、班级、院系、小组成员全是星号占位。但真正翻完二十多页之后，我发现它其实是一份相当完整的数据库设计交付物：需求分析、组织机构图、门诊与住院两条业务主线、数据字典（数据项、数据结构、数据流、数据存储、处理过程）、以及若干张表的字段级定义。换句话说，它不是代码，但它决定了后面所有代码怎么写。
这份资源适合两类人。一类是正在做课程设计或毕业设计、需要一份能直接对照着建表的需求分析范本的学生；另一类是接手了医疗类信息系统、需要快速理解“门诊挂号—收费—就诊—取药—检查”和“住院登记—排床—医嘱—手术—出院”这两条业务闭环的开发者。它不提供可运行的程序，提供的是数据模型的地基。地基打歪了，后面写多少 CRUD 都是返工。所以这篇笔记我不讲空话，直接按“这份文档怎么读、怎么变成表、怎么跑起来验证、怎么改”的顺序拆。
2. 需求分析拆解：门诊与住院两条业务主线怎么落到实体上
2.1 组织机构与部门职责决定了实体边界
文档里把医院拆成门诊部门和住院部门两大块，下面挂口腔科、内科、外科、骨科等科室，再往外延伸出药库、药房、设备科、财务科、后勤仓库、门诊收费处、门诊挂号处、问讯处、住院处、检查科室、血库、病案室、手术室以及行政部门。这段看着像背景介绍，实际上是实体划分的依据。
我的读法是：每一个有独立业务动作、且需要留存记录的部门，背后至少对应一个实体或一张单据表。挂号处对应挂号单，收费处对应收费项目，药房对应药品发放记录和请领单，药库对应药品库存和采购订单，检查科室对应检查申请单和结果报告单，手术室对应手术申请单和手术通知单，病案室对应病案。行政部门在这份设计里没有展开，属于合理留白——真要做权限模块时再补。
这里有个容易翻车的点：文档里门诊和住院下设的部分科室是交叉的（内科、外科两边都有）。如果按“科室名”做主键，立刻撞车。正确做法是科室表用独立科室编号，再用一个“科室归属类型”字段区分门诊/住院，或者干脆建科室表加科室-部门关联表。文档没写这一层，但建表时必须补。
2.2 门诊业务链路：从挂号到取药的六个状态
文档用一张流程图描述了门诊流程：初诊病人到挂号处登记基本信息并挂号，复诊病人直接挂号排号；到收费处缴挂号费；持凭证到相应科室就诊；医生开处方或检查申请单；处方到收费处交费后去药房取药，检查单交费后去检查科室检查；检查结果回到原科室复诊；药房库存低于阈值时向药库申领。
把这条链路翻译成数据流，核心是单据的流转，不是人的流转。挂号单产生后，收费记录挂靠挂号单；处方单挂靠就诊记录；收费记录挂靠处方单；发药记录挂靠处方单。每一跳都要能追溯，否则对账就是黑匣子。
文档的数据流部分给了几条关键定义，我摘出来对照：
| 数据流名称 | 数据来源 | 数据流向 | 涉及数据结构 |
|---|---|---|---|
| 挂号登记 | 病人 | 挂号单 | 病人、挂号单 |
| 处方信息 | 门诊医生、收费处 | 药房 | 医生、药房 |
| 检查单 | 门诊医生 | 检查部门 | 门诊医生、检查部门 |
| 病历 | 门诊医生 | 门诊挂号处 | 门诊医生、门诊挂号 |
| 药品请领单 | 药房 | 药库 | 药房、药库 |
| 药品采购单 | 供应商 | 药库 | 供应商、药库 |
这张表的价值在于：它直接告诉你哪些字段是外键。比如“处方信息”来源是医生和收费处，那处方表里就必须有医生编号和收费单号（或至少能关联到收费记录）。
2.3 住院业务链路：床位、医嘱、手术三个高频变更点
住院部分比门诊复杂，文档描述的顺序是：病人持入院通知单到住院处登记基本信息、交预交款；病区科室安排床位、录入缴费信息；医生开医嘱（用药、检查申请）；病区科室把用药汇总成药品申领单向药库领药并按医嘱发药；检查申请单转检查科室，结果回病区；需要手术时病区提交手术申请，手术室排日程、备器械、发手术通知，术中记录麻醉、术中医嘱、材料器械使用；出院时病区登记出科，住院处办出院手续；转科则在病区办转科手续，另一病区重新排床。
这条链路里数据变更最频繁的是三张表：床位表（排床、转床、出科释放）、医嘱表（启动、执行、停止）、手术表（申请、排期、完成）。文档的数据结构定义里，医嘱的组成是“诊断单序号、诊断类别、启动日期、处理日期、遗嘱内容、主治医师、病人”，手术的组成是“手术序号、主刀医师、住院号、病人、手术名称、手术日期、手术结果、手术室”。注意医嘱里写的是“遗嘱内容”，这是原文的笔误，实际应为“医嘱内容”，建表时字段注释要写对，不然接手的人一脸问号。
床位这块文档只给了“病床号 char(8)”这一个数据项，没有给床位表结构。按这个场景的常见做法，床位表至少要有床位编号、病区编号、房间号、床位状态（空闲/占用/预留）、当前住院号。状态字段是排床逻辑的核心，没有它并发排床必然冲突。
3. 数据字典落地：从 char(8) 编码到可执行建表语句
3.1 数据项与编码规则：为什么主键统一用 char(8)
文档的数据项部分列了十几个编码：挂号号 Gh_no、病历号 Bl_no、处方号 Cf_no、收费项目号 Sfxm_no、检查序号 Jc_no、供应商号 Gys_no、药品编号 kind_no、医生号 doctor_no、病床号 Bc_no、病人号 People_no、处理方案号 Clfa_no，全部是 char(8)，描述统一为“8 位组成唯一编码”。订单号 Dd_no 是 char(20)，病区号 Bq_no 是 char(10) 但描述又写“8 位组成”，前后不一致。
这种统一长度的编码设计在教务/课程设计场景里很常见，好处是格式整齐、便于人工核对，坏处是业务含义全靠约定。真落地时我一般会保留 char 类型但加约束，同时补一个自增代理键或者用序列生成，避免应用层手拼编码撞号。下面是我按文档字段整理出的核心建表语句，以 MySQL 为例，字段名沿用文档的英文别名，长度按文档定义：
-- 病人表：文档“病人”数据结构 + 门诊病人数据字典合并 CREATE TABLE patient ( people_no CHAR(8) NOT NULL COMMENT '病人号，8位唯一编码', br_name VARCHAR(32) NOT NULL COMMENT '病人姓名', br_sex CHAR(1) NOT NULL COMMENT '性别 M/F', br_age INT COMMENT '年龄', id_card VARCHAR(18) COMMENT '身份证号', birth_date DATE COMMENT '出生日期', address VARCHAR(128) COMMENT '住址', phone VARCHAR(20) COMMENT '联系方式', PRIMARY KEY (people_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='病人基本信息'; -- 医生表：文档“医生”数据结构 CREATE TABLE doctor ( doctor_no CHAR(8) NOT NULL COMMENT '医生号', doc_name VARCHAR(32) NOT NULL COMMENT '姓名', doc_sex CHAR(1) COMMENT '性别', doc_age INT COMMENT '年龄', title VARCHAR(32) COMMENT '职称：主治/副主任/普通医师', dept_no CHAR(8) COMMENT '所在科室编号', work_years INT COMMENT '工龄', phone VARCHAR(20) COMMENT '联系方式', PRIMARY KEY (doctor_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='医生信息';逻辑说明：病人号和医生号都按文档用 char(8) 做主键，姓名用 VARCHAR 而不是文档里的 char(8)——中文姓名 char(8) 在 utf8mb4 下够用但浪费，且文档里“病人姓名 Br_name char(8)”本身就不严谨。性别用 char(1) 存 M/F，比存“男/女”省空间也避免编码问题。科室编号这里先留字段，下一节补科室表。
参数说明：ENGINE=InnoDB是为了事务和外键，医疗场景下收费、发药、库存扣减必须在一个事务里；utf8mb4是底线，病人姓名、地址里出现生僻字不至于乱码。文档没提字符集，但这是现在建表的默认选择。
3.2 挂号、处方、检查三张单据表的关联设计
文档给了挂号单、门诊病历、门诊处方、检查项目四张单据的数据结构，以及对应的数据字典字段级定义。我把它们落成表，重点看外键怎么连：
-- 挂号单：文档“挂号单”数据结构 + 挂号单数据字典 CREATE TABLE registration ( gh_no CHAR(8) NOT NULL COMMENT '挂号号', gh_type CHAR(8) NOT NULL COMMENT '挂号类别/所看医科', doctor_no CHAR(8) COMMENT '主治医师编号', patient_no CHAR(8) NOT NULL COMMENT '挂号人（病人号）', dept_no CHAR(8) NOT NULL COMMENT '挂号科室', gh_date DATE NOT NULL COMMENT '挂号日期', fee_status TINYINT DEFAULT 0 COMMENT '缴费状态 0未缴 1已缴', PRIMARY KEY (gh_no), KEY idx_patient (patient_no), KEY idx_date (gh_date) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='门诊挂号单'; -- 门诊处方：文档“门诊处方”数据结构 CREATE TABLE prescription ( cf_no CHAR(8) NOT NULL COMMENT '处方号', doctor_no CHAR(8) NOT NULL COMMENT '主治医师', patient_no CHAR(8) NOT NULL COMMENT '病人号', cf_content VARCHAR(500) COMMENT '处方内容', cf_date DATETIME NOT NULL COMMENT '开方时间', charge_no CHAR(8) COMMENT '关联收费单号', PRIMARY KEY (cf_no), KEY idx_patient (patient_no), KEY idx_doctor (doctor_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='门诊处方';逻辑说明：挂号单里fee_status是我补的，文档只说了“到收费处缴纳挂号费”，但没说挂号单怎么标记已缴费。没有这个字段，收费处和挂号处的数据就对不上。处方表的charge_no同理，文档数据流写“处方信息来源：门诊医生、收费处”，说明处方和收费记录有关联，但数据结构里没体现，这里补一个可空外键，先开方后收费的顺序不会卡住。
参数说明：idx_patient和idx_date是高频查询索引——病人查自己的挂号记录、收费处按日期对账都走这两个。文档摘要里提到“对经常查询的字段建立索引”，这里就是具体落点。注意别给cf_content这种大文本建索引，没意义还拖慢写入。
3.3 药品与库存：请领单和采购单的双向流水
文档里药品相关的数据结构有“药品”“订单”“药库”，数据流有“药品请领单（药房→药库）”“药品采购单（供应商→药库）”，处理过程有“药品采购”。库存管理的核心是每一次出入库都要有流水，库存量是流水的结果而不是独立维护的数字。文档的药品数据结构里直接放了“数量”字段，这是典型的单表存库存写法，小系统能用，但一旦要追溯“这批药什么时候进的、发给谁了”就抓瞎。
我的改法是拆成药品主表 + 库存流水表：
-- 药品主表：文档“药品”数据结构去掉数量、金额 CREATE TABLE drug ( kind_no CHAR(8) NOT NULL COMMENT '药品编号', drug_name VARCHAR(64) NOT NULL COMMENT '药品名', spec VARCHAR(32) COMMENT '规格', unit VARCHAR(8) COMMENT '单位', price DECIMAL(10,2) COMMENT '单价', produce_date DATE COMMENT '生产日期', expire_date DATE COMMENT '保质期/失效日期', PRIMARY KEY (kind_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='药品基础信息'; -- 库存流水：入库为正，出库为负 CREATE TABLE stock_flow ( flow_id BIGINT NOT NULL AUTO_INCREMENT, kind_no CHAR(8) NOT NULL COMMENT '药品编号', flow_type TINYINT NOT NULL COMMENT '1采购入库 2请领出库 3发药出库 4退药入库', qty INT NOT NULL COMMENT '变动数量，入库正出库负', ref_no CHAR(20) COMMENT '关联单号：订单号或请领号', flow_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (flow_id), KEY idx_kind_time (kind_no, flow_time) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='药品库存流水';逻辑说明：flow_type把文档里的采购、请领、发药、退药四类动作统一到一张流水表，qty带符号，当前库存就是SUM(qty)。文档处理过程里写“当库存少到一定程度，系统应提出警告”，有了流水表，这个阈值判断就是一条聚合查询，不用额外维护库存字段，也就不会出现“库存字段和实际流水对不上”的经典问题。
参数说明：ref_no用 char(20) 是为了兼容文档里订单号 Dd_no 的 char(20) 定义；idx_kind_time支撑“某药品最近出入库”的查询。金额用 DECIMAL 不用 FLOAT，财务数据用浮点是血泪经验。
4. 把设计跑起来：建库、灌样例数据、验证业务闭环
4.1 建库顺序与外键依赖
文档没有给完整的建表脚本，只给了数据字典。按依赖关系，建表顺序应该是：科室 → 医生/病人 → 挂号单 → 处方/检查单 → 收费记录 → 药品 → 库存流水 → 住院登记 → 床位 → 医嘱 → 手术 → 病案。外键能不加就先不加，用应用层保证，或者加外键但设ON DELETE RESTRICT，医疗数据不允许级联删除。
下面是一段可执行的初始化脚本骨架，把前面几张表串起来：
# 建库并导入表结构（假设表结构已保存为 schema.sql） mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS his_demo DEFAULT CHARSET utf8mb4;" mysql -u root -p his_demo < schema.sql # 验证表是否建齐 mysql -u root -p his_demo -e "SHOW TABLES;"逻辑说明：先建库指定字符集，再导入 schema，最后SHOW TABLES确认。这一步看着简单，但字符集不指定的话，后面导入中文姓名可能变成问号，排查起来很浪费时间。
参数说明：-u root -p是本地开发常用，生产环境换成专用账号；his_demo是库名，按项目改。
4.2 灌入样例数据验证门诊闭环
设计对不对，灌一遍数据就知道。按门诊链路造一条完整记录：病人登记 → 挂号 → 开处方 → 收费 → 发药扣库存。
-- 1. 病人 INSERT INTO patient (people_no, br_name, br_sex, br_age, phone) VALUES ('P0000001', '张三', 'M', 35, '13800000000'); -- 2. 挂号 INSERT INTO registration (gh_no, gh_type, doctor_no, patient_no, dept_no, gh_date, fee_status) VALUES ('G0000001', '内科', 'D0000001', 'P0000001', 'KS01', '2024-04-19', 1); -- 3. 处方 INSERT INTO prescription (cf_no, doctor_no, patient_no, cf_content, cf_date, charge_no) VALUES ('C0000001', 'D0000001', 'P0000001', '阿莫西林 0.5g 每日三次', NOW(), 'CH000001'); -- 4. 发药出库，库存流水记负数 INSERT INTO stock_flow (kind_no, flow_type, qty, ref_no) VALUES ('K0000001', 3, -2, 'C0000001'); -- 5. 查当前库存 SELECT kind_no, SUM(qty) AS current_qty FROM stock_flow WHERE kind_no = 'K0000001' GROUP BY kind_no;逻辑说明：第 4 步的flow_type=3对应发药出库，qty=-2表示发出两盒，ref_no回填处方号，这样从处方能追到发了什么药、发了多少。第 5 步的聚合查询就是文档里“自动得出新的即时的库存量”的实现方式。
参数说明：gh_type存的是“内科”这种业务值，严格来说应该存科室编号，这里为了演示直观先存文本，正式项目改成dept_no外键。charge_no是收费单号，演示里直接给了值，实际应由收费模块生成后回写。
4.3 用查询验证住院链路的床位与医嘱
住院部分至少验证两件事：床位不能被重复占用，医嘱能按病人和状态查出来。
-- 床位表（文档未给结构，按业务补全） CREATE TABLE bed ( bc_no CHAR(8) NOT NULL COMMENT '病床号', bq_no CHAR(10) NOT NULL COMMENT '病区号', room_no VARCHAR(16) COMMENT '房间号', bed_status TINYINT NOT NULL DEFAULT 0 COMMENT '0空闲 1占用 2预留', zy_no CHAR(8) COMMENT '当前住院号', PRIMARY KEY (bc_no), KEY idx_bq_status (bq_no, bed_status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='床位'; -- 排床：只允许更新空闲床位，影响行数为0说明已被占 UPDATE bed SET bed_status = 1, zy_no = 'Z0000001' WHERE bc_no = 'BC000001' AND bed_status = 0; -- 查某病人当前有效医嘱 SELECT yiz_no, yiz_content, start_date, doctor_no FROM medical_order WHERE patient_no = 'P0000001' AND order_status = 1;逻辑说明：排床用UPDATE ... WHERE bed_status = 0这种条件更新，靠数据库的行锁保证并发下不会两个人抢到同一张床，比先查后改安全得多。医嘱查询带order_status = 1（执行中），避免把已停止的医嘱也查出来。
参数说明：bed_status三态是排床、转床、出科释放的基础；zy_no可空，空闲时为空。医嘱表结构文档给了“诊断单序号、诊断类别、启动日期、处理日期、医嘱内容、主治医师、病人”，我额外加了order_status，因为文档提到医嘱有“启动”和“处理”，没有状态字段就没法区分执行中还是已停止。
5. 避坑与排查：这份设计文档落地时最容易踩的五个坑
5.1 坑一：char(8) 主键手工拼接导致撞号
现象：并发挂号时偶尔出现主键冲突，或者两个病人拿到同一个挂号号。原因：文档只定义了“8 位唯一编码”，没定义生成规则，很多实现是在应用层用“日期+自增”手拼，并发下自增部分重复。解决：主键仍用 char(8) 保持与文档一致，但生成交给数据库序列或 Redis 自增，应用层只负责补零格式化；或者加唯一索引兜底，冲突时重试。
5.2 坑二：库存字段和流水两套数据对不上
现象：药品表里的“数量”和实际出入库记录算出来的库存不一致。原因：文档的药品数据结构直接放了数量字段，实现时既改数量又写流水，中间任何一步失败就脏数据。解决：按第 3.3 节改成只写流水、库存靠聚合，或者用触发器在同一事务里更新汇总字段，二选一，别两头都手工维护。
5.3 坑三：科室交叉导致按科室名关联出错
现象：住院内科和门诊内科的病人混在一起统计。原因：文档明确说门诊和住院下设科室有交叉，但数据字典里科室只体现为ghks char(8)这种文本字段。解决：建独立科室表，用科室编号关联，再加“部门类型”字段区分门诊/住院，所有单据表存科室编号不存科室名。
5.4 坑四：医嘱“遗嘱内容”字段名照抄进代码
现象：建表或写实体类时字段名写成will_content之类，后面接手的人看不懂。原因：文档原文“遗嘱内容”是笔误，应为“医嘱内容”。解决：建表时字段注释写清楚“医嘱内容”，代码里用order_content，别把笔误带进生产。
5.5 坑五：收费与业务单据没有关联字段
现象：对账时发现某笔收费找不到对应的处方或检查单。原因：文档数据流写了“处方信息来源：门诊医生、收费处”，但处方数据结构里没有收费单号字段，实现时容易漏掉这层关联。解决：处方表、检查申请表都加可空的收费单号字段，收费完成后回写，对账时用LEFT JOIN就能查出无主收费。
6. 二次开发改造：把课程设计文档变成能演进的数据层
这份文档最大的价值不是它写得多完美，而是它把业务链路和数据项列全了，改起来有据可依。我一般会做三件事。
第一件，补全文档留白的表。文档给了病人、医生、药品、挂号、处方、检查、医嘱、手术、病案、订单、供应商、药库，但床位表、收费明细表、权限表都没给结构。床位按第 4.3 节补；收费明细我建议拆成收费主单 + 收费明细，主单挂业务单据号，明细挂收费项目号，这样一张处方里多种药品能分别计价。权限表按“用户-角色-权限”三张表起步，文档安全要求里写了“对不同数据设置不同访问级别”，这就是落点。
第二件，把 char(8) 编码体系换成“业务编码 + 代理主键”双轨。业务编码保留给人工核对和打印单据，代理主键用 BIGINT 自增给外键关联用。改造时不用动文档定义的字段名，只加一列id BIGINT AUTO_INCREMENT UNIQUE，外键指向id，业务编码加唯一索引。这样既尊重原设计，又避免编码规则变更时全表改主键。
第三件，给高频查询补索引并用执行计划验证。文档摘要提到索引设计，但没给具体字段。我的习惯是：挂号单按(patient_no, gh_date)建联合索引，处方按(patient_no, cf_date)，库存流水按(kind_no, flow_time)，医嘱按(patient_no, order_status)。建完用EXPLAIN看一遍，确认走的是索引而不是全表扫。下面是一个验证示例：
EXPLAIN SELECT gh_no, gh_date FROM registration WHERE patient_no = 'P0000001' ORDER BY gh_date DESC LIMIT 10;如果type列是ALL，说明索引没生效，检查字段类型是否和查询值一致——char(8) 和 varchar 比较可能隐式转换导致索引失效，这是我在类似项目里翻过车的地方。
改造完怎么验证？我的做法是造一批边界数据：同一病人同一天多次挂号、一张处方对应多次发药、床位转床后原床位释放、医嘱停止后再开新医嘱。跑一遍链路，看库存聚合、收费对账、床位状态是否自洽。自洽了再谈性能。
从那以后我每次拿到这类“仅供参考”的设计文档，都强制先把数据流图翻译成外键关系图，再动手建表——文档可以参考，外键不会骗人。希望帮到你。
本文还有配套的精品资源，点击获取
