Автоматизированная библиотечно

Автоматизированная
библиотечно-информационная
система
Руслан
®
Сервер «Руслан» Версия 2.16.x
АРМ Администратора Версия 1.8.x
РУКОВОДСТВО АДМИНИСТРАТОРА
Версия 2.3.3
2008
Авторы: Владимир Баранов, Дмитрий Сова
СОДЕРЖАНИЕ
Введение.......................................................................................................................5
Техническая поддержка..............................................................................................7
Термины.......................................................................................................................9
1. Описание интерфейса АРМа Администратора..................................................11
2. Настройка схемы данных «Руслан»....................................................................17
2.1. Настройка источников библиотечных данных...........................................17
2.2. Настройка таблиц индексирования MARC-записей...................................21
2.3. Настройка точек доступа к MARC-записям................................................26
2.4. Обновление схемы данных «Руслан»...........................................................31
3. Настройка сервера «Руслан»................................................................................33
3.1. Настройка параметров сервера «Руслан»....................................................33
3.2. Настройка работы справочников..................................................................37
3.3. Загрузка и активизация справочника...........................................................40
3.4. Добавление нового справочника..................................................................41
4. Управление пользователями................................................................................43
4.1. Операции над группами прав доступа.........................................................46
4.2. Операции над пользователями......................................................................49
5. Управление библиотечными базами данных.....................................................53
5.1. Создание библиотечных БД организации...................................................55
5.2. Редактирование параметров библиотечных БД организации...................58
5.3. Определение количественных показателей библиотечных БД.................60
5.4. Удаление библиотечной БД или данных из библиотечной БД.................61
5.5. Индексация/переиндексация библиографической БД...............................62
5.6. Анализ статистики для библиотечных БД...................................................65
5.7. Обновление точек доступа к библиографическим БД...............................66
5.8. Загрузка записей в библиотечные БД..........................................................67
5.9. Выгрузка записей из библиотечных БД.......................................................69
5.10. Установка начального номера генератора ключей записей
библиотечных БД..............................................................................................72
5.11. Просмотр записей в библиотечных БД......................................................74
5.12. Контроль дублетов в полях MARC-записей и служебных записей........76
5.13. Просмотр истории изменения библиографических записей и
восстановление удаленной или измененной записи......................................78
2
5.14. Пакетное изменение библиографических записей...................................83
6. Библиотечные технологии....................................................................................91
6.1. Работа с буферной базой...............................................................................91
6.2. Заимствование аналитики.............................................................................93
6.3. Настройка средств фоновой обработки библиографических записей.....97
6.4. Настройка средств фоновой обработки служебных записей...................103
6.5. Настройка экспорта и импорта данных для АСУ ВУЗа...........................107
6.6. Настройка сервера для поддержки процесса автоматизированной
книговыдачи....................................................................................................112
6.7. Настройка сервера для поддержки процесса контроля читателем
выданных на руки книг...................................................................................114
6.8. Настройка сервера для поддержки процесса сбора статистики
книговыдачи ...................................................................................................115
6.9. Настройка сервера для диспетчеризации электронного заказа документов
...........................................................................................................................117
6.10. Настройка сервера для поддержки процесса инвентаризации фонда. .121
7. Архивирование данных......................................................................................127
7.1. Архивирование средствами СУБД Oracle.................................................127
7.2. Архивирование средствами АРМа Администратора...............................130
7.3. Запуск процесса архивирования сервером «Руслан»...............................131
8. Перенос данных на другой компьютер.............................................................133
9. Обеспечение бесперебойной работы серверной части АБИС «Руслан».......135
10. Управление лицензиями...................................................................................143
11. Мониторинг и управление работой сервера «Руслан»..................................145
11.1. Перегрузка параметров сервера................................................................145
11.2. Анализ текущего состояния сервера........................................................146
11.3. Просмотр подключенных к серверу пользователей...............................148
11.4. Просмотр перечня известных серверу библиотечных БД.....................151
11.5. Анализ соединений к физической базе данных......................................154
11.6. Анализ статистики работы сервера..........................................................157
Приложения.............................................................................................................163
Приложение 1. Диагностические сообщения сервера «Руслан»........................165
Приложение 2. Теги служебных баз данных........................................................167
Приложение 3. Формат обмена для служебных баз данных..............................169
3
Приложение 4. Формат запроса.............................................................................171
4
Введение
Данное руководство предназначено для администратора автоматизированной библиотечно-информационной системы (АБИС) «Руслан».
АБИС «Руслан» состоит из клиентской и серверной частей. Серверная
часть состоит из сервера «Руслан» и автоматизированного рабочего места
(АРМа) Администратора. Клиентская часть представляет собой набор целевых
библиотечных модулей (АРМов), которые взаимодействуют с сервером «Руслан» по протоколу Z39.50.
Сервер «Руслан» является ядром АБИС «Руслан» и поддерживает три интерфейса:
➔
Z39.50 – для взаимодействия с библиотечными АРМами и Z39.50-клиентами других производителей;
➔
Oracle® Net Services (Net8) – для взаимодействия с хранилищем данных на
базе СУБД Oracle®;
➔
Microsoft® DCOM – для взаимодействия с АРМом Администратора.
АРМ Администратора (в дальнейшем АРМ) предназначен для управле-
ния библиотечными данными в СУБД Oracle® и сервером «Руслан». Самостоятельного значения (вне серверной части АБИС «Руслан») АРМ не имеет.
В руководстве содержится описание интерфейса и возможностей АРМа
Администратора для решения задач настройки, управления и мониторинга
АБИС «Руслан».
5
6
Техническая поддержка
Техническая поддержка осуществляется ООО «Балтиксофт».
Сайт компании: www.balticsoft.ru
Электронная почта: ruslan@balticsoft.ru
7
8
Термины
Администратор
«Руслан»
АБИС - сотрудник организации, владеющий административным входом (имя администратора-владельца источника служебных данных и его пароль) и решающий административные задачи,
в том числе настройка системы. Администратор может владеть также системным входом в
базу данных (БД). Администратор может удалить (безвозвратно) любые данные организации, а будучи и системным оператором БД –
любые данные этой БД!
СУБД
- система управления базами данных.
База данных (БД)
- физическая база данных, т.е. база данных в том
понимании, как ее рассматривает СУБД. Термин
БД может применяться и для обозначения логических баз данных, что будет следовать из контекста.
Логическая БД
- набор таблиц, триггеров и т.п. в физической БД.
Библиотечная БД
- логическая БД, которая может быть библиографической либо служебной.
Библиографическая БД
- библиотечная БД, предназначенная для хранения
MARC-записей.
Служебная БД
- библиотечная БД, которая содержит записи, состоящие из произвольных полей (идентифицируемых тегами) с учетом экземплярности.
Область хранения
(tablespace)
- именованная совокупность файлов БД, которая
рассматривается как единое целое. В областях
хранения хранятся все данные, имеющие отношение к конкретной БД. Управляет областями хранения СУБД.
Источник служебных
данных (ИСД) (user
schema)
- специализированная логическая БД, владельцем
которой является пользователь СУБД, являющийся администратором АБИС «Руслан». ИСД
именуется следующим образом: <имя пользователя>@<имя БД>.
Источник библиотечных - набор логических БД, владельцем которых явданных (ИБД) (user
ляется пользователь СУБД и которые можно
9
schema)
рассматривать как единое целое при определенных операциях (например, архивирования). ИБД
именуется следующим образом: <имя пользователя>@<имя БД>.
LOB (Large Object)
- большой объект, текстовый или бинарный
(например, фотография, рисунок), обычно не индексируемый средствами СУБД
ТД
- точка(и) доступа – поисковый атрибут, представленный числом (1-9999)
Алиас
- псевдоним для БД
Таблица отката
10
Таблица, содержащая старые версии записей.
Старые версии записей не доступны по поиску из
АРМов. С ними можно работать только из АРМа
Администратора.
1. Описание интерфейса АРМа Администратора
Для запуска АРМа выберите ярлык «АРМ Администратора АБИС
'Руслан'» на рабочем столе или в меню задач в папке «АБИС Руслан».
Выберите из меню «Файл» команду «Новая сессия» (рис.1) или нажмите на иконку «Новая сессия» на панели инструментов (рис.2) или введите комбинацию клавиш Ctrl+N.
Рис. 1
Рис. 2
11
Появится диалоговое окно как на рис.3. В списке имеется два значения
для выбора: «RUSLAN-Database» и «RUSLAN-Server». Если выбрать в
списке первое значение («RUSLAN-Database») и нажать кнопку «OK», то
(после авторизации) откроется интерфейс взаимодействия (через Oracle® Net
Services (Net8)) со схемой данных «Руслан» (рис.5). Будем называть этот интерфейс в дальнейшем «RUSLAN-Database». Если выбрать в списке второе значение («RUSLAN-Server»), то откроется интерфейс взаимодействия (через
Microsoft® DCOM) с сервером «Руслан» (рис.7). Будем называть этот интерфейс
в дальнейшем «RUSLAN-Server».
Рис. 3
После выбора «RUSLAN-Database» появится диалоговое окно авторизации (рис.4). Если файл инициализации (см. АБИС «Руслан». Руководство по
установке) находится в рабочей папке и не поврежден, то два первых поля диалогового окна будут заполнены. В противном случае работа с АРМом Администратора невозможна. После того, как Вы введете пароль администратора и нажмете на кнопку «Выполнить», будет произведена авторизация в СУБД
Oracle. После авторизации будет создано соединение с источником служебных
данных (рис.5), в котором содержится схема данных «Руслан».
12
Рис. 4
Рис. 5
13
После выбора «RUSLAN-Server» появится диалоговое окно авторизации (рис.6). Введите сетевое имя компьютера (на котором запускается сервер
«Руслан»), имя пользователя на этом компьютере и пароль.
В случае, если компьютер входит в домен Microsoft, необходимо перед
именем пользователя добавить имя домена (например, MY_DOMEN\username).
Если АРМ запускается на том же компьютере, что и сервер «Руслан» и ОС –
Windows XP, то достаточно ввести в поле «Адрес сервера» localhost.
Если АРМ и сервер запускаются под Windows 2003 SP1/SP2 или Windows
Vista, но компьютер не входит в домен, то необходимо в поле «Адрес сервера» указать имя компьютера и также указать его перед именем пользователя
(например, MY_COMPUTER\username). Пароль вводить обязательно.
После авторизации будет создано соединение с сервером «Руслан»
(рис.7). В случае, если сервис сервера «Руслан» не запущен (см. АБИС
«Руслан». Руководство по установке), АРМ не сможет установить с ним соединение и появится сообщение об ошибке.
Рис. 6
Оба интерфейса («RUSLAN-Database» и «RUSLAN-Server») имеют похожий вид и делятся на три части. Слева расположено окно навигатора с объектами администрирования в виде дерева. Снизу расположено окно лога. Справа
14
расположено основное окно, в котором раскрывается содержимое объектов
администрирования (в большинстве случаев в виде таблицы). Вы можете изменять размеры частей интерфейсов. Все операции в интерфейсах выполняются с
помощью контекстных меню. Для вызова контекстного меню щелкните правой
клавишей мыши.
Рис. 7
При переходе в окне навигатора от одного объекта к другому АРМ автоматически проверяет, были ли сделаны изменения в содержимом объектов.
Если АРМ считает, что были сделаны изменения (в некоторых случаях реальных изменений может и не быть), то он выдает сообщение «Возможно, параметры были изменены. Сохранить изменения?». Можно сохранить изменения или отказаться от сохранения по Вашему усмотрению. Если
Вы уверены, что не делали изменений, то лучше отказаться.
15
16
2. Настройка схемы данных «Руслан»
В данном разделе описываются операции по настройке схемы данных
АБИС «Руслан» в СУБД Oracle. Схема данных состоит из набора таблиц, хранящих список ИБД, таблицы параметров сервера «Руслан», таблицы индексирования MARC-записей, списки точек доступа к MARC-записям, данные по
безопасности, а также обслуживающих их процедур.
Настройка схемы данных производится из интерфейса «RUSLANDatabase» (см. п.1).
2.1. Настройка источников библиотечных данных
Настройка ИБД заключается в их регистрации или де-регистрации, а также в изменении их параметров: пароля владельца источника и количества соединений, которые сервер «Руслан» устанавливает с СУБД.
Регистрация источника библиотечных данных
Эта операция необходима для того, чтобы ИБД, созданный в процессе
установки (см. АБИС «Руслан». Руководство по установке), стал известен
АБИС «Руслан». В нормальной ситуации при создании ИБД происходит автоматическая регистрация. Однако, по тем или иным причинам (сбой системы,
случайная ручная де-регистрация) может потребоваться выполнение данной
операции вручную.
Для регистрации ИБД выберите в окне навигатора объект «Источники
данных» и в основном окне вызовите из контекстного меню команду «Новый»
(рис.8). В основном окне в таблице появится новая строка с наименованием
«Новый источник». Два раза щелкните левой клавишей мыши на этой строке. Появится диалоговое окно редактирования параметров источника (рис.9).
17
Рис. 8
Рис. 9
18
Введите требуемые параметры (см. пример на рис.10) и нажмите кнопку
«Выполнить». В поле «Количество соединений» задается количество соединений, которое будет устанавливать сервер «Руслан» с данным ИБД. Количество соединений определяет какое количество операций с ИБД может выполняться параллельно. Если Вы не уверены, то поставьте количество соединений,
равное трем. Если Вы ввели неправильные параметры источника, их можно
снова отредактировать. Если Вы зарегистрировали лишний источник, то его
можно удалить командой контекстного меню «Удалить». После того как все
требуемые источники будут зарегистрированы, вызовите из контекстного меню
команду «Сохранить». Если Вы хотите отменить все изменения, то вызовите
из контекстного меню команду «Восстановить».
Рис. 10
19
Зарегистрированные источники можно увидеть, если раскрыть в окне навигатора объект «Источники данных» (см. рис.11).
Рис. 11
Де-регистрация источника библиотечных данных
Эта операция исключает ИБД из перечня источников, известных АБИС
«Руслан». В нормальной ситуации при удалении ИБД происходит автоматическая де-регистрация. Однако, по тем или иным причинам (сбой системы) может
потребоваться выполнение данной операции вручную.
Для регистрации ИБД выберите в окне навигатора объект «Источники
данных» и в основном окне выберите ИБД, который требуется де-регистрировать. Из контекстного меню выберите команду «Удалить». Появится подтверждение операции. Если операцию подтвердить, то указанный ИБД исчезнет из
перечня. Для окончательного выполнения операции вызовите из контекстного
меню команду «Сохранить». Операцию можно отменить, если вызвать из
контекстного меню команду «Восстановить».
Изменение параметров ИБД
Возможно изменение двух параметров зарегистрированного ИБД: пароля
владельца ИБД и количества соединений, которое сервер «Руслан» устанавливает с ИБД. Количество соединений определяет какое количество операций с
20
ИБД может выполняться параллельно. Можно также изменить имя владельца
источника, однако это фактически будет означать регистрацию нового ИБД.
Для изменения параметров ИБД два раза щелкните левой клавишей
мыши на строке с описанием требуемого ИБД. Появится диалоговое окно редактирования параметров источника (рис.10). Для изменения пароля введите
пароль дважды в соседних полях. Для сохранения изменений нажмите кнопку
«Выполнить». Далее можно отредактировать параметры другого ИБД. Для
фиксации произведенных изменений вызовите из контекстного меню команду
«Сохранить». Для отмены всех проведенных изменений вызовите из
контекстного меню команду «Восстановить».
2.2. Настройка таблиц индексирования MARC-записей
Для добавления, удаления или редактирования таблиц индексирования
выберите в окне навигатора объект «Индексирование» и в основном окне
вызовите контекстное меню (рис.12). Команда «Новый» создает новую (пустую) таблицу индексирования. Команда «Изменить» вызывает диалоговое
окно редактирования выбранной таблицы индексирования (рис.13). Эту же команду можно вызвать двойным щелчком левой клавишей мыши. Команда
«Удалить» удаляет выбранную таблицу индексирования. Команда «Сохранить» сохраняет все сделанные изменения во всех таблицах индексирования.
Команда «Восстановить» отменяет все сделанные изменения во всех таблицах индексирования. Команда «Загрузить» загружает таблицы индексирования из текстового файла. После загрузки для сохранения таблиц индексирования необходимо выполнить команду «Сохранить». Команда «Выгрузить»
выгружает таблицы индексирования в текстовый файл.
Каждая таблица индексирования имеет идентификатор-число, комментарий и собственно описательную часть, в которой содержится описание, каким
образом индексировать поля MARC-записи.
21
Рис. 12
Рис. 13
22
Описательная часть в диалоговом окне редактирования таблицы индексирования (рис.13) раскрывается в виде таблицы для удобства работы с ней.
Контекстное меню содержит команды: «Добавить» – для добавления нового
правила индексирования в конец таблицы, «Вставить» – для вставки правила
индексирования перед выбранным, «Удалить» – для удаления правила индексирования. Для редактирования ячейки таблицы щелкните на ней левой клавишей мышки. Каждое правило индексирования занимает одну строку таблицы.
Порядок следования правил имеет значение: при индексировании MARC-записи таблица индексирования (описательная часть) просматривается сверху вниз
для каждого поля (подполя) записи и при удовлетворении поля очередному
правилу индексирования происходит индексирование в соответствии с этим
правилом, таблица дальше не просматривается. Правило индексирования состоит из трех атрибутов: шаблона поля, шаблона подполя и типа индексирования. Шаблон поля состоит из трех символов-цифр. Шаблон подполя состоит из
одного символа, которым может быть либо цифра, либо буква английского алфавита в нижнем регистре. Также, при задании шаблона поля или подполя прочерк (знак «минус») означает любой символ. Например, шаблон поля в виде
«02-» означает «все поля с 020 по 029». Тип индексирования состоит из двух
символов-цифр.
Доступные следующие типы индексирования:
➔
00 – не индексировать;
➔
01 – подполе-фраза: разбирает подполе на слова и обеспечивает возможность искать по слову, по списку слов и по фразе в пределах подполя;
➔
11 – поле-фраза: разбирает подполе на слова и обеспечивает возможность
искать по слову, по списку слов и по фразе в пределах поля (имеет смысл,
например для обеспечения поиска со структурой терма типа «нормализованное имя» для записей в формате RUSMARC);
➔
02 – как есть: убирает начальные и конечные пробелы, остальное рассматривается как слово, обеспечивает возможность поиска по слову;
23
➔
03 – ISBN: специальный тип индексирования для подполей, содержащих
ISBN или ISSN;
➔
4X – кодированное поле: обеспечивает возможность индексирования кодированных полей и их частей как слов. В шаблоне подполя указывается начальная позиция индексируемого элемента, а символ X содержит длину индексируемого элемента в символах. Позиция и длина задаются одним символом, при этом числу 10 соответствует символ «a», числу 11 – символ «b», ...,
числу 35 – символ «z»;
➔
05 – числовой диапазон: в подполе выделяются только числовые элементыслова, раскрывается символ диапазона (знак «минус»), т.е., например, в подполе с содержимым «N5, 6-9» будут проиндексированы элементы (слова)
«5», «6», «5», «7», «8», «9»;
➔
06 – УДК: специальный тип индексирования для подполей, содержащих
УДК. При индексировании разделителем считается скобка, точка разделителем не считается;
➔
07 – поле-ссылка: специальный тип индексирования для RUSMARC-полей,
содержащих встроенные поля. При этом сами встроенные поля индексируются по правилам, определенным для не-встроенных (обычных) полей.
Встроенное 200 поле индексируется, если первый индикатор для этого поля
не равен нулю;
➔
08 – оптимизация 999 полей: используется для ускорения процесса индексирования полей (999-ых в АБИС «Руслан»), содержащих учетную информацию. Правило ставится в начале таблицы индексирования. При этом шаблон
поля содержит «асс», шаблон подполя - «-»;
➔
09 – инвентарный номер: специальный тип индексирования для полей (подполей), содержащих инвентарные номера. При этом инвентарный номер
должен состоять из трех элементов, разделенных символом-разделителем
(«-», «\», «/» и т.п.).
24
Все индексируемые элементы (слова) индексируются как лексограммы
(сравниваются в лексикографическом порядке), а также и как числа (сравниваются в числовом порядке), если они состоят целиком из символов-цифр (с возможным знаком «минус» в начале).
Существуют следующие специальные значения шаблона поля: «000» –
маркер (тип индексирования всегда – 4X), «acc» – включение оптимизации
999-полей RUSMARC-а (тип индексирования всегда – 08), «key» – внутренний
ключ записи – обязательный элемент таблицы индексирования, за исключением случаев переиндексирования части полей (шаблон подполя всегда – «-», тип
индексирования всегда – 02).
Для различных MARC-форматов может потребоваться различные типы
индексирования для одних и тех же шаблонов полей и подполей. С каждой
библиографической БД связывается одна таблица индексирования (которая может быть разбита на две при двух-фазовой схеме индексирования). Поэтому в
каждой библиографической БД могут находиться только записи определенного
MARC-формата.
Для уменьшения времени отклика системы на операции вставки и изменения библиографических записей в сервере «Руслан» предусмотрена двух-фазовая схема индексирования. При вставке/изменении MARC-записи из АРМов АБИС «Руслан» (за исключением АРМа Администратора) происходит
вставка/изменение записи и ее индексирование/переиндексирование в соответствии с таблицей индексирования для первой фазы. В случае успешного выполнения этих операций пользователю отсылается соответствующее сообщение и
сервер «Руслан» в фоновом режиме производит индексирование/переиндексирование MARC-записи в соответствии с таблицей индексирования для второй
фазы. Ошибки на второй фазе нигде не фиксируются, их можно обнаружить
только по неправильному поиску. Поэтому не рекомендуется индексировать во
второй фазе важные поля (подполя). Обычно на второй фазе индексируются
25
поля содержание большие объемы текста, например содержание документа, реферат, примечание и т.п.
2.3. Настройка точек доступа к MARC-записям
Точка доступа (ТД) – это число, однозначно связанное с поисковым атрибутом («Автор», «Заглавие» и т.п.). Точки доступа обеспечивают поиск как
библиографических (MARC), так и служебных записей в библиотечных БД
АБИС «Руслан». В АБИС «Руслан» можно настраивать точки доступа к библиографическим записям, т.е. определять, какие поля MARC-записей отображаются в какие точки доступа. Для каждого MARC-формата будет различное
отображение. С каждой библиографической БД связывается один набор (список) точек доступа. Поэтому в каждой библиографической БД могут находиться только записи определенного MARC-формата.
Каждый список ТД имеет числовой идентификатор. Обычно используются следующие идентификаторы (1 – UNIMARC, 10 – USMARC, 28 –
RUSMARC библиографический, 281 – RUSMARC авторитетный).
Рис. 14
Добавление нового списка точек доступа
Для добавления списка ТД выберите в окне навигатора объект «Точки
доступа» и вызовите контекстное меню. В контекстном меню вызовите ко26
манду «Добавить новый список ТД» (рис.14). Появится диалоговое окно,
в котором необходимо ввести идентификатор нового списка ТД (рис.15).
Рис. 15
Новый список появится в окне навигатора. Для работы со списком ТД его
надо выбрать в окне навигатора (рис.16).
Рис. 16
27
Работа со списком точек доступа
Любые действия со списком ТД выполняются в основном окне из
контекстного меню (рис. 17).
Рис. 17
Команда «Новый» создает новую точку доступа. Команда «Изменить»
вызывает диалоговое окно редактирования выбранной точки доступа (рис.18).
Эту же команду можно вызвать двойным щелчком левой клавишей мыши. Команда «Удалить» удаляет выбранную точку доступа. Команда «Сохранить»
сохраняет все сделанные с данным списком ТД изменения. Команда «Восстановить» отменяет все сделанные изменения с данным списком ТД. Команда
«Загрузить» загружает ТД из текстового файла в существующий список ТД.
После загрузки для сохранения списка ТД необходимо выполнить команду
«Сохранить». Команда «Выгрузить» выгружает ТД выбранного списка в
текстовый файл.
В дистрибутив АБИС «Руслан» входят списки ТД для UNIMARC (файл
ap1.txt), для USMARC (файл ap10.txt), для RUSMARC-а библиографического
(файл ap28.txt) и для RUSMARC-а авторитетного (файл ap281.txt).
Отображение MARC-полей/подполей в ТД (рис.18) описывается с помощью логического выражения, каждый терм которого выделяет один или
28
несколько
MARC-полей/подполей.
Структура
выражения
соответствует
предложению WHERE в SELECT-операторе языка SQL. Терм имеет вид:
field <op> '###A' или field in ('###A',...,'###A'), где
<op> – один из операторов: =,<>,>,<,>=,<=,like,not like (наиболее
часто используются = и like);
### – номер MARC-поля;
A – символ MARC-подполя соответствующего MARC-поля.
Рис. 18
Допускается вместо символа(ов) # или A использовать символ подчеркивание (_) для обозначения любого символа или символ процента (%) для
обозначения произвольного количества любых символов. Использовать символ
процента, а также операторы <> и not like (также like для Oracle Standard
29
Edition) не рекомендуется там, где можно обойтись перечислением с использованием выражения field in, поскольку это снизит скорость поиска. В случае
задания нескольких термов, допускается их объединение логическими операторами and, or и not and.
Для привязки поисковых атрибутов к позициям кодированных полей и
маркера используются псевдо-поля, как они определены в таблице индексирования (см. п.2.2, специальные значения шаблона поля), т.е. ### – шаблон поля,
A – шаблон подполя как в таблице индексирования.
Рис. 19
30
Удаление списка точек доступа
Для удаления списка ТД выберите в окне навигатора требуемый список,
выделите все атрибуты списка (выделите первый атрибут, нажмите клавишу
«Shift», выделите последний атрибут) и вызовите из контекстного меню команду «Удалить» (рис.19). Подтвердите операцию – из основного окна все
точки доступа удалятся (вид как на рис.17). Вызовите из контекстного меню
команду
«Сохранить».
Подтвердите
операцию.
Затем
вызовите
из
контекстного меню окна навигатора (рис.14) команду «Обновить». После этого идентификатор удаленного списка ТД исчезнет из окна навигатора.
ВНИМАНИЕ! Для применения изменений в списке точек доступа необходимо
их обновить для каждой библиографической БД, использующей данный список
(см. п.5.7).
2.4. Обновление схемы данных «Руслан»
Обновления схемы данных могут быть двух видов:
➔
простое обновление – обновление одного или нескольких (всего их три) пакетов хранимых процедур;
➔
сложное обновление – обновление структуры хранения данных, включая
возможное обновление самих данных.
Сложное обновление обычно поставляется как исполняемый файл про-
граммы-патча. Вместе с патчем поставляется документация по его применению.
Простое обновление поставляется в виде файлов с расширением plb
(обычно pkg_phbase.plb для базового пакета или pkg_phupd.plb для пакета расширенных сервисов или pkg_phutil.plb для пакета утилит).
Для выполнения простого обновления схемы необходимо из меню
«Файл» вызвать команду «Обновить схему БД» (рис.20). Появится стан-
31
дартное окно выбора файла, в котором необходимо выбрать файл с новым пакетом. В процессе обновления пакета появится и пропадет окно командной
строки. В случае успешного обновления в основном окне, при выборе объекта
«База данных 'Руслан'» (рис.5), должна быть отражена новая версия пакета. Данную процедуру следует повторить для всех файлов, входящих в обновление.
Рис. 20
Примечание. После проведения процедуры простого обновления схемы данных
возможно на некоторых операциях появление однократной некритической
ошибки при работе из АРМов АБИС «Руслан», связанной с изменением
контекста БД Oracle. Необходимо просто повторить операцию. Для исключения возможности появления ошибок рекомендуется перед обновлением схемы
данных остановить сервер «Руслан», а после проведения обновления снова его
запустить.
32
3. Настройка сервера «Руслан»
В данном разделе описываются операции по настройке сервера «Руслан»
АБИС «Руслан». Настройка сервера производится из интерфейса «RUSLANDatabase».
3.1. Настройка параметров сервера «Руслан»
Для добавления, удаления или редактирования параметров сервера выберите в окне навигатора объект «Параметры» и в основном окне вызовите
контекстное меню (рис.21). Каждый параметр состоит из трех элементов: наименования параметра, значения параметра и комментария. Длина каждого
элемента параметров не может превышать 255 символов.
Команда «Новый» создает новый параметр. Команда «Изменить» переводит ячейку таблицы, на которую указывает курсор, в режим редактирования.
Эту же команду можно вызвать щелчком левой клавишей мыши на ячейке
(если параметр выделен). Команда «Удалить» удаляет выбранный параметр.
Возможно удаление нескольких параметров или всех (при множественном выделении стандартным способом с использованием клавиш «Shift» и «Ctrl»).
Команда «Загрузить» загружает параметры из текстового файла. При этом
предполагается, что параметры еще не загружены (основное окно пустое). После загрузки для сохранения параметров необходимо выполнить команду
«Сохранить». Команда «Выгрузить» выгружает параметры в текстовый
файл. Команда «Загрузить со слиянием» предназначена для загрузки новой версии параметров из текстового файла (параметры уже были загружены).
После загрузки со слиянием для сохранения изменений также необходимо выполнить команду «Сохранить». Команда «Сохранить» сохраняет все параметры в БД. Команда «Восстановить» отменяет все сделанные с помощью
33
операций «Изменить», «Загрузить» или «Загрузить со слиянием» в параметрах
изменения (загружает параметры из БД).
Описание параметров приведено в поле комментарий. Более подробное
описание параметров, если это необходимо, содержится в отдельной документации или в разделах данного руководства. Большинство параметров изменять
не требуется и категорически не рекомендуется, поскольку может привести к
неработоспособности сервера «Руслан» или отдельных его сервисов.
Рис. 21
Создание нового параметра или загрузка нового файла параметров (операция «Загрузка со слиянием») достаточно редкие операции и выполняются по
указанию службы поддержки системы.
34
Существуют параметры, имеющие свои значения для каждой организации (библиотеки). При загрузке нового файла параметров эти параметры должны сохранить прежнее значение. Для автоматизации этого процесса предусмотрена операция «Загрузка со слиянием». В процессе выполнения этой операции,
при обнаружении старой версии значения параметра для каждого параметра
выдается диалоговое окно (рис.22), где администратору предлагается выбрать
старое или новое значение.
Рис. 22
Далее рассмотрим основные параметры сервера, которые потребуется изменять администратору после загрузки параметров из файла, входящего в дистрибутив серверной части АБИС «Руслан» (см. АБИС «Руслан». Руководство
по установке).
35
Всегда требуется изменять параметры OrgEng и OrgRus. Первый содержит название-аббревиатуру организации (библиотеки) на английском языке,
второй – на русском.
Параметры ActsDB, BillsDB, CircDB, DirsDB, OrderDB, QueueDB,
ReaderDB, ReaderADB, SubscrDB содержат имена служебных библиотечных
БД специального назначения. Если в процессе установки АБИС были созданы
библиотечные БД по умолчанию (см. АБИС «Руслан». Руководство по установке), то эти параметры изменять не следует. Если Вы создаете библиотечные
БД вручную, то Вы можете задать другие имена для БД, соответствующих этим
параметрам, нежели те, что предлагаются по умолчанию.
Параметр GroupDB позволяет задавать виртуальные (групповые) имена
для нескольких реальных библиотечных БД. Возможно задание нескольких
виртуальных имен. Формат значения поля приведен в комментарии к полю.
При этом на первом месте должно стоять виртуальное имя и далее, через запятую, имена реальных библиотечных БД, входящих в группу. Если Вы хотите
задать несколько групп, то отделите их описание точкой с запятой. Виртуальное имя может быть полезно при поиске. При поиске по БД с виртуальным
именем осуществляется поиск во всех БД, связанных с эти именем. Виртуальное имя удобно, например, использовать в настройках АРМа Читателя (HTTPZ39.50 – шлюза), поскольку при добавлении новой библиотечной БД в группу
не потребуется изменять настройки АРМа Читателя. Редактировать записи,
найденные в виртуальной БД, невозможно.
Параметр Scan содержит перечень поисковых атрибутов (см. документацию по протоколу Z39.50, набор поисковых атрибутов bib1), для которых будет поддерживаться сервис «Scan», т.е. сервис просмотра поисковых индексов.
В перечне поисковых атрибутов следует оставить только те атрибуты, которые
реально используются в данном сервисе. Поисковые индексы для ускорения их
просмотра загружаются в оперативную память. Количество занимаемой оперативной памяти зависит от количества поисковых атрибутов в параметре Scan,
36
от количества библиографических БД, для которых разрешен сервис «Scan», от
количества записей в этих библиографических БД, а также от количества
разных слов, которые могут содержать соответствующие поисковым атрибутам
поля библиографических записей.
Параметр DafLog управляет ведением файла лога взаимодействия с БД
Oracle (daf.log), который находится в рабочей папке АРМа Администратора (по
умолчанию C:/Program Files/Ruslan/SysAdmin) и в рабочей папке
сервера «Руслан» (по умолчанию C:/Program Files/Ruslan/Server).
По умолчанию параметр имеет значение «1». Это означает, что ведется файл
лога для АРМа и для сервера. Периодически, когда файлы станут большими, их
следует удалять. Если параметр установить в «0», то файлы лога не будут вестись. Файлы лога позволяют помочь с определением причины неполадок в системе или если система не обеспечивают определенную функциональность. В
случае проблем следует установить этот параметр в 1 и направить полученные
в результате работы АРМа и сервера «Руслан» файлы логов в службу поддержки системы.
3.2. Настройка работы справочников
Все справочники делятся на два типа. Первый тип (основной) – это справочники, которые служат для просмотра и выбора из них значений для вставки
в поля библиографической записи. В таких справочниках каждый элемент состоит из поискового термина и примечания к нему (может отсутствовать). Второй тип – это справочники специального назначения типа справочника генераторов инвентарных номеров.
Все справочники ведутся с использованием двух специализированных
служебных баз. Первая база, DDIR, содержит описание всех справочников в
системе. Данная база используется АРМами для формирования списков доступных справочников и организации доступа к ним. Вторая база, DIR (имя БД
может быть изменено, см. предыдущий пункт), содержит все справочники.
37
Каждый справочник имеет уникальный идентификатор. Зарегистрированные
справочники приведены в документации к АРМу Комплектования/Каталогизации. При заведении нового справочника следует согласовать его идентификатор со службой технической поддержки системы.
Каждый справочник состоит из набора записей во внутреннем формате
АБИС Руслан (см. Приложение 3). Рекомендуется, чтобы суммарный объем
всех справочников не превышал 200000 записей. Каждая запись справочника
состоит максимум из 3-х тегов: 5 (идентификатор справочника), 17 (термин) и
18 (примечание к термину). Значение под тегом 18 является не обязательным и
как правило используется для расшифровки терминов содержащих аббревиатуру или какой-либо код.
Для организации работы справочников второго типа следует:
1. Проверить, что созданы служебные БД DDIR и DIR. Если в процессе установки АБИС были созданы библиотечные БД по умолчанию (см. АБИС «Руслан». Руководство по установке), то данные БД должны присутствовать. В
противном случае их следует создать вручную (см. п.5.1).
2. Загрузить в БД DDIR описания справочников из прилагаемого к дистрибутиву файла ddir.dat (см. п.5.8) с опцией «Генерировать ключ записи».
Если необходимо добавить новый справочник, то необходимо получить его
идентификатор в службе поддержки системы и затем создать файл, подобный ddir.dat (который будет содержать описание только нового справочника) и загрузить его в БД DDIR. Подробнее см. в п.3.4.
3. Дать пользователям соответствующие права на БД DDIR и DIR (см. п.4).
Если данные БД были созданы по умолчанию, то для них также была создана
группа прав доступа gdir, которую необходимо дать пользователям, работающим со справочниками (в частности со справочником генераторов инвентарных номеров).
Для организации работы справочников первого типа дополнительно к
вышеперечисленным действиям следует:
38
4. Создать файл справочника в формате, описанном в Приложении 3 с тегами 5
(идентификатор справочника), 17 (термин), 18 (примечание термина). Подробнее см. в п.3.3.
5. Загрузить созданный в п.4 данного перечня файл в БД DIR (см. п.5.8) с опцией «Генерировать ключ записи».
6. Установить флаг «Скан по словам» для БД DIR (см. п.5.2).
7. Проверить параметры сервера (см. п.3.1). Они должны быть следующими:
ServiceDBScanFilterTag
5
ServiceDBScanFilterValue
должен содержать через запятую все идентификаторы справочников первого типа
ServiceDBScanTag
17
ServiceDBScanNoteTag
18
8. При изменении параметров, их необходимо в сервере перегружать (см.
п.11.1) или перезапускать сам сервер. После загрузки справочников из АРМа
Администратора, сервер также требуется перезапустить.
База DIR используется также для хранения справочника «Генератор инвентарных номеров». Данный справочник является специализированным и работа с ним выполняется только с использованием АРМа Комплектования/Каталогизации. Идентификатор данного справочника равен 200. Необходимо следить за тем что бы при работе с базой DIR не были случайно испорчены
данные справочника генератора инвентарных номеров.
Следует помнить, что справочники начинают загружаются через минуту
после старта сервера «Руслан» и этот процесс занимает определенное время, зависящее от мощности компьютера и объема справочников. После загрузки
справочников в EventViewer (Application Log) появляется соответствующее сообщение (рис.23) для каждой БД с установленным флагом «Скан по словам».
39
Рис. 23
3.3. Загрузка и активизация справочника
Активизация справочника заключается в добавлении идентификатора активизируемого
справочника
в
список
значений
параметра
сервера
ServiceDBScanFilterValue. Активизация означает разрешение работы со справочником из АРМов (справочник может быть описан в базе DDIR, загружен в
базу DIR, но если он не активизирован, то при попытке доступа к нему из АР40
Мов будет выдаваться диагностическое сообщение под номером 114). Допустима активация справочника без загрузки даных в базу DIR. В этом случает
данные можно заполнять «ручным» способом, используя возможности АРМов.
Перед загрузкой справочников в базу DIR предварительно необходимо
получить записи во внутреннем формате АБИС «Руслан». Для этого можно
воспользоваться специализированным конвертором доступным для пользователей АБИС «Руслан». Данный конвертор позволяет получить требуемый формат из данных размещенных в текстовом файле с символом табуляции в качестве разделителя колонок. Файл в таком формате можно получить, например,
сохранив данные из программы работы с электронными таблицами (например,
Microsoft Excel), указав типа файла «Текстовые файлы (с разделителями табуляции) (*.txt)». Указания по использованию конвертора можно получить, запустив его без указания параметров. Запись справочника должна содержать два
обязательных тега. Под тегом 5 должен быть указан идентификатор справочника, под тегом 17 должны быть собственно справочные данные. Под факультативным тегом 18 может содержаться примечание к справочным данным. Примечание используется для пояснения кодированных справочных данных
(например, справочник подразделений библиотеки).
Например, для получения файла с записями ключевых слов в требуемом
для АБИС «Руслан» формате необходимо запустить конвертор со следующими
параметрами:
lconv <входной_файл.txt> <выходной_файл.dat> 5=6
После загрузки записей справочника в базу DIR необходимо перестартовать
сервер.
3.4. Добавление нового справочника
Для каждого нового справочника необходимо запросить у разработчиков
АБИС «Руслан» новый идентификатор. Во избежание проблем совместимости
41
с будущими версиями АБИС, не рекомендуется заводить идентификатор самостоятельно.
Полный цикл добавления нового справочника включает в себя шаги по
настройке сервера «Руслан» и настройку АРМа (см. документацию на требуемый АРМ), в котором предполагается использовать справочник.
Последовательность шагов для добавления нового справочника на серверной части АБИС «Руслан»:
1. Убедиться, что в существующем списке, поставляемом в дистрибутив в виде
файла ddir.dat, нет подходящего справочника. Если есть, то использовать
его. Иначе запросить у разработчиков АБИС Руслан идентификатор нового
справочника.
2. Создать запись, описывающую новый справочник. Для этого можно взять
любую запись из файла ddir.dat и на ее основе создать новую запись в
отдельном файле. В записи необходимо поменять значения у двух тегов 5 и
4. Под тегом 5 содержится идентификатор справочника, под тегом 4 содержится название справочника.
3. Используя АРМ Администратора загрузить сформированную запись в базу
DDIR.
4. Выполнить инструкции п.3.3.
После выполнения данной последовательности действий доступ к справочнику возможен из любого АРМа.
42
4. Управление пользователями
В данном разделе описывается система безопасности АБИС «Руслан» в
части управления пользователями: создание и удаление пользователей, назначение им прав доступа и ролей.
Ключевыми понятиями при управлении безопасностью являются следующие понятия:
библиотечная БД (ББД)
- объект защиты
группа прав доступа
(ГПД, в дальнейшем
группа)
- именованная совокупность ББД, в которой с каждой ББД связаны определенные права на манипулирование данными в ней; пользователь, которому назначена ГПД, получает на ББД из этой
группы соответствующие права
функциональная группа
- неизменяемое символьное имя, связанное с определенной функциональностью системы; пользо(ФГ, в дальнейшем роль)
ватель, которому назначена ФГ, получает возможность использовать определенную функциональность в АРМе(ах) АБИС, т.е. может выполнять определенную роль (например, комплектование, каталогизация, администрирование печати
и т.п.)
пользователь
- любой человек, работающий с системой через
АРМы или Z39.50-клиенты третьих фирм
право доступа
- операция, которую может выполнять пользователь над ББД (над записями в ББД)
Выделены следующие права доступа:
Поиск (Search)
- право искать записи и просматривать часть полей записи (в будущих версиях будет настраиваться)
Извлечение (Present) - право просматривать полную запись
Вставка (Insert)
- право вставлять (создавать) новую запись
Изменение (Update) - право изменять запись
Удаление (Delete)
- право удалять запись
Заказ (Order)
- право обрабатывать заказы читателей данной библиотеки на документы из локального каталога (право делать заказы устанавливается из АРМа Книговыдачи)
43
МБА (ILL)
- право обрабатывать заказы по МБА
Перечень функциональных групп (не полный, подробнее см. в документации на АРМ Комплектования/Каталогизации):
compl
- дает привилегии по редактированию полей, требуемые для реализации функциональности комплектования
catal
- дает права, требуемые для реализации функциональности каталогизации
billcreator - дает право администрировать счета (создавать, изменять, удалять)
billdispatch - дает право изменять статус счета
printadmin - дает право администрировать службу печати
Перечень функциональных групп (ролей) задается параметром FGroups. Данный параметр может быть изменен либо в процессе обновления параметров
(см. п.3.1), либо по специальному указанию службы поддержки системы.
Рис. 24
Группа включает в себя одну или несколько ББД с указанием прав доступа к каждой ББД (рис.24). Одна или несколько групп могут быть назначены
пользователю. Пользователь получает права на некоторую ББД, если хотя бы в
одной из групп, назначенных ему, присутствует данная ББД. Если данная ББД
присутствует в нескольких группах, назначенных пользователю, и если права
44
на данную ББД различны в разных группах, то пользователь получает все права
установленные в той или иной группе (права из разных групп объединяются).
Пользователю также обычно назначается одна или несколько ролей, которые обеспечивают соответствующую функциональность АРМа(ов).
Для эффективного управления безопасностью требуется провести предварительное планирование. Необходимо определить перечень требуемых ББД
и сгруппировать права доступа к ним в определенные группы, которые затем
следует назначить соответствующим пользователям. Названия как ББД, так и
групп устанавливает администратор системы. Роли имеют предопределенные
названия (см. документацию на соответствующие АРМы). Если в процессе
установки АБИС были созданы библиотечные БД по умолчанию (см. АБИС
«Руслан». Руководство по установке), то также были созданы группы: gcompl
для комплектаторов, gcatal для каталогизаторов и gdir для работы со справочниками.
При установке системы заводится пользователь anonymous и ему назначается группа nobody. Данный пользователь может подключаться к серверу
«Руслан» без пароля. При создании каждой библиографической БД, она автоматически включается в группу nobody с правами Search и в группу library
с правами Search и Present. При создании каждой служебной БД, она автоматически включается в группу library с правами Search и Present. Группу
library следует давать всем пользователям АБИС. Таким образом автоматически обеспечивается доступ по поиску и полному просмотру всех БД зарегистрированным пользователям АБИС и доступ по поиску и частичному просмотру любым пользователям сети Интернет, которые могут подключаться
(под пользователем anonymous) к серверу «Руслан». Последнее определяется
сетевой политикой безопасности, специфичной для каждой организации. Если
удалить пользователя anonymous, то доступ к серверу «Руслан» будут иметь
только зарегистрированные пользователи.
45
4.1. Операции над группами прав доступа
Для добавления, удаления или изменения ГПД выберите в окне навигатора объект «Безопасность->Группы». В основном окне появится таблица, в
которой отражены все ГПД и связанные с ними ББД. Группа сама по себе не
существует, а только в паре с ББД. Пара ГПД-ББД является уникальной. Таблицу можно отсортировать по любой колонке. Для этого щелкните левой клавишей мыши на заголовке колонки.
Рис. 25
Все операции выполняются из контекстного меню (рис.25). Команда
«Добавить» вызывает диалоговое окно добавления новой пары ГПД-ББД
(рис.26). Команда «Добавить по образцу» вызывает диалоговое окно добавления новой пары ГПД-ББД, в котором все поля заполнены в соответствии с
46
выбранной парой ГПД-ББД. Команда «Изменить» вызывает диалоговое окно
редактирования выбранной пары ГПД-ББД (рис.27). Эту же команду можно
вызвать двойным щелчком левой клавишей мыши. При этом изменить можно
только комментарий и права доступа («0» – нет права, «1» – есть право). Команда «Удалить» удаляет выбранную пару ГПД-ББД. Каждая из рассмотренных выше операций изменяет (после предупреждения) информацию о группах
непосредственно в БД.
Рис. 26
Команда «Фильтр» (рис.28) накладывает фильтр на таблицу в основном
окне. Возможен фильтр только по одному столбцу таблицы основного окна.
Поддерживается применение фильтра к результату фильтрации (вложенные
фильтры). Для этого установите флаг «Применить к результату предыдущего фильтра». Маска фильтра представляет собой подстроку, т.е. по
маске «BOOKS» будут отобраны строки не только с «BOOKS», но и с «ABOOKS»
и с «BOOKS1». Маска применяется с учетом регистра.
47
Рис. 27
Рис. 28
Чтобы отменить фильтр вызовите команду «Фильтр» и, оставив поля пустыми, нажмите кнопку «Применить». Если использовались вложенные
48
фильтры, то они также отменяются. Также фильтр отменяется автоматически
при переходе на другой объект в окне навигатора и при выполнении одной из
операций, описанных выше.
4.2. Операции над пользователями
Для добавления, удаления или редактирования пользователя выберите в
окне навигатора объект «Безопасность->Пользователи». В основном
окне появится таблица, в которой отражены все пользователи. Таблицу можно
отсортировать по любой колонке. Для этого щелкните левой клавишей мыши
на заголовке колонки.
Рис. 29
Все операции выполняются из контекстного меню (рис.29). Команда
«Добавить» вызывает диалоговое окно добавления пользователя (рис.30). Команда «Добавить по образцу» вызывает диалоговое окно добавления
пользователя, в котором часть полей (ГПД, ФГ, Тип пользователя) заполнены в
соответствии с выбранным пользователем. Команда «Изменить» вызывает
диалоговое окно редактирования пользователя (рис.31). Эту же команду можно
вызвать двойным щелчком левой клавишей мыши. Команда «Удалить» удаляет выбранного пользователя. Каждая из рассмотренных выше операций изменяет (после предупреждения) информацию о группах непосредственно в БД.
49
Команда «Фильтр» накладывает фильтр на таблицу в основном окне. Действие
команды аналогично описанному в предыдущем пункте.
Рис. 30
В диалоге добавления/редактирования пользователя (рис.30, рис.31) для
ввода нового пароля необходимо заполнить два соседних поля. Поле «Имя
пользователя» содержит имя пользователя АБИС «Руслан», которое пользователь использует для авторизации из АРМов АБИС «Руслан» при соединении
с сервером «Руслан». Все неавторизованные пользователи могут подключаться
к системе только под пользователем с именем anonymous (без пароля), если
этот пользователь не удален из списка пользователей. Имя пользователя в
АБИС «Руслан» никак не связано с именем пользователя в операционной системе, из которой запускаются АРМы.
50
ВНИМАНИЕ! Имя пользователя АБИС «Руслан» не может совпадать с
именем группы (ГПД).
Поле «Комментарий» рекомендуется использовать для задания фамилии,
имени и отчества пользователя или описания пользователя в случае не персонифицированного или коллективного пользователя (обычно это имеет место в
корпорациях).
Рис. 31
Для назначения ГПД (см. предыдущий пункт) пользователю выберите
группу из существующих групп в перечне «Доступные группы» и нажмите
кнопку с соответствующей стрелкой. Для назначения роли (см. предыдущий
пункт) выберите роль из перечня «Доступные роли» и нажмите кнопку с соответствующей стрелкой. Для ролей может иметь значение их порядок (см. до51
кументацию на АРМы). Для изменения положения роли выделите ее в списке
«Роли» и нажмите кнопку с соответствующей стрелкой (вверх или вниз).
Пользователь может быть либо «Локальным» либо «Внешним». "Внешние" пользователи требуются для организации корпоративной службы МБА
при хранении в данной библиотеке электронных каталогов других библиотек.
Для обеспечения нормального функционирования АРМов необходима
корректная установка как групп, так и ролей. Так, для обеспечения работы
комплектования, необходимо пользователю дать роли billcreator и compl, а также дать группу(ы) которая будет иметь права на поиск, извлечение, вставку, изменение, удаление записей в библиографических БД, с которыми осуществляется работа, а в служебных БД счетов, актов, книги суммарного учета,
описаний справочников, справочников. В конкретном случае права могут отличаться даже для работы одного типа, в частности правом на удаление записей.
52
5. Управление библиотечными базами данных
В данном разделе описываются все операции, связанные с управлением
библиотечными базами данных. Библиотечные базы данных хранятся в одном
или нескольких ИБД. Для доступа к библиотечным БД выберите в окне навигатора требуемый ИБД, раскрыв объект «Источники данных» (см. рис.11). В
основном окне появится перечень библиотечных БД в виде таблицы. Все операции над библиотечными БД выполняются из контекстного меню основного
окна (рис.32).
Рис. 32
Команда «Фильтр» (рис.33) накладывает фильтр на таблицу в основном
окне. Возможен фильтр только по одному столбцу таблицы основного окна.
53
Поддерживается применение фильтра к результату фильтрации (вложенные
фильтры). Для этого установите флаг «Применить к результату предыдущего фильтра». Маска фильтра представляет собой подстроку, т.е. по
маске «BOOKS» будут отобраны строки не только с «BOOKS», но и с «ABOOKS»
и с «BOOKS1». Маска применяется с учетом регистра.
Рис. 33
Чтобы отменить фильтр вызовите команду «Фильтр» и, оставив поля пустыми, нажмите кнопку «Применить». Если использовались вложенные
фильтры, то они также отменяются. Также фильтр отменяется автоматически
при переходе на другой объект в окне навигатора и при выполнении одной из
операций, описанных выше.
54
5.1. Создание библиотечных БД организации
Библиотечные БД делятся на библиографические и служебные. Библиографические БД предназначены для хранения библиографических записей.
Служебные БД предназначены для хранения библиотечных не-библиографических данных, таких как справочники, акты, данные по подписке, заказам, данные о читателях и т.п.
Рис. 34
Библиографические БД хранят записи в формате, близком к ISO2709.
Служебные БД хранят записи в специализированном формате АБИС «Руслан».
Каждая запись служебной БД состоит из одного или нескольких полей. Имя
поля – числовой идентификатор (тег). Каждое поле может иметь один или
несколько экземпляров. Значение поля может быть либо строкой (до 1500 сим55
волов), либо бинарными данными (не индексируются, размер до 4 Гбайт). В
полях бинарного типа хранятся фотографии читателей, данные МБА-заказов и
т.п.
Для создания библиографической БД выберите из контекстного меню команду «Создать->Библиографическая БД» (рис.32). Появится диалоговое окно (рис.34), в котором требуется ввести имя БД (английскими буквами),
выбрать формат записей и области хранения для хранения элементов БД: записей, словаря и индекса (см. АБИС «Руслан». Руководство по установке, пп. 3.1,
3.3, 3.4). После выбора формата записей (за исключением формата «MARC»)
часть полей диалогового окна будет автоматически заполнена. Эти значения
изменять не рекомендуется.
При выборе формата записей «MARC», администратору предоставляется
самостоятельно задать значения для полей:
➔
«Идентификатор списка точек доступа» (см. п.2.3)
➔
«Идентификатор схемы» (последнее число в OID схемы, см. описание
протокола Z39.50)
➔
«Идентификатор синтаксиса записи» (последнее число в OID синтаксиса записи, см. описание протокола Z39.50)
➔
«Идентификатор таблицы индексирования MARC-записей» для
первой и второй фазы (см. п.2.2)
Если используется одно-фазное индексирование, то идентификатор таблицы
индексирования MARC-записей для второй фазы должен быть «0».
После заполнения всех полей нажмите кнопку «Выполнить». Новая библиографическая БД будет создана.
Для создания служебной БД выберите из контекстного меню команду
«Создать->Служебная БД» (рис.32). Появится диалоговое окно (рис.35), в
котором требуется ввести имя БД (английскими буквами) и выбрать области
56
хранения (см. АБИС «Руслан». Руководство по установке, пп. 3.1, 3.3, 3.4) для
хранения элементов БД: данных (поля-строки записей) и LOB-данных (полябинарные данные записей).
Рис. 35
После заполнения всех полей нажмите кнопку «Выполнить». Новая служебная БД будет создана.
ВНИМАНИЕ! Имена библиотечных БД должны быть уникальными не только
в рамках одного источника (ИБД), но и в рамках всех зарегистрированных в системе источников (см. п.2.1).
57
5.2. Редактирование параметров библиотечных БД организации
Для редактирования параметров библиотечной БД выберите в таблице в
основном окне строку с требуемой БД и вызовите из контекстного меню команду «Изменить» (рис.32). Появится диалоговое окно (рис.36).
Рис. 36
Большинство параметров БД (за исключением имени и типа) можно изменить. Установка флага «Доступна», означает, что к БД разрешен доступ по
протоколу Z39.50. Установка флага «Скан по словам» означает, что по заданным точкам доступа (см. п.3.1, параметр Scan) при старте сервера «Руслан»
в оперативную память будут загружены скан-индексы (поисковые индексы), к
которым производится обращение через сервис «Скан» (см. описание протокола Z39.50). Сервис «Скан» интегрирован в АРМ Комплектования/Каталогиза58
ции. Если после установки флага «Скан по словам» для требуемых БД, на
компьютере, на котором запущен сервер «Руслан», появились признаки нехватки оперативной памяти, то необходимо либо выключить данный флаг для некоторых БД, либо уменьшить число поисковых атрибутов для сервиса «Скан» (в
параметре Scan). Флаг «Скан по значению» в настоящей версии не поддерживается.
Параметр «Каталог» может иметь два значения: «Локальный» и
«Внешний». При создании БД этот параметр имеет значение «Локальный».
Значение «Внешний» устанавливается для библиографических БД, которые
принадлежат сторонним организациям и из которых возможен заказ литературы по МБА.
Алиасы БД – это синонимы имени БД. Имя БД может быть только на английском языке. Алиас может быть задан на любом языке, он хранится в кодировке unicode. Алиасы обычно используют в АРМе Комплектования/Каталогизации и АРМе Читателя для лучшего и более понятного отражения содержания
БД. Алиасом БД также всегда является ее имя. Этот алиас нельзя удалить. БД
может иметь несколько алиасов. Категорически не рекомендуется давать одинаковые алиасы разным БД не только в рамках одного источника (ИБД), но и в
рамках всех зарегистрированных в системе источников (см. п.2.1). Если требуется объединить под одним именем (псевдонимом) несколько БД (одного
типа), то следует создать виртуальное групповое имя (см. п.3.1, параметр
GroupDB).
Ключ записи состоит из префикса и номера записи. Номер записи генерируется автоматически при вставке новой записи. Нумерация записей последовательная, начиная с 1 (по умолчанию, см. п.5.10). Удаленные номера (образуются при удалении записей) повторно не используются. Префикс состоит из
нескольких частей. Структура префикса не является стандартом. Рекомендуется выделить в префиксе три поля, разделенных наклонной чертой: код страны,
код организации, имя базы. Например, префикс ключей для записей из базы
59
BOOKS Фундаментальной библиотеки Санкт-Петербургского государственного
технического
университета
выглядит
следующим
образом:
RU\SPSTU\books\. В общем случае не рекомендуется давать одинаковые
префиксы разным библиографическим БД организации. Это, в большинстве
случаев (исключая специальное управление номерной частью ключа), приведет
к появлению разных записей с одинаковым ключом, что может создать определенные проблемы при загрузке/выгрузке, связывании записей, для работы
службы заказа. Префикс ключа записи может быть задан на любом языке (хранится в unicode).
Диалог позволяет изменить также идентификаторы таблиц индексирования и списка точек доступа. Однако делать это не рекомендуется. При изменении идентификатора таблицы индексирования, если в данной БД содержатся
записи, необходимо удалить индекс (см. п.5.4) и переиндексировать БД (см.
п.5.5). При изменении идентификатора списка точек доступа их необходимо
обновить (см. п.5.7).
Параметры «OID схемы», «OID синтаксиса записей», «OID набора атрибутов» категорически не рекомендуется изменять за исключением особо оговоренных в данном руководстве и в руководстве по установке случаев.
5.3. Определение количественных показателей библиотечных БД
Для определения количества записей в библиотечной БД выберите в таблице в основном окне строку с требуемой БД и вызовите из контекстного
меню команду «Количество записей» (рис.32). Результат выполнения команды выводится в окно лога. Данная информация является наиболее достоверной (по сравнению с определением количества записей через поисковые
запросы).
Для библиографических БД можно определить такие показатели обработки, как количество уникальных штрихкодов и количество экземпляров до60
кументов в БД. Для определения этих показателей выберите в таблице в основном окне строку с требуемой БД и вызовите из контекстного меню команды
«Количество штрихкодов» и «Количество экземпляров» (рис.32). Результат выполнения команд выводится в окно лога.
5.4. Удаление библиотечной БД или данных из библиотечной БД
Для удаления библиотечной БД выберите в таблице в основном окне
строку с требуемой БД и вызовите из контекстного меню команду «Удалить>Удалить базу» (рис.32). После двух предупреждений выделенная БД будет удалена со всеми данными. Восстановить данные возможно только из архивной копии.
Для удаления данных из библиотечной БД выберите в таблице в основном окне строку с требуемой БД и вызовите из контекстного меню команду
«Удалить->Удалить данные из базы» (рис.32). После двух предупреждений появится диалоговое окно (рис.37), в котором необходимо выбрать ту
часть данных, которую необходимо удалить. Вариант «Удалить все данные» удаляет все записи, включая старые версии и индекс. Восстановить данные возможно только из архивной копии. Вариант «Удалить индекс» удаляет только индекс. Эта операция требуется, когда необходимо переиндексировать всю библиографическую БД после значительных изменений (пакетных)
записей. Вариант «Удалить все старые версии записей» удаляет все
старые записи. После этой операции восстановить старую версию записи из
данной БД возможно только из архивной копии. Варианты «Удалить старые версии записей старше 1 года» и «Удалить старые версии
записей старше 2-х лет» удаляют старые записи с указанным сроком
давности с соответствующим снижением возможностей восстановления.
Вариант «Удалить записи по запросу» удаляет все записи удовлетворяющие запросу, включая индекс. Эти записи не попадают в таблицу отката, однако старые версии удаляемых записей сохраняются в таблице отката.
61
Перед выполнением собственно удаления будет выдано сообщение с результатом поиска (сколько найдено записей) и на этой стадии от удаления еще можно
отказаться. Формат поискового запроса приведен в Приложении 4. Также формат будет выведен на экран, если нажать на кнопку «?».
Рис. 37
5.5. Индексация/переиндексация библиографической БД
Данная операция (индексирование) требуется в обязательном порядке
после загрузки записей, иначе записи будут недоступны по поиску. Также операция (переиндексирование) необходима после изменения таблиц индексирования записей, а также после выполнения пакетных изменений.
62
Рис. 38
В процессе переиндексирования последовательно для каждой записи будет удаляться старый индекс и создаваться новый. При этом в процессе переиндексирования все записи доступны по поиску, однако требуется существенно
больше времени на выполнение, по сравнению с индексированием. Поэтому
переиндексирование всей БД рекомендуется выполнять следующим образом:
сначала удалить индекс (см. п.5.4), а затем выполнить индексирование. Не рекомендуется допускать выполнение операций модификаций (вставка, изменение, удаление) во время переиндексирования. Поэтому либо проводите переиндексирование в нерабочее время, либо сделайте БД временно недоступной (см.
п.11.4).
63
Для индексирования/переиндексирования записей в библиографической
БД выберите в таблице в основном окне строку с требуемой БД и вызовите из
контекстного меню команду «Переиндексировать» (рис.32). Появится диалоговое окно как на рис.38.
По умолчанию индексирование/переиндексирование выполняется по таблицам индексирования, идентификаторы которых указаны в параметрах БД.
Если требуется выполнить операцию с другой таблицей индексирования, то в
поле «Таблица индексирования» следует задать идентификатор требуемой таблицы индексирования. Существует возможность переиндексировать/доиндексировать только определенные поля. Для этого в поле «Таблица индексирования» следует задать требуемый фрагмент описательной части таблицы индексирования (см. п.2.2). Не рекомендуется что-либо задавать в поле
«Таблица индексирования», если Вы не уверены в том, что делаете.
Существует три режима индексации/переиндексации: всех записей, некоторого диапазона записей или непроиндексированных на 1 фазе записей (на 1
фазе – поскольку фиксируется только успешное окончание 1 фазы индексирования – см. п.2.2). Последний режим применяется, если в БД, содержащую
проиндексированные записи, были дополнительно загружены новые записи
или в случае, если индексирование БД было прервано. Во втором режиме номера записей в диапазоне соответствуют порядку ввода записей в БД. Поэтому
данную возможность следует использовать при индексации/переиндексации
всей БД известными порциями. Например, для тестирования результата или в
случае временных ограничений.
Для запуска процесса индексации/переиндексации нажмите кнопку
«Запустить». Имеется возможность в любой момент прервать процесс, нажав
кнопку «Закрыть», и продолжить в другое время. Также возможно приостановить процесс, нажав кнопку «Остановить», а затем продолжить, нажав кнопку «Продолжить». Отработка команд «Остановить» и «Закрыть» (но не в
случае, когда закрывается диалоговое окно по кнопке «x») может занять опре64
деленное время, поскольку выполняется анализ статистики (см. п.5.6), который
также проводится после индексации/переиндексации первой 1000 записей,
каждых 10000 записей и в конце операции.
5.6. Анализ статистики для библиотечных БД
Схема данных «Руслан» использует различные индексы СУБД Oracle.
СУБД Oracle обеспечивает лучшее качество (по времени) поиска на основе статистических данных. СУБД не собирает эти данные автоматически – для этого
существует специальная команда анализа статистики, которая интегрирована в
АРМ. С течением времени (если проводились операции модификации записей)
статистика устаревает и качество поиска снижается. Поэтому анализ статистики надо проводить периодически для всех библиотечных БД (при увеличении
размера БД на несколько тысяч записей). О необходимости проведения анализа
статистики свидетельствует постепенное (не резкое) увеличение времени поиска на известных запросах (если не происходило изменений в оборудовании и
конфигурации физической БД). В процессе загрузки записей и индексирования
(переиндексирования) записей анализ статистики проводится автоматически.
Для анализа статистики библиотечной БД выберите в таблице в основном
окне строку с требуемой БД и вызовите из контекстного меню команду «Анализ» (рис.32). После выполнения анализа соответствующее сообщение появится в окне лога. Имеется возможность задать анализ статистики у нескольких БД
одновременно (сам анализ будет проводиться последовательно для каждой БД).
Для этого выделите в таблице несколько БД и выберите в контекстном меню
команду «Анализ».
Сервер «Руслан» версии 2.13 и выше производит автоматический анализ
статистики каждую ночь, и выполнять ручной анализ рекомендуется только после выполнения существенных изменений при пакетном изменении с частичным переиндексированием.
65
5.7. Обновление точек доступа к библиографическим БД
Описание точек доступа (см. п.2.3) отделено от их применения к библиографическим базам данных (в отличие от таблиц индексирования). Т.е. при изменении точек доступа в некотором списке ТД, эти изменения автоматически
не применяются к БД, связанным с данным списком ТД. Также, при изменении
идентификатора списка ТД у некоторой БД (см. п.5.2), ТД для этой БД остаются прежними. Обновлять ТД необходимо вручную. Эта операция быстрая и некритичная.
Для обновления ТД библиографической БД выберите в таблице в основном окне строку с требуемой БД и вызовите из контекстного меню команду
«Обновить ТД» (рис.32). После выполнения операции соответствующее сообщение появится в окне лога.
Имеется возможность обновить точки доступа у нескольких библиографических БД одновременно. Для этого выделите в таблице несколько БД и выберите в контекстном меню команду "Обновить ТД". После обработки каждой
БД будет появляться сообщение об успешном (в логе) или неуспешном (блокирующее дальнейшую работу сообщение) прохождении процесса для указанной
БД. В случае выдачи сообщения о неудачном завершении процесса для какой
либо БД, после нажатия на кнопку "OK" программа переходит к обновлению
точек доступа для следующей БД. В дальнейшем для той БД, для которой процесс завершился неудачно, необходимо повторить операцию. Если процесс завершился неудачно для всех выбранных БД, то это означает ошибку в синтаксисе задания какой-либо точки доступа. Для упрощения выделения БД с требуемым идентификатором списка ТД можно отсортировать таблицу по колонке
«Точки доступа» или наложить фильтр (см. п.5).
66
5.8. Загрузка записей в библиотечные БД
Операция загрузки обеспечивает загрузку данных как в библиографические, так и в служебные БД. Для библиографических БД поддерживается загрузка из файла в формате ISO2709. Для служебных БД поддерживается загрузка из файла в формате Руслан (см. Приложение 3). Поддерживаются следующие кодировки записей: DOS (866), MS Windows (1251), КОИ-8, UNICODE
(UTF-8).
В библиографическую БД следует загружать записи того формата
(RUSMARC, USMARC, ...), для которого данная БД создавалась. После загрузки библиографических записей, для обеспечения поисковых возможностей, записи необходимо проиндексировать (см. п.5.5). Записи служебных БД индексируются в процессе загрузки.
Для загрузки записей в библиотечную БД выберите в таблице в основном
окне строку с требуемой БД и вызовите из контекстного меню команду «Загрузить» (рис.32). В появившемся диалоговом окне (рис.39) необходимо задать файл либо вручную (с полным путем), либо с помощью стандартного диалогового окна выбора файла. Для вызова диалога выбора файла нажмите кнопку «>>» справа от поля ввода имени файла. После этого выберите кодировку, в
которой представлены записи в файле и дождитесь окончания процесса
подсчета количества записей в файле (поле «Количество записей в
файле» перестанет изменяться).
Для файла библиографических записей необходимо выбрать MARC-формат (RUSMARC, UNIMARC, USMARC, MARC – если другой, нежели первые
три) и тип MARC-формата (библиографический, авторитетный, классификационный). Также возможно, в случае необходимости, указать опции «Добавить
префикс к ключу» (в поле 001) и «Генерировать ключ дублетности»
(в поле 998 и только для RUSMARC).
Если в загружаемых записях отсутствуют ключи или они Вас не устраивают, то следует установить опцию «Генерировать ключ записи». При
67
этом будет генерироваться новый ключ для каждой вставляемой записи в соответствии с текущим префиксом базы (для библиографических БД) и установкой генератора номеров ключей (см. п.5.10). При создании новой БД генератор
номеров ключей устанавливается в «1» (номера ключей будут генерироваться,
начиная с 1).
Рис. 39
Опции «Генерировать ключ записи» и «Добавить префикс к
ключу» взаимоисключающие.
Операция загрузки позволяет управлять порядком загрузки записей –
можно загружать все записи, записи в диапазоне (номера записей в диапазоне
соответствуют порядку записей в загружаемом файле), записи «С первой не
вставленной и до конца». Последний вариант будет правильно работать,
68
если БД, в которую загружаются записи, изначально была пуста, а также между
этапами загрузки не производилась модификация исходного файла записей и
файла плохих (поврежденных) записей. Файл плохих записей имеет имя соответствующее исходному файлу загружаемых записей и расширение ".bad" и создается в той же директории, где и файл исходных записей. При невозможности вставить запись в БД запись помещается в файл плохих записей.
Для запуска процесса загрузки нажмите кнопку «Запустить». В любой
момент можно прервать загрузку записей, нажав кнопку «Закрыть», и продолжить в другое время. Также можно приостановить загрузку записей, нажав
кнопку «Остановить», а затем продолжить, нажав кнопку «Продолжить».
Примечание.
5. Если среди загружаемых записей есть связанные записи, то генерация новых
ключей нарушит эти связи.
6. Ключ дублетности генерируется по правилам АБИС «Руслан».
7. Проверка на дублетность осуществляется при вводе новых записей из АРМа
Комплектования/Каталогизации. При загрузке проверка на дублетность не
осуществляется.
8. После загрузки записей без генерирования новых ключей необходимо установить генератор номеров ключей на новое значение (см. п.5.10), чтобы исключить генерирование дублетных ключей.
5.9. Выгрузка записей из библиотечных БД
Операция выгрузки обеспечивает выгрузку данных как из библиографических, так и из служебных БД. Для библиографических БД поддерживается
выгрузка в файл в формате ISO2709. Для служебных БД поддерживается выгрузка в файл в формате Руслан (см. Приложение 3). При выгрузке записи могут быть перекодированы в следующие кодировки: DOS (866), MS Windows
(1251), КОИ-8, UNICODE (UTF-8). В последнем случае перекодирование не
69
осуществляется, поскольку записи в библиотечных БД хранятся в кодировке
UTF-8.
Для выгрузки записей из библиотечной БД в файл выберите в таблице в
основном окне строку с требуемой БД и вызовите из контекстного меню команду «Выгрузить» (рис.32). В появившемся диалоговом окне (рис.40) необходимо задать файл либо вручную (с полным путем), либо с помощью стандартного диалогового окна выбора файла. Для вызова диалога выбора файла
нажмите кнопку «>>» справа от поля ввода имени файла. После этого выберите
кодировку, в которой должны быть представлены записи в файле.
Рис. 40
70
Имеется возможность либо перезаписать файл (старое содержимое теряется), либо добавить выгружаемые записи в конец указанного файла. Опция
«Построчно» указывает, что после каждой записи в файле будет вставлен
символ перевода строки (в Windows-стиле, т.е. два байта).
Поле «Удалить теги» используется для задания перечня тегов, которые следует удалить при выгрузке из записей служебных БД. Теги задаются через запятую (без запятой в конце).
Операция выгрузки позволяет управлять порядком выгрузки записей –
можно выгрузить все записи, некоторый диапазон записей и записи, отобранные по запросу (формат запроса см. в Приложении 4). Номера записей в диапазоне соответствуют порядку ввода записей в БД. Поэтому данную возможность
следует использовать при выгрузке всей (или части) БД известными порциями.
Выгрузка записей по запросу может использоваться для архивирования
изменений (вновь созданных и измененных записей с определенного момента
времени). Так, по запросу «@1012,5,0,2,0,0,8=20010521» будут выгружены (из указанной библиографической БД) все записи созданные или измененные в период с 21 мая 2001 года и по настоящий момент. Для служебной БД
аналогичный
запрос
будет
выглядеть
следующим
образом:
«@3,5,0,2,0,0,8=20010521».
Для запуска процесса выгрузки нажмите кнопку «Запустить». В любой
момент можно прервать выгрузку записей, нажав кнопку «Закрыть», и продолжить в другое время. Также можно приостановить выгрузку записей, нажав
кнопку «Остановить», а затем продолжить, нажав кнопку «Продолжить».
Примечание.
1. Из библиографических БД выгрузка возможна только в «родном» MARCформате, т.е. в том, в котором записи загружались.
2. Если выгрузка из БД происходит в то время, когда пользователи могут работать с данной БД через сервер «Руслан», то возможна потеря записей в файле
71
(несоответствие их количества предполагаемому) в следствие удаления записей пользователями из данной БД.
5.10. Установка начального номера генератора ключей записей
библиотечных БД
После создания новой БД, генератор для данной БД установлен в «1», т.е.
при вставке новых записей из библиотечных АРМов, они будут нумероваться
(посредством ключа для служебных БД и числовой части ключа для библиографических БД) последовательно начиная с 1.
Рис. 41
Если после создания БД в нее загружаются записи без генерирования
ключа (см. п.5.8), то при вставке новых записей из библиотечных АРМов мо72
жет получиться так, что вновь сгенерированный ключ уже будет существовать.
В результате при вставке записи возникнет ошибка. Например, Вы загрузили в
некоторую библиографическую БД 3 записи без генерирования ключей. Эти записи имеют ключи с числовой частью «5», «6» и «7». Далее в эту БД вставили 4
записи из библиотечного АРМа. Они получили ключи с числовой частью «1»,
«2», «3», «4». При попытке вставить в эту БД 5-ю запись возникнет ошибка, поскольку ключ с числовой частью «5» уже существует. Чтобы этого не произошло генератор ключей следует сместить, т.е. установить для него новый начальный номер. Для приведенного примера новый начальный номер генератора должен быть «8».
Для установки нового начального номера генератора ключей выберите в
таблице в основном окне строку с требуемой БД и вызовите из контекстного
меню команду «Установить ключ» (рис.32). В появившемся диалоговом
окне (рис.41) будет приведен последний номер в ключе в записях данной БД,
текущий номер генератора и предлагаемый системой новый начальный номер
генератора. Если Вас не устраивает новый начальный номер, предложенный
системой, Вы можете задать тот номер, который считаете правильным.
Нажмите на кнопку «Выполнить», чтобы установить заданный новый
начальный номер генератора ключей. В окне лога появится сообщение об
успешном выполнении операции.
Примечание.
1. В случае отмены операции значение генератора будет увеличено на 1. Поэтому, если Вы решили не изменять начальный номер генератора (текущий номер соответствует новому начальному номеру), все равно нажмите кнопку
«Выполнить».
2. Настоятельно не рекомендуется устанавливать в качестве начального номера «0» или отрицательное число.
73
5.11. Просмотр записей в библиотечных БД
Для просмотра записей выберите в таблице в основном окне строку с требуемой БД и вызовите из контекстного меню команду «Просмотр» (рис.32).
Эту же команду можно вызвать двойным щелчком левой клавишей мыши на
строке с требуемой БД. Для библиографической БД появится диалоговое окно
как на рис.42, а для служебной БД – как на рис.43. Если в БД нет записей, а также в случае ошибок выдается сообщение «Ошибка извлечения первой
записи!».
Рис. 42
Кнопки навигации позволяют перейти к первой записи в БД («|<»), к последней записи в БД («>|»), к следующей записи («>>»), к предыдущей записи
(«<<»). В случае перехода на несуществующую запись выдается сообщение
74
«Ошибка извлечения записи!». Для библиографических БД возможен
переход на конкретную запись, идентифицируемую внутренним (ключ БД)
либо внешним (ключ из MARC-поля 001) ключом. Для этого введите ключ в
соответствующее поле диалогового окна и нажмите клавишу «Ввод»
(«Enter»). Для служебных БД возможен переход на конкретную запись, идентифицируемую внутренним ключом.
Статус библиографической записи означает: 0 – запись не проиндексирована, 1 – запись проиндексирована (по крайней мере на 1 фазе в случае двухфазной индексации).
Рис. 43
Для библиографической БД имеется возможность выделить (чтобы выделить всю запись поместите курсор в поле записи и нажмите Ctrl+A) и скопи75
ровать текстовое представление записи в буфер обмена (стандартная комбинация клавиш – Ctrl+C).
Для библиографической записи информация о том кто и когда ее создал
выводится в соответствующим образом поименованных полях. Для служебной
записи информация о том кто и когда ее создал находится соответственно в
поле 2 и 3 тега (формат даты: ГГГГММДДЧЧММСС). Если запись была создана в процессе загрузки из АРМа Администратора, то имя создателя –
«phloader».
Кнопка «Удалить» служит для удаления записи из БД. При удалении запись помещается в таблицу отката (см. п.5.13). После удаления она все еще
остается на экране. Для библиографических БД поддерживается операция индексирования/переиндексирования просматриваемой записи (кнопка «Переиндексировать»). Индексирование/переиндексирование производится в соответствии с таблицами индексирования, определенными для выбранной БД
(см. п.5.1).
5.12. Контроль дублетов в полях MARC-записей и служебных
записей
Контроль дублетов позволяет получить список дублетных значений в
указанном поле (подполе) MARC-записи или поле служебной записи. Эта операция полезна для контроля дублетности инвентарных номеров, штрих-кодов и
т.п.
Для получения списка дублетов в библиографической БД выберите в таблице в основном окне строку с требуемой БД и вызовите из контекстного
меню команду «Дублеты» (рис.32). В появившемся диалоговом окне (рис.44) в
поле «Поле» введите номер поля (подполя), в поле «Кол-во» – ограничение
на количество извлекаемых значений.
Для поиска дублетов нажмите кнопку «Найти». После выполнения операции поиска появится сообщение о количестве извлеченных дублетов. Если
76
оно равно ограничению, то, возможно, дублетов больше. Дублеты будут выведены в таблицу диалогового окна. В колонке «Значение» выводятся значения
указанного поля (подполя), которые повторяются в записях выбранной БД. Для
служебных БД это значение усекается до 32-х первых символов. В колонке
«Дублетность» выводится количество повторений значения во всех записях выбранной БД.
При закрытии диалогового окна поиска дублетных значений появляется
сообщение с предложением сохранить найденные дублеты в текстовом файле
для последующего использования библиотекарями.
Рис. 44
77
5.13. Просмотр истории изменения библиографических записей и
восстановление удаленной или измененной записи
В АБИС «Руслан» хранится история изменений библиографических записей для каждой библиографической БД. При изменении записи старая версия
записи помещается в так называемую таблицу отката. При удалении записи она
также помещается в таблицу отката. Для каждой записи хранится кто и когда
ее создал. Имеется возможность восстановить в БД любую версию записи (если
эта версия не была удалена).
Рис. 45
Для просмотра таблицы отката некоторой БД выберите в таблице в
основном окне строку с требуемой библиографической БД и вызовите из
78
контекстного меню команду «Откат» (рис.32). Появится диалоговое окно как
на рис.45.
Для каждой записи отображается внутренний ключ (ключ БД); внешний
ключ (из MARC-поля 001); операция, в результате которой данная запись была
помещена в таблицу отката; пользователь, который создал (в результате операции загрузки, вставки или модификации) данную версию записи в случае операций «Изменение» и «Удаление» или который удалил запись в случае операции «Удалил»; время, когда была создана (а не помещена в таблицу отката!) в БД данная версия записи, в случае операций «Изменение» и «Удаление» или время, когда была выполнена операция «Удалил» (когда запись
была помещена в таблицу отката в результате операции удаления).
Рис. 46
В примере на рис.45 запись с ключом «ru\spstu\books\139427» была загружена в АРМе Администратора (пользователь phloader) 14.02.2004 в 15:53:23.
Следующая версия записи была создана пользователем compl 24.02.2004 в
11:35:29 и попала в откат в результате операции изменения. Следующая версия
записи также была создана пользователем compl 24.02.2004 в 11:36:34 и попала
в откат в результате операции удаления, которую выполнил пользователь
compl_admin 24.02.2004 в 11:40:23. Запись с ключом «ru\spstu\books\139435»
79
была загружена в АРМе Администратора (пользователь phloader) 14.02.2004 в
15:53:23. 24.02.2004 в 11:38:30 эта запись была удалена администратором системы (libmgr) из АРМа Администратора.
Рис. 47
Все операции в окне отката осуществляются через контекстное меню
(рис.46). Для сравнения старой версии записи с текущей (в рабочей базе) выделите строчку таблицы со старой версией и два раза щелкните на ней левой клавишей мыши или выберите из контекстного меню команду «Сравнить». Появится диалог как на рис.47. В верхней части диалога содержится актуальная
запись из БД, ее создатель и дата создания. В нижней части диалога содержит80
ся запись из таблицы отката, ее создатель и дата создания записи. В случае,
если актуальная запись (в БД) была удалена, верхняя часть будет пустой.
Для сравнения записей из таблицы отката выделите две интересующие
вас записи и выберите из контекстного меню команду «Сравнить».
Для восстановления старой версии записи выделите требуемую старую
версию и выберите из контекстного меню команду «Восстановить». Для
восстановления последней версии удаленной записи можно выбрать строку таблицы как с операцией «Удаление», так и с операцией «Удалил». В случае
восстановления старой версии записи, которая не была удалена, текущая версия будет помещена в таблицу отката. Восстановленная запись считается созданной пользователем СУБД, которым является владелец ИБД (см. п.2.1), в
котором находится данная библиографическая БД. В примере, который
рассматривается в данном руководстве, таким пользователем будет lib1 (см.
например рис.45).
Рис. 48
Информация о старых версиях записей в диалоговое окно отката выдается порциями по 30 версий. При открытии диалогового окна отката выводятся
30 последних версий записей в указанной БД. По умолчанию записи сортируются по дате в убывающем порядке. Можно отсортировать таблицу отката по
81
любой колонке, щелкнув левой клавишей мыши на заголовке колонки. Для извлечения следующих 30 версий выберите из контекстного меню команду «Выбрать больше». Для быстрого нахождения новой порции версий, перед тем
как подать команду «Выбрать больше», выделите последнюю строку в
списке – эта строка после выполнения команды останется выделенной.
Поскольку со временем в таблице откатов накапливается очень много
версий записей, предусмотрена возможность их фильтрации. После применения фильтра, версии записей также выводятся порциями по 30 штук. Для задания фильтра выберите из контекстного меню команду «Фильтр». Появится
диалоговое окно (рис.48), в котором можно задать фильтрацию по внутреннему
ключу (ключу БД), по внешнему ключу (из MARC-поля 001), по операции, в
результате которой запись попала в таблицу отката, по пользователю, создавшему версию записи или удалившему запись и по дате создания версии записи
или удаления записи. Для внутреннего ключа и даты можно задать отношение
(<, >, = ...). Внешний ключ всегда фильтруется операцией LIKE. При отсутствии спецсимволов («_», «%») эта операция работает на равенство. Спецсимвол подчеркивание («_») означает любой символ (один!). Спецсимвол процент
(«%») означает любое количество символов. Обычно спецсимвол процент используется, чтобы не задавать префикс ключа, который у всех записей библиографической БД в нормальном состоянии один и тот же. Для снятия фильтра
вызовите диалоговое окно фильтра, нажмите сначала на кнопку «Очистить»,
а затем «Принять». Кнопка «Оставить без изменений» закрывает окно
фильтра без каких-либо изменений по условиям фильтрации.
Для уменьшения общего объема базы и повышения скорости работы со
старыми версиями записей рекомендуется периодически чистить таблицу отката (удалять совсем старые версии). Эту операцию возможно выполнить
несколькими способами. Наиболее быстрый способ удаления всех старых версий приведен в п.5.4. Удалить все старые версии можно также из диалогового
окна отката, выбрав из контекстного меню команду «Удалить->Все». Для
82
удаления выделенных версий записей выберите из контекстного меню команду
«Удалить->Выбранные». Для удаления всех версий записей, удовлетворяющих примененному фильтру, выберите из контекстного меню команду «Удалить->Все по фильтру».
5.14. Пакетное изменение библиографических записей
В АБИС «Руслан» предусмотрено два варианта пакетного изменения библиографических записей: простой и расширенный. Простой вариант ограничен
по своим возможностям, но имеет дружественный пользовательский интерфейс. Расширенный вариант позволяет проводить с записями любые изменения, но требует участия программиста для создания программы этих изменений. Поэтому для расширенного варианта поставляется службой поддержки
специальная библиотека (DLL) с типовыми изменениями. В рамках технической поддержки можно заказать необходимые изменения (обращайтесь по адресу ruslan@balticsoft.ru).
Для выполнения простого пакетного изменения над некоторой БД выберите в таблице в основном окне строку с требуемой библиографической БД и
вызовите из контекстного меню команду «Изменить записи->Простое
изменение» (рис.32). Появится диалоговое окно как на рис.49.
Возможно одновременное проведение трех операций изменения:
➔
замена/добавление подстроки в поле(подполе) или во встроенном поле(подполе) в поле связи. Операция изменения проводится над всеми экземплярами подполя во всех экземплярах поля записи. Добавление подполя производится только для существующих полей и во всех экземплярах полей, т.е.
при отсутствии поля оно не будет создаваться автоматически. Возможна замена целой строки при задании опции «целая строка», выполнение операции удаления поля(подполя) при задании опции «удалить», выполнение
операции добавления подстроки (возможно вместе с добавлением подполя)
при задании опции «добавить» (значение в поле «заменить» выступает
83
как фильтр записей). В последнем случае можно указать как поступить, если
подполе существует: добавлять, не добавлять, конкатенировать слева (опция
«лк») или справа (опция «пк»). При включении опции «добавить» несуществующее подполе будет добавлено только в том случае, если поле существует;
➔
замена индикаторов в поле или во встроенном поле в поле связи;
➔
замена подстроки в кодированном поле(подполе) или во встроенном кодированном поле(подполе) в поле связи. Опция «добавить» позволяет добавить кодированное поле(подполе) всегда или если оно не существует. Отсутствующий индикатор задается пробелом. Маркер указывается путем задания
000 в кодированном поле. Для кодированных полей задается позиция, с которой производятся изменения (начиная с 0). При этом длины заменяемой и
замещающей подстрок должны совпадать.
84
Рис. 49
Для добавления подполя вместе с добавлением поля (когда поле не существует) следует задать его параметры в разделе для кодированного поля, вне
зависимости от того, является ли поле кодированным или нет.
В областях для ввода строк с данными («заменить» и «на») можно
указать макроподстановки в виде ссылки на подполе, например, {999а}. В
этом случае значение строки будет браться из соответствующего подполя. Если
указанное в макросе поле совпадает с полем, над которым производится операция модификации (введенное в «В поле»), то значение строки для каждого эк85
земпляра поле будет браться из соответствующего экземпляра поля. Если поля
отличаются, то значение строки будет браться из первого экземпляра поля указанного в макросе.
Рис. 50
Использование макроподстановок позволяет копировать данные из одного подполя в другое (операция добавить) и получать более сложные фильтры
при операциях удалить/заменить.
Для выполнения расширенного пакетного изменения над некоторой БД
выберите в таблице в основном окне строку с требуемой библиографической
86
БД и вызовите из контекстного меню команду «Изменить
записи-
>Расширенное изменение» (рис.32). Появится диалоговое окно как на
рис.50.
В поле «Файл DLL» необходимо ввести имя файла динамической библиотеки (должна иметь расширение dll) с указанием полного пути вручную или
с помощью стандартного диалога выбора файла. Для вызова диалога нажмите
кнопку «>>» справа от поля ввода имени файла. После выбора файла DLL из
перечня «Имя
функции
изменения» выберите требуемую функцию
(FuncName). Если файл DLL поставлен службой поддержки системы, то назначение функций дано в сопровождающей документации. После выбора функции
в поле «Лог» будет выведена дополнительная информация по работе с функцией. В поле «Файл параметров» введите имя файла параметров, если он требуется для выбранной функции.
Как простой, так и расширенный варианты пакетного изменения имеют
следующие общие элементы настройки. Изменения можно проводить как непосредственно в рабочей БД, которая указана в поле «Имя базы», так и копируя новые записи в другую (желательно пустую) БД (для этого ее имя необходимо выбрать в поле «Имя базы, в которую помещать измененные
записи»). База для копирования должна быть создана до начала выполнения
процедуры пакетного изменения. Это дает возможность проверить правильность изменения записей и избежать порчи записей в рабочей БД. Если изменения записей происходят правильно, то можно запустить процедуру изменения
записей непосредственно в рабочей БД. Для этого в поле «Имя базы, в которую помещать измененные записи» должно оставаться пустым, в нем
не надо ничего выбирать! При этом старый вариант каждой записи (до изменения) будет помещен в откат. Рекомендуется перед исправлением записей в рабочей БД сделать ее архивную копию (см. п.7).
В поле «Таблица разбора» можно задать специальную таблицу индексирования или фрагмент описательной части таблицы индексирования (см.
87
п.2.2) для индексирования/переиндексирования измененных записей. Не рекомендуется что-либо задавать в поле «Таблица индексирования», если Вы
не уверены в том, что делаете. Значение «0» (стоит по умолчанию) в этом поле
означает: не проводить индексирование измененных записей. Рекомендуется
указывать это значение, если изменяются неиндексируемые поля/подполя.
Если в поле «Таблица индексирования» ничего не вводить, будут использованы таблицы индексирования по умолчанию для данной БД (рекомендуется,
если изменяются индексируемые поля).
Имеется возможность просмотреть все записи на предмет изменения или
в некотором диапазоне (в порядке ввода в БД). В случае простого изменения
имеется также возможность изменить записи, отобранные по запросу (см. Приложение 4).
Флаг «Откат» определяет будут или нет старые варианты записей помещаться в откат. Этот флаг рекомендуется снимать, если есть уверенность в правильности производимых изменений (правильность изменений была тщательно
проверена с использованием тестовой базы, в которую помещались измененные записи) и изменяются большое количество записей.
Для запуска процесса пакетного изменения нажмите кнопку «Запустить». Процесс можно приостановить кнопкой «Остановить», а затем продолжить, нажав кнопку «Продолжить». Кнопка «Закрыть», нажатая во время
процесса, прерывает его выполнение. Процесс изменения записей отражается в
логе. Указывается сколько записей было просмотрено, сколько предложено к
изменению и сколько были успешно изменены.
Примечание.
1. В случае, если пакетное изменение (при котором изменяются индексируемые
поля/подполя) охватывает значительный процент записей в БД, то рекомендуется в поле «Таблица индексирования» задать Значение «0» и после
88
пакетного изменения удалить весь индекс (см. п.5.4) и проиндексировать БД
заново (см. п.5.5).
2. В случае прерывания процесса изменения, измененные к этому моменту записи останутся в измененном состоянии. Для восстановления исходных записей воспользуйтесь функцией восстановления старых версий записей (см.
п.5.13) или восстановите архивную копию БД.
3. В процессе пакетного изменения не производится анализ статистики.
Администратор должен при необходимости (если изменяются индексируемые поля/подполя) выполнить его самостоятельно (см. п.5.6). Рекомендуется
проводить анализ статистики после выполнения всех требуемых изменений.
89
6. Библиотечные технологии
В данном разделе описываются операции, необходимые для настройки
прикладных технологических циклов, выполняемых как независимо сервером
«Руслан», так и технологических циклов, реализуемых совместно с различными АРМами системы.
6.1. Работа с буферной базой
АБИС «Руслан» поддерживает две технологии ввода новых записей. Первая технология предполагает наличие одной основной библиографической БД
(для вида документов, например, для книг). Сотрудники библиотеки создают
записи в этой БД. Читатели, при работе с электронным каталогом, также работают с этой БД. При этом возникает проблема, связанная с доступностью для
читателей библиографических описаний еще не прошедших полный цикл библиографической обработки, т.е. документы не поступили в отделы обслуживания. Читатель может заказать недоступные для обслуживания документы. Данная проблема может быть решена следующим способом. Для записей, не прошедших обработку, «ставится» статус (в маркере записи), означающий не полностью каталогизированный документ. А в пользовательском интерфейсе читателя вводится скрытый фильтр по статусу записи. Недостаток этого способа сокрытия от читателей записей на не полностью каталогизированные документы
в его ресурсоемкости (снижение производительности системы).
Система «Руслан» также предлагает другую технологию сокрытия от читателей записей на не полностью каталогизированные документы. Помимо
основной библиографической БД (для вида документов) создается буферная
библиографическая БД (для вида документов). Ввод новых записей и их обработка осуществляется в буферной БД. При завершении обработки документы
передаются в отделы обслуживания, а записи на эти документы переносятся из
91
буферной БД в основную. Для читателей буферная БД делается недоступной
(см. п.4). Преимущество этой технологии в том, что можно настроить разные
уровни доступа к буферной и основной БД для сотрудников библиотеки. Тем
самым повышается безопасность основной БД (например, операция удаления
разрешается только для буферной БД).
Для переноса полных записей из буферной библиографической БД в
основную выберите в таблице в основном окне строку с требуемой буферной
БД и вызовите из контекстного меню команду «Переместить записи»
(рис.32). После некоторого промежутка времени, во время которого происходит анализ записей в буферной БД, появится диалоговое окно (рис.51), в котором необходимо выбрать основную БД, в которую будут перемещаться записи.
Рис. 51
92
Перемещаются только полные записи. В случае иерархически связанных
записей, полные записи высшего уровня перемещаются всегда. Количество
перемещаемых записей не высшего уровня можно варьировать вручную, автоматически делать кратным 5 или 10. Кроме того, имеется возможность параллельно сохранить перемещаемые записи не высшего уровня в файл в одной из
кодировок: DOS (866), MS Windows (1251), КОИ-8 или UNICODE (UTF-8). Для
сохранения записей в файл необходимо задать имя файла вручную (с полным
путем) или с использованием стандартного диалогового окна выбора файла.
Для вызова диалога выбора файла нажмите кнопку «>>» справа от поля ввода
имени файла. Можно либо перезаписать файл (старое содержимое теряется),
либо добавить выгружаемые записи в конец указанного файла. Опция «Построчно» указывает, что после каждой записи в файле будет вставлен символ
перевода строки (в Windows-стиле, т.е. два байта).
Для запуска операции перемещения записей нажмите кнопку «Выполнить». Ход выполнения операции будет отражен в логе. После перемещения
записей будет предложено проиндексировать их. В случае согласия будет выполнено индексирование в соответствии с таблицами индексирования указанными в параметрах основной БД (см. п.5.1). В случае отказа операция индексирования (если требуется) выполняется вручную (см. п.5.5).
6.2. Заимствование аналитики
Заимствование аналитики – это заимствование библиографических записей на составную часть сериального издания.
При работе по составлению аналитических записей рекомендуется обязательно устанавливать связи на основе поля 001 между записью на составную
часть, записью на выпуск сериального издания и записью на сериальное издание в целом. При ручном создании аналитической записи в АРМе Каталогизатора связи на основе полей 001 устанавливаются автоматически. Процедура заимствования аналитических записей из внешнего источника имеет ряд особен93
ностей, усложняющих восстановление связи на основе 001 поля. Основная причина в том, что заимствование производится сразу всех записей выпуска сериального издания. При этом, восстановление связей в АРМе Каталогизатора возможно только индивидуально для каждой записи.
Для повышения эффективности процесса заимствования аналитических
записей в сервере «Руслан» версии 2.11 и выше реализован механизм автоматического восстановления связи на основе полей 001. На базе имеющейся в аналитической записи информации о сериальном издании (ISSN, заглавие, год, номер выпуска) в локальных базах находятся собственные записи на сериальное
издание в целом и запись на выпуск сериального издания. В заимствуемой аналитической записи исходное содержимое полей встроенных в поля 461 и 463
заменяется на данные из найденных записей. Если записи найти не удалось, то
сервером возвращается диагностика. В этом случае необходимо провести процедуру пересвязывания записей в ручном режиме используя стандартные возможности АРМе Каталогизатора.
Реализованный механизм не гарантирует 100% успешного результата
пересвязывания. Существует достаточно большой процент изданий (2-10%)
для которых результат пересвязывания может быть некорректным. Также, результат пересвязывания существенно зависит от соблюдения формата
RUSMARC при создании (или конвертировании) библиографических записей.
Для обеспечения корректности основных рабочих баз не рекомендуется проводить заимствование аналитических записей напрямую в рабочие базы, а использовать промежуточные базы для временного хранения и контроля пересвязанных записей. Начиная с версии сервера «Руслан» 2.11, снято ограничение на
обязательное хранение записей на составную часть и записей на источник в одной физической базе. В связи с этим, рекомендуется заведение отдельных рабочих баз для хранения аналитических записей и еще одной промежуточной
базы.
94
Пересвязывание с использованием промежуточной базы
Процедура настройки механизма пересвязывания с использованием промежуточной базы состоит из следующих 4-х шагов:
1. Создать дополнительную библиографическую базу для временного хранения
аналитических записей (например, ANALIT_TMP). При необходимости создайте новую библиографическую базу для постоянного хранения аналитических записей (например, ANALIT), если для этой цели не будет использоваться стандартная база SERIAL.
2. В параметре сервера CorpDB добавить базу ANALIT_TMP.
3. В параметре сервера SerialItemDBMap указать соответствие между базой используемой для хранения сериальных записей и базами, используемыми для
хранения аналитических записей (например, если сериальные записи хранятся
в
базе
SERIAL,
то
в
параметре
необходимо
задать
строку
«SERIAL,ANALIT_TMP,ANALIT;»).
4. Перезапустить сервер.
Данный режим позволяет добавлять аналитические записи в рабочую
базу (например, ANALIT) без использования механизма пересвязывания.
Пересвязывание без использования промежуточной базы
Процедура настройки механизма пересвязывания без использования промежуточной базы состоит из следующих 4-х шагов:
1. Создайте новую библиографическую базу для постоянного хранения аналитических записей (например, ANALIT_2005).
2. В параметре сервера CorpDB добавить базу ANALIT_2005. Не используйте
базу SERIAL в параметре CorpDB.
3. В параметре сервера SerialItemDBMap добавить указание соответствия между базой используемой для хранения сериальных записей и базами используемыми для хранения аналитических записей (например, если сериальные за95
писи хранятся в базе SERIAL, то в параметре необходимо задать строку
«SERIAL,ANALIT_2005;»).
4. Перезапустить сервер.
Данный режим не обеспечивает возможности добавления аналитических
записей в рабочую базу (например, ANALIT_2005) без использования механизма пересвязывания (т.е. механизм пересвязывания работает всегда), но обладает, в среднем, большей скоростью работы.
Пересвязывание через промежуточную базу
Для использования механизма пересвязывания через промежуточную
базу следует выполнить следующие шаги в АРМе Каталогизатора:
1. Подключиться к локальному серверу.
2. Подключиться к удаленному серверу.
3. Найти аналитические записи записи для нужного выпуска сериального издания.
4. Скопировать записи в промежуточную базу (например, ANALIT_TMP).
5. Найти записи в промежуточной базе.
6. Если результирующие записи устраивают, то скопировать их в рабочую базу
аналитики (в данном режиме использования это могут быть или SERIAL или
ANALIT).
7. Если результаты пересвязывания не устраивают, то выполнить ручное пересвязывание в рабочей базе.
8. Удалить записи из ANALIT_TMP.
Пересвязывание без промежуточной базы
Для использование механизма пересвязывания без промежуточной базы
следует выполнить следующие шаги в АРМе Каталогизатора:
1. Подключиться к локальному серверу.
96
2. Подключиться к удаленному серверу.
3. Найти аналитические записи записи для нужного выпуска сериального издания.
4. Скопировать записи в рабочую базу (например, ANALIT_2005).
5. Найти записи в рабочей базе.
6. Если результирующие записи устраивают, то продолжить работу над следующей партией записей (или завершить работу).
7. Если результаты пересвязывания не устраивают, то выполнить корректировку
записей
и
ручное
пересвязывание
в
рабочей
базе
(например,
ANALIT_2005).
Для ускорения работы механизмов пересвязывания записей рекомендуется провести переработку старого массива сериальных и аналитических записей
(уменьшить размер базы используемой для хранения сериальных изданий).
Если при предыдущей работе для хранения сериальных и аналитических записей использовалась база SERIAL, то рекомендуется выделить из этой базы все
аналитические записи и разместить их в отдельной базе (например,
ANALIT_OLD). Создать отдельную базу для хранения аналитических записей
(например, ANALIT) и использовать ее для хранения новых аналитических записей. Так как при использовании технологий заимствования объем баз может
расти гораздо более быстрыми темпами чем при самостоятельном создании
описаний, то рекомендуется заводить новую базу для хранения аналитики при
достижении текущей базы объема порядка 200000 тысяч записей.
6.3. Настройка средств фоновой обработки библиографических
записей
Сервер «Руслан» поддерживает возможность автоматической обработки
записей в библиографических или авторитетных базах на основе файлов с данными в формате RUSMARC, USMARC, UNIMARC. Обработка включает в себя
97
три операции: загрузка (вставка новой записи), обновление и удаление (для старых записей). При выполнении операции обновления запись в базе заменяется
на запись из файла целиком.
Сервер «Руслан» поддерживает четыре схемы автоматической обработки.
Далее в документе используются следующие обозначения схем: F001Type,
F035Type, MARSType, RKPType. Основное отличие в схемах – способ уникальной идентификации служебной записи. Для обеспечения работы данного сервиса используются два обязательных (для данного сервиса) параметра сервера:
LoadFilesDB
Содержит список библиографических баз для загрузки.
LoadFilesPath
Задает корневой каталог, от которого начинаются подкаталоги для размещения файлов, участвующих в операциях обработки. Не рекомендуется использовать в качестве корневого
каталога каталог, подключенный по сети – в случае сетевого
сбоя сервер может быть заблокирован на время сетевого
таймаута.
Если предполагается выполнять операции обновления и удаления, то
должны быть заданы четыре дополнительных параметра (присутствуют в дистрибутиве серверной части АБИС «Руслан» по умолчанию):
RF24
Содержит служебную строку для формирования запроса на
удаление библиографической записи (записей) из базы данных. Используется для схемы обработки RKPType.
RF25
Содержит служебную строку для формирования запроса на
удаление библиографической записи (записей) из базы данных. Используется для схемы обработки MARSType.
RF26
Содержит служебную строку для формирования запроса на
удаление библиографической записи (записей) из базы данных. Используется для схемы обработки F001Type.
RF27
98
Содержит служебную строку для формирования запроса на
удаление библиографической записи (записей) из базы данных. Используется для схемы обработки F035Type.
Настройка обработки файла
Для активизации процедуры обработки библиографических записей в
определенную базу необходимо выполнить следующую последовательность
действий:
1. К списку баз в параметре LoadFilesDB добавить название новой базы.
2. Убедиться в наличии корректного пути в параметре LoadFilesPath.
3. В случае, если планируются операции обновления или удаления, убедиться
в наличии запроса в параметре RFXX, соответствующем схеме загрузке.
4. Создать вложенные подкаталоги, начиная с корневого каталога, в соответствие со следующей последовательностью: имя базы, схема обработки
(F001TYPE, F035TYPE, MARSTYPE, RKPTYPE), операция (INSERT,
UPDATE, DELETE), формат записей (RUSMARC,USMARC,UNIMARC), кодировка записей (DOS,KOI,WIN,UTF8). Пример пути:
X:\Корневой_каталог\USMARC_DEMO\MARSTYPE\INSERT\USMARC\DO
S\test.mrc
5. Разместить в результирующем каталоге файлы, требующие определенной
обработки. Файл должен иметь расширение mrc.
6. Убедиться, что пользователь, под которым запущен сервер «Руслан» (сервис
RUSLANServiceR6), имеет право на чтение, запись и удаление файлов из
созданного каталога.
7. Перезапустить сервис RUSLANServiceR6.
Если в пути результирующего каталога будет отсутствовать тип операции, то будет выполняться операция INSERT (операция по умолчанию).
99
Если в пути результирующего каталога будет отсутствовать тип формата,
то он будет определяться автоматически (точное определение формата не гарантируется).
В случае успешного выполнения операции, обработанный файл удаляется для любой схемы обработки.
Размещение файлов в каталогах, указывающих на операции изменения и удаления, может привести к необратимым изменениям в базе. Необходимо ограничить доступ к таким каталогам.
Общие ограничения по использованию
Задача обработки файлов запускается сервером «Руслан» автоматически
в период времени с 00:00 по 04:00 в соответствии с приоритетом относительно
других фоновых задач. Завершение задачи к 04:00 не гарантируется. Объем выполняемой работы (а косвенно и время работы) ограничивается «условными»
10 Мб. Для операции вставки записей (INSERT) объем рассчитывается как сумма объема всех файлов, определенных для данной операции. Для операций удаления (DELETE) используется повышающий коэффициент 9, для операций изменения (UPDATE) повышающий коэффициент равен 10. Коэффициенты корректны для баз объемом до 100000 записей. Ограничение в 10 Мб действует на
суммарный объем по всем трем операциям. Т.е. для 3 файлов размером по 300
Кб, определенных для всех трех операций «условный» объем будет равен 300 +
300*9 + 300*10 = 6 Мб.
Таким образом, посредством данного сервиса, за один сеанс можно загрузить порядка 5-20 тысяч записей или осуществить изменение порядка 5002000 библиографических записей. Реальное количество может сильно варьироваться в зависимости от производительности используемого компьютера и от
размера базы, над которой проводится операция.
Если обработка файла была отменена по причине ограничения суммарного объема нескольких файлов, то его обработка будет запускаться во всех по100
следующих сессиях, пока он не будет успешно загружен (и удален из каталога
сервером «Руслан») или не будет явно удален администратором из каталога обработки.
Сервис автоматической обработки файлов синхронизирован по времени с
другими задачами, инициируемыми самим сервером. Но для задач, инициируемых внешними по отношению к серверу «Руслан» средствами, требуется «ручная» синхронизация.
Необходимо отслеживать следующие моменты:
1. Контролировать пересечение по времени с автоматическим архивированием
физической БД Oracle.
2. Контролировать пересечение по времени с процедурами пакетного изменения, запускаемого из АРМа Администратора.
3. Контролировать пересечение по времени с процедурами загрузки и индексирования, запускаемых из АРМа Администратора.
Диагностика
В качестве средства контроля результата выполнения операций используется единый для всего сервера «Руслан» механизм – системный монитор событий (EventLog). Для сервиса автоматической обработки файлов определен код
сообщения 120. Смысл диагностического сообщения объясняется в текстовой
части.
Особенности обработки для схемы F001Type
Схема обработки F001Type предназначена для обработки записей, получаемых от источника, гарантирующего уникальность идентификатора записи
(ключа записи), хранящегося в поле 001 форматов семейства MARC. При выполнении операции вставки идентификатор записи не изменяется. Операция
101
изменения основывается на поиске записи по ее идентификатору (поле 001).
Операция удаления не поддерживается.
Особенности обработки для схемы F035Type
Схема обработки F035Type предназначена для обработки записей, получаемые от источника, не гарантирующего уникальность идентификатора записи (ключа записи), хранящегося в поле 001 форматов семейства MARC. При
выполнении операции вставки идентификатор записи изменяется, старое значение сохраняется в поле 035. Операции удаления и изменения основываются
на поиске записи по ее старому идентификатору (поле 035). Для данной схемы
не гарантируется корректное выполнение операций изменения и удаления
записей.
Особенности обработки для схемы MARSType
Схема обработки MARSType предназначена для обработки записей получаемых в рамках проекта МАРС. Значение идентификатора записи (ключа записи) хранящегося в поле 001 должно быть уникальным. Записи идентифицируются блоками, по значению, хранящемуся в поле 910a, и имени файла.
При выполнении операции вставки идентификатор записи не изменяется. Операции удаления и изменения основываются на поиске по специальному атрибуту основанному на поле 910a. Все операции идут только над блоком записей в
целом. Ошибка при выполнении любой операции над любой записью из блока
вызывает выдачу диагностического сообщения и прекращение обработки
файла (без его удаления).
Примечание. В более ранних версиях сервера при выполнении операции вставки генерировался новый идентификатор, а старое значение идентификатора
сохранялось в поле 035.
102
Особенности обработки для схемы RKPType
В данный момент схема обработки RKPType аналогична схеме обработки
F001Type. Операции изменения и удаления не используются.
6.4. Настройка средств фоновой обработки служебных записей
Сервер «Руслан» поддерживает возможность автоматической обработки
записей в служебных базах на основе файлов с данными во внутреннем формате АБИС «Руслан». Обработка включает в себя три операции: загрузка (вставка
новой записи), обновление и удаление (для старых записей). Результирующая
запись операции обновления получается как сумма следующих наборов тегов:
➔
«новых» тегов из записи в файле (которых не было в записи из базы);
➔
«старых» тегов из записи в базе (которых не было в записи из файла);
➔
«общих» тегов, взятых из записи в файле (значения тегов в файле затирают
значения тегов в базе).
Сервер «Руслан» поддерживает три схемы автоматической обработки.
Далее в документе используются следующие обозначения схем: R001Type,
R010Type, R100Type. Основное отличие в схемах – способ уникальной идентификации служебной записи. Для обеспечения работы данного сервиса используются два параметра сервера:
LoadFilesDB
Содержит список служебных баз для обработки.
LoadFilesPath
Задает корневой каталог, от которого начинаются подкаталоги для размещения файлов, участвующих в операциях обработки. Не рекомендуется использовать в качестве корневого
каталога каталог, подключенный по сети – в случае сетевого
сбоя сервер может быть заблокирован на время сетевого
таймаута.
103
Настройка обработки файла
Для активизации процедуры обработки служебных записей в определенной базе необходимо выполнить следующую последовательность действий:
1. К списку баз в параметре LoadFilesDB добавить название новой базы.
2. Убедиться в наличии корректного пути в параметре LoadFilesPath.
3. Создать вложенные подкаталоги, начиная с корневого каталога, в соответствие со следующей последовательностью: имя базы, схема обработки
(R001TYPE, R010TYPE, R100TYPE), операция (INSERT,UPDATE,DELETE),
формат записей (RUSLAN), кодировка записей (DOS,KOI,WIN,UTF8). Пример пути:
X:\Корневой_каталог\LUSR\R010TYPE\UPDATE\RUSLAN\DOS\users.dat
4. Разместить в результирующем каталоге файлы, требующие определенной
обработки. Файл должен иметь расширение dat.
5. Убедиться, что пользователь, под которым запущен сервер «Руслан» (сервис
RUSLANServiceR6), имеет право на чтение, запись и удаление файлов из созданного каталога.
6. Перезапустить сервис RUSLANServiceR6.
Если в пути результирующего каталога будет отсутствовать тип операции, то будет выполняться операция INSERT (операция по умолчанию).
Если в пути результирующего каталога будет отсутствовать тип формата,
то обработка файла будет прекращена.
В случае успешного выполнения операции обработанный файл удаляется
для любой схемы обработки.
Размещение файлов в каталогах, указывающих на операции изменения и удаления, может привести к необратимым изменениям в базе. Необходимо ограничить доступ к таким каталогам.
104
Общие ограничения по использованию
Задача обработки файлов запускается сервером «Руслан» автоматически
в период времени с 00:00 по 04:00 в соответствии с приоритетом относительно
других фоновых задач. Завершение задачи к 04:00 не гарантируется. Объем
выполняемой работы (а косвенно и время работы) ограничивается «условными» 10 Мб. Для операции вставки записей (INSERT) объем рассчитывается как
сумма объема всех файлов определенных для данной операции. Для операций
удаления (DELETE) используется повышающий коэффициент 9, для операций
изменения (UPDATE) повышающий коэффициент равен 10. Коэффициенты
корректны для баз объемом до 100000 записей. Ограничение в 10 Мб действует
на суммарный объем по всем трем операциям. Т.е. для 3 файлов размером по
300 кб, определенных для всех трех операций «условный» объем будет равен
300 + 300*9 + 300*10 = 6 Мб.
Таким образом, посредством данного сервиса за один сеанс можно загрузить порядка 5-20 тысяч записей или осуществить изменение порядка 500-2000
библиографических записей. Реальное количество может сильно варьироваться
в зависимости от производительности используемого компьютера и от размера
базы, над которой проводится операция.
Если обработка файла была отменена по причине ограничения суммарного объема нескольких файлов, то его обработка будет запускаться во всех последующих сессиях, пока он не будет успешно загружен (и удален из каталога
сервером «Руслан») или не будет явно удален администратором из каталога обработки.
Сервис автоматической обработки файлов синхронизирован по времени с
другими задачами инициируемыми самим сервером. Но для задач инициируемых внешними по отношению к серверу «Руслан» средствами требуется «ручная» синхронизация.
Необходимо отслеживать следующие моменты:
105
1. Контролировать пересечение по времени с автоматическим архивированием
физической БД Oracle.
2. Контролировать пересечение по времени с процедурами пакетного изменения, запускаемого из АРМа Администратора.
3. Контролировать пересечение по времени с процедурами загрузки и индексирования, запускаемых из АРМа Администратора.
Диагностика
В качестве средства контроля результата выполнения операций используется единый для всего сервера «Руслан» механизм – системный монитор событий (EventLog). Для сервиса автоматической обработки файлов определен код
сообщения 120. Смысл диагностического сообщения объясняется в текстовой
части.
Особенности обработки для схемы R001Type
Схема обработки R001Type предназначена для обработки записей получаемых от источника, гарантирующего уникальность идентификатора записи
(ключа записи в теге 1). При выполнении операции вставки идентификатор записи не изменяется. Операции удаления и изменения основываются на поиске
записи по ее идентификатору (тег 1). Операция удаления не поддерживается.
Данная схема ориентирована на обработку служебных записей, выгружаемых из рабочей версии сервера «Руслан».
Особенности обработки для схемы R010Type
Схема обработки R010Type предназначена для обработки записей получаемых от источника, не гарантирующего уникальность идентификатора записи (ключа записи в теге 1), но гарантирующего уникальность внешнего
идентификатора, который должен размещаться в теге 10. При выполнении
106
операции вставки генерируется новый идентификатор записи (в теге 1). Операции удаления и изменения основываются на поиске записи по внешнему
идентификатору (тег 10). Операция удаления не поддерживается.
Данная схема ориентирована на обработку служебных записей, выгружаемых из внешних систем (АСУ ВУЗа).
Особенности обработки для схемы R100Type
Схема обработки R100Type предназначена для обработки служебных записей о читателях. В качестве идентификатора операций используется уникальный идентификатор читателя (тег 100). При выполнении операции вставки генерируется новый идентификатор записи (в теге 1). Операции удаления и
изменения основываются на поиске записи по идентификатору читателя (тег
100). Операция удаления не поддерживается.
Данная схема ориентирована на обработку служебных записей, выгружаемых из внешних систем и должна применяться, если схемы R001TYPE и
R010TYPE по каким-либо причинам использовать не удается.
6.5. Настройка экспорта и импорта данных для АСУ ВУЗа
В АБИС «Руслан» можно реализовать два варианта создания описания
читателя. Первый вариант, обеспечивающий индивидуальное описание читателя, реализован в АРМе Книговыдачи. Данный режим наиболее приемлем для
библиотек, не имеющих какой-либо автоматизированной системы учета читателей, не связанной с АБИС. Второй вариант предполагает экспорт данных из
внешней системы учета читателей, а также периодическую синхронизацию
данных в АБИС и внешней системе. Этот вариант характерен для большинства
библиотек ВУЗов, где АСУ ВУЗа, как правило, содержит большую часть информации необходимую для описания читателя в АБИС. Взаимодействие
107
АБИС Руслан и АСУ ВУЗа можно представить состоящим из трех независимых процессов:
➔
первоначальный импорт данных из АСУ ВУЗа в АБИС;
➔
периодическое обновление информации в АБИС на основе данных, поступающих из АСУ ВУЗа;
➔
периодический импорт данных из АБИС в АСУ ВУЗа.
Первоначальный импорт информации о читателях
Для импорта информации о читателях в АБИС «Руслан» необходимо
подготовить файл описаний читателей, содержащий записи во внутреннем
формате АБИС «Руслан». Физическая структура формата приведена в Приложении 3. Набор тегов, используемых в служебных базах, в том числе, содержащих описания читателей библиотеки, приведен в документе «Список тегов
АРМа Книговыдачи». Набор специальных (зарезервированных) тегов приведен
в Приложение 2.
Если в данных АСУ ВУЗа есть уникальный идентификатор описания читателя, то его можно использовать и как уникальный идентификатор в АБИС
«Руслан», т.е. отображать его в тег 1. К значению тега 1 выдвигаются два требования: значение должно быть числом (содержать только символы цифр) и
значение должно быть уникальным на всем протяжении времени пока запись о
читателе будет храниться в АБИС «Руслан» (информация о выбывшем читателе размещается в архивной базе и хранится там до явного удаления администратором АБИС). Если в выходных записях присутствует тег 1, то при загрузке в АРМе Администратора нужно не указывать признак «Генерировать ключ
записи». При использовании тега 1 для хранения идентификатора читателя, потенциальные возможности для интеграция АСУ ВУЗа и АБИС максимальны.
В этом случае возможности по добавлению читателей в обход АСУ ВУЗа (по-
108
средством АРМа Книговыдачи) должны быть ограничены для обеспечения
возможности обратного экспорта.
Для хранения уникального внешнего идентификатора читателя, зарезервирован тег 10. Использование тега 10 вместо тега 1 предпочтительнее, если
предполагается создание описаний читателей в АРМе Книговыдачи. При загрузке в АРМе Администратора таких записей нужно указывать признак «Генерировать ключ записи».
Из всех тегов, используемых при создании записи о читателе, обязательным являются только тег 100, содержащий штрих-код читателя. Существует
три стратегии формирования значения тега 100:
1. Использование какого-либо внешнего уникального кода, который присвоен
читателю библиотеки внешней информационной системой (например, в
АСУ ВУЗа). Данный способ предпочтительнее, если организация уже имеет
средства технического контроля доступа на основе магнитных карточек,
карточек со штрих-кодовым кодированием и т.п. При таком решении
компьютеры библиотеки должны быть оснащены соответствующими
устройствами считывания информации с карт. В этом варианте значения тегов 1, 10 и 100 могут быть эквивалентными.
2. Генерация уникального кода при составлении записи о читателе какой-либо
внешней программой. Данный способ подходит, когда неприменим вариант
1 и полученные таким способом записи о читателе используются для пакетной печати читательских билетов из АРМа Книговыдачи.
3. Устанавливается единая для всех константа, которая гарантированно не
пересекается со значениями тега 100 уже имеющимися в записях о читателях. Присвоение уникального значения должно производиться при первом
посещении читателем библиотеки. Данный способ подходит, когда не подходят варианты 1 и 2, или используются предварительно изготовленные
штрих-коды (в виде наклеек на «стандартные» читательские билеты или в
виде выдаваемых читателям не-именных пластиковых карточек).
109
Для формирования файла с данными во внутреннем формате АБИС «Руслан» можно воспользоваться специализированным конвертором, позволяющем получить требуемый формат из данных, размещенных в текстовом файле с
символом табуляции в качестве разделителя колонок. Файл в таком формате
можно получить сохранив данные из MS Excel, указав типа файла «Текстовые
файлы (с разделителями табуляции)(*.txt)». Указания по использованию конвертора можно получить, запустив его без указания параметров. При сопоставлении колонок текстового файла и тегов необходимо учесть специальную обработку для тегов 101, 102, 103 (соответственно фамилия, имя и отчество читателя). Если в текстовом файла имя и отчество находится в одной колонке с фамилией и при конвертировании указано что этой колонке соответствует тег
101, то конвертор автоматически отделит второе и третье слово и поместит их
в теги 102 (имя) и 103 (отчество). Четвертое и последующие слова в колонке
игнорируются.
Формат записи данных некоторых тегов (109, 112, 113, 114) должен
соответствовать формату записи данных в файле list.ini АРМа Книговыдачи. В частности, необходимо обратить внимание, что «тип» организации или ее
подразделения не должен быть включен в название организации или подразделения. Например, должно быть:
@109,5,1,9=Факультет@112,5,1,22=Инженерно-строительный
а не:
@109,5,1,9=Факультет@112,5,1,22=Инженерно-строительный
факультет
и:
@109,5,1,9=Факультет@112,5,1,22=Технической кибернетики
а не:
@112,5,1,33=Факультет технической кибернетики
Тег 115 используется для хранения пароля читателя. Наличие пароля
необходимо только для обеспечения читателя возможностью формирования и
110
контроля электронного заказа из АРМа Читателя. Наличие или отсутствие у читателя пароля не влияет на его обслуживание в АРМе Книговыдачи.
Периодическое обновление информации в АБИС на основе данных,
поступающих из АСУ ВУЗа
Периодическое обновление информации о читателе (в первую очередь
информацию о статусе читателя) можно реализовать, воспользовавшись сервисом обработки служебных записей из файла. Эта технология позволяет синхронизовать данные в АСУ ВУЗА и АБИС «Руслан» с частотой до одного раза в
сутки.
В зависимости от способа формирования уникального идентификатора
записи о читателе, необходимо выбрать наиболее подходящую схему обработки.
При формировании записей для обновления информации о читателях
необходимо гарантировать отсутствие в них тегов, которые могут модифицироваться в АБИС «Руслан» в процессе обслуживания читателя.
Периодический экспорт данных из АБИС в АСУ ВУЗа
В ряде ВУЗов возникает задача экспорта части данных из АБИС
«Руслан» в АСУ ВУЗа. К таким данным относится любая информация, которая
обновляется в библиотеке чаще, чем в ВУЗе (информация об адресе, о паспортных данных и т.п.).
В АБИС «Руслан» можно воспользоваться двумя способами для экспорта
служебных данных:
1. Стандартная возможность выгрузки служебных данных во внутреннем формате АБИС «Руслан». Для обеспечения безопасности при выгрузке следует
удалить тег 115, указав его в поле «Удалить теги» (см. п.5.9).
111
2. Экспорт отдельных тегов служебных записей с помощью функций
GetTagValueByTag, GetTagNocaseUniqueValue и GetTagUniqueValue механизма пакетной обработки данных.
6.6. Настройка сервера для поддержки процесса
автоматизированной книговыдачи
Вариант сервера «Руслан-лайт» поставляется сконфигурированным, и не
требует дополнительных настроек. Вариант сервера «Руслан-лайт» не обрабатывает параметры конфигурирования, используемые в корпоративной версии
сервера кроме параметров CircADB и CircADBs.
Корпоративная версия сервера «Руслан» поставляется сконфигурированной в минимальной степени. В некоторых случаях может потребоваться изменить настройки по умолчанию или расширить их.
Настройка корпоративной версии сервера «Руслан» для поддержки процесса книговыдачи состоит из следующих шагов:
1. Для сотрудников отделов библиотеки, непосредственно занятых в процессе
обслуживания читателей, требуется добавить право на вставку, модификацию и удаление записей в базе выданных книг (по умолчанию создается база
с именем CIRC). Данная база должна быть указана в параметре сервера
CircDB. База CIRC должна прописывается в настройках АРМа Книговыдачи.
2. Настроить текущую базу архива выданных книг (по умолчанию создается
база ACIRC). Имя базы должно быть указано в параметре сервера CircADB.
В данную базу перемещаются служебные записи о выданных книгах при
возврате их читателем. Дополнительных прав доступа на архивную базу выданных книг не требуется. Рекомендуется периодически создавать новую
базу архива выданных книг при заполнении текущей архивной базы примерно до 100000-150000 записей или при выявлении существенного замедления
112
процесса списания книги с читателя. Все архивные базы, включая текущую,
должны быть указаны в параметре сервера CircADBs.
3. Настроить виртуальную базу архива выданных книг (ALLACIRC), в которую
на первом этапе включить только текущую архивную базу. По мере создания новых архивных баз необходимо модифицировать описание виртуальной базы. База ALLACIRC должна прописывается в настройках АРМа Книговыдачи.
4. Для сотрудников отделов библиотеки, непосредственно занятых в процессе
обслуживания читателей, требуется добавить право на вставку, модификацию и удаление записей в базе читателей (по умолчанию создается одна база
с именем LUSR). Необходимость нескольких баз может возникнуть, если в
библиотеке обслуживаются несколько групп читателей, регистрация которых выполняется обязательно различными подразделениями библиотеки.
Данные базы должна быть указаны в параметре сервера ReaderDBs. Необходимо контролировать, чтобы базы, указанные в параметре ReaderDBs,
были реальными (т.е. были видны в списке баз, отображаемом АРМом
Администратора).
5. Настроить виртуальную базу (ALLUSERS), содержащую описания всех читателей. По умолчанию, в виртуальную базу включена только база LUSR. При
создании новых баз читателей необходимо модифицировать описание виртуальной базы. База ALLUSERS должна прописываться в настройках АРМа
Книговыдачи. В ряде случаев, в некоторых установленных АРМах Книговыдачи может прописываться отдельная реальная база читателей. В этом случае читатели, описанные в других базах, будут недоступны для обслуживания в данных АРМах.
6. Настроить архивную базу описаний читателей (по умолчанию создается база
ALUSR). Данная база должна быть указана в параметре сервера ReaderADB.
7. Настроить базу очередей (по умолчанию создается база QUEUE). Данная база
должна быть указана в параметре сервера QueueDB.
113
Описание настройки АРМа Книговыдачи для поддержки технологического цикла автоматизированной книговыдачи смотрите в документации на
АРМ Книговыдачи.
Отсутствие настроек диспетчеризации электронного заказа и/или настроек сбора статистики книговыдачи не влияет на процесс автоматизированной книговыдачи.
ВНИМАНИЕ! Не допускается проводить операции выгрузки/загрузки библиографических записей (а также проводить любые другие действия которые могут привести к изменению внутреннего или внешнего идентификатора библиографической записи), на которые есть ссылки в базе выданных книг (CIRC).
Сервер «Руслан» не позволяет удалять библиографические записи, на которые есть ссылки в базе выданных книг (CIRC) посредством АРМа Комплектования/Каталогизации, но в АРМе Администратора удаление таких записей возможно. Удаление записей в базе CIRC можно выполнять с использованием
АРМа Администратора только если удаление в АРМе Книговыдачи по стандартной схеме по каким-либо причинам невозможно.
6.7. Настройка сервера для поддержки процесса контроля
читателем выданных на руки книг
Контроль читателем выданных на руки книг выполняется посредством
АРМа Читателя. Описание настроек АРМа Читателя для поддержки этого режима смотрите в документации на АРМ.
Настройка сервера «Руслан» заключается в установке корректного значения
размера
штрафа
за
день
просрочки
(в
параметре
сервера
PenaltyPerDay). В параметре сервера PenaltyCurrency должна быть
установлена денежная единица, в которой рассчитывается штраф (по умолчанию, «руб.»).
114
6.8. Настройка сервера для поддержки процесса сбора статистики
книговыдачи
Сервер «Руслан» осуществляет предварительную обработку данных книговыдачи за каждые сутки. Расчет статистики начинается в диапазоне времени
23:50-24:00. Результат предварительной обработки помещается в базу
CIRCSTAT.
Расчет статистических значений идет по трем основным показателям:
➔
выдача документа пользователю (по факту добавления записи в базу, указанную в параметре CircDB);
➔
возврат документа (по факту добавления записи в базу, указанную в параметре CircADB);
➔
посещаемость.
Посещаемость рассматривается как одна непрерывная цепочка операций
выдачи или возврата документов одним читателем одному сотруднику библиотеки. Также могут строиться два дополнительных одномерных распределения:
по времени выдачи/возврата документов и по содержанию выдаваемых документов (областям знаний). Деление распределения по содержанию аналогично
делению при расчете КСУ.
Каждый
статистический
показатель рассчитывается для объектов
четырех классов. Первый класс (1) – это библиотека в целом (всегда одна запись в базе CIRCSTAT за сутки). Объекты второго класса (2) – это фонды (сиглы) из которого происходила выдача за сутки. Третий класс (3) объектов – это
точка выдачи (ТВ). Под точкой выдачи подразумевается абстрактный идентификатор устанавливаемый на каждом экземпляре АРМа Книговыдачи (на каждом рабочем месте, где установлен АРМа Книговыдачи). Если на нескольких
экземплярах АРМа Книговыдачи установить одинаковый идентификатор ТВ,
то по ним будет производиться суммарный учет. Четвертый класс объектов –
это сотрудники библиотеки.
115
Сервер «Руслан» позволяет построить одно двухмерное распределение в
качестве расширения одномерного распределения по содержанию документов.
Второй размерностью может служить набор значений, который задается через
параметр STATAddDistr (не более 10 агрегированных значений) одного из
тегов (тег задается через параметр STATAddDistrAttr) записи из базы выданных книг. В случае отсутствия в служебной записи нужного тега берется
значение, указанное в параметре STATAddDistrDefValue. Параметр
STATAddDistrLevel ограничивает класс объектов, для которых рассчитывается двухмерное распределение (значение по умолчанию 1, не рекомендуется
устанавливать значение этого параметра больше чем 2). В параметрах сервера,
по умолчанию, для расчета двухмерного распределения, второй размерностью
служит категория читателя.
Настройка сервера «Руслан» для поддержки процесса сбора статистики
книговыдачи состоит из следующих шагов:
1. Проверить наличие служебной базы CIRCSTAT.
2. Установить значение параметра сервера STATClassDistrLevel в наиболее приемлемое для библиотеки значение. Значение параметра устанавливает минимальный класс, для которого строятся дополнительные распределения (значение по умолчанию 3, т.е. для всех классов исключая сотрудников
библиотеки).
3. При необходимости, можно настроить условия распределения по содержанию в параметрах сервера KSUBBKMap и/или KSUUDCMap. В публичных
библиотеках эти параметры настроены для формирования КСУ и изменять
их не рекомендуется. Для библиотек ВУЗов, как правило, при расчете КСУ
эти параметры не задействованы и потребуется их дополнительная настройка.
4. При необходимости, перенастроить параметры двухмерного распределения,
установленные по умолчанию.
116
6.9. Настройка сервера для диспетчеризации электронного заказа
документов
Сервер «Руслан» осуществляет прием и диспетчеризацию электронных
заказов. Заказ формируется с использованием АРМа Читателя (самостоятельно
читателем) или АРМа Книговыдачи (сотрудником библиотеки на основании
традиционного требования, предъявляемого читателем). Описание настройки
АРМов для поддержки возможности электронного заказа документов приведено в документации на соответствующий АРМ.
В зависимости от типа заказа и настроек сервера «Руслан», заказ может
быть направлен на обработку или в АРМ Книговыдачи или в АРМ МБА. Описание процедур обработки электронного заказа приведено в документации на
соответствующие АРМы.
Контроль исполнения электронного заказа производится читателем посредством АРМа Читателя. Описание настройки АРМа Читателя для поддержки возможности контроля электронного заказа документов приведено в документации на АРМ Читателя.
В данном разделе не рассматривается вопрос диспетчеризации электронного заказа на обработку в АРМе МБА. Необходимыми условиями диспетчеризации электронного заказа на обработку в АРМе Книговыдачи являются:
➔
Читатель библиотеки, выполняющий заказ, должен обладать статусом локального читателя.
➔
База с библиографическими описаниями, из которой выполняется заказ,
должна иметь статус локальной.
➔
Электронный заказ должен быть на получение документа во временное хранение (получение книги на «руки»). Заказа электронной копии документа
всегда направляется на обработку в АРМ МБА.
117
Настройка сервера «Руслан», для поддержки процесса электронного заказа документа состоит из следующих шагов:
1. Проверить наличие служебной базы EXTD (создается по умолчанию) и определения для нее синонима IR-Extend-1.
2. Проверить значение параметру сервера DenyOrder, который определяет
доступен сервис заказа на книговыдачу или нет. Если значение параметра
отлично от 0, то сервис электронного заказа для локального читателя будет
не доступен. При попытке формирования заказа читатель будет получать
диагностическое сообщение, заданное в параметре сервера DenyOrderMag.
Параметр DenyOrder не влияет на прием заказов на МБА и используется
для избирательного отключения только приема заказов на книговыдачу (используется в библиотеках ВУЗов).
3. Установить параметр сервера ServDep так, чтобы он содержал список всех
сигл библиотеки, из которых возможен электронный заказ на книговыдачу.
4. В соответствии с планами библиотеки по организации обработки электронных заказов необходимо создать одну или несколько групп прав доступа, с
указанным правом Order.
5. Установить параметр сервера MapDepartGroup так, чтобы он содержал таблицу отображения сигл библиотеки в специальные группы прав доступа
(которые содержат право Order). Отсутствие данных в указанном параметре
делает невозможной корректную диспетчеризацию электронных заказов.
6. Установить значение параметра сервера UseMultiDepartOrder в наиболее подходящее для библиотеки значение. Значение больше 0 разрешает
при формировании электронного заказа указывать несколько возможных
сигл (значение по умолчанию равно 0).
7. Параметр сервера PriorityDepartList содержит приоритетный список сигл в случае заказа из нескольких сигл. Используется совместно с параметр UseMultiDepartOrder. Если в электронном заказе указывается
118
несколько сигл, то для обработки выбирается сигла указанная в параметре
PriorityDepartList ближайшая к началу списка.
Первичная обработка электронного заказа сервером «Руслан» состоит из
двух этапов. На первом этапе проверяется выполнимость заказа. На втором этапе происходит назначение специальных прав на обработку электронного заказа
соответствующей группе сотрудников библиотеки.
Проверка выполнимости электронного заказа
Определение выполнимости заказа включает в себя проверку следующих
условий (ограничений):
1. Проверяется, что обрабатываемое в электронном заказе библиографическое
описание ссылается на физический объект (не является описанием общей
части многотомного издания, описанием журнала в целом, описанием составной части документа и т.д.).
2. Проверяется наличие сиглы в электронном заказе. Проверяется допустимость указанной читателем сиглы. Сиглы, из которых, по правилам библиотеки, разрешено формировать электронный заказ, должны быть указаны в
параметре сервера ServDep. Описание дополнительных ограничений по
сиглам, из которых возможен электронный заказ, приведено в документации
на АРМ Читателя.
3. Проверяется количество сигл в электронном заказе. Для многоэкземплярных
документов, хранящихся в нескольких сиглах, АРМ Читателя позволяет указать несколько сигл при формировании электронного заказа. Если количество
сигл
больше
одной,
а
значение
параметра
сервера
UseMultiDepartOrder равно 0, то выдается диагностическое сообщение
о невозможности обработки заказа.
4. Проверяется наличие экземпляров документа в указанной сигле (без проверки доступности экземпляров).
119
5. Проверяется наличие необработанного электронного заказа на то же издание в текущий день (исключение дублетного заказа).
Если хотя бы одно условие не выполняется, заказ на выполнение не принимается и выдается соответствующая диагностика.
Назначение специальных прав на обработку заказа
К специальным правам доступа относится право обслуживать заказы на
книговыдачу (право Order) или МБА (право ILL) из библиографической базы.
Для каждого электронного заказа указывается, как минимум, право чтения заказа его владельцем. Для корректной обработки заказа должна быть получена
хотя бы одна группа специальных прав доступа. Нахождение специальных
групп прав доступа производится по следующему алгоритму:
1. Находятся все группы с правом Order для базы из которой выполняется
электронный заказ.
2. На основе таблицы отображения сигл и групп прав доступа, заданной в параметре сервера MapDepartGroup, выбираются необходимые группы прав
доступа в соответствии с сиглой, из которой был выполнен заказ. Если при
формировании заказа было указано несколько сигл и в параметре сервера
UseMultiDepartOrder указано значение больше 0, то берется первая
подходящая сигла (в которой есть экземпляр книги и из которой разрешен
электронный заказ) в соответствии с приоритетным списком сигл заданных
в параметре сервера PriorityDepartList.
Проверка корректности обработки заказа сервером «Руслан»
Проверку корректности настройки сервера можно оценить, выполнив тестовый электронный заказ. При «успешном» его выполнении (т.е. если в АРМе
Читателя не появилось диагностическое сообщение) в служебной базе EXTD
должна появиться новая запись. При корректной настройке параметров сервера
120
в записи должно быть не меньше чем 2 экземпляра тега 21. В первом экземпляре тега должен быть указан идентификатор читателя, выполнившего заказ. Во
втором экземпляре тега должна быть указана группа прав доступа. В АРМе
Книговыдачи данный электронный заказ будет «виден» только сотрудникам
библиотеки, входящим в установленную для заказа группу прав доступа.
6.10. Настройка сервера для поддержки процесса инвентаризации
фонда
Система «Руслан» позволяет организовать проведение электронной инвентаризации фонда с целю выяснения фактического состояния фонда, а также
выявления разного рода ошибок возникающих в процессе использования фонда.
Электронная инвентаризация всего фонда может быть разбита на
несколько этапов, каждый из которых состоит из следующих шагов:
1. Выбрать диапазон фонда для электронной инвентаризации и, при необходимости, провести подготовительные работы в соответствии с технологическими особенностями библиотеки. Размер диапазона рекомендуется выбирать в диапазоне 1000-10000 экземпляров. Определенные ограничения также могут накладывать технические средства, используемые для
чтения штрих-кодов или RFID меток.
2. Последовательно считать специализированным сканером штрих-коды
или RFID метки экземпляров в выбранном диапазоне.
3. Передать файл со штрих-кодами или RFID метками на компьютер где
установлен АРМ Администратора. Процедура инвентаризации требовательна к ресурсам, поэтому рекомендуется использовать экземпляр АРМа
Администратора установленный на той же машине что и СУБД Oracle.
4. Запустить процедуру инвентаризации в АРМе Администратора.
121
5. Обработать файл отчета, сформированный АРМом Администратора на
предыдущем этапе, и устранить выявленные ошибки в расстановке фонда
и/или в записях в электронном каталоге. При использовании RFID сканера с возможностью поиска RFID меток, метки «ошибочных» экземпляров можно взять из первой колонки файла отчета.
6. Повторить шаги 1-5 необходимое количество раз.
Рис. 51-1
После завершения всех этапов общую статистику об инвентаризации
фонда можно получить в АРМе Статистика.
122
В зависимости от специфики библиотеки приведенная выше последовательность действий может быть изменена. Серверная часть АБИС «Руслан» задействована только на шаге 4 и взаимодействует с предыдущими шагами только посредством файла со штрих-кодами. Требования к файлу штрих-кодов минимальны – каждый штрих-код должен быть на отдельной строке и состоять
только из цифр.
Запуск инвентаризации выполняется из АРМа Администратора через
контекстное меню библиографических баз. Для этого, в списке баз необходимо
выделить те библиографические базы, которые могут содержать записи инвентаризируемого фонда и выбрать пункт меню «Инвентаризация» (АРМ Администратора 1.8.x и выше). В появившемся окне «Инвентаризация» необходимо
заполнить все поля доступные для ввода (рис.51-1).
В зависимости от типа расстановки в фонде потребуется выбрать способ
задания диапазона инвентаризации. При расстановке на основе полочного индекса должен быть введен список индексов в том же порядке в котором производилось сканирование штрих-кодов. При инвентарной расстановке обязательным для ввода являются только первый и последний инвентарный номер
диапазона (цифровая часть инвентарного номера). Если у инвентарных номеров есть префикс или суффикс, то их необходимо ввести в соответствующие
поля вмести с символом разделителем (если он присутствует в инвентарном номере). Электронная инвентаризация при инвентарной расстановке может
проводиться только для диапазона включающего в себя только одинаковые префиксы и/или суффиксы! Поле описания этапа инвентаризации служит для ввода краткой характеристики этапа инвентаризации, его особенностей и применяется в случае проведения многоэтапной инвентаризации.
В результате электронной инвентаризации выявляются несколько типов
ошибок:
123
• Штрих-код из диапазона инвентаризации не найден в фонде (отсутствует в файле штрих-кодов) и отсутствует в базе выданных
книг. Код ошибки CLOST.
• Штрих-код из файла не входит в диапазон инвентаризации, но находитcя в ЭК (в поле 999). Код ошибки C999.
• Штрих-код из файла не входит в диапазон инвентаризации, но находитcя в ЭК как списанный экземпляр (в поле 989). Код ошибки
C989
• Штрих-код из файла не входит в диапазон инвентаризации, и не
находитcя в ЭК. Код ошибки FLOST.
• Штрих-код из файла находится в диапазоне инвентаризации, но
размещение на полке не соответствует порядку. Код ошибки
PLOST.
• Штрих-код из диапазона инвентаризации, отсутствует полочный
индекс. Код ошибки SCLOST.
• Штрих-код из файла, отсутствует полочный индекс. Код ошибки
SFLOST.
Результат электронной инвентаризации сохраняется в простом текстовом
файле состоящем из семи колонок:
1. штрих-код, для которого была выявлена ошибка
2. код ошибки
3. инвентарный номер/полочный индекс для штрих-кода
4. инвентарный номер/полочный индекс ближайшего корректного экземпляра
5. краткое описание (автор/заглавие)
6. библиографическая база
7. ключ библиографической записи (поле 001)
124
Разделителем колонок служит символ табуляции. В зависимости от типа
ошибки значения в некоторых колонках могут отсутствовать. Файл в приведенном формате ориентирован на открытие в MS Excel, встроенные средства которого позволяют получить различные формы группировок данных.
ШК
+
+
+
+
+
+
+
Ошибка
CLOST
C999
C989
FLOST
PLOST
SCLOST
SFLOST
Собст.инв
+
+
+
+
Ближ.инв
+
+
+
+
+
Описание
+
+
+
+
+
+
База
+
+
+
+
+
+
Ключ
+
+
+
+
+
+
Настройка сервера «Руслан» для поддержки процесса инвентаризации состоит из следующих шагов:
1. Проверить наличие служебной базы INVENT, при отсутствии создать ее.
2. Проверить, что подполе 989y индексируется по типу «50», и при необходимости выполнить соответствующую настройку.
3. Проверить наличие точки доступа 9895 по полю 989y и, при необходимости, выполнить соответствующую настройку.
4. Если точка доступа добавлялась на шаге 3, то необходимо:
4.1. Выполнить операцию «Обновить ТД» для всех библиографических
баз.
4.2. Проиндексировать все библиографические базы. Индексирование
можно ограничить подполем 989y, для чего в поле «Таблица индексирования» задать «#989y50».
125
7. Архивирование данных
Существует два подхода к архивированию. Первый подход – основной –
архивирование средствами СУБД. Второй подход – дополнительный – архивирование средствами АРМа(ов).
7.1. Архивирование средствами СУБД Oracle
СУБД Oracle имеет развитую систему архивирования и восстановления
(см. Oracle Backup and Recovery Guide). Наиболее простым способом архивирования является архивирование источников данных (библиотечных и служебного) целиком. Возможная потеря данных – за период с момента создания последнего архива (при хранении всех архивов). Достоинством является малое
время восстановления. Недостатком – сложность восстановления в случае, если
структура БД не была повреждена и требуется восстановить несколько записей
из библиотечных БД. Данный способ рекомендуется использовать всегда. При
наличии в организации квалифицированных специалистов по СУБД Oracle
можно использовать более сложные методы архивирования, сводящие к минимуму возможную потерю данных.
Для реализации этого способа для каждого источника создайте текстовый
файл экспорта вида:
FILE=<arch_source>
OWNER=<source_owner>
GRANTS=Y
ROWS=Y
INDEXES=Y
COMPRESS=Y
где
<arch_source> – имя архивного файла для источника данных с полным путем, например C:\archive\lib1.dat;
127
<source_owner> – имя владельца источника данных, например lib1.
Далее создайте командный файл архивации следующего вида (пример):
Rem удаление предыдущего архива с диска
del C:\Archive\*.dat
Rem создание нового архива
exp system/password@ora7 parfile=libmgr_exp
exp system/password@ora7 parfile=lib1_exp
Rem копирование нового архива на внешний носитель
copy C:\Archive\*.dat F:\Archive_Nxxx\*.dat
Данный файл на платформе Windows обычно имеет расширение bat. Сначала
происходит удаление предыдущего архива с диска, где создается архив средствами Oracle. Затем создается новый архив. Далее новый архив сохраняется на
внешнем носителе (диске другого компьютера, ленточном накопителе и т.п.).
Данный пример не содержит возможности автоматического генерирования
имени папки на внешнем носителе для нового архива – после выполнения командного файла папку F:\Archive_Nxxx следует переименовать. Предполагается, что архивные файлы имеют расширение dat. Архивируются два источника – источник служебных данных (файл экспорта libmgr_exp) и источник
библиотечных данных (файл экспорта lib1_exp). Имя физической БД –
ora7. Пароль пользователя system – password. Данная схема не является
единственной.
ВНИМАНИЕ! Командный файл содержит системный пароль СУБД в открытом виде. Размещайте этот файл в защищенной директории администратора
ОС.
128
Командный файл должен исполняться на том компьютере, где установлена СУБД. Для обеспечения автоматической периодичности архивирования командный файл следует включить в число задач, запускаемых по расписанию,
используя средство Scheduled Tasks (Назначенные задания в русскоязычной версии) из контрольной панели ОС Windows. В других ОС также
есть соответствующие средства запуска задач по расписанию. Рекомендуется
запускать процесс архивации один раз в сутки в 2 часа утра по системному
времени. Рекомендуется архивные файлы сохранять не только на дисках, но и
на других носителях (CD-RW, Tape и т.п.) и сохранять не только последний архив, а все архивы за некоторый период (за год). Последнее необходимо, поскольку архивируются источники данных целиком. Например, если была удалена библиотечная БД и после этого сделан архив, то восстановить БД можно
только из предыдущего (до момента удаления) архива.
Для восстановления источника данных (целиком, со всеми библиотечными БД) следует создать в новой физической БД области хранения для этого источника с теми же именами, что были в старой БД (см. АБИС «Руслан». Руководство по установке), которая по каким-либо причинам пришла в неработоспособное состояние. Далее следует создать текстовый файл импорта следующего вида:
FILE=<arch_source>
FROMUSER=<source_owner>
TOUSER=<source_owner>
GRANTS=Y
ROWS=Y
INDEXES=Y
COMMIT=Y
и выполнить команду
imp system/password@ora7 parfile=<file_imp>
где
129
<file_imp> – имя файла импорта,
ora7 – имя физической БД.
Команда выполняется из окна командной строки (Command Prompt) на том
компьютере, где установлена СУБД.
Порядок восстановления ИБД или ИСД на той же СУБД Oracle:
1. Удалить ИБД или ИСД – см. п.7.1 или п.7.2 АБИС «Руслан». Руководство по установке.
2. Создать с точно таким же именем и паролем источник данных с помощью функции «Создание источника служебных данных для
импорта» или «Создание источника библиотечных данных
для импорта» (см. АБИС «Руслан». Руководство по установке, п.3).
3. Выйти из АРМа Администратора.
4. Импортировать данные описанной выше командой.
5. Запустить АРМ Администратора.
6. Из интерфейса «RUSLAN-Database» выбрать в окне навигатора объект
«Источники данных» и в основном окне выбрать восстанавливаемый
ИБД (при восстановлении ИСД выполнить команду для каждого ИБД),
вызвать из контекстного меню команду «Восстановить
связи»
(рис.8).
Порядок восстановления ИБД и ИСД в другой СУБД Oracle описан ниже
в п.8.
7.2. Архивирование средствами АРМа Администратора
Архивация выполняется с помощью операции выгрузки записей (см.
п.5.9) для каждой библиотечной БД, которую требуется архивировать. Возможна как выгрузка всех записей из БД, так и выгрузка части записей, добавленных
или измененных с момента последней архивации. Достоинством данного подхода является возможность легко восстановить отдельные записи библиотеч130
ных БД. Недостатком является то, что не всю информацию из библиотечных
БД можно заархивировать (не архивируются индексы), а также то, что процесс
не является автоматизированным (требуется участие человека, тогда как первый подход позволяет сделать архивацию полностью автоматической).
Для восстановления записей библиотечных БД можно использовать либо
операцию загрузки записей (см. п.5.8), либо загрузить записи с помощью АРМа
Комплектования/Каталогизации.
ВНИМАНИЕ! Данный подход к архивированию возможен только если не используется автоматизированная книговыдача. В противном случае, при восстановлении данных, будет нарушена целостность данных о выданных книгах.
7.3. Запуск процесса архивирования сервером «Руслан»
Для обеспечения лучшей синхронизации с фоновыми процессами сервера «Руслан» обеспечена возможность запуска процесса архивирования самим
сервером «Руслан» в фоновом режиме в наиболее подходящее время. Данная
возможность может быть использована, если сервер «Руслан» работает на том
же компьютере, что и СУБД Oracle. При размещении сервера «Руслан» на другом компьютере также существует возможность организовать удаленный
запуск процесса архивирования СУБД Oracle вместо прямого, рассматриваемого в данном разделе. Удаленный запуск в данном руководстве не рассматривается.
Для организации запуска процесса архивирования сервером «Руслан» поместите командный файл архивирования (см. п.7.1) в рабочую папку сервера
под именем arch.bat. Образец командного файла входит в дистрибутив.
131
8. Перенос данных на другой компьютер
В процессе эксплуатации АБИС может возникнуть необходимость модернизации техники, замены компьютера-сервера на более производительную модель или замена в результате прихода в полную негодность. При этом необходимо перенести все данные из физической БД на старом компьютере-сервере в
физическую БД, созданную на новом компьютере-сервере. Поскольку АБИС
«Руслан» использует СУБД Oracle, то возможен перенос всех данных только из
одной БД Oracle в другую. При этом возможен перенос либо в ту же версию
СУБД, либо в более новую (т.е. из 8i возможен перенос в 9i, но не наоборот).
Следует учитывать, что АБИС «Руслан» работоспособна не на всех версиях
СУБД Oracle. Информация о поддерживаемых версиях выводится при запуске
инсталляционного файла серверной части системы. Также ее можно узнать в
службе технической поддержки системы.
Нижеследующая инструкция предполагает, что администратор изучил
документ АБИС «Руслан». Руководство по установке и владеет описанным
там интерфейсом.
Этапы переноса:
1. Осуществляется подготовка нового компьютера (устанавливается операционная система, СУБД, создается физическая БД, устанавливается серверная
часть АБИС – см. АБИС «Руслан». Руководство по установке). Следует создавать физическую БД с тем же самым именем. После установки серверной части АБИС в рабочую папку АРМа Администратора и в рабочую папку
сервера «Руслан» копируется файл ruslan.ini из рабочей папки ранее использовавшегося АРМа Администратора.
2. Останавливается эксплуатация АБИС (закрываются все АРМы, останавливается сервер «Руслан»).
3. Осуществляется архивирование (экспорт) всех источников данных, как описано в п.7.1.
133
4. В новой физической БД (на новом компьютере) создаются точно такие же
(по имени) области хранения, как и в старой БД. Размер областей, расположение файлов в файловой системе могут быть другими. Файловая система
должна быть NTFS.
5. В новой БД создаются точно такие же (по имени, паролям) источники данных, какие создавались в старой БД, но для их создания используются кнопки «Создание источника служебных данных для импорта» и
«Создание источника библиотечных данных для импорта».
6. Осуществляется импорт заархивированных на третьем этапе данных, как
описано в п.7.1(восстановление источника данных). Сначала следует импортировать ИСД, затем – все ИБД. В случае нарушения порядка следует
воспользоваться командой «Восстановить связи» (см. п.7.1).
7. Провести анализ статистики всех БД во всех источниках библиотечных данных, которые были импортированы в новую СУБД.
8. Запустить сервер «Руслан» на новом компьютере. Проверить работу с БД из
АРМа Администратора (например, работоспособность функции просмотра
записей – см. п.5.11, наличие настроек – см. п.2).
9. Перенастроить другие АРМы АБИС «Руслан» (или DNS-сервера) для работы
с новым сервером «Руслан» (в случае, если IP-адрес или имя нового компьютера другие, нежели у старого).
10. Запустить АБИС в эксплуатацию.
134
9. Обеспечение бесперебойной работы серверной части
АБИС «Руслан»
После ввода АБИС «Руслан» в промышленную эксплуатацию одной из
самых важных задач администрирования является обеспечение бесперебойного
функционирования системы. Особенно актуальна данная задача после автоматизации службы книговыдачи.
Основные причины, приводящие к нарушению бесперебойной работы
АБИС и потере данных:
1. Проблемы с техникой. Использование изношенного, некачественного оборудования, в том числе сетевого.
2. Отсутствие оборудования, снижающего вероятность отказа критически важной техники. Речь в первую очередь идет об отсутствии источников бесперебойного питания (ИБП) у серверов, на которых работает СУБД Oracle.
Сбои по питанию – очень распространенное и частое явление. В случае отсутствия ИБП и ПО, которое позволяет корректно завершить работу сервера
в случае длительного перебоя электроснабжения, возможна не только поломка диска(ов) с потерей актуальных данных, но и в случае отсутствия
поломки нарушение целостности данных. Нарушение целостности данных
может привести к неработоспособности СУБД Oracle, которую будет тяжело
восстановить в случае отсутствия высококвалифицированного специалиста
по данной СУБД.
3. Отсутствие процедуры регулярного архивирования библиотечных данных в
СУБД Oracle.
4. Некомпетентность администратора, игнорирование требований документации. Например, размещение файлов физической БД Oracle на файловой системе FAT, попытки проводить эксперименты над БД Oracle, находящейся в
эксплуатации администратором без соответствующей квалификации и т.п.
135
5. Отсутствия профилактических процедур контроля состояния оборудования
и поддержания оборудования в работоспособном состоянии. Нарушение
правил эксплуатации.
В данном разделе описывается процедура, позволяющая за минимальное
время восстановить работоспособность АБИС в случае поломки основного сервера. Под основным сервером в АБИС «Руслан» понимается компьютер, на
котором функционирует СУБД Oracle. Обычно на том же компьютере работает
сервер «Руслан». Процедура восстановления работоспособности АБИС «Руслан» заключается в запуске серверной функциональности на другом компьютере, пока основной сервер находится в ремонте. Этот другой компьютер будем
называть резервным сервером. В один момент времени может работать в качестве сервера для АБИС «Руслан» либо основной, либо резервный сервер, но
не два одновременно. Иначе будет рассогласование данных. Это важно, поскольку как основной, так и резервный сервер желательно прописать в библиотечных АРМах (АРМ Администратора не входит в их число) заранее, чтобы не
тратить времени на перенастройку.
Возможны два сценария работы: циклический и временный. Циклический предполагает, что основной и резервный серверы имеют примерно одинаковые параметры и, после сбоя основного сервера, резервный становится
основным, а основной – после починки – резервным (для АБИС «Руслан»).
Данный сценарий довольно редко возможно применить, поскольку библиотеки
редко имеют несколько мощных компьютеров и поскольку резервный сервер
не целесообразно держать колько как резерв (он должен работать), то возникают сложности с переносом функциональности. Основной сценарий – это временный. Он заключается в том, что резервный сервер подменяет основной на
время ремонта основного сервера. После ремонта основного сервера на него
снова возлагается старая функциональность. Резервный сервер должнен иметь
достаточную вычислительную и ресурсную мощность, чтобы заменить основной сервер. Это зависит от конкретной библиотеки.
136
После некритичного сбоя (основной сервер не требует ремонта, например замены процессора, дисков) основной вариант восстановления работоспособности – без использования резервного сервера. Процедуры те же самые,
только применимые к основному серверу. В большинстве случаев некритичный
сбой может устранить ПО СУБД Oracle. Процесс восстановления запускается
автоматически. Обычно среди процессов появляется процесс ORADIM.EXE.
Процесс может занять продолжительное время. При более критичных сбоях
может потребоваться пересоздать физическую БД Oracle, а возможно и переустановить все ПО СУБД Oracle. В этом случае следует руководствоваться нижеследующими инструкциями с поправкой на неиспользование резервного сервера.
Предполагается, что архивация производится регулярно. Под архивом понимается последний архив, наиболее актуальный архив. Часть данных, внесенная/измененная после архивации, естественно утрачивается.
Для наиболее быстрого восстановления работоспособности резервный
сервер должен быть подготовлен заранее.
Временный сценарий выглядит следующим образом:
1. Выполняется первичная подготовка резервного сервера к импорту данных
из архива (см. далее подробную инструкцию). Резервный сервер может использоваться для других нужд до момента поломки основного сервера.
Переход к следующим пунктам осуществляется после поломки основного
сервера. Промышленная эксплуатация АБИС прервана в результате поломки.
2. Выполняется импорт данных из архива (см. далее подробную инструкцию)
в резервный сервер. Часть данных, внесенная/измененная после архивации, не восстанавливается.
3. Резервный сервер вводится в эксплуатацию. Осуществляется промышленная
эксплуатация АБИС по временной схеме. Переход к следующим пунктам
осуществляется после ремонта основного сервера.
137
4. Выполняется подготовка основного сервера к импорту данных из архива.
5. Выполняется остановка промышленной эксплуатации АБИС по временной
схеме.
6. Выполняется архивация данных в соответствии с п.7.1. Потери данных не
произойдет, т.к. архивация выполняется после остановки промышленной
эксплуатации АБИС.
7. Выполняется импорт данных из архива (см. далее подробную инструкцию),
созданного на предыдущем шаге в основной сервер.
8. Основной сервер вводится в эксплуатацию. Осуществляется промышленная
эксплуатация АБИС до следующей поломки основного сервера.
9. Выполняется повторная подготовка резервного сервера к импорту данных
из архива (см. далее подробную инструкцию). Резервный сервер вновь может использоваться для других нужд до следующей поломки основного сервера. Переход к п.2 данного сценария осуществляется после поломки
основного сервера.
Примечание.
1. Возможна организация резервного сервера (здесь даже сервера горячего резерва) с использованием специализированных средств ПО Oracle. Данный
вариант предполагает наиболее быстрый ввод резервного сервера в промышленную эксплуатацию. Однако требует наличия высококвалифицированного специалиста по администрированию СУБД Oracle. Данный вариант
в данном документе не рассматривается и не является объектом технической поддержки. Недостаток данного варианта – ограничение по использованию резервного сервера для другого функционала, кроме как зеркалирования изменений на основном сервере.
2. Под вводом сервера (как компьютера) в эксплуатацию (для АБИС «Руслан»)
подразумевается запуск сервера «Руслан», проверка работоспособности системы, оповещение всех служб библиотеки о необходимости работать с дан138
ным сервером. Как отмечалось выше, АРМы должны быть настроена как на
работу с основным сервером, так и на работу с резервным сервером. В один
момент времени должна осуществляться работа только с одним сервером «Руслан».
3. Под остановкой эксплуатации АБИС подразумевается (в техническом плане) остановка сервера «Руслан» на основном или резервном сервере.
Нижеследующие инструкции предполагают, что администратор изучил
документ АБИС «Руслан». Руководство по установке и владеет описанным
там интерфейсом.
Первичная подготовка резервного сервера к импорту данных из архива
1. Подготовьте компьютер. Установите ОС и прочее ПО общего назначения в
соответствии с требованиями АБИС "Руслан".
2. Установите ПО СУБД Oracle.
3. Создайте физическую БД Oracle в соответствии с требованиями АБИС "Руслан" (см. АБИС «Руслан». Руководство по установке). Следует создавать
физическую БД с тем же самым именем, что и на основном сервере.
4. Установите ПО серверной части АБИС «Руслан». После установки скопируйте
в
рабочую
папку
АРМа
Администратора
(/Program
Files/Ruslan/SysAdmin) и в рабочую папку сервера «Руслан»
(/Program Files/Ruslan/Server) файл ruslan.ini из рабочей папки АРМа Администратора на основном сервере.
5. Запустите АРМ Администратора. Создайте точно такие же (по имени) области хранения, как и в БД на основном сервере. Размер областей, расположение файлов в файловой системе могут быть другими. Файловая система
должна быть NTFS.
6. Создайте точно такие же (по имени, паролям) источники данных, какие
создавались в БД на основном сервере, но для их создания используйте
139
кнопки «Создание источника служебных данных для импорта»
и «Создание источника библиотечных данных для импорта».
7. Выйдете из АРМа Администратора. Остановите сервисы СУБД Oracle (они
не должны запускаться автоматически). Сервис сервера «Руслан» также не
должен быть запущен и не должен запускаться автоматически. Резервный
сервер подготовлен.
Повторная подготовка резервного сервера к импорту данных из архива
1. Сервер «Руслан» должен быть к этому моменту остановлен.
2. Запустите АРМ Администратора. Удалите ИСД и все ИБД и создайте их
снова с теми же самыми именами и паролями используя кнопки «Создание источника служебных данных для импорта» и «Создание
источника библиотечных данных для импорта».
3. Выйдете из АРМа Администратора. Остановите сервисы СУБД Oracle (они
не должны запускаться автоматически). Сервис сервера «Руслан» также не
должен быть запущен и не должен запускаться автоматически. Резервный
сервер подготовлен.
Импорт данных из архива
1. Импорт данных из архива выполняется в соответствии с п.7.1(восстановление источника данных). Сначала следует импортировать ИСД, затем – все
ИБД. В случае нарушения порядка следует воспользоваться командой
«Восстановить связи» (см. п.7.1).
2. После импорта необходимо провести анализ статистики всех библиотечных
БД во всех ИБД, которые были импортированы.
3. Проверить работу с БД из АРМа Администратора (например, работоспособность функции просмотра записей – см. п.5.11, наличие настроек – см. п.2).
140
141
10. Управление лицензиями
Для просмотра количества имеющихся лицензий выберите из меню
«Справка» команду «О программе» (см. рис.2). Откроется диалоговое окно,
в котором будет выведена информация о версии АРМа Администратора, о правообладателе данной копии АРМа Администратора и сервера «Руслан», а также количество доступных авторизованных подключений (лицензий) к серверу
«Руслан» из АРМов Комплектования/Каталогизации или Книговыдачи.
При дополнительном приобретении некоторого количества авторизованных подключений администратору АБИС (или другому ответственному лицу в
организации) высылается новый лицензионный файл, который обычно имеет
имя ruslan.dat.
Для активации дополнительно приобретенных авторизованных подключений выполните следующие действия:
1. Скопируйте новый лицензионный файл в рабочую папку АРМа Администратора (АРМ Администратора не должен быть запущен!).
2. Запустите АРМ Администратора.
3. Из меню «Файл» выберите команду «Обновить ini-файл» (см. рис.2).
Будет обновлен ini-файл в рабочей папке АРМа Администратора.
4. Скопируйте обновленный файл ruslan.ini в рабочую папку сервера «Руслан» (по умолчанию C:/Program Files/Ruslan/Server).
5. Перезапустите сервер «Руслан».
143
11. Мониторинг и управление работой сервера «Руслан»
В данном разделе описываются возможности мониторинга сервера «Руслан» и операции управления сервером.
Для запуска сервера «Руслан» запустите программу управления сервисами Services (Start->Settings->Control Panel->Administrative Tools->Services). Выберите сервис «RUSLANService...». Вызовите контекстное меню и выберите из него команду «Start» («Пуск»). Для остановки сервера выберите из этого же контекстного меню команду «Stop» («Стоп»), а для перезагрузки – команду «Restart» («Перезапуск»).
Взаимодействие с сервером осуществляется из интерфейса «RUSLANServer» (см. п.1).
11.1. Перегрузка параметров сервера
Настройка параметров сервера «Руслан» описана в п.3.1.
Рис. 52
Для актуализации изменений параметров в сервере (т.е. перегрузки, перечитывания параметров сервером) выберете в окне навигатора объект «Сервер
"Руслан"» и вызовите из контекстного меню команду «Перегрузить»
145
(рис.52). Появится предупреждение (рис.53). В случае продолжения операции
результат операции будет отражен в логе (рис.54).
Рис. 53
Рис. 54
11.2. Анализ текущего состояния сервера
Для просмотра текущего состояния сервера выберете в окне навигатора
объект «Сервер "Руслан"->Состояние». В основном окне будет представлен список наиболее важных показателей (или параметров, но не путать с
параметрами из п.11.1) работы сервера (рис.55). Для обновления значений по146
казателей выберите в основном окне из контекстного меню команду «Обновить» (рис.56).
Рис. 55
Рис. 56
147
11.3. Просмотр подключенных к серверу пользователей
Для просмотра подключенных к серверу пользователей выберете в окне
навигатора объект «Сервер "Руслан"->Состояние->Пользователи». В
основном окне будет представлен список пользователей, в настоящий момент
подключенных к серверу «Руслан» (рис.57), а также параметры подключения:
время, с какого IP-адреса, в какой кодировке, из какого клиента (АРМа). Список пользователей можно отсортировать по любой колонке, щелкнув левой
клавишей мыши на ее заголовке. Для обновления списка пользователей выберите в основном окне из контекстного меню команду «Обновить список»
(рис.58).
Рис. 57
Рис. 58
Для актуализации изменений связанных с пользователями (изменение
прав, пароля, добавление, удаление пользователя – см. п.4) в сервере (т.е. пере148
грузки, перечитывания описаний пользователей из ИСД) выберите из
контекстного меню основного окна команду «Перегрузить из БД» (см.
рис.58) или выберете в окне навигатора объект «Сервер "Руслан"->Состояние->Пользователи» и вызовите из контекстного меню команду
«Перегрузить» (рис.59). Появится предупреждение как на рис.53. В случае
продолжения операции результат операции будет отражен в логе (рис.60).
Рис. 59
Рис. 60
Для любого пользователя, подключенного к серверу «Руслан» можно выполнить операцию принудительного (т.е. по инициативе сервера) закрытия соединения. Также имеется возможность послать информационное сообщение от
сервера к клиенту. Для закрытия соединения или посылки сообщения выберете
из контекстного меню основного окна команду «Закрыть/послать сообщение» (см. рис.58). В появившемся диалоговом окне (рис.61) выберите категорию(и) пользователей и одно из действий (закрыть или послать сообщение),
введите сообщение. Для выполнения операции нажмите кнопку «Выполнить».
149
Имеются предопределенные сообщения, которые можно отредактировать
(рис.62).
Рис. 61
Примечание.
1. Операция посылки сообщения от сервера «Руслан» к Z39.50-клиенту реализована с использованием сервиса «ResourseControl» протокола Z39.50, что не
гарантирует обработку сообщения клиентами не поддерживающими данный
сервис. АРМ «Комплектование/Каталогизация» и АРМ «Книговыдача» являются Z39.50-клиентами, поддерживающими данный сервис.
150
Рис. 62
11.4. Просмотр перечня известных серверу библиотечных БД
Для просмотра перечня известных серверу библиотечных БД выберете в
окне навигаторе объект «Сервер
"Руслан"->Состояние->Базы». В
основном окне будет представлен список библиотечных БД и их параметры
(рис.63). Список БД можно отсортировать по любой колонке, щелкнув левой
клавишей мыши на ее заголовке.
Для актуализации изменений связанных с БД (изменение параметров, добавление, удаление БД – см. пп.5.1, 5.2, 5.4) в сервере (т.е. перегрузки, перечитывания описания БД из ИСД) выберите в окне навигатора объект «Сервер
151
"Руслан"->Состояние->Базы» и вызовите из контекстного меню команду
«Перегрузить» (рис.64). Появится предупреждение как на рис.53. В случае
продолжения операции результат операции будет отражен в логе (рис.65).
Рис. 63
Рис. 64
152
Рис. 65
ВНИМАНИЕ! Операция перегрузки БД очень «тяжеловесная». Она может занимать значительное время. Рекомендуется перегружать БД, когда к серверу
подключено мало пользователей (0-3) и интенсивность их работы мала (интенсивность можно отслеживать из окна отображения статистики – см. п.11.6).
Наиболее безопасный способ перегрузки БД – перезапуск сервера «Руслан»
(см. в начале п.11).
Для временного разрешения/запрещения (до перезапуска сервера «Руслан») доступа к БД выберите в основном окне требуемую БД и вызовите из
контекстного
меню
команду
«Изменить
доступ»
(рис.66).
Для
запрещения/разрешения доступа вызовите эту команду еще раз.
Рис. 66
153
Если для БД была включена опция «Скан по словам» (см. п.5.2), то
возможно выполнение следующих команд из контекстного меню (рис.66). Команды «Разрешить скан-индекс» и «Запретить скан-индекс» соответственно временно разрешают или запрещают просмотр клиентами (АРМами) скан-индекса для выбранной БД (состояние отображается в колонке «Просмотр»). Команда «Перегрузить скан-индекс» удаляет скан-индекс из
оперативной памяти и снова загружает его. Команда «Очистить скан-индекс» удаляет скан-индекс из оперативной памяти.
ВНИМАНИЕ! Операция перегрузки скан-индекса может выполняться достаточно долго. Настоятельно рекомендуется не выполнять ее повторно до окончания процесса загрузки. О начале и конце процесса загрузки скан-индекса
можно судить по сообщениям в системном прикладном логе (Application Log)
операционной системы. Для просмотра сообщений используйте инструмент
«Event Viewer» («Просмотр событий») из панели управления.
Для постоянного разрешения или запрещения просмотра и загрузки сканиндекса, доступа к БД следует изменить конфигурацию (см. п.5.2). При этом
механизм временного разрешения/запрещения данных возможностей, рассмотренный выше, позволяет обойтись без перегрузки БД (в части актуализации
именно этих изменений).
11.5. Анализ соединений к физической базе данных
Для просмотра перечня соединений, которые сервер «Руслан» установил
с СУБД Oracle, и их состояния выберете в окне навигаторе объект «Сервер
"Руслан"->Состояние->Соединения с БД». В основном окне будет
представлен список соединений и их параметры (рис.67). Список соединений
можно отсортировать по любой колонке, щелкнув левой клавишей мыши на ее
заголовке.
154
Рис. 67
В основном окне представлены соединения для всех зарегистрированных
в системе ИБД. Количество соединений для каждого источника определяется
параметром «Количество соединений» (см. п.2.1). В первой колонке таблицы в основном окне отображается имя ИБД. Во второй колонке – количество соединений к соответствующему ИБД. Этот параметр имеет одинаковое
значение для всех соединений к конкретному ИБД. В третьей колонке – порядковый номер соединения в соответствующем ИБД, начиная с 0. В колонке
«Состояние» может быть два значения: 0 – соединение свободно, 1 – соединение занято (то есть соединение используется какой-либо операцией). В колонке «Кол. использ.» отображается общее количество операций (здесь и
далее с момента старта сервера «Руслан»), которые использовали данное соединение. В колонке «Сум. время(мс)» отображается суммарное время выполнения операций (в миллисекундах), которые использовали данное соединение,
а в колонке «Сред. время(мс)» – среднее время на каждую операцию (в миллисекундах).
В контекстном меню основного окна предусмотрены команды оперирования соединениями, такие как добавить, удалить, занять, освободить соединение (см. рис.68). Команды добавить или удалить соединение действуют только
155
до момента перезапуска сервера «Руслан». Для изменения количества соединений на ИБД необходимо изменить конфигурацию (см. п.2.1). Удалить можно
только свободное соединение. Команда «Занять соединение» делает невозможным использование данного соединения для выполнения любых операций над библиотечными БД (поиск, извлечение, вставка и т.п.). Она может использоваться для временного ограничения количества используемых соединений в целях настройки производительности. Команда «Освободить соединение» освобождает соединение, занятое по команде «Занять соединение». Команда «Обновить» обновляет информацию по состоянию соединений.
Рис. 68
При анализе состояния соединений следует обратить внимание на следующее. Если все соединения к какому-либо источнику данных постоянно заняты
(случай не единичный), то это может свидетельствовать о проблемах с СУБД
или производительностью. В первом случае следует перезапустить СУБД (см.
документацию на СУБД Oracle), во втором – добавить соединений. В любом
случае следует проконсультироваться со службой поддержки системы. Если
среднее время выполнения операции по всем соединениям источника с течением времени значительно возросло (достигло уровня 3–5 секунд), это означает,
156
что либо компьютер с СУБД не обеспечивает требуемую производительность,
либо необходимо провести операцию анализа статистики для библиотечных
БД соответствующего источника (см. п.5.6): для каких именно баз данных – поможет определить анализ статистики сервера (см. следующий пункт). Если
одно из соединений к одному источнику используется значительно меньше,
чем другие соединения (к этому же источнику), то возможно данное соединение лишнее и необходимо уменьшить количество соединений к этому источнику в конфигурации (см. п.2.1).
11.6. Анализ статистики работы сервера
Анализ статистики позволяет получать информацию по времени и статусу выполнения любых операций в сервере «Руслан», таких как поиск, извлечение, расширенные сервисы (вставка, изменение, удаление) и других с точностью до конкретного пользователя или категории пользователей за заданный
промежуток времени с момента старта сервера «Руслан». Независимо от промежутка времени из АРМа возможно посмотреть только последние 20000
операций.
Для просмотра статистики выберете в окне навигаторе объект «Сервер
"Руслан"->Статистика». В основном окне будет будет представлена форма для задания параметров фильтрации статистики (рис.69).
Рис. 69
157
Возможно задание фильтра на статистику одновременно по следующим
параметрам: периоду времени, операции, сессии, пользователю или категории
пользователей, статусу выполнения операции. Существует один специальный
тип операции – «Расширенные сервисы», который подразумевает совокупность действий по изменению записей в библиотечных БД. В выпадающем
списке «Действие» можно выбрать конкретное действие (вставка, изменение,
удаление и др.) для данного типа операции. Возможно посмотреть статистику
по категориям пользователей: библиотекарям, читателям, неавторизованным
пользователям. В случае библиотекарей (служащих организации) можно
уточнить статистику до конкретного пользователя. Такой пользователь должен
быть заведен из данного АРМа (см. п.4.2). По статусу выполнения операций
можно выделить успешные, ошибочные, частично выполненные и принудительно завершенные операции. Операция будет частично выполненной, если
операция была выполнена, но не в полном объеме (например, в большинстве
случаев, если при поиске по нескольким библиотечным БД часть БД недоступна или не существует). Операция будет принудительно завершенной, если она
не уложилась по времени в допустимую квоту. Временные квоты операций для
разных категорий пользователей задаются в параметрах сервера (см. п.3.1).
Рис. 70
Возможен просмотр статистики с точностью до операции и агрегированной статистики. Для просмотра статистики с точностью до операции задайте в
основном окне параметры фильтрации (если требуется) и нажмите на кнопку
158
«Выполнить» (рис.70). Пример вывода статистики с точностью до операции
приведен на рис.71.
Рис. 71
Каждая операция отображается на отдельной строке. Для каждой операции приводится пользователь, который ее запустил, время начало операции,
время пребывания операции в очереди (в мс), время выполнения операции (в
мс), номер сессии, в рамках которой выполнилась операция, описание операции и статус выполнения.
ВНИМАНИЕ! В окне статистики отображается только отработавшие (с тем
или иным статусом) операции.
Для большинства операций можно посмотреть дополнительную информацию. Для этого необходимо выбрать (после получения статистики) из списка
операций интересующую операцию и из контекстного меню вызвать команду
159
«Дополнительная информация» (см. рис.71). Появится диалоговое окно с
дополнительной информацией. Например, для операции вставки библиографической записи можно увидеть, в какую БД проведена вставка, какое количество
записей было вставлено (обычно за одну операцию вставляется одна запись),
внутренний ключ (MID) первой записи и диагностику (рис.72).
Рис. 72
Для просмотра агрегированной статистики задайте в основном окне параметры фильтрации (если требуется) и нажмите на кнопку «Расширенный»
(рис.70). Пример вывода агрегированной статистики приведен на рис.73. Каждая операция отображается на четырех строках, которые различаются по функции агрегирования: минимальное время операции (min), максимальное время
операции (max), суммарное время операции (sum), среднее время операции
(avg). Функции агрегирования применяются к временным параметрам: времени
пребывания в очереди и времени выполнения. Параметры отдельно считаются
для успешных и неудачных операций.
160
Рис. 73
Если с течением времени время выполнения операций для какой-либо БД
возрастает (по типам операций), то это говорит о том, что либо компьютер с
СУБД не обеспечивает требуемую производительность, либо необходимо провести операцию анализа статистики для данной БД (см. п.5.6).
161
Приложения
163
Приложение 1. Диагностические сообщения сервера
«Руслан»
Диагностические сообщения выводятся сервером «Руслан» в лог приложений (Application Log) операционной системы Windows. Для просмотра
лога используется инструмент администрирования «Просмотр событий»
(«Event Viewer»).
1
2
3
-
4
5
6
7
8
-
9
10
11
-
12
13
14
20
21
22
30
31
32
33
34
35
36
-
Не удалось инициировать обработчик сервиса.
Не удалось инициировать сервис удаленного управления.
Системная ошибка при инициировании сервиса удаленного управления.
Не удалось прочитать файл статистики.
Системная ошибка при чтении файла статистики.
Системная ошибка при запуске асинхронных процессов.
Не удалось инициировать прослушивание порта.
Системная ошибка при попытке инициировать прослушивание порта.
Ошибка при прослушивании порта.
Системная ошибка при закрытии соединений с СУБД .
Системная ошибка при закрытии соединений с Z-клиентами при завершении работы сервиса.
Системная ошибка при завершении работы сервиса.
Отсутствует или поврежден файл инициализации.
Не удалось инициировать обработчик сервиса.
Не удалось инициировать подключение к СУБД.
Не удалось открыть управляющее соединение к СУБД.
Не удалось получить параметры Z-сервера.
Системная ошибка в рабочем потоке.
Системная ошибка в потоке диспетчера.
Исключительная ситуация.
Ошибка при создании сокета прослушиваемого порта.
Не удалось разобрать адрес.
Не удалось связать сокет с портом.
Неизвестное событие.
165
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
100
101
102
103
104
105
106
108
166
-
Ошибка при прослушивании.
Ошибка при принятии соединения.
Ошибка при создании нового соединения.
Ошибка при создании потока кодирования/декодирования.
Ошибка при создании потока печати.
Ошибка при диспетчеризации параллельного запроса.
Ошибка при получении соединения к СУБД.
Ошибка при вставке записи.
Ошибка при изменении записи.
Ошибка при удалении записи.
Ошибка в MARC записи.
Внутренняя блокировка.
Ошибка при косвенном поиске.
Не удалось восстановить соединение.
Ошибка при создании нового соединения.
Не удалось сформировать результирующее множество.
Не удалось извлечь записи о читателях.
Сервис RUSLANServer инсталлирован
Сервис RUSLANServer удален.
Сервис RUSLANServer не удалось удалить.
Не удалось установить обработчик.
Не удалось завершить процесс инициализации.
Сервис запущен.
Сервис получил не поддерживаемый запрос.
Сервис остановлен.
Приложение 2. Теги служебных баз данных
Общие теги:
1
2
3
1002
1003
-
Ключ записи
Имя пользователя, создавшего или модифицировавшего запись
Дата создания или модификации записи
Предыдущее значение тега 2
Предыдущее значение тега 3
Остальные теги описаны в документации на компоненты АБИС, их использующие.
167
Приложение 3. Формат обмена для служебных баз данных
Записи служебных БД состоят из набора полей, каждое из которых характеризуется номером тега, типом и номером экземпляра. Конец строки означает
конец записи.
Формат записи:
@<tag>,<type>,<occur>,<len>=<value>@<tag>,...
где
@
<tag>
<type>
<occur>
<len>
<value>
-
Символ начала описания поля
Номер тега
Тип значения тега (1 – бинарные данные, 5 – строка)
Экземпляр тега (1, 2, ...)
Длина значения тега (в байтах)
Значение тега
169
Приложение 4. Формат запроса
В АРМе Администратора не предусмотрены функции поиска, создания и
редактирования записей. Для этого используйте АРМ Комплектования/Каталогизации. Однако некоторые функциональные возможности АРМа Администратора предусматривают возможность отбора записей по запросу. Запрос представляет собой форматированную строку вида:
@<use>,<rel>,<pos>,<str>,<trn>,<com>,<len>=<term>@0,<op>,
<level>,0,0,0,0=@<use>...
где
<use>,<rel>,<pos>,<str>,<trn>,<com> – целые неотрицательные числа соответствующие атрибутам use, relation, position, structure, truncation,
completeness набора атрибутов Bib-1 (см. Information Retrieval (Z39.50):
Application Service Definition and Protocol Specification, Appendix 3). В случае
служебной БД атрибут <use> соответствует номеру тега;
<len> – длина поискового терма в символах;
<term> – поисковый терм;
<op> – логическая операция (1 – И, 2 – ИЛИ, 3 – И-НЕ);
<level> – приоритет операции (чем больше номер, тем больше приоритет).
171