Narysuj relacje
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ł 2 z 6 w rozdziale Modelowanie danych, które coś znaczą, rozdziale 2 kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Wsłuchaj się w rzeczowniki · Dalej: Zbuduj model logiczny
Pytanie, na które odpowiada ten moduł: jak zamienić encje kandydujące w konceptualny model danych?
Mamy rzeczowniki na tablicy. Teraz chcę się dowiedzieć czegoś o liniach między prostokątami, bo zbiór encji to jeszcze nie jest model danych. To w relacjach mieszka duża część znaczenia. Partner detaliczny prowadzi centra dystrybucyjne. Manifest wymienia dostawy. Dostawa trafia do odbiorcy. Ekipa obsługuje ciężarówkę. Każde z tych zdań mówi mi coś o biznesie i każde daje mi kolejne pytanie do zadania.
Zacznij od języka biznesu
Dział zatytułowany „Zacznij od języka biznesu ”Nadal nie chcę rozmawiać o Salesforce. Nie pytam, czy to ma być relacja lookup, czy master-detail, nie myślę o obiektach łączących Salesforce (Salesforce Junction Object) ani nie decyduję, co się stanie po usunięciu rekordu nadrzędnego. Próbuję zrozumieć relację biznesową.
Weźmy „partner detaliczny prowadzi centra dystrybucyjne”. Brzmi prosto. Ale czy partner detaliczny może mieć jedno CD, czy wiele? W Steve Trucking każdy partner detaliczny prowadzi regionalne centrum dystrybucyjne w każdym regionie, który obsługuje Steve Trucking, więc wiele. Czy CD może należeć do więcej niż jednego partnera detalicznego? Czy CD ma znaczenie samo w sobie, z własnym personelem i historią, czy to tylko adres? Jeśli partner detaliczny odejdzie, czy jego CD nadal nas obchodzą?
To nie są pytania o Salesforce. To pytania biznesowe, a odpowiedzi na nie mogą całkowicie zmienić model.
Czytaj linie
Dział zatytułowany „Czytaj linie ”Zanim pójdziemy głębiej, chcę ci dać język, którego od teraz będziemy używać na każdym diagramie. Jest niewielki. Linia między dwoma prostokątami mówi, że te dwie rzeczy są powiązane, a znaki na jej końcach mówią, ile.
Zacznij od zwykłej linii, bez żadnych znaków. Od tego zaczynam na tablicy: wiem, że te dwa rzeczowniki są powiązane, tylko jeszcze nie zapytałem jak. Potem końce dostają znaki. Pojedyncza kreska w poprzek linii oznacza jeden. Kurza łapka (crow’s foot), koniec, który rozdziela się na trzy jak ptasia stopa, oznacza wiele. Dalej w tym module zobaczysz drugi znak obok pierwszego, kreskę albo kółko, i on odpowiada na inne pytanie: czy może nie być żadnego?
Jedna zasada do zapamiętania: każdy znak czytasz przy prostokącie, którego dotyka. Znak najbliżej prostokąta to największa możliwa liczba; następny znak dalej to najmniejsza.
Siad, zostań, modeluj
Dział zatytułowany „Siad, zostań, modeluj ”Zanim przejdziemy do Steve Trucking, wróćmy do psów z modułu 1. Mieliśmy pięć prostokątów: Właściciel, Hodowca, Pies, Rasa i Sztuczka. Teraz pytam o linie między nimi.
Jeden czy wiele? Właściciel może mieć więcej niż jednego psa; Ana ma dwa. Pies ma jednego właściciela, przynajmniej w naszym modelu. To jeden-do-wielu: kreska przy Właścicielu, kurza łapka przy Psie. Hodowca ma ten sam kształt: jeden hodowca hoduje wiele psów.
Czy może nie być żadnego? Max pochodzi ze schroniska, więc w ogóle nie ma hodowcy. Koniec przy Hodowcy dostaje kółko: pies ma zero albo jednego hodowcę. Za to każdy pies ma właściciela, więc ten koniec dostaje drugą kreskę: dokładnie jeden.
Wiele do wielu? Pies zna wiele sztuczek, a sztuczkę, powiedzmy Siad, zna wiele psów. To wiele-do-wielu i właśnie tam szukam ukrytego pojęcia. Czy jest coś, co dotyczy tego, że ten pies zna tę sztuczkę? Jak dobrze ją wykonuje i kiedy się jej nauczył. Relacja ma własne fakty, więc staje się osobną rzeczą: Sztuczka psa, z psem w nazwie, bo to pies nią rządzi.
Co znaczy każda linia? Właściciel jest właścicielem psa. Hodowca go hoduje. Pies zna swoje sztuczki. Nazwij linie, a każdy odczyta ci model z powrotem.
Teraz czy w czasie? Czy kogoś obchodzi, jak dobrze Bella robi Siad dzisiaj, czy też to, jak do tego doszła? Jeśli trener sprawdza ją co kilka miesięcy, każde sprawdzenie jest osobnym rekordem: Ocena sztuczki, z datą, poziomem umiejętności i osobą, która sprawdzała, pod Sztuczką psa, do której należy. Nawet relacja, która stała się rzeczą, może mieć własną historię.
Rasę na razie zostawiam bez połączenia. To wciąż pytanie z modułu 1, osobny prostokąt czy słowo przy psie, i rozstrzygnie je moduł 4.
Każde z tych pytań działa tak samo na prawdziwym biznesie. Zadajmy je teraz Steve Trucking.
Zapytaj: „jeden czy wiele?”
Dział zatytułowany „Zapytaj: „jeden czy wiele?” ”Jedną z pierwszych rzeczy, które chcę zrozumieć o relacji, jest jej liczność (kardynalność). To termin z baz danych; pytanie jest dużo prostsze: ile tych może być powiązanych z iloma tamtymi? Na poziomie konceptualnym są trzy podstawowe wzorce.
To ważny krok w procesie: weź dwa różne rzeczowniki i zrozum ich relację. W większości sytuacji to jeden-do-wielu albo wiele-do-jednego. Tylko w rzadkich przypadkach trafisz na jeden-do-jednego.
Jeden-do-wielu jest wszędzie. Jeden partner detaliczny ma wiele centrów dystrybucyjnych. Jeden manifest wymienia wiele dostaw. Jedna trasa ma mniej więcej dziesięć przystanków. Gdy słyszę takie sformułowania, zaczynam rysować linię.
A teraz linia dostaje swoje znaki. Każdy koniec mówi, ile jest prostokąta, którego dotyka: kreska dla jednego, kurza łapka dla wielu. Czytaj od każdego prostokąta: jeden partner detaliczny ma wiele centrów dystrybucyjnych.
Relacje jeden-do-jednego istnieją, ale są rzadkie, a gdy na jakąś trafiam, zadaję kilka pytań. Czy to naprawdę dwa różne rzeczowniki, czy jeden? Jeśli różne, czym jest relacja jeden-do-jednego między nimi? I czy zawsze będzie jeden-do-jednego, czy tylko jeden-do-jednego w tej chwili? To kluczowe pytania przy projektowaniu modelu danych. Ekipa i ciężarówka danego ranka wyglądają na jeden-do-jednego: dwie osoby, jedna ciężarówka, jedna trasa. W skali miesiąca już nie, i właśnie tam ukrywa się najciekawsza relacja w tym modelu.
Relacje wiele-do-wielu są szczególnie ciekawe, bo często mówią nam, że w biznesie istnieje jeszcze jedno pojęcie. Czy ekipa może z czasem jeździć więcej niż jedną ciężarówką? Tak. Czy ciężarówką może jeździć więcej niż jedna ekipa? W ciągu jej życia na pewno. Ekipy i ciężarówki mają więc relację wiele-do-wielu. Ale teraz chcę wiedzieć więcej. Czy biznes obchodzi, kiedy ekipa miała ciężarówkę? Na której trasie, którego dnia? Kto dokonał przydziału? Jeśli sama relacja niesie informacje, na których nam zależy, odkryliśmy kolejne pojęcie biznesowe: przydział ekipy (Crew Assignment).
To ważny nawyk modelowania. Czasem najciekawsza rzecz to nie żaden z rzeczowników, które usłyszeliśmy na początku. Ukrywa się w relacji między dwoma rzeczownikami.
Relacje mogą stać się rzeczami
Dział zatytułowany „Relacje mogą stać się rzeczami ”To jedno z miejsc, w których chcę, żeby administratorzy zaczęli myśleć inaczej. W Salesforce przywykliśmy mówić o obiektach i polach, więc łatwo traktować prostokąty jako ważną część, a linie jako hydraulikę. Ale sama relacja może mieć znaczenie biznesowe.
Weźmy dostawę i produkty na niej. Dostawa może zawierać kilka produktów, na przykład pralkę i suszarkę. Produkt, ten sam model lodówki, pojawia się w tysiącach dostaw. Na razie proste. Ale co, jeśli muszę wiedzieć, ile sztuk tego produktu jest w tej dostawie, czy będzie instalowany albo czy stary jest wywożony? Nie interesuje mnie już tylko relacja między dostawą a produktem. Interesuje mnie pozycja dostawy (Delivery Item), a to pojęcie zasługuje na własną encję.
Jeśli przychodzisz ze świata Salesforce, możesz już myśleć: „To obiekt łączący”. Nie mylisz się. Ale nie chcę od tego zaczynać. Pozycja dostawy to pojęcie biznesowe, zanim stanie się obiektem łączącym Salesforce (Salesforce Junction Object). Najpierw biznes, potem implementacja.
Kilka moich nawyków dotyczących takich encji relacyjnych, gdziekolwiek ostatecznie zostaną zbudowane.
Nazwij ją. Jeśli biznes ma już na nią słowo, użyj jego słowa. Jeśli nie ma, weź nazwy obu rodziców i połącz je. Pomyśl o zamówieniu i produkcie. To, co jest między nimi, to Order Item (pozycja zamówienia): zamówienie i rzecz w zamówieniu. To dziecko obu rodziców, a w Salesforce może skończyć jako obiekt łączący Salesforce (Salesforce Junction Object). Ale która nazwa idzie pierwsza: Item Order czy Order Item? Spójrz, jakim rodzajem danych jest każdy z rodziców. Produkt to dane referencyjne; zamówienie jest transakcyjne i to ono tu rządzi. Więc Order Item albo Order Product, tak jak Salesforce ma Opportunity Product. W Steve Trucking to Delivery Item. Nazwa, która rządzi, idzie pierwsza, a rekord ustawia się obok swojego właściciela na każdej liście, jaką kiedykolwiek zobaczysz. (Po polsku szyk jest odwrotny, „pozycja dostawy”, ale zasada się nie zmienia: nazwa wskazuje, kto rządzi.)
Daj jej własny klucz. Kusi, żeby powiedzieć, że pozycję dostawy identyfikuje dostawa plus produkt, i na tym poprzestać. To klucz złożony, a z kluczami złożonymi dużo trudniej sobie radzić: każdy system, który wskazuje na rekord, musi nosić obie połówki. Daj encji relacyjnej własny identyfikator, a dostawę plus produkt zachowaj jako regułę unikalności, nie jako tożsamość rekordu.
Zwróć uwagę, czego na niej nie ma: numeru seryjnego. Ilość i numer seryjny nie pasują do tego samego rekordu. Ilość liczy kilka sztuk czegoś; numer seryjny identyfikuje jedną konkretną rzecz. Jeśli biznes potrzebuje numerów seryjnych, każda sztuka staje się osobnym rekordem, a pięć lodówek to pięć rekordów. Nie widzę uzasadnienia dla pozycji dostawy ze szczegółem pozycji dostawy pod spodem. Albo jedno, albo drugie: agregat z ilością albo jeden rekord na sztukę. Tutaj to ilość.
Uważaj na atrybuty, które chcą mieć historię. Niektóre encje relacyjne są ustalone w chwili utworzenia: pralka w tej dostawie zostaje pralką w tej dostawie. Inne ciągle się zmieniają. Ekipa ma w tym tygodniu ciężarówkę 117, a w przyszłym ciężarówka trafia do innej ekipy. Gdy relacja się zmienia, a biznes obchodzi, jaka była wcześniej, encja relacyjna potrzebuje dat, a tą, na którą trzeba uważać, jest przydział ekipy. Zapytaj wcześnie, czy biznes obchodzi teraz, czy w czasie; za chwilę do tego wrócimy.
Relacje znaczą więcej niż liczność
Dział zatytułowany „Relacje znaczą więcej niż liczność ”„Jeden-do-wielu” to za mało, żeby zrozumieć relację. Chcę też wiedzieć, co relacja oznacza.
Dostawa ma lokalizację. Którą? Centrum dystrybucyjne, z którego wyjeżdża? Dom odbiorcy, do którego jedzie? Nie są wymienne. Dwa modele mogą mieć dokładnie te same prostokąty i tę samą liczność, a linie mogą znaczyć zupełnie różne rzeczy. Dlatego dobry model to nie tylko prostokąty połączone liniami. Linie potrzebują nazw. Jeśli dam swój diagram innemu architektowi, nie powinien musieć zgadywać, co oznacza relacja, a jeśli pokazuję go biznesowi, powinien używać języka, który biznes rozpoznaje.
Opcjonalność też ma znaczenie
Dział zatytułowany „Opcjonalność też ma znaczenie ”W pytaniu „ile?” kryje się jeszcze jedno pytanie: czy relacja jest wymagana? Czy dostawa może istnieć, zanim trafi na trasę? Musi: manifest przychodzi dzień lub dwa przed dostawą, a trasy ustala się wieczorem poprzedniego dnia. Czy dostawa może istnieć bez partnera detalicznego? Nie; każda dostawa pochodzi z manifestu partnera. To jest opcjonalność.
I znowu: nie skacz od razu do pola wyboru Wymagane w Salesforce. Jest różnica między stwierdzeniem „każda dostawa musi mieć partnera detalicznego” a stwierdzeniem „Salesforce powinien wymagać pola partnera detalicznego przy tworzeniu rekordu”. Mogą skończyć jako ta sama implementacja, ale to nie jest to samo zdanie. Pierwsze to reguła biznesowa; drugie to jeden ze sposobów jej egzekwowania. Jako architekci chcemy zrozumieć pierwsze, zanim zdecydujemy o drugim.
Na diagramie opcjonalność to drugi znak na każdym końcu. Znak najbliżej prostokąta to największa możliwa liczba: kreska dla jednego, kurza łapka dla wielu. Następny znak dalej to najmniejsza: kolejna kreska oznacza co najmniej jeden, kółko oznacza, że może być zero. Każda dostawa jest więc w dokładnie jednym manifeście, a manifest wymienia jedną albo wiele dostaw. Dostawa jest na zero albo jednym przystanku, na żadnym, dopóki nie trafi na trasę, a na przystanku zostawia się zero albo wiele dostaw.
Czas zmienia relacje
Dział zatytułowany „Czas zmienia relacje ”Oto pytanie, które często zadaję: czy masz na myśli teraz, czy w czasie?
Ekipa obsługuje ciężarówkę. Teraz? Na dzisiejszej trasie? Tak długo, jak te dwie osoby pracują razem? To dają różne modele. Jeśli biznes obchodzi tylko, którą ciężarówkę ekipa ma dziś, model może zostać prosty. Jeśli potrzebuje każdej ciężarówki, którą ekipa jeździła, kiedy i na której trasie, potrzebujemy historii, a odkryty przez nas przydział ekipy nagle bardzo zyskuje na znaczeniu.
To częste źródło błędów w modelowaniu. Modelujemy stan bieżący, bo to widzimy na ekranie. Potem, kilka tygodni później, partner detaliczny zgłasza reklamację szkody i ktoś pyta: „Która ekipa miała ciężarówkę 117 siedemnastego marca?”. I odkrywamy, że nadpisywaliśmy odpowiedź przy każdej zmianie przydziału.
Jednym ze sposobów zachowania tej historii jest uczynienie przydziału osobnym rekordem. Gdy ekipa dostaje przydział, tworzymy przydział ekipy z datą początku. Gdy przydział się zmienia, wstawiamy datę końca w starym rekordzie i tworzymy nowy z własną datą początku. Teraz pytanie „kto miał ten przydział pół roku temu?” jest proste, zamiast wymagać przekopywania historii pól albo dziennika zmian danych. A gdy ekipa ma już za sobą wiele przydziałów, ktoś zapyta, który jest bieżący, więc dodałbym też flagę Aktywny.
Kiedy więc ktoś opowiada mi o relacji, nie pytam tylko, jak te rzeczy są powiązane. Pytam: czy ta relacja się zmienia i czy obchodzi nas jej historia?
Rysuj, zanim zaczniesz konfigurować
Dział zatytułowany „Rysuj, zanim zaczniesz konfigurować ”Nasz model Steve Trucking staje się użyteczny. Wiemy, które relacje są jeden-do-wielu, gdzie wiele-do-wielu ukrywa kolejne pojęcie, które relacje są opcjonalne, a które zmieniają się w czasie. A wciąż nie utworzyliśmy żadnego obiektu Salesforce. To celowe.
Ten diagram powinien być czymś, co mogę postawić przed biznesem, a biznes nie powinien musieć znać Salesforce, żeby powiedzieć mi, czy jest dobry. Jeśli nie da się go zweryfikować, bo jest pełen terminologii Salesforce, za szybko przeszedłem do projektu fizycznego.
Co tu decyduje architekt
Dział zatytułowany „Co tu decyduje architekt ”Pracując nad relacjami w modelu konceptualnym, decyduję:
- Jak główne encje biznesowe wiążą się ze sobą.
- Czy każda relacja jest jeden-do-jednego, jeden-do-wielu czy wiele-do-wielu, teraz i w czasie.
- Czy każda relacja jest wymagana, czy opcjonalna.
- Czy relacja wiele-do-wielu ukrywa znaczące pojęcie biznesowe.
- Czy relacja zmienia się w czasie i czy potrzebujemy jej historii.
Lookup czy master-detail, konfiguracja obiektu łączącego, zachowanie kaskadowe i udostępnianie to decyzje fizyczne; do nich dojdziemy. Teraz wciąż odpowiadamy na ważniejsze pytanie: jak ten biznes naprawdę działa? Gdy zrozumiemy encje i relacje między nimi, możemy zacząć dodawać szczegóły, które je opisują. Wtedy nasz model konceptualny zaczyna stawać się logicznym modelem danych.