高级分区片和筛选
　　大多数分区策略是将一个矢量级别定为分区，将该矢量的每个成员的数据放入各自的分区。例如，“按年分区”或“按州分区”。
　　
　　抽取多维数据集某个部分的分区计划也很常见。例如，较新数据可能按日或星期分区，但较旧的数据按月或年分区。
　　
　　根据使用方式和数据基数不同，可能会需要设计更为复杂的分区计划。例如，假设客户中的 80% 居住在加利福尼亚、10% 居住在俄勒冈，其余 10% 平均分布在这个国家的其他地区。另外，大多数分析集中在加利福尼亚的客户。这种情况下，管理员可能希望为加利福尼亚创建县级分区、为俄勒冈创建州级分区、为所有其他地区创建一个分区。
　　
　　该分区片可能会类似于：
　　
　　California counties: [All USA].[CA].[Amador] ... [All USA].[CA].[Yolo]
　　
　　Oregon state: [All USA].[OR]
　　
　　Rest of the country: [All USA]
　　
　　如前面所讨论的，必须正确定义源数据筛选，以确保正确填充这些分区。请注意，如果一个查询需要合并加利福尼亚和俄勒冈的数据，那么它可能也需要查看“Rest of the country”分区。尽管服务分析查看“Rest of the country”映射表以了解那里是否有相关数据的花销不大，但如果多维数据集统一按州分区，然后进一步分解 CA（加利福尼亚），查询性能会更好。维护不均匀分区的应用程序逻辑也更加复杂，通常不推荐这种分区方法。然而，如果适当考虑维护应用程序的设计，同时理解查询性能的取舍，这项技术可以用来解决某些特定的设计问题。
　　对齐分区
　　由于本文的前半部分讨论的是 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 个新的州分区。这种情况下，通过复制上个月的分区、编辑必要的属性（例如分区片和源表名）以及更新多维数据集中的分区定义来创建这个月的分区是安全的。
　　
　　然而，假设有一个按月和品牌分区的多维数据集。品牌比州或省容易变化得多；在多维数据集存在期间，向产品系列添加一个新品牌是很可能的。维护应用程序必须确保创建一个分区来容纳保留新品牌的数据。建议的做法为：
　　
　　在创建新分区之前处理矢量。
　　
　　复制现有的分区以确保存储模式和聚合计划的连续性。
　　
　　在已处理的矢量中搜索新成员，为分区级别的所有新成员创建一个分区。系统必须指定默认的存储模式和聚合计划。
　　必须仔细设计分区管理系统以确保分区片和筛选的定义是对齐的，并在一段时间后仍保持精确。如果关系型数据库是分区的，并且这些分区象本文前面所述的那样定期合并，分区管理系统就应该更新多维数据集分区定义，与源数据保持同步。多维数据集分区不需要重新处理，但在将来有必要重新处理时应该更改其定义。
　　
　　数据完整性
　　确保将数据处理进一个并且仅一个分区是多维数据集设计和分区管理系统的任务。分析服务不检查是否所有的行均来自在多维数据集中进行实例化的一个事实表，也不验证某一行是否仅加载到一个分区中。如果不经意地将一个事实行加载到两个分区，分析服务会把它们看作不同的事实。所有的聚合将重复计入该数据，查询将返回不正确的结果。
　　
　　处理分区
　　处理分区与处理多维数据集基本相同。对于处理任务，自然的工作单位就是一个分区。分析管理器处理向导为处理多维数据集或分区提供了以下三种模式：
　　
　　“渐变更新”向现有多维数据集或分区中添加新数据，更新和添加被该新数据影响的聚合。
　　
　　“刷新数据”丢弃多维数据集或分区中的所有数据和聚合，并重新生成多维数据集或分区中的数据。
　　
　　“全部过程”完全重新创建多维数据集或分区的结构，然后刷新数据和聚合。
　　渐变处理需要管理员在源查询上定义筛选条件，以识别多维数据集的新数据集。通常该筛选基于日期（存储在事实表中的事件日期或处理日期）。
　　
　　DTS 多维数据集处理任务提供了完全相同的功能。大多数系统使用 DTS 多维数据集处理任务来定时安排多维数据集处理。经过渐变处理的多维数据集使用动态属性任务来更改源筛选。尽管渐变更新比刷新数据需要的代码要多一些，DSO 中的自定义代码也提供了相同的功能。
　　
　　设计分区管理系统时，请特别注意正在处理的渐变多维数据集或正在处理的分区要求过去已经处理过的分区。请勿在未被处理的多维数据集或分区上使用渐变处理。
　　
　　仅按日期分区的多维数据集有直接加载管理的要求。典型情况下，每个加载循环有一个要更新的单个分区；唯一的决策点为是要渐变更新还是要刷新数据。大多数日期矢量多维数据集可从一个简单的 DTS 程序包中管理。
　　
　　按多个矢量分区的多维数据集具有以下额外的挑战和好处：
　　
　　挑战：有大量分区要处理
　　
　　挑战：分区数量可能会更改
　　
　　好处：可并行加载分区
　　
　　好处：选择性强的查询的性能可大大改善。
　　大多数在多个矢量上分区的应用程序将多维数据集处理系统设计为可以并行地加载分区。并行加载系统能够启动多个同时运行的 DTS 程序包，它们的参数已经用动态属性任务更新过。尽管可行，但这种结构不便于使用，相反许多系统会选择使用本机 DSO 代码来更新分区。可以获得并行处理分区的示例工具。