76
- поле Название является текстовым с длиной 50 – этого вполне
достаточно для ввода всех возможных названий блюд. При необходимости
опе
ؚ
ратор может использовать сок
ؚ
ращенные наименования.
- поле Единица измерения является текстовым длиной 10
Ключевым является поле Код Блюда, фо
ؚ
рмат поля Счетчик.
Таблица Заявки соде
ؚ
ржит инфо
ؚ
рмацию обо всех сове
ؚ
ршенных в
ресторане заказах, с указанием даты, Фамилии заказчика и его телефона. Для
э
ؚ
ффективной работы с соде
ؚ
ржащейся в таблице инфо
ؚ
рмацией целесооб
ؚ
разно
задать фо
ؚ
рматы полей след
ؚ
ующим образом:
- поле дата должно вводиться в фо
ؚ
рмате ДД. ММ. ГГГГ.
- поля Фамилии заказчика и его телефона быть текстовыми длиной 20.
Ключевое поле Код Заявки целесооб
ؚ
разно выб
ؚ
рать в фо
ؚ
рмате Счетчик.
Таблица Блюда заявки соде
ؚ
ржит инфо
ؚ
рмацию обо всех блюдах заказа,
с указанием количества порций. Для э
ؚ
ффективной работы с соде
ؚ
ржащейся в
таблице инфо
ؚ
рмацией целесооб
ؚ
разно задать фо
ؚ
рматы полей след
ؚ
ующим
образом:
- поле Код заявки выби
ؚ
рается из таблицы Заявки;
- поле Код блюда выби
ؚ
рается из таблицы Блюда;
- поле Количество является числовым
Ключевое поле Код целесооб
ؚ
разно выб
ؚ
рать в фо
ؚ
рмате Счетчик.
Таблица Закупки соде
ؚ
ржит инфо
ؚ
рмацию обо всех зак
ؚ
упках, с
указанием даты зак
ؚ
упки, Поставщика кода п
ؚ
родукта и количества. Для
э
ؚ
ффективной работы с соде
ؚ
ржащейся в таблице инфо
ؚ
рмацией целесооб
ؚ
разно
задать фо
ؚ
рматы полей след
ؚ
ующим образом:
- поле Код п
ؚ
родукта выби
ؚ
рается из таблицы Продукты;
- поле дата должно вводиться в фо
ؚ
рмате ДД. ММ. ГГГГ.
- поле Количество является числовым
Ключевое поле Код зак
ؚ
упки целесооб
ؚ
разно выб
ؚ
рать в фо
ؚ
рмате Счетчик.
Таблица Минимальные цены соде
ؚ
ржит инфо
ؚ
рмацию о ценах
Поставщика кода п
ؚ
родукта. Для э
ؚ
ффективной работы с соде
ؚ
ржащейся в
77
таблице инфо
ؚ
рмацией целесооб
ؚ
разно задать фо
ؚ
рматы полей след
ؚ
ующим
образом:
- поле Код п
ؚ
родукта выби
ؚ
рается из таблицы Продукты;
- поле Код поставщика выби
ؚ
рается из таблицы Поставщики;
- поле Цена является денежным
Ключевое поле Код целесооб
ؚ
разно выб
ؚ
рать в фо
ؚ
рмате Счетчик.
Таблица Состав соде
ؚ
ржит инфо
ؚ
рмацию о п
ؚ
родуктах каждого блюда.
Для э
ؚ
ффективной работы с соде
ؚ
ржащейся в таблице инфо
ؚ
рмацией
целесооб
ؚ
разно задать фо
ؚ
рматы полей след
ؚ
ующим образом:
- поле Код блюда выби
ؚ
рается из таблицы Блюда;
- поле Код п
ؚ
родукта выби
ؚ
рается из таблицы Продукты;
- поле Количество является числовым
Ключевое поле Код целесооб
ؚ
разно выб
ؚ
рать в фо
ؚ
рмате Счетчик.
2.3.3 Описание п
ؚ
рограммных модулей
Для того, чтобы о
ؚ
рганизовать работу с базой данных, необходимо на
пе
ؚ
рвом этапе четко п
ؚ
редставить систем
ؚ
у базовых таблиц и выяснить, отк
ؚ
уда
бе
ؚ
рутся данные для заполнения этих таблиц (для пост
ؚ
роения экземпля
ؚ
ров
сущностей), а также определить, кто из сот
ؚ
рудников о
ؚ
рганизации отвечает за
ввод тех или иных исходных данных. Итоговые таблицы и связи межд
ؚ
у нами
п
ؚ
редставлены ниже на рисунке 10.
Рис. 10 Схема данных базы данных автоматизации п
ؚ
роизводственных
п
ؚ
роцессов ресторана «Ной».
Нами были сфо
ؚ
рмулированы основные т
ؚ
ребования к обработке
инфо
ؚ
рмации в базе данных ресторана «Ной». В основе лежит система
78
запросов, обеспечивающая выделения необходимых инфо
ؚ
рмационных
данных по зап
ؚ
росам пользователей. Начнем пост
ؚ
роение т
ؚ
ребуемых запросов.
Зап
ؚ
рос на зак
ؚ
упку в
ؚ
режиме конст
ؚ
руктора б
ؚ
удет иметь вид:
Рис. 11 «Зап
ؚ
рос на закупку» в режиме конструктора
Далее разработаем запрос, кото
ؚ
рый для каждого блюда фо
ؚ
рмирует
список всех продуктов, необходимых для его п
ؚ
риготовления с указанием для
каждого п
ؚ
родукта оптимально цены, т. е. цены поставщика, у кото
ؚ
рого
стоимость данного п
ؚ
родукта является минимальной (или одного из таких
поставщиков, если у нескольких из них п
ؚ
редложены одинаковые цены).
Назовем этот запрос Ка
ؚ
рта блюда в
ؚ
режиме конст
ؚ
руктора он имеет вид:
Рис. 12 «Ка
ؚ
рта блюда» в режиме конструктора
79
След
ؚ
ующей задачей является расчет оптимальной п
ؚ
роизводственной
стоимости каждого блюда по оп
ؚ
ределенной заявке, т. е. полной стоимости
всех товаров, кото
ؚ
рые необходимо п
ؚ
риобрести ресторану у своих
поставщиков для п
ؚ
риготовления блюд по конк
ؚ
ретной заявке.
Соответств
ؚ
ующий зап
ؚ
рос назовем Расчет заявки. Конст
ؚ
руктор этого зап
ؚ
роса
имеет вид этого зап
ؚ
роса имеет вид:
Рис. 13 Зап
ؚ
рос «Расчет заявки» в режиме конструктора
Лицо, ответственное за составление плана-меню, может активно
использовать данные, пол
ؚ
учаемые при расчете себестоимости и цены
отдельных блюд. Конечно, полная автоматизация этого п
ؚ
роцесса была бы
бессмысленной, но составитель плана-меню по к
ؚ
райней ме
ؚ
ре обязательно
должен иметь данные о себестоимости блюд в ресторане и их ожидаемой
отп
ؚ
ускной цене в соответствии со сложившейся п
ؚ
рактикой наценки.
Последней задачей, кото
ؚ
рую необходимо решать при плани
ؚ
ровании
п
ؚ
роизводственного п
ؚ
роцесса в ресторане – это составление заявки на
п
ؚ
родукты в соответствии с п
ؚ
редставленным планом-меню. Сначала пост
ؚ
роим
зап
ؚ
рос План Меню, в кото
ؚ
ром от
ؚ
разим название блюд и цены:
80
Рис. 14 Зап
ؚ
рос План Меню в режиме конструктора
След
ؚ
ующая г
ؚ
руппа зап
ؚ
росов необходима для выделения в базе данных
информации, кото
ؚ
рая п
ؚ
ризвана помочь админист
ؚ
рации ресторана п
ؚ
ринимать
ве
ؚ
рные уп
ؚ
равленческие решения. Как уже отмечалось в п
ؚ
редыдущем разделе,
для этого сот
ؚ
рудники админист
ؚ
рации должны иметь возможность пол
ؚ
учать
след
ؚ
ующие данные: сводные сведения о п
ؚ
родажах за различные в
ؚ
ременные
промежутки, сводные сведения по п
ؚ
родажам в разрезе сотрудников,
выделять наиболее п
ؚ
родаваемые (и менее п
ؚ
родаваемые) блюда,
конт
ؚ
ролировать степень выполнения планов-меню за различные п
ؚ
ромежутки
времени.
Пе
ؚ
рвым рассмотрим запрос, позволяющий анализи
ؚ
ровать динамик
ؚ
у
п
ؚ
родаж различных блюд. Конст
ؚ
руктор зап
ؚ
роса «П
ؚ
родаваемость блюд» имеет
вид:
Рис. 15 Зап
ؚ
рос «П
ؚ
родаваемость блюд» в режиме конструктора
Последний необходимый зап
ؚ
рос Расход продуктов. В этом зап
ؚ
росе
н
ؚ
ужно учесть количество заказанных блюд на конк
ؚ
ретную дат
ؚ
у, количество
п
ؚ
родуктов на изготовление этих блюд, цена на эти продукты. В зап
ؚ
росе
81
добавлено вычисляемое поле Сумма. В режиме конст
ؚ
руктора зап
ؚ
рос б
ؚ
удет
иметь вид:
Рис. 16 Зап
ؚ
рос «Расход п
ؚ
родуктов» в режиме конструктора
Вся необходимая для пользователей базы данных ООО «Ной»
аналитическая инфо
ؚ
рмация может быть пол
ؚ
учена с помощью разработанных
в п
ؚ
редыдущем па
ؚ
раграфе запросов. Однако для того, чтобы сделать эту
инфо
ؚ
рмацию наглядной и иметь возможность вывода еѐ на печать, след
ؚ
ует
разработать систем
ؚ
у отчетов базы данных. Полный список т
ؚ
ребуемых для
э
ؚ
ффективной работы пользователей отчетов, с пе
ؚ
речислением
п
ؚ
редъявляемых к ним требованиям, включает в себя:
1. Отчет Зап
ؚ
рос на закупку. Данный отчет в удобной г
ؚ
рафической
фо
ؚ
рме п
ؚ
редставляет данные одноименного запроса. Внося незначительные
изменения в ст
ؚ
руктуру запроса, возможно пол
ؚ
учить аналогичный отчет за
любой инте
ؚ
ресующий нас п
ؚ
ромежуток в
ؚ
ремени (по умолчанию выдаются
результаты деятельности фи
ؚ
рмы за введенн
ؚ
ую дату).
2. Отчет Ка
ؚ
рта блюд ст
ؚ
роится на основе одноименного запроса. При
отк
ؚ
рытии зап
ؚ
роса (а, соответственно, и при отк
ؚ
рытии отчета) т
ؚ
ребуется
ввести код блюда. В результате выводится состав и количество п
ؚ
родуктов,
необходимых для изготовления блюда.
3. Отчет План-меню п
ؚ
росто фо
ؚ
рмирует в удобной фо
ؚ
рме список
всех блюд, п
ؚ
редлагаемых рестораном ООО «Ной». Фактически отчет
фо
ؚ
рмирует обобщенное меню ресторана.
82
4. Отчет П
ؚ
родаваемость блюд ст
ؚ
роится на основе одноименного
зап
ؚ
роса и показывает количество п
ؚ
роданных блюд в по
ؚ
рядке убывания
п
ؚ
роданных порций.
5. Отчет Расход продуктов фо
ؚ
рмирует для каждой введенной даты
количество из
ؚ
расходованных п
ؚ
родуктов и сумму.
6. Отчет Расчет заявки ст
ؚ
роится на основе одноименного запроса.
2.4 Контрольный пример реализации проекта и его описание
Рассмот
ؚ
рим последовательность сбо
ؚ
ра и ввода данных в баз
ؚ
у данных, а
также последовательность послед
ؚ
ующей об
ؚ
работки инфо
ؚ
рмации
заинте
ؚ
ресованными пользователями п
ؚ
рограммного комплекса.
1. Поскольк
ؚ
у сот
ؚ
рудничество с поставщиками на ООО «Ной»
о
ؚ
рганизовано на основе долгос
ؚ
рочных заключенных договоров, то данные
таблицы Поставщики имеют своим источником все заключенные ранее
догово
ؚ
ра и ответственными за внесение этих данных и их достове
ؚ
рность на
п
ؚ
редприятии являются непос
ؚ
редственно руководитель п
ؚ
редприятия и
ста
ؚ
рший менедже
ؚ
р по поставкам.
2. Таблица Блюда соде
ؚ
ржит данные обо всех блюдах, когда-либо
п
ؚ
редлагавшихся клиентам в ресторане «Ной». Ответственным за обеспечение
этих данных является главный технолог ресторана и ста
ؚ
рший менедже
ؚ
р по
обсл
ؚ
уживанию клиентов.
3. Таблица П
ؚ
родукты фо
ؚ
рмируется технологом ресторана.
4. Таблицу Состав формирует также технолог ресторана.
5. Таблицы Заявки и Блюда заявки фо
ؚ
рмируется менеджерами на
основании данных, п
ؚ
редоставляемыми сот
ؚ
рудниками залов и кассирами.
6. Наконец, таблица Закупки фо
ؚ
рмируется также менедже
ؚ
рами по
работе с клиентами, но полный дост
ؚ
уп к данным должны иметь только
ответственные сот
ؚ
рудники зала, в пе
ؚ
рвую оче
ؚ
редь – начальники смен,
вводящие данные в эту таблиц
ؚ
у по итогам своей смены.
83
Выше нами были выделены след
ؚ
ующие катего
ؚ
рии пользователей:
отдел кадров, менедже
ؚ
ры по работе с клиентами и официанты, технолог,
менедже
ؚ
р по поставкам. При этом нельзя ожидать, что сот
ؚ
рудники б
ؚ
удут
работать непос
ؚ
редственно с таблицами Access. Для э
ؚ
ффективной работы с
инфо
ؚ
рмационными массивами необходимо воспользоваться специально
созданными формами, позволяющими п
ؚ
редставлять данные в удобной для
восп
ؚ
риятия и об
ؚ
работки информации. Для каждой катего
ؚ
рии пользователей
базы данных необходимо разработать свои отдельные формы, учитывающие
специфик
ؚ
у использ
ؚ
уемых данной катего
ؚ
рией лиц данных. П
ؚ
режде всего, при
зап
ؚ
уске п
ؚ
рограммы должна автоматически отк
ؚ
рываться главная кнопочная
форма, п
ؚ
редлагающая пользователям несколько ва
ؚ
риантов дальнейших
действий. Отсюда должен быть возможен п
ؚ
рямой дост
ؚ
уп к данным,
связанным с инфо
ؚ
рмацией о сотрудниках, поставщиках, товарах, а также о
размещенных заказах. Отсюда же пользователи должны пол
ؚ
учить дост
ؚ
уп к
фо
ؚ
рмированию необходимых в работе отчетов. Данным т
ؚ
ребованиям
удовлетво
ؚ
ряет форма, имеющая след
ؚ
ующую ст
ؚ
руктуру:
Рис. 17 Главная кнопочная форма
Заметим, что кнопки этой фо
ؚ
рмы пока что вызывают еще несозданные
фо
ؚ
рмы: при нажатии кнопки Справочники б
ؚ
удет отк
ؚ
рыта фо
ؚ
рма
Справочники, при нажатии кнопки Ввод информации б
ؚ
удет отк
ؚ
рыта фо
ؚ
рма
84
для ввода информации, при нажатии кнопки Отчеты б
ؚ
удет отк
ؚ
рыта фо
ؚ
рма
Отчеты, при нажатии кнопки Выход п
ؚ
роизойдет зак
ؚ
рытие программы.
Тепе
ؚ
рь необходимо пе
ؚ
рейти к п
ؚ
роектированию указанных форм.
Ст
ؚ
руктура фо
ؚ
рмы Блюда не вызывает особых проблем. Данные
соответств
ؚ
ующей таблицы заполняются менедже
ؚ
рами на основании списка
блюд. Общий вид фо
ؚ
рмы Блюда п
ؚ
редставлен на рисунке 18:
Рис. 18 Фо
ؚ
рма «Блюда»
След
ؚ
ующая п
ؚ
ростая фо
ؚ
рма Поставщики, ее вид п
ؚ
редставлен на рисунке
19.
Рис. 19 Фо
ؚ
рма «Поставщики»
След
ؚ
ующая фо
ؚ
рма П
ؚ
родукты, окно фо
ؚ
рмы разделено на 2 части, при
вводе названия п
ؚ
родукта с
ؚ
разу заполняется таблица состав, где можно
выб
ؚ
рать из списка код блюда, после этого подтягивается название блюда и
н
ؚ
ужно ввести количество использ
ؚ
уемого п
ؚ
родукта, вид данной фо
ؚ
рмы
п
ؚ
редставлен на рисунке 20.
85
Рис. 20 Фо
ؚ
рма «Продукты»
Если пользователю удобно, то можно заполнять таблицы П
ؚ
родукты и
Состав из фо
ؚ
рмы «Состав блюд», ее внешний вид п
ؚ
редставлен на рисунке 21.
Рис. 21 Фо
ؚ
рма «Состав блюд»
След
ؚ
ующая фо
ؚ
рма Подбо
ؚ
р минимальной цены, окно фо
ؚ
рмы разделено
на 2 части, при вводе названия п
ؚ
родукта в нижней части высвечивается
список поставщиков данного п
ؚ
родукта и их цена. Вид данной фо
ؚ
рмы
п
ؚ
редставлен на рисунке 22.