Navrhujte do třetí normální formy, pak couvněte
Ta treść nie jest jeszcze dostępna w Twoim języku.
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 5 z 6 kapitoly Modelování dat podle významu, kapitoly 2 kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: Dejte data tam, kam patří · Další: Převeďte model do Salesforce
Otázka, na kterou tento modul odpovídá: Kdy se mám záměrně odchýlit od čistého normalizovaného modelu?
V minulém modulu jsem vám řekl, ať navrhujete pro třetí normální formu.
Teď vám řeknu, ať ji porušíte.
Někdy.
To je důležité rozlišení. Je velký rozdíl mezi tím omylem postavit chaotický datový model a záměrně denormalizovat čistý. Pokud vůbec nerozumíte tomu, kam data patří, jejich kopírování jinam není architektura. Je to jen duplicita.
Jakmile ale rozumím čistému logickému modelu, mohu se vědomě rozhodnout dát datům jiný tvar pro lidi a systémy, které je spotřebovávají.
Navrhujte do třetí normální formy, kde je to proveditelné. Pak couvněte, kde je to nutné.
Všimněte si, co ta věta neříká. Neříká, že třetí normální forma je srozumitelnější. Někdy je to naopak: plně normalizovaný model může jednu obchodní myšlenku rozházet do pěti objektů a lidé, kteří ho používají, si ji musí poskládat v hlavě. Normalizace mi říká, kam každý fakt patří. Neslibuje, že je to tvar, který se nejsnáze čte, používá nebo se nad ním nejsnáze dělají sestavy. Právě proto je couvnutí návrhovou dovedností, a ne selháním.
Začněte tím, že namodelujete pravdu. Pak rozhodněte, jak má být ta pravda doručena.
Sedni, zůstaň, modeluj
Section titled “Sedni, zůstaň, modeluj ”Zpátky ke psům, a tentokrát uděláme pár záměrných rozhodnutí.
Plemeno: výběrový seznam, nebo vlastní tabulka? Proženeme ho otázkami, které vám dám později v tomto modulu. Je tu víc než jeden sloupec informací? Ano: aspoň velikost. Kolik hodnot? Kynologické kluby uznávají několik set plemen (jen American Kennel Club jich uvádí 205), daleko za mým orientačním pravidlem zhruba 20. Plemeno si tedy zaslouží vlastní tabulku a každý pes ukazuje na své plemeno. Tím je rozhodnutá otázka, kterou si neseme od modulu 1: Plemeno je samostatná krabice.
Úroveň dovednosti: výběrový seznam. Učí se, Dobrá, Expert. Tři popisky, nic dalšího se o nich říct nedá a nebudou se měnit. Přesně k tomu je výběrový seznam.
Kolik triků každý pes umí? Odpověď už v modelu je: spočítejte psovy záznamy Trik psa. Trenér ale chce to číslo na každé sestavě, aby podle něj mohl řadit a filtrovat, bez stavění sestavy přes dvě tabulky. Couvnu tedy a nechám počet Zvládnuté triky přímo na psovi. To je kopie. Pravda pořád žije v Triku psa; počet je její reprezentace a musí s ní zůstat v souladu. Salesforce nám dává čistý způsob, jak přesně tohle udělat, a uvidíme ho v modulu 6.
A teď zvrat: psí škola začne brát kočky. Co uděláme? Jedna možnost: přidat tabulku Kočka vedle tabulky Pes a Trik kočky vedle Triku psa. Všechno se zdvojí: dvě od každé obrazovky, dvě od každé sestavy, a v den, kdy začnou brát králíky, tři. Druhá možnost: udělat krok zpět a všimnout si, že kočka má majitele, možná chovatele, plemeno, datum narození a s trpělivostí i trik nebo dva. Stejná fakta a stejné vztahy jako pes. Zobecníme tedy: Zvíře s Druhem, pes, nebo kočka. Každé plemeno také patří k nějakému druhu a právě tam druh doopravdy žije: labrador je pes. Zvíře nese kopii, záměrně, aby každá obrazovka a sestava mohla začít otázkou „pes, nebo kočka?“, aniž by musela hledat plemeno. Další záměrná kopie, a v modulu 6 dostane vlastní práci.
To je navrhování pro změnu, a je to kompromis. Zobecněte příliš brzy a ze všeho se stane vágní „Věc“ s polem typu, kterému nikdo nerozumí. Zobecňuji, když mi byznys skutečně přinese ten druhý druh a oba sdílejí téměř všechno, jako tady psi a kočky. Kdyby kočky potřebovaly úplně jiná fakta, dvakrát bych si to rozmyslel.
Teď stejné druhy rozhodnutí ve Steve Trucking, kde je ve hře víc.
Nejčistší model není vždycky nejlepší systém
Section titled “Nejčistší model není vždycky nejlepší systém ”Představte si posádku na zastávce. Doručení má své položky. Instalace má kontrolní seznam. Každý krok potřebuje fotky. Příjemce podepisuje.
Normalizovaný model je krásný: Doručení → Položka doručení → Kontrolní seznam instalace → Fotka, každé tam, kam patří.
Pak si sednu s lidmi, kteří to skutečně používají. Posádka uzavře asi deset zastávek denně, na příjezdových cestách, často bez signálu. Pokud je můj krásný model provede bludištěm obrazovek a seznamů souvisejících záznamů, aby dokončili jednu zastávku, mám architektonický problém.
Datový model není jediná věc, kterou navrhujeme.
Navrhujeme systém.
Někdy vyhraje uživatelský zážitek
Section titled “Někdy vyhraje uživatelský zážitek ”To je jeden z důvodů, proč někdy od dokonale normalizovaného modelu ustoupím: uživatelský zážitek.
Možná by pojem technicky mohl být samostatnou entitou, ale jeho oddělení přidá složitost, která přináší velmi malou hodnotu. Možná je nadřazený záznam s několika úrovněmi podřízených akademicky čistý, ale mizerný na zadávání a údržbu. Možná je pojem malý, stabilní a používá se hlavně jako výběr.
Tady se přestanu ptát jen „Kam tento fakt teoreticky patří?“ a začnu se ptát „Jak se bude tento systém doopravdy používat?“
Neznamená to, že každá stížnost na jedno kliknutí navíc model zploští. Znamená to, že použitelnost je legitimní architektonický vstup.
Někdy vyhrají sestavy
Section titled “Někdy vyhrají sestavy ”Sestavy jsou dalším častým důvodem.
Každý maloobchodní partner chce hodnoticí přehled: doručení včas podle regionu a měsíce. V čistém modelu doručení zná své distribuční centrum a DC zná svůj region. Technicky se tím dokážeme proklikat.
Ale dokáže to nástroj pro sestavy? Dokážou to lidé, kteří si stavějí vlastní sestavy? Dokážou na otázku odpovědět bez architektury sestav, která je složitější než otázka sama?
Tehdy možná zkopíruji nebo odvodím region na doručení, blíž k místu, kde se spotřebovává.
Teď jsem zavedl duplicitu. Potřebuji tedy další otázku: kdo vlastní pravdu?
Když se zdrojová hodnota změní, co se stane s mou kopií? Má se změnit? Nebo si má ponechat to, co platilo, když se doručení uskutečnilo? To jsou různé požadavky.
Denormalizace složitost neodstraní.
Přesune ji.
Lookup, nebo výběrový seznam?
Section titled “Lookup, nebo výběrový seznam? ”Tady je menší příklad, se kterým se administrátoři Salesforce setkávají pořád. Uživatel si potřebuje vybrat ze sady hodnot. Vytvořím další entitu a navážu se na ni, nebo použiji výběrový seznam?
Vezměte stav doručení: naplánováno, naloženo, na cestě, přijíždí, doručeno, nainstalováno, výjimka, vráceno. Krátký, stabilní seznam popisků. Výběrový seznam je přesně to, co chci.
Teď vezměte druh zastávky: jen doručení, doručení s instalací, doručení s odvozem. Ten nese vlastní informace: jak dlouho zastávka trvá, jaké dovednosti posádka potřebuje, který kontrolní seznam instalace platí. Mění se nezávisle a spravuje ho byznys. To je entita, ne popisek.
Pokud vytvořím objekt pro každý pojem, který by se dal teoreticky normalizovat, můžu postavit technicky krásný systém, který nikoho nebaví používat. Pokud z každého pojmu udělám výběrový seznam, protože je to snadné, můžu se velmi rychle zahnat do kouta.
Ptám se tedy: má to vlastní informace? Vztahy? Mění se to nezávisle? Musí se to spravovat jako data? Mohl by byznys od toho nakonec potřebovat víc než popisek?
Tady jsou otázky, které na návrhovém sezení skutečně kladu.
Je tu víc než jeden sloupec informací? Pokud hodnota potřebuje popis, dobu trvání, seznam dovedností, vlastníka, už to není popisek.
Kolik hodnot? Moje orientační pravidlo je zhruba 20. Za 20 hodnotami se výběrový seznam začíná lámat a je čas přemýšlet o objektu. Státy USA s padesáti jsou výjimka, se kterou žijeme, a země jsou ještě horší; upřímně, má někdo rád výběrové seznamy zemí? Mně přijdou otravné.
Vznikají hodnoty v průběhu času a kdo je vytváří? Přidání hodnoty výběrového seznamu je změna konfigurace, což znamená administrátora. Pokud byznys přidává hodnoty každý týden a lidé, kteří je přidávají, nejsou administrátoři, staví výběrový seznam před každou novou hodnotu požadavek na podporu.
Potřebují lidé podle toho filtrovat a dělat sestavy? Na to jsou výběrové seznamy skvělé. Lookupy nejsou tak čisté. Každý lookup přidá skok: typ sestavy sleduje jen krátký řetěz souvisejících objektů (vlastní typ sestavy dovoluje nejvýše čtyři vztahy mezi objekty), obrazovka se změní v seznamy souvisejících záznamů uvnitř seznamů souvisejících záznamů a kód se zkomplikuje.
Seznam hodnot často začíná život jako výběrový seznam a časem si vlastní samostatný objekt zaslouží. Nechte ho, ať si ho zaslouží.
Někdy měřítko změní odpověď
Section titled “Někdy měřítko změní odpověď ”Návrh, který s několika tisíci záznamy funguje nádherně, se může s miliony chovat úplně jinak.
Nedívejte se tedy jen na diagram. Znejte čísla.
Steve Trucking provede zhruba milion doručení ročně a roste o 30 procent ročně. Každé doručení nasbírá asi osm aktualizací stavu. To je letos osm milionů záznamů stavu a ve třetím roce zhruba 13,5 milionu ročně. Přidejte čtyři nebo pět milionů fotek ročně.
Stejný model. Úplně jiná architektura.
Mnohem hlouběji půjdeme v části Architektura ve velkém měřítku. Prozatím si zapamatujte: objem může změnit rozhodnutí v datovém modelování. Vztah, který je logicky správný, není automaticky nejlepším fyzickým návrhem v každém měřítku.
Různí spotřebitelé chtějí různé tvary
Section titled “Různí spotřebitelé chtějí různé tvary ”Zatím jsme přemýšleli o provozním systému. Dispečeři plánují trasy doručení. Posádky uzavírají zastávky. Systém se mění, jak byznys běží.
Byznys ale chce také analyzovat roky historie. Kteří partneři a regiony mají zpoždění? Jak se změnila doba doručení? Jak často instalace potřebují druhou návštěvu?
Analytický systém může chtít stejné informace uspořádané jinak. Uslyšíte pojmy jako datový sklad, fakt, dimenze a hvězdicové schéma. Tady je rozbalovat nebudeme; ve Steve Trucking je to datový sklad Snowflake a vrátíme se k němu později v kurzu.
Prozatím: různí spotřebitelé mohou potřebovat různé tvary téže pravdy.
AI přidává dalšího spotřebitele
Section titled “AI přidává dalšího spotřebitele ”A teď je tu další spotřebitel: AI.
Příjemce pošle SMS: „Kde je moje doručení?“ Asistent AI by mohl najít tohle:
Doručení 10427, trasa 3312, zastávka 7, kamion 117, okno 13:00–15:00.
Tradiční aplikace s radostí projde těmi vztahy. Aby ale asistent příjemci odpověděl, potřebuje kontext poskládaný z několika míst:
Vaše myčka nádobí od Redrock je sedmá zastávka na dnešní trase z distribučního centra ve Phoenixu. Kamion je tři zastávky od vás a pořád jste ve svém okně 13:00–15:00.
Vzali jsme informace z několika souvisejících entit a poskládali plošší reprezentaci bohatou na kontext pro jednoho konkrétního spotřebitele.
To neznamená, že svůj normalizovaný model zničím. A rozhodně to neznamená „AI má ráda plochá data, tak dejte všechno do jednoho obřího objektu“. To nedělejte.
Zdroj pravdy zůstává čistý. AI dostane reprezentaci postavenou pro práci, kterou dělá. Je to stejná myšlenka, jakou jsme právě viděli u analytiky:
Jeden zdroj pravdy může podporovat více tvarů pro spotřebu.
Do ukotvení v datech a vyhledávání půjdeme mnohem hlouběji později v kurzu.
Nevytvářejte více pravd
Section titled “Nevytvářejte více pravd ”Je tu nebezpečí.
Pokud zkopíruji region na doručení kvůli sestavám, pošlu zploštělou verzi do Snowflake a postavím verzi bohatou na kontext pro asistenta AI, která z nich je správná?
Ta otázka potřebuje odpověď. Chci vědět, kde žije autoritativní hodnota. Všechno ostatní je reprezentace té pravdy pro nějaký účel.
To místo je zdrojový systém (system of record). Denormalizované kopie mohou být dobré: obrazovka zastávky, hodnoticí přehled, Snowflake i kontext pro AI dělají svou práci lépe s tvarem postaveným pro ně a odkazovat se na ně je v pořádku. Když se ale něco změní, změna začíná ve zdrojovém systému, typicky v relačním modelu, a proudí ven do každé kopie. Nikdo neopravuje region ve Snowflake ani ručně neupravuje kontext AI. Opravte to u zdroje a nechte změnu proudit.
A nejvíc na tom záleží, když se data mění. Pokud se distribuční centrum dnes přesune do jiného regionu, mají doručení z minulého měsíce ukazovat nový region? Možná. Možná ne. Pro historii mohu potřebovat region, který platil, když se doručení uskutečnilo. To už není problém synchronizace. To je obchodní rozhodnutí.
Proto by se denormalizace nikdy neměla stát náhodou. Každý zduplikovaný fakt vyvolává otázky o vlastnictví, synchronizaci, historii a důvěře. Je to myšlení v kompromisech z kapitoly 1: vězte, co kupujete (snazší obrazovku, jednodušší sestavu, lepší kontext pro AI) a co platíte (duplicitní data, synchronizaci, složitější vlastnictví pravdy). A protože jsme začali od čistého logického modelu, můžeme ukázat na každou kopii a říct: „Vím, že tohle patří tamhle. Dávám sem jeho reprezentaci kvůli tomuto požadavku.“ To je rozhodnutí, které můžeme revidovat, zpochybnit a zapsat, aby další architekt věděl proč.
Co tady rozhoduje architekt
Section titled “Co tady rozhoduje architekt ”Když zvažuji denormalizaci, rozhoduji:
- Kde žije autoritativní zdroj každého obchodního faktu.
- Zda čistý model vytváří skutečné problémy uživatelům, sestavám, měřítku nebo výkonu.
- Zda jednodušší reprezentace stojí za duplicitu a jak kopie zůstane důvěryhodná.
- Zda se mají historické hodnoty měnit, když se změní aktuální zdroj.
- Zda analytika nebo AI potřebuje jiný tvar dat než provozní systém.
Výchozí bod se nikdy nemění: vězte, kam pravda patří. Pak, když to požadavky ospravedlní, jí dejte tvar pro doručení.
Příště se do obrazu vrátí Salesforce. Převedeme to, co jsme navrhli, na fyzický datový model.
K prozkoumání
Section titled “K prozkoumání ”- Build Powerful Reports with Custom Report Types (otevře se v nové kartě), Salesforce Admins, 24. června 2019 (ověřeno 2026-10-17): vlastní typ sestavy „can span up to 4 object relationships“ (může zahrnout až 4 vztahy mezi objekty).
- Unleash the hounds, terriers and lapdogs: American Kennel Club recognizes 3 more breeds (otevře se v nové kartě), PBS NewsHour, 2. ledna 2026 (ověřeno 2026-10-17): „The AKC recognizes 205 breeds, including these three newcomers.“ (AKC uznává 205 plemen včetně těchto tří nováčků.)
- Pro zábavu: FCI Breeds Nomenclature (otevře se v nové kartě), Fédération Cynologique Internationale (ověřeno 2026-10-17): seznam plemen mezinárodní federace v deseti skupinách. Projděte si ho a uvidíte, proč si Plemeno vysloužilo vlastní tabulku.