Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

1. Формирование каталога книг.

1.1 Ввод данных о поступившей литературе.

1.2 Просмотр отчетов по запросам.

2. Составление карточки читателя.

2.1. Запись нового читателя.

2.1.1 Ввод книг выдаваемых читателю.

2.2. Получение отчетов карточки читателя и выданных ему книгах.

3. Ввод данных о читателях задолжниках.

3.1 Ввод данных.

3.2 Получение отчетов о текущих задолжниках.

4. Поиск книги.

4.1 Выбор критерия поиска.

4.1.1 Получение отчетов о результате поиска.

5. Выход из программы.

6. Справка.

Представление графа сценария задачи представлено на рисунке 1.

1.1

3.1

3.2.

4.1

2.2

2.1.1

4.1.1

Р ис.1 Граф сценария задачи «Библиотека вуза»

3.2 Разработка контекстной диаграммы

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

Контекстная диаграмма показана на рисунке 2.

Рисунок 2 – Контекстная диаграмма

3.3 Разработка программной системы

3.3.1 Описание системы с использованием языка моделирования UML

Приступим к созданию модели приложения «Библиотеки вуза». На основе описанных требований и ограничений выделим классы пользователей системы, определим требования к ним и дадим описание системы с точки зрения пользователя. В системе обозначений UML таким описанием является представление использования (Use-Case View). Это представление может состоять из нескольких диаграмм использования (Use-Case Diagram), которые описывают отдельные части системы и систему в целом. Сначала составим диаграмму использования, описывающую систему в целом

Описание системы с данного языка моделирования представлено на рисунках 3,4.

читатель

Пользователь-библиотекарь

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

Рисунок 4 – Представление работы системы в целом

Пользователь – читатель

Пользователь-библиотекарь

Рисунок 4 – Представление работы системы в целом

3.3.2Технология проектирования баз данных

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

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

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

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

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

• База данных должна удовлетворять выявленным и вновь возникающим требованиям конечных пользователей.

• База данных должна легко расширяться при реорганизации и расширении предметной области.

• База данных должна легко изменяться при изменении программной и аппаратной среды.

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

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

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

Этапы проектирования базы данных с учетом рассмотренных выше аспектов представлены на рисунке 5.

Рисунок 5 – Проектирование базы данных

3.3.3 Определение сущностей

Сущность (объект) – в реляционной теории баз данных элемент информационной системы, информация о котором сохраняется. объект можем быть реальным и абстрактным. Каждый объект обладает определенным набором свойств, которые запоминаются в информационной системе.

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

• ЧИТАТЕЛЬ;

• ПЕЧАТНОЕ ИЗДАНИЕ;

• ВЫДАЧА;

• КАТАЛОГ;

• ЧИТАТЕЛЬ-ЗАДОЛЖНИК;

3.3.4 Определение взаимосвязей между сущностями и создание модели данных

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

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

Определим для вышеперечисленных сущностей взаимосвязи.

Полученная после этого информационная модель представлена на рисунке 6.

Рисунок 6 – Информационная модель на втором этапе

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

3.3.5 Задание первичных и альтернативных ключей, определение атрибутов сущностей

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

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

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

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

Атрибуты и первичные ключи сущностей для информационной модели, включаемые в состав базы данных «Приемная комиссия», приведены в таблице 1.

Таблица 1 - Первичные, альтернативные ключи и атрибуты

Сущность	Первичный ключ	Атрибуты
1	2	3
Каталог_книг	Регистрационный _№	Регистрационный _№ Автор Название Год_издания Дата_регистрации Дата_списания Раздел Абонемент1 Абонемент2 Читальный_зал Количество Издательство
Читатели	№ читательского билета	№ читательского билета ФИО Признак(код) Адрес Паспортные данные Дата_записи Дата_выбытия Группа Факультет Кафедра Степень_звание Право пользования
Выдача_книг		регистрационный № № читательского билета АбонементА1 АбонементА2 Читальный_зал Количество Дата_выдачи Дата_возврата Фактическая_дата_возвра Кол_сдал
Задолжники	Код	Код регистрационный № № читательского билета количество
Типы_читателей	Код_читателя	Код_читателя Тип_читателя
Раздел	Код_раздела	Код_раздела Раздел

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

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

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

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

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

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

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

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

Характеристики

Список файлов ВКР