#Schema 类型

系统有两种 Schema 类型：Entity（实体） 和 Event（事件）。

#基础概念

#核心概念对比

建模时，需要根据实际业务场景合理划分实体和事件，并建立它们之间的关联关系。

#Entity（实体表）

实体表用于描述业务中的核心对象，例如：客户、产品、门店、员工等。

#建模要求

• 必须定义主键字段：作为实体的唯一标识，用于与其他实体表或事件表建立关联

#Event（事件表）

事件表用于记录业务中发生的行为或交易，例如：订单、支付、退货、登录等。

#建模要求

• 必须定义唯一的时间戳字段：标识事件发生的时间点

#时间戳字段说明

时间戳字段用于确定问答时的默认时间维度。

以订单表为例，通常包含多个时间字段：下单时间、支付时间、发货时间等。在 Schema 中，需要选择其中一个作为时间戳字段，系统会将其作为默认的统计时间。

示例：用户提问"去年销售额 TOP10 的产品"时，系统会自动使用时间戳字段进行时间范围筛选。

对于涉及多个时间条件的问题，如"上月下单、本月发货的订单"，系统仍能识别并分别匹配到对应的时间字段。

#实体关联

实体之间以及事件与实体之间可以建立关联关系，类似于数据库中的外键。

#配置方式

在 Schema 配置中，将字段类型设置为"实体"（object），然后选择对应的实体表即可完成关联。系统会通过该字段与目标实体表的主键进行匹配，实现表与表之间的连接。

#关联规则

#字段命名规范

字段命名应遵循原子化原则，确保语义清晰、无冗余。

Schema 中的字段名称直接影响问答的匹配准确度。

#实体表示例

数据库中产品表的字段可能命名为"产品ID"、"产品名称"、"产品类型"。在 Schema 中建议调整为：

• 表名：产品
• 字段名：ID、名称、类型

去除重复的表名前缀后，字段语义更加清晰，问答匹配度也会相应提升。

#事件表示例

事件表中的关联字段命名需要与实体表名称保持一致。

例如订单表中有"产品ID"字段，在 Schema 中应：

1. 将字段类型设置为"实体"（object）
2. 关联表选择"产品"
3. 字段名从"产品ID"修改为"产品"

这样配置后，字段名与关联的实体表名称一致，系统能够更准确地理解数据关系，提升问答匹配效果。

#实战示例：从宽表拆解实体与事件

下面通过一个零售场景的订单宽表，演示如何识别和拆分实体表与事件表，结合上面的说明内容，注意建模后模型同原表的字段命名变化。

#订单宽表

#拆解分析

整张宽表的基调是一个事件表，因为它记录了每次订单发生时的所有信息。但其中包含了很多维度信息，比如店铺、产品等，这些应该定义为实体表。

我们可以把相关信息抽取出来：

#拆分结果

这张宽表会被分成 4 张表：

1. 店铺实体表
2. SKU 实体表
3. SPU 实体表
4. 订单事件表

#表关系图

图例说明： 🔑 主键　🔗 外键关联　⏱️ 时间戳　📊 度量值

关联关系：

             ┌─────────┐
             │   SPU   │
             └────▲────┘
                  │
             ┌────┴────┐       ┌─────────┐
             │   SKU   │       │  店铺   │
             └────▲────┘       └────▲────┘
                  │                 │
                  └────────┬────────┘
                           │
                    ┌──────┴──────┐
                    │  订单       │
                    └─────────────┘

其中 SKU 和 SPU 有关联，订单事件表与所有实体表关联。

正是因为 SKU 和 SPU 有关联，所以即使订单事件表中只存放了 sku编码，我们也可以通过 sku编码 关联到 SKU 实体表，再关联 SPU 实体表，从而根据 SPU 信息进行统计和分析。