При построении инфологических моделей можно использовать язык ER-диаграмм (от англ. Entity-Relationship, т. е. сущность-связь) [31, стр. 39]. В них сущности изображаются помеченными прямоугольниками, ассоциации - помеченными ромбами или шестиугольниками, атрибуты - помеченными овалами, а связи между ними - ненаправленными ребрами, над которыми может проставляться степень связи (1 или буква, заменяющая слово "много") и необходимое пояснение. Между двумя сущностям, например, А и В возможны четыре вида связей.

Первый тип - связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В:

Второй тип - связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи МНОГИЕ-К-ОДНОМУ (М:1) и МНОГИЕ-КО-МНОГИМ (М:N).

Как правило, определяются три основные класса сущностей: стержневые, ассоциативные и характеристические, а также подкласс ассоциативных сущностей - обозначения. [25, стр. 76-77].

Стержневая сущность (стержень) - это независимая сущность.

Ассоциативная сущность (ассоциация) - это связь вида "многие-ко-многим" ("-ко-многим" и т. д. ) между двумя или более сущностями или экземплярами сущности.

Ассоциации рассматриваются как полноправные сущности:

- они могут участвовать в других ассоциациях и обозначениях точно так же, как стержневые сущности;

- могут обладать свойствами, т. е. иметь не только набор ключевых атрибутов, необходимых для указания связей, но и любое число других атрибутов, характеризующих связь.

Характеристическая сущность (характеристика) - это связь вида "многие-к-одной" или "одна-к-одной" между двумя сущностями (частный случай ассоциации). Единственная цель характеристики в рамках рассматриваемой предметной области состоит в описании или уточнении некоторой другой сущности. Необходимость в них возникает в связи с тем, что сущности реального мира имеют иногда многозначные свойства.

Расширим также язык ER-диаграмм, введя для изображения характеристики трапецию (рисунок 3. 2).

Рисунок 3. 2. - Элементы расширенного языка ER-диаграмм

Обозначающая сущность или обозначение - это связь вида "многие-к-одной" или "одна-к-одной" между двумя сущностями и отличается от характеристики тем, что не зависит от обозначаемой сущности.

3. 1. 2 Инфологическая модель задачи автоматизации работа ресторана «Альянс»

Для обработки поступающих от клиентов заказов, составления плана -меню, контроля состояния склада и формирования заказов поставщикам менеджеры ООО «Альянс» используют значительное количество информационных данных. Сначала следует выделить те атрибуты, которые в обязательном порядке используются всеми менеджерами - именно они и должны лечь в основу разрабатываемой базы данных предприятия. Анализ объектов позволяет выделить:

· стержни Адреса, Заказы, Блюда, Продукты и Сотрудники;

· ассоциации Состав (связывает Блюда с Продуктами), Поставки (связывает Поставщиков с Продуктами), Заказано (связывает Заказы с Блюдами), Обслуживание (связывает Сотрудников с Заказами);

· обозначение Клиенты и Поставщики;

· характеристики Рецепты и Расход.

ER-диаграмма модели показана на рис. 3. 3. а модель на языке ЯИМ имеет следующий вид:

Блюда (БЛ, Блюдо, Вид, Наценка)

Сотрудники (С, ФИО, должность)

Заказы (З, Дата , Столик, Кол-во мест)

Продукты (ПР, Продукт, Описание)

Поставщики (ПОС, Адрес, Поставщик) [Адреса]

Состав [Блюда M, Продукты N] (БЛ, ПР, Вес (г))

Поставки [Поставщики M, Продукты N] (ПОС, ПР, Цена, Ед. измерения)

Заказано [Заказы, Блюда] (З, БЛ, Кол-во)

Обслуживание [Заказы, Сотрудники] (З, С, Время, Примечания)

Адреса (Город, Организация)

Рецепты (БЛ, Рецепт) {Блюда}

Расход (БЛ, Дата _Р, Порций) {Блюда}

В этих моделях Блюдо, Продукт и Поставщик - наименования, а БЛ, ПР и ПОС - цифровые код ы блюд, продуктов и организаций, поставляющих эти продукты.

Далее необходимо выявить атрибуты сущностей и ключи, наборы которые и лягут в основу разрабатываемой базы данных.

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

1. Название поставщика (все поставщики - фирмы или частные предприниматели, имеющие фирменное наименование)

2. Адрес поставщика включает в себя адрес без указания города и страны, поскольку город, область и страну целесообразно выделить в качестве отдельных атрибутов для облегчения процедур анализа продаж)

3. Город поставщика

4. Область поставщика

5. Индекс поставщика

6. Страна поставщика

7. Телефон поставщика (с код ом страны или региона)

8. Факс поставщика (с код ом страны или региона)

