Логотип персонального сайта М.Жарких
Лист на сайт
Версія для друку
Стрічка новин (RSS)
ІТехнології / Проблеми автоматизації архівної справи

Проблеми автоматизації архівної справи

М.І.Жарких

1996-й рік приніс нам прецікавий збірник із середньовічно-довгою назвою [Національна архівна інформаційна система “Архівна та рукописна україніка” і комп’ютеризація архівної справи в Україні. – К. : 1996 р., т. 1 – 308 с. Т. 1 має підзаголовок : “Інформатизація архівної справи в Україні : сучасний стан та перспективи”. Таким чином, слово “архів” зустрічається в назві 4 рази, слово “Україна” – 3 рази, слова “інформація” та “справа” – тільки по 2 рази] і не менш довгим списком установ, причетних до його народження [Інститут української археографії та джерелознавства ім. М.С.Грушевського НАН України; Інститут рукописів Центральної наукової бібліотеки ім. В.І.Вернадського НАН України; Головне архівне управління при Кабінеті міністрів України; Український державний науково-дослідний інститут архівної справи та документознавства]. Ми розглянемо ті статті, які мають безпосереднє відношення до автоматизації та застосування баз даних в архівній справі.

З погляду теорії найвизначніша стаття в збірнику належить С.М.Гриші та О.В.Соханю : “Програмно-технологічні аспекти розбудови Національної архівної інформаційної системи : асоціативний підхід”. Автори розглядають можливості табличних та повнотекстових баз даних і доходять висновку, що для задоволення специфічних інформаційних потреб НАІС вони малопридатні :

“Якщо розглядати архівну інформацію, то її особливість полягає у тому, що вона фактично не містить фрагментів, які б не були некритичними для пошуку” (с. 77).

Для задоволення такої специфічної потреби автори пропонують новий підхід, який вони називають асоціативним. Він полягає в тому, що кожне слово чи часто вживане словосполучення вноситься у спеціальний словник (довідник значень), де отримують числові коди; текстові поля бази даних під час збереження записів аналізуються і знайдені фрагменти заміняються відповідними кодами. Результати кодування зберігаються у спеціальній таблиці (асоціаторі), яка має такі основні поля : номер документу; номер поля в формулярі документу (в термінах авторів – “рубрика”); номер значення з довідника значень; номер позиції значення всередині рубрики.

Таким чином, якщо нам треба внести в базу даних опис документу № 1 під назвою “Книга Житомирська гродська записова і поточна 1582 – 1588 рр.”, то ми маємо спочатку утворити рубрику № 1 “Назва документу” і внести в довідник значень слова “гродська” (№ 1), “Житомирська” (№ 2), “записова” (№ 3), “і” (№ 4), “Книга” (№ 5), “поточна” (№ 6). Після цього асоціатор набуває вигляду :

№ документу № рубрики № значення № всередині рубрики
1 1 5 (Книга) 1
1 1 2 (Житомирська) 2
1 1 1 (гродська) 3
1 1 3 (записова) 4
1 1 4 (і) 5
1 1 6 (поточна) 6

Економія досягається за рахунок того, що слово, наприклад, “книга”, один раз внесене в довідник значень, буде використовуватись дуже багато разів.

Під час видобування інформації з бази даних та її представлення для читання відбувається зворотній процес заміни числових кодів значень їх текстовими відповідниками з довідника значень. Ця дотепна система нагадує китайський телеграф (для китайської ієрогліфічної писемності непридатні ані код Морзе, ані шестибітовий код Бодо; китайці занумерували всі потрібні ієрогліфи числами і по телеграфу передають відповідні числа одним з телеграфних кодів, а на місці прийому розкодовують числа в ієрогліфи). Автори переконливо доводять, що така система зберігання текстів забезпечує значну економію в розмірах файлів.

Важливим позитивним моментом запропонованої структури зберігання є можливість поповнювати формуляр опису документів новими пунктами (рубриками), причому це поповнення не вимагає ніякого перетворення даних, які вже введені в базу. Це робить систему гнучкою і здатною задовольняти інформаційні потреби, які ще не сформульовані на час її проектування.

