Power BI 我们应该在星型模式模型中有粗分支还是细分支
Power BI should we have thick or thin branches in star schema model
这个问题没有满意的答案。请鼓励回答或发表评论。
让我们考虑以下数据模型。我们的模型中有三个维度。如果您需要命名它们，可以是 (A) 产品，(B) 品牌，(C) 地区。 B是A的容器，所以是层次结构。一个品牌的许多产品。表示为 A、B、C、AB、ABC 的 table 是仅包含唯一值的桥 table。
现在问题：
AB桥table在下面的型号中有必要吗？难道我们不能
将 A 和 B tables 直接连接到 ABC。
为所有维度创建笛卡尔积是个好主意吗
在模型中作为 中央桥 Table?
我们应该将预算 table 与 AB 维度相结合以桥接 AB 还是
桥ABC？取决于第一个问题的答案。
我们应该如何将广告 table 插入模型？桥接 ABC 或特别创建的桥 table BC 和那个连接到 ABC?
现在架构：
+-------+
| |
| A +-----+
| | |
+-------+ |
|
v
+-------+ +--+----+ +--------+ +------------+
| | | | | | | Sales |
| B +--> AB +----->| ABC +----->| ABC |
| | | | | | | |
+-------+ +--+----+ +---+----+ +------------+
^
|
+-------+ | +------------+
| | | | Budget |
| C +---------------------+ | AB |
| | | |
+-------+ +------------+
+------------+
| Advertizing|
| BC |
| |
+------------+
DAX 桥接。
我喜欢在 DAX 中构建桥梁 tables，而不是在 M 中。这有几个原因。首先，它是用简单的代码完成的。其次，它为查询编辑器引入了某种整洁，因为我看到那里只有源 tables（不是桥）。
因此，为 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 视为独立的维度。
我想专注于如何构建星型模式，以防我们有许多独立的维度和一些 tables，比如具有连接维度的字典。例如，我们可以按地区和品牌定义销售预算，按 product_color 定义广告预算。我们是否应该建造一个具有所有维度（ABC 的笛卡尔积）的中央桥 table？或者，中央桥 table 是否应该有许多维度的粗分支？在第二种情况下，我们将有 [AB] -> [ABC] <- [BC].
根据 OP
的评论于 2019 年 11 月 6 日更新
- Is the AB bridge table necessary in the following model? Couldn't we connect A and B tables directly to ABC.
没有。没有必要像 AB 和 ABC 这样的桥接 table。对于这样的模型，其中有多个事实 table，建议使用多个 star schema 构建模型。直接在维度tables和事实tables之间建立一对多关系，例如A -> Sales、B -> Sales、A -> Budget和[=16] =].请注意，当您查看每个单独的事实 table 时，事实 table 和所有相关维度 table 形成一个星型模式。
- Is it a good idea to create Cartesian product for all the dimensions in the model as a Central Bridge Table?
没有。将所有维度 table 的笛卡尔乘积变成一个大维度 table（我们称之为 "joint dimension table"）只是多余的。
当维度之间存在多对多关系时，通常需要两个维度之间的桥梁 table。例如，当 Customer 可能属于多个 Category 时，就需要一个桥梁 table Customer Category。 OP呈现的场景不是网桥的用例table.
关节尺寸的缺点 table 是，
需要额外的数据存储。如果A,B,C有100,100,1000行，联合维度 table 将有 1000 万行。假设你之后转而增加一个100行的新维度，那么维度行数就是10亿！这样不划算。
需要额外的计算。当我们想要Sales被A过滤时，引擎首先需要扫描联合维度table 以提取与过滤值 A 匹配的行，这可能是大量的行，然后引擎扫描 Sales 事实 table 与关系键包含在提取的联合维度 table 行中。这可能仅在维度的大小非常小且事实 table 非常大时才有效。但是在很多情况下，表现会很绝望
是业务数据的无关表示。我认为这是最大的缺点。在您的模型中，Budget 仅定义在维度 A 和 B 的粒度中。认为属于C实例的Budget是无稽之谈。但是，为了在关节维度 table 和 Budget 之间建立关系，我们需要调整 Budget 使其与 C.[=77= 的特定实例相关联]
- Should we plug Budget table with AB dimensions to bridge AB or to bridge ABC? Depending on what is the answer to first question.
Budget 应该与 A 和 B 直接相关。因为 Budget 的粒度在您的模型中是每个 A 和 B。
- How should we plug Advertizing table to the model? To bridge ABC or to especially created bridge table BC and that one connect to ABC?
建立关系 B -> Advertising 和 C -> Advertising。
顺便说一句，您的模型中实际上没有多对多关系。一个Product可能有多个Sales记录，但每个Sales记录只有一个Product，所以Product和[=23=之间的关系] 是一对多的。这同样适用于模型中的其他关系。
最好描述为 "multiple fact tables with different granularity"。
根据 OP
的评论于 2019 年 11 月 6 日添加
看起来 OP 对如何处理具有不同粒度的多个事实 table 感到困惑。我建议 OP 将受益于 Marco Russo 的 this article，但我尝试在这里总结本质。
基本上，OP 呈现的模型可以简化为星型模式模型，其中将放置事实 tables Sales、Budget 和 Advertising在不同星星的中心。
问题在于某些维度 table 被不同的事实 table 共享，而某些维度不共享。例如，维度 A 和 B 由 Sales 和 Budget 共享，而 C 仅与 Sales 相关。假设我们正在比较 Sales 和 Budget。当我们按 C 向下钻取报表时，Budget 中应该显示什么值？答案可能因业务而异，但在这里假设我们期望 Budget 为 空白 ，因为我们没有在每个 Budget 级别定义=22=].
这种情况普遍接受的方法是，仅在按相关维度过滤时检查度量中的过滤上下文和 return 值。例如，仅当当前上下文在 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 社区论坛中的一个问答线程，其中提到 link table 不是处理多个事实 table 的最佳实践.
这个问题没有满意的答案。请鼓励回答或发表评论。
让我们考虑以下数据模型。我们的模型中有三个维度。如果您需要命名它们，可以是 (A) 产品，(B) 品牌，(C) 地区。 B是A的容器，所以是层次结构。一个品牌的许多产品。表示为 A、B、C、AB、ABC 的 table 是仅包含唯一值的桥 table。
现在问题：
AB桥table在下面的型号中有必要吗？难道我们不能 将 A 和 B tables 直接连接到 ABC。
为所有维度创建笛卡尔积是个好主意吗 在模型中作为 中央桥 Table?
我们应该将预算 table 与 AB 维度相结合以桥接 AB 还是 桥ABC？取决于第一个问题的答案。
我们应该如何将广告 table 插入模型？桥接 ABC 或特别创建的桥 table BC 和那个连接到 ABC?
现在架构：
+-------+
| |
| A +-----+
| | |
+-------+ |
|
v
+-------+ +--+----+ +--------+ +------------+
| | | | | | | Sales |
| B +--> AB +----->| ABC +----->| ABC |
| | | | | | | |
+-------+ +--+----+ +---+----+ +------------+
^
|
+-------+ | +------------+
| | | | Budget |
| C +---------------------+ | AB |
| | | |
+-------+ +------------+
+------------+
| Advertizing|
| BC |
| |
+------------+
DAX 桥接。
我喜欢在 DAX 中构建桥梁 tables，而不是在 M 中。这有几个原因。首先，它是用简单的代码完成的。其次，它为查询编辑器引入了某种整洁，因为我看到那里只有源 tables（不是桥）。
因此，为 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 视为独立的维度。
我想专注于如何构建星型模式，以防我们有许多独立的维度和一些 tables，比如具有连接维度的字典。例如，我们可以按地区和品牌定义销售预算，按 product_color 定义广告预算。我们是否应该建造一个具有所有维度（ABC 的笛卡尔积）的中央桥 table？或者，中央桥 table 是否应该有许多维度的粗分支？在第二种情况下，我们将有 [AB] -> [ABC] <- [BC].
根据 OP
的评论于 2019 年 11 月 6 日更新
- Is the AB bridge table necessary in the following model? Couldn't we connect A and B tables directly to ABC.
没有。没有必要像 AB 和 ABC 这样的桥接 table。对于这样的模型，其中有多个事实 table，建议使用多个 star schema 构建模型。直接在维度tables和事实tables之间建立一对多关系，例如A -> Sales、B -> Sales、A -> Budget和[=16] =].请注意，当您查看每个单独的事实 table 时，事实 table 和所有相关维度 table 形成一个星型模式。
- Is it a good idea to create Cartesian product for all the dimensions in the model as a Central Bridge Table?
没有。将所有维度 table 的笛卡尔乘积变成一个大维度 table（我们称之为 "joint dimension table"）只是多余的。
当维度之间存在多对多关系时，通常需要两个维度之间的桥梁 table。例如，当 Customer 可能属于多个 Category 时，就需要一个桥梁 table Customer Category。 OP呈现的场景不是网桥的用例table.
关节尺寸的缺点 table 是，
需要额外的数据存储。如果
A,B,C有100,100,1000行，联合维度 table 将有 1000 万行。假设你之后转而增加一个100行的新维度，那么维度行数就是10亿！这样不划算。需要额外的计算。当我们想要
Sales被A过滤时，引擎首先需要扫描联合维度table 以提取与过滤值A匹配的行，这可能是大量的行，然后引擎扫描Sales事实 table 与关系键包含在提取的联合维度 table 行中。这可能仅在维度的大小非常小且事实 table 非常大时才有效。但是在很多情况下，表现会很绝望是业务数据的无关表示。我认为这是最大的缺点。在您的模型中，
Budget仅定义在维度A和B的粒度中。认为属于C实例的Budget是无稽之谈。但是，为了在关节维度 table 和Budget之间建立关系，我们需要调整Budget使其与C.[=77= 的特定实例相关联]
- Should we plug Budget table with AB dimensions to bridge AB or to bridge ABC? Depending on what is the answer to first question.
Budget 应该与 A 和 B 直接相关。因为 Budget 的粒度在您的模型中是每个 A 和 B。
- How should we plug Advertizing table to the model? To bridge ABC or to especially created bridge table BC and that one connect to ABC?
建立关系 B -> Advertising 和 C -> Advertising。
顺便说一句，您的模型中实际上没有多对多关系。一个Product可能有多个Sales记录，但每个Sales记录只有一个Product，所以Product和[=23=之间的关系] 是一对多的。这同样适用于模型中的其他关系。
最好描述为 "multiple fact tables with different granularity"。
根据 OP
的评论于 2019 年 11 月 6 日添加看起来 OP 对如何处理具有不同粒度的多个事实 table 感到困惑。我建议 OP 将受益于 Marco Russo 的 this article，但我尝试在这里总结本质。
基本上，OP 呈现的模型可以简化为星型模式模型，其中将放置事实 tables Sales、Budget 和 Advertising在不同星星的中心。
问题在于某些维度 table 被不同的事实 table 共享，而某些维度不共享。例如，维度 A 和 B 由 Sales 和 Budget 共享，而 C 仅与 Sales 相关。假设我们正在比较 Sales 和 Budget。当我们按 C 向下钻取报表时，Budget 中应该显示什么值？答案可能因业务而异，但在这里假设我们期望 Budget 为 空白 ，因为我们没有在每个 Budget 级别定义=22=].
这种情况普遍接受的方法是，仅在按相关维度过滤时检查度量中的过滤上下文和 return 值。例如，仅当当前上下文在 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 社区论坛中的一个问答线程，其中提到 link table 不是处理多个事实 table 的最佳实践.