Adatbázisok 3.rész

 

Az előző cikkemben az eddig kialakult három legfontosabb adatbázis-modellről volt szó. Mivel a hálós és hierarchikus adatmodellt napjainkra teljesen kiszorítva a relációs adatmodell és az erre építő adatbázisrendszerek terjedtek el, ezért ebben a cikkben ezzel a modellel fogunk foglalkozni.

 

Foglaljuk röviden össze, hogy mit is tudunk eddig a relációs adatbázisokról:

ˇ         A relációs adatbázisok táblákból állnak. Ezeket a táblákat nevezhetjük relációknak is. Az, hogy egy adatbázist hány táblából áll, általában az adott feladat követelményei határozzák meg.

ˇ         Egy  relációs adatmodellben a táblázat oszlopai lesznek a tulajdonságok, míg a táblázat sorai az egyed egyes értékei. (lásd: Adatbázisok, 2. cikk)

ˇ         Amelyik oszlopban lévő érték (vagyis tulajdonság) egyértelműen meghatározza, hogy melyik egyedről van szó, azt kulcsnak, az azt tartalmazó oszlopot pedig kulcsoszlopnak nevezzük. Az adatbázist alkotó egyes táblákat ezek a kulcsoszlopok kötik össze.

ˇ         A relációk között fennálló kapcsolat mindig dinamikus.

 

Ezek után vizsgáljuk meg a relációs adatbázis belső szerkezetét. Kezdjük mindjárt a kulcsokkal.

 

A relációs adatbázisok belső szerkezete

Eddig azt mondtuk, hogy egy relációban kulcsnak nevezzük azt a tulajdonságot, amely egyértelműen meghatározza a reláció egy sorát. Hány kulcs lehet egy relációban? Nyilvánvaló, hogy egynek minimum kell lennie, de előfordulhat, hogy több kulcs is szerepel(het) egy-egy relációban. Vajon egy kulcsot hány attribútum (tulajdonság) határozhat meg? Az is nyilvánvaló, hogy legalább egy tulajdonság kell ahhoz, hogy pontosan azonosítani tudjuk a reláció egy sorát. Ilyen esetben a kulcsot egyszerűnek nevezzük. Ha azonban több tulajdonság is szerepel a kulcsban, mert csak egynél több attribútum figyelembevételével határozható meg, hogy a reláció melyik soráról is van pontosan szó, akkor a kulcsot összetettnek nevezzük.

 

Azokat tulajdonságokat, amelyek egy másik relációban kulcsot alkotnak (vagyis pontosan meghatározzák, hogy a másik reláció melyik soráról van szó) külső kulcsnak nevezzük.

Hogy pontosan mit is jelent a külső kulcs fogalma, erre cikkben a normalizálás témakörénél még visszatérek.

 

Menjünk tovább, és nézzük meg, hogy melyek azok a dolgok, amelyek a relációs adatbázisok belső szerkezetét jellemzik.

 

Amikor relációs adatbázisokat használunk, előbb-utóbb bizonyosan szembetalálkozunk a normalizálás fogalmával.

 

A normálformák az adatbázisok belső szerkezetét jellemzik.

Miért is mondtam mindezt? Azért, mert a normalizálás arra vonatkozik, hogy miként valósítjuk meg az adatbázisban a kapcsolatokat és hogyan tároljuk az egyes adatokat az adatbázistáblákban. Amikor azt halljuk, hogy adatbázis-normalizást végzünk, mindig a felesleges adatok mennyiségét próbáljuk meg csökkenteni.

 

A normalizáció típusai

 

Első normálforma (1NF)

 

Az 1NF a lehető legegyszerűbb változat, a relációs adatbázisrendszerek alapja. Mi az 1NF követelménye? Az, hogy az adatbázis minden oszlopában csak egy értéket tároljunk.

Nézzük meg egy képzeletbeli számítástechnikai eszközöket forgalmazó cég rendelési adatbázisát.

 

 

Ha megnézzük alaposan a fenti ábrát, jól láthatjuk, hogy a rendelés száma melett feltüntettük a rendelt eszközök azonosítóját, vagyis egy oszlopban több értéket is megadtunk. Eleget tesz-e ez a forma az 1NF követelményeinek? A válasz: NEM, ugyanis az első normálforma nem engedélyezi, hogy egy sor egy oszlopában egynél több érték szerepeljen.

 

Hogyan hozható ez mégis első normálformába? Úgy, hogy a rendelés minden egyes cikkét külön-külön rekordba kell rögzítenünk. (Vagyis ugyanarról a rendelésről több rekordot kell létrehoznunk.)

 

Nézzük meg a normalizálás eredményét:

 

 

 

Ez a forma már megfelel az 1NF követelményeinek, hiszen minden sorban csak egy érték áll. (Az ilyen információt atomi értéknek is nevezhetjük.)

 

 

Második normálforma (2NF)

 

