维度建模核心概念与应用

原创于 2025-10-11 02:52:17 发布 · 376 阅读

4 ·

CC 4.0 BY-SA版权

文章标签：

#维度建模 #事实表 #维度 #星型模式 #一致性

维度建模

维度建模简介

与企业关系（ER）建模一样，维度建模也是一种逻辑设计技术。维度建模更适用于商业智能（BI）应用和数据仓库（DW）。它描述了整个企业的业务流程，并以逻辑方式组织这些数据及其结构。维度建模的目的是支持商业智能报告、查询和分析。混合型维度‐规范化模型最适合支持数据仓库的集成需求。

维度建模中的关键概念包括事实、维度和属性。根据是否可以相加，事实分为不同类型。
维度可以具有不同的层次结构，并包含定义维度模型中“谁、什么、何处、为何”的属性。
粒度，即细粒度级别，是维度建模中的另一个关键概念，因为它决定了详细程度的级别。

事实、维度和属性可以通过多种方式组织，这些方式称为模式。模式的选择取决于模型需要支持的报告类型以及所使用的商业智能工具类型等因素。构建维度模型还包括其他一些组成部分，例如日历和时间维度，以及更为复杂的部分，如退化维度和汇总事实表。

除了阐述这些概念外，本章节还将比较ER模型与维度模型之间的方法。

示意图0

维度模型的高层概览

如图9.1所示，维度模型中有两个关键实体：事实（度量）和维度（上下文）。示例展示了这些元素：事实 TblFactStoreSales 是维度模型的核心。

四个围绕的维度，用于定义并提供门店销售的上下文：
右上角是项目 Tbl_Dim_Item，表示销售了哪些产品。
下面是日期，Tbl_维度_日期，即这些产品销售的日期。
左下角是客户，Tbl_维度_客户，即购买产品的客户。
左上角是采购员，Tbl_维度_采购员，即为商店采购产品的人员。

在上下文中，该示例表明当有人购买产品时，我们可以使用此模型来捕获有关该业务流程的信息。具体细节将在后续章节中详细讨论。

事实

事实是对业务活动（如业务事件或事务）的度量，通常为数值型。事实的示例包括销售、费用和库存水平。数值型度量可能包括数量、美元金额、百分比或比率。

事实可以是聚合的或派生的。例如，您可以汇总总收入，或计算一组销售交易的盈利能力。
事实提供了衡量业务绩效好坏的度量。事实也称为组织绩效度量。

事实表是规范化的，且包含很少的冗余。事实表记录数可能变得非常大。在维度模型中，通常有90%的数据位于事实表中。处理事实表数据时，维度建模设计的关键问题是如何最小化、标准化这些数据并使其保持一致。

事实表键

事实表由两类列组成：键和度量。第一类是键列，包含一组外键 (FK)，这些外键指向与此事实表相关联的维度表的主键，以支持业务分析。事实表与维度之间的关系为一对多，如第8章实体关系建模部分所述。

示意图1

图9.2展示了销售事实表（事实_OnlineSales）中的键列：

日期键—购买日期和时间
商店键—进行购买的在线商店
产品键—所购产品
客户键—购买客户
促销键—销售促销
货币键—用于购买的货币

事实表的主键通常是一个复合键，由能够唯一标识事实表行的外键组合构成。该键也可称为复合键或连接键。此复合键可能是外键的一个子集，例如在我们的示例中：DateKey、 StoreKey、ProductKey 和 CustomerKey 可以唯一标识销售事实表中的每一行。

如果没有外键组合能够创建主键所需的唯一性，你有两种选择：

首先，记录用于填充事实表的业务交易或事件的操作系统通常会为这些交易创建相关的唯一标识符。这些标识符的示例包括销售订单号、发票号码和货运跟踪号码。这些标识符被称为退化维度，本章稍后将对此进行讨论。如果将此标识符与部分外键组合可实现唯一性，则该复合键将成为主键。
其次，如果您无法通过迄今为止讨论的任何方法识别出唯一行，则可以基于代理键创建主键。代理键通常由数据库系统使用 IDENTITY数据类型生成，是一个值无意义的整数。最佳实践是对事实表中的每个外键建立索引，因为这可以通过优化连接和过滤器来提高查询性能。

需要实施的一项关键最佳实践是：外键绝不能为空值。执行分析时需要将各个维度与事实表进行连接，而为了确保业务结果的有效性，必须具有外键的值。每个外键都指向一个相应的维度，提供与互联网销售事件相关的属性，例如客户是谁、居住地、年龄以及其他人口统计属性。

事实表度量

事实表中的第二类列是业务活动的实际度量，例如销售额和订单数量。每个度量都有一个粒度，即对某个事件进行度量时的细粒度级别，例如计量单位、所使用的货币或账户的日终余额。例如，货币的粒度可以精确到美元金额，也可以更细粒度地包含美分。粒度由其数据源决定。

示意图4

图9.5中圆圈部分图9.5显示了互联网销售的多个度量：销售数量、销售金额、退货金额、退货数量、折扣金额、折扣数量以及总成本，这些度量适用于客户在特定时间购买的产品。所有这些度量都与事实所代表的业务事件（销售）相关，并且它们具有与此事件相关的粒度级别。

在创建和定义列和度量时，需确保所有行数具有单一且统一的粒度。换句话说，它们必须是相关的。以购买产品为例，为了使查询和报告对业务人员有意义，您必须包含与该特定订单相关的度量。在此示例中，事实表应包含总成本而非单位成本将其与销售数量和销售金额进行比较；否则，业务比率和汇总订单将导致错误的度量。

将业务流程中捕获的最低层级或最详细粒度存储下来是一种被广泛接受的最佳实践。在图9.5 中，这意味着应存储订单行级别明细，而不是汇总的订单头信息。传统上，数据仓库和商业智能使用的是汇总数据，因此查询和报表的详细程度较低。这种做法源于当时基础设施和处理限制，而这些限制如今已不再适用。现在，业界已确立的做法是从事务型或操作系统中获取可用的最低事务级别细节进行存储。这样做能够提供最大的灵活性，因为一旦对数据进行汇总，就会丢失细节，导致数据的可用性降低。细粒度支持可扩展性；拥有最低层级的细节使您能够对事实或度量进行聚合和操作事实。

事实类型

在定义了事实中的度量及其粒度级别后，您需要确定存储在事实中的度量类型的数值属性。度量有三种类型：可加的、半可加的和不可加的。

可加性事实

可加性事实是最容易定义和管理的。它只是事实表中的一个度量，可以在所有维度上进行相加。最简单的可加性事实示例是物品数量在在线商店购买的——例如书籍的数量。可加性度量使得事实可以按所有相关维度进行聚合，在本例中这些维度是客户、商店、产品和日期。

半可加性事实

半可加性事实是事实表中可以沿某些维度相加但不能沿其他维度相加的度量。这类度量的例子包括银行账户余额、学生上课人数或库存水平。你不能简单地将12个月的账户余额相加来得出某人在银行账户中的金额。在这种情况下，你需要对这12个月的余额取平均值。然而，在它们被测量的时间点（月末），你可以将所有客户的账户余额相加，从而得到该时间点的总账户余额。

不可加性事实

