2014-10-29 132 views
2

MDX腳本中條款的評估順序是什麼?處理MDX查詢的邏輯順序

WITH 
    MEMBER measures.A AS ... 
    MEMBER measures.B AS ... 
    SET S1 AS ... 
SELECT 
    { 
    measures.A 
    ,measures.B 
    ,measures.x 
    } ON COLUMNS 
    {S1} HAVING <condition> on ROWS 
FROM [Cube] 
WHERE ({S2}) 
  1. FROM
  2. WHERE
  3. WITH
  4. SELECT
  5. HAVING

但是,可能並非如此簡單,因爲MEMBERSET在上下文方面的處理方式不同 - 因此,如果此順序是正確的,上下文如何結合?

+0

希望聽到投票結束這篇文章的人的評論,因爲它似乎不是關於編程。我很難找到一個關於編程的'MDX'問題,而不是腳本處理的順序:它是所有'MDX'腳本應該被構造的方式的基礎。 – whytheq 2014-11-04 18:23:16

回答

4

我會說:

  1. FROM(包括潛在子查詢)
  2. WHERE
  3. SET和MEMBER位置在WITH子句中
  4. 建立的元組的所有查詢軸列表(列,行,...)並行,忽略NON EMPTY和HAVING
  5. 所有軸交點的單元格值
  6. 從a中移除元組xes按照NON EMPTY和HAVING對每個軸的要求。

第3步中的「成員位置」指的是成員完全存在的信息,以及層次結構,也可能位於層次結構中的哪個父級。這不涉及成員定義表達式。這將在步驟5和6中評估,但步驟4需要該位置。

軸的並行計算意味着查詢處理中軸之間沒有關係。

另請注意,這是概念視圖。在物理上,第6步可能在第4步的處理過程中發生,或者無論優化程序決定的是正確的執行順序,只要結果相同即可。

+0

+1'概念視圖'是完美的,因爲在構建這些腳本時需要牢記這一點 - 而不是處理器的角度來看,這正是我目前試圖讓我的頭腦發生的事情。 – whytheq 2014-11-04 18:25:32

+0

@FrankPI沒有在OP中提到,但你可以請添加'subselect's? – whytheq 2014-11-04 18:28:16

+0

@FrankPI'WITH'子句中的一個自定義命名集不是上下文感知的,因爲在步驟4中創建了軸元組? – whytheq 2014-11-04 18:31:25