Objektum orientált adatbázisok alapfogalmai
Az objektum orientáltság koncepciója az informatika szinten minden területén
egyre nagyobb teret hódít az utóbbi években. Az objektumok előbb a
hagyományos programozási nyelvekben, mint nyelvi elemek jelentek meg, majd
elterjedtek egyéb alkalmazás fejlesztési eszközökben is, sőt a fejlesztési
módszertanok között is kialakultak az objektum orientált irányzatok. Ezen
általános fejlődési tendenciából az adatbázis kezelés sem maradt ki.
Napjainkban már sokan az objektum orientált adatbázis kezelő rendszerek
tekintik a DBMS-ek következő generációjának, mely nem is soká át fogja
venni a hatalmat a relációs modelltől.
Mivel eddigekben szinte kizárólag a relációs modellen alapulú
adatbáziskezelésről esett szó, s hogy ne maradjon említés nélkül e fontos
fejlődési irány sem, a következő fejezetben ezen új modell lényegi elemeit
fogjuk áttekinteni.
Mindenek előtt tisztáni kell, hogy mit is értünk objektum orientált adatbázis
kezelés alatt. A megnevezésben szereplő fogalmak külön-külön már bizonyára
mindenkinek ismerősek, mindenki tudja mit is takarnak. Mint várható, így
együtt e diszciplínák, területek egyfajta ötvözését fogjuk kapni. Ennek
megfelelően megalkotható egy induló definíció, mely mögött húzódó
jellegzetességekre a későbbiekben fokozatosan bepillantást kapunk.
Így objektum orientált adatbázis kezelő rendszernek (OODBMS, object
oriented database management system) nevezzük az objektum orientáltság
elveire épülő adatbáziskezelő rendszert.
Ha közelebbről megvizsgáljuk az előző definíciót, látható, hogy az OODBMS
két alappilléren nyugszik:
- OO, azaz objektum orientáltság
- DBMS, az adatabázis kezelés
E két, külön-külön is hatalmas terület ötvözésének célja az, hogy az
adatbázisok felett futó alkalmazások kihasználhassák az objektum orientáltság
előnyeit, s lehetőség legyen az adatbázisban az emberi szemlélethez közelebb
álló és fejlesztés munkáját jelentősen megbízhatóbbá és gyorsabbá tévő OO
elvek megvalósítására. Mindezt úgy, hogy közben a DBMS továbbra is
biztosítsa a megszokott szolgáltatásokat az adatvédelem, az integritásőrzés, a
tranzakció kezelési és az optimalizálás területén.
Tehát mit is kívánnak nyerni a felek a házasság révén. Az DBMS világ egy új
adatmodellt, amely emberközelibbé és hatékonyabbá teszi az adatbázis
alkalmazások fejlesztését. Az OO meg egy hatékony, megbízható permanens
adatkezelő mechanizmussal szeretne gyarapodni.
Ha az OODBMS-ek lehetőségeit szeretnénk megismerni, akkor célszerű előbb a
legfontosabb elvárt jellemzőket felidézni, hogy azok részletes vizsgálatával
közelebb jussunk a reális értékeléshez.
Az OODBMS tehát két fő forrásból származik, így legfontosabb elemeit is
valamelyik szülőtől örökölte. A következő lista ezen jellemzők bemutatását
adja.
OO forrásból származó elemek:
- ADT kezelése
Az ADT egy osztálynak megfeleltethető szerkezet, amely az absztrakt
adattipus elnevezésre utal. Az ADT nemcsak az egyed mögöt húzódó struktúrát,
hanem az egyedhez kapcsolódó tevékenységeket is magába foglalja. Az ADT-
hez kapcsolható metódusok jelentősége abban áll, hogy ellenőrzöttebbé válik az
egyes adatelemeken végzett trevékenység, hiszen most lesz egy központi
mechanizmus, amely tárolja, hogy milyen műveletek végezhetők az
adatbázisban. A relációs modellekben az alkalmazások sokkal nagyobb
szabadsággal rendelkeztek, s ezzel együtt nagyobb volt annak veszélye, hogy
különböző alkalmazások másképpen értelemzik, interpretálják az adatokat.
A relációs modellnél csak az adatkezelő műveleteket lehetett szabályozni,
vagyis azt, hogy az adatelemre engedjük-e és kinek a SELECT, INSERT,
UPDATE, DELETE, stb. végrehajtását. Ezek a műveletek formális adatkezelő
műveletek voltak, melyekben semmiféle utalás és kapcsolat sem létezik az
adatelemben tárolt adat jelentésére vonatkozóan. Ugyan a trigger
mechanizmussal lehetett egyfajta értékellenőrzést végeztetni az adatkezelés
során, de ezek működési elve és szerepe lényegesen eltér a metódusok
szerepétől. A triggerek egy nem kötelező jellegű ellenőrző szerepet játszottak, s
bárminemű műveletet megengedtek, ami a definiált ellenőrzési feltételen
átjutott. A metódusok ezzel szemben kötelező jellegűen, a lehetséges
hozzáférési lehetőséget definiálják, hiszen az ADT-hez csak a metódusain
keresztül lehet eljutni. A triggerek nem közvetlenül hívódnak meg, a hanem
közvetve, a metódusokat pedig közvetlenül is lehet aktivizálni. A metódusok
szemantikai tartalmat hordoznak, a triggerek közvetlenül nem hordoznak
szematikai tartalmat. Ugyancsak lényeges eltérés e két mechanizmus között,
hogy míg a triggerek továbbra is a felhasználó jogköre alatt futnak, addig a
metódusoknak más műveleti, adathozzáférési hatásköre lehet, mint a hívó
egyednek. Tehát a metódusok is számtalan új és hasznos lehetőséget hozhatnak
be az adatbáziskezelés területére.
Az ADT másik jellegzetessége, hogy a struktúrális részében összetett
attributumai is lehetnek, s az ADT elemek egymásba ágyazhatók. Az
adatmodellezés sempontjából ez annyit jelent, hogy itt már nincs szükség a
relációs modellben megszokott szétdarabolgatásokra (emlékezzünk a
dekompozíciós tervezési módszerre). A logikailag összetartozó adatelemek
egységként tárolhatók, vagyis a felhasználónak, az alkalmazás fejlesztőnek nem
kell törődnie többé a megfelelő adetelemek összeszedéséről közvetlenül lehet
hivatkozni a stuktúra elemekre. Az ADT alkalmazásával sok-sok korábbi join
művelettől megszabadulhatunk.
- ADT egyedisége, elrejtése
A relációs modellben egy rekordot a benne tárolt mezők értékei alapján
azonosítottunk. A kapcsolatoknál a kapcsoló kulcs egy értéket tartalmzott, s az
a rekord lesz a kapcsolódó rekord, ahol a kulcsmező értéke megegyezik a
kapcsoló kulcs értékével. Ha megváltozik a kulcsmező értéke, akkor úgymond
egy új egyedelőfordulás jön létre. Az OO rendszerekben ezzel szemben
bevezetik az objektumok egyediségét, önálló létét. Vagyis egy objektum az
attributumainak értékeitől függetlenül létezik, az objektum mindíg ugyanazaz
az objektummarad, bármilyen állapotba is kerülne.
Ugyancsak lényeges eltérés a relációs modellhez képest, hogy a relációs
modellben a tábla tárolási struktúra egy nyitott szerkezetet jelent, ha
engedélyezett a rekordok olvasása, akkor a rekord mindenmezője is látható. Az
ADT alkalmazásakor azonban az ADT egyfajta elrejtést, közvetlen hozzáférési
védelmet is hordoz magával. Az ADT esetén csak a megszabott kapukon
keresztül lehet bejutni az ADT belső szerkezetéhez.
- Öröklés
Az OO technika fontos eleme, hogy a tipusok, osztályok között egy öröklési
hierarchia állítható fel. Az öröklés segítségével áttekinthetőbb lesz az egyes
tipusok definíciója és az alkalmazása is. Sokkal megbízhatóbbá válik a
módosítások elvégzése is, hiszen minden lényege elemet elegendő csak egy
helyen megadni, nincs szükség ismétlődő részekre az egyes tipusok
megadásánál. Az öröklés során mind az adatszerkezetek, mind a metódusok, a
viselkedés is öröklődhet.
Most nézzünk néhány DBMS örökséget:
- Adatok permamens tárolása
A hagyományos programozási nyelvekben a permamens adattárolás az
operációs rendszer RMS komponensén keresztül valósul meg. Az adatok RMS-
en keresztül történő mentése, beolvasása formálisan is több ponton is eltér a
memóriában tárolt változók kezelésétől, s egy sor extra programozási feladatot
kíván meg a programozótól. A DBMS ezzel szemben egy egyszerűbben
kezelhető és gyorsabban programozható tárolási mechanzimust biztosít az aatok
hosszú idejű tárolására.
- Függetlenségi szintek
A DBMS rendszerek jellemzője, hogy a felhasználónak nem kell ismernie az
adatok fizikai tárolási mechanizmusát, formátumát. A felhasználó egy
emberközelibb kezelő nyelv segítségével kommunikálhat a DBMS-sel, amely
majd lefordítja a kapott magas szintű utasítást a végrehajtáshoz szükséges
fizikai szintre. E függetlenségi szint gyorsabb és kényelmesebb alkalmazás
fejlesztést, könnyebb kezelhetőséget biztosít.
- Konkurrens adatkezelés biztosítása, recovery, védelem
A DBMS egyidejűleg több párhuzamos kérés kiszolgálására alkalmas
mechanizmussal működik, így az adatok osztottan, több felhasználó által
egyidejűleg is elérhető módon tárolódnak az adatbázisban. Ez a követelmény
alapfető feltétele egy szervezeti egységre készített információs rendszer
létrehozásának, ahol szükségszerű a párhuzamos hozzáférések biztosítása. A
hagyományos programfejlesztési eszközökkel a konkurrens igények kielégítése
csak nehezen és részlegesen oldható csak meg. A DBMS által igényelt extra
szolgáltatások közé tartozik még a hozzáférések jogosultságának ellenőrzése, az
adatok sérülés elleni védelme is.
- Ad-hoc lekérdező rendszer
A DBMS rendszerek fontos eleme egy rugalmas lekérdező nyelv, amellyel
egyszerűen és hatékonyan lehet a felhasználóhoz közel álló formátumban
információt kinyerni a rendserből. E nyelv lényeges eleme, hogy hozzáférést
biztosít az adatbázis minden olyan eleméhez, melynek elérését a védelmi
szabályok nem tilják. E rugalmasságra azért is szükség van, mert az adatbázisok
tervezésének pillanatában még nem lehet biztosan tudni, hogy a távolabbi
jövőben milyen igények merülnek majd föl, illetve a felhasználói igények igen
széles skálán mozoghatnak, amiket szinte lehetetlen átfogni és előre
megtervezni.
Az OO és a DBMS elvek illesztéséből létrejövő OODBMS rendszerek
fejlődésébe az több informatikai szakterület eredményei is hatással voltak. Az
alábbi ábra az OODBMS kialakulásában fontosabb szerepet játszó területeket
mutatja be.
Az OO technika az 1980-as évek elején alakult ki és terjedt el, melynek százlós
hajój a Smalltalk fejlesztő nyelv volt. A Smalltalk után napjainkra egy másik
objektum orienált nyelv, a C++ vette át a vezető szerepet. Sokan ebben annak
az állításnak a bizonyítását látják, hogy az indformatikában sem szeretik az
emberek a nagy lépésekben történő forradalmi változásokat, sokkal inkább
ragaszkodik az alkalmazás fejlesztők társadalma a megszokott, bevált
dolgokhoz, s a kisebb lépésekben történő haladást. Természetesen e jelenség
mögött a megszokott rendszer biztonsága, megbízhatósága is lényeges szerepet
játszik.
Az OO-hoz kapcsolódóan megemlíthető, hogy nemcsak az OO alapú fejlesztő
rendszerek, hanem az OO alapú alkalamzás fejlesztési módszertanok, az OO
alapú rendszerek működése is lényeges hatással volt az OODBMS -ek
kialakulásában.
A DBMS-ek részéről elsősorban a relációs modell játszott kiemelkedő szerepet
az OODBS-ek kidolgozásában, mint a legelterjedtebb és legjobban bevált
DBMS rendszer. A RDBMS-ek mint tudjuk az 1970-es évek vége felé kezdek
megjelenni a piacon, de igazi sikereke csak a 80-as évektől kezdve értek el. A
relációs modell mellett azonban más modellek is hatással voltak az OODBMS-
ek funkcionális szerkezetének kialakításában. Itt elsősorban azokra a
szemantikai adatmodellekre (SDM) gondolunk, melyek a komplex struktúrák
tárolási lehetőségeit, a feljhasználóhoz közel álló kezelő felületek kialakítására
irányultak.
Az első OODBMS rendszerek az 1980-as évek végén, 1987 körül jelentek meg.
Mint ahogy a tapasztalat mutatja, az elvek megszületésétől az érett piaci termék
megjelenéséig 10 év körüli időre van szükség, mára már megjelentek az piacon
az RDBMS-ek vetélytársaként feléépő OODBMS rendszerek is. Ez a
megjelenés azonban nem igazán olyan szintú és jellegű, mint ahogy a leleks
OODBSM hívek azt korábban várták, a térhódítás egy kicsit lassabb és
ellentmondásosabb.
Nézzük, hogyan is jellemezhető röviden a ma létező OODBMS rendszerek. Az
OODBMS-ek mellett pozitív tulajdonságként felhozható, hogy
- igen népszerű, nagyon sok helyen foglalkoznak OO alapú adatbázis
rendszer kifejlesztésével, sok helyen vizsgálják, hogy mennyire tudná
az igényeiket kielégíteni egy OODBMS rendszer.
- nagyon sok egymástól független, párhuzamosan dolgozó műhely
alakult ki az OO adatbázis kezelő rendszerek kidolgozására és
fejlesztésére.
- biztosítja az OO elvek megvalósítását
- szoros kapcsolódást bíztosít az egyéb OO alapú fejlesztő eszközökhöz,
fejlesztő nyelvekhez
Az OODBMS-ek kialakulásában azonban bizonyos gyenge pontokat is
felfedezhetünk, melyekből az elábbiakat emeljük ki:
- az OODBMS kifejlesztése nem egy helyről indult el, hanem több
önálló kutató-fejlesztő egység is kialakult, melyek mindegyike egy kicsit
másképp értelmezte és oldotta meg az OODBMS különböző funkcióit.
Emiatt nem alakult ki egy egységes értelmezés és specifikáció rendszer a
fejlesztések elindulásakor, ami ahhoz vezetett, hogy csak utólag, egy
későbbi időpontban indult el egyfajta szabványosítási folyamatat. Az
OO adatmodell nem rendelkezik olyan induló elméleti
megalapozottsággal, mint a relációs modell, a modell lényegesebb
elemei egy folyamatos érlelődés hatására születnek csak meg.
- az első OODBMS rendszerek teljesítményben, megbízhatóságban
lényegesen alacsonyabb szinten álltak, mint az akkor már befutott
RDBMS rendszerek. Emiatt a felhasználók sem választották ezt a
megoldást a kritikus feladatok megoldására. Az OODBMS rendszerek
még ma is nagyrészt kisérleti állapotban vannak, s csak most érezhető
egy erőteljesebb piaci elmozdulás az OODBMS világ felé.
A piacon jelenleg is létező OO alapokat biztosító adatbáziskezelő rendszerek
igen különböző szolgáltatásokat nyujtanak és igen eltérő belső struktúrával is
rendelkeznek. Mint ahogy említettük is, az egységes elméleti alapok hiánya
miatt igen sokféle megvalósulású OODBMS rendszerek léteznek, melyekben az
OO elvei is igen különbözőképpen valósulnak meg. Mivel az OODBMS két
különböző terület egyesítéseként jött létre, léteznek olyan változatpok, meltyek
az OO programozás oldaláról, míg mások az RDBMS oldaláról kiindulva
közelítenek a megogalamzott célok felé.
Az egyik legegyszerűbb megvalósítási szintet a hagyományos OO nyelvek
kiegészítése jelenti. Ez rendszerint egy speciális, saját könyvtár létrehozását
jelenti, amely a permanens adatkezeléshez szükséges adattárolási funkciókat
valósítják meg. Ekkor a fejlesztés menete megegyezik a normál programok
készítésének menetével, azzal a különbséggel, hogy az adatok tárolását egy
csatolt függvény gyüjtemény felhasználásával gyorsabban és egyszerűbben
megoldhatjuk, mintha csak a RM szolgáltatásaira támaszkodhatnánk. Ebben a
megoldásban nem létezik igazi DBMS rendszer, mint amilyennek az Oracle
RDBMS tekinthető. E rendszerekben sokszor hiányzik a védelem, a tranzakció
kezelés, az optimalizálás és a rugalmas lekérdező nyelv is.
A másik oldalról induló próbálkozások közé tartoznak azon első lépések is,
amikor nem magát az adatbáziskezelő rendszert kívánták megvaáltoztatni,
hanem csak az RDBMS arcát, amit a felhasználó felé mutat. Ennek jegyében
számos olyan próbálkozás volt, amelyek az RDBMS felé egy objektum
orientált kezelő felületet fejlesztett ki. A felhasználó ekkor objektumokkal
dolgozhat, melyet a kezelő felület állít össze az RDBMS-ből származó
adatokból. A felhasználó rendszerint az objektumok közötti kapcsolatokon
mozogva, navigálva kérdezheti le az adatbázis tartalmát.
Igen elterjedt még az a módszer is, amikor az RDBMS-eket az alap OO
elvekkel egészítik ki. Ennél a megoldásnál új tárolási struktúrákat és adatbázis
objektumokat vezetnek be, meghagyva a relációs modellhez tartozó elemeket is.
E megoldás előnye, hogy a DBMS szolgáltatások már készen rendelkezésre
állnak, s a módosításnál, az új elemek bevonásánál is támaszkodhatnak a
DBMS fejlesztők a korábbi szolgáltatásokra.
A lehetséges megoldás tipusok negyedik csoportja az új alapoktól induló
OODBMS rendszerek jelentik. Ezen adatbázis kezelők a tiszta OO alapokra
támaszkodnak, a nulláról indulva hozzák őket létre, megvalósítva bennük
minden igényelt szolgáltatást. Ez a megoldás ugyan a legnagyobb
erőráfordítással jár, de egyben ez egy tiszta, egységes rendszer megvalósulását
igéri.
A OODBMS-ek kialakulását követve itt is megfigyelhető egy ugyanolyan
polémia, mint ami a relációs modell kialakulását kisérte. Mint ahogy a relációs
modell létjogosultságát is sokan megkérdőjelezték, úgy a OO adatmodellel
szemben is érezni bizonyos ellenállást. Erdekes megemlíteni Date véleményét
ezzel kapcsolatban. Date, mint a relációs modell nagy alakja, igen kritikusan
vélekedik a relációs modellről egyik könyvében. Ebben Date kifejti, hogy
milyen szempontból nem tartja egyeduralkodónak egy tiszta OODBMS
rendszert. A leglényegesebb megemlített hiányosságokat a következő lista
tartalmazza.
- Az OODBMS-ek kezelő nyelve a fejlesztő eszközökhöz (C++)
való simább illeszkedés miatt egy rekordorientált megközelítést mutat,
amely egy lényeges visszalépést jelent a relációs modellben megszokott
halmazorientált kelezési felülethez képest.
- Az OODBMS-ek több hiányossággal is rendelkeznek az adatok
integritási ellenőrzésére vonatkozólag. Így például nincs megfefelő
mechanizmus a kapcsolatok számosságának az ellenőrzésére, s nem
lehet deklaratív integritási feltételeket sem megadni.
- Hiányzik az adatok rugalmasabb megjelenését biztosító nézet (view)
lehetősége, ami rendkívül fontos lenne az adatbázis függetlenségi
szintjeinek megvalósításához, az adatkezelés egyszerűsítése és védelme
szempontjából is. Ezenkívül az OODBMS-ek nem rendelkezenek egy
hatékony és rugalmas lekérdező nyelvvel, amely a SQL SELECT
utasításhoz hasonló szolgáltatásokat tudna gyújtani. Egy érdekes
probléma ebből a szempontból, hogy mennyire illeszthető össze az
általános lekérdezés által igényelt nyíltság a objektumok zártságának az
elvével.
A fenti elméletibb jellegű kifogások mellett a gyakorlati szakemberek az
OODBMS-ek megvalósításának a kérdőjeleit is fel szokták hozni az
értékeléskor. Az olyan gyakorlati kételyek, mint hogy
- megfelelő lesz-e az OODBMS hatékonysága
- tud-e majd a rendszert nagy adatmennyiséget is kezelni
- mennyire megbízhatóak az OODBMS-t fejlesztő cégek
- mennyire szabványosak az egyes OODBMS-ek
mutatják, hogy a gyakorlatban még egyenlőre várni kell az OODBMS teljes
térhódítására.
A relációs kontra OO adatmodell vitában azonba mára már nem az fő kérdés,
hogy kell-e objektumokat tárolni az adatbázisokban, mivel ennek
szűükségességében mindenki egyetért, hanem azon folyik a vita, hogy milyen
módon, hogyan célszerű az objektumok tárolását megvalósítani. Itt két fő tábot
létezik, az egyik szerint a tiszta OODBMS-t, a mások szerint a ORDBMS-t
(object relational DBMS) célszerű támogatni.
Az OODBMS hívek vazt szokták felhozni fő érvként, hogy az OODBMS-ek
sokkal gyorsabban tudják az egyedek, obejktumok közötti kapcsolatokat
feltárni, mivel az OO elvekben a kapcsolatok pointereken keresztül valósulnak
meg, s nem értékeken keresztül. A relációs modell megközelítését szokták
asszociációs megközelítésnk nevezni, mivel a rekordok kapcsolódása a
megfelelő mezők értékeinek azonosságán, asszociácóján alapszik. Az OO
modell egy navigációs modellt reprezentál, melyben a kapcsolat pointereken
keresztül valósul meg, azaz az objektumban a kapcsolat jelző (a pointer)
elnavigál a kapcsolódó rekordhoz.
A kapcsolatok tárolásánál a nagyobb rugalmasság érdekében, mint azt már az
előző fejezetben is említettük, célszerű egy kétlépcsős mutatót megalkotni.
Azaz van egy központi objektumcím tábla, mely az objektum aktuális helyét
mutatja. Az kapcsolódó objektumok nem közvetlenül magára az objektumra,
hanem e tábla megfelelő bejegyzésére mutatnak. Így az objektum
áthelyezésekor csak egyetlen helyen, a címtáblában kell módosítást végezni. A
hivatkozási pointerek minden objektumban azonosak maradhatnak. A
kétlépcsős láncolást szemlélteti a következő ábra.
A gyakorlati OODBMS -ek bemutatására egy konkrét mintarendszer működési
elvéről adunk egy rövid leírást, mellyel szemlélteni kívánjuk e rendszerek
alkalmazásának módszereit. A példaként kiválasztott rendszer egy kisérleti
rendszer, melyet ingyenesen is le lehet tölteni a hálózatról. A rendszer
elnevezése OBST.
Az OBST a OO nyelvek permanenens tárolással való kibővítésének az elvén
alapszik. A fejlesztés során egy speciális sémaleíró nyelven kell elkészíteni az
objektum tipusok szerkezeti leírását. Ez a leírás egy szövegszerkesztő
segítségével hozható létre és az eredmény egy normál szöveges állományba fog
kerülni. A kapott szöveges állományból az OODBMS compiler-je készít a
kiválasztott fejlesztő nyelv (pl. C++) szintaktikájának megfelelő definíciós
állományt. A fejlesztő ezután ezt a generált állományt veszi elő újra, s befejezi
a definíciók megadását. Ezen a lépés legfontosabb elemi közé tartozik az
objektum tipushoz tartozó metódusok kifejtése. E lépés után már rendelkezésre
a választott fejlesztő nyelv szintaktikájának megfelelő osztály, objektumtipus
definíciók .
A kapott modulokat ezután a rendszer az OODBMS run-time könyvtárához
kapcsolja az elkészült definíciókat, így azok elérhetők lesznek a később
fejlesztendő alkalmazásokból is. E könyvtár e definíciók mellett a permanens
adatkezeléshez szükséges alaprutinokat tartalmazza. Az alkalmazások
fejlesztése a kiválasztott nyelvben (C++) megszokott módon történik, azzal a
különbséggel, hogy a programhoz hozzá kell kötni a megírt definíciókat és
könyvtárakat. A fejlesztés elvét a következő ábra foglalja össze.
A felvázolt leírásból látható, hogy ez a fajta működési elv milyen szoros
kapcsolatban áll a hagyományos fejlesztési mechjanizmusal, s milyen távol van
az RDBMS-ben megszokott működési mechanizmustól.
A felvázoltak és több szakértő alapján is úgy tűnik,hogy könnyebb lesz az
RDBMS oldaláról haladni az OO felé, mint fordítva. Ennek egyik
megnyílvánulása az alábbi kijelentés, mely az Oracle magazinban jelent meg:
'Az RDBMS rendszerek sokkal hamarabb biztosítani fogják mindazon
szolgáltatásokat, amit az OODBMS-ek tudnak, mint ahogy az OODBMS-ek
képesek lennének az RDBMS-el által nyújtott szolgáltatások megvalósítására'
A piacon kialakult RDBMS dominencia miatt is valószínűbbnek tűnik az
RDBMS világból kiinduló OO terjeszkedés fogja jelenteni az OO legfontosabb
megvalósítási formáját az adatbáziskezelésben. Ennek egyik jele az Oracle8
megjelenése. A rendszer, amely valamikor 97 nyarán fog a piacra kerülni, egyik
legfontosabb újdonsága, hogy tartalmazni fog OO elemeket is. Az Oracle8 egy
object-relational rendszernek tekinthető. Az Oracle súlyából kiindulva ez a
megoldás nagyobb teret fog magának meghódítani, mint a korábbi OODBMS
változatok együttvéve.
Mivel az Oracle8-ról még nem áll rendelkezésünkre pontos, utasítás szintű
leírás, ezért csak cimszavakban, röviden adjuk közre a legfontosabb
újdonságokat. Mindenek előtt hangsúlyozni szeretnénk, hogy az Oracle8
továbbra is támogatja a korábban megszokott relációs elemeket, SQL felülelet.
Az újdonságok mind új elemként jelennek meg a létező elemek mellett.
Néhány OO elem az Oracle8 készletéből:
- az adatok a táblák, mezők mellett obejktumokban is tárolhatók
- metódusok definiálhatók az osztályokhoz
- létező relációs táblákra OO objektumok definiálhatók
- tetszőleges bonyolultságú adattipusok hozhatók létre
- tábla mezőtipusa lehet obejktum, másik tábla, pointer más objektumra
vagy LOB elemre (large object, nagy DBMS szempontjából
struktúrálatlan adatelem, pl. mozi, kép, hang)
- a procedurális elemek megadásánál a PL/SQL mellett a C++ és a
Java is beintegrálásra kerül
- OO alapú alkalamzás fejlesztő környezet (Sedona)
Az Oracle8 példája mutaja, hogy mennyire életképesek a relációs alapból
kiinduló mzogás az OO felé. E törekvések nemcsak egy cég jellemvonása,
hanem igen sokan foglalkoznak e folyamattal. E folyamat komolyságát az is
mutatja, hogy már a szabványosítási lépések is megkezdődtek a object
relational felület kidolgozására. E törekvések egyikmegtestesítője az SQL3
tervezet.
Az SQL3 tervezet az ANSI és ISO szervezet projektjének tekinthető, amelynek
célja az SQL92 továbbfejlesztése. Már jó pár éve dolgoznak e tervezeten, de a
feladat bomolultságát mutatja, hogy még ma is számos tisztázásra váró pont,
probléma található a tervezetben.
Az SQL3-t legrövidebben úgy jellemezhetjük, ha megadjuk, milyen forrásokból
származiknak az elemi,milyen irányba történik a továbblépés. Az SQL3
alapvetően négy fő elemből épül fel, mint az a következő ábra is mutatja.
Az SQL3 egyrészt magába foglalja az SQL92 lehetőségeit, tehát az SQL3-ban
is változtatás nélkül használhatók ugyanazon paramcsformátumok, mint az
SQL92-ben. Másrészt az SQL3 bizonyos új relációs elemeket is behoz az
integritási feltételek, a sorok azonosítása, új mezőtipusok terén.
A számunkra most fontosabbnak túnő újdonságok viszont az objektum orientált
elemek és a procedúrális elemek megjelenéséhez kötődnek.
Az SQL3 támogatja az ADT-k alkalmazását, amely során a felhasználó tipus
konstruktorokkal tetszőlegesen összetett obejktumokat hozhat létre. Az ADT-k
a struktúrális elemek mellett metódusokat is tartalmazhatnak. Az ADT-k között
az öröklési kapcsolat létesíthető.
A relációs tábla mezői az SQL3-ban is tetszőleges ADT-hoz tartozó mezőket is
tartalmazhatnak. Az ADT-k megadásánál a metódusok két nagy csoportját lehet
majd megkülönböztetni. Az egyik csoportba kerülnek a szorosan az
adatkezeléshez kapcsolódó rutinok, melyek megmondják, hogy egy objektumot
mikor tekinthetünk kisebbnek, nagyobbnak, vagy egyenlőnek egy másk
objektummal való összehasonlítás során. Ezen metódusokat kell majd
felhasználni például az objektumok sorba rendezésenél is. A metódusok másik
csoportja az objektumtipushoz tartozó egyedi, szemantikai oldalról hozzá
tartozó műveleteit jelenti. Ide tartozhat például egy előléptet művelet a dolgozó
objektum esetén.
Az ADT definíálásra vonatkozó javaslat bemutatására álljon itt egy mintapélda,
amely egy dolgozó objektum tipust fog létrehozni:
CREATE OBJECT TYPE dolgozo (
nev CHAR (20) NOT NULL,
....
PRIVATE
kor REAL CHECK ....,
PUBLIC
EQUALS DEFAULT,
LESS THEN NONE,
ACTOR FUNCTION kor (:P dolgozo) RETURN REAL;
....
RETURN kor
END FUNCTION,
...
ACTOR FUNCTION eloleptet(....
END FUNCTION,
...
);
A példában a dolgozó az ADT azonosító neve, s a definícióban előbb az
attribútumok következnek, majd a ADT-hez tartozó metódusok. A metódusok
leírásánál az SQL3-hoz definiált procedúrális elemeket kell alkalmazni. Az
ACTOR kulcszóval kezdődő metódusok lesznek a viselkedést leíró metódusok.
A létrehozott ADT felhasználató például egy mezőtipus megadásánál is, mint
az következő példa is mutatja:
CREATE TABLE osztaly (
id integer;
fonok dolgozo;
....
);
A példában egy relációs táblát hoztunk létre, amely tartalamaz egy egész tipusú
id mezőt és dolgozó tipusú fonok mezőt.
Az ADT nemcsak táblába, hanem más AFT-be is beágyazható. A beágyazásnak
két tipusát lehet megkülönböztetni:
- beágyazott ADT: amikoris a külső objektum magába foglalja a belső
objektumot, a belső obejktum a külső részeként létezik. A megadás
formátuma:
CREATE OBJECT TYPE fff (
ugynok : dolgoz INSTANCE,
...
- hivatkozott ADT: amikor a külső obejktum csak egy pointert tartalma a
hivatkozott objektumra. A hivatkozott objektum nem része a hivtkozó
objektumnak. Formátuma:
CREATE OBJECT TYPE fff (
ugynok : dolgoz,
...
Vagyis ekkor nem kell szerepeltetni az INSTANCE kulcsszót.
Maguk az objektumok és kétféle alakban létezhetnek, definálható ugyanis
- object ADT, amikor az obejktum egy egyedi OID azonosítót kap, s
ekkor az objektum állapotától függetlenül mindíg egyértelműen
azonosítható lesz az OID-en keresztül. Ez a megközelítés az OO
szemlélethez áll közelebb.
- value ADT, amikor az obejktumnem kap OID azonosítót, így az
objektumot csak az állapotán, az attributumainak az értékén keresztül
azonosíthatjuk. Ez a megközelítés a relációs modellkhez áll közlebb,
ahol a reordot a kulcsmezőinek értéke alapján azonosíthattunk.
A bevezett változások a hagyámányos relációs táblákat sem hagyták érintés
nélkül. Az egyik újdonság a tervezetben, hogy a tábla szerkezete az eddigi
formátum mellett, amikor is a tábla a rekordok halmaza, melyben alapesetben
egy rekordérték többször is előfordulhat, másik két tábla szerkezetet is támogat.
Az SQL3-ban rendelekzésre álló táblatipusok a következők:
- MULTISET: ez a hagyományos felépítés, melynél alapesetben egy
rekordérték többször is előfordulhat a táblában
- SET: itt egy rekordérták csak egyszer fordulhat elő, nem ismétlődhet.
Az ismétlés letiltáshoz nincs szükség kiadni semmilyen UNIQUE
integritási feltételt.
- LIST: a tábla rekordjai között sorrendiséget lehet defniálni, azaz
minden rekordhoz tartozikegy pozició sorszám. Ez a megkölezítés az
xBase rendszerekben megismert mechanizmussal rokon.
Ugyancsak a táblát érinti az változás is, hogy lehetőség van a rekornak, mind
objektumnak a kezesére. Ez megfelel a klasszikus hozzárendelésnek, amikor is
egy relációséma egy osztálynak, míg egy rekordelőfordulás egy objektumnak
értelmezhető. A SQL3-ban minden rekord kaphat egy OID azonosítót, amely
felhasználható kulcs és kapcsoló kulcs szerepkörben is. A rekord mint obejktum
vonást erősíti,hogy létre lehet hozni olyan adadtipust, amely a tábla egy-egy
rekordját tudja tárolni. Ezzel lehetővé válik az is, hogy az eljárásokban
rekordokat lehessen paraméterként vagy visszatérési értékként felhasználni.
Egy másik érdekes új vonás, a relációsséme mint ADT vonatkozásában, hogy a
táblák között is éretelmezhető egy öröklési hierarchia. Azaz egy táblának lehet
szülő táblája. Ebben az esetben a gyerek tábla automatikusan örökli a szülő
táblában tartalmazott mezőket. Az öröklés formátuma a következő:
CREATE TABLE fo (nev CHAR(9), kor INTEGER);
CREATE TABLE al UNDER fo (fiz REAL);
A példában a fo tábla a szülő tábla és az al tábla a gyermek tábla. A
deklarációnál az UNDER kulszó jelöli ki a szülő táblát. A fenti definíció szerint
az al táblában a közvetlenül megadott fiz mező mellett még két mezőt
tartalmaz, a nev és kor mezőket. E két utóbbi mezőt a fo nevű szülő táblából
örökölte.
Az SQL3 másik fő újdonsága a procedurális elemek megjelenése. Az SQL92-ig
az SQL semmilyen procedúrális elemet nem tartalmazott, csak az adatbázishoz
tartozó adatkezelő utasításokat tartalmazta. A procedúrális elemek az SQL-hez
csatlakozó nyelvek, mint pl. a ProC szolgáltatták, vagy egy sajátos procedúrális
elemekkel kibővített SQL verziót, min t amilyen a PLSQL alkottak meg az
egyes fejlesztők.
A procedúrális elemek főbb jellemzői az alábbi pontokba foglalhatók össze:
- saját memória változók is létehozhatók, melybe ideiglenes, köznebső
eredményeket lehet tárolni. A nyelv lehetővé tesz, hogy egy változóba
közvetlenül lehelyezzük egy SQL SELECT teljes eredményét.
- a nyelv tartalmaz feltéteteles elágazás utasításokat, melyek lehetnek
sima
IF feltétel THEN
....
ELSE
.....
ENDIF
és a többszörös elágazást biztosító CASE szerkezetek is.
- Lehetőség van ciklusok szervezésére is, melyek egy
LOOP WHILE feltétel
....
ENDLOOP
alakot öltenek.
- Az SQL3 eljárások egymást is meghívhatják a
CALL azonosító
utasítással.
A vázolt utasításokból, lehetőségekből kitűnik, hogy az SQL3 a PL/SQL
funkciójához és lehetőségeihez közel álló nyelvet célozott meg, amelynek fő
funkciója az adatbázison belüli tevékenységek, metódusok, triggerek
defincíójához leíró eszközként szolgálni.
A relációs modellhez közel álló SQL3 mellett léteznek olyan szabványosítási
törekvések is, melyek inkább az OO oldaláról közelítik meg a feladatot. Az ez
irányú tevékenységek eredménye például egy OQL szabvány tervezet, amely az
Object Query Language rövídítéseként áll. Az OQL célja egy objektum
orientált lekérdező nyelv alapjainak a létrehozása.
Ez a tervezet egy nagyobb, az egész OO világot átfogó egységesítési terv
részeként született. Az OQL egy ODMG (object data management group)
konzorcium munkája, melyben számos olyan fejlesztő cég vesz részt, akik
OODBMS fejlesztésével, forgalmazásával foglalkoznak. Az ODMG pedig az
általánosabb célkitűzéssel működő OMG (object management group) egyik
alosztályaként dolgozik.