Пов’язати — не означає керувати
Також доступно 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: Стати архітектором даних. Попередній: Якість даних і врядування.
«Нам потрібне єдине джерело істини». Це одна з найчастіше повторюваних фраз в архітектурі й одна з найменш досліджених. Для чого? Візьміть один акаунт. ERP може володіти його юридичною назвою, адресою для рахунків і кредитним лімітом; Salesforce — його менеджером акаунта і рівнем підтримки; платформа згоди — його маркетинговими вподобаннями. Три авторитетні системи на одному записі, і це нормально. Тож коли хтось каже «Salesforce — наше єдине джерело істини щодо клієнта», моє наступне запитання завжди: якої істини?
Цей розділ — про те, щоб свідомо відповідати на це запитання. Авторитетність призначають атрибут за атрибутом. Пов’язати записи — не означає ними керувати. А Salesforce дає різні інструменти для різних робіт: керування дублікатами й злиття в межах однієї org; розпізнавання ідентичності в Data 360 для одного погляду між джерелами; окрему MDM-платформу, коли значення треба вирішити один раз і повернути всюди. Розділ завершується Контрольною точкою 1, де Частина 1 сходиться на Steve Trucking.
Зображення згенеровано ШІ.
Позиції цього розділу
Section titled “Позиції цього розділу ”- Істина — на атрибут. Питайте, де кожна частина даних створюється, редагується і де на неї посилаються, і як швидко вона змінюється. Показуйте зовнішню авторитетність у схемі системним префіксом, як-от
sap_чиerp_. - Потенційні клієнти — інша справа. Вони живуть у Salesforce, перш ніж ERP про них дізнається; авторитетність ERP діє після перетворення.
- Registry — норма в проєктах Salesforce, далі консолідація і співіснування; чисто централізоване MDM рідкісне.
- Зливайте лише з явним переможцем. Зберігайте дублікати із зовнішніх завантажень, якщо, можливо, доведеться простежити назад; злиття знищує цю історію. І вирішіть, що стається з дочірніми записами: перенести їх, не завантажувати їх чи лишити на неактивному записі.
- Уніфікований профіль — це карта; golden record — це рішення. Людей це може плутати: розпізнавання ідентичності створює уніфіковану особу (unified individual), але не golden record.
- Суворість зіставлення — рішення про ризик. Там, де змішування дороге, свідомо зіставляйте менше.
- Три інструменти для трьох робіт: злиття, розпізнавання ідентичності, MDM.
- Ієрархії мають розділену авторитетність. Вирішуйте авторитетність гілка за гілкою.
- «The hardest thing are the bi-directionals» (найскладніше — двобічні інтеграції). Двобічна інтеграція не створює двох майстрів. Вирішіть, які поля їдуть разом як одна транзакція, ще до першої колізії.
- Зробіть основні дані видимими. Можливістю редагування керує поле, яке каже, що це основні дані (ключ ERP чи позначка), а не тип запису.
- Ми не контролюємо ERP. Ми контролюємо те, як представляємо їх у Salesforce: один клієнт у двох ERP — це ієрархія, рівноправні записи чи один акаунт із дочірнім записом на кожну ERP, і вирішує це те, наскільки добре клієнт синхронізує свої ERP.
Три інструменти для трьох робіт
Section titled “Три інструменти для трьох робіт ”| Робота | Інструмент | Що він робить із джерелами |
|---|---|---|
| Дублікати в межах однієї org, з явним переможцем | Керування дублікатами і злиття | Зливає до трьох записів; інші йдуть у кошик |
| Одна ідентичність і єдиний погляд між джерелами | Розпізнавання ідентичності в Data 360 | Пов’язує їх; жодного не змінює (registry) |
| Одне кероване значення, повернене в кожну систему | Окрема MDM-платформа | Вирішує значення і розповсюджує його (співіснування чи централізоване) |
Шлях через цей розділ
Section titled “Шлях через цей розділ ”Шість модулів і завдання, кожне самостійне.
- Одне джерело істини на атрибут. Карта авторитетності, гібридний golden record і сигнали довіри.
- Чотири способи керувати основними даними. Registry, консолідація, співіснування і централізоване, і чому спільна модель — не спільна істина.
- Зіставлення, злиття і survivorship. Ціна хибного збігу, що насправді робить злиття в Salesforce (і що стається з дочірніми записами), і survivorship як твердження про довіру.
- Карта — це не рішення. Правила зіставлення й методи зіставлення, правила узгодження і чому уніфікований профіль — не golden record.
- Коли авторитетність спільна. Запити проти оновлень, цикли й колізії, ієрархії з розділеною авторитетністю і один клієнт у двох ERP.
- Завдання Контрольної точки 1, потім Контрольна точка 1: Steve Trucking, як я б це спроєктував. Спершу спробуйте завдання: намалюйте й захистіть дизайн Частини 1, потім порівняйте його з моїм і подивіться, що змінюється порівняно з ландшафтом із розділу 4.
Коли закінчите, перевірте себе за навчальним посібником до розділу: контрольний список для іспиту, звички, що виходять за його межі, ключові терміни і кілька запитань. Він завершує Частину 1; навчальний посібник до Частини 1 зводить разом усі шість розділів.
Що тут вирішує архітектор
Section titled “Що тут вирішує архітектор ”- Яка система авторитетна щодо кожного важливого атрибута і як це видно в моделі.
- Який стиль керування пасує кожному домену даних і скільки авторитетності отримує шар керування.
- Коли зливати, коли пов’язувати і хто володіє кожним правилом survivorship.
- Наскільки суворим має бути зіставлення, виходячи з того, чого коштує хибний збіг.
- Де двобічні дані й спільні ієрархії потребують явних меж.
За межами іспиту: агентам потрібна одна ідентичність, щоб на ній діяти, і це підвищує ставки в обидва боки. Надмірне зіставлення стає інцидентом приватності, а агент, що «оновлює клієнта», має записувати в систему обліку кожного атрибута, а не в уніфікований профіль. Кожен модуль завершується тим, що змінює ШІ.
Додаткові матеріали
Section titled “Додаткові матеріали ”- 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).