不可加性事实是事实表中无法沿任何维度相加的度量。此类例子包括单价、比率和温度；尽管它们是数字，但并不应该被相加。在一个真实案例中，我的一个客户在某个州采集水位样本，这些比率和水位不能直接相加。他们必须从科学的角度来分析这些数据。不可加性事实不能像典型的SQL查询那样通过对某一列求和来进行处理。

了解可加的、半可加的和不可加性事实的概念非常重要，因为数据的聚合或汇总在报告和分析中占据很大比重。这也是使用维度模型的主要好处之一，也是其最常被使用的功能之一。

在定义度量并确定它们是可加性事实、不可加性事实还是半可加性事实之后，您需要明确这些度量如何在商业智能中进行分析。确保执行分析的业务人员清楚所访问的度量类型，以防止不当使用数据，这是BI团队的责任。

维度

维度是用于建立企业所使用度量（事实）的业务上下文的实体。维度定义了维度模型中的谁、什么、哪里和为什么，并将类似的属性归类到一个类别或主题区域中。常见的维度示例包括产品、地理、客户、员工和时间。与数值型的事实不同，维度本质上是描述性的（尽管某些描述性信息，例如产品的列表价格，可能是数值型的）。创建维度使得事实能够将属性集中存储在一个位置，而不是在事实表的行数中重复存储。它们通过事实表中的外键相互连接，该外键指向相应的维度表。这是一种规范化级别——它消除了冗余。

维度的另一个好处是，除了节省存储空间并减少在网络中重复传输这些属性所需的带宽外，它还允许维度属性发生变更而不必修改底层的事实数据，从而避免了可能复杂且耗时的处理过程。

维度可防止数据库充斥冗余数据。将所有属性放在维度表中后，这些属性就不需要在事实表中重复。以亚马逊为例，单笔销售的数据会包含产品识别号，但不会重复该产品的所有属性（如颜色、描述、评论等）。这些属性存储在维度中，该产品每笔单笔销售只需指向这些属性即可。

示意图5

从业务角度来看，维度的主要目的是使用其属性基于绩效度量来筛选和分析数据。在图 9.6中，维度是产品，DimProduct，其属性包括名称、重量、尺寸、颜色和列表价格。当产品维度与销售事实表连接后，业务人员可以基于这些特定产品属性中的一个或多个来查看销售情况，例如按颜色或尺寸分析销售。

为了在分析中发挥作用，一个维度属性需要具备以下关键特征：

描述性的，以便业务人员和设计商业智能应用的人员能够理解。
完整的，没有缺失值。
唯一的，因为确保值能够被唯一标识至关重要。
有效的，以确保数据对业务有用。

维度层次结构

维度创建的业务上下文的另一个方面是，它们通常是层次化的；它们以企业会用来衡量自身的方式对事物进行分组。这些层次结构表示一对多关系。层次结构的示例包括：

组织结构，例如市场营销或销售组织。
产品或服务类别。
地理分组，例如销售区域。
时间。年可细分为季度、月、周、小时、天、分钟，直至秒。这是经典层次结构。

示意图6

图9.7 展示了地理维度 DimGeography，其属性定义了一个层次结构。该层次结构的最高级别是国家/ 地区（国家/地区代码），然后细分为州/省（州/省代码），再进一步细分为城市，最后到邮政编码。
此示例适用于美国和加拿大，但对于其他国家可能需要进行修改。

地理示例展示了层次结构，以及如何使用商业智能术语进行上钻、下钻和横向浏览。例如，您可以查看国家层面的销售数据，或下钻到更详细的州层面、城市层面，最后到邮政编码。这使您能够对数据进行聚合。如果数据组织得当，您可以使用SQL“Group By”语句，按该层次结构中的特定列或属性对数据进行分组，并适当地对数据求和。该求和操作将使用可加性事实或度量。

维度键和代理键

构建维度的一个关键概念是，维度表中的每一行都是唯一的。在维度表中，主键是单个字段，而事实表则使用外键的组合作为其主键。

示意图7

图9.8展示了两个维度，DimProduct 和地理维度（DimGeography）。每个维度都有单个字段，产品键用于 DimProduct，地理键用于地理维度（DimGeography），这些字段分别作为对应表的主键。

维代理键方面涌现的最佳实践之一是使用代理键作为主键，如图9.8所示。代理键通常由数据库系统生成，是一个值无意义的整数（有关解释，请参见下文关于智能键的部分）。日期和时间维度是对值无意义这一准则的公认例外，本章节稍后会对此进行说明。

注意：如果表中的最大行数大于 21 亿，则需要使用 bigint（大整数）或等效的数据类型，而不是 int（整数）。

在第8章中，我们讨论了在ER建模中指定主键的过程，即选择一个能够唯一标识实体的键。
如果有多个可能的键，则称为候选键，而未被选中的键则称为备用键。尽管事务系统已经创建了可用于维度模型的主键，但最佳实践是将该键指定为备用键，并创建代理键作为主键。

创建代理键的原因是：

从多个源系统收集维度数据时，这些系统通常使用不一致或不兼容的主键。
源系统的主键常随时间变化，不同时期可能采用不同的命名或编号规则。此外，随着时间推移，源应用程序可能被新系统取代，或因合并而产生系统替换的需求。
源系统维持主键一致性的时间可能短于企业分析需求所要求的期限。
源系统可能正在使用智能键。

另一项最佳实践是将源系统的主键作为维度中的备用键保留。这也称为源系统的自然键。
如果有多个源系统且每个系统都有自然键，则应添加一个用于标识源系统的属性。这将形成一个复合备用键来识别这些自然键。在图9.9中，CustomerSK是客户维度的主键，CustomerNK是维度中的自然键以及源系统中的主键，SOR_NK是记录系统（SOR）标识符，而复合备用键由 SOR_NK和CustomerNK列组成。

Dim_客户	Dim_客户
PK	客户SK
U1	SOR_NK 客户自然键

	称谓中间名姓名

示意图8

智能键

操作和事务系统有时使用智能键来定义或标识项目，例如产品。这些是字母数字字符串，长度可能为24或40个字符。该字符字符串通常被划分为子字符串，而这些子字符串具有特定含义，因此称为智能键。例如，前三个字符可能表示产品所建造的制造工厂，接下来的五个字符可能表示用于构造产品的材料，接下来的10个字符可能表示产品的尺寸或构造的其他特性，依此类推。

在1990年代和2000年代，当一些操作型系统被开发时，智能键是一种将大量信息放入键中的方法，尤其是在内存和存储有限的情况下。但如今，这种设计已对大多数操作系统造成了不利影响。原因主要有两点：

首先，在大多数操作系统中，智能键会随着时间而变化。其子字符串及其含义和定义都会发生变化。因此，当您试图获取该智能键的历史视图时，将会出现较大的不一致性。
其次，由于每个操作系统对其智能键的含义都有各自任意的定义，当一个企业拥有多个操作系统（而许多企业确实如此）时，这些键的不一致性使得在企业范围内唯一标识一个产品变得困难。

解决智能键问题的方法是创建代理键——一种无意义的键，作为维度中一致且唯一的标识符。

非空值

事实表中用作主键的外键不应包含空值。以下是一个空值分配示例：假设销售事实表中的一行数据在客户标识符列（该列为链接到客户维度的外键）中存在空值。在从源系统加载数据时， ETL 过程由于无法找到与该销售相关的客户（原因可能是该值未知、缺失或无效），因此将该列填入了空值。

