Modelowanie danych, które coś znaczą
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 2 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ł to fundament części egzaminu Data Modeling and Database Design, która stanowi jedną czwartą egzaminu. Obejmuje sposób myślenia; następny rozdział, Architektura danych Salesforce, obejmuje to, jak buduje to platforma. Większość tego, co sprawdza się o obiektach, polach i relacjach, wymaga więc obu rozdziałów.
Na egzamin
Dział zatytułowany „Na egzamin ”Punkty z tego rozdziału, które najpewniej będą miały znaczenie na egzaminie. Każdy jest powiązany ze swoim celem egzaminu i prowadzi do miejsca, w którym go omówiono. Odhaczaj je po kolei.
DM-1: porównywanie technik projektowania modelu danych Salesforce
- Potrafię wyjaśnić różnicę między konceptualnym, logicznym i fizycznym modelem danych oraz do czego służy każdy z nich. (Przenieś model do Salesforce)
- Potrafię znaleźć encje kandydujące w wymaganiu i odróżnić osobę wykonującą pracę od elementu danych. (Rzeczowniki dają ci encje kandydujące)
- Potrafię czytać i rysować notację kurzej łapki (crow’s foot): jeden, wiele i drugi znak dla opcjonalnej albo wymaganej. (Czytaj linie, Opcjonalność też ma znaczenie)
- Potrafię nazwać liczność relacji: jeden-do-jednego, jeden-do-wielu, wiele-do-wielu. (Zapytaj: „jeden czy wiele?”)
- Wiem, że relacja wiele-do-wielu staje się osobną encją, a w Salesforce zwykle obiektem łączącym z dwoma rodzicami. (Relacje mogą stać się rzeczami)
- Wiem, kiedy relacja potrzebuje historii (rekordu z datą początku i końca), a nie pola, które jest nadpisywane. (Czas zmienia relacje)
- Potrafię wybrać dobry unikalny identyfikator i wiem, dlaczego klucz naturalny albo cokolwiek z danymi osobowymi to ryzykowny wybór. (Potem musimy porozmawiać o unikalnych identyfikatorach)
- Znam różnicę między kluczem naturalnym a kluczem zastępczym i wiem, że jeden rekord może nosić kilka identyfikatorów zewnętrznych. (Klucze naturalne i klucze zastępcze)
- Wiem, że pole typu autonumer to czytelny numer, a nie identyfikator rekordu w Salesforce. (Relacje zależą od unikalnych identyfikatorów)
- Potrafię stosować pierwszą, drugą i trzecią postać normalną i wyłapać pole, które przechowuje kilka wartości albo powtarza fakt o czymś innym. (Prosty sposób myślenia o 1NF, 2NF i 3NF)
- Potrafię wyjaśnić, kiedy celowo denormalizować (użytkownicy, raportowanie, skala) i ile to kosztuje. (Projektuj do trzeciej postaci normalnej, potem odpuść)
- Potrafię wybrać między listą wyboru a lookupem do obiektu dla listy wartości. (Lookup czy lista wyboru?)
- Wiem, że niestandardowy typ raportu pozwala na co najwyżej cztery relacje między obiektami, i wiem, dlaczego to ma znaczenie dla głębokich modeli. (Lookup czy lista wyboru?)
- Wiem, kiedy pasuje master-detail (rekord podrzędny nigdy nie zmienia rodzica), a kiedy bezpieczniejszy jest lookup, włącznie z zaleceniem Salesforce, by na jednym rekordzie nadrzędnym nie było więcej niż 10 000 rekordów podrzędnych. (Relacje stają się decyzjami dotyczącymi platformy)
- Wiem, dlaczego unikać relacji polimorficznych, gdzie się da. (Relacje stają się decyzjami dotyczącymi platformy)
- Wiem, że encja biznesowa to nie automatycznie obiekt niestandardowy: może być obiektem standardowym, polem, konfiguracją albo danymi, które mieszkają poza Salesforce. (Encja biznesowa to nie automatycznie obiekt niestandardowy)
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.
- Zapomnij na chwilę o Salesforce. Zamodeluj biznes, zanim zmapujesz go na konto i kontakt.
- Wsłuchuj się w słowo, które kryje dwie rzeczy. W Steve Trucking „klient” to był partner detaliczny i odbiorca.
- Model jest częścią rozmowy. Twój pierwszy model nie ma mieć racji; ma ci pokazać, gdzie się mylisz.
- Nazywaj linie. Dwa modele z tymi samymi prostokątami mogą znaczyć różne rzeczy.
- Pytaj „teraz czy w czasie?” o każdą relację.
- Unikalny, niezmienny, bez znaczenia, nigdy dane osobowe.
- Umieść fakt tam, gdzie jego miejsce, potem celowo odpuść i zapisz dlaczego.
- Denormalizacja nie usuwa złożoności; przenosi ją. Wiedz, kto jest właścicielem prawdy.
- Jedno źródło prawdy, wiele kształtów: ekrany, raporty, hurtownia i AI.
- Nie projektuj z poziomu Konfiguracji. Narysuj model, zanim klikniesz Nowy obiekt niestandardowy.
- Prześledź każdą decyzję fizyczną wstecz do czegoś, czego potrzebuje biznes.
Słowa do zapamiętania
Dział zatytułowany „Słowa do zapamiętania ”| Termin | W jednym zdaniu |
|---|---|
| Encja | Rzecz, na której zależy biznesowi i o której przechowuje dane |
| Encja kandydująca | Rzeczownik, który może stać się encją, gdy już o niego zapytasz |
| Atrybut | Fakt opisujący encję |
| Relacja | Sposób, w jaki dwie encje są połączone, nazwany językiem biznesu |
| Liczność (kardynalność) | Ile jednych wiąże się z iloma drugimi |
| Opcjonalność | Czy relacja jest wymagana, czy może jej nie być |
| Kurza łapka (crow’s foot) | Znak „wiele” na końcu linii |
| Obiekt łączący | Sposób Salesforce na zbudowanie relacji wiele-do-wielu: rekord podrzędny obu rodziców |
| Model konceptualny | Co istnieje w biznesie i jak jest powiązane; bez Salesforce |
| Model logiczny | Dane: atrybuty, unikalne identyfikatory i relacje, nadal bez przywiązania do platformy |
| Model fizyczny | Jak zbuduje to platforma: obiekty, pola i typy relacji |
| Klucz naturalny | Identyfikator, który już istnieje w biznesie, jak VIN ciężarówki |
| Klucz zastępczy | Identyfikator utworzony wyłącznie po to, żeby identyfikować rekord |
| Identyfikator zewnętrzny | Identyfikator tego samego rekordu w innym systemie, zachowany i zmapowany |
| Normalizacja (1NF, 2NF, 3NF) | Umieszczanie każdego faktu tam, gdzie jego miejsce: jedna wartość na pole, fakty o całym kluczu, żadnych faktów o innych faktach |
| Denormalizacja | Celowe kopiowanie albo spłaszczanie danych z powodu, który da się nazwać |
| Anomalia aktualizacji | Ten sam fakt przechowywany w wielu miejscach, więc jedna zmiana zostawia część kopii błędnych |
Sprawdź się
Dział zatytułowany „Sprawdź się ”Krótkie scenariusze w stylu kursu. Zdecyduj o odpowiedzi, zanim ją rozwiniesz.
1. Biznes mówi ci, że ekipa jeździ ciężarówką. Sześć tygodni później ktoś pyta, która ekipa miała ciężarówkę 117 danego dnia. Co powinien był mieć model?
Przydział ekipy: relację między ekipą a ciężarówką jako osobny rekord, z datą początku, datą końca i trasą. Ekipy i ciężarówki są w czasie w relacji wiele-do-wielu, a biznes obchodzi historia. Pole na ciężarówce zostałoby nadpisane. Przeczytaj ponownie Czas zmienia relacje.
2. Zespół proponuje, żeby unikalnym identyfikatorem był numer telefonu każdego odbiorcy, „bo jest unikalny”. Co odpowiadasz?
Nie przechodzi testów: numery telefonów się zmieniają i bywają współdzielone, więc nie są niezmienne ani wiarygodnie unikalne, a to dane osobowe, które zostałyby skopiowane do każdego systemu powiązanego z rekordem. Użyj wygenerowanego identyfikatora bez znaczenia, a numer telefonu zachowaj jako atrybut. Przeczytaj ponownie Potem musimy porozmawiać o unikalnych identyfikatorach.
3. Dostawa ma pola Pozycja 1, Pozycja 2 i Pozycja 3. Przychodzi dostawa z czterema pozycjami. Na czym polega prawdziwy problem i jak go naprawić?
Model ukrył powtarzającą się strukturę w polach (problem pierwszej postaci normalnej). Naprawą nie jest pole Pozycja 4; jest nią encja pozycja dostawy, rekord podrzędny dostawy, dzięki czemu każda pozycja jest rekordem. Przeczytaj ponownie Pierwsza postać normalna.
4. Każda dostawa przechowuje nazwisko kierownika centrum dystrybucyjnego. Kierownik się zmienia. Co poszło nie tak?
Fakt o czymś innym (o centrum dystrybucyjnym) był przechowywany na dostawie: problem trzeciej postaci normalnej, a teraz anomalia aktualizacji w setkach rekordów. Kierownik należy do centrum dystrybucyjnego; dostawa wskazuje na centrum dystrybucyjne. Przeczytaj ponownie Trzecia postać normalna.
5. Rodzaj przystanku (tylko dostawa, z instalacją, z wywozem) potrzebuje czasu trwania, umiejętności ekipy i listy kontrolnej. Lista wyboru czy obiekt?
Obiekt. Ma więcej niż jedną kolumnę informacji, zarządza nim biznes i zmienia się we własnym rytmie. Status dostawy, krótka, stabilna lista etykiet, zostaje listą wyboru. Przeczytaj ponownie Lookup czy lista wyboru?.
6. Partnerzy chcą karty wyników punktualności według regionu, a region mieszka na centrum dystrybucyjnym. Kopiujesz region na każdą dostawę. O czym musisz zdecydować?
Kto jest właścicielem prawdy, jak kopia pozostaje zsynchronizowana i czy stare dostawy powinny zachować region, który był prawdziwy w chwili dostawy, czy podążać za centrum dystrybucyjnym, jeśli się przeniesie. Denormalizacja przeniosła złożoność; nie usunęła jej. Przeczytaj ponownie Czasem wygrywa raportowanie.
7. Sztuczka taka jak Siad może być powiązana z setkami tysięcy zwierząt. Master-detail czy lookup ze Sztuczki zwierzęcia do Sztuczki?
Lookup. Zalecenie Salesforce to nie więcej niż 10 000 rekordów podrzędnych na jednym rekordzie nadrzędnym, a popularna sztuczka by je przekroczyła. Master-detail pasuje dla relacji Sztuczki zwierzęcia ze Zwierzęciem, bo sztuczka zwierzęcia nigdy nie zmienia rodzica, a jedno zwierzę zna tylko kilka sztuczek; to także dzięki master-detail zwierzę może zliczać swoją Liczbę sztuczek przez roll-up. Przeczytaj ponownie Siad, zostań, modeluj.
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.