筆者曾經看到乙份某廠商提交給使用者的報告，認為「teradata只支援第三正規化而不支援星形模式」。這就完全誤解了邏輯資料模型與物理平台的關係。事實上，無論是星形模式還是第三正規化，都是邏輯上的概念，與具體的物理平台並沒有什麼關係。
teradata、udb、oracle、sql server等都是關聯式資料庫產品，都能同時支援星形模式和第三正規化。只是在物理實施時，由於各種資料庫產品的特性、內部結構等方面的差異，當資料量很大時，一些資料庫產品無法處理以規範方式（如第三正規化）儲存的海量資料，不得不採取星形模式或者其它不規範化方式（如小結表、預連線等）對資料進行預處理，以回答那些可以預知的業務問題。
很多資料庫產品都是基於聯機交易處理系統（oltp）設計的，其內部結構更適合於進行交易處理，並不適合於資料倉儲中大量的複雜資料分析與綜合處理。這些資料庫用於資料倉儲引擎時，往往**儲存採用第三正規化建模，然後按照各種預知的需求建立大量的資料集市，前台業務使用者只是訪問這些資料集市，從而遮蔽了業務使用者對後台詳細資料的訪問。
現在很多企業都在進行資料集中、統一平台與標準等工作，因此在選擇資料倉儲前端產品時，它們往往要問:能否選擇乙個統一的前端展現工具？哪些前端產品與哪些資料庫產品的匹配性最好？
不同的前端產品具有不同的市場定位和功能特點，雖然各種工具產品的功能與特點確實有許多交叉和重合，但基本上沒有一種前端產品可以涵蓋乙個企業所有業務部門的需求。國外許多發展多年的資料倉儲系統大多是根據不同型別使用者的使用特點與需求而選用不同的前端工具。如果我們去考察乙個資料倉儲使用者，往往會發現他們同時使用了sas、bo、brio、cognos
等多種工具。
磁碟容量越來越大，從早期的9gb、18gb，到現在的36gb、73gb、146gb，而且更高容量的磁碟還會不斷出現。那麼在配置資料倉儲的儲存系統時，是否磁碟容量越大越好？如果不是，應該如何進行選擇？
資料倉儲負載主要是sql查詢處理，需要掃瞄大量的資料，因此資料倉儲系統對磁碟儲存系統的i/o要求很高。而影響乙個磁碟儲存系統總體i/o頻寬的主要因素是磁碟個數和磁碟轉速。
一般來說，隨著磁碟數的增加，儲存系統的i/o頻寬也會相應增加。但磁碟數增加到一定程度，儲存系統的i/o將趨於飽和。因此，儲存系統的磁碟數並非越多越好。使用者在進行選擇時，要研究磁碟儲存系統的i/o頻寬與其磁碟數之間的關係圖表，並注意儲存系統的i/o能力在資料倉儲負載不同時，會發生相應變化，一般情況下，可以認為資料倉儲的典型負載為80%讀、20%寫。
另乙個影響儲存系統i/o能力的主要因素是磁碟轉速，轉速越高，i/o越好。目前市面上的磁碟轉速主要有7200轉、10000轉和15000轉。我們在選擇磁碟時，應該是轉速越高越好，更準確地說，是平均到每單位儲存容量上的頻寬越高越好。
現在很多人常常走入乙個誤區:把開放性理解成硬體平台能否支援多種作業系統或者資料庫軟體，資料庫能否執行在多個作業系統或者硬體平台上。
乙個系統是否開放，我們主要考察它的可移植性、互操作性以及可擴充套件能力。從這幾點要求來看，考察資料倉儲系統的開放性與oltp系統的開放性並沒有什麼區別。
oltp系統中的資料是自身在執行過程當中產生的，而資料倉儲系統本身不產生資料，其資料需要從業務系統中獲得。因此在考察資料倉儲系統開放性時需要著重考察其對源資料的獲取能力，gartner group把這種能力稱之為適應性(suitability)。
另外，由於資料倉儲系統與業務處理系統的應用完全不同，其資料模型也完全不一樣，兩個系統之間的etl（資料抽取、轉換與載入）是非常複雜的。因此我們在考察資料倉儲系統的開放性時，需要著重考察其從業務系統獲取資料的能力。
資料倉儲系統中不同使用者的資訊訪問特點不一樣，一般使用者的大部分需求可以從多維立方體、預定義報表中得到，這時，系統效能主要取決於網路傳輸速度、olap伺服器的併發處理效能等因素。一般來說，這時的響應速度都在秒級。
對於資料倉儲中的動態查詢、資料探勘等複雜分析，其效能主要取決於資料倉儲引擎的併發處理能力和複雜sql處理能力。但由於需求的不可預知性，很難定義明確的效能指標。
因此，我們在定義資料倉儲系統效能指標時，應該根據不同使用者的使用特點分別規劃，然後再對資源進行合理的安排和排程，以滿足大部分使用者的效能要求。
資料倉儲與資料湖之間的理解誤區
誤解一 資料倉儲和資料湖二者在架構上只能二選一 很多人認為資料倉儲和資料湖在架構上只能二選一，其實這種理解是錯誤的。資料湖和資料倉儲並不是對立關係，相反它們的並存可以互補給企業架構帶來更多的好處 資料倉儲儲存結構化的資料，適用於快速的bi和決策支撐，而資料湖可以儲存任何格式的資料，往往通過挖掘能夠發...
資料倉儲（二） 資料倉儲為什麼要分層
1 空間換時間。通過建設多層次的資料模型供使用者使用，避免使用者直接使用操作型資料，可以更高效的訪問資料。把複雜問題簡單化。講乙個複雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。而且便於維護資料的準確性，當資料出現問題之後，可以不用修復所有的資料，只需要從有問題的步驟開始...
資料倉儲（六） 資料倉儲的概念設計
在資料集市設計中可以使用3種基本的系統方法 資料驅動的方法 需求驅動的方法和混合方法。它們的區別在於源資料庫分析和終端使用者需求分析階段所佔的比重。方法的選擇將極大地影響概念設計的方式。資料驅動方法包括 基於實體 關係模式的設計 基於關係模式的設計 基於xml模式的設計。概念型實體 關係模式比關係型...