在使用分析型数据库时，分析人员将数据归入公用组，并尝试确定条件变化时产生的结果。
例如，提高产品价格会增加单位利润，但可能会减少销量????ù会产生较高还是较低的总利润？或者，联邦贴现率的下降会如何影响房地产贷款的收益？为了帮助分析人员根据历史趋势做出有根据的预测，Microsoft 在 SQL Server 2000 中提供了分析服务，在 SQL Server 7.0 中提供了 OLAP 服务。这些服务都提供 OLAP 功能，能够将存储在 SQL Server（或任何其他 OLE DB 兼容的数据源）上的数据处理成多维数据结构，称为多维数据集。多维数据集简化了趋势分析和建立实体间交互方式联系的过程。
例如，房地产投资者采用现金流模型来区分一组具有共同特征（如：地产类型、地理位置和利率范围）的贷款，并预测各种事件的影响。如果贷款提前偿还或者借款人违约，后果将会如何？此类不可预测的事件会如何影响贷款所担保的债券的收益？
从包含几百笔贷款的清单中选择并区分具有分析特征的贷款是需要相当技巧的。分析服务和 OLAP 服务有助于在各组贷款间建立联系，以便分析人员能够建立贷款假设模型。为了帮助客户的房地产分析人员预测商业抵押证券的业绩，我们的开发小组需要设计一个以各种方式（如：利率、到期期限或地产位置）来简化贷款分类的系统。其界面应易于学习和使用。而且，所开发的系统需要在 Internet 上进行安全的部署。为了满足这些要求，开发小组选择了分析服务。
使用 OWC 在 Web 上部署 Office在选定了后端技术后，开发小组开始制订实现前端界面的计划。多数金融分析人员使用 Microsoft Excel，他们对其界面比较熟悉，感觉也很舒服。Excel 包括数据透视表服务，能够允许分析人员连接到分析服务数据库。Excel 的拖放界面提供了对多维数据的简单和直观的访问，并不要求用户进行深入的培训。而且，通过使用 Excel 的制图功能，用户能够以图和表的形式表示数据。所以，对于前端界面，小组的首选是 Microsoft Office XP 中的 Excel 2002。sqlserver/art/BuildingaWeb-BasedAnalysisSystemFigure_01.gif" target="_blank">图 1 显示了 Excel 数据透视表服务浏览一个分析服务 OLAP 多维数据集的情形。
如果所有的客户端用户在同一幢大楼内一起工作，并通过同一个局域网访问分析服务器，Excel 会是不错的选择。但用户需要和办公地点散布于世界各地的不同组织共享应用程序，因此开发小组需要一个用户可以通过 Internet 访问且类似于 Excel 的组件。该小组发现 Office Web 组件 (OWC) 能够满足这一需要。OWC 是一组能够在 Web 页上使用并提供 Office 功能的 ActiveX 控件。OWC 数据透视表组件是 Excel 中数据透视表服务的 Web 版本；数据透视表使用数据透视表服务，并要求在运行前安装数据透视表服务。但没有 Excel，OWC 数据透视表也能工作。
数据透视表能够从分析服务器上检索多维数据并将这些数据显示在一个交互的拖放界面上。已安装 Microsoft Internet Explorer (IE) 4.01 或以上版本的用户可以使用 OWC 对分析服务数据进行分析，而不必安装额外的组件软件。sqlserver/art/BuildingaWeb-BasedAnalysisSystemFigure_02.gif" target="_blank">图 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://support.microsoft.com/default.aspx?scid=kb;en-us;q301901 的 Microsoft 文章 "INF:TCP Ports Used by OLAP Services when Connecting Through a Firewall"。）
首先，我们试图使用 HTTP 连接和服务器通过 80 端口进行连接以解决连接问题。该连接通过 Web 浏览器使用的同一个端口来提供访问。对于额外的安全性，分析服务还能够使用安全套接字层 (SSL)，通过 443 端口进行连接。大多数组织同时打开 80 端口和 443 端口以便用户访问 Internet。（有关使用 HTTP 的更多信息，参见位于 http://support.microsoft.com/default.aspx?scid=kb;en-us;q279489 的 Microsoft 文章 "INF: How to Connect to Analysis Service 2000 By Using HTTP Conection"。）sqlserver/art/BuildingaWeb-BasedAnalysisSystemFigure_03.gif" target="_blank">图 3说明了使用 OWC 连接到分析服务器涉及的问题。
然而，HTTP 连接的执行产生了一些难以克服的困难。我们测试显示，通过 80 端口进行连接要明显慢于直接连接。因为多维数据集需要向客户端提供大量的数据，性能的降低使 OWC 的使用很不现实。
接下来，我们的小组考虑使用 ADO-MD 和 MDX 查询创建自定义界面。您可使用 OPENROWSET 命令直接查询分析服务多维数据集。（有关查询分析服务的信息，参见位于 http://support.microsoft.com/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 的拖放界面同样的交互式效果。所以，虽然这些解决方案各具优势，但没有一个能够完全满足本项目的要求。在我们小组将自定义开发成本加入第三方软件的总成本考虑时，我们决定重新寻找替代方案。
使用 Web 瘦客户端访问多维数据开发小组成员最后选用 Microsoft SQL Server Resource Kit，为我们的难题找到了解决方案：分析服务 Web 瘦客户端浏览器。（要在资源工具箱 CD-ROM 上访问 Web 瘦客户端，参见资源工具箱第 39 章的参考信息，该信息位于 http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/sql/reskit/sql2000/part11/c3961.asp。）Web 瘦客户端使用 Active Server Page (ASP) 连接到分析服务器、将多维数据转换成 HTML，并将数据传递给客户端。图 4说明了 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 浏览器已经更新或更改，它会产生错误。此外，Web 瘦客户端不直接支持对服务器的回写。幸好，我们小组的应用程序不要求回写， 所以，这个缺失的功能并不妨碍我们使用 Web 瘦客户端。在对其优点和缺点进行评估后，我们决定部署 Web 瘦客户端。这个解决方案在生产环境中使用效果不错，并得到了用户的广泛认可。
为任务选择合适的客户端我们的开发小组在本项目中得到的经验教训能够为在企业中部署 OLAP 解决方案提供有价值的指导。Excel 提供了功能强大而且熟悉的客户端，您可以在局域网中进行部署，但需要实时连接 OLAP 服务器。在 Intranet 内部署分析服务客户端时，OWC 的使用效果不错，因为您可以轻松控制客户端平台，并且能够在 Intranet 内安全地打开端口。当存在防火墙，并且您希望尽可能减少对用户操作系统的影响时，Web 瘦客户端是一个很好的 Internet 解决方案。对于任何开发项目，需要理解所开发产品的使用者的业务要求和需要。通过概括要求并权衡所有选择，可以发现能够满足客户要求的正确解决方案。