XIII Международная студенческая научная конференция Студенческий научный форум - 2021

Ядром любой базы данных является модель данных. С помощью модели данных могут быть представлены объекты предметной области и взаимосвязи между ними [5].

Модель данных – это совокупность структур данных и операций их обработки. Рассмотрим три основных типа моделей данных: иерархическую, сетевую и реляционную [31].

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

К основным понятиям иерархической структуры относятся уровень, узел и связь. Узел – это совокупность атрибутов данных, описывающих некоторый объект. На схеме иерархического дерева узлы представляются вершинами графа. Каждый узел на более низком уровне связан только с одним узлом, находящимся на более высоком уровне. Иерархическое дерево имеет только одну вершину, не подчиненную никакой другой вершине и находящуюся на самом верхнем - первом уровне. Зависимые (подчиненные) узлы находятся на втором, третьем и т. д. уровнях. Количество деревьев в базе данных определяется числом корневых записей. К каждой записи базы данных существует только один иерархический путь от корневой записи [20].

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

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

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

Для разработки сервиса автоматизации процесса выполнения гарантийного сервиса салона сотовой связи была выбрана реляционная модель данных. Это обусловлено несколькими причинами:

условия на программное обеспечение: для наших целей лучше всего подходит СУБД MySQL, которая работает с реляционными базамиданных;

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

Так как объем работ непосредственно с базой невелик (на клиенте – доступ к базе имеет только один пользователь, на сервере – производится обработка уже извлеченных данных), то предпочтение было отдано удобству работы с базой (реляционная модель), а не скорости доступа к данным (иерархическая, сетевая модель).

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

Рисунок 1 – Схема данных клиентской части сервиса

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

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

На рисунке 2 приведено дерево функций клиентской части проектируемого сервиса.

Рисунок 2 – Дерево функций клиентской части сервиса

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

Рисунок 3 – Сценарий диалога с пользователем клиентской части

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

В качестве средства разработки БД будет использована реляционная система управления базами данных «MySQL» [28].

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

В таблицах 1-6 приведена физическая реализация модели данных. Указаны названия проектируемых сущностей, атрибуты и их тип данных, формат полей, описание полей и выделены ключевые поля для клиентской части сервиса. Далее следуют две таблицы 7-8, описывающие БД серверной части сервиса.

Таблица 1 – Сущность «Ветвь»

Ключ	Имя поля	Тип данных	Формат	Описание
PK	Код	Счетчик	Длинное целое	Ключевое поле
	Имя	Текстовый	255	Название ветви дерева решений

Таблица 2 – Сущность «Блок»

Ключ	Имя поля	Тип данных	Формат	Описание
PK	Код	Счетчик	Длинное целое	Ключевое поле
	Ветвь	Текстовый	255	Название ветви дерева решений
	Стартовый	Логический		Показывается когда пользователь подпи- сывается набота
	Ссылка	Текстовый	50	По этой ссылке осу- ществляется переход на блок в чате Viber
FK	Тип	Числовой	Длинное целое	Тип блока из справоч- ника «ТипБлока»

Таблица 3 – Сущность «Сообщение»

Ключ	Имя поля	Тип данных	Формат	Описание
PK	Код	Счетчик	Длинное целое	Ключевое поле
FK	Блок	Числовой	Длинное целое	Блок, к которомуотносится сообщение
FK	Тип	Числовой	Длинное целое	Тип сообщения из справочника «ТипСообщения»
	Текст	Поле MEMO		Текст сообщения, который видит пользователь

Таблица 4 – Сущность «Ответ»

Ключ	Имя поля	Тип данных	Формат	Описание
PK	Код	Счетчик	Длинное целое	Ключевое поле
FK	Блок	Числовой	Длинное целое	Ссылка на блок
	Текст	Текстовый	255	Вариант ответа клиента
FK	Ссылка	Числовой	Длинное целое	Ссылка на блок, к которому будет осуществлен переход

Таблица 5 – Сущность «Настройки»

Ключ	Имя поля	Тип данных	Формат	Описание
PK	Имя	Текстовый	20	Название параметра
	Значение	Текстовый	255	Значение параметра

Таблица 6 – Сущность «ТипБлока»

Ключ	Имя поля	Тип данных	Формат	Описание
PK	Код	Числовой	Длинное целое	Ключевое поле
	Название	Текстовый	50	Название типа блока

Таблица 6 – Сущность «ТипСообщения»

Ключ	Имя поля	Тип данных	Формат	Описание
PK	Код	Числовой	Длинное целое	Ключевое поле
	Название	Текстовый	50	Название типа сообщения дляклиентской части
	Форма с сайта	Текстовый	50	Название типа как оно

Таблица 7 – User

Ключ	Имя поля	Тип данных	Формат	Описание
PK	id	Числовой	Длинное целое	Ключевое поле
	forma_id	Текстовый	50	Идентификатор пользователя,присвоенный в форме сайта
	field	Текстовый	50	Имя поля, в которое будет записан пользовательский ввод
	next			Имя блока для перехода

Таблица 8 - Data

Ключ	Имя поля	Тип данных	Формат	Описание
PK	id	Числовой	Длинное целое	Ключевое поле
FK	user	Числовой	Длинное целое	Идентификатор пользователя
	field	Текстовый	50	Имя поля
	value	Текстовый	50	Значение поля

Первичные данные вводятся в клиентскую часть сервиса с помощью экранных форм и напрямую в таблицы. Экранные формы и сами таблицы клиентской части – изображены на рисунках 4 и 5, а также части сотрудника на рисунках 6 – 9.

Рисунок 4 – Форма «Оставить заявку»

Клиент вводит данные и жмет кнопку «Оставить заявку». После нажатия кнопки «Оставить заявку» выполняется переход на вкладку «Отследить ремонт» с выводом номера заявки в правом верхнем углу, которая была создана. В случае если было создано несколько заявок на этот номер телефона, отобразятся все заявки по этому номеру, смотреть рисунок 5.

Рисунок 5 – Форма «Отследить ремонт»

Часть сотрудника. Для входа на сайт как администратор необходимо авторизоваться на сайте как сотрудник, ввести логин и пароль. Форма авторизации пользователя показана на рисунке 6.

Рисунок 6 – Авторизация сотрудника

Далее после удачной авторизации появится новая вкладка «Просмотреть запросы» при переходе в данную вкладку открывает весь список запрос на данный момент, смотреть рисунок 7.

Рисунок 7 – Просмотр запросов

Чтобы открыть подэкран редактирования заявки нужно кликнуть на нее один раз ЛКМ. На этом подэкране заполняются данные о заявке со стороны сотрудника. Исполнителем заявки становится сотрудник, который авторизовался и обработал заявку. Если заявку обработали, то в отслеживании заявки отображается ее исполнитель, смотреть рисунок 8.

Рисунок 8 – Форма редактирования заявки

Также присутствует возможность выгрузки в Excel за необходимый период, сотрудник выгружает только свои заявки (которые он обработал), администратор может выгрузить как заявки как по всем сотрудникам, так и по определенному сотруднику, смотреть рисунок 9.

Рисунок 9 – Выгрузка в Excel

Так же можно посмотреть список имеющихся сотрудников на рисунке 10 (поле role отвечает кто зашел, админ или простой сотрудник).

Рисунок 10 – Список сотрудников

Выходные документы серверной части зависят от выбранной системы и передаваемых в нее данных о пользователе.

В результате был разработан сервис автоматизации обработки заявок клиентов по гарантийному сервису в салоне сотовой связи.

Код для цитирования: Скопировать