3. 建立本体模型 (Ontology)

在有了高质量的 Dataset 之后，我们需要赋予数据“业务灵魂”。本体 (Ontology) 也是平台区别于传统数据中台的标志性能力。

3.1 为什么需要本体？

大模型和前端开发者通常不懂底层表结构（比如 dim_user_info_v2 到底是什么意思）。 本体层的作用就是将这层结构翻译成：对象 (Object) -> 属性 (Property) -> 关系 (Link) -> 动作 (Action)。

3.2 映射对象与属性

1. 进入 [本体] 菜单，点击 [新建对象类]。
2. 基础信息：命名为 Employee (内部标识) 和 员工 (展示名称)。
3. 绑定数据：选择底层对应的 Dataset（例如我们之前清洗好的 cleaned_employee_dataset）。
4. 主键映射：选择底层表的哪一列作为对象的全局唯一 ID（例如 emp_no）。
5. 属性映射：将底层物理列勾选为你需要的业务属性。
   • 例如：把 hire_date 映射为属性，并设置其在 UI 上默认使用日期选择器渲染。
   • 勾选“是否允许搜索”，将其推入底层的搜索引擎中。

3.3 建立关联关系 (Link)

真实世界的业务对象是网状的。建立 Link 后，你可以通过图谱漫游的方式在不同对象间穿梭，完全不需要再写 JOIN SQL。

1. 在 Employee 对象页面，切换到 [关联关系] Tab。
2. 点击新建关系，例如命名为 department。
3. 选择目标对象类为 Department。
4. 定义基数关系（例如 Many To One，多个员工属于一个部门）。
5. 配置底层连接条件（例如 Employee.dept_id = Department.id）。

配置完成后，开发者在 SDK 中就可以直接这样优雅地获取数据：

// 直接获取某个员工所在的部门信息，无需手写 JOIN
const dept = await client.objects.Employee.get("E1001").department().fetch();

3.4 定义业务动作 (Action)

如果说对象、属性和关系定义了数据的“读”，那么 Action 就定义了数据的“写”。

1. 切换到 [动作] Tab，新建一个动作，命名为 update_employee_status。
2. 定义输入参数：例如需要传入 new_status (字符串) 和 reason (字符串)。
3. 定义校验规则：例如 new_status 必须属于枚举值 [ACTIVE, INACTIVE]。
4. 定义执行逻辑：编写一段受限的脚本或 SQL，指明如何将这些参数写入到底层的 Dataset 中。

Action 定义好后，它会自动成为一个强类型的 API 接口，甚至直接转换为大模型可以调用的 Tool（函数调用）。