Ukládat, či neukládat (dokumenty do databáze)

Nedávno jsem byl svědkem dvou, poměrně vášnivých, diskuzí na téma zda ukládat dokumenty do databáze, či nikoliv. Osobně se nekloním ani na jednu stranu. Trefně to však vystihl kolega, který prohlásil, že každý preferuje to, co zná. Pojďme se však podívat na věc pokud možno objektivně.

Rychlost (zejména vkládání dokumentu)
Častým argumentem odpůrců vkládání je tvrzení, že vkládání dokumentu na databáze trvá výrazně déle než vkládání na filesystem. Toto (minimálně pro databáze Oracle) byla pravda někdy, dnes již dost dávno. Obecně trvá vkládání do databáze o něco déle, rozdíl je však v jednotkách procent. A pro některé speciální případy (vkládání mnoha krátkých souborů najednou) dokáže být databáze dokonce rychlejší. Stejně tak může být rychlejší, pokud je systém synchronizován (např. z důvodů disaster recovery - databáze synchronizuje celý commit, filesystem každou změnu).

Komprese, deduplikace, šifrování dokumentů
Argumentem zastánců databáze naopak bývá možnost využití databázových options, a to zejména na kompresi vkládaných dokumentů (zmenšení obsahu na disku), deduplikaci (vkládá-li se stejný soubor vícekrát, je uložen fyzicky jen jednou a z dalších míst existuje odkaz) a zašifrování (ani pro db administrátora nebude soubor čitelný, pokud si jej vyhledá prostředky databáze).
Předně, tyto options často bývají k dispozici i na úrovni filesystému (zpravidla taktéž za příplatek). Navíc, jejich přínos je velmi závislý na tom, co se bude do úložiště ukládat (dokumenty MS Office se budou komprimovat dobře, PDF, TIFF či JPEG formátům asi komprese moc neubere), či jak je projekt implementován (přílohy emailů po firmě by se neměly posílat jako soubory, ale jako odkazy do úložiště).

Synchronizace active a stand-by lokality
Podobně je na tom využití technologie DataGuard pro synchronizaci active a stand-by lokality u řešení v rámci disaster recovery. UCM bohužel "odkládá" některá provozní data na filesystem (z těch nejznámějších: stavy položek ve workflows), a tak je podporována jen instalace, kde je synchronizována databáze i filesystem.

Fulltext indexace
Databáze umí (kromě engines třetí strany) indexovat soubory pro fulltextové vyhledávání. Pro využití této vlastnosti však není nezbytně nutné, aby zdrojové soubory byly uloženy v databázi (v databázi je v každém případě výsledný index).

Jednotná správa
Pokud nebudete implementovat model OAIS, který vyžaduje, aby i v případě ukládání dat na "otevřenou platformu" byla data i metadata u sebe, dá se očekávat, že při ukládání na filesystem budou metadata v databázi, tj. při případné ztrátě či chybě, která oba celky od sebe rozpojí, budete mít problémy spojit, co k sobě patří (po pravdě řečeno, i s metadaty rozházenými na disku to nebude o moc snazší). Toto je tedy argument pro databázi. Na druhou stranu, k jeho uplatnění dojde jen v opravdu krizových situacích a v případě správné politiky zálohování lze dopady minimalizovat.

Hierarchical Storage Management
To jest, ukládání starších dat s možnou delší vybavovací dobou na levnější fyzická úložiště lze dosáhnout jak prostředky databáze, tak filesystému - při využití partitioningu bude databáze pracovat s několika málo většími soubory, zatímco na filesystému bude základní jednotkou nejspíš jednotlivý soubor, což opět může být mírný agrument pro databázi.

V souhrnu je tedy vidět, že obě metody jsou srovnatelné s mírnou převahou pro ukládání v databázi. Při výběru metody je tedy třeba zvážit i to, na co jsou zvyklí administrátoři zákazníka či zda zákazník neinvestovat do jedné či druhé metody a očekává zhodnocení svých investic v rámci projektu.

Přehled vlastností Oracle UCM, část 7., pár slov k URM

Dnes budeme pokračovat tam, kde jsme minule skončili. Máme již tedy hotovo:

• odlišení 'records' a 'non-records'
  
• přiřazení dispozičních pravidel

Samozřejmě, jelikož z každého pravidla existují výjimky, nabízí modul records management (RM) způsob, jak se s nimi vyrovnat - takovou výjimkou může být např. vedení soudního procesu, které může být značně nezávislé na skartačních lhůtách a jistě by zákazníka nepotěšilo, kdyby systém uprostřed procesu smazal důležité svědecké důkazy. Tyto výjimky (angl. disposition holds, nebo 'freezes') umožňují vytvořit nad každou položkou jakýsi 'zámek', který ji vyloučí z provedení dispozičních pravidel.

Poslední vlastností, o které se z modulu RM zmíním detailně je audit. Vzhledem k tom, že records management reaguje často na požadavky dané zákonem, nezřídka musí pro případný audit doložit nejen položku a obsah, ale také to, kdo s položkou jak pracoval - včetně seznamu uživatelů, kteří na položku nahlíželi. Samozřejmě, audit v RM je rozšířením standardní funkcionality nabízené Content Trackerem. Jedná se hlavně o tvorbu reportů zaměřených na úlohy spojené s modulem RM.

UCM RM vs URM?
Nyní uděláme malou odbočku na Universal Records Management (URM) - máme-li modul RM v UCM, k čemu ještě potřebujeme produkt Universal Records Management?

