上一篇说明了企业本体怎样让 Data Agent 按企业定义理解业务。接下来需要先分清：本体、知识图谱和数据模型各自负责什么，哪些能力可以组合，哪些概念不能混用。本体、知识图谱和数据模型经常描述同一批客户、订单和商品，但它们承担的任务不同：数据模型规定数据怎样组织、存储和计算；知识图谱连接具体对象与事实；本体定义这些对象、关系和规则在业务上代表什么。三者不是互相替代的技术路线，而是分别解决执行、事实连接和共享语义问题。
| 比较维度 | 数据模型 | 知识图谱 | 本体 |
|---|---|---|---|
| 主要回答 | 数据怎样组织、关联和落库？ | 哪些具体对象和事实彼此相连？ | 业务概念、关系和规则怎样解释？ |
| 主要内容 | 实体、属性、键、表、列、数据类型 | 实体实例、节点、边、属性或三元组 | 类、属性、关系、术语、规则和约束 |
| 典型产物 | 概念模型、逻辑模型、物理模型、Schema、DDL | 实例图、RDF 数据、属性图、关系查询接口 | 本体词汇、关系定义、业务规则与数据映射 |
| 运行时作用 | 存储、计算、事务和查询的基础 | 实体关联、多跳查询和跨源上下文 | 术语消歧、业务解释和语义边界 |
| 更适合解决 | 系统和数仓怎样可靠运行 | 事实怎样跨系统连接 | AI 怎样按企业口径理解业务 |
实际系统中会出现交叉。概念数据模型也会表达部分业务规则，成熟知识图谱通常包含模式层或本体层，本体也需要数据映射才能运行。判断一项能力属于哪一类，关键不是看它是否画了节点和连线，而是看它主要解决什么问题。
业务人员问：
上个月高价值客户买了哪些商品？
这个问题看似简单，实际包含三类不同任务。
首先，系统要知道“高价值客户”“买了”和“上个月”分别是什么意思。“高价值”按收入还是利润判断？“买了”指下单、支付还是签收？这属于本体和业务规则要回答的问题。
其次，系统要找到具体的客户、订单、支付事件和商品，并沿着正确关系把事实连接起来。这是知识图谱或其他关系组织能力可以承担的任务。
最后，系统还要把这些对象和关系落到客户表、订单表、支付表和商品表中，执行筛选、连接和汇总。这依赖数据模型和查询系统。
如果只有数据模型，系统知道表怎样连接，却不一定知道“购买”应使用哪个业务事件。如果只有本体，系统拥有清楚定义，却可能还没有真实数据和执行路径。如果只有知识图谱，系统能够沿关系找到事实，也仍然需要明确关系代表什么、数据怎样更新和计算。
数据模型覆盖从业务概念到数据库实现的多个层次。逻辑模型描述实体、属性、键和关系；物理模型进一步落实为表、列、索引和存储结构。
在客户与订单场景中，一个关系型数据模型可能包含：
customer(customer_id, customer_level, ...) orders(order_id, customer_id, status, created_at, paid_at, ...) order_item(order_id, sku_id, quantity, ...) product(sku_id, product_name, category_id, ...)
这套结构可以明确订单如何关联客户、订单明细如何关联商品，也可以用主键、外键、唯一性和数据类型保证基础完整性。
但当业务人员说“上个月这个客户买了什么”，数据模型通常不会自动说明“买了”应该绑定创建时间、付款时间还是签收时间。它提供的是可执行结构，具体业务含义还要由术语、规则或本体补充。
知识图谱主要组织具体实体和事实关系。放到同一个订单场景中，可以表达为：
客户 C001 ─提交→ 订单 O1001 订单 O1001 ─包含→ 商品 SKU-88 订单 O1001 ─发生于→ 门店 S12 订单 O1001 ─支付于→ 2026-08-01 10:32
这里出现的是具体客户、具体订单和具体商品。系统可以沿关系回答“C001 买过哪些商品”“这些订单发生在哪些门店”“哪些客户购买了同一商品”等问题。
知识图谱可以物化在 RDF 三元组库或属性图数据库中，也可以通过映射动态访问关系数据库。图数据库是一种适合节点和关系查询的存储技术，知识图谱是一种组织和使用知识的方式，二者不能直接画等号。
关系连起来之后，系统仍需知道“提交”“支付”“购买”分别代表什么，允许连接哪些对象，时间和状态怎样解释。这部分依赖图谱采用的模式、本体和校验规则。
本体关注共享语义。它不只列出“客户、订单、商品”这些名词，还要说明：
有了这些定义，系统才能判断两个同名字段是否代表同一类对象，也能识别“已经下单”和“已经购买”在当前企业口径下是否成立。
本体可以用 OWL 等标准化语言表达，也可以使用轻量元数据模型、领域 DSL 或配置规则。是否采用图数据库，应由多跳关系、图算法、跨源实体关联、性能和维护成本决定，而不是由“建设本体”这个名称决定。
围绕“上个月高价值客户买了哪些商品”，三者可以这样协作：
这不是固定的三段式产品架构。企业可以不物化知识图谱，直接将本体定义映射到现有关系数据库；也可以在已有知识图谱中增加更严格的本体和数据校验。组合方式取决于问题复杂度和现有资产。
可以从当前最需要解决的问题判断：
更稳妥的方式，是从一个高价值问题倒推需要的语义和数据，而不是先建设一套覆盖全公司的概念体系。现有数据模型和指标资产应尽量复用，只有确实需要的关系才进入知识图谱。
可以把本体看作知识图谱模式和语义规则的重要来源，但二者并不完全等同。本体关注可共享的概念、关系和约束；知识图谱还包含具体实体、事实、来源、更新和查询机制。
两者都会出现客户、订单、商品等业务概念。概念数据模型通常继续走向可实施的逻辑与物理结构；本体更强调概念在不同系统中的一致含义、语义复用和推理边界。实际项目可以复用同一批建模成果。
不一定。如果现有模型已经能稳定回答核心问题，没有跨系统身份、复杂关系和口径歧义，就不必为了技术名词增加新层。只有当现有结构无法表达或治理关键业务含义时，再补相应能力。
数据模型、知识图谱和本体处理的是同一业务世界的不同层面。数据模型让数据可以存储和计算，知识图谱让具体事实可以连接和遍历，本体让这些数据和关系具有一致的业务含义。企业真正需要的不是在三者之间选一个“更先进”的名称，而是判断当前问题缺的是结构、事实连接，还是共享语义。