Normalizace databáze je v informatice označení postupu, kdy je struktura dat v relační databázi přeorganizována tak, aby využívala výhody relačního modelu dat. Normalizace databáze umožňuje data efektivněji ukládat, prohledávat, třídit i zpracovávat. Při normalizaci jsou v databázi měněny atributy (sloupce) jednotlivých tabulek a zaváděny mezi nimi výhodné vztahy, je omezována redundance uložených dat (vět) a je brán ohled na řešení problému s případnou nekonzistencí dat.
Autorem termínu normalizace databáze je britsko-americký matematik a informatik Edgar. F. Codd.
Charakteristika V relačním modelu jsou data uložena v tabulkách, na které má jisté požadavky. Při splnění požadavků je tabulka označována jako normalizovaná. Pokud nejsou tyto požadavky splněny, jsou označovány jako nenormalizované a proces jejich převodu na tabulky se označuje jako normalizace. Při tomto procesu dochází k odstraňování nedostatků tabulek jako je redundance nebo možnost vzniku aktualizační anomálie, tj. nechtěného vedlejšího efektu operace nad databází, při kterém dojde ke ztrátě nebo nekonzistenci dat. Postup normalizace je rozdělen do několika kroků a po dokončení každého z nich se tabulka nachází v určité normální formě. V praxi se většinou normalizuje do třetí normální formy, vyšší normální formy je vcelku obtížné porušit a vyžadují relativně velké znalosti, stejně jako návrh databází takové velikosti, kde je možné je porušit.
Normální formy Přestože existuje řada normálních forem, v praxi se za normalizovanou databázi považuje taková, která splňuje alespoň první tři normální formy. Předmětem zkoumání prvních čtyř forem (1NF, 2NF, 3NF, BCNF) je vztah neklíčových atributů na primárním klíči, předmětem zkoumání posledních dvou normálních forem (4NF, 5NF) jsou vztahy uvnitř složených primárních klíčů. Důležité také je, že každá z normálních forem obsahuje a vyžaduje splnění všech pravidel obsažených ve formách předchozích.
UNF: Nenormalizovaná databáze 0NF: Alespoň jeden atribut obsahuje více než jednu hodnotu. 1NF: Každý atribut obsahuje pouze atomické hodnoty. 2NF: Každý neklíčový atribut je plně závislý na každém kandidátním klíči. (Neklíčovým atributem rozumíme atribut, který není součástí žádného kandidátního klíče.) 3NF: Všechny neklíčové atributy musí být vzájemně nezávislé. BCNF: Atributy, které jsou součástí primárního klíče, musí být vzájemně nezávislé. 4NF: Relace popisuje pouze příčinnou souvislost mezi klíčem a atributy. 5NF: Relaci již není možno bezeztrátově rozložit.
Historie normálních forem První normální forma byla představena v konferenčním příspěvku z roku 1970 publikovaného E. F. CoddemCODD, E. F., (1970). A Relational Model of Data for Large Shared Data Banks, Communications of the ACM. 13 (6): 377–387. doi:10.1145/362384.362685, [citováno: 11. 6. 2018] (v angličtině) Codd pokračoval v definici druhé a třetí normální formy v roce 1971CODD, E. F., (1971). Further Normalization of the Data Base Relational Model, Courant Computer Science Symposia Series 6, "Data Base Systems", New York City, IBM Research Report RJ909, [citováno: 11. 6. 2018] (v angličtině) V roce 1974 E. F. Codd společně s Raymondem F. Boyce definovali Boyceho-Coddovu normální formuCODD, E. F., (1974). Recent Investigations into Relational Data Base Systems, IBM Research Report RJ1385, [citováno: 11. 6. 2018] (v angličtině) Čtvrtou normální formu představil v roce 1977 Ronald FaginFAGIN, R. (1977). Multivalued dependencies and a new normal form for relational databases, ACM Transactions on Database Systems (TODS), str. 262-278, [citováno: 11. 6. 2018] (v angličtině) R. Fagin rozšířil normální formy o definici páté normální formy svým konferenčním příspěvkem v roce 1979KRISHNA, S., (1991). Introduction to Database and Knowledge-Base Systems, . str. 65, [citováno: 11. 6. 2018] (v angličtině)
Pro splnění určité normální formy je nutné splnit i ty předchozí. V praxi se obvykle používají pouze první tři.
Nenormalizovaná forma (UNF) Nenormalizovaná forma (z anglického Unnormalized Form) byla pojmenována v roce 1970 E. F. Coddem a představuje formu jakékoliv tabulky, která je v nenormalizovaném stavu, tj. tabulky, na níž dosud nebyly aplikovány žádné normální formy. V literatuře se často nenormalizovaná forma neuvádí, především proto, že její splnění je v podstatě automatické a vypovídající hodnota této kategorizace je zanedbatelná. Je důležité poznamenat, že tabulka v nenormalizované formě nutně nemusí porušovat některé z dalších normálních forem – to je však předmětem aplikace a šetření spojeného s následujícími normálními formami.
Nultá normální forma (0NF) Nultá normální forma bývá obdobně jako nenormalizovaná forma zřídka v literatuře zmiňována. V některých případech je uváděna jako součást první normální formy. Obvykle není zvažována, jelikož její splnění bývá v praxi automaticky zaručeno. Přesto lze nalézt následující definici: Schéma relace je v nulté normální formě právě tehdy, když existuje alespoň jeden atribut, který obsahuje více než jednu hodnotuZÁDOVÁ, V., Relační datový model, Technická Univerzita v Liberci, Katedra informatiky, Ekonomická fakulta, [citováno: 10. 6. 2018]
První normální forma (1NF) Pro splnění první normální formy je zapotřebí zajistit následující: splnění nulté normální formy (0NF) všechny atributy tabulky musí být atomické, tedy dále nedělitelné
Příklad 1 Klasickým příkladem tabulky porušující první normální formu bývá nejčastěji problém s telefonními čísly, kdy naším cílem je umožnit evidovat pro každou osobu dvě různá telefonní čísla, jak lze vidět v tabulce níže: Poznámka: U všech příkladů níže platí pravidlo, že podtržené názvy atributů představují primární klíč.
Tabulka Osoba ID Osoby Jméno Telefonní číslo 1 Petr Novák +420 111 222 333 2 Jarmil Hnízdo +420 123 123 123, +420 123 123 124
Tato tabulka ovšem porušuje první normální formu, jelikož sloupec (atribut) telefonní číslo není atomický. Zjevným řešením této situace by mohlo být přidání druhého sloupce pro telefonní číslo, abychom zajistili splnění pravidla atomických atributů:
Tabulka Osoba ID Osoby Jméno Telefonní číslo 1 Telefonní číslo 2 1 Petr Novák +420 111 222 333 2 Jarmil Hnízdo +420 123 123 123 +420 123 123 124
Přestože je tato tabulka formálně správná a již neporušuje pravidlo první normální formy, její návrh je stále problematický. Problém nastane zejména v případě, že bude zapotřebí evidovat čísel více. Rozšiřování tabulky o další sloupce telefonních čísel není často realizovatelné a také se označuje za špatný návrh. Správným řešením je vytvoření nové tabulky a odstranění sloupce telefonních čísel z tabulky osob, jak lze vidět na příkladu níže:
Tabulka Osoba ID Osoby Jméno 1 Petr Novák 2 Jarmil Hnízdo
Tabulka Kontakt ID Kontaktu ID Osoby Telefonní číslo 1 1 +420 111 222 333 2 2 +420 123 123 123 3 2 +420 123 123 124
V tomto případě je tedy první normální forma splněna a rozdělením tabulek jsme umožnili bezproblémové přidávání libovolného počtu telefonních čísel pro každou osobu. Všimněme si, že tabulka s kontakty obsahuje navíc kromě primárního klíče také cizí klíč, který nám zajišťuje svázání telefonního čísla se správnou osobou.
Druhá normální forma (2NF) Pravidla definovaná druhou normální formou lze shrnout na následující: tabulka musí být v první normální formě (1NF) každý neklíčový atribut musí být plně závislý na každém kandidátním klíči (neklíčovým atributem rozumíme atribut, který není součástí žádného kandidátního klíče) Druhá normální forma klade důraz především na odstranění možných duplicit v záznamech.
Příklad 2 Uveďme si příklad, kdy máme tabulku evidující následující informace o kurzech. Všimněme si především toho, že tabulka má složený primární klíč {ID Kurzu, ID Semestru}:
Tabulka Záznam SMASHERY (2013) What are database normal forms and can you give examples? [online], stackoverflow.com, [aktualizováno: 31. 5. 2013], [citováno: 10. 6. 2018] (v angličtině) ID Kurzu ID Semestru Počet míst Jméno kurzu IT101 ls 2017 100 Programování IT101 zs 2017 100 Programování IT102 ls 2017 200 Databáze IT102 zs 2017 150 Databáze IT103 zs 2017 120 Web design
Tato tabulka porušuje druhou normální formu, jelikož sloupec Jméno kurzu není plně závislý na celém primárním klíči. Jméno kurzu je závislé na sloupci ID Kurzu, ovšem není již závislé na sloupci ID Semestru. V takovéto tabulce navíc dochází k redundanci dat, jak lze vidět na opakujících se jménech každého kurzu. Při vypisování již existujících kurzů v budoucnu (v nových semestrech) by docházelo k neustálému opakování těchto záznamů.
Způsob, jakým lze tento problém vyřešit je dekompozice tabulky a zajištění, že všechny neklíčové atributy dané tabulky budou závislé na celém klíči. Možným řešením může být například následující rozdělení tabulky:
Tabulka Záznam ID Kurzu ID Semestru Počet míst IT101 ls 2017 100 IT101 zs 2017 100 IT102 ls 2017 200 IT102 zs 2017 150 IT103 zs 2017 120
Tabulka Kurz ID Kurzu Jméno kurzu IT101 Programování IT102 Databáze IT103 Web design
Výše uvedená dekompozice tabulky zajišťuje splnění druhé normální formy. Jediný neklíčový atribut v původní tabulce – Počet míst je již závislý na celém složeném primárním klíči, obdobně jako jediný neklíčový atribut Jméno kurzu v tabulce Kurz, který je již závislý na jediném primárním klíči nově vytvořené tabulky.
Třetí normální forma (3NF) Třetí normální forma klade následující podmínky: tabulka je ve druhé normální formě (2NF) neobsahuje tranzitivní závislostiCHLAPEK, D., (2015). Normalizace dat - souhrnný příklad, Vysoká škola ekonomická v Praze, Fakulta informatiky a statistiky, Katedra informačních technologií, str. 7-10, [citováno: 10. 6. 2018]
Funkční závislost v databázích chápeme jako vztah mezi atributy, kdy tvrzení, že atribut Y je funkčně závislý na atributu X značíme jako:
Tato závislost zajišťuje, že dva řádky mající stejnou hodnotu atributu X budou mít vždy stejnou hodnotu atributu Y. Tranzitivní závislost pak chápeme jako vztah mezi třemi atributy (např. X, Y, Z), kdy atribut Y je funkčně závislý na atributu X, atribut Z je funkčně závislý na atributu Y, a proto lze implikovat, že atribut Z je také funkčně závislý na atributu X. Tento vztah značíme jako:
pokud ŽOLTÁ, L., Funkční závislosti [online], lucie.zolta.cz, [citováno: 11. 6. 2018]
Příklad 3 Nejlépe však tuto normální formu lze pochopit na vypovídajícím příkladu. Mějme následující tabulku evidující jednotlivé filmy, jejich žánry a délku jejich stopáže:
Tabulka Film ID Filmu ID Žánru Název žánru Délka filmu 1 3 Dokumentární 01:20:00 2 2 Akční 01:05:00 3 1 Komedie 01:50:00 4 2 Akční 01:10:00 5 3 Dokumentární 01:11:00
Na první pohled není s tabulkou nic v nepořádku. Tabulka splňuje druhou normální formu, všechny neklíčové atributy jsou závislé na celém primárním klíči (tedy v tomto případě na atributu ID Filmu). Přesto tato tabulka nesplňuje pravidla určená třetí normální formou. V tabulce výše vidíme, že primární klíč identifikující každý film rozhoduje o tom, jaký žánr bude zvolen, tedy jinými slovy atribut ID Žánru je funkčně závislý na atributu ID Filmu (ID Filmu → ID Žánru). Další závislost, kterou můžeme identifikovat je vztah identifikačního čísla žánru a názvu daného žánru, jinými slovy atribut Název žánru je funkčně závislý na atributu ID žánru (ID Žánru → Název žánru). Jak již z definice tranzitivní závislosti víme, z těchto dvou vztahů plyne i vztah třetí, určující funkční závislost atributu Název žánru na primárním klíči ID Filmu.
Způsob, jakým lze třetí normální formu uspokojit je dekompozice tabulky, díky čemuž dosáhneme odstranění nalezené tranzitivní závislosti. Pro příklad výše by dekompozice vypadala následovně:
Tabulka Film ID Filmu ID Žánru Délka filmu 1 3 01:20:00 2 2 01:05:00 3 1 01:50:00 4 2 01:10:00 5 3 01:11:00
Tabulka Žánr ID Žánru Název žánru 1 Komedie 2 Akční 3 Dokumentární