Здравствуйте, есть вопросы по поводу использования системы слияния записей.

Есть две записи. Нужно перенести из второй в первую сведения об экземплярах (кол-во повторений 910 поля >100 в обеих записях). Причем сделать это надо таким образом, чтобы в первую запись были добавлены только те повторения 910 поля из второй записи, в которых есть штрих-коды, отсутствующие в первой записи.
При этом нужно перенести и те повторения, в которых нет штрих-кода, но есть инв. номера.

Что должен возвращать формат, используемый в режиме слияния записей?

И вообще, каковы механизмы работы системы импорта со слиянием?

Если можно, хотелось бы увидеть хотя бы оди пример формата.

Заранее большое спасибо.

Примером формата слияния в БД IBIS является IMPSVK.PFT - обеспечивающий слияние при создании СВОДНОГО каталога...
В общем формат слияния используется следующим образом:
- входной (импортируемый) документ расформатируется по формату слияния;
- результат расформатирования рассматривается как ключ (термин), по которому в БД находится тот документ (назовем его документ слияния), который будет сливаться с входным (если таковой не находится, входной документ просто импортируется).
При слиянии действует "жесткий" алгоритм:
- оригинальные значения повторяющихся полей складываются (т.е. если во входном документе 5 значений 910 поля, а в документе слияния 4 значения 910 поля, то в результирующем документе будет 9 повторений 910 поля - при условии, что все повторения оригинальные)
- значения неповторящихся полей замещаются (т.е. если во входном документе и в документе слияния есть 200 поле, то в результирующем документе останется 200 поле входного документа)
Т.е. при собственно слиянии никакого анализа внутренней структуры полей (т.е. подполей) не производится - они сравниваются как единое целое. Иными словами - все тонкости алгоритма слияния необходимо реализовывать в ФОРМАТЕ СЛИЯНИЯ.

Александр Иосифович, большое спасибо, только вот IMPSVK.PFT не нашел ни в 4.1 ни в 4.2.
Если можно, пришлите его, пожалуйста :)

В 2004.2 для примера "вливания" записей в сводный каталог есть форматы:
impsvk.pft - определяет ключ поиска ("свертка" ЭД БО, как и при сверке на дублетность);
impsvk.fst - определяет набор полей для слияния;
mergepft.mnu - перечень форматов *.pft.

Помогите, пожалуйста разобраться! Не могу понять, почему не работает...

Есть следующая ситуация - БД не ЭК, есть три поля A, B, C
Необходимо, чтобы при импорте в записи добавлялись поля С а сверка на дублетность осуществлялась по полям А и В.

IMPSVK.PFT:
IF p(g1005) then g1005 ELSE if val(&uf('JLSINV,',"!"v200," - "v210))>0 then "!"v200," - "v210 fi,FI

IMPSVK.FST:
1005 0 &uf('+1W1005#'''),&uf('+1W1005#'"!"v200," - "v210),
10 0 if &uf('+1R1005')<>'' then else (v10/) fi
200 0 if &uf('+1R1005')<>'' then else (v200/) fi
210 0 if &uf('+1R1005')<>'' then else (v210/) fi
211 0 if &uf('+1R1005')<>'' then else (v211/) fi
910 0 if &uf('+1R1005')<>'' then else (v910/) fi

В LSINV.FST есть 999 0 "!"v200," - "v210/
файлы default.ws и LSINV.ws есть.

Может быть чего-то не учел?

Здесь есть опечатки, но они становятся хорошо видны только в редакторе форматов. Первая строка ТВП должна выглядеть так:

&uf('+1W1005#'),&uf('+1W1005#',if val(&uf('JLSINV,',"!"v200," - "v210))>0 then "!"v200," - "v210 fi),

Всё-таки нам -- простым смертным без подсветки править нельзя. :)

Вообще должен тебя очень поблагодарить: если бы в пятницу мы совместно не почесали затылки, изучая IMPSVK.FST, завтра я, вероятно, даже не задумываясь над возможностями слияния, добавил бы в свою базу для заимствования 100 тыс. дублетов. А теперь постараюсь использовать прогрессивные методы. :)

