數據倉庫生命周期工具箱目錄

Ⅰ 數據歸檔的優化數據倉庫基礎設施

自從二十世紀五十年代後期計算機的首次使用以來，數據和信息的世界一直在不斷的發展。隨著時間的過去，很明顯數據像許多實體一樣都有生命周期，並且特定於生命周期中的每個時點、不同的一組特徵、存儲和訪問需求。數據倉庫的概念由業務需求演變而來，業務需要在不同數據源之間基於其生命周期內的不同點進行可靠、統一和集成的數據報告和分析。
就總的感覺而言，數據倉庫只是組織以電子方式存儲數據的一個資料庫；重要的是必須意識到，任何倉庫都會受限於在倉庫中查找和訪問項目以及將項目移入和移出倉庫的流程。對於數據而言，數據倉庫系統的主要組成部分包括有選擇地存儲數據的能力、檢索和分析數據的能力（不管數據在哪裡），以及管理數據字典的能力。為了有效操作數據倉庫，組織需要了解數據倉庫中存儲的信息在數據生命周期內的不同點存在的固有差異。
隨著數據變舊：
1. 訪問數據的可能性會降低。簡言之，數據變得越舊，它的使用頻率就越低。
2. 數據結構會改變。隨著軟體逐漸發展得更加復雜以更有效率地處理更多數據，資料庫體系架構必然也要改變。透過一系列利用越來越強大的硬體和軟體技術的軟體版本穩定發布可看到這一點。
3. 存儲的數據量呈指數方式增長。受行業及政府法規的制約，數據必須存儲和保持可訪問數年之久。然後只有第一年的數據價值被有效利用，維護歷史數據可能輕易地讓數據存儲激增到比當前生產資料庫多20倍。
實施強大存檔技術將為數據倉庫提供最佳的和經濟高效的存檔基礎設施：
1. 在多種格式之間保持數據完整性
2. 實現方便的按需訪問存檔數據
3. 提供通用連接，並與多種存檔平台集成以確保卓越和經濟高效的可擴展性和性能
4. 高效存儲存檔數據以節約存儲容量，同時促進快速檢索數據

Ⅱ 資料庫系統原理的作品目錄

