3. 追溯数据模型设计：追溯数据实体定义、数据关系建模、关键字段设计、数据字典建立
好，咱们直接进入正题。追溯数据模型，说白了就是给产品建一个「数字档案」。你想想看，一个产品从原材料进厂，到成品发货，中间经历了多少道工序？每个工序又产生了多少数据？如果没有一个清晰的数据模型，追溯就是一句空话。
我个人习惯，在设计追溯模型之前，先问自己三个问题：
- 要追溯什么？（实体定义）
- 这些东西怎么串起来？（关系建模）
- 每个节点存什么？（字段设计）
嗯，咱们一个一个来拆解。
3.1 追溯数据实体定义
什么是实体？就是你要追溯的「对象」。在MES里，常见的追溯实体有这些：
| 实体名称 | 英文标识 | 说明 |
|---|---|---|
| 物料批次 | MaterialLot | 原材料、半成品、成品的批次信息 |
| 生产工单 | WorkOrder | 生产指令，一个工单对应一个批次 |
| 工序记录 | OperationRecord | 每个工序的执行情况 |
| 设备状态 | EquipmentStatus | 加工设备的参数与状态 |
| 质量检测 | QualityCheck | 检验结果、SPC数据 |
| 人员操作 | OperatorAction | 谁在什么时间做了什么 |
我在项目中遇到过，有些企业只定义了「物料批次」和「生产工单」，结果出了问题，查了半天发现设备参数没记录，根本没法分析根因。所以，实体定义一定要覆盖「人机料法环」五个维度。
核心原则：每个实体必须有一个全局唯一的标识符（GUID或流水号），这是追溯的「身份证」。
3.2 数据关系建模
实体定义好了，接下来就是「连线」。数据关系建模，说白了就是回答：这批料用了哪台设备？谁操作的？检测结果怎么样？
我常用的建模方式是「星型模型」——以物料批次为中心，其他实体像卫星一样围绕它。
你看这张图，物料批次是核心。一个工单可以产出多个批次（比如分罐），一个批次也可以经过多个工序。设备状态和质量检测，则是每个工序的「附属品」。这种关系，在数据库里就是外键关联。
避坑指南：我曾经在一个项目里，把「设备状态」和「工序记录」做成了1:1关系。结果发现同一台设备在同一个工序里可能记录多次参数（比如温度每分钟采集一次）。后来改成了1:N，才解决了数据丢失的问题。
3.3 关键字段设计
字段设计，是数据模型的「血肉」。每个实体需要哪些字段？我总结了一个「最小必要集」：
物料批次（MaterialLot）
LotID VARCHAR(50) -- 批次号（唯一）
MaterialCode VARCHAR(30) -- 物料编码
Quantity DECIMAL(10,2) -- 数量
Unit VARCHAR(10) -- 单位
Status INT -- 状态（0=待检,1=合格,2=不合格）
CreateTime DATETIME -- 创建时间
ParentLotID VARCHAR(50) -- 父批次号（用于追溯拆分/合并）
工序记录（OperationRecord）
RecordID INT -- 自增主键
LotID VARCHAR(50) -- 关联批次号
OperationCode VARCHAR(20) -- 工序代码
StartTime DATETIME -- 开始时间
EndTime DATETIME -- 结束时间
EquipmentID VARCHAR(30) -- 设备编号
OperatorID VARCHAR(30) -- 操作员工号
ParamJSON TEXT -- 工艺参数（JSON格式，灵活扩展）
嗯，这里要注意。我见过很多设计把工艺参数拆成几十个字段，结果每次改工艺都要改表结构。我个人习惯用ParamJSON字段，把参数存成JSON。这样既灵活，又方便查询。
质量检测（QualityCheck）
CheckID INT -- 自增主键
LotID VARCHAR(50) -- 关联批次号
CheckType VARCHAR(20) -- 检测类型（首检/巡检/完工检）
Result INT -- 结果（0=NG,1=OK）
DefectCode VARCHAR(20) -- 缺陷代码
CheckTime DATETIME -- 检测时间
CheckerID VARCHAR(30) -- 检验员工号
注意：关键字段设计时，一定要考虑「时间戳」和「操作人」。没有时间维度的追溯，等于没有追溯。你想想看，如果只知道「这批料不合格」，却不知道「什么时候、谁检的」，那根本没法做根因分析。
3.4 数据字典建立
数据字典，就是给每个字段写「说明书」。很多MES项目上线后乱成一锅粥，就是因为没有数据字典。我举个例子：
| 字段名 | 数据类型 | 长度 | 是否必填 | 说明 | 取值范围/示例 |
|---|---|---|---|---|---|
| Status | INT | 4 | 是 | 物料状态 | 0=待检,1=合格,2=不合格,3=冻结 |
| DefectCode | VARCHAR | 20 | 否 | 缺陷代码 | D001=划伤, D002=尺寸超差 |
| ParamJSON | TEXT | - | 是 | 工艺参数JSON | {"temp":180, "pressure":2.5} |
数据字典的建立，我建议在项目一开始就做，并且用Excel或Wiki维护。每次变更字段，都要更新字典。我曾经在一个项目里，因为数据字典没及时更新，导致开发人员和业务人员对「Status=3」的理解不一致，差点造成批量数据错误。
总结一下：追溯数据模型设计，核心就是「实体-关系-字段-字典」四步走。实体要全，关系要清，字段要精，字典要准。做到这四点，你的追溯系统就成功了一半。
好了，这一节的内容就到这里。数据模型是地基，地基打牢了，后面的追溯查询和分析才能跑得稳。下一节咱们聊聊「追溯链的构建与数据采集」，到时候我会分享一些实际项目中的采集策略和坑点。