АРМ Администратор-серверный (ИРБИС64):

В режим ИМПОРТ добавлена опция СО СЛИЯНИЕМ (так же, как в АРМе Каталогизатор)

Отлично. А эта опция поддерживается в пакетных заданиях?
И туда же пожелание для полнотекста. Обеспечить возможность автоматической актуализации ПТБД из пакетных файлов.

Панев Максим написал(а):
-------------------------------------------------------
> Отлично. А эта опция поддерживается в пакетных
> заданиях?
Да
Теперь пакетная команда IMPORTDB имеет следующую структуру операндов:

[0/#/@|1],FstName,[0|1],[0|1|2],FileName,[0|1],[0|1],[0|1],PftGblName
Где:
Первый операнд - исходный формат данных:
0 - ISO-формат, # - символ-разделитель полей, @ - символ-разделитель записей;
1 - текстовый формат.
FstName - имя ТВП переформатирования, если пустое значение - переформатирование не используется.
Третий операнд - признак ФЛК:
0 - не применять;
1 - применять.
Четвертый операнд - вид кодировки:
0 - DOS
1 – Windows
2 – UTF8
Пятый операнд - FileName - полное имя файла с исходными данными;
Шестой операнд - признак Автоввода:
0 - не применять;
1 - применять.
Седьмой параметр - признак формирования протокола
0 - не формировать;
1 - формировать.
Восьмой параметр - использование СЛИЯНИЯ
0 - слияние на основе ключевого формата
1 - слияние на основе глобального задания
отсутствие параметра (т.е наличие ТОЛЬКО семи параметров) означает, что слияние не используется.
Девятый параметр - имеет смысл ТОЛЬКО при наличии восьмого параметра и определяет имя соответственно ФОРМАТА или ГЛОБАЛЬНОГО ЗАДАНИЯ



Редактировано 2 раз. Последний раз 30.11.2011 18:46 пользователем Alio.

Предложения для АРМ «Книговыдача»

Залоговый абонемент.

Нужна технология учета книг выданных под залог.

Например, вот так:
• в 40 поле добавить подполе «Залог» (статус, по принципу – да/ нет )
• в форме выдачи книги добавить галочку о том, что книга выдается под залог (для всех режимов: без ЭК, по штрих-кодам, без заказа, по заказу)
• в окне просмотра списка изданий на руках добавить колонку с информацией о том, что книга выдана под залог и суммой
• в INI файле пользователя добавить параметр, указывающий формат по которому рассчитывается залоговая сумма, и параметр, отключающий технологию залогового абонемента
• в форматы печати форму добавить форму заявления для выдачи под залог в двух экземплярах
Пример формы:

---

Заявление

Я, Арноси Галина Алексеевна взял(а) под залог на сумму 2500 р. библиотечные документы:

1. Арсеньева, Елена Арсеньевна. Яд вожделения, 1998 ;
2. Картленд, Барбара. Испуганная невеста, 1997;
3. Вейр, Тереза. Игрушка богатого человека;
4. Мельникова, Ирина Александровна. Формула одиночества, 2007;
5. Браун, Сандра. Пробуждение, 1996.

во временное пользование - на срок до 28 декабря 2011 г. из читального зала
"Отдел городского абонемента" в количестве _5_экз. Обязуюсь возвратить
перечисленные документы в установленный срок, гарантирую сохранность.
При нарушении сроков возврата документов обязуюсь выплатить 10% от
залоговой суммы за сутки.

Дата выдачи 01 декабря 2011 года ____________________
подпись заявителя

---

Государственная универсальная научная библиотека Красноярского края, Ассоциация ЭБНИТ

Предложения для АРМ «Книговыдача»


Настраиваемые фильтры в АРМ «Книговыдача»

Было бы неплохо иметь возможность настраивать перечень фильтров для АРМ «Книговыдача» через INI-файл пользователя.

Кроме основных фильтров («Место выдачи», «Место хранения», «Имя БД») могут понадобиться такие фильтры как: «Категория читателей», «Место учебы», а может быть «Факультет» или «Форма обучения». А, например, фильтры «Шифр документа» или «Инвентарный номер» вообще никогда не будут использоваться.

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

Пример:

Маша работает в отделе «Гуманитарной литературы». У этого отдела есть три возможных кафедры выдачи: Зал для научных работников, зал для молодежи и зал для специалистов. В зависимости от своего штатного расписания Маша работает то на одной, то на другой, то на третьей кафедре.
Для того чтобы Маша в аббревиатурах кафедр не надела ошибок (лишние пробелы к примеру) и не сбила другие фильтры, Маше запрещено корректировать настройки. Поэтому у Маши на данный момент несколько различных логинов. Общий логин на кафедру сделать нельзя потому, что нужно знать, кто и когда работал с читателем.
:)

