'''Normalizace databáze''' je v [[Informatika|informatice]] označení procesu zodpovědného za transformaci [[Relační databáze|relační databáze]] tak, aby splňovala sadu podmínek – tzv. [[#Normální formy|normálních forem]]. Cílem aplikace těchto podmínek je upravení databáze do vhodnějšího stavu, zamezení nekonzistencí, zvýšení integrity dat, odstranění duplicit (potažmo snížení redundance dat) a zamezení potenciálních problémů při manipulaci s daty v relační databázi. Autorem termínu normalizace databáze je britsko-americký matematik a informatik [[Edgar_Frank_Codd|Edgar. F. Codd]].

= 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. 

== 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. Coddem<ref>CODD, 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.</ref> 
*Codd pokračoval v definici druhé a třetí normální formy v roce 1971<ref>CODD, 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</ref> 
*V roce 1974 E. F. Codd společně s Raymondem F. Boyce definovali Boyceho-Coddovu normální formu<ref>CODD, E. F., (1974). ''Recent Investigations into Relational Data Base Systems'', IBM Research Report RJ1385</ref> 
*Čtvrtou normální formu představil v roce 1977 Ronald Fagin<ref>FAGIN, R. (1977). ''Multivalued dependencies and a new normal form for relational databases'', ACM Transactions on Database Systems (TODS), str. 262-278</ref> 
*R. Fagin rozšířil normální formy o definici páté normální formy svým konferenčním příspěvkem v roce 1979<ref>KRISHNA, S., (1991). ''Introduction to Database and Knowledge-Base Systems'', ISBN 9810206208. str. 65 </ref> 

== 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 hodnotu <ref>ZÁDOVÁ, V., ''Relační datový model'', Technická Univerzita v Liberci, Katedra informatiky, Ekonomická fakulta, [citováno: 10. 6. 2018] </ref> 

== 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 [[Atomicita|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íč|primární klíč]].

{| class="wikitable"
|+ align="top" | ''' 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ů:

{| class="wikitable"
|+ align="top" | ''' 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:

{| class="wikitable"
|+ align="top" | ''' Tabulka Osoba'''
!| ID Osoby
!| Jméno
|-
| 1 || Petr Novák
|-
| 2 || Jarmil Hnízdo
|-
|}

{| class="wikitable"
|+ align="top" | ''' 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íč|cízí 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í klíč|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}:

{| class="wikitable"
|+ align="top" | ''' Tabulka Záznam''' <ref>SMASHERY (2013) [https://stackoverflow.com/a/724032 ''What are database normal forms and can you give examples?''] [online], stackoverflow.com, [aktualizováno: 31. 5. 2013], [citováno: 10. 6. 2018] (anglicky)</ref>
!| 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:

{| class="wikitable"
|+ align="top" | ''' 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
|-
|}

{| class="wikitable"
|+ align="top" | ''' 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ávislosti <ref name=CHLAPEK>CHLAPEK, D., (2015). ''Normalizace dat - souhrnný příklad'', Vysoká škola ekonomická v Praze, Fakulta informatiky a statistiky, Katedra informačních technologií, str. 7-10.</ref>

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: 
*<math>X \rightarrow Y</math> 
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 <math>X \rightarrow Y \land Y \rightarrow Z \Rightarrow X \rightarrow Z</math><ref>ŽOLTÁ, L., [http://lucie.zolta.cz/index.php/iformacni-systemy-databaze/47-funkcni-zavislosti ''Funkční závislosti''] [online], lucie.zolta.cz, [citováno: 11. 06. 2018]</ref>

=== 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:

{| class="wikitable"
|+ align="top" | ''' 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ě:

{| class="wikitable"
|+ align="top" | ''' 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
|-
|}

{| class="wikitable"
|+ align="top" | ''' Tabulka Žánr'''
!| ID Žánru
!| Název žánru
|-
| 1 || Komedie
|-
| 2 || Akční
|-
| 3 || Dokumentární
|-
|}

Rozkladem původní tabulky nyní dostáváme dvě tabulky, které již neobsahují žádné tranzitivní závislosti. Navíc jsme díky naplnění třetí normální formy napomohli ke snížení redundance dat.

== Boyceho-Coddova normální forma (BCNF) ==
viz. článek [[Boyceho–Coddova_normální_forma|Boyceho–Coddova_normální_forma]]

== Čtvrtá normální forma (4NF) ==
'''Čtvrtá normální forma''' je dalším krokem po uplatnění Boyceho-Coddovy normální formy. Jak již bylo nastíněno v počátku, druhá, třetí a Boyceho-Coddova normální forma řeší funkční závislosti jednotlivých atributů, kdežto čtvrtá a pátá normální forma zkoumá vztahy složených primárních klíčů. Dle jedné z definic navíc od splnění všech předešlých normálních forem umožňuje rozlišení a oddělení nezávislých vícehodnotových atributů vytvářejících složený primární klíč. <ref name=CHLAPEK />

Požadavky pro splnění 4NF jsou tedy následující:
*relace je v BCNF
*pro každou netriviální vícehodnotovou závislost X ↠ Y je X superklíčem v dané relaci. (superklíč je jakékoliv uskupení atributů, které jednoznačně identifikuje záznam v tabulce)<ref>ŠÍPAL, Š., [http://vyuka.greendot.cz/materialy/material-37.ppt ''Databázové systémy''] [online], [citováno: 11. 6. 2018]</ref>

=== Příklad 4 ===
Ukažme si opět na příkladu, mějme následující tabulku evidující záznamy o prodejcích, prodávaných produktech a pobočkách, kde nabízejí své produkty:

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Produkt-Pobočka'''
!| Prodejce
!| Produkt
!| Pobočka
|-
| Prodejce 01 || Lyže || Praha
|-
| Prodejce 01 || Lyže || Liberec
|-
| Prodejce 01 || Lyže || Pardubice
|-
| Prodejce 01 || Lyžařské brýle || Praha
|-
| Prodejce 01 || Lyžařské brýle || Liberec
|-
| Prodejce 01 || Lyžařské brýle || Pardubice
|-
| Prodejce 02 || Lyže || Praha
|-
| Prodejce 02 || Lyže || Liberec
|-
| Prodejce 02 || Lyže || Pardubice
|-
| Prodejce 02 || Lyžařské brýle || Praha
|-
| Prodejce 02 || Lyžařské brýle || Liberec
|-
| Prodejce 02 || Lyžařské brýle || Pardubice
|-
| Prodejce 03 || Lyže || Pardubice
|-
|}

Stejně jako předchozí normální formy, i čtvrtá normální forma se snaží zamezit zbytečné redundanci dat. Množství záznamů v tabulce výše bylo zvoleno především proto, aby bylo možné ilustrovat, že i tato normální forma napomáhá ke snížení redundance dat.

Jelikož tabulka neobsahuje žádné neklíčové atributy (je tvořena pouze složeným primárním klíčem {Prodejce, Produkt, Pobočka}), máme zajištěné splnění všech předchozích normálních forem. Tato tabulka však nesplňuje pravidla určená čtvrtou normální formou. Vezmeme-li v úvahu, že všichni prodejci poskytují všechny své produkty na všech svých pobočkách (a proč by také neposkytovali), zjistíme, že složený klíč je bezpochyby tvořen z nezávislých dat, kdy produkt není vázán na určitou pobočku. Z toho důvodu je porušena čtvrtá normální forma a pro její splnění je zapotřebí provést dekompozici následující tabulky, která by vypadala následovně:

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Produkt'''
!| Prodejce
!| Produkt
|-
| Prodejce 01 || Lyže
|-
| Prodejce 01 || Lyžařské brýle
|-
| Prodejce 02 || Lyže
|-
| Prodejce 02 || Lyžařské brýle
|-
| Prodejce 03 || Lyžařské brýle
|-
|}

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Pobočka'''
!| Prodejce
!| Pobočka
|-
| Prodejce 01 || Praha
|-
| Prodejce 01 || Liberec
|-
| Prodejce 01 || Pardubice
|-
| Prodejce 02 || Praha
|-
| Prodejce 02 || Liberec
|-
| Prodejce 02 || Pardubice
|-
| Prodejce 03 || Pardubice
|-
|}

Po dekompozici tabulky již máme splnění čtvrté normální formy zajištěné.

== Pátá normální forma (5NF) ==
'''Pátá normální forma''' tkví ve splnění následujících:
*čtvrté normální formy (4NF)
*tabulku není možné dále bezeztrátově rozdělovat.
Ve všech předchozích normálních formách nedocházelo dekompozicí tabulek ke ztrátě dat <ref>SEKHAR, R., [https://www.quora.com/What-is-5NF-in-DBMS ''Fifth Normal Form (5NF)''] [online], Quora.com, [aktualizováno: 9. 3. 2017], [citováno: 10. 6. 2018] (anglicky)</ref>, ovšem upravíme-li příklad a situaci ze čtvrté normální formy, kdy prodejci již neposkytují všechny své produkty na každé své pobočce, ale pouze některé z nich, dojde při rozkladu ke ztrátě informací.

=== Příklad 5 ===
Mějme tedy následující upravenou tabulku z minulého příkladu:

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Produkt-Pobočka'''
!| Prodejce
!| Produkt
!| Pobočka
|-
| Prodejce 01 || Lyže || Praha
|-
| Prodejce 01 || Lyžařské brýle || Praha
|-
| Prodejce 01 || Rukavice || Pardubice
|-
| Prodejce 02 || Rukavice || Praha
|-
|}

Když se pokusíme o dekompozici tabulky, stejně jako při uspokojování čtvrté normální formy, dostaneme následující:

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Produkt'''
!| Prodejce
!| Produkt
|-
| Prodejce 01 || Lyže
|-
| Prodejce 01 || Lyžařské brýle
|-
| Prodejce 01 || Rukavice
|-
| Prodejce 02 || Rukavice
|-
|}

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Pobočka'''
!| Prodejce
!| Produkt
|-
| Prodejce 01 || Praha
|-
| Prodejce 01 || Pardubice
|-
| Prodejce 02 || Praha
|-
|}

Zajisté jsme dekompozicí pomohli snížit redundanci dat v naší databázi (která by byla zjevná především u rozsáhlých databází s velkým počtem záznamů), ovšem ve výsledku jsme ztratili důležité informace o závislosti prodejců – produktů – poboček. Při aplikaci některého z možných spojení tabulek, např. [[JOIN#Přirozené_spojování|přirozeného spojování]] (NATURAL JOIN) dostáváme následující výsledky:

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Produkt-Pobočka'''
!| Prodejce
!| Produkt
!| Pobočka
|-
| Prodejce 01 || Lyže || Praha
|-
| Prodejce 01 || Lyžařské brýle || Praha
|-
| Prodejce 01 || Rukavice || Praha
|-
| Prodejce 01 || Rukavice || Pardubice
|-
| Prodejce 01 || Lyžařské brýle || Pardubice
|-
| Prodejce 01 || Lyže || Pardubice
|-
| Prodejce 02 || Rukavice || Praha
|-
|}

Všimněme si, že dle obdržených výsledků vrácených spojením tabulek ''Prodejce-Produkt'' a ''Prodejce-Pobočka'' došlo k vytvoření tří nových záznamů, které tvrdí, že např. Prodejce 01 prodává lyžařské brýle v Pardubicích, což ovšem v porovnání s původní tabulkou víme, že není pravda.
Uvažujme tedy o dekompozici původní tabulky na tři tabulky oproti dvěma původním. Tedy kromě tabulek Prodejce-Produkt a Prodejce-Pobočka přidáme ještě tabulku Pobočka-Produkt evidující vztah mezi produkty a jejich dostupností na jednotlivých pobočkách. Mějme tedy navíc následující tabulku:

{| class="wikitable"
|+ align="top" | ''' Tabulka Pobočka-Produkt'''
!| Pobočka
!| Produkt
|-
| Praha || Lyže
|-
| Praha || Lyžařské brýle
|-
| Praha || Rukavice
|-
| Pardubice || Rukavice
|-
|}

Problém však nastává ve chvíli, kdy se pokusíme tyto tři tabulky spojit a dostat tak původní data. Po chvíli zkoušení zjistíme, že se nám takové spojení realizovat nepodaří a že není způsob, jak bychom dekompozicí původní tabulky mohli provést bezeztrátově. Tedy lze konstatovat, že tabulka Prodejce-Produkt-Pobočka již nelze dále bezeztrátově rozložit (je tedy v 5NF), a proto se musíme spokojit s redundancí dat původní tabulky pro zajištění, že nepřijdeme o žádná potenciálně důležitá data.

=== Příklad 6 ===
Víme už tedy o jaké tabulce můžeme konstatovat, že je v páté normální formě. Ukažme si ještě tabulku, která pátou normální formu porušuje. Upravíme-li záznamy původní tabulky a určíme-li, že se v Praze prodávají všechny produkty (lyže a lyžařské brýle), ale v Pardubicích pouze lyžařské brýle (důvod této diskriminace ponecháme záhadou), bude nová tabulka vypadat následovně:

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Produkt-Pobočka'''
!| Prodejce
!| Produkt
!| Pobočka
|-
| Prodejce 01 || Lyže || Praha
|-
| Prodejce 01 || Lyžařské brýle || Praha
|-
| Prodejce 01 || Lyžařské brýle || Pardubice
|-
| Prodejce 02 || Lyže || Praha
|-
| Prodejce 02 || Lyžařské brýle || Praha
|-
|}

Budeme-li postupovat stejně jako při pokusu o dekompozici bezeztrátově nerozdělitelné tabulky výše, dostaneme následující tři tabulky:

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Produkt'''
!| Prodejce
!| Produkt
|-
| Prodejce 01 || Lyže
|-
| Prodejce 01 || Lyžařské brýle
|-
| Prodejce 02 || Lyže
|-
| Prodejce 02 || Lyžařské brýle
|-
|}

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Pobočka'''
!| Prodejce
!| Produkt
|-
| Prodejce 01 || Praha
|-
| Prodejce 01 || Pardubice
|-
| Prodejce 02 || Praha
|-
|}

{| class="wikitable"
|+ align="top" | ''' Tabulka Pobočka-Produkt'''
!| Pobočka
!| Produkt
|-
| Praha || Lyže
|-
| Praha || Lyžařské brýle
|-
| Pardubice || Lyžařské brýle
|-
|}

Při pokusu o jejich opětovné spojení, zjistíme, že se nám v tomto případě podařila bezeztrátová dekompozice a výsledkem naší selekce je totožná tabulka s tabulkou před rozdělením. Po spojení těchto tabulek tedy získáváme:

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Produkt-Pobočka'''
!| Prodejce
!| Produkt
!| Pobočka
|-
| Prodejce 01 || Lyže || Praha
|-
| Prodejce 01 || Lyžařské brýle || Praha
|-
| Prodejce 01 || Lyžařské brýle || Pardubice
|-
| Prodejce 02 || Lyže || Praha
|-
| Prodejce 02 || Lyžařské brýle || Praha
|-
|}

