ACC: Základy normalizácia

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:100139
Tento článok bol archivovaný. Je publikovaný v aktuálnej podobe a už nebude aktualizovaný.
Začiatočník: Vyžaduje vedomosti o používateľského rozhrania na jedného používateľa počítačov.

SUHRN
Tento článok vysvetľuje základy databázy normalizácia terminológie. Azákladné znalosti o tejto terminológia je užitočná pri prerokúvaníkonštrukcia relačnej databázy.

POZNÁMKA: Microsoft taktiež ponúka WebCast, že diskutuje základy normalizácia. Zobraziť tento WebCast, navštívte nasledujúcu webovú lokalitu spoločnosti Microsoft:POZNÁMKA: Ak chcete zobraziť túto informáciu z aplikácie Microsoft Access 2000, prečítajte si nasledujúci článok v databáze Microsoft Knowledge Base:
209534 ACC2000: Základy normalizácia
DALSIE INFORMACIE

Popis normalizácia

Normalizácia je proces usporiadania údajov v databáze. Totozahŕňa vytváranie tabuliek a vytvorenie vzťahy medzi subjektmitabuľky podľa pravidiel navrhnuté aj na ochranu údajov askontrolujte databázu pružnejšie odstránením dva faktory: nadbytočnosti anekonzistentné závislosť.

Nadbytočné údaje zaberá miesto na disku a vytvorí problémov súvisiacich s údržbou. Akúdajov, ktorý existuje vo viac ako jednom mieste musí byť zmenené, údaje musiazmeniť v presne rovnakým spôsobom na všetkých miestach. Zákazníkadresa zmena je oveľa jednoduchšie vykonanie ak údaje skladuje lenv tabuľke Zákazníci a nikde inde v databáze.

Čo je "nekonzistentné závislosti"? Zároveň je to intuitívne pre používateľapozrieť v tabuľke Zákazníci pre adresu určitéhozákazník, to môže zmysel sa tam pozrieť na platzamestnanec, ktorý vyzýva tohto zákazníka. Týkajúcich sa platu zamestnancaalebo je závislý na zamestnanca a preto by mal byť presunutý doTabuľka zamestnanci. Nekonzistentné závislostí môžete sťažujú údajovprístup; cestu 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álny formulár." Ak sa pozoruje prvé pravidlo, je povedal databázyv "prvý normálnej forme." Ak sú pozorované prvé tri pravidlá,databáza sa považuje za v "tretí normálnej forme." Hociinými úrovňami normalizácia sú možné, tretej normálnej forme jepovažovaná za najvyššiu úroveň potrebnú pre väčšinu aplikácií.

S mnohými formálne pravidlá a špecifikácie, reálny svet scenáre urobiťnie vždy umožniť dokonalý súlad. Vo všeobecnosti normalizáciavyžaduje ďalšie tabuľky a niektorí zákazníci nájsť tento ťažkopádne. Akste sa rozhodli v rozpore s jedným z prvé tri pravidlá štandardizácie,Uistite sa, že vaša aplikácia ráta akékoľvek problémy, ktoré by mohlivyskytujú sa ako nadbytočných údajov a nekonzistentné závislostí.

POZNÁMKA: Nasledujúcich opisov zahŕňajú 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 dvochmožných zdrojov, záznam o zásobách môže obsahovať polia pre dodávateľaKód 1 a kód dodávateľa 2.

Ale čo sa stane, keď budete pridávať predajca tretej? Pridáte pole nie jeodpovede; vyžaduje program a tabuľka modifikácie a niehladko ubytovať dynamické počet predajcov. Namiesto toho umiestniť všetkyinformácie o dodávateľovi do samostatnej tabuľky nazýva dodávatelia, potom odkazsúpis dodávateľov s položka èíselné tlaèidlo alebo dodávatelia zásobs 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 hlavný kľúč tabuľky(to zložený kľúč, ak je to potrebné). Napríklad, zvažovať zákazníkaadresa v účtovného systému. Adresa je potrebnýTabuľka Zákazníci, ale aj prostredníctvom účtov objednávok, lodnej dopravy, faktúry,Pohľadávky a zbierok tabuliek. Miesto na skladovanie zákazníkariešiť ako samostatná položka v každom z týchto tabuliek, Uchovávajte ho v jednommiesto, v tabuľke Zákazníci alebo do samostatnej tabuľky adries.

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 niepatria do tabuľky. Vo všeobecnosti, kedykoľvek obsah skupinapolia môžu uplatňovať na viac ako jeden záznam v tabuľke, zvážiťuvádzanie týchto polí do samostatnej tabuľky.

