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

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

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

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

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

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

表1：事務處理 V.S 分析系統

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

數據倉庫（data warehouse）

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

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

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

圖8：數據倉庫和簡化的ETL過程

大廠幾乎都有數倉，但小廠卻少聞。可能是因為小廠沒那么多不同OLTP系統，一般只有少量數據，完全可以在傳統SQL數據庫中直接查詢分析，甚至可以在Excel分析。而在大廠，做一些在小廠很簡單的事，往往需大量繁重工作。

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

OLTP數據庫 V.S 數據倉庫

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

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

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

最近，大量開源的基于Hadoop的SQL項目出現，雖然還很年輕，但在與商業數倉系統競爭。入Apache Hive，Spark SQL，Cloudera Impala，Facebook Presto。

星型和雪花型的分析模式

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

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

圖9：用于數據倉庫的星型模式的示例**

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

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

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

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

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

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

典型數倉中，表格通常很寬：

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