Dejte data tam, kam patří

🌐 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)

Obrázek vytvořený pomocí AI

Přeloženo pomocí AI. Komunita překlad zatím nezkontrolovala. Číst anglicky

Modul 4 z 6 kapitoly Modelování dat podle významu, kapitoly 2 kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: Sestavte logický model · Další: Navrhujte do třetí normální formy, pak couvněte

Otázka, na kterou tento modul odpovídá: Jak mi normalizace pomáhá zjistit, kam data skutečně patří?

Máme logický model: entity, vztahy, atributy a klíče. Teď chci položit jednu z nejdůležitějších otázek datového modelování: patří tato data opravdu sem?

Zní to jednoduše. Není to tak. Viděl jsem spoustu systémů, kde každé pole dávalo smysl, když ho někdo vytvořil. Problém nebyl v tom, že by pole byla nesmyslná; byl v tom, že fakta byla uložená na špatném místě. Doručení nese informace, které ve skutečnosti popisují distribuční centrum. Stejná adresa se objevuje na stovkách záznamů. Jedno pole obsahuje tři hodnoty oddělené čárkami. Změna jednoho obchodního faktu znamená aktualizovat 10 000 záznamů. To je problém, se kterým nám pomáhá normalizace, a než se zahrabeme do databázové terminologie, tady je celá myšlenka: dejte fakt tam, kam patří. Všechno ostatní v tomto modulu nám pomáhá dělat to systematičtěji.

Co je normalizace?

Normalizace je uspořádání dat tak, aby byl každý fakt uložený jednou, na místě, kam patří. Když jedna tabulka dělá příliš mnoho prací, rozdělíme ji na tabulky, z nichž každá popisuje jednu věc, a propojíme je klíči.

Proč se s tím obtěžovat? Protože fakt uložený jednou je fakt, který měníme jednou. Normalizace zabraňuje redundanci, tedy stejnému faktu zkopírovanému do mnoha záznamů, a s ní i nekonzistencím, které se vloudí, když se jedna kopie aktualizuje a ostatní ne. Proto sedí na transakční systémy, jako je Salesforce, kde se záznamy celý den vytvářejí a aktualizují.

Normalizujeme v krocích, kterým se říká normální formy, a každá klade jedinou otázku:

• První normální forma (1NF): jedna hodnota v každém poli a něco, co jednoznačně identifikuje každý řádek.
• Druhá normální forma (2NF): každý fakt popisuje celé to, co řádek identifikuje, ne jen jeho část.
• Třetí normální forma (3NF): každý fakt popisuje tuto věc, ne něco jiného, s čím souvisí.

Za třetí formou jsou ještě další. Řeknu o nich slovo později, i o tom, proč se obvykle zastavíme u třetí. Nejdřív se podívejme, jak tři kroky probíhají.

Proč normalizujeme?

Když tohle učím naživo, nezačínám doručeními. Začínám psy. Psům rozumí každý, takže nikoho neruší byznys a můžeme sledovat, jak si data hledají domov. Pak stejné kroky přeneseme do Steve Trucking.

Sedni, zůstaň, modeluj

Začátek: surová tabulka. Dám na obrazovku pár psů a pak místnost přidá svoje. Za pár minut máme jeden velký seznam: pes, rok narození, kdo ho vlastní, kde majitel bydlí, plemeno, kdo ho odchoval a jaké triky umí.

Pes	Narozen	Majitel	PSČ	Město	Plemeno	Chovatel	Triky
Bella	2017	Marcus	80202	Denver	Labrador	Maple Ridge	Sedni, Zůstaň, Podej pac
Milo	2019	Marcus	80202	Denver	Pudl	Golden Meadow	Sedni, Kutálej se
Max	2022	Ana	64105	Kansas City	Kříženec		Sedni, Mrtvý brouk
Luna	2020	Kenji	98101	Seattle	Husky	Cascade	Sedni, Zůstaň, Točka
Rocky	2024	Priya	30301	Atlanta	Bígl	Maple Ridge	Sedni
Coco	2014	Ana	64105	Kansas City	Čivava	Little Paws	Podej pac, Točka

