元数据体系 × 本体系统 —— 关系解析与「基于元数据构建本体」详细方案

cmx 元数据体系 × 本体系统 —— 关系解析与「基于元数据构建本体」详细方案

版本:v1 · 日期 2026-09-10
范围:DCT(字典)/ DOC(单据)/ FLC(弹性组合)三元定义(+ RPT 报表)与 cmx-ontology 本体系统 的关系,以及在元数据之上构建本体的完整工程方案。
前置三部曲:《DCT》《DOC》《FLC》元数据实现设计方案。本篇是它们的汇流与升维——把三类元数据接成一个可推理、可穿透、可操作的「对象世界」。

摘要

企业的物理库里只有「行与列」,没有业务语义。本体(Ontology)是企业的世界模型——它回答「什么存在、如何关联、何为真」,是纵向贯穿全栈的「真相脊柱」。而 元数据,就是让物理表变成对象世界的那张「地图」:它告诉本体「采购申请对象 = 哪张表、哪些列、走哪个外键、指标怎么算」。

一句话概括三者关系:

主数据(DCT)「存」· 单据(DOC)「映射查」· 指标报表(RPT)「算」,而元数据是让本体知道「怎么存、怎么查、怎么算」的那本说明书。

本体不是推倒重来,而是既有元数据的运行时投影:你在模型中心用 DCT/DOC 定义好字典与单据,本体据此自动生成对象类型 + backing 映射,再经「声明式对象集 → 一条 SQL」把查询下推回传统关系库。元数据是唯一建模真源,本体是它的语义层。

_{图1 · 从元数据到本体的全景四层:元数据建模 → 翻译层 → 本体(两库) → 消费}

1. 本体系统是什么(概念精要)

cmx-ontology 是 Palantir Foundry 式的企业本体平台(Rust,独立微服务 :8097),用六个元模型原语描述企业:

两库分离是本体最重要的结构事实:

• 元数据库 om_*:六原语的类型定义(om_object_type/om_link_type/om_action_type/om_function/om_source_mapping),JSONB 存储、有版本快照 om_version。低频写、强一致。
• 对象库 oo_*/ol_*/oe_*:物化对象实例(oo_<type>)、关系边(ol_edge)、编辑日志/发件箱(oe_*)。高频读写、面向查询优化。

与 FLC「文件存储」不同,本体定义持久化在 Postgres(JSONB);与 DCT/DOC「编译建表」也不同,本体的两写口是漏斗灌入与 Action 写回,对象库不开放裸 SQL 写——一切可审计、可回放、可 CDC。

2. 三元定义(+RPT)→ 本体原语的映射

这是关系的核心。三类元数据不是平行地「都变成对象」,而是各按性质映射到不同的本体原语:

_{图2 · 三元定义(+报表)→ 本体六原语 映射矩阵:各按性质映射,非平行「都变对象」}

• DCT 字典 → 一等对象类型(materialized)。每个供应商/物料成为 oo_<type> 里的一行。主数据高复用、关系密集,是对象图的枢纽节点。字典的树(科目表)天然是 LinkType 的自关联特例,复用 cmx-hierarchy。
• DOC 单据 → 对象类型(不物化,投影)。单据头是对象类型(有身份、可连关系、可挂 Action),但数据留在物理单据表 cv_*,本体只做映射投影,查询时才拉。关键实现事实:当前 map_doc 把一张多层单据映射为单个对象 + 嵌套层块属性(头/行/明细折叠为父的 array/struct 属性,constraints.children 递归),不拆成多对象、不产组合关系。明细行不建独立对象(千万~亿/月,逐行建对象是灾难)。
• RPT 报表 / 指标 → 函数,非对象。指标是 derivedProperty(FEEL 求值)/ aggregation(SQL 聚合下推),定义一次、随数据实时算,不存实例。报表是引擎产物,报表平台按定义组 SQL/公式算。
• FLC 弹性组合 → 不是本体运行时原语。FLC 留在元数据建模侧(维度组合的规则/呈现),至多驱动 Action 的动态表单 / 对象视图的呈现变体(同对象按维度组合渲不同列),但本体不把它投影成对象/关系/动作/函数。

承载分工也在这张图里:Property 的 semanticType/i18n 复用 cmx-meta-data;Link 的层级复用 cmx-hierarchy;Action 的副作用走 cmx-flow、校验走 cmx-rulesengine;Function 的运行时走 cmx-rulesengine(FEEL/Rhai)。本体不重造轮子,它是这些既有能力的语义编排层。

3. 四类数据的不同待遇(为什么不全物化)

不是所有数据都当对象、都物化。本体按数据性质分档——这是「既有对象语义、又不必把整企业数据搬进一张图」的关键取舍。

_{图3 · 四类数据的不同待遇:主数据「存」· 单据「映射查」· 指标报表「算」}

三档实例化(规模化的核心决策):

4. 元数据即翻译层:声明式对象集 → 一条 SQL

