Разработка многопользовательской информационной системы по ведению учета подписной деятельности почтовым отделением

КУРСОВОЙ ПРОЕКТ

Тема: “Разработка многопользовательской информационной системы по ведению учета подписной деятельности почтовым отделением”

Введение

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

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

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

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

1. Постановка задачи

1.1 Анализ предметной области

Моделируемая информационная система призвана упростить ведение учета и анализа подписной деятельности в рамках отдельного почтового отделения.

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

Администрация призвана вести контроль над работой кассира-оператора и проводить текущий анализ эффективности деятельности кассиров-операторов и почтовых отделений в целом.

1.2 Обоснование актуальности решаемой задачи

Задачей данного курсового проекта является реализация многопользовательской информационной системы по учету и анализу подписной деятельности.

Моделируемая информационная система предназначена для упрощения ведения подписной деятельности, а именно призвана решать следующие практические задачи:

Ввод и хранение сведений об организациях – клиентах;

Ввод и хранение сведений о клиентах физических лицах;

Составление рейтинга наиболее популярных изданий;

Составление списка почтовых отделений, которые сработали лучше других за отчетный период;

Анализ общего объема подписки и числа подписных изданий;

Анализ объема подписки по отдельным изданиям;

Составление отчета по организациям и объемам подписки.

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

2. Проектирование логической модели системы

2.1 Функциональная модель

Для проведения анализа и функционального проектирования информационной системы используется CASE – средство Bpwin. Bpwin поддерживает три методологии: IDEF0, DFD и IDEF3, позволяющие анализировать организационную систему.

Информационная система функционирует следующим образом.

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

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

– в формах – для вывода наглядной информации для пользователя; после закрытия формы результаты преобразования не сохраняются;

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

Вывод данных на экран осуществляется посредством вызова соответствующих таблиц, запросов, форм или отчетов. Таблицы соответствуют физическим данным, которые хранятся на диске. Результаты запросов также можно сохранять в отдельных таблицах.

2.1.1 Контекстная диаграмма и детализация процессов

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

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

Контекстная диаграмма представляет собой схему управления процессом подписки. Управляющим воздействием являются нормативные акты и приказы; входные данные – данные для запросов и отчетов, они вводятся пользователем. Результатом функционирования являются различные отчеты.

Функциональная модель (диаграммы первого и второго уровней) рассматриваемой информационной системы изображена в приложении 5.1.

2.1.2 Миниспецификация процессов

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

2.2 Информационная модель

2.2.1 Идентификация сущностей и связей. ER-диаграмма логического уровня

Для отображения информационной модели рассматриваемого процесса были использованы следующие сущности:

Издание

ВедПодписка (ведомственная подписка)

ЧастПодписка (подписка физических лиц)

Почтовое отделение

ИзданиеПочтОтдел

ЧастЦена (цена подписки издания для частных лиц)

ВедЦена (цена подписки издания для организаций)

Схема каждого из отношений представлена на рисунке 3.

Для однозначного определении записей в каждом из отношений выделен первичный ключ (простой или составной).

Внешние ключи для отношений БД:

В отношениях ВедЦена и ЧастЦена – это ключ Индекс;

В отношениях ВедПодписка и ЧастПодписка – это составной ключ: Индекс, НомерПО.

На логическом уровне проектирования в моделируемой базе данных присутствуют следующие типы связей между описанными сущностями:

1) связь типа один ко многим;

2) связь типа многие ко многим между Изданием и Почтовым Отделением.

2.2.2 Определение доменов для схем отношений. Уточнение типов данных для атрибутов схем отношений. Реализация ссылочной целостности

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

Все не ключевые атрибуты функционально полно и не транзитивно зависят от первичного ключа. Следовательно, отношение находится в БКНФ.

Все вышеизложенные отношения функционально полно зависят от первичного ключа.

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

Таким образом, все отношения находятся в БКНФ.

На логическом уровне в моделируемой системе присутствовала связь типа “многие ко многим” между сущностью Издание и сущностью Почтовое отделение. Для ее реализации на физическом уровне была введена дополнительная зависимая сущность ИзданиеПочтОтдел.

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

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

Результат связывания объектов модели процессов отображается в следующей таблице.

Таблица 1 – Результат связывания объектов модели процессов

Attribute Name

Entity Name

Arrow Name

