Мастер-данные и идентичность
Также доступно на 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; эта страница поможет проверить, что запомнилось.
Об этом учебном пособии. Оно построено только на материалах этого курса и на списке целей из опубликованного руководства Salesforce по экзамену. Оно никогда не основано на реальных экзаменационных вопросах и не претендует на знание того, что будет на экзамене. Если вы сдавали экзамен, пожалуйста, не присылайте мне вопросы из него: соглашение о сертификации запрещает ими делиться, а заучивание ответов — все равно неправильный путь к тому, чтобы стать архитектором.
Эта глава охватывает раздел экзамена Master Data Management (5 %) и единое представление клиента из раздела Salesforce Data Management. По весу раздел небольшой, но его идеи (полномочия, сопоставление, правила выживания значений) появляются внутри многих других сценариев. Цифры платформы меняются, поэтому проверяйте актуальные значения, прежде чем на них полагаться.
Для экзамена
Заголовок раздела «Для экзамена »Отмечайте пункты по ходу. Каждый ведет туда, где эта тема разбирается.
MDM-2: золотая запись и система истины
- Я знаю, что полномочия назначаются для каждого атрибута, а не для каждой записи: у одной организации могут быть поля, которые ведутся в ERP, и поля, которые ведутся в Salesforce. (Истина принадлежит атрибуту)
- Я спрашиваю, где каждый атрибут создается, редактируется и используется по ссылке, и какова задержка его изменений. (Где создается, редактируется, используется — и как быстро?)
- Я умею строить карту полномочий и знаю, что бизнес-владелец и авторитетная система — не одно и то же. (Постройте карту полномочий)
- Я знаю, что полномочия могут меняться в течение жизненного цикла (потенциальный клиент в Salesforce становится клиентом под управлением ERP) и что копия — это не полномочия. (Полномочия меняются в течение жизненного цикла, Копия — это не полномочия)
MDM-1: методы MDM
- Знать к экзамену: я знаю четыре стиля внедрения MDM — реестр, консолидацию, сосуществование и централизованную модель: что каждый из них централизует и отправляет ли значения обратно. (Все четыре рядом)
- Я различаю четыре стиля MDM — реестр, консолидацию, сосуществование и централизованную модель — и выбираю самый легкий, который решает проблему. (Все четыре рядом)
- Я знаю, что каноническая модель данных гармонизирует структуру, но не решает вопрос полномочий. (Общая модель — это не общая истина)
- Я знаю порядок: гармонизация, затем сопоставление, затем консолидация. (Гармонизируйте, затем сопоставляйте, затем консолидируйте)
- Я знаю, что пороги отражают терпимость к ошибке, а обогащению нужно происхождение. (Пороги, проверка и обогащение)
- Знать к экзамену: я знаю управление иерархиями: иерархию строит Parent Account (представление в Lightning показывает до 2 000 организаций, без персональных учетных записей), у иерархий часто несколько мастеров по ветвям, а у компании может быть несколько законных иерархий. (Иерархии — тоже мастер-данные, Одна иерархия, несколько мастеров)
MDM-3: выбор побеждающих атрибутов
- Я держу сопоставление, слияние и правила выживания значений раздельно. (Сопоставление, слияние и правила выживания)
- Я знаю правила выживания значений: самое свежее, самое частое, приоритет источника — и что у каждого правила должен быть владелец. (Правила выживания: какое значение побеждает?)
- Я знаю, что совпадение не требует слияния, и сливаю записи, только когда есть явный победитель, заранее решив, что будет с дочерними записями. (Совпадение не требует слияния, Мое правило слияния: явный победитель)
- Знать к экзамену: я знаю, что делает слияние организаций в Salesforce: до трех записей, одна основная, сохраняются Created By и Created Date самой старой, остальные — в корзину (Recycle Bin), а объекты точек контакта у персональных учетных записей не сливаются. (Что на самом деле делает слияние в Salesforce)
SDM-3: единое представление клиента
- Я знаю, что разрешение идентичности в Data 360 связывает исходные профили в унифицированный профиль и сохраняет обратные связи: ближе всего к реестру. (Разрешение идентичности отвечает на вопрос «кто?»)
- Знать к экзамену: я знаю правила сопоставления Data 360: в правиле должны совпасть все критерии, совпасть может любое правило; больше критериев — для точности, меньше — для консолидации. (Правила сопоставления)
- Я знаю методы сопоставления (Exact, Exact Normalized, Fuzzy с тремя уровнями точности): менее точный метод повышает консолидацию — и риск ложных совпадений. (Правила сопоставления)
- Знать к экзамену: я знаю, что правила согласования (Last Updated, Most Frequent, Source Priority) решают, что показывает унифицированный профиль, но не меняют источники; точки контакта не согласуются. (Согласование — все еще не мастеринг)
- Я умею выбрать для задачи между управлением дубликатами, разрешением идентичности и отдельной MDM-платформой. (Три инструмента для трех задач)
MDM-4 и двусторонние данные
- Я знаю, что двусторонние данные не означают двух мастеров: правка в Salesforce поля, которым владеет ERP, — это запрос, поэтому проектирую запрос → проверка → принятие → публикация с состоянием ожидания. (Двусторонние данные не означают двух мастеров, Когда мастер говорит «нет»)
- Я знаю, как избегать циклов и конфликтов: отличать исходное изменение от его эха и решать, какие поля путешествуют вместе как одна транзакция. (Циклы и конфликты)
- Для одного клиента в двух ERP я умею выбрать иерархию, равноправные организации или одну организацию с дочерней записью для каждой ERP — в зависимости от того, насколько хорошо клиент синхронизирует свои ERP. (Один клиент, две ERP, Спросите, как они синхронизируют свои ERP)
Контрольная точка 1: собираем часть 1 воедино
- Знать к экзамену: я знаю, какие внешние лицензии поддерживают стандартный общий доступ: Customer Community Plus и Partner Community, которым нужны роли для внешних пользователей; Customer Community использует наборы общего доступа (sharing sets). (Кто что видит и кому нужна лицензия)
За пределами экзамена
Заголовок раздела «За пределами экзамена »Экзамен — это пол, а не потолок. Вот привычки из этой главы, которые нужны архитектору, независимо от того, спросят ли о них когда-нибудь на экзамене.
- «Единый источник истины»: какой истины? Это архитектура истины, а не одна запись.
- Делайте полномочия видимыми в схеме: префикс для полей, которыми владеет другая система.
- Доверию нужно больше, чем значение: источник, дата последнего подтверждения, кто его изменил.
- Начинайте с проблемы, а не с MDM-продукта. MDM — это бизнес-решение о полномочиях.
- Связывание — это не мастеринг.
- Там, где ложные совпадения дорого обходятся, сознательно сопоставляйте меньше.
- Сохраняйте дубликаты из внешних загрузок, если вам может понадобиться проследить их происхождение.
- Унифицированный профиль — это карта. Золотая запись — это решение.
- Отображение — это не полномочия.
- Унификация идентичности не стирает границы безопасности.
- Самое сложное — это двунаправленные потоки. Разделенные полномочия — не проблема; проблема — неясные полномочия.
- Никогда не позволяйте отклоненному запросу превратиться в конкурирующую истину.
- Поле, которое говорит, что это мастер-данные, определяет возможность редактирования, а не тип записи.
- Мы не управляем ERP. Мы управляем тем, как представляем их в Salesforce.
Ключевые термины
Заголовок раздела «Ключевые термины »| Термин | В одной строке |
|---|---|
| Управление мастер-данными (MDM) | Установление авторитетной идентичности и значений ключевых данных во всех системах и управление ими |
| Карта полномочий (authority map) | Для каждого атрибута: кто его создает, кто владеет решением, какая система авторитетна, кто может его менять |
| Золотая запись | Управляемое решение о том, какие значения авторитетны |
| Гибридная золотая запись | Запись, часть атрибутов которой ведется в другой системе и копируется внутрь, а часть принадлежит локальной системе |
| Реестр (registry) | MDM, которое связывает записи как одну сущность, не меняя источники |
| Консолидация | MDM, которое объединяет данные централизованно, обычно для аналитики, не отправляя их обратно |
| Сосуществование (coexistence) | MDM, которое решает, каким будет мастер-значение, и публикует его обратно в источники |
| Централизованное MDM | MDM, при котором управляемые данные создаются в мастере и распространяются |
| Каноническая модель данных | Согласованная корпоративная форма понятия, через которую системы отображаются друг на друга |
| Гармонизация | Приведение значений к сравнимому виду: стандартные форматы, коды и сокращения |
| Сопоставление | Решение о том, представляют ли записи одно и то же |
| Правила выживания значений (survivorship) | Правила, определяющие, какое значение побеждает, когда источники расходятся |
| Основная запись (principal) | При слиянии в Salesforce — запись, которая выживает и сохраняет свои скрытые поля и поля только для чтения |
| Метод сопоставления (match method) | Как критерий сопоставления в Data 360 сравнивает значения: точно, точно после нормализации или нечетко |
| Разрешение идентичности (identity resolution) | Сопоставление исходных профилей в унифицированные профили в Data 360 |
| Унифицированный профиль | Набор ключей, связывающих исходные записи, которые представляют одного человека или одну компанию |
| Правила согласования (reconciliation rules) | Правила Data 360, определяющие, какое значение показывает унифицированный профиль |
| Иерархия с несколькими мастерами (split-mastered) | Иерархия, ветвями которой владеют разные системы |
Проверьте себя
Заголовок раздела «Проверьте себя »Короткие сценарии в стиле курса. Решите, каким будет ваш ответ, прежде чем его открыть.
1. «Salesforce — наш единый источник истины о клиенте». Что вы спросите?
Какой истины? Полномочия назначаются для каждого атрибута: ERP может владеть юридическим названием, адресом для счетов и кредитным лимитом, а Salesforce — менеджером по работе с клиентом и уровнем сопровождения. Постройте карту полномочий. Перечитайте Истина принадлежит атрибуту.
2. Агентам поддержки нужно видеть, что контакт в Salesforce — тот же человек, который купил что-то онлайн. Менять системы никому не нужно. Какой стиль MDM?
Реестр: связать записи как одну идентичность, не меняя источники, — именно это делает разрешение идентичности в Data 360. Выбирайте самый легкий шаблон, который решает проблему. Перечитайте Реестр: скажите мне, кто есть кто.
3. Для всех полей задано правило выживания «побеждает самое свежее». Кто-то меняет копию в Salesforce юридического названия, которым владеет ERP. Что произойдет и что здесь не так?
Победит самое новое значение, и копия перекроет полномочия. «Самое свежее» — это заявление о доверии, которое подходит одним атрибутам (мобильный номер) и не подходит другим. Там, где карта полномочий говорит, что полем владеет ERP, побеждает ERP. Перечитайте Правила выживания: какое значение побеждает?.
4. Импортированы записи клиентов из унаследованной системы, и они совпадают с существующими организациями. Сливать?
Осторожно. Совпадение не требует слияния, а слияние уничтожает унаследованные ID и старые значения, которые вам может понадобиться проследить. Свяжите их, если только нет явного победителя и дубликат не добавляет ничего нужного. Перечитайте Мое правило слияния: явный победитель.
5. Унифицированный профиль в Data 360 показывает «Даллас». Команда говорит, что теперь Даллас — золотое значение для всех систем. Так ли это?
Нет. Согласование решает, что показывает унифицированный профиль; оно не меняет источники и не принимает решение о мастеринге. Если каждая система должна использовать одно управляемое значение, это сосуществование или централизованное MDM — с владельцем. Перечитайте Согласование — все еще не мастеринг.
6. Сопоставление медицинских записей и маркетинговых записей: правила одни и те же?
Нет. Ложное совпадение в маркетинге отправляет не то предложение; в медицинских данных оно объединяет истории болезни двух людей. Задавайте строгость по цене ошибки и сознательно сопоставляйте меньше там, где смешение обходится дорого. Перечитайте Цена ошибки.
7. Торговые представители хотят обновлять из Salesforce адрес для счетов, которым владеет ERP. Как вы это спроектируете?
Как запрос, а не правку: Salesforce отправляет предлагаемое значение, ERP проверяет и принимает его и публикует авторитетное значение обратно. До тех пор держите состояние ожидания и обрабатывайте отклонения, конфликты и эхо. Перечитайте Двусторонние данные не означают двух мастеров.
8. В Steve Trucking один и тот же John Smith появляется в манифестах двух розничных партнеров. Унифицировать его?
Нет, сознательно. Партнер никогда не должен видеть получателей другого партнера, а унифицированная идентичность — тот самый мост, через который происходит утечка. Сопоставляйте меньше там, где смешение обходится дорого; если партнер хочет распознавать повторных получателей, ограничьте это только этим партнером. Перечитайте Стал бы я унифицировать получателей разных партнеров?.
9. Торговый представитель отправляет новую улицу для адреса, которым владеет ERP, а в ту же минуту кто-то в ERP меняет город. Что вы решаете?
Путешествует ли адрес как одна транзакция. Если да, все поля проходят вместе или не проходит ни одно, и запрос отклоняется, потому что адрес за это время изменился. Решите это до первого конфликта и помните: запрос просит изменить значение ERP, а не меняет его. Перечитайте Циклы и конфликты.
10. У клиента один покупатель хранится в двух ERP, и никто не синхронизирует эти две записи. Продажи хотят одну организацию. Что вы порекомендуете?
Не одну организацию. Если клиент не может синхронизировать записи в собственных ERP, Salesforce не сделает этого за него: представьте их как равноправные организации или иерархию и покажите структуру, которую продажи уже знают. Одна организация с дочерней записью для каждой ERP требует клиента, который синхронизирует общие значения. Перечитайте Спросите, как они синхронизируют свои ERP.
Дополнительно
Заголовок раздела «Дополнительно »- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (на английском, проверено 2026-09-25): официальный список целей экзамена и их веса. Всегда проверяйте актуальную версию, прежде чем записываться на экзамен.
- В разделе «Дополнительно» каждого модуля перечислена документация Salesforce, на которой основаны его факты, с датой проверки.