gpt4 book ai didi

powerbi - Power BI应该在星型模式模型中有粗支还是细支

转载 作者:行者123 更新时间:2023-12-02 14:50:08 24 4
gpt4 key购买 nike

这个问题没有令人满意的答案。请感到鼓舞回答或评论。

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

现在的问题:


在以下模型中,AB桥接表是否必要?我们不能
将A和B表直接连接到ABC。
为所有尺寸创建笛卡尔积是一个好主意
在模型中作为中央桥台?
我们是否应该将预算表与AB尺寸一起插入以桥接AB或
桥接ABC?取决于第一个问题的答案。
我们应该如何将广告表插入模型?要桥接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]。

最佳答案

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



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



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

star schema model



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



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

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

关节尺寸表的缺点是


它需要额外的数据存储。如果ABC分别具有100、100、1000行,则关节尺寸表将具有1000万行。假设如果您之后又添加了一个具有100行的新维度,那么维度行的数量将为10亿!这不经济。
它需要额外的计算。当我们要用Sales过滤A时,引擎首先需要扫描联合尺寸表以提取与A过滤后的值匹配的行,该值可能是大量的行,然后引擎扫描< cc>事实表,其中包含提取的联合尺寸表行中包含的关系关键字。仅当维度的大小很小并且事实表很大时,这才可能起作用。但是在许多情况下,性能将是绝望的。
它与业务数据无关。我认为这是最大的缺点。在您的模型中,仅在尺寸SalesBudget的粒度中定义A。认为属于B实例的Budget是胡说八道。但是,为了在联合尺寸表和C之间建立关系,我们需要调整Budget使其与Budget的特定实例相关。




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



C应直接与BudgetA相关。因为B的粒度是模型中的每个BudgetA



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



建立关系BB -> Advertising



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

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



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

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

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

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

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

[Total Budget] :=
IF (
NOT ( ISFILTERED ( 'C' ) ),
SUM ( 'Budget'[Amount] )
)


参考资料

新增于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社区论坛中的一个问答环节,其中提到链接表不是处理多个事实表的最佳实践。

关于powerbi - Power BI应该在星型模式模型中有粗支还是细支,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/58644354/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com