该问题没有令人满意的答案。请鼓励回答或发表评论。
让我们考虑以下数据模型。我们的模型具有三个维度。如果需要命名,请选择(A)产品,(B)品牌,(C)地区。 B是A的容器,因此它是一个层次结构。一个品牌中的许多产品。表示为A,B,C,AB,ABC的表是仅包含唯一值的桥接表。
现在是问题:
在以下模型中,AB桥表是否必要?我们不能 将A和B表直接连接到ABC。
为所有尺寸创建笛卡尔积是一个好主意 在模型中作为中央桥表?
我们应该将带有AB尺寸的预算表插入到AB桥接还是 桥接ABC?取决于第一个问题的答案。
我们应该如何将Advertising table插入模型?要桥接ABC或特别创建的桥接表BC,并且该表连接到ABC?
现在是架构:
+-------+
| |
| A +-----+
| | |
+-------+ |
|
v
+-------+ +--+----+ +--------+ +------------+
| | | | | | | Sales |
| B +--> AB +----->| ABC +----->| ABC |
| | | | | | | |
+-------+ +--+----+ +---+----+ +------------+
^
|
+-------+ | +------------+
| | | | Budget |
| C +---------------------+ | AB |
| | | |
+-------+ +------------+
+------------+
| Advertizing|
| BC |
| |
+------------+
DAX桥接。
我喜欢在DAX中而不是在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]。
答案 0 :(得分:4)
根据OP的评论于2019年11月6日更新
- 以下模型中是否需要AB桥表?我们不能将A和B表直接连接到ABC。
不。不需要像AB
和ABC
这样的桥表。对于具有多个事实表的此类模型,建议使用多个star schema构建模型。只需在维度表和事实表之间建立直接的一对多关系,例如A -> Sales
,B -> Sales
,A -> Budget
和B -> Budget
。请注意,当您查看每个单个事实表时,事实表和所有相关的维度表都形成一个星型模式。
- 为模型中的所有尺寸创建笛卡尔乘积作为中央桥表是一个好主意吗?
不。将笛卡尔积将所有尺寸表合并为一个大尺寸表(简称为“关节尺寸表”)只是多余的。
当尺寸之间存在多对多关系时,通常需要两个尺寸之间的桥表。例如,当Customer
可能属于多个Category
时,将需要一个桥接表Customer Category
。 OP提出的方案不是桥接表的用例。
关节尺寸表的缺点是,
这需要额外的数据存储。如果A
,B
,C
分别有100、100、1000行,则联合维表将有1000万行。假设如果您之后又添加了100行的新维度,那么维度行的数量将为10亿!这不经济。
这需要额外的计算。当我们希望Sales
被A
过滤时,引擎首先需要扫描联合尺寸表以提取与过滤A
的值(可能是大量的行),然后引擎使用提取的联合尺寸表行中包含的关系关键字扫描Sales
事实表。仅当维度的大小很小并且事实表很大时,这才可能起作用。但是在很多情况下,性能会很糟糕。
这与业务数据无关。我认为这是最大的缺点。在模型中,Budget
仅以维度A
和B
的粒度定义。认为属于Budget
实例的C
是胡说八道。但是,为了在联合维表和Budget
之间建立关系,我们需要调整Budget
使其与C
的特定实例相关。
- 我们应该将预算表与AB尺寸一起插入以桥接AB或桥接ABC吗?取决于第一个问题的答案。
Budget
应该与A
和B
直接相关。因为Budget
的粒度是模型中的每个A
和B
。
- 我们应该如何将Advertising table插入模型?要桥接ABC还是特别创建的桥接表BC,并且那个连接到ABC?
建立关系B -> Advertising
和C -> Advertising
。
顺便说一句,您的模型中实际上没有多对多关系。可能有多个与Sales
相关的Product
记录,但是每个Sales
记录只有一个Product
,因此Product
和{{1}之间的关系}是一对多的。同样适用于模型中的其他关系。
最好将其描述为“具有不同粒度的多个事实表”。
根据OP的评论于2019年11月6日添加
OP似乎对如何处理具有不同粒度的多个事实表感到困惑。我建议OP将受益于Marco Russo的this article,但我尝试在这里总结其要点。
基本上,OP提出的模型可以简化为星型模式模型,其中事实表Sales
,Sales
和Budget
将放置在不同星型的中心。
问题在于某些维表由不同的事实表共享,而某些维则不共享。例如,维度Advertising
和A
由B
和Sales
共享,而Budget
仅与C
相关。假设我们正在比较Sales
和Sales
。当我们按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社区论坛中的一个问答环节,其中提到链接表并不是处理多个事实表的最佳实践。