 |
 |
 |
|
|||||||||
|
 | |||||||||||
|
 |
||||||||
|
МЕНЮ
|
БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА - РЕФЕРАТЫ - Разработка многопользовательской информационной системы по ведению учёта подписной деятельности почтовым отделениемРазработка многопользовательской информационной системы по ведению учёта подписной деятельности почтовым отделениемКУРСОВОЙ ПРОЕКТ Тема: "Разработка многопользовательской информационной системы по ведению учёта подписной деятельности почтовым отделением" Введение Сфера оказания услуг связи и коммуникации, как в частном, так и государственном секторе в настоящее время проходит через бурный период автоматизации и модернизации. Внедрение новых программных продуктов и систем хранения и обработки имеющейся информации становится доминирующим направлением в данной деятельности. Основным требованием, предъявляемым к системным продуктам, является возможность оперативно обрабатывать большие объёмы сложно структурированной информации. Системы автоматизации различных аспектов почтовой деятельности в последние годы довольно широко применяются и в этой сфере деятельности и воспринимаются работниками, которые с ними сталкиваются каждый день, как достаточно удобное средство. Автоматизация расчетов и создание отчетов во много раз повышают эффективность и качество работы, облегчают труд операторов рабочих мест. Подписная деятельность является одной из основополагающих для всех почтовых отделений и отделений связи. Соответственно, учёт и анализ этой деятельности имеет большое значение для разработки стратегии ведения подписной кампании и привлечения максимального числа клиентов, как среди организаций, так и частных лиц. Целью данного курсового проекта является реализация информационной системы "Подписная деятельность" в архитектуре "клиент-сервер". Данная программа обладает всеми необходимыми компонентами для выполнения задач, связанных с поиском и обработкой информации, удобным графическим интерфейсом и средствами для форматированного вывода информации на печать. 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 - Результат связывания объектов модели процессов
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).Рисунок 34.2 Анализ результатов тестирования ИССНабор действий оператора и результаты работы ИСС приведены в таблице.
Приложение Б Рис. Б1 - ER-диаграмма (физический уровень) |
РЕКЛАМА
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА | ||
 |
© 2010 | |