Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье объясняется терминология нормализации базы данных для начинающих. Базовое понимание этой терминологии полезно при обсуждении проектирования реляционной базы данных.
Описание нормализации
Нормализация — это процесс организации данных в базе данных. Он включает создание таблиц и установление связей между этими таблицами в соответствии с правилами, разработанными как для защиты данных, так и для повышения гибкости базы данных путем устранения избыточности и несогласованности зависимостей.
Избыточные данные тратят место на диске и создают проблемы с обслуживанием. Если данные, которые существуют в нескольких местах, должны быть изменены, их необходимо изменить одинаково во всех местах. Изменение адреса клиента проще реализовать, если эти данные хранятся только в таблице "Клиенты" и нигде в базе данных.
Что такое "несогласованная зависимость"? Хотя для пользователя интуитивно понятно смотреть в таблице "Клиенты" для адреса конкретного клиента, возможно, не имеет смысла искать там зарплату сотрудника, который работает с этим клиентом. Заработная плата сотрудника связана с ним или зависит от него и таким образом должна быть перенесена в таблицу "Сотрудники". Несогласованные зависимости могут затруднить доступ к данным, так как путь для поиска данных может быть пропущен или нарушен.
Существует несколько правил нормализации базы данных. Каждое правило называется "нормальной формой". Если первое правило наблюдается, база данных, как сообщается, находится в "первой нормальной форме". Если выполняются первые три правила, база данных считается "третьей нормальной формой". Хотя возможны другие уровни нормализации, третья нормальная форма считается самым высоким уровнем, необходимым для большинства приложений.
Как и во многих формальных правилах и спецификациях, реальные сценарии не всегда позволяют обеспечить идеальное соответствие требованиям. Как правило, нормализация требует дополнительных таблиц, и некоторые клиенты находят это громоздким. Если вы решите нарушить одно из первых трех правил нормализации, убедитесь, что приложение ожидает любые проблемы, которые могут возникнуть, например избыточные данные и несогласованные зависимости.
Ниже приведены примеры.
Первая обычная форма
- Исключите повторяющиеся группы в отдельных таблицах.
- Создайте отдельную таблицу для каждого набора связанных данных.
- Определите каждый набор связанных данных с первичным ключом.
Не используйте несколько полей в одной таблице для хранения аналогичных данных. Например, для отслеживания элемента инвентаризации, который может поступать из двух возможных источников, запись инвентаризации может содержать поля для кода поставщика 1 и кода поставщика 2.
Что происходит при добавлении третьего поставщика? Добавление поля не является ответом; он требует изменения в программе и таблице и не обеспечивает плавное размещение динамического числа поставщиков. Вместо этого поместите все сведения о поставщиках в отдельную таблицу с именем "Поставщики", а затем свяжите инвентаризацию с поставщиками по ключу с номером элемента или поставщиков с инвентаризацией по ключу с кодом поставщика.
Вторая обычная форма
- Создайте отдельные таблицы для наборов значений, которые применяются к нескольким записям.
- Связать эти таблицы с внешним ключом.
Записи не должны зависеть ни от чего, кроме первичного ключа таблицы (составного ключа, в случае необходимости). Например, рассмотрим адрес клиента в системе учета. Адрес необходим в таблице "Клиенты", но и в таблицах "Заказы", "Доставка", "Счета", "Задолженность" и "Коллекции". Вместо хранения адреса клиента в виде отдельной записи в каждой из этих таблиц сохраните его в одном месте либо в таблице Customers, либо в отдельной таблице Адресов.
Третья нормальная форма
- Исключите поля, которые не зависят от ключа.
Значения в записи, которые не являются частью ключа этой записи, не должны находиться в таблице. Как правило, в любое время содержимое группы полей может применяться к более чем одной записи в таблице, рассмотрите возможность размещения этих полей в отдельной таблице.
Например, в таблице "Подбор персонала" могут быть указаны название университета и адрес кандидата. Но вам нужен полный список университетов для групповой рассылки. Если сведения о университете хранятся в таблице кандидатов, нет способа перечислить университеты без текущих кандидатов. Создайте отдельную таблицу университетов и свяжите ее с таблицей кандидатов с ключом кода университета.
ИСКЛЮЧЕНИЕ: соблюдение третьей нормальной формы, в то время как теоретически желательно, не всегда является практическим. Если у вас есть таблица "Клиенты" и вы хотите исключить все возможные межфилдовые зависимости, необходимо создать отдельные таблицы для городов, ZIP-кодов, представителей продаж, классов клиентов и любого другого фактора, который может дублироваться в нескольких записях. В теории нормализация стоит того, чтобы её проводить. Однако многие небольшие таблицы могут снизить производительность или превысить открытые емкости файлов и памяти.
Возможно, лучше применить третью обычную форму только к данным, которые часто изменяются. Если некоторые зависимые поля остаются, создайте приложение, чтобы пользователь должен проверить все связанные поля при изменении любого из них.
Другие формы нормализации
Четвертая нормальная форма, также называемая Boyce-Codd нормальной формы (BCNF), и пятая нормальная форма существуют, но редко рассматриваются в практическом проектировании. Игнорирование этих правил может привести к менее идеальному проектированию базы данных, но не должно повлиять на функциональность.
Нормализация примера таблицы
Эти шаги демонстрируют процесс нормализации фиктивной таблицы учащихся.
Ненормализованная таблица:
Студент# Помощник Adv-Room Класс1 Класс2 Класс3 1022 Джонс 412 101-07 143-01 159-02 4123 Иванов 216 101-07 143-01 179-04 Первая нормальная форма: отсутствие повторяющихся групп
Таблицы должны иметь только два измерения. Так как один учащийся имеет несколько классов, эти классы должны быть перечислены в отдельной таблице. Поля Class1, Class2 и Class3 в приведенных выше записях указывают на проблемы с проектированием.
Электронные таблицы часто используют третье измерение, но таблицы не должны. Другой способ посмотреть на эту проблему заключается в связи "один ко многим", не помещайте одну сторону и многие стороны в одну таблицу. Вместо этого создайте другую таблицу в первой обычной форме, исключив повторяющуюся группу (Class#), как показано в следующем примере:
Студент# Помощник 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 Вторая обычная форма: устранение избыточных данных
Обратите внимание на несколько значений Class# для каждого значения Student# в приведенной выше таблице. Класс# функционально не зависит от student# (первичный ключ), поэтому эта связь не является второй нормальной формой.
В следующих таблицах показана вторая обычная форма:
Студенчество:
Студент# Помощник Adv-Room 1022 Джонс 412 4123 Иванов 216 Регистрация:
Студент# Класс# 1022 101-07 1022 143-01 1022 159-02 4123 101-07 4123 143-01 4123 179-04 Третья обычная форма: устранение данных, не зависящих от ключа
В последнем примере Adv-Room (номер офиса помощника) функционально зависит от атрибута Помощника. Решение заключается в перемещении этого атрибута из таблицы "Учащиеся" в таблицу преподавателей, как показано ниже:
Студенчество:
Студент# Помощник 1022 Джонс 4123 Иванов Факультет
Имя Комната Отдел Джонс 412 42 Иванов 216 42