第2章 Kimball维度建模技术概述

始于 The Data Warehouse Toolkit（Wileyl，1996)第1版， Kimball小组为采用维度方式建模数据定义了完整的技术集合。在本书的前两个版本中作者感到技术的介绍应该通过涵盖各种行业的熟悉的用例展开。尽管我们仍然感到业务用例是基本的教学方法，但由于技术已经非常标准化，因此有些维度建模者对这一逻辑进行了改变，首先介绍技术，然后基于环境研究用例。不管使用哪种方法都是一个好事情。

Kimball技术已经被业界所接受，成为最佳实践。实际上，一些早期 Kimball大学毕业的学生已经出版了他们自己的维度建模书籍。这些书籍通常能非常准确地解释 Kimball技术，但由于这些技术的健壮性，其他书籍并未显著地扩展技术库或提供了一些有争论指导。
本章内容出自这些设计模式的发明者。我们并不期望您一开始就从头到尾阅读本章，但希望您能将本章作为所提供技术的参考。

2.1 基本概念

本节介绍的技术，在所有维度设计工作中都需要考虑。本书的每一章几乎都会涉及本节所介绍的概念。

2.1.1 收集业务需求与数据实现

开始维度建模工作前，项目组需要理解业务需求，以及作为基础的源数据的实际情况。通过与业务代表交流来发现需求，用于理解他们的基于关性能指标、竞争性商业问题、决策制定过程、支持分析需求的目标。同时，数据实际情况可以通过与源系统专家交流，构建高层次数据分析访问数据可行性来揭示。

2.1.2 协作维度建模研讨

维度模型应该由主题专家与企业数据管理代表合作设计而成。工作由数据建模者负责，但模型应该通过与业务代表开展一系列高级别交互讨论获得。这些讨论组也为丰富业务需求提供了一种机会。维度模型不应该由那些不懂业务以及业务需求的人来设计，协作是成功的关键。

2.1.3 4步骤维度设计过程

维度模型设计期间主要涉及4个主要的决策:
(1) 选择业务过程
(2) 声明粒度
(3) 确认维度
(4) 确认事实
要回答上述问题，需要考虑业务需求以及协作建模阶段涉及的底层数据源。按照业务过程、粒度、维度、事实声明的流程，设计组确定表名和列名、示例领域值以及业务规则。而业务数据管理代表必须参与详细的设计活动，以确保涵盖正确的业务。

2.1.4 业务过程

业务过程是组织完成的操作型活动，例如，获得订单、处理保险索赔、学生课程注册或每个月每个账单的快照等。业务过程事件建立或获取性能度量，并转换为事实表中的事实。多数事实表关注某一业务过程的结果。过程的选择是非常重要的，因为过程定义了特定的设计目标以及对粒度、维度、事实的定义。每个业务过程对应企业数据仓库总线矩阵的一行。

2.1.5 粒度

声明粒度是维度设计的重要步骤。粒度用于确定某一事实表中的行表示什么。粒度声明是设计必须履行的合同。在选择维度或事实前必须声明粒度，因为每个候选维度或事实必须与定义的粒度保持一致。在所有维度设计中强制实行一致性是保证BI应用性能和易用性的关键。在从给定的业务过程获取数据时，原子粒度是最低级别的粒度。我们强烈建议从关注原子级别粒度数据开始设计，因为原子粒度数据能够承受无法预期的用户查询。上卷汇总粒度对性能调整来说非常重要，但这样的粒度往往要猜测业务公共问题。针对不同的事实表粒度，要建立不同的物理表在同一事实表中不要混用多种不同的粒度。

2.1.6 描述环境的维度

维度提供围绕某一业务过程事件所涉及的“谁、什么、何处、何时、为什么、如何“等背景。维度表包含BI应用所需要的用于过滤及分类事实的描述性属性。牢牢掌握事实表的粒度，就能够将所有可能存在的维度区分开。当与给定事实表行关联时，任何情况下都应使维度保持单一值。

维度表有时被称为数据仓库的“灵魂“，因为维度表包含确保DW/BI系统能够被用作业务分析的入口和描述性标识。主要的工作都放在数据管理与维度表的开发方面，因为它们是用户BI经验的驱动者。

2.1.7 用于度量的事实

事实及来自业务过程事件的度量，基本上都是以数量值表示一个事实表行与按照事实表粒度描述的度量事件之间存在一对一关系，因此事实表对应一个物理可观察的事件。在事实表内，所有事实只允许与声明的粒度保持一致。例如，在零食事务中，销售产品的数量与其总额是良好的事实，然而商店经理的工资不允许存在于零售事务中。

2.1.8 星型模式与OLAP多维数据库

