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