ИПМ им. М.В.Келдыша РАН • Электронная библиотека Препринт № 2 за 2011 г.
			М.М.Горбунов-Посадов, А.В.Ермаков, Э.С.Луховицкая, Р.Ю.Скорнякова О выборе автоматизированной информационной библиотечной системы для библиотеки ИПМ
	Рекомендуемая форма ссылки: Горбунов-Посадов М.М., Ермаков А.В., Луховицкая Э.С., Скорнякова Р.Ю. О выборе автоматизированной информационной библиотечной системы для библиотеки ИПМ // Препринты ИПМ им.М.В.Келдыша. 2011. № 2. 32 с. URL: http://library.keldysh.ru/preprint.asp?id=2011-2

Ордена Ленина

Институт прикладной математики

имени М.В.Келдыша

Российской академии наук

М.М.Горбунов-Посадов, А.В.Ермаков,
Э.С.Луховицкая, Р.Ю.Скорнякова

О выборе автоматизированной информационной библиотечной системы для библиотеки ИПМ


Москва — 2011

Горбунов-Посадов М.М., Ермаков А.В., Луховицкая Э.С., Скорнякова Р.Ю.

О выборе автоматизированной информационной библиотечной системы для библиотеки ИПМ

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

Ключевые слова: информационная библиотечная система, АБИС, АИБС

Mikhail Mikhailovich Gorbunov-Possadov, Aleksey Viktorovich Ermakov, Engelina Solomonovna Lukhovitskaya, Rimma Yur’evna Skornyakova

About the Choice of Automated Library Information System for the KIAM Library

Reasons for the choice of Automated Library Information System for the KIAM Library are given. Technologies and data storage principles used in ALIS’es presented in Russian market are analyzed. The choice takes in account the forthcoming changes in bibliographic standards.

Key words: library information system, LIS, MARC

Оглавление

Введение

Важную роль как в научно-исследовательской работе, так и в преподавательской деятельности сотрудников ИПМ играла и играет научно-техническая библиотека. Ее каталог насчитывает более 100 000 наименований отечественной и зарубежной литературы.

Социально-экономические проблемы последнего двадцатилетия и произошедшая интернет-революция бросают нашей библиотеке целый ряд вызовов, на которые предстоит найти адекватный ответ.

Прежде всего, это доступность как библиотечного каталога, так и самого библиотечного фонда. Если раньше для сотрудников ИПМ при поиске нужной публикации выбор был ограничен поиском в институтской библиотеке и поиском в других библиотеках (БЕН, ГПНТБ и т.д.), то с развитием информационных технологий научные сотрудники все чаще при поиске необходимой информации направляют свои усилия в сферу интернета. Обращение к «бумажному» фонду обычно происходит лишь в случае неудачного поиска в сети (или в силу привычки). Такое бывает, особенно в фундаментальных областях. Но поиск в бумажном каталоге на фоне поиска при помощи электронных средств выглядит просто «каменным веком».

Кстати, существующий стереотип, утверждающий, что читателю не нужно ничего, кроме электронного каталога, не совсем верен. Современные информационные технологии предоставляют массу полезных средств для оперативного информирования читателей и о новых поступлениях, и о заказах по межбиблиотечному абонементу, и о работе библиотеки в целом (например, по организации электронной подписки). Более того, для каждого читателя может быть сформирован индивидуальный профиль его научных предпочтений, по которому он сможет получать актуальную информацию любым современным и удобным ему способом.

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

Это направление было поддержано в Институте более десяти лет назад в рамках проекта «Электронная библиотека ИПМ». В соответствии с приказом директора Института электронные версии всех препринтов размещаются на сайте Института в свободном доступе (http://library.keldysh.ru/preprints/).

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

1. Постановка задачи

В июне 2010 года перед нами была поставлена задача автоматизации деятельности библиотеки ИПМ. Автоматизация библиотеки может идти в двух направлениях:

1) организация информационной поддержки традиционных видов деятельности библиотеки: комплектования библиотечных фондов, ведения каталога, поиска книг через каталог и выдачи их читателям;

2) создание полнотекстовой электронной библиотеки путем сканирования имеющего библиотечного фонда и предоставления доступа к этому фонду через Интернет.

Первую задачу решают так называемые Автоматизированные Библиотечные Информационные Системы (АБИС), или (с другим порядком слов) Автоматизированные Информационные Библиотечные Системы (АИБС). Требования, предъявляемые к таким системам, изложены в работах [1], [2]. В частности, функциональная структура системы для обеспечения работы современной библиотеки должна включать:

• комплектование своих фондов;

• предметизацию и систематизацию фондов;

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

• организацию хранения фондов;

• обслуживание читателей;

• межбиблиотечный абонемент.

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

Не имея опыта разработки библиотечных систем, мы решили, что лучше купить готовую библиотечную систему. Рассуждали так. Если задача простая, то должны быть хорошие готовые решения. Если задача сложная и хороших решений нет, то опыт эксплуатации чужой системы будет полезен для создания в будущем собственных разработок.

При выборе системы мы стремились учитывать не только предоставляемый ею набор функциональных возможностей, но и используемые технологии, программное обеспечение, а также имеющуюся информацию о ее реализации. Хотелось, чтобы система была достаточно современной по используемым технологиям и программному обеспечению, чтобы работа ее была надежна и чтобы ее можно было легко расширять и модифицировать.

