从数据到信息
从信息到洞察

理解扩展表 Expanded Tables

扩展表(Expanded Tables)理论是 DAX 的核心,了解扩展表的工作原理对于理解 DAX 的至关重要,本文将系统介绍扩展表的相关知识。

在 DAX 的学习历程中,理解计值上下文、上下文传递、上下文转换筛选还原是非常重要的技能,你需要掌握这些技能才能准确理解 DAX 如何为表达式计值。但是之前的文章对计值上下文的定义做了一定程度的简化。因为在后续文章中,你会学到 DAX 计值上下文内部的全部细节。现在这个时刻终于来了:你即将开始学习计值上下文中最隐秘的知识。

在向你展示全貌之前,让我们先回顾一下迄今为止关于计值上下文的知识点:

  • 有两种上下文:行上下文和筛选上下文。
  • 行上下文不会通过关系传递。
  • 行上下文总是包含一行,它是由计算列或迭代函数引入的
  • 筛选上下文按照关系定义的方向传递。筛选上下文可以操作表,也可以操作列。当处理列时,它只筛选该列。当处理表时,它筛选表的所有列。

之前的所有描述都是正确的,到目前为止,你应该已经掌握了这些知识。然而,为了完成对计值上下文的彻底理解,你需要学习计值上下文和 DAX 的理论基石:扩展表。

注:如果你确信已经理解了扩展表理论,可以转到文末的测试题,检查一下自己的理解水平。

认识扩展表

DAX 中的每个表都有对应的扩展版本。扩展表包含原始表的所有列,以及可以通过多对一关系筛选原始表的所有表和列。让我们先用一个简单的模型来对扩展表有个直观的认识,下面的模型包含四张表,其中 Sales 表通过多对一关系可以访问所有表,所以它的扩展版本包含了整个模型。

Sales 的扩展表包含了模型中的所有表

现在让我们把模型变得稍微复杂一点,观察下图:

通过这个简单的模型你将学习扩展表的概念

同样的情况,Sales 表与 Product 表有多对一的关系,所以 Sales 表的扩展版本包含 Product 表的所有列,继续顺着关系推演,你很容易发现 Sales 表的扩展表包含了整个数据模型。另一方面,Product 表的扩展表包含自身, Product Subcategory 和 Product Category 的所有列。

日期表需要特别注意。事实上,它可以被销售表筛选是因为两者间建立了双向关系。而且这不是多对一关系,而是一对多关系。日期表的扩展表只包含日期表本身,即使日期可以被 Sales、Product、Product Subcategory 和 Product Category 表筛选。因为使筛选生效的机制是双向筛选而非扩展表。

对数据模型中的其他表重复相同的推演,你将创建这样一个扩展表对照。

每个表对应的的扩展表

扩展表是一个很有用的概念,因为它们为每个表显示了可以筛选自身原始表的列的集合。例如,如果以 Product 表为例,你可以轻松的发现如果你筛选了其扩展版本中的任何列,那么引擎也将筛选 Product 表。最重要的是,DAX 使用扩展表将所有筛选器置于筛选上下文中。为了更好地理解它,可以将模型的扩展表可视化到一个表格上,如图所示。

可视化展示让模型的扩展表更易于观察

该图表在行上列出了数据模型中的所有列,在列上展示了每个表。我们对单元格进行着色,以表示内部两种不同的列:

  • 原生列(Native columns):表的原始列
  • 相关列(Related columns):是沿着关系添加到扩展表的列。

列筛选器的一般规则

当你把一个筛选器置于一列,可以为包含该列的行涂上颜色,以直观地显示筛选了哪些表。如果你使用下面这个度量值

[RedSales] :=
CALCULATE (
    SUM ( Sales[Quantity] ),
    Product[Color] = "Red"
)

由于筛选器位于颜色列上,我们可以使用下图来突出显示包含 Product[Color]列的表

对列所在的行着色可以清楚地显示哪些表可以被筛选

颜色列的筛选器是一个列筛选器,即一个操作单列的筛选器。因此,我们现在可以声明列筛选器的一般规则:“来自列的筛选上下文可以筛选包含此列的所有扩展表”。正如你所看到的,这条规则与我们之前的表述相同,而当时我们还在谈论表和关系。实际上筛选上下文并不真正通过关系“传播”,它将筛选效果应用于包含该列的所有表,因为它基于扩展表生效。

