Министерство  образования и науки Российской Федерации

      Федеральное агентство образования

      Курский институт социального образования

      (филиал)

      Российского государственного социального университета 

      Кафедра информационных систем и ЕНД 
 
 

      Курсовой  проект 
 

      по  дисциплине «Автоматизированные системы организационно-административного управления» 
 

      на  тему «АИС почтовое отделение» 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

      КУРСК 2009

СОДЕРЖАНИЕ:

ВВЕДЕНИЕ  ……………………………………………………………………. 2

1. АНАЛИЗ  ПРЕДМЕТНОЙ ОБЛАСТИ …………………………………… 4
1. Описание предметной области ……………………………………... 4
2. Анализ требований к базе данных ………………………………….. 6
2. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ …………………………………. 9
1. Методология проектирования …………………………………….… 10
1. Метод нормальных форм …………………………………….. 13
2. Метод сущность-связь ……………………………………….. 16
2. Проектирование базы данных «Почтовые отделения» …………… 21
3. РЕАЛИЗАЦИЯ БАЗЫ ДАННЫХ СРЕДСТВАМИ MS ACCESS ………. 25
1. Обзор системы управления базами данных MS Access …………… 25
2. Формирование исходных данных ………………………………….. 28
3. Бизнес-план……………………………………………………………30
4. Разработка объектов базы данных …………………………………35

      3.5Построение модели в программе  BPwin» ….………………..………..46

      3.6Организационная структура…………………………………………….48 

ЗАКЛЮЧЕНИЕ  ……………………………………………………………….. 49

СПИСОК  ЛИТЕРАТУРЫ …………………………………………………….. 51 
 
 
 
 
 
 
 
 

ВВЕДЕНИЕ

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

    Для автоматизации обработки данных в начале 70-х годов были предложены программы, специально предназначенные для управления данными – системы управления базами данных (СУБД).

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

    С ростом популярности СУБД в 70-80-х годах  появилось множество различных моделей данных. У каждой из них имелись свои достоинства и недостатки, которые сыграли ключевую роль в развитии реляционной модели данных, появившейся во многом благодаря стремлению упростить и упорядочить первые модели данных.

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

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

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

    Цель  моей работы заключается в проектировании и разработке базы данных «Почтовые отделения». Разрабатываемая мною база данных может быть использована для создания единой информационной системы почтовых отделений. В ней можно будет отслеживать пересылку писем, бандеролей, закупку печатных изданий у типографий. Моя база данных будет ограничена закупкой печатных изданий у различных типографий. В базе данных будет отслеживаться информация об известных печатных изданиях, типографиях и почтовых отделениях. Создаваемая база данных облегчит поиск почтовым отделениям необходимых изданий, а также можно будет выбрать типографию, закупка у которой данного печатного издания будет наиболее выгодной. Далее созданную базу данных можно будет расширить для использования в других целях.

Достижение  цели осуществляется посредством комплекса  задач:

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

1. АНАЛИЗ  ПРЕДМЕТНОЙ ОБЛАСТИ

    Сфера деятельности почтовых отделений характеризуется  большими массивами информации и объёмом выполняемых работ.

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

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

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

    Сведения  о почтовых отделениях должны включать в себя следующую информацию:

• уникальный шифр издания;
• название газеты или журнала;
• Ф.И.О. редактора газеты или журнала.

    Сведения о типографиях, выпускающих данные газеты или журналы, должны содержать:

• уникальный номер типографии;
• адрес типографии;
• Ф.И.О. директора типографии.

    Также в этой базе данных должны храниться  сведения о заказах, сделанных почтовыми отделениями на определённые издания. Они должны включать:

• Уникальный номер заказа;
• Номер почтового отделения, делающего заказ;
• Номер типографии, у которой делают заказ;
• Код издания, на которое делают заказ;
• Количество заказов;
• Цена доставки изданий.

    В базе данных должны содержаться сведения о тиражах выпускаемых изданий определёнными типографиями:

• Номер типографии;
• Код издания;
• Цена за один экземпляр издания;
• Код заказа;
• Тираж.

1.2. Анализ требований  к базе данных 

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

1. по изданиям:

• один и тот же человек не может быть редактором нескольких изданий одновременно;

• у нескольких изданий не может быть одинакового кода издания;

2. по типографиям:

• каждая типография должна иметь свой уникальный номер;
• несколько типографий не могут располагаться по одному почтовому адресу;
• один и тот же человек не может быть директором нескольких типографий одновременно;

3. по почтовым отделениям:

• каждое почтовое отделение должно иметь свой уникальный номер;
• несколько почтовых отделений не могут располагать по одному почтовому адресу;
• один и тот же человек не может быть директором нескольких почтовых отделений одновременно.

    С базой данных должны работать следующие  группы пользователей:

• редакторы изданий;
• служащие и начальники типографий;
• служащие и начальники почтовых отделений.

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

• об изданиях определенного типа с сортировкой их по популярности, которая основана на заказах почтовых отделений.

    Служащим  или начальнику типографии может потребоваться следующая информация:

