Partitionnement fondé sur l’utilisation

taille, la version réduite contient moins de membres. Pour couvrir le même nombre de membres que dans une partition importante, Analysis Services peut être amené à effectuer plus d’analyses de multiples partitions de petite taille. Par conséquent, le temps et les ressources nécessaires à l’exécution de calculs sur le résultat de plusieurs partitions peuvent annuler l’avantage de la rapidité d’analyse procurée par chacune des partitions de taille réduite.

Le choix du partitionnement d’un cube dépend des requêtes que vous allez exécuter. En toute logique, vous pouvez décider de partitionner en fonction de tout n-uplet spécifié par une requête. Par exemple, pour améliorer les performances du listing 2, vous pouvez être tenté de partitionner en fonction de chaque n-uplet de la jointure croisée de {Time.[1998], Time.[1999], Time.[2000]}, [Occupant_ Severity].Members (6 membres) et [Street].[Street_ List].Members (environ 30 000 membres). Dans ce cas, vous allez créer des partitions sur un total de 540°000°n-uplets (3 x 6 x 30 000 = 540°000). Ce plan, en apparence simple, aboutit à deux problèmes. Premièrement, l’analyse de 540°000 partitions et la synthèse de 3 années pour chaque n-uplet de gravité et d’intersections (soit 180°000 n-uplets au total) aura une incidence non négligeable sur les performances. Deuxièmement, le temps et le travail nécessaires à la création et au traitement de 540°000 partitions, que ce soit manuellement pour par programmation à l’aide d’objets DSO (Decision Support Objects), sont astronomiques.

La charge excessive ainsi générée en termes de performances lorsque vous partitionnez en fonction de chaque nuplet d’une requête constitue un problème sérieux pour un certain nombre de raisons. Premièrement, la requête du listing 2 n’est pas supposée retourner chaque année individuellement.

Elle droit renvoyer uniquement le cumul des incidents sur 3 ans. Un partitionnement efficace inclura les trois années spécifiées afin qu’Analysis Services calcule uniquement la somme au sein de la partition. Deuxièmement, la requête ne se contente pas d’accéder à une seule intersection, mais analyse toutes les intersections indépendamment des partitions créées. Le fait de pouvoir accéder directement à une intersection spécifique n’améliore pas les performances car il reste nécessaire de parcourir toutes les partitions.

Il vaut mieux conserver toutes les intersections dans la même partition. Le point crucial est que vous devez partitionner en fonction d’un n-uplet uniquement si la partition évite à votre requête d’effectuer une analyse séquentielle pour le n-uplet en question.