Мислити як архітектор даних

Також доступно 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)

An open sketchbook on a drafting table at dawn, a building sketched on one page and a data model on the other, with a pencil, an eraser, a cup and a lamp. — Зображення згенеровано ШІ

Навчальний посібник до розділу 1 курсу Data Architect. Спершу прочитайте сім модулів; ця сторінка допоможе перевірити, що запам’яталося.

Про цей посібник. Він побудований лише на власному змісті цього курсу та на переліку цілей в опублікованому посібнику Salesforce до іспиту. Він ніколи не спирається на справжні екзаменаційні запитання і не претендує на знання того, що буде на іспиті. Якщо ви складали іспит, будь ласка, не надсилайте мені запитань із нього: сертифікаційна угода забороняє ними ділитися, а завчати відповіді — у будь-якому разі хибний шлях до того, щоб стати архітектором.

У цьому розділі менше екзаменаційних фактів, і це навмисно. Він про те, як мислить архітектор, і жодна ціль іспиту не належить лише йому. Але іспит побудований зі сценаріїв: бізнес, кілька цифр, обмеження і кілька відповідей, які могли б спрацювати. Звички з цього розділу — це те, як ви читаєте такі сценарії. Тож контрольний список нижче вказує, яку ціль кожен пункт підтримує, а не стверджує, що її перевіряють безпосередньо.

Для іспиту

Позначайте їх у міру просування. Кожен пункт веде туди, де його пояснено.

Читати сценарій як архітектор (підтримує всі цілі)

Я відокремлюю справжню вимогу від дизайну, в якому вона прийшла («нам потрібні поля Approver 2 і Approver 3» проти «нам треба відстежувати кожне погодження»). (Не просто приймайте вимогу)
Я шукаю неявні вимоги, яких ніхто не назвав: володіння, свіжість, збої, зберігання, доступ. (Шукайте неявні вимоги)
Я підставляю цифри: обсяг на день, на рік, зі зростанням — і помічаю, коли ще один нуль змінює відповідь. (Знайте свої цифри)
Серед кількох робочих відповідей я порівнюю, що кожна дає і від чого відмовляється, з огляду на заявлені вимоги й обмеження. (Знайте, чим ви жертвуєте, Обмеження змінюють відповідь)
Я вважаю вартість, ліцензування й ліміти частиною того, чи пасує інструмент, а не чимось другорядним. (Дев’ять запитань)

Модель даних (підтримує DM-1)

Я можу оцінити модель за тим, чи вона підтримує бізнес, чи може зростати разом із ним і чи працює швидко. (Підтримувати. Зростати. Працювати.)
Я помічаю модель, яка надто пласка (Field 1, Field 2, Field 3), надмірно нормалізована або збудована на хибному стандартному об’єкті. (Надто пласка, надто складна чи просто хибна)
Я знаю, чому список вибору пасує до короткого стабільного переліку, а lookup — до переліку, що постійно зростає або надходить з інтеграції. (Багато способів розв’язати задачу)
Я знаю, що ключ, який несе зміст (скажімо, частину назви), ламається, коли цей зміст змінюється. (Деякі рішення змінити дешево)

Зміна наявного (підтримує DM-1 і SDM-2)

Я знаю, чому зміна типу поля або позначення наявного поля як Required може згодом щось зламати і чому платформа блокує зміну типу, поки на поле посилаються код чи flows. (Обережно зі зміною скелета)
Я знаю шаблон додавайте, а не змінюйте; виводьте з ужитку, а не заскакуйте зненацька і що Field Usage може позначити поле як кандидата на виведення. (Обережно зі зміною скелета)
Я знаю факти про master-detail, що стоять за тестом на зворотність: доступ і власність деталі визначає майстер, видалення майстра видаляє його деталі, зведені поля потребують master-detail, а lookup перетворюється на master-detail лише тоді, коли в кожному записі є значення. (Тест на зворотність, Додаткові матеріали)

Ліцензії та спільний доступ (підтримує SDM-1)

Я знаю, що користувачі спільноти великого обсягу (серед них Customer Community) не мають ролей і не використовують модель спільного доступу, тож доступ дають sharing sets і share groups, а Apex sharing до них не дістає. (Розібраний приклад: Apex sharing)

Збої (підтримує MIG-1 і розділи про інтеграцію)

Я знаю, що «завдання завершено» — не те саме, що дані правильні, і як звірка знаходить записи, які не дійшли. (Частковий успіх — теж збій, який треба зрозуміти)

За межами іспиту

Іспит — це підлога, а не стеля. Ось звички з цього розділу, потрібні архітекторові, незалежно від того, чи спитають про них колись на іспиті.

