Przenieś model do 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

Moduł 6 z 6 w rozdziale Modelowanie danych, które coś znaczą, rozdziale 2 kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Projektuj do trzeciej postaci normalnej, potem odpuść · Dalej: przewodnik do nauki do rozdziału, a potem następny rozdział: Architektura danych Salesforce

Pytanie, na które odpowiada ten moduł: jak logiczny model danych staje się fizycznym modelem danych w Salesforce?

Wreszcie porozmawiamy o Salesforce. Jeśli od początku kusiło cię, żeby zamienić każdy prostokąt w obiekt, teraz możesz. Ale zwróć uwagę na kolejność, w jakiej tu doszliśmy: zrozumieliśmy biznes, opisaliśmy dane, umieściliśmy każdy fakt tam, gdzie jego miejsce, i zdecydowaliśmy, gdzie celowo od tego odstąpimy. Dopiero teraz pytam, jak Salesforce powinien to zaimplementować. To jest kolejność, którą chcę, żeby udało ci się zapamiętać: konceptualny → logiczny → fizyczny. Model konceptualny opisuje biznes. Model logiczny opisuje dane. Model fizyczny opisuje, jak naprawdę to zbudujemy.

Siad, zostań, modeluj

Krok fizyczny najłatwiej zobaczyć na czymś małym, więc zwierzęta idą pierwsze.

Kim są firmy i ludzie? Hodowca to firma, więc staje się kontem z typem rekordu Hodowca. Właściciel też jest kontem, albo kontem osoby, z typem rekordu Właściciel. Dwa rodzaje tego samego obiektu standardowego, obok siebie na górze diagramu, dokładnie tam, gdzie są od modułu 1.

Co nie ma standardowego domu? Zwierzę, Rasa, Sztuczka, Sztuczka zwierzęcia i Ocena sztuczki stają się obiektami niestandardowymi. A pamiętasz gatunek, który w module 5 skopiowaliśmy na zwierzę? Tu dostaje swoje zadanie: staje się typem rekordu Zwierzęcia, Pies albo Kot. Jeden obiekt z dwoma typami rekordów, każdy z własnym układem strony i wartościami list wyboru, zamiast obiektu Pies i obiektu Kot.

Które relacje są master-detail? Master-detail stosuję tylko tam, gdzie rekord podrzędny nigdy nie zmieni rodzica. Sztuczka zwierzęcia należy do swojego zwierzęcia na całe życie, a każda Ocena sztuczki należy do swojej Sztuczki zwierzęcia, więc obie są master-detail. To od razu się opłaca: master-detail pozwala zwierzęciu trzymać podsumowanie zbiorcze (roll-up) swoich Sztuczek zwierzęcia, więc licznik Liczba sztuczek z modułu 5 sam pozostaje aktualny. Zwierzęta zmieniają jednak domy, więc Właściciel to lookup.

Które są lookupami? Salesforce nie zaleca więcej niż 10 000 rekordów podrzędnych na jednym rekordzie nadrzędnym. Popularna sztuczka, taka jak Siad, popularna rasa albo duży hodowca łatwo mogą to przekroczyć, więc Sztuczka zwierzęcia wskazuje na swoją Sztuczkę lookupem, a zwierzę tak samo wskazuje na swoją Rasę i Hodowcę. I unikaj relacji polimorficznych, gdzie się da, czyli takich, w których jedno pole może wskazywać na kilka typów obiektów. Są wygodne pierwszego dnia, a trudniejsze dla wszystkiego, co musi je później czytać: raportów, integracji, a teraz agentów.

Co zostaje poza platformą? Jeśli zwierzę nosi obrożę GPS, która zgłasza, gdzie jest, tej lokalizacji w ogóle nie trzeba kopiować. Może być obiektem zewnętrznym, czytanym na żywo z systemu śledzenia obroży.

Click to enlarge

Każda decyzja na tym diagramie wynika z czegoś, co postanowiliśmy wcześniej, i właśnie o to chodzi. Teraz ten sam krok dla Steve Trucking.

Zacznij od modelu logicznego

Nasz model logiczny Steve Trucking zawiera teraz partnera detalicznego, centrum dystrybucyjne, manifest, dostawę, pozycję dostawy, odbiorcę, trasę, przystanek, ekipę, ciężarówkę i przydział ekipy. To pojęcia biznesowe i teraz mogę zacząć mapować je na Salesforce.

Partner detaliczny może być kontem. Dostawa może odpowiadać czemuś, co Salesforce już ma dla zaplanowanej pracy w terenie, albo może stać się obiektem niestandardowym. Dla manifestu nie ma niczego standardowego, co by pasowało, więc pewnie stanie się niestandardowy. A odbiorca to naprawdę trudne pytanie: konto osoby, kontakt czy po prostu informacje na dostawie? Na to pytanie porządnie odpowiemy w następnym rozdziale.

