Автоматизция музейной деятельности

В программе ГИВЦа  также имеется мощная система  настройки выходных отчетов. Поэтому  не только разработчик, но и опытный  пользователь может создать свою собственную форму любого выходного  документа (акта, карточки, учетной  книги).

В АС "Музей" структура  карточки описания музейного предмета едина для всех фондов. ГИВЦ является принципиальным противником индивидуальной настройки карточки для каждого  фонда. Соображения здесь следующие. Если специалист захочет получить информацию об экспонате из соседнего фонда  или другого музея, то он не будет  знать, по каким атрибутам этот предмет  искать, так как перечень полей  описания будет разным.

Между тем настраиваемость  системы снимает проблему взаимодействия с разработчиками на расстоянии. Пользователям  АС "Музей" каждый раз приходится сообщать специалистам ГИВЦа суть требующихся  изменений, затем ждать обновления системы на дискетах или по FTP.

Вывод: настраиваемость  необходима. Это настолько полезная штука, что, если разработчики слягут на две недели с гриппом или эмигрируют в Новую Зеландию, вы даже не заметите их отсутствия. Потому что сможете  настроить вашу базу данных сами.

                     Наличие ограничений на функционирование системы.

Ограничения бывают разные. Я буду говорить не о вынужденных, объективных ограничениях, без которых  не может существовать ни одна система  вообще, а об ограничениях, загоняющих пользователя в угол.

В АС "Музей" имеются  поля, обязательные для заполнения. К ним относятся количество предметов  и два уровня классификационной  схемы описания музейного предмета: тип источников (вещественные, письменные или изобразительные) и вид предмета (живопись, предметы естественнонаучной коллекции, предметы истории техники, предметы этнографии и др.) Нетрудно видеть, что обязательные для заполнения поля являются теми самыми атрибутами, из которых формируются статистические сведения для министерской формы 8-НК. Таким образом, пунктуальное и аккуратное заполнение вышеуказанных полей  в карточке музейного предмета избавляет  сотрудников отдела учета от трудоемкого  ручного подсчета официальной статистики. Здесь ограничение, связанное с  обязательностью, является благом. В  первой версии АС "Музей" было около 70-и полей, обязательных для заполнения. Это требование попросту блокировало  возможность нормальной работы с  системой, так как далеко не все  сведения об экспонате могли быть занесены "с ходу", без научного изучения. Кроме того, существует целый  ряд учетных операций, для осуществления  которых достаточно описать базовые 5-7 полей (например, операция сверки). В  случае наличия полей, обязательных для заполнения, выполнение этих операций становится невозможным.

В КАМИС нет полей, обязательных для заполнения. Для  того, чтобы в базе данных появилась  новая карточка, в ней необходимо лишь ввести номер по книге поступлений  или инвентарный номер.

Еще одним существенным ограничением является предел на объем  базы данных, который в состоянии  обработать купленная вами музейная система. Например, АС "Музей-2" по сведениям разработчиков успешно  прошла испытания на массиве в 400 тысяч записей и теоретически может обрабатывать базу данных, содержащую сведения об 1 миллионе экспонатов.

Относительно КАМИС  известно следующее. На реальной базе данных Владимиро-Суздальского музея-заповедника  мной проверены операции с объемом  данных 105 тысяч экспонатов. В Российском Этнографическом музее (РЭМ) функционирует  комплекс "Сверка наличия музейных предметов". Он работает с базой  данных в 560 тысяч записей. Теоретически СУБД FoxPro может работать с миллионами записей. Упомянутая выше задача РЭМ  прошла успешное тестирование на массиве  в 2 миллиона записей.

Новая версия КАМИС-2000, построенная на платформе Oracle, теоретически имеет предел в сотни миллионов  записей. Такой лимит позволит обрабатывать собрания музеев-миллионеров (ГИМа и  Эрмитажа) и даже общую базу данных музейного фонда России объемом 50 миллионов записей. На практике проверен массив информации в 55 тысяч записей, который обрабатывается с помощью  КАМИС-2000 в Рыбинском музее-заповеднике, и массив в 45 тысяч записей в  отделе учета Государственного Русского музея. В качестве примечания для  коллег-специалистов добавлю, что Oracle изначально ориентирован на большие  объемы информации и работает с базой  данных от сотен гигабайт до 10 терабайт. К системе на Oracle теоретически может  быть подключено до 10 тысяч клиентов. Oracle демонстрирует очень высокое  быстродействие в многопользовательском  режиме и лучшие среди СУБД результаты по производительности.

                                                         Быстродействие.