颜色列的筛选器也会传递到日期表,尽管从技术的角度,颜色列不属于日期表的扩展表,这是双向筛选的作用,颜色列的筛选器并非通过扩展表到达日期表,DAX 引擎在内部注入特定的筛选代码以使双向筛选正常工作,而对扩展表的筛选则根据引擎的工作方式自动进行。两者的差异只存在于 DAX 内部,但指出这一点很重要。

表作为筛选器

你可以创建来自列的筛选器,也可以创建整张表作为筛选器,比如使用 FILTER 函数将整张表作为参数。那么表筛选器是如何工作的?他们也在扩展表上执行筛选。实际上,无论何时CALCULATE 中使用表作为筛选条件,筛选的都是对应的扩展表

为了理解这个概念,我们来看看这两个度量值:

[NumOfCategories] :=
COUNTROWS ( 'Product Category')

[NumOfCategoriesFilteredByProduct] :=
CALCULATE ( COUNTROWS ( 'Product Category' ), Product )

第一个度量值计算产品类别的数量。第二个计算相同的指标,但在此之前,它应用一个包含产品表的筛选上下文(当然,它会被外部上下文筛选)。结果参考下图,其中我们将产品颜色设为行标签。

透视表显示了在 CALCULATE 中应用表筛选器的效果

第一列 NumOfCategories 始终显示相同的值。原因在于行标签使用的是产品表颜色列,如果你查看之前的扩展表图解,产品类别表并不包含颜色列。因此,筛选颜色列对筛选上下文中可见的 NumOfCategories 没有影响。但是,当你将整个产品表作为筛选器参数时,你实际上使用的是产品表的扩展表。因为产品表的扩展版本包含产品子类别表的所有列,所以可见的 NumOfCategories 不再是 8 个,而是包含特定颜色的结果。

使用表作为 CALCULATE 的筛选器参数将筛选其扩展表的所有列,因此,以下两个指标存在显著不同:

[NumOfCategoriesFilteredByColor] :=
CALCULATE (
    COUNTROWS ( 'Product Category' ),
    FILTER (
        ALL ( Product[Color] ),
        Product[Color] = "Green"
    )
)

[NumOfCategoriesFilteredByProduct] :=
CALCULATE (
    COUNTROWS ( 'Product Category' ),
    FILTER (
        ALL ( Product ),
        Product[Color] = "Green"
    ) 
)

虽然这两个公式看起来几乎相同,但实际并非如此。第一个度量值只在颜色列上放置一个筛选器,因此,它的筛选效果被隔离到包含 Product[Color]列的扩展表中。因此,它对产品类别表没有影响。但是,第二个度量值在整个产品表上设置一个筛选器。因为产品表的扩展表包含了产品类别表的列,所以第二个度量值只计算包含绿色产品的类别的数量,而第一个度量值总是显示类别的总数。

透视表显示了在 CALCULATE 中应用表筛选器的效果

扩展表是帮助你理解筛选上下文传播方向的强大工具。实际上,它是 DAX 筛选上下文得以传播的真正理论基础。因为扩展表的生效方式不是很直观,理解它需要一定基础,所以我们在介绍它之前先介绍了其他概念,以帮助你熟悉该语言。一旦你掌握了扩展表的使用,就会发现理解 DAX 的工作原理并没有想象的那么难。

RELATED, RELATEDTABLE 和扩展表

扩展表包含了关系。实际上,关系就是在扩展表中运行的,一旦你开始用扩展表的方式思考,就不再需要考虑关系了。在刚开始学习 DAX 的时候,我们对 RELATED 的认知是它允许访问相关表中的列。更准确的理解是,RELATED 允许你访问扩展表的相关列。

变量和扩展表

关于扩展表有一个重要规则:扩展行为在定义表的时候发生。观察下面的查询:

DEFINE
    VAR SalesA =
        CALCULATETABLE ( Sales, USERELATIONSHIP ( Sales[Date], 'Date'[Date] ) )
    VAR SalesB =
        CALCULATETABLE ( Sales, USERELATIONSHIP ( Sales[DueDate], 'Date'[Date] ) )
EVALUATE
ADDCOLUMNS ( SalesB, "Month", RELATED ( 'Date'[Month] ) )

SalesA 和 SalesB 使用不同的关系定义 Sales 表。SalesA 使用 Sales[Date](默认关系),SalesB 使用 Sales[DueDate]的关系。ADDCOLUMNS 迭代 SalesB 并返回对应的’Date'[Month],问题是这个新增的月份列会使用哪个关系呢?Sales[Date]还是 Sales[DueDate]?如果你仍然从关系的角度思考,很容易被误导。

