База данных библиотеки ВУЗа

Курсовая работа

Разработка базы данных библиотеки ВУЗа

автоматизация информационный бизнес процесс библиотека

Содержание

1. Анализ предметной области

1.1 Этапы разработки БД

1.2 Описание объекта автоматизации

1.3 Формализация безнес — процессов

1.4 Разработка концеатуальной модели БД

2. Проектирование логической модели БД

2.1 Обоснование логической модели БД

2.2 Разработка логической модели БД

2.3 Разработка запросов к БД

3. Реализация БД

3.1 Выбор СУБД

3.2 Разработка физической модели БД

3.3 Разработка приложения к БД Заключение Список использованных источников Приложение

В процессе общения с другими людьми мы передаем и получаем информацию.

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

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

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

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

Актуальность. В своей работе я решила затронуть актуальную на сегодняшний день тему автоматизации, и рассмотреть ее на конкретном примере — проектирование базы данных библиотеки ВУЗа.

Предмет исследования — повышения автоматизации библиотеки ВУЗа.

Объект исследования — база данных, разработанная с помощью программных средств (ERWin).

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

Библиотечный каталог хранит информацию о книгах, каждая из которых имеет название, автора, год издания. Информация в базах данных хранится в упорядоченном виде, в библиотечном каталоге — либо по алфавиту (алфавитный каталог), либо по области знания (предметный каталог).

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

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

Таким образом, передо мной стоят следующие задачи:

1. Анализ предметной области и построение концептуальной модели данных. На основе информации, полученной при анализе, необходимо создать подробное описание предметной области, обращая особое внимание на требование к данным. (Изучить структуру библиотеки ВУЗа. Рассмотреть принципы учета списания, выдачи, возврата, хранения литературы).

2. Логическое проектирование. Построить логическую модель базы данных — обобщенное, не привязанное к каким — либо компьютерам и СУБД, описание предметной области: набор данных, их типов, длин, связей и т. п. (Создать на основе изученной структуры информационную модель будущей базы данных, в частности конкретные сущности, их атрибуты, типы данных).

3. Физическое проектирование. Выбрать СУБД, под управлением которой должна функционировать база данных, и создать даталогическую (табличную) модель базы данных — логическую модель, переведенную на язык выбранной СУБД (Разработать с помощью программных средств (ERWin) базу, позволяющую упростить и усовершенствовать работу специалистов).

4. Разработка приложения.

Структура курсовой работы.

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

1. Анализ предметной области

1.1 Этапы разработки БД

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

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

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

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

В ходе анализа предметной области необходимо:

· уяснить и указать назначение базы данных;

· определить и выделить первоначальный набор сущностей и атрибутов предметной области.

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

При проектировании базы данных решаются две основные проблемы:

1. Отображение объектов предметной области в абстрактные объекты модели данных таким образом, чтобы это отображение не противоречило семантике предметной области, и было по возможности лучшим (эффективным, удобным и т. д.). Часто эту проблему называют проблемой логического проектирования баз данных;

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

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

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

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

1.2 Описание объекта автоматизации

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

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

Библиотечный каталог хранит информацию о книгах, каждая из которых имеет название, автора, год издания. Информация в базах данных хранится в упорядоченном виде, в библиотечном каталоге — либо по алфавиту (алфавитный каталог), либо по области знания (предметный каталог).

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

Опишем информационную систему для автоматизации учета получения и выдачи книг в библиотеке.

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

Каждая книга, хранящаяся в библиотеке, характеризуется следующими параметрами:

· уникальный шифр;

· название;

· фамилии авторов (могут отсутствовать);

· издательство;

· год издания;

· количество страниц;

· стоимость книги.

Книги могут иметь одинаковые названия, но они различаются по своему уникальному шифру — (ISBN).

В библиотеке ведется картотека читателей. Каждому читателю присваивается уникальный номер читательского билета.

Каждая книга в библиотеке может присутствовать в нескольких экземплярах. Каждый экземпляр имеет следующие характеристики:

