Project REAL分析服务技术探讨
来源: 数据库 SQL Server | 作者: landluo | 发布: 2009-7-08 10:09
最佳实践：在时间维度向导中，为各个属性输入键列（非名称列），例如年、月、周。
选择键的好处在于，少后，你仅需要改变成员的名称。默认情况下，向导将把Order By属性设置到键上。因此，如果在这里输入一个键列，你稍后需要改变就仅仅是名称列。
在你运行完向导后，当我们开始涉及确定定义的时候，请牢记对成员键唯一性的要求。在这个时候，我们很容易去使用传统的键和名称。例如，你可能会把Q1，Q2，Q3，Q4作为名称或者键；或者你也可能像下面这种情况使用键值：用1代表1月，……，12代表12月。尽管数据库管理员都记得他们按照特定的顺序使用1…12作为月份的键值（否则4月有可能成为每年的第一个月），但我们并不能总是牢记这些顺序，因此值为Q2的季节或者值为4的月份并能够唯一的确定一个键。你经常需要回过头去，为成员键创建一个集合，并将年份添加到集合中以确定其唯一性。
不要忘记忘记给你创建的多层次对象创建属性关系。例如，在日和周之间、周和月之间、月和季之间以及季和年之间，创建一个属性关系。就像键的唯一性一样，如果你想要系统良好运行，这种关系也很重要。
一旦你确定了成员的名称，就需要确保时间层次上各属性键的唯一，需要建立一个属性关系用来支持你已经定义的多个层次，你也可以添加其它时间相关的属性，比如周末、假期和季节指示器等。
虽然时间看上去是一个简单的概念（毕竟，它只是一个时间戳而已），但你还需要在构建数据库表和分析服务对象上花费你大量的设计时间，以确保它们已被适当的设置。
度量组
Project REAL实现的关系型数据模型包括三张实际的表：Store Sales、Store Inventory、和Distribution Center Inventory。物理上，为处理大量的数据(例如，每周约1.4亿-2.0亿条存货记录)，需要按周来分割这三张实体表。分割是很重要的，因为：
◆这能提供更好的性能。查询只会扫描覆盖某个时段的分割表。一般情况下，这些分割表越多，它们就越小，查询就会执行的更快。
◆更容易删除数据。简单的删除分割表，就能删除数据。你不必再重新处理任何Cube。正常情况下，从一个实际的表中删除数据，都需要重新处理Cube。
◆更容易实现起伏不定的周期。例如，假定一个系统需要保存最近三年有价值的历史数据。你可以按不同的周期来获得分割表，累积到36个月即可。这比从某个固定日期开始，要好很多。新的分割表按照每周或者每月不断的被创建。三年以前的分割表就能直接被删除。
一个对SQL Server 2000分析服务应用很熟练的用户会注意到Project REAL设计中一个有趣的事情：所有的度量组都是包含再一个单一的Cube中。度量组提供了一个在SQL Server 2000分析服务中被称为Cube的对象。一个Cube就是一个实际的表，它会连接到维度的一个子集，这个子集在数据库中可以按指定的粒度使用。一个真实表粒度是各种维度里面级别最低的。SQL Server 2000分析服务有一个称为虚拟Cube的特性，允许你将各不相同的Cube聚合到一个简单框架中。在SQL Server 2005分析服务中，一个Cube就是一个这样的简单框架。现在的度量组就是捕获各种粒度的维度子集。
如果你想使用一个虚拟的Cube，可以使用在多个Cube之间连接的度量组来创建虚拟Cube。这些连接的Cube(老式的Cube)每个都带有一个简单度量组。事实上，这就是分析服务迁移向导(Analysis Services Migration Wizard)所创建的内容。它这样作，也是想要把SQL Server 2000数据库分析服务和SQL Server 2005数据库分析服务中的对象数目和类型保持一致。
这种Metacube方法既有正面的意义，也带来了一些消极作用。通过这种方法，所有的事物都被丢到简单的Cube中。这种方法最重要的优点在于，由于构建Cube的方法，使得终端用户用户不必强加人为的界限，就可以去连接或者查询。终端用户看到的是度量值的集合。在用户如何查询Cube的基础上，系统可以动态的调整必要的度量组。
计算是类似的。你只需创建一个简单的Cube包含所有你提供的计算，系统就会根据它们做出自我调整。若要得到更多关于这种丰富的对象空间(所有的事物都在一个简单”罐子”中)，可以查看AdventureWorksDW 分析服务数据库。这个数据库中包含了18个维度、154个属性层次、18个用户定义层次、超过100个计算以及9个度量组（每个粒度都不相同），并且所有对象都在一个Cube中，这太棒了。
无论如何，这种方法都会带来一些成本。最明显的程序是需要过渡很多对象。你需要客户端应用程序能够处理SQL Server 2005种的对象，例如显示文件夹或者透视图等。这些对象允许你将对象组织到不同的功能分类中，这样，用户能够更好的记住各对象可以应用的选项。
这个方法带来的第二个成本是执行一个完成的维度过程会对所有使用这个维度的度量组重置状态。这既包含了度量组，也包含了这些度量组的分割表。我们是在测试执行一个Vendor Type 维度(只包含五个成员)的过程中，意外的发现这点的。我们不得不回过头去，重新处理基于Sales 和Item Vendor度量组的153个分割表。显而易见，完成这个过程需要大量的时间。我们决定除非迫不得已，我们将不这么做。并且这可能导致更坏的结果。如果我们完成一个Measures 维度(只有一个成员)的过程，这将影响到所有的度量组。完成这个过程，会涉及2G的数据，需要在3天后才能得到结果。
如早先提到的那样，实际表中包含了以下三种信息：
◆实际表的粒度已经在它的维度中体现出来。每个维度都会有个外部键，用来指向在适当级别/属性的维度表。在Project REAL中，这些就是代理键(surrogate keys)，这些键都是通过系统生成的，因此我们能实现第二种类型缓慢变化维度。这些代理键被连接的级别代表了这个维度的粒度。例如，时间维度键可能是Month。另外一个实际表可以是Day。对于其它的维度，这些键可以是Item和Store
◆并不是所有的维度都必须出现在度量组中。例如， Store Inventory和DC Inventory 度量组不必做任何基于Vendors的分析。因此，它们不必包括Vendor 和Vendor Type两个维度。
在Project REAL中，各个Cube的粒度如图13所示：
图13：在Cube编辑器中的维度-度量组映射图
◆实际表包含的度量是我们需要在解决方案中报告的数据。在我们的案例中，Sales 实际表包含的度量有销售总计、销售数量、折扣数量和优惠券数量。
◆另外，实际表也可以包含一些附加的信息（被称为degenerate keys），但不会指向维度。但这些附加的信息自己可以包含维度。例如，对于Store Sales，实际表可以包含销售条目的注册数目。在Project REAL的实际表中，没有degenerate keys。
内部上，分析服务在每个度量组存储了大量的信息。下一个章节描述了跟度量组相关的信息子集(也是包含在设计细节中的)。
共20页: 12 下一页
【内容导航】
原文：Project REAL分析服务技术探讨(12)