Teoretické aspekty návrhu databází, normální formy relací

Teoretické aspekty návrhu databází, normální formy relací

Normální formy jsou sice pro mnohé vývojáře a databázisty strašákem, nicméně jejich znalost patří k základním databázovým dovednostem.

V souvislosti s návrhem relačního databázového systému se velmi často mluví o tzv. normálních formách. Základním smyslem těchto norem je co nejvíce omezit případné redundance dat v tabulkách a co nejvíce zefektivnit další možné dotazy do tabulek. Normální formy jsou vlastně souhrnem postupně se zpřísňujících pravidel. V souvislosti s touto nepřímou chválou na normální formy je nutno říci, že dodržování byť nejtvrdších norem pro tabulky náš systém neudělá automaticky vysoce efektivní a funkční. Pouze je to pak mnohem pravděpodobnější než bez dodržování zavedených pravidel a norem.

Normální formy si můžeme rozdělit do dvou skupin. První skupinu tvoří první tři normální formy, které byly součástí Coddovy formulace relační teorie. Ve většině případů si s těmito normami plně vystačíme. Druhou skupinu pak tvoří normální forma Boyce/Coddova a čtvrtá a pátá forma. Slouží pro speciální případy, Boyce/Coddova forma je také někdy pokládána za variaci třetí normální formy.

Tabulka je v nulté normální formě 0NF právě tehdy, když existuje alespoň jedno pole, které obsahuje více než jednu hodnotu. Pokud tabulka není v nulté normální formě, pak je alespoň v první normální formě – 1NF.

Chceme-li uvést myšlenku první normální formy tabulek do matematické řeči, řekli bychom, že musí být každý atribut definován nad skalárním oborem hodnot. Poměrně jednoduché pravidlo, ale v mnoha případech diskutovatelné. Už jsme jednou narazili na problém 'správného' zápisu jména do tabulky (jméno = křestní nebo jméno = křestní + příjmení, jméno = příjmení). Podobně bychom mohli diskutovat správný zápis datumu do tabulky. Datum se skládá ze tří částí – den + měsíc + rok. Měli bychom tedy vytvořit tři samostatné atributy pro zápis úplného datumu nebo ignorovat části a brát ho jako nedělitelný atribut? V praxi bychom u obou případů zhodnotili, jakým způsobem bude systém manipulovat s těmito hodnotami. Zavedeme je potom tak, aby tvar atributu odpovídal nejčastějšímu použití.

Příklad tabulky v nulté normální formě

Výše uvedená tabulka je pouze v nulté normální formě, neboť obsahuje sloupce s více druhy údajů. Tabulku je potřeba rozložit tak, aby splňovala podmínky pro první normální formu.

Příklad tabulky v první normální formě

Tabulka v nulté normální formě neumožňuje klást efektivní dotazy na její obsah. Naproti tomu je-li tabulka alespoň v první normální formě, je možné klást efektivní dotazy na data v ní obsažená. Máme-li nyní tabulku v první normální formě, pak se budeme snažit zvýšit její normu především pro lepší možnost aktualizace dat v tabulce.

Pro každou tabulku musí existovat určitá kombinace atributů, která jednoznačně identifikuje jednotlivé záznamy v tabulce. V databázových systémech se při popisu tabulek nevyhneme zavedení pojmu jednoduchého a složeného klíče. Klíč nám slouží k rychlému určení toho správného a konkrétního řádku příslušné tabulky.

Jako možný klíč by nás pravděpodobně nejjednodušeji napadla kombinace všech atributů tabulky, ale musí být splněna ještě jedna podmínka – jakákoli podmnožina množiny atributů klíče už nevyjadřuje jednoznačnou identifikaci (co když je 2 lidé jmenují úplně stejně?). Při výběru atributů pro primární klíč je nutné také posuzovat efektivitu z časového a paměťového hlediska. Pokud je použitelný klíč tabulky příliš obsáhlý počtem polí nutných pro jednoznačnou identifikaci záznamů, je možné jako primární klíč tabulky použít speciální datový typ, který vytvoří klíč s jednoznačnými hodnotami.

Jednoduchý klíč – sloupec tabulky, který obsahuje vzájemně různé, neprázdné hodnoty. Např. číslo.

Složený klíč – skupina sloupců tabulky, které obsahují vzájemně různé kombinace hodnot.

Má-li tabulka jednoduchý nebo složený klíč, pak rozlišujeme její sloupce podle toho, zda jsou nebo nejsou součástí tohoto klíče. Je-li sloupec součástí klíče, pak hovoříme o klíčovém sloupci. Není-li sloupec součástí klíče, hovoříme o neklíčovém sloupci. Při převodu tabulky do vyšších normálních forem se zabýváme jednotlivými klíčovými a neklíčovými sloupci tabulky a jejich závislostmi.

