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