构建基于Web的分析系统

最新推荐文章于 2024-07-13 09:38:58 发布

zgqtxwd

最新推荐文章于 2024-07-13 09:38:58 发布

阅读量271

点赞数

文章标签： web microsoft excel sqlserver 服务器 internet

本文链接：https://blog.csdn.net/zgqtxwd/article/details/2338613

版权

在使用分析型时，分析人员将数据归入公用组，并尝试确定条件变化时产生的结果。

例如，提高产品价格会增加单位利润，但可能会减少销量????ù会产生较高还是较低的总利润？或者，联邦贴现率的下降会如何影响房地产贷款的收益？为了帮助分析人员根据历史趋势做出有根据的预测，Microsoft在2000中提供了分析服务，在SQLServer7.0中提供了OLAP服务。这些服务都提供OLAP功能，能够将存储在SQLServer（或任何其他OLEDB兼容的数据源）上的数据处理成多维数据结构，称为多维数据集。多维数据集简化了趋势分析和建立实体间交互方式联系的过程。

例如，房地产投资者采用现金流模型来区分一组具有共同特征（如：地产类型、地理位置和利率范围）的贷款，并预测各种事件的影响。如果贷款提前偿还或者借款人违约，后果将会如何？此类不可预测的事件会如何影响贷款所担保的债券的收益？

从包含几百笔贷款的清单中选择并区分具有分析特征的贷款是需要相当技巧的。分析服务和OLAP服务有助于在各组贷款间建立联系，以便分析人员能够建立贷款假设模型。为了帮助客户的房地产分析人员预测商业抵押证券的业绩，我们的开发小组需要一个以各种方式（如：利率、到期期限或地产位置）来简化贷款分类的系统。其界面应易于学习和使用。而且，所开发的系统需要在Internet上进行的部署。为了满足这些要求，开发小组选择了分析服务。

使用OWC在Web上部署Office

在选定了后端技术后，开发小组开始制订实现前端界面的计划。多数金融分析人员使用Microsoft，他们对其界面比较熟悉，感觉也很舒服。Excel包括数据透视表服务，能够允许分析人员连接到分析服务数据库。Excel的拖放界面提供了对多维数据的简单和直观的访问，并不要求用户进行深入的培训。而且，通过使用Excel的制图功能，用户能够以图和表的形式表示数据。所以，对于前端界面，小组的首选是MicrosoftOfficeXP中的Excel2002。图1显示了Excel数据透视表服务浏览一个分析服务OLAP多维数据集的情形。

如果所有的客户端用户在同一幢大楼内一起工作，并通过同一个局域网访问分析服务器，Excel会是不错的选择。但用户需要和办公地点散布于世界各地的不同组织共享应用程序，因此开发小组需要一个用户可以通过Internet访问且类似于Excel的组件。该小组发现OfficeWeb组件(OWC)能够满足这一需要。OWC是一组能够在Web页上使用并提供Office功能的ActiveX控件。OWC数据透视表组件是Excel中数据透视表服务的Web版本；数据透视表使用数据透视表服务，并要求在运行前安装数据透视表服务。但没有Excel，OWC数据透视表也能工作。

数据透视表能够从分析服务器上检索多维数据并将这些数据显示在一个交互的拖放界面上。已安装MicrosoftInternetExplorer(IE)4.01或以上版本的用户可以使用OWC对分析服务数据进行分析，而不必安装额外的组件。图2显示了外观和操作都类似于熟悉的Excel界面的OWC数据透视表客户端界面。OWC数据透视表也提供了智能缓存，通过减少数据透视表从网络到服务器的往返行程次数而提高性能。所以，通过有效使用分析服务，数据透视表能够减少数据传输并提高效率。

虽然OWC提供了我们开发小组的项目需要的全部东西，但当我们试图在Internet上部署OWC时，我们遇到了难题。首先是OWC的运行平台问题。OfficeXP版的OWC要求使用MicrosoftDataComponents(MDAC)2.6或以上版本。而许多服务订户使用WindowsNTWorkstation4.0作为其，如果要安装MDAC2.6，还必须安装ServicePack6(SP6)。使用OWC的一个主要吸引力在于我们认为它能够实现无缝的部署。我们发现虽然能够自动处理安装ServicePack，但该过程需要重新启动，非常麻烦。以后，Microsoft提供了一个使用SP4的OWC组件修订版本，但我们同时也在开发自己的应用程序，在金融机构严格控制的客户端网络上部署ServicePack是一个很大的困难。因此，需要在操作系统上使用特定ServicePack的解决方案是不可行的。

其次，我们小组遇到了连接问题。OWC要求直接连接分析服务数据源。OWC使用默认的2725端口直接和分析服务器通信，对于使用的机构来说，这是个问题。（有关连接分析服务的详细信息，参见位于http://support.microsoft.com/default.aspx?scid=kb;en-us;q301901的Microsoft文章"INF:TCPPortsUsedbyOLAPServiceswhenConnectingThroughaFirewall"。）

首先，我们试图使用HTTP连接和服务器通过80端口进行连接以解决连接问题。该连接通过Web浏览器使用的同一个端口来提供访问。对于额外的安全性，分析服务还能够使用安全套接字层(SSL)，通过443端口进行连接。大多数组织同时打开80端口和443端口以便用户访问Internet。（有关使用HTTP的更多信息，参见位于http://support.microsoft.com/default.aspx?scid=kb;en-us;q279489的Microsoft文章"INF:HowtoConnecttoAnalysisService2000ByUsingHTTPConection"。）图3说明了使用OWC连接到分析服务器涉及的问题。

