下行数据流多维数据集的分区

　　如果关系型数据库仅用于支持分析服务多维数据集，就不必定义 UNION ALL 视图。这种情况下，该应用程序就不会受 256 个表的限制，但是建议您不要以这种无法定义 UNION ALL 视图的方式来对关系型数据仓库进行分区。

　　在分区管理已能够自动进行并通过测试之前，分区的数据仓库不应该正式投入使用。分区管理系统是一种简单的应用程序，该系统的一般要求在下面讨论。

　　下面的讨论假设分区是按日期进行的。

　　稳定的分区管理系统应由元数据驱动。只要确保能够编程访问元数据，就可以把元数据存储在任何位置。大多数数据仓库系统使用在数据仓库 SQL Server 或 Microsoft SQL Server Meta Data Services 上定义的自定义元数据表。

　　不论元数据的存储机制是什么，元数据的内容必须包括每个分区的以下信息：

• 分区名称
  
  
• 创建分区的日期
  
  
• 分区中数据的日期范围
  
  
• 分区开始联机的日期（加入 UNION ALL 视图）
  
  
• 分区不再联机的日期（从视图中丢弃）
  
  
• 丢弃分区的日期

　　作为数据仓库整个管理系统的一部分的其他元数据表，应该跟踪何时以及有多少数据被加载到每个分区。

　　分区管理系统的首要任务是创建新分区。应该安排周期性运行的任务，来创建用作下一个分区的新表。

　　执行该任务有许多有效的方式。建议的方法为使用 SQL-DMO（分布式管理对象）来创建与现有分区具有相同结构和索引的新表，但新表具有新的表名、索引名、分区键约束定义、文件组等等：

• 获取模板表定义（通常为最新的分区）；
  
  
• 修改表和索引的 Name 属性，检查约束 Text 属性和其他属性；
  
  
• 使用 ADD 方法对表进行实例化。

　　使用智能命名约定，用几行代码即可完成这项任务。

　　如本文后面将要讨论的那样，您的应用程序可以将分析服务分区用于数据仓库系统的多维数据集。如果这样，在 RDBMS 中创建分区的脚本和程序可以使用决策支持对象 (DSO) 继续创建相应的多维数据集分区。

　　前面提到过，数据可以被加载入 UNION ALL 视图。理论上，这是表分区结构的一大功能，但在实践中不推荐将其用于数据仓库应用程序。不能将数据批量加载到 UNION ALL 视图；对于大到必须对表进行分区的数据仓库来说，加载进程将会太慢。

　　相反，数据仓库应用程序的设计必须使每一个周期都可以把数据快速加载到相应的目标表。如果数据分阶段应用程序在 SQL Server 数据转换服务 (DTS) 中实现，动态属性任务可以很容易地更改数据泵任务或批量插入任务的目标表的名称。

　　只要新分区没有加入 UNION ALL 视图，就不需要在系统停机时间加载数据。

　　数据仓库分阶段应用程序应该设计为可以处理不属于当前分区的新数据。如果数据仓库加载进程不是在一个夜晚完成，就可能发生这种特殊情况。其他系统要处理不断到来的旧数据。系统的设计必须考虑到这些例外情况的可能性、频率和数据量。

　　如果旧数据以足够低的量到达，最简单的设计就是使用可更新的 UNION ALL 视图来加载所有不属于当前分区的数据。

　　一旦渐变加载成功完成，就必须重新修订 UNION ALL 视图。仍然建议使用 SQL-DMO 完成本任务：使用 ALTER 方法更改 VIEW 对象的 TEXT 属性。从上面所述的元数据表中导出视图定义中要包括的分区列表是最佳途径。

　　表面上看来，将若干分区合并至单个较大分区似乎是多余的。不过，对于日加载量巨大同时加载窗口很小的数据仓库，通过下列措施可以显著改善加载性能：

• 用要加载的数据创建文本文件，按簇索引的顺序排序。
  
  
• 批量加载到空的日分区。
  
  
• 创建所有的非簇索引。
  
  
• 通过重新创建 UNION ALL 视图，使新分区保持联机。
  
  
• 通过自日分区插入、重新创建索引和重新生成 UNION ALL 视图，每周创建和填充新的周分区。然后就可以丢弃日分区。
  
  
• 数据变得陈旧后就移动至周甚至月分区，这样更多的分区可以联机保留在 UNION ALL 视图中。