Автор работы: Пользователь скрыл имя, 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
Основными целями проекта автоматизации компании “Content” являются:
—Разработка и внедрение комплексной автоматизированной системы отслеживания почтовых грузов в процессе доставки.
—Повышение эффективности
База данных - поименная совокупность структурированных данных, относящихся к определенной предметной области. Под предметной областью принято понимать часть реального мира, подлежащую изучению для организации управления и автоматизации (предприятия, организации). Анализ предметной области позволяет определить, какие данные содержатся в БД. Пользователями БД могут быть различные прикладные программы, программы-комплексы, а также специалисты предметной области, которые называются конечными пользователями.
Модель предметной области. Модель предметной области - это наши знания о предметной области. Знания могут быть как в виде неформальных знаний в мозгу эксперта, так и выражены формально при помощи каких-либо средств. В качестве таких средств могут выступать текстовые описания предметной области, наборы должностных инструкций, правила ведения дел в компании и т.п. Опыт показывает, что текстовый способ представления модели предметной области крайне неэффективен. Гораздо более информативными и полезными при разработке баз данных являются описания предметной области, выполненные при помощи специализированных графических нотаций. Имеется большое количество методик описания предметной области. Из наиболее известных можно назвать методику структурного анализа SADT и основанную на нем IDEF0, диаграммы потоков данных Гейна-Сарсона, методику объектно-ориентированного анализа UML, и др. Модель предметной области описывает скорее процессы, происходящие в предметной области и данные, используемые этими процессами. От того, насколько правильно смоделирована предметная область, зависит успех дальнейшей разработки приложений.
Сфера деятельности почтовых
отделений характеризуется
Задача почтовых отделений
заключается в своевременной
доставке газет, журналов, писем, телеграмм,
бандеролей жителям своих районов.
Для этого им необходима единая информационная
система, в которой будет отслеживаться
поступление и последующая
В рамках проекта развертывание новой системы предполагается осуществить только в следующих подразделениях “Content”.
Одно из основных требований компании “Content” к будущему решению состоит в том, чтобы оно было построено на фундаменте единой интегрированной системы, а работа всех сотрудников велась в одном информационном пространстве.
Ключевые функциональные требования к информационной системе:
Информационно-логическая модель
отображает данные предметной области
в виде совокупности информационных
объектов и связей между ними. Эта
модель представляет данные, подлежащие
хранению в базе данных. При разработке
модели данных могут использоваться
два подхода. В первом подходе
сначала определяются основные задачи,
для решения которых строится
база, и выявляются потребности задач
в данных. При втором подходе сразу
устанавливаются типовые
База данных «Почтовое отделение» содержит следующие сущности:
Связь «получает» - М:1-несколько получений, являются лишь одной операцией получения.
Связь «отправляет» - М:1-несколько отправлений, являются лишь одной операцией отправления.
Связь «подписывает» - М:1-несколько подписок, являются лишь одной операцией подписка.
Связь «подписывается» - 1:М - один подписчик может оформить несколько подписок.
Связь «заказывает» - 1:М – на одно издание можно оформить несколько подписок.
Рис.1. Инфологическая модель БД «Почтовое отделение».
Для создания эффективной базы данных важно правильно определить структуру таблиц, то есть состав полей. На этом этапе нужно руководствоваться следующими соображениями:
Рассмотрим более подробно каждую из сущностей и атрибуты, которые они должны содержать. Так же опишем непосредственно типы данных, которые должны браться для каждого из атрибутов в практической реализации базы данных. Причём типы данных могут иметь несколько иные названия в определённых, отдельно взятых СУБД.
В соответствии с данными инфологической и даталогической моделями уже можно приступать к непосредственному созданию реальной базы данных в оболочке SQL Server 2000.
Физическая модель данных описывает данные средствами конкретной СУБД. Мы будем считать, что физическая модель данных реализована средствами именно реляционной СУБД, хотя, как уже сказано выше, это необязательно. Отношения, разработанные на стадии формирования логической модели данных, преобразуются в таблицы, атрибуты становятся столбцами таблиц, для ключевых атрибутов создаются уникальные индексы, домены преображаются в типы данных, принятые в конкретной СУБД.
Ограничения, имеющиеся в логической модели данных, реализуются различными средствами СУБД, например, при помощи индексов, декларативных ограничений целостности, триггеров, хранимых процедур. При этом опять-таки решения, принятые на уровне логического моделирования определяют некоторые границы, в пределах которых можно развивать физическую модель данных. Точно также, в пределах этих границ можно принимать различные решения. Например, отношения, содержащиеся в логической модели данных, должны быть преобразованы в таблицы, но для каждой таблицы можно дополнительно объявить различные индексы, повышающие скорость обращения к данным. Многое тут зависит от конкретной СУБД.
При разработке физической модели данных возникают вопросы: хорошо ли спроектированы таблицы? Правильно ли выбраны индексы? Насколько много программного кода в виде триггеров и хранимых процедур необходимо разработать для поддержания целостности данных?
И, наконец, как результат предыдущих этапов позволяет собственно сама база данных. База данных реализована на конкретной программно-аппаратной основе, и выбор этой основы позволяет существенно повысить скорость работы с базой данных. Например, можно выбирать различные типы компьютеров, менять количество процессоров, объем оперативной памяти, дисковые подсистемы и т.п. Очень большое значение имеет также настройка СУБД в пределах выбранной программно-аппаратной платформы.
Но опять решения, принятые на предыдущем уровне - уровне физического проектирования, определяют границы, в пределах которых можно принимать решения по выбору программно-аппаратной платформы и настройки СУБД.
Таким образом ясно, что решения, принятые на каждом этапе моделирования и разработки базы данных, будут сказываться на дальнейших этапах. Поэтому особую роль играет принятие правильных решений на ранних этапах моделирования
Таблица 1. «Операционный отдел»
Таблица 2. «Отдел ЖД перевозок»
Таблица 3. «Отдел авиа-перевозок»
Таблица 4. «Отдел авто-перевозок»
Таблица 5. «Таможенный отдел»
Таблица 6. «Бухгалтерия»
Таблица 7. IT- менеджер
.
Таблица 8. Офис менеджер
.
Таблица 9. Дирекция
.
Таблица 10. Офисные сотрудники
Рис.2. Связи между таблицами в базе данных
Одним из основных назначений разработанного приложения является быстрый поиск информации в базе данных и получение ответов на разнообразные вопросы. Для этих целей используются средства, называемые запросами.
Для создания запросов вы можете использовать мастер запросов, который последовательно запрашивает наименования таблиц, используемых в запросе, перечень полей таблиц, критерий упорядочения и условия фильтрации данных.
Для того чтобы создать запрос, необходимо выбрать запросы в менеджере проектов и выбрать на панели создать. После чего откроется окно «Новый запрос» в котором необходимо выбрать, с помощью чего вы хотите создать запрос. Запросы можно создавать с помощью: конструктора, мастера. При выборе конструктора запросов, мы видим, что окно разделено на две панели. Верхняя панель содержит выбранные для данного запроса таблицы. Таблицы представлены списками полей. Нижняя панель является бланком запроса, который нужно заполнить.
При формировании столбца бланка запроса необходимо знать следующее:
Информация о работе Разработка ИС компании Content по доставке и отправке почты