开发人员可以使用不同的工具创建关系分区的管理系统。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 个新的州分区。这种情况下，通过复制上个月的分区、编辑必要的属性（例如分区片和源表名）以及更新多维数据集中的分区定义来创建这个月的分区是安全的。

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

• 在创建新分区之前处理矢量。
  
  
• 复制现有的分区以确保存储模式和聚合计划的连续性。
  
  
• 在已处理的矢量中搜索新成员，为分区级别的所有新成员创建一个分区。系统必须指定默认的存储模式和聚合计划。

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

　　确保将数据处理进一个并且仅一个分区是多维数据集设计和分区管理系统的任务。分析服务不检查是否所有的行均来自在多维数据集中进行实例化的一个事实表，也不验证某一行是否仅加载到一个分区中。如果不经意地将一个事实行加载到两个分区，分析服务会把它们看作不同的事实。所有的聚合将重复计入该数据，查询将返回不正确的结果。

　　处理分区与处理多维数据集基本相同。对于处理任务，自然的工作单位就是一个分区。分析管理器处理向导为处理多维数据集或分区提供了以下三种模式：

• “渐变更新”向现有多维数据集或分区中添加新数据，更新和添加被该新数据影响的聚合。
  
  
• “刷新数据”丢弃多维数据集或分区中的所有数据和聚合，并重新生成多维数据集或分区中的数据。
  
  
• “全部过程”完全重新创建多维数据集或分区的结构，然后刷新数据和聚合。

　　渐变处理需要管理员在源查询上定义筛选条件，以识别多维数据集的新数据集。通常该筛选基于日期（存储在事实表中的事件日期或处理日期）。

　　DTS 多维数据集处理任务提供了完全相同的功能。大多数系统使用 DTS 多维数据集处理任务来定时安排多维数据集处理。经过渐变处理的多维数据集使用动态属性任务来更改源筛选。尽管渐变更新比刷新数据需要的代码要多一些，DSO 中的自定义代码也提供了相同的功能。

　　设计分区管理系统时，请特别注意正在处理的渐变多维数据集或正在处理的分区要求过去已经处理过的分区。请勿在未被处理的多维数据集或分区上使用渐变处理。

　　仅按日期分区的多维数据集有直接加载管理的要求。典型情况下，每个加载循环有一个要更新的单个分区；唯一的决策点为是要渐变更新还是要刷新数据。大多数日期矢量多维数据集可从一个简单的 DTS 程序包中管理。

按多个矢量分区的多维数据集具有以下额外的挑战和好处：

• 挑战：有大量分区要处理
  
  
• 挑战：分区数量可能会更改
  
  
• 好处：可并行加载分区
  
  
• 好处：选择性强的查询的性能可大大改善。

　　大多数在多个矢量上分区的应用程序将多维数据集处理系统设计为可以并行地加载分区。并行加载系统能够启动多个同时运行的 DTS 程序包，它们的参数已经用动态属性任务更新过。尽管可行，但这种结构不便于使用，相反许多系统会选择使用本机 DSO 代码来更新分区。可以获得并行处理分区的示例工具。

　　对于沿日期分区的多维数据集，它的分区的数量会随时间流逝而增长。如前面所述，分区数量增加到一定程度后，理论上存在着一个查询性能开始降低的点。我们测试了包括 500 个以上分区的开发项目，但还没有达到过这个极限。由于过多分区的其他缺点，例如源数据操作缓慢等，将给管理数据库带来更多的困难，系统管理员在达到该极限之前往往就已不能忍受它了。

　　通过 DSO 和分析管理器，分析服务支持合并分区的功能。合并两个分区时，一个分区的数据将合并到另一个分区中。两个分区必须具有相同的存储模式和聚合计划。合并完成后，第一个分区被丢弃，第二个分区则包含合并的数据。合并处理仅发生在多维数据集数据上；合并过程中不访问数据源。两个分区的合并过程的效率很高。

　　如果系统设计包括合并的分区，合并过程应该通过编程进行，而不是通过分析管理器。合并分区很简单，和其他 DSO 操作一样只需要几行代码。分区合并系统必须负责验证最终合并的分区包含用于源筛选的精确元数据信息，以确保必要时可以重新处理分区。分区合并过程正确地更改分区片定义，也尽可能合并筛选定义。但合并过程不要求从相同的表或数据源填充两个分区，合并两个不能被重新填充的分区是可能的。

　　第二个要考虑的问题是：与所有分区一样，已合并的分区不能被重新命名。

　　通过使用以下良好的系统设计方法可以避免这些问题：

• 使用清晰的命名约定。
  
  
• 遵循一致的分区合并计划。
  
  
• 匹配分区多维数据集和关系分区时要小心，或不对关系型数据仓库进行分区。

　　例如，考虑按星期分区数据的“销售额”多维数据集。本周按日进行分区，然后在本周末合并。将分区命名为 Sales_yyyymmdd，其中名称中的日期是分区中数据的第一天。2000 年 11 月，我们将会有 Sales_20001105、Sales_20001112、Sales_20001119 和 Sales_20001126 周分区。下周里，我们通过 Sales_20001209 创建和处理 Sales_20001203、Sales_20001204 等。在星期天的处理窗口期间（那时系统使用率很低），我们可以把从 20001204 到 20001209 合并至 Sales_20001203，仅留下周分区。或者，您可以通过新建一个有您想要的名称的空分区，将其他分区合并进去，从而有效地重新命名一个分区。