Power BI 中的模式与数据建模
Source: Dev.to
Source: …
Power BI 中的数据建模
Power BI 往往让人联想到仪表板——彩色图表、大数字卡片、可点击的切片器以及精美的可视化。这些是用户交互的元素，所以自然会认为它们决定了报告的“好坏”。
实际上，仪表板只是最终层。在任何可视化出现在屏幕之前，关键决策已经完成。这些决策决定了报告是快还是慢、可靠还是误导、直观还是令人沮丧。这一步——往往是看不见的——就是数据建模。
数据建模是组织数据的过程，使 Power BI 能够理解数据代表什么以及不同数据之间的关联方式。它涉及决定：
- 需要哪些表？
- 每个表应该包含什么？
- 这些表应如何关联？
当结构设计良好时，Power BI 的表现会合乎逻辑且可预测。当结构不佳时，即使是简单的问题也可能返回混乱或错误的结果。换句话说，Power BI 报告的质量在第一个图表创建之前就已经决定。
Source: …
什么是 Power BI 中的 “Schema”
在 Power BI 中，**schema（模式）**是数据模型的整体结构。它不是抽象概念，而是你在 模型视图 中看到的 实际布局，包括表以及它们之间的关系。
Schema 能回答非常实际的问题：
- 模型中存在哪些表？
- 哪些表存放度量值，哪些表存放描述性数据？
- 当用户点击切片器时，Power BI 如何知道要包含哪些数据？
Power BI 并不像人类那样“推理”数据。它 遵循你定义的路径。Schema 决定了：
- 过滤器如何从一个表传播到另一个表，
- 总计和平均值如何计算，
- 当用户与报表交互时，可视化的响应速度有多快。
在 Power BI 模型中最常出现的两种 schema 模式是：
- 星型模式（Star schema）
- 雪花模式（Snowflake schema）
理解这两者的区别可以解释为什么有些 Power BI 模型感觉 简单且可靠，而另一些则显得 脆弱且不可预测。
事实表和维度表：了解它们的作用
大多数 Power BI 模型都是使用 两种表 构建的。了解每种表的作用是数据建模的基础。
事实表 – 记录发生了什么
事实表 用来记录事件。每一行代表一次实际发生的事情。
在像 Kenya crops data（肯尼亚作物数据）这样的数据集中，事实表中的单行可能表示：
- 某一种特定作物，
- 在某个特定县种植，
- 在某个特定年份或季节，
- 并且有可度量的结果，例如 千克产量。
由于这些事件会随时间反复记录，事实表通常：
- 规模非常大，
- 同一作物或县会出现多次，
- 侧重于可以 求和、求平均或计数 的数值。
事实表 不 解释作物是什么或县位于何处；它仅仅记录了某件事发生了。
维度表 – 为事件赋予意义
维度表 用来描述和为事实提供上下文。与其在事实表的每一行中重复名称和描述，这些信息会 一次性 存放在单独的表中，例如：
- Crop（作物） 表，存放作物名称和类型，
- County（县） 表，包含县名，
- Date（日期） 表，包含年份或季节。
维度表通常：
- 与事实表相比 变化缓慢，
- 包含描述性而非数值数据，
- 用于在报表中 筛选、分组和标记 结果。
当你在切片器中选择某个县或作物时，Power BI 会依赖 维度表 来确定应包含事实表中的哪些行。这种分离使得分析 既高效又准确。
星型模式：与 Power BI 思维方式相匹配的结构
星型模式是 Power BI 模型最有效且最广泛推荐的结构。
在星型模式中：
- 一个 事实表 位于中心（例如，作物产量记录）。
- 每个 维度表 直接连接到该事实表（作物、县、日期）。
- 维度表 不 相互连接。
星型模式中的过滤工作原理
当您在切片器中选择一个县时，Power BI：
- 查看 County 表。
- 确定所选县的唯一键。
- 直接沿关系到达事实表。
- 仅保留匹配的行。
- 使用这些行进行计算。
由于每个维度直接连接到事实表，过滤器直接作用于被分析的数据。Power BI 不 需要通过中间表传递过滤器，因此计算行为保持一致。这使得大部分分析 逻辑由结构本身处理，从而减少后期编写复杂 DAX 公式的需求。
为什么星型模式在 Power BI 中表现更好
Power BI 将数据存储在 列 中，并针对快速聚合进行优化。当关系 简单且明确 时，它的表现最佳。
在星型模式中，你会发现：
- Power BI 对任何筛选都遵循 一条明确的关系路径。
- 为回答查询所需的连接更少，从而加快计算速度。
- 避免歧义和循环关系，产生更可靠的结果。
- 模型更易于理解、维护和扩展。
结论
仪表板的视觉美化只是冰山一角。高性能、可信赖的 Power BI 报表的真正基础是精心设计的数据模型——最好是由明确划分的事实表和维度表构成的星型模式。在这层看不见的层面上投入时间，视觉效果就会自动变得既美观且可靠。
Source:
雪花模型：稍微复杂一点
雪花模型的概念与星型模型相同，但将描述性信息拆分到多个相关表中。
例如，数据可能不再把所有地点细节都存放在单个 County（县）表中，而是组织为：
- 一个存放县信息的 County 表，
- 一个存放地区信息的 Region 表，
- 一个存放国家信息的 Country 表。
当用户选择一个国家时，Power BI 必须走更长的路径才能到达数据：
- 从 Country 表开始。
- 移动到 Region 表。
- 移动到 County 表。
- 最后到达 Fact（事实）表。
每增加一步，Power BI 的处理工作量就会增加，并且如果任何关系不正确，错误的可能性也会提升。
虽然雪花模型可以减少数据重复，但它在 Power BI 中会带来挑战，因为过滤器必须通过多个表传播，且需要管理的关系更多。因此，预测计算的行为会变得更加困难。
基于此，雪花模型在源系统中很常见，但在报表阶段通常会被重新塑造成星型模型。
关系：表格实际如何协同工作
关系定义了表格之间的通信方式以及过滤器的流动方式。
当您在切片器中选择县、作物或年份时，Power BI 不会直接搜索事实表。它：
- 查看维度表，
- 确定匹配的键，
- 沿着关系到达事实表，且
- 相应地过滤事实行。
在一个设计良好的模型中：
- 每个维度表包含 唯一值（每种作物或每个县只出现一次），
- 事实表包含与这些值关联的 大量记录，
- 过滤器从 维度表流向事实表。
这映射了现实世界的逻辑：一个县可以有多条作物记录，而一种作物可以跨多个年份出现。
基数：理解“一”和“多”
基数 描述一个表中的行与另一个表中的行之间的对应数量。
| 类型 | 描述 |
|---|---|
| One‑to‑Many | 维度表中的一行对应事实表中的多行。 |
| One‑to‑One | 一行恰好匹配另一表中的一行（在报表中很少见）。 |
| Many‑to‑Many | 多行对应多行（如果处理不当可能导致总计重复） |
注意： 错误的基数仍可能产生结果，但这些结果可能 并不反映实际情况。
为什么良好的数据建模很重要
数据建模以三种关键方式影响每个 Power BI 报表。
性能
简单的结构减少处理工作，从而实现更快的可视化和更流畅的交互。
准确性
正确的关系确保每条事实只计一次，防止总计被夸大和平均值产生误导。
简洁性
清晰的模型使报表更易构建、理解和维护。复杂的 DAX 往往是模型需要改进的信号。
有效的模型通常：
- 将度量与描述分离，
- 在可能的情况下使用星型模式，
- 明确定义关系，
- 依赖模型处理逻辑，而不是强迫可视化进行补偿。
当这一基础稳固时，Power BI 更易使用，也更值得信赖。模式和数据建模直接决定 Power BI 是产生可靠洞察还是混乱结果。通过了解事实表和维度表、选择合适的模式以及仔细定义关系，分析师能够创建快速、准确且易于理解的报表。
欲了解更多信息，请访问 Microsoft 官方的 Power BI 指南。
欢迎在评论中分享您在 Power BI 项目中如何进行数据建模的经验。我们始终欢迎讨论和不同的观点。