GIS adatmodellek II

Ebben a részben először megismerkedünk a leíró és geometriai adatok összekapcsolásának

általános problematikájával, majd megismerkedünk néhány tipikus megoldással, éspedig

a georelációs modellel ,
az egységes megoldással ,
a projektorientált rendszerekkel ,
az objektumorientált és georelációs vegyes architektúrával és végül röviden felvázoljuk
az objektum orientált megközelítést.

A helyzeti és leíró adatok tárolásának-kezelésének néhány implementációs variánsa

Az implementációs adatmodellt több logikai szinten realizálják. A legalacsonyabb logikai színt azt határozza meg, hogy a grafikus és numerikus adatok tárolása milyen formában történik, s hogy ezeket az adatelemeket hogyan és milyen szintig integrálják a GIS függvények számára. A történelmi fejlődést követve négy variánst fogunk röviden megismerni.

A georelációs modell (az ARC/INFO példája)

A legrégibb és legelterjedtebb GIS szoftver az ARC/INFO a hetvenes évek végétől vált kereskedelmi termékké, számtalan rendszere működik világszerte. Architektúrája azon az alapelven nyugszik, hogy külön-külön adatbázisban tárolja a helyzeti és leíró adatokat. Az azóta eltelt hosszú idő tapasztalatait az ESRI (az ARC/INFO-t kifejlesztő szoftverház) úgy értékeli, hogy az általuk georelációsnak nevezett modell igen sikeres volt és további fejlesztéseiket is erre az architektúrára alapozva végzik.

4.4 ábra - a georelációs GIS vázlata

Amint azt a 4.4 ábrán szemléltetjük a helyzeti adatok réteg szerkezetben, topológiai struktúrában, hierarchikus módszerrel kerülnek tárolásra, míg a leíró adatok relációs adatbázisba vannak szervezve. A két adatbázis között keresztreferencia biztosítja a kapcsolatot.
A felhasználói program tematikus megkereséseit a relációs adatbázis-kezelő dolgozza fel majd a keresztreferencia révén aktivizálja az érdekelt grafikus állományt. Helyzeti lekérdezés esetén fordítva készül a válasz: először a grafikus adatbázisból kiválasztódnak a kérdéses objektumok, melyek a keresztreferencia révén felveszik a relációs adatbázisból a hozzájuk rendelt attribútumokat.
Két dologról érdemes még szólni az ARC/INFO fejlesztési tapasztalataira támaszkodva. Az első azt a kritikai megjegyzést érinti [3] miszerint ez az architektúra nem alkalmas kataszteri feladatokra, mivel hiányzik a konzisztencia vizsgálat lehetősége a nem relációs adatbázisban tárolt elemekre. A gyakorlat azonban azt mutatja, hogy a rendszer biztosítja a referenciális integritást a két adatbázis között. A másik érdekesség, hogy azok az új verziók, melyek mind raszteres mind vektoros adatok kezelésére alkalmasak továbbra is a georelációs architektúra alapján állnak.

Az egységes megoldás

