3.2. Моделирование процесса обработки заявки на размещение рекламного объявления в печатных изданиях. Модель TO-BE
Для того чтобы наглядно представить процесс, который будет осуществляться после проектирования и ввода информационной системы, необходимо смоделировать этот процесс, т.е. наглядно его представить в виде диаграммы.
На рис. 3.1 представлена диаграмма процесса обработки заявки на размещение рекламного объявления с учетом произошедших при вводе информационной системы изменений. Информационная система, введенная в усовершенствованной модели, позволит учесть все недостатки, выявленные ранее в предыдущей модели.
Внедрение данной информационной системы позволит упростить работу редакционного коллектива издательства, ускорить процесс осуществления консультации за счет сочетания в себе необходимого функционала, позволит рассчитать стоимость выбранных спецификаций рекламного объявления, оформить заявку, назначить ответственного за ходом выполнения работ руководителя в соответствии с данными загруженности работников, а также предоставит возможность отслеживать статус заявки.
Процесс обработки заявки на размещение рекламного объявления
На рис. 3.2 представлена декомпозированная модель процесса обработки заявки на размещение рекламного объявления после ввода информационной системы. На данном этапе произошли изменения по сравнению с моделью AS-IS изображенной на рис.1.4. Поскольку внедряемая информационная система содержит полный перечень данных необходимых для оформления заявки, а также стоимость услуг, оператор отдела рекламы, анализируя намерения клиента, вводит данные и оформляет заявку непосредственно в системе, поэтому два этапа – анализировать намерения клиента и оформить заявку, — объединены в один.
В результате процесс, изображенный на рис. 3.2. состоит из следующих этапов:
- анализировать намерения и оформить заявку;
- рассмотреть заявку;
- подготовить объявление к публикации;
- отправить в типографию.
На рис. 3.3 представлена декомпозиция блока «Анализировать намерения и оформить заявку», которая состоит из 7 этапов:
- проконсультировать и проинформировать потенциального клиента: дать краткую характеристику деятельности издательства, предоставить обзор текущего состояния рынка рекламы, его области развития, конкуренции, объема, структуры, особенностей, а также информирование по перечню услуг и специальных предложений, предоставляемых издательством;
- сформировать перечень услуг: ознакомившись с прейскурантом, возможными скидками и наценками на размещение объявлений, клиент останавливает свой выбор на издании, задает приоритет и параметры для объявления;
- рассчитать стоимость услуг: оператор задает перечень услуг, в результате которого формируется стоимость, в случаях, если клиента не устраивает выведенная на экран монитора цена, данные корректируются за счет выбора сопоставимых по функциям, но более демократичных в цене услуг размещения. После корректировки перечня услуг структура цены запрашивается вновь;
- принять платеж: после урегулирования разногласий и в случае готовности клиента к сотрудничеству услуги оплачиваются. Бухгалтер формирует квитанцию об оплате, с которой клиент возвращается к оператору отдела рекламы;
- согласовать условия сделки: после получения оператором квитанции об оплате услуг, составляется договор о намерениях, в котором подробно отражены условия и сроки договора, обязательства и ответственность сторон, конфиденциальность, гарантии, возмещение убытков и тд.;
- зарегистрировать и закрепить клиента за руководителем: клиент регистрируется путем фиксирования всех необходимых данных для дальнейшего информирования. За клиентом закрепляется руководитель исходя из загруженности;
- оформить заявку: заявка составляется исходя из внесенных ранее данных в систему.
3.3. Моделирование движения потоков данных в процессе обработки заявки на размещение рекламного объявления. Модель TO-BE
Для того чтобы лучше рассмотреть процесс, который будет осуществляться после проектирования и ввода информационной системы необходимо смоделировать контекстную DFD-диаграмму, рис. 3.4.
На DFD-диаграмме изображены следующие элементы:
- Функциональные блоки. Представленная диаграмма, содержит только один функциональный блок, – «Обработка заявки на размещение рекламного объявления».
- Внешние сущности. В качестве внешних сущностей выбраны «Клиент», «Оператор отдела рекламы», «Бухгалтер», «Руководитель проекта», «Специалист по верстке», «Компьютерный центр», «Выпуск». Более подробно их роль будет рассмотрена при описании декомпозированной диаграммы.
- Стрелки, связывающие объекты диаграммы.
Для размещения рекламного объявления в печатных изданиях издательского дома ЗАО «АБРОН» клиент обращается в отдел рекламы. Изучив намерения клиента, оператор задает перечень услуг, в результате которого формируется электронный бланк расчета стоимости услуг. Данный бланк отправляется бухгалтеру по электронной почте для расчета стоимости услуг. Исходя, из данных электронного бланка бухгалтер рассчитывает стоимость, после чего оправляет ответ оператору. В тех случаях, если клиента не устраивает стоимость, перечень услуг электронного бланка корректируется и повторно отправляется бухгалтеру. Бухгалтер рассчитывает стоимость услуг после корректировки и вновь отправляет электронный бланк оператору. В случае если клиента не устраивает стоимость, перечень услуг электронного бланка корректируется. Бухгалтер принимает платеж от клиента принявшего решения о сотрудничестве, и формирует квитанцию об оплате, с которой клиент возвращается к оператору отдела рекламы. После получения квитанции об оплате услуг, оператор оформляет заявку, путем заполнения всех необходимых граф системы. После оформления заявки, оператор отдела рекламы ставит задачу перед назначенным им руководителем проекта обработать заявку на размещение рекламного объявления. В случае необходимости создания макета рекламного объявления оформленная заявка направляется специалисту по верстке. Далее руководитель проекта устанавливает требования к оформлению рекламного объявления. Компьютерный центр оформляет рекламное объявление и передает его обратно руководителю проекта, который записывает оформленное рекламное объявление на электронный носитель и отправляет его в отдел выпуск. Проверяющий редактор отдела выпуска проверяет записанное на электронном носителе объявления в составе номера, сравнивая его с данными оформленной заявкой. Затем дежурный редактор выпуска утверждает объявление в составе номера к публикации и отправляет номер в типографию. После публикаций дежурный редактор выпуска фиксирует информацию в системе путем смены статуса заявки. Руководитель проекта отслеживает информацию о публикации и в случае изменения статуса заявки в системе составляет отчет о проделанной работе, который показывает оператору. Далее оператор отдела рекламы обращается к системе и, опираясь на сведения о публикации, связывается с клиентом и сообщает о том, что заявка обработана.
На рис.3.5 представлена декомпозиция диаграммы потоков данных в процессе обработки заявки на размещение рекламного объявления после ввода информационной системы.
Заинтересованный в размещении рекламного объявления клиент обращается в отдел рекламы. Оператор отдела консультирует и информирует клиента, а также предлагает услуги предоставляемые издательством. Исходя из целей и задач клиента, оператор формирует перечень услуг в системе, в который входит издание и тип этого издания соответственно, приоритеты размещения, а также параметры объявления. На основании заданных параметров в системе формируется электронный бланк расчета стоимости услуг. Данный бланк отправляется бухгалтеру по электронной почте. Исходя, из данных электронного бланка бухгалтер рассчитывает стоимость, после чего оправляет ответ оператору. В тех случаях, если клиента не устраивает стоимость, перечень услуг электронного бланка корректируется и повторно отправляется бухгалтеру. Бухгалтер рассчитывает стоимость услуг после корректировки и вновь отправляет электронный бланк оператору. Оператор демонстрирует полученный расчет клиенту. В случае согласия клиента на сотрудничество электронный бланк расчета выводится на печать. Далее клиент направляется к бухгалтеру для оплаты услуг. Оплата может осуществляться как единовременно, так и по частям (обычно в процентах от полной стоимости) по мере готовности заказа. Бухгалтер принимает платеж и формирует квитанцию об оплате, с которой клиент возвращается к оператору отдела рекламы. Затем клиент предоставляет квитанцию об оплате оператору, который в свою очередь регистрирует клиента в системе, закрепляет за ним руководителя проекта и заключает договор о намерениях. После согласования условий сделки сторонами оператор оформляет заявку, выбирая данные введенные в систему во время анализа намерений клиента. После оформления заявки, оператор отдела рекламы ставит задачу перед назначенным им руководителем проекта обработать заявку на размещение рекламного объявления. В случае необходимости создания макета рекламного объявления оформленная заявка направляется специалисту по верстке. Далее руководитель проекта устанавливает требования к оформлению рекламного объявления. Компьютерный центр оформляет рекламное объявление и передает его обратно руководителю проекта, который записывает оформленное рекламное объявление на электронный носитель и отправляет его в отдел выпуск. Проверяющий редактор отдела выпуска проверяет записанное на электронном носителе объявление в составе номера для публикации, сравнивая его с данными оформленной заявкой. Далее дежурный редактор выпуска утверждает объявление в составе номера к публикации и отправляет номер в типографию. Печать рекламных объявлений в составе номера газеты осуществляется в типографии «ВМГ – Принт». Печать рекламных вкладышей, объявлений в составе брошюр, каталогов, а также номера любого из журналов издательства, выполняется в типографии Мосполиграф. После публикаций дежурный редактор выпуска фиксирует информацию в системе путем смены статуса заявки. Руководитель проекта отслеживает информацию о публикации и в случае изменения статуса заявки в системе составляет отчет о проделанной работе, который показывает оператору. Далее оператор отдела рекламы обращается к системе и, опираясь на сведения о публикации, связывается с клиентом и сообщает о том, что заявка обработана.
3.3. Объектно-ориентированное моделирование информационной системы по обработке заявок на размещение рекламных объявлений в печатных изданиях
Диаграмма вариантов использования
Объектно-ориентированное проектирование осуществляется с помощью UML-диаграмм.
Диаграмма вариантов использования (диаграмма прецедентов) – диаграмма, на которой отражены отношения, существующие между актерами и прецедентами (вариантами использования).
Диаграмма вариантов использования, представленная на рисунке 3.6 , включает в себя двух актеров, которые являются внешними сущностями по отношению к моделируемой системе и двенадцать вариантов использования, которые представляют собой аспект или фрагмент поведения некоторой сущности без раскрытия ее внутренней структуры.
К актерам относятся оператор отдела рекламы, бухгалтер и проверяющий редактор.
Оператор отдела рекламы имеет следующие варианты использования:
- может сформировать перечень услуг. Данный вариант использования включает в себя 4 варианта:
- выбрать печатное издание;
- выбрать приоритет размещения;
- выбрать параметры объявления;
- согласовать условия сделки.
- зарегистрировать клиента;
- закрепить клиента за руководителем;
- согласовать условия сделки;
- оформить заявку.
Бухгалтер имеет следующие варианты использования:
- рассчитать стоимость услуг;
- принять платеж.
Проверяющий редактор имеет следующие варианты использования:
- проверить правильность выполнения заказа;
- изменить статус заявки.
Диаграмма классов
Диаграмма классов (Class diagram) — статическая структурная диаграмма, описывающая структуру системы, она демонстрирует классы системы, их атрибуты, методы и зависимости между классами.
На рис. 3.7 представлена диаграмма классов, которая состоит из следующих частей:
- 1. Классы (entity) – Договор, Клиент, Тип издания, Издания, Оператор, Приоритеты, Параметры объявления, Заявки, Объявления.
- Границы (Boundary) – Создание клиента, Редактирование клиента, Поиск клиента, Поиск заявки клиента, Изменение статуса заявки, Поиск оператора, Добавление издания, Редактирование издания.
- Управления (control) – Менеджер клиентов, Менеджер изданий, Менеджер заявка клиента.
Диаграмма развертывания
Диаграмма развертывания для информационной системы «Обработка заявок на размещение рекламных объявлений в печатных изданиях» представлена на рис. 3.8. Основными пользователями информационной системы будут оператор отдела рекламы, бухгалтер и проверяющий редактор отдела выпуск. Информационная система будет установлена на сервере, где также будет установлена СУБД Microsoft Access. Все пользователи будут соединены по локальной сети с сетевым принтером.
3.4. Моделирование структуры реляционной базы данных
3.4.1. Структура реляционной базы данных информационной системы «Обработка заявок на размещение рекламных объявлений в печатных изданиях»
На рисунке 3.9 представлена схема реляционной базы данных информационной системы «Обработка заявок на размещение рекламных объявлений в печатных изданиях». Данная структура в стандарте IDEF1X на логическом уровне.
Логический уровень реляционной базы данных информационной системы
На рисунке, представленном выше, показана база данных состоящая из следующих сущностей: «Договор», «Клиенты», «Тип издания», «Издания», «Приоритеты», «Операторы», «Параметры объявлений», «Заявки», «Объявления».
Сущность «Договор» отражает всю важную информацию о рекламодателе, а также присваивает уникальный номер договора.
Тип сущности «Клиенты» содержит в себе информацию о рекламодателях или, проще говоря, клиентах, которые заинтересованы в размещении рекламных объявлений.
При подаче объявления клиенту присваивается порядковый номер, который в последствие привязывается к договору.
В издательском доме ЗАО «АБРОН» все печатные издания разделяются по типам изданий. Данные всех параметров и характеристик хранит в себе сущность «Тип издания».
Сущность «Издания», располагает информацией о каждом издании, выпускаемом издательством.
Тип сущности «Приоритеты» включает хранилище разработанных издательством «ЗАО «АБРОН»» приоритетов подачи объявлений.
Приоритеты, предложенные издательством различные, — это и срочность обработки заявки, и выбор места размещения рекламных объявлений на страницах печатных, и различные специальные предложения. В случае если заявка не относится ни к одному из специальных типов приоритетов, ей автоматически присваивается статус «без приоритета». Каждый приоритет имеет определенную стоимость. Наиболее эффективным является размещение рекламы на обложке и последней странице издания, поэтому их стоимость выше по сравнению с остальными. Но, как правило, данные престижные места выкуплены на много месяцев вперед, поэтому в издательстве разработан VIP-приоритет, который дает возможность разместить рекламное объявление вне очереди. Однако на данный приоритет не действуют скидки, и наценка составляет 100% от общей стоимости всех предоставленных услуг.
Типу сущности «Операторы» отводится для информации об операторах, которые работают с клиентами. Оператор – это сотрудник рекламного отдела, который занимается приемом и обработкой заявок для размещения объявлений и рекламы на страницах печатных изданий. После закрепления оператора за клиентом, вся ответственность за заявку лежит на операторе.
В сущности «Параметры объявлений» отражается перечень возможных параметров рекламных объявлений. Перечень параметров согласовывается с рекламодателем и заносится в таблицу. Рекламодатель задает следующие параметры: «тип и вид рекламы», «формат», «количество модулей». Более подробно параметры объявлений описаны в приложении 3.
Тип сущности «Заявки» содержит полную информацию о заявке на размещение рекламных объявлений в печатные издания издательства. Данная сущность является ключевой, т.к. частично включает в себя данные всех описанных ранее сущностей. Первичным ключом является поле «id_z»;
Сущность «Объявления» хранит в себе обработанные заявки, т.е. данные заявок на рекламные объявления вышедших в свет. Данная сущность необходима для наглядного анализа деятельности отделов, задействованных в обработке и размещении рекламных материалов. На основании данных таблицы можно более эффективно планировать работы, а также штат сотрудников, учитывая количество поступающих заявок.
Далее необходимо определить связи между сущностями. Существует несколько типов связей:
- связь «один к одному». Такая связь означает, что один экземпляр первой сущности связан с одним экземпляром второй сущности. Разнесения данных разным таблицам и связывания их потом такой связью обычно делают, когда хранить все данные в одной таблице по каким-то причинам не целесообразно. Такая связь используется редко.
- связь «один ко многим». Это самый распространенный тип связи, означающий, что на одну запись первой сущности приходится множество записей во второй сущности.
- связь «многие ко многим». При данном типе связи запись из одной сущности связывается с несколькими записями другой сущности, а запись из второй сущности связывается с несколькими записями в первой сущности.
Рассмотрим более подробно связи сущностей, показанные на рис. 3.9.
Связь между таблицами «Договор» – «Клиент» один ко многим, то есть один клиент может заключить множество договоров, но конкретный договор заключается с определенным клиентом.
Со стороны родительской сущности:
D:R – нельзя удалить запись из таблицы «Договор», если зафиксированы данные о клиенте.
U:R – нельзя присвоить договору другой номер, если существует ссылающая на него запись в таблице «Клиент».
Со стороны дочерней сущности:
I:R – нельзя создать запись о клиенте, не указав номера договора.
U:R – нельзя изменить запись о клиенте, присвоив ему несуществующий номер договора.
Связь между таблицами «Тип Издания» – «Издания» один ко многим, то есть к одному типу издания принадлежат множество различных изданий, но каждое издание имеет определенный тип.
Со стороны родительской сущности:
D:R – нельзя удалить запись из таблицы «Тип Издания», если печатное издание зафиксировано.
U:R – нельзя присвоить изданию другой тип, если существует ссылающая на него запись в таблице «Издания».
Со стороны дочерней сущности:
I:R – нельзя создать запись об издании, не указав тип издания.
U:R – нельзя изменить содержание записи издания, привязав его к несуществующему типу издания.
Связь между таблицами «Клиенты» – «Заявки» один ко многим, то есть один клиент может подать несколько заявок, но каждая заявка содержит данные только одного клиента.
Со стороны родительской сущности:
D:R – нельзя удалить запись из таблицы «Клиент», если им была подана заявка.
U:R – нельзя присвоить клиенту другой номер, если существует ссылающая на него запись в таблице «Заявки».
Со стороны дочерней сущности:
I:R – нельзя создать запись о заявке, не указав номера клиента.
U:R – нельзя изменить запись о заявке, присвоив несуществующий номер клиента.
Связь между таблицами «Договор» – «Заявки» один ко многим, то есть в один и тот же договор может быть включены различные заявки, но каждая заявка содержит определенный договор.
Со стороны родительской сущности:
D:R – нельзя удалить запись из таблицы «Договор», если клиент подал заявку.
U:R – нельзя присвоить договору другой номер, если существует ссылающая на него запись в таблице «Заявки».
Со стороны дочерней сущности:
I:R – нельзя создать запись о заявке, не указав номера клиента.
U:R – нельзя изменить запись о заявке, присвоив ему несуществующий номер клиента.
Связь между таблицами «Приоритеты» – «Заявки» один ко многим, то есть один и тот же приоритет может быть включен в различных заявках, но каждая заявка содержит определенный приоритет.
Со стороны родительской сущности:
D:R – нельзя удалить запись из таблицы «Приоритеты», если клиент подал заявку.
U:R – нельзя присвоить приоритету другой номер, если существует ссылающая на него запись в таблице «Заявки».
Со стороны дочерней сущности:
I:R – нельзя создать запись о заявке, не указав номера приоритета.
U:R – нельзя изменить запись о заявке, присвоив ему несуществующий номер приоритета.
Связь между таблицами «Операторы» – «Заявки» один ко многим, то есть один и тот же оператор может зарегистрировать различные заявки, но каждая заявка создана определенным оператором.
Со стороны родительской сущности:
D:R – нельзя удалить запись из таблицы «Операторы», если заявка принята.
U:R – нельзя присвоить оператору другой номер, если существует ссылающая на него запись в таблице «Заявки».
Со стороны дочерней сущности:
I:R – нельзя создать запись о заявке, не указав номера оператора.
U:R – нельзя изменить запись о заявке, присвоив ему несуществующий номер оператора.
Связь между таблицами «Параметры объявлений» – «Заявки» один ко многим, то есть один и тот же параметр может быть включен в различных заявках, но каждая заявка содержит определенный параметр объявления.
Со стороны родительской сущности:
D:R – нельзя удалить запись из таблицы «Параметры объявлений», если клиент подал заявку.
U:R – нельзя присвоить параметру другой номер, если существует ссылающая на него запись в таблице «Заявки».
Со стороны дочерней сущности:
I:R – нельзя создать запись о заявке, не указав номера параметра.
U:R – нельзя изменить запись о заявке, присвоив ему несуществующий номер параметра объявления.
Связь между таблицами «Издания» – «Заявки» один ко многим, то есть в одно издание может быть включены несколько заявок, но каждая заявка может содержать только одно издание.
Со стороны родительской сущности:
D:R – нельзя удалить запись из таблицы «Издания», если была подана заявка.
U:R – нельзя присвоить изданию другой номер, если существует ссылающая на него запись в таблице «Заявки».
Со стороны дочерней сущности:
I:R – нельзя создать запись о заявке, не указав номера издания.
U:R – нельзя изменить запись о заявке, присвоив несуществующий номер издания.
Связь между таблицами «Заявки» – «Объявления» один к одному, то есть каждой заявке соответствует только одно объявление, которое было опубликовано и каждое объявление содержит информацию о конкретной оформленной заявке. После опубликования заявки на размещение рекламного объявления на страницах печатных изданий издательства запись из таблицы «Заявки» удаляется, а данные таблицы переносятся в таблицу «Объявления».
3.4.2. Описание атрибутов сущности
Система состоит из 8 сущностей: «Dogovor», «Klienti», «Tip_izdaniya», «Izdaniya», «Prioriteti», «Operatori», «Parametri_obyavlenii», «Zayavki» и «Obyavleniya».
Dogovor – данные этой сущности показывают уникальный номер каждого заключенного договора, а также его тип. Данные атрибутов сущности приведены в таблице 3.1.
Таблица 3.1. Атрибуты сущности «Dogovor»
| Column Name | Data Type | Obligatory field | Key Type | Declaration |
| id_dog | NUMBER (5) | No | Primary Key | номер договора |
| Dogovor | VARCHAR2 (25) | No | — | тип договора |
Сущность Klienti – отражает полную информацию о клиентах заинтересованных в размещении рекламных объявлений. Атрибуты сущности представлены в таблице 3.2.
Таблица 3.2. Атрибуты сущности «Klienti»
| Column Name | Data Type | Nullable | Key Type | Declaration |
| id_kl | NUMBER (5) | No | Primary Key | номер клиента |
| Last_name | VARCHAR2 (15) | No | — | фамилия клиента |
| First_name | VARCHAR2 (15) | No | — | имя клиента |
| Mid_name | VARCHAR2 (15) | No | — | отчество клиента |
| Telefon | NUMBER(11) | Yes | — | контактный телефон клиента |
| id_dog | NUMBER (5) | No | Foreign key | номер договора |
Сущность Tip_izdaniya – располагает подробной информацией о типах изданий выпускаемых издательством. Атрибуты сущности приведены в таблице 3.3.
Таблица 3.3. Атрибуты сущности «Tip_izdaniya»
| Column Name | Data Type | Nullable | Key Type | Declaration |
| id_tiz | NUMBER (5) | No | Primary Key | номер типа издания |
| Tip_prodykcii | VARCHAR2 (20) | No | — | тип издания |
| Periodichnost | VARCHAR2 (15) | No | — | периодичность выпуска печатной продукции конкретного типа |
| Kolichesvo | NUMBER (10) | No | — | количество продукции |
Сущность Izdaniya – содержит сведения об изданиях выпускаемых издательским домом. Данные атрибутов сущности представлены в таблице 3.4.
Таблица 3.4. Атрибуты сущности «Izdaniya»
| Column Name | Data Type | Nullable | Key Type | Declaration |
| id_iz | NUMBER (5) | No | Primary Key | номер издания |
| Izdanie | VARCHAR2 (20) | No | — | название издания |
| Kol-vo stranic | VARCHAR2 (10) | No | — | количество страниц |
| Tirage | VARCHAR2 (10) | No | — | Тираж экземпляров |
| Data | DATE | No | —
|
дата издания |
| id_tiz | NUMBER (5) | No | Foreign key | номер типа издания |
Сущность Prioriteti – является хранилищем разработанных издательством приоритетов подачи объявлений. Данные атрибутов сущности приведены в таблице 3.5.
Таблица 3.5. Атрибуты сущности «Prioriteti»
| Column Name | Data Type | Nullable | Key Type | Declaration |
| id_pr | NUMBER (5) | No | Primary Key | номер приоритета |
| Prioritet | VARCHAR2 (20) | No | — | наименование приоритета |
Сущность Operatori – содержит информацию об операторах рекламного отдела, которые получают заявки на размещение рекламных объявлений от рекламодателей. Данные атрибутов сущности представлены в таблице 3.6.
Таблица 3.6. Атрибуты сущности «Operatori»
| Column Name | Data Type | Nullable | Key Type | Declaration |
| id_op | NUMBER (5) | No | Primary Key | номер оператора |
| Last_name | VARCHAR2 (15) | No | — | фамилия оператора |
| First_name | VARCHAR2 (15) | No | — | имя оператора |
| Mid_name | VARCHAR2 (15) | No | — | отчество клиента |
| Telefon | NUMBER(11) | Yes | — | контактный телефон оператора |
Сущность Parametri_obyavlenii – представляет информацию о параметрах рекламных объявлений. Атрибуты данной сущности представлены в таблице 3.7.
Таблица 3.7. Атрибуты сущности «Parametri_obyavlenii»
| Column Name | Data Type | Nullable | Key Type | Declaration |
| id_pob | NUMBER (5) | No | Primary Key | номер параметра объявления |
| Tip_obyavleniya | VARCHAR2 (15) | No | — | тип и вид рекламного объявления |
| Format | VARCHAR2 (15) | No | — | формат рекламного объявления |
| Kol_modylei | VARCHAR2 (15) | No | — | количество модулей |
| Cena | VARCHAR2 (15) | No | — | стоимость |
Сущность Zayavki – содержит полную информацию о заявках на размещение рекламных объявлений. Данная сущность является ключевой. Атрибуты сущности приведены в таблице 3.8.
Таблица 3.8. Атрибуты сущности «Zayavki»
| Column Name | Data Type | Nullable | Key Type | Declaration |
| id_z | NUMBER (5) | No | Primary Key | номер параметра объявления |
| Data_podachi | DATE | No | — | тип и вид рекламного объявления |
| Kol_vivodov | VARCHAR2 (5) | No | — | формат объявления |
| Skidki | VARCHAR2 (15) | Yes | — | количество модулей |
| Nacenki | VARCHAR2 (15) | Yes | — | стоимость |
| id_op | NUMBER (5) | No | Foreign key | номер оператора рекламного отдела |
| id_dog | NUMBER(5) | No | Foreign key | номер договора |
| id_kl | NUMBER(5) | No | Foreign key | номер клиента |
| id_pob | NUMBER(5) | No | Foreign key | номер параметра объявления |
| id_pr | NUMBER(5) | No | Foreign key | номер приоритета |
| id_iz | NUMBER(5) | No | Foreign key | номер издания |
| id_tiz | NUMBER (5) | No | Foreign key | номер типа издания |
Сущность Obyavleniya – отражает опубликованные на страницах печатных изданий издательства заявки. Потребность в данной сущности обусловлена необходимостью разнесения данных сущности «Zayavki» по двум таблицам для удобства эксплуатации пользователями системы и наглядности отображения информации. Как видно из таблицы 3.9, сущность содержит атрибуты сущности «Заявки».
Таблица 3.9. Атрибуты сущности «Obyavleniya»
| Column Name | Data Type | Nullable+ | Key Type | Declaration |
| id_ob | NUMBER (5) | No | Primary Key | номер опубликованного объявления |
| id_z | NUMBER (5) | No | Foreign key | номер заявки |
| id_op | NUMBER (5) | No | Foreign key | номер оператора рекламного отдела |
| id_dog | NUMBER(5) | No | Foreign key | номер договора |
| id_kl | NUMBER(5) | No | Foreign key | номер клиента |
| id_pob | NUMBER(5) | No | Foreign key | номер параметра объявления |
| id_pr | NUMBER(5) | No | Foreign key | номер приоритета |
| id_iz | NUMBER(5) | No | Foreign key | номер издания |
| id_tiz | NUMBER (5) | No | Foreign key | номер типа издания |
3.4.3. Создание интерфейса для базы данных информационной системы «Обработка заявок на размещение рекламных объявлений в печатных изданиях»
Для более удобной работы с базой данных был разработан интерфейс с помощью Borland Delphi 7 Enterprise Edition. Borland Delphi 7 – последняя версия одного из самых популярных в мире средств быстрой разработки программ для Microsoft Windows на языке Delphi (ранее носившем название Object Pascal), созданная первоначально фирмой Borland Программный комплекс удобен в использовании, имеет дружественный интерфейс для разработчика и пользователя, а также предоставляет разработчику богатейший инструментарий.
В качестве СУБД была выбрана Microsoft Access 2007, которая является составляющей частью пакета Microsoft Office 2007. Microsoft Access – это прикладная программа, основная функция которой – удобное и простое управление данными, содержащимися в таблицах, состоящих из строк и столбцов (поля и записи). Благодаря тому, что базы данных реляционные, пользователь может одновременно работать с несколькими таблицами как с одной областью хранения, а также извлекать любую информацию в нужном формате и порядке.
На рис.3.10 изображена схема связи компонентов пользовательского интерфейса автоматизированной информационной системы «Обработка заявок на размещение рекламных объявлений в печатных изданиях».
Для работы с информационной системой пользователю необходимо запустить программу и ввести пароль. Сессия работы в системе по времени не ограничена.
Если процесс прошел успешно, пользователь попадает на главную страницу программы и может перемещаться по страницам приложения с помощью меню панели задач или дублирующих меню кнопок. Меню включает в себя следующее разделы программы: «Оформление заявок», «Добавление клиентов/договоров», «Операторы», «Параметры объявлений», «Приоритеты», «Издания». Находясь в любом из разделов, пользователь всегда имеет возможность выйти из системы, для корректного выхода пользователю необходимо кликнуть левой кнопкой мыши по кнопке «Закрыть» (крестик).
На рис. 3.11 представлен интерфейс входа в программу. Для того чтобы войти в систему и работать в ней необходимо ввести пароль для входа в программу.
В авторизации может быть отказано, в случае, если:
- Пользователь не указал пароль.
- Пароль неверный.
- Введенный пароль заблокирован в системе.
В каждом из вышеперечисленных случаев система откажет в доступе и выдаст диалоговое окно, представленное на рис. 3.12.
Сессия работы в системе по времени не ограничена. После ввода данных сотрудник попадает на главную страницу, интерфейс которой представлен на рис.3.13.
В нужное меню панели задач можно войти двумя способами. В первом способе следует выбрать нужную операцию из списка, визуально это представлено на рис. 3.14.
Также под списком операций, в программе расположены дублирующие окна, так называемые «горячие» клавиши, необходимые для удобства работы с наиболее часто выполняемыми операциями. При наведении курсора мыши на выбранное окно появляется текст операции (рис 3.15).
Работа с клиентами базы данных
Для работы с клиентами и договорами в системе предназначен соответствующий раздел. Все клиенты выводятся в табличном виде, с указанием фамилии, имени, отчества, контактного телефона, а также номера договора. На рисунке 3.16 продемонстрирован общий вид интерфейса раздела «Клиенты/Договора».
Для каждой записи в таблице доступны такие действия, как редактирование, удаление, переход к договорам пользователя. На рисунке 3.17 представлен интерфейс удаления клиента вместе с договором.
Также, интерфейс позволяет производить быстрый поиск, достаточно ввести лишь первые буквы фамилии клиента и система выдаст все возможные варианты. (см. рис 3.18)
На рисунке 3.19 показан интерфейс создания нового клиента. Все введенные данные проверяются на корректность, с учетом ограничений наложенных в базе данных.
В системе имеется раздел «Операторы», продемонстрированный на рис.3.20, который позволяет создавать, редактировать и удалять операторов рекламного отдела. Для каждого оператора можно выполнить следующие действия:
- Редактировать информацию;
- Производить быстрый поиск;
- Добавить нового оператора;
- Удалить оператора.
Раздел «Приоритеты» представляет собой справочник, который хранит в себе информацию о возможных параметрах мест размещения рекламных объявлений на страницах печатных изданий издательства «ЗАО «АБРОН»» (рис 3.21).
На рисунке 3.22 представлен раздел «Параметры объявлений», который содержит в себе информацию о типах объявлений, форматах, количестве модулей и их стоимости. Данный раздел также позволяет редактировать данные, удалять и добавлять новые.
Раздел «Издания», представленный на рис. 3.23, вмещает в себе полный перечень печатных продуктов в соответствии с типами изданий. В данном разделе содержится информация о названии издания, количестве страниц, его тираже, типе издания, дате издания, а также периодичности и количестве изданий соответствующей категории. Система позволяет создавать, редактировать и удалять данные раздела.
В разделе «Оформление заявки» пользователю предлагается оформить заявку на подачу объявления. Раздел содержит следующие поля для заполнения: дата подачи, количество выводов, скидки, наценки, договор, оператор, приоритет, тип объявления, издание. Как видно из рис. 3.24 и рис. 3.25, часть данных необходимо вводить вручную, часть имеет меню, которое выводится нажатием стрелки вниз, также в системе предусмотрен календарь, необходимый для удобства работы в системе при выборе даты.
На рис. 3.26 представлена страница «Заявки». Данная страница является хранилищем всех оформленных заявок в системе и является наглядным отражением работы рекламного отдела. На основании страницы можно проводить анализ проведенных работ и планировать увеличение штата сотрудников с учетом увеличения количества поступающих заявок.
Над данными страницы «Заявки» расположена кнопка меню «Опубликовать в объявлениях». Данная функция, как показано на рис. 3.27, необходима для фиксирования объявлений, которые опубликовались на страницах печатных изданий «Новых Известий» и тем самым сменили свой статус с «Заявки» на «Объявления». После осуществления данной процедуры данные записываются в список «Объявления» и удаляются из списка «Заявки» соответственно. (рис. 3.28)
Если по какой-то причине рекламодатель отказался от публикации рекламных материалов после оформления заявки и подписания договора, в системе предусмотрена возможность удаления истории заявки. Наглядно диалоговое окно удаления данных из списка «Заявки» представлено на рисунке 3.29.
Выявив в аналитической части дипломного проекта недостатки существующей информационной системы, рассмотрев в теоретической части возможные средства разработки, языки программирования и программы аналоги, в проектной части составили Техническое задание на создание автоматизированной системы, смоделировали процесс обработки заявок на размещение рекламных объявлений в печатных изданиях и спроектировали информационную систему. Автоматизированная информационная система «Обработка заявок на размещение рекламных объявлений в печатных изданиях» представлена в виде совокупности реляционных таблиц. На основании выделенных информационных объектов построена модель «Сущность-связь» позволившая проследить информационные связи между этими объектами, были построены UML-диаграммы, характеризующие процесс с использованием ИС, а также представлен интерфейс внедряемой информационной системы, разработанный с помощью программы Borland Delphi 7 Enterprise Edition.