PS
Очень печально, что на форуме нет режима подсветки. Например, никогда и никто точно не подчитает, сколько здесь апострофов и сколько кавычек: "''''"'"""''. Просматривая листигни, можно можно угадать, что находится на экране только по смыслу.

Комментарии для тех, кто не понял, как работает режим слияния и что делает приведённые Романом код.

Файл FST(ТВП) определяет должна ли в базе создаваться новая запись, а файл PFT(далее - формат) - какая из имеющихся в базе записей должна быть дополнена полями из текущей импортируемой записи. Грубо говоря, можно сказать, что ТВП отвечает за дополнение БАЗЫ новыми ЗАПИСЯМИ, а формат за дополнение одной ЗАПИСИ новыми ПОЛЯМИ.
ТВП и формат могут использоваться как независимо, так и совместно. При совместной работе вначале обрабатывается ТВП, а потом формат. В этом режиме ТВП передаёт через глобальную переменную "ключ"(см. ниже) и формат уже не генерирует его самостоятельно(IF p(g1005) then g1005 ELSE <самостоятельная генерация> FI).

Выше я употребил выражение "FST определяет должна ли создаваться новая запись", но это неверно. Так должно быть, но это не так. Даже если необходимость в создании записи отсутствует, в базе всё равно создаётся запись, но ПУСТАЯ. Это конечно же не есть хорошо...

"Ключ" - это любое значение словаря, включая префикс, которое может однозначно идентифицировать запись. (Например, если вы сливаете две версии своего каталога, им может быть системный шифр(903) или инвентарный номер(910^b). Роман использует в качестве ключа поля 200 и 210(обратите внимание, что это допустимо только в ИРБИС 64)).
В файлах IMPSVK.PFT и IMPSVK.FST в качестве ключа используется то, что разработчики называют "библиогафической свёрткой документа". Это строки из маленьких фрагментов полей, смешанных между собой по строго определённому алгоритму, которые всегда являются одинаковыми для двух одинаковых записей. Их используют для проверки на дублетность, а так же во случаях, когда сравнивать между собой записи целиком затруднительно.
Вот пример такой свёртки: !005-235-02315-3лзЖюаидмзеенйч778426
Надо подчеркнуть, что восклицательный знак в начале - это не часть свёртки. Это префикс словаря - то, посредствам чего система определяет принадлежность помещённого в словарь термина к определённой группе терминов(например, заглавия в словаре имеют префикс "Т=", а авторы "A=").

Продолжение возможно последует...

Кирилл, спасибо, что поправил. ;)
Чесно говоря, я и сам еще не до конца понимаю, как должна работать система.
При проверке - формат в pft-файле создает ключ, существующий в словаре, формат в fst-файле пишет то же самый ключ в переменную, НО! При импорте записей они не вливаются в существующую дублетную запись, а дописываются в БД как новые записи, причем теряя одно поле - 200...

> Роман использует в качестве ключа поля 200 и 210(обратите внимание, что это допустимо только в ИРБИС 64)).

А в чем разница между тем, какие поля использовать? И почему только в 64-м? Ведь БД - произвольная - "не ЭК"! Там могут быть любые метки - хоть 3, 4, 5, 83 - для БД VUZ! Я потому и описал задачу вцелом для - А, В, С, чтоб легче было прояснить ситуацию...



Редактировано 2 раз. Последний раз 12.12.2006 08:53 пользователем А. Роман.

???

Роман, вы проверяли формат &uf('JLSINV,',"!"v200," - "v210) в БД LSINV для значений полей 200 и 210 в GenPft? Т.е. в некой БД в некой записи сделайте поля 200 и 210, которые импортируются, и смотрите находит ли формат для них запись в LSINV. А в ИРБИС-32 это может не работать, если "!"v200," - "v210 больше 30 символов.

Конечно проверял. И именно на той БД (со всеми упомянутыми полями) в которую собирался вливать записи.

А про ограничения длины терминов в 32-м уже стал забывать... :)

Отправил Вам по электронной почте письмо со ссылками на архив БД и примером того, что нужно "влить" в эту БД.



Редактировано 1 раз. Последний раз 12.12.2006 11:58 пользователем А. Роман.

Обнаружил такую проблему - выдает сообщение: скопировано документов 0 с номерами 0-0
При этом, в нужную запись все же добавляется только одно повторение 910 поля...