Государственная универсальная научная библиотека Красноярского края, Ассоциация ЭБНИТ



Редактировано 1 раз. Последний раз 01.12.2011 09:21 пользователем GLUKa.

Предложения для АРМ «Книговыдача»

Учет посещение выставок и мероприятий

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

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

А для этого нужно изменить сам режим фиксирования посещений и добавить в ini-файл пользователя книговыдачей, например такие параметры:

• имя БД для ведения мероприятий
• префикс словаря для отбора мероприятия, посещаемого читателем
• имя формата переноса данных в запись читателя о посещении выбранного мероприятия

Пример заполнения поля 40 в записи читателя

^G ИМЯ БД
^A Шифр мероприятия
^V Место выдачи
^D Дата выдачи (посещения)
^F Дата фактического возврата (посещения)
^C Краткое описание мероприятия
^I Ответственный

Государственная универсальная научная библиотека Красноярского края, Ассоциация ЭБНИТ



Редактировано 2 раз. Последний раз 07.12.2011 09:04 пользователем GLUKa.

Предложения для АРМ «Книговыдача»

Доработка для области «Заказы»

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

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

Государственная универсальная научная библиотека Красноярского края, Ассоциация ЭБНИТ



Редактировано 4 раз. Последний раз 09.12.2011 12:55 пользователем GLUKa.

Поддерживаю идею по расширению технологии учета посещений для мероприятий. Это позволит получать полные данные по посетителям, что очень важно для анализа эффективности и планирования дальнейших мероприятий.
Мы (КрЦНТИБ КрасЖД) сейчас ведем учет посещения мероприятия в отдельном поле с подполями, что, конечно, позволяет получать данные для анализа, но трудозатратно и нарушает технологию однократного ввода/многократного использования.
Решение, предлагаемое Галиной (учет посещений - это лишь часть решения), системно и может использоваться всеми библиотеками (технология "учета" мероприятий и сопутствующих им выставок подробно описана в докладе на Либком-2011). Если добавить учет посещений мероприятия через Книговыдачу, будет замечательно!

Кстати, могу предложить в дополнение к мероприятиям саму базы мероприятий, по тому как сделал и веду такие еще с 2005 года.

У нас тоже такая БД есть:) Завязана с WEB-ом. и ЭК для виртуальных выставок :). Осталось с книговыдачей завязать только.

Государственная универсальная научная библиотека Красноярского края, Ассоциация ЭБНИТ



Редактировано 1 раз. Последний раз 07.12.2011 09:26 пользователем GLUKa.

вот и надо решение сделать типовым :) потому что всем надо. И посещения учитывать.

Абсолютно согласна с GLUKa по поводу "Заказов". Если это реализовать, то станет намного удобнее, а главное логичнее! Ведь зачем во время работы с конкретным читателем нужно просматривать еще какие-то другие заказы? И не придется тратить время на дополнительный поиск заказов для этого читателя.

Научная библиотека СибГТУ



Редактировано 1 раз. Последний раз 13.12.2011 05:49 пользователем Hellena.

Серверная часть ИРБИС64.

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

Дальнейшие разъяснения будут интересны исключительно продвинутым администраторам ИРБИС, которым не лень разбираться в тонкостях "движка" СУБД ИРБИС.

Чтобы объяснить суть нового механизма актуализации, необходимо напомнить схему старого механизма. Она состоит в следующем:
- рассматриваются две копии актуализируемой записи: последняя копия (т.е. актуальное состояние записи после корректировки) и предыдущая копия (т.е. состояние записи до выполнения корректировки, или точнее - то состояние записи, для которого выполнялась предыдущая актуализация);
- обе копии записи подвергаются обработке (в оперативной памяти) в соответствии с таблицей инвертирования данной БД (<имя_БД>.FST). Обработка состоит в том, что копии записи форматируются по КАЖДОЙ строке таблицы инвертирования (см. структуру FST) и в соответствии с методами инвертирования создаются списки терминов. В результате - формируются два списка терминов: один - связанный с предыдущей копией записи, другой - с последней копией;
- два списка терминов (после сортировки) сравниваются. В результате: а) термины, являющиеся общими для обоих списков отбрасываются (не рассматриваются), б) термины, оставшиеся в списке последней копии (т.е. те термины, которые присутствовали в списке последней копии и отсутствовали в списке предыдущей копии) ДОБАВЛЯЮТСЯ в словарь БД, в) термины, оставшиеся в списке предыдущей копии (т.е. те термины, которые присутствовали в списке предыдущей копии и отсутствовали в списке последней копии) УДАЛЯЮТСЯ из словаря.