然而，HTTP连接的执行产生了一些难以克服的困难。我们测试显示，通过80端口进行连接要明显慢于直接连接。因为多维数据集需要向客户端提供大量的数据，性能的降低使OWC的使用很不现实。

返回页首

寻找替代方案

接下来，我们的小组考虑使用ADO-MD和MDX查询创建自定义界面。您可使用OPENROWSET命令直接查询分析服务多维数据集。（有关查询分析服务的信息，参见位于http://support.microsoft.com/default.aspx?scid=kb;en-us;q218592的Microsoft文章"HOWTO:SQLServer7DistributedQuerywithOLAPServer"。）OPENROWSET允许您从包括分析服务在内的任何OLEDB源上查询数据。这种灵活性能够让我们使用ADO查询分析服务。分析服务使用的OLEDB提供程序MSOLAP将多维数据转换成ADO能够用来同前端的应用程序进行数据通信的标准行集。这种自定义解决方案的问题在于创建具有OWC和Excel外观的直观而且互动的界面是一件非常复杂的工作。虽然开发小组能够创建这样的界面，但所花时间长、费用高，且需要不断进行维护，因此该解决方案不具备可行性。

开发小组也研究了几个第三方的解决方案。很多第三方解决方案是帮助用户生成一个查询，然后执行它来查看结果。这种方式虽然有效地利用了系统资源，但达不到Excel和OWC的拖放界面同样的交互式效果。所以，虽然这些解决方案各具优势，但没有一个能够完全满足本项目的要求。在我们小组将自定义开发成本加入第三方软件的总成本考虑时，我们决定重新寻找替代方案。

返回页首

使用Web瘦客户端访问多维数据

开发小组成员最后选用MicrosoftSQLServerResourceKit，为我们的难题找到了解决方案：分析服务Web瘦客户端浏览器。（要在资源工具箱CD-ROM上访问Web瘦客户端，参见资源工具箱第39章的参考信息，该信息位于http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/sql/reskit/sql2000/part11/c3961.asp。）Web瘦客户端使用ActiveServerPage()连接到分析服务器、将多维数据转换成，并将数据传递给客户端。图4说明了Web瘦客户端显示贷款数据子集的情况。

Web瘦客户端需要IE5.0或以上版本。因为客户端不直接连接到分析服务计算机，所以客户端不需要MDAC2.6。由于多数客户端订户具有IE5.0，所以我们不必在订户的个人计算机上部署ServicePack。图5显示了Web瘦客户端使用的结构。Web瘦客户端使用ASP从MicrosoftIIS服务器—而不是客户端—来查询多维数据集。Web瘦客户端带有ASP页，使得您能够在IIS服务器上部署。因为只有运行ASP的IIS服务器才能够连接到分析服务数据库，所以，您能够使用一个连接来保证通过防火墙进行的多维数据集访问，并且可以将该连接局限于Web服务器和数据库服务器。这种安排创建了一个高效和易于保护的连接。对客户端的唯一连接是标准的HTML连接，这能够减少防火墙的影响。

Web瘦客户端将查询的数据放到一个网格状的HTML表结构中，并将数据发送到浏览器。用户通过Script和数据进行交互。通过使用透明层，用户可以将维拖到多维数据集中进行数据操作、通过维向下追溯并显示和分析其需要的数据。

如多数设计决策那样，使用Web瘦客户端需要做出某些折衷。因为在Web服务器域和后端域之间不存在信任关系。您不能在系统中扩展ActiveDirectory(AD)作为其验证服务。这样的信任关系会给入侵者提供一种破坏后端域安全的方法。因此，系统必须建立一个匿名用户来访问分析服务器上的数据。如果对数据的访问取决于用户，则不能使用基于分析服务的角色安全性来控制对数据的访问。然而，如果系统允许所有用户通过一个安全上下文进行数据访问，则使用Web瘦客户端是安全的，而且容易部署。

Web瘦客户端也有其他缺点。OWC通过使用数据透视表的智能缓存把从Web浏览器到OLAPWeb服务器的往返行程数减少到最小来获取更多的数据。但Web瘦客户端是从服务器端提取数据的，因为数据在Web浏览器中并不缓存，所以每次对数据的更改都要求浏览器向Web服务器提出新的请求。当处理的数据量很大时，这个进程会很缓慢。OWC还具有丰富的对象模型，您可以对之编写自定义代码。而Web瘦客户端使用JavaScript，很难自定义。因为Web瘦客户端是资源工具箱内包含的“自由代码”，所以Microsoft并不像支持Excel或OWC那样对Web瘦客户端提供相同程度的支持。而且，Web瘦客户端要求客户端脚本，如果Web浏览器已经更新或更改，它会产生错误。此外，Web瘦客户端不直接支持对服务器的回写。幸好，我们小组的应用程序不要求回写，所以，这个缺失的功能并不妨碍我们使用Web瘦客户端。在对其优点和缺点进行评估后，我们决定部署Web瘦客户端。这个解决方案在生产环境中使用效果不错，并得到了用户的广泛认可。

返回页首

为任务选择合适的客户端

我们的开发小组在本项目中得到的经验教训能够为在企业中部署OLAP解决方案提供有价值的指导。Excel提供了功能强大而且熟悉的客户端，您可以在局域网中进行部署，但需要实时连接OLAP服务器。在Intranet内部署分析服务客户端时，OWC的使用效果不错，因为您可以轻松控制客户端平台，并且能够在Intranet内安全地打开端口。当存在防火墙，并且您希望尽可能减少对用户操作系统的影响时，Web瘦客户端是一个很好的Internet解决方案。对于任何开发项目，需要理解所开发产品的使用者的业务要求和需要。通过概括要求并权衡所有选择，可以发现能够满足客户要求的正确解决方案。