作者：Omniwaresoft / Project team / Antonio Chen

#商業智慧 #分析型資料架構 #保險業 #財務分析 #反正規化模型

前言

在資料分析領域中談到分析型資料應該要採取什麼樣的設計架構，就不能免俗地提到多年前對於資料分析架構的一場討論，再將話題延伸到當年為分析型資料所設計的架構，以及隨之衍生出的資料倉儲體系，是不是還適用於今日的時空環境的問題，最後再以保險業的實際案例作為一個小小的分享，讓讀者可以領略分析型資料架構的況味。

一場資料架構界的神仙打架

當 1989 年 Howard Dresner 將商業智慧 (Business Intelligence) 的概念廣泛介紹後，資料倉儲界的大師 Ralph Kimball 隨後提出了為分析架構而生的「維度模型」(Dimensional model)，一般也可以稱為「反正規化模型」(De-normalized model)；而另一位大師 Bill Inmon 則提出正規化模型 (Normalized model) 也可以作為資料倉儲模型，並不一定要大費周章建立一個反正規化模型的資料倉儲。

持平而論，兩者都沒有錯，正規化模型原本就是可供 OLTP 類型應用系統的使用，而在沒有資料倉儲架構之前，OLTP 類型的正規化架構 (也就是 Bill Inmon 主張的) 也是可以產出各類型報表及分析，一點問題都沒有，只是報表產出的過程當中，資訊人員的介入比例非常的高 (還記得「需求單」這個東西嗎？)。

所以當「使用者自行設計報表」(User reporting) 這面大旗被高舉之後，正規化模型的效率就趕不上反正規化模型了，那一塊一塊為特定分析目的而設計出的資料市集 (Datamart)，讓分析人員可以透過簡單的模型設計，就可以設計出自己的報表，不必假手他人。 

但是反正規化模型需要轉換，需要大量的 ETL 與資料驗證；而正規化模型則無此問題，而且隨著摩爾定律的不斷刷新，以及資料聯邦 (Data federation) 技術的逐漸推廣，正規化模型也有其擁護者。

那反正規化模型真的褪去光環了嗎？

這個問題，我們可以看一下業界常講的資料庫效能調校的金字塔模型：

在這個金字塔模型裡面，越下面的部分代表越可以事半功倍，越往上，不管是時間成本或是金錢成本，都會有倍數的成長。舉例來說，如果資料庫效能有問題，先要檢查資料庫架構設計上有沒有需要調整的；如果窮盡了一切手段，才會去想要不要更換應用程式 (如資料庫系統)；如果資料庫系統本身該升級的升級，該補丁的補丁，也許就是軟體平台的問題，也許該換成 Linux，或是虛擬平台換實體平台；最後的最後，如果一切都能調的都調了，但是資料量或用量已經大到超出硬體的物理極限了，才會想要更換硬體。

由以上可以看出良好的資料庫設計，能在最小的成本下，釋放出資料分析系統的最大效益。而適合使用者自行設計報表的反正規化模型，還是在目前先進的分析工具中 (如 Tableau 等)，最適合的資料模型。

反正規化模型的工法

反正規化模型的設計來源，都是來自於終端的分析需求，也就是不管來源資料如何的雜亂，都要設法把資料整理好，讓分析工具好取用資料，這其中牽涉到的工法如下：

1. 資料需求端訪談：設法引導出分析端的需求，並將之整理為簡明清晰的資料市集模型。
2. 資料來源端清點：將上述結果，嘗試在資料來源端找到正確的資料源，並確認來源端資料更新的頻率、資料型態是否符合終端的需求、資料的顆粒度 (Granularity) 是否可以支持終端的分析要求等。
3. 建立資料映對規則：此部分包含不同格式與廠牌的資料來源的落地 (Landing) 映對規則，以及落地端到分析端的資料轉置 (Data transformation) 的規則，必須詳細到欄位級別。
4. 建立資料驗證標準：此部分包含上段所述的映對規則後的資料驗證機制，以確保轉換的正確性。

透過以上機制，就可以基本上建成一個反正規化模型。而資料品質的監控體系，也是極為重要的，這之後再以專文加以討論。以下就以一個保險業財務分析小模型來說明反正規化模型的實踐方式。

保險業財務分析模型

如上段的工法所述，先確定需求端的要求，主要有以下幾項：

1. 固定式報表：如損益表、資產負債表等制式報表。
2. 分析型報表：建立各種分析用母版報表，備齊相關的分析欄位與篩選條件，供使用者取用母版並修改後，另存為特定的版本。
3. 與其他系統介接的介面資料檔：此部分的需求是與其他系統的交換檔，以及呈送到總部或是政府機關的法報檔等，以文字檔 (TXT 或 CSV) 方式產出。

在確定了需求端的規格之後，再來就是要調查來源端的資料是否可以滿足，而來源端的資料，主要包含以下幾項：

1. 保險業核心系統 (Core-insurance)：
   這就是上文所述的 OLTP 系統，也就是支持保險業日常營業的主要系統，其地位相當於金融業的 Core-Banking、製造業的 ERP、服務業的進銷存系統等。其中包含了各類型的主檔資料，如：

   • 客戶主檔、產品主檔、會計科目主檔、行銷方案主檔、乃至於業務員主檔等。
   • 各類型的交易明細檔，如保單主檔、要保人/被保人主檔。
   • 其他如集團匯率主檔等。

2. 上傳檔：
   財務分析的主體來自於財務人員製作的各類型分錄，其形態為試算表 (XLS) 形式的檔案，份數多但格式均一。
3. 其他計算所得之分錄檔：
   如共同成本分擔 (Common cost re-allocation) 的分錄，或是評價匯兌損益 (Foreign exchange evaluation) 的分錄等。

觀察上述資料來源的性質，可以看出 1 類的資料，是屬於反正規化模型中的分析維度，故為維度表格 (Dimensional tables)，而 2 與 3 含有分析的數值 (借方金額與貸方金額)，也稱之為量測值 (Measure/Metric)，故為事實表格 (Fact tables)，以反正規化星狀模型 (Star schema) 的精神予以規畫，大致如下圖：

根據上圖，所有外圍的維度表格都以一對多 (1:M) 的方式對應到中間的分錄交易檔，所有的報表都以至多一個連結即可組成需要的資料。

以這個星狀模型，組成各種類型的分析資料母版，也就是前段所述的資料市集。或許有人會問既然有了這個星狀模型，為什麼還需要組成資料市集，這是因為財務上的資料，都有「前期結轉」、「本期交易」、「期末餘額」等概念，故如果沒有將每一期結算後的金額算好留下，就不容易堆疊出上述的量測值，這是較為特別的一點。

至於從來源檔到星狀模型，以及星狀模型到資料市集的映對規則，屬於規則分析的範疇，也是資料分析師的工作，限於篇幅，不在此文討論。

結語

本文主要解釋反正規化模型的基本概念與規劃方式，也略述了一下實作的工法，但是文中每一段內容，都足以再深入探討，希望能引發讀到此文的讀者，對於資料倉儲規劃的興趣，也歡迎來信討論。

---