如果我们在星型模式模型中拥有粗细分支,则Power BI应该

时间:2019-10-31 13:25:00

标签: powerbi relationship dax

该问题没有令人满意的答案。请鼓励回答或发表评论。

让我们考虑以下数据模型。我们的模型具有三个维度。如果需要命名,请选择(A)产品,(B)品牌,(C)地区。 B是A的容器,因此它是一个层次结构。一个品牌中的许多产品。表示为A,B,C,AB,ABC的表是仅包含唯一值的桥接表。

现在是问题:

  1. 在以下模型中,AB桥表是否必要?我们不能 将A和B表直接连接到ABC。

  2. 为所有尺寸创建笛卡尔积是一个好主意 在模型中作为中央桥表

  3. 我们应该将带有AB尺寸的预算表插入到AB桥接还是 桥接ABC?取决于第一个问题的答案。

  4. 我们应该如何将Advertising table插入模型?要桥接ABC或特别创建的桥接表BC,并且该表连接到ABC?

现在是架构:

   +-------+
   |       |
   |  A    +-----+
   |       |     |
   +-------+     |
                 |
                 v
   +-------+  +--+----+      +--------+      +------------+
   |       |  |       |      |        |      | Sales      |
   |  B    +-->  AB   +----->|  ABC   +----->|   ABC      |
   |       |  |       |      |        |      |            |
   +-------+  +--+----+      +---+----+      +------------+
                                 ^
                                 |
   +-------+                     |           +------------+
   |       |                     |           | Budget     |
   |  C    +---------------------+           |   AB       |
   |       |                                 |            |
   +-------+                                 +------------+


                                             +------------+
                                             | Advertizing|
                                             |   BC       |
                                             |            |
                                             +------------+

DAX桥接。

我喜欢在DAX中而不是在M中构造桥表。这有几个原因。首先,它是用简单的代码完成的。其次,由于我只看到源表(而不是桥),因此向查询编辑器引入了一些整理。

Bridge tables - DAX or M?

因此为A维创建桥看起来像这样:

#A =
DISTINCT (
    UNION (
        TOPN ( 0, ROW ( "A", "Apple" ) ),
        DISTINCT ( Sales[A] ),
        DISTINCT ( Budget[A] ),
        DISTINCT ( Advertizing[A] )
    )
)

AB桥将是这样创建的A和B的笛卡尔积:

AB =
CROSSJOIN (
    DISTINCT ( '#A'[A] ),
    DISTINCT ( '#B'[B] ),
    "A@B", COMBINEVALUES("@",'#A'[A], '#B'[B])
)

在收到第一个答案后进行更新。

赏金开始后,我不想编辑问题的内容。在获得第一个答案之后,我意识到层次结构是偶然地提出来的,这使您分心。您可以忘记层次结构,将维度A,B,C视为独立维度。

如果我们有许多独立的维度和一些表,例如具有联合维度的字典,我想重点介绍如何构建星型模式。例如,我们可以有一个按地区和品牌定义的销售预算,以及一个由product_color定义的广告预算。我们是否应该构建一个具有所有尺寸的中央桥台(ABC的笛卡尔积)?或者,中央桥台是否应具有许多尺寸的粗支?在第二种情况下,我们将使用[AB]-> [ABC] <-[BC]。

1 个答案:

答案 0 :(得分:4)

根据OP的评论于2019年11月6日更新

  
      
  1. 以下模型中是否需要AB桥表?我们不能将A和B表直接连接到ABC。
  2.   

不。不需要像ABABC这样的桥表。对于具有多个事实表的此类模型,建议使用多个star schema构建模型。只需在维度表和事实表之间建立直接的一对多关系,例如A -> SalesB -> SalesA -> BudgetB -> Budget。请注意,当您查看每个单个事实表时,事实表和所有相关的维度表都形成一个星型模式。

star schema model

  
      
  1. 为模型中的所有尺寸创建笛卡尔乘积作为中央桥表是一个好主意吗?
  2.   

不。将笛卡尔积将所有尺寸表合并为一个大尺寸表(简称为“关节尺寸表”)只是多余的。

当尺寸之间存在多对多关系时,通常需要两个尺寸之间的桥表。例如,当Customer可能属于多个Category时,将需要一个桥接表Customer Category。 OP提出的方案不是桥接表的用例。

关节尺寸表的缺点是,

  • 这需要额外的数据存储。如果ABC分别有100、100、1000行,则联合维表将有1000万行。假设如果您之后又添加了100行的新维度,那么维度行的数量将为10亿!这不经济。

  • 这需要额外的计算。当我们希望SalesA过滤时,引擎首先需要扫描联合尺寸表以提取与过滤A的值(可能是大量的行),然后引擎使用提取的联合尺寸表行中包含的关系关键字扫描Sales事实表。仅当维度的大小很小并且事实表很大时,这才可能起作用。但是在很多情况下,性能会很糟糕。

  • 这与业务数据无关。我认为这是最大的缺点。在模型中,Budget仅以维度AB的粒度定义。认为属于Budget实例的C是胡说八道。但是,为了在联合维表和Budget之间建立关系,我们需要调整Budget使其与C的特定实例相关。

  
      
  1. 我们应该将预算表与AB尺寸一起插入以桥接AB或桥接ABC吗?取决于第一个问题的答案。
  2.   

Budget应该与AB直接相关。因为Budget的粒度是模型中的每个AB

  
      
  1. 我们应该如何将Advertising table插入模型?要桥接ABC还是特别创建的桥接表BC,并且那个连接到ABC?
  2.   

建立关系B -> AdvertisingC -> Advertising


顺便说一句,您的模型中实际上没有多对多关系。可能有多个与Sales相关的Product记录,但是每个Sales记录只有一个Product,因此Product和{{1}之间的关系}是一对多的。同样适用于模型中的其他关系。

最好将其描述为“具有不同粒度的多个事实表”。


根据OP的评论于2019年11月6日添加

OP似乎对如何处理具有不同粒度的多个事实表感到困惑。我建议OP将受益于Marco Russo的this article,但我尝试在这里总结其要点。

基本上,OP提出的模型可以简化为星型模式模型,其中事实表SalesSalesBudget将放置在不同星型的中​​心。

问题在于某些维表由不同的事实表共享,而某些维则不共享。例如,维度AdvertisingABSales共享,而Budget仅与C相关。假设我们正在比较SalesSales。当我们按Budget细分报表时,C中应该显示什么值?答案可能因业务而异,但是在这里让我们认为Budget是空白的,因为我们在每个{{1}的级别上都没有定义Budget }。

这种情况的普遍接受的方法是,在度量中检查过滤器上下文,并仅在按相关维度过滤后才返回值。例如,仅当当前上下文在Budget上没有过滤器时,才计算总C

Budget

参考

于2019年11月11日添加

Analyzing Data with Power BI and Power Pivot for Excel详细介绍了数据建模的模式和最佳实践。

Understand star schema and the importance for Power BI说明了星型模式的功能和优点。此外,它还列出了其他常见的建模模式。

Best Way for work with Multiple Fact Tables是Microsoft Power BI社区论坛中的一个问答环节,其中提到链接表并不是处理多个事实表的最佳实践。