DAX數據建模終極指南

前言

最近看見杜雨童鞋日積月累居然寫了上百篇貼子,讓人昨舌,有種著作等身的感覺.當然了杜雨童鞋目前還是財經大學碩士,學習時間比較充足,也比較刻苦,筆耕不綴.我想我也來寫點東西吧,正好斷斷續續地學power bi系列有一年半,還算比較懂,,筆者想騰出精力學點別的,因此這本書做為自己學習的終結之旅.,更重要的是DAX數據分析領域在國內比較空白,書籍非常非常少,你想百度搜索DAX某個知識點也非常難.除了劉凱老師的<微軟Excel 2013 用PowerPivot建立數據模型>這本書極具深度之外,而且我也經常瀏覽國外網站,,.這本書被譽DAX中的聖經,其權威性就無需懷疑了.想乾脆搞個好的中文吧,當作個人學習心得貼子是非常好的,而且知識在於廣泛傳播嘛..呵呵.....

這本英文電子書是由PBIHome For Power BI論壇|Power BI之家論壇某位版主堅兄提供的,在此感謝!..為了更好的翻譯,我把整個資料庫里的數據都差不多翻譯成中文,再抽進DAX數據倉庫里,於是書中每個圖例就能以中文的面貌出現,方便國內讀者閱讀,每句代碼,我都測試一下,弄懂其中的原理機制,再反推翻譯得對不對.....再加上自己的理解註解一下.理解可能會存在錯誤,自己英語也是戰鬥力只有五的渣....這隻能在日積月累的學習與思考中修正自己的錯誤了.

當然這本書不會涉及很深的商業數據分析,而是做燒腦的公式編寫,實在商業數據分析是個大而無當的話題(需要讀者的專業知識與企業的實踐經驗再加上紮實的編程技術,三者有機結合)..就拿財務數據分析來說,我看國外 這方面的技術文章也是非常零散.實在是財務有很高的保密性,我從來沒見過公開拿出整個財務數據做體系化分析的技術性文章,大多數都在抽像層面說事,拿不出成套的代碼或公式,,一般人接觸不到財務數據.真要做成體系的財務分析,那就得將資料庫里每一張會計分錄載入進數據倉庫,開始成體系的編寫代碼,但這對一般的會計人員估計同樣接觸不到,只能接觸財務數據某一部分,只有財務老大才有這權力了解公司整個底細.做為一般的會計人員其實也蠻尷尬的,因為在大中型公司,財務整個流程完全被細化成很多部門很多環節,一般的會計人員也只做某幾個科目,比如與幾家公司的或者企業內部之間的往來賬等.公司整個財務是怎麼搞的,還真搞不懂.不是人笨,實在是環境將人變成一顆螺絲釘固定在機器的某一處了,就難窺見全貌.由於筆者一直做的是底層的小微企業會計,內賬,外賬,抄稅,報稅等全方面都得包桿到底,總不好意思對老闆說,這個環節我不會,你再招個會計.再招個會計就意味著我得下崗.都是利害關係,囧...因此不會也得會,於是就有機會統籌全局,也有機會打開資料庫,將財務數據全抽進數據倉庫,琢磨財務數據分析怎麼玩的.(一邊看財管書了解一下財務指標及其數學公式怎麼推出來的,一邊寫代碼將財務指標成體系化的數據建模.沒多大鳥用,小微企業用不著CFO...,更重要的凡是老闆不讚賞的就是沒鳥用的.→_→只被老闆讚賞過做出來的其它小型數據系統). 商業數據分析另一個主流就是做銷售營運方面的,比如CRM客戶關係管理模型,又或是最近很時髦的AARRR增長黑客數據分析體系.像最近可口可樂永久撤銷首席營銷官CMO職位,用首席增長官CGO取代...嗯,DAX權威指南這本書里的很多例子基本是關於銷售方面的.

成體系的商業數據分析並不是一個新東西.其實早在2002年左右就以大型數據倉庫的面貌出現,特別是以CRM客戶關係系統的形式出現.當時出了一套系列叢書,現在來看,也有極強的學習意義.這是這套叢書中的一本.