第1篇基礎篇
第1章資料庫系統概述
1.1資料庫、資料庫管理系統和資料庫系統
1.2資料庫系統的特點與功能
1.2.1信息完整、功能通用
1.2.2程序與數據獨立
1.2.3數據抽象
1.2.4支持數據的不同視圖
1.2.5控制數據冗餘
1.2.6支持數據共享
1.2.7限制非授權的存取
1.2.8提供多種用戶界面
1.2.9表示數據之間的復雜聯系
1.2.10完整性約束
1.2.11數據恢復
1.3資料庫系統的用戶
1.3.1資料庫管理員
1.3.2資料庫設計者
1.3.3最終用戶
1.3.4系統分析員和應用程序員
1.3.5與資料庫系統有關的其他人員
1.4數據抽象
1.4.1數據抽象與資料庫的三種模式
1.4.2數據獨立性
1.5數據模型
1.5.1基於對象的數據模型
1.5.2基於記錄的數據模型
1.5.3物理數據模型
1.5.4資料庫模式和資料庫實例
1.6資料庫語言
1.7資料庫管理系統的結構
1.8資料庫技術的發展
1.8.1第一代資料庫系統
1.8.2第二代資料庫系統
1.8.3第三代資料庫系統
1.8.4Internet時代的資料庫技術
習題1
本章參考文獻
第2章關系資料庫系統
2.1關系數據模型
2.1.1數據結構
2.1.2完整性約束規則
2.2關系運算
2.2.1關系代數
2.2.2元組關系演算
2.2.3域關系演算
2.3關系運算的安全性
2.4關系代數、元組關系演算、域關系演算的等價性
2.5關系資料庫查詢語言
2.5.1ISBL語言
2.5.2QUEL語言
2.5.3QBE語言
2.6標准關系資料庫查詢語言SQL
2.6.1數據定義
2.6.2數據查詢
2.6.3數據更新
2.6.4視圖定義
2.6.5安全性機制
2.6.6嵌入式SQL語言
習題2
本章參考文獻
第3章資料庫的安全性與完整性
3.1安全性
3.1.1資料庫安全性與資料庫管理員
3.1.2系統保護機制
3.1.3授權機制
3.1.4統計資料庫的安全性
3.1.5資料庫加密技術
3.1.6資料庫操作跟蹤審計
3.2完整性
3.2.1完整性約束的類型
3.2.2顯式約束的定義
3.2.3完整性約束的驗證
習題3
本章參考文獻
第2篇設計篇
第4章資料庫設計概述與需求分析
4.1資料庫的設計概述
4.1.1資料庫的設計問題
4.1.2資料庫的生命周期
4.1.3資料庫的設計過程
4.2需求分析
4.2.1應用領域的調查分析
4.2.2定義資料庫系統支持的信息與應用
4.2.3定義資料庫操作任務
4.2.4定義數據項
4.2.5預測現行系統的未來改變
習題4
本章參考文獻
第5章概念資料庫設計
5.1概述
5.2實體聯系模型
5.2.1實體和屬性
5.2.2實體型、鍵屬性和屬性的值域
5.2.3資料庫實例
5.2.4實體間的聯系
5.2.5弱實體
5.2.6實體聯系圖
5.3擴展的實體聯系模型
5.3.1子類、超類、演繹和歸納
5.3.2演繹和歸納的性質
5.3.3范疇與范疇化
5.3.4EER圖
5.4概念設計的方法與策略
5.4.1概念設計的方法
5.4.2概念設計的策略
5.5視圖綜合設計方法
5.5.1局部概念模式設計
5.5.2全局概念模式合成
5.6事務的設計
習題5
本章參考文獻
第6章邏輯資料庫設計
6.1形成初始關系資料庫模式
6.2關系資料庫設計理論
6.2.1問題的提出
6.2.2函數依賴
6.2.3數據依賴的公理系統
6.2.4關系模式的規范形式
6.2.5多值依賴與第四範式
6.2.6連接依賴與第五範式
6.3關系模式規范化方法
6.3.1無損連接性和函數依賴保持性
6.3.2關系模式分解演算法
6.4關系模式的優化
6.5完整性和安全性約束的定義
6.6邏輯資料庫的性能估計
習題6
本章參考文獻
第7章物理資料庫設計
7.1影響物理資料庫設計的因素分析
7.2為關系模式選擇存取方法
7.2.1索引存取方法的選擇
7.2.2Hash存取方法的選擇
7.2.3聚集存取方法的選擇
7.3物理存儲結構的設計
習題7
本章參考文獻
第3篇實現篇
第8章物理存儲結構
8.1資料庫存儲設備
8.1.1磁碟存儲器
8.1.2磁碟緩沖處理技術
8.1.3磁碟的調度策略
8.1.4磁碟容錯技術
8.1.5第三級存儲器
8.2文件和文件記錄
8.3無序文件
8.4有序文件
8.5Hash文件
8.5.1簡單Hash方法
8.5.2動態Hash方法
8.5.3可擴展的Hash方法
8.6索引文件
8.6.1主索引
8.6.2聚集索引
8.6.3輔助索引
8.6.4多級索引
8.7B樹與B+樹索引結構
8.7.1索引樹結構
8.7.2B樹索引結構
8.7.3B+樹索引結構
8.8多維索引
8.8.1柵格文件
8.8.2KD樹
8.8.3R樹
8.8.4點陣圖索引
習題8
本章參考文獻
第9章資料庫管理系統的數據字典
9.1關系資料庫管理系統的數據字典
9.2資料庫管理系統軟體模塊對數據字典的存取
習題9
第10章關系代數操作的實現演算法
10.1查詢處理的過程
10.2選擇操作的實現演算法
10.3笛卡兒積的實現演算法
10.4連接操作的實現演算法
10.5投影操作的實現演算法
10.6集合的並、交、差的實現演算法
習題10
本章參考文獻
第11章查詢優化技術
11.1問題的提出
11.2啟發式關系代數優化方法
11.2.1關系代數等價變換規律
11.2.2啟發式代數優化規則
11.2.3啟發式代數優化演算法
11.3啟發式關系演算優化方法
11.3.1多重自然連接的優化處理
11.3.2查詢的超圖表示
11.3.3超圖消解演算法
11.4基於復雜性估計的查詢優化方法
11.5語義查詢優化方法
11.6查詢優化的遺傳演算法
習題11
本章參考文獻
第12章事務處理技術之一：並發控制技術
12.1並發控制概述
12.1.1單用戶和多用戶資料庫系統
12.1.2並發控制的必要性
12.2事務模型
12.2.1事務中的讀寫操作
12.2.2事務的原子性
12.2.3事務的狀態
12.2.4事務的性質
12.3事務調度與可串列性
12.3.1事務的調度
12.3.2調度的可串列性
12.3.3調度的可串列性測試
12.4基於鎖的並發控制協議
12.4.1鎖的概念
12.4.2兩段鎖協議
12.4.3資料庫圖協議
12.5時間印協議
12.6其他並發控制技術
12.6.1實現並發控制的驗證技術
12.6.2多版本並發控制技術
12.6.3多種並發控制的粒度
12.7插入和刪除操作
12.7.1刪除操作對並發控制的影響
12.7.2插入操作對並發控制的影響
12.7.3插入元組現象
習題12
本章參考文獻
第13章事務處理技術之二：資料庫恢復技術
13.1資料庫恢復的必要性
13.2使用日誌的資料庫恢復技術
13.2.1資料庫系統日誌
13.2.2推遲更新技術
13.2.3即時更新技術
13.3緩沖技術
13.3.1日誌緩沖技術
13.3.2資料庫緩沖技術
13.4檢測點
13.5影子頁面技術
13.6永久存儲器中信息丟失後的資料庫恢復
13.7資料庫恢復與並發控制技術的結合
13.7.1事務的嵌套撤銷
13.7.2調度的可恢復性
習題13
本章參考文獻
第14章其他事務處理技術
14.1死鎖處理
14.1.1預防死鎖協議
14.1.2死鎖的檢測和恢復技術
14.2高性能事務處理系統
14.2.1主存資料庫
14.2.2事務的成批提交技術
14.3長事務處理技術
14.3.1可串列性概念不適於長事務處理
14.3.2嵌套事務技術
14.3.3補救事務技術
14.3.4實時資料庫系統
習題14
本章參考文獻
第4篇專題篇
第15章新一代資料庫系統及應用
15.1新一代資料庫應用
15.1.1工程設計與製造
15.1.2辦公自動化系統
15.1.3決策支持系統
15.1.4科學與統計數據管理
15.1.5異構多資料庫應用
15.1.6人工智慧應用
15.1.7其他的新一代資料庫應用
15.2新一代資料庫系統的特點和熱點問題
15.3新一代資料庫系統
習題15
本章參考文獻
第16章擴展的關系資料庫系統
16.1基於邏輯的關系資料庫系統
16.1.1邏輯數據模型
16.1.2查詢的計算策略
16.1.3查詢結構
16.1.4否定
16.1.5非遞歸查詢
16.1.6遞歸查詢
16.2基於嵌套關系模型的關系資料庫系統
16.2.1文檔檢索實例
16.2.2嵌套關系模式的定義
16，2.3嵌套關系查詢語言
16.3專家資料庫系統
習題16
本章參考文獻
第17章面向對象與對象關系資料庫系統
17.1面向對象程序設計方法
17.2面向對象數據模型
17.2.1對象的結構
17.2.2類和類層次
17.2.3多重繼承性
17.2.4對象的標識
17.2.5對象的嵌套
17.3面向對象資料庫的物理組織
17.4面向對象資料庫的查詢
17.5面向對象資料庫模式的修改
習題17
本章參考文獻
第18章分布式資料庫系統
18.1概述
18.1.1計算機網路
18.1.2分布式資料庫和分布式資料庫系統
18.1.3分布式資料庫的結構
18.2分布式資料庫設計
18.2.1數據的重復存儲
18.2.2數據的分片存儲
18.2.3數據的組合存儲
18.2.4命名和局部自治性
18.3分布式資料庫查詢處理
18.3.1分布式資料庫管理系統概述
18.3.2分布式查詢處理
18.4分布式資料庫系統中的事務處理
18.4.1分布式事務處理器的結構
18.4.2分布式系統恢復技術
18.4.3分布式並發控制技術
18.4.4分布式死鎖處理技術
習題18
本章參考文獻
第19章並行資料庫技術
19.1支持並行資料庫的並行結構
19.2關系資料庫系統的固有並行性
19.3實現關系查詢並行化的數據流圖方法
19.4並行資料庫的物理組織
19.4.1一維數據劃分方法
19.4.2多維數據劃分方法
19.4.3傳統物理存儲結構的並行化
19.5新的並行數據操作演算法
19，5.1基於嵌套循環的並行連接演算法
19.5.2基於Sort-Merge的並行連接演算法
19.5.3基於Hash的並行連接演算法
19.5.4數據分布的均勻性與並行連接演算法
19.5.5數據的初始劃分與並行連接演算法
19.6查詢優化技術
19.6.1基於左線性樹的查詢優化演算法
19.6.2基於右線性樹的查詢優化演算法
19.6.3基於片段式右線性樹的查詢優化演算法
19.6.4基於濃密樹的查詢優化演算法
19.6.5基於操作森林的查詢優化演算法
習題19
本章參考文獻
第5篇新技術篇
第20章資料庫技術的研究進展
20.1影響資料庫技術發展的因素
20.2近10年出現的資料庫新技術和新問題
本章參考文獻
第21章數據倉庫與聯機分析處理技術
21.1什麼是數據倉庫
21.2數據倉庫系統的結構
21.3數據倉庫的多維數據模型
21.3.1多維數據集合
21.3.2多維數據集合的關系表示方法
21.3.3多維數據集合上的操作
21.4數據倉庫系統的實現技術
2l，4.1數據倉庫的存儲方法
21.4.2數據倉庫的索引技術
21.4.3數據操作演算法
21.4.4查詢處理技術
21.5數據倉庫工具
21.6數據倉庫設計
本章參考文獻
第22章數據挖掘技術
22.1數據挖掘的基本概念
22.2關聯規則挖掘方法
22.3分類方法
22.4聚類方法
22.5相似性搜索技術
22.6Web挖掘技術
本章參考文獻
第23章Web信息檢索與Web數據管理技術
23.1Web信息檢索技術
23.1.1搜索引擎技術
23.1.2分類技術
23.1.3元搜索
本節參考文獻
23.2Web數據集成技術
23.2.1數據集成的演變
23.2.2傳統的多資料庫系統技術
23.2.3Web數據集成方法
本節參考文獻
23.3XML資料庫技術
本節參考文獻
第24章其他資料庫新技術
24.1多媒體資料庫技術
本節參考文獻
24.2時態資料庫技術
本節參考文獻
24.3空間資料庫技術
本節參考文獻
24.4移動資料庫技術
本節參考文獻
24.5主動資料庫系統
本節參考文獻
24.6數據流技術
本節參考文獻
……