Activity Name

Адрес

ЧастПодписка

Данные клиента

Изменение данных по частПодписке

Регистрация частПодписки

Индекс

ВедПодписка

Запрос об объемах

Анализ общего объема ведомственной подписки и количества подписных изданий

Отчет по изданиям

Анализ объема ведподписки по изданиям

Отчет по организациям

Анализ объемов подписки по организациям

ЧастПодписка

Запрос об объемах част

Анализ общего объема частной подписки и количества подписных изданий

Отчет по част изд

Анализ объема частподписки по изданиям

Код

ЧастПодписка

Данные клиента

Изменение данных по частПодписке

Регистрация частПодписки

Запрос об объемах част

Анализ общего объема частной подписки и количества подписных изданий

НазвИздания

Издание

Запрос об объемах

Анализ общего объема ведомственной подписки и количества подписных изданий

Запрос об объемах част

Анализ общего объема частной подписки и количества подписных изданий

Отчет по изданиям

Анализ объема ведподписки по изданиям

Отчет по организациям

Анализ объемов подписки по организациям

Отчет по част изд

Анализ объема частподписки по изданиям

НомерПО

ЧастПодписка

Данные клиента

Изменение данных по частПодписке

Регистрация частПодписки

Объем

ВедПодписка

Запрос об объемах

Анализ общего объема ведомственной подписки и количества подписных изданий

Отчет по изданиям

Анализ объема ведподписки по изданиям

Отчет по организациям

Анализ объемов подписки по организациям

Организация

ВедПодписка

Данные организации

Изменение данных по ведПодписке

Регистрация ведПодписки

Запрос об объемах

Анализ общего объема ведомственной подписки и количества подписных изданий

Отчет по организациям

Анализ объемов подписки по организациям

Период

ВедПодписка

Запрос об объемах

Анализ общего объема ведомственной подписки и количества подписных изданий

Период

ЧастПодписка

Данные клиента

Изменение данных по частПодписке

Регистрация частПодписки

Запрос об объемах част

Анализ общего объема частной подписки и количества подписных изданий

Отчет по част изд

Анализ объема частподписки по изданиям

Фамилия

ЧастПодписка

Данные клиента

Изменение данных по частПодписке

Регистрация частПодписки

3. Реализация системы

3.1 Описание программного обеспечения, разработанного в архитектуре “клиент – сервер”

Моделируемое программное обеспечение предполагает работу с двумя клиентами: кассиром-оператором и начальником почтового отделения, которые пользуются одними данными, но выполняют различные виды работ с этими данными. Поэтому было разработано два приложения “Обработать данные для кассира-оператора” и “Обработать данные для начальника”.

Работа с базой данных начинается с автоматического открытия главной кнопочной формы. На форме находятся следующие управляющие элементы – кнопки и их подписи. При нажатии на кнопку с помощью мыши раскрывается форма или выполняется некоторый запрос. Для облегчения работы каждая кнопка снабжена всплывающей подсказкой. Для осуществления поиска необходимых данных на главную кнопочную форму выведены кнопки для вызова соответствующих запросов. Для выхода из базы данных предусмотрена кнопка “Выход”.

Кнопочная форма клиентского приложения “Обработать данные для начальника почтового отделения” представлена на следующем рисунке 1.

Рисунок 1 – Форма клиентского приложения “Обработать данные для начальника почтового отделения”

Кнопочная форма клиентского приложения “Обработать данные для кассира-оператора” представлена на следующем рисунке 2.

Рисунок 2 – Форма клиентского приложения “Обработать данные для кассира-оператора”

Для ввода информации служат кнопки “Оформление ведомственной подписки” и “Оформление подписки для частных лиц” расположенные в главной кнопочной форме клиентского приложения “Обработать данные для кассира-оператора”, которые открывают соответствующие формы “ВедПодписка” и “ЧастПодписка”.

3.2 SQL – определения регламентированных запросов и представлений

На базе описанных выше таблиц для обработки данных и для нахождения требуемой информации были построены следующие запросы.

Для составления списка трех лучших почтовых отделений был построен запрос с параметрами, который на языке SQL имеет следующий вид:

SELECT DISTINCTROW TOP 3 ВедПодписка. НомерПО, Sum(ВедПодписка. Объем) AS Объем

FROM ВедПодписка

