一家人共同买一辆车，多次试驾属于同一次购车机会，下订和交车又是不同节点。把这些约定讲清楚后，还有一个实际问题。模型里的这次购车机会，怎样在企业已有数据中找出来？
它可能分散在接待记录、试驾活动和订单系统中。订单表里的“客户”指购买方，沟通记录里的“客户”指联系人。即使字段名称相同，直接关联也未必能还原同一次需求。
在 Dataphin 中建设本体所需的业务语义，可以从已有模型、指标和数据资产开始。 规范建模把对象和活动组织成数据模型，指标定义保存统计条件；知识图谱则整理文档中的实体、关系与来源。把这些资产与业务定义逐项对应，才能让同一个问题找到合适的数据和依据。
本文延续上一篇的家庭购车模型，重点说明已有资产能为业务定义提供什么依据。
这里的业务语义包括对象身份、角色、节点条件和指标含义。数据模型与知识图谱分别保存和组织相关依据，团队再沿同一业务定义核对。
想先看产品如何组织模型与数据资产，可以了解 Dataphin。下面沿同一个购车机会，解释业务语义怎样分别对应数据模型和文档知识。
规范建模把业务定义落实到对象、活动与记录
上一章用购车机会关联家庭、参与者、体验活动和订单，回答的是它们在业务上怎样相连。进入数据建设，还要决定每类记录描述什么，以及如何找到彼此。
Dataphin 的规范建模区分业务对象与业务活动。对象描述参与业务的人或事物，活动描述发生的事件、持续的流程或某一时刻的状态。由这些概念模型，可以进一步设计维度逻辑表和事实逻辑表，分别组织对象属性与活动信息。
沿用家庭购车的设计，在家庭购车模型中，首先需要分清家庭客户单元与个人。家庭是本次购买的需求归属，个人可以担任联系人、购车人或用车人。两者各有标识，通过成员及参与角色建立联系。对象之间还要分清“是一种”与“有关联”。例如，会员客户是客户的一种，可以考虑继承客户定义；家庭包含个人，则是不同对象之间的关联。同一个人在本次购买中担任购车人、在另一次购买中担任用车人，角色应随具体购买关系记录。
Dataphin官方通用示例。图例区分普通对象、关联关系与继承关系，帮助检查概念之间怎样连接；图中的地址、用户和员工并非本文汽车模型。
前文的购车过程有持续时间，也有明确节点。完成试驾、订金到账或取消订单，是其中发生的一次变化；“月底仍有多少机会待交付”，则是在一个时点观察状态。把三种含义分开，才有条件解释销售数字的差异。
| 业务活动类型 | 记录的业务含义 | 与购车过程的对应方式 |
| 业务事件 | 某次发生及其时间，通常对应流程的一次状态变化 | 一次试驾完成、订金到账、订单取消或交车完成。关联机会及相关对象，明确事件时间和成立条件 |
| 业务快照 | 某一时点观察到的状态或结果 | 月底各购车机会的状态、门店待交付订单数量。保存观察时点，区分当时状态与后来发生的变化 |
| 业务流程 | 有开始、结束和状态流转的完整过程 | 从需求明确到成交或关闭的购车机会推进；从订单成立到交付或取消的订单履行。记录生命周期及相关节点 |
在业务流程的配置中，Dataphin支持选择关联实体、前序业务流程和流程事件。沿用本例，可以把已经定义的个人、车辆等实体与流程关联，再按业务顺序组织订金到账、取消、交车等事件。如果将购买确认和订单履行分别建成业务流程，且购买确认完成是启动履行的必要条件，就可以把购买确认设为前序业务流程。“下订成立”则是需要进一步核对的节点条件。取消和待交付分支的含义，还应写清节点条件与终止条件。
这里的业务流程服务于数据建模，用来描述过程怎样发生。上一篇的横向流程图由此可以落实为生命周期、事件与状态的定义，为事实记录和统计提供依据；业务中的通知、跟进或交付操作，会在后续行动设计中继续展开。
概念模型确定之后，维度逻辑表进一步组织业务对象的主键和属性，事实逻辑表组织业务活动的记录及计算所需信息。界面中选择了一个实体类型，还需要继续配置来源记录、关联条件和时间字段。
普通维度逻辑表的官方配置示例。字段说明记录属性含义，主键标识具体对象；页面也提供从表或建表语句引入字段的入口。示例中的字段并非汽车销售字段。
以夫妻共同试驾为例，体验事件关联到同一个购车机会，参与者则分别关联到两个人。参与人数可以是两人，完成的体验仍只有一次。模型需要分开保存活动身份与参与者关系，接待人数和体验次数才能各按自己的单位计算。
再看订单。订单标识回答是哪笔交易，机会标识说明属于哪次需求，购买方标识说明实际由谁购买。三者各有用途。若来源系统没有记录机会归属，就要结合接待、活动和订单资料核对；仅按同一客户连接，可能把这个家庭上次购车的试驾与本次订单放到一起。
这一步的交付结果，是业务定义、模型分类和真实记录能够逐项对应。 查看一次体验，能分清预约与实际完成；核对一笔订单，能找到所属机会和购买方；回看月末状态，也能区分已经取消与尚未交付。下一步再据此明确指标的分子、分母与观察窗口。
Dataphin把业务口径对应到计算指标
在Dataphin中，原子指标可以关联业务对象或业务活动，定义基础计算逻辑，并用“指标口径”说明统计含义与加工方式。按本例，可以围绕完成体验的机会数、满足下订条件的机会数组织基础计算，明确使用机会标识去重。下订成立仍需同时核对订单确认和订金到账，不能只看是否存在订单记录。
业务限定用于表达参与统计的业务范围，派生指标结合原子指标、业务限定、统计周期和对象粒度，组织不同范围的统计结果。团队需要把已确认的业务定义对应到这些配置，并核对来源逻辑表及实际计算条件。
“每个机会体验后30天”与“最近30天”有不同的起点。 前者以每个机会首次完成体验的时间为起点，后者按统一的日历范围筛选记录。落实本例时，数据加工应先关联同一机会的首次体验时间与下订成立时间，再判断下订是否发生在其后30天内，得到计算分子分母所需的记录。统计周期的选择需要与这段加工逻辑一起核对。
窗口还未结束的机会，应说明目前观察到了哪一天。回看原期末结果时，也应按当时的事件和状态判断；后来才发生的取消或交付，不能倒改原来的结论。至此，本体语义的对象身份和流程节点，就与企业实际数据中的记录、计算和观察范围形成了对应。
用元数据、SQL和血缘，核对每个数字的来路
有些定义写在模型里，有些已经体现在日常报表的代码中。
在 Dataphin 的资产详情中，可以先看表和字段的说明，确认数据描述的对象、状态与时间。下面的官方示例打开了“明细信息”中的“字段信息”，字段列表展示名称、描述和数据类型；主键旁有钥匙标识，操作区提供查看字段血缘的入口。
图中字段并非汽车销售字段；字段说明能帮助核对含义，不能代替具体计算逻辑。
回到购车模型，可以从结果表中找到机会标识、首次体验时间和下订时间，核对说明是否与前文约定一致。字段名称或描述只提供初步线索，还需要结合相关开发任务中的 SQL，检查筛选、关联与去重条件。
假设某份“试驾客户数”报表按个人标识去重。面对夫妻共同试驾的记录，它统计的是参与者；体验到下订转化率的分母则按购车机会去重。SQL本身提供了检查依据，也让团队知道差异发生在统计单位上。
同样，如果 SQL 只按客户编号关联试驾与订单，应继续检查这是不是同一次需求。技术连接条件提供关系线索，业务模型中的机会归属、事件时间和来源记录帮助确认其含义。数据血缘则用于找到产生结果的表和加工任务。
再看下面的表级血缘图。当前表位于中间，上游说明它从哪些表取得数据，下游说明哪些表继续使用它。遇到“转化率为什么不同”的问题，可以先沿血缘找到相关来源，再回到加工任务核对计算逻辑。
语义整理方法。虚线表示供团队核对的来源依据，保留业务定义的适用范围及出处。
整理这些资产时，每项定义都应带上可以追查的来源。例如，“体验机会数”对应哪段计算、采用哪个机会标识、适用哪种观察范围。定义发生分歧时，团队可以回到具体记录检查，也能判断需要修订业务说明，还是调整数据加工。
知识图谱为销售判断补充文档中的依据
回到前面的30个下订机会，20个已经交车，5个取消，5个仍待交付。统一口径并核对计算后，团队能够确认这批机会的转化情况。要决定下一步怎么跟进，还需要了解客户为什么取消，以及待交付订单是否按计划推进。
订单和活动记录可以定位要调查的机会，进一步判断可能需要查看沟通文本、车型资料及相关规则。例如，客户提到交期，是在询问预计时间，还是已经明确表达不能接受当前安排？这个区别，只有结合原文和当时情境才能判断。
在 Dataphin 的知识图谱中，可以定义实体类型、关系类型和属性。对于这个教学场景，可以围绕车型、配置、客户关注的问题组织文档知识。在模型中写清“提及车型”和“选定车型”的区别，也为后续抽取和查询提供明确含义。
车型身份需要延续已有业务定义。不同年款、配置版本应当能够区分，选择业务主键时要核对资料中的标识。规范建模里的车型定义可以作为图谱设计的核对依据；图谱模型则围绕文本中需要识别的实体与关系维护。
有了空间和模型，非结构化离线工作流中的知识图谱解析算子可以利用大模型抽取实体与关系，按配置写入指定图谱。模型定义会进入解析所用的提示信息，业务背景与抽取侧重点也可以补充。本例从文本开始处理；销售录音先取得相应文本。
实线表示文本处理路径，虚线表示模型定义对解析的约束；抽取结果仍需核对原文含义。
知识查询支持查找实体、发现路径及展开关联，也能查看实体相关的来源文档和片段。围绕某个车型寻找有关配置、交期或客户关注点的资料时，关系有助于定位内容，原文用于核对适用条件。这些关联知识可以为 Graph RAG，也就是利用图谱辅助检索的问答方式，提供依据。
回到某个具体购车机会，还要确认沟通材料属于哪位参与者、哪次需求和哪个时间。顾问的判断与客户的原话也应当区分。资料中出现“交期”可以成为调查线索，是否构成取消原因仍要结合相应订单和沟通经过核查。
上图为规范建模的实体关系视图，下图为知识图谱的实体查询。截图来自官方文档通用示例，说明产品界面。
截图中的两类界面分别服务于数据模型与知识检索。可以继续查看 Dataphin 产品能力，或按当前问题选择文末的规范建模与知识图谱指南。
用同一批记录验收，才能知道定义是否真的落地
完成模型、指标与文档知识的整理后，可以用前述购车记录检查结果。
夫妻共同参与一次体验，接待人数与机会数应能分别计算。核对下订记录时，检查订单确认和订金到账是否同时满足；再选一张期末后取消的订单，确认原期末的统计结果得以保留。这些检查将业务约定落实到可观察的记录上。
再核对一段沟通文本，检查“提及车型”有没有被抽取成“选定车型”，查询结果能否找到相关原文。结构化计算和文档知识各有核对依据，组织业务应用时，应沿相同的对象身份与时间范围使用它们。
至此，业务定义已有两类依据。模型与计算结果说明发生了什么，文档知识补充判断所需的原文和适用条件。它们分别建设、分别核对，使用时沿一致的对象身份与时间范围解释。
本篇完成的是业务定义与已有资产的对应。下一篇将继续讨论，怎样把这些依据组织成Agent的销售跟进任务；产品之间如何连接，以及怎样生成和修正语义模型，将在后续篇目分别展开。
想进一步了解建设方式，可以阅读规范建模指南，查看对象、活动和指标怎样组织；知识图谱模型设计指南则介绍实体、关系与属性的定义方式。
已有数仓模型、指标或业务文档，希望用于企业本体建设，可以通过瓴羊官方联系入口交流数据与知识的组织需求。
继续阅读：02 业务对象与口径怎样统一 · 05 Dataphin × WinNexo的产品架构 · 06 已有数据的逆向语义建模
资料来源
业务实体，对应业务对象、事件、流程及其关联。
原子指标与派生指标，对应计算逻辑、指标口径、业务限定、周期及粒度。
逻辑表和字段详情，对应元数据与来源血缘；文中SQL解读属于教学核对方法。
实体类型与关系类型，对应图谱类型、属性和主键设计。
知识图谱解析与知识查询，对应离线文本处理、关系检索和来源片段核对。文中汽车销售模型与指标均为教学设计。
作者：莫疑（工号264386）
