Architektura danych Salesforce

🌐 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)

Obraz wygenerowany przez AI

Przetłumaczone przez AI. Jeszcze niesprawdzone przez społeczność. Czytaj po angielsku

Przewodnik do nauki do rozdziału 3 kursu Data Architect. Najpierw przeczytaj dziesięć 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.

To rozdział, w którym model spotyka się z platformą, i niesie dużą część egzaminu. Zasila obie największe części, Data Modeling and Database Design oraz Salesforce Data Management, każdą stanowiącą jedną czwartą egzaminu. Liczby platformy się zmieniają: lista kontrolna podaje te, które cytują moduły, z datą sprawdzenia. Ucz się, do czego służy każdy limit, i sprawdź aktualną liczbę, zanim się na niej oprzesz.

Na egzamin

Odhaczaj je po kolei. Każdy punkt prowadzi do miejsca, w którym go omówiono.

DM-1: projektowanie modelu danych na platformie

• Wiem, że Salesforce to platforma sterowana metadanymi i wielodzierżawna: obiekt to metadane, a nie nowa tabela, a każdy obiekt dostaje swoje API w chwili, gdy powstaje. (Metadane to plan budynku, API przyszło razem z obiektem)
• Wiem, że limity zarządcze istnieją po to, żeby jeden dzierżawca nie mógł zająć wspólnych zasobów. (Nie możesz zająć windy)
• Potrafię czytać standardowe modele danych: konwersję potencjalnego klienta na konto, kontakt i szansę sprzedaży; produkt szansy sprzedaży (Opportunity Product) wskazuje na pozycję cennika (Price Book Entry), która wskazuje na Product2; a po stronie obsługi zgłoszenie, zasób i uprawnienie do obsługi (Entitlement). (Model sprzedaży, Model obsługi)
• Wiem, o czym decyduje ekran Nowy obiekt niestandardowy (New Custom Object): nazwa rekordu jako tekst albo autonumer; klasyfikacja obiektu (Object Classification: z włączonym udostępnianiem, Bulk API i Streaming API to obiekt Enterprise Application, z wyłączonymi obiekt Light Application); oraz Allow Search, domyślnie wyłączone. (Ekran New Custom Object)
• Potrafię odczytać nazwę API: obiekty i pola standardowe nie mają prefiksu ani sufiksu; niestandardowe obiekty i pola kończą się na __c; pakiet zarządzany dodaje swój prefiks przestrzeni nazw (abc__); a pole, które dodajesz do obiektu z pakietu, dostaje __c, ale nigdy prefiksu dostawcy. (Prefiksy i sufiksy)
• Potrafię zastosować test czystego dopasowania dla obiektu standardowego i wiem, kiedy znaczenie albo ciężar wskazują na obiekt niestandardowy. (Test czystego dopasowania)
• Wiem, do czego służą zasób (Asset) i konta osób, że konto osoby zajmuje mniej więcej dwa razy więcej przestrzeni niż konto firmowe i że po włączeniu kont osób nie da się ich wyłączyć. (Zasób to dobry przykład, Konta osób, Kiedy osoba jest kontem?)
• Wybieram typ pola według potrzebnego zachowania (numer floty to nie liczba) i wiem, że data/godzina jest przechowywana w GMT i pokazywana w strefie czasowej każdego czytającego, więc porównuje się ją zakresami, a nie równością. (Liczba to nie zawsze liczba, Data, data/godzina i godzina)
• Wiem, że tekst jest dwojakiego rodzaju: do 255 znaków przy rekordzie (z możliwością indeksowania, do użycia jako pole unikalne albo External ID) oraz długi albo sformatowany tekst powyżej tej granicy, bez indeksu, bez filtrowania w WHERE i bez formuł. (Rodzina pól tekstowych)
• Wiem, kiedy użyć pola Name typu autonumer, i że to nie identyfikator rekordu. (Czy człowiek musi to identyfikować?)
• Wiem, jak External ID pozwala integracji wykonywać upsert i ładować rekordy podrzędne według External ID rodzica. (External ID)
• Wiem, kiedy wartość powinna być wyliczana formułą, a kiedy to fakt historyczny, który trzeba przechowywać. (Przechowywane czy wyliczane?)
• Znam różnicę między logicznym obiektem łączącym (idea modelowania: obiekt, który łączy dwa inne w relacji wiele-do-wielu, z własnymi atrybutami) a obiektem łączącym Salesforce (Salesforce Junction Object: obiekt niestandardowy z dwiema relacjami master-detail) i wiem, że Salesforce ma na myśli ten drugi. (Dwóch rodziców wszerz)
• Znam relację hierarchiczną: specjalny lookup tylko na obiekcie User, jak standardowe pole Manager, który nie może zawrócić do tego samego użytkownika ani bezpośrednio, ani pośrednio, i nie jest hierarchią ról. (Hierarchiczna)
• Znam różnicę między lookup a master-detail: własność, udostępnianie, wymagany rodzic, usuwanie kaskadowe, pola podsumowania zbiorczego. (Lookup, Master-detail)
• Wiem, że relacji master-detail nie da się utworzyć na obiekcie, który ma już dane (utwórz lookup, wypełnij go, przekonwertuj), że z powrotem na lookup da się przejść tylko bez roll-upów na rekordzie nadrzędnym i że przeniesienie rekordu podrzędnego wymaga Zezwalaj na zmianę rekordu nadrzędnego. (Czy rekord podrzędny może zmienić rodzica?)
• Znam kształt platformy dla master-detail: do trzech niestandardowych poziomów szczegółowych w głąb (lookup może przerwać łańcuch w dowolnym miejscu) i dwóch rodziców master-detail wszerz. W obiekcie łączącym Salesforce relacja master-detail utworzona jako pierwsza jest główna (właściciel, wygląd, dział), druga jest drugorzędna, a dostęp wymaga obu rodziców: wygrywa najbardziej restrykcyjny. (Trzy poziomy w głąb, Dwóch rodziców wszerz)
• Znam trzy możliwości lookupu, gdy rodzic zostaje usunięty: wyczyszczenie pola (domyślnie), zablokowanie usunięcia albo usunięcie kaskadowe, które jest wyłączone, dopóki Salesforce go nie włączy, i omija udostępnianie. (Lookup)
• Wiem, że relacja do samego siebie musi być lookupem, i znam dwie wbudowane: konto nadrzędne na koncie i zgłoszenie nadrzędne na zgłoszeniu. (Relacje do samego siebie)
• Wiem, że przeliczenie roll-upów może trwać, że roll-up nie może użyć formuły z NOW(), TODAY() ani z odwołaniem międzyobiektowym i że nie wybiera się master-detail tylko po to, żeby dostać roll-up: alternatywą jest przechowywane pole utrzymywane przez przepływ albo trigger. (Roll-upy są przydatne, ale nie za darmo)
• Znam limity relacji cytowane w module: dwie relacje master-detail na obiekt; domyślnie 40 pól relacji (maksymalnie 50); domyślnie 25 roll-upów (maksymalnie 40). (Relacje też mają limity)

