Az adatbázisok normalizálásának alapjai
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.
A normalizálás ismertetése
A normalizálás az adatbázisban található adatok rendszerezését jelenti. Ez magában foglalja a táblák létrehozását és a táblák közötti kapcsolatok létrehozását az adatok védelme és az adatbázis rugalmasabbá tétele érdekében a redundancia és az inkonzisztens függőségek kiküszöbölésével.
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. Az ügyfélcím-módosítás egyszerűbben implementálható, ha az adatokat csak a Vevők táblában tárolja, az adatbázisban pedig sehol máshol.
Mi az „inkonzisztens függőség”? Bár a felhasználók számára magától értetődő, hogy az Ügyfelek táblában meg kell keresni egy adott ügyfél címét, előfordulhat, hogy nem érdemes az adott ügyfelet hívó alkalmazott fizetését keresni. 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. Minden szabályt "normál űrlapnak" nevezünk. Ha az első szabályt figyeli meg, az adatbázis "első normál formában" lesz. Ha az első három szabályt betartják, az adatbázis "harmadik normál" formátumúnak minősül. Bár a normalizálás más szintjei is lehetségesek, a harmadik normálforma a legtöbb alkalmazáshoz szükséges legmagasabb szintnek tekinthető.
Mint számos hivatalos szabály és specifikáció esetében, a valós forgatókönyvek sem mindig teszik lehetővé a tökéletes megfelelőséget. 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.
Ne használjon több mezőt egyetlen táblában 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? Nem a mező hozzáadása a válasz; program- és táblamódosítást igényel, és nem képes zökkenőmentesen alkalmazkodni a szállítók dinamikus számához. 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 nem függenek mástól, mint a tábla elsődleges kulcsa (szükség esetén ö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
- Távolítsa el azokat a mezőket, amelyek nem függenek a kulcstól.
A rekord 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 elméletileg kívánatos, a harmadik normál forma megtartása nem mindig praktikus. 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. Elméletileg a normalizálást érdemes folytatni. 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 normalizálási formák
A negyedik normálforma, más néven Boyce-Codd normálforma (BCNF) és az ötödik normálforma létezik, de a gyakorlati tervezés során ritkán veszik figyelembe. Ha figyelmen kívül hagyja ezeket a szabályokat, az az adatbázis tökéletesebb kialakítását eredményezheti, de nem befolyásolhatja a működést.
Példatáblázat normalizálása
Az alábbi lépések egy kitalált hallgatói tábla normalizálását mutatják be.
A tábla a normalizálás előtt:
Hallgató azonosítója Konzulens Konzulens szobaszáma 1. tantárgy 2. tantárgy 3. tantárgy 1022 Belinszki 412 101 -07 143 -01 159 -02 4123 Béla 216 101 -07 143 -01 179 -04 Első normálforma: Nincsenek ismétlődő csoportok
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ák gyakran a harmadik dimenziót használják, de a tábláknak nem szabad. Ezt a problémát úgy is megvizsgálhatja, ha egy-a-többhöz kapcsolatban van, ne helyezze az egy és a több oldalt ugyanabba a táblába. Ehelyett hozzon létre egy másik táblát az első normál formában az ismétlődő csoport (Class#) eltávolításával, ahogyan az alábbi példában látható:
Hallgató azonosítója Konzulens Konzulens szobaszáma Tantárgy száma 1022 Belinszki 412 101 -07 1022 Belinszki 412 143 -01 1022 Belinszki 412 159 -02 4123 Béla 216 101 -07 4123 Béla 216 143 -01 4123 Béla 216 179 -04 Második normálforma: A redundáns adatok kiküszöbölése
Jegyezze fel a fenti táblázatban szereplő student#-értékek több Osztály# értékét. A Class# funkcionálisan nem függ a Student# (elsődleges kulcs) függvénytől, így ez a kapcsolat nem a második normál formában van.
Az alábbi táblázatok a második normálformát szemléltetik:
Hallgatók:
Hallgató azonosítója Konzulens Konzulens szobaszáma 1022 Belinszki 412 4123 Béla 216 Regisztráció:
Hallgató azonosítója Tantárgy száma 1022 101 -07 1022 143 -01 1022 159 -02 4123 101 -07 4123 143 -01 4123 179 -04 Harmadik normálforma: A kulcstól nem függő adatok kiküszöbölé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:
Hallgató azonosítója Konzulens 1022 Belinszki 4123 Béla Oktatók:
Name (Név) Szoba Részleg Belinszki 412 42 Béla 216 42
Visszajelzés
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ: https://aka.ms/ContentUserFeedback.
Visszajelzés küldése és megtekintése a következőhöz: