Power BI 数据建模：商业智能的星型架构设计

数据模型是每个 Power BI 报告的基础。精心设计的模型使 DAX 测量变得简单、查询性能快速且报告开发直观。设计不当的模型会让一切变得困难——测量需要复杂的解决方法，查询运行缓慢，开发人员花费更多的时间来对抗模型而不是构建洞察。

星型模式是分析数据模型的黄金标准，几十年来一直如此。为您的 ERP 和 CRM 系统提供支持的关系数据库旨在使用具有数十个互连表的规范化模式来提高事务效率。这种设计对于记录单个交易来说是最佳的，但对于聚合、比较和趋势分析来说却很糟糕。星型模式通过将数据分为事实表（发生的情况）和维度表（发生的情况的上下文）来重组相同的数据，以提高分析性能。

本指南涵盖专门针对 Power BI 的星型模式设计原则，包括如何构建事实表和维度表、配置关系、编写高效的 DAX 度量、利用计算组、实施时间智能以及使用复合模型连接到多个数据源。

要点

• 星型模式将数据分离为事实表（数值度量、外键）和维度表（描述性属性） --- 此结构针对 Power BI 的 VertiPaq 引擎进行了优化
• Power BI 模型中的每个关系都应从维度流向事实（一对多），并且仅在一个方向上进行交叉过滤
• DAX 度量在星型模式上的性能显着提高，因为 VertiPaq 可以有效压缩维度列并通过关系过滤事实
• 计算组用应用于所有基本度量的单一模式替换了数十个冗余度量（YTD、QTD、MTD、上一年）
• 时间智能需要专用的日期维度表 --- 切勿使用自动日期/时间或依赖事实表中的日期列
• 复合模型可让您将导入的数据与 DirectQuery 连接相结合，为您提供内存中的性能和实时查询的新鲜度
• 角色扮演维度（一张表用于多个关系角色）需要DAX的USERELATIONSHIP函数

---

星型模式基础知识

为什么 Power BI 采用星型架构

Power BI 的内存引擎 VertiPaq 使用列压缩来存储数据。它独立地压缩每一列，并且基数较低（唯一值很少）的列会大幅压缩——在 1000 万行中具有 40 个唯一值的“国家/地区”列几乎不会被压缩。具有高基数（许多唯一值）的列（例如事务 ID 或时间戳）压缩效果较差。

星型模式通过在狭窄的事实表中隔离高基数事务数据（日期、金额、数量）并将低基数描述性数据（名称、类别、区域）放置在单独的维度表中来利用这一点。结果是一个内存更小、查询速度更快的数据模型。

考虑一下差异。零售业务的非规范化平面表可能有 50 列：OrderDate、CustomerName、CustomerEmail、CustomerCity、CustomerCountry、CustomerSegment、ProductName、ProductCategory、ProductSubcategory、Brand、Supplier、SupplierCountry、Quantity、UnitPrice、Discount、TotalAmount 等。每行重复“美国”数千次，“电子”数百次，以及客户所下的每个订单的完整客户名称。

星型模式等效将其分为：

FactSales（狭窄，每个订单行一行）：OrderDateKey、CustomerKey、ProductKey、Quantity、UnitPrice、Discount、TotalAmount。

DimCustomer：客户密钥、客户名称、电子邮件、城市、国家/地区、段。

DimProduct：产品密钥、产品名称、类别、子类别、品牌。

DimDate：日期键、日期、年、季度、月份、月份名称、星期几。

事实表只有 7 列，而不是 50 列。每个维度表只将每个唯一值存储一次。 VertiPaq 将此结构的压缩效果比平面表好 3-5 倍，并且查询运行速度快 2-10 倍，因为引擎会过滤小维度表，然后仅解析事实表中的匹配行。

事实表：设计原则

事实表记录业务事件——销售、订单、发货、支持票、网络访问、生产运行。每一行代表一个事件或事件的一个行项目。

粒度定义。 粒度是事实表中的详细程度。精确定义并一致执行。销售事实表可能具有“每个订单行项目一行”或“每个每日产品销售摘要一行”的粒度。在单个事实表中混合粒度（有些行是单独的事务，有些是每日聚合）会产生极难调试的计算错误。

