一. 维度表技术基础

1.1 维度表结构

  每个维度表都包含单一的主键列 。维度表的主键可以作为与之关联的任何事实表的外键，维度表行的描述环境应与事实表行完全对应 。维度表通常比较宽 ，是扁平型非规范表 ，包含大量的低粒度的文本属性 。操作代码与指示器可作为属性对待 ，最强有力的维度属性采用冗余的描述填充。维度表属性是查询及BI应用 的约束和分组定义的 主要目标。 报表的描述性标识通常是维度表属性领域值 。

image.png

1.2 维度代理键

  维度表中会包含一个列 ，表示唯一主键。该主键不是操作型系统的自然键 ，由于需要 跟踪变化 ，因此若采用自然键 ，将需要多个维度行表示 。另外，维度的自然健可能由多个源系统建立 ，这些自然键将出现兼容性问题 难以管理 。DW/BI 系统需要声明对所有维度的主键的控制，而无法采用单 一的自然键或附加日期的自然键 ，可以为每个维度建立无语义的整型主键 。这些维度代理键是按顺序分配的简单整数 ，以值 1 开始。每当需要新键时， 键值自动加1。日期维度不需要遵守代理键规则 ，日期维度是高度可预测的且稳定的维度 ， 可以采用更有意义的主键 。

clipboard.png

以贷款业务为例
假设公司分线上和线下两套业务系统，应用和数据都独立，做数据仓库的时候需要把两部分数据集成到一起，假设此时需要创建一个客户维度表。而两套业务系统客户表的主键都是ID，这个时候两套系统集成的时候，如果沿用源系统的主键，就会产生冲突，分不出系统数据的来源，此时应该使用一个无意义的整型主键作为代理键。

clipboard.png

1.3 自然键、持久键和超自然键

  由操作型系统建立的自然键受业务规则影响 ，无法被 DW/BI 系统控制。例如 ，如果雇员辞职，然后重新工作 ，则雇员号码（自然键）可能会发生变化 。数据仓库希望为该雇员创建单一 键 ，这就需要建立新的持久键以确保在此种情况下 ，雇员号保持持久性不会发生变化。该键有时被称为持久性超自然键 。最好的持久键其格式应该独立于原始的业务过程 ， 并以整数 l开始进行分配 。多个代理键与某一个雇员关联时 ，若描述发生变化时 ，持久键不会变化。

  自然键和持久键区别：举个例子就明白了，比如说公司员工离职之后又重新入职，他的自然键也就是员工编号发生了变化，但是他的持久键身份证号是不变的。

1.4 下钻

  下钻是商业用户分析数据的最基本的方法 。下钻仅需要在查询上增加一个行头指针 。 新行的头指针是 一个维度属性 ，附加了 SQL 语言的 GROUP BY 表达式 。属性可以来自任 何与查询使用的事实表关联的维度 。下钻不需要预先存在层次的定义 ，或者是下钻路径 。

  比如对产品销售情况分析时，可以沿着时间维从年到月到日更细粒度的观察数据。从年的维度可以下钻到月的维度、日的维度等。

image.png

1.5 退化维度

  有时 ，维度除了主键外没有其他内容。例如 ，当某一发票包含多个数据项时 ，数据项 事实行继承了发票 的所有描述性维度外键 ，发票除了外键外无其 他项 。但发票数量仍然是 在此数据项级别的合法维度键 。这种退化维度被放入事实表 中，清楚地表明没有关联的维 度表 。退化维度常见 于交易和累计快照事实表中 。

  退化维度，就是那些看起来像是事实表的一个维度关键字，但实际上并没有对应的维度表，就是维度属性存储到事实表中，这种存储到事实表中的维度列被称为退化维度。与其他存储在维表中的维度一样，退化维度也可以用来进行事实表的过滤查询、实现聚合操作等。

  那么究竟怎么定义退化维度呢？比如说订单id，这种量级很大的维度，没必要用一张维度表来进行存储，而我们进行数据查询或者数据过滤的时候又非常需要，所以这种就冗余在事实表里面，这种就叫退化维度，citycode这种我们也会冗余在事实表里面，但是它有对应的维度表，所以它不是退化维度。

