Учебная работа. Курсовая работа: Работа торгового склада

Учебная работа. Курсовая работа: Работа торгового склада

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

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

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

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

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

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

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 Разработка иерархической модели БД для данной ПО на 3-х уровнях абстракции.

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 либо схожих средств доступа к данным.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1)

Рис. 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. Реляционная модель данных

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

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

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

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

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

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

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

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

1-ая обычная форма

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

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

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

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

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

Рис.4.1.2 Вид затратной

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

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

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

Дата

клиент

город

Адресок

Продукт

Ед_измерения

Цена_за_ед_измер

Отпущено_ед

Общая_стоимость

Номер_накладной

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

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

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

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

Дата

клиент

Номер_накладной

продукт

Город

Адресок

Ед_измер

Цена_за_ед_измер

Отпущено_ед

Общая_стоимость

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

2-ая обычная форма

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

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

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

Номер_накладной

продукт

Дата

клиент

Город

Адресок

Ед_измер

Цена_за_ед_измер

Отпущено_ед

Общая_стоимость

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

1-ое требование 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 Связи меж таблицами

3-я обычная форма

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

В таблице «Отпуск продуктов со склада» имеется зависимость значения поля «Общая стоимость» от значения поля «Количество». структура которой приводится на рис. 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 Организация секретности базы данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. Перечень операций над базой данных

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

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

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

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

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

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

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

1) Выбор какого-нибудь 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

Приобретенные продукты

продукт1

…

ТоварN

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

Select клиент from затратные where номер_накладной in

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

продукт =’наимен_товара’)

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

Таблица 6.2

клиент, который заполучил продукт

Покупатель1

…

ПокупательN

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

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

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

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

GROUPBY продукты . продукт

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

Таблица 6.3

продукт
Кол-во единиц проданных за все время
Общая сумма за всегда

продукт1
Кол-во_товара1
Сумма1

…
…
…

ТоварN
Кол-во_товараN
СуммаN

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

Select затратные . дата ,

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

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

GROUPBY затратные . дата

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

Таблица 6.4

Дата
Выручка_за_денек

Дата1
Выручка1

…
…

ДатаN
Выручка N

Выручка за определенный денек

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

продукт
Кол-во единиц проданных за денек
Общая сумма за денек

продукт1
Кол-во_товара1
Сумма1

…
…
…

ТоварN
Кол-во_товараN
СуммаN

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» неоднократно упрощает и ускоряет обычно трудоёмкий процесс программирования СУБД в архитектуре клиент-сервер. Широкий выбор компонент управления визуализацией и редактированием дозволяет просто поменять вид отображаемой инфы и автоматом настроить средства отображения и редактирования применительно к специфичности вашей инфы.

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

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

«Живы» данные (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.

Набросок 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:ProgramFilesDatabase. Дальше, запустив файл “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. Грей П. системы баз данных. / Пер. с англ. – М. :Наука. Гл. ред. Физ. – мат. Инт. , 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)

где Mj
— число групп полей в записях(А2
=2 и наиболее), lij
длина группы [б].

=55+60+30+32=177 б.

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

[б] (3.2)

где N — число типов записей в информационном фонде, Kj
— количество записей 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 предусмотрена система откатов и восстановлений, работающей опосля сбоев в работе сервера либо какого или клиентского терминала системы. Данная система базирована на свойстве доказательства транзакций.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

]]>