· уникальный инвентарный номер;

· место размещения в библиотеке.

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

· номер билета читателя, который взял книгу;

· дата выдачи книги;

· дата возврата.

При работе с системой библиотекарь должен иметь возможность решать следующие задачи:

· принимать новые книги и регистрировать их в библиотеке.

· относить книги к одной или нескольким областям знаний.

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

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

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

Вести учет выданных книг читателям, при этом предполагается два режима работы:

· выдача книг читателю;

· прием от него возвращаемых им книг обратно в библиотеку.

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

При приеме книги, возвращаемой читателем, проверяется соответствие возвращаемого инвентарного номера книги выданному инвентарному номеру, и она ставится на свое место на полку библиотеки.

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

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

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

· устранение рутинных ручных операций, неизбежных при обработке информации;

· существенное ускорение процессов обработки и преобразование данных;

· повышение точности учетных и отчетных данных;

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

· высвобождение времени работников для решения творческих задач.

1.3. Формализация бизнес — процессов

Для построения функциональной модели данной предметной области была использована методология SADT, которая отражает функциональную структуру объекта, т. е. производимые им действия и связи между этими действиями. Графика блоков и дуг диаграммы отражает функцию в виде блока, а интерфейсы входа/выхода представляются дугами. Взаимодействие блоков друг с другом выражается по средствам интерфейсных дуг, описывающих, когда и над чем какая функция выполняется и как управляется. На рисунке 1 изображен блок А0 представляющий собой всю систему в целом, именем блока служит название всей системы. Обработке по данной схеме подвергается информация о книгах и читателях базы данных, а результатом работы всей системы служит выдача отчетов о результатах ее деятельности. Управление на систему оказывает библиотекарь, который заносит поступающею информацию в базу данных и руководит ею посредствам автоматизированной системы.

Рис. 1. SADT диаграмма — Блок A0. 1

Следующим шагом построения SADT диаграммы служит более детальное рассмотрение системы путем декомпозиции всей системы на более мелкие подзадачи. На рисунке 2 схематично в качестве блоков показаны основные процессы системы:

Блок А1 — Регистрация читателя. В этом блоке заносится информация в базу данных о новых читателях. Входящей информацией служат индивидуальные данные читателя, вносимые библиотекарем, в процессе регистрации читателю присваивается уникальный номер. Результатом работы этого процесса является добавление новой записи в таблицу зарегистрированных читателей. Блок А2 — Регистрация книг. Предназначен для ввода поступивших книг в библиотеку, при регистрации книг так же присваивается уникальный номер. После выполнения процесса, зарегистрированные книги готовы к выдаче читателям. Блок А3 — Выдача книг. При выполнении этого процесса библиотекарем заносится запись о выдачи книги читателю, в которой указывается, кто и какую книгу взял, и отмечается дата занесения записи. Блок А4 — Возвращение книг. В этом процессе читатель возвращает книгу обратно в библиотеку, при выполнении этого запроса удаляется запись о взятии книги у вернувшего читателя, а книга возвратимая им снова готова к выдачи следующему читателю.

Рис. 2. Схема подзадачи системы.

1.4 Разработка концептуальной модели базы данных

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

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

Цель концептуального проектирования — создание концептуальной модели данных на основе представлений о предметной области каждого отдельного типа пользователей. Концептуальная модель представляет собой описание основных сущностей (таблиц) и связей между ними без учета принятой модели БД и синтаксиса целевой СУБД.

Ниже рассматривается последовательность шагов при концептуальном проектировании:

1. Выделение сущностей.

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

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

Каждая сущность должна обладать некоторыми свойствами:

· должна иметь уникальное имя, и к одному и тому же имени должна всегда применяться одна и та же интерпретация;

· обладать одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь;

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

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

В графической нотации IDEF1X для отображения сущности используются обозначения, изображенные на рис. 3

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

2. Определение атрибутов.

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

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

Выявленные атрибуты могут быть следующих видов:

