SQL Server 2005 中的商务智能和数据仓库(5)

构建分析数据库的途径主要有两个：

 

•	完全自定义：从源开始，通常是从一个关系型源开始，定义维度、多维数据集、关键绩效指标、计算和数据挖掘模型。此途径对那些业已具备数据仓库或主题集市的客户来说十分适合。在多维数据集向导的第一个屏幕中，此选项的标签为“使用现有数据库/数据仓库”。
•	可自定义的模板：从模板开始，定义和生成一个完整的应用程序，包括关系数据库、DTS 包和 Analysis Services OLAP 数据库。设计和生成这些组件的目的是使这些组件无缝合作，共同组成一个完整的应用程序。此途径对于那些从模板开始安装完整商务智能解决方案的客户来说十分适合。在多维数据集向导的第一个屏幕中，此选项的标签为“在不具备数据源的前提下设计商务智能模型”。

不管采用哪种方法，基本的系统设计都假设使用当前熟悉的、来自一个或多个源的商务智能结构来填充维度关系型数据仓库，然后再用数据仓库来填充 Analysis Services 数据库。但是，SQL Server 2005 提供了许多选项，通过消除或淡化不同的组件使其背离了这种常规设计。在下面“统一维度”模型中讨论了一些其他的备选系统。

从现有的源数据库创建自定义数据库

创建 Analysis Services 数据库的第一种方法最为 SQL Server 2000 的用户所熟悉。即从任意结构的源数据库开始着手创建数据库：

•	按事实数据表和维度表构建一个维度数据库，或
•	任何其他的数据库结构，包括标准化的事务系统。

SQL Server 2005 中可从标准化数据库寻源的能力是对 Analysis Services 2000 的一大突破，在 Analysis Services 2000 中，执行此操作需要一个维度结构，此结构或是星型的，或是雪花型的，或是拉伸型的。此功能使您可以轻松地开发具有极低延迟时间的商务智能应用程序。

通过直接在事务数据库内构建 Analysis Services 数据库，而不需要先构建正式的数据仓库，可以用较低的成本，轻松有效地满足许多用户的要求。如果您需要仅对数据执行最低的数据转换、清理和集成便投入使用，则可考虑使用一个 Analysis Services 数据库来补充或替换现有的关系报告。您可以充分利用 Analysis Services 的功能和交互性，更好地管理事务系统中的负载。

虽然可以直接从事务系统构建和维护 Analysis Services 数据库，但只有先构建关系型数据仓库才能最好地满足许多企业分析的要求。复杂的数据集成和数据更改管理问题可以通过典型的数据仓库体系结构得到最好的解决，其中 Analysis Services 数据库充当着查询和分析引擎的角色。

数据源和数据源视图

构建分析应用程序的第一步就是在 Business Intelligence Development Studio 中创建一个新的 Analysis Services 项目。创建了空项目之后，应当创建一个“数据源”并将其与源数据库建立连接，此源数据库可以是任何受支持的关系数据库管理系统中的数据库。对于 Beta 2 版本，建议您将 SQL Server 2000 或 SQL Server 2005 关系数据库作为源。

“数据源”负责为源数据连接存储信息。“数据源视图”中包含着源数据库表相关子集的信息。此信息不只局限于源数据库中表的物理结构；您还可以添加诸如关系、表和列的友好名称、计算列和命名查询之类的信息。

“数据源视图”可以在 BI 项目和 DTS 项目之间共享。“数据源视图”很有用处，尤其是在以下几种情况中：

•	源数据库包含成千上万个表，但其中只有相对少数的表在 BI 应用程序中真正有用。
•	Analysis Services 数据库使用来自多个源的数据，这些源有多重数据库、服务器、平面文件或 RDBMS。
•	BI 系统开发人员不具有源数据库中的系统管理权限，且不允许创建物理视图或修改源数据库。
•	BI 系统开发人员需要以“脱机”模式工作，必须断开与源数据库的连接。设计和开发任务针对“数据源视图”发生，而“数据源视图”已从源数据中分离出来。

您为“数据源视图”设置良好名称和关系所作的投资将换来分析应用程序的轻松开发。

创建维度和多维数据集

创建了“数据源视图”之后，便可以右击“解决方案资源管理器”窗格中的“多维数据集”图标，选择“新建多维数据集”，创建一个多维数据集。您可以启用 IntelliCube 检测和建议。如果您选择使用 IntelliCube，则必须决定是否构建一个已为报告经过旋转优化的多维数据集。IntelliCube 技术会对“数据源视图”中的数据库和数据基数关系进行检查，并按事实数据表、维度表或用于解析多对多关系的维度-事实桥接表来智能呈现表特征。对于 Beta 2 版本来说，选择是为旋转还是为报告优化多维数据集和维度存在一些微小的差别。唯一的差别就是 IntelliCube 是否会尝试在维度属性之间创建层次关系。由于层次易于创建，也易于毁坏，因此无须担心会花费太多时间和精力。

建议您在此“多维数据集向导”的初始屏幕后立即点击“完成”按钮。这样会一次定义好所需的 Analysis Services 数据库、维度、层次、属性和多维数据集。您可以对此设计进行编辑，但通常情况下，仔细一点儿走完向导，并在过程中作出一些明智的选择会更加有效。

实施完“多维数据集向导”之后，您可能会发现您更喜欢用“维度向导”来逐一地创建复杂的维度，要启动“维度向导”，只需在“解决方案资源管理器”窗格中右击“维度”即可。仔细定义完大型维度（例如“产品”、“客户”和“时间”）后，启动“多维数据集向导”，并确保在适当的位置包括这些预定义的维度。