A 2NF első követelménye, hogy az adatbázis első normálformában legyen. A második követelménye pedig az, hogy az reláció (tábla) minden egyes sora azonosítható legyen. Eleget tesz a fenti ábra a második követelménynek?

 

Gondolkodjunk egy kicsit. Látszólag eleget tesz, mert ha a rendelés számát, együtt használjuk a rendelt eszköz kódjával (vagyis összetett kulcsot használunk), akkor máris pontosan tudjuk azt, hogy melyik sorra gondoltunk. DE!! Mi van akkor, ha ugyanaz a termék több rendelésben is szerepel? Ekkor ez az összetett kulcs máris használhatatlanná válik az azonosítás folyamatában.

 

Mit lehet ebben az esetben tenni? Fel kell vennünk egy olyan oszlopot, amely önmagában is képes jól azonosítani, hogy a reláció melyik soráról van szó. Milyen feltételnek kell megfelelnie ennek az azonosítást szolgáló oszlopnak? Ebben az oszlopban csak olyan atomi értékek lehetnek, amelyek egyértelműen azonosítják a reláció egyes sorait, vagyis egy érték soha nem szerepelhet kétszer! Vegyünk tehát fel egy RendelésID mezőt.

 

 

Ez a forma már eleget tesz a 2NF követelményeinek.

 

 

Harmadik normálforma (3NF)

 

A harmadik normálforma jelenti az igazán nagy segítséget az adatbázis-fejlesztők számára. A 3NF legelső követelménye, hogy az adatbázis 2NF-ban legyen. A második kitétel, hogy a tábláinkban nem lehet olyan redundáns (ismétlődő) nem-kulcs információ, amely más táblákban is nem-kulcs információt jelent.

 

Minden normalizálásnak a célja az, hogy az adatbázisunkat 3NF-ra hozzuk.

Miért emeltem ki ezt a megfogalmazást?

 

Nézzük meg a "Termék leírása" oszlopot. Ez az oszlop ugyanabban a táblában kerül tárolásra, amelyekben a bolti rendelések is szerepelnek, holott ezek az adatok valószínűleg az adatbázisunk más táblájában is megtalálhatóak. (Vagy akár több táblában is szerepelhetnek egyszerre, vagyis ismétlődnek/redundálódnak az adatbázison belül.) Ez pedig előbb-utóbb biztosan súlyos problémákhoz fog vezetni.

 

Joggal feltehető a kérdés: Miért? Azért, mert ha pl. az adatbázis rendelés táblájában szeretnék módosítani a nyomtatónak, mint terméknek a leírását, akkor azt minden egyes táblában módosítanunk kell, ahol szerepel ez termék. Ha az adatbázisunk nagy és sok táblából épül fel, akkor nem biztos, hogy minden helyen sikerül kijavítanunk az adott értéket, és így előbb-utóbb teljesen összekeverednek a nyomtatókkal kapcsolatos adatok.

Ezt elkerülendő, szüntessük meg a táblában a Termék leírása nevű oszlopot. Így máris kijavítottuk a hibát, ezáltal 3NF-ra hoztuk az adott táblát.

 

 

 

 

Mivel az adott termékhez egyértelműen hozzárendelhető egy azonosító, így máris lehetőségünk nyílik arra, hogy létrehozzunk egy olyan táblát, amely az adott termék összes tulajdonságát tartalmazza.

 

 

 

Ha idáig eljutottunk, akkor felmerülhet bennünk egy másik kérdés is. Mégpedig az: Volt ennek értelme? Hiszen így nem kaptunk teljes képet az adatbázisunkról. Lett viszont két táblánk és ha minden egyes adatra kíváncsiak vagyunk ami csak az adott terméket jellemzi, akkor máris két táblában kell keresnünk a megfelelő értékeket. Vagy mi van akkor, ha pl. 10-15 különböző táblában kellene kutakodnunk ahhoz, hogy egy termék összes információjához hozzájussunk?

A kérdés jogosan vetődött fel. Mégis azt kell erre mondanunk, hogy érdemes, sőt szükséges az adatbázisunkat 3NF-ba hozni. Léteznek ugyanis a modern adatbázis kezelőrendszerekben ún. nézettáblák, amely az általunk megadott lekérdezések eredményét adják vissza. Ha megfelelően összekapcsoljuk a különböző táblákban szereplő információkat, akkor minden egyes táblából kinyerhetjük azokat az adatokat, amelyekre nekünk szükségünk van, és mégsem esünk a redudancia hibájába.

 

Nézettábla alkalmazásával egy terméket jellemző összes információt egyetlen táblázatba gyűjthetjük ki.

 

Nézettáblákkal a későbbi cikkek során bővebben is foglalkozni fogunk.

 

A következő résztől elkezdjük relációs adatbázisok saját lekérdezőnyelvének megismerését, az SQL nyelv alapjainak bemutatását.

 

Kiszely Gábor -  kg@kgb.hu