Mielött valami scifi novellára gondolnánk, pontosítsunk, mi is az a virtuális adatbázis? Amiről én most írni fogok, az a Peter Pressmar szabadalmaztatta “Heterogén adatstruktúrák virtuális adatbázisa“. Mindez jól hangzik, de nem jutottunk közelebb a megértéséhez.
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:
| Vezetéknév | Keresztnév | Születési idő | Születés helye | Nem |
|---|---|---|---|---|
| Büttner | Júlia | 1848.05.22 | Sajóvámos | Nő |
| Büttner | József | Férfi | ||
| Büttner | Karolina | 1846.12.09 | Sajóvámos | Nő |
| Büttner | Emil | 1831 | Férfi |
Egyértelmű ugyan, hogy öt mezőm van, de miképp is néznek ki ezek a mezők?
| Mezőnév | Típus | Hossz |
|---|---|---|
| Vezetéknév | C | 50 |
| Keresztnév | C | 50 |
| Születési idő | D | |
| Születés helye | C | 40 |
| Nem | C | 1 |
Mi van akkor, ha meg akarom határozni, hogy valami kulcs-e, illetve honnan tudom ezt meg?
| Mezőnév | Típus | Hossz | Kulcs |
|---|---|---|---|
| Vezetéknév | C | 50 | Y |
| Keresztnév | C | 50 | Y |
| Születési idő | D | N | |
| Születés helye | C | 40 | N |
| Nem | C | 1 | N |
És hol állítom be azt, hogy milyen adatokat adhatok meg a tábladefiníciónal?
| Mezőnév | Típus | Hossz |
|---|---|---|
| Mezőnév | C | 30 |
| Típus | C | 1 |
| Hossz | N | 2 |
| Kulcs | C | 1 |
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:
| Mezőnév | Típus | Hossz |
|---|
Mindhárom mező kötelező, valamint mindhárom mezőnek szerepelnie kell az alphában.
| Mezőnév | Típus | Hossz |
|---|---|---|
| Mezőnév | C | 30 |
| Típus | C | 1 |
| Hossz | N | 2 |
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.
| Mezőnév | Típus | Hossz |
|---|---|---|
| Vezetéknév | C | 50 |
| Keresztnév | C | 50 |
| Születési idő | D | |
| Születés helye | C | 40 |
| Nem | C | 1 |
Majd a gamma szint, maguk az adatok.
| Vezetéknév | Keresztnév | Születési idő | Születés helye | Nem |
|---|---|---|---|---|
| Büttner | Júlia | 1848.05.22 | Sajóvámos | Nő |
| Büttner | József | Férfi | ||
| Büttner | Karolina | 1846.12.09 | Sajóvámos | Nő |
| Büttner | Emil | 1831 | Férfi |
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