维度建模（四）

事实表与维度表的高级技术

一、事实表高级技术

1.1 事实表代理键

• 代理键可用所有维度表的主键复合，可使用单列代理事实键，但没有什么必要这么做
• 不与任何维度表做关联的代理键是ETL过程中顺次生成的：
  1. 可作为事实表的唯一主键
  2. ETL过程中可作为事实表的行的直接标识，不必查询多列
  3. 允许将事实表的更新操作分解为风险更小的插入和删除操作

1.2 蜈蚣事实表

• 对多对一层次的每层建立不同的规范化维度，如日期、周、月、季度、年度，并将这些维度全都放入事实表中
• 上述操作就会产生蜈蚣事实表，包含与维度相关的多个维度
• 应避免使用蜈蚣事实表，而是将关联的多个维度化为最细粒度的维度
• 若将多个外键嵌入单一粒度的事实表，而不使用杂项维度时，也会产生蜈蚣事实表

1.3 属性或事实的数字值

• 某些数字值很难确定该为维度还是度量，例如产品的单价
• 若用于计算，则可算作度量，属于事实表
• 若用于过滤或分组，则算作维度，属于维度表，离散数值可用范围补充
• 某些情况将数字值既建模为维度，也建模为属性是有益的

1.4 日志/持续时间事实

• 累积快照事实表中存在多个过程里程碑，每个都包含日期/时间戳外键
• 有时需要分析里程碑间的滞后或延迟，有些可能只是时间的差别，而有些基于更复杂的业务规则
• 此时可根据过程开始时间点为每一个里程碑存储一个时间延迟，方便计算两个里程碑间的延迟

1.5 头/行事实表

• 操作型交易系统通常包含事务头指针行，头指针行与多个事务行关联
• 采用头/行模式（也称父/子模式）的表在事实表建模时，所有头指针行的外键与退化维度，都应该被包含在相关的事务行中

1.6 分配的事实

• 头指针/行事务数据与对应的事实粒度不同是常发生的
• 应尽量分配头指针事实，使其按业务规则划分为行级别，分配的事实可按所有维度进行分片和上钻
• 多数时候应避免建立头指针级别的事实表，除非有查询性能的提高

1.7 利用分配建立利润与损失事实表

• 用事实表揭示利润等价方程：利润 = 收入 - 开销
• 理想的实现利润方程的事实表应包含原子事务粒度的收入和多个开销项
• 如此便需要将开销项按事实表粒度从原始来源划分出来，通常由ETL完成，需要业务人员参与
• 因此利润与损失事实表在数仓早期通常不做处理

1.8 多种货币事实

• 此类事实在事实表中应包含多列
• 其中一列记录真实交易币种的事实，并配置一列标明行的真实交易币种
• 其他列记录另外的币种，ETL过程按汇率等转化规则由真实币种计算得来

1.9 多种度量事实

• 针对业务需要以多种单位同时存储同一事实的场景，如供应链可能会按客户需求对相同事实按平台、货运、零售和单个扫描单元来构建报表
• 事实表中只存储以公认的标准单位表示的事实
• 同时必须在事实表的行中存储不同单位的转换系数，以确保计算及查询简单正确

1.10 YTD事实

• 针对商业系统需要在事实表中获取year-to-date（YTD）值的场景
• 但是YTD很容易变换为财务周期YTD或财务周期日
• 更好的方法是在OLAP系统中计算YTD矩阵cube，而不是在事实表中查询并计算YTD值

1.11 避免事实表间的关联

• 两个实时表不应该直接使用外键进行关联，如产品的出货和退货事实不可以按用户和产品外键直接关联
• 应采用跨钻方式使用这两张事实表

1.12 针对事实表的时间跟踪

• 三种基本事实表粒度：事务粒度、周期快照、累积快照
• 在事实表中增加行有效开始日期、行截止日期、最新行标识，以解决缓慢变化事实的场景，如缓慢变化库存平衡

1.13 迟到的事实

• 指新事实行产生时多数当前维度内容无法匹配新事实的情况
• 此时必须搜索相关维度以发现有效的维度

二、维度表高级技术

2.1 维度表连接

• 维度表可以包含到其他维度表的引用，可以采用支架维度建模实现
• 但是支架维度中的类型2变化会强制基本维度表做修改，可能会引起基本维度表的爆炸性增长
• 处理这一问题可以将支架维度的外键放入事实表而不是基本维度表，可以减少维度之间的关联，仅需遍历事实表

2.2 多值维度与桥接表

• 经典的维度表中，每个与事实表关联的维度都有与事实表粒度相同的唯一值
• 但是维度表是允许存在合理的多值的（即事实表的一行对应维度表多行），此时必须有多个维度键通过桥接表使每个维度值与事实表的一行关联
• 事实表中存储桥接表外键，桥接表中存储一组事实表行对应的维度外键

