數據倉庫數據建模的幾種思路

2024-07-21 02:45:08

字體：大中小

來源：轉載

供稿：網友

上周針對數據倉庫建模的方向進行了常時間討論，嘗試找到一種適合阿里巴巴數據倉庫平臺發展的建模方法論。數據倉庫接典型的兩種數據倉庫建模的理論是維度建模和基于主題域的實體關系建模，這兩種方式分別以Kimball和Immon兩位大師為代表。維度建模以數據分析需求為驅動，倡導總線架構：一致的事實和一致的維度，這種數據模型易于用戶理解和數據分析操作。基于主題域的實體關系建模以源系統數據為驅動，整合企業的所有數據，站在企業級的高度對數據進行抽象，整合，采用3NF的實體關系理論建模，這種數據建模方式以更為抽象的方式嘗試建立一個相對穩定的數據模型，并能描述企業級的數據關系。在工業界往往把兩種方式結合起來運用數據倉庫的不同數據層次結構中。

我們上周主要是針對采用基于主題域的實體關系建模中數據整合的方式進行較為深入的討論，討論了以下三種思路：

以屬性聚集的方式同一主題域中不同實體的屬性。比如對于會員、公司、客戶等等實體對象我們都有地址屬性信息、名稱標識屬性信息等等，這種思路就是把屬性內聚性高的字段整合在一起，并把不同的屬性打上類型標識以樹表的形式存放。它的優點是：第一，模型穩定性好，外圍系統變化了字段，只需要添加不同的類型，不需要進行表結構的變更；第二，減少大量冗余記歷史數據。它的缺點是：第一，丟失了很多實體的屬性標識信息，我們從模型上將看不到一個會員究竟有哪些地址屬性，只能通過查詢類型代碼才能獲取這些信息；第二，它極度的膨脹數據表的記錄數，因為它采用豎表的形式存放；第三，應用起來很難，效率是一個大問題，因為我們往往要使用一個實體的多個字段，就會有很多join操作和豎轉橫的操作。第四：屬性聚集也是一件比較難操作的過程，應為這是一個抽象的過程，對建模人員的業務背景知識和抽象能力都提出了很高的要求；第五：雖然減少了冗余的記歷史數據，但是記歷史的操作也較為復雜。
采用面向對象建模的方式，抽象不同實體的共同屬性，然后再一步步采用繼承、組合等面向對象的思想具體化實體。他的優點是模型模型概念比較清晰，缺點也是模型相對不是很穩定，整合后的數據的后續應該也面臨重新組合的問題。
貼源的建模方式：采用基本保持源系統的方式進行建模，重點放在數據的標準化，一致化，和數據業務意義的梳理。這種做法和我們目前數據倉庫的做法比較類似。它具有實施比較容易，快速實現，前臺可以直接使用數據；缺點是整合度不高，模型不穩定。
模型終究是為數據分析應用服務的，具體采用什么方式建模需要根據實際業務特點和源系統的特點決定。阿里巴巴的源系統具有變化快，數據分析應該變化快的特點，響應速度也要快的特點，而且我們要求不同系統之間整合的需求并不是很大，往往深度的數據整合帶來的是應用上的不方便。因此，我個人覺得采用貼源的方式是當前更優的方案。

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/wsbupt/archive/2009/12/30/5109309.aspx

上一篇：SQL 2005 發送郵件存儲過程

下一篇：ETL架構中考慮的六個關鍵因素