Az adatbázisok normalizálásának alapjai

A cikk fordítása A cikk fordítása
Cikk azonosítója: 283878 - A cikkben érintett termékek listájának megtekintése.
Kezdők: az egyfelhasználós számítógépek felhasználói felületének ismerete szükséges.

A cikk Microsoft Access 2000 alkalmazásra vonatkozó változata a Tudásbázis következő számú cikke: 209534 (Előfordulhat, hogy a hivatkozás részben vagy teljes egészében angol nyelvű tartalomra mutat.).
A cikk Microsoft Access 95 és Microsoft Access 97 alkalmazásra vonatkozó változata a Tudásbázis következő számú cikke: 100139 (Előfordulhat, hogy a hivatkozás részben vagy teljes egészében angol nyelvű tartalomra mutat.).
Az összes kibontása | Az összes összecsukása

A lap tartalma

Összefoglaló

A cikk az adatbázisok normalizálásával kapcsolatos terminológiát ismerteti kezdők számára. A terminológia alapszintű ismerete hasznos lesz a relációs adatbázisok felépítésének megértéséhez.

MEGJEGYZÉS: A Microsoft élő adást is készített az adatbázisok normalizálásának alapjairól. Az adás megtekintéséhez látogassa meg a Microsoft alábbi webhelyét:
http://support.microsoft.com/servicedesks/webcasts/wc060600/wc060600.asp?fr=1

További információ

A normalizálás ismertetése

A normalizálás az adatbázisban található adatok rendszerezését jelenti. Táblákat hozhat létre, és azok között kapcsolatokat létesíthet szabályok szerint. A szabályok célja az adatok védelme és az adatok rugalmasabbá tétele (például a redundanciák és az inkonzisztens függőségek kiküszöbölése).

A redundáns adatok feleslegesen foglalják a lemezterületet, és karbantartási problémákat okoznak. Ha a több helyen megtalálható adatot módosítani kell, a módosítást minden helyen pontosan ugyanúgy kell elvégezni. A vevő címének módosítása sokkal egyszerűbb, ha ez az adat csak a Vevők táblában szerepel, és az adatbázis más részén nem.

Mi az „inkonzisztens függőség”? Ha a felhasználó egy vevő címére kíváncsi, azt magától értetődően a Vevők táblában keresi, de például a vevőhöz tartozó alkalmazott bérét nem lenne logikus ebben a táblában tárolni. Az alkalmazott bére az alkalmazotthoz kapcsolódik (attól függ), ezért azt az Alkalmazottak táblában kell tárolni. Az inkonzisztens függőségek hatására előfordulhat, hogy az adatokhoz nehezen lehet hozzáférni, mert az adatok elérési útja hiányos vagy hibás lehet.

Az adatbázisok normalizálásának van néhány szabálya. A szabályok neve „normálforma”. Ha az adatbázisra teljesül az első szabály, „első normálformában” van. Ha az adatbázis megfelel az első három szabálynak, „harmadik normálformában” van. Bár a normalizálás további szintjei is lehetségesek, a legtöbb alkalmazás esetében a harmadik normálforma a szükséges legmagasabb szint.

A valós problémák számos esetben nem feleltethetők meg tökéletesen a szabályoknak és specifikációknak. A normalizáláshoz általában új táblák létrehozása szükséges, és egyes ügyfelek ezt fáradságosnak találják. Ha úgy dönt, hogy a normalizálás első három szabálya közül valamelyiknek nem tesz eleget, bizonyosodjon meg arról, hogy az alkalmazás kiküszöböli az esetlegesen felmerülő problémákat (például az adatok redundanciáját és az inkonzisztens függőségeket).

Az alábbi leírásokban példát is talál.

Első normálforma

  • Szüntesse meg az egyes táblákban az ismétlődő csoportokat.
  • Az egymáshoz kapcsolódó adatok minden halmazához hozzon létre külön táblát.
  • Az egymáshoz kapcsolódó adatok minden halmazát azonosítsa elsődleges kulccsal.
