核心概念与模型结构
基本组件
- 事实表 (Fact Table)：
- 多维模型的核心，记录业务事件的度量值（可量化数据）。
- 度量值：通常为数值型（可加、半加、不可加），是分析的对象。
- 外关键字 (FK)：连接维度表，组合构成事实表的主键。
- 粒度 (Granularity)：事实表中一行所代表的含义（如：每一笔POS交易中的单个商品条目）。
- 维度表 (Dimension Table)：
- 入口：是用户查询、筛选和报表分组的“列”。
- 属性：文本型或离散数据，提供描述性信息（如：日期、产品名、商店地址）。
- 特点：列多行少（相对于事实表），属性高度反规范化。
- 融合：通过外键将维度表和事实表连接起来（见下方的星型模型）。
常见模型架构
| 模型类型 |
特点 |
适用场景与优缺点 |
| 星型模型 (Star Schema) |
事实表居中，维度表直接挂接（无中间层）。 |
优点：连接简单，查询性能高（低开销），支持物理加速。缺点：数据冗余大。 |
| 雪花模型 (Snowflake Schema) |
维度表被进一步规范化（拆分为子维度表）。 |
优点：节省存储空间。缺点：表关系复杂，连接开销大，降低浏览性能。 |
| 星座/星系模型 |
多个事实表共享一组一致性维度表。 |
企业级数据仓库总线结构的基础，用于跨主题分析。 |
维度建模的四步设计过程
- 选取业务处理过程：确定分析的主题（如：零售营销、库存管理）。
- 定义粒度 (Defining Granularity)：确定事实表中每一行代表什么（最关键的一步）。例如：是每个POS事务，还是每个POS事务中的单品？粒度越细，分析能力越强。
- 选定维度 (Choosing Dimensions)：确定描述业务的环境（Who, When, Where, What, How）。
- 选定事实 (Identifying Facts)：确定度量值（如：销售量、销售额、成本额）。
三种核心事实表模型 (案例：库存与订单)
根据业务需求，事实表可以分为三种类型，适用于不同的分析场景：
事务事实表 (Transaction Fact)
- 粒度：每个事务事件一行。
- 适用场景：记录离散的操作（如：每次商品出库、每次订单生成）。
- 加载方式：插入 (Insert)。
- 更新策略：不重新存取旧行。
- 日期维度：包含事务发生日期。
- 示例：POS零售营销事务表（记录每笔销售）、库存事务表。
周期快照事实表 (Periodic Snapshot Fact)
- 粒度：每段固定时间（如每天）一行。
- 适用场景：记录规律性的状态（如：每日库存水平、银行账户每日余额）。
- 加载方式：插入 (Insert)。
- 更新策略：不重新存取旧行（但会不断插入新行）。
- 日期维度：包含周期结束日期。
- 关键概念：半加型事实。
- 含义：度量值只能在部分维度上相加。
- 示例：“库存量”可以在“产品”或“商场”维度上相加，但不能跨越“日期”维度相加（1月1日库存 + 1月2日库存 无意义）。
- 处理：对于不可加的度量值，通常采用平均、统计等方法。
- 示例：商场库存周期快照、货栈库存周期快照。
累积快照事实表 (Accumulating Snapshot Fact)
- 粒度：每个生命周期（如一个订单、一次装运）一行。
- 适用场景：跟踪具有明确起止点的流程（如：订单从生成到发货、入库到出库的生命周期）。
- 加载方式：插入 (Insert) + 更新 (Update)。
- 更新策略：随着流程推进，不断地更新该行的状态与日期外键。
- 日期维度：包含多个标准关键环节的日期（角色扮演维度：如订单日期、加工日期、装运日期、发票日期）。
- 特点：事实表数据密集，能直观计算各环节的时间差（如：订购到发货延迟）。
- 示例：仓库库存累积事实、订单作业累积事实。
三种模型对比总结
| 特征 |
事务粒度 |
周期快照粒度 |
累积快照粒度 |
| 代表的时间段 |
时间点 |
规律性可预见间隔 |
不确定时间跨度（短期） |
| 事实表加载 |
插入 |
插入 |
插入与更新 |
| 事实行更新 |
不重新存取 |
不重新存取 |
任何时候都要重新存取 |
| 日期维度 |
事务发生日期 |
时间段终止日期 |
标准关键环节的多个日期 |
| 事实内容 |
事务活动 |
预定时间间隔的性能 |
给定生命期的性能 |
高级维度设计技巧
退化维度 (Degenerate Dimension)
- 定义：维度表为空，具体的维度值（如订单编号、发票编号）直接存放在事实表中。
- 作用：用于将事务细节分组，或反向连接回操作型系统。
杂项维度 (Junk Dimension)
- 定义：将一堆低基数（取值少）、互不相关、且不方便归入其他维度的标志位（如：支付类型、订单类型、是否代办）组合成一个单独的维度表。
- 目的：避免事实表膨胀（不加改变地留在事实表中）或维度表膨胀（每个标志建一个表）。
角色扮演维度 (Role-Playing Dimension)
- 定义：同一个物理维度表在同一个事实表中被多次引用，扮演不同角色。
- 实现：后台维护一个标准维度表（如日期表），前端通过建立多个视图 (View) 来区分不同角色（如：
Order_Date_View、Ship_Date_View、Invoice_Date_View）。
- 优点：节省存储空间，保持一致性。
维度表的属性体系结构 (Attribute Hierarchies)
- 反规范化 (星型)：将体系的各个层级（如：SKU -> 小类 -> 大类 -> 部门）扁平化存入同一张维度表。
- 规范化 (雪花型)：将体系层级拆分为独立的维度表（如：产品维表、小类维表、大类维表）。
- 选择标准：是否需要跨主题共享维度？如果是，建议适度规范化（雪花）以节省空间并便于共享。但为了查询性能，通常保持星型结构。
维度支架 (Dimension Outrigger)
- 定义：从主维度表（如客户维度）延伸出一个次级维度表（如：县人口统计支架维度）。
- 作用：用于连接低基数的属性集，或将外部数据（如人口统计数据）附加到现有维度上。
- 特点：粒度与主维度不同，通过视图可隐藏使其在逻辑上像星型结构。
数据仓库总线与一致性 (DW Bus Architecture)
总线矩阵 (Bus Matrix)
- 结构：
- 行：代表业务处理过程/主题（如：零售营销、库存快照）。
- 列：代表共享的公共维度（如：日期、产品、商场）。
- 作用：规划企业级数据仓库架构，明确哪些维度是在多个主题间共享的。
- 核心：跨主题共享的维度必须完全一致。
- 特征：
- 层级：
- 原子型维度：最细粒度的定义（如：单个产品）。
- 上钻维度 (Roll-up)：原子型维度的子集（如：商标维度）。如果上钻维度是原子维度的严格子集，则视为一致。
- 定义：在不同事实表（或数据备份）中，同一种度量值的定义、单位、计算方法必须保持一致。若无法一致，则需赋予不同名称。
客户关系管理 (CRM) 中的特殊问题
客户维度的特点
- 行数极多：通常数百万行。
- 属性极多：姓名地址解析（拆分为多个片段）、日期属性、分类属性、聚集属性。
渐变维度 (Slowly Changing Dimensions - SCD)
当维度属性值随时间发生变化时（如客户搬家、产品换部门），有几种处理策略：
| 类型 |
策略名称 |
做法 |
特点 |
| Type 1 |
改写属性值 |
直接覆盖旧值 |
优点：简单；缺点：丢失历史数据，无法按旧属性分析历史事实。 |
| Type 2 |
添加维度行 |
新增一行记录新值，旧行保留 |
优点：准确跟踪历史，保留历史一致性；缺点：维度表膨胀。 |
| Type 3 |
添加维度列 |
增加一列保存旧值（如“前部门”） |
优点：可查看新旧对比；缺点：只能保存最近一次变化，不可无限扩展。 |
| Type 6 |
混合型 |
结合1+2+3 |
综合以上特点，对空间要求较高，但分析最灵活。 |
快变维度 (Rapidly Changing Dimensions)
- 挑战：属性变化极快，用 Type 2 会导致维度表极速膨胀。
- 解决方案：微型维度 (Mini-Dimension)。
- 将变化快的属性（如：年龄、收入等级、信用等级）剥离出来，形成独立的微型维度表。
- 做法：将连续值离散化（如收入分为 5 个档次）。将每种属性组合作为一行。
- 优点：独立于庞大的客户维度，查询性能高。
深度可变体系 (Variable Depth Hierarchy)
- 挑战：组织结构或客户关系是树形结构，且层次深度不固定。
- 解决方案：桥接表 (Bridge Table)。
- 在客户维度和事实表之间增加一张桥接表，记录父节点与子节点的关系。
- 自顶向下：维度表对应父节点（查询下属）。
- 自下向上：维度表对应子节点（查询上级）。
其他设计考虑
- 多货币与计量单位：
- 多货币：建立货币转换事实表，包含源货币、目标货币、兑换率和日期。
- 多计量单位：在事实表中加入转换因子（如：盎司转磅），存储后在视图中计算。
- 事实表的规范化：
- 策略：尽量避免将事实表拆分为多个单度量表。
- 例外：当不同度量值的粒度不同时（例如：订单总折扣在标题级，而销售量在分列项级）。
- 解决方案：尽可能将粗粒度事实向下分配（Assign）到细粒度，保持同一粒度。
- 实时分区 (Real-Time Partition)：
- 场景：在常规静态仓库前建立动态分区，以容纳当天/实时数据。
- 三种形式：事务粒度、周期快照、累积快照。需保证与静态仓库的无缝连接。