实际上,RELATED 访问的是 Sales 扩展表上的列。SalesB 包含 Sales 的扩展表,该扩展发生在 Sales[DueDate]作为活动关系的时候。因此,SalesB 中的 Date[Month]与 Sales[DueDate]有关,与 Sales[Date]无关。很显然,如果你改用 SalesA 进行迭代,将得到另外一种结果。

ALL 函数和扩展表

ALLEXCEPT 对表的所有列移除筛选器,除了作为参数的列之外。一个不太常见的用法是,你也可以在 ALLEXCEPT 中使用扩展表,例如,下面这个度量值可以正常计值:

[SalesOfSameColorAndCategory] :=
CALCULATE (
    SUMX (
        Sales,
        Sales[Quantity] * Sales[UnitPrice]
    ),
    ALLEXCEPT (
        Product,
        Product[Color],
        'Product Category'[Category]
    ) 
)

原因是产品表的扩展表也包含产品类别表的所有列。你还可以从扩展表中指定一个完整的表作为参数,而不是逐个指定表的所有列。例如,关于 ALLEXCEPT 的以下两个表达式是等价的:

ALLEXCEPT ( Product, 'Product Category' )
ALLEXCEPT ( Product, 
           'Product Category'[ProductCategoryKey], 'Product Category'[Category] )

第一个公式的含义是,在第二参数中指定的表被排除在 ALL 函数的效果之外。前提是这些表必须是第一参数扩展表的一部分。

CALCULATE 调节器和扩展表

ALL 作为 CALCULATE 调节器时,不返回表,只从作为参数的表的扩展版本中移除筛选器。观察以下公式:

[NumberOfSales]:= CALCULATE ( COUNTROWS ( 'Date' ), Sales  )
[NumberOfSalesWithAll]:= CALCULATE ( COUNTROWS ( 'Date' ), ALL ( Sales ) )

两种写法唯一的区别是,后者在 CALCULATE 的筛选器参数中使用了 ALL。如果 ALL 返回 Sales 表的所有行,那么这两个度量值将以相同的方式运行。然而,事实并非如此,ALL 在这里的作用是移除筛选器。在计值 COUNTROWS 之前,ALL 从当前筛选上下文中移除 Sales 表的所有列,也就是移除了来自整个模型的所有筛选器,所以 Date 表无法被任何筛选器筛选,NumberOfSalesWithAll 的结果不是有销售记录的日期数。相反,它返回日期表中的日期总数。

扩展表的性能提示

本文介绍了扩展表理论,当你真正理解它之后,可以借助它读懂并解释很多之前难以理解的公式,也可以开始试着对度量值和查询的写法做出优化。通过将理论付诸实践,你的 DAX 水平会得到进一步的提升。

另外,通过阅读本文,你不难发现一种新的筛选器用法:直接将表作为 CALCULATE 的筛选器参数,比如上文中的[NumberOfSales]公式。这种写法简单粗暴,事实证明在某些情况下也确实非常有效,但我仍然建议你谨慎使用,原因是:

本文隐藏内容查看价格为8G币,请先
注:加入VIP会员可享受全站权益,性价比更高。单独购买的内容长期有效,不受时间限制。

扩展表理解测试

在学习 DAX 的过程中,掌握扩展表理论非常重要,因为它会帮助你理解公式背后的理论细节,这对于理解正确和错误的度量值之间的细微差别至关重要。

第一题

如图所示,两张表通过 manager 建立关系,在左边新建计算列[SUM],计算每个经理的销售额,如图所示,公式得到了正确的结果。

第一题的示例数据和公式

如果你按关系的方式思考,CALCULATE 将维度表的行上下文转换为筛选上下文,这些筛选条件进入模型,沿着关系筛选了事实表,进而得出最终结果。现在的问题是,公式用 ALL 移除了组成 sales 表的四列,也就移除了施加在这些列上的筛选器,计算列的每行似乎应该得出相同的结果,但事实并非如此,你能说出原因吗?

本文隐藏内容查看价格为8G币,请先
注:加入VIP会员可享受全站权益,性价比更高。单独购买的内容长期有效,不受时间限制。

第三题

想象有这样一个两张表的简单模型,Answers 表和 Customers 表通过 CustomerKey 列建立关系,Customers 位于关系的一端,Answers 位于多端。基于扩展表原理,我们计划将 Answers 表作为筛选器计算顾客数量,同时增加一个筛选器 Answers[AnswerKey] = 6,希望只计算回答特定问题的顾客数:

