异构性的四种形态#

• 数据模型异构（data model heterogeneity）：关系表、图、XML、JSON、CSV、纯文本，各用一套模型
• 系统异构（system heterogeneity）：即使采用同一种数据模型，不同系统之间也不完全兼容
• schema 异构（schema heterogeneity）：同一件事，不同的人看法不同，设计出来的 schema 也不同
• 数据层异构（data-level heterogeneity）：同一个实体在不同源里写法不同，比如 IBM、Int. Business Machines、International Business Machines

前两种可以靠连接器和适配器处理，属于工程问题。后两种是语义层面的分歧，工具无法自行判断两个字段是否指同一件事，需要人给出对应关系。

四种形态里 schema 异构出现得最多，它又可以细分成三类差异：表和属性的命名、表和属性的组织方式、schema 覆盖的范围和粒度。

计算机学院和数学学院各自建了人员库，三类差异同时出现：

person(p_id, name, role)
supervision(student_id, advisor_id)

staff(sid, fullname, title)
student(sid, name, advisor_sid)

VKG 的做法是把这份对应关系从查询里抽出来，写成一份独立的映射：先在所有数据源之上定义一层统一的概念描述，再由映射逐条声明每个源的哪张表、哪个列对应哪个概念。查询只针对概念层书写，系统按映射把它翻译成各个库上的 SQL。新增一个学院时补一份该学院的映射，已有的查询不用改。

整体结构是三层：

工业界的同一思路：Palantir Ontology#

在工业界，Palantir 的产品架构建立在 Ontology 这一层之上：把组织里的实体定义成对象类型（Object Type）、属性和链接类型（Link Type），再把这些定义映射到底层已经接入的数据集。分析师面对的是「航班」「机场」「延误」这些对象和它们之间的关系，而不是某个库里的某张表。

这套设计在早期的 Gotham 平台里称为动态本体（dynamic ontology）。「动态」指本体可以随业务演化被重新定义和扩展，不必重做底层的数据管道。

Palantir 把这套结构做成了商业产品并部署在大规模异构数据上。区别在于 Palantir 的模型是专有的，VKG 用的是 RDF、SPARQL、OWL 这套 W3C 标准，本体带有明确的逻辑语义。

Gotham 的动态本体有公开的学术分析（IEEE 2024 的系统分析、The Information Society 2022 的批判性综述），Foundry 的 Ontology 有官方文档。开源领域也有沿用同一架构的尝试，例如 Semantica，把对象、关系、决策和溯源统一放进一张图里供智能体使用。

数据库与商业智能领域的对应问题#

给定一个目标 schema 和一批新数据，如何把数据转换进目标里，这个问题在数据库领域称为 schema mapping，配套的两个子问题是 schema matching（找出源和目标元素之间的语义对应）和 data exchange（构造能真正填充目标实例的映射）。

Rahm 和 Bernstein 2001 年的综述给出了 matcher 的经典分类，即 schema 级还是实例级、元素级还是结构级。系统性的映射生成算法由 IBM 的 Clio 项目开创，EDBT 2011 的这份 tutorial 对这批算法有完整梳理，适合作为入口。

这一类工作现在更常见的统称是数据准备（data preparation），也写作 data wrangling，范围比 schema mapping 大，schema 对齐之外还包括格式转换、清洗和实体消解。Hameed 和 Naumann 的商用工具综述（SIGMOD Record 2020）梳理了这类工具的能力和缺口。

自动化数据准备是近几年的活跃方向。Stanford 的 Wrangler（CHI 2011）走交互路线，系统给出转换建议、由人确认，后来商业化为 Trifacta，2022 年被 Alteryx 收购；微软的 Auto-Suggest（SIGMOD 2020）走学习路线，从大量数据科学 notebook 里学习下一步该做的转换。用大模型做数据准备的工作近两年明显增多，Can Foundation Models Wrangle Your Data?（VLDB 2023）把清洗和集成的五类任务改写成 prompt，用 LLM 做 schema matching 和 entity matching 现在是常见设定，2025 年的一篇综述整理了用语言模型做表格数据准备的现状。

