Третья Всероссийская научно-практическая конференция "Университетская библиотека на рубеже тысячелетий: выбор пути"
[05.12.2000 - 07.12.2000]

О. В. Баранова

Корпоративный электронный каталог: вчера, сегодня, завтра

     Уважаемые участники конференции!
Заканчивается первый этап работы в рамках корпоративного проекта "Consensus Omnium". Я думаю, год – это достаточный срок, чтобы можно было остановиться, оглянуться назад, оценить уже сделанное, и, основываясь на приобретенном опыте, попытаться построить дальнейшую стратегию. Не вдаваясь в технические подробности, я попытаюсь описать методы хранения данных в сводном каталоге нашего корпоративного проекта. Тем более что именно эта сторона обычно скрыта от пользователей.
     Итак, позвольте мне вспомнить, как все это начиналось год назад, какие факторы повлияли на выбор технологий и программного обеспечения. Исторически сложилось так, что большинство библиотек – участниц корпоративного проекта используют в своей работе программное обеспечение "МАРК", разработанное НПО "Информ-система". Наши библиотекари работают с этой программой давно, она их, в основном, устраивает, и, поэтому было принято решение использовать АИБС "МАРК-WEB этой же компании для объединения информационных ресурсов библиотек и доступа к ним в сети Интернет. Для хранения сводного каталога библиотек – участниц корпоративного проекта была выбрана система управления базами данных (СУБД). Почему мы остановились на этой, довольно дорогой, СУБД?

• СУБД Oracle – одна из самых популярных в мире систем для работы с базами данных. Она предназначена для обработки больших объемов информации, высокопроизводительна и достаточно надежна. Кроме того, эта СУБД Internet ориентирована, поддерживает различные платформы (в том числе мощные многопользовательские сервера фирмы Sun Microsystems, которые широко используются в Центре компьютерных технологий).
• В приобретении СУБД Центру компьютерных технологий помогла финансовая поддержка Института "Открытое общество". Первая лицензионная версия Oracle 8.0.4 была получена в рамках гранта ИОО. Этот факт имел немаловажное значение при выборе СУБД, т.к. современные высокоэффективные среды для работы с базами данных стоят немалые деньги. В настоящее время СУБД Oracle в нашем центре обновлена до версии 8.1.6, которая является одной из самых последних версий.
• Как любая сложная система, СУБД Oracle требует наличия квалифицированных специалистов для своего обслуживания. У нас в Центре компьютерных технологий работают 4 сертифицированных администратора Oracle, обученных в рамках гранта ИОО.
• НПО "Информ-система", анонсируя АИБС "МАРК-WEB", заявила сервер Oracle в списке поддерживаемых SQL серверов.

     Последнее немаловажно, поскольку, как было сказано выше, в качестве программного обеспечения для организации сводного электронного каталога уже использовалось ПО компании "Информ-система". В дальнейшем же оказалось, что платформу Oracle "МАРК-WEB" не поддерживает, вернее, поддерживает, но не сейчас, а через некоторое время. А на время доработки АИБС нам предлагалось использовать другую СУБД, например, Microsoft Access. Но Access существенно уступает Oracle в производительности и надежности. Если бы сводный каталог содержал не более 10 тысяч записей, мы, возможно, и рассмотрели бы этот вариант. К тому же, поработав в среде, мы поняли преимущества этой платформы. Другими словами, предложенный вариант нас не устраивал, и мы настояли на доработке программного обеспечения "МАРК-WEB" в контексте совместимости с СУБД Oracle.

     В результате длительной переписки со специалистами компании "Информ-система" нам удалось установить "МАРК-WEB" на основе имеющейся у нас СУБД Oracle. Сводный электронный каталог корпоративного проекта "Consensus Omnium", реализованный с помощью АИБС "МАРК-WEB" был выставлен в сети Интернет, но существовал в этом виде очень недолго. Недолговечность каталога объяснялась наличием объективных недостатков, смириться с которыми мы не могли:

• Самый простой поиск происходил очень долго – до 5-ти минут.
• Поиск был чувствителен к регистру, т.е. в каталоге искались записи в точности соответствующие введенному поисковому терму (вплоть до регистра). А если учесть, что словари по поисковым полям в "МАРК-WEB" составлялись по разному (словарь ключевых слов, например, полностью переводился в верхний регистр, а остальные словари – нет) и пользователь не знал принципов, которыми руководствовались разработчики "Информ-системы" при составлении словарей, то становится понятно, что результат поиска в большинстве случаев был неадекватен ожидаемому результату.
• Поисковые возможности, заложенные в интерфейсе, не удовлетворяли потребности наших пользователей (информации, выдаваемой в результате поиска, было недостаточно для заполнения требования на найденную книгу; поиск по нескольким полям с условием "И" был невозможен; навигация по результатам поиска была затруднена отсутствием необходимых кнопок таких, как "Назад", "Помощь").

     Сейчас, я думаю, все эти проблемы решены разработчиками АИБС "МАРК-WEB", т.к. эти препятствия не относятся к числу непреодолимых. Перечисленные неприятности устранимы, но для этого необходимо время, которого у нас не было. Не оставалось времени и на то, чтобы сделать что-то полностью свое. Поэтому мы решили не отказываться полностью от программного обеспечения "МАРК-WEB", а оставить только ту его часть, которая конвертирует записи в формате USMARC (файлы ldb, созданные предыдущими версиями АИБС "МАРК") в СУБД Oracle.

     Я не буду подробно останавливаться на структуре записи библиографического описания в формате USMARC. В среде Oracle после конвертации эти же записи хранятся в виде таблицы:

     Единица библиографического описания (item) представляет собой знакомую вам запись в формате с незначительными изменениями: справочник удален, а поля описания расположены последовательно, отделенные друг от друга специальными символами–разделителями. Каждое поле имеет свой код, который в записи – описании следует за разделителем и предшествует содержимому поля. Поле может содержать подполя, идентифицируемые, также, символами-разделителями и кодами.

Пример:

Запись до конвертации:

00555nam 22001697 4500
005001700000 020000900017 020001000026 040006400036 080002100100 090005500121
100002000176 245009900196 260001800295 300001100313 653004200324 990001900366^

20000613132717.5^00Ўc1-35^00Ўc32-00^ 00ЎaНаучная библиотека Уральского государственного университета^ 00Ўa530.145.6(076.2)^ 00Ўa530ЎxФ 738Ўe745334; 746090; 746091; 1202937Ў fАЕЛ-4^10ЎaФлюгге, Зигфрид^ 00ЎaЗадачи по квантовой механике: В 2 т.Ў nТ. 2ЎcПер. с англ. Б. А. Лысова; Под ред. А. А. Соколова^ 00ЎaМ.ЎbМирЎc1974^ 00Ўa315 с.^ 00ЎaКВАНТОВАЯ МЕХАНИКА (ЗАДАЧИ И РЕШЕНИЯ)^ 00Ўf25.10.99Ўz0Ўj4

Запись после конвертации:

005 Ў020001127172808.4^ 02000Ўc1-35^02000Ўc32-00^04000ЎaНаучная библиотека Уральского государственного университета^08000Ўa530.145.6(076.2)^09000Ўa530Ўe745334; 746090; 746091; 1202937ЎfАЕЛ-4ЎxФ 738^10010ЎaФлюгге, Зигфрид^24500ЎaЗадачи по квантовой механике: В 2 т.ЎcПер. с англ. Б. А. Лысова; Под ред. А. А. СоколоваЎnТ. 2^26000ЎaМ.ЎbМирЎ c1974^30000Ўa315 с.Ў65300ЎaКВАНТОВАЯ МЕХАНИКА (ЗАДАЧИ И РЕШЕНИЯ)^99000Ўf25.10.99Ўj4Ўz0

