Třetí normální forma (3NF): definice a pravidla normalizace databází
Přehled 3NF: srozumitelná definice, pravidla a příklady normalizace databází pro odstranění redundance, správu primárních klíčů a zajištění datové konzistence.
Třetí normální forma (3NF) je vlastnost relačního modelu, konkrétně tabulek, která slouží jako kritérium normalizace databáze. Cílem 3NF je odstranit redundanci a anomálie při vkládání, aktualizaci nebo mazání dat tím, že zajistí, aby non-key (neklíčové) atributy byly závislé přímo a pouze na klíči tabulky, nikoli na jiných neklíčových atributech.
Podmínky a formální definice
Nezbytnou podmínkou pro dosažení třetí normální formy je, aby tabulka byla nejprve ve druhé normální formě. K tomu se přidává pravidlo týkající se tzv. tranzitivních závislostí.
- Praktické pravidlo (běžná formulace): Každý sloupec (atribut) v tabulce, který není součástí primárního klíče, musí být závislý přímo na primárním klíči a nesmí být závislý nepřímo přes jiný neklíčový atribut (tj. nesmí existovat tranzitivní závislost).
- Formální definice: Pro každou netriviální funkční závislost X → A platí alespoň jedna z podmínek: X je superklíč, nebo A je tzv. prime atribut (tj. součást nějakého kandidátního klíče). Tato formulace povoluje některé výjimky, které BCNF zakazuje.
Co to znamená v praxi
V tabulce, která je ve třetím normálním tvaru, jsou data v jednotlivých sloupcích v každém řádku závislá pouze na sloupcích, které jsou součástí primárního klíče. Primární klíč je jeden nebo více sloupců v řádku, který se používá k identifikaci a indexování daného řádku tabulky. Sloupce, které nesouvisejí s žádným sloupcem primárního klíče, by měly být odstraněny nebo přesunuty do jiné tabulky tak, aby již nepředstavovaly tranzitivní závislost.
Příklad (ilustrace problému a řešení)
Původní tabulka (nenormalizovaná):
- Objednávka(OrderID, CustomerID, CustomerName, CustomerAddress, ProductID, Quantity)
Problém: atributy CustomerName a CustomerAddress závisí na CustomerID, nikoli přímo na OrderID. To je tranzitivní závislost: OrderID → CustomerID → CustomerAddress. Opakované ukládání adresy u více objednávek téhož zákazníka vede k redundanci a riziku nekonzistence.
Řešení pomocí 3NF: rozdělit tabulku na dvě (nebo více):
- Orders(OrderID, CustomerID, ProductID, Quantity)
- Customers(CustomerID, CustomerName, CustomerAddress)
Tímto způsobem jsou informace o zákazníkovi uloženy pouze jednou a závisí na CustomerID (který je primárním klíčem tabulky Customers), čímž se odstraní tranzitivní závislost a redundantní data v tabulce objednávek.
Postup při normalizaci do 3NF
- Identifikujte primární a kandidátní klíče v tabulce.
- Určete všechny funkční závislosti mezi atributy.
- Odstraňte parciální závislosti (pokud existují) – to je přechod přes 2NF.
- Odstraňte tranzitivní závislosti – rozdělte tabulku tak, aby každý neklíčový atribut závisel pouze na klíči dané tabulky.
- Ověřte, že po rozdělení jsou zachovány potřebné vazby (cizí klíče) a integrita dat.
Rozdíl mezi 3NF a BCNF
- BCNF (Boyce‑Codd Normal Form) je přísnější než 3NF. Vyžaduje, aby pro každou netriviální funkční závislost X → A byl X superklíč.
- 3NF dovoluje výjimku: A může být prime atribut (součást některého kandidátního klíče), i když X není superklíč. To znamená, že některé struktury, které splňují 3NF, nemusí splňovat BCNF.
Výhody a nevýhody použití 3NF
- Výhody: méně redundance dat, menší riziko nekonzistence, snazší údržba a aktualizace, lepší logická struktura dat.
- Nevýhody: více tabulek znamená více JOIN operací při dotazování, což může mít vliv na výkon v některých aplikacích; někdy je vhodné mírné denormalizace pro rychlost čtení.
Shrnutí
Třetí normální forma je praktické a dobře zavedené pravidlo normalizace, které odstraní tranzitivní závislosti mezi atributy a zajistí, že neklíčové atributy závisí přímo na klíči. Je důležitá pro návrh čistých, konzistentních relačních databází, přičemž v praxi je třeba zvážit i výkonní aspekty a případné kompromisy (např. denormalizace) podle potřeb aplikace.
Vyhledávání