?早期，數(shù)據(jù)庫寫入通常與一筆商業(yè)交易（commercial transaction）相對應：如銷售、訂單等。雖然隨數(shù)據(jù)庫發(fā)展到不涉及金錢交易的領域，術語 交易/事務（transaction） 仍保留下來，指一組讀寫操作構成的一個邏輯單元。

事務不一定具備ACID。事務處理只是意味著允許客戶端進行低延遲讀取和寫入，而不是只能周期運行（如每天一次）的批量處理作業(yè)。

即使數(shù)據(jù)庫開始被用于許多不同類型的數(shù)據(jù)，如博客評論，游戲的動作，通訊錄的聯(lián)系人等，但基本訪問模式仍類似處理商業(yè)交易。應用程序通常使用索引通過某K查找少量記錄。根據(jù)用戶輸入新增或更新記錄。由于這些應用程序是交互式的，這種訪問模式被稱為 在線事務處理（OLTP, OnLine Transaction Processing） 。

但數(shù)據(jù)庫也越來越多用于數(shù)據(jù)分析，它們有著很不同的訪問模式。通常，分析查詢需掃描大量記錄，每個記錄只讀取幾列，并計算匯總統(tǒng)計信息（如計數(shù)，總和或平均值），而非將原始數(shù)據(jù)返給用戶。例如，若數(shù)據(jù)是個銷售交易表，則分析查詢可能包含：

• 一月份每個商店的總收入？
• 在最近的推廣活動中多賣了多少香蕉？
• 哪個牌子的嬰兒食品最常與X品牌的尿布同時購買？

這些查詢通常由業(yè)務分析師編寫，并提供給幫助公司管理層做出更好決策（商業(yè)智能）的報告。為將這種使用數(shù)據(jù)庫的模式和事務處理區(qū)分，被稱為在線分析處理（OLAP, OnLine Analytice Processing）。

表1：事務處理 V.S 分析系統(tǒng)

起初，相同數(shù)據(jù)庫可同時用于事務處理和分析查詢。SQL在這方面證明是非常靈活：可同時勝任OLTP及OLAP類型查詢。但1980s末和1990s初期，公司放棄使用OLTP系統(tǒng)用于分析，而是在單獨數(shù)據(jù)庫上運行分析：數(shù)據(jù)倉庫。

數(shù)據(jù)倉庫（data warehouse）

企業(yè)可能有幾十個不同交易處理系統(tǒng)：面向終端客戶的網(wǎng)站，控制實體店的收銀系統(tǒng)，跟蹤倉庫庫存，規(guī)劃車輛路線，供應鏈管理，員工管理等。這些系統(tǒng)中每個都很復雜，需專人維護，所以系統(tǒng)最終都是彼此獨立運行。

這些OLTP系統(tǒng)往往對業(yè)務運作至關重要，因而通常要求高可用 與處理事務時 低延遲。所以DBA會密切關注他們的OLTP數(shù)據(jù)庫，DBA一般不愿意讓業(yè)務分析人員在OLTP數(shù)據(jù)庫上運行臨時分析查詢，因為這些查詢通常開銷巨大，會掃描大量數(shù)據(jù)集，這會損害并發(fā)執(zhí)行事務的性能。

相比之下，數(shù)據(jù)倉庫是個獨立數(shù)據(jù)庫，分析人員可查詢他們想要的內容而不影響OLTP操作。數(shù)據(jù)倉庫包含公司各種OLTP系統(tǒng)的只讀副本。從OLTP數(shù)據(jù)庫（使用周期數(shù)據(jù)轉儲或連續(xù)更新流）中提取數(shù)據(jù)，轉換成適合分析的模式，清理并加載到數(shù)據(jù)倉庫中。將數(shù)據(jù)存入倉庫的過程稱為“提取-轉換-加載（Extract-Transform-Load，ETL）”：

圖8：數(shù)據(jù)倉庫和簡化的ETL過程

大廠幾乎都有數(shù)倉，但小廠卻少聞?？赡苁且驗樾S沒那么多不同OLTP系統(tǒng)，一般只有少量數(shù)據(jù)，完全可以在傳統(tǒng)SQL數(shù)據(jù)庫中直接查詢分析，甚至可以在Excel分析。而在大廠，做一些在小廠很簡單的事，往往需大量繁重工作。