仅限外键。 事实表包含维度表的外键，而不是描述性属性。事实表不应包含“CustomerName”或“ProductCategory”——它们属于维度表。事实表具有 CustomerKey 和 ProductKey，它们链接到描述性详细信息所在的维度。

累加度量。 事实表中的数字列应该是累加的 --- 可以跨任何维度进行有意义求和的值。收入、数量、成本和折扣是累加的。百分比、比率和单价不具有累加性（您不能对不同产品的单价求和）。将组件（分子和分母）存储在事实表中并计算 DAX 度量中的比率。

避免事实中的计算列。 将计算列添加到事实表会增加表的内存占用量并增加刷新期间的处理时间。相反，在 DAX 度量中计算派生值，这些值在查询时计算并且不消耗存储。

维度表：设计原则

维度表描述了业务事件的“人物、事件、地点、时间、原因”。它们包含用户过滤、分组和切片所依据的属性。

代理键。 使用整数代理键（CustomerKey、ProductKey）作为维度表中的主键，而不是自然键（客户电子邮件、产品 SKU）。代理键更小，压缩效果更好，并且使模型免受源系统键变化的影响。

非规范化维度。 在星型模式中，维度表被故意非规范化。 DimProduct 表包含类别、子类别和品牌作为同一表中的列，而不是作为具有自己的键的单独规范化表。这与事务数据库设计相反，并且是有意为之的。非规范化维度可产生更快的查询和更简单的 DAX，因为 VertiPaq 引擎扫描单个表而不是连接多个表。

包括描述性层次结构。 如果用户从类别向下钻取到子类别再到产品，则所有三个级别都应该是 DimProduct 中的列。在定义此钻取路径的 Power BI 模型中创建层次结构对象。

缓慢变化的维度。 当维度属性随时间变化（客户移动城市、产品更改类别）时，您需要一个策略。类型 1（覆盖）最简单 --- 使用新值更新维度行。类型 2（添加新行）保留历史记录 --- 添加具有有效日期范围的新行，因此历史事务与当时当前的属性值相关联。类型 2 更为复杂，但在历史准确性很重要时（财务审计、监管报告）是必要的。

---

配置关系

Power BI 的关系规则

Power BI 关系定义表如何连接以及筛选器如何传播。建立正确的关系至关重要——不正确的关系会默默地产生错误的数字，这比产生错误更糟糕。

仅限一对多。 星型模式中的每个关系都将维度表（一侧）连接到事实表（多侧）。维度表的键列具有唯一值。事实表有重复值。 Power BI 会验证这一点并标记违规行为。如果 Power BI 检测到多对多关系，则需要解决建模问题。

单向交叉过滤。 在所有关系上将交叉过滤器方向设置为“单一”。这意味着过滤器从维度流向事实（当您在切片器中选择客户时，只有该客户的行出现在事实表视觉效果中），而不是从事实流回维度。双向过滤会在具有多个事实表的模型中创建不明确的过滤路径，除非在非常特定的情况下，否则应该避免。

活动关系与非活动关系。 Power BI 只允许任意两个表之间存在一种活动关系。如果事实表具有多个日期列（OrderDate、ShipDate、DeliveryDate），请创建一个活动关系（通常是 OrderDate 到 DimDate）并为其他关系创建非活动关系。在需要时使用 DAX 度量中的 USERELATIONSHIP 函数激活非活动关系：

Shipped Revenue =
CALCULATE(
    [Total Revenue],
    USERELATIONSHIP(FactSales[ShipDateKey], DimDate[DateKey])
)

角色扮演维度

角色扮演维度是在模型中充当多个角色的单个维度表。日期维度是最常见的示例 --- 它连接到事实表中的 OrderDate、ShipDate 和 DeliveryDate，在每个关系中扮演不同的“角色”。

在 Power BI 中，您可以通过两种方式处理角色扮演维度：

非活动关系 + USERELATIONSHIP（推荐）。 保留一个 DimDate 表，其中包含一个活动关系（与 OrderDate）以及与其他日期列的非活动关系。创建使用 USERELATIONSHIP 作为备用日期视角的度量。这使模型保持紧凑并避免数据重复。

