Модель даних — це скелет

🌐 Також доступно 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 з 7 розділу Мислити як архітектор даних, першого розділу курсу Data Architect. Кожен модуль самостійний. Попередній: Мислити як архітектор · Наступний: Тест на зворотність

Питання, на яке відповідає цей модуль: Чому модель даних важливіша за все, що на ній побудовано, і як її оцінювати?

Коли я викладаю архітектуру даних, є фраза, до якої я повертаюся знову і знову: модель даних — це скелет.

Модель даних — це скелет системи. Усе інше будується навколо неї, і саме вона тримає решту тіла вкупі. Дивлячись на людину, ви не бачите кісток, але саме вони визначають, якого вона зросту, як рухається і що може нести.

Подумайте про все, що ми будуємо під час впровадження Salesforce. Ми будуємо автоматизацію навколо моделі даних. Пишемо до неї Apex і Flows, що її читають і оновлюють. Будуємо інтеграції, які надсилають у неї дані й забирають їх звідти. Створюємо на ній звіти й аналітику і проєктуємо навколо неї безпеку. І дедалі частіше будуємо ШІ-агентів, яким треба розуміти ці дані й діяти на їх основі. Усе це залежить від структури під ним.

Ось чому так важливо вчасно зробити модель даних правильно. Скелет можна змінити пізніше. Але, найімовірніше, буде боляче.

Почніть із бізнесу

Добра модель даних починається з простого запитання: що насправді має відображати бізнес? Не «які об’єкти Salesforce у нас є?» І точно не «що я можу швидко збудувати?»

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

Це звучить очевидно. На практиці дуже легко зробити все навпаки. Хтось бачить щось схоже на Opportunity, Case чи Asset і одразу починає проєктувати навколо цього. Іноді це саме те, що треба. Іноді ми запихаємо квадратний кілок у круглий отвір, і коли навколо цього рішення вже чимало збудовано, витягти кілок назад стає дуже дорого.

Ось запитання, яке я чую постійно. Бізнес клієнта може мати багато адрес доставки. Чи має кожна адреса бути Account, чи користувацьким об’єктом? Перш ніж відповісти, зверніть увагу, що вам треба знати спершу: що адреса означає для цього бізнесу і що з нею відбувається. Це і є моделювання бізнесу перед об’єктами. (Свою відповідь я дам у розділі 3.)

Підтримувати. Зростати. Працювати.

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

Підтримувати. Модель має підтримувати те, чого бізнес насправді намагається досягти. Є велика різниця між моделлю, яка технічно може зберігати дані, і моделлю, яка справді добре відображає бізнес. Якщо я постійно додаю дивні поля, спеціальні прапорці, складну автоматизацію і винятки, бо модель не зовсім пасує, я починаю питати, чи проблема справді в автоматизації. Можливо, хибна сама модель. Добра модель має робити бізнес зрозумілішим, а не складнішим.

Зростати. Кажучи «зростати», я маю на увазі не лише більше записів. Обсяг важливий: десять тисяч записів і сто мільйонів створюють дуже різні проблеми. Але бізнес зростає і в складності. Додає продукти, виходить на нові ринки, купує компанії, змінює процеси, додає канали й підключає нові системи. Виявляє, що те, що здавалося однією річчю, насправді п’ять різних. Модель, яка чудово працює сьогодні, може стати пасткою, якщо в ній немає місця для завтра. Тому я віддаю перевагу дизайнам, які зростають через додавання, а не тим, що постійно змінюють уже наявне. Додати щось нове зазвичай легше, ніж перевизначати те, від чого залежать десятки інших речей.

Працювати. Дані не просто лежать. Ми їх записуємо, шукаємо, запитуємо, ділимося ними, будуємо на них звіти й інтегруємо, а дедалі частіше ШІ-системи витягують їх як контекст, перш ніж діяти. Модель може гарно виглядати на діаграмі й бути жахливою в експлуатації. Тож ми проєктуємо і те, як дані зберігаються, і те, як їх використовуватимуть.

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

Підтримувати. Зростати. Працювати. Ми повертатимемося до цих трьох тестів протягом усього курсу.

Click to enlarge

Надто пласка, надто складна чи просто хибна

Я бачив, як моделі даних ідуть шкереберть трьома способами.

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

