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

这个问题没有令人满意的答案。请感到鼓舞回答或评论。让我们考虑以下数据模型。我们的模型具有三个维度。如果需要命名，请选择（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] 最佳答案 根据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的特定实例相关。 我们应该将预算表与AB尺寸一起插入以桥接AB或桥接ABC吗？取决于第一个问题的答案。 C应直接与Budget和A相关。因为B的粒度是模型中的每个Budget和A。 我们应该如何将广告表插入模型？要桥接ABC还是特别创建的桥接表BC，并且那个连接到ABC？ 建立关系B和B -> Advertising。顺便说一句，您的模型中实际上没有多对多关系。可能有多个与C -> Advertising相关的Sales记录，但是每个Product记录只有一个Sales，因此Product和Product之间的关系是一对多的。同样适用于模型中的其他关系。最好将其描述为“具有不同粒度的多个事实表”。根据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是空白的，因为在每个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/