Описание основных принципов нормализации базы данных

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

Описание нормализации

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

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

Что такое "несогласованная зависимость"? Хотя пользователю естественно искать адрес конкретного клиента в таблице «Клиенты», вряд ли имеет смысл искать там зарплату сотрудника, который работает с этим клиентом. Заработная плата сотрудника связана с сотрудником или зависит от него, поэтому её следует перенести в таблицу «Сотрудники». Несогласованные зависимости могут затруднить доступ к данным, так как путь для поиска данных может быть пропущен или нарушен.

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

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

Ниже приведены примеры.

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

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

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

Что происходит при добавлении третьего поставщика? Добавление поля не является ответом; он требует изменения в программе и таблице и не обеспечивает плавное размещение динамического числа поставщиков. Вместо этого поместите всю информацию о поставщиках в отдельную таблицу под названием «Поставщики», а затем свяжите таблицу запасов с поставщиками по ключу номера позиции или поставщиков с таблицей запасов по ключу кода поставщика.

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

• Создайте отдельные таблицы для наборов значений, которые применяются к нескольким записям.
• Свяжите эти таблицы внешним ключом.

Записи не должны зависеть ни от чего, кроме первичного ключа таблицы (составного ключа, при необходимости). Например, рассмотрим адрес клиента в системе учета. Адрес необходим в таблице "Клиенты", но и в таблицах "Заказы", "Доставка", "Счета", "Задолженность" и "Коллекции". Вместо хранения адреса клиента в виде отдельной записи в каждой из этих таблиц сохраните его в одном месте либо в таблице Customers, либо в отдельной таблице Адресов.

Третья нормальная форма

• Исключите поля, которые не зависят от ключа.

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

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

ИСКЛЮЧЕНИЕ: соблюдение третьей нормальной формы, в то время как теоретически желательно, не всегда является практическим. Если у вас есть таблица "Клиенты" и вы хотите исключить все возможные межфилдовые зависимости, необходимо создать отдельные таблицы для городов, ZIP-кодов, представителей продаж, классов клиентов и любого другого фактора, который может дублироваться в нескольких записях. Теоретически нормализацию стоит проводить. Однако многие небольшие таблицы могут снизить производительность или превысить открытые емкости файлов и памяти.

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

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

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

Нормализация примера таблицы

Эти шаги демонстрируют процесс нормализации вымышленной таблицы со сведениями об учащихся.

1. Ненормализованная таблица:

   Студент#	Advisor	Adv-Room	Класс1	Класс2	Класс3
   1022	Джонс	412	101-07	143-01	159-02
   4123	Смит	216	101-07	143-01	179-04

2. Первая нормальная форма: отсутствуют повторяющиеся группы

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

   Электронные таблицы часто используют третье измерение, но обычные таблицы не должны этого делать. Другой способ взглянуть на эту проблему — рассмотреть её с точки зрения связи «один ко многим»: не помещайте сторону «один» и сторону «многие» в одну и ту же таблицу. Вместо этого создайте другую таблицу в первой обычной форме, исключив повторяющуюся группу (Class#), как показано в следующем примере:

   Студент#	Advisor	Adv-Room	Класс#
   1022	Джонс	412	101-07
   1022	Джонс	412	143-01
   1022	Джонс	412	159-02
   4123	Смит	216	101-07
   4123	Смит	216	143-01
   4123	Смит	216	179-04

3. Вторая обычная форма: устранение избыточных данных

   Обратите внимание на несколько значений Class# для каждого значения Student# в приведенной выше таблице. Класс# функционально не зависит от student# (первичный ключ), поэтому эта связь не является второй нормальной формой.

   В следующих таблицах показана вторая обычная форма:

   Студенты:

   Студент#	Advisor	Adv-Room
   1022	Джонс	412
   4123	Смит	216

   Регистрации:

   Студент#	Класс#
   1022	101-07
   1022	143-01
   1022	159-02
   4123	101-07
   4123	143-01
   4123	179-04

4. Третья обычная форма: устранение данных, не зависящих от ключа

   В последнем примере Adv-Room (номер офиса помощника) функционально зависит от атрибута Помощника. Решение заключается в перемещении этого атрибута из таблицы "Учащиеся" в таблицу преподавателей, как показано ниже:

   Студенты:

   Учащийся#	Advisor
   1022	Джонс
   4123	Смит

   Факультет:

   Name	Комната	Отдел
   Джонс	412	42
   Смит	216	42