Je trouve cette méthode excellente pour permettre aux décideurs, et tous les non IT, de se voir dans l’évolution afin de permettre de cadrer et postitionner leurs besoins, attentes et objectifs. Il permet aussi aux professionnels (IT) d’avoir un plan directeur que les décideurs peuvent comprendre, une sorte de langage commun (et dieu sait si les deux ne parlent pas le même langage).

Un très bon complément d’information

PPS est fait pour être intégré à Sharepoint (WSS ou Sharepoint Portal). Mais pour des fins de tests vous pouvez utiliser la fonction « apreçu » pour jouer avec.
Liens utiles :
– Pour télécharger la version d’évaluation : http://www.microsoft.com/business/performancepoint/howtobuy/trial-software.aspx
– Pour voir les vidéos de training : http://www.microsoft.com/business/performancepoint/resources/training.aspx

Voila voila !

Un très bon départ qui pourra se poursuivre avec les tutos de DVP

Voici le lien vers les virtual labs de la suite Business Intelligence de MS : http://technet.microsoft.com/en-us/bb499788.aspx

Enjoy !

- orientées « métier » ou business (par exemple, pour une banque un compte débiteur sera agrégé avec les prêts accordés par la banque et non pas avec les autres comptes restés créditeurs, à la différence de ce qui se passe dans la comptabilité et le système de production d’origine)
- présentées selon différents axes d’analyse ou « dimensions » (par exemple : le temps, les types ou segments de clientèle, les différentes gammes de produits, les différents secteurs régionaux ou commerciaux, etc.)
- non volatiles : stables, en lecture seule, non modifiables,
- intégrées en provenance de sources hétérogènes ou d’origines diverses (y compris des fichiers externes de cotation ou de scoring)
- archivées et donc datées : avec une conservation de l’historique et de son évolution pour permettre les analyses comparatives (par exemple, d’une année sur l’autre, etc.)

Voila pour la définition, il faut retenir que dans un entrepôt on ne supprime JAMAIS les données, il est la dans un but historique, donc JAMAIS de suppression, et sauf dans des cas bien spécifiques, JAMAIS d’update des données. Le système de prod ne garde pas la trace de l’ancien prix du produit avant qu’on décide de le changer, mais les analystes ont un intérêt certain à étudier l’impact du changement de prix dans la consommation de ce produit !
Autre chose à retenir : le schéma doit être assez simple pour que des non informaticiens puissent accéder à l’entrepôt et faire de l’analyse. Souvenez vous que le but est de donner plus d’autonomie aux utilisateurs finaux. Plus de va et viens entre les départements et l’informatique pour la création d’un rapport qu’on utilisera qu’une seule fois ! Donc plus d’autonomie = permettre l’accès à la source.
En partant de ces principes, des gens intelligents ont crées un schéma de modélisation simple pour les données d’un entrepôt. Le but du jeu sera, par la suite, de transposer les données de production dans ce schéma la en gardant entre les yeux les principes précedement cités. Naquit le schéma en étoile (Star schema) !!!!
Contrairement au schéma relationnel (modèle Entité-Relation), le schéma en étoile se base sur deux concepts transversaux au relationnel : Dimension et Fait.
Le concept de Dimension désigne un axe d’analyse de l’entreprise. Plus clairement, avec quoi on va faire de l’analyse. Des exemples pourraient être des dimensions produits, fournisseurs, temps, clients, etc. La particularité de ces axes est qu’ils doivent être, le plus possibles, communs à l’entreprise, en ce sens qu’il faut faire un vrai effort de prospection pour définir des concepts communs à tous les départements (des heures de plaisir pour mettre tout le monde d’accord sur ce qu’est un « produit » dans l’entreprise). Pourquoi ? ben parce que ces axes seront utilisés pour décrire l’entreprise dans son ensemble, indépendamment des structures organisationnelles.
Deuxième spécificité : les données des dimensions doivent être unifiés. Pas question d’avoir des prix en dollars, dinars et Euros. C’est le meilleur moyen pour faire un flop.
Troisième spécificité : les données doivent avoir des méta-données claires et parlantes pour les utilisateurs. Les utilisateurs finaux doivent comprendre les noms des colonnes, évitez les DF_XPROD_GLE, y’a que vous qui comprenez ça !
Quatrième spécificité : et la plus importante !!! n’utilisez JAMAIS les clés de vos tables de prod pour identifier vos Dimensions. Je sais, je sais, on commence l’analyse, on voit que notre analyse portera sur les ventes par date, par vendeur, par client, par produit. On a donc des dimensions Date, Vendeur, Produit et Client et … on a les tables associés dans notre système de prod, pourquoi ne pas les migrer dans notre schéma en étoile …. NOOON !!!! N’oubliez pas que l’entrepôt est le garant des changements de l’entreprise, la mémoire de l’entreprise, comment garder trace des changement de prix, de titre, de code produit, de code client à travers le temps ??? La solution est d’avoir une clé primaire pour notre dimension et d’ajouter l’identifiant dans le système de production comme simple champ de notre dimension. De cette façon, si un changement se produit, on insérera un nouvel enregistrement dans notre dimension et l’historique est sauf. Je traiterais plus en détail de la gestion de l’historique dans un autre article, et si c’est un peu flou pour vous, ne vous inquiétez pas, j’ai prévu un exemple qui vous montrera la lumière
Le concept de fait maintenant, en fait c’est sur quoi va porter l’analyse (rappelez vous, dimension = avec quoi on va analyser, fait = qu’est ce qu’on va analyser). En pratique un fait est un aspect de l’entreprise : ventes, commandes, stock, réclamations, etc. Une table de fait regroupe les concepts clés de chaque aspect, pour les ventes par exemples : le chiffre d’affaire brut, net, les quantités vendues, les quantités retournées, les abimés, etc. La table de fait regroupera fidèlement ces concepts dans son contenu.
Les tables de faits obéissent au même principes que les dimensions, ajoutez y les deux spécificités suivantes :
1- Chaque ligne de la table de fait doit avoir une référence vers les tables de dimensions : on analyse le contenu de la table de faits en fonction du contenu des tables de dimensions, si on veut voir le C.A net par client, par date, chaque ligne de la table de fait doit avoir un lien avec les dimensions Produit et date. C’est pour cela qu’on appelle ce schéma « étoile », la table de fait est centrale et reliée aux dimensions, comme dans l’image suivante :

