Помещение базы данных в третью нормальную форму (3NF)

Третья нормальная форма (3NF) – это принцип базы данных, который поддерживает целостность данных, основываясь на принципах нормализации базы данных, предоставленных первой нормальной формой (1NF) и второй нормальной формой (2NF).

Цель 3NF – улучшить обработку базы данных, а также минимизировать затраты на хранение.

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

Существуют два основных требования к базе данных в 3NF:

  • База данных уже должна соответствовать требованиям как 1NF, так и 2NF.
  • Все столбцы базы данных должны зависеть от первичного ключа, то есть значение любого столбца может быть получено только из первичного ключа.

Зависимость первичного ключа

Давайте подробнее рассмотрим, что мы подразумеваем под тем фактом, что все столбцы должны зависеть от первичного ключа. Если значение столбца может быть получено как из первичного ключа, так и из другого столбца в таблице, это нарушает 3NF. Рассмотрим таблицу сотрудников с этими столбцами:

  • EmployeeID
  • Имя
  • Фамилия

И LastName, и FirstName зависят только от значения EmployeeID? Ну, а может ли LastName зависеть от FirstName? Нет, потому что ничто, присущее LastName, не может предложить значение FirstName.

Может ли FirstName зависеть от LastName? Нет, опять же, потому что то же самое верно: каким бы ни было LastName, оно не может предоставить подсказку относительно значения FirstName. Следовательно, эта таблица соответствует требованиям 3NF.

Но рассмотрим эту таблицу транспортных средств :

  • VehicleID
  • производитель
  • модель

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

Перемещение дополнительного зависимого столбца в другую таблицу и обращение к нему с использованием внешнего ключа сделает его совместимым. Это приведет к двум таблицам:

В Таблице транспортных средств , приведенной ниже, ModelID является внешним ключом таблицы моделей:

  • VehicleID
  • производитель
  • ModelID

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

  • ModelID
  • производитель
  • модель

Производные поля в модели 3NF

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

  • Порядковый номер
  • Номер клиента
  • Цена за единицу
  • Количество
  • Всего

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

Фактически, поскольку он является производным, лучше вообще не хранить его в базе данных, а просто вычислять его на лету при выполнении запросов к базе данных. Например, мы могли ранее использовать этот запрос для получения номеров заказов и итогов:

ВЫБЕРИТЕ OrderNumber, Total

ОТ WidgetOrders

Теперь используйте следующий запрос для достижения тех же результатов без нарушения правил нормализации:

ВЫБЕРИТЕ OrderNumber, UnitPrice * Количество AS Всего

ОТ WidgetOrders

Оцените статью
Solutics.ru
Добавить комментарий