don’t-do-it : La clé fonctionnelle (business key)

Complex problems have simple, easy to understand wrong answers.
Grossman’s Misquote

Pour cette année 2021, nous vous proposons une nouvelle série « don’t do it ». En fait, je souhaitais l’appeler « WTF » ou « merde happens », mais notre éditeur-en-chef en quelques expressions m’a convaincu que c’était une fausse bonne idée… Voici donc un nom plus conventionnel. Dans cette série, on évoquera les solutions que vous ne devez (presque) jamais utiliser.

Encore une fois, vous ne trouverez pas de méthodologie ultra précise ni de tests exacts, mais vous y trouverez notre avis et nos observations.

La clé fonctionnelle

La clé fonctionnelle (business key, clé métier) est une valeur qui doit uniquement identifier un objet métier (personne, société, contrat, etc).

Voici les exemples de clés utilisées :

code TVA (ou SIREN) pour les sociétés,
code SIRET pour les établissements en France,
code alphanumérique pour le contrat,
numéro + date de la facture,
code client de CRM,
nom + prénom + date de naissance (+ ville de naissance, parfois) – pour les personnes physiques,
etc.

Quelle est l’utilité des clés fonctionnelles ?

l’utilisation des clés fonctionnelles pour les entrepôts de données permet de rapprocher facilement plusieurs versions d’une même donnée et d’obtenir des dimensions communes consolidées (ex. nous avons deux enregistrements type « client-société » qui proviennent du CRM et de l’ERP qui ont le même code TVA -> nous allons dire que c’est la même société et elle sera représentée qu’une seule fois dans l’entrepôt),
l’utilisation de clés fonctionnelles dans les systèmes transactionnels permet de contrôler et d’empêcher la saisie de doublons (vous voulez créer un « nouveau » client avec un code TVA existant ? -> l’ERP vous proposera de mettre à jour la fiche correspondante).

Pourquoi l’approche est-elle si populaire ?

premièrement, c’est une situation rare quand la solution est aussi claire pour le métier et que pour l’IT,
deuxièmement, pour la vaste majorité des systèmes, la mise en place d’une clé fonctionnelle est aussi facile que l’exécution de
create unique index on...,
troisièmement, vu que les indexes dans les bases de données sont assez rapides, notre solution est aussi extrêmement performante,
quatrièmement, elle semble fonctionner – par exemple, dans ma dernière analyse de données chez un client, une clé fonctionnelle aurait pu trouver ⅘ de doublons automatiquement identifiables.

Pourquoi cela m’énerve

Sémantique

Vous rapprochez les sociétés par une clé « TVA ». Effectivement, le code TVA est unique pour chaque société et ne se change (presque) jamais… mais en réalité il faut aussi comprendre d’où provient ce code.

Possibilité 1. Vous importez automatiquement les données depuis une source « sûre » (base SIRENE). Dans ce cas, vous pouvez être assez certains que le code associé est correct et correctement attaché.
Possibilité 2. Vous saisissez les mêmes données à la main… dans ce cas, le code observé a été copié-collé, ainsi, il existe une chance (et j’ai observé cela avec mes propres yeux) que la personne peut se tromper de la case et copier le code TVA d’une autre société – et vous obtenez un « faux positif », i.e. vous rapprochez deux lignes qui en rélaité ne sont pas des doublons.
Possibilité 3. Vous avez saisi au début le nom de la société et l’adresse de son établissement et puis vous avez utilisé un service externe pour immatriculer les données (« reprendre les codes TVA »). Dans ce cas, la qualité de la clé est aussi en question – elle dépend fortement de la qualité d’immatriculation.
etc.

Conclusion : oui, la clé choisie peut être unique « en réalité », mais il faut prendre en compte comment est-elle arrivée dans vos systèmes. Le cheminement ajoute forcément du « bruit » et donc parfois des erreurs aux données. Le problème avec la clé fonctionnelle est que vous n’avez aucun moyen pour la vérifier.

Fausse protection

Souvent, les sociétés commencent par la clé fonctionnelle… et terminé ! La clé fonctionnelle une fois mise en place vous indique : « je suis là, vous n’avez plus rien à vérifier ». Et là, voici l’audit DQ qui arrive et prouve que :

Dans les prénoms il y a des fautes de frappe -> clé nom+prénom+date de naissance ne fonctionne plus pour identifier une personne.
Les codes des factures peuvent être formatés différemment.
Les contrats peuvent changer le code suite aux changements de la nomenclature.
Codes CRM… n’identifient rien du tout car dans CRM nous pouvons aussi avoir des « doublons » et même les données dans CRM peuvent avoir une sémantique différente (https://ithealth.io/difficulte-de-definir-dictionnaire-data-governance-mythique/).
Les codes TVA mal attribués génèrent des faux positifs qui sont impossibles à corriger sauf dans le SI source (qui peut être hors de portée d’une équipe DWH – en Mexique, en Chine, aux US).
etc.

Non-universalité

Nous arrivons à la conclusion que les clés fonctionnelles ne sont pas universelles – elles fonctionnent parfaitement bien pour certains cas (quand vous importez les données depuis une base de SIRENE) et sont absolument inutiles dans les autres… si vous comprenez ce point, vous êtes probablement parmi les 5% de top spécialistes de ce domaine.

La problème ici est que le nombre des cas où la clé fonctionnelle fonctionne vraiment est très limité.

Un autre problème est que l’organisation des données autour des clés fonctionnelles est très différente du cas « général » car dans ce cas général, vous devez manipuler les tables de transcodification avec les traces de source-cible pour chaque golden record. Cela ajoute au moins une table et une opération de plus.

Si tu n’es pas d’accord – critique, critiques – propose, proposes – fais, fais – sois responsable.
S. Korolev, fondateur du programme spatial soviétique

Je propose :

Rapprochement avec les modèles statistiques ou ML (https://ithealth.io/rapprochement-de-donnees/).
Stockage de golden records dans les hiérarchies, par exemple (https://ithealth.io/dimensions-master-data-problemes-et-solutions/).
Pour les SI – protection pro-active contre les doublons (https://ithealth.io/data-quality-vision-a-linverse-et-qualitysigner/).

Il y a une seule chose qui est pire qu’une clé fonctionnelle : deux clé fonctionnelles !

Finissons cet article avec un exemple…

Un organisme de formation (très important) a mis en place plusieurs règles d’unicité des clients : chaque client doit avoir un e-mail ou un téléphone portable et ces derniers doivent être uniques…

Si un membre de votre famille, votre fille par exemple, utilise votre e-mail ou votre numéro de téléphone portable pour s’inscrire à une formation – vous ne pourrez plus, personnellement, vous inscrire en futur ! C’est un cas récurrent car malheureusement cet organisme propose un service de formation aux personnes susceptible d’avoir un téléphone portable par famille (ça existe en France, oui).

Conclusion

La clé fonctionnelle est l’une des solutions de rapprochement de données… mais c’est une solution de type « quick and dirty ». Il faut être conscient que c’est très loin de l’état d’art. J’espère que vos solutions, même si elles utilisent la clé fonctionnelle, sont conçues pour pouvoir évoluer vers une approche plus avancée.

Bonne santé à vous et à vos systèmes !