Nakreslete vztahy
Deze inhoud is nog niet vertaald.
K dispozici také v 29 jazycích
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 2 z 6 kapitoly Modelování dat podle významu, kapitoly 2 kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: Naslouchejte podstatným jménům · Další: Sestavte logický model
Otázka, na kterou tento modul odpovídá: Jak z kandidátních entit udělat konceptuální datový model?
Podstatná jména máme na tabuli. Teď chci vědět o čarách mezi krabicemi, protože sbírka entit ještě není doopravdy datový model. Velká část významu žije ve vztazích. Maloobchodní partner provozuje distribuční centra. Manifest obsahuje seznam doručení. Doručení jde k příjemci. Posádka jezdí s kamionem. Každé z těch tvrzení mi něco říká o byznysu a každé mi dává další otázku, kterou položit.
Začněte jazykem byznysu
Section titled “Začněte jazykem byznysu ”Pořád nechci mluvit o Salesforce. Neptám se, jestli to má být vztah lookup, nebo master-detail, nepřemýšlím o spojovacích objektech Salesforce (Salesforce Junction Object) ani nerozhoduji, co se stane, když se smaže nadřazený záznam. Snažím se pochopit obchodní vztah.
Vezměte „maloobchodní partner provozuje distribuční centra“. Zní to jednoduše. Může ale mít maloobchodní partner jedno DC, nebo mnoho? Ve Steve Trucking provozuje každý maloobchodní partner regionální distribuční centrum v každém regionu, kde Steve Trucking působí, takže mnoho. Může DC patřit víc než jednomu maloobchodnímu partnerovi? Má DC význam samo o sobě, s vlastními lidmi a historií, nebo je to jen adresa? Když maloobchodní partner odejde, zajímají nás pořád jeho DC?
To nejsou otázky na Salesforce. Jsou to obchodní otázky a odpovědi na ně mohou model úplně změnit.
Čtěte čáry
Section titled “Čtěte čáry ”Než půjdeme hlouběji, chci vám dát jazyk, který odteď použijeme na každém diagramu. Je malý. Čára mezi dvěma krabicemi říká, že spolu ty dvě věci souvisejí, a značky na jejích koncích říkají kolik.
Začněte prostou čárou, úplně bez značek. Tím začínám na tabuli: vím, že tato dvě podstatná jména spolu souvisejí, jen jsem se ještě nezeptal jak. Pak konce dostanou značky. Jedna příčka přes čáru, křížek, znamená jeden. Vraní noha, konec, který se rozdělí do tří jako ptačí pařát, znamená mnoho. Později v tomto modulu uvidíte, jak se vedle první značky objeví druhá, příčka nebo kroužek, a ta odpovídá na jinou otázku: může jich být nula?
Jediné pravidlo k zapamatování: každou značku čtete u krabice, které se dotýká. Značka nejblíž krabici je nejvyšší možný počet; další značka směrem ven je nejnižší.
Sedni, zůstaň, modeluj
Section titled “Sedni, zůstaň, modeluj ”Než se pustíme do Steve Trucking, vraťme se ke psům z modulu 1. Měli jsme pět krabic: Majitel, Chovatel, Pes, Plemeno a Trik. Teď se ptám na čáry mezi nimi.
Jeden, nebo mnoho? Majitel může mít víc než jednoho psa; Ana má dva. Pes má jednoho majitele, aspoň v našem modelu. To je jedna k mnoha: příčka u Majitele, vraní noha u Psa. Chovatel má stejný tvar: jeden chovatel odchová mnoho psů.
Může jich být nula? Max je z útulku, takže žádného chovatele nemá. Konec u Chovatele dostane kroužek: pes má nula nebo jednoho chovatele. Každý pes ale má majitele, takže tento konec dostane druhou příčku: právě jeden.
Mnoho k mnoha? Pes umí mnoho triků a trik, třeba Sedni, umí mnoho psů. To je mnoho k mnoha, a přesně tam jdu hledat skrytý pojem. Je něco, co platí o tom, že tento pes umí tento trik? Jak dobře ho předvádí a kdy se ho naučil. Vztah má vlastní fakta, takže se stane samostatnou věcí: Trik psa, s psem na prvním místě, protože právě pes ho řídí.
Co každá čára znamená? Majitel psa vlastní. Chovatel ho odchoval. Pes své triky umí. Pojmenujte čáry a model vám kdokoli přečte zpátky.
Teď, nebo v čase? Zajímá někoho, jak dobře Bella dnes umí Sedni, nebo jak se k tomu dostala? Pokud ji trenér kontroluje každých pár měsíců, je každá kontrola samostatný záznam: Hodnocení triku s datem, úrovní dovednosti a tím, kdo kontroloval, pod Trikem psa, ke kterému patří. I vztah, který se stal věcí, může mít vlastní historii.
Plemeno zatím nechávám nepropojené. Pořád je to otázka z modulu 1, samostatná krabice, nebo slovo u psa, a modul 4 ji rozhodne.
Každá z těchto otázek funguje stejně i na skutečném byznysu. Položme si je teď u Steve Trucking.
Ptejte se „jeden, nebo mnoho?“
Section titled “Ptejte se „jeden, nebo mnoho?“ ”Jedna z prvních věcí, kterým chci u vztahu porozumět, je jeho kardinalita. To je databázový termín; otázka je mnohem jednodušší: kolik těchto se může vázat ke kolika těm? Na konceptuální úrovni existují tři základní vzory.
Tohle je v procesu důležitý krok: vezměte dvě různá podstatná jména a pochopte jejich vztah. Ve většině situací jde o jedna k mnoha, nebo mnoho k jedné. Jen vzácně narazíte na jedna k jedné.
Jedna k mnoha je všude. Jeden maloobchodní partner má mnoho distribučních center. Jeden manifest obsahuje mnoho doručení. Jedna trasa má asi deset zastávek. Když slyším takový jazyk, začnu kreslit čáru.
A teď čára dostane své značky. Každý konec říká, kolik je krabic, které se dotýká: příčka pro jeden, vraní noha pro mnoho. Čtěte to od každé krabice: jeden maloobchodní partner má mnoho distribučních center.
Vztahy jedna k jedné existují, ale jsou vzácné, a když na nějaký narazím, kladu si otázky. Jsou to opravdu dvě různá podstatná jména, nebo totéž? Pokud jsou různá, jaký je mezi nimi vztah jedna k jedné? A bude to vždycky jedna k jedné, nebo jen právě teď? To jsou klíčové otázky při návrhu datového modelu. Posádka a kamion vypadají kteréhokoli rána jako jedna k jedné: dva lidé, jeden kamion, jedna trasa. Za měsíc už ne, a právě tam se skrývá nejzajímavější vztah v tomto modelu.
Vztahy mnoho k mnoha jsou obzvlášť zajímavé, protože nám často říkají, že v byznysu je další pojem. Může posádka v průběhu času řídit víc než jeden kamion? Ano. Může kamion řídit víc než jedna posádka? Za dobu jeho života určitě. Posádky a kamiony tedy mají vztah mnoho k mnoha. Teď ale chci vědět víc. Zajímá byznys, kdy posádka měla kamion? Pro kterou trasu, v který den? Kdo přiřazení udělal? Pokud sám vztah nese informace, na kterých nám záleží, objevili jsme další obchodní pojem: přiřazení posádky (Crew Assignment).
To je důležitý modelovací návyk. Někdy nejzajímavější věc není žádné z podstatných jmen, která jsme slyšeli jako první. Skrývá se ve vztahu mezi dvěma podstatnými jmény.
Ze vztahů se mohou stát věci
Section titled “Ze vztahů se mohou stát věci ”Tohle je jedno z míst, kde chci, aby administrátoři začali myslet jinak. V Salesforce jsme zvyklí mluvit o objektech a polích, takže je snadné brát krabice jako tu důležitou část a čáry jako instalatérství. Sám vztah ale může mít obchodní význam.
Vezměte si doručení a produkty na něm. Doručení může vézt několik produktů, třeba pračku a sušičku. Produkt, tentýž model ledničky, se objeví na tisících doručení. Zatím snadné. Ale co když potřebuji vědět, kolik kusů toho produktu je na tomto doručení, jestli se instaluje, nebo jestli se ten starý odváží? Už mě nezajímá jen vztah mezi doručením a produktem. Zajímá mě položka doručení (Delivery Item) a tento pojem si zaslouží vlastní entitu.
Pokud přicházíte ze Salesforce, možná už si říkáte: „To je spojovací objekt.“ Nemýlíte se. Nechci tam ale začínat. Položka doručení je obchodní pojem dřív, než je spojovacím objektem Salesforce. Nejdřív byznys, pak implementace.
Pár mých návyků pro tyto vztahové entity, ať už se nakonec postaví kdekoli.
Pojmenujte ji. Pokud pro ni byznys už má slovo, použijte jeho. Pokud nemá, vezměte názvy obou rodičů a spojte je. Představte si objednávku a produkt. Věc mezi nimi je položka objednávky (Order Item): objednávka a položka na objednávce. Je to potomek obou rodičů a v Salesforce z ní může být spojovací objekt Salesforce. Který název ale jde první: Item Order, nebo Order Item? Podívejte se, jaký druh dat každý rodič je. Produkt jsou referenční data; objednávka je transakční a je to objednávka, kdo ji řídí. Je to tedy Order Item, nebo Order Product, stejně jako má Salesforce Opportunity Product. Ve Steve Trucking je to položka doručení (Delivery Item). Řídící název jde první a záznam se v každém seznamu, na který se kdy podíváte, seřadí vedle svého vlastníka.
Dejte jí vlastní klíč. Je lákavé říct, že položku doručení identifikuje doručení plus produkt, a skončit. To je složený klíč a se složenými klíči se pracuje mnohem hůř: každý systém, který na záznam ukazuje, musí nést obě poloviny. Dejte vztahové entitě vlastní identifikátor a doručení plus produkt si nechte jako pravidlo o jedinečnosti, ne jako ID záznamu.
Všimněte si, co na ní není: sériové číslo. Množství a sériové číslo nepatří na stejný záznam. Množství počítá několik kusů něčeho; sériové číslo identifikuje jednu konkrétní věc. Pokud byznys sériová čísla potřebuje, stane se z každého kusu samostatný záznam a pět ledniček je pět záznamů. Nevidím důvod pro položku doručení s detailem položky doručení pod ní. Buď jedno, nebo druhé: souhrn s množstvím, nebo jeden záznam na kus. Tady je to množství.
Hlídejte atributy, které chtějí historii. Některé vztahové entity jsou po vytvoření ustálené: pračka na tomto doručení zůstane pračkou na tomto doručení. Jiné se pořád mění. Posádka má tento týden kamion 117 a příští týden jde kamion jiné posádce. Když se vztah mění a byznys zajímá, jaký býval, potřebuje vztahová entita data a právě přiřazení posádky je ta, kterou je třeba hlídat. Zeptejte se brzy, jestli byznys zajímá teď, nebo v čase; za chvíli se k tomu vrátíme.
Vztahy mají význam i nad rámec kardinality
Section titled “Vztahy mají význam i nad rámec kardinality ”„Jedna k mnoha“ k pochopení vztahu nestačí. Chci také vědět, co vztah znamená.
Doručení má místo. Které? Distribuční centrum, odkud odjíždí? Domov příjemce, kam míří? Ta nejsou zaměnitelná. Dva modely mohou mít úplně stejné krabice a stejnou kardinalitu, a přesto mohou čáry znamenat úplně odlišné věci. Proto dobrý model nejsou jen krabice spojené čarami. Čáry potřebují názvy. Když dám svůj diagram jinému architektovi, nemusí hádat, co vztah znamená, a když ho ukazuji byznysu, měl by používat jazyk, který poznají.
Záleží i na volitelnosti
Section titled “Záleží i na volitelnosti ”V otázce „kolik?“ se skrývá ještě jedna otázka: je vztah povinný? Může doručení existovat dřív, než je zařazené na trasu? Musí: manifest přichází den nebo dva před doručením a trasy se dokončují večer předtím. Může doručení existovat bez maloobchodního partnera? Ne; každé doručení pochází z manifestu některého partnera. To je volitelnost.
Ani tady neskákejte rovnou k zaškrtávacímu políčku Required v Salesforce. Je rozdíl mezi tím říct „každé doručení musí mít maloobchodního partnera“ a říct „Salesforce by měl při vytvoření záznamu vyžadovat pole maloobchodního partnera“. Mohou skončit jako stejná implementace, ale nejsou to stejná tvrzení. První je obchodní pravidlo; druhé je jeden ze způsobů, jak ho vynutit. Jako architekti chceme porozumět prvnímu dřív, než rozhodneme o druhém.
Na diagramu je volitelnost druhou značkou na každém konci. Značka nejblíž krabici je nejvyšší možný počet: příčka pro jeden, vraní noha pro mnoho. Další značka směrem ven je nejnižší: další příčka znamená alespoň jeden, kroužek znamená, že jich může být nula. Každé doručení je tedy na právě jednom manifestu a manifest obsahuje jedno nebo mnoho doručení. Doručení je na nula nebo jedné zastávce, na žádné, dokud není zařazené na trasu, a na zastávce se vyloží nula nebo mnoho doručení.
Čas mění vztahy
Section titled “Čas mění vztahy ”Tady je otázka, kterou kladu často: myslíte teď, nebo v čase?
Posádka jezdí s kamionem. Právě teď? Pro dnešní trasu? Po celou dobu, co ti dva lidé spolupracují? To vede k různým modelům. Pokud byznys zajímá jen to, který kamion má posádka dnes, může model zůstat jednoduchý. Pokud potřebuje každý kamion, který posádka řídila, kdy a na které trase, potřebujeme historii a přiřazení posádky, které jsme objevili, najednou hodně znamená.
To je častý zdroj chyb v modelování. Modelujeme aktuální stav, protože ten vidíme na obrazovce. Pak o několik týdnů později podá maloobchodní partner reklamaci škody a někdo se zeptá: „Která posádka měla 17. března kamion 117?“ A zjistíme, že jsme odpověď přepisovali pokaždé, když se přiřazení změnilo.
Jedním způsobem, jak tu historii uchovat, je udělat z přiřazení samostatný záznam. Když je posádka přiřazena, vytvoříme přiřazení posádky s datem začátku. Když se přiřazení změní, dáme starému záznamu datum konce a vytvoříme nový s vlastním datem začátku. Teď je „kdo měl to přiřazení před šesti měsíci?“ jednoduchá otázka, místo pátrání v historii polí nebo v logu změn dat. A jakmile má posádka mnoho přiřazení, někdo se zeptá, které je aktuální, takže bych přidal i příznak Active.
Když mi tedy někdo vypráví o vztahu, neptám se jen, jak spolu věci souvisejí. Ptám se: mění se ten vztah a záleží nám na jeho historii?
Kreslete dřív, než konfigurujete
Section titled “Kreslete dřív, než konfigurujete ”Náš model Steve Trucking začíná být užitečný. Víme, které vztahy jsou jedna k mnoha, kde se ve vztahu mnoho k mnoha skrývá další pojem, které vztahy jsou volitelné a které se v čase mění. A pořád jsme nevytvořili žádný objekt Salesforce. To je záměr.
Tento diagram by měl být něco, co můžu položit před byznys, a lidé by nemuseli znát Salesforce, aby mi řekli, jestli je správně. Pokud ho nedokážou ověřit, protože je plný terminologie Salesforce, přešel jsem do fyzického návrhu příliš rychle.
Co tady rozhoduje architekt
Section titled “Co tady rozhoduje architekt ”Když procházím vztahy v konceptuálním modelu, rozhoduji:
- Jak spolu souvisejí hlavní obchodní entity.
- Zda je každý vztah jedna k jedné, jedna k mnoha, nebo mnoho k mnoha, teď i v čase.
- Zda je každý vztah povinný, nebo volitelný.
- Zda vztah mnoho k mnoha neskrývá smysluplný obchodní pojem.
- Zda se vztah v čase mění a zda potřebujeme jeho historii.
Lookup nebo master-detail, konfigurace spojení, kaskádové chování a sdílení jsou fyzická rozhodnutí; dostaneme se k nim. Teď pořád odpovídáme na důležitější otázku: jak tento byznys doopravdy funguje? Jakmile porozumíme entitám a vztahům mezi nimi, můžeme začít přidávat podrobnosti, které je popisují. Tehdy se z našeho konceptuálního modelu začne stávat logický datový model.