2.2. Проектирование БД
В базе данных отображается информация об определенной предметной области (ПО). Инфологическая модель (ИМ) – это описание предметной области, выполненное без ориентации на используемые программные и технические средства.
На основе инфологической модели была спроектирована физическая база данных на платформе СУБД Interbase 6.
Доступ к БД должен производиться из программ с помощью SQL-запросов (3 диалект). Размер страницы обмена составляет 4 096 Байт.
Определим имена основных таблиц, соответствующих объектам инфологической модели.
БД имеет 6 таблиц, которые представлены далее в табл. 2.1–2.8
Таблица 2.1 – Структура БД
| Объект | Имя таблицы в БД |
| Справочник “Подразделения” | Departs |
| НД “Входящая кореспонденция” | InCors |
| НД “Исходящая кореспонденция” | OutCors |
| НД “Приказы” | Decrees |
| НД “Дела” | Cases |
| Справочник “Типы дел” | TypeCases |
Определим структуру таблиц БД.
Для описания полей таблицы в БД определены следующие домены:
Таблица 2.2 – Определения доменов БД
| Домен | Тип | Размер | Ограничения |
| TCount | Integer | 4 | Значение по умолчанию – 0 |
| TDate | Char(10) | 10 | Маска ввода – ‘_ _ ._ _._ _ _ _’ |
| TDep | Char(30) | 30 | |
| TDepNum | Integer | 2 | |
| TExecuter | Varchar(20) | 20 | |
| TIndexCase | Varchar(2) | 2 | Обязательное |
| TInfo | Varchar(100) | 100 | |
| TDecreeNum | Varchar(10) | 10 | Обязательное |
| TDecreeText | Varchar(512) | 512 | |
| TNameCase | Varchar(150) | 150 | |
| TNumber | Integer | 4 | Обязательное |
| TNumVH | Varchar(15) | 15 | |
| TPerNum | Varchar(5) | 5 | |
| TSave | Varchar(5) | 5 | |
| TSender | Varchar(50) | 50 | |
| TSign | Varchar(20) | 20 | |
| TCaseNum | Varchar(10) | 10 | Обязательное |
| TCaseText | Varchar(512) | 512 |
В таблицах символом # отмечают ключи (первичные индексы), а символом (#) – вторичные индексы [8].
Далее представлено описание входящей оперативной информации и ее структуры.
При получении первичных документов заполняются следующие таблицы:
Таблица 2.3 – Структура таблицы «Приказы» (DECREES)
| Поле | Ключ | Тип | Описание поля |
| ID | # | TNumber | Код |
| Decree_Num | TDecreeNum | Номер приказа | |
| Decree_Text | TDecreeText | Текст приказа | |
| Sign | TSign | Контроль | |
| Data | TDate | Дата приказа |
Таблица 2.4 – Структура таблицы «Подразделения» (DEPARTS)
| Поле | Ключ | Тип | Описание поля |
| ID | # | TNumber | Код подразделения |
| Dep | TDep | Название подразделения | |
| Info | TInfo | Обязанности подразделения |
Таблица 2.5 – Структура таблицы «Входящая корреспонденция» (INCORS)
| Поле | Ключ | Тип | Описание поля |
| ID | # | TNumber | Код документа |
| Data1 | TDate | Дата получения документа | |
| Sender | TSender | Отправитель | |
| NumVH | TNumVH | Номер входящего документа | |
| Data2 | TDate | Дата входящего документа | |
| Text | TCaseText | Короткое содержание документа | |
| ID_Executor | TExecuter | Исполнитель | |
| Info | TInfo | Отметка о контроле |
Таблица 2.6 – Структура таблицы «Типы дел» (TYPECASES)
| Поле | Ключ | Тип | Описание поля |
| Number | # | TNumber | Код |
| Dep | (#) | TDepNum | Код подразделения |
| Ind | (#) | TIndexCase | Индекс дела |
| CountPart | TCount | Количество томов | |
| NameSase | TNameCases | Заглавие дела | |
| Period | TSave | Срок хранения | |
| PerNum | TPerNum | Номер статьи | |
| Info | TInfo | Примечание |
Таблица 2.7 – Структура таблицы «Дела» (CASES)
| Поле | Ключ | Тип | Описание поля |
| ID | # | TNumber | Код |
| Case_Num | TCaseNum | Номер дела | |
| Dep | (#) | TDepNum | Код подразделения |
| Ind | (#) | TIndexCase | Индекс дела |
| Case_Date | TDate | Дата формирования | |
| Case_Text | TCaseText | Короткое содержание |
Таблица 2.8 – Структура таблицы «Исходящая корреспонденция» (OUTCORS)
| Поле | Ключ | Тип | Описание поля |
| ID | # | TNumber | Код документа |
| Data1 | TDate | Дата отправления | |
| SendTo | TSender | Адресат | |
| Text | TSpravaText | Короткое содержание документа | |
| Dep | (#) | TDepNum | Код подразделения, где находится копия |
Таблица 2.9 – Структура таблицы «Исполнители» (EXECUTORS)
| Поле | Ключ | Тип | Описание поля |
| ID | # | TNumber | Код документа |
| Data1 | TDate | Дата отправления | |
| SendTo | TSender | Адресат | |
| Text | TSpravaText | Короткое содержание документа | |
| Dep | (#) | TDepNum | Код подразделения, где находится копия |
В спроектированной БД учитываются требования нормализации БД: поля неделимы, отсутствует дублирование информации, указаны ключи, однозначно определяющие запись и которые не являются избыточными, то есть значения ключевых полей уникальны для каждой записи.
Базы данных InterBase не имеют специальных типов для реализации полей-счетчиков. Поэтому автоматическая инициализация значений ключевых полей перечисленных таблиц осуществляется с помощью специальных генераторов, которые задействуются внутренними процедурами таблиц БД – триггерами.
Далее в таблице 2.10 перечислены задействованные генераторы и соответствующие триггеры. Начальные значения генераторов установлены в 0.
Таблица 2.10 – Список генераторов БД
| Генератор | Триггер | Таблица | Изменяемое поле |
| Gen_Departs_ID | Departs_BI | Departs | ID |
| Gen_InCors_ID | InCor_BI | InCors | ID |
| Gen_Decrees_ID | Decrees_BI | Decrees | ID |
| Gen_OutCors_ID | OutCors_BI | OutCors | ID |
| Gen_Cases_ID | Cases_ID | Cases | ID |
| Gen_TypeCases_ID | TypeCases_ID | TypeCases | ID |
| Gen_Executors_ID | Executors_BI | Executors | ID |
Отметим, что все триггеры выполняются перед добавлением записей в соответствующие таблицы.
Для оптимизации поиска документов требуемые поля проиндексированы.
2.3. Разработка структуры программного обеспечения
Взаимодействие пользователя с системой производится в диалоговом режиме. Основным соединительным элементом разрабатываемой АИС есть система меню, которая состоит из главного меню и подменю.
Функциональное меню автоматизированной системы представлено на рис. 2.5.

Технология внутримашинной организации определяется последовательностью реализованных процедур, схем взаимосвязей программных модулей и информационных массивов.
Указанные схемы представляют из себя декомпозицию общего процесса решения задачи на отдельные процедуры преобразования массивов, называемых модулями (ввод, контроль, перезапись информации с одного МН на другой, сортировка, сжатие данных, редактирование, вывод на печать, удаление и т.д.).
Основное предназначение разрабатываемой АИС – автоматизация документооборота в образовательном заведении.
Укрупненную функциональную схему программы можно представить следующими основными блоками (рис 2.6):

Текст программы объединяет несколько программных модулей, описание которых представлено в таблице 3.11.
Таблица 2.11 – Программные модули системы
| Модуль | Форма | Предназначение |
| UMain | FMain | Главный модуль. Реализация основных функций |
| USettings | FSettings | Инициализация начальных данных |
| UAccess | FAccess | Авторизация. Вход в систему |
| UExecutor | FExecutor | Справочник «Исполнители» |
| UContent | FContent | Вывод информации о программе |
| UAbout | FAbout | Вывод информации о разработчике |
Схема межмодульного взаимодействия представлено на рис. 2.7.

2.4. Разработка алгоритмов работы программного обеспечения
Работа с программой начинается с подключения клиентского приложения к БД. При этом пользователь с помощью стандартного диалога выбора может самостоятельно определить путь к файлу БД и зафиксировать его.
Автоматически с реестра системы загружаются данные о руководстве заведения, службе деловодства, о почтовом сервере. При необходимости эту информацию можно изменить.
Как указано выше, работа программы осуществляется в диалоговом и пошаговом режимах, при этом под диалогом понимается предоставление пользователю нескольких альтернатив и обработка его выбора.
Под событиями понимаются процессы, которые активизируются пользователем (например – нажатие функциональных клавиш), а также программные события – получение определенным полем фокуса редактирование или потеря фокуса ввода. На основании данных событий активизируются процедуры контроля допустимости данных.
Для понимания программной логики работы созданного приложения рассмотрим используемые глобальные переменные, процедуры, а также некоторые алгоритмы реализации функционала.
Глобальные переменные хранят значения на протяжении всего сеанса работы и доступны из других модулей.
Таблица 2.12 – Глобальные переменные
| Имя | Тип | Предназначение |
| PathProg | string | путь к папке приложения |
| PathDB | string | путь к БД приложения |
| tn | Array[1..1000] of integer | хранение идентификаторов записей с выборки |
| tn2, tn3 | Array[0..100] of string | хранение промежуточных данных с выборки |
| pwd | string | текущий пароль пользователя |
| DirectorName | string | Фамилия, отчество директора |
| Delovod | string | Фамилия, отчество деловода |
| SMTPSer | string | SMTP-сервер |
| Login | string | логин почтового ящика |
| Pass | string | пароль почтового ящика |
| A | integer | флаг результата авторизации |
Основные расчеты и визуализация данных выполняются пользовательскими процедурами и функциями, представленными ниже:
function TFMain.decoder(s:string):string – декодирование текстовой строки;
function TFMain.coder(s:string):string – кодирование текстовой строки;
procedure TFMain.SGZClear – очистка ячеек компонента TStringGrid;
procedure TFMain.Word1(s:string;a, b:OleVariant; var vstart, vend: OleVariant) – определение вхождения указанной строки в документ Word;
procedure TFMain.WordInsertText(Text: string) – вставка указанного текста в документ Word;
procedure TFMain.WordGotoBookmark(Bookmark: string) – переход в документе Word на указанную закладку;
procedure TFMain.WordInit(FileName:OleVariant) – инициализация сервер MS Word;
procedure TFMain.WordEnd(FileName:OleVariant) – отключение от сервера MS Word;
procedure TFMain.TableF(U:integer) – форматирование таблицы в документе Word;
procedure TFMain.Open1Click(Sender: TObject) – вход в систему, подключение к БД;
procedure TFMain.Close1Click(Sender: TObject) – завершение работы.
В разрабатываемой информационной системе для ввода, просмотра и распечатки отчетов с информацией базы данных применяются формы. Обработка таблиц осуществляется с помощью SQL-запросов, которые формируются и выполняются компонентом IBQuery1.
Далее представлен формат SQL-запросов для осуществления основных действий над БД.
Таблица 2.13 – SQL-запросы обработки данных
| Операция | SQL-команда |
| Добавление | insert into DEPARTS (Dep, Info) values (‘Подразделение 1‘, ‘——‘) |
| Редактирование | update DEPARTS set Dep = ‘Подразделение 1‘, Info = ‘——‘ where ID=1 |
| Выборка | select * from TYPECASES order by Dep, Ind |
Контроль достоверности информации в программе осуществляется на разных уровнях и на разных стадиях ее ввода. Он призван обеспечить отсутствие ошибок при вводе тех или иных данных, поддержку достоверности информации в процессе функционирования СУБД.
К средствам контроля относятся:
– задания входных данных, максимальных и минимальных значений, шаблонов для элементов ввода;
– контроль изменения информации при работе с ней и сообщение об изменении информации перед сохранением;
– использование кэширования данных;
– использование целостности связей;
– использование таблиц-справочников;
– ведение копий таблиц;
– отражение в справочной системе правил ввода информации;
– разграничение доступа пользователей к информации, фиксация пользователя, вводящего информацию.
Степень контроля информации в значительной степени зависит от степени важности используемой СУБД и от последствий, к которым могут привести ошибки. Слишком жесткий контроль может осложнит функционирование программного продукта, не дав ощутимого эффекта.
При разработке программного комплекса использован спектр средств, обеспечивающих программный контроль входной информации.
Так на уровне программного кода для ввода даты поступления или отправки документа, названия отправителя или адресата применен шаблон ввода, контролирующий также обязательность введения. Данные о подразделениях и индексы дел вводятся путем выбора из соответствующих справочников, при этом в больших справочниках интегрирована система поиска.
Перед выполнением операций изменения записей БД система проверяет корректность входных данных и требует подтверждения проведения операции.
При вводе данных у соответствующие компоненты, автоматически проверяется корректность их представления. Например, ввод числового значения сопровождается игнорированием всех символов, кроме цифр, десятичной точки и клавиши BackSpace. Также блокируется попытка повторного ввода десятичного разделителя. Указанные возможности реализуются событием KeyPress для компонентов ввода, текст кода которого приведен ниже:
var vrPos,vrLength,vrSelStart : byte;
const I : byte=1; //I+1 – количество знаков после точки
Begin
with Sender as TEdit do
begin
vrLength:=Length(Text); //определение длины текста
vrPos:=AnsiPos(‘.’, Text); //проверка наличия точки
vrSelStart:=SelStart; //определение положения
курсора
end;
case Key of
‘0’..’9′ : //проверка положения курсора и количества знаков после точки
іf (vrPos>0)and(vrLength-vrPos>I) and (vrSelStart>=vrPos)
then Key:=#0; //»погасить» клавишу
‘,’, ‘.’ : //блокировка повторного ввода точки
іf (vrPos>0) or (vrSelStart=0) or (vrLength=0)
then Key:=#0
else Key:=’.’; //замена запятой на точку
#8 : ; //реакция на клавишу ‘BackSpace’’
else Key := #0; //блокировка запрещенных символов
end;
End;
Также на уровне БД при формировании структуры таблиц определены поля, для которых при отсутствии ввода данных, определяется значение по умолчанию (например 0 для COUNT), или проверяется уникальность содержимого (ID, DEP).
Правильные связи между взаимосвязанными таблицами БД позволяют автоматически устанавливать и поддерживать организацию целостности связей (таблицы OUTCORS — DEPARTS т.д.).
Для запрета корректировки данных некоторых параметров использовано свойство ReadOnly для отдельных столбцов (DBGRID).
Ошибка в информации может возникнуть не только в результате ввода некорректных данных, но и в случае отсутствия сохранения кэшированной информации в соответствующих таблицах БД. По этой причине предусмотрен вывод сообщений об имеющихся изменений, или об намерении удаления записи. Для этого используются соответствующие стандартные диалоговые окна. Удаление же данных из таблиц физически доступно только одному человеку – администратор.
Корректность фиксации данных в БД также достигается за счет использования механизма транзакций – манипуляции с БД, которая переводит ее из одного целостного состояния в другое. Если одно из изменений, которое вносится в БД в рамках транзакции, завершается неудачно, производится откат до состояния БД, имевшего место до начала транзакции, то есть все изменения, внесенные в БД в рамках транзакции, или одновременно подтверждаются, или не подтверждается ни одно из них.
Если в рамках транзакции произошел сбой при выполнении одной из операций, автоматически отменяется результат выполнения всех других операций, иначе информация в БД будет недостоверной. Например, если из таблицы «ПОДРАЗДЕЛЕНИЯ» изъять запись, и при этом не выполнять никаких манипуляций над таблицей исходящей корреспонденции, будем иметь «зависшие» данные в последней таблице.
2.5. Руководство пользователя программного обеспечения
2.5.1. Установка приложения на ПК
Установка приложения производится простым копированием дистрибютивной папки ZAUCH с носителя на жесткий диск ПК.
Ниже приведена файловая структура дистрибютива:
| PZauch.exe Zauch.ini
Zauch.fdb content.rtf blank.doc dep.doc cases.doc type_case.doc rep1.doc rep2.doc rep3.doc | – –
– – – – – – – – – | исполняемый файл программы файл, содержащий путь к БД системы и данные начальной инициализации; файл базы данных; текст справки шаблон фирменного бланка шаблон бланка отчета по подразделениям шаблон бланка дела шаблон бланка отчета по типам дел шаблон общего отчета по документам шаблон отчета о категориях и количестве дел шаблон отчета по делам |
Предварительно, необходимо установить и загрузить сервер БД Firebird. Скачать дистрибютив указанного сервера БД можно по адресу: http://www.firebirdsql.org/en/downloads/
2.5.2. Настройка подключения к БД и вход в систему
При первом запуске программы следует настроить связь с БД. Подпункт “Настройка” пункта “Файл” главного меню программы активизирует форму подключения к БД (рис. 3.4).
Путь к серверной БД формируется через использование сетевого протокола, формат строки ТСР/ІР которого следующий:
<HOST>:<Local Path\Zauch.gdb>, (3.1)
где HOST – имя хоста (сервера),
Local Path – локальный путь к БД в файловой системе.
Например, COMP1:D:\Zauch\Zauch.fdb
Имя хоста (IP-адрес сервера) можно получить у администратора сети.
Иногда между именем сервера и файловым путем к БД следует ставить ‘\’.
Например, COMP1:\D:\Zauch\Zauch.fdb

Если С и БД установлены на одном ПК, то в качестве сетевого имени хоста используют локальный адрес («заглушка») localhost с ІР-адресом 127.0.0.1.
При наличии сети из двух машин, соединенных кросовым кабелем, то можно выбрать любой IP-адрес для сервера (кроме 127.0.0.1) и IP-адрес для клиентского ПК.
Для ускорения соединения с БД в файл hosts необходимо внести следующую запись: <host> <IP-адреса>. Например, localhost 127.0.0.1
В Windows NT2000 файл HOSTS размещается в C:\WINNT\system32\drivers\etc\, а в Windows 95/98/ME/XP/Server2003 – в C:\Windows.
Строку ТСР/ІР соединения можно построить, вызвав соответствующее диалоговое окно:

После правильного ввода пути к БД, его следует сохранить с помощью кнопки “Сохранить”. Путь к БД сохраняется в файле Zauch.ini в текущем каталоге программы.
Система защищена программным образом и ее активизация происходит после ввода пароля в соответствующее поле:

2.5.3. Работа в среде АИС «Учет документов»
Взаимодействие пользователя с системой производится в диалоговом режиме, то есть разработанная система есть меню-ориентированной.
Внешний вид главной формы программы приведен на рис. 2.11.

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

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

Информация о программе вызывается после нажатия горячей клавиши «F1». Завершается работа с программным приложением после выбора подпункта «Завершить» пункта «Файл» главного меню.