Funguje to. Každá tabulka první den funguje. Ale podívejte se, co už je špatně. Jak najdu všechny psy, kteří umí Podej pac? PSČ Any je na dvou řádcích, stejně jako Marcusovo: co se stane, když ho někdo aktualizuje na jednom a na druhém ne? Maple Ridge se objevuje dvakrát, stejně jako Kansas City. A Max je z útulku, takže žádného chovatele nemá.

Krok 1: první normální forma. Dvě pravidla. Každé pole obsahuje jedinou hodnotu, takže seznam triků oddělený čárkami musí pryč. A každý řádek potřebuje něco, co ho jednoznačně identifikuje. Ne jméno psa; psů jménem Max je hodně. ID: automaticky generované ID nebo GUID. Triky se přesunou do vlastních řádků, jeden řádek pro každého psa a každý trik. A jakmile má trik vlastní řádek, je místo i pro to, co bychom v seznamu s čárkami nikdy nedokázali říct: jak těžký trik je, jak dobře ho tento pes umí a kdy se ho naučil.

Pes (identifikovaný podle ID psa)

ID psa	Jméno	Narozen	Majitel	PSČ	Město	Plemeno	Chovatel
D-001	Bella	2017	Marcus	80202	Denver	Labrador	Maple Ridge
D-002	Milo	2019	Marcus	80202	Denver	Pudl	Golden Meadow
D-003	Max	2022	Ana	64105	Kansas City	Kříženec
D-004	Luna	2020	Kenji	98101	Seattle	Husky	Cascade
D-005	Rocky	2024	Priya	30301	Atlanta	Bígl	Maple Ridge
D-006	Coco	2014	Ana	64105	Kansas City	Čivava	Little Paws

Trik psa (identifikovaný podle ID psa + triku)

ID psa	Trik	Obtížnost	Úroveň dovednosti	Naučen
D-001	Sedni	Snadná	Expert	2017-11
D-001	Zůstaň	Snadná	Expert	2018-01
D-001	Podej pac	Střední	Dobrá	2018-06
D-002	Sedni	Snadná	Expert	2020-02
D-002	Kutálej se	Těžká	Učí se	2023-05
D-003	Sedni	Snadná	Dobrá	2022-06
D-003	Mrtvý brouk	Těžká	Učí se	2024-03
D-004	Sedni	Snadná	Expert	2020-11
D-004	Zůstaň	Snadná	Dobrá	2021-01
D-004	Točka	Střední	Expert	2021-06
D-005	Sedni	Snadná	Učí se	2025-02
D-006	Podej pac	Střední	Expert	2015-06
D-006	Točka	Střední	Učí se	2025-04

Teď je „všichni psi, kteří umí Podej pac“ jednoduchá otázka. Všimněte si ale, podle čeho je Trik psa identifikovaný: ne podle jedné věci, ale podle dvou věcí dohromady, psa a triku. To si zapamatujte.

Krok 2: druhá normální forma. Druhá normální forma hraje roli jen tehdy, když je řádek identifikovaný kombinací, a Trik psa je. U každého sloupce se tedy ptám: popisuje celou kombinaci, nebo jen její část? Úroveň dovednosti popisuje tohoto psa při tomto triku: Bella je v Sedni expert, Rocky se ho ještě učí. Naučen, totéž. Ale obtížnost? Sedni je snadné, ať ho dělá kterýkoli pes. Popisuje trik, jen část klíče, a proto se „Snadná“ opakuje na každém řádku se Sedni. Trik tedy dostane vlastní tabulku a zbude dvojice.

Trik

ID triku	Trik	Obtížnost
T-01	Sedni	Snadná
T-02	Zůstaň	Snadná
T-03	Podej pac	Střední
T-04	Kutálej se	Těžká
T-05	Mrtvý brouk	Těžká
T-06	Točka	Střední

Trik psa (ID psa + ID triku)

ID psa	ID triku	Úroveň dovednosti	Naučen
D-001	T-01	Expert	2017-11
D-001	T-02	Expert	2018-01
D-001	T-03	Dobrá	2018-06
D-002	T-01	Expert	2020-02
D-002	T-04	Učí se	2023-05
D-003	T-01	Dobrá	2022-06
D-003	T-05	Učí se	2024-03
D-004	T-01	Expert	2020-11
D-004	T-02	Dobrá	2021-01
D-004	T-06	Expert	2021-06
D-005	T-01	Učí se	2025-02
D-006	T-03	Expert	2015-06
D-006	T-06	Učí se	2025-04