DM-2: model, który szanuje udostępnianie i się skaluje

• Wiem, że rekord podrzędny w master-detail nie ma własnego właściciela ani tabeli udostępniania: dostęp wynika z rekordu nadrzędnego. (Własność jedzie w pakiecie)
• Znam nierównomierny rozkład rodzic-dziecko: zalecenie Salesforce to nie więcej niż około 10 000 rekordów podrzędnych na jednego rodzica. (Pytanie o 10 000 rekordów podrzędnych)
• Znam nierównomierny rozkład własności (jeden użytkownik jest właścicielem ponad 10 000 rekordów obiektu) i zalecenia: rozkładaj własność albo trzymaj tego użytkownika poza hierarchią ról lub samego na jej szczycie, a także poza grupami publicznymi używanymi przez reguły udostępniania. (Własność może stać się problemem skali)
• Znam tabelę udostępniania: obiekt udostępniania obiektu niestandardowego to Object__Share; obiekt szczegółowy go nie ma, jego dostęp pochodzi od rekordu nadrzędnego; a zmiana właściciela usuwa udostępnienia ręczne, ale zachowuje udostępnianie Apex z własną przyczyną. (Tabela udostępniania)
• Potrafię zdecydować, kto jest właścicielem rekordów tworzonych przez integracje i agentów, na podstawie tego, czy własność decyduje o udostępnianiu. (Kto jest właścicielem rekordów tworzonych przez systemy?)