Полужирным шрифтом выделены коды полей в библиографическом описании.

     После конвертации записей в систему управления базами данных с помощью АИБС "МАРК-WEB" предлагалось построить словари по полям, участвующим в поиске, что должно было ускорить получение информации. Но от построения словарей по поисковым полям мы решили отказаться, т.к. строились они очень долго (время исчислялось сутками) и ненадежно. К тому же, так как каждая запись содержит полное библиографическое описание книги (документа), для простого поиска достаточно имеющейся таблицы. Под простым поиском понимается отбор записей, содержащих контекстное вхождение поискового условия без уточнения того, в каком поле описания оно должно находиться. Используемая нами СУБД Oracle предоставляет механизм, позволяющий производить такой поиск, причем делать это с учетом или без учета регистра, в зависимости от желания пользователя.
     Если усложнить поисковую задачу, уточнив поле описания, в котором должно содержаться поисковое условие, имеющейся структуры может оказаться недостаточно. Вообще говоря, можно и для решения этой задачи ограничиться вышеприведенной таблицей. Так как поля и подполя имеют собственные идентификаторы, поиск можно уточнить, включив эти идентификаторы в поисковое условие. Например, для отбора книг, автором которых является Зигфрид Флюгге, можно искать контекстное вхождение строки "10010aФлюгге", добавив код поля "100" и код подполя "a" к фамилии автора.
     Однако автор может находиться еще и в поле 700, которое, к тому же, является повторяющимся, поэтому запрос будет слишком сложным, и, что более неприятно, включающим много дополнительных проверок, а это увеличит время, затраченное на поиск. Исходя из этих соображений, имеет смысл усложнить исходную структуру, введя дополнительные структурные элементы. Возможны различные пути расширения структуры, каждый из них имеет свои преимущества и недостатки. Мы решили выбрать самый простой способ решения этой проблемы, добавив к таблице документов дополнительные колонки для каждого поля описания, по которому предполагается поиск. При такой структуре поиск в определенном поле библиографического описания сводится к отбору записей, содержащих контекстное вхождение поискового условия в соответствующей колонке таблицы.
     Итак, в настоящее время сводный электронный каталог библиотек – участниц корпоративного проекта "Consensus Omnium" хранится в виде одной таблицы, состоящей из нескольких колонок. Эта схема проста, но работоспособна, и она нас устраивала полностью до тех пор, пока сводный электронный каталог библиотек – участниц корпоративного проекта не достиг объема, при котором заметно снизилась скорость поиска информации. Например, составная часть сводного каталога – каталог статей – содержит 48618 единиц описания, среднее время поиска в этом каталоге занимает около трех секунд, что является вполне удовлетворительным результатом. Время поиска в другой части сводного электронного каталога – каталоге книг, включающем на сегодняшний день 230115 записей, занимает от 20 до 40 секунд, а это не может удовлетворить потребности наших пользователей. Бесспорно, дальнейший рост количества библиографических описаний приведет к возрастанию времени, необходимого для поиска информации. Сегодня очевидно, что сводный электронный каталог корпоративного проекта "Consensus Omnium" перерос имеющуюся структуру хранения данных.
     Для ускорения процедуры поиска большинство автоматизированных информационных систем, в том числе АИБС "МАРК-WEB", используют построение словарей для каждого поискового поля библиографического описания. Словарной единицей в этом случае является содержимое соответствующего поля (подполя). Такие проиндексированные словари действительно существенно уменьшают время, затраченное на получение информации. Но эта методика имеет свои недостатки:

