📚 课程目录第3章产品履历追溯的数据对象与信息模型

3. 产品履历追溯的数据对象与信息模型

返工返修履历追溯能否真正落地，取决于底层数据对象是否定义清晰、关系是否可推导。如果只把“产品编号、返修记录、检验结果”堆在一张表里，追溯时就会出现“查得到记录、说不清过程、算不准影响范围”的问题。本节从追溯数据对象出发，建立返工返修履历的信息模型与关系结构，使每一次返工返修都能被唯一标识、被完整还原、被准确关联。

一、追溯数据对象的定义

追溯数据对象是履历的最小语义单元。返工返修场景中，需要定义以下核心对象：

产品唯一标识（ProductUID）：产品在生命周期内的全局唯一身份，通常由“厂商代码 + 产品型号 + 序列号”构成，也可采用二维码/DataMatrix 承载。它是所有履历记录的挂载点。
批次（LotID）：同一批投料、同一工艺条件下产出的产品集合。批次用于快速圈定影响范围，返工返修中常用于判断“同批是否存在共性缺陷”。
序列号（SN）：单台产品的制造流水号，与 ProductUID 可合一，也可分离。分离时 SN 用于产线识别，ProductUID 用于全生命周期追溯。
工序（ProcessStep）：产品经过的制造或返修工位，包含工序编码、工序名称、工序版本。返工返修往往新增“返修工序”，需与原工序区分。
人员（Operator）：操作者、检验员、审批人。记录工号、资质等级、所属班组，用于责任归属与技能匹配分析。
设备（Equipment）：工装、测试台、焊接设备等。记录设备编号、校准状态、程序版本，用于判断设备因素是否导致返修。
物料（Material）：更换的元器件、辅料、替代料。记录物料批次、供应商、替代关系，用于物料追溯与质量归因。
时间（Timestamp）：事件发生的时间戳，需统一时区与精度（建议精确到秒），并区分“发生时间”与“记录时间”。
检测结果（InspectionResult）：返修前后的测试数据、判定结论、缺陷代码。它是返修是否有效的直接证据。

这些对象并非孤立存在，而是通过“产品—批次—工序—事件”的主线相互关联。设计信息模型时，关键是确定主键、外键与关系基数，使任意一次返修都能沿关系链回溯到原始制造履历。

二、返工返修履历的信息模型

返工返修履历可抽象为“一个产品、多次事件、每次事件包含多个数据对象”的结构。推荐采用三层模型：

产品层：ProductUID、型号、批次、当前状态（在制/返修中/已放行/报废）。
履历事件层：EventID、事件类型（返工/返修/复检/报废）、触发原因、关联工序、时间戳、责任人。
事件明细层：每次事件下的设备、物料、检测结果、参数快照、附件（图片/波形）。

关系结构上，产品与履历事件是一对多，履历事件与明细是一对多，批次与产品是一对多，工序与事件是多对多。返修事件还需额外记录“返修前状态”和“返修后状态”，形成状态迁移链。这样，当客户返回一台故障机时，输入 ProductUID 即可拉出完整履历树，并定位到具体返修事件及其更换物料、操作人员和测试数据。

三、关系结构的设计要点

信息模型的价值在于“可查询、可推导、可审计”。设计时需注意三点：

第一，主键选择。ProductUID 作为全局主键，EventID 作为事件主键，明细行采用“EventID + 明细序号”复合主键。避免用时间戳或人员工号做主键，防止并发写入冲突。

第二，状态字段与事件分离。产品当前状态是“结果”，履历事件是“过程”。状态可由事件推导，但为了查询效率，可在产品层冗余一个当前状态字段，并通过事件写入时同步更新。返修前后状态需成对记录，形成可验证的状态迁移。

第三，参数快照。设备程序版本、工艺参数、测试阈值会随时间变化。返修事件必须记录“当时生效”的参数快照，而不是引用当前配置。否则半年后回溯时，看到的参数已不是当时实际使用的值，追溯结论会失真。

四、可落地的履历数据表结构示例

以下给出一组可直接参考的表结构示例，字段按返工返修场景裁剪，避免引入无关管理字段。示例中的字段名和类型为教学假设，实际落地时需结合企业 MES/QMS 系统调整。

表：product_master（产品主表）
  product_uid   VARCHAR(64)  PK   产品唯一标识
  model         VARCHAR(32)       产品型号
  lot_id        VARCHAR(32) FK    批次号
  current_state VARCHAR(16)       当前状态：IN_PROCESS/REWORKING/RELEASED/SCRAPPED

表：rework_event（返工返修事件表）
  event_id      VARCHAR(64)  PK   事件唯一标识
  product_uid   VARCHAR(64)  FK   关联产品
  event_type    VARCHAR(16)       事件类型：REWORK/REPAIR/RECHECK/SCRAP
  trigger_reason VARCHAR(128)     触发原因
  process_step  VARCHAR(32)       关联工序编码
  operator_id   VARCHAR(32)       责任人工号
  event_time    DATETIME          事件发生时间
  state_before  VARCHAR(16)       返修前状态
  state_after   VARCHAR(16)       返修后状态

表：event_detail（事件明细表）
  event_id      VARCHAR(64)  FK   关联事件
  detail_seq    INT          PK   明细序号
  detail_type   VARCHAR(16)       明细类型：EQUIPMENT/MATERIAL/INSPECTION
  ref_id        VARCHAR(64)       引用对象编号（设备号/物料批次/检测单号）
  param_snapshot TEXT             参数快照（JSON）
  result        VARCHAR(16)       结果：PASS/FAIL/NA
  remark        VARCHAR(256)      备注

以一台型号为 X200、批次为 LOT-20240612-03 的产品为例，其 ProductUID 为 “ACME-X200-000871”。该产品在客户返回后登记事件 EV-20240715-009，事件类型为 REPAIR，触发原因为“电源模块无输出”，关联工序为“电源返修工位”，操作员为 OP-1042，返修前状态为 RELEASED，返修后状态为 REWORKING。明细中记录更换物料批次 MAT-20240520-A、测试设备 EQ-PSU-07、检测结果 PASS。这样，任意查询者输入 ProductUID，即可沿事件链还原完整返修过程。

设计信息模型时，先问三个问题：这台产品是谁（ProductUID）？它经历了什么（EventID）？每次经历的证据是什么（明细）？三个问题对应三层模型，追溯链就不会断。

常见错误是把返修记录直接写在产品主表里，导致一台产品多次返修时只能保留最后一次。正确做法是事件独立成表，产品主表只保留当前状态，历史事件全部保留。

综上，返工返修履历追溯的数据对象与信息模型，核心是“以产品唯一标识为锚点、以事件为过程、以明细为证据”的三层结构。批次、序列号、工序、人员、设备、物料、时间、检测结果各归其位，通过明确的关系基数串联成可查询、可推导、可审计的追溯网络。只有模型设计到位，后续的追溯查询、影响范围分析和质量归因才有可靠的数据基础。