DM-4: big objects a obiekty standardowe i niestandardowe

• Znam trzy domy danych: w core (sObjects, codzienna praca), wskazywane (źródłem prawdy jest inny system: obiekty zewnętrzne Salesforce Connect, __x, albo własne wywołania) i zarchiwizowane (w core w big objects, __b, albo poza core w hurtowni). (W core i poza core)
• Wiem, że obiekty zewnętrzne wykonują wywołanie zewnętrzne przy każdym dotknięciu, więc liczą się opóźnienie i dostępność systemu źródłowego. (Wskazywane)
• Znam big objects: ogromne wolumeny, zapytania przez indeks z dokładnym dopasowaniem albo zakresem, brak standardowego interfejsu i raportowania, tylko uprawnienia do obiektu i pól, bez automatyzacji. (Zarchiwizowane)
• Wiem, że większość rekordów liczy się jako około 2 KB przestrzeni na dane niezależnie od liczby pól, a pliki są liczone osobno, w przestrzeni na pliki. (Dwie kolumny czy dwieście, Pliki i załączniki)

SDM-1: licencje i obiekty, z których ludzie mogą korzystać

• Znam trzy licencje wewnętrzne, Sales Cloud, Service Cloud i Platform, i wiem, z czego każda może korzystać. (Trzy licencje wewnętrzne)
• Wiem, że licencje są częścią modelu danych: użytkownicy Salesforce Platform nie mają potencjalnych klientów, kampanii, szans sprzedaży ani prognoz, a użytkownicy Customer Community nie mogą używać szans sprzedaży. (Teraz wszystko skomplikuję: licencje)
• Znam poziomy licencji zewnętrznych: Customer Community, Customer Community Plus (raporty, pulpity, standardowe udostępnianie), Partner Community (obiekty sprzedażowe); i wiem, że Partner Community nie da się używać z kontami osób. (Stadion)
• Znam licencje członkowskie (member-based) i logowaniowe (login-based) i wiem, do jakiej populacji pasuje każda z nich. (Sposób płacenia zmienia projekt)
• Wiem, że niektóre licencje platformowe ograniczają użytkowników do jednej aplikacji z maksymalnie dziesięcioma obiektami niestandardowymi, i znam wzorzec z typami rekordów do pracy w tych ramach. (Gdy licencja kształtuje model)
• Wiem, że licencja Salesforce Integration jest dla użytkowników system-system, tylko z dostępem przez API. (Ludzie to już nie jedyni użytkownicy)
• Wiem, że raportowanie SLA wymaga uprawnień do obsługi i kamieni milowych, a te wymagają licencji Service. (Teraz wszystko skomplikuję: licencje)

SDM-2: utrzymanie spójności danych

