Проектирование АИС для супермаркета

Введение 3 1.Описание предметной области 5 2.Обоснование средства проектирования 10 3.Концептуальное проектирование 15 4. Физическая модель и схема данных 18 5.Описание функционала приложения 22 Заключение 28 Список использованных литературных источников 29

Введение

Совокупность многих различных процессов разработки разного рода программного обеспечения (ПО) всегда представляются сложной и многоаспектной системой выполнения этапов в рамках определенной методологии создания программного продукта. Существующие на современный день методы разработки иногда разделяют на несколько основных групп: последовательные, циклические, абстрактные и иные. Для последовательных методологий проектирования ПО основной можно считать так называемую водопадную модель для разработки ПО; для циклических методик – итеративную, для абстрактного инструментария – модель индивидуального процесса. Заметим, что вне зависимости от типа применяемой модели, для всех практически известных методологий разработка программ сразу начинается с определений всех требований, потом следуют стадии проектирования, реализации, тестирования. Завершающим этапом считают внедрение и сопровождение созданного ПО. Современная сфера предоставления услуг и производства должна развиваться в направлении полной автоматизации с широким использованием персональных компьютеров (ПК), внедрения новые гибкие технологии, позволяющих эффективно и быстро перестраивать производственные процессы на изготовление новейших изделий или предоставление более качественных услуг. Актуальность проводимого исследования состоит в разработке АИС, который дает возможность адаптации программы под непосредственные требования конкретной организации. В этом и есть основное отличие между универсальными программными платформами, которые направлены на общую деятельность компаний и ПО, что создается для обеспечения функционирования определенного бизнес-процесса внутри супермаркета. Цель курсовой работы – выполнить проектирование АИС для супермаркета. Исходя из поставленной цели необходимо решить такие основные задачи: – провести анализ литературы с теории проектирования информационных систем;  провести анализ предметной области — супермаркет;  выполнить основные этапы проектирования БД и АИС;  разработать АИС с помощью программного средства Access. Объект исследования: супермаркет. Предмет исследования: учет товаров супермаркета. Курсовая работа состоит из введения, основной части, заключения, списка литературы и базы данных.

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

