Модель данных — это скелет
Также доступно на 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 главы Думать как архитектор данных, глава 1 курса Data Architect. Каждый модуль самостоятелен. Назад: Думать как архитектор · Далее: Тест на обратимость
Вопрос, на который отвечает этот модуль: Почему модель данных важнее всего, что на ней построено, и как ее оценивать?
Когда я преподаю архитектуру данных, есть фраза, к которой я возвращаюсь снова и снова: модель данных — это скелет.
Модель данных — это скелет системы. Все остальное строится вокруг нее, и именно она держит вместе все остальное тело. Глядя на человека, вы не видите его костей, но именно они определяют, какого он роста, как он двигается и что может нести.
Подумайте обо всем, что мы строим во внедрении Salesforce. Мы строим автоматизацию вокруг модели данных. Мы пишем Apex, который с ней работает, и Flows, которые ее читают и обновляют. Мы строим интеграции, которые отправляют в нее данные и забирают их оттуда. Мы создаем на ней отчеты и аналитику и проектируем вокруг нее безопасность. И все чаще мы строим ИИ-агентов, которым нужно понимать эти данные и действовать на их основе. Все это зависит от структуры, лежащей в основе.
Вот почему так важно правильно выстроить модель данных с самого начала. Скелет можно поменять и потом. Но, скорее всего, это будет больно.
Начинайте с бизнеса
Заголовок раздела «Начинайте с бизнеса »Хорошая модель данных начинается с простого вопроса: что на самом деле нужно представить бизнесу? Не «какие объекты Salesforce у нас есть?». И уж точно не «что я могу быстро построить?».
Сначала мы пытаемся понять бизнес. Какие вещи в этом бизнесе важны? Как они связаны между собой? Кто ими владеет? Как они меняются со временем? Что нужно помнить и что общее для разных бизнес-процессов? Только поняв все это, стоит начинать переводить это в объекты, поля и связи.
Звучит очевидно. На практике очень легко сделать все наоборот. Кто-то узнает что-то похожее на возможность (Opportunity), обращение (Case) или актив (Asset) и сразу начинает проектировать вокруг этого. Иногда это именно то, что нужно. А иногда мы пытаемся забить квадратный колышек в круглое отверстие, и когда вокруг этого решения построено достаточно, вытащить колышек обратно становится очень дорого.
Вот вопрос, который я слышу постоянно. У бизнеса клиента может быть много пунктов доставки. Каждый пункт должен быть организацией (Account) или пользовательским объектом? Прежде чем ответить, заметьте, что вам нужно узнать сначала: что пункт доставки значит для этого бизнеса и что с ним происходит. Это и есть моделирование бизнеса до объектов. (Свой ответ я дам в главе 3.)
Поддерживать. Расти. Работать.
Заголовок раздела «Поддерживать. Расти. Работать. »Когда я смотрю на модель данных, я хочу, чтобы она прошла три теста: поддерживать бизнес, расти вместе с бизнесом и хорошо работать.
Поддерживать. Модель должна поддерживать то, чего бизнес на самом деле пытается добиться. Есть большая разница между моделью, которая технически может хранить данные, и моделью, которая действительно хорошо отражает бизнес. Если я постоянно добавляю странные поля, особые флаги, сложную автоматизацию и исключения, потому что модель не совсем подходит, я начинаю спрашивать себя, правда ли проблема в автоматизации. Может быть, неправильна модель. Хорошая модель должна делать бизнес понятнее, а не сложнее.
Расти. Говоря «расти», я имею в виду не только больше записей. Объем важен: десять тысяч записей и сто миллионов создают совсем разные проблемы. Но бизнес растет и в сложности. Он добавляет продукты, выходит на новые рынки, покупает компании, меняет процессы, добавляет каналы и подключает новые системы. Он обнаруживает, что то, что считалось одной вещью, на самом деле пять разных вещей. Модель, которая прекрасно работает сегодня, может стать ловушкой, если в ней нет места для завтрашнего дня. Поэтому я предпочитаю проекты, которые растут за счет добавления, а не те, что постоянно меняют уже существующее. Добавить что-то новое обычно проще, чем переопределить то, от чего зависят десятки других вещей.
Работать. Данные не просто лежат. Мы их записываем, ищем, запрашиваем, делимся ими, строим по ним отчеты и интегрируем их, а все чаще их еще и извлекают ИИ-системы как контекст, прежде чем действовать. Модель может красиво выглядеть на диаграмме и при этом быть ужасной в эксплуатации. Поэтому мы проектируем и то, как данные хранятся, и то, как данные будут использоваться.
И она должна продолжать работать. Работать в масштабе: когда растет число пользователей, когда растет объем данных, в реальных условиях и на пиках, в самый загруженный день года, а не в средний. И продолжать работать, когда случается что-то неожиданное.
Поддерживать. Расти. Работать. Мы будем возвращаться к этим трем тестам на протяжении всего курса.
Слишком плоская, слишком сложная или просто неправильная
Заголовок раздела «Слишком плоская, слишком сложная или просто неправильная »Я видел, как модели данных идут не туда тремя путями.
Первый — с самого начала выбрать не то. Мы берем стандартный объект, потому что он выглядит достаточно похожим, а потом годами добавляем исключения, потому что он никогда толком не подходил. Это и есть квадратный колышек.
Второй — сделать модель слишком плоской. Все складывается в один объект, и поначалу это кажется чудесно простым. Потом бизнес растет, и мы обнаруживаем, что у некоторых из этих вещей свой жизненный цикл, их может быть несколько экземпляров, им нужна своя безопасность или у них есть собственные связи. И вдруг мы изображаем связь «один ко многим» полями «Поле 1», «Поле 2» и «Поле 3» или все более сложными флагами и автоматизацией. Модель не оставила нам места для роста.
Третий — противоположная ошибка: мы чрезмерно нормализуем. Мы рисуем элегантную диаграмму, объект за объектом, каждое понятие идеально отделено. Технически красиво, практически мучительно. Пользователям трудно в этом разобраться, а макеты страниц и страницы Lightning, со связанными списками один за другим, начинают казаться бесконечно глубокими. Запросы усложняются, автоматизация проходит через все больше связей, отчеты строить труднее, и платформа делает больше работы, чтобы ответить на обычные бизнес-вопросы.
Так что же правильно — плоская модель или нормализованная? Формулы нет. Вы держите в голове картину оптимальной модели и понимаете компромиссы по мере того, как от нее отходите. В этом и есть искусство архитектуры, и мы вернемся к нему в модуле 4 и в следующей главе, где научимся моделировать. А пока признайте, что сама структура — это архитектурное решение.
Осторожнее с изменением скелета
Заголовок раздела «Осторожнее с изменением скелета »Когда система уже работает, я становлюсь очень осторожным с фундаментальными изменениями модели данных.
Допустим, текстовое поле существует уже много лет, и кто-то говорит: «Мы его уже так не используем. Давайте сделаем его числовым». Звучит как изменение поля. Но что от этого поля зависит? Flows, Apex, отчеты, интеграции, конвейеры данных, внешние приложения, ИИ-агенты. И что будет с историческими данными? Сама платформа не даст поменять тип поля, пока на него ссылаются код или flows, и это говорит о том, насколько далеко заходит такое изменение.
Иногда правильный ответ — не менять то, что уже есть. В зависимости от серьезности изменения я скорее создам что-то новое, обдуманно проведу миграцию и выведу старую структуру из употребления:
Добавляйте, а не меняйте. Выводите из употребления, а не удивляйте.
Salesforce даже дает способ сказать это в метаданных: Field Usage (использование поля) можно установить в DeprecateCandidate — «планируется к выводу из употребления и больше не используется». Это помечает поле для всех, кто читает объект; поле при этом не скрывается, так что вывести его из употребления — по-прежнему решение, которое вы должны выполнить сами.
Ведь как только от чего-то зависят другие части архитектуры, изменить его смысл бывает гораздо опаснее, чем изменить его имя. Хуже всего — поле, имя которого остается прежним, а содержимое меняется: все, что ниже по потоку, по-прежнему доверяет имени.
Даже такая простая вещь, как флажок 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) и другие поля классификации.