只是後面都銷聲匿跡了,實在是沒給企業帶來實際利益.據報道有百分之八十的公司在使用時效果非常差,根本沒給企業帶來實際的銷售增長或是提高企業營運效率等.錢沒賺到,還虧了,一個大型CRM系統項目好歹得上百萬吧,最後變成可有可無的玩意,只有極少的公司才能在這些用來搞數據分析的項目上獲利.這差不多算早期的商業數據分析吧.隨著最近這兩年大數據的興起,這些玩意現在以小型商業數據分析敏捷型BI的面貌死灰復燃.........,其中的佼佼者有微軟的power BI(DAX數據建模這是power bi裡面必須認真學習的核心),還有另一家公司的產品Tableau(炫酷十足的圖表繪製以及簡單易懂,缺點就是貴,而且很難破解.不過筆者有最新版破解法,價格好商量...).當然了也可以從底層自己打造一款智能BI也行,比如利用python里的各種包,尤其是Open Mining ,面向Pandas的商業智能（BI）界面.不過這對一般人吃不消,我也吃不消...在這個人人都喊數據分析的年代,那挺有必要學習一下了,這是大勢所趨.就像最近國內取消會計從業資格考試,大力推廣管理會計,恐怕也是越來越強調財務人員的數據分析能力!.只是需要清醒的認知,數據分析無論看起來怎麼高大上,如果商業數據分析不能給公司增加銷售額,其次不能給公司削減成本,再其次不能及早洞察異常數據的出現,或者再其次一下.......露骨點說吧,本來四五個人乾的事,如果不能實現更好的自動化,將事情砍成由一兩個人去干,,都是比較失敗的(其實最後一條理由不屬於數據分析主要目標了,那屬於編程自動化的目標,而且也挺有社會殘酷性的,不仁道,以前是羊吃人,現在是機器吃人,效率的提高對於老闆來說自然而然地就要砍掉一部人........)...商業數據分析,他終究是姓商的,商是逐利的,當然了,高大上的東西對大公司或是諮詢公司非常有必要,能提高大企業的逼格,比如炫酷十足渾身散發科技感的數據駕駛管理艙..大企業逼格高能拉高粉絲效應擴大銷售額帶來實際利益.就像自帶領袖光環的喬布斯,他的PPT逼格十足,發布一次演講對企業銷售有好多層的加成.百度的某次商業發布會,PPT太LOW,結果某領導被迫辭職...

在銷售方面,數據分析通常有比較強的得附加分的能力.就像一家企業採取粗放式的經營,那隻能賺一百萬銷售,精細化的銷售營運,就有可能額外再賺30萬.其次精準的銷售管理分析,能精確的計算顧客的生命周期,提供優質的售後服務用來更好的延長顧客的生命周期,,畢竟做生意不是一鎚子買賣,每家公司都希望自己能成為百年老店,希望有更多更穩定時間更長的老顧客.

在削減成本方面,對於大中型公司,管理層的臃腫化是讓人頭痛的,這不光意味著企業決策效率低下,反映在財務數據上,就是管理費用在企業支出上佔比很大,一些費用項目找這個領導那個部門審批,也許還會發生互相扯皮,辦公室政治.如果能進行財務數據分析,那些支出費用不大的項目完全可以放權,簡化審批流程,提高企業管理運行的效率.同時用來監督警惕管理費用的增長.對於大中型公司,管理費用只佔百分之十是很完美的,這從數據層面反映公司管理層面的運行是非常高效的.當然佔比到底多少算理想,還得和同行業比較.

總之這本書不會涉及太深的數據分析層面,重點在於工具怎麼使用,該怎麼編寫燒腦的公式,而且成熟的商業數據分析對於大部分中小型企業尤其是小微企業還屬於探索階段(說真的,小微企業不需什麼太多的什麼數據分析,只需要強大的自動化能力,一個人能頂五六個人),就像互聯網早期,互聯網公司都處於燒錢模式,例如當時的企鵝帝國也準備好錢萬一破產,就發完錢,捲鋪蓋走人,都在探索找到穩定的獲利渠道.而現在互聯網公司就比前成熟很多,互聯網也是最賺錢的行業......民眾也逐漸培養起付費使用的習慣啦,就像在知乎上向大V請教一個問題或知識,還得出諮詢費.