Remarquez les références vers les tables de Dimension dans la table de fait, le cas de la dimension Date est toujours un cas particulier dans le monde du B.I. Nous le traiterons une autre fois.
2- La granularité des tables de faits et des dimensions doit être la même : en effet, puisqu’il va y avoir des liens (1:N) entre les dimension et la table de fait, une ligne de la table de fait doit faire référence à une et une seule ligne de la table de dimension.

Un schéma en étoile possède, en général, une table de faits et plusieurs dimensions. Et c’est l’union de tous les modèles en étoile de l’entreprise qui forme l’entrepôt de données.

BON ! ceci étant dit, un exemple est de rigueur :
Le cas :
Une entreprise vous demande de créer de créer entrepôt de données, vous êtes en charge de la partie « ventes ». Donc conceptualiser l’étoile « ventes ».
D’interminables heures de plaisir avec les futurs clients nous ont donnés les informations suivantes :
– On veut faire l’analyse du C.A brut et net, les quantités vendues et les retours par territoire, par date (année fiscale et régulière), par produit, par client, par fournisseur et par vendeur.
– On veut pouvoir voir l’information jusqu’au niveau du jour (les ventes d’un jour donné par ex.)
– On veut pouvoir des analyses comparatives sur les années (a / a-1).
– Un produit est caractérisé par son code, titre, prix, etc.
– Un fournisseur est caractérisé par son code, nom, date de contrat, etc.
– Une facture est caractérisée par son code facture, Qte vendue, Qte livrée, code client, code produit, …
– Un client est caractérisé par sont code, nom, ….
– Un vendeur est caractérisé par son code, nom, …
L’approche :
On va faire comme dans la réalité, s’assoir avec un des utilisateurs finaux et valider tout ce qui a été dit plus haut. Pour cela, le meilleur outil que je connaisse est le tableau
Le tableau c’est en fait un tableau à deux dimensions ou l’on spécifie les faits et les dimensions avec leur granularité !!! Voici un exemple :

Désolé d’insister mais il faut faire très attention à la granularité, si notre table de faits contients des ventes par semaine, et que notre dimension temps s’arrete au jours. Le schéma est simplement faux !
Donc comme vous pouvez le voir dans le tableau, nous avons les faits dans la derniere ligne, et les dimensions avec leurs attributs dans les colonnes. Très facile à partir de cela de créer notre schéma en étoile.
Note : je vous laisse faire la tableau récapitulatif pour ce cas ou pour un cas que vous auriez déjà en main.
Après cette étape rien de plus simple pour modéliser, nous avons les attributs, ajoutons les clés spécifiques aux dimensions et faits. Ça devrait donner un schéma de ce genre :

Remarquez les trois relations entre la dimension Date et la table de faits, c’est parce que notre table de faits contient trois références de date : la date de facturation, la date de commande et la date de retour.
Bien sur, le modèle peut être amélioré. Mais le but de cet article est de montrer le schéma en étoile, nous apprendrons plus tard comment optimiser ce schéma.