Normalizace databáze (database normalization)

Příklady z praxe

1. 01

   Zákazník opakovaný v objednávkách

   E-shop ukládal e-mail a jméno zákazníka přímo do každé objednávky. Po změně e-mailu zůstaly starší objednávky s původní hodnotou a zákaznická podpora hledala zákazníka pod dvěma identitami. Rozdělení na tabulky zákazníků a objednávek přesunulo kontakt na jedno místo a objednávky na něj jen odkazují.

   -- Problematický tvar: zákazník se opakuje u každé objednávky
   CREATE TABLE orders_flat (
     order_id integer PRIMARY KEY,
     customer_email text,
     customer_name text,
     ordered_at timestamp
   );
   
   -- Normalizovaný tvar: zákazník má vlastní tabulku
   CREATE TABLE customers (
     customer_id integer PRIMARY KEY,
     email text UNIQUE NOT NULL,
     name text NOT NULL
   );
   
   CREATE TABLE orders (
     order_id integer PRIMARY KEY,
     customer_id integer NOT NULL REFERENCES customers(customer_id),
     ordered_at timestamp NOT NULL
   );

2. 02

   Seznam štítků v jedné buňce

   Katalog produktů měl ve sloupci `tags` hodnoty jako `notebook,akce,skladem`. Filtr podle štítku byl pomalý a překlepy vytvářely duplicitní varianty stejného štítku. Spojovací tabulka `product_tags` umožnila ukládat každý vztah produkt-štítek samostatně a databáze začala hlídat duplicity přes primární klíč.

   CREATE TABLE products (
     product_id integer PRIMARY KEY,
     name text NOT NULL
   );
   
   CREATE TABLE tags (
     tag_id integer PRIMARY KEY,
     label text UNIQUE NOT NULL
   );
   
   CREATE TABLE product_tags (
     product_id integer REFERENCES products(product_id),
     tag_id integer REFERENCES tags(tag_id),
     PRIMARY KEY (product_id, tag_id)
   );

Časté omyly

MýtusNormalizace databáze znamená, že se musí odstranit úplně všechny duplicity.

Ve skutečnostiNormalizace databáze odstraňuje škodlivé redundance vyplývající ze špatných závislostí. Některé kopie dat mohou být záměrné, například historická cena na faktuře nebo odvozená analytická tabulka.

MýtusTřetí normální forma je vždy konečný a nejlepší stav návrhu.

Ve skutečnostiTřetí normální forma je užitečný praktický cíl, ale ne univerzální maximum. Některé modely potřebují přísnější kontrolu závislostí, jiné naopak vědomou denormalizaci kvůli reportům nebo výkonu čtení.

Časté dotazy

Má smysl normalizovat databázi i v malém projektu?

Normalizace databáze je obvykle dobrý výchozí bod pro transakční systémy, ale malý projekt nemusí hned modelovat každou věc do nejjemnějšího detailu. Důležité je poznat údaje, které se budou měnit nezávisle a mohou se opakovat. Zákazník, objednávka, produkt a adresa si samostatné tabulky často zaslouží i v jednoduché aplikaci, protože pozdější oprava duplicit bývá dražší než rozumný návrh na začátku.

Zpomalí normalizace databáze aplikaci?

Normalizace databáze může zvýšit počet spojení v dotazech, ale sama o sobě neznamená pomalou databázi. Výkon závisí na objemu dat, indexech, dotazech, plánovači databáze a vzorcích používání aplikace. Normalizovaný model často zrychlí zápisy a sníží počet chyb, protože se upravuje méně míst. Pokud jsou čtecí dotazy kritické, běžným řešením je cílený odvozený pohled, materializovaná tabulka nebo cache, ne návrat k náhodným duplicitám.

Jak poznám, že tabulka porušuje normalizaci databáze?

Normalizace databáze se pozná podle závislostí mezi hodnotami, ne jen podle počtu tabulek. Podezřelé jsou sloupce s opakovanými skupinami, seznamy hodnot v jedné buňce, údaje zákazníka uložené u každé objednávky nebo atributy, které závisí na jiném neklíčovém atributu. Praktický test zní: když se jedna skutečnost změní, musí se upravit více řádků nebo více tabulek? Pokud ano, model pravděpodobně obsahuje zbytečnou duplicitu.

