63
обладающий индивидуальностью, и, следовательно не существующий
экземпляр стержневой сущности. По тем же причинам необходимо
обеспечить уникальность первичного ключа.
Теперь о внешних ключах:
- Если сущность С связывает сущности А и В, то она должна включать
внешние ключи, соответствующие первичным ключам сущностей А и В.
- Если сущность В обозначает сущность А, то она должна включать
внешний ключ, соответствующий первичному ключу сущности А.
В построенных выше стержневых сущностях выделены атрибуты,
описывающие внешние ключи. Очевидно, что ни один из них не может
принимать неопределенное значение, являясь фактически номером
соответствующего экземпляра сущности.
Таким образом, соблюдены все требования, предъявляемые к
первичным ключам сущности и к их внешним ключам.
2.2.2 Характеристика нормативно-справочной, входной и
оперативной информации
В программном комплексе автоматизации производственных
процессов ресторана «Альянс» используется справочно-нормативнная и
входная информация, на основании которых заинтересованные пользователи
получают информационные результатные блоки.
К справочно-нормативной информации комплекса следует отнести те
данные, которые составляют основу информационной системы ресторана и
мало подвержены изменениям с течением времени. К таким
информационным блокам первую очередь относятся:
- сведения о поставщиках, содержащиеся в таблице Поставщики
- сведения о блюдах, составляющих ресторанное меню. Данные о
блюдах собраны в две таблицы – Блюда и Состав.
Для просмотра и редактирования справочно-нормативной информации
в программном комплексе должны быть предусмотрены формы,
64
отображающие данные от сотрудниках, поставщиках и о блюдах. Доступ к
этим формам должен быть организован из главной формы программного
комплекса прямыми ссылками.
Помимо справочной информации, программный комплекс должен
работать с оперативной входной информацией, основу которой составляют
данные о поступлении и выполнении заказов посетителей ресторана. Данные
об оперативной работе ресторана собираются с использованием таблиц базы
данных Заказы, Обслуживание, Заказано. Доступ к формам, обеспечивающих
внесение данных в эти таблицы, также должен осуществляться из главной
формы программного комплекса.
2.2.3 Характеристика результатной информации
На основании оперативной и справочной информации фактически и
должна осуществляться содержательная обработка информационных данных
в проектируемом программном комплексе. При этом следует учесть
потребности всех потенциальных пользователей программного комплекса.
Особую важность анализ данных имеет для администрации, поскольку
должен позволить проводить текущий и стратегические (долгосрочный)
анализ продаж в разрезе клиентов ресторана, поставщиков продукции, а
также и сотрудников, выполняющих работы по обслуживанию заказов.
Именно, к системе аналитической обработки данных предъявляются
следующие требования:
1. Программа должна позволять формировать полный список всех
блюд, которые в настоящий момент могут быть предложены рестораном, с
указанием их основных признаков и с расчетом себестоимости при условии
закупа продуктов у тех поставщиков, которые уже задействованы в базе
данных, а также с указанием их ожидаемой реализационной цены при
использовании наценки из таблицы Блюда.
2. Программа должна формировать список всех необходимых для
организации производственного процесса продуктов. По плану-меню на
65
отчетную дату программа должна автоматически формировать список
продуктов, которые необходимо закупить у поставщиков на отчетную дату.
При этом выбор поставщика для каждой товарной позиции должен
выполняться автоматически с учетом минимизации закупочных цен на
товары.
3. Программа должна формировать полный отчет об имеющихся
заказах с указанием их текущих параметров: даты размещения заказа,
выбранных в заказе блюд, об обслуживании заказа сотрудником ресторана.
4. Возможность формирования списка всех заказов за
интересующий год (или другой временной промежуток) с указанием даты
размещения, стоимости заказа, его кода.
5. Возможность сформировать сведения обо всех заказах,
размещенных в прошлом году с указанием всех существенных атрибутов
заказа.
6. Возможность формирования списка всех блюд ресторана с ценой,
выше средней.
7. Возможность выделения данных, необходимых для
формировании впоследствии для каждого заказа, счета, выставляемого
клиенту.
8. Для анализа логистической структуры поставок администрации
ресторана необходимо иметь возможность объединения в одном документе
данных по поставщикам.
9. Наконец, необходимо иметь возможность анализа имеющихся
данных о продажах по кварталам.
2.3 Программное обеспечение задачи
2.3.1 Общие положения (дерево функций и сценарий диалога)
В разработанном модуле предусмотрен только один пользователь –
менеджер. Управление программой происходит посредством выбора пункта
66
меню или подменю, каждому пункту меню соответствует индивидуальная
функция. Дерево функций модуля представлено на рисунке 8.
Рис. 8 Дерево функций менеджера
Дерево функций менеджера ООО «Альянс» состоит из двух частей:
основные функции и служебные функции.
На основании дерева функций разработан сценарий диалога,
схематически представленный на рисунке 9.
Рис. 9 Сценарий диалога
Функции менеджера
Основные
Служебные
Получение
отчетных
документов
Учет заявок
Учет закупок
Заполнение
справочников
Главное меню
1. Справочники
2. Ввод информации
3. Отчеты
4. Выход
Справочники
1. Блюда
2. Поставщики
3. Продукты
4. Выход
Ввод информации
1. Оформление заявки
2. Подбор поставщика
3. Состав блюд
4. Выход
Отчеты
1. Запрос на закупку
2. Карта блюда
3. Меню
4. Расчет заявки
5. Расход продуктов
6. Продаваемость блюд
7. Выход
67
Сценарий диалога менеджера с системой представлен в виде форм и
их основных функций. Сценарий содержит логику действий, в соответствии с
которой происходит взаимодействие с БД и осуществляются подсказки
менеджеру.
2.3.2 Характеристика базы данных
Выбрав реляционный подход к разработке базы данных, мы
фактически приняли решение использовать для описания сущностей таблицы
данных, удовлетворяющие некоторым естественным внешним ограничениям:
1. Каждая таблица состоит из однотипных строк и имеет уникальное
имя.
2. Строки имеют фиксированное число полей (столбцов) и значений
(множественные поля и повторяющиеся группы недопустимы). Иначе говоря,
в каждой позиции таблицы на пересечении строки и столбца всегда имеется в
точности одно значение или ничего.
3. Строки таблицы обязательно отличаются друг от друга хотя бы
единственным значением, что позволяет однозначно идентифицировать
любую строку такой таблицы.
4. Столбцам таблицы однозначно присваиваются имена, и в каждом из
них размещаются однородные значения данных (даты, фамилии, целые числа
или денежные суммы).
5. Полное информационное содержание базы данных представляется в
виде явных значений данных и такой метод представления является
единственным. В частности, не существует каких-либо специальных
«связей» или указателей, соединяющих одну таблицу с другой.
6. При выполнении операций с таблицей ее строки и столбцы можно
обрабатывать в любом порядке безотносительно к их информационному
содержанию.
Следовательно, должны быть созданы таблицы Поставщики, Блюда,
Продукты, Заявки, Закупки, Состав, Блюда заявки, Минимальные цены,
68
удовлетворяющие требованиям, сформулированным для соответствующих
сущностей. Однако, прежде чем мы будем использовать данные таблицы для
разработки программного продукта средствами Microsoft Access, следует
убедиться, что набор исходных таблиц является нормализованным, если же
это не так, следует нормализовать его для обеспечения целостности базы
данных и отсутствия ошибок при обработке данных.
Нормализация – это разбиение таблицы на две или более, обладающих
лучшими свойствами при включении, изменении и удалении данных.
Окончательная цель нормализации сводится к получению такого проекта
базы данных, в котором каждый факт появляется лишь в одном месте, т. е.
исключена избыточность информации [12].
Как указывалось выше, каждая таблица в реляционной БД
удовлетворяет условию, в соответствии с которым в позиции на пересечении
каждой строки и столбца таблицы всегда находится единственное атомарное
значение, и никогда не может быть множества таких значений. Любая
таблица, удовлетворяющая этому условию, называется нормализованной.
Фактически, ненормализованные таблицы, т. е. таблицы, содержащие
повторяющиеся группы, даже не допускаются в реляционной БД.
Таблица находится в первой нормальной форме (1НФ) тогда и только
тогда, когда ни одна из ее строк не содержит в любом своем поле более
одного значения и ни одно из ее ключевых полей не пусто. Всякая
нормализованная таблица автоматически считается таблицей в первой
нормальной форме, сокращенно 1НФ. Как нетрудно заметить, все
сконструированные нами ранее исходные таблицы БД учета заказов на ООО
«Альянс» заведомо находятся в первой нормальной форме.
Теория нормализации основывается на наличии той или иной
зависимости между полями таблицы. Определены два вида таких
зависимостей: функциональные и многозначные. Функциональная
зависимость. Поле В таблицы функционально зависит от поля А той же
таблицы в том и только в том случае, когда в любой заданный момент
69
времени для каждого из различных значений поля А обязательно существует
только одно из различных значений поля В. Отметим, что здесь допускается,
что поля А и В могут быть составными. Полная функциональная зависимость.
Поле В находится в полной функциональной зависимости от составного поля
А, если оно функционально зависит от А и не зависит функционально от
любого подмножества поля А. Многозначная зависимость. Поле А
многозначно определяет поле В той же таблицы, если для каждого значения
поля А существует хорошо определенное множество соответствующих
значений В.
Таблица находится во второй нормальной форме (2НФ), если она
удовлетворяет определению 1НФ и все ее поля, не входящие в первичный
ключ, связаны полной функциональной зависимостью с первичным ключом.
Таблица находится в нормальной форме Бойса-Код да (НФБК), если и
только если любая функциональная зависимость между его полями сводится
к полной функциональной зависимости от возможного ключа.
Итак, можно сказать, что нормализация – это разбиение таблицы на
несколько, обладающих лучшими свойствами при обновлении, включении и
удалении данных. Можно дать и другое определение: нормализация – это
процесс последовательной замены таблицы ее полными декомпозициями до
тех пор, пока все они не будут находиться в НФБК.
Рассмотрим таблицу Поставщики. Очевидно, что, поскольку все
содержащиеся записи относятся к конкретному поставщику, которому
присвоен уникальный Код Поставщика, то эта таблица находится во 2НФ, а
так как каждое поле однозначно определяется этим уникальным кодом, то
таблица находится и в НФБК. Аналогичные замечания полностью
применимы к таблицам Продукты, Блюда, Заявки и Закупки, Состав, Блюда
заявки, Минимальные цены, которые, следовательно, также находятся в
НФБК.
Итак, проведя аккуратную разработку инфологической модели, мы
добились того, что при разработке системы таблиц для базы данных удалось
70
сразу предложить нормализованные таблицы. Нам нет необходимости
модифицировать инфологическую модель и для дальнейшей работы мы
можем принять таблицы базы данных в той форме, как они описаны в
соответствии с инфологической моделью сущностей.
Для того, чтобы эффективно работать с разработанной системой таблиц,
необходимо определить, каким образом заполняются соответствующие поля
в таблицах базы данных, а именно установить форматы полей. Снова
последовательно рассмотрим все используемые таблицы.
Таблица Поставщики содержит информацию об организациях и
частных предпринимателях, поставляющих продукты в производственные
цеха ресторана «Альянс». Для эффективной работы с содержащейся в
таблице информацией целесообразно задать форматы полей следующим
образом:
- поле Поставщик является текстовым с длиной 50 – этого вполне
достаточно для ввода всех возможных названий. При необходимости
оператор может использовать сокращенные наименования.
- поле Адрес должно быть текстовым и допускать записи длины 100 –
такого количества символов вполне достаточно для ввода даже самых
длинных адресных записей.
- поле Телефон является текстовым и имеет длину 24 (поскольку кроем
10-значного номера возможно, потребуется вводить еще и дополнительные
цифры)
Что касается ключевого поля Код Поставщика, то в данном случае
целесообразно сделать его в формате Счетчик, что позволит автоматически
нумеровать поставщиков по мере их занесения в базу данных и позволит
контролировать целостность записей по поставщикам в базе данных.
Таблица Продукты содержит информацию об используемых в цехах
ресторана продуктах с указанием их полного названия и используемой в
данном ресторане единице измерения. Для эффективной работы с
71
содержащейся в таблице информацией целесообразно задать форматы полей
следующим образом:
- поле Название является текстовым с длиной 50 – этого вполне
достаточно для ввода всех возможных названий продуктов. При
необходимости оператор может использовать сокращенные наименования.
- поле Единица Измерения должно быть текстовым и допускать записи
длины 12 - такого количества символов вполне достаточно для ввода даже
самых длинных составных единиц измерения.
Что касается ключевого поля Код Продукта, то в данном случае
целесообразно сделать его текстовым (длины 12) для возможности
унифицированного ввода продуктов в зависимости от их пользовательских
характеристик. В настоящее время в ресторане «Альянс» используется
следующая унифицированная форма кодирования продуктов:
Первая буква код а соответствует форме хранения (жидкий –Ж, мягкий
– М, твердый – Т и т. п. ), вторая и третья буквы соответствуют типу
продукта (мясной – МЯ. молочный – МО и т. п. ), далее идет трехзначное
число, соответствующее сроку хранения в часах, далее, через еще один
символ – тире, указывается двузначное число, соответствующее нормативной
температуре хранения и после него указывается символ Н (при
положительной температуре) или Х (в условиях холода). Остальные символы
являются резервными. Например, обычное молоко в пакетах в такой системе
кодирования получит обозначение ЖМО048-05Нм (суффикс м означает, что
используется мягкая упаковка). Поскольку данная форма кодирования на
предприятии является уже сложившейся и даже по форме записи работники
могут визуально определить тип и характеристики продукта, то
целесообразно при автоматизации работы ресторана сохранить эту форму
записи для продуктов без изменений.
Таблица Блюда содержит информацию обо всех изготавливаемых в
ресторане блюдах, составляющих меню ресторана, с указанием их полного
названия, типа блюда, и используемой в данном ресторане единице
72
измерения. Для эффективной работы с содержащейся в таблице
информацией целесообразно задать форматы полей следующим образом:
- поле Название является текстовым с длиной 50 – этого вполне
достаточно для ввода всех возможных названий блюд. При необходимости
оператор может использовать сокращенные наименования.
- поле Единица измерения является текстовым длиной 10
Ключевым является поле Код Блюда, формат поля Счетчик.
Таблица Заявки содержит информацию обо всех совершенных в
ресторане заказах, с указанием даты, Фамилии заказчика и его телефона. Для
эффективной работы с содержащейся в таблице информацией целесообразно
задать форматы полей следующим образом:
- поле дата должно вводиться в формате ДД. ММ. ГГГГ.
- поля Фамилии заказчика и его телефона быть текстовыми длиной 20.
Ключевое поле Код Заявки целесообразно выбрать в формате Счетчик.
Таблица Блюда заявки содержит информацию обо всех блюдах заказа,
с указанием количества порций. Для эффективной работы с содержащейся в
таблице информацией целесообразно задать форматы полей следующим
образом:
- поле Код заявки выбирается из таблицы Заявки;
- поле Код блюда выбирается из таблицы Блюда;
- поле Количество является числовым
Ключевое поле Код целесообразно выбрать в формате Счетчик.
Таблица Закупки содержит информацию обо всех закупках, с
указанием даты закупки, Поставщика кода продукта и количества. Для
эффективной работы с содержащейся в таблице информацией целесообразно
задать форматы полей следующим образом:
- поле Код продукта выбирается из таблицы Продукты;
- поле дата должно вводиться в формате ДД. ММ. ГГГГ.
- поле Количество является числовым
Ключевое поле Код закупки целесообразно выбрать в формате Счетчик.