Project REAL分析服务技术探讨（1）

核心提示：这份白皮书提供了一个关于分析服务(Analysis Services)设计和在Project REAL中的最佳实践的技术讨论，它深入的讨论了每一类对象的细节，Project REAL分析服务技术探讨（1），例如数据源、数据源视图、维度、层次、属性、度量组、分割表等等，并指出如何在关系型数据库分割表的基础上创建一个能自动

这份白皮书提供了一个关于分析服务(Analysis Services)设计和在Project REAL中的最佳实践的技术讨论。它深入的讨论了每一类对象的细节，例如数据源、数据源视图、维度、层次、属性、度量组、分割表等等。并指出如何在关系型数据库分割表的基础上创建一个能自动创建度量组分割表的SQL Server 2005集成服务程序包。

关于Project Real

Project Real是微软为创建商业智能应用程序提供最佳实践而所做的努力。这些程序都是在Microsoft® SQL Server™ 2005基础上，在真实的客户背景上构建实施的。这就意味着真实客户数据是可以代入系统内部，并且可以应对客户在开发过程中将会遇到的同样的问题。这些问题包括：

◆模式设计- 关系型模式和分析服务型模式

◆数据抽取、数据转换、数据加载(ETL)过程的实现

◆客户端系统的设计与开发，包括数据报表和交互式的分析

◆产品系统的分级

◆运营系统的管理和维护，包括数据资料的不断更新

通过在这种真实部署环境中的工作经历，我们获得了如何使用这些工具的完整理解。我们的目标是全方位的关注大公司在他们自己实际部署过程中所遇到的所有问题。

这份白皮书提供了一个关于分析服务(Analysis Services)设计和在Project REAL中的最佳实践的技术讨论。我们深入的讨论了每一类对象的细节，例如数据源、数据源视图、维度、层次、属性、度量组、分割表等等。并指出了我们在前进过程中遇到的重要问题。

