Gurvan Guyader - BI Blog

Intégration de données spatiales dans une table SQL Server

2012-01-15T22:29:00.001+01:00

Depuis la version 2008, SQL Server permet de stocker directement des données spatiales dans une table.
Une application directe est la création de rapport type carte dans reporting services.
Reporting Services permet en effet de constuire un rapport carte de 2 façons:

fichier ESRI
requête spatiale SQL Server

La première option est la plus simple. En général, depuis votre logiciel de création de carte (MapInfo par exemple), vous pouvez exporter la carte dans le format ESRI (shapefile) et essayer de l'utiliser dans SSRS.

Cependant il est préférable de l'intégrer dans SQL serveur pour centraliser vos informations spatiales dans un endroit unique. De plus le fait de les charger en base apporte beaucoup de souplesse pour la création dynamique de carte.

Le chargement dans SQL server peut se faire par un outil développé par Morten Nielsen vraiment très pratique : Shape2SQL.

Une fois les données intégrées. Il est possible de valider le résultat directement via Management Studio :

La carte ESRI ci-dessus est issue du site http://www.diva-gis.org/gdata

Datasource MySQL avec SSRS

2012-01-08T21:45:00.000+01:00

L'interopérabilité SSRS et MySQL fonctionne parfaitement via le driver ODBC fournit par Oracle. Cela est bien pratique si vous souhaitez faire du reporting avancés (pour de l'impression par exemple) sur une application fonctionnant avec une base MySQL.

Les étapes consistent à :

Télécharger le driver depuis le site d'Oracle (32 ou 64 en fonction de votre serveur SSRS)
Installer le driver sur votre serveur SSRS
Configurer le lien odbc via ODBC Datasource administrator sur le serveur SSRS
Créer le lien au niveau System et non Utilisateur pour qu'il soit vu par le service SSRS

Indiquer le nom du serveur et le le login/password pour se connecter à la base MySQL

Créer la datasource dans SSRS en mentionnant le nom du lien ODBC créé précédemment

Créer vos rapport !

N'oubliez pas d'installer le driver et de configurer le même lien ODBC sur votre machine de dev afin de pouvoir réliaser les rapports dans BIDS ou Report Builder.

Quartile Excel en MDX

2009-09-27T18:17:00.001+02:00

La fonction Excel quartile est une fonction statistique couramment utilisée en analyse des ventes pour segmenter une population en fonction d’un indicateur.

le 1er quartile sépare les 25 % inférieurs des données
le 2e quartile sépare les 50 % inférieurs des données (médiane)
le 3e quartile sépare les 75 % inférieurs des données

La fonction quartile n’est pas disponible en tant que fonction native MDX, cependant elle existe dans l’assembly ExcelMDX.

Attention, cette assembly a quelques contraintes d’utilisation :

Excel 2003 ou supérieur installé sur le serveur Analysis Services.
Droits suffisant pour le compte Analysis Services sur l’application DCOM « Application Microsoft Excel » (a minima Execution locale et Activation locale).

Une fois ces pré requis remplis à vous les joies des fonctions Excel dans vos requêtes MDX.

Ainsi pour récupérer les quartiles d’un set, quelques lignes de MDX et le tour est joué :

Member [Measures].[Indicator] as cdbl([Measures].[Internet Sales Amount])

set [Base] as
NONEMPTY([Product].[Product Categories].[Subcategory].members,[Measures].[Indicator])

Member [Measures].[Q3] as ExcelMDX!quartile(settoarray([Base],[Measures].[Indicator]),3)
Member [Measures].[Q2] as ExcelMDX!quartile(settoarray([Base],[Measures].[Indicator]),2)
Member [Measures].[Q1] as ExcelMDX!quartile(settoarray([Base],[Measures].[Indicator]),1)

select {[Measures].[Q1],[Measures].[Q2],[Measures].[Q3]} on 0 from [Adventure Works]

NB1 : la fonction VB cdbl permet de typer explicitement la mesure car certains types natifs Analysis Services ne sont pas supportés par le fonction quartile.

NB2 : La fonction quartile ne prend pas en paramètre directement un SET mais une liste d’ou l’utilisation de la fonction SetToArray.

