3. 排放因子库架构设计：字段定义与元数据管理

排放因子库是碳排放核算体系的核心数据资产。一个设计良好的因子库，必须从字段定义和元数据管理两个维度同时发力：字段定义决定了因子数据的“骨骼”是否完整，元数据管理则决定了因子数据的“血液”是否可追溯、可信任。本节将围绕燃料类型、单位、热值、碳含量、氧化率五大核心字段，以及配套的元数据管理机制，展开实战级架构设计。

3.1 核心字段定义与设计规范

排放因子库的字段设计需同时满足“数据完整性”和“业务可解释性”。以下为五大核心字段的详细定义与设计规范：

3.2 元数据管理：让因子数据“可溯源、可审计”

元数据是排放因子库的“数据说明书”。没有元数据管理的因子库，本质上只是一堆无法验证的数字。元数据管理应覆盖以下核心维度：

• 来源元数据： 记录因子数据的原始出处（如 IPCC 指南、国家清单、行业实测、文献引用），包括来源名称、版本号、发布年份。
• 版本元数据： 每次因子更新必须记录版本号、更新日期、更新人、变更说明，支持版本回滚与差异比对。
• 质量元数据： 对因子数据进行质量评级（如高/中/低），记录数据质量评估指标（如样本量、标准差、置信区间）。
• 适用性元数据： 标注因子适用的行业范围（如电力、钢铁、水泥）、工艺类型（如煤粉炉、循环流化床）、地域范围（如全国、省级、特定企业）。
• 审计元数据： 记录数据的创建时间、最后修改时间、审核状态（待审/已审/驳回）、审核人及审核意见。

3.3 字段扩展与多行业适配设计

不同行业的排放因子需求差异显著。基础字段必须支持扩展，才能适配电力、钢铁、水泥、化工等多行业场景。以下为行业适配字段扩展设计：

3.4 元数据驱动的数据质量校验规则

元数据不仅是“标签”，更是数据质量校验的规则引擎。以下为基于元数据的自动化校验规则示例：

• 范围校验： 碳含量必须在 0~1 之间，氧化率必须在 0~1 之间，热值必须大于 0。
• 一致性校验： 同一燃料类型在不同来源中的排放因子差异不得超过 10%（基于质量元数据中的置信区间）。
• 时效性校验： 因子数据的版本年份与当前年份相差超过 5 年时，自动标记为“建议更新”。
• 适用性校验： 当核算对象的行业/工艺/地域与因子的适用性元数据不匹配时，触发警告。
• 审计状态校验： 只有状态为“已审”的因子数据才能用于正式核算报告。

-- 示例：基于元数据的质量校验 SQL 逻辑
SELECT 
    f.factor_id,
    f.fuel_type,
    f.carbon_content,
    m.quality_grade,
    m.confidence_interval,
    CASE 
        WHEN f.carbon_content < 0 OR f.carbon_content > 1 THEN 'FAIL: 碳含量超出范围'
        WHEN m.quality_grade = 'C' THEN 'WARN: 数据质量等级低'
        WHEN m.status != '已审' THEN 'FAIL: 数据未审核'
        ELSE 'PASS'
    END AS quality_check_result
FROM emission_factors f
JOIN metadata m ON f.factor_id = m.factor_id;

3.5 字段定义与元数据管理的协同设计

字段定义与元数据管理不是孤立的两个模块，而是需要协同设计的整体架构。以下为协同设计的核心原则：

1. 字段定义驱动元数据采集： 每个核心字段在定义时，必须同步定义其元数据采集规则（如来源、版本、质量等级）。
2. 元数据反哺字段质量： 元数据中的质量评级、审计状态等信息，可用于动态调整字段的权重或使用优先级。
3. 版本管理覆盖字段变更： 当字段定义发生变更（如新增字段、修改单位）时，必须通过版本元数据记录变更历史，确保数据可追溯。
4. 适用性元数据指导字段选择： 在多行业适配场景中，根据适用性元数据自动匹配最合适的字段组合与因子值。

通过字段定义与元数据管理的协同设计，排放因子库不再是静态的“数值表”，而是具备自我校验、版本追溯、行业适配能力的动态数据资产。这是实现多行业碳排放核算数据核验的基础保障。