Роман, ты абсолютно прав, слияние в режиме добавления оригинальных записей и дополнения имеющихся не работает. Совместно использовать fst и pft нельзя. Очевидно, что это программная ошибка.

Хочу заметить, что всё сказанное мной выше относительно устройства формата и ТВП абсолютно справедливо, по отношению к структуре файлов предоставленных разработчиками. Именно на режим параллельной работы IMPSVK.PFT и IMPSVK.FST рассчитывал их автор, но, судя по всему, об ошибке в исполняемом файле на момент написания этих файлов он знал не больше нас. Единственное, что мне не совсем понятно, так это почему столь очевидная ошибка оказалась незамеченной?

Подводя итоги, могу сказать следующее:
1. Режим дополнения ЗАПИСЕЙ(IMPSVK.PFT, например) функционирует нормально.
2. Режим дополнения БАЗЫ(IMPSVK.FST, например) функционирует некорректно, поскольку с одной стороны, в ходе отбора без всякой нужды создаются пустые записи, а с другой его использование приводит к автоматическому отключению режима дополнения записей.

В ходе экспериментов, оказалось, что при совместном запуске ТВП и формата, формат даже не расформатируется. Глобальные переменные, которые в нём находятся(напр, &uf('+1W807#Запуск выполнен')) не возвращают никаких значений.

Конечно, допустимо автономное использование режимов дополнения базы и дополнения записей. Но это лишает функцию слияния её ключевой возможности - возможности дополнения имеющихся записей записями в других форматах! Например, если у меня имеется база в Rusmarc, полученная от РКП, и я хочу дополнить свои записи некоторыми полями из неё(например, добавить аннотацию), то этого я сделать не смогу.
Тестировалось с системе ИРБИС 32, версия 2006.1

Александр Иосифович? Мяч на вашей стороне поля!

