Vissza az előzőleg látogatott oldalra (nem elérhető funkció)Vissza a tananyag kezdőlapjára (P)Ugrás a tananyag előző oldalára (E)Ugrás a tananyag következő oldalára (V)Fogalom megjelenítés (nem elérhető funkció)Fogalmak listája (nem elérhető funkció)Oldal nyomtatása (nem elérhető funkció)Oldaltérkép megtekintése (D)Keresés az oldalon (nem elérhető funkció)Súgó megtekintése (S)

Tehetséggondozás az informatikában – Adatbázis-kezelés / Adatbázis-tervezés, normalizálás

Tanulási útmutató

Összefoglalás

Ebben a fejezetben az adatbázis tervezés alapjaival ismerkedhetünk meg példákon keresztül

Adatbázis-tervezés, normalizálás

Az előző fejezetben arra néztünk általános elveket és néhány példát, hogy hogyan tudjuk a feladat megoldásához megfelelő formára hozni a rendelkezésünkre bocsátott forrásállományokat.

Ebben a fejezetben olyan feladatokkal fogunk foglalkozni, ahol nem csak a forrásállományok formátumával van probléma, hanem a forrásállományok szerkezetével is, sőt, adott esetben nekünk kell megtervezni az adatbázis sémáját is. Ehhez szükségesnek tartom bevezetni a normalizálás fogalmát, és az ahhoz kapcsolódó kulcsfogalmakat is.

Ezen fogalmakat igyekszem a lehető legegyszerűbben, legközérthetőbben tárgyalni, hozzájuk egyszerű példákat csatolni, majd néhány OKTV feladaton keresztül bemutatni az alkalmazásukat.

Fogalmak

Elsődleges kulcs: minden táblában – nem kötelező, de – ajánlott lennie olyan mezőnek vagy mezőknek, amely(ek) a rekord többi mezőjét egyértelműen azonosítják. Ez(eke)t a mező(ke)t nevezzük elsődleges kulcsnak.

Funkcionális függőség: ha egy táblában az egyik mező bármely értékéhez egy másik mezőnek csak egy értéke rendelhető. Például egy személyi számhoz csak egy név tartozhat, de ugyanahhoz a névhez több személyi szám is.

Kölcsönös funkcionális függőség: ha a funkcionális függőség mindkét irányba igaz. Például: rendszám – autó.

Funkcionális függetlenség: ha a két mező értékei között nincs semmiféle kapcsolat. Például: a dolgozó szemének színe és a cég telephelye.

Tranzitív funkcionális függőség: ha egy tábla egy mezőjének konkrét értékei meghatároznak a táblán belül más mező értékeit. Például: a FEOR kód meghatározza a szakképzettséget.

Redundancia: bizonyos információk feleslegesen ismétlődnek több sorban. Nézzük meg a következő példát:

1. táblázat: A Filmek tábla
filmcím év hossz műfaj stúdióNév színészNév
Csillagok háborúja 1977 124 sci-fi Fox Carrie Fischer
Csillagok háborúja 1977 124 sci-fi Fox Mark Hamill
Csillagok háborúja 1977 124 sci-fi Fox Harrison Ford
Elfújta a szél 1939 231 dráma MGM Vivien Leigh
Wayne világa 1992 95 vígjáték Paramount Dana Carvey
Wayne világa 1992 95 vígjáték Paramount Mike Meyers
Forrás

A példát lásd itt: Jeffrey D. Ullman – Jennifer Widom: Adatbázis-rendszerek. Alapvetés. Második, átdolgozott kiadás. Panem. Budapest, 2009. [600], ISBN 978-9-635454-81-5. 90. oldal

Nézzük meg figyelmesen a Filmek táblát. Láthatjuk, hogy a Csillagok háborúja és a Wayne világa című filmek esetén a színészNév mezőben szereplő neveken kívül minden más adat megegyezik. Ez felesleges ismétlődés, vagyis redundancia.

Módosítási anomáliák: ezek akkor fordulhatnak elő, ha nem terveztük meg gondosan az adatbázisunkat, és sok benne a redundáns adat. Ilyen esetben, ha módosítjuk az egyik rekord egy mezőjében tárolt adatot, akkor gondoskodnunk kell arról, hogy a többi hasonló rekordban is megváltozzon.

Nézzük ismét a Filmek táblát! Ha valamiért meg szeretnénk változtatni a Wayne világa műfaját vígjátékról drámára, akkor – ha nem figyelünk oda – csak az első sorban változtatjuk meg, míg a második sorban változatlanul hagyjuk. Így viszont nem lennének egységesek a műfaji adatok a filmre nézve.

Törlési anomáliák: adott esetben, ha bizonyos értékek halmaza üressé válik, akkor felléphet olyan mellékhatás, hogy más fontos információt is elveszíthetünk. Példának okáért, ha az Elfújta a szél című filmben szereplő színészek közül kitörölnénk Vivien Leight-t, akkor ebben a táblában (és egyúttal az adatbázisban) nem maradna több színész az Elfújta a szélhez, így a Filmek táblából eltűnne az erre vonatkozó sor, minden rá vonatkozó információval együtt (hossz, műfaj).

Ezen anomáliák kiküszöbölése érdekében fontos feladat az adatbázis logikai felépítésének gondos megtervezése. Ezt a folyamatot nevezzük normalizálásnak. A normalizálás különböző stádiumait normálformákkal írjuk le. A továbbiakban a normálformákat NF-fel jelölöm, előttük pedig a sorszám jelzi, hogy hányadik normálformáról van szó.

Megjegyzés

A fentieken kívül léteznek még magasabb rendű normálformák (Boyce-Codd Normál-forma, 4NF, 5NF) is, ezekre azonban nem térek ki.

