建立数据仓库---- 聚集策略

        每个数据仓库都应该包含预先计算并预先保存的聚集表。如果给定了严格避免出现混合事实表粒度的规则，则每个独特事实表聚集都应该拥有聚集的物理事实表。在对事实进行聚集操作时，要么消除维度性，要么将事实与堆积维度联系起来。这些堆积形成的聚集维度事实表应该是与基本粒度事实表相联系的维度压缩版本。这样，聚集维度表与基本维度表就能保持一致。

       考虑建立所有可能的聚集组合是不切实际的。比如，一个非常简单的事实表仅有四个维度，并且每个维度具有三个用于聚集的候选属性，则可能得到的不同聚集事实表的数日多达 256。 由于不可能建立、存储与管理所有这些聚集事实表，因此，在设计聚集策略时需要考虑两个基本因素。首先，需要考虑业务用户的存取模式。换句话说，他们通常匆匆忙忙地对什么样的数据进行汇总?这个问题可以从业务需求分析的内幕知识，以及由监控实际应用模式得到的输入内容中找到解答。其次，需要评估数据的统计分布。例如，每个体系层有多少个独特实例，以及从一个层次移到下一个层次时压缩情况如何?比如，50 种产品堆积形成 10 个商标，那么仅仅汇总 5 个基本行(平均)就可以算出商标聚集体。在这种情况 下，不值得花力气预先物理地存储聚集体。另一方面，如果通过存取聚集体可以避免接触 100 个基本行，则显得更有意义。聚集策略极大地减少了输入输出量。一般来说，聚集表所需要的磁盘空间大约是基本层次上数据所消耗的空间的两倍。

       在总体聚集策略中，聚集导航器(navigator)的可用性是另外一个考虑的因素。如果没有聚集导航器，那么供分析型用户手工选取的聚集模式数目是非常有限的——很可能每个基本事实表存在数量不超过两个的方案。聚集导航器在发出请求的客户与关系型数据库管理系统之间发挥作用。聚集导航器截取客户的 SQL 请求，并且只要有可能就对其进行修改，以便存取性能得到改进的、最合适的聚集体。聚集导航器在为客户应用提供缓冲的同时，使聚集表的使用显得富有成果。只要在加入或者删除聚集体时对查询进行改 写，那么客户用不着专门给出二个查询来存取与聚集事实表相对的特定基本表。聚集导航器处理现场中聚集数据量的变化，从而使客户不去理会这些本不该理会的事情。

        最后，应该将 OLAP  立方体的角色作为聚集策略的组成部分进行考虑， 因为它们特别适合于对汇总的数据做出迅速的响应。有些产品还允许在立方体的聚集数据与关系型结构中的细节方案之间进行无缝集成。