Model danych to szkielet

🌐 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ł 2 z 7 w rozdziale Myśleć jak architekt danych, pierwszym rozdziale kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Myśleć jak architekt · Dalej: Test Odwracalności

Pytanie, na które odpowiada ten moduł: dlaczego model danych jest ważniejszy niż wszystko, co na nim zbudowano, i jak go ocenić?

Kiedy uczę architektury danych, wciąż wracam do jednego zdania: model danych to szkielet.

Model danych to szkielet systemu. Wszystko inne buduje się wokół niego i to on trzyma resztę ciała w całości. Patrząc na człowieka, nie widzisz jego kości, ale to one decydują, jak wysoko stoi, jak się porusza i co jest w stanie unieść.

Pomyśl o wszystkim, co budujemy we wdrożeniu Salesforce. Wokół modelu danych budujemy automatyzację. Piszemy pod niego Apex i Flow, które go odczytują i aktualizują. Budujemy integracje, które wysyłają do niego dane i je z niego pobierają. Tworzymy na nim raporty i analizy, a wokół niego projektujemy bezpieczeństwo. Coraz częściej budujemy też agentów AI, którzy muszą te dane rozumieć i na ich podstawie działać. Wszystko to zależy od struktury pod spodem.

Dlatego tak ważne jest, żeby od początku dobrze zaprojektować model danych. Kości można później zmienić. Ale to raczej będzie bolało.

Zacznij od biznesu

Dobry model danych zaczyna się od prostego pytania: co biznes naprawdę musi odwzorować? Nie „jakie mamy obiekty Salesforce?”. I na pewno nie „co mogę szybko zbudować?”.

Najpierw próbujemy zrozumieć biznes. Co jest w nim ważne? Jak te rzeczy są ze sobą powiązane? Kto jest ich właścicielem? Jak zmieniają się w czasie? Co trzeba zapamiętać, a co jest wspólne dla różnych procesów biznesowych? Dopiero gdy to zrozumiemy, powinniśmy zacząć przekładać to na obiekty, pola i relacje.

Brzmi to oczywiście. W praktyce bardzo łatwo zrobić to odwrotnie. Ktoś widzi coś, co wygląda jak szansa sprzedaży, zgłoszenie albo zasób, i od razu zaczyna wokół tego projektować. Czasem to dokładnie właściwy ruch. Czasem próbujemy wcisnąć kwadratowy kołek w okrągły otwór, a kiedy wokół tej decyzji zbuduje się już dość dużo, wyciągnięcie kołka staje się bardzo kosztowne.

Oto pytanie, które słyszę bez przerwy. Firma klienta może mieć wiele punktów dostaw. Czy każdy punkt powinien być kontem, czy obiektem niestandardowym? Zanim odpowiesz, zauważ, co musisz najpierw wiedzieć: czym jest punkt dostaw dla tego biznesu i co się z nim dzieje. To właśnie modelowanie biznesu przed obiektami. (Moją odpowiedź podam w rozdziale 3.)

Wspierać. Rosnąć. Działać.

Kiedy patrzę na model danych, chcę, żeby przeszedł trzy testy: wspierał biznes, rósł razem z biznesem i działał wydajnie.

Wspierać. Model musi wspierać to, co biznes naprawdę próbuje osiągnąć. Jest wielka różnica między modelem, który technicznie potrafi przechować dane, a takim, który dobrze odwzorowuje biznes. Jeśli ciągle dodaję dziwne pola, specjalne flagi, skomplikowaną automatyzację i wyjątki, bo model nie do końca pasuje, zaczynam się zastanawiać, czy problem naprawdę leży w automatyzacji. Może to model jest zły. Dobry model powinien sprawiać, że biznes staje się łatwiejszy do zrozumienia, a nie trudniejszy.

