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