Ontop 详解：不搬数据库，也能把 MySQL / PostgreSQL 变成知识图谱
如果企业的数据已经全部存在 MySQL、PostgreSQL、Oracle 里，还需要为了知识图谱重新搬一遍数据吗？
Ontop 给出的答案是：不一定。
GitHub：
https://github.com/ontop/ontop
官网：
一、先说结论：Ontop 是干什么的？
Ontop 是一个开源的 Virtual Knowledge Graph，虚拟知识图谱系统。
它最核心的能力可以用一句话说明：
把关系型数据库“映射”为知识图谱，但数据依然保留在原来的数据库里。
也就是说：
MySQL
PostgreSQL
Oracle
SQL Server
↓
Ontop
↓
Virtual Knowledge Graph
↓
SPARQL
你并不一定需要：
MySQL
↓
ETL
↓
RDF
↓
Neo4j / RDF Store
把整个数据库复制一份。
Ontop 会在查询的时候，把针对知识图谱的 SPARQL Query 转换成关系数据库能够执行的 SQL Query，然后直接查询原始数据库。
这就是它最有意思的地方。
截至 2026 年 8 月，Ontop GitHub 主仓库约有 900+ Stars，采用 Apache 2.0 License；GitHub Release 页面显示当前稳定版为 Ontop 5.5.0，发布时间为 2026 年 2 月 14 日。
二、为什么会出现 Ontop？
先看一个非常常见的企业系统。
比如一个电商平台的数据可能全部放在 MySQL 里：
users
orders
products
suppliers
payments
表之间通过：
user_id
order_id
product_id
supplier_id
连接。
对后端开发来说，这种结构非常熟悉。
例如：
SELECT
u.name,
o.id,
p.name
FROM users u
JOIN orders o
ON u.id = o.user_id
JOIN order_items oi
ON o.id = oi.order_id
JOIN products p
ON oi.product_id = p.id;
但是知识图谱不是这么理解世界的。
知识图谱可能会把它描述成：
User
|
| places
↓
Order
|
| contains
↓
Product
|
| suppliedBy
↓
Supplier
也就是说：
数据库关注的是：
表
字段
主键
外键
知识图谱关注的是：
实体
关系
语义
两套世界观不一样。
三、传统知识图谱的问题
如果企业已经有：
1000 万用户
5000 万订单
1 亿商品记录
传统做法可能是：
生产数据库
↓
ETL
↓
数据清洗
↓
RDF Triple
↓
Knowledge Graph
问题马上就来了。
1. 数据重复
原来 MySQL 已经有一份：
100GB
现在知识图谱里又有：
100GB+
相当于复制了一份。
2. 数据同步
数据库发生变化：
订单状态：
pending
↓
paid
知识图谱里面也必须同步。
于是开始出现：
CDC
Kafka
ETL
同步任务
定时任务
系统越来越复杂。
3. 实时性
数据库已经：
payment_status = paid
知识图谱可能还停留在：
payment_status = pending
如果 Agent 使用的是知识图谱，就有可能拿到旧数据。
4. 数据治理成本
企业实际上变成：
业务数据库一套
知识图谱一套
搜索一套
向量数据库一套
数据越多，维护成本越高。
于是 Ontop 提出了另外一种思路：
不复制数据，让知识图谱成为数据库上面的一层语义视图。
四、什么是 Virtual Knowledge Graph？
Virtual Knowledge Graph，简称：
VKG
可以翻译成：
虚拟知识图谱。
所谓“虚拟”，意思就是：
图并不真正完整存储在那里。
真正的数据还是：
MySQL
PostgreSQL
Oracle
Ontop 在数据库上方增加一层：
Ontology
+
Mapping
最终：
SPARQL
↓
Ontology
↓
Mapping
↓
Ontop
↓
SQL
↓
Relational Database
用户看见：
Knowledge Graph
数据库看见：
SQL
Ontop 负责中间翻译。
这就是它的核心。
五、一个具体例子
假设数据库里有一张：
CREATE TABLE users (
id BIGINT PRIMARY KEY,
name VARCHAR(100),
email VARCHAR(200),
company_id BIGINT
);
还有：
CREATE TABLE companies (
id BIGINT PRIMARY KEY,
name VARCHAR(200)
);
数据库世界里：
users.company_id
只是一个外键。
但是在 Ontology 里面可以定义：
User
Company
以及：
User
worksFor
Company
于是从语义层面：
王仕宇
|
| worksFor
↓
JavaPub
不再只是：
company_id = 1001
这就是语义层的价值。
六、Ontop 的三个核心部分
Ontop 可以简单理解为三个核心模块：
Ontology
Mapping
Query Rewriting
七、第一部分：Ontology
Ontology 负责定义：
这个业务世界里面有哪些概念，以及它们之间是什么关系。
例如电商：
User
Order
Product
Supplier
Payment
关系：
User
↓ places
Order
Order
↓ contains
Product
Product
↓ suppliedBy
Supplier
Order
↓ paidBy
Payment
如果使用 OWL / RDF 表示，可以进一步描述：
User is a Person
Supplier is an Organization
Order hasPayment Payment
Ontology 不负责保存具体：
王仕宇
订单 10001
iPhone 17
它主要定义：
世界的结构。
八、第二部分：Mapping
Mapping 是 Ontop 最重要的部分之一。
因为数据库和 Ontology 本身是完全不同的两个世界。
需要告诉 Ontop：
数据库里的 users 表
=
Ontology 里的 User
比如：
users.id
对应：
User URI
然后：
users.name
对应：
User.name
再比如：
users.company_id
对应：
User worksFor Company
这就是 Mapping。
九、一个 Mapping 示例
假设：
SELECT
id,
name
FROM users;
可以映射成类似：
http://example.com/user/{id}
rdf:type
ex:User
以及：
http://example.com/user/{id}
ex:name
{name}
最终数据库：
id = 1
name = Alice
在图世界里：
User/1
|
rdf:type
|
User
以及：
User/1
|
name
|
Alice
这就是：
Relational Data
↓
RDF View
十、R2RML 是什么？
Ontop 支持 R2RML Mapping。
R2RML 是 W3C 用来描述：
如何把关系型数据库映射成 RDF 的标准。
名字也很好理解：
RDB
to
RDF Mapping Language
它主要描述：
哪张表？
哪个 SQL？
生成什么 Subject？
Predicate 是什么？
Object 从哪个字段来？
例如概念上：
SELECT id, name
FROM users
映射：
{id}
→ User
然后：
{name}
→ User.name
Ontop 就可以知道该怎么构造知识图谱。
十一、Ontop 最核心的一步：SPARQL 转 SQL
这才是 Ontop 真正厉害的地方。
用户写：
SELECT ?name
WHERE {
?user a :User .
?user :name ?name .
}
Ontop 接收到之后，并不会去一个 RDF Database 里查。
它会根据：
Ontology
Mapping
进行 Query Rewriting。
最后可能生成：
SELECT name
FROM users;
数据库执行 SQL：
Alice
Bob
Charlie
Ontop 再把结果转换回 SPARQL Result。
整个流程：
SPARQL
↓
Ontology Reasoning
↓
Mapping
↓
Query Rewriting
↓
SQL
↓
Database
↓
Result
十二、复杂查询会发生什么？
例如 SPARQL：
SELECT ?user ?product
WHERE {
?user :places ?order .
?order :contains ?product .
}
语义层看起来非常简单：
User
↓ places
Order
↓ contains
Product
但是数据库可能是：
users
orders
order_items
products
Ontop 最终需要翻译成：
SELECT
u.id,
p.id
FROM users u
JOIN orders o
ON o.user_id = u.id
JOIN order_items oi
ON oi.order_id = o.id
JOIN products p
ON p.id = oi.product_id;
对于上层开发者来说：
不再需要了解：
order_items
product_id
user_id
各种 JOIN
只需要理解：
User
places
Order
contains
Product
这就是 Ontology 带来的抽象。
十三、Ontop 和数据库 View 有什么区别？
有人可能会说：
这不就是数据库 View 吗？
不完全一样。
数据库 View：
SQL Schema
↓
SQL View
本质还是：
表
字段
Ontop：
Relational Schema
↓
Semantic Model
你看到的是：
User
Organization
Order
Product
worksFor
purchased
owns
而不是：
tbl_user
company_id
order_user_rel
更重要的是 Ontology 还可以表达：
继承
类型关系
语义规则
这已经不是普通 View 能直接替代的。
十四、为什么企业特别适合 Ontop？
因为企业数据最大的特点就是：
数据很多，但都已经存在数据库里。
比如银行：
Customer
Account
Transaction
Loan
实际存储：
Oracle
医院：
Patient
Doctor
Diagnosis
Treatment
存储：
PostgreSQL
制造业：
Machine
Factory
Order
Supplier
Part
存储：
ERP Database
这时候如果要上知识图谱，最麻烦的是：
重新构建一套数据系统。
Ontop 的优势就在于：
数据库不用动。
只增加语义层。
十五、一个企业 Ontop 架构
可以设计：
AI Agent
|
↓
GraphRAG
|
↓
SPARQL
|
↓
Ontop
/ \
Ontology Mapping
\ /
|
↓
-----------------------------
| | |
MySQL PostgreSQL Oracle
| | |
-----------------------------
|
企业业务数据
这时候 Ontop 就像：
企业数据库和 AI 之间的语义中间层。
十六、Ontop + AI Agent
这也是我觉得 Ontop 在今天重新变得非常有意思的地方。
以前：
Ontop 更多是：
Semantic Web
Knowledge Graph
SPARQL
现在可以把 AI Agent 放上去。
比如用户问：
去年购买过服务器，并且当前合同仍然有效的客户有哪些？
Agent 首先理解：
Customer
purchased
Server
hasContract
Contract
然后生成：
SPARQL
交给 Ontop。
Ontop：
SPARQL
↓
SQL
然后：
MySQL / PostgreSQL
返回真实业务数据。
整个链条：
自然语言
↓
LLM
↓
SPARQL
↓
Ontology
↓
Ontop
↓
SQL
↓
业务数据库
这就是一个非常漂亮的：
Semantic Data Agent。
十七、为什么不直接让 LLM 生成 SQL？
这个问题很关键。
现在很多项目是：
自然语言
↓
LLM
↓
SQL
也就是 Text-to-SQL。
比如用户问：
查询购买过服务器的客户。
LLM 必须知道：
customers 表
orders 表
order_items 表
products 表
字段名称
JOIN 条件
问题是企业数据库可能有：
2000 张表
数万个字段
LLM 很难理解。
加 Ontology 之后
Agent 看到的是：
Customer
Order
Product
purchased
不需要知道：
crm_customer_base_v2
sales_order_master
sales_item_relation
底层复杂度交给：
Mapping + Ontop
于是：
自然语言
↓
Semantic Query
↓
SPARQL
↓
Ontop
↓
SQL
从系统设计上可能更加稳定。
十八、这可能比 Text-to-SQL 更适合大型企业
小项目：
10 张表
Text-to-SQL 完全够用。
但是大型 ERP：
500+
1000+
5000 张表
如果全部把 Schema 扔给 LLM：
基本不可行。
Ontology 可以把：
5000 张数据库表
抽象成：
Customer
Order
Product
Supplier
Employee
Factory
可能只有几十、几百个核心概念。
于是：
复杂物理数据模型
↓
简单业务语义模型
这就是 Ontology 最大的价值之一。
十九、Ontop + RAG
Ontop 也可以和传统 RAG 配合。
比如：
结构化数据：
MySQL
走：
Ontop
非结构化数据：
PDF
Word
Wiki
走：
Vector Database
然后：
用户问题
|
↓
Agent
/ \
Graph Vector
| |
Ontop RAG
| |
Database Documents
\ /
↓
LLM
这比纯 Vector RAG 能处理更多问题。
二十、Ontop + GraphRAG
进一步可以：
Ontology
↓
Virtual Knowledge Graph
↓
Graph Retrieval
↓
Document Retrieval
↓
LLM
例如用户问：
A 公司最近为什么出现交付延期？
首先通过 Ontop 找：
A 公司
↓
订单
↓
供应商
↓
产品
↓
物流
然后再到向量数据库搜索：
这些订单对应的合同
邮件
会议纪要
故障报告
这就是：
Structured Graph
+
Unstructured RAG
结合起来。
二十一、Ontop 支持什么数据库？
Ontop 面向关系数据库。
常见场景包括：
PostgreSQL
MySQL
Oracle
SQL Server
本质依赖：
JDBC
连接数据库。
因此它本身特别适合 Java / 企业后端生态。
二十二、Ontop 是 Java 项目
Ontop 主体使用 Java 开发。
GitHub 项目本身是 Maven 工程。
源码构建：
git clone https://github.com/ontop/ontop.git
cd ontop
然后：
mvn clean install
官方当前 Version 5 分支的 README 标明构建使用 Maven 3.6+ 和 Java 11。
二十三、Ontop 也支持 Docker
Ontop 提供官方 Docker 镜像。
因此生产环境可以：
PostgreSQL
+
Ontop
+
Ontology
+
Mapping
直接容器化。
一个典型结构：
docker-compose.yml
ontology.owl
mapping.obda
ontop.properties
然后：
docker compose up -d
最终暴露一个：
SPARQL Endpoint
给其他系统访问。
二十四、Ontop + Protégé
Ontop 还有一个很方便的东西：
Ontop Protégé Plugin。
也就是说：
Protégé
+
Ontop
可以直接结合起来。
你可以在 Protégé 里：
设计 Ontology
编写 Mapping
连接数据库
执行 SPARQL
然后看查询结果。
这对于学习 Ontology 非常方便。
官方 GitHub Release 也提供 macOS、Windows 和 Linux 的 Protégé Bundle。
二十五、Ontop 不是什么？
理解一个项目最好的方式，有时候是先知道：
它不是什么。
Ontop 不是：
Neo4j
它不会要求你把全部数据搬进 Graph Database。
Ontop 不是：
Vector Database
它主要不是做 Embedding Search。
Ontop 也不是：
LLM
它不会帮你聊天。
它真正负责的是：
Semantic Layer
+
Query Translation
二十六、Ontop 和 Neo4j 的区别
可以简单对比：
| 能力 | Ontop | Neo4j |
|---|---|---|
| 数据存储 | 原数据库 | 图数据库 |
| 是否搬数据 | 不一定 | 通常需要 |
| Query | SPARQL | Cypher |
| 数据模型 | RDF / Ontology | Property Graph |
| 实时同步 | 直接查询源库 | 通常需要同步 |
| Ontology | 原生方向 | 需要额外设计 |
| 企业关系库集成 | 强 | 需要数据导入 |
所以：
Neo4j 更像：
真正的 Graph Database
Ontop 更像：
数据库上方的 Virtual Graph Layer
二十七、Ontop 最大优势
我觉得有三个。
第一：不用搬数据
这是最大的优势。
Business DB
↓
直接查询
不存在：
复制
同步
一致性
这些额外问题。
第二：数据实时
数据库发生：
UPDATE orders
SET status = 'paid'
下一次 Ontop 查询：
理论上就可以直接看到最新状态。
因为它查询的是源数据库。
第三：语义层解耦
底层：
tbl_order_2026
user_base_v3
sku_master_info
上层：
Order
User
Product
这对 Agent 特别重要。
因为 AI 更容易理解：
Customer purchases Product
而不是：
customer_id JOIN sku_order_relation
二十八、Ontop 的缺点也很明显
当然，它并不是万能的。
1. Mapping 成本
真正难的部分：
Database Schema
↓
Ontology
如何建立 Mapping。
大型企业可能需要大量人工设计。
2. 复杂 SQL 性能
SPARQL：
Graph Traversal
最终可能被翻译成：
大量 JOIN
如果数据库设计不合理，SQL 性能可能会变差。
3. 依赖 Ontology 质量
Ontology 如果设计得不好：
语义层
本身就可能变成新的技术债务。
二十九、LLM 可能解决 Ontop 最大的问题
这也是我现在非常关注的方向。
Ontop 最大的问题：
Mapping 太麻烦。
但是 LLM 出现之后，可以尝试：
Database Schema
↓
LLM
↓
理解表和字段
↓
生成 Ontology
↓
生成 Mapping
↓
人工审核
↓
Ontop
例如：
数据库：
t_customer
customer_name
enterprise_id
LLM 自动理解：
Customer
Customer.name
Customer belongsTo Enterprise
然后生成：
R2RML Mapping
这样 Ontology 工程的成本就可能大幅下降。
三十、Ontop + LLM 可能形成新的 Data Agent
完整路线：
用户
|
↓
LLM
|
↓
Semantic Understanding
|
↓
SPARQL
|
↓
Ontop
|
Mapping
|
↓
---------------------
| | |
MySQL Oracle PostgreSQL
| | |
---------------------
|
Enterprise Data
最终：
用户可以直接问：
今年购买 AI 服务超过 10 万元，
但最近 30 天没有续费的客户有哪些？
LLM 不需要知道全部数据库字段。
它只需要理解：
Customer
Purchase
AI Service
Renewal
Ontop 负责：
Semantic
↓
Physical Database
转换。
三十一、Ontology 在 AI 时代重新有价值
过去大家觉得 Ontology 很学术。
因为：
OWL
RDF
SPARQL
学习成本很高。
但是 AI Agent 时代出现一个新问题：
AI 到底应该怎样理解企业的业务世界？
直接给它：
5000 张表
很难。
直接给它：
100 万个 Chunk
也不够。
我们真正需要的可能是：
Customer
Order
Contract
Product
Supplier
这样的：
Business Semantic Layer。
Ontology 恰好就是干这个的。
三十二、我怎么看 Ontop
如果只把 Ontop 看成：
一个 SPARQL 转 SQL 工具
其实有点低估它。
我更愿意把它理解成：
关系数据库和 AI 之间的一层语义操作系统。
下面是：
MySQL
PostgreSQL
Oracle
上面是：
Agent
GraphRAG
LLM
中间：
Ontology
+
Ontop
于是：
AI Agent
↓
Ontology
↓
Ontop
↓
Business Data
这条路线，我觉得未来在企业 AI 里面会越来越有价值。
三十三、总结
一句话总结 Ontop：
Ontop 让关系数据库无需迁移数据，就可以通过 Ontology 和 Mapping 被虚拟成知识图谱，并使用 SPARQL 查询。
它解决的不是：
如何存一张图
而是：
如何让现有数据库拥有知识图谱的语义能力。
传统方式：
Database
↓
ETL
↓
Knowledge Graph
Ontop：
Database
↓
Virtual Knowledge Graph
未来再结合：
LLM
GraphRAG
AI Agent
可能形成：
Natural Language
↓
LLM
↓
Ontology
↓
SPARQL
↓
Ontop
↓
SQL
↓
Enterprise Database
如果说 Graphiti 更偏：
给 Agent 建立长期、动态的记忆。
那么 Ontop 更偏：
让 Agent 直接理解和访问企业现有的结构化数据。
这两个项目实际上代表了两条非常值得关注的路线：
Graphiti
↓
Agent Memory
Ontop
↓
Agent Data Layer
再往上汇合：
Ontology
↓
Knowledge Graph
↓
Context / Data
↓
AI Agent
这也是我认为 Ontology 在 AI Agent 时代真正值得重新研究的原因。
项目地址
GitHub：
https://github.com/ontop/ontop
官网：
王仕宇 JavaPub
浙公网安备 33010602011771号