Разработка Баз данных складского учета

 

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА КУРСОВОГО  ПРОЕКТА

ПО ДИСЦИПЛИНЕ «Базы данных»

 

ТЕМА: Разработка базы данных складского учета магазина «Аква-стар»

 

 

Содержание

 

 

 

Введение

 

В настоящее  время среди разработчиков базы данных (БД) большой популярностью  пользуется реляционная СУБД ACCESS, входящая в состав пакета  Microsoft Office 2003. Дружественный интерфейс  и простота настройки, эффективные средства создания таблиц, форм, запросов, интеграция с другими приложениями пакета, средства организации работы с базами данных и защита информации - вот далеко не полный перечень достоинств этого приложения.

Основные функции  СУБД – это описание структуры  базы данных, обработка данных и  управление данными.

База данных – это совокупность сведений о  реальных объектах, процессах, событиях или явлениях, относящихся к определённой теме или задаче, организованная таким образом, чтобы обеспечить удобное представление этой совокупности, как в целом, так и любой её части. Реляционная база данных представляет собой множество взаимосвязанных таблиц, каждая из которых содержит информацию об объектах определённого типа. Каждая строка таблицы содержит данные об одном объекте (например, клиенте, автомобиле, документе), а столбцы таблицы содержат различные характеристики этих объектов – атрибуты (например, наименования и адреса клиентов, марки и цены автомобилей). Строки таблицы называются записями, все записи имеют одинаковую структуру – они состоят из полей, в которых хранятся атрибуты объекта. Каждое поле в записи содержит одну характеристику объекта и имеет строго определённый тип данных (например, текстовая строка, число, дата). Все записи имеют одни и те же поля, только в них содержатся разные значения атрибутов.

Любая СУБД позволяет  выполнять четыре простейшие операции с данными:

- добавить в  таблицу одну или несколько  записей;

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

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

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

1. Общая характеристика и анализ объекта исследования

1.1. Общая  характеристика предметной области  и анализ объекта исследования

 

В данном курсовом проекте в качестве предметной области  рассматривается магазин «Аква-стар». Разработанная база данных «Склад» решает следующие задачи: учёт товара, выдача данных о поставщиках и поставляемых ими товарах, выдача данных о покупателях приобретаемых ими товарах (фирма-поставщик, его реквизиты, наименование товаров, характеристики, цены), вычисляет суммы оплаты.

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

Применяемая СУБД: АССЕSS 2003 .

Исходные данные о магазине: магазин располагается  в нескольких помещениях (склад, торговый зал). У фирмы есть поставщики, осуществляющие поставку товаров на склад магазина.

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

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

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

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

 

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

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

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

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

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

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

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

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

• Отчетов о списках заказов;
• Отчётов о сведениях о покупателях;
• Отчет о сведениях о поставщиках.

 

 

 

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

 

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

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

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

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

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

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

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

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

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

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

Основными информационными  объектами системы СКЛАД являются: покупатель, заказ, товар, поставщик, полка. Между ними можно установить следующие логические отношения:

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

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

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

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

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

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

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

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

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

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

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

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

 

3. Датологическое моделирование

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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