Разработка информационной системы библиотечного фонда города при помощи SQL Developer

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Введение

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

Система библиотечного фонда города, дает нам необходимые сведения о читателях, о книгах и другой литературе, которая есть у читателей и самого фонда и не только это, эта система контролирует все ,что происходит с хранящийся в ней информацией.

При выполнении курсовой работы была использована среда SQL Developer. Для проектирования и проверки модели использовались средства Erwin Data Modeler и Erwin Model Validator.

1. Создание логической модели базы данных

Первый этап работы это создание логической модели Информационной системы библиотечного фонда города (Рисунок 1).

Логическое проектирование --Это развитие концептуального представления БД с учетом какой-либо модели в нашем случае с реляционной. Для реляционной модели данных логическая модель -- набор схем отношений, в которых указываются первичные ключи и связи между отношениями, которые представляют внешние ключи.

Построение модели данных предполагает определение сущностей и атрибутов, то есть необходимо определить какая информация будет храниться в конкретной сущности или атрибуте. Сущность можно определить как объект, событие или концепцию, информация о которых должна сохраняться. Сущности должны иметь наименование с четким смысловым значением, именоваться существительным в единственном числе, не носить "технических" наименований и быть достаточно важными для того, чтобы их моделировать.

Сущность - абстракция реально существующего объекта, явления, предмета.

Атрибут -это характеристика сущности, которая имеет имя и отображает свойства сущности.

Связь - средство представления отношений между сущностями.

Различают три уровня логической модели, отличающиеся глубиной представления информации о данных:

* диаграмма сущность-связь

* модель данных, основанная на ключах

* полная атрибутивная модель

Диаграмма сущность-связь Это данных верхнего уровня. В ней находятся различные сущности и взаимосвязи, отражающие основные бизнес-правила предметной области. В такой диаграмме отражено мало деталей, в нее включаются основные сущности и связи между ними, которые удовлетворяют основным требованиям. Диаграмма сущность-связь может включать связи многие-ко-многим и не включать описание ключей.

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

Полная атрибутивная модель - наиболее детальное представление структуры данных: представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи.

В ERwin может быть создана схема данных, наглядно отображающая логическую структуру БД. А также параллельно может создавать физическую модель данных.

Рисунок 1 - Логическая модель базы данных

1.1 Сущности

В системе библиотечного фонда можно выделить следующие сущности:

Студент - включает в себя информацию о студенте.

Научный Работник - включает в себя информацию о научных работниках.

Преподаватель - включает в себя информацию о преподавателе

Школьник - включает информацию о школьниках.

Пенсионер - включает информацию о пенсионерах.

Рабочий - включает информацию о рабочих.

Билет - сущность, в которой мы даем каждой категории регистрировшихся свой номер билета.

Библ_Фонд - сущность, где описывается название и адрес библиотеки.

Автор - сущность, где записываем ФИО автора.

Ограничения - сущность, где накладывается ограничение на определенный тип книг, определенного издания.

Хран_Библ - сущность, в которой отображается место положение определенного типа книги и его название.

Выдача - сущность, где ведется учет о том на какой срок выдана литература и кто вел учет.

Сотрудник - Информация о сотруднике

Тип - В таблице тип отображаются все типы возможной литературы и их номера для удобного поиска места того или иного типа.

1.2 Связи

Все связи между сущностями в БД являются связями один-ко-многим , многие ко многим и один к одному.

Связи между сущностями Студент, научный_Рабочий, преподаватель, школьник, пенсионер, рабочий, билет являются идентифицирующими, так как вторичный ключ попадает в атрибуты первичного ключа другой сущности.

Связи между сущностями ограничения, выдача, есть идентифицирующие и неидентифицирующие, так вторичный ключ является одновременно и первичным ключом.

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

2. Создание физической модели

Физическое проектирование -- создание схемы базы данных с учётом выбранной целевой СУБД.

В физической модели содержится информация о всех объектах БД. Так как нет определенных стандартов на объекты БД (например, нет стандарта на типы данных), эта модель зависит от конкретной реализации СУБД. Это говорит о том, что несколько физических моделей могут соответствовать одной логической модели. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, значит в физической модели будет важным описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, и т. д.

Рисунок 2 - Физическая модель базы данных

3. Нормализация

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

Таблица находится в 1НФ тогда и только тогда, когда ни одна из ее строк не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто.

2НФ: Отношение находится в 1НФ и все ее поля не входящие в первичный ключ, связаны функциональной зависимостью с первичным ключом.

3НФ: Отношение находится в 2НФ и все неключевые атрибуты взаимно независимы.

4. Проверка разработанной модели средствами Validator

AllFusion Data Model Validator - Программа, которая проверяет разработанную модель данных. (рисунок 5).

Рисунок 5 - Проверка модели

программный логический документированный

Программа обнаружила 1 ошибку в созданной модели.

Причина: С одной таблицей связано 6 таблиц, что приведет к задержке при обновлении данных.

Решение: Создать вид связи супер тип подтип.

5. Прямое проектирование

Проводим проектирование БД в Oracle. Прямое проектирование (Forward Engineering) - процесс генерации физической схемы БД из логической модели данных.

Рисунок 6 - Конец прямого проектирования

Введем данные в таблицы БД. Рисунки 7 - 20

Рисунок 7 - Автор

Рисунок 8 - Библ_Фонд

Рисунок 9 - Билет

Рисунок 10 - Выдача

Рисунок 11 - Научный_Раб

Рисунок 12 -Ограничения

Рисунок 13 - Пенсионер

Рисунок 14 - Преподаватель

Рисунок 15 - Рабочий

Рисунок 16 -Сотрудник

Рисунок 17 - Студент

Рисунок 18 - Тип

Рисунок 19 - Хранилище Библиотеки

Рисунок 20 - Школьник

6 Обратное проектирование

Процесс генерации логической модели из физической БД называется обратным проектированием (Reverse Engineering).

Рисунок 21 - Результат обратного проектирования

7 SQL Запросы

С помощью средств запросов SQL построим 5 запросов.

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

Рисунок 22

Список читателей, на руках у которых находиться указанное издание.

Рисунок 23

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

Рисунок 24

Список литературы, которая в настоящий момент выдана с определенной полки некоторой библиотеки

Рисунок 25

Данные о выработке библиотекарей (число обслуженных читателей в указанный период времени).

Рисунок 26

Заключение

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

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

Размещено на Allbest.ru