Kmenová data a identita
Bu içerik henüz dilinizde mevcut değil.
K dispozici také v 29 jazycích
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)
Studijní průvodce ke kapitole 6 kurzu Data Architect. Nejdřív si přečtěte šest modulů, včetně průchodu Kontrolním bodem 1; tato stránka vám pomůže ověřit, co vám zůstalo v hlavě.
O tomto studijním průvodci. Je sestavený jen z vlastního obsahu tohoto kurzu a ze seznamu cílů v oficiálním průvodci zkouškou od Salesforce. Nikdy nevychází ze skutečných zkouškových otázek a netvrdí, že ví, co u zkoušky bude. Pokud jste zkoušku skládali, prosím, neposílejte mi z ní otázky: certifikační smlouva jejich sdílení zakazuje a učit se odpovědi nazpaměť je stejně špatná cesta, jak se stát architektem.
Tato kapitola nese oddíl zkoušky Master Data Management (5 %) a jednotný pohled na zákazníka z oddílu Salesforce Data Management. Podle váhy je to malý oddíl, ale jeho myšlenky (autorita, párování, přežití hodnot) se objevují uvnitř mnoha dalších scénářů. Čísla platformy se mění, takže si před spolehnutím ověřte ta aktuální.
Ke zkoušce
Section titled “Ke zkoušce ”Odškrtávejte si je postupně. Každý bod odkazuje na místo, kde se vykládá.
MDM-2: zlatý záznam a systém pravdy
- Vím, že autorita se přiděluje po atributech, ne po záznamech: jeden účet může mít pole spravovaná v ERP a pole spravovaná v Salesforce. (Pravda patří atributu)
- U každého atributu se ptám, kde se vytváří, upravuje a odkazuje a jaká je latence jeho změn. (Vytvořeno, upraveno, odkazováno a jak rychle?)
- Umím sestavit mapu autorit a vím, že obchodní vlastník a autoritativní systém nejsou totéž. (Sestavte mapu autorit)
- Vím, že se autorita může během životního cyklu měnit (potenciální zákazník v Salesforce se stane zákazníkem řízeným ERP) a že kopie není autorita. (Autorita se během životního cyklu mění, Kopie není autorita)
MDM-1: techniky MDM
- Ke zkoušce: znám čtyři styly implementace MDM, registr, konsolidaci, koexistenci a centralizovanou správu: co každý centralizuje a jestli posílá hodnoty zpět. (Všechny čtyři vedle sebe)
- Umím čtyři styly MDM rozlišit: registr, konsolidace, koexistence a centralizovaná správa, a zvolit nejlehčí, který problém vyřeší. (Všechny čtyři vedle sebe)
- Vím, že kanonický datový model harmonizuje strukturu, ale o autoritě nerozhoduje. (Společný model není společná pravda)
- Znám pořadí: harmonizovat, pak párovat, pak konsolidovat. (Harmonizujte, pak párujte, pak konsolidujte)
- Vím, že prahy odrážejí toleranci chyb a že obohacení potřebuje původ. (Prahy, revize a obohacení)
- Ke zkoušce: znám správu hierarchií: hierarchii staví Parent Account (zobrazení v Lightning ukazuje až 2 000 účtů, bez osobních účtů), hierarchie mají často rozdělenou autoritu a firma může mít několik platných hierarchií. (I hierarchie jsou kmenová data, Jedna hierarchie, několik masterů)
MDM-3: výběr vítězných atributů
- Držím párování, slučování a přežití hodnot odděleně. (Párování, slučování a přežití hodnot)
- Znám pravidla přežití hodnot: nejnovější, nejčastější, priorita zdroje, a vím, že každé pravidlo potřebuje vlastníka. (Přežití hodnot: která hodnota vyhraje?)
- Vím, že shoda nevyžaduje sloučení, a slučuji jen s jasným vítězem, přičemž nejdřív rozhodnu, co se stane s podřízenými záznamy. (Shoda nevyžaduje sloučení, Moje pravidlo pro sloučení: jasný vítěz)
- Ke zkoušce: vím, co dělá sloučení účtů v Salesforce: až tři záznamy, jeden hlavní, ponechá se nejstarší Created By a Created Date, ostatní jdou do Koše a u osobních účtů se objekty kontaktních bodů neslučují. (Co sloučení v Salesforce skutečně dělá)
SDM-3: jednotný pohled na zákazníka
- Vím, že rozpoznávání identity v Data 360 propojuje zdrojové profily do sjednoceného profilu a uchovává odkazy zpět: nejblíž k registru. (Rozpoznávání identity odpovídá na otázku „kdo?“)
- Ke zkoušce: znám pravidla párování v Data 360: v pravidle se musí shodovat všechna kritéria, shodovat se může kterékoli pravidlo; víc kritérií pro přesnost, méně pro konsolidaci. (Pravidla párování)
- Znám metody párování (Exact, Exact Normalized, Fuzzy se třemi úrovněmi přesnosti): méně přesná metoda zvyšuje konsolidaci i riziko falešných shod. (Pravidla párování)
- Ke zkoušce: vím, že pravidla sladění (Last Updated, Most Frequent, Source Priority) rozhodují, co ukáže sjednocený profil, ale zdroje nemění; kontaktní body se neslaďují. (Sladění pořád není správa kmenových dat)
- Umím pro danou práci zvolit mezi správou duplicit, rozpoznáváním identity a vyhrazenou platformou MDM. (Tři nástroje pro tři práce)
MDM-4 a obousměrná data
- Vím, že obousměrná data neznamenají dva mastery: úprava pole vlastněného ERP v Salesforce je požadavek, takže navrhuji požadavek → ověření → přijetí → zveřejnění, se stavem čekání. (Obousměrná data neznamenají dva mastery, Když master řekne ne)
- Vím, jak se vyhnout smyčkám a kolizím: rozlišit zahájenou změnu od její ozvěny a rozhodnout, která pole cestují společně jako jedna transakce. (Smyčky a kolize)
- U jednoho zákazníka ve dvou ERP umím zvolit hierarchii, rovnocenné účty, nebo jeden účet s podřízeným záznamem pro každé ERP, podle toho, jak dobře klient udržuje svá ERP v souladu. (Jeden zákazník, dvě ERP, Zeptejte se, jak udržují ERP v souladu)
Kontrolní bod 1: spojení části 1
- Ke zkoušce: vím, které externí licence nesou standardní sdílení: Customer Community Plus a Partner Community, které potřebují role pro externí uživatele; Customer Community používá sady sdílení. (Kdo co vidí a kdo potřebuje licenci)
Nad rámec zkoušky
Section titled “Nad rámec zkoušky ”Zkouška je podlaha, ne strop. Tohle jsou návyky z této kapitoly, které architekt potřebuje, ať se na ně nějaká otázka zeptá, nebo ne.
- „Jediný zdroj pravdy“: jaké pravdy? Je to architektura pravdy, ne jeden záznam.
- Udělejte autoritu viditelnou ve schématu: předpona pro pole, která vlastní jiný systém.
- Důvěra potřebuje víc než hodnotu: zdroj, poslední potvrzení, kdo ji změnil.
- Začněte problémem, ne produktem MDM. MDM je obchodní rozhodnutí o autoritě.
- Propojení ještě není správa kmenových dat.
- Kde jsou falešné shody drahé, párujte záměrně méně.
- Duplicity z externích nahrávání si nechte, když možná budete potřebovat dohledávat.
- Sjednocený profil je mapa. Zlatý záznam je rozhodnutí.
- Zobrazení není autorita.
- Sjednocení identity nesmaže bezpečnostní hranice.
- Nejtěžší jsou obousměrné toky. Problémem není sdílená autorita; problémem je nejasná autorita.
- Nikdy nenechte odmítnutý požadavek proměnit se v konkurenční pravdu.
- Upravitelnost řídí pole, které říká, že jde o kmenová data, ne typ záznamu.
- ERP nemáme pod kontrolou. Pod kontrolou máme, jak je reprezentujeme v Salesforce.
Pojmy k zapamatování
Section titled “Pojmy k zapamatování ”| Pojem | V jedné větě |
|---|---|
| Správa kmenových dat (MDM) | Stanovení a řízení autoritativní identity a hodnot klíčových dat napříč systémy |
| Mapa autorit (authority map) | U každého atributu: kdo ho vytváří, kdo vlastní rozhodnutí, který systém je autoritativní, kdo ho smí měnit |
| Zlatý záznam (golden record) | Řízené rozhodnutí o tom, které hodnoty jsou autoritativní |
| Hybridní zlatý záznam | Záznam, jehož některé atributy se spravují jinde a kopírují dovnitř a některé se vlastní lokálně |
| Registr (registry) | MDM, které propojuje záznamy jako stejnou entitu, aniž by měnilo zdroje |
| Konsolidace | MDM, které spojuje data centrálně, obvykle pro analytiku, bez posílání zpět |
| Koexistence (coexistence) | MDM, které rozhoduje spravovanou hodnotu a zveřejňuje ji zpět do zdrojů |
| Centralizovaná MDM | MDM, kde se řízená data vytvářejí v masteru a rozesílají |
| Kanonický datový model | Dohodnutý podnikový tvar pojmu, používaný k mapování systémů na sebe navzájem |
| Harmonizace | Zajištění porovnatelnosti hodnot: standardní formáty, kódy a zkratky |
| Párování (matching) | Rozhodnutí, zda záznamy reprezentují stejnou věc |
| Přežití hodnot (survivorship) | Pravidla pro to, která hodnota vyhraje, když se zdroje neshodnou |
| Hlavní záznam (principal record) | Při sloučení v Salesforce záznam, který přežije a ponechá si svá skrytá pole a pole jen pro čtení |
| Metoda párování (match method) | Jak kritérium párování v Data 360 porovnává hodnoty: exact, exact normalized nebo fuzzy |
| Rozpoznávání identity (identity resolution) | Párování zdrojových profilů do sjednocených profilů v Data 360 |
| Sjednocený profil | Sada klíčů propojujících zdrojové záznamy, které reprezentují jednu osobu nebo firmu |
| Pravidla sladění (reconciliation rules) | Pravidla Data 360 pro to, kterou hodnotu sjednocený profil ukáže |
| Hierarchie s rozdělenou autoritou | Hierarchie, jejíž větve vlastní různé systémy |
Otestujte se
Section titled “Otestujte se ”Krátké scénáře ve stylu kurzu. Rozhodněte se pro odpověď dřív, než ji otevřete.
1. „Salesforce je náš jediný zdroj pravdy o zákazníkovi.“ Na co se zeptáte?
Jaké pravdy? Autorita je po atributech: ERP může vlastnit oficiální název, fakturační adresu a úvěrový limit, zatímco Salesforce vlastní account executive a úroveň péče. Sestavte mapu autorit. Přečtěte si znovu Pravda patří atributu.
2. Servisní agenti potřebují vidět, že kontakt v Salesforce je stejná osoba, která nakoupila online. Nikdo nepotřebuje, aby se systémy měnily. Jaký styl MDM?
Registr: propojit záznamy jako jednu identitu, aniž by se měnily zdroje, což dělá rozpoznávání identity v Data 360. Zvolte nejlehčí vzor, který problém vyřeší. Přečtěte si znovu Registr: řekni mi, kdo je kdo.
3. Přežití hodnot je nastavené na „vyhrává nejnovější“ pro každé pole. Někdo změní kopii oficiálního názvu vlastněného ERP v Salesforce. Co se stane a co je špatně?
Vyhraje nejnovější hodnota a kopie přebije autoritu. „Nejnovější“ je tvrzení o důvěře, které sedí na některé atributy (číslo mobilu) a na jiné ne. Kde mapa autorit říká, že pole vlastní ERP, vyhrává ERP. Přečtěte si znovu Přežití hodnot: která hodnota vyhraje?.
4. Importované záznamy zákazníků ze staršího systému se shodují s existujícími účty. Sloučit je?
Buďte opatrní. Shoda nevyžaduje sloučení a sloučení zničí starší ID a starší hodnoty, které možná budete potřebovat dohledat. Propojte je, pokud není jasný vítěz a duplicita nepřidává nic, co potřebujete. Přečtěte si znovu Moje pravidlo pro sloučení: jasný vítěz.
5. Sjednocený profil v Data 360 ukazuje Dallas. Tým říká, že Dallas je teď zlatou hodnotou pro každý systém. Je?
Ne. Sladění rozhoduje, co ukáže sjednocený profil; nemění zdroje ani nedělá rozhodnutí o správě kmenových dat. Pokud musí každý systém používat jednu řízenou hodnotu, je to koexistence nebo centralizovaná MDM, s vlastníkem. Přečtěte si znovu Sladění pořád není správa kmenových dat.
6. Párování zdravotnických záznamů oproti marketingovým: stejná pravidla?
Ne. Falešná shoda v marketingu pošle špatnou nabídku; ve zdravotnických datech spojí historie dvou lidí. Přísnost nastavte podle ceny omylu a kde je smíchání drahé, párujte méně. Přečtěte si znovu Cena omylu.
7. Obchodníci chtějí ze Salesforce aktualizovat fakturační adresu vlastněnou ERP. Jak to navrhnete?
Jako požadavek, ne jako úpravu: Salesforce pošle navrženou hodnotu, ERP ji ověří a přijme a zveřejní autoritativní hodnotu zpět. Do té doby držte stav čekání a řešte odmítnutí, kolize a ozvěny. Přečtěte si znovu Obousměrná data neznamenají dva mastery.
8. Ve Steve Trucking se stejný John Smith objeví v manifestech dvou maloobchodních partnerů. Sjednotit ho?
Ne, záměrně. Žádný partner nikdy nesmí vidět příjemce jiného a sjednocená identita je most, kudy to unikne. Kde je smíchání drahé, párujte méně; pokud partner chce rozpoznávat opakované příjemce, omezte to jen na toho partnera. Přečtěte si znovu Sjednotil bych příjemce napříč partnery?.
9. Obchodník pošle novou ulici k adrese vlastněné ERP a ve stejnou minutu někdo v ERP změní město. Co rozhodnete?
Zda adresa cestuje jako jedna transakce. Pokud ano, pole projdou všechna dohromady, nebo žádné, a požadavek se odmítne, protože se adresa mezitím změnila. Rozhodněte to před první kolizí a pamatujte, že požadavek žádá o změnu hodnoty v ERP, nemění ji. Přečtěte si znovu Smyčky a kolize.
10. Klient má jednoho zákazníka ve dvou ERP a nikdo ty dva záznamy neudržuje v souladu. Obchod chce jeden účet. Co doporučíte?
Ne jeden účet. Pokud záznamy nedokážou udržet v souladu ve vlastních ERP, Salesforce to za ně neudělá: reprezentujte je jako rovnocenné účty nebo hierarchii a ukažte strukturu, kterou obchod už zná. Jeden účet s podřízeným záznamem pro každé ERP potřebuje klienta, který sdílené hodnoty udržuje v souladu. Přečtěte si znovu Zeptejte se, jak udržují ERP v souladu.
K prozkoumání
Section titled “K prozkoumání ”- Salesforce Certified Platform Data Architect Exam Guide (otevře se v nové kartě), Salesforce Help (ověřeno 2026-10-17): oficiální seznam cílů a jejich vah. Před přihlášením ke zkoušce si vždy ověřte aktuální verzi.
- Sekce K prozkoumání každého modulu uvádí dokumentaci Salesforce, ze které vycházejí jeho fakta, s datem ověření.