Základy normalizace databáze

Překlady článku Překlady článku
ID článku: 283878 - Produkty, které se vztahují k tomuto článku.
Začátečníci: Je nutná znalost uživatelského rozhraní v počítačích pro jednoho uživatele.

Verzi tohoto článku pro aplikaci Microsoft Access 2000 naleznete pod číslem 209534 (Tento článek může obsahovat odkazy na anglický obsah (dosud nepřeložený).).
Verzi tohoto článku pro aplikaci Microsoft Access 95 nebo Microsoft Access 97 naleznete pod číslem 100139 (Tento článek může obsahovat odkazy na anglický obsah (dosud nepřeložený).).
Rozbalit všechny záložky | Minimalizovat všechny záložky

Na této stránce

Souhrn

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.

POZNÁMKA: Společnost Microsoft nabízí také webové vysílání, kde jsou diskutovány základy normalizace databází. Chcete-li toto webové vysílání shlédnout, navštivte následující web společnosti Microsoft:
http://support.microsoft.com/servicedesks/webcasts/wc060600/wc060600.asp?fr=1

Další informace

Popis normalizace

Normalizace je proces uspořádání dat v databázi. Patří sem vytváření tabulek a vztahů mezi nimi podle pravidel navržených za účelem ochrany dat a za účelem vytvoření pružnější databáze odstraněním redundance a nekonzistentní závislosti.

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. Je mnohem snazší implementovat změnu adresy zákazníka v případě, že jsou příslušná data uložena pouze v tabulce Zákazníci a nikde jinde v databázi.

Co znamená „nekonzistentní závislost“? Zatímco je pro uživatele intuitivní hledat adresu určitého zákazníka v tabulce Zákazníci, asi by ho nenapadlo hledat v této tabulce plat zaměstnance, který má daného zákazníka na starosti. 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.“ Je-li splněno první pravidlo, říkáme, že databáze je v „první normální formě.“ Jsou-li splněna první tři pravidla, říkáme, že databáze je ve „třetí normální formě.“ Přestože jsou možné ještě další úrovně normalizace, třetí normální forma je považována za nejvyšší úroveň nutnou pro většinu aplikací.

Stejně jako u mnoha formálních pravidel i specifikací nelze v situacích z reálného světa vždy zajistit dokonalou shodu. 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 více polí v jedné tabulce k uložení podobných dat. 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í řešení. Vyžaduje to úpravy programu a tabulky a nelze bezproblémově začlenit dynamický počet 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ě nutnosti na složeném klíči). 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

  • Eliminujte pole, která nezávisí na klíči.
Do tabulky nepatří hodnoty v záznamu, které nejsou součástí klíče záznamu. 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: Ačkoli dodržení třetí normální formy může být teoreticky žádoucí, není to 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 vhodné usilovat o normalizaci. 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

Existuje také čtvrté normální forma, označovaná také jako BCNF (Boyce Codd Normal Form), a také pátá normální forma, ty jsou ovšem při praktickém návrhu zvažovány jen zřídka. Nepřihlížení k těmto pravidlům může vést k poněkud méně dokonalému návrhu databáze, ale nemělo by ovlivnit funkčnost.

Příklad normalizace tabulky

Tyto kroky demonstrují proces normalizace fiktivní tabulky studentů.
  1. Nenormalizovaná tabulka:

    Zmenšit tuto tabulkuRozšířit tuto tabulku
    Číslo studentaPoradceKancelář poradcePřednáška1Přednáška2Přednáška3
    1022Dvořák412101-07143-01159-02
    4123Novák216201-01211-02214-01
  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.

    Tabulkové procesory obvykle používají třetí rozměr, ale databázové tabulky by neměly. Další možností pohledu na tento problém je vztah jednoho prvku k více prvkům. Neumísťujte do jedné tabulky jeden prvek na jedné a mnoho prvků na druhé straně. Vytvořte místo toho další tabulku v první normální formě tím, že eliminujete opakující se skupinu (Číslo přednášky), jak vidíte v následujícím příkladu:

    Zmenšit tuto tabulkuRozšířit tuto tabulku
    Číslo studentaPoradceKancelář poradceČíslo přednášky
    1022Dvořák412101-07
    1022Dvořák412143-01
    1022Dvořák412159-02
    4123Novák216201-01
    4123Novák216211-02
    4123Novák216214-01
  3. Druhá normální forma: Eliminujte redundantní data

    Všimněte si, že u každé hodnoty Číslo studenta je více hodnot Číslo přednášky. Pole Číslo přednášky není funkčně závislé na poli Číslo studenta (primární klíč), takže tento vztah není v druhé normální formě.

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

    Studenti:

    Zmenšit tuto tabulkuRozšířit tuto tabulku
    Číslo studentaPoradceKancelář poradce
    1022Dvořák412
    4123Novák216


    Registrace:

    Zmenšit tuto tabulkuRozšířit tuto tabulku
    Číslo studentaČíslo přednášky
    1022101-07
    1022143-01
    1022159-02
    4123201-01
    4123211-02
    4123214-01
  4. Třetí normální forma: Eliminujte data, která nezávisí 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:

    Zmenšit tuto tabulkuRozšířit tuto tabulku
    Číslo studentaPoradce
    1022Dvořák
    4123Novák


    Fakulta:

    Zmenšit tuto tabulkuRozšířit tuto tabulku
    NázevMístnostKatedra
    Dvořák41242
    Novák21642

Vlastnosti

ID článku: 283878 - Poslední aktualizace: 8. května 2007 - Revize: 6.4
Informace v tomto článku jsou určeny pro produkt:
  • Microsoft Office Access 2007
  • Microsoft Office Access 2003
  • Microsoft Access 2002 Standard Edition
Klíčová slova: 
kbinfo kbdesign kbdatabase kbhowto KB283878

Dejte nám zpětnou vazbu

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com