空值对人员和商业智能工具都会造成困扰。如果你熟悉SQL，就会知道在使用包含空值或非空值的键进行连接查询时，查询结果是不同的。再次以我们的示例为例，销售事实表与客户维度表之间的连接只会包含客户键中有值（非空）的销售行数。这意味着，如果业务人员试图分析总销售额，那些客户键为空值的销售记录将会被遗漏。这种情况显然会导致误导性的分析，可能带来业务风险。如果其他外键也存在空值，这一问题可能会进一步加剧。

解决此潜在业务风险的最佳实践包括：

在维度值未知、缺失、无效或无法满足引用完整性等情况下，为每个维度创建相应的维度行。
由于代理键的编号约定使用正整数，因此可使用负整数（如−999 ）作为“缺失”行的键。
维度行包含代理键以及用于命名和描述它们的属性。应在所有维度中统一这些行的标准名称和描述，例如“缺失”、“未知”或“无效”。

至少为每个维度表指定一行以表示缺失值，但如果需要能够识别不同的条件，则应使用多行。
如果有多个条件需要处理，则应在所有维度中对这些条件使用标准的编号和命名方式。

这看似微不足道，但如果事实表的外键中存在空值，商业智能工具和带有连接的SQL查询一样，都会导致误导性或不准确的结果。这会使业务面临不必要的风险。

使用代理键作为维度主键的主要优势在于提供一个跨源系统和时间保持一致且唯一的标识符，并且独立于业务系统。代理键的另一个优势是，由于其基于整数，因此在关系模型中非常适合作为索引和连接的数据类型。

总之，维度应具备以下特征：

唯一行
用作主键的代理键
非空主键

模式

现在你已经了解了维度、事实和属性。是时候将这些部分组合起来，完成维度数据模型的拼图了。构建维度模型有三种模式：星型模式、雪花型模式和多维模式。

在构建维度模型时，通过考虑以下问题来选择要使用的模式：

您希望对这些数据进行何种分析，其复杂程度如何？
分析需求和限制是什么？
您想要查询和分析的数据一致性如何？
您计划使用哪种商业智能工具？尽管不同的工具可能看似展示相同类型的数据、结果和图表，但其底层实现可能大不相同，并且依赖于特定的模式以获得最佳效果。

星型模式

星型模式是维度模型中最常见的模式。它由一个事实表和多个围绕其周围的维度表组成，如图9.10所示。
该示例展示了一个事实，FactInternetSales；此示例是关于在线销售产品的。该事实的多个维度表为：

DimSalesTerritory—销售区域所在位置
DimPromotions—哪些促销活动正在销售产品
DimCurrency—使用的货币类型，例如美元或英镑
DimCustomer—谁在购买
DimDate—销售时间
DimProduct—他们正在销售的产品

示意图9

当然，通过不同维度表中的属性进行过滤或分组，使业务人员能够分析谁在购买、购买什么、他们的位置、购买时间以及是否使用促销活动进行购买。

星型模式是完全规范化与非规范化模型之间的一种折衷。事实表是维度模型中大部分数据存储的位置，因此将事实存储在规范化表中非常重要。这种规范化对于减少冗余、便于维护以及提高查询性能至关重要。

另一方面，维度是包含属性的非规范化表，如果使用第三范式数据模型，这些属性通常会分散在多个表中。在图9.10中，所列出的每个维度都在一个非规范化或“扁平化”的表中具有描述性属性。即使是在ER模型中每个层次级别都由单独实体表示的层次结构，在星型模式中也会被扁平化为一个维度表。

星型模式的优势在于其非常适合查询、性能和分析。它支持业务人员在电子表格中使用数据透视表时通常执行的任务，因此对他们来说非常直观。由于商业智能工具旨在充分利用星型模式结构，因此业务人员易于使用，并且具有快速的查询性能。

雪花模式

第二种维度模式是雪花型。它在星型模式的基础上更进一步，星型模式中的事实表被非规范化维度环绕，而雪花型则通过对特定维度内的层次结构进行规范化来实现。维度层次结构中的每一层都成为一个独立的维度表，并创建父键以将层次结构链接在一起。事实表存储指向维度层次结构最低层级的外键。

示意图10

图9.11 展示了一个雪花模式，其中销售事实 FactInternetSales 与产品维度 DimProduct 相关联。如果这是一个星型模式，事实表将直接指向 DimProduct，就像上面第一个表在图9.10 中所做的那样。但在雪花模式中，维度产品表被拆分为产品层级的后续层级。其组成部分包括：

DimProduct，这是层次结构的核心或最低级别。如果这是一家自行车商店，这可能指的是所销售的具体自行车、骑行短裤或水壶等产品。
DimProductSubcategory，为下一个级别，将各种产品归类到子类别中。对于自行车商店而言，与自行车相关的子类别可能包括公路车、山地车和混合型自行车。
DimProductCategory，为层次结构的最高级别。对于自行车商店而言，顶级类别可能包括自行车、服装和配件。

在此示例中，星型模式中的产品维度被拆分为三个表，以表示层次结构的三个级别——在雪花模式中分别为产品、产品子类别和产品类别。对互联网销售的产品数据进行汇总时，需要将销售事实表与产品层级结构的每一级进行连接，直到达到汇总所需的最高级别。

这种方法最常用于具有大量行数且层次结构较深但相对静态的维度。如果层次结构中的层级数量相对固定，开发人员更倾向于使用这种模型，因为它更接近源系统中使用的ER模型。

一些商业智能工具专门用于利用雪花模式。这些工具使用元数据（即关于维度雪花模型的定义）来生成报表和查询。然而，大多数商业智能工具将要求商业智能开发人员“展平”层次结构（参见第14章）。

尽管开发人员更倾向于使用雪花模式，因为它们更容易设计，但业务人员在分析时发现它们更难使用。因此，在维度建模领域通常不建议采用这种做法。但由于其在特定BI产品中提供的优势和速度，雪花模式仍然被使用。第10章将介绍其被使用的原因。

多维模式

第三种维度模型是多维模式。它是一种层次数据库，由一种结构即多维数组组成。为了帮助理解多维模式，可将其概念化为电子表格透视表，这近似于一个多维立方体。它在数组的各个层级中包含了所有详细数据和汇总数据。就像一个大型魔方，®如图9.12 所示。

该示例展示了具有产品、日期和地理维度的销售事实；立方体的其他“侧面”上还可以有更多维度。立方体的每个单元格都是一个实际的度量。根据用户需要从该立方体中获取的数据，不同维度的组合将引导他们找到包含所需数据的单元格，该数据位于多维数组中。维度属性和层次结构在多维产品的元数据中定义。

星型和雪花模式传统上存储在关系数据库中（有关其他选项的讨论，请参见第7章），而多维模式则存储在多维数据库中，也称为在线分析处理（OLAP）立方体。关系数据库使用 SQL以及特定的结构标准——表、列、外键，而多维数据库的结构则差异较大且通常为专有。

