在Microsoft SQL Server 2000数据仓库中使用分区

对齐分区

由于本文的前半部分讨论的是 RDBMS 中的分区，读者很自然地会问服务分区是否必须与关系分区对齐。这两种分区策略不需要完全相同，但如果分区比较相似，分区管理应用程序更容易设计、创建和理解。常见的策略是在两个系统中按日期进行相同的分区，此外可以选择性地按多维数据集中的第二个甚至第三个矢量定义分区片。

最简单的策略就是使用 UNION ALL 视图作为所有多维数据集分区的源事实表。如果多维数据集分区与关系分区对齐，每个多维数据集分区都可以绕过 UNION ALL 视图直接指向它的相关联的关系分区。在这种配置中，从关系型数据库中提取数据的多维数据集处理查询将运行得最快。这种性能改善办法的代价是维护应用程序需要确保源表与每个分区都正确地相关联。

如果关系型数据库仅用于填充分析服务多维数据集，并不为其他查询提供服务，系统管理员可以选择不创建和管理 UNION ALL 视图。可适当设计关系表的索引，优化把数据加载到多维数据集的单个查询。这种情况下，关系型数据库的作用更象分阶段区域，而不是完全的数据仓库。

存储模式和聚合计划

每个分区可以拥有自己的存储和聚合计划。不经常被访问的数据可以是轻度聚合的，或作为 ROLAP 或 HOLAP 而不是 MOLAP 存储。由于更改这些参数需要重新处理分区，所以按时间渐变加载的多维数据集不大可能沿其分区的时间矢量使用此功能。大多数情形下，处理时间和系统复杂性的开销似乎使得最小多维数据集带来的节约变得几乎没有必要。

相反，沿其他矢量划分的分区可能具有不同的聚合计划。基于使用情况的优化向导可为每个分区设计聚合方式。系统管理员应该使优化向导集中于最近的分区，并以最近的分区上的每个新分区集的聚合设计作为基础，使聚合设计尽可能新。

管理分区多维数据集

开发人员可以使用不同的工具创建关系分区的管理系统。SQL-DMO 受到极力推荐，不过使用存储过程、扩展存储过程、甚至解析包含表定义的文本文件的 Perl 脚本也已经生成了有效的系统。相反，多维数据集分区维护程序必须使用 DSO。

对于具有传统数据库背景的开发人员而言，使用对象模型对数据库对象进行实例化的想法似乎有些不好理解。开发人员可以使用熟悉的脚本编程语言，例如 Microsoft® Visual Basic® Scripting Edition (VBScript)、Microsoft® JScript®、Perl 或类似于 Visual Basic (VB) 或 C++ 的开发环境来开发使用 DMO 和 DSO 的模块。这些模块可以从操作系统或 SQL-Agent 中定时执行，或从 DTS 程序包中调用。即使开发人员以前从未使用过对象模型，也不能因为要求用 DSO 创建管理系统而放弃使用分区。本文后面将提供一个 VBScript 示例来说明如何使用脚本复制分区。

如果关系型数据仓库使用分区，多维数据集分区管理系统应该设计为关系型数据库分区管理系统的一部分。多维数据集分区管理系统必须具有以下功能：

创建新分区

分区管理系统在关系型数据库中创建新日期分区的同时，它应该创建与该日期相对应的所有的必要的多维数据集分区。由于可能沿分区片之一添加新矢量成员，所以在创建新分区前，渐变更新多维数据集矢量是比较好的做法。

最简单的情况是多维数据集仅按日期分区。分区管理系统只是按适当的时间周期（日、星期、月等等）创建一个新分区。

除了按日期分区外，如果按另一矢量对多维数据集进行分区，分区管理系统将一次添加许多分区。例如，以一个按月和按美国各州分区的多维数据集为例。系统每个月都会创建 50 个新的州分区。这种情况下，通过复制上个月的分区、编辑必要的属性（例如分区片和源表名）以及更新多维数据集中的分区定义来创建这个月的分区是安全的。

然而，假设有一个按月和品牌分区的多维数据集。品牌比州或省容易变化得多；在多维数据集存在期间，向产品系列添加一个新品牌是很可能的。维护应用程序必须确保创建一个分区来容纳保留新品牌的数据。建议的做法为：

必须仔细设计分区管理系统以确保分区片和筛选的定义是对齐的，并在一段时间后仍保持精确。如果关系型数据库是分区的，并且这些分区象本文前面所述的那样定期合并，分区管理系统就应该更新多维数据集分区定义，与源数据保持同步。多维数据集分区不需要重新处理，但在将来有必要重新处理时应该更改其定义。