Проєктуйте до третьої нормальної форми, а потім відступіть
Також доступно 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)
Модуль 5 з 6 розділу Моделювання даних заради змісту, розділ 2 курсу Data Architect. Кожен модуль самостійний. Попередній: Розмістіть дані там, де їм місце · Наступний: Перетворіть модель на Salesforce
Питання, на яке відповідає цей модуль: Коли варто свідомо відійти від чистої нормалізованої моделі?
У попередньому модулі я сказав вам проєктувати до третьої нормальної форми.
Тепер я скажу вам її порушити.
Іноді.
Це важлива відмінність. Є велика різниця між тим, щоб випадково збудувати безладну модель даних, і тим, щоб свідомо денормалізувати чисту. Якщо ви взагалі не розумієте, де місце даних, копіювання їх кудись іще — не архітектура. Це просто дублювання.
Але щойно я розумію чисту логічну модель, я можу свідомо вирішити надати даним іншої форми для людей і систем, що їх споживають.
Проєктуйте до третьої нормальної форми, де це можливо. Потім відступайте, коли це необхідно.
Зверніть увагу, чого цей рядок не каже. Він не каже, що третю нормальну форму легше зрозуміти. Іноді важче: повністю нормалізована модель може розкидати одну бізнес-ідею по п’яти об’єктах, і люди, що нею користуються, мусять збирати її в голові. Нормалізація каже мені, де місце кожного факту. Вона не обіцяє, що це найлегша для читання, використання чи звітності форма. Саме тому відступ — проєктна навичка, а не поразка.
Почніть із моделювання правди. Потім вирішіть, як цю правду треба доставити.
Сидіти, чекати, моделювати
Section titled “Сидіти, чекати, моделювати ”Повернімося до собак, і цього разу ухвалимо кілька свідомих рішень.
Порода: список вибору чи окрема таблиця? Пропустіть її через запитання, які я дам вам далі в цьому модулі. Чи є більше однієї колонки інформації? Так: принаймні розмір. Скільки значень? Кінологічні клуби визнають кілька сотень порід (сам лише American Kennel Club налічує 205), набагато більше за моє емпіричне правило приблизно у 20. Тож Порода заслуговує на окрему таблицю, і кожна собака посилається на свою породу. Це розв’язує запитання, яке ми несемо з модуля 1: Порода — окремий прямокутник.
Рівень навички: список вибору. Вчиться, Добре, Експерт. Три мітки, більше про них нічого сказати, і вони не змінюватимуться. Саме для цього список вибору й існує.
Скільки трюків знає кожна собака? Відповідь уже є в моделі: порахуйте записи Трюку собаки для цієї собаки. Але дресирувальник хоче бачити це число в кожному звіті, сортувати й фільтрувати за ним, не будуючи звіт по двох таблицях. Тож я відступаю і тримаю лічильник Відомих трюків прямо на собаці. Це копія. Правда досі живе в Трюку собаки; лічильник — її відображення, і він має йти в ногу з нею. Salesforce дає нам чистий спосіб саме це зробити, і ми побачимо його в модулі 6.
А тепер поворот: школа для собак починає приймати котів. Що робимо? Один варіант: додати таблицю Кіт поруч із таблицею Собака і Трюк кота поруч із Трюком собаки. Усе подвоюється: по два кожного екрана, по два кожного звіту, а в день, коли почнуть приймати кроликів, — по три. Інший варіант: відступити й помітити, що в кота є власник, можливо заводчик, порода, дата народження і, за терпіння, трюк-другий. Ті самі факти й ті самі зв’язки, що й у собаки. Тож ми узагальнюємо: Улюбленець із Видом — собака чи кіт. Кожна порода теж належить до виду, і саме там вид живе по-справжньому: лабрадор — це собака. Улюбленець свідомо несе копію, щоб кожен екран і звіт міг почати з «собака чи кіт?», не шукаючи породу. Ще одна свідома копія, і в модулі 6 вона отримає власну роботу.
Це проєктування з урахуванням змін, і це компроміс. Узагальніть зарано — і все стане розмитою «Річчю» з полем типу, якого ніхто не розуміє. Я узагальнюю, коли бізнес справді приносить мені другий вид, і два види мають майже все спільне, як собаки й коти тут. Якби котам були потрібні зовсім інші факти, я подумав би двічі.
Тепер ті самі види рішень у Steve Trucking, де ставки вищі.
Найчистіша модель — не завжди найкраща система
Section titled “Найчистіша модель — не завжди найкраща система ”Уявіть бригаду на зупинці. У доставки є позиції. У встановлення є чек-лист. Кожен крок потребує фото. Отримувач розписується.
Нормалізована модель прекрасна: Доставка → Позиція доставки → Чек-лист встановлення → Фото, кожне на своєму місці.
Потім я сідаю з людьми, які справді цим користуються. Бригада закриває близько десяти зупинок на день, на під’їзних доріжках, часто без зв’язку. Якщо моя прекрасна модель веде їх лабіринтом екранів і пов’язаних списків, щоб закрити одну зупинку, у мене архітектурна проблема.
Модель даних — не єдине, що ми проєктуємо.
Ми проєктуємо систему.
Іноді перемагає користувацький досвід
Section titled “Іноді перемагає користувацький досвід ”Це одна з причин, чому я іноді відступаю від ідеально нормалізованої моделі: користувацький досвід.
Можливо, поняття технічно могло б бути окремою сутністю, але його відокремлення додає складності, яка дає дуже мало цінності. Можливо, батьківський запис із кількома рівнями дочірніх академічно чистий, але болісний для введення й підтримки. Можливо, поняття невелике, стабільне і використовується переважно як вибір.
Саме тут я перестаю питати лише «Де теоретично місце цього факту?» і починаю питати «Як насправді користуватимуться цією системою?»
Це не означає, що кожна скарга на зайвий клік сплощує модель. Це означає, що зручність — легітимний архітектурний чинник.
Іноді перемагає звітність
Section titled “Іноді перемагає звітність ”Звітність — ще одна поширена причина.
Кожен роздрібний партнер хоче показники: вчасні доставки за регіонами, за місяцями. У чистій моделі доставка знає свій розподільчий центр, а DC знає свій регіон. Технічно ми можемо цим пройти.
Але чи може інструмент звітності? Чи можуть люди, які будують власні звіти? Чи можуть вони відповісти на запитання без архітектури звітності, складнішої за саме запитання?
Тоді я можу скопіювати або вивести регіон на доставку, ближче до місця споживання.
Тепер я створив дублювання. Тож потрібне ще одне запитання: хто володіє правдою?
Якщо значення в джерелі зміниться, що станеться з моєю копією? Вона має змінитися? Чи має зберегти те, що було правдою, коли доставка відбулася? Це різні вимоги.
Денормалізація не усуває складності.
Вона її переносить.
Lookup чи список вибору?
Section titled “Lookup чи список вибору? ”Ось менший приклад, з яким адміністратори Salesforce стикаються постійно. Користувачеві треба вибрати з набору значень. Створити ще одну сутність і зв’язатися з нею чи використати список вибору?
Візьміть статус доставки: заплановано, завантажено, у дорозі, прибуває, доставлено, встановлено, виняток, повернено. Короткий стабільний перелік міток. Список вибору — саме те, що треба.
Тепер візьміть вид зупинки: лише доставка, доставка зі встановленням, доставка з вивезенням старого. Це вже несе власну інформацію: скільки триває зупинка, які навички потрібні бригаді, який чек-лист встановлення застосовується. Він змінюється незалежно, і бізнес ним керує. Це сутність, а не мітка.
Якщо я створюватиму об’єкт для кожного поняття, яке теоретично можна нормалізувати, я можу збудувати технічно прекрасну систему, якою нікому не приємно користуватися. Якщо перетворюватиму кожне поняття на список вибору, бо це легко, я дуже швидко загоню себе в кут.
Тож я питаю: чи має воно власну інформацію? Зв’язки? Чи змінюється незалежно? Чи треба керувати ним як даними? Чи може бізнесу зрештою знадобитися від нього більше, ніж мітка?
Ось запитання, які я справді ставлю на проєктній сесії.
Чи є більше однієї колонки інформації? Якщо значенню потрібні опис, тривалість, перелік навичок, власник, — це вже не мітка.
Скільки значень? Моє емпіричне правило — близько 20. Понад 20 значень список вибору починає розвалюватися, і час думати про об’єкт. Штати, яких п’ятдесят, — виняток, з яким ми живемо, а з країнами ще гірше; чесно, хтось любить списки вибору країн? Мене вони дратують.
Чи створюються значення з часом і ким? Додати значення до списку вибору — це зміна конфігурації, тобто робота адміністратора. Якщо бізнес додає значення щотижня, а ті, хто додає, — не адміністратори, список вибору ставить заявку перед кожним новим значенням.
Чи треба людям фільтрувати й звітувати за ним? Списки вибору для цього чудові. Lookup — не такі зручні. Кожен lookup додає крок: тип звіту проходить лише коротким ланцюжком пов’язаних об’єктів (користувацький тип звіту дозволяє щонайбільше чотири зв’язки між об’єктами), екран перетворюється на пов’язані списки в пов’язаних списках, а код ускладнюється.
Перелік значень часто починає життя як список вибору, а з часом заробляє собі окремий об’єкт. Дайте йому заробити.
Іноді масштаб змінює відповідь
Section titled “Іноді масштаб змінює відповідь ”Дизайн, що чудово працює з кількома тисячами записів, може поводитися зовсім інакше з мільйонами.
Тож не дивіться лише на діаграму. Знайте цифри.
Steve Trucking виконує близько мільйона доставок на рік при зростанні 30 відсотків на рік. Кожна доставка збирає близько восьми оновлень статусу. Це вісім мільйонів записів статусу цього року і близько 13,5 мільйона на рік до третього року. Додайте чотири-п’ять мільйонів фото на рік.
Та сама модель. Зовсім інша архітектура.
Значно глибше ми підемо в частині Архітектура в масштабі. Поки що пам’ятайте: обсяг може змінити рішення в моделюванні даних. Логічно правильний зв’язок не стає автоматично найкращим фізичним дизайном у кожному масштабі.
Різним споживачам потрібні різні форми
Section titled “Різним споживачам потрібні різні форми ”Досі ми думали про операційну систему. Координатори формують маршрути. Бригади закривають зупинки. Система змінюється в міру роботи бізнесу.
Але бізнес також хоче аналізувати роки історії. Які партнери й регіони запізнюються? Як змінився час доставки? Як часто встановлення потребує другого візиту?
Аналітичній системі може знадобитися та сама інформація, впорядкована інакше. Ви почуєте терміни сховище даних, факт, вимір і схема «зірка». Ми не розбираємо їх тут; у Steve Trucking це сховище Snowflake, і ми повернемося до нього пізніше в курсі.
Поки що: різним споживачам можуть знадобитися різні форми тієї самої правди.
ШІ додає ще одного споживача
Section titled “ШІ додає ще одного споживача ”А тепер є ще один споживач: ШІ.
Отримувач пише: «Де моя доставка?» ШІ-асистент міг би знайти таке:
Delivery 10427, Route 3312, Stop 7, Truck 117, Window 13:00–15:00.
Традиційний застосунок цілком задоволено пройде цими зв’язками. Але щоб відповісти отримувачеві, асистентові потрібен контекст, зібраний із кількох місць:
Ваша посудомийна машина від Redrock — сьома зупинка сьогоднішнього маршруту з розподільчого центру у Фініксі. Вантажівка за три зупинки від вас, і ви досі в межах свого вікна з 13:00 до 15:00.
Ми взяли інформацію з кількох пов’язаних сутностей і зібрали пласкіше, багате на контекст відображення для одного конкретного споживача.
Це не означає, що я знищую свою нормалізовану модель. І точно не означає «ШІ любить пласкі дані, тож покладімо все в один гігантський об’єкт». Не робіть цього.
Джерело правди лишається чистим. ШІ отримує відображення, збудоване для роботи, яку він виконує. Це та сама ідея, яку ми щойно бачили з аналітикою:
Одне джерело правди може підтримувати кілька форм для споживання.
Значно глибше в grounding і витягування даних ми підемо пізніше в курсі.
Не створюйте кількох правд
Section titled “Не створюйте кількох правд ”Тут є небезпека.
Якщо я скопіюю регіон на доставку для звітності, надішлю сплощену версію в Snowflake і збудую багату на контекст версію для ШІ-асистента, — котра правильна?
Це запитання потребує відповіді. Я хочу знати, де живе авторитетне значення. Усе інше — відображення цієї правди з певною метою.
Це місце — система обліку. Денормалізовані копії можуть бути добрими: екран зупинки, показники, Snowflake і контекст ШІ кожне краще робить свою роботу з формою, збудованою для нього, і звертатися до них — нормально. Але коли щось змінюється, зміна починається в системі обліку, зазвичай у реляційній моделі, і тече назовні до кожної копії. Ніхто не виправляє регіон у Snowflake чи не редагує контекст ШІ вручну. Виправляйте в джерелі й дайте зміні потекти.
І найважливіше це тоді, коли дані змінюються. Якщо розподільчий центр сьогодні переходить в інший регіон, чи мають доставки минулого місяця показувати новий регіон? Можливо. А можливо, ні. Для історії мені може знадобитися регіон, який був правдою на момент доставки. Це вже не проблема синхронізації. Це бізнес-рішення.
Ось чому денормалізація ніколи не має відбуватися випадково. Кожен продубльований факт порушує запитання про володіння, синхронізацію, історію й довіру. Це те саме мислення компромісами з розділу 1: знайте, що ви купуєте (легший екран, простіший звіт, кращий контекст для ШІ) і чим платите (дубльовані дані, синхронізація, складніше володіння правдою). А оскільки ми почали з чистої логічної моделі, можемо показати на кожну копію і сказати: «Я знаю, що це належить он туди. Я кладу сюди його відображення через ось цю вимогу». Це рішення, яке можна переглянути, оскаржити й записати, щоб наступний архітектор знав чому.
Що тут вирішує архітектор
Section titled “Що тут вирішує архітектор ”Розглядаючи денормалізацію, я вирішую:
- Де живе авторитетне джерело кожного бізнес-факту.
- Чи створює чиста модель реальні проблеми для користувачів, звітності, масштабу чи продуктивності.
- Чи варте простіше відображення дублювання і як копія лишається надійною.
- Чи мають історичні значення змінюватися, коли змінюється поточне джерело.
- Чи потрібна аналітиці чи ШІ інша форма даних, ніж операційній системі.
Відправна точка ніколи не змінюється: знайте, де місце правди. А потім, коли вимоги це виправдовують, надайте їй форми для доставки.
Далі в картину повертається Salesforce. Ми перетворимо спроєктоване на фізичну модель даних.
Додаткові матеріали
Section titled “Додаткові матеріали ”- Build Powerful Reports with Custom Report Types (opens in a new tab), Salesforce Admins, 24 червня 2019 р. (англійською, перевірено 2026-10-12): користувацький тип звіту «може охоплювати до 4 зв’язків між об’єктами».
- Unleash the hounds, terriers and lapdogs: American Kennel Club recognizes 3 more breeds (opens in a new tab), PBS NewsHour, 2 січня 2026 р. (англійською, перевірено 2026-10-12): «AKC визнає 205 порід, зокрема ці три новачки».
- Для розваги: FCI Breeds Nomenclature (opens in a new tab), Fédération Cynologique Internationale (перевірено 2026-10-12): перелік порід міжнародної федерації в десяти групах. Прогорніть його, і ви побачите, чому Порода заслужила окрему таблицю.