Oracle商業智能應用程序(第二部分)

在第一部分中，我們討論了什麼是商業智能應用程序以及為什麼需要它。在第二部分中，我們將更多 地專注於你與商業智能應用程序的一些密切關系。

普遍的誤解

在開始介紹購買決策的一些反對意見之前，我想討論一些普遍的誤解。

它只作用於預先建立的數據源：

Oracle商業智能應用程序完全設計為用比一個開發場景中少得多的工作量就可以添加新的數據源到商 業智能應用程序。使用一個發布——訂閱模型，數據可以從任何與商業智能應用程序中的已有對象相匹配 的源應用程序中提取。在提取之後，一個叫做Universal Adapters 的特性會使用這個數據並繼續轉換和 加載它到目標商業應用程序中去。

我會受限於我所購買的應用程序：

商業智能應用程序是建立在一個百分百開放的平台上的;沒有不能擴展的東西。你是否對與你所購買的 商業智能應用程序沒有關系的一些數據具有報表需求呢?那麼只要像你一般所做的——簡單的開發這些映 射，並將它們插入到強大的基礎構建中作為另一個工作流。

這裡關鍵的地方是他們不會以任何方式或形式將你束縛於你所購買的代碼。實際上，你可以購買一個 商業智能應用程序，刪除所有的商業智能應用程序特殊代碼，並使用這個平台和基礎構建來建立一個百分 百定制的數據倉庫。這產生了重復工作：你可以將這個平台簡單地作為一個預先建立的基礎構建並做任何 你想對它做的(假設你有正確的許可證)。如同在第一部分中所說的，在建立一個新的數據倉庫時，通常會 忽略ETL基礎構建。

實際上，大多數商業智能應用程序部署從其它的來源帶來了其它數據，例如其它的一些ERP、外部數據 、電子數據表、或定制開發的內部應用程序。如果復雜性是第一關注的焦點，那麼你完全可以將商業智能 應用程序看作是一個著手點，而最終方向是由非商業智能應用程序內容和需求所決定的。

應用程序供應商的商業智能應用程序是輕量級的：

這對於許多商業智能應用程序來說確實如此。事實上Oracle在它的商業智能應用程序7.9出現之前它自 己所提供的就是如此。但是，現在Oracle所提供的商業智能應用程序遠遠超出輕量級范圍。這些應用程序 是使用行業最佳方法建立在范圍和數據庫可以處理的一樣廣泛的關系型平台上的。

不像從其它供應商那裡拿來的預先打包的商業智能應用程序那樣，Oracle 使用了與你一開始想使用的 相同設計技術、工具和平台。如果你對於關系型數據庫、維度模型和Informatica感覺很好，那麼你也會 覺得商業應用程序很好的。對於這些工具你想自己在一個開發環境中所做的一切事情你都可以對購買的 Oracle商業智能應用程序去做。此外，Oracle 添加了Informatica所沒有的一些功能，叫做ETL Orchestration(以數據倉庫管理控制台——“DAC”的形式)。

有一個復雜的例子，如果必要的話你可以構建到你的商業智能應用程序系統中去，就是例如一個跨國 公司有兩個不同類型的ERP，每一個都放在世界各地的6個數據中心裡。此外，在各地較小的應用程序中有 更多的客戶數據。這所有的12個ERP實例需要順利地集成到一個數據倉庫中，還要克服潛在的數據問題， 例如在不只一個的ERP上數據隨機顯示，在ERP間鏈接記錄，以及一個復雜的安全模型。實際場景是對商業 智能應用程序進行適當的擴展和定制以處理更多的邏輯。許多用戶需求是和預先開發的代碼和配置非常不 同的，但是商業智能應用程序可以調整以處理非常復雜的需求。

對於商業智能應用程序的復雜性，關於關系OLAP vs 多維OLAP(立方體)有一點需要討論。要以對商業 智能應用程序添加新的維度以進行度量分析，只要對現有的可以處理許多豐富維度的事實表添加一個新的 維度就可以了。基於立方體的系統一般不以這種方式操作;對你在一個立方體確定下來之前能夠添加到它 其中的維度屬性是有限制的，而且要刪除一些其它的東西。企業級ROLAP引擎就不像OBI EE。

最後，有了OBI EE的功能，OBI應用程序受到了廣泛的關注。當CRM宣布客戶的360度查看時，這個咒語 再次在商業智能應用程序上開始實現了。360度查看意味著深度和廣度，而且在OBI EE平台上具有廣泛和 深入的分析功能，並在商業智能應用程序中獲得了利用。實際上，這使得可以對各種不同的度量進行分析 ，每一個都是從不同的源獲得，而且同時對不同的過程進行分析。這是在商業智能應用程序中嚴重缺少的 能力，因為技術平台的限制或他們的應用程序弱點所造成的。此外，OBI EE平台的這個能力是這篇文章存 在的原因。