Звичайно, для практичної реалізації її переваг потрібно розробити відповідні програмні засоби, а не імітувати цю систему за допомогою табличних СУБД. До того ж, якщо такий програмний комплекс буде розроблятись, доцільно зробити його якомога абстрактнішим (не орієнтованим спеціально на архівне застосування), оскільки він може знайти застосування і за межами тієї предметної області, в якій він виник.

Стаття О.В.Соханя “Гіпертекстові та гіпермедіальні технології : перспективність їх використання в архівних інформаційних системах” присвячена обговоренню можливостей об’єктних архітектур баз даних. В термінології автора гіпертекст – це текст, окремі фрагменти якого мають посилання на інші тексти, а мультігіпертекст – мережа, вершинами якої є інформаційні об’єкти довільної внутрішньої структури (не тільки тексти), а дугами – зв’язки між об’єктами. На жаль, не досить чітко пояснено, чи зв’язки між об’єктами є статичними (тобто фактично – атрибутами самих об’єктів), чи динамічними (такими, що утворюються під час сеансу роботи за певними алгоритмами). Скоріше йдеться про другий варіант, але нема навіть натяку на суть алгоритмів побудови динамічних зв’язків. Перевага зберігання інформації у вигляді об’єктів, на думку автора, полягає в тому, що навігація по системі зв’язків між об’єктами є природним засобом мислення.

Наприклад, від об’єкту “Петро Могила” (класу “Особа”) ми можемо перейти до “факту поховання П.Могили в соборі Києво-Печерської лаври” (класу “Біографічний факт”), від нього – до “Києво-Печерської лаври” (класу “Пам’ятка”), далі – до “книги Ф.І.Титова про Києво-Печерську лавру” (класу “Бібліографічне джерело”), і т.д.; а можемо від “Петра Могили” вирушити в іншому напрямку – до об’єкту “Київський митрополит” (класу “Посада”), далі одержати список всіх осіб, що були київськими митрополитами, вибрати з нього “Йова Борецького”, отримати біографічну довідку про нього, і т.д.

Звичайно, таку навігацію не можна й не потрібно формалізовувати, але при великій кількості однорідних об’єктів ручна навігація – не найкращий спосіб відбору потрібної інформації. Досконалою була б система, яка об’єднувала б переваги гіпертекстової чи об’єктної навігації з відбором за формальними критеріями. Автор обмежується аналізом теоретичних аспектів проблеми, не намічаючи шляхів її реалізації.

Стаття І.П.Антоненко “Авторитетний контроль найменувань установ та організацій в інформаційних системах археографічного типу та можливості його використання в НАІС” примітна перш за все невдалою транскрипцією англійського терміну “authority control”. Англійське “control” – це “управління, керування”, але ніяк не наш “контроль” (checking, testing); що таке “authority” – я не знаю, і що таке “авторитетний” вкупі з “контролем” – незрозуміло. А суть справи проста : для того, щоб позбутися різночитань в найменуванні установ, треба створити окремий словник цих найменувань і під час заповнення полів, які містять назви установ, вибирати для них значення тільки зі словника. Записи в цьому словнику можуть містити довідки про установи (це взагалі найвідповідніше місце для такої інформації) та перехресні посилання (наприклад, від альтернативних написань назви до основного на-писання). До статті додано досить детально розроблений проект таблиці бази даних, на якій має базуватись словник.

Поважна частина збірника віддана інформаційним повідомленням про досягнення архівів в галузі створення та використання баз даних.

Таблиця 1. Досвід створення баз даних в архівних установах.

Установа Програміст Програмний засіб Призначення продукту Число записів
Головархів України Інститут програмних систем НАНУ CDS/ISIS Фондовий каталог ?
Центральний державний архів громадських об’єднань України ? ? Персональні справи репресованих ?
Державний архів-музей літератури і мистецтва України власний CDS/ISIS Фондовий каталог 8 500
Державний архів Харківської області мале підприємство Clipper Персональні справи про перебування громадян у Німеччині (Ostarbeiters) 92 000
Державний архів Київської області Інститут програмних систем НАНУ CDS/ISIS Персональні справи про перебування громадян у Німеччині (Ostarbeiters) 42 000
Інститут української археографії НАНУ власний File Maker Pro (Macintosh) Джерела з історії Української повстанської армії ?
Центральна наукова бібліотека НАНУ власний CDS/ISIS Книжкова спадщина України 600