CALCULATE (
      DISTINCTCOUNT ( Customers[CustomerKey] ),
      Answers,
      Answers[AnswerKey] = 6
)

问题:将这个公式放入卡片图,它将返回以下哪种结果,为什么?

  • A 空值
  • B 所有客户数
  • C 有答题记录的客户数
  • D 回答 AnswerKey 为 6 这个问题的所有客户数

本文隐藏内容查看价格为8G币,请先
注:加入VIP会员可享受全站权益,性价比更高。单独购买的内容长期有效,不受时间限制。

120
说点什么

1000
 
鼓掌微笑开心憧憬爱你色并不觉得吃瓜doge二哈喵喵思考笑哭捂脸悲伤大哭抓狂汗偷笑打脸捂眼黑线问号晕拜拜闭嘴衰咒骂ok作揖
27 评论数
95 被回复的评论
21 订阅评论的人数
 
查看最近回复
查看最热评论
  订阅本文评论  
最新 最旧 得票最多
提醒
成员
xifeng

老师,今天有人问了我一个DAX的问题,我帮他解决了,但是这让我遇到了一个关于扩展表的问题,数据、模型等详见下图,具体如下:
背景:别人问我的问题如图1所示,并且我的答案也在图1里。然后,在写公式前我忘了看数据模型了,不知道两个表自动连接了关系,所以一开始我没有考虑两个表之间的关系,结果自然是错的,后来发现了原因就把ALL加上去了,然后得到了正确结果,但是我后来想了下也没搞懂这个计值流程,所以就来问下老师。

我的问题:表1是下级表,表2是上级表,计算器聚合的是上级表(表2)的数据,内部筛选器是表2的第一列,外部筛选上下文是由表1的行上下文转换而来的筛选上下文,所以能影响到计算器的计算结果的外部筛选器中只有表1的扩展表所带来的关于表2第一列的筛选器。但是行上下文转换先执行,内部筛选器后执行,所以内部筛选器可以修改表1的行上下文转换而来的外部筛选上下文。

所以,我的问题为:为什么内部筛选器不能直接覆盖掉外部筛选器中关于表2第一列的筛选,从结果来看也不是相交行为啊,老师能帮我看看这个计值流程吗

合并图2.jpg
合并图1.jpg
游客
xifeng

我搞懂了,不用麻烦老师了……我忘了表2是有两列的,所以表1的扩展表包含了表2的两列,而我只覆盖了第一列 捂脸

成员
与你有关

老师,针对第二题,我们用value product color创建的行文上下文里用,FILTER(Sales, Sales[Quantity] > 3)。filter里的sales扩展表就会覆盖掉value创建的行文上下文里的color,计算出的是总值。但是我自己创建一个度量值(如图),同样用 FILTER(Sales, Sales[Quantity] > 3),把color列显示在表里,为什么就能计算出正确的值那? 请问两者扩展表,上下文转换,有什么差别那?

filter_question.PNG
成员
张磊

请问老师,列的扩展表是指列对应的表(不含表的扩展表)吗

成员
teamowu

请问老师,测试题第三题:既然计值后的结果求两个筛选器的交集得到最终的筛选上下文,表筛选器的范围更大,而列筛选器仅作用于一列,那最终的交集结果难道不是仅有列筛选器吗?为什么公式最终反而是由 Answers 表的扩展表执行有效筛选?

成员
风自由

老师,怎么NumOfCategories 和 NumOfCategoriesFilteredByProduct我做出来的答案都是一样的啊。

度量值是这样写的 ,请问是哪里有问题呢?

NumberOfCategoryFilterByProduct = CALCULATE(COUNTROWS(‘ProductCategory’),’Product’)

NumberOfCategory = COUNTROWS(‘ProductCategory’)

QQ图片20200811134226.png
成员
xianwensu

