Project 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属性的键也有两个列。问题就得到了修复。

共20页: 4 下一页

【内容导航】

原文：Project REAL分析服务技术探讨(4)