Основні дані та ідентичність

🌐 Також доступно 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. За вагою це невелика частина, але її ідеї (авторитетність, зіставлення, survivorship) з’являються в багатьох інших сценаріях. Числа платформи змінюються, тож перевіряйте актуальні, перш ніж на них покладатися.

Для іспиту

Позначайте їх у міру просування. Кожен пункт веде туди, де його пояснено.

MDM-2: golden record і система істини

• Я знаю, що авторитетність призначають для атрибута, а не для запису: один акаунт може мати поля, якими керує ERP, і поля, якими керує Salesforce. (Істина належить атрибуту)
• Я питаю, де кожен атрибут створюється, редагується і де на нього посилаються, і яка його затримка змін. (Створено, редаговано, посилаються — і як швидко?)
• Я можу побудувати карту авторитетності і знаю, що бізнес-власник і авторитетна система — не одне й те саме. (Побудуйте карту авторитетності)
• Я знаю, що авторитетність може змінюватися протягом життєвого циклу (потенційний клієнт у Salesforce стає клієнтом під врядуванням ERP) і що копія — не авторитетність. (Авторитетність змінюється протягом життєвого циклу, Копія — не авторитетність)

MDM-1: техніки MDM

• Варто знати для іспиту: я знаю чотири стилі впровадження MDM — registry, консолідація, співіснування і централізоване: що кожен централізує і чи повертає він значення назад. (Чотири поруч)
• Я можу розрізнити чотири стилі MDM: registry, консолідація, співіснування і централізоване — і обрати найлегший, що розв’язує задачу. (Чотири поруч)
• Я знаю, що канонічна модель даних гармонізує структуру, але не вирішує авторитетності. (Спільна модель — не спільна істина)
• Я знаю порядок: гармонізувати, потім зіставляти, потім консолідувати. (Гармонізуйте, потім зіставляйте, потім консолідуйте)
• Я знаю, що пороги відображають толерантність до помилок, а збагаченню потрібне походження. (Пороги, перегляд і збагачення)
• Варто знати для іспиту: я знаю керування ієрархіями: Parent Account будує ієрархію (подання Lightning показує до 2000 акаунтів, без персональних акаунтів), ієрархії часто мають розділену авторитетність, а компанія може мати кілька дійсних ієрархій. (Ієрархії — теж основні дані, Одна ієрархія, кілька майстрів)

MDM-3: вибір атрибутів-переможців

• Я тримаю окремо зіставлення, злиття і survivorship. (Зіставлення, злиття і survivorship)
• Я знаю правила survivorship: найновіше, найчастіше, пріоритет джерела — і що кожному правилу потрібен власник. (Survivorship: яке значення перемагає?)
• Я знаю, що збіг не вимагає злиття, і зливаю лише з явним переможцем, спершу вирішивши, що станеться з дочірніми записами. (Збіг не вимагає злиття, Моє правило злиття: явний переможець)
• Варто знати для іспиту: я знаю, що робить злиття акаунтів у Salesforce: до трьох записів, один основний, зберігаються найстаріші Created By і Created Date, інші — у кошик (Recycle Bin), а об’єкти контактних точок для персональних акаунтів не зливаються. (Що насправді робить злиття в Salesforce)

SDM-3: єдиний погляд на клієнта

