Gå til innholdet
SteveTechArcSteveTechArc Courses

Sestavte logický model

Dette innholdet er ikke tilgjengelig på ditt språk.

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)

Five different dog collars on pegs by a home's front door, each with its own blank metal tag, beside a leash, a brush and a water bowl.
Obrázek vytvořený pomocí AI

Modul 3 z 6 kapitoly Modelování dat podle významu, kapitoly 2 kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: Nakreslete vztahy · Další: Dejte data tam, kam patří

Otázka, na kterou tento modul odpovídá: Jak z konceptuálního modelu udělat logický datový model?

Konceptuální model nám řekl, co ve Steve Trucking existuje a jak to spolu souvisí: maloobchodní partneři a jejich distribuční centra, manifesty a doručení, příjemci, trasy a zastávky, posádky, kamiony a přiřazení posádek. To stačí na velmi produktivní rozhovor s byznysem. Nakonec ale potřebuji víc podrobností. Co potřebujeme vědět o doručení? Čím se jedno distribuční centrum liší od jiného? Jak identifikujeme příjemce? Co patří k přiřazení posádky, a ne k posádce nebo ke kamionu? Tyto otázky nás posouvají od konceptuálního modelu k logickému datovému modelu, a pořád ještě nestavíme v Salesforce.

Sedni, zůstaň, modeluj

Section titled “Sedni, zůstaň, modeluj ”

Nejdřív zpátky ke psům. Máme krabice a čáry. Teď dvě nové otázky: co o každé věci víme a jak jednu od druhé rozeznáme?

Co ji popisuje? Pes má jméno a datum narození. Majitel má jméno, telefonní číslo a adresu. Trik má název a obtížnost. Každý fakt jde na krabici, kterou popisuje.

Pak spojení. Jak dobře Bella umí Sedni a kdy se to naučila: popisuje to Bellu? Ne tak docela; některé triky umí lépe než jiné. Popisuje to Sedni? Ne; každý pes dělá Sedni jinak. Popisuje to Bellu a Sedni dohromady, takže to patří na Trik psa: úroveň dovednosti a datum naučení. Proto spojení existuje: některá fakta patří jen dvojici.

Který pes je který? Zkuste nejdřív jméno. Psů jménem Max je hodně, takže jméno jedinečné není. Telefonní číslo majitele? Marcus má dva psy na stejném telefonu, lidé čísla mění a jde o něčí osobní údaje, které by se zkopírovaly do každého systému, který kdy na psa ukáže. Číslo čipu vypadá lépe: je jedinečné a nemění se. Nové štěně ale ještě čip mít nemusí a klíč nesmí být prázdný. Číslo čipu tedy zůstane jako něco, pod čím je pes také znám, a pes dostane vlastní ID psa: číslo, které dělá jednu nudnou práci, rozlišuje jednoho psa od druhého.

Model psů s klíči a atributy Model psů jako podrobný datový model. Každá krabice uvádí své ID záznamu a několik polí. Majitel: ID majitele, jméno, telefon, PSČ, město. Chovatel: ID chovatele, jméno, město. Pes: ID psa, také známý pod číslem mikročipu, ID majitele a ID chovatele, jméno, datum narození. Plemeno, zatím nepropojené: ID plemene, název, velikost. Trik: ID triku, název, obtížnost. Trik psa, mezi Psem a Trikem: ID triku psa, ID psa a ID triku, úroveň dovednosti, datum naučení. Hodnocení triku, pod Trikem psa: jeho ID, ID triku psa, datum, úroveň dovednosti, kdo hodnotil. Čáry jsou stejné jako předtím: majitel vlastní psy, chovatel chová psy (pes má žádného nebo jednoho chovatele), pes umí triky psa, trik je v tricích psa a trik psa je ověřen v hodnoceních triku. vlastní chová umí je v je ověřen v Majitel ID majitele ID ZÁZNAMU Jméno Telefon ZIP Město Chovatel ID chovatele ID ZÁZNAMU Jméno Město Pes ID psa ID ZÁZNAMU Číslo mikročipu TAKÉ ZNÁMO JAKO ID majitele ID chovatele Jméno Datum narození Plemeno ID plemene ID ZÁZNAMU Název Velikost Trik psa ID triku psa ID ZÁZNAMU ID psa ID triku Úroveň dovednosti Datum naučení Trik ID triku ID ZÁZNAMU Název Obtížnost Hodnocení triku ID hodnocení triku ID ZÁZNAMU ID triku psa Datum Úroveň dovednosti Hodnotil právě jeden nula nebo jeden jeden nebo mnoho nula nebo mnoho © 2026 Twinshark LLC · stevetecharc.com
Kliknutím zvětšíte

