通过

Microsoft Fabric 仓库中的维度建模：事实数据表

  • 项目

适用于：✅SQL 分析终结点和 Microsoft Fabric 中的仓库

注意

本文属于维度建模系列文章的一部分。 本系列重点介绍 Microsoft Fabric 仓库中与维度建模相关的指南和设计最佳做法。

本文提供了在维度模型中设计事实数据表的指南和最佳做法。 它为 Microsoft Fabric 中的仓库提供了实用指南，这是一种支持许多 T-SQL 功能的体验，比如创建表和管理表中的数据。 因此，你可以完全控制创建维度模型表并向其加载数据。

注意

在本文中，术语数据仓库是指企业数据仓库，该数据仓库可全面集成整个组织的关键数据。 相比之下，单独的术语仓库是指 Fabric 仓库，它是一种服务型软件 (SaaS) 关系数据库产品/服务，可用于实现数据仓库。 为清楚起见，后者在本文中被称为 Fabric 仓库。

提示

如果你不熟悉维度建模，请考虑将此系列文章作为你的第一步。 本文并非旨在提供有关维度建模设计的完整讨论。 有关更多信息，请直接参考广泛采用的已发布内容，如 Ralph Kimball 等创作的数据仓库工具包：维度建模的最终指南（第三版，2013 年）。

在维度模型中，事实数据表存储与观察或事件关联的度量。 它可以存储销售订单、库存余货、汇率、温度读数等。

事实数据表包括度量值，这些度量值通常是数值列，比如销售订单数量。 分析查询在维度筛选器和分组的上下文中汇总度量值（通过使用总和、计数、平均值和其他函数）。

事实数据表还包括维度键，它们用于确定事实的维度。 维度键值用于确定事实的粒度，即定义事实的原子级别。 例如，销售事实数据表中的订单日期维度键设置日期级别的事实粒度，而销售目标事实数据表中的目标日期维度键则可以在季度级别设置粒度。

注意

虽然可以以更高的粒度存储事实，但很难将度量值拆分为较低的粒度级别（如果需要）。 庞大的数据量和分析需求可能会为存储更高粒度的事实提供合理的理由，但代价是进行详细的分析。

若要轻松识别事实数据表，通常要为其名称加上前缀 f_ 或 Fact_。

事实数据表结构

若要描述事实数据表的结构，请考虑名为 f_Sales 的销售事实数据表的以下示例。 此示例应用了良好的设计做法。 后续部分将介绍每一组列。

CREATE TABLE f_Sales
(
    --Dimension keys
    OrderDate_Date_FK INT NOT NULL,
    ShipDate_Date_FK INT NOT NULL,
    Product_FK INT NOT NULL,
    Salesperson_FK INT NOT NULL,
    <…>
    
    --Attributes
    SalesOrderNo INT NOT NULL,
    SalesOrderLineNo SMALLINT NOT NULL,
    
    --Measures
    Quantity INT NOT NULL,
    <…>
    
    --Audit attributes
    AuditMissing BIT NOT NULL,
    AuditCreatedDate DATE NOT NULL,
    AuditCreatedBy VARCHAR(15) NOT NULL,
    AuditLastModifiedDate DATE NOT NULL,
    AuditLastModifiedBy VARCHAR(15) NOT NULL
);

主密钥

与示例中的情况一样，示例事实数据表没有主键。 这是因为它通常没有什么有用的目的，并且会不必要地增加表存储大小。 主键通常由一组维度键和属性表示。

维度键

示例事实数据表具有各种维度键，用于确定事实数据表的维度。 维度键是对相关维度中的代理键（或更高级别属性）的引用。

注意

这是一个不寻常的事实数据表，至少不包含一个日期维度键。

一个事实数据表可以多次引用某个维度。 在这种情况下，它被称为角色扮演维度。 在此示例中，事实数据表具有 OrderDate_Date_FK 和 ShipDate_Date_FK 维度键。 每个维度键表示不同的角色，但只有一个实际日期维度。

最好将每个维度键都设置为 NOT NULL。 在事实数据表加载期间，可以使用特殊维度成员来表示缺失、未知、N/A 或错误状态（如有必要）。

特性

示例事实数据表有两个属性。 属性提供其他信息并设置事实数据的粒度，但它们既不是维度键，也不是维度属性，也不是度量值。 在此示例中，属性列将存储销售订单信息。 其他示例可能包括跟踪号码或票证号码。 出于分析目的，一个属性可能会形成一个退化维度。

度量值

示例事实数据表还具有度量值，如 Quantity 列。 度量值列通常是数值列，常见的为累加列（这意味着可以使用其他聚合对列求和与汇总）。 有关详细信息，请参阅本文后面的度量类型。

审核属性

