Správa dat Souborného katalogu ČR

Obsah:

1. Sběr dat pro souborný katalog od roku 1995
2. Zpracování dat pro souborný katalog v systému ALEPH
3. Zpracování dat pro souborný katalog s využitím vlastních aplikací databázového systému ORACLE
4. Sdílení záznamů v rámci souborného katalogu

1. Sběr dat pro souborný katalog od roku 1995

Z hlediska kvality souborného katalogu je jistě velmi významná skutečnost, že na samém počátku sběru dat byla stanovena jednotná instrukce, která specifikovala strukturu a obsah záznamu pro souborný katalog. V září 1994 byl vydán návrh instrukce Záznam pro souborný katalog, na jejímž základě v lednu 1995 správce zahájil první kontakty s knihovnami, které projevily zájem přispívat svými záznamy do souborného katalogu. V červnu 1995 byly do souborného katalogu importovány první záznamy zahraničních monografií a do konce roku 1995 bylo importováno celkem 25.000 záznamů osmi knihoven. Ověřovací provoz souborného katalogu, kdy byly přijímány záznamy pouze zahraničních monografií bez možnosti kontroly duplicit, probíhal od 1.1.1996 do 31.1.1997, na konci ověřovacího provozu souborný katalog obsahoval téměř 44.000 záznamů čtrnácti účastníků.

V květnu 1996 vydala Národní knihovna ČR schválenou instrukci Záznam pro souborný katalog: UNIMARC. Tištěné monografie (diskuse nad návrhem instrukce trvala téměř dva roky, což svědčí o obtížnosti vytvoření takové instrukce pro souborný katalog). V lednu 1997 bylo dokončeno testování programu na kontrolu duplicit pro souborný katalog a všechny záznamy do té doby dodané do souborného katalogu byly porovnány na duplicitu. K 1.2.1997 zahájil souborný katalog příjem záznamů nejen zahraničních, ale také českých tištěných monografií a zahájil tak svůj rutinní provoz. Na konci roku 1997 souborný katalog obsahoval téměř 65.000 záznamů (z toho 1.780 duplicitních) devatenácti českých a moravských knihoven.

Kvantitativní údaje naplňování souborného katalogu v letech 1995 - 1999 ukazuje graf.

2. Zpracování dat pro souborný katalog v systému ALEPH

Již v prvních koncepčních materiálech Souborného katalogu je konstatováno, že "cílovým principem budování Souborného katalogu je sdílená katalogizace on-line." Bylo zdůrazňováno, že právě zajištění sdílené katalogizace pro knihovny v ČR je hlavním důvodem změny systému pro souborný katalog. Méně se však hovořilo o tom, že vývoj vlastních aplikací pro provoz a správu souborného katalogu v systému ORACLE je pro správce nezbytné z důvodu zásadní racionalizace zpracování a celkové správy dat.

Souborný katalog byl provozován v systému ALEPH, který však neumožňuje provádět import záznamů s kontrolou na duplicity dle potřeb souborného katalogu a dále nedovoluje zásahy do záznamů v bázi jinými než vlastními prostředky. Další modifikace pomocí programů je nutno provádět mimo bázi. Správce souborného katalogu používá externě vytvořený program pro řízený import s kontrolou duplicit. Toto řešení však vyžadovalo aktivaci procedury kontroly duplicit mimo bázi v systému ALEPH, a tudíž bylo možné zpracovávat pouze data získaná off-line.

Účastnící souborného katalogu zasílají data na ftp server nebo na disketě klasickou poštou. Zasílání dat prostřednictvím e-mailu se neosvědčilo, velmi často docházelo k narušení struktury i obsahu dat.

Celý proces zpracování záznamů se skládal z těchto fází:

• kvalitativní analýza dat - konverze dat
• konverze dat do exportního souboru ALEPH
• konverze znakových sad do ISO 8859
• rozlišení záznamů českých a zahraničních dokumentů
• přidělení kvalitativní váhy
• řízený import dat do báze souborného katalogu
• obnovení kompatibility pomocného souboru BASE s bází souborného katalogu pro import dat

2.1. Kvalitativní analýza dat

