Základy normalizace databáze

Tento článek vysvětluje terminologii normalizace databází pro začátečníky. Základní pochopení této terminologie je užitečné při diskusi nad návrhem relační databáze.

Popis normalizace

Normalizace je proces uspořádání dat v databázi. Zahrnuje vytváření tabulek a vytváření relací mezi těmito tabulkami podle pravidel navržených jak k ochraně dat, tak k zajištění větší pružnosti databáze odstraněním redundance a nekonzistentních závislostí.

Redundantní data zbytečně plýtvají místem na disku a způsobují potíže s údržbou. Je-li nutné změnit data existující na více místech, je nutné je změnit přesně stejným způsobem ve všech umístěních. Změna adresy zákazníka je jednodušší implementovat, pokud jsou tato data uložená pouze v tabulce Zákazníci a nikde jinde v databázi.

Co znamená „nekonzistentní závislost“? I když je pro uživatele intuitivní hledat v tabulce Zákazníci adresu konkrétního zákazníka, nemusí mít smysl hledat tam plat zaměstnance, který ho volá. Plat zaměstnance se vztahuje nebo je závislý na daném zaměstnanci a proto by měl být přesunut do tabulky Zaměstnanci. Nekonzistentní závislosti mohou ztížit přístup k datům, protože cesta k nim může chybět nebo být neplatná.

Existuje několik pravidel pro normalizaci databáze. Každé pravidlo se nazývá "normální forma". Pokud je dodrženo první pravidlo, říká se, že databáze je v "první normální formě". Pokud jsou dodržena první tři pravidla, databáze se považuje za třetí normální formu. I když jsou možné jiné úrovně normalizace, třetí normální forma je považována za nejvyšší úroveň potřebnou pro většinu aplikací.

Stejně jako u mnoha formálních pravidel a specifikací ani scénáře z reálného světa neumožňují vždy dokonalé dodržování předpisů. Normalizace obecně vyžaduje další tabulky a někteří zákazníci to považují za nepohodlné. Rozhodnete-li se porušit jedno z prvních tří pravidel normalizace, ověřte, zda je vaše aplikace připravená na všechny problémy, ke kterým by mohlo dojít, například redundantní data a nekonzistentní závislosti.

Následující popisy obsahují příklady.

První normální forma

• Eliminujte opakující se skupiny v jednotlivých tabulkách.
• Vytvořte samostatnou tabulku pro každou sadu souvisejících dat.
• V každé sadě souvisejících dat definujte identifikaci prostřednictvím primárního klíče.

Nepoužívejte k ukládání podobných dat více polí v jedné tabulce. Chcete-li například sledovat skladovou položku, která může pocházet ze dvou možných zdrojů, může skladový záznam obsahovat dvě pole pro Kód dodavatele 1 a Kód dodavatele 2.

Co se stane, když přidáte třetího dodavatele? Přidání pole není odpověď. vyžaduje úpravy programů a tabulek a nepochází bez problémů s dynamickým počtem dodavatelů. Namísto toho umístěte všechny informace o dodavatelích do samostatné tabulky s názvem Dodavatelé. Poté vytvořte vazbu skladu na prodejce pomocí klíče čísla položky nebo vazbu dodavatelů na sklad pomocí klíče kódu dodavatele.

Druhá normální forma

• Vytvořte oddělené tabulky pro sady hodnot, které se týkají více záznamů.
• Vytvořte relace na tyto tabulky pomocí cizího klíče.

Záznamy by neměly záviset na ničem jiném než na primárním klíči tabulky (v případě potřeby na složený klíč). Uvažujme například adresu zákazníka v účetním systému. Tato adresa je potřebná v tabulce Zákazníci, ale také v tabulkách Objednávky, Doprava, Faktury, Pohledávky a Inkaso. Namísto uložení adresy zákazníka jako samostatné položky v každé z těchto tabulek uložte adresu na jednom místě, buď v tabulce Zákazníci, nebo v samostatné tabulce Adresy.

Třetí normální forma

• Odstraňte pole, která nezávisí na klíči.

Hodnoty v záznamu, které nejsou součástí klíče záznamu, nepatří do tabulky. Obecně lze říci, že kdykoli se obsah skupiny polí může týkat více než jednoho záznamu v tabulce, měli byste uvažovat o umístění těchto polí do samostatné tabulky.

