Popis normalizácia základy databázy v programe Access 2000

Preklady článku Preklady článku
ID článku: 209534 - Zobraziť produkty, ktorých sa tento článok týka.
Začiatočník: Vyžaduje vedomosti o používateľského rozhrania na jedného používateľa počítače.

Microsoft Access 97 verziu tohto článku, pozri 100139.
Pre program Microsoft Access verziu 2002 tohto článku, pozri 283878.
Rozbaliť všetko | Zbaliť všetko

Na tejto stránke

SUHRN

Tento článok vysvetľuje databázy normalizácia terminológia pre začiatočníkov. Základné znalosti o tejto terminológia je užitočné, keď diskutuje o návrhu relačnej databázy.

POZNÁMKA: Microsoft taktiež ponúka WebCast, že diskutuje základy Normalizácia. Zobraziť tento WebCast, navštívte prosím nasledujúce Webovú lokalitu spoločnosti Microsoft:
http://support.Microsoft.com/servicedesks/webcasts/wc060600/wc060600.asp?FR=1
Ďalšie informácie o tejto téme v staršej verzii programu Access, kliknite na tlačidlo nasledujúci článok číslo článku databázy Microsoft Knowledge Base:
100139Normalizácia základy databázy

DALSIE INFORMACIE

Popis normalizácia

Normalizácia je proces usporiadania údajov v databáze. Toto zahŕňa vytváranie tabuliek a o založení vzťahy medzi subjektmi tabuliek podľa pravidiel určených na ochranu údajov a aby databáza pružnejšie odstránením nadbytočné a nekonzistentné závislosť.

Nadbytočné údaje zaberá miesto na disku a vytvorí problémov súvisiacich s údržbou. Ak musí byť zmenené údaje, ktoré existuje viac ako jedno miesto, musí byť údaje zmenila v presne rovnakým spôsobom na všetkých miestach. Zmena adresy zákazníka je oveľa jednoduchšie vykonanie ak údaje uložené len v tabuľke Zákazníci a nikde inde v databáze.

Čo je "nekonzistentné závislosti"? Zároveň je to intuitívne používateľovi pozrieť v tabuľke Zákazníci pre adresu konkrétneho zákazníka, to môže zmysel sa tam pozrieť na plat zamestnanec, ktorý vyzýva tohto zákazníka. Platu zamestnanca súvisí s, alebo závislé zamestnanca a preto by mali byť presunuté do tabuľky Zaměstnanci. Nekonzistentné závislostí môžete údaje stane sťažujú prístup k, pretože cesta k nájsť údaje môžu byť chýbajúce alebo nefunkčné.

Existuje niekoľko pravidiel pre Normalizácia. Každé pravidlo sa nazýva "normálnej forme." Ak prvé pravidlo je dodržaná, databázy je povedal v "prvý normálnej forme." Ak prvý tri pravidlá sú dodržané, databázy je považovať za "tretie normálne forme." Hoci inými úrovňami normalizácia sú možné, tretie normálnej forme sa považuje za potrebné pre väčšinu aplikácií najvyššej úrovni.

Ako s mnohými formálne pravidlá a špecifikácie, reálny svet scenáre nie vždy urobiť umožniť dokonalý súlad. Vo všeobecnosti vyžaduje dodatočné normalizácia tabuľky a niektorí zákazníci nájsť tento ťažkopádne. Ak sa rozhodnete porušovať jedným z prvé tri pravidlá normalizácia, skontrolujte, či vaša žiadosť ráta akékoľvek problémy, ktoré by mohli nastať napríklad nadbytočných údajov a nekonzistentné závislostí.

Nasledujúcich popisov zahrnúť príklady.

Prvá štandardná zásada

  • Odstránenie opakujúcej sa skupiny v jednotlivých tabuľkách.
  • Vytvoriť samostatná tabuľka pre každú množinu súvisiacich údajov.
  • Identifikovať každú množinu súvisiacich údajov s primárnym kľúčom.
Nepoužívajte viacerých polí v jednej tabuľke na uloženie podobné údaje. Napríklad, na sledovanie tovaru zásob, ktoré môžu pochádzať z dve možné zdrojov, záznam o zásobách môže obsahovať polia pre dodávateľa kód 1 a dodávateľa Kód 2.

