Информационная система управления торгово-закупочной фирмы

Для разработки модели данных использовалось инструментальное средство Erwin. Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире. Объекты модели, представляемые на логическом уровне - сущности и атрибуты. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД. Логический уровень модели данных представлен на рисунке 6.

Рисунок 6. Логический уровень представления

Логический уровень отличается от физического тем, что на нем данные выглядят как в реальности. Между тем физический уровень зависит от конкретной СУБД (MS SQL Server 2000), фактически являясь отображением системного каталога. Создав логическую модель, можно сгенерировать физические модели под любую поддерживаемую ERwin СУБД. В физической модели содержится информация о всех объектах БД.

По заданию на курсовое проектирование нам необходимо использовать нотацию IDEF1X.

Рисунок 7. Физический уровень представления

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

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

3. Приведение модели к 3 нормальной форме

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

После построения модели данных она проверяется в Erwin Validator на наличие ошибок. В Erwin Validator есть средство ERWin Examiner. С помощью него можно анализировать структуру баз данных с целью выявления недочетов и ошибок проектирования. Ошибки бывают 4 категорий:

· Ошибки проектирования колонок

· Ошибки индексов и ограничений

· Ошибки нормализации( приведения к 1,2,3 н.ф.)

· Ошибки связей

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

Рисунок 8. Отчет об ошибках

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

4. Связывание моделей

После разработки модели данных её следует связать с моделью процессов, что гарантирует завершенность анализа, корректности и согласованности сущностей и работ. Для этого необходимо в Erwin выбрать пункт меню File/Export/Bpwin и создать файл экспорта *.eax, а затем в Bpwin выбрать File/Import/Erwin.

На рисунке 9 отображены те сущности, которые были импортированы в Bpwin.

Рисунок 9. Импорт сущностей в Bpwin.

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

Рисунок 10. Связывание со стрелками сущностей и атрибутов.

Рисунок 11. Таблица связывания.

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

5. Интеграция модели данных Erwin и SQL Server 2000

После получения схемы модели данных необходимо интегрировать функциональную модель, созданную в Erwin c СУБД. Для этого произвелось подключение к серверу SQL. Затем я создал там базу данных Firma. После соединения в неё добавились 8 таблиц, аналогичных таблицам Erwin и MS Access.

Рисунок 12. Таблица “товары” в БД Firma.

Рисунок 13. БД “Клиенты” в БД Firma.

В результате интеграции, изменяя данные в MS Access изменения вносились и в таблицы расположенные на SQL Server'е.

6. Перевод базы данных на SQL Server 2000

Для того чтобы перевести базу данных в формат SQL Server 2000, необходимо выполнить следующие действия: создать на сервере базу данных командой create database Firma, где Firma - уникальное в пределах сервера имя базы данных, cоздать в Microsoft Access проект существующей базы данных.

Рисунок 14. Связь с данными.

Рисунок 15. Импорт объектов.

Рисунок 16. Создание приложения Access "клиент-сервер".

В результате проделанных операций все данные базы данных Access сохранились в базе данных на SQL сервере.

7. Разработка клиентского приложения

Разработка клиентского приложения осуществлялась с помощью MS Access.

Были созданы следующие формы, таблицы и запросы:

Рисунок 17. БД товаров.

Рисунок 18. Форма регистрации клиентов.

Форма определения к какому отделу принадлежит сотрудник фирмы:

Рисунок 19. Форма "Просмотр сотрудников".

Таблица клиентов, из рисунка видно, что таблица связана с таблицей заказы:

Рисунок 20. Связывание таблиц.

Таблица сотрудников фирмы:

Рисунок 21. Таблица "Сотрудники".

По коду заказа клиент может просмотреть свой заказ:

Рисунок 22. Форма "Просмотр состояния заказа".

Аналогично предыдущей форме работает запрос:

Рисунок 23. Запрос "Просмотр состояния заказа".

После ввода значения кода заказа (например 32) выводятся характеристики заказа:

Рисунок 24. Запрос "Данные заказа".

Структуру взаимодействия таблиц отображает схема данных фирмы:

Рисунок 25. Схема данных.

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

8. Диаграммы в аннотации UML

В соответствии с заданием на курсовое проектирование необходимо разработать диаграммы функционирования информационной системы, на основе AllFusion Component Modeler'а. Этот пакет позволяет эффективно генерировать код приложений. AllFusion Component Modeler поддерживает методологию CA Catalysys, ориентированную на технологию компонентной разработки. Для характеристики торгово-закупочной фирмы необходимо описать архитектуру фирмы, которую наиболее полно отражают диаграммы компонентов и размещения. По клиентскому приложению была построена диаграмма классов.

Рисунок 26. Диаграмма компонентов.

Рисунок 27. Диаграмма размещения.

Рисунок 28. Диаграмма классов.

Заключение

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

Список используемой литературы

1. Маклаков С.В. Создание информационных систем с AllFusion Modelling Suite. - М.: ДИАЛОГ - МИФИ, 2002. - 224с.

2. Сайт case-web «Информационные системы».

3. «Информационные системы» (http://alice.stup.ac.ru/case).

4. Макарычев П.П.: Курс лекций по дисциплине «Проектирование информационно-управляющих систем».

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