對於搞資料倉儲的人來說，面試的時候總會問及到lookup表的概念。。。。。。
對於搞資料倉儲的人來說，面試的時候總會問及到 lookup 表的概念，這個概念一開始對我而言也是很莫名其妙的；明明基礎表和事實表的乙個關聯就可以完成的事情需要什麼 lookup 表。
通常的做法
select a.id,sum(measure1) as measure1,sum(measure2) as measure2 from table_original a,table_dimension b
where a.id = b.id
為了嚴謹起見，我們的處理最多是加以 null 值或者未匹配鍵值的處理
select -- a.id,b.id, -- the transformed field names id
decode(nvl(a.id,-2),-2,-2, decode(nvl(b.id,-1),-1,-1,b.id)) as id,
sum(case a.measure1>0 and a.measure1<100 then measure1 else 0 end
) measure1,
sum(case a.measure2>0 and a.measure2<100 then measure2 else 0 end
) measure2,
from table_original a,table_dimension b
where a.id = b.id(+)
group by decode(nvl(b.id,-2),-2,-2, decode(nvl(b.id,-1),-1,-1,b.id))
但是對於老外來說，為了嚴謹起見，把維度做為歷史處理的軌跡進行儲存，主要是全記錄處理方式其中包括版本號方式、時戳方式、標誌方式（具體處理方式參看資料倉儲系列文章）；所以必須增加乙個**主鍵，以記錄和替代原來不斷變化的內容，從而儲存原主鍵資訊的變化軌跡。主鍵的變化導致與原事實表關聯過程中的脫節，必須使用新的外來鍵**原來的外鍵值。同時主鍵的變化導致在與事實表關聯過程的變化，當然我們也可以使用複雜的檢視和函式方式尋找到相應的外鍵值；但是對於老外來說寧願用最簡單的方式，圖形化的操作和最直觀的方式進行處理，畢竟資料庫、資料倉儲、 etl 圖形工具全部都是由老外發明的。實現的原理其實很簡單：
關於資料倉儲的想法
要能夠把企業的資料從巨集觀到微觀能夠清晰表達，並且能夠實現出來。需要首先有乙個全域性的了解，將整個crm系統進行巨集觀的歸併，得到高層資料檢視，並加以抽象，劃定幾個邏輯的資料主題範圍 然後再對目前需要做的報表所在的主題進行資料分析和主題定義 如果主題還過大還需要進行分解，定義低一級的主題 定義維 度...
資料倉儲 事實表
事實表分成三種 事務事實表 週期快照事實表 累計快照事實表 官方定義是 發生在某個時間點上的乙個事件。比如以訂單為例 下單是乙個事實 付款是乙個事實 退款是乙個事實，所有事實的累計就是事務事實表 如果需要對某一天或者某個月的資料進行分析，那麼可以使用週期快照事實表，比如 以天舉例，財務報表一般都是週...
資料倉儲 維度表
維度建模將業務抽象成事實和維度兩個概念。維度建模的核心是對齊維度。所以維度表的一致性是很重要的！維度表是如何進行處理的呢？穩定的維度表。比如 時間維度表 這種維度表的屬性是穩定的，不需要做天的全量快照資料，直接匯入一次即可 緩慢漸變維 維度會隨著時間發生緩慢的變化。比如 使用者維度表 資料量很大，但...