Основным видом деятельности супермаркета является «Торговля розничная продуктами питания». Дополнительные виды деятельности: – Торговля розничная пищевыми продуктами, напитками и табачными изделиями.  Торговля розничная непродовольственными потребительскими товарами.  Торговля розничная неспециализированная.  Торговля розничная преимущественно пищевыми продуктами, включая напитки, и табачными изделиями в неспециализированных магазинах.  Торговля розничная прочая в неспециализированных магазинах.  Торговля розничная алкогольными напитками, включая пиво, в специализированных магазинах.  Торговля розничная прочими товарами в специализированных магазинах.  Деятельность автомобильного грузового транспорта и услуги по перевозкам. Заметим, что для ведения торговой деятельности супермаркет в направлении торговли имеет определенное помещение магазина, склад магазина для комплектации и хранения продовольственных товаров. Вся деятельность ведется в магазине. Магазин – это стационарный пункт для выполнения розничной торговли, который занимает отдельное территориально распределенное помещение и имеет большой торговый зал для реализации товаров. В основные функции супермаркета входит: – управление товарными запасами; – изучение уровня спроса на продаваемые товары, а также их рыночные предложения; – поддержания баланса между спросом и предложением на продукцию; – формирование торгового ассортимента; – непосредственное удовлетворение потребностей клиентов в товарах; – реализация учета продукции, товародвижения и другие. Структура супермаркета показана на рисунке 1. В супермаркете представлено ассортимент в количестве более 10000 видов, каждый с которых имеет условия хранения, период годности. Каждый день в магазин поступает новый вид товаров. Рисунок 1 – Структура супермаркета Рассмотрим обязанности сотрудников склада [11]. 1. Заведующий складом супермаркета обязан: – Руководить работой склада супермаркета по приему, хранению и отпуску товарно-материальных ценностей, по их размещению с учетом наиболее рационального использования складских площадей, облегчения и ускорения поиска необходимых материалов, инвентаря и т.п. – Обеспечивать сохранность складируемых товарно-материальных ценностей, соблюдение режимов хранения, учет складских операций. – Обеспечивать соблюдение правил оформления и сдачи приходно-расходных документов, составлять установленную отчетность по предприятию. – Следить за наличием и исправностью противопожарных средств, состоянием помещений, оборудования и инвентаря на складе супермаркета и обеспечивать их своевременный ремонт. – Организовывать проведение погрузочно-разгрузочных работ на складе магазина с соблюдением правил охраны труда, техники безопасности, производственной санитарии и противопожарной защиты, сбор, а также хранение и своевременный возврат поставщикам погрузочного реквизита. – Участвовать в проведении инвентаризаций товарно-материальных ценностей. Функции бухгалтера склада супермаркета: – Осуществляет организацию бухгалтерского учета хозяйственно-финансовой деятельности склада супермаркета и контроль экономного использования материальных, трудовых и финансовых ресурсов; – Готовит рабочие планы счетов, форм первичных учетных документов, применяемых для оформления хозяйственных операций, по которым не предусмотрены типовые формы; – Обеспечивает проведение инвентаризаций, контролирует проведение хозяйственных операций, соблюдение технологии обработки бухгалтерской информации и порядка документооборота; – Обеспечивает рациональную организацию бухгалтерского учета и отчетности на складе супермаркета; – Принимает меры по предупреждению недостач, незаконного расходования товарно-материальных ценностей, нарушений финансового и хозяйственного законодательства. Функции специалиста товародвижения: – Осуществлять и контролировать обработку заказов на поставку товаров. – Обеспечение правильного складирования продукции на складе супермаркета. – Вырабатывать и внедрять организационно технические мероприятия для управления запасами. – Организовывать мероприятия по транспортировке товаров в отделы супермаркета. Функции специалиста приходно-расходных материалов: – Осуществляет работу по приему, хранению и отпуску товарно-материальных ценностей на складах супермаркета, вычислению и контроля их остатков. – Обеспечивает сохранность складируемых товарно-материальных ценностей, соблюдение режимов хранения, ведение учета складских операций. – Обеспечивает соблюдение правил оформления и сдачи приходно-расходных документов, составление установленной отчетности. – Участвует в проведении инвентаризаций товарно-материальных ценностей. Грузчик имеет следующие обязанности: – Осуществляет погрузку и выгрузку. – Устанавливает лебедки, подъемные блоки, устройство временных скатов и другие приспособления для погрузки и выгрузки грузов. – Осуществляет крепление и укрытие грузов на складах супермаркета и транспортных средствах. – Переносит щиты и трапы. Охранник должен: – Нести службу по охране объектов и материальных ценностей. – Осуществлять проверку документов у проходящих на охраняемый объект (выходящих с объекта) лиц и контроль за ввозом и вывозом (выносом) материальных ценностей. – Принимать под охрану от материально ответственных лиц оборудованные сигнализацией обособленные помещения. Чтобы оставаться конкурентоспособным, а также увеличивать прибыль непосредственно за счет привлечения покупателей, уменьшения уровня расходов на потерю каких-то товаров из-за некачественного хранения, из-за сотрудничества с недоброжелательными поставщиками, для супермаркета необходима актуальная информация по спросу на определенную продукцию, оперативный анализ движения разного рода товаров поставщик-прилавок, контроль непосредственно за условиями хранения товаров на складе супермаркета, также объективный анализ поставщиков.

2.Обоснование средства проектирования

