В библиотеке ведется картотека читателей. Каждый читатель характеризуется следующими параметрами: ФИО и т. д. Ограничения, связанные с читателем: каждый читатель должен держать не более 5 книг; каждый читатель должен держать не более одного экземпляра каждой книги.
Характеристики экземпляра: инвентарный номер (уникальный для экземпляра в пределах библиотеки); шифр книги, место размещения в библиотеке.
В случае выдачи книги имеется объект вкладыш, содержащий сведения: дата выдачи, дата возврата, ФИО взявшего и т.д.
Ограничения на информацию в целом по системе: фамилии автора могут отсутствовать; в библиотеке должны быть записаны читатели не моложе 17 лет; в библиотеке присутствуют книги, начиная с определенного года; каждый читатель обязательно должен иметь номер телефона.
Между областями знаний и книгами связь "многие-ко-многим ".
Описание групп пользователей: администрация, библиотекари, читатели.
Библиотекарь должен решать следующие задачи:
1. Принятие книг и регистрация.
2. Определение области знаний, к которой относится книга.
3. Назначение новых инвентарных номеров книгам.
4. Списание старых книг (списывать можно только те книги, все экземпляры которых находятся в библиотеке).
5. Ведение учета выдачи книг.
6. Проведение списания утерянных книг.
7. Проведение закрытия абонемента читателя.
Читатель имеет право:
1. Просматривать системный каталог.
2. По выбранной области брать список книг.
3. По книге получать номер и местонахождение свободного экземпляра. В случае, если экземпляр не свободен, узнать дату возврата книги.
4. Для выбранного автора получать список книг.
Администрация библиотеки имеет право:
1. Получать список должников.
2. Получать информацию о книгах, которые давно не выдавались.
3. Получать информацию о наиболее популярных книгах.
Перед началом разработки необходимо иметь точное представление о том, что должно выполняться в системе, какие пользователи в ней будут работать и какие задачи будут решаться.
Итак, на первом этапе проектирования базы данных необходимо: рассмотреть все объекты и связи между ними; выявить все ограничения на систему, касающиеся предметной области, и явно их записать; выяснить все группы пользователей, цели и задачи, стоящие перед пользователями, а также входные и выходные документы, необходимые для работы.
Даталогическое проектирование
В реляционной базе данных даталогическое проектирование заканчивается разработкой схемы базы данных, т. е. совокупности отношений и связей между ними. При построении схемы постоянно анализируется корректность этой модели на наличие (отсутствие) связей между атрибутами.
В результате выполнения даталогического проектирования получается описание концептуальной схемы базы данных в терминах выбранной СУБД (атрибуты, типы, ключевые атрибуты), описание внешней модели в терминах СУБД, описание правил поддержки целостности базы данных, разработка процедур поддержки целостности базы данных. Построенная схема должна быть корректной, т. е. должны отсутствовать нежелательные связи между атрибутами.
Существует два пути построения корректной схемы:
1. Путь разбиения. Исходное множество отношений заменяется другим множеством отношений. В общем случае эти отношения являются проекциями исходных отношений.
2. Путь синтеза. Заключается в компоновке из заданных элементарных зависимостей единой схемы базы данных.
Первый путь основан на теории нормализации. Процесс нормализации - это последовательный переход от одной нормальной формы к другой, при котором каждая последующая итерация соответствует форме более высокого уровня. Каждой нормальной форме соответствует набор ограничений. Обычно выделяется следующая последовательность нормальных форм:
1НФ -> 2НФ -> 3НФ -> НФ Бойса-Кодда (НФБК) -> 4НФ -> 5НФ
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.