重复维度表。 创建 DimDate 的单独副本（DimOrderDate、DimShipDate、DimDeliveryDate），每个副本都与其各自的事实列具有活动关系。从 DAX 角度来看，这种方法更简单（不需要用户关系），但会增加模型大小和维护负担。

对于大多数实现，首选非活动关系方法。它产生了更清晰的模型和更小的内存占用，但代价是 DAX 稍微冗长。

多对多关系

某些业务场景确实需要多对多关系。一个客户可以属于多个细分市场，一个产品可以参与多个促销活动，一个销售人员可以覆盖多个地区。星型模式通过桥接表来处理这些。

桥接表位于具有多对多关系的两个表之间，并且每个组合包含一行：

BridgeCustomerSegment：CustomerKey、SegmentKey

DimCustomer 连接到 BridgeCustomerSegment（CustomerKey 上的一对多）。 DimSegment 连接到 BridgeCustomerSegment（SegmentKey 上的一对多）。桥接表可以按分段过滤 FactSales，同时正确处理多个分段中的客户。

请谨慎对待桥接表——如果不与处理多对多分配的适当 DAX 度量配对，它们可能会产生重复计算。使用已知数据进行彻底测试，以验证总数是否正确。

---

DAX 指标：模式和表现

基本措施

每个分析模型都需要一组基本度量，这些度量对事实表列执行简单聚合。首先定义它们——它们充当更复杂计算的构建块。

Total Revenue = SUM(FactSales[TotalAmount])
Total Quantity = SUM(FactSales[Quantity])
Total Cost = SUM(FactSales[CostAmount])
Order Count = COUNTROWS(FactSales)
Average Order Value = DIVIDE([Total Revenue], [Order Count])
Gross Margin = DIVIDE([Total Revenue] - [Total Cost], [Total Revenue])

请注意，平均订单价值和毛利率引用了其他度量，而不是重复聚合逻辑。这是有意为之的——如果总收入的定义发生变化（例如，排除回报），下游指标会自动反映该变化。

计算：DAX 的核心

CALCULATE 是最重要的 DAX 函数。它评估修改后的过滤器上下文中的表达式。了解 CALCULATE 就是了解 DAX。

Revenue Last Year =
CALCULATE(
    [Total Revenue],
    SAMEPERIODLASTYEAR(DimDate[Date])
)

此度量采用“总收入”度量，并在日期范围向后移动一年的筛选上下文中对其进行评估。如果当前过滤器上下文是“2026 年 1 月”，则 CALCULATE 将其修改为“2025 年 1 月”并评估该修改上下文中的总收入。

CALCULATE 接受多个过滤器参数，并且它们根据其类型进行不同的交互：

表过滤器（如 SAMEPERIODLASTYEAR）替换该表列上的现有过滤器。如果视觉对象已有月份筛选器，SAMEPERIODLASTYEAR 会使用上一年的对应月份覆盖它。

布尔过滤器（如 DimProduct[Category] = "Electronics"）添加到现有上下文。如果视觉对象筛选为 2026 年，计算结果将显示 2026 年电子产品收入。

REMOVEFILTERS 清除现有过滤器。 CALCULATE([Total Revenue], REMOVEFILTERS(DimProduct[Category])) 返回所有类别的总收入，无论哪个类别过滤器处于活动状态。

可读性和性能变量

变量 (VAR) 计算一个值一次并多次引用它。它们使复杂的测量变得可读并消除冗余计算：

Revenue YoY Growth =
VAR CurrentRevenue = [Total Revenue]
VAR PriorRevenue = [Revenue Last Year]
VAR Growth = CurrentRevenue - PriorRevenue
VAR GrowthPct = DIVIDE(Growth, PriorRevenue)
RETURN
    GrowthPct

如果没有变量，此度量将多次计算[总收入]和[去年收入]（一次用于减法，一次用于除法），计算成本增加了一倍。变量确保每个变量只计算一次。

迭代器函数：何时使用它们

迭代器函数（SUMX、AVERAGEX、MAXX、MINX、COUNTX、RANKX）在表中逐行计算表达式。它们功能强大但价格昂贵——它们扫描指定表中的每一行。

当您需要在聚合之前进行行级计算时，请使用迭代器：