多维数据库在层次结构的各个层级上存储并聚合数据。它们支持上钻和下钻，意味着你可以从最低层级或最详细的数据逐级向上汇总数据，然后再通过层次结构向下返回。这些数据库专门设计用于处理多维数组，层次结构、立方体中哪些是可加的、哪些是半可加的以及哪些不是可加的。正如关系数据库需要定义表、列、约束等一样，多维数据库的元数据存储库中也需要定义事实、维度、层次结构等。

多事实星型模型

维度模型的示例，无论是星型、雪花型还是多维的，通常都用一个被维度包围的单一事实表来表示。尽管这是一种流行的图示方式，并且是一种简化说明的极佳方法，但实际情况是，企业中的数据需要多个事实。事实的示例包括销售、费用、库存以及与运营企业相关的许多其他业务事件。

示意图11

示意图12

图9.13 展示了两个事实：门店销售和门店库存（Tbl_Fact_Store_Sales 和 Tbl_Fact_Store_Inventory）。
右侧是这两个事实共享的三个维度：商品维度、日期维度和买家维度。这些共享的维度被称为一致性维度，这一概念将在本章节后面的内容中介绍。
示例的左侧是未在两个事实之间共享的客户和门店维度。Tbl_Dim_Customer 与 Tbl_Fact_Store_Sales 相关联，而 Tbl_Dim_Store 与 Tbl_Fact_Store_Inventory 相关联。

在实际案例中，可能存在数百或数千张表，这些表具有许多不同的维度组合，并共享各种事实组合。
尽管数据模型可能变得复杂，但将数据模型的子集可视化为星型有助于更好地理解和验证这些模型。

实体关系与维度建模

ER模型和维度模型都描述了相同的业务流程，但如图9.14所示，ER模型比维度模型包含显著更多的实体和关系。（您无需看清示例中的细节，此处仅用于高层次展示复杂性上的差异。）在上一章节中，您已见过ER建模与维度建模的类似对比：图8.3。

在维度模型中，维度是非规范化的，而事实是规范化的。此外，在维度模型中，仅根据分析需求和降低复杂性，从操作系统中选择部分事实。与ER模型相比，维度模型明显更简单、更易于导航且更易理解。

需要注意的是，如今大多数操作系统是购买的，而大多数分析系统是由信息技术部门定制构建的。因此，大多数信息技术部门会熟悉或使用维度建模方法，而非ER模型方法。

比较方法

实体关系建模（有时称为规范化建模）是事务系统（也称为操作型或联机事务处理（OLTP）系统）的标准。维度建模是商业智能和OLAP系统的最佳实践。其原因在于这两种系统处理和操作数据的方式不同。

操作型系统中的数据会不断更新。这些工作主力的主要任务是事务吞吐量。它们必须维护和更新大量记录，因此必须能够以大量数据实现高稳定吞吐量。

与商业智能与报表系统相比，这些系统通常不会更新数据，而是从操作系统中复制、抽取、转换和加载数据。它们不像操作系统那样进行实时更新。一旦数据被加载，重点就不再放在事务吞吐量上，而是在查询性能以及收集与聚合大规模数据集上。这是一个关键操作。事务系统经常更新少量的数据记录，而商业智能系统则较少进行操作，但会收集与聚合大量的数据记录—— 有时跨越很长的时间段。商业智能系统的数据随后被用于生成报表。参见表9.1以了解差异的总结。

操作系统及其配套的规范化模型具有最少的冗余，以支持高事务吞吐量。其有限的索引和对存储空间的高效利用消除了需要一致的数据，同时也促进了快速的事务吞吐量。该系统能够即时更新和维护记录。

另一方面，在商业智能报告中存在大量冗余。毕竟，数据仓库、数据集市以及你在报告端存储的其他内容，都是最初来自操作系统的数据的副本。商业智能系统高度依赖索引和分区，因为它需要更多的存储空间用于报告，而操作系统只需要内部一致性——它不必与其他系统的数据保持一致。商业智能需要从多个操作系统整合一致的数据，因此不一致性可能不仅存在于单个系统内部，还存在于各个系统之间。许多维度结构的设置旨在支持一致的信息。

由于操作系统没有冗余且索引使用有限，因此维护问题较少。然而，商业智能系统比操作系统有更多的维护问题，因为它存储了长期历史数据，而数据不易随时间保持良好状态。

为何这些结构至关重要

一个重要问题是：为什么这些结构对数据建模至关重要？每种结构都有其特定用途，您需要为当前任务选择合适的结构。这种选择高度依赖于数据的使用方式以及所使用的数据仓库或商业智能工具的类型。最佳实践是在联机事务处理系统中使用规范化实体关系模型。操作数据存储通常镜像联机事务处理系统的结构，并针对联机事务处理系统的操作报告进行优化。

另一方面，商业智能应用和与商业智能相关的数据存储更适合使用维度数据模型。在查询关系数据库时，采用星型或雪花模型的商业智能工具能够提供最佳性能。或者，如果BI应用是多维模型，则需要选择支持该特定多维模型的合适商业智能工具。

示意图13

图9.15 显示了ER模型一侧的较小数据子集，其中商店数据库是使用ER模型实现的。此示例展示了一个业务流程。在示例的顶部，客户拨打电话；该呼叫有类型。该客户呼叫与客户相关联，而客户又关联到一个客户订单实体，然后关联到订单明细项实体，再关联到该明细项被选中的位置，即缺货的位置。接着，示例将此关联到该商品所在目录的制造商。这种结构非常面向流程，且随着业务活动在特定业务流程中的推进，相关实体也会随之更新。

在示例的维度一侧，商店数据库的子集与ER模型一侧看起来大不相同。其中心是一个销售单元。销售事实表包含指向客户、地理、时间和产品的四个键。因此，左侧的ER模型体现的是面向过程和应用的设计，而右侧的维度模型则是数据和主题区域驱动的设计。维度模型的表数量更少，更易于理解，且较少关注业务流程。

维度建模的目的

现在你已经了解为什么维度建模是商业智能的最佳选择，接下来重要的是理解其目的以及它如何与业务报告相结合。企业中的业务人员可能永远不会直接看到实际的数据模型，但他们肯定会使用基于这些模型生成的报表或仪表板。因此，数据模型必须能够帮助生成清晰有效的报告与分析，从而最终帮助业务人员查看数据并为企业做出明智决策。维度建模非常适合生成业务人员所需的信息类型。这些模型常见的业务用途是在BI报表、OLAP分析或电子表格中展示事实（度量）和维度。这种数据可视化方式对于每天都在分析数据的数百万电子表格用户来说非常普遍。

示意图14

映射到业务报表

示意图15

图9.16 展示了一份业务报表，其中按销售额对顶级员工和顶级门店进行了排名。顶级员工的销售额以表格形式和条形图显示，顶级门店的销售额则以表格形式和饼图显示。事实（度量）在表格中以数字形式呈现，在图表中则通过条形或饼图的尺寸来表示。员工姓名列表和门店名称列表分别来自员工和门店维度的属性。尽管本示例中未显示，但通常该报表会提供过滤器，使业务人员能够选择员工或门店的特定属性，以进行更详细的分析。第14章讨论了BI界面设计选项。

映射到OLAP分析或电子表格

示意图16

