Akit magyarnak teremtett az Úristen és nem fogja pártját nemzetének 
 - nem derék ember

Gróf Széchenyi István

Mielött azonban elmélyednénk abban, hogy mi is ez, nézzük meg azt, hogy miért jó, ha van egy új adattárolási technikánk, valamint a legfontosabbat, hogy hol tudjuk használni.

A virtuális adatbázis (VDB) kialakulása migrációs problémákhoz vezethető vissza. Migrálás során heterogén adatokkal találkozunk, ahol a beékező input adatokra azok forrása, és néhány jellemző tulajdonsága alapján alkalmanként más és más struktúrát feszítünk rá. Ráadásul minden egyes struktúra változtatásnak komoly programozási vonzatai vannak. Mi lenne azonban, ha a megfelelő migrációs eszköz értelmezni tudná az adatként tárolt struktúrát? Ha már itt tartunk, akkor a kivétel kezelést is levezérelhetné az eszköz, ún. szabályokon keresztül. Sőt, talán nem nagy elvárás, ha az ember ugyanitt megadhatja a mező-mező szintü hozzárendeléseket is. Ezekre az igényekre készült válaszként a VDB. VDB-t és az ahhoz kapcsolodó migrációs eszközt használva a szakember felhasználó határozhatja meg, hogy milyen esetekben mi történjen az adatokkal, azok hogy kerüljenek migrálásra, bármilyen programozói ismeret nélkül. Különösen a szabálykezelés nagyon fontos momentum ebben, azaz a “mi történik akkor, ha …” ezekre ugyanis legtöbbször a próbafutások alatt kapunk választ, amitől a programunk “if … then … else … if … then … else” -ek átláthatatlan halmazává válil. Egy kellemes felületen táblázatban meghatározni a döntési táblákat nem is igazi kihívás, mégis oly hasznos segítség az adatok feldolgozásában. És voilá, máris kész a migrációnk.

A VDB egy olyan adatbázis, amely más, RDBMS rendszerekre rátelepülve lehetővé teszi az adatok dinamikus kezelését. Az adatok leképezését a hálós és a táblázatos adatmodelek házasításával, egyetlen adattáblán keresztül végzi, egymás mellett tárolva az adatokat, és a definíciókat.

Milyen módszerrel tárolja az adatokat a VDB, ha csupán egyetlen táblát használ? Nos, nézzük az adatokat egy kicsit másképp:

Egyértelmű ugyan, hogy öt mezőm van, de miképp is néznek ki ezek a mezők?

Mi van akkor, ha meg akarom határozni, hogy valami kulcs-e, illetve honnan tudom ezt meg?

És hol állítom be azt, hogy milyen adatokat adhatok meg a tábladefiníciónal?

Mit jelentenek ezek a táblák? Fordítsuk meg a defiíciókat a megfelelő sorrendben, és nézzük őket egyben.

A VDB-ben négy adatszintet különböztetünk meg. Az alpha a legutóljára látható táblázat, a struktúra definíciója. Itt határozom meg, hogy az egy szerkezetű adatok milyen szerkezettel írhatóak le. Az adatdefiníciók között itt találhatóak egyedül fix értékek a VDB-n belül. Ez pedig az alpha struktúrája:

Mindhárom mező kötelező, valamint mindhárom mezőnek szerepelnie kell az alphában.

Ez, mondhatni, a minimális definíció.

Következik a béta szint, ahol SQL szinten meghatározom a tábla struktúráját.

Majd a gamma szint, maguk az adatok.

A negyedik szint, a delta, az adatokat logikailag fogja össze. Az SQL-lel összehasonlítva adatbázisoknak nevezném. Bár a VDB-ben ezen túl van még egy szint, hiszen egy VDB adatbázisban több delta szintü adatunk is lehet, valamint egy rendszerben több VDB adatbázist is kezelhetünk…

Mindezekhez még hozzátartozik, hogy a VDB rendszerekben semmilyen adatunk nem vész el, csupán átalakul. Bármikor előhivhatjuk a korábbi állapotokat, akár komplett adatstruktúra módosítása után is.

Néhány szóban a hátrányokról, bár erről leginkább hallgatni szoktak a fejlesztők . A hálós-relációs adatmodel sajnos nem teszi lehetővé, hogy csupán SQL szintű lekérdezésekkel kinyerhetőek legyenek az adatok. Interpreter egyenlőre csak JAVA és PL/1 alatt létezik, VDB-re épülő alkalmazás esetén a megszokott JDBC/SQL methodhivásoktól eltérő, csak a VDB-lekérdező methodusokat kell meghívni.

Az adattárolás logikája is eltér, megszokása időt vehet igénybe. Folyamatosan felmerülő kérdés, miért van erre szükség, amikor kis ráfordítással hasonlóan dinamikusan megoldható ez SQL környezetben is. Tekintsünk erre a kérdésre úgy, mint amikor az RDBMS adatbázisok elterjedésénél a hálós adatbázist használók kérdezték ugyanezt.

További információk: gefu gmbh