【轉載】把握資料倉儲中的"鍵"

目前，在資料倉儲邏輯模型設計上主要有實體關係建模和維度建模兩種方法，其中維度建模，即星型模式設計在國內資料倉儲專案工程實踐中應用更為廣泛。星型結構模型典型的形式是一個主題由中間的一個大表和圍繞在其周圍的一組小表組成。中間的大表稱為“事實表”，儲存數值型度量指標和連線到維度表的外來鍵；外圍的小表稱為“維度表”，儲存用於描述事物的文字屬性資訊及連線到事實表的主鍵。
    這一結構體現了兩種關係，一是維度表與事實表之間的一對多關係；二是通過事實表體現出的維度表之間相互的多對多關係。實踐證明，這種簡單而對稱的結構能夠表達各種複雜的業務邏輯，並有助於終端使用者的訪問。
    主外來鍵關係是維度建模的重要基礎，那麼怎樣決定資料倉儲中的主鍵呢？至少有三個方面因素必須考慮：第一，主鍵應該是穩定的；第二，主鍵應該能夠標識出到相關源系統的對映；第三，主鍵實際是一種約束，必須考慮載入和查詢的效率。

維度表中的鍵
    維度表一般由主鍵、分類層次和屬性描述組成。對於主鍵的選擇一般存在兩種觀點：一種是採用自然鍵（Natural Key），即操作型系統使用的具有一定內建含義的識別符號；另一種是採用代理鍵（Surrogate Key），即由裝載程式或者資料庫系統所賦予的一個數值，該數值按順序分配，沒有內建含義但可以作為一行維度資訊的惟一標識。
    根據筆者的專案經驗，推薦採納第二種觀點，主要原因是代理鍵簡化了事實表與維度表的主外來鍵關係。維度表作為使用者進入事實表的入口，承擔著記錄觀察視角的歷史變化軌跡的任務。如果以自然鍵、時間標籤，或許還有機構程式碼聯合起來也可以在邏輯上惟一標識出一個產品，但如果作為主鍵，那就意味著在事實表中也要加入同樣的外來鍵資訊，而事實表記錄行數是巨大的，在多個維度上重複這樣的做法會使事實表由於列寬過於膨脹而迅速崩潰。
    最好的辦法是採用代理鍵，即選擇一個只佔用4個位元組就可以處理20億個正整數的列作為維度表的主鍵，這樣既解決了事實表儲存空間的浪費問題，又維持了自身的獨立和穩定。
    另一個好處是，代理鍵可以作為資料倉儲系統與源系統之間的緩衝。隨著企業的發展，生產系統中的產品名稱、產品分類、組織機構幾乎不可避免地會發生調整，有的時候甚至自然鍵本身也會發生變化。就像身份證號碼都從15位變到18位一樣，在歷史的長河中一般認為不可能的事其實都有可能發生。如果採用了代理鍵，這些變化會被遮蔽在維度表內，需要記錄歷史軌跡的就貼上時間標籤，不需要的就直接更新掉，變化的過程不會對事實表產生任何衝擊。維持業務系統的自然鍵與維度表代理鍵的對照關係的目的也在於此，既保留了業務系統到資料倉儲系統的對映，又提高了資料倉儲系統的抗震性。

事實表中的鍵
    事實表中包含度量指標和連線到相關維度表的一組外來鍵，這組外來鍵的聯合惟一標識了一行事實資料。然而，事實表在維度建模過程中是如此重要，以致於我們必須進一步認識它。這裡的關鍵是對邏輯主鍵和物理主鍵的認識。
    邏輯主鍵是構成事實表的所有維度外來鍵的聯合。由於事實表存在多種型別，從粒度上看有原子級和彙總級；從度量的可加性上看有完全可加、半可加和不可加型別。在資料倉儲邏輯模型設計階段，使用邏輯主鍵是妥當的，這是一個具有很好包容性和概括性的定義。物理主鍵是在具體的專案場景中能夠惟一標識事實表中一行資料的列的聯合。在資料倉儲物理模型設計階段，一般會採用物理主鍵的概念。邏輯主鍵有時是和物理主鍵一致的，但並不總是這樣。
    物理模型中保單事實表的物理主鍵已經確定，那麼是否意味著一定要在事實表上真正建立起聯合主鍵？這個問題目前在業界存在著廣泛的爭議。筆者認為應該視情況而定，如果事實表很大，每天的增量資訊很多，那麼這個聯合主鍵可以不做顯式的宣告，即不在保單事實表上建立主鍵，物理主鍵只用於ETL及資料核查過程。
    因為，在OLTP系統環境中，資料的完整性通常靠兩種方式來保證，一是應用程式的邏輯保證，另一個是資料庫結構自身的約束機制。這兩種方式相互補充，而資料倉儲環境中的情況則完全不同，資料倉儲中資料的完整性更依賴於應用程式，也就是ETL系統的保證。
    首先，ETL系統執行時間雖然很長，但其結構是簡單的，重複地抓取、清洗、轉換、載入動作。與其相比，OLTP系統可能同時在一張表上執行大量並行業務操作；其次，事實表的惟一入口是維度表，按照維度建模的思路實現ETL程式，只可能產生不準確的維度資訊，但不可能在事實表中產生重複記錄；第三，與OLTP系統相比，資料倉儲系統沒有互動式人機錄入介面，不存在“人為”錯誤。
    因此，當裝載時間窗是一個必須考慮的問題時，建議從資料倉儲環境中刪除一些不必要的約束，其中包括主鍵約束、外來鍵約束和惟一索引約束。這些約束規則可以在外部得以實施。