З наведеної порівняльної таблиці можна зробити декілька висновків :

– на даному етапі переважають бази даних, які є комп’ютерними аналогами картотек або формулярних документів; тільки два останніх проекти спрямовані на інтеграцію інформації з різних джерел, тобто не орієнтовані на якийсь один конкретний тип документів;

– абсолютною перевагою користується апаратна платформа IBM / MS DOS та програмний комплекс CDS/ISIS; нема баз даних, які б використовували середовище Windows. Причина переваг CDS – в можливості отримати безкоштовну легальну копію продукта та наявності української (як також і російської) версії. Над цими обставинами слід замислитись різним “провайдерам” та “дистриб’юторам” [не кажучи вже про “ділерів” та “сейлерів”] іноземних програмних пакетів – чи правильно вони роблять, намагаючись продати свої продукти за європейськими цінами ?

– для реалізації баз даних значним організаційним ускладненням є пошук програміста. Тут різні установи йдуть різними шляхами;

Особливо треба зупинитись на двох однотипних проектах, реалізованих в Харківському та Київському обласних архівах. Робота по видачі довідок колишнім остарбайтерам (у зв’язку з можливістю отримати компенсацію) вимагає значної кількості одноманітних операцій, і її автоматизація виглядає цілком природно. Важливою мені здається є мотивація запровадження автоматизації : виявилось, що дешевше купити комп’ютер і створити базу даних, ніж прогортати масу паперів вручну. В часи СРСР все було навпаки : дешевше було найняти сто працівників, які коштували дуже дешево, ніж завести комп’ютер, який коштував дуже дорого. Збільшення ціни робочої сили наближає нас до країн, які звуться “цивілізованими”. Але разом з цим викликає подив, що така стандартна база даних створюється незалежно в кількох місцях відносно невеликої України, замість того, щоб поширюватись з єдиного центру. Це свідчить про відсутність в Україні осередку, який узяв би на себе координацію робіт на царині автоматизації в організаційному, методичному та програмно-технічному аспектах. Архівне начальство виявилось неготовим до здійснення таких функцій, надавши обласним архівам сумнівний привілей – самотужки плисти комп’ютерним морем. Хочеться вірити, що створення в системі архівного управління Науково-дослідного інституту архівної справи та документознавства змінить цю ситуацію на краще.

Останній з матеріалів збірника, на якому я хотів би зупинитись – це технічне завдання на розробку “Національної архівної інформаційної системи”. Це дуже серйозна робота, яка справляє враження всебічно продуманої та узгодженої; вона може слугувати як зразок для розробки технічних завдань для аналогічних загальнодержавних проектів. Автори щасливо уникли характерної для жанру технічного завдання помилки – нав’язування розробникам системи свого бачення майбутньої реалізації, або включення до завдання вказівок по проектуванню системи.

Основна функція НАІС – це “оптимізація процесів наукового використання архівних та рукописних документів” (с. 197) та “оперативний облік та підготовка даних для управління архівною справою” (с. 198), тобто планується в одній системі об’єднати функції адміністрування фондами і науково-довідкового апарату.

Разом з тим в технічному завданні закладено деякі рішення, які навіть апріорно можна вважати джерелами утруднень. Перш за все, передбачено централізоване управління всім комп’ютерним комплексом з головної архівної станції, яка координує роботу регіональних архівних станцій (зокрема, в обласних архівах). Це означає, що головна станція не зможе працювати на повну потужність, поки нема розвиненої мережі регіональних станцій; а регіональна станція, в свою чергу, не зможе виконувати всіх своїх функцій, поки не запрацювала головна станція. Тобто архітектура мережі, на мій погляд, не є достатньо модульною. А при тому, що фінансування проекту ще довгий час буде недостатнім і розбудова всього комплексу може розтягнутись на довгий строк, було б важливо запустити автономні модулі системи, які реально можна змонтувати. Другий слабкий момент цього рішення – необхідність підтримання телекомунікаційного зв’язку між архівними станціями. Йому присвячено досить багато місця в завданні, але технічний рівень нашого телефонного зв’язку є джерелом головного болю для всіх користувачів модемів. Можна сподіватись хіба на те, що на час досягнення системою повної потужності якість зв’язку встигне поліпшитись.

