SQLBI_精通DAX課程筆記_02_資料型別
PowerBi 和 Analysis Services 在資料載入環節，無論資料來源是什麼型別，都會自動將資料轉化為DAX可用的資料型別集。
以下連結為微軟官方文件，也可以參考瀏覽：
https://learn.microsoft.com/zh-cn/power-bi/connect-data/desktop-data-types
一：資料型別
1.1 數字型別
數字型別包含了，Integer(64 bit) 即整數型，，Decimal 十進位制 (floating point) 即浮點型，日期時間型、貨幣型（以整數形式儲存，整數的最後四位用作小數位數）、布林型等等
1.2：其他型別
String (字串型)，“文字”資料型別是 Unicode 字元資料字串，可以是字母、數字或以文字格式表示的日期。 根據 Power BI 的 Power Query 基礎引擎及其對“文字”資料型別長度的限制，字串長度的實際最大限制約為 32,000 個 Unicode 字元。 “文字”資料型別超出實際最大限制可能會導致錯誤。（偶爾在pq中會遇到超出資源等報錯提示，就有可能是這個原因）
Binary Objects (二進位制型別)等等
這裡附一個對照表：
二：資料型別和格式有區別
資料型別和格式完全不是一回事。
格式(圖中1號標記)：控制一個數字的顯示方式，而不以任何方式影響基礎精度。
資料型別（圖中2號標記）：控制資料的型別，將更改數值的精度，使之與所宣告的資料型別一致。注意，更改資料型別會永久改變資訊在表中的儲存方式，可能會導致資料丟失。
影片案例中，以"8.99"元的單價列做了例子
2.1 修改列格式
當單價列，只修改格式，由貨幣調整為整數型時，顯示的值變為了"9"
當我們手工調回2位顯示時，仍舊顯示為"8.99"，這意味著，我們只剛剛修改的格式，並沒有從根本上修改我們數字的儲存方式，也就是所謂的保持了精度。
2.2 修改列資料型別
當單價列，我們修改資料型別為整數型時，首先我們收到了警告，如下圖
點選確定後，顯示的值同樣變為了"9"，但是我們試圖手工調整資料格式為小數型時，我們發現值已經永久的被修改為了"9"，除非我們重新載入原來的舊的的資料集，否則這個值就是被永久改變了。經過這個實驗案例，我們明白了，上面的核心觀點，修改資料型別，會直接永久性的更改資料精度。
三：運算子過載
運算子可以應用於不同的運算元（operand），DAX引擎會自動轉化運算子的引數，已滿足運算子的需要，最終結果的資料型別有運算子去定義。
如下圖所示，我們建立兩個度量值，將他們放入矩陣視覺物件，分別測試1和2的結果值，他們的區別在於分別有"+"和"&"去連結，我們可以看到結果，當用"+"好去連線時，返回了7（數字型別），即運算子過載返回了加法結果，而"&"號連結時，返回的結果是34（文字型別），所以返回的結果數的型別是由運算子去定義的。
正因為有運算子過載功能，所以我們最好是在書寫程式碼時，或者是設定預設值時，就應該明確規定資料型別，以免因為資料過載導致的計算結果不一致的問題。（控制權得在我們們自己手裡，不許引擎自己瞎算）
四：日期時間型別
日期時間型以浮點數儲存，分為整數部分和小數部分。
4.1 整數部分
整數部分表示，1899年12月30日之後的天數，即在DAX中，整數"1"就代表了1899年12月30日當日。所以日期直接減去一個整數1，就代表日期減1，前一天。
4.2 小數部分
小數部分表示的是天的分數，在DAX中用1除以24來表示一個小時的（我算了一下，相當於1小時就是0.416......），0.25（0.416*6 約等於0.249）就代表是早上的6點。
4.3 簡單案例（計算送貨天數）
綜合上訴兩點，影片中，舉了一個簡單的例子。
假設我們有兩個日期列，一個是發貨日期，一個是收貨日期。當我們需要送貨天數時，我們直接新建了計算列（送貨天數=收貨日期-發貨日期），畢竟日期就是數字，所以可以直接進行運算，得到的結果是XXXX年X月X天，並不是直接顯示間隔天數，只需修改這個計算列的資料格式為整數，送貨天數就以整數天數的形式展示了。