• Potrafię umieścić regułę na właściwym szczeblu drabiny spójności: typ pola i słownictwo, wymagane i unikalne, reguły sprawdzania poprawności, reguły duplikatów, automatyzacja. (Spójność danych)
• Wiem, że ograniczona lista wyboru odrzuca wartości spoza listy, nawet przez API, a globalny zestaw wartości udostępnia jedną listę wielu polom (do 1000 wartości). (Szczebel pierwszy)
• Wiem, że wymaganie w układzie strony chroni tylko ten ekran, a nie dane, i że reguły sprawdzania poprawności działają przy każdym zapisie. (Walidacja w interfejsie to nie walidacja danych, Szczebel trzeci)
• Potrafię ograniczyć regułę sprawdzania poprawności funkcjami ISNEW() i ISCHANGED(), uprawnieniem niestandardowym albo datą wejścia w życie, wiedząc, które zapisy (także te, których nie kontroluję, jak wsadowa zmiana właściciela czy roll-up) każdy z tych wyborów nadal sprawdza. (Problem starych rekordów)
• Znam reguły dopasowania i reguły duplikatów, limity cytowane w module (pięć aktywnych reguł duplikatów na obiekt, po trzy reguły dopasowania w każdej) i wiem, że nie rozwiązują tożsamości między systemami. (Szczebel czwarty: reguły duplikatów)
• Wiem, że reguły duplikatów nie porównują rekordów zapisywanych w tym samym momencie, że zapisy przez API i import są blokowane bez alertu i że zapis oraz wszystko, co uruchamia, są wycofywane jako jedna transakcja. (Szczebel czwarty, Wszystko albo nic)
• Wiem, że reguły przepływu pracy i Process Builder nie są już wspierane; automatyzacja to Flow albo Apex. (Szczebel piąty: automatyzacja)

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.

• Platforma ma kształt. Projektuj pod platformę, na której jesteś, a nie pod ogólną bazę danych.
• Patrz na statek-matkę. Zobacz, jak Salesforce modeluje pojęcie, zanim wymyślisz własne.
• Każdy obiekt to zobowiązanie: przestrzeń, limity, model udostępniania, licencje i zależności.
• Zapytaj, gdzie mieszkają dane, zanim wybierzesz obiekt: w core, wskazywane czy zarchiwizowane.
• Odczytaj dowolną nazwę API, a będziesz wiedzieć, kto ją stworzył, i co możesz zmienić.
• Jeśli nie archiwizujesz dziś, czy kiedykolwiek będziesz archiwizować?
• Zrób prototyp big objects, zanim je zaproponujesz.
• Różne nazwy biznesowe nie oznaczają automatycznie różnych obiektów.
• Pytaj, które tożsamości potrzebują danych: ludzie, klienci, partnerzy, integracje i agenci.
• Każde pole dostaje opis, a klasyfikację tam, gdzie ma znaczenie.
• Najpierw opisz zachowanie relacji; konfiguracja je implementuje. Nie wykrzywiaj modelu, żeby dostać funkcję.
• Pytanie o usuwanie: co powinno stać się z rekordami podrzędnymi, jeśli ktoś usunie rodzica?
• Wybierz, które ogniwo przerywa łańcuch: zrób lookup tam, gdzie rekord podrzędny naprawdę ma własne życie.
• Własność od głównego, dostęp od obu: wygrywa najbardziej restrykcyjny.
• Oddzielaj nieaktywne od nieistniejącego i rób z retencji regułę biznesową.
• Przesuwaj regułę tak nisko, jak poprawnie pasuje, i daj prawidłowej historii obejście, zamiast ją przepisywać.
• Diagram to nie architektura. Umiej prześledzić każdą strukturę wstecz do powodu biznesowego.

Słowa do zapamiętania

