Курсовая работа по проектированию баз данных на тему Проектирование и разработка базы данных электронного каталога библиотеки

Введение

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


Глава 1. Анализ предметной области и концептуальное проектирование

1.1 Детальное описание предметной области «Библиотечный электронный каталог»

Предметная область охватывает все процессы, связанные с хранением, поиском, учётом и выдачей книг в библиотеке. Как отмечается в специализированной литературе по автоматизации библиотечных процессов, традиционные карточные каталоги обладают серьёзными недостатками: низкая скорость поиска, невозможность одновременного доступа нескольких пользователей, трудоёмкость обновления [1]. Переход к электронным каталогам, базирующимся на реляционных базах данных, позволяет не только ускорить поиск в сотни раз, но и реализовать сложные аналитические запросы, прогнозирование пополнения фонда и интеграцию с внешними системами [2]. Ключевыми участниками (акторами) являются: библиотекарь (осуществляет регистрацию читателей, выдачу и приём книг, формирование отчётов), читатель (ищет книги, получает их на руки, возвращает), администратор библиотеки (управляет фондом, добавляет новые поступления, списывает утерянные экземпляры, настраивает правила работы), а также внешние системы (например, электронный каталог других библиотек для межбиблиотечного абонемента).
Основные бизнес-процессы включают: регистрацию новой книги (ввод метаданных: название, ISBN, год издания, количество страниц, жанр, издательство, авторы, аннотация, язык, ключевые слова), добавление экземпляров (физических копий) с уникальными инвентарными номерами, регистрацию читателя (выдача читательского билета с уникальным номером, сбор контактных данных, определение категории), выдачу книги читателю (проверка наличия свободного экземпляра, проверка отсутствия задолженностей у читателя, фиксация даты выдачи и плановой даты возврата, обычно через 30 дней, обновление статуса экземпляра), возврат книги (проверка состояния, расчёт штрафа при просрочке, обновление статуса экземпляра, запись фактической даты возврата), поиск книг по различным критериям (автор, название, жанр, диапазон годов, ключевые слова, ISBN, издательство), формирование отчётов (задолжники, популярные книги, статистика по жанрам, активность читателей, оборот фонда), управление задолженностями (начисление штрафов, их оплата, блокировка читателей при превышении лимита задолженности), а также бронирование книг (читатель может зарезервировать книгу, которая в данный момент выдана другому читателю).
Дополнительные процессы могут включать межбиблиотечный абонемент, учёт электронных изданий (PDF, EPUB), интеграцию с RFID-метками для автоматической идентификации экземпляров, экспорт каталога в форматы MARC21 или RUSMARC для обмена с другими библиотеками [10]. В рамках данной курсовой работы мы сосредоточимся на ядре системы: книга, автор, издательство, экземпляр, читатель, выдача. Связи между сущностями требуют тщательного анализа.
Книга и автор находятся в отношении «многие ко многим»: одна книга может быть написана несколькими авторами (сборник статей, коллективная монография, учебник под редакцией), и один автор может написать множество книг. Для реализации этой связи в реляционной модели необходима вспомогательная (ассоциативная) таблица Book_Authors [6]. Книга и издательство связаны как «многие к одному»: каждое издательство выпускает много книг, но каждая книга выходит в одном основном издательстве (если не рассматривать переиздания как разные записи – для простоты считаем, что каждое издание уникально, то есть разные издания одной и той же книги (например, «Евгений Онегин» 1980 и 2000 годов) считаются разными записями в таблице Books).
Одна книга может иметь много физических экземпляров (копий), каждый из которых характеризуется своим статусом (в наличии, выдана, списана, на реставрации) и инвентарным номером. Один читатель может одновременно держать несколько книг (обычно ограничение 5–10 единиц в зависимости от категории читателя), и каждая выдача относится к одному читателю и одному экземпляру. История выдач сохраняется: даже после возврата записи не удаляются, что позволяет анализировать читательский спрос, вычислять среднюю длительность чтения, выявлять наиболее активных читателей [4].
Важным атрибутом выдачи является расчёт штрафа. Штраф может начисляться как фиксированная сумма за каждый день просрочки (например, 1 рубль в день) или как фиксированный платеж при превышении порога (например, 100 рублей при просрочке более 30 дней). В нашей модели штраф вычисляется либо при запросе (как виртуальное поле) с помощью функции, либо сохраняется в момент возврата как материализованное значение. Мы выберем подход хранения вычисленного штрафа в момент возврата, чтобы избежать пересчёта при каждом просмотре истории, но для запросов текущей задолженности штраф может быть вычислен динамически с использованием функции CURRENT_DATE.
Дополнительные атрибуты, важные для предметной области: для книги – аннотация (текст до 2000 символов), ключевые слова (строка, но лучше отдельная таблица Keywords для нормализации), язык издания (справочник), количество страниц, обложка (ссылка на файл или BLOB), формат (печатная, электронная, аудиокнига). Для читателя – адрес, электронная почта, дата рождения, категория (школьник, студент, преподаватель, пенсионер), дата последней активности, флаг блокировки. Для издательства – сайт, год основания, страна.
В целях демонстрации принципов проектирования мы включим основные атрибуты, оставив расширение для будущих версий. Нормализация данных – ключевой этап. Исходная ненормализованная таблица содержала бы повторяющиеся группы (например, несколько авторов в одном поле через запятую, несколько жанров в одном поле), что приводит к аномалиям обновления (при изменении имени автора пришлось бы обновлять все книги этого автора), вставки (нельзя добавить автора без книги) и удаления (при удалении последней книги автора теряется информация об авторе) [1, с. 78].
Поэтому мы стремимся к третьей нормальной форме (3NF), где каждый неключевой атрибут функционально полно зависит от первичного ключа и отсутствуют транзитивные зависимости [2, с. 156]. Например, издательство не зависит от названия книги, поэтому вынесено в отдельную таблицу. Год издания зависит от книги, а не от издательства, что тоже устраняет транзитивную зависимость.

1.2 Выбор модели данных и обоснование реляционной модели

Для реализации электронного каталога наиболее подходит реляционная модель данных, предложенная Эдгаром Коддом в 1970 году и до сих пор доминирующая в корпоративных системах [1]. Основные аргументы в пользу реляционной модели: поддержка сложных запросов с соединениями (INNER JOIN, LEFT JOIN, RIGHT JOIN, FULL OUTER JOIN, CROSS JOIN) между несколькими таблицами; строгая типизация данных и контроль целостности с помощью первичных и внешних ключей, а также ограничений CHECK, UNIQUE, NOT NULL; мощный язык SQL, ставший промышленным стандартом и поддерживаемый всеми современными СУБД с незначительными диалектами; возможность транзакционной обработки с соблюдением свойств ACID (атомарность, согласованность, изоляция, долговечность), что критически важно для операций выдачи и возврата, где одновременные изменения могут привести к выдаче одной книги двум читателям; зрелые технологии оптимизации запросов (индексы, статистика, планировщики, материализованные представления) [5].