Relációs adatbázis
A Wikipédiából, a szabad enciklopédiából.
 |
Ez a szócikk (vagy szakasz) nem tünteti fel a forrásokat, melyek segítségével készült. Segíts megbízható forrásokat találni, hogy alátámaszthassuk, ami a lapon olvasható! Az ezen a lapon látható jelölés 2007 augusztusából származik. |
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 hozhatjuk létre, szerkeszthetjük és törölhetjük.
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.
Tartalomjegyzék |
[szerkesztés] A relációs adatbázis részei
[szerkesztés] 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.
[szerkesztés] 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):
| TAJ szá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 hozzú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 TAJ szá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.
[szerkesztés] 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.
[szerkesztés] 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é.
[szerkesztés] 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 | TAJ szá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 TAJ szám oszlop csak olyan értékeket vehet fel, amelyek a Beteg tábla TAJ szá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 TAJ szá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 TAJ szám mezőjével, ha a Beteg tábla hivatkozott rekordjának TAJ szá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)
[szerkesztés] Eljárások és függvények
A legtöbb relációs adatbázis-kezelő rendelkezik valamilyen lineáris programozási nyelvvel, aminek segítségével különböző műveleteket végezhetünk az adatokon. Ez a nyelv legtöbbször az SQL valamelyik változata, dialektusa, vagy a Java programozási nyelv. Az adatbázisban függvényeket és eljárásokat hozhatunk létre ezen a nyelven, amelyek megkönnyíthetik az adatok kezelését.
A függvények és eljárások hívását ugyanúgy a jogosultsági rendszer ellenőrzi, mint az adatokhoz való hozzáférést.
[szerkesztés] Triggerek
Bővebben: Trigger (adatbázisok)
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.
[szerkesztés] 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.
[szerkesztés] 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).
[szerkesztés] Lásd még
- Adatbázis
- Adatmodell
- Tudásreprezentáció
- Relációs adatmodell
- Relációs adatbázis-kezelő