• Я знаю, що розпізнавання ідентичності в Data 360 пов’язує профілі джерел в уніфікований профіль і зберігає зв’язки назад: найближче до registry. (Розпізнавання ідентичності відповідає на «хто?»)
• Варто знати для іспиту: я знаю правила зіставлення Data 360: усі критерії в правилі мають збігтися, збігтися може будь-яке правило; більше критеріїв — для точності, менше — для консолідації. (Правила зіставлення)
• Я знаю методи зіставлення (точний, точний після нормалізації, нечіткий із трьома рівнями точності): менш точний метод підвищує консолідацію — і ризик хибних збігів. (Правила зіставлення)
• Варто знати для іспиту: я знаю, що правила узгодження (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 — бізнес-рішення про авторитетність.
• Пов’язати — не означає керувати.
• Там, де хибні збіги дорогі, свідомо зіставляйте менше.
• Зберігайте дублікати із зовнішніх завантажень, якщо, можливо, доведеться простежити назад.
• Уніфікований профіль — це карта. Golden record — це рішення.
• Показ — не авторитетність.
• Уніфікація ідентичності не стирає меж безпеки.
• «The hardest thing are the bi-directionals». Спільна авторитетність — не проблема; проблема — неоднозначна.
• Ніколи не дозволяйте відхиленому запиту стати конкурентною істиною.
• Можливістю редагування керує поле, яке каже, що це основні дані, а не тип запису.
• Ми не контролюємо ERP. Ми контролюємо те, як представляємо їх у Salesforce.

Ключові терміни

Термін	Одним реченням
Управління основними даними (MDM)	Встановлення й врядування авторитетної ідентичності й значень ключових даних між системами
Карта авторитетності	Для кожного атрибута: хто створює, хто володіє рішенням, яка система авторитетна, хто може змінювати
Golden record	Кероване рішення про те, які значення авторитетні
Гібридний golden record	Запис, деякі атрибути якого керуються деінде й копіюються всередину, а деякими володіють локально
Registry	MDM, що пов’язує записи як ту саму сутність, не змінюючи джерел
Консолідація	MDM, що поєднує дані централізовано, зазвичай для аналітики, без повернення
Співіснування	MDM, що вирішує кероване значення і публікує його назад у джерела
Централізоване MDM	MDM, де керовані дані створюють у майстрі й розповсюджують
Канонічна модель даних	Узгоджена корпоративна форма поняття, якою зіставляють системи одна з одною
Гармонізація	Приведення значень до порівнюваного вигляду: стандартні формати, коди й скорочення
Зіставлення	Рішення, чи представляють записи те саме
Survivorship	Правила, яке значення перемагає, коли джерела розходяться
Основний запис (principal)	Під час злиття в Salesforce — запис, що виживає і зберігає свої приховані поля й поля лише для читання
Метод зіставлення	Як критерій зіставлення в Data 360 порівнює значення: точно, точно після нормалізації чи нечітко
Розпізнавання ідентичності	Зіставлення профілів джерел в уніфіковані профілі в Data 360
Уніфікований профіль	Набір ключів, що пов’язує вихідні записи, які представляють одну людину чи компанію
Правила узгодження	Правила Data 360 щодо того, яке значення показує уніфікований профіль
Ієрархія з розділеною авторитетністю	Ієрархія, гілками якої володіють різні системи

Перевірте себе

Короткі сценарії в стилі курсу. Визначтеся з відповіддю, перш ніж розгорнути її.

1. «Salesforce — наше єдине джерело істини щодо клієнта». Що ви запитаєте?

Якої істини? Авторитетність — на атрибут: ERP може володіти юридичною назвою, адресою для рахунків і кредитним лімітом, а Salesforce — менеджером акаунта й рівнем успіху. Побудуйте карту авторитетності. Перечитайте Істина належить атрибуту.

2. Сервісним агентам треба бачити, що контакт Salesforce — та сама людина, що купила онлайн. Нікому не треба, щоб системи змінювалися. Який стиль MDM?

Registry: пов’язати записи як одну ідентичність, не змінюючи джерел, — саме це робить розпізнавання ідентичності в Data 360. Обирайте найлегший шаблон, що розв’язує задачу. Перечитайте Registry: скажіть мені, хто є хто.

3. Survivorship налаштовано як «перемагає найновіше» для кожного поля. Хтось змінює копію в Salesforce юридичної назви, якою володіє ERP. Що станеться і що не так?

Перемагає найновіше значення, і копія переважає авторитетність. «Найновіше» — твердження про довіру, що пасує одним атрибутам (мобільний номер), а іншим — ні. Там, де карта авторитетності каже, що полем володіє ERP, перемагає ERP. Перечитайте Survivorship: яке значення перемагає?.

4. Імпортують записи клієнтів із застарілої системи, і вони збігаються з наявними акаунтами. Зливати?

Будьте обережні. Збіг не вимагає злиття, а злиття знищує застарілі ID і старіші значення, які, можливо, доведеться простежити. Пов’яжіть їх, якщо немає явного переможця і дублікат не додає нічого потрібного. Перечитайте Моє правило злиття: явний переможець.

5. Уніфікований профіль у Data 360 показує Dallas. Команда каже, що Dallas тепер золоте значення для кожної системи. Це так?

Ні. Узгодження вирішує, що показує уніфікований профіль; воно не змінює джерел і не ухвалює рішення про керування. Якщо кожна система мусить використовувати одне кероване значення, це співіснування чи централізоване 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, що стоїть за фактами, з датою перевірки.