老师,我有一个产品表和一个销售表。产品表一端连接销售表。现在有个公式:test3 =
AVERAGEX(ALL(‘销售表’),CALCULATE(SUM(‘销售表'[销售额])))。出来结果,如图,我有两个疑问:
1)为什么忽略了产品表里的产品行标签,始终返回全部销售额的值。ALL(‘销售表’)不在CALCULATE内部,也会被认为用到扩展表理论吗?行上下文转换的销售表字段会覆盖产品表筛选器吗?
2)我的表里,销售表的产品都在产品表里,为啥还会出现一行空白值?

picture13.PNG
成员
180****3919

第一题测试题【在 CALCULATE 将维度表的行上下文转换为筛选上下文后,上下文堆栈中其实没有针对事实表的筛选条件,只有维度表的筛选条件,所以 ALL 并没有起作用】,我用了维度表的manager列也没有忽略效果,是计算列所有all(列)都失效了吗;

成员
139****3194

第四行的 Answers[AnswerKey] = 6 只对 AnswerKey 列施加筛选器,无法影响第三行的 Answers 表,因为每个筛选器在各自原始筛选上下文中计值。所以公式最终由 Answers 表的扩展表执行有效筛选,得到有答题记录的客户。
老师,cal里的两个筛选器在各自的初始外部上下文中计值,计值后的两个新筛选器不是取交集形成最终筛选上下文,然后对cal第一参数计值,对吗?那他们的交集为什么是answers 表的扩展表呢?您能纠正下我思维错误地方在哪里?

成员
139****3194

[NumOfCategoriesFilteredByProduct] :=
CALCULATE ( COUNTROWS ( ‘Product Category’ ), Product )

老师,内部筛选器产品表,外部筛选器产品表的颜色列,内部不是覆盖外部了吗?为什么文章中内部表筛选器被外部列筛选了呢?可否详细说明下,谢谢。

成员
139****3194

还有,第2题,销售数量大于3的表为什么能覆盖颜色行上下文转换的筛选器,这和我上面问题不一样吗?这题内部筛选器能覆盖转换而来筛选器,为什么内部筛选器不能覆盖外部初始筛选器呢?

游客
Lily

老师,为什么我看不了隐藏内容了?

成员
wxb2012

太难了没人讲解看了好久,我的总结是,也不知道那些理解的对那些理解的不对,请老师指正一下
1.当多端筛选一端时,当“列”作为筛选器时 ,就要注意了,列只对包含这列的扩展表起作用。所以如果不注意这一点列的筛选将失败比如
CALCULATE (
COUNTROWS ( ‘Product Category’ ),
FILTER (
ALL ( Product[Color] ),
Product[Color] = “Green”
)
(包含Product[Color]的扩展表有product和sales,Product Category表没有包含Product[Color])

2. 当多端表作为筛选器时,当不管是多选一,还是一选多时,当外面有行上下文存在时要注意的是calculate转换而来的筛选上下文,很有可能被覆盖从而失效比如
一选多,Product[Color]相对于sales为一端
ADDCOLUMNS (
VALUES ( Product[Color] ),
“Sales”, CALCULATE(
[Average Sales Amount],
FILTER ( Sales, Sales[Quantity] > 3 )
)
多选一
ADDCOLUMNS (
VALUES ( Sales[DueDate] ),
“Sales”,CALCULATE ( COUNTROWS ( ‘Product Category’ ), Sales )

这个多选一,sales多端,Product Category为一端,需要老师确定一下,筛选器表sales是不是,不会被calculate转换而来的
上下文Sales[DueDate]的所筛选,也就是说sales,覆盖了转换而来的筛选上下文,老师需要你帮我确定一下。

成员
wxb2012

3,当多选一时,表和列同时作为筛选器,要注意的是列筛选器是否起作用,因为列只作用在包含这列的扩展表上比如
CALCULATE (
DISTINCTCOUNT ( Customers[CustomerKey] ),
Answers,
Answers[AnswerKey] = 6
)

Answers[AnswerKey] 列位于Answers表,而且它们是通过 CustomerKey相连接的,所以Customers不包含Answers[AnswerKey] ,所以不起作用,如果将Answers[AnswerKey] = 6,改为CustomerKey=张三,就起作用了,这我不是很确定请老师看看是否正确。

成员
wxb2012

老师请教下
案例测试第二题
其中这段代码:
ADDCOLUMNS (
VALUES ( Product[Color] ),
“Sales”, CALCULATE(
[Average Sales Amount],
FILTER ( Sales, Sales[Quantity] > 3 )

ADDCOLUMNS 产生了行上下文,以下这段代码
CALCULATE(
[Average Sales Amount],
FILTER ( Sales, Sales[Quantity] > 3)

对values的每行计值,calculate将行上下文转换成筛选上下文被替换的原因是FILTER ( Sales, Sales[Quantity] > 3)是扩展表,它已经包含了Product[Color]这一列,所以由行上下文转换而来的筛选上下文,就不起作用了,因为filter筛选器已经包含了一切列当然包括这Product[Color]一列,老师我换一种说法不知道对不对,是这样的,不管values()里面是什么列,是values(Product[Color])这个也好,是 values(’Product Category'[ProductCategoryKey] )或者是 ‘Product Category'[Category],都将被覆盖FILTER ( Sales, Sales[Quantity] > 3),是这样的吗?
把原始的
FILTER ( Sales, Sales[Quantity] > 3)
改为
Sales[Quantity] > 3
这个呢等效于
filter(all(Sales[Quantity]),Sales[Quantity] > 3)
然而filter(all(Sales[Quantity]),Sales[Quantity] > 3),只是包含Sales[Quantity] 这一列它不包含Product[Color],所以也就是它覆盖不了Product[Color]。

成员
风自由

老师,我买了一个月的会员,暂时还没有通读,但是我还是想买书,请问当当亚马逊上可以买吗?书名我应该搜什么?谢谢!

成员
139****3194

ADDCOLUMNS (
VALUES ( Product[Color] ),
“Sales”, CALCULATE (
[Average Sales Amount],
Sales[Quantity] > 3
)
)
老师,改成列作为筛选器,这是内外筛选器形成新筛选器为筛选颜色列,且数量大于3吗,谢谢

成员
139****3194

[NumberOfSales]:= CALCULATE ( COUNTROWS ( ‘Date’ ), Sales )
[NumberOfSalesWithAll]:= CALCULATE ( COUNTROWS ( ‘Date’ ), ALL ( Sales ) )

日期是1端,sales表多端,这里是因为双向关系才发生计值流吗?如果没有双向关系,还能被sales表筛选计值日期表的行数吗?
all取消模型筛选器,即没有任何筛选,所以计值结果等于日期表本身的行数?没有all函数得筛选表,整张sales表为筛选器,按前面理论,以表为筛选器筛选的是扩展表,这里的计值的日期表是扩展表里的日期表吗?请高老师解答,感谢。

成员
139****3194

VAR SalesB =
CALCULATETABLE ( Sales, USERELATIONSHIP ( Sales[DueDate], ‘Date'[Date] ) )
EVALUATE
ADDCOLUMNS ( SalesB, “Month”, RELATED ( ‘Date))

老师,既然salesB是扩展表了,已经有date表的所有列了,为什么还要RELATED ( ‘Date)呢?

成员
139****3194

[NumOfCategoriesFilteredByProduct] :=
CALCULATE ( COUNTROWS ( ‘Product Category’ ), Product )
这个度量为什么透视表行标签对应单元格得出不同值?如果不用扩展表思维,而是用计值流的顺序:外部初始筛选上下文为行标签,即产品表的颜色列,而内部筛选器为整张产品表,内部覆盖外部筛选器,得到新筛选器还是整张产品表,它怎么回会最后计值产品类别表的行数呢?产品类别位于1端,怎么会发生计值流呢?
为什么扩展思维和计值流思维貌似结果不一?

彻底晕菜,麻烦高大师指点,谢谢

游客
139****3194

老师,为什么隐藏内容我看不了了?

成员
153****0115

您好,老师, 这段话 “虽然这两个公式看起来几乎相同,但实际并非如此。第一个度量值只在颜色列上放置一个筛选器,因此,它的筛选效果被隔离到包含 Product[Color]列的扩展表中。因此,它对产品类别表没有影响。但是,第二个度量值在整个产品表上设置一个筛选器。因为产品表的扩展表包含了产品类别表的列,所以第二个度量值只计算包含绿色产品的类别的数量,而第一个度量值总是显示类别的总数。”中的这句话 “第一个度量值只在颜色列上放置一个筛选器,因此,它的筛选效果被隔离到包含 Product[Color]列的扩展表中”的理解是不是“颜色的筛选效果被隔离在包含其列的扩展表之外”?

成员
153****0115

之前的表达不清楚,这句话的意思是不是 “因为使用了列筛选,筛选效果就被限制在那些包含该列的扩展表内部了,不包含它的扩展表就不能被它筛选”。

成员
migcq

DAX这种隐晦的计值顺序、隐晦的参数差异,某种意义上来说,这是DAX的缺陷。现在power bi是最先进的bi工具,但真心希望DAX变得更明确,更好理解。

DAX 圣经

导读

初识 DAX

DAX 基础知识

DAX 原理

DAX 高级原理

基础函数类型

迭代函数

CALCULATE 函数

CALCULATE 调节器

基础表函数

条件判断函数

查找匹配函数

时间智能函数

统计类函数

投影函数

分组/连接函数

集合函数

其他函数