Перетворіть модель на 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 розділу Моделювання даних заради змісту, розділ 2 курсу Data Architect. Кожен модуль самостійний. Попередній: Проєктуйте до третьої нормальної форми, а потім відступіть · Наступний: навчальний посібник до розділу, потім наступний розділ: архітектура даних Salesforce

Питання, на яке відповідає цей модуль: Як логічна модель даних стає фізичною моделлю даних Salesforce?

Нарешті ми поговоримо про Salesforce. Якщо ви стримували бажання перетворити кожен прямокутник на об’єкт, тепер можна. Але зверніть увагу на порядок, яким ми сюди прийшли: зрозуміли бізнес, описали дані, поклали кожен факт на його місце і вирішили, де свідомо від цього відступимо. Лише тепер я питаю, як Salesforce має це реалізувати. Ось послідовність, яку я хочу, щоб ви запам’ятали: концептуальна → логічна → фізична. Концептуальна модель описує бізнес. Логічна модель описує дані. Фізична модель описує, як ми насправді це збудуємо.

Сидіти, чекати, моделювати

Фізичний крок найлегше побачити на чомусь маленькому, тож улюбленці йдуть першими.

Хто тут компанії й люди? Заводчик — компанія, тож він стає Account із типом запису Breeder. Власник теж Account, або персональний акаунт, із типом запису Owner. Два види того самого стандартного об’єкта, поруч угорі діаграми, саме там, де вони були з модуля 1.

Що не має стандартного дому? Улюбленець, Порода, Трюк, Трюк улюбленця і Оцінка трюку стають користувацькими об’єктами. А пам’ятаєте вид, який ми скопіювали на улюбленця в модулі 5? Тут він отримує свою роботу: він стає типом запису Улюбленця — Dog чи Cat. Один об’єкт із двома типами записів, кожен із власним макетом сторінки й значеннями списків вибору, замість об’єкта Собака й об’єкта Кіт.

Які зв’язки — master-detail? Я використовую master-detail лише там, де дочірній запис ніколи не змінить батька. Трюк улюбленця належить своєму улюбленцю довічно, а кожна Оцінка трюку належить своєму Трюку улюбленця, тож обидва — master-detail. Це одразу окупається: саме master-detail дає улюбленцю змогу мати зведене поле (roll-up summary) за своїми Трюками улюбленця, тож лічильник Відомих трюків із модуля 5 сам іде в ногу. Але улюбленці змінюють домівки, тож Власник — це lookup.

Які — lookup? Salesforce не рекомендує понад 10 000 дочірніх записів на одного батька. Популярний трюк на кшталт «Сидіти», поширена порода чи великий заводчик легко перевищать цю межу, тож Трюк улюбленця посилається на свій Трюк через lookup, а улюбленець так само посилається на свою Породу і Заводчика. І уникайте поліморфних зв’язків, де можете, — тих, де одне поле може посилатися на об’єкти кількох типів. Вони зручні першого дня і складніші для всього, що має їх читати згодом: звітів, інтеграцій, а тепер і агентів.

Що лишається поза платформою? Якщо улюбленець носить GPS-нашийник, який повідомляє, де він, це місцезнаходження взагалі не треба копіювати всередину. Це може бути зовнішній об’єкт, що читається наживо із системи відстеження нашийника.

Click to enlarge

Кожне рішення на цій діаграмі веде назад до чогось, що ми вирішили раніше, і в цьому суть. Тепер той самий крок для Steve Trucking.

Почніть із логічної моделі

Наша логічна модель Steve Trucking тепер містить Роздрібного партнера, Розподільчий центр, Маніфест, Доставку, Позицію доставки, Отримувача, Маршрут, Зупинку, Бригаду, Вантажівку і Призначення бригади. Це бізнес-поняття, і тепер я можу почати відображати їх на Salesforce.

Роздрібний партнер може бути Account. Доставка може відобразитися на щось, що в Salesforce уже є для запланованої роботи в полі, або стати користувацьким об’єктом. Для маніфесту немає нічого стандартного, тож він, мабуть, стане користувацьким. А отримувач — справді складне запитання: Person Account, Contact чи просто інформація на доставці? Ми як слід відповімо на нього в наступному розділі.

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

Бізнес-сутність не означає автоматично користувацький об’єкт

Ось пастка, якої я хочу, щоб адміністратори уникали: «Ми визначили одинадцять сутностей, тож нам потрібно одинадцять користувацьких об’єктів». Ні. Логічна сутність каже нам, що бізнес-поняття важливе. Вона не диктує, як Salesforce має його зберігати. Поняття може стати стандартним об’єктом, користувацьким об’єктом, зв’язком між об’єктами, полем чи кількома полями, значенням у конфігурації або даними, що взагалі живуть поза Salesforce (фото доставок Steve Trucking — добрий кандидат для цього). Фізична модель — це місце, де ухвалюють ці рішення, і саме тому ми не ухвалювали їх на першій розмові.

