BO与Oracle BIEE产品对比 v1.doc

第1章 产品体系结构比较

BO
Oracle BIEE
多数据源的集成
语义层能同时连接多种数据源。
前端只能访问单一数据源。
统一的产品架构
BO采用统一的架构、统一的WEB界面提供了所有类型的BI应用。
OBIEE由一系列收购的工具松散的耦合而成，并非统一的架构。
安全性
能够对整个系统进行统一的安全性定义。
需要在不同的BI工具中单独进行安全性定制，无法在不同工具间进行同步。

第2章 在企业关键BI需求上BO 与 OBIEE对比
BI关键需求
BO
OBIEE
统一的BI平台
· 报表和深层分析无缝整合
· 统一Web界面
· 唯一元数据
BO BI 是一个统一的、完整的架构，整个系统具有统一用户管理、统一权限管理、统一元数据和统一的门户。

Oracle是首次尝试将Siebel Business Analytics Platform，Hyperion BI and Oracle Business applications三者整合在一起， 它还不是一个经过项目检验的、成熟的BI平台。
OBIEE中不同的功能模块拥有不同的WEB界面(例如：Presentation Services Web 界面和Oracle BI Publisher 界面)，现在WEB界面中只是通过链接将他们生硬的连在一起。
OBIEE拥有多个元数据， Oracle BI Server、Oracle BI Publisher、 Presentation Services 都分别拥有独立的元数据库。
经市场证明的企业级性能
· 支持64位
· 7*24小时的高可靠性
· 智能集群
· 负载均衡
BO 完全支持64位的系统，包括64位的Windows 2003、HP-UX、Linux Red Hat、Linux SUSE等。
BO具有智能的集群功能， 它的群集是一个全部激活的对等配置，系统是作为一个统一的逻辑平台共同承担负载。
BO不仅能在相同的操作系统间配置集群，还能跨系统配置集群。例如，在UNIX服务器和Windows服务器间配置集群。
通过配置集群BO系统能够实现负载均衡，达到7*24小时的高可靠性。
OBIEE 并不真正支持64位的Linux平台，它需要32位的处理器模拟器。
OBIEE采用主从模式的集群架构，虽然从服务器出现故障不会影响整个系统，但主服务器的故障则会影响整个集群系统，因此OBIEE并不能真正支持7*24小时的高可靠性。
在集群的环境中Oracle BI Server必须重启才能获取变化的元数据。而且在配置集群的时候，必须手动为每个BI Server手动安装和维护配置文件，以及同步服务器的时钟等。
可重用的元数据层
· 统一的元数据
· 可重用的元数据
· 面向对象的元数据
BO BI拥有一个统一的元数据。BO BI在这个统一的元数据基础上提供了统一、一致的数据视图。
BO报表中的提示、筛选等都可以保存为一个报表对象，在多个报表间重用。
OBIEE Plus 缺乏统一的元数据库。它共有三个元数据库，BI Server、Presentation Services、BI Publisher Server各有一个元数据库。各个功能模块间无法完全共享元数据信息。
报表中的提示作为报表的属性保存在元数据中，无法在报表间共享，不具备可重用性。
交互的所见即所得Web界面
· 完全交互的报表，任何浏览器上都是零脚本下载。
· Web上所见即所得的文档编辑和设计界面
全球最漂亮的交互式易表盘，支持FLASH以及假设分析。
实时离线的交互式仪表盘，与PPT整合以及在线多维分析。
BO在WEB界面中提供了所见即所得编辑功能。所有的功能都是通过HTML和脚本来实现，无需下载任何插件。
BO的Dashboard提供了大量的交互控件，如单选/多选按钮、滑动条、下拉菜单等，在用户和仪表盘之间提供了丰富的交互功能。
Oracle BI Answers 和 Oracle BI Interactive Dashboards不提供所见即所得的环境。当用户在浏览报表结果的时候，不能同时编辑仪表盘或报表。如果想修改仪表盘，用户必须返回 Answers。
OBIEE的Dashboard与用户的交互功能比较弱，只支持少量交互控件。
不支持假设分析以及网页不支持向上钻取，只能回跳。
不支持离线仪表盘。
多级安全机制
· 支持LDAP
· 支持SSL
· 通过单点登录和其他任何安全框架集成
· 不用的用户运行同一个报表会得到不同的数据
· 单元格级的安全控制
BO 采用集中的、基于 LDAP 的安全管理机制。整个系统拥有统一的用户管理机制，统一的权限控制机制。并且，BO可以同时支持多种LDAP系统。
在数据安全方面BO能够实现单元格级控制。当多个用户打开同一张报表的时候，每个用户都只能看到与其权限相适应的数据切片。
BO在WEB上还支持SSL加密，确保数据传输的安全性。

