用了Power BI，不做關聯式資料庫到底行不行?

在課堂上解釋關聯式資料庫時，我舉出關聯式資料庫最重要的兩個好處: 1.減少資料庫大小以加快運算速度 2.減少人為輸入機會以減少人為錯誤。

但仍然有學員在下課空檔拿自己公司的資料來詢問: 如果目前的資料結構已經相當完整，資料量也還不到需要縮減資料量才能正常運作的大小，是否就不需要做成關聯式資料庫的形式呢?

我的答案是 "看需求而定，可以不用但做了會更好"。其實我在最一開始使用Power BI 時也有這種疑問，因為我其實跟這位學員一樣，即使沒有做成關聯式資料庫，我的資料結構也已經夠完整了。但評估了幾個面向後，最後還是決定花點時間調整成關聯式資料庫的結構。除了上面已經提到的兩點外，下面再分享幾個重點讓各位可以自行評估。

一、是否有 "有價值" 的額外資訊可以加入分析?

例如在 "日期維度表" 中，可以加入財務年/季等資訊。在 "業務維度表" 中，我可以加上每位業務的所屬分店/地區，他的到職日/年資…等資訊。

二、需分析的資料庫的規模數量有多大

有的公司分工細，每位員工只需要負責單一報表，對這點可能沒什麼感覺。但如果你需要負責較多或較廣的資料面向時，可能會遇到以下的狀況:

多個明細資料表 共用同個維度資料表，可避免重複工作

從圖中我們可以看到，時常會有不同的報表但有著相同的維度資料。這時如果有一個專屬的維度資料表，一來可以讓各報表共用，省下重複做的力氣外；二來在新增/更動維度表中的相關資料時，有統一的維度資料表會大大的降低維護資料所需的時間。

三、是否會有更複雜的資料表結構需要連結?

很多時候我們連結的資料表並非只有 "單一明細資料表(Fact table)" ；也可能需要連結兩個以上的明細表，或是還有延伸的維度明細表，這時關聯式資料庫就扮演了很重要的角色。(在專業的說法，前者的結構稱為 "星形結構" Star schema；後者的結構則稱為 "雪花結構" Snowflake schema。以個人的實際經驗來說，其實後者出現的頻率比較高。)

星形結構 與 雪花結構

以上是我個人使用Power BI 的經驗中整裡出來的重點與各位分享。