Microsoft Fabric 仓库中的维度建模

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

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

注意

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

提示

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

星型架构设计

星型架构是关系数据仓库采用的维度建模设计方法。 它是创建 Fabric 仓库时建议采用的设计方法。 星型架构包括事实数据表和维度表。

• 维度表描述与你的组织和分析要求相关的实体。 大致而言，它们代表你建模的内容。 内容可以是产品、人员、地点或任何其他概念，包括日期和时间。 有关详细信息和设计最佳做法，请参阅本系列中的维度表。
• 事实数据表存储与观察或事件关联的度量值。 它们可以存储销售订单、库存余货、汇率、温度读数等。 事实数据表包含维度键以及可聚合的粒度值。 有关详细信息和设计最佳做法，请参阅本系列中的事实数据表。

星型架构设计针对分析查询工作负载进行了优化。 因此，它被视为企业 Power BI 语义模型的先决条件。 分析查询涉及筛选、分组、排序和汇总数据。 事实数据在相关维度表的筛选器和分组上下文中进行汇总。

它之所以被称为星型架构，是因为事实数据表构成了星形的中心，而相关的维度表则构成了星形的各个点。

星型架构通常包含多个事实数据表，因此包含多个星形。

设计良好的星型架构提供高性能（关系）查询，因为表联接较少，并且索引有用的可能性更高。 此外，随着数据仓库设计的演变，星型架构通常需要低维护。 例如，向维度表添加一个新列以支持通过新属性进行分析是一项相对简单的任务。 随着数据仓库范围的发展，也会添加新的事实和维度。

通过提取、转换和加载 (ETL) 进程定期（或许每天）更新和加载维度模型中的表。 此过程将其数据与存储操作数据的源系统同步。 有关详细信息，请参阅此系列中的加载表。

Power BI 的维度建模

对于企业解决方案，Fabric 仓库中的维度模型是创建 Power BI 语义模型的建议先决条件。 维度模型不仅支持语义模型，而且也是其他体验（如机器学习模型）的数据来源。

但是，在特定情况中，它可能不是最佳方法。 例如，需要自由和敏捷性来快速行动且不依赖于 IT 的自助服务分析师可能会创建直接连接到源数据的语义模型。 在这种情况下，维度建模理论仍然适用。 该理论可帮助分析人员创建直观高效的模型，同时避免需要在数据仓库中创建和加载维度模型。 相反，可以使用 Power Query 创建准维模型，该模型定义要连接到和转换源数据以创建和加载语义模型表的逻辑。 有关详细信息，请参阅了解星型架构和 Power BI 的重要性。

重要

使用 Power Query 在语义模型中定义维度模型时，无法管理历史更改，这可能是准确分析过去所需要的。 如果这是一项要求，你应创建数据仓库并允许定期 ETL 进程捕获和适当存储维度更改。

规划数据仓库

你应将数据仓库的创建和维度模型的设计视为一项严肃而重要的任务。 这是因为数据仓库是数据平台的核心组件。 它应形成一个坚实的基础，以支持整个组织的分析和报告，从而支持决策过程。

为此，数据仓库应努力将高质量、一致性和历史上准确的数据存储为单一事实版本。 它应以快速的性能提供可理解且可导航的数据，并强制实施权限，使正确的数据只能由正确的人访问。 努力设计数据仓库以实现复原能力，从而使数据仓库能够随着需求的发展而适应变化。

数据仓库的成功实现取决于良好的规划。 有关战略和战术注意事项以及导致成功采用 Fabric 和数据仓库的拟办事项的信息，请参阅 Microsoft Fabric 采用蓝图。

提示

建议以迭代方式构建企业数据仓库。 首先从最重要的主题区域开始，然后随着时间的推移，根据优先级和资源，用其他主题领域扩展数据仓库。

相关内容

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