本体、分类法、数据库模式与知识图谱的区别

本体、分类法、数据库模式与知识图谱的区别

假设你参加一次供应链数据评审，桌面上放着四份交付物。

第一份是 EF Core 迁移：它创建了 Organizations、Products 和 Contracts 表，还配置了主键、外键与索引。

第二份是产品分类树：最上层是“工业部件”，下面有“控制器”，再下面是“24V 控制器”。每个分类还有编码和中英文名称。

第三份定义了“组织”“供应商”“客户”“制造商”“供应产品”等概念和关系，并说明供应商、客户和制造商都可以是组织承担的业务角色。

第四份装着具体事实：ERP 的 V-1048、CRM 的 C-8821 和 PLM 的 M-77 都映射到组织 ORG-00042；这家组织供应产品 CTRL-24V-A，合同 CT-208 只在华东工厂和指定期限内有效。系统可以沿这些关系查询，并返回数据来源。

有人把四份交付物都叫“本体”，也有人把它们都叫“知识图谱”。两个叫法都把重要边界抹掉了。

这四份东西可以一起工作，但它们回答的不是同一个问题。

先分清四种问题

为了避免术语绕口，可以先把四类交付物翻译成四句白话：

• 数据库模式关心“数据按什么结构存进去”；
• 分类法关心“业务术语按什么层级整理”；
• 本体关心“这些概念和关系在多个系统中表示什么”；
• 知识图谱关心“现在有哪些实体和事实可以连接、查询与追溯”。

这不是四选一的技术排行榜，也不是从“低级”到“高级”的升级路线。一个生产系统完全可能同时需要四者。真正要避免的是让其中一种承担另外三种的职责。

数据库模式：先保证数据能正确保存

数据库模式是描述数据在数据库中的组织方式。对常见的关系数据库来说，工程人员最熟悉的内容包括表、列、数据类型、主键、外键、唯一约束和索引。

在 .NET 应用里，EF Core 使用元数据模型描述实体类型如何映射到底层数据库，再通过约定、数据注解或 Fluent API 调整映射。迁移可以把这些变化落实到数据库结构中。

例如，采购服务可以规定：

• Organizations.Id 是主键；
• Contracts.OrganizationId 必须引用已有组织；
• Contracts.ContractNumber 不能重复；
• ValidTo 使用日期类型；
• 经常查询的外键需要索引。

这些规则很重要。它们能阻止孤立合同、重复合同号或错误类型的数据进入事务系统。

但它们不会自动回答：ERP 的 Supplier、CRM 的 Customer 和 PLM 的 Manufacturer 是否表达同一种业务角色；三个不同主键是否指向同一家现实企业；“供应商”与“制造商”之间是什么关系。

原因并不是数据库能力不足，而是数据库模式的首要职责是存储结构与数据完整性。跨系统词义需要另外定义。

还要注意一个容易混淆的用词。在 PostgreSQL、SQL Server 等产品中，schema 也常指数据库内用于组织表、视图和函数等对象的命名空间。本文说“数据库模式”时采用更宽的工程语境，指与存储有关的整体结构；具体产品中的 schema 命名空间只是其中一个概念。讨论时最好说清自己指哪一种。

分类法：把术语放进可维护的层级

分类法主要组织受控术语及其上下位关系。所谓受控，是指团队不再随意写“控制模块”“控制器”“控制装置”，而是维护一组经过确认的名称、编码和层级。

例如，PLM 可以维护这样的产品分类：

工业部件
└── 控制器
    ├── 24V 控制器
    └── 48V 控制器

它适合回答：一个产品属于哪个分类；某个分类有哪些更具体的子分类；旧称和首选名称如何对应；导航菜单应该怎样展开。

W3C 的简单知识组织系统（Simple Knowledge Organization System，SKOS）可以用机器可读方式表示分类法、叙词表、分类方案等知识组织系统。这里必须把两件事分开：分类法是一种组织知识的方式，SKOS 是可以表示它的标准词汇；分类法并不等于 SKOS。

同样，“24V 控制器”位于“控制器”下面，也不自动等于 C# 中的类继承，更不自动得到本体中的子类语义。分类树表达的是业务概念的上下位组织。是否还要声明更严格的逻辑关系，需要团队另外建模。