Є в документі й деякі дрібні недоліки [в силу приповідки про несповите дитя, няньками якого є : С.М.Гриша, А.А.Галяпа, О.В.Сохань, М.В.Пийтер, С.М.Кіржаєв, К.Є.Новохатський, Т.М.Захарченко – рівно сім, як і має бути] :

– перші два розділи – “Призначення системи” та “Мета створення системи” – дублюють один одного. Будь-яка система призначена для досягнення своєї мети;

– до числа функцій адміністратора архівної станції включено боротьбу з комп’ютерними вірусами та можливість давати адресні оголошення (с. 204); друга функція підтримується всіма програмами адміністрування локальними мережами – навіщо її дублювати в базі даних ? Боротьба з вірусами, з точки зору функціонування бази даних – це загальносистемне завдання, частина підтримки працездатності операційної системи. За неї мусить відповідати адміністратор комп’ютерної мережі – особа з окремими функціями, про яку нема згадки у завданні й тому не розмежовано повноваження адміністратора мережі й адміністратора бази даних;

– опис відкладено-діалогового та відкладено-пакетного режимів доступу (с. 204) нічим не розрізняється (певно, через технічну помилку підготовки тексту);

– передбачається, що “час реакції на елементарні операції (запис окремого реквізиту, вибір з меню) не повинен перевищувати 3 сек.” (с. 206). Три секунди для розгортання меню чи панелі діалогу – це страшенно довго ! В той же час 3 секунд може бути мало для ряду важливих операцій, і авторам доведеться оголосити їх “не елементарними”. В той же час в таблиці (с. 211 – 213) для ряду функцій передбачено час реакції не більше 5 сек. (про 3 сек. вже не йдеться);

– “Згідно з ДЕСТ 27002-86 надійність системи оцінюється показником імовірності виконання функцій системи за оперативний час, який вказано в таблиці” (с. 206). Не знаю, що там пише стандарт, але називати таку характеристику “надійністю” не випадає. Надійність характеризується часом безвідмовної роботи системи або імовірністю випадкового збою; час виконання функцій не має до цього ніякого стосунку;

– невдало сказано, що “система повинна надавати можливість у виняткових випадках виконувати пошук і серед знищеної інформації” (с. 208). Вимога забезпечувати пошук серед знищеної інформації викличе зубовний скрегіт у будь-якого програміста. На мій погляд, було б доцільніше явно запровадити категорію “сміттєзвалища” : записи, які підлягають знищенню, спочатку відправляються на це звалище, а пізніше, коли остаточно з’ясується, що вони не потрібні, знищуються.

Але ці зауваження не знижують загального позитивного враження від завдання.

На завершення хочу відзначити, що збірник виконано на дуже високому поліграфічному рівні. Його підготовано на комп’ютерному обладнанні, наданому Інституту рукописів Фондом катедр українознавства. Треба відзначити, що Фонд не помилився : його обладнання потрапило в умілі руки, і хочеться вірити, що ми невдовзі побачимо наступний випуск цього корисного збірника.

Джерело : Археометрія та охорона історико-культурної спадщини, 1997 р., вип. 1, с. 126 – 129.

Попередня стаття | Перелік статей | Наступна стаття

Сподобалась сторінка? Допоможіть розвитку нашого сайту!

© 1978 – 2017 М.І.Жарких

Передрук статей із сайту заохочується за умови
посилання (гіперпосилання) на мій сайт

Сайт живе на

Число завантажень : 4083

Модифіковано : 5.08.2017

Якщо ви помітили помилку набору
на цiй сторiнцi, видiлiть її мишкою
та натисніть Ctrl+Enter.