Access – функционально полная СУБД реляционных БД. Кроме того, Access является одной из наиболее мощных, гибких, а также простых в использовании системах. В ней можно также выполнять создание большинства программных приложений, не написав ни единой строки программы, когда нужно создать сложные и массивные приложения, то на тот случай в Access используется язык – VBA. Популярность СУБД обусловлена такими основными причинами:[6] – Access – одна с самых легкодоступных систем для профессионалов и начинающих, позволяющая быстро осваивать самые основные принципы в работе с БД; – система использует русифицированную версию; – идеологии Windows позволяют представить информацию наглядно; – непосредственная интегрированность с пакетами программ Office: Excel, Word, Mail; – возможность применения разных OLE технологии, что позволяет с легкостью установить связи с разными объектами иного приложения, а также внедрить другие объекты; – технология под названием WYSIWIG позволяет пользователям видеть результаты действий сразу перед собой; – наглядно и широко также представлена справочная система в рассматриваемой СУБД; – существует также широкий набор “мастеров” при разработке объектов. Рассмотрим положительные стороны СУБД Access: – низкий порог вхождения в разработку; – применения специальных подпрограмм-мастеров для создания объектов базы данных; – внедренный язык программирования VBA. К отрицательным сторонам можно отнести то, что СУБД не применяется для серверных задач, а также в веб-приложениях. Таблица – объект, что выполняет хранение данных в БД. Для каждой таблицы имеется первичный ключ, а также один или же несколько индексированных столбцов [15]. Access дает возможность создавать макеты таблиц в основных трех режимах: – с помощью конструктора – самый функциональный метод, который дает возможность гибкой настройки запроса в виде QBE или написание кода SQL; – с помощью мастера – последовательность шагов, выполнив которые пользователь придет к готовой таблице; –ввод данных вручную – структура таблицы создается вручную с помощью переименования пустого макета таблицы. Запрос – это элемент базы, который содержит инструкции SQL запроса и использует свое уникальное имя в базе. Запросы создаются такими основными способами: – мастером создания запросов; – конструктором запросов. В первом случае пользователям предлагается выбрать наименование таблиц, поля для выборки, указать групповые операции для вычисления итогов, провести сортировку. Во втором – можно выбирать несколько элементов БД сразу, связывать их, определить поля выборки. [13] Форма – элемент базы для компонентов пользовательского интерфейса: поля для ввода данных, переключатели, кнопки, выпадающие списки, группы радиокнопок и прочее. На форме разработчики с легкостью могут расположить все компоненты для навигации, выполнения корректировок, группировок, просмотра данных, вне зависимости от данных, которые нужно обрабатывать. [14] Форму создают такими методами: – при помощи конструктора создания форм; – с помощью мастера создания форм. Отчёты – элементы Access, предназначенные для вывода на экран информации, что впоследствии будет выводится на экран или печать. Такой документ часто содержит итоги по выборке, вычислительные поля, информацию о дате создания отчета, времени, количестве страниц и другую вспомогательную информацию. Для создания отчетов применяют 2 основных метода: – мастер создания отчетов; – создание отчета с помощью конструктора. Страница – это средство для выполнения публикации информации как по локальной сети, так и по сети Internet. AllFusion Process Modeller – это ведущий кроссплатформенный инструмент визуального моделирования бизнес процессов. Он имеет возможность наглядно представлять любую структуру или деятельность в виде модели, что в дальнейшем позволит оптимизировать работу отдела маркетинга, спроектировать его рациональную структуру, снизить издержки, повысить эффективность и гибкость, а также исключить ненужные операции. Данный программный продукт поддерживает IDEF0 методологию моделирования, позволяющая детально анализировать бизнес-процессы. В данной дипломной работе рассматривается моделирования с помощью методологии IDEF0. Это основная из 3 методологий AllFusion Process Modeller, относится к множеству IDEF, которое применялось еще в начале 70-х годов. Она используется для широкого класса систем, для указания функций, которые используются для последующей разработки системы, которая отвечает за реализацию поставленных функций. Рисунок 2 – Интерфейс AllFusion Process Modeller В результате применения данной методологи будет создана модель исследуемой системы, которая состоит из иерархически упорядоченного множества диаграмм, текста словарей и документации, связанных друг с другом при помощи перекрестных ссылок. Двумя самыми важными оставляющими, из которых строятся эти диаграммы, являются работы или бизнес-функции (представленные на диаграммах прямоугольниками) и данные или объекты (стрелки), связывающие между собой эти работы. При этом все стрелки, в зависимости от стороны прямоугольника, в который они входят или выходят, делятся на 4 вида: – стрелки входа – изображают объекты или данные, изменяемые в ходе работы. – стрелки управления (входят в верхнее ребро прямоугольника) — изображают ограничения и правила, согласно которым выполняется эта работа. – стрелки выхода из правой стороны прямоугольника — изображают объекты или данные, появляющиеся после выполнения работы. – стрелки механизмов (входят в нижнюю часть работы) – изображают ресурсы, которые необходимы для выполнения работы и не изменяющиеся в ее процессе (оборудование, сотрудники). Первая диаграмма в совокупности IDEF0 всегда изображает работу системы в целом. Эти диаграммы называются контекстными. В нее входит описание целей моделирования, области (что будет именно рассматриваться в качестве компонента системы, а что – внешнее воздействие) и точка зрения (позиции построения модели). После описания контекста, проводится построение других диаграмм в иерархии. Все последующие диаграммы являются более подробным описанием одной из работ на прежней диаграмме. Описание таких подсистем проводится аналитиком вместе с экспертом предметной области. Экспертом является человек, которые отвечает за эту подсистему, поэтому досконально знает все ее функции. В результате вся система разбивается на блоки (подсистемы) до нужного уровня разбиения, и получается модель, которая приближает систему с необходимым уровнем точности. Получив такую модель, адекватно отображающую бизнес-процессы (модель AS IS), аналитик легко может увидеть наиболее уязвимые места исследуемой системы.

