Önálló laboratórium beszámoló BME-TTT

1. A laboratóriumi munka környezetének ismertetése, a munka előzményei és kiindulási állapota

Bevezető/elméleti összefoglaló

 

A deduktív objektumorientált adatbázisok (továbbiakban DOOD-k), mint nevük is mutatja, (legalábbis az általuk biztosított lehetőségekben) hibrid rendszerek. Ilyeneket az élet bármely területén azért hozunk létre, mert maguk a problémák, amelyeket meg szeretnénk oldani velük, összetettek, egyszerre többféle (egyetlen szemléletmóddal nehezen áthidalható) követelményt támasztanak: inherensen heterogének. Másrészt általánosságban a hibrid technológiáktól azt várjuk, hogy az egyes összetevők pozitív tulajdonságait mind magukban hordozzák, ugyanakkor az esetleges hátrányokat kiküszöbölik. Természetesen —szélsőséges esetben— vágyainktól eltérően lehetséges, hogy csupán a negatívumokat egyesítjük, vagy —ami gyakoribb— az elért előnyök az elszenvedett veszteségeket nem kompenzálják kellőképp. Előfordulhat, hogy pusztán egyetlen jellemző változik nem megfelelően és ez az adott alkalmazás esetében nem tolerálható. Ezek miatt is fontos megtalálni mindazokat a területeket, amelyekben egy termék, jelen esetben egy DOOD, a már feltérképezett jellemzőivel sikeres lehet.

Mivel az objektumorientált szemléletmóddal ill. annak átültetésével az adatbázisok területére nyilván minden szakmabeli megismerkedett, azt el is sajátította, ezért itt ezzel nem kívánok foglalkozni. Annál is inkább, mert ez már általánosan elterjedt, továbbá például az [1.1]-ben említett könyv 25. fejezete is erről szól.

A következőkben röviden bevezetem az olvasót a kevésbé ismert, logikán alapuló adatbázisok elméletébe elsősorban [1.1]-re támaszkodva. Ugyanakkor néhány helyen idézek —ha nem is szó szerint— [1.2]-ből is. A továbbiakban feltételezem, hogy az olvasó az alapvető matematikai logikai fogalmakkal tisztában van. Ha nem így lenne, ajánlom figyelmébe akár [1.1]-t, amely első néhány pontjában a szükséges alapfogalmakat kellő részletességgel vezeti be.

A modellelméleti nézőpont, amely az adatbázisok hagyományos nézőpontja, (leegyszerűsítve) a következő:

- az egyes értékek, konstansok a valós világ egy-egy elemének felelnek meg,

- az (RDBMS-ekből átvett fogalmat használva: relációkban tárolt) n-esek és a megszorítások, amelyeknek nem szabad ellentmondaniuk, egy bizonyos logikai értelemben vett modellt alkotnak, az adatbázis (egyik) jelentését adják.

Az adatbázisok bizonyításelméleti nézőpontja szerint a jelentés az az elmélet, amely az axiómákból levezethető. (Ugyanis, mint az könnyen látható, minden explicit szereplő relációban levő n-es, ill. levezetett reláció, továbbá az adatok integritását jellemző összes megszorítás mind-mind egy általános klózforma speciális esetének tekinthetőek.) Az axiómákat

- a konkrét relációk,

- a teljességi axióma (nincs más n-es az adott relációban, csak a felsoroltak),

- az egyediségi axióma (minden konstans megkülönböztethető a többitől),

- a zártsági axióma (nincs más konstans, csak ami az adatbázis területén előfordul) és

- az =-hez fűződő axiómák

alkotják. Ha ezekhez még a megszorításokat is hozzávesszük (az egyéb következtetési szabályokon kívül), jutunk a deduktív adatbázishoz.

A bizonyításelmélet adatbázisbeli használatának vannak olyan előnyei, amelyekkel más rendszerek nem rendelkeznek, például:

- diszjunkciót,

- negációt tartalmazó és

- rekurzív lekérdezések

megvalósítása. (Bár e legutolsó problémát más rendszerekben is megoldották már. Pl. rekurzív operátorok RDBMS-ekben.) Ugyanakkor a logika nagy kifejezőereje miatt

- mind az adatok, megszorítások, a dedukciók, a lekérdezések ugyanabban a formában ábrázolhatóak,

- lekérdezés-optimalizálásra, integritás-betartatásra stb. éppúgy alkalmazható.