Kézenfekvőnek tűnhet az a megoldás, hogy minden adatot egy relációs adatbázisban helyezzünk el. Ebben az esetben olyan előnyökkel számolhatnánk mint a konzisztencia kontroll, a redundancia mentesség, az adatmodell rugalmassága és nem utolsó sorban a lekérdezőnyelv lehetőségeinek közvetlen kihasználása. Ez az architektúra többek közt lehetővé teszi, hogy egyszerű eszközökkel olyan adatmodellt hozzunk létre, mely tartalmazza az objektum orientáltság bizonyos jellemvonásait például a rétegmentességet, folyamatos adatstruktúrát, összetett objektumokat stb.
Ahhoz azonban, hogy a relációs adatbázis alkalmazható legyen az egységes helyzeti-leíró adatbázis céljaira, eredeti jellemzőit módosítani kell, azaz nem használható közönséges kereskedelmi relációs adatbázis-kezelő szoftver, hanem csak olyan, mely rendelkezik a kívánt bővítésekkel.
Amint azt az első fejezetben már láttuk, a relációs adatbázisok olyan táblázatokból állnak, melyek valamennyi sora azonos számú mezőből ál. Ehhez még hozzátehetjük, hogy egy oszlopon belül minden mező azonos típusú és maximált méretű értéket tartalmaz. Ha azonban a topológiai modellt akarjuk táblázatokba foglalni hasonlóan ahhoz amint ezt a topológiai szervezés példája kapcsán tettük, úgy olyan formán célszerű bővíteni az adatbázis lehetőségeit, hogy alkalmas legyen az úgy nevezett 'bulk'-ok (rakások) tárolására is.
A bulkok nem mások mint azok a változó hosszúságú adatmondatok, melyek tartalmazzák a csomópont kéttősök között elhelyezkedő íveket alkotó pontok koordinátáit. Bár az adatbázis-kezelő a bulkot csak egészében kezeli (a töréspont koordinátákat csak a feldolgozó program értelmezi) a probléma az hogy a bulkok különböző hosszúak ezért a kiterjesztett rendszernek kezelnie kell tudni a különböző mezőhosszúságokat.
Kívánatos lehet e mellett az is, hogy a strukturált adatokat tartalmazó mezők is lehessenek változó hosszúságúak azaz hogy olyan hierarchiák is felírhatók legyenek, melyeket a relációs adatbázis kezelők éppen az első normál formával küszöbölnek ki. Még további kívánalmakat is említhetnénk, de már az eddig felsoroltak is igazolják, hogy a GIS adatok egységes tárolására szolgáló adatbázis nem tekinthető szabványos relációs adatbázisnak.
Bár a módosított (kiterjesztett) relációs adatbázis-kezelő már alkalmas a GIS adatok tárolására további probléma, hogy a grafikus adatok jelenléte nagymértékben lassítja a relációs adatbázis-kezelő működését. Ha tehát azt akarjuk, hogy a GIS műveletek elfogadható idő alatt kerüljenek végrehajtásra, úgy célszerű a munkába vett egymás melletti grafikus elemeket laponként egy külön pufferben tárolni. A puffer relatíve gyors feltöltésére a vektoros adatmodell tárolását tárgyaló részben ismertetett valamely térbeli keresési eljárás (fa-struktúra, címjegyzék orientált módszerek, többdimenziós hashing, stb.) szolgál. Az egységes architektúra vázlatát a 4.5 ábrán mutatjuk be.

Az egységes architektúrára példaként a kanadai Unisys cég SYSTEM 9 nevű GIS szoftverjét említjük. Ebben a rendszerben lehetőségünk van rugalmas adatmodell kialakítására s ezzel a réteg szemlélet meghaladására. Érdemes megjegyezni, hogy az összetett objektumok létrehozása szempontjából a lényeges különbség az objektum orientált jeleket hordozó rugalmas adatmodellek és a rétegszemléletű adatmodellek között abban van, hogy míg az utóbbiak csak poligon fedvényezési műveletek (overlay operation) eredményeképpen képesek az összetett objektumok bizonyos fajtáit létrehozni, addig a rugalmas adatmodellel dolgozó rendszerekben az összetett objektumokat az adatbázis létrehozási stádiumában kell definiálni.

4.5 ábra - egységes architektúrájú GIS vázlata

Projektorientált rendszerek

Ez az architektúra igyekszik egybeolvasztani a georelációs modell és az egységes megoldás előnyeit. Valamennyi adat tartós tárolására relációs adatbázisban kerül sor. Megjegyezzük, hogy ebben az esetben alkalmazható szabványos relációs adatbázis-kezelő rendszer is, de gyakorlati okokból (a tranzakciók meggyorsítása, kevesebb redundáns adat tárolása, rugalmas adatmodell létrehozásának megkönnyítése, stb.), gyakran alkalmazzák a változó mezőhosszúságot kezelni tudó bővítéseket is.

4.6 ábra - projektorientált GIS vázlata

A relációs adatbázisból minden munka megkezdése előtt kiválasztják azokat az adatbázis részeket, melyekre az adott projektben szükség lesz. A kiválasztott állományok grafikus részéből a rendszer kialakítja az ARC/INFO-hoz hasonló ideiglenes grafikus adatbázist, míg a figyelembe vett attributív adatokból egy ideiglenes relációs adatbázist. A műveletek ezután úgy folynak a munkanap befejezéséig mintha georelációs adatmodellben dolgoznánk. A munkanap végén kerül sor a relációs adatbázis módosítására a munka közben keletkezett eredményekkel. A felújítás során az adatbázis kezelő elvégzi a konzisztencia vizsgálatot és hiba esetén lehetőséget ad a hibás elemek javítására. A 4.6 ábrán felvázoltuk a projektorientált architektúra főbb csomópontjait.
Példaként a fenti architektúrára két svájci szoftvert említhetünk a Kern cég INFOCAM nevű rendszerét, illetve a Strässle cég által forgalmazott GRADIS GIS-t.