То, что качество реализации некоторых систем оставляет желать лучшего, можно было заключить из некоторых публикаций и отзывов в интернете, в частности из публикации [3] заведующего отделом автоматизации НТБ МАДИ. В ней был описан опыт эксплуатации системы «Библиотечная компьютерная сеть 5.3», разработанной в научной библиотеке МГУ, и были даны нелестные характеристики этой системе. И хотя эта система относится к предыдущему поколению библиотечных систем и использует морально устаревший DBF-формат для хранения данных, далеко не все недостатки системы, описанные в публикации [3], можно объяснить этими причинами. Очевидно, что имелись явные программистские недоработки, и самое главное из написанного, что произвело впечатление, — это то, что разработчики не пожелали выполнять обязательства по поддержке и обслуживанию программы: больше года их просили исправить ошибку, но они так этого и не сделали. Нам не хотелось бы оказаться в такой ситуации.

Разумеется, не имея исходного кода, невозможно составить полное заключение о качестве разработки. Однако для многих систем оказалось возможным получить информацию о принципах хранения и структуре данных. Некоторые разработчики предоставляли на своих сайтах демонстрационные версии, другие — документацию о структуре базы данных или ссылки на публикации, в которых описывались принципы хранения данных. База данных составляет основу системы. Клиентскую часть приложения можно изменять, не меняя структуры данных, а изменять структуру данных, не делая изменений в клиентской части, можно только при очень грамотно спроектированной работе с БД, например, если обращение к данным из клиентской части происходит только опосредованно через представления, хранимые процедуры и функции. Поэтому по качеству проектирования БД можно в значительной степени судить о качестве системы в целом, надежности ее работы, а также о возможности ее доработки и модификации.

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

2. Действующие стандарты каталогизации
и соответствующие им структуры
библиографических данных

Первые машинные библиотечные каталоги появились в середине прошлого века и хранились на ленточных носителях. В 1960 г. в библиотеке Конгресса США началась разработка первого стандарта для хранения и обмена библиографическими данными, и в 1965-66 гг. такой стандарт, основанный на правилах каталогизации, разработанных Американской ассоциацией библиотек, был создан. Он получил название MARC (MAchine-Readable Cataloging) [4], [5].

В процессе развития и использования формата в 1970-х годах появились более 20 его различных версий, ориентированных на национальные правила каталогизации (в том числе UKMARC, USMARC, AUSMARC, CANMARC, DanMARC, NorMARC, SwaMARC и др.). Для преодоления несовместимости этих форматов в 1977 г. Международной федерацией библиотечных ассоциаций IFLA был выпущен «Универсальный формат MARC» (Universal MARC Format, UNIMARC). Основой для стандарта UNIMARC послужили требования Международного стандарта библиографических описаний (International Standard Bibliographic Description, ISBD). Предполагалось, что этот формат должен стать посредником между любыми национальными версиями форматов MARC и, следовательно, обеспечивать конвертирование данных из национального формата в него, а из него — в другой национальный формат. В 1999 г. в результате согласования и последующего слияния библиографических форматов США и Канады (USMARC и CANMARC) было объявлено об образовании на их основе нового формата («Формата XXI века») — MARC21.

Таким образом, сейчас существует целое семейство форматов MARC и среди них два конкурирующих между собой ответвления UNIMARC и MARC21. UNIMARC поддерживается международной организацией IFLA и используется в основном в Европе и Азии. MARC21 поддерживается библиотекой Конгресса США и используется в основном в США и Канаде.

Одним из принципиальных отличий этих форматов является наличие в UNIMARC и отсутствие в MARC21 возможности делать ссылки из одной библиографической записи на другую и таким образом связывать между собой разноуровневые издания: том многотомника с самим многотомником, выпуск журнала с самим журналом, журнальную статью с выпуском журнала, в котором она опубликована. В MARC21 вся иерархия должна быть представлена в одной библиографической записи.

В 1998 году появился и российский вариант UNIMARC — RUSMARC [6], основанный на российских правилах каталогизации.

Если вначале MARC-форматы служили стандартами и для хранения библиографических записей, и для обмена ими, то в настоящий момент они являются только коммуникативными стандартами — стандартами файлового обмена библиографической информацией. Внутри АИБС данные могут храниться в любом виде, удобном разработчикам системы. Тем не менее, для того чтобы система могла обмениваться данными с другими системами, в ней должна быть предусмотрена возможность преобразования данных из внутренней структуры в MARC-формат и обратно. Поэтому АИБС, претендующая на универсальность, должна иметь структуру данных, логически эквивалентную MARC-формату.

За почти полвека существования и развития MARC-форматы претерпели ряд изменений, но основа, заложенная в 60-х годах прошлого века, когда еще не было ни реляционных баз данных, ни объектно-ориентированного программирования, не изменилась. Логическая структура стандарта описывается в терминах, обозначаемых числами полей, которые могут быть отмечены как периодические, и подполей, имеющих буквенно-цифровые обозначения, тоже единичных или периодических. Некоторые подполя отмечаются как «точки доступа». Они являются поисковыми атрибутами. Всего подполей насчитывается более тысячи, а множественных — несколько сотен.

