以下注意事項按照重要性相反順序排列，但即便是前面的錯誤也會導致嚴重後果。
錯誤12：將文字屬性留在事實表中。
　　建立維度模型實際上是將數值測量和描述性文字屬性分別放在事實表和維度表中的過程。針對某個測量操作，首先將數值測量歸入事實表中，然後將測量的上下文中的描述性文字屬性歸入維度表中，最後，要對殘留的程式碼和偽數值項逐一判斷，應該屬於事實表還是維度表。這個過程中可能會錯誤地將描述性文字納入事實表中，尤其可能留在事實表的“備註”之類的欄位中，這種情況是應該避免的。

例：針對超市收銀的操作，一條記錄可能包括：商品名、件數、單價、交易時間、收銀臺ID、超市等，它們分別應該歸納到事實表還是維度表中呢？

錯誤11：忽略維度表中的詳細描述屬性。
　　有些設計者可能為了減小維度表，而犧牲描述上下文。但維度表在幾何數量上通常遠小於事實表，縮小維度表空間對效能提升有限，而在每個維度上提供詳細的描述上下文，確保用可讀的描述文字來定義每一個編碼，對資料倉庫的易用性提升是非常明顯的。

錯誤10：將層次結構劃分成多個維度
　　層次結構就是一系列級聯的多對一關係，例如許多個產品屬於一個品牌，許多品牌屬於一個商品類別。此時應該用一個包含“產品名稱、品牌、所屬商品類別”欄位的表作為產品維度表，而不是建立產品維度表、品牌維度表和商品類別維度表這樣3個表。
　　理解層次結構應該是前端或者使用者的事，資料倉庫的任務是以最自然有效的方式來呈現它們，一個層次結構應該屬於單一的物理扁平化維度表。
　　總之，大多數情況下，只要確保該維度是在最小可能粒度上定義的，那麼在一個維度中包含所有的層次結構就是合理的。例如這個例子中應該定義成“產品維度表”，如果定義在品牌粒度上，那麼具體每個產品的資訊就丟失了。

錯誤９：沒有正確使用漸變維度（SCD）
　　有很多資料倉庫專案會重寫重要維度，例如顧客和產品，這些維度都來自基礎的資料來源。這違背了資料倉庫的基本原則：準確表示歷史資料。
　　SCD是每一個數據倉庫必要的設計元素。
錯誤８：使用智慧鍵將維度表聯結到事實表
　　在設計維度表中連線到事實表外來鍵的主鍵時，剛入門的資料倉庫設計者往往會望文生義，將整套維度屬性宣告為維度表鍵，這會導致各種問題。
　　正確處理方法是用一個代理鍵替換智慧物理鍵，且最好是用１～Ｎ的順序編號（Ｎ＝維度表中記錄數量）的簡單整數代理鍵。
錯誤７：在確定測量值的粒度確定之前將維度新增到事實表
　　維度設計應該首先識別測量源，然後確定測量的準確粒度和含義，最後用該粒度上的維度來圍繞這些測量。
　　忠實於粒度是維度資料模型設計中的關鍵。
錯誤６：基於特定的報告來定義維度模型

　　維度模型與預期的報告沒有任何關係！
　　維度模型是測量過程的模型，數值測量形成了事實表的基礎，適用於指定事實表的維度是描述測量環境的上下文。維度模型牢牢基於測量過程。
　　也就是說如何按照使用者要求展現報告，是資料倉庫下游和前端要完成的任務，他們將維度模型中的資料按照使用者需求轉換並載入到前端展現出來，而維度模型本身是根據數值測量過程來定義的，完全獨立於業務使用者。
錯誤５：在相同事實表中混合不同粒度的事實
　　維度設計中的嚴重錯誤是將“有幫助的”彙總過的事實新增到事實表，如描述擴充套件的根據時間段或地區彙總的記錄。儘管這些特別的事實似乎會讓一些特定程式更簡單，但這破壞了事實表本身的結構，會造成更多的錯誤結果。
錯誤４：不基於最低級別原子資料構建維度模型
　　最低級別資料是最具維度性的，且應該是維度化設計的物理基礎。聚合的資料已經失去了一些維度。如果基於聚合的資料構建一個維度模型，那麼使用者就無法向下鑽取到原子資料，也就是說無法查詢到最詳細的細節資料。
　　應該基於原子的資料來構建所有維度模型，讓所有原子資料成為資料倉庫展示區域的一部分，這樣使用者才可以向下鑽取到最詳細的細節。
錯誤３：在面對查詢效能瓶頸時忽略“聚合事實表並且收縮維度表”的方案；通過新增更多並行處理硬體來解決效能問題
　　聚合（如Oracle的物化檢視和DB2的自動彙總表）是提升查詢效能的單一的最具成本優勢的方式。大多數查詢工具都明確支援聚合，並且這些工具都依賴維度建模構造。
　　首先通過構建聚合、選擇具有查詢效率的DBMS軟體、構建大量索引、增加實體記憶體以及提高CPU速度來提高查詢效能，這些方法還是滿足不了效能需求，再考慮新增並行處理硬體。
錯誤2：未能跨獨立事實表讓事實一致化
　　如果在源自不同基礎系統的兩個或多個維度模型中有一個相同的數值測量事實（如收益），那麼就需要完全明確這些事實的定義以便區分。
錯誤１：未能跨獨立事實表一致化維度
　　這是最大的錯誤，因為維度建模最重要的設計技術就是一致化維度。如果兩個或多個事實表具有相同的維度，那麼一定要讓這些維度完全相同或者有子集的關係。在跨事實表維度一致化時，將能夠橫向鑽取不同的資料來源，因為約束和行標題表示的含義是相同的並且可以在資料層面進行匹配。一致化維度是構建分散式資料倉庫的獨家祕方，可以為已有的資料倉庫增加非預期的新資料來源，並且讓多種不相容的技術和諧地共同發揮作用。