不物化的数据「用时查传统库」,但你不手写 SQL、不碰表名——本体编译器读元数据,把声明式对象集自动翻译成一条 SQL。

_{图5 · 元数据即翻译层:声明式对象集 → 编译器读 om_ → 一条 SQL → 传统库}

流程:① 声明式意图 → ② 编译器(compile.rs 读 om_)→ ③ 一条 SQL → 传统关系库。

你写: Base(采购申请).filter(月='2026-08').searchAround(供应商).aggregate(sum(金额))
编译: 本体查元数据 → 采购申请=cv_采购申请表、供应商关系走 supplier_id 外键
产出: SELECT s.pk, SUM((r.props->>'金额')::numeric)
FROM cv_采购申请 r JOIN 供应商 s ON s.pk = r.supplier_id
WHERE r.month = $1 GROUP BY s.pk; — 过滤/JOIN/聚合全部下推

与手写 SQL 的本质区别:①你写业务语义,不碰表名/JOIN;②底层表变了只改元数据映射,上层查询与前端零改;③三跳编译成一条 SQL,杜绝 N+1;④值全参数绑定、标识符白名单,结构性防注入。

元数据两职责:①登记(对象=哪张表、pk/title、关系走哪个外键、指标怎么算);②驱动(查询编译、投影、校验+写侧 Action、OSDK 生成+UI 渲染、智能体接地)。本质:元数据 = 关系世界 ↔ 对象世界 的翻译层。

5. 基于元数据构建本体:两条集成路径

「构建本体」= 把元数据(定义)与物理数据(行)接进本体。这是两条正交路径,切勿混为一谈:

_{图4 · 基于元数据构建本体的两条集成路径(定义时反向导入 + 数据时漏斗)+ oo_ 物化三模式}

5.1 路径 A · 定义时反向导入(建 Schema)

• 输入:cmx-model 的 DocMetaView / DctQuery → 适配为归一化 JSON(本体不直接读 cf_*/cv_*,保持解耦)。
• 处理:import.rs 的 map_doc(DOC → 单对象 + 嵌套层块属性)/ map_dct(DCT → 引用对象类型 + seed 对象)。
• 产出:写入 om_object_type,并盖 cmx_origin 溯源戳({source:"doc"|"dct", docApiName|dctApiName})+ dam(域/应用/模块)+ doc_type。
• 绑定机制:是软溯源指针,不是 FK/drn/dictId 硬引用。对象类型 schema 在导入时派生自 DOC/DCT 定义(快照/投影),此后独立活在 om_object_type。

这解释了本体与 cmx-model 的解耦:本体消费「调用方适配的归一 JSON」,定义时不读物理表,唯一回链是软 cmx_origin。元数据是唯一建模真源,本体是它的运行时投影——改元数据即可再生成,不推倒重来。

5.2 路径 B · 数据时漏斗(灌对象)

• 映射规格 SourceMapping(持久化为 om_source_mapping):object_type + source_query(SELECT,可打到 cf_*/cv_* 或任意源)+ key_columns(→pk)+ title_column + property_map(源列→对象属性)+ required。
• 内核 map_row(纯逻辑、零 IO):逐行映射 + 更严校验(主键非空、必填齐全、类型可转),产出 MappedObject{pk,title,properties} 或 Violation[]。
• 执行 run_full_sync(壳层):执行 source_query 读源行 → 逐行 map_row → 合格者批量 upsert 进 oo_<type>,违规者入 oo_quarantine,记 SyncReport{read,written,quarantined}。对象是物理拷贝进 oo_<type>,不是虚拟视图。

5.3 oo_ 物化三模式(按源表是否存在 + 是否需增强 选择)

为什么两库分层(而非给 ERP 表加列): 这是「账本 vs 索引卡」的分层,不是冗余——

• 原表 = 账本(System of Record):权威事实 + 事务,含 ERP 私有字段,不可替代;
• oo_ = 索引卡 + 语义标签(System of Engagement):服务跨域关联、智能推理、写侧动作。

给 ERP 表加本体关注点(统一 id、向量、边)会污染其结构、职责不清,且多套源系统的主数据只有在 oo_ 层才能对齐成同一对象。这正是 Palantir Foundry 范式:源系统权威,本体是策划过的物化语义层。

5.4 写侧:Action 写回 oo_,不回写 cv_

Action 是本体的「手」,四部分:parameters(表单参数)+ authz(前置鉴权,PDP)+ edits(create/modify/deleteObject、add/removeLink)+ sideEffects(startBusinessProcess/computeReport/notification/webhook…)。

以「审批采购申请」为例:

关键:Action 写入本体自己的 oo_*/ol_edge,不调 DOC saver、不碰 cv_*——「编辑覆盖源」(edit-overrides-source):用户编辑落本体对象库并优先,漏斗重灌时把源值合并于其下。漏斗与 Action 是 oo_* 的两个写入者,DOC/cv_* 只在漏斗上游。

6. 拓扑与规模化:承载分工