Ⅲ 什麼是數據倉庫的生命周期

整個數據倉庫從建設到維護過程，是一個持續不斷的過程

Ⅳ 哪位親有《數據倉庫生命周期工具箱》的電子版，求！！謝謝！！

我幫你找到了,來這里抄看看，不知道是不是你需要的。如果下載需要積分,自己注冊一個用戶,就兩分鍾的時間.注冊後就有積分啦。
http://ishare.iask.sina.com.cn/search.php?key=%CA%FD%BE%DD%B2%D6%BF%E2%C9%FA%C3%FC%D6%DC%C6%DA%B9%A4%BE%DF%CF%E4&format=

Ⅳ 網站數據分析:數據倉庫相關的問題(3)

網站數據分析:數據倉庫相關的問題(3)
之前的文章——網站數據分析的一些問題2中主要整理了BI相關的問題，這篇文章主要想整理一些數據倉庫相關的問題。因為最近重新在看一些數據倉庫的資料和書籍，想把之前以及當前遇到的主要問題提出來(博客中有關數據倉庫的相關內容請參閱網站數據倉庫這個目錄)，同時自己也對數據倉庫方面的知識進行下重新的整理和認識，而且很久沒有在博客發新的文章了，不能讓自己過於懶散了。
之前看過Inmon的《構建數據倉庫》和《DW 2.0》，而另外一位數據倉庫大師Kimball的《數據倉庫生命周期工具箱》一直沒有時間閱讀，最近才有時間看完了大部分，就迫不及待想寫點東西了。其實數據倉庫領域普遍認為Inmon和Kimball的理論是對立的，兩者在構建數據倉庫上方向性的差異一直爭論不休，誰也無法說服誰到底哪種方法更好。我的Evernote的筆記裡面不知什麼時候從哪裡摘錄過來了對兩者觀點的概括性描述，非常簡潔明了而一針見血：
Inmon vs Kimball
Kimball – Let everybody build what they want when they want it, we』ll integrate it all when and if we need to. (BOTTOM-UP APPROACH)
Pros: fast to build, quick ROI, nimble
Cons: harder to maintain as an enterprise resource, often rendant, often difficult to integrate data marts
Inmon – Don』t do anything until you』ve designed everything. (TOP-DOWN APPROACH)
Pros: easy to maitain, tightly integrated
Cons: takes way too long to deliver first projects, rigid
其實看了《數據倉庫生命周期工具箱》之後，發現兩者的觀點沒有那麼大的本質性差異，可能隨著數據倉庫的不斷發展，兩者在整體的架構上慢慢趨同。基本上，構建統一的企業級數據倉庫的方向是一致的，而Inmon偏向於從底層的數據集成出發，而Kimball則趨向於從上層的需求角度出發，這可能跟兩者從事的項目和所處的位置有關。
有了上面這段高質量的概括，第一個問題——你更偏向於以何種方式搭建數據倉庫(BOTTOM-UP or TOP-DOWN)，分別有什麼優劣勢?——其實就不用問了，所以下面主要提幾個在實際中可能經常遇到或者需要想清楚的問題：
Q1、數據倉庫的技術解決方案有哪些，這些解決方案的優勢在哪，瓶頸在哪?
隨著數據倉庫的不斷發展和成熟，「大數據」概念的風靡，有越來越多的相關產品出來，最常見的技術解決方案包括hadoop和hive，oracle，mysql的infobright，greenplum及nosql，或者多個結合使用。
其實歸納起來就兩類：一是用傳統RDBMS為主導的資料庫管理數據，oracle、mysql等都是基於傳統的關系型資料庫，優勢就是有更嚴謹的數據結構，關系型資料庫對數據的管理更加規范，數據處理過程中可能出現的非人為誤差極小，而且標準的SQL介面使數據獲取的成本較低，數據的查詢和獲取更加靈活和高效;但劣勢也很明顯，對海量數據的處理和存儲的能力不足，當數據量達到一定程度的時候就會出現明顯的瓶頸。而是基於文本的分布式處理引擎，hadoop、greenplum和nosql都是基於文本數據的處理和存儲，優勢是強大的數據處理能力，分布式的架構支持並行計算，並且具備超強的擴展延伸能力;劣勢就是上層介面不方便，因此Hadoop上層的hive和greenplum上層的postgreSQL都是為了解決數據介面的問題，並且數據的查詢和獲取很難做到實時響應，靈活性不足。
Q2、數據倉庫是否就應該保存聚合數據，細節數據不應該放入數據倉庫?
其實這個問題基本已經達成共識，如果是構建企業級的數據倉庫，那麼對細節數據的集成和存儲是必不可少的，但現實中還是存在很多直接從外部數據源計算聚合之後導入數據倉庫的實例。如果對數據倉庫只是輕量級的應用，僅存放聚合數據也無可厚非，畢竟沒人規定數據倉庫一定要是怎麼樣的，最終的目的無非就是滿足對數據的支持和需求。
但對於企業的長期發展來看，數據倉庫中存放細節數據有兩方面的好處：一方面從技術層面，數據倉庫存儲細節數據可以釋放前台資料庫的查詢壓力，同時對於文本類數據和外部文檔類數據入庫之後管理更加規范，數據倉庫保留歷史和不可變更的特性可以讓信息不被丟失;另一方面就是從數據的使用上，數據倉庫讓數據的獲取和使用更加簡便，集成細節數據讓大量的文本型數據可查詢，可關聯，而面向主題的設計讓數據的展現和分析更有方向性和目的性，而且細節數據是支持數據分析和數據挖掘應用所必不可少的。所以，如果數據倉庫要不斷地催生出更大的價值，細節數據的存儲是必不可少的。
Q3、你會把數據倉庫分為幾層，每層的數據作用是什麼?
沒有標准答案，根據數據倉庫中數據的復雜性和對數據使用的需求程度，數據倉庫可以有不用的層級劃分。
我一般會把數據倉庫劃成三層：最底層的細節數據，管理策略是優化存儲，一般存儲導入的原始數據，便於進行向上的統計匯總，因為數據量較大所以需要優化存儲;中間層是多維模型，管理策略是優化結構和查詢，面向主題的多維模型的設計，需要滿足OLAP和數據查詢的多樣需求，同時保證查詢的便捷性，關鍵在與維表的設計和維度的選擇及組合，事實表需要關注存儲和索引的優化;最上層是展現數據，管理策略是優化效率，一般會存放每天需要展現的匯總報表，或者根據多維模型拼裝的視圖，展現層的數據需要以最快的速度展現出來，一般用於BI平台的Dashboard和報表。
Q4、數據倉庫搭建中最繁雜的事情是什麼，最容易缺失的是哪一塊?
一直覺得數據倉庫的核心不在於數據集成，當然數據集成是數據倉庫實現價值的前提，數據倉庫真正的價值體現在數據的有效應用，數據源於業務反作用於業務。而搭建數據倉庫的核心在於數據倉庫的架構和數據模型的設計，怎麼權衡數據的存儲和數據獲取效率之間的矛盾是數據倉庫管理上的難點，這個難點任何數據倉庫都會存在，而大數據增大了這種權衡中的難度。而數據的集成和數據質量控制是數據倉庫搭建中最繁雜的事情，尤其是數據清洗的過程，我之前也寫過幾篇數據質量控制的文章，但現實中這個過程還要復雜得多，而且為了上層數據產出的准確性和有效性，這項工作又不得不做，而且要做得盡量細致。
搭建數據倉庫中最容易缺失的就是對元數據的管理，很少有數據倉庫團隊具備完整的元數據，當然搭建數據倉庫的工程師本身就是活的元數據，但無論是為了用數據的人還是數據倉庫自身的團隊著想，元數據都不可或缺。一方面元數據為數據需求方提供了完整的數據倉庫使用文檔，幫助他們能自主地快速獲取數據，另一方面數據倉庫團隊成員可以從日常的數據解釋中解脫出來，無論是對後期的不斷迭代更新和維護還是培訓新的員工，都非常有好處，元數據可以讓數據倉庫的應用和維護更加高效。

