Zbuduj model logiczny

🌐 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ł 3 z 6 w rozdziale Modelowanie danych, które coś znaczą, rozdziale 2 kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Narysuj relacje · Dalej: Umieść dane tam, gdzie ich miejsce

Pytanie, na które odpowiada ten moduł: jak zamienić model konceptualny w logiczny model danych?

Model konceptualny powiedział nam, co istnieje w Steve Trucking i jak jest ze sobą powiązane: partnerzy detaliczni i ich centra dystrybucyjne, manifesty i dostawy, odbiorcy, trasy i przystanki, ekipy, ciężarówki i przydziały ekip. To wystarczy na bardzo owocną rozmowę z biznesem. Ale w końcu potrzebuję więcej szczegółów. Co musimy wiedzieć o dostawie? Czym jedno centrum dystrybucyjne różni się od drugiego? Jak identyfikujemy odbiorcę? Co należy do przydziału ekipy, a nie do ekipy czy ciężarówki? Te pytania przesuwają nas od modelu konceptualnego w stronę logicznego modelu danych, a my nadal nie budujemy jeszcze Salesforce.

Siad, zostań, modeluj

Najpierw wróćmy do psów. Mamy prostokąty i linie. Teraz dwa nowe pytania: co wiemy o każdej rzeczy i jak odróżnić jedną od drugiej?

Co ją opisuje? Pies ma imię i datę urodzenia. Właściciel ma imię i nazwisko, numer telefonu i adres. Sztuczka ma nazwę i stopień trudności. Każdy fakt trafia do prostokąta, który opisuje.

Potem obiekt łączący. Jak dobrze Bella robi Siad i kiedy się tego nauczyła: czy to opisuje Bellę? Niezupełnie; niektóre sztuczki wychodzą jej lepiej niż inne. Czy opisuje Siad? Nie; każdy pies robi Siad inaczej. Opisuje Bellę i Siad razem, więc należy do Sztuczki psa: poziom umiejętności i data nauki. Po to właśnie istnieje obiekt łączący: niektóre fakty należą tylko do pary.

Który pies jest który? Najpierw spróbuj imienia. Psów o imieniu Max jest mnóstwo, więc imię nie jest unikalne. Numer telefonu właściciela? Marcus ma dwa psy pod tym samym numerem, ludzie zmieniają numery, a to czyjeś dane osobowe, które zostałyby skopiowane do każdego systemu, który kiedykolwiek wskazuje na psa. Numer mikrochipa wygląda lepiej: jest unikalny i się nie zmienia. Ale nowy szczeniak może jeszcze nie mieć chipa, a klucz nie może być pusty. Mikrochip zostaje więc jako coś, po czym pies jest także znany, a pies dostaje własny ID psa: numer, który wykonuje jedną nudną pracę, czyli odróżnia jednego psa od drugiego.

Click to enlarge

To te same pytania, które teraz zadamy Steve Trucking, a powody, dla których imię, telefon i mikrochip zawodzą, składają się na zasadę, której trzymam się od lat.

Model konceptualny mówi, co istnieje; logiczny mówi, co to znaczy jako dane

Weźmy ciężarówkę. Co muszę o niej wiedzieć? Może jej numer floty, VIN, markę, model, rok modelowy, numer rejestracyjny, aktualny przebieg i status. To atrybuty ciężarówki.

Teraz weźmy dostawę. Może numer zamówienia partnera detalicznego, datę dostawy, obiecane okno czasowe, rzeczywisty czas przyjazdu, status i to, czy obejmuje instalację albo wywóz starego sprzętu. Znowu atrybuty.

Model konceptualny powiedział nam, że dostawa istnieje. Model logiczny zaczyna mówić, co dostawa oznacza jako dane. Prosty prostokąt, jak ciężarówka czy dostawa, może kryć cały zestaw pól.

Click to enlarge

Mimo to na większości naszych diagramów prostokąty pozostają proste, z trzech powodów. Liczba pól rośnie. Pola szybko stają się nieaktualne. A każde pole ma szczegóły, które trudno pokazać w modelu obiektów: nazwę API, etykietę, typ danych i długość. Te szczegóły na pewno zostaną zapisane, tylko nie w pierwszym modelu danych. Gdy pokazanie kilku kluczowych pól naprawdę pomaga opowiedzieć historię, narysuję szczegółowy model danych: wycinek skupiony na jednej sprawie, tylko z polami, które się dla niej liczą.

Atrybuty powinny opisywać encję

Oto proste pytanie, którego używam, patrząc na atrybut: co to opisuje? Marka ciężarówki wyraźnie opisuje ciężarówkę. Ale co z imionami i nazwiskami członków ekipy na dostawie? Czy opisują dostawę? Czy raczej ekipę, która miała przydział ekipy, który obejmował trasę, która zawierała ten przystanek?

