Моделювання даних заради змісту
Також доступно 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)
Навчальний посібник до розділу 2 курсу Data Architect. Спершу прочитайте шість модулів; ця сторінка допоможе перевірити, що запам’яталося.
Про цей посібник. Він побудований лише на власному змісті цього курсу та на переліку цілей в опублікованому посібнику Salesforce до іспиту. Він ніколи не спирається на справжні екзаменаційні запитання і не претендує на знання того, що буде на іспиті. Якщо ви складали іспит, будь ласка, не надсилайте мені запитань із нього: сертифікаційна угода забороняє ними ділитися, а завчати відповіді — у будь-якому разі хибний шлях до того, щоб стати архітектором.
Цей розділ — фундамент для частини іспиту Data Modeling and Database Design, яка становить чверть іспиту. Він охоплює мислення; наступний розділ, Архітектура даних Salesforce, — те, як це будує платформа. Тож для більшості того, що перевіряють про об’єкти, поля і зв’язки, потрібні обидва розділи.
Для іспиту
Section titled “Для іспиту ”Пункти з цього розділу, які найімовірніше знадобляться на іспиті. Кожен прив’язаний до своєї цілі іспиту і веде туди, де його пояснено. Позначайте їх у міру просування.
DM-1: порівняння технік проєктування моделі даних Salesforce
- Я можу пояснити різницю між концептуальною, логічною і фізичною моделлю даних і для чого кожна з них. (Перетворіть модель на Salesforce)
- Я можу знайти кандидатів у сутності у вимозі й відрізнити людину, що виконує роботу, від частини даних. (Іменники дають кандидатів у сутності)
- Я можу читати й малювати нотацію «воронячі лапки»: один, багато і друга позначка для необов’язкового чи обов’язкового. (Читайте лінії, Обов’язковість теж важлива)
- Я можу назвати кардинальність зв’язку: «один до одного», «один до багатьох», «багато до багатьох». (Питайте «один чи багато?»)
- Я знаю, що зв’язок «багато до багатьох» стає окремою сутністю, а в Salesforce зазвичай об’єктом-з’єднувачем із двома батьками. (Зв’язки можуть ставати речами)
- Я знаю, коли зв’язку потрібна історія (запис із датами початку й завершення), а не поле, яке перезаписують. (Час змінює зв’язки)
- Я можу обрати добрий унікальний ID і знаю, чому природний ключ або будь-що з персональною інформацією — ризикований вибір. (Далі треба поговорити про унікальні ID)
- Я знаю різницю між природним і сурогатним ключем і що один запис може нести кілька зовнішніх ідентифікаторів. (Природні й сурогатні ключі)
- Я знаю, що поле Auto Number — це читабельний номер, а не ID запису Salesforce. (Зв’язки залежать від унікальних ID)
- Я можу застосувати першу, другу і третю нормальні форми і помітити поле, що містить кілька значень або повторює факт про щось інше. (Простий спосіб думати про 1НФ, 2НФ і 3НФ)
- Я можу пояснити, коли свідомо денормалізувати (користувачі, звітність, масштаб) і чого це коштує. (Проєктуйте до третьої нормальної форми, а потім відступіть)
- Я можу обрати між списком вибору і lookup на об’єкт для переліку значень. (Lookup чи список вибору?)
- Я знаю, що користувацький тип звіту дозволяє щонайбільше чотири зв’язки між об’єктами і чому це важливо для глибоких моделей. (Lookup чи список вибору?)
- Я знаю, коли пасує master-detail (дочірній запис ніколи не змінює батька), а коли безпечніший lookup, зокрема настанову Salesforce не більше ніж 10 000 дочірніх записів на одного батька. (Зв’язки стають рішеннями платформи)
- Я знаю, чому варто уникати поліморфних зв’язків, де можна. (Зв’язки стають рішеннями платформи)
- Я знаю, що бізнес-сутність не означає автоматично користувацький об’єкт: це може бути стандартний об’єкт, поле, конфігурація чи дані, що живуть поза Salesforce. (Бізнес-сутність не означає автоматично користувацький об’єкт)
За межами іспиту
Section titled “За межами іспиту ”Іспит — це підлога, а не стеля. Ось звички з цього розділу, потрібні архітекторові, незалежно від того, чи спитають про них колись на іспиті.
- Забудьте на хвилину про Salesforce. Моделюйте бізнес, перш ніж відображати його на Account і Contact.
- Слухайте слово, що ховає дві речі. У Steve Trucking «клієнт» — це роздрібний партнер і отримувач.
- Модель — частина розмови. Ваша перша модель не має бути правильною; вона має показати, де ви помиляєтеся.
- Називайте лінії. Дві моделі з однаковими прямокутниками можуть означати різне.
- Питайте «зараз чи з часом?» про кожен зв’язок.
- Унікальний, незмінний, без змісту, ніколи не персональні дані.
- Покладіть факт на його місце, потім свідомо відступіть і запишіть чому.
- Денормалізація не прибирає складність; вона її переносить. Знайте, хто володіє правдою.
- Одне джерело правди, багато форм: екрани, звіти, сховище даних і ШІ.
- Не проєктуйте з Setup. Намалюйте модель, перш ніж натиснути New Custom Object.
- Простежуйте кожне фізичне рішення назад до чогось, що потрібно бізнесу.
Ключові терміни
Section titled “Ключові терміни ”| Термін | Одним реченням |
|---|---|
| Сутність | Річ, яка важлива бізнесу і про яку він зберігає дані |
| Кандидат у сутності | Іменник, який може стати сутністю, коли ви про нього розпитаєте |
| Атрибут | Факт, що описує сутність |
| Зв’язок | Як дві сутності поєднані, названо мовою бізнесу |
| Кардинальність | Скільки одних пов’язано зі скількома інших |
| Обов’язковість | Чи зв’язок обов’язковий, чи може бути нуль |
| «Воронячі лапки» | Позначка «багато» на кінці лінії |
| Об’єкт-з’єднувач | Спосіб Salesforce будувати зв’язок «багато до багатьох»: дочірній запис обох батьків |
| Концептуальна модель | Що існує в бізнесі і як воно пов’язане; без Salesforce |
| Логічна модель | Дані: атрибути, унікальні ID і зв’язки, досі не прив’язані до платформи |
| Фізична модель | Як платформа це збудує: об’єкти, поля і типи зв’язків |
| Природний ключ | Ідентифікатор, що вже існує в бізнесі, як VIN вантажівки |
| Сурогатний ключ | Ідентифікатор, створений лише для ідентифікації запису |
| Зовнішній ідентифікатор | ID того самого запису в іншій системі, що зберігається й зіставляється |
| Нормалізація (1НФ, 2НФ, 3НФ) | Кожен факт — на його місці: одне значення на поле, факти про весь ключ, жодних фактів про інші факти |
| Денормалізація | Свідоме копіювання чи сплощення даних із причиною, яку можна назвати |
| Аномалія оновлення | Той самий факт зберігається в багатьох місцях, тож одна зміна лишає деякі копії хибними |
Перевірте себе
Section titled “Перевірте себе ”Короткі сценарії в стилі курсу. Визначтеся з відповіддю, перш ніж розгорнути її.
1. Бізнес каже вам, що бригада їздить на вантажівці. Через шість тижнів хтось питає, яка бригада мала вантажівку 117 певного дня. Що мала містити модель?
Призначення бригади: зв’язок між бригадою і вантажівкою як окремий запис із датою початку, датою завершення і маршрутом. З часом бригади й вантажівки пов’язані як «багато до багатьох», а бізнесу важлива історія. Поле на вантажівці було б перезаписане. Перечитайте Час змінює зв’язки.
2. Команда пропонує використовувати номер телефону кожного отримувача як унікальний ID, «бо він унікальний». Що ви скажете?
Він не проходить тестів: номери телефонів змінюються і ними діляться, тож він не незмінний і не надійно унікальний, і це персональна інформація, яку копіювали б у кожну систему, пов’язану із записом. Використайте згенерований ID без змісту, а номер телефону тримайте як атрибут. Перечитайте Далі треба поговорити про унікальні ID.
3. Доставка має поля Item 1, Item 2 і Item 3. Надходить доставка з чотирма позиціями. У чому справжня проблема і як її виправити?
Модель сховала повторювану структуру всередині полів (проблема першої нормальної форми). Виправлення — не поле Item 4; це сутність Позиція доставки, дочірня до Доставки, щоб кожна позиція була записом. Перечитайте Перша нормальна форма.
4. Кожна доставка зберігає ім’я менеджера розподільчого центру. Менеджер змінюється. Що пішло не так?
Факт про щось інше (розподільчий центр) зберігали на доставці: проблема третьої нормальної форми, а тепер ще й аномалія оновлення в сотнях записів. Менеджерові місце в розподільчому центрі; доставка посилається на розподільчий центр. Перечитайте Третя нормальна форма.
5. Вид зупинки (лише доставка, зі встановленням, з вивезенням) потребує тривалості, навичок бригади і чек-листа. Список вибору чи об’єкт?
Об’єкт. У нього більше однієї колонки інформації, ним керує бізнес, і він змінюється за власним графіком. Статус доставки, короткий стабільний перелік міток, лишається списком вибору. Перечитайте Lookup чи список вибору?.
6. Партнери хочуть показник вчасності за регіонами, а регіон живе на розподільчому центрі. Ви копіюєте регіон на кожну доставку. Що треба вирішити?
Хто володіє правдою, як копія лишається синхронізованою і чи мають старі доставки зберігати регіон, що був правдою на момент доставки, чи слідувати за розподільчим центром, якщо він переїде. Денормалізація перенесла складність, а не прибрала її. Перечитайте Іноді перемагає звітність.
7. Трюк на кшталт «Сидіти» може бути пов’язаний із сотнями тисяч улюбленців. Master-detail чи lookup від Трюку улюбленця до Трюку?
Lookup. Настанова Salesforce — не більше 10 000 дочірніх записів на одного батька, а популярний трюк її перевищить. Master-detail пасує від Трюку улюбленця до Улюбленця, бо трюк улюбленця ніколи не змінює батька, а один улюбленець знає лише кілька трюків; саме це й дає улюбленцю змогу підсумовувати свій лічильник Відомих трюків. Перечитайте Сидіти, чекати, моделювати.
Додаткові матеріали
Section titled “Додаткові матеріали ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (англійською, перевірено 2026-09-25): офіційний перелік цілей та їхньої ваги. Завжди перевіряйте актуальну версію, перш ніж записатися на іспит.