Ouch, ce pavé m’a pris six mois à lire, par parties, et il a dû partager ma table de chevet avec d’autres. Dur de s’y mettre (hé, c’est la théorie de mon boulot !), mais une fois ouvert dur de le lâcher (hé, c’est ma vie ! (enfin, ce que devrait être ma vie dans un monde où on aurait le temps de faire correctement son taf [1])).

Si vous ne savez pas, et ne voulez pas savoir, ce qu’est un datawarehouse (qui dit entrepôt de données ?), vous pouvez fermer cette page et retourner sur Facebook. En gros, un système décisionnel rassemble, nettoie, coordonne, croise, indexe... dans une même base de données tous les « faits » issus de plusieurs systèmes de production opérationnels (« sources » : CRM, ERP, systèmes de production/logistique/vente/facturation/service après-vente, ou financiers/comptables/RH/marketing..., et la multiplicité des fichiers Excel qui traînent partout), afin de permettre une exploitation homogène, aisée, indépendamment des outils sources, intégrant toutes les règles métier et tous les indicateurs que l’utilisateur désire [2].

Kimball est LA référence du domaine. Franchement, ça se sent dans ce livre bourré de conseils issus de la vie réelle, issus parfois de la politique interne d’entreprise (règles majeures : se trouver un sponsor de poids capable d’imposer aux autres de bosser pour le projet datawarehouse que tout le monde attend sans vouloir lui consacrer une seconde, et qui est transverse, donc a priori l’affaire de personne ; éviter d’avoir des silos séparés par service qui seraient redondants et incohérents ; se méfier de toutes les règles non-écrites et variables d’une personne à l’autre ; chercher les économies et gains auxquels le datawarehouse a participé pour en justifier coût et maintenance).

Bref, tout sauf de la théorie déconnectée. Les performances de l’outil sont un souci constant (comment faire les jointures ?). Les conseils en planning sont de prévoir large [3], et le lecteur est prévenu qu’en soulevant le capot des bases de données source, il aura forcément des surprises [4].

Chaque étape est décrite. En vrac et en en oubliant parce que je n’ai pas envie de relire le sommaire :

  • rassemblement des spécifications (requirements), en se basant sur les process genre vente ou production, et non les services cible (surtout pas de datamarts locaux) ; spécs obtenus des gens du front qu’on cuisinera sur leur vie et attentes ; et pas en leur demandant de fournir les tableaux déjà existants à re-créer, mais quels sont leurs objectifs et « ce qui les empêche de dormir » ;
  • conception du « bus d’entreprise » : les dimensions bien documentées, harmonisées, nettoyées, « conformes » ;
  • choix des outils (longue liste de fonctionnalités dont je ne sais si un produit existe qui les a toutes [5]) ;
  • modélisation : dimensions à évolution lentes ou pas ; types de tables de fait (là ça m’a éclairci les idées) ;
  • étapes de l’ETL : notamment en discernant premier chargement et chargement par étape quotidienne par la suite quitte à dupliquer [6] ;
  • nettoyage des données : typiquement la partie sous-estimée, avec des données qu’on croyait là qui n’y sont, ou pas à la bonne granularité, pas formatées clairement ; bref un nid à surprises [7] ;
  • chargement par ETL [8] : c’est le plus technique, le plus ingrat, le moins visible ; le challenge réside dans la capacité à charger le datawarehouse dans un temps raisonnable (moins d’une nuit pour les données de la journée écoulée, le temps réel étant une option ruineuse à éviter), en intégrant tout le nettoyage, les calculs, les agrégats, etc. ;
  • restitutions, en sachant que 80% des utilisateurs seront « presse-boutons » [9] ;
  • maintenance : l’équipe ne doit pas être dissoute ou significativement réduite après la mise en production car un datawarehouse n’est jamais fini — à moins que personne ne l’utilise, car justement il doit faire naître des questions qu’on ne posait pas plus tôt [10].

Pour chaque étape, il est fourni une liste des livrables.

Dans le décisionnel, j’ai jusque là appris sur le tas en allant direct au front, en maintenant des choses écrites par d’autres, suivi les méthodes de gourous locaux, et pas manipulé de vraiment grosse volumétrie. D’autres collègues avaient d’autres techniques, et je me demandais s’il y avait la bonne méthode, deux méthodes pour deux cas différents, ou juste deux styles différents.

Exemple typique : pour les tables, clé fonctionnelle ou clé synthétique ? Pour les bases opérationnelles, y a pas à se poser de question. Pour une base décisionnelle, dénormalisée et alimentée par ETL, c’est plus discutable. Maintenant j’ai vu la lumière : si on cause de perfs on n’échappe pas aux synthétiques, mais pour de la volumétrie réduite, avec les bases de données actuelles, on peut (c’est pas Kimball qui le dit mais moi...) s’épargner cette complexité. Il est possible que la décision soit influencée par l’ETL [11], ensembliste (ODI/Sunopsis, mon préféré) ou de flux (cette m... de BODI [12], Informatica...).

Autre grand moment de modélisation : je floconne, ou je floconne pas [13] ? Kimball et son équipe sont des adversaires déclarés de la normalisation dans le datawarehouse (l’étoile, rien que l’étoile, ça allège les jointures), et plus le temps passe, plus j’évolue comme ça aussi. Après, faut voir si les grains des tables collent.

