多源维度模型扩展咨询：新增非通用维度的设计方案

针对已投产的线上/线下零售销售模型，要给线上新增channel维度、线下新增jobcode维度且二者互不通用的需求，提供以下几种可行设计方案：

方案一：事实表新增允许NULL的维度键字段 #

这是最轻量化的改造方案，适配现有投产系统的最小侵入性原则：

• 在现有sales事实表中新增两个字段：channel_key（关联线上channel维度表）和jobcode_key（关联线下jobcode维度表），两个字段均设置为允许NULL。
• 数据加载规则：当source='线上'时，填充channel_key，jobcode_key留空；当source='线下'时，填充jobcode_key，channel_key留空。
• 维度表单独维护：分别创建dim_channel（存储线上渠道编码、名称、所属平台等属性）和dim_jobcode（存储线下岗位编码、岗位名称、职级等属性）两个独立维度表。

优点：

• 无需修改现有事实表的核心结构，ETL改造工作量小，投产周期短。
• 兼容历史数据，历史线上数据可通过补数逻辑填充channel_key，线下数据同理。
• 上层报表只需新增维度关联逻辑，无需大范围调整。

缺点：

• 事实表存在冗余的NULL字段，但在数据仓库场景中属于可接受的设计，可通过source字段过滤避免无效关联。

方案二：拆分事实表为线上/线下专属表 #

如果业务对数据结构的纯净性要求较高，可选择拆分事实表：

• 将原sales事实表拆分为online_sales_fact和offline_sales_fact两个事实表：
  • online_sales_fact保留原有维度键（date_key、teammember_key、division_key、store_key），新增channel_key。
  • offline_sales_fact保留原有维度键，新增jobcode_key。
• 原sales表可保留作为历史归档表，或创建视图v_sales将两个拆分表union对外提供统一查询入口。

优点：

• 事实表结构清晰，无NULL字段，避免无效维度关联。
• 后续线上/线下业务扩展可独立进行，互不影响。

缺点：

• ETL流程需大幅改造，包括数据拆分、同步逻辑调整，投产周期较长。
• 现有报表、BI工具需适配新的数据源，若依赖原sales表需修改查询逻辑。

方案三：退化维度直接存储字段（适合属性简单的场景） #

如果channel和jobcode仅为枚举值、无额外属性需要维护，可直接将字段存入事实表，无需创建独立维度表：

• 在sales事实表中新增channel（字符串类型，如"微信商城"、"淘宝旗舰店"）和jobcode（字符串类型，如"S001"、"S002"）字段，允许NULL。
• 数据加载时根据source字段填充对应字段，另一字段留空。

优点：

• 无需维护额外维度表，设计和实现最简单。
• 查询时无需关联维度表，性能更优。

缺点：

• 若后续需要给channel或jobcode添加属性（如渠道负责人、岗位薪资范围），需重构为维度表，扩展性差。
• 字段值若出现重复或拼写不一致，需在ETL阶段做严格校验。

通用注意事项 #

• 数据回溯：针对历史数据，需根据业务规则补全新增字段的值（如线上历史订单可通过订单来源日志匹配channel，线下可通过员工档案匹配jobcode）。
• ETL适配：修改数据加载逻辑，新增维度数据的同步流程（如dim_channel需从线上渠道管理系统同步数据）。
• 报表兼容：若采用拆分事实表方案，建议创建统一视图封装底层结构，减少上层应用的修改量。

内容的提问来源于stack exchange，提问作者pam