Архітектура даних 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 існують, щоб один тенант не міг захопити спільні ресурси. (Ви не можете захопити ліфт)
• Я вмію читати стандартні моделі даних: конвертація ліда в Account, Contact і Opportunity; Opportunity Product вказує на Price Book Entry, який вказує на Product2; а на боці обслуговування — Case, Asset і Entitlement. (Модель Sales, Модель Service)
• Я знаю, що вирішує екран New Custom Object: назва запису Text чи Auto Number; Object Classification (з увімкненими sharing, Bulk API і Streaming API це об’єкт Enterprise Application, з вимкненими — Light Application); і Allow Search, вимкнений за замовчуванням. (Екран New Custom Object)
• Я вмію читати API-назву: стандартні об’єкти й поля не мають ні префікса, ні суфікса; користувацькі об’єкти й поля закінчуються на __c; керований пакет додає свій префікс простору імен (abc__); а поле, яке ви додаєте до об’єкта пакета, отримує __c, але ніколи не префікс постачальника. (Префікси й суфікси)
• Я вмію застосовувати тест чистої відповідності для стандартного об’єкта і знаю, коли зміст чи вага вказують на користувацький об’єкт. (Тест чистої відповідності)
• Я знаю, для чого існують Asset і персональні акаунти, що персональний акаунт займає приблизно вдвічі більше сховища, ніж бізнес-акаунт, і що після ввімкнення персональні акаунти не можна вимкнути. (Asset — добрий приклад, Персональні акаунти, Коли людина — це акаунт?)
• Я обираю тип поля за потрібною поведінкою (парковий номер — не Number) і знаю, що дата й час зберігаються в GMT і показуються в часовому поясі кожного читача, тож їх порівнюють діапазонами, а не рівністю. (Число — не завжди число, Date, Date/Time і Time)
• Я знаю, що текст буває двох видів: до 255 символів у записі (індексується, може бути унікальним чи External ID) і Long чи Rich text понад це — без індексу, без фільтрації WHERE і без формул. (Сімейство текстових полів)
• Я знаю, коли використовувати автонумерацію для Name, і що це не ID запису. (Чи має людина її впізнавати?)
• Я знаю, як External ID дає інтеграції змогу виконувати upsert і завантажувати дочірні записи за External ID батьківського. (External ID)
• Я знаю, коли значення слід обчислювати формулою, а коли це історичний факт, який треба зберігати. (Зберігати чи обчислювати?)
• Я знаю різницю між логічним об’єктом-з’єднувачем (ідея моделювання: об’єкт, що поєднує два інші у зв’язку «багато до багатьох», із власними атрибутами) і об’єктом-з’єднувачем Salesforce (користувацький об’єкт із двома зв’язками master-detail), і що Salesforce має на увазі другий. (Два батьківські вшир)
• Я знаю ієрархічний зв’язок: особливий lookup лише в об’єкті User, як стандартне поле Manager, що не може замкнутися на того самого користувача ні прямо, ні опосередковано, і це не ієрархія ролей. (Ієрархічний)
• Я знаю різницю між lookup і master-detail: власність, спільний доступ, обов’язковий батьківський запис, каскадне видалення, зведені поля. (Lookup, Master-detail)
• Я знаю, що master-detail не можна створити на об’єкті, у якому вже є дані (створіть lookup, заповніть, конвертуйте), повернути до lookup можна лише без зведених полів на master, а щоб перенести дочірній запис, потрібен Allow reparenting. (Чи може дочірній запис змінити батьківський?)
• Я знаю форму платформи для master-detail: щонайбільше три користувацькі рівні detail углиб (lookup може розірвати ланцюг будь-де) і два батьківські master-detail ушир. В об’єкті-з’єднувачі Salesforce першим створений master-detail — основний (власник, вигляд, підрозділ), другий — другорядний, а для доступу потрібні обидва батьківські: перемагає найсуворіший. (Три рівні вглиб, Два батьківські вшир)
• Я знаю три варіанти lookup, коли батьківський запис видаляють: очистити поле (за замовчуванням), заблокувати видалення або каскадне видалення, яке вимкнене, доки його не ввімкне Salesforce, і яке обходить спільний доступ. (Lookup)
• Я знаю, що зв’язок із собою мусить бути lookup, і знаю два вбудовані: Parent Account в Account і Parent Case в Case. (Зв’язки із собою)
• Я знаю, що перерахунок зведень може тривати, що зведення не може використовувати формулу з NOW(), TODAY() чи міжоб’єктним посиланням, і що не слід обирати master-detail лише заради зведення: альтернатива — збережене поле, яке тримає актуальним flow чи тригер. (Зведення корисні, але не безкоштовні)
• Я знаю ліміти зв’язків, на які посилається модуль: два master-detail на об’єкт; 40 полів зв’язків за замовчуванням (щонайбільше 50); 25 зведених полів за замовчуванням (щонайбільше 40). (Зв’язки теж мають ліміти)

DM-2: модель, що поважає спільний доступ і масштабується

• Я знаю, що дочірній запис master-detail не має власного власника й таблиці спільного доступу: доступ іде за master. (Власність іде в комплекті)
• Я знаю перекіс «батьківський–дочірній»: рекомендація Salesforce — не більше приблизно 10 000 дочірніх записів на один батьківський. (Питання 10 000 дочірніх записів)
• Я знаю перекіс власності (один користувач володіє понад 10 000 записів об’єкта) і рекомендації: розподіляти власність або тримати цього користувача поза ієрархією ролей чи окремо на вершині, і поза публічними групами, які використовують правила спільного доступу. (Власність може стати проблемою масштабу)
• Я знаю таблицю спільного доступу: об’єкт спільного доступу користувацького об’єкта — Object__Share; detail-об’єкт його не має, його доступ іде від master; а зміна власника прибирає ручний спільний доступ, але зберігає Apex sharing із власною причиною. (Таблиця спільного доступу)
• Я вмію вирішити, хто володіє записами, які створюють інтеграції й агенти, залежно від того, чи визначає власність спільний доступ. (Хто володіє записами, які створюють системи?)