NB3 : bien penser à exclure les valeurs nulles du SET avec la fonction Nonempty.

Enfin si besoin, un FILTER sur le SET de base permet de récupérer le détail des membres d’un quartile :

filter([Base],[Measures].[Indicator]<[Measures].[Q1])

Quoi de neuf dans les pivot tables Office 2010 ?

2009-08-04T16:58:00.000+02:00

Depuis la sortie de la CTP (Community Technical Preview) d’Office 2010 et bien que Chris Webb nous ait déjà donné un aperçu de ce à quoi il fallait s’attendre, je n’ai pu m’empêcher de regarder un peu plus en détail les nouveautés des pivot tables pour Analysis Services :). Globalement, leur comportement est très proche de celles de la version 2007 avec tout de même quelques nouveautés fort sympathiques :

La nouveauté majeure se situe au niveau du Slicer présenté initialement pendant la démonstration du projet Gemini de la BI Conference 2008. En gros Il s’agit d’un nouveau composant graphique affichant les membres d’une hiérarchie Analysis Services sous forme d’une liste de boutons :

Les slicers prennent tous leurs intérêts lorsqu’ils sont connectés à une pivot table. En effet dans ce cas ils se comportent exactement comme une hiérarchie placée dans le “Report Filter” de la pivot table. Sauf que l’avantage ici est que les membres du filtre sont directement visibles. L’analyse est donc plus claire et intuitive.

Voici une liste de points notés pendant leur utilisation :

Seul les membres d’un seul niveau d’une hiérarchie sont affichés (pas possible d’afficher tous les membres d’une hiérarchie utilisateur multi niveaux).
La multi sélection de membres est supportée.
Un slicer peut être connecté à plusieurs Pivot Tables (idéal pour la construction de Dashboard).
Si plusieurs Slicers sont liés à une même pivot table. Ces derniers deviennent interdépendants. Par exemple lorsqu’on sélectionne un membre dans le slicer des catégories de produit alors le slicer des sous catégories met en évidence seulement les membres ayant des valeurs dans le cube.
Leur design est très personnalisable (couleur, taille des boutons, nombre de colonnes, position,…).
Les slicers seront très probablement exportables dans SharePoint via les Excel Services.
Le wirteback (écriture dans les cubes) est enfin supporté nativement dans les pivot tables. Cette fonction appelée aussi “what-if Analysis” est souvent implémentée dans les applications BI de type budgétisation / planification / prévision.


bouton dans le menu	option au niveau des cellules de saisies

Un designer de Set calculé est désormais disponible. Les utilisateurs peuvent donc créer eux-mêmes des sets qu’il pourront sélectionner ensuite dans la zone “Pivot Table Field List” pour construire leurs tableaux (avec possibilité d’éditer le MDX si besoin).
Enfin, dans les menus de sélection des membres des hiérarchies, une zone de filtre interactif des membres fait son apparition :

Pour conclure, cette version 2010 des Pivot Tables nous réserve sûrement encore quelques surprises car certains items du menu étaient visibles mais non sélectionnables :(. Je pense entre autres aux “calculated field” et “calculated Item”.

Bonne CTP.

[SSAS] : Quelques précisions sur les DMV

2009-07-14T19:56:00.001+02:00

Les DMV pour “Data Management Views” permettent d’accéder facilement aux informations retournées par la méthode XMLA Discover.

Il existe plusieurs types de DMV, en voici quelques exemples :

Type	DMV
Activité et état du serveur	$system.discover_connections $system.discover_sessions $system.discover_jobs $system.discover_object_activity
Méta données du serveur	$system.dbschema_catalogs $system.dbschema_tables $system.dbschema_columns
Objets Analysis Services	$system.mdschema_cubes $system.mdschema_dimensions $system.mdschema_measuregroups $system.mdschema_measuregroup_dimensions $system.mdschema_kpis $system.mdschema_hierarchies $system.mdschema_sets
Objets Data Mining	$System.dmschema_mining_functions $System.dmschema_mining_models $System.dmschema_mining_structures $System.dmschema_mining_structure_columns

Le langage utilisé n’est pas du MDX mais du SQL très basique : SELECT (…) FROM (…) WHERE (…) avec si besoin quelques fonctions du type LIKE. Les jointures entre DMV ne sont pas supportées nativement (on peut cependant contourner cette limitation en passant par un serveur liée dans SQL Server et des OPENQUERY).

Voici une illustration de requête que l’on peut exécuter directement dans l’éditeur MDX de Management Studio :

SELECT table_schema, table_name
FROM $system.dbschema_tables
WHERE table_schema = '$system'

Ce qui nous donne ici la liste des DMV disponibles :) très pratique !