Egy táblán belül ne használjon több mezőt hasonló adatok tárolására. Ha egy készletcikk például két lehetséges forrásból származhat, annak nyomon követéséhez a készletrekord a Szállítókód 1 és a Szállítókód 2 mezőt tartalmazhatja.

Mi történik, ha egy harmadik szállítót is hozzáad? Egy új mező hozzáadása nem a megfelelő megoldás, ehhez ugyanis a szállítók számának egyszerű növelése helyett a programot és a táblát is át kellene alakítani. Ehelyett az összes szállító adatait helyezze egy különálló Szállítók nevű táblába, és kapcsolja a készletet a szállítókhoz (a cikk száma a kulcs) vagy a szállítókat a készlethez (a szállító kódja a kulcs).

Második normálforma

  • Hozzon létre külön táblákat a több rekordra vonatkozó értékcsoportokhoz.
  • A táblákat külső kulccsal kapcsolja össze.
A rekordok csak a tábla elsődleges kulcsától függhetnek (ha szükséges, ez lehet összetett kulcs). Vegyük például egy vevő címét egy számlázási rendszerben. A címre szükség van a Vevők táblában, de a Rendelések, a Szállítás, a Számlák, a Követelések és az Inkasszó táblában is. Ahelyett, hogy a vevő címét minden táblában külön bejegyzésként elhelyezné, tárolja azt egyetlen helyen, a Vevők táblában vagy egy különálló Címek táblában.

Harmadik normálforma

  • Szüntesse meg a kulcstól nem függő mezőket.
A rekordok azon értékei, amelyek nem részei a rekord kulcsának, nem tartoznak a táblához. Általánosan elmondható, hogy ha egy mezőcsoport tartalma a tábla egynél több rekordjára vonatkozhat, a mezőcsoportot egy külön táblába kell helyezni.

Az Alkalmazottak toborzása táblában például szerepelhet a jelentkező egyetemének neve és címe. Csoportos levélküldéshez azonban szükség van az egyetemek teljes listájára is. Ha az egyetemek adatait a Jelentkezők táblában tárolja, a listában nem fognak szerepelni azok az egyetemek, amelyekhez nem tartozik jelentkező. Hozza létre az Egyetemek táblát, és kapcsolja úgy a Jelentkezők táblához, hogy az egyetem kódja legyen a kulcs.

KIVÉTEL: Bár a harmadik normálforma használata elméletileg mindig szükséges, a gyakorlatban nem minden esetben célravezető. Ha a Vevők táblában például meg szeretné szüntetni a mezők közötti összes lehetséges függőséget, külön táblát kell létrehoznia a városok, az irányítószámok, az értékesítési képviselők, a vevőosztályok és minden, a rekordok között esetlegesen ismétlődő tényező számára. A normalizálás elméletben minden esetben hasznos. A sok kis tábla kezelése azonban csökkentheti a teljesítményt, és a sok megnyitott fájl feleslegesen foglalhatja a memóriát.

Ezért célszerűbb a harmadik normálformát csak olyan esetben alkalmazni, ha az adatok gyakran változnak. Ha marad néhány függő mező, állítsa be úgy az alkalmazást, hogy a felhasználótól minden módosításkor megkövetelje a kapcsolódó mezők ellenőrzését.

További normálformák

A negyedik normálforma – más néven Boyce-Codd normálforma (BCNF) – és az ötödik normálforma létezik ugyan, de a gyakorlatban ritkán használják. Ezen szabályok figyelmen kívül hagyásával az adatbázis felépítése nem tökéletes, de ez a felhasználhatóságára nincs hatással.

Példa normalizálásra

