本体工程手记01｜一个追溯问题为什么不能只靠一条SQL
作者：北海 奇点智能FDE&数据架构师
一台成品在终检环节出现振动异常。
质量工程师问了一个看起来很简单的问题：这台异常产品，实际使用了哪些物料批次？
做过数据平台或跨系统集成的人，第一反应大概相同：查QMS找到检验记录，查MES找到工单，再到 ERP 关联物料批次，最后写一条跨系统SQL。
但真正动手以后，问题很快就变了。
QMS 里的产品编码指的是被检验的序列化成品，MES 里的产品编码可能指工单上的产品型号，ERP 里的物料批次记录了领料，却不一定等于生产现场的实际消耗。PLM 还有多个产品版本和工艺版本，设备系统则用另一套设备编号记录当时的状态。
每个系统都有数据，每张表也都能查询。但这些数据还不能自动拼成一条身份一致、时间正确、证据可追溯的制造故事。
SQL能连接字段，却不能替我们判断字段背后究竟指向哪个现实对象。这正是本系列要讨论的问题。
1 最危险的答案：查到了，但查错了
假设我们根据产品编码、工单号和物料批次号完成了关联，查询返回三条物料记录。结果结构完整，字段齐全，执行时间也很快，它仍然可能是错的。
至少有六件事需要先回答：
记录、零件和检测设备都摆在桌面上，并不等于它们已经证明了同一个制造事实。如果这些问题没有答案，SQL 只是把不确定性藏进了连接条件。
过去做数据架构和数字化交付时，我反复遇到一种错觉：系统通了、表也汇了，就默认业务已经打通。到了验收现场才发现，真正耗时的不是把数据搬过来，而是不同部门对客户、订单、产品、完成、有效这些词的理解并不一致。
制造追溯把这个问题放大了。它不只关心一张当前快照，还要回答：谁在什么时候，按照哪个版本，用什么设备和物料，实际做了什么，并留下了什么证据。
2 先把业务真正要问什么固定下来
在本体工程中，用来定义模型范围并检验模型是否可用的问题，专业上叫能力问题（Competency Question，简称 CQ）。为了让非技术读者更容易理解，本系列优先叫它业务验收问题。
M厂的第一个业务验收问题可以写成：对于终检异常的成品实例M-FG-00017，返回生产时实际消耗的物料批次、对应工序执行、发生时间和来源记录；不得用计划用料替代实际消耗。这句话比“建设质量追溯本体”小得多，却更接近一个能够交付和验收的项目。
它明确了六件事：
本体先回答什么才算回答了业务问题，再决定应该有哪些类。
这个业务验收问题将贯穿本系列全部十三篇文章。每一篇都在回答同一件事：为了让这个问题得到稳定、可信、可验收的答案，我们还需要补上什么。
3 一个问题要穿过完整的工程链
要稳定回答上面的追溯问题，至少要完成这样一条链：
业务问题 → 概念 → 本体论判断 → 模型 → 源数据 → 身份 → 约束与推理 → 查询 → 业务动作 → 验收与版本
先识别产品实例、物料批次、工序执行、设备和检验事件等概念。再区分产品型号与产品实例、工艺步骤与一次真实工序执行、计划用料与实际消耗。然后定义使用了什么、由什么产生、什么设备参与、什么检验对应什么产品等关系，把 ERP、MES、QMS、PLM 和设备系统的字段映射进来。
数据进入以后，还要解决跨系统身份：两个相似编码究竟是同一对象、不同版本，还是完全不同的对象？接着检查数据是否满足最基本的可用条件。一次工序执行如果缺少产品、时间或参与设备，就不应该悄悄进入追溯结果。
最后，查询返回的答案必须带着来源和证据路径进入追溯应用。模型、映射或规则发生变化后，还要重跑原来的业务问题，确认答案没有被破坏。
这才是本体工程，它包含本体建模，但远不止本体建模。
4本体不会替代SQL，也不会替代数据治理
这里需要提前划清一条边界。
本体并不用来消灭数据库、接口、SQL、主数据或数据质量工作。SQL 仍然负责高效查询，接口仍然负责数据交换，主数据仍然负责关键编码治理，数据质量规则仍然负责发现缺失、错误和异常。
本体增加的是另一层能力：把跨系统共享的概念、关系、身份、时间和约束显式表达出来，让不同系统、不同角色以及后续的AI能够在同一种语义下使用数据。
如果问题只是某个接口没通、某列数据缺失，应该先修接口、补数据。如果问题只是流程无人负责，应该先补治理责任。只有当同一业务对象在多个系统中长期存在稳定的语义分歧，而且这种分歧需要被复用、解释、验证或供人机共同使用时，本体才可能成为必要组成部分。
所以本体工程手记系列的第一篇，不会教你怎样“画”本体。它先回答一个更重要的问题：你的项目究竟需不需要本体？
本体项目不是建一张概念图。它是让关键业务问题从定义到数据、查询和验收全程不失真。
下期预告
先别急着立项。下一篇我们回到 M 厂的追溯会，判断问题究竟卡在数据、流程，还是共享语义。
案例声明：本文中的M厂是用于教学的离散制造合成案例，不对应任何真实客户；人物、系统、编码、数据和事件均为模拟设定。