2013-02-12 1 views
3

Dans mon cube SSAS, plusieurs mesures définies dans MDX fonctionnent correctement, sauf dans un type d'agrégation sur plusieurs périodes. Certains ne s'agrègent pas (et ne sont pas destinés à) mais on agrège mais donne les mauvaises réponses. Je peux voir pourquoi, mais pas ce qu'il faut faire pour l'empêcher. Le total mis en évidence dans la capture d'écran Excel ci-dessous (sacrément, pas autorisé à inclure une image, revenant à l'ancienne table) est le cas le plus simple de ce qui ne va pas. Dans cet exemple, 23 621 est et non le total général de 5 713 et 6 837.Agrégation d'une mesure calculée MDX lorsque plusieurs périodes sont sélectionnées

 Active Commitments Acquisitions Net Lost Commitments Growth in Commitments 
2009 88,526    13,185   5,713     7,472 
2010 92,125    10,436   6,837     3,599 
Total      23,621   23,621 
  1. Engagements actifs fonctionne très bien. Il est calculé pour un moment précis et ne doit pas être agrégé sur plusieurs périodes.
  2. Les acquisitions fonctionnent bien.
  3. [Augmentation des engagements] = ([Mesures]. [Engagements actifs], [Date Dimension]. [Exercice hiérarchique] .currentMember) - ([Mesures]. [Engagements actifs], [Date Dimension .] [exercice Hiérarchie] .prevMember)
  4. [mesures] [engagements nets perdus] = ([mesures] [acquisitions] -... [mesures] [de croissance des engagements])

ce qui se passe dans la capture d'écran, le total des engagements nets perdus est calculé à partir du total des acquisitions (23 621) moins le total de la croissance des engagements (qui est nul).

L'agrégation des engagements perdus nets est logique et fonctionne pour les dimensions hors temps. Mais je veux qu'il montre null lorsque plusieurs périodes sont sélectionnées plutôt qu'une valeur erronée. Notez que ce n'est pas la même chose que de simplement désactiver toute agrégation sur la dimension temporelle. L'agrégation de Net Lost Commitment fonctionne bien dans la hiérarchie temporelle - la capture d'écran affiche les valeurs correctes pour 2009 et 2010, et si vous étendez à trimestres ou mois, vous obtenez toujours des valeurs correctes. Ce n'est que lorsque plusieurs périodes sont sélectionnées que l'agrégation échoue. Donc, ma question est de savoir comment changer la définition des engagements perdus nets de sorte qu'elle ne s'agrège pas lorsque plusieurs périodes sont sélectionnées, mais continue à s'agréger pour toutes les autres dimensions. Par exemple, est-il un moyen d'écriture dans MDX:

CREATE MEMBER CURRENTCUBE.[Measures].[Net Lost Commitments] 
AS (iif([Date Dimension].[Fiscal Year Hierarchy].**MultipleMembersSelected** 
     , null 
     , [Measures].[Acquisitions] - [Measures].[Growth in Commitments])) 

ADVthanksANCE,

Matt.

+0

Autre idée ... le MDX définissant les mesures se trouve dans le script "Calculation" du cube SSAS. Alors peut-être que plutôt que de limiter l'agrégation dans la définition de mesure elle-même, je pourrais le faire via une instruction SCOPE. Existe-t-il un moyen dans une instruction SCOPE de dire "ce bloc n'applique que lorsque le contexte est un seul membre de la [Dimension de date]"? – MattClarke

Répondre

1

Je n'ai pas bien compris la première partie de la question, désolé ... mais à la fin je pense que vous demandez comment détecter si plusieurs membres d'une dimension particulière sont utilisés dans le MDX.

Vous pouvez examiner l'un des deux axes sous forme de chaîne et l'utiliser pour former un test vrai/faux. N'oubliez pas que vous pouvez utiliser les fonctions VBA dans les implémentations Microsoft de MDX.

Je suggère InStr(1, SetToStr(StrToSet("Axis(1)")), "whatever") = 0 comme un moyen d'élaborer le premier argument de votre IIF. Cela obtient l'ensemble des membres sur l'axe numéro un, le convertit en une chaîne, et cherche à voir si une certaine chaîne est présente (elle renvoie la position de cette chaîne dans l'autre). Zéro signifie non trouvé (donc il retourne vrai). Vous devrez peut-être utiliser l'axe zéro à la place, ou peut-être vérifier les deux.

Pour voir si plusieurs membres de la même dimension étaient utilisés, la chaîne de test ci-dessus devrait être plus compliquée. Vous voulez savoir si whatever se produit une ou deux fois. Vous pourriez tester si la première occurrence de la chaîne était à la même position que la dernière occurrence (en cherchant en arrière); mais cela pourrait aussi signifier la chaîne n'a pas été trouvé du tout:

IIF(
    InStr(1, bigstring, littlestring) = InStrRev(bigstring, littlestring), 
    'used once', 
    'used twice or not at all' 
) 
+0

Merci Magnus. Je vais essayer cela pendant quelques jours et poster ce que je découvre ici. – MattClarke

+0

Ayant essayé d'implémenter cette suggestion Magnus, je ne peux pas le voir fonctionner aussi souvent que pas la dimension de date est dans une trancheuse plutôt que sur l'un ou l'autre axe. Je pourrais peut-être écrire une instruction IIF complexe qui cherchait plusieurs occurrences de "[Date Dimension]" sur Axe 0 ou Axe 1, mais je ne pense pas que le contenu de la clause "where" soit accessible de la même manière. – MattClarke

+0

Oh mon dieu. Pardon. J'étais sur le point de suggérer que vous utilisiez .currentMember dans le InStr() pour examiner le tuple en cours d'évaluation .... mais je vois ci-dessus que vous l'avez trouvé! –

2

Une suggestion d'une autre source a résolu ce pour moi. Je peux utiliser -

iif(iserror([Date Dimension].[Fiscal Year Hierarchy].CurrentMember), 
    , null 
    , [Measures].[Acquisitions] - [Measures].[Growth in Commitments])) 

CurrentMember renvoie une erreur lorsque plusieurs membres ont été sélectionnés.

1

Je suis tombé sur ce post en recherchant une solution pour mon propre problème avec des totaux généraux de mesures calculées au fil du temps lorsque des filtres sont impliqués. Je pense que vous auriez pu corriger les calculs au lieu de les supprimer en utilisant des ensembles dynamiques. This worked for me.

Questions connexes