Группа исследователей Университета северного Техаса под руководством Вильяма Моэна (William Moen) в 2005-2007 гг. проанализировала 56 миллиардов записей в формате MARC21, содержащихся во всемирном каталоге OCLC (Online Computer Library Center) [7], [8]. Оказалось, что 211 полей и 1596 подполей были использованы, по крайней мере, один раз, 7 полей встречались во всех записях, 14 полей встречались более чем в 80% случаев, 66% встречались менее чем в 1% случаев, поле под номером 656 встретилось ровно один раз. Нам неизвестно, проводились ли аналогичные исследования относительно записей в каком-либо из форматов семейства UNIMARC, однако можно предположить, что картина должна быть похожей: почти все поля и подполя используются, хотя значительная часть из них встречается редко.

Таким образом, формальное следование стандарту предполагает использование более тысячи атрибутов, среди которых сотни множественных. Из-за этого разложение структуры библиографического описания на реляционные составляющие должно насчитывать сотни таблиц, что делает использование реляционной модели неэффективным. Запрос на получение одного библиографического описания должен включать сотни операторов LEFT JOIN, а обработка одного библиографического описания (вставка или редактирование) должна осуществляться сотнями SQL-предложений. Тем самым теряется главное преимущество реляционной модели: легко формулируемые и быстро выполняемые запросы.

В конце 60-x годов прошлого столетия была разработана специализированная база данных CDS/ISIS (Computerised Documentation Service / Integrated Set of Information Systems) [9], которая с 1985 года развивается и поддерживается ЮНЕСКО. Основное назначение этой базы данных — ведение каталогов библиотек и музеев. База данных предназначена для хранения и поиска текстовых данных переменной длины. Структура этой базы данных, так же как и структура MARC-формата, описывается в терминах нумеруемых полей и подполей с буквенно-цифровыми обозначениями. Разнообразные методы индексирования, включая создание индексов по ключевым словам, дают возможности для различных вариантов текстового поиска. В настоящее время существует версия этой базы и для Windows — WINISIS. В работе [10] приводятся аргументы в пользу использования этой специализированной СУБД и указываются ее преимущества по сравнению с реляционными СУБД. Работа была написана в 2001г., и в связи с появлением дополнительных возможностей в реляционных СУБД и снятием в них некоторых ограничений часть из этих аргументов отпала. Главным аргументом, на наш взгляд, остается то, что база данных распространяется бесплатно. Но это имеет и оборотную сторону. Поскольку финансовые возможности ЮНЕСКО гораздо слабее возможностей фирм, разрабатывающих коммерческие СУБД, пакеты для создания прикладного программного обеспечения для баз данных из семейства ISIS содержат существенно меньше возможностей, чем пакеты для создания прикладного программного обеспечения для коммерческих СУБД. В настоящее время семейство баз данных ISIS предназначается главным образом для развивающихся стран.

Еще одна возможность для хранения библиографических данных — это использование коммерческих нереляционных СУБД, например, довольно мощной СУБД ADABAS [11], существующей с 1969 года, поддерживаемой и развиваемой немецкой фирмой Software AG. Эта СУБД реализует модель данных NF2 — не первая нормальная форма. Запись в такой модели может содержать множественные поля и периодические группы, что близко к логической структуре MARC-формата. На сегодняшний день, пожалуй, выбор такой СУБД для хранения библиографических данных является оптимальным. Однако тенденции в мире баз данных таковы, что реляционные СУБД, такие как ORACLE, DB2 и Microsoft SQL Server, расширив возможности реляционной модели добавлением поддержки XML-структур, полнотекстового поиска и т.п., постепенно вытесняют с рынка базы данных, основанные на других моделях, и будущее таких баз данных, как ADABAS, находится под вопросом.

Таким образом, на сегодняшний день для MARC-совместимой библиотечной системы имеется три возможности:

1) использовать современную коммерческую реляционную базу данных, но не вполне по назначению — без реляционной модели;

2) использовать довольно слабую по программистским возможностям специализированную СУБД из семейства ISIS;

3) использовать морально устаревшую коммерческую нереляционную СУБД.

Поэтому задача, которую мы поставили перед собой вначале, — найти универсальную АИБС, одновременно и хорошо спроектированную, и использующую современные технологии и ПО — оказалась нереализуемой.

3. Новые правила каталогизации, допускающие реляционную модель данных

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

В 1990 г. в Стокгольме состоялся семинар по библиографическим записям, организованный IFLA, на котором было принято решение провести исследование для определения функциональных требований к библиографическим записям. Целью исследования было создание основы, которая обеспечила бы ясное, четко сформулированное и общепринятое понимание того, какие сведения должна содержать библиографическая запись с точки зрения удовлетворения потребностей пользователя. В 1992 г. была создана рабочая группа для проведения этой работы. В 1995 г. группа выпустила проект отчета, который был выставлен во всемирной сети для обсуждения. В сентябре 1997 г. появился окончательный вариант отчета, в котором были учтены полученные в результате этого обсуждения замечания и предложения, и который получил название Functional Requirements for Bibliographic Records, или, сокращенно, FRBR [12]. FRBR-модель представляет собой концептуальную референсную модель, составляющую основу для дальнейшей детализации и построения модели данных.

Требования FRBR-модели сформулированы в терминах сущность-связь, хотя к моменту их создания объектная парадигма уже получила широкое распространение, а в январе 1997 г. вышла спецификация UML 1.0 языка объектного моделирования Unified Modeling Language [13]. На наш взгляд, модель была бы четче и лучше воспринималась, если бы была сформулирована в терминах объектов/классов, и в ней присутствовала иерархия классов.

