Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Введение

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

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

1. Техническое задание

1.1 Анализ предметной области

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

Можно выделить следующие основные объекты описываемой предметной области:

1) Заказчики, разместившие заказы;

2) Готовые заказы, поступившие на склад (печатные изделия - бланки, брошюры, этикетки);

3) Журнал операций, фиксирующий поступление и отгрузку;

4) Журнал статуса, фиксирующий динамическое состояние по каждому заказу;

5) Отчёт о движении заказов для бухгалтерии.

Заказчики характеризуются следующими исходными данными

- УНН;

- наименование;

- телефоны;

- адреса.

Заказы характеризуются следующими исходными данными:

- номер заказа;

- дата оформления;

- наименование заказчика;

- наименование заказа

- тираж

- цена

- стоимость НДС

- стоимость

Журнал операций характеризуется следующими исходными данными:

- номер заказа;

- тип операции (поступление / отгрузка);

- дата операции;

- количество;

- сумма;

Журнал статуса заказа характеризуется следующими исходными данными:

- номер заказа;

- количество, отгруженное по заказу;

- стоимость, количества отгруженного по заказу;

- остаток заказа на складе;

- стоимость остатка на складе.

1.2 Постановка задачи

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

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

2. Технический проект информационной системы

2.1 Функциональная модель

2.1.1 Контекстная диаграмма и диаграммы детализации процессов

Для проведения анализа и функционального проектирования информационной системы используется CASE - средство BPWin. Поддерживает три методологии: IDFO, DFD, IDEF3, позволяющие анализировать организационную систему с трех ключевых точек зрения.

· С точки зрения функций системы. В рамках методологии IDFO моде-

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

· С точки зрения потоков информации (документооборота) в системе.

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

· С точки зрения последовательности выполняемых работ. И еще более

точную картину можно получить, дополнив модель диаграммами IDEF3. Этот метод привлекает внимание к очередности выполнения событий. В IDEF3 включены элементы логики, что позволяет моделировать и анализировать альтернативные сценарии развития бизнес - процесса.

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

В данной модели использованы следующие компоненты диаграмм:

1) процесс - выполняет преобразование входных потоков данных в выходные в соответствии с действием, которое определяется именем процесса.

2) хранилище или накопитель данных - позволяет определить данные, которые сохраняются между процессами.

3) потоки данных (стрелки) - определяют информацию, передаваемую через некоторое соединение от источника к приемнику.

На контекстной диаграмме первого уровня (рисунок 1) представлен процесс «Деятельность склада готовой продукции»:



Рисунок 1 - Контекстная диаграмма первого уровня «Деятельность склада готовой продукции»

На верхнем (первом) уровне диаграмма характеризует процесс в общем. Входным параметром являются нормативные документы, список сотрудников организации, запрос сотрудников организации. Механизмами или внешними факторами являются сотрудники организации, правила и процедуры.

Каждая последующая диаграмма является более подробным описанием (декомпозицией) одной из работ на вышестоящей диаграмме. Декомпозироваться процессы могут в разных нотациях, таких как нотации IDEF0, DFD, IDEF3. В основном процессы декомпозированы в нотации IDEF0. На предпоследнем и последнем уровне используется нотация DFD. На IDEF0 диаграммах присутствуют процессы и потоки данных

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

1) Входные - отражают информацию, которая подвергается обработке (это стрелки входящие в блок слева).

2) Выходные - материал или информация, которая производится процессом (это стрелки исходят из правой стороны блока).

В рассматриваемой предметной области представлено 4 уровня диаграмм детализации.

Второй уровень - это диаграмма (рисунок), с помощью которой производится детализация основного процесса, находящегося на контекстной диаграмме первого уровня.

Рисунок 2 - Диаграмма (второго уровня) детализации процесса «Деятельность склада готовой продукции»

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