Tabulka je ve druhé normální formě – 2NF, jestliže je v první normální formě, zároveň existuje klíč a současně všechna neklíčová pole jsou funkcí celého klíče, a nikoli jen jeho části.

Příklad tabulky ve druhé normální formě

Primární klíč této tabulky je tvořen sloupci Produkt a Dodavatel. Uvážíme-li nyní neklíčový sloupec TelDodavatele, tak zjistíme, že závisí pouze na části primárního klíče – Dodavatel. Tabulka tak v této podobě druhé normální formy nedosáhne. Jedná se v podstatě o problém, že se pokoušíme v jedné tabulce vyjádřit dvě různé entity – Produkt a Dodavatel. Takový model povede k redundancím
a následným problémům při údržbě systému. Zde lze problém řešit jednoduchým oddělením obou entit do samostatných tabulek.

Tabulka Produkt

Tabulka Dodavatel

Tabulka je ve třetí normální formě – 3NF, je-li ve druhé normální formě a zároveň neexistují závislosti neklíčových sloupců tabulky.

Představíme-li si existenci dvou neklíčových sloupců PSC a Město nějaké tabulky, tak je v souvislosti s třetí normou diskutovatelný právě sloupec PSC. Teoreticky můžeme odvozovat PSC ze znalosti města a dalšího připojeného číselníku zajišťujícího převod pro tyto hodnoty. Otázkou je, zda bude vůbec výhodné, komplikovat si touto úpravou život. Mohlo by to vést ke složitým a nepřehledným tabulkám, popř. i ke ztrátě výkonu. Víme-li, že budou v tabulce pouhé desítky záznamů, stěží bude výhodné mít zavedenou v databázi tabulku, která zajišťuje zvlášť evidenci několika tisíc směrovacích čísel měst a obcí.

Tyto příklady se snaží upravit zadaný problém do 3NF, tedy navrhnout tabulky tak, aby žádný sloupec libovolné tabulky neměl vztah k jinému sloupci stejné tabulky. Tedy jde o to, aby se v jedné tabulce nevyskytovaly údaje, které spolu souvisí (např. město vs. PSČ) a tím se snížil počet dat zabírající jeden řádek. Může se to zdát zbytečné, ale máte-li seznam občanů ČR, tedy cca 10 milionů řádků, může se například nahrazením názvu kraje bydliště za kód kraje (je jich 14) ušetřit cca 200MB dat v databázi. To samé platí pro okresy atd…

PACIENTI(rodné-č, jméno, příjmení, diagnóza, den-nástupu, č-oddělení, název-oddělení)

pacient(id-pacient, rodné-č, jméno, příjmení)

oddělení(č-oddělení, název-oddělení)

ošetření(id-pacient, č-oddělení, datum-nástupu, diagnóza)

BYDLIŠTĚ(rodné-č, jméno, příjmení, místo, ulice, ČP, PSČ, městská-čtvrt, okres, kraj)

obyvatel(id-obyvatel, rodné-č, jméno, příjmení, kód-bydliště)

bydliště(kód-bydliště, kód-ulice, ČP, PSČ)

* rozsekání na číselníky, umožňuje hledat závislé ulice, města, čtvrti atd..

ulice(kód-ulice, ulice, kód-čtvrti)

čtvrť(kód-čtvrti, městská-čtvrt, kód-města)

psč(PSČ,kód-města)

město(kód-města, město, kód-okresu)

okres(kód-okresu, okres, kód-kraje)

kraj(kód-kraje, kraj)

TRESTNÍ REJSTŘÍK(rodné-č, jméno, příjmení, trestný-čin, paragraf, sazba-od, sazba-do, výše-trestu, nápravná-skupina)

pachatel(id-pachatel, rodné-č, jméno, příjmení)

trestný_čin(id-trestný-čin, trestný-čin, paragraf, sazba-od, sazba-do)

nápravná(id-nápravná-skupina, nápravná-skupina)

trest(id-pachatel, id-trestný-čin, výše-trestu, id-nápravná-skupina)

AUTA(SPZ, typ, barva, obsah-válců, rok-výroby, prodejní-cena, dovezené, rodné-č-majitele, jméno, příjmení)

majitel(id-majitel, rodné-č-majitele, jméno, příjmení)

typ(id-typ, typ)

barva(id-barva, barva)

auto(id-auto, id-typ, id-barva, obsah-válců, prodejní cena, dovezené)

registr (SPZ, id-auto, id-majitel)