Az informatika más területeihez hasonlóan a térinformatikai feladatok ellátása során is van lehetőség különböző szerepet betöltő szerverek segítségével optimalizálni a munkafolyamatokat. A térinformatikai architektúra egyik leglátványosabb eleme a térképszerver, amely a téradatok szolgáltatásokon (pl. WMS, WFS) keresztül történő elérését teszi lehetővé. Ezúttal azonban egy másik komponensről, az adatbázisszerverről szeretnék szót ejteni, amely az adatok tárolása, kezelése, hozzáférhetősége szempontjából kiemelten fontos szerepet kap(hat) akár a desktop szoftverrel (pl. QGIS, ArcGIS) végzett munka, akár a webes térképes alkalmazások készítése során. Az adatbázisszerverek közül az ArcGIS Database Server for Workgroup-ot választottam, mivel nemrég segíthettem egy olyan rendszer kialakításában, amely ezt a komponenst használja adatbázisszerverként, működésre bírása azonban nem volt annyira egyszerű, ezért gondoltam, megosztom a tapasztalataimat másokkal is.
Mire jó a(z tér)adatbázisszerver?
Az adatbázisszerver használata teljes mértékben opcionális, enélkül is kiválóan el lehet látni a térinformatikai feladatokat. Az adatbázisszerver rengeteg előnyt képes biztosítani, ugyanakkor a szerver kialakítása, üzemeltetése, karbantartása plusz feladatokat is jelent, így azt kell mérlegelni, hogy ad-e annyit (most és a tervezhető jövőben), amennyi vesződséggel jár. Nézzük hát az előnyeit, összehasonlítva egy-két másik megoldási lehetőséggel!
A téradatok nyugodtan tárolhatók shapefájl, geopackage, fájl geoadatbázis, stb. formátumokban lokálisan, saját gépen. Így azonban egyszerre csak egy felhasználó férhet hozzájuk, ha más is szeretné használni ezeket, le kell másolnia az ő saját gépére. A plusz tárhelyigény is fájdalmas lehet, ha már sok adatról van szó, tapasztalatom szerint azonban a legnagyobb gond mégsem ez, hanem az, hogy a különböző példányok nagyon hamar eltérnek egymástól. Az egyik kolléga észlel egy hibát, kijavítja, de ez a javítás csak az ő példányában létezik. A másik kolléga hozzáad egy nagyon hasznos információkat tartalmazó plusz oszlopot, de ez is csak az ő példányában létezik. Az eredetileg egységes adat pedig pillanatokon belül rengeteg változattá alakul, és így az együtt dolgozó kollégák már nem ugyanazt értik, amikor az adatra hivatkoznak, teljesen mást jelent mindenkinek, hogy "hozzáadtam a település réteget".
Ha a téradatokat egy hálózati meghajtón tároljuk, úgy, hogy mindenki hozzáférhessen, a fenti problémát megoldottuk. Ez azonban csak addig jelent megoldást, amíg mindenki csak megjeleníteni (olvasás, read) akarja az adatot. Mert abban a pillanatban, hogy valaki módosítana (írás, write) rajta valamit (kijavítana egy hibát, hozzáadna egy hasznos plusz információt, stb.), ezt nem fogja tudni megtenni, amíg bárki másnál használatban van a fájl. Ilyenkor nincs más hátra, körbe kell kérdezni a kollégákat, hogy ki használja és be tudná-e zárni, amíg elvégezzük a módosítást.
Rengeteg további árnyalata van még az adatok közös használatának, de térjünk rá az adatbázisszerverre. Ha a téradatokat egy adatbázisban tároljuk, mindenki számára elérhetők, akik kaptak jogosultságot az adatbázishoz. Az egyszerre történő használat, egyidejű írás-olvasás sem probléma, ezt az adatbázisszerver kezeli helyettünk. Emellett pedig lehetőséget kapunk arra, hogy olyan lekérdezéseket is végezhessünk az adatbázisban, amelyek a térinformatikai környezetben nem vagy csak rendkívül sok plusz művelettel valósítható meg. (Jellemezően ilyenek a több réteg alfanumerikus adattal vagy térbeli helyzetük alapján összekapcsoló lekérdezések, szűrések.) Az adatbázisszerverhez tartozó SQL kliensszoftverben ezt a lekérdezést sokkal könnyebben meg lehet írni.
ArcGIS Database Server for Workgroup
Az ArcGIS Server architektúra rengeteg választási lehetőséget kínál, hogy a felhasználó a számára legjobban illeszkedő változatot használhassa. Ezek egyike az ArcGIS Enterprise Workgroup, amely néhány szempontból kevesebbet tud, mint a sima ArcGIS Enterprise, ezek közül a témánk szempontjából a legfontosabb, hogy az adatbázis kapcsolatok közül csak a Microsoft SQL Server Express-t támogatja. Ez még önmagában tűnik problémásnak, mégsem volt annyira egyszerű felépíteni ezt a rendszert, mint mondjuk egy PostgeSQL-re épülő rendszert, de nézzük részletesen, hogy mi okozott fejtörést!
Előre szeretném leszögezni, hogy az ESRI dokumentációit általánosságban nagyon jónak, részletesnek, jól kereshetőnek és strukturáltnak tartom. Ebben a témakörben azonban sok-sok keresés és dokumentációolvasás után sem találtam meg mindenre a választ. Ez nem jelenti azt, hogy nem létezik, könnyen lehetséges, hogy csak nem találtam meg a megfelelő oldalt. A most következők egy része így pusztán a saját következtetésem, nem tudok mindent hivatalos leírással alátámasztani. Ezeket a gondolatokat igyekszem megjelölni a "(Következtetés:)" elhelyezésével a gondolat elején.
0. Más logika
Az összes többi adatbázisszerverre épülő ArcGIS rendszer az adatbázisszerverre bízza az authentikációt, így igazából csak az a lényeg, hogy az a gép, amelyikről kapcsolódni szeretnénk az adatbázisszerverhez, "láthassa" azt, vagyis engedélyezni kell a kapcsolódást számára. A kapcsolat létrehozása után a felhasználó azonosítását az adatbázisszerver végzi el.
A Database Server for Workgroup (a továbbiakban DSW) esetében ez nem így van. Először is az ArcGIS Desktop nem közvetlenül az adatbázisszerverhez kapcsolódik. A kapcsolódáshoz szüksége van egy SQL kliens telepítésére az ArcGIS Desktop mellé. A kapcsolódási adatokat is két helyen kell megadni, egyszer az SQL kliensben, egyszer pedig az ArcGIS-ben. (Következtetés:) Az ArcGIS a kapcsolódási kísérlet során először a saját gépén az SQL klienssel fog kommunikálni, ami végül továbbítja az üzenetet a szerver felé és visszafelé ugyanezt az irányt járja be. Így a dokumentációban írt "Direct connection" egy kicsit tágabban értelmezendő.
A másik fontos eltérés, hogy a DSW alapértelmezetten Windows felhasználói authentikációt használ, nem az adatbázisszerver user authentikációját. Ebből sajnos az is következik, hogy a lokális (saját gépen érvényes) felhasználónév nem lesz használható, még akkor sem, ha a szerveren is van azonos nevű felhasználó, mert a myserver\username nem azonos a mymachine\username felhasználóval. Így a local account login csak a szervergépen használható, egyébként a domain account login-re lenne szükség. Ehhez azonban az adatbáziszervernek és a hozzákapcsolódni kívánó gépeknek azonos tartományban kellene lenniük. (Következtetés:) A DSW azt feltételezi, hogy az adatbázisszerver és a hozzá kapcsolódni kívánó gépek egy tartományban vannak.
De mi van abban az esetben, ha az adatbázisszerver nem a tartományunkban van, hanem egy szolgáltatótól bérelt virtuális szerveren? Ha van is erre megoldás, üzemeltetési ismereteim erre egyelőre nem terjednek ki, így számomra maradt az, hogy megpróbáljuk a DSW-t is adatbázisszerverre bízott authentikációval életre kelteni.
1. A Database Server for Workgroup telepítése
Nagyjából az ESRI dokumentációt követve sikeresen települt az adatbázisszerver. Az egyetlen eltérés, hogy az SQL Express-t előtte, külön telepítettem, így az ArcGIS telepítő varázslójában azt a lépést kihagytam.
2. Lokális kapcsolat létrehozása, tesztelése
Elsőként a szervergépen próbáltam ki, hogy sikerül-e kapcsolódni, ehhez feltelepítettem az SQL Server Management Studo-t, mivel a leírásban ajánlott My Esri linken nem találtam a dokumentáció által említett SQL Server Native client szoftvert. Szerencsére az SSMS is teljesen jól működött, tette a dolgát, ezzel nem volt gond, sikerült kapcsolódni az Add Database Server segítségével, a lokális (a szerveren érvényes) Windows authentikációt használva.
3. Kapcsolódás a távoli szerverhez - kudarc
Következő lépésben egy lokális gépről próbáltam megismételni a kapcsolódás lépéseit, elsőként ide is feltelepítettem az SQL Server Management Studiot-t. Itt azonban kijött a már fent írt probléma: nem egy tartományban van a szerver és a gép, amiről kapcsolódni próbálok, így a Windows authentikáció nem használható. Valójában már az SQL kliens sem tudott kapcsolódni, így elég hamar feladtuk ezt a próbálkozást.
4. Adatbázisszerver beállításainak módosítása
Első lépésben biztosítani kellett, hogy az adatbázisszerver távolról is elérhető, ehhez ellenőrizni kellett, hogy a távoli elérés engedélyezve van-e (alapértelmezetten igen, nálunk is így volt), valamint elérhetővé kell tenni a megfelelő portot. Mindennek a beállításához nagyon jó leírást találtam az SQL Server hivatalos oldalán.
Következő lépésben meg kellett változtatni az adatbázisszerver authentikációjának menetét. Ehhez is található leírás az SQL Server oldalán, ahhoz képest csak annyit változtattam, hogy nem az sa nevű usert tettem aktívvá, hanem egy teljesen új user-t hoztam létre és adtam neki megfelelő jogokat.
Furcsa módon azok az SQL Server user-ek, akiket az authentikáció menetének megváltoztatása előtt hoztam létre, nem tudtak kapcsolódni a szerverhez, hiába kapták meg ugyanazokat a jogokat. A változtatás után létrehozott user-ek azonban már képesek voltak a kapcsolódni.
5. Kapcsolódás a távoli szerverhez, újra - siker
A fenti módosítások után ismét a saját gépen próbáltam létrehozni a kapcsolatot. Az SSMS indítása után a Windows authentication helyett az SQL Server authentication-t választottam ki és a leírásnak megfelelően a tcp:<serverIP>,<portnumber> mintát követve adtam meg a Server name értékét. Pl. (kitalált IP és portszámmal): tcp:100.101.102.103,56789. A kapcsolat sikeresen létrejött, az SQL kliens létrehozott egy kapcsolatot, amelyet így nevezett el: 100.101.102.103,56789.
6. Kapcsolódás a távoli szerverhez ArcGIS Desktop-ból
A Database Server kapcsolat sajnos ezután sem működött, az mindenképpen Windows authnetikációt akar használni. Database Connection létrehozásakor azonban kiválasztható az authentikáció módja. Az Instance-hoz alapértelmezetten a szerver neve után visszaperjellel elválasztva az SQLEXPRESS szót várja, pl. MY-SERVER-VPS\SQLEXPRESS. Ez a szervergépen működne is, hiszen ott a MY-SERVER-VPS név feloldható és a gép megtalálja saját magát. Mivel azonban a kliens gép környezetében a MY-SERVER-VPS név nem értelmezhető, le kellett cserélni az SQL kliens által adott névre, tehát a helyes érték (a fenti példát folytatva) így néz ki: 100.101.102.103,56789\SQLEXPRESS.
A szerveren létrehozott SQL user nevét és jelszavát megadva a kapcsolódási ablak alján a legördülő menüben ezek után megjelennek a user számára hozzáférhetővé tett adatbázisok és kiválaszthatja, melyikhez kíván kapcsolódni.
7. Kész vagyunk?
Lényegében igen. A munkafolyamat ebben a rendszerben úgy néz ki, hogy új adatbázis létrehozása esetén az adatbázisszerver adminisztrátora a szerveren a Database Server kapcsolatot használva létrehoz egy új adatbázist és biztosítja a megfelelő jogosultságokat azoknak az adatbázis felhasználóknak, akiknek ezzel az adatbázissal dolgozniuk kell. Ezt követően pedig az említett felhasználók a saját gépükről már tudnak új Database Connection-t létrehozni az új adatbázishoz és jogosultságaiknak megfelelően tudják azt kezelni.
Ha adatbázis-építés, adatelemzés, vizualizáció, térinformatika témában segítségre van szükséged, írj nekünk az Ez az e-mail-cím a szpemrobotok elleni védelem alatt áll. Megtekintéséhez engedélyeznie kell a JavaScript használatát. címre és megpróbálunk egy tippel, ötlettel segíteni!