在OBIEE中安全性不是集中管理的，必须在不同的组件中进行配置。OBIEE 用户在多个不同的组件中被创建和维护。Answers和Dashboards用户被创建保持在一个元数据库中，而Oracle BI Publisher用户被保存在另外一个地方。当Publisher的用户想获得Answers的访问权限时候，管理员必须把Publisher的用户信息拷贝到Answers的元数据库中。
OBIEE也提供对LDAP和SSL的支持。
集中的企业管理
· 自调整、可扩展的服务器
· 具有监视、审计功能
· 可分析的控制环境
· 统一的管理控制台
BO在WEB界面上为管理员提供了统一的监控和管理平台。
在配置管理界面中，管理员可以配置、管理系统所有的数据源连接、报表样式、输出的打印机等等。
在安全管理界面中，管理员可以统一管理系统中的所有用户、用户组和角色，并为它们分配权限。
在状态管理界面中，BO提供了图文并貌的方式，展现当前系统的状况：如用户的会话状况，报表服务的请求状况、队列状况，计划作业的执行状况等。
OBIEE没有提供一个集中的监控管理工具，各种监控功能是分离的。从前的Siebel products有自己的监控工具，而BI Publisher也有自己的监控工具。所以OBIEE系统的管理工作必须分散在两个环境中进行：一个是Oracle BI Server，另一个是Oracle BI Publisher。
OBIEE没有提供一个完整性检查的功能，从而使管理员可以轻易的重命名或者删除一个已经被引用的报表对象，破坏元数据的完整性。
OBIEE也没有提供一个自动化的工具，能够检测BI系统环境中发生的变化或者存在的不一致性。
灵活的OLAP 分析
· 丰富OLAP分析功能
· 内置统计分析函数
· 灵活的取路径
BO具有强大OLAP的分析功能，比如切片、切块、旋转、上钻、下钻等，所有的这些操作都可以在WEB上通过鼠标拖拽等简单的操作来实现。
BO内置了大量的统计分析函数，使业务人员能够方便的插入计算或进行分析。
BO为用户提供了独特的 Analyze – Then – Query 的数据访问方式，用户可以从Cube中直接钻透到报表。使用户能够按照自己的想法探察业务数据 —— 先分析汇总信息，然后再查看隐藏的细节。
BIEE的OLAP功能在WEB上仅仅通过Answers来实现，而Answers原本的设计目的只是一个即席查询工具，OLAP分析并非它的强项。
用户在Answers中是通过旋转透视表功能来实现OLAP分析功能的，它不能很方便的插入排名计算、插入百分比计算，也不支持任意路径的钻取，用户只能在同一个Hierachy的不同层中进行钻取，另外它也没有向上钻取功能，它的向上钻取功能只能通过IE的后退按钮来实现。
在Answers的操作界面中并不提供右键菜单，用户不能在表格或图表中通过右键菜单进行快捷的操作。
另外，在Answers的旋转透视表中，它将页面分成操作区和展示区，操作区列出了报表用到的维度、度量，展示区用来显示报表的内容。用户不能直接在显示数据的报表中进行鼠标拖拽等操作，只能在最上方的操作区进行鼠标拖拽的操作，也影响了操作的方便性。
与MS Office无缝集成
· 支持任何Office产品 (Excel, PowerPoint, Word)
· 利用所有的报表及报表对象
· 创建新报表
· Web与Office之间一致的、可互换的格式化
BO的Office组件允许用户使用Excel、PowerPoint、Word访问报表，还允许用户创建报表。
BO的Office组件还为Excel提供了强大的分析功能。用户可以使用Excel浏览、分析BO的多维数据模型。
另外，它还允许用户在一个EXCEL文件中，使用不同的数据源，创建多Sheet页面、多查询的报表。
Oracle有两个针对OFFICE的插件，一个是Oracle Answers,另一个是Oracle BI Publisher.
Answers 用户不可以使用Excel创建报表，只能查看。
用户可以通过Excel查看Answers reports，但不可以创建。
用户不能通过WORD查看或者创建Answers reports或者Interactive Dashboards。
动态企业仪表盘
· 与企业级BI平台结合的仪表盘
· 交互性的仪表盘。
· 所见即所得的设计要求