图9.17 展示了业务用户在使用数据探索工具、OLAP立方体或电子表格透视表时所看到的视图。
在此类界面中，维度显示为标签和标题。在本示例中，维度包括销售区域、产品类别、产品子类别和时间（财年）。报告主体部分显示实际的销售额数据。示例还显示，在左侧的度量组下方列出了度量或事实，以及如客户、日期、员工、产品和销售区域等维度。电子表格、数据透视表或OLAP立方体的视觉方面都专门设置为利用维度模型。

事实表

在维度建模中，有三种类型的事实表：事务、周期性和累积事实。

事务事实表 在维度建模中最为常见。它们逐条记录业务事件或事务，并包含与该事件相关的所有数据。例如销售交易，如在亚马逊上购买书籍。该购买行为会被记录在销售的事务事实表中。
周期性事实表 记录特定时间点的数据快照，例如季度末的库存水平或月末的账户余额。每一行代表在特定时间点的一个事实。
累积事实表 为事件的整个生命周期存储一条记录，展示事件进展过程中的活动情况。一个使用互联网销售订单的例子是：首先记录第一个事件（订单），然后记录后续的日期和事件，例如下单时间，当信用卡交易被处理时，订单发货时，发货过程中的各个状态，以及最终送达客户时。

这些被称为角色扮演日期维度，示例中的事件分别称为订单日期、发货日期和送达日期。

表 9.2 事实表类型的比较	表 9.2 事实表类型的比较	表 9.2 事实表类型的比较	表 9.2 事实表类型的比较
属性	事务	周期性	累积
粒度	每笔交易一行	每个时间段一行	每个事件生命周期一行一个事件
日期维度	最低粒度级别	期末粒度	每行多个
维度数量	最少	平均	Most
事实	与交易相关	与期间相关	在…期间的众多事件生命周期
度量	可加的	不可加，取平均	需要推导
一致性维度	Yes	Yes	Yes
一致性事实	Yes	Yes	Yes
数据库大小	最大	较小	最小

表 9.2 显示了每种事实类型具有不同的属性或特征。

粒度：每个表的细粒度突显了第一个差异。最详细粒度存储在事务表中，每个与该事实相关的业务事件对应一行。周期性表的细节较少，每一行覆盖一个完整的时间段。例如，它不显示银行账户中的每笔交易，而是显示与月末或期末余额相关的一行。最后，最粗略的粒度和最少的行数是累积事实的情况。例如，你下了一个订单，与该订单数据相关的所有日期（如请求日期、已填写日期、发货日期等）都记录在同一行上，并且该记录会就地更新。

日期维度 ：这三个事实的日期维度在从事务表到累积事实表的过程中，表现出粒度级别的类似下降。例如，事务表可能显示某次销售的日期，周期性表可能显示第一季度销售额，因为它仅是周期结束时的数据，而累积事实表则可能显示销售周期各个阶段的所有日期。

维度数量 ：维度数量在事务中最少，在累积中最多，在周期性中居中。

事实：事实之间的区别在于，它们基于单个交易（例如您向支票账户存款）、整个时间段（例如您的月度余额）或事件生命周期期间的众多事件（例如向银行申请抵押贷款时涉及的多个步骤）。

度量：在事务表中，数值始终是可加的——你可以将存入支票账户的所有存款相加。在周期性表中，数值是半可加的，或是平均值。因此，银行可以计算你12个月度余额的平均值。在累积表中，数值必须是派生的。例如，它会派生出你首次联系银行申请抵押贷款的日期与签署最终文件的日期之间的时间差。

一致性维度和事实，以及数据库大小 ：所有三种类型的事实表都具有一致性维度和一致性事实。事务表的数据库大小最大，因为它需要存储大量交易；累积表的尺寸最小，周期性表的尺寸介于两者之间。

实现一致性

保持数据一致性是数据仓库和商业智能中的一个 recurring 主题。基于不一致数据做出决策的企业往往会犯下代价高昂的错误。数据一致性使我们认识到操作系统与数据仓库/商业智能系统之间的一个关键区别：操作系统只需在自身内部保持数据一致性；而另一方面，数据仓库或商业智能环境需要在多个操作系统之间保持数据一致性，有时甚至需要在企业外部保持一致性。

一致性维度

这种对一致性的需求使我们引入了一致性维度——即在整个企业范围内保持一致且经过统一的维度。这确保了任何与客户维度关联的事实都能获得一致的客户信息；由于这些一致性维度的存在，所有报表和分析都保持一致。

目前业界使用了几个与维度相关的术语：

主数据管理（MDM）
客户数据集成（CDI）
产品信息管理（PIM）

还有其他一些流行术语也被使用。它们都围绕着创建客户、产品、供应商、组织、位置和时间的主列表这一理念。这些全部都是维度，且都属于维度一致性范畴，以便能够进行报表和分析。

您始终以尽可能最细粒度或最详细的级别定义维度，有时这被称为原子级别。每个一致性维度都使用代理键作为主键，并且维度中的每一行都是唯一的。当您使维度保持一致或统一时，便可实现一致的报告。

一致性事实

伴随一致性维度的是一致性事实。在此上下文中，“一致性”也意味着标准化——即为事实、度量或关键绩效指标（KPI）定义标准的定义。定义一个事实、度量或 KPI 意味着定义业务规则、公式或算法、分配、过滤器以及将数据转化为对业务有用的信息所需的其他任何内容。示例包括计算收入、利润、标准成本、价格、利润率等。所有这些计算都在企业中每日进行。

在标准化事实时，有两个陷阱需要避免：“单一真相版本”和政治因素。

首先，你在了解企业资源规划（ERP）系统和数据仓库时，可能已经听说过“单一真相版本”这一说法。认为一个事实、度量或关键绩效指标（KPI）只有一种解释是过于简单的。在操作型层面，也就是业务运行的最详细层面上，根据不同的业务上下文，事实可能存在不同的解释或定义。这并不是指凭空捏造数字，或者因为不理解而产生不同解释。如果根据不同的方式计算，收入和利润可能会有不同的数值在业务链的不同环节，根据不同的业务流程，并为不同的业务部门而有所差异。销售团队、市场部门和制造部门都在销售、营销或生产相同的产品，但在公司业务周期中的不同位置，您会以不同的方式看待收入或利润计算，因为这取决于您的业务部门如何分配或分摊这些收入或利润。

这意味着你不会得到一个单一的利润率定义，而是会针对许多不同的流程获得不同的利润率定义。然而，每个流程需要在该流程中保持相同的度量，这就是一致性的体现。

要避免的第二个陷阱是认为数字与政治因素无关。通常，技术人员会认为，他们只需了解业务规则、公式和算法中的数字并将其记录下来即可。然而现实情况是，让企业各方就这些度量达成一致需要耗费大量时间。如果这些数字过去一直通过电子表格手动计算，那么在设计数据模型时，必须先将相关的业务规则和关系进行文档化并加以利用。一旦某个数字被纳入数据模型并实现共享，它就会变得可见、透明，并且必须得到各方认可。请花时间确保在您的数据模型中正确地记录了所需的度量。

高级维度和事实

维度建模在构建支持业务流程的复杂业务模型时，运用了许多概念、关系和方法。维度建模中使用的一些术语，例如“退化”，可能听起来较为深奥和晦涩。然而，随着您对高级维度建模的深入了解以及在实际中的应用，您将认识到理解这些术语及其应用的重要性。需要明确的是，这些并非仅仅是深奥的概念，实际上在表示业务以及支持报表和分析方面非常有用。

