数据源和数据资源视图

数据源是你在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数据库构建的维度是很重要的。

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

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/16475407/viewspace-614124/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/16475407/viewspace-614124/