Ebből már látható, hogy lehetőség van a (logikai) programozási nyelv legmesszebbmenő integrálására az adatbázisba. (A hagyományos, jól ismert DBMS-ek külön nyelvet biztosítanak az adatok elérésére, és ettől eltérő nyelvet használunk más programozási feladataink megoldására.)

Az elmúlt évtizedekben folytak már törekvések DOOD-k megvalósítására, nem is eredménytelenül. Ezek négy fő csoportba sorolhatóak. Itt most nem részletezett okok és célok miatt (ezek egyébként részletesen megtalálhatóak [1.2]-ben) az ún. OO-Logic irányban szeretnénk előrelépni.

A már többször említett TDK dolgozat megoldotta az objektumorientált paradigma elemeinek deklaratív elemekké való (elvi) leképzését. Továbbá szükség van egy, a hatékonyság (részbeni) kézbentartására CLP (megszorításalapú logikai programozás) alapú nyelv létrehozására, amely a fentiek szerint az adatbázis "saját" nyelve lenne. Az adatbázisok elmélete szerint egy realizációban meg kell alkotni és fel kell használni:

- az adatdefiníciós ill. az adatlekérdező nyelveket (a hozzáférési felületet),

- adatbázis-menedzsert (a végrehajtó, központi részt).

 

A munka állapota, készültségi foka a félév elején

 

Társam (Kardkovács Zsolt Tivadar, lodoktor@inf.bme.hu) már az előző félév során szakirány laboratóriumában is ezzel a témával foglalkozott. Annak lezárásaként a párhuzamosan elkészített TDK dolgozatának ([1.2]) egy kivonatát adta be. A félév elején tehát gyakorlatilag csak ez az előzménynek tekinthető munka állt rendelkezésre, amelyet még sok szempontból kiegészíteni, módosítani, pontosítani kellett.

2. Az elvégzett munka és eredmények ismertetése

Az általam konkrétan elvégzett munka bemutatása

 

A félév elején, mivel én a deduktív adatbázisok területén addig nem rendelkeztem semmilyen ismerettel sem, először áttanulmányoztam néhány ezzel foglalkozó irodalmat. Tételesen ez [1.1] és [1.2] volt. Az utóbbi önmagában is egy összefoglalást nyújt a DOOD-k előéletéről, azonban nem foglalkozik önállóan a deduktív adatbázisok alapelveivel, jellemzőivel. Ezt a hiányt igyekezett pótolni az előbbi.

Továbbá társam a TDK dolgozatához begyűjtötte a tanszéken a korábbi félévek során a DOOD-k tanulmányozása eredményeképp keletkezett laboratóriumi beszámolókat is. Így rendelkezésemre bocsátotta az alábbi két dolgozatot is; ezeket szintén átnéztem:

- B. Tóth Attila: Modul laboratórium beszámoló, 1995-96. tanév 2. félév (Deduktív objektum-orientált adatbázisok elmélete; Megismerkedés a deduktív objektum-orientált adatbázisok elméletének alapjaival),

- Molnár Valéria: Modul laboratórium beszámoló, 1995-96. tanév (Deduktív objektumorientált adatbázis-kezelő rendszerek; ROCK&ROLL megismerése, használata).

A következő fázis során ki kellett választanunk azt az alkalmazási területet, amelyre (a következő félévekre átnyúlva) egy minta adatbázis-kezelőt valósítunk meg. Konzulenseinkkel folytatott többszörös konzultáció eredményeképp gondos mérlegessel egy sakkadatbázis mellett döntöttünk. Alternatívaként felmerült többek között egy városi úthálózat adatait tároló rendszer, menedzsmentet támogató termék, orvosi szakértői ill. valamiféle tőzsdei információs rendszer gondolata. A döntésben tükröződik azon törekvésünk, hogy egy olyan rendszert hozzunk létre, amely nem kifejezetten “iskolapélda-jellegű”, vélhetően magán viseli az efféle rendszerek minden jellemzőjét; ugyanakkor nagymennyiségű adat könnyen beszerezhető, ezek valósak, továbbá nem szükséges egy új szakmát, területet részleteiben is megismernünk. Habár ezekben az esetekben ugyanúgy, mint a valós életben az informatika egy vagy több szakmával kerül kapcsolatba; de így legalább jobban koncentrálhatunk fő feladatunkra, az adatbázis létrehozására.