1.6 非规范化扁平维度

  一般来说 ，维度设计者需要抵制由 多年来操作型数据库设计所带来的对规范化设计的 要求 ，并将非规范化的多对一固定深度层次引入扁平维度行的不同属性 。非规范化维度能 够实现维度建模的双重 目标：简化及速度 。

非规范化扁平维度:

clipboard.png

1.7 多层次维度

  多数维度包含不止一个自然层次。例如 ，日历日期维度可以按照财务周期 层次从天到 周进行划分 ，也可能存在从天到月再到年的层次 。位置密集型维度可能包含多个地理层次 。 所有这些情况下 ，在同一维度中可以存在不同的层次 。

1.8 文档属性的标识与指示器

  令人迷惑 的缩写、真／假标识以及业务指标可以作为维度表中文本 字词含义的补充解 释 。操作代码值所包含的意义应分解成不同的表示不同描述性维度属性的部分 。

image.png

1.9 维度表中的空值属性

  当给定维度行没有被全部填充时，或者当存在属性没有被应用到所有维度行时 ，将产 生空值维度属性 。上述两种情况下 ，我们推荐采用描述性字符串替代空值 。例如 ，使用 Unknown 或 Not Applicable 替换空值 。应该避免在维度属性中使用空值 ，因为不同的数据库系统在处理分组和约束时 ，针对空值的处理方法不一致 。

1.10 日历日期维度

  连接到实际事实表 的日历日期维度 ，使得能够对事实表 ，按照熟悉的日期 、月份 、财 务周期和日历上 的特殊日期进行导航 。不要指望能够用SQL 计算复活节 ，但可以在日历日 期维度上寻找复活节 。日历日期维度通常包含许多描述 ，例如 ，周数 、月份名称、财务周期、国家假日等属性 。为方便划分，日期维度的主键可以更有意义 ，例如 ，用一个整数表 示 YYYYMMDD，而不是用顺序分配的代理键 。然而，日期维度表需要特定的行表示未知或待定的日期 。若需要更详细的精确度，可以在事实表中增加不同的日期时间戳 。日期时间戳并不是维度表的外健，但以单独列的形式存在 。如果商业用户按照当天时间（ time-of­ day）属性进行约束或分组，例如，按当天时间或其他数字分组，则需要在事实表上增加一个 “ 当天时间（time-of-day ）” 维度外键 。

1.11 扮演角色的维度

  单个物理维度可以被事实表 多次引用，每个 引用连接逻辑 上存在差异 的角色维度。例 如 ，事实表可以有多个日期 ，每个日期通过外键表示不 同的日期维度，原则上每个外键表 示不同的日期维度视图 ，这样引用具有不同的含义 。这些不同的维度视图（唯一的属性列名） 被称为角色 。

以贷款行业为例
在申请事实表中，有注册时间、申请时间、初审时间、审批时间、签约时间、放款时间等不同的时间维度。

1.12 杂项维度

  事务型商业过程通常产生一系列混杂的、低粒度的标识和指示器 。与其为每个标识或 属性定义不同 的维度，不如建立单独的将不同维度合并到 一起的杂项维度 。这些维度 ，通 常在一个模式 中标记为 事务型概要维度 ，不需要所有属性可能值的笛卡尔积 ，但应该只包含实际发生在源数 据中的合并值。

image.png

1.13 雪花维度

  当维度表中的层次关系是规范的时，低粒度属性 作为辅助表通过属性键连接到基本维 度表 。当这一过程包含多重维度表层次 时，建立的多级层次结构被称为 雪花模式 。尽管雪 花模式可精确表示层次化的数据 ，但还是应该避免使用 雪花模式 ，因为对商业用户来说 ， 理解雪花模式并在其中查询是非常困难 的。雪花模式还会影响查询性能。扁平化的 、非规范的维度表完全能够获得 与雪花模式相同的信息 。

image.png

image.png

