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:

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ó.

• 1NF: a tábla minden sorában oszloponként szereplő értékek atomiak (vagyis egy mezőben csak egy érték szerepel), és megadható hozzá kulcs. Ha több értéket tartalmaz egy mező, akkor annyi sorra bontjuk, ahány érték szerepel a mezőben, és a sor többi elemét ismételjük.
• 2NF: a tábla 1NF-ban van, és minden olyan érték, amely nem kulcs, funkcionálisan függ az elsődleges kulcstól.
• 3NF: a tábla 2NF-ban van, és csak az elsődleges kulcstól függnek a mezők. Ha van olyan a táblában, hogy a „B” mező értéke függ az „A” mező értékétől, és a „C” mező értéke függ a „B” értékétől, akkor ebből az következik, hogy a „C” mező értéke tranzitíven függ az „A” mező értékétől. Ha ilyen tranzitív függések fennállnak, azokat ki kell küszöbölni, mégpedig úgy, hogy a táblát két táblára kell bontani úgy, hogy az egyes táblákban már ne legyenek ilyen függések, vagy 3NF-ban legyenek.

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:

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:

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:

• Ha kitöröljük az IFA W50-t, akkor ezzel töröljük Segít Eleket is minden adatával együtt, pedig a későbbiekben még kölcsönözhet, és akkor jó lenne, ha az adatai az adatbázisban lennének. (törlési anomália)
• Ha megváltoztatjuk a személygépjárművek kölcsönzési díját, akkor ezt min-den egyes sorban meg kell tennünk, különben az adatok nem lesznek konzisztensek. (módosítási anomália)
• Ha bekerül egy új jármű a táblába, akkor nem tudunk minden mezőt kitölteni, hiszen azt a járművet még nem kölcsönözte ki senki. (bővítési anomália)

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):

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:

• Hozzunk létre egy Kategória táblát Kategória és Díj mezőkkel! A Kategória mező legyen elsődleges kulcs!
• A Járművek táblát pedig módosítsuk úgy, hogy kivesszük belőle a Díj mezőt!

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

• Kölcsönzések (*Sorszám, Dátum, Jármű típusa, Kölcsönző neve)
• Járművek (*Jármű típusa, Kategória)
• Ügyfelek (*Kölcsönző neve, Cím)
• Kategória (*Kategória, Díj)

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