Relációs adatbázis

Relációs adatbázisnak nevezzük a relációs adatmodell elvén létrehozott adatok összességét, a relációs adatmodell fogalomrendszerében meghatározott ún. relációk egy véges halmazát. Relációs adatbázisokat relációs adatbázis-kezelőkkel hozhatunk létre, szerkeszthetünk és törölhetünk.

A relációs adatmodellben a reláció halmaz, ennek megfelelően a reláció minden eleme (sora) egyedi. A tipikus relációs adatbázis-kezelők ehhez képest három módosítással élnek: egyrészt a relációk jellemzően nem halmazok, hanem zsákok (angolul: bag, ismétlődéseket is megengedő, rendezés nélkül elemek összessége), másrészt nem teszik lehetővé, hogy egy relációnak két azonos nevű attribútuma (oszlopa) legyen, harmadrészt pedig lehetőség van az ún. NULL (üres, ismeretlen) értékek használatára.

A relációs adatbázisok kialakításának sajátosságaival az adatbázis-tervezés foglalkozik.

A relációs adatbázis részei

Felhasználók és jogosultsági rendszer

Az adathozzáféréshez jogosult felhasználók és jelszavaik nyilvántartása. A felhasználók minden tevékenységét egy jogosultsági rendszer ellenőrzi. Ez a jogosultsági rendszer lehet hierarchikus (pld. Sybase Anywhere) vagy egyszintű (pld. Oracle).

Hierarchikus jogosultsági rendszer esetén csoportok és alcsoportok (group) képezhetők, egyszintű jogosultsági rendszer esetén szerepekről (role) beszélünk. A csoportoknak és a szerepeknek részletesen szabályozhatók a jogaik: a hozzáférés engedélyezése vagy tiltása az adatbázis objektumaihoz. Nagyon sokféle jogosultság képzelhető el egyetlen objektum elérésénél is, de a legalapvetőbbek: olvasás, futtatás, módosítás, törlés, szerkezet megváltoztatása.

Mind hierarchikus, mind egyszintű jogosultsági rendszer esetében minden felhasználó több csoportba vagy szerepbe is besorolható. A jogosultsági rendszer világosan leírja, hogy egymásnak ellentmondó jogok közül melyik jut érvényre (effektív jogosultság).

Nem támogatott, de lehetséges az egyes felhasználók hozzáférési jogainak külön, egyedi szabályozása is. Szerepeken vagy csoportokon keresztül szabályozni azonban sokkal hatékonyabb.

A jogosultságot kezelő rendszer fenti fajtája mindig az adatbázis-kezelő része.

Táblák

A táblákban tároljuk az adatokat. A táblák felépítése: azonos szerkezetű sorok (rekordok), különböző típusú oszlopok (attribútumok, mezők).

Példa (Beteg tábla):

Tajszám	Vezetéknév	Keresztnév	Születési dátum
123 456 789	Kovács	István	1933.03.03
987 654 321	Horváth	Géza	1967.12.23

Az egyes oszlopoknak kötelező adattípust adni. A relációs adatbázisokban leggyakoribb adattípusok:

• szám (NUMBER)
• rögzített hosszúságú karakteres (CHAR)
• változó hosszúságú karakteres (VARCHAR, korábban CHAR VARYING)
• dátum (DATE)
• idő (TIME)
• dátum és idő (TIMESTAMP)
• nagyméretű karakteres (long varchar – character large object – CLOB)
• nagyméretű bináris (long binary – binary large object – BLOB)

Minden oszlopnak meghatározható egy alap (default) érték, például egy szám, vagy az aktuális rendszerdátum. Amennyiben a táblázat egy sorában nem töltenénk ki ezt az oszlopot, úgy a relációs adatbázis-kezelő ezt az alapértéket illeszti be ide.

A táblában meg kell jelölni, hogy melyik mező, vagy melyik mezők együttesen az elsődleges kulcsok. Az elsődleges kulcs minden rekordban egyedi: a fenti példában a tajszám.

A táblákat és az egyes oszlopokat megjegyzésekkel is elláthatjuk, így lehetővé téve, hogy az adatbázis öndokumentált legyen, és ne legyen szükséges külön dokumentációt vezetni.

Nézetek

A nézet tulajdonképpen egy állandósított lekérdezés: egy vagy több tábla valamely oszlopai egymás mellé rendezve. Ha több tábláról van szó, akkor a nézet az összekapcsolás szabályait is tartalmazza. Mint neve is mutatja, általában arra használjuk, hogy adatainkat egy bizonyos szemszögből, egy bizonyos rendezettséggel mutassa.

A nézeteket megkülönböztetjük aszerint, hogy csak olvasható, vagy módosítható a tartalmuk.

Indexek

Az index a táblához kapcsolódó, gyors keresést lehetővé tevő táblázat. Az index tartalmazza, hogy a tábla rekordjai egy vagy több oszlop alapján (pld. vezetéknév és keresztnév) sorba rendezve hogyan következnek egymás után. Fontos, hogy ez nem jelenti a teljes tábla megismétlését többféle rendezettséggel: az index csak egy mutató, amely hivatkozik a táblára.

Az indexek szerkezete általában B-fa, ami nagyon gyors (a soros, "minden rekordot egymás után megvizsgálunk" kereséshez képest egy nagyságrenddel gyorsabb) keresést tesz lehetővé.

Az indexek létrehozása jelentősen növeli az adatbázis hatékonyságát, de a méretét is. Egy általános adatbázisban az indexek helyfoglalása körülbelül akkora, mint az adatoké.