Justement, j’ai été conforté par ce que je pensais sur les grains des tables de faits : bien le fixer dès le départ est cardinal et la première chose à faire. Combien de fois me suis-je fait avoir parce que la clé primaire réelle (sous forme d’une composition de clés étrangères dans ce cas) était mal posée, ou était plus là pour le principe qu’autre chose (rassemblement de toutes les clés étrangères de la table !). Et je ne parle pas de contraintes entre faits et dimension totalement absentes. Toutes erreurs qui me coûtent cher en temps de débogage quand j’interviens au niveau de la restitution (univers et rapports Business Objects).

Bémols

  • C’est en anglais. Dans le métier on n’y coupe pas. On est loin de Shakespeare, c’est très clair et lisible, et il y a quelques touches d’humour par ci-par là.
  • Très peu d’exemples concrets (par rapport à la masse d’informations) : dans pas mal de cas, il faudra se raccrocher à sa propre expérience. Je pense à ceux qui ne sont jamais confrontés aux problèmes d’historisation et des dimensions à évolution lente de type 2 et qui ne voient pas forcément de quoi on cause. Bon, cela aurait rajouté pas mal de pages aux plus de 600 (déjà bien denses) mais tout de même.
  • La modélisation n’est qu’effleurée, c’est un bon début, mais il va falloir que je continue à creuser le sujet.
  • Quant aux comparatifs entre produits sur le marché, il n’y a même pas de tentative. C’est tout juste si le nom d’Excel est glissé furtivement dans un coin, c’est dire. Certes, le marché est pléthorique et évolue vite. J’ai ri jaune en voyant le nombre de fonctionnalités désirables que ne possède absolument pas celui sur lequel je galère la journée. et ce que je vois de la concurrence ne me pousse pas à vouloir m’y jeter, hélas [14].

Moralité

Ce livre n’est pas pour les débutants dans le décisionnel. Ceux-là auront mieux fait de digérer toute la littérature gratuite et synthétique trouvable en ligne et de se lancer dans de premiers projets d’abord.

Pour les expérimentés, lecture obligatoire.

Autres avis

Voir les avis sur Amazon.com, entre autres. Le meilleur comme le pire sont vrais.

Notes

[1] Et où Business Objects serait assez stable pour ne pas exploser tous les plannings de 50%.

[2] Plus exactement : ce que l’on a pu faire avec les données réellement disponibles en essayant de se rapprocher de ce qu’on a compris de ce qu’il a cru vouloir.

[3] Ce qui commercialement passe très mal.

[4] Mon expérience confirme.

[5] Et en tout cas pas Business Objects.

[6] J’essaierais même pas de suggérer ça à ma hiérarchie ; faire du boulot en double ça boufferait la marge. Et puis franchement, je ne joue pas avec la volumétrie d’une banque.

[7] En fait, personne ne sait vraiment ce qu’il y a dans une base de données avant d’y avoir vraiment fouillé. La première fois qu’un 30 février m’a sauté à la gorge, ça a fait tout drôle.

[8] L’utilité d’un outil ETL dédié, souvent ruineux et toujours délicat, n’est pas immédiate pour qui maîtrise bien le SQL et se dit qu’il s’agit juste de charger des tables. Moi aussi il a fallu me convaincre. Mais quand on doit jongler avec dix bases de trois types différents, un ERP, intégrer plein de fichiers Excel, XML, et suivre à la trace les impacts des modifications des différents schémas, l’outil finalement se révèle ultime. Par contre il faut bien le choisir.

[9] C‘est vrai, mais d’un autre côté pas mal d’endroits en déduisent que les outils de développement n’ont pas à quitter les mains d’informaticiens ; donc ils ne sont plus faits que pour les informaticiens ; et les power users hors de l’informatique se retrouvent fort démunis et improductifs. Et Business Objects, pourtant ciblant le créneau des utilisateurs capables de s’investir raisonnablement pour faire leurs rapports, devient si lourdingue et complexe qu’une partie doit baisser les bras, quand ce ne sont pas les professionnels eux-mêmes.

[10] Sur ce point, grosse motivation pour l’équipe de SSII qui voit le « rebond » et grosse surprise pour le client qui voit les demandes de modifications et d’améliorations affluer quand le budget est déjà épuisé. J’ai aussi vu le contraire, l’infocentre pas demandé, construit dans le vide à partir de trois données incohérentes, inutile et pas utilisé. Ou encore celui redondant avec les outils déjà en place et au point.

[11] L’ETL, on est censé le choisir en fonction du projet et de critères techniques. Arf, je ne l’ai jamais vu choisi qu’en fonction du partenariat avec l’éditeur, de la tarification, ou du fait qu’il soit gratuit.

[12] Dépare pas chez SAP, cette bouse. Peu pratiqué, mais assez pour savoir que je ne l’aime pas. Même pas fichu de connaître le Ctrl-Z...

[13] Floconner, c’est normaliser les dimensions, quand le modèle en étoile voudrait des tables de faits liées directement aux dimensions, sans aller plus loin. Plus les tables sont grosses, plus il est coûteux en jointures de floconner.

[14] À part un produit d’un éditeur qui n’est pas dans nos partenaires, donc on fait pas.