日期（或日历）维度

日期维度不仅是维度建模中的最佳实践，而且在其中起着核心作用，因为几乎每个事实表都至少包含一个日期，且大多数查询都在分析与日期相关的度量。尽管如此，许多人仍然不了解创建日期维度的必要性。让我们从这种维度的创建初衷开始谈起。

日期并不像看起来那么简单，因为其背后涉及的操作远比人们想象的要复杂。当业务人员查看一笔销售交易的日期时，他们会立即知道该销售发生的年份、季度和月份。他们还能判断该销售是否发生在需要分析的时间段内，例如上个月、上个季度，或比较今年本月与去年同期的月份。业务人员在不知不觉中已经完成了日期子串操作和数据运算。

几乎每个事实表都至少有一个属性是日期。该属性可能以DATE数据类型“2004 27 23 10 27, 2004 10 40 01918 ‐ ‐”的形式存储，更常见的是以格式“ ‐ ‐ : : . ”的DATETIME数据类型存储，或者较少见地以字母数字型字符字符串存储。

以下是需要在商业智能中对每次查询或分析的每一行上的每个日期应用的一些潜在的日期子串操作、计算或业务规则示例：

选择特定日历周期（如月、季度或年）的日期。这需要一个函数，用于提取正在检查的事实表中每一行上每个适用日期的特定DATE子字符串，以确定是否存在匹配。如果该周期比年更详细，则需要在层次结构（年‐季度‐月‐日）中包含高于该周期的每一级进行子字符串比较。
选择或比较具有 DATETIME数据类型的日期与比较具有 DATE 数据类型的日期不同。数据仓库中的许多日期具有DATETIME数据类型，因为事务系统在事务发生时记录了该级别的详细信息，并将此详细信息带入数据仓库。然而，企业进行的大部分分析都是基于DATE的。SQL 在将“ 2004‐10‐27”与DATETIME数据类型进行比较之前，会将其转换为默认时间“2004‐10‐27 00:00:00.000”。这样做是为了使它们能够匹配；它们必须具有相同的数据类型。因此，事件 “2004‐10‐27 23:40:01.918”将完全不会被选中，这会导致如果业务分析按DATE选择项目时数据出现错误。因此，每次比较具有DATETIME数据类型的日期时，都需要将其转换为DATE数据类型。
在标准日历日期和财政年度日历日期之间切换（如果两者不同）。存在基于政府规则的公式，可将标准日历日期转换为企业所使用的财政年度日历日期。
分配对企业具有重要意义的节假日或时间段，通常通过创建查找表或在报表或电子表格中手动编码日期列表来确定。
选择由日期函数计算的日历周期，例如季度、年内周数和年内天数。

在维度建模引入日期维度概念之前，每个BI应用在每次执行查询时都必须进行这些日期操作。

设计日期维度

示意图17

图9.18 描述了一个事实表（Fact_Store_Sales），其中包含一个外键（Date_SK），该外键链接到日历日期维度（Dim_Date）。尽管不同企业中数据维度的构成会因业务人员使用的报表过滤器和日期标题而有所不同，但其设计均遵循特定的设计标准和规范。

日期维度中必需的两列是主键和完整日期值。在我们的示例中，它们是Date_SK（主键和代理键）以及 Date_Value（完整日期值）。

对于第一个必填列主键，日期维度是维度建模规则中的一个例外情况，即维度表的代理键通常应为无意义的整数。最佳实践是将日期的代理键设为YYYYMMDD格式的整数，其中 YYYY代表四位数年份（1991），MM代表两位数月份（03），DD代表两位数日期（03），因此本例中结果为19910303。

如果使用诸如数据库 IDENTITY 数据类型之类的无意义代理键，则分配给任何日期的键将根据分配给维度的起始日期而变化。这意味着不同的维度表中为日期分配的值可能不同，从而导致不一致。相比之下，采用YYYYMMDD的约定可确保特定日期在每个日期维度表中具有相同的值。例如，1991年3月3日，在任何时间或由任何人生成的每个日期维度表中，其值均为19910303。

使用这种智能键具有多个优势：

众所周知
它符合 ISO 8601 日期和时间国际交换标准。
最重要的是，此约定建立了日期维度一致性，有助于在企业内实现数据共享。

第二个必填列通常存储在数据类型为 DATE 的列中，包含完整日期值，这一点至关重要，因为它在 ETL 过程中被用作查找列，以分配事实表中的日期外键。在我们的示例中，ETL 过程将源系统销售数据中的销售日期与日期维度（Dim_Date）中的相应行进行匹配，然后将外键（Date_SK）的值分配给销售事实表（Fact_Store_Sales）。

除了两个必填列外，还会填充各种列，以支持在报表和分析中对日期进行过滤、聚合、分组和标注。这些列可以根据业务需求为数值型或字母数字型。

一些常见的日期属性包括：

从日期子串派生的日历周期：年、月和日。
多个列代表相同日历周期的不同变体，例如月份全称“September”、三字符缩写“Sep”、波兰语翻译“Wrzesień”、数值型9、月份数字的字符形式“09”及其他变体。
通过日期函数派生的日历周期：季度、年内周数、年内天数、月内天数、周内天数等。
用作标志的列，用于指示某一天是否为工作日、周末、节假日等。这些标志会因企业、国家、业务线以及“浮动”节假日在不同年份而变化，可能导致在数据分析时使用国家特定或业务特定的日期维度。请注意，在BI环境中使用这些特定的日期维度不会影响加载事实表的抽取、转换和加载（ETL）过程或底层事实表的设计。
也可能标记对企业特定的季节性周期。例如，一家贺卡公司可能会标记主要购卡季节，如母亲节前的一段时间；而农业相关企业，如农用设备公司或化肥制造商，则会有生长季。

企业可能有两种日历：标准日历和财政年度日历。标准日历从适用年份的第一天开始，例如在美国为1月1日。财政年度日历则为政府和税务申报目的而设立。存在特定规则来定义具体参数，例如年度起始日期、每季度的开始日期以及每季度的长度。当标准日历与财政年度日历不同时，日期维度将包含每个日期行对应的标准日历周期和财政对应周期。

在商业智能架构中使用日期维度可以实现简化和整合。例如，使用日期维度意味着以下操作只需执行一次：

从源系统加载日期字段时，会为每个日期字段分配一个日期代理外键。
在加载日期维度时，执行数据子串和数据计算。
在加载日期维度时，生成标准与财政日历转换。
所有业务特定的日历标识符（如节假日）都被输入到日期维度中，作为单一查找表。

与此形成对比的是，没有日期维度的BI报表或业务分析。每次执行查询时，它们都需要对每一行中的每个日期字段执行这些相同的日期操作。对于每个报表或业务分析，这些日期操作可能会重复数千次甚至数百万次，在整个企业范围内更是难以计数！

使用日期维度的好处还包括以下几点：