3.Концептуальное проектирование

Концептуальное проектирование баз данных – это сбор, анализ, редактирование требований к имеющимся данным. Для выполнения проектирования данного вида осуществляются такие мероприятия: – исследование предметной области, а также изучение ее структуры; – выявление фрагментов, каждый из них характеризуется пользовательским представлением, а также информационными объектами, связями между ними и процессами над данными объектами; – интеграция и моделирование всех представлений. Существуют 2 основных подхода к выполнению проектирования систем баз данных: – восходящий; – нисходящий. При восходящем подходе все работа по проектированию начинается с нижнего уровня атрибутов (свойств сущностей, связей), что на основе анализа имеющихся между ними связей могут группироваться в отношения, которые представляют типы сущностей, а также связи между ними. К примеру, процесс нормализации представляет вариант восходящего подхода проектирования баз данных. Нормализация дает возможность идентификации требуемых атрибутов с дальнейшем созданием из них разных нормализованных таблиц, которые основаны на функциональных зависимостях для этих атрибутов. Восходящий подход приемлем в наибольшей степени для проектирования простых БД с небольшим количеством атрибутов. Но использование этого подхода усложняется при проектировании БД с большим количеством имеющихся атрибутов, установить все существующие функциональные зависимости среди которых довольно затруднительно. Изучив предметную область можно выделить следующие сущности и их атрибуты: – Единицы измерения: 1. Код единицы измерения; 2. Название единицы измерения. – Клиенты: 1. Код клиента; 2. ФИО клиента; 3. Адрес; 4. Телефон. – Сотрудник: 1. Код сотрудника; 2. ФИО сотрудника; 3. Адрес; 4. Телефон. – Товары: 1. Код товара; 2. Название; 3. Единица измерения; 4. Количество на складе; 5. Цена. – Продажа: 1. № п/п; 2. Дата отгрузки; 3. Товар; 4. Клиент; 5. Количество; 6. Ответственный; 7. Оплата. Выполним нормализацию отношений. Отношение находится в первой нормальной форме (1НФ), если значения атрибутов (то есть домены), из которых построено данное отношение, являются простыми, неделимыми, иначе говоря, атомарными значениями. Все отношения для рассматриваемой предметной области являются атомарными. Отношение находится во второй нормальной форме, если оно находится в первой нормальной форме и значения в каждом неключевом атрибуте однозначно определяются значением первичного ключа. Для каждого отношения создано ключевое поле (первые поля в перечне атрибутов). Отношение находится в третьей нормальной форме (3НФ) тогда и только тогда, когда отношение находится в 2НФ и все неключевые атрибуты взаимно независимы. В наших таблицах нет не ключевых полей, которые идентифицируются с помощью другого не ключевого поля. Следовательно, таблицы находятся в третьей нормальной форме.

