Versioning a víceuživatelská editace databáze

Jakub Šilhavý

Západočeská univerzita v Plzni, FAV

Obsah

Úvod
Versioning (verzování, vytváření verzí)
Kam zařadit verzování
Základní pojmy
Scénář 1. Přímé editování standardní databáze
Scénář 2. Dvouvrstvá verze
Scénář 3. Náhradník verze DEFAULT
Scénář 4. Vícevrstvá verze
Scénář 5. Cyklická verze
Scénář 6. Správa historických verzí
Zdroje
Závěr - Využití pro terénní mapování
Seznam zdrojů a použité literatury

Abstrakt

Semestrální práce v úvodu vymezuje obecné pojmy důležité pro téma víceuživatelské editace databáze. V hlavní části se zabývá pojmem Versioning (verzování databáze)jako možností databáze ArcSDE od firmy ERSI. Od definice základních pojmů až po popis strategií použití verzování.

Úvod

Databáze lze dnes potkat na každém kroku. Jedná se o nejčastější způsob ukládání většího množství dat. A data jsou základ pro všechny projekty zpracovávané v dnešním digitálním světě. Málokterý projekt si vystačí s jedním pracovníkem, který by sám editoval databázi. Vyvstává tak potřeba víceuživatelské editace, tedy stav, kdy více uživatelů přistupuje ke stejným datům ve stejný okamžik. Multiuser editing, jak je tento proces nazýván v anglicky psané literatuře, v sobě skrývá mimo výhody spolupráce více lidí na jednom projektu také nevýhodu hrozby konfliktní situace (viz obr. 1 – „Víceuživatelská editace - konflikt“).

Obrázek 1. Víceuživatelská editace - konflikt

Víceuživatelská editace - konflikt

Představme si, že dva nebo více uživatelů najednou mění stejný prvek ve stejné databázi. Konflikt nastává v momentě, kdy se jeden uživatel pokusí uložit změny po té, co jiný uživatel své změny uložil dříve. Riziko konfliktních situací narůstá s časem potřebným na provedení transakce.

Pojem transakce v databázovém kontextu znamená posloupnost operací nad prvky databáze, která realizuje jednu ucelenou operaci z pohledu uživatele. V geografických informačních systémech (GIS) se setkáváme hlavně s termínem dlouhá transakce. Mnoho GIS editací si vyžádá více než pár minut a některé úpravy zaberou hodiny, dny či dokonce měsíce než jsou dokončeny.

Existují dvě základní možnosti jak přistoupit k víceuživatelské editaci. Podstatou prvního z nich, pesimistického přístupu, je vyloučení možnosti, že konflikt nastane. Objekty databáze editované jedním uživatelem jsou pro ostatní uživatele nepřístupné, databázový systém provede zamčení celé databáze, jedné tabulky, jednoho řádku nebo jedné buňky. Tento způsob zamykání je dobře realizovatelný u klasických (lexikálních) databází, v případě prostorových je situace obtížnější. Ochránit před dvojí editací je potřeba celé prvky, které je zapotřebí zamknout. Ty mohou ale zasahovat i do jiných výřezů než je ten aktuálně editovaný. Kvůli jednomu objektu se zbytečně znepřístupní příliš velká oblast databáze. Z tohoto důvodu se pesimistický přístup v prostorových databázích příliš neuplatňuje.

Optimistický přístup vychází z předpokladu, že ke konfliktu nedojde, případně jen v omezeném množství. Nedochází k zamykání databáze a jejích částí, uživatelé editují stejnou databázi ve stejný okamžik. Po dokončení transakce a uložení změn následuje kontrola konfliktů. V případě konfliktu je na editorovi (uživatel, který uložil změny) nebo na správci databáze rozhodnout, která ze tří verzí se do databáze uloží (viz tabulka 1 – „Řešení konfliktu - tři možnosti uložení “).

Tabulka 1. Řešení konfliktu - tři možnosti uložení

VerzePopisZ pohledu editora
edited versionverze uživatele, který způsobil konfliktmoje verze
conflict versionverze uživatele, který uložil dřívecizí verze
pre-edited versionverze existující před začátkem editace uživatele, který způsobil konfliktpůvodní verze

