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平台的這個能力是這篇文章存 在的原因。