В данной функциональной модели на DFD диаграммах присутствуют такие компоненты, как процессы, потоки и хранилища данных. Определение потоков данных и процессов идентично с их определениями в IDEF0 диаграммах. Хранилище данных представляет собой абстрактное устройство для хранения информации, которую можно в любой момент поместить в хранилище и через определенное время извлечь. Действие - «единица работы», выполняемое системой действие. Связи выделяют существенные взаимоотношения между действиями.

Третий уровень - это диаграммы (рисунок 3 - рисунок 5), детализирующие процессы расположенные на диаграмме декомпозиции второго уровня.

Рисунок 3 - Диаграмма (третьего уровня) детализации процесса «Поступление готовой продукции»



Рисунок 4 - Диаграмма (третьего уровня) детализации процесса «Отгрузка готовой продукции»

Рисунок 5 - Диаграмма третьего уровня, детализации процесса «Создание отчётов»

Четвертый уровень - это диаграмма (рисунок 6), детализирующая процессы, расположенные на диаграмме декомпозиции третьего уровня «Выполнение задач администрации».

Рисунок 6 - Диаграмма четвертого уровня, детализации процесса «Ведение журнала поступления»



Рисунок 7 - Диаграмма четвертого уровня, детализации процесса «Ведение журнала отгрузки»

Рисунок 8 - Диаграмма четвертого уровня, детализации процесса «Сформировать отчёт отгрузки»



Рисунок 9 - Диаграмма четвертого уровня, детализации процесса «Сформировать отчёт поступления»

Рисунок 10 - Диаграмма (четвертого уровня) детализации процесса «Сформировать отчёт оборотов»

2.1.2 Диаграмма дерева узлов

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

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

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



Рисунок 11 - Диаграмма дерева узлов

2.2 Информационная модель

информационный миниспецификация модель тестирование

2.2.1 Идентификация сущностей и связей. ER - диаграмма логического уровня

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

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

Данные, относящиеся к связям, очень важны и часто являются критическими данными, которые мы используем в жизни. Связь - это соотношение либо между двумя сущностями, либо между сущностью и этой же сущностью. Связь - «логический» объект, представленный одним или несколькими атрибутами - внешними ключами. Связь в ERwin обычно содержит пять типов информации: тип связи, родительский конец связи, дочерний конец связи, знак «обязательности» связи и кардинальность связи.

Различают идентифицирующую и неидентифицирующую связи. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERwin автоматически преобразует дочернюю связь в зависимую. Зависимая сущность изображается прямоугольником со скругленными углами. Идентифицирующая связь показывается на диаграмме сплошной линией с жирной точкой на дочернем конце связи, неидентифицирующая - пунктирной.

Для реализации существующего проекта использованы следующие сущности (см. рисунок 12):

Customer (заказчики), address_customer (адреса заказчиков), telephone_customer (телефоны заказчиков), orders (заказы), journal_operation (журнал операций), dynamic_status (состояние заказа), numbers_orders (номера заказов), type_operation (тип операции).

На логическом уровне проектирования в моделируемой базе данных представлены следующие типы связей между описанными сущностями (см. рисунок 12):

1) связь типа один ко многим (например: неидентифицирующая связь type_operation - journal_operation и идентифицирующая связь сustomer и telephone_customer);

2) связь типа многие ко многим (customer - numbers_orders).



Рисунок 12 - Модель диаграммы на уровне сущности

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

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

Внешние ключи создаются автоматически, когда связь соединяет сущности: связи образуют ссылку на атрибуты первичного ключа в дочерней сущности и эти атрибуты образуют внешний ключ в дочерней сущности (миграция ключа). Атрибуты внешнего ключа обозначаются символом (FK) после своего имени.

Альтернативный ключ - это потенциальный ключ, не ставший первичным. Каждому ключу соответствует индекс, имя которого также присваивается автоматически.

Сущности, атрибуты и связи являются основными компонентами ER - диаграммы. ER - диаграмма логического уровня представлена на рисунке 13.

