Пример проектирования базы данных
Назначение и предметная область
База данных предназначена для хранения информации о персонале некоторой компании. В компании есть несколько отделов. В каждом отделе есть несколько сотрудников, несколько проектов и несколько кабинетов. Каждый сотрудник имеет несколько заданий. Для каждого задания существует ведомость с перечнем денежных сумм, полученных сотрудником за выполнение данной работы. В каждом кабинете есть несколько телефонов.
В базе данных должна храниться следующая информация:
Для каждого отдела: уникальный номер отдела, бюджет и уникальный номер руководителя отдела;
для каждого сотрудника: уникальный номер сотрудника, номер текущего проекта, номер кабинета, номер телефона, а также название выполняемой работы вместе с датами и размерами всех оплат, полученных за выполнение данной работы;
для каждого проекта: уникальный номер проекта и бюджет;
для каждого кабинета: уникальный номер кабинета, площадь, номера всех телефонов.
Семантические утверждения (ограничения):
Ни один сотрудник не является одновременно руководителем нескольких отделов;
ни один сотрудник не работает одновременно более чем в одном отделе;
ни один сотрудник не работает одновременно более чем с одним проектом;
ни один сотрудник не имеет одновременно более одного кабинета;
ни один сотрудник не имеет одновременно более одного телефона;
ни один сотрудник не имеет одновременно более одного задания;
ни один проект не дается одновременно более чем одному отделу;
ни один кабинет не относится одновременно более чем к одному отделу.
Проектирование базы данных
А
нализ
определенных выше объектов и атрибутов
позволяет выделить сущности проектируемой
базы данных и построить ее инфологическую
модель в виде "Таблицы-связи"
(рис. 5.7.1).
Исходную иерархическую структуру можно рассматривать как ненормализованное отношение:
ОТДЕЛЫ (ОТД№, БЮДЖЕТ_О, РУК№, СОТРУДНИКИ, ПРОЕКТЫ, КАБИНЕТЫ) CANDIDATE KEY (ОТД№) CANDIDATE KEY (РУК№)
Здесь смысл атрибутов ОТД№ (уникальный номер отдела), БЮДЖЕТ_О, РУК№ (номер руководителя) понятен из названий, а атрибуты СОТРУДНИКИ, ПРОЕКТЫ, КАБИНЕТЫ состоят из значений-отношений. Мы можем расписать их вложенные атрибуты:
ОТДЕЛЫ (ОТД№, БЮДЖЕТ, РУК№, СОТРУДНИКИ (СОТР№, ПРОЕКТ№, КАБ№, ТЕЛ№, РАБОТА (ТЕМА, ОПЛАТА (ДАТА, СУММА))), ПРОЕКТЫ (ПРОЕКТ№, БЮДЖЕТ_П), КАБИНЕТЫ (КАБ№, ПЛОЩАДЬ, ТЕЛЕФОН (ТЕЛ№))) CANDIDATE KEY (ОТД№) CANDIDATE KEY (РУК№)
Сейчас можно привести это отношение к набору отношений в 1НФ. При этом, рассматривая каждое значение-отношение отдельно, мы исключаем все многозначные зависимости, которые не являются функциональными зависимостями.
ОТДЕЛЫ1 (ОТД№, БЮДЖЕТ_О, РУК№) PRIMARY KEY (ОТД№) ALTERNATE KEY (РУК№)
СОТРУДН1 (СОТР№, ОТД№, ПРОЕКТ№, КАБ№, ТЕЛ№) PRIMARY KEY (СОТР№)
РАБОТА1 (ТЕМА, СОТР№) PRIMARY KEY (ТЕМА, СОТР№)
ОПЛАТА1 (СОТР№, ТЕМА, ДАТА, СУММА) PRIMARY KEY (СОТР№, ТЕМА, ДАТА)
ПРОЕКТЫ1 (ПРОЕКТ№, БЮДЖЕТ_П, ОТД№) PRIMARY KEY (ПРОЕКТ№)
КАБИНЕТЫ1 (КАБ№, ПЛОЩАДЬ, ОТД№) PRIMARY KEY (КАБ№)
ТЕЛЕФОНЫ1 (ТЕЛ№, КАБ№) PRIMARY KEY (ТЕЛ№)
Далее, можно привести отношения, находящиеся в 1НФ, к эквивалентной совокупности отношений в 2НФ, исключая неприводимые зависимости.
Отношения ОТДЕЛЫ1, СОТРУДН1, ОПЛАТА1, ПРОЕКТЫ1, КАБИНЕТЫ1 и ТЕЛЕФОНЫ1 уже находятся в 2НФ.
Отношение РАБОТА1 является проекцией отношения ОПЛАТА1, следовательно, оно несет избыточную информацию и его можно удалить без потери данных. В то же время, отношение ТЕЛЕФОНЫ1 является проекцией отношения СОТРУДН1, но при его удалении появятся аномалии обновления – данные о телефонах не будут существовать без данных о конкретных сотрудниках.
Покажем сейчас структуру базы данных, отношения которой приведены к 2НФ, используя язык моделирования «Таблица-Связь», который применяется в СУБД MS ACCESS:
ОТДЕЛ2 |
|
СОТРУДН2 |
|
ОПЛАТА2 |
|
ПРОЕКТ2 |
|
КАБИНЕТ2 |
|
ТЕЛЕФОН2 |
ОТД№ |
СОТР№ |
СОТР№ |
|
ПРОЕКТ№ |
КАБ№ |
ТЕЛ№ |
||||
БЮДЖЕТ_О |
ОТД№ |
ДАТА |
ОТД№ |
ПЛОЩАДЬ |
КАБ№ |
|||||
РУК№ |
|
ПРОЕКТ№ |
ТЕМА |
БЮДЖЕТ_П |
ОТД№ |
|
||||
|
КАБ№ |
|
СУММА |
|
|
|
|
|
|
|
|
ТЕЛ№ |
|
|
|
|
|
|
|
||
Далее, исключая транзитивные зависимости, можно привести отношения к эквивалентной совокупности отношений в 3НФ. Единственным отношением, которое не находится в 3НФ, является отношение СОТРУДН, в котором атрибуты КАБ№ и ОТД№ транзитивно зависят от первичного ключа СОТР№ – КАБ№ через ТЕЛ№, а ОТД№ через ПРОЕКТ№ и, кроме того, через КАБ№ и ТЕЛ№. Тогда отношение СОТРУДН можно заменить совокупностью проекций, находящихся в 3НФ:
СОТРУДН3 (СОТР№, ПРОЕКТ№, ТЕЛ№) PRIMARY KEY (СОТР№)
X (ТЕЛ№, КАБ№) PRIMARY KEY (ТЕЛ№)
Y (ПРОЕКТ№, ОТД№) PRIMARY KEY (ПРОЕКТ№)
Z (КАБ№, ОТД№) PRIMARY KEY (КАБ№)
Но отношение X – аналог отношения ТЕЛЕФОН2, Y – проекции отношения ПРОЕКТ2, Z – проекции КАБИНЕТ2 и, значит, могут быть удалены из модели базы данных. Следовательно, модель базы данных, отношения которой приведены к 3НФ, будет выглядеть так:
ОТДЕЛЫ3 (ОТД№, БЮДЖЕТ_О, РУК№) PRIMARY KEY (ОТД№) ALTERNATE KEY (РУК№)
СОТРУДН3 (СОТР№, ПРОЕКТ№, ТЕЛ№) PRIMARY KEY (СОТР№)
ОПЛАТА3 (СОТР№, ТЕМА, ДАТА, СУММА) PRIMARY KEY (СОТР№, ТЕМА, ДАТА)
ПРОЕКТЫ3 (ПРОЕКТ№, БЮДЖЕТ_П, ОТД№) PRIMARY KEY (ПРОЕКТ№)
КАБИНЕТЫ3 (КАБ№, ПЛОЩАДЬ, ОТД№) PRIMARY KEY (КАБ№)
ТЕЛЕФОНЫ3 (ТЕЛ№, КАБ№) PRIMARY KEY (ТЕЛ№)
Каждое из этих отношений находится в НФБК. Более того, они находятся в 4НФ – от возможных многозначных зависимостей мы избавились на этапе приведения модели к 1НФ. Все отношения не содержат видимых аномалий и поэтому можно предполагать, что база данных сконструирована правильно.