Cikk azonosítója: 283878 - Utolsó ellenőrzés: 2007. május 8. - Verziószám: 6.4 Az adatbázisok normalizálásának alapjai
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 (http://support.microsoft.com/kb/209534/HU/ ) (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 (http://support.microsoft.com/kb/100139/HU/ ) (Előfordulhat, hogy a hivatkozás részben vagy teljes egészében angol nyelvű tartalomra mutat.). 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
(http://support.microsoft.com/servicedesks/webcasts/wc060600/wc060600.asp?fr=1)
További információA normalizálás ismertetéseA 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
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
Harmadik normálforma
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ákA 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ásraAz alábbi lépések egy kitalált hallgatói tábla normalizálását mutatják be.
A cikkben található információ a következő(k)re vonatkozik:
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. | Egyéb források További támogatás
KözösségAzonnali segítségA cikk fordítása
|






Windows Live
Facebook
Twitter
Linkedin
Digg it
Yahoo
Delicious
StumbleUpon
Yammer
Reddit
Technorati
FriendFeed
Email
A lap tetejére
