數據倉庫的需求只有在已經裝載了部分數據並開始使用時才能弄清楚。數據倉庫是在啟發方式下建造的，

一個階段的開發完全依賴於上一階段獲得的結果。

1. 載入一部分數據供 DSS 分析員使用和查看

2. 根據最終用戶的反饋，修改數據和/或添加其他數據

3. 建立數據倉庫的另一個部分，並返回到一

上述反饋過程貫穿數據倉庫的整個開發生命周期之中。

從操作數據開始

如何將數據放置在數據倉庫中？

將未經集成的數據載入到數據倉庫是一個極端嚴重的錯誤。

數據缺乏集成是抽取程序員不得不面對的一場噩夢，為了從操作型環境中適當的取出數據，必須對無數細節編程進行

一致性處理。

數據缺乏集成的情況

1. 數據編碼不一致

2. 字段語義不一致

3. 原有數據在不同的 DBMS 下可能以多種不同的格式存儲

數據倉庫系統中數據轉換工作的難點包括

1. 對現有歷史系統的集成

2. 訪問現有系統數據的效率，也就是判斷現有系統的程序如何知道一個文件已經被掃描過

3. 數據從操作型環境到數據倉庫時要經歷的時基變化（什麽是時基？）

4. 對數據倉庫中已有的及要傳入的數據規模進行管理（主要涉及到壓縮）

從操作型環境到數據倉庫有 3 種裝載工作要做

1. 裝載檔案數據

2. 裝載在操作型系統中的現有數據

3. 將上次數據倉庫刷新依賴在操作型環境中不斷發生的變化從操作型環境中裝載到數據倉庫中

第 3種情況，即當操作型環境變化時，不斷的將變化數據裝載到倉庫中是最困難的。當數據倉庫刷新時，為了限制操作型

數據量通常可以采用 5 種技術

1. 掃描在操作型環境中那些被打上時間戳的數據

2. 掃描增量文件

3. 對作為事務處理的副產品產生的日誌文件或者審計文件進行掃描

4. 控制掃描數據量

5. 將映像文件進行比較，迫不得已時才使用

對於新零售來說，個人認為使用方法 1 就可以應對大部分情況了。

數據倉庫和數據模型

企業數據模型應用到操作型系統時，需要的改動非常少。但將企業模型用到數據倉庫中則需要相當多的改動。

1. 去除純粹用於操作型環境的數據

2. 關鍵字中加入時間元素

3. 將導出的數據加到企業數據模型中

4. 在數據倉庫中將操作型系統中的數據關系轉變為 “人工關系”

5. 穩定性分析，是指根據各個數據是否經常變化的特性將這些屬性分組。

　　將很少變化，不時變化，經常變化的各分成一組。

穩定性分析的最後結果就是建立具有相似特性的數據分組

企業數據模型是操作型數據模型與數據倉庫數據模型的共同起源。

數據建模分成 3 個層次：

1. 高層建模（實體關系圖 ERD）

2. 中間層建模（數據集或者 DIS）

3. 底層建模（物理模型）

數據模型與叠代式開發

任何情況下，數據倉庫都應當以叠代的方式進行建造。

叠代式開發是說首先建造數據倉庫的一部分，然後再建造另一部分，如此繼續。

這麽做的重要原因如下

• 業界成功的記錄強烈的建議這麽做
• 最終用戶在第一遍叠代開發完成前不能清晰的提出需求
• 只有實際結果切實並且明確時，管理部門才會做出充分的承諾
• 必須能很快的見到結果

就像拼積木一樣，一遍一遍的開發，就像開發出一個個積木，後一個積木是在前一個積木的基礎上構建的，

這樣叠代循環，最終會產生一個內聚的，高度和諧的整體。

元數據

元數據是指數據的數據。

元數據會對以下各項進行記錄

• 程序員所知的數據結構
• DSS 分析員所知的數據結構
• 數據倉庫的源數據
• 數據進入數據倉庫時進行的轉換
• 數據模型
• 數據模型和數據倉庫的關系
• 抽取數據的歷史記錄

參照表管理

數據倉庫中既包含不停運行公司日常事務的一般大型數據庫，還包括一類常被忽略的數據：參照數據。

參照數據應該同數據倉庫的其他部分一樣加入時間元素以反映他們的時變特征。

數據周期——時間間隔

是指操作型環境中的數據發生改變起，到這個變化反映到數據倉庫中所用的時間。

也就是指 DBMS 中的數據變化最快何時能反映到數據倉庫中。

采用時間間隔的原因如下

1. 操作型環境與數據倉庫間結合的越緊密，所需的技術就越復雜。24 小時時間間隔以現有技術容易實現，而 12小時， 6 小時等則一級比一級難

2. 在轉入數據倉庫前，數據能達到穩定。數據在進入數據倉庫前，仍然可以在操作型環境中進行調整。

　　而如果數據被馬上送到數據倉庫中，一旦發現必須對這些數據進行調整，那麽調整就必須同時在操作

型環境和數據倉庫中進行

待續... 3.8 轉換和集成的復雜性 p70

數據倉庫之設計數據倉庫—讀書筆記