Například v tabulce Nábor zaměstnanců může být u kandidáta uveden název univerzity a její adresa. Nicméně potřebujete úplný seznam univerzit, abyste mohli odesílat hromadnou poštu. Jsou-li informace o univerzitách uložené v tabulce Kandidáti, neexistuje žádný způsob, jak vytvořit seznam univerzit bez aktuálních kandidátů. Vytvořte oddělenou tabulku Univerzity a propojte ji s tabulkou Kandidáti pomocí klíče kódu univerzity.

VÝJIMKA: Dodržování třetí normální formy, i když je teoreticky žádoucí, není vždy praktické. Máte-li tabulku Zákazníci a chcete eliminovat všechny možné závislosti mezi poli, je nutné vytvořit samostatné tabulky pro města, PSČ, obchodní zástupce, třídy zákazníků a další faktory, u kterých může dojít ve více záznamech k duplikaci. Teoreticky je normalizace hodná. Mnoho malých tabulek může ovšem snížit výkon nebo překročit kapacitu paměti a otevřených souborů.

Může být proto vhodnější použít třetí normální formu pouze pro data, která se často mění. Pokud zůstanou nějaká závislá pole, navrhněte aplikaci tak, aby v případě změny jednoho pole po uživateli požadovala ověření všech souvisejících polí.

Další formy normalizace

Čtvrtá normální forma, označovaná také jako Boyce-Codd normální formulář (BCNF) a pátá normální forma existují, ale v praktickém návrhu se uváží jen zřídka. Ignorování těchto pravidel může vést k méně než dokonalému návrhu databáze, ale nemělo by to mít vliv na funkčnost.

Normalizace vzorové tabulky

Tyto kroky demonstrují proces normalizace fiktivní tabulky studentů.

1. Nenormalizovaná tabulka:

   Číslo studenta	Poradce	Kancelář poradce	Přednáška1	Přednáška2	Přednáška3
   1022	Dvořák	412	101-07	143-01	159-02
   4123	Novák	216	101-07	143-01	179-04

2. První normální forma: Žádné opakující se skupiny

   Tabulky by měly být pouze dvourozměrné. Jeden student má několik přednášek, a proto by tyto přednášky měly být uvedené v samostatné tabulce. Pole Přednáška1, Přednáška2, Přednáška3 v uvedených záznamech ukazují na potíže s návrhem.

   Tabulky často používají třetí dimenzi, ale tabulky by neměly. Dalším způsobem, jak se na tento problém podívat, je použít relaci 1:N, nevkládejte jednu stranu a strany N do stejné tabulky. Místo toho vytvořte další tabulku v první normální podobě odstraněním opakující se skupiny (Class#), jak je znázorněno v následujícím příkladu:

   Číslo studenta	Poradce	Kancelář poradce	Číslo přednášky
   1022	Dvořák	412	101-07
   1022	Dvořák	412	143-01
   1022	Dvořák	412	159-02
   4123	Novák	216	101-07
   4123	Novák	216	143-01
   4123	Novák	216	179-04

3. Druhá normální forma: Odstranění nadbytečných dat

   Všimněte si několika hodnot Class# pro každou hodnotu Student# ve výše uvedené tabulce. Class# není funkčně závislá na Student# (primární klíč), takže tato relace není ve druhé normální podobě.

   Následující dvě tabulky demonstrují druhou normální formu:

   Studenti:

   Číslo studenta	Poradce	Kancelář poradce
   1022	Dvořák	412
   4123	Novák	216

   Registrace:

   Číslo studenta	Číslo přednášky
   1022	101-07
   1022	143-01
   1022	159-02
   4123	101-07
   4123	143-01
   4123	179-04

4. Třetí normální forma: Odstranění dat, která nejsou závislá na klíči

   V posledním příkladu je pole Kancelář poradce (číslo kanceláře poradce) funkčně závislé na atributu Poradce. Řešením je přesunout tento atribut z tabulky Studenti do tabulky Fakulta, jak je ukázáno v následujícím příkladu:

   Studenti:

   Číslo studenta	Poradce
   1022	Dvořák
   4123	Novák

   Fakulta:

   Name (Název)	Místnost	Katedra
   Dvořák	412	42
   Novák	216	42