分类法通常比本体窄。它很擅长管理名称、代码和层级，但不会仅凭一棵产品树说明“哪家组织在什么合同和时间范围内向哪个地点供应该产品”。后一类问题涉及多种实体、角色和关系。

本体：定义跨系统共享的含义

本体（Ontology）描述一个领域中的概念、关系和公理（Axiom）。这里的公理，是写进模型并供机器解释的明确陈述。W3C 的 OWL 2 概览把本体概括为通常覆盖特定领域、由一组用户共享的形式化词汇；术语的定义通过它们与其他术语的关系来说明。OWL 2 是表达本体的一种标准语言，但“本体”这个概念不等于某个文件扩展名。

回到开头的例子，本体关心的不是 Organizations 表叫什么，而是这些术语表示什么：

• “组织”表示现实中的企业或机构主体；
• “供应商”“客户”“制造商”表示组织在不同业务中的角色；
• “供应关系”连接组织、产品、地点和合同；
• “有效期”说明一条关系在什么时间范围内成立。

这样的定义允许 ERP 保留 Supplier，CRM 保留 Customer，PLM 保留 Manufacturer。各系统不用为了共享语义而强行改成同一个 C# 类，只需要明确本地概念如何映射到共同定义。

本体也不只是类名清单或类继承图。只有 Organization、Supplier、Product 三个方框，却没有关系的方向、适用条件和明确含义，最多是一张概念草图。是否已经成为可计算的本体，要看机器能否依据确定的语义处理其中的定义和公理。

反过来，本体也不必包含大量业务实例。团队可以先发布“组织、角色、产品和供应关系”的定义，而不把 ORG-00042 或 CT-208 写进去。本体主要提供共享语义，具体事实可以由知识图谱承载。

知识图谱：连接并使用具体事实

对于“知识图谱（Knowledge graph）”，本文不引用 W3C 的规范定义，不同研究和产品对范围的强调并不完全相同。因此，本系列采用一个明确的工程工作定义：

知识图谱是以图结构组织实体、关系和相关语义，并围绕这些数据提供查询、追溯、治理或推理能力的数据产品。

这一定义服务于本系列，不冒充行业唯一答案。这里所说的上下文，可以是事实的来源、适用时间或所属业务范围。

在供应链案例中，知识图谱可以装入这些事实：

• ORG-00042 在 ERP 中对应 V-1048，在 CRM 中对应 C-8821；
• ORG-00042 承担供应商和制造商角色；
• 它供应 CTRL-24V-A；
• 合同 CT-208 适用于华东工厂，并带有有效期与来源。

应用可以沿这些关系回答：“给华东工厂供应 24V 控制器的组织有哪些？依据哪份合同？数据来自哪里？”

知识图谱可以复用本体中的概念，也可以复用分类法中的产品层级，但三者不是同义词。本体偏向定义，知识图谱偏向事实及其使用；分类法则聚焦术语组织。

还要区分 RDF 图（RDF graph）与知识图谱。W3C 对 RDF 图的定义很精确：一组 RDF 三元组就是一个 RDF 图。一个 RDF 图可能只包含几条测试数据，并不自动具备稳定身份、来源治理或知识服务，所以不能仅凭“保存成 RDF”就宣称已经建成知识图谱。反过来，知识图谱也不必一律使用 RDF；其他图模型同样可以承载某些知识图谱实现。不同图模型的差异会在后续互操作专题展开。

同一批事实，四种不同交付物

把开头的供应链材料放到一张表里，边界会更清楚：

交付物	主要回答的问题	典型内容	不会自动提供
数据库模式	数据怎样保存并保持结构完整	表、列、键、约束、索引、映射	跨系统共享词义
分类法	术语怎样命名、分组和分层	分类编码、首选名称、别名、上下位概念	多实体关系与复杂公理
本体	领域概念和关系表示什么	类、属性、关系、公理、本地术语到共同定义的映射	完整业务实例和事务处理
知识图谱	现有哪些实体与事实可连接和使用	实体、关系、来源、时间、查询与服务	正确语义和数据质量的自动保证

最后一列尤其重要。

数据库里出现外键，不等于系统已经共享词义；分类树很深，不等于它已经表达复杂本体；本体文件存在，不等于业务实例已经接入；数据装进图数据库，也不等于身份、来源和质量问题已经解决。