Meghatároztuk azt is, milyen fejlesztői környezetet fogunk használni. Voksunkat az Intel x86 alapú Linux operációs rendszer mellett tettük le. Programozási nyelveink pedig a GNU C/C++ implementációja ill. a SICStus Prolog. Az utóbbiból a félév elején még a 3.6-os változat állt rendelkezésünkre ([1.3]), de a lejjebb részletezett problémák miatt áttértünk 3.7.1-re ([1.4]). Ez a változat már tartalmaz olyan hatékony elemeket, amelyeket érdemes lehet beépíteni készülő rendszerünkbe; nevezetesen: file-ban (és nem memóriában) elhelyezkedő kifejezések (External Database) és Prologbeli objektumok (Prolog Objects) használata. Nyilvánvaló, hogy egy (önálló) adatbázis megvalósítása esetén a legalsó fizikai réteget is realizálni kell, azonban ha ezt minden részletre kiterjedően szeretnénk elvégezni (ahogy az egy kereskedelmi termék esetében szükséges), jelentős időnk menne el vele. Ezért az attribútumok tárolását (várhatóan) Oracle RDBMS-re bízzuk. Hallgatólagosan elfogadtuk azt is, hogy programjainkat a lehetőségeknek megfelelően minél hordozhatóbban írjuk meg, ezzel elősegítve a későbbi esetleges többplatformossá tételt.

Az előkészítő jellegű feladatok után nekiláttunk a munka érdemi részének. Társammal az elkészítendő rendszer főbb komponenseit azonosítottuk, a kezdeti fázis teendőit felosztottuk egymás között [2.1]. Ennek során szükséges volt néhány, [1.2]-ben már lefektetett elv megváltoztatására. Ezek mind megtalálhatóak ebben a beszámolóban ill. a csatlakozó dokumentációkban.

Mivel a fejlesztést az alapoktól kezdtük, szükség volt néhány (minden komponens számára) közös probléma megoldására. Ezek közé tartozik egy objektumorientált C++›Prolog ill. Prolog›C++ interfész kifejlesztése. Ennek első változatát készítettem el. Várható, hogy ez még funkcionálisan bővülni fog, hiszen (kitűzésünknek megfelelően) minden tekintetben inkrementális fejlesztést végzünk. Sajnos problémáink már itt jelentkeztek. A nálam otthon Intel x86-on futó Windows NT és Microsoft Visual C++ 97 alatt elkészített, letesztelt modul bent Linux alatt nem működött. Az ok felderítése, miszerint a SICStus 3.6 régebben készült és így nem működik a C könyvtári függvények 6-os változatával, jelentős időnket és energiánkat emésztette fel. Ekkor kértük dr. Szeredi Pétert, a Számítástudományi és Információelméleti Tanszék tanárát valamint az IQSoft Rt. munkatársát, hogy biztosítsa számunkra a Prolog egy újabb (3.7.1-es) változatát.

Kálváriánk azonban így sem ért véget. Ezzel már működtek a C-s, valamint az egyszerűbb C++-os tesztprogramjaink, de az interfész, amely jelentős mértékben épül a C++ kivételkezelésének lehetőségére, továbbra sem. A problémát sikerült lokalizálni (a throw utasítás tehető felelőssé: ha nem használjuk, minden rendben), de megoldani továbbra sem. Később, látva, hogy ezzel nem tudunk egyedül megbirkózni, kértem mind Szeredi urat, mind két C++–Prolog illesztésben járatos doktoranduszt, hogy segítsenek ennek elhárításában. A jelenlegi állapot ezzel kapcsolatban ez. Ugyanakkor a megoldás kutatása során sikerült további inkonzisztenciákat, működésképtelenségeket felfedeznem és azonosítanom mind a SICStus Prologban, mind a Windows NT–SICStus Prolog–Visual C++ együttműködésével kapcsolatban. Ezeket itt nem részletezem, mert feladatunk szempontjából (jelenleg) nem lényegesek ill. a hibák elkerülhetőek, de részleteiben megtalálhatóak —akárcsak a fenti throw-probléma— [2.4]-ben.

A fentebb leírt nehézségek felvetik azt a kérést, nem lenne-e érdemesebb egy másik (esetleg ingyenes) Prolog implementáció használata. A következő félév során lehetséges, hogy erre a kérdésre érdemben visszatérünk.