1.14 支架维度

  维度可包含对其他维度的引用 。例如，银行账户维度可 以引用表示开户日期的维度 。 这些被引用的辅助维度称为支 架维度 。支架维度可以使用，但应该尽量少用 。多数情况下， 维度之间的关联应该由 事实表来实现。在事实表中通过两 个维度的不同外键相 关联。

Kimball的架构中不推崇雪花模型，但如果一组属性在维度表中出现不止一次时，我们也可以采用受限的雪花模型——也就是支架表。
除了事实表，一些维度表也用到了日期维度，日期维度被多个表锁使用，就成为日期支架表。

image.png

二. 使用一致性维度集成

  维度建模方法最成功的方面之 一就是为集成来自不同商业过程的数据而定义了简单 而强大的解决方案 。

一致性维度通俗讲解:
在同一个集市内，一致性维度的意思是两个维度如果有关系，要么就是完全一样的，要么就是一个维度在数学意义上是另一个维度的子集。例如，如果建立月维度话，月维度的各种描述必须与日期维度中的完全一致，最常用的做法就是在日期维度上建立视图生成月维度。这样月维度就可以是日期维度的子集，在后续钻取等操作时可以保持一致。如果维度表中的数据量较大，出于效率的考虑，应该建立物化视图或者实际的物理表。

2.1 一致性维度

  当不同的维度表的属性具有相同列名和领域内容时 ，称维度表具有一致性 。利用一致 性维度属性与每个事实表关联 ，可将来自不同 事实表的信息合并到同 一报表中 。当一致性 属性被用作行头（就是说 ，用作 SQL 查询中的分组列）时 ，来自不同事实表的结果可以排列 到跨钻报表的同一行中 。以上实现是集成企业DW/Bl 系统的基础 。一致性维度一旦在与业 务数据管理方共 同定义后 ，就可以被所有事实表重用 。该方法可获得分析一致性并减少未 来开发的开销，因为不需要重新创建。

2.2 缩减维度

  缩减维度是一种一致性维度 ，由基本维度的列与（或）行的子集构成 。当构建聚集事实表时需要缩减上卷维度 。当商业过程自然地获取粒度级别较高的数据时，也需要缩减维度， 例如某个按月和品牌进行的预测（不需要与销售数据 关联的更原子 级别的数据和产品） 。另外一种情况下 ，也就是当两个维度具有同样粒度级别的细节数据 ，但其中一个仅表示行的 部分子集时 ，也需要一致性维度子集 。

2.3 跨表钻取

  简单地说 ，跨表钻取意思是当每个查询的行头包含相同的一致性属性时，使不同的查 询能够针对两个或更多的事实表进行查询 。来自两个查询的回答集合将针对公共维度属性 行头，通过执行排序 融合操作实现排列 。Bl 工具提供商对这些功能有多种不同的命名方法 ， 包括编织和多遍查询等。

2.4 价值链

  价值链用于区分组织中主要业务过程的自然流 程 。例如 ，销售商 的价值链可能包括购 买、库存、零售额等 。一般的分类账价值链可能包括预 算编制 、承付款项 、付款等 。操作 型源系统通常为价值链上的每个步骤建立事务或快照 。因为每个过程在特定时间间隔 ，采 用特定的粒度和维度建 立唯一的度量，所以每个过程通常至少建立 一个原子事实表 。

2.5 企业数据仓库总线架构

  企业数据仓库总线架构提供一种建立企业 DW/BI 系统的增量式方法 。这一架构通过关 注业务过程将 DW/BI 规划过程分解为可管理 的模块，通过重用跨不同过程的标准化一致性 维度发布实现集成。企业数据仓库总线架构提供了 一种架构性框架 ，同时也支持可管理敏 捷实现对应企业数据仓库总线矩阵 。总线架构中技术与数据库平台是独立的 ，无论是关系 数据库或者是 OLAP 维度结构都能参与其中 。

