Проектирование базы данных «Спортивный клуб» методом нормальных форм

Перечень атрибутов.

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

Зависимости между атрибутами отношений:

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

Нормализация — процесс разбиения (декомпозиции) отношений с неудовлетворительными свойствами на новые отношения.

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

Сущность Тренеры (*Код тренера; *ФИО тренера; Адрес тренера; Телефон тренера; Дата рожд. тренера; Серия, № паспорта; Стаж работы, лет; Оклад; *Код вида занятия; Вид занятия; *№ дня недели; День недели; Время; Продолжительность, мин.; *№ зала; Наименование зала; Количество занятий; *Код клиента; ФИО клиента; Дата рожд. клиента; Телефон клиента; Начало действия абонемента; Конец действия абонемента; Оплата; Отметка об оплате).

Исходное отношение имеет составной ключ Код клиента, Код тренера, ФИО тренера, № дня недели, № зала, Код вида занятия. В этом отношении имеется явное и неявное избыточное дублирование данных. Часть избыточности устраняется при переводе отношения в 2НФ.

Вторая нормальная форма. Отношение находится в 2НФ, если:

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

Или 2) любое неключевое поле должно однозначно идентифицироваться ключевыми полями.

Для перевода отношения в 2НФ используется операция проекции, то есть разложения отношения на несколько отношений.

Так как в моем отношении нет составного ключа, то оно уже находится в 3НФ.

Третья нормальная форма.

Отношение находится в 3НФ, если:

• 1) отношение находится в 2НФ,
• 2) каждый неключевой атрибут нетранзитивно зависит от первичного ключа.

Или.

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

Транзитивные зависимости приводят к избыточному дублированию информации в отношении, которое можно устранить операцией проекции на атрибуты, которые являются причиной транзитивных зависимостей. Преобразуем данное отношение в R1, R2, R3, R4, R5, R6, R7, R8, R9, каждое из которых находится в 3НФ:

Выделим R1 (сущность Клиенты):

(*Код клиента; ФИО клиента; Дата рожд. клиента; Телефон клиента; Код тренера).

Данное отношение имеет ключ Код клиента.

Выявим зависимости:

Код клиента Начало действия абонемента Код клиента Конец действия абонемента Код клиента Оплата Код клиента Отметка об оплате Так как все атрибуты функционально зависят от Кода клиента, выявим R2 (сущность Учет):

(*Код клиента; *Начало действия абонемента; Конец действия абонемента; Оплата; Отметка об оплате).

Данное отношение имеет составной ключ Код клиента, Начало действия абонемента.

Выявим транзитивную зависимость:

Код клиента ОплатаКоличество занятий Код клиента Количество занятий Так как атрибуты транзитивно зависят от Кода клиента, выявим R3 (сущность Количество занятий):

(*Оплата; Количество занятий).

Данное отношение имеет ключ Оплата. Выделим R4 (сущность Тренеры):

(*Код тренера; ФИО тренера; Адрес тренера; Телефон тренера; Дата рожд. тренера; Серия, № паспорта; Стаж работы, лет).

Данное отношение имеет ключ Код тренера.

Выявим зависимости:

Код тренера Стаж работы, лет Стаж работы, лет Оклад Код тренера Оклад Так как между атрибутами имеются функциональные зависимости и взаимозависимости, выявим R5 (сущность Оклад):

(*Стаж работы, лет; Оклад) Данное отношение имеет ключ Стаж работы, лет.

Выявим зависимости:

Код тренера Код вида занятия Код тренера № дня недели Код тренера № зала Код тренера Время Код тренера Продолжительность, мин Так как все атрибуты функционально зависят от Кода тренера, выделим: R6 (сущность Залы):

(*Код тренера; Код вида занятия; Вид занятия; *№ дня недели; День недели; Время; Продолжительность, мин.; № зала; Наименование зала).

Данное отношение имеет составной ключ Код тренера, № дня недели.

Выявим зависимости:

Код тренера Код вида занятия Вид занятия Код тренера Вид занятия Так как имеет место транзитивная зависимость атрибутов от Кода тренера, выявим R7 (сущность Виды занятий):

(*Код вида занятия; Вид занятия).

Данное отношение имеет ключ Код вида занятия.

Выявим зависимости:

Код тренера № дня недели День недели Код тренера День недели Так как имеет место транзитивная зависимость атрибутов от Кода тренера, выявим R8 (сущность Дни недели):

(*№ дня недели; День недели).

Данное отношение имеет ключ № дня недели.

Выявим зависимости:

Код тренера № зала Наименование Код тренера Наименование Так как имеет место транзитивная зависимость атрибутов от Кода тренера, выявим R9 (сущность Залы):

(*№ зала; Наименование).

Данное отношение имеет ключ № зала.

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

Усиленная 3НФ или нормальная форма Бойса-Кодда (БКНФ).

Отношение находится в БКНФ, если оно находится в 3НФ и в нем отсутствуют зависимости ключей от неключевых атрибутов.

У нас подобной зависимости нет, поэтому процесс проектирования на этом заканчивается. Результатом проектирования является БД, состоящая из следующих таблиц: R3, R4, R5, R6, R7, R8, R9, R10 и R11. В полученной БД имеет место необходимое дублирование данных, но отсутствует избыточное.