文献翻译基于 Web 的分析系统院(系)名称信息工程学院专业名称软件工程英文译文基于Web 的分析系统马克斯科特,约翰琳1 摘要在使用分析型数据库时,分析人员将数据归入公用组,并尝试确定条件变化时产生的结果。
例如,提高产品价格会增加单位利润,但可能会减少销量ù会产生较高还是较低的总利润?或者,联邦贴现率的下降会如何影响房地产贷款的收益?为了帮助分析人员根据历史趋势做出有根据的预测,Microsoft 在SQL Server 2000 中提供了分析服务,在SQL Server 7.0 中提供了OLAP 服务。
这些服务都提供OLAP 功能,能够将存储在SQL Server(或任何其他OLE DB 兼容的数据源)上的数据处理成多维数据结构,称为多维数据集。
多维数据集简化了趋势分析和建立实体间交互方式联系的过程。
例如,房地产投资者采用现金流模型来区分一组具有共同特征(如:地产类型、地理位置和利率范围)的贷款,并预测各种事件的影响。
如果贷款提前偿还或者借款人违约,后果将会如何?此类不可预测的事件会如何影响贷款所担保的债券的收益。
从包含几百笔贷款的清单中选择并区分具有分析特征的贷款是需要相当技巧的。
分析服务和OLAP 服务有助于在各组贷款间建立联系,以便分析人员能够建立贷款假设模型。
为了帮助客户的房地产分析人员预测商业抵押证券的业绩,我们的开发小组需要设计一个以各种方式(如:利率、到期期限或地产位置)来简化贷款分类的系统。
其界面应易于学习和使用。
而且,所开发的系统需要在Internet 上进行安全的部署。
为了满足这些要求,开发小组选择了分析服务。
2 在Web上部署Office在选定了后端技术后,开发小组开始制订实现前端界面的计划。
多数金融分析人员使用Microsoft Excel,他们对其界面比较熟悉,感觉也很舒服。
Excel 包括数据透视表服务,能够允许分析人员连接到分析服务数据库。
Excel 的拖放界面提供了对多维数据的简单和直观的访问,并不要求用户进行深入的培训。
而且,通过使用Excel 的制图功能,用户能够以图和表的形式表示数据。
所以,对于前端界面,小组的首选是Microsoft Office XP 中的Excel 2002。
Excel 数据透视表服务浏览一个分析服务OLAP 多维数据集的情形。
2.1 使用OWC在Web上部署Office如果所有的客户端用户在同一幢大楼内一起工作,并通过同一个局域网访问分析服务器,Excel 会是不错的选择。
但用户需要和办公地点散布于世界各地的不同组织共享应用程序,因此开发小组需要一个用户可以通过Internet 访问且类似于Excel 的组件。
该小组发现Office Web 组件(OWC) 能够满足这一需要。
OWC 是一组能够在Web 页上使用并提供Office 功能的ActiveX 控件。
OWC 数据透视表组件是Excel 中数据透视表服务的Web 版本;数据透视表使用数据透视表服务,并要求在运行前安装数据透视表服务。
但没有Excel,OWC 数据透视表也能工作。
数据透视表能够从分析服务器上检索多维数据并将这些数据显示在一个交互的拖放界面上。
已安装Microsoft Internet Explorer (IE) 4.01 或以上版本的用户可以使用OWC 对分析服务数据进行分析,而不必安装额外的组件软件。
图2显示了外观和操作都类似于熟悉的Excel 界面的OWC 数据透视表客户端界面。
OWC 数据透视表也提供了智能缓存,通过减少数据透视表从网络到服务器的往返行程次数而提高性能。
所以,通过有效使用分析服务,数据透视表能够减少数据传输并提高效率。
虽然OWC 提供了我们开发小组的项目需要的全部东西,但当我们试图在Internet 上部署OWC 时,我们遇到了难题。
首先是OWC 的运行平台问题。
Office XP 版的OWC 要求使用Microsoft Data Access Components (MDAC) 2.6 或以上版本。
而许多服务订户使用Windows NT Workstation 4.0 作为其操作系统,如果要安装MDAC 2.6,还必须安装Service Pack 6 (SP6)。
使用OWC 的一个主要吸引力在于我们认为它能够实现无缝的部署。
我们发现虽然能够自动处理安装Service Pack,但该过程需要重新启动,非常麻烦。
以后,Microsoft 提供了一个使用SP4 的OWC 组件修订版本,但我们同时也在开发自己的应用程序,在金融机构严格控制的客户端网络上部署Service Pack 是一个很大的困难。
因此,需要在操作系统上使用特定Service Pack 的解决方案是不可行的。
其次,我们小组遇到了连接问题。
OWC 要求直接连接分析服务数据源。
OWC 使用默认的2725 端口直接和分析服务器通信,对于使用防火墙的机构来说,这是个问题。
先,我们试图使用HTTP 连接和服务器通过80 端口进行连接以解决连接问题。
该连接通过Web 浏览器使用的同一个端口来提供访问。
对于额外的安全性,分析服务还能够使用安全套接字层(SSL),通过443 端口进行连接。
大多数组织同时打开80 端口和443 端口以便用户访问Internet。
(有关使用HTTP 的更多信息,参见位于/default.aspx?scid=kb;en-us;q279489 的Microsoft 文章"INF: How to Connect to Analysis Service 2000 By Using HTTP Conection"。
)说明了使用OWC 连接到分析服务器涉及的问题。
然而,HTTP 连接的执行产生了一些难以克服的困难。
我们测试显示,通过80 端口进行连接要明显慢于直接连接。
因为多维数据集需要向客户端提供大量的数据,性能的降低使OWC 的使用很不现实。
2.2 寻找替代方案接下来,我们的小组考虑使用ADO-MD 和MDX 查询创建自定义界面。
您可使用OPENROWSET 命令直接查询分析服务多维数据集。
(有关查询分析服务的信息,参见位于/default.aspx?scid=kb;en-us;q218592 的Microsoft 文章"HOWTO:SQL Server 7 Distributed Query with OLAP Server"。
)OPENROWSET 允许您从包括分析服务在内的任何OLE DB 源上查询数据。
这种灵活性能够让我们使用ADO 查询分析服务。
分析服务使用的OLE DB 提供程序MSOLAP 将多维数据转换成ADO 能够用来同前端的应用程序进行数据通信的标准行集。
这种自定义解决方案的问题在于创建具有OWC 和Excel 外观的直观而且互动的界面是一件非常复杂的工作。
虽然开发小组能够创建这样的界面,但所花时间长、费用高,且需要不断进行维护,因此该解决方案不具备可行性。
开发小组也研究了几个第三方的解决方案。
很多第三方解决方案是帮助用户生成一个查询,然后执行它来查看结果。
这种方式虽然有效地利用了系统资源,但达不到Excel 和OWC 的拖放界面同样的交互式效果。
所以,虽然这些解决方案各具优势,但没有一个能够完全满足本项目的要求。
在我们小组将自定义开发成本加入第三方软件的总成本考虑时,我们决定重新寻找替代方案。
2.3 使用Web 瘦客户端访问多维数据开发小组成员最后选用Microsoft SQL Server Resource Kit,为我们的难题找到了解决方案:分析服务Web 瘦客户端浏览器。
(要在资源工具箱CD-ROM 上访问Web 瘦客户端,参见资源工具箱第39 章的参考信息,该信息位于/technet/treeview/default.asp?url=/technet/prodtechnol/sql/reskit/sq l2000/part11/c3961.asp。
)Web 瘦客户端使用Active Server Page (ASP) 连接到分析服务器、将多维数据转换成HTML,并将数据传递给客户端。
说明了Web 瘦客户端显示贷款数据子集的情况。
Web 瘦客户端需要IE 5.0 或以上版本。
因为客户端不直接连接到分析服务计算机,所以客户端不需要MDAC 2.6。
由于多数客户端订户具有IE 5.0,所以我们不必在订户的个人计算机上部署Service Pack。
图5显示了Web 瘦客户端使用的结构。
Web 瘦客户端使用ASP 从Microsoft IIS 服务器—而不是客户端—来查询多维数据集。
Web 瘦客户端带有ASP 页,使得您能够在IIS 服务器上部署。
因为只有运行ASP 的IIS 服务器才能够连接到分析服务数据库,所以,您能够使用一个连接来保证通过防火墙进行的多维数据集访问,并且可以将该连接局限于Web 服务器和数据库服务器。
这种安排创建了一个高效和易于保护的连接。
对客户端的唯一连接是标准的HTML 连接,这能够减少防火墙的影响。
Web 瘦客户端将查询的数据放到一个网格状的HTML 表结构中,并将数据发送到浏览器。
用户通过JavaScript 和数据进行交互。
通过使用透明层,用户可以将维拖到多维数据集中进行数据操作、通过维向下追溯并显示和分析其需要的数据。
如多数设计决策那样,使用Web 瘦客户端需要做出某些折衷。
因为在Web 服务器域和后端域之间不存在信任关系。
您不能在系统中扩展Active Directory (AD) 作为其验证服务。
这样的信任关系会给入侵者提供一种破坏后端域安全的方法。
因此,系统必须建立一个匿名用户来访问分析服务器上的数据。
如果对数据的访问取决于用户,则不能使用基于分析服务的角色安全性来控制对数据的访问。
然而,如果系统允许所有用户通过一个安全上下文进行数据访问,则使用Web 瘦客户端是安全的,而且容易部署。
Web 瘦客户端也有其他缺点。
OWC 通过使用数据透视表的智能缓存把从Web 浏览器到OLAP Web 服务器的往返行程数减少到最小来获取更多的数据。
但Web 瘦客户端是从服务器端提取数据的,因为数据在Web 浏览器中并不缓存,所以每次对数据的更改都要求浏览器向Web 服务器提出新的请求。
当处理的数据量很大时,这个进程会很缓慢。
OWC 还具有丰富的对象模型,您可以对之编写自定义代码。
而Web 瘦客户端使用JavaScript,很难自定义。
因为Web 瘦客户端是资源工具箱内包含的“自由代码”,所以Microsoft 并不像支持Excel 或OWC 那样对Web 瘦客户端提供相同程度的支持。
而且,Web 瘦客户端要求客户端脚本,如果Web 浏览器已经更新或更改,它会产生错误。