Normalizace je metoda, pomocí níž se upravuje prvotní hrubá nenormalizovaná struktura databáze na strukturu tzv. normalizovanou, která je vyčištěna od formálních chyb a nedostatků. Normalizace fakticky znamená rozdělení atributů do normalizovaných entit. Na jejím konci leží správně navržená databáze. Cílem normalizace, řečeno velice jednoduše, je splnění základního požadavku jeden fakt na jednom místě.

Podle relačního modelu dat musí databáze splňovat následující vlastnosti:

Dr. Codd definoval dalších dvanáct pravidel pro relační databáze:

Pro praktické účely nám postačí, když všechny entity našeho návrhu budou ve formě BCNF (Boyce-Codd Normal Form). Formy 1, 2, 3 nemají sami o sobě prakticky význam, nicméně přes ně vede cesta ke kýžené BCNF.

Pojem, se kterým se setkáváme v průběhu normalizace, je tzv. normální forma. Existuje několik normálních forem. Mluvíme o první, druhé a třetí normální formě, o formě BCNF, případně o čtvrté a páté normální formě.

Z předešlého již víme, co je to primární klíč (PK). Každá entita musí mít primární klíč a volba PK je první a nezbytný krok v procesu návrhu databáze. Primární klíč je složen z jednoho nebo více atributů a má tyto dvě vlastnosti:

Databáze je v první normální formě, pokud jsou všechny atributy dále nedělitelné (neboli atomické) a pokud databáze neobsahuje opakující se skupiny atributů.

Podívejme se na tabulku níže. Tato tabulka vykazuje na první pohled problémy – vyhledávání, změna dat – a to v každém sloupci.

Tato tabulka nemá primární klíč, který by jednoznačně identifikoval každý řádek, a atributy nejsou atomické. Musíme tedy přidat atribut obsahující primární klíč a jednotlivé atributy v tabulce rozdělit.

Tato tabulka již obsahuje primární klíč a všechny položky jsou atomické. Můžeme tedy říci, že je v první normální formě.

Databáze je ve druhé normální formě, pokud je v první normální formě a pokud žádný neklíčový atribut není závislý pouze na části klíče. Jinými slovy to znamená, že pokud chceme znát hodnotu nějakého atributu, neměla by stačit pouze znalost části klíče daného záznamu. Tento problém automaticky odpadá v případě, že má entita pouze jednoduchý klíč. V tom případě je databáze ve druhé normální formě ihned, jakmile je v první normální formě.

V následujícím příkladu (tabulka níže) je vidět, že se tabulka nachází v první normální formě – má primární klíč a atributy jsou atomické. Problém ovšem je, že primární klíč tvoří kombinace atributů.

Primární klíč této tabulky tvoří kombinace sloupců Nazev_vyrobku a Vyrobce. Touto kombinací lze v tabulce identifikovat každý řádek. Bohužel pro identifikaci nestačí pouze jeden sloupec – jak je patrné z tabulky. Problém nastává se sloupcem Vyrobce_mesto, který není závislý na celém primárním klíči – je závislý pouze na sloupci Vyrobce. To znamená, že nějaký neklíčový atribut je závislý pouze na části primárního klíče. Tabulka není ve druhé normální formě a je třeba provést dekompozici.

V tabulce Vyrobek se nachází primární a cizí klíč (ID_Vyrobce), v tabulce Vyrobce je primárním klíčem Vyrobce_ID.

Databáze je ve třetí normální formě, pokud je ve druhé normální formě a pokud žádný neklíčový atribut není závislý na jiném neklíčovém atributu. Jinými slovy, každý neklíčový atribut musí být závislý na klíči, neboli neexistuje tranzitivní závislost neklíčového atributu na klíči.

V přechozí tabulce vidíme sloupce, které jsou závislé na primárním klíči – tím je ID_Zamestnance. Ovšem nalezneme zde také sloupce, které jsou závislé na jiných sloupcích – vidíme závislost poštovního směrovacího čísla a města nebo že plat je závislý na vykonávané práci. Tabulka je tedy ve druhé normální formě, a abychom ji měli i ve třetí normální formě, je zapotřebí provést dekompozici. Z předchozího je zřejmé, že výsledkem budou tři tabulky (Zamestnanec, Mesto, Prac_pozice).

Relace se nachází v BCNF, jestliže pro každou netriviální závislost X -> Y platí, že X je nadmnožinou nějakého klíče schématu R. Nejsnáze Boyce/Coddovu normální formu pochopíme s pomocí funkčních závislostí. Boyce/Coddova normální forma v podstatě říká, že mezi kandidátními klíči nesmí být žádná funkční závislost. Uveďme si příklad s adresami.

Kromě toho, že v této tabulce nevidíme na první pohled primární klíč, najdeme zde i dvě závislosti. Jednou závislostí je již zmíněná závislost PSČ na městu a druhou závislostí je závislost atributů Město a Ulice_nazev na poštovním směrovacím čísle. Kombinace sloupců Ulice_nazev a PSC tvoří kandidátní klíč.

Tabulka je tedy ve třetí normální formě, ale není v BCNF. Řešením tohoto problému je tedy dekompozice tabulky. Vzniknou dvě tabulky – tabulka Mesta s atributy PSC a Mesto a tabulka Ulice s atributy PSC a Ulice_nazev.