轉自：https://www.2cto.com/kf/201709/684395.html
遵循這些原則進行維度建模可以保證數據粒度合理，模型靈活，能夠適應未來的信息資源，違反這些原則你將會把用戶弄糊塗，並且會遇到數據倉庫障礙。
原則一: 載入詳細的原子數據到維度結構中
維度建模應該使用最基礎的原子數據進行填充，以支持不可預知的來自用戶查詢的過濾和分組請求，用戶通常不希望每次只看到一個單一的記錄，但是你無法預測用戶想要掩蓋哪些數據，想要顯示哪些數據，如果只有匯總數據，那么你已經設定了數據的使用模式，當用戶想要深入挖掘數據時他們就會遇到障礙。當然，原子數據也可以通過概要維度建模進行補充，但企業用戶無法只在匯總數據上工作，他們需要原始數據回答不斷變化的問題。
原則二: 圍繞業務流程構建維度模型
業務流程是組織執行的活動，它們代表可測量的事件，如下一個訂單或做一次結算，業務流程通常會捕獲或生成唯一的與某個事件相關的性能指標，這些數據轉換成事實后，每個業務流程都用一個原子事實表表示，除了單個流程事實表外，有時會從多個流程事實表合並成一個事實表，而且合並事實表是對單一流程事實表的一個很好的補充，並不能代替它們。
原則三: 確保每個事實表都有一個與之關聯的日期維度表
原則二中描述的可測量事件總有一個日期戳信息，每個事實表至少都有一個外鍵，關聯到一個日期維度表，它的粒度就是一天，使用日歷屬性和非標准的關於測量事件日期的特性，如財務月和公司假日指示符，有時一個事實表中有多個日期外鍵。
原則四: 確保每個事實表中的事實具有相同的粒度或同級的詳細程度
在組織事實表時粒度上有三個基本原則：事務，周期快照或累加快照。無論粒度類型如何，事實表中的度量單位都必須達到相同水平的詳細程度，如果事實表中的事實表現的粒度不一樣，企業用戶會被搞暈，BI應用程序會很脆弱，或者返回的結果根本就不對。
原則五: 解決事實表中的多對多關系
由於事實表存儲的是業務流程事件的結果，因此在它們的外鍵之間存在多對多(M:M )的關系，如多個倉庫中的多個產品在多天銷售，這些外鍵字段不能為空，有時一個維度可以為單個測量事件賦予多個值，如一個保健對應多個診斷，或多個客戶有一個銀行賬號，在這些情況下，它的不合理直接解決了事實表中多值維度，這可能違反了測量事件的天然粒度，因此我們使用多對多，雙鍵橋接表連接事實表。
原則六: 解決維度表中多對一的關系
屬性之間分層的: 多對一(M：1)的關系通常未規范化，或者被收縮到扁平型維度表中，如果你曾經有過為事務型系統設計實體關系模型的經歷，那你一定要抵抗住舊有的思維模式，要將其規范化或將M:1關系拆分成更小的子維度，維度反向規范化是維度建模中常用的詞匯。在單個維度表中多對一(M:1)的關系非常常見，一對一的關系，如一個產品描述對應一個產品代碼，也可以在維度表中處理，在事實表中偶爾也有多對一關系，如詳細當維度表中有上百萬條記錄時，它推出的屬性又經常發生變化。不管怎樣，在事實表中要慎用M:1關系。
原則七: 存儲報告標記和過濾維度表中的范圍值
更重要的是，編碼和關聯的解碼及用於標記和查詢過濾的描述符應該被捕獲到維度表中，避免在事實表中存儲神秘的編碼字段或龐大的描述符字段，同樣，不要只在維度表中存儲編碼，假定用戶不需要描述性的解碼，或它們將在BI應用程序中得到解決。如果它是一個行/列標記或下拉菜單過濾器，那么它應該當作一個維度屬性處理。盡管我們在原則5中已經陳述過，事實表外鍵不應該為空，同時在維度表的屬性字段中使用“NA”或另一個默認值替換空值來避免空值也是明智的，這樣可以減少用戶的困惑。
原則八: 確定維度表使用了代理鍵
按順序分配代理鍵(除了日期維度)可以獲得一系列的操作優勢，包括更小的事實表: 索引以及性能改善，如果你正在跟蹤維度屬性的變化，為每個變化使用一個新的維度記錄，那么確實需要代理鍵，即使你的商業用戶沒有初始化跟蹤屬性改變的設想值，使用代理也會使下游策略變化更寬松，代理也允許你使用多個業務鍵映射到一個普通的配置文件，有利於你緩沖意想不到的業務活動，如廢棄產品編號的回收或收購另一家公司的編碼方案。
原則九: 創建一致的維度集成整個企業的數據
對於企業數據倉庫一致的維度(也叫做通用維度: 標准或參考維度)是最基本的原則，在ETL系統中管理一次，然后在所有事實表中都可以重用，一致的維度在整個維度模型中可以獲得一致的描述屬性，可以支持從多個業務流程中整合數據，企業數據倉庫總線矩陣是最關鍵的架構藍圖，它展現了組織的核心業務流程和關聯的維度，重用一致的維度可以縮短產品的上市時間，也消除了冗余設計和開發過程，但一致的維度需要在數據管理和治理方面有較大的投入。
原則十: 不斷平衡需求和現實，提供用戶可接受的並能夠支持他們決策的DW/BI解決方案
維度建模需要不斷在用戶需求和數據源事實之間進行平衡，才能夠提交可執行性好的設計，更重要的是，要符合業務的需要，需求和事實之間的平衡是DW/BI從業人員必須面對的事實，無論是你集中在維度建模，還是項目策略: 技術/ETL/BI架構或開發/維護規划都要面對這一事實