• о тираже изданий, выпускаемых данной типографией, с указанием ФИО их редактора;
• об общем объеме заказа почтовыми отделениями каждого издания, выпускаемого на данной типографии;
• о заказах почтовыми отделениями изданий у данной типографии.

    Служащим  или начальнику почтового отделения  может потребоваться следующая  информация:

• об изданиях, заказываемых у типографий, данным почтовым отделением;
• о заказах данным почтовым отделением изданий у типографий с указанием ФИО директора типографии;
• ФИО начальника почтового отделения, на которое поступает наибольшее общее число изданий.

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

• об изданиях, учет которых ведется в базе данных;
• о типографии, в которых печатается данное издание и его тираж;
• о почтовых отделениях, в которые поступает данное издание и в каком количестве.

    В базу данных могут вноситься следующие  изменения:

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

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

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

3. служащие или начальник почтового отделения могут:

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

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

1. отчет по известным печатным изданиям, содержащий следующие данные:

• шифр, название, ФИО редактора этого издания;

• тираж и цена этого издания в различных типографиях;

2. отчет о работе типографий, содержащий следующие данные:

• номер, адрес и ФИО директора типографии;
• шифры, названия, тиражи и цены выпускаемых изданий;
• адреса рассылки (номера и адреса почтовых отделений) для каждого печатного издания;
• объем заказа и цену доставки для каждого почтового отделения;

3. отчет о работе почтовых отделений, содержащий следующие данные:

• номер, адрес и ФИО начальника почтового отделения;
• шифр, название, объем заказа и цена доставки покупаемых изданий;
• номера и адреса типографий, в которых заказаны издания.

4. отчет о работе определенного почтового отделения, содержащий следующие данные:

• номер, адрес и ФИО начальника почтового отделения;
• шифр, название, объем заказа и цена доставки покупаемых изданий;
• номера и адреса типографий – поставщиков.

2. ПРОЕКТИРОВАНИЕ БАЗЫ  ДАННЫХ 

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

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

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

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

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

2.1. Методология проектирования 

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

    Было  сформулировано принципиальное требование отделения программ от интегрированных данных. Этот принцип направлен на отчуждение данных в качестве ресурса предприятия, важен также тем, что консервативные по характеру данные отделялись от прикладных программ, которые могли часто подвергаться изменениям.

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

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

Временные характеристики и транзакции. 

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

• возможности сравнения временных параметров вариантов реализации разных вариантов схемы БД, на некоторой СУБД;
• возможности сравнения параметров вариантов реализации одной схемы БД на разных СУБД;
• возможности сравнения параметров реализации одной схемы БД на разных аппаратных серверах БД;
• возможности предсказания временных параметров работы различных прикладных программ и служебных программ-утилит.

    Задача  сравнения временных параметров разных СУБД рассматривается как  самостоятельная. Однако, она часто  должна решаться как часть проектной  задачи выбора СУБД для проектируемой БД и в процессе этого проектирования.  
Понятие транзакции было введено для определения законченной совокупности действий над БД, которая переводит БД из одного целостного в логическом смысле состояния в другое. На его базе строились, прежде всего, механизмы корректной актуализации и восстановления БД. Однако, затем на этой основе стали базироваться и другие механизмы и методы.

    Временные оценки СУБД наиболее популярных тестов последнее время даются в виде числа транзакций определенного стандартизованного вида в единицу времени. Распределенная обработка строится на основе мониторов транзакций.  
Нужно будет обнаруживать пределы возможностей такого деления работ на достаточно мелкие порции. Здесь отметим очень важный эффект: практика ориентации на "транзакционный подход" тесно связана с классической методологией проектирования БД, которая развивалась, в основном, как методология проектирования так называемы "операционных" БД, то есть баз данных, которые должны фиксировать отдельные совершаемые операции и хранить модель текущего фактического состояния объекта или ПрО.

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

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

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

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

2.1.1. Метод нормальных  форм

    Нормализация  – это приведение, к лучшей форме  относительно включения, удаление и модификации.

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

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

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

    Атрибут В функционально зависит о атрибута А, если каждому значению А соответствует в точности одно значение В (обозначение: А®В). Функциональная взаимозависимость атрибутов А и В означает, что имеется взаимнооднозначное соответствие, т.е. А®В и В®А (А«В). Функциональная частичная зависимость – зависимость неключевого атрибута от части составного ключа. Полная функциональная зависимость – зависимость неключевого атрибута от всего составного ключа.

    Атрибут С зависит от атрибута А транзитивно, если для атрибутов А,В,С выполняется условие А®В и В®С, но обратная зависимость отсутствует.

    Атрибут В многозначно зависит от атрибута А, если каждому значению А соответствует множество значений В, не связанных с другими атрибутами. Эти зависимости могут быть «один ко многим», «многие к одному» или «многие ко многим» (1:m, m:1, m:m соответственно), обозначаемые соответственно АÞВ, ВÞА и АÛВ.