mercredi 14 décembre 2011

Gestion des Orphelins

La gestion des orphelins est une problématique récurrente de tous les projets décisionnels. On va détailler ici les 3 méthodes permettant de gérer tout ça.

Tout d'abord : qu'est-ce qu'un orphelin ? Il s'agit d'une clé dans notre table de fait qui arrive de notre système source, mais qui n'est pas référencée dans la dimension associée. Comment cela peut-il se produire ? Plusieurs hypothèses sont possibles : une erreur à la saisie lors d'une gestion par saisie manuelle d'un code, des systèmes de gestions indépendants n'ayant pas des mises à jours simultanées, ... Les causes peuvent être multiples.

Dans les exemples qui suivent on va partir d'une table de faits de ventes qui contient un code client qui n'est pas dans la dimension client (l'exemple n'est pas innocent, c'est un cas rencontré chez un client. La création de la carte client remontait dans les systèmes sources avec une latence d'une quinzaine de jours alors que la vente était bien saisie sur la carte non encore créée)

On a donc en tables sources les tables suivantes :

Une table source Client :

Code Client Nom Prénom
12 Pierre Jean
15 Dupont Jacques
25 Martin Louis


Une table source Ventes :

DateVente CodeClient CodeProduit Quantité
12/12/11 12 FR1234 2
12/12/11 12 FR3421 5
13/12/11 25 GR0987 10
15/12/11 40 RF5483 9

qui contient bien un client non référencé (ici le CodeClient 40)


1ère méthode : Le rejet


La première méthode est la plus simple : elle consiste à dire que cette ligne de ventes avec un client inconnu est une anomalie, et à rejeter de ce fait la ligne.

Attention, il faut penser à insérer la ligne rejetée dans une table de rejet pour pouvoir retenter une intégration une fois notre système source client mis à jour.

On a donc au final les 3 tables suivantes :

Une dimension Client :

IdClient CodeClient Nom Prénom
1 12 Pierre Jean
2 15 Dupont Jacques
3 25 Martin Louis


Une table de faits Ventes :

IdDate IdClient IdProduit Quantité
20111212 1 1 2
20111212 1 2 5
20111213 3 3 10


Et une table de rejet :

DateVente CodeClient CodeProduit Quantité
15/12/11 40 RF5483 9


Cette méthode est une des plus simples à mettre en place. Il faut juste penser à rejouer l'intégration des lignes de la table de rejet de manière régulière.


2ème méthode : Création d'un membre inconnu

La méthode vue précédemment a un inconvénient : à un instant t, on peut avoir au niveau global des différences de chiffres. En effet des lignes sont rejetées, ce n'est pas la meilleure manière de gérer l'intégrité des données.
La solution consiste donc à définir un client inconnu sur lequel on rattachera les lignes contenant un code client absent du système source.

