简介这份资源是方正公司医院信息系统CHIS5.0的数据库表结构文档面向医院信息化开发者、数据库设计与运维人员以及需要对接或二次开发CHIS系统的技术人员帮助其快速理解各业务模块的数据组织方式与表间关系。压缩包内共1个doc文件约5.01MB内容按PUBLIC、GH、MZ、RT、WH、YP、ZY、YZ、XT、ZD等模块组织逐项列出公共、挂号、门诊、报表、维护、药品、住院、医嘱、系统、字典等业务对应的数据表及字段说明并附有目录与摘要便于定位。目前已有130人学习下载。读者可据此掌握CHIS核心表结构用于数据库建模、接口开发、数据查询与系统维护也可作为医院信息系统实施与排错时的参考依据减少因表关系不清导致的开发返工。1. 方正医院信息系统数据库表结构一份文档能省掉多少猜表名的夜晚接手一套跑了好几年的方正医院信息系统最磨人的往往不是写 SQL而是面对几百张表不知道从哪张下手。PATIENT_INFO和PAT_MASTER到底哪个是主表ORDERS和ORDER_DETAIL谁先谁后字段YBFLAG是医保标志还是别的什么缩写——这些答案通常就藏在一份叫「方正公司医院信息系统数据库表结构.doc」的文档里。它本质是一份数据字典把 CHIS医院信息系统里各业务域的表名、字段名、类型、注释和主外键关系摊开讲清楚。适合三类人刚接手院内系统二次开发的工程师、要做数据对接或报表的 BI 同学、以及需要从老库里抽数做迁移的运维。这篇不空谈直接讲怎么把这份文档用起来、怎么验证它和真实库是否一致、以及神通数据库 dbstudio 这类工具在只备份表结构时该怎么配合。2. 先看懂表结构文档的骨架业务域、命名规则与主外键拿到一份表结构文档第一反应不该是逐行读而是先摸清它的组织逻辑。方正这套 CHIS 的表结构文档通常按业务域分块门诊、住院、收费、药房、医嘱、检验检查、医保接口。每个业务域下再列具体表表与表之间靠主外键串起来。你如果能先把「域」和「域之间怎么关联」理清后面查任何一张表都快。2.1 从表名前缀反推业务归属方正 CHIS 的表名大多带前缀或固定词根这是快速定位的第一把钥匙。常见规律是门诊相关多用MZ或OUTP住院用ZY或INP收费结算用SF或FEE药品用YP或DRUG医嘱用YZ或ORDER。文档里一般会在每个业务域开头说明本域的表名规则但很多版本写得比较散需要你自己归纳。我一般会先做一件事把文档里所有表名抽出来按前缀分组做成一张速查表。这样当有人问「住院病人的费用明细在哪张表」时你能立刻缩小到ZY_FEE_DETAIL或INP_BILL_ITEM这个范围而不是全库搜。业务域常见表名前缀典型主表关联关键字段门诊挂号MZ / OUTPMZ_REGISTERPATIENT_ID, VISIT_NO住院管理ZY / INPZY_ADMISSIONINP_NO, PATIENT_ID收费结算SF / FEESF_MASTERSETTLE_NO, INP_NO药品管理YP / DRUGYP_STOCKDRUG_CODE, STORE_ID医嘱YZ / ORDERYZ_MASTERORDER_NO, INP_NO检验检查JY / LISJY_REQUESTREQ_NO, PATIENT_ID这张表不是让你背而是让你在文档里找对应章节时有方向。注意不同医院版本的前缀可能有差异以文档实际内容为准。2.2 主外键关系怎么读才不迷路表结构文档里最值钱的部分不是字段列表而是主外键说明。方正 CHIS 的核心链路通常是患者主索引 → 就诊记录 → 医嘱/收费/检验。患者主索引表一般叫PATIENT_MASTER或PAT_INDEX主键是PATIENT_ID就诊记录表用VISIT_NO或INP_NO关联医嘱和收费再通过就诊号挂上去。读文档时建议你拿一张纸画出这条主链把每个环节的主键和外键标出来。比如-- 从患者主索引出发查某患者所有住院就诊 SELECT p.PATIENT_ID, p.PATIENT_NAME, a.INP_NO, a.ADMISSION_DATE FROM PATIENT_MASTER p JOIN ZY_ADMISSION a ON p.PATIENT_ID a.PATIENT_ID WHERE p.PATIENT_ID 00012345;这段 SQL 的逻辑是PATIENT_MASTER是患者维度的主表ZY_ADMISSION是住院就诊事实表两者通过PATIENT_ID关联。参数PATIENT_ID是医院内唯一患者标识通常由 HIS 在建档时生成。如果你在文档里发现ZY_ADMISSION的主键是INP_NO而不是PATIENT_ID那说明一个患者多次住院会有多条记录查询时要加时间范围或VISIT_NO过滤。提示文档里如果只写了字段名没写注释优先看字段类型和长度。比如CHAR(1)的字段大概率是标志位VARCHAR(20)且叫XXX_CODE的通常是编码。2.3 字段注释缺失时怎么补全老版本的方正表结构文档有个通病部分字段只有英文名没有中文注释。这时候别硬猜用三条路交叉验证。第一看同域其他表的相似字段比如FEE_FLAG和CHARGE_FLAG大概率同义。第二去数据库里查实际数据分布SELECT YBFLAG, COUNT(*) FROM SF_MASTER GROUP BY YBFLAG如果只有 0 和 1基本就是布尔标志。第三找院内老开发或运维问一句比翻半天文档快。我一般会建一张「字段疑点表」把不确定的字段列出来标注推测含义和验证方式。等验证完再回填到自己的速查笔记里。这样下次再遇到同一张表就不用重新猜。3. 把文档变成可查询的数据字典导入与比对实操文档是死的库是活的。真正高效的用法是把文档里的表结构信息导入到数据库或本地工具里做成可查询的数据字典再和真实库做比对。这样既能快速检索又能发现文档和实际库的差异。3.1 用 Python 把 Word 表格转成结构化数据方正的表结构文档通常是.doc或.docx里面用表格列字段。手工抄不现实用python-docx解析表格是常见做法。下面这段代码把文档里所有表格读出来转成 CSV方便后续导入数据库。from docx import Document import csv doc Document(方正公司医院信息系统数据库表结构.docx) rows [] for table in doc.tables: # 每个表格通常对应一张表的结构 current_table_name for i, row in enumerate(table.rows): cells [cell.text.strip() for cell in row.cells] # 第一行可能是表名或表头 if i 0: current_table_name cells[0] if cells else UNKNOWN continue # 跳过表头行字段名/类型/长度/注释 if cells[0] in (字段名, 字段, 列名): continue if len(cells) 4: rows.append({ table_name: current_table_name, column_name: cells[0], data_type: cells[1], length: cells[2], comment: cells[3] if len(cells) 3 else }) with open(chis_columns.csv, w, newline, encodingutf-8) as f: writer csv.DictWriter(f, fieldnames[table_name, column_name, data_type, length, comment]) writer.writeheader() writer.writerows(rows) print(f共提取 {len(rows)} 个字段)逻辑说明遍历文档中每个表格假设第一个单元格是表名后续行是字段定义。参数方面cells[0]到cells[3]分别对应字段名、类型、长度、注释如果你的文档列顺序不同调整索引即可。跑完后你会得到一个 CSV每行一个字段带表名方便用 SQL 或 Excel 筛选。注意有些版本的文档把表名写在表格上方的段落里而不是表格第一行。这种情况需要额外解析段落文本判断哪一行是表名。可以先打印所有段落看看规律。3.2 导入 SQLite 做本地速查CSV 有了导入 SQLite 就能用 SQL 查。这一步的好处是你不用连生产库本地就能回答「哪个表有YBFLAG字段」这种问题。import sqlite3 import csv conn sqlite3.connect(chis_dict.db) cur conn.cursor() cur.execute( CREATE TABLE IF NOT EXISTS columns_dict ( table_name TEXT, column_name TEXT, data_type TEXT, length TEXT, comment TEXT ) ) with open(chis_columns.csv, encodingutf-8) as f: reader csv.DictReader(f) cur.executemany( INSERT INTO columns_dict VALUES (:table_name, :column_name, :data_type, :length, :comment), reader ) conn.commit() # 查所有含 YBFLAG 的表 cur.execute(SELECT table_name, column_name, comment FROM columns_dict WHERE column_name LIKE %YBFLAG%) for row in cur.fetchall(): print(row) conn.close()逻辑说明建一张columns_dict表把 CSV 灌进去。executemany批量插入比逐条快。查询时用LIKE模糊匹配字段名能快速定位。参数:table_name等是命名占位符对应 CSV 的列名。这个本地字典库可以反复用每次拿到新版本文档重新生成 CSV 再导入即可。3.3 和真实库做差异比对文档和实际库不一致是常态尤其是系统升级后文档没更新。比对方法很简单从真实库查出所有表和字段和你的字典库做LEFT JOIN找出文档有但库里没有、或库里有但文档没有的项。-- 在真实库中查询以神通数据库为例信息模式表名可能不同 SELECT table_name, column_name FROM information_schema.columns WHERE table_schema PUBLIC ORDER BY table_name, column_name;把结果导出成 CSV再导入 SQLite 的另一张表real_columns然后-- 文档有但库里没有 SELECT d.table_name, d.column_name FROM columns_dict d LEFT JOIN real_columns r ON d.table_name r.table_name AND d.column_name r.column_name WHERE r.column_name IS NULL; -- 库里有但文档没有 SELECT r.table_name, r.column_name FROM real_columns r LEFT JOIN columns_dict d ON r.table_name d.table_name AND r.column_name d.column_name WHERE d.column_name IS NULL;这两条查询能帮你快速定位文档滞后或遗漏的地方。我一般会把差异结果发给运维确认是文档没更新还是库里有临时字段。确认后再更新自己的字典库。4. 只备份表结构dbstudio 与神通数据库的配合方式热搜里有人问「神通数据库 dbstudio 工具怎么只备份表结构」这其实和表结构文档的使用场景直接相关你拿到文档后往往需要在测试环境复现一套空表结构而不是把生产数据全导出来。神通数据库是国产库dbstudio 是它的图形化管理工具只备份表结构有几种常见做法。4.1 用 dbstudio 导出 DDL 的步骤dbstudio 里通常有「导出」或「生成 SQL」功能。操作路径大致是连接目标库 → 展开表列表 → 选中需要导出的表 → 右键选择「生成 DDL」或「导出表结构」。不同版本菜单名有差异但核心逻辑是只生成CREATE TABLE语句不勾选「导出数据」。如果你在菜单里找不到可以试试用「数据库对象对比」或「模式导出」功能里面一般有「仅结构」选项。导出后得到一个.sql文件里面是建表语句可以直接在测试库执行。注意神通数据库的 DDL 语法和 Oracle 比较接近但和 MySQL 有差异。比如VARCHAR2而不是VARCHARNUMBER而不是INT。导出后别直接往 MySQL 里灌先检查类型映射。4.2 用 SQL 查询生成建表语句如果 dbstudio 版本不支持一键导出可以用 SQL 查系统表拼 DDL。神通数据库的系统表里通常有USER_TAB_COLUMNS或类似的信息模式视图。-- 查询某张表的字段定义神通数据库常见写法 SELECT column_name, data_type, data_length, data_precision, data_scale, nullable, data_default FROM user_tab_columns WHERE table_name ZY_ADMISSION ORDER BY column_id;拿到字段列表后你可以用脚本拼成CREATE TABLE。这一步比较繁琐但胜在可控。我一般会写个 Python 脚本连库查字段按类型映射规则生成 DDL再人工检查一遍。4.3 只备份表结构的三个参数要点不管用哪种方式只备份表结构时要注意三个点。第一索引和约束别丢。CREATE TABLE只建表主键、外键、唯一索引、检查约束需要额外导出。dbstudio 里通常有「包含索引」「包含约束」的勾选项记得勾上。第二默认值和注释。字段默认值影响插入行为注释影响可读性导出时确认这两项包含在内。第三表空间和存储参数。生产库和测试库的表空间名可能不同导出后要替换否则执行会报错。导出项是否必须常见问题表定义是类型映射错误主键是漏掉导致数据重复外键按需测试环境可能不需要索引是漏掉导致查询慢默认值是漏掉导致插入失败注释建议影响后续维护表空间否需替换为目标环境5. 避坑与排查表结构文档使用中的五个血泪教训5.1 文档版本和库版本对不上现象按文档写的 SQL 查不到字段报「列不存在」。原因文档是两年前的版本系统升级后加了字段或改了表名文档没同步。解决先用第 3 章的比对方法找出差异以真实库为准同时把差异反馈给运维更新文档。我一般会在字典库里加一列verify_date记录最近一次和真实库比对的时间。5.2 字段名大小写和引号问题现象在神通数据库里SELECT patient_id FROM PATIENT_MASTER报错但文档里写的就是小写。原因神通数据库默认大写标识符建表时如果没加引号实际存储的是大写。文档里写小写只是习惯。解决查询时用大写或者加双引号PATIENT_ID。更稳妥的做法是查USER_TAB_COLUMNS确认实际大小写。5.3 主外键关系在文档里是逻辑关系而非物理外键现象文档里画了表之间的连线但库里没有外键约束插入脏数据不报错。原因很多 HIS 为了性能不建物理外键文档里的关系是逻辑上的。解决别依赖数据库约束保证一致性在应用层或 ETL 里做校验。查询时自己用JOIN关联别指望CASCADE。5.4 只备份表结构时漏掉序列和触发器现象测试库建好表后插入数据报主键冲突或自增字段不生效。原因只导了CREATE TABLE没导序列SEQUENCE和触发器TRIGGER。方正 CHIS 里很多主键靠序列生成。解决导出时勾选序列和触发器或者手动补建。神通数据库里查USER_SEQUENCES和USER_TRIGGERS确认。5.5 把文档当唯一真相现象完全按文档开发上线后发现数据对不上。原因文档是参考真实数据分布、业务规则、历史遗留逻辑都不在文档里。解决文档用来定位表和字段业务逻辑必须找临床科室或老开发确认。我习惯在关键表上跑SELECT COUNT(*)和SELECT * FROM ... WHERE ROWNUM 5先看看真实数据长什么样。6. 进阶把表结构文档变成自动化巡检脚本到这一步你已经有了字典库、比对方法和避坑经验。最后分享一个我常用的技巧把表结构巡检做成定时脚本每周跑一次自动发现文档和库的差异、字段类型变更、索引缺失。这样不用等出问题再翻文档。具体做法是用 Python 连神通数据库查USER_TAB_COLUMNS和USER_IND_COLUMNS和本地字典库比对差异输出到 CSV 或直接发邮件。核心代码框架如下import sqlite3 import jaydebeapi # 神通数据库 JDBC 连接 # 连真实库 conn_real jaydebeapi.connect( com.oscar.Driver, jdbc:oscar://192.168.1.100:2003/CHISDB, [username, password], /path/to/oscarJDBC.jar ) cur_real conn_real.cursor() cur_real.execute( SELECT table_name, column_name, data_type, data_length FROM user_tab_columns ORDER BY table_name, column_id ) real_cols {(r[0], r[1]): (r[2], r[3]) for r in cur_real.fetchall()} # 连本地字典库 conn_dict sqlite3.connect(chis_dict.db) cur_dict conn_dict.cursor() cur_dict.execute(SELECT table_name, column_name, data_type, length FROM columns_dict) dict_cols {(r[0], r[1]): (r[2], r[3]) for r in cur_dict.fetchall()} # 比对 only_in_real set(real_cols) - set(dict_cols) only_in_dict set(dict_cols) - set(real_cols) type_diff {k for k in set(real_cols) set(dict_cols) if real_cols[k][0] ! dict_cols[k][0]} print(库里有但文档没有:, only_in_real) print(文档有但库里没有:, only_in_dict) print(类型不一致:, type_diff)逻辑说明jaydebeapi是 Python 连 JDBC 的常用库神通数据库需要对应的 JDBC 驱动 jar。user_tab_columns是神通数据库的系统视图字段名和 Oracle 类似。比对逻辑用集合运算简单直接。参数方面JDBC URL 里的 IP、端口、库名按实际环境改驱动路径指向你本地的 jar 文件。这个脚本跑顺之后你可以加个定时任务每周一早上跑差异结果发到工作群。这样文档滞后的问题能在第一时间发现而不是等开发踩坑了才回头查。我自己这些年最大的习惯就是不管拿到什么文档先花半小时把它变成可查询、可比对的数据而不是直接读。文档是别人写的库是活的只有把两者对上心里才踏实。希望帮到你。本文还有配套的精品资源点击获取