В готовящейся версии 2004.1 в АРМе Каталогизатор появится новый режим СЛИЯНИЕ. Реализован он как опция режима ИМПОРТ. В отличие от собственно импорта (когда импортируемые записи добавляются в БД в качестве новых) режим слияния позволяет сливать импортируемые (внешние) записи с записями, уже существующими в БД. Слияние может производится двумя способами: на основе ключевого формата (т.е. формата, по которому формируется термин-ключ, на основе которого находится запись для слияния) или на основе сценария глобальной корректировки. Также реализована возможность вставлять (сливать) в текущую запись (т.е. в ту, которая находится на корректировке) запись из внешнего файла (в формате ISO или TXT.)
Кроме этого, добавляются некоторые новые форматные выходы (UNIFOR) - в частности,
- форматный выход, связывающий текущую запись с несколькими записями другой или этой же БД (это развитие форматного выхода unifor('D....)
- расширение форматного выхода unifor('3...) - для получения различных форм даты и времени.

Порадовался. Спасибо.

Я понимаю, что режим "Слияние" нужен после того, как использован режим "Разливание". Там повторяющиеся (двойные) данные в сливаемых записях удаляются при сливании?

А что будет при слиянии повторений фамилий автора (двух родных братьев Алексанра и Андрея, например) в двух повторениях (при одинаковых инициалах)?

А что будет, если уже в БД имеются дублетные значения кода записи? Нужна предварительная проверка кодов записей на предмет равенства.

Я бы посоветовал разработать режим пакетной работы и для АРМ Каталогизатор, т.к. по моему опыту процесс импорта (и слияния) долгий, и его можно (нужно) делать в ночное время автоматом.

А если нужно нарабатывать опыт для синхронизации ИРБИС64, то там можно работать с log-файлом и уже из него строить файлы локального отчета изменений в записях. Но требуется создавать файлы отчета как для режима слияния по коду записи, так и по mfn записи.

Вопрос. А что планируется относительно встраивания хоть какого-то Z-клиента в АРМ "Каталогизатор" и "Комплектатор"? Может в ИРБИС64 интеграция будет?

Просьба относительно новых команд unifor:
1) организовать цикл по выбору повторений полей, который бы можно было организовать относительно других повторений.
Задача: организовать перенос ключевых слов из повторяющихся подполей ключевых слов в номере журнала (922^5, 922^6, 922^7) в поле 610 той же записи, и чтобы в результате в 610 поле не было повторяющихся значений слов.
У меня ничего не получалось, кроме как организовать такое:
ADD
610
XXXXXXXXXXXXXXXXXXX
&unifor('Av922^5#1')
XXXXXXXXXXXXXXXXXXX
ADD
610
XXXXXXXXXXXXXXXXXXX
if v610:&unifor('Av922^5#2') then else &unifor('Av922^5#2') fi
XXXXXXXXXXXXXXXXXXX
ADD
610

if v610:&unifor('Av922^5#3') then else &unifor('Av922^5#3') fi
XXXXXXXXXXXXXXXXXXX
....
ADD
610

if v610:&unifor('Av922^5#100') then else &unifor('Av922^5#100') fi
XXXXXXXXXXXXXXXXXXX

Получается много строчек, однако.

2) Подойти все-таки к вопросу переменных, в том числе преобразуемых в команды.
Например:
(if v991^a:v201^e then define %a=v201^e enddefine/), (if v910^c:%a then 'YES', else 'NO' fi /)

Переменной %a присваивается значение последнего повторения поля, для которого условие истинно, а потом оно сравнивается со всеми повторениями поля 910^c, и выводится YES или NO.

или
%a=v10001,
....
if val(%a)>699 and val(%a)<703 then &unifor("Kpolename.mnu|"%a),v%a fi


И еще можно поподробнее про связь "одна запись-ко многим"? Там же нужно использовать переменные, содержащие данные о записях.

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

По поводу нового UNIFOR('7....) - связка текущего док-та с несколькими другими - та же идея, что UNIFOR('D...), но по ссылке берется не единственный документ (первый), а все.

Думаю я, не переставая, про слияние - приятная тема.
Идея такая.

В ИРБИС от 2003.1 версии поддерживается проверка на дублетность по нескольким базам.
Так вот, если в какой-либо базе находится дублет, то вывести список баз и влить запись (выбранные поля) из базы данных, где есть дублет (например чей-то заимствованной) в редактируемую. Можно это реализовать через буферную запись, предварительно его просматривая и редактируя, не переходя в другую базу.

И еще идея:
Сделать буферную запись между АРМовой (чтобы данные переносились не только в рамках одного АРМа на одном компьютере), т.е описать структуру буфера, чтобы можно было работать и писать программы, где бы можно было через этот буфер работать, например с Z-клиентом. А то требуется достаточно большое время для экспорта-импорта. Да и можно код написать для exprorer'а (сам напишу), чтобы брать z-запись с сайта и импортировать в буфер записи ИРБИСа.

Задача: организовать перенос ключевых слов из повторяющихся подполей ключевых слов в номере журнала (922^5, 922^6, 922^7) в поле 610 той же записи, и чтобы в результате в 610 поле не было повторяющихся значений слов.
Почему вы не организовали следующий цикл:

ADD
111

(v922^5/)

REPEAT
ADD
610
XXXXXXXXXXXXXXXXXXX
if v610:&unifor('Av111#1') then else &unifor('Av111#1') fi
XXXXXXXXXXXXXXXXXXX
DEL
111
1

UNTIL
if p(v111) then '1' else '0' fi

> Почему вы не организовали следующий цикл:
а) Тогда еще этого не было в старой версии (2002.1), которую необходимо было использовать.
б) я не знал тогда про это.

