Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Курсовик «разработка Базы Данных Для Ресторана» По Базам Данных (Марков А. А.).doc
Скачиваний:
63
Добавлен:
07.10.2014
Размер:
666.11 Кб
Скачать

Функциональные зависимости (пояснения по выбору первичных ключей)

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

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

В таблицах «orders», «dishes», «firm», «tables», «waiters» первичными ключами являются «ID_order», «ID_dish», «ID_firm», «ID_table», «ID_waiter» соответственно. Использование ID в этих таблицах удобно и необходимо, так как значения других атрибутов повторяются, и они не могут использоваться как первичные ключи. В таблице «dishes» можно было бы принять атрибут «name» («название блюда») в качестве первичного ключа, потому что оно уникально. Но его не удобно было бы использовать в таблице связи заказов с блюдами («order_dishes»). Поэтому в этой таблице был введен атрибут «ID_dish» («номер блюда») – первичный ключ.

В таблице «order_dishes» («состав заказа») номер заказа «ID_order» связан с номером блюда «ID_dish». Но т.к. заказ может включать несколько блюд, то «ID_order» повторяется, и поэтому не может быть первичным ключом. Одно блюдо может входить в состав нескольких заказов, поэтому «ID_dish» тоже не может быть первичным ключом. Первичный ключ в данной таблице составной и включает «ID_order» и «ID_dish». Сочетание номеров повториться не может.

Таблица «waiter_tables» («официант_столики») осуществляет связь официанта с номером столика. Один официант обслуживает несколько столиков, поэтому в этой таблице составной ключ («ID_waiter», «ID_table»).

Начальное заполнение таблиц

Для демонстрации особенностей базы данных, работы типовых запросов, триггеров и хранимых процедур созданные таблицы были заполнены тестовыми данными. Ниже приведены таблицы с примером хранящихся в них данных. Исходные коды пакетного файла для заполнения базы находятся в приложении №3.

  1. Таблица «dishes»:

……………………………………………………………………………………

2. Таблица «firm»:

  1. Таблица «orders»:

  1. Таблица «order_dishes»:

  1. Таблица «tables»:

  1. Таблица «waiters»:

  1. Таблица «waiter_tables»: