資料倉庫專題（7）-次元模組化10大基本原則

一、前言

      特别聲明：本文整理自網際網路。

       遵循這些原則進行次元模組化可以保證資料粒度合理，模型靈活，能夠适應未來的資訊資源，違反這些原則你将會把使用者弄糊塗，并且會遇到資料倉庫障礙。

二、正文

　　原則1、載入詳細的原子資料到次元結構中

　 　次元模組化應該使用最基礎的原子資料進行填充，以支援不可預知的來自使用者查詢的過濾和分組請求，使用者通常不希望每次隻看到一個單一的記錄，但是你無法預測 使用者想要掩蓋哪些資料，想要顯示哪些資料，如果隻有彙總資料，那麼你已經設定了資料的使用模式，當使用者想要深入挖掘資料時他們就會遇到障礙。當然，原子數 據也可以通過概要次元模組化進行補充，但企業使用者無法隻在彙總資料上工作，他們需要原始資料回答不斷變化的問題。

　　原則2、圍繞業務流程建構次元模型

　 　業務流程是組織執行的活動，它們代表可測量的事件，如下一個訂單或做一次結算，業務流程通常會捕獲或生成唯一的與某個事件相關的性能名額，這些資料轉換 成事實後，每個業務流程都用一個原子事實表表示，除了單個流程事實表外，有時會從多個流程事實表合并成一個事實表，而且合并事實表是對單一流程事實表的一 個很好的補充，并不能代替它們。

　　原則3、確定每個事實表都有一個與之關聯的日期次元表

　　原則2中描述的可測量事件總有一個日期戳資訊，每個事實表至少都有一個外鍵，關聯到一個日期次元表，它的粒度就是一天，使用月曆屬性和非标準的關于測量事件日期的特性，如财務月和公司假日訓示符，有時一個事實表中有多個日期外鍵。

　　原則4、確定每個事實表中的事實具有相同的粒度或同級的詳細程度

　　在組織事實表時粒度上有三個基本原則：事務，周期快照或累加快照。無論粒度類型如何，事實表中的度量機關都必須達到相同水準的詳細程度，如果事實表中的事實表現的粒度不一樣，企業使用者會被搞暈，bi應用程式會很脆弱，或者傳回的結果根本就不對。

　　原則5、解決事實表中的多對多關系

　　由于事實表存儲的 是業務流程事件的結果，是以在它們的外鍵之間存在多對多(m:m)的關系，如多個倉庫中的多個産品在多天銷售，這些外鍵字段不能為空，有時一個次元可以為 單個測量事件賦予多個值，如一個保健對應多個診斷，或多個客戶有一個銀行賬号，在這些情況下，它的不合理直接解決了事實表中多值次元，這可能違反了測量事 件的天然粒度，是以我們使用多對多，雙鍵橋接表連接配接事實表。

　　原則6、解決次元表中多對一的關系

　　屬性之間分層的、多對一(m：1)的關系通常未規範化，或者被收縮到扁平型次元表中，如果你曾經有過為事務型系統設計實體關系模型的經曆，那你一定要抵抗住舊有的思維模式，要将其規範化或将m:1關系拆分成更小的子次元，次元反向規範化是次元模組化中常用的詞彙。

　　在單個次元表中多對一(m:1)的關系非常常見，一對一的關系，如一個産品描述對應一個産品代碼，也可以在次元表中處理，在事實表中偶爾也有多對一關系，如詳細當次元表中有上百萬條記錄時，它推出的屬性又經常發生變化。不管怎樣，在事實表中要慎用m:1關系。

　　原則7、存儲報告标記和過濾次元表中的範圍值

　 　更重要的是，編碼和關聯的解碼及用于标記和查詢過濾的描述符應該被捕獲到次元表中，避免在事實表中存儲神秘的編碼字段或龐大的描述符字段，同樣，不要隻 在次元表中存儲編碼，假定使用者不需要描述性的解碼，或它們将在bi應用程式中得到解決。如果它是一個行/列标記或下拉菜單過濾器，那麼它應該當作一個次元 屬性處理。

　　盡管我們在原則5中已經陳述過，事實表外鍵不應該為空，同時在次元表的屬性字段中使用“na”或另一個預設值替換空值來避免空值也是明智的，這樣可以減少使用者的困惑。

　　原則8、确定次元表使用了代理鍵

　 　按順序配置設定代理鍵(除了日期次元)可以獲得一系列的操作優勢，包括更小的事實表、索引以及性能改善，如果你正在跟蹤次元屬性的變化，為每個變化使用一個 新的次元記錄，那麼确實需要代理鍵，即使你的商業使用者沒有初始化跟蹤屬性改變的設想值，使用代理也會使下遊政策變化更寬松，代理也允許你使用多個業務鍵映 射到一個普通的配置檔案，有利于你緩沖意想不到的業務活動，如廢棄産品編号的回收或收購另一家公司的編碼方案。

　　原則9、建立一緻的次元內建整個企業的資料

　 　對于企業資料倉庫一緻的次元(也叫做通用次元、标準或參考次元)是最基本的原則，在etl系統中管理一次，然後在所有事實表中都可以重用，一緻的次元在 整個次元模型中可以獲得一緻的描述屬性，可以支援從多個業務流程中整合資料，企業資料倉庫總線矩陣是最關鍵的架構藍圖，它展現了組織的核心業務流程和關聯 的次元，重用一緻的次元可以縮短産品的上市時間，也消除了備援設計和開發過程，但一緻的次元需要在資料管理和治理方面有較大的投入。

　　原則10、不斷平衡需求和現實，提供使用者可接受的并能夠支援他們決策的dw/bi解決方案

　 　次元模組化需要不斷在使用者需求和資料源事實之間進行平衡，才能夠送出可執行性好的設計，更重要的是，要符合業務的需要，需求和事實之間的平衡是dw/bi 從業人員必須面對的事實，無論是你集中在次元模組化，還是項目政策、技術/etl/bi架構或開發/維護規劃都要面對這一事實。

三、未完待續

      分布式資料倉庫資料存儲模型設計進行中，後續會持續更新，請關注qq群：分布式資料倉庫模組化 398419457。