Сущности модели поделены на три группы. В первую группу входят сущности, которые отражают результат интеллектуального труда или художественного творчества: work (произведение), expression (выражение), manifestation (воплощение) и item (физическая единица). Вторую группу составляют сущности, соответствующие ответственным за этот результат: person (физическое лицо) и corporate body (организация). В последующих версиях FRBR-модели во вторую группу была добавлена еще одна сущность family (род). Третью группу составляют сущности, отражающие содержание интеллектуального труда или результата художественного творчества: concept (идея, концепция), object (предмет), event (событие) и place (место). На рис. 1–3 отражены связи этих сущностей между собой. Двойная стрелка означает «множественность» данной стороны связи. Рекурсия на рис. 1 означает, что произведение может состоять из других произведений.

В описании FRBR-модели [12] приведены также атрибуты сущностей на логическом уровне. Не все они являются элементарными. Значительная часть их представляет собой совокупность более простых элементов. Например, заголовок воплощения может включать основной заголовок (включая номер/заглавие части), параллельное заглавие, примечания о вариантных и транслитерированных заглавиях и ключевое заглавие.

Указанные сущности и связи между ними, а также приводимые в модели атрибуты сущностей должны обеспечивать следующие основные задачи пользователя: найти (find), идентифицировать (identify), выбрать (select) и получить (obtain) некоторую сущность из модели. При этом предполагаются разные виды пользователей: читатели, студенты, исследователи, библиотечный персонал, издатели, продавцы, рекламщики, ответственные за соблюдение интеллектуальных прав собственности и т.п.

В 2002 г. было принято решение заменить вторую редакцию англо-американских правил каталогизации, существующую с 1978 г., новыми правилами каталогизации RDA (Resource Description and Access, Описание ресурса и доступ к нему), основанными на FRBR-модели. Новый стандарт в первую очередь предназначен для электронных каталогов. Разработка велась Объединенным комитетом (Joint Steering Committee), организованным Американской ассоциацией библиотек, Австралийским комитетом по каталогизации, Британской библиотекой, Британским институтом специалистов в области библиотек и информации, библиотекой Конгресса США. В июне 2010 г. был опубликован окончательный вариант этих правил [14]. Правила RDA детализируют атрибуты, представленные в FRBR-модели, и уже могут рассматриваться как модель данных, хотя детализация атрибутов некоторых сущностей отложена до появления следующих редакций правил. Поскольку правила основаны на FRBR-модели, разработанной IFLA, они претендуют также на роль международного стандарта.

Рис.1. Группа 1 и первичные связи.

Рис. 2. Группа 2 и связи "ответственности".



Рис. 3. Группа 3 и связи "тема/содержание".

Работы по адаптации этих правил в России ведутся, в частности, в национальном информационно-библиотечном центре «ЛИБНЕТ». По мнению генерального директора центра Б.Р.Логинова [15], правила RDA будут внедрены в России лет через пять-шесть. И хотя профессиональные каталогизаторы воспринимают новые правила довольно критически и не стремятся их внедрять (например, главный библиотекарь Российской государственной библиотеки Бахтурина Т.А. существенными недостатками правил RDA считает то, что они не годятся для карточных каталогов, до сих пор ведущихся во многих библиотеках нашей страны, и то, что терминология FRBR-модели слишком абстрактна и плохо воспринимается как библиотекарями, так и читателями [16]), надо полагать, что с продвижением компьютеризации библиотек постепенно будут внедряться и новые правила.

Один из разработчиков правил RDA Том Делси (Tom Delsey) предложил несколько сценариев реализации этих правил в базах данных [17]. Один из сценариев, в частности, предполагает использование реляционной модели. Данные хранятся в структуре, отражающей концептуальную модель FRBR. В ней имеются таблицы, соответствующие основным сущностям модели: WORK (произведение), EXPRESSION (выражение), MANIFESTATION (воплощение), ITEM (физическая единица), PERSON (физическое лицо) и др.


MANIFESTATION RECORD

Рис. 4. Реализация RDA в реляционной модели.

Рис. 4 из [17] содержит набросок структуры базы данных для этого сценария. Первичные связи FRBR-модели представлены на рисунке двойными линиями со стрелками на концах, а остальные связи — одинарными. Атрибуты, по которым предполагается поиск, отмечены знаком «*». На рисунке присутствуют лишь наиболее значимые атрибуты сущностей. Например, для произведения (work) — это основное заглавие, автор/ы, форма произведения. По основному заглавию предполагается поиск. Авторы определяются через связи с таблицей PERSON.

На рисунке не отражены все элементы, приведенные в правилах RDA. И хотя, на наш взгляд, при довольно большом числе элементов RDA (на настоящий момент их насчитывается несколько сотен) и, возможно, довольно большом числе среди них множественных, может возникнуть та же проблема, что и с MARC-форматом — большое число реляционных составляющих, эту проблему можно решить, сочетая реляционную модель с XML-типом данных, который к настоящему моменту реализован во многих коммерческих реляционных СУБД. Те множественные элементы, которые не используются при поиске и не являются обязательными, можно включать в XML-структуры.