治理原则:让本体承载「语义与推理」,让关系数据库承载「体量与事实」。

_{图6 · 承载分工:存储分层 · PostgreSQL 选型(非图库)· 联邦式单一本体拓扑}

6.1 存储分层:内存放定义,库放数据

• 元数据 om_*(KB~MB,读多写少) → 内存/缓存(cmx-redis 失效广播);
• 对象数据 oo_*/ol_edge/cv_*(GB_TB,千万亿行/月) → 永远在库,按月/租户分区、冷热分离,过滤/JOIN/聚合下推——绝不把千万行 load 进内存。

6.2 存储引擎:PostgreSQL,明确不是图库

企业遍历的决定性特征是有界深度(沿已知外键走 2~4 跳)——这是关系 JOIN 的主场,不是图库。PG 在批量写吞吐、有界遍历、聚合报表、ERP 同库零迁移、运维/HA/信创上全面胜出;对象集代数编译成一条 SQL(对标 Palantir Object Set Service,含 JOIN 避免 N+1)。专用引擎是旁路而非替代:pgvector(向量)、PostGIS(空间)、图引擎(仅用于真·无界 M:N 子域,如集团股权穿透)。

6.3 关系粒度:物理外键全都有,语义关系精挑选

物理外键 ≠ 本体关系。 判据:这条关系会不会被 Search-Around 走到、被智能体推理、被报表下钻?会 → 建 LinkType;不会 → 留作物理层普通 FK。把每个 FK 都提升会膨胀成「数据库 schema 的镜像」,失去「语义骨架」的价值。落地:1:1/1:N 复用既有 FK 列(零额外存储);真 M:N 才写 ol_edge。

6.4 拓扑:联邦式单一本体

• ✕ 单一大一统 → 泥球,演进僵化、性能差、治理难;
• ✕ 孤立多本体 → 语义碎片(「客户」在财务/CRM/物流是三个不能 join 的东西)、主数据重复——把本体降级成又一批孤岛;
• ✓ 联邦式单一 → 逻辑一个本体、按 DAM(域/应用/模块) 分区治理、核心域(Kernel)共享主数据定义一次、物理可分而语义统一。跨域 join:核心域实体定义一次(Core.Customer),域对象经共享 PK / 接口(IParty)指向,Search-Around 一跳到达。这是 Palantir Foundry / Data Mesh 的共同答案。

建模铁律:单据内层次(头/行/明细)用嵌套复合属性表达(一个整体),只有跨域实体才用 LinkType——切勿「把单据层次当成跨域关系」。这与 §2「DOC → 单对象 + 嵌套层块」的实现一致。

7. 建设路线图(O0–O8)

从元数据到本体的落地顺序:先 O1 建模引擎就位 → 路径 A(定义时反向导入)从 cmx-model DOC/DCT 生成对象类型 → O3 路径 B(漏斗)从 cf_*/cv_* 灌对象 → O4 Action 写侧 + O5 函数(指标)→ O6 安全 → O7 OSDK/API → O8 前端与案例。

8. 为什么这样设计:决策 → 收益

9. 结语:元数据是地基,本体是脊柱

三元定义(DCT/DOC/FLC)+ RPT 把企业的字典、单据、变体、报表收敛成一份份可版本化、AI 可读可改的元数据;本体则把这些元数据接成一个可推理、可穿透、可操作的对象世界——不重造存储,而是作为「关系世界 ↔ 对象世界」的翻译层与运行时投影。

• 元数据回答「怎么存、怎么查、怎么算」(地图 / 编译器符号表);
• 本体回答「什么存在、如何关联、何为真」(世界模型 / 真相脊柱);
• 二者相加,LLM 有了接地、Agent 有了可操作的对象与动作——这正是认知型企业系统的地基:让智能体「看得懂对象、办得成 Action」。

一句话:元数据让物理表变成可查询的语义,本体让语义变成可推理、可行动的世界——你在模型中心改一份 JSON,本体那端就多了一类可被智能体理解和操作的企业对象。

附录 · 关键 scheme 速查

• 表前缀:om_*(本体定义,JSONB/缓存)· oo_<type>(对象物化表,pk/title/props JSONB)· ol_edge(M:N 关系边)· oe_action_log/oe_outbox(审计/事务发件箱)· cf_*(DCT 字典)· cv_*(DOC 单据)· cm_*(原 ERP 主数据)
• 对象类型溯源字段:backing(物理表映射)· datasource(漏斗源)· cmx_origin(DOC/DCT 溯源)· dam(域/应用/模块 分区键)· marking(密级)· vector(嵌入)
• Action 原语:edits = createObject/modifyObject/deleteObject/addLink/removeLink;sideEffects = startBusinessProcess/computeReport/notification/webhook/callFunction/emitEvent;智能体连接器 = onto_execute_action
• 服务:cmx-model :8093(DCT/DOC/FLC/编码)· cmx-report :8092(RPT)· cmx-ontology :8097(本体运行时)