Рисунок 13 - ER - диаграмма логического уровня.

2.2.2 ER-диаграмма физического уровня. Ограничения ссылочной целостности. Индексирование отношений

Физическая модель содержит всю информацию, необходимую для реализации конкретной БД. Физический уровень представления модели зависит от выбранного сервера. ERwin поддерживает практически все распространенные СУБД, всего около 20 реляционных и нереляционных баз данных, при этом он позволяет учесть особенности реализации конкретной СУБД. Основными объектами физической модели являются таблицы и колонки. ERwin автоматически создает имена таблиц и колонок на основе имен соответствующих сущностей и атрибутов, учитывая максимальную длину имени и другие синтаксические ограничения, накладываемые СУБД. При генерации имени таблицы или колонки по умолчанию все пробелы автоматически преобразуются в символы подчеркивания, а длина имени обрезается до максимальной длины, допустимой для выбранной СУБД. ER - диаграмма физического уровня представлена на рисунке 14.

На логическом уровне в моделируемой системе присутствовала связь типа «многие-ко-многим» между сущностями (customer - numbers_orders), которая на физическом уровне модели разрешается при помощи создания новой таблицы orders.

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

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

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

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

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

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

· Каскадное удаление. При удалении кортежа из отношения, на который идет ссылка, автоматически удаляются все ссылающиеся кортежи.

Обеспечение целостности данных реализуется установкой соответствующего флажка «Обеспечение целостности данных», а так же «каскадное обновление связанных полей» и «каскадное удаление связанных записей» в диалоговом окне Access 2003 «Изменение связей» (см. рисунок 15). Каскадное удаление данных соблюдается. Т.е. автоматически удаляются все ссылающиеся кортежи.

Настройка индексов и создание объектов физической памяти в ERwin позволяет создавать объекты физической памяти и настраивать индексы с учетом конкретной реализации СУБД. Эта особенность ERwin обеспечивает создание высокопроизводительных приложений для любой из выбранных СУБД.

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

Рисунок 14 - ER - диаграмма физического уровня



Рисунок 15 - Диалоговое окно Access 2003 «Изменение связей»

В индексе хранится ссылка на строку данных. При выполнении запроса сервер автоматически использует индекс для ускорения поиска необходимых данных. Индекс помогает избежать полного индексирования таблиц при поиске.

Для ускорения поиска данных в разработанной базе данных нашли применение индексированные таблицы, по колонкам которых реализуется поиск при помощи запросов. В базе данных организованы следующие запросы:

- запрос о движении за период;

- запрос на выбор всех операций;

- запрос на поиск заказа по номеру;

- запрос о заказах по заказчикам:

- запрос на выбор всех заказов;

- запрос на выбор заказчиков по вводу букв (оператор Like);

- запрос на выбор всех заказчиков;

- запрос на выбор всех заказов;

- запрос на выбор состояние заказа по номеру заказа;

- запрос на добавление заказа в таблицу состояния заказа;

- запрос на обновление состояния заказа;

- запрос на удаления заказа из таблицы состояния заказа;

- прочие запросы, обеспечивающие дополнительный системный сервис.

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

Индекс содержит отсортированную по колонке или нескольким колонкам информацию и указывает на строки, в которых хранится конкретное значение колонки. Например, если необходимо найти заказ по номеру, можно создать индекс по колонке order_number таблицы journal_operation. В индексе order_number будут отсортированы по возрастанию или убыванию. Для поиска заказа серверу направляется запрос с критерием поиска (number =1234). При выполнении запроса СУБД просматривает индекс, вместо того чтобы просматривать по порядку все строки таблицы journal_operation. Поскольку значения в индексе хранятся в определенном порядке, просматривать нужно гораздо меньший объем данных, что значительно уменьшает время выполнения запроса. Индекс можно создать для всех колонок таблицы, по которым часто производится поиск. При генерации схемы физической БД ERwin автоматически создает отдельный индекс на основе первичного ключа каждой таблицы, а также на основе всех альтернативных ключей, внешних ключей и инверсионных входов, поскольку эти колонки наиболее часто используются для поиска данных.