Таким образом, хотя при существующих на данный момент в России правилах каталогизации и коммуникативных стандартах библиографическое описание не может быть эффективно реализовано в реляционной модели и разработчики, использующие реляционные СУБД, используют эти СУБД не по назначению, в дальнейшем, с введением правил каталогизации RDA, использование реляционных СУБД будет вполне оправданным.

4. Российские АИБС и их реализации.
Выбор системы для покупки

На российском рынке готовых компьютерных систем имеется более десятка АИБС. Таблица 1 содержит список АИБС, информацию о которых удалось найти в интернете. При этом, если у одного и того же разработчика имелось несколько библиотечных систем, мы включали в список только последнюю его разработку.

Сами АИБС, как правило, представляют собой АРМ (Автоматизированное Рабочее Место) библиотекаря. Дополнительно к АИБС может быть поставлен так называемый OPAC (Online Public Access Catalog) – модуль, предоставляющий доступ читателю к электронному каталогу библиотеки через интернет, который реализуется как отдельная система. Исключение составляет система OPAC-Global(Midi, Mini), в которой соединены и АРМ библиотекаря, и читательский интерфейс доступа к каталогу.

Таблица 1. АИБС и их разработчики.

	Название	Разработчик	Сайт в интернете
1	Абсотек Юникод	«R.I.I. Diffusion» (Франция), ЗАО «Компания ЛИБЭР» (Россия)	http://www.libermedia.ru/
2	АзЪ	«Инфокомм» (Санкт-Петербург)	http://www.infocomm.ru/
3	Академия+	«Ростехноком» (Санкт-Петербург)	http://www.rostechnocom.ru/
4	АС Библиотека-3	«Информационно-аналитические системы»	http://www.ians.ru/
5	Библиобус	«ИКС Три», БЕН РАН	http://www.eks3.ru/
6	Буки	ООО «Рикс Хаус» (Ярославль)	http://www.buki.yar.ru/
7	Ирбис	ГПНТБ, ЭБНИТ
8	Колибри +	НМБ СПб Государственной Консерватории	http://www2.colibry.com/
9	МАРК-SQL	НПО «Информ-система»	http://www.informsystema.ru/
10	Моя библиотека	БКС – МГУ	http://www.bks-mgu.ru/
11	НЕВА	«Балтиксофт» (Санкт-Петербург)	http://www.balticsoft.ru/
12	OPAC-Global(Midi, Mini)	«ДИТ-М»	http://www.ditm.ru/
13	Руслан	ООО «Открытые библиотечные системы» (Санкт-Петербург)	http://obs.ruslan.ru/
14	Фолиант	Петрозаводский государственный университет, ООО «ЕМЕ»	http://www.eme.ru/

Таблица 2 содержит для каждой из перечисленных выше АИБС используемые в АРМе библиотекаря технологии и СУБД.

Системы «Руслан» (строка 13 в таблице 2) и «Фолиант» (14) в качестве кандидатов для покупки мы рассматривать не стали, потому что они используют дорогостоящую СУБД Oracle, хотя о системе «Руслан» имелись хорошие отзывы, в частности, генеральный директор Центра ЛИБНЕТ Логинов Б.Р. называл эту систему в числе четырех лучших АИБС.

Таблица 2. АИБС: Используемые технологии и СУБД.

	Название	Технология	СУБД
1	Абсотек Юникод	Тонкий клиент	MS SQL Server 2005, 2008
2	АзЪ	Клиент-сервер	MS SQL Server
3	Академия+	Клиент-сервер	Любая реляционная: ORACLE, MS SQL Server, My SQL, PostgreSQL
4	АС Библиотека-3	Клиент-сервер	MS Access, MS SQL Server
5	Библиобус	Клиент-сервер	MS SQL Server 2005, 2008
6	Буки	Клиент-сервер/Файл-сервер	MS SQL Server, Access/DBF-формат
7	Ирбис	Клиент-сервер	CDS/ISIS
8	Колибри +	Клиент-сервер	Btrieve
9	МАРК-SQL	Клиент-сервер	MS Access, MS SQL Server, Oracle
10	Моя библиотека	Клиент-сервер	MS SQL Server 2005
11	НЕВА	Клиент-сервер	Собственный механизм управления данными
12	OPAC-Global(Midi, Mini)	Тонкий клиент	ADABAS
13	Руслан	Клиент-сервер	Oracle
14	Фолиант	Клиент-сервер	Oracle

Система «Колибри+» (8) отпала, поскольку она использует редко встречающуюся СУБД Btrieve и, кроме того, она предназначена главным образом для нотных библиотек и ориентирована на англо-американский стандарт MARC21.

Система «Нева» (11) использует собственный механизм управления данными и предназначена для небольших библиотек. В таких библиотеках, как правило, нет компьютерных специалистов, которые могли бы заниматься администрированием базы данных. В нашем институте довольно большая библиотека и нет таких ограничений по специалистам, поэтому мы рассматривать эту систему не стали.

О системе «Ирбис» (7) имелись хорошие отзывы, в частности, Б.Р.Логинова. Она имеет большое число внедрений, в том числе в институтах РАН. Демонстрационная версия, которую мы скачали с сайта разработчиков, тоже произвела неплохое впечатление. Однако мы решили ее не покупать из-за описанных выше недостатков CDS/ISIS, а также из-за необходимости в будущем переделывать электронный каталог под новые правила каталогизации RDA, для которых больше подходит реляционная модель данных. Кроме того, система создавалась в 1995 году, еще до введения стандарта RUSMARC. Ее логическая структура соответствует существовавшему тогда ГОСТу на составление библиографических описаний, и при преобразовании данных в RUSMARC и обратно возможны небольшие несоответствия.