Az alábbi lépések egy kitalált hallgatói tábla normalizálását mutatják be.
  1. A tábla a normalizálás előtt:

    A táblázat összecsukásaA táblázat kibontása
    Hallgató azonosítójaKonzulensKonzulens szobaszáma1. tantárgy2. tantárgy3. tantárgy
    1022Belinszki412101-07143-01159-02
    4123Tóth216201-01211-02214-01
  2. Első normálforma: ismétlődő csoportok megszüntetése

    A táblának csak két dimenziója lehet. Mivel egy hallgatóhoz több tantárgy tartozik, a tantárgyakat külön táblában kell felsorolni. A fenti rekordok 1. tantárgy, 2. tantárgy és 3. tantárgy mezője tervezési hibát jelez.

    A számolótáblákban gyakran használják a harmadik dimenziót, táblákban azonban ez nem megengedett. A probléma másik megközelítése, hogy az egy-sok kapcsolat két oldala nem lehet egy táblában. Ehelyett hozzon létre egy első normálformában lévő táblát az ismétlődő csoport (tantárgy száma) ismétlődésének megszüntetésével az alábbiak szerint:

    A táblázat összecsukásaA táblázat kibontása
    Hallgató azonosítójaKonzulensKonzulens szobaszámaTantárgy száma
    1022Belinszki412101-07
    1022Belinszki412143-01
    1022Belinszki412159-02
    4123Tóth216201-01
    4123Tóth216211-02
    4123Tóth216214-01
  3. Második normálforma: az adatok redundanciájának megszüntetése

    Mint a fenti táblában láthatja, minden hallgatóazonosítóhoz több tantárgyszám tartozik. A tantárgy száma nem függ funkcionálisan a hallgató azonosítójától (elsődleges kulcs), ezért ez a kapcsolat nincs második normálformában.

    Az alábbi két tábla a második normálformát szemlélteti:

    Hallgatók:

    A táblázat összecsukásaA táblázat kibontása
    Hallgató azonosítójaKonzulensKonzulens szobaszáma
    1022Belinszki412
    4123Tóth216


    Regisztráció:

    A táblázat összecsukásaA táblázat kibontása
    Hallgató azonosítójaTantárgy száma
    1022101-07
    1022143-01
    1022159-02
    4123201-01
    4123211-02
    4123214-01
  4. Harmadik normálforma: a kulcstól nem függő adatok kiszűrése

    Az utolsó példában a Konzulens szobaszáma (a konzulens irodájának száma) funkcionálisan függ a Konzulens attribútumtól. A megoldás, hogy ezt az attribútumot a Hallgatók táblából az Oktatók táblába helyezi az alábbiak szerint:

    Hallgatók:

    A táblázat összecsukásaA táblázat kibontása
    Hallgató azonosítójaKonzulens
    1022Belinszki
    4123Tóth


    Oktatók:

    A táblázat összecsukásaA táblázat kibontása
    NévSzobaRészleg
    Belinszki41242
    Tóth21642

Tulajdonságok

Cikk azonosítója: 283878 - Utolsó ellenőrzés: 2007. május 8. - Verziószám: 6.4
A cikkben található információ a következő(k)re vonatkozik:
  • Microsoft Office Access 2007
  • Microsoft Office Access 2003
  • Microsoft Access 2002 Standard Edition
Kulcsszavak: 
kbhowto kbinfo kbdatabase kbdesign KB283878
A Microsoft tudásbázisban szolgáltatott információkat "az adott állapotban", bárminemű szavatosság vagy garancia nélkül biztosítjuk. A Microsoft kizár mindennemű, akár kifejezett, akár vélelmezett szavatosságot vagy garanciát, ideértve a forgalomképességre és az adott célra való alkalmasságra vonatkozó szavatosságot is. A Microsoft Corporation és annak beszállítói semmilyen körülmények között nem felelősek semminemű kárért, így a közvetlen, a közvetett, az üzleti haszon elmaradásából származó vagy speciális károkért, illetve a kár következményeként felmerülő költségek megtérítéséért, még abban az esetben sem, ha a Microsoft Corporationt vagy beszállítóit az ilyen károk bekövetkeztének lehetőségére figyelmeztették. Egyes államok joga nem teszi lehetővé bizonyos károkért a felelősség kizárását vagy korlátozását, ezért a fenti korlátozások az ön esetében esetleg nem alkalmazhatók.

Visszajelzés küldése

 

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