使用單獨的數(shù)倉，而非直接查詢OLTP系統(tǒng)進行分析，一大優(yōu)勢是數(shù)倉能針對分析訪問模式進行優(yōu)化。之前討論的索引算法對OLTP工作效果很好，但不擅長應對分析查詢。

OLTP數(shù)據(jù)庫 V.S 數(shù)據(jù)倉庫

數(shù)倉的數(shù)據(jù)模型通常是關系型，因為SQL通常很適合分析查詢。有許多GUI數(shù)據(jù)分析工具可生成SQL查詢，可視化結果，并允許分析人員探索數(shù)據(jù)（通過下鉆，切片和切塊等操作）。

表面上，數(shù)倉和關系OLTP數(shù)據(jù)庫相似，因為它們都有SQL查詢接口。但系統(tǒng)內部很不同，它們針對迥然不同的查詢模式，各自進行了優(yōu)化。許多數(shù)據(jù)庫供應商都專注支持事務處理或分析工作負載，而不是同時支持。

一些數(shù)據(jù)庫（如Microsoft SQL Server和SAP HANA）支持在同一產(chǎn)品中支持事務處理和數(shù)倉。但它們正在日益成為兩個獨立的存儲和查詢引擎，這些引擎恰好能通過一個通用SQL接口進行訪問。

最近，大量開源的基于Hadoop的SQL項目出現(xiàn)，雖然還很年輕，但在與商業(yè)數(shù)倉系統(tǒng)競爭。入Apache Hive，Spark SQL，Cloudera Impala，F(xiàn)acebook Presto。

星型和雪花型的分析模式

根據(jù)應用程序需要，在事務處理領域使用了多種不同數(shù)據(jù)模型。分析型業(yè)務的數(shù)據(jù)模型則少得多。許多數(shù)倉都以相當公式化的方式使用，稱為星型模式（也稱為維度建模）。

圖9中的模式顯示了可能在食品零售商處找到的數(shù)倉。模式的中心是個事實表（該案例中稱為fact_sales）。事實表的每行表示在特定時間發(fā)生的事件（這里的每行代表客戶購買的產(chǎn)品）。若分析網(wǎng)站流量而非零售量，則每行可能代表一個用戶的頁面瀏覽量或點擊量：

圖9：用于數(shù)據(jù)倉庫的星型模式的示例**

一般事實被捕獲為單獨事件，因為這樣之后的分析中獲得最大的靈活性。但是，這意味著事實表可能很大。像蘋果這樣巨頭在數(shù)倉可能有幾十PB交易歷史，其中大部分保存在事實表。

事實表中的列是屬性，如產(chǎn)品銷售的價格和從供應商處購買的成本（可計算出利潤率），其它列是對其他表（稱為維度表）的外鍵引用。由于事實表中的每一行都表示一個事件，因此這些維度代表事件的發(fā)生地點，時間，方式和原因。

如圖9中，其中一個維度是銷售的產(chǎn)品。 dim_product? 表中的每行代表一種出售產(chǎn)品，包括庫存單位（SKU），說明，品牌名稱，類別，脂肪含量，包裝尺寸等。fact_sales 表中的每行都使用外鍵表示在特定交易中銷售了哪些產(chǎn)品。（為簡單起見，如果客戶一次購買幾種不同產(chǎn)品，則它們在事實表中被表示為單獨行）。

日期和時間通常使用維度表來表示，因為這允許對日期的附加信息（如公共假期）進行編碼，從而允許查詢區(qū)分假期和非假期的銷售。

“星型模式”名字來源：當表關系可視化時，事實表在中間，被一系列維度表包圍；與這些表的連接就像星星的光芒。

該模板的變體為雪花模式，其中維度被進一步分解為子維度。如品牌和產(chǎn)品類別可能有單獨表格，且dim_product? 表格中的每行都能再次將品牌和類別作為外鍵，而不是將它們作為字符串直接存儲在 dim_product 表。雪花模式比星形模式更規(guī)范化，但星形模式是首選，因為對于分析師，它更簡單。

典型數(shù)倉中，表格通常很寬：

• 事實表格通常超過100列，有時甚至數(shù)百列；
• 維度表也可能很寬，因為它們包括可能與分析相關的所有元數(shù)據(jù)。如dim_store 表可能包括在每個商店提供哪些服務的細節(jié)，是否具有店內面包房，店面面積，商店開張日期，最后一次裝修時間，距離最近的高速公路有多遠等。