· простой (атомарный, неделимый) — состоит из одного компонента с независимым существованием;

· составной — состоит из нескольких компонентов (например, «ФИО», «адрес», и т. д.). Степень атомарности атрибутов, закладываемая в модель, определяется разработчиком. Если от системы не требуется выборки всех клиентов с фамилией Иванов или проживающих на улице Комсомольской, то составные атрибуты можно не разбивать на атомарные;

· однозначный — содержит только одно значение для одного экземпляра сущности (например, у кривой в плане может быть только одно значение радиуса, угла поворота, возвышения наружного рельса и т. д.);

· многозначный — содержит несколько значений;

· производный (вычисляемый) — значение атрибута может быть определено по значениям других атрибутов (например, «возраст» может быть определен по «дате рождения» и текущей дате, установленной на компьютере);

· ключевой — служит для уникальной идентификации экземпляра сущности (входит в состав первичного ключа);

· не ключевой (описательный) — не входит в первичный ключ;

· обязательный — при вводе нового экземпляра в сущность или редактировании обязательно указывается допустимое значение атрибута, т. е. оно после редактирования не может быть неопределенным (NOT NULL).

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

· суперключ (superkey) — атрибут или множество атрибутов, которое единственным образом идентифицирует экземпляр сущности. Суперключ может содержать «лишние» атрибуты, которые необязательны для уникальной идентификации экземпляра. При правильном проектировании структуры БД суперключом в каждой сущности (таблице) будет являться полный набор ее атрибутов;

· потенциальный ключ (potential key) — суперключ, который не содержит подмножества, также являющегося суперключом данной сущности, т. е. суперключ, содержащий минимально необходимый набор атрибутов, единственным образом идентифицирующих экземпляр сущности. Сущность может иметь несколько потенциальных ключей. Если ключ состоит из нескольких атрибутов, то он называется составным ключом. Среди всего множества потенциальных ключей для однозначной идентификации экземпляров выбирают один, так называемый первичный ключ, используемый в дальнейшем для установления связей с другими сущностями;

· первичный ключ (primary key) — потенциальный ключ, который выбран для уникальной идентификации экземпляров внутри сущности;

· альтернативные ключи (alternative key) — потенциальные ключи, которые не выбраны в качестве первичного ключа.

Если некий атрибут (набор атрибутов) присутствует в нескольких сущностях, то его наличие обычно отражает наличие связи между экземплярами этих сущностей. В каждой связи одна сущность выступает как родительская, а другая — в роли дочерней. Это означает, что один экземпляр родительской сущности может быть связан с несколькими экземплярами дочерней. Для поддержки этих связей обе сущности должны содержать наборы атрибутов, по которым они связаны. В родительской сущности это первичный ключ. В дочерней сущности для моделирования связи должен присутствовать набор атрибутов, соответствующий первичному ключу родительской. Однако здесь этот набор атрибутов уже является вторичным ключом. Данный набор атрибутов в дочерней сущности принято называть внешним ключом (foreign key).

3. Определение связей.

Связь характеризуется следующим набором параметров:

· именем — указывается в виде глагола и определяет семантику (смысловую подоплеку) связи;

· кратностью (кардинальность, мощность): один-к-одному (1:1), один-ко-многим (1:N) и многие-ко-многим (N:M, N = M или N <> M). Кратность показывает, какое количество экземпляров одной сущности определяется экземпляром другой. Например, на одном участке (описывается строкой таблицы «Участки») может быть один, два и более путей (каждый путь описывается отдельной строкой в таблице «Пути»). В данном случае связь 1:N. Другой пример: один путь проходит через несколько раздельных пунктов и через один раздельный пункт может проходить несколько путей — cвязь N:M;

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

· обязательностью: обязательная (при вводе нового экземпляра в дочернюю сущность заполнение атрибутов внешнего ключа обязательно и для введенных значений должен существовать экземпляр в родительской сущности) и необязательная (заполнение атрибутов внешнего ключа в экземпляре дочерней сущности необязательно или введенным значениям не соответствует экземпляр в родительской сущности);