GROUP BY ВедПодписка. НомерПО

ORDER BY Sum(ВедПодписка. Объем) DESC;

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

SELECT DISTINCTROW Издание. НазвИздания, Sum(ВедПодписка. Объем) AS Объем

FROM Издание INNER JOIN ВедПодписка ON Издание. Индекс = ВедПодписка. Индекс

GROUP BY Издание. НазвИздания;

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

SELECT DISTINCTROW Издание. НазвИздания, Count(ЧастПодписка. Индекс) AS Объем

FROM Издание INNER JOIN ЧастПодписка ON Издание. Индекс = ЧастПодписка. Индекс

GROUP BY Издание. НазвИздания;

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

SELECT DISTINCTROW ВедПодписка. Организация, Sum(ВедПодписка. Объем) AS Объем

FROM ВедПодписка

GROUP BY ВедПодписка. Организация;

Для выполнения запроса на получение данных об общем объеме ведомственной подписке и количестве подписных изданий соствлен SQL -запрос следующего вида:

SELECT DISTINCTROW Count([V в_подписки по изданиям]. НазвИздания) AS [Число подписных изданий], Sum([V в_подписки по изданиям].Объем) AS [Объем ведПодписки]

FROM [V в_подписки по изданиям];

4. Исследование операционных характеристик ИСС

4.1 Описание базы данных контрольного примера

Для проведения испытаний созданной ИСС разработан контрольный пример, позволяющий проверить работоспособность и отказоустойчивость последней.

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

Рисунок 3

4.2 Анализ результатов тестирования ИСС

Набор действий оператора и результаты работы ИСС приведены в таблице.

Действия оператора

Ответ ИСС

1

Ввод данных о клиенте с помощью формы “ЧастПодписка”

Дата: 23.11.2004

Номер ПО: 2

Фамилия: Иванов С. С.

Адрес: Первомайская 45-78

Индекс: 00003

Период: 12

Код: 2

Записано.

2

Запрос на нахождение объема ведомственной подписки по организациям

Выведена на экран таблица, содержащая сведения о следующих организациях:

Горсвет, Дорстрой, МГУ им Кулешова, ОблПочта, Налоговая, Химволокно.

3

Запрос на нахождение объема ведомственной подписки по изданиям

Выведена на экран таблица, содержащая сведения о следующих изданиях:

Могилевская правда, Могилевские ведомости, Копеечка, Днепровская неделя, Скандинавские кроссворды

4

Запрос на получение отчета об общем объеме ведомственной подписки и количестве подписных изданий

На экран выводится отчет, содержащий необходимые цифры.

5

Ввод данных об организации-клиенте с помощью формы “ВедПодписка”:

Дата: 15.01.2005

Номер ПО: 1

Индекс: 63926

Организация: Дорстрой

Объем: 2

Период: 6

Записано.

6

Запрос на нахождение периодических изданий и объема подписки физическими лицами

На экран выводится таблица, содержащая общие цифры по изданиям: Днепровская неделя, Скандинавские кроссворды, Могилевские ведомости, Могилевская правда.

7

Вызов таблицы “Ведподписка” для редактирования данных

Внесены и отражены в таблице изменения в поле “Объем” для записи Химволокно, 12.01.2005 с 6 на 10 шт.

8

Получение отчета о 3-х лучших почтовых отделениях

На экран выводится лист отчета с номерами 3-х лучших ПО в порядке убывания объемов подписки :3,1,2.

В результате проведенного тестирования разработанная ИСС показала себя как вполне надежная программа, выполняющая все заявленные в описании задачи.

Заключение

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

Данное программное обеспечение разработано в архитектуре “клиент-сервер” на языке SQL.

Возможно дальнейшее совершенствование созданного программного обеспечения.

Список использованных литературных источников

1. Ляхович В. Ф. Основы информатики. – Ростов н/Д: изд-во “Феникс”, 2000. – 608 с.

2. Тихомиров Ю. В. Microsoft SQL Server 7.0: Разработка приложений. – СПб.: БХВ – Петербург, 2000. – 352 с.

Приложение А

Рис. А.1 – Функциональная диаграмма потоков данных

Приложение Б

Рис. Б1 – ER-диаграмма (физический уровень)


Разработка многопользовательской информационной системы по ведению учета подписной деятельности почтовым отделением