4. Нормализация реляционных баз данных

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

4.1. Некоторые операции над отношениями

1. Проектирование – получение проекции.

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

Пусть – некоторый набор атрибутов отношения,k<n. Операция проектирования на набор атрибутов А ставит в соответствие отношению R новое отношение R[A], получаемое из исходного отношения удалением значений атрибутов, не принадлежащих множеству А. Проектирование – удаление «ненужных» столбцов.

2. Соединение.

Обратно проектированию. При соединении всегда нужно указывать критерий, по которому будут склеиваться строки исходных таблиц. Критерий соединения включает наборы соединяемых атрибутов и операцию отношения из множества . Наборы соединяемых атрибутовА и В должны быть -сравнимы, т.е. они должны иметь одинаковую длину для любого aA и bB. Результат операции должен принимать значение ИСТИНА или ЛОЖЬ и не должен быть неопределенным (например, можно сравнивать вес и рост, нельзя сравнивать имя и рост).

Наборы атрибутов состоят из нескольких столбцов. Пусть имеется набор и.A и B -сравнимы, еслиk = n, а также и-сравнимы, гдеi = 1÷n.

Критерий сравнения :

.

Пусть C, Q – два кортежа, т.е. и. Сцепление кортежейC и Q – кортеж . Обозначение: (С, Q) или (С Q).

Пусть наборы атрибутов А и В отношений R и S -сравнимы. Тогда соединениеR и S по критерию A B – отношение R[A B]S, кортежи которого получаются сцеплением тех кортежей исходных отношений, для которых на наборах атрибутов А и В критерий сравнения принимает значение ИСТИНА:

R[A B]S = {(r, s) | r R, s S, r.Ai s.Bi = True, i = 1÷k}.

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

СЛУЖАЩИЙ_1(Код_сотрудника, Фамилия, Зарплата)

СЛУЖАЩИЙ_2(Код_сотрудника, Вычеты).

Операция соединения этих отношений по очевидному критерию равенства значений в атрибуте Код_сотрудника приведет к отношению вида:

СЛУЖАЩИЙ(Код_сотрудника, Фамилия, Зарплата, Код_сотрудника, Вычеты).

Налицо нарушение свойства 3 реляционных таблиц «Столбцы однозначно именуются». Для устранения данной проблемы введена операция естественного соединения.

Если операция – равенство, то один из двух одинаковых атрибутов (в примере – столбцов “Код_сотрудника”) удаляется. Операция обозначается

R*[A=B]*S или R*S.

Естественное соединение по критерию равенства кодов сотрудников

СЛУЖАЩИЙ(Код_сотрудника, Фамилия, Зарплата, Вычеты).

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

Пусть имеются два отношения:

ЗАКАЗ (Код_заказчика, Код_товара, Дата_заказа)

ПОСТАВКА (Код_заказчика, Код_товара, Дата_поставки)

Бизнес-правило: поставка товара осуществляется в срок, не более 7 дней после даты получения заказа.

Задача: найти заказы, по которым отдел поставки не уложился в нормативный срок.

Результирующее отношение будет иметь вид:

ПРОСРОЧЕННАЯ_ПОСТАВКА(Код_заказчика, Код_товара, Дата_заказа, Дата_поставки)

При его получении необходимы операции естественного соединения на наборе атрибутов (Код_заказчика, Код_товара) и соединения на наборе атрибутов (Дата_заказа, Дата_поставки) по критерию Дата_поставки – Дата_заказа > 7

4.2. Функциональные зависимости в отношениях. Возможные ключи. Ключ

Отношения характеризуются внутренними устойчивыми связями, которые определяются семантикой. В частности, в отношениях существуют атрибуты, от которых зависят другие атрибуты. Например, в приведенном выше отношении СЛУЖАЩИЙ от атрибута Код_сотрудника напрямую зависят атрибуты Фамилия, Зарплата, Вычеты. Такие устойчивые отношения называются функциональными зависимостями.

Функциональной зависимостью (ФЗ) набора атрибутов В отношения R от набора атрибутов А того же отношения называется такое соотношение элементов проекций R[A] и R[B], при котором в каждый момент времени любому элементу проекции R[A] соответствует строго один элемент проекции R[B], входящий вместе с ним в некоторый кортеж отношения R.

Наличие ФЗ обозначается R.A R.B

Отсутствие ФЗ обозначается R.A R.B

Такое явление, как ФЗ приводит к понятию возможного ключа (ключа-кандидата). Это набор атрибутов, от которого зависят остальные атрибуты. В одном отношении может быть несколько возможных ключей.

Совокупность атрибутов, входящих в набор К отношения R, является возможным ключом, если:

1. Каждый атрибут R функционально зависит от К;

2. Ни один атрибут из набора К не может быть удален без нарушения пункта 1.

Математическое определение:

пусть М – полный набор атрибутов R. К является возможным ключом, если:

R.K R.A;

M R. R.B

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

Требования основные:

1. Ключ не может иметь значение NULL (не определено, неизвестно);

2. Ключ должен быть уникальным.

Дополнительные требования:

1. Ключ должен быть коротким, компактным.

2. Ключ должен быть по возможности стабильным.

Практически все СУБД по ключу строят индексы. Фактически выбор ключа влияет на физическую организацию данных.

Ключ служит для однозначной идентификации записей. Этим объясняется необходимость соблюдения основных требований. За этим следит СУБД. Если набор атрибутов описан на языке описания данных СУБД как ключевой, СУБД не допустит нарушения основных требований.

Ключ служит для организации связи между таблицами. При этом ключ родительской записи дублируется в подчиненной записи, обеспечивая привязку дочерних сущностей к родительским. Этим объясняется дополнительное требование компактности. Если ключ родительской сущности часто изменяется, для сохранения связей его изменения надо немедленно портировать во все подчиненные таблицы. Этим объясняется дополнительное требование стабильности.

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

Существует два типа ключей: естественные и суррогатные. Если ключ составляется непосредственно из полей таблицы, он называется естественным. Если в таблице нет полей, удовлетворяющих требованиям к ключу, он создается искусственно введением дополнительного поля (как правило, единственного с целью обеспечения компактности). Обычно суррогатные ключи – это уникальные в переделах таблицы целочисленные коды, однозначно идентифицирующие запись и не отображаемые в интерфейсе пользователя. По сути, они увеличивают объем базы данных. Но за счет этого повышается скорость работы, эффективно организуются межтабличные связи.

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

Допустим, требуется работать с данными, которые можно представить в виде отношения со схемой:

СОТРУДНИК (Табельный_номер, Фамилия, Имя, Отчество, Должность)

На первый взгляд, поле Табельный_номер можно сделать естественным ключом. Но, прежде чем принимать такое решение, его надо проверить на соответствие основным требованиям. Для этого надо задать постановщику задачи вопросы:

1. У всех ли работающих есть табельные номера? Это проверка первого требования наличия значений. Возможна ситуация, когда, например, стажеру на период испытательного срока табельный номер не присваивается;

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

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