· степенью участия — количеством сущностей, участвующих в связи. В основном между сущностями существуют бинарные связи, т. е. ассоциации, связывающие две сущности (степень участия равна 2). Например, «Участок» состоит из «Путей». В то же время по степени участия возможны следующие типы связей:

— унарная (рекурсивная) — сущность может быть связана сама с собой. Например, в таблице «Работники» могут быть записи и по подчиненным, и по их начальникам. Тогда возможна связь «начальник» — «подчиненный», определенная на одной таблице;

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

Рис. 4. Концептуальная модель

2. Проектирование Логической модели базы данных

2.1 Обоснование типа логической модели

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

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

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

Иерархическая модель

Модель этого типа жестко сконструирована, то есть взаимосвязь между объектами внутри модели подчинена строгому ранжиру. Подчинение объектов разделено на уровни. На первом уровне представлен один главный объект, которому подчиняются объекты второго уровня. Причем объект первого уровня не может напрямую управлять объектом третьего уровня возможно только через объект второго уровня. Также запрещены взаимосвязи на одном уровне.

Сетевая модель

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

Реляционная модель

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

В основе реляционной модели данных лежат не графические табличные методы и средства представления данных и манипулирование ими. Таблица отражает объект реального мира — сущность. Каждый столбец таблицы имеет уникальное для каждой таблицы имя.

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

После создания различных таблиц, содержащих данные, относящиеся к различным аспектам базы данных, необходимо обеспечить целостность базы данных.

Для данного проекта подходит больше всего реляционная модель построения базы данных.

2.2 Разработка логической модели базы данных

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

На основании предметной области и концептуального проектирования перейдем к разработке логической модели базы данных библиотеки ВУЗа.

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

При проектировании базы данных библиотеки ВУЗа можно выделить следующие сущности:

1.

Литература

.

Для данной сущности выбраны атрибуты, характеризующие свойства определенной книги: ее наименование, количество страниц, BBK, UDK, аннотация, ее вид (учебник, пособие, методичка) и тип (научная, учебная, историческая). ISBN является личным номером для каждого экземпляра. Дополнительная информация содержит сведения о состоянии книги.

2. Автор.

В данной сущности приведены сведения об авторе книге. Так как один автор может написать несколько книг, а разные авторы могли бы написать книги с одинаковыми названиями, то между этими сущностями возможна связь многие ко многим.

3. Издательство.

Представлены данные об издательстве: полное и сокращенное наименование издательства, и город где была книга издана

4. Экземпляры.

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

5. Место хранения.

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

6. Выдача книг.

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

7. Читатель.

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

8. Библиотекарь.

В данной сущности выбраны атрибуты, идентифицирующие каждого работника библиотеки.

Разработка ключей.

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

Значение атрибутов ключа не должно меняться в течение всего времени существования экземпляра сущности. Сотрудник библиотеки или читатель может сменить как фамилию, так и паспорт. Поэтому атрибуты, содержащие ФИО, номер паспорта не подходят на роль первичного ключа. Поэтому принято решение в сущностях ЧИТАТЕЛЬ и БИБЛИОТЕКРАЬ на роль первичных ключей разработать уникальный код, который бы идентифицировал каждого человека уникально.

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

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

При работе ИС часто бывает необходимо обеспечить доступ к нескольким экземплярам сущности, объединенным каким-либо одним признаком. Для повышения производительности в этом случае используются неуникальные индексы. ERwin позволяет на уровне логической модели назначить атрибуты, которые будут участвовать в неуникальных индексах. Атрибуты, участвующие в неуникальных индексах, называются Inversion Entries. Inversion Entry — это атрибут или группа атрибутов, которые не определяют экземпляр сущности уникальным образом, но часто используются для обращения к экземплярам сущности. ERwin генерирует неуникальный индекс для каждого Inversion Entry. Внешние ключи (FK) создаются автоматически, когда связь соединяет сущности: связь образует ссылку на атрибуты первичного ключа в дочерней сущности и эти атрибуты образуют внешний ключ в дочерней сущности (миграция ключа) [1]