9. Кроме того, целесообразно иметь уникальный код Поставщика, поскольку теоретически названия (и другие атрибуты) могут и совпадать, а нам необходимо точно и однозначно идентифицировать каждого Поставщика. Код поставщика будет его девятым атрибутом.

Ключевым полем сущности разумно считать уникальный код Поставщика.

Далее рассмотрим обозначающую сущность Блюда. Ей присущи следующие обязательные атрибуты:

1. Наименование блюда

2. Единица измерения

3. Торговая наценка (указывается в % относительно суммарной стоимости продуктов, используемых при изготовлении данного блюда)

4. Вводим в качестве атрибута уникальный Код Блюда. Этот код является ключом сущности.

Рассмотрим стержневую сущность ПРОДУКТЫ. По сути, это база используемых в работе производственных цехов ресторана элементов. Атрибутами сущности являются:

1. Название продукта

2. Описание продукта.

3. Единица измерения

4. Кроме того, целесообразно иметь уникальный код Продукта, поскольку теоретически названия (и другие атрибуты) могут и совпадать, а нам необходимо точно и однозначно идентифицировать каждый Продукт. Код продукта будет его четвертым атрибутом. Этот код является ключом данной сущности.

Важной стержневой сущностью базы данных является сущность СОТРУДНКИ, с помощью которой ведется база работников предприятия, заносится вся необходимая информация о сотруднике. Необходимыми атрибутами данной сущности являются:

1. Фамилия, имя и отчество сотрудника

2. Пол сотрудника

3. Должность сотрудника

4. Дата рождения сотрудника

5. Адрес сотрудника

6. Домашний телефон сотрудника (с код ом страны или региона)

7. Мобильный телефон сотрудника (с код ом страны или региона)

8. Общие сведения о сотруднике

9. Уникальный идентификационный номер сотрудника, являющийся также и ключом данной сущности.

Сущность ЗАКАЗЫ является стержневой сущностью в данной инфологической модели. Её атрибутами являются:

1. Уникальный код заказа

2. Дата размещения заказа

3. Номер столика заказа

4. Количество обслуживаемых по заказу мест

Следующей сущностью, которую следует проанализировать, является ассоциативная сущность ЗАКАЗАНО. Он связывает сущности ЗАКАЗЫ и Блюда. Её атрибутами являются:

1. Код заказа

2. Код блюда в заказе

3. Количество данного блюда в заказе

4. Предоставленная скидка

5. Ключевыми атрибутами для сущности ЗАКАЗАНО являются пары значений Код заказа и Код Блюда.

Последней сущностью является сущность ОБСЛУЖИВАНИЕ, связывающая сущности СОТРУДНИЕИ и ЗАКАЗЫ. Её атрибутами являются:

1. Код заказа

2. Код сотрудника

3. Время обслуживания заказа

4. Примечания по заказу

Ключевыми атрибутами сущности является пара Код заказа и Код сотрудника.

По результатам проведенного анализа легко видеть, что все рассматриваемые сущности обладают уникальным код ом и этот код является простым, т. е. содержащим только один атрибут сущности либо их связанные пары. Для того, чтобы впоследствии эффективно работать с заявленными сущностями, необходимо точно указать, каким типом данных выражается тот или иной атрибут сущности и каков его размер при размещении в базе данных. Также важно для атрибутов установить, обязательными ли они являются для данной сущности и возможны ли повторения для данных атрибутов [14, стр. 112]. Проведя анализ имеющихся записей у официантов, работающих с клиентами и менеджера зала, можно дать соответствующие оценки. Итоговые данные по сущностям, используемым в инфологической модели базы данных, приведены в Приложении А. Модель на языке ЯИМ имеет следующий вид:

ПОСТАВЩИКИ(Код Поставщика, Название, Адрес, Город, Область, Индекс, Страна, Телефон, Факс)

ПРОДУКТЫ (Код Продукта, Наименование, Описание)

БЛЮДА (Код Блюда, Наименование блюда, Тип блюда, выпускающий цех, Единица измерения, Торговая наценка в %)

СОТРУДНИКИ (Код Сотрудника, ФИО, Пол, Должность, Дата Рождения, Адрес, ДомашнийТелефон, Мобильный Телефон, Примечание)

ЗАКАЗЫ (Код Заказа, Дата , Столик, Количество мест)

ОБСЛУЖИВАНИЕ [Сотрудники-1, Заказы-М] (Код Заказа, Код Сотрудника, Время, Примечания)

ЗАКАЗАНО [Заказы М, Блюда N] (Код Заказа, Код Блюда, Количество, скидка)

СОСТАВ [Блюда М, Продукты N] (Код Блюда, Код Продукта, Единица измерения, Расход)

ПОСТАВКИ [Продукты M, Поставщики N] (Код Продукта, Код Поставщика, Единица измерения, Цена)

