MicroStrategy和BusinessObjects实现商务智能需求解决方案的对比.doc

MicroStrategy和BusinessObjects实现商务智能需求解决方案的对比本文讨论了成功实现BI的主要需求。在每个需求的后面，MicroStrategy 和 Business Objects各自都提供了与此需求相关的、直接对比的实现和策略。注意：本文是为那些希望直接、公平比较的读者组织的，围绕以下主要主题：i. 伸缩性ii. 安全iii. 部署能力（包括维护能力）iv. 分析能力v. 易用vi. 性能注意：此次分析是以对MicroStrategy 7.1平台和Business Objects 2000套件的考察为基础的，其中Business Objects 2000套件包括BusinessObjects 5i, WebIntelligence 2.6, Set Analyzer 2.0, Broadcast Agent 5.1, Designer 5.1, Supervisor 5.1, Developer Suite and Auditor。I.伸缩性1. BI需求:纯web架构为互联网建立的纯web架构，提供了web报表制作，安全性，性能和为升级web部署所需要的web标准需求。Web的伸缩性（就像定义的那样，有大量的并发网络用户浏览统计报表和完成深层次的交互分析）对要求很高的web报表制作、交互式的OLAP分析和外网解决方案是非常必要的。Web伸缩性要求在展示/接口层有一个纯web架构（例如所有的HTML接口-不包括客户端的插件，XSL格式等）和应用服务层（如真正的web缓存、 XML信息传输等）。那些需要危险和昂贵的客户端下载、没有真正的应用服务器功能，或者要求那些对内存消耗较大的client/server 中的桌面程序运行在Web服务器上的工具集，极大地限制了Web的可伸缩性并且不适合于互连网的部署。MicroStrategy满足以下需求：MicroStrategy的纯web架构为企业内外的用户扩展OLAP分析和web报表制作提 供了所需要的伸缩性。MicroStrategy 7 Web 在瘦的 all-HTML web接口提供了完整的特色特性；DHTML提供了必要的终端用户的交互行为，XSL提供了高度格式化、用户化的报表制作。MicroStrategy的 以XML为基础的信息传递和真正的应用服务器（确保在展示层、应用层、数据层之间真正的分离）通过在网络和web服务器最小化负载来提供很高的web用户 伸缩性。BO的方式：BO由于没有纯web架构，需要通过在网络和web服务器上传输很重的负载，这严重限制了web用户的伸缩性。没有真正的web应用服务器功 能，无异步处理的能力和在WebIntelligence上运行耗时的client / server程序的架构意味着每个并发web用户需要大量的内存，明显限制了web用户的伸缩性。BO的客户和合作伙伴曾提到由于要为每个并发用户提供全 功能性的web报表制作，需要运行多个BOManager 和 BusinessObjects 桌面进程，这使得每个CPU上最多有7-9个BO的 web并发用户。注意：对MicroStrategy来说在同样的条件下每个CPU server上却能运行45-50个并发的web用户。同样的问题是，BO由于依赖web需求，需要有大量的客户端下载。对web用户来说，浏览、修改一个BO 桌面的公司文档或创建一个WebIntelligence报表需要过分地依赖于大量的客户端插件，这表明BO在支持web方式的企业级BI的能力是有限 的。Web用户对桌面报表的任何的存取（即使只是简单的浏览）都需要在web浏览器机器上下载某些程序。如果没有客户端的插件，web用户将无权使用BO 桌面报表，将只有有限的报表生成和编辑能力，不能分成各个等级，只能支持很少的计算类型（sum, count, min, max, percent）并且只有有限的钻取能力。2. BI需求: 数据容量伸缩性由于企业收集大量事务级和客户为中心的数据，导致了数据库的爆炸式增长，而且互联网把BI扩展到企业内外的用户，因此把应用部署在TB级的平台上是十分必要的。我们应该注意到，即使以很小数据量开始的部门级的应用，也会以指数的方式增长到BO的分析范围不再适应基于桌面的cube。真正的数据伸缩性要求能利用数据库来加强数据处理的第三代ROLAP架构，和对中间层上的200多个分析函数应用进行多维分析的引擎。通过反复利用数据库 和应用服务器来最小化网络流量，确保在优化的平台上进行处理。那些主要利用数据库来进行简单查询或在本地桌面做大部分处理的工具，由于要将大量数据复制到 每个桌面上，增加了网络的负载。更严重的是，它的结构对摘要级别的分析是有限的，因为在这样的结构里，分析要受越过网络被复制到桌面 cube中的数据量的约束。MicroStrategy满足以下需求：MicroStrategy的第三代ROLAP架构，在容量上很容易能达到TB级或一个数据库平台能存储的数据 量，这是通过以下方式实现的：反复地在优化的基于server的平台、数据库和MicroStrategys Intelligence Server中执行分析。根据定义，假定BI平台能够像MicroStrategy 7那样产生高度优化的基于平台的SQL，数据库技术不断扩展并且将是一个理想的场所来完成大容量数据处理。MicroStrategy中的 Intelligence Server能进行多维分析，比如能利用各种各样的OLAP函数，执行那些不能被数据库高效率处理的类似于Cube的切片、切块分析功能。BO的方式：由于容量的限制，甚至典型的cube爆炸问题也不会发生。基于桌面的处理和cube结构是BO的先天的缺陷，因为大尺寸的cube是一个网络 上的瓶颈，包括对cube大量手工的维护和要求大容量硬盘空间。正如同所定义的那样，跨过网络复制到桌面内存的数据量从根本上限制了cube的大小，并且 需要在原本就有限的机器上处理cubes。注意：数据的伸缩性消极地影响着那些存取桌面报表的web用户，因为不仅需要下载报表结果，还必须把相应cube里的数据下载到他们的桌面。另外，即使那 些基于Webintelliigence、存在于web server里的cubes也必须和对应的语义层定义一起，跨过网络被单独地加载到Web Server内存中，这样便限制了能进行并发分析的cubes的数量。阻碍BO数据伸缩性的其它结构化缺陷还包括：. 大量来自桌面和web并且对数据库不可控制的直接连接，最终会摧垮数据库. 使用没有优化的SQL，导致了数据库性能的降低. 聚合能力的限制，导致不能进行大数据量的聚合. 有限的共享缓存使得大量的查询要运行在实时的数据库上. 没有应用服务器功能. 绝大多数据处理在本地执行，部分在web server box上执行，更少量在数据库上执行；BO过分依赖于本地却很少利用数据库来进行处理。3. BI需求:真正的应用服务器真正的应用服务器必须位于任何一个多用户BI环境的中心。应用服务器为了高效率传送数据，不仅在展示层、商业逻辑层和数据层提供了有效地分离，而且要提供排队等待、优先级控制、缓存和调度等功能。应用服务器应该能够给适合的平台分发所有的处理，以使重复地在数据库和中间层分析引擎之间的处理对用户来说是完全透明的。应用服务器也应当提供如下功能： 多级缓存，保证用户在安全约束下进行优先处理。注意：由于要求大量的cube管理，在cube环境中应用服务器功能 显得特别重要。一个真正的平台（功能上具备一个应用服务器）与多种不同工具共存于同一服务器方式之间有明显的不同。提供重要的文件服务却没有真正的应用服务器功能的环境是不可伸缩的，因为每个终端用户的请求是独立地被提交到数据库中，没有进行全面的系统控制和优先处理。MicroStrategy满足以下需求：MicroStrategy 7中的Intelligence Server是一个基于组件的应用服务器，提供了高度伸缩性环境所具备的必要控制和应用系统管理，如下所述： .在理想平台上完成多维分析处理（通过Intelligence Server或数据库中的200多个分析库）真正共享的多级别的缓存完全与Intelligence Server中的安全模式进行了集成通过连接池、粒状数据和应用控制来智能地管理所有的用户对数据库的连接通过排队等候和线程管理，对所有请求动态分配优先权系统用法和性能调整工具群集管理和负载均衡通过动态资源分配进行自我调整的结构使组件满负荷工作BO的方式：BO 2000主要是基于桌面OLAP(DOLAP)处理。虽然BO 2000包含两个基于服务器的产品：WebIntelligence 和 Broadcast Agent，但是真正的应用服务器功能对文件服务的支持在web环境中是有限的，并且在桌面环境中根本不存在。虽然BO 中的方式可能确保在server机器（与桌面比较）上确实执行一些web处理，却没有与之对应的系统管理和控制。WebIntelligence主要是能为cubes充当索引和存储设备的报表或文件服务器；提供了一些有限的协调能力和最小限度的应用管理。当BO的 web用户需要存取一个创建在桌面上的报表时，缺少应用服务器的弊端便显现出来了；为了实现两层结构不能处理的功能，数据和报表必须被下载到web用户的 桌面上。BO缺乏应用服务器意味着：1. 没有报表的排队等候/区分优先次序2. 没有异步处理3. 不能取消来自web的数据库查询4. 非常有限的查询管理。注意：仅有的能被利用的系统资源管理包括数据库返回的行数和查询执行时间5. 没有对应用层和展示层进行分割-缺乏表现上的灵活性并且不能有效地传递信息。6. 最小限度的系统管理和审核功能。注意：BO Auditor主要是在基于网络上的受限；两层桌面处理是无审核能力的。7. 不能对报表对象管理；在用户和环境中不能动态移植报表对象8. 有限的对微型立方体的管理能力和更新能力导致频繁的微型立方体扩张。由于所有的ad-hoc请求会产生新的微型立方体，微型立方体数量的显著膨胀导致数据的大量复制和对同一数据多种不同版本/解释，9. 没有与系统管理软件集成10. 没有共享的缓存11. 没有cube级别安全性12. 在BO web产品和数据库之间需要建立直接的联系，这是一个巨大的安全缺陷13. 有限的两层桌面 用户和数据仓库跟踪14. 有限的web并发用户，由于大量客户端运行的BusinessObject必须运行在web 服务器上（需要消耗大量内存）15. 有限的均衡负载4. BI:需求. 支持Unix一个开放的BI平台必须能够在多个数据库和操作系统平台上运行，以确保用户和数据的可伸缩性。数据库平台应该支持所有主要主流的、基于server的关系 型数据库，包括那些运行在Unix和Windows NT上的，开放的操作系统应当支持包括在Unix 和 Windows NT上的web服务器和web应用服务器。MicroStrategy满足以下需求：MicroStrategy 7中的Intelligence Server提供对Unix伸缩性的支持。另外，数据仓库（在这里要进行大量处理）能存在于任何平台（Unix,NT）。MicroStrategy近来 给MicroStrategy SDK增加了一个基于Java的Web API，这样便可在多个平台（包括IBM AIX, Sun Solaris 和 Microsoft Windows NT）和web应用服务器（如IBM WebSphere, iPlanet, and Apache Tomcat）上定制MicroStrategy 7的web开发。另外，为了满足那些运行Unix的公司的需要，用来支持更多应用系统的Java and Unix的扩展能力，会使得对系统集成商和增值代理商来说，快速开发和集成MicroStrategy中的BI平台到他们的产品中去变得更加容易。BO的方式：虽然BO对他们的一些基于服务器的产品提供了Unix支持，但是我们有必要了解其中的某些限制： .在客户端没有支持Unix的工具不是所有的服务器组件都能运行在Unix机器上（Broadcast方式只能运行在Windows环境中）BO对Unix的支持根据产品和Unix版本的不同而发生变化；对HP-UX的支持要明显落后于对Sun Solaris的支持Unix版本没有与NT版本提供提供同样的功能，不稳定并且还丧失了某些功能（例如报表更新等）5. BI 需求:主动信息分发随着BI的普及和用户对信息更加实时地存取，由高度升级的信息分发服务器通过web、无线或者语音传递给不同用户群的主动信息分发显得特别必要。以用户指定的多种信息展示方式，给不同类型设备进行的信息传递，把BI应用系统价值扩展给那些连接或断开的用户。虽然有多种方法把信息传递给各种媒体，但要考虑的关键方面有：1. 结构本身内在的伸缩性和稳定性2. 自我诊断的程度3. 向不同类型的设备传递高度格式化信息的支持MicroStrategy满足以下需求：MicroStrategy是第一个认可主动信息传递需要的BI厂商。以1998年的Broadcaster产 品为开端，还有近期新近命名的Narrowcast Server，MicroStrategy使得通过各种媒体如：email、传真、呼机、手机，主动传递高度个性化的相关信息成为可能。该功能是系统内嵌的并且不需要任何定制代码。用户定制他们想收到的信息、条件，例如数据中的异常或者是基于事件的标准和设备类型。结构被设计成从MicroStrategy 7 Intelligence Server和外部信息源中接受个性化的内容。从多种来源中获得的信息可能会出现在MicroStrategy Narrowcast Server的输出结果当中。数据源的例子包括从ERP系统中获得的XML内容、从内容供给者和入口处获得的ICE内容，或者其它的非关系型的内容如：平 面文件、图片等等。基于XML的结构确保了完善的内容控制和对任何当前或将来存在的设备的适应性。MicroStrategy Narrowcast Server使你能够以HTML、普通文本、或Excel的形式给任何一个SMTP网关传送商业智能报告，这种功能是系统内嵌的。BO的方式：BO的信息分发是以调度范例为基础的，这样便限制了伸缩和功能的全面性。BO的Broadcast Agent通过使能基本报表调度，被设计成把建立的cube卸载到批环境中去。导致的结果是为了完整的伸缩性而需要很多BO结构中没有的一些特性。例如一 个中间层的、允许一个将被提交到数据库的 全局请求（如从三月获得的销售数据）的切片能力。如果管理员编写VBA宏并且手动地进入所期望的分发列表，BO的报表分发也只能通过e-mail进行；由于BO不提供动态分发列表能力，分发在运行期间不 能被动态决定。尽管如此,报表通常是以邮件附件形式存在的cube，并且必须被保存到当地硬盘，而且只能用BusinessObjects软件查看。大多 数设备支持需要定制的代码-对设备有很少的系统内嵌的支持。II.安全性6. BI需求:全面的多级安全BI的安全方式必须符合安全标准（如LDAP），在多级上被分成粒状（应用系统/对象，用户，传输和数据），能够被集成进现存的安全配置，提供重要的管理。简而言之，真正的网络安全要求在所有级别都是全面的和易处理的。更重要的是，绝对无安全漏洞。MicroStrategy满足以下需求：MicroStrategy 7安全模式包含必要的广度和深度，通过internet允许BI应用系统对员工、合作伙伴、供应商和顾客进行安全部署。MicroStrategy产品是 通过以下方式实现其安全性的：应用功能级别的特权的使用、报表对象级别上的访问控制列表、安全过滤器、连接映射和在数据级别上对数据库视图的支持。另外， 用户级别的安全是通过MicroStrategy与NT、LDAP的集成实现的，传输级别的安全是通过128位的SSL传输、128位数据加密或在web 服务器上无数据库连接的双防火墙配置来实现的。MicroStrategy 7基于配置文档的安全性能确保了平台和传输体系中的每一部分都是安全的，都被严格管理。另外，MicroStrategy对工业标准的安全尺度的实现确保了MicroStrategy的安全模型能与当前存在的任一安全方式进行集成。BO的方式：虽然BO有一个多级安全模式，但它们缺少一个综合方案。他们不仅没有关键的安全部件，它们的安全架构也存在危害公司资产的严重安全缺陷。BO 有大量的基本安全隐患（如WebIntelligence直接与数据库相连，大量使用ActiveX和Java applets）和安全漏洞（如对SSL非常有限的支持，不能直接进行数据级别的安全）。BO的安全性需要大量维护，因为安全必须用多种工具和接口进行安装和维护，如BO中的 Supervisor和Designer工具。虽然BO提供了一些数据级别的安全性，一个SQL WHERE条件子句对每个用户来说必须书写，这完全限制了数据级别的存取。这需要大量管理，如果漏掉了WHERE子句。III.部署能力7. BI需求:从一个接口完全集成BI一个单独的BI接口（从桌面或web接口能进行查询&报表生成和全部的OLAP能力）最小化了培训要求、软件费用并且对所有终端用户进行支持。大量BI工具要求高级别的管理员来安装和维护，这导致了购买者的大量花费。MicroStrategy满足以下需求：MicroStrategy提供了桌面方式和web方式的集成的全功能性的BI，完整的BI功能包括静态报表制作，报表分发，查询和报表制作，OLAP分析，集分析并且从一个集成的接口利用数据挖掘，MicroStrategy 7 Desktop允许用户从一个单独的接口，通过MicroStrategy Architect, MicroStrategy Agent 和 MicroStrategy 7服务器管理之间紧密的集成来进行设计、创建、维护、运行和监视分析MicroStrategy 7 Web提供了与客户端工具相当的全部报表、查询、OLAP和高级分析功能。MicroStrategy 7 Web版通过三个纯Web版本（Web Analyst, Web Reporter and Web Viewer）提供了完整性能（同MicroStrategy Desktop同样的功能）的web接口。终端用户只需学会这样一个接口便可以了：能支持BI所需的从静态web报表制作到完全交互式的OLAP分析。 MicroStrategy允许终端用户从简单的查询和报表制作开始，随着需求的发展，很容易地便可以用同一接口进行高级分析处理BO的方式：BO 桌面版和web版的BI都需要使用大量工具，每一个都有自己的一套接口、元数据、报表制作范例和报表制作功能。虽然BO工具组很多，但是提供的工具十分零 散；BO的基于桌面的BI典型地至少需要使用两个单独的工具；BusinessObjects, Set Analyzer 和Business Miner同样如此。由于Set Analyzer 和 Business Miner在web版没有被嵌入，BO的基于web的BI仅能够使用WebIntelligence 和 BusinessObjects 5i。BO的工具分散对终端用户和管理员产生了消极的影响。终端用户需要学习和使用大量的接口、报表制作范例和报表制作功能，例如，分析中心围绕着Set Analyzer中的原始资料和主题，并且以不同的报表制作范例和一套、与使用“类”和“对象”的BusinessObjects完全不同的元数据为基础 的。另外，为了正确地共享和发布文档，终端用户需要知道别的用户有哪些工具，这给管理员产生了很大的消极影响，管理员必须为多个工具创建和支持报表制作环 境，包括手动地集成各种工具中的元数据。由于用户的需求很容易超越一个工具所能达到的，之后必须产生一个新的工具，这样变动的BI请求导致购买者大量的花费，其结果是重叠的工具功能要求终端用户 知道在什么时间使用其中的一个。由于BO终端用户经常以BusinessObjects开始。BO的web用户以WebIntelligenc开始，但是 他们很快便意识到当需要超出简单的报表分发时，便需要8. BI需求:单独的元数据层BI以单独元数据层为基础的开发，使用完全可重用的报表制作对象（对所有的接口、用户间的共享、组和报表制作环境来说都可利用），这样便导致了快速的开发和更加容易的部署。MicroStrategy满足以下需求：MicroStrategy 7建立在统一的结构（在所有的产品中间有一个公共的元数据层）之上，在这种结构中所有的报表生成对象被存储在一个单独的库中，并且对所有用户都是完全共享 和重用的。特别地，MicroStrategy Desktop版创建的报表（所有内部的报表生成对象例如度量、过滤器等）在同一个报表生成范例中，依靠MicroStrategy Web 和MicroStrategy Narrowcast Server而不需要任何手工的步骤便立即和自动地被所有的终端用户使用。报表的共享使可重用性最大化，并且确保系统管理员在接口发生变化或者报表生成从Desktop版移到web版时不必重新建立报表生成对象。另 外，MicroStrategys Object Manager的功能确保了所有的报表生成对象很容易地在用户、组中被共享，在报表生成环境如开发和成品之间被迁移。BO的方式：BO有大量独立的、需要手动同步的元数据库。被BusinessObjects桌面版工具存取的主desktop库使用Designer工 具，然而被Set Analyzer存取的资料库使用Architect工具。由于BO桌面版和web版的报表生成环境没有被完全集成，为了使桌面版的报表对web终端用户 可用，需要手动发布。当web报表被手动地发布到本地用户时，大部分的格式被丢掉了。BO用户必须把各种类型的报表区分开来，因为这些报表是完全不同的对象；“WebIntelligence 企业报表”（在web版用WebIntelligence工具创建）和“企业文档”（用BusinessObjects桌面版工具创建的本地报表）由于它 们没有被完全集成，在功能上差别很大，存储的位置有差别 (一种在WebIntelligence Server和另一种在资料库)，并且他们的可用性也存在差别。Web报表主要是静态的，具有一些简单的ad-hoc报告能力，然而桌面版报表仅仅是提供 本地OLAP 工具期望的功能类型的BO介质。大多数的内部报表生成对象，包括条件和计算（公式、变量等），确实存在于本地，在报表和BO工具间是不可重用的（却鼓吹Broadcast Agent可利用本地对象）并且在终端用户之间是不可共享的。由于BO不具备报表生成对象的运转和移动功能，如果不手工书写脚本来完成内部的报表对象的移 动，完全共享报表是很困难的。缺少一个完整的元数据层意味着：对BO 图解对象的改变要求受影响的对象从所有的相关报表中手工移走，被改变的对象则需重新装入。缺少影响分析功能意味着没有办法来决定哪一个具体的报表和/或报表生成对象是受schema的改变影响的。9. BI需求:灵活的基于部件的BI平台一个基于部件的BI平台能够通过开放的SDK展现所有的功能，能很容易地被扩展和集成到现存的每一个主导产业的分析家组织近来已经公布了BI平台标准。虽然要求和标志（如“下一代的商业智能”，“企业报表制作”，“BI”平台等）有些细微的不同， 实质同样都是应用于BI平台的要求很高的标准。The Gartner Group在2000/3/2提供了一套有用且严格的标准，如下所述：1. 现代化的平台结构2. 第三方扩展3. 厂商对各种方案的支持4. BI特色The Gartner Group定义是“BI平台提供一整套工具来对所有BI应用系统进行创建、部署，支持和维护。”MicroStrategy满足以下需求：MicroStrategy作为一个BI 平台始终根据The Gartner Group的标准进行分类并且在2001/5/10 的“BI Platforms Magic Quadrant”被Gartner认做最高级别的完善版本。MicroStrategy 重新构造了它的整个产品线，提供BI平台所要求的、基于组件的开放性和分析混合。这意味着MicroStrategy 7平台除了能够建立定制的应用外还能够提供静态报表制作、用于复杂OLAP的查询报表分析，either vertical specific or integrated with and into other technologies and infrastructures.对组织内外所有类型的BI来说，只有真正的平台才能被设计成为企业级标准。BO的方式：BO从来都没有被The Gartner Group归类为平台提供者。对Gartner标准的不支持说明在2001/5/10的Gartner BI Platform Quadrant release上，它们没有被列出。虽然BO通常被认为是一个强大的BI工具集，但它只不过是一个对DOLAP，HOLAP和ROLAP工具松散的集成集，并不是以基于组件的架构为基础的。由于BI套件是允许终端用户做简易分析或者基于有限的数据库容量或桌面支持的cubes之上进行报表制作的工具集，他们主要是一个部门级的方式。10. BI需求：完全开放的web方式和桌面方式的 BI结构BI平台，通过它可以展现所有桌面和web方式的报表制作、分析和管理功能，需要定制的接口和应用系统功能或者把应用系统嵌入到当前存在的共有的或技术结构中去。简易地把BI应用系统嵌入到现存的框架的开放性和能力，不仅需要展现所有的功能，而且还需要一个能提供包括全部的文档和大量程序例子的完整的软件开发包（SDK），MicroStrategy满足以下需求：包括完整的Java Web 和 XML API的 The MicroStrategy SDK，提供了一个使开发者能够集成和扩展的开放的结构，并且通过一套丰富的、展示平台的所有功能的API库来充分地利用MicroStrategy 7平台。基于标准的结构如HTML, CSS, XML 和 XSL，确保了BI的展示是能够完全和简易地定制的。另外，MicroStrategy对MDX的支持使得即使不是MicroStrategy的产品如Cognos PowerPlay 和 Excel 2000也能够对MicroStrategy 7平台进行存取。BO的方式：由于BO提供了有限的web API（如无XML API），它便不具有所有web功能的真正的web可定制化能力，而且工具集很难嵌入到当前的应用系统中，虽然也允许有限的应用于存在于应用系统的logos和图片基本定制BO确实有一个基于桌面的API，但它主要是集中展示报表制作功能的，而不是管理的或其它非报表制作功能。11. BI需求：快速部署真正的以web为中心的应用系统能够被快速地建立和部署并且对终端用户环境不产生影响。语义层和报表环境应该很容易被建立并且必须利用现存的数据模型和报表制作结构。桌面 部署耗费由于集中的数据库连接和管理而被最小化。MicroStrategy满足以下需求： MicroStrategy中的Project Builder工具允许终端用户通过向导界面创建新的报表制作项目。完全利用初始的项目报表创建，MicroStrategy Architect是一个能为TB级的应用系统建立语义层的功能强大的工具。MicroStrategy Architect支持所有的数据仓库模型和所有主流数据库平台，能够扩展现存的架构特性如：Dimensional 和 Fact Extensions.系统管理员的负担被最小化，因为与BO相比，根据安全配置文档，MicroStrategy终端用户能创建他们自己的与所有用户共享的完全可重用的度量和过滤器。由于最小限度的安装需求（无基于桌面的中间件连接安装，无plug-ins 或applets下载），MicroStrategy的桌面 和 web部署变得非常容易。BO的方式：虽然BO Designer同样是一个建立语义层的图解设计工具，但他要求系统管理员熟知数据仓库中表的结构，数据库和SQL设计规则。特别地，为了安装 BusinessObjects环境，系统管理员必须定义一个universe，包括定义条件、度量和钻取路径，然后手工地查看连接路径，为每个计算定义 所有可能的集成路径（这个麻烦的过程共包括6步）。例如：在BO中利用聚合表需要：每个度量2-3个小时的作业并且包括下列步骤：1. 定义聚合表并且手工与所有相关表相连2. 定义所有可能的表，在其中完成计算并且在每个度量内部以尺寸降序方式列出表3. 相对于其它所有的报表生成对象，定义所有可能的不兼容性BO部署的最大的问题是大量客户端的plug-ins和applets，它们限制了浏览器和防火墙的兼容性。另外，在每一个BO 桌面上需要安装和维护某些类型的中间件连接层，这增加了安装过程的复杂性。12. BI需求：易维护和管理一个对所有用户和报表制作提供详尽管理和追踪能力的平台，产生的结果是购买者更少量的花费。集中的管理能够通过一个单独的接口进行MicroStrategy满足以下需求：就MicroStrategy 7来说，系统管理员仅仅需要部署一个集成的环境，这是由于MicroStrategy 7 Administrator为开发、部署和维护跨多个平台的多个应用系统提供了一个集成的环境。Object Manager，作为MicroStrategy 7 Administrator的核心部件，推动了完善的生命周期管理，这样报表生成对象很容易地在跨过开发、测试和产品环境被迁移并且在用户、分组和项目之 间被共享。完善的用户和数据仓库的监视，包括动态的自我调节，保证了最高性能和生产量。BO的方式：BO方式需要单独工具和应用系统安装 ，没有所需的集中式管理工具。BO环境由于有很多的安装、配置、管理的工具和安装的应用系统，需要很强的维护性。由于隐藏了所需的维护（维持一个微型立方体环境而不进行所需的微型立方体管理）和监视工具，BO对购买者。终端用户必须手动地对微型立方体s和相应的报告 文档“建立许多/部署一次”。由于终端用户在桌面上不能创建可重用的、在sd-hoc报表生成期间别的用户能利用的计算和条件， 他们需要依靠系统管理员创建可重用的BO Measures和条件并把他们添加到BO的一个中央存储库中。13. BI需求： 多数据源存取在一个单独的展示层，存取和呈现多数据源的能力有时需要不同的数据源。虽然大多企业范围的数据继续被集成进一个共同的数据仓库或者数据集市，为了分析和展示的目的，仍然很有必要存取不同的数据源。MicroStrategy满足以下需求： 为了分析和展示的目的，MicroStrategy支持多数据源的存取。MicroStrategy Narrowcast Server支持在一个单独的展示层从多数据源中显示数据。MicroStrategy 7.1 Intelligence Server为了存取不同种类、分布式数据源，能够支持IBM的DataJoiner并且MicroStrategy 7 Web能够存取包含任何关系型和非关系型内容的文档BO的方式：虽然BO确实支持在一个报表中多数剧源的展示，但BO不支持在一个单独的报表或cube中对多个不同类型的数据源的分析。BO能够在一个单独 的报表文档中从多个数据源显示数据，但除了能跨过数据源进行一些简单的计算外，不能以任何有意义的方式从多个不同的数据源集成分析。由于用到不同种类的数 据存取， BO不能在同一个SQL内存取多个不同的数据源类型而使用MicroStrategy 7.1 和 IBMs DataJoiner却可以实现。其结果是，BO经常推荐一个相关产品作为它的多数据源存取的一部分。即使通过连接universes，对同一数据源类型进行多数据源分析是可行的，它也需要安装时间并且有一些限制。由于一个BO universe仅能包含一个单独的数据库连接，大量universes（包括universe中每个class）连接。如果对每一个报表的所有的 classes和每个钻取路径没有被正确连接，由于BO引擎不知道怎样连接classes 和 objects，不知道数据已经被错误地计算，这样用户很容易地便得到了不准确结果。所有转换和手动地连接数据所需的步骤基于连接数据计算类型，并且两个主要的计算类型（formulas 和 variables）不能被连接使用一个gateway产品或者把数据从多个源复制到一个不可重用的私有cube中去，是产生同样结果的两个不同的方法，在BO中如果需要每次转换和连接数据到一个备用的 cube14. BI需求：基于价值的定价客户和合作伙伴需要灵活和一致的定价，这样对部门级的部署特别具有吸引力，对适当提高定价的企业级的应用来说，花费是合理的。MicroStrategy满足以下需求： MicroStrategy以用户和CPU为基础，提供了标准的、公开的定价。基于CPU的定价，MicroStrategy为企业级的部署提供了更低的价格并且能支持无限量的用户。BO的方式：BO定价变化很大，不是标准的并且不适合于企业级的部署。虽然BO推荐的定价对部门级的部署（对10-25个用户许可）特别具有吸引力，但不 适合于企业级的部署。BO定价差别很大，特别地，对内网和外网可指定每用户，对外网却只能指定每个服务器。另外，BO定价是保密的，根据顾客不同差别很 大。15. BI需求： 24X7世界级的技术支持能够对终端用户和合作伙伴提供的强大的支持，确保能够配置高质量的应用系统，使商业价值最大化。世界各地的客户能够在任何时间、任何地点获得回答和解决方案。MicroStrategy满足以下需求： MicroStrategy优先考虑的是客户的成功，世界的任何人都可利用的高级技术支持24X7使我们的客户满意率大体保持在85-90%范围上。BO的方式：BO已公开承认提供很弱的客户技术支持。根据2000/10 BO在BOs User Conference 2000上发起的对目前BO客户的调查，客户技术支持满意率大体上在30%，30%的客户满意基于帮助标准、持续的时间和产品知识。IV.广泛的分析16. BI需求：在桌面和web上的精密复杂的分析能力能够提供整个范围精密复杂的分析能力（在可控范围内），确保桌面和web能以足够的深度和广度存取数据库的数据。MicroStrategy满足以下需求：MicroStrategy提供了所需的许多优化的特性，在所期望的细节级别上提供了详尽的精密复杂分析，其中包括：. 在MicroStrategy的优化的SQL引擎和中间层分析引擎之间以互动的方式相互协作. 分析库包括超过200个内置的统计、金融和OLAP函数。另外终端用户可以定义他们自己的分析函数并把它们嵌入到平台中去。. 集成的Set Analysis，为了做到这一点，MicroStrategy隐含地使用一个分析的结果集作为过滤器以进行下一步分析，而这对终端用户来说是完全透明的。. 用户定义的custom groups或动态的支持对一个报表多级分析的虚属性. 嵌套的聚合能力在各种动态分析级别上显著地支持运算。所有分析混合或者顺利地发生，如同在重复的处理和嵌套的聚合的情况下那样，或者是用户定义的如custom group定义-不需要管理的支持。另外，所有的这些特性对web用户来说都是可用的，一个有报表创建特权的web用户能利用整个范围的分析混合。BO的方式：BO不支持上面讨论的分析特性，并且由于cube结构的限制和集成的基于cube的处理的固有的缺陷，BO将来也不会支持。BO提供了有限的 分析函数，不支持金融函数并且只支持四个OLAP和统计函数（standard deviation, average, median , variance）更重要的是，BO方式需要任何程度的高级分析（由系统管理员通过BO Designer product安装的预定义的measure）.web 终端用户仅能够使用现有的简单的measures，并且对计算数值进行sum, avg, min, max, count, percentages等运算。这样便丧失了有价值的分析灵活性，也意味着新分析需求要求管理员重建universes。BO仅适合于提供部门级需求的简单的桌面报表，因为在这里仅有少量用户需要基本的报表存取来摘要数据。由于所有的数据必须返回到桌面进行处理，用户不能以有意义的方式分析事务级或以顾客为中心的数据。BO cubes能回答简单的优先次序的问题，但是进一步的分析需要代价很高的没有优化的数据库存取。终端用户的报表制作查询会很显著地改变并且随着用户开始浏 览数据而增长。由于本地内存和硬盘容量的约束限制了微型立方体的大小，用户很有可能把他们时间的40-60%花费在存取数据库上，而不是本地的微型立方体 s。仅有的工作区是用户用来进行尽可能多的pre-select（给微型立方体构造时间是不可行的）或调度一切进行批运行。任何类型有意义的ad-hoc 分析会导致cube爆炸和大量的错误通过网络传到数据库。不支持multi-pass SQL意味着不具有多级分析。BO不能回答你最重要的商业问题，不支持精密复杂分析，有限的依靠手工的metric dimensionality意味着不能进行完整的分析，没有非聚合的metrics说明只能进行有限的清单和帐目的平衡分析，没有快速的有条件的 metrics意味着不能进行所需的允许用户在运行期间选择开始和结束日期的精密复杂计算，不能在分类当中分类意味着不能进行：为我的前5名支持的客户。 许多精密复杂分析仅能通过手工书写SQL获得支持；在分析以另外的查询结果为基础的子查询的地方，需要子查询来回答问题，例如“给我展示一下总消费额大于 平均消费额的所有顾客”便需要大量的SQL编程以确保得到正确的结果。17. BI需求： 细节数据的访问要求能够越过很大范围顺利地对细节数据的存取，以进行富有洞察力的客户和产品分析。虽然分析经常在汇总级别上开始，例如：为了能够确定局外人、异常和趋 势，仍然需要对内部数据深刻了解。另外，为了进行有意义的分析，包括毛利分析、趋势和等级分析，只存取少量的slice级细节的数据是不充分的。特别地， 以顾客为中心的分析要求存取更大范围的数据，例如：虽然了解一个确定产品每天的销售趋势是很重要的，但更有意义的是在那个产品种类范围内与别的一些产品做 同样的比较分析。终端用户对细节数据的访问应该从任一点都可进行，而不需要对计算、钻取路径和分析范围的重复预定义并且不需要以cube形式进行大量数据复制。有效、清晰的对细节数据的访问要求： .利用数据库的伸缩性（包括数据库分割、派生表等）对密切相关的数据进行处理以客户为中心的分析或当使用大量事实表时，需要产生优化的、能够快速存取大容量数据的SQL完全限定在数据库中的所有查询，包括给所有的计算类型或钻取活动实施条件MicroStrategy满足以下需求：由于MicroStrategy具有能够以优化的方式存取TB级数据的能力，用户有权在他们的安全角色确定的适 当的控制范围内使用整个数据仓库。虽然许多查询工具能够检索少量的slice级别的数据，仅有MicroStrategy能够对可用的信息进行足够深度和 宽度的优化存取，例如：某一地域市场经理可能想知道每个地方某个产品的盈利能力和股票影响的分析。另外，MicroStrategy不需要像BO那样，把 多个大数据集复制成一个基于cube的产品，这对管理员来说意味着更少的安装和维护，对用户来说更少的故障时间和更大的报表生成灵活性。BO的方式：BO的基于桌面 的cube方式先天地受到cube中包含的数据量和在有限的数据集上进行的分析的限制。通常，由于整个cube必须被装载进桌面内存，cube要受到它能 装载的源数据量和它能够分析的类的层次数量的约束，其导致的结果是一个单独的cube拥有的有意义数据的数量经常是明显有限的。在BO中，最严重的瓶颈经常在用户试图钻取时发生，由于BO没有对钻取提供限制条件，即使用户试图加亮确定数量的行，cube爆炸很快地便会发生。也就是，当用户试图去钻取时，没有应用子集过滤并且整个cube在新的期望级别上被重建。一个零售例子说明了在网络容量方面cube所受到的限制以及随后的钻取可能是多么的危险：假设BO universe有三个类层次：产品：（种类，子种类，产品）假设电子种类包含5000中产品地理：（地域，地区，商店）假设跟踪东北地域的50个商店。时间：（年，季度，月，天）假设跟踪2年的历史数据我的BO分析范围开始于：2个简单的measures：销售金额，销售数量建立一个概要的cube来对两年期间，东北地区的电子种类进行销售分析；分析范围扩展到产品级别：我的概要cube会包含：#记录数：5000个产品X50个商店X2年=500,000记录需要20MB的数据（5列*500000记录*8字节）假定20MB的数据能够跨网络被复制、保存在本地硬盘上、加载到桌面内存中，我们的概要级分析要开始了，为了确定为什么在上个月销售量下降，当我钻取到细节级时cube的爆炸问题便产生了。如果我想从当前年级别钻取到季度级别时，我需要重建我的cube：5000产品*50商店*8季度=2000000记录，需要80MB如果我想从当前季度级别钻取到月级别时，我需要重建我的cube：5000产品*50商店*24季度=6000000记录，需要240MB如果我想从当前月级别钻取到天级别时，我需要重建我的cube：5000产品*50商店*730季度=182500000记录，需要7.3GB注释/假设： .如果我想跨过各时间段分析数据，例如这个时期与上个时期或基于变动的时期，分析便不可行了假定每个产品在每个日期都被销售BO为cube存储提供了有限的数据压缩，但是当cube被存取、自动解压时，压缩带来的好处便丧尽了BO能