Очень хорошее впечатление произвела система «OPAC-Global» (12), на основе которой работает Центр ЛИБНЕТ. Система использует мощную коммерческую СУБД ADABAS, модель данных которой хорошо соответствует стандарту RUSMARC, лежащему в основе логической структуры данных этой системы. Преимуществом системы является также использование технологии «тонкий клиент». Работа не только читателя, но и библиотекаря ведется через браузер и не требует установки специального ПО на рабочем месте. Сотрудники фирмы «ДИТ-М» произвели впечатление не только грамотных технических специалистов, но и людей, глубоко разбирающихся в библиотечном деле. По-видимому, на сегодняшний день «OPAC-Global» — это лучшая АИБС, и если бы в дальнейшем не планировался переход на правила RDA, мы остановились бы на этой системе, несмотря на ее очень высокую цену. К сожалению, хотя сотрудники фирмы и работают над переходом на новые правила каталогизации, они не планируют в дальнейшем отказ от использования СУБД ADABAS и переход на одну из распространенных коммерческих реляционных СУБД. На наш взгляд, это может создать проблемы в будущем. Поскольку ADABAS становится все менее популярной, то в перспективе трудно будет найти специалистов, разбирающихся в этой СУБД, для выполнения функций администрирования.

Таким образом, остались системы, которые в качестве СУБД могут использовать СУБД Microsoft SQL Server. Мы решили, что хотя на данный момент использование реляционной СУБД для ведения библиотечного каталога в АИБС не является адекватным, нам будет удобнее купить одну из таких АИБС, чтобы в дальнейшем облегчить переход на правила RDA с использованием реляционной модели.

Систему «Буки» (6) мы рассматривать не стали, поскольку клиентская часть системы написана на морально устаревшей Visual FoxPro.

При анализе других систем, которые могут использовать в качестве СУБД Microsoft SQL Server, выяснилось, что в них реализован один из трех вариантов хранения библиографического описания:

1) хранение всего библиографического описания в одном поле типа text или image в одном из MARC-форматов;

2) распределение библиографического описания по двум таблицам: в первой, основной таблице для каждого библиографического описания заводится строка, часть атрибутов библиографического описания, не являющихся множественными, хранится в отдельных столбцах этой строки; во второй, дополнительной таблице, связанной с первой, каждому оставшемуся атрибуту, имеющему непустое значение, соответствует отдельная строка;

3) хранение всего библиографического описания в одном поле в виде библиографической карточки.

Первый вариант хранения реализован в системах

(3) «Академия+» (источник информации — публикация [18]);

(4) «АС Библиотека-3» (источник информации — документация на сайте разработчика);

(9) «МАРК-SQL» (источник информации — демонстрационная версия, скачанная с сайта разработчика);

(10) «Моя библиотека» (источник информации — демонстрационная версия, скачанная с сайта разработчика).

Второй вариант хранения реализован в системах

(1) «Абсотек Юникод» (источники информации — документация на сайте демонстрационной версии в интернете, ответы разработчиков на наши письма);

(2) «АзЪ» (источник информации — публикация [19]).

Третий вариант хранения реализован в системе «Библиобус» (5) (источник информации — ответ разработчиков на наше письмо).

Ясно, что ни один из этих вариантов не является реализацией реляционной модели, в которой каждому атрибуту сущности должен соответствовать отдельный столбец, что находится в соответствии со сформулированным выше утверждением о невозможности эффективной реализации реляционной модели при действующих стандартах.

Первый вариант хранения имеет два существенных недостатка:

1) неструктурированное хранение данных в MARC-формате, что делает данные, непосредственно хранящиеся в БД, плохо воспринимаемыми человеком и затрудняет отслеживание ошибок ввода информации;

2) необходимость дублирования информации в специально создаваемых таблицах для тех атрибутов, по которым происходит поиск, что может привести к рассогласованию данных и ошибкам при поиске.

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

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

Среди систем, реализующих первый вариант хранения, наиболее популярна система «МАРК-SQL» (9). Ее также называл в четверке лучших Б.Р. Логинов. Из систем, реализующих второй вариант хранения, возможной для покупки оказалась только «Абсотек Юникод» (1). Разработчики системы «АзЪ» (2) на наше письмо не ответили. Таким образом, выбор библиотечной системы свелся к выбору из трех систем:

(1) «Абсотек Юникод»

(5) «Библиобус»

(9) «МАРК-SQL»

О системе «Абсотек Юникод» мы судили по демонстрационной версии, представленной в Интернете, и ответам разработчиков на наши письма. Демонстрационная версия для скачивания разработчиками не предоставлялась.

К достоинствам системы с точки зрения общего проектирования можно отнести уже упоминавшееся структурированное хранение данных, а также наличие в БД представлений, хранимых процедур и функций, использование технологии «тонкий клиент», открытость значительной части кода. Система функционально богата. Однако пользовательский интерфейс не очень удобен для библиотекаря.

На рис. 5–6 приведены формы редактирования и просмотра сведений об издании.