VKG 的映射生成是 schema mapping 的一个特例：源仍然是关系库，目标 schema 换成本体的类和属性，术语是 relational-to-ontology mapping generation。VKG资料收集里的 RODI benchmark 专门评这项任务，组里的 LLM4VKG 把 LLM 做 schema matching 的思路搬到了这个设定上。

商业智能（Business Intelligence，BI）指用报表、看板和多维分析支持业务决策的那一类系统。这个领域的对应物是语义层（semantic layer）。这个词和这套做法都来自 Business Objects，1991 年的专利名为 “relational database access system using semantically dynamic objects”，产品中的实现称为 Universe，作用是让业务人员用业务词汇取数，不必知道表名和字段名。专利名里的 “semantically dynamic objects” 和 Palantir 的 dynamic ontology 用词几乎重合。

语义层现在的主流实现是 Looker 的 LookML、dbt Semantic Layer、Cube、AtScale，以及 Databricks metric views、Snowflake semantic views 这类仓库自带的方案。最近语义层重新受到关注，原因是要给大模型提供一份一致的指标定义。

决策一：声明式映射#

传统数据集成用 mediator，即为每个数据源手写一段转换代码。声明式映射的优势：

• 映射是一份规范说明，阅读时不必跟随控制流
• 设计和维护的成本因此更低
• 支持增量集成，接入新数据源只需追加一组映射，已有映射不受影响
• 格式机器可读，可以参与查询优化

最后一条的影响最大。手写的转换代码对系统是黑盒，只能整体执行。声明式映射可以被系统解析，与用户查询合并后统一重写和优化，具体过程见语义查询优化。

决策二：知识图谱与本体#

传统数据集成的全局 schema 是一个关系模式。VKG 把全局 schema 的数据模型换成知识图谱，图中使用的词汇由本体给出。换用知识图谱的理由：

• 不需要在一开始就锁定一种结构
• 更能容纳异构性
• 更能处理缺失和不完整的信息
• 加入新信息或新数据源时不需要大规模重构

第三条对应 schema 异构里的「范围与粒度」差异。关系模式要求每张表的列固定，某个源缺某个属性时需要填 NULL 或者拆表。RDF 由三元组构成，属性存在时写入对应三元组，不存在时省略，结构本身不用改。

本体承担的是 schema 的角色，类、属性、类层次都在本体里声明。它同时是一套带标准形式语义的逻辑声明，推理能力由此直接可用，不需要在应用层实现，查询处理流程一节给出两个例子。

决策三：虚拟访问#

物化式的数据集成用 ETL，把数据从各个源抽取、转换、装载进一个集成存储，可能是数据仓库，也可能是一份物化的 KG。保持虚拟的理由：

• 数据留在源里，只在查询时访问
• 不需要构造和维护一份可能很大、代价很高的物化副本
• 数据因此始终与源里的最新状态一致
• 可以继续依赖已有的数据基础设施和运维经验
• 同样适合增量集成

第四条在实际项目里尤其重要，源库上多年积累的索引、分区、权限配置和调优经验都能直接复用，不必在新系统里重建一遍。另有一类场合完全排除了物化：医院的数据库不允许拷贝、企业的生产库不允许导出、合作方的数据仅开放读权限。

三个决策的代价集中在两处：映射和本体都需要人工设计，本体的表达能力还有硬性上限，后者的具体边界见本体的表达能力限制。

术语#

VKG 是比较新的术语。同一套技术在早期文献里称为 OBDA（Ontology-Based Data Access，基于本体的数据访问），2010 年前后的论文一律用这个词。扩展到多数据源的场合有时写作 OBDI（Integration）。这几个缩写指的是同一项技术。

处理阶段#

