ETL中的問題
書中提到了設計數據倉庫時會遇到的以下問題
- 列
- 相同數據不同名字
- 不同數據相同名字
- 行
- 有些系統缺少相應數據
- 值
- 數據類型不同
- 單位不同
- 枚舉不同
但我認爲這些問題不算問題,應爲DW的設計應該是與DW無關的,是更穩定不變的,是更接近公司運營本質的,頂多是受到DM的影響.即使這些問題算問題,也是ETL時遇到的問題,並且這些問題都比較容易解決,比較難解決的在我看來是DB的數據表示與業務不一致,DB的數據存儲僅僅滿足的頁面呈現的要求而沒有呈現業務的本質,是的,我說的就是關於ID的問題.數據庫中的一行記錄和現實業務中的一個實體/操作並不是一一對應關係.這既有業務變形的問題(業務系統沒有提供該操作從而操作員使用一些變通辦法來實現)也有歷史數據丟棄的問題(數據庫的數據失去了聯繫性,使用delete+insert來代替update操作)對於前一種操作會導致數據庫的一行記錄對應多個業務實體(這個是歷史上的先後,也就是一個id在不同時間對應不同業務實體,例如部門重組,新部門是有新的id還是使用某一個歷史部門的id),後一種操作會導致一個業務實體有多條記錄,這個要求業務本身有唯一Number來追蹤歷史變化.
建模
非業務考量
在DW建模時,它綜合了各個DB中的數據並對那些OneToOne關係進行合併,那麼就是建一個字段是DB字段合集的表就可以了麼?如果考慮字段本身的更新頻率,可以大致把字段分爲很少更改,不時更改,經常更改等幾類,並且對於不同的字段有可能需要跟蹤記錄變化.
企業模型
按照文中企業模型的定義,企業模型是操作型數據模型和數據倉庫數據模型的基礎,只是和前者更接近.當轉換爲DW模型時需要加上一些時間相關的字段
拼圖
站在整個企業的角度來看,不同的業務系統的模型如同盲人摸象,都只是看到了自己相關的一個切面,作爲ERD&DIS會綜合各個業務系統視角.但是這個時候就又出現了一個問題,我覺得這是又一個DW承諾解決但實際上沒有解決的問題:面向未來的演進.DW的模型可以來自於兩個方面,1對現有系統的綜合,2對企業本質的體現.對於第一個當然簡單些,但是這樣DW也會隨着DB的變化,特別是新系統(而不是新業務)而變化,如果DW是跟隨企業的本質,就不會有這個問題,但是企業本質又如何而來呢?這個時候又進入了經典的總分模型,先是對整個系統有一個大的規劃,然後各個模塊分別演進,最後神奇的自動對接.
# 概要記錄
對於沒必要做詳細歷史記錄的數據,可以形成概要記錄.從這個地方也可以看到一點就是DW更關注數字,後面再對它們進行運算而不是着力於分析字段間的關係
- Sum
- Count
- Average
- Max
- Min
- First
- Last
Feedback
前面都是提到數據從業務系統到DW的流向,那麼會有DW到業務系統的情況麼?有以下兩種情況
- 簡單查詢
這和DW的其他查詢沒有區別,只是入口在業務系統而已,所以它有DW的所有缺點:慢 - 分析結果
第二種情況看上去更有價值一點.書中舉得是一個定價的例子,定價同時要參考現在庫存(來自業務系統)和歷史情況(來自DW).另一個例子是個性化推薦.從這些例子上來看,這已經不是一個爲管理層準備的DSS系統,而是一個面向一線人員的數據分析系統.
關係模型 vs 星形連接
文中認爲關係模型給人一種假象,即使圖中各個實體是對等的,實際上不是,參見下圖,所以要給數據量多的實體也額外關注
所以建出來表是這樣的
並且事實表和維表的字段類型也有自己的特色,一般事實表大多是數字而維表是字符
