現在決大多數企業已在其一個或多個部門內採用了計算機商務管理系統，也累積了相當的商業數據。然而，正如業內的那句老話“rich data, poor information”，以前累積的數據，並沒有很好的得到利用。Why?並不是企業高層管理人員沒有想到，而是這些數據來源太廣，格式不統一，並且其中極少量的數據記錄格式不正確；同時，累計的數據量相當龐大，上百萬條記錄纔剛起步，某些大型公司每天所產生的商業記錄已過千萬；而且，某些細節對高層管理人員來說並不重要。他們需要的是一份站在戰略層角度統觀全局，及時的，在短時間內可以讀完，爲企業決策服務的統計報表。
爲了實現這一艱鉅的目標，BI專家把任務分解成了三個子任務：
1)爲了整合各種格式的數據，清除原有數據中的錯誤記錄，專家們提出了數據預處理的要求——STL(數據抽取、轉換、裝載)；
2)對預處理過數據，應該統一集中起來，由此產生了元數據(Meta data)、數據倉庫(Data Warehouse)；
3)最後，對於集中起來的龐大的數據集，還應進行相應的專業統計，從中發掘出對企業決策有價值的新的機會，這就是OLAP(聯機事務分析)和數據挖掘(Data Mining)。
下面具體介紹一下每個子任務所需要用到的專業技術和輔助工具。
1)數據預處理(STL：Extraction，Transformation，Load)
當早期大型的在線事務處理系統(OLTP)問世後不久，就出現了一種用於“抽取”處理的簡單程序，其作用是搜索整個文件和數據庫，使用某些標準選擇合乎要求的數據，將其複製拷貝出來，用於總體分析。因爲這樣做不會影響正在使用的在線事務處理系統，降低其性能，同時，用戶可以自行控制抽取出來的數據。但是，現在情況發生了巨大的變化，企業同時採用了多個在線事務處理系統，而這些系統之間的數據定義格式不盡相同，即使採用同一軟件廠商提供的不同軟件產品，或者僅僅是產品版本不同，之間的數據定義格式也有少許差距。由此，我們必須先定義一個統一的數據格式，然後把各個來源的數據按新的統一的格式進行轉換，然後集中裝載入數據倉庫中。
其中，尤其要注意的一點時，並不是各個來源的不同格式的所有數據都能被新的統一格式包容，我們也不應強求非要把所有數據源的數據全部集中起來。Why?原因很多。有可能原來錄入的數據中，少量的記錄使用了錯誤的數據，這類數據如果無法校正，應該被捨去。某些數據記錄是非結構化的，很難將其轉化成新定義的統一格式，而且從中抽取信息必須讀取整個文件，效率極低，如大容量的二進制數據文件，多媒體文件等，這類數據如果對企業決策不大，可以捨去。
目前已有一部分軟件廠商開發出專門的ETL工具，其中包括：
·Ardent DataStage
·Evolutionary Technologies,Inc. (ETI) Extract
·Information Powermart
·Sagent Solution
·SAS Institute
·Oracle Warehouse Builder
·MSSQL Server2000 DTS
2)數據倉庫
上面提到，在進行STL之前，需要先定義一個統一的數據格式。那麼，定義出來的統一的數據格式是否需要保存起來，以便在數據倉庫日後的演化中使用呢？Yes!隨着企業不斷變化的商業模式和業務規則，肯定需要對系統進行修改和功能升級。如果弄不清楚之前定義的數據格式的具體含義，我們將無從下手。所以，我們需要一種用來描述數據的數據。早期我們使用的是數據字典(Data Dictionary)，數據字典一般包括數據的定義、關係、來源、作用域、格式和用法。但是，隨着時間的推移，專家們發現，越來越多的已搭建好的數據倉庫希望方便的包容最新的各種格式的結構化和非結構化數據，而傳統的基於關係型數據庫的數據字典並不能達成這一目標。
xml出世之後，這種自描述，可無限嵌套擴展，平臺獨立性的文本數據格式爲數據字典的進化提供了相當重要的技術支持，由此產生了基於xml的元數據的概念。並且，目前已有不少的軟件系統和數據倉庫都採用了xml格的元數據。如微軟的.Net，P2P的EMule等。由此可見，元數據並不單單侷限運用在數據倉庫中。
由於基於xml的元數據相當靈活，我們可以用元數據來描述複雜的商業業務定義。所以，現在數據倉庫中的元數據分爲兩種：技術元數據和業務元數據。技術元數據(technical meta data)是爲企業技術用戶和IT部門的員工提供支持的元數據，對於維護和改進系統來所至關重要。而業務元數據(business meta data)是爲企業業務用戶提供支持的元數據，使業務用戶更容易理解統計報表中的信息。
元數據工具分爲兩類：一類是將各種元數據集成到集中式倉儲的集成工具，另一類是在倉儲上執行查詢訪問的訪問工具。一般來說，大多數軟件廠商所提供的數據倉庫、BI系統中都捆綁了相應的工具。其中包括：
·Ardent MetaStage (Infomix)
·IBM information Catalog
·Brio Enterprise
·Business Objects
·Cognos Impromptu及Powerplau
·Information Advantage Business Intelligence
·Microsoft OLAP Services ("Plato")
·Microstrategy DSS Web and Server
數據倉庫是BI的基礎，就好比廚師的食材。各個數據源的數據經ETL的預處理後，就被送進了數據倉庫中。數據倉庫有如下４個重要特性：
①面向主題的：不同類型的公司，其主題集合是不相同的。
②集成的：數據倉庫的數據來源很廣，數據倉庫最重要的目的就是爲了集成這些不同數據源的數據。
③非易失的：和傳統的操作型數據庫系統相比，數據倉庫通常是以批量方式載入和訪問。而且，對於數據倉庫中的記錄，並不進行一般意義上的數據更新，刪除。所有的歷史數據都會被保留，通常我們只是不停的批量導入新的數據。
④隨時間變化的：操作型數據庫系統出於性能上的考慮，並不保存系統投入運行後所產生的所有數據，一般只保留最新的60~90天內所產生的數據記錄。而且，通常情況下，操作型數據庫中一項業務活動只佔用一條記錄。當業務狀況發生變化後，我們只需更新相應的記錄。而爲了按時間變化發掘業務活動的時序規律，數據倉庫中，該業務活動可能同時存在多條記錄，除了相應字段的內容不同外，其業務活動的時間記錄也不相同。數據倉庫中的數據是一系列在某時某刻生成的複雜的快照，由此可見，數據倉庫的數據是高度冗餘且必須的。
而且，由於數據倉庫的使用對象不盡相同，數據倉庫的設計需要考慮其數據單元的細節程度，即粒度。細節程度越高，粒度級就越低，反之亦然。例如：一個簡單的交易處於低粒度級，而每個月所有交易的彙總則處於一個高粒度級。通常，數據分析人員使用的數據粒度較低，而高層管理人員所使用的數據粒度較高。粒度同時決定了數據倉庫所佔用的物理空間的大小，儘管一條交易記錄可能只佔用200個字節，但是一個月所累積的10萬條交易記錄就佔用了20M個字節。如果按月對每月的所有交易記錄進行綜合，所得到的記錄可能只佔用500個字節。
數據倉庫通常的活動是批量載入和查詢訪問，並不進行一般意義的數據更新，而且其數據冗餘程度較高。爲了提高查詢效率，我們可以採用一些非常規的方法來進行數據分區存儲。而且，我們需要對數據倉庫中的數據進行方便且有效的監控。
提供數據倉庫技術服務的軟件廠商大多是從操作型數據庫系統發展起來，其推出的數據倉庫都是基於其自身研發的大型數據庫產品上，且捆綁了相應的ETL，元數據，OLAP，報表等工具，如IBM的DM2，SAS，Sybase，Oracle，Informix，MSSQL Server等。
在本節末要說明一下數據集市(Data Mark)。如果說數據倉庫是建立在企業級的數據模型之上的話。那麼數據集市就是企業級數據倉庫的一個子集，他主要面向部門級業務，並且只面向某個特定的主題。數據集市可以在一定程度上緩解訪問數據倉庫的瓶頸。然而，由於各個數據集市之間彼此獨立，從而形成新的“信息孤島”，也造成了重複投資。所以，目前越來越多的數據倉庫廠商開始提供幫助企業用戶整合原有數據集市，構建集中數據倉庫的技術服務。在實際項目中，到底是選擇數據倉庫，還是選擇數據集市，應取決於該項目的主要商業驅動。如果企業正忍受糟糕的數據管理和不一致的數據，希望爲今後打下良好的基礎，則數據倉庫的方案比較好。如果該企業迫切需要給用戶提供信息，那麼可以先構建一個數據集市。而一旦滿足了迫切的信息需求後，就應該考慮包含獨立數據倉庫的數據體系結構的轉換計劃。
