SQL Server 2000 数据仓库中使用分区(4)

定义分区的范围

BETWEEN 语法最直接、可读性最强、执行效率最高。以下述形式的按月分区为例：

date_key < 19990101
date_key BETWEEN 1990101 AND 19990131
date_key BETWEEN 19990201 AND 19990229
...
date_key BETWEEN 19991201 AND 19991231
date_key > 19991231

请注意其中的第一个和最后一个分区：即使您认为决不会有数据进入这些分区，这仍是一个定义分区的好方法，这样可以覆盖所有可能的日期值。同时，请注意尽管 1999 年不是闰年，但二月分区仍覆盖 2 月 29 日。该结构使设计创建分区和约束的应用程序时不需要判断是否为闰年。

随着时间流逝，要合并分区吗？为了使活动分区的数量最小，创建分区应用程序时，数据库管理员可以选择将日分区合并为星期分区或月分区。我们将在下面有关填充和维护分区的一节中详细讨论这种方法。

关于如何按日期分区的详细讨论同样适用于采用其他可能的分区键时的情形。

数据加载：如果新的数据具有与其他矢量对齐的明显倾向，或者例如，如果每个存储或附件是由不同的系统分发的，这些就是自然的分区键。

多维数据集数据查询：尽管并没有技术原因要求以相同的方式对关系型数据库和分析服务多维数据集进行分区，但这是通常采用的做法。如果做出这个假设，维护应用程序将得以简化。这样，即使关系型数据库的存在仅是用于填充分析服务多维数据集，在选择分区键时也应该考虑到一般的查询模式。

命名约定:命名水平分区事实表的成员表的规则应该从分区设计自然地引出。为获得最大的通用性，请在标题中使用完整的分区开始日期：即使分区每年进行一次，[sales_fact_yyyymmdd] 也比[sales_fact_yyyy] 好。

如果数据库支持多个大小的分区，命名约定应该反映每个分区的时间范围。例如，月分区使用 sales_fact_20001101m，日分区使用 sales_fact_20001101d。

成员表的名称对通过视图访问数据的最终用户是隐藏的，因此成员表的名称应该面向执行维护的应用程序。

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

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

管理分区事实表

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

假设分区是按日期进行

元数据

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