Дипломная работа МГУ! ХРАНИЛИЩЕ НАУЧНЫХ ПУБЛИКАЦИЙ

Идея дипломной работы очень хорошая! Поставили 5! Гарантирую что и Вам поставят пять!

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

Получил 5! ...

1. Введение ……………………………………………………………………. 3
2. Постановка задачи………………………………………………………….7
3. Программные системы поддержки библиотечного дела…………….. 8
3.1 АБИС …………………………………………………………………… 8
3.1.1 Абсотек Юникод ..……………………………………………. 9
3.1.2 МАРК-SQL …………………………………………………... 10
3.2 Системы управления библиографической информацией ………….. 12
3.3 Заключение……………………………………………………………. 13
4. Построение модели..………………………………………………………. 14
4.1 Первичная модель ………………………………………………….. ….14
4.2 Нормализация модели………………………………………………….. 15
5. Описание реализации web-сайта …………………………………….… 17
6. Заключение ………………………………………….……………………. 24
7. Список литературы………………………………………………………. 25

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

Библиографические записи применимы к большому числу носителей информации: книги, аудиокниги, карты, статьи в сети интернет; типу документов: монографии, сборники статей, периодические издания. В данной дипломной работе рассматриваются записи только для научных публикаций.Также необходимо создать экспериментальную программную реализацию в виде web-сайта с удобным для пользователя интерфейсом, которая демонстрировала бы работоспособность и практичность данной модели. Программные системы поддержки библиотечного дела.Задача о поиске модели для хранения библиографических записей не нова. С начала 60-х годов, вместе с развитием ЭВМ, идут попытки разработать систему, целью которой является полностью автоматизировать роль библиотекаря. Интерес к этому направлению не угасает до сих пор (за последние 10 лет было выпущено более 8 систем). Более того, государства многих стран активно разрабатывают собственные АБИС. Далее будет идти обзор возможностей таких средств. АБИС. Автоматизированная библиотечная информационная система (АБИС) - централизованная система хранения данных, призванная облегчить библиотечный учет. Функциональные возможности присутствующие почти во всех системах:каталог библиотеки хранится в электронном виде, упрощая поиск по наименованию;интерфейс читателя через среду интернет (OPAC);возможность хранить издания в электронных форматах;проверка доступности книг;учет поступивших/выданных книг;разнообразная статистика, на основе которой, например, можно сделать вывод какие книги необходимо приобрести дополнительно;отслеживание периодических изданий;Зачастую АБИС разрабатывают в виде модульной системы. Поэтому добавление новых функций или изменение старых не доставляет больших проблем.Абсотек Юникод.Абсотек Юникод (Absotheque Unicode) – разработана частной компанией ЗАО «Компания ЛИБЭР». Данная система функционирует на отдельном сервере, предоставляя интерфейс для работы через технологию “thin client” (а точнее веб-браузера). Использование этой технологии позволяет сократить время на настройку и обслуживание системы. Поисковая выдача организована по отложенному механизму: допустим найдено 15 тыс. записей, но сервер не отправляет все данные сразу, а выдает их по частям, по запросу клиента. Благодаря этому существенно уменьшается нагрузка на локальную сеть. Взаимодействие сервера и клиента происходит через протокол HTTP, посредством HTML-страниц.Система построена по модульному принципу. К её основным функциям можно добавить: права доступа к документам, разнообразные алгоритмы шифрования, расширение пользовательского интерфейса читателей, разные виды расширенного поиска, веб-сервис для информирования читателей о новых поступлениях, задолженностях и др.Записи хранятся в реляционной базе данных MS SQL Server, используя второй способ из вышеприведенного списка.Недостатки: неопределенность в переводе интерфейса (изначально разработка велась французской компанией), неполная поддержка RUSMARK, не все необходимые возможности есть в базовом дистрибутиве, неудобство печати электронной карточки.Достоинства: использование технологии thin client, большое число возможностей предоставляемые как читателям, так и библиотекарям, наличие в БД представлений, хранимых процедур и функций, частичная открытость кода, использование гибкой модели для хранения записей.Рис. 1. Интерфейс библиотекаря в Абсотек Юникод.МАРК-SQL.МАРК-SQL – разработана отечественной НПО «Информ-система». На сайте системы указано, что было выпущено 2 версии: на основе MARC21 и RUSMARC.Система МАРК-SQL имеет очень много внедрений. Она также получила свидетельство национальной службы развития системы форматов RUSMARC о соответствии стандарту. Однако неструктурированное хранение данных в MARC – формате будет причинять неудобство при расширении системы.На рисунке представлена форма ввода сведений об издании, являющемся монографией.Рис. 2. Форма ввода сведений об изданииФорма содержит довольно много полей и подполей. Реально заполняются далеко не все, и пользователь может потратить много времени на выбор тех из них, которые нуждаются в заполнении. В системе предусмотрена возможность создания шаблонов, в которых задается список полей и подполей для заполнения, но чтобы создавать шаблоны, администратор системы должен быть хорошо знаком с MARC-форматом. Возможно, это не является большим неудобством, но разработчики должны были озаботиться более удобным интерфейсом.Достоинства: многоплатформенность, совместимость с большим числом СУБД. Недостатки: изменение и добавление изданий в систему требует знания MARC.Системы управления библиографической информацией.Данный тип систем разрабатывался сугубо для научных сотрудников. Все дело в различии требований к статьям у разных научных изданий, а именно к оформлению библиографических ссылок. Переформатирование ссылок для каждого научного издания вручную занимает время, к тому же человек может допустить ошибку, из-за чего статья не будет принята к публикации, а это опять же потеря времени. Для автоматизации этого процесса было создано семейство программ (преимущественно для окружения LaTeX), которые на основании файла описания стиля (или иных требований) могут строить библиографические ссылки и сразу заносить их в научную публикацию. Заключение. При анализе систем выяснилось, что, во-первых, подавляющее большинство систем используют реляционные СУБД, а во-вторых, в них реализован один из трех вариантов хранения библиографического описания:1) хранение всего библиографического описания в одном поле типа textили image в одном из MARC-форматов;2) распределение библиографического описания по двум таблицам: в первой, основной таблице для каждого библиографического описания заводится строка, часть атрибутов библиографического описания, не являющихся множественными, хранится в отдельных столбцах этой строки; во второй, дополнительной таблице, связанной с первой, каждому оставшемуся атрибуту, имеющему непустое значение, соответствует отдельная строка;3) хранение всего библиографического описания в одном поле в виде библиографической карточки.Первый вариант хранения имеет два существенных недостатка:1) Форма содержит довольно много полей и подполей. Реально заполняются далеко не все, и пользователь может потратить много времени на выбор тех из них, которые нуждаются в заполнении.2) необходимость дублирования информации в специально создаваемых таблицах для тех атрибутов, по которым происходит поиск, что может привести к рассогласованию данных и ошибкам при поиске.Построение модели.С учетом недостатков моделей, о которых шла речь в прошлом разделе, было решено создать принципиально новую. Хотя реляционные СУБД обладают недостатками, на сегодняшний день они развиты лучше чем остальные направления. Объектно-ориентированные СУБД медленно развиваются, а с сетевыми ситуация еще хуже. Поэтому за основу был взята реляционная СУБД.Первичная модель.Если каждому полю из описания стандарта сопоставить поле из таблицы, получим базу данных, которая состоит из одной таблицы, представленной на рисунке 3. Рис. 3. Структура таблицы Publication.Недостатки подхода «в лоб» очевидны. Если у книги несколько авторов, придется дублировать строки, чтобы указать всех авторов. Причем это относится и к Publishers (сведения об издательстве), и к Contributors (сведения о лицах принимавших участие в создании документа), поскольку стандарт разрешает упоминание нескольких лиц в этих полях. Эти дубли будут мешать при поиске записи и уменьшат скорость выполнения запросов. Кроме того, теряется порядок упоминания авторов, что абсолютно недопустимо. Исходя из этого, принято решение модифицировать модель так, чтобы максимально устранить эти недостатки. В результате чего приходим к процессу нормализации БД.Нормализация модели.Понятно, что процесс нормализации следует проводить делая упор на поля Authors, Publishers, Contributors. Рассмотрим на примере поля Authors, поскольку для остальных полей рассуждения аналогичны. Для того, чтобы с библиографической записью мог ассоциироваться более чем один автор, следует создать таблицу, в которой будут храниться все авторы, имеющих упоминание во всех библиографических записях. Чтобы зафиксировать факт отношения автора к записи, вводится еще одна таблица, имеющая полями ключ из таблицы авторов и ключ из самой записи: Рис. 4. Результат преобразования.Использовав этот прием на остальных «проблемных» полях и проведя нормализацию, получим модель, в которой имеется одна опорная таблица, а все остальные таблицы связаны с ней прямо или косвенно.Полученная модель лишена недостатков прошлой. Однако это компенсируется сложностью запросов. Чтобы добавить или удалить запись, необходимо провести разбор записи на составные компоненты и лишь затем провести нужную операцию с каждой из таблиц. Это нельзя назвать серьезным недостатком, т.к. ввод записей в базу данных будет осуществляться через специальный интерфейс. Однако при поиске записей, например по автору, сначала придется найти идентификатор (первичных ключ) соответствующий автору из таблицы Authors, затем найти все отношения, в которых находится автор из таблицы Publication_Authors.Рис. 5. Конечный результат преобразований.Описание реализации web-сайта.Для разработки хранилища была выбрана CMS Drupal, система управления содержимым, написанная на языке PHP и использующая в качестве хранилища данных реляционную базу данных MySQL. Для реализации поставленных целей были написаны методы на языке программирования PHP.