數據管理壹直在演進，從早期的電子表格、蛛網系統到架構式數據倉庫。發展至今以維度建模和關系建模為主，而隨著互聯網的發展，數據從GB到PB的裱花，企業業務叠代更新亦是瞬息萬變，對維度模型的偏愛漸漸有統壹互聯網數倉建模標準的趨勢。
數倉模型不分高下，都是壹種觀察現實的角度。維度模型以實體與實體之間發生的事務/實為切入，而關系建模則以實體與實體之間的關系來組織數據。在當前的環境下，互聯網更傾向於維度建模，而傳統行業則較多沿用關系建模。
個人先後經歷金融、互聯網數倉建設，有多個0到1的項目經歷，對於數倉建設仍在持續學習中。如有錯誤之處，還請多指出交流。
以事實表為核心，多個維度表作為手臂形成的星型模型，是維度建模的典型實現方式。
事實表，記錄業務過程中發生的可度量事件，如訂單中的消費金額，折扣金額或是庫存數量等，在實際業務中事實表占據主要的存儲，如訂單表；而維度表，則是對業務過程度量有關的文本環境，描述“誰、什麽、哪裏、何時、如何、為什麽”，常用的維度表有日期、產品、用戶、地址等。壹般維度表會冗余信息，有超過100個列的維度表，這樣的不規範化帶來數據組織上的簡單。
關系建模，被稱為“實體-關系”模型，以壹種“標準化”的方式存在，強調數據之間非冗余，滿足3NF。在建設過程中，將數據標準化到細節級數據，如用戶主題下，會有用戶與姓名、用戶與年齡、用戶與住址等。在傳統行業中，成熟的關系建模有ls-ldm模型，面向金融行業形成10大主題。
維度建模 ： 從實際的需求出發進行數據建設，壹般面向部門/業務形成獨立的數據集市，這樣的方式帶來鮮明的特點，高效。但由於基於需求出發，往往導致頻繁的需求叠代帶來的維護成本較高，壹旦業務過程發生調整，模型有可能會重來的風險。
關系建模 ：面向企業進行模型建設，具有較強的抽象性。建設時以3NF的方式建設無冗余的數據，使模型具有很高的靈活性，但由於不能直接面向需求，效率上不如維度模型。另外面向企業建設，周期相比於維度建模，要長的多，但也有個好處：企業數據集成更容易。
在企業內，這兩種建模方式往往同時存在，基礎數據倉庫的建設使用關系建模，技術的優雅換來了數據的精簡，保證高度抽象、高度壹致性，要求業務穩定；往上維度建模更合適壹些，偏向於直接面對業務，靠數據的冗余帶來了可用性，保證查詢效率。兩者優勢互補
在大數據的環境下，數據存儲和發展已發生很大變化，曾經的維度建模和關系建模在當前的場景下都有各自的不足之處。那數據倉庫在大數據環境下如何發展、成熟？Inmon等就提出了data vault模型
data valult是壹個面向細節的、歷史追溯的並且唯壹鏈接的規範化表集，能給支持壹個或者多個業務功能區；是壹種中心輻射式模型，其設計重點圍繞著業務鍵的集成模式。data vault有三種基本的實體(結構)
從建模風格上看，它采用了壹種由第三範式方法與維度建模方法混合而成的方式，以二者的獨特組合來滿足企業需求。