三个阶段依次执行，本体只作用于第一步，映射只作用于第二步：

   SPARQL 查询
        │
        │  ① rewriting     用本体把隐含的知识补进查询
        ▼
   改写后的查询（若干个析取项）
        │
        │  ② unfolding      用映射把三元组模式替换成 SQL 片段
        ▼
   SQL 查询
        │
        │  ③ SQO            消除冗余的 join、DISTINCT、UNION 分支
        ▼
   优化后的 SQL ──────▶ 源数据库执行
                            │
   查询结果 ◀────────────────┘

查询改写：类层次#

第一个例子只用到子类关系。查计算机学院的所有教师：

1
SELECT ?x WHERE { ?x a :Faculty . }

数据库里没有任何一列写着 Faculty，映射里也没有一条规则产出 :Faculty。但本体声明了 Professor 和 AssociateProfessor 都是 :Faculty 的子类，所以改写阶段把这个查询变成两个分支的并集：

1
{ ?x a :Professor . } UNION { ?x a :AssociateProfessor . }

再经过展开，最终的 SQL 大致是：

1
SELECT p_id FROM person WHERE role = 1
2
UNION ALL
3
SELECT p_id FROM person WHERE role = 2

提问的人写了一个类名，系统展开成了两个分支。子类越多，一次改写覆盖的分支越多。新增一条 :Lecturer rdfs:subClassOf :Faculty 之后，原来的查询不用改一个字符。

查询改写：存在量化#

第二个例子涉及存在量化。查计算机学院的教师带了哪些学生：

1
SELECT ?s WHERE {
2
    ?s :isSupervisedBy ?a .
3
    ?a a :Faculty .
4
}

假设表里的数据如下：

person                          supervision
p_id  name   role               student_id  advisor_id
1     陈立   1                  3           1
2     周敏   2
3     吴天   3
4     郑好   3

吴天（p_id=3）在 supervision 表里有记录，导师是教授陈立，这一行直接满足查询。郑好（p_id=4）也是博士生，但表里没有他的师生关系记录。

按 SQL 的语义，郑好不该出现在结果里。按本体的语义，他应该出现：本体声明了每个博士生都有一位教师作为导师，郑好是博士生，因此他有导师，只是这位导师是谁数据库里没记。

关键在于 ?a 只出现在 WHERE 里，不在 SELECT 里。查询要的是学生，导师只作为存在性条件出现。既然本体保证这个条件成立，郑好就该被返回。

改写阶段把这层推理体现为一个额外的析取项：

1
{ ?s :isSupervisedBy ?a . ?a a :Faculty . }
2
UNION
3
{ ?s a :PhDStudent . }

多出来的这个分支就是 tree-witness rewriting 的结果。tree witness 指的是那个不存在于数据、只存在于模型中的匿名个体，也就是郑好的导师。

映射展开#

展开阶段的工作比改写机械：把查询里每一个三元组模式，替换成映射中能产出它的那些 source 查询，然后按查询的图结构做 join。

?s :isSupervisedBy ?a 只有 supervision 一条映射能产出，替换成 SELECT student_id, advisor_id FROM supervision。?a a :Faculty 经过改写已经变成两个分支，各自对应一条映射。三部分拼起来就是最终 SQL 的骨架。

一个三元组模式可能对应多条映射，这时展开的结果是 UNION。映射拆得越细，UNION 分支越多，这是映射设计需要考虑性能的原因之一。

语义查询优化#

朴素展开出来的 SQL 通常很臃肿，充满自连接和 DISTINCT。Ontop 会利用数据库的主键、外键、唯一约束把它们消掉，比如两个子查询按主键连接同一张表时可以合并成一个。

这一步的效果取决于约束信息是否可见。源库没建约束、或者查询走的是视图，Ontop 只能按最坏情况生成 SQL。

想看实际生成的 SQL，把日志级别打开：

1
ONTOP_LOG_LEVEL=DEBUG ./ontop endpoint -m lab.obda -t lab.ttl -p lab.properties

入门阶段这个开关比读文档更直接。写一条 SPARQL，看系统生成了什么 SQL，然后改动本体或映射再看一次，几轮下来整套机制就清楚了。