简介这份资源是面向高校计算机与数据库课程学习者、课程设计实践者的医院病房管理系统完整项目包围绕数据库设计与业务系统开发展开适合需要完成数据库课设或练习B/S架构开发的学生参考。包内共146个文件以59个class与37个java源码为主体配合24张jpg、6张png界面截图及4个xml配置另有sql建库脚本、doc说明文档与项目工程文件压缩包约5.04MB覆盖从数据库建表到前后端实现的完整链路。项目涉及病人信息、病房床位、医护人员、排班与费用结算等实体关系建模并体现主键外键、索引视图、DML与DDL等关系数据库理论的实际运用同时包含权限控制与数据备份等安全设计思路。目前已有164人学习下载可帮助读者理解需求分析、系统设计到编码测试的软件工程流程快速搭建可运行的课设原型并对照完善自身方案。1. 医院病房管理系统数据库课设从建表到能演示中间隔着多少坑做过数据库课设的人都清楚最难的从来不是写 SQL而是把「医院病房管理系统」这七个字翻译成一组能跑起来的表、约束和查询。你拿到这个题大概率面对的是这样的场景老师给了两周时间要求交一份带 ER 图、建表脚本、增删改查界面和课程设计报告的完整作业而你打开 Navicat 或者 SSMS 之后盯着空白的查询窗口不知道第一行该敲什么。这个题目的本质是一个中等复杂度的关系型数据库设计任务涉及病人、病房、医生、护士、住院记录、费用清单这几类核心实体表数量通常在 8 到 12 张之间需要处理外键约束、多表联查、事务和至少一个存储过程或触发器。它适合正在上数据库课程、需要交课设的本科生也适合想拿一个完整案例练手 SQL 的转行者。下面我按实际做一遍的顺序把建表、插数据、写查询、做界面这条链路拆开讲中间会重点说那些第一次做必然翻车的地方。2. 需求拆解与表结构设计别急着写 CREATE TABLE2.1 先画 ER 图还是先列表我的实际顺序很多人一上来就打开建模工具画 ER 图画完发现实体之间的关系根本对不上又回头改来回折腾。我一般会先拿一张纸把系统里「谁对谁做了什么」用大白话列出来再转成表。具体来说医院病房管理系统的核心业务流是这样的一个病人来住院被分配到一个病房的一张床位由一位主治医生负责可能有多个护士参与护理住院期间产生若干条医嘱和费用记录出院时结算。把这段话里的名词圈出来——病人、病房、床位、医生、护士、医嘱、费用——这些就是候选实体。动词圈出来——分配、负责、参与、产生、结算——这些就是关系。转成表的时候有几个判断规则值得记住。第一如果两个实体之间是「一对多」比如一个病房有多张床位那就在「多」的那边加外键不需要单独建关系表。第二如果是「多对多」比如一个病人可以由多个护士护理一个护士也护理多个病人那就必须建中间表。第三如果关系本身带有属性比如「住院」这个关系有入院时间、出院时间、诊断结果那它就应该独立成一张住院记录表而不是塞到病人表里。按这个思路我通常会得到这样一组核心表病人表patient、医生表doctor、护士表nurse、病房表ward、床位表bed、住院记录表admission、医嘱表medical_order、费用记录表expense。如果课设要求更细还可以加科室表department、药品表medicine、排班表schedule。表数量控制在 10 张左右比较合适太少显得单薄太多两周做不完。2.2 建表脚本从病人表开始的完整 DDL下面是我实际用的建表脚本以 MySQL 8.0 为例字符集用 utf8mb4引擎用 InnoDB 以支持外键和事务。先建没有外键依赖的表再建有关联的表顺序不能反。-- 病人表核心实体记录基本信息 CREATE TABLE patient ( patient_id INT PRIMARY KEY AUTO_INCREMENT COMMENT 病人编号, name VARCHAR(50) NOT NULL COMMENT 姓名, gender CHAR(1) NOT NULL DEFAULT 男 COMMENT 性别, birth_date DATE COMMENT 出生日期, id_card VARCHAR(18) UNIQUE COMMENT 身份证号, phone VARCHAR(20) COMMENT 联系电话, address VARCHAR(200) COMMENT 家庭住址, created_at DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 建档时间 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT病人信息表; -- 病房表记录病房类型和容量 CREATE TABLE ward ( ward_id INT PRIMARY KEY AUTO_INCREMENT COMMENT 病房编号, ward_no VARCHAR(10) NOT NULL UNIQUE COMMENT 病房号, ward_type VARCHAR(20) NOT NULL COMMENT 病房类型普通/重症/隔离, floor_no INT NOT NULL COMMENT 所在楼层, capacity INT NOT NULL DEFAULT 4 COMMENT 床位容量, daily_rate DECIMAL(10,2) NOT NULL COMMENT 每日床位费 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT病房信息表; -- 床位表属于某个病房状态标记是否占用 CREATE TABLE bed ( bed_id INT PRIMARY KEY AUTO_INCREMENT COMMENT 床位编号, ward_id INT NOT NULL COMMENT 所属病房, bed_no VARCHAR(10) NOT NULL COMMENT 床位号, status TINYINT NOT NULL DEFAULT 0 COMMENT 0空闲 1占用 2维修, CONSTRAINT fk_bed_ward FOREIGN KEY (ward_id) REFERENCES ward(ward_id), UNIQUE KEY uk_ward_bed (ward_id, bed_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT床位信息表; -- 医生表 CREATE TABLE doctor ( doctor_id INT PRIMARY KEY AUTO_INCREMENT COMMENT 医生编号, name VARCHAR(50) NOT NULL COMMENT 姓名, title VARCHAR(20) COMMENT 职称, department VARCHAR(50) COMMENT 所属科室, phone VARCHAR(20) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT医生信息表; -- 住院记录表关联病人、床位、医生记录住院过程 CREATE TABLE admission ( admission_id INT PRIMARY KEY AUTO_INCREMENT COMMENT 住院流水号, patient_id INT NOT NULL COMMENT 病人编号, bed_id INT NOT NULL COMMENT 床位编号, doctor_id INT NOT NULL COMMENT 主治医生, admit_date DATETIME NOT NULL COMMENT 入院时间, discharge_date DATETIME COMMENT 出院时间为空表示在院, diagnosis VARCHAR(200) COMMENT 入院诊断, status TINYINT NOT NULL DEFAULT 1 COMMENT 1在院 2已出院, CONSTRAINT fk_adm_patient FOREIGN KEY (patient_id) REFERENCES patient(patient_id), CONSTRAINT fk_adm_bed FOREIGN KEY (bed_id) REFERENCES bed(bed_id), CONSTRAINT fk_adm_doctor FOREIGN KEY (doctor_id) REFERENCES doctor(doctor_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT住院记录表;这段脚本里有几个参数值得单独说。AUTO_INCREMENT让主键自增省去手动编号的麻烦但要注意在 MySQL 里它和PRIMARY KEY一起用时才能生效。UNIQUE约束加在身份证号和「病房号床位号」的组合上前者防止重复建档后者防止同一病房出现两个相同床位号。外键的CONSTRAINT命名建议用「fk_表名_关联表名」的格式出问题时错误信息里能看到约束名方便定位。status字段用TINYINT而不是BOOLEAN因为 MySQL 的 BOOLEAN 本质就是 TINYINT(1)直接用数字更直观。注意建表顺序必须是 patient、ward、doctor 在前bed、admission 在后。如果先建 admission外键引用的表还不存在MySQL 会直接报 errno 150。2.3 医嘱表和费用表容易被忽略的两个细节医嘱表和费用表是课设里区分「能跑」和「做得好」的关键。医嘱表记录医生对病人下达的用药、检查、护理指令费用表记录每一笔产生的费用。这两张表的设计有一个共同点它们都依附于住院记录而不是直接依附于病人。因为同一个病人可能多次住院每次住院的医嘱和费用是独立的。-- 医嘱表依附于住院记录 CREATE TABLE medical_order ( order_id INT PRIMARY KEY AUTO_INCREMENT COMMENT 医嘱编号, admission_id INT NOT NULL COMMENT 住院流水号, order_type VARCHAR(20) NOT NULL COMMENT 类型用药/检查/护理, content VARCHAR(500) NOT NULL COMMENT 医嘱内容, doctor_id INT NOT NULL COMMENT 下达医生, order_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 下达时间, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待执行 1已执行, CONSTRAINT fk_order_adm FOREIGN KEY (admission_id) REFERENCES admission(admission_id), CONSTRAINT fk_order_doctor FOREIGN KEY (doctor_id) REFERENCES doctor(doctor_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT医嘱表; -- 费用记录表 CREATE TABLE expense ( expense_id INT PRIMARY KEY AUTO_INCREMENT COMMENT 费用编号, admission_id INT NOT NULL COMMENT 住院流水号, item_name VARCHAR(100) NOT NULL COMMENT 费用项目, amount DECIMAL(10,2) NOT NULL COMMENT 金额, expense_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 产生时间, CONSTRAINT fk_exp_adm FOREIGN KEY (admission_id) REFERENCES admission(admission_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT费用记录表;这里有个设计选择需要解释为什么医嘱和费用不直接关联病人因为如果直接关联病人当同一个病人第二次住院时你无法区分哪些医嘱属于哪一次住院。通过 admission_id 关联每次住院的医嘱和费用天然隔离查询时也更清晰。这个细节在课设答辩时经常被问到提前想清楚能省不少事。3. 数据插入与增删改查让系统真正跑起来3.1 造测试数据手工插入和批量生成表建好之后是空的没法演示查询。我一般会先手工插入几条基础数据确认外键关系没问题再用脚本批量生成测试数据。手工插入的顺序和建表顺序一致先病人、病房、医生再床位、住院记录最后医嘱和费用。-- 插入病人 INSERT INTO patient (name, gender, birth_date, id_card, phone, address) VALUES (张伟, 男, 1985-03-12, 110101198503121234, 13800138001, 北京市朝阳区), (李娜, 女, 1990-07-25, 110101199007251234, 13800138002, 北京市海淀区), (王强, 男, 1978-11-08, 110101197811081234, 13800138003, 北京市西城区); -- 插入病房 INSERT INTO ward (ward_no, ward_type, floor_no, capacity, daily_rate) VALUES (301, 普通, 3, 4, 80.00), (302, 普通, 3, 4, 80.00), (ICU-01, 重症, 5, 2, 500.00); -- 插入医生 INSERT INTO doctor (name, title, department, phone) VALUES (赵明, 主任医师, 内科, 13900139001), (孙丽, 副主任医师, 外科, 13900139002); -- 插入床位为 301 病房生成 4 张床 INSERT INTO bed (ward_id, bed_no, status) VALUES (1, A, 0), (1, B, 0), (1, C, 0), (1, D, 0), (2, A, 0), (2, B, 0), (2, C, 0), (2, D, 0), (3, A, 0), (3, B, 0); -- 插入住院记录张伟住进 301-A 床主治赵明 INSERT INTO admission (patient_id, bed_id, doctor_id, admit_date, diagnosis, status) VALUES (1, 1, 1, 2024-03-01 09:30:00, 急性支气管炎, 1); -- 插入医嘱 INSERT INTO medical_order (admission_id, order_type, content, doctor_id, status) VALUES (1, 用药, 阿莫西林 0.5g 口服 每日三次, 1, 1), (1, 检查, 胸部X光正位片, 1, 0); -- 插入费用 INSERT INTO expense (admission_id, item_name, amount) VALUES (1, 床位费, 80.00), (1, 诊查费, 20.00), (1, 药品费, 156.50);批量生成数据可以用 Python 脚本配合faker库或者直接随机组合。如果不想装额外依赖用 MySQL 的存储过程循环插入也行但课设里手工插十几条足够演示了。关键是数据之间要有逻辑关联比如住院记录里的 bed_id 必须真实存在否则外键会拒绝插入。3.2 核心查询从单表到多表联查课设答辩时老师最爱问的就是「你这个系统能查什么」。下面这几条查询覆盖了最常见的需求也是必须能当场写出来的。第一条查当前在院病人列表显示姓名、病房号、床位号、主治医生SELECT p.name AS 病人姓名, w.ward_no AS 病房号, b.bed_no AS 床位号, d.name AS 主治医生, a.admit_date AS 入院时间, a.diagnosis AS 诊断 FROM admission a JOIN patient p ON a.patient_id p.patient_id JOIN bed b ON a.bed_id b.bed_id JOIN ward w ON b.ward_id w.ward_id JOIN doctor d ON a.doctor_id d.doctor_id WHERE a.status 1 ORDER BY a.admit_date DESC;这条查询用了四个 JOIN逻辑是从 admission 出发依次关联病人、床位、病房、医生。WHERE a.status 1过滤出在院记录。注意 JOIN 的顺序不影响结果但影响可读性我习惯从主表 admission 开始往外扩。第二条查某个病人的总费用SELECT p.name AS 病人姓名, SUM(e.amount) AS 总费用 FROM expense e JOIN admission a ON e.admission_id a.admission_id JOIN patient p ON a.patient_id p.patient_id WHERE p.patient_id 1 GROUP BY p.patient_id, p.name;这里用SUM聚合GROUP BY必须包含所有非聚合列。如果只写GROUP BY p.patient_id在 MySQL 的ONLY_FULL_GROUP_BY模式下会报错因为p.name没有出现在 GROUP BY 里。这是新手常踩的坑解决办法要么把 name 加进 GROUP BY要么用ANY_VALUE(p.name)。第三条查空闲床位SELECT w.ward_no, b.bed_no, w.ward_type, w.daily_rate FROM bed b JOIN ward w ON b.ward_id w.ward_id WHERE b.status 0 ORDER BY w.ward_no, b.bed_no;3.3 增删改查的界面层用 Python tkinter 做个能演示的壳课设通常要求有界面哪怕很简陋。用 Python 的 tkinter 配合 pymysql 是最快能出效果的方式不需要装额外的 GUI 框架。下面是一个最小可用的查询界面能连数据库、执行查询、把结果显示在表格里。import tkinter as tk from tkinter import ttk, messagebox import pymysql # 数据库连接参数按自己的环境改 DB_CONFIG { host: localhost, user: root, password: your_password, database: hospital, charset: utf8mb4 } def query_patients(): 查询在院病人并显示在表格中 try: conn pymysql.connect(**DB_CONFIG) cursor conn.cursor() sql SELECT p.name, w.ward_no, b.bed_no, d.name, a.admit_date FROM admission a JOIN patient p ON a.patient_id p.patient_id JOIN bed b ON a.bed_id b.bed_id JOIN ward w ON b.ward_id w.ward_id JOIN doctor d ON a.doctor_id d.doctor_id WHERE a.status 1 cursor.execute(sql) rows cursor.fetchall() # 清空表格 for item in tree.get_children(): tree.delete(item) # 插入新数据 for row in rows: tree.insert(, end, valuesrow) cursor.close() conn.close() except Exception as e: messagebox.showerror(查询失败, str(e)) # 主窗口 root tk.Tk() root.title(医院病房管理系统 - 在院病人查询) root.geometry(800x400) # 表格 columns (姓名, 病房号, 床位号, 主治医生, 入院时间) tree ttk.Treeview(root, columnscolumns, showheadings) for col in columns: tree.heading(col, textcol) tree.column(col, width140) tree.pack(fillboth, expandTrue, padx10, pady10) # 查询按钮 btn tk.Button(root, text查询在院病人, commandquery_patients) btn.pack(pady5) root.mainloop()这段代码的逻辑很直白点按钮触发query_patients连数据库、执行 SQL、把结果塞进 Treeview。参数方面DB_CONFIG里的password要换成你自己的database要和你建库时的名字一致。charsetutf8mb4不能省否则中文会变问号。异常处理用messagebox弹出错误方便调试时看到具体报错。提示如果运行时报ModuleNotFoundError: No module named pymysql先执行pip install pymysql。如果连不上数据库检查 MySQL 服务是否启动、端口是否被防火墙拦截。4. 避坑与排查课设里最容易翻车的五个地方4.1 外键约束报错 errno 150现象执行建表或插入时报ERROR 1215 (HY000): Cannot add foreign key constraint或errno 150。原因通常有三个一是字段类型不匹配比如主表主键是INT外键写成了BIGINT二是字符集不一致主表用utf8mb4子表用latin1三是引用的列没有索引MySQL 要求外键列必须有索引。解决办法用SHOW CREATE TABLE 表名检查两边的字段定义确保类型、字符集、引擎完全一致。如果是索引问题给外键列加INDEX即可。4.2 中文乱码从建库到连接都要统一现象插入的中文数据显示为???或乱码。原因可能出现在三个环节建库时没指定字符集、建表时没指定字符集、连接时没指定字符集。解决办法建库用CREATE DATABASE hospital DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_unicode_ci;建表时加DEFAULT CHARSETutf8mb4Python 连接时加charsetutf8mb4。三个地方都对齐乱码问题基本不会出现。4.3 插入数据时外键顺序搞反现象插入住院记录时报Cannot add or update a child row: a foreign key constraint fails。原因是你引用的 patient_id 或 bed_id 在对应的表里还不存在。解决办法严格按照依赖顺序插入——先 patient、ward、doctor再 bed再 admission最后 medical_order 和 expense。如果已经插入了部分数据用SELECT * FROM 表名确认引用的 ID 确实存在。4.4 查询结果重复JOIN 时忘了加 DISTINCT 或 GROUP BY现象查病人列表时同一个病人出现多次。原因是一个病人有多条医嘱或多条费用记录JOIN 之后行数被放大了。解决办法如果只需要病人基本信息用DISTINCT去重如果需要聚合信息比如总费用用GROUP BY按病人分组。判断标准是看查询目的——要明细就用 JOIN 后直接查要汇总就用 GROUP BY。4.5 界面查询卡死连接没关或 SQL 写错现象点了查询按钮之后界面无响应。原因通常是数据库连接没有关闭或者 SQL 语句有语法错误导致游标一直等待。解决办法用try...except...finally确保连接关闭或者在query_patients函数里把conn.close()放在finally块中。另外开发阶段把 SQL 打印出来复制到 Navicat 里单独执行一遍能快速定位语法问题。5. 进阶技巧用触发器和存储过程把课设做出区分度课设拿高分的关键往往不是界面多漂亮而是有没有用到数据库本身的高级特性。触发器和存储过程是两个性价比最高的选择代码量不大但答辩时能讲出东西。先说触发器。医院病房管理系统里有一个典型的业务规则病人办理住院时对应的床位状态应该自动变成「占用」病人出院时床位自动变回「空闲」。这个逻辑用触发器实现最合适不需要在应用层写额外代码。-- 入院时自动占用床位 DELIMITER // CREATE TRIGGER trg_admission_insert AFTER INSERT ON admission FOR EACH ROW BEGIN IF NEW.status 1 THEN UPDATE bed SET status 1 WHERE bed_id NEW.bed_id; END IF; END // DELIMITER ; -- 出院时自动释放床位 DELIMITER // CREATE TRIGGER trg_admission_update AFTER UPDATE ON admission FOR EACH ROW BEGIN IF NEW.status 2 AND OLD.status 1 THEN UPDATE bed SET status 0 WHERE bed_id NEW.bed_id; END IF; END // DELIMITER ;这两个触发器的逻辑是插入住院记录时如果状态是在院就把床位标记为占用更新住院记录时如果状态从在院变成出院就把床位释放。NEW和OLD是触发器里的关键字分别代表新行和旧行的数据。DELIMITER //是为了让 MySQL 把整个触发器体当作一个语句处理不然分号会提前结束定义。再说存储过程。课设里经常需要「查某个病人在指定时间段内的费用明细」这个查询参数多、逻辑固定封装成存储过程调用起来很方便。DELIMITER // CREATE PROCEDURE sp_patient_expense( IN p_patient_id INT, IN p_start_date DATE, IN p_end_date DATE ) BEGIN SELECT e.item_name AS 费用项目, e.amount AS 金额, e.expense_time AS 产生时间 FROM expense e JOIN admission a ON e.admission_id a.admission_id WHERE a.patient_id p_patient_id AND DATE(e.expense_time) BETWEEN p_start_date AND p_end_date ORDER BY e.expense_time; END // DELIMITER ; -- 调用方式 CALL sp_patient_expense(1, 2024-03-01, 2024-03-31);存储过程的参数用IN声明表示输入参数。BETWEEN ... AND ...是闭区间包含起止日期。调用时直接传参即可不需要拼 SQL 字符串避免了 SQL 注入的风险。最后说一个验证方法做完触发器和存储过程之后用SHOW TRIGGERS和SHOW PROCEDURE STATUS WHERE Db hospital确认它们已经创建成功。然后手工插入一条住院记录查一下 bed 表的 status 有没有自动变再调用一次存储过程看结果是否符合预期。这两个动作做完课设的数据库部分基本就扎实了。我自己做课设时最大的教训是别等到最后一天才动手建表。表结构一旦定下来后面所有查询和界面都依赖它改一处就要改十处。提前花两个小时把 ER 图和建表脚本打磨好后面能省下至少一整天的返工时间。希望帮到你。本文还有配套的精品资源点击获取