Térinformatikai adatok verziókezelése

Version control of spatial data

KOLESÁR András

Lechner Tudásközpont
1149 Budapest Bosnyák tér 5.
andras.kolesar@lechnerkozpont.hu
+3614604166

Abstract

Spatial databases should track every change. This allows us to view database at any moment in the past. What can guarantee immutability for every version?


Tartalom

Alapvető követelmény a változtatások nyilvántartása térinformatikai adatbázisokban. Ezzel tudjuk biztosítani, hogy visszatekinthessünk bármilyen időpontra. Mi biztosíthatja, hogy minden változat megmaradjon abban az állapotában, ahogy annak idején letároltuk?


Keywords

spatial data, versioning, time machine


Kulcsszavak

térinformatikai adat, verziókezelés, időgép

1. Miért fontosak a verziók?

Nem csak azt szeretnénk tudni, hogy mi van most.

1.1. Előzmények

Nem csak azt szeretnénk tudni, hogy mi van most. Szeretnénk látni az előzményeket is, bármely időpontban.

Verziókezelés hiányában mentésekből szoktak visszatekinteni korábbi állapotokra. Ha minden éjjel készítenek is másolatot az adatbázisról, akkor sem szerepel egyikben sem az az állapot, amelyet készítése után még ugyanazon napon módosítottak vagy töröltek. Távolabbi múltból tárhely-korlátok miatt csak ritkább mintavételezésű (heti, havi, éves) mentések szoktak rendelkezésre állni, amelyek még kevésbé alkalmasak a célra.

1.2. Visszavonás

Szeretnénk visszavonni bármelyik módosítást. Ehhez tudnunk kell, hogy milyen módosítások történtek. Az előzmények láncolatának utolsó tagja gond nélkül visszavonható. Ugyanígy bármennyi lépés visszavonható a lánc végéről ütközés nélkül, mivel még nem érkezett rájuk épülő további módosítás.

Visszavonás a korábbi változatokat nem törölheti, hanem új változatként állítja vissza a korábbi állapotot. Ez azért fontos, mert csak így lehet hitelesen bemutatni bármely időpont aktuális állapotát. A művelet nyom nélküli törlésével erre nem lehetnénk képesek.

Szükség lehet olyan műveletre is, amely régebbi módosítás hatását szünteti meg. Ez esetben megvizsgálandó, hogy a módosítást követő műveletek érintik-e a visszaállításban szereplő objektumokat, az esetleges ütközések feloldandók.

1.3. Jóváhagyás

Szeretnénk kezelni jóváhagyásra váró változtatásokat. Ezeket tárolnunk kell az adatbázisban, mivel nem csak a készítőjét, hanem másokat is érintenek.

Fontos ezeket megkülönböztetnünk az éles változattól, amelyben ezek a változtatások nem jelenhetnek meg.

Ha a jóváhagyandó változtatásokat ütközések feloldása nélkül, vagyis módosítás nélkül kell tudnunk bármikor élesíteni, akkor újabb változtatások tárolásakor a rendszernek ellenőriznie kell, hogy nem érint-e olyan objektumot, amelynek már van jóváhagyásra váró változata. Ez esetben ugyanis a változtatás nem kerülhet élesbe, majd csak akkor, ha az alapját képező módosítás is éles lesz. Így jóváhagyandó változtatások egymásra épülő sorát is tudnunk kell kezelni.

1.4. Egyidejű szerkesztések

Több felhasználó által egyszerre végzett szerkesztéseknél előfordul, hogy ugyanazt az objektumot többen is szeretnék módosítani egyidejűleg. Ez nem jelenti azt, hogy a módosítási igények azonos időpontban érkeznének be. A probléma ott jelentkezik, hogy a később beérkező módosítás készítője nem látta (idő hiányában nem láthatta) az őt megelőző módosítást. A később érkező módosítás csak akkor fogadható be, ha az érintett objektumok aktuális változataira épül, nem korábbiakra.

2. Hogyan valósítható meg?