2.3 Верификация спроектированной логической модели

Верификация осуществляется из моделей, разработанных в ERwin и BPwin, что является дополнительной проверкой функционирования разработанной модели базы данных. Такая связь гарантирует завершенность анализа, гарантирует, что есть источники данных (сущности) для всех работ. Связывание моделей способствует согласованности, корректности и завершенности анализа. Результат связывания объектов модели процессов представлены ниже (см. табл. 1).

Таблица 1 - Результат связывания объектов модели процессов

Arrow Name	Entity Name	Attribute Name
Бухгалтерия	address_customer
		address
		customer_unn
		name
	customers
		customer_name
		customer_unn
	dynamic_status
		motion_amount
		motion_cost
		order_number
		remains_amount
		remains_cost
		token
	journal_operation
		amount
		date_operation
		order_number
		summa
		type_id
	numbers_orders
		number
		order_number
		year
	orders
		circulation
		cost
		cost_nds
		customer_unn
		date_in
		name_order
		order_number
		summa
	telephones_customer
		customer_unn
		name
		telephone_number
Выборка за период	dynamic_status
		motion_amount
		motion_cost
		order_number
		remains_amount
		remains_cost
		token
	journal_operation
		amount
		date_operation
		order_number
		summa
		type_id
	numbers_orders
		number
		order_number
		year
	orders
		circulation
		cost
		cost_nds
		customer_unn
		date_in
		name_order
		order_number
		summa
Данные журнала по отгрузки	customers
		customer_name
		customer_unn
	dynamic_status
		motion_amount
		motion_cost
		order_number
		remains_amount
		remains_cost
		token
	journal_operation
		amount
		date_operation
		order_number
		summa
		type_id
	numbers_orders
		number
		order_number
		year
	orders
		circulation
		cost
		cost_nds
		customer_unn
		date_in
		name_order
		order_number
		summa
Данные журнала по поступлению	customers
		customer_name
		customer_unn
	dynamic_status
		motion_amount
		motion_cost
		order_number
		remains_amount
		remains_cost
		token
	journal_operation
		amount
		date_operation
		order_number
		summa
		type_id
	numbers_orders
		number
		order_number
		year
	orders
		circulation
		cost
		cost_nds
		customer_unn
		date_in
		name_order
		order_number
		summa
Данные о заказчиках	address_customer
		address
		customer_unn
		name
	customers
		customer_name
		customer_unn
	telephones_customer
		customer_unn
		name
		telephone_number
Динамическое состояние заказа	dynamic_status	motion_amount
		motion_cost
		order_number
		remains_amount
		remains_cost
		token
	journal_operation	amount
		date_operation
		order_number
		summa
		type_id
	numbers_orders	number
		order_number
		year
	orders	circulation
		cost
		cost_nds
		customer_unn
		date_in
		name_order
		order_number
		summa
Заказы	customers
		customer_name
		customer_unn
	numbers_orders
		number
		order_number
		year
	orders
		circulation
		cost
		cost_nds
		customer_unn
		date_in
		name_order
		order_number
		summa
Кладовщик	address_customer
	customers
	dynamic_status
	journal_operation
	numbers_orders
	orders
	telephones_customer
Остатки	dynamic_remains	amount
		cost
		order_number
	dynamic_status	motion_amount
		motion_cost
		order_number
		remains_amount
		remains_cost
		token
	journal_operation	amount
		date_operation
		order_number
		summa
		type_id
	numbers_orders	number
		order_number
		year
	orders	circulation
		cost
		cost_nds
		customer_unn
		date_in
		name_order
		order_number
		summa
Отгруженная готовая продукция	dynamic_status
	journal_operation
	numbers_orders
	orders
