在第一部分中，我们讨论了什么是商业智能应用程序以及为什么需要它。在第二部分中，我们将更多 地专注于你与商业智能应用程序的一些密切关系。
普遍的误解
在开始介绍购买决策的一些反对意见之前，我想讨论一些普遍的误解。
它只作用于预先建立的数据源：
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平台的这个能力是这篇文章存 在的原因。