Nézzünk egy példát erre a folyamatra! Egy gépjárműkölcsönző forgalmát papíron az alábbiak szerint lehetne vezetni:

2. táblázat: A Járműkölcsönző tábla
Kölcsönzés dátuma Kölcsönző neve Kölcsönző címe Kölcsönzött jármű típusa Jármű kategóriája Kölcsönzési díj
2012.08.08. Vincs Eszter, Segít Elek Fő u. 23, Alma u. 1. Toyota Yaris, IFA W50 személy, teher 1000, 1500
2012.08.09. Kiss József, Nagy Ferenc, Em Elek Körte u. 2., Szilva u. 3., Hold u. 10. Opel Astra, Renault Midliner, Scania R124 személy, teher, kamion 1000, 1500, 2000

Ha figyelmesen megnézzük, láthatjuk, hogy ez a táblázat nincsen 1NF-ban, hiszen egy soron belül több oszlopban több érték is szerepel (Kölcsönző neve, Kölcsönző címe, Kölcsönzött jármű típusa, Jármű kategóriája, Kölcsönzési díj), vagyis az oszlopok értékei nem atomiak.

Úgy tehetjük 1NF-ba, hogy a fenti két sort annyi sorra osztjuk fel, ahány különböző adat szerepel bennük, és mindegyikhez beírjuk a kölcsönzés dátumát. Így a táblázat 5 soros lesz, és a táblázat minden oszlopában csak atomi értékek szerepelnek. Ezek után a tábla így néz ki:

3. táblázat: A Járműkölcsönző tábla 1NF-ben
Kölcsönzés dátuma Kölcsönző neve Kölcsönző címe Kölcsönzött jármű típusa Jármű kategóriája Kölcsönzési díj
2012.08.08. Vincs Eszter Fő u. 23 Toyota Yaris személy 1000
2012.08.08. Segít Elek Alma u. 1. IFA W50 teher 1500
2012.08.09. Kiss József Körte u. 2. Opel Astra személy 1000
2012.08.09. Nagy Ferenc Szilva u. 3. Renault Midliner teher 1500
2012.08.09. Em Elek Hold u. 10. Scania R124 kamion 2000

Viszont a táblázat tele van redundanciával, hiszen a dátumok többször is szerepelnek a táblázatban. Ebben az esetben törlési és módosítási anomáliák lehetősége is fennáll:

Ezeket az anomáliákat kellene kiküszöbölnünk, vagyis a táblát 2NF-ra kell hoznunk. Az előző módosításnak köszönhetően a tábla már 1NF-ban van, így most meg kell találnunk azokat a mezőket, amelyek elsődleges kulcsok lehetnek. Ez esetben elsődleges kulcs lehet a Kölcsönző neve, a Kölcsönzött jármű típusa és a Jármű kategóriája is, mert a Kölcsönző neve meghatározza a Címet, a Kölcsönzött jármű típusa a Jármű kategóriáját, a Jármű kategóriája pedig a Kölcsönzési díjat.

A 2NF akkor teljesül, ha az elsődleges kulcsoktól részben függő több különálló táblát készítünk (a továbbiakban csak a mezőneveket tüntetem fel):

4. táblázat: Kölcsönzések tábla
Sorszám Kölcsönzés dátuma Kölcsönző neve Kölcsönzött jármű típusa
5. táblázat: Járművek tábla
Kölcsönzött jármű típusa Jármű kategóriája Kölcsönzési díj
6. táblázat: Ügyfelek tábla
Kölcsönző neve Cím

A Kölcsönzések táblába bevezettem egy új, Sorszám mezőt, ami az elsődleges kulcs szerepét tölti be.

Még így is maradt egy törlési anomália a Járművek táblában, mert ha kitörlünk egy járműtípust, akkor törlődik a kategória és a kölcsönzési díj is.

Ahhoz, hogy ezt megszüntessük, és egyben 3NF-ra hozzuk az adatbázist, a Járművek táblát kell tovább bontanunk. Meg kell szüntetnünk a tranzitív függést (a típus meghatározza a kategóriát, a kategória pedig a kölcsönzési díjat, tehát a típus jelenleg meghatározza a kölcsönzési díjat). Bontsuk szét a Járművek táblát az alábbi módon:

Így a végleges adatbázis a következőképpen néz ki (az elsődleges kulcsokat csillaggal jelölöm):

A négy táblát természetesen össze is kell kapcsolni, hiszen a legtöbb esetben csak együttes használattal lehet kiolvasni az adatokat az adatbázisból. Például, ha azt szeretnénk megtudni, hogy ki és mennyiért kölcsönzött járművet, akkor szükség lesz mind a négy táblára.

Azokat a mezőket, melyek hivatkoznak egy másik tábla elsődleges kulcsára, idegen kulcsnak nevezzük. Ezeken keresztül valósulnak meg a táblák közötti kapcsolatok. A könnyebbség kedvéért azokat a mezőket, melyeken keresztül össze kell kapcsolni a táblákat, ugyanúgy neveztem el. Célszerű a gyakorlatban is így tenni, mert ezzel saját munkánkat könnyítjük meg, továbbá így az adatbázis önmagát is „dokumentálja”.

E hosszabb elméleti rész után nézzünk néhány OKTV részfeladatot, melyekben alkalmazhatjuk ezen új ismereteket!

Vissza a tartalomjegyzékhez

Új Széchenyi terv
A projekt az Európai Unió támogatásával, az Európai Szociális Alap társfinanszirozásával valósul meg.
Készült az "Országos koordinációval a pedagógusképzés megújításáért” című TÁMOP-4.1.2.B.2-13/1-2013-0007 pályázat keretében.

A tananyag az ELTESCORM keretrendszerrel készült