Kvalitativní analýza dat spočívala v ruční kontrole struktury a obsahu dat u každé dodané dávky. Pokud se jednalo o účastníka, který již dodával data pravidelně, byla prováděna pouze namátková kontrola u každé nové dávky dat. Záznamy všech nových účastníků jsou prověřovány velmi pečlivě v několika kolech, kdy dochází k aktivní komunikaci písemné i telefonické a osobní mezi správcem souborného katalogu a účastníkem, který má zájem o dodávání svých záznamů do souborného katalogu.

Pro potřeby kvalitativní analýzy se záznamy ve formátu UNIMARC i ve Výměnném formátu zaslané jako ISO soubory importovaly do pomocné báze na lokálním PC, kde probíhala vlastní kontrola obsahu záznamů. Záznamy dodané v řádkovém UNIMARCu nebo v ALEPH load formátu se prohlížely jako textové soubory.

Výsledek kvalitativní analýzy správce písemně oznámil účastnické knihovně. Pokud byla data v pořádku, přesunul správce soubor dat do jiného adresáře na lokálním PC a přistoupil k jejich konverzi.

2.2. Konverze dat

Konverze dat do exportního souboru ALEPH Správce provedl konverzi dat do exportního souboru ALEPH (ALEPH load formátu), k tomu účelu spustil některý z níže uvedených programů, jenž vybral na základě použitého formátu dat a znakové sady v konkrétním souboru dat:

Konverze znakových sad do ISO 8859
Bylo-li to nutné, provedl správce konverzi znakových sad do ISO 8859 s využitím programu:

XLIT: konverze znakových sad do ISO 8859
Dávky záznamů jednotlivých účastníků tvořily samostatné soubory. Ty byly po skončení kvalitativní analýzy a konverze přesunuty pomocí ftp z adresáře na lokálním PC na server, kde správce pokračoval v jejich zpracování.

2.3. Rozlišení záznamů českých a zahraničních dokumentů

S využitím programu BASE1 přidělil správce záznamům tzv.logické báze, které umožňují rozlišení záznamů českých a zahraničních dokumentů.

2.4. Přidělení kvalitativní váhy

Váha je numerická hodnota vyjadřující kvalitu záznamu. Správce musel otevřít soubor záznamů ve vi editoru, prohlédnout jejich obsah (při tom se však již opíral o provedenou kvalitativní analýzu) a přidělit příslušnou váhu (viz Tabulka 1).

Tabulka 1

2.5. Řízený import dat do báze souborného katalogu

JIMCHECK - program pro řízený import dat do bází ALEPH s kontrolou duplicit pracoval následujícím způsobem:

• program pracoval s pomocným souborem BASE, který byl vytvořen exportem báze ALEPH, ale obsahoval pouze vybraná pole tj. pole, která se používala k identifikaci dokumentu a k tvorbě porovnávacích klíčů; proti záznamům v souboru BASE porovnával záznamy, které byly určeny pro souborný katalog, a upravoval je pro import do báze ALEPH
• pomocný soubor musel být před každým zpracováním vstupních dat v souladu s bází ALEPH
• aby nebylo nutné po každém importu do souborného katalogu provádět export pomocného souboru BASE z báze ALEPH, modifikoval doplňkový program JIMAPP pomocný soubor BASE tak, aby byl v souladu se stavem báze ALEPH po importu nových záznamů; program JIMAPP do něj přidává nově přidané záznamy neduplicitní
• stav báze ALEPH mohl být v souladu se stavem pomocného souboru BASE pouze za podmínky, že se v bázi ALEPH neprováděly žádné modifikace cestou on-line (tj. ani katalogizace, ani údržba autorit); po každé modifikaci v bázi ALEPH by totiž bylo třeba znovu vytvořit pomocný soubor BASE, jinak dojde ke ztrátě informací, vzniku nežádoucích nových duplicit a možná i "falešných spojů".

Program pro řízený import (JIMCHECK) vyrobil následující výstupní soubory:

• soubor s příponou add obsahovaluje duplicitní záznamy se stejnou nebo nižší vahou než nalezený originální záznam, ke kterému se připíše pouze sigla vlastníka duplicitního záznamu
• soubor s příponou upd (update) obsahoval duplicitní záznamy s vyšší vahou než originální záznamy v bázi souborného katalogu; záznamy s vyšší vahou přepíší záznamy s nižší vahou, ze kterých se zaznamenává pouze sigla vlastníka dokumentu
• soubor s příponou new obsahoval záznamy, ke kterým program neobjevil duplicitní, tyto záznamy se přihrají jako nové do báze souborného katalogu
• soubor s příponou err obsahoval chybové záznamy, které program vyřadil pro závažnou chybu; bylo-li to možné, správce data opravil ručně s využitím pomocných programů globálních oprav.

Soubory add, upd a new se jeden po druhém importovaly do báze souborného katalogu, přičemž správce použil alephovské utility - UTIL 91 : import dat do báze.

Po úspěšném importu všech tří souborů se s využitím UTIL 101 a UTIL 303 opět exportovaly záznamy souboru new, přičemž všechny nové záznamy již měly své SYSNO (systémové číslo v rámci báze souborného katalogu). S využitím doplňkového programu JIMAPP se tyto záznamy ve zkrácené formě a se správnými SYSNO přihrály na konec pomocného souboru BASE a obnovila se tak jeho kompatibilita s bází souborného katalogu pro další import záznamů jiné knihovny.

Řízený import dat s kontrolou duplicit do souborného katalogu s využitím programu JIMCHECK trvá nejméně osm hodin, pokud se vyskytly komplikace i déle. Přitom nezáleželo na velikosti jedné dávky dat, protože program "čte" celou bázi, ale záleželo na velikosti báze, která pochopitelně stále roste.

Z výše uvedeného vyplývá, že zpracování dávky dat jedné knihovny (bez ohledu na to, zda obsahoval 100 či 10 000 záznamů) trvala dva pracovní dny. Od počátku roku 1998 je souborný katalog zdrojem pro kooperativní zpracování České národní bibliografie, proto správce musí pravidelně každý měsíc přednostně importovat záznamy MZK v Brně a ostatních státních vědeckých knihoven, které se na kooperativním zpracování ČNB podílejí. Lze si snadno spočítat jak málo pracovních dní zbývalo správci souborného katalogu na zpracování záznamů ostatních účastníků (cca 28 knihoven). S rostoucím počtem záznamů v souborném katalogu probíhal vlastní import jednotlivých dávek stále pomaleji. Správce řešil situaci tak, že pokud to bylo nezbytné, importoval záznamy ostatních účastníků po dvou až třech dávkách najednou. Každé řešení tohoto stavu bylo však na úkor aktuálnosti souborného katalogu. Racionalizace správy souborného katalogu a tudíž i značné zrychlení importu dat bylo vyřešeno využitím vlastních aplikací pro souborný katalog v systému ORACLE.

3. Zpracování dat pro souborný katalog s využitím vlastních aplikací databázového systému ORACLE

Potřeba zásadního zkvalitnění správy souborného katalogu a nutnost dalšího rozvoje služeb pro uživatele i knihovníky vedla k rozhodnutí vývoje vlastních aplikací s využitím databázového systému ORACLE pro správu i provoz souborného katalogu. Veškeré služby jsou realizovány prostřednictvím SQL Serveru ORACLE a WebServeru ORACLE, a to při zachování všech současných standardů pro dodavatele a příjemce dat (navíc jsou přijímána data využívající UNICODE UTF 8).

Od března 1998 probíhá vývoj aplikací pro provoz souborného katalogu v systému ORACLE, dne 9.9.1999 byla omezenému okruhu uživatelů zpřístupněna beta verze vyvíjeného systému k testování (byly zpřístupněny záznamy tištěných monografií). Došlo ke značné automatizaci všech činností spojených se správou bází souborného katalogu včetně analýzy vstupních dat, a to s maximálním využitím k tomu účelu dosud vytvořených softwarových prostředků.

Při vývoji aplikací pro souborný katalog v systému ORACLE měl správce na mysli maximální racionalizaci pracovních postupů, která spočívá v eliminaci lidského zásahu všude tam, kde je to možné a efektivní.

