Study guide
Also in 28 languages
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) · Français (Canada) · Deutsch (Schweiz)
Study guide for chapter 2 of the Data Architect course. Read the six modules first; this page helps you check what stuck.
About this study guide. It’s built only from this course’s own content and the published Salesforce exam guide’s list of objectives. It is never based on real exam questions, and it doesn’t claim to know what’s on the exam. If you’ve taken the exam, please don’t send me questions from it: the certification agreement forbids sharing them, and memorizing answers is the wrong way to become an architect anyway.
This chapter is the foundation for the exam’s Data Modeling and Database Design section, which is a quarter of the exam. It covers the thinking; the next chapter, Salesforce Data Architecture, covers how the platform builds it. So most of what’s tested on objects, fields and relationships needs both chapters.
For the Exam
Section titled “For the Exam”The points from this chapter most likely to matter on the exam. Each one is tied to its exam objective and links to where it’s taught. Tick them off as you go.
DM-1: comparing techniques for designing a Salesforce data model
- I can explain the difference between a conceptual, a logical and a physical data model, and what each one is for. (Turn the Model into Salesforce)
- I can find candidate entities in a requirement, and tell a person doing a job from a piece of data. (Nouns Give You Candidate Entities)
- I can read and draw crow’s-foot notation: one, many, and the second mark for optional or required. (Read the Lines, Optionality Matters Too)
- I can name a relationship’s cardinality: one-to-one, one-to-many, many-to-many. (Ask “One or Many?”)
- I know a many-to-many relationship becomes an entity of its own, and in Salesforce usually a junction object with two parents. (Relationships Can Become Things)
- I know when a relationship needs history (a record with start and end dates) rather than a field that gets overwritten. (Time Changes Relationships)
- I can pick a good unique ID, and I know why a natural key or anything with personal information is a risky one. (Then We Have to Talk About Unique IDs)
- I know the difference between a natural key and a surrogate key, and that one record can carry several external identifiers. (Natural Keys and Surrogate Keys)
- I know an Auto Number field is a readable number, not the record’s Salesforce ID. (Relationships Depend on Unique IDs)
- I can apply first, second and third normal form, and spot a field that holds several values or repeats a fact about something else. (A Simple Way to Think About 1NF, 2NF and 3NF)
- I can explain when to denormalize on purpose (users, reporting, scale), and what it costs. (Design to Third Normal Form, Then Back Off)
- I can decide between a picklist and a lookup to an object for a list of values. (Lookup or Picklist?)
- I know a custom report type allows at most four object relationships, and why that matters for deep models. (Lookup or Picklist?)
- I know when master-detail fits (the child is never re-parented) and when a lookup is safer, including Salesforce’s guidance of no more than 10,000 children on one parent. (Relationships Become Platform Decisions)
- I know why to avoid polymorphic relationships where I can. (Relationships Become Platform Decisions)
- I know a business entity doesn’t automatically mean a custom object: it can be a standard object, a field, configuration, or data that lives outside Salesforce. (A Business Entity Doesn’t Automatically Mean a Custom Object)
Beyond the Exam
Section titled “Beyond the Exam”The exam is the floor, not the ceiling. These are the habits from this chapter that an architect needs, whether or not a question ever asks about them.
- Forget Salesforce for a minute. Model the business before you map it to Account and Contact.
- Listen for the word that hides two things. At Steve Trucking, “customer” was a Retail Partner and a Recipient.
- The model is part of the conversation. Your first model isn’t meant to be right; it’s meant to show you where you’re wrong.
- Name the lines. Two models with the same boxes can mean different things.
- Ask “now, or over time?” of every relationship.
- Unique, unchanging, meaningless, never PII.
- Put a fact where it belongs, then back off on purpose, and write down why.
- Denormalization doesn’t remove complexity; it moves it. Know who owns the truth.
- One source of truth, many shapes: screens, reports, the warehouse and AI.
- Don’t design from Setup. Draw the model before you click New Custom Object.
- Trace every physical decision back to something the business needs.
Words to Know
Section titled “Words to Know”| Term | In one line |
|---|---|
| Entity | A thing the business cares about and keeps data on |
| Candidate entity | A noun that might become an entity, once you’ve asked about it |
| Attribute | A fact that describes an entity |
| Relationship | How two entities are connected, named in business language |
| Cardinality | How many of one relate to how many of the other |
| Optionality | Whether the relationship is required, or can be zero |
| Crow’s foot | The mark for “many” at the end of a line |
| Junction object | Salesforce’s way to build a many-to-many relationship: a child of both parents |
| Conceptual model | What exists in the business and how it relates; no Salesforce |
| Logical model | The data: attributes, unique IDs and relationships, still not tied to a platform |
| Physical model | How the platform will build it: objects, fields and relationship types |
| Natural key | An identifier that already exists in the business, like a truck’s VIN |
| Surrogate key | An identifier created only to identify the record |
| External identifier | Another system’s ID for the same record, kept and mapped |
| Normalization (1NF, 2NF, 3NF) | Putting each fact where it belongs: one value per field, facts about the whole key, no facts about other facts |
| Denormalization | Copying or flattening data on purpose, for a reason you can name |
| Update anomaly | The same fact stored in many places, so one change leaves some copies wrong |
Check Yourself
Section titled “Check Yourself”Short scenarios in the style of the course. Decide your answer before you open it.
1. A business tells you a crew drives a truck. Six weeks later, someone asks which crew had truck 117 on a given day. What should the model have had?
A Crew Assignment: the relationship between crew and truck as a record of its own, with a start date, an end date and the route. Crews and trucks are many-to-many over time, and the business cares about the history. A field on the truck would have been overwritten. Reread Time Changes Relationships.
2. A team proposes using each Recipient's phone number as the unique ID, "because it's unique." What do you say?
It fails the tests: phone numbers change and get shared, so it isn’t unchanging or reliably unique, and it’s personal information that would be copied into every system that links to the record. Use a meaningless generated ID and keep the phone number as an attribute. Reread Then We Have to Talk About Unique IDs.
3. A Delivery has fields Item 1, Item 2 and Item 3. A delivery with four items arrives. What's the real problem, and the fix?
The model hid a repeating structure inside fields (a first normal form problem). The fix isn’t an Item 4 field; it’s a Delivery Item entity, a child of Delivery, so every item is a record. Reread First Normal Form.
4. Every delivery stores the distribution center manager's name. The manager changes. What went wrong?
A fact about something else (the distribution center) was stored on the delivery: a third normal form problem, and now an update anomaly across hundreds of records. The manager belongs with the distribution center; the delivery points at the distribution center. Reread Third Normal Form.
5. The kind of stop (delivery only, with install, with haul-away) needs a duration, crew skills and a checklist. Picklist or object?
An object. It has more than one column of information, it’s managed by the business and it changes on its own schedule. A delivery’s status, a short stable list of labels, stays a picklist. Reread Lookup or Picklist?.
6. Partners want an on-time scorecard by region, and the region lives on the distribution center. You copy the region onto each delivery. What must you decide?
Who owns the truth, how the copy stays in sync, and whether old deliveries should keep the region that was true when they happened or follow the distribution center if it moves. Denormalizing moved the complexity; it didn’t remove it. Reread Sometimes Reporting Wins.
7. A trick like Sit could be linked to hundreds of thousands of pets. Master-detail or lookup from Pet Trick to Trick?
A lookup. Salesforce’s guidance is no more than 10,000 children on one parent, and a popular trick would pass it. Master-detail fits Pet Trick to Pet, because a pet’s trick is never re-parented and one pet knows only a few tricks; it’s also what lets the pet roll up its Tricks Known count. Reread Sit, Stay, Model.
Explore
Section titled “Explore”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (checked 2026-09-25): the official list of objectives and their weights. Always check the current version before you book the exam.