Kényszerek

Kényszer (constraint): a lehetséges adatok halmazát leíró, korlátozó szabály. Sokan a tábla elsődleges kulcsát is egyfajta megszorításnak tekintik, hiszen az elsődleges kulcs maga után von egy egyediségi (UNIQUE) kényszerfeltételt. Mi itt a külső kulcsokról (foreign key) szólunk, amelyek a relációs adatbázis szempontjából rendkívüli fontosságúak.

Egy külső kulcs megszorítás meghatározza, hogy egy tábla bizonyos oszlopa csak egy másik tábla egy bizonyos oszlopának értékeit veheti fel.

Példa (Lelet tábla):

Lelet száma	Tajszám	Lelet kérés dátuma	Lelet elkészült	Leírás
17543	123 456 789	2004.08.18.	2004.08.19.	Sürgős
17544	123 456 789	2004.08.19.	2004.08.23.	Kontroll vizsgálat
17545	987 654 321	2004.08.23.	2004.08.25.	Dr. Szabónak átküldeni

Ehhez a táblához olyan külső kulcsot kell létrehozni, amely előírja, hogy a tajszám oszlop csak olyan értékeket vehet fel, amelyek a Beteg tábla tajszám oszlopában szerepelnek. Ezzel az előírással az adatbázis integritását, helyességét biztosítjuk, ezért is szokták a külső kulcs megszorításokat integritási megszorításoknak is nevezni (integrity constraint). Ha ezt a megszorítást nem alkalmazzuk, akkor könnyen kerülhetnek olyan rekordok a Lelet táblába, amelyekben olyan tajszám szerepel, ami a beteg nyilvántartásban nem létezik.

A külső kulcs definíciójánál kitérhetünk arra is, mi történjen a Lelet tábla tajszám mezőjével, ha a Beteg tábla hivatkozott rekordjának tajszám mezőjét megváltoztatjuk:

• változzon vele együtt (on update cascade)
• vegyen fel Null értéket (on update set null)
• egyáltalán ne engedje a Beteg tábla TAJ szám mezőjének módosítását (on update restrict)

Ugyanezt törlések esetére is előírhatjuk:

• törlődjön vele együtt (on delete cascade), hiszen ha a beteget törlik, akkor a leleteire már nincs szükség
• vegyen fel Null értéket (on delete set null)
• egyáltalán ne engedje a Beteg tábla hivatkozott rekordjának törlését (on delete restrict)

Triggerek

Elfogadott, elterjedt magyar nyelvű megnevezése még nincs.

A trigger egy eseményre adott automatikus válasz. Nem az adatbázis, hanem az adatbázis-kezelő része. Egy trigger tipikusan három elemből tevődik össze: eseményből, feltételből és egy utasításból, ezért leírható egy ún. ECA-modell (ECA: Event, Condition, Action) segítségével. Az adatbázis-kezelő egy bizonyos esemény hatására (ez a triggeresemény) megvizsgálja az eseményhez kötött feltételek (triggerfeltételek) teljesülését. Ha feltétel teljesül, akkor hajtja végre a trigger leírásában meghatározott programkódot. Minden más esetben tétlen marad.

A változás hatására elinduló programnak többféle célja lehet: üres mezők kitöltése, integritás biztosítása, keresőmezők létrehozása stb.

Megkülönböztetünk sor-szintű és tábla-szintű triggereket. A sor-szintű trigger egy-egy módosítás után rekordonként egyszer végrehajtódik, a tábla-szintű trigger viszont a módosítás után csak egyszer, függetlenül attól, hogy egyszerre hány sor (rekord) módosult.

A relációs adatbázis létrehozása

A relációs adatbázist általában valamilyen segédprogrammal hozzuk létre, amelyet a relációs adatbázis-kezelőkhöz adnak a gyártók. A relációs adatbázis létrehozása után csak a rendszer táblákat tartalmazza, egyéb szempontokból üresnek tekinthető.

A létrehozás után az adatbázis adminisztrátora a gyárilag beállított felhasználói néven és a gyárilag megadott jelszóval tud belépni az adatbázisba, és hozzáfoghat az adatbázis objektumok létrehozásához.

A relációs adatbázis futtatása

A relációs adatbázist általában egy kiszolgáló, egy adatbázis motor teszi elérhetővé a felhasználók számára. Az adatbázis motor képes a kérések párhuzamos kezelésére, a naplózásra, a hibák észlelésére. Kritikus hiba esetén azonnal leáll, hogy az adatok helyessége ne sérüljön.

Az adatbázis motor általában egy külön kiszolgáló számítógépen fut, de ez nem szükségszerű: futhat azon a gépen is, ahol a felhasználó dolgozik. Kisebb hálózatok esetén szokásos egy erősebb munkaállomásra telepíteni az adatbázis motort.

A fejlettebb adatbázis motorok biztosítják a tranzakciókezelést, amely óvja az adatok épségét (integritását). Ha egy felhasználó egy műveletsort nem tud befejezni (például programhiba miatt), akkor a műveletsort (tranzakciót) vissza lehet görgetni (rollback) a kezdőponthoz. Ha a műveletsor sikeres volt, akkor pedig jóvá kell hagyni azt (commit).

Kapcsolódó szócikkek

• Adatbázis
• Adatmodell
• Tudásreprezentáció
• Relációs adatmodell
• Relációsadatbázis-kezelő rendszer