用了Power BI，不做關聯式資料庫到底行不行?
在課堂上解釋關聯式資料庫時，我舉出關聯式資料庫最重要的兩個好處 : 1. 減少資料庫大小以加快運算速度 2. 減少人為輸入機會以減少人為錯誤。 但仍然有學員在下課空檔拿自己公司的資料來詢問 : 如果目前的資料結構已經相當完整，資料量也還不到需要縮減資料量才能正常運作的大小，是否就不需要做成關聯式資料庫的形式呢 ? 我的答案是 " 看需求而定，可以不用但做了會更好 " 。其實我在最一開始使用 Power BI 時也有這種疑問，因為我其實跟這位學員一樣，即使沒有做成關聯式資料庫，我的資料結構也已經夠完整了。但評估了幾個面向後，最後還是決定花點時間調整成關聯式資料庫的結構。除了上面已經提到的兩點外，下面再分享幾個重點讓各位可以自行評估。 一、是否有 " 有價值 " 的額外資訊可以加入分析 ? 例如在 " 日期維度表 " 中，可以加入財務年 / 季等資訊。在 " 業務維度表 " 中，我可以加上每位業務的所屬分店 / 地區，他的到職日 / 年資 … 等資訊。 二、需分析的資料庫的規模數量有多大 有的公司分工細，每位員工只需要負責單一報表，對這點可能沒什麼感覺。但如果你需要負責較多或較廣的資料面向時，可能會遇到以下的狀況 : 多個明細資料表 共用同個維度資料表，可避免重複工作 從圖中我們可以看到，時常會有不同的報表但有著相同的維度資料。這時如果有一個專屬的維度資料表，一來可以讓各報表共用，省下重複做的力氣外；二來在新增 / 更動維度表中的相關資料時，有統一的維度資料表會大大的降低維護資料所需的時間。 三、是否會有更複雜的資料表結構需要連結 ? 很多時候我們連結的資料表並非只有 " 單一明細資料表 (Fact table)" ；也可能需要連結兩個以上的明細表，或是還有延伸的維度明細表，這時關聯式資料庫就扮演了很重要的角色。 ( 在專業的說法，前者的結構稱為 " 星形結構 " Star schema ；後者的結構則稱為 " 雪花結構 " Snowflake schema 。以個人的實際經驗來說，其實後者出現的頻率比較高。 )