Skip to main content

Vložení databáze do druhého normálního formuláře (2NF)

108 - Normalizace - Dějiny udatného českého národa (Smět 2024)

108 - Normalizace - Dějiny udatného českého národa (Smět 2024)
Anonim

Podívali jsme se na několik aspektů normalizace tabulky databáze. Nejprve jsme diskutovali o základních principech normalizace databáze. Naposledy jsme zkoumali základní požadavky stanovené prvním normálním formulářem (1NF). Nyní pokračujte v naší cestě a pokryte zásady druhé normální formy (2NF).

Obecné požadavky 2NF

  • Odebrat podmnožiny dat, které se vztahují k více řádkům tabulky, a umístit je do samostatných tabulek.
  • Vytvořte vztahy mezi těmito novými tabulkami a jejich předchůdci pomocí cizích klíčů.

Tato pravidla lze shrnout do jednoduchého příkazu: 2NF se snaží snížit množství redundantních dat v tabulce tím, že je extrahuje, umístí je do nových tabulek a vytváří vztahy mezi těmito tabulkami.

Podívejme se na příklad. Představte si internetový obchod, který uchovává informace o zákaznících v databázi. Mohou mít jednu tabulku s názvem Zákazníci s následujícími prvky:

  • CustNum
  • Jméno
  • Příjmení
  • Adresa
  • Město
  • Stát
  • ZIP

Stručný pohled na tuto tabulku odhaluje malé množství redundantních dat. Ukládáme položky "Sea Cliff, NY 11579" a "Miami, FL 33157" dvakrát. Nyní by se nám v našem jednoduchém příkladu nemuselo zdát příliš mnoho přidaných úložišť, ale představte si, že bychom měli zbytečný prostor, kdybychom měli v našem stole tisíce řádků. Navíc, pokud se změní poštovní směrovací číslo pro Sea Cliff, je třeba tuto změnu provést na mnoha místech v celé databázi.

Ve struktuře databáze kompatibilní s 2NF jsou tyto nadbytečné informace extrahovány a uloženy v samostatné tabulce. Naše nová tabulka (nazýváme ji ZIP) může mít následující pole:

  • ZIP
  • Město
  • Stát

Chceme-li být super-efektivní, můžeme tuto tabulku dopředu vyplnit - pošta poskytuje seznam všech platných PSČ a jejich vztahů mezi městy a státem. Určitě jste narazili na situaci, kdy byl tento typ databáze využit. Někdo, kdo přijal objednávku, vás mohl nejprve požádat o váš PSČ a poté znali město a stát, od kterého jste volali. Tento typ uspořádání snižuje chybu obsluhy a zvyšuje účinnost.

Po odstranění duplicitních dat z tabulky Zákazníci jsme splnili první pravidlo druhého normálního formuláře. Stále ještě potřebujeme použít cizí klíč, abychom spojili obě tabulky dohromady. K vytvoření tohoto vztahu použijeme PSČ (primární klíč z tabulky ZIP). Zde je tabulka našich nových zákazníků:

  • CustNum
  • Jméno
  • Příjmení
  • Adresa
  • ZIP

Nyní jsme minimalizovali množství redundantních informací uložených v databázi a naše struktura je v druhé normální podobě.