Нетрудно понять, что данный механизм имеет существенный недостаток, связанный с нечувствительностью к тому, КАКИЕ и СКОЛЬКО полей записи подвергались изменению (корректировке). Т.е. если изменялись все или большинство полей записи (или точнее – большинство тех полей, которые участвуют в инвертировании), этот механизм эффективен; если же изменялось одно или несколько полей (а именно это имеет место на практике при работе с библиографическими БД) - механизм малоэффективен. И уж совсем "впустую" он работает в тех случаях, когда изменялись только те поля, которые не участвуют в инвертировании (т.е. те, по которым не создаются словари).
Проиллюстрировать это можно на следующем примере. При корректировке записи изменялось только поле 910 (экземпляры). В этом случае форматирование последней и предыдущей копий записи по строкам таблицы инвертирования, не имеющим отношения к полю 910, заведомо бессмысленно, поскольку сформированные в результате этого термины окажутся общими для обоих списков и будут отброшены. Имеет смысл использовать только те строки таблицы инвертирования, которые имеют отношение к полю 910. Но этого не происходит - старый механизм "тупо" обрабатывает ВСЕ строки таблицы инвертирования и тратит время на ненужное форматирование.Таким образом, идея нового механизма актуализации лежит как будто на поверхности: определять, какие поля в записи изменялись (сравнивая последнюю и предыдущую копии записи) и отбирать из таблицы инвертирования только те строки, которые имеют отношение к изменившимся полям.
(Все именно так - только надо сразу видеть и "обратную сторону", т.е. недостатки нового механизма: в случае изменения всех или большинства полей записи впустую уже будет тратиться время на сравнение копий и отбор строк из таблицы инвертирования.)
Процесс сравнения копий (с целью выявления изменившихся полей) - очевиден и его реализация не вызывает никаких проблем. А вот задача отбора строк таблицы инвертирования, имеющих отношение к изменившимся полям, более "хитрая".(И даже более того - в силу изощренности языка форматирования ИРБИС эта задача алгоритмически строго говоря вообще неразрешима. Вот пример - разумеется, чисто теоретический - строки таблицы FST, по которой нельзя определить, к какому полю она относится:
100 0 ....&uf('AV',f(val(v100),0,0),'#1').....
понятно, что это не поле 100 - а то поле, чья метка указана в поле 100 текущей записи.)
И тем не менее, для решения "хитрой" задачи предлагается следующее. Вводится новая структура - дополнительная по отношению к таблице инвертирования. Будем называть ее ТАБЛИЦА АКТУАЛИЗАЦИИ - IFS (именно такое расширение предлагается для соответствующего файла). Таблица актуализации создается ИСКЛЮЧИТЕЛЬНО на основе таблицы инвертирования (каким образом - об этом ниже) и является ее ОДНОЗНАЧНЫМ следствием ("придатком"). Отличие таблицы актуализации от таблицы инвертирования только лишь в структуре первого элемента (если смотреть через Редактор РЛ - это первая колонка). В таблице инвертирования это т.н. "точка входа". В таблице актуализации - в первом элементе дополнительно к точке входа указываются (через запятую) МЕТКИ полей, имеющих отношение к данной строке (т.е. метки тех полей, которые используются в соответствующем формате - третьем элементе таблицы).
Схематичный пример строки таблицы инвертирования:
100 0 .....v100......v200......v300....
Ей будет соответствовать следующая строка таблицы актуализации:
100,100,200,300 0 .....v100......v200......v300....
Понятно, что такая структура таблицы актуализации позволяет легко решать задачу отбора строк инвертирования, имеющих отношение к изменившимся полям.

Таким образом, новый механизм актуализации состоит в следующем:
- сравниваются последняя и предыдущая копии записи - в результате определяются метки изменившихся полей;
- из таблицы актуализации отбираются строки, имеющие отношение к изменившимся полям и на их основе формируется временная (создаваемая налету для конкретной записи) таблица инвертирования;
- отрабатывает "старый" механизм актуализации на основе временной таблицы инвертирования.
Необходимо отметить, что по понятным причинам при актуализации (т.е. сохранении) НОВОЙ записи (у которой нет никаких предыдущих копий), а также при УДАЛЕНИИ и РАЗУДАЛЕНИИ записи будет применяться старый механизм актуализации.

