1. normální forma - syntakticky i sémanticky

Jednou jeden kolega na jedné své přednášce řekl, že nejhorším sloupcem v tabulkách je sloupec poznámka. Často se stává, že do poznámky se pak ukládají jinde neumístitelná data, protože s datovým modelem se různých důvodů nechce hýbat. Pak pro výběr dat z takovéhoto sloupce musíte používat složitou heuristiku.

Mohu to potvrdit z vlastní praxe.  Normalizace datového modelu databáze pomůže těmto i mnohým jiným problémům lehce předcházet.  Dnes bychom se podívali na to, jak by se s takovou poznámkou mělo zacházet. Neboli 1. normální forma. V tomto článku čerpám ze svých materiálů z přednášky „Entitno relační modelování“ (březen 2016).

Abstrakce : 1. Normální forma

Tabulka je v 1. NF právě když :

1. Každý sloupec má jedinečný název v rámci tabulky.
2. Každý sloupec má jeden datový typ.
3. Žádné dva řádky nemohou obsahovat stejné hodnoty (primární klíč tabulky).
4. Každý sloupec musí obsahovat jednu hodnotu (atomičnost).

Příklad Dodržíme syntax

V Excelu jsme vytvořili seznam členů spolku a protože jich máme již hodně, rozhodneme se je převést do relační databáze. Tak vytvoříme kopií excelovského souboru v datbáze a dostaneme toto :

Krásná tabulka, která není v 1. normální formě. Ptáte se proč? Pojďme společně ověřit si data.

1. Každý sloupec má jedinečný název v rámci tabulky.

        Splněno OK. Máme jméno a pak adresu

2. Každý sloupec má jeden datový typ.

       Splněno OK

3. Žádné dva řádky nemohou obsahovat stejné hodnoty (primární klíč tabulky).

   Splněno. Od katastorfy nás v případě Michala Pohnoutky zachránilo pouze to že za příjmení jsme dali přívlastek. Asi bychom mněli zavést něco jako osobní číslo, které by bylo pro každého člena jedinečné.

4. Každý sloupec musí obsahovat jednu hodnotu (atomičnost).

Splněno ? Ne určitě ne. Sloupec jméno obsahuje vlastní jméno, příjmení, titul- nebo přívlastek. Adresa taky obsahuje Stát, Město,ulici, číslo popisném, část obce a psč. Ptáme se jak bychom pomocí SQL jazyka např: vzbrali seznam všech měst. Asi těžko.

Proto bychom měli udělat následující úpravu uložení dat v tabulce.

Takhle jsem zabespečili, že jednak jsou data uložená v atomické podobě a jednak jsou jednoduše identifikovaná pomocí jedinečného klíče osobní číslo.

Příklad Jak dodržením syntaxe nedodržíme sémanitku

Mnozí z nás se naučili pracovat a myslet v intentcích tabulkových procesorů jako je Excel. První věcí když nepostačuje sílá Excelu, je uložit data do databáze. V PostgreSQL to jde velice jednoduše. Data uložíte do .cvs formátu (uložit jako) a buďto příkazy copy nebo /copy nebo přes fdw dostaneme data do databáze. Pak můžeme dostat tuhle tabulku.

Pro jistotu jednotlivé sloupce jsou v datovém typu text.

Takáto tabulka v databáze není v 1. normální formě. Proč ?

1. Podmínka je splněna. Každý sloupec má jedinečný název. I kdybychom se pokusili vytvořit tabulku se stejným pojmenováním sloupců, tak PostgreSQL nám to neumožní.

2. Podmínka je splněna. Každý sloupec má jeden datový typ. V našem případě text, protože ten je univerzální. Zde bych se zastavil. Zvolili jsme datový typ text, ale sami vidíme, že některé sloupce jsou skutečně textové jako kategorie. Ale jiná jsou datumová např. 1_měsíc a jiná typu number. Tak to zase tak s 2. podmínkou není úplně v pořádku. Později si vysvětlíme proč.

3. Žádné dva řádky nemohou obsahovat stejné hodnoty. OK splněno i když tabulce je to v tomto případě jedno, ale nám by nemnělo. Výběr dat v relační datbáze je pomocí řádku a položme si otázku. Jak bychom zde vybrali 2. řádek pomocí SQL dotazu?

4. Každý sloupec musí obsahovat jednu hodnotu. OK splněno. Do opravdy ? Např 2. řádek tabulky je jaké kategorie ? Excelovské myšlení nám říká přece Kategorie A, ale relační databázové myšlení nám říká null. Kdybych vybrali data pomocí SQL příkazu, tak hodnota by byla null.

Řekneme si tak co, splněno. Ano máme pravdu splněno z pohledu syntaxe. Ale z pohledu sémantiku ne. Jak bychom například spočetli průměrnou hodnotu ? No museli bychom spočítat průměrnou hodnotu za jednotlivé měsíce a ty pak zprůměrovat.  Zbytečně složité i když proveditelné. Jednoduše je to možné upravit datovou strutktúru tak, aby odpovídala sématice 1. NF.

Zkusme se ji zformulovat :

Sématická pravidla 1. normální formy

1. Každá tabulka musí obsahovat jedinečný primární klíč, pomocí kterého se dají identifikovat a měnit popisná data daného konkrétního řádku tabulky.

2. Každý řádek tabulky musí obsahovat izolovaná data tak, aby byla nezávislá oproti jiným řádkům tabulky.

3. Sloupce musí být redukovány tak, aby obsahovala sématicky (významově) stejná data aniž by se narušila jejich jedinečnost v rámci tabulky.

4. Každý sloupec musí obsahovat sémanticky jeden druh dat.

V praxi to znamená, že zavedeme primární klíč tabulky. V tomto případě abstraktní id.

Pak kategorii všude doplníme v každém řádku tabulky.

Sloučime sloupce 1_mesic,2_mesic,3_mesic do sloupce datum a hodnota, hodnota2, hodnota3 do sloupce hodnota. Zvětší se nám sice počet řádků, ale zmenší se šířka tabulky.

Výslední podoba tabulky bude :

Nebo kdyby Jste si nepamatovali to hroznou sématickou definici, vzpomente si na tento příklad.

Dodatek EAV tabulky

EAV tabulky (entita – atribut – hodnota) nejsou taky v 1. NF. Protože nesplňují 4. pravidlo , že jeden sloupec obsahuje jednu kategorii dat a syntaktické pravidlo,každý sloupec má jeden datový typ.

(V budoucnu přidám příklad)

Dodatek JSON a XML a obecně kompositní datové typy

Podle mně taky nejsou v 1.NF, protože nedodržují minimálně pravidlo atomičnosti. V PostgreSQL se to obchází pomocí funkcí, pomocí kterých je možné separovat data a vracet je do atomické podoby v 1.NF.

A co datový typ datum. Hm. Posudte samy … :)