Zpracování záznamů probíhá zcela automaticky:

• příjem a identifikace souboru dat (včetně konverze)
• formálně logické kontroly dat - import dat - statistiky
• problémy k řešení pro správce

3.1. Příjem a identifikace dat

Účastník umístí svá data v přiděleném prostoru na ftp serveru (pokud je dodá na disketě, nahraje je na ftp server správce). Program v pravidelných intervalech kontroluje, zda na ftp server nepřibyla nová data. Stáhne je a dle názvové konvence (viz níže) zjistí jejich vlastníka, v jakém jsou formátu a jaká byla použita znaková sada.

Názvová konvence - délka názvu datového souboru je 8 + 3 tedy 11 znaků:

• prvních 6 znaků názvu tvoří sigla instituce
• znaky 7 a 8 popisují použitou znakovou sadu
• znaky 9, 10 a 11 popisují formát dat

Příklady:

3.2. Formálně logické kontroly dat

Všechny nové i editované záznamy jsou před importem do souborného katalogu testovány. Součástí automatické kontroly je:

• test na UNIMARC
• přidělení kvalitativní váhy
• test na duplicitu záznamů.

Test na UNIMARC

Pomocí vyvinuté aplikace jsou jednotlivé záznamy automaticky testovány na správnost zápisu do polí formátu UNIMARC. Algoritmus testování na UNIMARC je podrobně popsán v materiálu Souborný katalog ČR. Zadání pro vývoj aplikací v systému ORACLE. 1.kapitola Příjem dat, u všech polí se prověří:

• zápis obecně
• opakovatelnost polí a podpolí, přítomnost a hodnota indikátorů
• různé podmínky zápisu v poli

Přidělení kvalitativní váhy

• byla vytvořena tabulka sigel a k nim přidělených vah pro knihovny, které již dodávají záznamy.
• každá nová knihovna je ručně analyzována, správce jí přidělí váhu a zapíše do tabulky
• vyskytne-li se v prostoru pro vstupní data soubor se siglou v názvu, která dosud není v tabulce, neanalyzuje se automaticky, ale je upozorněn správce, který data analyzuje ručně
• data došlá od knihoven, které již mají přidělenou váhu v tabulce, projdou automatickým testem na přidělování vah. Takto přidělená váha je automaticky porovnána s vahou v tabulce. Bude-li shodná, data se zpracují automaticky. Liší-li se váha, zpracování dat se zastaví a je upozorněn správce.

Algoritmus přidělování vah je podrobně popsán v materiálu Souborný katalog ČR. Zadání pro vývoj aplikací v systému ORACLE. 1.kapitola Příjem dat. Test na duplicitu záznamů Záznamy jsou automaticky testovány na duplicitu, je-li to nutné, probíhá testování duplicity ve dvou fázích. Algoritmus primárního i sekundárního klíče pro porovnávání záznamů je také podrobně popsán v materiálu Souborný katalog ČR. Zadání pro vývoj aplikací v systému ORACLE. 1.kapitola Příjem dat. Duplicitní záznamy s vyšší váhou nahradí záznamy s nižší váhou.

3.3. Import dat

V průběhu testování záznamů na duplicitu v aplikacích systému ORACLE nevznikají výstupní soubory add, upd a new. Každý záznam se hned po porovnání importuje do báze souborného katalogu a porovnává se s každým dalším záznamem dané dávky, dochází tudíž ke kontrole také vnitřní duplicity vstupní dávky dat. Informace o nevyhovujících záznamech jsou prostřednictvím e-mailu jako statistika s příslušným komentářem zaslány zpět příslušné knihovně k opravě.

Celý proces zpracování záznamů (trvá cca 40 minut!) má správce možnost spustit jako celek, takže jednotlivé kroky proběhnou automaticky v návaznosti na sebe, nebo po jednotlivých krocích tak, že má možnost kontroly výstupů z každého kroku. V obou variantách správce může nastavit datum a čas spuštění celého procesu nebo kroků.

3.4. Statistiky