Les DMV sont supportées nativement par le moteur SSAS depuis la version 2008. En 2005 elles sont accessibles à condition d’installer la procédure stockées ASSP qui se trouve sur Codeplex.

Quelques cas d’utilisations des DMV :

Réaliser la supervision de l’activité de serveur Analysis Services (“qui est connecté ?”, “avec quelle application ?”, “depuis combien de temps ?”,…). Un projet développé par Carl Rabeler de la SQL Cat Team est d’ailleurs mis à disposition ici.
Récupérer les méta données d’un serveur SSAS pour faire de la documentation (cf. post de Vidas Matelis)
Récupérer les dates de dernier traitement des cubes et dimensions

SELECT LAST_DATA_UPDATE
FROM $SYSTEM.MDSCHEMA_CUBES
WHERE CUBE_NAME = 'Adventure Works'

Récupérer les UniqueNames des hiérarchies pour faire du MDX dynamique dans Reporting Services

SELECT [LEVEL_UNIQUE_NAME]
FROM $SYSTEM.MDSCHEMA_LEVELS
WHERE CUBE_NAME = 'Adventure Works'
AND [HIERARCHY_UNIQUE_NAME] = '[Customer].[Customer Geography]'

Récupérer les valeurs courantes des compteurs de performance sans passer par PerfMon

SELECT *
FROM SYSTEMRESTRICTSCHEMA(
$SYSTEM.DISCOVER_PERFORMANCE_COUNTERS ,
PERF_COUNTER_NAME = '\MSOLAP$SQL2008:Connection\Total Requests')

[SSRS] : Bug du Render HTML avec les Placeholders

2009-07-06T00:13:00.001+02:00

Je poste ce billet car j’ai été confronté à ce problème certes très spécifique mais pour lequel il est difficile de trouver des informations.

L’anomalie se produit avec ssrs 2008 SP0 et SP1 et est liée à la nouvelle implémentation du composant textbox supportant le “Rich Format Text”. La textbox est désormais un conteneur de placeholders (et plus précisément de textruns) avec chacun des propriétés spécifiques. Cette nouveauté est très pratique par exemple lors du développement des rapports pour concaténer du texte statique avec des paramètres dynamiques.

Etapes pour reproduire l’anomalie :

création d’une textbox dans le body d’un rapport avec un texte statique et le paramètre global “Execution” :

Ce qui nous donne le résultat suivant avec le render HTML du Report Server :

Jusque là tout va bien, maintenant nous allons modifier le format de la date en changeant la propriété “language” de la textbox (en “en-US” au lieu du langage par défaut) :

Résultat une fois déployé dans le Report Server :

Pas terrible n’est ce pas. En regardant de plus près dans le HTML on constate que la classe de style appliquée au texte statique contient un erreur de syntaxe : un guillemet est manquant dans la propriété LANG ! D’ou le problème d’affichage dans IE.