示例事实数据表还具有各种审核属性。 审核属性是可选的。 它们使你能够跟踪创建或修改事实记录的时间和方式，并且可以包括提取、转换和加载 (ETL) 进程中产生的诊断或故障排除信息。 例如，你将要跟踪谁（或哪些进程）更新了行，以及何时进行的更新。 审核属性还可以帮助诊断具有挑战性的问题，例如 ETL 进程何时意外停止。

事实数据表大小

事实数据表的大小各不相同。 其大小对应于维度、粒度、度量值数量和历史记录量。 与维度表相比，事实数据表范围更窄（列更少），但行更大，甚至是巨大（超过数十亿）。

事实设计概念

本节介绍各种事实设计概念。

事实数据表类型

有三种类型的事实数据表：

  • 交易事实数据表
  • 定期快照事实数据表
  • 累计快照事实数据表

交易事实数据表

交易事实数据表存储业务事件或交易。 每行均以维度键和度量值以及可选的其他属性存储事实。 所有数据在插入时都是完全已知的，并且永远不会更改（除非更正错误）。

通常，交易事实数据表以尽可能低的粒度级别存储事实，并包含在所有维度上累加的度量值。 存储每个销售订单行的销售事实数据表是交易事实数据表的一个很好的示例。

定期快照事实数据表

定期快照事实数据表以预定义的时间或特定时间间隔存储度量值。 它汇总了一段时间内的关键指标或性能指标，因此它对于趋势分析和监视随时间的变化非常有用。 度量值始终是半累加性的（稍后介绍）。

清单事实数据表是定期快照表的一个很好的示例。 它每天加载每种产品的日末库存余货。

当记录大量交易的成本很高，并且不支持任何有用的分析要求时，可以使用定时快照表来代替交易事实数据表。 例如，一天内可能有数百万种库存变动（这可以存储在交易事实数据表中），但分析只关注日末库存水平的趋势。

累计快照事实数据表

累计快照事实数据表存储跨明确定义的时间段或工作流累计的度量值。 它通常记录不同阶段或里程碑的业务流程状态，这可能需要数天、数周甚至数月才能完成。

事实数据行在流程中的第一个事件之后很快加载，然后在每次发生里程碑事件时，该行都会按可预测的顺序进行更新。 更新会继续到此流程完成时。

累计快照事实数据表具有多个日期维度键，每个键表示里程碑事件。 某些维度键可能会记录 N/A 状态，直到流程到达某个里程碑。 度量值通常会记录持续时间。 里程碑之间的持续时间可以提供对业务工作流或程序集流程的宝贵见解。

度量值类型

度量值通常以数值表示，常见为加法。 但是，某些度量值并不总是可以添加的。 这些度量值分为半累加性或非累加性。

累加性度量值

可跨任何维度对累加性度量值进行求和。 例如，订单数量和销售收入是累加性度量值（前提是收入以单一货币记录）。

半累加性度量值

只能跨特定维度对半累加性度量值进行求和。

下面是半累加性度量值的一些示例。

  • 不能跨其他时间段对定期快照事实数据表中的任何度量值进行求和。 例如，不应对夜间采样的库存物料的年限进行求和，但可以每晚计算货架上所有库存物料的年限。
  • 不能跨其他产品对清单事实数据表中的库存余货度量值进行求和。
  • 不能跨货币对具有货币维度键的销售事实数据表中的销售收入进行求和。

非累加性度量值

不能跨任何维度对非累加性度量值进行求和。 一个例子是温度读数，从本质上讲，将其添加到其他读数是没有意义的。

其他示例包括费率，比如单价和比率。 但是，更好的做法是存储用于计算比率的值，这样可以在需要时计算比率。 例如，销售事实的折扣百分比可以存储为折扣金额度量值（除以销售收入度量值）。 或者，不应随时间推移对货架上库存物料的年限进行求和，但你可能会观察到库存物料的平均年限趋势。

虽然有些度量值不能求和，但它们仍然是有效的度量值。 可以使用计数、非重复计数、最小值、最大值、平均值等来合并它们。 此外，非累加性度量值在计算中使用时也可能会变为可累加。 例如，单位价格乘以订单数量产生销售收入，这是累加性的。

无事实事实数据表

当事实数据表不包含任何度量值列时，称为无事实事实数据表。 无事实事实数据表通常记录事件或发生情况，如学生上课情况。 从分析的角度看，可以通过统计事实数据行来实现度量。

合并事实数据表

合并事实数据表表示将基本事实数据表汇总到更低的维度和/或更高的粒度。 其目的是加速常见查询维度的查询性能。

注意

Power BI 语义模型可以生成用户定义的合并来实现相同的结果，或通过使用 DirectQuery 存储模式来使用数据仓库合并事实数据表。

相关内容

在本系列的下一篇文章中，了解加载维度模型表的指南和设计最佳做法。