Accesul multiplu la geodatabase

Working with a versioned geodatabase

Accesul multiplu la geodatabase se face prin intermediul versiunilor (versioning). Acest regim permite creearea simultana a structurilor in baza de date fara replication. Utilizatorii pot edita acelasi feature sau tabele fara a fi necesara blocarea (lock) altor utilizatori care modifica aceleasi date.

O institutie care are implementat un astfel de sistem poate gestiona alternative de proiectare, sa rezolve scenarii de tipul "ce.daca" fara impact asupra bazei de date si sa creeze reprezentari temporale ale bazei de date.

In primul rand, versiunile simplifica procesul de editare. Mai multi utilizatori pot modifica direct baza de date fara a fi necesara extragerea datelor sau blocarea featurelor inainte de editare. Daca, din intamplare sunt modificate acelasi features, o caseta de dialog al conflictului de rezolutie il va ghida pe utilizator sa determine reprezentarea corecta a featurelor si a atributelor.

Bazele de date versionificate pot contine topologii. Pentru mai multe informatii asupra modului in care versiunile afecteaza topologia vezi capitolul "Topology".

Bazele de date versionificate pot fi de tipul "check-out database" pentru disconnected editors. Pentru mai multe informatii vezi capitolul "Disconnected editing".

Integrating versioning with your organization work flow

Conceptul de versioning asociat cu geodatabase constituie o tehnica de stocare revolutionara in procesul fluxului de activitati in multe aplicatii privind informatia spatiala. Proiectantii pot genera alternative de proiectare utilizand baza de date in intregime. In cadrul analizei spatiale se pot face scenarii de tipul "ce.daca" fara a afecta reprezentarea curenta din baza de date. Administratorul bazei de date poate crea "historical" snapshots pentru arhivare sau pentru recuperare. Multiuser geodatabase implica o localizare centralizata a bazei de date in care niciodata nu se vor extrage portiuni din aceasta in vederea editarii de feature individuale sau structuri.

The work flow process (fluxul activitatilor)

Evolutia fluxului activitatilor -modul in care activitatile se desfasoara in timp-variaza de la institutie la institutie .

Astfel procesul de versionificare a geodatabase a fost proiectat sa fie cat mai flexibil pentru a raspunde atat cerintelor de baza cat si aplicatiilor complexe, eventual restrictive fara a fi nevoie de aplicatii personalizate suplimentare. In mod normal fluxul de activitati se face progresiv urmand niste etape. La fiecare etapa se cer diferite reguli care restrictioneaza anumite structuri. Fiecare etapa are un nume. De exemplu "working", "proposed", "accepted", "under construction" si "as build". Procesul este ciclic. Initial se genereaza fluxul si o etapa este atribuita unui inginer, apoi se modifica in timp dupa care se progreseaza la etapa superioara.

Fig. p. 268

Acesta este un exemplu de modul in care versioning simplifica fluxul de activitati. Deoarece fluxul de activitati poate lua zile, luni sau chiar ani, baza de date trebuie sa fie permanent disponibila in operatiunile tehnice. Atunci cand se aplica restrictive locks asupra datelor implicate in process, alti utilizatori nu pot sa lucreze pe acestea.

Pentru a implementa fluxul de activitati pe geodatabase, se pot crea versiuni care sa corespunda fiecarei etape din fluxul de activitati. Sistematic se poate crea o versiune pentru fiecare etapa din fluxul de activitati urmata de modificarea numelui versiunii pentru a reprezenta etapa curenta dupa necesitatile procesului pe parcursul fiecarei etape. Structura curenta a fluxului de activitati ale institutiei va influenta semnificativ modul in care procesul de versioning a geodatabase este implementata pentru a gestiona tranzitiile spatiale. Flexibilitatea sistemului va permite determinarea celei mai bune solutii pentru cerintele institutiei.

In cele ce urmeaza din acest capitol se va ilustra modul in care se foloseste ArCatalog si ArcMap pentru a executa diferite versiuni. In particular, ultima sectiune va contine exemple ale modului in care o institutie poate implementa fluxul de activitati utilizand potentialul versiunilor geodatabase. Pentru detalii vezi "Modeling our world".

BOX pag.270 Registering data as versioned

