做本体建模时，很容易从创建对象类型开始：供应商、采购订单、物料、仓库……一个个业务概念逐渐进入模型，对象之间的关系也随之增加。

但模型元素越来越多，并不意味着业务问题就能得到清晰表达。

> 例如，在供应链采购场景中，业务人员真正关心的可能只是一个问题：**采购订单分别由哪些供应商承接？**
>

这个问题看起来简单，却需要明确采购订单和供应商分别代表什么、两者之间是什么关系，以及模型最终应该支持怎样的查询。

如果这些需求没有提前梳理清楚，后续的模型设计就容易不断扩展，却难以判断哪些内容是当前真正需要的。

这也是本篇想讨论的重点：

**本体建模如何从具体业务问题出发，把需求、对象类型和对象关系组织起来。**

今天介绍的 qOntology 开源版，提供了建模目标管理能力，可以集中记录业务问题及其相关信息，并将建模目标与本体元素关联起来。

下面结合一个供应链采购与仓储协同示例，看看这一思路如何在 qOntology 中展开。

感兴趣的可以先去项目仓库看看： [https://gitee.com/qiantongtech/qOntology](https://gitee.com/qiantongtech/qOntology)

---

## 一、先明确要解决什么，再决定模型需要包含什么
本体模型可以描述**一个业务领域中的概念、对象及其关系**。

> 以供应链为例，供应商可能涉及组织类别、联系人等信息，采购订单可能关联物料、金额和日期，物料还可能与库存、仓库等业务概念产生联系。
>

这些内容都可能有建模价值，但不一定需要在同一阶段全部展开。

如果一开始就围绕概念不断补充对象和属性，团队可能投入不少时间完善模型，却很难回答一个实际问题：当前这些模型元素究竟要支持什么业务需求？

另一个容易被忽视的问题是**需求的来源**。

业务问题可能来自部门访谈、业务文档，也可能来自日常讨论。

如果需求与模型设计分开记录，后续接手的成员看到对象类型和关系时，就不一定能理解当初为什么这样设计。

因此，可以先把一个具体的业务问题写清楚，再围绕这个问题识别需要表达的对象及其联系。

例如，供应链项目可以先聚焦于：

> **采购订单分别由哪些供应商承接？**
>

围绕这个问题，当前需要重点关注的是采购订单、供应商，以及两者之间的供货责任关系。

付款结算、物流运输等其他内容，可以根据后续业务需求另行梳理。

<img src="https://developer.qcloudimg.com/http-save/yehe-12852146/84ed71b474696982c579b402e7d9f2ad.png" width="1983" title="" crop="0,0,1,1" id="uefdf51ae" class="ne-image">

---

## 二、建模目标是什么？它连接的是业务问题与模型设计
在本体工程中，可以用**能力问题**（Competency Question，简称 CQ）表达模型应该支持回答的业务问题。

它与宽泛的建设目标有所不同。

例如：

> “建立一个供应链本体”说明了项目方向，但没有明确模型需要支持哪些业务认识，而“采购订单分别由哪些供应商承接？”则更具体：问题涉及采购订单与供应商，需要在模型中表达两者之间的供货关系。
>

建模目标的作用，就是将**这类业务问题明确记录下来**，作为后续模型设计的参照。

围绕同一个供应链项目，还可以继续提出其他问题：

+ 指定采购订单采购了哪些物料？
+ 已到货订单对应哪些入库记录？
+ 如何根据供应商查询其承接的采购订单？

这些问题关注的业务范围并不相同，可以分别记录、明确优先级，再逐步展开模型设计。

这种方式并不是要求一次性列出所有可能的问题，而是先明确当前最需要解决的场景。

目标越具体，团队就越容易讨论哪些对象和关系需要纳入模型，哪些内容可以留到后续阶段。

<img src="https://developer.qcloudimg.com/http-save/yehe-12852146/331d7ca415e7f0770af024764c69d616.png" width="1983" title="" crop="0,0,1,1" id="udd26a6fe" class="ne-image">

---

## 三、在 qOntology 中，如何把业务诉求记录下来？
明确建模目标的意义之后，还需要解决一个实际问题：

> 这些目标应该记录在哪里？后续如何让团队成员找到对应的需求背景？
>

qOntology 开源版提供了“**建模目标**”页面，用于集中管理当前项目版本中的业务问题。

目标列表可以呈现**目标问题、问题来源、业务场景和优先级**等信息，帮助团队先了解需求背景，再查看具体目标。

<img src="https://developer.qcloudimg.com/http-save/yehe-12852146/04ddba4e93563b99aa65fa5ec283dace.png" width="1920" title="" crop="0,0,1,1" id="ue12fecb5" class="ne-image">

### 目标问题要具体，问题来源也要保留
目标问题最好写成一句能够直接理解的业务问句。

相比“做好供应商管理”，“采购订单分别由哪些供应商承接？”明确了需要关注的业务对象及其联系，更容易进一步转化为模型设计要求。

问题来源则用于**保留需求的来处**。

> 例如，这个问题由采购部门提出，当团队需要进一步确认业务口径时，可以回到相应部门或资料核实，而不必仅凭已有模型推测当初的需求。
>

### 补充场景和优先级，让需求有轻重缓急
同一个问题可能出现在不同业务活动中。

本例中的业务场景是“**订单供货责任追溯**”，意味着团队希望了解每笔采购由谁承担供货任务。

明确场景后，建模人员就更容易理解为什么需要建立采购订单与供应商之间的关系。

优先级则用于**表达不同目标的重要程度**，为建模工作的安排提供参照。

先处理当前最关注的问题，再逐步补充其他需求，可以让模型建设更贴近实际业务节奏。

<img src="https://developer.qcloudimg.com/http-save/yehe-12852146/6719e5310480e682991d7a92fc37e95a.png" width="1983" title="" crop="0,0,1,1" id="uc8b6dc5c" class="ne-image">

### 用验收标准说明期望得到什么答案
除了记录问题本身，还需要明确怎样的结果才算满足需求。

在 qOntology 中，可以通过“**验收标准**”字段记录问题期望得到的答案及其范围。

例如，本例可以写成：

> “能够按采购订单查询供应商，并支持按供应商查询其承接的采购订单。”
>

这句话明确了两个查询方向：从采购订单了解对应供应商，也可以从供应商了解其承接的采购订单。

提前写清楚期望结果，有助于业务人员和建模人员形成一致理解，也为后续对象关系的设计提供了依据。

---

## 四、从业务问题到模型元素：对象类型和关系怎么确定？
**记录建模目标**只是第一步。

接下来，需要把**业务问题转化为模型中可以表达的对象与关系**。

qOntology 在目标详情中提供对象类型与对象类型关系等相关页面，也支持从模型元素侧关联建模目标，使业务诉求与模型设计能够建立对应关系。

### 先识别对象类型
回到“采购订单分别由哪些供应商承接？”这个问题，首先需要识别两个关键对象类型：

+ **采购订单：** 表示采购业务中的单据。
+ **供应商：** 表示承担供货任务的组织。

两者的业务角色不同，需要分别明确其定义。

示例模型将供应商放在“组织”类型之下，同时保留采购订单等业务单据类型。

这里不需要为了一个问题就把整条供应链中的所有概念全部展开。

当前重点是订单与供应商，其他类型可以在对应业务目标中继续完善。

<img src="https://developer.qcloudimg.com/http-save/yehe-12852146/ac0abe8426073624c27996de53c94a39.png" width="1920" title="" crop="0,0,1,1" id="u458e60ea" class="ne-image">

### 再用对象关系表达业务联系
识别对象之后，还需要说明它们之间究竟是什么关系。

> 在本例中，通过“指定供应商”关系连接采购订单与供应商，该关系以采购订单为起点、供应商为终点，表达订单指定由哪个供应商承担供货任务。
>

同时，关系还设置了**反向名称**“承接采购订单”。

从供应商一侧阅读时，这个名称能够表达同一项业务联系，也与建模目标中“按供应商查询其承接的采购订单”的要求相对应。

**关系名称并不是简单的标签。**

它需要尽可能准确地表达业务语义，避免团队成员看到模型结构后，还需要重新猜测对象之间的联系。

<img src="https://developer.qcloudimg.com/http-save/yehe-12852146/104b7a1c047c41a87ac02b631261f6de.png" width="1920" title="" crop="0,0,1,1" id="u9dd5c730" class="ne-image">

### 让模型元素能够回到对应的业务目标
如果建模目标只停留在需求列表中，而对象类型和对象关系完全独立维护，团队仍然需要在不同信息之间来回查找。

qOntology 支持将**建模目标与对象类型、对象类型关系等模型元素关联起来**。

这样，查看目标时可以了解它涉及的模型元素；从模型元素回看关联目标，也可以理解这些设计服务于哪些业务问题。

当业务需求发生变化时，团队可以结合已有对应关系讨论：是目标问题的范围需要调整，还是对象类型、对象关系需要补充。

这种关联能够帮助团队保留模型设计的业务背景，但不能替代业务口径确认、模型评审或实际数据验证。

<img src="https://developer.qcloudimg.com/http-save/yehe-12852146/45a3ca308a6fca1f61db9c5c4f8a1a99.png" width="1983" title="" crop="0,0,1,1" id="u0d556a18" class="ne-image">

---

## 五、用一个供应链示例，把建模目标串起来
前面介绍了建模目标管理涉及的主要信息。

接下来，继续使用“供应链采购与仓储协同本体”中的仿真业务实例，将这些内容串联起来。

这里使用的是示例数据，用于说明模型如何表达业务含义，并不代表已经接入真实企业业务系统。

### 从一条明确的问题开始
在建模目标列表中，找到“采购订单分别由哪些供应商承接？”这一目标。

该目标的来源是采购部门，业务场景为订单供货责任追溯，优先级为高。验收标准则明确要求支持从订单查询供应商，也支持从供应商查询其承接的订单。

通过这些信息，业务人员与建模人员可以围绕同一项需求展开讨论，而不必仅凭“供应商管理”这样的宽泛名称理解建模范围。

### 把问题落实到对象和关系
围绕这条目标，当前重点关注采购订单和供应商两个对象类型，以及“指定供应商”这一关系。

采购订单承担业务单据的角色，供应商承担供货主体的角色，关系则表达订单与供货方之间的业务联系。

反向名称“承接采购订单”进一步明确了从供应商侧阅读时的含义。

### 用仿真实例理解模型表达的业务含义
在示例数据中，可以将订单与供应商的对应关系概括为：

+ 示例订单一指定供应商 A。
+ 示例订单二指定供应商 B。
+ 从供应商 A 一侧查看，可以了解其承接的示例订单一。

通过这样的对应关系，团队能够更直观地理解对象类型与关系各自表达什么。

<img src="https://developer.qcloudimg.com/http-save/yehe-12852146/12f89a1c7429d901aa0b44510fba6bda.png" width="1983" title="" crop="0,0,1,1" id="u616c827f" class="ne-image">

需要明确的是，这里的仿真实例用于说明目标期望表达的内容。

模型设计明确了订单、供应商及其联系，但真实业务数据的接入与应用查询，还需要结合后续的数据和应用系统开展，不能仅凭示例模型就认定实际业务链路已经打通。

本例关注的是**订单供货责任**，如果后续还需要回答“采购订单采购了哪些物料”或“已到货订单对应哪些入库记录”，可以将它们分别整理为新的建模目标，再逐步扩展相关对象和关系。

---

## 六、这个开源项目值得关注的地方，以及使用时需要考虑什么
从这个案例可以看到，qOntology 建模目标管理关注的不只是记录一条业务问题，而是将目标问题、来源、场景、优先级和验收标准组织起来，并与相关本体元素建立联系。

对参与本体建设的团队来说，这种方式有几个值得关注的地方。

**第一，让建模需求更加具体。** 

与笼统的建设目标相比，明确的业务问题更容易讨论，也更容易判断当前阶段应该表达哪些对象和关系。

**第二，让模型设计保留业务背景。** 

通过建模目标与模型元素的关联，团队能够回看设计服务于什么需求，减少后来接手的成员仅凭模型结构猜测设计意图的情况。

**第三，让模型扩展有明确的业务线索。** 

当新需求出现时，可以先判断它是否对应新的业务问题，再决定是否需要补充对象类型或关系，而不是不断扩充模型却难以说明建设重点。

当然，这种方法也有适用边界。

> 建模目标管理不能代替业务调研。
>

目标是否准确，仍然取决于业务人员能否说清楚实际需求，以及建模人员是否正确理解了业务语义。

同样，建立了对象类型和关系，也不意味着真实业务数据已经接入，更不意味着应用查询已经可以直接使用。

**数据接入、数据映射、应用开发和实际验证**仍然需要结合项目情况开展。

对于准备使用 qOntology 的团队，可以先选择一个具体业务问题，例如“采购订单分别由哪些供应商承接？”，明确期望答案和验收范围，再识别相关对象类型与关系。

通过一个小场景逐步验证建模方法，比一开始就追求覆盖整个业务领域更容易控制范围。

---

## 七、想体验 qOntology，可以从一个业务问题开始
如果你正在了解本体建模，或者希望尝试将业务需求与模型设计关联起来，可以从 qOntology 开源版开始进一步了解。

**项目仓库**：

[https://gitee.com/qiantongtech/qOntology](https://gitee.com/qiantongtech/qOntology)

建议先围绕一个具体业务场景整理需要回答的问题，再根据项目文档了解建模目标、对象类型和对象关系的相关操作。

实际界面、可用功能及具体操作方式，以当前开源版本为准。

本体建模真正需要关注的，不只是模型中包含多少对象和关系，还包括这些结构是否对应明确的业务需求，团队能否理解它们为什么存在，以及后续能否围绕新的问题继续维护和扩展。

> 从一个具体问题开始，把期望答案写清楚，再逐步落实到模型元素，是一种值得尝试的建模思路。
>

对于 qOntology 来说，建模目标管理提供了连接业务诉求与本体设计的一种实践方式。

是否适合自己的项目，还需要结合实际业务场景进一步验证。


做本体建模时，很容易从创建对象类型开始：供应商、采购订单、物料、仓库……一个个业务概念逐渐进入模型，对象之间的关系也随之增加。

qOntology开源版本体建模目标管理：从业务问题到对象关系的实践路径

文章主张本体建模应从具体业务问题出发，而非先堆砌对象。qOntology开源版提供“建模目标”管理，用能力问题记录目标、来源、场景、优先级和验收标准，并与对象类型、关系关联，使模型设计有业务依据。

数据库

本体建模应从具体业务问题出发，而非盲目扩展对象类型。通过“采购订单分别由哪些供应商承接？”这一能力问题（CQ），明确核心对象（采购订单、供应商）及其关系（指定供应商），确保模型设计有据可依。qOntology开源版支持集中管理建模目标，关联需求与本体元素，助力团队聚焦业务重点，实现高效、可追溯的模型构建。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

qOntology开源版本体建模目标管理：从业务问题到对象关系的实践路径-腾讯云开发者社区-腾讯云

qOntology开源版本体建模目标管理：从业务问题到对象关系的实践路径

qOntology开源版本体建模目标管理：从业务问题到对象关系的实践路径

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