Čo sa stane, keď budete pridávať predajca tretej? Pridanie poľa je nie je odpoveď; vyžaduje program a tabuľka modifikácie a nie hladko ubytovať dynamické počet predajcov. Namiesto toho umiestniť všetky dodávateľa informácie do samostatnej tabuľky nazýva dodávatelia, potom prepojiť zásob predajcovia položka ?íselné tla?idlo alebo dodávateľov zásobám s kľúčovou kód predajcu.

Druhá štandardná zásada

  • Vytvoriť samostatné tabuľky pre množinami hodnôt, ktoré sa vzťahujú na viaceré záznamy.
  • Tieto tabuľky sa týkajú s cudzí kľúč.
Záznamy by mali nie je závislá na nič iného ako tabuľky primárny kľúč (to zložený kľúč, ak je to potrebné). Napríklad, zvažovať zákazníka adresa v účtovného systému. Adresa je potrebný tabuľky Zákazníci, ale tiež podľa objednávky, lodnej dopravy, faktúr, pohľadávky, a Zbierky tabuľky. Miesto na skladovanie adresu zákazníka ako oddelený vstupu v každej z týchto tabuliek, Uchovávajte ho v jednom mieste, buď v zákazníkov Tabuľka alebo v samostatných adresy tabuľke.

Tretí normálnej forme

  • Odstránenie polí, ktoré nezávisia od kľúč.
Hodnoty v zázname, ktoré nie sú súčasťou tohto záznamu kľúča urobiť nie je patrí v tabuľke. Vo všeobecnosti, kedykoľvek obsah skupinu polí môžu uplatňovať na viac ako jeden záznam v tabuľke, zvážte možnosť umiestnenia tých polia do samostatnej tabuľky.

Napríklad v náboru zamestnancov Tabuľka, kandidáta univerzita meno a adresu možno zahrnúť. Ale musíte úplný zoznam univerzít pre skupinu korešpondenciu. Ak univerzita informácie je uložený v tabuľke kandidátov, neexistuje spôsob, ako zoznam univerzít s č súčasné kandidátov. Vytvorenie samostatných univerzít tabuľky a prepojiť ho na Kandidáti tabuľka s kľúčovou univerzita kód.

VÝNIMKA: Priliehajúcu k tretí normálnej forme, hoci teoreticky žiaduce, nie je vždy praktické. Ak máte tabuľku Zákazníci a chcete odstrániť všetko možné interfield závislostí, musíte vytvoriť samostatné tabuľky pre mestá, PSČ, predaj zástupcovia, zákazníckym triedam a akýkoľvek iný faktor, ktorý možno rozmnožovať v viaceré záznamy. V teórii, normalizácia stojí vykonávajúcich. Avšak, mnoho malé tabuľky môžu rozkladať výkone alebo prekročiť otvoriť súbor a kapacity pamäte.

Môže byť realizovateľný uplatňovať tretej normálnej forme len k údajom, ktoré zmeny často. Ak niektoré polia závislé od zostanú, navrhnúť žiadosť požadovať od užívateľa, overiť súvisiacich polí, keď sa zmení jeden.

Iné formy normalizácia

Štvrtý normálnej forme, tiež nazývaný Boyce Codd normálny formulár (BCNF), a piaty normálnej forme existujú, ale len zriedka posudzujú v praktických dizajn. Bez ohľadu na týchto pravidiel môže viesť k návrhu menej než perfektné databázy, ale nemá vplyv na funkčnosť.

Normalizovanie príklad tabuľky

