Рисунок  2.1 – Структурная схема архивации SQL баз данных 

Рисунок 2.2 – Структурная схема архивации файлов и каталогов 

     Программа-приложение на рисунках 2.1 и 2.2 явным образом не взаимодействует ни с MS SQL Server, ни с архиватором, ни с командой копирования во время архивации данных, а лишь подготавливает САД к такому взаимодействию программ, создавая на SQL Server-е хранимую процедуру, настроив её выполнение по заданному расписанию.

     Рассмотрим  такое взаимодействие на примере архивации SQL баз данных.

     MS SQL Server по заданному расписанию запускает Job, который лишь вызывает хранимую процедуру. В хранимой процедуре записана вся последовательность действий по архивации данных этого сервера включая SQL базы данных, файлы и каталоги. Первым выполняется команда BackUp с заданными параметрами для указанных баз данных. Её выполнение протоколируется в указанный файл. После удачного завершения появляется файл резервной копии SQL базы данных и файл журнала BackUp. Оба файла передаются по средствам команды с заданными параметрами архиватору для упаковки в один архив. Весь процесс опять же протоколируется в файл-журнал архивации. Готовый архив с помощью настроенной команды копируется на другой сервер. Процесс копирования протоколируется в тот же файл-журнал, что и архивация.

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

     Такая структура архивации данных позволяет:

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

2.3 Функциональная модель  системы архивации  данных

 

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

• какие действия выполняются в рамках данной методологии?
• кто или что выполняет действие, и какое?
• чем руководствуется исполнитель при выполнении действия?
• какой документ или документы, или какие результаты получаются после завершения действия?

     Функциональное  моделирование системы проведено  в рамках SADT (IDEF0) – методологии [6] для обзора предметной области с точки зрения инженера.

     Функциональное  моделирование выполнено  в среде  Computer Associates\AllFusion Process Modeler\BPwin [6].

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

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

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

     Место соединения дуги с блоками определяет тип интерфейса.

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

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

     Результаты  выполнения функции отображаются с  правой стороны (блок выхода).

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

     Основная  функция системы изображена на рисунке 2.3.

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

     На  рисунке 2.4 представлена декомпозиция основного блока, из которой следует, что этот блок состоит из следующих более «мелких» функций:

• команда BackUp для SQL Server;
• архивация данных;
• копирование готовых архивов.

     Диаграмма также содержит связи между этими  функциями и исполнителями.

     IDEF0 не ограничивает количество уровней декомпозиции. Это дает возможность получать модель бизнес-процедуры с требуемой степенью детализации. Основная функция системы фактически не изменилась (рисунок 2.5). Функциональная же модель, которая является структурированным изображением функций системы, а также информации и объектов, связывающих эти функции, для состояния «как должно быть» (“to be”), претерпела некоторые изменения (рисунок 2.6 и 2.7).

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

     Точка зрения: инженер.

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

 

     

Рисунок 2.3 – Основная функция системы (модель прототипа «как есть»)

Рисунок 2.4 – Декомпозиция верхнего уровня (модель «как есть»)

Рисунок 2.5 – Основная функция системы (модель «как должно быть») 
 

Рисунок 2.6 – Декомпозиция верхнего уровня (модель «как должно быть»)

Рисунок 2.7 – Декомпозиция нижнего уровня (модель «как должно быть») 

2.4 Алгоритмические модели

 

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

     

Рисунок  2.8 – Существующий алгоритм механизма архивации SQL баз данных (а),

файлов  и каталогов (б) 

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

     Алгоритм  механизма функционирования будущей  системы архивации данных представлен  на языке блок-схем по ГОСТ 19.701 на рисунке 2.9.

     

Рисунок  2.9 – Алгоритм работы будущей САД для SQL баз данных (а),

файлов  и каталогов (б)

2.5 Результаты и выводы по главе 2

 

     В данной главе синтезированы следующие  модели:

• концептуальная модель системы;
• структурная модель системы;
• функциональная модель системы;
• алгоритмическая модель системы.

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

3 Проектирование системы архивации данных

3.1 Системное проектирование

3.1.1 Состояние объекта

 

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

     Листинг хранимой процедуры приведен в Приложении А.

     Хранимая  процедура была внедрена в базу данных master и вызывалась простым Job-ом (exec zzz_BackUp), настроенным на выполнения по заданному расписанию и сохранение сообщений при выполнения в указанный файл. Внедрение и настройка выполнялись в ручном режиме.

3.1.2 Техническое задание  на разработку

 

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

     Техническое задание приведено в Приложении Б. 

3.2 Результаты и выводы по главе 3

 

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

4 Инженерная реализация системы архивации данных

4.1 Модули реализованные инженерно

 

     Функционально система САД состоит из двух модулей:

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

     Модуль  непосредственного выполнения архивации представляет собой внедренную в базу данных Master в СУБД MS SQL Server 2000 хранимую процедуру. Хранимая процедура запускается на выполнение специально настроенным Job-ом по расписанию.

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

4.2 Экранные формы,  отражающие интерфейс САД

4.2.1 Подключение и авторизация SQL Server

 

     Сразу после загрузки программы появляется форма для подключения и авторизации  на SQL Server-е (рисунок 4.1).

     Поля  «Логин» и «Пароль» появляются только при выбранном типе «SQL-авторизации».

     При нажатии кнопки «Отмена» программа закрывается, так как все дальнейшие действия не могут быть выполнены без авторизации на SQL Server-е.

     При нажатии кнопки «ОК» программа при  успешной авторизации переходит  в главное окно.

Рисунок  4.1 – Подключение и авторизация SQL Server

4.2.2 Главное окно

 

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