Qu'est-ce qu'une business key dans Data Vault ?

Un hub ne vaut que ce que vaut la clé sur laquelle il repose. Dans Data Vault, la clé du succès, c’est la business key.

Ce qu’est une business key

Une business key est l’identifiant que le métier utilise lui-même : le numéro de client sur un courrier, le numéro de facture qu’un client donne au téléphone, le numéro de contrat dans un e-mail. Les collaborateurs et les clients connaissent ces clés, et c’est pour cela qu’elles sont stables. Un système peut renuméroter ses lignes internes ; il peut difficilement changer un numéro imprimé sur dix mille factures.

En termes de modélisation de données classique, la business key est la clé naturelle, l’une des clés candidates de l’entité, par opposition à la clé de substitution qu’une base de données génère pour ses propres besoins. Si vous avez déjà choisi une clé primaire pour un modèle conceptuel, vous avez déjà fait ce travail.

Comment les trouver : l’astuce de la facture papier

Beaucoup de data engineers et de modélisateurs hésitent à interroger les utilisateurs métier sur les clés. La question paraît technique, et les réponses dérivent vers des noms de tables. Un exercice simple permet de l’éviter :

1. Demandez aux utilisateurs métier d’imprimer quelques documents réels : une commande, une facture, un bon de livraison.
2. Posez-leur la question : « Si un client vous appelle au sujet de ce document, que vous dira-t-il pour que vous puissiez le retrouver ? »
3. Surlignez ce qu’ils vous montrent.

Ces numéros surlignés sont vos business keys. La même feuille de papier vous montre les concepts qui les entourent (le client, la commande, le produit) et la façon dont ils sont liés les uns aux autres : c’est le point de départ du modèle.

Pourquoi Data Vault repose sur les business keys

• Intégration passive. Les business keys sont partagées entre les systèmes sources. Lorsque le CRM et l’ERP chargent tous deux le client C-10442 dans le même hub, leurs données sont reliées sans aucune logique d’intégration manuelle : ce sont la clé commune et notre automatisation qui font le travail.
• Migrations des systèmes sources. Lorsqu’un système source est remplacé, ses clés techniques changent. Ses business keys, elles, ne changent pas, si bien que l’historique d’avant et d’après la migration concorde toujours.
• Générations d’entrepôts de données. Il en va de même pour l’entrepôt lui-même. Lorsqu’une nouvelle solution d’intégration de données ou de DWH doit reprendre les données de l’ancienne, les business keys relient les deux, car elles restent stables d’une version du DWH à l’autre.

Lorsque le même numéro désigne des choses différentes dans des systèmes différents, comme la commande 1018 dans l’ERP suisse et dans l’ERP allemand, le Business Key Prefix les distingue. Lorsqu’une clé se compose de plusieurs parties, comme un code société et un numéro de client, la business key est tout simplement composite.

La difficulté

La plupart des systèmes sources stockent la business key dans l’entité qu’elle définit : le numéro de client se trouve dans la table des clients. Les relations, en revanche, utilisent des clés techniques. Une ligne de commande porte l’identifiant interne au système du client, pas son numéro de client. Comment passer de là à un modèle fondé sur les business keys, c’est le sujet du prochain article de cette série : clés techniques versus clés métier.

Ce qui change avec Datavault Builder

Dans Datavault Builder, vous définissez le concept une seule fois. Vous y rattachez ensuite chaque source en définissant les colonnes qui forment sa business key, et Datavault Builder fait tout le nécessaire pour réaliser l’intégration : le hub, la gestion des clés et le code de chargement sont générés. L’effort porte sur le dialogue avec le métier, pas sur l’écriture de la logique de chargement.