Przejdź do głównej zawartości

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)

Rozdział 2 kursu Data Architect, część 1: Jak zostać architektem danych. Wstecz: Myśleć jak architekt danych Salesforce.

Jedna z rzeczy, które robię podczas pierwszej rozmowy z klientem, to wsłuchiwanie się w rzeczowniki. Partner detaliczny. Odbiorca. Centrum dystrybucyjne. Dostawa. Ciężarówka. Gdzieś w tej rozmowie są zaczątki mojego modelu danych i chcę zacząć go widzieć, zanim ktokolwiek otworzy Konfigurację. W tym rozdziale zrobimy to dwa razy. Najpierw na czymś, co wszyscy rozumieją, na szkole dla psów: właściciele, hodowcy, psy i sztuczki, które znają. Potem na Steve Trucking, firmie dostaw ostatniej mili, której używamy przez cały kurs.

Architekt słucha właściciela firmy dostawczej i szkicuje pierwszy kształt modelu danych w domu na pustyni

Obraz wygenerowany przez AI.

W rozdziale 1 powiedziałem, że model danych to szkielet. Ten rozdział pokazuje, jak zaprojektować szkielet, w kolejności, w jakiej ja to robię: zrozum biznes, opisz dane i dopiero wtedy zdecyduj, jak Salesforce to zaimplementuje. Najpierw konceptualny, potem logiczny, potem fizyczny. Jeśli wskażesz cokolwiek w moim modelu fizycznym i zapytasz „dlaczego to tu jest?”, chcę umieć poprowadzić cię z powrotem przez model logiczny i konceptualny do czegoś, czego biznes naprawdę potrzebuje.

Każdy moduł zaczyna się od psów, w krótkiej sekcji Siad, zostań, modeluj, a potem przenosi ten sam ruch do Steve Trucking. Obserwuj po drodze model psów: to jeden diagram, który rośnie z modułu na moduł, od prostych prostokątów przez relacje i szczegółowy model danych po obiekty Salesforce, a każdy prostokąt zostaje w tym samym miejscu, więc widać dokładnie, co dodaje każdy krok.

  1. Wsłuchaj się w rzeczowniki. Znajdź zaczątki modelu danych w rozmowie z biznesem i zapomnij na chwilę o Salesforce. Pięć psich rzeczowników staje się pięcioma kandydującymi prostokątami.
  2. Narysuj relacje. Jeden czy wiele, wymagana czy opcjonalna, teraz czy w czasie, i pojęcie biznesowe ukryte w relacji wiele-do-wielu: Sztuczka psa i przydział ekipy.
  3. Zbuduj model logiczny. Atrybuty opisujące właściwą rzecz i klucze, które są unikalne, niezmienne, bez znaczenia i nigdy nie są danymi osobowymi. Dlaczego imię psa, telefon jego właściciela, a nawet jego mikrochip nie wystarczą jako klucz.
  4. Umieść dane tam, gdzie ich miejsce. Czym jest normalizacja, potem arkusz z sześcioma psami doprowadzony krok po kroku do trzeciej postaci normalnej i te same trzy pytania w Steve Trucking.
  5. Projektuj do trzeciej postaci normalnej, potem odpuść. Kiedy celowo odchodzę od czystego modelu: użytkownicy, raportowanie, lista wyboru czy lookup, skala, analityka i AI. I dzień, w którym szkoła dla psów zaczyna przyjmować koty.
  6. Przenieś model do Salesforce. Od modelu logicznego do obiektów standardowych i niestandardowych, pól i relacji, master-detail czy lookup, i dlaczego nie projektuje się z poziomu Konfiguracji.

Na koniec sprawdź się z przewodnikiem do nauki do tego rozdziału: lista kontrolna na egzamin, nawyki wykraczające poza niego, słowa do zapamiętania i kilka pytań.

  • Znaleźć encje kandydujące i relacje w rozmowie albo w dokumencie wymagań i zweryfikować je z biznesem.
  • Opisać każdą relację: jej liczność, znaczenie, to, czy jest wymagana, i to, czy liczy się jej historia.
  • Zbudować model logiczny z atrybutami na właściwych encjach i kluczami, które się utrzymają.
  • Stosować 1NF, 2NF i 3NF jako praktyczne pytania i świadomie denormalizować, wiedząc, ile to kosztuje.
  • Zmapować model logiczny na Salesforce i prześledzić każdy wybór fizyczny wstecz do biznesu.

Dalej: Architektura danych Salesforce