Objektumorientált és georelációs vegyes architektúra

Azok a jelentős előnyök, melyeket az objektum orientált környezet többek közt az összetett objektumok bevezetésével valamint a gyors prototípus képzéssel nyújt arra késztették az ESRI-t hogy kutatásaiban vizsgálja meg objektum orientált GIS szoftver létrehozásának lehetőségét. A vizsgálatok eredményeit egybevetve a piaci feltételekkel végül is úgy döntöttek, hogy a meglévő georelációs modellt látják el egy olyan burokkal, mely értelmezi a rétegek egyesítéséből adódó régiókat, az összetett objektumokat, a prototípusokat, stb. Mivel a fejlesztési stratégiának döntő eleme a hibrid adatmodell (vektor és raszter adatok együttes kezelése) által nyújtott lehetőségek maximális kihasználása, az objektum orientált burkon keresztül erősíthető az automatizált, szkenneléses adatnyerési forrás, mely feltétlenül szükséges a raszteres adatbázis feltöltéséhez és felújításához. Hasonlóképpen támogatja az architektúra a másik fejlesztési célkitűzést: a kliens - szerver környezetben való működést.
A fenti célok megvalósítását szolgálja két új ESRI szoftver: az ArcStorm (Arc Storage Management System) nevű objektum orientált felszíni adatbázis-kezelő és az Avenue nevű objektum orientált programozási nyelv, mely utóbbi támogatja az objektum orientált alkalmazói fejlesztéseket.

4.7 ábra - objektumorientált burok az Arc/Info-n

Az ESRI elképzelései szerint az új architektúra egyrészt lehetővé teszi, hogy a felhasználók a megszokott és kipróbált georelációs adatmodell környezetben dolgozzanak, másrészt megteremti annak a lehetőségét is, hogy kipróbálják és lassan megszokják az objektum orientált környezetet, mely fejlődés egy idő után időszérűsítheti a valóban hatékony, teljesen objektum orientált, tehát objektum orientált adatbázisra támaszkodó szoftver kibocsátását.

Az objektumorientált megközelítés

Az objektum orientált megközelítésben mind az adatok mind a műveleti szoftver modulok, melyek rendelkeznek több kevesebb objektumokra jellemző tulajdonsággal - objektumok. Tárolásuk és kezelésük optimális körülmények között objektum orientált adatbázisban történhet. Az adatbázis lehet úgy nevezett objektum-relációs is, ami nem más mint a relációs adatbázis kiegészítése olyan elemekkel, melyek lehetővé teszik az objektumok tárolását relációs adatbázisban.
A fokozott igényt az objektum orientált GIS létrehozására a hálózatok rohamos terjedése és a hálózati adat szabványok megjelenése váltotta ki. A CORBA, JAVA, ODBC és OLE/COM szabványok ugyanis mind program vagy adat objektumok becsomagolási feltételeit határozzák meg. Azaz amit becsomagolnak objektumok, tehát ebben az osztott hálózati környezetben a térbeli objektumok is objektum formában kell hogy jelentkezzenek.
Ezt a helyzetet, illetve a töménytelen térbeli adatformátum okozta nehézségeket látva létrejött az OPEN GIS konzorcium számtalan szoftver és hardver cég támogatásával, mely célul tűzte ki olyan objektum orientált térbeli adatmodell létrehozását, mely megfelel a korszerű hálózati követelményeknek és lehetővé teszi a különböző térbeli adatok és szoftver modulok együttes hálózati munkáját.
Az OPEN GIS koncepció egészére és különösen a részletes adatmodellre a szoftverekről szóló fejezetben még visszatérünk. Egyelőre csak annyit kívánunk megjegyezni, hogy a koncepcióhoz legközelebb a Laser Scan cég áll, mely Gothic nevű objektum orientált GIS fejlesztő környezete könnyen alkalmassá tehető a specifikáció teljesítéséhez, csak az objektum kezelőjéhez kapcsolódó DLL interfésze használatát kell kibővíteni a hálózati specifikációknak (CORBA, JAVA, ODBC és OLE/COM) megfelelő konverterek hozzáadásával.
Az előző bekezdés egyben arra is céloz, hogy egyelőre nem sok valódi Objektum Orientált GIS található a piacon.