维度表技术原创
# 维度表结构
包含单一主键列，维度表通常比较宽的扁平化非规范表，包含大量的低粒度文本属性。操作代码与指示器可作为属性对待。维度表属性是查询及BI应用的约束和分组定义的主要目标。报表的描述性标识通常是维度表属性领域值。
图1-产品维表
# 维度代理健
维度表中的唯一主键，不是操作型系统的自然间，一般是无语义的整形自增主键。日期维度不需要遵循代理键规则，可采用更有意义的主键。
# 自然键、持久键和超自然键
当雇员重新入职会分配不同的雇员号码，则雇员号码为自然键，如果数仓希望创建单一键不因为入职影响，则这个为持久键或者超自然键。
# 下钻
在查询上增加一个行头指针，对应一个维度属性，附加GROUP BY表达式。属性可以来自任何与查询使用的事实表关联的维度。
# 退化维度
若维度除了主键外没有其他内容，例如当某一发票包含多个数据项时，数据项事实行继承了发票所有描述性维度外键，发票除了外键外无其他项。但发票数量任然是在此数据项级别的合法维度键。这种退化维度被放入事实表中，清楚地表明没有关联的维度表。常见于交易和累计快照事实表。
如订单事实表中的订单编号则是一个退化维度，同时支付方式也可以作为一个退化维度：
图2-订单事实表
被认为是退化维度的原因：
- 不需要单独维度表：订单编号通常没有其他需要描述的属性，不会随时间变化。
- 直接存储在事实表中，是业务的自然标识符，经常用于查询过滤，可能直接打印在报表上。
其他常见的退化维度示例：交易编号、票据编号、发票号码、运单号、合同编号、申请单号、索赔编号
主要特点：直接来自业务单据、无额外属性、高频使用、低基数性。
# 非规范化扁平维度
维度建模需要抵制规范化设计，将非规范化的多对一固定层次引入扁平维度行的不同属性，可实现设计简化及访问速度提升。
下面是商品到类目到行业的规范化设计：
图3-商品层次关系图
上面的设计在关系型数据库使用是正确的，但是在数据仓库中规范化的设计难以理解，计算复杂，可以改成以下的反规范化形式：
图4-商品层次扁平维表
# 多层次维度
多数维度包含不止一个层次，如日期维度可以按照财务周期层次从天到周划分，也可能存在天到月再到年的参差，位置维度也类似。针对固定层次的维度可以参照上方图4。如果是某些分支的层次不固定，但是总层次固定的情况，可以简化为按固定层次维度进行建模，针对其中层次少的分支进行默认值补充。如以下淘宝商品类目层次关系：
图4-商品类目层次
可以使用以下设计维表（列全5级）：
图5-商品类目扁平化维表
对于递归层次存在高级类目的低级类目属性为空的情况：
表1-扁平化设计对于高等级层次存在空值情况
如类目ID等于21为一级类目，那他的二级、三级、四级、五级类目都不存在，可以把一级类目的编号存入二级、三级类目中：
表2-扁平化设计对于高等级层次填充至低层级属性
这样做的好处是统计类目ID为21的最近1天GMV针对类目上钻、下钻时不需要指导其所属类目层级；避免了根据某层级ID关联时存在空值的问题，导致比该层级低的类目ID且为叶子节点的数据，如上表121456022所在行如果不补充3级科目为121456022，则按3级科目统计时121456022的类目无法被统计到。
# 文档属性的标识与指示器
令人迷惑的缩写、标识及业务指标使用维度表中文字词含义补充解释。操作代码包含的含义应该分解成不同的维度属性。假设一个字段叫备用字段BAK，里面存储的字符串为"0401100101001"，其中0401为地区号，00101为网点号，001为币种，则应该将其拆解为地区好、网点号、币种3个字段.
# 日历日期维度
连接到事实表的日历日期维度应该使事实表按照熟悉的日期、月份、财务周期和日历上的特殊日期进行导航。不要通过SQL去计算类似复活节这种日期，而是应该在日期维度中存储。日期维度的主键可以用yyyyMMdd表示，而不是代理健。事实表可以添加时间戳，如果有当天时间的分组则需要在事实表添加一个当天时间的维度外键。
图6-日期维表
# 扮演角色的维度
单个物理维度可以被事实表多次引用，每个引用连接逻辑上存在的差异的角色维度。例如事实表可以有多个日期，每个日期通过外键连接不同的日期维度，原则上每个外键表示不同的日期维度视图。最常见的是累积快照事实表内，下方的接收日期、验收日期、入库日期、初始装运日期、最终装运日期都是日期维表的一个视图。。
图7-库存收据累积快照
# 杂项维度
杂项维度是由操作型系统中的指示符或者标志字段组合而成，一般不在一致性维度之列。比如交易订单的交易类型字段，包括充值话费、司法拍卖、航旅等；支付状态、物流状态等，他们在原系统中直接保存在交易表中。
事实表中可能会存在多个类似的字段，如果直接存储会导致事实表过大，单独建立维表又会导致维表过多，如果删除则有人不同意。通常做法是建立杂项维度，多个字段的不同取值组成一条记录，生成代理健存入维表中。
事务型商业过程通常产生一系列混杂的、低粒度的标识和指示器。与其为每个标识或属性定义不同的维度，不如建立单独的将不同维度合并到一起的杂项维度。通常在一个模式中标记为事务型概要维度，不需要所有笛卡尔积，只需要记录实际发生的合并值。
图8-订单标识杂项维度
# 雪花维度
当维度表中的层次关系是规范的时，低粒度属性作为辅助表通过属性键连接到基本维度表，这种建立的多层结构为雪花模式。不要使用雪花模式，扁平化、反规范化的维度表完全能获得同样信息。
# 支架维度
维度可包含对其他维度的引用，这种叫支架维度，如银行账户维度可以引用表示开户日期的维度。尽量少用支架维度，多数维度的关联应该由事实表来实现，在事实表中通过2个维度的不同外键相关联。
图9-产品维度及其产品引入日期支架维度
# 使用一致性维度继承
# 一致性维度
不同维度表的属性具有相同列名和领域内容时，称维度表具有一致性。利用一致性维度属性与每个事实表关联，可将不同事实表的信息合并到同一报表中，实现跨钻。如下报表就是将订单、库存、销售3个事实表按照产品描述跨钻计算而成：
表3-按产品跨钻
# 缩减维度
属于一种一致性维度。①当需要聚集时需要缩减上卷；②获取更高粒度的数据时；③两个维度具有同样粒度级别数据，但其中一个仅是另外一个的部分子集，也需要一致性维度子集。
- 以下日期缩减至月，原因是有共同的属性子集（获取跟高粒度性能度量）
图10-日缩减至月
- 2个维度包含行子集的缩减一致性维度，当跨钻公共一致属性时，2个维度具有相同粒度，且有公共属性时：
图11-相同粒度的一致维度子集
- 当需要聚集时需要缩减上卷，也就是按更粗粒度进行分组。
# 跨表钻取
每个查询行头包含相同一致性属性时，使不同的查询能够针对2个或者更多的事实表进行查询。
# 价值链
用于区分组织中主要业务过程的自然流程，一般操作型原系统通常为价值链上的每个步骤建立事务或者快照。每个过程在特定时间间隔，采用特定的粒度和维度建立唯一度量。
图12-公司价值链
# 企业数据仓库总线架构
将关注的业务过程将数仓规划过程分解为可管理模块，通过重用跨不同过程的标准化一致性维度实现继承，可实现敏捷实现对应企业数据仓库总线矩阵。
# 企业数据仓库总线矩阵
设计与企业数据仓库总线架构交互的基本工具，行表示业务过程，列表示维度。设计时考虑是否为业务过程定义好相关候选维度、某一维度需要跨多个业务过程并保持一致性。
表3-数据仓库总线矩阵
# 总线矩阵实现细节
是一种偏实施细节的表格，数仓总线矩阵每个业务过程行替换为具体事务，并增加列扩展信息：粒度、事实列表。
表4-总线矩阵实现细节
# 机会/利益相关方矩阵
确定数仓总线矩阵后，可通过替换包含业务功能的维度列规划不同的矩阵。通过矩阵点表示哪些业务功能与哪些业务过程相关。
表5-机会/利益相关方矩阵
# 处理缓慢变化维度属性
# 类型0：保留原样
用于属性标记为“原始”的属性，也就是一直不会变的属性，如客户原始积分。
# 类型1：重写
度行中原来属性被新值覆盖，总是反应最近的工作，但破坏了历史情况。
图13-覆盖重写属性
# 类型2：增加新行，拉链表
使用拉链表并且有1列为当前标志。支持用维度历史值关联历史事实、维度最新值关联历史事实。
图14-增加新行
# 类型3：增加新属性
在维表上新增属性以保存原来的属性值，新属性值以变化类型1方式重写主属性，可以利用当前值或者历史值分组过滤事实数据，不太常用。
图15-增加新属性
# 类型4：增加微型维度
当维度中一组属性快速变化并划分为微型维度时采用。微型维度需要自己的唯一主键，及维度和微型维度主键从相关事实表获取。
例如可以为一组不稳定的客户人口统计学属性（年龄、购买频度、积分和收入水平等）建立一个微型维度。每个年龄、购买频度、积分和收入水平的组合在微型维度中用1行表示，而不是采用每个客户1行的方式。微型维度变成人口统计学概要的集合，尽管客户维度包含几百万行，微型维度中的行将显著减少。在建立微型维度时，不断变化的属性（如收入）被转换未带状范围值。
图16-微型维度
拆分后，新的微型维度与客户维度同时连接事实表，而不是通过客户连接，然后统计维度再连接客户维度。
图17-拆分微型维度后与事实表的关系
# 类型5：增加微型维度及类型1支架
用于精确保存历史属性值，建立在类型4微型维度上并嵌入当前类型1引用及维度中的微型维度。当当前维度分配发生变化时，ETL小组需要重写类型1微型维度引用。
主要作用：用当前的属性关联历史的事实表，重新计算。如下图，可以使用客户的当前购买频度重新计算相关指标，只要历史事实关联客户维度，使用客户的当前购买频度属性即可。
图18-人口统计微型维度和类型1支架表
上图中物理实现是数仓有对应的表，包含当前人口统计维度，但是对BI来讲把相关信息合并到客户维度中。事实表原来通过人口统计维度键关联人口统计维度，计算对应指标。如果需要用客户最新的人口统计进行重算历史，则使用客户维度中的当前年龄范围等计算。
# 类型6：增加类型1属性到类型2维度
增加类型1属性到类型2维度。建立在类型2的基础上，同时嵌入维度行属性的当前类型1版本，因此事实行可以被过滤或分组，要么按照当度量发生时有效的类型2属性值，要么按照属性的当前值。当属性发生变化时，类型1属性由系统自动重写与持久键关联的所有行。混合方法为获取类型2建立新行，新增列以跟中当前分配（类型3），后续变化采用类型1响应，1+2+3=6，所以叫类型6。
就是拉链表增加多1列“历史属性”，原来的属性变为“当前属性”，如历史部门名称、当前部门名称。优点是既可以用当前又可以用历史的属性进行重算，但是实现、使用门槛都比较高，需要提前权衡。
图19-类型6变化过程
主要特点：所有行的当前部门名称是统一更新的
# 类型7：双类型1和类型2维度
用于支持过去和现在报表的最后一种混合技术。事实表可以被访问，通过被建模为类型1维度仅仅展示最新属性值，建模为类型2维度展示最新历史概要。维度的持久键和主代理健同时存在事实表上。从类型1角度看，维度的当前标识被约束至当前，通过持久键与事实表连接。从类型2角度看，当前标识无约束，事实表通过代理健主键连接。可通过不同的视图部署到BI应用上。
图20-类型7，包含双重外键，应用于类型1和类型2
图21-类型7变体
其实就是把事实表建立2个外键，1个是常规维度键，1个是不会变的持久键。当需要历史时通过常规维度键关联变化2的维表，限定开始、结束日期。当需要当前时，用持久键关联当前的维度视图获取信息。
这个方法的最大好处时可以基于任何时间点概要上卷历史事实。比如基于去年12月1日开始的有效层次构建3年历史度量报表，按以下步骤：
- 类型2维表限定开始、结束日期，找出去年12月1日有效的所有持久键；
- 通过持久键关联事实表进行上卷，这样历史事实表中12月1日不存在的持久键就不会进行计算，只会计算去年12月1日存在的数据。
类型7与类型6实现的功能相同，但是类型7比类型6的实现简单得多。
# 缓慢变化维总结
| SCD类型 | 维度表行动 | 对事实分析的影响 |
|---|---|---|
| 类型0 | 属性值无变化 | 事实与属性的原始值关联 |
| 类型1 | 重写属性值 | 事实与属性的当前值关联 |
| 类型2 | 为新属性增加新维度行 | 事实将与在事实发生时有效的属性值关联 |
| 类型3 | 增加新列来保存属性当前和原先的值 | 事实与当前和先前属性的交替值关联 |
| 类型4 | 增加包含快速变化属性的微型维度 | 事实与事实发生时有效的变化属性关联 |
| 类型5 | 增加类型4微型维度以及在基本维度中重写类型1微型维度键 | 事实与事实发生时有效的变化属性关联，加上当前快速变化的属性值 |
| 类型6 | 在类型2维度行中增加类型1重写属性，并重写所有先前的维度行 | 事实与事实发生时有效的变化属性关联，加上当前值 |
| 类型7 | 增加包含新属性值的类型2维度行，加上限于当前行和属性值的视图 | 事实与事实发生时有效的变化属性关联，加上当前值 |
表6-缓慢变化维总结
# 处理维度层次关系
# 固定深度或者深度有限的可变深度层次
- 固定深度位置的层次：多对一关系的一种，如从产品到品牌再到分类，到部门。深度固定，层次就具有商定的名字（可以知道如何约束并解释每个层次），层次级别作为维度表中的不同位置属性出现。
如账户维表，包含总经理层账户、业务主管层账户，存在1个下级对应多层上级情况，维表的结构如下：
| 层级ID | 层级名称 | 上级层级ID | 层级深度 | 描述 |
|---|---|---|---|---|
| L1 | 公司 | NULL | 1 | 整个公司层面 |
| L2 | 事业部 | L1 | 2 | 公司下属事业部 |
| L3 | 部门 | L2 | 3 | 事业部下属部门 |
| L4 | 总经理层 | L3 | 4 | 部门总经理层级 |
| L5 | 业务主管层 | L4 | 5 | 下属业务主管层 |
| L6 | 团队负责人 | L5 | 6 | 主管下属团队负责人 |
| L7 | 普通员工 | L6 | 7 | 最基础的员工层级 |
表7-职位层级表结构
每个普通员工（多）对应一个团队负责人，每个团队负责人（多）对应一个业务主管，以此类推。
示例数据如下：
| 账户ID | 账户名称 | 所属层级ID | 上级账户ID |
|---|---|---|---|
| A001 | 张三 | L7 | A010 |
| A010 | 李四团队 | L6 | A100 |
| A100 | 王五主管 | L5 | A200 |
| A200 | 赵六总经理 | L4 | A300 |
| A300 | 市场部 | L3 | A400 |
| A400 | 销售事业部 | L2 | A500 |
| A500 | XX公司 | L1 | NULL |
表8-账户维表-账户及其上级账户
- 轻微参差不齐/可变深度层次：没有固定深度，但层次深度有限。地理层次深度通常包含3到6层。可将其变换为固定深度位置设计，针对不同的维度属性确定最大深度，然后基于业务规则放置属性值。
如地理层级，存在3种可能：最简单的为地址、城市、州和国家；复杂一点的增加了区域，最复杂的增加了区和区域级别。可以对缺的层级进行填充，如地址、城市、州和国家的情况，把区、区域都填充为城市属性。
表9-轻微可变层级-地区维表
# 桥接表的参差不齐/可变深度层次
可通过再关系型数据库中采用构建桥接表方式建模参差不齐层次来解决。桥接表对每个可能的路径保留一行，确保能够遍历所有层次的形式。
图22-组织层级桥接关系
典型的父子递归设计：
图23-组织层级桥接关系
按桥接表结构表示以下层级：
图24-示例层级关系
对应的表数据存储如下：
| 父组织键 | 子组织键 | 距离父组织的层次 | 最高层父节点标识 | 最低层子节点标识（叶子节点） |
|---|---|---|---|---|
| 1 | 1 | 0 | T | F |
| 1 | 2 | 1 | T | F |
| 1 | 3 | 2 | T | T |
| 1 | 4 | 2 | T | F |
| 1 | 5 | 3 | T | T |
| 1 | 6 | 3 | T | T |
| 1 | 7 | 1 | T | F |
| 1 | 8 | 2 | T | T |
| 1 | 9 | 2 | T | F |
| 1 | 10 | 3 | T | F |
| 1 | 11 | 4 | T | T |
| 1 | 12 | 4 | T | T |
| 1 | 13 | 3 | T | T |
| 2 | 2 | 0 | F | F |
| 2 | 3 | 1 | F | T |
| 2 | 4 | 1 | F | F |
| 2 | 5 | 2 | F | T |
| 2 | 6 | 2 | F | T |
| 3 | 3 | 0 | F | T |
| 4 | 4 | 0 | F | F |
| 4 | 5 | 1 | F | T |
| 4 | 6 | 1 | F | T |
| 5 | 5 | 0 | F | T |
| 6 | 6 | 0 | F | T |
| 7 | 7 | 0 | F | F |
| 7 | 8 | 1 | F | T |
| 7 | 9 | 1 | F | F |
| 7 | 10 | 2 | F | F |
| 7 | 11 | 3 | F | T |
| 7 | 12 | 3 | F | T |
| 7 | 13 | 2 | F | T |
| 8 | 8 | 0 | F | T |
| 9 | 9 | 0 | F | F |
| 9 | 10 | 1 | F | F |
| 9 | 11 | 2 | F | T |
| 9 | 12 | 2 | F | T |
| 9 | 13 | 1 | F | T |
| 10 | 10 | 0 | F | T |
| 10 | 11 | 1 | F | F |
| 10 | 12 | 1 | F | T |
| 11 | 11 | 0 | F | T |
| 12 | 12 | 0 | F | T |
| 13 | 13 | 0 | F | T |
表10-复杂可变层级示例数据
# 具有路径字符属性的可变深度层次
可在维度中采用路径字符属性，以避免使用桥接表表示可变深度。维度中每行，路径字符属性包含特定的嵌入文本字符，包含从层次最好节点到特定维度行所描述节点的完整路径描述。然而路径字符方法不能确保其他层次的快速替换，也无法保证共享自身层次，也难于构建可变路径层次的变化，可能需要重新标记整个层次。
如下图，路径字符属性值显示在每个节点内。在某个层次，路径字符包含父节点的完整路径并增加字母A\B\C等。在其父节点下从左至右增加，路径字符最后一位是+，表示该节点还包含子节点，若为一个.点，则表示该节点没有子节点，可以使用通配符约束路径字符，可以实现针对树的查询，例如：
- A*，检索整棵树，其中星号表示可变成都通配符
- *.，仅检索左节点
- ?+，检索顶端节点，问号时单个字符通配符。
图25-路径字符属性的不规则层次设计
# 高级维度技术
# 维度表连接
维度表可以采用支架维度建模表示到其他维度表的引用，但会导致维度爆炸（如处理支架的维度是SDC类型2时尤为突出）。一般是将支架表中的外键嵌入事实表中而不是放置在基本维度表中，降低维度表之间的关联。1个维度表连接的示例如下（第8章有更多的支架案例）：
图26-客户维表与机构维表连接
按一下改造，把机构支架嵌入事实表后更易于理解，在获取客户机构属性的使用上也更方便：
图27-客户维表及客户所属机构维表连接事实表
# 多值维度与桥接表
某些情况下，维度存在合理的多值，例如某个病人接受一次健康体检，可能同时出现多个诊断，这种情况下多值维度必须通过一组维度键通过桥接表使一组中的每个诊断与事实表一行关联。
图28-客户维表及客户所属机构维表连接事实表
如果某个病人有三种诊断，则他将被分配在桥接表中包含三个对应行的诊断组中。
# 随时间变化的多值桥接表
多值桥接表可能需要基于缓慢变化类型2维度，如实现银行账户与单独客户的多对多关系的桥接表，通常必须基于类型2的账户与客户维度。为防止账户与客户间的不正确连接，桥接表必须包含有效期和截止日期/时间戳，请求的应用必须约束桥接表，使其满足特定时刻以产生一致的快照。
图29-使用拉链技术的账户及客户维表及其桥接表
# 标签的时间序列行为
几乎所有的文本都是维度表中的描述文本。数据挖掘客户聚类分析通常产生文本化的行为标签，通常可以用作区分周期。跨时间范围的客户行为度量成为由这些行为标签构成的一种序列，该时间序列应该以位置属性被存储在客户维度中，包含可选文本串，构成完整的序列标签。
图30-把时间标签序列当作维度行
行为序列格式：YYYYMMDD:tag1,tag2,tag3|YYYYMMDD:tag2,tag4|...
- 示例：
"20230101:高活跃,购物达人|20230215:中活跃,折扣敏感|20230320:低活跃"
# 行为研究分组
通过执行多次迭代分析，来分析复杂的客户行为。将行为分析嵌入到BI应用，以约束所有客户维度的成员，获取复杂的行为的做法是不现实的。复杂行为分析的结果可以通过某些简单表获取，这些表称为研究分组，仅包含客户的持久键。查询时通过约束研究组表的列与目标模式中客户维度的持久键，该静态表可当成一种可应用于任何带有客户维度的维度模式过滤器。
图31-客户行为研究分组
通过上方建模，可以获取多个客户行为分组，并且进行并集、差集、交集操作。比如上月及本月同时消费超1万的客户、去年前100贡献且本月消费超1万客户。
# 聚集事实作为维度属性
商业用户通常对基于聚集性能度量的客户维度感兴趣，如过滤去年或整个阶段所有花费超过一定数额的客户。聚集事实可以放入作为约束和作为行标识报表的目标为维度。度量通常表示为维度表中的带状范围。
比如去年花费0-99，100-999，1000-9999这种区间，可以用一个去年花费范围字段进行存储。
# 动态值范围报表
动态值范围报表由一系列报表行头组成，这些报表行头为目标数字化事实定义了范围不断变化的集合。如一个银行的公共值域范围报表包含带有标签的多个行，如“从0到$10的平帐”，“从10.01到$25的平账”等等。此类报表是动态报表，因为每次查询时都定义了特定的行头，而不是在ETL过程中定义的。
通俗点说：预计算与BI查询时现算的区别。
# 文本注释维度
与其将自由注释作为事实表的文本度量，不如将他们存储与事实表之外的不同的注释维度，每个事务一行，需要注释的粒度满足唯一事务的数目，使该注释维度对应事实表中的一个外键。
# 多时区
为在多时区应用中获得通用标准时间以及本地时间，应该在受影响的事实表中设置双外键，用以连接两个不同角色的日期维度表。
图32-多时区的实现
# 度量类型维度
有时当事实表每行包含一长列稀疏存储的事实时，可以建立度量类型维度，通过度量类型维度将事实表行变成单一通用事实。我们一般不建议采用该方法，尽管它消除了所有空的事实表列。当潜在事实的数量达到极限（几百个），但是没有多少需要应用到任何给定事实表行时，可以采用该技术。
# 步骤维度
序列过程（例如WEB页事件）通常在事务事实表中用不同行表示过程中的每一步。为了告知哪个步骤满足整个会话，使用步骤维度展示当前步骤的步骤号以及完成该会话共由多少步骤。
步骤维度最熟悉的例子来自通过客户的cookie获取来自多个Web服务器的个体页面事件构建的会话的web事件。
图33-电商WEB会话事实与步骤维度的3类角色
步骤维度的表结构及数据如下表：
| 步骤键 | 总步骤号 | 该步步骤号 | 该步到结束的步骤数 |
|---|---|---|---|
| 1 | 1 | 1 | 0 |
| 2 | 2 | 1 | 1 |
| 3 | 2 | 2 | 0 |
| 4 | 3 | 1 | 2 |
| 5 | 3 | 2 | 1 |
| 6 | 3 | 3 | 0 |
| 7 | 4 | 1 | 3 |
| 8 | 4 | 2 | 2 |
| 9 | 4 | 3 | 1 |
| 10 | 4 | 4 | 0 |
表11-步骤维度表数据
步骤维度是一个事前定义的抽象维度。第1行只能用于一个步骤的会话。第2、3行用于2步的会话，4、5、6行用于3步的会话，以此类推。
结合电商WEB会话事实，多个步骤维度的角色连接事实表，通过步骤键可以直接知道哪个事务是会话的第1步或者最后1步，可以直接用于分析连续行为及某一个行为的前1或者后1步对应的事务。
建模连续行为的另外一种方法是为每个可能出现的步骤建立特殊的固定代码。比如零售中客户连续购买产品的行为，可以建立包含产品代码序列的文本列，示例存储内容如下（5位数字为产品代码）：
12345|45882|53340|74934|93636
通过通配符匹配可以查询购买某产品时同时购买了哪些其他产品或者购买了某产品时没有购买的其他产品。
# 热交换维度
同一个事实表与相同维度的不同拷贝交替搭配时，可使用热交换维度。例如某事实表包含股票行情，可以同时展示给不同的投资人，不同的投资人对不同的股票由不同的属性要求。这个股票的例子也叫“多租户维度建模”，解决方案为：热可交换股票维度（客户专属维度+共享事实表）
核心思路：
- 共享事实表：所有客户访问同一份股票价格数据
- 客户专属维表：每个客户有自己定制的股票属性（如行业分类、财务指标、自定义标签）
- 动态关联：查询时，根据客户ID选择对应维表进行关联（热交换）
图34-客户股票热交换实现
# 抽象通用维度
抽象即把事物往上级靠。如单一的位置维度而不是关于商店、仓库和客户维度的嵌入地理属性。人员维度包含雇员、客户和供应商。应该避免使用抽象通用维度。
# 审计维度
当事实表行是在ETL之后建立时，建立包含当时已知的ETL过程元数据的审计维度是很好的方法。审计维度行可包含一个或多个数据质量的基本标识，也许来自对错事件模式的检验，记录数据处理是发现的数据质量问题。审计维度属性可以包含描述建立事实行或ETL执行时间戳的ETL代码版本环境变量。
可以预先考虑相关数据质量的问题，通过构建一个包含所有事实表中的审计维度来表明在建立事实表行时，元数据内容时真实的，如下图：
图35-包含在发票事实表中的审计维度
借助审计维度，可以把原报表扩展，如出界标识，可以看到正常和异常的出界结果。
图36-审计维度应用于异常数据分析
上图中在标准报表基础上分组键增加出界标识，得出数据正常、出界对应的数据，用于异常分析。
# 最后产生的维度
业务过程的事实在关联维度内容前，以分钟、小时、天或周产生。如在实时日期发布环境下，订单消耗行可能会到来，显示客户提交的购买特定商品的自然键。在实时ETL系统中，该行必须提交到BI层，即使客户或产品还不能立即确定下来。在此情况下，建立特殊的维度行，包含作为属性的为分界的自然键，这些维度行必须包含通用未知值，当这些维度内容最后获取时，占用维度行用类型1重写。
# 特殊目的模式
# 异构产品的超类与子类模式
金融服务与其他商业通常提供不同业务类型的广泛产品。如零售银行可以提供许多不同类型的账户，从支票账户到抵押贷款到商业贷款，但是所有这些都使账户的实力。视图建立单一的、固定的事实表，将所有可能的事实都包含在内，联系维度表包含所有不同产品的属性是不会成功的。因为存在大量的不兼容事实和属性，解决方案是建立单一的超类事实表，该事实表遍历所有账户类型的事实表然后系统化地为不同子类建立不同的事实表（与维度表关联）。超类与子类事实表也被成为核心或自定义事实表。
一般会有2个分析角度：全局视图，关注公共事实、业务领域视图，关注细节。
对于全局视图可以建立一个跨越所有业务领域的超类事实表，提供对完整客户组合的知识，此类超类事实表只能取公共产品属性的子集。
图37-针对所有账户的超类快照事实表
对于业务领域视图，关注某个业务的比较深入细节，例如活期存款业务包含大量仅对该业务有效的事实和属性。这些特殊事实无法存储到虫类事实表中，解决方案时为获取存款业务建立子类模式，该模式仅仅被货期账户使用。同时这种子类也必须包含超类事实和属性，以避免超类和子类模式之间发生连接操作。
图38-为活期产品建立的业务领域子类模式
这种超类/子类模设计技术应用到所有业务，提供了包含多个业务领域的范围广泛的产品。假设实在一个销售软件的公司，可以建立以全局客户角度发布的超类销售事实和产品维度表。该超类表包括跨多个业务领域的所有公共事实和维度属性。超类表将成为深入到不同业务领域的子类事实和属性模式的补充。
# 实时事实表
实时事实比传统的夜间批处理过程更频繁地被更新。
# 错误事件模式
数仓中数据质量管理需要一个综合性系统，管理数据质量通过屏幕或过滤器来实现，用于测试从源系统到BI平台的数据。当数据质量屏幕监测到错误时，该事件将被记录在特殊的维度模式中，仅能被ETL后端处理系统处理。包含错误事件事实表，粒度为单独错误事件和相关错误事件详细事实表，相关错误事件详细事实表粒度为参与错误事件的每个表中的列。
图39-错误事件模式