Tieto kroky ukazujú proces normalizovanie fiktívne študent tabuľka.
  1. Unnormalized tabuľka:
    Zbaliť túto tabuľkuRozbaliť túto tabuľku
    Študent #PoradcaADV-izbaClass1Class2Class3
    1022Jones412101-07143-01159-02
    4123Smith216201-01211-02214-01
  2. Prvý normálnej forme: Žiadne opakujúce sa skupiny

    Tabuľky by mali mať len dva rozmery. Pretože jeden študent má niekoľko tried, tieto triedy by mali byť uvedené do samostatnej tabuľky. Polia Class1, Class2 a Class3 v záznamoch náznakov, dizajn problémy.

    Hárky často používajú tretieho rozmeru, ale tabuliek by nemali. Ďalším spôsobom, ako sa pozrieť na Tento problém je s vzťahu one-to-many, nevkladajte na jednej strane a strany many v tej istej tabuľke. Namiesto toho vytvoriť inú tabuľku v prvom normálnych forma odstránením opakujúcu sa skupinu (trieda #), ako je uvedené nižšie:
    Zbaliť túto tabuľkuRozbaliť túto tabuľku
    Študent #PoradcaADV-izbaTrieda #
    1022Jones412101-07
    1022Jones412143-01
    1022Jones412159-02
    4123Smith216201-01
    4123Smith216211-02
    4123Smith216214-01
  3. Druhý normálnej forme: Odstránenie nadbytočných údajov

    Poznámka: viaceré triedy # hodnoty pre každú hodnotu študent # v uvedenej tabuľke. Trieda # nie je funkčne závislá študent # (hlavný kľúč), takže tento vzťah nie je v druhom normálnej forme.

    Obidve nasledujúce tabuľky preukázať druhý normálnej forme:

    Študenti

    Zbaliť túto tabuľkuRozbaliť túto tabuľku
    Študent #PoradcaADV-izba
    1022Jones412
    4123Smith216

    Registrácia

    Zbaliť túto tabuľkuRozbaliť túto tabuľku
    Študent #Trieda #
    1022101-07
    1022143-01
    1022159-02
    4123201-01
    4123211-02
    4123214-01
  4. Tretí normálnej forme: Odstránenie údajov nezávisí od Kľúč

    V poslednom príklade Adv-izba (poradca úrad číslo) je funkčne závislé poradca pre atribút. Roztok je presunúť atribút z tabuľky študenti fakulty tabuľky, ako je uvedené nižšie:

    Študenti

    Zbaliť túto tabuľkuRozbaliť túto tabuľku
    Študent #Poradca
    1022Jones
    4123Smith

    Fakulta

    Zbaliť túto tabuľkuRozbaliť túto tabuľku
    programuIzbaOdd.
    Jones41242
    Smith21642

ODKAZY

Ahlo, Hamilton M., Randy Brown a Peter Colclough. FoxPro 2: Developer's Guide: odborných usmernení pre Priemyselná-sila programovanie. John Wiley & synov, október 1991. Stránky 220-225.

Jennings, Roger. Použitím prístupu 1.1 pre Windows. Que Corporation, júl 1993. 799 Stránky-800.
Note This is a "FAST PUBLISH" article created directly from within the Microsoft support organization. The information contained herein is provided as-is in response to emerging issues. As a result of the speed in making it available, the materials may include typographical errors and may be revised at any time without notice. See Terms of Use for other considerations.

Vlastnosti

ID článku: 209534 - Posledná kontrola: 20. októbra 2011 - Revízia: 2.0
Informácie v tomto článku sa týkajú nasledujúcich produktov:
  • Microsoft Access 2000 Standard Edition
Kľúčové slová: 
kbdatabase kbdesign kbinfo kbusage kbmt KB209534 KbMtsk
Strojovo preložené
DÔLEŽITÉ: Tento článok bol preložený pomocou softvéru na strojový preklad od spoločnosti Microsoft, nie prekladateľom. Spoločnosť Microsoft ponúka články preložené prekladateľmi aj strojovo preložené články, vďaka čomu máte možnosť prístupu ku všetkým článkom databázy Knowledge Base vo svojom jazyku. Strojovo preložený článok však nie je vždy perfektný. Môže obsahovať chyby týkajúce sa slovnej zásoby, syntaxe alebo gramatiky, podobne ako cudzinec môže robiť chyby, keď rozpráva vašim jazykom. Spoločnosť Microsoft nenesie zodpovednosť za akékoľvek nepresnosti, chyby alebo škody spôsobené akýmkoľvek nepresným prekladom obsahu alebo jeho použitím zo strany zákazníkov. Spoločnosť Microsoft softvér na strojový preklad pravidelne aktualizuje.
Pokiaľ chcete vidieť anglickú verziu článku, kliknite sem:209534

Odošlite odozvu

 

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