Обновлена версия программы для просмотра LOG-файлов - LogViewer.EXE

Где ее брать, и что в ней обновлено?

В версии 2004.1:
В АРМе Администратор добавлен режим создания новой произвольной базы данных, т.е. абстрактной БД ИРБИС без какой-либо параметрии - полезно тем, кто создает под ИРБИС произвольные (небиблиографические) БД.
В АРМах Каталогизатор и Комплектатор реализована идея ВЛОЖЕННЫХ РЛ (WS) (по аналогии с вложенными форматами). Это позволяет создавать типовые РЛ (например, в виде одной страницы РЛ), из которых формировать (как из "кирпичиков") реальные РЛ - при этом достаточно откорректировать вложенный РЛ, чтобы соответствующим образом изменились все РЛ, в которых он используется.

В версии 2004.1
В АРМах Читатель и Каталогизатор в ПОИСКЕ добавлены новые логические операторы (дополнительно к И, ИЛИ, НЕТ):
И (в поле) - определяет присутствие терминов в одном повторении поля (пример применения: поиск по словам из заглавия в оглавлении журнала);
И (фраза) - определяет присутствие терминов в одной фразе (в указанном порядке).
Кроме того, для сценариев поиска добавлен новый параметр
ItemLogicN=
который определяет, какие логические опреаторы могут использоваться для данного вида поиска. Возможные значения:
0 - только логика ИЛИ;
1 - логика ИЛИ и И;
2 - логика ИЛИ, И, НЕТ (по умолчанию)
3 - логика ИЛИ, И, НЕТ, И (в поле)
4 - логика ИЛИ, И, НЕТ, И (в поле), И (фраза)

В версии 2004.1
В АРМе Администратор введена команда для пакетного задания:
EXIT [путь_имя_файла]
закрывающая АРМ Администратор. Если задан параметр - он рассматривается как путь/имя_файла, в котором сохраняется протокол выполнения пакетного задания.

В версии 2004.1
В АРМе Каталогизатор введена возможность определять права доступа к базам данных в рамках заданного контекста работы. Т.е. в списке доступных БД (который содержится в справочнике, имя которого определяется через параметр DBNAMECAT INI-файла, - по умолчанию dbnam2.mnu) можно определить БД, которые доступны только на чтение. Для этого перед именем БД в справочнике надо поставить знак "-" (минус)
Разумеется, речь идет о правах доступа ТОЛЬКО в рамках ИРБИС - не надо путать с сетевыми правами доступа.

2004.1 она такая хорошая будет.... Особенно, то что касется создания небиблиографических БД и вложенных РЛ, не говоря уже о слиянии....
Надеюсь увидеть в Судаке!