构建和部署

到此为止，前面执行的这些步骤已在您的开发机器上以 XML 文件轻松创建了维度和多维数据集定义和结构。Business Intelligence Development Studio 和“配置管理器”使您可以对目标服务器上的项目构建和部署过程进行管理。默认情况下，“部署”目标服务器就是您的本地服务器。您可以创建适合其他环境部署的备选配置。项目的主要属性，如目标服务器的名称和数据源连接字符串等，可能会因配置而不同。

要在开发循环过程中预览和测试多维数据集和维度，请从 Business Intelligence Development Studio 的菜单中选择“部署”，在指定的目标服务器上构建和部署项目。或者，单击 F5，或选择“调试”（位于 Business Intelligence Development Studio 主菜单中）。这样会启动几个调试和浏览工具中的一个，具体启动哪个，要取决于您所执行的操作以及您选择“部署”的时间。根据此上下文，“部署”过程会启动多维数据集浏览器、MDX 脚本调试器或 KPI 浏览器。

您可能想在定义完系统的维度、度量值和多维数据集后查看一下系统原型。请使用相对较少的数据针对开发数据库进行处理，以验证数据和结构的行为是否与预期的行为相一致。

作为原型的一部分，您可能想设计一些更为复杂的“Analysis Services 数据库”、“关键绩效指标”、“操作”和“计算”组件。如果您的数据库是被对不同数据视图感兴趣的不同用户团体使用的话，请深入查看“透视”和备选的安全计划。如果您计划部署可供国际上不同语言的用户使用的数据库，则可以使用“翻译”功能引入本地化项目名称。最终，原型会评估备选的物理配置，例如“分区”和不同的“主动缓存”选项。

在 Analysis Service 数据库开发完成之后，便可以部署数据库对象，以便于进行最终测试、临时过渡并投入生产服务器。在构建阶段的项目输出可以用作 Analysis Services 部署实用工具的输入。此实用工具可以帮助您部署和处理数据库。

从模板创建可自定义的数据库

我们刚刚描述了从已知源创建自定义 Analysis Services 数据库的基本步骤。这种通过“多维数据集向导”和“维度向导”创建的方法与创建 Analysis Services 2000 数据库的标准方法十分类似。

创建 2005 分析应用程序的另外一种备选方法就是选择“多维数据集向导”第二个屏幕上的“在不具备数据源的前提下设计商务智能模型”选项。这种通过向导创建的方法与 SQL Server 2000 Accelerator for Business Intelligence 的设计体验十分类似。这种设计体验会从模板生成一个完全可自定义的应用程序，此处的模板：具有丰富的维度结构和分析功能，还有可能包括一个关系型数据仓库和 DTS 包。Microsoft、集成商或独立软件供应商都可以提供这种模板。

不管采用哪种通过向导创建的方法，是从源数据库创建，还是从模板创建，都可以设计相同的 Analysis Services 数据库。第一种选项假设您将创建一个完全自定义的系统。对象名称和结构都是可以完全自定义的，初始设计是受源数据库中的名称和结构所驱动的。模板选项也可以创建一个完全自定义的数据库，但是初始设计是受专家主题区域模板所驱动的。

许多用户都喜欢将这两种方法结合使用。一个非常常见的方法就是用现有源创建 Analysis Services 数据库中的大部分内容，而用模板法生成“时间”维度。

统一维度模型

Analysis Services 2005 使关系数据库与多维度 OLAP 数据库之间的界线变得更加模糊。OLAP 数据库分析应用程序一直以来都具有着巨大的优势，这些优势主要体现在以下几个方面：

•	卓越的查询性能、
•	丰富的分析功能，以及
•	其易于业务分析师使用的操作简单性。

不过，在实现这些功能的同时也带来了一定的负面效应。到目前为止，已经发现的问题就有 OLAP 数据库（包括 Analysis Services 2000 在内）很难交付以下内容：

•	包括多对多关系的复杂架构、
•	对广泛属性集的详细报告，以及
•	低延迟数据。

通过将传统 OLAP 分析与关系报告二者的优点相结合，Analysis Services 2005 能够提供一个可以同时覆盖这两方面需求的统一维度模型。在 SQL Server 2005 中定义的一套多维数据集和维度被称为统一维度模型 (Unified Dimensional Model)，或 UDM。UDM 的优势和灵活性引发了设计领域的巨变。过去，BI 架构师会权衡备选基础结构的收益和成本，并在关系数据库和 OLAP 数据库之间作出选择。现在，架构师可以设计一个“统一维度模型”，然后从传统极限中确定一点用于放置 Analysis Services 系统逻辑设计和物理配置。

基于属性的维度

Analysis Services 2005 围绕维度的属性，而非维度的层次构建多维数据集。在 Analysis Services 2000 中，维度设计由层次主宰，层次的示例有 或 。这些层次要求各层之间存在密切的数据关系。作为成员属性和虚拟维度公开的“属性”是“二等公民”。虽然有可能在物理维度中生成属性，但性能因素却使这一技术的广泛使用大打折扣。熟悉关系结构的用户对 OLAP 数据库中对层次的过度侧重深感困惑。

Analysis Services 2005 结构与关系型维度结构更为类似。一个维度可包含多个属性，每个属性都可用于切片和筛选查询，同时每个查询又可以合并到层次中，而不必考虑数据的相互关系。

有 OLAP 背景的用户都知道强大的层次结构的价值，有一点您可以肯定，那就是“城市”清晰地汇总为“地区”和“国家”。这种自然层次结构依然存在，并应在适当的位置进行定义：查询性能会因为这种层次结构而得到提高。