Myśleć jak architekt 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 1 kursu Data Architect. Najpierw przeczytaj siedem 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.
W tym rozdziale jest mniej faktów egzaminacyjnych i to celowo. Chodzi w nim o to, jak myśli architekt, a żaden cel egzaminu nie należy wyłącznie do niego. Ale egzamin jest zbudowany ze scenariuszy: firma, kilka liczb, ograniczenie i kilka odpowiedzi, które mogłyby zadziałać. Nawyki z tego rozdziału to sposób czytania takich scenariuszy. Dlatego lista kontrolna poniżej mówi, który cel każdy punkt wspiera, zamiast twierdzić, że jest sprawdzany bezpośrednio.
Na egzamin
Dział zatytułowany „Na egzamin ”Odhaczaj je po kolei. Każdy punkt prowadzi do miejsca, w którym go omówiono.
Czytanie scenariusza jak architekt (wspiera każdy cel)
- Oddzielam prawdziwe wymaganie od projektu, w którym przyszło („potrzebujemy pól Zatwierdzający 2 i Zatwierdzający 3” a „musimy śledzić każde zatwierdzenie”). (Nie przyjmuj wymagania bez pytań)
- Szukam wymagań domyślnych, których nikt nie wypowiedział: własność, świeżość, awaria, retencja, dostęp. (Szukaj wymagań domyślnych)
- Podaję liczby: wolumen na dzień, na rok, ze wzrostem, i zauważam, kiedy jedno zero więcej zmienia odpowiedź. (Znaj swoje liczby)
- Spośród kilku działających odpowiedzi porównuję, co każda zyskuje, a z czego rezygnuje, w odniesieniu do podanych wymagań i ograniczeń. (Wiedz, z czego rezygnujesz, Ograniczenia zmieniają odpowiedź)
- Traktuję koszty, licencje i limity jako część oceny, czy narzędzie pasuje, a nie jako dodatek na koniec. (Dziewięć pytań)
Model danych (wspiera DM-1)
- Potrafię ocenić model po tym, czy wspiera biznes, może z nim rosnąć i działa wydajnie. (Wspierać. Rosnąć. Działać.)
- Potrafię rozpoznać model zbyt płaski (Pole 1, Pole 2, Pole 3), nadmiernie znormalizowany albo zbudowany na złym obiekcie standardowym. (Zbyt płaski, zbyt skomplikowany albo po prostu zły)
- Wiem, dlaczego lista wyboru pasuje do krótkiej, stabilnej listy, a lookup do listy, która ciągle rośnie albo przychodzi z integracji. (Wiele sposobów na rozwiązanie problemu)
- Wiem, że klucz, który niesie znaczenie (na przykład fragment nazwy), psuje się, gdy to znaczenie się zmienia. (Niektóre decyzje tanio się zmienia)
Zmiana tego, co już istnieje (wspiera DM-1 i SDM-2)
- Wiem, dlaczego zmiana typu pola albo oznaczenie istniejącego pola jako wymaganego może później coś zepsuć i dlaczego platforma blokuje zmianę typu, dopóki odwołuje się do pola kod lub Flow. (Ostrożnie ze zmienianiem szkieletu)
- Znam wzorzec dodawaj, zamiast przerabiać; wycofuj, zamiast zaskakiwać i wiem, że Field Usage może oznaczyć pole jako kandydata do wycofania. (Ostrożnie ze zmienianiem szkieletu)
- Znam fakty o master-detail stojące za Testem Odwracalności: dostęp i własność rekordu szczegółowego wynikają z nadrzędnego, usunięcie rekordu nadrzędnego usuwa jego rekordy szczegółowe, pola podsumowania zbiorczego wymagają master-detail, a lookup da się przekształcić w master-detail tylko wtedy, gdy każdy rekord ma w nim wartość. (Test Odwracalności, Do zgłębienia)
Licencje i udostępnianie (wspiera SDM-1)
- Wiem, że użytkownicy społeczności o dużym wolumenie (wśród nich Customer Community) nie mają ról i nie korzystają z modelu udostępniania, więc dostęp wynika z zestawów udostępniania i grup udostępniania, a udostępnianie przez Apex do nich nie sięga. (Przykład krok po kroku: udostępnianie przez Apex)
Awaria (wspiera MIG-1 i rozdziały o integracji)
- Wiem, że „zadanie zakończone” to nie to samo co dane są poprawne, i wiem, jak uzgadnianie znajduje rekordy, które nie dotarły. (Częściowy sukces to wciąż awaria, którą trzeba zrozumieć)
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.
- Ktoś musi trzymać plan. Architektura to podejmowanie dobrych decyzji przy niepełnych informacjach i znajomość ich konsekwencji.
- Model danych to szkielet. Wszystko inne jest na nim zbudowane.
- Test Odwracalności: jak trudno to odwrócić i ile będzie od tego zależeć?
- Architektura tworzy grawitację. To zależności sprawiają, że zmiana jest droga, a nie sama zmiana.
- Pomyśl o zasięgu rażenia, wewnątrz Salesforce i w całym przedsiębiorstwie. Architektura to ruch dwukierunkowy.
- Zapisz, dlaczego: kontekst, opcje, decyzja, konsekwencje, właściciel, przegląd. Zastępuj; nie wymazuj.
- Najlepsze w czym? Decyzja nieoptymalna może być częścią optymalnej architektury, jeśli wiesz, że ją podejmujesz.
- Miej w głowie obraz optimum, żeby wiedzieć, w którą stronę się od niego oddalasz i dlaczego.
- Think Correct. Think Fast. Szybkość bierze się z myślenia wykonanego przed tą chwilą.
- Buduj na dziś. Planuj na jutro. Planuj na awarię. I przyjmuj 30 procent wzrostu, gdy nikt nie poda ci liczby.
- Ucz się dziewięciu pytań, nie tylko odpowiedzi.
- AI to rakieta nośna. Generowanie to nie osąd, nieodwracalne nadal jest nieodwracalne, a przegląd przez człowieka to nie ceremonia. Ufaj, ale sprawdzaj.
Słowa do zapamiętania
Dział zatytułowany „Słowa do zapamiętania ”| Termin | W jednym zdaniu |
|---|---|
| Decyzja architektoniczna | Taka, którą trudno odwrócić i od której dużo zależy |
| Test Odwracalności | Jak trudno to odwrócić i ile będzie od tego zależeć? |
| Grawitacja | Zależności, które z czasem gromadzą się wokół decyzji |
| Zasięg rażenia | Wszystko inne, co się porusza, gdy decyzja się zmienia |
| Rejestr decyzji | Kontekst, opcje, decyzja, konsekwencje, właściciel i moment przeglądu, krótko |
| Kompromis (trade-off) | Co opcja zyskuje i z czego rezygnuje, żeby to zyskać |
| Wymaganie domyślne | Coś, czego biznes oczekuje bez proszenia, na przykład odzyskiwania, gdy import zawiedzie |
| Liczba Zer Steve’a | Jedno zero więcej w wolumenie może zmienić całą architekturę |
| Uzgadnianie | Porównanie tego, co powinno się wydarzyć, z tym, co się wydarzyło, rekord po rekordzie |
| Wycofanie | Oznaczenie czegoś jako odchodzącego, a potem świadome usunięcie, zamiast zmiany w miejscu |
| Użytkownik o dużym wolumenie | Użytkownik społeczności (wśród licencji Customer Community) bez roli, poza modelem udostępniania |
| Rozrost schematu | Obiekty i pola, które się mnożą, bo tanio je tworzyć, aż model przestaje być przez kogokolwiek zaprojektowany |
Sprawdź się
Dział zatytułowany „Sprawdź się ”Krótkie scenariusze w stylu kursu. Zdecyduj o odpowiedzi, zanim ją rozwiniesz.
1. Zespół sprzedaży prosi o pola Zatwierdzający 2 i Zatwierdzający 3, każde z datą, na szansie sprzedaży. O co pytasz i co możesz zbudować?
Zapytaj, dlaczego i ile może być zatwierdzeń. Jeśli może ich być więcej niż dwa czy trzy, wymaganiem jest śledzenie każdego zatwierdzenia, a nie dodanie pól: obiekt podrzędny, jeden rekord na zatwierdzenie. Przeczytaj ponownie Nie przyjmuj wymagania bez pytań.
2. Ktoś chce zmienić etykietę pola, a ktoś inny chce zmienić format identyfikatora klienta, który przechowuje już pięć systemów. Co zasługuje na więcej twojej uwagi i dlaczego?
Identyfikator. Etykietę tanio się zmienia. Identyfikator nie przechodzi Testu Odwracalności: trudno go odwrócić i dużo już od niego zależy. Poświęcaj uwagę proporcjonalnie do kosztu pomyłki. Przeczytaj ponownie Niektóre decyzje tanio się zmienia.
3. Pole tekstowe jest używane od lat. Biznes chce, żeby teraz przechowywało liczbę. Jakie jest twoje podejście?
Nie przerabiaj go w miejscu. Ustal, co od niego zależy (Flow, Apex, raporty, integracje, agenci) i co stanie się ze starymi danymi. Zwykle: dodaj nowe pole, przeprowadź świadomą migrację i wycofaj stare. Przeczytaj ponownie Ostrożnie ze zmienianiem szkieletu.
4. 1200 lokalizacji, 100 wizyt na lokalizację dziennie, około 305 dni w roku, dwa rekordy na wizytę, przechowywanie przez pięć lat, 30 procent wzrostu. Mniej więcej ile rekordów i dlaczego to ma znaczenie?
Około 73 milionów rekordów w pierwszym roku (36,6 mln wizyt, po dwa rekordy) i ponad 650 milionów w ciągu pięciu lat ze wzrostem. Ta sama funkcja, kilka zer więcej, zupełnie inna architektura. Przeczytaj ponownie Znaj swoje liczby.
5. Nocny import raportuje „zakończono” dla miliona rekordów. Skąd wiesz, że zadziałał?
Przeprowadzasz uzgadnianie. Strona odbierająca potwierdza każdy zapisany rekord; nadawca porównuje to, co wysłał, z tym, co potwierdzono. Brakujące potwierdzenia oznaczają, że nie zadziałał, bez względu na status zadania, i mówią ci, które rekordy ponowić, przekazać człowiekowi albo zgłosić alarmem. Przeczytaj ponownie Częściowy sukces to wciąż awaria, którą trzeba zrozumieć.
6. Społeczność z 15 milionami użytkowników Customer Community potrzebuje złożonego dostępu do rekordów. Ktoś proponuje udostępnianie przez Apex. W czym problem?
To użytkownicy o dużym wolumenie: bez ról, poza modelem udostępniania, więc nie ma rekordu udostępniania, który Apex mógłby zapisać. Dostęp wynika z zestawów udostępniania i grup udostępniania. Licencja zdecydowała, które narzędzia udostępniania istnieją. Przeczytaj ponownie Przykład krok po kroku: udostępnianie przez Apex.
7. Narzędzie AI w kilka minut generuje dwadzieścia obiektów dla nowej aplikacji. Na czym teraz polega praca architekta?
Na zdecydowaniu, czy nie powinno ich być pięć. Na zrozumieniu modelu na tyle, żeby go bronić: dlaczego te obiekty i relacje, gdzie są klucze i dane podstawowe, co się stanie w skali. Na sprawdzeniu faktów, na których się oparło. Generowanie to nie osąd. Przeczytaj ponownie Tania implementacja przesuwa wartość.
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.