> Tech > Création d’un rapport intégrant les mesures au niveau des lignes

Création d’un rapport intégrant les mesures au niveau des lignes

Tech - Par iTPro - Publié le 24 juin 2010
email

Dans la majorité des rapports Reporting Services qui utilisent Analysis Services comme source de données, la requête MDX place les mesures sur l’axe Columns et, dans le contrôle de matrice de Reporting Services, le champ Measures apparaît dans la zone de texte Data. Toutefois, les impératifs économiques et de gestion

Création d’un rapport intégrant les mesures au niveau des lignes

imposent parfois de placer les mesures sur les lignes, par exemple lorsqu’une entreprise cherche à évaluer les résultats d’une personne vis-à-vis d’un ensemble de mesures de performances.

Comme allez-vous apporter cette modification à votre rapport ? La réponse semble relativement simple : modifiez la requête afin que les mesures figurent sur l’axe Rows. Néanmoins, vous ne devez pas oublier que la valeur dans le rapport est écrite sur l’axe Columns dans l’expression MDX qui sera utilisée par Reporting Services. Ainsi, que placerez- vous sur l’axe Columns de la requête si les mesures sont transférées sur l’axe Rows ? Dans un tel cas de figure, vous placez généralement une valeur unique sur l’axe Columns. Cette valeur peut être le niveau All (tous) pour les produits, une catégorie unique (par ex., Drinks [Boissons]) ou un seul produit (par ex., Beer [Bière]).

N’importe quelle autre dimension, généralement Time, peut être utilisée sur l’axe Pages. Pour les besoins de notre exemple, créons un nouveau rapport intitulé Mesures on Rows dans Visual Studio. Pour voir les fichiers terminés de l’exemple, vous pouvez télécharger le fichier .zip dans le Club Abonnés. Nous n’utiliserons pas le New Report Wizard car il n’offre pas un contrôle suffisant pour la configuration du rapport. Nous allons prendre le cube Foodmart 2000 en tant que source de données et supposer que l’entreprise souhaite examiner les mesures Store Sales (Ventes du magasin) and Store Cost (Coûts du magasin) pour la catégorie de produits Beer and Wine (Bière et vin) par mois.

Le listing 3 présente la requête MDX qui va retourner les données nécessaires. Lorsque vous exécutez l’instruction MDX du listing 3 sous l’onglet Data, vous obtenez les données appropriées et un rapport conçu avec un contrôle de type matrice fonctionnera correctement. Malheureusement, cette requête manque cruellement de souplesse car elle s’appuie systématiquement sur la catégorie Beer and Wine. Lorsque vous cliquez sur l’onglet Layout et examinez la fenêtre Fields, vous voyez un champ intitulé Product_All_Products_Drink _Alcoholics_Beverages_Beer_and_Wine.

 Outre son manque de maniabilité, le nom du champ contient désormais la catégorie de produits spécifiée dans la requête. Vous pouvez ajouter ce champ à la zone de texte Data sur une matrice et cette approche fonctionnera, mais si l’auteur du rapport modifie la requête afin qu’elle examine une autre catégorie, le nom du champ changera en conséquence. En revanche, le rapport continuera de rechercher l’ancien nom. Par conséquent, chaque fois que vous modifiez la catégorie dans une requête, le lien du rapport est rompu.

Téléchargez gratuitement cette ressource

Endpoint Security : Etude IDC Enjeux & Perspectives

Endpoint Security : Etude IDC Enjeux & Perspectives

Quel est l'état de l'art des solutions de Endpoint Security et les perspectives associées à leur utilisation ? Comment garantir la sécurité des environnements sensibles en bloquant au plus tôt les cyber attaques sophistiquées, avant qu’elles n'impactent durablement vos environnements de travail ?

Tech - Par iTPro - Publié le 24 juin 2010