Музейные собрания, как правило, насчитывают от тысяч  до миллионов единиц хранения. Таким  образом, электронные базы данных музеев - это значительные массивы информации. Кроме того, эти массивы имеют  достаточно сложную структуру. Поэтому  одной из важных характеристик автоматизированной музейной системы является быстродействие.

Быстродействие системы  определяется, с одной стороны, аппаратным обеспечением, то есть конфигурацией  вашего компьютера: быстродействием  процессора, объемом оперативной  памяти и др. Например, скорость обработки  запроса или формирование выходного  документа могут занимать существенно  разное время при одном и том  же объеме данных на компьютерах с  процессорами Intel 386 и Pentium 400.

С другой стороны, быстродействие в значительной степени зависит  от средства разработки, то есть программного обеспечения, на котором написана система. В новых поколениях СУБД гораздо  эффективнее и оптимальнее реализованы  алгоритмы обработки данных. Вместе с тем следует учитывать, что  даже среди последних новомодных версий программного обеспечения могут  встретиться так называемые "тупиковые  ветви". То есть кроме неоспоримых  плюсов у данного средства разработки есть серьезные ограничения, поэтому  такая программа широко по миру не распространится и долго не проживет. А вы уже купили автоматизированную систему на ее базе. Получается, что  покупка бесперспективная. Чтобы  не возникало подобных ситуаций, должны действовать два условия: компетентность разработчика программы и (для подстраховки) информированность посредника между  фирмой-поставщиком и пользователями. В роли посредника может выступать  администратор базы данных (если такой есть в музее) или внешний консультант (например, специалист из местного университета).

А что касается конкретных цифр, то быстродействие КАМИС на Oracle значительно выше быстродействия АС "Музей" на Advanced Revelation и даже на Access. Причина в том, что для Access характерен медленный поиск информации по текстовым полям, а у Oracle такой  проблемы нет.  

                                          Преодолимость нештатных ситуаций.

Прежде всего, два  слова о том, почему нештатные  ситуации возникают. Это случается  по вине:

·  разработчика (если в программе обнаружена "неотловленная" ранее ошибка);

·  пользователя (из-за его некомпетентности, неумелых действий);

·  третьих сил (например, потеря данных при перезагрузке компьютера, вызванной скачком напряжения).

Порядок выхода из внештатной ситуации в системе КАМИС следующий. Здесь предусмотрено три операции, последовательное выполнение которых  после возникновения необъяснимой нештатной ситуации и отсутствия под рукой разработчика или администратора позволяет научному сотруднику в  большинстве случаев самостоятельно снять проблему. Это операции переиндексации данных, перегенерации системы и  перекомпиляции программ.

Разработчики ГИВЦа, в свою очередь, сообщают, что за счет большого числа внедрений АС "Музей-2" количество ошибок в данной программе практически равно  нулю, и их появление вероятно только в новых, недостаточно оттестированных  модулях. Поэтому вероятность возникновения  в АС "Музей" внештатной ситуации, зависящей от разработчика, чрезвычайно  низка.

                          Развитая система помощи и наличие документации.

Неоспоримым преимуществом  АС "Музей-2" является развитая система  помощи и документация, выделенная в отдельный блок под заголовком "Инструкции". Вместе с тем, в  процессе эксплуатации АС "Музей" на экране могут возникать предупредительные  сообщения, непонятные неподготовленному  пользователю и связанные с функциями  администратора системы.

"Альт-Софтом" подготовлена  подробная документация по работе  с системами КАМИС 2.6, КАМИС  3.0 и КАМИС-2000. Она включает инструкцию  по работе с учетной задачей,  картотеками фондов, изображениями  и по администрированию системы.  Однако эта документация не  встроена в программу и поставляется  пользователю на дискете в  виде текстового файла. Что  касается специфических модулей,  разработанных по индивидуальному  заказу конкретного музея, то  для них документация отсутствует.  Есть лишь отдельные сообщения  системы, направляющие действия  пользователя при выполнении  тех или иных операций ("ждите...", "вставьте дискету в дисковод" и т.д.)

                   Лингвистическое обеспечение систем, организация словарей.

