Kimball建模理论

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累积快照事实表

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

2.2.8无事 实的事实表

尽管多数度量事件获取的结果是数字化的，但也存在某些事件仅仅记录一系列某一时
刻发生的多维实体。例如，在给定的某一天中发生的学生参加课程的事件，可能没有可记
录的数字化事实，但该事实行带有一个包含日历天、学生、教师、地点、课程等定义良好
的外键。同样，客户交际也是一种事件，但没有相关的度量。利用无事实的事实表也可以
分析发生了什么。这类查询总是包含两个部分:包含所有可能事件的无事实覆盖表，包含
实际发生的事件的活动表。当活动从覆盖表中减除时，其结果是尚未发生的事件。

2.2.9聚集事实表或OLAP多维数据库

聚集事实表是对原子粒度事实表数据进行简单的数字化上卷操作，目的是为了提高查
询性能。这些聚集事实表以及原子事实表可以同时被BI层使用，这样BI工具在查询时可
以平滑地选择适当的聚集层次。这–被称为聚集导航的过程是开放的，以便报表制作者、
查询工具、BI应用都能够获得同样的性能优势。适当设计的聚集集合应该类似数据库索引，
能够提高查询性能，但不需要直接面对BI应用或商业用户。聚集事实表包含外键以缩小一
致性维度，聚集事实的构建是通过对来自多个原子事实表的度量的汇总而获得的。最后,
使用汇总而度量聚集OLAP多维数据库- -般 与关系类型的聚集方法类似，但是OLAP多维
数据库可以被商业用户直接访问。

2.2.10合并事实表

通常将来自多个过程的，以相同粒度表示的事实合并为一个单一的合并事实表，这样
做能够带来方便。例如，现货销售可以与销售预测合并为-张事实表，与针对多个不同的
事实表采用下钻应用比较，这样做可使对现货及预测任务的分析工作变得简单快捷。合并
事实表会增加ETL处理过程的负担，但降低了BI应用的分析代价。合并事实表特别适合
那些经常需要共同分析的多过程度量。

举例：

1.事实表结构示例：
假设我们有一个销售数据仓库，以下是一个订单事实表的示例结构：
●订单事实表(order_fact):
	●订单ID(order_id)
	●产品D(product_id)
	●订单日期(order_date)
	●数量(quantity)
	●销售额(sales_amount)
2.可加、半可加、不可加事实示例:
	●可加事实:销售额是一个可加事实， 可以按照任意维度(如产品、客户、时间)进行汇总。
	●半可加事实:差额是一个半可加事实，可以按照除时间维度以外的其他维度进行汇总。
	●不可加事实:比率是一个不可加事实，不能直接进行汇总，需要通过计算得出。
3.事实表中的空值:
	在事实表中，度量事件可能存在空值。聚合函数(如SUM、COUNT、MIN、MAX、 AVG) 可对空值事实进行计算。但在事实表的外键中不能存在空值 ,需要使用默认行(代理键)来表示未知或无法应用的条件。
4. 一致性事实:
如果同一个度量出现在不同的事实表中，需要确保对该度量的技术定义是相同的，并使用相同的命名。如果不同的事实表定义不一致， 可以使用不同的命名来提醒业务用户和BI应用。
5. 事务事实表示例: 
假设我们有-个订单处理系统，以下是一个订单事务事实表的示例结构:
●订单事务事实表(order_transaction_fact):
	●事务ID(transaction_id)
	●订单ID(order_id)
	●产品ID(product_id)
	●客户ID(customer_id)
	●事务日期(transaction_date)
	●数量(quantity)
	●销售额(sales_amount)
6.周期快照事实表示例:
假设我们有一个每月销售汇总报表，以下是一个周期快照事实表的示例结构:
●月度销售快照事实表(monthly. sales. snapshot):
	●日期(date)
	●销售额(sales_ amount)
	●订单数量(order. count)
	●产品数量(product count)
7.累积快照事实表示例:
假设我们有一个订单履行系统，以下是一个累积快照事实表的示例结构:
●订单履行累积快照事实表(order. fifllment snapshot):
	●订单ID(order. _id)
	●产品ID(product. id)
	●客户ID(customer. id)
	●开始日期(start date)
	●结束日期(end. date)
	●步骤完成情况(step. completion)
