Подскажите пожалуйста, как должен выглядеть список студентов в формате excel для то чтобы их можно было импортировать в БД?

Если у вас есть АРМ Книгообеспеченность, то очень просто сделать импорт. Удобнее всего, чтобы всё было в отдельных графах (колонках) - фамилия, имя, отчество, факультет, ну и т.д., какие еще данные вы имеете и хотите видеть у себя в базе. Тогда очень просто можно открыть такой файл в АРМ Книгообеспеченность, назначить каждой колонке то поле, куда попадут данные и всё. Ну еще, разумеется шапку лучше убрать - чтобы не получился студент Фамилия Имя Отчество

Список студентов может выглядеть как угодно (за исключением того, о чем уже написала Татьяна Ароновна - фамилия, имя и отчество - по отдельным столбцам). Порядок следования столбцов не важен, но при последующем импорте порядок следования столбцов должен сохраниться тем же, что и при первом импорте. Главное, чтобы в файле была нужная для работы информация и особенно - идентификаторы записей из той системы, из которой вы импортируете данные, чтобы в последствии можно было без проблем импортировать данные студентов находя записи для слияния не по ФИО+номер группы и/или еще какому-то полю, а по идентификатору.

Могут быть нюансы. Если импортировать только новых пользователей, то проблем быть не болжно (разве что вы не сможете добавить дополнительные поля с информацией, кроме тех, которые есть в таблице).
Можно конечно настроить автоввод или глобальную корректировку после импорта.

А вот если нужно обновить и информацию о тех, кто уже был в БД RDR то придется настроить формат для поиска записей для импорта со слиянием (для обновления значений полей).

Еще в 2018 году приводился пример файлов для импорта из АРМ Администратор серверный (в АРМ Каталогизатор при количестве импортируемых записей более одной-двух тысяч наблюдается проблема с замедлением импорта после определенного момента (видимо переполняется буфер для итогового протокола импорта). В сообщении есть архив с набором файлов примера для импорта с преобразованием данных и формированием дополнительных полей ( например поле с меткой 31).
[irbis.elnit.org]

Что вы подразумеваете под "...поиска записей для импорта со слиянием..."?
Стандартный режим в АРМе Каталогизатор или Администратор?
В АРМе Книгообеспеченность слияние реализуется не настройкой формата, а режимом "Обновить" и заданием параметров обновления.

Да, все верно.

Конечно я имел ввиду настройки АРМ Книгообеспеченность для определения записей для обновления.

По ФИО это делать в большинстве случаев не удается корректно, так как при наличии полных однофамиьцев данные будут загружены не в те записи.
Поэтому тут (в файле mergedbrdr.mnu) стоит дополнительно настроить (если это возможно) дополнительный (третий) вариант.

В АРМ Администратор и АРМ Каталогизато в формате отбора записей для импорта можно более гибко определить условие, включив например не словарь ФИО, а комбинированный словарь (ФИО + что-то еще, что обычно вводят вручную сотрудники библиотеки (дата рождения или номер группы, если она не меняется у студента или номер пропуска, главное, чтобы эта информация была в импортируемом файле и в записях в БД RDR). Это и может стать третьим вариантом отбора записей для обновления.

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

В БД RDR давно есть инверсия - т.н. свертка. Это год рождения + ФИО. Может ее использовать? Можно свертку расширить.

ochagova написал(а):
-------------------------------------------------------
> В БД RDR давно есть инверсия - т.н. свертка. Это
> год рождения + ФИО. Может ее использовать? Можно
> свертку расширить.

Если год рождения вводится то можно попробовать хотя ситуация с наличием полных однофамильцев рожденных в один год хотя и редка но не исключается.

Опять же не у всех вводится дата/год рождения, поэтому скорее всего сделать универсальный механизм свертки не получится, так как условия могут отличаться от библиотеки к библиотеке (ведь нет общих правил ведения БД RDR единых для всех и пользовательские адаптации вполне допускаются). Но принцип такой же - создается отдельный вид поиска, который определяет уникальность записи читателя не по идентификатору, а по ФИО + доп. данные.