Поступившая готовая продукция	customers
	numbers_orders
	orders
Уникальные номера заказов	dynamic_remains	amount
		cost
		order_number
	dynamic_status
		motion_amount
		motion_cost
		order_number
		remains_amount
		remains_cost
		token
	journal_operation
		amount
		date_operation
		order_number
		summa
		type_id
	numbers_orders
		number
		order_number
		year
	orders
		circulation
		cost
		cost_nds
		customer_unn
		date_in
		name_order
		order_number
		summa

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

3. Реализация системы

3.1 Миниспецификации процессов диаграмм нижнего уровня функциональной модели

Система реализована с помощью программного продукта Microsoft Office 2003, в состав которого входит пакет Access 2003. Microsoft Access 2003 используется преимущественно в таких областях как: создание баз данных для накопления и хранения информации (в частности, необходимой информации для отделов и групп лиц, также информации, специфической для различных приложений, например, предпочтений пользователей) и разработка приложений для управления данной информацией. Миниспецификации процессов используется для описания функционирования процесса в случае если нет необходимости в его дальнейшей детализации с помощью DFD.

Ведение журнала поступления (см. рисунок 6):

«Выбрать готовые заказы»

@ВХОД=ПОСТУПИВШАЯ ГОТОВАЯ ПРОДУКЦИЯ

@ВЫХОД = ВЫБРАННЫЕ ЗАКАЗЫ

@СПЕЦПРОЦ А1.1.1 ПРОСМОТР ИНФОРМАЦИИ В БАЗЕ ДАННЫХ О ГОТОВОЙ ПРОДУКЦИИ ПОСТУПИВШЕЙ НА СКЛАД

ВЫПОЛНИТЬ выбрать ГОТОВЫЙ ЗАКАЗ для размещении в ЖУРНАЛЕ ОПЕРАЦИЙ

ЕСЛИ ГОТОВЫЙ ЗАКАЗ выбран ТО

ВЫПОЛНИТЬ запрос размещения в ЖУРНАЛЕ ОПЕРАЦИЙ выполнен

ИНАЧЕ

ВЫПОЛНИТЬ определиться с выбором информации

КОНЕЦЕСЛИ

@КОНЕЦ СПЕЦПРОЦ

«Сохранить данные в журнале»

@ВХОД= ВЫБРАННЫЕ ЗАКАЗЫ

@ВЫХОД = ДАННЫЕ ЖУРНАЛА ПО ПОСТУПЛЕНИЮ

@СПЕЦПРОЦ А1.1.2 РАЗМЕЩЕНИЕ ГОТОВЫХ ЗАКАЗОВ В ЖУРНАЛЕ ПОСТУПЛЕНИЯ

ВЫПОЛНИТЬ сохранить выбранный заказ В ЖУРНАЛЕ ПОСТУПЛЕНИЯ

ЕСЛИ запись выбрана ТО

ВЫПОЛНИТЬ сохранение записи В ЖУРНАЛЕ выполнено

ИНАЧЕ

ВЫПОЛНИТЬ определиться с данными записи

КОНЕЦЕСЛИ

@КОНЕЦ СПЕЦПРОЦ

Ведение журнала отгрузки (см. Рисунок 7):

«Выбрать заказы на складе»

@ВХОД= ДАННЫЕ ЖУРНАЛА ПО ПОСТУПЛЕНИЮ

@ВЫХОД = ВЫБРАННЫЕ ЗАКАЗЫ

@СПЕЦПРОЦ А1.2.1 ПОЛУЧЕНИЕ ЗАКАЗА ДЛЯ РАЗМЕЧЕНИЯ В ЖУРНАЛЕ ОТГРУЗКИ

ВЫПОЛНИТЬ получить ЗАКАЗ из ЖУРНАЛА ПО ПОСТУПЛЕНИЮ

ЕСЛИ получение произошло ТО