BO的Dashboard为用户提供了“所见即所得”的编辑功能。
支持最漂亮的离线分析仪表盘。
强大的假设分析功能。支持FLASH全面优越特性，将来支持HTML5。
BO的Dashboards为用户提供了丰富的交互功能，用户可以使用“多选框”、“单选框”、“滑动条”、“下拉框”等控件，控制仪表盘的现实内容。
Oracle BI 仪表盘的交互功能较弱，对于一些常用的交互控件比如单选框、多选框、滑动条等都不支持。
不支持ANDRIOD移动设备分析。
不支持WHAT-IF假设分析；
用户不能用所见即所得的方式编辑仪表盘，必须从仪表盘的界面切换回Anwsers的界面才能修改仪表盘。
强大的企业级报表
· 支持不平衡的中国式报表。
· 支持多种多样的报表风格
· 导出到Excel、PDF
BO 通过水晶报表CRYSTAL REPORT模块提供专业的报表开发功能，支持不平衡的中国式报表。
是全球企业报表的标准，能提供最复杂的固定格式，中国式的复杂报表。
BO默认提供了6种报表风格供用户选择，另外BO允许用户修改或者添加新的报表风格。
BO的WEB报表可以导出到Excel(2000/2002/2007)、PDF、CSV、XML等格式。
Oracle BIEE缺乏对高度格式化报表的支持，在企业级报表制作方面功能较弱，尤其是不平衡的中国式报表。
Oracle BIEE的Answers报表在WEB页面上可以导出到Excel、Powerpoint、HTML格式。
信息发送和预测
· 广泛的输出形式： Web，电子邮件，MS OFFICE ，打印机，无线设备IPHONE,IPAD,ANDRIOD
· 警告和阀值
· 仪表盘和计分卡
· 门户集成
BO的报表可以通过WEB、电子邮件、MS OFFICE甚至手机终端进行访问。
支持IPHONE,IPAD,ANDRIOD, BLACKBERRY.
用户可以在报表中的定义阈值，当指标发生异常时，报表能够以预定义的方式进行告警，如以高亮方式显示数值等等。
用户可以在Event管理中设置条件来监控数据，在业务事件或者异常条件发生时执行特定任务或通过邮件、短信的方式通知相关人员。
除了发送之外，相关的报警信息也可以集成到用户的Portal页面中。
OBIEE Plus 的信息发送，同时需要Oracle BI Publisher和Oracle BI Delivers两个功能模块。这其实是两个独立的产品，他们拥有各自独立的元数据。Oracle BI Publisher分发服务器用来发送Oracle BI Publisher报表。Oracle BI Delivers 用来分发Oracle BI Answers报表。而Oracle Interactive Dashboards不能使用任何一个工具进行分发。
当用户安全性使用数据仓库身份验证机制的时候，Oracle BI Delivers会限制产生个性化的报表。
Oracle BI Delivers不能发送 Oracle Answers和Interactive Dashboards到打印机,保存文件到网络中的文件服务器。
用户不能使用移动终端比如BlackBerry访问交互式的报表或者仪表盘，Oracle只能发送静态的图片到用户的手机设备上。