在學習DAX表達式時,也有必要學習一下M語言,兩者相輔相成.如果想往數據分析方面發展,那把學習重心往DAX傾斜.因為DAX數據建模是用來搞企業決策的,如果是一般辦公人員,還是多學習M語言吧,提高個人辦公效率(學習VBA編程也行),畢竟一般辦公人員面臨的更多問題是數據清洗,數據轉化,報表合併,數據統計等零零碎碎的事情。最後要說的是,無論使用任何工具的數據分析師,終究還是要認真研究一款資料庫,熟悉SQL語言,資料庫里包含幾十張上百張互為關係的表,如果無法使用SQL語言編寫出自己想要的查詢表,將查詢表抽取出來,那就沒辦法談更一步的數據分析了..至於是使用power bi 還是Excel,還是SSAS玩轉DAX表格模型,全憑個人能力與喜歡.像我比較喜歡用excel,excel對數據的載入也是十分驚人的.如下圖所示,三百多萬行一張表.

廢話不多說,進入DAX權威指南的技術環節.

第一章什麼是DAX？

DAX是Microsoft SQL Server Analysis Services（SSAS）和Microsoft Power Pivot for Excel的編程語言(譯者注:這話意思是說DAX語言不光能在SQL Server里使用,還包括能在Excel,Power BI里使用.而且更重要的是微軟在下一盤很大的棋,改用微軟的Azure雲服務解決企業整個底層數據流的吃喝拉撒,雲資料庫或許更好理解,再用power bi做頂層的精細化數據分析,這是一個非常龐大的項目.目前也只有微軟能如此全面了....)。它是在2010年創建的，首次發布PowerPivot for Excel 2010（是的，在2010年，PowerPivot拼寫沒有空間;該空間在2013年的Power Pivot名稱中引入）。隨著時間的推移，DAX在Excel社區中得到普及，該社區使用DAX在Excel中創建Power Pivot數據模型，並在商業智能（BI）社區中使用DAX構建具有SSAS的模型。

DAX是一種簡單的語言。也就是說，DAX與大多數編程語言不同，可能需要一些時間才能熟悉它。根據我們的經驗，已經向數千人教過DAX，學習DAX的基礎很簡單：您可以在幾個小時內開始使用它。但是，當了解諸如評估上下文，迭代和上下文轉換等高級概念時，一切似乎都是複雜的。不要放棄！耐心一點。一旦你的大腦開始消化這些概念，你會發現DAX確實是一種簡單的語言。它需要時間來習慣。

第一章從表和關係方面對數據模型進行了簡要的介紹。我們建議讀者閱讀本節，以便在參考表，模型和不同類型的關係時，了解本書中使用的術語。

在接下來的章節中，我們向具有其他編程語言（即Excel，SQL和MDX）經驗的讀者提供建議。每個部分適用於已經知道該語言的讀者，並且可能會發現閱讀一個非常快速的DAX簡介，我們將其與這些各種語言進行比較。如果您是Excel用戶，並且發現MDX部分幾乎不可能理解，那就是完全預期的。只要跳過這個部分，因為它包含對您本質上沒有意義的信息，並轉到下一章，我們進入DAX語言的旅程真的開始了。

了解數據模型

DAX是專門用於通過數據模型計算業務公式的語言。您可能已經知道數據模型是什麼，但如果您不熟悉它，那麼值得花上幾頁來描述數據模型和關係，從而為您構建DAX知識的基礎。

數據模型是一組由關係鏈接的表。

我們都知道一個表是什麼：一組包含數據的行，每行分成幾列。每列具有數據類型並包含單個信息。我們通常將表中的一行引用為記錄。表格是組織數據的便捷方式。一個表本身就已經是一個數據模型，儘管是最簡單的形式。因此，當您在Excel工作簿中編寫名稱和數字時，您將創建一個數據模型。

