數(shù)據(jù)倉庫的幾個原則，讓你避免“陷阱”

想要數(shù)據(jù)粒度的合理性、模型的靈活性得到保證，并且能夠適應未來的信息資源，需要遵守維度建模的一些原則。否則，很容易會遇到數(shù)據(jù)倉庫障礙，并且把用戶弄糊涂。

1.原子數(shù)據(jù)需詳細

維度建模應該使用最基礎的原子數(shù)據(jù)進行填充，以支持不可預知的來自用戶查詢的過濾和分組請求。

用戶通常不希望每次只看到一個單一的記錄，但是你無法預測用戶想要掩蓋或顯示哪些數(shù)據(jù)。如果只有匯總數(shù)據(jù)，那么你已經(jīng)設定了數(shù)據(jù)的使用模式，當用戶想要深入挖掘數(shù)據(jù)時，他們就會遇到障礙。盡管原子數(shù)據(jù)通過概要維度建模補充也是一種辦法，但是這樣做的話，企業(yè)用戶便無法只在匯總數(shù)據(jù)上工作，畢竟，他們需要原始數(shù)據(jù)回答不斷變化的問題。

2.使用代理鍵

按順序分配代理鍵（除了日期維度）可以獲得一系列的操作優(yōu)勢，包括更小的事實表、索引以及性能改善。如果你正在跟蹤維度屬性的變化，并需要為每個變化使用一個新的維度記錄，那么代理鍵就顯得十分重要了。因為，即使你的商業(yè)用戶沒有初始化跟蹤屬性改變的設想值，使用代理也會使下游策略變化更寬松。另外，代理也允許使用多個業(yè)務鍵映射到一個普通的配置文件中，這有利于緩沖意想不到的業(yè)務活動。

3.標記和過濾范圍值

值得注意的是，編碼、關聯(lián)的解碼、用于標記和查詢過濾的描述符，應該被捕獲到維度表中，避免在事實表中存儲神秘的編碼字段或龐大的描述符字段。同樣的，不要只在維度表中存儲編碼，而要假定用戶不需要描述性的解碼，或它們將在BI應用程序中得到解決。如果它是一個行/列標記或下拉菜單過濾器，那么它應該當作一個維度屬性處理。

另外，事實表的外鍵不應該為空，同時在維度表的屬性字段中應使用“NA”或另一個默認值來替換空值，這也是明智的，可以減少用戶的困惑。

4.一致的維度，集成整個企業(yè)的數(shù)據(jù)

企業(yè)數(shù)據(jù)倉庫一致的維度（也叫做通用維度、標準或參考維度）是最基本的原則，它在ETL系統(tǒng)中管理一次后，在所有事實表中都可以重用。

一致的維度，在整個維度模型中可以獲得一致的描述屬性，可以支持從多個業(yè)務流程中整合數(shù)據(jù)。企業(yè)數(shù)據(jù)倉庫總線矩陣是最關鍵的架構藍圖，它展現(xiàn)了組織的核心業(yè)務流程和關聯(lián)的維度，重用一致的維度可以縮短產(chǎn)品的上市時間，也消除了冗余設計和開發(fā)過程，但一致的維度需要在數(shù)據(jù)管理和治理方面有較大的投入。

5.圍繞業(yè)務流程建模

業(yè)務流程是組織執(zhí)行的活動，它們代表可測量的事件，如下一個訂單或做一次結算。業(yè)務流程通常會捕獲或生成唯一的與某個事件相關的性能指標，當這些數(shù)據(jù)轉換成事實后，每個業(yè)務流程都會用一個原子事實表表示。除了單個流程事實表外，有時會以多個流程事實表合并成一個事實表，而且合并事實表是對單一流程事實表的一個很好的補充。

6.相同的粒度或同級的詳細程度

在組織事實表時，粒度上有三個基本原則：事務、周期快照、累加快照。無論粒度類型如何，事實表中的度量單位都必須達到相同水平的詳細程度；如果事實表中的事實表現(xiàn)的粒度不一樣，企業(yè)用戶容易混淆，BI應用程序也會隨之變得不堪一擊，從而導致返回的結果不對等低級錯誤的發(fā)生。

7.一對一的關聯(lián)日期維度表

如上文所說，每個可測量事件總有一個日期戳信息，每個事實表至少需要有一個外鍵，能夠關聯(lián)到一個日期維度表，它的粒度就是一天。這個方法，利用的是日歷屬性和非標準的關于測量事件日期的特性，如財務月和公司假日的指示符；當然，有時一個事實表中會有多個日期外鍵。

8.解決多對一關系

屬性之間分層的、多對一（M：1）的關系，通常是未規(guī)范化的，或者被收縮到扁平型的維度表中。如果你曾經(jīng)有過為事務型系統(tǒng)設計實體關系模型的經(jīng)歷，那你一定要摒棄掉舊有的思維模式，將其規(guī)范化或將M：1關系拆分成更小的子維度。維度反向規(guī)范化，便是維度建模中常用的詞匯。

一對一的關系，如一個產(chǎn)品描述對應一個產(chǎn)品代碼，可以在維度表中處理。然而，在單個維度表中，多對一（M：1）的關系也非常常見，在事實表中偶爾也有多對一關系，如當維度表中有上百萬條記錄，而它推出的屬性又經(jīng)常發(fā)生變化時。不管怎樣，在事實表中要慎用M：1關系。

9.解決多對多關系

由于事實表存儲的是業(yè)務流程事件的結果，因此在它們的外鍵之間存在多對多（M：M）的關系，如多個倉庫中的多個產(chǎn)品在多天銷售，這些外鍵字段便不能為空。有時一個維度可以為單個測量事件賦予多個值，如一個保健對應多個診斷，或多個客戶有一個銀行賬號，在這些情況下，它的不合理直接解決了事實表中多值維度，這可能違反了測量事件的天然粒度，因此我們使用多對多、雙鍵橋接表連接事實表。

10.平衡需求和現(xiàn)實，提供DW/BI解決方案

維度建模需要不斷在用戶需求和數(shù)據(jù)源事實之間進行平衡，才能夠提交可執(zhí)行性好的設計。更重要的是，要符合業(yè)務的需要，需求和事實之間的平衡是DW/BI從業(yè)人員必須面對的事實，無論是集中在維度建模，還是項目策略、技術/ETL/BI架構，或開發(fā)/維護規(guī)劃，都要面對這一事實。

總的來說，數(shù)據(jù)倉庫維度建模需要注意的部分挺多，在建模的過程中務必要多留心眼，細致謹慎，這才是成功之道。尤其進入大數(shù)據(jù)時代，與數(shù)據(jù)打交道的機會愈趨增多，要想成為工作中的“常勝將軍”，切忌馬虎。