4. Физическая модель и схема данных

Для создаваемой базы данных требуются следующие информационные объекты (таблицы): – Единицы измерения; – Клиенты; – Отгрузка; – Сотрудники; – Товары. После запуска СУБД и открытия конструктора таблиц, откроется окно в котором нужно указать название поля, тип данных, описание (если нужно), задать свойства полей, установить ключевое поле. Внешний вид окна конструктора таблицы Единицы измерения показан на рис. 3: Рисунок 3 – Таблица Единицы измерения в режиме конструктора Аналогичным образом создаются остальные таблицы (рисунки 4 – 7). Рисунок 4 – Таблица Клиенты в режиме конструктора Рисунок 5 – Таблица Сотрудники в режиме конструктора Рисунок 6 – Таблица Продажа в режиме конструктора Рисунок 7 – Таблица Товары в режиме конструктора После формирования структуры таблицы (наименований полей и определение их типов). Нужно определить ключевое поле. Поскольку в ключевом поле должны находится уникальные данные, то, например, для таблицы «Товары» им будет поле «Код товара». Для установки индексированного поля в разделе свойств нужно использовать пункт «Индексированное поле». Оно имеет 3 варианта значений: да (допускаются совпадения), нет, да (не допускаются совпадения). Рассмотрим процесс установки связей между таблицами. Для этого необходимо открыть окно «Схема данных», добавить все таблицы. После этого нужно перетащить определенные поля одно на другое. В результате этого откроется окно которое показано на рисунке 8: Рисунок 8 – Обеспечение целостности данных при связывании таблиц Поскольку не отображаются типы связей, то нужно дважды щелкнуть на линии соединения и задать следующие настройки: В результате выполнения данной процедуры для всех таблиц, получим следующую структуру (рис.9): Рисунок 9 – Схема данных В результате выполненных действий будет выполнена разработка физической модели БД супермаркета. Далее перейдем к непосредственной разработки функционала АИС супермаркета.

5.Описание функционала приложения