如果您的數據模型包含許多表，那麼它們很可能通過關係鏈接。兩個表之間有一個關係。當兩張表被關係時，我們說它們是相關的。在圖形上，關係由連接兩個表的線表示。如圖顯示了一個數據模型的例子。

圖1n

這是一個由六個表組成的數據模型的簡單示例。關係的一些重要方面要學好：(筆者注:表與表之間的線條端的星號*代表處於關係的多端,1代表處於關係的一端.這些表與表之間的關係很容易讓人想起資料庫.)

1.關係中的兩個表有具有不同的作用。它們被稱為關係的一端和多端。在圖中，重點介紹下產品表和產品子類別之間的關係。單個子類別包含許多產品，而單個產品只有一個子類別。因此，產品子類別是關係的一端（具有一個子類別），而產品表是多端（有許多產品）。

2.用於創建關係的列（通常在兩個表中具有相同的名稱）稱為關係的關鍵字。在關係的一端，列需要為每行具有唯一且不能重複的值。在關係的多端，相同的值可以（並且經常是）在許多不同的行重複。當列具有每行的唯一值時，它將被稱為表的鍵。通常，表只有一列鍵。

3.關係可以形成鏈。每個產品都有一個子類別，每個子類別都有一個類別。因此，每個產品都有一個類別。為了檢索產品的類別，您需要遍歷兩個表之間關係鏈。圖中包括一個由三個關係組成的關係鏈的示例，從銷售表開始，並繼續到產品分類表。

4.在每個關係中，可以有一個或兩個小箭頭。在圖中，您可以在銷售表和產品表之間的關係中看到兩個箭頭，而所有其他關係都有一個箭頭。(譯者注,在圖中其實只有一個小箭頭,要形成雙箭頭,必須使用power bi,而且表與表之間關係最好是一對一的關係.而譯者使用的是power pivot...power pivot目前的版本無法實現雙箭頭.) 箭頭表示自動過濾關係的方向。我們將在後面的章節中更詳細地討論這一點，因為確定過濾器的正確方向是學習最重要的技能之一。

筆者注:在power BI當中要實現雙箭頭,是通過如下設置.

在DAX表格數據模型中，只能在單列上創建關係。引擎不支持多列關係。(譯者注:使用MDX表達式的多維模型支持創建表與表之間的多列關係。MDX形式上很類似SQL語言,而DAX形上類似工作表函數。)

理解關係

正如我們上一節所述，每個關係可以有一個或兩個方向進行過濾。過濾總是從關係的一端到多方傳遞。如果關係是雙向的（也就是它有兩個箭頭），則過濾也可以從多端到一端傳遞。

一個例子可能會幫助您更好地了解這一行為。如果創建基於圖1的數據模型的數據表，其中包含行數上的年份以及值區域中銷售金額和產品ID的計數(相當於產品的銷量) ，您將看到下圖所示的結果。

行標籤包含年份，即日期表中的一列。日期是處於銷售表關係的一端。因此，當您將銷售表中的銷售金額放在數據透視表中時，引擎會根據年份正確地過濾出每年的銷售額。銷售表和產品表之間的關係是多對一; 當您將產品表中的產品ID放入數據透視表進行計數時，結果發生錯誤。過濾總是從一端向多端傳遞,但是日期表與銷售表處於一對多的關係,而銷售表與產品表處於多對一的關係,方向不統一,導致日期表中的年份無法正確地過濾產品表的產品ID,而第一產品ID是銷售表裡的列,所以能正確的過濾..(產品表中的列只能編寫公式做人工傳遞了,),

DAX的Excel 用戶

假如你已經知道Excel公式語言，而DAX和其有類似的地方。畢竟，DAX的根源在Excel的Power Pivot中，開發團隊試圖保持兩種語言相似。這使得過渡到這種新語言更容易。但是，有一些非常重要的區別。

單元格與表

在Excel中，您可以對單元格執行計算。使用其坐標引用單元格。因此，您編寫公式如

=（A1 * 1.25） - B2n