РЕЦЕПТЫ (Код Блюда, Наименование блюда, Рецепт) {Блюда}

РАСХОД(Код Блюда, Количество порций, Дата потребления) {Блюда}

3.1.3 Анализ ключей сущностей проектируемой базы данных

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

Теперь о внешних ключах:

- Если сущность С связывает сущности А и В, то она должна включать внешние ключи, соответствующие первичным ключам сущностей А и В.

- Если сущность В обозначает сущность А, то она должна включать внешний ключ, соответствующий первичному ключу сущности А.

Связь между первичными и внешними ключами сущностей иллюстрируется рисунке 1. 6 [14, стр. 119]:

Рисунок 3. 4 - Структуры: а - ассоциации; б - обозначения (характеристики)

В построенных выше стержневых сущностях выделены атрибуты, описывающие внешние ключи. Очевидно, что ни один из них не может принимать неопределенное значение, являясь фактически номером соответствующего экземпляра сущности. Построенные выше сущности имеют следующие ассоциации: сущности ЗАКАЗАНО, ОБСЛУЖИВАНИЕ, ПОСТАВКИ, СОСТАВ. Их первичный ключ представляет собой сочетание внешних ключей.

Для сущности ЗАКАЗАНО первичный ключ представляет собой сочетание внешних ключей, которыми являются атрибуты Код Заказа и Код Блюда, принадлежащие соответственно сущностям БЛЮДА и ЗАКАЗЫ. В случае с сущностями-обозначениями и характеристиками (это сущности БЛЮДА и ЗАКАЗЫ) их первичные ключи Код Блюда и Код Заказа соответственно.

Для сущности ОБСЛУЖИВАНИЕ первичный ключ представляет собой сочетание внешних ключей, которыми являются атрибуты Код Заказа и Код Сотрудника, принадлежащие соответственно сущностям ЗАКАЗЫ и СОТРУДНИКИ.

Для сущности ПОСТАВКИ первичный ключ представляет собой сочетание внешних ключей, которыми являются атрибуты Код Продукта и Код Поставщика, принадлежащие соответственно сущностям ПРОДУКТЫ и ПОСТАВЩИКИ.

Для сущности СОСТАВ первичный ключ представляет собой сочетание внешних ключей, которыми являются атрибуты Код Блюда и Код Продукта, принадлежащие соответственно сущностям БЛЮДА и ПРОДУКТЫ.

Таким образом, соблюдены все требования, предъявляемые к первичным ключам сущности и к их внешним ключам.

Подведем итоги, описав для используемых сущностей процедуры работы с первичными и внешними ключами в случае изменения содержания базы данных. Необходимо ответить на следующие вопросы:

1. Может ли данный внешний ключ принимать неопределенные значения (NULL-значения)? Иначе говоря, может ли существовать некоторый экземпляр сущности данного типа, для которого неизвестна целевая сущность, указываемая внешним ключом?

2. Что должно случиться при попытке УДАЛЕНИЯ целевой сущности, на которую ссылается внешний ключ? Например, при удалении поставщика, который осуществил по крайней мере одну поставку.

Существует три возможности [12, стр. 65-67]:

Что должно происходить при попытке ОБНОВЛЕНИЯ первичного ключа целевой сущности, на которую ссылается некоторый внешний ключ? Например, может быть предпринята попытка обновить номер такого поставщика, для которого имеется по крайней мере одна соответствующая поставка.

Имеются те же три возможности, как и при удалении:

Таким образом, для каждого внешнего ключа в проекте проектировщик базы данных должен специфицировать не только поле или комбинацию полей, составляющих этот внешний ключ, и целевую таблицу, которая идентифицируется этим ключом, но также и ответы на указанные выше вопроса (три ограничения, которые относятся к этому внешнему ключу).

Наконец, о характеристиках - обозначающих сущностях, существование которых зависит от типа обозначаемых сущностей. Обозначение представляется внешним ключом в сущности, соответствующей этой характеристике. Но три рассмотренные выше ограничения на внешний ключ для данного случая должны специфицироваться следующим образом:

NULL-значения не допустимы

УДАЛЕНИЕ ИЗ (цель) КАСКАДИРУЕТСЯ

ОБНОВЛЕНИЕ (первичный ключ цели) КАСКАДИРУЕТСЯ

Указанные спецификации представляют зависимость по существованию характеристических сущностей. В ситуации с рассмотренными выше сущностями базы данных ООО «Альянс» имеют место следующие общие наблюдения:

Сущность ПОСТАВЩИКИ *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( Код Поставщика )

ПОЛЯ (Код Поставщика, Название, Адрес, Город, Индекс, Страна, Телефон, Факс);

Сущность СОТРУДНИКИ *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( Код Сотрудника )