2.6 企业数据仓库总线矩阵

  企业数据仓库总线矩阵是用于设计并与企业数据 仓库总线架构 交互的基本工具 。矩阵的 行表示业务过程 ，列表示维度。矩阵中的点表示维度与给定 的业务过程是否存在关联关系 。 设计小组分析每一行，用于测试是否为 业务过程定义好相关的候选维度 ，同时也能分析每个 列，考虑某一维度需要跨多个业务过程并 保持一致性。除技术设计细节外 ，当设计小组实现 矩阵中的某行时 ，总线矩阵还可用作输入帮助确定优先 处理 DW/BI 项目过程管理。

image.png

2.7 总线矩阵实现细节

  总线矩阵实现细节是一个更加粒度化的总线矩阵，其中扩展每个业务过程行以展示特 定事实表或 OLAP 多维数据库 。在此细节粒度上 ，可以文档化精确 的粒度描述以及事实列表。

image.png

2.8 机会／利益相关方矩阵

  在确定了企业数据仓库总线矩阵行之后，可以通过替换包含业务功能（例如 ，市场、销 售 、财务等）的维度列规划不同的矩阵 。通过确定矩阵点以表示哪些业务功能与哪些 业务过 程行相关 。机会／利益相关方矩阵可用于区分哪些业务过程分组应该与 过程中心行相关 。

三. 处理缓慢变化维度属性

3.1 类型 0：原样保留

  对类型 0，维度属性值不会发生变化，因此事实表以原始值分组 。类型0适合属性标 记为 “ 原型” 的情况。例如 ，客户原始的信用卡积分或持久型标识符 。该类型也适用于日期维度的大多数属性 。

以贷款行业为例:
比如在用户维度表中，用户注册时使用的原始用户名（original_user_name）。如果它发生变化，那么变化后的值是无效的，会被抛弃。

3.2 类型 1：重写

  对类型 1 ，维度行中原来的属性值被新值覆盖 。类型1属性总是反映最近的工作 ，因此该技术破坏了历史情况 。尽管该方法易于实现且不需要建立额外的维度行，但使用时需小心，因为受此影响的聚集事实表和 OLAP 多维数据库将会重复计算。

以贷款行业为例:
此方法必须有前提条件，即你不关心这个数剧的变化。例如，某个销售人员的英文名改了，如果你不关心员工的英文名有什么变化则可直接覆盖(修改)数据仓库中的数据。

3.3 类型 2：增加新行

  对类型 2，将在维度表中增加新行 ，新行中采用 修改的属性值。要实现该方式 需要维 度主键更具有一般性 ，不能仅采用自然键或持久键 ，因为采用该方法时经常会出现多行描述同样成员的情况 。在为维度成员建 立新行时 ，将为其分配新的 主代理键，在修改发生后， 将其作为所有事实表的外键，直到后续变化产生新维度键并更新维度行 。
  当变化类型 2 发生时，最少需要在维度行中增加 三个额外列 ：①行有效的日期／时间戳 列：②行截止日期／时间戳列：③当前行标识 。

image.png

以贷款行业为例:
贷款产品的费率会随着市场行情的变化而变化，此时我们应该通过拉链表来记录费率的变化，保证历史订单的费率信息是准确的。

3.4 类型 3：增加新属性

  对类型 3，将在维度表上增加新属性以保存原来的属性值 ，新属性值以变化类型 l 方 式重写主属性 。这种类型 3 变化有时称为替换现实 。商业用户可以利用当前值或 替换现实 来分组或过滤事实数据 。此种缓慢变化维度技术不太 常用。

image.png

3.5 类型 4：增加微型维度

  对类型 4，当维度中的一组属性快速变化并划分为微型维度时采用 。此种情况下的维度通常被称为快速变化魔鬼维度 。通常在包含几百万行的维度表中使用的属性是微型维度设计的候选 ，即使它们并不经常变化 变化类型 4 微型维度需要自己的唯一主键，基维度 和微型维度主键从相关的 事实表中获取。

以案例来看:
初始的维度表

image.png

1. 重写覆盖

   
   
   image.png

2. 增加行

   
   
   image.png

3. 增加新属性保留旧属性

   
   
   image.png

4. 增加微型维度

   
   
   image.png