Weighted Average Price =
DIVIDE(
    SUMX(FactSales, FactSales[Quantity] * FactSales[UnitPrice]),
    SUM(FactSales[Quantity])
)

这无法通过简单的 SUM 来实现，因为在求和之前您需要将每行的数量乘以单价。迭代器 SUMX 处理这种逐行乘法。

当简单的聚合就足够时，请避免使用迭代器。 SUMX(FactSales, FactSales[TotalAmount]) 在功能上与 SUM(FactSales[TotalAmount]) 等效，但速度较慢，因为迭代器逐行扫描，而 SUM 利用列压缩。

---

计算组

计算组解决什么问题

在计算分组之前，具有 10 个基本度量（收入、数量、成本、利润等）和 5 个时间智能变量（YTD、QTD、MTD、上一年、上一年 YTD）的数据模型需要 50 个单独的度量。添加一项新的基本测量意味着再创建 5 种时间智能变体。添加一种新的时间智能模式意味着再创建 10 种度量。这种组合爆炸使得模型难以维护。

计算组通过定义一次时间智能模式并将其动态应用到任何度量来解决这个问题。

建立时间智能计算组

在 Power BI Desktop 中，通过模型视图或使用表格编辑器（提供更多控制）等外部工具创建计算组。

定义各时间智能模式的计算项：

当前： 无修改 --- 按原样返回度量。

SELECTEDMEASURE()

年初至今（年初至今）：

CALCULATE(
    SELECTEDMEASURE(),
    DATESYTD(DimDate[Date])
)

上一年：

CALCULATE(
    SELECTEDMEASURE(),
    SAMEPERIODLASTYEAR(DimDate[Date])
)

上一年年初至今：

CALCULATE(
    SELECTEDMEASURE(),
    DATESYTD(SAMEPERIODLASTYEAR(DimDate[Date]))
)

同比变化：

VAR CurrentValue = SELECTEDMEASURE()
VAR PriorValue = CALCULATE(SELECTEDMEASURE(), SAMEPERIODLASTYEAR(DimDate[Date]))
RETURN CurrentValue - PriorValue

同比变化百分比：

VAR CurrentValue = SELECTEDMEASURE()
VAR PriorValue = CALCULATE(SELECTEDMEASURE(), SAMEPERIODLASTYEAR(DimDate[Date]))
RETURN DIVIDE(CurrentValue - PriorValue, PriorValue)

定义后，用户将计算组放置在视觉对象的列轴或行轴中，Power BI 会将每个计算项应用于值池中的任何度量。一个包含 6 个项目的计算组取代了 60 个单独的测量（对于 10 个基本测量）。

格式化字符串表达式

每个计算项都可以有一个格式字符串表达式，该表达式根据计算动态更改数字格式：

对于绝对度量（当前、年初至今、上一年）：使用基本度量的格式。 对于百分比度量（同比变化百分比）：格式为百分比。

// Format string for YoY % Change
"0.0%;-0.0%;0.0%"

这可确保当用户在“当前”（显示 1,234,567 美元）和“同比变化百分比”（显示 12.5%）之间切换时，格式正确，无需手动干预。

---

时间智能

日期维度表

Power BI 中的时间智能需要专用的日期维度表。不要依赖自动日期/时间功能（在文件 → 选项 → 数据加载中禁用它）——它会为每个日期列创建隐藏的日期表，从而使您的模型膨胀并限制您的控制。

构建一个涵盖全部数据的日期维度表，并且每边至少包含一年。如果您最早的交易是 2020 年 1 月，则从 2019 年 1 月开始日期表。如果您的分析将包括 2027 年的预测，则从 2027 年 12 月结束。

日期维度表的基本列：

在 Power Query 中创建日期表或创建 DAX 计算表：

DimDate =
VAR StartDate = DATE(2019, 1, 1)
VAR EndDate = DATE(2027, 12, 31)
RETURN
ADDCOLUMNS(
    CALENDAR(StartDate, EndDate),
    "DateKey", YEAR([Date]) * 10000 + MONTH([Date]) * 100 + DAY([Date]),
    "Year", YEAR([Date]),
    "Quarter", "Q" & QUARTER([Date]),
    "MonthNumber", MONTH([Date]),
    "Month", FORMAT([Date], "MMMM"),
    "DayOfWeek", FORMAT([Date], "dddd"),
    "IsWeekend", WEEKDAY([Date], 2) >= 6
)

