Cet article fait partie d’une série présentant en détail les principes du DataOps Manifesto et leur application à Power BI. Pour une introduction aux principes DataOps, je vous invite à commencer par cette présentation.

Principe #1 : satisfaire votre client de façon continue.

Le terme clef ici n’est pas « satisfaire » mais bien « de façon continue« . Après tout, nous savons tous comment satisfaire notre client : nous plier à ses exigences, bâtir rapidement (et pour un moindre coût de développement si possible !) un rapport contenant l’intégralité des données que le client est susceptible d’utiliser pour ses analyses. D’utiliser ou … de ne pas utiliser. Dans le doute, on charge tout dans le modèle sémantique, transformant le modèle en un immense datamart quitte à conserver le contenu complet des tables d’origine.

C’est bien joli tout ça mais, que va-t-il arriver lorsque notre client (certes satisfait lors de la première livraison) nous demandera d’ajouter de nouvelles données au modèle ? Etes vous sûr que vos mesures DAX tiendront le choc et continuerons à donner un résultat satisfaisant même si la granularité évolue (c’est-à-dire le niveau de détail de votre table de faits) ?

Vous l’avez sans doute compris, le seul moyen de satisfaire votre client de façon continue sur toute la durée du projet (et après, car il y a toujours un après) est de soigner son modèle initial.

Cela nécessite de porter une attention particulière aux principes fondamentaux d’un bon modèle sémantique :

• des tables de dimensions bien pensées (le modèle n’est pas une base de données opérationnelle)
• des tables de faits dont la granularité est définie en amont (si vous n’êtes pas capable de comprendre quelle est la granularité de chaque table en vous replongeant dans votre modèle des mois après sa mise en production, c’est qu’il y a un problème)
• des relations « propres » entre les tables (pas de relation 1-1, ça ne sert à rien ; pas de relation N-N, c’est trop dangereux ; un nombre limité de relations 1-N à double sens). Je reviendrai sur ce sujet dans un prochain article.
• des noms de tables et colonnes clairs pour les utilisateurs métiers (pas de noms techniques, d’acronymes, noms abrégés, de noms en majuscule et autres « tirets du bas »)

Cela parait naturel et basique, mais si dès le départ ses règles ne sont pas respectées, votre modèle fonctionnera et satisfera le client … au début. Mais il vaut mieux passer quelques jours sur votre modèle initial, quitte à faire patienter le client, plutôt que de délivrer rapidement le premier modèle et de devoir passer des jours entiers sur les modèles suivants car votre point de départ n’a pas été pensé pour être évolutif.

Règle d’or #1 : passer dès le début le temps nécessaire pour bâtir un modèle sémantique évolutif.