3.6 类型 5：增加微型维度及类型 1 支架

  对类型5，用于精确保存历史属性 值 ，按照当前属性值 ，增加报表的历史事实 。类型 5 建立在类型 4 微型维度之上 ，并嵌入当前类型 l 引用基维度中的微型维度 。这样才能确保 当前分配的微型维度属性能够与基维度上其他微型维度 一起被访问 ，而不必通过事实表连 接 。逻辑上说 ，应该将基维度及微型维度支架表 示为展现区域中的单一表。每当当前微型 维度分配发生变化时 ，ETL 小组需要重写类型 l 微型维度引用 。

3.7 类型 6：增加类型 1 属性到类型 2 维度

  与类型 5 类似，类型 6 也保存历史和当前维度属性值 。类型 6 建立在类型 2 的基础上， 同时嵌入维度行属性的当前类型 l版本 ，因此事实行可以被过滤或分组 ，要么按照当度量 发生时有效的类型 2 属性值 ，要么按照、属性的当前值。在此环境中 ，当属性发生变化时 ， 类型 1属性由系统自动重写与特定持久键关联的所有行 。

3.8 类型 7：双类型 1 和类型 2 维度

  类型 7 是用于支持过去和现在报表的最后 一种混合技术 。事实表可以被访 问，通过被 建模为类型 l 维度仅仅展示最新属性值 ，建模为类型 2 维度展示最新历史概要 。同样的维 度表确保实现两方面的观点 。维度的持久键和主代理键同时存在事实表上 。从类型 l角度 看，维度的当前标识被约束至当前 ，通过持久键与事实表连接 。从类型 2 角度看 ，当前标 识无约束 ，事实表通过代理键主键连接。此两种方法可以按照不同的视图 部署到 BI 应用上 。

四. 处理维度层次关系

维度往往存在层次关系 。本节描述处理层次关系的方法 ，从最基本的情况开始讨论 。

4.1 书中解释

4.1.1 固定深度位置的层次

  固定深度层次是多对一关系的一种 ，例如 ，产品→品牌→类别→部门 。当固 定深度层次定义完成后，层次就具有商定的名字 ，层次级别作为维度表中的不同位置属性 出现。只要满足上述条件，固定深度层次就是最容易理解和查询的层次关系 ，固定层次也 能够提供可预测的、快速的查询性能 。当层次不是多对一关系 ，或层次的深度不定 ，以致 层次没有稳定的命名时 ，就需要接下来将描述的非固定层次技术 。

4.1.2 轻微参差不齐 ／可变深度层次

  轻微参差不齐层次没有固定的层次深度 ，但层次深度有限 。地理层次深度通常包含 3到 6 层。与其使用复杂 的机制构建难以预测的可变深度层次 ，不如将其变换为固定深度位 置设计 ，针对不同的维度属性确立最大深度 ，然后基于业务规 则放置属性值 。

4.1.3 具有层次桥接表的参差不齐 ／可变深度层次

  在关系数据库 中，深度不确定的可变深度层次非常难以建模 。尽管 SQL 扩展和 OLAP 访问语言对递归父子关系提供了 一些支持 ，但方法极为有限 。采用 SQL 扩展，在查询时， 不能替换参差不齐层次 ，不支持对自身层次结构的共享 ，同时也不支持随时间变化的参差 不齐层次 。以上所有问题可以通过在关系数据库中采用构建桥接表方式建模参差不齐层次 米解决 。这样的桥接表对每个可能的路径保留 一行，确保能够遍历所有层次的形式 ，采用 标准 SQL 而不是用特定语 言扩展来实现 。

4.1.4 具有路径字符属性的可变深度层次

  可以在维度中采用路径字符属性 ，以避免使用桥接表表示可变深度层次 。对维度中的 每行 ，路径字符属性包含特定的嵌入文本字符 ，包含从层次最高节点到特定维度行所描述 节点的完整路径描述 。多数标准层次分析需求可以通过标准 SQL 处理，不必采用 SQL 语 言扩展 。然而 ，路径字符方法不 能确保其他层次的快速替换 ，也无法保证共享自身层次 。 路径字符方法也难于构建可变路径层次的变化 ，可能需要重新标记整个层次 。

