把模型落到 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)
第 6 个模块，共 6 个，属于 Data Architect 课程第 2 章为含义建模数据。每个模块都可以单独阅读。 上一篇：设计到第三范式，然后适度回退 · 下一篇：本章学习指南，然后是下一章：Salesforce 数据架构
**本模块回答的问题：**一个逻辑数据模型如何变成一个物理的 Salesforce 数据模型？
我们终于要谈 Salesforce 了。如果你一直在忍着不把每个方框都变成对象，现在可以了。但请注意我们是按什么顺序走过来的：我们理解了业务，描述了数据，把每个事实放在该放的地方，并决定了在哪里有意变通。直到现在，我才问 **Salesforce 应该如何实现它。**这就是我希望你记住的推进过程：**概念 → 逻辑 → 物理。**概念模型描述业务。逻辑模型描述数据。物理模型描述我们实际上要如何构建它。
坐下、别动、建模
Section titled “坐下、别动、建模 ”物理建模这一步，在小东西上最容易看清，所以先从宠物开始。
谁是企业，谁是人？繁育者是一家企业，所以它成为一个客户（Account），记录类型为 Breeder。主人也是一个客户，或者是个人客户，记录类型为 Owner。同一个标准对象的两种类型，并排位于图的顶部，正是它们从模块 1 起一直所在的位置。
什么没有标准的归宿？宠物、品种、技能、宠物技能（Pet Trick）和技能评估成为自定义对象。还记得我们在模块 5 复制到宠物上的物种吗？它在这里有了用处：它成为宠物的记录类型，Dog 或 Cat。一个对象带两个记录类型，各有自己的页面布局和选项列表值，而不是一个狗对象加一个猫对象。
哪些关系是主从关系？我只在子记录永远不会更换父记录时才用主从关系。一条宠物技能终生属于它的宠物，而每条技能评估属于它的宠物技能，所以两者都是主从关系。这马上就有回报：正是主从关系让宠物能对它的宠物技能做汇总，这样模块 5 的已会技能数就能自动保持同步。不过宠物是会换主人的，所以主人用的是查找关系。
哪些是查找关系？Salesforce 不建议单个父记录下有超过 10,000 条子记录。像坐下这样热门的技能、一个常见品种或一家大型繁育者，很容易就超过这个数，所以宠物技能用查找关系指向它的技能，宠物也用同样的方式指向它的品种和繁育者。还有，尽可能避免多态关系，也就是一个字段可以指向多种对象类型的那种。它们在第一天很方便，但对之后所有需要读取它们的东西都更难：报表、集成，现在还有 agent。
**什么留在平台之外？**如果宠物戴着一个会报告位置的 GPS 项圈，这个位置根本不需要复制进来。它可以是一个外部对象，从项圈的追踪系统实时读取。
那张图上的每一个决定，都能追溯到我们之前做过的某个决定，这正是重点所在。现在对 Steve Trucking 做同样的一步。
从逻辑模型开始
Section titled “从逻辑模型开始 ”我们的 Steve Trucking 逻辑模型现在包含零售合作伙伴、配送中心、装货清单、配送、配送项目、收货人、路线、停靠点、配送小组、卡车和配送小组分配。这些是业务概念，现在我可以开始把它们映射到 Salesforce 了。
零售合作伙伴可能是一个客户（Account）。配送可能映射到 Salesforce 中已有的、用于现场排期工作的某样东西，也可能成为一个自定义对象。装货清单没有合适的标准对象，所以很可能成为自定义对象。而收货人是一个真正的难题：个人客户、联系人，还是干脆只是配送上的信息？我们会在下一章好好回答这个问题。
重要的词仍然是可能。不要因为一个业务概念听起来像某个 Salesforce 对象，就认定它的实现。这就是我们先构建逻辑模型的原因：它给了我们一个用来检验 Salesforce 设计的参照。
一个业务实体并不自动意味着一个自定义对象
Section titled “一个业务实体并不自动意味着一个自定义对象 ”有一个陷阱我希望管理员避开：“我们识别出了十一个实体，所以需要十一个自定义对象。”不对。一个逻辑实体告诉我们这个业务概念很重要。它并不规定 Salesforce 必须如何存储它。一个概念可能成为一个标准对象、一个自定义对象、对象之间的一个关系、一个或几个字段、一个在配置中管理的值，或者完全存在于 Salesforce 之外的数据（Steve Trucking 的配送照片就是这方面的好候选）。这些选择是在物理模型中做出的，这也正是我们没有在第一次通话时就做这些选择的原因。
属性变成物理字段
Section titled “属性变成物理字段 ”属性也会经历同样的转变。我们逻辑上的卡车有车辆编号、VIN、品牌、型号、年款、车牌和状态。现在我们来决定它们在物理上如何存在：哪个对象拥有它们，用什么字段类型，哪些必填，哪些必须唯一，哪些是外部标识符，哪些需要验证，哪些是推导出来而不是存储的，哪些是敏感的。在逻辑层面，我们问的是**卡车意味着什么。**在物理层面，我们问的是 **Salesforce 将如何表示卡车。**不同的问题。
关系变成平台层面的决定
Section titled “关系变成平台层面的决定 ”我们在关系上花的所有时间，在这里都有了回报。我们已经知道每个关系是一对一、一对多还是多对多，是必需还是可选，以及它的历史是否重要。现在我们决定 Salesforce 如何实现它：查找关系、主从关系，还是 Salesforce 联接对象（Junction Object），也许是一个带有自己属性的联接对象，因为正如我们发现的，关系本身可以有业务含义。
回想一下配送小组分配。我们本可以在本章一开始就说：“我们在配送小组和卡车之间建一个 Salesforce 联接对象吧。”看看我们会跳过什么：这个关系为什么存在，它是否需要一个日期和一条路线，它是否有状态，几周后的一起货损索赔是否需要它的历史。这些业务问题告诉我们配送小组分配是什么。只有在那之后，我们才应该决定 Salesforce 如何构建它，以及 Salesforce 是否已经有能胜任这项工作的东西。
现在画出物理模型
Section titled “现在画出物理模型 ”图又变了。概念模型展示的是业务概念和简单的连线。逻辑模型加上了属性、键、基数，以及藏在关系里的实体。现在，物理模型开始看起来像 Salesforce 了：标准对象、自定义对象、字段、关系类型，以及放在平台之外的东西。
我希望你能把这三张图并排放在一起，看到其中的推进：不是三张互不相关的图，而是同一个业务在三个层次上的样子。
说一下我是怎么画这些图的，因为布局本身就是信息的一部分。我把主对象放在中间偏下的位置。如果它有父对象，我就把它们放在略高一点的地方，这样你读模型的顺序就是从上到下、从左到右，和业务思考它的方式一致。参考数据放在一边。颜色也有含义：我总是把 Salesforce 画成蓝色，再为公司自己的系统选一种颜色，通常是绿色，因为绿色是一种友好的颜色。我不用红色，黄色也有点刺眼。当一个模型这样布局时，它在我眼里就会唱起歌来。你能找到的很多图其实都是在做空间管理：我怎么把所有车停进我拥挤的车库里？我宁愿画一幅头脑能把握的、有逻辑的图景。
物理模型必须尊重平台
Section titled “物理模型必须尊重平台 ”Salesforce 不是一个通用的关系数据库。它在关系、所有权、安全和报表方面有自己的主张。它有限制、查询行为和自动化，还有一套会影响模型在规模下如何表现的架构。所以一个在白板上看起来完美的逻辑模型，在变成物理模型时可能需要改变。这不是 Salesforce 在碍事，而是说明平台有它自己的形状，好的架构师理解这个形状。下一章讲的正是这个。
有时，物理模型也会因为我们在模块 5 中做出的反规范化决定，而有意不同于干净的逻辑模型。这没问题，只要我们能解释原因。
不要从设置界面开始设计
Section titled “不要从设置界面开始设计 ”有一个习惯，如果你有，我希望你改掉：从设置 → 对象管理器 → 新建自定义对象开始你的数据架构，边做边摸索模型。Salesforce 让创建东西变得极其容易；这是它的优势之一，也是薄弱的数据模型出现得如此之快的原因之一。点几下就有了一个对象，再点几下就有了字段和一个关系。然后数据进来了，Flow 建起来了，报表做出来了，集成依赖上它了，而你五分钟创建的对象改起来就非常昂贵了。这就是第 1 章的可逆性测试。所以在点击新建自定义对象之前，先把模型画出来。
物理不等于永久
Section titled “物理不等于永久 ”我把三个模型分开还有另一个原因：技术会变。今天，Steve Trucking 的一部分数据在 Salesforce 核心平台上。明天，其中一部分可能在 Data 360、某个数据仓库，或者一个我们还没选定的系统里，而 AI 助手需要它自己的表示。物理架构可以变，而业务概念却出奇地稳定：零售合作伙伴、配送和收货人仍然存在。这正是逻辑模型的价值所在。它是对业务的一份持久的描述，不与今天的实现绑定。
架构师在这里决定什么
Section titled “架构师在这里决定什么 ”在把逻辑模型变成物理的 Salesforce 模型时，我要决定的是：
- 哪些业务实体映射到 Salesforce 的标准能力，哪些需要自定义对象或其他表示方式。
- 逻辑属性如何变成物理字段，关系如何在平台上实现。
- 有意的反规范化在物理设计中放在哪里。
- 哪些数据属于 Salesforce，哪些属于别处。
- 平台的哪些特性要求物理模型不同于逻辑模型。
最重要的是，我希望能把每个决定往回追溯。如果你指着我物理模型里的某样东西问**“为什么它在那里？”**，我应该能带你沿着逻辑模型和概念模型一路回溯，找到业务真正需要的某样东西：业务 → 概念 → 逻辑 → 物理。
**考试之外：AI 改变了什么。**AI 现在可以一步就把一份需求文档变成 Salesforce 的对象和字段。这让这个顺序变得更重要，而不是更不重要：如果它从需求直接跳到了配置，就让它展示中间发生了什么：它把什么认定为实体，选了哪些键，假定了哪些关系，在哪里做了反规范化。这些都是架构决定，架构师仍然需要看到它们。
本章我们从第一次通话、聆听名词开始，以一个能追溯回业务的物理模型结束。既然我们已经选择在 Salesforce 上构建，下一个问题会更深入：我们实际上是在一个什么样的数据平台上构建？
- Designing Record Access for Enterprise Scale: Parent-Child Data Skew (opens in a new tab)，Salesforce Developers，Winter ‘27（英文，查阅日期 2026-10-02）：“父子关系中，一条父记录下的子记录不要超过 10,000 条。”这是关于数据倾斜的指导原则，不是硬性限制；第 7 章会更深入。
- Roll-Up Summary Field (opens in a new tab)，Salesforce Help（英文，查阅日期 2026-10-12）：汇总字段通过主从关系对从记录进行计数或求和。