Загрузка...
Учебная работа. Реферат: АИС почтовое отделение
Федеральное агентство образования
Курский институт общественного образования
(филиал)
Русского муниципального общественного института
Кафедра информационных систем и ЕНД
Курсовой проект
по дисциплине «Автоматические системы организационно-административного управления»
на тему «АИС почтовое отделение»
КУРСК 2009
СОДЕРЖАНИЕ:
ВВЕДЕНИЕ ……………………………………………………………………. 2
1. анализ ПРЕДМЕТНОЙ ОБЛАСТИ …………………………………… 4
1.1. Описание предметной области ……………………………………… 4
1.2. анализ требований к базе данных ………………………………….. 6
2. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ …………………………………. 9
2.1. Методология проектирования …………………………………….… 10
2.1.1.способ обычных форм …………………………………….. 13
2.1.2.Способ сущность-связь ……………………………………….. 16
2.2. Проектирование базы данных «Почтовые отделения» …………… 21
3. РЕАЛИЗАЦИЯ БАЗЫ ДАННЫХ СРЕДСТВАМИ MSACCESS ………. 25
3.1. Обзор системы управления базами данных MSAccess …………… 25
3.2. Формирование начальных данных ………………………………….. 28
3.3. бизнес-план……………………………………………………………30
3.4. Разработка объектов базы данных …………………………………35
3.5Построение модели в программке BPwin» ….………………..………..46
3.6Организационная структура…………………………………………….48
ЗАКЛЮЧЕНИЕ ……………………………………………………………….. 49
СПИСОК ЛИТЕРАТУРЫ …………………………………………………….. 51
ВВЕДЕНИЕ
В истинные время в связи с развитием компьютерной техники возникла возможность заавтоматизировать почти все процессы, также возрос размер обрабатываемой инфы. И появилась беспристрастная необходимость заавтоматизировать огромную часть сферы людской деятельности.
Для автоматизации обработки данных сначала 70-х годов были предложены программки, специально созданные для управления данными – системы управления базами данных (СУБД).
В самом общем смысле база данных
– совокупа особым образом организованных данных, хранимых в памяти вычислительной системы и отображающих состояние объекта и их взаимосвязей в рассматриваемой предметной области. В базе данных может храниться огромное количество таблиц с однотипными записями. один из типов баз данных — это документы, набранные при помощи редакторов текста и сгруппированные по темам. иной тип — файлы электрических таблиц, объединяемые в группы по количество разных моделей данных. У каждой из их имелись свои плюсы и недочеты, которые сыграли главную роль в развитии реляционной модели данных, показавшейся почти во всем благодаря рвению упростить и упорядочить 1-ые модели данных.
Зависимо от метода установления связей меж данными с компьютерно–нацеленным описанием на языке определенной СУБД, разрабатывались разные модели логической организации данных: иерархическая, сетевая и реляционная.
Внедрение баз данных и информационных систем становится неотъемлемой составляющей деловой деятель современного человека и функционирования преуспевающих организаций. В связи с сиим огромную актуальность приобретает освоение принципов построения и действенного внедрения соответственных технологий и программных товаров: систем управления базами данных, CASE-систем автоматизации проектирования, средств администрирования и защиты баз данных и остальных.
От правильного набора инструментальных средств сотворения информационных систем, определения пригодной модели данных, обоснования рациональной схемы построения баз данных, организация запросов к хранимым данным и ряда остальных моментов почти во всем зависят эффективность функционирования разрабатываемых систем. Все это просит осознанного внедрения теоретических положений и инструментальных средств разработки баз данных и информационных систем.
Цель моей работы заключается в проектировании и разработке базы данных «Почтовые отделения». Разрабатываемая мною база данных быть может применена для сотворения единой информационной системы почтовых отделений. В ней можно будет выслеживать пересылку писем, бандеролей, закупку печатных изданий у типографий. Моя база данных будет ограничена закупкой печатных изданий у разных типографий. В базе данных будет отслеживаться информация о узнаваемых печатных изданиях, типографиях и почтовых отделениях. Создаваемая база данных облегчит поиск почтовым отделениям нужных изданий, также можно будет избрать типографию, закупка у которой данного печатного издания будет более прибыльной. Дальше сделанную базу данных можно будет расширить для использования в остальных целях.
Достижение цели осуществляется средством комплекса задач:
— проектирование и создание таблиц для хранения данных;
— ввод данных;
— разработка остальных частей базы, созданных для просмотра, редактирования и вывода инфы.
1.
анализ ПРЕДМЕТНОЙ ОБЛАСТИ
Сфера деятельности почтовых отделений характеризуется большенными массивами инфы и объёмом выполняемых работ.
Задачка почтовых отделений заключается в своевременной доставке газет, журналов, писем, телеграмм, бандеролей жителям собственных районов. Для этого им нужна единая информационная система, в какой будет отслеживаться поступление и следующая доставка всех писем, телеграмм и бандеролей популяции и разным организациям, также доставка газет и журналов по подписке на потовых отделениях популяции и организациям. Свойство и своевременность доставки писем, телеграмм и бандеролей будет зависеть от того, как обмыслены каналы обмена ими меж почтовыми отделениями и конкретная их доставка получателям. А доставка газет и журналов жителям и организациям, которые подписались на их получение, зависит от своевременного заказа нужных газет и журналов на типографиях, оплаты и доставки их на почтовые отделения, также от своевременной их доставки получателям.
Моя цель – создать базу данных для почтовых служащих, работающих в единой системе почтовых отделений. Она обязана показывать весь список газет и журналов, которые имеются в наличии, также Создание их на типографиях и заказы почтовых отделений газет и журналов у этих типографий с следующей оплатой и получением нужных партий.
Описание предметной области
В базе данных должны храниться сведения о почтовых отделениях, газетах и журнальчиках, поступающих в почтовое отделение, и типографиях, их выпускающих.
Сведения о почтовых отделениях должны включать в себя последующую информацию:
— неповторимый шифр издания;
— заглавие газеты либо журнальчика;
— Ф.И.О. редактора газеты либо журнальчика.
Сведения о типографиях, выпускающих данные газеты либо журнальчики, должны содержать:
— неповторимый номер типографии;
— адресок типографии;
— Ф.И.О. директора типографии.
Также в данной нам базе данных должны храниться сведения о заказах, изготовленных почтовыми отделениями на определённые издания. Они должны включать:
— Неповторимый номер заказа;
— Номер почтового отделения, делающего заказ;
— Номер типографии, у которой делают заказ;
— Код издания, на которое делают заказ;
— Количество заказов;
— Стоимость доставки изданий.
В базе данных должны содержаться сведения о тиражах выпускаемых изданий определёнными типографиями:
— Номер типографии;
— Код издания;
— Стоимость за один экземпляр издания;
— Код заказа;
— Тираж.
1.2. анализ требований к базе данных
На информацию, лежащую в базе данных, накладываются последующие ограничения:
1. по изданиям:
– один и этот же человек не быть может редактором нескольких изданий сразу;
– у нескольких изданий не быть может схожего кода издания;
2. по типографиям:
– любая типография обязана иметь собственный неповторимый номер;
– несколько типографий не могут размещаться по одному почтовому адресу;
– один и этот же человек не быть может директором нескольких типографий сразу;
3. по почтовым отделениям:
– каждое почтовое отделение обязано иметь собственный неповторимый номер;
– несколько почтовых отделений не могут располагать по одному почтовому адресу;
– один и этот же человек не быть может директором нескольких почтовых отделений сразу.
С базой данных должны работать последующие группы юзеров:
– редакторы изданий;
– служащие и начальники типографий;
– служащие и начальники почтовых отделений.
Редакторам изданий может потребоваться последующая информация:
– о изданиях определенного типа с сортировкой их по популярности, которая базирована на заказах почтовых отделений.
Служащим либо начальнику типографии может потребоваться последующая информация:
– о тираже изданий, выпускаемых данной типографией, с указанием ФИО их редактора;
– о общем объеме заказа почтовыми отделениями всякого издания, выпускаемого на данной типографии;
– о заказах почтовыми отделениями изданий у данной типографии.
Служащим либо начальнику почтового отделения может потребоваться последующая информация:
– о изданиях, заказываемых у типографий, данным почтовым отделением;
– о заказах данным почтовым отделением изданий у типографий с указанием ФИО директора типографии;
– ФИО начальника почтового отделения, на которое поступает наибольшее общее число изданий.
Юзерам данной нам базы данных может потребоваться также последующая информация:
– о изданиях, учет которых ведется в базе данных;
– о типографии, в каких печатается данное издание и его тираж;
– о почтовых отделениях, в которые поступает данное издание и в котором количестве.
В базу данных могут вноситься последующие конфигурации:
1. редакторы изданий могут добавлять информацию о собственном издании, изменять либо удалять ее из базы данных;
2. служащие либо начальник типографии могут:
– добавлять информацию о собственной типографии, изменять либо удалять ее из базы данных;
– добавлять информацию о выпуске на собственной типографии изданий, изменять либо удалять ее из базы данных;
3. служащие либо начальник почтового отделения могут:
– добавлять информацию о собственном почтовом отделении, изменять либо удалять ее из базы данных;
– добавлять информацию о собственном заказе на типографии изданий, изменять либо удалять ее из базы данных.
Юзерам, работающим с данной базой данных, нужны последующие отчеты:
1. отчет по известным печатным изданиям, содержащий последующие данные:
– шифр, заглавие, ФИО редактора этого издания;
– тираж и стоимость этого издания в разных типографиях;
2. отчет о работе типографий, содержащий последующие данные:
– номер, адресок и ФИО директора типографии;
– шифры, наименования, тиражи и цены выпускаемых изданий;
– адреса рассылки (номера и адреса почтовых отделений) для всякого печатного издания;
– размер заказа и стоимость доставки для всякого почтового отделения;
3. отчет о работе почтовых отделений, содержащий последующие данные:
– номер, адресок и ФИО начальника почтового отделения;
– шифр, заглавие, размер заказа и стоимость доставки покупаемых изданий;
– номера и адреса типографий, в каких заказаны издания.
4. отчет о работе определенного почтового отделения, содержащий последующие данные:
– номер, адресок и ФИО начальника почтового отделения;
– шифр, заглавие, размер заказа и стоимость доставки покупаемых изданий;
– номера и адреса типографий – поставщиков.
2. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ
процесс проектирования базы данных представляет собой последовательность переходов от неформального словесного описания информационной структуры предметной области к нормализованному описанию объектов предметной области в терминах некой модели.
Проектирование БД является весьма принципиальным шагом, от которого зависят следующие этапы разработки СУБД (системы управления базами данных). Время, затраченное разрабом на проектирование БД, обычно окупается высочайшей скоростью реализации проекта.
Перед созданием базы данных нужно располагать описанием избранной предметной области, которое обязано обхватывать настоящие объекты и процессы, иметь всю нужную информацию для ублажения предполагаемых запросов юзера и найти потребности в обработке данных.
На базе такового описания на шаге проектирования базы данных осуществляется определение состава и структуры, данных предметной области, которые должны находиться в базе данных и обеспечивать выполнение нужных запросов и задач юзера. структура данных предметной области может отображаться информационно-логической моделью. На базе данной нам модели просто создается реляционная база данных.
Информационно-логическая модель показывает данные предметной области в виде совокупы информационных объектов и связей меж ними. Эта модель представляет данные, подлежащие хранению в базе данных.
При разработке модели данных могут употребляться два подхода. В первом подходе поначалу определяются главные задачки, для решения которых строится база, и выявляются потребности задач в данных. При втором подходе сходу инсталлируются типовые объекты предметной области. Более правильно сочетание обоих подходов. Это соединено с тем, что на исходном шаге, как правило, нет исчерпающих сведений обо всех задачках. Внедрение таковой технологии тем наиболее оправдано, что гибкие средства сотворения реляционной базы данных в Access разрешают на любом шаге разработки внести конфигурации в базу данных и видоизменять ее структуру без вреда для введенных ранее данных.
2.1. Методология проектирования
Обширно известные способы проектирования баз данных (БД) возникли в процессе разработки все наиболее сложных Информационных Систем (ИС), которые должны были разглядывать потребности не 1-го юзера, но огромных групп и обществ. одна таковая встроенная БД создавалась для решения почти всех задач, любая из которых употребляла лишь «свою» часть данных, обычно, пересекающуюся с частями, применяемыми в остальных задачках. Потому главнейшими способами проектирования стали способы исключения избыточности в данных. Эти способы связывались с иными средствами обеспечения логической целостности данных.
Было сформулировано принципное требование отделения программ от встроенных данных. Этот принцип ориентирован на Отчужде данных в качестве ресурса компании, важен также тем, что ограниченные по могли нередко подвергаться изменениям.
Иной принципиальной неувязкой проектирования БД явилось обеспечение подходящих эксплуатационных характеристик, таковых как размер наружной памяти либо время выполнения разных операций. Известны и остальные требования. к примеру, информация не обязана потеряться не только лишь из-за отказов оборудования, да и вследствие ошибки юзера. Это различается от того положения, при котором тот, кто решает некоторую задачку, сам и отвечает за сохранность данных для данной нам задачки.
Сформировалось осознание встроенной БД как общего информационного ресурса компании. Хранимые данные стали подобны большенному компу, который сразу употребляется почти всеми юзерами с разными целями и должен быть всегда работоспособен.
Временные свойства и транзакции.
Обеспечение эксплуатационных черт БД — как и раньше сложная задачка, невзирая на увеличение удельной мощности компов и понижение удельной цены памяти. При всем этом определение временных черт работы с БД и сохранение этих черт в процессе использования БД относится к труднейшим проектным задачкам. На шагах проектирования для определения рациональной физической схемы БД от методов определения временных черт необходимо последующее:
· способности сопоставления временных характеристик вариантов реализации различных вариантов схемы БД, на некой СУБД;
· способности сопоставления характеристик вариантов реализации одной схемы БД на различных СУБД;
· способности сопоставления характеристик реализации одной схемы БД на различных аппаратных серверах БД;
· способности пророчества временных характеристик работы разных прикладных программ и служебных программ-утилит.
задачка сопоставления временных характеристик различных СУБД рассматривается как самостоятельная. Но, она нередко обязана решаться как часть проектной задачки выбора СУБД для проектируемой БД и в процессе этого проектирования.
понятие транзакции было введено для определения законченной совокупы действий над БД, которая переводит БД из 1-го целостного в логическом смысле состояния в другое. На его базе строились, до этого всего, механизмы корректной актуализации и восстановления БД. Но, потом на данной нам базе стали базироваться и остальные механизмы и способы.
Временные оценки СУБД более фаворитных тестов крайнее время даются в виде числа транзакций определенного стандартизованного вида в единицу времени. Распределенная обработка строится на базе мониторов транзакций.
необходимо будет обнаруживать пределы способностей такового деления работ на довольно маленькие порции. тут отметим весьма принципиальный эффект: практика ориентации на «транзакционный подход» тесновато связана с традиционной методологией проектирования БД, которая развивалась, в главном, как методология проектирования так именуемы «операционных» БД, другими словами баз данных, которые должны фиксировать отдельные совершаемые операции и хранить модель текущего фактического состояния объекта либо ПрО.
При проектировании структур данных для автоматических систем производится сбор инфы о объектах предметной области в рамках одной таблицы (дела), а позже производится следующая ее декомпозиция на несколько взаимосвязанных таблиц на базе процедуры нормализации отношений. При определении структур данных в отношениях реляционной модели есть две главные препядствия: лишнее дублирование данных и аномалии.
Следует различать обычное (неизбыточное) и лишнее дублирование
данных
. наличие обычного дублирования допускается в базе данных, а лишнее может приводить к дилеммам при обработке данных.
Аномалиями
именуют такую таблицу в базе данных, которая приводит к противоречиям в базе данных либо значительно усложняет обработку данных. Выделяют три главных вида аномалий: аномалии модификации, удаления и прибавления. Аномалии модификации появляются в том, что изменение 1-го значения может повлечь за собой просмотр всей таблицы и надлежащие конфигурации остальных записей таблицы. Аномалии удаления заключаются в том, что при удалении какого-нибудь значения из таблицы может пропасть и иная информация, которая не связана на прямую с удаляемым значением. Аномалии прибавления появляются в вариантах, когда информацию в таблицу недозволено поместить до того времени, пока она не полная, или вставка новейшей записи просит доп просмотра таблицы.
От избыточности данных и разных аномалий можно избавиться при помощи нормализации отношений.
2.1.1. способ обычных форм
Нормализация – это приведение, к наилучшей форме относительно включения, удаление и модификации.
процесс проектирования баз данных с внедрением способа обычных форм является итерационным и заключается в поочередном переводе отношений из первой обычной формы в обычные формы наиболее высочайшего порядка по определенным правилам. Любая последующая обычная форма ограничивает определенный тип многофункциональных зависимостей, избавляет надлежащие аномалии при выполнении операций над отношениями базы данных и сохраняет характеристики предыдущих обычных форм.
Для определения структуры каждой таблицы нужно выполнить анализ многофункциональных зависимостей, т. е. узнать какие поля зависят от остальных полей, а потом поля с схожей зависимостью организовать в отдельную таблицу. Таковым образом, в одну и туже таблицу не необходимо включать поля, являющиеся случайными от остальных полей. В итоге количество нужных таблиц определяется числом многофункциональных зависимостей. Формально нормализация данных обеспечена, если набор таблиц удовлетворяет первым трем правилам, которые именуются нормальными формами.
Этот способ является традиционным способом проектирования реляционной базы данных. Он основан на понятии зависимости меж атрибутами
отношений. Есть последующие главные виды зависимостей: многофункциональные, транзитивные и неоднозначные.
Атрибут В функционально
зависит о атрибута А, если любому значению А соответствует в точности одно части составного ключа. Полная многофункциональная зависимость – зависимость неключевого атрибута от всего составного ключа.
Атрибут С зависит от атрибута А транзитивно
, если для атрибутов А,В,С производится условие А®В и В®С, но оборотная зависимость отсутствует.
Атрибут В неоднозначно
зависит от атрибута А, если любому значению А соответствует огромное количество значений В, не связанных с иными атрибутами. Эти зависимости могут быть «один ко почти всем», «почти все к одному» либо «почти все ко почти всем» (1:m, m:1, m:m соответственно), обозначаемые соответственно АÞВ, ВÞА и АÛВ.
Два и наиболее атрибута именуются взаимнонезависимыми,
если не один из этих атрибутов не является функционально-зависимым от остальных атрибутов (В не зависит от А: АØ®В; взаимнонезависимы: АØ =В).
процесс проектирования базы данных с внедрением способа обычных форм
является итерационным и заключается в поочередном переводе дела из первой обычной формы (НФ) в нормальную форму наиболее высочайшего порядка по определенным правилам. Перевод дела в последующую нормальную форму осуществляется способом декомпозиции без утрат, главный операцией этого способа является
Отношение находится в 2НФ
, если оно находится в 1НФ, и любой неключевой атрибут функционально-полно зависит от первичного ключа.
Отношение находится в 3НФ
, если оно находится в 2НФ и любой неключевой атрибут нетранзитивно зависит от первичного ключа. Отношение находится в 3НФ
в том и лишь в том случае, если все неключевые атрибуты дела взаимнонезависимы и на сто процентов зависят от первичного ключа.
Если в отношении имеется зависимость атрибутов составного ключа от неключевых атрибутов, то необходимо перейти к БКНФ. Отношение находится в БКНФ
, если оно находится в 3НФ, и в нем отсутствуют зависимости ключей от неключевых атрибутов.
4НФ
. В случайном отношении R(A,B,C) может сразу существовать неоднозначная зависимость АÞВ и АÞС. Это событие обозначим как АÞВ|С, т.е. атрибуты В и С неоднозначно зависят от А.
Аксиома Фейджина
: отношение R(A,B,C) можно спроецировать без утрат в отношение R1
(A,B) и R2
(A,C) в том и лишь в том случае, когда существует зависимость АÞВ|С.
Отношение R находится в 4НФ
в том и лишь в том случае, когда существует неоднозначная зависимость АÞВ, а все другие атрибуты R функционально зависят от А.
5НФ
. Результатом нормализации прошлых отношений были два новейших дела, время от времени это создать не удается либо дела заранее имеют ненужные характеристики. В этом случае делают декомпозицию дела наиболее чем на два дела.
Отношение R(X,Y,…,Z) удовлетворяет зависимости соединения, которое обозначим как *(X,Y,…,Z), в том и лишь в том случае, если R восстанавливается без утрат методом соединения собственных проекций на X,Y,…,Z.
Отношение R находится в 5НФ
либо обычной форме проекции-соединения (PJ/NF) в том и лишь в том случае, когда неважно какая зависимость соединения в R следует из существования некого вероятного ключа в R.
Эта форма является крайней из узнаваемых, условия ее получения достаточно нетривиальны и потому она практически не употребляется на практике. Наиболее того, она имеет определенные недочеты, потому на практике обычно ограничиваются структурой базу данных, соответственной 3НФ либо БКНФ.
2.1.2. способ сущность-связь
Моделирование структуры базы данных с помощью метода нормализации, описанного в прошлых главах, имеет суровые недочеты:
Первоначальное размещение всех атрибутов в одном отношении является весьма ненатуральной операцией. Интуитивно разраб сходу проектирует несколько отношений в согласовании с найденными сущностями. Даже если совершить насилие над собой и сделать одно либо несколько отношений, включив в их все предполагаемые атрибуты, то совсем неясен смысл приобретенного дела.
Нереально сходу найти полный перечень атрибутов. Юзеры имеют привычку именовать различными именами одни и те же вещи либо напротив, именовать одними именами различные вещи.
Для проведения процедуры нормализации нужно выделить зависимости атрибутов, что тоже весьма нелегко, т.к. нужно очевидно выписать все зависимости
, даже те, которые являются явными.
В настоящем проектировании структуры базы данных используются иной способ — так называемое, семантическое моделирование
. Семантическое моделирование представляет собой моделирование структуры данных, делая упор на смысл этих данных. В качестве инструмента семантического моделирования употребляются разные варианты диаграмм сущность-связь
(
).
1-ый вариант модели сущность-связь был предложен в 1976 г. Питером Пин-Шэн Ченом . В предстоящем почти всеми создателями были разработаны свои варианты схожих моделей (нотация Мартина, нотация IDEF1X, нотация Баркера и др.). Не считая того, разные программные средства, реализующие одну и ту же нотацию, могут различаться своими способностями. На самом деле, все варианты диаграмм сущность-связь исходят из одной идеи — набросок постоянно нагляднее текстового описания. Все такие диаграммы употребляют графическое изображение сущностей предметной области, их параметров (атрибутов), и взаимосвязей меж сущностями.
Мы опишем работу с ER-диаграммами близко к нотации Баркера, как достаточно легкой в осознании главных мыслях. Данная глава является быстрее иллюстрацией способов семантического моделирования, чем всеполноценным введением в эту область.
Не считая способа обычных форм Кодда для проектирования огромных баз данных употребляют способ ER-диаграмм (способ сущность-связь). На крайнем шаге способа ER-диаграмм приобретенные дела анализируют на принадлежность к БКНФ.
Главными понятиями этого способа являются последующие: суть; атрибут сути; ключ сути; связь меж сущностями, степень связи, класс принадлежности экземпляров сути; диаграммы ER-экземпляров и диаграммы ER-типа.
Суть
представляет собой объект, информация о котором хранится в базе данных. Экземпляры сути различаются друг от друга и совершенно точно идентифицируются. Наименованиями сути являются, как правило, существительные, к примеру, ИЗДАНИЕ, ТИПОГРАФИЯ и т.д. Атрибут сути
– свойство сути. Ключ сути
– атрибут либо набор атрибутов, применяемый для идентификации экземпляра сути. Связь сути
– зависимость меж атрибутами этих сущностей, заглавие связи обычно представляется глаголами.
С целью увеличения наглядности и удобства проектирования употребляют последующие графические средства: диаграммы ER-экземпляра; диаграммы ER-типов либо ER-диаграммы. При построении диаграмм ER-типов учитывается степень связи и класс принадлежности, которые выявляются на базе анализа диаграмм ER-экземпляров. Степень связи
охарактеризовывает связь меж сущностями, которая быть может один к одному (1:1), один ко почти всем (1:М), много к одному (М:1), много ко почти всем (М:М).. Степень означается знаками на полосы связи. Класс принадлежности
быть может неотклонимым либо необязательным. Класс принадлежности является неотклонимым в том случае, если все экземпляры данной нам сути непременно участвуют в данной нам связи. В неприятном случае класс принадлежности является необязательным.
Под каждым блоком, подходящим некой сути указывается ее ключ, выделяемый подчеркиванием. Многоточие за главными атрибутами значит, что вероятны остальные атрибуты сути, но ни один из их не быть может частью ее ключа. Эти атрибуты выявляются опосля формирования дела.
Этапы проектирования
процесс проектирования базы данных является итерационным, т.е. допускающим возврат к предшествующим шагам для пересмотра ранее принятых решений, и включает последующие этапы:
1. выявление сущностей и связей меж ними;
2. построение диаграмм ER-типа с учетом всех сущностей и их связей;
3. формирование набора подготовительных отношений с указанием предполагаемого первичного ключа для всякого дела;
4. добавление неключевых атрибутов в дела;
5. приведение подготовительных отношений к БКНФ при помощи способа обычных форм;
6. пересмотр ER-диаграмм в последующих вариантах:
– некие дела не приводятся к БКНФ;
– неким атрибутам не находится логически-обоснованных мест в подготовительных отношениях.
Опосля преобразования ER-диаграмм осуществляется повторное выполнение прошлых шагов проектирования.
Правила формирования отношений:
1. Если степень связи 1:1 и класс принадлежности обеих сущностей неотклонимы, то формируется одно отношение. Первичным ключом этого дела быть может ключ хоть какой сути.
2. Если степень связи 1:1 и класс принадлежности первой сути обязателен, а иной нет, то под каждую из сущностей выделяется по отношению с первичными ключами, являющимся ключами соответственных сущностей. Дальше к отношению, суть которого имеет неотклонимый класс принадлежности, добавляется в качестве атрибута ключ сути с необязательным классом принадлежности.
3. Если степень связи 1:1 и класс принадлежности обеих сущностей необязателен, то необходимо применять три дела: два дела соответствуют связываемым сущностям, ключи которых являются первичными в этих отношениях; третье отношение является связным меж первыми 2-мя, потому его ключ соединяет воединыжды главные атрибуты связываемых отношений.
4. Если степень связи меж сущностями 1:М либо М:1 и класс принадлежности М-связной неотклонимый, то довольно формирования 2-ух отношений, по одному на каждую из сущностей. Каждое отношение будет иметь свои первичные ключи, и, не считая того, ключ 1-связной сути добавляется в отношение М-связной сути.
5. Если степень связи 1:М либо М:1 и класс принадлежности М-связной сути является необязательным, то нужно формирование 3-х отношений: два дела соответствуют связываемым сущностям, ключи которых являются первичными в этих отношениях; третье отношение является связным и его ключ соединяет воединыжды ключи первых 2-ух отношений.
6. Если степень связи М:М, то независимо от класса принадлежности сущностей формируется три дела: два дела соответствуют связываемым сущностям; а третье является связным и соединяет воединыжды ключи первых 2-ух отношений.
2.2.
ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ «ПОЧТОВЫЕ ОТДЕЛЕНИЯ
»
1-ый шаг проектирования
В итоге анализа предметной области работы почтовых отделений выделим последующие сути:
– ИЗДАНИЕ (Шифр издания
, заглавие, Ф.И.О. редактора);
– ТИПОГРАФИЯ (Номер
, адресок, Ф.И.О. директора);
– ПОЧТОВОЕ ОТДЕЛЕНИЕ (Номер
, адресок, Ф.И.О. директора).
Меж этими сущностями есть последующие связи:
· Типографии печатают
издания;
· Почтовые отделения заказывают
издания.
2-ой шаг проектирования
3-ий шаг проектирования
На базе анализа построенной диаграммы ER-типа и правил формирования отношений построим подготовительные дела.
Связь «Печатает» удовлетворяет условиям правила №6, в согласовании с которым получаем 3 дела:
– ИЗДАНИЕ (Шифр издания
, заглавие, Ф.И.О. редактора);
– ТИПОГРАФИЯ (Номер
, адресок, Ф.И.О. директора);
– ТИРАЖ (Шифр издания, Номер типографии
, тираж, стоимость 1-го экземпляра, код заказа).
Связь «Заказывают
» удовлетворяет условиям правила №6, в согласовании с которым получаем 3 дела:
– ПОЧТОВОЕ ОТДЕЛЕНИЕ (Номер
, адресок, Ф.И.О. директора);
– ИЗДАНИЕ (Номер
, заглавие, Ф.И.О. редактора);
– заказ (Код заказа
, номер почтового отделения, шифр издания, номер типографии, количество заказов, стоимость доставки).
4-ый шаг проектирования
Добавим неключевые атрибуты к приобретенным отношениям, тогда и они воспримут последующий вид:
– ИЗДАНИЕ (Шифр издания
, Заглавие, ФИО_редактора);
– ТИПОГРАФИЯ (Номер
, адресок, ФИО_директора);
– ПОЧТОВОЕ ОТДЕЛЕНИЕ (Номер
, адресок, ФИО_начальника);
– ТИРАЖ (Шифр издания, Номер типографии
, Тираж, Цена_1-го_экземп-ляра);
– заказ (Код заказа
, Номер почтового отделения, Шифр издания, Номер типографии, количество заказов, Цена_доставки).
5-ый шаг проектирования
При помощи способа обычных форм приведем начальные дела к БКНФ. Все атрибуты всех начальных отношений являются ординарными, как следует, все эти дела уже находятся в 1НФ.
Зависимости меж атрибутами в отношениях:
1. ИЗДАНИЕ (Шифр издания
, Заглавие, ФИО_редактора):
1.1. Шифр издания
® Заглавие;
1.2. Шифр издания
® ФИО_редактора;
2. ТИПОГРАФИЯ (Номер
, адресок, ФИО_директора):
2.1. Номер
® Адресок;
2.2. Номер
® ФИО_директора;
3. ПОЧТОВОЕ ОТДЕЛЕНИЕ (Номер
, адресок, ФИО_начальника):
3.1. Номер
® Адресок;
3.2. Номер
® ФИО_начальника;
4. ТИРАЖ (Шифр издания, Номер типографии
, Тираж, Цена_1-го_экземп-ляра):
4.1. Шифр издания, Номер типографии
® Тираж;
4.2. Шифр издания, Номер типографии
® Цена_1-го_экземпляра;
5. заказ (Код заказа
, Номер почтового отделения, Шифр издания, Номер типографии, количество заказов, Цена_доставки):
5.1. Код заказа
® количество_заказа;
5.2. Код заказа
® Цена_доставки.
Любой из неключевых атрибутов всех отношений функционально-полно зависит от первичного ключа собственного дела, и это означает, что все эти дела находятся в 2НФ. Все неключевые атрибуты всякого из отношений взаимно-независимы и на сто процентов зависят от собственного первичного ключа, как следует, все эти дела находятся в 3НФ. Все атрибуты первичных ключей всякого из отношений не имеют зависимости от неключевых атрибутов, и это означает, что все эти дела находятся в БКНФ. Потому что все дела приведены к БКНФ и все атрибуты имеют логически обоснованные места в подготовительных отношениях, то проектирование данной нам базы данных не просит проведения шестого шага проектирования.
3. РЕАЛИЗАЦИЯ БАЗЫ ДАННЫХ СРЕДСТВАМИ
MS
ACCESS
3.1. Обзор системы управления базами данных
MS
Access
MicrosoftAccess – система управления базами данных (СУБД), которую КомпанияMicrosoft включает в состав проф редакции (ProfessionalEdition) MicrosoftOffice. Удобство использования и мощность интегрированных средств делает спектр информационных систем, построенных с применением Access, очень широким – от локальных разработок для домашнего внедрения до суровых проф проектов распределенных по сети баз данных, включающих сотки тыщ записей и сложнейшие правила обработки данных.
СУБД Access поддерживает реляционную модель представления данных. Она работает под управлением операционных систем Windows 95/98, WindowsNT и выше. СУБД Access имеет стандартизованный интерфейс приложений Windows. Access дозволяет сделать рабочую информационную систему фактически без единой строчки программного кода, только при помощи зрительного проектирования, интегрированных мастеров и шаблонов. В ней реализованы способности программирования с внедрением структурированного языка запросов StructuredQueryLanguage (SQL) и языка VisualBasicforApplication (VBA).
Access поддерживает классические для офисных программ механизмы связывания и встраивания объектов ObjectLinkingandEmbedding (OLE) и динамического обмена данными DynamicDataExchange (DDE). Это дозволяет Access работать с хоть какими объектами из библиотеки типов другого приложения пакета MicrosoftOffice и предоставлять свои объекты для остальных приложений. В Access 2002 возникли способности использования расширяемого языка разметки – extensibleMarkupLanguage (XML), играющего роль эталона обмена данными меж приложениями.
Большая часть действий по работе с элементами баз данных в среде Access можно выполнить при помощи последующих средств: установок основного меню, клавиш панелей инструментов, установок контекстного меню и композиций кнопок.
база данных является главным компонентом проекта приложения Access. К главным элементам базы данных можно отнести таблицы, запросы, отчеты, макросы и модули.
Для работы с БД в Access имеется обычное окно, из которого можно вызвать хоть какой ее объект для просмотра, выполнения, разработки либо модификации. юзер может для работы с БД создать собственный интерфейс, базу которого обычно составляют формы.
Текущая (открытая в данный момент) БД может вести взаимодействие с наружными БД, которые употребляются как источники таблиц при импорте либо присоединении, также как получатели при экспорте данных из текущей базы данных.
Таблица
представляет собой основную единицу хранения данных в базе. понятие таблицы в Access соответствует аналогичному понятию реляционной модели данных. В случайной базе данных Access обычно имеется совокупа связанных меж собой таблиц.
С таблицей в целом можно делать последующие операции:
– создание (определение структуры);
– изменение структуры (реструктуризация);
– переименование;
– удаление.
При разработке таблицы задается структура и имя таблицы. При сохранении таблицы на диске вся нужная информация располагается в файле базы данных. При изменении структуры таблицы в ней могут поменяться наименования и свойства полей, состав и наименования ключа и индексов, ограничения. Для конфигурации структуры и переименования таблиц употребляются утилиты (программки), созданные для работы с таблицами БД.
Меж 2-мя таблицами можно устанавливать связи типа 1:1 и 1:М в окне описания схемы данных. Главными операциями над таблицами являются: просмотр и обновление (ввод, модификация и удаление), сортировка, фильтрация и печать.
запрос
представляет собой формализованное требование на отбор данных из таблиц либо на выполнение определенных действий с данными. запрос дозволяет сделать набор записей из данных, находящихся в различных таблицах, и применять его как источник данных для формы либо отчета. В Access можно создавать и делать последующие главные типы запросов: подборка, обновление, удаление либо добавление данных. При помощи запросов можно также создавать новейшие таблицы, используя данные из одной либо нескольких имеющихся таблиц. Описание запроса можно выполнить при помощи бланка QBE либо аннотации языка SQL.
Форма
представляет собой объект базы данных Access, в каком разраб располагает элементы управления, принимающие деяния юзеров либо служащие для ввода, отображения и конфигурации данных в полях. На формах можно расположить разные элементы, такие как: поля таблиц, поля со перечнем, клавиши, раскрывающиеся списки, выключатели, переключатели, флажки, картинки, надписи, подчиненные формы и т.д. За клавишами обычно закрепляют вызов функций. Функции обработки инфы во время работы с БД задаются при помощи макросов либо программ на языке VBA.
отчет
представляет собой объект базы данных, созданный для отображения содержащейся в базе данных инфы. Он дозволяет производить нужную группировку данных, показывать расчетные и итоговые данные. отчет можно просмотреть на дисплее либо распечатать через принтер на бумагу.
Макрос
представляет последовательность установок встроенного в Access языка VBA, задающих автоматическое выполнение неких операций.
Модуль
представляет совокупа описаний, инструкций и процедур на языке VBA, сохраненную под общим именованием. В Access употребляются модули 3-х типов: формы, отчета и обычный. Модули форм и отчетов содержат программки, являющиеся локальными для этих объектов. Процедуры из обычного модуля, если они не описаны очевидно как локальные для содержащего их модуля, распознаются и могут вызываться процедурами из остальных модулей той же либо иной базы данных Access.
3.2.Формирование начальных данных
Сущность хоть какой базы данных состоит в том, что она обязана хранить данные, правильно отражающие соответственное состояние предметной области. Потому настоящая база данных для почтовых работников обязана содержать фактические данные, надлежащие данной предметной области. Но моя база данных является учебной, и потому данные, хранящиеся в ней, будут условными.
Тем не наименее, начальные данные данной нам базы данных должны соответствовать требованиям, которые были выявлены при анализе предметной области, т.е. данные будут заполняться согласно запросам, формам и отчетам, которые могут быть нужны юзерам данной нам базы данных. Не считая того, начальные данные должны проверить соответствие спроектированной базы данных данной предметной области, также оценить корректность формирования отношений, выявление первичных ключей и связей меж отношениями.
Начальные данные, нужные для данной предметной области, можно просмотреть в Приложении 3.
3.3.Составление бизнес – плана
бизнес-план
это набор документов, позволяющий оценить эффективность и надежность вложения средств для перевоплощения бизнес-идеи в реальное дело, приносящее прибыль.
Содержащуюся в бизнес-плане информацию можно условно поделить на информацию описательного нрава и информацию, полученную в итоге денежных расчетов моделируемой ситуации.
Расчетная информация быть может получена и систематизирована при помощи программной системы ProjectExpert.
Project
Expert
— автоматическая система планирования и анализа эффективности вкладывательных проектов на базе имитационной модели валютных потоков. Применяемый в данной системе сценарный подход (возможность построения модели и проигрыш вариантов ее развития) является более действенным в критериях неопределенности почти всех важных для вкладывательного проекта причин, к примеру, таковых как: И, прогноз размера продаж, задержки платежей и т.п. Модель проекта с наибольшей достоверностью имитирует настоящую операционную деятельность компании в критериях, когда вводимые начальные данные и варьируемые характеристики обрисовывают сущность принимаемых тех либо других управленческих решений. В итоге расчетов оцениваются последствия принимаемых решений в виде принятых денежных характеристик.
отчет о прибылях и убытках
дозволяет найти из каких составляющих складывается Прибыль компании.
Таблица Кэш-фло
Эффективность инвестиций
3.
4
. Разработка объектов базы данных
MSAccess предоставляет два метода сотворения базы данных: создание типовой БД при помощи мастера и создание пустой БД, которая не содержит данных, но хранит информацию о структуре. 1-ый метод обеспечивает резвое создание БД и дозволяет получить типовую базу данных с эталонами инфы в таблицах. Он применим в вариантах, когда юзеру подступает одна из 10 предлагаемых СУБД Access типовых баз данных. 2-ой метод различается большей гибкостью и сразу большей трудозатратностью, так как просит отдельного определения всякого элемента базы данных. Независимо от метода сотворения базу данных можно в хоть какое время поменять и расширить.
При разработке базы данных «Почтовые отделения» я буду воспользоваться вторым методом сотворения БД. Для сотворения новейшей базы данных при помощи СУБД MSAccess нужно: открыть ее при помощи щелчка по соответственной пиктограмме.
Дальше нужно сделать файл новейшей БД, и для этого необходимо выполнить последующие деяния:
1. В открывшемся рабочем окне MicrosoftAccess покажется диалоговое окно, в каком будут последующие варианты:
,
либо
. Из их нужно избрать
и надавить клавишу
.
2. Покажется диалоговое окно сотворения новейшей БД. В нем нужно найти имя новейшего файла и указать его положение. По дефлоту Access присвоит создаваемой базе данных имя
и предложит сохранить ее в папке
. Потому что я создаю базу данных, спроектированную во 2-ой главе курсовой работы, то разумно именовать ее «Почтовые отделения». Опосля ввода имени в поле И
нужно щелкнуть на кнопочке
.
3. Раскрывается диалоговое окно сделанной базы данных, в каком предлагается избрать элемент БД и метод его сотворения.
В открывшемся окне открыта веб-сайт на котором находится таковая ссылка в Избранное (Favorites) тк обычно таковая ссылка активизирует скрипт который без вашего подготовительного согласия зано
, для сотворения новейшей таблицы нужно надавить клавишу
. В открывшемся окне «Новенькая таблица» предлагаются последующие режимы сотворения новейшей таблицы:
,
,
,
,
. Для сотворения моей базы данных я буду применять режим
, потому выбираю в этом окне
и нажимаю на клавишу
.
Открывшееся окно содержит три раздела:
–
– неотклонимый раздел;
–
– условно-обязательный раздел;
–
– необязательный раздел.
В разделе
необходимо указать имена всех нужных полей таблицы. Чтоб начать работу с разделом
, следует в нем в строке, соответственной создаваемому полю, щелкнуть мышью. Опосля возникновения клавиши со стрелкой вниз щелкнуть на ней и избрать пригодный тип данных из показавшегося перечня. Для всякого поля можно добавочно задать характеристики полей в разделе
, который делится на две вкладки
и
. нужно обозначить главные поля таблицы, это нужно для идентификации каждой записи таблицы. Для этого нужно выделить их и надавить на панели инструментов клавишу
. Опосля ввода всех нужных характеристик на панели инструментов нужно избрать в меню
пункт
, а дальше в показавшемся окне ввести имя создаваемой таблицы и надавить клавишу
.
СУБД MSAccess поддерживает последующие типы данных: текстовый; поле MEMO; числовой; дата/время; валютный; счетчик; логический; поле объекта OLE; ссылка; мастер подстановок.
СУБД MSAccess дозволяет заполнить последующие характеристики полей, которые определяют характеристики ввода, отображения и хранения данных в таблицах:
– размер поля: употребляется лишь текстовым и числовым типами данных, для текстовых полей он быть может от 1 до 255 знаков, а у числовых – целое, длинноватое целое, одинарное с плавающей точкой и остальные;
– маска ввода: устанавливается формат, применяемый при вводе данных;
– подпись: задает имя полей, которое будет употребляться для отображения в формах и отчетах;
–
– условие на
– непременное поле: описывает необходимость ввода данных в поле;
– индексированное поле: показывает, необходимо ли создавать индекс на поле.
Таковым образом, создаем последующие таблицы, которые соответствуют отношениям, выявленным на шаге проектирования базы данных: Издание, Типография, Почтовое отделение, Тираж, заказ. Структура этих таблиц приведена в приложении 2.
Для сотворения запроса нужно переключиться в сделанной БД на закладку
и надавить клавишу
. В открывшемся окне «Новейший запрос» можно избрать один из последующих методов сотворения запроса:
,
,
,
,
. Для сотворения запросов к моей БД я буду применять
, потому нужно избрать
и надавить клавишу
. В итоге раскроется окно новейшего запроса и в нем диалоговое окно «Добавление таблицы», в каком можно избрать таблицы, которые будут необходимы для формирования запросов, также уже сделанные запросы. Открывшееся окно
разбито на две части: в верхней показываются все избранные для запроса таблицы со перечнями входящих в их полей и имеющиеся межтабличные связи; в нижней находится бланк запроса, служащий для определения характеристик запроса.
Дальше нужно избрать тип запроса:
,
,
,
,
,
. По умолчания будут создаваться запросы на подборку, которые я и буду применять в собственной базе данных.
Для формирования бланка запроса нужно из верхней части окна перетаскивать в него нужные поля таблиц. Бланк запроса содержит последующую информацию по любому использующемуся полю:
,
,
,
,
,
. В строке
можно задать одну из последующих сортировок для всякого поля:
либо
. В строке
можно избрать одну из последующих операций: суммирование, избрать малое либо наибольшее Вывод на экран
можно поставить либо убрать отметку о выводе на экран, по дефлоту для всех полей она будет поставлена. В строке
можно задать последующие типы критерий: определенное
Для сохранения этого запроса нужно избрать в меню
пункт
, в открывшемся окне набрать имя новейшего запроса и надавить клавишу
. Таковым образом, создаем последующие запросы.
запрос «1 – адреса типографий, в каких печатаются газеты либо журнальчики данного наименования» показывает информацию по последующим полям: Издание.name, Типография.adress. В этом запросе в поле Издание.name делается отбор записей, у каких заказ всеми почтовыми отделениями данного издания, и сортировка записей по убыванию. Будет выполняться сортировка записей по убыванию в этом же поле. Этот запрос сотворен для показа редакторам изданий определенного типа популярности изданий, основанной на объеме заказа почтовыми отделениями.
запрос «2-1 — Информация о изданиях на типографии» показывает информацию по последующим полям: Тираж.shifr_izd, Издание.nazv_izd, Тираж.zena_ekz_izd, Тираж.tirag_izd, заказ.obem_zakaza. Для этого запроса делается отбор записей по номеру типографии, который будет введен для поля Типография.nom_tipograf. Этот запрос сотворен для показа работникам определенной типографии инфы о печатаемых типографией изданиях, также тираж и общий размер заказа издания почтовыми отделениями у типографии.
запрос «2-2 — Заказы изданий почтовыми отделениями у типографии» показывает информацию по последующим полям: Издание.nazv_izd, заказ.nom_pocht_otd, Заказ.obem_zakaza, а так же поле, в каком делается вычисление по последующему выражению для определения цены заказа с учетом цены доставки: Тираж.zena_ekz_izd * заказ.obem_zakaza + Заказ.zena_dostav-ki_partii. Для этого запроса делается отбор записей по номеру типографии, который будет введен для поля Типография.nom_tipograf. Этот запрос сотворен для показа работникам определенной типографий инфы о заказах почтовыми отделениями изданий.
запрос «3-1 — информация о изданиях на почтовом отделении» показывает информацию по последующим полям: Тираж.shifr_izd, Издание.nazv_izd, заказ.obem_zakaza. А в поле Заказ.obem_zakaza делается групповая операция – суммирование (Sum), для того, чтоб показать совокупный заказ сиим почтовым отделением определенного издания. Для этого запроса делается отбор записей по номеру почтового отделения, который будет введен для поля Почтовое_отделение.nom_pocht_otd. Этот запрос сотворен для показа работникам определенного почтового отделения инфы о совокупных заказах изданий.
запрос «3-2 — Заказы изданий почтовым отделением у типографий» показывает информацию по последующим полям: Издание.nazv_izd, заказ.nom_tipograf, Типография.adres_tipograf, Типография.fio_direktora_tipograf, заказ.obem_zakaza, а так же поле, в каком делается вычисление по последующему выражению для определения цены заказа с учетом цены доставки: Тираж.zena_ekz_izd * заказ.obem_zakaza + Заказ.zena_dostavki_partii. Для этого запроса делается отбор записей по номеру почтового отделения, который будет введен для поля Почтовое_отделение.nom_pocht_otd. Этот запрос сотворен для показа работникам определенного почтового отделения инфы о заказах изданий у типографий.
запрос «3-3 — Почтовое отделение с большим общим числом изданий» показывает информацию по последующим полям: Почтовое_отделение.nom_-pocht_otd, Почтовое_отделение.adres_pocht_otd, Почтовое_отделение.fio_nach_-pocht_otd, заказ.obem_zakaza. А в поле Заказ.obem_zakaza делается групповая операция – суммирование (Sum), для того, чтоб показать общее число изданий, заказанное почтовым отделением. Этот запрос сотворен для показа инфы о почтовом отделении с большим общим числом заказываемых изданий.
запрос «4-1 — Перечень изданий» показывает информацию по последующим полям: Издание.shifr_izd, Издание.nazv_izd, Издание.fio_redaktora_izd. Этот запрос сотворен для показа инфы о узнаваемых печатных изданиях.
запрос «4-2 — Типографии где печатается издание» показывает информацию по последующим полям: Тираж.nom_tipograf, Типография.adres_tipograf, Типография.fio_direktora_tipograf, Тираж.tirag_izd. Для этого запроса делается отбор записей по шифру издания, который будет введен для поля Тираж.shifr_izd. Этот запрос сотворен для показа типографий, где печатается определенное издание.
запрос «4-3 — Почтовые отделения которые заказывают издание» показывает информацию по последующим полям: Заказ.nom_pocht_otd, Почтовое_отделение.adres_pocht_otd, Почтовое_отделение.fio_nach_pocht_otd, заказ.obem_zakaza. А в поле Заказ.obem_zakaza делается групповая операция – суммирование (Sum), для того, чтоб показать совокупный заказ сиим почтовым отделением определенного издания. Для этого запроса делается отбор записей по шифру издания, который будет введен для поля заказ.shifr_izd. Этот запрос сотворен для показа почтовых отделений, которые заказывают определенное издание.
Все эти запросы приведены в Приложении 4.
Для сотворения форм нужно переключиться в сделанной БД на закладку
и надавить клавишу
. MSAccess дозволяет создавать формы последующим методами: в режиме
, при помощи
, при помощи
. Не считая того, может быть построение различных форм при помощи запросов и расширение способностей форм на базе включения в их диаграмм, картографических данных и рисунков. Для сотворения форм к моей БД я буду применять
, и для этого нужно в открывшемся окне «Новенькая форма» нужно избрать
и надавить клавишу
.
Раскроется 1-ое окно мастера
. В нем есть перечень
, в каком отображены все таблицы и запросы, сделанные в данной нам БД и которые можно применять как источники данных, нажав на стрелку прокрутки и выбрав из перечня. При всем этом в области
будут отражаться поля избранной таблицы либо запроса. Нужные поля можно перенести в область
при помощи особых клавиш. Опосля выбора нужных полей перемещаемся в последующее окно мастера, нажав клавишу
.
В левой части открывшегося окна дается список применяемых таблиц, одну из которых выбирают как главный источник данных. В правой же части окна находится область подготовительного просмотра и можно избрать вариант формы:
,
либо
. Опосля воплощения нужного выбора перемещаемся в последующее окно мастера, нажав клавишу
.
В правой части открывшегося окна находится область определения наружного вида формы, в левой – область подготовительного просмотра. Можно избрать один из последующих видов форм:
,
,
,
и остальные. Опосля воплощения нужного выбора перемещаемся в последующее окно мастера, нажав клавишу
.
В правой части открывшегося окна можно избрать стиль формы, в левой части находится область подготовительного просмотра. Можно избрать один из последующих стилей формы:
,
,
и остальные. Опосля воплощения нужного выбора перемещаемся в последующее окно мастера, нажав клавишу
.
Раскроется крайнее окно
, в каком можно поменять имя формы и подчиненной формы (если таковая будет сотворена). В нем также предлагается создать выбор последующих действий:
либо
. Можно также отметить пункт
. Опосля воплощения нужных конфигураций жмем клавишу
. Если в качестве предстоящего деяния избран вариант
, то раскроется конструктор сделанной формы, в каком можно создать нужные конфигурации.
Таковым образом, создаем последующие формы:
– «1-1 — Перечень изданий» с полями: Издание.shifr_izd, Издание.nazv_izd, Издание.fio_redaktora_izd; эта форма имеет «ленточный» вид;
– «2-1 — Перечень типографий» с полями: Типография.nom_tipograf, Типография.adres_tipograf, Типография.fio_direktora_tipograf; эта форма имеет «ленточный» вид;
– «2-2 — Печать изданий типографиями» с полями: Типография.nom_tipograf, Типография.adres_tipograf, Типография.fio_direktora_tipograf, Издание.-shifr_izd, Издание.nazv_izd, Издание.fio_redaktora_izd, Тираж.tirag_izd, Тираж.zena_ekz_izd; эта форма имеет вид «в один столбец»;
– «3-1 — Перечень почтовых отделений» с полями: Почтовое_отделение.nom_-pocht_otd, Почтовое_отделение.adres_pocht_otd, Почтовое_отделение.fio_-nach_pocht_otd; эта форма имеет «ленточный» вид;
– «3-2 — заказ изданий почтовыми отделениями у типографий»: Почтовое_отделение.nom_pocht_otd, Почтовое_отделение.adres_pocht_otd, Почтовое_отделение.fio_nach_pocht_otd, Типография.nom_tipograf, Типография.-adres_tipograf, Типография.fio_direktora_tipograf, Издание.shifr_izd, Изда-ние.nazv_izd, Издание.fio_redaktora_izd, заказ.obem_zakaza, Заказ.zena_dos-tavki_partii; эта форма имеет вид «в один столбец».
В приложении 5 приведен пример формы на базе формы «3-2 — заказ изданий почтовыми отделениями у типографий».
Для сотворения отчета нужно переключиться в сделанной БД на закладку
и надавить клавишу
. MSAccess дозволяет создавать отчеты последующими методами: при помощи
, при помощи
, при помощи
. Для сотворения отчетов к моей БД я буду применять
, и для этого в открывшемся окне «Новейший отчет» нужно избрать
и надавить клавишу
.
Раскроется 1-ое окно мастера
. В нем есть перечень
, в каком отображены все таблицы и запросы, сделанные в данной нам БД и которые можно применять как источники данных, нажав на стрелку прокрутки и выбрав из перечня. При всем этом в области
будут отражаться поля избранной таблицы либо запроса. Нужные поля можно перенести в область
при помощи особых клавиш. Опосля выбора нужных полей перемещаемся в последующее окно мастера, нажав клавишу
.
В левой части открывшегося окна дается список применяемых таблиц, одну из которых выбирают как главный источник данных, а в правой – область подготовительного просмотра. Опосля воплощения нужного выбора перемещаемся в последующее окно мастера, нажав клавишу
.
В левой части открывшегося окна дается список всех отобранных полей и можно выбирать уровни группировки, выбирая поле, по которому будет проводиться группировка, и используя особые клавиши. Изменять уровни группировки можно при помощи клавиш
. В правой же части окна находится область подготовительного просмотра, в каком показываются все конфигурации с группировками в новеньком отчете. Опосля выполнения нужных конфигураций перемещаемся в последующее окно мастера, нажав клавишу
.
В открывшемся окне можно задать сортировку записей по возрастанию либо по убыванию, включающую до 4 полей, также вычислить итоговые значения (сумма, среднее, наибольшее и меньшее). Для выполнения вычислений итоговых значений следует надавить клавишу
. Откроется окно, в каком перечислены все поля таблиц и запросов, применяемых в отчете с данными числового и валютного типов, также список операций. Выбор операции осуществляется методом установки флага в соответственном окне строчки с именованием поля. Для продолжения работы с мастером нужно надавить клавишу
. Опосля выполнения нужных конфигураций перемещаемся в последующее окно мастера, нажав клавишу
.
В правой части открывшегося окна можно избрать макет отчета и ориентацию страничек (книжная либо альбомная). Предлагается создать выбор 1-го из последующих макет отчета:
,
,
,
и остальные. В левой части этого окна находится область подготовительного просмотра, где показываются все конфигурации с макетом отчета. Опосля воплощения нужного выбора перемещаемся в последующее окно мастера, нажав клавишу
.
В правой части открывшегося окна можно избрать стиль создаваемого отчета, а в левой находится область подготовительного просмотра, где показываются все конфигурации со стилем отчета. Можно избрать один из последующих стилей отчета:
,
,
и остальные. Опосля воплощения нужного выбора перемещаемся в последующее окно мастера, нажав клавишу
.
Раскроется крайнее окно
, в каком можно поменять имя отчета. В нем также предлагается создать предстоящий выбор:
либо
. Можно также отметить пункт
. Опосля воплощения нужных конфигураций жмем клавишу
. Если в качестве предстоящего деяния избран вариант
, то раскроется конструктор сделанного отчета, в каком можно создать нужные конфигурации.
Таковым образом, создаем последующие отчеты:
– «1-1 — информация о изданиях» с полями: Издание.shifr_izd, Издание.-nazv_izd, Издание.fio_redaktora_izd, Типография.nom_tipograf, Типография.-adres_tipograf, Типография.fio_direktora_tipograf, Тираж.tirag_izd, Тираж.-zena_ekz_izd;
– «2-1 — информация о типографиях» с полями: Типография.nom_tipograf, Типография.adres_tipograf, Типография.fio_direktora_tipograf, Издание.shifr_-izd, Издание.nazv_izd, Тираж.tirag_izd, Тираж.zena_ekz_izd, Почтовое_отде-ление.nom_pocht_otd, Почтовое_отделение.adres_pocht_otd, заказ.obem_-zakaza, Заказ.zena_dostavki_partii;
– «3-1 — информация о почтовых отделениях» с полями: Почтовое_отделе-ние.nom_pocht_otd, Почтовое_отделение.adres_pocht_otd, Почтовое_отделе-ние.fio_nach_pocht_otd, Издание.shifr_izd, Издание.nazv_izd, Тираж.zena_-ekz_izd, заказ.obem_zakaza, Заказ.zena_dostavki_partii, Типография.nom_ti-pograf, Типография.adres_tipograf;
– «3-2 — отчет по работе почтового отделения» с полями: Почтовое_отделение.nom_pocht_otd, Почтовое_отделение.adres_pocht_otd, Почтовое_отделение.fio_nach_pocht_otd, Издание.shifr_izd, Издание.nazv_izd, заказ.obem_zakaza, Тираж.zena_ekz_izd, Заказ.zena_dostavki_partii, вычисляемое поле «Стоимость партии с доставкой» выражением Тираж.zena_ekz_izd * Заказ.obem_zakaza + заказ.zena_dostavki_partii, Типография.nom_tipograf, Типография.adres_tipograf. Этот отчет в отличие от предшествующего выводит информация по одному почтовому отделению, номер которого будет запрошен для поля Почтовое_отделение.nom_pocht_otd.
В приложении 6 приведен пример отчета на базе отчета «3-2 — отчет по работе почтового отделения».
Исследование главных функций пакета
BPwin
BPwin дозволяет аналитику создавать сложные модели бизнес-процессов при малых усилиях. BPwin поддерживает три методологии – IDEF0, IDEF3 и DFD. Любая из их призвана решать свои специальные задачки.
Модель в BPwin рассматривается как совокупа работ, любая из которых оперирует с неким набором данных. работы изображаются в виде прямоугольников (блоков), данные – в виде стрелок (дуг).
Модели на базе эталона IDEF0 нужны для описания технологических действий. Диаграммы потоков данных (DFD) обрисовывают функции обработки инфы, документы, объекты, также служащих и подразделения. При всем этом употребляется набор частей для источников, приемников и хранилищ данных. Для логики взаимодействия информационных потоков употребляется IDEF3. С его помощью дают характеристику как отдельной постановке реализации бизнес-процесса, так и полной последовательности действий.
В IDEFO различают 5 типов стрелок:
Вход (
Input
)
— материал либо информация, которые употребляются либо преобразуются работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Любой тип стрелок подступает к определенной стороне прямоугольника, изображающего работу, либо выходит из нее. Стрелка входа рисуется как входящая в левую грань работы.
Управление (
Control
)
— правила, стратегии, процедуры либо эталоны, которыми управляется работа. Любая работа обязана иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы.
Выход (
Output
)
— материал либо информация, которые выполняются работой. Любая работа обязана иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не обязана моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы.
Механизм (
Mechanism
)
— ресурсы, которые делают работу, к примеру персонал компании, станки, устройства и т. д. Стрелка механизма рисуется как входящая в нижнюю грань работы.
Вызов (
Call
)
— особая стрелка, указывающая на другую модель работы. Стрелка механизма рисуется как исходящая из нижней грани работы. Стрелка вызова используется для указания того, что некая работа производится за пределами моделируемой системы. В BPwin стрелки вызова употребляются в механизме слияния и разделения моделей.
Граничные стрелки.
Стрелки на контекстной диаграмме служат для описания взаимодействия системы с миром вокруг нас. Они могут начинаться у границы диаграммы и заканчиваться у работы, и напротив. Такие стрелки именуются граничными.
Диаграммы потоков данных (Dataflowdiagramming, DFD) употребляются для описания документооборота и обработки инфы. Подобно IDEF0, DFD представляет модельную систему как сеть связанных меж собой работ. Их можно применять как дополнение к модели IDEF0 для наиболее приятного отображения текущих операций документооборота в корпоративных системах обработки инфы. DFD обрисовывает:
■ функции обработки инфы (работы);
■ документы (стрелки, arrow), объекты, служащих либо отделы,
которые участвуют в обработке инфы;
■ наружные ссылки (externalreferences), которые обеспечивают интер
фейс с наружными объектами, находящимися за границами модели
руемой системы;
■ таблицы для хранения документов (хранилище данных, datastore).
В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD разглядывает систему как совокупа предметов.
наличие в диаграммах DFD частей для описания источников, приемников и хранилищ данных дозволяет наиболее отлично и наглядно обрисовать процесс документооборота. Но для описания логики взаимодеяния информационных потоков наиболее подступает IDEF3, именуемая также workflowdiagramming — методологией моделирования, использующая графическое описание информационных потоков, отношений меж действиями обработки инфы и объектов, являющихся частью этих действий. Диаграммы Workflow могут быть применены в моделировании бизнес-процессов для анализа завершенности процедур обработки инфы. С помощью их можно обрисовывать сценарии действий сотрудников организации, к примеру последовательность обработки заказа действия, которые нужно обработать за конечное время.
Финансово-экономический отдел
Начальник узла почтовой связи
Отдел информатизации и эксплуатации почтовой связи
Отдел кадров
Заместитель начальника
Отдел сортировки, обработки и доставки почты
Коммерческий отдел
Отдел перевозки почты
Хозяйственный отдел
Транспортный участок
Отделения почтовой связи
Рис.1. Организационно — производственная структура узла почтовой связи
ЗАКЛЮЧЕНИЕ
Проектирование базы данных представляет собой долгий и трудозатратный процесс. Свойство сделанной базы данных зависит от анализа предметной области и избранной методологии проектирования. При неполном анализе предметной области в процессе использования сделанной базы данных может возникать лишнее дублирование данных, а так же разные аномалии, что, быстрее всего, приведет к потере нужных данных и повторному проектированию базы данных. процесс следующего проектирования базы данных не наименее ответственный, потому что нужно верно выявить нужные сути и согласно связям меж ними сформировать дела. процесс реализации базы данных средствами СУБД является преобразованием выполненного проектирования на ЭВМ .
Моей целью являлось проектирование базы данных «Почтовые отделения» средствами СУБД MSAccess.
1-ый шаг проектирования заключается в кропотливом анализе предметной области работы почтовых отделений. Задачка почтовых отделений заключается в закупке печатных изданий. Эти печатные издания составляет редактор, типографии их печатают и поставляют согласно заказам почтовых отделений. В процессе анализа предметной области были выявлены группы характеристик для всякого из объектов, информация о которых будет храниться в проектируемой базе данных. Были также выявлены:
– ограничения, накладываемые на информацию, которая будет храниться в базе данных;
– список запросов на предоставление справочной инфы;
– вероятные конфигурации инфы, которая будет храниться в базе данных, также добавление новейшей и удаление ненадобной инфы;
– список отчетов, которые будут нужны работникам, которые будут обслуживать проектируемую базу данных.
Результаты проведенного анализа должны быть сгруппированы подабающим образом и представлены в виде отчета на картонном носителе.
2-ой шаг проектирования делится на две фазы, 1-ая из их это выбор методологии проектирования, а 2-ая – проектирование базы данных «Почтовые отделения». Для проектирования моей базы данных я избрал способ «сущность-связь» и способ обычных форм. При помощи первого из их формируются сути, выявляются связи меж ними и строится диаграмм ER-типов. Дальше из сущностей и связей меж ними формируются дела согласно правилам формирования отношений, изложенным выше. При помощи второго способа уже сформированные дела приводятся к БКНФ.
3-ий шаг проектирования заключается в реализации базы данных «Почтовые отделения» при помощи СУБД Microsoft Access. Выбор для реализации базы данных СУБД MSAccess обосновывается последующим. Во-1-х, эта СУБД заходит в состав более всераспространенного пакета прикладных программ по работе с документами MicrosoftOffice. Из MSAccess вероятен экспорт инфы в остальные приложения, входящие в MSOffice (MSWord, MS Excel). Во-2-х, MSAccess может являться дополнением к иным приложениям, а именно и СУБД, таковым как Delphi, dBase и остальные. к примеру, файлы MSAccess могут являться основой для построения базы данных при помощи Delphi. Также MSAccess может являться клиентом по отношению к MicrosoftSQLServer. В-3-х, MSAccess поддерживает механизм OLE, т.е. может связывать и внедрять объекты.
Полученную базу данных можно применять в экспериментальных либо показательных целях для проектирования полнофункциональной информационной системы с единой базой данных для работы почтовых отделений, также типографий.
СПИСОК ЛИТЕРАТУРЫ
1. Карпова Т.С. Базы данных: модели, разработка, реализация. – СПб.: Питер, 2001. – 304 с.
2. Хомоненко А.Д., Гридин В.В. MicrosoftAccess. Резвый старт. – СПб.: БХВ-Петербург, 2003. – 304 с.
3. Золотова С.И. Практикум по Access. – М.: деньги и статистика, 2004. – 144 с.
4. Тиори Т., Фрай Дж. Проектирование структур баз данных: В 2-х кн. Кн. 1. Пер. с англ. – М.: мир, 1985. – 287 с.
5. Чамберлин Д.Д., Астрахан М.М., Эсваран К.П., Грифитс П.П., Лори Р.А., Мел Д.В., Райшер П., Вейд Б.В. SEQUEL 2: унифицированный подход к определению, манипулированию и контролю данных //СУБД. — 1996. — №1. — С.144-159.
6. Чаудхари С. способы оптимизации запросов в реляционных системах //СУБД. — 1998. — №3. — С.22-36.
7. Чен П. Модель «сущность-связь» — шаг к одному представлению о данных //СУБД. — 1995. — №3. — С.137-158.
]]>