Основные понятия реляционной модели данных. Потенциальные ключи отношений, страница 7

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

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

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

·  Для каждого проекта должен храниться уникальный номер проекта и бюджет.

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

Данные зависимости получились на основе исходных данных, а также на основе следующих утверждений:

1.  Ни один сотрудник не является одновременно руководителем нескольких отделов.

2.  Ни один сотрудник не работает одновременно более чем в одном отделе.

3.  Ни один сотрудник не работает одновременно более чем с одним проектом.

4.  Ни один сотрудник не имеет одновременно более одного кабинета.

5.  Ни один сотрудник не имеет одновременно более одного телефона.

6.  Ни один сотрудник не имеет более одного задания.

7.  Ни один проект не выполняется одновременно более чем одним отделом.

8.  Ни один кабинет не относится одновременно более чем к одному отделу.

Рассмотренную ранее иерархическую структуру можно рассмотреть как ненормализованное отношение следующего вида:

DEPT0(DEPT#, DBUDJET, MGR#, EMP (EMP#, PROJ#, OFF#, PHONE#, XJOBO (JOBTITLE, XSALHISTO(DATE, SALARY))), XPROJO(PROJ#, PBUDJET, XOFFICE(OFF#, AREA, XPHONEO(PHONE#)))

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

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

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

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

В результате получим следующий набор отношений, находящихся в 1НФ:

1.  DEPT1 (DEPT#, DBUDJET,MGR#)

2.  EMP1 (DEPT#, EMP#, PROJ#, OFF#, PHONE#)

3.  JOB1 (DEPT#, EMP#, JOBTITLE)

4.  SALHIST1 (DEPT#, EMP#, JOBTITLE, DATE, SALARY)

5.  OFFICE1 (DEPT#, OFF#, AREA)

6.  PHONE1 (DEPT#, OFF#, PHONE)

7.  PROJ1 (DEPT#, PROJ#, BUDJET)

(1) – уже находится в 2НФ.

(2) – не 2НФ, т.к. компонент ключа «номер отдела» - избыточен.

(3) – номер отдела также не обязателен. Для приведения к 2НФ разбиваем на 2 следующих отношения:

JOBA (EMP#, JOBTITLE)

JOBB (EMP#, DEPT#)

(4) – можно удалить атрибут DEPT# & JOBTITLE.

(5) – если OFF# рассматривать, как необязательный компонент первичного ключа, то отношение находится в 2НФ.