查询速度更快，因为您在加载日期维度时仅执行一次日期操作，而无需像上面讨论的那样重复执行无数次。尽管每次日期操作耗时极短，但累积起来的影响比人们想象的要显著得多。
生产力得到提升，无论是业务人员还是信息技术人员，都无需再反复且冗余地将这些日期操作手动编码到每个BI仪表板、报告、查询或电子表格中。
一致性得以增强，因为日期仅定义一次，并在整个企业范围内统一使用，避免了不同的解释或出错的可能性。
分析能力也得到加强，得益于所有预建日期维度属性，这些属性将立即可供每个BI应用使用，供业务人员进行日历周期的过滤、聚合、分组和标注。

这个概念看似简单，但日期维度是维度建模中的一个基础性概念，能够带来显著的业务和技术好处。

时间维度

在企业中进行的大部分业务分析，例如同比周期、年初至今或季度至今分析，通常仅涉及 DATETIME数据类型的日期部分。例如，销售发生的具体一天中的时间通常并不需要，因为大多数企业绩效指标是按天、周、季度或年汇总的。使用一天中的时间进行绩效分析的示例包括容量规划和劳动力利用率，但通常情况下，一天中的时间数据并不相关，实际上可能造成混淆和误导。

这导致了处理一天中的时间的两种方法。

将一天中的时间作为事实

首先，如果每日时间分析在您的企业中无关紧要或仅有限使用，则时间被视为一个事实。对于事实表中的每个日期，创建两列。第一列应包含一个外键，该外键链接到日历日期维度，当一天中的时间无关紧要时，此维度将用于业务分析。第二列应同时包含日期和时间。即使看似没有业务分析需求，仍保留一天中的时间有多个实用原因：

通过对账事实表中的日期与事务系统中的日期来实现对账。
通过直接使用包含完整日期时间的事实列，支持偶尔进行的每日时间分析。由于此类分析很少执行，因此无需专门构建时间维度来支持（另一种处理一天中时间的方法）。
如果情况发生变化，每日时间分析成为业务需求，则由于事实属性中已包含日期时间，可通过采用下述第二种方法重新适配此类分析。

示意图18

图9.19中所示的示例展示了包含这两列的FactStoreSales表。第一列是外键OrderDateKey，它链接到日期维度DimOrderDate；第二列是OrderDate列，其中包含完整的日期时间数据。

将一天中的时间作为维度

采用第二种方法，时间被作为维度进行管理，因为业务上需要按一天中的时间来分析绩效度量。该方法为业务需要分析的每个日期在事实表中存储三列。包括之前另一种按一天中的时间处理方法中讨论的两列——指向日期维度的外键和一个存储完整日期时间的列。第三列是指向时间维度的外键，如图9.20所示，在先前示例的基础上增加了订单_时间键（外键），该键关联到维度_时间（时间维度）。

示意图19

设计时间维度时，最初需要考虑的问题是每日时间分析所需的粒度级别：小时、分钟、秒还是百分之一秒？随着细节级别的增加，行数显著增长：小时为24行，分钟为1440行，秒则达到86,400行。时间维度的粒度应恰好满足业务需求中的每日时间分析要求，不宜过细。这并不是因为数据库或商业智能工具无法处理到秒级别的数据，而是因为如果细节级别超出业务需求，商业智能工具的可视化和交互将变得更加繁琐。

时间维度的主键是代理键，通常从零（0）开始。它还包括一个包含一天中的时间的列，该列采用时间数据类型，或根据所使用的数据库对应的等效类型。其他列则用于分析中的过滤和描述性用途。示意图20 展示了一个粒度为小时的示例时间维度。时间_SK 是代理键，时间_值是表示一天中时间的列，其余列的示例包括12小时制时间；24小时制时间；上午或下午；以及一段示例文本描述。描述性列的选择基于业务分析需求。

示意图21

图9.22 展示了一个具有分钟粒度的时间维度。在该示例中，时间维度包含必需的代理键 Time_SK 和以 Time_Value 存储的时间值。该示例包含一组过滤和描述性列，但企业需要构建必要的列以支持其所需的时间维度业务分析。

时间段

每日时间分析在零售（线上和实体店）、餐饮、公用事业、电信和媒体（线上、有线电视和广播）等行业中被用于分析消费者行为。例如，通过一天中的时间来评估现有的绩效指标和活动效果。

这种每日时间分析通常基于时间分段范围的时间段进行。例如，如图9.23所示，一家连锁餐饮或媒体公司创建了一个模式，以在以下时间段内分析一天中的时间：早高峰为上午6:00– 9:00，上午晚些时候为上午9:00–11:30，午餐时间为上午11:30–下午2:30，放学时间为下午 2:30–4:00，晚高峰为下午4:00–7:00。尽管事实表和时间维度包含精确到分钟的粒度细节，但日内时间粒度实际上是这些时间段。在这些场景中的业务并不关心6:16 AM整具体发生了什么，因为这种细节层次属于“噪声”，并非业务需要采取行动的信息。

有两种方法可以使用时间段来支持每日时间分析。首先，如果使用时间作为维度，则在时间维度中添加更多列，并包含适当的时间段描述如图9.23所示。从实用角度来看，时间段不太可能保持不变，也不太可能只有一种将时间段分组为时间段的方法，但维度表使企业能够根据需要添加任意数量的附加列。

在事实表中实现时间但没有使用时间维度时，采用第二种方法。使用此方法创建值段维度，以定义与时间和一天中的时间段的关联。

这两种方法都优于在每个BI应用或对这些数据执行的SQL查询中手动编码时间段，因为手动编码是冗余的，可能存在不一致，通常缺乏文档记录，且不易修改。

示意图22

跨时区的日期和时间维度

如果企业的运营跨越多个时区，则在两个事实表中使用两个不同时区记录时间是一种最佳实践。第一个时间是在事实发生的本地时区记录的，例如呼叫中心所在的位置或包裹发货的位置。第二个时区对应一个用作基准来计算偏移量的全球标准时间。此模式的示例如图9.24所示图 9.24。

示意图23

通常，您可以在两个全球标准中选择一个：格林尼治标准时间（GMT）或企业总部的本地时区。例如，如果总部位于香港，则公司可以选择该地的本地时间作为其全球标准，以替代格林尼治标准时间。只要一切实现标准化，各个制造工厂、分支机构或办公室所处的时区就不再重要。系统将记录事件的本地时间和全球时间，以便业务能够协调统一事件发生的时间视图。

以两个时区表示时间的业务原因是由于执行了两种类型的每日时间分析：

在此示例中，业务部门（如呼叫中心和货运仓库）将在其本地时区的上下文中检查其绩效指标，例如响应时间和劳动力资源平衡分析。
企业高级管理层以及物流和销售等全球业务部门将基于全球标准时区，以24小时周期为基准进行有意义的分析来评估绩效指标。

替代方法，例如存储相对于GMT等基准的时区指示器或小时偏移，将依赖于在BI应用和电子表格中手动编码日期计算来实现分析。与使用维度过滤相比，手动编码有许多缺点，包括编码属性耗时更长、更高的维护成本以及分析中的不一致性。

角色扮演维度

事实表有时会多次引用一个维度作为外键。此类情况的示例如下：

与订单、发货和交付等不同事件相关的多个日期被记录在累积事实表中。
多个地址相关列用于标识不同的位置，如发货和账单地址。
与销售事实相关的多个人员，例如客户和销售人员，或劳动力相关分析中的员工及其经理。

