Архитектура данных 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)

Изображение создано с помощью ИИ

Переведено ИИ. Сообщество еще не проверило перевод. Читать на английском

Учебное пособие к главе 3 курса Data Architect. Сначала прочитайте десять модулей; эта страница поможет проверить, что запомнилось.

Об этом учебном пособии. Оно построено только на материалах этого курса и на списке целей из опубликованного руководства Salesforce по экзамену. Оно никогда не основано на реальных экзаменационных вопросах и не претендует на знание того, что будет на экзамене. Если вы сдавали экзамен, пожалуйста, не присылайте мне вопросы из него: соглашение о сертификации запрещает ими делиться, а заучивание ответов — все равно неправильный путь к тому, чтобы стать архитектором.

Это глава, где модель встречается с платформой, и на нее приходится большая часть экзамена. Она питает оба крупнейших раздела, Data Modeling and Database Design и Salesforce Data Management, по четверти экзамена каждый. Цифры платформы меняются: чек-лист приводит те, на которые ссылаются модули, с датой проверки. Выучите, для чего нужен каждый лимит, и проверяйте актуальное значение, прежде чем на него полагаться.

Для экзамена

Отмечайте пункты по ходу. Каждый ведет туда, где эта тема разбирается.

DM-1: проектирование модели данных на платформе

• Я знаю, что Salesforce — управляемая метаданными мультитенантная платформа: объект — это метаданные, а не новая таблица, и каждый объект получает свои API в момент появления. (Метаданные — это чертеж, API пришел вместе с объектом)
• Я знаю, что governor limits (лимиты платформы) существуют, чтобы один арендатор не мог захватить общие ресурсы. (Лифт нельзя занять целиком)
• Я умею читать стандартные модели данных: преобразование интереса (Lead) в организацию (Account), контакт и возможность (Opportunity); продукт возможности указывает на запись прайс-листа (Price Book Entry), которая указывает на Product2; а на стороне обслуживания — обращение (Case), актив (Asset) и право на обслуживание (Entitlement). (Модель продаж, Модель обслуживания)
• Я знаю, что решает экран New Custom Object: имя записи типа Text или Auto Number; Object Classification (с включенными общим доступом, Bulk API и Streaming API это объект Enterprise Application, с выключенными — объект Light Application); и Allow Search, по умолчанию выключенный. (Экран New Custom Object)
• Я умею читать API-имя: у стандартных объектов и полей нет ни префикса, ни суффикса; пользовательские объекты и поля заканчиваются на __c; управляемый пакет добавляет свой префикс пространства имен (abc__); а поле, которое вы добавляете к объекту пакета, получает __c, но никогда — префикс поставщика. (Префиксы и суффиксы)
• Я умею применять тест на чистое соответствие для стандартного объекта и знаю, когда смысл или вес указывают на пользовательский объект. (Тест на чистое соответствие)
• Я знаю, для чего нужны актив (Asset) и персональные учетные записи (Person Account), что персональная учетная запись занимает примерно вдвое больше места, чем бизнес-организация, и что после включения персональные учетные записи нельзя отключить. (Актив — хороший пример, Персональные учетные записи, Когда человек — это организация?)
• Я выбираю тип поля под нужное мне поведение (номер в автопарке — это не Number) и знаю, что дата и время хранятся в GMT и показываются в часовом поясе каждого читателя, поэтому их сравнивают диапазонами, а не равенством. (Число — не всегда число, Date, Date/Time и Time)
• Я знаю, что текст бывает двух видов: до 255 символов в записи (индексируемый, может быть уникальным или External ID) и Long или Rich text сверх этого, без индекса, без фильтрации в WHERE и без формул. (Семейство текстовых полей)
• Я знаю, когда использовать Name типа auto number, и что это не ID записи. (Нужно ли человеку это опознавать?)
• Я знаю, как External ID позволяет интеграции делать upsert и загружать дочерние записи по External ID их родителя. (External ID)
• Я знаю, когда значение должно вычисляться формулой, а когда это исторический факт, который нужно хранить. (Хранить или вычислять?)
• Я знаю разницу между логическим связующим объектом (идея моделирования: объект, который соединяет два других в связи «многие ко многим» и имеет собственные атрибуты) и связующим объектом Salesforce (Salesforce Junction Object) (пользовательский объект с двумя связями master-detail), и что Salesforce имеет в виду второе. (Два родителя вширь)
• Я знаю иерархическую связь: особый lookup только на объекте User, как стандартное поле Manager, который не может прямо или косвенно замкнуться на того же пользователя и не является иерархией ролей. (Иерархическая)
• Я знаю разницу между lookup и master-detail: владение, общий доступ, обязательный родитель, каскадное удаление, поля сводки. (Lookup, Master-detail)
• Я знаю, что master-detail нельзя создать на объекте, где уже есть данные (создайте lookup, заполните его, преобразуйте), что вернуться к lookup можно, только если на мастере нет полей сводки, и что для перемещения дочерней записи нужен Allow reparenting. (Может ли дочерняя запись сменить родителя?)
• Я знаю форму master-detail на платформе: до трех пользовательских уровней детализации вглубь (lookup может разорвать цепочку в любом месте) и два родителя master-detail вширь. В связующем объекте Salesforce созданная первой связь master-detail — основная (владелец, внешний вид, подразделение), вторая — вторичная, и для доступа нужны оба родителя: побеждает самый строгий. (Три уровня вглубь, Два родителя вширь)
• Я знаю три варианта lookup на случай удаления родителя: очистить поле (по умолчанию), запретить удаление или каскадное удаление, которое выключено, пока его не включит Salesforce, и которое обходит общий доступ. (Lookup)
• Я знаю, что самосвязь должна быть lookup, и две встроенные: Parent Account у организации и Parent Case у обращения. (Самосвязи)
• Я знаю, что пересчет полей сводки может занять время, что поле сводки не может использовать формулу с NOW(), TODAY() или межобъектной ссылкой, и что не нужно выбирать master-detail только ради поля сводки: альтернатива — хранимое поле, которое поддерживает в актуальном состоянии flow или триггер. (Roll-up полезны, но не бесплатны)
• Я знаю лимиты связей, которые приводит модуль: две связи master-detail на объект; 40 полей связей по умолчанию (максимум 50); 25 полей сводки по умолчанию (максимум 40). (У связей тоже есть лимиты)