Első körben egy örökléseket sem, csak attribútumokat tartalmazó osztály bevitelét tűztük ki célul. Ehhez kapcsolódóan az adatdefiníciós nyelv (DDL) megalkotását [2.5] valamint első szintű (DBMS előtti) feldolgozását [2.5] végeztem én.

A beviendő séma feldolgozása, akárcsak egy tetszőleges szöveg értelmezése esetén, alapvetően két fázisra bontható: szintaktikai és szemantikai lépések. Ez gyakorlatilag azt jelenti, hogy a bemenetet kétszer értelmezzük, hatékonyabb lenne ezeket egyben megoldani, de ez kellően átláthatatlan programkódot eredményezne és ellentmondana a funkcionális minimalitás elvének is: már akkor a “tartalommal” foglalkoznánk, amikor még a “külső” helyességéről meg sem győződtünk.

A szintaktikai elemzés magját célszerűnek látszott a Prolog beépített beolvasó eljárásával (read_term/3) megoldanom, hiszen a séma elemei deklaratív módon kerülnek megadásra (pl. relációk, függvények). Ehhez szükség volt egy olyan Prolog folyam (stream) C(++) megvalósítására [2.6], amely lehetővé teszi, hogy a megmaradt (még nem értelmezett) részeket visszakapjuk. A Prolog képes arra, hogy (folyamként megnyitott) fájlból olvasson, ekkor a fájlpozíció megadná ezt, de a sémának nyilvánvalóan kell tartalmaznia részeket, amelyek a különböző deklarációkat választják el egymástól. Ezek nemdeterminisztikus (visszalépésen alapuló) elemzése fájlból közvetlenül nem lehetséges. Ugyanakkor megoldott karakterek listájából, ebből szintén tud a Prolog olvasni, de a fennmaradó részeket nem tudjuk kinyerni. Azonban lehetőség van arra, hogy Prologban új folyamtípust valósítsunk meg (jelen esetben karakterlistából készítek folyamot), ez képessé tehető a le nem elemzett rész visszaadására.

Amikor megfogalmaztam a szemantikai feldolgozás feladatait, azt a társammal közösen elfogadott vezérelvet tartottam szem előtt, hogy minél kevesebb feladatot rójunk e tekintetben a DBMS-re. Elképzelhető lenne, hogy a pusztán leelemzett kifejezéseket továbbítunk feléje. Ez több szempontból sem lenne előnyös a későbbiekben vélhetően kialakítandó kliens–szerver architektúra esetén:

- az esetleges hibaüzeneteket vissza kéne juttatni a kliens oldalra,

- a szerver más feladatokkal is el lehet foglalva, hiszen egyszerre több klienst is kiszolgálhat, felesleges lenne ezzel is terhelni.

Az ellenőrzendő követelményeket az egyes objektumosztály-tulajdonságokhoz kapcsolódóan az 1. táblázat tartalmazza.

1. táblázat

A sémafordító jelenlegi készültségi állapotában az (1), (2), (3), (8) feladatokat oldja meg.

(4) elkészítéséhez már megtettem az előkészületeket, megvalósítottam C++-ban Floyd algoritmusát [1.7] egy irányított gráf minden csomópontpárja közötti legrövidebb út felkutatására [2.6]. Az újrafelhasználhatóság minél szélesebb körű biztosítása érdekében ez sablon (template) formában készült el. A mátrixok kezelését egy az Internetről beszerzett szintén generikus osztály adja [1.8][2.6]. Sajnos szerzői nem minden helyen használtak konstans paraméterátadásokat és tagmezőket, ahol lehetséges lett volna. Ennek köszönhetően ezekkel a felhasználó programrészekben szintén óvatosan kell bánni. (Ez annyit tesz, hogy a const kulcsszó használata meglehetősen körülményes.) Ezáltal fordítási időben jelentős hibák maradhatnak észrevétlenül, nehezebbé téve a futásidejű hibakeresést. Valószínűsíthető, hogy a közeljövőben a mátrixosztály jelzett hiányosságát meg fogom szüntetni.