Таблица № 1 Первичные, альтернативные, внешние ключи, индексы и атрибуты логической модели.

Связи.

В IDEF1X различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERwin автоматически преобразует дочернюю сущность в зависимую.

Можно выделить три типа связей между таблицами:

· идентифицирующая связь (1:1) — каждой записи одной таблицы соответствует только одна запись другой таблицы;

· неидентифицирующая связь (1:М) — одной записи главной таблицы могут соответствовать несколько записей подчиненной таблицы;

· многие ко многим (М:М) — одна запись главной таблицы связана с несколькими записями подчиненной таблицы, а одна запись подчиненной таблицы связана с не сколькими записями главной таблицы.

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

Между сущностями «Литература» и «Автор» установим связь многие — ко — многим, поскольку есть вероятность наличие литературы с одинаковым названием, написанной разными авторами и возможность присутствия разных книг одного автора. Для учета каждого экземпляра книги библиотеки и определения его места нахождения связываем сущности «Литература» и «Экземпляры» неидентифицирующей связью с разрешением нулевых областей.

Таким образом, каждый экземпляр имеет своё определенное место. Каждая книга имеет издательство. Одному издательству могут принадлежать несколько книг, поэтому связь между сущностью «Издательство» и «Литература» неидентифицирующая. Свяжем сущности «Экземпляры» и «Место хранения» связью, один — ко — многим (1:М). Таким образом, одной записи таблицы «Место хранения» могут соответствовать несколько записей подчиненной таблицы «Экземпляры». Между сущностями «Экземпляры» и «Выдача книг» установим связь один — к — одному (1:1). Следовательно, каждой записи одной таблицы соответствует только одна запись другой таблицы. В виду того, что в библиотеки работает не один сотрудник и соответственно вести учет книг могут разные работники, свяжем сущности «Библиотекарь» и «Выдача книг» связью один — ко — многим.

Рис. 5. Логическая модель

Приведение модели к требуемому уровню нормальной формы

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

Введение

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

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

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

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

В общем случае при проектировании базы данных необходимо соблюдать следующие правила:

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

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

2.3 Разработка запросов к базе данных

Процессор обработки данных Jet является составной частью Access и выполняет инструкции Access SQL (Jet SQL).

СУБД Access позволяет создавать запросы в режиме «Конструктор» или «Режим SQL»

Чтобы войти в режим SQL в Access нужно в поле конструктора запроса нажать левой кнопкой и в появившемся окне нажать «Режим SQL».

В появившемся окне прописываем SQL запрос. К примеру, нам надо показать какие данные находятся в таблице «Литература». Прописываем:

SELECT id_literatura, naimenovanie

FROM T_literatura;

В итоге появится таблица, в которой мы видим «идентификационный номер» книги и её название.

Для удобства поиска автора по его инициалам создаём запрос, где требуется в таблице «Автор» упорядочить фамилии в алфавитном порядке, создаем SQL запрос следующего вида:

SELECT familiya, imya, otchestvo

FROM T_avtor

ORDER BY familiya;

Создадим запрос на поиск книги по фамилии автора:

SELECT familiya, imya, otchestvo,

[nimenovanie], [izdatel]

FROM T_avtor, T_literatura, T_izdatelstvo;

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

SELECT id_inv_nomer, naimenovanie,

familiya, imya, otchestvo, data_vid, data_vozvrata

FROM T_ekzemplyary_T_chitat, T_literatura, T_chitatel;

3. Реализация БД

3.1 Выбор СУБД

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

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

По характеру использования СУБД делят на многопользовательские и персональные.

Многопользовательские СУБД позволяют создавать информационные системы, функционирующие в архитектуре «клиент-сервер». Наиболее известными многопользовательскими СУБД являются: Oracle, Informix, SyBase, Microsoft SQL Server, InterBase.