DAX是不同的。在DAX中，單元格的概念及其坐標不存在。DAX適用於表和列，而不是單元格。所以每當你寫DAX表達式時，它們只會引用表和列。表格和列的概念在Excel中並不新鮮。實際上，如果您將Excel範圍定義為表.(筆者注:快捷鍵是CTRL+L),則可以在Excel中編寫引用表和列的表達式。

如圖,你會看到銷售金額列將評估引用同一表中的列的表達式，而不是工作簿中的單元格.

使用Excel，您可以使用[@ColumnName]格式引用表中的列，其中ColumnName是要使用的列的名稱，

@符號表示「取當前行的值」。雖然語法是不是很直觀，通常你不要寫這些表達式。它們只需單擊一個單元格即可出現，Excel會為您插入正確的代碼。

您可能會認為Excel有兩種不同的執行計算方法：您可以使用標準單元格引用（在這種情況下，單元格的公式寫成C2 * D2），或者可以使用列引用，如果你在表中 使用列引用的優點就是可以在列的所有單元格中使用相同的表達式。

DAX在計算列時同樣如此。例如，在DAX中，以這種方式寫入類似的乘法：

"銷售表"[銷售金額] ="銷售表"[產品價格] *"銷售表"[銷售數量]n

您可以看到在DAX公式中，都加上表名稱為前綴("銷售表")。在Excel中，您無需提供表名，因為Excel公式在單個表中工作。另一方面，在DAX中，引用需要指定表名稱，因為DAX數據模型中會有許多不同的表.

DAX中的許多功能與等效的Excel功能相同。例如， IF 函數在DAX和Excel中以相同的方式讀取：

Excel中 IF（[@銷售金額]> 10，1，0）nDAX中 IF（"銷售表" [銷售金額]> 10，1，0）n

Excel和DAX的語法不同的一個重要方面是引用整個列的方式。您可能已經注意到，當編寫[@銷售數量]時，@表示「當前行中的值」。使用DAX時，不需要指定。語言的默認行為是獲取當前行的值。如果在Excel中要引用整個列（即該列中的所有行），可以通過刪除@符號來實現。

銷售總額列的值在所有行中相同，因為它是銷售金額列的總計。換句話說，當前行中的列的值與整個列的值之間存在語法上的差異。

DAX是不同的。在DAX中，您可以這樣寫出如上圖的銷售部額的表達式：

[銷售總額]:= SUM（"銷售表" [銷售金額]）n

筆者注: [銷售總額]：與[銷售總額]表達不同的意思.加一個冒號"："表示進行寫度量公式.而不加冒號,表示是寫計算列公式.

使用列獲取特定行的值並使將列作為一個整體使用，並沒有任何語法上的區別。DAX知道您希望聚合列上的所有值，因為您在聚合函數（在這種情況下為SUM函數）中使用列名稱，這需要將列名稱作為參數傳遞。因此，在Excel需要明確的語法來區分要檢索的兩種類型的數據，但在DAX中以自動的方式進行消除。至少在一開始，這可能會令人困惑。

Excel和DAX：兩種函數式語言

兩種語言非常相似的一個方面就是Excel和DAX都是函數語言。函數語言由基本上是函數調用的方式組成。在Excel和DAX中都不存在循環和跳轉的概念，這對許多編程語言是常見的。在DAX中，一切都是表達式。對於來自不同語言的程序員來說，或許是一個挑戰，但對於Excel用戶來說，這一點並不奇怪。

使用迭代器

一個可能對傳統Excel用戶來說是一個新概念的就是迭代器。在Excel中工作時，您可以一步一步執行計算。在上一個示例中，您已經看到，為了計算銷售總額，您已經創建了一列包含價格乘以數量的列，然後作為第二步，將其總計來計算總銷售額。然後，這個數字將是有用的，例如，作為計算每個產品的銷售百分比的分母。(筆者注:感覺說得很繞口,最簡單的,傳統Excel用戶在寫函數公式時,一個習慣性動作就是寫完公式,然後下拉.而在DAX中是不需要的,它會根據行上下文進行自動迭代.)