A szerzőket dicséri azonban, hogy kihasználták a Standard C++ könyvtár [1.5] lehetőségeit (pl. a kivételek területén). A jelenlegi C++ fordítók mindegyike biztosítja többé-kevésbé ezt a könyvtárat. A C++-beli szoftverfejlesztés tendenciája ennek minél szélesebb körű használata. A félév elején e rendszert csak hallomásból ismertem, de úgy gondoltam érdemes lenne megismerkedni vele, annál is inkább, mivel egy Standard mintakönyvtár (STL) is a részét képzi. Ebben általános, bővíthető adatstruktúrák (pl. fák, listák), algoritmusok (pl. egy adattároló minden elemére alkalmazás, keresések) találhatóak. Mivel a Visual C++ súgórendszere az STL elemeit inkább csak referenciajelleggel ismerteti, nekem pedig az alapkoncepció is ismeretlen volt, az Interneten kerestem ezzel kapcsolatos irodalmat. A legjobbnak a Silicon Graphics által készített leírást [1.6] találtam, így azt tanulmányoztam, az STL használatát, ahhoz illeszkedő osztályok fejlesztését abból sajátítottam el. Az általam készített Prolog-C++ interfész is megfelel ennek. (Pl. tartalmaz olyan osztályt, amely memóriamenedzsmentet végez (allocator) [2.3].)

Meg kell említenem azonban, hogy a Standard C++ könyvtár támogatásban, sajnálatos módon, jelentős eltérések vannak az egyes fordítók között. Kevés olyan van, amely mindenben megfelel a szabványban lefektetett igényeknek. Mindez jól tükröződik például az SGI STL implementációjának [1.6] stl_config.h fájlában.

Az 1. táblázatban (5)-tel jelölt feladat is gyakorlatilag megoldott, hiszen ugyanaz, mint (3), csak máshonnan kell venni az ellenőrizendő adatot. (6) pedig felhasználhatja a már említett Floyd-algoritmus által visszaadott útinformációt. (7) és (10) feltételez egy hatékony tárolási formát, amely az attribútumokat, relációkat és függvényeket tartalmazza. De első körben (a kitűzött részfeladatnak megfelelően) ezekkel nem foglalkozunk. (9)-hez pedig szükség volna annak ismeretére, a DBMS egyáltalán milyen alaptípusokat támogat, ill. milyen megszorításokra van szüksége egy-egy típus kezeléséhez. Ezt azonban még nem rögzítettük.

A DOOD (jelenleg még egyetlen) felhasználó felőli oldalának, a sémafordítónak elkészült részeit (a fentebb részletezett problémák miatt kizárólag) Windows NT alatt leteszteltem. A "teljes" rendszerbe illesztés a [2.1]-ben specifikált módon és protokollal lehetséges, a további munkát (az osztály bejegyzését) a DBMS végzi el. A tényleges összekapcsolásra azonban még nem került sor a fellépett (és előbbiekben vázolt) hordozhatósági probléma miatt; annak megoldása a későbbi fejlesztésekhez elengedhetetlen, így arra koncentráltunk.

A következő félévek során szeretnénk munkánkat, egy DOOD megvalósítását, amelynek alapjait, mint az a beszámolóból eddig kiderült, már lefektettük, önállólabor-feladatként ill. diplomatervként folytatni.

Összefoglalás

 

- Áttanulmányoztam [1.1]-t megértve a deduktív adatbázisok lényegét;

- Magamévá tettem az [1.2]-ben leírt (és továbbra is fenntartott) célokat, elveket, módszereket, technológiákat;

- Az [1.2]-ben említett néhány rendszer közelebbi megismeréséhez elolvastam azokat az anyagokat, amelyeket (társam rendelkezésre bocsátott és) az előző félévek során hasonló feladattal foglalkozó elődeink laboratóriumi munkájuk során elkészítettek;

- Megállapodtunk az alkalmazási területben, amelyre egy minta adatbázis-kezelőt valósítunk meg, továbbá a fejlesztői környezetet is meghatároztuk;

- Társammal együtt az elkészítendő rendszer főbb komponenseit azonosítottuk, a kezdeti fázis teendőit felosztottuk egymás között [2.1];

- Leraktam egy objektumorientált C++›Prolog ill. Prolog›C++ interfész alapjait, amelyet én eddig is használtam és a későbbiek során használni fogunk [2.3];

- Felfedeztem néhány, SICStus Prologhoz kapcsolódó, hibás ill. nem dokumentált működést [2.4];

- Elkészítettem egy olyan C++ nyelvű kiegészítést a Prologhoz (streamet), amely segítségével karakterlistából lehet magasszintű olvasást végrehajtani és a fennmaradó (el nem olvasott) darabot visszakaphatjuk [2.6];

