3 Выбор системы управления базой данных.

В настоящее время существует большое количество программных продуктов, в которых можно реализовать спроектированную базу данных. Самыми популярными СУБД на сегодняшний день являются: «1С предприятие», «Microsoft Access», «Lotus Approach», «FoxPro», «dBase», «Paradox».

Для выбора СУБД решим, какими функциональными возможностями должна она обладать.

Круг людей, которые могут иметь доступ к базе данных ресторана «Версаль» должен быть ограничен, требуется стойкая система защиты. СУБД должна обеспечивать целостность данных на уровне базы данных, ввиду сложности ее внутренней структуры. СУБД должна обеспечивать быстрый доступ к данным, возможность накопления данных.

Выдвинутым требованиям соответствует СУБД, которая входит в комплект поставки пакета приложений Microsoft Office -Microsoft Access 2003

Выбранная нами СУБД Microsoft Office Access 2003 вполне устраивает нас по ряду причин:

- стопроцентная интеграция в среде Windows.

- обеспечение процессов ввода и обработки данных.

- обеспечение целостности данных.

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

MS Access имеет самый богатый набор визуальных средств.

Для коммерческого распространения приложений, разработанных на Access, предназначен пакет Access Developer Toolkit, вместе с которым поставляются некоторые дополнения и несколько дополнительных объектов ActiveX.

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

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

4 Логическое проектирование

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

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

- представим стержни Меню, Продукты, Поставщики, в виде таблиц и специфицируем ключ:

Таблица 3 - Меню Таблица 4 - Продукты

Меню

Код блюда

Название блюда

Вид блюда

Цена_в руб

Изображение

Вес

Продукты

Код продукта

Калорийность

Продукт

Таблица 5 – Поставщики

Поставщики

Код поставщика

Поставщик

Город

ИНН

Телефон

В таблице «Меню» поле Код блюда назначено ключевым.

В таблице «Продукты» ключевым является поле Код продукта.

В таблице «Поставщики» ключевым является поле Код поставщика.

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

- представим ассоциативные сущности Состав и Поставки в виде таблиц, обозначим ключи.

Таблица 6 – Состав Таблица 7 - Поставки

Состав

Код блюда

Код продукта

Поставки

Код продукта

Код поставщика

Количество

Дата

Цена_в руб

Код поставки

Таблица «Состав» является ассоциацией – внешним ключом является Код продукта.

В таблице «Поставки» внешним ключом является поле Код поставки.

- Рассмотрим характеризующие сущности Рецепт и Прибыль

Представим их в виде таблиц:

Таблица 8 – Рецепт Таблица 9 – Прибыль

Рецепт

Код блюда

Ингредиенты

Рецепт

Прибыль

Код продажи

Дата

Число проданных порций

Код блюда

В таблице «Рецепт» внешним ключом является поле Код блюда.

В таблице «Прибыль» внешним ключом служит поле Код продажи.

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

Условия и ограничения, накладываемые на отношения:

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

- строки имеют фиксированное число полей и значений;

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

- столбцам таблицы присваивается имена и в каждом из них размещаются однородные значения данных;

-отсутствуют какие-либо специальные «связи» и указатели, соединяющих одну таблицу с другой;

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

Данные условия выполняются, следовательно таблицы можно считать отношениями.

Рассмотрим реляционные отношения и проведем нормализацию таблиц базы данных.

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

В таблице «Меню» присутствует избыточные данные, так как атрибуты поля «Вид блюда» повторяются (салат, первое блюдо, второе, десерт, напитки), поэтому необходимо провести отношение ко 2-ой нормальной форме. Это делаем введением таблицы «Вид блюда» (с полями Код вида и Вид), являющейся характеристикой.

В поле «Вес порции» также присутствуют повторяющиеся данные. Приводим отношение ко 2-й нормальной форме введением характеристики Вес порций, с полями Код веса , Вес.

С учетом введения новой таблицы, изменится ER-диаграмма - вид рисунка 3.

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

Укажем ограничения целостности проектируемой базы данных. В таблице «Меню» не должны совпадать коды блюд и видов. Также в таблице «Состав» код продукта не должен совпадать с кодом блюда; в таблице «Поставки» не должны быть одинаковыми код продукта и код поставщика.

Рисунок 3 – ER-диаграмма

В подчиненные таблицы «Рецепт», «Прибыль», «Состав» нельзя вносить либо удалять запись без добавления или удаления записи в таблицу «Меню». Аналогично нельзя вносить и удалять запись в таблицы «Поставки» и «Поставщики» без проделанных соответствующих операций в таблице «Продукты».

5 ФИЗИЧЕСКОЕ ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ

16