再說Change Log之前，我們有必要了解它的母體ODS（BI 7 之後稱為DSO）。從外界看來，ODS就像一個普通的Table，而我們常常通路ODS也是通過讀取他的Active Data Table來擷取ODS的資料。因為我們單純隻是了解Data在ODS中的存放結構，是以不會去探讨ODS的其他特性。
上面我們提到了一個Active Data Table，事實上ODS的相關的資料會存放在三個Table中，分别是New Data Table 存放導入ODS且尚未激活的資料，Active Data table 存放激活後的ODS的資料，Change Log Table存放激活過程中産生的資料變動。這個三個表的命名規則為：
New Data Table: /BIC/A*40 （系統描述為 Active Records）
Active Data Table: /BIC/A*00 （系統描述為Update）
Change Log Table: 流水号 （系統描述為Transfer Structure Application 8*）
其中*表示具體的ODS名稱。
那麼怎麼去了解這個三個表的關系呢。
首先我們假設目前某個ODS，暫且名為ZRL_001,它的結構為：
現在我們來進行幾次資料的加載，從中我們可以看到幾個表的變化過程。
Step 1：導入一批資料
FISCPER MATERIAL AMOUNT CURRENCY
2010001 MAT001 100 RMB
2010001 MAT002 100 RMB
2010001 MAT003 100 RMB
各個表的資料情況：
/BIC/AZRL_O0140：New Data Table
其他兩個表都暫時沒有資料。
然後我們把這批資料激活。
這時候，New Data Table的資料被清空了，而其他兩個表的資料如下：
/BIC/AZRL_O0100： Active Data Table
/BIC/B0004352000：Change Log Table
從上面幾個表的變化，我們暫時隻能知道，資料激活後會清空New Data Table，并加載到其他兩個表，那麼加載的邏輯是什麼?既然名中有個Log，自然是有記錄的意思，那麼我們就加載如下記錄，看看資料怎麼變？
FISCPER MATERIAL AMOUNT CURRENCY
2010001 MAT001 100 RMB
2010001 MAT002 200 RMB
2010001 MAT003 300 RMB
在尚未加載之前，我們有必要預測一下未來，這也是一個程式員良好的思維習慣。我們知道這個ODS的關鍵字有時間、物料号，是以按照ODS的特性，它存放某筆記錄時，隻能存放唯一一條相同時間且相同物料号的資料行。是以單我們把最新的資料加載後，很明顯，新舊三筆的關鍵字都是一一對應的，也就是說最終記錄也就是隻有三筆。
/BIC/AZRL_O0140：New Data Table
激活後，New Data Table清空，我們再看看其他兩個表的情況，
/BIC/AZRL_O0100： Active Data Table
/BIC/B0004352000：Change Log Table
Active Data Table的表的結果我們可以很好了解，因為它儲存的就是最後的記錄，我們這個認認真真看看Change Log發生了什麼。
1. 資料有原來的3行變成現在的7行
2. 我們上傳的都是正數金額，但是出現了兩行記錄的金額是負數
3. 最後一列的資料是我們沒有關心的，但是現在看上去很礙眼，也很神奇
首先看看從3行變成7行，都增加了哪些記錄數。從Request這個一列我們可以很情況的看到，新增的是哪4行。從關鍵字方面考慮，它們都是成對出現的，日期因為都是一樣我們就不管它。是以是料号MAT002和MAT003個2筆記錄，因為清晰起見，我把MAT002的3行記錄先拿出來看看。
我們應該知道，記錄先後是沒有差別的，是以大家不要被它們的先後順序迷惑。在第二次上次過程我們把MAT002的金額改成了200，而之前的數字是100，稍微停頓思考之後，我們會發現系統在給我們上國小計算課，因為100 + 200 + （-100） = 200而這個數字就是我們最後的值。是以，Change Log Table為我們展示的是一個簡單而實用的補零的過程。以上隻是我們自以為是推斷，那麼SAP BW是不是就是和我們不謀而合呢？大家回到命名規則說明的那段，系統是這樣描述Change Log Table的“Transfer Structure Application 8*”（如果不知道什麼是Transfer Structure，那就先找其他地方查查）。原來它是為作為一個資料源準備的，是以我們不難了解，為什麼要補零。因為它導入到其它的地方的資料都是從Change Log Table來的（這裡其實有一個前提，那就是導入到其他地方用的是delta機制），假設原來的100已經在Cube中了，現在要變成200，它不是先做一個計算，200-100 = 100，然後加載一個100進去，當然這樣做我覺得也是行的通的，因為從數值上來講，就是這樣，但是為什麼不這樣做，因為沒找到官方的書面說明（口頭就更談不上了），我們不知道，我們隻能順着結果去倒推來由。
開始的三點疑問，大家應該已經知道一二了，是以在來看看三。RECORDMODE欄位放的到底是什麼東西。
看到上述幫助，以及之前我們對的觀察，可以發現，它是對資料的狀态描述。
第一次出現，是“N”，第二次出現時為空代表最新資料，“X”代表之前的資料。這個描述有什麼用？當删除Request的時候，ODS要傳回到之前的值的時候，那麼它可以通過這個RECORDMODE知道，之前之後的資料分别是什麼，是以可以删的很堅決。如果愛熱鬧，可能還會問其他幾個值是什麼意思，抱歉，我們以後再說。
到目前為止，大家對Change Log Table應該有一定了解了。我們來說另外一個話題，删除Change Log Data。
進入ODS的Management界面從菜單Environment中可以看到一個“Delete Change Log Data”子菜單。大家可能會想，上面說的把Change Log Table頂了天，這個既然可以删除裡面的資料。沒搞錯？沒錯。那麼到底是怎麼回事？為什麼可以删除？有什麼局限？
為什麼要删除？從前面我們的介紹，我們看到Active Data Table放了三筆記錄，而Change Log Table卻有七筆，因為它把資料的變化過程以及最新的資料都記錄下來了，是以保守估計，它一定等于或多餘Active Data Table的記錄行。是以從資料存儲方面來講，它的空間占有大小，不容忽視。而實際上，我們使用ODS的過程中，也沒有去用Change Log Table，是以想當然的想：應該要删，應該可以删。
說它沒用到，是因為它的使用過程對我們來講比較透明，如果真的沒用到BW也不會多這個東西，是以一定有用，也一定要用。怎麼用？如果你怎麼問的話，說明沒有好好看我之前的介紹。1. 它的補零用于後面的資料更新 2. 它的變動log，可以用于Request删除後的資料回退。
當然它真的是可以删的，前提：1.我永遠不用删Request 2.補零的作用已經完成。
得出以上結論的原因是：1. 如果你要删Request，那麼資料無法正确的回退，那麼Active Data Table放的就是一個錯誤的值；2. 當把資料往其它地方導入用Change Log的資料，而它實際上已經被你删除，自然倒得的是錯誤資料。
是以我們再把删除Change Log Table的前提具體一點：1. 以後不會去删除已經删除在Change Log Table中對應Request的Request ； 2. 到删除點為止，ODS要導入其他地方的資料已全部導完，新的Request進來，會産生新的Change Log，而這些Change Log是彼此獨立的。這時候你可以大膽的删了。