Jakość danych i ład danych
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 5 kursu Data Architect. Najpierw przeczytaj sześć modułów; 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 Data Governance (10%) oraz fragmenty Data Modeling (metadane) i Salesforce Data Management (spójność). To także miejsce, w którym prawo o prywatności spotyka się z modelem danych. To architektura, a nie porada prawna: dział prawny decyduje, co obowiązuje, a architekt sprawia, że da się to egzekwować. 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.
GOV-2: projektowanie programu ładu danych
- Wiem, że właściciel rekordu (mechanizm platformy dotyczący dostępu) to nie właściciel danych (odpowiedzialny za dane jako zasób biznesowy) i że każde pole może zapisywać Data Owner. (Właściciel rekordu to nie właściciel danych)
- Potrafię odróżnić właściciela danych (ustala politykę), data stewarda (dba o to, żeby działało) i opiekuna technicznego (prowadzi system). (Właściciel, steward, opiekun techniczny)
- Wiedza egzaminacyjna: Znam trzy sposoby prowadzenia programu ładu danych, centralny, federacyjny (zdecentralizowany) i hybrydowy, i wiem, co każdy z nich oznacza dla tego, kto ustala politykę i gdzie mieszkają wspólne definicje. (Jak działa program)
- Potrafię użyć RACI, żeby odpowiedzieć, gdzie dane są tworzone, edytowane i wskazywane. (Niech RACI zapracuje na swoje miejsce)
- Potrafię wskazać punkt egzekwowania polityki ładu danych (uprawnienia, walidacja, pola zapisywane tylko przez integrację, historia pól), a nie tylko szkolenie. (Ład danych musi stać się mechaniczny)
- Wiem, że warto mierzyć te sygnały jakości, na które ktoś zareaguje. (Mierz to, na co ktoś zareaguje)
SDM-2 i MDM-4: zatrzymywanie złych danych
- Potrafię zdecydować, czy tworzenie kont powinno być otwarte czy zablokowane, i znam ścieżkę z tymczasowym typem rekordu dla kont zarządzanych w ERP. (Otwarte czy zablokowane?, Droga środka)
- Potrafię chronić zarządzane atrybuty (identyfikator z ERP, nazwę prawną), zostawiając własne pola Salesforce edytowalnymi: hybrydowy złoty rekord. I wiem, że pole tylko do odczytu na stronie Dynamic Forms to nie egzekwowanie; egzekwowaniem są zabezpieczenia na poziomie pól albo reguła sprawdzania poprawności. (Chroń zarządzany rekord, Typ rekordu dla każdego przepływu)
- Wiem, że przepływy dwukierunkowe są najtrudniejsze: jeśli ERP jest źródłem nadrzędnym dla pola, Salesforce prosi o jego zmianę, a kolizja potrzebuje reguły (ERP wygrywa, odrzucenie, jeśli wartość się zmieniła, albo rozstrzyga człowiek). (Chroń zarządzany rekord)
- Wiem, że pola wymagane mogą tworzyć fałszywe dane (
N/A,999999), i znam alternatywy. (Nie pozwól, żeby pola wymagane tworzyły fałszywe dane) - Potrafię zdecydować, co dzieje się z danymi wejściowymi, które nie przechodzą kontroli: przyjęcie, odrzucenie albo kwarantanna, i kto jest właścicielem wyjątku. (Każda granica danych potrzebuje decyzji o jakości)
- Wiem, że dane referencyjne też potrzebują metadanych: definicji, właściciela, źródła i mapowań między systemami. (Dane referencyjne też potrzebują metadanych)
DM-3: metadane biznesowe i techniczne
- Wiedza egzaminacyjna: Odróżniam metadane biznesowe (znaczenie, definicje, właściciel, zasady, wrażliwość) od metadanych technicznych (obiekty, pola, typy, nazwy API, schematy, mapowania, pochodzenie danych). (Dwa rodzaje metadanych)
- Znam różnicę między słownikiem biznesowym (co to znaczy), pochodzeniem (skąd się wzięło) i klasyfikacją (jak trzeba to traktować). (Poznaj swoje dane)
- Znam pola klasyfikacji Salesforce: Data Owner, Field Usage, Data Sensitivity Level, Compliance Categorization, na polach standardowych i niestandardowych. (Klasyfikacja odpowiada na inne pytanie)
- Wiem, że należy klasyfikować pola wrażliwe, a nie każde pole, i że klasyfikacja bez egzekwowania to dekoracja. (Klasyfikacja bez egzekwowania to dekoracja)
GOV-1: dane osobowe i wrażliwe
- Rozpoznaję główne przepisy (RODO/GDPR, CCPA/CPRA, PIPEDA, LGPD, australijski Privacy Act, HIPAA, PCI DSS, SOX, COPPA), wiem, że RODO może sięgać organizacji spoza UE, i wiem, co te przepisy mają wspólnego: prawa, przekazywanie, zgłaszanie naruszeń i rozliczalność. (Regulacje, które warto rozpoznawać, Prawo nie zatrzymuje się na granicy)
- Znam różnicę między szyfrowaniem, maskowaniem, pseudonimizacją i anonimizacją i wiem, że dane spseudonimizowane to nadal dane osobowe. (Anonimizowane, pseudonimizowane, szyfrowane, maskowane)
- Wiem, że zbieranie mniej to mechanizm ochrony prywatności, a retencję projektuje się z góry. (Zbieranie mniej to decyzja architektoniczna, Retencja jest częścią modelu)
- Znam model danych zgód: zgodę globalną na osobie (Individual), zgodę dla kanału kontaktu, zgodę dla punktu kontaktu i cel wykorzystania danych. (Użyj modelu, który Salesforce już zbudował)
- Wiem, że żądania mają terminy (RODO: miesiąc, z możliwością przedłużenia o kolejne dwa), więc mapa kopii musi istnieć wcześniej. (Zegar tyka)
- Wiem, że prawo do bycia zapomnianym oznacza znalezienie każdej kopii (historia, archiwa, analityka, logi, pliki, dowolny tekst) i że polityki Privacy Center działają per obiekt względem rekordu klienta. (Teraz osoba mówi: zapomnijcie mnie, Privacy Center to narzędzie)
- Znam kompromisy Shield Platform Encryption: pól szyfrowanych probabilistycznie nie da się filtrować, grupować ani sortować w SOQL; szyfrowanie deterministyczne pozwala filtrować; zaszyfrowane pola nie mogą sterować regułami udostępniania opartymi na kryteriach. (Szyfrowanie to mechanizm kontroli, a nie zgodność)
- Wiem, że nie kopiuje się wrażliwych danych z produkcji do sandboxów i że Data Mask jest zastępowany przez Data Mask & Seed. (Nie kopiuj ryzyka z produkcji do sandboxa)
- Odróżniam śledzenie historii pól (do 20 pól na obiekt; 18 miesięcy, 24 tylko przez API; przy długim tekście zapisuje tylko fakt edycji) od Field Audit Trail (do 200 pól, przechowywane do czasu usunięcia). (Historia to też dane)
- Znam retencję logów Event Monitoring (1 dzień bez dodatku dla niektórych zdarzeń, domyślnie 30 dni z dodatkiem, do 365 po przedłużeniu) i wiem, że zdarzenia eksportuje się do SIEM, zanim będą potrzebne: płatnych logów nie da się pobrać za okres sprzed początku umowy. (Audyt i monitorowanie to nie to samo)
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.
- Polityka bez punktu egzekwowania to w dużej mierze pobożne życzenie.
- Właściciele ustalają politykę; architekci ją egzekwują. Nie wymyślaj polityki i nie baw się w prawnika.
- Ładu danych nigdy się nie kończy. Przychodzi falami; zaprojektuj informację zwrotną.
- Nie polegaj na dobrym zachowaniu. Zbuduj mechanizm kontroli: ludzie, integracje i agenci popełniają błędy.
- Zarządzaj tyle, ile trzeba, a nie wszystkim.
- Najpierw zapobiegaj kosztownym błędom. Duplikat z dwoma latami historii to duży problem.
- Odróżniaj to, co czytają ludzie, od tego, na podstawie czego decydują maszyny.
- Dokumentuj szeroko; klasyfikuj świadomie.
- Najtańsze w zarządzaniu dane wrażliwe to te, których nigdy nie skopiowano.
- Zgoda to dane, a pozwolenie na korzystanie z danych musi dać się zapisać jako dane.
- Najpierw kontroluj, dokąd trafiają dane osobowe, bo usuwanie jest rzadkie i trudne.
- Zgodność to nie produkt.
- Pozyskaj → Sklasyfikuj → Chroń → Używaj → Przechowuj → Usuń → Audytuj.
- Zbieraj dowody, zanim ktokolwiek o nie poprosi.
Słowa do zapamiętania
Dział zatytułowany „Słowa do zapamiętania ”| Termin | W jednym zdaniu |
|---|---|
| Ład danych (data governance) | Polityki dotyczące danych i architektura, która sprawia, że są prawdziwe |
| Właściciel danych | Osoba albo funkcja odpowiedzialna za dany rodzaj danych |
| Data steward | Osoba, która na co dzień dba o kondycję danych |
| Opiekun techniczny (custodian) | Zespół, który obsługuje systemy przechowujące dane |
| RACI | Responsible, Accountable, Consulted, Informed |
| Rekord tymczasowy | Rekord utworzony, zanim przyjął go system nadrzędny |
| Słownik biznesowy | Uzgodnione definicje ważnych terminów biznesowych |
| Pochodzenie (lineage) | Skąd wzięła się wartość i co działo się z nią po drodze |
| Klasyfikacja danych | Oznaczanie danych według wrażliwości i kategorii zgodności, żeby dostały właściwe mechanizmy kontroli |
| Taksonomia | Zestaw etykiet, którym organizacja klasyfikuje dane |
| Dane osobowe | Informacje, które identyfikują osobę albo dają się z nią powiązać |
| Pseudonimizacja | Zastąpienie identyfikatorów przy zachowaniu drogi powrotnej; nadal dane osobowe |
| Anonimizacja | Usunięcie rozsądnej możliwości zidentyfikowania osoby |
| Model danych zgód | Obiekty Salesforce do zapisywania zgód według osoby, kanału, punktu kontaktu i celu |
| Prawo do bycia zapomnianym | Prawo osoby, tam gdzie przewiduje je prawo, do usunięcia jej danych osobowych |
| Hybrydowy złoty rekord | Jeden rekord z polami systemu nadrzędnego i własnymi polami Salesforce, każde z jednym źródłem |
| Metadane biznesowe / techniczne | Co dane znaczą i kto jest ich właścicielem / jak są zbudowane i jak się przemieszczają |
| Field Audit Trail | Dłuższa historia pól: do 200 pól na obiekt, przechowywana do usunięcia |
| Event Monitoring | Logi logowań, eksportów, wywołań API i wyświetleń, przechowywane przez ograniczony czas |
| SIEM | Repozytorium bezpieczeństwa, w którym przechowuje się i analizuje logi zdarzeń |
Sprawdź się
Dział zatytułowany „Sprawdź się ”Krótkie scenariusze w stylu kursu. Zdecyduj o odpowiedzi, zanim ją rozwiniesz.
1. Polityka mówi, że tylko finanse mogą zmieniać nazwę prawną klienta. Zespół planuje omówić to na szkoleniu. Czego brakuje?
Punktu egzekwowania. Szkolenie to nie mechanizm kontroli: użyj dostępu na poziomie pól, pola zapisywanego tylko przez integrację, reguły sprawdzania poprawności albo kontrolowanego procesu. Właściciele ustalają politykę; architekt sprawia, że jest mechanicznie prawdziwa. Przeczytaj ponownie Ład danych musi stać się mechaniczny.
2. Klienci są zarządzani w ERP. Handlowcy muszą od razu zaczynać sprzedaż nowym potencjalnym klientom. Jak im na to pozwolić, żeby dwa systemy nie tworzyły rekordu nadrzędnego?
Pozwól handlowcom tworzyć konto z tymczasowym typem rekordu, a potem konwertuj je przez kontrolowany proces: finanse zatwierdzają albo integracja przekazuje je do ERP, który dopasowuje albo tworzy klienta i odsyła nadrzędny identyfikator. Przeczytaj ponownie Droga środka.
3. Nowe pole wymagane zapełnia się wartościami „N/A” i „999999”. Co się stało i co zrobić zamiast tego?
Użytkownicy musieli odpowiadać, zanim znali odpowiedź. Wymagaj tego później w procesie, pozwól innemu systemowi to dostarczyć, użyj stanu tymczasowego albo dopuść wyraźne Nieznane, gdy to prawdziwa odpowiedź. Przeczytaj ponownie Nie pozwól, żeby pola wymagane tworzyły fałszywe dane.
4. Zespół zastąpił nazwiska tokenami i mówi, że dane są zanonimizowane, więc żądanie usunięcia jest załatwione. Czy jest?
Nie, jeśli tokeny da się powiązać z osobą: to pseudonimizacja, a dane nadal są osobowe. Powiedz dokładnie, co robi system, gdzie jest mapowanie, i pozwól działowi prawnemu zdecydować, czy to spełnia wymaganie. Przeczytaj ponownie Anonimizowane, pseudonimizowane, szyfrowane, maskowane.
5. Odbiorca zgadza się na SMS-y o dostawie, ale nie na marketing. Jak model powinien to zapisać?
Modelem danych zgód, a nie jednym polem wyboru: osoba, kanał (SMS), konkretny numer i cel wykorzystania danych (powiadomienia o dostawie, nie marketing). I zdecyduj, który system jest nadrzędny dla zgód, żeby wycofanie docierało do każdego systemu, który na nich działa. Przeczytaj ponownie Użyj modelu, który Salesforce już zbudował.
6. Dział zgodności musi filtrować raporty po zaszyfrowanym polu z numerem Social Security. Pole używa domyślnego schematu szyfrowania. W czym problem?
Szyfrowanie probabilistyczne nie pozwala filtrować w klauzulach SOQL WHERE ani w filtrach zarządzania danymi. Szyfrowanie deterministyczne pozwala filtrować kosztem odrobiny siły. Szyfrowanie to decyzja projektowa z kompromisami, a nie pole wyboru na końcu. Przeczytaj ponownie Szyfrowanie to mechanizm kontroli, a nie zgodność.
7. Pół roku po incydencie ktoś pyta, kto wyeksportował zestaw rekordów. Nikt nie skonfigurował przechowywania danych z Event Monitoring. Co możesz powiedzieć?
Pewnie nic: logi zdarzeń są przechowywane przez ograniczony czas (najwyżej rok, nawet po przedłużeniu), więc wszystko starsze przepada, chyba że zostało wyeksportowane. Skonfiguruj Event Monitoring i wysyłaj zdarzenia do SIEM, zanim będą potrzebne. Przeczytaj ponownie Audyt i monitorowanie to nie to samo.
8. Handlowiec prosi Salesforce o zmianę nazwy prawnej klienta, dla której źródłem nadrzędnym jest ERP. W tych samych minutach ktoś zmienia ją w ERP. Co powinien mówić projekt?
Że Salesforce prosił o zmianę, a nie zmieniał: źródłem nadrzędnym dla pola jest ERP. Ustal z góry regułę na kolizje (ERP wygrywa, odrzucenie, jeśli wartość się zmieniła, albo rozstrzyga człowiek) i to, czy powiązane pola podróżują razem. Przeczytaj ponownie Chroń zarządzany rekord.
9. Przychodzi żądanie usunięcia danych osoby. Zespół planuje zacząć mapować, gdzie mieszkają jej dane. W czym problem?
Zegar już tyka: według RODO miesiąc, z możliwością przedłużenia o kolejne dwa przy złożonych żądaniach. Mapa kopii musi istnieć, zanim przyjdzie żądanie. Przeczytaj ponownie Zegar tyka.
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 i przepisy stojące za jego faktami, z datą sprawdzenia.