ПОЛЯ (Код Сотрудника, ФИО, Пол, Должность, Дата Рождения, Адрес, Домашний Телефон, Мобильный Телефон, Примечания);

Сущность ЗАКАЗЫ *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( Код Заказа )

ПОЛЯ (Код Заказа, Дата заказа, Номер столика, Количество мест);

Сущность ПРОДУКТЫ *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( Код Продукта )

ПОЛЯ (Код Продукта, Название, Единица измерения);

Сущность БЛЮДА *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( Код Блюда )

ПОЛЯ (Код Блюда, Название блюда, Вид, Описание);

Сущность РЕЦЕПТЫ *( Обозначение )

ПЕРВИЧНЫЙ КЛЮЧ ( Код Блюда )

ВНЕШНИЙ КЛЮЧ ( Код Блюда ИЗ БЛЮДА

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ БЛЮДА ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ БЛЮДА. Код Блюда ОГРАНИЧИВАЕТСЯ)

ПОЛЯ (Код Блюда, Рецепт)

ОГРАНИЧЕНИЯ ( Значения полей Код Блюда должны принадлежать набору значений соответствующих полей сущности БЛЮДА; при нарушении вывод предупреждающего сообщения);

Сущность РАСХОД *( Обозначение )

ПЕРВИЧНЫЙ КЛЮЧ ( Код Блюда, Дата Расхода)

ВНЕШНИЙ КЛЮЧ ( Код Блюда ИЗ БЛЮДА

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ БЛЮДА ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ БЛЮДА. Код Блюда ОГРАНИЧИВАЕТСЯ)

ВНЕШНИЙ КЛЮЧ ( Дата Расхода

NULL-значения НЕ ДОПУСТИМЫ

Должен представлять дату в формате ДД. ММ. ГГГГ)

ПОЛЯ (Код Блюда, Дата Расхода, ЕдИзмерения, Расход)

ОГРАНИЧЕНИЯ ( Значения полей Код Блюда должны принадлежать набору значений соответствующих полей сущности БЛЮДА; при нарушении вывод предупреждающего сообщения);

Сущность ЗАКАЗАНО *( Характеризует БЛЮДА и ЗАКАЗЫ )

ПЕРВИЧНЫЙ КЛЮЧ ( Код Заказа, Код Блюда )

ВНЕШНИЙ КЛЮЧ ( Код Заказа ИЗ ЗАКАЗЫ

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ ЗАКАЗЫ ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ ЗАКАЗЫ. Код Заказа КАСКАДИРУЕТСЯ)

ВНЕШНИЙ КЛЮЧ ( Код Блюда ИЗ БЛЮДА

NULL-значения ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ БЛЮДА ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ БЛЮДА. Код Блюда КАСКАДИРУЕТСЯ)

ПОЛЯ ( Код Заказа, Код Блюда, Количество )

ОГРАНИЧЕНИЯ ( Значения поля Код Заказа должны принадлежать набору значений соответствующего поля сущности Заказы, значение поля Код Блюда принадлежит набору значений соответствующего поля сущности БЛЮДА; при нарушении вывод сообщения);

Сущность ОБСЛУЖИВАНИЕ *( Связывает СОТРУДНИКИ и ЗАКАЗЫ )

ПЕРВИЧНЫЙ КЛЮЧ ( Код Заказа, Код Сотрудника )

ВНЕШНИЙ КЛЮЧ ( Код Заказа ИЗ ЗАКАЗЫ

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ ЗАКАЗЫ ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ ЗАКАЗЫ. Код Заказа КАСКАДИРУЕТСЯ)

ВНЕШНИЙ КЛЮЧ ( Код Сотрудника ИЗ СОТРУДНИКА

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ ТОВАРЫ ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ ТОВАРЫ. Код Сотрудника КАСКАДИРУЕТСЯ)

ПОЛЯ ( Код Заказа, Код Сотрудника, Время, Примечания )

ОГРАНИЧЕНИЯ ( Значения полей Код Заказа и Код Сотрудника должны принадлежать набору значений соответствующих полей сущностей ЗАКАЗЫ и СОТРУДНИКИ; при нарушении вывод сообщения);

Сущность ПОСТАВКИ *( Связывает ПРОДУКТЫ и ПОСТАВЩИКИ )

ПЕРВИЧНЫЙ КЛЮЧ ( Код Продукта, Код Поставщика)

ВНЕШНИЙ КЛЮЧ ( Код Продукта ИЗ ПРОДУКТЫ

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ ПРОДУКТЫ ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ ПРОДУКТЫ. Код Продукта КАСКАДИРУЕТСЯ)

ВНЕШНИЙ КЛЮЧ ( Код Поставщика ИЗ ПОСТАВЩИКИ

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ ПОСТАВЩИКИ ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ ПОСТАВЩИКИ Код Поставщика КАСКАДИРУЕТСЯ)

