Construire le modèle logique

🌐 Aussi en 28 langues

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Deutsch (Schweiz)

Image générée par IA

Traduit par IA. Pas encore relu par la communauté. Lire en anglais

Module 3 sur 6 du chapitre Modéliser les données pour leur sens, chapitre 2 du cours Data Architect. Chaque module se suffit à lui-même. Précédent : Dessiner les relations · Suivant : Mettre les données à leur place

La question à laquelle répond ce module : comment transformer un modèle conceptuel en modèle de données logique ?

Le modèle conceptuel nous a dit ce qui existe chez Steve Trucking et comment c’est lié : les partenaires distributeurs et leurs centres de distribution, les manifestes et les livraisons, les destinataires, les tournées et les arrêts, les équipes, les camions et les affectations d’équipe. C’est assez pour une conversation très productive avec le métier. Mais il me faut tôt ou tard plus de détails. Que devons-nous savoir sur une livraison ? Qu’est-ce qui distingue un centre de distribution d’un autre ? Comment identifions-nous un destinataire ? Qu’est-ce qui appartient à une affectation d’équipe plutôt qu’à l’équipe ou au camion ? Ces questions nous font passer d’un modèle conceptuel à un modèle de données logique, et nous ne construisons toujours pas Salesforce.

Assis, pas bouger, modèle

D’abord, retour aux chiens. Nous avons les boîtes et les traits. Maintenant, deux nouvelles questions : que savons-nous de chaque chose, et comment distinguer l’une de l’autre ?

Qu’est-ce qui la décrit ? Un chien a un nom et une date de naissance. Un propriétaire a un nom, un numéro de téléphone et une adresse. Un tour a un nom et une difficulté. Chaque fait va sur la boîte qu’il décrit.

Puis la jonction. Le niveau de Bella sur « Assis », et la date à laquelle elle l’a appris : est-ce que cela décrit Bella ? Pas tout à fait ; elle est meilleure sur certains tours que sur d’autres. Est-ce que cela décrit « Assis » ? Non ; chaque chien fait « Assis » différemment. Cela décrit Bella et « Assis » ensemble, donc cela a sa place sur le Tour du chien : le niveau de maîtrise et la date d’apprentissage. C’est pour cela que la jonction existe : certains faits n’appartiennent qu’à la paire.

Quel chien est lequel ? Essayez d’abord le nom. Il y a beaucoup de chiens qui s’appellent Max, donc le nom n’est pas unique. Le numéro de téléphone du propriétaire ? Marcus a deux chiens sur le même téléphone, les gens changent de numéro, et ce sont les données personnelles de quelqu’un, qui seraient copiées dans chaque système qui pointe un jour vers un chien. Le numéro de puce électronique a l’air mieux : il est unique, et il ne change pas. Mais un chiot qui vient d’arriver n’est peut-être pas encore pucé, et une clé ne peut pas être vide. Donc la puce reste, comme quelque chose sous lequel le chien est aussi connu, et le chien reçoit son propre ID du chien : un numéro qui fait un seul travail ennuyeux, distinguer un chien d’un autre.

Click to enlarge

Ce sont les mêmes questions que nous allons maintenant poser à Steve Trucking, et les raisons pour lesquelles le nom, le téléphone et la puce ne suffisent pas deviennent une règle que je tiens depuis des années.

Le conceptuel me dit ce qui existe ; le logique me dit ce que cela signifie en tant que données

Prenez le camion. Que dois-je savoir sur un camion ? Peut-être son numéro de parc, son numéro d’identification (VIN), sa marque, son modèle, son année, sa plaque d’immatriculation, son kilométrage actuel et son statut. Ce sont des attributs du camion.

Prenez maintenant la livraison. Peut-être le numéro de commande du partenaire distributeur, la date de livraison, le créneau promis, l’heure d’arrivée réelle, le statut, et si elle comprend une installation ou un enlèvement. Encore des attributs.

Le modèle conceptuel nous a dit que la livraison existe. Le modèle logique commence à nous dire ce qu’une livraison signifie en tant que données. Une boîte simple comme Camion ou Livraison peut représenter tout un ensemble de champs.

Click to enlarge

Malgré tout, dans la plupart de nos schémas, les boîtes restent simples, pour trois raisons. Le nombre de champs augmente. Les champs deviennent vite obsolètes. Et chaque champ a des détails difficiles à montrer dans un modèle d’objets : son nom d’API, son étiquette, son type de données et sa longueur. Ces détails seront bien sûr consignés, mais pas dans le premier modèle de données. Quand montrer quelques champs clés aide vraiment à raconter l’histoire, je dessine un modèle de données détaillé : une tranche ciblée, avec seulement les champs qui comptent pour le propos.

Les attributs doivent décrire l’entité

