Министерство образования и науки Украины

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

к курсовому проекту на тему

«Работа торгового склада»

по дисциплине

«Организация баз данных»

2006

СОДЕРЖАНИЕ

Введение

1. Постановка задания

2. Современные технологии создания клиентских приложений

2.1 Технология ActiveX Data Objects (ADO)

2.2 Механизм BDE

2.3 Технология InterBaseExpress

3. Логическое проектирование базы данных

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

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

3.3 Потоки данных

4. Реляционная модель данных

4.1 Процесс нормализации базы данных

4.2 Целостность базы данных

4.3 Организация секретности базы данных

5. Список операций над базой данных

6. Список запросов к базе данных

7. Обоснование выбора языка программирования

8. Технические требования к системе для применения программы

9. Общая структура программы

10. Руководство пользователя

Заключение

Библиография

Введение

Активная деятельность по отысканию приемлемых способов обобществления непрерывно растущего объема информации привела к созданию в начале 60-х годов специальных программных комплексов, называемых "Системы управления базами данных" (СУБД).

Основная особенность СУБД – это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали называть банки данных, а затем "Базы данных" (БД).

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

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

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

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

1. Постановка задания

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

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

1 Проектирование базы данных.

1.1 Анализ предметной области (ПО).

1.2 Разработка иерархической модели БД для заданной ПО на трех уровнях абстракции.

1.3 Определение необходимых операций выполняемых над БД:

а) операции модификации;

б) множество запросов к БД.

1.4 Обеспечение секретности.

1.5 Защита целостности данных.

1.6 Организация параллельных операций над БД.

1.7 Защита от отказов и восстановление.

2 Разработка интерфейса.

2. Современные технологии создания клиентских приложений

2.1 Технология ActiveX Data Objects (ADO)

Технология ADO усиленно развивается компанией Microsoft. На основе этой технологии созданы соответствующие компоненты-наборы: TADOTable, TADOQuery, TADOStoredProc, повторяющие в функциональном отношении компоненты TTable, TQuery, TstoredProc, но не требующие развертывания и настройки на клиентской машине BDE.

Основным достоинством является ее естественная ориентация на создание «облегченного» клиента. В рамках этой технологии на машине разработчика базы данных устанавливаются базовые компоненты MSADO. На машине сервера данных устанавливается так называемый провайдер данных – некоторая надстройка надспециальной технологии OLEDB, «понимающая» запросы объектов ADO и умеющая переводить эти запросы в нужные действия с данными. Взаимодействие компонентов ADO и провайдера осуществляется на основе универсальной технологии ActiveX, причем провайдер реализуется как COM-сервер, а ADO-компоненты – как COM-клиенты.

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

2.2 Механизм BDE

Ключевой механизм BDE, обеспечивающий работу визуальных компонент баз данных, действует как интерфейс между приложением и самой базой данных. Он реализован в виде набора системных *.*dll-файлов. Взаимодействие объектов с BDE никак не специфицирует конкретную базу данных и не зависит от реализации обмена информацией на нижнем уровне иерархии. Используя BDE, мы можем получить доступ ко всем локальным стандартным базам данных, к источникам данных и к SQL-серверам.

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

2.3 Технология InterBase Express

Как рассмотренная технология ADO, технология InterBaseExpress (используется как в качестве файл-серверной технологии, так и в качестве клиент-серверной технологии) рассчитана на создание «облегченного» клиента. С этой целью она предоставляет программисту способ непосредственного обращения к промышленному серверу InterBase версии 5.5 без использования машины баз данных BDE или подобных средств доступа к данным.

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

Характерной особенностью данной технологии является создание соединения с базой данных, которое достигается с помощью двух компонент: TIBDataSet и TIBTransaction. Только после размещения на форме этих компонентов и их настройки доступ к данным могут получить другие компоненты InterBase.

Использование механизма InterBase для реализации доступа к локальным базам данных обладает рядом преимуществ:

- InterBase входит в состав инсталляционного пакета Delphi и его можно установить при инсталляции;

- отсутствие необходимости производить установку дополнительных средств доступа к данным;

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

Поэтому при разработке автономных локальных баз данных в данном курсовом проекте наиболее целесообразно было использование механизма InterBaseExpress.

3. Логическое проектирование базы данных

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

Процесс проектирования БД состоит из 2-х этапов:

--проектирование логической БД;

--проектирование физической БД.

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

Физическое проектирование связано с фактической реализацией БД. Оно определяет рациональный выбор структуры хранения данных и методов доступа к ним. Результат физического проектирования - внутренняя модель данных.(см. ниже).

При проектировании выделяют три уровня абстракции (см. рисунок 3.1) для БД :

1)представление – инфологическая (внешняя) модель;

2)концептуальная БД – даталогическая (внутренняя) модель;

3)физическая БД – физическая (внутренняя) модель.

Реально хранится только физическая БД.

Рис. 3.1 Уровни моделей данных

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

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

Необходимо разработать БД и клиентское приложение для работы торгового склада. Имеются данные о товарах и о покупателях, которые содержатся в накладных. Эти данные могут быть представлены внешней моделью (Рис.3.1.1).

Рис.3.1.1 Внешняя модель

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

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

3.2 Обмен информацией между базой и отдельными категориями

пользователей системы

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

- категория кладовщик;

- категория оператор;

- категория администратор.

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

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

Рисунок 3.2.1- Порядок обмена информацией между пользователями и базой данных.

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

3.3 Потоки данных

Структурная схема потоков данных представлена на рисунке 3.3.1.

Рисунок 3.3.1.- Структурная схема потоков данных

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

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

4. Реляционная модель данных

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

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

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

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

4.1 Процесс нормализации базы данных

Процесс проектирования БД можно в некоторой степени формализовать.

Одной из таких формализации является требование, согласно которому реляционная база данных должна быть нормализована. Процесс нормализации (см. Рис. 4.1.1) имеет своей целью устранение избыточности данных и заключается в приведении к третьей нормальной форме (ЗНФ).

Рис.4.1.1 Процесс нормализации

Первая нормальная форма

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

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

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

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

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

Рис.4.1.2 Общий вид накладной

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

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

ОТПУСК-ТОВАРОВ-СО-СКЛАДА

Рис. 4.1.3 Таблица без составных полей и циклических групп

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

На рис. 4.1.4 показана структура таблицы после выделения полей в составе первичного ключа (эти поля отчеркнуты от прочих полей линией и располагаются в верхней части структуры таблицы).

ОТПУСК-ТОВАРОВ-СО-СКЛАДА

Рис. 4.1.4 Таблица с избыточным первичным ключом

Вторая нормальная форма

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

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

ОТПУСК-ТОВАРОВ-СО-СКЛАДА

Рис. 4.1.5 Таблица с неизбыточным первичным ключом, но еще не приведенная к 2НФ

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

Рис. 4.1.6 Выделение таблицы «Товары»

После анализа структуры таблицы можно заметить, что значение поля «Покупатель» никоим образом не зависит от пары значений «Номер накладной», «Товар», а зависит только от значения поля «Номер накладной». Поэтому данное поле и зависящие от его значения поля «Город», «Адрес» выделяем в таблицу «Покупатели» (рис. 4.1.7).

Анализируя далее структуру таблицы «Отпуск товаров со склада», обнаруживаем, что одно из оставшихся полей - «Дата» - зависит только от значения поля «Номер накладной». Поэтому выделяем поля «Дата» и «Номер накладной» в самостоятельную таблицу «Накладные» (рис. 4.1.8).

Установим связи между таблицами. Один покупатель может встречаться во многих накладных. Поэтому между таблицами «Покупатели» и «Накладные» имеется связь один-ко-многим по полю «Покупатель». Одной накладной может соответствовать несколько товаров. Поэтому между таблицами «Накладные» и «Отпуск товаров со склада» имеется связь один-ко-многим по полю «Номер накладной» (рис. 4.1.9).

Рис. 4.1.7 Выделение таблицы «Покупалели»

Рис. 4.1.8 Выделение таблицы «Накладные»

Рис. 4.1.9 Связи между таблицами

Третья нормальная форма

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

В таблице «Отпуск товаров со склада» имеется зависимость значения поля «Общая стоимость» от значения поля «Количество». Значение поля «Общая стоимость» может вычисляться как значение поля «Количество», умноженное на значение поля «Цена за единицу измерения» из таблицы «Товары» (из записи с таким же значением поля «Товар»). Поэтому поле «Общая стоимость» из таблицы «Отпуск товаров со склада» удаляем. В результате получаем нормализованную базу данных, структура которой приводится на рис. 4.1.10.

