Разработка информационной системы учета складских операций

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

КУРСОВАЯ РАБОТА

на тему: «Разработка информационной системы учета складских операций»



Содержание

1. Анализ предметной области и постановка задачи

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

2.1 Построение ЕR-диаграммы

2.2 Построение схемы реляционной модели базы данных в третьей нормальной форме

2.3 Описание физической базы данных

2.4 Проектирование интерфейса базы данных

3. Программная реализация продукта

3.1 Создание структуры таблиц

3.2 Создание форм для ввода и просмотра данных



1. Анализ предметной области и постановка задачи

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

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

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

Поставщики и товары связаны накладными поставок, а покупатели и товары -- чеками о покупках.

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

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

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

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

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

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

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

- Формирование номенклатуры продаваемых товаров

- Изменение информации о хранении товаров в соответствии с накладными поставок

- Изменение количества товаров в соответствии с количество продаж

- Формирование и печать при необходимости накладных поставок

- Формирование и печать чеков проданных товаров

- Учет количества товаров на складе

- Формирование заявок на поставку недостающих товаров

- Проверка срока годности товаров

- Возможность поиска товара по номеру или названию

- Возможность поиска информации о поставщике

- Возможность поиска накладных по указанной дате

- Сортировка товаров по поставщикам

- Сортировка товаров по сроку годности

- Возможность поиска товаров по указанному поставщику

- Возможность фильтрации данных по поставщикам

- Возможность фильтрации данных по дате поставки.

- Формирование еженедельных отчетов по продажам

- Формирование еженедельных отчетов по поставкам.

- Формирование ежемесячных отчетов по поставкам.

Рисунок 1.1 - Концептуальная модель предметной области

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

При исследовании предметной области были определены характеристики основных объектов предметной области.

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

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

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

Кроме того, в БД хранится информация о покупках/поставках, которая описывается следующими данными: дата поставки/покупки, количество, название товара, сумма поставки/заказа, форма оплаты.



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

2.1 Построение ЕR-диаграммы

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

- Хранить информацию о товарах, поставщиках изаказчиках.

- Печатать накладные и чеки на отпущенные товары.

- Следить за наличием товаров на складе.

Выделим все существительные в этих предложениях и проанализируем их:

- Товар - стержневая сущность

- Поставщик -- стержневая сущность

- Покупатель/Заказчик -- стержневая сущность

- Накладная -- ассоциативная сущность, которая связывает поставщика и товар

- Чек/накладная об отгрузке - ассоциативная сущность, которая будет связывать заказчика/покупателя с товаром

- (?) Склад - Если имеется несколько складов то это сущность, иначе информацию о нем нет нужды хранить в базе данных

Рисунок 2.1 - Предварительный вид ЕR-диаграммы

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

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

Рисунок 2.2 -- Пример ЕR-диаграммы для связи сущностей Товар и Покупатель

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

Теперь можем построить ЕR-диаграмму сущностей для предметной области «Склад-магазин бытовой химии»

Теперь для каждой сущности добавим характеризующие её атрибуты. Эти атрибуты выплывают из характеристик наших сущностей, которые былиопределены на этапе исследования предметной области.

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

Рисунок 2.4 - Оптимизированная ЕR-диаграмма

С учетом всего выше перечисленного мы можем построить полную ЕR-диаграмму предметной области.

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



2.2 Построение схемы реляционной модели базы данных в третьей нормальной форме

Реляционная модель базы данных - это представление данных в виде отношений (двумерных таблиц). Любое отношение должно находиться как минимум в третьей нормальной форме. В предыдущем подразделе при построении ЕR-диаграммы были выделены основные сущности предметной области, т.е. товар, покупатель/поставщик, список накладной, список чека. Информация, характеризующая каждую из этих сущностей, может быть объединена в соответствующе реляционное отношение.

Таблица 2.1 - Отношение «Товар»

Код_тов	Название	Серийный номер	Фирма- Производ	Цена	Кол	Ед.изм	Упаковка	Объем упаковки	ВидТовра	Скидка

То есть реляционная модель предметной области может быть представлена следующими отношениями.

Таблица 2.2 - Отношение «Поставщик/Покупатель»

Код_П	Название	Адрес	Контакт. Номер	Факс	Конт.Лило	Название банка	Расч/счет	МФО банка	Признак

Таблица 2.3 - Отношение «Список накладной»

		Код_т	| Дата пост.	1 Цена опт	Кол. Пост

Таблица 2.4 - Отношение «Список чека»

№_списка	Код_т	№_чека	Дата_пок	Кол	Наличие скидки на товар	Скидка на покупку



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

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

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

Для первых двух отношений это определение справедливо, т.е они находятся в 3НФ.

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

{Код_П, Дата_Пост} -->№_накладной

{Код_Т, Цена_оптДСол_пост}-->Пор_№

{ Пор_№ } -->№_накладной

С учетом этого мы можем разбить отношение «Список накладной» на два отношения Накладная (№_накладной, Дата-пост, Код_П) и Список Накладной(Пор_№, Код_т, Кол_пост,Опт_цена,№_накладной).

В отношении «Список чека» возникают аналогичные аномалии, т.е. одна дата для одного чека и для нескольких покупок, скидка выдается на все товары одного чека. Поэтому отношение «Список накладной можно разбить на два отношения»: Чек (№_чека, ДатаПокупки, ВремяПокупки, Скидка на покупку, ФормаОплаты,ОбщаяСумма) и «СиисокЧека» (№_списка,№чека, Код_т, Количество, Наличие скидки на товар).

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



2.3 Описание физической базы данных

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

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

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

