AD Blog

Při návrhu databázové struktury se osvědčily některé postupy, které nám ušetří spoustu následných problémů při provozování databáze v reálu. Jedním z vřele doporučovaných postupů je normalizace.

Struktura a data v databázi tvoří vlastně obrázek výseku reality, kterým se snažíme tuto realitu co nejlépe popsat. Prvním krokem je tedy shromáždění všech dostupných informací o datech – říkejme jim atributy, které realitu popisují. Tím vznikne katalog atributů, které můžeme transformovat jako sloupce jediné tabulky v databázi. Když to takto uděláme, dostaneme tabulku s mnoha sloupci, ve kterých se budou některé údaje často opakovat. Při práci s tabulkou zjistíme, že:

• vznikají chyby při zápisu (stejná hodnota atributu je, vlivem lidských fluktulací, zapsána často s drobnými odlišnostmi),
• práce s tabulkou je obtížná, je to velké, pomalé vlivem chyb v zápisech jsou výsledky dotazů nepřesné a zkreslené,
• množství nutných indexů v tabulce místo aby práci zrychlovalo ji „de facto“ zpomaluje.

Máme tedy tabulku s atributy, bylo by vhodné do ní zavést pořádek. Toho dosáhneme definicí primárního klíče (key). Primární klíč je sloupec, nebo několik sloupců jednpznačně identifikující záznam (řádek) tabulky.

Například v adresáři to může být jméno+příjmení­+obec+ulice+čís­lo popisné+číslo bytu. No, to tedy moc prakticky nevypadá, že? Možná někoho napadne přidat další sloupec s číselným identifikátorem. Bing ho! Většina databází má zabudouvanou funkci autoinkrement, která umí automaticky, při uložení nového záznamu vygenerovat jedinečné číslo. A toto číslo může být v tabulce primárním klíčem. Který, navíc, uživatel našeho systému nemusí vůbec vidět.

Co ale naše veliká, jediná tabulka? Přidali jsme sice pole s identifikátorem, ale ostatní nectnosti jsme nevyřešily. Řekněme, že naše databáze se nachází v nulté normální formě. Jak přejít k prvé, druhé a třetí normální formě? Jednoduše řečeno procesem normalizace:

První normální forma

Eliminace periodických vstupů

Jde o vyhledání opakujících se atributů a jejich umístění do další tabulek, někdy také nazzváných číselníky. A nebo vytvoření tabulek s vazbou k základní tabulce 1:N (jedna ku mnoha). Vezměme teda náš adresář, upravme ho na adresář pracovníků nějaké firmy a podívejme co by se dalo přemístit do dalších tabulek.

Máme následující datovou strukturu:

tabulka adresare

ID
jmeno
prijmeni
cislo_bytu
cislo_popisne
ulice
obec
kraj
stat
telefon
telefon_1 (telefon na vedoucího)
odd_1 (název oddělení ve kterém pracoval)
start_1 (odkdy pracuje)
odd_2 (název druhého oddělení ve kterém pracoval)
start_2 (odkdy pracuje)

Téměř jistě můžeme do číselníku vyčlenit stat a kraj. U obec už musíme uvážit, zda vzniknuvší číselník nebude obsahovat příliš mnoho záznamů a nebude pro uživatele nepřehledný. Také potřebujeme zajistit vztahy mezi tabulkou adresáře a číselníky. Toho dosahujeme pomocí cizího klíče umístěného v tabulce adresare. Cizí klíče označuji konvencí nazev_tabulkyID. Pole odd+start máme v tabulce uvedno 2×, co si však počneme, když pracovník přejde do třetího oddělení? Vyčleníme tedy tyto atributy do tabulky oddeleni s vazbou 1:N na tabulku adresar a pracovník může fluktulovat jak chce. Výsledek našeho snažení bude vypadat nějak takhle:

tabulka adresare

ID
jmeno
prijmeni
cislo_bytu
cislo_popisne
ulice
obec
krajID
statID
telefon
telefon_1 (telefon na vedoucího)
oddID

tabulka oddeleni
ID
odd (název oddělení ve kterém pracoval)
start (odkdy pracuje)

tabulka (číselník) kraj

ID
kraj

tabulka (číselník) stat
ID
stat

Vazbu mezi ID a cizími klíči můžeme realizovat například pomocí SQL left Join, nebo a lépe, pomocí nastavení relačních vztahů přímo v databázi.

Druhá normální forma

Eliminace nadbytečných dat

Druhou normální formu podmiňuje existence databáze v první normální formě.

Tabulka oddeleni je taková zvláštní, není to číselník, je to tabulka ve které je obsažena historie pracovníka. A vidíme, že pole odd se nám opakuje. Vyčleňme ho do další tabulky!

tabulka adresare

ID
jmeno
prijmeni
cislo_bytu
cislo_popisne
ulice
obec
krajID
statID
telefon
telefon_1 (telefon na vedoucího)
oddID

tabulka oddeleni
ID
oddID
start (odkdy pracuje)

tabulka odd_nazev
ID
odd (název oddělení ve kterém pracoval)

tabulka (číselník) kraj

ID
kraj

tabulka (číselník) stat
ID
stat

Třetí normální forma

Odstranění nezávislých polí

Třetí normální formu podmiňuje existence databáze v druhé normální formě.

V tomto kroku odstraníme pole, které se jeví jako nezávislé a to buď úplným vymazáním , nebo přeložením do jiné tabulky.

Horkým kandidátem je pole telefon_1 (telefon na vedoucího).

Existuje pěkné a jednoduché pravidlo pro objevení takovéhoto pole: Pokud potřebujete pro popis pole dva přívlastky (telefon vedoucího zaměstnance)nepatří toto pole do tabulky

No dobře, co ale s tím. Je možné, že jsme již v první kroku (při zjišťování potřebných atributů) udělali chybu a telefon na vedoucího není potřeba. V tomto případě ho z tabulky adresar vyhodíme. A nebo je tato vazba skutečně potřeba a musíme ji zohlednit v datovém modelu přidáním tabulky vedouci, kde příslušné vztahy popíšeme.

Pro jednoduchost jsme se rozhodl pro první případ a a atribut telefon_1 jsem vyhodil úplně. Výsledkem je databáze v kýžené třetí normální formě:

tabulka adresare

ID
jmeno
prijmeni
cislo_bytu
cislo_popisne
ulice
obec
krajID
statID
telefon
oddID

tabulka oddeleni
ID
oddID
start (odkdy pracuje)

tabulka odd_nazev
ID
odd (název oddělení ve kterém pracoval)

tabulka (číselník) kraj

ID
kraj

tabulka (číselník) stat
ID
stat

Dobrým vodítkem mi při psaní tohoto spotu byla kniha „Síťové programování ve FoxPro“ autorů Josepha D. Bootha a Grega Liefa.

Výborným pomocníkem při datovém modelování je český nástroj Case Studio 2