Inainte de a edita seturi de date feature, clase de feature sau tabele intr o geodatabase multiuser, trebuie sa inregistram datele ca versiune in ArcCatalog.

Pentru a face ca o clasa de feature sau tabel sa fie in regim multiversiune este necesar un camp intreg unic. In mod normal acesta este OBIECT 1D. Doar proprietarul datelor poate inregistra sau neinregistra (unregister) obiectul ca fiind versionificat.

Atunci cand un set de date sau clasa de feature neinregistrata este versionificata in ArcCatalog , apare o caseta de dialog de avertizare care ne informeaza ca outstanding edits ramane inca in versiunea existenta. Neinregistrarea clasei ca versiune va avea ca efect indepartarea tuturor editarilor. Pentru a pastra editurile trebuie sa compress database inainte de a reinregistra datele versionificate.

Personal geodatabase nu suporta versiuni.

Tip.

Prin registrarea unui set de date de feature ca versiune se inregistreaza toate clasele de feature din setul de date ca versiune.

BOX pag.271 Creating and administering Versions in ArcCatalog

ArcCatalog ne permite sa creem noi versiuni , sa redenumim versiuni existente, sa stergem versiuni si sa modificam proprietatile versiunilor .Aceste sarcini administrative sunt efectuate prin intermediul casetei de dialog Version Manager.

Initial baza de date consta dintr-o singura versiune numita "DEFAULT", detinuta de administratorul ArcSDE. Noile versiuni se bazeaza intotdeauna pe o versiune existenta. Atunci cand se creeaza o noua versiune , aceasta este identica cu versiunea precedenta, din care ea este dedusa. De-a lungul timpului versiunile vor evolua diferit in functie de modificarile facute in versiunea parinte precum si noile versiuni.

Fiecare versiune are cateva proprietati: un nume (alfanumeric), un proprietar, o descriere optionala, data intrarii, data ultimei modificari, versiunea parinte si permisiunea in versiuni. Permisiunea in versiuni poate fi modificata doar de proprietar.

Setarile disponibile privind permisiunea sunt:

Parinte- doar proprietarul poate vizualiza si modifica clasele de feature

Protected- orice utilizator poate vizualiza versiunea, dar numai proprietarul poate modifica clasele de feature

Public- orice utilizator poate vizualiza si modifica clasele de feature

Doar proprietarul versiunii poate redenumi, sterge sau poate altera (alter) versiunea. O versiune "parinte" nu pote fi stearsa pana cand toate versiunile "copil" nu au fost mai intai sterse.

Pentru a imbunatati performantele baza de date trebuie sa fie compressed periodic. Aceasta compresie va indeparta toate unreferenced database states precum si randure redundante. Doar administratorul ArcSDE poate face aceasta operatiune. Pentru mai multe detalii vezi sectiunea "Versioning Scenarios" de la sfarsitul acestui capitol.

In fine, dupa compresarea bazei de date sau dupa editarea datelor, trebuie sa se execute comanda Analyze pentru a actualiza datele statistice pentru fiecare set de feature sau pentru fiecare clasa de feature.

Acest lucru nu va ajuta pentru a imbunatati performantele de afisare si interogare.

Tip.Description

Se poate utiliza version description pentru a furniza informatii suplimentare privind scopurile versiunii

Tip.sorting versions

In caseta de dialog Version Manager se pot sorta versiunile dand click pe headerul coloanei.

Tip.Refresh

Pentru a actualiza proprietatile fiecarei proprietati ale versiunii cu valorile curente se foloseste comanda Refresh.

See Also

Pentru mai multe informatii privind personalizarea ArcCatalog, vezi "Using ArcCatalog" si "Exploring ArcObjects".

Tip.Analyze

Dupa comprimarea bazei de date, intotdeauna trebuie facuta o analiza privind o actualizare statistica a bazei de date. Se foloseste aceeasi metoda pentru a adauga comanda Analyze in ArcCatalog atunci cand folosim comanda Compress.

See Also

Pentru mai multe detalii a modului de administrare a bazei de date ArcSDE vezi Managing ArcSDE Services.

See Also

Pentru mai multe detalii privind crearea conexiunilor la baza de date vezi "Introduction" din aceasta carte.

BOX pag.278 Working with versions in ArcMap

