Ontop 详解：不搬数据库，也能把 MySQL / PostgreSQL 变成知识图谱

如果企业的数据已经全部存在 MySQL、PostgreSQL、Oracle 里，还需要为了知识图谱重新搬一遍数据吗？

Ontop 给出的答案是：不一定。

GitHub：

https://github.com/ontop/ontop

官网：

https://ontop-vkg.org/

---

一、先说结论：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

官网：

https://ontop-vkg.org/

---

王仕宇 JavaPub

https://javapub.net.cn/