Другий — зробити модель надто пласкою. Усе йде в один об’єкт, і спершу це здається чудово простим. Потім бізнес росте, і ми виявляємо, що деякі з цих речей мають власний життєвий цикл, можуть мати кілька екземплярів, потребують власної безпеки або мають власні зв’язки. Раптом ми відображаємо зв’язок «один до багатьох» через Field 1, Field 2 і Field 3 або через дедалі складніші прапорці й автоматизацію. Модель не залишила нам місця для зростання.

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

То що правильно — пласка чи нормалізована? Формули немає. Ви тримаєте в голові образ оптимальної моделі й розумієте компроміси, віддаляючись від неї. Це мистецтво архітектури, і ми повернемося до нього в модулі 4 та в наступному розділі, де вчимося моделювати. Поки що визнайте, що сама структура — це архітектурне рішення.

Click to enlarge

Обережно зі зміною скелета

Щойно система запрацювала, я стаю дуже обережним щодо фундаментальних змін моделі даних.

Припустімо, текстове поле існує роками, і хтось каже: «Ми вже насправді не так ним користуємося. Змінімо його на число». Звучить як зміна поля. Але що від цього поля залежить? Flows, Apex, звіти, інтеграції, конвеєри даних, зовнішні застосунки, ШІ-агенти. А що станеться з історичними даними? Сама платформа не дасть змінити тип поля, поки на нього посилаються код чи flows, — і це показує, як далеко сягає така зміна.

Іноді правильна відповідь — не змінювати наявне. Залежно від серйозності зміни я радше створю щось нове, свідомо мігрую і виведу стару структуру з ужитку:

Додавайте, а не змінюйте. Виводьте з ужитку, а не заскакуйте зненацька.

Salesforce навіть дає спосіб сказати це в метаданих: для поля можна встановити Field Usage у значення DeprecateCandidate — «планується до виведення і більше не використовується». Це позначає поле для кожного, хто читає об’єкт; поле не ховається, тож вивести його з ужитку — це все одно рішення, яке ви виконуєте.

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

Click to enlarge

Навіть така проста річ, як поставити позначку Required на полі, може стати бомбою сповільненої дії. Якщо ви вже зібрали дані, у деяких записах це поле не заповнене. Потім, за дні, тижні чи місяці, хтось оновлює один із таких записів, і збереження не вдається через обов’язкове поле, а цього значення ні в кого немає. Така проста зміна, як зробити поле обов’язковим, може мати непередбачені й відкладені наслідки. Ми повернемося до Required і до того, коли значення справді відоме, у розділі 3.

За межами іспиту: ШІ теж будує на скелеті. Попросіть ШІ-інструмент збудувати застосунок, і він за хвилини згенерує об’єкти, поля, Flows, Apex, компоненти й тести. Якщо початкова модель даних була хибною, ми не уникнули наслідків поганого рішення; ми їх прискорили, бо кожен згенерований шар — ще одна річ, що залежить від цієї структури. Тому я хочу, щоб модель даних, згенеровану ШІ, переглядав архітектор-людина, розумів її і відповідав за неї. Модуль 7 розвиває цю думку.

Спершу скелет

Протягом курсу ми говоритимемо про багато технологій: об’єкти й зв’язки, великі обсяги даних, запити, інтеграцію, міграцію, транзакції, безпеку, Data 360 і ШІ. Під усім цим лежить модель даних.

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

Модель даних — це скелет. Архітекторам слід бути дуже обережними, проєктуючи скелет. Зміни наявних структур можуть мати каскадні наслідки.

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

• Чи підтримує модель бізнес, чи може зростати разом із ним і чи працює для тих способів, якими використовуватимуть дані.
• Чи пасує поняття до стандартного об’єкта, чи це квадратний кілок.
• Наскільки пласкою чи нормалізованою зробити модель і чому.
• Чи має зміна скелета бути додаванням, міграцією чи виведенням з ужитку, а не зміною на місці.

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

• Considerations for Converting the Field Type of a Custom Field (opens in a new tab), Salesforce Help (англійською, перевірено 2026-10-02; повторно 2026-10-12): які зміни типу можуть призвести до втрати даних і чому не можна змінити тип поля, на яке посилаються Apex, flows чи процеси.
• Data Classification Metadata Fields (opens in a new tab), Salesforce Help (англійською, перевірено 2026-10-02; повторно 2026-10-12): значення Field Usage (Active, DeprecateCandidate, Hidden) та інші поля класифікації.