.a7{font-family:Arial;font-size:10pt;font-weight:700;font-style:normal;text-decoration:none;color:Red; LANG="en-US;}.

Remarques complémentaires :

Dans le Report Designer ou le Report Builder 2 l’anomalie n’est pas visible directement car l’outil de prévisualisation n’utilise pas tout à fait la même render extension HTML que celle du Report Server. Dans tout les cas l’anomalie est visible avec un export MHTML.

L’anomalie est seulement constatée avec la propriété “Language” appliquée sur du contenu de type texte dans une textbox contenant plusieurs placeholders et seulement pour le render HTML.

Moyens de contournement :

Dans l’exemple ci-dessus il existe des moyens de contournement pour appliquer correctement le format de la date.

En appliquant la propriété uniquement sur le placeholder du paramètre “Execution”.
Ou si le format est global au rapport, en l’appliquant directement au niveau du composant Report.

Gestion des hiérarchies SSAS dans SSRS

2009-06-14T23:37:00.001+02:00

En reprenant le billet de Robert Bruckner sur la gestion des hiérarchies parent-enfant dans SSRS, on peut facilement étendre la technique à tous les types de hiérarchies SSAS.

Voici un aperçu du rapport (téléchargeable ici) se basant sur la base d’exemple AdventureWork :

Tout d’abord définissons une requête MDX permettant d’afficher la hiérarchie utilisateur [Product Model Lines] en ligne et la mesure [Measures].[Internet Sales Amount] en colonne :

WITH

MEMBER [Measures].[UniqueName] as
axis(1).item(0).item(0).hierarchy.currentmember.uniquename

MEMBER [Measures].[ParentUniqueName] as
axis(1).item(0).item(0).hierarchy.currentmember.parent.uniquename

MEMBER [Measures].[Name] as
axis(1).item(0).item(0).hierarchy.currentmember.name

SELECT

{[Measures].[UniqueName],[Measures].[ParentUniqueName], [Measures].[Name],
[Measures].[Internet Sales Amount] } ON COLUMNS,
{ ([Product].[Product Model Lines].ALLMEMBERS ) } ON ROWS

FROM [Adventure Works]

Les points importants à noter sont :

La récupération de tous les membres de la hiérarchie en ligne [Product].[Product Model Lines].ALLMEMBERS
La création de membres calculés afin de récupérer dans des champs du dataset :

le uniquemename du membre courant se trouvant en ligne
le name du membre courant se trouvant en ligne
le uniquename du parent du membre courant se trouvant en ligne

Petite subtilité au niveau de la définition des membres calculés, des fonctions MDX permettent de récupérer de manière dynamique le hiérarchie en ligne :

axis(1).item(0).item(0).hierarchy=[Product].[Product Model Lines]

Ainsi si l’on souhaite réaliser un autre rapport avec une hiérarchie différente, il n’y pas besoin de modifier les membres calculés.

Ensuite, définissons les propriétés du groupe dans un tablix de type table pour créer notre rapport de DrillDown. Pour cela, créons un groupe en ligne avec les propriétés suivantes :

group on : =Fields!UniqueName.Value
Recursive Parent : =Fields!ParentUniqueName.Value
Toggle item : utiliser la cellule contenant le libellé
Hidden : =iif(level()=0,false,true) afin de n’afficher au départ que les membres du niveau 0.

Enfin, il ne reste plus qu’a mettre de la mise en forme en fonction du niveau, par exemple :

Backgroundcolor :=Choose(level() + 1,"#c3d9ff","GainsBoro")
Padding Left : =20 * Level() & "pt"

Et notre magnifique rapport est fini !

NB : gros avantage avec ce design de rapport, c’est que les agrégations sont issues directement du cube. Pas besoin de fonction d’agrégations au niveau SSRS.

Bon Report !

Drillthrough SSAS dans SSRS

2009-05-31T21:49:00.001+02:00

Reporting Services n’est pas compatible avec les actions SSAS de DRILLTHROUGH définis au niveau d’un cube. Il est cependant possible de reproduire en partie cette fonctionnalité dans un rapport via les actions SSRS de type “Go to report”.

Voici un tutorial basique permettant de l’illustrer :

Première étape : création du rapport de détail

Tout d’abord, pour effectuer une requête de type DRILLTHROUGH avec SSRS, il faut utiliser le provider OLEDB for AS (le provider MS Analysis Services ne supporte pas ce type d’instruction).

Update : Comme le souligne François dans son article, il existe une astuce pour effectuer des requêtes de drillthrough avec le provider MS AS en passant en mode DMX dans le query designer.

Création de la source de données :

Création d’un rapport tabulaire avec l’instruction de DRILLTHROUGH; par exemple, un rapport affichant la liste des commandes Internet.

Drillthrough maxrows 200
select [Measures].[Internet Sales Amount] on 0
from [Adventure Works]

Aperçu du rapport :

Seconde étape : création du rapport d’analyse

Le rapport permet ici d’analyser les ventes Internet des produits par sous-catégories.

Requête MDX utilisée :

With member [Measures].SubCatUniqueName as [Product].[Product Categories].currentmember.uniquename
SELECT
{[Measures].[Internet Gross Profit Margin], [Measures].[Internet Order Count],
[Measures].[Internet Sales Amount],[Measures].SubCatUniqueName } ON COLUMNS,
{([Product].[Product Categories].[Subcategory].ALLMEMBERS ) }
ON ROWS FROM [Adventure Works]

Un membre calculé est ajouté dans le but de récupérer dans un champ du dataset le UniqueName des membres de la hiérarchie [Product Categories]. Ce champ sera utilisé ultérieurement pour transmettre la sous-catégorie sélectionnée au rapport de détail.

Exemple de rapport d’analyse construit à partir du dataset résultant :

Troisième étape : création du lien entre les 2 rapports

L’objectif est d’obtenir à partir du rapport d’analyse des ventes le détail des commandes en cliquant sur une cellule.

Il faut donc ajouter un paramètre “Sous catégorie” au niveau du rapport de détail. Ce dernier permettra de stocker le UniqueName de la sous-catégorie sélectionnée dans le rapport d’analyse.

Création du paramètre SubCategorie :

Ensuite ce paramètre est ajouté dans la requête de DRILLTRHOUGH en clause WHERE afin de filtrer sur la sous-catégorie sélectionnée. Le problème est que le provider OLEDB for AS ne supporte pas les paramètres. Il faut donc évaluer la requête en tant que chaine de caractères.

Remplacement de la requête de l’étape 1 par l’expression suivante au niveau de la Query du dataset :

="Drillthrough maxrows 200
select [Measures].[Internet Sales Amount] on 0
from [Adventure Works]
where " + parameters!SubCategorie.value + " "

Enfin il reste à définir l’action SSRS de type “Go to report” dans le rapport d’analyse au niveau de la cellule contenant le libellé des sous-catégories :

Il suffit alors de sélectionner le rapport de détail et d’effectuer le mapping paramètre [@Subcategorie] avec le valeur courante du champ [SubCatUniqueName] du rapport d’analyse.

Modification du design des cellules afin de mettre en évidence le lien. Et voici le résultat :

Si besoin les sources de l’exemple sont téléchargeables ici.

Dynamic Set vs Static Set

2009-05-24T23:01:00.001+02:00

Analysis Services dans sa version 2008 introduit la notion de set dynamic et static.

Le static set correspond au set classique des versions antérieures d’analysis services, c’est à dire que le set est évalué une seule fois en dehors du contexte de la requête MDX dans laquelle il est utilisée.

Le dynamic set fait partie des nouveautés apportées à Analysis Services 2008. Il est évalué dans le contexte de la requête. Le set est donc exécuté à chaque fois que l’on fait appel à lui dans une requête.

La syntaxe pour écrire un set est la suivante :

CREATE [SESSION] [ STATIC | DYNAMIC ] [HIDDEN] SET
CURRENTCUBE | Cube_Name .Set_Name AS
'Set_Expression' [,Property_Name = Property_Value, ...n]

Prenons un exemple, soit les requêtes suivantes exécutées dans Management Studio :

/*création du set static*/
create session static set [Adventure Works].[Top 5 Resellers Static] as
topcount([Reseller].[Reseller].[Reseller].members,5,[Measures].[Reseller Sales Amount])
GO
/*création du set dynamic*/
create session DYNAMIC set [Adventure Works].[Top 5 Resellers Dynamic] as
topcount([Reseller].[Reseller].[Reseller].members,5,[Measures].[Reseller Sales Amount])
GO
/* requête sans set*/
SELECT
[Measures].[Reseller Sales Amount] ON COLUMNS,
topcount([Reseller].[Reseller].[Reseller].members,5,[Measures].[Reseller Sales Amount]) ON ROWS
FROM [Adventure Works]
WHERE [Date].[Calendar].[Calendar Year].&[2002]
GO
/* requête avec set static*/
SELECT
[Measures].[Reseller Sales Amount] ON COLUMNS,
[Top 5 Resellers Static] ON ROWS
FROM [Adventure Works]
WHERE [Date].[Calendar].[Calendar Year].&[2002]
GO
/* requête avec set dynamic*/
SELECT
[Measures].[Reseller Sales Amount] ON COLUMNS,
[Top 5 Resellers Dynamic] ON ROWS
FROM [Adventure Works]
WHERE [Date].[Calendar].[Calendar Year].&[2002]

La requête 1 n’utilise aucun set. Il s’agit du résultat souhaité affichant le top 5 des revendeurs en 2002.

Résultat requête 1 :

La requête 2 utilise le static set. On constate que le résultat n’est pas le top 5 des revendeurs pour l’année 2002 mais le top 5 toutes années confondues. La raison est que le set a été évalué dans le contexte général du cube sans prendre en compte la clause WHERE.

Résultat requête 2 :

Le requête 3 renvoie le même résultat que la requête 1. La clause WHERE a bien été prise en compte lors de l’évaluation du top 5.

Résultat requête 3 :

En conclusion, on constate que Microsoft a su améliorer les fonctionnalités des sets en les rendant interactifs par rapport au contexte d’exécution. Cependant il faut être vigilant quant à leur utilisation car ils peuvent empêcher les optimisations des plans d’exécutions tel que le block computation par exemple.

Pour aller plus loin vous pouvez vous rendre sur le blog de Mosha où ce dernier explique en détail la différence entre les 2 types de set :

http://sqlblog.com/blogs/mosha/archive/2007/08/25/mdx-in-katmai-dynamic-named-sets.aspx

Chris Webb a écrit également un article intéressant sur une des limitations du set dynamic. Entre autre sur le fait que ce dernier ne puisse pas être évalué plusieurs fois au sein d’une même requête :

http://cwebbbi.spaces.live.com/Blog/cns!7B84B0F2C239489A!1555.entry

“Kilimandjaro” devient SQL Server 2008 R2

2009-05-15T15:08:00.001+02:00

Lors de la conférence Teched qui s’est déroulée du 11 au 15 Mai 2009 à Los Angeles, Microsoft a annoncé de manière officielle la sortie d’une version “Release 2” pour SQL Server 2008.

Ce produit appelé auparavant SQL Server “Kilimandjaro” comprend un ensemble d’améliorations pour SQL Server 2008 focalisées essentiellement sur la partie décisionnelle. Voici un résumé des principales nouveautés :

L’analyse à la demande (codename “Gemini”) :

“Gemini” est le nom de code d’un add-in pour Excel destiné aux utilisateurs finaux et permettant de traiter de manière performante des volumes importants de données (jusqu’à plusieurs dizaines de millions d’enregistrements) directement sur un poste client sans utiliser un serveur Analysis Services.

Techniquement parlant, l’add-in inclut une version cliente d’Analysis Services qui traite les données directement en mémoire. On parle de D-OLAP pour Desktop Online Analytical Processus.

Une version améliorée des tableaux croisés dynamiques est également prévue avec la possibilités de publier le résultat directement dans un portail SharePoint via les Excel Services. Le plus intéressant étant que le tableau publié continuera de se mettre à jour en fonction de la planification de chargement des données définie par l’utilisateur.

Enfin, il est prévu de mettre à disposition un tableau de bord SharePoint pour la supervision des serveurs Analysis Services.

Le Reporting à la demande :

Les composants graphiques Dundas de SQL Server 2008 vont être complétés par les cartes géographiques.

Un aspect collaboratif va être introduit avec l’ajout d’une librairie de composants partagés. Cette nouvelle fonctionnalité issue du rachat de 90Degree permettra aux utilisateurs de partager entre eux des parties de rapports (par exemple une entêtes de pages, un tableau d’analyse avec son formatage,…).

La gestion de la qualité des données (codename “Bulldog”) :

Suite à l’acquisition des sociétés Stratature et Zoomix, Microsoft à développé un nouvel outil de gestion de qualité des données nommé Master Data Services (MDS).

La gestion des entrepôts de données (codename “Madison”) :

Cet outil provenant du rachat de Datallegro permet de gérer des architectures complexes d’entrepôts de données. A titre d’exemple la gestion de bases de données allant jusqu’au PetaBytes (1000⁵) de données sera supportée.

lien officiel de SQL Server 2008 R2 :

http://www.microsoft.com/sqlserver/2008/en/us/R2.aspx

La première CTP est annoncée pour cet été et la version finale pour le premier semestre 2010.

Où sont stockées les permissions des Rôles de sécurité ?

2009-04-12T11:29:00.001+02:00

Voici un point qui m’a surpris lors de la mise à jour d’un cube dans une base Analysis Services de production à l’aide d’un script ASSL généré depuis un environnement de développement :

Les permissions des rôles ne sont pas définies dans le rôle en tant que tel mais directement dans les objets de la base OLAP i.e. dimensions et cubes.

Par exemple en créant une commande ALTER sur un cube pour lequel un rôle de sécurité est défini en Read, on constate que le script contient une section cubePermission incluant les paramètres de définition du rôles sur le cube.

<CubePermissions>
<CubePermission>
<ID>CubePermission</ID>
<Name>CubePermission</Name>
<RoleID>Role</RoleID>
<Read>Allowed</Read>
<ReadSourceData>None</ReadSourceData>
</CubePermission>
</CubePermissions>

De plus en générant un script CREATE d’un rôle, on constate que ce dernier contient seulement un ID, un Name et la liste des comptes/groupes Windows associés.

<Create (…)>
<ParentObject>
<DatabaseID>Adv Wks DW</DatabaseID>
</ParentObject>
<ObjectDefinition>
<Role (…)>
<ID>Role</ID>
<Name>Reader</Name>
<Members>
<Member>
<Name>Everyone</Name>
<Sid>S-1-1-0</Sid>
</Member>
</Members>
</Role>
</ObjectDefinition>
</Create>

Conclusion, dans le cas de mise à jour de base via des commandes ALTER il est donc important de répliquer à l’identique les rôles de production sur les environnements de développements.

Agrégats Analysis Services et Reporting Services

2009-04-05T19:52:00.001+02:00

Avec le provider MS Analysis Services fourni depuis la version 2005 de Reporting Services, par défaut seules les données au niveau des feuilles des hiérarchies sont récupérées lors de la construction de datasets en mode design. Si des groupes sont définis au niveau d’une data region alors les agrégats sont recalculés au sein du rapport par Reporting Services.

Dans le cas d’agrégations simples (de type SUM ou COUNT) les résultats obtenus sont conformes aux valeurs du cube bien que en terme de performance il soit sûrement plus efficace d’agréger au niveau OLAP qu’au niveau Reporting Services. Par contre si la base OLAP comporte des fonctions d’agrégations semi-additives telles que LASTNONEMPTY ou FIRSTCHILD dans ce cas il est nécessaire de récupérer les agrégats natifs de la base OLAP.

Pour cela une fonctionnalité est prévue au niveau Reporting Services : il s’agit de la fonction d’agrégation AGGREGATE. Cette dernière permet de récupérer les agrégats directement depuis la base OLAP sans les recalculer au niveau du rapport.

Voici un exemple sur la base OLAP AdventureWorks2008 :

La fonction AGGREGATE est définie au niveau des groupes du tablix :

Voici la requête MDX générée par le designer :

SELECT
NON EMPTY
{
[Measures].[Internet Sales Amount]
,[Measures].[Internet Average Sales Amount]
} ON COLUMNS
,NON EMPTY
{
[Product].[Product Categories].[Category].ALLMEMBERS
,[Product].[Product Categories].[Subcategory].ALLMEMBERS
,[Product].[Product Categories].[Product].ALLMEMBERS
}
ON ROWS
FROM [Adventure Works]

Ce qui nous donne le résultat suivant :

Nous sommes bien conformes aux résultats réels des agrégats du cube.

NB : en retournant en mode design du dataset, on remarque des valeurs nulles lors de l’exécution de la requête : il s’agit en fait des lignes complémentaires comportant les valeurs des agrégats. Ces dernières peuvent être masquées via l’option “show Aggregations” de la barre d’outils.