In Arc Map se poate vizualiza si edita (work) multiple versiuni simultan, si sa se creeze noi versiuni si sa se modifice (transfere) clasele de feature din tabele de la o versiune la alta

De asemenea se poate utiliza version manager, sa se refaca (refresh) o conexiune la spatiul de lucru al versiunii si sa se modifice clasele de feature disponibile in ArcMap.

Pentru a crea o noua versiune , cel putin o versiune trebuie sa fie prezenta pe harta. Daca sunt prezente mai multe versiuni, trebuie sa specificam versiunea "parinte". Noua versiune creata trebuie sa fie identica cu versiunea "parinte".

Schimbarea versiunilor ne permite sa navigam intre doua versiuni schimband clasele de feature curente din harta. Acest lucru simplifica procesul de vizualizare a diferentelor dintre clasele de feature sau executarea unei analize cu cele doua versiuni.

Atunci cand o versiune a spatiului de lucru este schimbata in diferite versiuni toate clasele de feature prezente in spatiul de lucru vor fi noul "target" version.

In ArcMap exista doua metode disponibile pentru schimbarea versiunilor .Aceasta se face in bara de instrumente Versioning sau in Table of Contents (TOC).

Intr-un mediu multiuser baza de date poate fi modificata de un alt utilizator in acelasi timp cu vizualizarea bazei de date. De aceea clasele de feature din ArcMap pot fi reactualizate.

Pentru a actualize baza de date in ArcMap se poate face operatiunea de refresh pe unul sau mai multe spatii de lucru asociate prin click pe butonul Refresh de pe bara de instrumente Versioning. In timpul editarii acest buton e dezactivat.

Pot exista mai multe versiuni pe o harta , in functie de necesitati , dar se poate edita doar una intr-o versiune de lucru.

Tip.Creating backup version

Se pot crea versiuni alternative ca backup ale versiunii originale.

Tip.The Change Version Command

Folositi comanda Change Version in loc de a adauga versiuni multiple pe Map document.

Tip.Preserving a version

Daca se doreste sa se pastreze reprezentarea curenta a bazei de date , se va crea o noua versiune inainte de refresh.

Editing and conflict

Geodatabase este proiectata sa gestioneze eficient si sa suporte tranzactii de dimensiuni mari utilizand versiunile. Geodatabase permite de asemenea ca mai multi utilizatori sa editeze aceeasi versiune in acelasi timp. Fiecare versiune de editare in ArcMap are propria reprezentare a versiunii pana ce se face salvarea. Salvarea sesiunii de editare va avea ca efect reflectarea modificarilor in versiune ,facand aceste schimbari imediat accesibile in baza de date.

Atunci cand utilizatorii multipli editeaza simultan o versiune sau compatibilizeaza (reconcile) doua versiuni pot aparea conflicte. Acestea apar atunci cand aceeasi feature sau feature corelate topologic sunt utilizate de doi sau mai multi utilizatori iar in ceea ce priveste baza de date nu este clar care reprezentare este valida. Conflictele sunt rare , dar apar atunci cand se suprapun (overlapping) areale geografice in baza de date editata. Pentru a nu depinde de integritatea bazei de date, geodatabase detecteaza cand o feature a fost editata in doua versiuni si raporteaza aceasta ca un conflict. ArcMap afiseaza instrumentele necesare pentru investigarea conflictelor, iar utilizatorul final va lua decizia privitor la reprezentarea corecta a featurei.

ArcMap ofera instrumentele pentru a rezolva conflictele and reconcile and post versions. In sectiunile urmatoare vom explica acestea in detaliu.

Reconcile(compatibilitate)

Butonul reconcile din ArcMap reuneste (merges) toate modificarile dintre versiunea curenta si versiunea selectata. Orice diferenta intre featurele din versiunea selectata si featurele din versiunea de editare sunt aplicate in sesiunea de editare.

Diferentele pot consta in feature noi introduse, sau nou actualizate. Procesul de compatibilizare (reconcile) detecteaza aceste diferente si descopera orice conflict. Daca exista conflicte se afiseaza un mesaj, urmat de o caseta de dialog. Trebuie sa compatibilizam editarile inainte de a le lipi (posting) la noua versiune. O versiune target este orice versiune precedenta cum ar fi versiunea "parinte" din versiunea DEFAULT.