ВЫПОЛНИТЬ получение ЗАКАЗА из ЖУРНАЛА ПО ПОСТУПЛЕНИЮ состоялось

ИНАЧЕ

ВЫПОЛНИТЬ определиться с выбором получение ЗАКАЗА

КОНЕЦЕСЛИ

@КОНЕЦ СПЕЦПРОЦ

«Сохранить данные в журнале по отгрузке»

@ВХОД= ВЫБРАННЫЕ ЗАКАЗЫ

@ВЫХОД = ДАННЫЕ ЖУРНАЛА ПО ОТГРУЗКИ

@СПЕЦПРОЦ А1.2.2 РАЗМЕЩЕНИЕ ГОТОВЫХ ЗАКАЗОВ В ЖУРНАЛЕ ОТГРУЗКИ

ВЫПОЛНИТЬ сохранить выбранный заказ В ЖУРНАЛЕ ОТГРУЗКИ

ЕСЛИ выбор заказа произошло ТО

ВЫПОЛНИТЬ запись выбранного заказа В ЖУРНАЛЕ ОТГРУЗКИ состоялась

ИНАЧЕ

ВЫПОЛНИТЬ определиться с выбором заказа

КОНЕЦЕСЛИ

@КОНЕЦ СПЕЦПРОЦ

«Отгрузить заказ»

@ВХОД= ГОТОВАЯ ПРОДУКЦИЯ

@ВЫХОД = ОТГРУЖЕННАЯ ГОТОВАЯ ПРОДУКЦИЯ

@СПЕЦПРОЦ А1.2.3 ВЫПОЛНЕНИЕ ОТГРУЗКИ ГОТОВОЙ ПРОДУКЦИИ

ВЫПОЛНИТЬ отгрузку ГОТОВОЙ ПРОДУКЦИИ

ЕСЛИ отгрузка произошла ТО

ВЫПОЛНИТЬ ВЫПОЛНЕНИЕ ОТГРУЗКИ ГОТОВОЙ ПРОДУКЦИИ

СОТРУДНИКА состоялось

ИНАЧЕ

ВЫПОЛНИТЬ определиться с выбором задачи

КОНЕЦЕСЛИ

@КОНЕЦ СПЕЦПРОЦ

Сформировать отчёт отгрузки (См. Рисунок 8)

«Выбрать отгрузку за период»

@ВХОД= ДАННЫЕ ЖУРНАЛА ПО ОТГРУЗКИ

@ВЫХОД = ВЫБОРКА ЗА ПЕРИОД

@СПЕЦПРОЦ А2.2.1 ПОЛУЧЕНИЕ ДАННЫХ ДЛЯ ОТЧЁТА ПО ОТГРУЗКЕ

ВЫПОЛНИТЬ получение данных для ОТЧЁТА ПО ОТГРУЗКЕ за период

ЕСЛИ данные для ОТЧЁТА ПО ОТГРУЗКЕ получены ТО

ВЫПОЛНИТЬ получение данных для ОТЧЁТА ПО ОТГРУЗКЕ состоялось

ИНАЧЕ

ВЫПОЛНИТЬ определиться с данными

КОНЕЦЕСЛИ

@КОНЕЦ СПЕЦПРОЦ

Сформировать отчёт поступления (См. Рисунок 9)

«Выбрать поступления за период»

@ВХОД= ДАННЫЕ ЖУРНАЛА ПО ПОСТУПЛЕНИЮ

@ВЫХОД = ВЫБОРКА ЗА ПЕРИОД

@СПЕЦПРОЦ А2.2.1 ПОЛУЧЕНИЕ ДАННЫХ ДЛЯ ОТЧЁТА ПО ПОСТУПЛЕНИЮ

ВЫПОЛНИТЬ получение данных для ОТЧЁТА ПО ПОСТУПЛЕНИЮ

за период

ЕСЛИ данные для ОТЧЁТА ПО ПОСТУПЛЕНИЮ

