Связывание — это не мастеринг
Также доступно на 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 курса Data Architect, Часть 1: Как стать архитектором данных. Назад: Качество данных и управление ими.
«Нам нужен единый источник истины». Это одна из самых повторяемых фраз в архитектуре — и одна из наименее продуманных. Для чего? Возьмем одну организацию (Account). ERP может владеть ее юридическим названием, адресом для счетов и кредитным лимитом; Salesforce — ее менеджером по работе с клиентом и уровнем поддержки; платформа согласий — ее маркетинговыми предпочтениями. Три источника полномочий в одной записи, и это нормально. Поэтому, когда мне говорят: «Salesforce — наш единый источник истины о клиенте», мой следующий вопрос всегда один: какой истины?
Эта глава о том, как отвечать на этот вопрос осознанно. Полномочия назначаются атрибут за атрибутом. Связать записи — еще не значит провести их мастеринг. И Salesforce дает разные инструменты для разных задач: управление дубликатами и слияние внутри одного org; разрешение идентичности (identity resolution) в Data 360 — для единого представления по многим источникам; отдельную MDM-платформу — когда значения нужно решить один раз и отправить обратно повсюду. В конце — контрольная точка 1, где вся часть 1 сходится на Steve Trucking.
Изображение создано с помощью ИИ.
Позиции этой главы
Заголовок раздела «Позиции этой главы »- Истина для каждого атрибута. Спрашивайте, где каждый элемент данных создается, редактируется и используется по ссылке и как быстро он меняется. Показывайте внешние полномочия в схеме системным префиксом, например
sap_илиerp_. - С потенциальными клиентами все иначе. Они живут в Salesforce еще до того, как о них узнает ERP; полномочия ERP начинают действовать после конверсии.
- Реестр — норма на проектах Salesforce, затем идут консолидация и сосуществование; чистое централизованное MDM встречается редко.
- Сливайте, только когда есть явный победитель. Сохраняйте дубликаты из внешних загрузок, если вам может понадобиться проследить их происхождение: слияние уничтожает эту историю. И решите, что будет с дочерними записями: перенести их, не загружать или оставить на неактивной записи.
- Унифицированный профиль — это карта; золотая запись — это решение. Людей это может сбивать с толку: разрешение идентичности создает унифицированного индивида, но не золотую запись.
- Строгость сопоставления — это решение о риске. Там, где смешение записей обходится дорого, сознательно сопоставляйте меньше.
- Три инструмента для трех задач: слияние, разрешение идентичности, MDM.
- У иерархий несколько мастеров. Решайте вопрос полномочий ветвь за ветвью.
- «Самое сложное — это двунаправленные потоки». Двусторонняя интеграция не создает двух мастеров. Решите, какие поля путешествуют вместе как одна транзакция, до первого конфликта.
- Сделайте мастер-данные видимыми. Возможность редактирования определяет поле, которое говорит, что это мастер-данные (ключ ERP или флаг), а не тип записи.
- Мы не управляем ERP. Мы управляем тем, как представляем их в Salesforce: один клиент в двух ERP — это иерархия, равноправные записи или одна организация с дочерней записью для каждой ERP, и выбор зависит от того, насколько хорошо клиент синхронизирует свои ERP.
Три инструмента для трех задач
Заголовок раздела «Три инструмента для трех задач »| Задача | Инструмент | Что он делает с источниками |
|---|---|---|
| Дубликаты внутри одного org, с явным победителем | Управление дубликатами и слияние | Сливает до трех записей; остальные попадают в корзину (Recycle Bin) |
| Одна идентичность и единое представление по многим источникам | Разрешение идентичности в Data 360 | Связывает их, ни одну не меняя (реестр) |
| Одно управляемое значение, отправленное обратно в каждую систему | Отдельная MDM-платформа | Решает, каким быть значению, и распространяет его (сосуществование или централизованная модель) |
Путь по этой главе
Заголовок раздела «Путь по этой главе »Шесть модулей и задание, каждый самостоятелен.
- Один источник истины для каждого атрибута. Карта полномочий, гибридная золотая запись и сигналы доверия.
- Четыре способа управлять мастер-данными. Реестр, консолидация, сосуществование и централизованная модель — и почему общая модель не означает общей истины.
- Сопоставление, слияние и правила выживания. Цена ложного совпадения, что на самом деле делает слияние в Salesforce (и что происходит с дочерними записями), и правила выживания значений как заявление о доверии.
- Карта — это не решение. Правила сопоставления и методы сопоставления, правила согласования и почему унифицированный профиль — не золотая запись.
- Когда полномочия разделены. Запросы и обновления, циклы и конфликты, иерархии с несколькими мастерами и один клиент в двух ERP.
- Задание контрольной точки 1, затем Контрольная точка 1. Steve Trucking: как бы я это спроектировал. Сначала попробуйте выполнить задание: нарисуйте и защитите дизайн части 1, потом сравните его с моим и посмотрите, что изменилось по сравнению с ландшафтом из главы 4.
Закончив, проверьте себя с помощью учебного пособия к главе: чек-лист для экзамена, привычки за его пределами, ключевые термины и несколько вопросов. Оно завершает часть 1; учебное пособие к части 1 собирает все шесть глав вместе.
Что здесь решает архитектор
Заголовок раздела «Что здесь решает архитектор »- Какая система авторитетна для каждого важного атрибута и как это отражается в модели.
- Какой стиль мастеринга подходит каждому домену данных и сколько полномочий получает слой мастеринга.
- Когда сливать, а когда связывать, и кто владеет каждым правилом выживания значений.
- Насколько строгим должно быть сопоставление, исходя из цены ложного совпадения.
- Где двусторонним данным и общим иерархиям нужны явные границы.
За пределами экзамена: агентам нужна одна идентичность, с которой они работают, и это повышает ставки в обе стороны. Избыточное сопоставление превращается в инцидент конфиденциальности, а агент, который «обновляет клиента», должен писать в систему записи каждого атрибута, а не в унифицированный профиль. Каждый модуль заканчивается тем, что меняет ИИ.
Дополнительно
Заголовок раздела «Дополнительно »- Salesforce Architects, Data 360 Architecture (opens in a new tab) (на английском, проверено 2026-10-14).
- Salesforce Help, Considerations for Merging Duplicate Accounts (opens in a new tab), Identity Resolution Match Methods (opens in a new tab) и Identity Resolution Reconciliation Rules (opens in a new tab) (на английском, проверено 2026-10-14).
Далее: часть 2 начинается с главы Проектирование для масштаба (coming soon).