DAX 列上下文 (Row Context) 完全指南：解鎖迭代的秘密
覺得 DAX 中的 SUMX 和計算資料行難以理解？關鍵就在「列上下文 (Row Context)」。本指南將用放大鏡的比喻，帶你徹底搞懂 DAX 引擎如何進行逐行運算，並深入解析 DAX 中最神奇、也最強大的技巧：「上下文轉換」。掌握它，你就能真正駕馭 CALCULATE 與迭代函數的威力。
你好，我是 Kiro。
在《DAX 函數終極指南》中，我們深入探討了 DAX 的兩大核心環境。如果說「篩選上下文」是決定要計算哪些資料列的「超級篩選框」，那麼它的雙胞胎兄弟——「列上下文」，就是一把在特定一列上進行精細操作的「放大鏡」。
如果你曾經疑惑：
- 為什麼
SUM('銷售表'[數量] * '銷售表'[單價])會報錯，但SUMX就可以？ - 為什麼在計算資料行裡用
SUM，結果每一列的數字都一樣？
那麼，你遇到的正是「列上下文」的魔力與陷阱。
這篇文章，就是你的列上下文終極說明書。我們將用最直觀的比喻，帶你徹底搞懂這個概念，並學會 DAX 中最重要的高級技巧：「上下文轉換」。
第一部分：到底什麼是列上下文？—— 放大鏡的比喻
忘掉所有生硬的定義，記住這個畫面：
列上下文 (Row Context) 就像一把放大鏡，它強迫 DAX 引擎一次只專注於你資料表中的「單一一列」。
當這把放大鏡停在某一列上時：
- 它的視野很「寬」： 它可以清楚地看到這一列中所有欄位的值（例如，這一列的
[數量]是 5，[單價]是 100）。 - 同時它的視野也很「窄」： 它完全看不到其他任何一列的資料。它不知道上一列的數量是多少，也不知道下一列的單價是多少。
列上下文的核心任務只有一個：迭代 (Iteration)，也就是逐行處理。
列上下文 vs. 篩選上下文：一場「放大鏡」與「篩網」的對決
這是 DAX 新手最容易混淆的地方。讓我們用一張表來徹底釐清它們的區別：
核心概念對決
| 比較維度 | 列上下文 (Row Context) | 篩選上下文 (Filter Context) |
|---|---|---|
| 核心比喻 | 放大鏡 🔍 | 篩網 / 篩選框 🥅 |
| 核心動作 | 迭代 (Iterating) - 逐行掃描 | 篩選 (Filtering) - 圈選符合條件的資料列 |
| 作用範圍 | 單一一列 (A Single Row) | 多個資料列 (A Table of Rows) |
| 主要出現地 | 計算資料行、迭代函數 (`...X`) | 量值 (Measures) |
簡單來說，篩選上下文決定了你要處理的數據範圍（例如，只看北區的銷售數據），而列上下文則是在這個範圍內（或整個表）進行逐行運算。
第二部分：列上下文在哪裡出沒？
列上下文並不像篩選上下文那樣無處不在。它只會在你明確要求「逐行處理」時才會被啟動。主要有兩個場景：
場景一：計算資料行 (Calculated Columns)
這是最自然、最常見的列上下文。當你在資料表中新增一個計算資料行時，DAX 會自動為每一列都執行一次你的公式。
LineTotal (新計算資料行) = 'Fact_Sales'[Quantity] * 'Fact_Sales'[UnitPrice]
| OrderID | Quantity | UnitPrice | LineTotal (新計算資料行) |
|---|---|---|---|
| ORD-001 | 3 | 50 | 150 ⬅️ (🔍 當前列上下文: 3 * 50) |
| ORD-002 | 2 | 30 | 60 |
| ORD-003 | 5 | 100 | 500 |
DAX 引擎逐行掃描，在每一列的「列上下文」中執行乘法。
場景二：迭代函數 (Iterator Functions)
這是 DAX 更強大、也更核心的應用。所有以 "X" 結尾的函數（SUMX, AVERAGEX, MAXX, FILTER 等）都被稱為迭代函數。
它們被設計出來的目的，就是在量值 (Measure) 的計算過程中，手動創建一個臨時的列上下文。
示意圖：SUMX 的運作流程
SUMX 在記憶體中創建臨時的列上下文，逐行計算後再加總。
| Qty | Price |
|---|---|
| 3 | 50 |
| 2 | 30 |
| 5 | 100 |
總銷售額 =
SUMX(
'銷售表',
'銷售表'[Qty] * '銷售表'[Price]
)| (臨時計算結果) |
|---|
| 150 |
| 60 |
| 500 |
➡️ 深度學習： 想更深入了解SUM與SUMX的差異與應用場景嗎？請閱讀我們的專文：《SUM vs. SUMX：一篇搞懂 Power BI 的迭代函數》
第三部分：最重要的概念：上下文轉換 (Context Transition)
現在，準備好迎接 DAX 中最神奇、也最強大的概念：「上下文轉換」。它回答了一個終極問題：
如果我正處於「列上下文」（例如，在一個計算資料行中），但我需要進行一次「篩選上下文」的操作（例如，計算一個聚合值），該怎麼辦？
CALCULATE 函數在這裡的唯一任務，就是執行「上下文轉換」。它能將當前「列上下文」中的值，轉換成一個等效的「篩選上下文」。
示意圖：資料模型關係
DAX 透過「一對多」關係，將篩選從維度表傳播到事實表。
| ProductID (PK) | ProductName |
|---|---|
| P-001 | iPhone 15 |
| P-002 | Galaxy S24 |
| OrderID | ProductID (FK) | SalesAmount |
|---|---|---|
| ORD-101 | P-001 | 30000 |
| ORD-102 | P-002 | 15000 |
| ORD-105 | P-001 | 30000 |
Step 1: DAX 處於 Dim_Product 表的某一列 (列上下文 🔍)
Product Sales (New Column) =
CALCULATE(
SUM('Fact_Sales'[SalesAmount])
)
| ProductID | ProductName | ... | Product Sales (New Column) |
|---|---|---|---|
| P-001 | iPhone 15 | ... | 正在計算... |
Step 2: CALCULATE 提取該列的值，並將其「轉換」為篩選器
列上下文的值 (`ProductID = 'P-001'`)
⬇️ CALCULATE 轉換 ⬇️
新的篩選上下文 (`FILTER('Dim_Product', [ProductID] = "P-001")`) 🥅
CALCULATE 將單一一列的「列上下文」，轉化為篩選整個模型的「篩選上下文」。
Step 3: 新的篩選上下文作用於 Fact_Sales 表
| OrderID | ProductID | SalesAmount |
|---|---|---|
| ORD-101 | P-001 | 30000 |
| ORD-105 | P-001 | 30000 |
Step 4: SUM 在被篩選後的表上進行計算，返回最終結果
| ProductID | ProductName | ... | Product Sales (New Column) |
|---|---|---|---|
| P-001 | iPhone 15 | ... | 60000 |
這就是上下文轉換的威力。CALCULATE 就像一座橋樑，讓你能從逐行掃描的「列上下文」，跳轉到聚合篩選的「篩選上下文」，從而實現極其複雜和強大的計算。
結論：掌握兩種上下文，駕馭 DAX 全局
DAX 的世界，就是由「篩選上下文」和「列上下文」這兩大核心規則所統治的。
- 篩選上下文告訴你計算的範圍。
- 列上下文讓你在這個範圍內（或整個表）進行逐行處理。
- 而
CALCULATE則是讓你能夠在這兩種強大環境之間自由轉換的唯一鑰匙。
理解它們的區別，並學會駕馭它們之間的轉換，你就真正掌握了像 DAX 引擎一樣思考的能力。這不僅是技巧的提升，更是思維的升維。
🚀 從心法到實戰，只差一步
恭喜你，你已經掌握了 DAX 的完整思維藍圖！如果你渴望將這些心法，轉化為可以放進作品集的亮眼專案，我誠摯地邀請你加入我在 Hahow 好學校的線上課程。
【Power BI x AI 終極實戰：打造高效數據分析工作流】
✨ 超過 5 小時的 DAX 專門單元，帶你逐行拆解 DAX 在真實商業專案中的應用。
🎯 親手實作三大商業儀表板，將理論化為你的實戰超能力。
💬 專屬學員社團，由我親自為你解答學習路上的所有疑惑。
這不只是一堂工具課，更是一趟將你打造成真正數據專家的旅程。
👉 點擊這裡，立即加入超過千名學員的行列，將 DAX 從夢魘變為超能力！
🎁 想持續升級你的數據決策系統嗎？
覺得這篇文章對你有幫助嗎？這只是個開始。
免費加入，立即解鎖『會員資源中心』(內含完整電子書、練習檔案與更多專屬內容)！
你將不僅能立即下載排版精美的 【數據分析師的養成心法 (2025 終極指南)】 完整版電子書 (PDF) ，更重要的是，你將開始每週收到我的獨家框架、實踐案例與工具推薦。
讓我們一起，將數據轉化為智慧，打造屬於自己的理想人生。