Логичен вопрос: зачем поддерживать две структуры - таблицу инвертирования и таблицу актуализации, почему нельзя отказаться от таблицы инвертирования и применять только новую структуру - таблицу актуализации. Ответ очевиден: исключительно для соблюдения принципа наследования. Т.е. если в структуре БД присутствует таблица актуализации (<имя_БД>.IFS) , будет применяться новый механизм актуализации, в противном случае - старый механизм.
(Необходимо сразу отметить, что при полном создании словаря используется ТОЛЬКО таблица инвертирования - <имя_БД>.FST - т.е. этот файл остается ОБЯЗАТЕЛЬНЫМ в структуре БД, в отличие от таблицы актуализации <имя_БД>.IFS, которая может отсутствовать).Теперь о том, каким образом создавать таблицу актуализации. Разумеется, нет большой трагедии в том, чтобы создавать и корректировать ее вручную на основе таблицы инвертирования - ведь таблица инвертирования это фундамент БД и меняется она отнюдь не каждый день. И именно так придется поступать на первых этапах применения нового механизма актуализации (конечно же в дистрибутиве 2012.1 будут предлагаться таблицы актуализации для всех стандартные БД ИРБИС). В будущем (м.б. и до выхода версии 2012.1) будет предложен инструмент для формирования таблицы актуализации на основе таблицы инвертирования (сразу хочу предложить продвинутым пользователям-разработчикам ИРБИС - прежде всего Паневу и Панарину, имеющим опыт работы с регулярными выражениями, разработать такую утилиту). Но при этом надо иметь в виду, что каким бы точным ни был этот инструмент (а абсолютно точным он быть не может по приведенным выше причинам), все равно будет требоваться ручная постредакутра таблицы актуализации.

Следствием введения нового механизма актуализации является изменение
следующих серверных исполняемых модулей:
irbis64.dll
server_64.exe
irbisa.exe
GenPft64.exe
IrbisGblAdmin.exe
Web-шлюзы
(и что самое "неприятное" - они становятся НЕСОВМЕСТИМЫМИ с аналогичными модулями версий ниже 2012.1)

Серверный Администратор ИРБИС64

Введена МНОГОПРОЦЕССОРНАЯ технология для режима СОЗДАТЬ СЛОВАРЬ ЗАНОВО - что позволяет СУЩЕСТВЕННО ускорить выполнение этого режима (дополнительно используется новый исполняемый модуль IrbisMultiLoad.exe).

В связи с этим введен новый паоаметр в IRBISA.INI в секции [MAIN]
MULTILOAD=N
где N - количество параллельных процессов.
По умолчанию N<2 - что определяет однопрцессорный (т.е. "старый") режим загрузки словаря.
Оптимальным значением для N является КОЛИЧЕСТВО ядер (или процессоров) на компьютере, на котором выполняется загрузка словаря (т.е. на сервере)

Выигрыш по времени получается существенным на БОЛЬШИХ БД (>100 тыс.) и при количестве ядер (процессоров) на менее двух.

Ниже приводятся результаты испытаний новой загрузки для БД Электронного каталога объемом 485 тыс.документов на компьютерах разной мощности:

Компьютер Pentium Dual-Core (2-ух ядерный) 2.6 ГГц, 1.99 Гб ОЗУ
Кол-во процессов: 1 (MULTILOAD<2) - время выполнения: 6 час. 27 мин. 3 сек.
Кол-во процессов: 2 (MULTILOAD=2) - время выполнения: 3 час. 36 мин. 42 сек.
Кол-во процессов: 3 (MULTILOAD=3) - время выполнения: 4 час. 13 мин. 10 сек.

Компьютер Intel Xeon 8 процессоров 2.6 ГГц, 2.0 Гб ОЗУ
Кол-во процессов: 1 (MULTILOAD<2) - время выполнения: 6 час. 16 мин. 32 сек.
Кол-во процессов: 8 (MULTILOAD=8) - время выполнения: 1 час. 8 мин. 17 сек.
Кол-во процессов: 10 (MULTILOAD=10) - время выполнения: 1 час. 11 мин. 47 сек.

Пользователи 2011.1 (имеющие БОЛЬШИЕ БД) могут взять новый АРМ Администратор для тестирования

Вот это потрясающая новость! Доработка крайне необходимая.

А можно пример таблицы инвертирования и таблицы актуализации?

Вот реальные таблицы для IBIS (в случае использования вложенных FST - результирующий IFS не должен (желательно) содержать вложенных)

Цитата:

Кол-во процессов: 2 (MULTILOAD=2) - время выполнения: 3 час. 36 мин. 42 сек.
Кол-во процессов: 3 (MULTILOAD=3) - время выполнения: 4 час. 13 мин. 10 сек.