Рис. 5. Форма редактирования сведений об издании в системе
«Абсотек Юникод».


Рис. 6. Форма просмотра сведений об издании в системе «Абсотек Юникод».
Заполнение и просмотр данных требуют прокрутки. На наш взгляд, если бы данные были сгруппированы и разнесены по разным страницам, пользователю было бы удобнее.

Система создавалась не с нуля, а путем перевода и адаптации французской системы. Перевод не везде удачен и временами может приводить к недоразумениям. Например, при нажатии на значок под названием «параметры» возникает меню, представленное на рис. 7. Меню, очевидно, содержит не параметры, а набор действий.

Рис. 7. Выпадающее меню, возникающее при нажатии на значок
под названием «Параметры».

При нажатии на значок «Формат вывода» возникает меню, представленное на рис. 8. Кроме того, что в нем имеются опечатки, оно содержит смесь форматов вывода и конкретных действий, например, печати карточки. К глубокому разочарованию наших библиотекарей, печать карточки оказалась лишь выводом в файл формата «Word». Поля Unimarc в меню на самом деле являются полями Rusmarc. Можно было бы отразить это в меню.

К недостаткам системы можно также отнести медленное обновление экрана и неполное соответствие стандарту RUSMARC. Тест на соответствие стандарту, размещенный на сайте [6], эта система не прошла. При импорте пропали связи многотомника с отдельными томами.

У системы «Абсотек Юникод», на наш взгляд, хорошее будущее. Благодаря структурированному хранению данных она удобна для перехода в дальнейшем на правила RDA, однако для того чтобы наши библиотекари могли начать ее использовать, нужно было бы потратить довольно много времени на ее доработку.

Рис. 8. Выпадающее меню, возникающее при нажатии на значок
под названием «Формат вывода».

Система «МАРК-SQL» имеет очень много внедрений. Она также получила свидетельство национальной службы развития системы форматов RUSMARC о соответствии стандарту. Однако неструктурированное хранение данных в MARC-формате (кроме уже упоминавшихся его недостатков), осложняет переход в дальнейшем на правила RDA.

Пользовательский интерфейс, на наш взгляд, тоже не слишком удобен для библиотекаря.

На рис. 9 представлена форма ввода сведений об издании, являющемся монографией. Форма содержит довольно много полей и подполей. Реально заполняются далеко не все, и пользователь может потратить много времени на выбор тех из них, которые нуждаются в заполнении. В системе предусмотрена возможность создания шаблонов, в которых задается список полей и подполей для заполнения, но чтобы создавать шаблоны, администратор системы должен быть хорошо знаком с MARC-форматом.

Рис. 9. Форма ввода сведений об издании в системе «МАРК-SQL».

На рис. 10 представлена форма ввода и редактирования сведений об издании. На ней имеются только заполненные поля. Если понадобится вводить данные в другие поля или подполя, надо будет нажать дополнительные клавиши для того, чтобы эти поля и подполя появились в списке. При этом также требуется знание MARC-формата.

Рис. 10. Форма просмотра и редактирования сведений об издании
в системе «МАРК-SQL».

Таким образом, для начала работы с этой системой и библиотекари, и администратор системы должны пройти обучение стандарту RUSMARC. Возможно, это и имело бы смысл, если бы в будущем не планировался переход на правила RDA.

В итоге мы сочли, что из трех систем, «Абсотек Юникод», «МАРК-SQL» и «Библиобус», наилучшей для библиотекаря в нашем случае является система «Библиобус». Она привлекла нас в первую очередь пользовательским интерфейсом.

На рис. 11–12 приведены формы просмотра и редактирования библиографических данных в этой системе.

Рис. 11. Форма просмотра сведений об издании в системе «Библиобус».

Интерфейс сделан с заботой о библиотекаре. Библиотекарю гораздо удобнее вводить данные в привычном для него виде библиографической карточки, а не заполнять отдельные поля, соответствующие MARC-формату, как это делается в «МАРК-SQL», тем более что потом эти отдельные поля все равно преобразуются в одно и хранятся в одном столбце в базе данных.

Дополнительным преимуществом системы «Библиобус» является возможность импорта из базы данных БЕН РАН сведений о тех изданиях, которые поступают в нашу библиотеку через БЕН.



Рис. 12. Форма редактирования сведений об издании
(библиографического описания) в системе «Библиобус».

Если же сравнивать поставляемые отдельно OPAC-модули, которые предоставляют читателю доступ к электронному каталогу через Интернет, то электронный каталог «ABSOPAC Unicode», соответствующий системе «Абсотек Юникод», несомненно, выигрывает по сравнению с электронным каталогом, соответствующим системе «Библиобус». К сожалению, демонстрационную версию OPAC-модуля "МАРК-SQL Internet", разработчики «МАРК-SQL» на сайте не разместили.

На рис. 13–14 приведены форма запроса и результат запроса в «ABSOPAC Unicode». На рис. 15 приведена форма запроса вместе с результатом в электронном каталоге системы «Библиобус».

Главное преимущество «ABSOPAC Unicode» в том, что он предоставляет возможность не только найти нужную литературу в каталоге, но и увидеть, доступны ли экземпляры, и сделать заказ. Электронный каталог системы «Библиобус» такой возможности не предоставляет. Система заказа литературы может быть приобретена дополнительно как отдельный модуль. Однако разработчики системы «Библиобус» обещают в будущем добавить функцию заказа литературы в свой электронный каталог.

