ACC: Základy normalizace databáze

Překlady článku Překlady článku
ID článku: 100139 - 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.

Rozbalit všechny záložky | Minimalizovat všechny záložky

Na této stránce

Souhrn

Tento článek vysvětluje základy terminologii normalizace databází. 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
Poznámka: zobrazení pro Microsoft Access 2000 tyto informace naleznete následujícím článku databáze Microsoft Knowledge Base:
209534ACC2000: Základy normalizace databáze

Další informace

Popis normalizace

Normalizace je proces uspořádání dat v databázi. To zahrnuje vytvoření tabulek a stanovení vztahů mezi tyto tabulky podle pravidel navrženy k ochraně dat a vytvoření pružnější databáze podle vyloučení dva faktory: 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 obtížné dat přístup; cestu najít data může být chybějící nebo poškozený.

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.

Poznámka: následujících popisů zahrnují 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.

Ale 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 normalizace stojí pursuing; však mnoho malých tabulek může snížit výkon nebo překročit kapacitu paměti a otevření souboru.

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í.

Ostatní normalizace formulářů

Č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.
               **********************************
                 Examples of Normalized Tables
               **********************************

 Normalization Examples:

 Unnormalized table:

    Student#   Advisor   Adv-Room  Class1   Class2   Class3
    -------------------------------------------------------
    1022       Jones      412      101-07   143-01   159-02
    4123       Smith      216      201-01   211-02   214-01
				
  1. První normální forma: Ne REPEATING SKUPIN

    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 Class1, Přednáška2, & Class3 výše záznamu jsou uvedeno návrhu potíže.

    Tabulkové procesory obvykle používají třetí rozměr, ale databázové tabulky by neměly. Jiným způsobem prohlédněte tento problém: s n, nevkládejte jedné straně a strana n ve stejné tabulce. Místo toho vytvořit jinou tabulku v první normální formě podle vyloučení skupinu s opakováním (třídy #), jak je ukázáno níže:
           Student#   Advisor   Adv-Room    Class#
           ---------------------------------------
           1022      Jones      412       101-07
           1022      Jones      412       143-01
           1022      Jones      412       159-02
           4123      Smith      216       201-01
           4123      Smith      216       211-02
           4123      Smith      216       214-01
    					
  2. 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:
        Students:   Student#    Advisor   Adv-Room
                    ------------------------------
                    1022        Jones       412
                    4123        Smith       216
    
        Registration:   Student#    Class#
                        ------------------
                        1022        101-07
                        1022        143-01
                        1022        159-02
                        4123        201-01
                        4123        211-02
                        4123        214-01
    					
  3. Třetí normální forma: Odstranění dat NOT ZÁVISLÉ ON KEY

    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 níže:
        Students:   Student#    Advisor
                    -------------------
                    1022        Jones
                    4123        Smith
    
        Faculty:    Name    Room    Dept
                    --------------------
                    Jones   412     42
                    Smith   216     42
    					

Odkazy

Další informace o návrhu databáze klepněte na článek číslo článku databáze Microsoft Knowledge Base:
234208ACC2000: "Princip návrhu relační databáze" dokument dostupné v Centru pro stahování
"FoxPro 2 A Developer's Guide, uživatele Hamilton hodnotu M. Ahlo Jr. et al. stránek 1991 220-225 knihy M & T

"Pomocí Access pro Windows," Roger Jennings stránek 799-800 Que Corporation 1993

Vlastnosti

ID článku: 100139 - Poslední aktualizace: 18. ledna 2007 - Revize: 2.1
Informace v tomto článku jsou určeny pro produkt:
  • Microsoft Access 1.0 Standard Edition
  • Microsoft Access 1.1 Standard Edition
  • Microsoft Access 2.0 Standard Edition
  • Microsoft Access 95 Standard Edition
  • Microsoft Access 97 Standard Edition
Klíčová slova: 
kbmt kbinfo kbusage KB100139 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:100139
Právní omezení pro obsah znalostní báze týkající se produktů, jejichž podpora byla ukončena
Tento článek byl napsán o produktech, pro které společnost Microsoft již neposkytuje nadále podporu. Článek je tedy nabízen v takovém stavu, v jakém je, a nebude již nadále aktualizován.

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