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.

Publié dans Modélisation BI

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :