J’ai honte, honte de vous avoir abandonné comme ça…
Mais j’ai une bonne raison! Je bosse sur une présentation sur le décisionnel Agile. Si ça vous intéresse, n’hésitez pas à vous inscrire!
Dès que c’est derrière moi je reprendrai le rythme hebdomadaire! Promis 🙂
Lors d’un des derniers projets auquel j’ai participé, nous avons eu à mettre en place une sécurité à la ligne. Rien d’extraordinaire en soi, mais c’est un bon cas d’étude pour comprendre comment fonctionne la sécurité entre les différentes briques de l’environnement SQL Server.
J’ai essayé de schématiser ça en 3 dessins Visio que je laisse en téléchargement par ici (C’est la première fois que j’utilise Google Document comme ça, mailez moi si ça ne marche pas).
Pour faire court :
Pour implémenter une sécurité à la donnée, on ne peut pas donner des droits DataReader/DataWriter aux utilisateurs sur la base. En effet la granularité minimale de la sécurité sur SQL Server c’est la table, ni la ligne ni la colonne.
Il va donc falloir utiliser des procédures stockées (droits GRANT EXECUTE) et joindre les résultats sur la table qui stocke les couples Utilisateur / Périmètre.
Pour le cube, il va falloir définir un rôle qui utilise cette même table.
Le point important dans tout ça, c’est que si votre configuration n’est pas mono-serveur, c’est-à-dire si votre service SSRS n’est pas installé sur le serveur qui héberge la base et/ou le cube, il va falloir mettre en place la délégation d’autorité en utilisant Kerberos. C’est en effet la seule manière de faire propager le UserId depuis le SSRS frontal jusqu’aux cubes et aux procédures stockées. Dans le cas contraire, ce sera le compte de service de SSRS qui se propagera jusqu’aux données.
On peut contourner ce pré-requis si on n’utilise pas de cube dans la solution. Pour ce faire, il suffit de transmettre la constante User !UserId de SSRS en paramètre à la procédure stockée appelée. Ce n’est pas la best practice, mais ça marche. Cette manipulation n’est pas possible pour SSAS puisque la gestion des droits est transparente dans le cube.
Voici le premier schéma, il présente une vue d’ensemble de la configuration:
Concernant la sécurité fonctionnelle, la sécurité à la ligne, on peut utiliser un jeu de tables comme cela pour l’implémenter:
Et enfin, pour utiliser tout ça, il faut employer les scripts suivants:
Rappel : si vous voulez le VSD de ces schémas, il suffit de remonter en haut de l’article.
Ne disposant pas de la science infuse, j’apprécierai sincèrement les éventuelles corrections / améliorations que vous auriez à proposer 🙂
Histoire de quand même mériter la mention de « Business Intelligence » dans le nom de ce blog, je vous livre ce lien vers un article de Marco Russo. Ce sont les sources de son livre sur PowerPivot, ça peut être super pratique pour débuter sur cette techno (avec ou sans le livre).
J’en profite pour vous dire que si ça vous concerne, ça bouge du côté de la faille ASP.NET découverte la semaine dernière.
La base de cet article est un pavé écrit par Venkatesh Rao de Ribbonfarm: celui-ci.
Pour moi c’est à lire absolument, et d’autant plus si vous êtes dans un de ces deux cas:
Qu’est ce que j’appelle un architecte des étoiles? C’est un architecte perdu pour la cause dans son délire mégalo-maniaque de modéliser le monde entier dans son application.
Les symptômes?
Ce qui nous ramène à l’article de Ribbonfarm, qui vient nous expliquer comment naissent ces délires étoilés:
Toutes ces étapes sont naturelles, humaines, il ne sert à rien de vouloir les éviter absolument.
Ce qui est important, c’est que lorsque ça commence à faire mal (étape 3, étape 6), on arrive à mettre son amour propre de côté et repartir de 0. A force d’itération la connaissance et la compréhension vont s’améliorer, un modèle correct finira donc bien par émerger tôt ou tard. Bien évidemment, une itération prenant du temps, il faut donc mieux itérer sur des maquettes, voir des prototypes, pendant une grosse phase de conception, plutôt qu’itérer sur des cycles de développements complets à 200 jours-hommes pièce…
Vous pouvez maintenant vous demander qu’est ce qui différencie l’architecte étoilé de ses pairs, si la nature humaine force tout le monde à suivre le même chemin de croix? C’est son manque définitif de remise en question lorsque tout s’écroule qui l’identifie clairement: son modèle était parfait, ce n’est quand même pas de sa faute si les développeurs étaient si bêtes!
Vu chez Flowing Data, ce slide issu d’une présentation de Tableau Software:
Le slide est commenté par son auteur ici, je trouve sa réflexion extrêmement pertinente. La citation « big software, little analysis » pour décrire le datawarehousing est tellement vraie!
L’idée présentée dans ce slide est très bien résumée par cette phrase de Nathan Yau : « You have to get over the wall to really get something out of your data. Otherwise, you’re just a drone doing a computer’s work when it should be the other way around » (« Tu dois aller à droite du mur si tu veux tirer quelque chose de tes données. Sinon tu n’es qu’un drone qui fait le boulot d’un ordinateur alors que cela devrait être l’inverse.« )
Le message nous est en partie adressé, à nous les consultants qui fabriquons les applications décisionnelles, bien à l’abri à gauche du mur:
En terme d’outils, à gauche du mur on retrouve SQL Server, SSIS et SSRS. Pour moi la brique qui fait le pont entre les deux mondes c’est SSAS. De l’autre côté, on a Excel (tableaux croisés dynamiques ou avec les fonctions cube), maintenant PowerPivot (gratuit sur Excel 2010) et les modules de données de SharePoint (ex PPS Monitoring). Cela plus tous les outils de l’écosystème Microsoft (Tableau pour l’analyse, Clarity Systems pour le BPM,…), ça ne fait pas de nous les plus mal équipés pour traiter le problème!
Alors va falloir s’y mettre! 🙂
Ps: J’ai testé Tableau, enfin leur soft, et je l’ai trouvé vraiment sexy. Par contre je ne l’ai encore jamais déployé ni vu déployé. A venir peut être!
Ps: Je cite Clarity ici parce que j’ai eu droit à une démo de leur produit, et leur module de saisie (objectifs, budgets…) est juste bluffant.
Le Junkie en question c’est Jamie Thomson, le célébre SSIS Junkie.
Dernièrement il a écrit 3 articles qui ont retenu mon attention:
Pour ceux qui ne suivent pas directement Jamie, je pense linker régulièrement ses bons articles par ici. A suivre donc!
La BI ça vous gagne! 