Ważnym słowem nadal jest może. Nie zakładaj implementacji tylko dlatego, że pojęcie biznesowe brzmi jak obiekt Salesforce. Właśnie dlatego najpierw zbudowaliśmy model logiczny: daje nam coś, względem czego możemy testować projekt w Salesforce.

Encja biznesowa to nie automatycznie obiekt niestandardowy

Oto pułapka, której chcę, żeby administratorzy unikali: „Zidentyfikowaliśmy jedenaście encji, więc potrzebujemy jedenastu obiektów niestandardowych”. Nie. Encja logiczna mówi nam, że pojęcie biznesowe ma znaczenie. Nie dyktuje, jak Salesforce ma je przechowywać. Pojęcie może stać się obiektem standardowym, obiektem niestandardowym, relacją między obiektami, polem albo kilkoma polami, wartością zarządzaną w konfiguracji albo danymi, które w ogóle mieszkają poza Salesforce (zdjęcia z dostaw Steve Trucking to dobry kandydat). Te wybory dokonują się w modelu fizycznym i właśnie dlatego nie dokonaliśmy ich podczas pierwszej rozmowy.

Atrybuty stają się polami fizycznymi

To samo przejście dotyczy atrybutów. Nasza logiczna ciężarówka ma numer floty, VIN, markę, model, rok modelowy, numer rejestracyjny i status. Teraz decydujemy, jak fizycznie istnieją: który obiekt jest ich właścicielem, jakich typów pól używają, które są wymagane, które muszą być unikalne, które są identyfikatorami zewnętrznymi, które wymagają walidacji, które są wyliczane, a nie przechowywane, i które są wrażliwe. Na poziomie logicznym pytaliśmy, co znaczy ciężarówka. Na poziomie fizycznym pytamy, jak Salesforce będzie ją odwzorowywać. To różne pytania.

Click to enlarge

Relacje stają się decyzjami dotyczącymi platformy

Cały czas, który poświęciliśmy relacjom, tu się zwraca. Wiemy już, czy każda z nich jest jeden-do-jednego, jeden-do-wielu czy wiele-do-wielu, wymagana czy opcjonalna i czy liczy się jej historia. Teraz decydujemy, jak Salesforce ją zaimplementuje: lookup, master-detail albo obiekt łączący Salesforce (Salesforce Junction Object), a może obiekt łączący z własnymi atrybutami, bo, jak odkryliśmy, sama relacja może mieć znaczenie biznesowe.

Przypomnij sobie przydział ekipy. Mogliśmy zacząć ten rozdział od słów: „Utwórzmy obiekt łączący Salesforce między ekipą a ciężarówką”. Zobacz, co byśmy pominęli: dlaczego relacja istnieje, czy potrzebuje daty i trasy, czy ma status i czy reklamacja szkody kilka tygodni później będzie potrzebować jej historii. Te pytania biznesowe mówią nam, czym jest przydział ekipy. Dopiero potem powinniśmy decydować, jak Salesforce go zbuduje i czy Salesforce nie ma już czegoś, co wykonuje tę pracę.

Teraz narysuj model fizyczny

Diagram znowu się zmienia. Model konceptualny pokazywał pojęcia biznesowe i proste linie. Model logiczny dodał atrybuty, klucze, liczność i encje ukryte w relacjach. Teraz model fizyczny zaczyna wyglądać jak Salesforce: obiekty standardowe, obiekty niestandardowe, pola, typy relacji i to, co mieszka poza platformą.

Click to enlarge

Chcę, żeby udało ci się położyć te trzy diagramy obok siebie i zobaczyć przejście: nie trzy niepowiązane diagramy, ale ten sam biznes na trzech poziomach.

Słowo o tym, jak je rysuję, bo układ jest częścią przekazu. Główny obiekt umieszczam pośrodku, trochę niżej. Jeśli ma obiekty nadrzędne, umieszczam je trochę wyżej, żeby model czytało się z góry na dół i od lewej do prawej, tak jak myśli o tym biznes. Dane referencyjne idą na bok. Kolor też coś znaczy: Salesforce zawsze robię na niebiesko, a dla własnych systemów firmy wybieram kolor, zwykle zielony, bo zielony to miły, przyjazny kolor. Nie używam czerwonego, a żółcie są trochę ostre. Gdy model jest tak ułożony, po prostu do mnie śpiewa. Wiele diagramów, które spotkasz, to tak naprawdę zarządzanie przestrzenią: jak zaparkować wszystkie samochody w zatłoczonym garażu? Wolę namalować logiczny obraz, który umysł potrafi ogarnąć.

Model fizyczny musi szanować platformę

