【问题标题】:Best practice to design fact table rollups for BI's Aggregate Navigation为 BI 的聚合导航设计事实表汇总的最佳实践
【发布时间】:2021-04-08 11:03:00
【问题描述】:

我正在尝试以正确的方式实现事实表及其汇总,以便有朝一日能够将其转移到某个 BI 系统

并且,基于Oracle's articleKimballGoups's article,据我了解,整个设计必须遵守严格的原则

那么,假设有一个表fact_sales

-----------------------------------------
| dim_store | dim_product | total_sales |
-----------------------------------------
|         1 |           1 |          10 |
|         1 |           2 |          20 |
|         2 |           3 |          20 |
-----------------------------------------

假设,需要创建另一个表,按商店汇总,省略产品列,所以,它看起来像这样,fact_sales_by_store

---------------------------
| dim_store | total_sales |
---------------------------
|         1 |          30 |
|         2 |          20 |
---------------------------

而且,我猜,事情并没有那么简单,要让 BI 的聚合导航正常工作,在维度上肯定有一些技巧,但我无法从文章中得到它

正如我所见/猜想的那样,暗淡和事实表之间必须是一些“逻辑表源”,还是一些层次结构暗淡?

您能否根据该示例进一步指出我?)谢谢

【问题讨论】:

  • 我不是 PowerBI 专家,但在过去 24 小时内没有其他人做出回应,我会试一试...据我所知,如果您创建一个PowerBI 中的聚合表,然后它将启用聚合导航。但是,如果您的外部源中已经有聚合表并想直接使用它们,则不能使用聚合导航,但可以使用 DAX 确定要查询的事实表

标签: database-design powerbi olap datamart


【解决方案1】:

对于任何现代 BI 应用程序(例如 Power BI),我根本不会创建聚合表。所使用的 BI 应用程序应该能够通过任意维度组合灵活地聚合数据。

可能存在比您概述的更复杂的要求,这证明创建两个具有不同粒度/粒度的事实表是合理的。在这种情况下,功能强大的 BI 工具可以将来自两个事实表的聚合汇总到一个输出数据集/视觉对象中。统一因素是任何常见的维度表。

【讨论】:

  • 出于性能原因创建聚合表,而不是因为 BI 工具无法创建聚合
  • 它们曾经使用过,但 Power BI 等应用不再需要它们。使用其 Vertipac(列存储)架构的聚合几乎总是优于 SQL 聚合。 OP链接的两篇文章都有5年以上的历史。金布尔集团于 2015 年关闭。
猜你喜欢
  • 2014-11-11
  • 1970-01-01
  • 2015-09-28
  • 2020-01-09
  • 1970-01-01
  • 2012-10-13
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多