《数据仓库工具书》总结
维度建模、商业智能及维度建模初步
DW/BI
数据仓库和商业智能（Data Warehousing and Business Intelligence）
维度建模
维度建模早期用于简化数据库，后来人们被别这种单一维度结构满足人们基本需求的简单性所吸引，它能以商业用户可理解的方式发布数据，提供高效的查询性能。
维度模型通常应用在关系数据库管理系统之上，但并不要求维度模型必须满足第三范式。
星型模型与OLAP多维数据库
在关系数据库管理系统中实现的维度模型称为星型模型
在多维数据库环境中实现的维度模型通常称为联机分析处理（OnLine Analytical Processing，OLAP）多维数据库
如果采用的DW/BI环境包括星型模型或OLAP多维数据库，则可以说是利用了维度概念。
由于采用预计算、索引策略和其他优化方法，多维数据库可实现高性能查询。业务用户可以通过增或删除其查询中的属性，开展上钻和下钻操作，获得良好的分析性能，不需要提出新的查询。OLAP多维数据库还提供大量健壮的分析函数。
尽管OLAP技术不断得到改善，通常推荐将详细的、原子的信息加载到星型模型中，然后将OLAP多维数据库移植到星型模式上。
用于度量的事实表
事实表中的每一行对应一个度量事件。每行的数据是一个特定级别的细节数据，称之为粒度。
最实用的事实是数值类型和可加类型事实，例如销售额、销售量。
一般事实表具有多个外键与维度表主键关联。
需要注意的是，上图中的简单事实表，如果给定产品没有销售活动，则不要再表中插入任何行。不要试图以0表示没有活动发生来填充事实表，这些0将会占据大量事实表。仅将发生的活动放入事实表中，事实表将变得非常稀疏。尽管存在稀疏特性，事实表仍然占据维度模型消耗空间的90%甚至更多。从行的数量来看，事实表趋向于变长。从列的数量来看，事实表趋向于变短。鉴于事实表占据大量的空间的实际情况，应该仔细考虑对事实表空间的利用问题。
用于描述环境的维度表
维度表包含与业务过程度量事件有关的文本环境。
维度表通常有多列，与事实表比较，维度表趋向于包含较少的行。
每一个维度表由单一主键定义，用于在与事实表连接操作时实现参照完整性的基础
维度属性可以作为查询约束、分组、报表标识的主要来源。
多数情况下，数据仓库的好坏直接取决于维度属性的设置；DW/BI环境的分析能力直接取决于维度属性的质量和深度。
上图表面维度表通常以层次关系表示。例如，产品抽象为品牌，然后抽象为类别。层次描述信息存储存在冗余，这样做的目的主要是为了方便使用和提供查询性能。
星型模式中维度与事实的连接
维度模型表示每个业务过程，包含事实表，事实表存储事件的数值化度量，围绕事实表的是多个维度表，维度表包含事件发生时实际存在的文本环境。
假如我们要将事实表与维度表转换为报表，维度属性支持报表过滤和标识，事实表支持报表中的数字值。
SELECT store.district_name, product.brand, sum(sales_facts.sales_dollars) AS "Sales Dollars" FROM store, product, date, sales_facts WHERE data.month_name="January" AND date.year=2013 AND store.store_key=sales_facts.store_key AND product.product_key=sales_facts.product_key AND date.date.key=sales_facts.date_key GROUP BY store.district_name, product.brand;
KimBall的DW/BI架构
其他DW/BI架构
独立数据集市架构
辐射状企业信息工厂Inmon架构
混合辐射状架构与Kimball架构
Kimball维度建模技术概述
收集数据需求与数据实现
开始维度建模工作前，项目组需要理解业务需求，以及作为基础的数据源的实际情况。通过与业务代表交流发现需求，用于理解他们的基于关键性能指标、竞争性商业问题、决策制定过程、支持分析需求目标。同时，数据实际情况可以通过与源系统专家交流，构建高层次数据分析以及访问数据可行性。
4步维度设计过程
1）选择业务过程
在业务系统中，挑选我们感兴趣的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。
2）声明粒度
数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求。
3）确认维度
维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。
确定维度的原则是：后续需求中是否要分析相关维度的指标。例如，需要统计，什么时间下的订单多，哪个地区下的订单多，哪个用户下的订单多。需要确定的维度就包括：时间维度、地区维度、用户维度。
4）确认事实
此处的“事实”一词，指的是业务中的度量值（次数、个数、件数、金额，可以进行累加），例如订单金额、下单次数等。
事实表技术基础
事实表中的数字度量
可加：可以按照与事实表关联的任意维度汇总例如，销量。
半可加：可以对某些维度汇总，但不能对所有维度汇总。例如，差额是常见的半可加事实，除了时间维度外，他们可以跨所有维度进行加法操作。
不可加：对所有维度都不能汇总。例如，比率。对非可加事实，一种好的方法是，尽可能存储非可加度量的完全可加的分量，并在计算最终的非可加事实前，将这些分量汇总到最终的结果集合中。最终计算通常发送在BI层或OLAP多维数据库层
事务事实表
事务事实表的一行对应空间或时间上某点的度量事件。例如一个销售订单记录，一笔支付记录等。
一旦事务被提交，事实表数据被插入，数据就不再进行更改。
周期快照事实表
周期快照事实表中的每行汇总了发送在某一标准周期，如某一天、某周、某月的多个度量事件。例如每天或者每月的销售额，或每月的账户余额等。
不会保留所有数据，只保留固定时间间隔的数据。
累积快照事实表
累积快照事实表的行汇总了发生在过程开始和结束之间可预测步骤内的度量事件。例如，数据仓库中可能需要累积或者存储订单从下订单开始，到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。
当这个业务过程进行时，事实表的记录也要不断更新，用于跟踪业务事实的变化。
无事实的事实表
尽管多数度量事件获取的结果是数字化的，但也存在某些事件仅仅记录一系列某一时刻发生的多维实体。例如，在给定的某一天中发生的学生参加课程的事件，可能没有可记录的数字化事实，但该事实行带有一个包含日历天、学生、教师、地点、课程等定义良好的外键。
利用无事实表也可以分析发生了什么。这类查询总是包含两个部分：包含所有可能事件的无事实覆盖表，包含实际发生的事实的活动表。当活动从覆盖表中减除时，其结果是尚未发生的事件。
聚集事实表
聚集事实表是对原子粒度事实表数据进行简单的数字化上卷操作。
上卷：数据的汇总聚合，细粒度到粗粒度的过程,会无视某些维度
合并事实表
通常将多个过程的，以相同粒度表示的事实合并为一个单一的合并事实表，这样能带来方便。例如，现货销售可以与销售预测合并为一张事实表，与针对多个不同的事实表采用下钻应用比较，这样做可使对现货及预测任务的分析工作变得简单快捷。
合并事实表会增加ETL处理过程的负担，但降低了BI应用的分析代价。合并事实表特别适合那些经常需要共同分析的多过程度量。
下钻：数据明细，粗粒度到细粒度的过程，会细化某些维度
维度表技术基础
退化维度
有时，维度除了主键外没有其他内容。例如，当某一发票包含多个数据项时，数据项事实行继承了发票的所有描述性维度外键，发票除了外键外无其他项。但发票数量仍然是在此数据项级别的合法维度键。这种退化维度被放入事实表中，清楚地表明没有关联的维度表。
日历日期维度
连接到实际事实表的日历日期维度，使得能够对事实表，按照熟悉的日期、月份、财务周期和日历上的特殊日期进行导航。不要指望能够用SQL计算复活节，但可以在日历日期维度上寻找复活节。日历日期维度通常包含许多描述，例如，周数、月份名称、财务周期、国家假日等属性。为方便划分，日期维度的主键可以更有意义，例如，YYYYMMDD，而不是顺序分配的代理键。若需要更详细的精确度，可以在事实表中增加不同的日期时间戳。
雪花维度
当维度表的层次关系是规范的时，低粒度属性作为辅助表通过属性键连接到基本维度表。当这一过程包含多层维度表层次时，建立的多级层次结构被称为雪花模式。尽管雪花模式可精确表示层次化的数据，但还是应该避免使用雪花模式，因为对商业用户来说，理解雪花模式并在其中查询是非常困难的。雪花模式还会影响性能。
使用一致性维度集成
一致性维度
当不同的维度表的属性具有相同列名和领域内容时，称维度表具有唯一性。利用唯一性维度属性与每个事实表关联，可将来自不同事实表的信息合并到同一报表中。当一致性属性被用作行头（就是说，用作SQL查询中的分组列）时，来自不同事实表的结果可以排列到跨钻报表的同一行中。一致性维度一旦定义后，就可以被所有事实表重用。该方法可获得分析一致性并减少未来开发的开销，因为不需要重新创建。
缩减维度
缩减维度是一种一致性唯度，由基本维度的列与（或）行的子集构成。当构建聚集事实表时需要缩减上卷维度。当商业过程自热地获取粒度级别较高的数据时，也需要缩减维度，例如某个按月和品牌进行预判（不需要与销售数据关联的更原子级别的数据和产品）。另一种情况下，也就是当两个维度具有相同粒度级别的细节数据，但其中一个仅代表行的部分子集时也需要一致性维度子集。
跨表钻取
跨表钻取意思是每个查询的行头包含相同的一致性属性时，使不同的查询能够针对两个或更多的事实表进行查询。来自两个查询的回答集合将针对公共维度属性行头，通过执行排序-融合操作实现排序。BI工具提供商对这些功能有多种不同的命名方法，包括编织和多遍查询。
价值链
价值链用于区分组织中主要业务过程的自然流程 。例如 ，销售商的价值链可能包括购买、库存、零售额等 。一般的分类账价值链可能包括预算编制 、承付款项 、付款等 。操作型源系统通常为价值链上的每个步骤建立事务或快照 。因为每个过程在特定时间间隔 ，采用特定的粒度和维度建 立唯一的度量，所以每个过程通常至少建立一个原子事实表 。
企业数据仓库总线架构
企业数据仓库总线架构提供一种建立企业 DW/BI 系统的增量式方法 。这一架构通过关注业务过程将 DW/BI 规划过程分解为可管理的模块，通过重用跨不同过程的标准化一致性维度发布实现集成。企业数据仓库总线架构提供了 一种架构性框架 ，同时也支持可管理敏捷实现对应企业数据仓库总线矩阵 。总线架构中技术与数据库平台是独立的 ，无论是关系 数据库或者是 OLAP 维度结构都能参与其中。
企业数据仓库总线矩阵
企业数据仓库总线矩阵是用于设计并与企业数据 仓库总线架构 交互的基本工具 。矩阵的 行表示业务过程 ，列表示维度。矩阵中的点表示维度与给定 的业务过程是否存在关联关系 。 设计小组分析每一行，用于测试是否为 业务过程定义好相关的候选维度 ，同时也能分析每个 列，考虑某一维度需要跨多个业务过程并 保持一致性。除技术设计细节外 ，当设计小组实现 矩阵中的某行时 ，总线矩阵还可用作输入帮助确定优先 处理 DW/BI 项目过程管理。
处理缓慢变化维度属性
类型 0：原样保留
对类型 0，维度属性值不会发生变化，因此事实表以原始值分组 。类型0适合属性标 记为 “ 原型” 的情况。例如 ，客户原始的信用卡积分或持久型标识符 。该类型也适用于日期维度的大多数属性 。
以贷款行业为例: 比如在用户维度表中，用户注册时使用的原始用户名（original_user_name）。如果它发生变化，那么变化后的值是无效的，会被抛弃。
类型 1：重写
对类型 1 ，维度行中原来的属性值被新值覆盖 。类型1属性总是反映最近的工作 ，因此该技术破坏了历史情况 。尽管该方法易于实现且不需要建立额外的维度行，但使用时需小心，因为受此影响的聚集事实表和 OLAP 多维数据库将会重复计算。
以贷款行业为例: 此方法必须有前提条件，即你不关心这个数据的变化。例如，某个销售人员的英文名改了，如果你不关心员工的英文名有什么变化则可直接覆盖(修改)数据仓库中的数据。
类型 2：增加新行
对类型 2，将在维度表中增加新行 ，新行中采用修改的属性值。要实现该方式 需要维 度主键更具有一般性 ，不能仅采用自然键或持久键 ，因为采用该方法时经常会出现多行描述同样成员的情况 。在为维度成员建立新行时 ，将为其分配新的主代理键，在修改发生后， 将其作为所有事实表的外键，直到后续变化产生新维度键并更新维度行 。
当变化类型 2 发生时，最少需要在维度行中增加 三个额外列 ：①行有效的日期／时间戳列：②行截止日期／时间戳列：③当前行标识 。
以贷款行业为例: 贷款产品的费率会随着市场行情的变化而变化，此时我们应该通过拉链表来记录费率的变化，保证历史订单的费率信息是准确的。
类型 3：增加新属性
对类型 3，将在维度表上增加新属性以保存原来的属性值 ，新属性值以变化类型1方式重写主属性 。这种类型3变化有时称为替换现实 。商业用户可以利用当前值或 替换现实 来分组或过滤事实数据 。此种缓慢变化维度技术不太常用。
类型 4：增加微型维度
对类型 4，当维度中的一组属性快速变化并划分为微型维度时采用 。此种情况下的维度通常被称为快速变化魔鬼维度 。通常在包含几百万行的维度表中使用的属性是微型维度设计的候选 ，即使它们并不经常变化 变化类型 4 微型维度需要自己的唯一主键，基维度 和微型维度主键从相关的 事实表中获取。
以案例来看: 初始的维度表
在一年后变为二年级：
类型 1：重写
类型 2：增加新行
类型 3：增加新属性
类型 4：增加微型维度
类型 5：增加微型维度及类型 1 支架
对类型5，用于精确保存历史属性值 ，按照当前属性值 ，增加报表的历史事实 。类型 5 建立在类型 4 微型维度之上 ，并嵌入当前类型1引用基维度中的微型维度 。这样才能确保 当前分配的微型维度属性能够与基维度上其他微型维度 一起被访问 ，而不必通过事实表连 接 。逻辑上说 ，应该将基维度及微型维度支架表 示为展现区域中的单一表。每当当前微型 维度分配发生变化时 ，ETL 小组需要重写类型1微型维度引用 。
类型 6：增加类型 1 属性到类型 2 维度
与类型 5 类似，类型 6 也保存历史和当前维度属性值 。类型 6 建立在类型 2 的基础上， 同时嵌入维度行属性的当前类型 l版本 ，因此事实行可以被过滤或分组 ，要么按照当度量 发生时有效的类型 2 属性值 ，要么按照、属性的当前值。在此环境中 ，当属性发生变化时 ， 类型 1属性由系统自动重写与特定持久键关联的所有行 。
类型 7：双类型 1 和类型 2 维度
类型 7 是用于支持过去和现在报表的最后 一种混合技术 。事实表可以被访 问，通过被 建模为类型1维度仅仅展示最新属性值 ，建模为类型 2 维度展示最新历史概要 。同样的维 度表确保实现两方面的观点 。维度的持久键和主代理键同时存在事实表上 。从类型1角度 看，维度的当前标识被约束至当前 ，通过持久键与事实表连接 。从类型 2 角度看 ，当前标 识无约束 ，事实表通过代理键主键连接。此两种方法可以按照不同的视图 部署到 BI 应用上 。
处理维度层次关系
固定深度位置的层次
固定深度层次是多对一关系的一种 ，例如 ，产品→品牌→类别→部门 。当固 定深度层次定义完成后，层次就具有商定的名字 ，层次级别作为维度表中的不同位置属性 出现。只要满足上述条件，固定深度层次就是最容易理解和查询的层次关系 ，固定层次也 能够提供可预测的、快速的查询性能 。当层次不是多对一关系 ，或层次的深度不定 ，以致 层次没有稳定的命名时 ，就需要接下来将描述的非固定层次技术 。
轻微参差不齐 ／可变深度层次
轻微参差不齐层次没有固定的层次深度 ，但层次深度有限 。地理层次深度通常包含 3到 6 层。与其使用复杂 的机制构建难以预测的可变深度层次 ，不如将其变换为固定深度位 置设计 ，针对不同的维度属性确立最大深度 ，然后基于业务规 则放置属性值 。
具有层次桥接表的参差不齐 ／可变深度层次
在关系数据库 中，深度不确定的可变深度层次非常难以建模 。尽管 SQL 扩展和 OLAP 访问语言对递归父子关系提供了 一些支持 ，但方法极为有限 。采用 SQL 扩展，在查询时， 不能替换参差不齐层次 ，不支持对自身层次结构的共享 ，同时也不支持随时间变化的参差 不齐层次 。以上所有问题可以通过在关系数据库中采用构建桥接表方式建模参差不齐层次 米解决 。这样的桥接表对每个可能的路径保留 一行，确保能够遍历所有层次的形式 ，采用 标准 SQL 而不是用特定语 言扩展来实现 。
具有路径字符属性的可变深度层次
可以在维度中采用路径字符属性 ，以避免使用桥接表表示可变深度层次 。对维度中的 每行 ，路径字符属性包含特定的嵌入文本字符 ，包含从层次最高节点到特定维度行所描述 节点的完整路径描述 。多数标准层次分析需求可以通过标准 SQL 处理，不必采用 SQL 语 言扩展 。然而 ，路径字符方法不 能确保其他层次的快速替换 ，也无法保证共享自身层次 。 路径字符方法也难于构建可变路径层次的变化 ，可能需要重新标记整个层次 。
高级事实表技术
事实表代理键
代理键可用作所有维度表的主键 。此外 ，可使用单列代理事实键 ，尽管不太需要 。事实表代理键可用于: ①作为事实表的唯一主键列； ②在ETL中，用作事实表行的直接标识符 ，不必查询多个维度 ： ③允许将事实表更新操作分解为风险更小的插入和删除操作。
蜈蚣事实表
一些设计者为多对一层次的每层建立不同的规范化维度 ，例如 ，日期维度、月份维度 、 季度维度和年维度等 ，并将所有外键包含在 一个事实表中 。这将产生娱蛤事实表 ，包含与 维度相关的多个维度 。应该避免使用娱蛤事实表 。所有这些固定深度的 、多对一层次化关 联的维度都应该回到它们最细节的粒度上 ，例如 ，上例中提到的日期 。当设计者将多个外 键嵌入到单一低粒度维度表中 ，而不是建立杂项维度时 ，也会产生娱蛤事实表 。
属性或事实的数字值
设计者有时会遇到一些数字值 ，难 以确定将这些数字值分类到维度表或是事实表的情况。典型的实例是产品的标准价格。如果该数字值主要用于计算目的，则可能属于事实表 。 如果该数字值主要用于确定分组或过滤 ，则应将其定义为维度属性 ，离散数字值用值范围属性进行补充（例如 ，$0 50） 。某些情况下 ，将数字值既建模为维度又建模为属性是非常有益的，例如，定量准时交货度量 以及定性文本描述符 。
日志／持续时间事实
累积快照事实表获取多个过程里程碑 ，每个都包含日期外键并可能包含日期／时间戳。 商业用户通常希望分析这些里程碑之间的滞后及延迟时间 。有时这些延迟仅仅是日期上的差异，但某些情况下，延迟可能基于更复杂的业务规则 。如果流水线包含大量的步骤，则可能存在上百个延迟 。与其要求用户查询通过日期／时间戳或者日期维度外键计算每个可能存在的延迟，不如根据过程的开始时间点为每个度量步骤存储一个时间延迟 。这样做可以方便地通过利用存储在事实表中的两个延迟，简单地用减法计算任何两个步骤间可能存在的延迟。
头／行事实表
操作型交易系统通常包括事务头指针行 ，头指针行与 多个事务行关联 。采用头／行模式（也称为父／子模式），所有头指针级别维度外键与退化维度应该被包含在行级别事实表 。
分配的事实
头指针／行事务数据与对应的事实具有不同粒度这样的情况经常发生 ，例如，头表示货运费用 。应该尽量分配头指针事实 ，使其基于业务所提供的规则划分为行级别 ，分配的事 实可以按照所有维度进行分片井上钻操作 。多数情况下，可避免建立头指针级别的 事实表 ， 除非这样的聚集能够获得查询性能的改善 。
利用分配建立利润与损失事实表
事实表揭示利润等价方程是企业 DW/BI 应用能够发布的最强大的结果 。利润方程是 ：收入- 开销 = 利润。理想地实现利润方程的事实表应为原子收入事务粒度并包含许多开销项 。
因为这些表处于原子粒度 ，才能实现数字化的上卷 ，包括客户利润 ，产品利润，促销利润 ， 渠道利润等 。然而 ，建立这些事实表存在一定难度 ，因为开销项必须从其原始来源划分到 事实表粒度 。这一分配步骤通常由 ETL 子系统完成，这一过程是一个与业务相关的步骤 ， 需要高层经理 的支持。出于以上原因 ，利润与损失事实表通常在 DW/BI 程序的早期实现阶 段不会被处理。
多种货币事实
以多种货币单位记录财务事务的事实表行应该包含一对列 。其中一列包含以真实币种表示的事实 ，另外列包含同样的 ，但以整个事实表统一的单一标准币种表示的事实 。标准币种值在 ETL 过程中按照规定的货币转换 规则建立。该事实表也必须有一个货币维度用 于区分事务的真正货币 。
多种度量事实单位
某些业务过程需要事实 同时以多种度量单位表示 。例如 ，按照业务用户的观点 ，供应 链可能需要对相同事实 以平台 、船运 、零售 以及单个扫描单元构建报表 。如果事实表包含 大量事实 ，而每个事实都必须以所有度 量单位表示 ，此时较好的方法是将 事实以公认的标 准度量单位存储 ，同时存储标准度量与其他度量的转换系数 。这种事实表可按照不同用户 的观点部署 ，使用适当选择的转换系数 。转换系数必须存储在事实表行中以确保计算简单 正确，并尽量降低查询复杂性 。
年-日事实
商业用户在事实表 中通常需要年-日（year-to-date, YTD）值 。很难反对单个请求 ，但是 YTD 请求很容易变 换为 “ 财务周期结束时的 YTD ” 或者 “ 财务周期日”。一种更可靠 、可 扩展的处理这些请求 的方法是在 BI 应用或 OLAP 多维数据库中计算 YTD 矩阵 ，而不是在 事实表 巾查出 YTD 事实。
多遍 SQL 以避免事实表间的连接
BI 应用绝不应该跨事实表 的外键处理两个事实表 的连接操作 。在关系数据库中 ，控制 此类连接操作的回答集的基数是不可能 的，将会产生 不正确的结果 。例如 ，如果两个 事实 表包含客户产品 出货和返回，则这两个表不 能按照客户和产品外键 直接连接 。要采用跨钻 方式使用两个事实表 ，井对结果按 照公共行头指针属性值 ，进行排序 融合操作以产生正确 结果。
针对事实表的时间跟踪
存在三种基本事实表粒度 ：事务 级别、周期快照和累积快照。个别情况下 ，在事实表中增加行有效时期 、行截止日期和当前行标识是非常有用的 ，与采用类型 2 缓慢变化维度， 在事实行有效时获取时间的方式类似。尽管不太常用 ，但该模型能够解决诸如缓慢变化库存平衡的场景，其中频繁周期快照可以在每个快照上 加载同一行。
迟到的事实
迟到事实是指如果用于新事实行的多数当前维度内容无法匹配输入行的情况。这通常发生在当事实行延迟产生时 。在此情况下，当迟到度量事件出现时 ，必须搜索相关维度以发现有效的维度键 。
高级维度表技术
维度表连接
维度表可以包含到其他维度表的引 用。尽管此类关系可以采用支架维度建模实现 ，但 某些情况下 ，存在于基本维度上的指向支架维度的外键的存在将导致 基本维度爆炸性增长 ， 因为支架表中的类型 2 变化强制需要在基本维度中对 应处理类型 2 变化。如果通过将支架 表中的外键放入事实表中而不是放置在基本维度表中 ，降低维度表之间的关联，则此类增 长通常可被避免 。该方法意味着发现维度之间的关联 ，仅需要通过遍历 事实表 ，这是可以 接受的 ，特别是当事实表示周期快照 ，其所有维度的所有键都会在每个报表周期 内出现时。
多值维度与桥接表
经典维度模式中 ，每个与事实表关联 的维度都有一个与事实表粒度一致的单一值。但 是某些情况下 ，维度存在合理的多值 。例如 ，某个病人接受了 一次健康体检，可能同时出 现多个诊断。在此情况下，多值维度必须通过 一组维度键通过桥接表使一组中的每个诊断 与事实表一行关联 。
随时间变化的多值桥接表
多值桥接表可能需要基于缓慢变 化类型 2 维度。例如 ，实现银行账户与单独客户的多 对多关系的桥接表 ，通常必须基于类型 2 的账户与客户维度 。在此情况下 ，为防止账户与 客户之间 的不正确连接 ，桥接表必须包含有效期和截止日期 ／时间戳，请求的应用必须约 束 桥接表 ，使其满足特定时刻以产生一致的快照 。
标签的时间序列行为
数据仓库中几乎所有的文本都是维度表中的描述性文本 。数据挖掘客户聚类分析通常 产生文本化的行为标签，通常可以用作区分周期 。在此情况下 ，跨时间范围的 客户行为度 量成为由这些行为标签构成的一种序列 ，该时间序列应该以位置属性被存储在客 户维度中， 包含可选文本串 ，构成完整的序列标签 。行为标签在位置设计时建 立 ，因为行为标签是复 杂并发查询而不是数字计算的目标 。
行为研究分组
有时可以通过执行多次迭代分析 ，来发现复杂的客户行为 。在此情况下 ，将行为分析嵌入到 BI 应用，以约束所有客户维度的成员 ，获取复杂的行为 ，这样的做法是不现实 的。 复杂行为分析的结果 ，可以通过某些简单表获取 ，这些表称为研究分组 ，仅包含客户的持 久键 。在查词时 ，通过约束研 究组表的列与目标模式中客户维度的持久键 ，该静态表可当 成一种可应用于任何带有客户维度的维度模式过滤器 。可以定义多个研究组 ，导出的研究 组可以通过遍历、联合、设置差异等方式建立 。
聚集事实作为维度属性
商业用户通常对基于聚集性能度量的客户维度感兴趣 ，例如 ，过滤去年或整个阶段所 有花费超过一定数额的客户 。选择聚集事实 可以放入作为约束和作为行标识报表的目标维 度 。度量通常表示 为维度表中的带状范围 。维度属性表示聚集性能度量将增加 ETL 处理的 负担 ，但是可以方便 BI 应用层的分析功能。
动态值范围
动态值范围报表由 一系列报表行头组成 ，这些报表行头为目标数字 化事实定义了范围 不断变化的集合 。例如 ，一个银行的公共值范围报 表包含带有标签的多个行 ，例如 ，“ 从 0 到$10 的平账”，＂从$10.01 到$25 的平账” 等等 。此类报表是动态报表 ，因为每次查询时都 定义了特定 的行头，而不是在 ETL 过程中定义的 。行定义可以通过在小值范围维度表实现 ， 通过大于连接或 小于连接而与事实表实现连接 ，定义可以仅存在于 SQL CASE 语句中 。该 值范围维度方法可 能会获得更高 的性能，特别是针对列数据库 ，因为 CASE 语句方法包含 针对几乎所有事实表 的无约束关系扫描。
文本注释维度
与其将自由注释作为事实表的文本度 量 ，不如将它们存储于事实表之外的不同的注释维度（或作为维度属性 ，每个事务一行 ，但需要注释 的粒度满足唯一事务的数目） ，使该注 释维度对应事实表中的一个外键。
多时区
为在多时区应用中获得通用标准时间以及本 地时间 ，应该在受影 响的事实表中设置双外键 ，用以连接两个不同角色的日期（和可能的 当天时间（time-oιday））维度表 。
度量类型维度
有时 当事实表每行包含一长列稀疏存储 的事实时，可 以建立度量类型维度 ，通过度量 类型维度将事实表行变成单一通用事实。我们一般不推荐采用该方法 。尽管它消除 了所有空的事实表列，但按照每行中 占用列的平均数量 ，这增加了事实表大小 ，并且使内部列的 计算更加困难 。当潜在事实的数量达到极限（几百个），但是没有多少需要应用 到任何给定 事实表行时 ，可以采用该技术 。
步骤维度
序列过程(例如,Web事件)通常在事务事实表中用不同行表示过程中的每一步。为了告知哪个步骤满足整个会话 ，使用步骤维度展示当前步骤的步骤 号以及完成该会话共有 多少步骤。
热交换维度
当同一个事实表与相同维度的不同拷贝交替搭配时 ，可使用热交换维度 。例如 ，某事 实表包含股票行情 ，可以同时展示给不同的投资人 ，不同的投资人对不同的股 票有不同的 属性要求 。
抽象通用维度
一些建模者喜欢使用抽象通用维度 。例如 ，他们的模式包 含单一通用位置维度而不是 关于商店 、仓库和客户维度的嵌入式的地理属性 。类似地 ，其人员维度包含 雇员、客户和 供应商行 ，因为尽管每种类型都包含显然不同的属性 ，但他们都 是人 。在维度建模时应 尽 量避免使用抽象通用维度 。与每种类型关联的属性集合通常存在差异 。如果属性是通用的， 例如 ，地理州 ，应将它们唯一标识以区分商店所在州与客户所在州 。最后 ，将所有不同的 位置 、人员、产品放入单一维度将产生大型的维度表 。数据抽象可以适 当运用于操作型源 系统或 ETL 处理 ，但对查询性能有负面影响 ，并会对维度模型的易 读性带来负面影响 。
审计维度
当事实表行是在 ETL 之后建立时 ，建立包含当时己知的 ETL 过程元数据的 审计维度 是很好的方法 。简单的审计维度行可包含 一个或多个数据质量的基本标识 ，也许来自对错误事件模式的检验 ，记录数据处理是发现的数据质量问题 。另外，使用审计维度属性可以包含描述建立事实行或 ETL 执行时间戳的 ETL 代码版本环境变量 。这些环境变 量对审计 意图特别有用 ，因为它们确保 BI 工具下钻以确定！那些行是由哪些 ETL 软件版本建立的。
最后产生的维度
有时来自操作型业务过程的 事实在关联维度 内容前 ，以分钟、小时、天或周产生 。例 如，在实时日期发布环境下 ，订单消耗行可能 会到来 ，显示客户提交的购 买特定商品的自 然键 。在实时 ETL 系统中 ，该行必须提交到 BI 层 ，即使客户或产品还不能立即确定下来。 在此情况下 ，将建立特殊的维度行 ，包含作为属性的 未分解的自然键 。当然，这些维度行必须包含通用未知值 ，用于多数描述性列 ：推测适当的维度 内容将会从源获得 。当这些维度内容最后获得时 ，占位维度行用类型 1 重写 。当采用类型 2 维度属性的追溯性变化 发生后，最后达到的维度数据也会 产生 。在此情况下 ，新行需要插入维度表中 ，然后需要重新 定义关联事实行 。
