3. 追溯数据模型基础

食品质量追溯系统的核心不是"存了多少数据"，而是"数据之间能否沿着正确的路径被找到"。实体-联系模型（ER模型）正是把这种"找得到"的能力提前设计进数据库结构的方法。本节围绕追溯场景中最常见的五类核心实体——批次、产品、企业、位置、事件——说明它们各自的属性与联系，并进一步区分正向跟踪与反向溯源对数据模型提出的不同要求，最后给出一个可落地的简单追溯场景ER图草图。

一、五类核心实体的识别与属性设计

在追溯语境下，实体不是业务表单的简单映射，而是"需要被独立追踪、且能与其他对象建立联系"的对象。以下五类实体构成了绝大多数食品追溯模型的主干：

• 产品（Product）：指品类层面的定义，如"巴氏杀菌鲜牛奶 950mL"。关键属性包括产品编码、名称、规格、保质期、储存条件。产品是相对稳定的"类型"，不随生产批次变化。
• 批次（Batch/Lot）：追溯的最小粒度单元，是"某一时间、某一产线、某一原料组合"的产物。关键属性包括批次号、生产日期、数量、质检结论。批次是连接产品与事件的枢纽。
• 企业（Enterprise）：包括生产企业、原料供应商、物流商、经销商。关键属性包括企业统一社会信用代码、名称、角色类型、资质信息。同一企业可在不同环节扮演不同角色。
• 位置（Location）：指发生物理位移或存放的场所，如车间、冷库、运输车辆、门店货架。关键属性包括位置编码、类型、地址、温区要求。位置是判断"货在哪里"的依据。
• 事件（Event）：追溯链上的动态节点，如原料入库、生产投料、成品出库、运输交接、门店收货。关键属性包括事件类型、发生时间、操作企业、发生位置、关联批次。事件是把静态实体"串起来"的关键。

需要强调的是，批次与产品是一对多关系（一个产品对应多个批次），批次与事件是一对多关系（一个批次经历多个事件），而事件同时关联企业、位置和批次，形成"事件作为联系中心"的星形结构。这种设计的好处是：无论正向还是反向查询，都可以从事件表出发，避免在多个业务表之间做复杂的多表连接。

二、正向跟踪与反向溯源对模型的不同要求

正向跟踪回答的是"这批货去了哪里"，反向溯源回答的是"这批货从哪来"。两者在数据模型上的要求并不对称：

正向跟踪要求模型能够从"原料批次"出发，沿着事件链向下游扩散。它强调的是一对多的分支能力：一个原料批次可能被投料到多个成品批次，一个成品批次可能发往多个经销商。因此模型中必须保留"事件→下游批次"的关联字段，并且事件的时间顺序必须可排序，否则无法还原扩散路径。

反向溯源要求模型能够从"问题成品批次"出发，向上游逐级回溯。它强调的是多对一的收敛能力：一个成品批次可能由多个原料批次共同构成，因此需要一张"批次构成关系"表（或投料明细表），记录"成品批次—原料批次—投料量"的三元关系。缺少这张表，反向溯源就会在"这个成品用了哪些原料"这一步断链。

三、简单追溯场景的ER图草图

下面以一个"乳制品从原料奶到门店"的简化场景为例，给出ER图草图。图中矩形表示实体，菱形表示联系，连线标注基数（1、N）。该图仅表达结构与联系方向，不涉及具体字段类型。

读图时注意三点：第一，事件是联系中心，它同时挂接批次、企业、位置，因此事件表应包含批次号、企业ID、位置ID三个外键；第二，批次构成关系是独立实体，用虚线连到批次，表示它描述的是批次之间的"投入—产出"关系，而不是批次与事件的时序关系；第三，正向与反向两条路径在图中用不同颜色区分，它们共享同一套实体，但依赖的联系不同——正向依赖事件的下游关联，反向依赖批次构成关系。

四、建模时的两个实操判断

第一，事件类型是否需要独立字典表。如果事件类型固定且数量少（如入库、投料、出库、收货四类），可直接用枚举字段；如果后续要扩展检验、召回、退货等类型，建议单独建事件类型字典表，避免枚举值散落在代码中。第二，位置是否要区分"企业内位置"与"运输位置"。运输车辆是移动位置，其温区监控数据往往独立采集，建模时可给位置表增加"是否移动"标志位，便于后续接入冷链温度记录。

完成ER草图后，建议用两三个真实业务问题做一次"走图验证"：例如"批号 A 的原料奶流向了哪些成品批次"应能沿事件与构成关系走通；"某门店收到的成品由哪些原料构成"应能反向收敛到原料批次。若某条路径在图上走不通，说明模型缺少相应的联系，应在进入物理表设计之前补齐，而不是等到系统上线后再靠临时查询补救。