2.1. Elődeink megoldásai

Tekintsünk vissza a változások követésének fejlődésére.

2.1.1. Létrehozás és utolsó módosítás időpontja

Régebbi rendszerekben csak dátum (év, hó, nap) időpont nélkül. Jó esetben felhasználói azonosító is kapcsolódik hozzájuk.

Kitöltése lehet kézi vagy automatikus. Ha az adatbázis elfogadja a felhasználótól érkező adatot, akkor tartalma akár hamis is lehet. Visszatérő motívum, hogy a a pontos idő meghatározására a felhasználó gépének óráját használják, amely hajlamos elcsúszni vagy visszaállni évekkel korábbra.

2.1.2. Megszűnés időpontja

Adatbázisokban hamar felmerült az igény korábbi állapotok megőrzésére. Módosításkor nem helyben írják felül a régi értéket, törléskor pedig nem törlik a sort az adatbázisból, hanem letárolják az aktuális időt a megszűnés időpontja oszlopban, ezzel érvénytelenítve a korábbi sort.

Ha a felhasználóra bízzák az előző állapot érvénytelenítését, akkor szabadon módosíthatja az előzményeket. Módosíthat időpontokat, feléleszthet törölt sort, vagy akár az adatokat is átírhatja.

2.1.3. Létrehozás és megszűnés részletes adatai kapcsolódó táblában

Korábbi megoldásokban csak időpont és felhasználói azonosító jellemezte a változtatást. Kiderült tehát hogy mikor és ki, de az nem, hogy miért. Fontos lehet például a módosításhoz kapcsolódó ügy azonosítója, amelyet gazdaságtalan lenne letárolni minden érintett sorban. Különösen érvényes ez relációs adatbázisokban, ahol egyszerre sok táblában történik módosítás.

Külön táblát hoztak létre a változások adatainak tárolására, majd ezen tábla egyedi azonosítóját tárolták csak le az érintett sorokban. Ezzel még két legyet is ütöttek egy csapással: a változás azonosítója összekapcsolja a változott objektumokat, így nem csak az időpontok azonossága vagy közelsége alapján lehet csoportosítani azokat.

Fontos, hogy a felhasználónak csak bővíteni legyen joga a változások tábláját, mert ha módosítást is tehet, akkor át tudja írni az előzményeket. Ha a kapcsolódó táblákban módosítani tudja az előző sorok változás-azonosítóit, akkor még inkább meg tudja hamisítani a történelmet.

2.1.4. Jóváhagyásra váró és éles állapotok megkülönböztetése

Bizonyos nyilvántartásokban különválik a szerkesztés és az élesítés. A megszerkesztett változtatást letárolják, de jóváhagyásig nem jelenik meg az éles adatok között.

Megvalósítására többféle megoldás is született.

Egyik esetben a változás tulajdonságaként kezelik az állapotát (jóváhagyásra vár, éles), amely tulajdonság megváltoztatható. A korábban leírtak értelmében ez aggodalomra adhat okot, jó esetben a rendszer nem engedi a már élesbe került változtatás állapotának utólagos módosítását. Fontos továbbá visszavonhatatlanul tárolni az állapot változásának időpontját, hogy lehessen tudni, mióta éles.

Máshol új változás létrehozásával léptetik életbe az addig várakozót. Mivel a változás tábla fontos tulajdonsága az időpont és az adatok megváltoztatásának tiltása, ezért nem merülnek fel az előző bekezdésben említett aggodalmak.

Nem mindegy azonban, hogyan élesítik a változást.

Ha felülírják az érintett sorokban a változás azonosítóját, akkor elvész az az információ, hogy mely sorokat érintett a jóváhagyásra váró változtatás. Biztonsági probléma továbbá, hogy módosítani kell hozzá egy korábbi sort.

Másik megoldásban két külön mezőben tárolják a jóváhagyandó és élessé alakító módosítások azonosítóit. Ez esetben nem írnak felül információt az élesítéskor, viszont élesítéskor ugyanúgy bele kell írni a régi sorba.

