Здравствуйте всем.

Я недавно сконвертировал базу из старой самопальной программы в ирбис, где дублетность не проверялась. Мне достоверно известно, что дублетных записей в безе видимо невидимо.

Как бы мне найти все такие записи?

А на этапе конвертирования этого сделать нельзя? А вообще, есть галка при импорте записей "Формально-догический контроль" и если мне память не изменяет, если галка установлена, то сверка на дублетность происходит. Если я ошибаюсь, то есть программное обеспечение из Томска, ISISUtils называется. Распространяется бесплатно. Там можно эти моменты отловить. Обращайтесь к Караушу Александру сергеевичу. Хотя у меня такое ощущение, что он сюда еще напишет :)...

Да, и еще такой вопрос, Вы как конвертировали в ИРБИС? Через промежуточные файлы, а затем импортом, или сразу в базу (так сказать на низком уровне :) )?

Из фокса базу выгружал в текстовый файл в формате
900: ^a...
...
701: ^a..^c..
Затем импортировал в ирбис обычным образом. Так гораздо проще, чем на "низком уровне".

Касательно формально-логического контроля. Он здесь не очень помогает.
Объясняю. До конвертации в ирбисе имеется база LIB, в которой хранятся 8000 статей журналов с 01.01.2004 (это к примеру).
В старой базе (в фоксе) статей около 260 000 с 1993 года до 31.12.2003.
Известно, что в базе LIB (8000) дублетных записей нет.
Далее конвертирую из фокса в bd.txt (с учетом повторяющихся полей итд итп). После из bd.txt импортирую в LIB средствами ирбиса и с формально-логическим контролем. При этом происходит следующее (как мне кажется): ирбис берет очередную запись из bd.txt и сравнивает определенные её поля с УЖЕ ПОСТРОЕННЫМИ словарями предыдущих 8000 записей. Если дублетности не обнаружено (или других глюков) то запись вносится в LIB, но не актуализируется сразу (т.е. в словари не заносится).
Т.О. формально-логический контроль отлавливает дублетные записи только в том случае, если одна из них находится среди первых 8000 записей, а другая среди остальных 260000 записей.

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

То же самое с книгами.

Дублетность можно проверять, делая ИМПОРТ в Каталогизаторе - при этом импортирование, разумеется, будет идти медленно...

Относительно данной темы у меня есть повод пофилософствовать и кое-какие идеи высказать для новых версий.

Во-первых, что каждый имел ввиду под словом «дублетные»? Если речь идет про библиографическое описание документа, то вышеперечисленными способами данная проблема – уничтожения нежелательных повторений библиографических описаний в отдельной базе данных – решается более чем успешно через режим импорта АРМа «Каталогизатор». Да, долго, но реально.

Но если рассматривать проблему шире, а именно, по жизни, то выводы такие:
1. дублетные библиографические описания - записи, создаваемые не автоматическим копированием, а «ручками», ВСЕГДА РАЗНЫЕ и несут технологическую и иную информацию. Будь то отличные от других ключевые слова, рубрики или новые повторения экземпляров документов, которые игнорировать нельзя простым импортом с проверкой на дублетность.
2. Все проверки на дублетность библиографического описания (по опыту) отстают от реальных данных. Например, мне и в последних версиях приходилось убирать некоторые жесткие условия при копировании некоторых документов для создания их описаний, как электронного ресурса, например, файла. Я ничего не писал в форум, поскольку, пока шел до дома, я забыл, собственно, что делал с ИРБИСом (суббота была) :(
3. Ничего более грамотного, чем интерактивная работа в трудных случаях по принятию решения об импорте записи в реальном времени, никто еще не придумал (или я заблуждаюсь?). И иной раз возвращаться к «отвергнутым» при импорте записям возвращаться крайне неохота, тем более что отчет об импорте в log-файл не складывается. И библиотекаря, который принимает экспертное решение об импорте того или иного документа по интерактивным данным, крайне сложно обучать, потому что операция эта разовая и нужна только на этапе конверсии данных, и все время рядом должен находится инженер (хотя зачем – не понимаю, по-видимому, для спокойствия).

Во-вторых, термин «дублетные» меняется в жизни на термин «похожие» с коэффициентом – корреляцией. А вот в этом вопросе по библиографическим данным во всей библиографии тишь. Шкала измерения качества биб.описания содержит два пункта: хорошо и плохо. А вот насколько – много вопросов. Тут библиографы «своих забивают», а автоматизаторов «отстреливают» еще на походе к вопросу. Мне в жизни хватило одного «стрелка» - Эдуарда Рубеновича.

В-третьих, даже если принимается решение о том, что данная запись дублетная, но нужная информация в ней все же содержится, то механизмов слияния с «переменными правилами» в разных АБИС на данное время нет. Функция же слияния ИРБИСа мной пока слабо изучена, и интерактивно с ней работать невозможно.

По всему вышеописанному при конверсии каталогов я обычно импортирую записи без разбора на дублетность. Как есть – ведь это продукт отдела каталогизации! Так почему один автоматизатор должен голову «ломать» над вопросом чистки баз данных без каталогизатора?

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

PS. Тема, однако, мне кажется интересной и перспективной, поскольку дублетных данных в библиотеках великое множество, и сводить все это в рамках разных объединений все равно придется. А моделей-то работы маловато будет, да и никто их не систематизировал!
Может кто найдется из каталогизаторов- читателей данного форума, кто проанализирует эту проблему «красиво». Материал обещаю из практики «подкинуть» интересный. А потом можно и опубликовать. А то, страх, как люблю статьи разные писать :))