Персональные СУБД обеспечивают возможность создания локальных БД, работающих на одном компьютере. К персональным СУБД относятся: Paradox, dBase, FoxPro, Access и др.

СУБД dBASE

Одним из наиболее распространённых языков программирования, ориентированным на создание и использование реляционных баз данных, являлся в начале 90^х годов язык dBASE, поддерживаемый системами dBASE III Plus, которая была русифицирована под названием РЕБУС и dBASE IV. Выполнение программ этими системами осуществляется путём интерпретации одиночных команд или их набора в форме программного модуля.

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

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

На сегодняшний день шире всего используется dBase-подобный язык FoxPro в различных версиях программной среды и СУБД FoxPro.

СУБД FoxPro

СУБД FoxPro на 1995 год обладала исключительно высокими скоростными характеристиками и в этом отношении заметно выделялась среди интерпретирующих систем. Сравнительно с dBASE IV ее скорость в несколько раз выше. Практически по всем показателям Fox-программы работают заметно быстрее Clipper-программ. Версии системы от 1 до 2.3 являются исключительно программными, но, несмотря на большую трудоемкость, вполне позволяют создавать в приложениях окна, кнопки, падающие и всплывающие меню, подключать мышь для работы пользователя. Эти версии системы не работают с сопроцессором, используют MS-DOS-окно памяти, т. е. 640 Кб.

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

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

СУБД Microsoft Access

Система управления базами данных MS Access поддерживает реляционную модель данных с механизмом ссылочной целостности. Поэтому в базах данных СУБД MS Access данные представляются в виде таблиц и функциональных бинарных связей между таблицами. Дополнительное средство представления данных — запросы. Запрос представляет собой виртуальную таблицу, которая формируется по требованию на основе заранее составленного описания запроса по данным из физических таблиц базы данных. Никаких других различий между физическими таблицами и запросами нет. Во всех операциях они участвуют на равных правах. Основное назначение запросов — представление для вывода дополнительной информации, а также скрытие от пользователей сложных запросов: пользователь обращается к системе с простым запросом к виртуальным данным, а всю работу по их формированию (по заранее составленному сложному запросу) берет на себя СУБД.

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

Access входит в набор инструментальных программных средств, является настольной СУБД, легка в использовании даже для неспециалистов в программировании[3].

Выделим основные критерии, на основании которых выберем СУБД для данного проекта:

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

2. Возможность интеграции с другими программами.

3. Поддержание реляционной модели БД.

4. Механизм ссылочной целостности, для реализации функциональных бинарных связей.

Преимущества MS Access

Рассмотрим вышеперечисленные СУБД непосредственно для выбора программы, удовлетворяющей поставленные задачи.

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

Поскольку основным преимуществом СУБД FoxPro является расчеты, то её удобно использовать в сфере экономики.

СУБД Access удовлетворяет поставленным задачам для данного проекта, так как обладает следующими возможностями:

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

· глубоко развитые возможности интеграции с другими программными продуктами, входящими в состав Microsoft Office, а также с любыми программными продуктами, поддерживающими технологию OLE;

· богатый набор визуальных средств разработки;

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

3.2 Разработка физической модели БД

Физическая модель фактически является отображением системного каталога БД. Создание модели данных, как правило, начинается с создания логической модели. После описания логической модели, проектировщик может выбрать необходимую СУБД и ERWin автоматически создаст соответствующую физическую модель. ERWin поддерживает большинство ведущих наиболее популярных реляционных СУБД, а также настольные системы: Access, FoxPro, dBase, Clipper и Paradox. На основе физической модели ERWin может сгенерировать системный каталог СУБД или соответствующий SQL-скрипт, то есть набор команд на языке SQL. Этот процесс называется прямым проектированием (Forward Engineering). Тем самым достигается масштабируемость — создав одну логическую модель, можно сгенерировать физические модели под любую поддерживаемую ERWin СУБД.

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

Таблица № 2. Перечень объектов и их атрибутов.