Stejné otázky si teď položíme u Steve Trucking, a důvody, proč jméno, telefon i čip neobstojí, se promění v pravidlo, které zastávám už roky.

Konceptuální model říká, co existuje; logický říká, co to znamená jako data

Section titled “Konceptuální model říká, co existuje; logický říká, co to znamená jako data ”

Vezměte kamion. Co o kamionu potřebuji vědět? Možná číslo vozidla ve flotile, VIN, značku, model, modelový rok, SPZ, aktuální stav tachometru a stav. To jsou atributy kamionu.

Teď vezměte doručení. Možná číslo objednávky maloobchodního partnera, datum doručení, slíbené časové okno, skutečný čas příjezdu, stav a jestli zahrnuje instalaci nebo odvoz. Zase atributy.

Konceptuální model nám řekl, že doručení existuje. Logický model nám začíná říkat, co doručení znamená jako data. Jednoduchá krabice jako kamion nebo doručení může zastupovat celou sadu polí.

Od krabic k entitám s atributy Tři konceptuální krabice vlevo (Kamion, Doručení, Distribuční centrum), každá spojená čarou „se stane“ s logickou entitou vpravo, která vypisuje její atributy. Kamion: číslo vozidla, VIN, značka, model, modelový rok, SPZ, aktuální stav tachometru, stav. Doručení: číslo objednávky partnera, datum doručení, slíbené časové okno, skutečný příjezd, stav, včetně instalace, včetně odvozu. Distribuční centrum: název, adresa, trh, telefon. KONCEPTUÁLNÍ: CO EXISTUJE LOGICKÝ: CO TO ZNAMENÁ JAKO DATA se stane se stane se stane Kamion vozidlo Kamion Číslo vozidla VIN Značka Model Modelový rok SPZ Aktuální stav tachometru Stav Doručení jedna objednávka jednomu příjemci Doručení Číslo objednávky partnera Datum doručení Slíbené časové okno Skutečný příjezd Stav Včetně instalace Včetně odvozu Distribuční centrum odkud doručení odjíždějí Distribuční centrum Název Adresa Trh Telefon Většina našich diagramů si nechává jednoduchou krabici: pole přibývají, zastarávají a nesou podrobnosti (název API, popisek, typ, délka). © 2026 Twinshark LLC · stevetecharc.com
Kliknutím zvětšíte

I tak ale ve většině našich diagramů zůstávají krabice jednoduché, ze tří důvodů. Počet polí roste. Pole rychle zastarávají. A každé pole má podrobnosti, které se v objektovém modelu těžko ukazují: název API, popisek, datový typ a délku. Tyto podrobnosti se určitě zachytí, jen ne v prvním datovém modelu. Když opravdu pomůže ukázat několik klíčových polí, nakreslím podrobný datový model: zaměřený výřez jen s poli, na kterých záleží.

Atributy mají popisovat entitu

Section titled “Atributy mají popisovat entitu ”

Tady je jednoduchá otázka, kterou si kladu, když se dívám na atribut: co to popisuje? Značka kamionu zjevně popisuje kamion. Ale co jména členů posádky na doručení? Popisují doručení? Nebo popisují posádku, která měla přiřazení, které pokrývalo trasu, která zahrnovala tuto zastávku?

Tady začne datový model odhalovat věci, které na obrazovce vypadají naprosto rozumně. Dispečer řekne: „Chci na doručení vidět jména posádky.“ To je platný požadavek na uživatelský zážitek. Nemusí to ale být požadavek jména posádky na doručení ukládat. To jsou dvě různé věci a vrátíme se k nim u normalizace. Prozatím si zvykněte ptát se, jakou věc tento fakt doopravdy popisuje. Tahle otázka vám ušetří spoustu potíží.

Pak musíme mluvit o jedinečných ID

Section titled “Pak musíme mluvit o jedinečných ID ”

Atributy popisují věci. Je tu ale další problém k vyřešení: jak poznám, která věc je která?

Dva příjemci se jmenují John Smith. Jsou to tatáž osoba? Možná; možná ne. Jméno nestačí. Adresa? Lidé se stěhují. Telefonní čísla se mění. E-mailové adresy se mění. I název maloobchodního partnera se může změnit.

Tím se dostáváme ke klíčům: k tomu, co nám v modelu umožňuje něco jednoznačně identifikovat. Je to oblast, ve které jsem si za ta léta vytvořil dost silný názor. Od identifikátoru chci čtyři věci:

Jedinečný. Neměnný. Bez významu. Nikdy osobní údaje (PII).

Jedinečný. Identifikátor musí identifikovat právě jednu věc. Pokud mohou mít dvě doručení stejnou hodnotu, není to spolehlivý identifikátor doručení. Jména obvykle jedinečná nejsou, adresy jedinečné být nemusí a telefonní čísla se sdílejí. I hodnoty, které dnes vypadají jedinečně, už jedinečné být nemusí, jakmile máte dost dat. Ptejte se tedy: mohou mít dvě z nich někdy stejnou hodnotu? Pokud ano, buďte velmi opatrní, než ji použijete jako jedinečné ID záznamu.