DM-2: модель, которая учитывает общий доступ и масштабируется

• Я знаю, что у дочерней записи master-detail нет собственного владельца и таблицы общего доступа: доступ следует за мастером. (Владение едет в комплекте)
• Я знаю перекос «родитель — потомок» (parent-child skew): рекомендация Salesforce — не больше примерно 10 000 дочерних записей на одного родителя. (Вопрос 10 000 дочерних записей)
• Я знаю перекос владения (ownership skew: один пользователь владеет больше чем 10 000 записями объекта) и рекомендации: распределяйте владение или держите этого пользователя вне иерархии ролей либо одного на самом верху, и вне публичных групп, которые используют правила общего доступа. (Владение может стать проблемой масштаба)
• Я знаю таблицу общего доступа: объект общего доступа пользовательского объекта — Object__Share; у объекта детализации его нет, доступ приходит от мастера; а смена владельца удаляет ручной общий доступ, но сохраняет общий доступ Apex с собственной причиной. (Таблица общего доступа)
• Я могу решить, кто владеет записями, которые создают интеграции и агенты, исходя из того, определяет ли владение общий доступ. (Кто владеет записями, которые создают системы?)

DM-4: big objects в сравнении со стандартными и пользовательскими объектами

• Я знаю три дома для данных: в ядре (sObjects, ежедневная работа), по ссылке (источник истины — другая система: внешние объекты Salesforce Connect, __x, или собственные вызовы) и в архиве (в ядре в big objects, __b, или вне ядра в хранилище данных). (В ядре и вне ядра)
• Я знаю, что внешние объекты делают вызов каждый раз, когда к ним обращаются, поэтому важны задержка и доступность системы-источника. (По ссылке)
• Я знаю big objects: огромные объемы, запросы через их индекс по точному совпадению или диапазону, нет стандартного интерфейса и отчетности, только разрешения на объект и поля, нет автоматизации. (В архиве)
• Я знаю, что большинство записей занимают около 2 КБ хранилища данных независимо от числа полей и что файлы учитываются отдельно, в хранилище файлов. (Два столбца или двести, Файлы и вложения)

