Jan Mikoláš
Slovník pojmů
Relační databáze
Relační model není jen tabulkový vzhled dat. Stojí na významu sloupců, identitě řádků, vztazích, constraintách, SQL dotazech a transakcích.
Stručná definice
Tabulky a klíče popisují související fakta.
Relační databáze drží jeden druh faktu v tabulce a vztahy vyjadřuje klíči. Tabulka zákazníků tak nemusí opakovat údaje v každé objednávce; objednávka na zákazníka odkazuje. Databáze potom může spojovat související řádky dotazem, chránit odkazy cizím klíčem a provádět změny v transakci.
Relační model není Doctrine ORM ani tabulkový procesor. ORM je aplikační vrstva mapující PHP objekty; spreadsheet typicky nehlídá stejnou integritu a souběh. Konkrétní relační databází je například PostgreSQL, zatímco SQL je jazyk, kterým se s takovými daty pracuje.
Jaký problém řeší
Vztahy, které nesmějí skončit jako volný text
Relační model má největší hodnotu tam, kde data vzájemně souvisejí a pravidla musejí platit i při souběhu.
- objednávkový proces, položky, platby, vratky a sklad
- produkty, varianty, ceny, kategorie a výrobci
- uživatelé, organizace, role a tenantní kontext
- importy propojené s jedinečnými externími identifikátory
- interní systémy s přehledy napříč více druhy dat
Praktický model
Vztahy v e-shopu
Objednávka obsahuje customer_id. Položka objednávky obsahuje order_id a product_id. Cena a název položky mohou být historický snapshot nákupu, zatímco tabulka products drží aktuální katalogový stav. Tato záměrná duplicita má jiný časový význam a není stejná jako nekontrolované kopírování dat.
Při založení objednávky databáze ověří cizí klíče a v transakci uloží objednávku i její položky. Dotaz s JOIN potom pro administraci sestaví potřebný přehled.
Jak funguje
Zákazník, objednávka a položka v jednom modelu
Textová alternativa: jeden zákazník má více objednávek; objednávka má více položek a každá položka odkazuje na produkt.
- Zákazník Tabulka customers drží stabilní identitu a údaje zákazníka.
- Objednávka Tabulka orders nese customer_id, který odkazuje na zákazníka a vyjadřuje vztah jeden ku více.
- Položka objednávky Tabulka order_items nese order_id a product_id; rozděluje opakující se položky na samostatné řádky.
- Klíče a constrainty Primární klíče určují identitu a cizí klíče chrání platné vazby mezi tabulkami.
- SQL join Dotaz spojí objednávku, zákazníka a položky pro administraci nebo API, aniž by se celý záznam kopíroval.
Důležité pojmy
Relace znamená víc než několik tabulek vedle sebe.
Pojmy popisují, co data znamenají a jak spolu mohou souviset.
Tabulka, řádek a sloupec
Tabulka ukládá jeden typ záznamu. Řádek je konkrétní záznam a sloupec jeho pojmenovaný atribut s datovým typem.
Doména hodnot
Datový typ a další pravidla určují, jaké hodnoty dávají ve sloupci smysl. Cena, datum a e-mail nemají stejnou povahu.
Klíče a vztahy
Primární klíč identifikuje řádek. Cizí klíč odkazuje na jiný řádek a chrání referenční integritu.
Jedna ku jedné, jedna ku více, více ku více
Jedna objednávka má více položek. Vztah více ku více, například produkt a kategorie, se vyjadřuje spojovací tabulkou.
Normalizace a transakce
Normalizace omezuje neřízené opakování faktů. Transakce drží související lokální změny pohromadě.
Vztah k podobným pojmům
Model, produkt a aplikační vrstva jsou tři různé věci.
Relační databáze je obecný model; nástroje nad ním mají jiné role.
- Databáze
- Obecné úložiště dat; relační databáze je jen jeden z možných modelů.
- PostgreSQL
- Konkrétní relační databázový systém, který model realizuje vlastním SQL dialektem.
- Doctrine ORM
- Mapuje objekty na relační data, ale nenahrazuje klíče, constrainty ani návrh schématu.
- Dokumentová databáze
- Často ukládá celek jako dokument; hodí se pro jiné přístupové vzory a kompromisy než vztahy v tabulkách.
Výhody a omezení
Integrita neznamená bezmezně dělit data.
Přínosy
- jasné vztahy a ochrana neplatných odkazů
- SQL dotazy a agregace napříč souvisejícími daty
- transakční změny a databázové constrainty
- omezení duplicit faktů v transakčním modelu
Časté chyby
- považování každé tabulky za objekt aplikace
- vztahy bez constraintů, které dovolí neplatné odkazy
- představa, že JSON automaticky nahradí celý relační model
- dělení dat do co nejvíce tabulek bez ohledu na jejich význam
- zaměňování ORM za samotnou relační databázi
Praktický příklad
Objednávka není jeden nekonečný dokument.
Model customers → orders → order_items → products vyjadřuje, že zákazník může mít více objednávek a produkt se může objevit v mnoha položkách. Spojovací tabulka je stejný princip pro vztah více ku více, například products ↔ categories.
JSON sloupec může přirozeně nést proměnlivý payload externího API. Jádro objednávky, ceny, identity a vztahy však často potřebují tabulky, typy a constrainty, aby byly dobře dotazovatelné a konzistentní.
Na co myslet
Vztah musí mít význam, vlastníka a pravidlo.
Datový model se navrhuje podle skutečných faktů a změn, ne jen podle aktuální obrazovky formuláře.
- pojmenovat, který fakt patří do které tabulky
- zvolit stabilní identitu řádků a cizí klíče pro interní vazby
- měřit dotazy a teprve potom přidávat indexy nebo denormalizaci
- rozlišit aktuální katalogová data a historický snapshot objednávky
- nechat ORM doplňovat práci s daty, nikoli skrýt základní model
Časté otázky
Relační model v praxi
Je každá databáze s tabulkami relační?
Ne nutně. Relace, klíče, integrita a způsob práce s daty jsou důležitější než samotný tabulkový vzhled.
Musím vždy používat cizí klíče?
U interních dat, kde databáze vlastní oba konce vztahu, jsou často vhodnou ochranou. Na hranici externí služby stejnou garanci databáze obvykle poskytnout nemůže.
Nahrazuje JSON relační model?
Ne. Hodí se pro proměnlivá doplňková data, ale u klíčových vztahů často ztrácí přímou integritu, constrainty a pohodlné dotazy.
Je Doctrine ORM relační databáze?
Ne. Je to PHP nástroj pro práci s relačními daty; databáze, SQL a její pravidla zůstávají samostatnou vrstvou.
Jak tento princip používám v praxi
Relační data navrhuji podle skutečných vztahů a změn.
U e-shopů a interních systémů řeším model objednávek, produktů, integračních identit i výkon dotazů nad jasně oddělenými fakty.