Проект базы данных ресторана

 

Сущность «Поставка» - исходная сущность

код поставки

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

код ингредиента

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

цена

количество

 

Результат отображения на реляционную  модель:

Отношение 15 («Ингредиент»)

код ингредиента

наименование

значение

 

Отношение 16 («Поставка»)

код поставки

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

код ингредиента

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

цена

количество

 

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

8   Связь «Поставщик – Поставка»

В данном случае получена связь «один-ко-многим», причем от сущности «Поствка» идет простая связь, поэтому именно она и будет являться исходной.

Сущность «Поставщик» - порожденная сущность

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

название

страна

область

город

адрес

телефон

 

Сущность «Поставка» - исходная сущность

код поставки

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

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

код ингредиента

цена

кол-во

 

Результат отображения на реляционную  модель:

Отношение 17 («Поставщик»)

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

название

страна

область

город

адрес

телефон

 

Отношение 18 («Поставка»)

код поставки

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

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

код ингредиента

цена

кол-во

 

Необходимости в переносе ключа «Код поставщика» порожденной сущности «Поставщик» в исходную сущность «Поставка» нет, так как она уже включает в себя этот атрибут.

Итак, в результате логического  проектирования были получены следующие  отношения:

Отношение 1 («Сотрудники»)

код клиента

фамилия

имя

отчество

№ телефона

код скидки

 

Отношение 2 («Клиенты»)

код клиента

фамилия

имя

отчество

№ телефона

код скидки

 

Отношение 3 («Меню»)

код блюда

код ингредиента

наименование

цена

 

Отношение 4 («Заказы»)

код заказа

код блюда

код сотрудника

код клиента

дата заказа

количество

 

Отношение 5 («Ингредиент»)

код скидки

наименование

значение

 

Отношение 6 («Поставка»)

код поставки

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

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

код ингредиента

цена

кол-во

 

Отношение 7 («Поставщик»)

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

название

страна

область

город

адрес

телефон

 

Отношение 8 («Зарплата»)

код выплаты

код сотрудника

дата выплаты

месяц

оплата

количество часов

 

Отношение 9 («Скидка»)

код скидки

наименование

значение

 

Отношение 10 («Заказы_Меню»)

код заказа

код блюда

код ингредиента

 

Отношение 11 («Меню_Состав»)

код ингредиента

код блюда

 

3.4 Нормализация отношений

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

3.4.1 Приведение отношений к первой нормальной форме

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

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

3.4.2 Приведение отношений ко второй нормальной форме

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

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

 

Функциональные зависимости отношения 1

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

Фамилия

Имя

Отчество

Дата рождения

Адрес

Номер телефона

Должность

Дата найма

Дата увольнения

Т.к. первичный ключ не является составным, то отношение 1 находится во 2НФ.

 

Функциональные зависимости отношения 2

Код клиента

Фамилия

Имя

Отчество

Номер телефона

Код скидки

 

Данное отношение находится  во 2НФ

 

 

Функциональные зависимости отношения 3

Код блюда

Код ингредиента

Наименование

Цена

 

В данном случае отношение не состоит  во 2НФ. Для приведения его в нее  необходимо создать новое отношение, которое будет состоять из тех атрибутов, которые зависят от части первичного ключа, а затем установить связь между отношениями.

Отношение «Меню»

Код блюда

Наименование

Цена

 

Отношение «Меню_Состав»

Код блюда

Код ингредиента

Раскладка

 

Функциональные зависимости отношения 4

Код заказа

Код блюда

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

Код клиента

Дата заказа

Количество

 

Необходимо создание еще одного отношения.

Отношение «Заказы_Учет»

Код заказа

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

Дата заказа

 

Отношение «Заказы_Обслуживание»

Код заказа

Код блюда

Код клиента

Количество

 

Функциональные зависимости отношения 5

Код ингредиента

Наименование

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

 

Данное отношение находится во 2НФ

 

Функциональные зависимости отношения 6

Код поставки

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

Дата поставки

Код ингредиента

Цена

Количество

 

Данное отношение уже находится во 2НФ

 

Функциональные зависимости отношения 7

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

Название

Страна

Область

Город

Адрес

Телефон

 

Функциональные зависимости отношения 8

Код выплаты

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

Дата выплаты

Месяц

Оплата

Количество часов

 

Отношение 8 находится во 2НФ.

 

Функциональные зависимости отношения 9

Код скидки

Наименование

Значение

 

Отношение 9 также находится во 2НФ.

 

Функциональные зависимости отношения 10

Код заказа

Код блюда

Код ингредиента

 

В последнем отношении  нет неключевых атрибутов, следовательно, он находится в 2НФ

Проанализировав все выше сказанное, можно утверждать, что все отношения приведены ко второй нормальной форме.

3.4.3 Приведение отношений к третьей нормальной форме

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

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

В результате логического проектирования и нормализации была получена логическая модель с помощью пакета ERWin (приложение Ж).

 

 

4 ФИЗИЧЕСКОЕ ПРОЕКТИРОВАНИЕ

 

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

Формат хранимых записей определим  исходя из реальных объёмов хранимой информации и формата её представления. Физическое представление атрибутов отношений представлены на таблицах З.1-З.12.

Также получили физическую модель с помощью пакета ERWin (приложение И).

 

 

 

 

 

 

5 ПРОГРАМНОЕ И ТЕХНИЧЕСКОЕ ОБЕСПЕЧЕНИЯ

 

5.1 Обоснование выбора СУБД

Группа реляционных СУБД представлена на рынке программных продуктов  очень широко. Одним из  представителей данной группы является СУБД Access (фирма Microsoft). Данная СУБД имеет достаточно высокие скоростные характеристики и входит в состав чрезвычайно популярного в нашей стране и за рубежом пакета Microsoft Office. Набор команд и функций, предлагаемых разработчикам программных продуктов в среде Access, по мощи и гибкости отвечает большинству современных требований к представлению и обработке данных. В Access поддерживаются разнообразные всплывающие и многоуровневые меню, работа с окнами, также реализованы функции низкоуровнего доступа к файлам, управления цветами, представления данных в виде электронных таблиц и т.д. К тому же система обладает средствами быстрой генерации отчетов и меню, поддерживает язык управления запросами SQL, хорошо работает в сети. К плюсам данной СУБД можно отнести и тот факт, что Access позволяет использовать другие компоненты пакета Microsoft Office, такие как Word, Excel и т.д

Перечисленные факторы и определили выбор СУБД Access в качестве среды для практической реализации спроектированной БД.

5.2 Системные требования

Для обеспечения качественного  применения выбранной среды необходимо учесть минимальные требования к  технической базе. Для этого необходим IBM-совместимый компьютер на базе процессора с тактовой частотой не ниже 100 МГц, видеокарта 16 Мбайт, установленный пакет Microsoft Office 2003 или отдельно продукт Microsoft Access 2003, операционная система MS Windows 98 или MS Windows ХР, мышь.