Автоматизация работы мебельного магазина

1.4. Функциональные требования

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

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

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

2. Техническое задание

Введение

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

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

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

2.1. Основание и назначение разработки

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

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

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

2. Требования к базе данных

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

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

Программа должна иметь доступный и удобный  интерфейс.

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

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

База данных «Мебельный магазин» должна включать в себя следующие таблицы:

• должность;
• отделы;
• поставка;
• поставщики;
• производители;
• продажа;
• сотрудники;
• типы мебели;
• товары;

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

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

• кол-во продаж по типам мебели;
• поставщики;
• кол-во проданного каждым сотрудником;

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

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

• поставщики;
• типы мебели;
• товары;
• сотрудники;
• производители; 
  

3. Конструкторская часть

3.1. Моделирование потоков данных

Диаграммы потоков данных (DFD – Data Flow Diagram) являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств – продемонстрировать, как каждый процесс преобразует свои входные данные, а также выявить отношения между этими процессами.

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

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

Назначение  процесса состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса.

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

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

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

Главная цель построения иерархического множества  DFD заключается в том, чтобы сделать требования ясными и понятными на каждом уровне детализации, а также разбить эти требования на части с точно определенными отношениями между ними. (Маклаков С. В. Моделирование бизнес-процессов с BRwin 4.0. ДИАЛОГМИФИ. Москва, 2002).

Пример  методологии DFD приведен на рис. 3.1. и рис. 3.2.

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

Диаграмма первого уровня на рис. 3.2. содержит функциональные блоки Продавец, Покупатель, Принять заявку, Обработать заявку, Подготовленная заявка: База данных. Все элементы соединены между собой стрелками.

3.2. Логическая модель базы данных

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

Одним из наиболее удобных инструментов унифицированного представления данных, независимого от реализующего его программного обеспечения, является модель "сущность-связь" (entity - relationship model, ER - model).

 

Рис. 3.1. Контекстная диаграмма «Осуществить обработку заказов»

 

Рис.3.2. Диаграмма DFD 1-го уровня декомпозиции «Осуществить обработку заказов» 

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

Сущность (entity) - любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д.

Набор сущностей (entity set) - множество сущностей одного типа (обладающих одинаковыми свойствами). Наборы сущностей не обязательно должны быть непересекающимися.

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

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

В курсовой работе представлена ER-модель «сущность-связь» рассматриваемой предметной области, которая состоит из 8 таблиц, ее графическое представление показано на рис.3.3.

В ER-модель «сущность-связь» могут быть созданы следующие связи между таблицами: Один – к – одному (1:1)

При таком  виде связи одному экземпляру первой сущности соответствует всего один экземпляр второй сущности.

• Один – ко – многим (1:N)

При таком  виде связи одному экземпляру первой сущности соответствует 1, 2, … , N экземпляров второй сущности.

• Многих – ко – многим (N:M)

При таком  виде связи одному экземпляру первой сущности соответствует 1, 2, …, N экземпляров второй сущности, и в тоже время одному экземпляру второй сущности соответствует 1, 2, …, N экземпляров первой сущности.  (Сенов, А.П. Access 2003 Практическая разработка баз данных. Учебный курс.-СПб. Питер, 2006 – 256с.)

В моей курсовой работе была использована связь Один – ко – многим (1:N). Данный вид связи получился между следующими таблицами.

1. Отделы - Сотрудники
2. Сотрудники - Продажи
3. Продажи - Товары
4. Поставщики– Поставка
5. Поставка– Товары
6. Типы мебели– Товары
7. Товар-Производитель
8. Должность -Сотрудники

В ER-модель «сущность-связь» рассматриваемой предметной области представлены следующие сущности.

1. Отделы
2. Сотрудники
3. Продажи
4. Товары
5. Поставщики
6. Производители
7. Типы мебели
8. Поставка

3.3. Реализация базы данных

3.3.1. Обоснование выбора системы управления базами данных

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

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

 

 

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

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