Popis normalizace
Normalizace databáze je proces návrhu sloužící k uspořádání dané sady dat do tabulek a sloupců v databázi. Každá tabulka by měla obsahovat data týkající se konkrétní "věci" a obsahují pouze data, která podporují stejnou "věc" obsaženou v tabulce. Cílem tohoto procesu je snížit duplicitní data obsažená v databázi a snížit tak snížení výkonu vkládání a aktualizací databáze. Změna adresy zákazníka je například mnohem jednodušší implementovat, pokud je v tabulce Zákazníci uloženo jediné místo, kde je adresa zákazníka uložená. Nejběžnějšími formami normalizace jsou první, druhá a třetí normální forma a jsou popsány níže.
První normální formulář
První normální formulář má následující specifikace:
- Vytvoření samostatné tabulky pro každou sadu souvisejících dat
- Eliminace opakujících se skupin v jednotlivých tabulkách
- Identifikace každé sady souvisejících dat pomocí primárního klíče
V tomto modelu byste neměli používat více sloupců v jedné tabulce k ukládání podobných dat. Pokud například produkt může mít více barev, neměli byste mít v jednom řádku více sloupců obsahujících různé barevné hodnoty. První tabulka níže (ProductColors) není v první normální podobě, protože existují opakující se hodnoty pro barvu. U produktů s jedinou barvou je nevyužitý prostor. A co když produkt přišel ve více než třech barvách? Místo toho, abychom museli nastavit maximální počet barev, můžeme tabulku vytvořit znovu, jak je znázorněno ve druhé tabulce ProductColor. Máme také požadavek na první normální formu, že existuje jedinečný klíč tabulky, což je sloupec (nebo sloupce), jehož hodnota jednoznačně identifikuje řádek. Žádný ze sloupců ve druhé tabulce není jedinečný, ale kombinace IDproduktu a barvy je jedinečná. Pokud potřebujete více sloupců, nazýváme ho složený klíč.
| Productid | Barva 1 | Color2 | Barva 3 |
|---|---|---|---|
| 1 | Červený | Zelený | Yellow |
| 2 | Yellow | ||
| 3 | Modrý | Červený | |
| 4 | Modrý | ||
| 5 | Červený |
| Productid | Color (Barva) |
|---|---|
| 1 | Červený |
| 1 | Zelený |
| 1 | Yellow |
| 2 | Yellow |
| 3 | Modrý |
| 3 | Červený |
| 4 | Modrý |
| 5 | Červený |
Třetí tabulka ProductInfo je v prvním normálním formátu, protože každý řádek odkazuje na konkrétní produkt, neexistují žádné opakující se skupiny a máme sloupec Idproduktu, který se má použít jako primární klíč.
| Productid | Productname | Cena | ProductionCountry | Krátká poloha |
|---|---|---|---|---|
| 0 | Widget | 15.95 | USA | (USA) |
| 2 | Foop | 41.95 | Spojené království | Velká Británie |
| 3 | Glombit | 49.95 | Spojené království | Velká Británie |
| 4 | Sorfin | 99,99 | Filipínská republika | RepPhil |
| 5 | Šroub kmene | 29.95 | USA | (USA) |
Druhý normální formulář
Druhý normální formulář má kromě těch, které vyžadují první normální formulář, následující specifikaci:
- Pokud tabulka obsahuje složený klíč, musí všechny atributy záviset na úplném klíči a ne jenom na jeho části.
Druhý normální formulář je relevantní pouze pro tabulky se složenými klíči, například v tabulce ProductColor, což je druhá tabulka výše. Vezměte v úvahu případ, kdy tabulka ProductColor obsahuje také cenu produktu. Tato tabulka obsahuje složený klíč pro IDproduktu a barvu, protože pouze použití obou hodnot sloupců můžeme jednoznačně identifikovat řádek. Pokud se cena produktu nezmění barvou, můžeme vidět data, jak je znázorněno v této tabulce:
| Productid | Color (Barva) | Cena |
|---|---|---|
| 1 | Červený | 15.95 |
| 1 | Zelený | 15.95 |
| 1 | Yellow | 15.95 |
| 2 | Yellow | 41.95 |
| 3 | Modrý | 49.95 |
| 3 | Červený | 49.95 |
| 4 | Modrý | 99,95 |
| 5 | Červený | 29.95 |
Výše uvedená tabulka není ve druhé normální podobě. Hodnota ceny závisí na IDproduktu, ale ne na barvě. Pro IDproduktu 1 existují tři řádky, takže cena produktu se opakuje třikrát. Problém s porušením druhé normální formy je, že pokud musíme aktualizovat cenu, musíme se ujistit, že ji aktualizujeme všude. Pokud bychom aktualizovali cenu v prvním řádku, ale ne druhou nebo třetí, měli bychom něco, čemu se říká "aktualizační anomálie". Po aktualizaci bychom nemohli zjistit, jaká byla skutečná cena za ID produktu 1. Řešením je přesunout sloupec Price do tabulky, která má KÓD ProductID jako klíč s jedním sloupcem, protože to je jediný sloupec, na který cena závisí. K uložení ceny můžeme například použít tabulku 3.
Pokud se cena produktu liší na základě barvy, čtvrtá tabulka by byla ve druhé normální podobě, protože cena by závisela na obou částech klíče: IDProduktu a Barva.
Třetí normální formulář
Třetí normální forma je obvykle cílem většiny databází OLTP. Třetí normální formulář má kromě těch, které vyžadují druhý normální formulář, následující specifikaci:
- Všechny sloupce bez klíče jsou nepřenosné závislé na primárním klíči.
Přechodná relace znamená, že jeden sloupec v tabulce souvisí s jinými sloupci prostřednictvím druhého sloupce. Závislost znamená, že sloupec může v důsledku závislosti odvodit jeho hodnotu z jiné. Váš věk můžete například určit od data narození, takže váš věk závisí na vašem datu narození. Vraťte se k třetí tabulce ProductInfo. Tato tabulka je ve druhé normální podobě, ale ne ve třetí. Sloupec ShortLocation je závislý na sloupci ProductionCountry, což není klíč. Stejně jako druhá normální forma může porušení třetího normálního formuláře vést k aktualizaci anomálií. Pokud bychom aktualizovali ShortLocation na jednom řádku, ale neaktualizovali bychom je ve všech řádcích, kde došlo k umístění, skončíme nekonzistentními daty. Abychom tomu zabránili, můžeme vytvořit samostatnou tabulku pro ukládání názvů zemí a oblastí a jejich zkrácených formulářů.
Denormalizace
I když je třetí normální forma teoreticky žádoucí, není vždy možné pro všechna data. Normalizovaná databáze navíc ne vždy poskytuje nejlepší výkon. Normalizovaná data často vyžadují více operací spojení, aby se získala všechna potřebná data vrácená v jednom dotazu. Mezi normalizací dat existuje kompromis mezi normalizací dat, když počet spojení potřebných k vrácení výsledků dotazů má vysoké využití procesoru a denormalizovaná data, která mají méně spojení a méně požadovaných procesorů, ale otevírá možnost aktualizovat anomálie.
Poznámka:
Denormalizovaná data nejsou stejná jako nenormalizovaná. Pro denormalizaci začneme návrhem tabulek, které jsou normalizovány. Potom můžeme do některých tabulek přidat další sloupce, abychom snížili požadovaný počet spojení, ale jak to děláme, víme o možných anomáliích aktualizací. Pak se ujistěte, že máme triggery nebo jiné druhy zpracování, které zajistí, že při aktualizaci se aktualizují také všechna duplicitní data.
Denormalizovaná data mohou být efektivnější pro dotazování, zejména pro úlohy náročné na čtení, jako je datový sklad. V takových případech může mít další sloupce lepší vzory dotazů a/nebo více zjednodušených dotazů.
Hvězdicové schéma
I když je většina normalizace zaměřená na úlohy OLTP, datové sklady mají svou vlastní strukturu modelování, což je obvykle denormalizovaný model. Tento návrh používá tabulky faktů, které zaznamenávají měření nebo metriky pro konkrétní události, jako je prodej, a spojuje je s tabulkami dimenzí, které jsou menší z hlediska počtu řádků, ale mohou mít velký počet sloupců pro popis dat faktů. Mezi příklady dimenzí patří inventarizace, čas a/nebo zeměpisná oblast. Tento vzor návrhu se používá k usnadnění dotazování databáze a k zajištění zvýšení výkonu úloh čtení.
Výše uvedený obrázek ukazuje příklad hvězdicového schématu, včetně tabulky faktů FactResellerSales a dimenzí pro datum, měnu a produkty. Tabulka faktů obsahuje data související s prodejními transakcemi a dimenze obsahují pouze data související s konkrétním prvkem prodejních dat. Například tabulka FactResellerSales obsahuje pouze ProductKey, který označuje, který produkt se prodal. Všechny podrobnosti o jednotlivých produktech jsou uloženy v tabulce DimProduct a souvisí s tabulkou faktů se sloupcem ProductKey .
Souvisí s návrhem hvězdicového schématu je sněhové vločkové schéma, které používá sadu normalizovaných tabulek pro jednu obchodní entitu. Následující obrázek ukazuje příklad jedné dimenze pro schéma sněhové vločky. Dimenze Products je normalizována a uložena ve třech tabulkách s názvem DimProductCategory, DimProductSubcategory a DimProduct.
Hlavním rozdílem mezi hvězdicovým a sněhovým vločkovým schématem je, že rozměry ve schématu sněhové vločky jsou normalizovány, aby se snížila redundance, což šetří prostor úložiště. Nevýhodou je, že vaše dotazy vyžadují více spojení, což může zvýšit složitost a snížit výkon.