在 Power BI 中将表标记为日期表（表工具 → 标记为日期表 → 选择日期列）。这将启用内置时间智能功能。

常见时间智能模式

通过适当的日期维度，Power BI 的时间智能函数可以处理最常见的时间计算：

年初至今： DATESYTD(DimDate[Date]) 本季度至今： DATESQTD(DimDate[Date]) 本月至今： DATESMTD(DimDate[Date]) 去年同期： SAMEPERIODLASTYEAR(DimDate[Date]) 滚动 12 个月： DATESINPERIOD(DimDate[Date], MAX(DimDate[Date]), -12, MONTH) 平行周期： PARALLELPERIOD(DimDate[Date], -1, QUARTER)（相同大小的窗口向后移动）

这些函数在 CALCULATE 中使用时会修改日期过滤器上下文。仅当日期列来自标记为具有连续、完整日期范围的日期表的表时，它们才能正常工作。

财政日历支持

如果您组织的会计年度与日历年度不一致，请修改时间智能计算以使用会计日历：

Fiscal YTD Revenue =
CALCULATE(
    [Total Revenue],
    DATESYTD(DimDate[Date], "6/30")  -- Fiscal year ends June 30
)

DATESYTD 的第二个参数指定会计年度结束日期。所有 YTD 计算均使用会计年度边界而不是 12 月 31 日。

---

复合模型

何时使用复合模型

复合模型将导入的数据（存储在 VertiPaq 中）与 DirectQuery 数据（从源实时查询）组合在单个模型中。当您需要导入数据的性能用于历史分析和实时数据的新鲜度用于运营指标时，这种混合方法非常有价值。

常见场景：

历史+实时。 导入3年历史销售数据进行趋势分析（快速查询，对源数据库无影响）。通过 DirectQuery 连接到当月的数据以获得最新的运营视图。

中央模型 + 本地丰富。 通过 DirectQuery 连接到集中管理的数据集（确保您使用组织的受管定义）。添加中央模型中不存在的部门特定数据（预算目标、自定义分类）的本地导入表。

多个源系统。 从云数据仓库（Snowflake、Azure Synapse）导入数据，并通过 DirectQuery 连接到单个报告中的操作数据库（PostgreSQL、SQL Server），无需构建单独的 ETL 管道来整合它们。

复合模型架构

在复合模型中，每个表都有一种存储模式：

导入： 数据加载到 VertiPaq 内存中。最快的查询性能，但需要计划刷新才能更新。

DirectQuery： 从源实时查询数据。始终是最新的，但取决于源数据库性能。

双： 表已导入并可用于 DirectQuery。用于需要与导入和 DirectQuery 事实表相关的维度表。

设置将导入和 DirectQuery 事实桥接到“双”模式的维度表。这允许 VertiPaq 引擎在过滤导入事实时使用内存中副本，并在过滤 DirectQuery 事实时生成 SQL 查询。

性能考虑因素

复合模型引入了复杂性。 Queries that span Import and DirectQuery tables require Power BI to merge results from two different engines, which can be slow if the DirectQuery source is not optimized.

通过构建模型来最大程度地减少跨源联接，以便大多数分析查询都会命中导入表。仅对需要实时新鲜度的特定表使用 DirectQuery。在关系和筛选器中使用的列上对 DirectQuery 源表建立索引。

For organizations building complex Power BI data models, ECOSIRE's data modeling services provide expert guidance on star schema design, DAX optimization, and composite model architecture tailored to your specific data landscape and performance requirements.

---

模型优化

减小模型大小

大型模型消耗更多内存，刷新更慢，查询响应速度更慢。通过以下技术优化模型大小：

删除未使用的列。 如果某个列未在任何视觉、度量、关系或 RLS 规则中使用，请将其删除。即使没有视觉引用，每一列都会消耗内存。 Common offenders include auto-generated columns, audit columns (CreatedBy, ModifiedDate), and technical identifiers that serve no analytical purpose.

减少基数。 具有数百万个唯一值（时间戳、GUID、自由文本字段）的列压缩效果很差。将时间戳舍入到适当的粒度（每日、每小时）。将 GUID 替换为整数代理键。将自由文本字段移至单独的明细表，仅在钻取时查询该明细表。