DM-4: big objects порівняно зі стандартними й користувацькими об’єктами

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

SDM-1: ліцензії та об’єкти, якими можуть користуватися люди

• Я знаю три внутрішні ліцензії, Sales Cloud, Service Cloud і Platform, і що кожна з них може використовувати. (Три внутрішні ліцензії)
• Я знаю, що ліцензії — частина моделі даних: користувачі Salesforce Platform не отримують Leads, Campaigns, Opportunities чи Forecasts, а користувачі Customer Community не можуть використовувати Opportunity. (А тепер я все ускладню: ліцензування)
• Я знаю рівні зовнішніх ліцензій: Customer Community, Customer Community Plus (звіти, дашборди, стандартний спільний доступ), Partner Community (об’єкти продажів); і що Partner Community не можна використовувати з персональними акаунтами. (Стадіон)
• Я знаю ліцензування за учасником і за входами і для якої аудиторії підходить кожне. (Те, як вони платять, змінює дизайн)
• Я знаю, що деякі ліцензії платформи обмежують користувачів одним застосунком із щонайбільше десятьма користувацькими об’єктами, і шаблон із типами записів, щоб працювати в цих межах. (Коли ліцензія формує модель)
• Я знаю, що ліцензія Salesforce Integration призначена для користувачів «система–система», що працюють лише через API. (Люди вже не єдині користувачі)
• Я знаю, що для звітності за SLA потрібні entitlements і milestones, а для них — ліцензії Service. (А тепер я все ускладню: ліцензування)

SDM-2: як зберігати дані узгодженими

• Я вмію поставити правило на правильний щабель драбини узгодженості: тип поля і словник, required і unique, правила перевірки, правила дублікатів, автоматизація. (Як зберігати дані узгодженими)
• Я знаю, що обмежений список вибору відхиляє значення, яких немає в списку, навіть через 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	Першим створений master-detail об’єкта-з’єднувача Salesforce (власник, вигляд, підрозділ) і другий (обсяг звітів; стає основним, якщо перший прибрати)
Ієрархічний зв’язок	Особливий lookup лише в об’єкті User, як Manager, що не може замкнутися на того самого користувача
Префікс простору імен	Префікс постачальника на об’єктах і полях керованого пакета, як-от abc__Inspection__c
Таблиця спільного доступу	Об’єкт спільного доступу (AccountShare, Truck__Share), що зберігає більшість спільного доступу до запису, по рядку на користувача чи групу, з причиною
Зведене поле (roll-up summary)	Поле в master, що рахує, підсумовує чи знаходить мінімум або максимум його details
Перекіс даних	Забагато записів під одним батьківським чи одним власником, що спричиняє блокування й тривалі перерахунки спільного доступу
За учасником / за входами	Оплата за кожного зовнішнього користувача або за кожен вхід щомісяця
Драбина узгодженості	Рівні, що забезпечують правила даних, від типу поля до автоматизації
Обмежений список вибору	Список вибору, що відхиляє будь-яке значення поза своїм списком, з будь-якого джерела
Класифікація даних	Метадані поля про власника, використання, чутливість і категорію відповідності вимогам

Перевірте себе

Короткі сценарії в стилі курсу. Визначтеся з відповіддю, перш ніж розгорнути її.

1. Користувачам треба бачити деталі замовлень, якими володіє і які весь день оновлює ERP. У Salesforce вони їх не редагують. Копіювати їх чи ні?

Посилайтеся на них: зовнішні об’єкти через Salesforce Connect лишають ERP джерелом істини без копії, яку треба синхронізувати. Прийміть, що кожен перегляд робить виклик, тож затримка й доступність ERP мають значення, і що це краще підходить для читання, ніж для інтенсивного редагування чи звітності. Перечитайте За посиланням.

2. Бізнес хоче відстежувати дистриб’юторів, постачальників і роздрібних партнерів. Три користувацькі об’єкти?

Ні. Усі вони компанії, тож Account — чиста відповідність; різні назви — це ролі, які передаються типом, типом запису чи зв’язком. Перечитайте Тест чистої відповідності.

3. Дизайн використовує Opportunity, але більшість людей, яким потрібні дані, мають ліцензії Salesforce Platform чи Customer Community. Що тепер?

Ці ліцензії не можуть використовувати Opportunity, тож ліцензія — архітектурне обмеження: купити інші ліцензії, перенести досвід або переробити дизайн, зазвичай у бік користувацького об’єкта. Перечитайте А тепер я все ускладню: ліцензування.

4. ERP щоночі надсилає оновлення акаунтів. Як інтеграції знайти правильний запис, не запитуючи Salesforce ID?

Зберігайте номер клієнта з 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 із Crew (створений першим) і Truck. Диспетчер бачить бригаду, але не вантажівку. Чи бачить він Crew Assignment?

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

10. Партнер повторно надсилає файл маніфесту, і той самий клієнт трапляється в ньому двічі. У вас є правило дублікатів на Account, налаштоване на блокування. Ви в безпеці?

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

Додаткові матеріали

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