А. Роман написал(а):
-------------------------------------------------------
> IMPSVK.PFT:
> IF p(g1005) then g1005 ELSE if
> val(&uf('JLSINV,',"!"v200," - "v210))>0 then
> "!"v200," - "v210 fi,FI
>
> IMPSVK.FST:
> 1005 0 &uf('+1W1005#'''),&uf('+1W1005#'"!"v200," -
> "v210),
Здесь также нужно при формировании 1005 поставить условие наличия в БД соответствующей записи

> 10 0 if &uf('+1R1005')<>'' then else (v10/) fi
> 200 0 if &uf('+1R1005')<>'' then else (v200/) fi
> 210 0 if &uf('+1R1005')<>'' then else (v210/) fi
> 211 0 if &uf('+1R1005')<>'' then else (v211/) fi
> 910 0 if &uf('+1R1005')<>'' then else (v910/) fi

Здесь (если бы было учтено мое первое замечание) Вы определяете, что если запись найдена, то вводить в нее ничего не нужно !!!
А так, как написано у Вас, результат расформатирования всегда пустой, в том числе и для новой записи

При этом нужно учесть следующее (несколько дополняю то, о чем говорил Соколинский):
1. по impsvk.pft - ищется запись в БД, найденная корректируется, не найдено - создается новая
2. по impsvk.fst импортируемая запись переформатируется
3. в новую запись вносятся ВСЕ данные
4. при корректировке записи действует следующее правило: неповторяющиеся поля заменяются, к повторяющимся приписываются оригинальные (определяется по default.ws)


<Обнаружил такую проблему - выдает сообщение: скопировано документов 0 с номерами 0-0
При этом, в нужную запись все же добавляется только одно повторение 910 поля...>
Такое сообщение выдается при импорте со слиянием с глобальной корректировкой: здесь первоначально создается новая запись, затем при ЕЕ корректировке находится и корректируется (оператор CORREC) нужная запись, а созданная удаляется (в дистрибутиве форматы IMPSVK_SIGLA.FST и IMPSVK_SIGLA.GBL)
P.S. В первоначальном варианте в файлах IMPSVK.FST и IMPSVK.PFT были ошибки, исправлены в обновлении D3 версии 2005.2

Дунаевская написал(а):
> 1. по impsvk.pft - ищется запись в БД, найденная
> корректируется, не найдено - создается новая

Светлана Михайловна, Ваше объяснение входит в противоречие с кодом IMPSVK.FST и IMPSVK.PFT. Зачем IMPSVK.PFT проверяет наличие глобальной переменной 1005 и пытается её использовать, если она не задана ранее в IMPSVK.FST?

Да, действительно, мои пп. 1 и 2 нужно переставить местами
1. по impsvk.fst импортируемая запись переформатируется
2. по impsvk.pft - на переформатированной импортируемой записи ищется запись в БД; найденная корректируется, не найдено - создается новая
3. в новую запись вносятся ВСЕ данные
4. при корректировке записи действует следующее правило: неповторяющиеся поля заменяются, к повторяющимся приписываются оригинальные (повторение определяется по default.ws)

Дунаевская написал(а):
-------------------------------------------------------
> Да, действительно, мои пп. 1 и 2 нужно переставить
> местами

Можно заключить, что сделанные мной и Романом выводы справедливы. Источником ошибок является исполняемый файл. Ещё раз перечислю проявления ошибок:

1. Даже в том случае, когда FST не генерирует ни одной строки, в базе создаются пустые записи;
2. При совместной работе PFT и FST дополнение записей имеющихся в базе не происходит(PFT даже не расформатируется)
3. В ИРБИС 64 при слиянии записей добавляется только одно повторение(подробности может сообщить только Роман. У меня в ИРБИС 32 2006.1 добавляются все повторенияо.)

Присылаю по e-mail образцы экспериментальных файлов.

ИТОГИ
Я ошибался, утверждая, что слияние с одновременным использованием FST и PFT не работает. Это показали результаты тестирования в ИРБИС 32-2006.1 и ИРБИС 64 - 2006.1 на слияние загружаемых записей с текущей базой. Единственная ошибка, которая при этом место – это ошибка, связанная с созданием в ИРБИС 32 пустых записей. Разработчики признают её наличие. Что касается моих пояснений относительно IMPSVK и формата Романа, то они, как ни странно, не потеряли своей актуальности, хотя проанализированные решения могли бы быть гораздо проще.
Главной причиной наших с Романом затруднений было то, что мы неверно определили назначение оригинального файла IMPSVK.FST. Мы ограничились изучением его первых строк(набор конструкций if &unifor('+1R1005')<>'' then else fi), совершенно не обратив внимания последнюю строчку, ради которой он создавался:
902 0 (v902/)
Цель IMPSVK в том, чтобы дописывать к имеющимся в базе записям сиглу библиотеки и добавлять новые записи, если аналогов в базе нет. Я очень благодарен Светлане Михайловне за то терпение, с которым она отвечала на мои не всегда разумные вопросы. Вышеупомянутую строку FST я в упор не замечал.
Теперь считаю своим долгом привести несколько простых примеров, которые могли бы хорошо проиллюстрировать различные варианты использования режима слияния и сохранить время тем, кто намерен его применять. Чтобы упростить объяснения хотел бы переопределить(ввести с новыми значениями) два понятия:
1. ИМПОРТ - добавление в базу новых записей;
2. СЛИЯНИЕ - дополнение записей базы полями из других записей.

ПЕРВЫЙ РЕЖИМ: ИМПОРТ+СЛИЯНИЕ
FST
10 0 (v10/)
200 0 (v200/)
210 0 (v210/)
211 0 (v211/)
910 0 (v910/)

PFT
"!"v200," - "v210

Комментарий. В данном случае, поскольку схема полей одинакова, то от FST можно вообще отказаться.

ВТОРОЙ РЕЖИМ: ТОЛЬКО СЛИЯНИЕ
FST
1005 0 &uf('+1W1005#'),&uf('+1W1005#',if val(&uf('J,',"!"v200," - "v210))>0 then "!"v200," - "v210 fi),
10 0 if p(g1005) then (v10/) fi
200 0 if p(g1005) then (v200/) fi
210 0 if p(g1005) then (v210/) fi
211 0 if p(g1005) then (v211/) fi
910 0 if p(g1005) then (v910/) fi

PFT
g1005

Комментарий. Некорректно работает в ИРБИС 32. Вместо каждой пропущенной записи будет создана пустая запись. Занятно, что при перелистывании этих пустых записей система каждый раз спрашивает: "Сохранить изменения?".

ТРЕТИЙ РЕЖИМ: ТОЛЬКО ИМПОРТ
FST
1005 0 &uf('+1W1005#'),&uf('+1W1005#',if val(&uf('J,',"!"v200," - "v210))>0 then 'TRUE' fi),
10 0 if a(g1005) then (v10/) fi
200 0 if a(g1005) then (v200/) fi
210 0 if a(g1005) then (v210/) fi
211 0 if a(g1005) then (v211/) fi
910 0 if a(g1005) then (v910/) fi

PFT
Не требуется.

Комментарий. Некорректно работает в ИРБИС 32. Вместо каждой пропущенной записи будет создана пустая запись.

Возможно, Светлана Михайловна выпустит оптимизированную версию IMPSVK, которая так же сможет выступать в качестве наглядного примера. Но пока иллюстрировать различные решения удобнее было на формате Романа. Следует только заметить, что формат ключа("!"v200," - "v210) писался им для весьма специфической задачи. В случае, когда требуется определить дублетность обычных записей, имеет смысл пользоваться алгоритмом свёртки из первых строк IBIS.FST(квалификатор 999).



Редактировано 2 раз. Последний раз 26.12.2006 01:08 пользователем Кирилл Соколинский (СЗТУ).

Вы не сказали о том, что задачей Романа было объединение дублетных записей из входного файла, а именно, оригинальные заглавия должны записываться как новые записи, и в них должны собираться все соответствующие экземпляры.
Этот режим действительно не требует FST, а в PFT может быть записан просто ключ.
Однако, этот режим (дублеты во входном файле импорта) работает пока только в ИРБИС 32.

Дунаевская написал(а):
-------------------------------------------------------
> Однако, этот режим (дублеты во входном файле
> импорта) работает пока только в ИРБИС 32.

Я правильно Вас понял, ИРБИС 64 не актуализирует записи в ходе загрузки(слияния)?

Да, ввод в БД и актуализация словаря производится для всей группы входных записей, а не по-документно.

В ИРБИС64 версии 2006.2 режим импорта в АРМе Каталогизатор (включая импорт со слиянием) будет учитывать дублеты внутри входного файла (аналогично ИРБИС 32)

Извините. Почитал почитал, не совсем все понял.
Какой файл отвечает за поиск необходимой записи для слияния?
Например, очень простой примерчик:
Необходимо у читателей с известными номерами читательских билетов "v30" добавить какое-либо поле vXXX. Для этого из какой-то другой БД (не ИРБИС) экспортировали файл вида:
#30: 111
#XXX: 1
*****
#30: 222
#XXX: 0
*****
#30: 333
#XXX: 1
*****
Затем надо произвести импорт со слиянием. Что необходимо прописать в fst?

Здесь FST не нужен

pft? слияние через gbl?
Через слияние же такую операцию необходимо проводить?
Я же простенький пример привел, дабы разобраться в принципе слияния. В примере с impsvk разобраться не смог :(



Редактировано 1 раз. Последний раз 17.09.2007 16:33 пользователем iLq.

В PFT нужно записать ключ (поисковый термин) "RI="v30.
FST не нужно, поскольку никакого преобразования данных и условий их ввода не нужно - поле ХХХ будет добавлено в найденный в БД документ с учетом следующего принципа:
- если поле ХХХ определено в DEFAULT.WS как неповторяющееся, то оно будет заменено полем из импортируемого документа,
- если же оно определено как повторяющееся, то из импортируемого документа будут добавлены повторения поля, значения которых отсутствуют в найденном в БД документе.

Спасибо большое. Наконец разобрался. Я почему то подумал, что слияние через fst, а ТВП через pft, а оказалось наоборот.

А если поля нет в default.ws оно замениться или добавиться? Не зависимо от ответа считаю, что должно добавиться.

Пожалуйста помогите разобраться

Стоит Ирбис 64, v7.2

Так получилось, что при корректировке БД RDR были удалены "лишние" повторения поля 40. Теперь встала необходимость добавить "недостающие" данные в поле 40 из архивной копии (так как эта проблема обнаружилась только спустя два дня).

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