Поддерживаю идею из Томска, о встроенном Z-клиенте

В версии 2004.1
В АРМе Книговыдача дополнен режим скоростной книговыдачи на основе штрих-кодов - в части возврата многоэкземплярной литературы с одинаковыми штрих-кодами, в случае когда на руках у нескольких читателей имеются экземпляры таких изданий. А именно - при возврате (когда вводится только штрих-код возвращаемого экземпляра) в случае возникновения неопределенности предлагается ввести дополнительно штрих-код читателя.

Александр Иосифович!

Я тут не понял такой момент.
Будет ли в форме "буферная запись" в АРМ "Каталогизатор" добавлена возможность "СЛИЯНИЕ", что описана выше?
Очень ожидаю такую функцию. Поскольку тут сразу появляется возможность удаленной систематизации.

Для буферной записи нет слияния. Но не забывайте, что можно работать с НОВОЙ записью, как с временным буфером: т.е. в НОВУЮ (или врменно опустошенную) запись можно вставить буферную запись, затем выполнить СЛИЯНИЕ и результат опять взять в буфер и т.п. - надеюсь, идея понятна.

Идея понятна, но долгая. Целых три операции вместо одной :)
Посмотрю как пойдет.

В версии 2004.1
В АРМе Книговыдача:
- появилась возможность с помощью параметров INI-файла определять доступность/недоступность кнопок, связанных с ответственными режимами работы: ВЫПОЛНИТЬ (заказ), УДАЛИТЬ (заказы), ВОЗВРАТ, ВЫДАЧА БЕЗ ЗАКАЗА, ВЫДАЧА БЕЗ ЭК, ПРОДЛИТЬ, УДАЛИТЬ (сведения о выдачах/возвратах в записи читателя).
- на плоскости ЧИТАТЕЛИ в области ЧИТАТЕЛЬ появилась кнопка, обеспечивающая печать текущей записи читателя в заданном формате.

А вот такая функция:
Можно ли сделать preview (предварительный просмотр) импортируемых записей из MARC-файла (или другого коммуникативного формата)? Т.е. показывается часть записи в формате, типа brief.pft (или что сами пользователи нарисуют), и потом можно выбрать определенные записи и только их импортировать? Для начала сделать только 2: UNIMARC-preview и USMARC-preview, и показывать автора, заглавие и вых.данные.

Дело в том, что все чаще и чаще библиотекам, например из книготорговых организаций приходит один большой файл, содержащий описания всех книг, поскольку робот там по фактуре создает такой файл. И те книги, что требуют докомплетования не нужно импортировать. Причем процент докомплектования в ряде случаев 80%. Таким образом, за 1 месяц работы набирается более 2000 удаленных записей логически. Можно постоянно делать реорганизацию, но это не выход, потому что основную массу "пустых" записей в каталог добавляет именно "ненормализованный" импорт, который нельзя ничем другим отсечь, кроме предварительного просмотра и выбора конкретных записей.
Для справки:
Если работают 20 каталогизаторов в сети, и на компьютере Celeron533 идет импорт с созданием словаря ключевых слов на 150-200 записей, то на сети в 100 Mbit это делается 10-15 минут. При этом все остальные в сети отдыхают, причем 80% этих записей удаляются (т.е. производительность 1/5). А если добавить к этому "медленное" размножение статей из содержания журналов, типа "Компьютер-Пресс" от корки до корки (90-100 статей) и других (а их 150), то моментов, когда сеть не занята совсем не остается.
Ситуация в сети при работе с ИРБИС64 несколько оптимистичней, чем при ИРБИС32, но и там пустые записи копятся, только ситуация с реорганизацией там хуже, поскольку каталогизатору не дашь право заходить на сервер терминалом.

Почему нельзя создать временную БД, в которую загонять весь импорт, а потом просматривать эту БД и что необходимо копировать?
И не надо импортировать большие порции док-ов через Каталогизатор - это надо делать через АРМ Администратор.

> Почему нельзя создать временную БД, в которую загонять весь импорт, а потом просматривать эту БД и что необходимо копировать?

Потому что, 80% всех затрат времени идет на пустоту. И это обидно.

> И не надо импортировать большие порции док-ов через Каталогизатор - это надо делать через АРМ Администратор.

