CREATE TABLE beds ( bed_id uuid DEFAULT gen_random_uuid() NOT NULL, bed_number varchar(100) NOT NULL, department_id uuid NULL, bed_type varchar(20) NULL CHECK (bed_type IN ('普通床', 'ICU床','隔离床', '抢救床','儿科床')), equipments jsonb NULL, current_status varchar(20) NULL CHECK (current_status IN ('占用','空闲','清理中')), physical_location jsonb NULL, support_isolation bool DEFAULT false NULL, specialty_attribute text NULL, created_at timestamptz DEFAULT now() NULL, updated_at timestamptz DEFAULT now() NULL);
首先是可追溯性问题。当系统只保留“当前状态”时,无法进行历史追溯、操作追溯,很难回答看似简单的问题:谁用过这张床?病人为什么转科?床位状态为什么是这样?
其次是逻辑分散、维护成本高的问题。技术实现中,每个业务操作需要编写专门的存储过程(procedure),且牵扯多种函数或表关系,当业务规则发生变化时,往往需要同时修改多处代码且新增业务类型时,需要考虑对现有流程的影响。随着业务流程的复杂,会导致系统越来越臃肿,最终复杂的存储过程与触发器会难以理解和调试,成本也会越来越高。
最后是系统语义模糊的问题。在状态驱动模型中,数据库中的一行记录,往往混合了三种含义:现实世界发生过什么;系统当前认为是什么状态;流程执行到了哪一步。这三者在数据层面被耦合在一起,使得系统越来越像一个“黑盒”。
综上所述, 医院这种高度依赖时间、行为和约束,且场景多样复杂,行为动态变化的需求下,我们需要新的数据管理思维去建立新的系统。以床位系统为例,需要有以下优点:
因此,我们希望系统能够完整记录整个过程,状态只是从事实中推导出的结果。
我们以患者转科的例子来比较传统思维与Ontology的区别:
传统转科思维模式:
(1)更新患者表的状态
UPDATE patient SET department_id = '心内科' WHERE patient_id = '001';
UPDATE bed SET current_status = '清理中' WHERE bed_id = 'B01';UPDATE bed SET current_status = '占用' WHERE bed_id = 'B02';
Palantir思维模式:
(1)在行为表中记录一个不可变的事实
INSERT INTO bed_events ( patient_id, event_type, event_time, details) VALUES ( '001', '占用', '2024-01-15 14:30:00', '{ "department": "心内科", "bed": "B01", "reason": "确诊冠心病需专科治疗", "doctor": "张明", "order_id": "ORDER_789" }'::JSONB);CREATE VIEW current_bed_status ASWITH latest_bed_events AS ( SELECT DISTINCT ON (bed_id) * FROM bed_events ORDER BY bed_id, event_time DESC)
1. 记录事实
本体论的核心在于事实优先,而相较于传统数据库,PostgreSQL在事实型数据建模方面具备天然优势:
· JSONB类型
可存储任意结构的上下文数据,适合事实表的构建,当业务流程变化时,无需频繁修改表结构,只需在JSONB中扩展新的字段即可;
· 时间类型丰富
PostgreSQL提供了多种时间类型,并支持时区转换,适合精确描述行为发生的完整时间维度;
· 表继承与分区
通过表继承能自然建立事实表的层级关系,而分区功能可以有效管理海量历史数据,提高查询性能和管理效率。
2. 描述状态
在本体论中,“状态”是由事实型数据推导的结果,而PG在这方面具备显著优势:
· 视图与物化视图
PostgreSQL支持复杂的视图和物化视图,可以从事实表中实时推导出当前状态。物化视图支持自动或手动刷新,在性能与实时性之间提供灵活平衡。
· 窗口函数与聚合
PostgreSQL拥有强大的窗口函数和聚合能力,能够基于历史事实序列计算出各种状态指标,如平均住院日、床位周转率等。
· 递归查询支持
通过CTE(公共表表达式)和递归查询,可以处理复杂的层次结构和时序分析,例如完整追溯患者的整个诊疗过程。
3. 维护数据一致性
4. 特有扩展能力
PostgreSQL通过丰富的扩展生态系统,能够满足医疗场景中的特殊需求:
· 空间数据分析
PostGIS扩展支持地理空间数据存储与分析,可用于医院床位布局优化、患者动线分析等场景。
· 外部数据集成
通过FDW(Foreign Data Wrapper)可以透明地集成医院其他系统的数据,实现真正的数据融合,而无需复杂的ETL流程。
· 时序数据优化
TimescaleDB扩展专门优化时序数据处理,能够高效管理医院环境中产生的大量时间序列事实数据。
· 图数据支持
Apache AGE扩展为PostgreSQL增加图数据库能力,可以分析复杂的医患关系、疾病传播路径等。
5. 生态成熟
综合来看,在本体论中,PostgreSQL 承担以下角色:
· 现实世界行为的事实存储层
· 业务状态的推演与分析基础
· 多系统数据一致性的核心锚点
这些特点使PostgreSQL作为数据层的坚实基础,成为本体论方法中落地的理想选择
在本文中,我们以医院床位管理为例,设计一个最小的 PostgreSQL Demo,用于验证 本体论思路在实际业务场景中的可行性。
本体论视角下核心对象建模
在医院床位管理场景中,主要可以抽象出以下几类核心对象:
· Patient
· Bed
· Department
· Order(医嘱表):表示医生的医嘱,是意图而不是已发生的事实
这些对象本身相对稳定,业务变化不体现在对象结构上,而是体现在它们的关系变化上。
create table beds(bed_id uuid default gen_random_uuid() not null,bed_code varchar(100) not null,department_id uuid null,bed_type varchar(20) null check (bed_type in ('普通床', 'icu床','隔离床', '抢救床','儿科床')),last_changed_at timestamp);系统中的事实存储
在床位管理场景中,有事实存储表:bed_actions,只负责记录事实,不包含业务逻辑。需要强调的是:
· Action 表不包含状态字段
· 不区分“执行中 / 已完成 / 已失败”
· 一条 Action 一旦写入,即被视为系统确认的事实
这使得 Action 表天然具备以下特性:
· 事实不可篡改
· 历史完整保留
· 行为语义清晰
create table bed_actions ( action_id uuid primary key default gen_random_uuid(), action_type text not null check( action_type in ('被分配','被释放')), patient_id uuid not null references patients(patient_id), bed_id uuid references beds(bed_id), from_department_id uuid references departments(department_id), to_department_id uuid references departments(department_id), context jsonb, occurred_at timestamptz not null default now());在这个模型中表达一次转科流程,是两条action:释放原床和分配新床
#释放原床insert into bed_actions( action_type, patient_id, bed_id, from_department_id, context) values( '被释放', 'Patient_01', 'B01', 'D01', jsonb_build_object( 'reason','转科转出', 'order_id':order_id ));#分配新床insert into bed_actions( action_type, patient_id, bed_id, from_department_id, context) values( '被分配', 'Patient_01', 'B02', 'D02', jsonb_build_object( 'reason','转科转入', 'order_id':order_id ) );
若想查询“某科室有哪些空床”,根据bed_actions表派生状态,使用SQL进行查询
#构建床位状态表create view bed_current_status asselectb.bed_id,b.department_id,casewhen last_action.action_type = '被分配' then '占用'when last_action.action_type = '被释放' then '空闲'else '空闲'end as bed_statusfrom beds bleft join lateral (select *from bed_actions awhere a.bed_id = b.bed_idorder by occurred_at desclimit 1) last_action on true;#查询某科室空床select *from bed_current_statuswhere department_id = :dept_idand bed_status = '空闲';
从状态驱动到行为驱动的转变,本质上是数据管理思维的根本革新。 传统系统试图维护一个"完美的当前状态",而本体论方法选择忠实地记录"所有重要事实"。这种转变让系统具备了前所未有的追溯能力和灵活性。
PostgreSQL凭借其强大的数据管理能力,成为这一方法落地的理想选择。 它不仅提供了技术实现的可能,更重要的是其设计哲学与本体论思想高度一致:都强调数据的完整性、一致性和可追溯性。
在实际应用中,这种架构实现了职责的清晰分离:应用层专注于业务流程编排,PostgreSQL作为数据基石。 选择PostgreSQL,并以行为为核心建模时,许多看似复杂的问题——历史追溯、状态一致性、系统可解释性——都会在模型层面被自然化解。数据库不再只是数据的存储容器,而成为对现实世界的结构化表达。这正是本体论方法在复杂业务系统中真正的价值所在。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/70051178/viewspace-3188016/ ,如需转载,请注明出处,否则将追究法律责任。