为什么 Order 会忽略子选择？

Question

我在 Analysis Services 2005（和 2008 R2）中遇到了一些令人困惑的行为，如果有人能解释为什么会发生这种情况，我将不胜感激。为了解决这个问题，我重现了 Adventure Works 立方体的行为。

鉴于此 MDX：

SELECT [Customer].[Education].[(All)].ALLMEMBERS ON COLUMNS,
    Order(DrillDownLevel({[Customer].[Customer Geography].[All Customers]}), 
          ([Measures].[Internet Order Count]), 
          ASC) ON ROWS
FROM (SELECT {[Customer].[Education].&[Partial High School]} ON COLUMNS FROM [Adventure Works])
WHERE [Measures].[Internet Order Count];

查询使用行上的有序集进行计算：
所有客户：2, 136
德国：269
法国：298
加拿大：304
英国：311
美国：457
澳大利亚：497

但是，如果我在订单声明中使用的元组中包含教育的所有成员（或默认成员）：

SELECT [Customer].[Education].[(All)].ALLMEMBERS ON COLUMNS,
        Order(DrillDownLevel({[Customer].[Customer Geography].[All Customers]}), 
              ([Measures].[Internet Order Count], [Customer].[Education].[All Customers]), 
              ASC) ON ROWS
FROM (SELECT {[Customer].[Education].&[Partial High School]} ON COLUMNS FROM [Adventure Works])
WHERE [Measures].[Internet Order Count];

然后该集合以明显不同的顺序返回：
所有客户：2, 136
法国：298
德国：269
英国：311
加拿大：304
澳大利亚：497
美国：459

请注意，法国和德国相对而言是无序的。与加拿大/英国和美国/澳大利亚相同。据我所知，它是在评估子多维数据集之前基于聚合进行排序的。

为什么包含此成员（它应该隐式地位于第一个示例中的元组中？）会导致顺序语句的计算看起来超出了子多维数据集的视觉总计？ Filter 和 TopCount 等函数似乎具有相同的行为。

干杯。

Answer 1

我的猜测是，由于这两个属性仅通过键相关（不存在直接关系），因此属性的交叉连接导致关键成员被聚合，这就是不应用视觉总计的地方（这是如何计算的方法之一）与子选择的非视觉总计）。

我构建了一个查询来演示交叉连接所发生的情况：

WITH

MEMBER sortExpr as
AGGREGATE(Descendants([Customer].[Customer Geography].CurrentMember), [Measures].[Internet Order Count])

SELECT 
[Customer].[Education].[(All)].ALLMEMBERS 
*
{[Measures].[Internet Order Count], sortExpr} ON COLUMNS,
Order
(
    DrillDownLevel({[Customer].[Customer Geography].[All Customers]})
    ,sortExpr
    ,ASC
) ON ROWS
FROM 
(
    SELECT 
    {[Customer].[Education].&[Partial High School]} ON COLUMNS 
    FROM [Adventure Works]
)
;

编辑：
这是另一个查询，表明一旦您使用查询作用域集（众所周知的解决方案）解决子选择问题，表达式就可以正确地使用属性覆盖：

WITH

set sub as
[Customer].[Customer Geography].[Customer]

MEMBER sortExpr2 as
Aggregate(existing sub, [Measures].[Internet Order Count])

SELECT 
[Customer].[Education].[(All)].ALLMEMBERS 
*
{[Measures].[Internet Order Count], sortExpr2} ON COLUMNS,
Order
(
    DrillDownLevel({[Customer].[Customer Geography].[All Customers]})
    ,
    (
--      [Customer].[Customer Geography].CurrentMember,
        [Customer].[Education].[All Customers],
        sortExpr2
    )
    ,ASC
) ON ROWS
FROM 
(
    SELECT 
    {[Customer].[Education].&[Partial High School]} ON COLUMNS 
    FROM [Adventure Works]
)
;

感谢 Boyan 在 Twitter 上发布了这个问题。
问候， 赫尔沃耶

Answer 2

注意：请查看 http://www.bp- msbi.com/2011/07/mdx-subselects-some-insight/ 我在其中更详细地解释了该行为。

关于子选择的一篇很棒的文章是 Mosha 的 2008 MDX：在非可视模式下进行子选择和 CREATE SUBCUBE

请注意，当您使用子选择。隐式存在并应用视觉总计。这里关于您所经历的情况的关键信息是：

2。即使在表达式中，如果没有坐标覆盖，也会将视觉总计应用于物理度量值。

在您的第一个查询中，SSAS 默认应用视觉总计。您可以将查询更改为不这样做，如下所示：

SELECT [Customer].[Education].[(All)].ALLMEMBERS ON COLUMNS,
    Order(DrillDownLevel({[Customer].[Customer Geography].[All Customers]}), 
          ([Measures].[Internet Order Count]), 
          ASC) ON ROWS
FROM NON VISUAL (SELECT {[Customer].[Education].&[Partial High School]} ON COLUMNS FROM [Adventure Works])
WHERE [Measures].[Internet Order Count];

SELECT 语句中的 NON VISUAL 关键字告诉 SSAS 仅应用隐式 Exists，而不应用可视总计部分。查询的结果将与第二种情况相同，但您还将看到其排序所依据的实数。

由于您在第二个查询中显式覆盖 All 成员，因此 SSAS 不会将可视总计应用于此表达式，并按所有年份的总额进行排序。但是，在评估非视觉总计的顺序后，它仍然显示所选 ROWS 度量的视觉总计。

Answer 3

我不是 SSAS 专家，但这与 属性覆盖。

您将覆盖 Order 函数评估中的子选择。请注意，此行为取决于上下文（轴评估、计算成员和枢轴）。在您的示例中，上下文是轴评估期间的函数。该行为与枢轴的评估不同（一旦您知道轴）。这很复杂，但就是这样。

请注意，在 icCube 中，在与一些 MDX 专家讨论后，我们决定简化而不遵循此行为：子选择过滤器始终是应用。