Stačí pro normalizaci databáze používat cizí klíče?

Normalizace databáze chrání logickou konzistenci modelu, zatímco cizí klíče jsou jeden z nástrojů, jak pravidla vynutit v relační databázi. Návrh může být teoreticky normalizovaný, ale bez omezení v databázi zůstává část odpovědnosti na aplikaci. Cizí klíč například zabrání objednávce od neexistujícího zákazníka. Normalizace rozhoduje, kam vztah patří; databázové omezení hlídá, že se vztah skutečně dodržuje.

Zdroje

1. Database normalization(otevře se v novém okně)Wikipedia
2. 5.5. Constraints(otevře se v novém okně)PostgreSQL Global Development Group
3. SQLite Foreign Key Support(otevře se v novém okně)SQLite
4. Description of the database normalization basics(otevře se v novém okně)Microsoft

Související pojmy

• JOINJOIN je operace v SQL, která skládá řádky ze dvou nebo více tabulek podle zadané podmínky, typicky podle shody primárního a cizího klíče. Umožňuje číst normalizovaná data jako jeden výsledek, ale může měnit počet řádků i výkon dotazu.
• DenormalizaceDenormalizace je záměrné zavedení redundance do datového modelu, typicky zkopírováním nebo předpočítáním hodnot z jiných tabulek, aby čtení nemuselo spojovat mnoho tabulek a agregovat je za běhu. Denormalizace zrychluje dotazy výměnou za větší objem dat, složitější zápisy a riziko, že se kopie hodnoty rozejdou s originálem.
• Primární klíčPrimární klíč je databázové omezení, které jednoznačně identifikuje každý řádek tabulky a nedovolí prázdnou ani duplicitní hodnotu. Slouží jako stabilní adresa záznamu pro dotazy, vazby mezi tabulkami i kontroly integrity. V relačních databázích bývá tvořen jedním sloupcem nebo kombinací více sloupců.
• Katalog produktůKatalog produktů je strukturovaná databáze zboží a služeb e-shopu, která pro každou položku drží identifikátory, názvy, popisy, parametry, varianty, ceny, dostupnost a obrázky. Katalog produktů tvoří jádro elektronického obchodu: z něj čerpají výpisy kategorií, vyhledávání, filtry, objednávkový proces i exporty do srovnávačů a reklamních systémů.
• ACIDACID je sada čtyř vlastností databázové transakce: atomicity, consistency, isolation a durability. Zaručuje, že skupina zápisů proběhne jako jeden celek, neporuší definovaná pravidla databáze, nebude se nebezpečně míchat s jinými transakcemi a po potvrzení přežije pád systému, například při převodu peněz.
• Adaptive IconAdaptivní ikona je formát ikony aplikace na Androidu, který se místo jedné hotové bitmapy skládá z oddělených vrstev: pozadí a popředí. Systém výsledný tvar sám ořízne podle masky výrobce zařízení a může vrstvy animovat nebo přebarvit. Vývojář tak dodá jeden zdroj a launcher z něj vytvoří kruh, čtverec i squircle.
• Adresa v pamětiAdresa v paměti je číslo, kterým procesor jednoznačně označuje konkrétní buňku operační paměti, obvykle jeden bajt. Program pomocí adresy říká, odkud má data načíst nebo kam je zapsat. Adresy tvoří souvislý číselný rozsah, jehož velikost určuje šířka adresní sběrnice a architektura, typicky 32 nebo 64 bitů.
• AI agentAI agent je softwarový systém, který pomocí modelu umělé inteligence vnímá zadaný kontext, plánuje další kroky a samostatně volá nástroje nebo služby k dosažení cíle. Na rozdíl od jednorázového promptu udržuje stav úlohy, vyhodnocuje výsledky akcí a může opakovat postup, dokud nesplní zadání nebo nenarazí na limit.