Jelikož se nám podařilo opětovně spojit tři rozdělené tabulky a získat tak nezměněnou původní tabulku, lze konstatovat, že tabulka nesplňuje pravidla stanovená pátou normální formou. Srovnáme-li oba příklady této normální formy, zjistíme, že hlavním rozdílem bylo uvedení rozšiřujících informací, které nejsou ihned zjevné při pohledu na samotnou tabulku. Identifikování tabulek, které porušují pátou normální formu bývá v praxi velmi složité, a navíc reálný přínos její aplikace bývá často nezřetelný. Pátá normální forma patří mezi formy založené spíše na teoretickém zázemí, postrádajíc reálně dosažitelné výsledky při aplikaci v praxi.

== Další normální formy ==
Následující normální formy jsou zřídka uváděny a obvykle se s nimi při normalizaci nesetkáváme. Většina z nich je postavena na čistě teoretickém modelu a jejich aplikace v praxi bývá přehlížena (občas záměrně).
Pro úplnost je však vhodné si tyto normální formy alespoň uvést.

=== Normální forma elementárních klíčů (EKNF) ===
'''Normální forma elementárních klíčů''' (z anglického ''Elementary key normal form'') je nadstavbou nad třetí normální formou a striktně spadá před BCNF, tedy platí pravidlo, že relace v EKNF jsou zároveň ve třetí normální formě. Tuto normální formu představil v roce 1982 Carlo Zaniolo. <ref>ZANIOLO, C. (1982) [http://web.cs.ucla.edu/~zaniolo/papers/tods82b.pdf ''A New Normal Form for the Design of Relational Database Schemata''] [online], ACM Transactions on Database Systems. [citováno 11. 6. 2018] (anglicky)</ref> EKNF cílí na zachycení hlavních kvalit jak třetí normální formy, tak BCNF a zároveň adresuje jejich problémy 

Formální definice EKNF zní: 
*Relace R je v normální formě elementárních klíču (EKNF) právě tehdy, když pro každou netriviální funkční závislost X → Y platí:
**X je superklíč, nebo
**Y je součástí některého z elementárních klíčů
***kde klíč K je elementární právě tehdy, když existuje atribut A relace R, kde funkční závislost K → A je netriviální a neredukovatelná

=== Normální forma nezbytných n-tic (ETNF) ===
'''Normální forma nezbytných n-tic''' (z anglického ''Essential tuple normal form''), zkráceně ETNF je jedna z nejnovějších normálních forem. Její představení proběhlo v roce 2012. <ref name=FAGIN2012>DARWEN, H., DATE, C. J., FAGIN, R. (2012) ''A Normal Form for Preventing Redundant Tuples in Relational Databases'', ICDT '12 Proceedings of the 15th International Conference on Database Theory, ISBN: 978-1-4503-0791-8, [citováno 11. 06. 2018]</ref>
Jedná se o normální formu, která zaujímá místo mezi čtvrtou a pátou normální formou. Předmětem zkoumání této normální formy jsou funkční závislosti v relacích relačních databázích. Hlavní výhodou aplikace této normální formy je obdobně jako v případě ostatních normálních forem snížení redundance dat. 
Dle znění formální definice je schéma relace R v normální formě nezbytných n-tic (ETNF) právě tehdy, když:
*každá n-tice každé instance R je nezbytná (její ztráta by zapříčinila ztrátu informací)<ref name=FAGIN2012 />

=== Normální forma doménových klíčů (DK/NF) ===
'''Normální forma doménových klíčů''' (z anglického ''Domain-key normal form'') je další normální formou, jejíž autorem je R. Fagin. <ref>FAGIN, R. (1981) [http://www.almaden.ibm.com/cs/people/fagin/tods81.pdf ''A Normal Form for Relational Databases That Is Based on Domains and Keys''] [online], ACM Transactions on Database Systems, str 387–415. [citováno 11. 6. 2018] (anglicky)</ref> 

Dle jedné z definic je DK/NF splněna, pokud:
*databáze neobsahuje žádné omezení kromě doménových omezení a omezení klíčů.
**doménové omezení určuje možné hodnoty daného atributu, a
**omezení klíčů určuje atributy, které unikátně identifikují řádek (záznam) dané tabulky.

Dle další definice<ref>DATE, C. J. (2012) [https://web.archive.org/web/20120406123712/http://www.dbdebunk.com/page/page/621935.htm ''ON DK/NF NORMAL FORM''],</ref> je DK/NF splněna, pokud:
*každé omezení je logickým následkem definicí klíčů a [[Datová_doména|datových domén]].

Poznámka: V literatuře se můžeme setkat s chápáním DK/NF jako synomem k šesté normální formě, ovšem dle definice Christophera Date se DK/NF od jím definované šesté normální formy liší.

=== Šestá normální forma (6NF) ===
'''Šestá normální forma''' je poslední uváděná normální forma, představená v roce 2003 a jejíž autory jsou C. J. Date, H. Darwen a N. A. Lorentzos. 
Cílem šesté normální formy je dekompozice relací na dále již neredukovatelné komponenty (relace).
<ref>DATE, C. J., DARWEN, H., LORENTZOS, N. A. (2003) ''Temporal Data and the Relational Model: A Detailed Investigation into the Application of Interval and Relation Theory to the Problem of Temporal Database Management''. Oxford: Elsevier LTD. ISBN 1-55860-855-9.</ref>
<ref>NEHA, S. K. (2015) [https://www.ijraset.com/fileserve.php?FID=1559 ''Sixth Normal Form''] [online], International Journal for Research in Applied Science & Engineering Technology (IJRASET), Volume 3 Issue I, January 2015, ISSN: 2321-9653</ref>
<ref>KNOWLES, C. (2012) [http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1026&context=sais2012 ''6NF Conceptual Models and Data Warehousing 2.0''] [online], Georgia Southern University, Association for Information System, AIS Electronic Library (AISeL). [citováno 12. 6. 2018]</ref>

Dle jedné z možných definic je tabulka v 6NF právě tehdy, když:<ref>ROGERS, R., PerformanceDBA (2015) [https://stackoverflow.com/a/4843859 ''Would like to Understand 6NF with an Example''] [online] stackoverflow.com, [aktualizováno: 7. 5. 2015], [citováno 11. 6. 2018] (anglicky)</ref>
*řádek tabulky obsahuje primární klíč a pouze (maximálně) jeden další atribut

Šestá normální forma nabírá na důležitosti s využitím dočasných datových uložišť a datových skladů.

= Další četba =

* CHLAPEK, D., STANOVSKÁ, I., ŘEPA, V. (2011) ''Analýza a návrh informačních systémů'', Praha : Oeconomica, 2011, ISBN: 978-80-245-1782-7
* KULHAN, J., LEHOCKÝ, Z. (2008) [http://programujte.com/clanek/2008071900-normalizace-relacnich-databazi/ ''Normalizace relačních databází''] [online], programujte.com, [aktualizováno 23. 7. 2008]
* SKŘIVAN, J. (2000) [https://www.interval.cz/clanky/databaze-a-jazyk-sql/ ''Databáze a jazyk SQL''] [online], interval.cz, [aktualizováno 4. 8. 2000]
* ZENDULKA, J. [http://www.fit.vutbr.cz/study/courses/DSI/public/pdf/nove/5_2.pdf ''Databázové systémy - 5 Formalizace návrhu databáze''], Vysoké učení technické v Brně, Fakulta informačních technologií
* KRISHNA, S. (1992) [https://books.google.cz/books?id=iVWmw2aTtasC&printsec=frontcover#v=onepage&q&f=false ''Introduction to Database and Knowledge-base Systems''], World Scientific Series in Computer Science - Vol. 28 (anglicky)
* DATE, C. J. (2000) ''An introduction to database systems'', Addison-Wesley, ISBN: 0-201-38590-2 (anglicky)
* ROGERS, R., PerformanceDBA (2015) [https://stackoverflow.com/a/4843859 ''Would like to Understand 6NF with an Example''] [online] stackoverflow.com, [aktualizováno: 7. 5. 2015], [citováno 11. 6. 2018] (anglicky)
* MICROSOFT (2017) [https://support.microsoft.com/en-us/help/283878/description-of-the-database-normalization-basics ''Description of the database normalization basics''] [online], Microsoft, [aktualizováno 10. 5. 2017] (anglicky)

= Reference =
<references/>

Normalizace databáze/cs

2018-06-14T15:55:24Z

Navd00: /* Šestá normální forma (6NF) */

'''Normalizace databáze''' je v [[Informatika|informatice]] označení procesu zodpovědného za transformaci [[Relační databáze|relační databáze]] tak, aby splňovala sadu podmínek – tzv. [[#Normální formy|normálních forem]]. Cílem aplikace těchto podmínek je upravení databáze do vhodnějšího stavu, zamezení nekonzistencí, zvýšení integrity dat, odstranění duplicit (potažmo snížení redundance dat) a zamezení potenciálních problémů při manipulaci s daty v relační databázi. Autorem termínu normalizace databáze je britsko-americký matematik a informatik [[Edgar_Frank_Codd|Edgar. F. Codd]].

= 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. 

== 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. Coddem<ref>CODD, 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.</ref> 
*Codd pokračoval v definici druhé a třetí normální formy v roce 1971<ref>CODD, 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</ref> 
*V roce 1974 E. F. Codd společně s Raymondem F. Boyce definovali Boyceho-Coddovu normální formu<ref>CODD, E. F., (1974). ''Recent Investigations into Relational Data Base Systems'', IBM Research Report RJ1385</ref> 
*Čtvrtou normální formu představil v roce 1977 Ronald Fagin<ref>FAGIN, R. (1977). ''Multivalued dependencies and a new normal form for relational databases'', ACM Transactions on Database Systems (TODS), str. 262-278</ref> 
*R. Fagin rozšířil normální formy o definici páté normální formy svým konferenčním příspěvkem v roce 1979<ref>KRISHNA, S., (1991). ''Introduction to Database and Knowledge-Base Systems'', ISBN 9810206208. str. 65 </ref> 

== 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 hodnotu <ref>ZÁDOVÁ, V., ''Relační datový model'', Technická Univerzita v Liberci, Katedra informatiky, Ekonomická fakulta, [citováno: 10. 6. 2018] </ref> 

== 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 [[Atomicita|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íč|primární klíč]].

{| class="wikitable"
|+ align="top" | ''' 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ů:

{| class="wikitable"
|+ align="top" | ''' 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:

{| class="wikitable"
|+ align="top" | ''' Tabulka Osoba'''
!| ID Osoby
!| Jméno
|-
| 1 || Petr Novák
|-
| 2 || Jarmil Hnízdo
|-
|}

{| class="wikitable"
|+ align="top" | ''' 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íč|cízí 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í klíč|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}:

{| class="wikitable"
|+ align="top" | ''' Tabulka Záznam''' <ref>SMASHERY (2013) [https://stackoverflow.com/a/724032 ''What are database normal forms and can you give examples?''] [online], stackoverflow.com, [aktualizováno: 31. 5. 2013], [citováno: 10. 6. 2018] (anglicky)</ref>
!| 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:

{| class="wikitable"
|+ align="top" | ''' 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
|-
|}

{| class="wikitable"
|+ align="top" | ''' 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ávislosti <ref name=CHLAPEK>CHLAPEK, D., (2015). ''Normalizace dat - souhrnný příklad'', Vysoká škola ekonomická v Praze, Fakulta informatiky a statistiky, Katedra informačních technologií, str. 7-10.</ref>

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: 
*<math>X \rightarrow Y</math> 
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 <math>X \rightarrow Y \land Y \rightarrow Z \Rightarrow X \rightarrow Z</math><ref>ŽOLTÁ, L., [http://lucie.zolta.cz/index.php/iformacni-systemy-databaze/47-funkcni-zavislosti ''Funkční závislosti''] [online], lucie.zolta.cz, [citováno: 11. 06. 2018]</ref>

=== 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:

{| class="wikitable"
|+ align="top" | ''' 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ě:

{| class="wikitable"
|+ align="top" | ''' 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
|-
|}

{| class="wikitable"
|+ align="top" | ''' Tabulka Žánr'''
!| ID Žánru
!| Název žánru
|-
| 1 || Komedie
|-
| 2 || Akční
|-
| 3 || Dokumentární
|-
|}

Rozkladem původní tabulky nyní dostáváme dvě tabulky, které již neobsahují žádné tranzitivní závislosti. Navíc jsme díky naplnění třetí normální formy napomohli ke snížení redundance dat.

== Boyceho-Coddova normální forma (BCNF) ==
viz. článek [[Boyceho–Coddova_normální_forma|Boyceho–Coddova_normální_forma]]

== Čtvrtá normální forma (4NF) ==
'''Čtvrtá normální forma''' je dalším krokem po uplatnění Boyceho-Coddovy normální formy. Jak již bylo nastíněno v počátku, druhá, třetí a Boyceho-Coddova normální forma řeší funkční závislosti jednotlivých atributů, kdežto čtvrtá a pátá normální forma zkoumá vztahy složených primárních klíčů. Dle jedné z definic navíc od splnění všech předešlých normálních forem umožňuje rozlišení a oddělení nezávislých vícehodnotových atributů vytvářejících složený primární klíč. <ref name=CHLAPEK />

Požadavky pro splnění 4NF jsou tedy následující:
*relace je v BCNF
*pro každou netriviální vícehodnotovou závislost X ↠ Y je X superklíčem v dané relaci. (superklíč je jakékoliv uskupení atributů, které jednoznačně identifikuje záznam v tabulce)<ref>ŠÍPAL, Š., [http://vyuka.greendot.cz/materialy/material-37.ppt ''Databázové systémy''] [online], [citováno: 11. 6. 2018]</ref>

=== Příklad 4 ===
Ukažme si opět na příkladu, mějme následující tabulku evidující záznamy o prodejcích, prodávaných produktech a pobočkách, kde nabízejí své produkty:

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Produkt-Pobočka'''
!| Prodejce
!| Produkt
!| Pobočka
|-
| Prodejce 01 || Lyže || Praha
|-
| Prodejce 01 || Lyže || Liberec
|-
| Prodejce 01 || Lyže || Pardubice
|-
| Prodejce 01 || Lyžařské brýle || Praha
|-
| Prodejce 01 || Lyžařské brýle || Liberec
|-
| Prodejce 01 || Lyžařské brýle || Pardubice
|-
| Prodejce 02 || Lyže || Praha
|-
| Prodejce 02 || Lyže || Liberec
|-
| Prodejce 02 || Lyže || Pardubice
|-
| Prodejce 02 || Lyžařské brýle || Praha
|-
| Prodejce 02 || Lyžařské brýle || Liberec
|-
| Prodejce 02 || Lyžařské brýle || Pardubice
|-
| Prodejce 03 || Lyže || Pardubice
|-
|}

Stejně jako předchozí normální formy, i čtvrtá normální forma se snaží zamezit zbytečné redundanci dat. Množství záznamů v tabulce výše bylo zvoleno především proto, aby bylo možné ilustrovat, že i tato normální forma napomáhá ke snížení redundance dat.

Jelikož tabulka neobsahuje žádné neklíčové atributy (je tvořena pouze složeným primárním klíčem {Prodejce, Produkt, Pobočka}), máme zajištěné splnění všech předchozích normálních forem. Tato tabulka však nesplňuje pravidla určená čtvrtou normální formou. Vezmeme-li v úvahu, že všichni prodejci poskytují všechny své produkty na všech svých pobočkách (a proč by také neposkytovali), zjistíme, že složený klíč je bezpochyby tvořen z nezávislých dat, kdy produkt není vázán na určitou pobočku. Z toho důvodu je porušena čtvrtá normální forma a pro její splnění je zapotřebí provést dekompozici následující tabulky, která by vypadala následovně:

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Produkt'''
!| Prodejce
!| Produkt
|-
| Prodejce 01 || Lyže
|-
| Prodejce 01 || Lyžařské brýle
|-
| Prodejce 02 || Lyže
|-
| Prodejce 02 || Lyžařské brýle
|-
| Prodejce 03 || Lyžařské brýle
|-
|}

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Pobočka'''
!| Prodejce
!| Pobočka
|-
| Prodejce 01 || Praha
|-
| Prodejce 01 || Liberec
|-
| Prodejce 01 || Pardubice
|-
| Prodejce 02 || Praha
|-
| Prodejce 02 || Liberec
|-
| Prodejce 02 || Pardubice
|-
| Prodejce 03 || Pardubice
|-
|}

Po dekompozici tabulky již máme splnění čtvrté normální formy zajištěné.

== Pátá normální forma (5NF) ==
'''Pátá normální forma''' tkví ve splnění následujících:
*čtvrté normální formy (4NF)
*tabulku není možné dále bezeztrátově rozdělovat.
Ve všech předchozích normálních formách nedocházelo dekompozicí tabulek ke ztrátě dat <ref>SEKHAR, R., [https://www.quora.com/What-is-5NF-in-DBMS ''Fifth Normal Form (5NF)''] [online], Quora.com, [aktualizováno: 9. 3. 2017], [citováno: 10. 6. 2018] (anglicky)</ref>, ovšem upravíme-li příklad a situaci ze čtvrté normální formy, kdy prodejci již neposkytují všechny své produkty na každé své pobočce, ale pouze některé z nich, dojde při rozkladu ke ztrátě informací.

=== Příklad 5 ===
Mějme tedy následující upravenou tabulku z minulého příkladu:

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Produkt-Pobočka'''
!| Prodejce
!| Produkt
!| Pobočka
|-
| Prodejce 01 || Lyže || Praha
|-
| Prodejce 01 || Lyžařské brýle || Praha
|-
| Prodejce 01 || Rukavice || Pardubice
|-
| Prodejce 02 || Rukavice || Praha
|-
|}

Když se pokusíme o dekompozici tabulky, stejně jako při uspokojování čtvrté normální formy, dostaneme následující:

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Produkt'''
!| Prodejce
!| Produkt
|-
| Prodejce 01 || Lyže
|-
| Prodejce 01 || Lyžařské brýle
|-
| Prodejce 01 || Rukavice
|-
| Prodejce 02 || Rukavice
|-
|}

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Pobočka'''
!| Prodejce
!| Produkt
|-
| Prodejce 01 || Praha
|-
| Prodejce 01 || Pardubice
|-
| Prodejce 02 || Praha
|-
|}

Zajisté jsme dekompozicí pomohli snížit redundanci dat v naší databázi (která by byla zjevná především u rozsáhlých databází s velkým počtem záznamů), ovšem ve výsledku jsme ztratili důležité informace o závislosti prodejců – produktů – poboček. Při aplikaci některého z možných spojení tabulek, např. [[JOIN#Přirozené_spojování|přirozeného spojování]] (NATURAL JOIN) dostáváme následující výsledky:

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Produkt-Pobočka'''
!| Prodejce
!| Produkt
!| Pobočka
|-
| Prodejce 01 || Lyže || Praha
|-
| Prodejce 01 || Lyžařské brýle || Praha
|-
| Prodejce 01 || Rukavice || Praha
|-
| Prodejce 01 || Rukavice || Pardubice
|-
| Prodejce 01 || Lyžařské brýle || Pardubice
|-
| Prodejce 01 || Lyže || Pardubice
|-
| Prodejce 02 || Rukavice || Praha
|-
|}

Všimněme si, že dle obdržených výsledků vrácených spojením tabulek ''Prodejce-Produkt'' a ''Prodejce-Pobočka'' došlo k vytvoření tří nových záznamů, které tvrdí, že např. Prodejce 01 prodává lyžařské brýle v Pardubicích, což ovšem v porovnání s původní tabulkou víme, že není pravda.
Uvažujme tedy o dekompozici původní tabulky na tři tabulky oproti dvěma původním. Tedy kromě tabulek Prodejce-Produkt a Prodejce-Pobočka přidáme ještě tabulku Pobočka-Produkt evidující vztah mezi produkty a jejich dostupností na jednotlivých pobočkách. Mějme tedy navíc následující tabulku:

{| class="wikitable"
|+ align="top" | ''' Tabulka Pobočka-Produkt'''
!| Pobočka
!| Produkt
|-
| Praha || Lyže
|-
| Praha || Lyžařské brýle
|-
| Praha || Rukavice
|-
| Pardubice || Rukavice
|-
|}

Problém však nastává ve chvíli, kdy se pokusíme tyto tři tabulky spojit a dostat tak původní data. Po chvíli zkoušení zjistíme, že se nám takové spojení realizovat nepodaří a že není způsob, jak bychom dekompozicí původní tabulky mohli provést bezeztrátově. Tedy lze konstatovat, že tabulka Prodejce-Produkt-Pobočka již nelze dále bezeztrátově rozložit (je tedy v 5NF), a proto se musíme spokojit s redundancí dat původní tabulky pro zajištění, že nepřijdeme o žádná potenciálně důležitá data.

=== Příklad 6 ===
Víme už tedy o jaké tabulce můžeme konstatovat, že je v páté normální formě. Ukažme si ještě tabulku, která pátou normální formu porušuje. Upravíme-li záznamy původní tabulky a určíme-li, že se v Praze prodávají všechny produkty (lyže a lyžařské brýle), ale v Pardubicích pouze lyžařské brýle (důvod této diskriminace ponecháme záhadou), bude nová tabulka vypadat následovně:

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Produkt-Pobočka'''
!| Prodejce
!| Produkt
!| Pobočka
|-
| Prodejce 01 || Lyže || Praha
|-
| Prodejce 01 || Lyžařské brýle || Praha
|-
| Prodejce 01 || Lyžařské brýle || Pardubice
|-
| Prodejce 02 || Lyže || Praha
|-
| Prodejce 02 || Lyžařské brýle || Praha
|-
|}

Budeme-li postupovat stejně jako při pokusu o dekompozici bezeztrátově nerozdělitelné tabulky výše, dostaneme následující tři tabulky:

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Produkt'''
!| Prodejce
!| Produkt
|-
| Prodejce 01 || Lyže
|-
| Prodejce 01 || Lyžařské brýle
|-
| Prodejce 02 || Lyže
|-
| Prodejce 02 || Lyžařské brýle
|-
|}

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Pobočka'''
!| Prodejce
!| Produkt
|-
| Prodejce 01 || Praha
|-
| Prodejce 01 || Pardubice
|-
| Prodejce 02 || Praha
|-
|}

{| class="wikitable"
|+ align="top" | ''' Tabulka Pobočka-Produkt'''
!| Pobočka
!| Produkt
|-
| Praha || Lyže
|-
| Praha || Lyžařské brýle
|-
| Pardubice || Lyžařské brýle
|-
|}

Při pokusu o jejich opětovné spojení, zjistíme, že se nám v tomto případě podařila bezeztrátová dekompozice a výsledkem naší selekce je totožná tabulka s tabulkou před rozdělením. Po spojení těchto tabulek tedy získáváme:

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Produkt-Pobočka'''
!| Prodejce
!| Produkt
!| Pobočka
|-
| Prodejce 01 || Lyže || Praha
|-
| Prodejce 01 || Lyžařské brýle || Praha
|-
| Prodejce 01 || Lyžařské brýle || Pardubice
|-
| Prodejce 02 || Lyže || Praha
|-
| Prodejce 02 || Lyžařské brýle || Praha
|-
|}

Jelikož se nám podařilo opětovně spojit tři rozdělené tabulky a získat tak nezměněnou původní tabulku, lze konstatovat, že tabulka nesplňuje pravidla stanovená pátou normální formou. Srovnáme-li oba příklady této normální formy, zjistíme, že hlavním rozdílem bylo uvedení rozšiřujících informací, které nejsou ihned zjevné při pohledu na samotnou tabulku. Identifikování tabulek, které porušují pátou normální formu bývá v praxi velmi složité, a navíc reálný přínos její aplikace bývá často nezřetelný. Pátá normální forma patří mezi formy založené spíše na teoretickém zázemí, postrádajíc reálně dosažitelné výsledky při aplikaci v praxi.

== Další normální formy ==
Následující normální formy jsou zřídka uváděny a obvykle se s nimi při normalizaci nesetkáváme. Většina z nich je postavena na čistě teoretickém modelu a jejich aplikace v praxi bývá přehlížena (občas záměrně).
Pro úplnost je však vhodné si tyto normální formy alespoň uvést.

=== Normální forma elementárních klíčů (EKNF) ===
'''Normální forma elementárních klíčů''' (z anglického ''Elementary key normal form'') je nadstavbou nad třetí normální formou a striktně spadá před BCNF, tedy platí pravidlo, že relace v EKNF jsou zároveň ve třetí normální formě. Tuto normální formu představil v roce 1982 Carlo Zaniolo. <ref>ZANIOLO, C. (1982) [http://web.cs.ucla.edu/~zaniolo/papers/tods82b.pdf ''A New Normal Form for the Design of Relational Database Schemata''] [online], ACM Transactions on Database Systems. [citováno 11. 6. 2018] (anglicky)</ref> EKNF cílí na zachycení hlavních kvalit jak třetí normální formy, tak BCNF a zároveň adresuje jejich problémy 

Formální definice EKNF zní: 
*Relace R je v normální formě elementárních klíču (EKNF) právě tehdy, když pro každou netriviální funkční závislost X → Y platí:
**X je superklíč, nebo
**Y je součástí některého z elementárních klíčů
***kde klíč K je elementární právě tehdy, když existuje atribut A relace R, kde funkční závislost K → A je netriviální a neredukovatelná

=== Normální forma nezbytných n-tic (ETNF) ===
'''Normální forma nezbytných n-tic''' (z anglického ''Essential tuple normal form''), zkráceně ETNF je jedna z nejnovějších normálních forem. Její představení proběhlo v roce 2012. <ref name=FAGIN2012>DARWEN, H., DATE, C. J., FAGIN, R. (2012) ''A Normal Form for Preventing Redundant Tuples in Relational Databases'', ICDT '12 Proceedings of the 15th International Conference on Database Theory, ISBN: 978-1-4503-0791-8, [citováno 11. 06. 2018]</ref>
Jedná se o normální formu, která zaujímá místo mezi čtvrtou a pátou normální formou. Předmětem zkoumání této normální formy jsou funkční závislosti v relacích relačních databázích. Hlavní výhodou aplikace této normální formy je obdobně jako v případě ostatních normálních forem snížení redundance dat. 
Dle znění formální definice je schéma relace R v normální formě nezbytných n-tic (ETNF) právě tehdy, když:
*každá n-tice každé instance R je nezbytná (její ztráta by zapříčinila ztrátu informací)<ref name=FAGIN2012 />

=== Normální forma doménových klíčů (DK/NF) ===
'''Normální forma doménových klíčů''' (z anglického ''Domain-key normal form'') je další normální formou, jejíž autorem je R. Fagin. <ref>FAGIN, R. (1981) [http://www.almaden.ibm.com/cs/people/fagin/tods81.pdf ''A Normal Form for Relational Databases That Is Based on Domains and Keys''] [online], ACM Transactions on Database Systems, str 387–415. [citováno 11. 6. 2018] (anglicky)</ref> 

Dle jedné z definic je DK/NF splněna, pokud:
*databáze neobsahuje žádné omezení kromě doménových omezení a omezení klíčů.
**doménové omezení určuje možné hodnoty daného atributu, a
**omezení klíčů určuje atributy, které unikátně identifikují řádek (záznam) dané tabulky.

Dle další definice<ref>DATE, C. J. (2012) [https://web.archive.org/web/20120406123712/http://www.dbdebunk.com/page/page/621935.htm ''ON DK/NF NORMAL FORM''],</ref> je DK/NF splněna, pokud:
*každé omezení je logickým následkem definicí klíčů a [[Datová_doména|datových domén]].

Poznámka: V literatuře se můžeme setkat s chápáním DK/NF jako synomem k šesté normální formě, ovšem dle definice Christophera Date se DK/NF od jím definované šesté normální formy liší.

=== Šestá normální forma (6NF) ===
'''Šestá normální forma''' je poslední uváděná normální forma, představená v roce 2003 a jejíž autory jsou C. J. Date, H. Darwen a N. A. Lorentzos. 
Cílem šesté normální formy je dekompozice relací na dále již neredukovatelné komponenty (relace).
<ref>DATE, C. J., DARWEN, H., LORENTZOS, N. A. (2003) ''Temporal Data and the Relational Model: A Detailed Investigation into the Application of Interval and Relation Theory to the Problem of Temporal Database Management''. Oxford: Elsevier LTD. ISBN 1-55860-855-9.</ref>
<ref>NEHA, S. K. (2015) [https://www.ijraset.com/fileserve.php?FID=1559 ''Sixth Normal Form''] [online], International Journal for Research in Applied Science & Engineering Technology (IJRASET), Volume 3 Issue I, January 2015, ISSN: 2321-9653</ref>
<ref>KNOWLES, C. (2012) [http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1026&context=sais2012 ''6NF Conceptual Models and Data Warehousing 2.0''] [online], Georgia Southern University, Association for Information System, AIS Electronic Library (AISeL). [citováno 12. 6. 2018]</ref>

Dle jedné z možných definic je tabulka v 6NF právě tehdy, když:<ref>ROGERS, R., PerformanceDBA (2015) [https://stackoverflow.com/a/4843859 ''Would like to Understand 6NF with an Example''] [online] stackoverflow.com, [aktualizováno: 7. 5. 2015], [citováno 11. 6. 2018] (anglicky)</ref>
*řádek tabulky obsahuje primární klíč a pouze (maximálně) jeden další atribut

Šestá normální forma nabírá na důležitosti s využitím dočasných datových uložišť a datových skladů.

= Další četba =

* CHLAPEK, D., STANOVSKÁ, I., ŘEPA, V. (2011) ''Analýza a návrh informačních systémů'', Praha : Oeconomica, 2011, ISBN: 978-80-245-1782-7
* KULHAN, J., LEHOCKÝ, Z. (2008) [http://programujte.com/clanek/2008071900-normalizace-relacnich-databazi/ ''Normalizace relačních databází''] [online], programujte.com, [aktualizováno 23. 7. 2008]
* SKŘIVAN, J. (2000) [https://www.interval.cz/clanky/databaze-a-jazyk-sql/ ''Databáze a jazyk SQL''] [online], interval.cz, [aktualizováno 4. 8. 2000]
* ZENDULKA, J. [http://www.fit.vutbr.cz/study/courses/DSI/public/pdf/nove/5_2.pdf ''Databázové systémy - 5 Formalizace návrhu databáze''], Vysoké učení technické v Brně, Fakulta informačních technologií
* KRISHNA, S. (1992) [https://books.google.cz/books?id=iVWmw2aTtasC&printsec=frontcover#v=onepage&q&f=false ''Introduction to Database and Knowledge-base Systems''], World Scientific Series in Computer Science - Vol. 28 (anglicky)
* DATE, C. J. (2000) ''An introduction to database systems'', Addison-Wesley, ISBN: 0-201-38590-2 (anglicky)
* ROGERS, R., PerformanceDBA (2015) [https://stackoverflow.com/a/4843859 ''Would like to Understand 6NF with an Example''] [online] stackoverflow.com, [aktualizováno: 7. 5. 2015], [citováno 11. 6. 2018] (anglicky)
* MICROSOFT (2017) [https://support.microsoft.com/en-us/help/283878/description-of-the-database-normalization-basics ''Description of the database normalization basics''] [online], Microsoft, [aktualizováno 10. 5. 2017] (anglicky)

= Reference =
<references/>

Normalizace databáze/cs

2018-06-14T15:54:01Z

Navd00: /* Normální forma nezbytných n-tic (ETNF) */

'''Normalizace databáze''' je v [[Informatika|informatice]] označení procesu zodpovědného za transformaci [[Relační databáze|relační databáze]] tak, aby splňovala sadu podmínek – tzv. [[#Normální formy|normálních forem]]. Cílem aplikace těchto podmínek je upravení databáze do vhodnějšího stavu, zamezení nekonzistencí, zvýšení integrity dat, odstranění duplicit (potažmo snížení redundance dat) a zamezení potenciálních problémů při manipulaci s daty v relační databázi. Autorem termínu normalizace databáze je britsko-americký matematik a informatik [[Edgar_Frank_Codd|Edgar. F. Codd]].

= 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. 

== 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. Coddem<ref>CODD, 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.</ref> 
*Codd pokračoval v definici druhé a třetí normální formy v roce 1971<ref>CODD, 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</ref> 
*V roce 1974 E. F. Codd společně s Raymondem F. Boyce definovali Boyceho-Coddovu normální formu<ref>CODD, E. F., (1974). ''Recent Investigations into Relational Data Base Systems'', IBM Research Report RJ1385</ref> 
*Čtvrtou normální formu představil v roce 1977 Ronald Fagin<ref>FAGIN, R. (1977). ''Multivalued dependencies and a new normal form for relational databases'', ACM Transactions on Database Systems (TODS), str. 262-278</ref> 
*R. Fagin rozšířil normální formy o definici páté normální formy svým konferenčním příspěvkem v roce 1979<ref>KRISHNA, S., (1991). ''Introduction to Database and Knowledge-Base Systems'', ISBN 9810206208. str. 65 </ref> 

== 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 hodnotu <ref>ZÁDOVÁ, V., ''Relační datový model'', Technická Univerzita v Liberci, Katedra informatiky, Ekonomická fakulta, [citováno: 10. 6. 2018] </ref> 

== 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 [[Atomicita|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íč|primární klíč]].

{| class="wikitable"
|+ align="top" | ''' 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ů:

{| class="wikitable"
|+ align="top" | ''' 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:

{| class="wikitable"
|+ align="top" | ''' Tabulka Osoba'''
!| ID Osoby
!| Jméno
|-
| 1 || Petr Novák
|-
| 2 || Jarmil Hnízdo
|-
|}

{| class="wikitable"
|+ align="top" | ''' 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íč|cízí 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í klíč|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}:

{| class="wikitable"
|+ align="top" | ''' Tabulka Záznam''' <ref>SMASHERY (2013) [https://stackoverflow.com/a/724032 ''What are database normal forms and can you give examples?''] [online], stackoverflow.com, [aktualizováno: 31. 5. 2013], [citováno: 10. 6. 2018] (anglicky)</ref>
!| 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:

{| class="wikitable"
|+ align="top" | ''' 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
|-
|}

{| class="wikitable"
|+ align="top" | ''' 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ávislosti <ref name=CHLAPEK>CHLAPEK, D., (2015). ''Normalizace dat - souhrnný příklad'', Vysoká škola ekonomická v Praze, Fakulta informatiky a statistiky, Katedra informačních technologií, str. 7-10.</ref>

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: 
*<math>X \rightarrow Y</math> 
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 <math>X \rightarrow Y \land Y \rightarrow Z \Rightarrow X \rightarrow Z</math><ref>ŽOLTÁ, L., [http://lucie.zolta.cz/index.php/iformacni-systemy-databaze/47-funkcni-zavislosti ''Funkční závislosti''] [online], lucie.zolta.cz, [citováno: 11. 06. 2018]</ref>

=== 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:

{| class="wikitable"
|+ align="top" | ''' 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ě:

{| class="wikitable"
|+ align="top" | ''' 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
|-
|}

{| class="wikitable"
|+ align="top" | ''' Tabulka Žánr'''
!| ID Žánru
!| Název žánru
|-
| 1 || Komedie
|-
| 2 || Akční
|-
| 3 || Dokumentární
|-
|}

Rozkladem původní tabulky nyní dostáváme dvě tabulky, které již neobsahují žádné tranzitivní závislosti. Navíc jsme díky naplnění třetí normální formy napomohli ke snížení redundance dat.

== Boyceho-Coddova normální forma (BCNF) ==
viz. článek [[Boyceho–Coddova_normální_forma|Boyceho–Coddova_normální_forma]]

== Čtvrtá normální forma (4NF) ==
'''Čtvrtá normální forma''' je dalším krokem po uplatnění Boyceho-Coddovy normální formy. Jak již bylo nastíněno v počátku, druhá, třetí a Boyceho-Coddova normální forma řeší funkční závislosti jednotlivých atributů, kdežto čtvrtá a pátá normální forma zkoumá vztahy složených primárních klíčů. Dle jedné z definic navíc od splnění všech předešlých normálních forem umožňuje rozlišení a oddělení nezávislých vícehodnotových atributů vytvářejících složený primární klíč. <ref name=CHLAPEK />

Požadavky pro splnění 4NF jsou tedy následující:
*relace je v BCNF
*pro každou netriviální vícehodnotovou závislost X ↠ Y je X superklíčem v dané relaci. (superklíč je jakékoliv uskupení atributů, které jednoznačně identifikuje záznam v tabulce)<ref>ŠÍPAL, Š., [http://vyuka.greendot.cz/materialy/material-37.ppt ''Databázové systémy''] [online], [citováno: 11. 6. 2018]</ref>

=== Příklad 4 ===
Ukažme si opět na příkladu, mějme následující tabulku evidující záznamy o prodejcích, prodávaných produktech a pobočkách, kde nabízejí své produkty:

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Produkt-Pobočka'''
!| Prodejce
!| Produkt
!| Pobočka
|-
| Prodejce 01 || Lyže || Praha
|-
| Prodejce 01 || Lyže || Liberec
|-
| Prodejce 01 || Lyže || Pardubice
|-
| Prodejce 01 || Lyžařské brýle || Praha
|-
| Prodejce 01 || Lyžařské brýle || Liberec
|-
| Prodejce 01 || Lyžařské brýle || Pardubice
|-
| Prodejce 02 || Lyže || Praha
|-
| Prodejce 02 || Lyže || Liberec
|-
| Prodejce 02 || Lyže || Pardubice
|-
| Prodejce 02 || Lyžařské brýle || Praha
|-
| Prodejce 02 || Lyžařské brýle || Liberec
|-
| Prodejce 02 || Lyžařské brýle || Pardubice
|-
| Prodejce 03 || Lyže || Pardubice
|-
|}

Stejně jako předchozí normální formy, i čtvrtá normální forma se snaží zamezit zbytečné redundanci dat. Množství záznamů v tabulce výše bylo zvoleno především proto, aby bylo možné ilustrovat, že i tato normální forma napomáhá ke snížení redundance dat.

Jelikož tabulka neobsahuje žádné neklíčové atributy (je tvořena pouze složeným primárním klíčem {Prodejce, Produkt, Pobočka}), máme zajištěné splnění všech předchozích normálních forem. Tato tabulka však nesplňuje pravidla určená čtvrtou normální formou. Vezmeme-li v úvahu, že všichni prodejci poskytují všechny své produkty na všech svých pobočkách (a proč by také neposkytovali), zjistíme, že složený klíč je bezpochyby tvořen z nezávislých dat, kdy produkt není vázán na určitou pobočku. Z toho důvodu je porušena čtvrtá normální forma a pro její splnění je zapotřebí provést dekompozici následující tabulky, která by vypadala následovně:

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Produkt'''
!| Prodejce
!| Produkt
|-
| Prodejce 01 || Lyže
|-
| Prodejce 01 || Lyžařské brýle
|-
| Prodejce 02 || Lyže
|-
| Prodejce 02 || Lyžařské brýle
|-
| Prodejce 03 || Lyžařské brýle
|-
|}

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Pobočka'''
!| Prodejce
!| Pobočka
|-
| Prodejce 01 || Praha
|-
| Prodejce 01 || Liberec
|-
| Prodejce 01 || Pardubice
|-
| Prodejce 02 || Praha
|-
| Prodejce 02 || Liberec
|-
| Prodejce 02 || Pardubice
|-
| Prodejce 03 || Pardubice
|-
|}

Po dekompozici tabulky již máme splnění čtvrté normální formy zajištěné.

== Pátá normální forma (5NF) ==
'''Pátá normální forma''' tkví ve splnění následujících:
*čtvrté normální formy (4NF)
*tabulku není možné dále bezeztrátově rozdělovat.
Ve všech předchozích normálních formách nedocházelo dekompozicí tabulek ke ztrátě dat <ref>SEKHAR, R., [https://www.quora.com/What-is-5NF-in-DBMS ''Fifth Normal Form (5NF)''] [online], Quora.com, [aktualizováno: 9. 3. 2017], [citováno: 10. 6. 2018] (anglicky)</ref>, ovšem upravíme-li příklad a situaci ze čtvrté normální formy, kdy prodejci již neposkytují všechny své produkty na každé své pobočce, ale pouze některé z nich, dojde při rozkladu ke ztrátě informací.

=== Příklad 5 ===
Mějme tedy následující upravenou tabulku z minulého příkladu:

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Produkt-Pobočka'''
!| Prodejce
!| Produkt
!| Pobočka
|-
| Prodejce 01 || Lyže || Praha
|-
| Prodejce 01 || Lyžařské brýle || Praha
|-
| Prodejce 01 || Rukavice || Pardubice
|-
| Prodejce 02 || Rukavice || Praha
|-
|}

Když se pokusíme o dekompozici tabulky, stejně jako při uspokojování čtvrté normální formy, dostaneme následující:

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Produkt'''
!| Prodejce
!| Produkt
|-
| Prodejce 01 || Lyže
|-
| Prodejce 01 || Lyžařské brýle
|-
| Prodejce 01 || Rukavice
|-
| Prodejce 02 || Rukavice
|-
|}

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Pobočka'''
!| Prodejce
!| Produkt
|-
| Prodejce 01 || Praha
|-
| Prodejce 01 || Pardubice
|-
| Prodejce 02 || Praha
|-
|}

Zajisté jsme dekompozicí pomohli snížit redundanci dat v naší databázi (která by byla zjevná především u rozsáhlých databází s velkým počtem záznamů), ovšem ve výsledku jsme ztratili důležité informace o závislosti prodejců – produktů – poboček. Při aplikaci některého z možných spojení tabulek, např. [[JOIN#Přirozené_spojování|přirozeného spojování]] (NATURAL JOIN) dostáváme následující výsledky:

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Produkt-Pobočka'''
!| Prodejce
!| Produkt
!| Pobočka
|-
| Prodejce 01 || Lyže || Praha
|-
| Prodejce 01 || Lyžařské brýle || Praha
|-
| Prodejce 01 || Rukavice || Praha
|-
| Prodejce 01 || Rukavice || Pardubice
|-
| Prodejce 01 || Lyžařské brýle || Pardubice
|-
| Prodejce 01 || Lyže || Pardubice
|-
| Prodejce 02 || Rukavice || Praha
|-
|}

Všimněme si, že dle obdržených výsledků vrácených spojením tabulek ''Prodejce-Produkt'' a ''Prodejce-Pobočka'' došlo k vytvoření tří nových záznamů, které tvrdí, že např. Prodejce 01 prodává lyžařské brýle v Pardubicích, což ovšem v porovnání s původní tabulkou víme, že není pravda.
Uvažujme tedy o dekompozici původní tabulky na tři tabulky oproti dvěma původním. Tedy kromě tabulek Prodejce-Produkt a Prodejce-Pobočka přidáme ještě tabulku Pobočka-Produkt evidující vztah mezi produkty a jejich dostupností na jednotlivých pobočkách. Mějme tedy navíc následující tabulku:

{| class="wikitable"
|+ align="top" | ''' Tabulka Pobočka-Produkt'''
!| Pobočka
!| Produkt
|-
| Praha || Lyže
|-
| Praha || Lyžařské brýle
|-
| Praha || Rukavice
|-
| Pardubice || Rukavice
|-
|}

Problém však nastává ve chvíli, kdy se pokusíme tyto tři tabulky spojit a dostat tak původní data. Po chvíli zkoušení zjistíme, že se nám takové spojení realizovat nepodaří a že není způsob, jak bychom dekompozicí původní tabulky mohli provést bezeztrátově. Tedy lze konstatovat, že tabulka Prodejce-Produkt-Pobočka již nelze dále bezeztrátově rozložit (je tedy v 5NF), a proto se musíme spokojit s redundancí dat původní tabulky pro zajištění, že nepřijdeme o žádná potenciálně důležitá data.

=== Příklad 6 ===
Víme už tedy o jaké tabulce můžeme konstatovat, že je v páté normální formě. Ukažme si ještě tabulku, která pátou normální formu porušuje. Upravíme-li záznamy původní tabulky a určíme-li, že se v Praze prodávají všechny produkty (lyže a lyžařské brýle), ale v Pardubicích pouze lyžařské brýle (důvod této diskriminace ponecháme záhadou), bude nová tabulka vypadat následovně:

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Produkt-Pobočka'''
!| Prodejce
!| Produkt
!| Pobočka
|-
| Prodejce 01 || Lyže || Praha
|-
| Prodejce 01 || Lyžařské brýle || Praha
|-
| Prodejce 01 || Lyžařské brýle || Pardubice
|-
| Prodejce 02 || Lyže || Praha
|-
| Prodejce 02 || Lyžařské brýle || Praha
|-
|}

Budeme-li postupovat stejně jako při pokusu o dekompozici bezeztrátově nerozdělitelné tabulky výše, dostaneme následující tři tabulky:

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Produkt'''
!| Prodejce
!| Produkt
|-
| Prodejce 01 || Lyže
|-
| Prodejce 01 || Lyžařské brýle
|-
| Prodejce 02 || Lyže
|-
| Prodejce 02 || Lyžařské brýle
|-
|}

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Pobočka'''
!| Prodejce
!| Produkt
|-
| Prodejce 01 || Praha
|-
| Prodejce 01 || Pardubice
|-
| Prodejce 02 || Praha
|-
|}

{| class="wikitable"
|+ align="top" | ''' Tabulka Pobočka-Produkt'''
!| Pobočka
!| Produkt
|-
| Praha || Lyže
|-
| Praha || Lyžařské brýle
|-
| Pardubice || Lyžařské brýle
|-
|}

Při pokusu o jejich opětovné spojení, zjistíme, že se nám v tomto případě podařila bezeztrátová dekompozice a výsledkem naší selekce je totožná tabulka s tabulkou před rozdělením. Po spojení těchto tabulek tedy získáváme:

{| class="wikitable"
|+ align="top" | ''' Tabulka Prodejce-Produkt-Pobočka'''
!| Prodejce
!| Produkt
!| Pobočka
|-
| Prodejce 01 || Lyže || Praha
|-
| Prodejce 01 || Lyžařské brýle || Praha
|-
| Prodejce 01 || Lyžařské brýle || Pardubice
|-
| Prodejce 02 || Lyže || Praha
|-
| Prodejce 02 || Lyžařské brýle || Praha
|-
|}

Jelikož se nám podařilo opětovně spojit tři rozdělené tabulky a získat tak nezměněnou původní tabulku, lze konstatovat, že tabulka nesplňuje pravidla stanovená pátou normální formou. Srovnáme-li oba příklady této normální formy, zjistíme, že hlavním rozdílem bylo uvedení rozšiřujících informací, které nejsou ihned zjevné při pohledu na samotnou tabulku. Identifikování tabulek, které porušují pátou normální formu bývá v praxi velmi složité, a navíc reálný přínos její aplikace bývá často nezřetelný. Pátá normální forma patří mezi formy založené spíše na teoretickém zázemí, postrádajíc reálně dosažitelné výsledky při aplikaci v praxi.

== Další normální formy ==
Následující normální formy jsou zřídka uváděny a obvykle se s nimi při normalizaci nesetkáváme. Většina z nich je postavena na čistě teoretickém modelu a jejich aplikace v praxi bývá přehlížena (občas záměrně).
Pro úplnost je však vhodné si tyto normální formy alespoň uvést.

=== Normální forma elementárních klíčů (EKNF) ===
'''Normální forma elementárních klíčů''' (z anglického ''Elementary key normal form'') je nadstavbou nad třetí normální formou a striktně spadá před BCNF, tedy platí pravidlo, že relace v EKNF jsou zároveň ve třetí normální formě. Tuto normální formu představil v roce 1982 Carlo Zaniolo. <ref>ZANIOLO, C. (1982) [http://web.cs.ucla.edu/~zaniolo/papers/tods82b.pdf ''A New Normal Form for the Design of Relational Database Schemata''] [online], ACM Transactions on Database Systems. [citováno 11. 6. 2018] (anglicky)</ref> EKNF cílí na zachycení hlavních kvalit jak třetí normální formy, tak BCNF a zároveň adresuje jejich problémy 

Formální definice EKNF zní: 
*Relace R je v normální formě elementárních klíču (EKNF) právě tehdy, když pro každou netriviální funkční závislost X → Y platí:
**X je superklíč, nebo
**Y je součástí některého z elementárních klíčů
***kde klíč K je elementární právě tehdy, když existuje atribut A relace R, kde funkční závislost K → A je netriviální a neredukovatelná

=== Normální forma nezbytných n-tic (ETNF) ===
'''Normální forma nezbytných n-tic''' (z anglického ''Essential tuple normal form''), zkráceně ETNF je jedna z nejnovějších normálních forem. Její představení proběhlo v roce 2012. <ref name=FAGIN2012>DARWEN, H., DATE, C. J., FAGIN, R. (2012) ''A Normal Form for Preventing Redundant Tuples in Relational Databases'', ICDT '12 Proceedings of the 15th International Conference on Database Theory, ISBN: 978-1-4503-0791-8, [citováno 11. 06. 2018]</ref>
Jedná se o normální formu, která zaujímá místo mezi čtvrtou a pátou normální formou. Předmětem zkoumání této normální formy jsou funkční závislosti v relacích relačních databázích. Hlavní výhodou aplikace této normální formy je obdobně jako v případě ostatních normálních forem snížení redundance dat. 
Dle znění formální definice je schéma relace R v normální formě nezbytných n-tic (ETNF) právě tehdy, když:
*každá n-tice každé instance R je nezbytná (její ztráta by zapříčinila ztrátu informací)<ref name=FAGIN2012 />

=== Normální forma doménových klíčů (DK/NF) ===
'''Normální forma doménových klíčů''' (z anglického ''Domain-key normal form'') je další normální formou, jejíž autorem je R. Fagin. <ref>FAGIN, R. (1981) [http://www.almaden.ibm.com/cs/people/fagin/tods81.pdf ''A Normal Form for Relational Databases That Is Based on Domains and Keys''] [online], ACM Transactions on Database Systems, str 387–415. [citováno 11. 6. 2018] (anglicky)</ref> 

Dle jedné z definic je DK/NF splněna, pokud:
*databáze neobsahuje žádné omezení kromě doménových omezení a omezení klíčů.
**doménové omezení určuje možné hodnoty daného atributu, a
**omezení klíčů určuje atributy, které unikátně identifikují řádek (záznam) dané tabulky.

Dle další definice<ref>DATE, C. J. (2012) [https://web.archive.org/web/20120406123712/http://www.dbdebunk.com/page/page/621935.htm ''ON DK/NF NORMAL FORM''],</ref> je DK/NF splněna, pokud:
*každé omezení je logickým následkem definicí klíčů a [[Datová_doména|datových domén]].

Poznámka: V literatuře se můžeme setkat s chápáním DK/NF jako synomem k šesté normální formě, ovšem dle definice Christophera Date se DK/NF od jím definované šesté normální formy liší.

=== Šestá normální forma (6NF) ===
'''Šestá normální forma''' je poslední uváděná normální forma, představená v roce 2003 a jejíž autory jsou C. J. Date, H. Darwen a N. A. Lorentzos. 
Cílem šesté normální formy je dekompozice relací na dále již neredukovatelné komponenty (relace).
<ref>DATE, C. J., DARWEN, H., LORENTZOS, N. A. (2003) ''Temporal Data and the Relational Model: A Detailed Investigation into the Application of Interval and Relation Theory to the Problem of Temporal Database Management''. Oxford: Elsevier LTD. ISBN 1-55860-855-9.</ref>
<ref>NEHA, S. K. (2015) [https://www.ijraset.com/fileserve.php?FID=1559 ''Sixth Normal Form''] [online], International Journal for Research in Applied Science & Engineering Technology (IJRASET), Volume 3 Issue I, January 2015, ISSN: 2321-9653</ref>
<ref>KNOWLES, C. (2012) [http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1026&context=sais2012 ''6NF Conceptual Models and Data Warehousing 2.0''] [online], Georgia Southern University, Association for Information System, AIS Electronic Library (AISeL). [citováno 12. 6. 2018]</ref>

Dle jedné z možných definic je tabulka v 6NF právě tehdy, když:
*řádek tabulky obsahuje primární klíč a pouze (maximálně) jeden další atribut<ref>ROGERS, R., PerformanceDBA (2015) [https://stackoverflow.com/a/4843859 ''Would like to Understand 6NF with an Example''] [online] stackoverflow.com, [aktualizováno: 7. 5. 2015], [citováno 11. 6. 2018] (anglicky)</ref>

Šestá normální forma nabírá na důležitosti s využitím dočasných datových uložišť a datových skladů.

= Další četba =

* CHLAPEK, D., STANOVSKÁ, I., ŘEPA, V. (2011) ''Analýza a návrh informačních systémů'', Praha : Oeconomica, 2011, ISBN: 978-80-245-1782-7
* KULHAN, J., LEHOCKÝ, Z. (2008) [http://programujte.com/clanek/2008071900-normalizace-relacnich-databazi/ ''Normalizace relačních databází''] [online], programujte.com, [aktualizováno 23. 7. 2008]
* SKŘIVAN, J. (2000) [https://www.interval.cz/clanky/databaze-a-jazyk-sql/ ''Databáze a jazyk SQL''] [online], interval.cz, [aktualizováno 4. 8. 2000]
* ZENDULKA, J. [http://www.fit.vutbr.cz/study/courses/DSI/public/pdf/nove/5_2.pdf ''Databázové systémy - 5 Formalizace návrhu databáze''], Vysoké učení technické v Brně, Fakulta informačních technologií
* KRISHNA, S. (1992) [https://books.google.cz/books?id=iVWmw2aTtasC&printsec=frontcover#v=onepage&q&f=false ''Introduction to Database and Knowledge-base Systems''], World Scientific Series in Computer Science - Vol. 28 (anglicky)
* DATE, C. J. (2000) ''An introduction to database systems'', Addison-Wesley, ISBN: 0-201-38590-2 (anglicky)
* ROGERS, R., PerformanceDBA (2015) [https://stackoverflow.com/a/4843859 ''Would like to Understand 6NF with an Example''] [online] stackoverflow.com, [aktualizováno: 7. 5. 2015], [citováno 11. 6. 2018] (anglicky)
* MICROSOFT (2017) [https://support.microsoft.com/en-us/help/283878/description-of-the-database-normalization-basics ''Description of the database normalization basics''] [online], Microsoft, [aktualizováno 10. 5. 2017] (anglicky)

= Reference =
<references/>