Tabulka Trik psa je ta, kterou jsme našli v modulu 2, a v datovém modelování má název: spojení (junction), nebo jak tomu říkám já, logický spojovací objekt. Pes umí mnoho triků; trik umí mnoho psů. Spojení sedí mezi nimi a není to prázdné instalatérství: obsahuje fakta, která patří samotnému vztahu, úroveň dovednosti a datum. Potkáme ho znovu v modulu 6 a v kapitole 3 uvidíme, že Salesforce používá „junction object“ úžeji: spojovací objekt Salesforce (Salesforce Junction Object) je vlastní objekt se dvěma vztahy master-detail (kapitola 3, modul 7).

Krok 3: třetí normální forma. Teď zpět k tabulce Pes. Všechno v ní je identifikované podle ID psa, takže druhá normální forma nemá co říct. Třetí normální forma klade jinou otázku: popisuje tento fakt psa, nebo něco jiného, s čím pes souvisí? Plemeno je samostatná věc: labrador je labrador, ať jde o kteréhokoli psa, a fakta o něm, třeba jeho velikost, patří k plemeni, ne k Belle. PSČ a město popisují majitele, ne psa: tam bydlí Ana, ať se díváme na kteréhokoli z jejích psů. Údaje o chovateli popisují chovatele. Každé z toho je fakt o jiném faktu, takže se každé přesune do vlastní tabulky a pes na něj ukazuje cizím klíčem:

• Pes: ID psa, jméno, narozen, ID majitele, ID plemene, ID chovatele
• Majitel: ID majitele, jméno, PSČ, město
• Plemeno: ID plemene, plemeno, velikost
• Chovatel: ID chovatele, název, město
• Trik a Trik psa z kroku 2

Ana je teď uložená jednou a oba její psi ukazují na ni. Maple Ridge je uložený jednou a tabulka Plemeno nám dává domov pro fakta o každém plemeni, třeba o jeho velikosti, pro která v tabulce nebylo kam. Cizí klíč může být prázdný: Max nemá ID chovatele, a to je poctivá odpověď, ne mezera. Pak místnosti položím chyták: kam patří datum, kdy majitel psa získal? K psovi. Pes má v tomto modelu v jednu chvíli jednoho majitele, takže to datum popisuje vztah psa k jeho majiteli.

Mohli byste jít o krok dál a oddělit město od PSČ; učebnice to dělají. V praxi adresa zůstává pohromadě a Kansas City navíc leží ve dvou státech, pěkná připomínka, že skutečný svět naše učebnice nečte.

Takhle to postupuje: tabulka, pak tři otázky, a každý fakt skončí na jednom místě. Udělejte krok zpět a podívejte se, co jsme postavili. Z jednoho chaotického seznamu se staly šest tabulek, z nichž každá popisuje jednu věc, propojené klíči:

Kliknutím zvětšíte

Nikdo k tomu nepotřeboval jediné slovo ze Salesforce. Jsou to jen psi, lidé kolem nich a to, co umí.

Teď to použijme na Steve Trucking

Na psech jsou kroky dobře vidět. Skutečný byznys jim dává váhu, protože stejné chyby stojí ve velkém měřítku skutečné peníze. Vezměme tedy stejné tři otázky do Steve Trucking. Představte si, že svá doručení vede takhle:

Doručení	Maloobchodní partner	Distribuční centrum	Město DC	Posádka	Kamion
1001	Keystone	Keystone Phoenix DC	Phoenix	Posádka 12	117
1002	Keystone	Keystone Phoenix DC	Phoenix	Posádka 8	122
1003	Keystone	Keystone Phoenix DC	Phoenix	Posádka 12	117

Na první pohled tu nic složitého není. Ale podívejte se na distribuční centrum. „Keystone Phoenix DC, Phoenix“ opakujeme na každém doručení, které z něj odjíždí: Steve Trucking provede asi 3 300 doručení denně z devíti DC, tedy pár set denně z každého. Co se stane, když se to DC přestěhuje? Kolik záznamů změníme a co se stane, když jeden vynecháme? Teď data říkají, že DC je ve dvou městech zároveň. To je anomálie při aktualizaci. Co když chceme založit nové DC před jeho prvním doručením? Co když smažeme poslední doručení z nějakého DC: smazali jsme právě jediné místo, kde jsme o něm cokoli měli?

