Базы данных "Склад"

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

БАЗА ДАННЫХ «СКЛАД»



Введение

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

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

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



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

1.1 Назначение системы

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

ѕ Информационная система СКЛАД предназначена для ввода, хранения и обработки данных о товарах, поступающих и хранящихся на складе.

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

Склад предназначен для хранения товаров определенных типов.

- Необходимо хранить характеристики категорий товаров и их наименования.

- Для каждого наименования товара следует знать размер минимального запаса, определенного для этого вида товара.

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

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

- Информационная система должна включать сведения о типе (категории) товара, наименовании товара, номерах партий поставляемого товара.

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

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

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

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

- Необходимо хранить сведения о покупателях: их реквизиты и телефоны для связи.

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

Ведение складского учета требует проведения периодических проверок:

- Отчетов о списках заказов;

- Отчётов о позициях заказов и покупателях.

интерфейс база данные автоматизированный



2. Проектирование информационной системы

2.1 Выбор информационной модели и программного средства ее представления

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

· Модель «сущность-связь» (Entity Relationship - ER-модель) является визуальным средством представления объектов рассматриваемой предметной области, их характеристик (реквизитов) и отношений между объектами.

· Для создания модели будет использоваться Microsoft Word.

2.2 Идентификация объектов предметной области и отношений между ними

Основными информационными объектами системы СКЛАД являются:

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

- «покупатель» «должен» «заказать» один или более «заказ».

- «заказ» «должен» «быть заказан» «один и только один» «покупатель».

- «товар» «может быть» «заказан» «в одном или более» «заказов».

- «заказ» «должен» «состоять» «из одного или более» «товаров».

- на «полке» «может» «храниться» «один или более» «товаров».

- «товар» «должен» «храниться» «на одной или нескольких» «полках».

- «поставщик» «должен» «поставлять» «один или более» «товаров».

- «товар» «должен быть» «поставлен» «одним или более» «поставщиком».

Идентифицированные объекты представлены в виде сущностей и атрибутов в модели. Отношения между объектами реализованы в виде логических отношений сущностей (рис.1).

2.3 Создание модели «сущность-связь»

Для информационных объектов, идентифицированных в рамках рассматриваемой предметной области Склад, с помощью Microsoft Word создана модель «сущность-связь» (рис.1).

Рис.1. Модель «сущность-связь» для предметной области Склад

2.4 Нормализация модели данных

Модель «сущность-связь», представленная на рис.1 не находится в первой нормальной форме, так как в сущностях Покупатель, Товар и Заказ имеются множественные и повторяющиеся атрибуты, которые представляют собой упущенные в модели сущности.

На рис.2 показан результат приведения к 1НФ сущности Покупатель. Атрибут Тип_покупателя выделен в отдельную сущность и исключен из сущности Покупатель, как повторяющийся атрибут.

На рис. 2 также показан результат приведения к 1НФ сущности Товар. Группа множественных атрибутов Дата_поставки, Количество, Наличие, Цена_поставки являются упущенной сущностью Партия_товара, поэтому они были удалены из сущности Товар и вынесены в отдельную сущность Партия_товара. Установлена логическая связь между новой сущностью Партия_товара и сущностью Поставщик.

Повторяющийся атрибут Тип_товара вынесен из сущности ТОВАР в отдельную сущность.

Также на рис.2 показан результат приведения к 1НФ сущности Заказ. Повторяющийся атрибут Форма_оплаты вынесен в отдельную сущность и исключен из сущности Заказ. Группа множественных атрибутов Наименование_товара, Количество, Цена_реализации вынесена в отдельную сущность Пункт_заказа и исключена из сущности Заказ.

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

Окончательный результат приведения к 1НФ всей модели показан на рис. 2. Между сущностями Полка и Тип_товара установлена логическая связь, которая следует из анализа предметной области: полки спроектированы под определенные типы товаров, то есть полка характеризуется типом товара, который может быть на ней размещен.



Рис.2. Приведенная к 1НФ модель Склад

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

Приведение к 3НФ состоит в исключении транзитивных зависимостей атрибутов от атрибутов, не являющихся частью ключа.

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

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

2.5 Устранение связей «многие-ко-многим»

В модели Склад присутствует связь «многие-ко-многим» между сущностями Полка и Товар. Устранение этой связи требует создания межсекционной сущности. По смыслу, имя такой межсекционной сущности может быть Партия_товара. Так как в модели уже присутствует сущность Партия_товара, то в целях устранения избыточности хранения данных, эта сущность может быть использована в качестве межсекционной при устранении связи «многие-ко-многим». Результат устранения множественной связи показан на рис. 3.

Рис.3. Модель «Склад» после устранения связей «многие-ко-многим



3. Разработка информационной системы

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

На основе модели «сущность-связь» разрабатывается структура базы данных. Физическая модель для предметной области Склад представлена на рис.4.

Рис.4. Физическая модель Склад

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

Покупатель:



Тип_покупателя:

Заказ:

Форма_оплаты:

Пункт_заказа:

Товар:

Тип_товара:

Партия_товара:

Поставщик:

Полка:

3.2 Обоснование выбора СУБД для реализации базы данных