Termin	W jednym zdaniu
Sterowana metadanymi	Obiekty i pola to definicje czytane przez platformę w czasie działania, a nie nowe fizyczne tabele
Wielodzierżawność	Wiele orgów dzieli infrastrukturę, każdy odizolowany, jak mieszkania w jednym bloku
Limity zarządcze (governor limits)	Limity, które nie pozwalają jednemu dzierżawcy zmonopolizować wspólnych zasobów
Obiekt zewnętrzny	Dane pokazywane w Salesforce przez Salesforce Connect, pobierane ze źródła przy każdym dotknięciu
Big object	Przestrzeń na bardzo duże, rzadko używane dane, odpytywane przez indeks
Konto osoby	Osoba fizyczna odwzorowana jako konto, w modelach business-to-consumer
Czyste dopasowanie	Pojęcie biznesowe zgodne z zamierzonym przeznaczeniem obiektu standardowego
External ID	Pole przechowujące identyfikator z innego systemu, używane do upsertów i dopasowywania
Upsert	Zaktualizuj rekord, jeśli istnieje, utwórz, jeśli nie istnieje
Lookup	Relacja, w której rekord podrzędny zachowuje własnego właściciela i własne życie
Master-detail	Relacja, w której rekord podrzędny należy do rodzica: dziedziczony właściciel i udostępnianie, kaskadowe usuwanie, roll-upy
Logiczny obiekt łączący	Idea modelowania: obiekt, który łączy dwa inne w relacji wiele-do-wielu i niesie własne atrybuty, niezależnie od tego, jak go zbudowano
Obiekt łączący Salesforce (Salesforce Junction Object)	To, co Salesforce rozumie przez „junction object”: obiekt niestandardowy z dwiema relacjami master-detail
Główny i drugorzędny rekord nadrzędny	Relacja master-detail obiektu łączącego Salesforce utworzona jako pierwsza (właściciel, wygląd, dział) i druga (zakres raportów; staje się główną, jeśli pierwsza zostanie usunięta)
Relacja hierarchiczna	Specjalny lookup tylko na obiekcie User, jak Manager, który nie może zawrócić do tego samego użytkownika
Prefiks przestrzeni nazw (namespace prefix)	Prefiks dostawcy na obiektach i polach pakietu zarządzanego, na przykład abc__Inspection__c
Tabela udostępniania	Obiekt udostępniania (AccountShare, Truck__Share), który przechowuje większość udostępnień rekordu, jeden wiersz na użytkownika lub grupę, z przyczyną
Pole podsumowania zbiorczego (roll-up summary)	Pole na rekordzie nadrzędnym, które liczy, sumuje albo znajduje minimum lub maksimum jego rekordów szczegółowych
Nierównomierny rozkład danych (data skew)	Zbyt wiele rekordów pod jednym rodzicem albo jednym właścicielem, co powoduje blokady i długie przeliczenia udostępniania
Członkowskie / logowaniowe	Płacenie za zewnętrznego użytkownika albo za logowanie w miesiącu
Drabina spójności	Warstwy egzekwujące reguły danych, od typu pola po automatyzację
Ograniczona lista wyboru	Lista wyboru, która odrzuca każdą wartość spoza listy, z dowolnego źródła
Klasyfikacja danych	Metadane pola dotyczące właściciela, użycia, wrażliwości i kategorii zgodności

Sprawdź się

Krótkie scenariusze w stylu kursu. Zdecyduj o odpowiedzi, zanim ją rozwiniesz.

1. Użytkownicy muszą widzieć szczegóły zamówień, których właścicielem jest ERP i które ERP aktualizuje przez cały dzień. Nie edytują ich w Salesforce. Kopiować je czy nie?

Wskazuj na nie: obiekty zewnętrzne przez Salesforce Connect utrzymują ERP jako źródło prawdy, bez kopii do synchronizowania. Przyjmij, że każdy widok wykonuje wywołanie zewnętrzne, więc liczą się opóźnienie i dostępność ERP, i że to lepiej pasuje do odczytu niż do intensywnej edycji czy raportowania. Przeczytaj ponownie Wskazywane.

2. Biznes chce śledzić dystrybutorów, dostawców i partnerów detalicznych. Trzy obiekty niestandardowe?

Nie. To wszystko firmy, więc konto pasuje czysto; różne nazwy to role, które niesie typ, typ rekordu albo relacja. Przeczytaj ponownie Test czystego dopasowania.

3. Projekt używa szansy sprzedaży, ale większość osób, które potrzebują danych, ma licencje Salesforce Platform albo Customer Community. Co teraz?

Te licencje nie mogą używać szansy sprzedaży, więc licencja jest ograniczeniem architektonicznym: kup inne licencje, przenieś doświadczenie albo przeprojektuj, zwykle w stronę obiektu niestandardowego. Przeczytaj ponownie Teraz wszystko skomplikuję: licencje.

4. ERP wysyła nocne aktualizacje kont. Jak integracja powinna znaleźć właściwy rekord bez odpytywania o identyfikatory Salesforce?