Атрибути стають фізичними полями

Той самий перехід відбувається з атрибутами. Наша логічна Вантажівка має бортовий номер, VIN, марку, модель, рік випуску, номерний знак і статус. Тепер ми вирішуємо, як вони існують фізично: який об’єкт ними володіє, яких типів поля, які обов’язкові, які мають бути унікальними, які є зовнішніми ідентифікаторами, які потребують перевірки, які обчислюються, а не зберігаються, і які чутливі. На логічному рівні ми питали, що означає Вантажівка. На фізичному рівні ми питаємо, як Salesforce відобразить Вантажівку. Різні запитання.

Click to enlarge

Зв’язки стають рішеннями платформи

Увесь час, витрачений на зв’язки, окупається тут. Ми вже знаємо, чи кожен із них «один до одного», «один до багатьох» чи «багато до багатьох», обов’язковий чи ні і чи важлива його історія. Тепер ми вирішуємо, як Salesforce це реалізує: lookup, master-detail чи об’єкт-з’єднувач Salesforce (Salesforce Junction Object), можливо з’єднувач із власними атрибутами, бо, як ми з’ясували, сам зв’язок може мати бізнес-зміст.

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

Тепер намалюйте фізичну модель

Діаграма знову змінюється. Концептуальна модель показувала бізнес-поняття і прості лінії. Логічна модель додала атрибути, ключі, кардинальність і сутності, що ховаються у зв’язках. Тепер фізична модель починає виглядати як Salesforce: стандартні об’єкти, користувацькі об’єкти, поля, типи зв’язків і те, що живе поза платформою.

Click to enlarge

Я хочу, щоб ви могли покласти ці три діаграми поруч і побачити поступ: не три непов’язані діаграми, а той самий бізнес на трьох рівнях.

Кілька слів про те, як я їх малюю, бо компонування — частина повідомлення. Я ставлю головний об’єкт посередині, трохи нижче. Якщо в нього є батьківські об’єкти, я ставлю їх трохи вище, щоб модель читалася згори донизу, зліва направо, так, як про це думає бізнес. Довідкові дані — збоку. Колір теж щось означає: Salesforce я завжди роблю синім, а для власних систем компанії обираю колір, зазвичай зелений, бо зелений — приємний дружній колір. Червоний я не використовую, а жовті трохи різкуваті. Коли модель скомпонована так, вона для мене співає. Багато діаграм, які ви знайдете, насправді про управління простором: як мені припаркувати всі машини в тісному гаражі? Я волію намалювати логічну картину, яку розум може охопити.

Фізична модель має поважати платформу

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

Іноді фізична модель також свідомо відрізнятиметься від чистої логічної моделі через рішення про денормалізацію, які ми ухвалили в модулі 5. Це нормально, якщо ми можемо пояснити чому.

Не проєктуйте з Setup

Є звичка, яку я хочу, щоб ви покинули, якщо вона у вас є: починати архітектуру даних із Setup → Object Manager → New Custom Object і з’ясовувати модель на ходу. Salesforce робить створення речей неймовірно легким; це одна з його сильних сторін і одна з причин, чому слабкі моделі даних з’являються так швидко. Кілька кліків — і в вас об’єкт, ще кілька — і поля та зв’язок. Потім надходять дані, будуються flows, створюються звіти, від нього залежать інтеграції, і об’єкт, створений за п’ять хвилин, стає дуже дорогим для змін. Це тест на зворотність із розділу 1. Тож перш ніж натиснути New Custom Object, намалюйте модель.

Фізична — не означає постійна

Є ще одна причина, чому я тримаю три моделі окремо: технології змінюються. Сьогодні частина даних Steve Trucking живе в ядрі Salesforce. Завтра частина може жити в Data 360, сховищі даних чи системі, яку ми ще не обрали, а ШІ-асистентові потрібне власне відображення. Фізична архітектура може змінюватися, а бізнес-поняття лишаються напрочуд стабільними: роздрібні партнери, доставки й отримувачі досі існують. Саме це робить логічну модель цінною. Це довговічний опис бізнесу, не прив’язаний до сьогоднішньої реалізації.

Що тут вирішує архітектор

Перетворюючи логічну модель на фізичну модель Salesforce, я вирішую:

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

Найважливіше: я хочу мати змогу простежити кожне рішення назад. Якщо ви покажете на щось у моїй фізичній моделі й запитаєте «Чому це тут?», я маю провести вас назад через логічну й концептуальну моделі до чогось, що справді потрібно бізнесу: бізнес → концептуальна → логічна → фізична.

За межами іспиту: що змінює ШІ. ШІ тепер може за один стрибок пройти від документа з вимогами до об’єктів і полів 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): зведене поле рахує або підсумовує записи деталей через зв’язок master-detail.