这些外键中的每一个都将相同的维度链接起来，以表示该维度的不同角色。例如，日期可以表示订单、发货或交付日期。“角色扮演”一词描述了物理维度在不同业务上下文中的使用。

示意图24

尽管这个概念很容易理解，但对于关系数据库而言却有所不同；尽管事实表可以包含多个外键列并关联到同一个维度，但这些列无法在同一个查询中使用。例如，您将无法通过过滤发货日期和交付日期，从销售表中对日期维度进行查询。

为了支持角色扮演维度，需要为每个角色关联一个数据库实体。创建角色扮演维度实体有两种不同的方法：

为每个角色创建独立表
使用单一维度为每个角色创建视图
为每个角色创建视图显然是最佳实践。例如，参见图9.25中的元素
日期维度，Dim_Date。您只需存储一次，它将为每个适用的角色创建视图。
互联网销售事实，FactInternetSales。它包含三个不同的角色日期，最初均关联回DimDate。为这些日期角色中的每一个所定义的视图是：
订单日期维度视图，vDimOrderDate
维度日期视图，vDimDueDate
维度发货日期视图，vDimShipDate
总之，我们仅存储Dim_Date一次，为每个角色创建一个视图，事实表和外键则指向vDimOrderDate、vDimDueDate和vDimShipDate，而非原始的Dim_Date。

创建视图可以避免维护和更新多个物理表，节省空间，并实现业务分析所需的多路连接。

退化维度

操作系统通过使用业务流程文档（如采购订单、发票、旅行预订或演唱会门票）来跟踪事务和业务事件。所有这些流程文档都具有诸如订单、发票和预订编号等唯一参考标识符，这些标识符在支持的操作模式中用作实体的主键。

示意图25

图 9.26 展示了一个经销商销售事实，列出了链接到商店（商店键）、员工（员工键）、订单日期（OrderDateKey）以及其他唯一标识该事务的维度的外键。其中包含多个度量，例如订单数量和销售金额。还有两个属性客户采购单号和承运人跟踪号码，用于表示客户采购订单和销售的承运商跟踪编号的唯一标识符。在操作型系统中，这些属性会是关联到操作型相关实体的外键，但在维度模型中，它们不会链接到任何维度。在维度模型中，这些实体不存在维度需求，因为在操作型系统中与这些实体相关的属性已经存储在其他维度中。例如，采购订单会有客户创建的属性，这些属性将存储在客户和地址相关维度中。

这些属性本质上是不关联到任何维度的外键，被称为退化维度。这一概念常常引起混淆，但实际上它只是一个其属性存在于其他地方的维度。尽管为每个这样的属性创建维度非常诱人，但这些信息会与其他维度产生重复。以我们的示例为例，将承运人跟踪号或客户采购订单号单独分离出来，会导致重复，因为相同的属性将同时存储在经销商销售事实和采购订单维度中。

那么，是否存在需要复制该数据的情况呢？答案是不需要。最佳实践是不要将其作为单独的维度，而是将其放在维度之后的事务表中外键，以及在数值属性之前。示例 Fact_ResellerSales 显示了两个作为销售订单号和行项目编号主键的外键；然后我们有一系列指向各个维度的外键。

示例展示了两个退化维度——承运人跟踪编号和客户采购订单编号，后跟与互联网销售相关的实际度量。需要注意的是，这些退化维度并非可加的数值；它们仅仅是用于我们在此维度模型中未跟踪的业务流程的标识符。然而，我们保留这些编号是因为它们可以链接回操作型系统，如果我们需要审计结果或进行追溯，则必须拥有这些编号。此外，一些业务人员可能不会基于销售订单号进行查询，而是会基于客户采购订单编号进行查询。退化维度支持此类查询方式。

事件表

事实几乎总是包含度量，但也有例外。这些例外情况发生在业务事件未产生或监控任何可量化的度量时。这类事实被称为无事实事实或事件表。

无事实事实或事件的示例包括学生上课和患者就诊。在这两种情况下，这些事件本身都没有直接关联的度量。学生上课会产生已付学费，患者就诊会生成账单，但这些均与其他事实相关，并基于其他属性，例如学生注册的课程以及医生执行的诊疗程序。无论学生是否上课或患者是否取消预约，都会产生学费和账单。

尽管无事实事实没有直接关联的度量，但这并不意味着该事件不值得跟踪。例如，教师可以在课堂上记录出勤情况，并在学生名称旁边标记一个X。

示意图26

跟踪这些无事实事实的方法如图9.27所示。该示例说明，创建一个属性作为虚拟计数事实，其值设为1或0；1表示事件发生，即学生到课。这使得事实表与维度之间能够建立连接——对这些事件。这种无事实事实表是捕获没有自然数值型度量的事件的最佳实践。

该示例展示了一个事件或无事实事实表：
它包含一个 StudentAttendance 事实，该事实具有指向学生、教师、班级地点、上课日期以及课程本身的在外键Stu。dentAttendance事实表中列出了所有这些外键，最后一个项目“出勤班级”是虚拟计数器，设为1或0。如果学生出席，则所有这些外键均填入1。如果同时进行记录，也可以在学生未出席时填入0。通过列出每次课程的每位学生记录，可以通过对“出勤班级”求和来统计特定日期出席的学生人数。您还可以筛选值为0的记录以确定哪些学生未出席该课程。

然后，你可以通过筛选1来进行聚合，以执行趋势分析在无事实事实表中实现虚拟计数器属性，使得即使这些业务事件本身没有与之关联的数值型度量，也能够进行业务分析。

汇总事实表

正如我们所讨论的，事实表用于存储有关事务或代表特定业务流程的业务事件的数据。事实表是规范化的，并与操作系统中ER数据模型的业务实体相关联。如果遵循最佳实践，数据仓库模式就应如此设计；然而，当数据被转换为支持数据集市或多维数据集的模式时，可能会出现一些例外情况，这些例外被称为合并事实。

示意图27

汇总事实表是那些在操作系统、业务流程和数据仓库中原本相互独立的事实表，通过整合或合并以促进报告和分析。图9.28中的示例展示了一个事实表（图9.28）（Fact_SalesPerf ormance），该表整合了销售度量（实际销售额）、预测销售额（预测销售额）、一个计算得出的差异（预测差异）以及到多个一致性维度的外键——产品、客户、地理和测量期间。

汇总事实表的另一个常见用途是进行预算与实际费用绩效分析。

这些事实的整合源于所执行的业务分析类型以及商业智能早期所使用的报表工具和电子表格的功能。将预算或预测与实际业绩进行比较是一种非常常见的业务分析类型，因此迫切需要促进此类分析。对于许多报表工具和电子表格而言，最简单的方法就是将这些事实整合到一个表中（即非规范化或扁平化表）。

合并事实表时需要考虑的两个关键因素是：事实共享一致性维度，并且它们具有相同的粒度。获得相同级别的细节或粒度通常需要对其中一个底层事实表进行聚合。例如，销售或费用的预算或预测可能是按周或月的粒度，而销售可能被实时记录，费用可能按每日记录。如果合并后的事实表中的某个事实已被聚合，则使用该合并事实表进行分析的用户将无法获得底层的详细信息。

在数据仓库模式中维护独立的事实表，并仅在与商业智能相关的数据存储（如数据集市和多维数据集）中合并事实表，这是一种最佳实践。