Высокий уровень  лингвистического обеспечения автоматизированной системы демонстрирует АС "Музей". Она включает тщательно проработанную  классификационную часть, присутствующую во всех фондах:

·  для предметов естественнонаучных коллекций классификация разработана с привлечением специалистов Государственного геологического музея им. В.И.Вернадского и Государственного Биологического музея им. К.А.Тимирязева;

·  для предметов истории техники классификация разработана с помощью сотрудников Политехнического музея;

·  для предметов нумизматики классификация разработана в соответствии с каталогом Мельникова;

·  для письменных источников классификация разработана в соответствии с архивной инструкцией.

Главным источником лингвистического обеспечения АС "Музей" является музейный словарь "Dictionarium Museologicum", выпущенный в 1986 году в Будапеште  при участии ИКОМ на 20 языках и  включающий 1632 статьи.

Эффективная работа музейной системы во многом зависит  от того, насколько продумано организован  в ней ввод информации о музейном предмете. Если научный сотрудник  будет описывать музейный экспонат, как акын ("Что вижу, то пою"), то вряд ли и он сам, и его коллеги  смогут получить удовлетворительный ответ  на тот или иной запрос, обращенный к программе. Задача разработчика при  построении системы сделать ее как  можно более универсальной, формализованной, добиться максимально возможной  однотипности описания тех или иных параметров в разных модулях системы. В этом отношении идеальный вариант, когда как можно больше атрибутов  описания являются справочными.

Как организуется простейший справочник? Например, при описании предмета фонда живописи мы добавляем  в перечень материалов значение "холст". Впоследствии, заводя в базу данных другие экспонаты из аналогичного материала, мы не печатаем заново "холст", а  выбираем из справочника, куда это слово  уже было занесено раз и навсегда.

Организация справочников - один из способов обеспечения чистоты  базы данных. Справочники помогают исключить дублирование значений того или иного атрибута, разночтения  в написании. Например, для пользователя не имеет принципиальной разницы, с  заглавной или со строчной буквы  он ввел фабричную технику, а для  системы это уже два отдельных  значения. Или, например, вы забыли переключить  раскладку клавиатуры и ввели  страну "Россия" первый раз - с  латинской буквы, а второй раз - с  русской. В справочнике "отловить" такие описки и повторы гораздо  проще, чем в текстовом поле. Поэтому, чем больше справочников, тем больше порядка в системе.

Однако справочник будет полезен только в том  случае, если им удобно пользоваться. Большинство  справочников, имеющихся в настоящее  время в Ас "Музей" и КАМИС, являются одноуровневыми. То есть нужный атрибут находится сразу при  входе в справочник. Наряду с этим в музейных системах встречаются  и многоуровневые справочники. Например, в АС "Музей-2" поля "Тип предмета" и "Вид предмета" имеют 9 уровней вложенности. В КАМИС-2000 поле "Место создания" может иметь до 4-х уровней описания: страна - область (губерния) - район (уезд) - город (деревня). Число уровней в КАМИС-2000 в принципе не ограничено. Разумеется, что чем больше уровней в справочнике, тем меньше вероятность того, что пользователь правильно построит цепочку переходов и дойдет до нужного ему результата на нижнем уровне. С этой точки зрения наиболее удобны для пользователя версии системы КАМИС 2.6 и КАМИС 3.0, в которых все справочники являются одноуровневыми. Вместе с тем существует теория (на основе которой, в частности, построены многоуровневые справочники Гетти), в соответствии с которой каждый уровень должен быть "коротким" (на экранную страницу), а самих уровней при этом может быть сколь угодно много. Таким образом, при организации справочников нужна разумная достаточность, определяемая в каждом конкретном случае.

Поскольку музейная система часто функционирует  не в сети, а на отдельных невзаимосвязанных  компьютерах, то возникает проблема совмещения справочников на разных машинах. В АС "Музей" эта задача решается довольно сложным, требующим большого внимания способом. Эталонные справочники  заводятся на определенной машине, которая условно считается главной. Затем вручную формируется протокол пополнения, и справочники вместе с протоколом передаются на другие компьютеры (в том числе и в  филиалы музея в разных городах). При такой организации совмещения справочников требуется регулярная актуализация. Проблема осложняется  еще и тем, что может возникнуть потребность в пополнении справочника  на второстепенной машине. Тогда для  переноса данных на главный компьютер  тоже готовится соответствующий  протокол.