2.2. Mi a gond a felsoroltakkal?

Nem hitelesek. Újraírható bármelyik előzmény. Az előző állapot érvénytelenítéséhez annak utólagos módosítására van szükség. Utólagos módosítás esetén nem zárható ki az előzmények újraírása.

2.3. Mi a megoldás?

Annak érdekében, hogy kizárható legyen az előzmények módosítása, az alábbi két intézkedés szükséges.

2.3.1. Új változatok tárolása az előzőek módosítása nélkül

Nem adunk hozzáférést korábban letárolt sor utólagos módosítására vagy törlésére. A munkafolyamatot ilyen műveletek nélkül szervezzük. Módosítás és törlés helyett is új sorokat hozunk létre az érintett táblákban, amellyel érvénytelenítjük a korábbi állapotot, de nem írjuk felül és nem adunk lehetőséget az előzmények megváltoztatására.

2.3.2. Hitelesített aláírás és időbélyegzés

Rendszergazdai hozzáféréssel bármilyen adat módosítható. Kikapcsolhatók a módosításokat naplózó eljárások is. Az adatok módosításának kivédésére ellenőrző összeget képzünk, amelyet hitelesített elektronikus aláírással és időbélyegzéssel látunk el.

Az ellenőrző összeg képzésébe bevonjuk az előző változtatás ellenőrző összegét is, így a láncolat egyetlen tagjának módosítása vagy törlése esetén a további változtatások is újraírandók lennének.

3. Hogyan néz ki mindez térinformatikai adatbázisban?

Az eddig leírtak bármely adatbázisra alkalmazhatók. Téradatok verziózott tárolásakor fontos kérdés a geometria tárolásának módja.

3.1. Adattárolás módja

3.1.1. Spagetti adattárolás

Geometriai objektumok (pont, vonal, felület) töréspontjainak koordinátáit tároljuk. Előnye, hogy a geometria bármely időpontban rendelkezésre áll térinformatikai műveletekre, hátránya az átfedő geometriák többszörös tárolása.

3.1.2. Topológiai adattárolás

Csak pontoknál tárolunk koordinátákat. Vonalakat a pontok egyedi azonosítóinak sorozataként tárolunk. Felületek vonalakra hivatkozva építünk fel. Hátránya hogy a geometria felépítése külön műveletet igényel. A gazdaságosabb tároláson kívül fontos előnye a verziókezelés szempontjából, hogy kisebb az ütközések esélye.

Egy pont koordinátájának megváltoztatása nem ütközik a rá hivatkozó vonalak és felületek egyéb módosításával. Egy pont vonalba történő beszúrása nem ütközik a rá hivatkozó felületek egyéb módosításaival.

3.2. Ütközések

Több szerkesztő egyidejű munkája esetén sincs szükség az állomány terület vagy idő alapú zárolására. Az esetleges ütközésekre a változtatás beküldésekor fény derül, az időközben mások által végzett módosítások megtekinthetők, az ütközés feloldása után a változtatás letárolható.

Ütközések egy része feloldható automatikusan is, ha az adott objektum egymástól jól elhatárolható részein történik módosítás. Kérdéses esetekben kézi megoldás szükséges.

4. Hivatkozások

4.1. Git

Programok fejlesztésekor alapvető fontosságú a forráskód verziókezelése. Ennek legelterjedtebb eszköze a Git verziókezelő rendszer. Gyors, nagy méretű feladatokra is alkalmas, nyílt közösség fejleszti, szabad licenc alatt elérhető a forráskódja, ingyenes.

Kiváló mintát ad a verziókezelés elveiről, amely adatbázisokban is megvalósítható. Az első fejezet szempontjai Git fogalmakkal:

4.2. OpenStreetMap

Verziózott adatbázis, minden változatot letárol és csak új változattal enged módosítani. Téradatokat topológiában tárolja. Nyílt forráskódú eszközöket használ, az adatokon kívül az adatbázis és alkalmazás forráskódja is elérhető szabad licenc alatt.