五. 高级维度表技术

5.1 维度表连接

  维度表可以包含到其他维度表的引 用。尽管此类关系可以采用支架维度建模实现 ，但 某些情况下 ，存在于基本维度上的指向支架维度的外键的存在将导致 基本维度爆炸性增长 ， 因为支架表中的类型 2 变化强制需要在基本维度中对 应处理类型 2 变化。如果通过将支架 表中的外键放入事实表中而不是放置在基本维度表中 ，降低维度表之间的关联，则此类增 长通常可被避免 。该方法意味着发现维度之间的关联 ，仅需要通过遍历 事实表 ，这是可以 接受的 ，特别是当事实表示周期快照 ，其所有维度的所有键都会在每个报表周期 内出现时。

5.2 多值维度与桥接表

  经典维度模式中 ，每个与事实表关联 的维度都有一个与事实表粒度一致的单一值。但 是某些情况下 ，维度存在合理的多值 。例如 ，某个病人接受了 一次健康体检，可能同时出 现多个诊断。在此情况下，多值维度必须通过 一组维度键通过桥接表使一组中的每个诊断 与事实表一行关联 。

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

  多值桥接表可能需要基于缓慢变 化类型 2 维度。例如 ，实现银行账户与单独客户的多 对多关系的桥接表 ，通常必须基于类型 2 的账户与客户维度 。在此情况下 ，为防止账户与 客户之间 的不正确连接 ，桥接表必须包含有效期和截止日期 ／时间戳，请求的应用必须约 束 桥接表 ，使其满足特定时刻以产生一致的快照 。

5.4 标签的时间序列行为

  数据仓库中几乎所有的文本都是维度表中的描述性文本 。数据挖掘客户聚类分析通常 产生文本化的行为标签，通常可以用作区分周期 。在此情况下 ，跨时间范围的 客户行为度 量成为由这些行为标签构成的一种序列 ，该时间序列应该以位置属性被存储在客 户维度中， 包含可选文本串 ，构成完整的序列标签 。行为标签在位置设计时建 立 ，因为行为标签是复 杂并发查询而不是数字计算的目标 。

5.5 行为研究分组

  有时可以通过执行多次迭代分析 ，来发现复杂的客户行为 。在此情况下 ，将行为分析嵌入到 BI 应用，以约束所有客户维度的成员 ，获取复杂的行为 ，这样的做法是不现实 的。 复杂行为分析的结果 ，可以通过某些简单表获取 ，这些表称为研究分组 ，仅包含客户的持 久键 。在查词时 ，通过约束研 究组表的列与目标模式中客户维度的持久键 ，该静态表可当 成一种可应用于任何带有客户维度的维度模式过滤器 。可以定义多个研究组 ，导出的研究 组可以通过遍历、联合、设置差异等方式建立 。

5.6 聚集事实作为维度属性

  商业用户通常对基于聚集性能度量的客户维度感兴趣 ，例如 ，过滤去年或整个阶段所 有花费超过一定数额的客户 。选择聚集事实 可以放入作为约束和作为行标识报表的目标维 度 。度量通常表示 为维度表中的带状范围 。维度属性表示聚集性能度量将增加 ETL 处理的 负担 ，但是可以方便 BI 应用层的分析功能。

5.7 动态值范围

  动态值范围报表由 一系列报表行头组成 ，这些报表行头为目标数字 化事实定义了范围 不断变化的集合 。例如 ，一个银行的公共值范围报 表包含带有标签的多个行 ，例如 ，“ 从 0 到10.01 到$25 的平账” 等等 。此类报表是动态报表 ，因为每次查询时都 定义了特定 的行头，而不是在 ETL 过程中定义的 。行定义可以通过在小值范围维度表实现 ， 通过大于连接或 小于连接而与事实表实现连接 ，定义可以仅存在于 SQL CASE 语句中 。该 值范围维度方法可 能会获得更高 的性能，特别是针对列数据库 ，因为 CASE 语句方法包含 针对几乎所有事实表 的无约束关系扫描。

