Slovník pojmů

Normalizace databáze

Normalizace omezuje rozpory v datech, ne počet sloupců za každou cenu. Cílem je mít pro důležitý fakt jasný zdroj pravdy, dokud měřený důvod nevyžaduje řízenou kopii.

Stručná definice

Jeden fakt má mít jedno smysluplné místo.

Normalizace rozpoznává údaje, které se opakují, a odděluje je podle skutečného významu. Když se aktuální název výrobce opakuje ve stovkách produktových záznamů, každá jeho změna hrozí rozporem. Samostatný záznam výrobce s odkazem z produktu pak chrání aktuální katalogový fakt na jednom místě.

Nejde o příkaz rozdělit vše do maximálního počtu tabulek. Historická cena, název produktu nebo výrobce v položce objednávky mohou být oprávněný snapshot, protože znamenají jiný časový fakt než aktuální katalog. Denormalizace pro vyhledávání, reporting nebo cache také může být správná, pokud má zdroj, způsob aktualizace a dohled nad zastaralostí.

Jaký problém řeší

Opakování dat a anomálie při jejich změně

Normalizovaný model je praktický hlavně pro transakční data, která se často mění a musejí zůstat konzistentní.

objednávka a opakující se položky místo seznamu v jednom poli
zákazník, produkt, výrobce a kategorie jako samostatné fakta
jedna změna názvu výrobce místo opravy stovek řádků
ochrana před smazáním poslední objednávky spolu s jediným záznamem produktu
odvozený vyhledávací index nebo cache s vědomou, řízenou duplicitou

Praktický model

Od opakování k jasným faktům

Neuspořádaný řádek může vypadat jako „1001 | Jana Nováková | Boty, ponožky | Acme, Acme“. Normalizovaný model rozdělí zákazníka, objednávku, položky, produkt, výrobce a kategorii do jejich vlastních záznamů. Vztahy pak vyjádří klíče místo textového seznamu.

Výsledný report může stále data spojit SQL dotazem. Vyhledávací index může navíc držet denormalizovaný produktový dokument, ale musí se synchronizovat z primárních dat.

Jak funguje

Od smíšeného exportu k souvisejícím tabulkám

Textová alternativa: neuspořádaný řádek objednávky se rozdělí na zákazníka, objednávku, položky, produkt a referenční vazby.

Najít opakování Model odhalí produkty jako seznam v textu nebo výrobce opakovaného v každé položce.
Popsat fakta Zákazník, objednávka, položka, produkt, výrobce a kategorie mají vlastní význam.
Rozdělit skupiny Více položek patří do order_items, ne do jednoho sloupce odděleného čárkami.
Propojit identity Primární a cizí klíče vyjádří vztahy a constrainty ochrání jejich platnost.
Kopírovat vědomě Pro reporting, fulltext nebo cache vznikne odvozená kopie jen s jasnou aktualizací a vlastníkem.

Důležité pojmy

Normalizační formy jsou praktická pomůcka.

Následující zkratky pomáhají odhalit běžné návrhové chyby bez akademického výkladu.

Anomálie při vložení

Nový produkt nebo výrobce nelze rozumně uložit bez vytvoření nesouvisející objednávky.

Anomálie při změně a smazání

Jeden fakt se musí opravit na mnoha místech, nebo se smazáním posledního řádku nechtěně ztratí jiná důležitá informace.

Funkční závislost

Jednoduše: známe-li identitu produktu, některé vlastnosti z ní jednoznačně plynou. Pomáhá odlišit vlastnost produktu od vlastnosti položky objednávky.

První až třetí normální forma

1NF vyžaduje atomické hodnoty a neschovává opakující se skupiny do jedné hodnoty; jejich rozdělení do řádků nebo tabulek je běžný důsledek návrhu. 2NF hlídá závislost na celém složeném klíči a 3NF omezuje zbytečnou závislost neklíčových údajů na jiných neklíčových údajích.

Denormalizace

Vědomá kopie nebo souhrn pro konkrétní čtení. Má mít důvod, zdroj pravdy, strategii aktualizace a kontrolu konzistence.

Vztah k podobným pojmům

Struktura dat není optimalizační index.

Normalizace řeší význam a závislosti, jiné nástroje řeší výkon konkrétních čtení.

Relační databáze: Model tabulek, klíčů a vztahů, pro který je normalizace přirozeným návrhovým nástrojem.
Databázový index: Zrychluje vybrané dotazy, ale neřeší, zda je fakt uložen na správném místě.
Elasticsearch: Často drží odvozený denormalizovaný dokument pro fulltext, ne primární transakční data.
Cache: Dočasná kopie výpočtu nebo dat; potřebuje invalidaci a nemá nahradit zdroj pravdy.

Výhody a omezení

Konzistence a výkon se navrhují společně.

Přínosy

méně míst, kde se může rozcházet stejný fakt
snazší ochrana integrity přes klíče a constrainty
předvídatelnější změny zákazníka, produktu či kategorie
lepší základ pro transakční systém a navazující odvozené modely

Časté chyby

dogmatické dělení každého údaje do samostatné tabulky
předčasná denormalizace bez strategie synchronizace
zaměnění normalizace s databázovým indexem nebo objektovým návrhem
přepis historického snapshotu aktuálním katalogovým údajem
považování cache či Elasticsearch za trvalý zdroj pravdy

Praktický příklad

Rozdělení objednávkového exportu

Nevhodný export může mít v orders zároveň customer_name, customer_email, product_names, manufacturer_name a několik položek v jednom textu. Při změně výrobce nebo zákazníka se stejné údaje rozpadají na více míst a položky nelze přesně filtrovat ani spojovat.

Praktičtější model má customers, orders, order_items, products, manufacturers a categories. order_items.unit_price přitom může být správný historický snapshot, protože cena v okamžiku nákupu nemá po změně katalogu zmizet.

Na co myslet

Nejdřív rozumějte datům, potom optimalizujte.

Výkonnostní problém se má měřit; kopie dat musí být vědomým návrhovým rozhodnutím.

rozlišit aktuální fakt od historického snapshotu
najít opakující se skupiny a závislosti mezi údaji
používat klíče a constrainty pro vztahy, které databáze vlastní
denormalizovaným kopiím dát zdroj, aktualizaci a monitoring
neřešit výkon přidáváním duplicit bez měření dotazů a indexů

Časté otázky

Normalizace v praxi

Musí být každá databáze ve třetí normální formě?

Ne. Normální formy jsou pomůcka pro návrh transakčních relačních dat, ne povinný žebříček. Záleží na významu dat, typech dotazů a ceně konzistence.

Je denormalizace chyba?

Ne, pokud jde o vědomou kopii pro konkrétní čtení, reporting nebo vyhledávání a je jasné, odkud se aktualizuje. Chybou je neřízená duplicita bez vlastníka.

Je JSONB alternativou normalizace?

Ne automaticky. Pomáhá s proměnlivým payloadem, ale u klíčových vztahů a pravidel často ztrácíte přímou integritu a cílené dotazy.

Proč ukládat cenu i do položky objednávky?

Cena v objednávce je historický fakt konkrétní transakce. Aktuální cena produktu může být jiný, později změněný údaj.

Jak tento princip používám v praxi

Datové modely dělím podle faktů, ne podle jedné obrazovky.

V e-commerce a integračních řešeních kombinuji relační zdroj pravdy s pragmatickými odvozenými modely pro vyhledávání, cache a reporting.

Jak pracuji s databázemi Nezávazně probrat projekt