Projektuj do trzeciej postaci normalnej, potem odpuść
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)
Moduł 5 z 6 w rozdziale Modelowanie danych, które coś znaczą, rozdziale 2 kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Umieść dane tam, gdzie ich miejsce · Dalej: Przenieś model do Salesforce
Pytanie, na które odpowiada ten moduł: kiedy celowo odejść od czystego, znormalizowanego modelu?
W poprzednim module mówiłem ci, żeby projektować do trzeciej postaci normalnej.
Teraz powiem ci, żeby ją łamać.
Czasami.
To ważne rozróżnienie. Jest wielka różnica między przypadkowym zbudowaniem bałaganiarskiego modelu danych a świadomą denormalizacją czystego modelu. Jeśli w ogóle nie rozumiesz, gdzie należą dane, kopiowanie ich gdzie indziej to nie architektura. To zwykła duplikacja.
Ale gdy rozumiem czysty model logiczny, mogę świadomie zdecydować, że ukształtuję dane inaczej dla ludzi i systemów, które z nich korzystają.
Projektuj do trzeciej postaci normalnej, gdzie to wykonalne. Potem odpuść, gdy to konieczne.
Zwróć uwagę, czego to zdanie nie mówi. Nie mówi, że trzecia postać normalna jest łatwiejsza do zrozumienia. Czasem jest trudniejsza: w pełni znormalizowany model potrafi rozrzucić jedną ideę biznesową po pięciu obiektach, a osoby, które z niego korzystają, muszą ją składać z powrotem w głowie. Normalizacja mówi mi, gdzie należy każdy fakt. Nie obiecuje, że to najłatwiejszy kształt do czytania, używania czy raportowania. Właśnie dlatego odpuszczanie to umiejętność projektowa, a nie porażka.
Zacznij od zamodelowania prawdy. Potem zdecyduj, jak tę prawdę trzeba dostarczyć.
Siad, zostań, modeluj
Dział zatytułowany „Siad, zostań, modeluj ”Wracamy do psów i tym razem podejmujemy kilka świadomych decyzji.
Rasa: lista wyboru czy osobna tabela? Przepuść ją przez pytania, które podam ci w dalszej części tego modułu. Czy jest więcej niż jedna kolumna informacji? Tak: przynajmniej wielkość. Ile wartości? Związki kynologiczne uznają kilkaset ras (sam American Kennel Club wymienia 205), znacznie ponad moją praktyczną granicę około 20. Rasa zasługuje więc na własną tabelę, a każdy pies wskazuje na swoją rasę. To rozstrzyga pytanie, które nosimy od modułu 1: Rasa to osobny prostokąt.
Poziom umiejętności: lista wyboru. Uczy się, Dobry, Ekspert. Trzy etykiety, nic więcej o nich do powiedzenia, i nie będą się zmieniać. Dokładnie do tego służy lista wyboru.
Ile sztuczek zna każdy pies? Odpowiedź już jest w modelu: policz rekordy Sztuczki psa danego psa. Ale trener chce mieć tę liczbę w każdym raporcie, sortować po niej i filtrować, bez budowania raportu na dwóch tabelach. Więc odpuszczam i trzymam licznik Liczba sztuczek bezpośrednio na psie. To kopia. Prawda nadal mieszka w Sztuczce psa; licznik jest jej odwzorowaniem i musi za nią nadążać. Salesforce daje nam czysty sposób, żeby dokładnie to zrobić, i zobaczymy go w module 6.
A teraz zwrot akcji: szkoła dla psów zaczyna przyjmować koty. Co robimy? Jedna opcja: dodać tabelę Kot obok tabeli Pies i Sztuczkę kota obok Sztuczki psa. Wszystko się podwaja: dwa egzemplarze każdego ekranu, dwa każdego raportu, a w dniu, w którym przyjmą króliki, trzy. Druga opcja: zrobić krok w tył i zauważyć, że kot ma właściciela, może hodowcę, rasę, datę urodzenia i, przy odrobinie cierpliwości, sztuczkę czy dwie. Te same fakty i te same relacje co pies. Uogólniamy więc: Zwierzę z Gatunkiem, pies albo kot. Każda rasa też należy do gatunku i to tam gatunek naprawdę mieszka: labrador to pies. Zwierzę nosi kopię, celowo, żeby każdy ekran i raport mógł zacząć od „pies czy kot?” bez sprawdzania rasy. Kolejna świadoma kopia, a w module 6 dostanie własne zadanie.
To projektowanie z myślą o zmianie i to jest kompromis. Uogólnij za wcześnie, a wszystko stanie się mglistą „Rzeczą” z polem typu, którego nikt nie rozumie. Uogólniam wtedy, gdy biznes naprawdę przynosi mi drugi rodzaj, a oba mają prawie wszystko wspólne, tak jak tu psy i koty. Gdyby koty potrzebowały zupełnie innych faktów, zastanowiłbym się dwa razy.
Teraz te same rodzaje decyzji w Steve Trucking, gdzie stawka jest wyższa.
Najczystszy model to nie zawsze najlepszy system
Dział zatytułowany „Najczystszy model to nie zawsze najlepszy system ”Wyobraź sobie ekipę na przystanku. Dostawa ma swoje pozycje. Instalacja ma listę kontrolną. Każdy krok wymaga zdjęć. Odbiorca podpisuje.
Znormalizowany model jest piękny: dostawa → pozycja dostawy → lista kontrolna instalacji → zdjęcie, każde tam, gdzie jego miejsce.
Potem siadam z ludźmi, którzy naprawdę z niego korzystają. Ekipa zamyka mniej więcej dziesięć przystanków dziennie, na podjazdach, często bez zasięgu. Jeśli mój piękny model prowadzi ich przez labirynt ekranów i list powiązanych rekordów, żeby zamknąć jeden przystanek, mam problem architektoniczny.
Model danych to nie jedyna rzecz, którą projektujemy.
Projektujemy system.
Czasem wygrywa doświadczenie użytkownika
Dział zatytułowany „Czasem wygrywa doświadczenie użytkownika ”To jeden z powodów, dla których czasem odchodzę od idealnie znormalizowanego modelu: doświadczenie użytkownika.
Może jakieś pojęcie technicznie mogłoby być osobną encją, ale jego wydzielenie dodaje złożoności, która daje bardzo niewiele. Może rekord nadrzędny z kilkoma poziomami rekordów podrzędnych jest akademicko czysty, ale wprowadzanie i utrzymywanie danych to męka. Może pojęcie jest małe, stabilne i używane głównie jako wybór z listy.
W tym miejscu przestaję pytać tylko: „Gdzie teoretycznie należy ten fakt?” i zaczynam pytać: „Jak ten system będzie naprawdę używany?”
To nie znaczy, że każda skarga na dodatkowe kliknięcie spłaszcza model. Znaczy, że użyteczność to uprawniony czynnik architektoniczny.
Czasem wygrywa raportowanie
Dział zatytułowany „Czasem wygrywa raportowanie ”Raportowanie to kolejny częsty powód.
Każdy partner detaliczny chce karty wyników: dostawy na czas według regionu i miesiąca. W czystym modelu dostawa zna swoje centrum dystrybucyjne, a CD zna swój region. Technicznie możemy przez to przejść.
Ale czy potrafi to narzędzie raportowe? Czy potrafią to ludzie, którzy sami budują swoje raporty? Czy mogą odpowiedzieć na pytanie bez architektury raportowej bardziej skomplikowanej niż samo pytanie?
Wtedy mogę skopiować albo wyprowadzić region na dostawę, bliżej miejsca, gdzie jest używany.
Teraz wprowadziłem duplikację. Potrzebuję więc kolejnego pytania: kto jest właścicielem prawdy?
Jeśli wartość źródłowa się zmieni, co stanie się z moją kopią? Powinna się zmienić? Czy powinna zachować to, co było prawdą w chwili dostawy? To różne wymagania.
Denormalizacja nie usuwa złożoności.
Ona ją przenosi.
Lookup czy lista wyboru?
Dział zatytułowany „Lookup czy lista wyboru? ”Oto mniejszy przykład, na który administratorzy Salesforce trafiają bez przerwy. Użytkownik musi wybrać z zestawu wartości. Czy tworzę kolejną encję i się z nią wiążę, czy używam listy wyboru?
Weźmy status dostawy: zaplanowana, załadowana, w drodze, na miejscu za chwilę, dostarczona, zainstalowana, wyjątek, zwrócona. Krótka, stabilna lista etykiet. Lista wyboru to dokładnie to, czego chcę.
Teraz weźmy rodzaj przystanku: tylko dostawa, dostawa z instalacją, dostawa z wywozem starego sprzętu. Ten niesie własne informacje: ile trwa przystanek, jakich umiejętności potrzebuje ekipa, która lista kontrolna instalacji obowiązuje. Zmienia się niezależnie i zarządza nim biznes. To encja, a nie etykieta.
Jeśli tworzę obiekt dla każdego pojęcia, które teoretycznie da się znormalizować, mogę zbudować technicznie piękny system, z którego nikt nie lubi korzystać. Jeśli zamieniam każde pojęcie w listę wyboru, bo tak łatwo, mogę bardzo szybko zapędzić się w kozi róg.
Pytam więc: czy ma własne informacje? Relacje? Czy zmienia się niezależnie? Czy trzeba nim zarządzać jako danymi? Czy biznes może w końcu potrzebować od niego czegoś więcej niż etykiety?
Oto pytania, które naprawdę zadaję na sesji projektowej.
Czy jest więcej niż jedna kolumna informacji? Jeśli wartość potrzebuje opisu, czasu trwania, listy umiejętności, właściciela, to już nie jest etykieta.
Ile wartości? Moja reguła kciuka to około 20. Powyżej 20 wartości lista wyboru zaczyna się sypać i czas pomyśleć o obiekcie. Stany USA, w liczbie pięćdziesięciu, to wyjątek, z którym żyjemy, a kraje są jeszcze gorsze; szczerze, czy ktoś kocha listy wyboru z krajami? Moim zdaniem są irytujące.
Czy wartości powstają z czasem i kto je dodaje? Dodanie wartości listy wyboru to zmiana konfiguracji, czyli zadanie dla administratora. Jeśli biznes dodaje wartości co tydzień, a osoby, które je dodają, nie są administratorami, lista wyboru stawia zgłoszenie przed każdą nową wartością.
Czy ludzie muszą po tym filtrować i raportować? Listy wyboru świetnie się do tego nadają. Lookupy nie są tak wygodne. Każdy lookup dodaje skok: typ raportu przechodzi tylko przez krótki łańcuch powiązanych obiektów (niestandardowy typ raportu pozwala na co najwyżej cztery relacje między obiektami), ekran zamienia się w listy powiązanych rekordów wewnątrz list powiązanych rekordów, a kod się komplikuje.
Lista wartości często zaczyna życie jako lista wyboru i z czasem zapracowuje na własny obiekt. Pozwól jej na niego zapracować.
Czasem skala zmienia odpowiedź
Dział zatytułowany „Czasem skala zmienia odpowiedź ”Projekt, który pięknie działa przy kilku tysiącach rekordów, przy milionach może zachowywać się zupełnie inaczej.
Nie patrz więc tylko na diagram. Znaj liczby.
Steve Trucking realizuje około miliona dostaw rocznie, przy wzroście 30 procent rocznie. Każda dostawa zbiera około ośmiu aktualizacji statusu. To osiem milionów rekordów statusu w tym roku i około 13,5 mln rocznie w trzecim roku. Do tego cztery albo pięć milionów zdjęć rocznie.
Ten sam model. Zupełnie inna architektura.
Dużo głębiej wejdziemy w to w części Architektura w skali (Architecting at Scale). Na razie zapamiętaj: wolumen może zmienić decyzję w modelowaniu danych. Relacja logicznie poprawna nie jest automatycznie najlepszym projektem fizycznym w każdej skali.
Różni odbiorcy chcą różnych kształtów
Dział zatytułowany „Różni odbiorcy chcą różnych kształtów ”Dotąd myśleliśmy o systemie operacyjnym. Dyspozytorzy układają trasy dostaw. Ekipy zamykają przystanki. System zmienia się w miarę działania biznesu.
Ale biznes chce też analizować lata historii. Którzy partnerzy i które regiony się spóźniają? Jak zmienił się czas dostawy? Jak często instalacje wymagają drugiej wizyty?
System analityczny może chcieć tych samych informacji uporządkowanych inaczej. Usłyszysz terminy takie jak hurtownia danych, fakt, wymiar i schemat gwiazdy. Nie rozkładamy ich tu na części; w Steve Trucking to hurtownia Snowflake, a wrócimy do niej później w kursie.
Na razie: różni odbiorcy mogą potrzebować różnych kształtów tej samej prawdy.
AI dodaje kolejnego odbiorcę
Dział zatytułowany „AI dodaje kolejnego odbiorcę ”A teraz jest jeszcze jeden odbiorca: AI.
Odbiorca pisze SMS-a: „Gdzie moja dostawa?”. Asystent AI mógłby odczytać coś takiego:
Dostawa 10427, trasa 3312, przystanek 7, ciężarówka 117, okno 13:00–15:00.
Tradycyjna aplikacja całkiem dobrze radzi sobie z przechodzeniem po tych relacjach. Ale żeby odpowiedzieć odbiorcy, asystent potrzebuje kontekstu złożonego z kilku miejsc:
Twoja zmywarka od Redrock to siódmy przystanek na dzisiejszej trasie z centrum dystrybucyjnego w Phoenix. Ciężarówka jest trzy przystanki od ciebie, a nadal mieścisz się w oknie 13:00–15:00.
Wzięliśmy informacje z kilku powiązanych encji i złożyliśmy z nich bardziej płaską, bogatą w kontekst reprezentację dla jednego konkretnego odbiorcy.
To nie znaczy, że niszczę swój znormalizowany model. I na pewno nie znaczy „AI lubi płaskie dane, więc wrzućmy wszystko do jednego gigantycznego obiektu”. Nie rób tego.
Źródło prawdy pozostaje czyste. AI dostaje reprezentację zbudowaną pod zadanie, które wykonuje. To ta sama idea, którą przed chwilą widzieliśmy przy analityce:
Jedno źródło prawdy może obsługiwać wiele kształtów do wykorzystania.
Dużo głębiej w ugruntowanie (grounding) i wyszukiwanie wejdziemy później w kursie.
Nie twórz wielu prawd
Dział zatytułowany „Nie twórz wielu prawd ”Jest tu pewne niebezpieczeństwo.
Jeśli skopiuję region na dostawę na potrzeby raportowania, wyślę spłaszczoną wersję do Snowflake i zbuduję bogatą w kontekst wersję dla asystenta AI, która z nich jest poprawna?
To pytanie wymaga odpowiedzi. Chcę wiedzieć, gdzie mieszka wartość nadrzędna. Wszystko inne to reprezentacja tej prawdy w jakimś celu.
To miejsce to system of record (system ewidencji). Zdenormalizowane kopie mogą być dobre: ekran przystanku, karta wyników, Snowflake i kontekst AI wykonują swoją pracę lepiej z kształtem zbudowanym dla nich, a korzystanie z nich jest w porządku. Ale gdy coś się zmienia, zmiana zaczyna się w systemie ewidencji, zwykle w modelu relacyjnym, i płynie na zewnątrz do każdej kopii. Nikt nie poprawia regionu w Snowflake ani nie edytuje ręcznie kontekstu AI. Popraw to u źródła i pozwól zmianie popłynąć.
A ma to największe znaczenie, gdy dane się zmieniają. Jeśli centrum dystrybucyjne przechodzi dziś do innego regionu, czy dostawy z zeszłego miesiąca powinny pokazywać nowy region? Może. Może nie. Na potrzeby historii mogę potrzebować regionu, który był prawdziwy w chwili dostawy. To już nie jest problem synchronizacji. To decyzja biznesowa.
Dlatego denormalizacja nigdy nie powinna dziać się przypadkiem. Każdy zduplikowany fakt rodzi pytania o własność, synchronizację, historię i zaufanie. To myślenie o kompromisach z rozdziału 1: wiedz, co kupujesz (łatwiejszy ekran, prostszy raport, lepszy kontekst dla AI) i ile płacisz (zduplikowane dane, synchronizacja, bardziej skomplikowana własność prawdy). A ponieważ zaczęliśmy od czystego modelu logicznego, możemy wskazać każdą kopię i powiedzieć: „Wiem, że to należy tam. Umieszczam tu jego reprezentację z powodu tego wymagania”. To decyzja, którą można przejrzeć, podważyć i zapisać, żeby następny architekt wiedział dlaczego.
Co tu decyduje architekt
Dział zatytułowany „Co tu decyduje architekt ”Rozważając denormalizację, decyduję:
- Gdzie mieszka nadrzędne źródło każdego faktu biznesowego.
- Czy czysty model tworzy prawdziwe problemy dla użytkowników, raportowania, skali lub wydajności.
- Czy prostsza reprezentacja jest warta duplikacji i jak kopia pozostaje wiarygodna.
- Czy wartości historyczne powinny się zmieniać, gdy zmienia się bieżące źródło.
- Czy analityka albo AI potrzebuje innego kształtu danych niż system operacyjny.
Punkt wyjścia nigdy się nie zmienia: wiedz, gdzie należy prawda. Potem, gdy wymagania to uzasadniają, ukształtuj ją do dostarczenia.
Dalej Salesforce wraca do gry. Zamienimy to, co zaprojektowaliśmy, w fizyczny model danych.
Do zgłębienia
Dział zatytułowany „Do zgłębienia ”- Build Powerful Reports with Custom Report Types (opens in a new tab), Salesforce Admins, 24 czerwca 2019 (po angielsku, sprawdzono 2026-10-12): niestandardowy typ raportu „może obejmować do 4 relacji między obiektami”.
- Unleash the hounds, terriers and lapdogs: American Kennel Club recognizes 3 more breeds (opens in a new tab), PBS NewsHour, 2 stycznia 2026 (po angielsku, sprawdzono 2026-10-12): „AKC uznaje 205 ras, w tym te trzy nowe”.
- Dla zabawy: FCI Breeds Nomenclature (opens in a new tab), Fédération Cynologique Internationale (po angielsku, sprawdzono 2026-10-12): lista ras międzynarodowej federacji, w dziesięciu grupach. Przewiń ją, a zobaczysz, dlaczego Rasa zasłużyła na własną tabelę.