若要查看Rroject REAL的概述信息，可查看 Project REAL: Technical Overview 白皮书。有相当大一部分的资料、工具、和例子，都是在Project REAL的生命周期中产生的。为了找到最新的信息，可以到Project REAL Web site这个连接来察看相关的信息(http://www.microsoft.com/sql/bi/ProjectReal/)。

备注：这篇文章仅仅是一个草案，它包括了一些建设性的实践方法，这些方法都是基于我们早先在SQL Server 2005的Community Technology Preview (CTP)工作中获得的经验。到产品发布之前，白皮书中所描述的都是准确的。文档中描述的产品功能性可能会有所变化。在将来，可能会提供更好的实践方案。SQL Server 2005是在我们对这些好的练习例程中用的开发工具。

绪论

这篇文章回顾了关于Project REAL分析服务的技术性设计，并且讨论了各种影响设计的问题。我们假定读者已经比较熟悉分析服务设计，并且实践过Project REAL所采用的模式。例如，我们假定读者已经知道多对多厂商维度的存在。我们的讨论主要关注为什么它会存在（以及我们在对设计进行定案之前所考虑的可供选择的办法）。

在本文中，我们检验了在多维度设计中应用到的各种类型的分析服务对象。从物理模式对象入手，例如数据源和数据源视图。接下来我们讨论在逻辑对象，例如维度，用户自定义的层次关系、属性层次、和度量组等等。接下来深入到度量组特征，例如分割、集合(aggregate)设计、以及前摄缓存(proactive caching)。这部分内容最后讨论了其它的逻辑设计，包括计算、关键性能指示器(KPIs)、活动、透视、定制程序集、用户自定义函数(UDFs)和MDX脚本等等。

最后一个章节中，我们详细讨论了在分析服务模式设计阶段，两种可选的、合理的设计方案。我们提供了目标，也是我们考虑要做的事情，也正是我们所实现的。

本篇以介绍服务端设置来结束，主要讨论了我们为什么要改变这些配置。

Project REAL设计强烈依赖于分割(partitioning)，在所有的度量组中，定义了几百个这样的分割表，在附录A中，我们将展示我们是如何解决我们在各种数据库中创建和管理分割表带来的管理问题。

和分析服务交互的三种方法

有三种方法来和分析服务交互：SQL Server管理环境(Management Studio)，项目模式下的商业智能开发环境(Business Intelligence Development Studio)和连接模式下的商业智能开发环境。我们将逐一的实施检验它们，并将向你描述如果你不能适当的结合这些工具方法，将带来的无穷麻烦。

SQL Server 管理环境（Management Studio）

在你启动SQL Server 管理环境之后，系统会直接连接分析服务的服务器，并能马上完成请求连接的操作。

例如：如果你处理一个Cube或者维度，系统内部将使用受控的API，也被称为分析管理对象(Analysis Management Objects ，AMO)，通过这些对象来查找信息以及请求管理功能，例如：对象处理。一些操作是通过AMO来实现的，另外一些是采用XMLA脚本来实现，但是无论是那种方法，都是依靠运行的分析服务服务器来完成的。由于分析服务支持并发访问，系统保留了结构上锁的特性，用来避免在多个操作并发的时候产生的冲突，例如：当某个维度正在被一个操作处理时，这个结构能够阻止试图删除这个维度的操作。

SQL Server 管理环境（Management Studio）是作为一个管理应用程序而被设计的。它并不是一个开发环境。它允许你用它来浏览分析服务（Analysis Services）服务器和执行各种相关的操作活动,例如执行备份和恢复；同步服务器；配置服务器等。当SQL Server管理环境完成基本对象管理时，例如更改少量的属性或者删除对象，它就需要依靠其它的程序来设计和配置分析服务对象。

BI Development Studio 项目模式 (默认模式)

想要设计和实现 Analysis Services 数据库的开发人员和数据库管理员可以利用BI Development Studio 与 Analysis Services 相合作。BI Development Studio 是运用 Microsoft Visual Studio® shell 构建而成的。利用BI Development Studio 完成操作与利用其他SQL Server 工具完成操作非常类似（例如创建一个集成服务包或者产生一个服务报告）。 Visual Studio shell 的一个原则就是开发是一个反复编辑，构建，配置的迭代过程。

对于Analysis Services来说，这就意味着你一旦开始了一个Analysis Services项目，你便与Analysis Services服务器分离开来。起初，你通过如下任意方式构建项目：1）从相关资源中创建维度，cube和其他对象，为Analysis Services server创建项目。2）从服务器中获取一个已有的Analysis Services数据库，并在库中创建项目。一旦项目被创建，它便与Analysis Services服务器分离开来（并且和其存在的数据库也分离开来）。你可以在飞机中或是家中利用便携式电脑脱机的获取项目。仅当你重新与Analysis Services服务器连接。

当开发项目时，BI Development Studio将检查对象在项目中和Analysis Services服务器中的不同。这些不同点用于同步项目与Analysis Services服务器。这就意味着创建了在脱机状态下创建的新对象，编辑了在脱机状态下改变的属性，删除了在项目中没有但是在Analysis Services服务器中存在的对象。

这是一个非常强大的范例。开发人员开发一个应用程序，然后进行编译和配置。从创建开始，项目可以脱机的存在于开发人员的工作站中，在工作站里项目可以被编辑，开发，然后被重新编译，配置。这也是用于Analysis Services项目的同样范例。

如何确保两个开发人员不对同一段代码冲突编辑？BI Development Studio运用了一个资源控制系统。任何人在通过相同的资源控制系统工作时，两个开发人员就不可能同时操作同一段代码了。BI Development Studio项目中的文件也是用了上述的方法保证避免冲突。这种方法也应用于项目子文件，例如组成项目的维度和cube正如组成应用程序的C＃程序源文件一样。

BI Development Studio直接联机模式

你可能认为有了这两样工具所有事情都可以做到了：操作人员使用的SQL Server Management Studio和开发人员使用的BI Development Studio。然而，在有些环境下，数据库管理员和操作员需要BI Development Studio的功能去完成他们的工作。事情就是这样的，例如，当你需要知道哪个cube有着什么样的尺寸，或者需要知道完整计划时。为了实现这个目的，BI Development Studio提供了一个直接联机模式。进入此模式需要在启动BI Development Studio后，在File菜单中选择Open选项，然后选择Analysis Services database。

在这种模式下，你不能使用脱机的项目。相反，你将直接联接到Analysis Services服务器上。如果你创建了一个分区，cube，或者维度时，你将直接创建，更新，删除对象。你将工作在运行的数据库中。在这里没有脱机编辑因此也就没有开发和迁入的基础文件。

如何陷入麻烦

很明显你能注意到这个问题。开发者利用资源控制系统保证工程文件在同一时间内保持一致。运用SQL Server Management Studio和直接联机模式下BI Development Studio的操作员依靠运行服务确保两个人不会同时进行相互矛盾的操作。这两种工作机制分别存在于自己的群体中。然而，他们却无法知道另一个群体做出的改变。运行中的服务不了解资源控制系统，资源控制系统也不了解运行中的服务。工程文件不能总是比较匹配运行的数据库。下面是几个这种麻烦发生的例子：

◆开发人员通过将一个现存的Analysis Services数据库引入到项目中的方式来创建一个项目。然后操作人员运用SQL Server Management Studio删除了数据库中的一个Cube。当开发人员配置项目时，cube有恢复了。这会产生一条如图1所示的消息：

图1：BI Development Studio检测到自最后一次开发后数据库被改变了

我们注意到消息没有告诉开发人员哪个对象被改变了，仅仅告知不匹配的数据库版本。因为开发人员不知道改变了的对象是否重要，她或他能做的事情就是点击YES。结果cube就恢复了。

◆Analysis Services项目被保存在资源控制系统中。你在Analysis Services服务器中通过执行SQL Server 2005集成服务包中XMLA脚本创建了一个新的分区。

例如，日常的SQL代理工作可能运行此包来处理引入的数据文件。当一个新的月份到来，此包为本月创建了一个新的分区。然后，开发人员在资源控制下改变了项目并配置项目。所有通过SQL Agent job创建的当月分区将消失。

◆运行的服务器系统崩溃并且丢失了一个磁盘驱动器。操作员将数据库恢复成为三个月前的状态，并且重新处理此数据库。开发人员配置一些QA要求的紧急改动（在资源控制下）时使得应用程序暂停。操作员认为应用程序停止是因为重新恢复备份被破坏。他们将数据库恢复到四个月前的状态。这时开发人员看到产品中没有他做的改变。因此开发人员有一次的配置了项目….因此有一次的停止了应用程序….随后操作员又将数据库恢复成为五个月前的状态。（你可以想象这种情况。）

如何解决这个问题…

这些事件的各种组合都可能发生。这将产生一些问题：

1.如何检测这种问题的发生

2.如何解决这种问题

检测到问题通常很简单。即使一个诸如修改一个对象属性这样的微小改变也会导致图1显示的错误。我们注意到仅仅是开发者被告知脱机项目文件的版本不再有效。除非开发人员告诉操作人员，否则操作人员并不知道他们在线的修改影响到了开发人员的工作。如果开发人员没有通知操作员并且开发人员继续配置他们的项目，即使数据库被修改，操作员看到的现象将是他们的修改来回反复存在和消失。

真正的挑战是如何解决这个问题。不幸的是没有一个机制自动的同步运行的Analysis Services数据库和脱机的Analysis Services项目。唯一的方法通过如下几个步骤来实现：

1.重现将Analysis Services数据库引入到一个新项目中。

2.利用引入功能重新创建所有文件

3.利用资源控制系统迁出项目（以及他们的子文件）

4.将新文件还原为迁出文件

5.迁入新版本到资源控制系统。如果你能正确操作上述步骤，现在资源控制系统将包含所有事务的最新版本

6.配置新项目，以让数据库版本号匹配。

另外一种方法是比较新引入项目文件和迁入资源控制系统的当前文件。一旦你发现了区别，逐一修改每个对象和属性以达到文件的匹配。你有效的做到了Analysis Services数据库和资源控制系统的人工同步。这种方法容易出错并且对于检测出所有差异和同步所有属性没有保证。

在同步过程中，无论是人工操作还是替换整个文件，操作员都不能在对在线系统做任何修改。此时的任意修改在最后的配置前都将被覆盖。所有的开发人员现在都必须从资源控制系统得到最新版本，或者迁出整个项目来更新人们本地的文件拷贝。

不管怎么来说，这个方法包括很多移动复制工作，这便很容易出错。如果你将要进行如此段描述的混合工作，你需要制定详细的能够确保开发人员和操作员协调合作的指导方针。

数据库设计

项目REAL Data Warehouse在一系列的多维Analysis Services数据库中执行，这些多维数据库称为：

◆REAL_Warehouse_V（代表数据的data-masked版本）是几千兆数据库版本

◆REAL_Warehouse_Development_V是数据库的开发版。它包含维度成员的全部设置，但是每15个分区在5个存储器中。REAL开发小组使用它作为一个数据集(约15GB)，每一个都能轻易的构建和测试。这种小规模的数据集能够让地理上分散的开发团队更好的共享内容。

◆REAL_Warehouse_Development_V是数据库的一个样版。它包含了一个维度结构的子集和大量的真实信息。不管怎么说，它覆盖了很长的一段时间（52个星期长的数据），因此，它里面的所有数据是系统很好的一个Demo。它正是作为Project REAL系统的一部分，为外部发行而用的。这意味着你将有足够的结构化数据使得系统能够运转。他也是其它各种Project REAL的基础。

所有这些数据库有相同的对象和结构。每个数据库有单独的一个Cube，和11个维度以及4个度量组。

数据源和数据资源视图

数据源是你在Analysis Services建模活动的起点。对于REAL项目，我们将三个SQL Server 2005关系数据库整合成一个关系数据库管理系统，它被用于数据源，Cube和运用此系统的结构。

数据源

对于所有数据拥有单一的数据源是不够的。我们最终的目的是检测出Analysis Services和资源RDBMS之间的访问路径，当他们处于服务器的不同的域中时，或许他们直接还有防火墙隔着。因此，我们及早的做出了决定我们应该运用SQL Server标准安全而不是集成安全来访问RDBMS。

我们通了过Analysis Services创建了一个专用的SQL登录来进行访问。这个帐户姓名为REAL_User，密码为password。这并不能创建一个高安全性的环境，但是已经足够我们使用了。在SQL Server数据库中，这个注册用户仅被给予data reader权限。

如创建和使用此数据源部分一样，我们注意到一个有趣的SQL Server 2005 Analysis Services现象。这就是当数据源被创建时，数据源密码被内部加密（这就意味着密码没有以明文的形式存储）并被同时删除了。因此，无论何时我们制作一个数据库拷贝时（通过在SQL Management Studio中选择Scripting然后选择任务菜单的Create Script来完成），XMLA脚本中的数据源密码都被设置为空。实事上，我们无法利用执行脚本，拷贝粘贴或其他机制将密码拷贝到另一个对象中。不管我们怎样拷贝，系统总是提示密码丢失或错误的密码。

最佳实践：当在标准安全模式下工作时，记住你的密码。当移动对象时候，你将经常需要输入密码。

删除密码有优点也有缺点。它能防止盗窃密码行为。甚至管理员也无法通过拷贝对象来使用它。当第一次使用拷贝时，管理员必须重新输入密码。在第一次使用拷贝后，数据源上有个选项，用来提示密码被数据源内部存储（加密）并且每次必须重新输入密码数据源才能被打开。得到OLAP管理者权限的恶意的用户不能拷贝任意对象，在任意其他环境上下文中使用对象，也不能通过检查数据源来获得密码。

不幸的是，这将使得通过存储在资源控制系统中的脚本构建一个每晚或每周自动重启的系统变得很困难。这是因为存储在资源控制系统的对象没有包含有效的密码。如果你的开发工厂夜间运行，自动重启，那么数据源中构建的对象就不能被Analysis Services处理，直到你输入正确的密码。在你从资源控制系统中提取和重建好所有Analysis Services对象后，你必须在能够自动处理维度，属性，分区和其他对象前为数据源设置一个有效密码。这将承担了一个安全风险，因为，密码会被以明文形式设置。因此要小心如何设置密码以及如何控制需要读取这些程序用户的访问。

数据资源视图

我们为系统的用户创建了一个数据资源视图。数据资源视图是用于扩展对象的抽取层（关系表和视图），扩展的对象被数据源用于从被创建的Analysis Services对象中抽取对象集合。为了保持典型关系数据库的最佳做法，我们不在新表中创建任何对象，但是运用关系视图。

在数据资源视图中我们包含了全部的关系视图，这些视图用于创建维度，层和属性。我们没有为每个测量组实现包含关系视图－这对于每个测量组分区来说是最基本的。此模板没有包含任何数据－仅是分区表视图，查询绑定和其他对象如何恢复的定义。

最佳实践

如下将叙述多种最佳实践

◆在那些可能的地方，能够继续使用视图向分析服务（Analysis Services）提供一个高质量的星型/雪花(star / snowflake)模式

当数据资源视图允许DBA构建复杂结构时，他们不需要专用的空间为数据添加事务值。数据资源视图不能通过数据库，服务器，应用程序被共享，也不能通过SQL Server中BI组件（例如位于Analysis Services，整合服务，报告服务之间）被共享。如果你通过视图添加了事务消息，你最好通过所有的应用程序重新使用那项专门的技能。我们发现利用数据资源视图来扩展一个系统是两种情况下极好的决策。一种情况是当RDBMS不允许设计者创建或改变视图时，另一个是当事务消息与cube的多维属性有关并与关系对象无关并且重用也不重要时。

◆运用数据资源视图创建foreign key (FK)关系，此关系不存在于基础数据源中。

FK关系不存在于数据源中的原因有很多。例如，数据来源于数据仓库。对于数据仓库，缓解参考完整性约束这是很常见的甚至他们在数据模型中已知的情况下。这样做将加速大批量数据的处理，或者当运行在清除阶段时包含可疑数据。同样，如果数据源是个数据库产品，那么参考完成性约束将不会被公示，这是因为基本关系数据库不支持这些。例如，不同数据库中或是不同服务器中的表。数据库和服务器的参考完整性约束在SQL中不允许。然而，当Analysis Services 创建SQL命令从数据源中收集数据时，FK关系非常有用。幸运的是，数据资源视图被用于为Analysis Services添加FK关系，这超越了数据源本身的定义。

◆非常容易获得被携带离开的数据资源视图和创建过多的关系

如果你的数据已经包含在星型模式中，FK关系就不再需要了，认识到这点很重要。关系被典型的应用，因此Analysis Services知道如何构建基本SQL命令。关系不需要用于浏览和操作对象或查询中。在REAL项目数据库中，我们没有定义数据资源视图关系，我们的系统也构建的相当完善。

使用数据源视图扩展元数据（metadata）

通过使用数据源视图很直接也很容易扩展元数据。在Project REAL中，我们以下几种方法使用扩展的元数据。

◆我们使用扩展的元数据来创建在离散化分组中用于数据转换的计算列。例如，Item维度有一个为称为Publish Year的属性。不管怎么样，年份都具有一些分析的意义。如何区分一个出版于1934年的书和一本出版于1992年的书？一个用于分析更好的属性应该是自出版以来已经有多少年了。因此，我们在Item表中创建了如下图所示的计算列（使用数据源视图）。

ISNULL(DATEDIFF(yyyy,Publish_Year,GETDATE()),0)

这个使用标准SQL函数的语句，将出版的年份转换到一个变量，变量的值是从出版年到现在已经有多少年了。

分析服务支持自动离散变量（例如自从出版以来的年份）。使用数据挖掘运算规则，分析服务能将值存储到统计出来的有意义的分组中。在这个例子中，我们最后得到以下十个分组

-3 到1 年 (因为Item表中包含在未来3年后才能出版的书籍，因此-3是一个有效的值)

2 年

3 年

4 年

5 年

6-7 年

8-9 年

10-13 年

14-103 年

我们为以下属性使用了这种统计方法。

维度	属性
Item	发布以来的年份分组
	零售价格分组
	页码总数分组
Store	书架空间数量分组
	仓库面积分组

◆用大家知道的范围来离散化的分组（不仅仅是统计），我们使用了稍微有点异样的方法。在这里，我们使用Transact-SQL CASE语句硬编码的方式创建一个计算列。例如，在数据源视图Store中有一个被称为Age of Store的计算列。它使用Case语句来分析数据源中的“bucketize”属性（创建日期）。

CASE
WHEN DATEDIFF(mm,open_date,GETDATE()) BETWEEN 0 AND 12
THEN 'Less than a year old'
WHEN DATEDIFF(mm,open_date,GETDATE()) BETWEEN 13 AND 24
THEN '1 - 2 years old'
WHEN DATEDIFF(mm,open_date,GETDATE()) BETWEEN 25 AND 60
THEN '2 - 5 years old'
WHEN DATEDIFF(mm,open_date,GETDATE()) BETWEEN 61 AND 120
THEN '5 - 10 years old'
WHEN DATEDIFF(mm,open_date,GETDATE()) > 121
THEN 'Older than 10 years'
ELSE 'Unknown'
END

尽管这个统计方法不需要硬编码，但它也不允许商业用户指定它们是如何被计算分组的。这里，我们能够将业务知识直接的嵌入到数据源视图中。

◆为了正确的对Age Of Store排序，我们创建了一个为称为Months SinceOpened的计算列。定义语句如下：

ISNULL(DATEDIFF(mm,open_date,GETDATE()),0)

然后我们将这两个列都添加到Store维度，并作为属性。我们再在Months Since Opened和Age of Store之间创建属性，然后再把Months Since Opened 的Order By属性的值设置成Key；然后把Age of Store的Order By属性设置成Attribute Key。这个配置允许能够按照Age of Store适当的排序（根据Months Since Opened），它也允许将两个属性都包含在查询中。

从数据源视图中忽略对象

尽管数据源视图已经经过有力的提取，但是仍有很多次，在数据源视图中包含了不改包含的对象。例如，你不应该在你的数据源视图中包含如下的对象。

◆没有需要的表和视图（尤其是对分割表）。如果一个表或者视图在维度中是没有用处的，或者只是作为一个度量组的模板表，那么就不要再包含它。因为这样做，只会让数据源视图更加混乱，并且难于导航。

◆系统不使用的业务对象表。例如，如果因为需要使用人员信息，数据源视图包含了人员数据源，然后添加Employee表，但是不做其它其它任何处理。请不要包含所有只是再人员应用程序中使用的其它的引用表和实体表。

◆其它应用程序使用的控制表。例如，在人员数据源中，你可能有一些用来控制文件或者调整ETL处理，以及更新人员应用系统数据流的表。请不要包含这些表。

修改数据源视图

在一些特定的情况下，你将需要修改数据源视图。例如，你可能需要将某个数据源表中列从integer类型修改成varchar类型，或者可能需要将varchar的大小从20字符调整到50字符。或者你可能需要修改维度定义，这些都会影响到Cube。

当你从数据源视图构建对象的时候，例如维度对象，然后将对象添加到Cube中，然后再在Cube中添加分割表，现有的元数据都会改变并影响到整个对象树。低级别的一些修改不代表这种修改会自动的带到更高的对象上。例如，假定你修改RDBMS维度表中一个列的数据类型。数据源视图不会做出自动的改变。数据源视图必须被刷新才能得到更新的结果。

同样地，如果数据源视图有所变化，基于这个数据源视图创建的对象不会自动地更新。如果一个维度或者Cube属性构建于一个列，然后你必须重新从数据源视图创建对象。实时上，你能猜到当你做出一个变化，你必须手动个根新更高级别地对象。如何让系统在一个改变地基础上，完成所有其它地改变。这里有一些指导：

◆如果只是简单地改变数据类型地大小，例如将一个数据库列从varchar（20）改成varchar（50），右键单击数据源视图的背景图，然后选择Refresh。这将更新整个数据源视图。那里可能还会有对象仍在使用旧的大小为20的值。对于这些在度量组中用来作为度量的列，编辑Cube并查看度量的数据类型和大小。对于那些被用来作为属性的列，编辑维度并改变相应的属性值。

◆如果是添加一个列，这样的改变，首先在数据源视图上单击Refresh。这将使得这个列是可用的，因此能够基于它去创建分析服务对象（也就是说维度中的属性；度量组中的度量）。

◆如果是删除一个列，这样的改变，当我们刷新数据源视图的时候所发生的事情取决于这个列是否被用来创建服务对象了。如果这个列没被用来创建其它的对象，在点击Refresh后，这个列就被删除了。否则，当你点击Refresh后，系统会提示你将删除一些对象（由于它们依赖于这个列）。

◆如果是添加或者删除一个表这样的改变，右键单击数据源视图，选择Add/Remove Tables。删除一个正在被分析服务的表，会带来一些分裂性的改变。在你删除一个表之前，首先是到Cube中更高级别的对象中。如果度量组使用了这个表，请删除这个度量组。如果是一个维度表，那就首先从所有Cube中移除这个维度，再删除这个维度。

一些增加性的改变能让你从方法学的角度来评估删除操作所带来的影响。如果你仅仅是从数据源视图中移除一个表，系统会告诉你更高级别的对象会被删除。（这可能包含很多使用这个表的对象。）一旦你点下Ok，表和指定的对象都将被删除。尽管这是一个简单的一步性操作，因为它不会让你去评估更远变化产生的影响，因此，最好还是严肃的、慢一点处理这个过程。

◆这种变化也有可能是逻辑结构上的变化而不是物理结构上的变化。例如，你可能会改变一个属性的键结构。物理数据源视图没有任何变化，但所有使用这个逻辑结构的对象都将被改变，要么重新创建这个对象要么通过刷新结果来更新对象。

例如，这就发生在当你使用特定粒度Cube中的一个维度时，键结构被内置到Cube中。为了重置键结构，只需要将这种粒度的Cube改变到其它的属性，然后在将其重新设置到原先的属性。这样重构结构，新的键值定义就会被使用。当我们在Project REAL中不得不调整它时间维度的键集合时候，我们就遇到了这个问题。

当确定属性键唯一性的时候，同常的情况时创建一个键集合，而不是使用一个单独的列。在Project REAL模式早先的版本中，我们有一个更简单的时间维度，在Month属性上并没有添加唯一性约束（也就时1－12）。为了将Month属性键设置成唯一，我们在Month键上添加了Year列。当我们完成后，我们发现，我们无法再重新部署Cube。维度的构建没有任何错误，打开查看结构也是正确的，但当我们部署Cube的时候，就遇到了错误。这是因为Cube的时间维度只有一个列来作为Month属性的键，而再新的维度键上却有两个列。为了修复这个问题，我们需要再Cube的维度中同步这个Month属性。

为了完成同步，我们改变了Cube的粒度，从Time.Day修改成Time.Week，然后保存Cube，然后再重新将它设置为Time.Day。这种内置维度的重置，也重置了键结果，因此，它的Month属性的键也有两个列。问题就得到了修复。

结论

总的来说，数据源视图在分析服务中有两个重要的角色。

首先，它们是在分析服务使用对象和数据源之间一个抽象的层。这允许你创建类似命名查询和计算列这样的对象，这些对象也能在数据源中直接创建（例如，关系型视图）。这很重要，因为分析服务的管理员可能没有必要的权限去改变源系统上的元数据。例如，源系统可能是一个保留了主要的私人信息的组织级的SAP系统。作为组织的资源，管理分析服务服务器的DBA可能没有权限在这个源系统中实现添加、移除或者改变视图这些操作。但如果把这些改变放到数据源视图中，DBA就能从一个抽象的层获得好处，而不必再去改变源系统上任何信息。

数据源视图允许你在那些不在物理数据库上或者不可能位于不同的数据库上的表和视图之间创建关联。例如，你不能在两个存储在不同数据库上的表创建外部关键字约束。这个关联对于那些从3NF或者OLTP数据库构建的维度是很重要的。

不要让数据源视图失去自控能力。毕竟它们只是一个工具，而不是一个万能药。如果你开发了一个很好的多维度设计，你可能会发现它们不仅仅是很有趣的工具。

维度(dimensions)

在Project REAL中，我们有大量的、复杂的维度。这也是带我们到这个特殊应用程序的内容之一。这有大量的分析是基于厂商所扮演的角色。这里有许多半可加性的度量，例如库存数量以及其它类型的库存数据。这种多维度设计对于那些已经开发或者正在维护零售数据库的人员是非常熟悉的。

维度键

维度包含的内容主要是用来过虑或者考虑真实表的各种度量。Cube中的维度都会映射到一个关系型的维度表。

逻辑模式有两种类型的键：代理键（Surrogate keys）或者业务键。代理键被用来表示表之间的内部关系。业务键（Business keys，有时也称为natural keys）是为了从业务本身中标识一个实体。因此，例如，尽管厂商被代理键(使用一个标识的属性，例如1-n)指定的时候，但在外部世界，它们自然键(natural keys)是一个厂商编号－例如，厂商#7233703。对于真实的表，ETL过程都会将业务键映射到代理键，因此，当记录被暴露到分析服务的时候，事务就已经发生。

在我们的案例中，代理键被用来跟踪第二种类型缓慢变化维度。你将发现，所有的维度键属性都使用了代理键列。我们在维度键属性上不使用自然业务键，因为多个第二种变化类型记录可能会有相同的业务键。尽管各种类型和缓慢变化维度的使用已经超出了本文的范围，但数据模型本身还是在推断的成员中使用了第一种类型和第二种类型缓慢变化维度用来插入，可以参见Project REAL: Business Intelligence ETL Design Practices 白皮书。我们也推荐在http://search.barnesandnoble.com/ booksearch/isbnInquiry.asp?isbn=0471200247网站上的Ralph Kimball的书籍《The Data Warehouse Toolkit, Wiley, 2nd edition》

层次（hierarchies）

尽管维度在报表中给出了度量的上下文和意思，但终端用户实际使用的分析对象是层次（hierarchies）。SQL Server 2005分析服务中，提供了两种类型的层次：属性层次（attribute hierarchies）和用户定义层次（user-defined hierarchies）。

在层次中是各个级别的集合。层次中每个Drilldown就是一个级别。例如Time层次中包含Year、Quarter、Month、Week和Day几个级别。在Book层次中（Project REAL中还用Item来表示）有Type、Subject、Category、SubCategory和Item级别。

报告层次（Reporting hierarchies）

第一个用户定义层次类型是报告层次。这个层次仅仅是用来报告的。潜在的数据并不支持各个级别上的关联信息。例如，我们有一个报告层次被设置成ALL->Author->Item。这样报告的目的仅仅是因为一个Item能够决定一本书，而其它的却不行。在层次中将作者放到Item前面，将产生一个多对多的关系。

自然层次（Natural hierarchies）

另外一种层次类型是自然层次，也被称为强层次（strong hierarchy）。在自然层次中，层次中的数据和其它的层次都有一个多对一的关系。日上 滚到周；周上滚到月；月上滚到季；季上滚到年。这将允许系统能够预先计算一个上滚动作或者是集合，例如为获得根据City的Store Sale的子集，然后根据City计算State；根据State计算Region；根据Region计算国家（这些求和都是基于层次的）。你能够重新打破或者再细分这些自然层次，因为每个成员都有且只有一个父亲。

自然用户定义层次不是SQL Server 2005新带的属性。它们在分析服务的早先版本中就存在。新的在于一种报高层次，它们是使用属性层次来构建的。

属性层次（Attribute hierarchies）

属性层次是SQL Server 2005中一个新的层次类型。它是基于维度表中的属性或者列。本质上任何数据库中的列都能成为维度的属性。当一个属性被定义到一个维度，一个属性层次就生成了。这意味着，如果时间维度表有一个Holiaday列，它只使用0或者1来表示某天是否是假期，然后你能够基于这个列创建一个Holiday属性层次。属性层次是平直的（Flat）。当一个层次只有两个级别的时候，我们称它为平直的。这两个级别是：所有的级别（把属性的所有值都加起来得到一个总的值）；另外一个就是它自己。由于Holiday作为一个在用户定义层次中的独立的层次存在并使用，因此终端用户能够通过Holiday实现销售情况的分析。SQL Server 2000分析服务中有一个类似的概念，叫做虚拟维度(virtual dimension)。尽管使用虚拟维度，你能够基于每个成员属性创建一个维度，但虚拟维度在范围和伸缩性上都有很大的局限性。

基于层次系统（hierarchie-based systems）和基于属性系统（attribute-based systems）的对比

这是两个SQL Server 发布版本重要的、基础性的区别。

SQL Server 2000分析服务是一个基于层次的系统。内部结构都导向层次或者级别。这包括了，像集合，是级别的一个捆绑，每个都针对一个维度；像虚拟维度，将成员属性提升为维度。一个维度智能有一个层次。多层次是一个命名惯例。两个时间层次，例如Time.Calendar 和Time.Fiscal，看上去，它们都和Time相关，但在内部，这是两个不同的维度，只是恰好它们的名字上都有Time。一个名称为Product的维度也有可能是名称为Product的层次。在维度和层次之间没有严格的差别。

SQL Server 2005 分析服务是一个基于属性的系统。属性是构建对象的基础。集合是捆绑属性的求和。默认情况下，属性层次会自动的为属性创建。一个维度能有多个层次。在一个时间维度中，Time.Calendar和Time.Fiscal是两个层次(Calendar和Fiscal)。用户定义层次（例如Calendar和Fiscal）纯粹的用来导航实体。它们存在不仅仅是为了辅助属性的组织。你马上将会看到，这样的概念将在整个文章中被反复的出现。

维度中使用了如此多的逻辑结构。现在，让我们来看看维度的一些物理特性。在这里，我们首先讨论它们使用的内存。