4. 数据模型设计
产能约束数据的持久化设计是供应链计划系统稳定运行的基石。本章从数据库表结构出发,通过实体关系(ER)图明确核心表之间的关联,并严格区分主数据与事务数据,为后续接口调试与实时同步提供清晰的数据边界。
4.1 产能约束数据的主数据与事务数据区分
在供应链计划系统中,产能约束数据按生命周期与变更频率可分为两大类:主数据(Master Data)与事务数据(Transactional Data)。两者的区分直接决定了数据同步策略、接口设计以及存储优化方向。
| 维度 | 主数据(Master Data) | 事务数据(Transactional Data) |
|---|---|---|
| 定义 | 描述产能资源静态属性与结构的数据 | 记录产能使用、分配与调整的动态事件 |
| 变更频率 | 低(周/月级变更) | 高(分钟/小时级变更) |
| 数据量 | 相对稳定,总量可控 | 持续增长,需定期归档 |
| 典型示例 | 工作中心、产线、设备、班次日历、产能定额 | 工单排产、设备停机记录、产能预留、产能调整单 |
| 同步方式 | 全量/增量定期同步 | 实时事件驱动同步 |
| 接口特征 | 批量接口,重校验 | 单条/小批量,低延迟 |
设计原则:主数据是事务数据的“骨架”,事务数据是主数据的“血液”。在表结构设计时,事务数据表必须通过外键引用主数据表,确保数据一致性,同时避免在主数据表中混入时间序列字段。
4.2 核心表结构设计(ER图)
以下ER图展示了产能约束数据在数据库中的核心实体及其关系。图中使用深色节点区分主数据(蓝色/紫色)与事务数据(红色/橙色),箭头表示外键依赖方向。
ER图解读:主数据节点(蓝色/紫色)位于左侧,事务数据节点(红色/橙色)位于右侧。所有事务数据均通过外键(FK)引用主数据,例如工单排产必须关联到具体的设备,产能调整单必须关联到产能定额。这种设计保证了事务数据在时间维度上的可追溯性,同时避免了主数据的重复存储。
4.3 关键表字段设计示例
以下以“设备”主数据表和“设备停机记录”事务数据表为例,展示字段设计的核心要点。
4.3.1 设备主数据表(equipment_master)
CREATE TABLE equipment_master (
equipment_id VARCHAR(32) PRIMARY KEY, -- 设备编码
equipment_name VARCHAR(128) NOT NULL, -- 设备名称
line_id VARCHAR(32) NOT NULL, -- 所属产线(FK → line_master)
equipment_type VARCHAR(32) NOT NULL, -- 设备类型(CNC/注塑/组装等)
status VARCHAR(16) DEFAULT 'ACTIVE', -- 状态:ACTIVE/INACTIVE/MAINTENANCE
standard_capacity DECIMAL(12,4) NOT NULL, -- 标准产能(件/小时)
maintenance_cycle INT DEFAULT 0, -- 维护周期(小时)
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
INDEX idx_line_id (line_id),
INDEX idx_status (status)
);
4.3.2 设备停机记录事务数据表(equipment_downtime)
CREATE TABLE equipment_downtime (
downtime_id BIGINT AUTO_INCREMENT PRIMARY KEY, -- 停机记录ID
equipment_id VARCHAR(32) NOT NULL, -- 设备编码(FK → equipment_master)
start_time DATETIME NOT NULL, -- 停机开始时间
end_time DATETIME DEFAULT NULL, -- 停机结束时间(NULL表示进行中)
downtime_reason VARCHAR(256) NOT NULL, -- 停机原因
downtime_type VARCHAR(32) NOT NULL, -- 停机类型:PLANNED/UNPLANNED
affected_capacity DECIMAL(12,4) DEFAULT 0, -- 影响产能(件)
source_system VARCHAR(64) DEFAULT 'MES', -- 来源系统
sync_status VARCHAR(16) DEFAULT 'PENDING', -- 同步状态:PENDING/SYNCED/FAILED
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
INDEX idx_equipment_id (equipment_id),
INDEX idx_start_time (start_time),
INDEX idx_sync_status (sync_status),
CONSTRAINT fk_downtime_equipment FOREIGN KEY (equipment_id) REFERENCES equipment_master(equipment_id)
);
避坑提示:事务数据表必须包含
sync_status 字段,用于标记该记录是否已同步至计划系统。同时建议添加 source_system 字段,便于在接口调试时快速定位数据来源。主数据表则无需这些字段,避免冗余。
4.4 主数据与事务数据的同步策略对比
基于表结构设计,两种数据的同步策略存在本质差异,直接影响到接口实现方式。
| 策略维度 | 主数据同步 | 事务数据同步 |
|---|---|---|
| 触发方式 | 定时任务(Cron)或手动触发 | 事件驱动(CDC / 消息队列) |
| 同步粒度 | 全量快照 + 增量变更集 | 单条记录或小批量(≤100条) |
| 一致性要求 | 最终一致性,允许分钟级延迟 | 强一致性或准实时(秒级) |
| 幂等性 | 支持(通过主键覆盖) | 必须支持(通过唯一业务键) |
| 失败处理 | 重试整个批次 | 单条重试 + 死信队列 |
| 接口协议 | RESTful POST/PUT 批量 | gRPC 流式 / Kafka 消息 |
4.5 数据模型设计检查清单
在完成表结构设计后,建议逐项核对以下要点,确保模型满足实时同步与接口调试的需求:
- 主键设计:主数据使用业务主键(如设备编码),事务数据使用自增ID或UUID,避免跨系统冲突。
- 外键约束:事务数据表必须显式声明外键,数据库层面保证引用完整性。
- 时间戳字段:所有表均包含
created_at和updated_at,用于增量同步的游标定位。 - 同步状态字段:事务数据表必须包含
sync_status,主数据表可选。 - 索引策略:外键字段、时间范围字段、同步状态字段必须建立索引,避免全表扫描。
- 归档策略:事务数据表需设计分区(按月份或季度),便于历史数据归档与清理。
- 字段类型选择:产能、数量等数值字段使用
DECIMAL而非FLOAT,避免精度丢失。