Przechowuj numer klienta z ERP w polu External ID i wykonuj na nim upsert: aktualizuj, jeśli znaleziono, twórz, jeśli nie. Rekordy podrzędne też mogą wskazywać na rodzica jego External ID. Przeczytaj ponownie External ID.

5. Pozycja dostawy nie może istnieć bez swojej dostawy, nigdy się nie przenosi i nie potrzebuje własnego właściciela. Dostawa istnieje, zanim trafi na trasę, i może przejść na inną trasę. Jaka relacja dla każdej z nich?

Pozycja dostawy do dostawy: master-detail (należy do rodzica na całe życie, dziedziczy dostęp, usuwa się kaskadowo). Dostawa do trasy: lookup (własne życie, na początku opcjonalna, można ją przenosić, a usunięcie trasy nigdy nie może usuwać dostaw). Przeczytaj ponownie Zacznij od relacji biznesowej.

6. Integracja tworzy 3300 dostaw dziennie, wszystkie należące do użytkownika integracyjnego, który ma rolę w środku hierarchii. Jakie jest ryzyko i jak temu zaradzić?

Nierównomierny rozkład własności: powyżej 10 000 rekordów przesunięcie tego użytkownika albo zmiana jego grup wywołuje długie przeliczenia udostępniania. Rozłóż własność, jeśli ma znaczenie dla dostępu; w przeciwnym razie trzymaj użytkownika integracyjnego poza hierarchią ról albo samego w roli na jej szczycie i poza grupami używanymi przez reguły udostępniania. Przeczytaj ponownie Własność może stać się problemem skali.

7. Dodajesz regułę sprawdzania poprawności, a 20 000 starych rekordów ją łamie. Użytkownik edytuje w jednym z nich numer telefonu i zapis się nie udaje. Co powinna była zrobić reguła?

Mówić, kiedy egzekwować, a nie tylko, co musi być prawdą: ograniczyć ją funkcjami ISNEW() albo ISCHANGED() na odpowiednich polach i dać rekordom sprzed reguły świadome obejście, zamiast przepisywać ich historię. Przeczytaj ponownie Problem starych rekordów.

8. Biznes chce każdego zdjęcia z dostawy „w Salesforce”: cztery do pięciu milionów rocznie, wzrost o 30 procent. Co proponujesz?

Oddziel dostęp od przechowywania. Trzymaj pliki w magazynie zbudowanym na taki wolumen, poza orgiem core, a w Salesforce trzymaj odwołanie, licznik albo rekord indeksu, żeby użytkownicy mogli je znaleźć i zobaczyć. Przeczytaj ponownie Zdjęcia.

9. Przydział ekipy ma relacje master-detail do ekipy (utworzonej jako pierwsza) i do ciężarówki. Dyspozytor widzi ekipę, ale nie ciężarówkę. Czy widzi przydział ekipy?

Nie. Ekipa jest rodzicem głównym, więc daje przydziałowi właściciela i wygląd, ale dostęp wymaga obu rodziców: dyspozytor potrzebuje dostępu do ekipy i do ciężarówki, na poziomie, którego wymaga Sharing Setting każdego pola master-detail. Wygrywa najbardziej restrykcyjny. Przeczytaj ponownie Dwóch rodziców wszerz.

10. Partner ponownie wysyła plik manifestu, a ten sam klient występuje w nim dwa razy. Masz na koncie regułę duplikatów ustawioną na blokowanie. Czy jesteś bezpieczny?

Nie dzięki samej regule duplikatów. Rekordy zapisywane w tym samym momencie nie są porównywane ze sobą, tylko z rekordami, które już są w Salesforce, więc oba wiersze mogą przejść. Przesuń unikalność w dół, do pola: unikalny External ID, który platforma sprawdza przy każdym zapisie, więc wygrywa tylko jeden. Przeczytaj ponownie Szczebel czwarty: reguły duplikatów i Wszystko albo nic.

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 o platformie, z datą sprawdzenia.