Таблица 2.5 -- Типы полей

Название поля	Тип поля	Размер поля	Дополнительные ограничения
Код_П	Числовой	5	Ключевой поле таблицы Поставщик/Покупатель
Код Т	Числовой	5	Ключевое поле таблицы Товар
Пор_№	Счетчик	3	Ключевое поле таблицы Список накладной
№_списка	Счетчик	3	Ключевое поле таблицы Список чека
Название_П	Текстовый	50
Название_Товар	Текстовый	50
Адрес	Текстовый	150
Конт тел	Числовой	15
Название банка	Текстовый	30
Расч/счет	Числовой	20
Факс	Текстовый	30
Конт. Лицо	Текстовый	30
Цена опт	Денежный
Цена	Денежный
Наличие скидки	Логический
Количество	Числовой	10
Упаковка	Текстовый	15
Название поля	Тип поля	Размер поля	Дополнительные ограничения
Объем упаковки	Числовой	10
№ наладной	Числовой	6
Ед. измерения	Текстовый	10
№ чека	Числовой	6
Дата покупки	Дата	Средний формат даты	По умолчанию текущая дата
Дата поставки	Дата	Краткий формат даты
МФО банка	Числовой	10
Признак	Текстовый	10	Поставщик, Заказчик
Фирма-Производитель	Текстовый	30
Сорт	Текстовый	15
Серийный номер	Числовой	15
Скидка на покупку	Процент	4
Скидка на товар	Процент	4
ВремяПокупки	Время

Кроме того, предметная область накладывает на вводимые данныеследующие значения (ограничения?О_о):

- Поставщик или заказчик имеют одни расчетный счет в одном банке

- Размер скидки не превышает 10%

- Для одного номера накладной одна дата поставки

- Заказчиком/покупателем может быть любой человек, даже если информация о нем не занесена в базу данных

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

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

2.4 Проектирование интерфейса базы данных

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

Основное меню будет выглядеть так, как показано на рисунке 2.5



Рисунок 2.5 - Эскиз меню базы данных

При нажатии на кнопку Ввод данных будет открыт о дополнительное подменю. (Рисунок 2.6)

Рисунок 2.6 - Эскиз вкладки ввод данных

При нажатии на кнопку «Ввод нового поставщика/заказчика» будет открываться следующая форма.

Рисунок 2.7 - Вид формы, для вода данных о поставщике/заказчике

При нажатии на кнопку «ввод информации о новом товаре» будет открыта форма аналогичного вида как на рисунке 2.6, только- в полями отношения «Товар».

При нажатии кнопки «Ввод новой накладной» будет открываться форма как на рисунке 2.8

Рисунок 2.8 - Эскиз формы «Ввод новой накладной»

При нажатии кнопки «Формирование чека» будет открыта форма как на рисунке 2.9

Рисунок 2.9 - Эскиз формы «Формирование чека»

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

Рисунок 2.10 - Эскиз вкладки Редактирование



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

Рисунок 2.11- Эскиз формы просмотра информации о поставщиках

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

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

При выборе вкладки Поиск будет открываться следующая форма:



Рисунок 2.12 - Эскиз вкладки «Поиск»

При нажатии на кнопку поиска будет открываться окно для ввода параметра поиска, например как на рисунке 2.13

Рисунок 2.13 - Вид окна для ввода параметра поиска

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

Рисунок 2.14 - Эскиз вкладки «Отчеты»

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

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

Кнопка «Закрыть» формы основного меню будет закрывать главную форму, а нажатие кнопки «ВЫХОД» будет осуществлять выход с базы данных.

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



3. Программная реализация продукта

3.1 Создание структуры таблиц

На основании описанных отношений в предыдущем раздела создаем в режиме конструктора соответствующие таблицы. В результате получаем 6таблиц, структуры которых представлены на рисунках 3.1 -3.6.

Для поля Дата и время установлены значения по умолчанию - Текущая дата и Текущее время.

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

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

3.2 Создание форм для ввода и просмотра данных

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

С учетом всех возможностей выбранного СУБД и требований предметной области были созданы следующие формы.

Для ввода информации о новом товаре была создана форма представленная на рисунке 3.7

Рисунок 3.7 - Вид формы для ввода информации о новом товаре

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



Рисунок 3.8 - Вид формы для ввода информации о новом поставщике/заказчике

В этой и предыдущей форме добавлены кнопки. Кнопка «Закрыть форму» закрывает открытую форму, кнопка «Добавить запись» заносит в БД введенную в поля информацию и открывает окно с пустыми полями для ввода новой записи. Две кнопки со стрелками позволяют переходить к просмотру предыдущей (введенной записи), и к следующей по порядку записи. Для ввода информации о накладных и их товарах была создана сложная форма, которая в качестве основной использует поля таблицы «Накладная», а в качестве подчиненной по № накладной поля таблицы «Список накладной» и в качестве подчиненной по Коду Поставщика (для вывода реквизитов поставщика) поля из таблицы Поставщик/заказчик. Информация о самом складе-магазине создана в виде текстового поля. Кроме того, в подчиненную форму Список Накладной добавлено вычисляемое поле Сумма, в котором будет вычисляться произведение количества поставленного товара на его оптовую цену. Для подсчета общей суммы поставок в примечание формы добавлено вычисляемое поле Общая сумма. Вид созданной формы представлен на рисунке 3.9.



Рисунок 3.9 Вид формы для ввода данных новой накладной

Для формирования чека создали форму вид которой представлен на рисунке 3.10.

Рисунок 3.10 - Вид формы для формирование покупки

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

...