КУРСОВОЙ ПРОЕКТ
Тема: "Разработка многопользовательской информационной системы по ведению учёта подписной деятельности почтовым отделением"
Введение
Сфера оказания услуг связи и коммуникации, как в частном, так и государственном секторе в настоящее время проходит через бурный период автоматизации и модернизации. Внедрение новых программных продуктов и систем хранения и обработки имеющейся информации становится доминирующим направлением в данной деятельности. Основным требованием, предъявляемым к системным продуктам, является возможность оперативно обрабатывать большие объёмы сложно структурированной информации.
Системы автоматизации различных аспектов почтовой деятельности в последние годы довольно широко применяются и в этой сфере деятельности и воспринимаются работниками, которые с ними сталкиваются каждый день, как достаточно удобное средство. Автоматизация расчетов и создание отчетов во много раз повышают эффективность и качество работы, облегчают труд операторов рабочих мест.
Подписная деятельность является одной из основополагающих для всех почтовых отделений и отделений связи. Соответственно, учёт и анализ этой деятельности имеет большое значение для разработки стратегии ведения подписной кампании и привлечения максимального числа клиентов, как среди организаций, так и частных лиц.
Целью данного курсового проекта является реализация информационной системы "Подписная деятельность" в архитектуре "клиент-сервер". Данная программа обладает всеми необходимыми компонентами для выполнения задач, связанных с поиском и обработкой информации, удобным графическим интерфейсом и средствами для форматированного вывода информации на печать.
1. Постановка задачи
Моделируемая информационная система призвана упростить ведение учёта и анализа подписной деятельности в рамках отдельного почтового отделения.
В задачи кассира-оператора входит внесение и корректировка сведений об организациях, оформляющих ведомственную подписку, а также необходимый объём данных при оформлении подписки физическими лицами. К концу рабочей смены в период подписной кампании, а также в конце отчётного периода кассир должен предоставить данные об объёме совершённых операций.
Администрация призвана вести контроль над работой кассира-оператора и проводить текущий анализ эффективности деятельности кассиров-операторов и почтовых отделений в целом.
Задачей данного курсового проекта является реализация многопользовательской информационной системы по учёту и анализу подписной деятельности.
Моделируемая информационная система предназначена для упрощения ведения подписной деятельности, а именно призвана решать следующие практические задачи:
ввод и хранение сведений об организациях - клиентах;
ввод и хранение сведений о клиентах физических лицах;
составление рейтинга наиболее популярных изданий;
составление списка почтовых отделений, которые сработали лучше других за отчётный период;
анализ общего объёма подписки и числа подписных изданий;
анализ объёма подписки по отдельным изданиям;
составление отчета по организациям и объёмам подписки.
Все полученные данные составляют необходимую базу для проведения анализа деятельности подразделений (почтовых отделений), а также изучения спроса на рынке периодических изданий. На основе полученных результатов можно делать выводы о предпочтениях клиентов и необходимом направлении деятельности почтовых отделений по оказанию данной услуги.
2. Проектирование логической модели системы
Для проведения анализа и функционального проектирования информационной системы используется CASE – средство Bpwin. Bpwin поддерживает три методологии: IDEF0, DFD и IDEF3, позволяющие анализировать организационную систему.
Информационная система функционирует следующим образом.
Все данные хранятся на внешнем носителе (диске). При необходимости работы с данными, пользователь запускает программу, адаптированную программистом для ввода и обработки данных в конкретной предметной области. Эта программа предоставляет пользователю интерфейс для работы с БД и возможности манипулирования данными.
Оператор может осуществлять ввод и корректировку данных в отношениях посредством основной и подчиненных форм, таблиц. При закрытии таблицы или запроса, результаты сохраняются на диск. Обработка данных производится:
- в формах – для вывода наглядной информации для пользователя; после закрытия формы результаты преобразования не сохраняются;
- в запросах – по данным пользователя отбирается и преобразуется в нужный вид интересующая его информация, выводится в табличном виде на экран; после закрытия запроса его результаты обычно не сохраняются, за исключением запросов на обновление.
Вывод данных на экран осуществляется посредством вызова соответствующих таблиц, запросов, форм или отчетов. Таблицы соответствуют физическим данным, которые хранятся на диске. Результаты запросов также можно сохранять в отдельных таблицах.
Первая диаграмма в иерархии диаграмм 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. Реализация системы