上週針對資料倉儲建模的方向進行了常時間討論，嘗試找到適合阿里巴巴資料倉儲平台發展的建模方法論。資料倉儲接典型的兩種資料倉儲建模的理論是維度建模和基於主題域的實體關係建模，這兩種方式分別以Kimball和Immon兩位大師為代表。維度建模以資料分析需求為驅動，倡導匯流排架構：一致的事實和一致的維度，此資料模型易於使用者理解和資料分析操作。基於主題域的實體關係建模以源系統數據為驅動，整合企業的所有數據，站在企業級的高度對數據進行抽象，整合，採用3NF的實體關係理論建模，這種數據建模方式以更抽象的方式嘗試建立一個相對穩定的資料模型，並能描述企業級的資料關係。在工業界往往把兩種方式結合起來運用資料倉儲的不同資料層次結構中。
我們上週主要是針對採用基於主題域的實體關係建模中資料整合的方式進行較為深入的討論，討論了以下三種思路：
以屬性聚集的方式同一主題域中不同實體的屬性。例如對於會員、公司、客戶等等實體物件我們都有地址屬性資訊、名稱標識屬性資訊等等，這種想法就是把屬性內聚性高的字段整合在一起，並把不同的屬性打上類型標識以樹表的形式存放。它的優點是：第一，模型穩定性好，外圍系統變化了字段，只需要添加不同的類型，不需要進行表結構的變更；第二，減少大量冗餘記歷史資料。它的缺點是：第一，丟失了很多實體的屬性標識信息，我們從模型上將看不到一個會員究竟有哪些地址屬性，只能通過查詢類型代碼才能獲取這些信息；第二，它極度的膨脹資料表的記錄數，因為它採用豎表的形式存放；第三，應用起來很難，效率是一個大問題，因為我們往往要使用一個實體的多個字段，就會有很多join操作和豎轉橫的操作。第四：屬性聚集也是比較難操作的過程，應為這是一個抽象的過程，對建模人員的業務背景知識和抽象能力都提出了很高的要求；第五：雖然減少了冗餘的記歷史數據，但是記歷史的操作也較為複雜。
採用物件導向建模的方式，抽像不同實體的共同屬性，然後再一步步採用繼承、組合等物件導向的思想具體化實體。他的優點是模型模型概念比較清晰，缺點也是模型相對不是很穩定，整合後的資料的後續應該也面臨重新組合的問題。
貼源的建模方式： 採用基本保持源系統的方式建模，重點放在資料的標準化，一致化，和資料業務意義的梳理。這種做法和我們目前資料倉儲的做法比較類似。它具有實施比較容易，快速實現，前台可以直接使用資料；缺點是整合度不高，模型不穩定。
模型終究是為資料分析應用服務的，具體採用什麼方式建模需要根據實際業務特徵和來源系統的特性決定。阿里巴巴的源系統具有變化快，數據分析應該變化快的特點，響應速度也要快的特點，而且我們要求不同系統之間整合的需求並不是很大，往往深度的數據整合帶來的是應用上的不方便。因此，我個人覺得採用貼源的方式是目前更優的方案。
本文出自CSDN博客，轉載請標示出處： http://blog.csdn.net/wsbupt/archive/2009/12/30/5109309.aspx
-