支架维度是什么
支架维度是被其他维度引用的维度，是雪花化的直接产物：商品维度里不直接存类目名称，而是存一个类目键，指向独立的类目维度。这样类目属性只需维护一份，改一次就能影响全部引用方；代价是查询多一层 join，自助分析时 join 路径变长。星型模型中应尽量控制支架数量，只有在复用面广、层次深且变更频繁时才值得保留。
基本信息
| 来源 | 维度与维度之间的引用关系 |
|---|---|
| 典型形态 | 商品引用类目、门店引用区域、员工引用组织 |
| 控制原则 | 能冗余则冗余，支架越少越好 |
| 保留条件 | 复用面广、层次深、变更频繁三者同时成立 |
典型使用场景
- 类目体系独立维护：类目结构由商品中台统一下发，多张商品维度表都要引用
- 组织结构调整：员工维度引用组织维度，架构变动时只需更新一处
- 区域层级治理：门店引用区域后，区域口径在所有报表中天然一致
- 层次深且共享：类目到五级的深度不适合冗余进商品维度，保留支架更省空间
- 变更频繁场景：属性每周都在调整时，支架维度的单点维护优势明显
支架维度查询
支架维度查询
-- dim_product 通过 cat_key 引用 dim_category（支架关系）
SELECT c.l1_name, -- 类目维度：一级类目
p.brand, -- 商品维度：品牌
sum(f.amt) AS amt
FROM fact_sale f
JOIN dim_product p ON f.product_sk = p.product_sk -- 第一层：事实到商品
JOIN dim_category c ON p.cat_key = c.cat_key -- 第二层：商品到类目
GROUP BY 1, 2; -- 多一层 join 换取类目口径唯一保留还是冗余
| 判断项 | 保留支架 | 冗余进主维 |
|---|---|---|
| 复用广度 | 多个维度表都要引用同一层次 | 仅一张维表使用 |
| 层次深度 | 四级以上且成员多 | 一两层且成员少 |
| 变更频率 | 频繁调整，需单点生效 | 基本稳定，改动能接受重刷 |
| 使用门槛 | 团队熟悉多表 join | 业务方自助查询为主 |
支架维度与雪花是一体两面：建了支架就等于把星型局部变成雪花。判断标准是复用广度与变更频率，而不是教科书上的规范化程度。
支架链路过长时，自助分析工具里的表关系图会变得难以理解，使用者经常漏 join 导致数字偏大或偏小，这比多占一些存储的代价更高。