1、.：.；12 : 47 代理鍵的思索 代理鍵surrogate key這個概念是球派提出來的，在這個鏈接中可以找到kimball對它的描畫，這篇文章還是1998年寫的，比較早了。我們在2000年設(shè)計QiDSS時，采用的是informix公司的方案，基于redbrick、metacube，可以說這個方案充溢著球派的痕跡，畢竟kimball就是redbrick的開創(chuàng)人。在這種情況下，我們不接納他的洗腦都難。運用代理鍵便是其中之一，kimball說了很多益處，我們也沒法去驗證，更來不及去疑心，反正不斷都用著。不過時間長了，就有人提出疑問，happypu在dwway論壇上提出了這個問題，何謂代理建，a

2、tiger給出了答案，比較常規(guī)的回答，代理鍵一個主要的功能是反映變化。可以換一個角度來了解，從面向?qū)ο笏枷氤霭l(fā)，一個維其實是一個class，而維成員是他的實例，object，在業(yè)務(wù)數(shù)據(jù)庫的代碼表中，主要記錄的是當前形狀，所以業(yè)務(wù)代碼表記錄的的是最近時辰一切維成員對象，對象ID就是碼表主鍵。而對于數(shù)據(jù)倉庫中的維表，他要表示歷史信息，要記錄的內(nèi)容是歷史上一切的維成員對象，而原有的業(yè)務(wù)主鍵一定不能作為對象ID，由于他不是獨一的了，而用業(yè)務(wù)主鍵結(jié)合變卦時間作為主鍵大家都不會贊同吧。因此，代理鍵就出現(xiàn)了，它就是“歷史上一切的維成員對象的對象ID。當然，kimball還又很多其他的理由運用代理鍵，這里也不

3、鼓吹了，畢竟有些益處我也沒有對比過。但是就運用代理鍵，在目前工程中遇到的一些問題卻是不得不說一下。首先，代理鍵的維護問題。代理鍵是一種自動添加的整型字段，如oracle的sequence，sql server的identy字段，對于那種慢速變化維SCD，這同樣是球派提出的，請看kimball對slowly changing dimensions的描畫。，要保證在數(shù)據(jù)倉庫建立生命周期內(nèi)，業(yè)務(wù)代碼和代理鍵的對應(yīng)關(guān)系是穩(wěn)定的。例如有個工程，在實施過程中，一旦維表構(gòu)造有稍許修正，就刪掉一切維表數(shù)據(jù)重新初始化，而此時很能夠打亂原有的對應(yīng)關(guān)系。原來的A對應(yīng)2，重新初始化以后就對應(yīng)到3上去了。呵斥的后果可以

4、想象，原來相關(guān)的現(xiàn)實表數(shù)據(jù)需求重新裝載，甚至假設(shè)有援用了這個值的報表SQL，存儲過程都需求修正。所以在代理鍵的維護過程中，一定要保證對應(yīng)關(guān)系的穩(wěn)定性和每次維護前的備份。再者，代理鍵被客戶接納的程度。在onteldatastage討論組中曾經(jīng)討論過著個問題。目前階段，報表還是關(guān)鍵的運用，在報表SQL中援用代理鍵總不如援用業(yè)務(wù)鍵值那樣順，例如客戶對于業(yè)務(wù)類型代碼、城市代碼都很熟習，普通看到代碼就知道是那個業(yè)務(wù)或城市，而運用代理鍵值，讓客戶很迷糊。所以這不利于系統(tǒng)的推行。對此，暫時沒有想到什么好的方法，只能暫時先在維表中放上業(yè)務(wù)代碼字段。但是仍有個問題，代理鍵和業(yè)務(wù)代碼不一定是一對一關(guān)系的，例如多個

