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

- 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.

Vous pouvez voir que DimProduit est liée à DimCatégorie qui regroupe les catégories et les sous catégories.
Que ce soit clair ! on ne fait pas de l’entité relation ici, ce schéma n’est pas en troisième forme normale, et on ne veut pas qu’il le soit ! C’est juste une astuce pour gagner en performance et en rapidité.
Ah oui ! On appelle ce schéma « flocon » parce qu’il ressemble à un flocon quand on agrège plusieurs dimensions
Quand floconer ? :
J’ai souvent posé cette question pendant ma découverte de ce modèle. Et bien la réponse est dans la définition ! On agrège quand les performances ne sont pas au rendez vous, on floconne quand c’est plus pratique pour tout le monde (les données sont mieux structurées et présentées). Il existe une règle (officieuse, mais qui tient plus de la logique à mon sens) et qui dit qu’on commence à penser flocon quand on atteint le 1 pour 1000, c’est à dire un agrégat englobe 1000 entrées de détail (une catégorie référence 1000 produits). Non, je me suis mal exprimé, sa serait plutôt : avant le 1 pour 1000 ne pensez même pas au flocon
Mais comme je l’ai dit c’est juste une règle de bonne pratique relative à la puissance du matériel et du logiciel utilisé à l’heure ou on parle. Il se pourrait très bien que cette nécessité disparaisse dans quelque années.
Flocon dans la dimension Date :
Une utilité plus qu’évidente serait pour le cas des dimensions de date qui tienne compte des minutes et secondes dans une transaction (cas d’un opérateur téléphonique par exemple). Il est clair que si l’on veut suivre les transactions à la seconde, il faudrait une dimension de temps méchament grande ! Imaginez toutes les dates (années, mois, jour, heure, minute, seconde) sur cinq années…Ça en ferait de l’enregistrement !!! Solution : agréger les dates (année, mois, jour) dans une table et laisser (hePublier le messageure, minute, seconde) dans une table enfant. On divise par beaucoup le nombre de lignes !!!!

Donc, pour éviter tout ce chaos, avoir deux systèmes indépendants de production et d’analyse. Le système de production fera de la production, le système d’analyse fera de l’analyse et des rapports. Criant de logique (mais pourtant beaucoup refusent d’emboiter le pas), les analystes seront aux anges et les utilisateurs « généraux » du système aussi. Même les informaticiens y trouveront leurs car, nous le verrons plus loin, ils développeront plus en moins de temps.

Ceci étant dit, il faut savoir que les systèmes d’analyse actuels se basent sur un modèle de données différent des systèmes conventionnels (modèle relationnel). Les systèmes d’analyses utilisent des entrepôts de données.

Concretement, qu’est ce que c’est ? :
Et bien, c’est des tables, pas en troisième forme normale, qui contiennent les informations historisées de production, mais organisés différament. Les données sont modélisées en étoile ou en flocon.

Pourquoi pas en 3eme FN, et pourquoi pas en Entité Relation ? :
Tout simplement parcequ’une structure optimisée pour faire de l’analyse et de la création de rapports s’en fiche qu’il existe un principe d’unicité dans les données. On va créer des doublons, on va dénormaliser, on va faire en sorte que l’information soit disponible en un minimum de transactions SQL (jointures, gestion d’index, recherche, etc) pour avoir un maximum de performance. Le schéma en étoile est très bon pour cela.
Autre raison, et pas des moindres, on veut permettre aux utilisateurs finaux de jouer directement avec la source de données, l’analyste pourra explorer les données et créer le rapport qu’il veut sans participation du département informatique !!!! Et oui ! le modèle en étoile (à travers des outils spécifiques) permet de faire cela. Nous verrons ces outils dans un autre post (OLAP). Je vous laisse imaginer les possibilités.

Imaginons que j’ai fait un entrepôt avec mes données de production, et après ? :
Une fois l’entrepôt fait, le voyage commence ! Premier test : essayer de faire un cumul annel du chiffre d’affaire, par client, par territoire depuis votre source de données, ensuite depuis l’entrepôt… Oui ça prend beaucoup moins de temps !!
Pas convaincus, regardez tout ce que votre entrepôt prend en historique des prix, et autres informations non gérés dans votre système de production. Plus de possibilités d’analyse !!!
Toujours pas convaincus ! Bon, parlons OLAP. Imaginez que, depuis Excel, votre patron, ou vos analystes puissent accéder à toutes les informations de votre entrepôt et analyser des faits par dimensions avec une simplicité déconcertante et sans connaissances en informatique spécifique. La si vous n’étes pas convaincus ….

Tous ces avantages font des entrepôts de données un outils stratégique de plus en plus présent dans les enptreprises. Dans un monde ou avoir l’information, c’est être meilleur, les Data WareHouses ont plus qu’une place de choix dans les entreprises. Il est clair que l’avenir sera informationnel plus qu’opérationnel.

Voici les points qui m’ont marqué ainsi que mon appréciation personnelle :

– La communauté OSBI s’accroit de mois en mois : nous avons enfin des chiffres !!! Bon, ça reste des chiffres fournis par les compagnies elles mêmes mais bon… 80 000 déploiements des produits B.I de la compagnie Jasper Soft, 20 000 développeurs ont accédé au portail BIRT Exchange et Pentaho Corp a réussi à obtenir un financement de 12 Millions $ (signe de bonne santé financière et de confiance des investisseurs).
– Le coté personnalisation plait beaucoup dans l’OSBI. En effet, il est très séduisant d’avoir un environnement ouvert qu’on peut adapter à sa guise. Mais tout à un prix …
– Les solutions OSBI « reste intéressantes » selon les interviews de l’auteur. Les entreprises envisagent mais n’emboitent pas encore le pas. La première restriction est le faite que « Open Source ne veux pas dire gratuit ! », en ce sens ou les couts amortis par l’acquisition des logiciels sont largement grignotés par le développement, la personnalisation et le support.
– Autre « piège » mentionné par l’auteur de cet excellent article : les frais cachés de l’OSBI !!! En effet, les versions en téléchargement libres de la suite B.I de Jasper (pour ne citer que cet exemple) contient les fonctionnalités de base de reporting et d’analyse. Dès que l’on veut quelque chose de plus « enterprise », il faut mettre la main au portefeuille et se procurer la licence pro : 25 000 $ pour une année de licence et de services pour Jasper, 30 000$ pour pentaho (selon les recherches de l’auteur)… ça donne à réfléchir ! Et ça pousse surtout à BIEN évaluer les besoins de l’entreprise avant de se lancer dans une aventure Open Source.

Le fait est, surtout avec la récession économique mondiale, que l’on se tourne de plus en plus vers les solutions B.I mais on reste craintif (à tort ou à raison). Parions que l’avenir sera Open Source