Statistiky se vytvářejí pro uživatele i pro správce. Uživatel má možnost zobrazit si statistiku a zprávy systému vztahující se k jeho činnosti v bázi na konci své aktivity. Tyto statistiky jsou archivovány po dobu stanovenou správcem a přístupné uživateli.

Statistika pro uživatele obsahuje:

• siglu uživatele (login)
• ip adresu, ze které akce probíhala
• činnosti, které systém prováděl
• počty zpracovávaných záznamů při sdílené katalogizaci rozdělené na editované, nově uložené, stažené svoje a cizí
• dále chybová hlášení - datum a čas relace.

Statistika pro správce obsahuje (za 24 hodin):

• počet přihlášených aktivních uživatelů
• seznam jejich login (kliknutím na položku se zobrazí příslušná statistika uživatele)
• počet přihlášených pasivních uživatelů
• chybová hlášení
• počet importovaných záznamů (přidaných - add, přepsaných - upd, nových - new) včetně uvedení jejich váhy.

3.5. Problémy k řešení pro správce souborného katalogu:

• stejně jako dodavatel dat obdrží správce přesnou statistiku chyb v záznamech chybového souboru
• pokud v průběhu automatického zpracování dat dojde k chybnému zakončení procesu, zabývá se správce hledáním příčiny, proč k tomu došlo a hledá nápravu
• pokud kvalitativní váha přidělená nové dávce dat neodpovídá dříve přidělené váze, systém na to správce upozorní a ten provede hlubší analýzu dat
• systém správce upozorní, že vlastníkem dodané dávky dat je knihovna, která ještě nemá přidělenou váhu, správce provede ruční kvalitativní analýzu dat.

4. Sdílení záznamů v rámci souborného katalogu

Vývojem vlastních aplikací pro souborný katalog v systému ORACLE vytvořil správce kvalitní technické podmínky k zásadnímu zlepšení aktuálnosti souborného katalogu. V zásadě je možné se s vybranými knihovnami domluvit, aby každý den ke konci pracovní doby zaslaly na ftp server souborného katalogu záznamy toho dne zpracovaných dokumentů, které správce během noci importuje.

Účastníci souborného katalogu mají možnost stahovat vybrané záznamy (copy cataloguing) nebo využít možnosti katalogizace uvnitř souborného katalogu s následným kopírováním záznamu ve svém lokálním katalogu (shared cataloguing).

4.1. Copy cataloguing

Uživatel má možnost stahování jednotlivých záznamů nebo dávek záznamů ve zvoleném formátu a znakovém repertoáru, který zadá v menu. Při využití obsahu pole 001 u záznamů editovaných vlastníkem záznamu může uživatel vlastními prostředky docílit přepsání původního záznamu ve své bázi kvalitnějším (staženým ze souborného katalogu).

4.2. Shared cataloguing

Při tvorbě nového záznamu v souborném katalogu využije katalogizátor dané knihovny nabídnutý vstupní formulář (JAVA applet), který neobsahuje nepovolená pole. Povinná pole dle instrukcí pro souborný katalog jsou rozepsána, avšak katalogizátor má možnost další zvolená pole, která nejsou jednotlivě uvedena ve formuláři, zahrnout do verze vstupního formuláře. Tuto vlastní verzi si pojmenuje, uloží do svého prostoru a kdykoliv znovu použije.

4.3. Editace záznamu

Pro editaci je k dispozici vstupní formulář, který zobrazí kompletní obsah editovaného záznamu. Při editaci má uživatel možnost vložit do svého záznamu identifikační číslo (tag 001), a tím může vlastními prostředky docílit přepsání původního záznamu ve své bázi kvalitnějším, který upravil v souborném katalogu. Použití tagu 001 umožní plně využít tuto službu také knihovnám, které jsou nuceny provádět konverzi formátu záznamů vlastními prostředky.

Správce souborného katalogu připravil technické podmínky ke sdílení záznamů, nyní záleží na účastnících do jaké míry se tato služba stane výhodná a hojně využívaná. Závěrem je třeba zdůraznit, že vývoj vlastního systému dává správci souborného katalogu i do budoucna možnost úprav stávajících aplikací a vývoj nových aplikací v souladu s vývojem informačních technologií.