JAKÁ JE TŘETÍ NORMÁLNÍ FORMA? (DATABÁZE) - TECHNOLOGIE - 2025

Třetí normální forma (databáze) je relační databáze navrhnou postup, kdy se různé tabulky, které tvoří nejen v souladu s druhým normální formě, ale všechny jeho atributy nebo pole jsou přímo závislé na primárním klíči.

Při navrhování databáze je hlavním cílem vytvoření přesné reprezentace dat, vztahů mezi nimi a omezení příslušných dat.

Zdroj: pixabay.com

K dosažení tohoto cíle lze použít některé techniky návrhu databáze, mezi něž patří normalizace.

Jedná se o proces organizace dat v databázi, aby se zabránilo nadbytečnosti a možným anomáliím při vkládání, aktualizaci nebo eliminaci dat, čímž se vytvoří jednoduchý a stabilní návrh koncepčního modelu.

Začíná zkoumáním funkčního vztahu nebo závislosti mezi atributy. Popisují určitou vlastnost dat nebo vztah mezi nimi.

Normální tvary

Normalizace používá řadu testů, které se nazývají normální formy, které pomáhají identifikovat optimální seskupení těchto atributů a nakonec vytvořit příslušnou sadu vztahů, které podporují požadavky na údaje společnosti.

To znamená, že normalizační technika je postavena na konceptu normální formy, která definuje systém omezení. Pokud vztah splňuje omezení konkrétní normální formy, je tento vztah považován za vztah v této normální formě.

První normální forma (1FN)

Tabulka je označena jako 1FN, pokud všechny atributy nebo pole v ní obsahují pouze jedinečné hodnoty. To znamená, že každá hodnota pro každý atribut musí být nedělitelná.

Podle definice bude relační databáze vždy normalizována na první normální formu, protože hodnoty atributů jsou vždy atomové. Všechny vztahy v databázi jsou v 1FN.

Jednoduše opuštění databáze, jako je tato, však stimuluje řadu problémů, jako je nadbytečnost a možné selhání aktualizace. K vyřešení těchto problémů byly vyvinuty vyšší normální formy.

Druhá normální forma (2FN)

Zabývá se odstraněním kruhových závislostí z tabulky. O relaci se říká, že je ve 2FN, pokud je v 1FN a dále každé neklíčové pole nebo atribut závisí zcela na primárním klíči, nebo konkrétněji, zajišťuje, že tabulka má jediný účel.

Atribut bez klíče je jakýkoli atribut, který není součástí primárního klíče vztahu.

Třetí normální forma (3FN)

Zabývá se odstraňováním přechodných závislostí z tabulky. To znamená odebrat neklíčové atributy, které nezávisí na primárním klíči, ale na jiném atributu.

Transitivní závislost je typ funkční závislosti, ve kterém je hodnota neklíčového pole nebo atributu určena hodnotou jiného pole, které také není klíčové.

Měli byste hledat opakující se hodnoty v atributech jiných než klíčů, abyste se ujistili, že tyto klíčové atributy nezávisí na něčem jiném než na primárním klíči.

O atributech se říká, že jsou vzájemně nezávislé, pokud žádný z nich není funkčně závislý na kombinaci jiných. Tato vzájemná nezávislost zajišťuje, že atributy lze aktualizovat jednotlivě, aniž by hrozilo ovlivnění jiného atributu.

Proto, aby vztah v databázi měl třetí normální formu, musí splňovat:

- Všechny požadavky 2FN.

- Pokud existují atributy, které se netýkají primárního klíče, musí být odstraněny a umístěny do samostatné tabulky, která obě tabulky spojuje pomocí cizího klíče. To znamená, že by neměly existovat žádné přechodné závislosti.

Příklady třetí normální formy

Příklad 1

Nechť tabulka je STUDENT, jehož primárním klíčem je identifikace studenta (STUDENT_ID) a skládá se z následujících atributů: STUDENT_NAME, STREET, CITY a POST_CODE, splňující podmínky 2FN.

V tomto případě STREET a CITY nemají přímý vztah s primárním klíčem STUDENT_ID, protože se přímo netýkají studenta, ale jsou zcela závislé na poštovním směrovacím čísle.

Protože se student nachází podle místa určeného kódem CODE_POSTAL, souvisí s tímto atributem STREET a CITY. Vzhledem k tomuto druhému stupni závislosti není nutné tyto atributy ukládat do tabulky STUDENT.

Vytvořit novou tabulku

Předpokládejme, že existuje více studentů umístěných ve stejném PSČ, přičemž tabulka STUDENT má obrovské množství záznamů a je nutné změnit název ulice nebo města, tato ulice nebo město musí být nalezeno a aktualizováno v celé tabulce. STUDENT.

Pokud například potřebujete změnit ulici „El Limón“ na „El Limón II“, budete muset hledat „El Limón“ v celé tabulce STUDENT a poté ji aktualizovat na „El Limón II“.

Prohledávání velké tabulky a aktualizace jednotlivých nebo více záznamů bude časově náročné, a proto ovlivní výkon databáze.

Místo toho lze tyto podrobnosti uchovat v samostatné tabulce (POSTCARD), která souvisí s tabulkou STUDENT pomocí atributu POST_CODE.

Tabulka POST bude mít relativně méně záznamů a tato tabulka POST bude muset být aktualizována pouze jednou. To se automaticky projeví v tabulce STUDENT, což zjednoduší databázi a dotazy. Tabulky tedy budou ve 3FN:

Příklad 2

Nechte následující tabulku použít s polem Project_Num jako primární klíč a s opakovanými hodnotami v atributech, které nejsou klíči.

Hodnota Telefon se opakuje pokaždé, když se opakuje jméno manažera. Důvodem je, že telefonní číslo závisí pouze na druhém čísle projektu od čísla projektu. Nejprve to záleží na manažerovi, a to zase na čísle projektu, což způsobuje přechodnou závislost.

Atribut Project_Manager nemůže být možným klíčem v tabulce Projekty, protože stejný správce spravuje více než jeden projekt. Řešením je odebrání atributu s opakovanými daty (Telefon), vytvoření samostatné tabulky.

Odpovídající atributy musí být seskupeny dohromady a vytvořit novou tabulku pro jejich uložení. Data jsou zadána a je ověřeno, že opakované hodnoty nejsou součástí primárního klíče. Primární klíč se nastavuje pro každou tabulku a v případě potřeby se přidávají cizí klíče.

Pro splnění třetího normálního formuláře je vytvořena nová tabulka (Managers), která tento problém vyřeší. Obě tabulky jsou propojeny prostřednictvím pole Project_Manager:

Reference

1. Teradata (2019). První, druhý a třetí normální formulář. Převzato z: docs.teradata.com.
2. Tutorial Cup (2019). Třetí normální forma (3NF). Převzato z: tutorialcup.com.
3. Databáze Dev (2015). Třetí normální formulář (3NF) - normalizace databáze. Převzato z: databasedev.co.uk.
4. Návrh relační databáze (2019). Úvod do třetího normálního formuláře. Převzato z: relationshipaldbdesign.com.
5. Dummies (2019). První, druhý a třetí normální formulář SQL. Převzato z: dummies.com.