База данных "Читальный зал"

Введение.

 

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

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

Таким образом можно сказать, что БД обеспечивает хранение данных, а СУБД – получение информации.

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

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

В данной работе представлена база данных «Читальный зал». В этой работе я попыталась автоматизировать систему работы читального зала.

 

 

Глава первая. «Постановки задачи»

1.1.Постановка цели

Необходимо создать базу данных «Читальный зал». База данных должна обеспечивать занесение новых данных, поиск, удаление записей. Библиотека заинтересована в автоматизации учета читателей, экземпляров, выдачи экземпляров читателям и сдачи экземпляров читателями, а так же заказов на издания. База данных должна обеспечивать учет экземпляров и читателей. Должно поддерживаться автоматическое формирование отчетов о читателях, имеющих задолженности и об экземплярах, которые не были возвращены в срок. Предложенный в настоящей курсовой работе проект направлен на достижение указанных целей.

 1.2.Назначение базы данных «Читальный зал»

 База данных «Читальный  зал» предназначена для автоматизации  процесса учета и контроля  обращения фондов читального  зала.

1.3.Функции базы данных «Читальный зал»

• Занесение новых книг в архив библиотеки
• Занесение новых читателей
• Поиск книги
• Поиск читателей
• Регистрация заказов

1.4. Категория пользователей.

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

 

1.5. Обоснование выбора СУБД.

Для реализации поставленной в данной работе задачи оптимальной является база Microsoft Access из пакета Microsoft Office

MS Access хранит данные в одном файле, но доступ к ним организован так, чтобы не использовать лишние ресурсы памяти. Отметим, что некоторые другие СУБД хранят информацию в разных файлах, но работе с ними это никак не мешает.

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

В MS Access возможно создание связи между таблицами, что позволяет совместно использовать данные из разных таблиц. Это экономит память, увеличивает скорость обработки данных, позволяет избежать ненужного дублирования и лишних ошибок.

СУБД MS Access  обычно применяется в тех случаях, когда прикладная задача требует хранения и обработки разнородной информации о большом количестве объектов и предполагает возможность многопользовательского режима работы. Тем не менее даже для хранения не очень большого объема данных в некоторых случаях лучше использовать пакет MA Access  просто потому, что в нем заранее предусмотрена защита не только от несанкционированного доступа, но и от не вполне корректного обращения, то есть выше сохранность данных.

- Операционная система  не ниже Windows 98;

- Процессор с частотой  обновления не менее 2 Гц;

- 512 Мб физической памяти;

- Не менее 300 Мб доступного  пространства на локальном диске.

 

 

 

 

 

 

 

 

Глава вторая «Проектирование базы данных «Читальный зал»

2.1. Понятие концептуальное (инфологическое) проектирование баз данных

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

Концептуальное  проектирование - сбор, анализ и редактирование требований к данным. На этой стадии проектирования создается семантическая модель предметной области. Для этого осуществляются следующие мероприятия:

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

По окончании данного  этапа получаем концептуальную модель, инвариантную к структуре базы данных. Она не ориентирована на какую либо СУБД.

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

Далеко не всегда очевидно то, чем является определенный объект – сущностью, связью или атрибутом. Разработчики БД должны ограничивать предметную область рамками того взгляда на мир и существующие в нем категории, который  задается  контекстом предприятия и создаваемого для него приложения.

Прежде, чем приступать к  созданию системы автоматизированной обработки информации, разработчик  должен сформировать понятия о предметах, фактах и событиях, которыми будет  оперировать данная система. Для  того, чтобы привести эти понятия  к той или иной модели данных, необходимо заменить их информационными  представлениями. Одним из наиболее удобных инструментов унифицированного представления данных, независимого от реализующего его программного обеспечения, является модель "сущность-связь" (entity - relationship model, ER - model).

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

Любой фрагмент предметной области может быть представлен  как множество сущностей, между  которыми существует некоторое множество  связей. Дадим определения:

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

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

Набор сущностей (entity set) - множество сущностей одного типа (обладающих одинаковыми свойствами). Примеры: все люди, предприятия, праздники и т.д. Наборы сущностей не обязательно должны быть непересекающимися. Например, сущность, принадлежащая к набору МУЖЧИНЫ, также принадлежит набору ЛЮДИ.

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

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

• Один- к – одному (1:1) Это означает, что в такой связи сущности с одной ролью всегда соответствует не более одной сущности с другой ролью.
• Один – ко – многим (1:n ) В данном случае сущности с одной ролью может соответствовать любое число сущностей с другой ролью.
• Много – к одному (n:1) В этом случае каждая из ассоциированных сущностей может быть представлена любым количеством экземпляров.

Принимая во внимание все  выше сказанное, делаем вывод что в данном проекте объектами являются: книги, читатели и заказ.

 

 

 

 

 

 

 

 

 

 

Читают

Книги

Посетители

 

Делают

Перемещают

ся

 

 

 

Заказ

 

Администратор

Рис. 1. ER – модель системы «Читальный зал»

2.2 . Даталогическое проектирование

На этапе даталогического проектирования строится логическая структура БД. При этом происходит преобразование исходной инфологической модели в модель данных, которая поддерживается конкретной СУБД. После этого производится проверка адекватности даталогической модели, отображаемой предметной области. Конечным результатом даталогического проектирования является описание структуры БД на языке описания данных конкретных СУБД.

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

В информационном аспекте  разрабатываются даталогические модели базы данных (прямое проектирование Forward Engineering), а также уточняются модели инфологического уровня (обратное проектирование Revers Engineering), разрабатываются схемы данных всех уровней, конструируются в терминах языка конкретной СУБД (часто это SQL) запросы к базе данных. Здесь могут быть полезны CASE-средства проектирования баз данных, такие как ERwin.

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

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

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

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

Рассмотрим основные особенности реляционной модели базы данных.

Одним из самых естественных способов представления данных является двухмерная таблица. Связи между  данными также могут быть представлены в виде двухмерных таблиц.