Popis Základy normalizace databáze v aplikaci Access 2000

Překlady článku Překlady článku
ID článku: 209534 - Produkty, které se vztahují k tomuto článku.
Začínajícího: Vyžaduje znalost uživatelského rozhraní v počítačích pro jednoho uživatele.

Aplikace Microsoft Access 97 verzi tohoto článku naleznete 100139.
Aplikace Microsoft Access 2002 verzi tohoto článku naleznete 283878.
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 také nabízí vysílání Rozebírá základy normalizace databáze. 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 o tomto tématu v dřívější verzi aplikace Access klepněte na následující číslo článku databáze Microsoft Knowledge Base:
100139Základy normalizace databáze

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 je "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í formě. „ Pokud je pozorované první pravidlo databáze je označováno být „ 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ÝJIMKY: Dodržení třetí normální forma, zatímco 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 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

Čtvrté normální forma Boyce Codd normální Form (BOYCE), nazývané také pátá normální forma neexistují, ale zřídka jsou považovány za v praktickém návrhu. 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.

Normalizace příklad tabulky

Tyto kroky demonstrují proces normalizace fiktivní student tabulky.
  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: Odstraňování 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: Odstraňování dat není závislý na klíč

    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

Odkazy

Ahlo M. uživatele Hamilton hodnotu Randy Brown a Peteru Colclough. FoxPro 2: průvodci výrobce: Poradce pokyny pro programování průmyslové šifrování. John Wiley & Sons, říjen 1991. 220 Stránek-225.

Jennings Roger. Použitím 1.1 pro Windows. Společnost Que 1993 červenec. Stránky 799-800.

Vlastnosti

ID článku: 209534 - Poslední aktualizace: 6. srpna 2004 - Revize: 2.2
Informace v tomto článku jsou určeny pro produkt:
  • Microsoft Access 2000 Standard Edition
Klíčová slova: 
kbmt kbdatabase kbdesign kbinfo kbusage KB209534 KbMtcs
Strojově přeložený článek
Důležité: Tento článek byl přeložen pomocí software společnosti Microsoft na strojový překlad, ne profesionálním překladatelem. Společnost Microsoft nabízí jak články přeložené překladatelem, tak články přeložené pomocí software na strojový překlad, takže všechny články ve Znalostní databázi (Knowledge Base) jsou dostupné v češtině. Překlad pomocí software na strojový překlad ale není bohužel vždy dokonalý. Obsahuje chyby ve skloňování slov, skladbě vět, nebo gramatice, podobně jako když cizinci dělají chyby při mluvení v češtině. Společnost Microsoft není právně zodpovědná za nepřesnosti, chyby nebo škody vzniklé chybami v překladu, nebo při použití nepřesně přeložených instrukcí v článku zákazníkem. Společnost Microsoft aktualizuje software na strojový překlad, aby byl počet chyb omezen na minimum.
Projděte si také anglickou verzi článku:209534

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