36
Рисунок2.11 – Раскрытие диаграммы «Заказ пищи»
Рисунок2.12 – Раскрытие диаграммы «Приготовление пищи»
37
Рисунок2.13 – Раскрытие диаграммы «Продажа заказа»
Если сформирован запрос и выполнены задачи, формируются новые
пункты меню и слайдов таблиц для дальнейшей работы.
Успех работы предприятия напрямую зависит от работы отдела продаж
которое состоит из специалистов менеджеров и меркетологов, поэтому
автоматизация данного подразделения крайне необходима.
38
III. ОБОСНОВАНИЕ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ
ПРОЕКТА
3.1 Разработка проекта автоматизации и эффективности проекта
3.1.1Обоснование выбора программных и технических средств
3.1.1.1 Модель взаимодействия
Во взаимодействии в соответствии с рисунком 3.1 участвуют следующие
сущности, Клиент, Оператор, Администратор и само электронное табло.
Приблизительная модель взаимодействия имеет вид:
Рисунок 3.1– Структурная схема взаимодействия
3.1.1.2 Программный алгоритм работы информационных терминалов
Ниже приведено описание сущностей, входящих в состав модели данных
проектируемого программного обеспечения в соответствии с рисунком 3.2.
Сущность «Блюда» описывает данные о возможности заказа:
– название;
– категория;
– текущая стоимость;
– единицы измерения порции;
– количество меры в порции;
– картинки.
39
Алгоритм полного взаимодействия отображен на рисунке:
Рисунок 3.2– Инфологическая модель системы
40
Сущность «Еда» описывает сам заказ, характеризуется следующими
атрибутами:
– название блюда;
– название категории;
–вес/объем;
–белки;
–жиры;
–углеводы;
– Ккал;
–картинка.
Сущность «Корзина» описывает общее название блюд, характеризуется
следующими атрибутами:
– блюдо;
– актуальная цена;
– количество порций;
– клиент;
– номер сессии.
Сущность «Заказ» описывает общее название блюд, характеризуется
следующими атрибутами
– блюдо;
– актуальная цена;
– количество порций;
– общая цена;
– дата заказа;
– время на которое заказано;
– клиент.
Сущность «Категории» описывает общее название блюд, характеризуется
следующими атрибутами:
– название категории.
Сущность «Меню» описывает общее название блюд, характеризуется
следующими атрибутами:
– название блюда;
41
– название категории:
– дата;
– цена;
– является ли акционным.
Сущность «Отдел» описывает отдел его расположение в строительной
организации и режим доступа, характеризуется следующими атрибутами:
– название отдела;
– расположение;
– телефон;
– режим доступа;
– начальник.
Сущность «Сотрудники» описывает пользователя использующего модуль,
характеризуется следующими атрибутами:
– фамилия;
– имя;
– отчество;
– отдел;
– права в системе;
– контактный телефон;
– мобильный телефон;
– комментарии;
– дата регистрации;
– прописка;
– имя пользователя;
– пароль.
Сущность «Картинки» используется только для оптимизации кода, так как
изображения могут периодически повторяться.
3.1.1.3 Необходимый перечень специалистов обслуживания
информационной системы
Администратор-это тот, кому доступны все разделы, он может
настраивать отображение полей, страниц и прочего. Его роль понятна.
42
Повар - это тот, кто заполняет информацию про текущие блюда и при
необходимости информирует клиента что блюда готово или % его готовки. В
начале рабочего дня составляет меню и передает экономисту.
Экономист - это тот, кто формирует цены и при необходимости акции,
заполняет базу.
Последовательность действий выглядит следующей:
– повар формирует меню на основании имеющихся на складе продуктов;
– экономист формирует цены, занимается маркетинговыми
исследованиями и формирует акции;
– клиент формирует заказ;
– повар готовит необходимое количество заказов;
– повар информирует о готовности;
– ответственный сотрудник собирает заказы;
– ответственный сотрудник отправляет по подразделениям;
– клиент (сотрудник) забирает свой заказ.
В результате этого формируется база данных и автоматизированное
заполнение типичных форм.
3.1.2 Описание программных средств
3.1.2.1 Реляционная модель базы данных
Традиционный подход в процессе построения информационных систем
сводится к определению данных с двух различных точек зрения – точкизрения
пользователя иточкизрения компьютера. С точкизрения пользователя,
определение данных представляется в контексте отчетов, выборок. Их
структуразависит от сферы деятельности, особенностей восприятия
сущностипользователем ит.д. Этот подход позволяет хранить набор
шифрованных данных, имеющих определенную структуру. Данные хранятся в
файлах в виде записииполя илив виде списка. Ноприхраненииданных в виде
файланеобходимосоздать некоторую модель, описать ее, установить связиит.д.
Существует итретий подход к определению данных с точкизрения
информационной структуры, называемой концептуальной схемой. Такое
определение сводится:
43
– к единому определению данных в рамках выбранной предметной
области;
– к независящему от того, как физическиосуществляется хранение
идоступ к данным;
– к независимой ориентации накакое-либоконкретное использование.
Наданном этапе определения данных выбираются информационные
объекты иописываются их характеристики, выявляются связимежду объектами.
Наоснове концептуальной схемы строится концептуальная модель
выбранной предметной области. Концептуальная модель является
представлением точки зрения пользователя напредметную область ине зависит
ниот программногообеспечения СУБД, ниот техническогорешения. Кроме того,
онаобладает тремя важнымисвойствами:
1. согласованас инфраструктурой предметной области;
2. стабильна, приее расширенииновые данные определяются без
изменения ранее определенных;
3. адаптируемая с точкизрения пользователя и структуры хранения
данных.
Необходимость определения данных с концептуальной точкизрения
подводит к новой методологиимоделирования данных, основанной на трактовке
данных в контексте их взаимодействия с другимиданными.
3.1.2.2 Преобразование информации
Логическая модель описывает понятия предметной области, их
взаимосвязь, а также ограничения на данные, налагаемые предметной областью.
Логическая модель данных является начальным прототипом будущей
базы данных. Логическая модель строится в терминах информационных единиц,
но без привязки к конкретной СУБД. Более того, логическая модель данных
необязательно должна быть выражена средствами именно реляционной модели
данных. Основным средством разработки логической модели данных в
настоящий момент являются различные варианты ER-диаграмм.
Существует три вида связей между таблицами. Вид создаваемой связи
зависит от того, как заданы связанные столбцы.
44
Связь "один ко многим" - наиболее распространенный вид связи. При
такой связи каждой строке таблицы может соответствовать множество строк
другой таблицы
Связь "один ко многим" создается в том случае, когда только на один из
связываемых столбцов наложено ограничение уникальности или он является
первичным ключом.
Связи "многие ко многим"
При установлении связи "многие ко многим" каждой строке
таблицыможет соответствовать множество строк другой таблицы и наоборот.
Такая связь создается при помощи третьей таблицы, называемой
соединительной, первичный ключ которой состоит из внешних ключей.
Связи "один к одному"
При установлении связи "один к одному" каждой строке таблицыможет
соответствовать только одна строка другой таблицы и наоборот. Связь "один к
одному" создается в том случае, когда оба связанные столбца являются
первичными ключами или на них наложены ограничения уникальности.
Перечень реляционных таблиц базы данных представлен в таблице 3.1
Таблица 3.1
Общий перечень таблиц
Название таблицы
Описание
Food
Наименование продукции
Category
Название категории
Menu
Меню
Cart
Корзина заказов
Sales
Продажи
Settings
Настройки
Collection
Графические элементы
rights
Права в системе
Users
Пользователи
Depart
Отделы
45
Каждая из этих таблиц должна иметь свою уникальную структуру, чтобы
была возможность свести к минимуму дублирующуюся информацию, а так же
охватывала всевозможную информацию касательно микроконтроллеров.
Описание таблиц представлено в таблицах.
Некоторые таблицы, например «Меню» одержит огромное количество
ссылок на другие таблицы, содержимое значений столбцов которых может быть
идентичным. По отношению к данной таблице применима связь «многие ко
многим», т.е. каждому новому значению содержимого таблицы присваивается
множество значений, которым свойственно повторятся.
Реализация базы данных осуществляется за счет использования написания
сложных структурированных запросов на основе созданных ранее алгоритмах и
прецедентах.MуSQL имеет встроенный консоль редактора команд, где
необходимо выполнить предварительную работу создания таблиц, после чего
возможно проводить вставки и выборки данных[18].
Индексация таблиц и определение ключей играет немаловажную роль в
проектировании баз данных. Это позволяет не только ограничить избыточность
базы данных дублирующейся информации, но и увеличить скорость выполнения
запросов. Как правило, первичным ключом называют столбец, значение
которого является уникальным и обладает минимальным количеством
информации. Чаще всего этим столбцом является индивидуальный номер
записи[14].
Для написания структурированных запросов используется следующий
перечень универсальных стандартизированных команд:
– create table;
– select;
– insert;
– update;
– delete;
Команда «createtable» служит для создания таблиц и описания их
структуры. Синтаксисэтойкомандыявляетсяследующим:
CREATE TABLE
[ database_name . [ schema_name ] . | schema_name . ] table_name