* 前言
前篇介紹一般使用者透過Power Query也可以使用的Data Cleansing小技巧,本篇會著重於進階使用者(IT)使用的方式。目的在於「怎麼產生有用的資料集」,這其中包含了異質資料的整合、Star schema or Snowflake schema的建模考量...等。
* Star schema or Snowflake schema
如果要分析的資料只有一種,其實不用Star schema,單純使用一個Fact Table來分析資料也是可行。但若需要分析兩種以上的資料(異質資料整合),那就需要star schema的建模考量。在建構star schema的過程中,可以想像成把Table做正規化。
主要優點
- 不需要花太多心力在檢查資料是否有重複計算
- Dimension Table的欄位可以重複利用來分析多份異質資料
缺點
- 要花時間構思怎麼拆Table
範例
- 目的:分析每位員工每天的工時、餐費
- 表:
- 員工表:Dim_Employee
- 工時表:Fact_WorkingHours
- 餐費表:Fact_MealExpense
- 日期表:Dim_Date
- Key:empId & date
- 建模:
- Table Visual
* Relation
這部份需要注意兩點:
* 欄位做關聯時,不分字串大小寫
例如以下Table:
Dim_Fruit
Fruit | UnitPrice |
---|---|
Apple | 10 |
APPle | 10 |
Banana | 5 |
Fact_Sales
Fruit | Date | Quantity |
---|---|---|
Apple | 2023/01/01 | 5 |
APPle | 2023/01/01 | 10 |
Banana | 2023/01/01 | 3 |
如果要做關聯時,就會跳出以下訊息,因為他認為Dim_Fruit中的Apple和APPle是一樣的東西,所以不能見關聯。
* 只支援「單一」欄位做關聯,不支援複合欄位做關聯
如果DB中有兩個Table需要多個欄位關聯,就不能直接將兩個Table直接匯入到PBI使用,要多做一點手腳。
範例
- 目的:分析各水果供應商的水果銷售金額
- 關聯:Vendor + Fruit
- 解法:
(1) 建立Key欄位:Vendor + Fruit (不推薦,會造成記憶體消耗太多,但很簡單)
(2) 建立Id (推薦)
小結
本篇簡單介紹了建模的核心概念 - Star Schema的優點和作法,也分享了2個在建關聯時可能會遇到的問題。下一篇還會再提到一些建模的小技巧,有了這些事前考量,會讓後續分析資料更容易,也不用花太多時間檢查資料正確性。