получены ТО

ВЫПОЛНИТЬ получение данных для ОТЧЁТА ПО ПОСТУПЛЕНИЮ

состоялось

ИНАЧЕ

ВЫПОЛНИТЬ определиться с данными

КОНЕЦЕСЛИ

@КОНЕЦ СПЕЦПРОЦ

Сформировать отчёт оборотов (См. Рисунок 10)

«Выбрать обороты за период»

@ВХОД= ДАННЫЕ ЖУРНАЛА ПО ПОСТУПЛЕНИЮ

@ВХОД= ДИНАМИЧЕСКОЕ СОСТОЯНИЕ ЗАКАЗА

@ВЫХОД = ВЫБОРКА ЗА ПЕРИОД

@СПЕЦПРОЦ А1.3.1 ФОРМИРОВАНИЕ ОТЧЁТА ОБОРОТОВ

ВЫПОЛНИТЬ формирование ОТЧЁТА ОБОРОТОВ

ЕСЛИ запрос на дынные для ОТЧЁТА ОБОРОТОВ выполнен ТО

ВЫПОЛНИТЬ формирование ОТЧЁТА ОБОРОТОВ

ИНАЧЕ

ВЫПОЛНИТЬ определиться с данными

КОНЕЦЕСЛИ

@КОНЕЦ СПЕЦПРОЦ

3.2 Описание разработанного приложения

Разработка приложения производится средствами Access и VBA. В данном проекте методом прямого проектирования (Forward Engineering) производим генерацию физической схемы БД из логической модели данных ERwin. При генерации физической схемы ERwin включает триггеры ссылочной целостности, хранимые процедуры, индексы, ограничения и другие возможности, доступные при определении таблиц в выбранной СУБД. Далее оформляем созданную в Access базу данных, на данный момент состоящую из таблиц, добавляя запросы, формы и отчеты. Создание запросов осуществляется в режиме конструктора запросов с помощью построителя выражений, либо в режиме SQL. Запросы в режиме SQL-скрипта, в разработанной базе данных представлены ниже.

1) Запрос для формирования отчёта оборотов за период:

SELECT numbers_orders.number, journal_operation.amount,

journal_operation.summa, dynamic_status.motion_amount,

dynamic_status.motion_cost, dynamic_status.remains_amount,

dynamic_status.remains_cost, journal_operation.type_id,

journal_operation.date_operation

FROM (numbers_orders INNER JOIN dynamic_status

ON numbers_orders.order_number = dynamic_status.order_number)

INNER JOIN journal_operation

ON numbers_orders.order_number = journal_operation.order_number

WHERE (((journal_operation.type_id)=1)

AND ((journal_operation.date_operation)

Between [Forms]! [between_for_report_moving]! [first_calendar]. [Value] And [Forms]! [between_for_report_moving]! [end_calendar]. [Value]));

2) Запрос на поиск заказа по номеру:

SELECT numbers_orders.order_number,

numbers_orders.number, orders.customer_unn, orders.date_in, orders.name_order, orders.circulation, orders.cost, orders.cost_nds, orders.summa

FROM numbers_orders INNER JOIN orders ON numbers_orders.order_number = orders.order_number

WHERE (((numbers_orders.order_number)=[num]));

3) Запрос выводится список всех заказов:

SELECT numbers_orders.order_number, numbers_orders.number, customers.customer_name, orders.date_in, orders.name_order, orders.circulation, orders.sale, orders.cost, orders.cost_nds, orders.summa

FROM customers INNER JOIN (numbers_orders INNER JOIN orders ON numbers_orders.order_number = orders.order_number) ON customers.customer_unn = orders.customer_unn;

4) Запрос для формирования журнала поступления:

SELECT journal_operation.order_number, journal_operation.type_id, journal_operation.date_operation, journal_operation.amount, journal_operation.summa

FROM journal_operation

WHERE (((journal_operation.type_id)=1));