1. federovaný records management
URM je schopno provádět centrální nastavení RM politik a díky technologii adaptérů (které je třeba každý zalicencovat!) vynucovat tyto politiky nad řadou úložišť. K dnešnímu dni existují adaptéry pro:

• UCM
• filesystem
• SharePoint
• Documentum
• FileNet
• Symantec Enterprise Vault
• a pak generický adaptér pro .NET a Java umožňující napojení na další úložiště

2. správa fyzického obsahu
URM má také modul pro správu fyzického obsahu. Při práci s fyzickým obsahem (listinné dokumenty či jejich celky jako šanony, ale také fyzická média jako CD-DVD obsahující elektronický obsah, atd.) je třeba podporovat některé další scénáře: obsah je buď 'někde uložen' nebo si jej 'někdo vypůjčil', bylo by vhodné, aby systém uměl sledovat naplněnost skladovacích prostor, atd. Základní myšlenkou je však to, aby hlavní vlastnosti RM, tj. dodržování skartačních lhůt a audit bylo možné nastavit a monitorovat na jediném místě, a to bez ohledu na typ položky.

3. licenční omezení
Aby vše nebylo tak jednoduché, připravil nám product management URM ještě jeden rébus - UCM RM je totiž možné použít v konfiguraci RM modulu 'Minimal' nebo 'Typical'. Bohužel však není nikde specifikováno, které features jsou součástí těchto konfigurací a které nejsou. Věřím, že se jedná zejména o speciální vlastnosti nutné pro DoD certifikace (např. tzv. "klasifikace", což je rozšíření standardních bezpečnostních mechanismů).

V zásadě bych se proto při výběru zda na records management použít URM či jen UCM RM držel hlavně prvních dvou výše zmínených kritérií.

Přehled vlastností Oracle UCM, část 6.

V dnešním článku budeme pokračovat popisem vlastností Oracle UCM a tentokrát se podíváme na oblast, ve které (a asi právem) vládnou určité nejasnosti kolem funkcionality i licencování - records management.

Sám výčet 'vlastností' modulu records management je poměrně strohý:

• records management; to si zaslouží další míru detailu
  
• URM content server adapter; tzn. pokud byste se rozhodli implementovat UCM i URM (k důvodům se také dostaneme - pravděpodobně ve speciálním článku o URM), adaptér, jehož úkolem je napojení URM do UCM a vynucování politik nastavených v URM na úrovni UCM, je součástí licence UCM

Jen pro připomenutí, hlavní požadavky na jakýkoliv ERMS systém jsou dva:

1. zaručit, že položky (na toto téma viz. zde), u kterých je k tomu nějaký důvod (zpravidla zákonný), se nesmažou
2. zaručit, že položky, u kterých k tomu důvod naopak je, se smažou, a to kontrolovaným způsobem dle významu položky

Příkladem z první kategorie mohou být došlé či vydané faktury, které mají skartační lhůtu 10 let; příkladem z druhé kategorie mohou být některé záznamy o zaměstancích, které ze zákona o ochraně osobnosti smí firma držet maximálně 2 roky po rozvázání pracovného poměru; jiným příkladem může být snaha smazat nepotřebný obsah (např. emaily).

V systému, ale vlastně i v metodice, se o splnění těchto požadavků stará spisový plán (angl. file plan či retention schedule), což je hierarchická struktura, zpravidla má podobu stromu, kde je možné uzlům přiřadit různé vlastnosti; zejména pak

• jedná-li se o položky, které nesmí uživatel ad-hoc smazat (viz faktury z našeho příkladu); v UCM/URM je tento požadavek implementován pomocí 3 metadatových 'flagů': isDeletable, isEditable, isRevisionable; mimochodem,všimnětě si, že s 'non-records' položkami je možné pracovat dále jako s živými, tj. vytvářet nové verze, měnit je, dokonce i mazat (v rámci bezpečnostních pravidel), ale přesto je možné na ně aplikovat pravidla jako na 'records'
  
• jaký je životní cyklus položky, resp. jaká dispoziční pravidla se na položku vztahují

Pozn. dispoziční pravidlo je vlastně definicí události a reakce na ni (např. na konci měsíce, v němž vyprší k ukončení pracovní smlouvy se zaměstnancem, počkej 2 roky a pak smaž obsah, včetně metadat). Událostí i možných reakcí je celá řada - události mohou být dané jak časem (př. 10 let po ukončení fiskálního roku), tak nějakou stavovou logikou závislou na vnějších faktorech (př. po dobu 1 roku nikdo položku nepřečetl); reakce pak kromě základních dvou, tj. 'smaž položku i metadata' nebo 'smaž položku, ale ponech metadata', umí pracovat s položkou na mnohem jemnější úrovni metadat či stavů - stavy jako 'Expired', 'Archived', 'Canceled' apod., což se velmi často používá pro přesun položky v rámci fyzického úložiště (s rychlého na pomalý disk či na pásku - samozřejmě, o přesun se stará HSM fyzického úložiště nebo databáze Oracle, nikoliv ERMS). V neposlední řadě je pak třeba zmínit, že jak události, tak reakce mohou být customizovány a že dispozičních pravidel může být přiřazeno hned několik (samozřejmě, každé z nich bude mít trochu jiný úkol - jedno může zaručovat přesun v úložišti, druhé zákonné povinnosti a třetí třeba migraci formátu).

(pokračování příště)