2. 排放因子数据模型设计：实体关系建模与范式化权衡
排放因子库是碳足迹数据刷新加速的基石。一个设计不良的数据模型会导致查询缓慢、数据冗余、维护困难，最终拖累整个碳足迹计算管线的性能。本章从实体关系建模出发，深入分析因子、来源、区域、时间四个核心实体的关联方式，并探讨范式化与反范式化在性能与一致性之间的权衡策略。
2.1 核心实体与关系定义
排放因子库至少需要管理以下四个核心实体：
- 因子（Factor）：排放因子的主体，包含因子名称、单位、数值、温室气体类型（CO₂、CH₄、N₂O 等）、数据质量等级等属性。
- 来源（Source）：因子的出处，如 IPCC 指南、EPA 数据库、行业报告、实测数据等，包含来源名称、版本、发布年份、可信度评分。
- 区域（Region）：因子适用的地理范围，如国家、省份、流域、气候带，包含区域编码、名称、层级关系。
- 时间（Time）：因子的有效时间窗口，包含起始年份、结束年份、数据采集年份、时效性标签。
实体间的核心关系为：一个来源提供多个因子，一个因子适用于多个区域，一个因子在不同时间窗口可能有不同取值。这种多对多关系需要通过关联表来解耦。
设计要点： 不要将来源、区域、时间直接作为因子表的字段。这会导致大量重复存储，且当来源信息更新时，需要扫描全表修改，极易产生数据不一致。
2.2 范式化模型设计（3NF）
遵循第三范式（3NF）的模型能最大限度消除数据冗余，保证数据一致性。以下是范式化设计的核心表结构：
| 表名 | 主键 | 核心字段 | 外键 |
|---|---|---|---|
| factor | factor_id | name, unit, gas_type, quality_grade | — |
| source | source_id | name, version, publish_year, credibility_score | — |
| region | region_id | code, name, parent_region_id | parent_region_id → region.region_id |
| time_period | time_id | start_year, end_year, collection_year, label | — |
| factor_value | factor_value_id | value, uncertainty, unit_convert_factor | factor_id, source_id, region_id, time_id |
其中 factor_value 是核心事实表，通过四个外键关联维度表，记录每个因子在特定来源、区域、时间下的具体数值。这种设计使得维度数据只需存储一次，更新来源名称或区域层级时，只需修改一行记录。
2.3 范式化的性能瓶颈
范式化模型在写入一致性和存储效率上表现优异，但在碳足迹数据刷新场景下，存在明显的性能瓶颈：
- 多表 JOIN 开销：每次查询因子数值时，必须关联 4~5 张表。当因子库规模达到百万级记录时，JOIN 操作会成为查询瓶颈。
- 维度表频繁访问：区域层级查询（如“查找某省份下所有城市的因子”）需要递归或多次 JOIN，在 OLAP 场景下尤其低效。
- 时间范围过滤复杂：时间维度的范围查询（如“查找 2018-2022 年有效的因子”）在范式化模型中需要额外的谓词下推优化。
避坑提示： 不要为了追求理论上的完美 3NF 而忽略实际查询模式。在碳足迹数据刷新场景中，90% 的查询是“给定因子名称+区域+年份，获取数值”，这种查询模式强烈建议做反范式化优化。
2.4 反范式化策略与权衡
反范式化通过引入冗余字段或合并表来减少 JOIN，以查询性能换取存储空间和写入复杂度。以下是三种常用策略：
| 策略 | 做法 | 优势 | 代价 |
|---|---|---|---|
| 字段冗余 | 在 factor_value 表中直接存储 source_name、region_name、time_label | 单表查询，无需 JOIN | 维度更新时需同步冗余字段，存储膨胀 30%~50% |
| 预聚合宽表 | 按常用查询维度（如区域+时间）预计算并存储因子值 | 查询速度极快，适合固定维度的报表 | 灵活性降低，维度组合爆炸时存储失控 |
| 嵌套结构 | 使用 JSON/STRUCT 类型存储来源和时间的复合信息 | 减少表数量，适合半结构化数据 | 查询语法复杂，索引效率低，不适合高频更新 |
2.5 实体关系与反范式化权衡的 SVG 架构图
下图展示了范式化模型与反范式化模型的实体关系对比，以及数据刷新时的查询路径差异：
2.6 混合模型：范式化与反范式化的融合实践
在实际工程中，纯范式化或纯反范式化都难以满足所有场景。推荐采用混合模型：
- 基础存储层采用 3NF：保证数据一致性和更新灵活性，维度表只存一份。
- 查询加速层采用宽表或物化视图：按碳足迹数据刷新的典型查询模式（因子+区域+时间）预构建宽表，定期从范式化基础表刷新。
- 使用增量刷新策略：只同步变更的因子数据到宽表，避免全量重建。
实践建议： 在 PostgreSQL 中可以使用
MATERIALIZED VIEW 实现宽表，配合 REFRESH MATERIALIZED VIEW CONCURRENTLY 实现无锁刷新。在 MySQL 中可以通过定时 ETL 任务将范式化数据写入反范式化缓存表。
2.7 数据刷新场景下的模型选择矩阵
下表总结了不同场景下数据模型的选择建议：
| 场景 | 推荐模型 | 原因 |
|---|---|---|
| 因子数据批量导入（首次加载） | 范式化（3NF） | 避免重复数据，便于数据质量校验 |
| 单因子数值查询（OLTP） | 反范式化宽表 | 毫秒级响应，无需 JOIN |
| 区域层级聚合查询（OLAP） | 范式化 + 递归 CTE | 区域维度表支持层级遍历，宽表难以处理动态层级 |
| 碳足迹批量计算（批量刷新） | 反范式化宽表 + 批量索引 | 减少 JOIN 开销，利用索引覆盖扫描加速 |
| 来源信息批量更新 | 范式化（3NF） | 一次更新维度表，所有关联因子自动生效 |
2.8 实体关系建模的最终权衡 SVG 决策图
下图展示了从需求分析到模型选型的决策流程，帮助你在范式化与反范式化之间做出合理选择：
2.9 本章小结
- 排放因子数据模型的核心实体包括 因子、来源、区域、时间，通过事实表 factor_value 关联。
- 范式化（3NF） 保证数据一致性和更新灵活性，但查询需要多次 JOIN，在批量刷新场景下性能不足。
- 反范式化（宽表） 将维度字段冗余到事实表，查询速度提升 5~10 倍，但存储膨胀 30%~50%，维度更新时需要同步冗余字段。
- 混合模型 是工程最佳实践：基础层用 3NF 保证一致性，加速层用宽表或物化视图提升查询性能，通过增量刷新策略平衡写入与读取开销。
- 模型选择应基于实际查询模式、更新频率和存储成本，没有银弹，只有权衡。