В таблице «Покупатели» значение поля «Адрес» зависит от значения поля «Город», поскольку в разных городах могут оказаться улицы с одинаковыми названиями и, соответственно, дома с одинаковыми номерами (вспомним известный кинофильм «Ирония судьбы, или с легким паром»). Однако такой зависимостью можно пренебречь, поскольку поле «Адрес» в нашем случае носит чисто информационный характер и не должно входить в условия запросов самостоятельно. Вообще говоря, на практике не всегда возможно получить идеально нормализованную БД.

Полная реализация реляционной структуры БД отражена на плакате.

Рис. 4.1.10. Нормализованная база данных

4.2 Целостность данных

Целостность (от англ. integrity – нетронутость, неприкосновенность, сохранность, целостность) – понимается как правильность данных в любой момент времени.

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

Выделяют три группы правил целостности:

1. Целостность по сущностям.

2. Целостность по ссылкам.

3. Целостность, определяемая пользователем.

Мотивировка правил целостности, общих для любых реляционных баз данных:

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

2. Значение внешнего ключа должно либо:

· быть равным значению первичного ключа цели;

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

3. Для любой конкретной базы данных существует ряд дополнительных специфических правил, которые относятся к ней одной и определяются разработчиком. Чаще всего контролируется: уникальность тех или иных атрибутов, диапазон значений (экзаменационная оценка от 2 до 5),принадлежность набору значений (пол "М" или "Ж").

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

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

В нашем случае зависимости между различными атрибутами будут следующими:

1. Товар определяется ключевым атрибутом «товар» в таблице Товары

2. Факт продажи товара со склада определяется составным ключевым атрибутом «товар» и «номер_накладной» в таблице Отпуск_товаров_со_склада

3. Накладные определяются ключевым атрибутом «номер_накладной» в таблице Накладные

4. Данные о покупателе определяются ключевым атрибутом «покупатель» в таблице Покупатель

Таблицы Товары и Отпуск_товаров_со_склада связаны отношением 1:М по внешнему ключу «Отпуск_товаров_со_склада . товар».

Таблицы Отпуск_товаров_со_склада и Накладные связаны отношением М:1 по внешнему ключу «Отпуск_товаров_со_склада . номер_накладной».

Таблицы Накладные и Покупатели связаны отношением М:1 по внешнему ключу «Накладные . покупатель».

4.3 Организация секретности базы данных

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

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

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

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

- выполнение стандартных простых и сложных запросов к базе данных.

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

- просмотр содержимого всех имеющихся таблиц;

- удаление, добавление, модификация данных;

- выполнение стандартных простых и сложных запросов к базе данных.

Администратор БД наделен наибольшими полномочиями. Вход осуществляется по паролю администратора. Функции:

- просмотр содержимого всех имеющихся таблиц;

- удаление, добавление, модификация данных;

- выполнение стандартных простых и сложных запросов к базе данных;

- реализация сеанса SQL с возможностью написания собственных запросов;

- изменение всех видов паролей.

5. Список операций над базой данных

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

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

1) традиционные теоретико-множественные операции объединения, пересечения, разности и декартового произведения применительно к отношениям;

2) специальные реляционные операции селекции, проекции, соединения и деления.

Язык SQL является языком манипулирования для реляционной БД. В SQL реализовано три функции манипулирования данными : 1) определение; 2) выборка; 3) обновление. Язык позволяет обеспечить наиболее необходимые и часто используемые операции при помощи объединения различных таблиц.

Все таблицы реализованы в физическом файле TEST.GDB. Таблицы реализованы в формате InterBASE, который используется для реализации локальных баз данных.

В программе реализованы следующие операции, которые можно выполнять над БД:

1) Выбор какого-либо одного поля либо всей записи из заданной таблицы по признаку равенства поля какому-либо значению;

2) Вывод нескольких необходимых полей таблицы;

3) Выбор всей таблицы в целом;

4) Сортировка данных таблиц по какому-либо заданному полю;

5) Создание, модификация и удаление записей таблиц;

6) Подсчет выручки за каждый день и вывод общего списка всех выручек либо подсчет выручки за какой-либо конкретный день;

7) Подсчет сведений о товарах: сколько всего единиц и на какую сумму каждого товара продано за весь период либо за конкретный день;