5.8 文本注释维度

  与其将自由注释作为事实表的文本度 量 ，不如将它们存储于事实表之外的不同的注释维度（或作为维度属性 ，每个事务一行 ，但需要注释 的粒度满足唯一事务的数目） ，使该注 释维度对应事实表中的一个外键。

5.9 多时区

  为在多时区应用中获得通用标准时间以及本 地时间 ，应该在受影 响的事实表中设置双外键 ，用以连接两个不同角色的日期（和可能的 当天时间（time-oιday））维度表 。

5.10 度量类型维度

  有时 当事实表每行包含一长列稀疏存储 的事实时，可 以建立度量类型维度 ，通过度量 类型维度将事实表行变成单一通用事实。我们一般不推荐采用该方法 。尽管它消除 了所有空的事实表列，但按照每行中 占用列的平均数量 ，这增加了事实表大小 ，并且使内部列的 计算更加困难 。当潜在事实的数量达到极限（几百个），但是没有多少需要应用 到任何给定 事实表行时 ，可以采用该技术 。

5.11 步骤维度

  序列过程(例如,Web事件)通常在事务事实表中用不同行表示过程中的每一步。为了告知哪个步骤满足整个会话 ，使用步骤维度展示当前步骤的步骤 号以及完成该会话共有 多少步骤。

5.12 热交换维度

  当同一个事实表与相同维度的不同拷贝交替搭配时 ，可使用热交换维度 。例如 ，某事 实表包含股票行情 ，可以同时展示给不同的投资人 ，不同的投资人对不同的股 票有不同的 属性要求 。

5.13 抽象通用维度

  一些建模者喜欢使用抽象通用维度 。例如 ，他们的模式包 含单一通用位置维度而不是 关于商店 、仓库和客户维度的嵌入式的地理属性 。类似地 ，其人员维度包含 雇员、客户和 供应商行 ，因为尽管每种类型都包含显然不同的属性 ，但他们都 是人 。在维度建模时应 尽 量避免使用抽象通用维度 。与每种类型关联的属性集合通常存在差异 。如果属性是通用的， 例如 ，地理州 ，应将它们唯一标识以区分商店所在州与客户所在州 。最后 ，将所有不同的 位置 、人员、产品放入单一维度将产生大型的维度表 。数据抽象可以适 当运用于操作型源 系统或 ETL 处理 ，但对查询性能有负面影响 ，并会对维度模型的易 读性带来负面影响 。

5.14 审计维度

  当事实表行是在 ETL 之后建立时 ，建立包含当时己知的 ETL 过程元数据的 审计维度 是很好的方法 。简单的审计维度行可包含 一个或多个数据质量的基本标识 ，也许来自对错误事件模式的检验 ，记录数据处理是发现的数据质量问题 。另外，使用审计维度属性可以包含描述建立事实行或 ETL 执行时间戳的 ETL 代码版本环境变量 。这些环境变 量对审计 意图特别有用 ，因为它们确保 BI 工具下钻以确定！那些行是由哪些 ETL 软件版本建立的。

5.15 最后产生的维度

  有时来自操作型业务过程的 事实在关联维度 内容前 ，以分钟、小时、天或周产生 。例 如，在实时日期发布环境下 ，订单消耗行可能 会到来 ，显示客户提交的购 买特定商品的自 然键 。在实时 ETL 系统中 ，该行必须提交到 BI 层 ，即使客户或产品还不能立即确定下米 。 在此情况下 ，将建立特殊的维度行 ，包含作为属性的 未分解的自然键 。当然，这些维度行必须包含通用未知值 ，用于多数描述性列 ：推测适 当的维度 内容将会从源获得 。当这些维度内容最后获得时 ，占位维度行用类型 1 重写 。当采用类型 2 维度属性的追溯性变化 发生后，最后达到的维度数据也会 产生 。在此情况下 ，新行需要插入维度表中 ，然后需要重新 定义关联事实行 。

参考:

1. 《数据仓库工具箱 维度建模权威指南》第三版