8.无事实的事实表示例:
假设我们有一个学生参 与课程的事件记录系统，以下是一个无事实的事实表的示例结构:
●学生课程参与事实表(student_ course_ participation_ _fact):
	●日期(date)
	●学生ID(student _id)
	●教师ID(teacher. id)
	●课程ID(course. id)
	●地点ID(location id)
9.聚集事实表或OLAP多维数据库示例:
假设我们有个销售分析系统，以下是一个聚集事实表的示例结构:
●销售聚集事实表(sales_ aggregate_ fact):
	●时间维度ID(time_dim_id)
	●产品维度ID(product dim _id)
	●客户维度ID(customer. _dim. id)
	●销售额(sales_ amount)
10.合并事实表示例:
假设我们有一个综合分析系统，以下是一个合并事实表的示例结构:
●综合分析事实表(combined. analysis. fact):
	●订单ID(order_id)
	●客户ID(customer_id)
	●订单日期(order_date)
	●预测销售额(forecasted_sales_amount)
	●实际销售额(actual_sales_amount)
以上是关于事实表的一些例子，它们展示了不同类型的事实表结构和应用场景。这些例子可以帮助组织设计和构建适合其业务需求的数据模型。

2.3维度表技术基础

2.3.1维度表结构

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

2.3.2维度代理键

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

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

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

2.3.4下钻

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

2.3.5退化维度

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

2.3.6 非规范化扁平维度

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

2.3.7 多层次维度

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

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

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

2.3.9维度表中的空值属性

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

2.3.10日 历日期维度

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

2.3.11扮演 角色的维度

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

2.3.12杂项维度

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

2.3.13雪花维度

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

2.3.14支架维度

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

举例：

根据Kimball理论的指导原则，下面是对上述14个例子的详细说明和表的设计示例：
1.维度表的结构：
每个维度表包含一个单一的主键列，并且维度表的主键可以作为与之关联的任何事实表的外键。维度表行的描述应与事实表行完全对应。维度表通常非规范化，含有大量低粒度的文本属性。
示例：维度表 - 产品维度表
主键：product_id

2.维度代理键：
维度表中的列，表示唯一的主键。这个主键不是操作型系统的自然键，因为需要跟踪变化。为了确保一行只有一个维度代理键，可以为每个维度使用无语义的整数进行分配，并按顺序分配。
示例：维度表 - 时间维度表
主键：time_id

3.自然键、持久键和超自然键：
自然键是由操作型系统建立的键，但受业务规则影响，DW/BI系统无法控制。为了确保在变化时保持持久性，需要为该键创建新的持久键。
示例：维度表 - 雇员维度表
自然键：employee_id
持久键：persistent_employee_id

4.下钻：
下钻是商业用户分析数据的基本方法，通过在查询上增加一个行头指针来实现。这个行头指针是一个维度属性，可以来自与查询使用的事实表关联的任何维度。
示例：查询 - 销售订单查询
下钻属性：产品类型

5.退化维度：
退化维度是指除了主键外没有其他内容的维度。它们常见于交易和累计快照事实表中，并被放入事实表中以表明没有关联的维度表。
示例：事实表 - 销售订单事实表
退化维度：订单号

6.非规范化扁平维度：
非规范化维度是指引入固定深度层次的多对一关系的扁平维度行。这种设计能够简化和提高查询性能。
示例：维度表 - 客户维度表
属性：客户姓名、客户地址、客户电话

7.多层次维度：
多数维度包含不止一个自然层次，例如时间维度可以按照天、周、月等层次进行划分。
示例：维度表 - 时间维度表
层次：年份 -> 季度 -> 月份 -> 周 -> 日期

8.文档属性的标识与指示器：
这些属性可以作为维度表中文本字词含义的补充解释，以便提供更多的描述性信息。
示例：维度表 - 操作代码维度表
属性：操作代码名称、操作代码描述

9.维度表中的空值属性：
推荐使用描述性字符串替代空值，例如使用"Unknown"或"Not Applicable"来表示空值。
示例：维度表 - 产品维度表
属性：产品颜色（可能为空）