Voici une question simple que j’utilise quand je regarde un attribut : qu’est-ce que cela décrit ? La marque du camion décrit clairement le camion. Mais qu’en est-il du nom des membres de l’équipe sur une livraison ? Décrivent-ils la livraison ? Ou décrivent-ils une équipe, qui avait une affectation, qui couvrait la tournée, qui comprenait cet arrêt ?

C’est là qu’un modèle de données commence à révéler des choses qui paraissent parfaitement raisonnables à l’écran. Un coordinateur dit : « Je veux voir le nom de l’équipe sur la livraison. » C’est une exigence d’expérience utilisateur valable. Ce n’est pas forcément une exigence de stocker le nom de l’équipe sur la livraison. Ce sont deux choses différentes, et nous y reviendrons avec la normalisation. Pour l’instant, prenez l’habitude de demander quelle chose ce fait décrit réellement. Cette question vous évitera bien des problèmes.

Ensuite, il faut parler des identifiants uniques

Les attributs décrivent les choses. Mais il y a un autre problème à résoudre : comment savoir quelle chose est laquelle ?

Deux destinataires s’appellent John Smith. Est-ce la même personne ? Peut-être, peut-être pas. Un nom ne suffit pas. Une adresse ? Les gens déménagent. Les numéros de téléphone changent. Les adresses courriel changent. Même le nom d’un partenaire distributeur peut changer.

Cela nous amène aux clés : ce qui nous permet d’identifier de façon unique quelque chose dans notre modèle. C’est un domaine sur lequel je me suis forgé une opinion assez tranchée au fil des ans. Pour un identifiant, je veux quatre choses :

Unique. Immuable. Sans signification. Jamais une donnée personnelle.

Unique. Un identifiant doit identifier exactement une chose. Si deux livraisons peuvent avoir la même valeur, ce n’est pas un identifiant de livraison fiable. Les noms ne sont généralement pas uniques, les adresses pas forcément, et les numéros de téléphone sont partagés. Même des valeurs qui paraissent uniques aujourd’hui peuvent ne plus l’être une fois qu’on a assez de données. Alors demandez : deux de ces choses peuvent-elles jamais avoir la même valeur ? Si la réponse est oui, soyez très prudent avant de l’utiliser comme ID unique de l’enregistrement.

Immuable. Celle-ci est souvent oubliée. Si nous identifions un partenaire distributeur par son nom et qu’il change de nom, avons-nous un nouveau partenaire ? Non. L’entité métier est restée la même ; l’un de ses attributs a changé. L’ID unique d’un enregistrement doit survivre aux changements de la chose qu’il identifie, ce qui exclut les noms, les adresses courriel, les numéros de téléphone, les adresses et les noms d’utilisateur, aussi pratiques qu’ils paraissent quand on commence à construire un système.

Sans signification. Cela paraît étrange la première fois qu’on l’entend. Pourquoi voudrais-je qu’un identifiant n’ait pas de sens ? Parce que le sens change. Imaginez que quelqu’un construise un ID de livraison qui encode le centre, le partenaire distributeur, la date de livraison et un numéro de séquence : PHX-KEY-20261002-0042. Ça a l’air astucieux. Puis le destinataire reporte au vendredi. Changeons-nous l’identifiant ? Si non, il nous ment. Si oui, nous avons changé l’ID unique de la livraison parce que l’un de ses attributs a changé, et chaque système qui avait stocké l’ancien ID vient de la perdre de vue. L’identifiant essayait de faire deux métiers : identifier la livraison et la décrire. Je préfère laisser les attributs la décrire et laisser l’identifiant faire un seul métier ennuyeux : l’identifier. Les identifiants ennuyeux sont de bons identifiants.

Jamais une donnée personnelle. Celle-ci est assez importante pour que je la garde à part. N’utilisez pas d’informations personnelles identifiantes comme identifiant juste parce qu’elles paraissent uniques. Chez Steve Trucking, il est tentant de reconnaître un destinataire à son numéro de téléphone. Mais une clé est copiée partout où des systèmes doivent relier des enregistrements : intégrations, exports, journaux, fichiers de statut renvoyés aux partenaires distributeurs, entrepôt de données, données de test. Faites d’un numéro de téléphone la clé, et vous avez répandu les données personnelles d’un destinataire dans toute l’architecture.

Une clé doit aussi être présente sur chaque enregistrement : jamais nulle ni vide. Si certaines personnes ne veulent pas, ou ne devraient pas avoir à, vous donner une valeur, cette valeur ne peut pas être la clé. C’est pourquoi les systèmes émettent leurs propres identifiants internes, et les données personnelles, si vous en avez besoin, deviennent un attribut protégé.

Ma règle est donc : unique, immuable, sans signification, jamais une donnée personnelle.

Clés naturelles et clés de substitution

