> Data > Le respect des règles avec Reporting Services

Le respect des règles avec Reporting Services

Data - Par Paul Goldy - Publié le 24 juin 2010
email

SQL Server 2005 Reporting Services effectue un travail remarquable pour les rapports chargés d’extraire des données de SQL Server 2005 Analysis Services.
Cet outil connaît son affaire pour fournir l’infrastructure nécessaire au développement de rapports, à la sélection de paramètres et au contrôle des accès aux rapports. Toutefois, Reporting Services a parfois un comportement inattendu ou non souhaité avec les données Analysis Services et vous devez faire preuve d’imagination pour contourner ce type de limitation.

Malheureusement, les solutions de contournement inventives peuvent, dans certains cas, entraîner des modifications du modèle de données ou de la sécurité. Il est préférable de circonscrire autant que possible les exigences sur la couche présentation plutôt que de modifier les modèles de données ou la sécurité simplement afin de faciliter le reporting. Le présent article aborde une situation fréquente au cours de laquelle Reporting Services n’a pas de solution intuitive pour répondre à des exigences particulières concernant un rapport. La solution en trois volets à ce problème fait appel à des fonctionnalités disponibles dans Reporting Services et Analysis Services pour se cantonner entièrement à la couche présentation des rapports.

L’exemple de projet Reporting Services, lequel s’appuie sur la base de données exemple AdventureWorks, est téléchargeable à l’adresse http:// www.itpro.fr (Club Abonnés). Le projet en question comporte deux fichiers .rdl : AW_Sample_Problem.rdl, qui affiche le rapport du problème, et AW_Sample.rdl, qui présente la solution. J’aimerais en profiter pour remercier Al Ludlow, développeur spécialiste des data warehouses chez CIBER, pour avoir aimablement créé la majeure partie de la solution.


Contenu Complémentaire :
Tout sur Reporting Services
Le groupe utilisateur de SQL Server

Le respect des règles avec Reporting Services

Pour notre exemple d’activité, nous avons pris un rapport des ventes clé dans lequel la sélection d’un membre de dimension Analysis Services dans la hiérarchie Geography constitue un paramètre de rapport. Le rapport des ventes comporte un groupe de lignes pour chaque niveau de la hiérarchie Geography. Conformément aux exigences métier, les membres dont le niveau dans la hiérarchie est supérieur (ancêtres) à celui du membre sélectionné par l’utilisateur ne doivent pas être visibles sur le rapport.

Mais Reporting Services ne comprend pas cette exigence car il ne comporte aucun mécanisme permettent de supprimer les membres de niveau supérieur au sein d’une hiérarchie. Par conséquent, notre rapport affiche des ancêtres indésirables. Par exemple, lorsqu’un utilisateur sélectionne Utah en tant que paramètre pour le rapport, ce dernier affiche le niveau Country (pays) avec Utah et ses descendants. Il en résulte une violation des exigences métier dès lors que l’ancêtre de Utah, à savoir United States, figure sur le rapport, comme le montre la figure 1. L’affichage souhaité, présenté à la figure 2, ne comporte pas les ancêtres de Utah.

Téléchargez gratuitement cette ressource

Protection des Données : 10 Best Practices

Protection des Données : 10 Best Practices

Le TOP 10 des meilleures pratiques, processus et solutions de sécurité pour mettre en œuvre une protection efficace des données et limiter au maximum les répercutions d’une violation de données.

Data - Par Paul Goldy - Publié le 24 juin 2010