ПОЛЯ ( Код Продукта, Код Поставщика, Цена, ЕдИзмерения)

ОГРАНИЧЕНИЯ ( Значения полей Код Продукта и Код Поставщика должны принадлежать набору значений соответствующих полей сущностей ПРОДУКТЫ и ПОСТАВЩИКИ; при нарушении вывод сообщения);

Сущность СОСТАВ *( Связывает БЛЮДА и ПРОДУКТЫ )

ПЕРВИЧНЫЙ КЛЮЧ ( Код Блюда, Код Продукта)

ВНЕШНИЙ КЛЮЧ ( Код Блюда ИЗ БЛЮДА

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ БЛЮДА ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ БЛЮДА. Код Блюда КАСКАДИРУЕТСЯ)

ВНЕШНИЙ КЛЮЧ ( Код Продукта ИЗ ПРОДУКТЫ

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ ПРОДУКТЫ ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ ПРОДУКТЫ. Код Продукта КАСКАДИРУЕТСЯ)

ПОЛЯ ( Код Блюда, Код Продукта, ед. измерения, Количество)

ОГРАНИЧЕНИЯ ( Значения полей Код Блюда и Код Продукта должны принадлежать набору значений соответствующих полей сущностей БЛЮДА и ПРОДУКТЫ; при нарушении вывод сообщения);

3.1.4 Разработка и нормализация системы таблиц базы данных

Выбрав реляционный подход к разработке базы данных, мы фактически приняли решение использовать для описания сущностей таблицы данных, удовлетворяющие некоторым естественным внешним ограничениям:

1. Каждая таблица состоит из однотипных строк и имеет уникальное имя.

2. Строки имеют фиксированное число полей (столбцов) и значений (множественные поля и повторяющиеся группы недопустимы). Иначе говоря, в каждой позиции таблицы на пересечении строки и столбца всегда имеется в точности одно значение или ничего.

3. Строки таблицы обязательно отличаются друг от друга хотя бы единственным значением, что позволяет однозначно идентифицировать любую строку такой таблицы.

4. Столбцам таблицы однозначно присваиваются имена, и в каждом из них размещаются однородные значения данных (даты, фамилии, целые числа или денежные суммы).

5. Полное информационное содержание базы данных представляется в виде явных значений данных и такой метод представления является единственным. В частности, не существует каких-либо специальных "связей" или указателей, соединяющих одну таблицу с другой.

6. При выполнении операций с таблицей ее строки и столбцы можно обрабатывать в любом порядке безотносительно к их информационному содержанию.

Следовательно, должны быть созданы таблицы Поставщики, Блюда, Продукты, Заказано, Заказы, Сотрудники, Обслуживание, Клиенты, Расход, Рецепты, Поставки удовлетворяющие требованиям, сформулированным для соответствующих сущностей и приведенным в Приложении А. Однако, прежде чем мы будем использовать данные таблицы для разработки программного продукта средствами Microsoft Access, следует убедиться, что набор исходных таблиц является нормализованным, если же это не так, следует нормализовать его для обеспечения целостности базы данных и отсутствия ошибок при обработке данных.

Нормализация - это разбиение таблицы на две или более, обладающих лучшими свойствами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т. е. исключена избыточность информации [12, стр. 188-190].

Как указывалось выше, каждая таблица в реляционной БД удовлетворяет условию, в соответствии с которым в позиции на пересечении каждой строки и столбца таблицы всегда находится единственное атомарное значение, и никогда не может быть множества таких значений. Любая таблица, удовлетворяющая этому условию, называется нормализованной. Фактически, ненормализованные таблицы, т. е. таблицы, содержащие повторяющиеся группы, даже не допускаются в реляционной БД.

Таблица находится в первой нормальной форме (1НФ) тогда и только тогда, когда ни одна из ее строк не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто. Всякая нормализованная таблица автоматически считается таблицей в первой нормальной форме, сокращенно 1НФ. Как нетрудно заметить, все сконструированные нами ранее исходные таблицы БД учета заказов на ООО «Меркатор» заведомо находятся в первой нормальной форме.

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

Таблица находится во второй нормальной форме (2НФ), если она удовлетворяет определению 1НФ и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом.

Таблица находится в нормальной форме Бойса-Код да (НФБК), если и только если любая функциональная зависимость между его полями сводится к полной функциональной зависимости от возможного ключа.

Итак, можно сказать, что нормализация - это разбиение таблицы на несколько, обладающих лучшими свойствами при обновлении, включении и удалении данных. Можно дать и другое определение: нормализация - это процесс последовательной замены таблицы ее полными декомпозициями до тех пор, пока все они не будут находиться в НФБК.

