Dane podstawowe i tożsamość
Dostępne także w 28 językach
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Przewodnik do nauki do rozdziału 6 kursu Data Architect. Najpierw przeczytaj sześć modułów, łącznie z omówieniem Punktu kontrolnego 1; ta strona pomoże ci sprawdzić, co zostało w głowie.
O tym przewodniku. Powstał wyłącznie na podstawie treści tego kursu i listy celów z opublikowanego przez Salesforce przewodnika po egzaminie. Nigdy nie opiera się na prawdziwych pytaniach egzaminacyjnych i nie twierdzi, że wie, co jest na egzaminie. Jeśli masz egzamin za sobą, proszę, nie przysyłaj mi z niego pytań: umowa certyfikacyjna zabrania ich udostępniania, a wkuwanie odpowiedzi i tak jest złą drogą do zostania architektem.
Ten rozdział obejmuje część egzaminu Master Data Management (5%) oraz jeden widok klienta z części Salesforce Data Management. Wagowo to mała część, ale jej idee (autorytet, dopasowanie, reguły przetrwania) pojawiają się w wielu innych scenariuszach. Liczby platformy się zmieniają, więc sprawdź aktualne, zanim się na nich oprzesz.
Na egzamin
Dział zatytułowany „Na egzamin ”Odhaczaj je po kolei. Każdy punkt prowadzi do miejsca, w którym go omówiono.
MDM-2: złoty rekord i system prawdy
- Wiem, że autorytet przypisuje się do atrybutu, a nie do rekordu: jedno konto może mieć pola zarządzane w ERP i pola zarządzane w Salesforce. (Prawda należy do atrybutu)
- Pytam, gdzie każdy atrybut jest tworzony, edytowany i wskazywany i jakie ma opóźnienie zmian. (Tworzone, edytowane, wskazywane i jak szybko?)
- Potrafię zbudować mapę autorytetów i wiem, że właściciel biznesowy i system nadrzędny to nie to samo. (Zbuduj mapę autorytetów)
- Wiem, że autorytet może zmieniać się w cyklu życia (potencjalny klient w Salesforce staje się klientem zarządzanym przez ERP) i że kopia to nie autorytet. (Autorytet zmienia się w cyklu życia, Kopia to nie autorytet)
MDM-1: techniki MDM
- Wiedza egzaminacyjna: Znam cztery style wdrażania MDM, rejestr, konsolidację, współistnienie i podejście scentralizowane: co każdy z nich centralizuje i czy odsyła wartości z powrotem. (Cztery obok siebie)
- Potrafię odróżnić cztery style MDM: rejestr, konsolidację, współistnienie i podejście scentralizowane i wybrać najlżejszy, który rozwiązuje problem. (Cztery obok siebie)
- Wiem, że kanoniczny model danych harmonizuje strukturę, ale nie decyduje o autorytecie. (Wspólny model to nie wspólna prawda)
- Znam kolejność: harmonizuj, potem dopasuj, potem konsoliduj. (Najpierw harmonizuj, potem dopasuj, potem konsoliduj)
- Wiem, że progi odzwierciedlają tolerancję błędu, a wzbogacanie wymaga znajomości pochodzenia. (Progi, przegląd i wzbogacanie)
- Wiedza egzaminacyjna: Znam zarządzanie hierarchią: hierarchię buduje pole konto nadrzędne (widok Lightning pokazuje do 2000 kont, bez kont osób), hierarchie często mają podzielony autorytet, a firma może mieć kilka prawidłowych hierarchii. (Hierarchie to też dane podstawowe, Jedna hierarchia, kilka źródeł nadrzędnych)
MDM-3: wybór zwycięskich atrybutów
- Trzymam osobno dopasowanie, scalanie i reguły przetrwania. (Dopasowanie, scalanie i reguły przetrwania)
- Znam reguły przetrwania: najnowsza, najczęstsza, priorytet źródła, i wiem, że każda reguła potrzebuje właściciela. (Reguły przetrwania: która wartość wygrywa?)
- Wiem, że dopasowanie nie wymaga scalenia, i scalam tylko przy wyraźnym zwycięzcy, decydując najpierw, co stanie się z rekordami podrzędnymi. (Dopasowanie nie wymaga scalenia, Moja zasada scalania: wyraźny zwycięzca)
- Wiedza egzaminacyjna: Wiem, co robi scalanie kont w Salesforce: do trzech rekordów, jeden główny, zachowane pola Utworzone przez i Data utworzenia najstarszego rekordu, pozostałe do Kosza, a obiekty punktów kontaktu kont osób nie są scalane. (Co naprawdę robi scalanie w Salesforce)
SDM-3: jeden widok klienta
- Wiem, że rozpoznawanie tożsamości w Data 360 łączy profile źródłowe w ujednolicony profil i zachowuje powiązania z nimi: najbliżej mu do rejestru. (Rozpoznawanie tożsamości odpowiada na pytanie „kto?”)
- Wiedza egzaminacyjna: Znam reguły dopasowania w Data 360: wszystkie kryteria w regule muszą się zgadzać, dopasować może się dowolna reguła; więcej kryteriów dla dokładności, mniej dla konsolidacji. (Reguły dopasowania)
- Znam metody dopasowania (Exact, Exact Normalized, Fuzzy z trzema poziomami precyzji): mniej precyzyjna metoda podnosi konsolidację, a razem z nią ryzyko fałszywych dopasowań. (Reguły dopasowania)
- Wiedza egzaminacyjna: Wiem, że reguły uzgadniania (Last Updated, Most Frequent, Source Priority) decydują, co pokazuje ujednolicony profil, ale nie zmieniają źródeł; punkty kontaktu nie są uzgadniane. (Uzgadnianie to nadal nie zarządzanie danymi podstawowymi)
- Potrafię wybrać do zadania między zarządzaniem duplikatami, rozpoznawaniem tożsamości a dedykowaną platformą MDM. (Trzy narzędzia do trzech zadań)
MDM-4 i dane dwukierunkowe
- Wiem, że dane dwukierunkowe to nie dwa źródła nadrzędne: edycja w Salesforce pola, którego właścicielem jest ERP, to prośba, więc projektuję prośba → weryfikacja → przyjęcie → publikacja, ze stanem oczekiwania. (Dane dwukierunkowe to nie dwa źródła nadrzędne, Gdy źródło nadrzędne mówi „nie”)
- Wiem, jak unikać pętli i kolizji: odróżniam zmianę źródłową od jej echa i decyduję, które pola podróżują razem jako jedna transakcja. (Pętle i kolizje)
- Dla jednego klienta w dwóch ERP potrafię wybrać hierarchię, konta równorzędne albo jedno konto z rekordem podrzędnym dla każdego ERP, zależnie od tego, jak dobrze klient utrzymuje synchronizację swoich ERP-ów. (Jeden klient, dwa ERP-y, Zapytaj, jak synchronizują swoje ERP-y)
Punkt kontrolny 1: składanie części 1 w całość
- Wiedza egzaminacyjna: Wiem, które licencje zewnętrzne dają standardowe udostępnianie: Customer Community Plus i Partner Community, które wymagają ról dla użytkowników zewnętrznych; Customer Community korzysta z zestawów udostępniania. (Kto co widzi i kto potrzebuje licencji)
Poza egzaminem
Dział zatytułowany „Poza egzaminem ”Egzamin to podłoga, nie sufit. Oto nawyki z tego rozdziału, których architekt potrzebuje, niezależnie od tego, czy jakiekolwiek pytanie o nie zapyta.
- „Jedno źródło prawdy”: która prawda? To architektura prawdy, a nie jeden rekord.
- Pokaż autorytet w schemacie: prefiks dla pól, których właścicielem jest inny system.
- Zaufanie potrzebuje więcej niż wartości: źródła, daty ostatniego potwierdzenia, tego, kto zmienił.
- Zacznij od problemu, nie od produktu MDM. MDM to decyzja biznesowa o autorytecie.
- Połączenie to jeszcze nie zarządzanie danymi podstawowymi.
- Tam, gdzie fałszywe dopasowania są kosztowne, celowo dopasowuj mniej.
- Zachowuj duplikaty z zewnętrznych importów, gdy możesz potrzebować dotrzeć do starszych wartości.
- Ujednolicony profil to mapa. Złoty rekord to decyzja.
- Prezentacja to nie autorytet.
- Ujednolicenie tożsamości nie znosi granic bezpieczeństwa.
- Najtrudniejsze są te dwukierunkowe. Dzielony autorytet to nie problem; problemem jest niejasny autorytet.
- Nigdy nie pozwól, żeby odrzucona prośba zamieniła się w konkurencyjną prawdę.
- Pole, które mówi, że to dane podstawowe, steruje możliwością edycji, a nie typ rekordu.
- Nie kontrolujemy ERP-ów. Kontrolujemy to, jak reprezentujemy je w Salesforce.
Słowa do zapamiętania
Dział zatytułowany „Słowa do zapamiętania ”| Termin | W jednym zdaniu |
|---|---|
| Zarządzanie danymi podstawowymi (MDM) | Ustalanie nadrzędnej tożsamości i wartości kluczowych danych w wielu systemach i zarządzanie nimi |
| Mapa autorytetów | Dla każdego atrybutu: kto go tworzy, kto jest właścicielem decyzji, który system jest nadrzędny, kto może go zmieniać |
| Złoty rekord (golden record) | Zarządzana decyzja o tym, które wartości są nadrzędne |
| Hybrydowy złoty rekord | Rekord, którego część atrybutów jest zarządzana gdzie indziej i kopiowana do środka, a część należy do niego lokalnie |
| Rejestr | MDM, który łączy rekordy jako ten sam podmiot, nie zmieniając źródeł |
| Konsolidacja | MDM, który centralnie łączy dane, zwykle do analityki, bez odsyłania ich z powrotem |
| Współistnienie | MDM, który ustala wartość nadrzędną i publikuje ją z powrotem do źródeł |
| Scentralizowane MDM | MDM, w którym zarządzane dane tworzy się w źródle nadrzędnym i rozsyła |
| Kanoniczny model danych | Uzgodniony w przedsiębiorstwie kształt pojęcia, używany do mapowania systemów między sobą |
| Harmonizacja | Sprawianie, że wartości da się porównać: standardowe formaty, kody i skróty |
| Dopasowanie | Decyzja, czy rekordy odwzorowują to samo |
| Reguły przetrwania (survivorship) | Reguły, która wartość wygrywa, gdy źródła się nie zgadzają |
| Rekord główny (principal) | W scalaniu w Salesforce rekord, który przetrwa i zachowuje swoje ukryte pola i pola tylko do odczytu |
| Metoda dopasowania | Sposób, w jaki kryterium dopasowania w Data 360 porównuje wartości: dokładnie, dokładnie po normalizacji albo w sposób rozmyty (fuzzy) |
| Rozpoznawanie tożsamości | Dopasowywanie w Data 360 profili źródłowych do ujednoliconych profili |
| Ujednolicony profil | Zestaw kluczy łączących rekordy źródłowe, które odwzorowują jedną osobę albo firmę |
| Reguły uzgadniania | Reguły Data 360 decydujące, jaką wartość pokazuje ujednolicony profil |
| Hierarchia z podzielonym autorytetem | Hierarchia, której gałęzie należą do różnych systemów |
Sprawdź się
Dział zatytułowany „Sprawdź się ”Krótkie scenariusze w stylu kursu. Zdecyduj o odpowiedzi, zanim ją rozwiniesz.
1. „Salesforce to nasze jedno źródło prawdy o kliencie”. O co pytasz?
Która prawda? Autorytet przypisuje się do atrybutu: ERP może być właścicielem nazwy prawnej, adresu rozliczeniowego i limitu kredytowego, a Salesforce opiekuna handlowego i poziomu obsługi. Zbuduj mapę autorytetów. Przeczytaj ponownie Prawda należy do atrybutu.
2. Agenci serwisu muszą widzieć, że kontakt w Salesforce to ta sama osoba, która kupiła coś online. Nikt nie potrzebuje zmian w systemach. Który styl MDM?
Rejestr: połącz rekordy jako jedną tożsamość, nie zmieniając źródeł, a to właśnie robi rozpoznawanie tożsamości w Data 360. Wybierz najlżejszy wzorzec, który rozwiązuje problem. Przeczytaj ponownie Rejestr: powiedz mi, kto jest kim.
3. Reguła przetrwania dla każdego pola to „wygrywa najnowsza”. Ktoś zmienia kopię nazwy prawnej w Salesforce, której właścicielem jest ERP. Co się dzieje i co jest nie tak?
Wygrywa najnowsza wartość, a kopia przesłania autorytet. „Najnowsza” to stwierdzenie o zaufaniu, które pasuje do niektórych atrybutów (numer komórkowy), a do innych nie. Tam, gdzie mapa autorytetów mówi, że właścicielem pola jest ERP, wygrywa ERP. Przeczytaj ponownie Reguły przetrwania: która wartość wygrywa?.
4. Zaimportowane rekordy klientów ze starego systemu pasują do istniejących kont. Scalić je?
Ostrożnie. Dopasowanie nie wymaga scalenia, a scalenie niszczy stare identyfikatory i starsze wartości, do których możesz potrzebować dotrzeć. Powiąż je, chyba że jest wyraźny zwycięzca, a duplikat nie wnosi niczego, czego potrzebujesz. Przeczytaj ponownie Moja zasada scalania: wyraźny zwycięzca.
5. Ujednolicony profil w Data 360 pokazuje Dallas. Zespół mówi, że Dallas to teraz złota wartość dla każdego systemu. Czy tak jest?
Nie. Uzgadnianie decyduje o tym, co pokazuje ujednolicony profil; nie zmienia źródeł ani nie podejmuje decyzji o danych podstawowych. Jeśli każdy system musi używać jednej zarządzanej wartości, to współistnienie albo scentralizowane MDM, z właścicielem. Przeczytaj ponownie Uzgadnianie to nadal nie zarządzanie danymi podstawowymi.
6. Dopasowywanie danych medycznych a danych marketingowych: te same reguły?
Nie. Fałszywe dopasowanie w marketingu wysyła niewłaściwą ofertę; w danych medycznych łączy historie dwóch ludzi. Ustal surowość według kosztu pomyłki i dopasowuj mniej tam, gdzie mieszanie jest kosztowne. Przeczytaj ponownie Koszt pomyłki.
7. Handlowcy chcą aktualizować z Salesforce adres rozliczeniowy, którego właścicielem jest ERP. Jak to zaprojektujesz?
Jako prośbę, a nie edycję: Salesforce wysyła proponowaną wartość, ERP ją weryfikuje i przyjmuje, a potem publikuje z powrotem wartość nadrzędną. Do tego czasu utrzymuj stan oczekiwania i obsłuż odrzucenia, kolizje i echa. Przeczytaj ponownie Dane dwukierunkowe to nie dwa źródła nadrzędne.
8. W Steve Trucking ten sam John Smith pojawia się w manifestach dwóch partnerów detalicznych. Ujednolicić go?
Nie, celowo. Żaden partner nigdy nie może widzieć odbiorców innego, a ujednolicona tożsamość jest mostem, przez który dane wyciekają. Dopasowuj mniej tam, gdzie mieszanie jest kosztowne; jeśli partner chce rozpoznawania powracających odbiorców, ogranicz je tylko do tego partnera. Przeczytaj ponownie Czy ujednoliciłbym odbiorców między partnerami?.
9. Handlowiec wysyła nową ulicę dla adresu, którego właścicielem jest ERP, a w tej samej minucie ktoś w ERP zmienia miasto. Co decydujesz?
Czy adres podróżuje jako jedna transakcja. Jeśli tak, pola idą wszystkie razem albo żadne, a prośba zostaje odrzucona, bo adres w międzyczasie się zmienił. Zdecyduj o tym przed pierwszą kolizją i pamiętaj, że prośba to prośba o zmianę wartości w ERP, a nie jej zmiana. Przeczytaj ponownie Pętle i kolizje.
10. Klient ma jednego klienta w dwóch ERP i nikt nie utrzymuje synchronizacji tych dwóch rekordów. Dział sprzedaży chce jednego konta. Co rekomendujesz?
Nie jedno konto. Jeśli nie potrafią utrzymać synchronizacji rekordów we własnych ERP-ach, Salesforce nie zrobi tego za nich: przedstaw je jako konta równorzędne albo hierarchię i pokaż strukturę, którą dział sprzedaży już zna. Jedno konto z rekordem podrzędnym dla każdego ERP wymaga klienta, który utrzymuje wspólne wartości w synchronizacji. Przeczytaj ponownie Zapytaj, jak synchronizują swoje ERP-y.
Do zgłębienia
Dział zatytułowany „Do zgłębienia ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Pomoc Salesforce (po angielsku, sprawdzono 2026-09-25): oficjalna lista celów i ich wag. Zawsze sprawdź aktualną wersję, zanim zapiszesz się na egzamin.
- Sekcja „Do zgłębienia” w każdym module wymienia dokumentację Salesforce stojącą za jego faktami, z datą sprawdzenia.