解釋 LuckyTemplates 中的行上下文

我發現大多數人對理解 DAX 在行上下文中的工作方式感到困惑。這是因為行上下文可能非常複雜且不必要。因此，我們將在整篇文章中討論行上下文。您可以在本博客底部觀看本教程的完整視頻。

我考慮行上下文的方式是通過迭代或迭代函數。一旦我在腦海中做出這種區分，就計算引擎中實際發生的事情而言，它就更有意義了。

回顧一下，我們已經討論了三種類型的上下文：求值上下文、過濾上下文和行上下文。

任何 DAX 計算都分兩步進行。評估上下文總是先進行，然後根據您編寫的函數分支到過濾器上下文或行上下文。

目錄

• 了解行上下文
  • 行上下文 VS 篩選上下文
  • 使用行上下文計算已售數量迭代
  • 為什麼使用行上下文或迭代函數？
• 理解 LuckyTemplates 上下文的關鍵注意事項
• 結論

了解行上下文

行上下文就是迭代。

我將向您展示幾個示例，希望這有助於您理解行上下文在後端的實際作用。

行上下文 VS 篩選上下文

在我們的示例中，公式是通過過濾器上下文計算的，因為它是一個簡單的聚合。在所有初始過濾器就位後，它會匯總整個數量列。

Sales 表的初始篩選器是產品 1。通過對已售出的每個數量求和，我們得到 165。

現在我將向您展示如何獲得完全相同的結果，但計算方式卻截然不同。首先，我將使用迭代公式為 Quantity Sold Iteration 創建一個新度量。

迭代函數的示例包括SUMX、AVERAGEX、MANYX和COUNTX。在這種情況下，我們將使用SUMX。

SUMX函數要求我放入一個表，所以我要放入 Sales 表。然後它要求我輸入一個表達式，所以我只輸入了數量列。

這個函數和第一個函數有很大的不同，但是當我把它拖進來的時候，我得到的結果是完全一樣的。

我們在這裡得到完全相同的結果，因為它最終是相同的計算。它只是以不同的方式計算的。

Quantity Sold Iteration 是使用row context計算的，而 Total Quantity Sold 是使用filter context計算的。

使用行上下文計算已售數量迭代

現在讓我們逐步了解如何計算迭代銷售數量。首先，您必須記住離開初始估值上下文，在本例中為 Product 1。然後通過行上下文，我們遍歷我們指定的表中的每一行。

在本例中，我們指定了 Sales 表，然後查看 Quantity 列中的每一行。

在初始評估期間，產品 1 將由產品 ID 列中篩選的任何內容確定。然後它計算數量列下的行數。每次它命中一行時，它都會進入並將結果保存到內存中。

到達表格底部後，它會評估保存在內存中的所有結果，然後執行您要求的任何計算，在本例中為SUMX。

為什麼使用行上下文或迭代函數？

這是因為在迭代函數中你可以做更複雜的事情。你可以在裡面寫一些很高級的邏輯。

例如，對於 Sales 表中的每一行，數量都乘以 2。您現在會看到發生了相同的計算過程，但我們得到了不同的結果。

這是因為對於每一行，我們都在編寫一些不同的邏輯。遍歷數量列中的每一行後，我們將該值乘以二，然後將其保存到內存中。最後，我們做一個SUM。

我們還可以在這裡編寫不同的東西，包括高級邏輯，例如IF或SWITCH邏輯。

有大量的例子表明使用迭代函數或行上下文進行計算比使用聚合函數或篩選上下文更好。

理解 LuckyTemplates 上下文的關鍵注意事項

要回顧有關上下文的所有關鍵事項，請記住在 DAX 中進行計算是通過兩步過程進行的。第一步始終是求值上下文。評估上下文是什麼非常重要。

一旦您了解了任何單個結果的評估上下文，DAX 就會分為兩種不同的方式。它可以通過過濾器上下文或行上下文進行計算。

選擇使用哪個上下文取決於您編寫的公式。因此，如果您編寫一個簡單的聚合公式，它就會通過篩選器上下文進行計算。但是如果你寫一個像 SUMX 這樣的迭代函數，那麼它會通過行上下文計算公式。

一旦您在 DAX 中稍微高級一點，您實際上可以在同一個函數中擁有多個上下文。但在你到達那里之前，你真的必須了解什麼是最簡單形式的上下文。

結論

當您學習 DAX 並希望從事更高級的工作時，了解上下文類型絕對至關重要。當你開始編寫真正高級的 DAX 公式時，你有多個上下文同時工作，你需要了解該公式的每個單獨部分正在做什麼以實現你想要的結果。

以下是一些推薦的鏈接，供您詳細了解行上下文在 LuckyTemplates 中的應用：

Evaluation Context – (1.8) DAX 終極初學者指南

Filter Context – (1.9) DAX 終極初學者指南

享受通過這個工作。