С удовольствием потестирую на 160 тыс. записей.
Но почему при большем количестве процессоров, оказалось большее время. То есть сейчас лучше иметь именно два а не три/четыре процессора?

Суть в том, что делать процессов больше чем ядер - нельзя, это приводит к тому, что эффективность падает. В примерах приводятся случаи для одного процесса, для количества процессов равного количеству ядер, и для случая, когда количество процессов больше чем ядер.

Все, понял. Количество процессов СТРОГО равна количеству ядер.
Если интересно могу протестировать на четырехядерном Феноме.

Alio написал(а):
-------------------------------------------------------
> Пользователи 2011.1 (имеющие БОЛЬШИЕ БД) могут
> взять новый АРМ Администратор для тестирования

Потестируем, точнее поработаем с удовольствием: большинство БД от 1 млн до 6 млн записей, а одна из полнотекстовых 5 млн (LN1 для сортировки - 209 Гб).

А где взять-то?!

За тестовым вариантом Администратора 2012.1 обращаться на alio@gpntb.ru

Тестируем. Пока ошибка 401 см. скриншот

Это ошибка при открытии файла словаря. Никакого отношения к новшеству не имеет.

Конечно ошибка может отношения и не имеет, но встречаюсь с ней впервые.

Пока тестовые показатели без мультипоточности такие.
170665 записей на AMD FX-4100 3.6GHz (4 ядра) - 1 час. 40 мин. 25 сек.

Покажи содержание файла <имя_БД>.par

170665 записей на AMD FX-4100 3.6GHz (4 ядра)
Без мультипоточности - 1 час. 40 мин. 25 сек.
MULTILOAD=4 - 0 час. 28 мин. 10 сек.

При этом создание словаря заканчиваеться с ошибкой.



Редактировано 1 раз. Последний раз 21.12.2011 22:32 пользователем Konstantinus.

Послал исправленную версию IrbisMultiLoad.Exe

170665 записей на AMD FX-4100 3.6GHz (4 ядра)
Без мультипоточности - 1 час. 40 мин. 25 сек.
MULTILOAD=4 - 0 час. 41 мин. 43 сек.

Но результирующие файлы получились для разных способов актуализации разные. Сравнил БД полученную классическим способом и многопоточным.
Файлы <Имя БД>.ifp <Имя БД>.l01 <Имя БД>.n01 различные.

> Но результирующие файлы получились для разных
> способов актуализации разные. Сравнил БД
> полученную классическим способом и многопоточным.
> Файлы <Имя БД>.ifp <Имя БД>.l01 <Имя БД>.n01
> различные.
Это м.б. следствием "блуждающей" ошибки в irbis64.dll, связанной с созданием сверток.
Необходимо использовать irbis64.dll из последнего обновления 2011.1

Дополнение к сообщению от 19 декабря 2011 по поводу
МНОГОПРОЦЕССОРНОЙ загрузки словаря.

Значение параметра MULTILOAD по умолчанию - равно реальному количеству ядер/процессоров в системе (а не 1, как было указано прежде).

Введен дополнительный параметр (в секции [MAIN]):
MULTISORT=
который имеет смысл ТОЛЬКО при MULTILOAD>1 и определяет:
используется (значение 1 - по умолчанию) или не используется (значение 0) многопроцессорная обработка на этапе СОРТИРОВКИ при создании словаря.
Введение данного параметра связано с тем, что при определенных условиях (зависящих от кол-ва процессов и объема БД) многопроцессорная сортировка оказывается МЕДЛЕННЕЕ однопроцессорной. (Здесь нет возможности вдаваться в подробности, почему так происходит, - скажу лишь, что связано это с тем, что собственно процесс сортировки включает разбиение исходных данных на части.)
Тестирование показало, что на двухядерной машине (MULTILOAD=2) при любых объемах БД многопроцессорная сортировка (MULTISORT=1) идет быстрее, чем однопроцессорная.
А вот на машине с 8 процессорами для БД объемом в диапазоне 200-300тыс. многопроцессорная сортировка идет медленнее однопроцессорной (при объемах БД меньше и больше этих значений многопроцессорная "выигрывает")

Обращаюсь ко всем, кто будет тестировать новый режим загрузки словаря (особенно к тем, кто будет использовать машины с 4 ядрами/процессорами)
публиковать данные своих испытаний (сравнивая временные показатели при MULTISORT=0 И MULTISORT=1).
(Тем, кто уже получил предварительную версию нового АРМа Администратор, необходимо получить обновленную версию.)



Редактировано 1 раз. Последний раз 29.12.2011 11:47 пользователем Alio.