Neměnný. Tohle se přehlíží. Pokud identifikujeme maloobchodního partnera podle názvu a partner se přejmenuje, získali jsme nového partnera? Ne. Obchodní entita zůstala stejná; změnil se jeden z jejích atributů. Jedinečné ID záznamu by mělo přežít změny věci, kterou identifikuje, a to vylučuje jména, e-mailové adresy, telefonní čísla, adresy i uživatelská jména, ať vypadají při první stavbě systému sebepohodlněji.

Bez významu. Když to slyšíte poprvé, zní to divně. Proč bych chtěl, aby byl identifikátor bez významu? Protože se význam mění. Představte si, že někdo postaví ID doručení, které kóduje DC, maloobchodního partnera, datum doručení a pořadové číslo: PHX-KEY-20261002-0042. Vypadá to chytře. Pak si příjemce přeloží doručení na pátek. Změníme identifikátor? Pokud ne, lže nám. Pokud ano, změnili jsme jedinečné ID doručení, protože se změnil jeden z jeho atributů, a každý systém, který si uložil staré ID, ho právě ztratil z dohledu. Identifikátor se snažil dělat dvě práce: doručení identifikovat a popsat. Raději nechám popis na atributech a identifikátoru nechám jednu nudnou práci: identifikovat. Nudné identifikátory jsou dobré identifikátory.

Nikdy osobní údaje. Tohle je dost důležité na to, abych to držel zvlášť. Nepoužívejte osobní údaje (PII) jako identifikátor jen proto, že vypadají jedinečně. Ve Steve Trucking je lákavé poznávat příjemce podle telefonního čísla. Klíč se ale kopíruje všude, kde systémy potřebují propojit záznamy: do integrací, exportů, logů, stavových souborů zpět k maloobchodním partnerům, do datového skladu, do testovacích dat. Udělejte z telefonního čísla klíč a rozšířili jste osobní údaje příjemce po celé architektuře.

Klíč také musí existovat u každého záznamu: nikdy null ani prázdný. Pokud vám někteří lidé hodnotu nedají, nebo by ji dávat neměli, nemůže být ta hodnota klíčem. Proto systémy vydávají vlastní interní identifikátory a osobní údaje, pokud je vůbec potřebujete, se stávají chráněným atributem.

Moje pravidlo tedy zní: jedinečný, neměnný, bez významu, nikdy osobní údaje.

Přirozené a náhradní klíče

Section titled “Přirozené a náhradní klíče ”

Databázoví lidé mají pro některé z toho názvy. Přirozený klíč už v obchodních datech existuje: dobrým příkladem je VIN kamionu. Naše aplikace ho nevymyslela a už má význam. Náhradní klíč (surrogate key) se vytváří výslovně k identifikaci záznamu; nic nepopisuje, jen identifikuje.

Ve většině architektur dávám přednost náhradnímu klíči jako internímu ID záznamu a důležité přirozené identifikátory si nechávám jako atributy. Neznamená to, že by přirozené identifikátory byly špatné; často jsou nesmírně důležité. Jen z nich automaticky nedělám jedinečné ID záznamu. Zeptejte se, co se stane, když se hodnota opraví, přeformátuje, nahradí, použije znovu, chybí, nebo přijde z víc než jednoho zdrojového systému. Tam se z jednoduše vypadajícího rozhodnutí stává rozhodnutí architektonické.

Jedna věc může mít několik užitečných identifikátorů

Section titled “Jedna věc může mít několik užitečných identifikátorů ”

Interní ID záznamu nemusí být identifikátor, který používají všechny ostatní systémy. Steve Trucking může doručení interně identifikovat vygenerovaným ID. Každý maloobchodní partner zná stejné doručení pod svým vlastním číslem objednávky: Keystone ve svém manifestu CSV, Redrock ve svém API, Brightwave ve svých zprávách EDI. A osm let historie v RouteDesk, starém dispečerském nástroji, používá vlastní ID doručení z RouteDesk.

Na těchto identifikátorech záleží. Musíme je uchovat a správně namapovat, protože aktualizace stavu musí jít ke každému partnerovi zpět pod jeho číslem. Nemusí se ale všechny stát jedinečným ID doručení. „Jaké má ID?“ může mít víc než jednu odpověď a architekt musí vědět, které ID je v kterém kontextu autoritativní. Vrátíme se k tomu u kmenových dat a integrace.

Vztahy závisejí na jedinečných ID

Section titled “Vztahy závisejí na jedinečných ID ”