To jsou různé příznaky stejného problému: smíchali jsme dohromady fakta o různých věcech. Fakta o distribučním centru patří k distribučnímu centru. Fakta o doručení patří k doručení. Fakta o posádce patří k posádce. To je normalizace v praxi.

První normální forma: neschovávejte opakující se strukturu

Začněme první normální formou, neboli 1NF, kde si lidé někdy normalizaci dělají těžší, než musí být.

Dejme tomu, že doručení má pole Položky: „Lednička, sada výrobníku ledu, odvoz.“ Do jednoho pole jsme dali tři informace. Vypadá to pohodlně, dokud se někdo nezeptá: „Kolik odvozů jsme minulý měsíc udělali?“ Nebo si představte pole Položka 1, Položka 2 a Položka 3. Funguje to až do doručení se čtyřmi položkami. Problém není v tom, že jsme zvolili špatný počet polí Položka. Problém je v tom, že jsme nerozpoznali opakující se strukturu. Doručení může mít několik položek. To jsou data, která bychom měli namodelovat: položka doručení, kterou jsme našli v modulu 2.

Kliknutím zvětšíte

Praktické poučení z 1NF: neschovávejte opakující se strukturu do polí. Když vám byznys řekne, že se něco může stát mnohokrát, poslouchejte. Možná se ven dere další entita.

Ve skutečných orgech to uvidíte pořád. Někdo potřebuje popis v několika jazycích, takže vytvoří pole Description_English, pak Description_French, pak Description_German. Nebo schválení potřebuje pár lidí, a tak vznikne Schvalovatel 1, Schvalovatel 2, Schvalovatel 3. Když to najdu při revizi, je to plácnutí přes prsty a oprava datového modelu. Jedno nebo dvě, možná, pokud byznys opravdu vždycky má jen jedno nebo dvě. Cokoli víc by měl být podřízený objekt: Překlad s jazykem, Krok schválení se schvalovatelem. Další jazyk nebo čtvrtý schvalovatel se pak stane novým záznamem, ne novým polem a nasazením.

Druhá normální forma: popisujte celou věc

Druhá normální forma, neboli 2NF, hraje roli, když je záznam identifikovaný kombinací věcí. Vezměte položku doručení. Má vlastní ID záznamu, ale každá je jedinečná podle doručení + produktu. Dejme tomu, že ukládáme doručení, produkt, množství a popis produktu.

Množství tu dává smysl: popisuje tento produkt na tomto doručení. Popis produktu ale nepopisuje kombinaci; popisuje produkt. Dejte ho na každou položku doručení a budeme ho opakovat pokaždé, když ten model ledničky odjede na dalším kamionu. To je vodítko, že fakt patří jinam.

Otázka 2NF tedy zní: popisuje tento atribut celou věc, kterou identifikuji, nebo jen její část? Pokud popisuje jen produkt, patří k produktu. Pokud popisuje místo produktu na tomto konkrétním doručení (množství, jestli se instaluje), patří na položku doručení. Mnoho administrátorů si nikdy vědomě neřekne: „Teď uplatňuji druhou normální formu.“ To je v pořádku. Mnohem víc mi záleží na tom, abyste se naučili ptát: co tento fakt doopravdy popisuje?

Třetí normální forma: neukládejte fakta o jiných faktech

Teď ta, na které mi při každodenním modelování záleží nejvíc: třetí normální forma, neboli 3NF.

Každé distribuční centrum má na straně maloobchodního partnera vedoucího, někoho, kdo používá partnerský portál. Dejme tomu, že jméno vedoucího DC dáme přímo na každé doručení. Co se stane, když DC dostane nového vedoucího? Aktualizujeme každé doručení z toho DC. To je zase ten zápach: opakujeme fakt, který patří jinam. Doručení odjíždí z DC; DC má vedoucího. To jsou dva vztahy a jméno vedoucího patří k DC.

Klasická učebnicová verze je adresa: PSČ, město a stát uložené společně na každém záznamu, přestože město a stát obvykle vyplývají z PSČ. Stejný tvar, stejná otázka.

Kliknutím zvětšíte

Praktická otázka 3NF zní: popisuje tento fakt tuto věc, nebo něco jiného, s čím tato věc souvisí? Chci, abyste si ji kladli neustále.