星型模式是部署在关系数据库管理系统(RDBMS)之上的多维结构。典型地，主要包含事实表，以及通过主键/外键关系与之关联的维度表。联机分析处理(OLAP)多维数据库是实现在多维数据库之上的多维结构，它与关系型星型模式内容等价，或者说来源于关系型星型模式。OLAP多维数据库包含维度属性和事实表，但它能够使用比SQL语言具有更强的分析能力的语言访问，例如，XMLA和MDX等。OLAP多维数据库包含在基本技术的列表中，因为OLAP多维数据库通常是部署维度DW/BI系统的最后步骤，或者作为一种基于多个原子关系型星型模式的聚集结构。

2.1.9 方便地扩展到维度模型

维度模型对数据关系发生变化具有灵活的适应性。当发生以下所列举的变化时，不需要改变现存的BI查询或应用，就可以方便地适应，且查询结果不会有任何改变。

• 当事实与存在的事实表粒度一致时，可以创建新列。
• 通过建立新的外键列，可以将维度关联到已经存在的事实表上，前提是维度列与事实表粒度保持一致。
• 可以在维度表上通过建立新列添加属性。
• 可以使事实表的粒度更原子化，方法是在维度表上增加属性，然后以更细的粒度重置事实表，小心保存事实表及维度表的列名。

2.2 事实表技术基础

本节介绍的技术将应用于所有的事实表中。在几乎所有章节中都有对事实表的描述。

2.2.1 事实表结构

发生在现实世界中的操作型事件，其所产生的可度量数值，存储在事实表中。从最低的粒度级别来看，事实表行对应一个度量事件，反之亦然。因此，事实表的设计完全依赖于物理活动，不受可能产生的最终报表的影响。除数字度量外事实表总是包含外键，用于关联与之相关的维度，也包含可选的退化维度健和日期/时间戳。查询请求的主要目的是基于事实表开展计算和聚集操作。

2.2.2 可加、半可加、不可加事实

事实表中的数字度量可划分为三类。最灵活、最有用的事实是完全可加，可加性度量。
可以按照与事实表关联的任意维度汇总。半可加度量可以对某些维度汇总，但不能对所有维度汇总。差额是常见的半可加事实，除了时间维度外，它们可以跨所有维度进行加法操作。另外，一些度量是完全不可加的，例如，比率。对非可加事实，一种好的方法是，尽可能存储非可加度量的完全加加的分量，并在计算出最终的非可加事实前，将这些分量汇总到最终的结果集合中。最终计算通常发生在BI层或OLAP多维数据库层。

2.2.3 事实表中的空值

事实表中可以存在空值度量。所有聚集函数(Sum、 COUNT、MIN、MAX、AVG)均可针对空值事实计算。然而，在事实表的外键中不能存在空值，否则会导致违反参照完整性的情况发生。关联的维度表必须用默认行（代理键）而不是空值外键表示未知的或无法应用的条件。

2.2.4 一致性事实

如果某些度量出现在不同的事实表中，需要注意，如果需要比较或计算不同事实表中的事实，应保证针对事实的技术定义是相同的。如果不同的事实表定义是一致的，则这些一致性事实应该具有相同的命名，如果它们不兼容，则应该有不同的命名用于告诚业务用户和BI应用。

2.2.5 事务事实表

事务事实表的一行对应空间或时间上某点的度量事件。原子事务粒度事实表是维度化及可表达的事实表，这类健壮的维度确保对事务数据的最大化分片和分块。事务事实表可以是稠密的，也可以是稀疏的，因为仅当存在度量时才会建立行。这些事实表总是包含一个与维度表关联的外键，也可能包含精确的时间戳和退化维度键。度量数字事实必须与事务粒度保持一致。

2.2.6 周期快照事实表

周期快照事实表中的每行汇总了发生在某一标准周期，如某一天、某周、某月的多个度量事件。粒度是周期性的，而不是个体的事务。周期快照事实表通常包含许多事实，因为任何与事实表粒度一致的度量事件都是被允许存在的。这些事实表其外键的密度是均匀的，因为即使周期内没有活动发生，也会在事实表中为每个事实插入包含0或空值的行。

2.2.7 累积快照事实表

累积快照事实表的行汇总了发生在过程开始和结束之间可预测步骤内的度量事件。管道或工作流过程(例如，履行订单或索赔过程)具有定义的开始点，标准中间过程，定义的结束点，它们在此类事实表中都可以被建模。通常在事实表中针对过程中的关键步骤都包含日期外键。累积快照事实表中的一行，对应某一具体的订单，当订单产生时会插入一行。当管道过程发生时，累积事实表行被访问并修改。这种对累积快照事实表行的一致性修改，在三种类型事实表中具有特性，除了日期外键与每个关键过程步骤关联外，累积快照事实表包含其他维度和可选退化维度的外键。通常包含数字化的与粒度保持一致的，符合里程碑完成计数的滞后性度量。