Relációs adatbázis
 |
Ez a szócikk nem tünteti fel a független forrásokat, amelyeket felhasználtak a készítése során. Emiatt nem tudjuk közvetlenül ellenőrizni, hogy a szócikkben szereplő állítások helytállóak-e. Segíts megbízható forrásokat találni az állításokhoz! Lásd még: A Wikipédia nem az első közlés helye. (2007 augusztusából) |
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áziskezelők|relációs adatbázis-kezelőkkel hozhatunk létre, szerkeszthetünk és törölhetünk.
Reláció (azaz kapcsolati viszony) jön létre egy adatbázisban például azzal, hogy a tárolt nevek mindegyikéhez tartozik egy a tárolt személyi számok közül. Technikai, adattárolási szempontból ezt kétféle módon is megoldhatjuk. Az egyik: külön tároljuk a neveket és külön a személyi számokat, és a nevekhez hozzákapcsolunk egy mutatót, amely megmutatja, hogy a személyi számok közül melyik tartozik egy névhez. Ez technikai reláció, amikor a kapcsolatot egy rövid közvetítő adattal tároljuk. A másik: minden névvel együtt tároljuk a hozzájuk tartozó személyi számot. Ez elvi reláció, amelyben nincs közvetítő adat, a reláció csak névleges, technikailag a relációban álló két elem egyszerre érhető el.
Az elméleti relációs adatmodellben a reláció halmaz, ennek megfelelően a reláció minden eleme (sora) egyedi. A tipikus [Relációsadatbázis-kezelő rendszer|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.
Tartalomjegyzék
A relációs adatbázis részei[szerkesztés]
Felhasználók és jogosultsági rendszer[szerkesztés]
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[szerkesztés]
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[szerkesztés]
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[szerkesztés]
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[szerkesztés]
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 tajszá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[szerkesztés]
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[szerkesztés]
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[szerkesztés]
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).
