Teď jste offline a čekáte, až se znova připojí internet.

Základy normalizace databáze

Podpora Office 2003 byla ukončena.

Společnost Microsoft ukončila dne 8. dubna 2014 podporu Office 2003. Tato změna ovlivnila aktualizace softwaru a možnosti zabezpečení. Další informace o tom, co to pro vás znamená a jak zajistit ochranu

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ý).).
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:
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:

    Čí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:

    Čí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:

    Číslo studentaPoradceKancelář poradce
    1022Dvořák412
    4123Novák216


    Registrace:

    Čí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:

    Číslo studentaPoradce
    1022Dvořák
    4123Novák


    Fakulta:

    NázevMístnostKatedra
    Dvořák41242
    Novák21642
BCNF relational normal model normalize ACC2002 ACC2003
Vlastnosti

ID článku: 283878 - Poslední kontrola: 05/08/2007 08:42:27 - Revize: 6.4

Microsoft Office Access 2007, Microsoft Office Access 2003, Microsoft Access 2002 Standard Edition

  • kbinfo kbdesign kbdatabase kbhowto KB283878
Váš názor
html>vaScript" async=""> var varAutoFirePV = 1; var varClickTracking = 1; var varCustomerTracking = 1; var Route = "76500"; var Ctrl = ""; document.write(" col-xs-24 ng-scope"> Paraguay - Español
Venezuela - Español
0&did=1&t=">did=1&t="> >>ow.location.protocol) + "//c.microsoft.com/ms.js'><\/script>"); >