On crée donc un client inconnu dans notre nouvelle table de dimension Client (souvent en id -1, ligne que l'on créera une bonne fois pour toutes au moment de la création de la table) :

IdClient CodeClient Nom Prénom
-1 N/A N/A N/A
1 12 Pierre Jean
2 15 Dupont Jacques
3 25 Martin Louis


Et au moment du chargement de notre table de faits Ventes, on met comme IdClient -1 lorsqu'on trouve un client non présent dans la table de dimension :

IdDate IdClient IdProduit Quantité
20111212 1 1 2
20111212 1 2 5
20111213 3 3 10
20111215 -1 4 9


Cette méthode est la plus répandue sur les projets décisionnels. Elle a cependant un inconvenient majeur, c'est qu'on a une perte d'information. Si le client est créé ultérieurement notre ligne sera toujours rattaché au client inconnu dans notre table de faits.

Pour cela, on peut utiliser une variation de cette deuxième méthode (méthode 2bis) qui consiste à rajouter dans notre table de faits le CodeClient afin de pouvoir mettre à jour l'IdClient une fois le client créé dans le système source.

La table de faits Ventes ressemblerait donc à :

IdDate IdClient CodeClient IdProduit Quantité
20111212 1 12 1 2
20111212 1 12 2 5
20111213 3 25 3 10
20111215 -1 40 4 9


Cela nécessite comme la première méthode le passage d'un script de mise à jour que l'on planifierait par exemple toutes les semaines ou tous les mois.
Je n'aime pas trop cette variation car elle crée dans la table de faits des données qui n'ont pas grand chose à y faire.


3ème méthode : la méthode "ultime"

La dernière méthode empêche toute perte d'informations mais peut être coûteuse en performance.
Elle consiste à scanner en amont du chargement de la table de faits les codes client non présents dans la table de dimension, et à les insérer dans la table de dimension, avec des attributs neutres qui seront mis à jour lors de l'arrivée du client dans le système source.

On obtient alors la table de dimension suivante :

IdClient CodeClient Nom Prénom
1 12 Pierre Jean
2 15 Dupont Jacques
3 25 Martin Louis
4 40 Inconnu Inconnu

Le nom inconnu et le prénom inconnu seront mis à jour lors de l'arrivée dans le système source du client ayant le CodeClient 40.

Et notre chargement de la table de faits donne la table suivante :

IdDate IdClient IdProduit Quantité
20111212 1 1 2
20111212 1 2 5
20111213 3 3 10
20111215 4 4 9


Cette méthode est la plus robuste (d'où le nom "ultime") dans le sens où vous pouvez alimenter votre table de faits sans lancer l'alimentation de votre table de dimension et ne pas perdre d'informations.


Conclusion :

Le méthode 2bis et 3 sont les plus robustes en terme de conservation de l'information. En revanche, elles n'ont d'intérêt que dans le cas où on a une chance de recevoir ultérieurement le client dans le système source. Dans les faits, ce sont la méthode 2 et dans une moindre mesure la méthode 3 qui sont les plus utilisées sur les projets.
Gardez à l'esprit que la gestion des orphelins doit se faire en fonction du souhait de votre client car il s'agit avant tout d'une problématique fonctionnelle. Ce n'est pas au développeur de décider quelle méthode implémenter, mais c'est à lui d'informer son client quand aux différentes gestions possibles.

mardi 13 décembre 2011

Un maître mot : l'Ergonomie

Pendant ma dernière année d'études, j'avais un cours d'ergonomie. Vous savez le cours dont on ne sait pas trop pourquoi il se trouve dans notre emploi du temps, et dont on ne voit l'intérêt qu'après quelques années d'expériences.
Je repensais à tout cela lors de mon retournement de veste pour repasser d'Android à iOs (quoi de mieux qu'Apple pour caractériser l'ergonomie)

Au final, je peux dire que mon choix de ma spécialité sur les technologies Microsoft dans le domaine de la BI s'est fait sur l'ergonomie des différents outils.

Comme tous les consultants en Business Intelligence, j'ai commencé par développer des packages Integration Services et lorsque j'ai mis les mains dans d'autres ETL (Datastage ou Informatica pour ne pas les citer), je n'ai eu qu'une envie : retourner sur SSIS. Je trouve son accessibilité et la clarté de son interface incomparables.
C'est à ce moment là en général qu'on a la fierté d'annoncer qu'on est développeur, mais qu'on écrit pas une ligne de code de la journée (vive le drag and drop et les interfaces graphiques).
En sortant de la présentation des nouveautés SQL Server 2012 pour SSIS, on constate l'effort particulier fait par Microsoft pour le développeur. N'est-ce pas le meilleur moyen d'attirer de nouveaux utilisateurs dans leur communauté ?

En lisant l'article de Florian Eiden sur les clés étrangères (où il me cite, il préfère que ce soit moi plutôt que lui qui sois fâché avec les DBA), je me disais également que je retrouvais ce souci d'ergonomie dans ma manière de modéliser et de développer.
Ne pas mettre de clés étrangères, c'est aussi un moyen de garder un modèle accessible et simple en ne le surchargeant pas de contraintes multiples.

Ma manière de construire des packages SSIS est aussi empreinte d'ergonomie et essayant de garder des packages le plus unitaire possible (chargement d'une table par package, un fichier de configuration commun à tous les packages, ...)

Même ma façon de construire des cubes n'échappe pas à cette problématique : je suis partisan de l'affichage exclusif des hiérarchies et du masquage de tous les attributs. Toujours vers un objectif de lisibilité accrue pour les utilisateurs.
La communication de Microsoft sur le modèle tabular d'Analysis Services 2012 est axée sur la simplicité de mise en oeuvre.

Finalement ma manière de travailler et mon choix de carrière ont été guidés par l'ergonomie de manière implicite. Il m'aura fallu 6 ans après ce cours pour m'en rendre compte.

Journées SQL Server à Paris 2011 : Compte-Rendu

Un petit retour rapide sur les journées SQL Server organisées par le GUSS qui se déroulaient les 12 & 13 Décembre à Paris : j'ai pu suivre 5 sections couvrant un spectre assez large des nouveautés SQL Server 2012.
Je vous livre un premier ressenti à chaud de ces nouveautés avant de tester tout ça plus en détail (et de commencer à les implémenter l'année prochaine chez nos clients)

Avant de commencer, je voulais féliciter le GUSS et l'ensemble des organisateurs de l'événement pour la qualité de la prestation (accueil, organisation, session, ...)


Analysis Services :

La session était présentée conjointement par Aurélien Koppel et François Jehl, et je ne peux que vous conseiller d'aller assister à leur session qui est déjà programmée aux TechDays à Paris en Février 2012.
Elle mettait en avant les différences entre mode multidimensionnel et mode tabular sous Analysis Services.
Pas de surprise sur le contenu, Microsoft met en avant la BI personnelle avec son mode tabular (et tout ce qui l'accompagne comme le DAX), sans toutefois délaisser le mode multidimensionnel pour la BI d'entreprise.
En outre le mode tabular semble bien marcher dès lors que les données sont "propres". Cela laisse à penser que le mode multidimensionnel tirera son épingle du jeu dès qu'on aura du spécifique.

La réserve qu'on pourrait poser finalement est la suivante :
La BI personnelle ne remettrait-elle pas au goût du jour les bases Access (remplacées par des classeurs PowerPivot aujourd'hui et demain) qu'on a cherché à intégrer dans un datawarehouse d'entreprise ces dernières années ?


PowerView (Ex-Crescent) :

Il s'agit d'un outil pour utilisateurs finaux (j'insiste bien dessus) qui sert à créer des rendus de données graphiques. Ça a un rendu sexy, ça semble plutôt intuitif, par contre ne serait-ce pas le remplaçant de Performance Point malgré la communication opposée de Microsoft ? (Surtout quand on sait que PPS ne profite d'aucune évolution dans cette nouvelle évolution de SQL Server)


Index ColumnStore :

On reste sur un avis mitigé : la fonctionnalité est-elle réellement finie ? Les performances de ces nouveaux index semblent intéressantes mais leur flexibilité laisse à désirer (on pense tout de suite à l'impossibilité de mettre à jour des données avec un tel index).
Fonctionnalité gadget ou véritable évolution, l'avenir nous le dira.


Integration Services :

Les nouveautés en terme de développement sont surtout d'ordre graphique et ergonomique, mais il s'agit là d'un vrai pas en avant dans ces domaines. Quand on connait les interfaces des outils concurrents, on voit que Microsoft cherche à satisfaire sa communauté de développeurs et à attirer de nouveaux utilisateurs.

La grosse avancée qui méritera d'être testée plus en profondeur est la toute nouvelle gestion au niveau déploiement et administration de l'outil (Integration Services est enfin un vrai service, gestion des packages au niveau projet, gestion des configurations au niveau projet également, disparition des fichiers dtsconfig, ...). Il est clair qu'elle nécessitera d'adopter une nouvelle méthode de travail.
Car même si l'ancienne méthode est toujours disponible (mode Legacy), il est à parier qu'elle ne le sera pas indéfiniment.


Un dernier mot pour parler de la session "Modélisation dimensionnelle" présentée par Jean-Pierre Riehl et Florian Eiden : elle ne concernait pas les outils ou les nouveautés SQL Server 2012, mais elle avait le mérite d'être à destination des consultants et des décideurs en leur rappelant les bases et les concepts de la modélisation d'un datawarehouse, sujet trop souvent sacrifié sur l'autel de la technique.