Tu model danych zaczyna ujawniać rzeczy, które na ekranie wyglądają zupełnie rozsądnie. Dyspozytor mówi: „Chcę widzieć na dostawie, kto jest w ekipie”. To uzasadnione wymaganie dotyczące doświadczenia użytkownika. Niekoniecznie jest to wymaganie, żeby przechowywać nazwiska ekipy na dostawie. To dwie różne rzeczy i wrócimy do tego przy normalizacji. Na razie wyrób sobie nawyk pytania, jaką rzecz ten fakt naprawdę opisuje. To pytanie oszczędzi ci mnóstwa kłopotów.

Potem musimy porozmawiać o unikalnych identyfikatorach

Atrybuty opisują rzeczy. Ale jest jeszcze jeden problem do rozwiązania: skąd wiem, która rzecz jest która?

Dwóch odbiorców nazywa się John Smith. Czy to ta sama osoba? Może tak, może nie. Imię i nazwisko nie wystarczą. Adres? Ludzie się przeprowadzają. Numery telefonów się zmieniają. Adresy e-mail się zmieniają. Nawet nazwa partnera detalicznego może się zmienić.

To prowadzi nas do kluczy: tego, co pozwala jednoznacznie zidentyfikować coś w naszym modelu. To obszar, w którym przez lata wyrobiłem sobie dość zdecydowane zdanie. Od identyfikatora chcę czterech rzeczy:

Unikalny. Niezmienny. Bez znaczenia. Nigdy dane osobowe (PII).

Unikalny. Identyfikator musi identyfikować dokładnie jedną rzecz. Jeśli dwie dostawy mogą mieć tę samą wartość, nie jest to wiarygodny identyfikator dostawy. Imiona i nazwiska zwykle nie są unikalne, adresy niekoniecznie są unikalne, a numerami telefonów ludzie się dzielą. Nawet wartości, które dziś wyglądają na unikalne, mogą przestać takie być, gdy danych będzie dość dużo. Zapytaj więc: czy dwie takie rzeczy mogą kiedykolwiek mieć tę samą wartość? Jeśli tak, bardzo ostrożnie z używaniem tego jako unikalnego identyfikatora rekordu.

Niezmienny. Ten punkt często się pomija. Jeśli identyfikujemy partnera detalicznego po nazwie, a partner zmieni nazwę, czy mamy nowego partnera? Nie. Podmiot biznesowy pozostał ten sam; zmienił się jeden z jego atrybutów. Unikalny identyfikator rekordu powinien przetrwać zmiany rzeczy, którą identyfikuje, co wyklucza nazwy, adresy e-mail, numery telefonów, adresy i nazwy użytkowników, choćby wydawały się wygodne, gdy dopiero budujemy system.

Bez znaczenia. Za pierwszym razem brzmi to dziwnie. Dlaczego miałbym chcieć, żeby identyfikator nic nie znaczył? Bo znaczenie się zmienia. Wyobraź sobie, że ktoś buduje identyfikator dostawy, który koduje CD, partnera detalicznego, datę dostawy i numer kolejny: PHX-KEY-20261002-0042. Wygląda sprytnie. Potem odbiorca przekłada dostawę na piątek. Czy zmieniamy identyfikator? Jeśli nie, identyfikator nas okłamuje. Jeśli tak, zmieniliśmy unikalny identyfikator dostawy, bo zmienił się jeden z jej atrybutów, a każdy system, który przechował stary identyfikator, właśnie ją zgubił. Identyfikator próbował wykonywać dwie prace: identyfikować dostawę i ją opisywać. Wolę, żeby opisywały ją atrybuty, a identyfikator wykonywał jedną nudną pracę: identyfikował. Nudne identyfikatory to dobre identyfikatory.

Nigdy dane osobowe. Ten punkt jest na tyle ważny, że trzymam go osobno. Nie używaj danych osobowych (PII) jako identyfikatora tylko dlatego, że wyglądają na unikalne. W Steve Trucking kusi, żeby rozpoznawać odbiorcę po numerze telefonu. Ale klucz jest kopiowany wszędzie tam, gdzie systemy muszą łączyć rekordy: do integracji, eksportów, logów, plików statusowych odsyłanych partnerom detalicznym, do hurtowni danych, do danych testowych. Zrób kluczem numer telefonu, a rozsiejesz dane osobowe odbiorcy po całej architekturze.

Klucz musi też istnieć dla każdego rekordu: nigdy null ani pusty. Jeśli niektórzy ludzie nie podadzą wartości albo nie powinni musieć jej podawać, ta wartość nie może być kluczem. Dlatego systemy nadają własne wewnętrzne identyfikatory, a dane osobowe, jeśli w ogóle są potrzebne, stają się chronionym atrybutem.

Moja zasada brzmi więc: unikalny, niezmienny, bez znaczenia, nigdy dane osobowe.

Klucze naturalne i klucze zastępcze

Ludzie od baz danych mają na część tego nazwy. Klucz naturalny istnieje już w danych biznesowych: dobrym przykładem jest VIN ciężarówki. Nasza aplikacja go nie wymyśliła i on już ma znaczenie. Klucz zastępczy (surrogate) tworzy się specjalnie po to, żeby identyfikować rekord; niczego nie opisuje, tylko identyfikuje.