Хтось має тримати креслення. Архітектура — це ухвалювати добрі рішення з неповною інформацією і знати їхні наслідки.
Модель даних — це скелет. Усе інше будується на ній.
Тест на зворотність: наскільки важко це скасувати і скільки від цього залежатиме?
Архітектура створює гравітацію. Дорогими зміни роблять залежності, а не самі зміни.
Думайте про радіус ураження — усередині Salesforce і в масштабі підприємства. Архітектура — це двосторонній рух.
Запишіть, чому: контекст, варіанти, рішення, наслідки, відповідальний, перегляд. Замінюйте новим; не стирайте.
Найкраще в чому? Неоптимальне рішення може бути частиною оптимальної архітектури, якщо ви знаєте, що його ухвалюєте.
Тримайте образ оптимального, щоб знати, в який бік від нього відходите і чому.
Think Correct. Think Fast. Швидкість береться з мислення, зробленого до моменту.
Будуйте для сьогодні. Плануйте на завтра. Плануйте на випадок збою. І беріть 30 відсотків зростання, коли ніхто не дає вам числа.
Вивчайте дев’ять запитань, а не лише відповіді.
ШІ — це ракетний прискорювач. Генерація — не судження, незворотне лишається незворотним, а людський перегляд — не церемонія. Довіряй, але перевіряй.

Ключові терміни

Термін	Одним реченням
Архітектурне рішення	Рішення, яке важко скасувати і від якого багато що залежить
Тест на зворотність	Наскільки важко це скасувати і скільки від цього залежатиме?
Гравітація	Залежності, що з часом збираються навколо рішення
Радіус ураження	Усе інше, що зрушує, коли змінюється рішення
Запис рішення	Контекст, варіанти, рішення, наслідки, відповідальний і точка перегляду — коротко
Компроміс	Що варіант дає і від чого відмовляється, щоб це отримати
Неявна вимога	Те, чого бізнес очікує, не питаючи, як-от відновлення, коли завантаження не вдалося
«Кількість нулів» Steve	Ще один нуль в обсязі може змінити всю архітектуру
Звірка	Порівняння того, що мало статися, з тим, що сталося, запис за записом
Виведення з ужитку	Позначити щось як таке, що відходить, а потім свідомо прибрати, замість змінювати на місці
Користувач великого обсягу	Користувач спільноти (серед ліцензій — Customer Community) без ролі, поза моделлю спільного доступу
Розростання схеми	Об’єкти й поля, що накопичуються, бо їх дешево створювати, доки модель ніхто не проєктує

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

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

1. Команда продажів просить поля Approver 2 і Approver 3, кожне з датою, в Opportunity. Що ви запитаєте і що, можливо, збудуєте?

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

2. Хтось хоче перейменувати мітку поля, а хтось інший — змінити формат ідентифікатора клієнта, який уже зберігають п’ять систем. Що заслуговує більше вашої уваги і чому?

Ідентифікатор. Мітку змінити дешево. Ідентифікатор не проходить тест на зворотність: його важко скасувати, і від нього вже багато що залежить. Витрачайте увагу пропорційно ціні помилки. Перечитайте Деякі рішення змінити дешево.

3. Текстове поле використовується роками. Тепер бізнес хоче, щоб воно містило число. Який ваш підхід?

Не змінюйте його на місці. З’ясуйте, що від нього залежить (Flows, Apex, звіти, інтеграції, агенти) і що станеться зі старими даними. Зазвичай: додати нове поле, свідомо мігрувати і вивести старе з ужитку. Перечитайте Обережно зі зміною скелета.

4. 1 200 локацій, 100 записів на прийом на локацію на день, близько 305 днів на рік, два записи на кожен прийом, зберігання п’ять років, зростання 30 відсотків. Приблизно скільки записів і чому це важливо?

Близько 73 мільйонів записів за перший рік (36,6 мільйона записів на прийом, по два записи на кожен) і понад 650 мільйонів за п’ять років зі зростанням. Та сама функція, ще кілька нулів — зовсім інша архітектура. Перечитайте Знайте свої цифри.

5. Нічне завантаження повідомляє «завершено» для мільйона записів. Як дізнатися, що все спрацювало?

Ви робите звірку. Сторона, що приймає, підтверджує кожен збережений запис; відправник порівнює надіслане з підтвердженим. Відсутні підтвердження означають, що не спрацювало, хоч би що казав статус завдання, і показують, які записи повторити, передати людині чи за якими підняти тривогу. Перечитайте Частковий успіх — теж збій, який треба зрозуміти.

6. Спільнота з 15 мільйонів користувачів Customer Community потребує складного доступу до записів. Хтось пропонує Apex sharing. У чому проблема?

Це користувачі великого обсягу: без ролей, поза моделлю спільного доступу, тож немає запису спільного доступу, який міг би записати Apex. Доступ дають sharing sets і share groups. Ліцензія вирішила, які інструменти спільного доступу існують. Перечитайте Розібраний приклад: Apex sharing.

7. ШІ-інструмент за хвилини генерує двадцять об’єктів для нового застосунку. Яка тепер робота архітектора?

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

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

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