3. Даталогическое проектирование

Даталогическое проектирование в РБД, называемое также логическим проектированием, - это построение схемы БД, т.е. совокупности схем отношений, которые адекватно отображают объекты предметной области и семантические связи между ними.

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

Классическая технология логического проектирования реляционных баз данных основана на теории нормализации отношений, разработанной американским математиком Е.Коддом. При этом проектирование – это последовательный переход от более низких нормальных форм к более высоким формам. Различают следующие нормальные формы : 1НФ, 2НФ, 3НФ, НФ Бойса-Кодда, 4НФ, 5НФ. На практике ограничиваются, как правило, приведением отношений к третьей нормальной форме (3НФ). В процессе нормализации элементы данных группируются в таблицы, представляющие объекты и их взаимосвязи.

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

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

Введем вначале некоторые понятия.

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

Определение 2. Отношение приведено к 1НФ, если все его атрибуты простые.

Рассмотрим процесс нормализации на примере отношения Сотрудник.

R1: Сотрудник

Таб№	ФИО	Оклад	Комната	Телефон	Дети Имя_ Возраст_ ребенка ребенка
211	Иванов И.И.	5000	12	616	Саша 10 Женя 7 Вася 3
358	Темин Т.Т.	7000	12	616	Вова 5
360	Котов К.К.	10000	5	306	Таня 8 Саша 6

Табельный номер в этом отношении является первичным ключом. Атрибуты Таб№, ФИО, Оклад, Комната, Телефон являются простыми, а вот атрибут Дети – это соединение значений из двух доменов, т.е. – сложный. И, согласно определению 2, отношение R1 не приведено к 1НФ.

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

Для приведения к 1НФ расширим первичный ключ R1 ( его исходный первичный ключ – это Таб№). Добавим к первичному ключу одно из полей сложного атрибута, например, Имя_ребенка., и заполним таблицу следующим образом.

R2: Сотрудник

Таб№	Имя_ ребенка	ФИО	Оклад	Комната	Телефон	Возраст_ ребенка
211 211 211	Саша Женя Вася	Иванов И.И. Иванов И.И Иванов И.И	5000 5000 5000	12 12 12	616 616 616	10 7 3
358	Вова	Темин Т.Т.	7000	12	616	5
360 360	Таня Саша	Котов К.К. Котов К.К.	10000 10000	5 5	306 306	8 6

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

1. Одна и та же информация дублируется многократно.

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

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

Чтобы устранить эти недостатки, продолжим процесс нормализации. Но предварительно дадим некоторые определения.

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

Отношение может иметь несколько возможных ключей, среди которых выбирается один, называемый затем первичным ключом отношения. Например, отношение Студент имеет два возможных ключа: ФИО и №_зач_книжки. Но, как правило, первичным ключом назначается атрибут №_зач_книжки.

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

Определение 5. Функциональная зависимость.

Пусть Х и У два атрибута некоторого отношения.

Говорят, что У функционально зависит от Х, если в любой момент времени каждому значению Х соответствует только одно значение У(Х. У).

Например, зависимость между атрибутами ФИО_студента и №_группы в отношении «Студент» будут выглядеть так:

ФИО_студента №_группы, а не наоборот.

Определение 6. Взаимно-независимые атрибуты – это атрибуты, которые функционально не зависят друг от друга.

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

Определение 8. Говорят, что не ключевой атрибут функционально полно зависит от составного ключа, если он функционально зависит от всего ключа , а не от какой-то его части.

В свете выше сказанного определим функциональные зависимости для нашего примера, т.е. отношения R2 (рис.3.1).

Как видим из рисунка, от составного ключа зависит только один не ключевой атрибут, а именно Возраст_ребенка. Все же остальные не ключевые атрибуты зависят только от части ключа, от атрибута Таб№.

Рис.3.1. Функциональные зависимости отношения R2.

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

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

Для приведения к 2НФ проведем декомпозицию (разделение) данного отношения на несколько отношений в зависимости от функциональных зависимостей. В результате получим следующие отношения:

R3: Дети R4: Сотрудник

Таб№	Имя_ ребенка	Возраст_ ребенка		Таб№	ФИО	Оклад	Комната	Телефон
211	Саша	10		211	Иванов И.И.	5000	12	616
211	Женя	7		358	Темин Т.Т.	7000	12	616
211	Вася	3		360	Котов К.К.	10000	5	306
358	Вова	5
360	Таня	8
360	Саша	6

Итак, получили два отношения, каждое из которых приведено ко 2НФ. Вернемся теперь к тем недостаткам отношения R2, которые были перечислены выше. Все они исчезли при приведении R2 ко 2НФ, т.е. при разделении R2 на два новых: R3 и R4.

1. Дублирование информации исчезло.

2. По каждому сотруднику вносятся изменения только в одну строчку.

3. Если даже у сотрудника нет детей, информация о нем все равно попадает в базу данных в таблицу R4.

Рассмотрим теперь подробнее отношение R4 . Номер телефона в этом отношении – это скорее характеристика комнаты, а не сотрудника.

Рис. 3.2. Функциональные зависимости отношения R4