W większości architektur jako wewnętrzny identyfikator rekordu wolę klucz zastępczy, a ważne identyfikatory naturalne zachowuję jako atrybuty. To nie znaczy, że identyfikatory naturalne są złe; często są niezwykle ważne. Po prostu nie robię z nich automatycznie unikalnego identyfikatora rekordu. Zapytaj, co się stanie, jeśli wartość zostanie poprawiona, przeformatowana, zastąpiona, użyta ponownie, będzie jej brakować albo przyjdzie z więcej niż jednego systemu źródłowego. Tu prosta z pozoru decyzja staje się decyzją architektoniczną.

Jedna rzecz może mieć kilka użytecznych identyfikatorów

Wewnętrzny identyfikator rekordu to niekoniecznie identyfikator, którego używa każdy inny system. Steve Trucking może wewnętrznie identyfikować dostawę wygenerowanym identyfikatorem. Każdy partner detaliczny zna tę samą dostawę pod własnym numerem zamówienia: Keystone w swoim manifeście CSV, Redrock w swoim API, Brightwave w swoich komunikatach EDI. A osiem lat historii w RouteDesk, starym narzędziu dyspozytorskim, używa własnych identyfikatorów dostaw RouteDesk.

Te identyfikatory mają znaczenie. Musimy je zachować i poprawnie zmapować, bo aktualizacja statusu musi wrócić do każdego partnera pod jego numerem. Ale nie wszystkie muszą stać się unikalnym identyfikatorem dostawy. Pytanie „jaki ma identyfikator?” może mieć więcej niż jedną odpowiedź, a architekt musi wiedzieć, który identyfikator jest nadrzędny w jakim kontekście. Wrócimy do tego przy danych podstawowych i integracji.

Relacje zależą od unikalnych identyfikatorów

Wróć teraz do narysowanych linii. Manifest wymienia dostawy. Odbiorca otrzymuje dostawy. Ekipa ma przydziały ekipy. Te relacje działają tylko dlatego, że potrafimy wiarygodnie zidentyfikować rzeczy na obu końcach.

Oto gdzie to boli w Steve Trucking. Partner detaliczny poprawia swój manifest w dniu dostawy: anulowane zamówienie, zamieniona rzecz, nowy adres. Jeśli nie potrafimy dopasować poprawionej pozycji do dostawy, którą już mamy, po numerze zamówienia partnera, tworzymy drugą dostawę tej samej lodówki, a ekipa może przyjechać dwa razy. Prostokąty, atrybuty, klucze i relacje to nie osobne idee. To części tego samego modelu.

Click to enlarge

W tym momencie możesz myśleć: „Salesforce nadaje każdemu rekordowi identyfikator”. Zgadza się, i do tego dojdziemy. Jeśli dane mieszkają w Salesforce, każdy rekord dostaje identyfikator wygenerowany przez Salesforce. Jest zagadkowy i trudny do odczytania, więc zwykle udostępniamy też pole identyfikatora, którego mogą używać ludzie, na przykład numer dostawy D-000184227, pole typu autonumer. Ludzie często myślą, że ten numer to identyfikator rekordu, ale nim nie jest: identyfikator Salesforce nadal jest pod spodem. Zewnętrzny system lub baza danych, Oracle czy SQL Server, też ma własne unikalne identyfikatory. Ale architektura może w końcu objąć Salesforce, finansowy ERP, Snowflake, Data 360, systemy partnerów i systemy, które jeszcze nie istnieją. Model logiczny opisuje dane biznesowe, nie uzależniając każdej decyzji od jednej technologii. To, jak Salesforce fizycznie go implementuje, to późniejszy krok.

Co tu decyduje architekt

Zamieniając model konceptualny w logiczny, decyduję:

• Które atrybuty naprawdę opisują każdą encję.
• Jak każda encja jest jednoznacznie identyfikowana i czy ten identyfikator jest dość stabilny, żeby być jej unikalnym identyfikatorem.
• Które identyfikatory biznesowe (numery zamówień partnerów, stare identyfikatory) trzeba zachować i zmapować.
• Czy jako klucz nie są używane informacje wrażliwe.
• Czy relacje łączą encje przez wiarygodne unikalne identyfikatory.

Mamy teraz encje, relacje, atrybuty i unikalne identyfikatory: zaczątki prawdziwego logicznego modelu danych. Ale wciąż jest problem. Bardzo łatwo umieścić całkowicie poprawne dane w złym miejscu. Tu wkracza normalizacja.

Do zgłębienia

• Custom Field Types (opens in a new tab), Pomoc Salesforce (po angielsku, sprawdzono 2026-10-09): autonumer nadaje każdemu rekordowi unikalny numer w formacie wyświetlania, na przykład z prefiksem i wiodącymi zerami; to nie jest identyfikator rekordu w Salesforce. Zobacz też Auto-Number Fields Are Not Always Sequential (opens in a new tab) (po angielsku, sprawdzono 2026-10-09).