Так я что буду им давать в ИРБИС64 терминал??? Или буду сам сидеть на вводе партий книг?

Тут логика-то такая, что основные затраты времени на этап попадания данных в mst-файл. Ну медленная функции (набор функций), что и говорить! А при простом пробегании по MARC файлу все равно пройдет сразу и проверка и выбор.
Такое средство я бы и сам сделал, только у меня нет возможностей, чтобы воплотить такое по причине закрытости структур форматов. Видимо, придется делать некий конвертор в IsisUtil, который будет "кушать" MARC файл, показывать предпросмотр по brief и потом выделенные записи "выбрасывать" в другой MARC-файл. Хотя хотелось бы сразу в БД ИРБИСа.



Отправка отредактированного (29-04-04 17:52)

А технологию с использованием БД PODB не хотите применять?

Светлана Михайловна!

> А технологию с использованием БД PODB не хотите применять?
Нет. Эта технология в данном случае не поможет.

Записи из книготорговой организации приходят при получении заказа, т.е. автоматом собирается в торговой организации MARC-файл, содержащий все записи на документы (или они пытаются собрать все, но на практике, конечно же, не все), что имеются в заказе (биб.записи сделаны в РКП). И весь этот файл после проплаты за заказ падает в электронный ящик ответственного за заказы от системы библиотек. Причем, иногда в файле по 300-500 записей, которые все приходится импортировать (с учетом докомплектования для системы библиотек - про это я выше писал).
Если бы их заказывали и ручками ставили в заказ, то можно было бы использовать сокращенный ввод с PODB. А вот в Топ-Книге, например, есть специальные макросы для Excel, которые собирают заказы распределенно, по разным библиотекам ЦБС, сами собирают суммарный заказ (или упрощают сведение его) и шлют итоговый заказ по электронной почте на фирму для выписки счета. Очень удобно, но всякий раз еще эти данные набирать в АРМы ИРБИСа, учитывая качество описания в прайсе в строке Excel и учитывая распределенность каждой библиотеки в системе, где у каждой стоит локальный ИРБИС, не логично. А биб.записи приходят после проплаты, что логично. Книги же всей партией поступают в единый центр обработки и каталогизации на все библиотеки системы.

Просто для сведения.
У нас в ГПНТБ при получении обязательного экз-ра получаем по эл. почте регистрационную БД РКП (общую, не только на полученное нами), загружаем ее в PODB (сами работники отдела обработки), там проводится разметка полученных экз-ров (ввод инвентарей и КСУ), разметка экземпляров, необходимых для докомплектования, и передача записей на обработку, причем в записи томов сразу переносятся сведения общей части из ЭК.
PODB используется для получения исходных описаний комплектаторами для того, что не получили как ОЭ, но хотим приобрести. PODB не реорганизуется, но время от времени опустошается.

Мы по той же схеме сейчас используем БД IBIS, которую также опустошаем. В общем-то работать можно, но хочется поэффективнее. Как? Пока сказать не могу.
В Крыму данная "штука" будет в нашем IsisUtil. Только в ИРБИС мы данные загружать все равно не сможем - слишком много файлов условий и обработок на входе. Но селекцию записей "ручками" для выгрузки делать позволим.