8) Получение сведений о том, какие фирмы приобретали тот или иной товар;

9) Получение сведений о том, какие товары приобретала определенная фирма.

Клиентское приложение работает с сервером баз данных.

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

Сервер на Win32 запускается в качестве сервиса ОС. Клиентские приложения могут присоединяться к нему несколькими способами: по протоколам NetBEUI, TCP-IP; локальное подключение (в случае, если вы работаете на машине, на которой запущен сервер). В нашем случае рассматривается подключение к серверу по протоколу ТСР-IP.

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

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

6. Список запросов к базе данных

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

Существует несколько категорий запросов:

1 Полный просмотр таблиц

Просмотр содержимого таблицы товары:

select *from товары

Просмотр содержимого таблицы покупатели:

select *from покупатели

Просмотр содержимого таблицы накладные:

select *from накладные

Просмотр содержимого таблицы отпуск_товаров_со_склада:

select *fromотпуск_товаров_со_склада

В результате запроса будет полностью выведена соответствующая таблица.

2 Простые запросы

Селекция для таблицы товары

select *fromтовары whereтовар=’наимен_тов’

select *fromтовары whereед_измерения=’наимен_ед_измер’

Селекция для таблицы покупатели

select *fromпокупатели whereгород=’наимен_города’

select *from покупатели whereпокупатель=’наимен_фирмы’

Селекция для таблицы накладные

select *fromнакладные whereдата=’день . месяц . год’

select *from накладные whereпокупатель=’наимен_фирмы’

Селекция для таблицы отпуск_товаров_со_склада

select *fromотпуск_тов_со_склада whereтовар=’наимен_тов’

select *fromотпуск_тов_со_склада whereотпущено_ед =max(отпущено_ед)

select *fromотпуск_тов_со_склада whereотпущено_ед =min(отпущено_ед)

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

3 Сложные запросы

Вывести список всех товаров, которые купил какой-либо покупатель

Select товар from отпуск_тов_со_склада where номер_накладной in

(select номер_накладной from накладные where покупатель=’наимен_фирмы’)

В результате запрос выведет таблицу 6.1.

Таблица 6.1

Вывести список всех покупателей, которые купили какой-либо товар

Select покупатель from накладные where номер_накладной in

(select номер_накладной from отпуск_тов_со_склада where

товар =’наимен_товара’)

В результате запрос выведет таблицу 6.2.

Таблица 6.2

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

Select товары . тов , sum(отпуск_тов_со_склада . отпущено_ед),

sum(отпуск_тов_со_склада . отпущено_ед * товары . ед_измер),

from (товары JOIN отпуск_тов_со_склада ON товары . товар= отпуск_тов_со_склада . товар) JOIN накладные ON отпуск_тов_со_склада . номер_накл=накладные . номер_накл

GROUPBY товары . товар

В результате запрос выведет таблицу 6.3.

Таблица 6.3

Список выручек за каждый день, за все время работы предприятия

Select накладные . дата ,

sum(отпуск_тов_со_склада . отпущено_ед * товары . ед_измер)

from (товары JOIN отпуск_тов_со_склада ON товары . товар= отпуск_тов_со_склада . товар) JOIN накладные ON отпуск_тов_со_склада . номер_накл=накладные . номер_накл

GROUPBY накладные . дата

В результате запрос выведет таблицу 6.4.

Таблица 6.4

Выручка за конкретный день

Selectsum(отпуск_тов_со_склада . отпущено_ед * товары . ед_измер)

from (товары JOIN отпуск_тов_со_склада ON товары . товар= отпуск_тов_со_склада . товар) JOIN накладные ON отпуск_тов_со_склада . номер_накл=накладные . номер_накл

where накладные . дата=’день. месяц. год’

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

Таблица 6.5

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

Select товары . тов , sum(отпуск_тов_со_склада . отпущено_ед),

sum(отпуск_тов_со_склада . отпущено_ед * товары . ед_измер),

from (товары JOIN отпуск_тов_со_склада ON товары . товар= отпуск_тов_со_склада . товар) JOIN накладные ON отпуск_тов_со_склада . номер_накл=накладные . номер_накл

where накладные . дата=’день. месяц. год’ GROUPBY товары . товар

В результате запрос выведет таблицу 6.6.

Таблица 6.6

7. Обоснование выбора языка программирования

