Проектируйте до третьей нормальной формы, затем отступите
Также доступно на 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
Вопрос, на который отвечает этот модуль: Когда стоит намеренно отойти от чистой нормализованной модели?
В прошлом модуле я сказал вам проектировать под третью нормальную форму.
А теперь я скажу вам ее нарушить.
Иногда.
Это важное различие. Есть большая разница между тем, чтобы случайно построить беспорядочную модель данных, и тем, чтобы намеренно денормализовать чистую. Если вы изначально не понимаете, где место данным, копирование их куда-то еще — это не архитектура. Это просто дублирование.
Но когда я понимаю чистую логическую модель, я могу принять осознанное решение придать данным другую форму для людей и систем, которые их потребляют.
Проектируйте до третьей нормальной формы, где это осуществимо. Затем отступайте, когда необходимо.
Обратите внимание, чего в этой фразе нет. В ней не сказано, что третью нормальную форму легче понять. Иногда ее понять труднее: полностью нормализованная модель может разбросать одну бизнес-идею по пяти объектам, и людям, которые ею пользуются, приходится собирать ее заново в голове. Нормализация говорит мне, где место каждому факту. Она не обещает, что эта форма проще всего читается, используется или ложится в отчеты. Именно поэтому умение отступить — это навык проектирования, а не провал.
Начните с того, чтобы смоделировать истину. Затем решите, в каком виде эту истину нужно доставлять.
Сидеть, стоять, моделировать
Заголовок раздела «Сидеть, стоять, моделировать »Вернемся к собакам, и на этот раз примем несколько осознанных решений.
Порода: список выбора или отдельная таблица? Прогоните ее через вопросы, которые я дам вам дальше в этом модуле. Есть ли больше одного столбца информации? Да: как минимум размер. Сколько значений? Кинологические клубы признают несколько сотен пород (один только Американский клуб собаководства (American Kennel Club) насчитывает 205), это далеко за пределами моего практического правила примерно в 20. Значит, Порода заслуживает своей таблицы, и каждая собака ссылается на свою породу. Это закрывает вопрос, который мы несем с модуля 1: Порода — отдельный прямоугольник.
Уровень навыка: список выбора. Учится, Хорошо, Эксперт. Три метки, больше о них сказать нечего, и они не изменятся. Именно для этого список выбора и существует.
Сколько трюков знает каждая собака? Ответ уже есть в модели: посчитайте записи Трюк собаки для этой собаки. Но дрессировщик хочет видеть это число в каждом отчете, сортировать и фильтровать по нему, не строя отчет по двум таблицам. Поэтому я отступаю и держу счетчик Освоенные трюки (Tricks Known) прямо у собаки. Это копия. Истина по-прежнему живет в Трюке собаки; счетчик — ее представление, и он должен идти с ней в ногу. Salesforce дает нам чистый способ сделать именно это, и мы увидим его в модуле 6.
А теперь поворот: школа для собак начинает принимать кошек. Что делаем? Вариант первый: добавить таблицу Кошка рядом с таблицей Собака и Трюк кошки рядом с Трюком собаки. Все удваивается: по два каждого экрана, по два каждого отчета, а в тот день, когда начнут принимать кроликов, — по три. Вариант второй: отойти на шаг и заметить, что у кошки есть владелец, возможно заводчик, порода, дата рождения и, если хватит терпения, трюк-другой. Те же факты и те же связи, что у собаки. Поэтому мы обобщаем: Питомец (Pet) с Видом (Species) — собака или кошка. Каждая порода тоже относится к виду, и именно там вид по-настоящему живет: лабрадор — это собака. Питомец намеренно несет копию, чтобы каждый экран и отчет мог начинаться с «собака или кошка?», не заглядывая в породу. Еще одна осознанная копия, и в модуле 6 у нее появится собственная работа.
Это проектирование под изменения, и это компромисс. Обобщите слишком рано — и все превратится в расплывчатую «Вещь» с полем типа, которое никто не понимает. Я обобщаю, когда бизнес действительно приносит мне второй вид и у этих двух почти все общее, как у собак и кошек здесь. Если бы кошкам нужны были совсем другие факты, я бы подумал дважды.
Теперь такие же решения в Steve Trucking, где ставки выше.
Самая чистая модель — не всегда лучшая система
Заголовок раздела «Самая чистая модель — не всегда лучшая система »Представьте бригаду на остановке. У доставки есть позиции. У установки есть чек-лист. На каждом шаге нужны фотографии. Получатель расписывается.
Нормализованная модель прекрасна: доставка → позиция доставки → чек-лист установки → фото, и все на своем месте.
Потом я сажусь с людьми, которые ею реально пользуются. Бригада закрывает около десяти остановок в день, на подъездных дорожках, часто без связи. Если моя прекрасная модель гонит их через лабиринт экранов и связанных списков, чтобы закрыть одну остановку, у меня архитектурная проблема.
Модель данных — не единственное, что мы проектируем.
Мы проектируем систему.
Иногда побеждает пользовательский опыт
Заголовок раздела «Иногда побеждает пользовательский опыт »Это одна из причин, по которым я иногда отступаю от идеально нормализованной модели: пользовательский опыт.
Возможно, понятие технически могло бы быть отдельной сущностью, но его выделение добавляет сложность, которая дает очень мало пользы. Возможно, родитель с несколькими уровнями дочерних записей академически чист, но вводить и поддерживать его — мучение. Возможно, понятие маленькое, стабильное и используется в основном для выбора.
Здесь я перестаю спрашивать только «Где теоретически место этому факту?» и начинаю спрашивать «Как на самом деле будут пользоваться этой системой?»
Это не значит, что каждая жалоба на лишний клик расплющивает модель. Это значит, что удобство использования — законный вход для архитектурного решения.
Иногда побеждает отчетность
Заголовок раздела «Иногда побеждает отчетность »Отчетность — еще одна частая причина.
Каждый розничный партнер хочет оценочную карту: своевременные доставки по регионам, по месяцам. В чистой модели доставка знает свой распределительный центр, а DC знает свой регион. Технически мы можем пройти по этой цепочке.
Но может ли инструмент отчетности? Могут ли люди, которые сами строят свои отчеты? Могут ли они ответить на вопрос без архитектуры отчетности, которая сложнее самого вопроса?
Вот тогда я, возможно, скопирую или выведу регион в доставку — ближе к тому месту, где его потребляют.
Теперь я ввел дублирование. Значит, нужен еще один вопрос: кому принадлежит истина?
Если исходное значение меняется, что происходит с моей копией? Должна ли она измениться? Или сохранить то, что было верно в момент доставки? Это разные требования.
Денормализация не устраняет сложность.
Она ее перемещает.
Lookup или список выбора?
Заголовок раздела «Lookup или список выбора? »Вот пример поменьше, с которым администраторы Salesforce сталкиваются постоянно. Пользователю нужно выбрать из набора значений. Создать еще одну сущность и связаться с ней или использовать список выбора?
Возьмем статус доставки: запланирована, загружена, в пути, прибывает, доставлена, установлена, исключение, возвращена. Короткий стабильный список меток. Список выбора — именно то, что мне нужно.
Теперь возьмем вид остановки: только доставка, доставка с установкой, доставка с вывозом старой техники. У этого есть собственная информация: сколько длится остановка, какие навыки нужны бригаде, какой чек-лист установки применяется. Он меняется независимо, и им управляет бизнес. Это сущность, а не метка.
Если я создам объект для каждого понятия, которое теоретически можно нормализовать, я могу построить технически прекрасную систему, которой никому не нравится пользоваться. Если я превращу каждое понятие в список выбора, потому что это легко, я очень быстро загоню себя в угол.
Поэтому я спрашиваю: есть ли у него собственная информация? Связи? Меняется ли оно независимо? Нужно ли управлять им как данными? Может ли бизнесу со временем понадобиться от него больше, чем метка?
Вот вопросы, которые я действительно задаю на сессии проектирования.
Есть ли больше одного столбца информации? Если значению нужно описание, длительность, список навыков, владелец, — это уже не метка.
Сколько значений? Мое практическое правило — около 20. После 20 значений список выбора начинает разваливаться, и пора думать об объекте. Штаты, которых пятьдесят, — исключение, с которым мы живем, а со странами еще хуже; честно, кто-нибудь любит списки выбора стран? По-моему, они раздражают.
Создаются ли значения со временем и кем? Добавление значения в список выбора — это изменение конфигурации, то есть работа администратора. Если бизнес добавляет значения каждую неделю, а добавляют их не администраторы, список выбора ставит заявку перед каждым новым значением.
Нужно ли людям фильтровать и строить отчеты по нему? Для этого списки выбора отлично подходят. Связи lookup не так удобны. Каждый lookup добавляет переход: тип отчета проходит только по короткой цепочке связанных объектов (пользовательский тип отчета допускает не больше четырех связей между объектами), экран превращается в связанные списки внутри связанных списков, а код становится сложнее.
Список значений часто начинает жизнь как список выбора и со временем заслуживает собственный объект. Пусть заслужит.
Иногда масштаб меняет ответ
Заголовок раздела «Иногда масштаб меняет ответ »Проект, который прекрасно работает с несколькими тысячами записей, может вести себя совсем иначе с миллионами.
Поэтому не смотрите только на диаграмму. Знайте цифры.
Steve Trucking делает около миллиона доставок в год с ростом 30 % в год. Каждая доставка собирает около восьми обновлений статуса. Это восемь миллионов записей статуса в этом году и около 13,5 млн в год к третьему году. Добавьте четыре-пять миллионов фотографий в год.
Та же модель. Совсем другая архитектура.
Гораздо глубже мы разберем это в части «Архитектура в масштабе». А пока запомните: объем может изменить решение по моделированию данных. Связь, которая логически верна, не становится автоматически лучшим физическим решением в любом масштабе.
Разным потребителям нужны разные формы
Заголовок раздела «Разным потребителям нужны разные формы »До сих пор мы думали об операционной системе. Координаторы распределяют доставки по маршрутам. Бригады закрывают остановки. Система меняется по мере того, как работает бизнес.
Но бизнес также хочет анализировать годы истории. Какие партнеры и регионы опаздывают? Как менялось время доставки? Как часто установке нужен второй визит?
Аналитической системе та же информация может понадобиться в другой организации. Вы услышите такие термины, как хранилище данных (data warehouse), факт, измерение и схема «звезда» (star schema). Здесь мы их не разбираем; в Steve Trucking это хранилище Snowflake, и мы вернемся к нему позже в курсе.
А пока: разным потребителям могут быть нужны разные формы одной и той же истины.
ИИ добавляет еще одного потребителя
Заголовок раздела «ИИ добавляет еще одного потребителя »А теперь появился еще один потребитель: ИИ.
Получатель пишет: «Где моя доставка?» ИИ-ассистент мог бы найти вот это:
Доставка 10427, маршрут 3312, остановка 7, грузовик 117, окно 13:00–15:00.
Традиционному приложению вполне удобно идти по этим связям. Но чтобы ответить получателю, ассистенту нужен контекст, собранный из нескольких мест:
Ваша посудомоечная машина Redrock — седьмая остановка сегодняшнего маршрута из распределительного центра в Финиксе. Грузовик в трех остановках от вас, и вы все еще в своем окне 13:00–15:00.
Мы взяли информацию из нескольких связанных сущностей и собрали более плоское, насыщенное контекстом представление для одного конкретного потребителя.
Это не значит, что я уничтожаю свою нормализованную модель. И уж точно не значит: «ИИ любит плоские данные, так что сложим все в один гигантский объект». Не делайте так.
Источник истины остается чистым. ИИ получает представление, построенное под ту работу, которую он делает. Это та же идея, что мы только что видели с аналитикой:
Один источник истины может поддерживать несколько форм для потребления.
Гораздо глубже в заземление на данные (grounding) и извлечение мы погрузимся позже в курсе.
Не создавайте несколько истин
Заголовок раздела «Не создавайте несколько истин »Здесь есть опасность.
Если я копирую регион в доставку для отчетности, отправляю плоскую версию в Snowflake и строю насыщенную контекстом версию для ИИ-ассистента, какая из них верна?
На этот вопрос нужен ответ. Я хочу знать, где живет авторитетное значение. Все остальное — представление этой истины для определенной цели.
Это место — система записи (system of record). Денормализованные копии могут быть хороши: экран остановки, оценочная карта, Snowflake и контекст ИИ лучше делают свою работу, когда у них форма, построенная под них, и обращаться к ним — нормально. Но когда что-то меняется, изменение начинается в системе записи, обычно в реляционной модели, и расходится наружу ко всем копиям. Никто не исправляет регион в Snowflake и не правит контекст ИИ вручную. Исправьте в источнике и дайте изменению растечься.
И важнее всего это тогда, когда данные меняются. Если распределительный центр сегодня переходит в другой регион, должны ли доставки прошлого месяца показывать новый регион? Может быть. А может, и нет. Для истории мне может понадобиться регион, который был верен в момент доставки. Это уже не проблема синхронизации. Это бизнес-решение.
Вот почему денормализация никогда не должна происходить случайно. Каждый продублированный факт поднимает вопросы о владении, синхронизации, истории и доверии. Это мышление компромиссами из главы 1: знайте, что вы покупаете (более простой экран, более простой отчет, лучший контекст для ИИ), и чем платите (дублирование данных, синхронизация, более сложное владение истиной). А поскольку мы начали с чистой логической модели, мы можем указать на каждую копию и сказать: «Я знаю, что этому место вон там. Я кладу сюда его представление из-за вот этого требования». Такое решение можно проверить, оспорить и записать, чтобы следующий архитектор знал почему.
Что здесь решает архитектор
Заголовок раздела «Что здесь решает архитектор »Рассматривая денормализацию, я решаю:
- Где живет авторитетный источник каждого бизнес-факта.
- Создает ли чистая модель реальные проблемы для пользователей, отчетности, масштаба или производительности.
- Стоит ли более простое представление дублирования и как копия остается достойной доверия.
- Должны ли исторические значения меняться, когда меняется текущий источник.
- Нужна ли аналитике или ИИ другая форма данных, чем операционной системе.
Отправная точка не меняется никогда: знайте, где место истине. Затем, когда требования это оправдывают, придайте ей форму для доставки.
Дальше в картину возвращается Salesforce. Мы превратим то, что спроектировали, в физическую модель данных.
Дополнительно
Заголовок раздела «Дополнительно »- 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): список пород международной федерации, разбитый на десять групп. Пролистайте его, и вы поймете, почему Порода заслужила свою таблицу.