使用DAX，您可以通過使用迭代器在單個步驟中執行相同的操作。迭代器完全符合它的名稱：它遍歷一個表，並對錶的每一行執行計算，聚合結果以產生所需的單個值。

在上一個例子中，您可以使用該計算器計算所有銷售額的總和

[銷售總額]：= SUMX（"銷售表"，"銷售表"[銷售數量] *"銷售表"[銷售價格]）n

這種方法既有優點也有缺點。優點在於，您可以單步執行許多複雜的計算，而無需擔心添加許多列，最終僅對某些特定公式有用。另一方面，缺點就是使用DAX進行編程不如Excel中那般可視化。你看不到列計算價格乘以數量; 它只存在於計算的生命周期中。

說實話，你還可以選擇創建一個計算出的價格和數量乘積的計算列。然而，這通常不是個好方法，因為它使用了寶貴的內存，並可能減慢計算速度。

DAX需要一些理論

我們必須清楚：這不是編程語言之間的差異；這是心態的差異。像這個星球上的任何人一樣，你可能習慣於在網上搜索複雜的公式和解決方案。當使用excel時，很可能你會找到一個幾乎可以滿足你需要的公式。您可以複製公式，自定義它以滿足您的需要，然後使用它，而不必過於擔心它是如何工作的。

例如，在我每天使用的工作表中，有這樣一個公式：

{=SUM(IF((交易額表!$B$5:$B$991>=M30)* (交易額表!$B$5:$B$991<=N30),1,0))}n

我不完全理解花括弧中的公式是如何工作的，以及如何計算if語句。說實話，我只記得我需要用一個三鍵結束的方式來確認他們。也就是說，它是有效的，它總是工作的，它計算的數字是有意義的，但是不能直觀的顯示在內部是如何計算該值。因此，作為圖書的作者和DAX專家，我也屬於這一類的用戶。(筆者注:感覺很繞口,總之一句話,數組對於DAX是不適用的.DAX在形式上像工作表函數,但DAX用戶思維模式卻必須得變得像在玩SQL資料庫一樣,不然就很理解DAX的運作機制.)

幸運的是，DAX的理論僅限於幾個重要的概念，這在第4章「 理解上下文 」中有所描述。當你到達那一章時，捲起你的袖子，準備回學校一段時間。一旦掌握了內容，DAX就不會有任何秘密，而且學習主要是經驗積累。

記住：知道只是戰鬥的一半。

DAX, SQL 開發人員

如果您習慣於SQL語言，那麼您已經處理了許許多多的表，並創建了列之間的連接，以便設置關係。從這個角度來看，您將在DAX使用的過程中感覺像回到了家一般，因為DAX中的計算是查詢一組由關係和聚合值連接的表。

SQL和DAX的首要區別在關係模型中的工作方式。在SQL中，您可以在表之間設置外鍵來聲明關係，但引擎在查詢時卻不使用這些外鍵，除非您明確申明。例如，你有一個客戶表和銷售表，其中客戶ID是客戶表中的主鍵和在銷售中是外鍵，你可以寫一個查詢：

SELECTn客戶表.客戶名字,nSUM ( 銷售表.銷售金額 ) AS 銷售總額 FROMn銷售表nINNER JOIN 客戶表nON 銷售表.客戶ID= 客戶表.客戶ID GROUP BYn客戶表.客戶名字n

即使您使用外鍵在模型中聲明關係，仍然需要明確地聲明查詢中的連接條件。(筆者注:SQL查詢一般要警惕不寫約束條件的句子.沒有約束一不留神就成死機..)它使查詢更詳細，它可以讓您在不同的查詢中使用不同的連接條件，為查詢提供更多的自由。

在DAX中，關係是模型的一部分，它們都是LEFT OUTER JOIN(左連接,筆者注:感覺說是右連接也行...)。一旦在模型中設置好關係鍵，您不再需要在查詢中指定連接類型：DAX 在使用與主表相關的列時，在查詢中會自動使用LEFT OUTER JOIN(左連接)。因此，您將在DAX中將以前的SQL查詢寫為：

EVALUATE nSUMMARIZE (n"銷售表", "客戶表"[客戶名字],n"銷售總額", SUM ( "銷售表"[銷售金額] )n)n