V případě dlouhé transakce jsou všechny změny provedené uživatelem uchovávány v takzvaných Add a Delete tabulkách, souhrnně označovaných jako Delta tabulky (delta tables). Prvky nově přidané znamenají záznam do tabulky Add (dodatky), naopak prvky smazané se zaznamenají do tabulky Delete (výmazy). Úprava existujícího prvku (změna geometrie, polohy...) vyžaduje zápis do obou tabulek najednou (starý tvar je smazán a nový přidán). Ukázka delta tabulek je na obrázku 2 – „Dlouhá transakce - delta tabulky“.

Obrázek 2. Dlouhá transakce - delta tabulky

Dlouhá transakce - delta tabulky

Versioning (verzování, vytváření verzí)

Verzování umožňuje vytvářet více stálých reprezentací databáze bez zdvojování a omezujícího zamykání dat.

Kam zařadit verzování

Je potřeba zmínit, že versioning (dále jen verzování) je jedna z funkcí prostorové databáze ArcSDE od společnosti ESRI. Pojem verzování se tedy týká pouze tohoto jediného produktu, ale to neznamená, že podobnou strategii není možné využít i v jiných prostorových nadstavbách klasických databází.

Pro zodpovězení otázky, kam zařadit verzování je třeba pochopit problematiku propojení od klasických databází až po GIS aplikace. Nutnost ukládat prostorová data přišla až v době, kdy již existovaly rozsáhlé možnosti ukládání dat lexikálních. A protože prostorová a lexikální data se ráda doplňují, místo vývoje nových standardů se vytvořily prostorové nadstavby pro klasické databáze. Jak ukazuje ilustrativní obrázek 3 – „Zařazení prostorových databází“ na příkladu často nasazovaných řešení, tyto nadstavby tvoří prostředníka mezi klasickými databázemi a GIS aplikacemi.

Obrázek 3. Zařazení prostorových databází

Zařazení prostorových databází

Podle polohy ArcSDE je zřejmé, že versioning není vymožeností toho či onoho SŘBD (Systém řídící báze dat), ale je to vhodné využití jejich funkcí aplikací ArcSDE. Pokud bychom chtěli hledat alternativu k verzování musíme se poohlédnout u nástrojů a funkcí produktů jako Oracle Spatial nebo PostGIS. Právě pro PostGIS jsem nalezl alternativu v podobě jednoho nástroje GeoTools.

Základní pojmy

Hlavním účelem verzování je zjednodušit proces editace dlouhých transakcí. Existuje mnoho strategií jak využít verzování. Jejich popisem se budu zabývat v následujících odstavcích. Na začátku je však potřeba vymezit důležité pojmy k tématu verzování.

Reconciling, reconcile.  - proces, který začlení změny z nadřazené (rodičovské) verze do verze, která je editována. Česky by se dal tento pojem přeložit jako smíření se, přizpůsobení se rodičovské verzi. Reconciling je náročná operace, která automaticky vloží, smaže a aktualizuje mnoho prvků editované verze. Odtud plyne možnost vzniku konfliktů, úkolem reconcile je všechny tyto konflikty vyřešit. Operaci reconcile provádíme na editované verzi vzhledem k její libovolné nadřazené verzi, nemůže být provedena vzhledem k verzi na stejné nebo nižší úrovni. Jako jiné operace může být vrácena do původního stavu, tzn. existuje zpětná operace.

Posting, post.  - proces, který posílá změny z následníka na předka. Operaci post musí bezprostředně předcházet operace reconcile ke stejné cílové verzi. Pokud mezi operací reconcile a post jiný uživatel změní cílovou verzi databáze, musí být proces reconcile proveden znovu. Díky tomuto opatření během procesu posting nemůže dojít k žádnému konfliktu (vše vyřeší reconcile). Změny provedené operací post jsou nevratné.

Obrázek 4. Názorná ukázka operací reconcile a post

Názorná ukázka operací reconcile a post

Pro aktualizaci nadřazené verze databáze z editované verze po dokončení všech změn se provedou operace reconcile a post v tomto pořadí (viz obr. 4 – „Názorná ukázka operací reconcile a post“).

Scénář 1. Přímé editování standardní databáze

Nejjednodušší případ verzování obsahuje jednu verzi. Tou je standardní (hlavní) databáze označovaná termínem DEFAULT. Každý uživatel edituje automaticky vytvořenou, nepojmenovanou, dočasnou verzi - nemusí zvlášť vytvářet verzi vlastní. Po dokončení editace nebo po uložení změn jsou na dočasné verzi automaticky provedeny operace reconcile a post vzhledem k DEFAULT verzi (viz obr. 5 – „Přímá editace verze DEFAULT“). Když nastane konflikt, editor musí rozhodnout, které změny uloží.