In plus , procesul de compatibilizare cere ca doar utilizatorul care editeaza in mod curent versiunea sa fie autorizat in toate privintele sa editeze compatibilizarile(vezi originalul). Daca un alt utilizator editeaza simultan versiunea sau incearca sa initieze editarea in timp ce   utilizatorul autorizat face compatibilizarea, un mesaj de eroare ne va informa ca versionea curenta este in uz.

Procesul de compatibilizare cere ca utilizatorul care face acest lucru sa aiba toate permisiunile la toate clasele de feature care au fost modificate in versiunea editata. Daca o clasa de feature este modificata intr-o versiune pentru care utilizatorul nu are privilegiu (drepturi) va aparea un mesaj de eroare. De asemenea nu se pote face compatibilizarea daca utilizatorul nu are permisiuni (drepturi) pentru aceasta.

Fig.

De exempu sa presupunem ca ati facut modificarile intr-o versiune si trebuie sa le adaugati(post) in versiunea DEFAULT. Mai intai trebuie sa compatibilizati versiunea cu un target version, sa rezolvati conflicte, daca e necesar, apoi sa le adaugati/lipiti (post).

Autoreconcilitation (autocompatibilizarea)

Sa presupunem ca am inceput o sesiune de editare intr-o versiune si un alt utilizator salveaza editarile in aceeasi versiune. Activarea sau dezactivarea autocompatibilizarii afecteaza datele altui utilizator atunci cand cel principal efectueaza salvarea. Daca utilizatorul principal doreste sa i se transmita o notificare acesta va revizui rezultatele inainte de a salva editarile si dezactiveaza autocompatibilitatea. Daca nu doreste sa i se aduca vreo notificare si vrea sa salveze fara a revizui rezultatele, activeaza autocompatibilitatea, ArcMap va trimite o notificare in cazul in care sunt conflicte atunci cand se salveaza.

Fig.p.282

Post (Sincronize)

Odata ce sesiunea de editare a fost compatibilizata cu target version, un click pe butonul Post va produce sincronizarea versiunii si salvarea datelor. Aceasta operatiune nu suporta undo daca schimbarile se aplica la o versiune care nu este editata in mod current. Daca versiunea compatibilizata este modificata intre operatiunile de compatibilizare si sincronizare, utilizatorul va fi notificat sa faca din nou compatibilizarea inainte de sincronizare.

Conflicts

Conflictele apar atunci cand aceleasi feature ( feature corelat topologic sau clase de relatii) sunt modificate in doua versiuni, in versiunea curenta in care se editeaza si in versiunea target. Detectarea conflictelor apare doar in timpul procesului de compatibilizare. Daca se detecteaza conflicte, apare un mesaj urmat de o caseta de dialog al conflict resolution.

Conflict resolution

Odata conflictele detectate, va apare o caseta de dialog numita resolution dialog box care contine toate clasele conflictuale impreuna cu featurele sau liniile din tabele ( rows) aflate in conflict. Aceasta caseta de dialog permite rezolvarea interactiva a conflictelor la nivelul de clase de feature sau la nivel de feature individuale. Rezolvarea conflictelor imlplica de fapt decizia utilizatorului daca featurele au o utilizare corectas aceasta nu inseamna neaparat ca trebuie facut ceva daca reprezentarile sunt satisfacatoare.

Se poate allege din trei reprezentari ale featurelor sau rows in conflict pentru a le rezolva. Versiunea dinintea editarii constituie reprezentarile featurelor initiale, inainte de a face orice modificari. Sesiunea de editare reprezinta featurele care exista inainte de a executa compatibilitatea. Ultima reprezentare este versiunea conflict.

Prin selectarea unei clase de feature sau feature individuale, se afiseaza oricare din cele trei reprezentari ale featurelor pe harta. Versiunea de preeditare este infatisata in Glben, versiunea in editare este infatisata in verde, iar versiunea conflict in rosu.

Fig.

Comentarii la fig. Conductlele laterale in albastru asa cum sunt ele inaintea editarii (A), conductele dupa ce au fost modificate (B) ti cele trei reprezentari tn timpul conflictului (C).