Rosnąć. Mówiąc o wzroście, nie mam na myśli tylko większej liczby rekordów. Wolumen ma znaczenie: dziesięć tysięcy rekordów i sto milionów to zupełnie inne problemy. Ale firmy rosną też w złożoności. Dodają produkty, wchodzą na nowe rynki, przejmują inne firmy, zmieniają procesy, dodają kanały i podłączają nowe systemy. Odkrywają, że coś, co uważały za jedną rzecz, to w rzeczywistości pięć różnych rzeczy. Model, który pięknie działa dziś, może stać się pułapką, jeśli nie ma w nim miejsca na jutro. Dlatego wolę projekty, które rosną przez dodawanie, od projektów, które ciągle zmieniają to, co już istnieje. Dodanie czegoś nowego jest zwykle łatwiejsze niż przedefiniowanie czegoś, od czego zależą dziesiątki innych rzeczy.

Działać. Dane nie leżą bezczynnie. Zapisujemy je, wyszukujemy, odpytujemy, udostępniamy, raportujemy i integrujemy, a coraz częściej systemy AI pobierają je jako kontekst, zanim zaczną działać. Model może pięknie wyglądać na diagramie, a i tak być fatalny w eksploatacji. Projektujemy więc zarówno pod kątem tego, jak dane są przechowywane, jak i tego, jak będą używane.

I model musi działać dalej. Musi działać w skali: gdy rośnie liczba użytkowników, gdy rośnie wolumen danych, w realnych warunkach i w szczytach, w najbardziej obciążony dzień roku, a nie w przeciętny. I musi działać dalej, gdy wydarzy się coś nieoczekiwanego.

Wspierać. Rosnąć. Działać. Do tych trzech testów będziemy wracać przez cały kurs.

Click to enlarge

Zbyt płaski, zbyt skomplikowany albo po prostu zły

Widziałem, jak modele danych idą w złą stronę na trzy sposoby.

Pierwszy to wybór złej rzeczy na samym początku. Używamy obiektu standardowego, bo wygląda na wystarczająco podobny, a potem latami dodajemy wyjątki, bo nigdy tak naprawdę nie pasował. To jest ten kwadratowy kołek.

Drugi to model zbyt płaski. Wszystko trafia do jednego obiektu i na początku wydaje się to cudownie proste. Potem biznes rośnie i odkrywamy, że niektóre z tych rzeczy mają własny cykl życia, mogą występować w wielu egzemplarzach, potrzebują własnych zabezpieczeń albo mają własne relacje. Nagle odwzorowujemy relację jeden-do-wielu polami Pole 1, Pole 2 i Pole 3 albo coraz bardziej skomplikowanymi flagami i automatyzacją. Model nie zostawił nam miejsca na wzrost.

Trzeci to błąd odwrotny: nadmierna normalizacja. Tworzymy elegancki diagram, obiekt za obiektem, każde pojęcie idealnie oddzielone. Technicznie piękne, w praktyce nieznośne. Użytkownicy z trudem to rozumieją, a układy stron i strony Lightning, z listą powiązanych rekordów za listą powiązanych rekordów, zaczynają sprawiać wrażenie bez dna. Zapytania się komplikują, automatyzacja przechodzi przez coraz więcej relacji, raportowanie staje się trudniejsze, a platforma wykonuje więcej pracy, żeby odpowiedzieć na zwykłe pytania biznesowe.

Co jest więc poprawne: płasko czy znormalizowanie? Nie ma na to wzoru. Masz w głowie obraz optymalnego modelu i rozumiesz kompromisy, gdy się od niego oddalasz. To jest sztuka architektury i wrócimy do niej w module 4 oraz w następnym rozdziale, w którym uczymy się modelować. Na razie zapamiętaj, że sama struktura jest decyzją architektoniczną.

Click to enlarge

Ostrożnie ze zmienianiem szkieletu

Gdy system już działa, staję się bardzo ostrożny wobec fundamentalnych zmian w modelu danych.

Załóżmy, że pole tekstowe istnieje od lat i ktoś mówi: „Właściwie już tak tego nie używamy. Zmieńmy je na liczbę”. Brzmi jak zmiana pola. Ale co od tego pola zależy? Flow, Apex, raporty, integracje, potoki danych, aplikacje zewnętrzne, agenci AI. I co się stanie z danymi historycznymi? Sama platforma nie pozwoli zmienić typu pola, dopóki odwołuje się do niego kod lub Flow, co pokazuje, jak daleko sięga taka zmiana.