5) Запрос для формирования журнала отгрузки:

SELECT journal_operation.order_number, journal_operation.type_id, journal_operation.date_operation, journal_operation.amount, journal_operation.summa

FROM journal_operation

WHERE (((journal_operation.type_id)=2));

6) Запрос для добавления заказа в таблицу состояния движения:

INSERT INTO dynamic_status (order_number, motion_amount, motion_cost, remains_amount, remains_cost, token)

VALUES (order_number, motion_amount, motion_cost, remains_amount, remains_cost, tok);

7) Запрос для обновления заказа в таблице состояния движения:

PARAMETERS motion_amount Long, motion_cost IEEESingle, remains_amount Long, remains_cost IEEESingle;

UPDATE dynamic_status

SET dynamic_status.motion_amount = [motion_amount],

dynamic_status.motion_cost = [motion_cost],

dynamic_status.remains_amount = [remains_amount],

dynamic_status.remains_cost = [remains_cost]

WHERE (((dynamic_status.order_number)=[num]));

8) Запрос для удаления заказа в таблице состояния движения:

DELETE dynamic_status.order_number

FROM dynamic_status

WHERE (((dynamic_status.order_number)=[num]));

9) Запрос о состоянии заказа в таблице движения:

SELECT dynamic_status.order_number, dynamic_status.motion_amount, dynamic_status.motion_cost, dynamic_status.remains_amount, dynamic_status.remains_cost

FROM dynamic_status

WHERE (((dynamic_status.order_number)=[num]));

10) Запрос поиска заказчика по введённым буквам (используется в форме filterCustomers):

SELECT customer_unn, customer_name FROM customers WHERE customer_name Like «& Pol &»;»

На базе СУБД Access 2003 мною разработано программное обеспечение для автоматизации БД «Склад готовой продукции». Вывод информации по запросам выводится на формы и в отчеты, что позволяет более наглядно и красочно представить выдаваемую информацию.

Работа в базе данных начинается с основной формы, с которой осуществляется доступ в другие формы через управляющие элементы на основной форме (кнопки).

В зависимости от выполняемых работ с базой данных выделены четыре управляющих элемента - закладки {Заказы}, {Журналы}, {Заказчики}, {Отчёты}.

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

Формы закладки «Журналы» демонстрируют работу с журналами.

Формы закладки «Заказчики» демонстрируют работу с заказчиками.

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

Работнику архива предоставляется самый полный доступ обработки записей базы данных, т.е. добавление, удаление и редактирование данных. Обработка записей по сотрудникам осуществляется с формы «Обработка данных по сотрудникам», являющейся подчиненной формой к форме «Работник архива» и вызываемой кнопкой {Сотрудники}.

Для учета выдачи и возвращения документов предусмотрены формы «Выдача документации» и «Выданная документация».

4. Результаты тестирования информационной системы

Тестирование необходимо для обнаружения ошибок в программе. Шаги этого процесса организовываются последовательным выполнением действий программы. Тестирование разработанной информационной системы показало, что она работает корректно и готова к использованию. С данной системой могут работать три пользователя, которые различаются по выполняемым с базой данных действиям, то есть система является многопользовательской. Минимальные требования для работоспособности системы необходимо 256 Мбайт оперативной памяти, Windows XP, Access2003.

После тестирования получены следующие результаты:

- информационная система поддерживает многопользовательский режим;

- тестирование запросов, форм, хранимых процедур и триггеров прошло успешно.

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

Заключение

В ходе выполнения курсового проекта были закреплены и усовершенствованы навыки работы с CASE - средствами (Bpwin и Erwin), программирования в среде VBA, использование приложения Microsoft Office 2003 (Access 2003) для создания ориентированной СУБД, а также решена задача формирования базы данных с применением запросов, созданием таблиц и их редактированием. Программа прошла тестирование и готова к практическому использованию.

Размещено на Allbest.ru