3. 数据模型设计：事件记录表结构、决策日志表结构、关联关系设计
数据模型是决策日志接口的基石。在供应链控制塔场景中，事件记录（Event Record）承载原始业务事实，决策日志（Decision Log）记录系统或人工对事件作出的响应。两者通过明确的关联关系构成可追溯的闭环。本章将依次定义两张核心表的字段结构、约束规则，并设计其关联方式。
3.1 事件记录表结构（event_record）
事件记录表用于存储从供应链各节点（仓储、运输、订单、生产）采集的原始事件。每条记录代表一个不可变的事实，例如“库存低于安全水位”“运输车辆偏离路线”“订单交付延迟”。
| 字段名 | 类型 | 约束 | 说明 |
|---|---|---|---|
| event_id | BIGINT UNSIGNED | PK, AUTO_INCREMENT | 全局唯一事件标识 |
| event_uuid | CHAR(36) | UNIQUE, NOT NULL | 业务层幂等键，防止重复写入 |
| event_type | VARCHAR(64) | NOT NULL, INDEX | 事件类型编码，如 stock_low、route_deviation |
| source_system | VARCHAR(32) | NOT NULL | 事件来源系统标识，如 WMS、TMS、OMS |
| source_id | VARCHAR(128) | NOT NULL | 来源系统内的业务主键，如订单号、运单号 |
| event_time | DATETIME(3) | NOT NULL, INDEX | 事件实际发生时间（毫秒精度） |
| payload | JSON | NOT NULL | 事件详情，包含上下文数据 |
| severity | TINYINT UNSIGNED | NOT NULL, DEFAULT 0 | 严重等级：0=信息，1=警告，2=严重 |
| status | VARCHAR(16) | NOT NULL, DEFAULT 'pending' | 处理状态：pending、processing、resolved、ignored |
| created_at | DATETIME(3) | NOT NULL | 记录入库时间 |
设计要点：event_uuid 由来源系统生成，用于幂等去重；payload 字段使用 JSON 类型，支持灵活的事件结构，避免频繁 DDL。
3.2 决策日志表结构（decision_log）
决策日志表记录针对事件作出的每一次决策。决策可以是自动规则触发（如补货建议）、人工审批（如加急调拨）或系统编排动作（如重分配承运商）。
| 字段名 | 类型 | 约束 | 说明 |
|---|---|---|---|
| decision_id | BIGINT UNSIGNED | PK, AUTO_INCREMENT | 全局唯一决策标识 |
| decision_uuid | CHAR(36) | UNIQUE, NOT NULL | 业务幂等键 |
| event_id | BIGINT UNSIGNED | NOT NULL, FK | 关联的事件记录主键 |
| decision_type | VARCHAR(64) | NOT NULL, INDEX | 决策类型，如 auto_replenish、manual_escalate |
| decision_action | JSON | NOT NULL | 决策执行的动作参数 |
| decision_result | VARCHAR(16) | NOT NULL | 结果：approved、rejected、pending、failed |
| decision_reason | TEXT | NULL | 决策理由或备注 |
| decided_by | VARCHAR(64) | NOT NULL | 决策者标识：system 或用户 ID |
| decided_at | DATETIME(3) | NOT NULL | 决策时间 |
| created_at | DATETIME(3) | NOT NULL | 记录入库时间 |
注意：decision_action 字段存储具体的执行参数，例如补货数量、目标仓库编码；不要将业务逻辑硬编码在字段名中，保持 JSON 的灵活性。
3.3 关联关系设计
事件记录与决策日志之间是一对多关系：一个事件可能触发零个、一个或多个决策。例如，库存预警事件可能同时触发自动补货决策和人工通知决策。
关联关系通过 decision_log.event_id 外键实现，并建立索引以支持高效查询。此外，还需要设计以下辅助关联：
- 决策链追溯：在 decision_log 中增加
parent_decision_id字段（自引用外键），支持决策的级联或依赖关系。 - 事件聚合视图：通过
event_type + source_id复合索引，快速检索同一业务对象的所有事件及对应决策。 - 时间窗口关联：利用
event_time和decided_at计算决策响应延迟，用于 SLA 监控。
3.4 索引与性能策略
基于查询场景，设计以下索引策略：
- 事件记录表：
idx_event_type_time：(event_type, event_time)，用于按类型和时间范围筛选。idx_source：(source_system, source_id)，用于按来源系统追溯。idx_status：(status)，用于待处理事件轮询。
- 决策日志表：
idx_event_id：(event_id)，外键关联查询。idx_decision_type_time：(decision_type, decided_at)，用于决策分析。idx_parent：(parent_decision_id)，用于决策链遍历。
实践建议：在开发阶段使用 EXPLAIN 验证查询计划；对于 payload 和 decision_action 中的 JSON 字段，可考虑使用 MySQL 8.0+ 的虚拟列 + 索引，加速 JSON 内属性过滤。
3.5 数据完整性约束
为保证数据质量，在数据库层面实施以下约束：
| 约束类型 | 作用对象 | 规则说明 |
|---|---|---|
| 外键约束 | decision_log.event_id | 引用 event_record.event_id，禁止孤立决策记录 |
| 唯一约束 | event_record.event_uuid | 防止同一事件被重复写入 |
| 唯一约束 | decision_log.decision_uuid | 防止同一决策被重复记录 |
| 检查约束 | event_record.severity | 值域 [0, 2] |
| 检查约束 | decision_log.decision_result | 值域：approved, rejected, pending, failed |
以上设计确保了事件与决策之间的完整追溯能力，为后续的接口开发提供了坚实的数据基础。