5、數(shù)據(jù)源系統(tǒng)的不同代碼映射到同一個代理鍵。這種情況，嘿嘿，只能看從哪個數(shù)據(jù)源出報表需求多了。08 : 59 再探數(shù)據(jù)形狀 我們以前工程中經(jīng)常想對度量進展分類，由于有些度量在計算匯總時要區(qū)別對待。為了區(qū)分，我們分成時點值和時期值，對于時點值，是不可累加的，例如在網(wǎng)用戶數(shù)、歷史欠費總金額、帳戶余額等。這些度量反響的時特定時間點的一個形狀值，不能在時間上累加，所以我們描畫這個目的的時候，普通也都需求帶上一個時間點定語，例如截至4月1日的在網(wǎng)用戶數(shù)、到9月30日的歷史欠費金額等。而對時期值，反響的是某個時間周期類的發(fā)生的值，例如通話費用、通話時長、新增用戶數(shù)等度量，都可以在時間上累加。表述這些度量普通帶

6、上一個時間區(qū)間的定語，例如8月份的通話費用、9月新增用戶數(shù)等等。普通OLAP工具對這兩種度量都是支持的，例如Cognos在度量選項中可以指定是求和還是求期末值或是期初值，可以求和的就是時期值，對于求期末、期初的度量，普通是時點值要運用此特性，必需明確指明一個時間維，可見這兩種值和時間是嚴密聯(lián)絡(luò)的。昨天寫的數(shù)據(jù)倉庫中的數(shù)據(jù)形狀中，提到ODS有兩種形狀數(shù)據(jù)，一種是事件型，一種為快照型?？煺招蛿?shù)據(jù)記錄當前時間點的形狀值，事件型數(shù)據(jù)記錄特定事件發(fā)生。這兩種不同形狀對于抽取增量有很大協(xié)助 。但是其他的分類方法，這是kimball在他的文章中提出來的，請看Fundamental Grain。此文中提出三種

7、現(xiàn)實表的數(shù)據(jù)形狀分類，我覺得比我的分類更合理一些。由于事件型和快照型這兩種分類主要是從增量抽取角度思索的，例如原來思索月帳單這種表應(yīng)該屬于哪一類時，有點模糊，便將至歸結(jié)于事件型數(shù)據(jù)中，以為每個用戶開帳是一種事件，不免有些牽強。因此，重新思索數(shù)據(jù)形狀在時間上的分類，可以分成三種。事件型(Transaction Grain)、周期快照型(Piriodic Snapshot Grain)和累積快照型(Accumulating Snapshot Grain)。其中，事件型和我提到的事件型是差不多的意思，它記錄的每一次事件的發(fā)生，包括發(fā)生的環(huán)境維度和發(fā)生的值度量，例如通話詳單表，日志表等。而我的快照型表

8、還需求細分成周期快照和累積快照，而原來我將周期快照歸于事件型。由于周期快照反響的是一段時間周期內(nèi)發(fā)生值，例如月底出帳，月帳單記錄每個用戶的消費金額，就是上月通話費用的匯總。由于這種數(shù)據(jù)帶有明顯的周期性，例如每月，假設(shè)將它和事件型數(shù)據(jù)混為一談有些說不過去。但是從運用周期快照型數(shù)據(jù)來說，他的特點和事件型數(shù)據(jù)有非常類似，例如都記錄的是發(fā)生值，再如它們提交后普通都不會再做update操作。而累積快照型和我的快照型相對應(yīng)，它記錄是一個時間點上實體的形狀，這種數(shù)據(jù)從實體的生命周期一開場不斷更新到生命終了，例如用戶表中，從用戶創(chuàng)建開場，用戶開機、停機、形狀改動都會直接更新這些數(shù)據(jù)，最后，用戶銷戶了，更新他的有效標志，從此這條記錄根本不會再修正了。再結(jié)合一開場提到的時點值、時期值，前者記錄某一時辰形狀，普通都在累積快照型表中，當然也有能夠在周期快照型表中，表示是期末那一刻的形狀值，例如充值余額可以記錄在用戶表中同時也能夠會在月帳單表中出現(xiàn)。而時點值普通在事件型數(shù)據(jù)中是不會出現(xiàn)的。時期值普通存在于事