Клиентское приложение для информационной системы «Работа торгового склада» разработано с помощью системы объектно-ориентированного программирования Delphi 6, при этом, для реализации доступа к данным был выбран механизм прямого доступа FireBird с форматом InterBase.

Система объектно-ориентированного программирования Delphi 6 производства корпорации Borland предназначена для операционных систем Windows 95,WindowsNT и более поздних версий Windows. Интегрированная среда Delphi 6 обеспечивает скорость визуальной разработки, продуктивность повторно используемых компонент в сочетании с мощью языковых средств ObjectPascal, усовершенствованными инструментами и разномасштабными средствами доступа к базам данных.

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

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

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

Delphi 6 обеспечивает высокое быстродействии при компиляции и сборке 32 - разрядных приложений для современных операционных систем Windows, включая OLE взаимодействие клиент-сервер. Результирующие программы хорошо оптимизированы по скорости исполнения и затратам памяти. "Дизайнер форм" и "Инспектор объектов" и другие средства остаются доступными во время работы программы, поэтому вносить изменения можно в процессе отладки.

Разработка по способу "drag-and-drop" многократно упрощает и ускоряет обычно трудоёмкий процесс программирования СУБД в архитектуре клиент-сервер. Широкий выбор компонент управления визуализацией и редактированием позволяет легко изменить вид отображаемой информации и поведение программы. Delphi 6 использует DatabaseExplorer (Проводник баз данных) и DataDictionary (Словарь данных), чтобы автоматически настроить средства отображения и редактирования применительно к специфики вашей информации.

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

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

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

Доступ к данным осуществляется через механизм прямого доступа к объектам FireBird, который поддерживает высокопроизводительный 32 – разрядный доступ к базам данных. Delphi 6 использует контроллер ODBC (OpenDatabaseConnectivity) производства Microsoft для связи с серверами баз данных.

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

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

8. Технические требования к системе для применения программы

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

- ЭВМ типа IBMPC или любая другая, обладающая полной совместимостью;

- наличие накопителя на жестком магнитном диске;

- наличие накопителя на гибких магнитных дисках;

- процессор класса не ниже Pentium;

- оперативная память – 16 Мбайт;

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

- сервер баз данных - InterBase Server.

Данные минимальные требования к системе определяются требованиями, необходимыми для работы операционной системы Windows 98 и надежной работы InterBase.

9. Общая структура программы

Структура программы отображает взаимодействие окон (форм) программы. Общая структура программы представлена на рисунке 9.1.

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

Unit1 (Form1) – основной модуль программы. Он используется для просмотра всех имеющихся таблиц, для добавления, модификации и удаления данных.

Unit3 (Form3) - модуль для выбора уровня доступа. Модуль включает проверку введенного пароля на соответствие текущему по данной категории пользователя.

Unit4 (Form4) – модуль, позволяющий задать путь к базе данных, а также позволяющий администратору осуществить смену паролей.

Unit5 (Form5) – модуль для ввода SQL-запроса. Позволяет администратору осуществить прямой ввод SQL-запросов в диалоговом окне.

Unit6 (Form6), Unit7 (Form7) – модули, используемые для выполнения запросов к различным таблицам в соответствии с интересующими пользователя данными.

Фрагменты текста программы приводится в приложении А. Полный текст программы (все листинги), файлы проекта и программа установки содержатся на дискете, которая прилагается к пояснительной записке.

10. Руководство пользователя

Технология InterBaseExpress используется как в качестве файл-серверной технологии, так и в качестве клиент-серверной технологии, она рассчитана на создание «облегченного» клиента. С этой целью она предоставляет программисту способ непосредственного обращения к промышленному серверу InterBase версии 5.5. Поэтому перед работой с приложения необходимо установить сервер баз данных - InterBaseServer и загрузить его.

Для запуска клиентского приложения необходимо записать файл Test.gdb в папку C:\ProgramFiles\Database\. Далее, запустив файл “storage.exe”, необходимо ввести пароль определенной категории. На экран выводится окно для ввода пароля (см. рисунок 10.1).

Рисунок10.1 Начальная загрузка программы.

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

При внесении администраторского пароля, кроме операций доступных оператору, появится возможность ввода SQL-запросов , т.к. в меню появится пункт «Ввод SQL» доступный только администратору. При входе в систему в роли администратора появляется возможность смены паролей всех категорий. Эта функция доступна только администратору.