• Словарь состоит из словосочетаний или даже целых фраз, т.к. каждая запись словарной таблицы – это содержимое определенного поля библиографического описания. Поэтому словари реально индексируются только по началу полей. По этой причине затруднен отбор записей, содержащих контекстное вхождение поискового условия в отдельных полях описания. Например, если вы будете искать слово "Людмила" в названии документа, то вряд ли вы быстро найдете книгу "Руслан и Людмила". Фактически, существующая схема хранения данных в нашем сводном каталоге решает эту задачу существенно быстрее.
• При поиске информации в нескольких полях библиографического описания приходится учитывать слишком много словарных таблиц. Это также увеличивает время, необходимое для получения результата.
• Одной единице библиографического описания может соответствовать несколько записей словаря (например, ключевые слова). Кроме того, ссылка на один и тот же документ наверняка присутствует в нескольких словарных таблицах. Поэтому, если поисковый критерий не один (например, при поиске нескольких ключевых слов), результат может содержать одну и ту же запись несколько раз. Современные СУБД, в том числе СУБД Oracle, предоставляют механизм устранения дуплетов, но он тоже имеет свои недостатки, останавливаться на которых я не буду, т.к. это внутренняя проблема СУБД.
• При поиске информации "по всем полям" все-равно приходится обращаться к основной таблице каталога, если, конечно, не построены словари для каждого поля библиографического описания. Если учесть, что таких полей формат USMARC предполагает несколько сотен, то можно представить задачу, стоящую перед администратором СУБД, обслуживающим такое количество таблиц.

     Наиболее эффективным способом решения задачи быстродействия, как мне кажется, является построение словоуказателя - словарной таблицы, содержащей отдельные слова, встречающиеся в библиографическом описании, по аналогии с автоматическими индексами поисковых систем Итнернет. Принципиальное отличие этого способа от предыдущего состоит в том, что при построении словаря для каждого поискового поля словарной единицей является содержимое всего поля библиографического описания, в то время как в словоуказателе словарная единица – это слово. Поэтому в индекс, построенный для словоуказателя, попадают все слова, используемые при описании документа, и время поиска информации всегда будет меньше, чем при отборе записей прямо из основной таблицы каталога. Даже при поиске информации "по всем полям" нет необходимости обращаться к основной таблице каталога, т.к. словоуказатель содержит все слова библиографического описания. Т.е. при любом поиске отбор документов происходит с помощью индекса, что существенно уменьшает время, затраченное на поиск информации. Наличие словоуказателя устраняет большинство недостатков, присущих предыдущему методу, однако, некоторые проблемы остаются и при такой структуре хранения данных. Например, все равно приходится решать проблему наличия повторяющихся записей в результате отбора, а это требует дополнительного времени и дополнительных ресурсов компьютера.
     Проанализировав статьи, посвященные профессиональному поиску в Интернет, я обнаружила еще ряд поисковых проблем. Одна из них связана с, так называемыми, "стоп-словами" ("stop-words"). К "стоп-словам" относят служебные части речи, которые не несут смысловую нагрузку. Такие слова можно не включать в словоуказатель, т.к. неучет "стоп-слов" при обработке запроса сокращает время поиска и повышает релевантность отобранных документов. С другой стороны, попробуйте отыскать по заголовку роман Савинкова Б.В. "То, чего не было" или энциклопедию "Что такое? Кто такой?", названия которых состоят только из "стоп-слов", и вы уже не владеете ситуацией. Однако если предусмотреть возможность поиска прямо в основной таблице каталога, не прибегая к помощи проиндексированного словоуказателя, можно искать контекстное вхождение "стоп-слов" прямо в таблице библиографических описаний. Не существует стандартизованного перечня "стоп-слов", так что разработчик должен сам решать какие слова нецелесообразно включать в словоуказатель. Например, мне кажется, что первыми кандидатами на звание "стоп-слов" являются предлоги и союзы. В любом случае, необходимо информировать пользователя о том, какие слова учитываются при поиске с использованием словоуказателя и можно ли искать документы прямо в основной таблице каталога.
     Другая проблема имеет отношение к "интеллектуальности" поиска. Она в большей степени затрагивает полнотекстовый поиск информации, чем поиск в электронном каталоге, но, тем не менее, я не могу на ней не остановиться. Думаю, каждый пользователь Интернет знаком с ситуацией, когда находишь не то, что ищешь. Это, в основном, связано с неправильным построением поискового условия. Релевантность результатов поиска во многом определяет дружественный интерфейс, помогающий пользователю правильно построить запрос. Наиболее передовые поисковые системы Интернет, например, AltaVista, в настоящее время дают возможность строить поисковые фразы, используя ассоциативные связи. Например, вы ищете библиотеку. Вместе с результатом поиска вы получаете выбор: общественная библиотека, электронная библиотека, библиотека Конгресса и т.д. Выбрав электронную библиотеку, вы можете уточнить, что именно вас интересует: бесплатная электронная библиотека, электронная библиотека Канады или просто информация об электронных библиотеках. То есть поисковая фраза строится поэтапно, используя ассоциативные связи. Правильно построенная поисковая фраза обеспечивает адекватность найденных документов ожидаемому результату, поэтому необходимо предусмотреть поиск словосочетаний в документах, который затруднен в случае словоуказателя, т.к. он состоит из отдельных слов, содержащихся в записях. Эту проблему можно решить несколькими способами, любой из которых ведет к увеличению накладных расходов:

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

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

• сводный электронный каталог корпоративного проекта "Consensus Omnium" перерос имеющуюся структуру хранения данных;
• для ускорения процедуры поиска информации в сводном каталоге необходимо построение проиндексированного словоуказателя, содержащего слова, из которых состоят библиографические описания.
• целесообразно изменить структуру основной таблицы каталога для хранения библиографических описаний в виде объектов, что позволит описывать документы более детально и оперировать ими на более высоком уровне абстракции.

Список литературы:

1. Попов В.В. Новые и информационные технологии: использование АИБС "МАРК-SQL" для учреждений культуры, образования и науки // Электронная конвергенция: новые технологии в музеях, галереях, библиотеках и архивах: Материалы конференции "EVA'2000 Москва". - Москва, 2000. - С. 15-1-1 – 15-1-2.
2. Талантов М. Поиск информации в Интернет: подводные камни // Компьютер Пресс. – 1999. – N9. – С. 156 – 160.