Зачем нужна нормализация

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

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

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

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

Нормальная форма

Первая

Вторая Третья Бойса-Кодда

Четвертая

Свойства таблицы

Содержит информацию об одной сущности, имеет первичный ключ; каждая ячейка содержит одно значение

Значения всех столбцов зависят от полного первичного ключа

Только первичный ключ определяет значения столбцов

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

Значения NULL во внешних ключах недопустимы, если этих ключей больше одного

Первая нормальная форма

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

Первая нормальная форма 99

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

Рассмотрим инструкцию CREATE TABLE, приведенную в листинге 8.1. Это таблица музыкального каталога. Она может хранить описание любой пластинки, любого компакт-диска и любой кассеты, имеющихся в коллекции. Указываются дата приобретения носителя и его нынешняя цена.

CREATE TABLE recording (

Главный принцип первой нормальной формы заключается в том, что любая запись таблицы должна содержать описание одной сущности. Этому правилу удовлетворяет практически любая таблица, поскольку столбцы выбираются сознательно. В нашем случае в таблице находятся описания предметов музхкальной коллекции. Но если присмотреться, то окажется, что столбцы можно разделить на две группы. Столбцы первой группы (Artist, Released, Title, Format, Label, Genre, Length, CurrentValue) описывают любой экземпляр музыкального носителя, а не только тот, что имеется в коллекции. Столбцы второй группы (Purchased, Cost) относятся к одному конкретному экземпляру. Может показаться, что таблицу следует разбить на две части. Но прежде давайте познакомимся с двумя другими принципами первой нормальной формы.

Второй принцип требует наличия первичного ключа. С технической точки зрения созданная выше таблица не имеет ключа: я просто не указал его в инструкции CREATE TABLE. Вспомните из главы 7, Проектирование баз нных , что в качестве первичного ключа можно использовать столбец-счетчик. Есть ли альтернативы? Допустим, столбцы Artist и Released формируют составной ключ. Тогда исполнитель не должен одновременно выпускать две разные работы. Это неразумное ограничение, потому что описанная ситуация возможна. Тогда предположим, что первичный ключ образуют столбцы Artist, Released и Title. Кажется глупым, чтобы исполнитель одновременно выпустил две работы с одинаковым названием. Но не забывайте о формате. Очень часто бывает, что альбом выходит на компакт-дисках и кассетах. Таким образом, можно продолжить включать столбцы в первичный ключ. По сути, несложно привести разумные доводы в пользу того, почему ключом следует сделать всю совокупность столбцов. Это чересчур непрактично, поэтому мы воспользуемся полем-счетчиком.

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

типа VARCHAR. Например, в столбце Format может быть записано 78,LP . Это означает, что носитель представляет собой долгоиграющую пластинку на 78 оборотов. Такой формат хранения не оптимален, поскольку пропадает возможность осуществлять отбор записей отдельно по каждому из этих критериев. Попробуйте найти все пластинки в коллекции. Можно, конечно, применить оператор LIKE, описанный в главе 10, Типы даннгх, переменные и выражения . В MySQL есть даже тип SET, обозначающий неупорядоченный набор значений, но его поддержка ограничена. Следует очень внимательно контролировать ситуации, когда в ячейку заносится несколько значений.

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

CREATE TABLE recording (

ID INT {11} NOT NULL AUTO INCREMENT,

Artist VARCHAR (32) NOT NULL,

Released DATE,

Title VARCHAR (32) NOT NULL,

Format VARCHAR (32) NOT NULL,

Label VARCHAR(32),

Genre VARCHAR (32),

Length INT (11),

Purchased DATE,

Cost DECIMAL(11,2),

CurrentValue DECIMAL{11,2),

PRIMARY KEY(ID)

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

Вторая нормальная форма

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

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

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