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


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

Для решения этих вопросов автором и разработчиком концепции реляционной модели данных Е. Коддом был разработан аппарат, называемый нормализацией отношений (таблиц). И хотя идеи нормализации сформированы в терминологии реляционной модели данных, они применимы и для других моделей данных.

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

При практическом проектировании реляционных БД обычно используют три нормальные формы таблиц. Самая совершенная - третья. Существует алгоритм, позволяющий любое отношение (таблицу) преобразовать к третьей нормальной форме. В процессе таких преобразований могут выделяться новые отношения.

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

Простым является атрибут, если его значения атомарны, т.е. неделимы.

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

Согласно 1НФ, в каждой позиции (клетке таблицы), определяемой строкой и столбцом, должна быть только одна величина, но не массив или список величин.

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

Рассмотрим пример таблицы, нарушающей требования 1НФ (звездочкой будем обозначать ключевое поле):

 

Заказы1

КодЗаказа* КодПокупателя СодержаниеЗаказа
5 молотков, 3 дрели, 6 ключей
1 молоток, 4 ключа
2 ключа

 

Таблица Заказы1 служит для хранения данных о заказах на складе инструментов. Эта таблица имеет простой ключ, состоящий из одного поля КодЗаказа. Данные в столбце СодержаниеЗаказасодержат списки величин и не являются атомарными. Так как в столбце СодержаниеЗаказанаходится слишком много информации, то получить упорядоченную информацию из этой таблицы будет трудно. Например, трудоёмким окажется составление отчёта о суммарных закупках инструментов различных видов. Таблицу Заказы1 можно преобразовать (без потери данных) в таблицу Заказы2, удовлетворяющую требованиям 1НФ:

Заказы2

КодЗаказа* КодСодержанияЗаказа* КодПокупателя Количествово СодержаниеЗаказа
молоток
дрель
ключ
молоток
ключ
ключ

 

Эта таблица имеет составной ключ из двух полей: КодЗаказа и КодСодержанияЗаказа. Данные всех столбцов таблицы Заказы2 являются атомарными.

 

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

Функциональная зависимость атрибутов - это зависимость, при которой определенному значению ключа соответствует только одно значение описательного атрибута.

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

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

Например, отношение Сотрудники находится в 1НФи имеет составной ключ Табельный номер родителя – Имя ребенка:

Сотрудники

Табельный номер родителя Имя ребенка Возраст ФИО Оклад
Саша Иванов И.И.
Женя Иванов И.И.
Вася Иванов И.И. 120
Таня Петров П.П.
Петя Сидоров С.С.

 

Атрибуты ФИО и Оклад не находятся в полной функциональной зависимости от ключа отношения, т.к. они функционально зависят только от части ключа - столбца Табельный номер родителя. Рассмотрим атрибут Оклад. Нерационально хранить эту информацию в отношении, каждый кортеж которого соответствует ребенку сотрудника. Во-первых, в этом случае имеет место дублирование информации, поскольку у сотрудника может быть несколько детей, и для каждого из них будут храниться сведения об окладе родителя. Кроме того, при изменении оклада понадобится корректировать не один, а несколько кортежей отношения (несколько строк таблицы). Во-вторых, проблема возникает с сотрудниками, у которых нет детей. Им не соответствует ни один кортеж отношения, а значит, БД не может содержать сведений о таких сотрудниках. Очевидно, что рассматриваемое отношение следует преобразовать.

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

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

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

Дети Родители

 

Табельный номер родителя Имя ребенка Возраст   Табельный номер ФИО Оклад
Саша   Иванов И.И.
Женя   Петров П.П.
Вася   Сидоров С.С. 180
Таня        
Петя        

 

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

Одну и ту же таблицу можно привести к 2НФ разными способами, не теряя данных.

Например, таблица Заказы2 не находится во 2НФ. Эта таблица имеет составной ключ, включающий 2 поля: КодЗаказа и КодСодержанияЗаказа. В то же время, неключевое поле СодержаниеЗаказа однозначно определяется только полем КодСодержанияЗаказа, т.е. только одним из двух полей, входящих в составной ключ. При заданной кодировке инструментов на складе для заполнения значения поля СодержаниеЗаказа достаточно знать только значение поля КодСодержанияЗаказа (1 – молоток, 2 – дрель и т. д.). Таким образом, для поля СодержаниеЗаказа отсутствует функциональная зависимость от всего составного ключа и таблица Заказы2 не находится во 2НФ. Таблицу Заказы2 можно преобразовать без потери данных в таблицу Заказы3, удовлетворяющую требованиям 2НФ:

 

Заказы3

КодЗаказа* СодержаниеЗаказа* КодПокупателя Количество
молоток
дрель
ключ
молоток
ключ
ключ

У таблицы Заказы3 составной ключ содержит 2 поля: КодЗаказа и СодержаниеЗаказа, а неключевые или описательные поля КодПокупателя и Количество функционально зависят от всего составного ключа. Из данного примера также видно, как уменьшается повторение одинаковых данных при переходе от 1НФ ко 2НФ («исчезает» один столбец из двух, содержащих повторяющиеся данные в таблице Заказы2).

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

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

Например, отношение

 

ДанныеСотрудников

 

Табельный номер ФИО Оклад Комната Телефон
Иванов И.И.
Петров П.П.
Сидоров С.С 180

 

находится во 2НФ, но не в 3НФ, т.к. атрибут Телефон зависит от номера комнаты, в которой работает сотрудник. Это отношение можно преобразовать в два отношения, связанных по полю Комната:

 



Дата добавления: 2016-06-22; просмотров: 2345;


Поиск по сайту:

Воспользовавшись поиском можно найти нужную информацию на сайте.

Поделитесь с друзьями:

Считаете данную информацию полезной, тогда расскажите друзьям в соц. сетях.
Poznayka.org - Познайка.Орг - 2016-2024 год. Материал предоставляется для ознакомительных и учебных целей.
Генерация страницы за: 0.01 сек.