Salesforce 数据架构
另有 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 课程第 3 章的学习指南。请先阅读十个模块；这一页帮你检查自己记住了什么。
**关于本学习指南。**它只依据本课程自己的内容，以及 Salesforce 公开发布的考试指南中的目标清单编写。它从不基于真实的考试题目，也不声称知道考试会考什么。如果你参加过考试，请不要把考题发给我：认证协议禁止分享考题，而且死记答案本来就不是成为架构师的正确方式。
这是模型与平台相遇的一章，承载了考试的很大一部分。它同时支撑考试中最大的两个部分：“数据建模与数据库设计”和“Salesforce 数据管理”，各占考试的四分之一。平台的数字会变：清单里给出的是各模块所引用的数字，并注明了查阅日期。要了解每项限制的用途，并在依赖它之前查看当前的数字。
边学边打勾。每一条都链接到讲授它的地方。
DM-1：在平台上设计数据模型
- 我知道 Salesforce 是一个元数据驱动的多租户平台：对象是元数据，而不是一张新表，而且每个对象一存在就有了它的 API。（元数据就是蓝图，你的 API 随对象一起到来）
- 我知道调控器限制的存在，是为了让一个租户不能霸占共享资源。（你不能霸占电梯）
- 我能读懂标准数据模型：潜在客户转换为客户、联系人和业务机会；业务机会产品指向一个价格手册条目，价格手册条目再指向 Product2；服务一侧则有个案、资产和权利（Entitlement）。（Sales 模型，Service 模型）
- 我知道 New Custom Object（新建自定义对象）界面决定了什么：记录名称用文本还是自动编号；Object Classification（对象分类）（开启共享、Bulk API 和 Streaming API，就是 Enterprise Application 对象；关闭它们，就是 Light Application 对象）；以及 Allow Search（允许搜索），默认关闭。（New Custom Object 界面）
- 我能读懂 API 名称：标准对象和字段没有前缀或后缀；自定义对象和字段以
__c结尾；托管软件包会加上它的命名空间前缀（abc__）；而你在软件包的对象上添加的字段会带__c，但绝不会带供应商的前缀。（前缀和后缀） - 我能对标准对象运用干净契合测试，也知道什么时候含义或分量指向自定义对象。（干净契合测试）
- 我知道资产和个人客户的用途，知道一个个人客户占用的存储大约是企业客户的两倍，也知道个人客户一旦启用就无法停用。（资产是个好例子，个人客户，个人客户：这个人什么时候就是客户？）
- 我按需要的行为来选择字段类型（车队编号不是数字），也知道日期/时间以 GMT 存储，并按每个读者的时区显示，所以要用范围来比较，而不是用等于。（数字不一定是数字，日期、日期/时间和时间）
- 我知道文本有两类：记录上最多 255 个字符的文本（可建索引，可用作唯一值或外部 ID），以及超过这个长度的长文本或富文本，它们没有索引，不能用
WHERE筛选，也不能用在公式里。（文本家族） - 我知道什么时候用自动编号作为 Name，也知道它不是记录的 ID。（需要人来识别它吗？）
- 我知道外部 ID 如何让集成做 upsert，以及如何通过父记录的外部 ID 加载子记录。（外部 ID）
- 我知道一个值什么时候应该由公式推导，什么时候它是必须存储的历史事实。（存储还是推导？）
- 我知道逻辑联接对象（建模概念：一个在多对多关系中连接另外两个对象、并带有自己属性的对象）和 Salesforce 联接对象（Junction Object）（一个有两个主从关系的自定义对象）之间的区别，也知道 Salesforce 说的是后者。（宽两个父对象）
- 我知道层级关系（Hierarchical）：一种只存在于用户对象上的特殊查找关系，例如标准的 Manager 字段，它不能直接或间接地绕回同一个用户，而且它不是角色层级。（层级关系）
- 我知道查找关系和主从关系的区别：所有权、共享、必需的父记录、级联删除、汇总字段。（查找关系，主从关系）
- 我知道不能在一个已经有数据的对象上创建主从关系（先创建查找关系，填好值，再转换），只有当主记录上没有汇总字段时才能改回查找关系，而移动子记录需要允许重设父级。（子记录能更换父记录吗？）
- 我知道主从关系在平台上的形状：最深三层自定义从对象（查找关系可以在任何地方断开这条链），最宽两个主从关系父对象。在 Salesforce 联接对象中，先创建的主从关系是主要父对象（决定所有者、外观和部门），第二个是次要父对象，而访问需要两个父对象都满足：最严格的那个说了算。（深三层，宽两个父对象）
- 我知道父记录被删除时，查找关系的三种选择：清空字段（默认）、阻止删除，或者级联删除；级联删除在 Salesforce 启用之前是关闭的，而且会绕过共享。（查找关系）
- 我知道自关系必须是查找关系，也知道内置的两个：客户的上级客户（Parent Account）和个案的父个案（Parent Case）。（自关系）
- 我知道汇总字段的重新计算可能需要时间，知道汇总字段不能使用带有
NOW()、TODAY()或跨对象引用的公式，也知道不要只为了得到汇总字段就选择主从关系：替代方案是一个由 Flow 或触发器保持最新的存储字段。（汇总字段很有用，但不是免费的） - 我知道模块中引用的关系限制：每个对象两个主从关系；默认 40 个关系字段（最多 50 个）；默认 25 个汇总字段（最多 40 个）。（关系也有限制）
DM-2：尊重共享并能扩展的模型
- 我知道主从关系中的子记录没有自己的所有者，也没有自己的共享表：访问权限跟随主记录。（所有权会随之而来）
- 我知道父子数据倾斜：Salesforce 的建议是单个父记录下的子记录不超过大约 10,000 条。（一万条子记录的问题）
- 我知道所有权数据倾斜（一个用户拥有某个对象超过 10,000 条记录）以及相关建议：分散所有权，或者让这个用户不在角色层级中、或单独位于顶部，并且不进入共享规则所用的公用组。（所有权可能变成规模问题）
- 我了解共享表：自定义对象的共享对象是
Object__Share；从对象没有共享对象，它的访问权限来自主记录；而更换所有者会删除手动共享，但会保留带有自己原因的 Apex 共享。（共享表） - 我能根据所有权是否决定共享，来决定集成和智能体创建的记录归谁所有。（系统创建的记录归谁所有？）
DM-4：大对象与标准对象和自定义对象的比较
- 我知道数据的三个归宿：核心之上（sObject，每天都在用）、引用的（另一个系统是真相的来源：Salesforce Connect 的外部对象
__x，或自定义调用），以及归档的（核心之上的大对象__b，或核心之外的数据仓库）。（核心之上与核心之外） - 我知道外部对象每次被访问都会发起一次外部调用，所以延迟和源系统的可用性很重要。（引用）
- 我了解大对象：海量数据，通过索引按精确匹配或范围查询，没有标准界面或报表，只有对象和字段权限，没有自动化。（归档）
- 我知道大多数记录不管有多少字段，都按大约 2 KB 的数据存储计算，而文件在文件存储中单独计量。（两列还是两百列，文件与附件）
SDM-1：许可以及人们能使用的对象
- 我知道三种内部许可：Sales Cloud、Service Cloud 和 Platform，以及每种许可能使用什么。（三种内部许可）
- 我知道许可是数据模型的一部分：Salesforce Platform 用户不能使用潜在客户、市场活动、业务机会或预测，Customer Community 用户不能使用业务机会。（现在让我把一切都复杂化：许可）
- 我知道外部许可的等级：Customer Community、Customer Community Plus（报表、仪表板、标准共享）、Partner Community（销售对象）；也知道 Partner Community 不能与个人客户一起使用。（体育场）
- 我知道按成员计费与按登录计费的许可方式，以及各自适合哪类人群。（付费方式会改变设计）
- 我知道有些平台许可把用户限制在一个应用、最多十个自定义对象，也知道在此限制下工作的记录类型模式。（当许可塑造模型时）
- 我知道 Salesforce Integration 许可是给系统间的、只用 API 的用户的。（用户不再只是人）
- 我知道 SLA 报表需要权利和里程碑，而它们需要 Service 许可。（现在让我把一切都复杂化：许可）
SDM-2：保持数据一致
- 我能把一条规则放到一致性阶梯的正确一级上：字段类型和词汇、必填和唯一、验证规则、重复规则、自动化。（保持数据一致）
- 我知道受限选项列表会拒绝不在列表上的值，即使是通过 API；而全局值集让多个字段共用一份列表（最多 1,000 个值）。（第一级）
- 我知道页面布局上的必填要求只保护那个界面，而不是数据，而验证规则在每次保存时都会运行。（界面验证不等于数据验证，第三级）
- 我能用 ISNEW() 和 ISCHANGED()、一个自定义权限或一个上线日期来限定验证规则的范围，并且知道每种选择仍然会检查哪些保存（包括我控制不了的保存，比如批量更换所有者或汇总字段的更新）。（旧记录问题）
- 我了解匹配规则和重复规则、模块中引用的限制（每个对象五条有效的重复规则，每条三条匹配规则），也知道它们解决不了跨系统的身份问题。（第四级：重复规则）
- 我知道重复规则不会比较同一时刻保存的记录，知道通过 API 和导入的保存会被直接阻止，没有提醒，也知道一次保存以及它引发的一切作为一个事务一起回滚。（第四级，全有或全无）
- 我知道工作流规则和 Process Builder 已不再受支持；自动化意味着 Flow 或 Apex。（第五级：自动化）
考试是底线，不是天花板。下面这些是本章中架构师需要的习惯，不管有没有考题问到它们。
- **平台有它的形状。**为你所在的平台做设计，而不是为一个通用数据库。
- **看向母舰。**在发明一个概念之前，先看看 Salesforce 是如何为它建模的。
- **每个对象都是一份承诺：**存储、限制、共享模型、许可和依赖。
- 在选择对象之前，先问数据放在哪里：核心之上、引用还是归档。
- **读懂任何一个 API 名称，你就知道它是谁做的，**以及你能改什么。
- 如果你今天不归档，你还会有归档的那一天吗？
- 在建议使用大对象之前，先做个原型。
- 不同的业务名称并不自动意味着不同的对象。
- **问一问哪些身份需要这些数据：**人、客户、合作伙伴、集成和智能体。
- **每个字段都要有描述，**在重要的地方还要有分类。
- **先描述关系的行为；**配置只是去实现它。不要为了得到一个功能而扭曲模型。
- **删除问题：**如果有人删除了父记录，子记录应该怎样？
- **选择由哪一环断开这条链：**在子记录真正有自己生命的地方使用查找关系。
- **所有权来自主要父对象，访问来自两个父对象：**最严格的那个说了算。
- **把不活跃和消失分开，**让保留成为一条业务规则。
- **把规则放到它正确所属的最低一层，**并给合法的历史数据一个绕过机制，而不是改写它。
- **图不等于架构。**要能把每个结构追溯到一个业务理由。
| 术语 | 一句话解释 |
|---|---|
| 元数据驱动 | 对象和字段是平台在运行时读取的定义，而不是新的物理表 |
| 多租户 | 许多 org 共享基础设施，彼此隔离，就像一栋楼里的公寓 |
| 调控器限制 | 防止一个租户独占共享资源的限制 |
| 外部对象 | 通过 Salesforce Connect 在 Salesforce 中显示的数据，每次访问都从来源获取 |
| 大对象 | 用于存放极大量、很少使用的数据的存储，通过索引查询 |
| 个人客户 | 把一个个人表示为一个客户，用于企业对消费者的模式 |
| 干净契合 | 与某个标准对象的本来用途相吻合的业务概念 |
| 外部 ID | 存放另一个系统标识符的字段，用于 upsert 和匹配 |
| Upsert（更新插入） | 记录存在就更新，不存在就创建 |
| 查找关系 | 子记录保留自己的所有人和生命的关系 |
| 主从关系 | 子记录属于父记录的关系：继承所有人和共享，级联删除，汇总字段 |
| 逻辑联接对象 | 建模概念：一个在多对多关系中连接另外两个对象、并带有自己属性的对象，无论它是如何构建的 |
| Salesforce 联接对象（Junction Object） | Salesforce 所说的“联接对象”：一个有两个主从关系的自定义对象 |
| 主要主对象和次要主对象 | Salesforce 联接对象上先创建的主从关系（决定所有者、外观和部门）和第二个主从关系（决定报表范围；如果第一个被移除，它就成为主要的） |
| 层级关系 | 一种只存在于用户对象上的特殊查找关系，例如 Manager，不能绕回同一个用户 |
| 命名空间前缀 | 供应商在托管软件包的对象和字段上加的前缀，例如 abc__Inspection__c |
| 共享表 | 存放一条记录大部分共享信息的共享对象（AccountShare、Truck__Share），每个用户或组一行，并带有原因 |
| 汇总字段 | 主记录上对其从记录计数、求和或求最小值、最大值的字段 |
| 数据倾斜 | 一个父记录或一个所有人名下的记录太多，导致锁定和长时间的共享重新计算 |
| 按成员计费 / 按登录计费 | 按外部用户付费，或按每月的登录次数付费 |
| 一致性阶梯 | 执行数据规则的各个层，从字段类型一直到自动化 |
| 受限选项列表 | 无论来自哪里，都拒绝不在列表上的值的选项列表 |
| 数据分类 | 关于所有者、用途、敏感性和合规类别的字段元数据 |
按课程风格编写的简短情景题。打开答案之前，先想好你的答案。
1. 用户需要查看由 ERP 拥有并整天更新的订单详情。他们不在 Salesforce 中编辑这些数据。要复制进来吗？
引用它们：通过 Salesforce Connect 使用外部对象，让 ERP 继续作为真相的来源，不需要同步任何副本。要接受每次查看都会发起一次外部调用，所以延迟和 ERP 的可用性很重要，而且它更适合读取访问，而不是大量编辑或报表。重读引用。
2. 业务方想跟踪经销商、供应商和零售合作伙伴。建三个自定义对象吗？
不。它们都是公司，所以客户是干净契合的；不同的名字是角色，由一个类型、一个记录类型或一个关系来承载。重读干净契合测试。
3. 一个设计用了业务机会，但需要这些数据的大多数人用的是 Salesforce Platform 或 Customer Community 许可。现在怎么办？
这些许可不能使用业务机会，所以许可是一个架构约束：购买不同的许可，把体验挪个地方，或者重新设计，通常是转向自定义对象。重读现在让我把一切都复杂化：许可。
4. ERP 每晚向客户发送更新。集成应该如何在不查询 Salesforce ID 的情况下找到正确的记录？
把 ERP 的客户编号存在一个外部 ID 字段里，基于它做 upsert：找到就更新，找不到就创建。子记录也可以通过父记录的外部 ID 来指向它。重读外部 ID。
5. 配送项目不能脱离它的配送而存在，从不移动，也不需要自己的所有人。配送在排上路线之前就存在，并且可以移到另一条路线上。各用什么关系？
配送项目到配送：主从关系（它终生属于父记录，继承访问权限，删除时级联）。配送到路线：查找关系（有自己的生命，一开始是可选的，可以移动，而删除路线绝不能删除配送）。重读从业务关系开始。
6. 一个集成每天创建 3,300 次配送，全部归集成用户所有，而这个用户在层级中间有一个角色。风险是什么，怎么修？
所有权数据倾斜：超过 10,000 条记录后，移动这个用户或改变它的组会触发长时间的共享重新计算。如果所有权对访问很重要，就分散所有权；否则就让集成用户不在角色层级中，或者单独位于顶部的一个角色里，并且不进入共享规则所用的组。重读所有权可能变成规模问题。
7. 你加了一条验证规则，有 20,000 条旧记录违反了它。一个用户在其中一条上编辑了电话号码，保存失败了。这条规则本该怎么做？
不仅说明什么必须为真，还要说明什么时候执行：用相关字段上的 ISNEW() 或 ISCHANGED() 来限定它的范围，并给在这条规则之前就存在的记录一个有意的绕过机制，而不是改写它们的历史。重读旧记录问题。
8. 业务方希望每张配送照片都“放在 Salesforce 里”：每年四五百万张，每年增长 30%。你会提出什么方案？
把访问和存储分开。把文件放在为这种数据量而构建的存储中，在核心 org 之外，在 Salesforce 中保留一个引用、一个数量或一条索引记录，让用户能找到并查看它们。重读照片。
9. 一条配送小组分配记录（Crew Assignment）与配送小组（先创建）和卡车都有主从关系。一个调度员能看到配送小组，但看不到卡车。他能看到这条配送小组分配记录吗？
不能。配送小组是主要父对象，所以它决定了这条分配记录的所有者和外观，但访问需要两个父对象都满足：调度员需要同时有配送小组和卡车的访问权限，并且达到每个主从关系字段的共享设置（Sharing Setting）所要求的级别。最严格的那个说了算。重读宽两个父对象。
10. 一个合作伙伴重发了一份装货清单文件，同一个客户在其中出现了两次。你在客户上有一条设为阻止的重复规则。你安全了吗？
仅靠重复规则是不够的。同一时刻保存的记录不会彼此比较，只会和 Salesforce 中已有的记录比较，所以两行都可能通过。把唯一性下推到字段上：一个唯一的外部 ID，平台在每次保存时都会检查它，所以只有一条能成功。重读第四级：重复规则和全有或全无。
- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab)，Salesforce Help（英文，查阅日期 2026-09-25）：官方的考试目标清单及其权重。预约考试前，务必查看最新版本。
- 每个模块自己的“延伸探索”部分列出了其平台事实所依据的 Salesforce 文档，并注明了查阅日期。