Přímé editování verze DEFAULT se uplatní tam, kde jednotlivé transakce nejsou časově náročné. Daní za jednoduchost je nepodporování dlouhých transakcí, které trvají více pracovních úseků a vyžadují více verzí. Protože je editována jedna verze, v jeden okamžik může probíhat pouze jeden proces reconcile, který je časově náročný. Při větším počtu editorů se rapidně zvyšuje doba čekání na příkaz post ve chvíli, kdy ukládá více uživatelů na jednou. Na rozdíl od propracovanějších verzi nedokáže ukládat historii příkazů a nepodporuje dávkové zpracování procesů reconcile/post.

Obrázek 5. Přímá editace verze DEFAULT

Přímá editace verze DEFAULT

Scénář 2. Dvouvrstvá verze

Mnohem běžnější a stálé jednoduchý přístup je dvouvrstvé verzování, které odděluje práce spojené s jedním konkrétním projektem. Je vhodný pro dlouhé transakce - po dobu editování se změny ukládají do vlastní vytvořené verze databáze, která znamená novou dlouhou transakci, na které může pracovat více uživatelů. Když je projekt dokončen provedou se operace reconcile a post vzhledem k DEFAULT verzi. Po té může být verze projekt smazána nebo uchována pro archivaci (viz obr. 6 – „Dvouvrstvá verze“).

V tomto přístupu jsou uživatelská práva k hlavní databázi omezena pouze na čtení, což donutí editory založit si vlastní verzi databáze. Výhodou dvouvrstvého verzování je logické uspořádání prací na projektu a větší ochrana hlavní databáze. Každý editor může vyvinout vlastní návrh bez ovlivnění původní databáze. Také se zde dá uplatnit dávkové zpracování procesů reconcile/post. Jako u každé víceuživatelské databáze je spravováno více řádků v delta tabulkách, což snižuje rychlost dotazování. Tento nedostatek se dá napravit pravidelnou kompresí databáze.

Obrázek 6. Dvouvrstvá verze

Dvouvrstvá verze

Scénář 3. Náhradník verze DEFAULT

Obměnou dvouvrstvého přístupu je použít jako cíl operací reconcile/post náhradníka DEFAULT verze. Jedná se o způsob ochrany hlavní databáze před neautorizovanými a neúmyslnými změnami. Náhradník je vytvořen administrátorem databáze jako následovník DEFAULT verze a všechny verze ostatní jsou odvozovány od náhradníka. Procesy reconcile a post mezi náhradníkem a DEFAULT verzí spravuje administrátor, bez vlivu na ostatní uživatele (viz obr. 7 – „Náhradník verze DEFAULT“).

Tato varianta dvouvrstvého přístupu přebírá všechny jeho výhody a navíc lépe zabraňuje nevyžádaným změnám veřejné databáze. Na druhou stranu při velkém počtu verzí odvozených od náhradníka a při velkém počtu editací uživatelů se projeví nutnost dvojího zpracování procesů reconcile a post - od verzí k náhradníkovi a zároveň i od náhradníka k hlavní databázi. Tím se zvyšuje časová náročnost celého přístupu.

Obrázek 7. Náhradník verze DEFAULT

Náhradník verze DEFAULT

Scénář 4. Vícevrstvá verze

Složitější projekty si nevystačí s přímou editací nebo s dvouvrstvým přístupem. Využívají propracovanější více členěnou strukturu pracovního postupu. Komplexnější projekt zahrnuje mnoho editorů často pracujících v různých týmech na samostatných úkolech. Efektní způsob organizace práce za takovýchto podmínek spočívá v tom, že týmy pracující na různých částech projektu si vytvoří vlastní verzi, do které editují změny. Po dokončení projektu je verze operacemi reconcile a post aktualizována do hlavní databáze (viz obr. 8 – „Vícevrstvá verze“).