Les spécialistes des bases de données ont des noms pour une partie de tout cela. Une clé naturelle existe déjà dans les données métier : le VIN d’un camion en est un bon exemple. Notre application ne l’a pas inventée, et elle a déjà un sens. Une clé de substitution est créée spécifiquement pour identifier l’enregistrement ; elle ne décrit rien, elle identifie, c’est tout.

Dans la plupart des architectures, je préfère une clé de substitution comme ID interne de l’enregistrement, et je garde les identifiants naturels importants comme attributs. Cela ne rend pas les identifiants naturels mauvais ; ils sont souvent extrêmement importants. Simplement, je n’en fais pas automatiquement l’ID unique de l’enregistrement. Demandez ce qui se passe si la valeur est corrigée, reformatée, remplacée, réutilisée, manquante, ou si elle arrive de plusieurs systèmes sources. C’est là qu’une décision d’apparence simple devient une décision d’architecture.

Une chose peut avoir plusieurs identifiants utiles

L’ID interne de l’enregistrement n’est pas forcément l’identifiant que tous les autres systèmes utilisent. Steve Trucking peut identifier une livraison en interne avec un ID généré. Chaque partenaire distributeur connaît la même livraison par son propre numéro de commande : Keystone dans son manifeste CSV, Redrock dans son API, Brightwave dans ses messages EDI. Et les huit ans d’historique de RouteDesk, l’ancien outil de répartition, utilisent les propres ID de livraison de RouteDesk.

Ces identifiants comptent. Nous devons les conserver et les faire correspondre correctement, car une mise à jour de statut doit repartir vers chaque partenaire sous son numéro. Mais ils n’ont pas tous à devenir l’ID unique de la livraison. « Quel est son ID ? » peut avoir plus d’une réponse, et l’architecte doit savoir quel ID fait foi dans quel contexte. Nous y reviendrons avec les données de référence et l’intégration.

Les relations dépendent des identifiants uniques

Revenez maintenant aux traits que nous avons dessinés. Un manifeste liste des livraisons. Un destinataire reçoit des livraisons. Une équipe a des affectations d’équipe. Ces relations ne fonctionnent que parce que nous pouvons identifier de façon fiable les choses aux deux extrémités.

Voici où cela fait mal chez Steve Trucking. Un partenaire distributeur révise son manifeste le jour même : une commande annulée, un article remplacé, une nouvelle adresse. Si nous ne pouvons pas faire correspondre la ligne révisée à la livraison que nous avons déjà, par le numéro de commande du partenaire, nous créons une deuxième livraison pour le même réfrigérateur, et une équipe risque de se présenter deux fois. Boîtes, attributs, clés et relations ne sont pas des idées séparées. Ce sont toutes des parties du même modèle.

Click to enlarge

À ce stade, vous pensez peut-être : « Salesforce donne un ID à chaque enregistrement. » C’est exact, et nous y viendrons. Si les données vivent dans Salesforce, chaque enregistrement reçoit un ID généré par Salesforce. Il est cryptique et difficile à lire, donc nous exposons généralement aussi un champ d’ID utilisable par les gens, comme un numéro de livraison D-000184227, un champ à numérotation automatique. Les gens pensent souvent que ce numéro est l’ID de l’enregistrement, mais ce n’est pas le cas : l’ID Salesforce est toujours là en dessous. Un système externe ou une base de données, Oracle ou SQL Server, a aussi ses propres ID uniques. Mais l’architecture peut finir par inclure Salesforce, l’ERP financier, Snowflake, Data 360, les systèmes des partenaires et des systèmes qui n’existent pas encore. Le modèle logique décrit les données métier sans faire dépendre chaque décision d’une seule technologie. La façon dont Salesforce le met en œuvre physiquement est une étape ultérieure.

Ce que l’architecte décide ici

Quand je transforme un modèle conceptuel en modèle logique, je décide :

• Quels attributs décrivent réellement chaque entité.
• Comment chaque entité est identifiée de façon unique, et si cet identifiant est assez stable pour être son ID unique.
• Quels identifiants métier (numéros de commande des partenaires, anciens ID) doivent être conservés et mis en correspondance.
• Si des informations sensibles sont utilisées comme clé.
• Si les relations relient les entités par des ID uniques fiables.

Nous avons maintenant des entités, des relations, des attributs et des ID uniques : les débuts d’un vrai modèle de données logique. Mais il reste un problème. Il est très facile de mettre des données parfaitement valides au mauvais endroit. C’est là qu’intervient la normalisation.

Pour aller plus loin

• Custom Field Types (opens in a new tab), aide Salesforce (en anglais, consulté le 2026-10-09) : la numérotation automatique attribue à chaque enregistrement un numéro unique avec un format d’affichage, comme un préfixe et des zéros initiaux ; ce n’est pas l’ID Salesforce de l’enregistrement. Voir aussi Auto-Number Fields Are Not Always Sequential (opens in a new tab) (en anglais, consulté le 2026-10-09).