因為DAX知道銷售表和客戶表之間的現有關係，所以它會自動隨著模型進行篩選。最後，SUMMARIZE函數需要由"客戶表" [客戶名字]執行分組，整個公式沒使用任何關鍵字。

DAX是一種函數式的語言

SQL是一種聲明性語言。您可以通過使用SELECT語句聲明從數據集中檢索出所需內容，而不必擔心引擎該如何檢索信息。另一方面，DAX是一種函數式的語言。

在DAX中，每個表達式都是一個函數調用，而函數參數又可以被其他函數調用。參數的評估可能導致DAX執行非常複雜的查詢用來計算結果。

例如，如果要僅檢索居住在歐洲的客戶，則可以在SQL中寫入：

SELECTn客戶表.客戶名字,nSUM ( 銷售表.銷售金額 ) AS 銷售總額 FROMn銷售表nINNER JOIN 客戶表nON 銷售表.客戶ID = 客戶表.客戶ID WHEREn客戶表.大洲= 歐洲 GROUP BYn客戶表.客戶名字n

在DAX中，您不會在查詢中聲明WHERE約束條件。而是使用特定函數（FILTER）過濾結果：

EVALUATEnSUMMARIZE ( FILTER (n"客戶表",n"客戶表"[大洲] = "歐洲"),n"客戶表"[客戶名字],n"銷售總額", SUM ( "銷售表"[銷售金額] )n)n

您可以看到FILTER做為一個篩選函數：它只返回生活在歐洲的客戶，產生預期的結果。嵌套函數的順序和使用的函數類型對最終結果和引擎的性能有很大的影響。這也發生在SQL中，即使在SQL中您信任查詢優化器來查找最佳查詢計劃。在DAX中，雖然查詢優化器做得很好，但程序員在編寫好代碼方面負有更多的責任。

DAX作為一種編程和查詢語言

在SQL中，用來作查詢的語言與用作編程的語言有著明顯的區別；也就是說，用於在資料庫中用於創建存儲過程、視圖和其他代碼的是另一組指令(筆者注:在這些方面通常就類似於編程語言,同樣有著循環語句等.)。每個SQL方言都有自己的語句，讓程序員用代碼充實數據模型。

另一方面，DAX幾乎不區分查詢和編程。一組豐富的函數可以操作表格，而又可以返回表格。您在上一個查詢中剛剛看到的FILTER功能就是一個很好的例子。

因此，就此而言，DAX比SQL簡單。一旦你將它作為一種編程語言（通常是它的第一個用法）學習，你將會了解所有需要使用它作為查詢語言的一切。

SQL子查詢與DAX條件句

SELECTn客戶名字, 銷售總額 FROM (nSELECTn客戶表.客戶名字,SUM ( 銷售表.銷售金額 ) AS 銷售總額 FROMn銷售表nINNER JOIN 客戶表nON 銷售表.客戶ID = 客戶表.客戶ID GROUP BYn客戶表.客戶名字n) AS 子查詢 WHEREn子查詢.銷售總額 > 100n

您可以通過簡單地嵌套函數調用在DAX中獲得相同的結果：

EVALUATE nFILTER ( SUMMARIZE (n"客戶表", "客戶表"[客戶名字],n"銷售總額", SUM ( "銷售表"[銷售金額] )n),n[銷售總額] > 100n)n

在此代碼中，檢索客戶名字和銷售總額的子查詢稍後將被饋送到一個FILTER函數中，該函數僅保留銷售總額大於100的行。現在此代碼對於讀者來說似乎無法看懂，但是，一旦您開始學習DAX，您將發現DAX使用起來比SQL子查詢要容易得多，它自然流動，因為DAX是一種函數式的語言。

下面是介紹MDX與DAX之間的區別,由於筆者看不懂MDX.而且這方面是資料非常非常的稀少,所以自動略過....

EasyCharts團隊出品

帥的人都關注了EasyCharts團隊^..^~

QQ交流群：553270834

微信公眾號：EasyCharts

推薦閱讀：