Procesy reconcile a post musí být prováděny postupně od přímých následovníků verze DEFAULT k nejnižším verzím pracovního schématu. Z toho plyne, že je vyloučeno provést operace reconcile a post nejnižší verze přímo vzhledem k verzi DEFAULT. Proces reconcile může probíhat pouze mezi verzemi jedné větve, nikoli napříč schématem. Správa vícevrstvého verzování je náročná na výpočetní výkon, s počtem řádků v delta tables klesá rychlost dotazování. Podporou komplexních projektů se rozumí i podpora dlouhých transakcí a dávkového zpracování procesů reconcile a post.

Obrázek 8. Vícevrstvá verze

Vícevrstvá verze

Scénář 5. Cyklická verze

Mnoho projektů se vyvíjí skrz pracovní fáze s pevným pořadím, kde začátek jedné fáze je podmíněn koncem té předchozí. Každá dlouhá transakce z předchozích scénářů může být rozdělena podle fází pracovního procesu. Například návrh, schválení a realizace představují tři fáze jednoho projektu a zároveň tři verze databáze. Nová verze je vytvořena po dokončení předchozí a obsahuje všechny její změny. Operace reconcile a post proto stačí provést jen na poslední verzi v pracovním schématu. Tím se výrazně šetří čas, který by byl nutný, pokud by proces reconcile a post probíhal po skončení každé fáze. Při archivaci jednotlivých vývojových částí projektu můžeme snadno zjistit, co bylo navrhnuto, co schváleno a co realizováno (viz obr. 9 – „Cyklická verze“).

Obrázek 9. Cyklická verze

Cyklická verze

Scénář 6. Správa historických verzí

Klíčovým požadavkem mnoha projektů je zachycení historie vývoje v čase pro archivaci a pozdější kontrolu. Při editaci se normálně neukládá automaticky její čas, ale je možné využít verzování a zaznamenat tak časové změny projektu. Uchovávání historických verzí je založeno na událostech při změně databáze (change events). Událost je vyvolána po každé změně stavu databáze. Na základě požadavků projektu nastavíme, v jakých intervalech se mají vytvářet nové verze. Závisí to především na frekvenci editace databáze. Takovýto přístup podporuje dotazy typu: "Jaký byl stav databáze v určitý čas?", "Jak se změnil určitý objekt během daného období?". Přesnost odpovědi závisí na frekvenci ukládání verzí. Stejně jako u ostatních strategií se s každou verzí ukládají delta tabulky. U složitějších projektů je tak ukládáno velké množství informací. K efektivnímu využití je vhodné starší verze archivovat mimo databázi, zvýší se tím výpočetní výkon (viz obr. 10 – „Správa historických verzí“).

Obrázek 10. Správa historických verzí

Správa historických verzí

Zdroje

V práci bylo čerpáno převážně z přednášek Karla Jedličky k předmětu KMA/AGI, z výukových materiálů firmy ESRI Understanding ArcSDE. Bližší popis verzování byl čerpán z Versioning Workflows, také materiálu firmy ESRI.

Závěr - Využití pro terénní mapování

Při využití některého ze scénářů verzování získáme v databázi přehledný systém, který nám usnadní její správu. Při vytváření mnoha různých verzí celé databáze nedochází k nadbytečnému zdvojování ukládaných dat, ale na druhou stranu více delta tabulek snižuje rychlost dotazování nad databází.

Jednou vhodnou aplikací verzování na terénní mapování je použití verzí reprezentujících území, které na sebe navazují a dohromady pokrývají celý zájmový prostor. Uplatní se při rozdělení těchto území mezi jednotlivé terénní pracovníky. Pokud se nejprve zmapují společné hranice jsou při dodržení nepřekrývajících se území konflikty prakticky vyloučeny.

Další variantou je použít verze znázorňující tematické celky. Například předem rozdělit mapování na polohopisné a výškopisné a ty dále dělit na další tematické části, jak je ukázáno na obrázku 8 – „Vícevrstvá verze“.

Seznam zdrojů a použité literatury

[JEDLIČKA 07] Karel JEDLIČKA: Přednášky AGI, Plzeň , ZČU, 2007,

[ESRI 04] ESRI: Versioning Workflows, Redlands , ESRI, 2004,

[ESRI 02] ESRI: Understanding ArcSDE, Redlands , ESRI, 2002,

[POSTGIS 03] Data Versioning?, Internetová diskuze Postgis-users, 2003, [citováno 2008-01-23]. Dostupné z URL: http://postgis.refractions.net/pipermail/postgis-users/2003-July/002726.htmll.