4. 制造数据建模与血缘元数据设计

制造数据血缘要能跨系统、跨工序地追溯,前提是先把制造现场的核心实体建模清楚,并为它们之间的血缘关系定义统一的类型与属性。如果实体模型不统一,同一台设备在MES里叫“CNC-01”、在设备台账里叫“加工中心1号”,血缘图就会断链;如果关系类型不统一,同一批物料“被消耗”和“被装配”混用,追溯路径就无法自动推理。本节围绕产品、工艺、设备、工单、批次、物料六类实体,说明元数据模型的设计方法,以及血缘关系类型与属性的定义规范。

一、六类核心实体的元数据模型

制造数据建模的目标不是把数据库表照搬过来,而是抽取“能唯一标识、能参与追溯、能表达状态”的最小元数据集合。每类实体都应包含三类字段:标识字段(全局唯一ID与业务编码)、描述字段(名称、规格、版本)、血缘锚点字段(用于连接上下游的键)。下面给出一个可直接参考的实体元数据模型示例。

实体主键(示例)关键业务字段血缘锚点
产品 Productproduct_id产品编码、名称、型号、BOM版本product_code + bom_version
工艺 Processprocess_id工艺路线号、工序号、版本、标准工时route_id + step_no
设备 Equipmentequipment_id设备编号、类型、所属产线、状态equipment_code
工单 WorkOrderwo_id工单号、计划数量、状态、计划起止wo_no
批次 Batchbatch_id批次号、数量、生产时间、质检结论batch_no
物料 Materialmaterial_id物料编码、名称、供应商、来料批次material_code + supplier_lot

设计时有三条经验规则。第一,业务编码与内部ID分离:内部ID用UUID保证跨系统唯一,业务编码保留现场可读性,两者都进入元数据。第二,版本必须显式建模:产品BOM版本、工艺路线版本是血缘分叉的关键,同一产品不同版本消耗的物料可能完全不同,版本字段缺失会导致追溯结果错误合并。第三,状态字段要可枚举:工单的“已下达/生产中/已完工/已关闭”、批次的“待检/合格/不合格/让步接收”,这些状态直接影响血缘边是否成立——未完工工单不应产生“产出批次”关系。

二、血缘关系类型定义

实体之间需要一套受控的关系类型词表,避免同义异名。制造场景中常用的血缘关系可归纳为五类:

  • 结构关系(BOM):产品—物料之间的“组成/装配”关系,带用量、层级、替代料标记。
  • 工艺关系:产品—工艺—工序之间的“加工/流转”关系,带工序顺序、加工参数。
  • 执行关系:工单—批次—设备之间的“生产/使用”关系,带时间戳、操作人、设备参数。
  • 消耗关系:批次—物料之间的“投入/消耗”关系,带投入数量、投入时间、投料工位。
  • 派生关系:上游批次—下游批次的“产出/拆分/合并”关系,带转换率、拆分数量。

每一条血缘边都应携带属性,否则只能回答“有没有关系”,无法回答“关系是否成立、何时成立、量是多少”。建议每条边至少包含:relation_type(关系类型)、source_id / target_id(两端实体)、timestamp(发生时间)、quantity(数量或用量)、confidence(置信度,用于区分实测采集与人工补录)、source_system(数据来源系统)。其中 confidence 在制造场景中非常实用:来自设备PLC自动采集的边可标为1.0,来自纸质记录补录的边可标为0.6,追溯时可按阈值过滤。

关系类型应建立受控词表并冻结命名,例如统一使用 CONSUMES 表示“批次消耗物料”,不要同时出现 USES、CONSUME、INPUT 等变体,否则图查询需要额外做同义词归一。

三、从实体到血缘图:一次追溯的建模视角

把上述实体与关系组合起来,就得到一张有向图:节点是六类实体,边是五类关系。追溯的本质是在这张图上做有向路径查询。例如要回答“某客户投诉的产品批次用了哪些来料批次”,路径为:产品 → 工单 → 产出批次 → 消耗关系 → 物料批次 → 供应商。下面用一张关系图展示六类实体与五类血缘边的连接结构,以及每条边携带的关键属性。

产品 Product product_code / bom_version 工艺 Process route_id / step_no 工单 WorkOrder wo_no / status 设备 Equipment equipment_code 批次 Batch batch_no / qc_result 物料 Material material_code / supplier_lot 结构关系 BOM 用量 / 层级 工艺关系 工序顺序 / 参数 执行关系 时间戳 / 操作人 执行关系 设备参数 消耗关系 投入数量 / 工位 派生 血缘边通用属性(每条边必须携带) relation_type:关系类型(受控词表)  source_id / target_id:两端实体ID timestamp:发生时间  quantity:数量或用量  source_system:来源系统 confidence:置信度(1.0=自动采集,0.6=人工补录)  version:BOM/工艺版本 追溯查询示例:产品 → 工单 → 产出批次 → 消耗关系 → 物料批次 → 供应商

四、关系属性的落地要点

关系属性定义完成后,还需要解决三个工程问题。第一,时间语义:timestamp 应记录业务发生时间而非入库时间,否则跨系统对齐时会出现“先消耗后产出”的倒挂。第二,数量守恒校验:同一批次向下游拆分的数量之和不应超过上游批次数量,超出即说明存在漏采或重复采集,可作为数据质量规则。第三,版本一致性:当产品BOM版本升级后,旧工单仍应关联旧版本BOM,血缘边上的 version 字段必须与工单创建时的版本快照一致,不能随主数据更新而漂移。

不要把“关系”直接建成外键字段塞进实体表。血缘边是独立的一等对象,需要独立存储、独立版本、独立置信度,否则无法表达“同一对实体在不同时间存在多条不同性质的关系”。

最后给出一份可直接用于建表或建模工具的关系定义片段,作为本节的可执行成果参考:

relation_type: CONSUMES
  source: Batch(batch_no)
  target: Material(material_code + supplier_lot)
  attributes:
    timestamp:    datetime   # 投料发生时间
    quantity:     decimal    # 投入数量
    uom:          string     # 单位
    station:      string     # 投料工位
    confidence:   float      # 0~1
    source_system:string     # MES / WMS / 手工补录
    version:      string     # 关联BOM版本