SDM-1: лицензии и объекты, которыми могут пользоваться люди

• Я знаю три внутренние лицензии, Sales Cloud, Service Cloud и Platform, и чем может пользоваться каждая. (Три внутренние лицензии)
• Я знаю, что лицензии — часть модели данных: пользователи Salesforce Platform не получают интересы (Leads), кампании, возможности и прогнозы, а пользователи Customer Community не могут работать с возможностями. (А теперь я все усложню: лицензирование)
• Я знаю уровни внешних лицензий: Customer Community, Customer Community Plus (отчеты, панели мониторинга, стандартный общий доступ), Partner Community (объекты продаж); и что Partner Community нельзя использовать с персональными учетными записями. (Стадион)
• Я знаю лицензирование по участникам (member-based) и по входам (login-based) и для какой аудитории подходит каждое. (То, как они платят, меняет дизайн)
• Я знаю, что некоторые лицензии платформы ограничивают пользователей одним приложением до десяти пользовательских объектов, и знаю шаблон с типами записей, позволяющий работать в этих рамках. (Когда лицензия формирует модель)
• Я знаю, что лицензия Salesforce Integration предназначена для пользователей, работающих только через API, для связи «система — система». (Пользователи — теперь не только люди)
• Я знаю, что для отчетности по SLA нужны права на обслуживание и вехи (entitlements and milestones), а для них нужны лицензии Service. (А теперь я все усложню: лицензирование)

SDM-2: поддержание согласованности данных

• Я умею поместить правило на правильную ступень лестницы согласованности: тип поля и словарь, обязательность и уникальность, правила проверки, правила дубликатов, автоматизация. (Поддержание согласованности данных)
• Я знаю, что ограниченный список выбора отклоняет значения, которых нет в списке, даже через API, а глобальный набор значений делится одним списком между полями (до 1 000 значений). (Ступень первая: тип поля и словарь)
• Я знаю, что обязательность на уровне макета страницы защищает только этот экран, а не данные, и что правила проверки выполняются при каждом сохранении. (Проверка в интерфейсе — не проверка данных, Ступень третья: правила проверки)
• Я умею ограничить правило проверки с помощью ISNEW() и ISCHANGED(), пользовательского разрешения или даты запуска, понимая, какие сохранения (включая те, которые я не контролирую, например пакетную смену владельца или пересчет поля сводки) каждый вариант все равно проверяет. (Проблема старых записей)
• Я знаю правила сопоставления и правила дубликатов, лимиты, которые приводит модуль (пять активных правил дубликатов на объект, по три правила сопоставления в каждом), и что они не решают идентификацию между системами. (Ступень четвертая: правила дубликатов)
• Я знаю, что правила дубликатов не сравнивают записи, сохраненные в один и тот же момент, что сохранения через API и импорт блокируются без предупреждения и что сохранение и все, что оно запускает, откатываются как одна транзакция. (Ступень четвертая: правила дубликатов, Все или ничего)
• Я знаю, что Workflow Rules и Process Builder больше не поддерживаются; автоматизация — это Flow или Apex. (Ступень пятая: автоматизация)

За пределами экзамена

Экзамен — это пол, а не потолок. Вот привычки из этой главы, которые нужны архитектору, независимо от того, спросят ли о них когда-нибудь на экзамене.

• У платформы есть форма. Проектируйте для платформы, на которой вы работаете, а не для абстрактной базы данных.
• Смотрите на корабль-носитель. Посмотрите, как Salesforce моделирует понятие, прежде чем изобретать свое.
• Каждый объект — это обязательство: хранение, лимиты, модель общего доступа, лицензии и зависимости.
• Спросите, где живут данные, прежде чем выбирать объект: в ядре, по ссылке или в архиве.
• Прочитайте любое API-имя — и вы знаете, кто его создал, и что вы можете изменить.
• Если вы не архивируете сегодня, будете ли вы вообще когда-нибудь архивировать?
• Сделайте прототип big objects, прежде чем их предлагать.
• Разные бизнес-названия не означают автоматически разные объекты.
• Спросите, каким удостоверениям нужны данные: людям, клиентам, партнерам, интеграциям и агентам.
• У каждого поля есть описание, а где это важно — и классификация.
• Сначала опишите поведение связи; конфигурация его реализует. Не искажайте модель ради функции.
• Вопрос удаления: что должно произойти с дочерними записями, если кто-то удалит родителя?
• Выберите, какое звено разрывает цепочку: делайте lookup там, где у дочерней записи действительно своя жизнь.
• Владение — от основного родителя, доступ — от обоих: побеждает самый строгий.
• Отделяйте неактивное от исчезнувшего и делайте хранение бизнес-правилом.
• Опускайте правило так низко, как ему правильно место, и давайте законной истории обход, а не переписывайте ее.
• Диаграмма — это не архитектура. Умейте проследить каждую структуру до бизнес-причины.