Рассмотрим таблицу Поставщики. Очевидно, что, поскольку все содержащиеся записи относятся к конкретному поставщику, которому присвоен уникальный Код Поставщика, то эта таблица находится во 2НФ, а так как каждое поле однозначно определяется этим уникальным код ом, то таблица находится и в НФБК. Аналогичные замечания полностью применимы к таблицам Продукты, Блюда, Заказы и Сотрудники, которые, следовательно, также находятся в НФБК.

Что касается таблиц Расход и Рецепты, то они имею ключевые поля вида Код Блюда-Дата Расхода и Код Блюда соответственно. Очевидно, что эти таблицы находятся в нормальной форме Бойса-Код да.

Наиболее сложными для анализа являются таблицы Обслуживание, Поставки, Состав и Заказано. Ключевым полем в таблице Заказано является поле Код Заказа-Код Блюда, оно действительно однозначно определяет все другие поля таблицы. Следовательно, таблица находится в 2НФ. Но, совершенно очевидно, что все другие поля содержат только сведения о количестве блюд данного наименования в данном заказе и поэтому функционально зависят от ключевого поля. Следовательно, таблица находится в НФБК. Что касается таблицы Обслуживание, то её ключевое поле является составным (Код Заказа - Код Сотрудника). Поскольку исключены повторения сотрудников при выполнении одного и того же заказа, а время выполнения заказа однозначно определено этими двумя полями, то и эта таблица находится в НФБК. Аналогичные рассуждения применимы и к таблицам Поставки и Состав.

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

3.1.5 Определение форматов данных в таблицах базы данных

Для того, чтобы эффективно работать с разработанной в предыдущих разделах системой таблиц, необходимо определить, каким образом заполняются соответствующие поля в таблицах базы данных, а именно установить форматы полей. Снова последовательно рассмотрим все используемые таблицы.

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

- поле Название является текстовым с длиной 50 - этого вполне достаточно для ввода всех возможных названий. При необходимости оператор может использовать сокращенные наименования.

- поле Адрес должно быть текстовым и допускать записи длины 100 - такого количества символов вполне достаточно для ввода даже самых длинных адресных записей.

- поле Город является текстовым и имеет длину 15

- поле Область является текстовым и имеет длину 15

- поле Индекс является текстовым и имеет длину 10

- поле Страна является текстовым и имеет длину 20

- поле Телефон является текстовым и имеет длину 24 (поскольку кроем 10-значного номера возможно, потребуется вводить еще и дополнительные цифры)

- поле Факс является текстовым и имеет длину 24

Что касается ключевого поля Код Поставщика, то в данном случае целесообразно сделать его в формате Счетчик, что позволит автоматически нумеровать поставщиков по мере их занесения в базу данных и позволит контролировать целостность записей по поставщикам в базе данных.

Таблица Продукты содержит информацию об используемых в цехах ресторана продуктах с указанием их полного названия и используемой в данном ресторане единице измерения. Для эффективной работы с содержащейся в таблице информацией целесообразно задать форматы полей следующим образом:

- поле Название является текстовым с длиной 50 - этого вполне достаточно для ввода всех возможных названий продуктов. При необходимости оператор может использовать сокращенные наименования.

- поле Единица Измерения должно быть текстовым и допускать записи длины 12 - такого количества символов вполне достаточно для ввода даже самых длинных составных единиц измерения.

Что касается ключевого поля Код Продукта, то в данном случае целесообразно сделать его текстовым (длины 12) для возможности унифицированного ввода продуктов в зависимости от их пользовательских характеристик. В настоящее время в ресторане «Альянс» используется следующая унифицированная форма код ирования продуктов:

Первая буква код а соответствует форме хранения (жидкий -Ж, мягкий - М, твердый - Т и т. п. ), вторая и третья буквы соответствуют типу продукта (мясной - МЯ. молочный - МО и т. п. ), далее идет трехзначное число, соответствующее сроку хранения в часах, далее, через еще один символ - тире, указывается двузначное число, соответствующее нормативной температуре хранения и после него указывается символ Н (при положительной температуре) или Х (в условиях холода), далее указывается номер цеха, принимающего данный продукт. Остальные символы являются резервными. Например, обычное молоко в пакетах в такой системе код ирования получит обозначение ЖМО048-05Н3м (суффикс м означает, что используется мягкая упаковка). Поскольку данная форма код ирования на предприятии является уже сложившейся и даже по форме записи работники цехов могут визуально определить тип и характеристики продукта, то целесообразно при автоматизации работы ресторана сохранить эту форму записи для продуктов без изменений.