10.历日期维度：
连接到实际事实表的日历日期维度，包含了日期、月份、财务周期和日历上的特殊日期等属性，方便对事实表按照日期进行导航和分组。
示例：维度表 - 时间维度表
属性：日期、月份、财务周期、国家假日

11.扮演角色的维度：
单个物理维度可以被事实表多次引用，并通过外键表示不同的角色。这些不同的维度视图被称为角色。
示例：事实表 - 销售订单事实表
角色维度：订单日期维度、发货日期维度

12.杂项维度：
将不同的维度合并为一个杂项维度，以避免为每个标识或属性定义不同的维度。杂项维度在一个模式中标记为事务型概要维度。
示例：维度表 - 货币维度表
属性：货币代码、货币名称、货币符号

13.雪花维度：
当维度表中的层次关系是规范的时，可以通过辅助表连接到基本维度表，形成多级层次结构。这种设计被称为雪花模式，但应避免使用，因为理解和查询雪花模式很困难。
示例：维度表 - 地理位置维度表
属性：国家名称、省份名称、城市名称

14.支架维度：
维度可以引用其他维度作为支架维度。支架维度可在事实表中通过两个维度的外键相关联，但应尽量少使用。
示例：维度表 - 账户维度表
支架维度：开户日期维度、账户类型维度

这些是基于Kimball理论的维度表设计的示例。实际的数据模型设计取决于具体的业务需求和数据分析目标。

2.5处理缓慢变化维度 属性

本节描述处理缓慢变化维度(Slowly Changing Dimension, SCD)属性的基本方法。对同
一维度表中属性的变化，采用不同的变化跟踪技术是比较常见的方法。

2.5.1类型0: 原样保留

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

2.5.2类型1:重写

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

2.5.3类型2:增加新行

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

2.5.4类型3:增加新属性

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

2.5.5类型 4:增加微型维度

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

2.5.6类型 5:增加微型维度及类型1支架

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

2.5.7类型 6:增加类型1属性到类型2维度

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

2.5.8类型7:双类型1和类型2维度

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

举例：

假设有一个客户维度表，其中包含客户ID、客户名称、客户等级、客户地址等属性。以下是应用不同类型的缓慢变化维度技术的例子:
●类型0:客户ID为原型属性，因为它永远不会改变。因此，在事实表中以客户ID分组，并保留原始值。
●类型1:客户等级是一个重要的属性，可能会随着时间而变化。如果客户从银级升级到金级，则在维度表中覆盖这个属性的原始值，以反映最新的等级。但是，历史数据将会丢失或被破坏。
●类型2:如果客户地址可能会变化，则可以使用类型2技术。在维度表中增加新行，每行都表示客户的不同地址版本。每当客户的地址发生变化时，就会创建新行，并为其分配一个新的主代理键。 历史数据将得到保留。
●类型3:如果需要保存原来的客户等级，可以在维度表上增加一个新属性。新属性值以类型1方式重写主属性。例如，新属性名为"旧等级”，其值为客户的旧等级。这样商业用户就可以利用"旧等级"来过滤数据。
●类型4:如果客户的某些属性经常发生变化，而且这些属性可以用作单独的维度，则可以使用类型4技术。例如，客户的偏好是一个快速变化魔鬼维度。 在这种情况下，一个”客户偏好微型维度会被创建，其中包含偏好ID、偏好名称、偏好描述等属性。
●类型5:如果需要确保历史事实与当前微型维度属性值相对应，则可以采用类型5技术。在类型4微型维度的基础上，增加了类型1支架。这种方法确保当前微型维度属性与其他微型维度一起被访问， 而不必通过事实表连接。
●类型6:如果需要保存历史和当前维度属性值，则可以使用类型6技术。在类型2基础上增加当前类型1版本的属性，以便可以根据这些属性来过滤或分组。当属性发生变化时，类型1属性会自动重写与特定持久键关联的所有行。
●类型7:如果需要同时支持过去和现在的报表，则可以使用类型7技术。在此情况下，事实表可以通过建模为类型1维度展示最新属性值，并建模为类型2维度展示最新历史概要。通过使用维度表的持久键和主代理键，可以从两个视角访问事实表。