Modéliser les données pour leur sens

🌐 Aussi en 28 langues

English · Español · 日本語 · Português (Brasil) · 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) · Français (Canada) · Deutsch (Schweiz)

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

Chapitre 2 du cours Data Architect, Partie 1 : Devenir architecte de données. Précédent : Penser comme un architecte de données Salesforce.

L’une des choses que je fais lors d’un premier appel avec un client, c’est écouter les noms. Partenaire distributeur. Destinataire. Centre de distribution. Livraison. Camion. Quelque part dans cette conversation se trouvent les débuts de mon modèle de données, et je veux commencer à le voir avant que quiconque ouvre la Configuration. Dans ce chapitre, nous le ferons deux fois. D’abord sur quelque chose que tout le monde comprend, une école pour chiens : des propriétaires, des éleveurs, des chiens et les tours qu’ils connaissent. Puis avec Steve Trucking, l’entreprise de livraison du dernier kilomètre que nous utilisons tout au long du cours.

Image générée par IA.

Au chapitre 1, j’ai dit que le modèle de données est l’ossature. Ce chapitre explique comment concevoir l’ossature, dans l’ordre où je le fais : comprendre le métier, décrire les données, et seulement ensuite décider comment Salesforce va le mettre en œuvre. Conceptuel, puis logique, puis physique. Si vous montrez n’importe quoi dans mon modèle physique en demandant « pourquoi c’est là ? », je veux pouvoir vous ramener à travers le modèle logique et le modèle conceptuel jusqu’à quelque chose dont le métier a réellement besoin.

Chaque module commence par les chiens, dans une courte section appelée Assis, pas bouger, modèle, puis applique le même geste à Steve Trucking. Suivez le modèle des chiens au fil des modules : c’est un seul diagramme qui grandit de module en module, des simples boîtes aux relations, puis à un modèle de données détaillé, puis aux objets Salesforce, et chaque boîte reste au même endroit, pour que vous voyiez exactement ce que chaque étape ajoute.

Le chapitre en six parties

1. Écouter les noms. Trouver les débuts d’un modèle de données dans une conversation métier, et oublier Salesforce un instant. Cinq noms autour des chiens deviennent cinq boîtes candidates.
2. Dessiner les relations. Un ou plusieurs, obligatoire ou facultatif, maintenant ou dans le temps, et le concept métier caché dans un plusieurs-à-plusieurs : le Tour du chien, et l’affectation d’équipe.
3. Construire le modèle logique. Des attributs qui décrivent la bonne chose, et des clés uniques, immuables, sans signification, jamais des données personnelles. Pourquoi le nom d’un chien, le téléphone de son propriétaire et même sa puce électronique ne suffisent pas comme clé.
4. Mettre les données à leur place. Ce qu’est la normalisation, puis un tableur de six chiens mené pas à pas jusqu’à la troisième forme normale, et les mêmes trois questions chez Steve Trucking.
5. Concevoir en troisième forme normale, puis prendre du recul. Quand je m’éloigne volontairement du modèle propre : utilisateurs, rapports, liste de sélection ou référence, volume, analyse et IA. Et le jour où l’école pour chiens commence à accepter les chats.
6. Transformer le modèle en Salesforce. Du modèle logique aux objets standard et personnalisés, aux champs et aux relations, principal-détails ou référence, et pourquoi on ne conçoit pas depuis la Configuration.

Quand vous avez terminé, testez-vous avec le guide d’étude du chapitre : une liste de contrôle pour l’examen, les habitudes qui vont au-delà, les mots à connaître et quelques questions.

Ce que vous saurez faire

• Trouver des entités candidates et des relations dans une conversation ou un cahier des charges, et les valider avec le métier.
• Décrire chaque relation : sa cardinalité, son sens, si elle est obligatoire, et si son historique compte.
• Construire un modèle logique avec les attributs sur les bonnes entités et des clés qui tiennent.
• Appliquer la 1FN, la 2FN et la 3FN comme des questions pratiques, et dénormaliser délibérément en connaissant le coût.
• Transposer un modèle logique dans Salesforce et faire remonter chaque choix physique jusqu’au métier.

Pour aller plus loin

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), aide Salesforce (en anglais, consulté le 2026-10-12) : l’objectif DM-1, le modèle de données

Suivant : L’architecture de données Salesforce