1. 數據庫和數據倉庫有什么區別？
2. 某大公司Hadoop Hive里的關系表不完全滿足完整/參照性約束，也不完全滿足范式要求，甚至第一范式都不滿足，這種情況正常嗎？
3.Oracle會在三年之內被代替嗎？為什么？
如果您不能五秒內給出答案，那么本文應該是對您有幫助的。
數據庫的"分家"
隨著關系數據庫理論的提出，誕生了一系列經典的RDBMS，如Oracle，MySQL，SQL Server等。這些RDBMS被成功推向市場，并為社會信息化的發展做出的重大貢獻。然而隨著數據庫使用范圍的不斷擴大，它被逐步劃分為兩大基本類型：
1. 操作型數據庫
主要用于業務支撐。一個公司往往會使用并維護若干個數據庫，這些數據庫保存著公司的日常操作數據，比如商品購買、酒店預訂、學生成績錄入等；
2. 分析型數據庫
主要用于歷史數據分析。這類數據庫作為公司的單獨數據存儲，負責利用歷史數據對公司各主題域進行統計分析；
那么為什么要"分家"？在一起不合適嗎？能不能構建一個同樣適用于操作和分析的統一數據庫？
答案是NO。一個顯然的原因是它們會"打架"......如果操作型任務和分析型任務搶資源怎么辦呢？再者，它們有太多不同，以致于早已"貌合神離"。接下來看看它們到底有哪些不同吧。
操作型數據庫 VS 分析型數據庫
因為主導功能的不同(面向操作/面向分析)，兩類數據庫就產生了很多細節上的差異。這就好像同樣是人，但一個和尚和一個穆斯林肯定有很多行為/觀念上的不同。
接下來本文將詳細分析兩類數據庫的不同點：
1. 數據組成差別 - 數據時間范圍差別
一般來講，操作型數據庫只會存放90天以內的數據，而分析型數據庫存放的則是數年內的數據。這點也是將操作型數據和分析型數據進行物理分離的主要原因。
2. 數據組成差別 - 數據細節層次差別
操作型數據庫存放的主要是細節數據，而分析型數據庫中雖然既有細節數據，又有匯總數據，但對于用戶來說，重點關注的是匯總數據部分。
操作型數據庫中自然也有匯總需求，但匯總數據本身不存儲而只存儲其生成公式。這是因為操作型數據是動態變化的，因此匯總數據會在每次查詢時動態生成。
而對于分析型數據庫來說，因為匯總數據比較穩定不會發生改變，而且其計算量也比較大(因為時間跨度大)，因此它的匯總數據可考慮事先計算好，以避免重復計算。
3. 數據組成差別 - 數據時間表示差別
操作型數據通常反映的是現實世界的當前狀態；而分析型數據庫既有當前狀態，還有過去各時刻的快照，分析型數據庫的使用者可以綜合所有快照對各個歷史階段進行統計分析。
4. 技術差別 - 查詢數據總量和查詢頻度差別
操作型查詢的數據量少而頻率多，分析型查詢則反過來，數據量大而頻率少。要想同時實現這兩種情況的配置優化是不可能的，這也是將兩類數據庫物理分隔的原因之一。
5. 技術差別 - 數據更新差別
操作型數據庫允許用戶進行增，刪，改，查；分析型數據庫用戶則只能進行查詢。
6. 技術差別 - 數據冗余差別
數據的意義是什么？就是減少數據冗余，避免更新異常。而如5所述，分析型數據庫中沒有更新操作。因此，減少數據冗余也就沒那么重要了。
現在回到開篇是提到的第二個問題"某大公司Hadoop Hive里的關系表不完全滿足完整/參照性約束，也不完全滿足范式要求，甚至第一范式都不滿足。這種情況正常嗎？"，答曰是正常的。
因為Hive是一種數據倉庫，而數據倉庫和分析型數據庫的關系非常緊密(后文會講到)。它只提供查詢接口，不提供更新接口，這就使得消除冗余的諸多措施不需要被特別嚴格地執行了。
數據倉庫(data warehouse)定義
聰明的讀者應該已經意識到這個問題：既然分析型數據庫中的操作都是查詢，因此也就不需要嚴格滿足完整性/參照性約束以及范式設計要求，而這些卻正是關系數據庫精華所在。這樣的情況下再將它歸為數據庫會很容易引起大家混淆，畢竟在絕大多數人心里數據庫是可以關系型數據庫畫上等號的。
那么為什么不干脆叫"面向分析的存儲系統"呢？
事實上數據倉庫不應讓傳統關系數據庫來實現，因為關系數據庫最少也要求滿足第1范式，而數據倉庫里的關系表可以不滿足第1范式。也就是說，同樣的記錄在一個關系表里可以出現N次。但由于大多數數據倉庫內的表的統計分析還是用SQL，因此很多人把它和關系數據庫搞混了。
知道了什么是數據倉庫后，再來看看它有哪些特點吧。某種程度上來說，這也是分析型數據庫的特點：
1. 面向主題
面向主題特性是數據倉庫和操作型數據庫的根本區別。操作型數據庫是為了支撐各種業務而建立，而分析型數據庫則是為了對從各種繁雜業務中抽象出來的分析主題(如用戶、成本、商品等)進行分析而建立；
2.集成性
集成性是指數據倉庫會將不同源數據庫中的數據匯總到一起；
3.企業范圍
數據倉庫內的數據是面向公司全局的。比如某個主題域為成本，則全公司和成本有關的信息都會被匯集進來；
4.歷史性
較之操作型數據庫，數據倉庫的時間跨度通常比較長。前者通常保存幾個月，后者可能幾年甚至幾十年；
5.時變性
時間性是指數據倉庫包含來自其時間范圍不同時間段的數據快照。有了這些數據快照以后，用戶便可將其匯總，生成各歷史階段的數據分析報告；
數據倉庫組件
數據倉庫的核心組件有四個：各源數據庫，ETL，數據倉庫，前端應用。如下圖所示：
1. 業務系統
業務系統包含各種源數據庫，這些源數據庫既為業務系統提供數據支撐，同時也作為數據倉庫的數據源(注：除了業務系統，數據倉庫也可從其他外部數據源獲取數據)；
2.ETL
ETL分別代表：提取、轉換、加載。其中提取過程表示操作型數據庫搜集指定數據，轉換過程表示將數據轉化為指定格式并進行數據清洗保證數據質量，加載過程表示將轉換過后滿足指定格式的數據加載進數據倉庫。
數據倉庫會周期不斷地從源數據庫提取清洗好了的數據，因此也被稱為"目標系統"；
3.前端應用
和操作型數據庫一樣，數據倉庫通常提供具有直接訪問數據倉庫功能的前端應用，這些應用也被稱為BI(商務智能)應用，其核心是以可視化的圖表將數據展現出來，使其具有對業務的決策指導意義。
數據集市(data mart)
數據集市可以理解為是一種"小型數據倉庫"，它只包含單個主題，且關注范圍也非全局。
數據集市可以分為兩種，一種是獨立數據集市，這類數據集市有自己的源數據庫和ETL架構；另一種是非獨立數據集市，這種數據集市沒有自己的源系統，它的數據來自數據倉庫。
當用戶或者應用程序不需要/不必要/不允許用到整個數據倉庫的數據時，非獨立數據集市就可以簡單為用戶提供一個數據倉庫的"子集"。
數據倉庫開發流程
在數據庫系列的第五篇中，曾詳細分析了數據庫系統的開發流程。數據倉庫的開發流程和數據庫的比較相似，因此本文僅就其中區別進行分析。
下圖為數據倉庫的開發流程：
較之數據庫系統開發，數據倉庫開發只多出ETL工程部分。然而這一部分極有可能是整個數據倉庫開發流程中最為耗時耗資源的一個環節。
因為該環節要整理各大業務系統中雜亂無章的數據并協調元數據上的差別，所以工作量很大。在很多公司都專門設有ETL工程師這樣的崗位，大的公司甚至專門聘請ETL專家。
小結
在大數據時代，數據倉庫的重要性更勝以往。Hadoop平臺下的Hive，Spark平臺下的Spark SQL都是各自生態圈內應用最熱門的配套工具，而它們的本質就是開源分布式數據倉庫。
在國內的互聯網公司里，很多數據引擎是架構在數據倉庫之上的。不少員工認為，開發成本應更多集中在數據倉庫層，不斷加大數據建設的投入。
因為一旦規范、標準、高性能的數據倉庫建立好了，在之上進行數據分析、數據挖掘、跑推薦算法等都是輕松愜意的事情。反之如果業務數據沒梳理好，各種臟亂數據會搞得人焦頭爛額，苦不堪言。