2.3 随时间变化的多值桥接表

• 多值桥接表可能会需要基于类型2的变化
• 此时就需要在桥接表中加入行的有效起始日期/时间戳，也可同时加入最新行标识
• 在查询中通过约束桥接表获取某一时刻的正确数据（一致性快照）

2.4 标签的时间序列行为

• 数据挖掘客户聚类分析通常会产生文本化的行为标签
• 跨时间范围的客户行为度量成为由这些标签构成的序列，该时间序列应以位置属性被存储于客户维度中，包含可选文本串，构成完整的序列标签

2.5 行为研究分组

• 对于复杂的用户行为分析结果，可设置研究分组表（仅包含客户的持久键）
• 在查询时通过约束研究组表的列与目标模式中客户维度的持久键，作为一种可用于任何带有客户维度的维度模式过滤器
• 可以设立多个研究组，研究组可以通过遍历、联合、设置差异等方式建立

2.6 聚集事实作为维度属性

• 商业用户通常对聚集事实的客户维度感兴趣，如某阶段花费超过一定数额的客户
• 聚集事实维度可以作为报表约束条件和行标识，通常表示为维度表中的带状范围

2.7 动态值范围

• 动态值范围报表由一些列报表行头组成，这些报表行头为目标事实数值范围不断变化的集合，如：0_{$10的平账，$10.1}$25的平账
• 此类报表是动态报表，每次查询都定义了特定的行头
• 行定义可通过范围维度表实现，使用大于连接或者小于连接与事实表连接，定义可仅存在于case语句中

2.8 文本注释维度

• 对于自由注释，与其作为事实表的文本度量，不如将其分解存储到事实表以外不同的注释维度
• 或者作为维度属性，每个事务一行，但注释粒度需满足唯一事务的数目
• 注释维度对应事实表中的一个外键

2.9 多时区

• 在事实表为不同时区设置多个外键，连接不同时区的日期、当天时间维度表

2.10 度量型维度

• 事实表每行包含一长列稀疏存储的事实时，可以建立度量类型维度，将事实表行变成单一通用事实
• 不推荐使用，此法虽然消除了所有空的事实表列，但增大了事实表大小，使内部计算更复杂
• 当潜在事实达到极限（几百个）但不需要应用到任何事实表时，可采用此法

2.11 步骤维度

• 序列过程，如Web页事件，通常在事务事实表中用不同行表示过程中的每一步
• 使用步骤维度展示当前步骤的步骤号以及该会话共有多少步骤

2.12 热交换维度

• 当同一事实表与相同维度表的不同拷贝交替搭配时，可使用热交换维度
• 热交换维度：对于不同的用户，不会让他们看到某维度的全部信息，故一个维度可以定制多个不同版本，在查询时根据当时的需要选择一个适合的版本

2.13 抽象通用维度

• 将某类维度抽象到同一个维度表的模式，如将雇员、客户、供应商全部抽象到人员维度
• 可能导致形成大型维度表，且每种类型的关联属性通常存在差异，对维度模型的易读性有负面影响，应尽量避免

2.14 审计维度

• 事实表行是在ETL之后建立时，可建立对已知ETL过程元数据的审计维度
• 审计维度：
  • 包含了事实表变更的元数据，事实数据的加载时间，数据质量指标
  • 元数据：数据源是哪里，在什么时间加载，是用哪个过程加载，加载时所用的规则是什么
  • 数据质量和统计：读取了多少行记录，插入了多少行，拒绝了多少行。事实数据是否完整，事实表的值是否在有效区域内

2.15 迟到的维度

• 操作型业务过程的事实比关联维度早几分钟、小时、天或周产生，维度属性可能还无法确定
• 可以使用未分解的自然键作为主键，建立特殊的占位维度行。这些维度还必须要包含通用未知值，用于描述性维度属性，合适的维度会在晚些时候从数据源获得
• 在获得维度内容时，占位维度行用缓慢变化维类型1重写
• 如果是当采用缓慢变化维类型2的维度表，此时需要插入新行记录最新状态，然后重新定义关联事实行

三、特殊目的模式

3.1 异构产品的超类与子类模式

• 对不同业务类型的商业产品，如银行的各种不同类型的账目，可用此模式
• 创建单一的超（父）类事实表，存储所有子类事实的公共度量，并创建包含公共属性的公共维度表
• 然后系统化的为每个子类创建单独的事实表，存储子类特有的度量，并创建包含子类属性的维度表

3.2 实时事实表

• 需要比传统的夜间批处理过程更频繁的更新

3.3 错误事件模式

• 数仓数据质量管理的综合性系统，记录数据质量错误
• 将数据质量检测出的错误记录到特殊的维度模式中，该模式仅能被ETL系统后台
• 包含错误事实表，粒度为单独错误事件，以及错误事件详细事实表，粒度为参与错误事件的每个表中的列