Автоматизированный учет торговой сети

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

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

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

 

 

 

 

3 ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

 

3.1 Общая архитектура  программного средства

 

При запуске программного средства открывается Главная кнопочная форма. Данная форма включает в себя следующие кнопки: Запросы БД, Отчеты, Формы, ВыходСохранение.

Кнопка «Запросы БД» включает в себя следующие запросы: Данные о поставщиках, Отсутствующие товары, Поиск поставщика по товару, Наличие товара, и кнопка, которая дает возможность возврата в главное меню.

Кнопка «Отчеты» включает в себя следующие отчеты: Поставщик, Отчет по продажам.

Кнопка «Формы» включает в себя следующие формы: Заказы, Данные о поставщиках, Наличие товара, Сотрудники, Поставщики, Товары, Чек.

Схема данных программного средства представлена на рисунке 3.1.1.

Рисунок 3.1.1 – Схема данных «Автоматизированный учет торговой сети»

 

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

 

3.2 Разработка структуры БД

 

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

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

При проектировании таблиц лучше разработать структуру на бумаге и только затем начинать работу с СУБД Access. При проектировке таблиц, рекомендуется руководствоваться следующими основными принципами:

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

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

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

- не рекомендуется включать в таблицу данные, которые являются результатом выражения;

- в таблице должна присутствовать вся необходимая информация;

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

 

3.3 Инфологическое моделирование

 

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

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

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

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

Между двумя сущностям, например, А и В возможны четыре вида связей.

Первый тип – связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В:

Рисунок 3.3.1 – Связь  ОДИН-К-ОДНОМУ

 

Студент может не «заработать» стипендию, получить обычную или одну из повышенных стипендий.

Второй тип – связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

Рисунок 3.3.2 – Связь ОДИН-КО-МНОГИМ

 

Квартира может пустовать, в ней может жить один или несколько жильцов.

Так как между двумя сущностями возможны связи в обоих направлениях, то существует ещё два типа связи МНОГИЕ-К-ОДНОМУ (М: 1) и МНОГИЕ-КО-МНОГИМ (М: М). В данной курсовой работе их использовать не будем.

 

3.4 Разработка интерфейса ПС

 

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

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

Общая структура интерфейса понятна и удобна в использовании для пользователя любого уровня подготовки.

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

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

Управление программой осуществляется манипулятором типа «мышь», поэтому осуществляется быстрый доступ к информации.

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4 РУКОВОДСТВО СИСТЕМНОГО  ПРОГРАММИСТА

 

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

К дополнительным функциям относятся:

- ведение информации;

- учет поставки товаров;

- печать отчетов.

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

Программная система  должна работать на IBM/PC совместимых персональных компьютерах.

Минимальная конфигурация:

• тип процессора класса Pentium частотой не ниже 500 МГц;
• объем оперативного запоминающего устройства 128 Мбайт;
• место на жестком диске  35 Мбайт;
• тип монитора не ниже VGA;
• клавиатура;
• мышь;
• принтер.

ПС должна работать под управлением операционной системы Windows XP и выше. Также для нормальной работы программы требуется, чтобы на компьютере была установлена СУБД Access 2003 и выше.

Запуск программной системы осуществляется с запуска файла «Автоматизированный учет торговой сети.mdb». При этом запускается главная кнопочная форма, в котором осуществляется навигация по функциям программной системы.

В базе данных находятся следующие созданные таблицы:

- Заказы – таблица заказов;

- Клиенты – таблица, содержащая информацию о клиентах;

- Поставка – таблица о поставках;

- Поставщики – таблица, содержащая информацию о поставщиках;

- Сотрудники  – таблица, содержащая информацию о сотрудниках;

- Товары – таблица о товарах.

Входная информация включает сведения:

- о  заказах (код сотрудника, код товара, дата подачи заявки, дата доставки, код клиента);

- о  клиентах (ФИО, адрес, телефон), обращающихся в магазин;

- о поставках (код поставщика, дата поставки);

- о поставщиках (название поставщика, представитель, ФИО, Контактный телефон, адрес);

- о  сотрудниках магазина (фамилия, имя, отчество, должность, адрес, домашний телефон, дата рождения);

- о  товарах (номер товара, наименование товара, описание, стоимость закупки, наличие, количество, стоимость продажи).

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

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

• текстовый. Текст или числа не требующие проведения расчётов;
• МЕМО.  Поле этого типа предназначено для хранения небольших текстовых данных (до 64000 символов). Поле этого типа не может быть ключевым или проиндексированным;
• числовой.  Этот тип данных содержит множество подтипов. От выбора подтипа (размера) зависит точность вичислений;
• счётчик.  Уникальные, последовательно возрастающие  числа, автоматически вводящиеся при добавлении новой записи в таблицу;
• логический.  Логические значения, а так же поля, которые могут содержать одно из двух возможных значений;
• денежный. Денежные значения и числовые данные, используемые в математических вычислениях. Дата/Время. Дата и время хранятся в специальном фиксированном формате;
• поле объекта OLE. Включает звукозапись, рисунок и прочие типы данных. Поле этого типа не может быть ключевым или проиндексированным;

• гиперсвязь.  Содержит адреса Web-страниц.

 

Таблица 4.1 – Сотрудники

Таблица: Сотрудники
Поле	Тип данных
Код сотрудника	Числовой
Фамилия	Текстовый
Имя	Текстовый
Отчество	Текстовый
Дата рождения	Дата/время
Должность	Текстовый
Адрес	Текстовый
Телефон	Текстовый

 

Таблица 4.2 – Поставка

Таблица: Поставка
Поле	Тип данных
Код поставки	Числовой
Код поставщика	Текстовый
ДатаПостави	Текстовый

 

 

Таблица 4.3 - Товары

 

 

Таблица: Товары
Поле	Тип данных
Код товара	Текстовый
Код поставки	Числовой
Наименование товара	Текстовый
Описание	Поле МЕМО
Стоимость закупки	Денежный
Наличие	Логический
Кол-во	Числовой
Стоимость продажи	Денежный

 

 

 

 

 

 

 

 

 

Таблица 4.4 – Заказы

 

Таблица: Заказы
Поле	Тип данных
Код заказа	Числовой
Код товара	Числовой
Код сотрудника	Числовой
Код клиента	Числовой
Дата зявки	Дата/время
Дата исполнения	Дата/время

 

 

 

 

 

 

 

Таблица 4.5 – Клиенты

 

Таблица: Клиенты
Поле	Тип данных
Код	Числовой
ФИО	Текстовый
Адрес	Текстовый
Телефон	Текстовый