使用适当的数据类型。 Power BI 存储“整数”比“小数”更有效。如果列仅包含整数（数量、计数），请将其类型设置为整数。 Text columns consume more memory than numeric columns of the same cardinality --- where possible, encode text categories as integers with a lookup dimension.

禁用自动日期/时间。 自动日期/时间功能为模型中的每个日期列创建一个隐藏的日期表。对于具有 10 个日期列的模型，即有 10 个隐藏日期表消耗内存。禁用此功能并改用单个显式日期维度。

查询性能诊断

使用 DAX Studio 分析超出 Power BI 内置性能分析器显示范围的查询性能。 DAX Studio 透露：

存储引擎查询。 发送到 VertiPaq 引擎的查询数量以及扫描的数据量。更少的查询扫描更少的数据意味着更好的性能。

公式引擎活动。 公式引擎做了多少工作（逐行计算、复杂表达式）。高公式引擎时间表示应重写措施以将更多工作推送给存储引擎。

查询计划。 DAX 查询的逻辑和物理执行计划，显示 Power BI 如何将度量分解为存储引擎查询和公式引擎操作。

交互式视觉效果的目标查询时间低于 500 毫秒。超过 2 秒的查询会让人感觉缓慢并阻碍仪表板的使用。如果特定视觉效果始终超过 2 秒，请简化其 DAX、减少其处理的数据量，或将其移至用户接受短暂等待的钻取页面。

---

常见问题解答

我应该在 Power BI 中使用星型架构还是雪花架构？

星型架构几乎总是 Power BI 的更好选择。雪花架构将维度表规范化为子表（类别 → 子类别 → 产品），这在关系数据库中运行良好，但在 Power BI 的 VertiPaq 引擎中创建不必要的联接。 VertiPaq 非常高效地压缩非规范化维度列，因此雪花节省的空间可以忽略不计，而额外关系的性能成本却是真实存在的。将维度展平为星型模式，除非您有特定的技术原因不这样做（例如非常大的维度表，其中包含您想要隔离的很少使用的高基数列）。

Power BI 中的最大数据集大小是多少？

Power BI Pro 支持高达 1GB 压缩的数据集。每用户高级版支持高达 100GB。高级容量（P1 及以上）支持高达 400GB 的大数据集存储。这些限制是指压缩后的内存大小，而不是源数据大小。 VertiPaq 通常以 10:1 的比例压缩数据，因此 1GB 的压缩数据集可能代表 10GB 的源数据。对于接近这些限制的数据集，请考虑使用 DirectQuery 进行聚合、增量刷新或复合模型以获取详细级别的数据。

如何处理星型模式中的多对多关系？

使用桥接表（也称为无事实事实表或联结表）。桥接表对于多对多关系中的每个组合都有一行，例如，对于每个客户群分配都有一行。创建从每个维度到桥接表的一对多关系。请注意，桥接表可能会导致重复计算；将它们与 DISTINCTCOUNT 度量配对，或使用 DAX 中的 CROSSFILTER 来控制过滤器传播。使用已知数据进行彻底测试，以确保总数正确。

我应该创建计算列还是 DAX 度量？

几乎在所有情况下，都优先选择度量而不是计算列。度量在查询时计算，不消耗存储空间。计算列在刷新期间计算并存储在内存中，从而增加了模型大小。仅当您需要可用于筛选、排序或关系的值时才使用计算列（您无法按切片器中的度量进行筛选，但可以按计算列进行筛选）。一个常见的例外是用户在切片器或表格视觉效果中需要的行级标签的串联列 (FullName = FirstName + " " + LastName)。

计算组如何与现有度量交互？

计算组通过将度量包装在计算项的表达式中来拦截度量评估。当视觉对象包含度量和计算组时，Power BI 通过 SELECTEDMEASURE() 函数将计算项应用于度量。这意味着您的基本措施不需要修改。但是，已经包含时间智能的度量（例如硬编码的 YTD 度量）将在顶部应用计算组，可能会产生双重应用。为了避免这种情况，请仅定义基本度量（简单聚合）并专门使用计算组来实现所有时间智能和比较逻辑。