Czasem właściwą odpowiedzią nie jest przerabianie tego, co już istnieje. Zależnie od tego, jak poważna jest zmiana, wolę stworzyć coś nowego, przeprowadzić świadomą migrację i wycofać starą strukturę:

Dodawaj, zamiast przerabiać. Wycofuj, zamiast zaskakiwać.

Salesforce daje ci nawet sposób, żeby zapisać to w metadanych: Field Usage pola można ustawić na DeprecateCandidate, czyli „zaplanowane do wycofania i już nieużywane”. To oznacza pole dla każdego, kto czyta obiekt; nie ukrywa go, więc jego wycofanie nadal jest decyzją, którą musisz przeprowadzić.

Bo kiedy inne części architektury od czegoś zależą, zmiana jego znaczenia może być dużo groźniejsza niż zmiana jego nazwy. Najgorszy przypadek to pole, którego nazwa zostaje ta sama, a zawartość się zmienia: wszystko dalej w łańcuchu wciąż ufa nazwie.

Click to enlarge

Nawet coś tak prostego jak zaznaczenie pola wyboru Wymagane przy polu może stać się bombą zegarową. Jeśli masz już zebrane dane, część rekordów nie będzie miała tego pola wypełnionego. Potem, po dniach, tygodniach albo miesiącach, ktoś aktualizuje jeden z tych rekordów i zapis kończy się błędem z powodu wymaganego pola, a nikt nie zna tej wartości. Prosta zmiana, taka jak oznaczenie pola jako wymaganego, może mieć niezamierzone i opóźnione skutki. Do pól wymaganych i do tego, kiedy wartość jest naprawdę znana, wrócimy w rozdziale 3.

Poza egzaminem: AI też buduje na szkielecie. Poproś narzędzie AI o zbudowanie aplikacji, a w kilka minut wygeneruje obiekty, pola, Flow, Apex, komponenty i testy. Jeśli pierwotny model danych był zły, nie uniknęliśmy skutków złej decyzji; przyspieszyliśmy je, bo każda wygenerowana warstwa to kolejna rzecz zależna od tej struktury. Dlatego chcę, żeby model danych wygenerowany przez AI przeglądał architekt, człowiek, który go rozumie i za niego odpowiada. Moduł 7 rozwija ten temat.

Najpierw szkielet

W tym kursie będziemy rozmawiać o wielu technologiach: obiektach i relacjach, dużych wolumenach danych, zapytaniach, integracji, migracji, transakcjach, bezpieczeństwie, Data 360 i AI. Pod tym wszystkim leży model danych.

Jeśli model wspiera biznes, może rosnąć razem z nim i działa wydajnie przy tym, jak będziemy używać danych, zbudowaliśmy solidny fundament. Jeśli fundament będzie zły, wszystko później stanie się trudniejsze.

Model danych to szkielet. Architekci powinni być bardzo ostrożni, kiedy projektują szkielet. Zmiany w istniejących strukturach mogą mieć kaskadowe konsekwencje.

Co tu decyduje architekt

• Czy model wspiera biznes, może z nim rosnąć i działa wydajnie przy tym, jak dane będą używane.
• Czy pojęcie pasuje do obiektu standardowego, czy jest kwadratowym kołkiem.
• Jak płaski albo jak znormalizowany ma być model i dlaczego.
• Czy zmiana szkieletu powinna być dodaniem, migracją albo wycofaniem, a nie zmianą w miejscu.

Do zgłębienia

• Considerations for Converting the Field Type of a Custom Field (opens in a new tab), Pomoc Salesforce (po angielsku, sprawdzono 2026-10-02; ponownie sprawdzono 2026-10-12): które zmiany typu mogą powodować utratę danych i dlaczego nie można zmienić typu pola, do którego odwołują się Apex, Flow lub procesy.
• Data Classification Metadata Fields (opens in a new tab), Pomoc Salesforce (po angielsku, sprawdzono 2026-10-02; ponownie sprawdzono 2026-10-12): wartości Field Usage (Active, DeprecateCandidate, Hidden) i pozostałe pola klasyfikacji.