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

Основой нормализации являются ключи, только ключи и ничего кроме ключей.

Иногда встречается также забавное дополнение к этой формуле:

Основой нормализации являются ключи, только ключи и ничего кроме ключей, да поможет мне Кодд!

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

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

Вступительные сведения

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

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

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

Процесс нормализации сущностей и связей, на котором основана процедура проектирования базы данных и создания таблиц, предусматривающий последовательный

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

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

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

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

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

Постепенный переход к третьей нормальной форме

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

Первая нормальная форма (First Normal Form - INF) предназначена для устранения повторяющихся групп данных и обеспечения неразрывности данных (обеспечения того, чтобы данные не содержали ссылки на другие данные и были независимыми). Наиболее целесообразный способ достижения этой цели состоит в осуществлении следующих этапов: создать первичный ключ (предположим, что данный этап уже выполнен), после чего перемещать все повторяющиеся группы данных в новые таблицы, создавать для этих таблиц новые ключи, и т.д. Кроме того, необходимо разделить на два или несколько столбцов все столбцы, характеризующиеся тем, что в них присутствуют многозначные данные, которые в различных строках представлены в разных комбинациях.

Следующий этап нормализации состоит в переходе ко второй нормальной форме (Second Normal Form - 2NF). Применение второй нормальной формы способствует дальнейшему сокращению количества повторяющихся данных (которые не должны обязательно составлять группы). Вторая нормальная форма определяется в соответствии с двумя приведенными ниже правилами.

□ Таблица должна удовлетворить правилам для первой нормальной формы. (Процесс нормализации является строго последовательным и напоминает кладку стены - в стену невозможно положить третий кирпич, не положив перед этим два первых.)

□ 1Саждый столбец должен зависеть от всего ключа.

Применение третьей нормальной формы (Third Normal Form - 3NF) позволяет добиться того, чтобы ни один столбец в таблице не зависел от каких-либо

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

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

□ Ни в одном столбце не должны проявляться какие-либо зависимости от другого неключевого столбца.

□ Наличие в таблице производных данных не допускается.

Другие нормальные формы

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

Нормальная форма Бойса-Кодца (Boyce-Codd), которая фактически часто рассматривается как разновидность третьей нормальной формы. Она относится к той ситуации, в которой имеется несколько перекрывающихся потенциальных ключей. Такая срггуация может возникать только при следующих услови5гх:

а) все потенциальные ключи являются составными ключами (иными словами, для создания ключа требуется больше одного столбца);

б) количество потенциальных ключей больше одного;

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

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

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

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