Меню программы содержит следующие пункты:

- файл;

- таблицы;

- запросы;

- утилиты.

“Файл” содержит выпадающее подменю:

- доступ;

- настройки;

- выйти.

При выборе пункта “доступ” на экране появляется окно, изображенное на рисунке 10.1.

При выборе пункта “настройки” на экране появляется окно, изображенное на рисунке 10.2.

Рисунок 10.2 Окно настроек

При выборе пункта “выйти” на экране появляется окно для подтверждения выхода, изображенное на рисунке 10.3.

Рисунок 10.3 Окно подтверждение выхода

Пункт главного меню “Таблицы” содержит выпадающее подменю:

- товары;

- покупатели;

- накладные;

- отпуск товаров.

При выборе пункта “товары” на экране отображается содержимое таблицы товары (рисунок 10.4).

Рисунок 10.4 Отображение таблицы товары

При выборе пункта “покупатели” на экране отображается содержимое таблицы покупатели (рисунок 10.5).

Рисунок 10.5 Отображение таблицы покупатели

При выборе пункта “накладные” на экране отображается содержимое таблицы накладные (рисунок 10.6).

Рисунок 10.6 Отображение таблицы накладные

При выборе пункта “отпуск товаров” на экране отображается содержимое таблицы отпуск товаров (рисунок 10.7).

Рисунок 10.7 Отображение таблицы отпуск товаров

Пункт “Запросы” содержит выпадающее подменю:

- сложные запросы;

- простые запросы.

При выборе пункта “сложные запросы” на экране появляется окно, изображенное на рисунке 10.8.

Рисунок 10.8 Окно выбора сложного запроса

При выборе пункта “ простые запросы” на экране появляется окно, изображенное на рисунке 10.9.

Рисунок10.9 Окно выбора простого запроса.

При выборе пункта “ввод SQL” на экране появляется окно, изображенное на рисунке 10.10.

Рисунок10.01 Окно ввода запроса SQL.

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

Пункт меню о программе содержит информацию об авторах проекта и краткую справочную информацию о программе.

Заключение

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

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

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

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

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

Библиография

1. Атре Ш. Структурный подход к организации баз данных. – М.: Финансы и статистика, 1983. – 320 с.

2. Грей П. Логика, алгебра и базы данных. / Пер.с англ. – М. :Машиностроение, 1989 – 386 с.

3. Дейт К. Введение в системы баз данных. / Пер. с англ. – М. :Наука. Гл. ред. Физ. – мат. Инт. , 1980 – 464 с.

4. Кнут Д. Искусство программирования на ЭВМ. Основные алгоритмы. - М.: Мир, 1976. Т.1: - 512 с., Т.2: - 740 с.

5. Фаронов В.В. Базы данных. Delphi 6. Учебный курс. – М.: Издатель Молгачева С. В., 2001. – 653 с., ил.

6. Фаронов В.В. Delphi 6. Учебный курс. – М.: Издатель Молгачева С. В., 2001. – 672 с., ил.

ПРИЛОЖЕНИЕ А

1 ИНФОРМАЦИОННЫЕ РАСЧЕТЫ, ВЫПОЛНЯЕМЫЕ НА ЭТАПЕ ЛОГИЧЕСКОГО ПРОЕКТИРОВАНИЯ

При построении физической БД рекомендуется следующая связь с категориями логической модели[8]:

-объект - файл;

-экземпляр объекта - логическая запись;

-атрибут - поле;

-структурная связь - указатель.

Данные о базе данных:

Таблица «Товары»:

Длина поля: 55 байт.

Таблица «Покупатели»:

Длина поля: 60 байт.

Таблица «Накладные»:

Длина поля: 30 байт.

Таблица «Отпуск товаров со склада»:

Длина поля: 32 байт.

1. Длина логической записи j-ого файла определяется как сумма длин полей:

[байт] (3.1)

где M_j - число групп полей в записях(А₂ =2 и более), l_ij длина группы [байт].

=55+60+30+32=177 байт.

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

[байт] (3.2)

где N - число типов записей в информационном фонде, K_j - количество записей j -го файла.

При пустой базе, то есть при отсутствии записей Ki =1.

Следовательно имеем: =177 байт.

3. Приращение информационного фонда

[байт^-1 ] (3.3)

где - число добавленных типов записей, - интенсивность добавления записей в файл j -го типа.