- Erre épülve a séma szintaxisának definiálása után, megvalósítottam annak elemzőjét Prologban [2.5];

- Hozzáláttam a (Prolog nyelvű) szemantikus ellenőrzéshez is [2.5];

- Ehhez azonban szükség volt egy legrövidebbút-kereső algoritmus (C++) programozására [1.7][2.6];

- A legfejlettebb technológiák alkalmazásának érdekében megismertem a Standard C++ könyvtár részét alkotó Standard Mintakönyvtár (STL) elvét, felépítését, elsajátítottam alkalmazásának [2.3] módját: Interneten fellelhető irodalmat kerestem, és ezek közül a legjobbnak tűnőt tanulmányoztam ([1.5], [1.6]).

 

3. Irodalom, és csatlakozó dokumentumok jegyzéke

A tanulmányozott irodalom jegyzéke:

[1.1] C. J. Date, Part VI. Chapter 24: Logic-Based Systems, An Introduction to Database Systems, Volume I., Fifth Edition, Addison-Wesley Publishing Company, 1990, pp. 641-682

[1.2] Kardkovács Zsolt Tivadar, Deduktív objektumorientált adatbázisok, Budapesti Műszaki Egyetem Villamosmérnöki és Informatikai Kar Tudományos Diákköri Konferencia és Országos Tudományos Diákköri Konferencia Informatika Szekció dolgozat, 1998.

[1.3] SICStus Prolog 3#6 User's Manual, Swedish Institute of Computer Science, November 1997 (a termék Windowsos súgófájla)

[1.4] SICStus Prolog 3.7.1 User's Manual, Intelligent Systems Laboratory, Swedish Institute of Computer Science, October 1998 (a termék leírása PS ill. PDF formátumban)

[1.5] Standard C++ Library Reference, Microsoft Visual Studio 97 Service Pack 3 documentation (a termék on-line súgórendszeréből)

[1.6] Standard Template Library Programmer's Guide, Silicon Graphics Computer Systems, Inc., 1999 (aktuális: http://www.sgi.com/Technology/STL ill. egy lementett változat: http://kay.ttt.bme.hu/~surprof/STL)

[1.7] Ivanyos Gábor, Rónyai Lajos, Szabó Réka, Algoritmusok, 1996. szeptember (jegyzet a BME-VIK műszaki informatika szak Algoritmusok elmélete c. tárgyához)

[1.8] C++ Matrix Template Library, Techsoft Pvt. Ltd., 1999 (http://www.techsoftpl.com/matrix.htm)

 

Csatlakozó egyéb elkészült dokumentációk, fájlok stb. jegyzéke:

 

Az alábbiakban hivatkozott fájlok (társam beszámolóját kivéve) az ARTHUR.TTT.BME.HU szerveren levő sajátkönyvtáram alatti DOOD\8 mappában lelhetőek fel.

[2.1] Kardkovács Zsolt Tivadar, Surányi Gábor Mihály, Deduktív objektumorientált adatbázisok, 1999. március 23. (DOC\class.ps)

[2.2] Kardkovács Zsolt Tivadar, Önálló laboratórium beszámoló, 1998-99. tanév 2. szemeszter

[2.3] Surányi Gábor Mihály, Általános célú, objektumorientált, nyelvi implementációktól független Prolog–C++ interfész, 1999. (DOC\C_Prolog.txt, Excepton.h, Platform.h, Platform.cpp, Prolog.h, Prolog.cpp)

[2.4] Surányi Gábor Mihály, Hibajelentés a SICStus Prolog 3.6-hoz ill. 3.7.1-hez, 1999. (BugRep_1\BugRep.txt, BugRep_1\er.pl, BugRep_1\er1.c, BugRep_1\er2.cpp, BugRep_1\er3.cpp, BugRep_1\er4.cpp)

[2.5] Surányi Gábor Mihály, A deduktív objektumorientált adatbázis sémafordítója, 1999. (DOC\DDL.txt, DDL.pl)

[2.6] Surányi Gábor Mihály, Gráfalgoritmusok és más kiegészítések a Prolog nyelvhez, 1999. (DOC\HelpAlgo.txt, graphext.pl, graph.hpp, matrix.h, CHARSTRM.cpp, charstrm.pl, helper.pl)