· СУБД Microsoft Access - наиболее распространенная программа для создания информационных систем, на мой взгляд, из-за того, что пакет Microsoft Office есть практически в каждом доме и в каждом офисе.

· Access обладает рядом уникальных возможностей:

· · объединение информации из самых разных источников (электронных таблиц, текстовых файлов, других баз данных);

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

· · интеграция с компонентами Microsoft Office.

· Но, по моему мнению, эта программа имеет недоработки, возникают трудности при работе с этой программой.

3.3 Реализация базы данных средствами выбранной СУБД

Средствами выбранной СУБД Access созданы таблицы реляционной базы данных и схема отношений (рис.5).

Рис.5. Схема данных для базы данных «Склад»

· Реализация таблиц для базы данных Склад в Access имела следующую особенность:

· ѕ Поскольку таблица Форма_оплаты содержит только два взаимоисключающих значения: наличный или безналичный расчет, то эти значения можно закодировать числами 0 и 1, и хранить в поле таблицы Заказ. А реализацию этого поля в форме Заказ (этот объект позволяет заполнять таблицу) выполнить с помощью элемента управления «переключатель». Таким образом, из модели на рис.5 устранена таблица Форма_оплаты.

· ѕ Для ввода данных в поля Телефон в таблицах Покупатель и Поставщик применен механизм маски. Реализация этого механизма показана на рис.6.



Рис.6. Использование маски ввода для поля Тел поставщика таблицы Поставщик

3.4 Создание интерфейса пользователя для автоматизированных рабочих мест

На этапе анализа были сформулированы задачи, которые пользователи системы будут выполнять с использованием созданной базы данных. Перечислим задачи пользователей, для решения которых необходимо разработать пользовательский интерфейс автоматизированных рабочих мест (АРМ):

1. Прием партий товара от поставщика, запас товара, данные о товарах - АРМ Товар.

2. Данные о поставщиках - АРМ Поставщик.

3. Информация и отчёты о покупателях - АРМ Покупатель.

4. Заказы товаров, отчёты о заказах - АРМ Заказ.

Меню открывается автоматически при запуске базы данных (рис.7)



Рис.7. Меню пользователя

АРМ Товары

Объекты, составляющие АРМ Товары, инициируются с помощью командных кнопок вкладки Товары из меню пользователя (рис.8).

Рис.8. Меню пользователя: вкладка Товары

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

Эта форма позволяет выполнять следующие операции:

-Выбирать тип товара из списка;

-Открывать формы Полка, Поставщик

-С помощью запроса узнавать о данных товаров для экспорта, о запасах товара.

АРМ Поставщик

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

Рис.9. Меню пользователя: вкладка Поставщики

АРМ Покупатели

Для получения информации о поставщиках, а также об отчётах имеется вкладка Покупатели (рис.10).

Рис.10. Меню пользователя: вкладка Покупатели

Рассмотрим более подробно АРМ Заказ, структура остальных АРМ аналогична.

АРМ Заказ

Объекты, составляющие АРМ Заказ, инициируются с помощью командных кнопок вкладки Заказ из меню пользователя (рис.11).

Рис.11. Меню пользователя: вкладка Заказы

Для решения задачи оформления заказов покупателям была разработана форма Заказ (рис. 12), которая открывается с помощью командной кнопки Заказ товаров.

Рис.12. Меню пользователя: вкладка Заказы



Форма Заказ позволяет выполнять следующие операции:

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

Рис.13. Форма Покупатель

2. Выбор формы оплаты заказа с помощью переключателя.

3. Формирование позиций заказа путем выбора имеющихся на складе товаров из списка.

4. Найти свободные места на полках, вычислить прибыль по видам товаров.

5. Автоматическое вычисление стоимости заказа и цены реализации - командная кнопка Стоимость заказа и Установить цену реализации соответственно (запрос на обновление) (рис.14)



Рис.14. Запрос для вычисления цены реализации

6. Запись данных о проданных партиях товаров в архивную таблицу Проданные партии товаров - командная кнопка В архив проданное.

7. Автоматическое удаление сведений о проданных партиях товаров со склада - командная кнопка Удаление записей о проданных партиях.

8. Удаление заказа из базы данных.

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

- основная форма Заказ;

- подчиненная форма Пункт_заказа;

- подчиненная форма Стоимость_заказа, реализованная на основе запроса Стоимость_заказа (рис.15)

Рис.15. Запрос для вычисления стоимости всего заказа



Для удаления текущего заказа из базы данных создан запрос на удаление (рис.16) и макрос для выполнения запроса (рис.17).

Рис.16. Запрос на удаление

Рис.17. Макрос для инициализации выполнения запроса на удаление



Для добавления записей о проданных партиях товаров в архивную таблицу создан запрос на добавление (рис.18).

Рис.18. Запрос на добавление данных в архивную таблицу

Отчёты в базе данных также предоставлены для получения необходимой информации. Примером является отчёт Список заказов и покупателей (рис.19)

Рис.19. Отчёт о списках заказов

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



Рис.20. Макрос autoexec



Заключение

В курсовой работе была разработана и воплощена в жизнь с помощью Microsoft Access база данных «Склад». Вследствие чего можно сделать следующие выводы:

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

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

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

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

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