第3章 对比BO与Oracle BIEE的常见问题
1. OBIEE是一个统一的、完整的架构，还是一个将并购而来的多种工具耦合而成的平台？
Oracle BIEE是ORACLE将多个收购而来的BI产品简单耦合而成的，作为企业级的BI平台显然它还不够成熟。OBIEE拥有看似统一的多个用户界面、多个服务器和多个存储在平面文件中的元数据，这些缺点都极大的制约了它的可伸缩性。
OBIEE Plus所提供的BI功能需要三个独立的服务来支持。用户访问复杂报表的时候，查询的SQL不是由一个单独的集中的服务器产生的，而是需要两个服务通过两个步骤才能产生。首先ORACLE BI Presentation Services产生逻辑SQL，然后Oracle BI Server再将接收到的逻辑SQL转化为物理SQL。这两个步骤明显有些冗余，直接降低了系统的性能，增大了系统故障的风险。
根据Gartner公司10年的报告，Oracle的对其BI产品和产品线的整合在近期还将继续。有强烈的证据表明，Hyperion的原有用户都在等待和观望，并没有升级到最新版本。在所有的用户调查中，Hyperion用户运行最新版本的比率是最低的。而且报告中还专门提到，Oracle用户反映得到的技术支持不够完善，Oracle在BIEE方面的一线技术专家还不够。
BO 产品是一个统一的、完整的架构，通过一个统一的门户向用户提供各种BI功能，整个系统采用统一的用户和权限管理。
2. OBIEE是否拥有统一的元数据？
OBIEE 系统拥有三个不同版本的元数据：
l BI Server的元数据：存储逻辑数据模型
l BI Presentation Services的元数据：主要存储 WEB目录信息，包括报表、筛选、提示和用户信息
l BI Publisher的元数据：主要存储复杂的企业级报表及其他报表对象的信息。
这些元数据在不同的功能模块间是无法完全共享的。其中BI Server的元数据和BI Presentation Services的元数据只能保存在一个平面文件中，不能存储在关系型数据库中，从而没有负载均衡和数据回滚的能力。
在集群的环境中，保存在平面文件中的元数据必须要通过共享文件系统才能同时被多台服务器所访问。但共享文件系统是无法针对高并发量的访问进行系统调优的，另外平面文件本身也存在大小的限制，进而也限制了元数据的增长。
此外，集群环境中的ORACLE BI SERVER仅仅在重启的时候，才会加载存储在平面文件中的元数据。这意味着想要修改后元数据生效，管理员就必须要重启集群内的所有服务器。这样即使OBIEE在集群环境中也不可能提供7*24小时的高可靠性。
Oracle BI Publisher的元数据不能充分利用来自Oracle BI Server元数据业务逻辑模型。来自Oracle BI Answer的报表，不能被Oracle BI Publisher充分利用创建Publisher报表。在Oracle BI Answers中创建的包含提示的报表，也不能在Oracle BI Publisher中正常使用。Oracle BI Publisher报表不能在Oracle BI Presentation Services Web中被浏览，因为这两个系统的元数据库是完全独立的。
在OBIEE中报表中的提示是存储在报表级别的，这意味这用户创建了一个地区提示，这个提示不能被后来的报表所重用。用户必须为每一张需要相同提示的报表重新创建。这种缺乏元数据抽象的弱点，增加了额外的维护工作和重复的步骤。
BO BI 拥有统一的元数据库，BO BI的元数据可以保存在关系型数据库中，它支持三种最常见的关系型数据：DB2、ORACLE和MS SQLSERVER。在BO中，提示、筛选等报表元素都可以作为一个对象保存下来，在多个报表引用。这种可重用性提高了开发效率，减少了维护工作。
3. OBIEE 能否在一个统一的架构上，通过一个统一的界面提供各种BI应用？
在OBIEE中不同组件的用户界面也不是统一的，它们看来像是一系列松散连接的WEB组件。这些不同功能模块的界面布局、操作方式、下拉菜单都不太相同。毕竟这些工具都是通过兼并或收购的方式获取的，彻底的融合还需要更多的时间才能完成。
在OBIEE中如果要创建复杂的企业级报表，就必须使用Oracle BI Publisher，这个工具不属于从前的Siebel Business Analytics平台，而是来自于Oracle e-Business解决方案，这就意味着它与Answers(即席查询和分析工具) 以及Dashboard很难统一起来。Answers和Dashboard的界面是由Presentation Services生成的，而Oracle BI Publisher只是通过一个链接与Oracle Presentation Services生成的WEB界面整合起来的，Oracle采用这种方法使这些模块看起来像是一个统一的界面。
Oracle BI Publisher 拥有独立的管理工具、元数据和维护方式。Oracle BI Publisher 用户如果想要获得Oracle BI Presentation Services 界面的访问权限，管理员就必须先把 Oracle BI Publisher 元数据库中的用户信息复制到Oracle BI Presentation Services的元数据库中。也就是说，用户安全必须设置两次，一次在Oracle Web Catalog(BI Presentation的元数据)，另一次在Oracle BI Publisher元数据中，并且这个操作不能通过Web界面来完成。冗余的用户设置不仅增加了额外的维护工作，也增加了出错的几率。Oracle BI Publisher 的设计界面并不是完全基于Web的，报表设计者通过一个插件把Microsoft Word 作为BI Publisher文档模板的设计工具。
BO BI是在统一的架构上，通过完整的、统一的界面向用户提供各种BI功能的，无论是即席查询，还是多维分析或是仪表盘，都是在同一个风格统一的Portal中进行的。用户不会像使用OBIEE一样明显感到是在不同工具间切换。
4. OBIEE Plus 能否为企业提供7*24小时的高可靠性？
OBIEE 宣称通过可以集群实现7*24小时的高可靠性，但事实上它的集群功能非常有限。Oracle BI Server 集群并不是全部被激活的对等配置，而是需要一个集群控制器监控集群的活动。实际上，它是一种主从集群的模式，主服务器会安装“集群控制器”组件，它负责将用户的请求分配到集群中的BI SERVER上。因此，Oracle BIEE只允许非主服务器失效，如果主服务器失效，它将会影响到整个集群的服务器。这种集群模式只给企业提供一个“单点故障”，并不能提供一种非常有效和可靠的解决方案。
因为Oracle BI Server元数据存储在平面文件中，多个Oracle BI Server必须通过共享文件系统才能访问它。共享文件系统不像RDBMS关系型数据库系统那样健壮，很难应付大并发的用户同时访问元数据库的情况。同样，共享文件系统也不能有效的进行线程管理、负载均衡和自动备份。
管理员必须为集群中的每一台Oracle BI Server 服务器手工修改配置文件的参数，而且，为了确保在群集中元数据库的正常升级，Oracle BIEE的管理员还要确保所有Oracle BI Servers中的时钟是同步的。这不仅增加了维护的负担，也增大的出错的可能性。在群集环境中，系统管理员必须通过“Master”服务器节点修改Oracle BI Server的元数据库。为了使元数据的修改生效，群集的所有节点都必须重启。
由此看来OBIEE的集群功能不仅不能提供7*24小时的可靠性，而且还会带来额外的维护工作。
与Oracle相比，BO具有智能的集群功能，不需要额外的第三方软件的设置和维护，系统是作为一个统一的逻辑平台共同工作的群集。相比Oracle BI EE使用的群集架构，BO的群集是一个全部激活的对等配置，并且这样的构建最小化了资源费用，确保了完全的故障恢复，并且不会产生单点失效。
5. Oracle BIEE 是否具有企业级的伸缩性，能否满足高并发高负载的需要？
Oracle Presentation Services的实现技术限制了OBIEE平台的伸缩性。在Oracle BIEE中SQL的产生和数据的处理是在两个层面中完成的。第一步处理是在Oracle Presentation Services Server上完成的，第二部处理是在Oracle BI Server上完成的。Oracle Presentation Services 功能模块首先产生Oracle Answers和Oracle interactive Dashboard 的用户界面，并且将用户的请求转化为逻辑SQL。Oracle BI Presentation Services把Oracle BI Server 作为一个ODBC客户端，将生成的逻辑SQL提交给它。Oracle BI Server 负责将逻辑SQL转化为物理SQL，并提交到数据库端去执行。在我们看来，这两个步骤其实是冗余的，再高并发的情况下会影响到系统的性能。
Oracle BI Server 需要连接到一个 Oracle BI Server 平面文件元数据库，主要存储业务逻辑模型。Oracle BI Presentation Services 也需要连接到一个 Oracle Web Catalog 平面文件资料库。主要用来存储报表定义和用户信息。这两个元数据容器都是平面文本文件，在集群情况下，需要建立一个共享文件系统以满足来自集群内的多个Oracle 服务器并发访问的要求。而共享文件系统不像RDBMS关系型数据库系统那样健壮，很难应付大并发的用户同时访问元数据库的情况。
另外平面文件本身也存在大小的限制，进而也限制了元数据的增长。所以，OBIEE是无法满足企业级伸缩性的要求的。
而BO 是在一个单一的、完整的架构上提供各种BI应用的，无论是即席查询还是多维分析，都是由BO 8 Server 来支撑的，不像OBIEE那样产生SQL都需要两个服务才能完成。BO 的元数据库可以建立在关系型数据库中，它支持三种最常见的关系型数据库MS SQLSERVER、DB2和ORACLE，完全可以应付高并发情况下用户同时访问元数据库的情况。
另外，BO是一个模块化的系统，它为用户提供了各种即插即用的功能模块。客户可以从部门级简单的BI应用开始起步，然后逐步扩展为企业级的全面的BI应用平台。因此，BO 才具有真正的、企业级的伸缩性。
6. OBIEE的Dashboards 是否具有“所见即所得的”编辑功能，是否为用户提供了丰富的交互方式？
当OBIEE的用户在浏览Dashboard的时候，他并不能使用“所见即所得”的方式编辑仪表盘，如果用户在查看仪表盘时想要对仪表盘上的数据项进行修改，他必须先切换到仪表盘的编辑模式，然后选中Answers报表，再切换到Answers报表的编辑器，修改之后保存Answers报表，然后再返回仪表盘编辑模式保存仪表盘，最后重新执行仪表盘才可以看到结果。
OBIEE的仪表盘只为用户提供了有限的交互功能，对于一些常用的交互控件比如单选框、多选框、滑动条等都不支持。
BO的Dashboard为用户提供了“所见即所得”的编辑功能，用户可以直接在Dashboard页面中打开嵌入的表格或者图形进行编辑。BO的Dashboards为用户提供了丰富的交互功能，用户可以使用“多选框”、“单选框”、“滑动条”、“下拉框”等控件，控制仪表盘的现实内容。
7. OBIEE是否为用户提供了友好易用、功能强大的WEB 界面？
大多数业务用户都是通过WEB界面的方式访问各种BI应用的，WEB界面的SF易用性对于系统的快速推广和提高业务人员的工作效率是非常重要的。BO 和OBIEE都提供了不需要下载任何插件的WEB界面，但BO的易用性明显由于OBIEE。
在OBIEE的WEB界面上，无论是Answers 还是Dashboard、Publisher，都没有提供鼠标右键菜单功能，WEB上的操作只能通过页面上方的菜单和工具栏按钮来实现。比如，用户想要在报表中的某一列上执行排序操作，如果表格行数较多，他就必须先把页面滚到到最上方，然后在上方的操作区中点击该列的排序按钮。而BO在所有的功能模块中都提供了丰富的右键菜单，如果用户想要执行排序操作，只需选中该列，然后从右键菜单中选择“排序”即可。其他的操作比如插入计算、钻取、隐藏、查看属性等功能，都可以通过右键菜单快速操作。
OBIEE的OLAP分析功能主要是通过Answers中的“旋转透视表”透视表来实现的，用户使用“旋转透视表”进行分析的时，并不能在展示数据的交叉中进行鼠标拖拽的操作，只能在页面上方的操作功能区中进行鼠标拖拽的操作。另外，OBIEE的报表也不支持锁定行表头列表头的操作。
而在BO的WEBI和EXPLORER中，用户进行OLAP分析时，可以直接在交叉表中通过鼠标拖拽进行操作，另外丰富的右键菜单也给用户的操作带来了很大的方便。
BO的OLAP分析功能同时提供了WEBIN和客户端的操作方式，而且WEB和客户端的功能完全相同，用户可以根据自己的偏好选择操作方式。OBIEE的Publisher也提供了WEB和客户端的操作方式，但它的WEB功能远远弱于客户端的功能, 这也是许多用户不愿意使用WEB界面，仍然坚持用Desktop设计仪表盘或者报表的原因。
8. Oracle BIEE由于产品本身的限制，对数据仓库模型的要求比较严格，只支持标准的星型模型和雪花模型， BO 是否也有这方面的限制？
Oracle BIEE 对要求数据仓库的模型要求比较高，只支持雪花型或星型模型，而且要求表之间固有的主外键关系必须设置好。Oracle BIEE将数据仓库的表结构导入系统后称为物理层，用户在物理层的基础上再开发逻辑业务模型(称为逻辑层)。在逻辑层中，BIEE对逻辑表之间的关联关系要求同样严格，任何一个逻辑表都必须建立主外键关系，系统是根据表之间的关系来判断是维表还是事实表。如果在聚合表中本身包含了维度信息和度量，不需要与其他表关联，那也要将该表分别映射为一个逻辑维表和一个事实表，这样才能生成正确的查询语句(标准的星型结构)。
BIEE对模型的严格要求限制了系统的灵活性、增加了开发周期、对模型维护人员在数据仓库方面的知识要求比较高。
在这方面BO就要灵活的多，我们不仅支持雪花模型、星型模型，还支持混合模型。我们并不严格要求设置数据仓库中表之间的主外键关系。用户可以在导入的物理模型的基础上创建逻辑模型，也可以直接使用物理模型的字段去创建报表。
在实际生产环境中，用户经常会有一些临时性的报表需求，只要求简单的报表展现。对BIEE的开发人员来说，他需要按照OBIEE的产品要求，按照新需求先在数据仓库中设计表结构，然后导入物理模型，最后创建逻辑模型。 BO开发人员可以直接把应用系统中相关表导入到BO中，然后直接使用物理模型的字段创建报表。BO既能满足用户规范化建模的要求，也可以快速的应对灵活的需求。
9