Teď se vraťte k čarám, které jsme nakreslili. Manifest obsahuje seznam doručení. Příjemce přijímá doručení. Posádka má přiřazení posádky. Tyto vztahy fungují jen proto, že dokážeme spolehlivě identifikovat věci na obou koncích.

Tady to ve Steve Trucking kousne. Maloobchodní partner v den doručení upraví svůj manifest: objednávka zrušená, položka vyměněná, nová adresa. Pokud nedokážeme upravený řádek spárovat s doručením, které už máme, podle partnerova čísla objednávky, vytvoříme druhé doručení pro stejnou ledničku a posádka se může objevit dvakrát. Krabice, atributy, klíče a vztahy nejsou oddělené myšlenky. Jsou to všechno části stejného modelu.

Podrobný, zaměřený datový model Podrobný, zaměřený datový model pro Steve Trucking ve třech skupinách. Každá entita uvádí své ID záznamu (generované interní jedinečné ID), všechno, pod čím je také známa, a několik klíčových polí. Maloobchodní partner (název, fakturační adresa, stav) provozuje distribuční centra a posílá doručení. Doručení je také známé pod číslem objednávky partnera a pod ID doručení v RouteDesk; doručuje se příjemci (jméno, adresa, telefon, e-mail), odjíždí z distribučního centra (název, adresa, trh) a obsahuje položky doručení (produkt, množství, včetně instalace). Posádka obsluhuje přiřazení posádky a kamion (také známý pod svým VIN a číslem vozidla) je použitý v přiřazeních posádky, která mají datum zahájení a datum ukončení. ZÁKAZNICKÁ DATA TRANSAKČNÍ DATA REFERENČNÍ DATA provozuje posílá doručuje se do odjíždí z obsahuje obsluhuje použitý v Maloobchodní partner ID maloobchodního partnera ID ZÁZNAMU Název Fakturační adresa Stav Příjemce ID příjemce ID ZÁZNAMU Jméno Adresa Telefon E-mail Doručení ID doručení ID ZÁZNAMU Číslo objednávky partnera TAKÉ ZNÁMO JAKO ID doručení v RouteDesk TAKÉ ZNÁMO JAKO Datum doručení Slíbené časové okno Stav Položka doručení ID položky doručení ID ZÁZNAMU Produkt Množství Včetně instalace Přiřazení posádky ID přiřazení posádky ID ZÁZNAMU Datum zahájení Datum ukončení Distribuční centrum ID distribučního centra ID ZÁZNAMU Název Adresa Trh Posádka ID posádky ID ZÁZNAMU Název Stav Kamion ID kamionu ID ZÁZNAMU VIN TAKÉ ZNÁMO JAKO Číslo vozidla TAKÉ ZNÁMO JAKO Značka Model SPZ Stav právě jeden nula nebo jeden jeden nebo mnoho nula nebo mnoho © 2026 Twinshark LLC · stevetecharc.com
Kliknutím zvětšíte

V tuhle chvíli si možná říkáte: „Salesforce dává každému záznamu ID.“ Správně, a dostaneme se k tomu. Pokud data žijí v Salesforce, dostane každý záznam ID vygenerované Salesforce. Je kryptické a těžko čitelné, takže obvykle zpřístupníme i pole s ID, které lidé mohou používat, třeba číslo doručení D-000184227, pole typu Auto Number. Lidé si často myslí, že toto číslo je ID záznamu, ale není: ID Salesforce je pořád pod ním. Externí systém nebo databáze, Oracle či SQL Server, má také vlastní jedinečná ID. Architektura ale může nakonec zahrnovat Salesforce, finanční ERP, Snowflake, Data 360, systémy partnerů i systémy, které ještě neexistují. Logický model popisuje obchodní data, aniž by každé rozhodnutí záviselo na jedné technologii. Jak to Salesforce fyzicky implementuje, je pozdější krok.

Co tady rozhoduje architekt

Section titled “Co tady rozhoduje architekt ”

Když převádím konceptuální model na logický, rozhoduji:

  • Které atributy skutečně popisují každou entitu.
  • Jak je každá entita jednoznačně identifikovaná a zda je ten identifikátor dost stabilní, aby byl jejím jedinečným ID.
  • Které obchodní identifikátory (čísla objednávek partnerů, starší ID) je potřeba uchovat a namapovat.
  • Zda se jako klíč nepoužívají citlivé informace.
  • Zda vztahy propojují entity přes spolehlivá jedinečná ID.

Teď máme entity, vztahy, atributy a jedinečná ID: začátky skutečného logického datového modelu. Pořád tu ale je problém. Je velmi snadné dát naprosto platná data na špatné místo. A tady přichází na řadu normalizace.

K prozkoumání

Section titled “K prozkoumání ”