Salesforce to nie jest uniwersalna relacyjna baza danych. Ma swoje zdanie o relacjach, własności, bezpieczeństwie i raportowaniu. Ma limity, zachowanie zapytań i automatyzację oraz architekturę, która wpływa na to, jak model zachowuje się w skali. Model logiczny, który na tablicy wygląda idealnie, może więc wymagać zmian, gdy staje się fizyczny. To nie Salesforce staje na drodze. To znaczy, że platforma ma kształt, a dobrzy architekci ten kształt rozumieją. O tym właśnie jest następny rozdział.

Czasem model fizyczny będzie też celowo różnił się od czystego modelu logicznego z powodu decyzji o denormalizacji, które podjęliśmy w module 5. To w porządku, o ile potrafimy wyjaśnić dlaczego.

Nie projektuj z poziomu Konfiguracji

Jest nawyk, który chcę, żeby udało ci się przełamać, jeśli go masz: zaczynanie architektury danych od Konfiguracja → Menedżer obiektów → Nowy obiekt niestandardowy (Setup → Object Manager → New Custom Object) i wymyślanie modelu po drodze. Salesforce sprawia, że tworzenie rzeczy jest niezwykle łatwe; to jedna z jego mocnych stron i jeden z powodów, dla których słabe modele danych powstają tak szybko. Kilka kliknięć i masz obiekt, kilka kolejnych i masz pola i relację. Potem przychodzą dane, powstają Flow, tworzone są raporty, zależą od tego integracje, a obiekt, który utworzono w pięć minut, staje się bardzo drogi do zmiany. To Test Odwracalności z rozdziału 1. Zanim więc klikniesz Nowy obiekt niestandardowy, narysuj model.

Fizyczny nie znaczy trwały

Jest jeszcze jeden powód, dla którego trzymam te trzy modele osobno: technologia się zmienia. Dziś część danych Steve Trucking mieszka w Salesforce core. Jutro część z nich może mieszkać w Data 360, w hurtowni albo w systemie, którego jeszcze nie wybraliśmy, a asystent AI potrzebuje własnej reprezentacji. Architektura fizyczna może się zmieniać, a pojęcia biznesowe pozostają zaskakująco stabilne: partnerzy detaliczni, dostawy i odbiorcy nadal istnieją. To właśnie czyni model logiczny cennym. To trwały opis biznesu, który nie jest przywiązany do dzisiejszej implementacji.

Co tu decyduje architekt

Zamieniając model logiczny w fizyczny model Salesforce, decyduję:

• Które encje biznesowe odpowiadają standardowym możliwościom Salesforce, a które potrzebują obiektów niestandardowych albo innej reprezentacji.
• Jak atrybuty logiczne stają się polami fizycznymi i jak relacje są implementowane na platformie.
• Gdzie w projekcie fizycznym jest miejsce na świadomą denormalizację.
• Które dane należą do Salesforce, a które gdzie indziej.
• Które cechy platformy wymagają, żeby model fizyczny różnił się od logicznego.

A co najważniejsze, chcę umieć prześledzić każdą decyzję wstecz. Jeśli wskażesz coś w moim modelu fizycznym i zapytasz: „Dlaczego to tu jest?”, powinienem umieć poprowadzić cię z powrotem przez model logiczny i konceptualny do czegoś, czego biznes naprawdę potrzebuje: biznes → konceptualny → logiczny → fizyczny.

Poza egzaminem: co zmienia AI. AI potrafi teraz w jednym skoku przejść od dokumentu wymagań do obiektów i pól Salesforce. To sprawia, że kolejność jest ważniejsza, a nie mniej ważna: jeśli przeskakuje od wymagań do konfiguracji, poproś ją, żeby pokazała, co działo się pomiędzy: co uznała za encję, jakie klucze wybrała, jakie relacje założyła i gdzie zdenormalizowała. To decyzje architektoniczne, a architekt nadal musi je widzieć.

Zaczęliśmy ten rozdział od pierwszej rozmowy, wsłuchując się w rzeczowniki, a kończymy go modelem fizycznym, który możemy prześledzić wstecz aż do biznesu. Skoro zdecydowaliśmy się budować na Salesforce, następne pytanie sięga głębiej: na jakiej platformie danych właściwie budujemy?

Do zgłębienia

• Designing Record Access for Enterprise Scale: Parent-Child Data Skew (opens in a new tab), Salesforce Developers, Winter ‘27 (po angielsku, sprawdzono 2026-10-02): „konfiguruj relacje nadrzędny-podrzędny tak, by na jeden rekord nadrzędny przypadało nie więcej niż 10 000 rekordów podrzędnych”. To wytyczna dotycząca nierównomiernego rozkładu danych (data skew), a nie twardy limit; rozdział 7 wchodzi w to głębiej.
• Roll-Up Summary Field (opens in a new tab), Pomoc Salesforce (po angielsku, sprawdzono 2026-10-12): pole podsumowania zbiorczego liczy lub sumuje rekordy szczegółowe przez relację master-detail.