前一天介紹了資料庫與資料倉儲的差別，今天我們來討論構建資料倉儲的維度模型。
OLAP Cubes
維度表Dimension Table裡面的欄位都是放文字型態的Descriptive Context(非數字)
維度屬性表三個主要用途：
DW做得好不好就看你的維度屬性設計得好不好，而維度表通常有很多欄位columns，每一個欄位都代表問題指標
有些維度屬性有階層hierarchies的狀況，使用向下鑽探Drill Down或上捲Roll Up來查看不同層次的問題，而越完整的維度屬性即可以轉換成越完整的分析能力。
事實表Fact Table放的是Measurements(測度、測量)可以被度量的數值型態(非文字)，事實表裡面都是一堆外來鍵FK(Foreign Key)，這些FK構成事實表的主鍵PK(Primary Key)，剩下的都是Fact
Fact是具有可加性additive的，Fact屬於數值型numeric：
一張事實表裡面只能存在一種顆粒，不同資料顆粒不能放一起比較，不同的顆粒要放在不同的事實表當中
花費最多時間的不是建置維度屬性表而是事實表的整理，事實表也就是做機器學習之前所取得的原始資料，從蒐集原始資料、進行資料清理、針對龐大的資料庫做維護等等，如果一開始沒有在選用資料或做資料清理時設想好處理手法，導致後來需要花大量時間修改補救很多地方，只要錯誤發現的越晚，就越難補救，先前所有儲存在資料庫的資料也要一併修改，是非常曠日廢時的。
平常我們說一筆交易記錄是用record記錄來稱呼，而在資料倉儲當中的事實表，要使用granular顆粒來表示，描述一個事實表的顆粒度大小
宣告資料顆粒就是去明確指定事實表裡面的每一列代表的東西，例：每掃描一次條碼就有一個資料顆粒，只要把明確的事情描述清楚了就是把資料顆粒宣告清楚
因為DW面對的環境都是歷史資料(增刪改查都不會發生在DW/BI當中)，所以不需要做正規化，所以模型才用星狀綱要模型。
今天先介紹到這，明天我們對維度模型做延伸討論。
iThome鐵人賽
看影片追技術