分区键的选择
　　事实表可以在多个矢量上进行分区，但是大多数人可能仅按日期进行分区。如前面描述的，日期分区可以支持简单的“滚动窗口”管理, 较旧的分区甚至可以被保存在不同的位置，或者减少索引次数。同样，大多数对数据仓库的查询是按日期进行筛选的。
　　
　　对于按日期分区的应用程序，决策变量为：
　　
　　使多少数据保持联机状态？这项决策的主要依据是业务要求，同时要考虑保持大量数据联机的费效比。
　　
　　如何设计日期键？数据仓库最好对矢量表和事实表使用代理键，这是得到广泛认可的。对于按日期分区的事实表，建议的做法为使用 yyyymmdd 形式的“智能”整数代理键。作为整数，与 8 字节的 datetime 相比较，该键仅使用 4 个字节。许多数据仓库使用 datetime 类型的自然日期键。
　　
　　如何确定分区的大小？尽管上面的示例使用年分区，但大多数系统会划分得更细致，例如月、星期或天。尽管我们会注意到用户查询通常是按月或周进行的，但最重要的因素还是系统总体规模和可管理性。您可能还记得，任何一个 SQL 查询最多可以引用 256 张表。对于维护多于一个月的数据的数据仓库，按天来分区的 UNION ALL 视图会超过该界限。作为一个好的规则，如果事实表仅按日期分区，那么最好按星期分区。
　　
　　如何定义分区的范围？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 上定义的自定义元数据表。
　　
　　不论元数据的存储机制是什么，元数据的内容必须包括每个分区的以下信息：
　　
　　分区名称
　　创建分区的日期
　　
　　分区中数据的日期范围
　　
　　分区开始联机的日期（加入 UNION ALL 视图）
　　
　　分区不再联机的日期（从视图中丢弃）
　　
　　丢弃分区的日期
　　作为数据仓库整个管理系统的一部分的其他元数据表，应该跟踪何时以及有多少数据被加载到每个分区。
　　
　　创建新分区
　　分区管理系统的首要任务是创建新分区。应该安排周期性运行的任务，来创建用作下一个分区的新表。
　　
　　执行该任务有许多有效的方式。建议的方法为使用 SQL-DMO（分布式管理对象）来创建与现有分区具有相同结构和索引的新表，但新表具有新的表名、索引名、分区键约束定义、文件组等等：
　　
　　获取模板表定义（通常为最新的分区）；
　　
　　修改表和索引的 Name 属性，检查约束 Text 属性和其他属性；
　　
　　使用 ADD 方法对表进行实例化。
　　使用智能命名约定，用几行代码即可完成这项任务。
　　
　　如本文后面将要讨论的那样，您的应用程序可以将分析服务分区用于数据仓库系统的多维数据集。如果这样，在 RDBMS 中创建分区的脚本和程序可以使用决策支持对象 (DSO) 继续创建相应的多维数据集分区。
　　
　　填充分区
　　前面提到过，数据可以被加载入 UNION ALL 视图。理论上，这是表分区结构的一大功能，但在实践中不推荐将其用于数据仓库应用程序。不能将数据批量加载到 UNION ALL 视图；对于大到必须对表进行分区的数据仓库来说，加载进程将会太慢。
　　
　　相反，数据仓库应用程序的设计必须使每一个周期都可以把数据快速加载到相应的目标表。如果数据分阶段应用程序在 SQL Server 数据转换服务 (DTS) 中实现，动态属性任务可以很容易地更改数据泵任务或批量插入任务的目标表的名称。
　　
　　只要新分区没有加入 UNION ALL 视图，就不需要在系统停机时间加载数据。
　　
　　数据仓库分阶段应用程序应该设计为可以处理不属于当前分区的新数据。如果数据仓库加载进程不是在一个夜晚完成，就可能发生这种特殊情况。其他系统要处理不断到来的旧数据。系统的设计必须考虑到这些例外情况的可能性、频率和数据量。
　　
　　如果旧数据以足够低的量到达，最简单的设计就是使用可更新的 UNION ALL 视图来加载所有不属于当前分区的数据。