在一个合理的组合中，SQL 数据库继续承担订单与合同事务；产品分类法管理产品代码和上下位层级；本体定义组织、角色、产品、地点与合同的共同语义；知识图谱汇集经过映射的实例事实，供查询和追溯使用。

四者不是互相淘汰，而是各自承担明确责任。

四问判断卡

面对一份数据资产，可以按下面的顺序判断它的主要性质：

1. 它首先约束数据如何保存吗？ 如果核心是表、字段、键、约束、索引或对象映射，主要交付物是数据库模式。
2. 它首先整理受控名称和层级吗？ 如果核心是分类编码、首选名称、别名、上位和下位概念，主要交付物是分类法。
3. 它首先定义跨系统概念和关系的含义吗？ 如果核心是共享概念、关系、公理和本地术语到共同定义的映射，主要交付物是本体。
4. 它首先连接具体实体和事实供查询使用吗？ 如果核心是实例、关系、来源、时间与围绕图的服务，主要交付物是知识图谱。

这里判断的是“主要职责”，不是要求每份文件只能属于一个盒子。例如，一个知识图谱可以同时引用本体和分类法；一个 .NET 接入服务也会同时读取数据库模式和本体映射。

如果一份仓库或服务同时包含多类内容，不要强行给整个项目贴一个标签。先按可独立维护的产物拆开：EF Core 模型和迁移属于数据库模式；产品类别文件属于分类法；本地字段到共同概念的映射属于语义映射；接入后生成的组织、产品和合同事实属于知识图谱数据。判断单位越具体，责任边界越清楚。

如果团队仍然争论名称，可以暂时不问“它叫什么”，先要求每位参与者写出两句话：这份交付物必须回答什么问题；它明确不负责什么问题。边界往往会比术语先清楚。

读者自测

某制造企业准备整合四份资产：

A. EF Core 模型规定 Products 表的主键、产品编码唯一约束和分类外键。

B. PLM 维护“工业部件 > 控制器 > 24V 控制器”的层级，并给每个分类配置编码、中文名称和英文名称。

C. 共享模型定义“组织可以承担供应商或制造商角色”“供应关系连接组织、产品、地点和合同”“供应关系具有有效期”。

D. 数据服务保存 ORG-00042、CTRL-24V-A、CT-208 和华东工厂之间的具体关系，并能返回每条关系的来源。

请先不要往下看。为 A 至 D 分别写出：主要属于哪类交付物；它回答什么问题；它不能单独回答什么问题。

参考判断如下：

• A 主要是数据库模式。它保证产品数据按既定结构保存，但不能单独解释不同系统中的产品编码是否具有相同含义。
• B 主要是分类法。它管理产品术语和层级，但不能单独表达供应商、合同、地点与有效期之间的完整关系。
• C 主要是本体。它定义共享概念和关系，但没有列出当前有哪些真实组织和合同实例。
• D 主要是知识图谱。它连接具体事实并支持追溯，但仍需要本体、分类法、映射规则和质量流程来保证含义与数据可信度。

可以用 12 个检查项验收答案：A 至 D 的主要分类各 1 项，每项的“能做什么”各 1 项，“不能单独做什么”各 1 项。四个分类必须全部正确，并且八条边界说明都要与题目中的具体内容对应，才算通过。仅仅记住四个名词，还不算完成本篇的学习结果。

生产注意事项

四类资产组合后，最容易被低估的风险是版本不同步。

数据库增加了 ValidityEnd 列，不代表本体已经定义有效期；分类法合并了两个产品类别，不代表历史知识图谱中的实例已经迁移；本体修改了关系含义，也不能直接用一次数据库迁移覆盖所有数据。

生产中应分别记录数据库迁移版本、分类法版本、本体版本和知识图谱数据版本，再用一份兼容性清单明确允许的版本组合与迁移顺序。部署前至少检查清单是否包含本次四个版本，并用合成数据演练一次迁移和回滚。不要假设四类资产能够无损地相互生成。

负责人也不完全相同。数据库模式通常由应用与数据团队维护；分类法需要业务专家参与；本体需要业务、数据和语义建模人员共同评审；知识图谱还要承担数据接入、来源、权限、查询性能和运行监控。职责没有落到人，术语定义得再漂亮也不会长期有效。