Skip to content
SteveTechArcSteveTechArc Courses

Modeling Data for Meaning

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)

Chapter 2 of Data Architect, Part 1: Becoming a Data Architect. Previous: Thinking Like a Salesforce Data Architect.

One of the things I do on a first call with a client is listen for the nouns. Retail Partner. Recipient. Distribution Center. Delivery. Truck. Somewhere in that conversation are the beginnings of my data model, and I want to start seeing it before anyone opens Setup. In this chapter we’ll do it twice. First on something everybody understands, a dog school: owners, breeders, dogs and the tricks they know. Then on Steve Trucking, the last-mile delivery company we use throughout the course.

Architect listening to a delivery-business owner and sketching the first shape of a data model in a desert home

Image generated with AI.

In Chapter 1 I said the data model is the bones. This chapter is how you design the bones, in the order I do it: understand the business, describe the data, and only then decide how Salesforce will implement it. Conceptual, then logical, then physical. If you point at anything in my physical model and ask “why is that there?”, I want to be able to walk you back through the logical model and the conceptual model to something the business actually needs.

Every module starts with the dogs, in a short section called Sit, Stay, Model, and then takes the same move to Steve Trucking. Watch the dog model as you go: it’s one diagram that grows from module to module, from plain boxes to relationships to a detailed data model to Salesforce objects, and every box stays in the same place, so you can see exactly what each step adds.

The chapter in six parts

Section titled “The chapter in six parts”
  1. Listen for the Nouns. Find the beginnings of a data model in a business conversation, and forget Salesforce for a minute. Five dog nouns become five candidate boxes.
  2. Draw the Relationships. One or many, required or optional, now or over time, and the business concept hiding in a many-to-many: the Dog Trick, and the Crew Assignment.
  3. Build the Logical Model. Attributes that describe the right thing, and keys that are unique, unchanging, meaningless, never PII. Why a dog’s name, its owner’s phone and even its microchip fall short as its key.
  4. Put Data Where It Belongs. What normalization is, then a spreadsheet of six dogs taken step by step to Third Normal Form, and the same three questions at Steve Trucking.
  5. Design to Third Normal Form, Then Back Off. When I back away from the clean model on purpose: users, reporting, picklist or lookup, scale, analytics and AI. And the day the dog school starts taking cats.
  6. Turn the Model into Salesforce. From the logical model to standard and custom objects, fields and relationships, master-detail or lookup, and why you don’t design from Setup.

When you’ve finished, check yourself with the chapter study guide: a checklist for the exam, the habits beyond it, the words to know, and a few questions.

What you’ll be able to do

Section titled “What you’ll be able to do”
  • Find candidate entities and relationships in a conversation or a requirements document, and validate them with the business.
  • Describe each relationship: its cardinality, its meaning, whether it’s required, and whether its history matters.
  • Build a logical model with attributes on the right entities and keys that hold up.
  • Apply 1NF, 2NF and 3NF as practical questions, and denormalize deliberately, knowing what it costs.
  • Map a logical model to Salesforce and trace every physical choice back to the business.

Explore

Section titled “Explore”

Next: Salesforce Data Architecture