Третья нормальная форма (3NF) - это принцип базы данных, который поддерживает целостность данных, основываясь на принципах нормализации базы данных, предоставляемых первой нормальной формой (1NF) и второй нормальной формой (2NF).
Третья нормальная форма Требования
Существует два основных требования к тому, чтобы база данных находилась в третьей нормальной форме:
- База данных должна соответствовать требованиям как 1NF, так и 2NF.
- Все столбцы базы данных должны зависеть от первичного ключа, что означает, что значение любого столбца может быть получено только из первичного ключа.
О первичной ключевой зависимости
Давайте подробнее рассмотрим, что мы подразумеваем под тем, что все столбцы должны зависеть от первичного ключа.
Если значение столбца может быть получено как из первичного ключа, так и из другого столбца в таблице, это нарушает 3NF. Рассмотрим таблицу Employees с этими столбцами:
- EmployeeID
- Имя
- Фамилия
Как LastName, так и FirstName зависят только от значения EmployeeID? Ну, может LastName зависит от FirstName? Нет, потому что ничего, что присуще LastName, не предложило бы значение FirstName. Может ли FirstName зависеть от LastName? Нет снова, потому что то же самое верно: каким бы ни было LastName, он не мог дать подсказки относительно значения FirstName. Поэтому эта таблица соответствует требованиям 3NF.
Но рассмотрите эту таблицу транспортных средств:
- VehicleID
- производитель
- модель
Производитель и Модель могут быть получены от VehicleID, но Модель также может быть получена от Изготовителя, поскольку модель транспортного средства изготовлена только конкретным производителем. Этот дизайн таблицы не соответствует требованиям 3NF и может привести к аномалиям данных. Например, вы можете обновить производителя без обновления модели, введя неточности.
Чтобы сделать его совместимым, нам нужно переместить дополнительный зависимый столбец в другую таблицу и ссылаться на него с помощью внешнего ключа. Это приведет к двум таблицам:
Стол транспортных средств
В приведенной ниже таблице ModelID является внешним ключом к модели Таблица:
- VehicleID
- производитель
- ModelID
Таблица моделей
Эта новая таблица отображает модели для производителей. Если вы хотите обновить любую информацию о транспортном средстве, характерную для модели, вы должны сделать это в этой таблице, а не в таблице «Транспортные средства».
- ModelID
- производитель
- модель
Производные поля в модели 3NF
Таблица может содержать производное поле, которое вычисляется на основе других столбцов в таблице. Например, рассмотрим эту таблицу заказов виджетов:
- Порядковый номер
- Номер клиента
- Цена за единицу
- Количество
- Всего
Общее нарушение 3NF-соответствия, поскольку оно может быть получено путем умножения цены единицы на количество, а не на полную зависимость от первичного ключа. Мы должны удалить его из таблицы, чтобы соответствовать третьей нормальной форме.
Фактически, поскольку он получен, лучше не хранить его в базе данных вообще.
Мы можем просто вычислить его «на лету» при выполнении запросов к базе данных. Например, мы могли бы ранее использовать этот запрос для получения номеров заказов и итогов:
SELECT OrderNumber, Total FROM WidgetOrders
Теперь мы можем использовать следующий запрос:
SELECT OrderNumber, UnitPrice * Количество AS Всего от WidgetOrders
для достижения тех же результатов без нарушения правил нормализации.
