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

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

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

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

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

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

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

Система разработана в СУБД Microsoft Access 2007, т.к. Access является удобным программным средством для ведения и эксплуатации баз данных.

1. Анализ и постановка задачи

1.1 Описание предметной области проектируемой ИС

Магазин розничной торговли осуществляет заказ запчастей в различных странах. В заказах перечисляется наименование товара, количество. Если указанное наименование товара ранее не поставлялось, оно пополняет справочник номенклатуры товаров.

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

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

1.2 Ограничение предметной области

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

— Учитывать бракованные детали, которые бы фиксировались в отдельной таблице;

— Разделить поставщиков по разным категория, которые бы имели различные наборы атрибутов.

Но из-за нехватки времени не удалось этого реализовать.

1.3 Определение требований

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

2. Система должна быть обеспечена формами ввода, обработки информации для каждого режима.

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

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

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

6. Требования, предъявляемые к документам:

а) Каждый документ должен быть построен на запросе с вводом параметров и с использованием полей со списками на форме.

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

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

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

2. Проектирование базы данных

2.1 Определение сущностей

Сущность (объект) — в реляционной теории баз данных элемент информационной системы, информация о котором сохраняется.

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

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

Т_ВидЗапчасти — Список видов запчастей, которые хранятся на складе;

Т_Ед_Времяни — данные о единицах срока годности автозапчасти;

Т_Заказ — список заказов;

Т_заказ_подчин — данные о заказе после покупки;

Т_категория — категории поставщиков;

Т_МаркаМашины — список машин, на которые поставляются запчасти;

Т_Поставщики — данные о поставщиках;

Т_Склад — список автозапчастей имеющихся на складе;

Т_Страна — список стран из которых поставляются автозапчасти;

2.2 Определение взаимосвязей между сущностями

Существующие взаимосвязи между сущностями представлены на рисунке 1.

Рисунок 1 — Схема данных системы

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

2.3 Задание первичных и альтернативных ключей, определение атрибутов сущностей

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

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

Первичный ключ — это атрибут (или группа атрибутов), которые единственным образом идентифицируют каждую строку в таблице.

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

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

Таблица 1

Сущность, первичные ключи и атрибуты

2.4 Представление использования

Исходя из описанных требований, можно построить диаграмму использования работы администратора, продавца и кладовщика данной информационной системы. Результат построения диаграммы использования системы «Магазина автозапчастей» можно увидеть на рисунках 2.

Рисунок 2 — Диаграмма использования работы информационной системы

2.5 Описание физической модели

Процесс приведения модели данных в соответствие требованиям реляционных баз данных называется нормализацией. Описание этого процесса приводится в таблице 2.

Таблица 2

Описание физической модели

3. Разработка программной среды

3.1 Разработка интерфейса пользователя

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

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

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

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

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

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

— Стандартизация. Рекомендуется использовать стандартные, проверенные многими программистами и пользователями интерфейсные решения. В качестве стандарта (образца для «подражания») может служить любое из приложений — Word, Excel или другие приложения Microsoft. Под решениями подразумеваются дизайн форм, распределение элементов управления в формах, их взаимное расположение, значки на кнопках управления, названия команд меню;

— Удобство и простота работы. Интерфейс должен быть интуитивно понятным. Желательно, чтобы все действия легко запоминались и не требовали утомительных процедур: выполнения дополнительных команд, лишних нажатий на кнопки, вызова промежуточных диалоговых окон;

— Внешний дизайн. Нельзя, чтобы интерфейс утомлял зрение. Он должен быть рассчитан на длительную работу пользователя с приложением в течение дня;

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

— Группировка. Элементы управления в форме необходимо группировать по смыслу, используя элементы группировки: рамки, фреймы;

— Разреженность объектов на форме. Элементы управления следует располагать на некотором расстоянии друг от друга; для выделения элементов управления можно организовать пустые пространства на форме.

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

На основе разработанного алгоритма функционирования программной системы требуется физически создать базу данных средствами СУБД MS ACCESS.

На основе таблицы 2 необходимо создать таблицы в режиме конструктора. Для заполнения таблиц (т.е. заполнения информацией программной системы) требуется создать формы для ввода информации в ИС. По таблицам нужно создать требуемые запросы пользователя, которые, в свою очередь, понадобятся для создания отчётов. Для быстрого и удобного доступа к отчетам необходимо создать формы для получения пользователем выходной информации.

3.2 Работа с данными

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

— Категория поставщика;

— Поставщики;

— Марка машины;

— Страны.

база данный магазин автозапчасть

4. Документация пользователя

4.1 Системные требования

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

— Процессор Intel или AMD с тактовой частотой 1000 MHz;

— графический адаптер SVGA;

— расширение экрана минимум 1024 на 768 пикселей;

— мышь, клавиатура;

— Для хранения информации, используемой в системе требуется не менее 3,5 Мб на жестком диске.

Требования к программным средствам:

— ЭВМ должна работать с операционными системами семейства Windows XP/Vista/7;

— Требуется установленный пакет Microsoft Office 2007 .

4.2 Инструкция пользователя

Работа с приложением для пользователя начинается с запуска файла Магазин автозапчастей.accdb. Появится форма для входа в систему. Данная форма показана на рисунке 4.

Рисунок 4 — Форма «Выбор пользователя»

Рисунок 5 — Главная форма пользователя «Администратор», вкладка «Справочная информация»

После выбора определенного пользователя, открывается определенная форма. Для примера рассмотрим приложение, авторизованное под пользователем «Администратор», так как администратору доступны все действия в приложении. Форма показана на рисунке 5.

На выше приведенном рисунке выбрана вкладка «Справочная информация», на ней осуществляется выбор справочников, в которые вносят информацию. При нажатии на кнопку открывается форма, представленная на рисунке 6.

Рисунок 6 — Форма «Категория поставщика»

На вкладке «Учетная информация» осуществляется выбор форм «Запчасти на складе» и «Ввод заказов». При нажатии на кнопку «Запчасти на складе» открывается форма, представленная на рисунке 7.

Рисунок 7 — Форма «Запчасти на складе»

На форме представленной выше, осуществляется ввод запчастей, которые будут храниться на складе, так же можно добавить новую марку машины нажав на кнопку, откроется форма, предоставленная на рисунке 8. Так же с формы «Запчасти на складе» можно добавить нового поставщика нажав на кнопку, откроется форма «Поставщики», рисунок 9.

Рисунок 8 — Добавление новой марки машины Рисунок 9 — форма «Поставщики»

На форме «Поставщики» осуществляется просмотр, добавление или удаления информации о поставщиках, так же добавление новой страны поставщика, при нажатии на кнопку .

Вернемся на вкладку «Учетная информация» откроем форму «Ввод заказов». Данная форма представлена на рисунке 10. На этой форме осуществляется ввод заказов, автоматически вычисляется сумма заказов и прибыль. Если мы оформляем заказ на реализацию товара, сначала жмем на кнопку, если при нажатии на кнопку обновилось «0» записей то деталей на складе нахватает, если обновилось хотя бы одна запись, то покупка произошла успешно.

Рисунок 10 — Форма «Ввод заказов»

На вкладке «Запросы», представленной на рисунке 11. Находятся ссылки на запросы:

— Запчасти определенного вида;

— Запчасти у определенного поставщика;

— Запчасти определенного вида у определенного поставщика;

— Заказы за определенный период;

— Заказы по сумме.

Рисунок 11 — Вкладка «Запросы»

Выбрав запрос «Запчасти определенного вида», у нас открылась форма, представленная на рисунке 12.

Рисунок 12 — Форма «Запчасти определенного вида»

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

Остальные запросы размещены аналогично представленному выше.

На вкладке «Отчеты» показанной на рисунке 13 содержатся элементы управления — группа переключателей, которые позволяют получить документы:

— Все заказы;

— Поставщики автозапчастей;

— Список поставщиков;

— Запчасти на складе.

-

Рисунок 13 — Вкладка «Отчеты»

Отчеты представлены в приложении А.

Заключение

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

1. ГОСТ 2.105−95. Единая система конструкторской документации. Общие требования к текстовым документам. — Введен в действие постановлением Госстандарта РФ от 8 августа 1995 г. № 426.

2. ГОСТ 7.80−2000. Библиографическая запись. Заголовок. Общие требования и правила составления. — Введ. 2000;01−07. — М.: Изд-во стандартов, 2000. — (Система стандартов по информации, библиотечному и издательскому делу).

3. Бобровский, С.И. Access 2007. Учебный курс. / С. И. Бобровский — Спб.: Питер, 2008. — 736с.: ил.

4. Малыхина, М. П. Базы данных: Основы, проектирование, использование [Текст] / М. П. Малыхина — СПб.: БХВ-Петербург, 2007 512 с.: ил.

5. Сухарев, М. Золотая книга Access 2007 [Текст]. / М. Сухарев — СПб.: Наука и техника, 2008. — 1040 с.: ил. ISBN 978−5-94 157−550−3

6. Фленов, М. Е. Библия Access 2007. / М. Е. Фленов — СПб.: БХВ-Петербург, 2007. — 880 с.: ил.

Приложение, А (обязательное)

Выходная документация

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

Далее приведены примеры следующих отчётов:

Отчет «Запчасти определенного вида»

Отчет «Запчасти у определенного вида поставщика»

Отчет «Запчасти определенного вида у определенного вида»

Отчет «Заказы за определенный период»

Отчет «Заказы по сумме большей указанной суммы»

Отчет «Заказы по сумме меньше указанной суммы»

Отчет «Заказы по сумме равная указанной суммы»

Отчет «Все заказы»

Отчет «Поставщики автозапчастей»

Отчет «Список поставщиков»

Отчет «Запчасти на складе»