Normalizace je technika návrhu databáze, která se používá k návrhu relační databázové tabulky až do vyšší normální formy. Tento proces je progresivní a vyšší úrovně normalizace databáze nelze dosáhnout, dokud nebudou splněny předchozí úrovně.
To znamená, že mít data v nenormalizované formě (nejméně normalizovaná) a zaměřená na dosažení nejvyšší úrovně úroveň normalizace, prvním krokem by bylo zajistit shodu s první normální formou, druhým krokem by bylo zajistit, aby byla splněna druhá normální forma, a tak dále v pořadí uvedeném výše, dokud data neodpovídají šesté normální formě.
Je však třeba poznamenat, že normální formy nad 4NF jsou hlavně akademického zájmu, protože problémy, které existují k řešení, se v praxi objevují jen zřídka.
Upozorňujeme, že údaje v následujícím příkladu byly záměrně navržen tak, aby odporoval většině běžných forem. V reálném životě je docela možné být schopen přeskočit některé normalizační kroky, protože tabulka neobsahuje nic, co by odporovalo dané normální formě. Také se běžně stává, že oprava narušení jedné normální formy také opraví narušení vyšší normální formy v procesu. Pro každý krok byla pro normalizaci vybrána také jedna tabulka, což znamená, že na konci tohoto příkladu mohou stále existovat některé tabulky, které nesplňují nejvyšší normální formu.
Počáteční dataEdit
Nechte databázovou tabulku s následující strukturou:
| Název | Autor | Autor Národnost | Formát | Cena | Předmět | Stránky | Tloušťka | Vydavatel | Země vydavatele | Typ publikace | ID žánru | Název žánru |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Začátek návrhu a optimalizace databáze MySQL | Chad Russell | americký | vázaná kniha | 49,99 | MySQL,
databáze, design |
520 | Silný | Apress | USA | E-kniha | 1 | Výukový program |
V tomto příkladu předpokládáme, že každá kniha má pouze jednoho autora.
Uspokojující 1NFEdit
K uspokojení 1NF musí být hodnoty v každém sloupci tabulky atomové. V počáteční tabulce předmět obsahuje sadu hodnot předmětu, což znamená, že není v souladu.
Jedním ze způsobů, jak dosáhnout 1NF, by bylo oddělit duplicity do více sloupců pomocí opakujících se skupin Předmět:
| Název | Formát | Autor | Autor Státní příslušnost | Cena | Předmět 1 | Předmět 2 | Předmět 3 | Stránky | Tloušťka | Vydavatel | Země vydavatele | ID žánru | Název žánru |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Zahájení návrhu a optimalizace databáze MySQL | Vázaná vazba | Chad Russell | Američan | 49,99 | MySQL | Databáze | Návrh | 520 | Silný | Apress | USA | 1 | Výukový program |
Ačkoli nyní tabulka formálně vyhovuje 1NF (je atomová), problém s tímto řešením je zřejmý – pokud kniha má více než tři předměty, nelze ji přidat do databáze, aniž by se změnila její struktura.
K vyřešení problému elegantnějším způsobem je nutné identifikovat entity zastoupené v tabulce a oddělit je do svých příslušných tabulek. V tomto případě by to mělo za následek tabulky Book, Subject a Publisher:
| Název | Formát | Autor | Autor Národnost | Cena | Stránky | Thickness | Genre ID | Genre Name | Publisher ID |
|---|---|---|---|---|---|---|---|---|---|
| Beginning MySQL Návrh a optimalizace databáze | Vázaná vazba | Chad Russell | Američan | 49.99 | 520 | Silný | 1 | Výukový program | 1 |
|
|
Pouhé rozdělení počátečních dat do více tabulek by přerušilo spojení mezi daty. To znamená, že je třeba určit vztahy mezi nově zavedenými tabulkami. Všimněte si, že sloupec ID vydavatele v tabulce Knihy je cizí klíč, který realizuje vztah typu jedna ku jedné mezi knihou a vydavatelem.
Kniha se vejde na mnoho předmětů, stejně jako na předmět odpovídá mnoha knihám. To znamená, že je také třeba definovat vztah mnoha lidí, kterého lze dosáhnout vytvořením tabulky odkazů:
|
Místo jedné tabulky v normalizované podobě nyní existují 4 tabulky vyhovující 1NF.
Uspokojující 2NFEdit
Tabulka Book má jeden kandidátský klíč (který je tedy primárním klíčem), složený klíč {Title, Format}. Zvažte následující fragment tabulky:
| Název | Formát | Autor | Autor Národnost | Cena | Stránky | Tloušťka | Genre ID | Genre Name | Publisher ID |
|---|---|---|---|---|---|---|---|---|---|
| Beginning MySQL Database Design and Optimization | Pevná vazba | Chad Russell | americký | 49,99 | 520 | silný | 1 | Výukový program | 1 |
| Zahájení návrhu a optimalizace databáze MySQL | E-kniha | Chad Russell | americký | 22,34 | 520 | silný | 1 | Výukový program | 1 |
| Relační model pro správu databáze: Verze 2 | E-kniha | EFCodd | britský | 13,88 | 538 | silný | 2 | Populární věda | 2 |
| Relační model pro databázi Ma nagement: Verze 2 | Brožovaná vazba | EFCodd | Britská | 39,99 | 538 | Silný | 2 | Populární věda | 2 |
Všechny atributy, které nejsou součástí kandidátského klíče, závisí na názvu, ale pouze cena závisí na formátu. Abyste vyhověli 2NF a odstranili duplicity, musí každý atribut jiného než kandidátského klíče záviset na celém kandidátském klíči, nejen na jeho části.
Chcete-li tuto tabulku normalizovat, udělejte z {Title} (jednoduchý) kandidátský klíč (primární klíč), takže každý atribut, který není kandidátským klíčem, závisí na celém kandidátském klíči, a odeberte Price do samostatné tabulky, aby bylo možné zachovat jeho závislost na formátu:
|
|
Nyní, tabulka Book odpovídá 2NF.
Uspokojující 3NFEdit
Tabulka Book má stále přechodnou funkční závislost ({Author Nationality} je závislá na {Author}, která je závislá na {Title }). Podobné narušení existuje pro žánr ({Genre Name} je závislý na {Genre ID}, který je závislý na {Title}). Tabulka Book proto není v 3NF. Abychom se dostali do 3NF, použijme následující strukturu tabulky, čímž odstraníme přechodné funkční závislosti umístěním {Author Nationality} a {Genre Name} do jejich vlastních příslušných tabulek:
| Název | Autor | Stránky | Tloušťka | ID žánru | ID vydavatele |
|---|---|---|---|---|---|
| Začátek návrhu databáze MySQL a Optimalizace | Chad Russell | 520 | Silný | 1 | 1 |
| Relační model pro správu databáze: verze 2 | EFCodd | 538 | tlustý | 2 | 2 |
|
| Autor | Autor Národnost |
|---|---|
| Chad Russell | americký |
| EFCodd | britský |
| Gen re ID | Název žánru |
|---|---|
| 1 | Výukový program |
| 2 | Populární věda |
Vyhovující EKNFEdit
Normální forma elementárního klíče (EKNF) spadá striktně mezi 3NF a BCNF a není v literatuře příliš diskutována. Je zamýšleno „zachytit hlavní vlastnosti jak 3NF, tak BCNF“ a zároveň se vyhnout problémům obou (konkrétně to, že 3NF je „příliš odpouštějící“ a BCNF je „náchylný k výpočetní složitosti“). Jelikož je to v literatuře zmiňováno jen zřídka, v tomto příkladu není zahrnuta.
Uspokojující 4NFEdit
Předpokládejme, že databázi vlastní franšíza maloobchodů s knihami, která má několik franšízantů, kteří vlastní obchody na různých místech.A proto se maloobchodník rozhodl přidat tabulku obsahující údaje o dostupnosti knih na různých místech:
| ID franchisanta | Název | Umístění |
|---|---|---|
| 1 | Zahájení návrhu a optimalizace databáze MySQL | Kalifornie |
| 1 | Zahájení návrhu a optimalizace databáze MySQL | Florida |
| 1 | Zahájení návrhu a optimalizace databáze MySQL | Texas |
| 1 | Relační model pro správu databáze: verze 2 | Kalifornie |
| 1 | Relační model pro správu databáze: verze 2 | Florida |
| 1 | relační model pro správu databáze: verze 2 | Texas |
| 2 | Začátek návrhu a optimalizace databáze MySQL | Kalifornie |
| 2 | Zahájení návrhu a optimalizace databáze MySQL | Florida |
| 2 | Počínaje návrhem a optimalizací databáze MySQL | Texas |
| 2 | Relační model pro správu databáze: verze 2 | Kalifornie |
| 2 | Relační model pro správu databáze: Verze 2 | Florida |
| 2 | Relační model pro správu databáze: verze 2 | Texas |
| 3 | Zahájení návrhu a optimalizace databáze MySQL | Texas |
Jelikož tato struktura tabulky sestává ze složeného primárního klíče, neobsahuje žádné neklíčové atributy a je již v BCNF (a proto také splňuje všechny předchozí normální formy). Pokud však předpokládáme, že všechny dostupné knihy jsou nabízeny v každé oblasti, můžeme si všimnout, že nadpis není jednoznačně vázán na určité místo, a proto tabulka nevyhovuje 4NF.
To znamená, že k uspokojení čtvrté normální formy je třeba rozložit i tuto tabulku:
|
|
||||||||||||
| ID franšízy | umístění | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Kalifornie | ||||||||||||
| 1 | Florida | ||||||||||||
| 1 | Texas | ||||||||||||
| 2 | Kalifornie | ||||||||||||
| 2 | Florida | ||||||||||||
| 2 | Texas | ||||||||||||
| 3 | Texas |
Každý záznam je nyní jednoznačně identifikován superklíčem, proto je 4NF uspokojeno.
Vyhovující ETNFEdit
Předpokládejme, že franšízanti mohou také objednávat knihy od různých dodavatelů. Nechte vztah rovněž podléhat následujícímu omezení:
- Pokud určitý dodavatel dodává určitý titul
- a titul je dodáván franšízantovi
- a poskytovatel franšízy je dodáván dodavatelem,
- poté dodavatel dodává vlastníkovi franšízy.
| ID dodavatele | Název | ID franchisanta |
|---|---|---|
| 1 | Začátek návrhu a optimalizace databáze MySQL | 1 |
| 2 | Relační model pro správu databáze: verze 2 | 2 |
| 3 | Výuka SQL | 3 |
Tato tabulka je ve formátu 4NF, ale ID dodavatele se rovná spojení jejích projekcí: {{ID dodavatele, Kniha}, {Kniha, ID franchisanta}, {Franchisee ID, Dodavatel ID}}.Žádná součást této závislosti na spojení není superklíčem (jediným superklíčem je celý nadpis), takže tabulka nesplňuje ETNF a lze ji dále rozložit:
|
|
|
Rozklad vytváří soulad s ETNF.
Uspokojuje 5NFEdit
Chcete-li zjistit tabulku, která nesplňuje 5NF, použijte je obvykle nutné údaje důkladně prozkoumat. Předpokládejme tabulku z příkladu 4NF s malou úpravou dat a nechme ji zkontrolovat, zda vyhovuje 5NF:
| ID franšízy | Název | Umístění |
|---|---|---|
| 1 | Zahájení návrhu a optimalizace databáze MySQL | Kalifornie |
| 1 | Učení SQL | Kalifornie |
| 1 | Relační model pro správu databáze: Verze 2 | Texas |
| 2 | Relační model pro správu databáze: verze 2 | Kalifornie |
Pokud tuto tabulku rozložíme, snížíme redundanci a dostaneme následující dvě tabulky:
|
|
Co se stane, když se pokusíme tyto tabulky spojit? Dotaz vrátí následující data:
| ID franchisanta | Název | Umístění |
|---|---|---|
| 1 | Začátek návrhu databáze MySQL a Optimalizace | Kalifornie |
| 1 | Učení SQL | Kalifornie |
| 1 | Relační model pro správu databáze: verze 2 | Kalifornie |
| 1 | Relační model pro správu databáze: Verze 2 | Texas |
| 1 | Učení SQL | Texas |
| 1 | Zahájení návrhu a optimalizace databáze MySQL | Texas |
| 2 | Relační model pro správu databáze: verze 2 | Kalifornie |
JOIN podle všeho vrací další tři řádky, než by měl – zkusme přidat ano k objasnění vztahu.Nakonec skončíme se třemi samostatnými tabulkami:
|
|
|
Co nyní vrátí JOIN? Ve skutečnosti není možné se k těmto třem stolům připojit. To znamená, že nebylo možné rozložit franšízy – umístění knihy bez ztráty dat, proto tabulka již vyhovuje 5NF.
CJ Date tvrdil, že pouze databáze v 5NF je skutečně „normalizována“.
Uspokojující DKNFEdit
Pojďme se podívat na tabulku Book z předchozích příkladů a zjistit, zda splňuje normální formu Domain-key:
| Název | Stránky | Tloušťka | ID žánru | ID vydavatele | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Začátek návrhu a optimalizace databáze MySQL | 520 | Silný | 1 | 1 | ||||||||||||||||||||||||||
| Relační model pro správu databáze: Verze 2 | 538 | tlustý | 2 | 2 | ||||||||||||||||||||||||||
| výuka SQL | 338 | Tenký | 1 | 3 | ||||||||||||||||||||||||||
| SQL Cookbook | 636 | Silný | 1 | 3 |
|
|
Tímto způsobem bylo odstraněno narušení integrity domény a tabulka je v DKNF.
Uspokojující 6NFEdit
Jednoduchá a intuitivní definice šesté normální formy je, že „tabulka je v 6NF, když řádek obsahuje primární klíč a nejvýše jeden další atribut“.
To znamená například tabulku Publisher navrženou při vytváření 1NF
| ID vydavatele | Název | Země |
|---|---|---|
| 1 | Apress | USA |
musí být dále rozloženo na dvě tabulky:
|
|
Zjevnou nevýhodou 6NF je množení tabulek potřebných k reprezentaci informací o jedné entitě. Pokud má tabulka v 5NF jeden sloupec primárního klíče a N atributů, bude představování stejných informací v 6NF vyžadovat N tabulek; aktualizace více polí k jednomu koncepčnímu záznamu budou vyžadovat aktualizace více tabulek; a vkládání a mazání bude podobně vyžadovat operace napříč více tabulkami. Z tohoto důvodu by se v databázích určených pro potřeby online zpracování transakcí nemělo používat 6NF.
Nicméně v datových skladech, které neumožňují interaktivní aktualizace a které se specializují na rychlý dotaz na velké objemy dat. určité DBMS používají interní reprezentaci 6NF – známou jako sloupcový datový sklad. V situacích, kdy je počet jedinečných hodnot sloupce mnohem menší než počet řádků v tabulce, umožňují úložiště orientované na sloupce významné úspory prostoru díky kompresi dat. Sloupcové úložiště také umožňuje rychlé provádění dotazů na rozsah (např. Zobrazit všechny záznamy, kde je konkrétní sloupec mezi X a Y nebo menší než X).
Ve všech těchto případech však návrhář databáze muset provést normalizaci 6NF ručně vytvořením samostatných tabulek. Některé DBMS, které se specializují na skladování, jako je Sybase IQ, používají ve výchozím nastavení sloupcové úložiště, ale návrhář stále vidí pouze jednu vícesloupcovou tabulku. Jiné systémy DBMS, například Microsoft SQL Server 2012 a novější, umožňují určit „index úložiště sloupců“ pro konkrétní tabulku.