В версии 2004.1
Включены новые форматные выходы (&unifor(...) в языке форматирования:
1. &unifor('7...) - реализация реляционности, т.е. реализация отношений "от одного к многим" - позволяет при расформатировании текущего документа осуществить расформатирование группы связаннызх документов из другой БД (фундаментальная по своей важности функция).
Конструкция передаваемых данных:
7<имя_БД>,</termin/>,<@имя_формата|формат>

имя_БД - имя базы данных, из которой будут браться связанные документы; по умолчанию, т.е. если имя БД "пустое", используется текущая БД.
/termin/ - ключевой термин, на основе которого отбираются (ищутся) связанные документы; термин заключается в уникальные ограничители (например. /), в качестве которых используется символ, не входящий (гарантированно) в термин.
@имя_формата|формат - имя формата или формат в явном виде, в соответствии с которым будут расформатироваться связанные документы. Если задается имя формата, то он берется из директории БД, заданной параметром <имя_БД>.
Есть аналогичный форматный выход - &unifor('D...) - который реализует связь "от одного к одному", т.е. из связанных документов берется только первый.
Пример:
...&unifor('7TEST,',"/T="v200^a"/",',v903"\par "')....

2. &unifor('+1....) - работа с глобальными строковыми переменными. Имеются три подфункции:
+1RNNN - чтение переменной с номером NNN
+1WNNN#AAA - запись в переменную с номером NNN значения AAA
+1 - опустошение всех глобальных переменных.
Глобальность переменных заключается в том, что перед началом очередного расформатирования они НЕ опустошаются, т.е. через глобальные переменные можно передавать данные из одного расформатирования в другое. Количество переменных не ограничено.
Пример:
...&unifor('+1W100#0')...(.....&unifor(|+1W100#|d999,F(val(&unifor(|+1R100|d999))+val(v999),0,0)).....).....&unifor('+1R100')....

3. &unifor('3...') - выдача данных, связанных с ДАТОЙ и ВРЕМЕНЕМ
Имеются следующие подфункции:
3 - выдать текущую дату в виде ГГГГММДД
30 - выдать теекущий год в виде ГГГГ
31 - выдать текущий месяц в виде ММ (с лидирующим нулем)
32 - выдать текущий день в виде ДД (с лидирующим нулем)
33 - выдать текущий год в виде ГГ
34 - выдать текущий месяц в виде М (без лидирующего нуля)
35 - выдать текущий день в виде Д (без лидирующего нуля)
36MM - выдать по заданному номеру месяца его название на русском языке в именительном падеже
37MM - выдать по заданному номеру месяца его название на русском языке в родительном падеже
38MM - выдать по заданному номеру месяца его название на английском языке
39 - выдать текущее время
3А - выдать номер текущего дня от начала года
Пример:
....&unifor('36',&unifor('34'))....

4. &unifor('!') - команда постредактуры: очистить результат расформатирования от двойных разделителей (двойных точек или двойных конструкций <. - >). Имеет смысл использовать один раз в любом месте формата.

5. &unifor('+F') - команда постредактуры: очистить результат расформатирования от RTF-конструкций. Имеет смысл использовать один раз в любом месте формата.

Да вот это возможности!!!.
А.И. просто фундаментальное спасибо!!!

И сразу хочется спросить про &unifor('36MM') он всегда выводит только в руском независимо от настроек локализации. Если да, то может в будущем добавить возможность для пользователей Украины и Казахстана учитывая их настройки локализации.
И тут же если необходимо выдать полную дату и текущее время ДДММГГГЧЧММСС, то нужно будет использовать комбинацию из &unifor-ов 32, 31, 30, и 39. Или есть сразу один вызов &unifor('3...'). Если нет то наверное даже так лучше из "кирпичиков" собирать то что тебе надо.


Еще хотел спросить как организована работа с переменными &unifor('+1....). Они хранятся в памяти или в каком-то временном файле, и как долго они живут:(для текущего формата или сценария глоб корр. или пока АРМ работает???)

Спасибо.



ДНАББ им. Заболотного
Саша

>И сразу хочется спросить про &unifor('36MM') он всегда выводит только >в руском независимо от настроек локализации. Если да, то может в ?>будущем добавить возможность для пользователей Украины и >Казахстана учитывая их настройки локализации.

К сожалению, локализация не используется - только по-русски.



>И тут же если необходимо выдать полную дату и текущее время >ДДММГГГЧЧММСС, то нужно будет использовать комбинацию из >&unifor-ов 32, 31, 30, и 39. Или есть сразу один вызов &unifor('3...'). Если >нет то наверное даже так лучше из "кирпичиков" собирать то что >тебе надо.
Именно так - надо использовать комбинации unifor




>Еще хотел спросить как организована работа с переменными &unifor
>('+1....). Они хранятся в памяти или в каком-то временном файле, и как >долго они живут:(для текущего формата или сценария глоб корр. или >пока АРМ работает???)
Разумеется они хранятся в памяти и живут пока длится сенс работы АРМа

У меня вопрос: возможно только NNN или NNNNNNNNNN тоже реально :)? Еще вопрос: длина строки ограничена 255 или 2^30 :)?