Воплотите модель в 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) с типом записи «Заводчик». Владелец — тоже организация или персональная учетная запись, с типом записи «Владелец». Два вида одного и того же стандартного объекта, рядом в верхней части диаграммы, ровно там, где они были с модуля 1.

У чего нет стандартного дома? Питомец, Порода, Трюк, Трюк питомца и Оценка трюка становятся пользовательскими объектами. А помните вид, который мы скопировали в питомца в модуле 5? Здесь у него появляется работа: он становится типом записи Питомца — «Собака» или «Кошка». Один объект с двумя типами записей, у каждого свой макет страницы и свои значения списков выбора, вместо объекта Собака и объекта Кошка.

Какие связи — 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), контакт или просто информация в доставке? Как следует мы ответим на него в следующей главе.

Важное слово по-прежнему — может. Не предполагайте реализацию только потому, что бизнес-понятие звучит как объект Salesforce. Именно поэтому мы сначала построили логическую модель: она дает нам то, с чем можно сверять проект в Salesforce.

Бизнес-сущность не означает автоматически пользовательский объект

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

Атрибуты становятся физическими полями

Тот же переход происходит с атрибутами. У нашего логического грузовика есть бортовой номер, VIN, марка, модель, год выпуска, госномер и статус. Теперь мы решаем, как они существуют физически: какому объекту принадлежат, какие типы полей используют, какие обязательны, какие должны быть уникальными, какие являются внешними идентификаторами, каким нужна проверка, какие вычисляются, а не хранятся, и какие конфиденциальны. На логическом уровне мы спрашивали, что означает грузовик. На физическом уровне мы спрашиваем, как Salesforce будет представлять грузовик. Это разные вопросы.

Click to enlarge

Связи становятся решениями платформы

Все время, которое мы потратили на связи, окупается здесь. Мы уже знаем, является ли каждая связь «один к одному», «один ко многим» или «многие ко многим», обязательна она или нет и важна ли ее история. Теперь мы решаем, как Salesforce ее реализует: lookup, master-detail или связующий объект Salesforce, а может, и связующий объект со своими атрибутами, потому что, как мы выяснили, у самой связи может быть бизнес-смысл.

Вспомните назначение бригады. Мы могли бы начать эту главу словами: «Давайте создадим связующий объект 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 дочерних». Это рекомендация, связанная с data skew (перекосом данных), а не жесткий лимит; глава 7 разбирает это подробнее.
• Roll-Up Summary Field (opens in a new tab), Salesforce Help (на английском, проверено 2026-10-12): поле сводки (roll-up summary) считает или суммирует подчиненные записи через связь master-detail.