Таблица Блюда содержит информацию обо всех изготавливаемых в ресторане блюдах, составляющих меню ресторана, с указанием их полного названия, типа блюда, выпускающего цеха и используемой в данном ресторане единице измерения, а также принятой торговой наценкой (в % от себестоимости продуктов, использцуемых при приготовлении данного блюда). Для эффективной работы с содержащейся в таблице информацией целесообразно задать форматы полей следующим образом:

- поле Название является текстовым с длиной 50 - этого вполне достаточно для ввода всех возможных названий блюд. При необходимости оператор может использовать сокращенные наименования.

- поле Вид является текстовым длиной 50

- поле Описание содержит полное описание блюда и поэтому его необходимо определить в формате МЕМО.

- поле наценка является числовым. Необходимо при вводе данных в это поле обеспечить контроль - вводимые значения должны находиться в интервале от 0 до 100, поскольку представляют собой проценты.

Ключевым является поле Код Блюда, его по сложившейся в ресторане «Альянс» практике следует считать текстовым с длиной 12. Код блюда определяется по следующей схеме: первая буква определяет тип блюда (П- первое, В- второе, Т- третье, З - закуска, Н - напиток), вторая характеристику блюда ( Г- горячее, Х - холодное, А - алкогольное т т. п. ), затем три цифры определяют вес порции, затем идет номер выпускающего цеха, затем указывается двухзначный план сервировки, трехзначное число, идущее после дефиса, определяет срок хранения. Например, для супа харчо запись будет иметь вид: ПГ245103-024.

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

- поля ФИО, Пол, Должность, Дата Рождения, Адрес, Домашний Телефон, Мобильный Телефон целесообразно определить как текстовые длиной 50, а поле Примечания - как поле в формате МЕМО.

Ключевым является поле Код Сотрудника, его по сложившейся в ресторане «Альянс» практике следует считать текстовым с длиной 6. Код сотрудника определяется по следующей схеме: первая буква определяет служебную категорию сотрудника, затем идет дефис, затем две буквы служат сокращением должности, затем идет указание номера структурного подразделения ресторана, к которому приписан данный сотрудник, через дефис - номер сотрудника в сводной ведомости. Например, официант получит запись вида 2-Оф02-044.

Таблица Заказы содержит информацию обо всех совершенных в ресторане заказах, с указанием даты, номера столика и количества занятых мест. Для эффективной работы с содержащейся в таблице информацией целесообразно задать форматы полей следующим образом:

- поле дата должно вводиться в формате ДД. ММ. ГГГГ.

- поля Номер Столика и Количество Мест должны быть числовыми. При вводе данных долен осуществляться контроль за соответствием вводимых чисел реальному состоянию дел (например, количество столиков в ресторане 26, а количество посадочных мест ограничено числом 146).

Ключевое поле Код Заказа целесообразно выбрать в формате текста и, поскольку отлаженной системы кодирования заказов в ресторане пока не сложилось, предоставить сотрудникам возможность вводить код ы заказов в соответствии со своими представлениями об этой процедуре, а впоследствии установить общие правила кодирования заказов.

Таблица Обслуживание является ассоциацией двух других таблиц, поэтому её ключевые поля Код Заказа и Код Сотрудника уже были определены раньше. Поле Время следует вводить в формате ЧЧ. ММ, а поле Примечания должно иметь формат МЕМО, поскольку в нем возможны любые записи, связанные с исполнением данного заказа.

Таблица Заказано также является ассоциацией двух других таблиц, поэтому её ключевые поля Код Заказа и Код Блюда уже были определены раньше. Поле Количество следует выбрать числовым, а поле Скидка также должно быть числовым, но необходимо определить контроль: значение скидки должно быть в пределах от 0 до 100 (поскольку она указывается в процентах).

Таблица Состав является ассоциацией двух других таблиц, поэтому её ключевые поля Код Блюда и Код Продукта уже были определены раньше. Поле Единица Измерения целесообразно выбрать текстовым дины 12, а поле Расход должно быть числовым.

Таблица Поставки является ассоциацией двух других таблиц, поэтому её ключевые поля Код Продукта и Код Поставщика уже были определены раньше. Поле Единица Измерения целесообразно выбрать текстовым дины 12, а поле Цена должно быть числовым (денежным).

3.1.6 Характеристика входной, справочно-нормативной и результатной информации при использовании ЭИС АСУПП ресторана «Альянс»

В программном комплекса автоматизации производственных процессов ресторана «Альянс» используется справочно-нормативнная и входная информация, на основании которых заинтересованные пользователи получают информационные результатные блоки.

К справочно-нормативной информации комплекса следует отнести те данные, которые составляют основу информационной системы ресторана и мало подвержены изменениям с течением времени. К таким информационным блокам первую очередь относятся:

- сведения о поставщиках, содержащиеся в таблице Поставщики

- сведения о сотрудниках, содержащиеся в таблице базы данных Сотрудники