Teď udělejte krok zpět, stejně jako u psů. Z tabulky doručení, se kterou jsme začali, se staly čtyři věci, z nichž každá drží svá vlastní fakta: položka doručení vyšla ven u první normální formy, produkt u druhé a město a vedoucí distribučního centra se u třetí přesunuli k distribučnímu centru.

Kliknutím zvětšíte

Stejné tři otázky, stejný výsledek: každý fakt na jednom místě.

Jednoduchý způsob, jak myslet o 1NF, 2NF a 3NF

Normalizaci můžete věnovat celý databázový kurz. My to dělat nebudeme. Pro tento kurz chci, abyste jí rozuměli prakticky, jako architekt:

• 1NF: neschovávám do pole nebo záznamu více hodnot nebo opakující se struktury?
• 2NF: popisuje tento fakt celou věc, kterou identifikuji?
• 3NF: popisuje tento fakt opravdu tuto entitu, nebo něco, co s ní souvisí?

To nejsou definice do databázové učebnice. Jsou to otázky, které můžu při navrhování skutečně použít.

Ano, normalizace jde dál: Boyce-Coddova normální forma (BCNF) zpřísňuje pravidla kolem 3NF pro modely se složitějšími klíči a existuje čtvrtá, pátá, a dokonce šestá normální forma. Řeší vzácnější druhy opakování, takové, které vzniká spíš z neobvyklých struktur klíčů než z běžných obchodních záznamů. Spousta teorie, a podle mých zkušeností nestojí za tu bolest hlavy u systémů, jaké stavíme na Salesforce. V obchodních systémech tlak obvykle působí opačně: mnohem spíš od třetí normální formy couvneme, kvůli uživatelům, sestavám a výkonu, než abychom šli za ni. To je další modul. Vězte, že další formy existují, ale pro většinu toho, co děláme, nám 1NF až 3NF dávají nástroje myšlení, které potřebujeme.

Navrhujte pro třetí normální formu

Tady je můj postoj. Když se snažím porozumět byznysu a navrhnout jeho logický model, chci začít načisto: fakta o doručení u doručení, fakta o distribučním centru u DC, fakta o kamionu u kamionu, opakující se pojmy namodelované jako pojmy. Nechci, aby byl obchodní fakt zkopírovaný po celém modelu jen proto, že by to mohlo usnadnit obrazovku nebo sestavu. Zatím ne.

Normalizace ale není náboženství. Cílem není akademicky nejčistší možný model. Viděl jsem architekty tak zaměřené na čistotu, že se model stal utrpením pro každého, kdo ho musí používat. Nesnažíme se vyhrát soutěž v normalizaci; stavíme systém a ten systém má uživatele, sestavy, integrace, výkonové potřeby, měřítko a čím dál častěji i AI, která data čte. Ti všichni mohou chtít data v různých tvarech.

Můj výchozí bod tedy zní navrhujte do třetí normální formy, kde je to proveditelné, a pak couvněte, kde je to nutné: nejdřív pochopte, kam každý fakt patří. Pokud se pak od toho odchýlíme, chci vědět proč. Pokud odpověď zní „protože jsem nevěděl, kam jinam to pole dát“, to nestačí. Pokud odpověď zní „tuto hodnotu jsme záměrně zkopírovali, protože to zjednodušuje hodnocení partnerů, a máme spolehlivý způsob, jak ji udržet synchronizovanou“, teď vedeme architektonický rozhovor.

Co tady rozhoduje architekt

Když normalizuji logický model, hledám:

• Opakující se hodnoty nebo struktury, které by se měly modelovat zvlášť.
• Atributy, které popisují jinou entitu než tu, na které jsou uložené.
• Fakta zbytečně zduplikovaná v mnoha záznamech a závislosti, kvůli kterým se rozcházejí.
• Obchodní pojmy schované uvnitř polí.
• Čistý model, který reprezentuje pravdu před jakýmikoli ústupky implementaci.

Ne proto, že by každý fyzický systém musel zůstat dokonale normalizovaný. Právě naopak. V dalším modulu se od čistého modelu záměrně odchýlíme, kvůli uživatelům, sestavám, měřítku, analytice a AI, a uděláme to s přesným vědomím toho, za co to vyměňujeme.