79
kod_sotr. Поле является первичным ключом и содержит код
сотрудника для связи с таблицами zaiavki и chat.
fio. ФИО сотрудника.
dolgnost. Должность сотрудника в отделе.
telefon. Городской телефонный номер с кодом города.
e-mail. Адрес электронной почты.
login. Логин сотрудника для авторизации в системе. Заводится
администратором системы.
password. Пароль сотрудника как пользователя в системе.
status_sotr. Статус пользователя. Либо администратор, либо оператор,
либо технический специалист Выбор жестко фиксирован в
программном коде.
Рассмотрим состав оперативной информации.
Для хранения и обработки оперативной информации в базе данных
tehsupport предназначены две таблицы "zaiavki" и "chat" В таблице " zaiavki"
создаются и хранятся все заявки на обслуживание. Реквизитный состав
следующий:
kod_sotr. Код сотрудника, который создает заявку.
kod_sotr_support. Код сотрудника, который закрывает заявку.
kod_zaiavki. Код заявки. Первичный ключ.
krat_name. Краткое наименование заявки.
opis. Подробное описание проблемы.
status. Статус заявки (Открыта, в работе, закрыта).
date_open. Дата создания заявки.
date_close. Дата закрытия заявки.
job. Описание работы, что было сделано. Заполняется техническим
специалистом, закрывающим заявку.
80
В таблице chat ведется переписка по заявкам, находящимся в статусе "В
работе".
Реквизиты таблицы следующие:
kod_zaiavki. Код заявки, внешний ключ.
kod_message_. Код сообщения. Первичный ключ.
kod_sotr. Код сотрудника, написавшего сообщение.
message_. Сообщение.
status_operat. Статус (прочтено, не прочтено) сообщений от
оператора, адресованных техническому специалисту.
status_tehsupport. Статус сообщений от технического специалиста,
адресованных оператору.
Поскольку система предназначена для обмена электронными заявками
внутри всей организационной структуры, то входные документы для ввода
информации в программу отсутствуют.
81
2.3.3. Характеристика результатной информации
Результатная информация характеризуется выполнением запросов к
базе данных.
Запрос — это выборка из таблиц базы данных.
В проекте имеется несколько запросов, представленных командой
SELECT. Еще один вид запросов представляет собой метод фильтрации уже
извлеченных данных, с помощью команды SELECT.
Рассмотрим запросы, применяемые для формирования наборов данных:
Для формирования набора данных, предназначенного для авторизации в
системе предназначена выборка:
SELECT kod_sotr, fio, dolgnost, login, password, status_sotr FROM sotr
Здесь, для формирования выборки используется одна таблица "sotr".
Для заполнения информацией таблиц "Отделы" и "Сотрудники"
предназначена форма "Сотрудники" (см. Приложение 2). Для работы данной
формы применяется два набора данных.
Первый набор данных формируется на основе запроса всех полей из
таблицы "otdel":
SELECT * FROM otdel
Второй набор данных извлекает информацию из таблицы "sotr" Выборка
так же содержит все поля таблицы. Но на данную выборку накладывается
ограничение в виде условия, где поле "kod_otdela" должно быть равно
переменной. В качестве переменной в запросах применяются параметры и
такие запросы называются параметрическими. Параметр обрамляется знаком
":"
SELECT * from sotr
WHERE kod_otdela=:kod_otdela
82
Параметр равен названию поля первого набора данных. Таким образом,
средствами Delphi через использование двух наборов данных создается связка
master-detail между двумя таблицами базы данных.
В результате работы двух запросов во втором наборе данных будут
содержаться только те записи, код отдела которых соответствует текущему
коду отдела в родительской (справочной) таблице. В данной связке
родительской таблицей является "otdel", а подчиненной "sotr", поскольку в
одном отделе может быть множество сотрудников.
Для просмотра и редактирования заявок из личного кабинета оператора
применяется параметрический запрос:
SELECT * FROM zaiavki WHERE kod_sotr=:kodsotr
В качестве параметра данного запроса используется :kodsotr,
представляющий из себя код сотрудника, который совершал авторизацию в
системе. Параметру присваивается глобальная переменная iKodSotr,
объявленная в модуле mdi формы.
Для работы с чатом применяется запрос, содержащий информацию из
двух таблиц, объединенных по полю "kod_sotr".
SELECT
chat.kod_zaiavki,
chat.kod_message_,
chat.message_,
chat.status_operat,
chat.status_tehsupport,
sotr.fio
FROM chat
INNER JOIN sotr
ON chat.kod_sotr = sotr.kod_sotr
WHERE chat.kod_zaiavki = :kod_zaiavki
order by kod_message_
В личном кабинете сотрудника технического специалиста заявки можно
только просматривать. Запрос на получение информации из базы данных
выглядит следующим образом:
83
SELECT
zaiavki.date_open,
zaiavki.krat_name,
sotr.fio,
otdel.name_otdela,
zaiavki.status,
zaiavki.date_close,
zaiavki.kod_sotr,
zaiavki.kod_sotr_support,
zaiavki.kod_zaiavki,
zaiavki.opis,
zaiavki.job
FROM zaiavki
INNER JOIN sotr
ON zaiavki.kod_sotr = sotr.kod_sotr
INNER JOIN otdel
ON sotr.kod_otdela = otdel.kod_otdela
ORDER BY zaiavki.kod_zaiavki
Запрос представляет из себя выборку из трех таблиц: zaiavki, sotr, otdel.
Для того, чтобы произвести выборку из уже полученного набора данных
(выборки первого уровня), следует на полученный набор наложить
дополнительный фильтр:
ADOQuery1.Filtered:=false;
ADOQuery1.Filter:= krat_name '+ ' LIKE ' + #39 + '%' + txtFind.Text + '%' + #39;
ADOQuery1.Filtered:=true;
Здесь происходит фильтрация данных по полю набора данных (не
физической таблицы) "Отправитель". Фильтрация ведется по неполному
ключу, для чего предназначен оператор LIKE.
Для осуществления фильтрации по теме письма, применяется фильтр:
ADOQuery1.Filtered:=false;
ADOQuery1.Filter:=' fio '+ ' LIKE ' + #39 + '%' + txtFind.Text + '%' + #39;
ADOQuery1.Filtered:=true;
Для фильтрации по регистрационному номеру письма:
ADOQuery1.Filtered:=false;
84
ADOQuery1.Filter:= status '+ ' LIKE ' + #39 + '%' + txtFind.Text + '%' + #39;
ADOQuery1.Filtered:=true;
Для фильтрации по диапазону дат зарегистрированного письма:
ADOQuery1.Filtered:=false;
ADOQuery1.Filter:= 'date_open>='+Date1+' and '+'date_open<='+Date2;
ADOQuery1.Filtered:=true;
Следует отметить, что отчеты формируются на основе полученного
набора данных с учетом или без учета фильтров. Выборка для получения
набора данных выглядит как многотабличный запрос к базе данных:
SELECT zaiavki.date_open, zaiavki.krat_name, sotr.fio, otdel.name_otdela,
zaiavki.status, zaiavki.date_close, zaiavki.kod_sotr,
zaiavki.kod_sotr_support,
zaiavki.kod_zaiavki, zaiavki.opis, zaiavki.job
FROM zaiavki INNER JOIN sotr ON zaiavki.kod_sotr = sotr.kod_sotr
INNER JOIN otdel ON sotr.kod_otdela = otdel.kod_otdela
where zaiavki.status="Открыта"
order by zaiavki.date_open
85
2.4. Программное обеспечение задачи
2.4.1. Общие положения (дерево функций и сценарий диалога)
Рисунок 11. Дерево функций
Дерево функций представлено на рисунке 11.
86
Сценарий диалога для администратора, специалиста службы
технической поддержки и оператора выглядит по-разному. Причем, сценарий
диалога специалиста технической поддержки и оператора одинаковы.
Рассмотрим сначала сценарий диалога для учетной записи
администратора. Он показан на рисунке 12.
Рисунок 12. Сценарий диалога учетной записи администратора
Пункт меню "Администрирование" вызывает подменю, в котором есть
пункт "Сотрудники". Этот пункт, в свою очередь, вызывает одноименное
окно, в котором администратор добавляет отделы и сотрудников в отделах.
Окно представлено в приложении 2.
Пункт меню "Личный кабинет оператора" вызывает одноименное окно
для добавления, удаления и редактирования заявок от имени Администратора.
Данное диалоговое окно представлено в приложении 3.
Пункт меню "Личный кабинет технического специалиста" вызывает
окно для работы с заявками операторов. Вид окна представлен в приложении
4.
Окно "Смена пользователя" вызывает окно для авторизации.
87
Рисунок 13. Сценарий диалога учетной записи оператора и
технического специалиста
Сценарий диалога оператора отличается отсутствием пунктов меню
"Администрирование", "Личный кабинет оператора" и "Личный кабинет
технического специалиста". Вместо этого в главном меню присутствует пункт
"Личный кабинет" и он вызывает окно либо оператора, либо технического
специалиста в зависимости от того, под какой учетной записью был выполнен
вход в систему. Он показан на рисунке 13.
88
2.4.2. Характеристика базы данных
Проектирование базы данных для службы технической поддержки
осуществлялось в MySQL Workbench 5.2.
Работа с данным графическим клиентом начинается с формирования
локальной модели базы данных, так называемой ER-модели. Это не
физическая база данных, а виртуальная схема с полями и связями между
таблицами по ключевым полям, а также другими элементами базы данных.
После построения модели базы данных необходимо сформировать
скрипт на языке SQL. Данный скрипт можно сохранить в файл. Смысл в
данной операции в том, чтобы не набирать команды вручную. Графическое
проектирование в значительной степени экономит время и уменьшает
вероятность ошибок.
Следующим этапом будет являться формирование физической базы
данных на основании созданной модели. Структура таблиц базы данных
представлена в таблице7.
Таблица 7
Структура таблиц базы данных
Идентификатор поля
Описание поля
Тип поля
Размер
поля
Значен
ие по
умолча
нию
Условие на
значение
Ключ
или
индекс
otdel (Отделы)
kod_otdela
Код отдела
INT
Счетчик
Уникальное
NOT NULL
ПК,
Индекс
name_otdela
Название отдела
VARCHAR
150
NOT NULL
sotr (Сотрудники)
kod_otdela
Код отдела
INT
NOT NULL
kod_sotr
Код сотрудника
INT
Счетчик
Уникальное
NOT NULL
ПК,
Индекс
fio
ФИО
VARCHAR
100
NOT NULL
dolgnost
Должность
VARCHAR
100
NOT NULL
telefon
Телефон
VARCHAR
255
e-mail
Электронная
почта
VARCHAR
100
NOT NULL