- сведения о блюдах, составляющих ресторанное меню. Данные о блюдах собраны в три таблицы - Блюда, Рецепты и Состав. Фактически единственной переменной величиной в этих таблицах является величина торговой наценки в таблице Блюда.

Для просмотра и редактирования справочно-нормативной информации в программном комплексе должны быть предусмотрены формы, отображающие данные от сотрудниках, поставщиках и о блюдах. Доступ к этим формам должен быть организован из главной формы программного комплекса прямыми ссылками.

Помимо справочной информации, программный комплекс должен работать с оперативной входной информацией, основу которой составляют данные о поступлении и выполнении заказов посетителей ресторана. Данные об оперативной работе ресторана собираются с использованием таблиц базы данных Заказы, Обслуживание, Заказано. Доступ к формам, обеспечивающих внесение данных в эти таблицы, также должен осуществляться из главной формы программного комплекса. Отдельно необходимо отметить таблицу План-меню, в которой администрацией ресторана формируются планы-меню на отчетные даты. Для работы с планами-меню должна быть предусмотрена отдельная форма.

На основании оперативной и справочной информации фактически и должна осуществляться содержательная обработка информационных данных в проектируемом программном комплексе. При этом следует учесть потребности всех потенциальных пользователей программного комплекса. Особую важность анализ данных имеет для администрации, поскольку должен позволить проводить текущий и стратегические (долгосрочный) анализ продаж в разрезе клиентов ресторана, поставщиков продукции, а также и сотрудников, выполняющих работы по обслуживанию заказов. Именно, к системе аналитической обработки данных предъявляются следующие требования:

1. Программа должна позволять формировать полный список всех блюд, которые в настоящий момент могут быть предложены рестораном, с указанием их основных признаков и с расчетом себестоимости при условии закупа продуктов у тех поставщиков, которые уже задействованы в базе данных, а также с указанием их ожидаемой реализационной цены при использовании наценки из таблицы Блюда.

2. Программа должна формировать список всех необходимых для организации производственного процесса продуктов. По плану-меню на отчетную дату программа должна автоматически формировать список продуктов, которые необходимо закупить у поставщиков на отчетную дату. При этом выбор поставщика для каждой товарной позиции должен выполняться автоматически с учетом минимизации закупочных цен на товары.

3. Программа должна формировать полный отчет об имеющихся заказах с указанием их текущих параметров: даты размещения заказа, выбранных в заказе блюд, об обслуживании заказа сотрудником ресторана.

4. Возможность формирования списка всех заказов за интересующий год (или другой временной промежуток) с указанием даты размещения, стоимости заказа, его код а.

5. Возможность сформировать сведения обо всех заказах, размещенных в прошлом 2011 году с указанием всех существенных атрибутов заказа.

6. Возможность формирования списка всех блюд ресторана с ценой, выше средней.

7. Возможность формирования данных о продажах по сотрудникам - для того, чтобы иметь возможность анализировать эффективность их работы.

8. Возможность выделения данных, необходимых для формировании впоследствии для каждого заказа, счета, выставляемого клиенту.

9. Для анализа логистической структуры поставок администрации ресторана необходимо иметь возможность объединения в одном документе данных по поставщикам и городам.

10. Наконец, необходимо иметь возможность анализа имеющихся данных о продажах по кварталам.

3.2 Программное обеспечение комплекса задач ЭИС АСУПП ресторана «Альянс»

Для того, чтобы организовать работу с базой данных, необходимо на первом этапе четко представить систему базовых таблиц и выяснить, откуда берутся данные для заполнения этих таблиц (для построения экземпляров сущностей), а также определить, кто из сотрудников организации отвечает за ввод тех или иных исходных данных. Итоговые таблицы и связи между нами представлены ниже на рисунке 2. 2.

Рисунок 3. 5. Схема данных базы данных автоматизации производственных процессов ресторана «Альянс».

Подробные описания таблиц базы данных вынесены в Приложение 4.

В разделе 3. 1. 5. были сформулированы основные требования к модулю обработки информации в базе данных ресторана «Альянс». В основе этого модуля лежит система запросов, обеспечивающая выделения необходимых информационных данных по запросам пользователей. Начнем построение требуемых запросов. Запрос Самый Дешевый Продукт режиме конструктора будет иметь вид:

Рисунок 3. 6. Запрос Самый Дешевый Продукт в режиме конструктора

Соответствующая инструкция на языке SQL имеет вид:

SELECT Поставки. Код Продукта, Min (Поставки. Код Поставщика) AS [Min-Код Поставщика], Поставки. Название, Поставки. Ед Измерения, Min (Поставки. Цена) AS [Min-Цена]

FROM Поставки

GROUP BY Поставки. Код Продукта, Поставки. Название, Поставки. Ед Измерения;