CC BY
71
УЧЕНЫЕ ЗАПИСКИ КАЗАНСКОГО ГОСУДАРСТВЕННОГО УНИВЕРСИТЕТА
Том 151, кн. 3
Физико-математические пауки
2009
УДК 004.9
МИФОЛОГИЧЕСКАЯ МОДЕЛЬ НАУЧНО-ОБРАЗОВАТЕЛЬНОЙ ЭЛЕКТРОННОЙ БИБЛИОТЕКИ ВУЗА
А.Г. Абросимов, Д. С. Зуев
Аннотация
В статье рассматривается ипфологическая модель, а также обсуждаются принципы построения программного обеспечения для электронной библиотеки вуза. Предлагается подход к объединению разнородных электронных коллекций в библиотеку па основе технологий веб-сервисов.
Ключевые слова: электронная библиотека, электронные коллекции, ипфологиче-ское моделирование.
Введение
Как известно (см.. например. [1]). отличительной чертой современного этапа развития человечества является представление информации и знаний не только в традиционной печатной, но и в электронной, цифровой форме, что позволяет принципиально иначе создавать, хранить, использовать информацию и организовывать доступ к ней. Современные информационные технологии привели к тому, что большое число информационных ресурсов сразу создается в электронном виде. В условиях формирования информационного общества чрезвычайно важным инструментом устойчивого экономического и социального развития является обеспечение публичного (в том числе удаленного) доступа к социально значимой информации. в первую очередь, к данным научного, образовательного и культурного характера.
Электронные библиотеки (ЭБ) как новое направление научно-практической деятельности представляют собой область пересечения интересов целого ряда дисциплин. включая управление данными и документооборотом, информационный поиск, библиотечное дело, информационные системы, сети и телекоммуникации, обработку изображений, искусственный интеллект, взаимодействие компьютера и человека. Естественно, что в первые годы развития ЭБ. начиная с середины 90-х годов XX века, усилия исследователей главным образом были направлены на объединение на новой почве возможностей того инструментария, который был разработан в названных дисциплинах. По большей части каждый из реализованных проектов в области электронных библиотек в определенном смысле был изолированным от остальных, потому что он заканчивался формированием системы, реализующей специфические потребности, заложенные в проекте. Однако, анализируя отдельные достижения всех проектов, можно обнаружить в них много общего, что позволяет сформулировать общие подходы к построению систем ЭБ.
В силу мультидисциплинарной природы ЭБ появилось несколько концепций того, что такое электронная библиотека, и было сформулировано несколько базовых определений ЭБ. Стало очевидным, что ЭБ является сложным понятием с несколькими разнообразными аспектами, которое не может быть охвачено одним
простым определением, и что требуется сформировать всестороннее представление о нем. отражающее все перспективы. Таким образом, за годы исследования были накоплены существенные знания и опыт, а электронные библиотеки, несмотря на молодой возраст, прошли длинный путь развития от начальной концепции до текущего состояния и достигли сегодня такого уровня завершенности, который, по мнению специалистов, позволил установить основные правила создания ЭБ и сформулировать полный спектр понятий, имеющих значение для ЭБ.
1. Система управления вузовской ЭБ
В создании информационных ресурсов весьма значительную роль играют вузы. основные информационные (образовательный и научный) ресурсы которых в настоящий момент создаются, как правило, в электронном виде. При этом многие вузы уже имеют большой опыт работы с электронными каталогами, создаваемыми с помощью автоматизированных библиотечно-информационных систем. Эти каталоги в определенной степени можно считать предтечами электронных библиотек.
Для вузов предоставление открытого доступа к своим ресурсам имеет ряд принципиально важных позитивных моментов. Во-первых, это форма рекламы. Если вуз выставляет на своем сайте хорошие учебно-методические пособия, то это означает. что в нем работают хорошие преподаватели, у которых есть чему научиться, причем даже беглый просмотр вузовских сайтов убеждает в том. что выставляются действительно достойные материалы, как правило, в тех направлениях, в которых эти вузы наиболее сильны. Во-вторых, размещение в интернете это и форма общественной экспертизы работы. Сейчас мало кто решится выставить на всеобщее обозрение плагиат или откровенно слабую компилятивную работу.
Сегодня большинство ЭБ тематические и представляют они собой в основном электронные аналоги печатных изданий. В отличие от них. ЭБ вуза содержит более широкий спектр информационных ресурсов, то есть является политематической. Это обусловлено хотя бы тем. что в вузе, а особенно в классических университетах. одновременно развивается множество научных направлений. Казанский государственный университет (КГУ) не исключение, например. Научная библиотека им. H.H. Лобачевского КГУ содержит обширные разнородные коллекции материалов. которые представляют особый научный интерес. Кроме того, в любом вузе существует всегда не менее двух направлений деятельности образовательная и научная. Таким образом, очевидно, что вузовская библиотека не может отражать интересы лишь какой-то одной области знания. В дальнейшем все наши рассуждения будем строить с учетом этих положений.
1.1. Мифологическая модель ЭБ. Все вышеизложенное, естественно, вызывает необходимость создания полноценной электронной библиотеки вуза, аккумулирующей все собственные ресурсы, а также внешние ресурсы, доступ к которым вуз приобрел или получил бесплатно. Однако специфика образовательного учреждения предполагает предъявление особых требований к создаваемой информационной системе [2. 3]. Во-первых, как уже упоминалось выше, необходимо интегрировать электронные коллекции, как собственные, так и приобретенные. Во-вторых, во многих вузах ведутся разработки или происходит внедрение информационных систем, предназначенных для автоматизации образовательной, административной и других видов деятельности, и электронная библиотека должна рассматриваться как естественная часть этого комплекса информационных систем, который можно назвать системой информатизации деятельности вуза. В-третьих, электронные коллекции вуза различаются по описываемым материалам, по об-
ласти применения. Как следствие, каждая коллекция нмеет свой профиль метаданных. Примером могут служить две центральные коллекции образовательная и научная. Для образовательной коллекции естественно использовать форматы метаданных LOM (Learning Object Metadata, http://ltsc.ieee.org/wgl2/), RIJSLOM (http://spec.edn.ni/sights/spec.nsf/(all)?OpenView&RestrictToCategory 3). а для научной можно использовать, например. Dublin Core (http:// dnblincore.org/ documents/ 1999/07/02/dccs/) или другие специализированные форматы.
Таким образом. ЭБ, особенно вузовская, имеет иерархическую структуру и состоит из разнородных коллекций. Внутри коллекций можно выделить разделы, которые в свою очередь образованы совокупностью электронных документов.
Как известно (см.. например. [4. 5]). иифологическая модель (или. иначе. ER-модель. ER-диаграмма) используется на ранних стадиях разработки проекта. Модель использует формализованный язык для описания и проектирования баз данных. Модель имеет однозначную интерпретацию в отлично от некоторых предложений естественного языка, и поэтому здесь не может быть никакого недопонимания со стороны разработчиков.
Эта модель в наибольшей степени согласуется с концепцией объектно-ориентированного проектирования, которая в настоящий момент времени, несомненно. является базовой для разработки сложных программных систем.
В основе ннфологнческой модели лежат следующие базовые понятия.
• Сущность, с помощью которой моделируется класс однотипных объектов.
Сущность имеет имя, уникальное в пределах моделируемой системы. Так как
сущность соответствует некоторому классу однотипных объектов, то предполагается, что в системе существует множество экземпляров с данной сущностью. Объект, которому соответствует понятие сущности, имеет свой набор атрибутов характеристик, определяющих свойства данного представителя класса. При этом набор атрибутов должен быть таким, чтобы можно было различать конкретные экземпляры сущности. Например, у сущности «Сотрудник» может быть следующий набор атрибутов: «Номер», «Фамилия», «Имя», «Отчество», «Дата рождения». Набор атрибутов, однозначно идентифицирующий конкретный экземпляр сущности, называют ключевым. Для сущности «Сотрудник» ключевым будет атрибут «Номер», поскольку для всех сотрудников данного предприятия табельные номера будут различны. Экземпляром сущности «Сотрудник» будет описание конкретного сотрудника предприятия.
Одно из общепринятых графических обозначений сущности прямоугольник, в верхней части которого записано имя сущности, а ниже перечисляются атрибуты, причем ключевые атрибуты помечаются, например, подчеркиванием или специальным шрифтом.
•
показывающие, каким образом сущности соотносятся или взаимодействуют между собой.
Связь может существовать между двумя разными сущностями или между сущностью и ею же самой (рекурсивная связь). Она показывает, как связаны экземпляры сущности между собой. Если связь устанавливается между двумя сущностями, то она определяет взаимосвязь между экземплярами одной и другой сущности.
Рассмотрим инфологичоскую модель системы ЭБ (см. рис. 1). Выделим основные сущности. Поскольку ЭБ состоит из электронных коллекций (ЭК), то разумно выделить сущность ЭК. Она должна содержать уникальный идентификатор коллекции и ряд атрибутов, как то: Наименование, Логотип, Создатель, Профиль метаданных коллекции и другие. Атрибуты коллекции должны отражать описания
Составной ИР-
эк
РК CID
Наименование
Описание
Логотип
Профиль
И др..
И
L< РК
Информационный ресурс
й
ОС-описание Статус ЭД и ДР.
—У—у у у
Управляет ЭК
ЭД состоит в нескольких ЭК : ЭК много ЭД
Управляет ЭД
Тек. персонал
РК &
Login
Пароль
ФИО
Роль
и др..
Контейнер ИР
РК Ш
Формат представления Дата доЕаеяения Путь к началу и др..
Поиск и просмотр ЭД—
_Управляет правами _ пользователем
Измеиенме ЭД
Пользователи
РК Ш.
Login
Пароль
ФИО
Роль
и др..
С
Единица хранения
РК id
Фейп
Описание
Checksum
Дата изменения
и др..
Рис. 1. Ипфологичоская модель ЭБ
самой коллекции, общих свойств документов, содержащихся в ЭК. а также связи между документами и коллекцией.
Электронная коллекция состоит из разделов и электронных документов. Раздел коллекции должен содержать в точности такие же атрибуты, что и сама коллекция. поэтому не будем выделять раздел как отдельную сущность, но должна быть предусмотрена возможность организации древовидной структуры ЭК и их разделов. Информационным ресурсом (ИР) будем называть основную единицу содержания ЭК. ИР состоит из электронного документа и его описания. Соответственно. необходимо рассматривать сущность «Информационный ресурс». Поскольку в каждой коллекции содержится множество ИР. то здесь присутствуют связи «один-ко-многим». В то же время один ИР может содержаться в нескольких ЭК. то есть ЭК и ИР связаны связью «многие-ко-многим».
Отдельно необходимо рассмотреть сущность «Информационный ресурс». ИР можно представить как данные (собственно электронный документ (ЭД)) и метаданные. описывающие эти данные. В самом простом случае данные это бинарный. текстовый нлн графический файл. Однако файлов в электронном документе может быть несколько и им соответствует одно описание ИР. Информационный ресурс также может иметь более сложную структуру, например состоять из различных частей (журнал состоит из статей, книга состоит из отдельных глав и частей). Здесь возникает вопрос, что считать неделимым ИР. Можно считать одни том журнала одним электронным документом. Однако такого рода информационный ресурс требует внутренней навигации. В то же время каждая журнальная статья имеет своих авторов, поэтому логичнее считать именно отдельную статью неделимым ИР. Но статья содержится в журнале и является его частью, поэтому
требуется механизм, который отображал бы подобные иерархии ПР. При построении инфологической модели будем предполагать, что IIP может состоять из частей. это позволит нам отразить возможную иерархию IIP. Поскольку ЭБ это еще и долговременное хранилище данных, то необходимо отслеживать все изменения не только описаний ИР. но и данных документов. Поэтому предлагается вынести на рассмотрение новую сущность, назовем ее «Контейнер ИР». Каждому описанию ИР ставится в соответствие только один контейнер ресурса (связь «один-к-одному»). Эта сущность, помимо уникального идентификатора, содержит ряд атрибутов, которые отвечают за целостность и изменение данных документа (отслеживаются дата добавления/изменения документа, формат представления ЭД. полный путь к данным, связи внутри ЭД). В контейнере ЭД может содержаться несколько «Единиц хранения ИР» («один-ко-многим»). Это сущность, которая содержит информацию о конкретном файле или битовом потоке соответствующего электронного документа (ID. контрольную сумму, связи с другими частями ЭД. описание) и является неделимым информационным объектом.
1.2. Роли пользователей системы. Жизненный цикл ИР. У любой информационной системы, в том числе у электронной библиотеки существует, свой круг пользователей, поэтому будем выделять несколько сущностей, отображающих людей, взаимодействующих с ЭД. Первая сущность «Пользователь» это все пользователи библиотеки. Указанная сущность должна содержать информацию об уникальном идентификаторе пользователя в системе (пара «логин пароль»), информацию о правах или ролях пользователя, а также некоторые другие атрибуты, связанные с пользователями системы. В зависимости от назначенной роли пользователь может управлять ИР внутри коллекции (добавление/измеиение/удаление документов), а также выполнять поиск по коллекциям. Таким образом, данная сущность связана с ИР связями «многие-ко-многим».
Помимо простых пользователей у ЭБ. как и у любой информационной системы, должен быть технический персонал, который занимается поддержкой и развитием системы администраторы БД. проектировщики, системные администраторы. Совершенно ясно, что простому читателю и. например, администратору системы должны предоставляться совершенно разные функционалы. Помимо этого существуют люди, которые не не имеют отношения к управлению функционированием системы, но могут и должны серьезно влиять на качество предоставляемых услуг. Поэтому создадим еще одну сущность «Технический персонал». Она содержит служебные данные об администраторах системы и другом обслуживающем персонале, информацию о роли пользователя и правах доступа. Помимо управления коллекциями и документами администратор должен управлять всей ЭБ и ее пользователями. Таким образом, возникают связи «один-ко-многим» с сущностями «Пользователь». «ЭК». «ЭД».
Каждый человек, взаимодействующий с ЭБ. по сути является пользователем ЭБ. Представим всех пользователей, взаимодействующих с системами ЭБ. следующими четырьмя различными категориями: конечные пользователи ЭБ. редакторы ЭБ. каталогизаторы ЭБ и управляющий персонал ЭБ (администраторы, разработчики компоненты и т. п.).
Конечные пользователи ЭБ используют функциональные возможности ЭБ для получения доступа к содержанию и его использования. Они воспринимают ЭБ как объект, сохраняющий состояние и удовлетворяющий их функциональные потребности. Режим работы и продукция ЭБ зависят от ее состояния в то время, когда активизирована специфическая часть ее функциональных возможностей.
Состояние ЭБ соответствует состоянию ее ресурсов, которые образованы электронными коллекциями информационных объектов (которыми управляет ЭБ).
групп уполномоченных пользователей и функциональных возможностей ЭБ. Это состояние изменяется в течение всего времени существования ЭБ согласно функциональным возможностям, активизированным пользователями.
Эти пользователи потребляют все доступные ресурсы ЭБ благодаря ее функциональным возможностям, обеспечиваемым электронной библиотекой в соответствии с правилами доступа и в надлежащем качестве, которое гарантируется электронной библиотекой.
Каталогизаторы ЭБ это производители содержания ЭБ. ресурсов, главным образом информационных объектов коллекций, к которым будет доступ у других пользователей ЭБ. Предполагается, что подобные пользователи достаточно хорошо знакомы с предметной областью создаваемых ресурсов и с требованиями, предъявляемыми ЭБ к информационному объекту, чтобы создать квалифицированное описание информационного объекта (ИО).
Иногда (например, в случае самокаталогизации) каталогизаторами могут выступать практически любые пользователи ЭБ. например, авторы монографий, размещаемых в ЭБ. Однако даже хорошо описанный ресурс требует проверки специально подготовленными сотрудниками для исключения неточностей и ошибок.
Редакторы, ЭБ это пользователи, отвечающие за содержание ЭБ. Фактически редакторы должны курировать все ресурсы, формирующие ЭБ. Редактор принимает окончательное решение об опубликовании электронных документов, коллекций ЭД, проверяет корректность их описаний, соответствие их тем или иным стандартам. Иными словами, редактор формирует информационное наполнение ЭБ. вырабатывает политики доступа и представления ИР конечным пользователям.
Безусловно, редактор это наиболее квалифицированный человек среди всех пользователей, он использует свое знание предметной области для того, чтобы определить, настроить и обслуживать электронную библиотеку таким образом, чтобы соединить информацию и функциональные потребности потенциальных пользователей ЭБ.
Технический персонал (администраторы) ЭБ. Под техническим персоналом будем понимать множество пользователей, которые выполняют различные специальные роли, необходимые для поддержания работоспособности системы, а также для развития ее технических возможностей. Как правило, подобные пользователи должны иметь максимально полные права доступа к информационным ресурсам ЭБ. хотя и могут выполнять принципиально разные задачи, поэтому логично было бы объединить их в рамках одиого сценария или роли. Выделим некоторые особенности данной группы пользователей. Функционально весь технический персонал ЭБ можно поделить на три группы. Это проектировщики ЭБ. системные администраторы и разработчики приложений ЭБ.
Проектировщики ЭБ. Главная задача проектировщика ЭБ создание (настройка. изменение) структуры, эффективно соединяющей в себе ИР ЭБ и удовлетворяющей потребностям потенциальных пользователей ЭБ. Для реализации поставленной задачи проектировщики взаимодействуют с системой управления ЭБ. обеспечивая оптимальные функциональные параметры и параметры конфигурации контента. Под функциональными параметрами будем понимать настройки, влияющие на представление функциональных возможностей ЭБ конечному пользователю системы. Параметры конфигурации контента определяют представление ресурсов третьей стороны, используемых ЭБ, например, хранилища данных, онтологии, схемы классификации, нормативные файлы и географические справочники, которые будут использоваться для того, чтобы сформировать информационное наполнение ЭБ. Значения этих параметров формируют способ представления ЭБ конечному пользователю.
Системные администраторы ЭБ настраивают компоненты программного обеспечения. необходимые для построения ЭБ как информационной системы. Выбор компонент должен отражать ожидания конечных пользователей и проектировщиков ЭБ. а также учитывать доступные ресурсы для создания ЭБ. Системные администраторы ЭБ взаимодействуют с системой управления ЭБ. задавая архитектурные параметры конфигурации, такие, как выбранные компоненты программного обеспечения или узлы хостинга. Ilx задача состоит в том. чтобы создать архитектурную конфигурацию для ЭБ и обеспечить высший уровень качества обслуживания пользователей.
Разработчики приложений ЭБ разрабатывают компоненты программного обеспечения, которые будут использоваться как элементы системы ЭБ для обеспечения доступа к соответствующим функциональным возможностям.
Информационные объекты, прежде чем стать полноценной частью ЭБ. должны пройти несколько стадий опубликования. Опишем жизненный цикл ИР.
Автор создает новый документ создается пустой документ, содержащий метаданные нового ИР. он получает статус «Предварительное описание». Далее производится загрузка электронного документа и таким образом создается первичный ИР. Каталогизатор проверяет корректность описания ИР. а также соответствие самого документа и его описания требованиям библиотеки, предъявляемым к электронным ресурсам. Если качество документа неудовлетворительное, то каталогизатор может вернуть документ автору, если же качество ИР удовлетворительное. то ИР присваивается статус «Публичный черновик», при этом может быть проведена необходимая доработка метаданных. После того как документ получил статус «Публичный черновик», он проверяется редактором и при удовлетворительном результате получает статус «Опубликованный». С этого момента к документу предоставляется публичный доступ, и он становится полноценным элементом электронной коллекции. В противном случае документ возвращается на предыдущие шаги или вовсе удаляется из коллекции.
Администратор ЭБ создает архивные копии ИР. фиксирует формат их представления. контрольные суммы, месторасположение и т. п.. а также при необходимости управляет коллекциями и любыми документами в ЭБ.
2. Двухуровневая структура программного обеспечения для ЭБ
Учитывая текущие тенденции развития СУБД и распространенность реляционных БД (РБД). мы предлагаем реалнзовывать полученную ннфологнческую модель с помощью РБД. Отмстим в этой связи, что РБД являются в настоящее время наиболее распространенным способом долговременного хранения информации.
Для быстрой и корректной работы инфологичсская модель БД должна быть приведена к нормальной форме. Технические моменты преобразования инфологи-чсской модели в нормальную форму и создания реляционной модели БД в настоящей статье оставим без рассмотрения, поскольку известны однозначные алгоритмы таких преобразований.
Примеры реализаций подобных электронных хранилищ существуют на практике. однако такие системы, как правило, являются строго вертикально выстроенными системами для хранения и управления сложными электронными объектами со строго определенным пользовательским интерфейсом (например. DSpace www.dspacc.org. cPrints www.cpririts.org. Greenstone www.grccnstonc.org). Мы же предлагаем другой подход, который представляется нам более универсальным.
При внедрении уже созданных систем электронных архивов (DSpacc. cPrints и пр.) или близких аналогов обычно требуется создание внутренней БД описаний
ПОЛЬЗОВАТЕЛИ
УроЕЩЛЬ библиотеки
Уровень толвеяции
Рис. 2. Логическая структура системы
электронных документов. Если организация планирует внедрение такой системы с нуля, без какого-либо значимого программного обеспечения (ПО) учета и поиска электронных документов, без имеющегося каталога электронных документов, то существующие разработки в таком случае подходят. Более того, можно утверждать. что они могут предоставить более полный функционал или более стабильную сборку ПО.
При условии, что в организации уже существуют разнородные ЭК. на этапе внедрения новой, пусть более мощной, но строго вертикально выстроенной системы для хранения и управления сложными электронными объектами в лучшем случае придется проводить работу по конвертации формата существующих БД электронных коллекций в формат этой системы. В худшем же случае это повлечет за собой создание всех коллекций заново, что приведет фактически к двойной работе и лишним трудозатратам. Поэтому мы предлагаем следующую логическую структуру ПО ЭБ.
Условно поделим все ПО для ЭБ на две части (см. рис. 2) уровень коллекции и уровень электронной библиотеки в целом. На уровне коллекции формируется ПО для отдельно взятой коллекции IIP. на уровне библиотек производится объединение всех ЭК в одно целое.
2.1. Уровень электронной коллекции. Рассмотрим уровень электронной коллекции подробнее и перечислим требования к ПО коллекций:
• каждая коллекция может иметь свои профиль метаданных и лингвистическое
обеспечение:
•
таданных этой коллекции, с использованием списков подстановок и авторитетных
файлов, что обеспечивает высокую релевантность поиска:
•
для этого структура метаданных коллекций описывается на формальном машиночитаемом языке (например, с использованием XML Schema), причем первичный вариант структуры создается до формирования самой электронной коллекции: на основе созданного машинного описания структуры метаданных генерируется вся программная система: экранные формы, таблицы баз данных, поисковая система и т. д.:
• процесс формирования коллекций - итерационный [6], поскольку провести качественный анализ всего материала для создания структуры метаданных перед формированием электронной коллекции не всегда представляется возможным: в процессе же создания коллекции в структуру метаданных могут вноситься уточнения. поэтому необходимо наличие ПО корректировки машиночитаемого описания профиля и списков подстановок атрибутов.
Более полное обоснованно и требования к ПО ЭК можно найти в [6 8]. В качество инструмента описания будем использовать XML Schema, обоснование подобного выбора содержится в [7].
Указанные выше требования позволят создать ПО для отдельных электронных коллекций, разнородных по своему содержанию. Однако эти требования не учитывают необходимости объединения всех коллекций в единую ЭБ. Таким образом, любые ЭК. построенные в соответствии с указанными требованиями, должны также включать в себя точки входа для трансляции поискового запроса с уровня ЭБ и передачи обратно результатов этого запроса. Учитывая, что все коллекции, входящие в ЭБ, должны соответствовать единой спецификации, то есть предоставить единые точки входа, логично представлять их в виде независимых сервисов.
2.2. Уровень библиотеки. На уровне ЭБ также должен быть реализован сервис, главной целыо которого являются одновременная трансляция одного и того же поискового запроса ко всем коллекциям и сбор результатов этого запроса. Разумеется, подобный сервис должен представлять инструментарий для управления точками входа в ЭК, добавления и изменения ЭК в библиотеке, управления пользователями ЭБ. Следовательно, информационная система (НС) ЭБ имеет сервис-ориентированную архитектуру, а, учитывая, что подобная система тесно связана с всемирной паутиной, разработка системы сводится к разработке набора различных веб-сервисов.
Поиск по библиотеке должен проводиться на основе единого коммуникативного формата метаданных (например, Dublin Core): формы описания ресурсов коллекций могут отличаться, поэтому там, где это необходимо, должна быть создана система конвертации метаданных коллекций в коммуникативный формат и обратно.
Помимо трансляции запроса должна быть предусмотрена возможность перо-хода к поисковым формам отдельных коллекций. Такой веб-сервис является своего рода единой точкой входа в ЭБ, при необходимости предоставляющей переход к более узконаправленным частям системы, каковыми являются отдельные коллекции. Логика работы подобной системы сводится к достаточно простому алгоритму (сценарий поиска документов рассмотрен на рис. 3).
Пользователь получает доступ к головному сервису ЭБ. Если он представляет, к какой конкретно коллекции принадлежит интересующий его документ, то он может сразу перейти к поисковой системе отдельно взятой коллекции и далее работать с ПО ЭК. Если пользователю неизвестна принадлежность ЭД к конкретной коллекции или документ может состоять в нескольких коллекциях, то он имеет возможность произвести общий поиск по всем коллекциям. В этом случае головной веб-сервис транслирует поисковый запрос ко всем ЭК, используя описанные точки входа к каждой коллекции. Так как все коллекции имеют строго определенные точки входа, результат поиска тоже будет передан головному сервису в едином коммуникативном формате. После просмотра полученных результатов пользователь может перейти к более подробному отображению результатов в рамках отдельной коллекции. Если же документ не содержится внутри ЭБ, то пользователю предоставляется возможность поиска в других хранилищах, поисковый запрос также может транслироваться по различным протоколам (например, Z39.50, SRU/SRW) к другим хранилищам или каталогам АБИС.
Рис. 3. Сценарий поиска ИР
Реализация системы ЭБ как набора веб-сервисов имеет еще одно приомущоство. Как уже отмечалось выше. ЭБ должна рассматриваться как часть всей ИС вуза, поэтому при разработке системы ЭБ надо предусматривать возможности связи ее с другими частями ИС. Использование технологии веб-сервисов при реализации данной системы, на наш взгляд, может значительно упростить задачу взаимосвязи между частями ИС вуза.
Заключение
Построенная инфологичоская модель системы управления ЭБ вуза учитывает специфику последнего, однако, на наш взгляд, вполне может быть применима для создания любой системы, объединяющей разнородные электронные коллекции. Предусматривается двухуровневая структура ПО для ЭБ. Разделение на уровни, как нам представляется, позволяет наряду с созданием новых компонент системы задействовать уже готовые решения, которые могут быть использованы в качестве независимых модулей системы ЭБ.
На базе данной модели создано ПО для некоторых электронных коллекций Научной библиотеки Казанского университета [7]. реализован модуль связи с внешними ЭК по протоколу 239.50 [3].
Поскольку веб-сервисы это реализация абсолютно четких интерфейсов обмена данными между различными приложениями, которые могут быть написаны не только на разных языках, но и распределены на разных узлах всемирной паутины, создание головного поискового сервиса ЭБ позволит объединять коллекции, сформированные с помощью любого ПО. в том числе и посторонних разработчиков.
Таким образом, прежде сильно интегрированные обособленные системы электронных архивов и обособленные разработки систем ЭБ трансформируются в набор отдельных модулей и сервисов, которые могут быть гибко объединены в различные многофункциональные системы.
Summary
А. С. Abrosimov, D.S. Zuev. The Entity-relationship Model of a Scientific Educational Digital Library at a Higher Educational Institution.
The article regards the entity-relationship model as well as the principles of developing the software for a digital library at a higher educational institution. An approach is proposed for combining heterogeneous digital collections into a library 011 the basis of web-service technology.
Key words: digital library, digital collections, entity-relationship modeling.
Литература
1. Арме В. Электронные библиотеки / Пер. с англ. М.: ПИК ВИНИТИ, 2001. 276 с.
2. Абросимов А.Г., Зуев Д.С. Научпо-образовательпая электронная библиотека вуза // Электронные библиотеки: перспективные методы и технологии, электронные коллекции: Тр. 10-й Всерос. науч. копф. "RCDL'2008" (Дубна, Россия, 7 11 окт. 2008 г.). Дубна: ОИЯИ, 2008. С. 374 379.
3. Абросимов А.Г., Зуев Д.С. Электронная коллекция информационно-образовательных ресурсов КРУ // 12-я Межд. копф. и выставка Libcom-2008 «Информационные технологии, компьютерные системы и издательская продукция для библиотек»: Докл. и тез. докл. М.: ГПНТБ России, 2008. URL: http://www.gpntb.ru/ libcom8/disk/2.pdf.
4. Чей П. Модель «сущность-связь» шаг к единому представлению о данных // СУБД. 1995. Л» 3. С. 137 158.
5. Иванов Д.Н. Основы реляционных баз данных. Барнаул: Изд-во Алт. ун-та, 2005. 125 с.
6. Абросимов А.Г. Метаданные описания коллекции периодической печати // Электронные библиотеки: рос. пауч. электронный журп. 2005 Т. 8, Вып. 2. URL: http://www.elbib. ru/iiulex. phtml?page=elbib/rus/jouriml2005/part. 2/Abrosimov, свободный.
7. Абросимов А.Г., Зуев Д.С. Принцип построения программного обеспечения электронной коллекции периодической печати // Актуальные проблемы современной пауки: Тр. 3-го Межд. форума (8-й межд. копф. молодых ученых и студентов). Естественные пауки. Ч. 1, 2: Математика. Математическое моделирование. Самара: Изд-во СамГТУ, 2007. С. 78 83.
8. Абросимов А.Г., Кузьмина В.Ю., Салосина И.И. Применение фасетпой классификации для систематизации газетных публикаций в электронной коллекции казанской периодической печати 19-го начала 20-го веков // Электронные библиотеки: рос. пауч. электронный журп. 2006. Т. 9, Вып. 1. URL: http://www^lbib.ru/iiulex.phtml?page=elbib/rus/ journal/2006/part.9/Abrosimov, свободный.
Поступила в редакцию 06.05.09
Абросимов Андрей Георгиевич кандидат педагогических паук, заместитель начальника отдела информатизации Казанского государственного университета. Е-шаП: agaQksu.ru
Зуев Денис Сергеевич аспирант НИИММ им. И.Г. Чеботарева Казанского государственного университета. Е-шаП: dzuevQksu.ru
