为含义建模数据
另有 28 种语言版本
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) · Français (Canada) · Deutsch (Schweiz)
Data Architect 课程第 2 章的学习指南。请先阅读六个模块；这一页帮你检查自己记住了什么。
**关于本学习指南。**它只依据本课程自己的内容，以及 Salesforce 公开发布的考试指南中的目标清单编写。它从不基于真实的考试题目，也不声称知道考试会考什么。如果你参加过考试，请不要把考题发给我：认证协议禁止分享考题，而且死记答案本来就不是成为架构师的正确方式。
本章是考试中“数据建模与数据库设计”部分的基础，这部分占整个考试的四分之一。本章讲的是思考方式；下一章Salesforce 数据架构讲的是平台如何构建它。所以关于对象、字段和关系的大部分考点，都需要结合这两章。
本章中最可能在考试中用到的要点。每一条都对应一个考试目标，并链接到讲授它的地方。边学边打勾。
DM-1：比较设计 Salesforce 数据模型的技术
- 我能解释概念、逻辑和物理数据模型之间的区别，以及每一种的用途。（把模型落到 Salesforce 中）
- 我能在一项需求中找出候选实体，并区分在做某项工作的人和一份数据。（名词给你候选实体）
- 我能读懂并画出鸦爪表示法：一、多，以及表示可选或必需的第二个标记。（读懂连线，可选性同样重要）
- 我能说出一个关系的基数：一对一、一对多、多对多。（问“一个还是多个？”）
- 我知道多对多关系会变成一个独立的实体，在 Salesforce 里通常是一个有两个父对象的联接对象。（关系可以变成事物）
- 我知道一个关系什么时候需要历史（一条带开始和结束日期的记录），而不是一个会被覆盖的字段。（时间会改变关系）
- 我能选出一个好的唯一 ID，也知道为什么自然键或任何带有个人信息的东西是有风险的选择。（然后我们得谈谈唯一 ID）
- 我知道自然键和代理键的区别，也知道一条记录可以带有好几个外部标识符。（自然键和代理键）
- 我知道自动编号字段是一个可读的编号，而不是记录的 Salesforce ID。（关系依赖于唯一 ID）
- 我能运用第一、第二和第三范式，并识别出存放了多个值或者重复了关于别的东西的事实的字段。（理解 1NF、2NF 和 3NF 的简单方法）
- 我能解释什么时候应该有意反规范化（用户、报表、规模），以及它的代价。（设计到第三范式，然后适度回退）
- 对于一份值列表，我能在选项列表和指向对象的查找关系之间做出选择。（查找关系还是选项列表？）
- 我知道自定义报表类型最多允许四层对象关系，以及这为什么对层次很深的模型很重要。（查找关系还是选项列表？）
- 我知道什么时候适合用主从关系（子记录永远不会更换父记录），什么时候查找关系更安全，包括 Salesforce 关于单个父记录下不超过 10,000 条子记录的建议。（关系变成平台层面的决定）
- 我知道为什么能避免就要避免多态关系。（关系变成平台层面的决定）
- 我知道一个业务实体并不自动意味着一个自定义对象：它可以是一个标准对象、一个字段、一项配置，或者存在于 Salesforce 之外的数据。（一个业务实体并不自动意味着一个自定义对象）
考试是底线，不是天花板。下面这些是本章中架构师需要的习惯，不管有没有考题问到它们。
- **暂时忘掉 Salesforce。**先为业务建模，再把它映射到客户和联系人。
- **留意背后藏着两样东西的那个词。**在 Steve Trucking，“客户”既是零售合作伙伴，也是收货人。
- **模型是对话的一部分。**你的第一个模型不是为了正确，而是为了让你看到自己哪里错了。
- **给连线起名字。**方框相同的两个模型，含义可能不同。
- 对每一个关系都问一问**“现在，还是随时间变化？”**
- 唯一、不变、无含义、绝不是 PII。
- **把事实放在它该在的地方，**然后有意地适度回退，并把原因写下来。
- **反规范化不会消除复杂度，只会转移它。**要知道谁拥有真相。
- **一个真相来源，多种形状：**界面、报表、数据仓库和 AI。
- **不要从设置界面开始设计。**在点击“新建自定义对象”之前先画出模型。
- 把每一个物理层面的决定都追溯到业务需要的某样东西。
| 术语 | 一句话解释 |
|---|---|
| 实体 | 业务在意并为之保存数据的一样东西 |
| 候选实体 | 一个在你问过之后可能成为实体的名词 |
| 属性 | 描述一个实体的事实 |
| 关系 | 两个实体如何连接，用业务语言命名 |
| 基数 | 这边的多少个与那边的多少个相关 |
| 可选性 | 关系是必需的，还是可以为零 |
| 鸦爪 | 线末端表示“多”的标记 |
| 联接对象 | Salesforce 构建多对多关系的方式：同时是两个父对象的子对象 |
| 概念模型 | 业务中有什么以及它们如何关联；不涉及 Salesforce |
| 逻辑模型 | 数据：属性、唯一 ID 和关系，仍不与某个平台绑定 |
| 物理模型 | 平台将如何构建它：对象、字段和关系类型 |
| 自然键 | 业务中本来就存在的标识符，比如卡车的 VIN |
| 代理键 | 只为识别记录而创建的标识符 |
| 外部标识符 | 另一个系统为同一条记录所用的 ID，需要保留和映射 |
| 规范化（1NF、2NF、3NF） | 把每个事实放在它该在的地方：每个字段一个值，事实关于整个键，不存关于其他事实的事实 |
| 反规范化 | 出于一个你能说出来的原因，有意地复制或扁平化数据 |
| 更新异常 | 同一个事实存放在很多地方，于是一次修改会让一些副本出错 |
按课程风格编写的简短情景题。打开答案之前，先想好你的答案。
1. 业务方告诉你一个配送小组驾驶一辆卡车。六周后，有人问某一天是哪个小组开的 117 号卡车。模型本应该有什么？
一个配送小组分配：把配送小组和卡车之间的关系作为一条独立的记录，带有开始日期、结束日期和路线。随着时间推移，配送小组和卡车是多对多关系，而业务在意其历史。卡车上的一个字段会被覆盖掉。重读时间会改变关系。
2. 一个团队提议用每位收货人的电话号码作为唯一 ID，“因为它是唯一的”。你怎么说？
它通不过检验：电话号码会变，也会被共用，所以它既不是不变的，也不是可靠唯一的，而且它是个人信息，会被复制到每一个链接到这条记录的系统里。使用一个无含义的生成 ID，把电话号码作为属性保留。重读然后我们得谈谈唯一 ID。
3. 一个配送对象有项目 1、项目 2 和项目 3 三个字段。来了一次有四个项目的配送。真正的问题是什么，怎么修？
模型把一个重复的结构藏在了字段里（一个第一范式问题）。修法不是加一个项目 4 字段，而是建一个配送项目实体，作为配送的子实体，让每个项目都是一条记录。重读第一范式。
4. 每次配送都存了配送中心经理的名字。经理换人了。哪里出了问题？
一个关于别的东西（配送中心）的事实被存在了配送上：这是一个第三范式问题，而现在它成了横跨几百条记录的更新异常。经理属于配送中心；配送指向配送中心。重读第三范式。
5. 停靠点类型（仅配送、加安装、加拉走旧货）需要一个时长、配送小组技能和一份检查清单。用选项列表还是对象？
用对象。它的信息不止一列，由业务方管理，而且按自己的节奏变化。配送的状态是一份短小稳定的标签列表，保持为选项列表。重读查找关系还是选项列表？。
6. 合作伙伴想要一份按区域统计的准时率记分卡，而区域存在配送中心上。你把区域复制到了每次配送上。你必须决定什么？
谁拥有真相，副本如何保持同步，以及旧的配送应该保留它们发生时为真的区域，还是在配送中心划到别的区域时跟着变。反规范化转移了复杂度，并没有消除它。重读有时报表胜出。
7. 像坐下这样的技能可能会关联几十万只宠物。从宠物技能到技能，用主从关系还是查找关系？
用查找关系。Salesforce 的建议是单个父记录下不超过 10,000 条子记录，而一项热门技能会超过这个数。主从关系适合从宠物技能到宠物，因为一只宠物的技能永远不会更换父记录，而且一只宠物只会少数几项技能；也正是主从关系让宠物能汇总它的已会技能数。重读坐下、别动、建模。
- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab)，Salesforce Help（英文，查阅日期 2026-09-25）：官方的考试目标清单及其权重。预约考试前，务必查看最新版本。