Для принятия каких-либо управленческих решений надо отобрать нужные данные с базы, провести некоторые вычисления или корректно и в удобном виде подать информацию. Для этого используются запросы. При некорректном подборе типов данных в таблицах или не правильном их объединении на схеме данных создать правильно функционирующий запрос не получится. Запрос Количество операций предназначен для вычисления количество операций, которые выполнены каждым с сотрудников. Код запроса имеет вид: SELECT Сотрудники.[ФИО сотрудника], Count(Отгрузка.Товар) AS [Count-Товар] FROM Сотрудники INNER JOIN Отгрузка ON Сотрудники.[Код сотрудника] = Отгрузка.Ответственный GROUP BY Сотрудники.[ФИО сотрудника]; Результат запроса показан на рисунке 10: Рисунок 10 – Запрос Количество операций Запрос Стоимость проданной продукции предназначен для вычисления общей стоимости отгруженной продукции: SELECT Товары.Название, Sum([Товары]![Цена]*[Отгрузка]![Количество]) AS Стоимость FROM Товары INNER JOIN Отгрузка ON Товары.[Код товара] = Отгрузка.Товар GROUP BY Товары.Название; На рисунке 11 показан результат запроса: Рисунок 11 – Запрос Стоимость отгруженной продукции Запрос Обновление стоимости предназначен для увеличения стоимости продукции: UPDATE Товары SET Товары.Цена = [Цена]*1.1; Запрос Удаление клиента выполняет удаление клиента с базы данных: DELETE Клиенты.[ФИО клиента] FROM Клиенты WHERE (((Клиенты.[ФИО клиента])=[Введите ФИО клиента])); Запрос Продажа товаров предназначен для отображения информации по работе компании: TRANSFORM Sum([Товары]![Цена]*[Отгрузка]![Количество]) AS Выражение1 SELECT Клиенты.[ФИО клиента] FROM Товары INNER JOIN (Клиенты INNER JOIN Отгрузка ON Клиенты.[Код клиента] = Отгрузка.Клиент) ON Товары.[Код товара] = Отгрузка.Товар GROUP BY Клиенты.[ФИО клиента] PIVOT Товары.Название; На рисунке 12 показан результат запроса: Рисунок 12 – Запрос Продажа товаров Формы – элемент базы данных для удобного отображения или ввода данных. Стоит отметить, что формы бывают одиночные (на основе одной таблицы) и составные или сложные (на основании нескольких таблиц. Также выделяют подчиненные формы – это многотабличные формы, которые созданы на основании таблиц, которые объединены связью «один – ко — многим». Некоторые из созданных форм показаны на рисунках 13 – 16: Рисунок 13 – Форма Клиенты Рисунок 14 – Форма Продажа Рисунок 15 – Форма Товары Рисунок 16 – Форма Сотрудники В базах данных при необходимости создаются отчеты – элементы базы данных для удобного вывода полученной информации на печать. На рисунках 17 – 18 показаны некоторые отчеты: Рисунок 17 – Отчет Продажа товаров Рисунок 17 – Отчет Количество операций Для навигации по БД используется кнопочная форма, внешний вид которой показан на рисунке 18: Рисунок 18 – Кнопочная форма В результате выполненных действий формируется БД по деятельности супермаркета.

Заключение

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

Список использованных литературных источников

1. Голицына О.Л. Базы данных/О.Л. Голицына, Н.В.Максимов, –И.И.Попов. — М.:Форум, 2014. 352 c. 2. Голицына О.Л. Базы данных: Учебное пособие/О.Л.Голицына, Н.В.Максимов, И.И.Попов. — М.:Форум, 2014.– 400 c. 3. Грэй П. Логика, алгебра и базы данных / П. Грэй. — М.: Машиностроение, 2015. — 368 c. 4. Информатика: Учебник /Под редакцией В.М. Мартю. – 2015/–880с. 5. Карпова И.П. Базы данных:Учебное пособие /И.П. Карпова. — СПб.:Питер, 2013.– 240 c. 6. Кириллов В.В. Введение в реляционные базы данных./В.В. Кириллов, Г.Ю.Громов.–СПб.: БХВ-Петербург, 2016.–464 c. 7. Кошелев В.Е. Базы данных в ACCESS 2007: Эффективное использование /В.Е. Кошелев.–М.: Бином-Пресс, 2014.–592 c. 8. Кузин А.В. Базы данных:Учебное пособие для студентов высш. учеб. заведений /А.В. Кузин, С.В. Левонисова.– М.: ИЦ Академия, 2015.–320 c. 9. Ливена С.В. Проектирование баз данных/С.В. Ливена.–М.: ИНФРА-М, 2013.–51 c. 10. Ульман Дж. Базы данных/ Дж. Ульман. — М.: Машиностроение, 2017. — 368 c. 11. Ульман Дж. Основы систем баз данных / Дж. Ульман. — М.: Финансы и статистика, 2017. — 292 c. 12. Ракован О.Л. Базы данных / О.Л. Ракован – М.:Форум, 2014. – 352 c. 13. Ракован О.Л.Базы данных: Учебное пособие/О.Л. Ракован. — М.:Форум, 2012.–400 c. 14. Симонова В.А. Проектирование баз данных в СУБД MySQL: Учебное пособие.–М.: ИД. «Форум»: ИНФРА–М. 2012–160с. 15. Титова В.М., Информатика для экономистов: учебник /В.М. Титова.–М.: ИД. «Форум»:ИНФРА–М. 2013–448с.