Ⅵ 軟體設計師考試考點分析與真題詳解的目錄

比特培訓-24期(2017年上)-軟體設計師培訓課件，免費下載

鏈接:https://pan..com/s/1ewtz01HsJL16rSVRzm3-7A

比特培訓-24期(2017年上)-軟體設計師培訓課件|00.2015年-2016年試題及解析|14.多媒體和知識產權(2017年下半年-列印版本)-軟設.doc|13.網路安全(2017年上半年-列印版本-改革版本).docx|12.資料庫列印版本（2017年上格式ok）.docx|11.面向對象設計模式--列印版本(2017年上-Java版本-24期).docx|10.UML分析與設計(2017年上-第24期列印版本).doc|09.面向對象及Java實踐(2017年上--完整列印版本）.docx|08.操作系統原理與技術（列印版本-2017年上-24期）.doc|07.常用演算法設計方法(2017年上-列印版本--鄧少勛--有答案--改革版本).docx|06.計算機體系結構-列印版本(24期-2017年上).docx|05.數據結構(2017年上-列印版本).docx|04.數據流圖與資料庫分析與設計(2017年上-列印版本).doc|03.程序設計語言基礎和編譯原理(2017年上半年-列印版本).doc|02.計算機網路概述列印版(2017年上).docx。

Ⅶ 什麼是 ODS

ODS全稱為Operational Data Store，是用來存儲多個數據源業務數據的系統，其數據用來支持業務流程或者輸入到數據倉庫中進行分析。

是操作型數據存儲，是「面向主題的、集成的、可變的、反映當前數據值的和詳細的數據的集合。ODS是數據倉庫體系結構中的一個可選部分，ODS具備數據倉庫的部分特徵和OLTP系統的部分特徵。

(7)數據倉庫生命周期工具箱目錄擴展閱讀：

ODS的出現：

系統應用集成中一般對各系統中數據分為兩類：操作型數據，有細節化，分散化的特點；決策型數據，有綜合化，集成化的特點。

數據倉庫概念的提出也把數據處理劃分為了操作型處理和分析型處理兩種不同類型，從而建立起了DB－DW的兩層體系結構。但是有很多情況，DB－DW的兩層體系結構並不能涵蓋企業所有的數據處理要求，比如有些實時性決策問題，它要求獲取數據周期不能太長，而且也需要一定程度的匯總。

信息處理的多層次要求導致了一種新的數據環境——DB－DW的中間層ODS（操作型數據存儲）的出現。它像DW一樣是一種面向主題，集成的數據環境，又像操作型DB一樣包含著全局一致的、細節的當前的數據。這樣就構成了DB－ODS－DW的關於企業數據的三層體系結構。

Ⅷ 衛生信息管理系統的圖書目錄

第一章 衛生信息管理系統概論
第一節 信息社會與衛生信息管理
一、信息社會及其基本特徵
二、信息時代的衛生信息管理
第二節 衛生信息管理系統的概念
一、信息與衛生信息
二、系統與信息系統
三、衛生信息管理與衛生信息管理系統
第三節 衛生信息管理系統的類型與結構
一、衛生信息管理系統的類型
二、衛生信息管理系統的結構
第四節 衛生信息管理系統的發展狀況與趨勢
一、衛生信息管理系統的發展狀況
二、衛生信息管理系統的發展趨勢
第二章 衛生信息管理系統平台構建技術
第一節 衛生信息技術與衛生信息平台
一、衛生信息技術
二、衛生信息平台
第二節 計算機網路技術
一、計算機網路概述
二、區域網技術
三、網路互聯技術
四、網際網路技術
五、web服務
第三節 資料庫技術
一、資料庫系統與資料庫應用系統
二、資料庫設計
三、網路資料庫系統
第四節 衛生決策與數據倉庫技術
一、數據倉庫技術
二、衛生決策支持系統
第五節 衛生信息管理系統平台的構建方法
一、區域衛生資源管理平台構建案例
二、醫院決策支持系統構建案例
第三章 衛生信息管理系統開發方法
第一節 衛生信息管理系統的開發方式、原則和策略
一、衛生信息管理系統的開發方式
二、衛生信息管理系統開發的基本原則
三、衛生信息管理系統的開發策略
第二節 結構化系統開發方法
一、結構化系統開發方法的基本思想
二、結構化開發方法遵循的基本原則
三、系統開發生命周期
四、結構化系統開發方法的優缺點
第三節 原型方法
一、原型法基本思想
二、原型化方法的開發過程
三、原型法的開發環境
四、原型法開發系統的特點
五、原型法的優缺點
第四節 面向對象的開發方法
一、面向對象的方法（OO方法）簡介
二、面向對象方法的基本思想
三、面向對象方法的基本概念
四、面向對象方法的開發過程
五、面向對象的分析
六、面向對象的設計
七、面向對象實現和面向對象的語言
八、面向對象方法的特點
第五節 CASE方法和軟體包開發方法
一、CASE方法的基本思想
二、CASE分類
三、CASE與信息系統開發方法的關系
四、CASE體系
五、購置軟體包的選擇
六、使用軟體包對系統開發的過程
七、CASE的發展趨勢
第六節 開發方法案例分析
一、醫院信息系統開發特點
二、醫院信息系統開發方法及程序
三、醫院信息系統的可行性研究
四、醫院信息系統的需求分析
五、醫院信息系統的設計
六、醫院信息系統的實施與測試
十、瞑瞎信息系統的使用和維護
第四章 衛生信息管理系統規劃
第一節 信息系統階段論模型
一、諾蘭模型
二、西諾特模型
三、米切模型
第二節 衛生信息管理系統規劃的內容
一、信息系統規劃的內涵
二、系統規劃的作用
三、信息系統規劃的內容
四、信息系統規劃的步驟
第三節 衛生信息管理系統規劃的主要方法
一、關鍵成功因素法
二、戰略目標集轉化法
三、企業系統規劃法
四、CSB方法
第四節 基於業務流程再造的衛生信息管理系統規劃
一、業務流程
二、業務流程再造
三、業務流程再造的方法、步驟及技術
四、信息系統規劃與業務流程再造
第五節 可行性分析
一、可行性研究的內容
二、可行性分析報告
第五章 衛生信息系統分析
第一節 需求分析
一、需求分析方法
二、詳細調查的范圍
三、醫院信息系統規范性需求分析
第二節 組織結構和功能分析
一、組織結構和功能分析概述
二、衛生信息系統功能分析概念
三、衛生信息系統功能的范疇
第三節 業務流程分析
一、業務流程分析
二、醫院業務流程的重組
第四節 數據流程分析
一、調查數據的匯總分析
二、數據流程分析
第五節 功能/數據分析
一、U/C矩陣及其建立及檢驗
二、子系統的劃分和選擇
三、模塊的劃分
第六章 衛生信息管理系統設計
第一節 系統設計概述
一、系統設計的概念
二、系統設計的原則
三、系統設計的任務
第二節 總體設計
一、總體設計的目標與要求
二、總體設計的步驟
第三節 代碼設計
一、代碼的功能
二、代碼設計規則
三、代碼的種類
四、代碼校驗
五、代碼設計的步驟
第四節 輸入、輸出和界面設計
……
第七章 衛生信息管理系統的實施、運行維護與評價
第八章 醫院信息系統
第九章 社區衛生與區域衛生服務信息系統
第十章 疾病預防控制信息系統
第十一章 衛生監督執法信息系統與電子政務系統
第十二章 衛生信息管理系統的管理
……

Ⅸ 數據倉庫的生命周期演變形式與資料庫的相同嗎

額……
資料庫的生命周期主要分為四個階段：需求分析、邏輯設計、物理設計、實現維護。符合軟體開發生命周期。數據倉庫的生命周期為資料庫的建立、部署、投入運行、同時技術人員進行維護。完成數據倉庫的一個生命周期。是完全的生命周期。

Ⅹ 為什麼傳統的資料庫不宜進行數據挖掘

為什麼要建立數據倉庫，數據倉庫和資料庫的區別？因為理論上的優點說法都很多，但要真正很好地理解，能簡潔地向客戶闡述明白，讓客戶覺得建立數據倉庫是一件值得做的事情，還是值得討論一下這個問題。有如下一些朋友們說法（自己在批註處談點個人的意見）：

A

資料庫是一個裝數據（信息的原材料）的地方。 數據倉庫是一種系統，這種系統也是用資料庫裝東西。（這有點沒說清楚：個人理解資料庫和數據倉庫當然都是裝數據的地方，關鍵的區別是裝的什麼樣的數據，資料庫裝的原始數據，沒經過任何加工；而數據倉庫是為了滿足分析需要，對源數據進行了Transform過程，具體是怎樣一個處理過程，可以從Bill Inmon的倉庫定義四個特性進行理解。） 數據倉庫系統（用資料庫裝東西）與其他基礎業務系統（例如財務系統、銷售系統、人力資源系統等，也是用資料庫裝東西）的區別是： 基礎業務系統的特點是各管各的，例如財務系統生產了白菜，那麼用一個資料庫來裝，人力資源系統生產了豬肉，再用一個資料庫來裝。我要做一道菜，需要分別到各個資料庫去取，比較麻煩（現實的情況是大部分時候讓種菜的農民伯伯送過來，但送過來的東西不一定是我想要的，而且不同的時候我想要不同的東西，經常會被農民伯伯罵，弄得雙方都不開心）。另外一方面，各個資料庫中放的是一些比較原始的東西，我要拿過來做菜，還需要經過很麻煩的清洗過程，一不小心裏面可能就藏著一條大青蟲。 那麼，數據倉庫系統就是建立一個大的超市，將各地農民伯伯出產的東西收集過來，清洗干凈，分門別類地放好。這樣，你要哪種菜的時候，直接從超市裡面拿就可以了。

B

早期一直不理解數據倉庫是什麼困惑得很。 宏觀一點講，數據倉庫就是堆放公司所有數據的地方，之所以把數據都堆在一起，是為了從中間找到有價值的東西。 數據倉庫更多的是一個概念，不要把數據倉庫想成那些號稱是數據倉庫的軟體產品們。（數據倉庫的建立和數據挖掘都是一個過程，可以從數據倉庫生命周期和OLTP系統生命周期的區別進行理解，數據挖掘過程CRISP-DM） 數據倉庫的物理上就是資料庫。相對業務系統資料庫叫OLTP資料庫（用於業務處理），這種資料庫叫OLAP資料庫（用於業務分析，不知道有沒有這種說法，個人覺得OLAP和資料庫還是不能簡單地稱為OLAP資料庫的；OLAP是針對特定問題的聯機數據訪問和數據分析而產生的一種技術，它滿足DDS從多種角度對數據進行快速、一致、交互地分析，克服傳統DDS交互能力差的弊病，使決策者能夠對數據進行深入觀察。OLAP伺服器使用為用戶預定義的多維數據視圖對數據倉庫的信息進行統計分析處理，為具有明確分析范圍和分析要求的用戶提供高性能的決策支持在線分析處理，只是基於DW上的一種多維分析方式，當然我也可以不用OLAP，直接做基於DW的DM）。 數據倉庫的概念是針對以下基本需求產生的： 公司的業務系統很多，業務系統的歷史數據不方便查詢。不同的業務系統往往管理部門不同，地域不同。能不能將所有這些數據集中起來，再淘淘有沒有有意義的業務規律。 數據倉庫資料庫往往很大，因為公司所有的數據集中得越多，越能淘到有價值的發現。例如隨便就100G以上。 數據倉庫的組成十分繁雜，既有業務系統的歷史數據，又有人事、財務數據，還要自己建一些基礎性的數據，例如，公共假期數據、地理信息、國家信息等等。 數據倉庫概念包含從業務生產系統採集數據的程序，這個程序還不能影響業務系統的運行。（屬於所謂「ETL」過程） 數據倉庫包括業務系統長期的歷史數據，例如5年，用來分析。（所謂「ODS」數據） 數據倉庫包括針對某相業務值（例如銷售量）重新打上標簽的業務流水數據。（所謂「事實表」、「維度表」）。 數據倉庫概念興許還包含報表生成工具（所謂「BI」工具）。這些工具能夠達到幾年前所謂DSS（決策分析）的效果。 數據倉庫的客戶歷史資量的分析，也許又與CRM系統粘點邊。 總之，一點，一個公司想針對已有的歷史業務數據，充分的利用它們，那麼就上數據倉庫項目。至於哪些嚇唬人的大寫字母的組合，只是達到這個目標的科學技術罷了。 牢記住數據倉庫的基本需求，不要被供應商嚇著。

C

數據倉庫可以說是決策支持系統（個人不同意這個觀點，決策支持系統（DDS）是在管理信息系統的基礎上發展起來的，在數據倉庫、OLAP技術和數據挖掘工具出現以前，就已經有DSS了，但其在實際應用開發過程中暴露出許多問題，DW為克服傳統DDS存在的問題提供了技術上的支持，基於DW上的DSS效果自然有很大提升），能幫助老闆了解企業的整體全貌，看到數據倉庫提供的經過整理統計歸納的數據後老闆憑自己的管理經驗可以發現企業的問題或困難或成功因素在哪一方面，然後可以不斷的追溯數據，直到確定到最具體的細節上，這樣能夠不斷提升老闆或管理層的管理水平，不斷改善企業的管理。我們知道的最好的一個例子就是美國某大型超市啤酒和尿布的故事。 沃爾瑪公司在美國的一位店面經理曾發現，每周，啤酒和尿布的銷量都會有一次同比攀升，一時卻搞不清是什麼原因。後來，沃爾瑪運用商業智能（Business Intelligence，簡稱BI）技術發現，購買這兩種產品的顧客幾乎都是25歲到35歲、家中有嬰兒的男性，每次購買的時間均在周末。沃爾瑪在對相關數據分析後得知，這些人習慣晚上邊看球賽、邊喝啤酒，邊照顧孩子，為了圖省事而使用一次性的尿布。得到這個結果後，沃爾瑪決定把這兩種商品擺放在一起，結果，這兩種商品的銷量都有了顯著增加。 資料庫是數據倉庫的基礎。數據倉庫實際上也是由資料庫的很多表組成的（這句話明顯不成立，數據倉庫里表分為事實表和維表，這和資料庫里的表還是有本質區別的，組織方式完全不一樣，一個是面向主題，一個是面向業務的）。需要把存放大量操作性業務數據的資料庫經過篩選、抽取、歸納、統計、轉換到一個新的資料庫中。然後再進行數據展現。老闆關注的是數據展現的結果。