44
После создаются хранимые процедуры, которые будут обрабатывать
данные. Эти процедуры также создаются или изменяются во время разра-
ботки программного обеспечения, по мере выяснения необходимости в них.
Одним из важнейших шагов при разработке базы данных, является
установка связей между данными, они могут хранится в нескольких табли-
цах, но быть взаимосвязанными. Примером таких данных, может послужить
информация о проектах.
Так в нашем случае проект объединяет все таблицы разрабатываемой
базы данных. Таблица проектов связана с таблицей пользователей - эта связь
указывает на то, кто из пользователей создал проект и кто контролирует его
выполнение, связь осуществляется напрямую, указанием уникального
ключа пользователя. Связь с таблицей прикреплённых данных, осуществля-
ется указанием уникального номера проекта, для файлов хранящихся в таб-
лице файлов, эта связь отличается от предыдущего примера, в этом случае
таблица файлов хранит ссылку на проект. Связь таблицы проектов и таб-
лицы связи, аналогично с таблицей файлов. И наконец связь с таблицей за-
дач, осуществляется не напрямую, а через таблицу связи. Таким образом об-
разуется взаимосвязь, которая позволяет однозначно идентифицировать
данные, которые являются составной частью проекта.
Эти связи закладываются при проектировке базы. Иначе сложность
установления однозначной принадлежности одних данных к другим, будет
или очень сложной задачей, или просто невозможно будет установить эту
связь
В нашем случае не использовались представления, которые служат
для отображения данных в виде, которые более информативны для воспри-
ятия человеком. Например, вместо числового идентификатор пользователя
можно отобразить его фамилию, имя и отчество и ещё какие-либо данные.
Хранимые процедуры, которые будут использоваться для обработки
данных и вывода их для отображения. Работа хранимых процедур позволяет
45
более гибко и мощно использовать сервер баз данных, а так как они ском-
пилированы, то они выполняются быстрее чем стандартные запросы.
Разберём их использование в нашей базе, в ней созданы на этапе раз-
работки три хранимые процедуры (таблица 13).
Таблица 13 – Хранимые процедуры СУБД
Название хранимой
процедуры
Роль хранимой процедуры
SEL_USER
выводит фамилию, имя и отчество пользователя одной стро-
кой, по его уникальному ключу
USER_LIST
выводит фамилии, имена и отчества пользователей, активных
пользователей одной строкой, также выводятся соответствую-
щие этим пользователям уникальные ключи
MY
подготавливает данные для отображения в виде дерева. Выве-
сти эти данные другим способом намного сложнее, так как эти
данные хранятся в разных таблицах и требуют обработки перед
выводом.
Алгоритм подготовки данных используется следующий:
- в зависимости от того, кто хочет получить данные (создатель проекта
или сотрудник контролирующий выполнение), формируются данные о про-
ектах (номер проекта, данные о проекте в виде строки содержащей часть
данных и уровень в иерархической структуре (для проектов это 0);
- в зависимости от получающего данные, получаем данные о проектах
и задачах как промежуточные данные;
- по промежуточной информации, формируем данные о задачах, ука-
зывая номер задачи, как уровень в иерархии.
Таким образом при помощи специальных компонентов можно постро-
ить структуру, в которой эти данные будут выводится в виде дерева, в корне
которого будут проекты.
Итак, первоначальная подготовка к разработке системы календарного
планирования окончена, но в процессе разработки, а также эксплуатации,
возникает потребность во внесении дополнительных данных, создания
46
представлений, хранимых процедур и другой доработке базы данных. Так
как запросы к базе создаются на этапе разработки или доработки программ-
ного обеспечения, то потребность базы в индексах может меняться и их мо-
гут удалять, или создавать новые. В зависимости от того, каким образом бу-
дет происходить отбор необходимых для работы данных.
В результате должна получиться следующая база данных (рисунок 8).
Рисунок 8 - Структура базы данных в среде разработки IB Expert
Этап разработки базы данных очень важен и допускать ошибки на
этом шаге нежелательно, так как множественные изменения в структуре
базы могут привести к большим объёмам доработок или изменений в про-
грамме, использующей дорабатываемую базу. Внесение изменений в базу
данных на этапе эксплуатации должен быть очень аккуратен, иначе может
получиться так, что программа не сможет получать, записывать или изме-
нять данные.
47
3.3. Разработка приложения
Работать непосредственно с базой данных сотрудники не могут, по-
этому для работы используются приложения, которые отображают инфор-
мацию и позволяют в удобной для человека форме вносить удалять и изме-
нять хранящуюся в базе информацию. Также приложение может позволить
выполнять множество других функций, которые будут заложены в него,
например, выгрузка данных из базы с последующим сохранением их в файл
(файлы), какого-либо формата. Так же программа может осуществлять кон-
троль над доступом к хранимым данным, это может быть ограничение как
на таблицы, так и на конкретные поля внутри таблиц. Ограничить доступ к
этим данным другими способами, не представляется возможным, особенно
при интенсивно используемой базе, в которую вносятся множество данных.
Первым шагом в нашем случае будет установка и настройка среды
разработки, в нашем случае это Embarcadero Delphi XE 10.2. После этого
устанавливаются дополнительные компоненты и библиотеки, Eh Lib
Standard, JEDI Visual Component Library и Fib Plus. Инструкций для уста-
новки различных компонентов существует множество, поэтому процесс их
установки рассматривать не будем.
СУБД Firebird 3 была установлена ранее, здесь рассмотрим только из-
менение её настроек, которые позволят подключаться разрабатываемой
программе к базе данных. В файл настроек СУБД "firebird.conf" необходимо
внести некоторые изменения, дописываем в этот файл следующие строки:
ServerMode = Super
AuthServer = Legacy_Auth,Srp
WireCrypt = enabled
Первая строка, режим работы Firebird 3, вторая режимы аутентифика-
ции и порядок их использования, а третья это включение или отключение
режима шифрования при передаче данных. Основная проблема из-за чего
48
приходится настраивать СУБД, это изменение именно в режиме аутентифи-
кации, которое может не позволить подключиться нашему ПО к базе дан-
ных.
Внешний вид программы взят уже из скомпилированной программы,
для того чтобы не загромождать рисунки неотображаемыми компонентами.
Один из самых ответственных этапов разработки любой программы -
это создание интерфейса который будет использоваться при работе пользо-
вателями. Часто этим занимаются целые команды дизайнеров интерфейсов,
в нашем случае это выяснялось в ходе обсуждений с теми, кто будет непо-
средственно пользоваться программой. Какова бы не была хороша про-
грамма, но если её использование сопряжено с большими трудностями, то
от неё могут отказаться.
Первая форма, которая создаётся, это главная форма программы, но
разработка внешнего вида и функционала, начинается с формы ввода логина
и пароля (рисунок 9).
Рисунок 9 - Форма аутентификации пользователя
После ввода логина и пароля и нажатия на кнопку "Принять", необхо-
димо каким-либо образом сравнить пару логин и пароль. Если для данного
логина пароль не верен, то не главная форма не запускается, а если отменить
ввод - программа полностью закрывается.
49
На данный момент логины и пароли хранятся в базе в открытом виде,
но это не совсем правильно и в дальнейшем необходимо будет хранить па-
роли в зашифрованном виде. Такой подход обусловлен тем, что при разра-
ботке часто приходится вводить данные в ручном режиме (например, со-
здать пользователя).
В нашем случае было решено использовать для отображения инфор-
мации закладки (рисунок 10).
Рисунок 10 - Внешний вид программы планирования
Каждый вид информации, будет размещён на своей закладке, а дальше
может разделяться по тому, как относится данная информация к сотруд-
нику, является ли он ее создателем, контролирует или выполняет.
На закладках для задач данные будем представлять в виде таблиц, на
верхней список задач, а ниже подробная информация о выделенной задаче.
Заполнение верхней таблицы, выполняется запросом, результат которого
отображается на экране.
Для заполнения нижней таблицы необходимо знать какая именно за-
дача активна в данный момент, для этого будем использовать событие After
50
Scroll, которое вызывается всякий раз, при смене строки данных. При этом
событии считываем номер задачи и делаем запрос к базе, для того чтобы
получить подробную информацию о задаче и отобразить её в нижней таб-
лице.
А так как для каждой закладки используется свой набор подключения
к данным, то при переходе от одной закладки к другой, подключение не те-
ряется, и нет необходимости менять запрос к базе. Использование парамет-
ризованных запросов снижает нагрузку на СУБД.
Таким образом наиболее необходимая информация, может быть полу-
чена очень быстро и легко можно переключаться между различными ви-
дами информации, получение которой, не так сильно влияет на производи-
тельность СУБД, как если бы запросы менялось во время выполнения про-
граммы.
Теперь рассмотрим - как будем располагать данные на экране и какие
формы будут использоваться для ввода и редактирования данных.
На верхней панели расположены кнопки, которые будут открывать
нужный раздел. На боковой панели каждой закладки располагаются
надписи, к которым привяжутся различные операции. При нажатии на «Со-
здать задачу» будет отображается окно, в котором должен происходить про-
цесс заполнение данных по новой задаче.
При создании и редактировании задачи, исполнитель и контролирую-
щий сотрудник, должны выбираться из списков в которых будут отобра-
жаться активные сотрудники. Должен происходить выбор даты и времени
начала выполнения и даты и времени, до которого сотрудник должен вы-
полнить данную задачу. Необходимо будет ввести наименование задачи и
если надо уточнить - как и что должно выполняться, то ввести дополнитель-
ные данные. Данные создателя задачи не должны редактироваться (рисунок
11).
51
Рисунок 11 - Окно создания и редактирования задачи
Созданные задачи должны отображаться на закладке "Мои задачи", а
у тех, кто должен контролировать или выполнять, на соответствующих за-
кладках. Такое разделение вызвано тем, что данные не смешиваются между
собой и сотрудник чётко знает. что ему необходимо делать, а также для каж-
дой закладки проще реализовать операции которые будут выполнятся над
задачами. Так для текущих задач сотрудника требуется только завершение,
а для тех ход которых необходимо контролировать, после проверки требу-
ется подтвердить её выполнение.
На данный момент, по техническому заданию, редактировать или уда-
лить задачу, может только тот, кто её создал. Но в дальнейшем не исключа-
ется возможность изменения задач сотрудником, контролирующим их вы-
полнение, например, для изменения сроков выполнения.
Эффективней контролировать процесс при помощи проектов, кото-
рые могут объединять в себе множество задач. Проект создаётся следую-
щим образом:
- создаются задачи с назначением исполнителей и контролёров;
52
- создаётся проект;
- в проект добавляются задачи, при необходимости прикрепляются
файлы.
Форма создания проекта представлена на рисунке 12.
Рисунок 12 - Форма создания и редактирования задач
Форма создания проекта отличается от формы создания задач, это
обусловлено тем, что в проекте может содержаться произвольное количе-
ство данных
Для добавления задач в проект, необходимо нажать на кнопку под
надписью "Список задач", после чего откроется форма (рисунок 13), на ко-
торой расположен перечень задач, не вошедших в проекты.
53
Рисунок 13 - Форма выбора задачи, для добавления в проект
Также можно исключить задачи из проекта, выделив требуемую за-
дачу и нажав кнопку удаления. Одна и та же задача не может входить в
несколько проектов.
Такой порядок работы выбран для того, чтобы можно было распреде-
лить создание проекта между несколькими сотрудниками, которые подго-
товят задачи, документы, а потом один сотрудник всё может объединить все
заранее подготовленные данные в один проект.
Контролирующий сотрудник не может изменить или удалить проект,
эти функции доступны создателю проекта, а он может только завершить вы-
полнение проекта, эта функция активируется только тогда, когда все задачи
завершены.
Списки проектов и входящих в них задач выполнены в виде иерархи-
ческого раскрывающегося списка.
Это позволяет отобразить или скрыть информацию о задачах (рисунок
14).