考慮建立所有可能的聚集組合是不切實際的。比如，一個非常簡單的事實表僅有四個維度，並且每個維度具有三個用於聚集的候選屬性，則可能得到的不同聚集事實表的數日多達 256。 由於不可能建立、存儲與管理所有這些聚集事實表，因此，在設計聚集策略時需要考慮兩個基本因素。首先，需要考慮業務用戶的存取模式。換句話說，他們通常匆匆忙忙地對什麼樣的數據進行彙總?這個問題可以從業務需求分析的內幕知識，以及由監控實際應用模式得到的輸入內容中找到解答。其次，需要評估數據的統計分佈。例如，每個體系層有多少個獨特實例，以及從一個層次移到下一個層次時壓縮情況如何?比如，50 種產品堆積形成 10 個商標，那麼僅僅彙總 5 個基本行(平均)就可以算出商標聚集體。在這種情況 下，不值得花力氣預先物理地存儲聚集體。另一方面，如果通過存取聚集體可以避免接觸 100 個基本行，則顯得更有意義。聚集策略極大地減少了輸入輸出量。一般來說，聚集表所需要的磁盤空間大約是基本層次上數據所消耗的空間的兩倍。
在總體聚集策略中，聚集導航器(navigator)的可用性是另外一個考慮的因素。如果沒有聚集導航器，那麼供分析型用戶手工選取的聚集模式數目是非常有限的——很可能每個基本事實表存在數量不超過兩個的方案。聚集導航器在發出請求的客戶與關係型數據庫管理系統之間發揮作用。聚集導航器截取客戶的 SQL 請求，並且只要有可能就對其進行修改，以便存取性能得到改進的、最合適的聚集體。聚集導航器在爲客戶應用提供緩衝的同時，使聚集表的使用顯得富有成果。只要在加入或者刪除聚集體時對查詢進行改 寫，那麼客戶用不着專門給出二個查詢來存取與聚集事實表相對的特定基本表。聚集導航器處理現場中聚集數據量的變化，從而使客戶不去理會這些本不該理會的事情。
最後，應該將 OLAP 立方體的角色作爲聚集策略的組成部分進行考慮， 因爲它們特別適合於對彙總的數據做出迅速的響應。有些產品還允許在立方體的聚集數據與關係型結構中的細節方案之間進行無縫集成。