Ключевые термины

Термин	В одной строке
Управление метаданными (metadata-driven)	Объекты и поля — это определения, которые платформа читает во время выполнения, а не новые физические таблицы
Мультитенантность	Множество org делят инфраструктуру, каждый изолирован, как квартиры в одном доме
Governor limits (лимиты платформы)	Лимиты, которые не дают одному арендатору монополизировать общие ресурсы
Внешний объект	Данные, показанные в Salesforce через Salesforce Connect и получаемые из источника при каждом обращении
Big object	Хранилище для очень больших, редко используемых данных, запросы через индекс
Персональная учетная запись	Человек, представленный как организация, для моделей «бизнес — потребитель»
Чистое соответствие	Бизнес-понятие, которое совпадает с предназначением стандартного объекта
External ID	Поле с идентификатором другой системы, используемое для upsert и сопоставления
Upsert	Обновить запись, если она существует, и создать, если нет
Lookup	Связь, при которой у дочерней записи свой владелец и своя жизнь
Master-detail	Связь, при которой дочерняя запись принадлежит родителю: унаследованные владелец и общий доступ, каскадное удаление, поля сводки
Логический связующий объект	Идея моделирования: объект, который соединяет два других в связи «многие ко многим» и несет собственные атрибуты, как бы он ни был построен
Связующий объект Salesforce (Salesforce Junction Object)	То, что Salesforce называет «junction object»: пользовательский объект с двумя связями master-detail
Основной и вторичный мастер	Созданная первой связь master-detail связующего объекта Salesforce (владелец, внешний вид, подразделение) и вторая (область отчетов; становится основной, если первую удалить)
Иерархическая связь	Особый lookup только на объекте User, как Manager, который не может замкнуться на того же пользователя
Префикс пространства имен	Префикс поставщика на объектах и полях управляемого пакета, например abc__Inspection__c
Таблица общего доступа	Объект общего доступа (AccountShare, Truck__Share), который хранит большую часть общего доступа к записи, по строке на пользователя или группу, с причиной
Поле сводки (roll-up summary)	Поле на мастере, которое считает, суммирует или находит минимум или максимум по его записям детализации
Data skew (перекос данных)	Слишком много записей под одним родителем или одним владельцем, что вызывает блокировки и долгие пересчеты общего доступа
По участникам / по входам	Оплата за каждого внешнего пользователя или за каждый вход в месяц
Лестница согласованности	Уровни, которые обеспечивают правила данных, от типа поля до автоматизации
Ограниченный список выбора	Список выбора, который отклоняет любое значение не из своего списка, из любого источника
Классификация данных	Метаданные поля о владельце, использовании, чувствительности и категории соответствия требованиям

Проверьте себя

Короткие сценарии в стиле курса. Решите, каким будет ваш ответ, прежде чем его открыть.

1. Пользователям нужно видеть данные заказов, которыми владеет ERP и которые она обновляет весь день. В Salesforce их не редактируют. Копировать их или нет?

Ссылайтесь на них: внешние объекты через Salesforce Connect оставляют ERP источником истины, и синхронизировать копию не нужно. Примите, что каждый просмотр делает вызов, поэтому важны задержка и доступность ERP, и что это лучше подходит для чтения, чем для активного редактирования или отчетности. Перечитайте По ссылке.

2. Бизнес хочет отслеживать дистрибьюторов, поставщиков и розничных партнеров. Три пользовательских объекта?