Рис. 13. Форма запроса в электронном каталоге ABSOPAC Unicode.



Рис. 14. Результат запроса в электронном каталоге ABSOPAC Unicode.



Рис. 15. Форма и результат запроса в электронном каталоге
системы «Библиобус».

Поскольку первоочередной задачей после приобретения АИБС является заполнение каталога, мы сочли, что на начальном этапе удобство работы библиотекаря важнее возможностей, предоставляемых читателю, и остановили свой выбор на системе «Библиобус». Надеемся также, что к тому моменту, когда каталог будет заполнен настолько, что он сможет быть полезным сотрудникам института — читателям библиотеки, нужные функции в электронном каталоге системы «Библиобус» появятся.

Оказалось, что наше мнение о том, какую систему покупать, совпало с мнением заведующей библиотекой. Она считала, что нам лучше всего опереться на разработки БЕН РАН, поскольку наш институт находится в системе РАН и БЕН все годы существования нашей библиотеки являлся основным поставщиком литературы. Ну, а насколько оправданным оказался наш выбор, покажет со временем опыт эксплуатации системы.

* * *

Авторы выражают признательность генеральному директору Центра ЛИБНЕТ Б.Р. Логинову, а также сотрудникам компании «Либэр» О.Д. Долиной и И.В. Сорокину за полезные беседы и предоставленную информацию.

Литература

1. Бойченко А. В., Васильчиков В. В., Кожевников А. Г. Нормативно-техническая база АБИС. — http://www.dksobrb.ru/doc/specam/boichenko.doc.

2. Бойченко А. В. Функциональная стандартизация автоматизированных информационных библиотечных систем (АБИС) // Сборник трудов ХI научно-практической конференции «Реинжиниринг бизнес-процессов на основе современных информационных технологий. Системы управления знаниями». — Москва, 2008. — Т. 2. — РБП-СУЗ-2008.

3. Малиновский М. П. Поспешность — залог фиаско // НТБ МАДИ (ГТУ) : Публикации. — 2007. — http://lib.madi.ru/pub/topics/malNtb2.shtm.

4. MARC STANDARDS (Network Development and MARC Standards Office, Library of Congress) // Library of Congress Home. — http://www.loc.gov/marc/.

5. MARC standards — Wikipedia, the free encyclopedia // Wikipedia, the free encyclopedia. — http://en.wikipedia.org/wiki/MARC_standards.

6. Национальная служба развития системы форматов RUSMARC // РОССИЙСКАЯ БИБЛИОТЕЧНАЯ АССОЦИАЦИЯ. – http://www.rba.ru/rusmarc/.

7. Professional Development — NISO Webinar: Bibliographic Control Alphabet Soup. — http://cloud.lib.wfu.edu/blog/pd/2009/10/14/niso-webinar-bibliographic-control-alphabet-soup/.

8. Moen William. Data-Driven Evidence for Core MARC Records // Information Standards Quarterly. — 2010. — SPECIAL EDITION: STATE OF THE STANDARDS and year in review. — Вып. 1 : Т. 22.

9. CDS/ISIS database software // United Nations Educational, Scientific and Cultural Organization. — http://portal.unesco.org/ci/en/ev.php-URL_ID=2071&URL_DO=DO_TOPIC&URL_SECTION=201.html.

10. Bhat Gurunandan R. Library Digital Resources: Relational Databases or Catalogues? (A Short Tutorial). — 2001. — https://drtc.isibang.ac.in/bitstream/handle/1849/91/Bhat.pdf?sequence=2.

11. Брусенков И. В., Кондратенков В. А., Силин В. Д. ADABAS — основа семейства программных продуктов фирмы Software AG для создания корпоративных баз данных. — 1996. — http://citforum.ru/database/kbd96/510.shtml.

12. Functional Requirements for Bibliographic Records | IFLA // International Federation of Library Associations and Institutions (IFLA). — http://www.ifla.org/en/publications/functional-requirements-for-bibliographic-records.

13. UML — Википедия // Википедия — свободная энциклопедия. — http://ru.wikipedia.org/wiki/UML.

14. Joint Steering Committee for Development of RDA: RDA // Joint Steering Committee for Development of RDA. — http://www.rda-jsc.org/rda.html.

15. Логинов Б. Р. Чем сложнее задача, тем интереснее решение // Современная библиотека. — Москва, 2009. — Вып. 2.

16. Бахтурина Т. А. Будущее каталогизации в России и в мире // Научные и технические библиотеки. — Москва : Министерство образования и науки Российской Федерации; Государственная публичная научно-техническая библиотека России., 2010. — Вып. 9. — стр. 34-44.

17. Delsey Tom. RDA Database Implementation Scenarios. — http://www.rda-jsc.org/docs/5editor2rev.pdf.

18. Ляшенко Т. В. Потенциал развития. Система, «смотрящая» в будущее. // Библиотечное дело. — Санкт-Петербург : "Агентство Информ-Планета", 2009. — Вып. 96. — № 06.

19. Ткачев В. И., Мошкин С. В. Особенности построения RUSMARC-ориентированной базы данных «ИнфоКомм» // Библиотеки и информационные ресурсы в современном мире науки, культуры, образования и бизнеса: 11-я Международная конференция «Крым 2004». — Судак, 2004.