Napríklad v náboru zamestnancov tabuľke, kandidátaUniverzita meno a adresu možno zahrnúť. Ale musíte úplnýzoznam univerzít pre skupinu korešpondenciu. Ak univerzita informácieuložené v tabuľke kandidátov, neexistuje spôsob, ako zoznam univerzíts žiadny aktuálny kandidátov. Vytvoriť samostatná tabuľka univerzít aprepojenie s tabuľkou kandidátov s univerzita kód kľúča.

VÝNIMKA: Priliehajúcu k tretej normálnej forme, zatiaľ čo teoretickyžiaduce, nie je vždy praktické. Ak máte tabuľku Zákaznícia chcete odstrániť všetky možné interfield závislostí, musítevytvoriť samostatné tabuľky pre mestá, PSČ, predajzástupcovia, zákazníckym triedam a akýkoľvek iný faktor, ktorý môžezduplikujú na viacero záznamov. V teórii, štandardizácia jestojí za realizáciu; však mnohé malé tabuľky môžu rozkladať výkonealebo prekročiť otvoriť súbor a pamäť kapacít.

Môže byť realizovateľný uplatňovať tretej normálnej forme len k údajom, ktorézmeny často. Ak niektoré polia závislé od zostanú, dizajn vášhouplatňovanie na vyžadujú od používateľa overiť všetky súvisiace polia pri jehojeden sa zmení.

Iné formy normalizácia

Štvrtý normálnej forme, tiež nazývaný Boyce Codd normálny formulár (BCNF), apiaty normálnej forme existujú, ale len zriedka posudzujú v praktickýchdizajn. Bez ohľadu na tieto pravidlá môžu viesť k menej než perfektnénávrhu databázy, ale by nemala ovplyvniť funkčnosť.
               **********************************                 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. Prvý normálnej forme: Žiadne opakujúce sa skupiny

    Tabuľky by mali mať len dva rozmery. Pretože jeden študent má niekoľkých tried, tieto triedy by mali byť uvedené v samostatnej Tabuľka. Polia Class1, Class2 "Class3 v zázname vyššie sú indikácie 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: s one-to-many vzťah, neuvedených na jednej strane a strane many v tom istom Tabuľka. Namiesto toho vytvoriť inú tabuľku v prvom normálnej forme odstránenie opakujúcu sa skupinu (trieda #), ako je uvedené nižšie:
           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álnej forme: Odstránenie nadbytočných údajov

    Poznámka viacnásobné hodnoty triedy # pre každý študent # hodnota v nad tabuľkou. 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:
        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. Tretí normálnej forme: Odstránenie údajov nie závislé na kľúč

    V poslednom príklade Adv-izba (poradca úrad číslo) je funkčne závislé poradca pre atribút. Riešením je presunúť tento atribút z tabuľky študenti fakulty tabuľky, ako je uvedené nižšie:
        Students:   Student#    Advisor                -------------------                1022        Jones                4123        Smith    Faculty:    Name    Room    Dept                --------------------                Jones   412     42                Smith   216     42					
ODKAZY
Ďalšie informácie o navrhovaní databázy, kliknite na nasledujúce číslo článku databázy Microsoft Knowledge Base:
234208 ACC2000: "Pochopenie návrhu relačnej databázy" dokument dostupný v stredisku pre prevzatie softvéru
"FoxPro 2 A Developer's Guide," Hamilton M. Ahlo Jr et al., stránky220-225, M & T kníh, 1991

"Použitím prístupu pre Windows," Roger Jennings, stránky 799-800, QueCorporation, 1993
BCNF relačný normálne model normalizovať

Upozornenie: Tento článok bol preložený automaticky.

Vlastnosti

ID článku: 100139 – Posledná kontrola: 12/04/2015 09:30:11 – Revízia: 2.0

Microsoft Access 1.0 Standard Edition, Microsoft Access 1.1 Standard Edition, Microsoft Access 2.0 Standard Edition, Microsoft Access 97 Standard Edition

  • kbnosurvey kbarchive kbinfo kbusage kbmt KB100139 KbMtsk
Pripomienky