Atunci cand se selecteaza o feature aflata in caseta de dialog Conflict Resolution, reprezentarile featurelor sau randurilor (rows9 din versiune sunt listate in jumatatea a doua a casetei. Punctul rosu din partea stanga a numelui campului identifica featurele aflate in conflict. De exemplu, daca geometria featurei a fost editata in fiecare versiune, va aparea un punct rosu in campul SHAPE. Acelasi lucru este valabil si pentru atributele in conflict. Daca o eature a fost stearsa in alta versiune va aparea "<deleted>" pentru valoarea de atribut din acea versiune. Astfel, un punct rosu va marca fiecare coloana, cu semnificatia ca acea coloana este in conflict de tipul update-delete sau delete-update.

Fig.

Comentarii la fig. Aceasta caseta privind conflictul de rezolutie arata doua clase de feature cu conflicte si o feature cu toate atributele listate din versiunea respectiva.

Rezolvarea conflictului implica o decizie responsabila din partea utilizatorului privitoare la reprezentarea corecta a featurelor. Se pot selecta featurele din caseta de dialof conflict resolution si inlocui in harta curenta cu una din cele trei reprezentari ale featurelor. Aceasta permite executarea unei actualizari rapide si inlocuirea featurelor in conflict. Daca sunt necesare mai tarziu si alte modificari, se poate folosi oricare din comenzile de editare ale ArcMap pentru a actualiza acele features.

Conflicts with geometric returns, feature-linked adnotation and relationships

Rezolvarea conflictelor privitoare la featurele aflate in relatie cu acel feature, cum ar fi cele dintr-o retea geometrica, feature-linked adnotation precum si clasele de relatii este diferita de rezolvarea conflictelor in clasa de feature simple. Deoarece fiecare din aceste clase de feature are un comportament specific in cadrul geodatabase care poate sa aiba un impact asupra altor clase de feature, rezolvarea conflictelor va avea de asemenea un impact asupra featurelor cu care sunt in relatie.

Atunci cand editam feature intr-o retea, schimbarile efectuate in reteaua geometrica si in reteaua logica pot crea conflicte.

Fig.

Comentarii la fig. Magistrala principala de apa originala (A), magistrala de apa schimbata la un diametru de 8 inches in prima sesiune de editare (B), un nou tip de serviciu inserat in sesiunea a doua de editare (C) si magistrala de apa in rosu infatisata ca si conflict.

De exemplu, atunci cand _ un servicu la o magistrala, aceasta nu va fi despicata (split) fizic in reteaua geometrica dar va fi despicata in reteaua logica. Astfel, chiar daca utilizatorul nu editeaza direct geometria magistralei, ea va fi editata logic. Daca in versiunea target cu care se face compatibilizarea s-a modificat de asemenea magistrala, noul serviciu inserat creeaza un conflict cu magistrala.

Rezplvarea unui conflict in care sunt implicate clasele de feature din reteaua geometrica cere o intelegere a modului in care comanda Replace With din caseta de dialog conflict resolutioon va actualiza topologia retelei prezenta in sesiunea de editare.

In exemplul precedent doi utilizatori modifica magistrala de apa- unul schimband un atribut, iar celalalt conectand un nou servicu. Rezolvarea conflictului cere doar investigarea diferentelor si constatarea ca acel conflict este valid si nu mai este necesar (no further resolution is required). Intrucat magistrala contine atributul corect pentru diametru, noul serviciu este corect conectat la magistrala. Dar aceasta este cazul atunci cand rezolvam conflicte in care sunt implicate o clasa de feature junction care se conecteaza la muchiile retelei.

Lucrul cu adnotatii implica urmatoarea regula: atunci cand se inlocuieste o feature care este legata cu o adnotatie, atat feature cat si adnotatia sunt inlocuite cu noua feature si adnotatie. Se poate edita noua adnotatie. De exemplu putem intalni un conflict in care am mutat o feature si am repozitionat o adnotare. Versiunea in conflict a executat aceleasi editari, adica s-a mutat feature si s-a efectuat o rotatie pentru adnotare. Decizia utilizatorului este de a feature cu feature din versiunea in conflict. Aceasta actiune produce stergerea featurei legata de adnotare existenta, inserarea featurei in conflict si crearea unei noi adnotari. Mai trebuie sa facem cateva editari in noua adnotare mutand-o sau rotind-o, dupa cum este necesar.

Relatiile au o dependenta (intre ele) similara. Stergand o feature din clasa de relatie originala poate declansa un mesaj pentru stergerea unei feature din clasa de relatie de destinatie. In consecinta trebuie sa fim atenti la ramificatii atunci cand se rezolva conflictele la care participa clase de relatii.

Un exemplu al modului in care poate aparea un conflict intre clasele de relatii este atunci cand am efectuat o actualizare a campului primar din clasa origine si influenteaza (breaking) relatia in versiunea A. In acelasi timp, in versiunea B, clasa de feature conectate de destinatie este de asemenea actualizata. Atunci cand compatibilizam versiunile, intrucat clasa de destinatie este dependenta de clasa de origine, se va detecta un conflict. Un exemplu similar este atunci cand dorim sa stergem un stalp care este in relatie cu un transformator, transformatorul va fi de asemenea sters. Dar in versiunea conflict atributele transformatorului sunt editate. La o compatibilizare va apare un conflict de tipul update-delete.

Conflicts with topologies

Deoarece featurele din clasele de feature care participa intr-o topologie pot partaja aceeasi geometrie cu alte feature, procesul de rezolvare a conflictelor intre versiuni ale claselor de feature topologizate difera de rezolvarea conflictelor claselor de feature simple. De asemenea sunt diferite fata de cele folosite pentru a rezolva conflictele in cazul retelei geometrice, claselor de relatii si feature-linked adnotation.

Atunci cand o clasa de feature care participa intr+o topologie este editata, celelalte feature legate topologizate pot fi modificate simultan. Modificarea featurelor poate apartine acelorasi clase de feature sau mai multor clase de feature. Pentru gestionarea procesului de detectare a unelor erori topologice care pot fi introduse prin editare, inregistrarile topologice editate sunt facute (declarate/have been made) ca dirty areas. Editarea featurelor intr+o topologie creeaza dirty area in topologie.

Noile erori ale topologiei pot aparea atunci cand versiunile "parinte" si "copil" sunt compatibilizate, chiar si atunci cand dirty areas din fiecare versiune au fost validate si nu au avut erori. Pentru a detecta astfel de erori topologice, dirty areas din versiunea "copil" sunt toate returnate ca si dirty dupa ce modificarile din versiunea "parinte" sunt aduse in ea in timpul unei compatibilizari. Dupa compatibilizare aceste areale pot fi revalidate si orice eroare va fi detectata.

Compatibilizarea a doua versiuni care nu contin dirty areas active poate rezulta dirty area. Orice dirty area care a fost prezenta in versiunea "copil" , fia ca a fost validata sau nu, va fi tot dirty area dupa compatibilizarea versiunilor. In general la compatibilizare avem urmatoarele situatii:

-Orice dirty area pe care versiunea "copil" o mosteneste de la versiunea "parinte" , fie ca a fost validata in versiunea copil fie ca nu, va fi tot dirty area dupa compatibilizare.

-Orice dirty area care a fost creata din orice feature, actualizata sau a fost stearsa in versiunea "copil", fie ca a fost validata sau nu, va fi tot dirty area dupa compatibilizare.

Editing a version( BOX p. 286)

Se va folosi bara de instrumente din ArcMap pentru compatibilizarea versiunilor, rezolvarea conflictelor si sincronizarea versiunilor, precum si post versions.

Atunci cand se incepe sesiunea de editare, daca sunt prezente mai multe versiuni pe harta se va selecta una singura. Inceperea unei sesiuni de editare pe o versiune creeaza una noua, fara nume, temporara care va exista pana in momentul cand se salveaza sau se incheie sesiunea de editare. Veti fi singurul utilizator care poate vedea modificarile pana se va salva explicit.

Atunci cand salvati sesiunea de editare aveti o optiune de activare/dezactivare a autocompatibilitatii. Daca se activeaza comanda, se va autocompatibiliza sesiunea de lucru (versiunea temporara) cu baza de date curenta, facandu-se toate modificarile cu celelalte baze de date. Daca comanda de autocompatibilizare nu este activata, atunci cand salvam, sesiunea de editare va fi compatibilizata cu versiunea curenta. Un mesaj ne va informa ca sesiunea de lucru a fost compatibilizata dar nu a fost salvata. Acest lucru apare doar daca un al doilea utilizator a editat versiunea si a salvat in timp ce am inceput sesiunea de editare. Este nevoie sa salvam inca odata pentru ca datele sa fie disponibile si celorlalti care utilizeaza baza de date.

In functie de necesitatile organizatiei(a fluxului de activitati) putem fi in situatia de a compatibiliza doua versiuni. Compatibilizarea este procesul de "lipire" a featurelor din versiunea target in sesiunea de editare curenta. Compatibilizarea trebuie facuta inainte de a face posting la o alta versiune.

In timpul compatibilizarii pot fi descoperite conflicte. Conflictele pot sa apara atunci cand aceeasi feature este actualizata in fiecare versiune sau actualizata intr+o versiune si stearsa in alta.

Atunci cand apar conflicte, va aparea caseta de dialog conflict resolution care ne ofera comenzile necesare sa rezolvam acele conflicte. Pentru fiecare conflict putem alege cand sa inlocuim feature din sesiunea de editare cu cea din versiunea in conflict, sau cu versiunea existenta la inceputul sesiunii de editare.

Odata ce s-a facut compatibilizarea cu succes, se poate trece la operatiunea posting pentru versiunea respectiva. Aceasta operatiune suncronizeaza editarile din sesiunea de editare cu versiuni target. Ele pot fi identice.

Tip. Topology errors

Atunci cand se editeaza o geodatabase versionificata, regulile topologice pot fi incalcate. Pentru a valida aceste erori, se folosesc tehnicile descrise in cap. "Topology" din aceasta carte sau "Editing topology" din cartea "Editing in ArcMap".

Versioning scenarios

In cele ce urmeaza vom prezenta un scenariu privind fluxul de activitati care poate fi implementat intr+o organizatie. Aceste exemple evidentiaza cateva tehnici disponibile pentru efectuarea tranzactiilor intr+un mediu multiuser. In principiu, orice organizatie va folosi aceste tehnici depinzand de activitatile sale.

Scenariu 1. Simple database modifications

Problema: Utilizatori multipli editeaza in mod concurent baza de date, executand modificari pe aceeasi harta, cum ar fi inserarea de feature noi, actualizarea atributelor si removing out-of-date facilities.

Solutie: Utilizatorii pot sa se conecteze (simultan) la versiunea DEFAULT, sa inceapa editarea si sa salveze modificarile atunci cand au terminat treaba. Utilizatorii nu trebuie sa creeze versiuni pentru a modifica baza de date. Daca un alt utilizator a editat versiunea DEFAULT inca de cand utilizatorul curent a pornit editarea, salvarile utilizatorului sunt notificate ca versiunea a fost modificata (changed) si deci versiunea va trebui salvata din nou. Utilizatorii pot evita acest mesaj de avertizare prin activarea autocompatibilizarii in caseta de dialog Option din arcMap. De asemenea, daca doi utilizatori modifica aceeasi feature in timpul sesiunii de editare, al doilea utilizator va inregistra un conflict. Utilizatorul trebuie sa decida ce feature are reprezentare corecta si sa o salveze in sesiunea de editare.

Scenariul 2. Transactions spanning multiple days

Problema: Actualizarea bazei de date care implica multiple sesiuni de editare si vreo doua zile pentru a fi completa.

Solutie: Un utilizator creeaza o versiune si apoi trece (switches) la o noua versiune dedusa din versiunea DEFAULT. Utilizatorul incepe editarea in noua versiune, modifica features si salveaza. El poate face un rezumat al sesiunii, in urmatoarele zile sau in urmatoarele saptamani. Cand modificarile sunt complete si gata pentru sincronizare (to be posted9 in versiunea DEFAULT, utilizatorul trebuie mai intai sa activeze (clic) butonul Reconcile de pe bara de instrumente Versioning. Daca sunt detectate conflicte, utilizatorul poate rezolva acest lucru dand clic pe butonul Past. Procesul de sincronizare (posting process) se aplica tuturor modificarilor din versiunea utilizatorului in versiunea DEFAULT. Apoi utilizatorul poate sterge versiunea lui.

Scenariul 3: A work flow process

Problema: Crearea unor versiuni individuale pentru fiecare etapa din fluxul de activitati si sincronizarea cu baza de date.

Solutia: Un utilizator sau un supervizor creeaza o noua versiune dedusa din versiunea DEFAULT. Utilizatorul incepe editarea in noua versiune si incepe sa modifice features sau sa creeze un nou proiect. Atunci cand utilizatorul a terminat modificarile sau proiectul propus, fluxul de activitati poate duce la situatia in care acestea sa fie sesizate de catre un supervizor. In acest moment se poate crea o noua versiune pentru a asigura salvarea (pastrarea) modificarilor proiectului initial.

Noua versiune poate fi atunci modificata dupa necesitati. Odata ce lucrarea a fost aprobata, se va crea o noua versiune. Scopul acestei versiuni este de a reflecta orice modificari care pot apare. In final, lucrul fiind complet, lucrarea poate fi sincronizata cu baza de date. Un utilizator poate apoi incepe editarea, sa faca compatibilizarile cu versiunea DEFAULT, sa rezolve orice conflict si apoi sa sincronizeze.

Solutia permite organizatiei sa creeze noi versiuni pentru fiecare etapa din proiect- un proiect initial sau o versiune propusa, o versiune acceptata si o versiune in faza de constructie. Fiecare versiune este pastrata si disponibila pentru diferite scopuri ( a avea o istorie a versiunilor). Pasul final este sincronizarea versiunii respective cu baza de date. Proiectul completeaza un intreg ciclu de la inceput la sfarsit, creand versiuni individuale la fiecare pas.

Scenariul 4:Restricting permissions to the database

Problema: Supervizorul organizatiei restrictioneaza accesul in scriere a versiunii DEFAULT, pentru revizuirea editarilor fiecarui utilizator inainte de a sincroniza modificarile cu baza de date.

Solutie: Pentru a restrictiona permisiunile de scriere in baza de date (in versiunea DEFAULT) , administratorul ArcSDE poate fixa anumite drepturi la versiunea DEFAULT, utilizand o versiune manager. Acest lucru permite insa vizualizarea versiunii DEFAULT fara a putea fi editata de catre utilizatori. Astfel utilizatorii trebuie sa-si creeze propriile versiuni si sa editeze baza de date in conformitate cu scenariul 2. Atunci cand un utilizator a terminat si a salvat editarile, administratorul ArcSDE poate compatibiliza versiunea respectiva cu versiunea DEFAULT. Pentru a duce la implinire acest lucru, managerul care se conecteaza la baza de date ca si administrator ArcSDE incepe editarea versiunii utilizatorului si actioneaza butonul Reconcile. Acest lucru va produce "lipirea" tuturor modificariloe din versiunea utilizatorului in versiunea DEFAULT. Daca se detecteaza conflicte, managerul poate sa le rezolve si sa salveze sesiunea de editare. Odata ce editarile au fost acceptate de catre manager, versiunea este gata de a fi sincronizata cu versiunea DEFAULT. Administratorul ArcSDE poate apoi sa inceapa editarea versiunii, sa execute compatibilizarea si sa sincronizeze versiunea. Acum versiunea utilizatorului poate sa fie stearsa.

Scenariul 5:Compressing the database

Problema: Geodatabase a fost editata pe o perioada lunga de timp si s-au creat un numar mare de database states, de features si de delta tables. Cum imbunatatim performanta geodatabase?

Solutie: Comanda Compress va indeparta toate database states care nu mai sunt referite de o versiune si va muta toate randurile din delta tables, care sunt comune tuturor versiunilor, in tabele de baza (base table). Pentru a obtine un maximum de beneficiu atunci cand se executa comanda Compress, se poate face, optional, mai intai compatibilizarea, sincronizarea fiecarei versiuni cu versiunea DEFAULT. Uneori acest lucru nu este tocmai potrivit pentru fluxul de activitati din organizatie. Cel putin, pentru a imbunatati performanta, trebuie facuta o simpla compatibilizare a fiecarei versiuni cu versiunea DEFAULT si sa se salveze, apoi sa se faca compress. Aceasta ne asigura ca toate activitatile din versiunea DEFAULT vor fi compressed din delata table in tabelul de lucru (business table). Sa ne reamintim ca, comanda Compress poate fi insa executata fara sa se faca mai intai compatibilizarea, sincronizarea si stergerea fiecarei versiuni, dar beneficiile nu vor fi semnificative.