4. 数据质量规则的形式化表达

在制造数据质量工程中，规则不能只停留在“不能为空”“必须大于零”这类自然语言描述上。自然语言便于沟通，却无法被系统稳定解析、批量执行和版本管理。形式化表达的核心任务，是把业务意图翻译成机器可解析、可复用、可追溯的结构化对象。本节围绕五种形式化载体展开：规则模板、断言、约束、业务规则引擎语法和规则元数据模型，并说明它们如何协同支撑一条规则从定义到落库、执行、追溯的完整链路。

规则模板：把同类规则抽象成可复用骨架

制造现场存在大量同构规则。例如“某测点采集值必须落在工艺上下限之间”“某工单的完工数量不得超过计划数量”“某设备状态码必须属于允许枚举集”。这些规则的对象不同，但结构一致。规则模板就是抽取这种共性后形成的参数化骨架，通常包含模板标识、适用对象类型、参数占位符、表达式骨架和默认严重级别。

以区间约束模板为例，可定义模板 RANGE_CHECK，参数为 {table}、{column}、{lower}、{upper}、{severity}，表达式骨架为 {column} BETWEEN {lower} AND {upper}。实例化时填入 table=fact_measure、column=temperature、lower=180、upper=220，即得到一条具体规则。模板的价值在于：规则编写从“每次重写”变为“选模板+填参数”，既降低出错率，也让同类规则的统计、批量调整和影响分析成为可能。

断言：可判真假的原子判断

断言是规则的最小可执行单元，其本质是一个返回布尔值的表达式。一条规则可以由一个断言构成，也可以由多个断言通过逻辑运算组合。制造数据中常见的断言类型包括：非空断言 IS NOT NULL、唯一性断言 COUNT(*)=COUNT(DISTINCT key)、值域断言 IN (...)、跨字段一致性断言 end_time >= start_time、跨表引用断言 EXISTS (SELECT 1 FROM dim_equipment WHERE ...)。

断言必须明确三件事：作用对象（表、字段、行集）、判断条件、期望结果。例如“设备编码必须存在于设备主数据中”可形式化为：对 fact_measure.equipment_code 的每一行，断言 EXISTS (SELECT 1 FROM dim_equipment d WHERE d.equipment_code = fact_measure.equipment_code) 为真。断言越原子，越容易定位问题、复用和组合；把多个不相关判断塞进一个断言，会导致失败原因难以归因。

约束：从单点断言到数据集合的完整性条件

约束比断言更强调“在数据集合层面必须成立的条件”。数据库中的主键约束、外键约束、唯一约束、检查约束都是典型形式。在数据质量场景中，约束常被扩展为跨表、跨时间窗口的完整性条件，例如：某工单在 fact_production 中的完工数量总和，必须等于 fact_order 中该工单的计划数量；某设备在连续 5 分钟窗口内的状态码不得出现非法跳变。

约束与断言的关系可以理解为：断言是判断语句，约束是要求该判断在指定数据集上恒成立。约束通常需要声明作用范围（全表、分区、时间窗口、分组）、违反判定方式（存在反例即失败）以及容忍度（允许的违反比例）。在制造场景中，给约束设置合理容忍度很重要，因为传感器抖动、补录延迟等会造成少量瞬时违反，直接判定整批数据不合格可能并不符合业务实际。

业务规则引擎语法：让规则可执行、可编排

规则引擎语法负责把模板、断言和约束组织成可被引擎加载和执行的规则集。常见形式包括声明式 DSL、决策表、表达式语言等。无论采用哪种语法，一条可执行规则通常需要包含：规则标识、触发条件（何时评估）、作用对象（对哪些数据评估）、判断表达式、严重级别、处置动作（告警、阻断、标记、转人工）。

下面是一个简化的规则 DSL 示例，用于说明语法结构，并非某个特定引擎的官方语法：

rule R_TEMP_RANGE_001
  template: RANGE_CHECK
  scope: fact_measure WHERE line_id = 'L01'
  when: batch_id = ${batch_id}
  assert: temperature BETWEEN 180 AND 220
  severity: MAJOR
  action: flag_row, notify_quality_engineer
  metadata: owner=process_eng_01, version=1.2, effective_from=2025-01-01

这段语法体现了规则引擎的关键能力：按批次触发、按产线限定范围、按表达式判断、按级别决定处置。引擎执行时通常先做规则匹配，再对目标数据集逐行或分组评估，最后汇总违反结果并触发动作。规则之间的优先级、互斥关系和依赖顺序也需要在语法或元数据中声明，否则同一数据可能被多条规则重复处置。

规则元数据模型：让规则可管理、可追溯

规则本身也是数据，需要被管理。规则元数据模型描述一条规则“是谁、为什么、何时、对什么、以什么方式”生效。一个实用的元数据模型通常包含以下维度：

• 标识与版本：规则 ID、名称、版本号、生效时间、失效时间。
• 业务归属：所属业务域、责任部门、责任人、关联 KPI 或质量特性。
• 技术绑定：模板 ID、作用表/字段、断言表达式、约束范围、引擎语法版本。
• 执行策略：触发频率、严重级别、容忍度、处置动作、是否阻断。
• 血缘与影响：上游数据源、下游报表或模型、关联规则、变更记录。
• 运行观测：最近执行时间、通过率、违反样本数、平均评估耗时。

元数据模型让规则从“一段脚本”升级为“可治理资产”。当工艺参数调整时，可以按模板和字段快速找到受影响规则；当某条规则频繁误报时，可以结合运行观测和血缘判断是阈值问题还是数据源问题；当审计要求说明某批数据为何被拦截时，可以回溯到具体规则版本和处置动作。

五层载体如何协同

这五种形式化载体不是并列选项，而是同一治理链条上的不同层次。模板提供复用骨架，断言提供原子判断，约束提供集合层面的恒成立条件，规则引擎语法把前三者组织成可执行规则，元数据模型则让整条链路可管理、可追溯。实际落地时，建议先梳理高频规则模式并沉淀模板，再把每条规则拆成可独立验证的断言，对需要跨表或跨窗口的条件补充约束声明，最后统一用规则引擎语法注册并绑定元数据。

需要特别注意的是，形式化表达不等于越复杂越好。制造数据质量规则的目标是稳定执行和清晰归因，而不是追求表达力极限。对于简单规则，一条断言加必要元数据即可；对于复杂业务逻辑，再引入约束组合和引擎编排。保持规则粒度适中、命名一致、版本可追溯，比堆叠复杂语法更能提升数据质量治理的实际效果。