При средней интенсивности =100 зап/день, имеем приращение информационного фонда:

=100*177=17700 байт, или 17,28 кБайт.

4. Зная первоначальный объём V_общ памяти, выделенной под развёртывание БД, и объем программного обеспечения V_ПО , представляется возможным оценить время заполнения информационного фонда

[время] (3.4)

Указанная величина определяется

- приращением информационного фонда: 17,28 кБайт;

- первоначальными объемами памяти: Vобщ=1,2 ГБ =614400 кБ;

- объемом программного обеспечения V_ПО = 307200 кБ;

- объемом памяти, необходимым для размещения информационного фонда: I=177 Б = 0,178 кБ.

Следовательно, имеем:

Iзап = (614400 – 307200 – 0,178)/17,28 = 17777 дней.

5. Время резервного копирования определяется промежутками времени, в которые поступает порция данных порядка 20% первоначального объёма БД

(3.6)

Следовательно, резервное копирование следует проводить каждые:

Tp=0.2*0.178/17.28=0,2 дня или через каждые 4.8 часов.

6. Количество обращений к логическим записям

(3.7)

где - количество обращений к записям j -го типа в i -м запросе.

В базе - три типа записей:

J=1 - Integer – 3 поле

J=2 - Date – 1 поле

J=3 - Varchar – 7 полей

J=4 - Numeric – 1 поле

Следовательно, имеем:

=12.

7. Интенсивность обращений к информационному фонду

(3.8)

где - частота выполнения i - того запроса( определяется учащимся и согласовывается с руководителем), Z - число запросов, обработка которых предусмотрена СУБД.

При среднем количестве запросов вывода информации равном 0, и запросов ввода равном 100. Имеем частоту выполнения запросов:

=100+20=120 зап/день.

Следовательно, имеем интенсивность обращений к информационному фонду:

=12*120=1440.

2 СЕТЕВАЯ СТРУКТУРА ОРГАНИЗАЦИИ БАЗ ДАННЫХ

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

В основе лежит возможность осуществления связи между удалёнными компьютерами по:

- линиям телефонной связи;

- воздушным радиолиниям;

- спутниковой связи.

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

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

- загруженность линий связи;

- загруженность клиентского терминала;

- общая неустойчивость системы.

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

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

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

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

В данной структуре априори известно, что сервер хранит базы данных и выполняет запросы, поступающие от клиентских терминалов из локальной сети. Либо выполняет запросы от удалённых клиентских терминалов, через всемирную сеть Интернет. Эти терминалы могут быть расположены по всему миру (например, базы данных авиакомпании «Америка ОнЛайн»). Причём интернет-порталом не обязательно должен быть сервер баз данных.

Удалённые

терминалы

Интернет

Сервер

Рабочие

станции

Рис.1 Сетевая организация баз данных корпоративных клиентов

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

В случае нашего курсового проекта на машине-сервере должен быть развернут InterBaseServer. А программным обеспечением осуществляющим отправку посылок и отображения результатов запросов является программа Storage.

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

Для администратора системы не предусмотрено никаких ограничений в работе с данными.

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

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

3 ОТКАЗЫ И ВОССТАНОВЛЕНИЕ

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

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

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

С помощью подтверждения транзакций реализуется система каскадных взаимодействий между таблицами через FK(ForeignKey – Удалённый ключ). Существует два типа каскадных взаимодействий:

Onupdate – по изменению поля.

Ondelete – по удалению поля.

Когда выставлено взаимодействие onupdate, при изменении содержимого поля в главной таблице изменяется содержимое поля в подчинённой.

Когда выставлено взаимодействие ondelete, при удалении содержимого поля в главной таблице удаляется содержимое поля в подчинённой.

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

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

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

4 СОХРАНЕНИЕ ДАННЫХ

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

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

- Следующий тип носителя, это CD-R, CD-WR диски (однократно записываемые, и перезаписываемые компакт диски). Эти носители не могут хранить настолько же большие объёмы информации, как магнитная лента, однако являются самыми распространёнными, для баз малого и среднего бизнеса, где не требуется хранить большие ресурсы, однако необходимы удобство и скорость работы. Так же компакт диски дольше других носителей могут хранить записанную на них информацию.

- И последний распространённый тип носителя – флоппи диски.

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

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

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

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

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

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

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