Разработка ИС компании Content по доставке и отправке почты

Автор работы: Пользователь скрыл имя, 27 Февраля 2013 в 14:41, курсовая работа

Описание работы

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

Содержание работы

Аннотация 2
Глоссарий 3
Введение 4
Порядок выполнения практического задания 5
Предварительная информация 5
1. Проектирование БД 9
1.1. Анализ предметной области 9
1.2. Инфологическая модель данных 11
1.3. Даталогическая модель данных 12
2. Физическая реализация базы данных. 13
2.1. Структура таблиц БД “Content” 14
2.2. Создание Запросов 16
2.3. Создание форм 17
2.4. Создание отчетов 19
3. Проектирование деятельности почтовой компании в среде Erwin 21
4. Проектирование модели деятельности почтовой компании BPwin 24
4.1. Диаграммы декомпозиции 25
Заключение 27
Список Литературы 29

Файлы: 1 файл

Разработка ИС компании Content по доставке и отправке почты.docx

— 3.43 Мб (Скачать файл)

База данных содержит 8 запросов:

3 Запроса по получениям  и 3 запроса по отправлениям, на  вывод информации о письмах,  посылках, бандеролях в отдельности,  соответственно установив в качестве  фильтров «письма», «посылки», «бандероли».

Запрос о возможной  подписке стоимостью не более 50 грн, соответственно в поле фильтра цены установить <50.

Запрос на получение информации о подписке, которая еще действительна. В поле фильтра установив Срок подписки <DATE ()

Пример запроса используемого  в базе данных:

Запрос на получение информации о действующих подписках:

 

Рис.3.  Запрос на выборку

2.3. Создание форм

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

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

Формы создают из набора отдельных элементов управления: текстовые поля для ввода и  редактирования данных, кнопки, флажки, переключатели, списки, метки полей, а также рамки объектов для  отображения графики и объектов OLE. Простейший путь создания основной и подчинённой форм – использование  «Мастера форм», который позволяет  создавать формы, содержащие поля из одной или более таблиц или  запросов. «Мастер форм» создает  базовый внешний вид формы  и добавляет текстовые поля для  отображения и редактирования значений полей таблиц. Независимо от уровня владения компьютером использование  «Мастера форм» заметно упрощает и ускоряет процесс создания простых  форм, которые затем можно усовершенствовать  в режиме конструктора. Создание форм базы данных происходит несколькими  способами: авто формой, мастером и  конструктором. Выбираем пункт «Создание  формы с помощью мастера». Следуя указаниям «Мастера» выбираем поля для формы, которые могут браться  из разных таблиц, которые имеются  в создаваемом проекте. После  выбора полей формы выбираем внешний  вид и стиль оформления создаваемой  формы, после чего задаётся имя формы.

После создания формы можно  перейти в режим конструктора и откорректировать содержащиеся в  форме поля, кнопки и т.д.

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

 

Рис.4. Форма «Отправления»

 

 

 

 

 

 

 

 

отправка

         

подписка

сведения

   

опеации

   

сведения

письма

 

отправка

получение

подписка

 

дешевая

посылки

         

действующая

бандероли

   

получение

   

отчет

отчет

   

сведения

     
     

письма

     
     

посылки

     
     

бандероли

     
     

отчет

     



 

Схема связи форм

2.4. Создание отчетов

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

В основном отчёты проще  всего построить при помощи «Мастера отчётов». Он старается создать оптимальный  вариант окончательного отчёта с  первой попытки. Обычно мастер в достаточной  степени приближается к законченному варианту, так что тратиться намного  меньше времени на редактирование базового отчёта мастера.

В базе данных используется 3 отчета: отправления, получения, подписка

Пример отчета, используемого  в базе данных:

Рис.5. Отчет «Подписка»

Рис.6. Отчеты

3. Проектирование деятельности  почтовой компании в среде Erwin

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

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

 

 


 

 

 

 

 

 

 

 

 

 

 

 

 

ERwin имеет два уровня представления модели: логический и физический. Создание модели данных начинается с создания логической модели.

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

Логическая модель – это  абстрактный взгляд на данные, на нем  данные представляются так, как выглядят в реальном мире и могут называться так, как они называются в реальном мире. Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами.

Рис.7. Логическая модель БД

 

Стоит обратить внимание на то, что не все связи между сущностями одинаковы на модели представленной выше. Связь  показывает отношения между сущностями 1 к 1 или ко многим, а связь 1 к 0, 1 или ко многим.

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

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

Для проектирования физической модели БД воспользуемся CASE-средством  All Fusion ERwin Data Modeler. В данном программном продукте в качестве имени таблицы на физическом уровне используется имя сущности на логической модели БД. Но Inter Base не допускает символов кириллицы в именах объектов. В связи с этим произведем переименования вручную.

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

Результатом диагностики  ошибок может стать отчет или  SQL-скрипт, корректирующий ошибки моделирования. Ниже приведен фрагмент корректирующего кода, сгенерированного для INTER BASE.

CREATE TABLE abonent_post (

postNumber  INTEGER,

t_first_name VARCHAR(20),

t_addres VARCHAR(20),

t_telepfone VARCHAR(20),

t_primechanie VARCHAR(20),

t_number_kartochki INTEGER NOT NULL,

t_name VARCHAR(20),

t_cod_chitatel INTEGER NOT NULL,

t_other_name VARCHAR(20)

);

4. Проектирование модели  деятельности почтовой компании BPwin

 

Контекстная диаграмма (А-0) является вершиной древовидной структуры  диаграмм и представляет собой общее  описание системы и ее взаимодействия с внешней средой (Рис.8.)

Рис.8. Контекстная диаграмма

 

Основные информационные потоки:

- Входящие потоки:

  • Данные о клиентах (паспортные данные клиентов);
  • Данные о почте (название, год, адрес и др.).

 

- Управляющие потоки:

  • Составление статистики поступления почты;
  • Методика подсчета рейтинга клиентов и регионов.

 

- Ресурсные потоки:

  • База данных почтовой фирмы
  • Почтальон.

 

- Выходящие потоки:

  • Статистика посещения клиентами почты (график);
  • Рейтинг почтовых направлений (график).

 

Созданная модель описывает  деятельность почтовой фирмы.

Объектом моделирования  является почтовая фирма.

Система рассматривается  с точки зрения директора почтовой фирмы.

4.1. Диаграммы декомпозиции

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

После декомпозиции контекстной  диаграммы «Почтовая система» возникло пять диаграмм декомпозиции:

  • Управление личными карточками работников;
  • Управление карточками клиентами;
  • Выдача/прием почты;
  • Получение рейтинга регионов;
  • Получение статистики посещений.

Рис.9. Диаграммы декомпозиции

 

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

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

Выдача/прием почты. Регулируется также нормативно-правовыми актами о деятельности почты. При выдаче почты в базе данных необходимо фиксировать: (название, дату выдачи, ФИО получателя, которому выдается почта, ФИО сотрудника, выдающему почту, ФИО сотрудника хранилища, который передал почту (непосредственно из хранилища) сотруднику, срок, когда выдается)

 

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

Основные статистические показатели: (учет получателей, учет выдачи почты).

Заключение

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

Информация о работе Разработка ИС компании Content по доставке и отправке почты