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)
Guide d’étude du chapitre 2 du cours Data Architect. Lisez d’abord les six modules ; cette page vous aide à vérifier ce que vous en avez retenu.
À propos de ce guide d’étude. Il est construit uniquement à partir du contenu de ce cours et de la liste des objectifs publiée dans le guide d’examen de Salesforce. Il ne s’appuie jamais sur de vraies questions d’examen et ne prétend pas savoir ce que contient l’examen. Si vous avez passé l’examen, merci de ne pas m’en envoyer les questions : l’accord de certification interdit de les partager, et apprendre des réponses par cœur n’est de toute façon pas la bonne manière de devenir architecte.
Ce chapitre est la base de la section Data Modeling and Database Design de l’examen, qui représente un quart de l’examen. Il couvre la réflexion ; le chapitre suivant, L’architecture de données Salesforce, couvre la façon dont la plateforme la construit. La plupart de ce qui est testé sur les objets, les champs et les relations a donc besoin des deux chapitres.
Pour l’examen
Section intitulée « Pour l’examen »Les points de ce chapitre les plus susceptibles de compter à l’examen. Chacun est rattaché à son objectif d’examen et renvoie à l’endroit où il est enseigné. Cochez-les au fur et à mesure.
DM-1 : comparer les techniques de conception d’un modèle de données Salesforce
- Je sais expliquer la différence entre un modèle de données conceptuel, logique et physique, et à quoi sert chacun. (Transformer le modèle en Salesforce)
- Je sais trouver des entités candidates dans une exigence, et distinguer une personne qui fait un travail d’une donnée. (Les noms vous donnent des entités candidates)
- Je sais lire et dessiner la notation en pattes de corbeau : un, plusieurs, et la deuxième marque pour facultatif ou obligatoire. (Lire les traits, Le caractère facultatif compte aussi)
- Je sais nommer la cardinalité d’une relation : un-à-un, un-à-plusieurs, plusieurs-à-plusieurs. (Demandez « un ou plusieurs ? »)
- Je sais qu’une relation plusieurs-à-plusieurs devient une entité à part entière, et dans Salesforce généralement un objet de jonction avec deux parents. (Les relations peuvent devenir des choses)
- Je sais quand une relation a besoin d’historique (un enregistrement avec des dates de début et de fin) plutôt que d’un champ écrasé. (Le temps change les relations)
- Je sais choisir un bon ID unique, et je sais pourquoi une clé naturelle ou tout ce qui contient des informations personnelles est risqué. (Ensuite, il faut parler des identifiants uniques)
- Je connais la différence entre une clé naturelle et une clé de substitution, et je sais qu’un enregistrement peut porter plusieurs identifiants externes. (Clés naturelles et clés de substitution)
- Je sais qu’un champ à numérotation automatique est un numéro lisible, pas l’ID Salesforce de l’enregistrement. (Les relations dépendent des identifiants uniques)
- Je sais appliquer les première, deuxième et troisième formes normales, et repérer un champ qui contient plusieurs valeurs ou répète un fait sur autre chose. (Une façon simple de penser la 1FN, la 2FN et la 3FN)
- Je sais expliquer quand dénormaliser délibérément (utilisateurs, rapports, volume), et ce que cela coûte. (Concevoir en troisième forme normale, puis prendre du recul)
- Je sais choisir entre une liste de sélection et une référence vers un objet pour une liste de valeurs. (Référence ou liste de sélection ?)
- Je sais qu’un type de rapport personnalisé autorise au plus quatre relations d’objet, et pourquoi cela compte pour les modèles profonds. (Référence ou liste de sélection ?)
- Je sais quand principal-détails convient (l’enfant ne change jamais de parent) et quand une référence est plus sûre, y compris la recommandation de Salesforce de ne pas dépasser 10 000 enfants par parent. (Les relations deviennent des décisions de plateforme)
- Je sais pourquoi éviter les relations polymorphes quand je le peux. (Les relations deviennent des décisions de plateforme)
- Je sais qu’une entité métier ne veut pas automatiquement dire un objet personnalisé : ce peut être un objet standard, un champ, de la configuration, ou des données qui vivent hors de Salesforce. (Une entité métier ne veut pas automatiquement dire un objet personnalisé)
Au-delà de l’examen
Section intitulée « Au-delà de l’examen »L’examen est le plancher, pas le plafond. Voici les habitudes de ce chapitre dont un architecte a besoin, qu’une question les aborde ou non.
- Oubliez Salesforce un instant. Modélisez le métier avant de le transposer en Compte et Contact.
- Écoutez le mot qui en cache deux. Chez Steve Trucking, « client » était un partenaire distributeur et un destinataire.
- Le modèle fait partie de la conversation. Votre premier modèle n’est pas fait pour être juste ; il est fait pour vous montrer où vous vous trompez.
- Nommez les traits. Deux modèles avec les mêmes boîtes peuvent signifier des choses différentes.
- Demandez « maintenant, ou dans le temps ? » pour chaque relation.
- Unique, immuable, sans signification, jamais une donnée personnelle.
- Mettez un fait à sa place, puis prenez du recul délibérément, et écrivez pourquoi.
- La dénormalisation ne supprime pas la complexité ; elle la déplace. Sachez à qui appartient la vérité.
- Une source de vérité, plusieurs formes : écrans, rapports, entrepôt et IA.
- Ne concevez pas depuis la Configuration. Dessinez le modèle avant de cliquer sur Nouvel objet personnalisé.
- Faites remonter chaque décision physique jusqu’à quelque chose dont le métier a besoin.
Les mots à connaître
Section intitulée « Les mots à connaître »| Terme | En une ligne |
|---|---|
| Entité | Une chose dont le métier se soucie et sur laquelle il conserve des données |
| Entité candidate | Un nom qui pourrait devenir une entité, une fois qu’on s’est posé la question |
| Attribut | Un fait qui décrit une entité |
| Relation | La façon dont deux entités sont reliées, nommée dans le langage du métier |
| Cardinalité | Combien de l’une sont liés à combien de l’autre |
| Caractère facultatif | Si la relation est obligatoire, ou peut être nulle |
| Patte de corbeau | La marque pour « plusieurs » à l’extrémité d’un trait |
| Objet de jonction | La façon dont Salesforce construit une relation plusieurs-à-plusieurs : un enfant des deux parents |
| Modèle conceptuel | Ce qui existe dans le métier et comment c’est lié ; pas de Salesforce |
| Modèle logique | Les données : attributs, ID uniques et relations, toujours sans lien avec une plateforme |
| Modèle physique | Comment la plateforme va le construire : objets, champs et types de relation |
| Clé naturelle | Un identifiant qui existe déjà dans le métier, comme le VIN d’un camion |
| Clé de substitution | Un identifiant créé uniquement pour identifier l’enregistrement |
| Identifiant externe | L’ID qu’un autre système donne au même enregistrement, conservé et mis en correspondance |
| Normalisation (1FN, 2FN, 3FN) | Mettre chaque fait à sa place : une valeur par champ, des faits sur toute la clé, pas de faits sur d’autres faits |
| Dénormalisation | Copier ou aplatir des données délibérément, pour une raison qu’on peut nommer |
| Anomalie de mise à jour | Le même fait stocké à de nombreux endroits, de sorte qu’un changement laisse certaines copies fausses |
Testez-vous
Section intitulée « Testez-vous »De courts scénarios dans le style du cours. Décidez de votre réponse avant de l’ouvrir.
1. Le métier vous dit qu'une équipe conduit un camion. Six semaines plus tard, quelqu'un demande quelle équipe avait le camion 117 un jour donné. Que le modèle aurait-il dû contenir ?
Une affectation d’équipe : la relation entre équipe et camion comme enregistrement à part entière, avec une date de début, une date de fin et la tournée. Équipes et camions sont en plusieurs-à-plusieurs dans le temps, et le métier s’intéresse à l’historique. Un champ sur le camion aurait été écrasé. Relisez Le temps change les relations.
2. Une équipe propose d'utiliser le numéro de téléphone de chaque destinataire comme ID unique, « parce qu'il est unique ». Que répondez-vous ?
Il échoue aux tests : les numéros de téléphone changent et sont partagés, donc ils ne sont ni immuables ni uniques de façon fiable, et ce sont des informations personnelles qui seraient copiées dans chaque système relié à l’enregistrement. Utilisez un ID généré sans signification et gardez le numéro de téléphone comme attribut. Relisez Ensuite, il faut parler des identifiants uniques.
3. Une livraison a des champs Article 1, Article 2 et Article 3. Une livraison avec quatre articles arrive. Quel est le vrai problème, et la correction ?
Le modèle a caché une structure répétée dans des champs (un problème de première forme normale). La correction n’est pas un champ Article 4 ; c’est une entité article de livraison, enfant de la livraison, pour que chaque article soit un enregistrement. Relisez Première forme normale.
4. Chaque livraison stocke le nom du responsable du centre de distribution. Le responsable change. Qu'est-ce qui n'allait pas ?
Un fait concernant autre chose (le centre de distribution) était stocké sur la livraison : un problème de troisième forme normale, et maintenant une anomalie de mise à jour sur des centaines d’enregistrements. Le responsable a sa place avec le centre ; la livraison pointe vers le centre. Relisez Troisième forme normale.
5. Le type d'arrêt (livraison seule, avec installation, avec enlèvement) a besoin d'une durée, de compétences d'équipe et d'une liste de contrôle. Liste de sélection ou objet ?
Un objet. Il a plus d’une colonne d’information, il est géré par le métier et il change à son propre rythme. Le statut d’une livraison, une liste d’étiquettes courte et stable, reste une liste de sélection. Relisez Référence ou liste de sélection ?.
6. Les partenaires veulent un tableau de bord de ponctualité par région, et la région se trouve sur le centre de distribution. Vous copiez la région sur chaque livraison. Que devez-vous décider ?
À qui appartient la vérité, comment la copie reste synchronisée, et si les anciennes livraisons doivent garder la région qui était vraie à leur date ou suivre le centre s’il change de région. Dénormaliser a déplacé la complexité ; cela ne l’a pas supprimée. Relisez Parfois, les rapports l’emportent.
7. Un tour comme « Assis » pourrait être lié à des centaines de milliers d'animaux. Principal-détails ou référence de Tour de l'animal vers Tour ?
Une référence. Salesforce recommande au plus 10 000 enfants par parent, et un tour populaire dépasserait ce seuil. Principal-détails convient entre Tour de l’animal et Animal, car le tour d’un animal ne change jamais de parent et un animal ne connaît que quelques tours ; c’est aussi ce qui permet à l’animal de faire le cumul de son nombre de Tours connus. Relisez Assis, pas bouger, modèle.
Pour aller plus loin
Section intitulée « Pour aller plus loin »- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), aide Salesforce (en anglais, consulté le 2026-09-25) : la liste officielle des objectifs et de leurs pondérations. Vérifiez toujours la version actuelle avant de réserver l’examen.