Нет. Все они компании, поэтому организация (Account) подходит с чистым соответствием; разные названия — это роли, которые передаются типом, типом записи или связью. Перечитайте Тест на чистое соответствие.

3. Проект использует возможность (Opportunity), но у большинства тех, кому нужны данные, лицензии Salesforce Platform или Customer Community. Что теперь?

Эти лицензии не дают работать с возможностями, поэтому лицензия — это архитектурное ограничение: купить другие лицензии, перенести интерфейс или перепроектировать, обычно в сторону пользовательского объекта. Перечитайте А теперь я все усложню: лицензирование.

4. ERP каждую ночь присылает обновления организаций. Как интеграции найти нужную запись, не запрашивая ID Salesforce?

Храните номер клиента из ERP в поле External ID и делайте по нему upsert: обновить, если найдено, создать, если нет. Дочерние записи тоже могут указывать на родителя по его External ID. Перечитайте External ID.

5. Позиция доставки не может существовать без своей доставки, никогда не перемещается и не нуждается в собственном владельце. Доставка существует до того, как попадет в маршрут, и может перейти в другой маршрут. Какая связь для каждой?

Позиция доставки с доставкой: master-detail (она принадлежит родителю всю жизнь, наследует доступ, каскадно удаляется). Доставка с маршрутом: lookup (своя жизнь, сначала необязательная, может перемещаться, а удаление маршрута никогда не должно удалять доставки). Перечитайте Начните с бизнес-отношения.

6. Интеграция создает 3 300 доставок в день, и всеми владеет интеграционный пользователь, у которого роль в середине иерархии. Каков риск и как это исправить?

Перекос владения: после 10 000 записей перемещение этого пользователя или изменение его групп запускает долгие пересчеты общего доступа. Распределите владение, если оно важно для доступа; иначе держите интеграционного пользователя вне иерархии ролей или одного в роли на самом верху, и вне групп, которые используют правила общего доступа. Перечитайте Владение может стать проблемой масштаба.

7. Вы добавляете правило проверки, и 20 000 старых записей ему не соответствуют. Пользователь меняет номер телефона в одной из них, и сохранение не проходит. Что должно было сделать правило?

Сказать, когда его применять, а не только что должно быть верно: ограничьте его с помощью ISNEW() или ISCHANGED() на нужных полях и дайте записям, появившимся раньше правила, осознанный обход, а не переписывайте их историю. Перечитайте Проблема старых записей.

8. Бизнес хочет, чтобы каждая фотография доставки была «в Salesforce»: четыре-пять миллионов в год с ростом на 30 процентов. Что вы предложите?

Отделите доступ от хранения. Держите файлы в хранилище, построенном для такого объема, вне org ядра, а в Salesforce храните ссылку, количество или индексную запись, чтобы пользователи могли их найти и увидеть. Перечитайте Фотографии.

9. У назначения бригады (Crew Assignment) есть связи master-detail с бригадой (создана первой) и грузовиком. Диспетчер видит бригаду, но не грузовик. Видит ли диспетчер назначение бригады?

Нет. Бригада — основной родитель, поэтому она дает назначению владельца и внешний вид, но для доступа нужны оба родителя: диспетчеру нужен доступ к бригаде и к грузовику, на уровне, который требует Sharing Setting каждого поля master-detail. Побеждает самый строгий. Перечитайте Два родителя вширь.

10. Партнер повторно присылает файл манифеста, и один и тот же клиент встречается в нем дважды. На организации настроено правило дубликатов с блокировкой. Вы в безопасности?

Не благодаря одному лишь правилу дубликатов. Записи, сохраненные в один и тот же момент, не сравниваются друг с другом, только с записями, которые уже есть в Salesforce, поэтому обе строки могут пройти. Опустите уникальность до уровня поля: уникальный External ID, который платформа проверяет при каждом сохранении, так что победит только одна. Перечитайте Ступень четвертая: правила дубликатов и Все или ничего.

Дополнительно

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (на английском, проверено 2026-09-25): официальный список целей экзамена и их веса. Всегда проверяйте актуальную версию, прежде чем записываться на экзамен.
• В разделе «Дополнительно» каждого модуля перечислена документация Salesforce, на которой основаны его факты о платформе, с датой проверки.